yashsingh1/xdaforums huggingface dataset:
[Google Pixel 3 Questions & Answers] DragonFire1024:
All right now that my mind has had some time away from the PC where I can actually clear my mind and think about things, I've put it all together, at least in thought and let me try to explain what we have here. This is a fluke if there ever was one. And I think there are only two reasons why, for the moment we have this working in our favor. One which in my opinion is a bug in one of its severest forms. The second maybe not so much, but the fact we have access through uart, is a bug in of itself, at least on a locked it device. But pretty much why I think this is going to 100% work is because of a single reason that really should not even happen. When citadel resets the bootloader value also is reset, from 1 a locked state, to a unlocked state. If I had to guess why probably waiting for <request>, or as the Embedded Controller, the console which I figured out why I am unable to access, but is an entirely different thing altogether, some kind of challenge and response in order for some kind of unlocking process to happen. Since we obviously do not have one when the device is rebooted into a normal state, that bootloader value changes back to 1. You can test this by resetting citadel, reboot the device normally, and reboot back into bootloader and run citadel state. Stay in ap_fastboot, value persists 0. That's where the embedded controller comes in:

This software includes a lightweight, multitasking OS with modules for power sequencing, keyboard control, thermal control, battery charging, and verified boot.

EC has the ability to disable write protect, in our case AVB. Or at least we have the ability to do so in EC. Looking in the hex editor there is no doubt about it. I'm almost certain that once resetting citadel takes place everything goes to s***, so to speak. The machine called actually translate the process quite well for being machine code and quite a bit of it is in readable format. It is clear that AVB gets disabled. That is the golden ticket. But now how....
[Google Pixel 3 Questions & Answers] DragonFire1024:
Sorry if this doesn't make any sense guys. I'm going to write down a detailed way on how everybody can at least get this far without having to worry about any destruction to their devices or whatnot. That will hopefully give a better understanding as to what might be going on here and we can work from there. I would also appreciate it if somebody could take a look at the vendor image while mounted and pull the files and question and use a hex editor to look at the code and see if what I'm seeing isn't just some crazy talk. This may take me a few days to put together so I may not be around as I do that but will try and reply if anyone has any more questions.
[Google Pixel 3 Questions & Answers] DragonFire1024:
I am on my way to work and I just noticed that there was a system update issued. My advice would be NOT to take the new system update. At least not yet until I can get everything together and see what we have. There's a good possibility this system update might fix everything that I have just done. This probably only applies to those who are on the preview of Android 12
[Google Pixel 3 Questions & Answers] DragonFire1024:
I haven't had time to sit down and write out anything detailed yet. So I've just been trying to progress further and I have. But just one step 🤣

I have gotten the tools to finally at least try and establish a connection to the console, and it recognizes the device serial number. However it fails to read the device board name. And that's where it stops, so far.

As I continue reading and I'm trying things out I still have not come any closer to figuring out why this is all being done through citadel. Or at the very least why citadel handles the capabilities to turn 'suzyq' on and off. No keys are exchanged as there are with ADB so I'm not sure why it handles it.

Secondly I'm 100% sure I'm going to be the only one able to test any of my theories because these consoles are not accessible without the proper debugging cable. I have already tried various methods of flashing a bin file in fastboot, even using 'fastboot flashing unlock_bootloader ec.bin' which does not work and returns 'Invalid argument'. That's a little bit intriguing because it doesn't tell me I can't flash anything on a locked device, which is what I expected it to say.
[Google Pixel 3 Questions & Answers] ipdev:
Keep up the good work.

You know more about this than I do. :D

As for flashing unlock binfile, normally the binfile is a custom unlock bin for the device.

Do you have the option to toggle OEM unlock under Settings-> Developer options ?

I am not sure but, I think that setting needs to be allowed before you can flash an unlock bin file.

If you can get the console connection to work and able to push bin/img files to the partitions manually, you might need a full set (or at least some) of Google bin/img files.

Including the proprietary binary/image files not included in the factory rom/update.

I run fedora so, I am not sure if I can port (or ports exist) the tools you are using.

I pulled standalone-hdctools but, I have not had time to look into it more.

I do not have a Pixel 3 (Google or Verizon) so I can not help too much but, I have a cable and a Pixel 3aXL, 4a and 5 (all Google version) that I can test on.

Cheers. :cowboy:
[Google Pixel 3 Questions & Answers] DragonFire1024:
I have updated to the new edition of Android 12 using ADB side load. About a day later I lost functionality of my SIM card. I have not gotten working yet and will probably have to factory reset and that's the last option before getting a new SIM card. Watching the screen in fastboot afterwards, I noticed yet again the slots have changed. Went from booting slot A to booting in slot B. So what commands is Google using to change slots?
[Google Pixel 3 Questions & Answers] DragonFire1024:
Well it looks like I got the embedded controller console to open but I'm not sure it is pointing at my device. I'm going to have to see where the values are being pointed to in this case it's /dev/pts? I may be missing part of the path there but I'm not at home right now but the screen did open up and confirmed the embedded controller was console open.
[Google Pixel 3 Questions & Answers] DragonFire1024:
So I figured out the issue I have with my SIM card. I have many useless SIM cards laying around. So I took one and decided to perform a test. Inside the settings menu, or the phone menu, I can't be specific as to which one because those settings will change based on availability in your area on the SIM card place in your phone. In this case it was the toggle to turn on Wi-Fi calling. Turning that toggle on it will take approximately a minute or so for the device to make an attempt to provision the SIM card for Wi-Fi calling. It will fail and in doing so pretty much erases the SIM card entirely including all of its data on what carrier it was with the phone number and any contact associated with it. It essentially corrupts the SIM card into a state where it is no longer readable by any device and is unrecoverable. So if you come across that setting inside your phone and it is toggled off it is best to keep it that way otherwise it failed provision will cause that SIM card to be permanently corrupted.
[Google Pixel 3 Questions & Answers] DragonFire1024:
Oh boy. So I found out what ec.bin is...this could very well be the smoking gun. Apparently, the ec.bin file I have been looking at DOES contain high-level keys. turns out, ec.bin is the file/binary responsible for upgrading the citadel firmware! And I found the source difference that tells us how this firmware is 'upgraded.' I use quotes, because we want exploit a file in order to write to the device in some form, and this tells us how we can do exactly that (at least how to write the file to device). You *absolutely need* the suzyq cable or a makeshift one for some of this script, there is no question about it. However, since we have OEM access to citadel, this maybe accomplished that way by staging the file. The process is done through ADB (says ADB root, but with OEM access, may not need root or the cable) and fastboot. Possible we can:

Here is some of the script where the ec.bin file is 'staged' in fastboot to reset the device:

# Reset the device.
adb -s $PHONE reboot-bootloader || true
cat ../../../prebuilts/locked_loaders/*$PHONE* \
blob-v1.ec.RW_A.hex.signed blob-v1.ec.RW_B.hex.signed > /tmp/ec.hex
../../../prebuilts/linaro/4.9/arm-none-eabi-gcc/bin/arm-none-eabi-objcopy \
-I ihex -O binary --gap-fill=0xff --pad-to=0xc0000 \
/tmp/ec.hex /tmp/ec.bin
../../../core/nugget/util/rescue2/bin2rec /tmp/ec.bin /tmp/ec.rec
fastboot stage /tmp/ec.rec
fastboot oem citadel rescue
fastboot reboot -w
adb -s $PHONE wait-for-device
adb -s $PHONE root
adb -s $PHONE shell /vendor/bin/hw/citadel_updater --suzyq 1 || true
adb -s $PHONE shell /vendor/bin/hw/citadel_updater -v || grep red_v0.0.7669-d7a39373f
[Google Pixel 3 Questions & Answers] DragonFire1024:
Well I have found out what set me off in a frenzy in the first place. This is why I got excited when I saw what appeared to be AVB being turned off. I haven't been so sure of that lately until today.

Has anyone heard of an 'avbApp?' well if you haven't you're not the first one. Because I haven't. According Google source code, an avbApp is responsible for everything I saw in regards to AVB. It is an actual application that communicates with parts of the Citadel including 'oemlock'. And yes this application does ask or communicate with Citadel in what appears to be unlocking the bootloader. More can be found in this link by navigating to the various folders. In them are source code files that Define the functions of this application and it's Communications with Citadel. Here's where our little console comes in:

I don't think it's an ec console anymore. I think this is how this application communicates with Citadel and for some reason, maybe this is supposed to happen maybe it's not I do not know, we happen to find ourselves in the console that these applications communicate to Citadel with. I say that because what is supposed to equal 'servo' in a chromium OS chroot, we see it replaced with 'proto2', or so I thought. It seems Proto is its own console:

When you open the console that we already have, it says 'nugget' next to some of the logs that pop up.

🤔
[Google Pixel 3 Questions & Answers] DragonFire1024:
Just thought I would make a note of this. Screwing around I was testing with some of the script I posted above. We have access to at least one key store, but I'm not entirely sure what keys they contain. But you can run these commands in a shell where $PHONE = DEVICE serial number (-s xxxxxx)

+adb -s $PHONE shell /system/bin/keystore_cli_v2 delete-all
+adb -s $PHONE shell /system/bin/keystore_cli_v2 list
+adb -s $PHONE shell /system/bin/keystore_cli_v2 generate \

And if I'm reading the source code correctly regarding this AVB application, we may have access to a few more others.

I'm going to be honest here I'm a lot more confused than I was when I started this. No I understand what this application is doing and it's purpose I'm trying to understand how we are in this position and how we're able to get there. If we are literally patched into this environment, then I have to be missing something. Otherwise this, the console we can open (and by the looks of the source code there are a few more including the EC) doesn't make any sense. I don't know if we're in some kind of testing environment or if we're actively exploiting an open console we shouldn't even be having access to in the first place. Though we may not be running any actual exploit the fact we're actually opening this shell in the first place might be the first level of it. But I honestly don't have a clue anymore. But this application does have the ability to perform several unlocking functions including but not limited to carrier unlocking, device unlocking, bootloader unlocking, AVB controller... If this device is booted and we can still have it with this console open then there has to be some way an application can interact with it to perform some kind of unlocking. Because the regular application cannot interact with the device while it is in fastboot.

At this point I'm going to start begging for some more information because I'm approaching a dead end here in terms of what I might be able to do at this point. Unless we can actively exploit this console or any of the others, creating applications is not even something I can comprehend. I just take stuff apart and put it back together and make it work better if I can. If you build the application I'll rip it apart and tell you what it does but it took me forever just to build a ROM, much less an application from it, but give me a binary file and I can find a couple of characters or a couple of lines of code that might unlock a device LOL.
[Google Pixel 3 Questions & Answers] MURFLY:
Google Pixel 3 - Прошивки - 4PDA

Google Pixel 3 - Прошивки

4pda.to
[Google Pixel 3 Questions & Answers] DragonFire1024:
Sorry but I can tell you without even trying that this won't work. Any 'fastboot flashing' command will fail. If anything is to be flashed it will have to be through alternative measures inside any one of these consoles if we can get it working properly. Otherwise there will be no other possible way to write a file of any kind to the device without it failing miserably.

Well my pixel three is ready for testing because I have already gotten my Pixel 4a yesterday. Unlocked, TWRP, magisk, Xposed, and The one thing that makes me happiest is the fact that Google pay and tap and pay still work. Safety net is in the green 👍
[Google Pixel 3 Questions & Answers] DragonFire1024:
All right so I moved over to my Windows machine on Windows 7, because I needed to install some drivers in order for my PC to talk to the device while in EDL mode. I have no other choice because Linux reads drivers from the Windows partition and then copies them over at Boot. I had noticed something that I was not noticing with Linux. The two devices came up in the device manager. The one that it really is, pixel 4/3. But the second device is what made me raise an eyebrow. It's listed as proto2. I didn't look around at it enough to see if I could access any file storage or communicate with it through a command line I just noticed it and I was rebooting it over to Linux when I saw it. Not sure it means anything but it is definitely interesting.
[Google Pixel 3 Questions & Answers] muhammad42620:
Fascinating, I guess you could use a console to connect to the said "proto2" device?
[Google Pixel 3 Questions & Answers] DragonFire1024:
I would presume yes. I mean assuming it would act like any other standard Android device then you should be able to run some commands through a terminal in theory. I have not tried yet and I'm looking eager to doing so when I get home though. I seem to be having better luck running some tools run on windows and others running better on Linux. But I did find it interesting that it emulated as an actual device as opposed to something else. There might be a problem here though. It could not find a driver for the device and without being able to somehow identify it, then it might be a crapshoot. However I have a sneaky suspicion that we might be able to hunt down a driver for what's emulated in Linux which is Vendor: 18d1, ID: 5014.

On my Pixel 4 which I'm trying to get more information out of because it is unlocked and rooted the emulated device in Linux is also 18d1:5014. It seems for whatever proto2 is, that vendor ID and product ID seem to be standard amongst the pixel family. But as it stands I was unable to install a driver for this so-called emulated device. And I was unable to find any identifiers in a standard quick search it comes up 'unknown' for any of the properties I'm able to see.
[Google Pixel 3 Questions & Answers] muhammad42620:
Could you try installing the emulated device as a COM port so you can connect to it? It can be done via Device Manager
[Google Pixel 3 Questions & Answers] muhammad42620:
By the way we could continue on this on Telegram if you want
[Google Pixel 3 Questions & Answers] DragonFire1024:
I am trying to get it to show up in device manager again. I am not sure how I got it there in the first place. It's quite common for me to find things like that happen only once. Argh!
[Google Pixel 3 Questions & Answers] muhammad42620:
I believe you got it via EDL mode
[Google Pixel 3 Questions & Answers] DragonFire1024:
I don't know if it was at this point or not. Because I don't recall seeing it there before while having it in edl. But that's another mode I've been trying to work with some tools in.

The proto device is what this emulated whatever it is, is named. And I'm pretty sure it will be the same across all the pixels and it is the same on my pixel 3 as well as my pixel 4. If you run various commands in Ubuntu you can get a readout of the identifiers for the various devices and consoles and emulators that are operating. The only thing I've been able to surmise Proto2 means is Google's way of calling it a "prototype device" so obviously we would not really be speaking of that in the physical sense. Whatever Proto is it is tied directly into the Titan Citadel. That much I am certain of but to what capacity I have no clue. Since I wasn't expecting to see it, in this state much less on a Windows machine, I can't recall what got it there and I haven't seen it again yet, but I'm also working tonight so I didn't have much time on my hands today.

I've only gotten pretty much one good command to come out of this and actually return something that may or may not be useful and that is a command in edl mode to OEM unlock. Spits out a pretty long set of hex numbers and whatnot. Didn't get a log of it yet but I've seen it several times and I'll post it the next time I look at it. Anything else I try it detects the device but then tells me it's in a "unknown mode" and to reboot and try "adb reboot edl". Which is exactly how I got it there in the first place.
[Google Pixel 3 Questions & Answers] muhammad42620:
HHm,

Hm, if only we could find the Servo V3 or v4 cable, it supports loading a bootloader into RAM so we potentially replace the bootloader from a Unlocked Pixel 3
[Google Pixel 3 Questions & Answers] DragonFire1024:
Well there is this. When booted properly, the device is called proto2 for usb serial. Now as to what it is in edl, I don't know. I didn't have time to look.
[Google Pixel 3 Questions & Answers] Malahayiti:
Any progress here yet? All their refurbished pixels seem to be bootloader-locked as well. The interesting thing is, at least on my refurbished pixel 2, in the build.prop file ro.oem_unlock_supported is 1, sys.oem_unlock_allowed is 1, and ro.boot.flash.locked is 1.
[Google Pixel 3 Questions & Answers] Joran01:
Seems like there's no hope anymore.
[Google Pixel 3 Questions & Answers] DragonFire1024:
I can confirm that on my pixel3 the first build prop has a value of 1. The other two props of course, have a value of 0.

Sorry I have been really busy with work as we are severely understaffed so I have had very little free time to do pretty much anything.

Not sure if it has anything to do with it but maybe those build props have something to do with the Android flash tool on the web. On my Pixel 3 I was able to upgrade to Android 12 via ADB side load, and downgrade it back to the latest stable Android 11 the same way, but I had to go through a few hoops to get there.

This may be something this may be nothing. I use Nova launcher I'm sure many of you do. Without root access of course you cannot have the Google companion or discovery option that swipes across the screen unless you download the Nova Google companion APK. Interesting enough going into developer options and checking compatibility options for applications, Nova's companion application comes up with several items to toggle. Not sure what if any effect they have on a device that's locked or unlocked but figure I would throw that out there given that some of these flags look weird to me.
[Google Pixel 3 Questions & Answers] DragonFire1024:
interesting observation. I have been able to load a DSU GSI image, direct from google. That's not a surprise. What's a surprise is when you try to install a Custom DSU GSI and you get a warning verity is disabled, when the phone turns on that the "device cannot be trusted and is corrupt". Pressing the power button makes the device boot normally. I mentioned this before, but i didn't know the cause of the failed verity. Correct me if I am wrong but this isn't supposed to happen right? No image should be able to be flashed much less corrupting the verity image. So what would the explanation be here? Nonetheless, the custom DSU GSI doesn't boot while official google GSI does.
[Google Pixel 3 Questions & Answers] LakesideWiseman:
Any progress on this? I also saw THIS thread about the Verizon Pixel 4 and using DePixel with success. Anyone tried this on a 3?

I've still got my Pixel 3 XL, and I would like to get some more time out of it, but the new Pixel 6 is looking appetizing. It would be incredible if we could figure something out here because the discounts from Verizon are too appealing and I'm not switching carriers.
[Google Pixel 3 Questions & Answers] dcarvil:
See this thread on unlocking a Verizon Pixel 3. However, it seems to work only on a new, fresh out of the box phone, that has never connected to Verizon. Even then, it is not always successful.

https://xdaforums.com/t/i-just-boot...branded-pixel-3-how-is-this-possible.4267273/

It also works on a Pixel 2. I bought a new (old stock) Verizon Pixel 2 XL from Woot last month, and successfully unlocked it.

It appears the bootloader is not permanently locked until the phone connects to Verizon. After it connects, you are out of luck.
[Google Pixel 3 Questions & Answers] rolandNW:
Based on available instructions for previous versions of the pixel and pixel xl I suspect the solution is as easy as a single pm command. For example, the pixel/xl...

adb shell
pm uninstall --user 0 com.android.phone

To unlock the bootloader you then connect to wifi, load any website in chrome, toggle the oem unlock switch in developer options, then fastboot oem unlock.

for the pixel 3a/xl...

adb shell
pm uninstall -k --user 0 com.google.android.apps.work.oobconfig

Unfortunately that only unlocks the sim. But I'm sure with a few simple tweaks you can get the bootloader unlocked as well. Maybe remove sim, wipe cache, factory reset, skip all setup, don't connect wifi, run pm uninstall, try fastboot unlock. If doesn't work then connect wifi, load a site in chrome, try fastboot unlock.

refs

https://xdaforums.com/t/google-pixel-3a-xl-4-xl-verizon-sim-unlock.4081869/

https://www.androidauthority.com/unlock-verizon-pixel-bootloader-870589/