Use 'fastboot oem citadel' to unlock bootloader? (Verizon Pixel 3)

Search This thread
Wait for your work to find out whether the bootloader can be unlocked.

So far no luck I'm still researching on whether or not I can use hdctools for an Android device. The pixels are unique in this particular case in that they are the only devices where this cable is capable of working or at least doing any number of things a regular USB cable can't. I think I'm going to have to learn how to set up a chroot chromeOS env in the on-device sandbox. Or find out if the tools can be modified into ARM .bins and push them to data/tmp and see if we have any luck. We can get these tools to work then we can remove right protection from the chips in which the cable allows us to interact with which in turn would allow us to flash firmware to those chips and or the device itself.

Citadel' reprovision works. I staged the stock bootloader and ran the commands, but tells me citadel is already provisioned. But the good news about this is 'fastboot rma' probably works. I don't have enough information to complete the command. Whatever RMA is, it has to do with unlocking the device and you can reprovision citadel after an RMA unlock. We also have to enable uart. And during my search for more information I happen to come across a post where some of these things I speak of were already being tested and used to unlock other devices. Some of the individuals involved with those cases, I have interacted with on numerous occasions here on XDA. Unfortunately most of those times were not happy and I did not get along with those individuals. So I am reluctant to ask for their help because they'll spend a few days telling me how dumb I am before telling me what I want to know or giving me a push in the direction I should be going in but never actually giving me enough info to succeed. So now I'm stuck in a catch 22.

However things continue to get interesting. I was able, again, to switch active slots (which isn't even supposed to be possible on a locked device particularly of the Verizon variant). I still do not know how I did it or when it happened but I did notice it changed from A back to B when I was trying to load a GSI using the DSU loader and or adb. But I cannot be sure that is the cause of it. 🤷

Secondly I've done a little more research on the screenshot I posted above of the air I now receive after attempting to load a GSI. The fact that the error comes up is actually really good because something somewhere wrote something to the device in some form which from what I understand, caused the vbmeta.img to change. Now again that's not even supposed to be possible on a locked device especially of the Verizon variant. So I have actually submitted a detailed report with Google about this particular case in hopes that they may be able to give me some details.

But the fact that both of these things can be accomplished is very very surprising. And I am totally out of my comfort zone and don't even know where to begin looking to try and find the clauses of these events.

I'm sorry this was such a long post but this is pretty much stuff I've learned over the last couple of days. The cable arrived today and I started experimenting with it unfortunately I don't have any different news to report as a result. Without getting the tools properly set up I am unable to use this cable to its fullest extent and abilities. I do have a ton of links that I intend to make available but I did not have any time today to gather them all up and post them. But there are quite a few.
 
Last edited:
  • Like
Reactions: Pixel 3xl
I've tried the activity runner APK but failed, it comes up with require Android.Permission.
Yes unfortunately the only way to launch some of those activities is with elevated access usually root access. However if you can figure out the strings then you can run 'adb shell am start ...'I have tried using the ADB function and I am very awful at being able to put the strings together properly so the command fails before it even gets a chance to try and launch an activity LOL.

Just a quick side note you can download IceBox - Apps Freezer from the Play store, then remove all accounts from the device (you do not need to perform a factory reset) and you can make icebox device owner and feeze whatever system applications you want (same as disabling). You can also use this application to download app ops by Rikka and designated as the delegated device administrator and run apps without having to have root access or install xposed.
 

Pixel 3xl

Member
May 9, 2021
10
3
So far no luck I'm still researching on whether or not I can use hdctools for an Android device. The pixels are unique in this particular case in that they are the only devices where this cable is capable of working or at least doing any number of things a regular USB cable can't. I think I'm going to have to learn how to set up a chroot chromeOS env in the on-device sandbox. Or find out if the tools can be modified into ARM .bins and push them to data/tmp and see if we have any luck. We can get these tools to work then we can remove right protection from the chips in which the cable allows us to interact with which in turn would allow us to flash firmware to those chips and or the device itself.

Citadel' reprovision works. I staged the stock bootloader and ran the commands, but tells me citadel is already provisioned. But the good news about this is 'fastboot rma' probably works. I don't have enough information to complete the command. Whatever RMA is, it has to do with unlocking the device and you can reprovision citadel after an RMA unlock. We also have to enable uart. And during my search for more information I happen to come across a post where some of these things I speak of were already being tested and used to unlock other devices. Some of the individuals involved with those cases, I have interacted with on numerous occasions here on XDA. Unfortunately most of those times were not happy and I did not get along with those individuals. So I am reluctant to ask for their help because they'll spend a few days telling me how dumb I am before telling me what I want to know or giving me a push in the direction I should be going in but never actually giving me enough info to succeed. So now I'm stuck in a catch 22.

However things continue to get interesting. I was able, again, to switch active slots (which isn't even supposed to be possible on a locked device particularly of the Verizon variant). I still do not know how I did it or when it happened but I did notice it changed from A back to B when I was trying to load a GSI using the DSU loader and or adb. But I cannot be sure that is the cause of it. 🤷

Secondly I've done a little more research on the screenshot I posted above of the air I now receive after attempting to load a GSI. The fact that the error comes up is actually really good because something somewhere wrote something to the device in some form which from what I understand, caused the vbmeta.img to change. Now again that's not even supposed to be possible on a locked device especially of the Verizon variant. So I have actually submitted a detailed report with Google about this particular case in hopes that they may be able to give me some details.

But the fact that both of these things can be accomplished is very very surprising. And I am totally out of my comfort zone and don't even know where to begin looking to try and find the clauses of these events.

I'm sorry this was such a long post but this is pretty much stuff I've learned over the last couple of days. The cable arrived today and I started experimenting with it unfortunately I don't have any different news to report as a result. Without getting the tools properly set up I am unable to use this cable to its fullest extent and abilities. I do have a ton of links that I intend to make available but I did not have any time today to gather them all up and post them. But there are quite a few.
Appreciate your experiments. I think there might be some ways to solve this problem.
 
Appreciate your experiments. I think there might be some ways to solve this problem.
You know I started experimenting on this phone for no particular reason because I honestly do not have any complaints about it aside from the fact that I was misled about it being a Verizon variant. And I told myself even despite that fact I wasn't going to tinker with it and I just could not resist. I definitely think we're in some kind of rabbit hole, as one user said a few days ago. The question is is whether or not it goes anywhere I think it does but I am very inexperienced on this end of the device spectrum so I could be chasing ghosts so to speak.
 
So I've had some discussions with Google not about what I'm trying to accomplish, here but in regards to eSIM functionality. I did so because I am waiting to have service activated with Google fi. So I attempted to do so using the esim functionality. It does not work. However there is light at the end of the tunnel
Hello:
Thank you for your work.
I used
Code:
adb shell settings put global euicc_provisioned 1
to enable my Verizon Pixel 3xl's eSIM function, but this function will not work after hard reset.
And do you know how to enable this phone's cdma network function with any codes?

So I've had some discussions with Google not about what I'm trying to accomplish, here but in regards to eSIM functionality. I did so because I am waiting to have service activated with Google fi. So I attempted to do so using the esim functionality. It does not work. However there is light at the end of the tunnel. I have suspected for some time that Google does not have a clue what Verizon does to their devices once they distribute them to Verizon. So believe it or not I've actually talked to a real person in depth about eastim functionality and why it does not work on these devices and only the ones from Verizon. I was very careful in words I chose because I wanted a genuine reply instead of something generic or a stupid reply like Verizon would give me. They told me the functionality was not available on Pixel 3 devices that had a sku associated with Verizon. I then ask is it because of the hardware Verizon uses once they leave your facility or is it simply a software restriction you have no control over. I am posting their reply below. In a nutshell they essentially tell me if I've gotten this far I can probably find a way to fully activate it and it seems like if I do they won't have a problem pushing the functionality to all pixel 3 devices. But until then they don't have a clue how Verizon restricted the functionality but essentially invited me to find out how:

We only have steps to activate the e-SIM feature if it's ordered from Google Store or Google Fi. If the Verizon Pixel 3/3XL device is ordered we will only be able to recommend getting a physical Fi SIM card as we don't have details or steps if eSIM can be enabled on Verizon versions.

Your understanding is highly appreciated here.

They also noted if you write to them or if you can find the option on their page they will actually send you a physical SIM card for free. Otherwise you will have to pay $10 to get one off Amazon or other websites
 
Update:

Found this when trying to find a link between suzyq/suzyqable and citadel. https://alexbakker.me/post/mysterious-google-titan-m-bug-cve-2019-9465.html

It's not this bug the individual wrote about or the app he created that gathers the info he wanted that interests me but the error he gets:

Code:
chatty  : uid=1064(hsm) /vendor/bin/hw/citadeld identical 5 lines
12-24 16:24:20.357   806   806 E /vendor/bin/hw/[email protected]: Incorrect Citadel update password
12-24 16:24:29.466   825   825 I /vendor/bin/hw/[email protected]: Running OemLock::setOemUnlockAllowedByCarrier: 1
12-24 16:24:29.473   584   584 I chatty  : uid=1064(hsm) /vendor/bin/hw/citadeld identical 1 line

Do you see it?
Code:
/vendor/bin/hw/[email protected]: Running OemLock::setOemUnlockAllowedByCarrier: 1

I was unable to Shell into the device and copy the vendor directory and its contents onto my PC, but I was able to mount the vendor image, did sudo -i, CD into the image and copy the bins in /vendor/bin to home directory on my PC.

Is there any way we can exploit this and change this property? There are citadel files in vendor/bin/he but not the same ones mentioned in the above link. That doesn't necessarily mean anything though. Would appreciate somebody with more knowledge about these type of things to chime in. What is user and group hsm? I looked in the source code for the boot image and the service listed in one of the init files does not list the permissions of these been files as 'user root' so is there any way we can pose as hsm and instructs citadel to change this value to a 1?
 
Found a Debian based hdctools installation that works *without* having to setup a chromium based chroot. Going to take a bit to install and configure everything. If anyone is interested, the installation is here: https://gitlab.collabora.com/chromium/servod-tools

Note: even if this works for me, it won't work for you unless you have the suzyq cable or you modify an existing usb-c cable. Supposedly this cable, and when configured properly, automatically opens up consoles and uart, when connected to the device. This should only be possible if the device is unlocked *unless* you are able to enable the suzyq function without unlocking the bootloader. In this case we are able to do just that. And from what I gather, we aren't supposed to be able to enable suzyq at all.
 

Pixel 3xl

Member
May 9, 2021
10
3
Found a Debian based hdctools installation that works *without* having to setup a chromium based chroot. Going to take a bit to install and configure everything. If anyone is interested, the installation is here: https://gitlab.collabora.com/chromium/servod-tools

Note: even if this works for me, it won't work for you unless you have the suzyq cable or you modify an existing usb-c cable. Supposedly this cable, and when configured properly, automatically opens up consoles and uart, when connected to the device. This should only be possible if the device is unlocked *unless* you are able to enable the suzyq function without unlocking the bootloader. In this case we are able to do just that. And from what I gather, we aren't supposed to be able to enable suzyq at all.
If it works, could you please post a tutarial?
 
If it works, could you please post a tutarial?

So I just completed the first phase of configurations. I had to make sure my rules.d configs were right. Although they were, they were missing a few entries, but I can confirm the cable *DOES INDEED WORK!!!* It is functioning and it appears a console(s) are indeed opening upon plugging in the phone to a properly configured pc and environment. To what extent and what consoles? I do not yet know. Run this command in a terminal to monitor when Cr50 device emulation is activated on the device we are working with. If the device appears in the list (refreshes every few seconds), the device is successfully recognized, uart should be enabled aloing twith the Cr50 emulation (what we were banking on being available):

Code:
$ watch -n 1 "lsusb | grep 18d1:5014"

5014 is what the Pixel 3 is identified as while this emulation is occuring. The cable MUST be plugged into the PHONE port with the text ADBG facing UP, or the device will not be triggered into the mode we need it in (device is still booted and turned on and usable). Posted below is a screen shot when running 'lsusb' in a terminal, the PC is properly configured and the emulation is ocurring:
pixel3debug.png


I don't know if this had an effect, but depending on what fastboot mode you are in, (fastboot vs. fastbootd), the device ID changes, so I added the config to the rules.d files I have set up in /etc/udev.

Fastboot: 18d1:4ee7
Fastbootd: 18d1:4ee0

Once I did that, installed the required dependencies for hdctools cleared my cache and what not, and rebooted, all was working so far, as it should. Now time to research a little and see what I can do and where can find instructions on how to do it :D
 
Last edited:
UPDATE:

Well I can confirm UART is initialized. According to https://chromium.googlesource.com/c...b/docs/case_closed_debugging_cr50.md#ccd-open run the command:

Code:
usb_console -d 18d1:5014

Then some information should be returned according to the link above:
Code:
At the Cr50 console, use the version command to make sure you have a recent enough version to use CCD. The relevant version is either RW_A or RW_B, whichever has the asterisk next to it.

Here is what is returned when my Pixel 3 is attached with suzyq and running the usb_console command above:

Code:
:~$: usb_console -d 18d1:5014


--- UART initialized after reboot ---
[Reset cause: rdd]
[Retry count: 1 -> 0]
[Image: RW_B, 0.0.3/brick_v0.0.8279-f93f99159371.195216 update_rollback_mask: stop at 0]
[159371.195856 gpio_wiggling: AP_EL2_LOW_IRQ = 0]
Console is enabled; type HELP for help.
> [159371.238856 passthru usb]
[159371.239492 usb_init, resume 0]
[159371.606672 usb_reset, status 4801020]
[159371.695496 usb_reset, status 9028]
[159371.779716 SETAD 0x11 (17)]
rx [Errno 110] Operation timed out

I have no time to type anything and the rx error just repeats itself over and over. Not sure what to make of this...
 
  • Like
Reactions: Pixel 3xl
rebooting the device into fastboot (adb reboot-bootloader) and running the usb_console command returns this:
Code:
usb_console -d 18d1:5014
[161155.250820 gpio_wiggling: VOL_DN_L = 0]
[161155.251544 km_set_vol_dn_btn: vol_dn already set]
[161155.458140 gpio_wigglingl dn released]
[161156.020804 gpio_wiggling: PHONE_ON_L = 0]
[161157.550416 ap_reboot_actions: signaling]
[161157.550976 ap_reboot_actions: 0 done 0]
[161157.551540 ap_is_rebooting: MSM_RST_OUT_L_FALLING: ap_is_in_bootloader=1]
[161157.554112 flash_physical_write: 0x73d00, 0xec bytes]
[161157.554916 nugget_dispatch_loop: [161157.556064 flash_physical_write: 0x73c00, 0x100 bytes]
reboot seen (vol-dn: 1)]
[161157.559688 flash_physical_write: 0x73e00, 0xec bytes]
[161157.561736 flash_physical_write: 0x73d00, 0x100 bytes]
[161157.563424 gpio_wiggling: VOL_UP_L = 0]
[161157.588992 passthru off]
[161157.622916 ap_reboot_actions: signaling]
[161157.623476 ap_reboot_actions: 0 done 1]
[161157.624044 ap_is_rebooting: MSM_RST_OUT_L_RISING: ap_is_in_bootloader=1]
[161157.624980 nugget_dispatch_loop: reboot seen (vol-[161158.725452 usb_reset, status 9020]
[161158.809772 SETAD 0x21 (33)]
rx [Errno 110] Operation timed out

Again the rx error repeats over and over. Note: Unless the device is rebooted, or it's mode is switched (fastboot vs fastbootd) then the above information will NOT reappear. Instead the message referenced in the post abive this one appears:
Code:
--- UART initialized after reboot ---
[Reset cause: rdd]
[Retry count: 1 -> 0]
[Image: RW_B, 0.0.3/brick_v0.0.8279-f93f99159371.195216 update_rollback_mask: stop at 0]
[159371.195856 gpio_wiggling: AP_EL2_LOW_IRQ = 0]
Console is enabled; type HELP for help.
> [159371.238856 passthru usb]
[159371.239492 usb_init, resume 0]
[159371.606672 usb_reset, status 4801020]
[159371.695496 usb_reset, status 9028]
[159371.779716 SETAD 0x11 (17)]
rx [Errno 110] Operation timed out
 
  • Like
Reactions: Pixel 3xl
Ok so nevermin
rebooting the device into fastboot (adb reboot-bootloader) and running the usb_console command returns this:
Code:
usb_console -d 18d1:5014
[161155.250820 gpio_wiggling: VOL_DN_L = 0]
[161155.251544 km_set_vol_dn_btn: vol_dn already set]
[161155.458140 gpio_wigglingl dn released]
[161156.020804 gpio_wiggling: PHONE_ON_L = 0]
[161157.550416 ap_reboot_actions: signaling]
[161157.550976 ap_reboot_actions: 0 done 0]
[161157.551540 ap_is_rebooting: MSM_RST_OUT_L_FALLING: ap_is_in_bootloader=1]
[161157.554112 flash_physical_write: 0x73d00, 0xec bytes]
[161157.554916 nugget_dispatch_loop: [161157.556064 flash_physical_write: 0x73c00, 0x100 bytes]
reboot seen (vol-dn: 1)]
[161157.559688 flash_physical_write: 0x73e00, 0xec bytes]
[161157.561736 flash_physical_write: 0x73d00, 0x100 bytes]
[161157.563424 gpio_wiggling: VOL_UP_L = 0]
[161157.588992 passthru off]
[161157.622916 ap_reboot_actions: signaling]
[161157.623476 ap_reboot_actions: 0 done 1]
[161157.624044 ap_is_rebooting: MSM_RST_OUT_L_RISING: ap_is_in_bootloader=1]
[161157.624980 nugget_dispatch_loop: reboot seen (vol-[161158.725452 usb_reset, status 9020]
[161158.809772 SETAD 0x21 (33)]
rx [Errno 110] Operation timed out

Again the rx error repeats over and over. Note: Unless the device is rebooted, or it's mode is switched (fastboot vs fastbootd) then the above information will NOT reappear. Instead the message referenced in the post abive this one appears:
Code:
--- UART initialized after reboot ---
[Reset cause: rdd]
[Retry count: 1 -> 0]
[Image: RW_B, 0.0.3/brick_v0.0.8279-f93f99159371.195216 update_rollback_mask: stop at 0]
[159371.195856 gpio_wiggling: AP_EL2_LOW_IRQ = 0]
Console is enabled; type HELP for help.
> [159371.238856 passthru usb]
[159371.239492 usb_init, resume 0]
[159371.606672 usb_reset, status 4801020]
[159371.695496 usb_reset, status 9028]
[159371.779716 SETAD 0x11 (17)]
rx [Errno 110] Operation timed out

Nevermind the RX error. Cr50 console is open. Navigating to my hdc tools and running the usb_console command in fastboot or fastbootd returns the RX error, but I am still able to type commands. typing HELP after the usb_console command returns this (ignore the continuous scrolling of RX error. manual scroll to stop the screen and read)
Code:
Known commands:
  apfastboot     Assert POWER + VOL_DN to force the AP into fastboot
The min/default time is 20 seconds, max is 60
  board_id       Display the Board ID values
  help           Print command help
  history        Print console history
  idle           Set or show the idle action: wfi, sleep, deep sleep
  reboot         Reboot Citadel
  repo           Show the repo snapshot for this image
  sleepmask      Display/force sleep mask
  stats          Show the current syatem power stats
  taskinfo       Print task info
  timerinfo      Print timer info
  trngstats      Collect some TRNG stats
  version        Print versions
HELP CMD = help on CMD.

The first command apfastboot requires an unlocked bootloader :(

History shows your command history. I will get to repo later.

running: taskinfo:
Code:
Task Ready Name         Events      Time (s)  StkUsed    Flags
   0 R << idle >>       80000000  556.135876    80/ 512  0000
   1 R HOOKS            20000000    0.166836   120/ 640  0000
   2   NUGGET           00000000    0.286404   168/1024  0000
   3   FACEAUTH         00000000    0.000524    80/2048  0000
   4   AVB              00000000    0.008216    88/4096  0000
   5   KEYMASTER        00000000    0.026576    88/9600  0000
   6   IDENTITY         00000000    0.000224    88/1952  0000
   7   WEAVER           00000000    0.006664   240/1024  0000
   8 R CONSOLE          00000000    0.359764   448/ 576  0000
Service calls:                 1588
Total exceptions:              1589
Task switches:                 1835
Task switching started: 162202.505900 s
Time in tasks:           557.084916 s
Time in exceptions:        0.086496 s

Version:
Code:
Chip:    Google Citadel C2-PVT
Board:   0
RO_A:    0.0.3/d55cc99c ok
RO_B:  * 0.0.3/874a9517 ok
RW_A:    0.0.3/brick_v0.0.8277-61fd4bbbc ok
RW_B:  * 0.0.3/brick_v0.0.8279-f93f993f0 ok
Build:   0.0.3/brick_v0.0.8279-f93f993f0
         2021-02-04 19:23:01 wfrichar

board_id:
Code:
0x00020000 0xff000080 0xfffdffff # MP, PVT/MP

timerinfo:
Code:
Time:     0x00000025f6f75af0 us, 163057.195760 s
Deadline: 0x00000025f701b268 ->    0.677752 s from now
Active timers:

stats:
Code:
hard_reset_count            1
time_since_hard_reset       163124.847384
wake_count                  106
time_at_last_wake           162202.503892
time_spent_awake            17124.537648
deep_sleep_count            105
time_at_last_deep_sleep     162200.189768
time_spent_in_deep_sleep    146000.309736
time_at_ap_reset            162614.632272
time_at_ap_bootloader_done  ---

trngstats:
Code:
FUSE.DEV_ID: 0xd2dccd59,0x2102f007
FUSE.TRNG_LDO_CTRL: 10
FUSE.RC_JTR_OSCMAX_CC_TRIM: 40
FUSE.RC_JTR_OSCAVG_CC_TRIM: 72
FUSE.RC_TIMER_OSC48_CC_TRIM: 77
FUSE.X_OSC_LDO_CTRL: 9
FUSE.DS_COUNT: 1
FUSE.FW_DEFINED_BROM_APPLYSEC: 0xddf
TRNG.OUTPUT_TIME_COUNTER: 0x0
PHONE_ON_L: 1
VOL_UP_L: 1
VOL_DN_L: 1
PM_MSM_RST_L: 1
AP_CTDL_IRQ: 0
NETS_GOOD: 1
TEMP.RANGE: 42.625,43.375
STATS.COUNT: 10
STATS.MIN: 792
STATS.MAX: 2215
STATS.AVG: 1549
HIST(0-599): 0
HIST(600-1199): 1
HIST(1200-1799): 7
HIST(1800-2399): 2
HIST(2400-2999): 0
HIST(3000-3599): 0
HIST(3600-4199): 0
HIST(4200-4799): 0
HIST(4800-5399): 0
HIST(5400-5999): 0
HIST(6000-6599): 0
HIST(6600-7199): 0
HIST(7200-7799): 0
HIST(7800-8399): 0
HIST(8400-8999): 0
HIST(9000-9599): 0
HIST(9600-10199): 0
HIST(10200-10799): 0
HIST(10800-11399): 0
HIST(11400-11999): 0
HIST(12000-): 0

repo:
Code:
97ad30fe2da20fc0300261bc1a3cbc37b989df88 bazel_rules
3cdf3eca0d0dd70c88b4f76fb44a9999df6e872b core/dcrypto
f93f993f0a5e6ad9915a28441e48e8dfea6b9afe core/nugget
e2797a7a7763ec042ce0287bec6bc031d04de9fd host/android
5f8a04f743447950a3a1977ea87dafa2ceb2c369 host/generic
5baf30afefa6fbbc2748b2998b48dc3760b89c30 host/linux
6d6c354952307f1acb7b5bb4a38ccff9aba384bc prebuilts/clang/host/linux-x86
29c92c535f007cfc33b396e9201f8179eba07194 prebuilts/lcov
8984774a642892f25b7e353a333833ef7acb8174 prebuilts/linaro/4.9
b09cda38a63d15ec3c761d48af51e183a1393f1d prebuilts/locked_loaders
c4bcce8b73b0382a3cafca0009e303581d2d7c46 prebuilts/protoc/linux-x86
c51dd6870ac22ad6729742bcf72baf6264370fe3 prebuilts/python-virtualenv/linux-x86
53add29eb7b4eaa9e128e3ec84eac9e65cf4c986 prebuilts/python/linux-x86/2.7.5
b5ddcdd0fc5f017cba9c823de5c472f10d849e56 prebuilts/riscv-gchips-clang
fdcc9b8194be613a6f1c48eeef2871407f61223e prebuilts/riscv-gnu/stable
42e4aa4f4c041746bcc2b3427f35c928bfa3d291 repohooks
648aea1ad6c5b9937b988f3b3b0099132ce4b1ac test/jenkins
16b9e671e6223fd2fabde111b56b3d453f4b4ad9 test/system-test-harness
83c422905dd29a759b67892082bc943b04d2657d third_party/ahdlc
f5bbc56c79e4ec0653aced61219c370b87df4f75 third_party/cn-cbor
910a575cc5a204f49c2d266db546e124a04a3b7a third_party/cryptoc
6924462b9f1522d391df1491a5c7db1f3e98fcda third_party/cryptoc-bsd
e9c240dc7afc8b67c865625e675e3a5d5d7227cc third_party/libftdi
9660e1954456ccce8848c9673a08e95aef8ed3a6 third_party/libmpsse
d9b2ff3e8de040dc630fc4138b2f61be6063f4d9 third_party/nanopb
1434ce273643b2d57c23df476b7c6f8dbad82dd_party/raiden_spi
9fa2a3d9e356a1f42a6184dcf1e0508ddfa9dbfb third_party/rapidjson
7e4ee69b4d716edcda8dd21eecaa608fe494ec17 third_party/scripts
cb2de5a810df1898cd3ae47d517603b8b12371c0 third_party/tpm2
END
 
Ok I got the rx error to stop. There are so many dependencies for all of these utilities, it's a miracle I haven't screwed anything up yet.

If I can get the EC console working, that's where we can flash EC firmware. We also have EDL mode (adb reboot edl) where, if I can get it working, "Qualcomm Sahara / Firehouse Attack Client /Diag Tools": https://github.com/bkerler/edl.git

I don't know if this is something to do with my configurations not being right but for some reason Ubuntu refuses to read the existence of a device in edl mode. At least in terms of running commands, it doesn't exist. We'll need to definitely install drivers on Windows and get Ubuntu to carry them over. But the tools used for a lot of edl are available only on Windows.

But getting that to run on a Linux machine is not going to be easy so it looks like I'm going to have to boot up my Windows 7 if I'm to even try because the drivers are only able to be installed there.

I again was looking through the vendor image. Since I'm trying to access the EC console, I started to look for files related to it. There are 2 files in the vendor image: ec.bin and ec.rec. looking through both are intriguing, but the bin file even more so which I have yet to finish looking through using a hex editor. There are or at least appear to be in readable format, several strong box keys. There is one option in fast food I have yet to try, because of the lack of anything to test.
Code:
fastboot flashing unlock_bootloader <request>

Now it doesn't fail or give me a warning that I can't run the command on a locked device but it tells me to provide a bin file. I was unaware This phone had a bin file to flash when requesting a bootloader unlock. I haven't gotten enough courage to try it but wouldn't it be a son of a gun if ec.bin worked? Also I have a few different variants of fastboot that have been modified in various other forums in an attempt to bypass some of those restrictions and hoping to get commands working that normally wouldn't on other fastboots.

It probably wouldn't which brings me to the latest update overall. Those files tell me there is a EC console available. But I am having a very hard time getting it set up properly. Most of these tools when configured right will work properly if you have all the dependencies which has been the real kicker here, finding them all. If I can finally get that end of the tools working, then we can update the EC firmware with newer EC bins. And somehow using that same cosole, you can remove write protect on certain other firmwares. I know the council is active or is available because of the certain values I got in which I posted above. Some of stuff I posted above actually comes out of that console.

All we need is just that one little area to write on, that we can write to an exploit in an attempt to get root privileges if at the very least. I'm sorry I don't have any more than this for today.
 
All right so I couldn't figure out how to copy text out of the hex editor, but of the hex copied quite perfectly. I'm on my work to work right now so I can only give a brief description of what I saw in EC.bin

I have a couple of questions perhaps some of you could answer. What is Weaver? Secondly what would an 'out of bounds' have to do in this neck of the woods? Weaver erases quite a few things including, if I'm reading correctly, several certificates, or rather wipes wherever they are stored essentially leading to some kind of mismatch that says out of bounds and then proceeds to show Weaver wiping those certain areas and by the time is all said and done if I'm reading correctly AVB is somehow set to "OFF!" and I don't know what is done after that. But somehow this starts off with rebooting citadel, and why do you ask? Because resetting it changes the bootloader state to zero and that's where a lot of this starts to come in. So until I find another hex editor where I can copy the text instead of the hex, I will have to start typing it out when I get home tomorrow. I'm very much paraphrasing so please don't get too excited but this tells me a lot more about what I can do with the proper consoles open. So whatever Weaver does leads to some kind of out of bounds exception where authorization is no longer required and somehow turns something to do with AVB in the off position
 
  • Like
Reactions: Pixel 3xl
I may have a crazy but yet working theory on how all this can work. Might even have a POC in the making here.

The post will be lengthy so I'm just going to say this. There's a high probability that I am very likely to cause irreversible damage to this phone even after one shot. So long story short I think that flashing that ec.bin is the answer, but only after very specific steps are taken in order to cause the domino effect as a result of resetting citadel. Remember in the very beginning I said that resetting citadel set the bootloader value to 0. Citadel can only be reached two ways: ap_fastboot running 'fastboot oem citadel', and the usb_console via suzyq cable. As long as the device stays in ap_fastboot after resetting it, the bootloader will stay value 0. Use citadel to tenable Suzyq (idk if needed for the rest though) then flash the EC.bin 'fastboot flashing unlock_bootloader ec.bin'.

Now I do not expect flashing this bin will work, at least not how you think. With the bootloader at 0, flashing that file, regardless of anything, sets the stage for why I say 'out of bounds' which is mentioned word for word in that bin file.' that's where Weaver and the rest of it follows and ending with AVB off.

Remember those CVEs I linked? 😮
 
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:

Code:
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....
 
  • Like
Reactions: ipdev and Pixel 3xl
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.
 
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
 
  • Like
Reactions: Pixel 3xl
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.
 
  • Like
  • Love
Reactions: Pixel 3xl and ipdev

Top Liked Posts

  • There are no posts matching your filters.
  • 3
    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.
    2
    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.
    2
    I may have a crazy but yet working theory on how all this can work. Might even have a POC in the making here.

    The post will be lengthy so I'm just going to say this. There's a high probability that I am very likely to cause irreversible damage to this phone even after one shot. So long story short I think that flashing that ec.bin is the answer, but only after very specific steps are taken in order to cause the domino effect as a result of resetting citadel. Remember in the very beginning I said that resetting citadel set the bootloader value to 0. Citadel can only be reached two ways: ap_fastboot running 'fastboot oem citadel', and the usb_console via suzyq cable. As long as the device stays in ap_fastboot after resetting it, the bootloader will stay value 0. Use citadel to tenable Suzyq (idk if needed for the rest though) then flash the EC.bin 'fastboot flashing unlock_bootloader ec.bin'.

    Now I do not expect flashing this bin will work, at least not how you think. With the bootloader at 0, flashing that file, regardless of anything, sets the stage for why I say 'out of bounds' which is mentioned word for word in that bin file.' that's where Weaver and the rest of it follows and ending with AVB off.

    Remember those CVEs I linked? 😮
    2
    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:

    Code:
    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....
    2
    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:
    Sweet!

    Well after a few days of thinking, and looking over everything, I think I have this figured out, well at least some.

    The cable allows access to several consoles. hdctools and ec_tools are to help with getting the EC console running. The cable is official stuff and being sed to access devices is experimental at most. very few public details or open sourced materials to go on here. So here it goes.

    Citadel resides in Google's Titan M chip. The chip handles all cryptographic keys, biometrics, lock screen lock, and bootloader/platform/ota keys. We are trying to access the chips's firmware. In order to do so, we need to get a 'servod' server running on the device board. The server then connects and opens the Embedded Controller Console (EC), where we have an abundance of options where we can control a few things.

    In the EC, we have 'flashrom', a tool to work with the chips firmware. It can perform several commands:

    Code:
    flashrom-wrapper: Installs and runs Chromium OS flashrom or flash_ec from sources.
    Wrapper usage:
      flashrom [parameters]      # Runs flashrom, first preparing it if necessary.
      flashrom flash_ec [params] # Runs flash_ec, first preparing it if necessary.
      flash_ec [parameters]      # Same as "flashrom flash_ec" (via symlink).
      flashrom install [-f]      # Just prepares (or updates) flashrom.
      flashrom uninstall         # Removes the prepared flashrom install.
    
    flashrom unknown on Linux 4.15.0-142-generic (x86_64)
    flashrom is free software, get the source code at https://flashrom.org
    
    Usage: /home/dragon/.local/flashrom/flashrom [-h|-R|-L|
        -p <programmername>[:<parameters>] [-c <chipname>]
            (--flash-name|--flash-size|
             [-E|-x|(-r|-w|-v) [<file>]]
             [(-l <layoutfile>|--ifd|--fmap|--fmap-file <fmapfile>) [-i <region>[:<file>]]...]
             [-n] [-N] [-f])]
        [-V[V[V]]] [-o <logfile>]
    
     -h | --help                        print this help text
     -R | --version                     print version (release)
     -r | --read [<file>]               read flash and save to <file>
     -w | --write [<file|->]            write <file> or the content provided
                                        on the standard input to flash
     -v | --verify [<file|->]           verify flash against <file>
                                        or the content provided on the standard input
     -E | --erase                       erase flash memory
     -V | --verbose                     more verbose output
     -c | --chip <chipname>             probe only for specified flash chip
     -f | --force                       force specific operations (see man page)
     -n | --noverify                    don't auto-verify
     -N | --noverify-all                verify included regions only (cf. -i)
     -x | --extract                     extract regions to files
     -l | --layout <layoutfile>         read ROM layout from <layoutfile>
          --wp-disable                  disable write protection
          --wp-enable                   enable write protection
          --wp-list                     list write protect range
          --wp-status                   show write protect status
          --wp-range=<start>,<len>      set write protect range
          --wp-region <region>          set write protect region
          --flash-name                  read out the detected flash name
          --flash-size                  read out the detected flash size
          --fmap                        read ROM layout from fmap embedded in ROM
          --fmap-file <fmapfile>        read ROM layout from fmap in <fmapfile>
          --ifd                         read layout from an Intel Firmware Descriptor
     -i | --image <region>[:<file>]     only read/write image <region> from layout
                                        (optionally with data from <file>)
     -o | --output <logfile>            log output to <logfile>
          --flash-contents <ref-file>   assume flash contents to be <ref-file>
          --do-not-diff                 do not diff with chip contents
                                        (should be used with erased chips only)
          --ignore-lock                 do not acquire big lock
     -L | --list-supported              print supported devices
     -p | --programmer <name>[:<param>] specify the programmer device. One of
        internal, dummy, raiden_debug_spi, ft2232_spi, buspirate_spi, dediprog,
        linux_spi, google_ec, ec, host.
    
    You can specify one of -h, -R, -L, -E, -r, -w, -v or no operation.
    If no operation is specified, flashrom will only probe for flash chips.

    We want to hopefully disable the write-protection and verification of this chips firmware. It also has some commands for disabling or turning off AVB, Android Verified Boot. This will allow us to write to the device and other parts of the system. perhaps. Once we do that, we can theoretically update it's firmware, or perhaps on purpose, brick it. A couple years ago, an unlock exploit was found for almost all newer Amazon Tablets. The exploit, if I recall correctly, allowed us to write to a small portion of the device, in order to trip it into what is known as 'boot-rom', a mode that unless you were trying to get it there, would make it seem like the device is dead. The exploit then, on purpose, modifies the GPT partition, unlocking the device. Here is that thread. If we can get EC to fully work, we might be able to do a similar exploit by flasbrick_v0.0.8279-f93f993f0hing a fake firmware file to Titan/citadel to brick it. Oddly enough the firmware Titan operates is called 'brick_v0.0.8279-f93f993f0'. I am unable to locate this file, and I am not sure it even publicly exists. Here is a pastebin of the various connections and values of Citadel.

    Code:
    [LIST=1]
    [*]Bus 001 Device 049: ID 18d1:5014 Google Inc.
    [*]Device Descriptor:
    [*]  bLength                18
    [*]  bDescriptorType         1
    [*]  bcdUSB               2.00
    [*]  bDeviceClass            0 (Defined at Interface level)
    [*]  bDeviceSubClass         0
    [*]  bDeviceProtocol         0
    [*]  bMaxPacketSize0        64
    [*]  idVendor           0x18d1 Google Inc.
    [*]  idProduct          0x5014
    [*]  bcdDevice            1.00
    [*]  iManufacturer           1 Google Inc.
    [*]  iProduct                2 proto2
    [*]  iSerial                 0
    [*]  bNumConfigurations      1
    [*]  Configuration Descriptor:
    [*]    bLength                 9
    [*]    bDescriptorType         2
    [*]    wTotalLength           32
    [*]    bNumInterfaces          1
    [*]    bConfigurationValue     1
    [*]    iConfiguration          3 brick_v0.0.8279-f93f993f0
    [*]    bmAttributes         0x80
    [*]      (Bus Powered)
    [*]    MaxPower              500mA
    [*]    Interface Descriptor:
    [*]      bLength                 9
    [*]      bDescriptorType         4
    [*]      bInterfaceNumber        0
    [*]      bAlternateSetting       0
    [*]      bNumEndpoints           2
    [*]      bInterfaceClass       255 Vendor Specific Class
    [*]      bInterfaceSubClass     80
    [*]      bInterfaceProtocol      1
    [*]      iInterface              4 Shell
    [*]      Endpoint Descriptor:
    [*]        bLength                 7
    [*]        bDescriptorType         5
    [*]        bEndpointAddress     0x81  EP 1 IN
    [*]        bmAttributes            2
    [*]          Transfer Type            Bulk
    [*]          Synch Type               None
    [*]          Usage Type               Data
    [*]        wMaxPacketSize     0x0040  1x 64 bytes
    [*]        bInterval              10
    [*]      Endpoint Descriptor:
    [*]        bLength                 7
    [*]        bDescriptorType         5
    [*]        bEndpointAddress     0x01  EP 1 OUT
    [*]        bmAttributes            2
    [*]          Transfer Type            Bulk
    [*]          Synch Type               None
    [*]          Usage Type               Data
    [*]        wMaxPacketSize     0x0040  1x 64 bytes
    [*]        bInterval               0
    [*]Device Status:     0x0000
    [*]  (Bus Powered)
    [/LIST]
    Notice one of the 'interfaces'? A shell console. Possibly an outlet here for a root exploit of the system. Not any idea how though.

    On a locked device, there is definitely a way to change boot slots. I installed the latest OTA of android 12 a couple days ago. Prior to the update, my device was on slot B. Following the update, it was on slot A. If we can bypass the slot restrictions, we would have some limited flashing capabilities.

    Lastly, i am totally missing something here. The 4 locks that change values when toggling OEM unlock, resetting citadel sets the bootloader value to 0, and citadel controls suzyq access. So im going to go out on a limb and say it seems highly unlikely suzyq would be controlled through here unless it serves a purpose not yet known, like actually unlocking those 4 AVB locks or resetting them. There is no reason for citadel to control suzyq unless it has the ability to actually unlock the bootloader.

    So I would have to say, being able to gain access too and control Titans firmware and citadel itself, without really escalating privileges, is really astonishing and mind blowing. This level of access IMO poses a major security risk. And to think it may only just be possible because of the BUG that defaults the bootloader to 0 after citadel is reset.
  • 5
    If it works, could you please post a tutarial?

    So I just completed the first phase of configurations. I had to make sure my rules.d configs were right. Although they were, they were missing a few entries, but I can confirm the cable *DOES INDEED WORK!!!* It is functioning and it appears a console(s) are indeed opening upon plugging in the phone to a properly configured pc and environment. To what extent and what consoles? I do not yet know. Run this command in a terminal to monitor when Cr50 device emulation is activated on the device we are working with. If the device appears in the list (refreshes every few seconds), the device is successfully recognized, uart should be enabled aloing twith the Cr50 emulation (what we were banking on being available):

    Code:
    $ watch -n 1 "lsusb | grep 18d1:5014"

    5014 is what the Pixel 3 is identified as while this emulation is occuring. The cable MUST be plugged into the PHONE port with the text ADBG facing UP, or the device will not be triggered into the mode we need it in (device is still booted and turned on and usable). Posted below is a screen shot when running 'lsusb' in a terminal, the PC is properly configured and the emulation is ocurring:
    pixel3debug.png


    I don't know if this had an effect, but depending on what fastboot mode you are in, (fastboot vs. fastbootd), the device ID changes, so I added the config to the rules.d files I have set up in /etc/udev.

    Fastboot: 18d1:4ee7
    Fastbootd: 18d1:4ee0

    Once I did that, installed the required dependencies for hdctools cleared my cache and what not, and rebooted, all was working so far, as it should. Now time to research a little and see what I can do and where can find instructions on how to do it :D
    4
    Ok I got the rx error to stop. There are so many dependencies for all of these utilities, it's a miracle I haven't screwed anything up yet.

    If I can get the EC console working, that's where we can flash EC firmware. We also have EDL mode (adb reboot edl) where, if I can get it working, "Qualcomm Sahara / Firehouse Attack Client /Diag Tools": https://github.com/bkerler/edl.git

    I don't know if this is something to do with my configurations not being right but for some reason Ubuntu refuses to read the existence of a device in edl mode. At least in terms of running commands, it doesn't exist. We'll need to definitely install drivers on Windows and get Ubuntu to carry them over. But the tools used for a lot of edl are available only on Windows.

    But getting that to run on a Linux machine is not going to be easy so it looks like I'm going to have to boot up my Windows 7 if I'm to even try because the drivers are only able to be installed there.

    I again was looking through the vendor image. Since I'm trying to access the EC console, I started to look for files related to it. There are 2 files in the vendor image: ec.bin and ec.rec. looking through both are intriguing, but the bin file even more so which I have yet to finish looking through using a hex editor. There are or at least appear to be in readable format, several strong box keys. There is one option in fast food I have yet to try, because of the lack of anything to test.
    Code:
    fastboot flashing unlock_bootloader <request>

    Now it doesn't fail or give me a warning that I can't run the command on a locked device but it tells me to provide a bin file. I was unaware This phone had a bin file to flash when requesting a bootloader unlock. I haven't gotten enough courage to try it but wouldn't it be a son of a gun if ec.bin worked? Also I have a few different variants of fastboot that have been modified in various other forums in an attempt to bypass some of those restrictions and hoping to get commands working that normally wouldn't on other fastboots.

    It probably wouldn't which brings me to the latest update overall. Those files tell me there is a EC console available. But I am having a very hard time getting it set up properly. Most of these tools when configured right will work properly if you have all the dependencies which has been the real kicker here, finding them all. If I can finally get that end of the tools working, then we can update the EC firmware with newer EC bins. And somehow using that same cosole, you can remove write protect on certain other firmwares. I know the council is active or is available because of the certain values I got in which I posted above. Some of stuff I posted above actually comes out of that console.

    All we need is just that one little area to write on, that we can write to an exploit in an attempt to get root privileges if at the very least. I'm sorry I don't have any more than this for today.
    3
    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.
    3
    Ok so nevermin
    rebooting the device into fastboot (adb reboot-bootloader) and running the usb_console command returns this:
    Code:
    usb_console -d 18d1:5014
    [161155.250820 gpio_wiggling: VOL_DN_L = 0]
    [161155.251544 km_set_vol_dn_btn: vol_dn already set]
    [161155.458140 gpio_wigglingl dn released]
    [161156.020804 gpio_wiggling: PHONE_ON_L = 0]
    [161157.550416 ap_reboot_actions: signaling]
    [161157.550976 ap_reboot_actions: 0 done 0]
    [161157.551540 ap_is_rebooting: MSM_RST_OUT_L_FALLING: ap_is_in_bootloader=1]
    [161157.554112 flash_physical_write: 0x73d00, 0xec bytes]
    [161157.554916 nugget_dispatch_loop: [161157.556064 flash_physical_write: 0x73c00, 0x100 bytes]
    reboot seen (vol-dn: 1)]
    [161157.559688 flash_physical_write: 0x73e00, 0xec bytes]
    [161157.561736 flash_physical_write: 0x73d00, 0x100 bytes]
    [161157.563424 gpio_wiggling: VOL_UP_L = 0]
    [161157.588992 passthru off]
    [161157.622916 ap_reboot_actions: signaling]
    [161157.623476 ap_reboot_actions: 0 done 1]
    [161157.624044 ap_is_rebooting: MSM_RST_OUT_L_RISING: ap_is_in_bootloader=1]
    [161157.624980 nugget_dispatch_loop: reboot seen (vol-[161158.725452 usb_reset, status 9020]
    [161158.809772 SETAD 0x21 (33)]
    rx [Errno 110] Operation timed out

    Again the rx error repeats over and over. Note: Unless the device is rebooted, or it's mode is switched (fastboot vs fastbootd) then the above information will NOT reappear. Instead the message referenced in the post abive this one appears:
    Code:
    --- UART initialized after reboot ---
    [Reset cause: rdd]
    [Retry count: 1 -> 0]
    [Image: RW_B, 0.0.3/brick_v0.0.8279-f93f99159371.195216 update_rollback_mask: stop at 0]
    [159371.195856 gpio_wiggling: AP_EL2_LOW_IRQ = 0]
    Console is enabled; type HELP for help.
    > [159371.238856 passthru usb]
    [159371.239492 usb_init, resume 0]
    [159371.606672 usb_reset, status 4801020]
    [159371.695496 usb_reset, status 9028]
    [159371.779716 SETAD 0x11 (17)]
    rx [Errno 110] Operation timed out

    Nevermind the RX error. Cr50 console is open. Navigating to my hdc tools and running the usb_console command in fastboot or fastbootd returns the RX error, but I am still able to type commands. typing HELP after the usb_console command returns this (ignore the continuous scrolling of RX error. manual scroll to stop the screen and read)
    Code:
    Known commands:
      apfastboot     Assert POWER + VOL_DN to force the AP into fastboot
    The min/default time is 20 seconds, max is 60
      board_id       Display the Board ID values
      help           Print command help
      history        Print console history
      idle           Set or show the idle action: wfi, sleep, deep sleep
      reboot         Reboot Citadel
      repo           Show the repo snapshot for this image
      sleepmask      Display/force sleep mask
      stats          Show the current syatem power stats
      taskinfo       Print task info
      timerinfo      Print timer info
      trngstats      Collect some TRNG stats
      version        Print versions
    HELP CMD = help on CMD.

    The first command apfastboot requires an unlocked bootloader :(

    History shows your command history. I will get to repo later.

    running: taskinfo:
    Code:
    Task Ready Name         Events      Time (s)  StkUsed    Flags
       0 R << idle >>       80000000  556.135876    80/ 512  0000
       1 R HOOKS            20000000    0.166836   120/ 640  0000
       2   NUGGET           00000000    0.286404   168/1024  0000
       3   FACEAUTH         00000000    0.000524    80/2048  0000
       4   AVB              00000000    0.008216    88/4096  0000
       5   KEYMASTER        00000000    0.026576    88/9600  0000
       6   IDENTITY         00000000    0.000224    88/1952  0000
       7   WEAVER           00000000    0.006664   240/1024  0000
       8 R CONSOLE          00000000    0.359764   448/ 576  0000
    Service calls:                 1588
    Total exceptions:              1589
    Task switches:                 1835
    Task switching started: 162202.505900 s
    Time in tasks:           557.084916 s
    Time in exceptions:        0.086496 s

    Version:
    Code:
    Chip:    Google Citadel C2-PVT
    Board:   0
    RO_A:    0.0.3/d55cc99c ok
    RO_B:  * 0.0.3/874a9517 ok
    RW_A:    0.0.3/brick_v0.0.8277-61fd4bbbc ok
    RW_B:  * 0.0.3/brick_v0.0.8279-f93f993f0 ok
    Build:   0.0.3/brick_v0.0.8279-f93f993f0
             2021-02-04 19:23:01 wfrichar

    board_id:
    Code:
    0x00020000 0xff000080 0xfffdffff # MP, PVT/MP

    timerinfo:
    Code:
    Time:     0x00000025f6f75af0 us, 163057.195760 s
    Deadline: 0x00000025f701b268 ->    0.677752 s from now
    Active timers:

    stats:
    Code:
    hard_reset_count            1
    time_since_hard_reset       163124.847384
    wake_count                  106
    time_at_last_wake           162202.503892
    time_spent_awake            17124.537648
    deep_sleep_count            105
    time_at_last_deep_sleep     162200.189768
    time_spent_in_deep_sleep    146000.309736
    time_at_ap_reset            162614.632272
    time_at_ap_bootloader_done  ---

    trngstats:
    Code:
    FUSE.DEV_ID: 0xd2dccd59,0x2102f007
    FUSE.TRNG_LDO_CTRL: 10
    FUSE.RC_JTR_OSCMAX_CC_TRIM: 40
    FUSE.RC_JTR_OSCAVG_CC_TRIM: 72
    FUSE.RC_TIMER_OSC48_CC_TRIM: 77
    FUSE.X_OSC_LDO_CTRL: 9
    FUSE.DS_COUNT: 1
    FUSE.FW_DEFINED_BROM_APPLYSEC: 0xddf
    TRNG.OUTPUT_TIME_COUNTER: 0x0
    PHONE_ON_L: 1
    VOL_UP_L: 1
    VOL_DN_L: 1
    PM_MSM_RST_L: 1
    AP_CTDL_IRQ: 0
    NETS_GOOD: 1
    TEMP.RANGE: 42.625,43.375
    STATS.COUNT: 10
    STATS.MIN: 792
    STATS.MAX: 2215
    STATS.AVG: 1549
    HIST(0-599): 0
    HIST(600-1199): 1
    HIST(1200-1799): 7
    HIST(1800-2399): 2
    HIST(2400-2999): 0
    HIST(3000-3599): 0
    HIST(3600-4199): 0
    HIST(4200-4799): 0
    HIST(4800-5399): 0
    HIST(5400-5999): 0
    HIST(6000-6599): 0
    HIST(6600-7199): 0
    HIST(7200-7799): 0
    HIST(7800-8399): 0
    HIST(8400-8999): 0
    HIST(9000-9599): 0
    HIST(9600-10199): 0
    HIST(10200-10799): 0
    HIST(10800-11399): 0
    HIST(11400-11999): 0
    HIST(12000-): 0

    repo:
    Code:
    97ad30fe2da20fc0300261bc1a3cbc37b989df88 bazel_rules
    3cdf3eca0d0dd70c88b4f76fb44a9999df6e872b core/dcrypto
    f93f993f0a5e6ad9915a28441e48e8dfea6b9afe core/nugget
    e2797a7a7763ec042ce0287bec6bc031d04de9fd host/android
    5f8a04f743447950a3a1977ea87dafa2ceb2c369 host/generic
    5baf30afefa6fbbc2748b2998b48dc3760b89c30 host/linux
    6d6c354952307f1acb7b5bb4a38ccff9aba384bc prebuilts/clang/host/linux-x86
    29c92c535f007cfc33b396e9201f8179eba07194 prebuilts/lcov
    8984774a642892f25b7e353a333833ef7acb8174 prebuilts/linaro/4.9
    b09cda38a63d15ec3c761d48af51e183a1393f1d prebuilts/locked_loaders
    c4bcce8b73b0382a3cafca0009e303581d2d7c46 prebuilts/protoc/linux-x86
    c51dd6870ac22ad6729742bcf72baf6264370fe3 prebuilts/python-virtualenv/linux-x86
    53add29eb7b4eaa9e128e3ec84eac9e65cf4c986 prebuilts/python/linux-x86/2.7.5
    b5ddcdd0fc5f017cba9c823de5c472f10d849e56 prebuilts/riscv-gchips-clang
    fdcc9b8194be613a6f1c48eeef2871407f61223e prebuilts/riscv-gnu/stable
    42e4aa4f4c041746bcc2b3427f35c928bfa3d291 repohooks
    648aea1ad6c5b9937b988f3b3b0099132ce4b1ac test/jenkins
    16b9e671e6223fd2fabde111b56b3d453f4b4ad9 test/system-test-harness
    83c422905dd29a759b67892082bc943b04d2657d third_party/ahdlc
    f5bbc56c79e4ec0653aced61219c370b87df4f75 third_party/cn-cbor
    910a575cc5a204f49c2d266db546e124a04a3b7a third_party/cryptoc
    6924462b9f1522d391df1491a5c7db1f3e98fcda third_party/cryptoc-bsd
    e9c240dc7afc8b67c865625e675e3a5d5d7227cc third_party/libftdi
    9660e1954456ccce8848c9673a08e95aef8ed3a6 third_party/libmpsse
    d9b2ff3e8de040dc630fc4138b2f61be6063f4d9 third_party/nanopb
    1434ce273643b2d57c23df476b7c6f8dbad82dd_party/raiden_spi
    9fa2a3d9e356a1f42a6184dcf1e0508ddfa9dbfb third_party/rapidjson
    7e4ee69b4d716edcda8dd21eecaa608fe494ec17 third_party/scripts
    cb2de5a810df1898cd3ae47d517603b8b12371c0 third_party/tpm2
    END
    2
    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.
Our Apps
Get our official app!
The best way to access XDA on your phone
Nav Gestures
Add swipe gestures to any Android
One Handed Mode
Eases uses one hand with your phone