Nokia 8 official bootloader unlock method.
- Thread starter stockandroiddudeone
- Start date
Are you sure your device is updated to the latest firmware? You can check in the device settings at System > About phone > Android security level patch.
Hello, did anybody check if we can also unlock critical using the official unlock key? The unofficial one could unlock critical, giving us a little bit more access to the system.
kosmatyj
Senior Member
The Benefit is rollback to Nougat, fo example. Is it not good? I think it is very good. I have used this possibility. My Nokia 8 now works just fine! I have no problems with wi-fi on rooted device or similar glitches that are inherent to Oreo.
Its not required... I unlock via unofficial too!
---------- Post added at 03:04 PM ---------- Previous post was at 03:03 PM ----------
Yeah, i confirmed... Twrp dev said he will definitely release a fix soon!!!
Afaik is the wifi problem a problem depending on how you root it. But the Offical should unlock critical, it's just the same key. But it's just my guess.
Does Android one nougat have OMS support?
I'll sum it up without the mess:
- 1. Save the file as unlock.key
- 2. Boot to download mode by: First shut down the phone, then press and hold the Volume down key and plug the USB cable.
- 3. In fastboot mode and connected to PC, run the following commands:
Code:fastboot flash unlock unlock.keyCode:fastboot oem unlock
You have Image retention on an lcd ips? I only ever had that issue on OLEDs.
Btw depending on where you from the warranty void for bootloader unlocking is not in line with local consumer protection law (they can only void the warranty for things that can verifyably be caused by a unlock)
So for me in Germany I can always get Hardware repaired for free even if most manufacturers state "warranty void" to cover their asses.
I just threaten them with running to the customer protection agency and they comply...
I don't have image retention but serious case of pink screen on edge of the screen. Check internet for photo. Second time in warranty in less than a year. Now I bought a used p10 lite for the wait and second phone for work.
Did you get the screen replaced? I also had the same issue but screen retention also. I have given the phone for screen replacement. Hope I would not get the issue on the replaced screen too
I'm getting the following error on a brand new Nokia 8:
Anyone else experiencing the same issue? Anyone have an idea how to get around this error message?
How'd you fix this? Getting the same issue.
The app should only accept your device if the requisites are fulfilled. The most important is that your device should be running the September security patch
If your device is brand new, then consider updating and trying again.
Last edited:
I had the same problem on my device (TA-1004), and decided to take a closer look at it. Running "adb logcat" while performing the steps in the app gives out multiple SELinux warnings and app exceptions related to opening the file "/proc/fver".
I also used a proxy to intercept and read the requests by the app to the HMD server.
I could prefectly open the file through "adb shell", and made the observation that the app probably tries to figure out which firmware the phone is running (NB1-488J-0-00WW-B01 for october patch). However, it seemed that october patch messed up the SELinux permissions
so every app that tries to access it gets blocked (shell works because it is some kind of elevated process I think, I vaguely recall that apps run in a different PID range). A side effect of that is that the app always reports the firmware as NB-1.0-0-00WW-B01 and gets
an error code that the version is not in the compatibility list.
As a next step I decided to take apart the apk itself and decompiled it into java code. The code is obfuscated (this means all elements are called a, b, c, d, etc. instead of the original names HMD uses) - so basically unreadable without lots of time,
but thankfully I had a starting point - the errors in the logcat included the spot where the code fails. Reading the file, I found that reading the firmware from /proc/fver is actually just a fallback, the prefered way is to read it from the "ro.build.odm.fver" property,
which, according to running "getprop ro.build.odm.fver" and just "getprop" to list all properties, does not exist.
What does this mean? Either the property never existed and HMD/Google/whoever broke accessing the /proc/fver file in the october patch, or the property existed on september patch, and they forgot to include it in the october patch as well.
(This seems more likely, since, for example, you also needed the september patch to run the app at all, even though they changed keys in august. That already indicates that they had to change something and forgot it now).
Is this solveable? Thats actually a good question. After I already had the code, I thought why not try to get it working.
The problem with that is that even though you can patch the app to stop erroring and force it to send a somewhat correct looking request, there are lots of security mechanisms put in place by HMD
- The app generates a hash of itself, and uses that to verify itself against the HMD server (solveable, SafetyNet just dumps those hashes into the logcat so I assigned them to their variables)
- The app seems to have some form of negotiation between itself and the HMD Server, I couldn't just resend a previous request. (Might be solveable, but hard without knowledge about the HMD server)
- The app does some work inside of a native library that cannot be decompiled. This is a problem.
That last point is important, because the whole body of the request is encrypted, with only a public key availabe in the apps files (public key is for encrypting, to read the data we would need the private key). It probably contains your IMEI numbers since they aren't anywhere else in the request.
Because we can neither decrypt the data to see whats actually sent, nor check out the code that generates the request, we are basically screwed. While you can edit the unencrypted version number in the request header, it did not work so far for me with the october patch version. I tried guessing the version number from september (I went straight from July to October due to having to reflash my device before sending it in for speaker repair, so I don't know the exact number), but it didn't work either.
I would be interested if anyone that is still running september patch could post the firmware version, so I can try that out. If it doesn't work we can say for sure that the firmware version is added a second time to the request body.
I would also be interested if this is a device specific issue. I have the dual-SIM version, maybe it works for the single SIM one?
Maybe it also never worked like it should on the dual-SIM one?
After writing such a long and probably hard to read post, I had a final thought: I wonder if the keys that are used to generate the unlock key are the same for all devices. If yes, and someone manages to figure out how to modify the request, it could be possible to have all different HMD phones (like Nokia 7 Plus for example) to identify with a Nokia 8 firmware and get an unlock key generated. But thats probably just a dream.
Last edited:
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
10
I had the same problem on my device (TA-1004), and decided to take a closer look at it. Running "adb logcat" while performing the steps in the app gives out multiple SELinux warnings and app exceptions related to opening the file "/proc/fver".
I also used a proxy to intercept and read the requests by the app to the HMD server.
I could prefectly open the file through "adb shell", and made the observation that the app probably tries to figure out which firmware the phone is running (NB1-488J-0-00WW-B01 for october patch). However, it seemed that october patch messed up the SELinux permissions
so every app that tries to access it gets blocked (shell works because it is some kind of elevated process I think, I vaguely recall that apps run in a different PID range). A side effect of that is that the app always reports the firmware as NB-1.0-0-00WW-B01 and gets
an error code that the version is not in the compatibility list.
As a next step I decided to take apart the apk itself and decompiled it into java code. The code is obfuscated (this means all elements are called a, b, c, d, etc. instead of the original names HMD uses) - so basically unreadable without lots of time,
but thankfully I had a starting point - the errors in the logcat included the spot where the code fails. Reading the file, I found that reading the firmware from /proc/fver is actually just a fallback, the prefered way is to read it from the "ro.build.odm.fver" property,
which, according to running "getprop ro.build.odm.fver" and just "getprop" to list all properties, does not exist.
What does this mean? Either the property never existed and HMD/Google/whoever broke accessing the /proc/fver file in the october patch, or the property existed on september patch, and they forgot to include it in the october patch as well.
(This seems more likely, since, for example, you also needed the september patch to run the app at all, even though they changed keys in august. That already indicates that they had to change something and forgot it now).
Is this solveable? Thats actually a good question. After I already had the code, I thought why not try to get it working.
The problem with that is that even though you can patch the app to stop erroring and force it to send a somewhat correct looking request, there are lots of security mechanisms put in place by HMD
- The app generates a hash of itself, and uses that to verify itself against the HMD server (solveable, SafetyNet just dumps those hashes into the logcat so I assigned them to their variables)
- The app seems to have some form of negotiation between itself and the HMD Server, I couldn't just resend a previous request. (Might be solveable, but hard without knowledge about the HMD server)
- The app does some work inside of a native library that cannot be decompiled. This is a problem.
That last point is important, because the whole body of the request is encrypted, with only a public key availabe in the apps files (public key is for encrypting, to read the data we would need the private key). It probably contains your IMEI numbers since they aren't anywhere else in the request.
Because we can neither decrypt the data to see whats actually sent, nor check out the code that generates the request, we are basically screwed. While you can edit the unencrypted version number in the request header, it did not work so far for me with the october patch version. I tried guessing the version number from september (I went straight from July to October due to having to reflash my device before sending it in for speaker repair, so I don't know the exact number), but it didn't work either.
I would be interested if anyone that is still running september patch could post the firmware version, so I can try that out. If it doesn't work we can say for sure that the firmware version is added a second time to the request body.
I would also be interested if this is a device specific issue. I have the dual-SIM version, maybe it works for the single SIM one?
Maybe it also never worked like it should on the dual-SIM one?
After writing such a long and probably hard to read post, I had a final thought: I wonder if the keys that are used to generate the unlock key are the same for all devices. If yes, and someone manages to figure out how to modify the request, it could be possible to have all different HMD phones (like Nokia 7 Plus for example) to identify with a Nokia 8 firmware and get an unlock key generated. But thats probably just a dream.7Rejoice people, Nokia just released an official bootloader unlock method for Nokia 8 confirming via a tweet from Juho Sarvikas.
Please check the tweet or Nokia website for more information, I am not yet allowed to post links/urls on XDA threads yet.22
Hi all,
Just got off the chat through the support app, the client service rep confirmed that the latest security update deactivated boot loader unlock for Nokia 8.
He also confirmed they have escalated the issue and it will be addressed by their android department.
And that the solution should come with the next security update.
Let's wait and see...!
New posts
-
How To Guide Best mods + Rooting tips + why you should root
- Latest: nutzfreelance
-
-
-