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.