possible zero-day for vzw pixel 2 xl root

[t2noob]

I'm not up to date on what Android has become, so I'm not sure how to get from temproot to OEM unlock partitions, but here's temproot for the Verizon Pixel 2 XL anyway.

The output of 'uname -a' must be:

Now I, too, will wait for someone to write up the rest

Think you can make the source available?

 

[logan2611]

Update: I've gotten the OEM unlock switch to toggle, but something in fastboot is holding me up :/
https://imgur.com/a/6Nv8z4i

 

[LetsHaveSomeAndroidFun]

Update: I've gotten the OEM unlock switch to toggle, but something in fastboot is holding me up :/
https://imgur.com/a/6Nv8z4i

What is happening in fastboot that's holding you up? Also, how did you get the switch to toggle?

 

[Hexlay]

Update: I've gotten the OEM unlock switch to toggle, but something in fastboot is holding me up :/
https://imgur.com/a/6Nv8z4i

https://forum.xda-developers.com/showpost.php?p=75674018&postcount=517

this might help, it's very theorical, but back in days there was no indication of root or whatsoever

 

[Rumold]

Update: I've gotten the OEM unlock switch to toggle, but something in fastboot is holding me up :/
https://imgur.com/a/6Nv8z4i

Toggling the OEM switch changed the sys.oem_unlock_allowed and ro.boot.cid properties? As someone suggested in this post (https://forum.xda-developers.com/showpost.php?p=80225800&postcount=198), that might be the step required and ro.boot.cid 11111111 might imply that is a google version and not a verizon one.

 

[Hexlay]

https://forum.xda-developers.com/showpost.php?p=67172888&postcount=2

Finally found out how it works.
While trying to find my screen resolution while offline I checked getprop with terminal and sys.oem_unlock_allowed [1] came up.

I then checked /dev/__properties__ and it was there so it is enable by writing sys.oem_unlock_allowed = 1 to /dev/__properties__

well, idk if it helps, but...

 

[Rumold]

BTW, I don't know if it is related, but I've found a "sys.oem_unlock_allowed" string reference in system/framework/services.jar (in classes.dex file). I've decompiled it and I've found a class called PersistentDataBlockService (which is related with my previous post). Unfortunately, I can't read the code (the tool just shows an //INTERNAL ERROR// message) but the method's and variables' name describe pretty much everything. Maybe someone with more knowledge can decompile it and use some of those methods to change the Persistent Data Block.

https://imgur.com/a/F3PKhLv

I've found more stuff in this file which is related with the HAL device and with the OemUnlockService. I can't upload the code and I don't want to spam with images and messages, let me know if there is another way to upload it and I'll try. I've added a new image that shows more functions in the same link provided.

 

[Hexlay]

BTW, I don't know if it is related, but I've found a "sys.oem_unlock_allowed" string reference in system/framework/services.jar (in classes.dex file). I've decompiled it and I've found a class called PersistentDataBlockService (which is related with my previous post). Unfortunately, I can't read the code (the tool just shows an //INTERNAL ERROR// message) but the method's and variables' name describe pretty much everything. Maybe someone with more knowledge can decompile it and use some of those methods to change the Persistent Data Block.

https://imgur.com/a/F3PKhLv

I've found more stuff in this file which is related with the HAL device and with the OemUnlockService. I can't upload the code and I don't want to spam with images and messages, let me know if there is another way to upload it and I'll try. I've added a new image that shows more functions in the same link provided.

So oemlock package determines and calls PersistantDataBlockService and this guy is who writes permission to pst partition... Well, i think editing PersistantDataBlockService would be bad idea, but however editing oemlock classes to send false positive? still idk.. i have never looked so deep in android

 

[Rumold]

So oemlock package determines and calls PersistantDataBlockService and this guy is who writes permission to pst partition... Well, i think editing PersistantDataBlockService would be bad idea, but however editing oemlock classes to send false positive? still idk.. i have never looked so deep in android

Me neither, I've never programmed in java so I'm relying in others skills and habilities, but I think you got the concept right. We can try to fake what PersistanDataBlockService writes in the pst partition, modifying this file, building a new jar file with the faked calls or whatever.

BTW If anyone wants to decompile, you just have to do this:

• adb pull /system/framework/services.jar (not a command per se) (give right permissions) ROOT NEEDED (you can copy the file to /sdcard, then adb)
• extract the package, then use dex-tools-2.1-SNAPSHOT (2.0 version will throw an error), execute script d2j-dex2jar.sh on classes.dex (or d2j-dex2jar.bat if you are on windows)
• decompile it with Java-Decompiler

https://github.com/pxb1988/dex2jar/releases
https://java-decompiler.github.io/

P.S: Sorry for the spam guys, but I'm very excited about this after almost 2 years

 

[logan2611]

Please exercise caution when dealing with the /system partition. Because our bootloaders are still locked, any changes to /system will effectively brick our phones due to Android's Verified Boot process.

I was able to get the toggle working through a couple of different methods, but the one that seemed most interesting was the ./oemlock-bridge-client method. The program has 3 different modes, "device_lock", "status", "unlock". I believe that on Google Pixels this in combination with oemlock-bridge is what enables the OEM unlocking flag. oemlock_provisioning appears to be the process responsible for phoning home as everytime I run it the status on the client changed to "provisioned" and resets all of the flags. An unlock may be possible if someone can decipher what exactly needs to be inputted into "oemlock-bridge-client unlock". It takes a version number in hex, a nonce (might be all 0s), and a 256 byte token.

Edit: I got the toggle switch working by changing have_id to 00, and by also running the command with unlock and zeroing everything. I have tried toggling OEM unlocking on and off to see if it would take, but fastboot always says "Flashing is not allowed on this device."

 

[Some1CP]

I can't wait for this to come out. My pixel 2 xl automatically updated to the October patch but I haven't rebooted yet just so that I can unlock the bootloader when something comes out of this. Is it possible to cancel an update after it has been applied? Like reversing the active A/B partition?

 

[slogar25]

Please exercise caution when dealing with the /system partition. Because our bootloaders are still locked, any changes to /system will effectively brick our phones due to Android's Verified Boot process.

I was able to get the toggle working through a couple of different methods, but the one that seemed most interesting was the ./oemlock-bridge-client method. The program has 3 different modes, "device_lock", "status", "unlock". I believe that on Google Pixels this in combination with oemlock-bridge is what enables the OEM unlocking flag. oemlock_provisioning appears to be the process responsible for phoning home as everytime I run it the status on the client changed to "provisioned" and resets all of the flags. An unlock may be possible if someone can decipher what exactly needs to be inputted into "oemlock-bridge-client unlock". It takes a version number in hex, a nonce (might be all 0s), and a 256 byte token.

Edit: I got the toggle switch working by changing have_id to 00, and by also running the command with unlock and zeroing everything. I have tried toggling OEM unlocking on and off to see if it would take, but fastboot always says "Flashing is not allowed on this device."

I think version refers to the bootloader version. But another user and I are thinking the bootloader generates the token itself. So that might be an issue. If you guys look in
/vendor/bin/hw there is another binary called [email protected] This has a major roll as well. Found it a long while back while scrubbing through source of the persistent data block on android git. But I get this when I try to run it....

 

[logan2611]

I think version refers to the bootloader version. But another user and I are thinking the bootloader generates the token itself. So that might be an issue. If you guys look in
/vendor/bin/hw there is another binary called [email protected] This has a major roll as well. Found it a long while back while scrubbing through source of the persistent data block on android git. But I get this when I try to run it....

I just remembered that another thing I found was that the ro.oem_unlock.pst partition points to "/dev/block/bootdevice/by-name/misc"

EDIT: Here's the hex dump of that partition

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000c90  44 69 53 61 00 00 00 00  00 00 00 00 00 00 00 00  |DiSa............|
00000ca0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001800  4f 45 4d 4c 00 00 00 00  00 01 01 01 00 00 00 00  |OEML............|
00001810  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00100000

 

[Rumold]

I just remembered that another thing I found was that the ro.oem_unlock.pst partition points to "/dev/block/bootdevice/by-name/misc"

EDIT: Here's the hex dump of that partition

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000c90  44 69 53 61 00 00 00 00  00 00 00 00 00 00 00 00  |DiSa............|
00000ca0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001800  4f 45 4d 4c 00 00 00 00  00 01 01 01 00 00 00 00  |OEML............|
00001810  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00100000

Welp this confirms my suspect, running /vendor/bin/oemlock-bridge-client unlock might change that block (/dev/block/sda5) because my dump looks like this after executing the following:

taimen:/ # /vendor/bin/oemlock-bridge-client unlock 544d5a333068 11111111 000000000000000000000000029418                                                              
Device lock: 0
Last message: 
        command: unlock (1)
        version: 114556229274964
        nonce: 286331153
        token: 00000000000000000000290041800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Storing message: 
        version: 114556229274964
        nonce: 286331153
        token: 00000000000000000000000002941800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Stored.

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000c90  44 69 53 61 00 00 00 00  00 00 00 00 00 00 00 00  |DiSa............|
00000ca0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001800  4f 45 4d 4c 02 00 00 00  54 4d 5a 33 30 68 00 00  |OEML....TMZ30h..|
00001810  11 11 11 11 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00001820  00 00 00 00 02 94 18 00  00 00 00 00 00 00 00 00  |................|
00001830  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001920  01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00001930  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00100000

Would be nice if someone makes a dump before any change

 

[logan2611]

Welp this confirms my suspect, running /vendor/bin/oemlock-bridge-client unlock might change that block (/dev/block/sda5) because my dump looks like this after executing the following:

taimen:/ # /vendor/bin/oemlock-bridge-client unlock 544d5a333068 11111111 000000000000000000000000029418                                                              
Device lock: 0
Last message: 
        command: unlock (1)
        version: 114556229274964
        nonce: 286331153
        token: 00000000000000000000290041800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Storing message: 
        version: 114556229274964
        nonce: 286331153
        token: 00000000000000000000000002941800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Stored.

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000c90  44 69 53 61 00 00 00 00  00 00 00 00 00 00 00 00  |DiSa............|
00000ca0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001800  4f 45 4d 4c 02 00 00 00  54 4d 5a 33 30 68 00 00  |OEML....TMZ30h..|
00001810  11 11 11 11 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00001820  00 00 00 00 02 94 18 00  00 00 00 00 00 00 00 00  |................|
00001830  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001920  01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00001930  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00100000

Would be nice if someone makes a dump before any change

I believe my dump was made before I tinkered with the oemlock-bridge-client. Interestingly, here is my misc partition after running the unlock command, going into fastboot, failing and then rebooting.

0000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000800  74 68 65 6d 65 2d 64 61  72 6b 00 00 00 00 00 00  |theme-dark......|
00000810  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000c90  44 69 53 61 00 00 00 00  00 00 00 00 00 00 00 00  |DiSa............|
00000ca0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001800  4f 45 4d 4c 00 00 00 00  00 01 02 02 01 00 00 00  |OEML............|
00001810  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001920  01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00001930  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00100000

There now appears to be a 01 at 0x1920, which wasn't there before.

 

[Rumold]

I believe my dump was made before I tinkered with the oemlock-bridge-client. Interestingly, here is my misc partition after running the unlock command, going into fastboot, failing and then rebooting.

0000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000800  74 68 65 6d 65 2d 64 61  72 6b 00 00 00 00 00 00  |theme-dark......|
00000810  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000c90  44 69 53 61 00 00 00 00  00 00 00 00 00 00 00 00  |DiSa............|
00000ca0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001800  4f 45 4d 4c 00 00 00 00  00 01 02 02 01 00 00 00  |OEML............|
00001810  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001920  01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00001930  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00100000

There now appears to be a 01 at 0x1920, which wasn't there before.

Could this be just modifying the toggle itself and not writing in the PST? Could be that dark mode just the force dark mode toggle in developers option?

 

[logan2611]

Could this be just modifying the toggle itself and not writing in the PST? Could be that dark mode just the force dark mode toggle in developers option?

I know that the theme-dark stuff is from me enabling dark theme, beyond that I don't have the slightest clue right now. I'll get back after I try a few things, since I know that modifying this partition is normal behavior.

EDIT:

hexdump post unlock command, OEM switch on:

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000800  74 68 65 6d 65 2d 64 61  72 6b 00 00 00 00 00 00  |theme-dark......|
00000810  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000c90  44 69 53 61 00 00 00 00  00 00 00 00 00 00 00 00  |DiSa............|
00000ca0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001800  4f 45 4d 4c 02 00 00 00  54 4d 5a 33 30 68 00 00  |OEML....TMZ30h..|
00001810  11 11 11 11 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00001820  00 00 00 00 02 94 18 00  00 00 00 00 00 00 00 00  |................|
00001830  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001920  01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00001930  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00100000

hexdump post unlock, OEM slider off:

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000800  74 68 65 6d 65 2d 64 61  72 6b 00 00 00 00 00 00  |theme-dark......|
00000810  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000c90  44 69 53 61 00 00 00 00  00 00 00 00 00 00 00 00  |DiSa............|
00000ca0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001800  4f 45 4d 4c 02 00 00 00  54 4d 5a 33 30 68 00 00  |OEML....TMZ30h..|
00001810  11 11 11 11 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00001820  00 00 00 00 02 94 18 00  00 00 00 00 00 00 00 00  |................|
00001830  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00100000

It seems the 01 at 0x1920 stores the postition of the OEM Unlocking switch.

 

[elliwigy]

yes.. if you run "getprop | grep pst" you will see the bit is stored at offset 6144 on misc partition...

the switch when toggled on sets the bit to 01..

you still need to go into fastboot and run the oem unlock commands..

if it still doesnt allow it then further digging is needed..

ive had a group open since p2xl launched for unlock discussion on tgram..

i no longer have a p2xl however.. if anyone has one and wants to test then pm me for a link.. i did a lot of testing back then so maybe we can get it going sooner rather than later

 

[logan2611]

yes.. if you run "getprop | grep pst" you will see the bit is stored at offset 6144 on misc partition...

the switch when toggled on sets the bit to 01..

you still need to go into fastboot and run the oem unlock commands..

if it still doesnt allow it then further digging is needed..

ive had a group open since p2xl launched for unlock discussion on tgram..

i no longer have a p2xl however.. if anyone has one and wants to test then pm me for a link.. i did a lot of testing back then so maybe we can get it going sooner rather than later

I believe I have tried this already, but I will try it again just to be sure.

EDIT: 6144 offset is the letter O in OEML.

EDIT2: It appears to be safe to write to the misc partition, for the most part.

 

[elliwigy]

I believe I have tried this already, but I will try it again just to be sure.

EDIT: 6144 offset is the letter O in OEML.

EDIT2: It appears to be safe to write to the misc partition, for the most part.

pm me.. we can chat on tgram n test some stuff out

Sent from my SM-N976V using Tapatalk