How to recover the closed-configuration device been tampered

[tsung-chihwang]

Hi All,

My chip set is IMX6UL.

I have one closed-configuration device which been tampered.

Then I used mfgtool to re-download images to flash.

However, these images are illegal.. because I used the wrong keys to sign images..

The target cannot be booted up so far, it will enter into serial down mode.

However, I cannot use mfgtool to upgrade images at this time.

Could you tell me how to recover this target?
Or the target becomes brick permanently?

[karina_valencia]

mariusviorelgrigoras-b32331‌, please continue with the follow up.

[marius_grigoras]

Sure Karina.

Carter, can you please check your CSF file to contain next lines, please?

[Unlock]
Engine = CAAM
Features = RNG

These are mandatory for a closed device.

Thank you,

Marius

[tsung-chihwang]

Hi Marius,

I tried your suggestion, but the result is the same.

BR,

carter

[marius_grigoras]

Hi Carter,

I responded on this also in the private community some time ago, just for having the public one in sync I'll respond also here:

If indeed the customer used the wrong keys to sign the images, then the SoC/target becomes bricked permanently once is closed.

Please suggest to the customer to use the private keys which are in sync with the ones burned to fuses.

Thank you,

Marius

[Yuri]

Hello,

  It is needed to use special files (U-boot, kernel) with MFG tool, that 

are signed with proper keys, so that they can run on closed system. 

Have a great day,
Yuri

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[tsung-chihwang]

But I met this kind of situation.

MFG tool hangs on Loading U-boot to memory, so I cannot do the next step..

[marius_grigoras]

Hi,

Basically you need to prepare a special u-boot image prepared for to be downloaded via SDP protocol used by OTG/MFGtool. Details are in the secure boot AN, but also you can take a look to my steps bellow:

My steps for having an u-boot signed image for mfgtool are bellow:

1. Find the DCD length:

dd if=u-boot.imx bs=1 skip=45 count=2 | od -t x2 -A none --endian=big
380

2. Update the csf-uboot adding next 3 lines, where 0x00910000  is the default OCRAM address where DCD will be copied, 0x2c is the default offset DCD address and 380 is the DCD length calculated using the above dd line (please update this number for your u-boot image)

[Authenticate Data] 
Verification index=2 
Blocks = 0x00910000 0x2c 0x380 "/work/mcu/security/cst-2.3.2/linux64/u-boot.imx"

3. Then you need to get a custom script that allows to sign the binary without the DCD table address in the IVT header since it is cleared during the SDP boot process. 
However, the code must be provided with a valid pointer to allow the manufacturing tool to locate the DCD table. See bellow all the steps.

b32331@fsr-ub1664-133:/work/mcu/security/cst-2.3.2/linux64$ wget https://storage.googleapis.com/boundarydevices.com/mod_4_mfgtool.sh
b32331@fsr-ub1664-133:/work/mcu/security/cst-2.3.2/linux64$ ./mod_4_mfgtool.sh clear_dcd_addr u-boot.imx 
b32331@fsr-ub1664-133:/work/mcu/security/cst-2.3.2/linux64$ ./cst --o csf-uboot_mfg.bin --i csf-uboot_mfg
b32331@fsr-ub1664-133:/work/mcu/security/cst-2.3.2/linux64$ ./mod_4_mfgtool.sh set_dcd_addr u-boot.imx 
b32331@fsr-ub1664-133:/work/mcu/security/cst-2.3.2/linux64$ cat u-boot.imx csf-uboot_mfg.bin > u-boot-signed_mfg.imx

4. The new generated u-boot-signed_mfg.imx image need to be used for mfgtool as firmware image. 

From what I seen in your csf, you need to update the 2nd parameter (instead of 0x0 need to use 0x2c). Also, please check all rest of the parameters. I have added also my csf file and my u-boot signed for mfgtool for your reference. If still you have problems, please add here the u-boot binary and your csf text file.

Thank you,

Marius

[tsung-chihwang]

Hi Marius,

Thanks for your explanation.

I am not sure what is the first command mean.

I got error message while running below command
dd if=u-boot.imx bs=1 skip=45 count=2 | od -t x2 -A none --endian=big

Could you help describe more for me?

BR,

carter

[marius_grigoras]

Hi Carter,

Using SDP (Serial Download Protocol) on close devices to download a signed u-boot reuqires:

1. Modify the CSF file in order to check the DCD tabled loaded in OCRAM memory

=> Otherwise considered as HAB error

2. Sign the u-boot.imx binary with the DCD address set to 0 in the IVT header

=> Since the SDP protocol clears the DCD table address

For the first modification to be done, simply modify the CSF file as suggested in the first reply using next parameters:

0x00910000 – is fixed OCRAM address where DCD will be copied
0x2c – is the offset in the u-boot binary where DCD is starting
0x380 – is calculated as above, being the DCD length

Best regards,

Marius

P.S.: In case you're not familiar with, both DCD and IVT are structures from the u-boot.imx binary. DCD contains key-pair registers (reg address - value) used for DDR and other peripherals initialization and the IVT (being the first structure header) contains the links to the rest of the structures and also to u-boot starting code addr.

[tsung-chihwang]

Hi Marius,

After I modified u-boot_csf.txt, then try to download images via MFG tool.
I found it will not hang on "Loading U-boot", but hang on "Jumping to OS image".

I just update modified u-boot.imx to /firmware folder, should I modify zImage too?

BR,

carter

[marius_grigoras]

Hi Carter,

From the security side, the response is valid and covers how the SDP is working in correlation with secure boot/closed device. So should work only with the u-boot modified.

To be honest, I don't know what's the tricky part now. Maybe a problem with mfgtool and/or with the board.

Have you tried the mfgtool before securing the board? It worked as expected?

Maybe a mfgtool expert can help more.

Thank you,

Marius

[tsung-chihwang]

Hi Marius,

Sure, MFG tool can work fine before securing the board.

So I want to rescue my brick from downloading legal u-boot and kernel via MFG tool.

Could you help me to transfer this issue to MFG tool expert?

I want to know how NXP handle this kind of brick issue(download illegal u-boot to a closed-configuration target).

BR,

carter

[tsung-chihwang]

I uploaded MfgTool.log while the MFG tool hangs on "Jumping to OS image".