Deciphering phone and embedded security - Part 2: What really happens during an unlock operation

Flashing erases and writes the MCU and PPM portion of the Flash and depending on the flashing method may or may not touch the CNT area but EEPROM is normally not updated. EEPROM also contains the phone's IMEI (International Mobile Equipment Identity) number that is unique to every phone. The IMEI is also contained in OTP memory that is part of application processor, where it is put at the factory and cannot be deleted or changed later, other than replacing the chip that contains it.

Apart from the IMEI number, EEPROM also includes "Lock Data" which is also unique. If someone during the Flashing process erases the IMEI number, the phone will be locked as this parameter is checked and matched with the IMEI number stored in the phone's OTP memory during boot.

Security is further enhanced by some of the Flash ID (FAID as called by some manufacturers) in EEPROM that is tied to the phone's IMEI number, firmware checksum, serial number of Flash chip and could include other parameters. Without matching FAID, the phone will not see the network, reboot every few seconds, and get all locks activated (process may slightly vary based on phone manufacturer). What that really means is even if you swap flash chips between two perfectly good smart phones, neither will work due to FAID mismatch.

One way to make the phone completely immune to unlocking is to store the "lock data"(a.k.a. Flash ID) in OTP memory instead of external EEPROM since data written in OTP memory cannot be changed. However this is not really desirable.

In most countries including the USA, operators like AT&T and Verizon offer phones at subsidized rates (or even free) if the customer purchases a long-term plan with a phone locked to the operator. On the expiry of the term, the customer can get the "unlock code" from the operator if one wishes to switch to a different operator.

In the first few generations of mobile phones, one could easily illegally do this by desoldering the Flash chip and reading it using external flash programmer hardware. Then the hacker could look at the resulting file to retrieve the code. Not anymore. Almost all phones today have at least some portion of the code encrypted, this includes the "unlock code", thus it is not directly readable (this is covered in detail in PART III).

Bypassing Internal bootloader
There are, in most phones, two bootloaders. One is in a small ROM area within the CPU chip. This is the first to start. Some phones don't have it. The other is in the beginning of flash address space. If you kill the flash bootloader, the ROM bootloader can still connect to the PC and let you flash the phone.

If there is no ROM bootloader and you kill the flash bootloader, the only way is to remove the flash chip and program it on an external programmer device. Phones without ROM bootloader usually have on-board contact points for JTAG interface, which allows direct access to flash and CPU busses.

On Power-up, Internal bootloader (as shown Figure 2) is initialized first. It checks if the Flash bootloader is present in the external Flash memory. If there is no Flash bootloader, it attempts to connect and load an external bootloader from system interface (usually without security checks).

When flash bootloader starts, it looks at the system interface again, to check for any attempts to load an external program. Unless the phone is in Factory mode, it will ask for some sort of valid key before it can load the external bootloader. The phone will still boot without a "valid key" but will not provide access to EEPROM (cannot be read or written). The same holds true for Flash ESN (Electronic Serial number) that is not readable in customer mode.

To get access to the complete phone (with no restrictions) it is necessary to enter this "valid key" which is selected randomly by the manufacture at production and encrypted in EEPROM. There could be other similar keys to, for example, to bypass the internal bootloader.

One way to fool or trick the phone is to make the ROM bootloader think that it has an empty flash bootloader (by cutting a PCB track or short-circuiting flash power to ground - via Testpoint). This temporarily disrupts power to the flash chip, allowing ROM bootloader to run an external bootloader on the phone. This bypasses any security checks allowing complete visibility of almost everything including ESN and IMEI, as well as EEPROM and any valid keys. Now you have all you need. One can read and write the entire phone memory, replace security blocks and do pretty much anything, including removing the service provider lock.

The reason one needs the testpoint is that the flash bootloader won't let you download and run anything without a proper digital signature (and this signing uses complex encryption which is not easy to crack). So, it's easier to disable the bootloader than to try and forge the signature for an external bootloader. Unlike older generation phones, the latest phones have this protection and thus need a testpoint to be able to bypass this security. Part III of the series will focus on signed and locked bootloaders.