Support for DIR-320/DIR-600 SquashFS

[GoogleCodeExporter]

Some D-Link routers (at least the DIR-320 and DIR-600) use a modified LZMA 
library in their SquashFS images. These SquashFS images cause the unsquashfs 
tools seg fault:

$ ./firmware-mod-kit/trunk/src/squashfs-2.1-r2/unsquashfs-lzma dir320.squashfs 
Segmentation fault

The issue is that the ZLib.cpp code has been modified to put a "7zip" string 
marker at the beginning of each LZMA block, so the D-Link decompression routine 
looks for that string and skips over it:

//+++ add by siyou ---//
//+++ I add "7zip" id to make kernel can check if use 7zip to decompress. ---//
ZEXTERN int ZEXPORT uncompress OF((Bytef *dest,   uLongf *destLen,
                                   const Bytef *source, uLong sourceLen))
{

    if ( strncmp((char*)source,"7zip",4) == 0 )
    {
       source += 4;
       sourceLen -= 4;
    }
    orig_uncompress(dest,destLen,source,sourceLen);
    return Z_OK;
}

Adding this same logic to the uncompress function in the FMK's ZLib.cpp file 
results in a successful extraction of all the files in the SquashFS image:

$ ./firmware-mod-kit/trunk/src/squashfs-2.1-r2/unsquashfs-lzma dir320.squashfs 

created 825 files
created 56 directories
created 103 symlinks
created 0 devices
created 0 fifos

I've attached a patch file that adds support for these SquashFS images to FMK's 
uncompress function. The DIR-320 source code can be downloaded from: 
http://tsd.dlink.com.tw/temp/download/2991/DIR-320%20v1.00%20GPL.tar.

Original issue reported on code.google.com by heffne...@gmail.com on 7 Aug 2011 at 5:05

Attachments:

• lzma7zip.patch

[GoogleCodeExporter]

Thank you for this contribution. I am going to add you as a contributor so that 
you can commit it yourself, and make any other changes you need to later (if 
any). Sound good to you? ;)

Original comment by jeremy.collake@gmail.com on 7 Aug 2011 at 4:44

[GoogleCodeExporter]

Done. Please let me know of any troubles. You should be able to close this 
ticket after you commit the changes.

Of course, as you know, the #1 rule is always be careful not to break 
compatibility with any other firmware types. I do not have an environment set 
up to automatically regression test every supported device, not to mention this 
would require actually flashing the built images to them to be 100% sure. 
Therefore, always be careful ;).

Your above patch is perfect, does what it needs, doesn't break anything. Great 
;)

Original comment by jeremy.collake@gmail.com on 7 Aug 2011 at 4:50

[GoogleCodeExporter]

Will tread with caution. :)

Patch applied and checked in. Thanks!

Original comment by heffne...@gmail.com on 8 Aug 2011 at 2:01

• Changed state: Fixed

[GoogleCodeExporter]

is it not necessary to add the 7zip strings to the squashfs filesystem when 
rebuilding the modified image? I ask because the router (wbr1310 revD) is not 
accepting my modified image and I haven't yet figured out why, but am trying to 
eliminate this as a possibility. I note the image built with fmk compresses 
better and pads the remaining blocks with 0xffff instead of 0x0000. I could 
probably figure out the code and send a patch, but won't bother if that's not 
likely the issue. thanks.

Original comment by john.com...@gmail.com on 13 Feb 2014 at 6:21