FreeCalypso > hg > freecalypso-reveng
view pirelli/rfcal @ 214:6b40617d00e6
analysis of ultra-malicious new C123 boot code from Ajay Fuloria
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Tue, 26 Jul 2016 23:32:17 +0000 |
parents | 30ba25056ecd |
children | 2cc7a17c3859 |
line wrap: on
line source
The 64 KiB flash sector at 0x027F0000 (the last sector of the 2nd flash bank) contains per-unit factory data, including the IMEI and RF calibration values. The location of the IMEI record (at offset 0x504) was found back in 2013-07 and its encryption was figured out in 2013-11, but it took a bit longer to find the RF calibration data. But I finally found most of the latter as well. Here they are: Hex offset Corresponding FFS file in TI's canonical version ---------------------------------------------------------------- 06E5 /sys/adccal 0709 checksum byte 072B /gsm/rf/tx/ramps.900 092B checksum byte 092C /gsm/rf/tx/levels.900 09AC checksum byte 09AD /gsm/rf/tx/calchan.900 0A2D checksum byte 0A2E /gsm/rf/tx/ramps.1800 0C2E checksum byte 0C2F /gsm/rf/tx/levels.1800 0CAF checksum byte 0CB0 /gsm/rf/tx/calchan.1800 0D30 checksum byte 0D31 /gsm/rf/tx/ramps.1900 0F31 checksum byte 0F32 /gsm/rf/tx/levels.1900 0FB2 checksum byte 0FB3 /gsm/rf/tx/calchan.1900 1033 checksum byte 10AF /gsm/rf/rx/calchan.900 10D7 checksum byte 10D8 /gsm/rf/rx/agcparams.900 10E0 checksum byte 10E1 /gsm/rf/rx/calchan.1800 1109 checksum byte 110A /gsm/rf/rx/agcparams.1800 1112 checksum byte 1113 /gsm/rf/rx/calchan.1900 113B checksum byte 113C /gsm/rf/rx/agcparams.1900 1144 checksum byte Each calibration record is followed by a checksum byte. It is a simple ripple- carry sum of all bytes in the preceding record. Note that this checksum byte is always 0 for the ramps records, as each correctly-formed ramp adds up to 128 (0x80), and the array has an even number of ramps in total. Unfortunately though, I have not been able to locate these two records: /gsm/rf/afcdac /gsm/rf/afcparams These two files appear in Openmoko's FFS on GTA02 modems, and the byte content differs for each physical unit, so I assume that these values really do need to be calibrated per unit, but I haven't been able to locate them in Pirelli's factory data block. /gsm/rf/afcdac is only 2 bytes long, thus very hard to spot visually in a hex dump of an unknown larger data structure; /gsm/rf/afcparams is 24 bytes long and has some structure to it, so I was hoping to recognize the latter, but no luck. We will have to try running uncalibrated, or perhaps we'll find the code in Pirelli's fw that fills the parts of the T_RF structure that are normally read from these files.