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.
