How to unpack such a firmware with header ''#SKYVIIA#

Hello Friends

I get a firmware image, wanting to extract it. tried several methods, for example unyaffs, unforunately, get nothing.

root@gpl-vm:/GPL/PX-1531/PX-1532# file PEARL.2011-09-02_12-29-14.fw 
PEARL.2011-09-02_12-29-14.fw: data
root@gpl-vm:/GPL/PX-1531/PX-1532# hexdump -C PEARL.2011-09-02_12-29-14.fw | more
00000000  23 53 4b 59 56 49 49 41  23 53 4b 59 56 49 49 41  |#SKYVIIA#SKYVIIA|
00000010  01 00 00 00 00 02 0b 06  06 12 32 51 b1 0b 03 00  |..........2Q....|
00000020  2f 80 04 30 00 08 00 00  00 00 00 00 08 00 00 30  |/..0...........0|
00000030  00 e0 05 70 00 00 6e 00  1f 10 80 10 11 81 85 70  |...p..n........p|
00000040  10 00 fe 00 1f 11 60 d0  00 00 00 70 00 00 0e 00  |......`....p....|
00000050  3e 01 00 00 00 00 00 00  00 00 00 00 00 00 ff ff  |>...............|
00000060  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

you can see the very first of the output is #SKYVIIA#, I google it, found it stands for a company in Taiwan. here it is http://www.skyviia.com.tw
it is a IC design provider. Are there anyone can help me to unpack this image?
Any ideas will be appreciated.

Tell us what you mean by 'extract'. This is similar to other questions you've posted recently. There is no generic 'unpack' or 'extraction' method for arbitrary lumps of binary data, and it doesn't matter whether the blobs of data came from a ROM, flash media, or an arbitrary file. In order to make some meaningful interpretation of the data, it is necessary to know some context for it. It may be a filesystem image or block device image, binary object code (for some particular CPU), image data in the sense of visual imagery (JPEGs, PNGs, etc), or simply data acquired by a running program.

--- rod.

Originally Posted by theNbomr Tell us what you mean by 'extract'. This is similar to other questions you've posted recently. There is no generic 'unpack' or 'extraction' method for arbitrary lumps of binary data, and it doesn't matter whether the blobs of data came from a ROM, flash media, or an arbitrary file. In order to make some meaningful interpretation of the data, it is necessary to know some context for it. It may be a filesystem image or block device image, binary object code (for some particular CPU), image data in the sense of visual imagery (JPEGs, PNGs, etc), or simply data acquired by a running program. --- rod.

Hi,

You understand me quite well. tell you what, I am doing a kind of service which requires to find out how many parts of GPL software, and find out its corresponding source code. that is GPL auditing or something like verifcation. So, at first, I need to unpack firmware, there are some method I have uesd in other fimware, for example , unyaffs, mount to loop, etc.

Inverse compilation of object code is somewhere between impractical and impossible. I lean toward the impossible end of that spectrum.
Having said that, you may be able to gain some insight to the use of particular source code by finding embedded string data. Typically, compilers don't mangle literal strings in source code, and these can be found in the object code. There are probably invariant signature code segments such as C startup code which could be used to identify the key points within object code. It would take a very large sample of the binary data in order for anyone to locate such signatures. It is not necessarily the case that object code lives at any particular location within a block of non-volatile storage media. There may well be unused gaps within the media, as well a regions of random non-zero data. If any effort has been made to conceal the use of licensed code, it will be even more difficult to reverse engineer.
Inverse compilation is extremely difficult, especially given the huge number of compilers, versions, compilation options, and target architectures that may have produced a given object code module. I hope you're not betting the farm on the success of your venture.

--- rod.

Originally Posted by theNbomr Inverse compilation of object code is somewhere between impractical and impossible. I lean toward the impossible end of that spectrum. Having said that, you may be able to gain some insight to the use of particular source code by finding embedded string data. Typically, compilers don't mangle literal strings in source code, and these can be found in the object code. There are probably invariant signature code segments such as C startup code which could be used to identify the key points within object code. It would take a very large sample of the binary data in order for anyone to locate such signatures. It is not necessarily the case that object code lives at any particular location within a block of non-volatile storage media. There may well be unused gaps within the media, as well a regions of random non-zero data. If any effort has been made to conceal the use of licensed code, it will be even more difficult to reverse engineer. Inverse compilation is extremely difficult, especially given the huge number of compilers, versions, compilation options, and target architectures that may have produced a given object code module. I hope you're not betting the farm on the success of your venture. --- rod.

No, it is not inverse compilation, also it is too difficult for me. I'd better take an example for you, what I should do is to make the firmware image upacked, in other words, I can access to the directory tree which contianed in the firmware. if a folder, let's call it bin, contians ,for example, iwlist/iwconfig/iwcontrol(wireless tool under GPLd) or lib/modules/ contains a xxx.ko (also under GPLd). with those binary modules, I could use strings command to read printable stings , for example, licnese, GPL, GNU General Public License etc to verify whether those modules are compliance with GPL. if yes, I must find their corresponding source code, and If the electronics provider failed to provide the corresponding source code with other people, then they infracts GPL, possible lawsuit will be launched by original developer of those tools (mentioned in previous, wireless tool, for example).

While your data might very well be a block device or filesystem image, it is impossible to tell from the very small sample size. It is very likely not object code, at least the portion you showed. 'Firmware', to me usually suggests a set of subroutines, functions, whatever you want to call them, with some organized method of invoking those routines, such as an entry point where arguments are used to dispatch to the caller's desired service. There is no filesystem involved with such an organization. Assuming that there is a filesystem of any sort in your data may send you on a long dead-end road. What is the nature of the original media that contained the data? That may reveal something about it's structure.

--- rod.

Originally Posted by theNbomr While your data might very well be a block device or filesystem image, it is impossible to tell from the very small sample size. It is very likely not object code, at least the portion you showed. 'Firmware', to me usually suggests a set of subroutines, functions, whatever you want to call them, with some organized method of invoking those routines, such as an entry point where arguments are used to dispatch to the caller's desired service. There is no filesystem involved with such an organization. Assuming that there is a filesystem of any sort in your data may send you on a long dead-end road. What is the nature of the original media that contained the data? That may reveal something about it's structure. --- rod.

hi rod,

Can you see this post and give your advice?

http://www.linuxquestions.org/questi...9/#post4844346

it is related to this one.

Regards