TrendChip firmware (ZTE-H108NS): Update to handle newer firmware

This is the fourth article in a series of articles documenting the reverse engineering of the TrendChip firmware image and the disassembly of its CRC checksum algorithm.

A small update for the newer firmware (1.17 as distributed by OTE).

tcrevenge was not working with the latest firmware because the version number of the firmware (called surprisingly model number in tcrevenge) was hard coded. Initial tests have been done with firmware 1.07 (model number: 3 6035 122 74) while the 1.17 firmware has model number: 3 6035 122 89.

Newest firmware do not allow older firmware to be uploaded so this was a major problem. Thanks to the efforts of user stav it was possible to identify the problem and add a command line option in tcrevenge to manually set the model number. Now when running tcrevenge in check mode it reads:

Manual check (all tests have been done with model 3) Model: 3 6035 122 74 found 3 6035 122 79. If they differ use -m to adjust.

While I was at it I also added a command line argument for the field called firmware_version. Despite the classy name, looks like it is used only for printing and the firmware does not actually run any checks against it.

With these changes in place there are two variables left in the header section that we don’t know how they are used.

  • magic_number with value 0x32524448
  • magic_device with value 0x100 // this is probably the header size

if the need arises I will add a way to set them from the command line too – but it looks that some disassembly is required first.

The modifications are committed and pushed in the repository so you are ready to roll.

Looks like that version 1.17 as distributed by OTE has disabled the telnet functionality. Again read the comments of user stav how to solve this and how to get rid of the TR69 and CWMP functionality.

Advertisements

TrendChip firmware (ZTE-H108NS): Build custom software – add namecheap DDNS support

This is the third article in a series of articles documenting the reverse engineering of the TrendChip firmware image and the disassembly of its CRC checksum algorithm.

In this installment we will see how it is possible to create custom software that will run on your modem router. The task at hand is to modify the ez-ipupdate software so it can handle namecheap’s DDNS protocol. Let’s see first how we can build custom software (hello_world.c – How original!), and then we will take a look at the namecheap’s DDNS protocol and finally we will modify the ez-ipupdate. Sounds like a plan, isn’t it?

What could possibly go wrong?
Petrified - Tinos. Photo by Christos AndronisPhoto by Christos Andronis.

Building software for TrendChip firmware

Generally there are two ways to build software for a foreign architecture.

  1. Cross compile (in the host machine)
  2. Build in place (in the target machine)

Cross compiling means that after setting the cross compiler we will need to cross compile the target system’s libc. In this case the target’s libc is uClibc version 0.9.30. Debian’s support for cross architectures reaches its limit in this one. There is a package named gcc-mips-linux-gnu that provides MIPS compiler with GNU libc (glibc). So I assume there is room for fame and glory for somebody to provide gcc-mips-linux-uclibc packages for Debian. I am father of two,the time is limited, the clock is ticking and surprisingly I don’t feel the urge to do the famous 3 stage bootstrap of gcc. Maybe it’s just me getting older.

What about the other option – building in place?

The problem in the second option is that the modem is not equipped neither with a compiler nor the development headers of a libc. The space required for this machinery is very big compared with the 23M that the uncompressed squashfs has.

So what’s left? Google I suppose and lo and behold – I found it. The uClibc project builds system images for all uClibc versions. You can boot the system image with qemu like this

system-image-mips$ ./run-emulator.sh 
Linux version 2.6.25.10 (landley@driftwood) (libc/sysdeps/linux/mips/crt1.S:(.text+0x1c): undefined reference to `main') #1 SMP Sun Nov 23 06:55:47 CST 2008

LINUX started...
Overriding previous set SMP ops
console [early0] enabled
CPU revision is: 00019300 (MIPS 24K)
FPU revision is: 00739300
registering PCI controller with io_map_base unset
Determined physical RAM map:
 memory: 00001000 @ 00000000 (reserved)
 memory: 000ef000 @ 00001000 (ROM data)
 memory: 0025a000 @ 000f0000 (reserved)
 memory: 07cb5000 @ 0034a000 (usable)
Wasting 26944 bytes for tracking 842 unused pages
Zone PFN ranges:
  DMA             0 ->     4096
  Normal       4096 ->    32767
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0:        0 ->    32767
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
Kernel command line: root=/dev/hda console=ttyS0 rw init=/usr/bin/qemu-setup.sh panic=1 PATH=/usr/bin 
Primary instruction cache 2kB, VIPT, 2-way, linesize 16 bytes.
Primary data cache 2kB, 2-way, VIPT, no aliases, linesize 16 bytes
Synthesized clear page handler (26 instructions).
Synthesized copy page handler (46 instructions).
Cache parity protection disabled
PID hash table entries: 512 (order: 9, 2048 bytes)
CPU frequency 200.00 MHz
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 126396k/127700k available (1843k kernel code, 1140k reserved, 263k data, 136k init, 0k highmem)
Mount-cache hash table entries: 512
Trying to install interrupt handler for IRQ16
Trying to install interrupt handler for IRQ17
Brought up 1 CPUs
net_namespace: 160 bytes
NET: Registered protocol family 16
pci 0000:00:0a.3: quirk: region 1100-110f claimed by PIIX4 SMB
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
io scheduler noop registered (default)
rtc: SRM (post-2000) epoch (2000) detected
Real Time Clock Driver v1.12ac
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250.2: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
console handover: boot [early0] -> real [ttyS0]
serial8250.2: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
loop: module loaded
pcnet32.c:v1.34 14.Aug.2007 tsbogend@alpha.franken.de
PCI: Enabling device 0000:00:0b.0 (0000 -> 0003)
pcnet32: PCnet/PCI II 79C970A at 0x1020, 52:54:00:12:34:56 assigned IRQ 10.
eth0: registered as PCnet/PCI II 79C970A
pcnet32: 1 cards_found.
Uniform Multi-Platform E-IDE driver
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
hda: QEMU HARDDISK, ATA DISK drive
hdc: QEMU DVD-ROM, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 512KiB
hda: 4194304 sectors (2147 MB) w/256KiB Cache, CHS=4161/255/63
hda: cache flushes supported
 hda: unknown partition table
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem).
Freeing prom memory: 956k freed
Freeing unused kernel memory: 136k freed
eth0: link up
Type exit when done.
/ #

 

The system image provides gcc-4.1.2 while the binaries in the modem are built with gcc-3.4.6 (at least the kernel). Let’s hope that the backward compatibility would be good enough in order to build things in the system-image and then copy them in the squashfs filesystem of the modem.

FileSystem woes

Before we continue we need to adjust the environment to our development cycle. The uclibc provided system image is 64MB (around 50MB root filesystem). It has vi and gcc and make but nothing more. It would be nice if we could mount some host’s exported directories in order to:

  • have available more space for the software builds
  • use host based editors and file managers

The combination of qemu and linux provides 3 ways to mount host’s provided directories. For more information and the gory details check this article by Rob Landley and Mark Miller especially this part.

  1. NFS
  2. SAMBA (private samba server runs by qemu with -smb option)
  3. FAT image

Any of them should work in theory but you should know the drill by now. It took me two weeks to accept the bitter truth of failure. The reason of the failure was that the uclibc provided kernel has no support for modules and no support for NFS, SMB and FAT filesystems. It took me a week and several network dumps from wireshark to figure out that the dreaded 111 mount returned error means the kernel has no support for NFS. It took me one more week to accept the fact that I can’t build a kernel for MIPS because:

  • buildroot of the time fails when it’s trying to build the kernel in a modern system
  • cross compiling a MIPS kernel on a recent Debian gives many errors on older kernels and a fatal one in the latest. In any case I cannot find the zImage target in the generated Makefiles.

So what is left? I resized the rootfs image to 2GB and mount it with the loop device. Of course concurrent access via the host and the emulated guest is not allowed so you have to be careful and run qemu / mount / unmount / run qemu again all the time.

Here is how to resize a filesystem image:

#dd if=/dev/zero of=disk.img bs=1M count=1024 oflag=append conv=notrunc
#e2fsck -f disk.img
#resize2fs disk.img

and here is how to mount / unmount between qemu invocations

#mount -o loop ./uclibc/0.9.30/system-image-mips/image-mips.ext2 /mnt/
#umount ./uclibc/0.9.30/system-image-mips/image-mips.ext2

ez-ipupdate invocation

The first step is to establish the beachhead. We make sure that hello world works. Indeed although the compiler is different – compiling in the guest system is good enough for the hello world to run in the modem just by copying the executable around (and rebuilding the firmware with tcrevenge).

The ez-ipupdate is free software hosted on sourceforge. It is written in C so in theory a modification like this is relatively easy. The namecheap’s DDNS protocol is not exactly rocket science to get right. So let’s see what the TrendChip firmware is doing and how it invokes the ez-ipupdate.

There is the file /etc/ddns.conf which looks like a direct dump of what is stored in the XML romfile. Probably cfg_manager dumps it in that form so subsequent scripts can operate on this data more easily.

# cat /etc/ddns.conf 
Active="Yes"
SERVERNAME="www.dyndns.org"
MYHOST="myhost.mydomain.noip"
USERNAME="username"   # It is literally username as it not prefixed with my (as in myusername)
PASSWORD="mypassword"
WILDCARD="No"

Then there is /etc/ipupdate.conf

# cat /etc/ipupdate.conf 
user=username:mypassword
host=myhost.mydomain.noip
service-type=dyndns
max-interval=2073600

which is what will be feed to the ez-ipupdate executable.

There are two scripts. The usr/script/ddns.sh converts the /etc/ddns.conf to the /etc/ipupdate.conf. The other one (/usr/scripts/ddns_run.sh) runs the ez-ipupdate with the /etc/ipupdate.conf as configuration parameter.

Namecheap’s DDNS protocol

It’s not really a protocol. It’s a http GET with certain parameters to the namecheap’s server. Here is how you can update your PC’s DNS manually with curl.

$curl https://dynamicdns.park-your-domain.com/update?host=myhost&domain=mydomain.com&password=mypassword&ip=myip

The only tricky part left is to parse the variables in the configuration file and assemble the GET request.

Finally: Compiling custom software – ez-ipupdate

The following patch implements namecheap support at expense of dyndns support. The potential users of this hack must use the configuration entries of the WEB GUI to fill the proper information in the dyndns section. The TrendChip firmware will use the hostname and password but it will connect to the namecheap’s servers instead.

diff -ur ez-ipupdate-3.0.11b7.orig/ez-ipupdate.c ez-ipupdate-3.0.11b7/ez-ipupdate.c
--- ez-ipupdate-3.0.11b7.orig/ez-ipupdate.c     2002-03-12 01:31:47.000000000 +0200
+++ ez-ipupdate-3.0.11b7/ez-ipupdate.c  2015-03-01 20:35:57.981976162 +0200
@@ -56,9 +56,9 @@
 #define DHS_REQUEST "/nic/hosts"
 #define DHS_SUCKY_TIMEOUT 60
 
-#define DYNDNS_DEFAULT_SERVER "members.dyndns.org"
+#define DYNDNS_DEFAULT_SERVER "dynamicdns.park-your-domain.com"
 #define DYNDNS_DEFAULT_PORT "80"
-#define DYNDNS_REQUEST "/nic/update"
+#define DYNDNS_REQUEST "/update"
 #define DYNDNS_STAT_REQUEST "/nic/update"
 #define DYNDNS_MAX_INTERVAL (25*24*3600)
 
@@ -1919,11 +1919,20 @@
     output(buf);
   }
 
-  snprintf(buf, BUFFER_SIZE, "%s=%s&", "hostname", host);
+  char *dot = strchr(host, '.');
+  *dot = 0;
+  char *domain = dot + 1;
+  
+  snprintf(buf, BUFFER_SIZE, "%s=%s&", "host", host);
+  output(buf);
+  snprintf(buf, BUFFER_SIZE, "%s=%s&", "domain", domain);
+  output(buf);
+  snprintf(buf, BUFFER_SIZE, "%s=%s&", "password", password);
   output(buf);
+    
   if(address != NULL)

One more note: The size of the final ez-update was 122624 bytes while the original was only 84720 bytes. Could it be the compiler? I tried with -Os and stripped all symbols. My guess for this sudden file increase is that ez-ipupdate has support for many DDNS protocols that are not listed in the web GUI of the Trendchip firmware. It is possible therefore that they had stripped the support of the missing protocols from the ez-ipupdate in order to save space.

After patching and moving the ez-ipupdate sources to the guest system the usual procedure of

$./configure
$make

can be used to build the software for MIPS. Copy the resulting executable to the expanded squashfs, create squashfs image, rebuild the firmware and upload it to the modem and you are ready.

Hope it was fun. Now off you go to build minidlna in order to enable streaming from your modem router.