Unpack & repack a firmware for use as an updated version?

Question

I am trying to modify a firmware for TD-W8961ND router because there is a vulnerability that could allow an attacker to download the configuration file of the router which exposes the router password & make him able to control the router's settings later on. I came across the idea to fix it from here. It was able to modify the firmware in virtual memory using the serial port which is not available to me.

So, is there a possibility to apply what he suggested in the firmware then update the router ?

The router firmware is named ras and it was published on 25.11.2011.

Using binwalk, it is apparent that the file is ZynOS. But, I really can't extract the signature as explained there and I really don't know what to do later on.

Edit

binwalk output

~$ binwalk ras

DECIMAL     HEX         DESCRIPTION
-------------------------------------------------------------------------------------------------------------------
84992       0x14C00     ZynOS header, header size: 48 bytes, rom image type: ROMBIN, uncompressed size: 66824, compressed size: 16870, uncompressed checksum: 0xF480, compressed checksum: 0xF03A, flags: 0xE0, uncompressed checksum is valid, the binary is compressed, compressed checksum is valid, memory map table address: 0x0
85043       0x14C33     LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 66824 bytes
128002      0x1F402     GIF image data, version "89a", 200 x 50
136194      0x21402     GIF image data, version "89a", 560 x 50
326749      0x4FC5D     Copyright string: " (c) 2001 - 2011 TP-LINK TECHNOLOGIES CO., LTD.LOGIES CO., LTD."
349184      0x55400     ZynOS header, header size: 48 bytes, rom image type: ROMBIN, uncompressed size: 102400, compressed size: 55931, uncompressed checksum: 0xC892, compressed checksum: 0xC30C, flags: 0xE0, uncompressed checksum is valid, the binary is compressed, compressed checksum is valid, memory map table address: 0x0
349235      0x55433     LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 102400 bytes
405248      0x62F00     ZynOS header, header size: 48 bytes, rom image type: ROMBIN, uncompressed size: 102400, compressed size: 59174, uncompressed checksum: 0x8D2B, compressed checksum: 0x66BC, flags: 0xE0, uncompressed checksum is valid, the binary is compressed, compressed checksum is valid, memory map table address: 0x0
405299      0x62F33     LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 102400 bytes
464640      0x71700     ZynOS header, header size: 48 bytes, rom image type: ROMBIN, uncompressed size: 102400, compressed size: 52399, uncompressed checksum: 0xA2DE, compressed checksum: 0x917A, flags: 0xE0, uncompressed checksum is valid, the binary is compressed, compressed checksum is valid, memory map table address: 0x0
464691      0x71733     LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 102400 bytes
517120      0x7E400     ZynOS header, header size: 48 bytes, rom image type: ROMBIN, uncompressed size: 102400, compressed size: 63920, uncompressed checksum: 0xFEC9, compressed checksum: 0xA7FD, flags: 0xE0, uncompressed checksum is valid, the binary is compressed, compressed checksum is valid, memory map table address: 0x0
517171      0x7E433     LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 102400 bytes
581120      0x8DE00     ZynOS header, header size: 48 bytes, rom image type: ROMBIN, uncompressed size: 102400, compressed size: 54909, uncompressed checksum: 0xF811, compressed checksum: 0x3544, flags: 0xE0, uncompressed checksum is valid, the binary is compressed, compressed checksum is valid, memory map table address: 0x0
581171      0x8DE33     LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 102400 bytes
636160      0x9B500     ZynOS header, header size: 48 bytes, rom image type: ROMBIN, uncompressed size: 102400, compressed size: 61051, uncompressed checksum: 0x36F3, compressed checksum: 0x6A1, flags: 0xE0, uncompressed checksum is valid, the binary is compressed, compressed checksum is valid, memory map table address: 0x0
636211      0x9B533     LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 102400 bytes
697344      0xAA400     ZynOS header, header size: 48 bytes, rom image type: ROMBIN, uncompressed size: 102400, compressed size: 54463, uncompressed checksum: 0x30D8, compressed checksum: 0x9AB9, flags: 0xE0, uncompressed checksum is valid, the binary is compressed, compressed checksum is valid, memory map table address: 0x0
697395      0xAA433     LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 102400 bytes
751872      0xB7900     ZynOS header, header size: 48 bytes, rom image type: ROMBIN, uncompressed size: 12440, compressed size: 6879, uncompressed checksum: 0x5C0A, compressed checksum: 0x1945, flags: 0xE0, uncompressed checksum is valid, the binary is compressed, compressed checksum is valid, memory map table address: 0x0
751923      0xB7933     LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 12440 bytes
759040      0xB9500     ZynOS header, header size: 48 bytes, rom image type: ROMBIN, uncompressed size: 3914416, compressed size: 884839, uncompressed checksum: 0xA904, compressed checksum: 0x73E3, flags: 0xE0, uncompressed checksum is valid, the binary is compressed, compressed checksum is valid, memory map table address: 0x0
759091      0xB9533     LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 3914416 bytes

the guy who revealed the exploit suggested that there isn't Lzma compressed data in the image as it seems to be & it is just big chunk of data in clear text.

Answer 1

It's important to know that not all ZyNOS images are created equal, and the exact steps that worked for piotrbania (as referenced in your question) will likely not work for you.

First, ZyNOS is a Real Time Operating System, and you can think of the entire OS as just one big kernel (i.e., there is no user space or file systems or anything easy to deal with like that). Depending on the ZyNOS version, compiler version, compiler options, target architecture, etc., even the same source code will compile to a different sequence of bytes and instructions, and different versions/flavors of ZyNOS may be "packaged" very differently.

In your case, I can almost guarantee that those LZMA signatures are valid, and probably contain some data/code. There is also probably raw, uncompressed code in the image as well (try binwalk -A to search for raw executable code).

Some general steps that you'll need to accomplish what you want:

1. Decompress all compressed blocks and identify which ones, if any, contain executable code
2. Disassemble all code (probably starting with any code that wasn't compressed to start with, since it's probably used to bootstrap the system and decompress the other sections of the firmware)
3. Part of the disassembly process will be identifying the load address of each code section; without this, data xrefs won't make sense. Look for references to absolute memory addresses for hints (e.g., jumps to direct addresses, function tables, jump tables, etc).
4. Now you can start actually reversing the code, looking for code that handles requests for the ras file. If you're lucky you'll have a symbol table which no disassembler will understand, so you'll have to write a script to parse the symbol table and rename all symbol addresses. If you aren't so lucky, identification of functions must be done manually.
5. Once you have identified the code that needs to be patched, you can patch it in a similar manner to piotrbania, though obviously details may differ slightly for your firmware image.
6. Re-compress and re-pack the firmware image parts, update all header checksums, then upload to your device and hope it doesn't turn into a paperweight. :)

So to answer your question, yes, this is certainly possible. But I'm not aware of a pre-built solution that will allow you to easily extract/patch/re-build the firmware, so it will take some effort to accomplish. Obviously, having some sort of debug access to the device (e.g., UART or JTAG) will help a lot, as evidenced by piotrbania's work.

Answer 2

You could try using firmware-mod-kit and see if you get any further, although firmware-mod-kit is geared to Linux specifically so it may not help that much. Sometimes I have found it can do things that binwalk cannot (and vice-versa for that matter)

Also, you may want to build binwalk from the latest source try again.

Answer 3

This is somewhat old, but I was unable to perform the same task as the OP -- that is, to find a tool that would properly unpack a ZyNOS firmware update image. So I rolled my own. Please grab and try it on your image:

https://github.com/dev-zzo/router-tools/blob/master/zynos.py

The tool does not support packing the image back at the moment, but I am working on it.