[Google Pixel XL Questions & Answers] npjohnson:
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.