Realme 9 pro plus not worked

[amigaser]

After updates on their server, the script no longer works for our smartphones.

pm has-feature oppo.version.exp: true ro.product.name: RMX3393RU ro.product.model: RMX3393 ro.build.version.ota: RMX3393_11.C.12_1120_202305050653

I managed to unlock the bootloader before their updates, but others fail. Deeptest writes "This phone model does not support deep testing." If flash the phone to the Taiwan region where unlocking is supported, then the deeptest passes, but fastboot in bootloader does not unlock. When click "Start the in-depth test," the phone reboot, writes an unlock error and boots back to the system. The request perl deeptesting-junk.pl pcb 0xHHHHHHHH imei DDDDDDDDDDDDDDD cmd checkApproveResult returns this {"resultCode":-1006,"msg":"已成功提交审核，正在审核..."}

http://videopro.ru/unlock_fail.jpg

use the new struct
the model name is not match
the model name is not match
verify partition data fail, status = %r
fastboot_unlock_verify fail

[amigaser]

There is information that for the Realme GT Master Edition (RMX3361) and Realme GT Neo 2 (RMX3370) models with China region (NV98/97) firmware the deepest works and the bootloader is unlocked. Can this help you with your research?

[melontini]

There is information that for the Realme GT Master Edition (RMX3361) and Realme GT Neo 2 (RMX3370) models with China region (NV98) firmware , the deepest works and the bootloader is unlocked. Can this help you with your research?

I'm sorry, but how can it work if they shut down lkf.realmemobile.com (lk still works) again?

Edit: https://c.realme.com/in/post-details/1671137365285982208 They literally copy-pasted the old message. (Was this written by ChatGPT?)

[amigaser]

I don't know. The owner of the RMX3370 unlock bootloader 11.06, and RMX3361 yesterday. Perhaps then their server was still working. In addition, another server may be used for China. It does not work in other regions, including Taiwan and Indian. Only China. There is no China region for my phone Realme 9 pro plus, only Taiwan. With him, the situation is as I described above.

[turistu]

I don't know. The owner of the RMX3370 unlock bootloader 11.06, and RMX3361 yesterday. Perhaps then their server was still working. In addition, another server may be used for China. It does not work in other regions, including Taiwan and Indian. Only China. There is no China region for my phone Realme 9 pro plus, only Taiwan. With him, the situation is as I described above.

You can trick your phone to use the servers within mainland China (lk.realmemobile.com instead of lkf.realmemobile.com) via some DNS redirect or override on your router: all their unlock servers are using the same TLS certificate and they do not check the SNI.

But I don't think it will work, because the Chinese servers use a different key to generate the unlock code, and an "export" phone will not accept that code and will not enter fastboot mode even if everything seemed to work right up to that point.

[melontini]

I've also tried applying to lk. While it gets instantly approved, as you said, the key is different, they use the new struct and it didn't accept most of the models I've tried. The key was different for every model I tried, but it wouldn't work either way thanks to the new struct.

Incredible effort by Realme to separate people by nationality. 🤭

[amigaser]

But I don't think it will work, because the Chinese servers use a different key to generate the unlock code, and an "export" phone will not accept that code and will not enter fastboot mode even if everything seemed to work right up to that point.

You must be right. Yesterday, the guy unlocked the bootloader simply by reflash his phone RMX3361 to the China region. He did not use any DNS redirection. His phone has a base (Image) region of :74 (Kenya?). Is it not an "export" phone? And the code was accepted and the bootloader unlocked.

if (this.a.getPackageManager().hasSystemFeature("oppo.version.exp")) {
        this.e = "https://lkf.realmemobile.com/realme/v1/";
} else {
        this.e = "https://lk.realmemobile.com/realme/v1/";
}

For my model, the RMX3393, majority has either the Russian region or the European one. I realized that there is no purely Chinese version of this model. Export only.

[turistu]

He did not use any DNS redirection.

After better checking, DNS redirection would not work anyway, at least not with the current iteration of their server software. So that was a false lead. Sorry.

[amigaser]

The guys who unlocked the bootloader confirmed that their phones have pm has-feature oppo.version.exp: false and Chinese firmware.

[amigaser]

For the Realme GT Master Edition (RMX3363) model with an export region, there is a way to unlock the bootloader by flash service firmware for the Chinese region (domestic) via QFIL. Before flashing the firmware, pm has-feature oppo.version.exp returns true, and after changing the region false, that is, the smartphone becomes non-export and deeptest send request to Chinese unlock server and the bootloader becomes unlocked. Where does this parameter oppo.version.exp come from? Maybe it can be replaced for the deeptest? What other parameters are needed deepest to determine the firmware region?

[rapperskull]

Maybe it can be replaced for the deeptest?

I doubt it will work, since it will force the device to use the Chinese server, and we already established that it doesn't provide a working code.

[amigaser]

If you flash the phone to the Chinese region, will the code be working? Or will it not work on all models?

[turistu]

Where does this parameter oppo.version.exp come from?

From some /etc/permissions/*.xml file in the my_product partition.

Maybe it can be replaced for the deeptest?

I don't see how you could do that.

What other parameters are needed deepest to determine the firmware region?

only oppo.version.exp determines whether the deeptest app will use the lk. or the lkf. server.

If you flash the phone to the Chinese region, will the code be working? Or will it not work on all models?

I have no idea. If you have a phone with Chinese firmware, but for which the they don't support the phone model, you can give it a try ;-)

[amigaser]

Why then will the code from the Chinese server be non-working?

[rapperskull]

I have no idea. If you have a phone with Chinese firmware, but for which the they don't support the phone model, you can give it a try ;-)

Someone allegedly tried it and it worked.

[amigaser]

I look the forum threads on various models and see that all phones initially with Chinese firmware are unlocked. The question is, will export phones altered to Chinese firmware also receive unlocking? Or does it depend on which partitions will be flashed (my_product), etc.?

Someone allegedly tried it and it worked

Thanks. There is only one question, will it work on all models?

[rapperskull]

Thanks. There is only one question, will it work on all models?

I think it should, as long as you have an equivalent Chinese model.

[amigaser]

Thank you for your answers.

[turistu]

So the Chinese server actually uses the same key, or we're missing something.

They're not using the same key, since they were generating different codes for the same pcb + model parameters (and each server --taken separately-- was always generating the same code for the same pcb + model).

It's either that a) the public key that the bootloader checks against is part of the flashed firmware, b) the phone includes the public keys from both servers, or c) they're not actually using that key and stuff and are doing something simpler ;-)

But that's just conjecturing. As long as the only way to write that code to oplusreserve1 is with that stupid deep testing app, it's not very appealing to waste time reverse engineering the bootloader to determine what exactly it does.

[rapperskull]

What I fail to understand is why the phone stays unlocked after switching back to global, since the Chinese server uses the new struct, and also a different key. My guess is that the signature is only checked when the bootloader is locked and you try to unlock it. Then, as long as it stays unlocked, no check is performed. This means that if you re-lock the bootloader, you shouldn't be able to unlock it again. Can someone with more knowledge of the process than me confirm or deny?

If this is true, there should be a way to bypass this check entirely, as long as you can write to oplusreserve1 in a way or another.

Something like this:

[melontini]

Hmm, when I decompiled the bootloader for RMX3081 it was always doing that rsa_verify check. It can skip the check if your phone has Secure Boot disabled, which is impossible on the retail version, as it's controlled by QFUSES.

[turistu]

My guess is that the signature is only checked when the bootloader is locked and you try to unlock it. Then, as long as it stays unlocked, no check is performed.

No, that's not how it works. At least not according to the EFI loader's logs from oplusreserve5 (unless I'm totally misinterpreting them):

#### BEFORE UNLOCKING FASTBOOT

Fastboot=1, Recovery:0
GetVmData: No Vm data present! Status = (0x3)
VM Hyp calls not present
Launching fastboot
secureboot is enabled!
Loading Image Start : 3217 ms
partition name maybe changed, try to oplusreserve1!
Loading Image Start : 3218 ms
Loading Image buff : 4096
reserve start:1114 size:4096
Loading Image Done : 3220 ms
Total Image Read size : 4096 Bytes
the serial is not match
fastboot_unlock_verify error and reboot.uefi reboot device with type 0x3E

#### AFTER UNLOCKING FASTBOOT

Fastboot=1, Recovery:0
GetVmData: No Vm data present! Status = (0x3)
VM Hyp calls not present
Launching fastboot
secureboot is enabled!
Loading Image Start : 3215 ms
partition name maybe changed, try to oplusreserve1!
Loading Image Start : 3217 ms
Loading Image buff : 4096
reserve start:1114 size:4096
Loading Image Done : 3218 ms
Total Image Read size : 4096 Bytes
VerifyHashWithRSASignature: SecRSAVerifySig failed! Status: 00000050
Failed to verify hash
The 1 time fastboot unlock rsa verify fail
The 2 time fastboot unlock rsa verify success
Fastboot Build Info: Nov 30 2022 21:09:46
usb_shared_hs_phy_init: hs phy cfg size: 12
Fastboot: Initializing...
EFI_ChargerExGetChargerPresence skipQcomUsbPwrCtrl
Fastboot: Processing commands
Dev_Common_Speed: Bus Speed: High
Dev_Common_Speed: Bus Speed: High
Handling Cmd: getvar:all
EFI_ChargerExGetChargerPresence skipQcomUsbPwrCtrl
Handling Cmd: getvar:all
EFI_ChargerExGetChargerPresence skipQcomUsbPwrCtrl
Handling Cmd: flashing get_unlock_ability
Handling Cmd: flashing unlock
[project = 136938!
[lcm] MDPPlatformConfigure 13
Read: NumHalfSectors 0x10, ReliableWriteCount 0x0
VB: RWDeviceState: Succeed using rpmb!
Read: NumHalfSectors 0x10, ReliableWriteCount 0x0
Write: NumHalfSectors 0x10, ReliableWriteCount 0x10
VB: RWDeviceState: Succeed using rpmb!
Write: NumHalfSectors 0x30, ReliableWriteCount 0x30
uefi reboot device with type 0x1

#### AFTER UNLOCKING THE BOOTLOADER

Fastboot=1, Recovery:0
GetVmData: No Vm data present! Status = (0x3)
VM Hyp calls not present
Launching fastboot
secureboot is enabled!
Loading Image Start : 3216 ms
partition name maybe changed, try to oplusreserve1!
Loading Image Start : 3217 ms
Loading Image buff : 4096
reserve start:1114 size:4096
Loading Image Done : 3219 ms
Total Image Read size : 4096 Bytes
VerifyHashWithRSASignature: SecRSAVerifySig failed! Status: 00000050
Failed to verify hash
The 1 time fastboot unlock rsa verify fail
The 2 time fastboot unlock rsa verify success
Fastboot Build Info: Nov 30 2022 21:09:46
usb_shared_hs_phy_init: hs phy cfg size: 12
Fastboot: Initializing...
EFI_ChargerExGetChargerPresence skipQcomUsbPwrCtrl
Fastboot: Processing commands
Dev_Common_Speed: Bus Speed: High
Dev_Common_Speed: Bus Speed: High
Handling Cmd: download:0a000000
Download Finished
Handling Cmd: boot
Fastboot Send Fail
Handling Cmd: getvar:has-slot:boot
EFI_ChargerExGetChargerPresence skipQcomUsbPwrCtrl
Handling Cmd: getvar:current-slot
EFI_ChargerExGetChargerPresence skipQcomUsbPwrCtrl
Handling Cmd: getvar:max-download-size
EFI_ChargerExGetChargerPresence skipQcomUsbPwrCtrl
Handling Cmd: getvar:is-logical:boot_b
EFI_ChargerExGetChargerPresence skipQcomUsbPwrCtrl
Handling Cmd: getvar:partition-size:boot_b
EFI_ChargerExGetChargerPresence skipQcomUsbPwrCtrl
Handling Cmd: download:0a000000
Download Finished
Handling Cmd: flash:boot_b
flash image status:  Success
Handling Cmd: reboot
rebooting the device
uefi reboot device with type 0x3E

[melontini]

Just to throw into the discussion, they seem to do something similar to this https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.rsa.verifyhash?view=net-7.0 or this https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.rsacryptoserviceprovider.verifyhash?view=net-7.0

I'm not sure where they get the data hash from as the RSA verify function only accepts 1 argument. I'd need to re-decompile the bootloader which I can't do ATM. And it doesn't seem very useful, as you still can't write this stupid code into the reserve.

[amigaser]

The lkf.realmemobile.com server started working. Now it remains only to check the situation with the bootloader unlocking.

[melontini]

It uses new struct. 💀

[rapperskull]

Are we sure the new struct is a problem? Are the new fields actually checked? Without an update to the bootloader, it's not obvious. BTW I tried the checkApproveResult command on my already unlocked serial, and it returned the old struct already in oplusreserve1.

[melontini]

Yes, the new struct stuff is checked.

You get old struct because you already applied. If you close and re-apply you'll get new struct.

[amigaser]

What is the new struct? Is the signature code old? How does the bootloader check it?

[melontini]

The old key is sig + serial, the new key is sig + serial + a bunch of 0 + model + a bunch of #.

See: https://github.com/turistu/rmx3474-rooting/issues/2#issuecomment-1570311321

Not sure if the signature is different, though.

[amigaser]

new key is sig + serial + a bunch of 0 + model + a bunch of #

Where is such a struct checked? In deeptest? But the application was not updated.

[melontini]

The bootloader itself.

[amigaser]

The bootloader was also not updated if I did not install the firmware update. Or have these checks already been built into it?

[melontini]

They've been there for a bit. No idea since when, but A13 has them 100%.

[rapperskull]

@melontini I see that you started to decompile the bootloader on XDA. What is the name of the bootloader partition? I don't seem to find it.

[melontini]

It's abl.

[rapperskull]

It's abl.

Is it obfuscated?

[amigaser]

but A13 has them 100%.

But then it becomes possible to unlock the bootloader on another firmware by rolling back to an older one. And by the way, I unlocked the bootloader by script on my phone on the A13 in early May before the server was closed.

[melontini]

@amigaser The server returned old struct before it got shut down.

As per rolling back, idk, I only looked into A13's abl.

[rapperskull]

We're definitely missing something. It looks like there's a flag the bootloader checks in order to verify with the old or new struct. But, what writes this flag? The response from the server returns only the unlockCode and not this flag. Is it the deeptest app that simply checks the length of the response to set this flag?

[melontini]

@rapperskull no, but it's UEFI, so you need to extract it first and then decompile it with HexRays IDA or Ghidra. The generated pseudo code is pretty nonsensical and broken.

There's no flag, it checks the key itself. Here's the function to save you a headache https://forum.xda-developers.com/t/discussion-a-thread-to-collate-and-share-what-is-known-about-unlocking-fastboot-on-oppo-devices.4490041/post-88602997

[amigaser]

We need to study changes in the bootloader code. It is not clear why they tormented their server for so long? Perhaps they were waiting for updates on all their smartphones that are in current support.

[amigaser]

I just received a message in the topic of my phone about unlocking using a script! It works again!

[melontini]

But it doesn't? I just checked with different models, OTAs, etc and just got booted from fastboot.

[amigaser]

Yes, it was false information, sorry. Bypassing through the script does not work. Fastboot does not unlock. Only the standard method works for some regions and models as before.

[rapperskull]

@melontini If you have an unlock code with the old struct, can you de-apply and re-apply and see if the signature part is the same or different? But maybe is different anyways, if it includes a timestamp.

[turistu]

Bypassing through the script does not work. Fastboot does not unlock.

I suppose that you' re getting again that using the new struct and the model name is not match messages on the screen, right?

[melontini]

@melontini If you have an unlock code with the old struct, can you de-apply and re-apply and see if the signature part is the same or different? But maybe is different anyways, if it includes a timestamp.

It's different for me, applied with identical info as pre-shutdown.

[amigaser]

the model name is not match messages on the screen, right?

It wasn't me doing it. He said just that apply to unlock comes, but after rebooting into fastboot, the phone simply reloads into the system. As it was before the shutdown.

[rapperskull]

@melontini If you have an unlock code with the old struct, can you de-apply and re-apply and see if the signature part is the same or different? But maybe is different anyways, if it includes a timestamp.

It's different for me, applied with identical info as pre-shutdown.

Does it change again if you de-apply and re-apply again?

[melontini]

No.

[rapperskull]

I think we should try to extract the public key from the bootloader and check what's actually inside. BTW, if the two bytes following the serial number are not 0x30 0x30, the permission and model name check are skipped entirely. What I'm wondering is what happens if we overwrite everything after the serial with zeroes, like in the old struct. Will the new signature match? Can't know without finding what the signature signs.