5

I have a board where in principle aim at emulating a DVD-ROM loading iso file from a drive.

This board is running a ARM CPU with 32MB of ram and has no vga output. The firmware update comes with 2 files called uImage and rootfs that needs to copied into the SDCARD.

I have tried:

  • binwalk: returns nothing on both
  • file: returns nothing on both
$ mkimage -l uImage
GP Header: Size 9411c123 LoadAddr 7f1c7cb5

$ mkimage -l rootfs
Image Type:   Freescale IMX Boot Image  
Image Ver:    2 (i.MX53/6/7 compatible)  
Mode:         PLUGIN  
Plugin Data Size:     302835498 Bytes = 295737.79 KiB = 288.81 MiB  
Plugin Code Size:     0 Bytes = 0.00 KiB = 0.00 MiB  
Plugin Load Address:  6c9053ca  
Plugin Entry Point:   3533782f  
U-Boot Data Size:     302835498 Bytes = 295737.79 KiB = 288.81 MiB  
U-Boot Load Address:  6c9053ca  
U-Boot Entry Point:   3533782f  

From dumpimage

$ dumpimage -l rootfs  
Image Type:   Freescale IMX Boot Image  
Image Ver:    2 (i.MX53/6/7 compatible)  
Mode:         PLUGIN  
Plugin Data Size:     302835498 Bytes = 295737.79 KiB = 288.81 MiB  
Plugin Code Size:     0 Bytes = 0.00 KiB = 0.00 MiB  
Plugin Load Address:  6c9053ca  
Plugin Entry Point:   3533782f  
U-Boot Data Size:     302835498 Bytes = 295737.79 KiB = 288.81 MiB  
U-Boot Load Address:  6c9053ca  
U-Boot Entry Point:   3533782f  

$ dumpimage -l uImage  
GP Header: Size 9411c123 LoadAddr 7f1c7cb5  

Data part is strange as the file is 40MB and not 300MB by the way as shown above. I have tried removing the 64bit header of both and re-run all the above with no luck so far.

I have seen a post for this device with a screenshot of the boot sequence, so it might be encrypted but not sure.
enter image description here

I just want to add an additional driver/module to get higher Ethernet performance.

If someone here as experience in u-boot with Freescale i.MX that would be great.

The picture of the board:
enter image description here

8
  • I have added extra information. Apr 16, 2019 at 8:58
  • Values from mkimage look bogus to me. Could you shared the image? Or give a try with dumpimage?
    – wisk
    Apr 16, 2019 at 20:24
  • I have added the result of dumpimage in the thread but it shows the same result. You can find the complete SDCard image which contains the boot in version v1.30 here: mediafire.com/file/5fqybr87uefiled/… Apr 17, 2019 at 8:59
  • You can also find in the link below the latest firmware in v2.01-4 which is not the complete SD card image but just the update of file uImage and rootfs that are to replace the one in the SD image. gbatemp.net/download/x360key-xk3y-firmware.32248/… Apr 17, 2019 at 9:02
  • Thanks for sharing. With OSFMount and Ext2sd, I was able to mount your SD card image. Unfortunately both uImage and rootfs seem to be encrypted (or compressed with an unknown way). Are you sure this is a i.MX SoC behind? Did you disassemble your key to check the reference on the chip?
    – wisk
    Apr 17, 2019 at 13:14

2 Answers 2

3

LPC3143 supports secure boot so probably this device has been configured for it. From the datasheet:


  1. Features

– On the LPC3143 only: secure booting using an AES decryption engine from SPI flash, NAND flash, SD/MMC cards, UART, or USB.

6.7 Internal Static ROM (ISROM)

The internal static ROM is used to store the boot code of the LPC3141/3143. After a reset, the ARM processor will start its code execution from this memory.

The LPC3143 ROM memory has the following features:

  • Supports secure booting from SPI flash, NAND flash, SD/SDHC/MMC cards, UART, and USB (DFU class) interfaces.
  • Supports SHA1 hash checking on the boot image.
  • Supports non-secure boot from UART and USB (DFU class) interfaces during development. Once AES key is programmed in OTP, only secure boot is allowed through UART and USB.
  • Supports secure booting from managed NAND devices such as moviNAND, iNAND, eMMC-NAND and eSD-NAND using SD/MMC boot mode.
  • Contains pre-defined MMU table (16 kB) for simple systems.

If you can get runtime access to the device, you may be able to dump the decrypted data; I don't see a way to decrypt these images statically.

6
  • Dear Igor, thank you for your answer, what do you mean exactly by "get runtime access to the device"? Apr 23, 2019 at 20:32
  • @Armandooooo e.g. serial console (UART) or JTAG
    – Igor Skochinsky
    Apr 24, 2019 at 5:42
  • There is a way to get a serial connection to it, but I don't know if it is UART or JTAG or anything else. Do you think doing the following would help progressing: eurasia.nu/… Apr 24, 2019 at 9:44
  • @Armandooooo: yes, that looks like a good start
    – Igor Skochinsky
    Apr 24, 2019 at 10:35
  • Hi Igor, apparently there is no prompt after boot as per the link above. What should i look for then? A way to dump the encryption key? Apr 25, 2019 at 9:05
1

Sorry, I have no chance to answer this by any other way...

@Armandooooo:

The MCU on your target PCB is a LPC3143, which was pre-programmed with the "AES-VALID" bit set in OTP at factory.

This means, OTP also holds the bootloader AES key which is a AES-128-CBC crypto key as per the MCU manual. So the bootloader is encrypted. This also applies to the Kernel itself. The Kernel AES key is stored within the bootloader binary once you get the bootloader decrypted (which requires shifting the encrypted bytes as well as the AES key and the AES IV around).

This MCU supports locking the access to the OTP area once the bootloader has started. The developer just has to set the "READ-PROT LOCK" bit after bootup and any reads from that area will then return zeroes (0). This definitely applies to your target.

I've been previously working on the LPC3143 on my own regarding the encryption and hacking open access to the locked OTP area (with success). The effort was big as it requires soldering at least 14 up to 16 wires to the target and some expensive extra hardware as well as Python scripts and an ARM memory dumper written and compiled in C.

But the AES key only won't be enough as LPC3143 encrypted binaries also require the AES IV which is hiding itself within this MCU's BOOTROM.

Regarding your own target, I almost have the whole OTP area dumped as well as the BOOTROM and the bootloader AES key and AES IV extracted as I've been working on the XKEY as well. With UART connected to the PCB you basically only see debug output of the bootloader but not from within the Kernel itself. So how did you get terminal access there as it doesn't print out any messages after decryption and verification of the Kernel header and jumping into SDRAM where it resides?

3
  • Hi @nitr8, I m glad to see I am not the only only who would like to get this thing with additional features... I did not get past the bootloader screen either, but I managed to get a read access to specific files within the system. Once you upgrade the xkey to the latest firmware 2.04 then you will see there is another File System RWFS that is unencrypted. This stores data of how many times you run games. There is a http address that will display the content of the file, ad using symlink, it enabled me to display /etc/passwd content. It is still progress, but not as far I wanted to be. Jun 29, 2022 at 9:00
  • I am curious now on how you were able to hack it? Was it with the XKEY or with another use case of the LPC3143? Jul 1, 2022 at 14:35
  • You should check your reddit chat inbox.
    – nitr8
    Jul 2, 2022 at 16:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.