OpenWrt Forum Archive

Topic: extract vmlinux from an lzma-compressed MIPS kernel image

The content of this topic has been archived on 12 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hi All!

subj. Please tell me how would one uncompress an lzma-compressed MIPS kernel image?
I have a firmware image for Draytek VigorFly 200 and it's actually an uboot image with a Linux kernel image inside. I want to uncompress it to have a sure proof of a GPL violation.
This is not directly related to OpenWrt (at the moment at least). But still maybe someone can help me? Is there any easy way without disassembling?

FW image is here: http://news.atg.ru/content/vigorfly200_ … YotaRC2.7z

uboot header states that it contains a Linux kernel image for MIPS with compression method 3 (which I believe to be lzma).

Simple dumb extraction method:

1) find & remember offset of "shsq" magic from vigorfly200_r836_103YotaRC2.all (for me it is 780107)
2) dd if=vigorfly200_r836_103YotaRC2.all of=rootfs.img skip=780107 bs=1
3) compile squashfs-3.2-r2-lzma (you can take it from firmware-mod-kit for example)
4) unsquashfs rootfs.img

Yes, it is GPL violated at most - kernel, busybox, dnsmasq, madwimax, etc. sad

If you know how to write effective complain, please do it.

Thanks, lly, I unpacked it!
Will try to talk to the guys first...

Very interesting, thanks!
Seems, that they splited their own code from madwimax so now GPL is not violated. Good!

@ lly: Can you further explain point (1) please?

PopOpen: In case of you are not familiar with any hex-editor, and even don't know what is "offset" in a file, I can't imagine how to help you. Try to find articles on Internet, read appropriate books, etc.

lly wrote:

PopOpen: In case of you are not familiar with any hex-editor, and even don't know what is "offset" in a file, I can't imagine how to help you. Try to find articles on Internet, read appropriate books, etc.

Hi. I'm very well familiar with both hexeditors and offsets but your line:

"find & remember offset of "shsq" magic from" is not clear.

This is because you don't tell us what is "shsq" and you are not saying anything how to find the offset. BUT I do suspect that what you wanted to say is, that the ASCII equivalent value for the magic number is "shsq" and the Decimal (?) offset from the first byte of the file to the first character of that string is: 780107. ???

So instead of suggesting to people who'd like to help you, to read "appropriate books", you might perhaps read a book yourself on how to write technical English in a more clear manner.

I'm working on a similar problem with the OpenRG based Pirelli firmware here: "Help! To understand, extract and create Pirelli firmware images"...

PopOpen wrote:

This is because you don't tell us what is "shsq" and you are not saying anything how to find the offset. BUT I do suspect that what you wanted to say is, that the ASCII equivalent value for the magic number is "shsq" and the Decimal (?) offset from the first byte of the file to the first character of that string is: 780107. ???

Very good point - I, too, dislike incomplete instructions. Here's my re-write, and my results:

1a) Unpack the vigorfly200_r836_103YotaRC2.7z file

$ 7za x vigorfly200_r836_103YotaRC2.7z

This produces the file "vigorfly200_r836_103YotaRC2.all"
On Linux, the "7za" command is in the "p7zip" package.

1b) Find the decimal value of the location of the string "shsq" in the vigorfly200_r836_103YotaRC2.all file

$ hexdump -C vigorfly200_r836_103YotaRC2.all | grep -m 1 shsq
000be740  ce 3d c5 32 12 7a b3 b7  31 85 7a 73 68 73 71 b8  |Î=Å2.z³·1.zshsq¸|

Thus, the string starts on 0xbe74b

1c) Turn that hex number into a decimal number

$ printf '%d\n' 0xbe74b
780107

Sadly, for me it was Step 4 where I ran into trouble:

$ unsquashfs rootfs.img
Can't find a SQUASHFS superblock on rootfs.img
$ unsquashfs -v
unsquashfs version 4.1 (2010/09/19)
copyright (C) 2010 Phillip Lougher <phillip@lougher.demon.co.uk>
...

Are you using the same dd as above?
What system are you using (ie. Ubuntu, Cygwin etc etc)?
Is "lzma" package included in you system...I think perhaps squashfs need it...

@Xander: Are these the steps you used successfully as well?

UPDATE: I just had success with Pirelli, so have a look here: https://forum.openwrt.org/viewtopic.php … 91#p132491

(Last edited by PopOpen on 8 Apr 2011, 01:42)

PopOpen wrote:

Are you using the same dd as above?
What system are you using (ie. Ubuntu, Cygwin etc etc)?
Is "lzma" package included in you system...I think perhaps squashfs need it...

1. Same "dd"
2. CentOS Linux
3. Yes, unsquashfs has lzma.

However, I've found the problem... it's due to byte-order differences.  I made a sample squashfs file on my Linux host:

$ mksquashfs /tmp ./tmp.sqsh
[i]... much output ...[/]
$ hexdump -C tmp.sqsh | head -1
00000000  68 73 71 73 03 00 00 00  17 56 a3 4d 00 00 02 00  |hsqs.....V£M....|

The Magic Number is reversed! I thought that programs such as unsquashfs could handle that (see Linux File Systems docs), but I guess not.  Anyway, this means that I probably won't have more to add to this discussion. Sorry!

I don't know anything about CentOS, apart being not very common for developers. However, it could be it is a "little endian" based system which may explain the byte reversal...

whbjr wrote:

However, I've found the problem... it's due to byte-order differences.  I made a sample squashfs file on my Linux host:

$ mksquashfs /tmp ./tmp.sqsh
[i]... much output ...[/]
$ hexdump -C tmp.sqsh | head -1
00000000  68 73 71 73 03 00 00 00  17 56 a3 4d 00 00 02 00  |hsqs.....V£M....|

The Magic Number is reversed! I thought that programs such as unsquashfs could handle that (see Linux File Systems docs), but I guess not.  Anyway, this means that I probably won't have more to add to this discussion. Sorry!

Many if not most of the embedded systems that use squashfs are big endian (MSB first).

Also, the unsquashfs tool for x86 is not always backwardly compatible with squash file systems created with earlier versions of mksquashfs.  The incompatibilities are aggravated where the host system is little endian and the file system is big endian.

The version of mksquashfs used to create squashfs for embedded systems is typically version 3.2r-2. In that version, the patch by jro for lzma compression hadn't officially been incorporated into the squashfs codebase.

The answer is to compile the source code for a compatible version of unsquashfs..

This version of unsquashfs from the neufbox 4 project was good for me..

http://svn.gna.org/svn/openbox4/trunk/f … -squashfs/

(Last edited by asbokid on 12 Jul 2011, 23:42)

The discussion might have continued from here.