The first step in dealing with unknown content binaries:
Code:
core2quad DXBACKUP $ file *
hidden1.bin: x86 boot sector; partition 1: ID=0x83, active, starthead 1, startsector 16, 819248 sectors; partition 2: ID=0x83, starthead 3, startsector 819264, 49152 sectors; partition 3: ID=0x83, starthead 3, startsector 868416, 16384 sectors; partition 4: ID=0xb, starthead 3, startsector 884800, 7020480 sectors, code offset 0x0
hidden2.bin: x86 boot sector; partition 1: ID=0xb, starthead 1, startsector 16, 7020464 sectors, extended partition table (last)\011, code offset 0x0
mtd_0.bin: data
mtd_1.bin: u-boot legacy uImage, s055537-1101131756-TNM0.9~2.6.2, Linux/ARM, OS Kernel Image (Not compressed), 1909000 bytes, Thu Jan 13 20:13:23 2011, Load Address: 0x80008000, Entry Point: 0x80008000, Header CRC: 0x9F3FB4DC, Data CRC: 0x19D80CB2
mtd_2.bin: data
mtd_3.bin: data
mtd_4.bin: u-boot legacy uImage, s055537-1101131756-TNM0.9~2.6.2, Linux/ARM, OS Kernel Image (Not compressed), 1909000 bytes, Thu Jan 13 20:13:23 2011, Load Address: 0x80008000, Entry Point: 0x80008000, Header CRC: 0x9F3FB4DC, Data CRC: 0x19D80CB2
mtd_5.bin: data
mtd_6.bin: ISO-8859 text, with very long lines, with no line terminators
mtd_7.bin: data
mtd_8.bin: data
part1.bin: Linux rev 1.0 ext3 filesystem data, UUID=51146397-cf15-41fc-bd6a-7e94c87cf04b
part2.bin: Linux rev 1.0 ext3 filesystem data, UUID=11e96b35-caa6-47c5-92a6-ecb0ba364606, volume name "LocalVars" (needs journal recovery)
part3.bin: data
core2quad DXBACKUP $
The "file" utility does a "best guess" when it checks a file and it can make mistakes, but that gives some initial direction to further study.
And the "first look" makes it appear that I **did not** have twobob duplicate anything.
To that information, add the file size information:
Code:
core2quad DXBACKUP $ ls -lh
total 441M
-rw-rw-r-- 1 mszick mszick 8.0K 2012-09-14 18:40 hidden1.bin
-rw-rw-r-- 1 mszick mszick 8.0K 2012-09-14 18:59 hidden2.bin
-rw-rw-r-- 1 mszick mszick 128K 2012-09-14 19:03 mtd_0.bin
-rw-rw-r-- 1 mszick mszick 3.5M 2012-09-14 19:04 mtd_1.bin
-rw-rw-r-- 1 mszick mszick 32K 2012-09-14 19:04 mtd_2.bin
-rw-rw-r-- 1 mszick mszick 128K 2012-09-14 19:04 mtd_3.bin
-rw-rw-r-- 1 mszick mszick 3.5M 2012-09-14 19:04 mtd_4.bin
-rw-rw-r-- 1 mszick mszick 64K 2012-09-14 19:04 mtd_5.bin
-rw-rw-r-- 1 mszick mszick 128K 2012-09-14 19:04 mtd_6.bin
-rw-rw-r-- 1 mszick mszick 24K 2012-09-14 19:04 mtd_7.bin
-rw-rw-r-- 1 mszick mszick 64K 2012-09-14 19:04 mtd_8.bin
-rw-rw-r-- 1 mszick mszick 401M 2012-09-14 18:45 part1.bin
-rw-rw-r-- 1 mszick mszick 24M 2012-09-14 18:59 part2.bin
-rw-rw-r-- 1 mszick mszick 8.0M 2012-09-14 18:59 part3.bin
Which seems to have a pattern to it of:
(for mtdblock partitions)
i.RAM binary
U-Boot (or other boot monitor)
Application code
And the kernel must be ... ? ?
Perhaps in the / system image file - more looking required.
Grab the low hanging fruit:
Code:
core2quad DXBACKUP $ sudo mkdir /mnt/part1 /mnt/part2
core2quad DXBACKUP $ sudo mount part1.bin /mnt/part1
core2quad DXBACKUP $ ls /mnt/part1
bin etc linuxrc mnt proc sys tmp var
dev lib lost+found opt sbin test usr
core2quad DXBACKUP $ sudo mount part2.bin /mnt/part2
core2quad DXBACKUP $ ls /mnt/part2
audio eink java log run system wan
Which all looks familiar.
Since the first 8K of the eMMC has a "dos disk label" - now see if the partition descriptions and our eMMC images correspond.
Checking carefully for areas "outside" of those described by the "disk label".
The "dos disk label" in hidden1.bin (from base 0 of the eMMC):
Code:
core2quad DXBACKUP $ fdisk -l hidden1.bin
You must set cylinders.
You can do this from the extra functions menu.
Disk hidden1.bin: 0 MB, 8192 bytes
4 heads, 16 sectors/track, 0 cylinders, total 16 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x489339d6
Device Boot Start End Blocks Id System
hidden1.bin1 * 16 819263 409624 83 Linux
hidden1.bin2 819264 868415 24576 83 Linux
hidden1.bin3 868416 884799 8192 83 Linux
hidden1.bin4 884800 7905279 3510240 b W95 FAT32
Still need to check for "code" or "other data" inside the "MBR area" of hidden1.bin, before the partition table (which is at the end of the 8K block) but nothing too surprising (yet).
Code:
hidden1.bin1 * 16 819263 409624 83 Linux
hidden1.bin2 819264 868415 24576 83 Linux
hidden1.bin3 868416 884799 8192 83 Linux
hidden1.bin4 884800 7905279 3510240 b W95 FAT32
[root@kindle root]# dd if=/dev/mmcblk0p1 of=/mnt/base-us/part1.bin bs=1024
409624+0 records in
409624+0 records out
[root@kindle root]# dd if=/dev/mmcblk0p2 of=/mnt/base-us/part2.bin bs=1024
24576+0 records in
24576+0 records out
[root@kindle root]# dd if=/dev/mmcblk0p3 of=/mnt/base-us/part3.bin bs=1024
8192+0 records in
8192+0 records out
Which looks reasonable.
And (which is needed to re-write the eMMC with U-boot that accepts write addresses) the eMMC storage looks to be mapped one-to-one with the images we made (the intended result).
I.E:
address 0:
hidden1.bin
part1.bin
part2.bin
part3.bin
and then mkdos fat32 on part4 (mmcblk0p4) for the user storage partition.
Still need to find the kernel(s) but they are probably in the mtd device since that is where the U-Boot applications are at.
Wrong, all ready found them, labeled "uimage" in the above.
Also found somebody's serial number and board ID (oops).
Note this image can do both, network load/write flash and network boot,
Or boot from mtd and mount an NFS exported root file system.
In terms of evolution from a manufacturer's development board into a commercial product, this DX image looks still very close to a development board system.
Somebody eyeball the DX(G) U-boot code sources - that will tell more of the story.