View Single Post
Old 09-26-2012, 03:29 PM   #54
knc1
Helpdesk Junkie
knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.
 
knc1's Avatar
 
Posts: 6,856
Karma: 6314522
Join Date: Feb 2012
Device: Too many.
DX(G) images

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.

Last edited by knc1; 09-26-2012 at 05:51 PM.
knc1 is offline   Reply With Quote