Building custom binaries

[zefie]

I have managed to create some custom binaries (including dropbear for SSH) that execute on the device.
I started with Buildroot (https://git.busybox.net/buildroot) then checked out an old version (tag 2016.02), and been manually updating the packages I want from the current master git.

So far I have gotten the following to work:

• htop (3.1.2)
• tmux (3.1c)
• nano (version 2.5.1)
• dropbear (v2020.81)
• openssl (update from 1.0.2h to 1.1.1.n)
• openvpn (v2.5.6, did not test connection yet)

If you are interested my buildroot setup is here: https://github.com/zefie/buildroot/tree/TMOHS1

[c-herz]

This is awesome, great work! I'll look into maybe adding the installation of some of these (most interested in SSH) to the script. Buildroot has always seemed a bit daunting to me so I never fully got into it, but this is really cool, nice job!

[zefie]

I switched from dropbear to openssh server and SFTP works too. Have to manually add the sshd user, and my maketar patches the sshd_config to allow password login. keys work fine too (in /home/root/.ssh/authorized_keys) with both openssh and dropbear, but I wanted SFTP.

[realtkco]

I was unable to build buildroot, Is there any help with it? https://github.com/realtkco/buildroot - I had to make as some repos were out of date, but now I get these errors.

[c-herz]

I actually have a fork of 2022.11 buildroot I've been experimenting with that I've used to successfully compile binaries on the device. Though it is quite unstable (I've taken away a lot of the checks that Buildroot does to ensure compatibility), it successfully builds an aarch64->armv7 toolchain that can compile working binaries on the Tmohs. (My main machine is a Mac with Apple Silicon, and I've been developing under an aarch64 Ubuntu VM). Once I clean this buildroot up a little and ensure the defconfig works at least somewhat, I'll make the repo public. If you'd like the precompiled aarch64 SDK to build on another Linux arm64 host, I can provide that now, however.

[c-herz]

Update: I've verified it works and made the repo public at https://github.com/c-herz/tmohs-buildroot. I've only tested it on an aarch64 host, but it should (hopefully) be able to build a cross toolchain for the TMOHS1 based on modern software out of the box.

[realtkco]

Going to test it out now :)

[realtkco]

Unable to build it :/ Would be cool if you put the built file in releases.

[c-herz]

@realtkco I took your suggestion and added precompiled cross-SDKs for both Linux x86 and aarch64 to the releases section :). Hopefully that takes out some of the headache and lets you use them to compile for the TMOHS1 right away.

And that's strange that it wasn't building--I cloned the repo on a stock WSL Ubuntu instance, and it built just fine when I followed the instructions I added to the beginning of the README. Did you follow those instructions, i.e. run "make tmohs1_defconfig" and "make sdk"? Did you have all the Buildroot dependencies installed on your host machine? If the answer to both of these is yes, do you mind telling me your platform/OS and the specific error you received? If an issue exists in building the SDK on some platforms I'd like to at least try to fix it.

[realtkco]

Yes, it locks up on make SDK. I had a friend try, tried it in WSL, a sep ubuntu VM, and codespaces. Pretty sure we are missing dependencies.

[foureight84]

Would it be possible to turn this hotspot into a Wifi bridge and tether the connection via USB?

[realtkco]

It tethers automatically with windows at least. Bridging would only be a few more steps. If you want full functionality just buy a 4G Router

[foureight84]

It tethers automatically with windows at least. Bridging would only be a few more steps. If you want full functionality just buy a 4G Router

Ah yea. I'm just looking to get it to connect to my wifi and tether the connection via USB to my chrome os flex. Trying to use this instead of buying a USB dongle.

[c-herz]

I bet this is possible; I've gotten it to connect to WiFi before. Had to use wpa_cli, just added a network, configured it, and enabled it. I didn't even need to run any custom software to do this. It felt very hacky and did not persist through a reboot but I was able to connect to a 2.4ghz network. Have never tried tethering from it after that before, but I bet you could since it's configured to share from its usb port by default. I'm interested in hearing the result of this.

[realtkco]

@c-herz Sorry to be off topic, Have you dumped the firmware of TMOHS1 somewhere?

@foureight84 Some chromebooks have a sim slot :) Else I would recommend 4G USB Dongle sticks.

[c-herz]

@c-herz Sorry to be off topic, Have you dumped the firmware of TMOHS1 somewhere?

I've managed to dump some of the MTD partitions, but not all of them. Something about the Qualcomm Linux NAND driver qpic_nand seems to lock up the entire system in really strange, inconsistent ways when you try to access /dev/mtd2 "efs" (or at least I think this driver is the culprit). I assume this is a security feature so that the application processor cannot access data that is supposed to be only relevant to the modem subsystem (configuration data about simlock, IMEI, etc) and not in Linux userspace. Purely speculating, though. They don't use the standard Linux MTD driver either way, it appears. Also got similar results trying to access "mibib", if I'm remembering correctly. I'll see if I can find some of the dumps, but they may be on a drive I do not have with me right now.

[foureight84]

I'll update once I get it working. I was able to connect earlier with WPA supplicant. But I was in ADB shell so tethering wasn't enabled. I'm gonna see if I can just get it to work with a cron script.

@realtkco Yes. But I'm using chrome os flex on a thin client and built-in wifi isn't working. I'm just trying to reuse this hotspot to fill that gap so it doesn't end up in the landfill.

[c-herz]

@foureight84 I can't see why this wouldn't work. You might also be able to set it up to use a persistent custom wpa_supplicant.conf and an init script, but I didn't want to modify the filesystem too much so I haven't tried this. If it doesn't tether at first once connected to WiFi, you might be able to enable tethering via QCMAP_CLI or MCM_MobileAP_CLI (undocumented tools related to configuring some of the network sharing modes the hotspot can be placed in).

Edit: @realtkco I found the dumps, but I haven't been able to actually extract files from the main MTD partition (/dev/mtd16) with ubireader due to the UBI images embedded in mtd16 containing corrupted LEBs, so I'm not really sure about their integrity, and I would absolutely not trust trying to flash one of them somehow and not breaking things. Also, they are far from unmodified (especially cachefs). Finally, I'm not even sure whether the full MTD dumps I have contain OOB data or not. It also appears that Wingtech actually did it properly and used a custom T-Mobile CA to sign each bootloader stage along with the modem firmware, and I assume the secure boot fuses on the SOC are irreversibly blown, so I doubt you could flash anything custom on any of the other MTD partitions either.

Rather off topic, but it's kind of odd how they clearly made choices to increase security--like implementing a proper chain of trust during boot and hardening SIM unlocking to do most of the interesting stuff through obscure, Qualcomm-proprietary protocols/busses that communicate with the secure modem subsystem from Linux userspace--yet still left a gaping CLI injection vulnerability in the web interface and never used the (seemingly fully-implemented) FOTA system to fix it. I feel like this disconnect might be explained by the fact that most of these secure routines are actually implemented by Qualcomm code rather than T-Mobile/Wingtech, and Qualcomm definitely knows how to secure their software. Compared to the TMOHS, the Franklin T9 had most of these secure routines reinvented (?) by Franklin in userspace, drastically reducing the security of the device. They also signed the firmware with the developer "testing" certificates (lol). Wingtech seemed to opt for the Qualcomm-provided implementations, which are much more secure, yet the web frontend is their own work, apparently written to lower security standards.

[parkerlreed]

Speaking of custom binaries: has anyone figured out if the USB port can be host?

I've tried a USB C to A adapter but nothing shows up with lsusb or under /sys

[parkerlreed]

So the DTB has peripheral only mode set. Has anyone attempted to edit the DTB for host mode?

/sys/firmware/devicetree/base/soc/usb@78d9000 # hexdump -Cv qcom,hsusb-otg-mode
00000000  00 00 00 01                                       |....|
00000004

[parkerlreed]

Thanks for the buildroot! I got an application compiled in anticipation of getting USB host working

(deck@steamdeck ~)$ file Pictures/arm-tmohs1-linux-gnueabi_sdk-buildroot/DslrDashboardServer/ddserver 
Pictures/arm-tmohs1-linux-gnueabi_sdk-buildroot/DslrDashboardServer/ddserver: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 3.18.0, not stripped

#Over telnet
/var/volatile/tmp # LD_PRELOAD=/tmp/libusb-1.0.so.0 ./ddserver
^C
/var/volatile/tmp # 

[SZRabinowitz]

can I use buildroot to build python for this hotspot? I'd love to be able to run python on there but I am going crazy trying to figure it out

[SZRabinowitz]

I was able to build python with the buildroot from @c-herz but I have libc errors when trying to run it.