comparison 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
comparison
equal deleted inserted replaced
392:35009c936a4a 393:6c31d8c54ae4
1 SE K200 family phones have 16 MiB of flash total, physically presented to the
2 Calypso chip as two banks of 8 MiB each. Their official fw architecture uses
3 the following flash organization:
4
5 Flash bank 1, first 64 KiB sector:
6
7 This part of the flash naturally contains the boot entry point. The word at
8 0x2000 equals 1, telling Calypso boot ROM to move itself out of the way and
9 perform a watchdog reset, and then the reset entry point is at 0. The code
10 implemented by SE or their ODM in this flash sector is a boot stage of their
11 own invention, eventually passing control to the main fw entry point at
12 0x200000.
13
14 Flash bank 1, 64 KiB sector at 0x10000:
15
16 This sector holds two items of factory-programmed data, apparently intended to
17 remain immutable for the lifetime of each hw unit:
18
19 7 bytes at 0x10000: the phone's IMEI, format obvious, no obfuscation
20 1 byte at 0x10007: 0xFF filler
21 64 bytes at 0x10008: appear to be cryptographically random filler
22
23 Flash bank 1 starting at 0x20000:
24
25 The main firmware image resides here, entry point right at 0x200000.
26
27 Flash bank 2, first 13 sectors of 256 KiB each:
28
29 The firmware on this phone model uses classic TIFFS. Their TIFFS organization
30 is 256x13 (a little smaller than Pirelli's 256x18), sitting at the beginning of
31 flash bank 2, mapped into Calypso address space at 0x01800000. FFS design
32 appears to be self-regenerating: if the fw is booted with all FFS sectors
33 erased, it will not only format a new FFS like Pirelli's fw, but also fill it
34 with all necessary data. In contrast with Pirelli's fw architecture, the FFS
35 in these SE K200 phones appears to NOT contain any static asset files that must
36 be loaded externally.
37
38 Flash bank 2, area starting at 0x01B40000, right after TIFFS:
39
40 This area appears to be an extension of the firmware. Without a lot more
41 reverse eng work, it is not obvious if this area contains any executable code,
42 or if it is only data bits like UI pixel images, MIDI ringtones, language
43 strings etc.
44
45 Flash bank 2, 64 KiB sector at 0x01FD0000:
46
47 This sector holds factory calibration data, including RF, AFC (VCXO) and MADC
48 calibrations. When the firmware reinitializes a freshly formatted FFS, it must
49 be copying calibration bits from this sector.
50
51 Flash bank 2, 64 KiB sector at 0x01FF0000 (end of flash):
52
53 First 0x2C8 bytes: purpose unknown, but they are fed into the hash function
54 that determines whether or not the firmware is allowed to boot.
55
56 8 bytes at 0x01FF02C8: output of some kind of cryptographic hash function
57
58 There is a hash function implemented in the custom bootloader in sector 0 (not
59 studied in detail) whose inputs are the IMEI record at 0x10000, the block of
60 0x2C8 bytes at 0x01FF0000 and the block of 64 bytes at 0x10008 in this order.
61 The output must match the 8 bytes at 0x01FF02C8, or the code refuses to boot
62 and goes into a dead hang instead.