Realme 9 pro plus not worked #4
Comments
|
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? |
I'm sorry, but how can it work if they shut down lkf.realmemobile.com (lk still works) again? Edit: |
|
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. |
You can trick your phone to use the servers within mainland China ( 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. |
|
I've also tried applying to lk. While it gets instantly approved, as you said, the key is different, they use the Incredible effort by Realme to separate people by nationality. 🤭 |
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. 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. |
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. |
|
The guys who unlocked the bootloader confirmed that their phones have |
|
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, |
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. |
|
If you flash the phone to the Chinese region, will the code be working? Or will it not work on all models? |
From some
I don't see how you could do that.
only
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 ;-) |
|
Why then will the code from the Chinese server be non-working? |
Someone allegedly tried it and it worked. |
|
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.?
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. |
|
Thank you for your answers. |
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 |
|
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. If this is true, there should be a way to bypass this check entirely, as long as you can write to Something like this:
|
|
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. |
No, that's not how it works. At least not according to the EFI loader's logs from |
|
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. |
|
The |
|
It uses new struct. 💀 |
|
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. |
|
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. |
|
What is the new struct? Is the signature code old? How does the bootloader check it? |
|
The old key is sig + serial, the new key is sig + serial + a bunch of 0 + model + a bunch of #. See: #2 (comment) Not sure if the signature is different, though. |
Where is such a struct checked? In deeptest? But the application was not updated. |
|
The bootloader itself. |
|
Can you even modify EROFS? It's supposed to be read-only. And even then, you'll lose a bunch of features with a chance of brickage. You'll still need to submit your request using the script, since the Chinese server supports even less models. |
|
I asked purely theoretically. And almost, for example, for the Realme GT Master Edition (RMX3363), if you flash Chinese firmware via QFIL (the my_stock partition is also replaced), the phone will be "non-export" and the deepest will send request to the Chinese server and the bootloader will unlock. And it works. |
|
Yes, you definitely need more than that. You need at least a correct model to pass the server-side blacklist and the bootloader's model check. I have no idea where the bootloader gets the model name from. Also, the private key used to generate the signature might be different between servers. |
|
So this is the key question. Where does the loader take the model? And, if the Chinese server uses another private key for encryption, then another public key must be used for decryption. Where does it come from? Or do I not understand that? It turns out that not only the export feature is important. |
|
Honestly, no idea, my phone has no Chinese version. Unrelated, but they blocked new applications (-1004 applyLkUnlock) and started returning -1002 for all requests from blacklisted models and -1009 from valid ones. |
Mine too, only export models. :) But there are Taiwanese firmware. Unlocking usually works on them. |
|
lk.realmemobile.com has not been working for two days. In the browser, I get |
|
It is "working" here -- it accepts applications and generates codes. Maybe they're geoblocking you, but that error does not suggest it. That server is not configured to accept GET requests on its root path, everybody will get the "path location is not configured" error if they try to go to https://lk.realmemobile.com/ with a browser. |
|
BTW, their shoddy server does not care about the But it's unfortunately too late for that now ;-( |
|
Apparently they changed something on their server? Two days ago, he was responding like a https://lkf.realmemobile.com/ in browser.
Through VPN, the same thing. Users began to complain that permission to unlock in the deepest stopped coming on Chinese smartphones. Or maybe they just don't have a stable server? |
|
Can I send a request to the Chinese server through your script to check the possibility of unlocking for a specific model? |
I can get a 405 Method not allowed page looking like that by going to https://lk.realmemobile.com/realme/v1/acquireClientStatus
Yes. Of course, try with some other random junk for the NB: the |
|
I sent such a command
What should be the other random junk? |
Because you (or someone else) ran the command before, and that's the model the server has associated with the device identified by the empty serial number and the
Whatever you like; preferably something that could not be a valid realme imei. In order not to DOS their server by filling it with crap (though they fully deserve it ;-)), run the script with the same imei and |
|
What is your opinion, why do some users now get permission from the Chinese server immediately, and some wait for hours or even days? What has changed? Previously, the permission came instantly for all. And from the export server they wait for weeks and do not receive permission at all? Did the servers start not working normally? |
|
@amigaser they're probably trying all kind of lame add-hoc fixes and are cleaning up by hand the database where they hold the serial/imei tuples. They will have to take the server(s) off completely, sooner or later. They're way too broken to stay online for much longer. |
|
The "global" server began sending permission to unlock the bootloader. |
|
Or denials and internal server errors. 🤭 They're still sending |
|
When I started applyLkUnlock in the script, I got the binding of my serial/IMEI to another model written in the script. How do I remove this binding to get the right one through the deepest? What should I do? |
|
|
|
Is it possible to hack the deeptest application so that it replaces the prescribed model that comes from the server in the response structure to the model of your smartphone? Will this structure be written to oplusreserve1? And will the bootloader unlock fastboot in this case? Or is that all nonsense? |
|
You'll lose the system signature by modifying the deeptesting app. Due to the way the key is encrypted it's not possible to modify the key without making it invalid. |
|
That is, you say that this application cannot be hacked? Is that the problem? I meant to change only the name of the model in the struct and not change the key. |
|
No. The app needs to be signed by Oppo to interact with system internals. And about the key. The theory about the first part (before serial) being a SHA digested version of the second part seems to be correct. So, modifying either part of the key invalides the signature. Btw, sending a serial number stuffed with non-deadbeef character doesn't work. The server doesn't have the |
|
Thank you, I got it. No chance. :) |
|
By code *#6776# I can see Manifest: Image. Can someone explain where Manifest and Image come from? From which partition, section or file? Especially interested Image. |
|
Is there any do decryption in server side? what if we simulate the server or do some man in the middle. |
The first is the region/country code in hex ( The second is a similar country code, but obtained from the modem via the RIL ("radio interface layer"). I have no idea where the modem stores that data ;-( |
Maybe in nvram? This is the most interesting thing, because it does not change after flashing to another region. Thank you for the information. P. S. "Image" region code is in nvram (nvdata) at the beginning of the AllFile file in eight bytes in ASCII view. |
|
There's been a new development. A certain version of deep testing can be modified to do basically anything you want (with the system uid). I'm not sure how useful that is outside of writing old codes to oplus_reserve, but here https://xdaforums.com/t/discussion-a-thread-to-collate-and-share-what-is-known-about-unlocking-fastboot-on-oppo-devices.4490041/post-89323153 |
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 checkApproveResultreturns this
{"resultCode":-1006,"msg":"已成功提交审核，正在审核..."}http://videopro.ru/unlock_fail.jpg
The text was updated successfully, but these errors were encountered: