Can't extract dd-wrt firmware for tp-link tl-1043nd

[GoogleCodeExporter]

What steps will reproduce the problem?
1. download firmware 
ftp://ftp.dd-wrt.com/others/eko/BrainSlayer-V24-preSP2/2011/06-14-11-r17201/tpli
nk_tl-wr1043nd/tl-wr1043nd-webflash.bin
2. ./extract_firmware.sh

What is the expected output? What do you see instead?
Attempting raw linux style firmware package (i.e. TEW-632BRP) ...
 Extracting /home/rion/Загрузки/tl-wr1043nd-webflash.bin to /home/rion/temp/firmware/ ...
 Error: filesystem not extracted properly.
  firmware image format not compatible?


What version of the product are you using? On what operating system?
firmware-mod-kit r186

Please provide any additional information below.
It looks like extracted squashfs-3-lzma.img is just piece of some data 
(probably cutted from invalid offset). I tried to search for magic bytes for 
lzma and squashfs in segment1 file but unsuccessfully.
After manual start of command which should extract rootfs i get

Can't find a SQUASHFS superblock on 
/home/rion/temp/firmware/image_parts/squashfs-3-lzma.img

Original issue reported on code.google.com by rion4ik on 23 Aug 2011 at 6:21

[GoogleCodeExporter]

The SquashFS file system is not being properly identified, so the 
squashfs-3-lzma.img file that you have is not actually the squashfs file 
system. Working on fixing this.

In the mean time, the file system is located at offset 936960:

$ binwalk dd-wrt.v24_mini_generic.bin 

DECIMAL     HEX         DESCRIPTION
--------------------------------------------------------------------------------
-----------------------
0           0x0         TRX firmware image, little endian,  image length: 3088384 
bytes, CRC32: 0x9A42E6F4
936960      0xE4C00     Squashfs filesystem, little endian, DD-WRT signature, 
version 3.0, 2149667 bytes, 554 inodes, blocksize: 131072 bytes, created: Fri 
Oct  9 16:30:52 2009

You can dd the file system out of the firmware image manually and then extract 
the contents with unsquashfs-3.0-lzma-damn-small:

$ dd if=dd-wrt.v24_mini_generic.bin bs=936960 skip=1 of=squashfs-3-lzma.img
2+1 records in
2+1 records out
2151424 bytes (2.2 MB) copied, 0.00639221 s, 337 MB/s

$ unsquashfs3.0-lzma-damn-small squashfs-3-lzma.img

created 322 files
created 46 directories
created 186 symlinks
created 0 devices
created 0 fifos

Original comment by heffne...@gmail.com on 27 Aug 2011 at 2:32

• Changed state: Accepted

[GoogleCodeExporter]

Thanks heffnercj .. P.S. (unrelated) I am going to move the docs and the 
version text file used for update checks somewhere you are able to edit this. 
Also, please feel free to put your name on things. Anywhere my name is, slap 
your name along side at your leisure ;).

Original comment by jeremy.collake@gmail.com on 27 Aug 2011 at 3:00

[GoogleCodeExporter]

Will do Jeremy. :)

On a somewhat related note, there seem to be several instances such as this 
where the root file system isn't properly detected by FMK. I've been thinking 
of integrating binwalk (used above) with FMK to possibly provide more 
robust/generic/flexible file system identification. It's essentially a 
recursive file utility with many firmware-specific signatures and filtering 
options.

What are your thoughts on replacing or augmenting the segment identification 
functionality in untrx/splitter3 with binwalk?

Original comment by heffne...@gmail.com on 27 Aug 2011 at 9:00

[GoogleCodeExporter]

Sounds like a good idea to me. untrx and splitter3 were both just tools I 
hacked together to do the job at hand. Replacing them with anything more robust 
is definitely appropriate.

Original comment by jeremy.collake@gmail.com on 27 Aug 2011 at 9:05

[GoogleCodeExporter]

The update check is good I see, referencing this site. I went to do it, then 
saw it had been done. Dunno if you did that, or if I changed it a long time ago 
and forgot about it. Yea, I could look, but ;p. Anyway, OT, but since I 
mentioned here, wanted to say that.

Looking forward to having binwalk in. Many problems have been associated with 
the scripts and custom tools not properly identifying segments or firmware 
types.

Glad to see someone is working on this project again. I'll contribute when I'm 
able, or have inclination, but you have free reign so go for it ;). No need to 
run anything by me, I can see you are a competent developer, so everything is 
at your discretion.

Original comment by jeremy.collake@gmail.com on 28 Aug 2011 at 1:43

[GoogleCodeExporter]

Thanks Jeremy, working on integrating binwalk now. I've been using several of 
the utilities in FMK for some time now and found them very useful, so glad I 
can give back. :)

Original comment by heffne...@gmail.com on 28 Aug 2011 at 4:05

[GoogleCodeExporter]

New extract-ng.sh script properly extracts this firmware image. The firmware 
header for this firmware is not yet supported though, so rebuilding will not 
work.

Original comment by heffne...@gmail.com on 30 Aug 2011 at 12:20

• Changed state: Fixed

[GoogleCodeExporter]

Nice work heffnercj ;). Wonderful addition, brings the FMK to a whole new level.

Original comment by jeremy.collake@gmail.com on 30 Aug 2011 at 12:40