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.


Author: vasvir

Interested in a wide range of topics from deep learning and big-data to embedded, from web GUI (GWT) to API and code consolidation. Maintainance is also fun for me unlike many other normal people...

5 thoughts on “TrendChip firmware (ZTE-H108NS): Update to handle newer firmware”

    1. Hi , your articles and comments are very useful. Could you please tell me if there is a utility that flashes image firmware on this zte router when the router is in recovery mode (eg. holding the reset button for 10 seconds after plugging in the power supply). I made a little modification and as vasvir wrote before “asssumption is the mother of all fuck ups”. The router boots for 10 secs and then reboots. I tried a tftpd method but router never asks for recovery image file.
      Alternatively is there any way of flashing firmware via usb port?
      Thank you and keep up the good work


  1. vasvir and Stav, really nice work!

    However, can one of you explain more the process of downgrading to 1.07?
    What commands need to be used with tcrevenge (the one with Stav’s changes) on the tclinux.bin provided by OTE Help site?


    1. @Vasos,

      Thanks for taking the time to read it.

      In order to downgrade you need to find the older firmware first which may not be an easy task.

      Furthermore tcrevenge will now also work for the newer 1.17 firmware. However tcrevenge cannot help you downgrade. tcrevenge can help you assemble a bootable firmware image having your modifications.

      The order of things are: 1) Download the firmware from your modem 2) Run tcrevenge in check mode to see what it understands from your original firmware. 3) Break the original firmware in pieces. 4) Assemble it back with tcrevenge as a positive control. It should be the same on a byte to byte level. 5) Now do your modifications and assemble it back. This is your new firmware… Be aware that this could easily brick your modem.

      Let us know how it went


  2. @Nikos,

    I don’t know any such utility. While I was disassembling the device AFAIR I saw http error messages. Maybe the modem’s bootloader initializes a minuscule http server?

    I would propose the following:
    1) Setup a nmap port scan (and maybe a fullscan)
    2) Setup a tcpdump session to log everything that comes from the modem

    I don’t want to disappoint you but it is also possible that the modem enters the emergency flash mode only from a serial connection via jtag. I had open the modem but I didn’t get any pictures and now I don’t remember how it is like inside.

    Let us know what you may find.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s