LPC3143 OTP dump success using CWlite


I previously purchased a ChipWhisperer Lite for ARM a few months ago as one of my projects was finding out the security bits in a LPC3143 MCU. This at first didn’t go as planned as this particular MCU is based on a ARM926EJ-S and NXP implemented security using OTP data reads.

The LPC3143 and it’s security features, only allows booting secure images once OTP was programmed at factory and therefore uses AES-128-CBC and SHA-hashing the header and data of the boot image. It also comes with several boot modes like DFU, SPI, NOR, NAND, UART and SPI.

My target board was set up to boot from SPI where an encrypted bootloader (U-Boot) was located and using the Tutorials linked here, it was almost impossible to make any use of the AES scripts included within the ChipWhisperer software. So I had to go another way…

After failing a couple of times and almost being frustrated about the unsuccessful results, I gave this another try after several weeks passed…

…and succeeded!

As per supporting several boot modes it’s possible to switch between them according to the MCU manual. One of these modes (especially the UART boot mode) can boot either PLAINTEXT or AES images. Therefore it reads the OTP region if the “AES-VALID” bit is set and once this is true, it then decides to display a message to the UART port which goes like “LPC31xx ready for AES image” and sits there, waiting for the user to download code into the MCU.

Dumping the BOOTROM was easy on my target board because the Linux Kernel running there allowed for terminal access and the BOOTROM region was NOT read-protected. Going further into the BOOTROM code, I found out that I had to flip a bit / variable to actually make the MCU send the message “LPC31xx ready for PLAIN image” to the UART port. Once this worked, I uploaded a memory dumper which would then just spit out the data and so I got my hands on the AES bootloader key of a pretty much secure MCU.

The LPC3143 does not support sending commands or anything unprotected to actually make use of any ChipWhisperer script. I had to write my own Python script for the glitch only to get it to work out as a success, as well as a simple compiled ARM C tool using NXP’s Common Driver Library (CDL) for this particular MCU.

…and I did it on two more target devices with the very same processor.

The whole process required to desolder almost ALL of the capacitors on the target board as the MCU is very resistable to VCC glitch attacks and makes use of any capacitor connected to it’s power rail wherever it can. Between 14 and up to 16 solder points had to be made to connect the ChipWhisperer to the target and the target itself once again to another board where a decoupling capacitor was sitting that actually holds the power low so it would actually boot the OTP memory dumper. This once capacitor just had to be connected once the “…PLAIN…” message was coming in over the UART port after triggering the glitch.

I finally didn’t regret to buy a ChipWhisperer. I’m pretty much happy that this really worked and I still somehow cannot believe that with having the AES bootloader key, I can basically write a completely new bootloader or even update the code.



For reference, I’m adding a link here to the site where I wrote more about how the “WODE” (which is based on a LPC3143) was hacked which allowed for dumping the whole OTP area which is usually locked down after the BOOTROM launched the bootloader.