[DISCUSSION] A thread to collate and share what is known about unlocking fastboot on Oppo devices

[User154]

Admin: Please move/delete this thread if it is in the wrong place or against the rules.

I wanted to create a thread to discuss unlocking fastboot mode on Oppo devices in general, rather than discussing it in terms of any one device in particular. The reason being is that there are currently little bits of information scattered here and there across various different device forums. I think it would be useful to have somewhere where we could pool our information on the subject.

I will say at this point, I'm not sure what progress can be made, but I do think we could answer some of each other's questions and build a bigger picture of what is going on.

One question I have for example, that I know someone out there will know, or be able to test, is if you have enabled engineer mode with the sec5 app, or otherwise, are you then able to invoke methods from the 'android.engineer.OplusEngineerManager' class without getting an selinux error?

I have decompiled the deeptesting app and looked through the sources a little and found the method that unlocks fastboot mode. Its signature is as follows:

fastbootUnlock(byte[ ] bArr, int i)

The byte array is essentially formed as followed:

a string is split into pairs of characters,
each pair is a hex code that is converted to an int,
the byte value of each of these integers is then stored in a byte array.

The int that the fastbootUnlock method takes is simply the length of the byte array.

I have a find x3 pro and have hit a bit of a brick wall in testing in that I cannot invoke methods from the 'android.engineer.OplusEngineerManager' class however I do suspect that with engineer mode enabled it may be possible to invoke methods from this class.

If you have any information you feel may be relevant, any questions, or even just want to say hello, do not hesitate to post

 

[User154]

So, no major breakthroughs to report but some stuff that may be of use to people.

After hitting a bit of a brick wall disassembling the deeptesting and engineermode apks I have turn my attention to the system.

Both these apks rely on custom services implemented by oppo (Although most files relating to them have oplus in the name)

After loading up one of the service files 'vendor-oplus-hardware-engineer@1.0-service' in ida I think I can see that the key required to unlock fastboot mode is stored on the odm partition in /odm/etc/DownloadModeKey/ (This is a little over my head but I can see multiple references to this)

Also I have found an xml with a list of mmi codes, I don't know how much use it will be to anyone, but there are a couple in there that I dont believe have been documented elsewhere, so I will upload it here

 

[super5at]

I did some very cursory reverse-engineering of the deeptest app and basically came to the conclusion that it depends on the response from Oppo's servers. In a properly designed system (which the original Danger hiptop/T-Mobile Sidekick implemented) there's an unlock entitlement cryptographically signed by the OEM. I *assume* that's the case here, but I don't know for sure.

 

[User154]

I did some very cursory reverse-engineering of the deeptest app and basically came to the conclusion that it depends on the response from Oppo's servers. In a properly designed system (which the original Danger hiptop/T-Mobile Sidekick implemented) there's an unlock entitlement cryptographically signed by the OEM. I *assume* that's the case here, but I don't know for sure.

Getting the correct response from Oppo servers allows the app to invoke the fastbootUnlock method however I believe the key required for the method is stored on device.

From my point of view, the biggest, and perhaps only remaining, hurdle is being able being able to invoke methods from the OplusEngineerManager class from our own apps.

I know the method required and and what parameters should be passed to it. I strongly suspect from reverse engineering the engineer service the key is stored on device. This key is then seperated into pairs of digits and convertered to a byte array. The fastbootUnlock method takes 2 parameters, the byte array and an integer that is equal to the length of the byte array.

 

[wizard8400]

Hi! I'm trying a different approach, to spoof the device model so that the deep test.apk will do its thing.
I have the realme gt 2 (EU) RMX3311 that can't be unlocked but the Indian version (RMX3312) can be unlocked. Some guys managed to change the region of the RMX3311 to India and the deep test apk allowed the bootloader to be unlocked. So, from what I've read, deep test reads build.prop and if it finds the right model it communicates with realme backend to receive the unlock code, and everything works...
Now I'm trying to find in the deep test apk when it reads the device model and change that code so it accepts whatever it finds The problem is I can't understand smali source code )

 

[User154]

Hi! I'm trying a different approach, to spoof the device model so that the deep test.apk will do its thing.
I have the realme gt 2 (EU) RMX3311 that can't be unlocked but the Indian version (RMX3312) can be unlocked. Some guys managed to change the region of the RMX3311 to India and the deep test apk allowed the bootloader to be unlocked. So, from what I've read, deep test reads build.prop and if it finds the right model it communicates with realme backend to receive the unlock code, and everything works...
Now I'm trying to find in the deep test apk when it reads the device model and change that code so it accepts whatever it finds The problem is I can't understand smali source code )

Hi! You might find it easier to understand the flow of the app if you decompile to java, the output won't be compilable but you could pinpoint where the region is checked and cross reference that to the smali code you have, you could at least get some idea of where to start.

I will say, if a modified version of the app can still access the OplusEngineerManager class without an selinux denial, then you could probably just get your download mode key by doing a dump of your device in edl mode and then modify the app to call its fastbootUnlock method with the key from your dump.

I haven't tested this because on my find x3 pro I can't even install the deeptesting app.


I haven't tried to do much in a while because I've gotten a bit stuck trying to work out how to calculate the secrecy token. I am not great with C and trying to understand decompiled pseudocode is a little bit beyond me lol. Quite disheartening too knowing that even if it was possible to work out that token by disassembling system services, it still might not mean I was able to access the OplusEngineerManager class.

 

[Unf59]

Luddite I be. Tired and couldn't workout how to cancel a post

 

[burhanhanzada199888]

https://xdaforums.com/t/kernel-source-and-device-tree-released.4534491/

 

[User154]

https://xdaforums.com/t/kernel-source-and-device-tree-released.4534491/

Always great to get a notification for this thread

The release of the kernel sources for the Find X3 Pro is slightly old news, sadly I don't think there is much to be found in regards to unlocking the bootloader or engineer mode.

 

[User154]

Secrecy/Engineer mode unlock possible (For a limited time), for more info please see here:

https://xdaforums.com/t/secrecy-unlock.4365059/post-87919303

 

[User154]

Small update:

Decided to try and pull the DownloadModeKey from my Find X3 pro via adb, the operation was a success but sadly it just looks like an RSA public key so not much use.

 

[xuanhoang1811]

Small update:

Decided to try and pull the DownloadModeKey from my Find X3 pro via adb, the operation was a success but sadly it just looks like an RSA public key so not much use.

Continue work bro

 

[serv0id]

Hi there,
I have reverse engineered the process deep testing apk does and recreated it independently of the phone.
Suppose I have the "token" which is sent as a byte array to android.engineer.OplusEngineerManager method fastbootUnlock, what will that achieve, except the unlock ofcourse?

I am new to the oppo ecosystem and trying to understand what powers this engineerMode has.

 

[User154]

Hi there,
I have reverse engineered the process deep testing apk does and recreated it independently of the phone.
Suppose I have the "token" which is sent as a byte array to android.engineer.OplusEngineerManager method fastbootUnlock, what will that achieve, except the unlock ofcourse?

I am new to the oppo ecosystem and trying to understand what powers this engineerMode has.

So I don't actually know for sure what else that method would do, but I can't imagine it would do much else. The OplusEngineerManager class contains multiple methods that do different things, from what I could see most of them are not called by the deeptesting app at all I think I have found the library that the OplusEngineerManager class calls but I'm not 100% sure.

Have you got the token?

 

[mkaylynn7]

Hey folks - apologies for being late to the party, but thought I'd add my findings.
I stumbled across this thread & a few others after doing some digging into the "in-depth testing" tool. A few things:

• I can't actually *install* the "in-depth testing" APK on my Find X5 Lite (a.k.a Reno 7 5G) - it seems like some version of the tool is already baked in to the stock ROM, so whatever APK I got my hands on fails to install because of conflicts.
  • I thought about trying to repack the APK, but apktool wasn't having it so I gave up pretty quickly.
• I decompiled the version of the APK I have, and it looks like it's referencing the class "android.engineer.OppoEngineerManager" when it calls a "fastbootUnlock" method (already established above, I know I know)
• I did some poking around and pulled (what I believed to be) the engineer mode APK using ADB, but after decompiling it things started to get a bit... weird. All of this is in a completely *different* namespace, it seems, and it's "com.oplus.engineermode" - so I have a hunch that I'm looking at bits of two different codebases. No luck, then.
• One of the other threads I was looking at mentioned there being a couple things of interest in the /odm/ directory - seemingly what the "fastbootUnlock" method was actually calling *into* - but I wasn't able to pull any of that over ADB. Seems the directory is protected :/
• With that in mind, I went on a quest to find a stock ROM to dig around in there. I did manage to find one and download it, but actually getting anything *out* of it has been a massive pain in the ass.
  • The stock ROM I found just has a big old ".ofp" file in it, instead of anything sensible - so in other words, proprietary garbage.
  • I had to use a dedicated extractor to get any files out of it, but even *that* wasn't enough; all of the juicy stuff is split into multiple ".img" files, and there's a bunch of different bits and pieces for the "super" image.
  • The bits and pieces for that super image are mentioned in a "mapping" file. This is just a text document that matches up different regions/carriers with the parts of the super image that you need.
  • All of the parts of the super image (once you've figured out which ones you need) need to be joined together. Just running "cat super0.xxxxx.img super1.xxxxx.img super2.xxxxx.img" seemed to work for this? (... but I was also able to use "simg2img" from the android otatools as well, see below)
  • But the troubles don't end here! This is a sparse image, so you need to go through *another* step to deflate it. I wound up using "simg2img" for this, and it gave me a final, honest-to-god super image. (imjtool was also able to do this for me)
  • Then comes the process of actually *extracting* the component parts of the super image. I originally used "lpunpack" (also from the android otatools) for this, but the output was really bizarre. *Some* of the output files were mountable ext4 partitions, but the ones I cared about *weren't*. More specifically, the files for the "product", "vendor", "system" and "odm" partitions were all just... gibberish. I wasn't able to mount them at all.
  • After some more searching I came across "imjtool", which is available here. And this tool has singlehandedly saved my entire ass. I got it to extract the super image again, and LO AND BEHOLD, it was able to identify the file system used by the "product", "vendor", "system" and "odm" partitions. It's.... (drum roll please) Huawei EROFS. More proprietary garbage.

Now that I *know* this, I can see the light at the end of the tunnel, and I think I have a reasonable chance of grabbing whatever-the-... the in-depth testing APK is actually calling *into*. Hopefully then I can decompile that, and figure out what the hell fastboot is doing on this device.

If I manage to get anywhere, I'll mention it here ^^ it's been a bit of a rigmarole so far haha

{Mod edit: Inappropriate language edited. Oswald Boelcke, Senior Moderator}

 

[User154]

Hey folks - apologies for being late to the party, but thought I'd add my findings.
I stumbled across this thread & a few others after doing some digging into the "in-depth testing" tool. A few things:

• I can't actually *install* the "in-depth testing" APK on my Find X5 Lite (a.k.a Reno 7 5G) - it seems like some version of the tool is already baked in to the stock ROM, so whatever APK I got my hands on fails to install because of conflicts.
  • I thought about trying to repack the APK, but apktool wasn't having it so I gave up pretty quickly.
• I decompiled the version of the APK I have, and it looks like it's referencing the class "android.engineer.OppoEngineerManager" when it calls a "fastbootUnlock" method (already established above, I know I know)
• I did some poking around and pulled (what I believed to be) the engineer mode APK using ADB, but after decompiling it things started to get a bit... weird. All of this is in a completely *different* namespace, it seems, and it's "com.oplus.engineermode" - so I have a hunch that I'm looking at bits of two different codebases. No luck, then.
• One of the other threads I was looking at mentioned there being a couple things of interest in the /odm/ directory - seemingly what the "fastbootUnlock" method was actually calling *into* - but I wasn't able to pull any of that over ADB. Seems the directory is protected :/
• With that in mind, I went on a quest to find a stock ROM to dig around in there. I did manage to find one and download it, but actually getting anything *out* of it has been a massive pain in the ass.
  • The stock ROM I found just has a big old ".ofp" file in it, instead of anything sensible - so in other words, proprietary garbage.
  • I had to use a dedicated extractor to get any files out of it, but even *that* wasn't enough; all of the juicy stuff is split into multiple ".img" files, and there's a bunch of different bits and pieces for the "super" image.
  • The bits and pieces for that super image are mentioned in a "mapping" file. This is just a text document that matches up different regions/carriers with the parts of the super image that you need.
  • All of the parts of the super image (once you've figured out which ones you need) need to be joined together. Just running "cat super0.xxxxx.img super1.xxxxx.img super2.xxxxx.img" seemed to work for this? (... but I was also able to use "simg2img" from the android otatools as well, see below)
  • But the troubles don't end here! This is a sparse image, so you need to go through *another* step to deflate it. I wound up using "simg2img" for this, and it gave me a final, honest-to-god super image. (imjtool was also able to do this for me)
  • Then comes the process of actually *extracting* the component parts of the super image. I originally used "lpunpack" (also from the android otatools) for this, but the output was really bizarre. *Some* of the output files were mountable ext4 partitions, but the ones I cared about *weren't*. More specifically, the files for the "product", "vendor", "system" and "odm" partitions were all just... gibberish. I wasn't able to mount them at all.
  • After some more searching I came across "imjtool", which is available here. And this tool has singlehandedly saved my entire ass. I got it to extract the super image again, and LO AND BEHOLD, it was able to identify the file system used by the "product", "vendor", "system" and "odm" partitions. It's.... (drum roll please) Huawei EROFS. More proprietary garbage.

Now that I *know* this, I can see the light at the end of the tunnel, and I think I have a reasonable chance of grabbing whatever-the-... the in-depth testing APK is actually calling *into*. Hopefully then I can decompile that, and figure out what the hell fastboot is doing on this device.

If I manage to get anywhere, I'll mention it here ^^ it's been a bit of a rigmarole so far haha

{Mod edit: Inappropriate language edited. Oswald Boelcke, Senior Moderator}

Hi, sorry I only have chance to write a quick reply, I had a similar headache trying to extract the system files

I did manage to do it in the end, and I can unlock engineer mode on my find x3 pro, if you want any specific files, pm me and I'll send then over

 

[User154]

What files were you looking for? I think the apk makes calls to the service I mentioned in OP I have had a look in IDA but I am not so great at understanding the pseudo code so have not gotten very far

 

[xuanhoang1811]

Hi, sorry I only have chance to write a quick reply, I had a similar headache trying to extract the system files

I did manage to do it in the end, and I can unlock engineer mode on my find x3 pro, if you want any specific files, pm me and I'll send then over

How about the unlock bootloader ?

 

[User154]

How about the unlock bootloader ?

This requires firstly the code which I do believe has to come from Oppo/Realme/whoever. The code stored on the device is an RSA key that the code is presumably checked against.

If someone manages to work out how to get code from Oppo unofficially then we need a way for an app to invoke the fastbootUnlock method from a custom app.

I haven't done much on this recently, I have been working on other projects, sorry.

 

[DRS_Frizzy]

Hi just wanted to say that it's nice to hear that some people try to unlock Bootloader on OPPO Qualcomm i thought that everyone accepted that it's not possible to unlock it and if you didn't know there is app called APKTool M you can read some root files with this app like this DownloadMode key and I can install Depp Testing app but I get this error:

For extracting firmware maybe you can putting phone to EDL and extracting firmware with Qualcomm Softwares as said we can use ApkTool M to read some root files but not all I attach Deep testing file that worked for me here and site from where I got it:https://www.oppo.cn/thread-397164526-1