Hacking the Vodafone Station

Well... why hacking the Vodafone Station. Time ago I use to have a Dlink router (a 504T). Now I switched to Vodafone as ISP so I had to use their router in order to connect to their network. In the past I patched Dlink router to have a wake-up site and a dynamic dns software. The Vodafone router is very powerful compared to old one:

• 64MB of RAM
• 16MB of flash which is a lot of software for an embedded system
• 300Mhz dual core MIPS CPU

So wow what an interesting piece of technology.

The problem is Vodafone software... very very limited... software from Broadcom provided ftp, port forwarding, printer server and other interesting settings but Vodafone cut down most of them (at least in my SP01 firmware version) limiting settings to enable/disable wifi ONLY !!!

So why not trying to change even this interesting firmware? So let's start!

First step: documentation

I searched in Internet every informations possible (chipset, software, depliants, software from CPU manufacturer and so on). Some results:

• the Vodafone Station is a Huawei EchoLife HG553
• software is the usual Linux embedded with kernel+squashfs root+boot loader (CFE in this case)
• broadcom provide the software (toolchains, kernel, other blobs and

tools like image builder, bcmImageBuilder) Second step: opening the beast

Just bought (if you don't own already) proper torc screwdrivers remove two pieces of white rubber below behind the Station and open it. Detach USB where to place the Internet Key, and remove gently the board. So you can detect:

• CPU (1F) (see )
• USB header (2F)
• flash (5F)
• ethernet switch (8F) (see )
• ram (3F) (see )
• circuit for VoIP (see )
• Wifi antenna (6F)
• 5 pins headers, soldered (4F)
• 10 pins (1B)
• buffer chip (2B) (see ). I found Vcc with this datasheet.

Now write down every single pieces and again search on Internet for informations.

After many reading on internet you can presume that 5 pins are an UART looking even at similar equipments (like and ).

Now is also time for hardware hacking. Well... I have to confess the my hardware skills are very limited so I had to ask to a collegue of mine to help me. Take a tester and with the help of some datasheets and some logic (like testing for ground near power) detect grounds and some Vcc just checking short circuits so we detect:

• on 5 pins Vcc and ground
• on 10 pins ground and Vcc (3.3V)

UART pinout (pin 5 near capacitor)

1 (3.3V)

2 GND

3 Vcc

4 (0V)

5 (3.3V)

JTag pinout

10 GND	9 (3.3V)
8 (0V)	7 (3.3V)
6 (0V)	5 (3.3V)
4 Vcc	3 (2.4V)
2 GND	1 (0V)

(well I have to confess that we did this things in some steps and I burn down two Maxim max3232cpe chip bought from China). Now turn on the power and measure voltages.

Third step: UART

As I say we tried to connect the 5 pins to an UART. Voltage is 3.3V so we had to build a circuits to adapt voltages (UART works at +/- 12 volts). We found a circuit using max3232cpe. TODO link, diagram and so on. Is better to realize circuit on a bread board first. TODO photos of wires. This circuit was a failure and I burned down 2 chips. At the end I realize that I could build a simple protocol analizer using the 74HC244 (see below) so I was able to catch signal and with a small statistical analisy and a small Perl script I get trasmission signal. You can find the small program to dump signals from serial, and analize them (complete with dumps I got).

Final UART pinout (pin 5 near capacitor)

1 TX

2 GND

3 Vcc

4 ?? (sometime serial output)

5 RX (still to test)

Fourth step: Jtag

So UART was a failure and we tried the Jtag way. This is the first step that required solder on the board !!!

We found on internet informations for circuit (see at OpenWRT) to connect Jtag and a possible pinout (see AVR at ). We bought material (some resistence and the 74HC244, see ) and we built the circuit.

With debrick code and UrJtag I tried many times without success. Than I discovered that UrJtag needs Subversion version (0.90 was not sufficient). But problem was pin order... still unknown. Then I realized a script that try every combination of TCK/TMS/TDO changing debrick code and I get the right IR code (which is 0x635817F see ) !!!

Final JTag pinout

10 GND	9 TDI
8 (nTRST??)	7 (??)
6 (nSRTT??)	5 TMS
4 Vcc	3 TDO
2 GND	1 TCK

Well... Jtag have mainly 4 signals:

• TCK output the clock and must be toggled every time
• TMS give that command
• TDO is the data output
• TDI is data input

The circuit we realized had 3 output and 1 input so an evening I tried for the last time and luckily I get the right code !!! With this circuit and link above I dumped 32MB from 0x1E000000 and get 2 time the flash. With

detectflash 0x1e000000

I got flash information, 128 cells of 128KB so correctly flash is 16MB.

jtag> detectflash 0x1E000000
ImpCode=00000000100000011000100100000100
EJTAG version: <= 2.0
EJTAG Implementation flags: R4k MIPS16 DMA MIPS32
ejtag_dma.c(422) Failed to enter debug mode, ctrl=00000000001000001100000100001000
Query identification string:
	Primary Algorithm Command Set and Control Interface ID Code: 0x0002 (AMD/Fujitsu Standard Command Set)
	Alternate Algorithm Command Set and Control Interface ID Code: 0x0000 (null)
Query system interface information:
	Vcc Logic Supply Minimum Write/Erase or Write voltage: 2700 mV
	Vcc Logic Supply Maximum Write/Erase or Write voltage: 3600 mV
	Vpp [Programming] Supply Minimum Write/Erase voltage: 0 mV
	Vpp [Programming] Supply Maximum Write/Erase voltage: 0 mV
	Typical timeout per single byte/word program: 128 us
	Typical timeout for maximum-size multi-byte program: 128 us
	Typical timeout per individual block erase: 1024 ms
	Typical timeout for full chip erase: 0 ms
	Maximum timeout for byte/word program: 1024 us
	Maximum timeout for multi-byte program: 4096 us
	Maximum timeout per individual block erase: 16384 ms
	Maximum timeout for chip erase: 0 ms
Device geometry definition:
	Device Size: 16777216 B (16384 KiB, 16 MiB)
	Flash Device Interface Code description: 0x0002 (x8/x16)
	Maximum number of bytes in multi-byte program: 32
	Number of Erase Block Regions within device: 1
	Erase Block Region Information:
		Region 0:
			Erase Block Size: 131072 B (128 KiB)
			Number of Erase Blocks: 128
Primary Vendor-Specific Extended Query:
	Major version number: 1
	Minor version number: 3
	Address Sensitive Unlock: Required
	Process Technology: Bad value
	Erase Suspend: Read/write
	Sector Protect: 1 sectors per group
	Sector Temporary Unprotect: Supported
	Sector Protect/Unprotect Scheme: Bad value
	Simultaneous Operation: Not supported
	Burst Mode Type: Supported
	Page Mode Type: 8 word Page
	ACC (Acceleration) Supply Minimum: 11500 mV
	ACC (Acceleration) Supply Maximum: 12500 mV
	Top/Bottom Sector Flag: Uniform top boot device
	Program Suspend: Not supported

Fifth step: dump analisy

Well... this is my field... offline code analisy. Using hexdump, hexedit and some magic from file command I found squashfs file. Before there was a header that strangely correspond to bcmImageBuilder so next must be the kernel and before from processor information and still bcmImageBuilder there is the CFE code. Than I analize bcmImageBuilder and addvtoken and realized structure after 128KB. Mainly there are lengths in decimal, positions in decimals and some crc coded in big endian order but without negating bits. Also last two 128KB cells contains XML settings, specifically at 0xFD0000 and 0xFF0000. After kernel and a bit before first settings cell there are some specific positions that contains serial number, firmware version, wep key, wpa key and other stuff. To sum up flash have this structure:

TODO structure

XML settings is as (with security informations omitted... I hope :) ).

.

.

.

.

Firmware B33 reconstructed.

I found also interesting links for and at Jerome Petazzoni pages.

Thanks

Thanks goes joecool for his support with every hardware stuff and material.

Links

These are unclassified links or less useful links.

$Id: index.html,v 1.14 2009-05-09 08:25:15 cvswrite Exp $