8

I'm trying to unpack this firmware image but I'm getting some issues understanding the structure.

First of all I have one image which I called firmware.bin, and the file command shows me that it's a LIF file:

firmware.bin: lif file

After that I analyze it with binwalk:

DECIMAL     HEX         DESCRIPTION
-------------------------------------------------------------------------------------------------------
84992       0x14C00     ZynOS header, header size: 48 bytes, rom image type: ROMBIN, uncompressed size: 65616, compressed size: 16606, uncompressed checksum: 0xBA2A, compressed checksum: 0x913E, 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: 65616 bytes
128002      0x1F402     GIF image data, version 8"9a", 200 x 50
136194      0x21402     GIF image data, version 8"7a", 153 x 55
349184      0x55400     ZynOS header, header size: 48 bytes, rom image type: ROMBIN, uncompressed size: 3113824, compressed size: 733298, uncompressed checksum: 0x3B9C, compressed checksum: 0xBBBA, 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: 3113824 bytes

As you can see there are 2 LZMA, 2 ZynOS (LZMA also once cut) and 2 images. Once I extract the LZMA I uncompress it and the first one is a single binary, but the second one is another LZMA file with 127 files in it, and each one of those files have a lot of new files inside.

File content sample

I guess that I'm not following the correct steps to unpack it, so I'm wondering how could I get the main filesystem clean?.

Improve this question
1

1 Answer 1

Reset to default
8

The output from the file utility, as you've probably guessed, is a false positive. The beginning of the firmware.bin file contains what looks to be a basic header (note the "SIG" string near the beginning of the file), and a bunch of MIPS executable code, which is likely the bootloader:

DECIMAL         HEX             DESCRIPTION
-------------------------------------------------------------------------------------------------------------------
196             0xC4            MIPS instructions, function epilogue
284             0x11C           MIPS instructions, function epilogue
372             0x174           MIPS instructions, function epilogue
388             0x184           MIPS instructions, function epilogue
416             0x1A0           MIPS instructions, function epilogue
424             0x1A8           MIPS instructions, function prologue
592             0x250           MIPS instructions, function epilogue
712             0x2C8           MIPS instructions, function epilogue
720             0x2D0           MIPS instructions, function prologue
832             0x340           MIPS instructions, function epilogue
840             0x348           MIPS instructions, function prologue
912             0x390           MIPS instructions, function epilogue
920             0x398           MIPS instructions, function prologue
976             0x3D0           MIPS instructions, function epilogue
984             0x3D8           MIPS instructions, function epilogue
1084            0x43C           MIPS instructions, function epilogue
1192            0x4A8           MIPS instructions, function epilogue
1264            0x4F0           MIPS instructions, function epilogue
...

Running strings on the firmware.bin binary seems backup this hypothesis, with many references to checksum and decompression errors:

checksum error! (cal=%04X, should=%04X)
     signature error!
     (Compressed)
start: %p
     unmatched objtype between memMapTab and image!
     Length: %X, Checksum: %04X
     Version: %s, 
     Compressed Length: %X, Checksum: %04X
memMapTab Checksum Error! (cal=%04X, should=%04X)
memMapTab Checksum Error!
%3d: %s(%s), start=%p, len=%X
%s Section:
memMapTab: %d entries, start = %p, checksum = %04X
$USER Section:
signature error!
ROMIO image start at %p
code length: %X
code version: %s
code start: %p
Decompressed image Error!
Decompressed image Checksum Error! (cal=%04X, should=%04X)
ROM length(%X) > RAM length (%X)!
Can't find %s in $ROM section.
Can't find %s in $RAM section.
RasCode

A quick examination of the strings in the two decompressed LZMA files you found shows that the smaller one (at offset 0x14C33) appears to contain some debug interface code, likely designed to be accessed via the device's UART:

                        UART INTERNAL  LOOPBACK TEST
                        UART EXTERNAL  LOOPBACK TEST
ERROR
======= HTP Command Listing =======
< press any key to continue >
 macPHYCtrl.value=
                        MAC INTERNAL LOOPBACK TEST 
                        MAC EXTERNAL LOOPBACK TEST 
                        MAC INTERNAL LOOPBACK 
                        MAC EXTERNAL LOOPBACK 
 LanIntLoopBack ...
Tx Path Full, Drop packet:%d
0x%08x
tx descrip %d:
rx descrip %d:
%02X 
%08X: 
< Press any key to Continue, ESC to Quit >
0123456789abcdefghijklmnopqrstuvwxyz
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
<NULL>
) Register Dump *****
***** ATM SAR Module: VC(
Reset&Identify reg   = 
Traffic Sched. TB reg= 
TX Data ctrl/stat reg= 
RX Data ctrl/stat reg= 
Last IRQ Status reg  = 
IRQ Queue Entry len  = 
VC IRQ Mask register = 
TX Data Current descr= 
RX Data Current descr= 
TX Traffic PCR       = 
TX Traffic MBS/Type  = 
TX Total Data Count  = 
VC IRQ CC Mask reg   = 
TX CC Current descr  = 
TX CC Total Count    = 
RX Miss Cell Count   = 
***** ATM SAR Module: Common Register Dump *****

The second larger file (at offset 0x55433) appears to contain the ThreadX RTOS, by Green Hills:

RTA231CV Reserved String
anonymous
www.huawei.com
1000
tc-e4f6ed2f5b87<
MSFT 5.07
user<
MSFT 5.07
LXT972
"AC101L
CIP101
RTL8201
CAC201
jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj
jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj
jjjjjjjj
jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj
jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj
jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj
jjjjjjjj
jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj
System Timer Thread
Copyright (c) 1996-2000 Express Logic Inc. * ThreadX R3900/Green Hills Version G3.0f.3.0b *

If you aren't familiar with RTOS's, they typically are just one big kernel with no concept of user space vs kernel space or what you would think of as a normal file system, although they will contain things like images and HTML files for this device's Web interface (see here for an example of how these types of files are stored/accessed in some VxWorks systems).

I'd say that you already pretty much have this firmware extracted into its basic parts. To further analyze the bootloader or the two extracted LZMA files, you will need to start disassembling those files, which entails determining the memory address where they are loaded at boot time, identifying code/data sections, looking for possible symbol tables, identifying common functions, and probably writing some scripts to help with all of the above.

Improve this answer
4
  • Wow, this was exactly what I need, thank you so much, awesome as always. Just one more question, Is there a guide to identify headers? I'm pretty new in this field (In fact I started after reading your work on WAG120N) and sometimes is hard to detect false positives or strange FS/files. Regards.
    – Nucklear
    Commented Jul 30, 2013 at 7:15
  • It varies based on the file you are looking at, but generally file/firmware headers consist of 2-4 "magic" bytes, followed by some structured data which usually includes things like file size, creation date, checksum(s), and possibly a human-readable ASCII description. It is often useful to interpret each offset as various data types (big/little endian longs, shorts, date codes, etc) to identify these fields in an unknown header (I use binwalk's -C option, but any good hex editor will have this capability as well).
    – devttys0
    Commented Jul 30, 2013 at 12:09
  • Yes, I understand that, but once identified those headers how could I identify what FS/File it is with almost 0 experience? Is there any resources to compare headers and identify it? I see in your blog that you sometimes say "Oh this is a LZMA header" or even a "weird LZMA header" how do you identify that headers without previous knowledge? Regards.
    – Nucklear
    Commented Aug 1, 2013 at 10:36
  • I would start by looking at the entropy of the data, which can give you a good idea if it's encrypted, compressed or neither. If, for example, it looks compressed, I would then start comparing the beginning of the header to known common compression types (lzma, zlib, etc). Failing that, you will probably need to reverse the code responsible for accessing/decompressing that data.
    – devttys0
    Commented Aug 1, 2013 at 17:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.