FORUMS

Nokia 8 official bootloader unlock method.

15 posts
Thanks Meter: 7
 
By stockandroiddudeone, Junior Member on 27th September 2018, 02:20 PM
Post Reply Email Thread
28th September 2018, 08:32 PM |#31  
Senior Member
Thanks Meter: 72
 
Donate to Me
More
Quote:
Originally Posted by paeschli

I closed the web page with the 5 step instruction (the one where they explain you need to download the unlock key and save it under a specific name and how you boot into the right mode).

Could anyone copy-paste it here?

I'll sum it up without the mess:
  1. 1. Save the file as unlock.key
  2. 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. 3. In fastboot mode and connected to PC, run the following commands:
    Code:
    fastboot flash unlock unlock.key
    Code:
    fastboot oem unlock
And you are done. Confirm on the phone when (if) prompted.
2nd October 2018, 07:27 AM |#32  
Member
Thanks Meter: 31
 
More
Quote:
Originally Posted by Sahinbas

I will not definitely do that! Cause, it is a high risk to unlock a device with a cronic image retention problem. I don't want to make my warranty void until I can completely trust this device!

TA-1012 cihazımdan Tapatalk kullanılarak gönderildi

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...
2nd October 2018, 08:04 AM |#33  
Senior Member
Thanks Meter: 75
 
More
Quote:
Originally Posted by Trissi

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.
The Following User Says Thank You to kekkojoker90 For This Useful Post: [ View ] Gift kekkojoker90 Ad-Free
2nd October 2018, 11:12 AM |#34  
Junior Member
Thanks Meter: 2
 
More
Quote:
Originally Posted by kekkojoker90

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
2nd October 2018, 04:38 PM |#35  
Senior Member
Thanks Meter: 75
 
More
Quote:
Originally Posted by shashankkp12

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

Yet to sent in
The Following User Says Thank You to kekkojoker90 For This Useful Post: [ View ] Gift kekkojoker90 Ad-Free
14th October 2018, 03:44 PM |#36  
Member
Thanks Meter: 7
 
More
Quote:
Originally Posted by OneDream

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.
14th October 2018, 08:57 PM |#37  
Senior Member
Thanks Meter: 72
 
Donate to Me
More
Quote:
Originally Posted by vonManstein

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 or anything newer than that. Update: Doesn't work in October. So, September only.
If your device is brand new, then consider updating and trying again.
15th October 2018, 07:30 PM |#38  
Member
Thanks Meter: 7
 
More
Quote:
Originally Posted by singhnsk

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 or anything newer than that.
If your device is brand new, then consider updating and trying again.

Thanks, on the latest (Oct) update so quite perplexed. Very strange!
20th October 2018, 04:05 AM |#39  
felipondrioxcl's Avatar
Senior Member
Flag Santiago
Thanks Meter: 44
 
More
Im on oct patch and still getting "device not support"
20th October 2018, 11:11 AM |#40  
THMSP's Avatar
Senior Member
Flag Europe
Thanks Meter: 239
 
More
Quote:
Originally Posted by felipondrioxcl

Im on oct patch and still getting "device not support"

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.
The Following 10 Users Say Thank You to THMSP For This Useful Post: [ View ] Gift THMSP Ad-Free
20th October 2018, 11:46 AM |#41  
Senior Member
Thanks Meter: 72
 
Donate to Me
More
Quote:
Originally Posted by THMSP

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.

I have no idea about about the functioning of the app, but as with the unlock keys (unofficial), each key is unique to the device and the project key. So, they were generated with an RSA-signed combination of IMEI number and the NB1, BL2 part from the serial number. Hence, I do not think it will work if the server is trained to serve requests only for NB1.
That said, I have no idea if that has changed with the new service bootloader and the new method to sign the keys as the old ones do not work anymore.
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes