FreeCalypso > hg > freecalypso-reveng
diff se_k200i/flash-notes @ 393:6c31d8c54ae4
se_k200i: preliminary analysis
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Sun, 06 Nov 2022 01:13:43 +0000 |
parents | |
children | 00f5287db832 |
line wrap: on
line diff
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/se_k200i/flash-notes Sun Nov 06 01:13:43 2022 +0000 @@ -0,0 +1,62 @@ +SE K200 family phones have 16 MiB of flash total, physically presented to the +Calypso chip as two banks of 8 MiB each. Their official fw architecture uses +the following flash organization: + +Flash bank 1, first 64 KiB sector: + +This part of the flash naturally contains the boot entry point. The word at +0x2000 equals 1, telling Calypso boot ROM to move itself out of the way and +perform a watchdog reset, and then the reset entry point is at 0. The code +implemented by SE or their ODM in this flash sector is a boot stage of their +own invention, eventually passing control to the main fw entry point at +0x200000. + +Flash bank 1, 64 KiB sector at 0x10000: + +This sector holds two items of factory-programmed data, apparently intended to +remain immutable for the lifetime of each hw unit: + + 7 bytes at 0x10000: the phone's IMEI, format obvious, no obfuscation + 1 byte at 0x10007: 0xFF filler +64 bytes at 0x10008: appear to be cryptographically random filler + +Flash bank 1 starting at 0x20000: + +The main firmware image resides here, entry point right at 0x200000. + +Flash bank 2, first 13 sectors of 256 KiB each: + +The firmware on this phone model uses classic TIFFS. Their TIFFS organization +is 256x13 (a little smaller than Pirelli's 256x18), sitting at the beginning of +flash bank 2, mapped into Calypso address space at 0x01800000. FFS design +appears to be self-regenerating: if the fw is booted with all FFS sectors +erased, it will not only format a new FFS like Pirelli's fw, but also fill it +with all necessary data. In contrast with Pirelli's fw architecture, the FFS +in these SE K200 phones appears to NOT contain any static asset files that must +be loaded externally. + +Flash bank 2, area starting at 0x01B40000, right after TIFFS: + +This area appears to be an extension of the firmware. Without a lot more +reverse eng work, it is not obvious if this area contains any executable code, +or if it is only data bits like UI pixel images, MIDI ringtones, language +strings etc. + +Flash bank 2, 64 KiB sector at 0x01FD0000: + +This sector holds factory calibration data, including RF, AFC (VCXO) and MADC +calibrations. When the firmware reinitializes a freshly formatted FFS, it must +be copying calibration bits from this sector. + +Flash bank 2, 64 KiB sector at 0x01FF0000 (end of flash): + +First 0x2C8 bytes: purpose unknown, but they are fed into the hash function +that determines whether or not the firmware is allowed to boot. + +8 bytes at 0x01FF02C8: output of some kind of cryptographic hash function + +There is a hash function implemented in the custom bootloader in sector 0 (not +studied in detail) whose inputs are the IMEI record at 0x10000, the block of +0x2C8 bytes at 0x01FF0000 and the block of 64 bytes at 0x10008 in this order. +The output must match the 8 bytes at 0x01FF02C8, or the code refuses to boot +and goes into a dead hang instead.