Develop Bugs

Wild speculation

I don't have the experience to know if this is possible, which is why I ask because I'm curious. I post here because I want devs to see it, and think "that could work" or "idiot"
As we know the defy bootloader will probably never be unlocked, now I was thinking would it not be possible to somehow isolate the bootloader from a rom, and run some kind of virtual one in a seperate partition to run a fully custom kernel? It's probably crazy but I'm dying to know what people think, don't be too hard on me I have no coding experience :/ however all opinions are welcome I think anything is possible
Sent from the real world by hacking into the matrix

I don't want that this will become another dead Bootloader-Hacking-Thread but I want to give you an answer with the facts:
1) There currently is no known way to execute code before booting the kernel because everything is well protected though signing code.
2) The only way to boot a kernel after kernel-boot are tools like kexec or 2ndboot. But a phone's RIL is a heavy stone on that way because it's not that easy to reinitialize this part of hardware and without RIL a phone is useless. The main-developers canceled this project due to this reason.
Other "non-phone"-devices with locked bootloader (like Sony's google-tv) are using this method without problems.
3) You can use kexec/2ndboot to load a full bootloader instead of an kernel only, too. But because we don't have the source we would have to reverse engineer it to disable the signature check of the kernel otherwise you would load another useless protected bootloader This was also an project but I don't think it's still alive...
Additional note: You can't directly flash a modified bootloader because our chipset has built-in OMAP3-security features. This means the CPU will only boot signed Code from NAND.
You can find many helpful information about this topic on this page:
http://and-developers.com/partitions:cdt#cdt_table_of_droid_x

Thanks that clarifies things quite a bit, however I mean loading not just a second kernel but a WHOLE bootloader that would handle the phones entire functions independently, or is it completely hardwired so its impossible for something to override it? (Sorry if you have already answered in the above). Another thing, has noone tried to compile custom fixed sbf? Maybe the bootloader could be replaced that way? In software almost anything done can be undone in some way, although perhaps this is the rare case where it isn't
Sent from the real world by hacking into the matrix

I edited my post to have everything at one place.
I hope this answers your questions.

The bootloader is like the bios in a pc (actually is part of the bios), it's what initializes the device and loads the rest of the code. to load it again or another one you had to reinitialize the device. the issue with the RIL is that when reset or restarted it "panics" and resets the whole device (I think, read it somewhere).
also the second unlocked bootloader that you want to load does not exist anyway.
it's better to just help the developers with bug reports and testing than daydream.
sorry mate!

m11kkaa said:
I edited my post to have everything at one place.
I hope this answers your questions.
Click to expand...
Click to collapse
So its all been tried before, damn! XD at least the devs here have done a fine job of making good roms even with this limitation, guess I will do my research before I buy my next phone as I love playing with roms, the more custom, the better
Sent from the real world by hacking into the matrix

Do google know that we've unlocked the bootloader?

Do google know that we've unlocked the bootloader? (as Sony do as they ask for email adresses etc and confirm the ulock)
Wondering about warranty.

there is a notice about unlocking of bootloader may violate warranty . thing is it is stated in a somewhat vague manner, it is not like CAUTION YOU ARE ABOUT TO VIOLATE WARRANTY but rather worded like you may be in violation of warranty. anyway, i think it does violate and yes there is most likely a software switch that sets a value in hardware register which can be recovered to determine that the bootloader was unlocked. if you have the least bit of concern do not unlock.

dkryder said:
there is a notice about unlocking of bootloader may violate warranty . thing is it is stated in a somewhat vague manner, it is not like CAUTION YOU ARE ABOUT TO VIOLATE WARRANTY but rather worded like you may be in violation of warranty. anyway, i think it does violate and yes there is most likely a software switch that sets a value in hardware register which can be recovered to determine that the bootloader was unlocked. if you have the least bit of concern do not unlock.
Click to expand...
Click to collapse
Ok thanks.
One last google noob question; does rooting usually need an unlocked bootloader?
On xperia root is more difficult to achieve with a locked bootloader, but can be done, thanks to the devs.
I guess I will read the 6P thread to get a feel for the situation.
Cheers again.

i do not know if it is possible, in practice as far as i know it is necessary to unlock if any modification is wanted. recently it is popular to gain root without mod of /system partition. hopefully that is what is achieved with the pixel c.
edit: never done this but, fastboot boot recovery recovery.img then flash a superuser from temp recovery. however it seems you would still be restricted from mod of /system
in future.

dkryder said:
i do not know if it is possible, in practice as far as i know it is necessary to unlock if any modification is wanted. recently it is popular to gain root without mod of /system partition. hopefully that is what is achieved with the pixel c.
edit: never done this but, fastboot boot recovery recovery.img then flash a superuser from temp recovery. however it seems you would still be restricted from mod of /system
in future.
Click to expand...
Click to collapse
If you use fastboot boot then you do not need to specify a partition (only if using fasboot flash *partition* image.img).
The device is still very new but im sure a custom recovery will be released soon so an easy root can be achieved.
MArk.

mskip said:
If you use fastboot boot then you do not need to specify a partition (only if using fasboot flash *partition* image.img).
The device is still very new but im sure a custom recovery will be released soon so an easy root can be achieved.
MArk.
Click to expand...
Click to collapse
I sure hope so. That's one of the only things keeping me from buying it already. It's kind of worrisome that the development forums are almost completely dead (save for the one thread trying to get root without a custom recovery, of course). I guess I'm just spoiled by using only Nexus devices, so having very active development is usually the norm.

well, the thing was only a rumor about sales start up until a report in a german site on 12/5 or so that sales would start 12/8 and then on 12/8 a confirm that at 1pm eastern u.s.a. sales would begin. talk about giving people a decent notice about a device this pixel c was a new low for google. it's almost they decided to sell them as android tablet at last moment instead of tossing in trash as a complete failure as chrome os tablet so, yeah, it will take a while for anyone that has skill to develop this device to ante up the funds and take delivery. if bootloader remains locked and boot temp recovery to flash supersu does that restrict the root in any way? i am just curious about this as my bootloader is unlocked.

Droid Turbo 2 Lets figure out how to get root

This thread is intended for the Droid Turbo 2. For the lucky Moto X Force owners, this thread shouldn't apply to you.
I think there are some brilliant minds lurking on this forum and I'm hoping there could be some research done to "encourage" the possibility of attaining root and boot loader access on our Droid Turbo 2 Devices.
My approach here is to establish a collection of "Zero Day Bugs". Security flaws found in our devices that would put our OS as risk. As far as I can tell, Google keeps a record database and the media likes to talk about zero-day discoveries. Of course these bugs need to be timely so zero-day flaws found in 2014 or early 2015 likely were patched with the launch of the DT2.
For example, below is a link to a Zero-Day exploit that elevates the privileges of an app. Can something like this be used? Who has the technical expertise to replicate such an exploit? This thread is to talk about these things.
http://perception-point.io/2016/01/...f-a-linux-kernel-vulnerability-cve-2016-0728/
Hopefully this will spur up some traction and help get us root and bootloader.
Exploit found for Turbo 2 that can grant root access
Given the widespread impact of this exploit, it is likely other device owners are going to try to implement this exploit as well. Please post here if you find any implementations for other devices as it may be usable for the Turbo 2.
It has been confirmed that Quadrooter can exploit the Turbo 2: http://www.zdnet.com/article/quadrooter-security-flaws-affect-over-900-million-android-phones/
Four vulnerabilities (CVE-2016-2059, CVE-2016-2504, CVE-2016-2503, CVE-2016-5340)
And just an FYI:
"ALLOW OEM UNLOCKING" DOES NOTHING ON THE DROID TURBO 2
Click to expand...
Click to collapse

windraver said:
This thread is intended for the Droid Turbo 2. For the lucky Moto X Force owners, this thread shouldn't apply to you.
I think there are some brilliant minds lurking on this forum and I'm hoping there could be some research done to "encourage" the possibility of attaining root and boot loader access on our Droid Turbo 2 Devices.
My approach here is to establish a collection of "Zero Day Bugs". Security flaws found in our devices that would put our OS as risk. As far as I can tell, Google keeps a record database and the media likes to talk about zero-day discoveries. Of course these bugs need to be timely so zero-day flaws found in 2014 or early 2015 likely were patched with the launch of the DT2.
For example, below is a link to a Zero-Day exploit that elevates the privileges of an app. Can something like this be used? Who has the technical expertise to replicate such an exploit? This thread is to talk about these things.
http://perception-point.io/2016/01/...f-a-linux-kernel-vulnerability-cve-2016-0728/
Hopefully this will spur up some traction and help get us root and bootloader.
Click to expand...
Click to collapse
Could be used on a Terminal Simulator and get the bootloader lock transistor to break safety.
But honestly, my first thought would be to force into QHSUSB_DLOAD and somehow inject all XT1580 stuff to get it recognized as such.

I have installed one-click root (I got it through another site, not from them) and it sometimes says failed to root, but other times, it goes through the process, says it's done and to reboot, but when rebooting it does not have root. I have tried running other apps, like King Root, or Root Genius, or half a dozen others to get it to root, after getting one-click to say it has rooted it. Not sure if this will help or not, and honestly, I'm to the point, I'm ready to give up and do something different. I WILL NEVER buy another Verizon phone, ever! I may not drop them as a carrier, but I wont be keeping their crappy locked junk.

brannonwj said:
rant
Click to expand...
Click to collapse
From what I understand, this thread is for brainstorming. Not ranting about how you didn't do your research.

not a rant
Techn0Luigi said:
From what I understand, this thread is for brainstorming. Not ranting about how you didn't do your research.
Click to expand...
Click to collapse
That wasn't a rant about how I didn't do any research. IT was a what I did that might lead to someone having an idea of how it might help.
Don't be a jerk.

mr_verystock said:
Could be used on a Terminal Simulator and get the bootloader lock transistor to break safety.
But honestly, my first thought would be to force into QHSUSB_DLOAD and somehow inject all XT1580 stuff to get it recognized as such.
Click to expand...
Click to collapse
Can you explain the QHSUSB_DLOAD more?

QHSUSB_DLOAD (Qualcomm High-Speed USB Download Mode)
Man... It's been a while. Haven't had fun with any of this.
The bootloader starts and checks everything. There are 3 stages of the bootloader. 1 starts TZ, 2 something else, by 3 everything is booted and then it loads fastboot. QHSUSB_DLOAD is baked into the hardware. If the bootloader file is missing (.sbn) or doesn't match magic key (.hex) then booting fails. Most of the stuff turn off except for the CPU (in this case, ARM Cortex A53 and A78) and communications (USB interface), and it is stuck at QHSUSB_DLOAD. From there, you can load anything raw into the phone. So you can bring over the partitions that is used to boot (so in this case, you may be able to bring over something that damages TZ transistor, thereby unlocking bootloader). What you bring over exactly for the bootloader unlock, it hasn't been discovered even with the original Moto X (2013). However, that's how root is done. Bring over the blocks of the OS that contains the root blocks, and the bootloader doesn't know a thing.
Bring over a valid .sbn and .hex file and forcing the phone CPU to reset would bring the phone back from the missing bootloader, and then fastboot loads, followed by the OS (if the Linux core is present, the boot sector there, but that's another topic).

They rooted the phone in China , they sell it rooted!! Here is the link
m.intl.taobao.com/detail/detail.html?id=521809261322&spm=0.0.0.0

mr_verystock said:
QHSUSB_DLOAD (Qualcomm High-Speed USB Download Mode)
Man... It's been a while. Haven't had fun with any of this.
The bootloader starts and checks everything. There are 3 stages of the bootloader. 1 starts TZ, 2 something else, by 3 everything is booted and then it loads fastboot. QHSUSB_DLOAD is baked into the hardware. If the bootloader file is missing (.sbn) or doesn't match magic key (.hex) then booting fails. Most of the stuff turn off except for the CPU (in this case, ARM Cortex A53 and A78) and communications (USB interface), and it is stuck at QHSUSB_DLOAD. From there, you can load anything raw into the phone. So you can bring over the partitions that is used to boot (so in this case, you may be able to bring over something that damages TZ transistor, thereby unlocking bootloader). What you bring over exactly for the bootloader unlock, it hasn't been discovered even with the original Moto X (2013). However, that's how root is done. Bring over the blocks of the OS that contains the root blocks, and the bootloader doesn't know a thing.
Bring over a valid .sbn and .hex file and forcing the phone CPU to reset would bring the phone back from the missing bootloader, and then fastboot loads, followed by the OS (if the Linux core is present, the boot sector there, but that's another topic).
Click to expand...
Click to collapse
I'd like to see a Verizon phone rooted. That is the version I have and most in the U.S. have as well.
Sent from my XT1585 using Tapatalk

I finally updated my Turbo 2, losing hope on a root exploit.
Then I read this.
http arstechnica dot com/security/2016/06/godless-apps-some-found-in-google-play-root-90-of-android-phones (sorry, longtime lurker, just registered, can't post links)
It might lead to nothing, but maybe for those who haven't updated an exploit can be found with the godless apps?

The godless app is a hack that steals your data. If it did work, (which from what I understand it only works on 5.1 and below) you'd risk your personal and financial data being stolen and sold.

Alaadragonfire said:
They rooted the phone in China , they sell it rooted!! Here is the link
m.intl.taobao.com/detail/detail.html?id=521809261322&spm=0.0.0.0
Click to expand...
Click to collapse
Any luck in contacting the seller on how it is rooted?

I'm sure they use stolen Lenovo/Motorola factory development "engineering" software which unlocks the bootloader. It's the same phone as the Moto X Force but with locked down bootloader.
There were similar Droid Turbo phones being sold with unlocked bootloader a year ago in China, months before the Sunshine exploit was found.

gizzardgulpe said:
I finally updated my Turbo 2, losing hope on a root exploit.
Then I read this.
http arstechnica dot com/security/2016/06/godless-apps-some-found-in-google-play-root-90-of-android-phones (sorry, longtime lurker, just registered, can't post links)
It might lead to nothing, but maybe for those who haven't updated an exploit can be found with the godless apps?
Click to expand...
Click to collapse
I dont have my dt2 but link to one of the apps in case someone wants to try
https://apkpure.com/summer-flashlight/com.foresight.free.flashlight?hl=en

I'm usually just lurking here and grab Roms and exploits when they pop up, but I have something to add. Has anyone unlocked the developer settings? There's a toggle named 'oem unlocking' with a subtext of 'allow the bootloader to be unlocked'. Does this mean the bootloader can be unlocked? Last Verizon phone I had was a g3 and only way to gain a faux unlock was to use 'bump' to install twrp. Could this be possible with the turbo 2? I'm not a coder or anything, but just trying to add to the think tank here

This setting does nothing.

damkol said:
This setting does nothing.
Click to expand...
Click to collapse
There really should be a sticky saying "ALLOW OEM UNLOCKING DOES NOTHING ON THE DT2"

Droid turbo 2
After spending countless hours trying to unlock my bootloader to root my phone I'm at an impasse I've been told the Verizon and at&t models arnt able to be unlocked I will keep trying to get around this to root and install custom roms if anyone has any tips

Rhydenallnight said:
After spending countless hours trying to unlock my bootloader to root my phone I'm at an impasse I've been told the Verizon and at&t models arnt able to be unlocked I will keep trying to get around this to root and install custom roms if anyone has any tips
Click to expand...
Click to collapse
Crack the case, hook up some leads (microscope) and dump the memory for the boot loader is the only thing I can think of. Don't know if the that is even possible with that memory. It's probably integrated with other stuff.
Sent from my XT1585 using Tapatalk
Update: Oh yeah, it's encrypted. Guess that won't work.

Found something. Does anyone know if this vulnerability exists on the Droid Turbo 2?
CVE-2015-1805
http://www.computerworld.com/articl...itical-android-root-vulnerability-itbwcw.html
There is a proof of concept out there. Has anyone tried it?
https://github.com/dosomder/iovyroot

Bootloaders (aboot/sdi/rpm/hyp/pmic/cmnlib/etc) Interchangeability

Hi, I understand that the G-2PW2100s all share identical hardwares, but are the bootloader partitions interchangeable between the Verizon ones & non-Verizon ones? (<- This is question #1) i.e. Can I for example use NJH47F factory image instead of NHG47Q (Verizon) from https://developers.google.com/android/images#marlin on a Verizon marlin assuming the bootloader is unlocked? Or if the stock rom is already rooted and I can overwrite the bootloader partitions via dd? Or perhaps fastboot boot twrp and then dd the bootloader partitions?
If so, can one say there are then no differences between these G-2PW2100 variants? (<- This is question #2)
Update 1: Since everyone focuses on the unlockability and ignores what's asked above, let me state that I know there's currently no way to unlock the bootloader or root the Verizon Pixel, and the purpose of this thread is to collect information in order to help those stuck with a locked bootloader on Verizon Pixels. If you have such information, feel free to share; repeating "you can't unlock/root" is not helpful. I do not own a Verizon Pixel, and I have absolutely nothing to gain from this; I merely want to give back to the community.
Rooting gives one access to read/write the partitions on the eMMC, therefore gives the ability to overwrite the bootloader partitions, which allows unlocking the bootloader.
Unlocking the bootloader also grants read/write access to the partitions on the eMMC, therefore allowing one to overwrite the partitions on the eMMC.
Sneaking an OTA pre-rooted image may or may not be possible, so is finding another way to gain access such as disabling signature check.
The point is, it comes down to the ability to write the partitions on eMMC; once it's writable, you own everything that's on the eMMC. Most people tend to think it's only about the ability to root/unlock, which isn't exactly false, but it's not exactly true either.
Update 2: According to aboot.c, the last byte of the eMMC controls whether a device can be unlocked or not (assuming the compiled aboot in your device uses this logic) For future reference, code is attached.

I don't think you can fastboot boot twrp img with lock bootloader.
Sent from my SM-G950U using Tapatalk

Nochis said:
I don't think you can fastboot boot twrp img with lock bootloader.
Sent from my SM-G950U using Tapatalk
Click to expand...
Click to collapse
Right, but if there's a way to flash or write to the partitions, it should be able to convert a Verizon Pixel to a non-Verizon Pixel. That's what I'm trying to confirm.

AncientDeveloper said:
Right, but if there's a way to flash or write to the partitions, it should be able to convert a Verizon Pixel to a non-Verizon Pixel. That's what I'm trying to confirm.
Click to expand...
Click to collapse
You can't overwrite a locked bootloader...that is the very definition of a locked bootloader. Yes, you need root. Root either temporary or permanent is what is needed to unlock the VZ phones. This has been covered a million times here.

TonikJDK said:
You can't overwrite a locked bootloader...that is the very definition of a locked bootloader. Yes, you need root. Root either temporary or permanent is what is needed to unlock the VZ phones. This has been covered a million times here.
Click to expand...
Click to collapse
The question asked in the post was that if this was doable, then there should be no differences between the 2 variants? I have not asked if unlocking the bootloader is possible at the moment.

Go ahead, brick it. You can't. Same hardware doesn't mean same software, there's still a difference.

martinez5241 said:
Go ahead, brick it. You can't. Same hardware doesn't mean same software, there's still a difference.
Click to expand...
Click to collapse
The Verizon image is obviously different than the non-Verizon one. That's a proven as the checksums are different. The question asked was that by loading the non-Verizon image into a Verizon Pixel, does it effectively make the phone non-Verizon since the hardware is the same?

Lets clear up some misconceptions here.
The phones ship with exactly the same image. It is not until you put in a VZ SIM do you get the different image. And it is only changes to radio and some network settings. Don't matter where you bought it, and it has nothing to do with locking.
Verizon does not lock the phone. They all ship locked including Googles. When you start it up it phones home to Google and Google decides if the phone qualifies to be unlocked. If so it unlocks. Verified with packet captures.
You will not unlock this phone without root. You will not flash anything other than OTA's without root.

If Rooted
yes on the first
NO on the second

TonikJDK said:
Lets clear up some misconceptions here.
The phones ship with exactly the same image. It is not until you put in a VZ SIM do you get the different image. And it is only changes to radio and some network settings. Don't matter where you bought it, and it has nothing to do with locking.
Verizon does not lock the phone. They all ship locked including Googles. When you start it up it phones home to Google and Google decides if the phone qualifies to be unlocked. If so it unlocks. Verified with packet captures.
You will not unlock this phone without root. You will not flash anything other than OTA's without root.
Click to expand...
Click to collapse
chazall1 said:
If Rooted
yes on the first
NO on the second
Click to expand...
Click to collapse
Since we're on the "unlockability" subject, we know that once it normal boots with a Verizon SIM, it becomes not unlockable; but does anyone know if it's because the phone contacts Verizon/Google & received "you can't unlock" command, or the baked-in factory image is pre-programmed to do this once the phone boots with a Verizon SIM?
Technically, one would just need to gain access to write to the eMMC; rooting is one way to gain such access.

AncientDeveloper said:
Since we're on the "unlockability" subject, we know that once it normal boots with a Verizon SIM, it becomes not unlockable; but does anyone know if it's because the phone contacts Verizon/Google & received "you can't unlock" command, or the baked-in factory image is pre-programmed to do this once the phone boots with a Verizon SIM?
Technically, one would just need to gain access to write to the eMMC; rooting is one way to gain such access.
Click to expand...
Click to collapse
It has nothing to do with the sim. This has been covered a million times. Some think it's the cid. Others think it's the IMEI. Either way it's nothing you can get around without temp root.

toknitup420 said:
It has nothing to do with the sim. This has been covered a million times. Some think it's the cid. Others think it's the IMEI. Either way it's nothing you can get around without temp root.
Click to expand...
Click to collapse
I don't have a Verizon Pixel to verify what you're saying, but according to this post, what you said is not true. Either way, I'm just trying to study the specifics and help the community, and I have nothing to gain or lose by either helping or not helping the community.
As mentioned, "rooting" is one way to gain access to write the system onto eMMC, unlocking bootloader is another; there may or may not be other methods. Saying one cannot get around without temp root is quite an absolute statement. And yes, I have also read most of the "million" threads.

AncientDeveloper said:
I don't have a Verizon Pixel to verify what you're saying, but according to this post, what you said is not true. Either way, I'm just trying to study the specifics and help the community, and I have nothing to gain or lose by either helping or not helping the community.
As mentioned, "rooting" is one way to gain access to write the system onto eMMC, unlocking bootloader is another; there may or may not be other methods. Saying one cannot get around without temp root is quite an absolute statement. And yes, I have also read most of the "million" threads.
Click to expand...
Click to collapse
Okay let me definitively explain this.
VZW Pixel's run the EXACT same software Google Store Pixel's that insert a VZW SIM get. The factory image you run doesn't affect your unlock ability at all.
A Google Store Pixel will update to the VZW build if a VZW SIM is inserted.
DISCLAIMER: From here down is conjecture based on my findings, reverse engineering, and things said/found around the forums.
/** begin my thoughts **/
A few things affect unlock ability (this isn't a catch all list, just from my findings):
1. Is the device SIM locked? - if yes, return grey out "Allow OEM Unlock" switch, if no, continue.
2. Is the device IMEI/MEID on approved by Google to be unlocked? - if this is met, allow "Allow OEM Unlock" to be checked, if not, continue checks.
3. Is the CID a non-unlockable CID (CID = Carried ID ex. VZW___001 on VZW sold Pixels) - if this is met (meaning that the CID is on a specific list of CID's like VZW's for example), grey out "Allow OEM Unlock", if not, allow "Allow OEM Unlock" to be checked.
If when the device connects to Google's servers it passes the above checks, the switch can be toggled.
If the switch can be toggled, you can unlock your device.
Hence why random VZW Pixels are unlockable for no apparent reason, their IMEI isn't VZW's or it doesn't have the VZW MEID (which comically is "vzwmeid"), then the CID being one of a locked device doesn't matter, because that check is never reached.
/** end my thoughts, back to cold hard facts **/
Though I may not be certain of the exact order/magnitude of the checks, the same basic principle applies, its a list of if/then statements. "Flashing an unlocked bootloader" doesn't even make sense in the context of 99% of devices. If you were on a VZW Pixel, and magically were able to flash a non-VZW generic factory image, bootloader set and all, you'd still be unable to unlock all the same.
Now, what else do we know? The device's switch can be toggled if /data/system/users/ 0.xml reports <restrictions> as "false".
This file cannot be edited without root, which many will say "...requires an unlocked bootloader...", but that isn't right.
Currently there are 3 main methods to root access:
- /system/ root - in which the SU binary is put in /system/, as /system/ already has the set-suid capability (which allows SU to actually work), this used to be the go to way, but as of DM-Verity's unveiling in Android 6.0 Marshmallow, we can't remount the system partition read/write, as the verity contexts would be changed, and the device would refuse to boot (and I haven't seen any public DM-Verity bypasses/vulnerabilities). An example of this is SuperSU installed in "System Mode". This can't be used on Locked Bootloader devices (running higher than Android 6.0 Marshmallow), because DM-Verity is enforced in the kernel (which is signature checked).
- Boot Image Root - in which the SU binary is put in the ramdisk, which has the set-suid capability (which allows SU to actually work), this was ChainFire (and later everyone else's) method to root Android 6.0 Marshmallow and beyond while respecting DM-Verity, with this method, we still can't remount the system partition read/write, as the verity contexts would be changed, and the device would refuse to boot (and I haven't seen any public DM-Verity bypasses/vulnerabilities). An example of this is SuperSU installed in "System-less Mode", or any Magisk installation. This can't be used on Locked Bootloader devices because the ramdisk is signature checked.
- Temporary Root - in which the SU binary is either put in /system/ in memory (like we saw with the DirtyCow vulnerability/exploits), or in the /data/ partition (this won't work unless we use some method to give /data/ the set-suid capability). To explain a little more, you've likely seen devices with Locked Bootloaders and /system/ write protection making use of these temp-root setups, like carrier editions of the Samsung Galaxy Note 4/5 with locked bootloaders, and of HTC phones that are S-ON/Bootloader locked. On these devices the exploit needs to be re-run after each boot (hence the "temp" part of temp-root).
The Pixel's can't be rooted with the top two methods due to the combination of DM-Verity and the bootloader being Locked. Though, temp-root can work.
All dePixel8 did was temp-root the Pixel's, remove the restrictions in that file (no proof of this one, though I believe it did), and manually set the "unlockable" bit that the "Allow OEM Unlock" sets when flipped on.
Hence why JCase (one of its creators) said "If anyone hands us a temp-root, we will release another unlock for the Pixel's.". It is literally as simple as plugging in the new temp-root exploit.
Now, the problem with finding a temp-root solution for the Pixel's is that they are one of the most secure and updated devices on the market, often getting Android's monthly security patches before any other device. What I would do it I were serious about it (and let me tell you, I am not), is surf the Android security bulletins and CVE boards for "Privilege Escalation" vulnerabilities that have public PoC's or exploits, and then either further reverse dePixel8 to figure out what bit they set, or just ask JCase, because if you can prove you have temp-root working, I'd bet he'd be friendly enough to talk it through with you. Now granted, that train of thought will only result in an unlock for a previous month's security patch level, but it is better than nothing.
As I noted above, I am not putting this here to express interest in me working on this (for those that might recognize me from my S4 research, or other security ventures), but have seen so much misinformation on these forums, and so much general misunderstanding that I felt it would be helpful to throw this out publically.
Tl;DR: Please link the confused to this post.

npjohnson said:
Tl;DR: Please link the confused to this post.
Click to expand...
Click to collapse
Thank you for your time and effort. I did not want to explain all that. I was attempting to collect information, but instead ended up explaining myself and replying replies that weren't related to the questions I asked.
Anyway, here's a minor update: According to the aboot.c code (and assuming the logic is not modified), the last byte of the eMMC controls whether the device is unlockable. Having root would be nice as it allows the user to write anything onto the eMMC, which makes this rather easy if it's a matter of overwriting one byte.

AncientDeveloper said:
Thank you for your time and effort. I did not want to explain all that. I was attempting to collect information, but instead ended up explaining myself and replying replies that weren't related to the questions I asked.
Anyway, here's a minor update: According to the aboot.c code (and assuming the logic is not modified), the last byte of the eMMC controls whether the device is unlockable. Having root would be nice as it allows the user to write anything onto the eMMC, which makes this rather easy if it's a matter of overwriting one byte.
Click to expand...
Click to collapse
Which aboot.c are you analyzing?
1. Google uses its own lock/unlock mechanism, much alike many other OEM's.
2. msm8996 uses non-standard LK, so it the public LK logic isn't necessarily what we use.

npjohnson said:
Which aboot.c are you analyzing?
1. Google uses its own lock/unlock mechanism, much alike many other OEM's.
2. msm8996 uses non-standard LK, so it the public LK logic isn't necessarily what we use.
Click to expand...
Click to collapse
Yes, in fact, the public aboot.c requires OEM implementation in order for it to work as some functions are merely defined as interfaces where OEM has to implement the actual code.
Perhaps I should've been more clear on "assuming the logic is not modified". What I meant was, if the OEM did not change the specific position of the unlock byte, this is where it'd be. Of course, there's no way to verify this without (1) obtaining the OEM aboot.c or (2) experimenting it on a device. One of the OnePlus for example, stores it at position 0x000FFE10.
This particular aboot.c is listed under quic/la from codeaurora under a late enough branch, where marlin is under.
Hope this clears things up a bit.

AncientDeveloper said:
Yes, in fact, the public aboot.c requires OEM implementation in order for it to work as some functions are merely defined as interfaces where OEM has to implement the actual code.
Perhaps I should've been more clear on "assuming the logic is not modified". What I meant was, if the OEM did not change the specific position of the unlock byte, this is where it'd be. Of course, there's no way to verify this without (1) obtaining the OEM aboot.c or (2) experimenting it on a device. One of the OnePlus for example, stores it at position 0x000FFE10.
This particular aboot.c is listed under quic/la from codeaurora under a late enough branch, where marlin is under.
Hope this clears things up a bit.
Click to expand...
Click to collapse
If you need some one to test this theory out for ya, I've got a VZW Pixel xl. I've also got a Nexus 6p I can fall back on if we "F UP" my Pixel. Plus I've brought back a lot of phones from brick. Even the Bootloader locked LG Flex. And those Flex owners thought it couldn't be done.

mattwheat said:
If you need some one to test this theory out for ya, I've got a VZW Pixel xl. I've also got a Nexus 6p I can fall back on if we "F UP" my Pixel. Plus I've brought back a lot of phones from brick. Even the Bootloader locked LG Flex. And those Flex owners thought it couldn't be done.
Click to expand...
Click to collapse
That's very brave of you. I've been exploring the possibility of using EDL (QDLoader 9008) mode to overwrite the whole eMMC with an already-unlocked image. Pixel is in an unique position to try this as all US versions share the same hardware (except marlin vs sailfish), so there shouldn't be a reason why they can't run the same image.

Shameless bump.

A question for the experts.

So now that the Z2 is out and being worked over I have a question that'll apply specifically to those of us who are still running the first gen Z Force. Is flashing the firmware from the Z2 Force able to be done onto the first gen Z Force? I was talking with some friends about doing some phone mods and this actual question was raised. Due to there being some differences right off the bat is this a feasible thing to try and do. My phone already did another forced update and is now 8.0, but if it's possible to change the phones firmware to the newer version that can be rooted would be great. I'm still learning as I go and hope I posed this correctly.

You should never attempt to flash firmware for one device onto another type of device. You're asking for a one way ticket to brick city by doing so. There are major differences between the two devices that make the software for one incompatible for the other.

phuqingA said:
So now that the Z2 is out and being worked over I have a question that'll apply specifically to those of us who are still running the first gen Z Force. Is flashing the firmware from the Z2 Force able to be done onto the first gen Z Force? I was talking with some friends about doing some phone mods and this actual question was raised. Due to there being some differences right off the bat is this a feasible thing to try and do. My phone already did another forced update and is now 8.0, but if it's possible to change the phones firmware to the newer version that can be rooted would be great. I'm still learning as I go and hope I posed this correctly.
Click to expand...
Click to collapse
Firmware runs the hardware abstraction layer. I.E. let's the software know how to send information across the chips. We have different CPU/GPU/screen/etc. It won't work if it even does flash.

Short answer: no, sorry.
Long answer: There's some ambiguity to what you refer to when you say firmware, because it can apply to many things in the boot stack, but it doesn't matter. If you could get it to flash, it wouldn't run, and if you could get it to run, it almost certainly wouldn't help you root unlock.
If you're interested in the subject and the distinctions between the different things you can call firmware, here is an elevator ramble about their functions (for OP and anyone new to the scene):
Check out this graphic here for a non comprehensive overview of what's what, what's called what, where whats sit in the boot stack and most importantly, what is firmware. If we're being so so so so so technical, The Firmware is the ROM on your snapdragon's die, who's only real job that we care about right now is to start the SBL, which is where things really get going. This firmware is called the PBL (primary bootloader) and is - quite literally - set in stone, ingrained into the die on your SoC (cpu/gpu/modem) It's pretty lax on security and once it's done its job, it hands over the responsibilities of "being firmware" to other items in the stack. Often, people casually talk about firmware to refer to anything kernel level downward, but I find this vague and hard to understand when you're getting started. OEMs like to refer to the entire stack as the device's firmware. You could make a good argument that the android/application bootloader (aboot) is the firmware since it's verifying the integrity of your boot image, manages fastboot, and is generally responsible for booting android in the first place (when you go from major android versions, like 7 -> 8, aboot generally gets an update too, and usually makes old roms not boot anymore). It's what you unlock when you "bootloader unlock" your phone. Aboot is signed, and verified by the SBL.
You push the power button -> hardware turns on, PBL runs -> PBL loads the SBL -> SBL loads aboot -> aboot loads the boot.img or recovery.img -> the boot image contains a kernel and a method to load important things into ram (like, android).
This varies by manufacturer, but most of them are variations on this process (except devices with intel processors, which are hilarious).

Thank you for the information on the primary question I posted, and for the ancillary too. I'm learning more each day and the posters here, all of you, are helping me more than you may know.
I don't know how long it's going to take me to even be close enough in knowledge on these phones as any of you are, but I am enjoying the journey.
Thank you again for the info and the continued education.