[About XDA developers] mozsafa:
hw solution

I recently found this box (in a junkpile), utterly obsolete, but good for playing around a bit :).

Open the box and look at the PCB, hold it so the leds face away from you and the SD card socket is to the left.

Just at the right-top corner of the SD card socket you see a missing 4-pin linear connector. Even the outline is drawn on the PCB, only the connector is missing.

Get your soldering iron and add those missing 4 pinheads :), because that is a serial port interface that will come *very* handy.

The pinout from top to bottom is: GND, RxD, TxD, +3.3V. To be sure:

- disconnect the power and check which pin is directly connected to the shielding boxes, that is GND (this shall be the topmost one)

- connect the power and check which of the remaining pins is at <0.1 Volts compared to this GND, that is RxD (this shall be the one just below GND)

- still powered on, check if the other two pins are at 3.3 Volts (they shall be)

- for distinguishing Vcc and TxD you either need an oscilloscope (the one that flickers during power-on is the TxD), or you've got to try both assumptions (there is no risk in it, if you guessed wrong and are expecting data from Vcc, the worst that happens is that you get only silence)

- so trust me: Vcc is the bottom-most pin and TxD is the one above it

Now you'll need a 3.3V-TTL-to-RS232 converter. You may buy one for about 20 bucks, but that's just cheating :), so go buy a MAX3232 chip for $2 and build it yourself. (There is no flow-control on this device, so don't forget to hardwire the RTS-CTS and DSR-DTR loopbacks on your converter.)

So you got the converter, plugged it between your computer and the unit. Start a serial terminal (I prefer minicom, but nothing special is needed, any will do), and configure the comm settings: 115200 baud, 8 data bits, no parity, 1 stop bit, no hardware flowcontrol, no software flowcontrol.

The moment of truth: power on the unit! You shall see something like this:

+---------------------------------------------------+

| Mboot for android system |

| Ver:1.12 Build date:Jun 20 2011 |

| Mboot write by mesada corporation |

copy: bad source 0

mout_audss: bad source 0

vic_pm_register: too few VICs, increase CONFIG_ARM_VIC_NR

vic_pm_register: too few VICs, increase CONFIG_ARM_VIC_NR

no memory for fimc0

init: cannot open '/initlogo.rle'

init: cannot find '/system/etc/install-recovery.sh', disabling 'flash_recovery'

sh: can't access tty; job control turned off

#

Yes, that is just a root prompt :) !

# ls -l /init.rc

-rwxr-x--- root root 15810 1970-01-01 00:00 init.rc

# busybox grep -v '^$' /init.rc | busybox sed -n '1,10p'

on init

sysclktz 0

loglevel 3

# setup the global environment

export PATH /sbin:/system/sbin:/system/bin:/system/xbin

export LD_LIBRARY_PATH /system/lib

export ANDROID_BOOTLOGO 1

export ANDROID_ROOT /system

export ANDROID_ASSETS /system/app

export ANDROID_DATA /data

Now you are free to roam around in /data and /system and /mnt/flash :)!

Certainly, the root filesystem you see is just an in-memory copy of an initrd-image, so if you change (for example) /init.rc, it will be lost on the next reboot.

The internal flash is visible as /dev/block/mmcblk0 (and its partitions as mmcblk0p1..mmcblk0p4), so if you attach a >2GB flash disk (it will appear as /dev/block/sda), you may copy it for analysing in a more comfortable environment:

# dd if=/dev/block/mmcblk0 of=/dev/sda bs=2M

(This will need a lot of time, so remember: patience is virtue :)...)

The structure of this mmcblk0 is (unit=sectors of 512 bytes):

[ 0 .. 22428) bootloader+kernel+initrd

[ 22428 .. 291564) p2 (/system), ext2, ro, 66M used, 88M total

[ 291564 .. 295302) unused, 3738 sectors

[ 295302 .. 564438) p3 (/system/app), ext2, ro, 46M used, 66M total

[ 564438 .. 568176) unused, 3738 sectors

[ 568176 .. 2209158) p4 (/data), ext3, rw, 93M used, 795M total

[2209158 .. 2212896) unused, 3738 sectors

[2212896 .. 3823973) p1 (/mnt/flash) vfat, rw, 0M used, 804M total

As you see, there is a ~11MByte boot image at the beginning that belongs to neither partition. Its 0xaf3800 bytes (512*22428) contains this:

[ 0x0 .. 0x0cf4) stage0

[ 0x2200 .. 0x020ffc) stage1

[0x042200 .. 0x042254) ?some config?

[0x344200 .. 0x344240) some header for the kernel

[0x344240 .. 0x636c90 .. 0x636e00) kernel

[0x844200 .. 0x844240) some header for the initrd image

[0x844240 .. 0x98127d .. 0x981400) initrd image

The initrd image is a gzip-compressed cpio file, so it starts with the usual gzip header: 1F 8B 08.

(In fact, it is the second gzip header in the boot image, because the kernel also consist of a small loader + a big gzip-compressed part.)

Save the initrd image to a file 'initrd.cpio.gz', create a new directory and unpack it:

$ gzip -dc ../initrd.cpio.gz | cpio -i

gzip: ../initrd.cpio.gz: decompression OK, trailing garbage ignored

6731 blocks

$ ls -lns

total 164

4 drwxrwx--x 2 1000 1000 4096 Jul 26 18:58 data

4 -rw-r--r-- 1 1000 1000 172 Jul 26 18:58 default.prop

4 drwxr-xr-x 2 1000 1000 4096 Jul 26 18:58 dev

108 -rwxr-x--- 1 1000 1000 107960 Jul 26 18:58 init

4 -rwxr-x--- 1 1000 1000 1677 Jul 26 18:58 init.goldfish.rc

16 -rwxr-x--- 1 1000 1000 15810 Jul 26 18:58 init.rc

4 -rwxr-x--- 1 1000 1000 379 Jul 26 18:58 init.smdkv210.rc

4 drwxr-xr-x 2 1000 1000 4096 Jul 26 18:58 modules

4 drwxr-xr-x 2 1000 1000 4096 Jul 26 18:58 proc

4 drwxr-x--- 2 1000 1000 4096 Jul 26 18:58 sbin

4 drwxr-xr-x 2 1000 1000 4096 Jul 26 18:58 sys

4 drwxr-xr-x 2 1000 1000 4096 Jul 26 18:58 system

So, that's indeed the image from where the root filesystem is decompressed :).

Please note that those 0x40 byte header before the initrd image may very well contain a checksum as well, so just overwriting the image with a modified one may not be the brightest idea...

This is how far I got until now, so I still need to find answers for some questions:

- Isn't it possible, by any chance, that the boot loader checks the external sd card as well and if it matches some constraints, boots from that instead of the internal one?

- Where are the location of the kernel and the initrd stored? (Suspect: [0x042200 .. 0x042254) ?some config?)

- What do the headers contain (that '?some config?' and the ones before the kernel and the initrd) ?

- Where does the address of that '?some config?' come from?

- Is it possible to trigger some 'recovery' image (just in case I botch the kernel, for example) to gain access to the flash?

So I still have a lot of interesting things to find out :), I'll write a follow-up as soon as I have results.