Multiple string tables in ELF object - binary

From ELF Documentation:
SHT_STRTAB
The section holds a string table. An object file may have multiple string table sections. See ‘‘String Table’’ below for details.
(Note: I didn't notice any information regarding multiple string table sections in ‘‘String Table’’ paragraph)
Does multiple string table sections mean string table for the section headers and string table for the object file itself?
There is no mention in the documentation regarding how to read a string if there are multiple string table for the object itself (.strtab).
Any clarification about the subject appreciated.

The manpage only has a overview/summary of (some parts of) the ELF file format, you might want to look at the System V ABI spec.
Explanation
Linking view
An ELF file has multiple string tables. Usually you have 3-4 string tables:
One string table (usually called .shstrtab) is used for section names. All section names (in the section header table) are taken from a single string table. This string table is identified by its index in the section header table: the index of the section name string table is indicated in the ELF header (e_shstrndx).
Another string table (usually called .strtab) is used for the full symbol table (.symtab). The same string table is used by the .dynamic section.
Another string table (usually called .dynstr) is used for the minirmal symbol table (.dynsym).
Another string table is used for
For a given symbol table section, the section used as string table is indicated in the sh_link field of the section header table (see Fig 4-12 of the system V ABI spec).
Execution view
For the execution view (the program header table), the address of the string table used for the symbol table (DT_SYMTAB) is given in the DT_STRTAB entry of the dynamic section.
Example
Linking view
This is a hello world program (shown with readelf -a).
.shtrtab
The ELF header:
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x4003c0
Start of program headers: 64 (bytes into file)
Start of section headers: 4624 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 8
Size of section headers: 64 (bytes)
Number of section headers: 30
Section header string table index: 27
tells us that the section names are in section 27. Conveniently enough this is .shtrtab:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[...]
[27] .shstrtab STRTAB 0000000000000000 000008e0
0000000000000108 0000000000000000 0 0 1
.dynstr
For .dynsym we have:
[ 5] .dynsym DYNSYM 0000000000400280 00000280
0000000000000048 0000000000000018 A 6 1 8
^
HERE
Its names are taken from section 6 which is .dynstr:
[ 6] .dynstr STRTAB 00000000004002c8 000002c8
0000000000000038 0000000000000000 A 0 0 1
This string table is used by other sections as well:
[ 8] .gnu.version_r VERNEED 0000000000400308 00000308
0000000000000020 0000000000000000 A 6 1 8
[21] .dynamic DYNAMIC 0000000000600698 00000698
00000000000001d0 0000000000000010 WA 6 0 8
.strtab
For .symtab:
[28] .symtab SYMTAB 0000000000000000 000009e8
0000000000000600 0000000000000018 29 45 8
^
HERE
the names are taken from section 29 which happens to be .strtab:
[29] .strtab STRTAB 0000000000000000 00000fe8
0000000000000224 0000000000000000 0 0 1
Execution view
Dynamic section at offset 0x698 contains 24 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x000000000000000c (INIT) 0x400370
0x000000000000000d (FINI) 0x400544
0x0000000000000019 (INIT_ARRAY) 0x600680
0x000000000000001b (INIT_ARRAYSZ) 8 (bytes)
0x000000000000001a (FINI_ARRAY) 0x600688
0x000000000000001c (FINI_ARRAYSZ) 8 (bytes)
0x000000006ffffef5 (GNU_HASH) 0x400260
0x0000000000000005 (STRTAB) 0x4002c8 <= HERE
0x0000000000000006 (SYMTAB) 0x400280
0x000000000000000a (STRSZ) 56 (bytes)
0x000000000000000b (SYMENT) 24 (bytes)
0x0000000000000015 (DEBUG) 0x0
0x0000000000000003 (PLTGOT) 0x600870
0x0000000000000002 (PLTRELSZ) 48 (bytes)
0x0000000000000014 (PLTREL) RELA
0x0000000000000017 (JMPREL) 0x400340
0x0000000000000007 (RELA) 0x400328
0x0000000000000008 (RELASZ) 24 (bytes)
0x0000000000000009 (RELAENT) 24 (bytes)
0x000000006ffffffe (VERNEED) 0x400308
0x000000006fffffff (VERNEEDNUM) 1
0x000000006ffffff0 (VERSYM) 0x400300
0x0000000000000000 (NULL) 0x0
The string table for dynamic linking is located at 0x4002c8 in the program memory.
Note: this is .dynstr.

Related

How to determine what is being relocated using readelf

From the snippet below, I can see that the relocation entry is to be applied at offset 0x000000201018 of some section, but how can I determine what section?
Also all of my sections are smaller than this offset. What are the implications of this?
Relocations:
Relocation section '.rela.plt' at offset 0x4f8 contains 1 entries:
Offset Info Type Sym. Value Sym. Name + Addend
000000201018 000300000007 R_X86_64_JUMP_SLO 0000000000000000 printk + 0
Section Headers:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
...
[ 6] .rela.plt RELA 00000000000004f8 000004f8
0000000000000018 0000000000000018 AI 3 21 8
...
[21] .got.plt PROGBITS 0000000000201000 00001000
0000000000000020 0000000000000008 WA 0 0 8
The section to which the relocation is applied is specified in the info field of the section headers. From the example elf in the question, the relocation section .rela.plt applies to section number 21, the .got.plt section.
The offset field has different meaning for object file and shared object file. "For a relocatable file, the value is the byte offset from the beginning of the section to the storage unit affected by the relocation. For an executable file or a shared object, the value is the virtual address of the storage unit affected by the relocation."
Source/More Info: http://www.skyfree.org/linux/references/ELF_Format.pdf

Decoding a hex file

I would like to use a webservice who deliver a binary file with some data, I know the result but I don't know how I can decode this binary with a script.
Here is my binary :
https://pastebin.com/3vnM8CVk
0a39 0a06 3939 3831 3438 1206 4467 616d
6178 1a0b 6361 7264 6963 6f6e 5f33 3222
0d54 6865 204f 6c64 2047 7561 7264 2a02
....
Some part are in ASCII so it easy to catch, at the end of the file you got vehicle name in ASCII and some data, it should be kill/victory/battle/XP/Money data but I don't understand how I can decode these hexa value, I tried to compare 2 vehicles who got same kills but I don't see any match.
There is a way to decode these data ?
Thanks :)
Hello guys, after 1 year I started again to find a solution, so here is the structure of the packet I guessed : (the part between [ ] I still don't know what is it for)
[52 37 08 01 10] 4E [18] EA [01 25] AB AA AA 3E [28] D4 [01 30] EC [01 38] 88 01 [40] 91 05 [48] 9F CA 22 [50] F5 C2 9A 02 [5A 12]
| | | | | | | | |
Victories Victory Ratio| | Air target| Xp Money earned
| | | Ground Target
Battles Deaths Respawns
So here is the result :
Victory : 78
Battles : 234
Victory Ratio : ? (should be arround 33%)
Deaths : 212
Respawns : 236
Air Target : 136
Ground Target : 657
Xp : ? (should be arround 566.56k)
Money : ? (should be arround 4.63M)
Is there a special way to calculate the result of a long hex like this ?
F5 C2 9A 02 (should be arround 4.63M)
I tell you a bit more :
I know the result, but I don't know how to calculate it with these hex from the packet.
If I check a packet with a small amout of money or XP to be compatible with one hex :
[52 1E 08 01 10] 01 [18] [01 25] 00 00 80 3F [28] 01 [30] 01 [48] 24 [50] 6E [5A 09]
6E = 110 Money earned
24 = 36 XP earned
Another exemple :
[52 21 08 01 10] 02 [18] 03 [25] AB AA 2A 3F [28] 02 [30] 03 [40] 01 [48] 78 [50] C7 08 [5A 09]
XP earned = hex 78 = 120
Money earned = hex C7 08 = 705
How C7 08 can do 705 decimal ?
Here is the full content in case but I know how to isolate just these part I don't need to decode all these hex data :
https://pastebin.com/vAKPynNb
What you have asked is nothing but how to reverse engineer a binary file. Lot of threads already on SO
Reverse engineer a binary dictionary file to extract strings
Tools to help reverse engineer binary file formats
https://reverseengineering.stackexchange.com/questions/3495/what-tools-exist-for-excavating-data-structures-from-flat-binary-files
http://www.iwriteiam.nl/Ha_HTCABFF.html
The final take out on all is that no single solution for you, you need to spend effort to figure it out. There are tools to help you, but don't expect a magic wand tool to give you the structure/data.
Any kind of file read operation is done in text or binary format with basic file handlers. And some languages offer type reading of int, float etc. or arrays of them.
The complex operations behind these reading are almost always kept hidden from normal users. And then the user has to learn more when it comes to read/write operations of data structures.
In this case, OFFSET and SEEK are the words one must find value and act accordingly. whence data read, it must be converted to suitable data type too.
The following code shows basics for these operations to write data and read blocks to get numbers back. It is written in PHP as the OP has commented in the question he uses PHP.
Offset is calculated with these byte values to be 11: char: 1 byte, short: 2 bytes, int: 4 bytes, float: 4 bytes.
<?php
$filename = "testdata.dat";
$filehandle = fopen($filename, "w+");
$data=["test string","another test string",77,777,77777,7.77];
fwrite($filehandle,$data[0]);
fwrite($filehandle,$data[1]);
$numbers=array_slice($data,2);
fwrite($filehandle,pack("c1s1i1f1",...$numbers));
fwrite($filehandle,"end"); // gives 3 to offset
fclose($filehandle);
$filename = "testdata.dat";
$filehandle = fopen($filename, "rb+");
$offset=filesize($filename)-11-3;
fseek($filehandle,$offset);
$numberblock= fread($filehandle,11);
$numbersback=unpack("c1a/s1b/i1c/f1d",$numberblock);
var_dump($numbersback);
fclose($filehandle);
?>
Once this example understood, the rest is to find the data structure in the requested file. I had written another example but it uses assumptions. I leave the rest to readers to find what assumptions I made here. Be careful though: I know nothing about real structure and values will not be correct.
<?php
$filename = "testfile";
$filehandle = fopen($filename, "rb");
$offset=17827-2*41; //filesize minus 2 user area
fseek($filehandle,$offset);
print $user1 = fread($filehandle, 41);echo "<br>";
$user1pr=unpack("s1kill/s1victory/s1battle/s1XP/s1Money/f1Life",$user1);
var_dump($user1pr); echo "<br>";
fseek($filehandle,$offset+41);
print $user2 = fread($filehandle, 41);echo "<br>";
$user2pr=unpack("s1kill/s1victory/s1battle/i1XP/i1Money/f1Life",$user2);
var_dump($user2pr); echo "<br>";
echo "<br><br>";
$repackeduser2=pack("s3i2f1",$user2pr["kill"],$user2pr["victory"],
$user2pr["battle"],$user2pr["XP"],$user2pr["Money"],
$user2pr["Life"]
);
print $user2 . "<br>" .$repackeduser2;
print "<br>3*s1=6bytes, 2*i=6bytes, 1*f=*bytes (machine dependent)<br>";
print pack("s1",$user2pr["kill"]) ."<br>";
print pack("s1",$user2pr["victory"]) ."<br>";
print pack("s1",$user2pr["battle"]) ."<br>";
print pack("i1",$user2pr["XP"]) ."<br>";
print pack("i1",$user2pr["Money"]) ."<br>";
print pack("f1",$user2pr["Life"]) ."<br>";
fclose($filehandle);
?>
PS: pack and unpack uses machine dependent size for some data types such as int and float, so be careful with working them. Read Official PHP:pack and PHP:unpack manuals.
This looks more like the hexdump of a binary file. Some methods of converting hex to strings resulted in the same scrambled output. Only some lines are readable like this...
Dgamaxcardicon_32" The Old Guard
As #Tarun Lalwani said, you would have to know the structure of this data to get the in plaintext.
If you have access to the raw binary, you could try using strings https://serverfault.com/questions/51477/linux-command-to-find-strings-in-binary-or-non-ascii-file

rjson::fromJSON returns only the first item

I have a sqlite database file with several columns. One of the columns has a JSON dictionary (with two keys) embedded in it. I want to extract the JSON column to a data frame in R that shows each key in a separate column.
I tried rjson::fromJSON, but it reads only the first item. Is there a trick that I'm missing?
Here's an example that mimics my problem:
> eg <- as.vector(c("{\"3x\": 20, \"6y\": 23}", "{\"3x\": 60, \"6y\": 50}"))
> fromJSON(eg)
$3x
[1] 20
$6y
[1] 23
The desired output is something like:
# a data frame for both variables
3x 6y
1 20 23
2 60 50
or,
# a data frame for each variable
3x
1 20
2 60
6y
1 23
2 50
What you are looking for is actually a combination of lapply and some application of rbind or related.
I'll extend your data a little, just to have more than 2 elements.
eg <- c("{\"3x\": 20, \"6y\": 23}",
"{\"3x\": 60, \"6y\": 50}",
"{\"3x\": 99, \"6y\": 72}")
library(jsonlite)
Using base R, we can do
do.call(rbind.data.frame, lapply(eg, fromJSON))
# X3x X6y
# 1 20 23
# 2 60 50
# 3 99 72
You might be tempted to do something like Reduce(rbind, lapply(eg, fromJSON)), but the notable difference is that in the Reduce model, rbind is called "N-1" times, where "N" is the number of elements in eg; this results in a LOT of copying of data, and though it might work alright with small "N", it scales horribly. With the do.call option, rbind is called exactly once.
Notice that the column labels have been R-ized, since data.frame column names should not start with numbers. (It is possible, but generally discouraged.)
If you're confident that all substrings will have exactly the same elements, then you may be good here. If there's a chance that there will be a difference at some point, perhaps
eg <- c(eg, "{\"3x\": 99}")
then you'll notice that the base R solution no longer works by default.
do.call(rbind.data.frame, lapply(eg, fromJSON))
# Error in (function (..., deparse.level = 1, make.row.names = TRUE, stringsAsFactors = default.stringsAsFactors()) :
# numbers of columns of arguments do not match
There may be techniques to try to normalize the elements such that you can be assured of matches. However, if you're not averse to a tidyverse package:
library(dplyr)
eg2 <- bind_rows(lapply(eg, fromJSON))
eg2
# # A tibble: 4 × 2
# `3x` `6y`
# <int> <int>
# 1 20 23
# 2 60 50
# 3 99 72
# 4 99 NA
though you cannot call it as directly with the dollar-method, you can still use [[ or backticks.
eg2$3x
# Error: unexpected numeric constant in "eg2$3"
eg2[["3x"]]
# [1] 20 60 99 99
eg2$`3x`
# [1] 20 60 99 99

Reading index content, possible?

Is there a way to analyze the contents of a specific index (fdb file)? I know I can see the index creation statement and try to guess from there but it would be nice if there is a way to see the contents/records inside an fdb file.
two tools cbindex and forestdb_dump can help. These are available in the bin folder along with other couchbase binaries. Note that, these tools are not supported, as documented at http://developer.couchbase.com/documentation/server/4.5/release-notes/relnotes-40-ga.html
given bucket/indexname, tool cbindex gets index level details:
couchbases-MacBook-Pro:bin varakurprasad$ pwd
/Users/varakurprasad/Downloads/couchbase-server-enterprise_451_GA/Couchbase Server.app/Contents/Resources/couchbase-core/bin
couchbases-MacBook-Pro:bin varakurprasad$ ./cbindex -server 127.0.0.1:8091 -type scanAll -bucket travel-sample -limit 4 -index def_type -auth Administrator:couch1
ScanAll index:
[airline] ... airline_10
[airline] ... airline_10123
[airline] ... airline_10226
[airline] ... airline_10642
Total number of entries: 4
Given a forestdb file, the tool forestdb_dump gets more low level details:
couchbases-MacBook-Pro:varakurprasad$ pwd
/Users/varakurprasad/Library/Application Support/Couchbase/var/lib/couchbase/data/#2i/travel-sample_def_type_1018858748122363634_0.index
couchbases-MacBook-Pro:varakurprasad$ forestdb_dump data.fdb.53 | more
[FDB INFO] Forestdb opened database file data.fdb.53
DB header info:
BID: 1568 (0x620, byte offset: 6422528)
DB header length: 237 bytes
DB header revision number: 3
...
Doc ID: airline_10
KV store name: back
Sequence number: 14637
Byte offset: 2063122
Indexed by the main index
Length: 10 (key), 0 (metadata), 24 (body)
Status: normal
Metadata: (null)
Body:^Fairline
...

Binwalk - Compressed data is corrupt

root#kali:~/ROUTER# binwalk new-firmware.bin
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
84 0x54 uImage header, header size: 64 bytes, header CRC: 0xE52A7F50, created: 2012-02-10 07:27:12, image size: 819799 bytes, Data Address: 0x80002000, Entry Point: 0x801AC9F0, data CRC: 0x6A10D412, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "Linux Kernel Image"
148 0x94 LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 2386252 bytes
917588 0xE0054 Squashfs filesystem, little endian, version 4.0, compression:lzma, size: 2588426 bytes, 375 inodes, blocksize: 16384 bytes, created: 2016-02-05 02:05:56
root#kali:~/ROUTER# dd if=new-firmware.bin of=uboot.lzma skip=148 bs=1
3735488+0 records in
3735488+0 records out
3735488 bytes (3.7 MB, 3.6 MiB) copied, 4.16712 s, 896 kB/s
root#kali:~/ROUTER# dd if=new-firmware.bin of=kernel.squash skip=917588 bs=1
2818048+0 records in
2818048+0 records out
2818048 bytes (2.8 MB, 2.7 MiB) copied, 3.46517 s, 813 kB/s
All looks to have worked so far but then I try the following:
root#kali:~/ROUTER# lzma -d uboot.lzma
lzma: uboot.lzma: Compressed data is corrupt
root#kali:~/ROUTER# unsquashfs kernel.squash
Parallel unsquashfs: Using 4 processors
lzma uncompress failed with error code 0
read_block: failed to read block #0x277af0
read_fragment_table: failed to read fragment table index
FATAL ERROR:failed to read fragment table
Any idea why it may be happening? As the prompt says, I am on Kali Linux. ALso get this
jj#ubuntu:~/Firmware$ binwalk -e new-firmware.bin
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
84 0x54 uImage header, header size: 64 bytes, header CRC: 0xE52A7F50, created: 2012-02-10 07:27:12, image size: 819799 bytes, Data Address: 0x80002000, Entry Point: 0x801AC9F0, data CRC: 0x6A10D412, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "Linux Kernel Image"
148 0x94 LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 2386252 bytes
WARNING: Extractor.execute failed to run external extractor 'sasquatch -p 1 -le -d '%%squashfs-root%%' '%e'': [Errno 2] No such file or directory
WARNING: Extractor.execute failed to run external extractor 'sasquatch -p 1 -be -d '%%squashfs-root%%' '%e'': [Errno 2] No such file or directory
917588 0xE0054 Squashfs filesystem, little endian, version 4.0, compression:lzma, size: 2588426 bytes, 375 inodes, blocksize: 16384 bytes, created: 2016-02-05 02:05:56
Try
lzma -d < uboot.lzma > uboot
The error you found is due to LZMA Utils having been superseded by XV Utils, which don't ignore the trailing garbage. If you use it as a stream (like I gave you), you'll still have the corruption error message in the end, but you'll get your file alright.
Source (search for "corrupt" and you'll find other related comments)
Try
binwalk -e new-firmware.bin
you will end up with 2 file one being extracted
In the extracted one you will get 2 one unzippped and a zipped one
you can use dd at this point and unlzma should work at least it did work out for me
this is what i mean
root#ROOT20:~/Desktop/project/dlink/dlink2# binwalk dcs932l_v1.14.04.bin
DECIMAL HEXADECIMAL DESCRIPTION
106352 0x19F70 U-Boot version string, "U-Boot 1.1.3"
106816 0x1A140 CRC32 polynomial table, little endian
124544 0x1E680 HTML document header
124890 0x1E7DA HTML document footer
124900 0x1E7E4 HTML document header
125092 0x1E8A4 HTML document footer
125260 0x1E94C HTML document header
125953 0x1EC01 HTML document footer
327680 0x50000 uImage header, header size: 64 bytes, header CRC: 0x88345E96, created: 2016-09-09 13:52:27, image size: 3804958 bytes, Data Address: 0x80000000, Entry Point: 0x803B8000, data CRC: 0x531E94DE, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "Linux Kernel Image"
327744 0x50040 LZMA compressed data, properties: 0x5D, dictionary size: 33554432 bytes, uncompressed size: 6558763 bytes
root#ROOT20:~/Desktop/project/dlink/dlink2# dd if=dcs932l_v1.14.04.bin skip=327744 bs=1 of=kernel.lzma
3866560+0 records in
3866560+0 records out
3866560 bytes (3.9 MB, 3.7 MiB) copied, 9.61104 s, 402 kB/s
root#ROOT20:~/Desktop/project/dlink/dlink2# unlzma kernel.lzma
unlzma: kernel.lzma: Compressed data is corrupt
root#ROOT20:~/Desktop/project/dlink/dlink2# binwalk -e dcs932l_v1.14.04.bin
DECIMAL HEXADECIMAL DESCRIPTION
106352 0x19F70 U-Boot version string, "U-Boot 1.1.3"
106816 0x1A140 CRC32 polynomial table, little endian
124544 0x1E680 HTML document header
124890 0x1E7DA HTML document footer
124900 0x1E7E4 HTML document header
125092 0x1E8A4 HTML document footer
125260 0x1E94C HTML document header
125953 0x1EC01 HTML document footer
327680 0x50000 uImage header, header size: 64 bytes, header CRC: 0x88345E96, created: 2016-09-09 13:52:27, image size: 3804958 bytes, Data Address: 0x80000000, Entry Point: 0x803B8000, data CRC: 0x531E94DE, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "Linux Kernel Image"
327744 0x50040 LZMA compressed data, properties: 0x5D, dictionary size: 33554432 bytes, uncompressed size: 6558763 bytes
root#ROOT20:~/Desktop/project/dlink/dlink2# ls
dcs932l_v1.14.04.bin _dcs932l_v1.14.04.bin.extracted kernel.lzma
root#ROOT20:~/Desktop/project/dlink/dlink2# cd _dcs932l_v1.14.04.bin.extracted/
root#ROOT20:~/Desktop/project/dlink/dlink2/_dcs932l_v1.14.04.bin.extracted# ls
50040 50040.7z
root#ROOT20:~/Desktop/project/dlink/dlink2/_dcs932l_v1.14.04.bin.extracted# binwalk 50040
DECIMAL HEXADECIMAL DESCRIPTION
3145804 0x30004C Linux kernel version 2.6.21
3175792 0x307570 SHA256 hash constants, little endian
3389960 0x33BA08 Unix path: /usr/gnemul/irix/
3392244 0x33C2F4 Unix path: /usr/lib/libc.so.1
3393940 0x33C994 Unix path: /dev/vc/0
3408260 0x340184 Copyright string: "Copyright (c) 2010 Alpha Networks Inc."
3491536 0x3546D0 Unix path: /etc/Wireless/RT2860STA/RT2860STA.dat
3573187 0x3685C3 Neighborly text, "neighbor %.2x%.2x.%.2x:%.2x:%.2x:%.2x:%.2x:%.2x lost on port %d(%s)(%s)"
3807776 0x3A1A20 CRC32 polynomial table, little endian
4038656 0x3DA000 LZMA compressed data, properties: 0x5D, dictionary size: 1048576 bytes, uncompressed size: 8072704 bytes
root#ROOT20:~/Desktop/project/dlink/dlink2/_dcs932l_v1.14.04.bin.extracted# dd if=50040 skip=4038656 bs=1 of=kernel2.lzma
2520107+0 records in
2520107+0 records out
2520107 bytes (2.5 MB, 2.4 MiB) copied, 8.23342 s, 306 kB/s
root#ROOT20:~/Desktop/project/dlink/dlink2/_dcs932l_v1.14.04.bin.extracted# unlzma kernel2.lzma
root#ROOT20:~/Desktop/project/dlink/dlink2/_dcs932l_v1.14.04.bin.extracted#
root#ROOT20:~/Desktop/project/dlink/dlink2/_dcs932l_v1.14.04.bin.extracted# mkdir cpio; cd cpio
root#ROOT20:~/Desktop/project/dlink/dlink2/_dcs932l_v1.14.04.bin.extracted/cpio# cpio -idm --no-absolute-filenames < ../kernel2
cpio: Removing leading `/' from member names
15767 blocks
root#ROOT20:~/Desktop/project/dlink/dlink2/_dcs932l_v1.14.04.bin.extracted/cpio# ls
bin dev etc etc_ro home init lib media mnt mydlink proc sbin sys tmp usr var