2

Here's a direct link to the firmware referenced:

ftp://ftp2.dlink.com/PRODUCTS/DIR-601/REVB/DIR-601_REVB_FIRMWARE_2.01.ZIP

I'm having trouble extracting the file system from this particular router more specifically by using the dd command to extract the kernel within the firmware binary.

My steps:

I used binwalk dir601_revB_FW_201.bin to find that the lzma in question is located at byte #148 (so fairly early on). I tried to extract this lzma archive by using the following command:

dd if=dir601_revB_FW_201.bin skip=148 bs=1 count=8388608 of=kernel.lzma

Where count is the dictionary size of the archive but to no avail because when I try to unlzma my extracted archive it keeps giving me compressed data is corrupt error.

How to extract and uncompress this archive?

1
  • 1
    Doesn't binwalk itself have an option to extract? Jun 12, 2019 at 21:12

2 Answers 2

2

In my Debian

binwalk -e dir601_revB_FW_201.bin

generates (among others) a file ./_dir601_revB_FW_201.bin.extracted/94. Below is my procedure to get the same file with dd and unlzma, like you tried.


I run your original command and the one from the other answer. In both cases I could do the extraction with 7za (with an error though) but not with sole unlzma. I was able to improve the approach so unlzma works.

First of all your count=8388608 is obviously wrong because dir601_revB_FW_201.bin is smaller. The right number is in the header:

uImage header, header size: 64 bytes, […] image size: 819799 bytes, […]

Your command should have been

dd if=dir601_revB_FW_201.bin skip=148 bs=1 count=819799 of=x.lzma

If I extract 1 byte less, unlzma x.lzma in my Debian will complain with unexpected end of input. If I extract 1 byte more, it will complain with compressed data is corrupt.

The exact number 819799 triggers no complains from the tool, everything works. After this I can binwalk x (as the other answer already noted).

The x file is identical to 94 obtained with binwalk -e (confirmed with cmp).

1
  • Thank you for your help!
    – Sparval
    Jun 12, 2019 at 20:32
0

I suggest you change a bit your dd options. Try it like this:

dd if=dir601_revB_FW_201.bin ibs=1 skip=148 of=x.lzma

Then you can uncompress it with lzma -d x.lzma and if you binwalk x you'll see something like this:

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
77724         0x12F9C         Certificate in DER format (x509 v3), header length: 4, sequence length: 30
1769504       0x1B0020        Linux kernel version 2.6.31
1832080       0x1BF490        CRC32 polynomial table, little endian
2081839       0x1FC42F        Neighborly text, "neighbor %.2x%.2x.%.2x:%.2x:%.2x:%.2x:%.2x:%.2x lost on port %d(%s)(%s)"
5
  • Thank you for your help!
    – Sparval
    Jun 12, 2019 at 20:33
  • Did you use unlzma or another tool? Your command produces exactly the same *.lzma file as the OP's command. If they couldn't proceed in the first place, your answer changes nothing. Jun 12, 2019 at 20:35
  • I used lzma -d. It's basically the standard tool for .lzma files.
    – gmelis
    Jun 13, 2019 at 6:19
  • Apparently your lzma -d (and probably unlzma) does accept archives with trailing garbage. The OP's unlzma doesn't and I guess their lzma -d won't. Jun 13, 2019 at 6:33
  • Well, I use the Debian repository's LZMA command line tool 9.22, if it's of any help. But still, once you have x.lzma you may dd if=x.lzma count=1791 bs=512 of=y.lzma and single out only the lzma archive in file y.lzma.
    – gmelis
    Jun 14, 2019 at 7:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .