4

I am trying to extract this ONT I240w-A firmware and binwalk reports some LZMA compressed data (dump below) but the fact the all of them read "uncompressed size: -1 bytes" makes me suspect they are false positives. Is this a correct assumption? Can someone provide any suggestions on how to unpack this file?

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: -1 bytes
64613         0xFC65          LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: -1 bytes
663307        0xA1F0B         LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: -1 bytes
1277775       0x137F4F        VMware4 disk image
1419798       0x15AA16        LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: -1 bytes
2167742       0x2113BE        LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: -1 bytes
2966631       0x2D4467        LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: -1 bytes
3649662       0x37B07E        LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: -1 bytes
4619541       0x467D15        LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: -1 bytes
5626408       0x55DA28        LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: -1 bytes
6526915       0x6397C3        LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: -1 bytes
7352076       0x702F0C        LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: -1 bytes
8028944       0x7A8310        LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: -1 bytes
8790601       0x862249        LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: -1 bytes
9628455       0x92EB27        LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: -1 bytes
10380524      0x9E64EC        LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: -1 bytes
11136805      0xA9EF25        LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: -1 bytes
11917494      0xB5D8B6        LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: -1 bytes
12590672      0xC01E50        LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: -1 bytes
13354487      0xCBC5F7        LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: -1 bytes
13954117      0xD4EC45        LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: -1 bytes
13955290      0xD4F0DA        uImage header, header size: 64 bytes, header CRC: 0xED8A6EC8, created: 2013-08-16 11:32:36, image size: 2369813 bytes, Data Address: 0x80010000, Entry Point: 0x80014110, data CRC: 0xB66029EE, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: gzip, image name: "Linux Kernel Image"
13955354      0xD4F11A        gzip compressed data, maximum compression, from Unix, NULL date (1970-01-01 00:00:00)
16325167      0xF91A2F        LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: -1 bytes
16476952      0xFB6B18        LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: -1 bytes
Improve this question
1
  • I've been quite busy with this ONT model lately, merely to enable some remote control outside the Motive toolset. How far have you come since your post?
    – EDP
    Commented Dec 23, 2015 at 8:59

2 Answers 2

Reset to default
4

All the LZMA entries appear to be valid, and decompress to tar archives (-1 is a valid file size, and is used when the compressor doesn't know the size of the original data, such as when the data is passed via stdin).

Although the tar file name is the same for most of them ("tmp_file"), the un-tar'd data is different; there appears to be a UBIFS file system in there, as well as plenty of plain text shell scripts and the like:

Scan Time:     2015-07-27 23:33:31
Target File:   /home/eve/Downloads/_FE54869ACAD07.extracted/_6397C3.extracted/tmp_file
MD5 Checksum:  63a711b8ee1cdbb886d572dd610f7a2d
Signatures:    332

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
40361         0x9DA9          Executable script, shebang: "/bin/sh"
90177         0x16041         Executable script, shebang: "/bin/sh"
113593        0x1BBB9         Executable script, shebang: "/bin/sh"
197217        0x30261         Executable script, shebang: "/bin/sh"
203169        0x319A1         Unix path: /opt/tools/broadlight/sysroot)I
297561        0x48A59         Executable script, shebang: "/bin/sh"
376433        0x5BE71         Executable script, shebang: "/bin/sh"
388553        0x5EDC9         Executable script, shebang: "/bin/sh"
396018        0x60AF2         Unix path: /../sysroot/usr/include
415009        0x65521         Executable script, shebang: "/bin/sh"
415617        0x65781         Executable script, shebang: "/bin/sh"
431897        0x69719         Executable script, shebang: "/bin/sh"
436698        0x6A9DA         HTML document header
504153        0x7B159         Executable script, shebang: "/bin/sh"
629257        0x99A09         Executable script, shebang: "/bin/sh"
629673        0x99BA9         Executable script, shebang: "/bin/sh"
630169        0x99D99         Executable script, shebang: "/bin/sh"
630889        0x9A069         Executable script, shebang: "/bin/sh"
678623        0xA5ADF         Unix path: /x86-linux2/../sysroot/usr/include


Scan Time:     2015-07-27 23:33:31
Target File:   /home/eve/Downloads/_FE54869ACAD07.extracted/_862249.extracted/tmp_file
MD5 Checksum:  099fbe96cd12990a19fe55e2dc4b651c
Signatures:    332

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             UBIFS superblock node, CRC: 0xD1C96755, flags: 0x0, min I/O unit size: 2048, erase block size: 129024, erase block count: 157, max erase blocks: 288, format version: 4, compression type: lzo
129024        0x1F800         UBIFS master node, CRC: 0xCB83706A, highest inode: 1330, commit number: 0
258048        0x3F000         UBIFS master node, CRC: 0xC7B38577, highest inode: 1330, commit number: 0

I don't know of any good tools to work with UBIFS though, maybe someone else here has some suggestions?

Improve this answer
0
3

First of all I'll start by saying that I'm only writing a partial solution since I don't have the time to fully extract it.

You are correct to assume you have a lot of false positives, however the start of the file does seem to be lzma compressed. The easiest way to check (that's what I did) is to look at it with a hex editor and if the header is ok try to decompress.

The results of the decompression: decompressed

Further more it seems the firmware has several sections and contains a wind river linux: "C: (Wind River Linux Sourcery G++ 4.4a-323) 4.4.1"

You can read about something similar here: http://www.devttys0.com/2011/07/reverse-engineering-vxworks-firmware-wrt54gv8/

Improve this answer
2
  • Thanks. Yes, it looks like something was decompressed by "lzma -d" and file size changed from 16726547 to 20766720 bytes. The "file" utility identifies the unpacked file as a TAR file, and "tar -x" extracts a "tmp_file" (only 720896 bytes). If I use "binwalk -e" it does extracts a few more blocks. I haven't been able to advance much more, but I will keep trying. Thanks again.
    – Maurice
    Commented Jun 29, 2015 at 23:49
  • All Alcatel-made executables on this box contain this string.
    – EDP
    Commented Dec 23, 2015 at 9:01

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.