Unlock Bootloader Kirin 710

[Julia Kozub]

HereI have some questions when I added the bootloader into my application. I read the applicatiin note "r01an0718ej0102_rl78g13.pdf" know the sample code in CubeSuite+ , but my requirement of bootloader is different. 1) To save code space (MCU is R5F100AC 32K ROM) I hope the bootloader code size can be as small as possible. 2) don't want the bootswap function.

I removed the swap function in bootloader code and set the flash staring address to 1000H (application start address) in CubeSuite+ and tried a test application about 200H code size. but I found the map file of application allways exist the 4bytes code "@EVECT00 02000H 00004H CSEG AT

@EVECT00 @cstarte 02000H 00004H", The last application code is at 11AEH , a) I don't know how to move the reset vector of application to 1000H in CubeSuit+ ? b) how to further decrease the bootloader code size (for example remove the not necessary functions of FSL lib into bootloader and how to check) ?

about a) you mention that make a directive file(.dr) as below ... , it means for the boot project or application project ? I tried add it in application flash project, but casue many compile errors! , I think the

b) I read that in the FSL document but how ro check the code size useage by FSL library ? , My situation meet the Table 2-10 (following function are used, but in my case actually even not use FSL_Iverify ,FSL_BankCheck, FSL_StatusCheck) how to know what functions and size been included in the build code ?

I guess it's better to do based on the sample which came with an application notebook below.

"RL78 Family Flash Self-Programming Library Type01Japanese Release"

Since sub project will be one, it's necessary to consider so as not to change every time it's compiled with memory directive setting.

I have not thought yet....

Thanks your information, I need build both the boot and flash projects together so I rewrote the whole codes by refernced the AP note "r01an0718ej0102_rl78g13.pdf" and sample code, not just only boot or flash application alone. I changed the branch table address to 1000H by running the repvect.bat with chiptype set to "f100le" as the instructions in document and work fine with r5f100le MCU, but has problem (error: "processor type different" in the startup file "s0rlle.rel: or s0rllb.rel" )if I change to "rafl100ac" MCU and rebuilt in CubeSuite+ IDE. I have question, whether I need rebuild the startup file again everytime if I change to different MCU in CubeSuite+ IDE ? For example , I change to R5F100AC then I need rebuild new starup routine for the boot and flash projects becasue of current startup routine is for R5F100LE.

Another question : Could I select the R5100LE MCU (64pins 64KROM,4KRAM) setting to build projects for target R5100AC(30pins 32KROM, 2KRAM) MCU in the CubeSuite+ ? The built hex/imagine file could be download to R5100AC by the E1 tool and Renesas's flash programmer without problem ? Let me know the detail if possible ?

So, straight to the point.

In Qualcomm based devices, we can enter EDL mode and with the right firehose programmer, we can do so much in the device such as access the storage and flash custom binaries or inject some commands.

The question is, what can we do with Hisilicon based devices?

Hisilicon based devices have some boot mode that equals to EDL from Qualcomm and I believe that we can achieve so much from there but how it works and to make a real use of it.

First step would be to identify the eMMC generation. Generally CLK+GND shorting would get you in faulty mode for eMMC up to version 4.x. For 5.x generations CLK+DAT+GND might do the trick, but I've only read about this and I didn't experiment myself.

There are pretty many docs about JTAG and ISP techniques for forensic procedures. Those are the base. Decryption on-the-fly while acquisition is the next step, usually way harder then the first step )

No need to look for eMMC faults most of the time, at least up to P20/Mate 20 series. Many HiSilicon based Huawei phones have testpoints to access their "service" mode, with phone being recognized as "Huawei USB COM 1.0". This mode is often used for firmware downgrade or FRP bypass on "new bootloader" phones, where the process seems to push and execute older bootloader version (they're unique per the CPU variant, not per the phone itself), then boot into fastboot mode and use an exploit to temprarily partially unlock bootloader.

As far as i tested - no, at least not on every device. The recent one i tested was P20 Lite that i needed to downgrade using testpoint method. It's an "exploit" used to write any signed Huawei firmware used by many flasher boxes. Even if flashing fails at some early stage, or in case you deselect userdata, phone will boot fine with data intact.

This doesn't allow to write any unsigned image, like custom recovery, custom boot image, at least as far as i tested. I haven't tried to enable "OEM Unlock" in settings and then using this method to write TWRP without actually unlocking bootloader.

Recently we have presented our research on the remote exploitation of Huawei basebands at Black Hat USA 2021.As part of our findings, we have identified several bootloader vulnerabilities in Huawei Kirin chipsets.In addition to that publication, we have also recently disclosed an additional bootrom vulnerability (CVE-2021-22429) in Huawei Kirins.

As it has been publicized, many of these bootloader vulnerabilities were present in bootrom code.As such, it can come as a surprise that Huawei in fact created a mitigation which was published just before Black Hat, in a July OTA update (updates started from June 29th, to be precise).

In this post, we describe how we reverse engineered the OTA to figure out how it prevents the exploitation of the bootrom vulnerabilities and how we in turn figured out a way to bypass the mitigation and maintain control of a device while also applying the OTA.

Luckily, in the case of the newest Kirin chipset family (Kirin 9000), Huawei received our initial reports in time for them to apply codefixes both at the bootROM and xloader level before the first devices with Kirin 9000 ever came out.

After a number of tries, we were able to conclude that the Test Point detection still works (that is when the Test Point is triggered an alternate boot path is selected), but for some reason the USB refuses to enumerate.That is to say, the boot process locks up and stays frozen when the Test Point is triggered, but without the trigger the phone boots up successfully.

When we analyzed the status of FPB in Kirins, we found that Huawei does in fact utilize the FPB unit of the Cortex-M3, but in a rather exotic way.The memory layout of the BootROM does not align with the hardcoded 0x20000000 SRAM base address, because the SRAM begins at 0x20000 instead.So as a workaround there is a tiny memory (probably backed by pure registers) at 0x20000000 to hold the FPB replacement values.

Most of the efuse values which are multi-bit (e.g. a number or a byte-string) are checksumed.The employed checksum simply stores the number of zeros over the bits of the content, which is amusingly clever.The efuse bits are initially all zeroes, and only the zero-to-one transition is allowed by the physics of the fuse.So the zero values can only decrement, but it is impossible to decrement a binary value by zero-to-one transitions.

The zero-count checksum mismatches are handled as faults, so the ARM FPB entries are not populated.This also means that, if done correctly, the FPB efuse values can only be written once, at the factory, because any subsequent write (albeit the efuse bits can be written!) would result in a bogus zero-count value, and thus no FPB would be applied.

Armed with that knowledge, we have previously analyzed the FPB efuse values in Kirin 990s and found that while the efuse bits are fully zeroed out, the checksum counter was also set to the maximum value:

By examining the context of this change, we found that the patch is located in the beginning of a function related to USB initialization.We originally called this function usb_clk_and_power_init, because it seems like clocking, gating, and power initialization happens inside.This function is reachable on the following call path in xloader (11.0.0.188):

As we can see, the behavior regarding the address 0xb818160c has changed and a new debug log message has appeared!The new code always clears the 12th bit at that address, whereas beforehand that bit was set only when reading a one-bit from the SCDEEPSLEEPED register.

So we have analyzed the xloader code so far. It gave us a useful hint, but the USB Download Mode fails in bootrom already, so the question was, what could have changed there?At this point, we looked for the same usb_clk_and_power_init in the bootrom and sure enough we found a basically identical code:

There it is, the same behavior!This gave us the theory that the 7th bit of the SCDEEPSLEEPED register must have changed as the result of the OTA update and that change now means that the 0xb818160c value gets initialized differently (set as opposed to not getting set) during USB controller bring-up.The log message, specifically, told us that this system control register bit is something called a VREGBYPASS.

Armed with the knowledge of the particular efuse and sysctrl addresses, we looked for hints in kernel sources.In soc_lpmcu_baseaddr_interface.h we found a reference to this sysctrl range, which is called HSDT_SYS_CTRL.

3a8082e126