• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!
  • Fill out your device list and let everyone know which phones you have!    Edit Your Device Inventory

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

Search This thread
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
Reactions: Pixel 3xl

ipdev

Recognized Contributor
Feb 14, 2016
1,433
1
1,669
Google Nexus 10
Nexus 7 (2013)
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.
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:
 

Attachments

  • PXL_20210521_231753193.jpg
    PXL_20210521_231753193.jpg
    2.2 MB · Views: 25
  • Like
Reactions: Pixel 3xl
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.
 
  • Like
Reactions: Pixel 3xl and ipdev
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?
 
  • Like
Reactions: Pixel 3xl
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.

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:

Ok sorry I have been pretty busy. This is the basic rundown. From here you can pretty much navigate to a lot of information. Aside from the citadel stuff, discovering the possibilities of what we might bea ble to do, came from this link: https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/HEAD/docs/ccd.md
Current Cr50 capabilities allow read/write access to a UART on the AP and a UART on the EC, as well as a SPI interface (normally used to access the flash chips) and an I2C interface (normally used to access INAs, but may be used to flash the EC).

In the contents you can click on raw access:
Once the SuzyQ is plugged in, three /dev/ttyUSB devices will enumerate:

  1. Cr50 console
  2. CPU/AP console (RW)
  3. EC console (RW)
These tools are not made for either of our setups, we're just lucky they still work with our distros. You will need to go here and setup hdctools and ec_tools. You will have to do a lot of small tweaking in the udev files as you go until you get the proper connections. I still haven't yet, but I had made really good progress today and was extatic to see my device to show up at
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:

Here's where is a good place to get started. This tells you the basic stuff. We're going to be doing a lot of Jerry rigging, especially software wise:


A lot of this is going to be hit or miss, except for the Embedded Controller. The one benefit we have with this console is knowing that at least the pixel 3, has an ec.bin in /vendor/bin/hw (it's in the vendor image but I'm not at my PC and it's either in bin or HW). Now is a good time to download the factory images for the pixel 3 but I think your pixels will probably suffice. If you have factory images available you probably want to download the vendor image. Any basic hex editor will do at least if you just want to read the excessively long binary file just to see that it contains pretty much everything in the console that we're first going to get access to, and then some.

Here is the tool set we're pretty much going to be working from and where we've got to do a lot of rigging so to speak. A lot of the stuff just is not going to work or if it does it's going to take a bit to get it to work because it is not designed for our type of environment. With that being said the proper tweaking should get us all the ability to write a file.


Here's royal you'll figure out the amount of dependencies you're going to be missing. There are a LOT of udev files and configs. Because each device is different, they'll all need to be tweaked differently. I don't think the kind of pixel matters, this should work of them. For me, the emulated device is 18d1:5014. When you get it to persist (run lsusb in a terminal) then you are almost there. In a terminal:

Code:
usb_console -d 18d1:xxxx

X being your emulated device. I say emulated because though you are working at it from a console it is actually connected to your device this is not an emulation per se. Now after entering the USB console if a bunch of rx errors aren't scrolling across the screen every second, then just type in the terminal the word help. There is your first interactive console it's not much but it gives us the basics. I believe this is the AP console but I don't know. So one thing for sure is, it is being done in uart. Anyways that's just to get you started and it may take you a while to get it all running. But when you go to install hdctools, install The other dependency inside of it. So clone into hdctools, build and install. And then when Don don't leave the directory clone into EC, build and install. That was my latest attempt to try and get all of these files to recognize each other and I didn't have much time to look it over but there is quite a difference. So that might cut down on time significantly or it might not.

So I was able to downgrade from the Android 12 build. I think they probably implemented a way for individuals to do that, given the amount of them that may not be able to. It's a new implementation they have and it actually worked. Since you're part of the Android beta program they now have a way where you can opt out of it and within a few hours or less they will send an OTA that will downgrade you back to Android 11 I did that because I thought it would fix my SIM card and so did Google. It did not. I'll get to that in a second. Citadel OEM commands still work on this build. Maybe even more so at least in terms of the consoles we open. When you do have a good connection you're going to notice what look like button values being pressed. Those are virtual buttons and those are your debug messages. I've noticed a few instances in those debug messages where it's a little bit different than it was in Android 12. I can't paraphrase the log and I'm not going to try but it was a little bit interesting. Also through my in Denver's of trying to fix this damn sim card I did several factory resets. During that time I have never seen this before on any Android device much less Google one, one phrase came up at the end before the factory reset was finished

Code:
wiping Titan M Citadel Chip
.

I don't know if that always happened and I'm just noticing it because of the debug messages. But this actually appeared on the device screen as the factory reset was literally on its last second. I did not get a screenshot unfortunately I could not and I did not have at the time a way to take a picture. This would explain one thing though only connecting the two, I did see something similar where it seemed like the citadel chip was being erased or formatted while looking around inside EC.bin. so I'm wondering if any of the commands I might have attempted beforehand actually succeeded but also wasn't supposed to have any effect other than hoping it would actually do something.

Since then I have been seeing some weird things in the debug messages in the console that comes up every time we connect. One of them even said

Code:
brickv0.0.3:done

That's a brief paraphrase but I am also now seeing in the same console after this a lot of the log messages relating to 'avb_fastboot bl: 0' which in this case might not mean necessarily unlocked but might mean 'not in bootloader mode' but there are a few logs that did suggest that at the moment it was being printed 'bl: 0' meant unlocked. Especially at times when it seems like something is being written in very small blocks in between actions or reboots.

Anyways 'brick' is the name of the firmware for this particular citadel chip on my device. Which brings me to my next to do. I have finally gotten device 5014 to show up in /dev/Google. Also please know as you get things to work you're going to notice that they're not all worded the same. In this case there might be a different console involved here that I am unaware of called proto2, or that just could be the code name for the embedded controller in this case. But anyways in normal instances in a normal environment, proto2 = servo. The issue I have here I think is because according to any schematic I can get while in this mode there is no serial number for 5014 and I'm not sure there's an actual board in terms of the normal setup of all this. So my guess is we have to somehow implement the actual board of the device?

Anyways sorry for such a long post but this is all the time I had and I wanted to get it down because I won't be able to write back or at least be contributing a lot for the next few days because of work. I also ordered a pixel 4a directly from the Google store. Because they actually gave me a $400 line of credit to buy one without a contract. Amazon flat out denied me. So you learn a lesson in this case. You get what you pay for. And I should have went to Google in the first place and saved all this trouble. So in the next week or so this pixel 3 will become my new testing device for what we're doing here and my 4A will be my daily driver.
 
  • Like
  • Love
Reactions: ipdev and Pixel 3xl
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.
 
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.
 
  • Like
Reactions: Pixel 3xl
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:

reset the device, generate a key test, upgrade and/or test upgrade the firmware.

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

Code:
# 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
 
  • Like
Reactions: Pixel 3xl
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:

Android communicates with Nugget apps in order to implement security related HALs. Currently, those HALs are Keymaster, Weaver and OemLock.

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:

The nugget directory contains items that are shared between the host and the firmware. Those include shared headers and service protos

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

🤔
 
  • Like
Reactions: Pixel 3xl
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)

Code:
+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.
 
Last edited:
  • Like
Reactions: Pixel 3xl
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 👍
 
  • Like
Reactions: Pixel 3xl
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.
 
Fascinating, I guess you could use a console to connect to the said "proto2" device?
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.
 

muhammad42620

Senior Member
Aug 2, 2019
125
29
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.
Could you try installing the emulated device as a COM port so you can connect to it? It can be done via Device Manager
 
I believe you got it via EDL mode
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.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 1
    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.
    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.
  • 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
    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.