1

I'm attempting to reverse engineer the DI-8002W firmware from Dlink in order to search for vulnerabilities within the router. I'm at the point where I've recovered the Linux Image, but I cannot recover the file system itself at the moment. I'll walk through what I've done so far.

Firmware can be found here - http://support.dlink.com.cn/ProductInfo.aspx?m=DI-8002W (Second Option)

Extracting uImage

Unzipping the download shows us DI_8002W-16.07.26A1.trx. This appears to be invalid from a strictly "trx" format, but rather has some Dlink specific information in the first 76 bytes such as VER216.07.26, etc. I strip this off with DD to get the uBoot image from the trx file.

binwalk DI_8002W-16.07.26A1.trx 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
76            0x4C            uImage header, header size: 64 bytes, header CRC: 0x6850C842, created: 2016-08-03 22:52:13, image size: 5612788 bytes, Data Address: 0x80000000, Entry Point: 0x8000C2F0, data CRC: 0xBE8E9338, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "Linux Kernel Image"
140           0x8C            LZMA compressed data, properties: 0x5D, dictionary size: 33554432 bytes, uncompressed size: 8550244 bytes

dd if=DI_8002W-16.07.26A1.trx of=clean.trx bs=1 skip=76

uImage

At this point it appears that I have a valid uImage file, comprising of a linux kernel image and lzma compressed data.

mkimage -l clean.trx 
Image Name:   Linux Kernel Image
Created:      Thu Aug  4 08:52:13 2016
Image Type:   MIPS Linux Kernel Image (lzma compressed)
Data Size:    5612788 Bytes = 5481.24 kB = 5.35 MB
Load Address: 80000000
Entry Point:  8000c2f0

file clean.trx: u-boot legacy uImage, Linux Kernel Image, Linux/MIPS, OS Kernel Image (lzma), 5612788 bytes, Wed Aug 3 22:52:13 2016, Load Address: 0x80000000, Entry Point: 0x8000C2F0, Header CRC: 0x6850C842, Data CRC: 0xBE8E9338

I presume the files / file system is located in the lzma data, so once again I extract this out, removing the header from the file.

dd if=clean.trx of=uboot.lzma skip=64 bs=1

LZMA data

file confirms we have valid LZMA data (at least according to the magic bytes).

file uboot.lzma: LZMA compressed data, non-streamed, size 8550244

I decompress the file with unlzma uboot.lzma and get the following file. This is about as much diagnostic information that I know how to provide.

file uboot: data

mkimage -l uboot 
Image Type:   MVEBU Boot from (null) Image
Image version:0
Data Size:    -4 Bytes = 4194304.00 kB = 4096.00 MB
Load Address: 00000000
Entry Point:  00000000

binwalk uboot 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
3399752       0x33E048        Linux kernel version "2.6.36+ (root@jhl-ubuntu) (gcc version 3.4.2) #2035 Wed Aug 3 18:52:00 EDT 2016"
3587968       0x36BF80        CRC32 polynomial table, little endian
3608048       0x370DF0        Base64 standard index table
3900536       0x3B8478        xz compressed data
3959784       0x3C6BE8        HTML document header
3959845       0x3C6C25        HTML document footer
3962060       0x3C74CC        HTML document header
3962252       0x3C758C        HTML document footer
3962416       0x3C7630        HTML document header
3962785       0x3C77A1        HTML document footer
3986999       0x3CD637        Neighborly text, "neighbor %.2x%.2x.%pM lostde"

I'm looking to transition from this point to discovering / analysing the file system to look for vulnerabilities. Attempting to perform binwalk extraction (i.e binwalk -eM *) is leading to what appears to be a recursing result of the same files being extracted over and over. In other words, an extraction folder with three files are created. Going into this folder and performing binwalk -eM on any of these files will extract exactly the same three files once more.

I'm lost on how we can transition from this point to recovering the file system.

Any thoughts or areas you can suggest I could read up would be greatly appreciated.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.