OMAPBootrom¶

Generic documentation¶

• check the various SOCs the sram size limit in the TRM.
• check the load address / memory mapping of MLO in case of USB boot or boot from eMMC in the TRM.
• Check mmc1 booting constraint (card size, look if < 4GiB works) in the TRM

• Read the TRM sections about SYS_BOOT and booting and document that, ideally write a tool for it, or upstream the code in some other tool.

Documentation¶

The droiddevelopers website has some information on trying to use bugs run free software on several Motorola devices.

• It has documentation on the structure of signed MLOs

• Read droiddevelopers more to understand restricted boot better.
• Also the OMAP wiki might have some information on OMAP restricted boot.
• Also look if there is substancial information in the Technical Reference Manual (TRM) about fuses but that's unlikely.
• Learn more about the following (from #replicant on Freenode):
  

  sensiblemn: https://web.archive.org/web/20130613110712/http://gitorious.org/x-loader/x-loader/blobs/master/README
  sensiblemn: "X-Loader can be signed by Texas Instruments IFT and installed to Nand flash to achieve Nand booting." 
  sensiblemn: [...] https://wiki.tizen.org/Tizen_IVI_Getting_Started_Guide_For_PandaBoard#x-loader_config_files There's also this curious part... "download the MShield signing tool and use the commands below. Contact your TI representative to get access to this tool." 
  

Code¶

• As march 2020, there are no fuses driver or code for any OMAP in either u-boot, Barebox, Linux, or crucible.
• U-boot documentation mention TI tools that have to be obtained after signing an NDA
• TODO: check if chipsec has infos on OMAP fuses

Possible attacks¶

• Even if it's unlikely, once we understand the OMAP restricted boot better, we could check if some devices are signed but not in enforcing mode.

Simply replacing the SOC with a GP version¶

On IRC there was some interest in replacing the SOC by simply unsoldering it and resoldering a GP OMAP.

For some SOCs like the Allwinner A20, it looks relatively easy to do . That is probably not the case for every SOCs as simply soldering a SOC can be really complicated sometimes (look for reballing for more details on how things can go wrong, and how it's typically repaired).

• Identify the very precise SOC.
• Make sure that POP is not needed. It's a pain to find factories that still know how to do that. See the issue that the GTA04 and the Neo900 are having with that. Note that this can sometimes be seen in the bootloader the source code in the code that tries to identify the device or RAM chip. if the eMMC and the RAM chips are together in the same package, it's then possible to identify the RAM chip simply by identifying which eMMC is there (eMMC have vendor and product IDs among other information).
• Make sure it's easy enough to do for people doing microsoldering board level repairs.
• Ideally make sure that the SOC replacement is safe for the environment (RHOS, CE, no lead, etc)
• Find a way to test the device once the SOC has been replaced for the very first time: We can compile the Xloader source code and load that, and get some prints on the UART, however we need to make sure that we can work in tandem with the person doing the SOC swap in order to validate that everything works together. If not, that person might just restore the normal bootloader and declare the "reparation" a success for instance. Or the person might expect the display to work or to have the stock bootloader which might not even work in GP mode because we don't have TrustZone there. The downstream Linux might not even work either because of TrustZone and the upstream Linux might lack a display driver for instance.
• Write code that init the display and probably does a complete test of the device to make it easier for people that swap the OMAPs to check if the device works.
• Find how to handle the amount of work combined with the insecurity of the supply chain for the OMAPs: If we buy only 1 OMAP and do a lot of work, and when the work is done we can't find any anymore, it would not be a good idea. If we buy a lot and nobody does the work it won't be a good idea either. We don't want to force people to work on things either as it would be a very strong attack on their freedom.

• To have a SOC in a package that is very easy to find new (so which is likely unsigned). This is probably not easy as smartphones manufacturers are trying to make thinner and thinner smartphones over time, but we might as well be lucky and find one.
• Having a microSD slot could be handy to try bootloaders on microSD
• If the UART is easy to access and documented it can make the bootloader port much much easier
• If there is an easy way to recover, like the ability to boot through USB, it could be handy, but we could also boot and make sure the SOC reboots to the microSD slot if there is one.
• To have Replicant 6.0 support is not that important because if we get rid of TrustZone we will probably not be able to run the downstream kernel.

Devices:

¹ We need to check which exact model variant it is. Ifixit usually use the generic model like Galaxy SII instead. And on some variant even the SOC can differ.

² See the Step 12 of the Galaxy Nexus Teardown by Ifixit

• If the replacement chip comes from broken devices, then it'll most likely already be signed
• If the replacement chip is new (it could for instance comes from over production or other means) it'll probably not be signed. The rationale behind that is that devices are typically fused in the factory. To do that they typically load the first software through USB or other external means which can then flash the bootloader and fuse the SOC. This is documented in various technical reference manual of system on a chip like various I.MX6 manuals where they talk about loading code for the first time which is then used to program the fuses, which in this SOC family can also configure the boot media.

The issue with these custom packages is that they might not be as available in low and large quantities as regular OMAP SOCs, which are probably already old and so harder to find.

• hpagseddy on #replicant on Freenode is interested in working on the hardware parts of it.

Links¶

• http://www.droid-developers.org : This attempts to run user code on several Motorolla smartphones. It includes analysis of the boot chain:
  • Application_Processor_Boot_ROM
  • Booting_chain