Edit: Step-by-step replication instructions for the skeptical experimenter.

This article is a review of what I have been able to discover regarding the Google H1, aka Cr50, aka the "G Chip", found in all Chromebooks of recent manufacture, including the Asus C101PA, my current candidate for a full delousing attempt.

To my knowledge, there has been no detailed public discussion of this NSA-imposed atrocity anywhere on the Net, aside from The Logs. This article is intended as a reference point for the aficionado, the casual explorer of pseudo-"open" hardware, and the merely curious. The Chromebooks are probably the closest thing to be had on the current market to an inexpensive, portable, and "cleanable" computer with reasonable performance.

However, the Cr50 -- a recent addition to the product line -- is explicitly designed to get in the way of a full "liberation". It is an item quite similar, in purpose and scope, to Intel's "glued on with broken glass, For Your Own Good!" on-die "ME" boobytrap.

Yet, unlike Intel, Google -- in its fetishistic pseudo-openness -- appears to have published at least a portion of the source for the device's firmware, making it a somewhat more promising target for attack and demolition than Intel's equivalent CPU-integrated turd. But we will dig deeper into this, further below. First, let's review the "big picture":

The Cr50 device is a classic "Fritz chip" -- i.e. a hardware "policeman", built into a computing device (typically, though not always, a consumer product), so as to specifically and deliberately act against the purchaser's interests, by subverting the Laws of Sane Computing in these three ways:

1. Prevention of the full control of the machine by its physical owner, typically by inhibiting attempts to install modified firmware. This practice is also known as "Tivoization", and is often justified to the gullible under the banner of "security".
2. Enablement of one or more types of "NOBUS" back door (Official NSA terminology! "No One But US", a kind of NATO Reich "Gott Mit Uns" motto.) In practice this means that the folks with the magic keys, can trivially circumvent any and all protection mechanisms on the box, locally and often remotely; while the uninitiated -- including the person who bought and paid for the hardware -- typically remain unaware of the backdoor's very existence.) A Fritzed machine serves its true master -- USG -- first, and only secondarily serves the hapless purchaser.
3. Last but not least: prevention of a clueful hardware owner's attempts to "jailbreak" -- to disable, remove, or circumvent the Fritz chip itself. Often there is an attempt to conceal the very existence of the mechanism. (Google is peculiar in that it is fond of deliberately, if subtly, taunting the purchaser of its pseudo-open devices with the existence of its Fritz chip.) Perpetrators will often deliberately litter the Net with disinformation regarding the nature and purpose of the Fritz chip, in an effort to discourage circumvention and spur on sales; the chumps will "buy their own cross" while there is still a semblance of choice on the market; afterwards, the choice evaporates, and only Fritz-laden products remain available. The latter process has already run its course in the x86 PC world; and is verging on completion in the low-power ARM portable market.

So, back to the Cr50: this device appears to be present in all of the currently-produced Chromebooks, and is -- per the vendor's published source -- able to rewrite all firmware, under the control of an external debug snake, or other, yet-undiscovered triggers; start and stop the CPU; master the I2C bus, on which, among other things, are to be found the sound card's microphone; upgrade its own firmware; and other interesting things that may or may not align with the machine owner's wishes at a particular moment. Possible usage scenarios include, but are not limited to, enablement of "lol enforcement" surreptitious searches and buggings of "borrowed" machines (and this is merely one obvious scenario.)

In re "glue with broken glass", the machine owner cannot simply remove or cut the traces to the Cr50: it has been placed in control of power supply bringup; the valuable debug interface; and other essentials.

But it is the upgrade process in particular that interests me, as it is the locked gate to potentially neutering the boobytrap. But can the end user rewrite the Cr50 firmware?

Let's begin with the disinfo! A Google employee informed me that "nobody has the cr50 key". Is this actually true?

How about No?

From the horse's mouth:


static const uint32_t LOADERKEY_A[RSA_NUM_WORDS + 1] = {
0xea54076f, 0xe986c871, 0x8cffffb4, 0xd7c50bda, 0x30700ee0, 0xc023a878,
0x30e7fdf8, 0x5bb0c06f, 0x1d25d80f, 0x18e181f7, 0xfbf7a8b0, 0x331c16d4,
0xeb042379, 0x4cef13ec, 0x5b2072e7, 0xc807b01d, 0x443fb117, 0xd2e04e5b,
0xcb984393, 0x85d90d9d, 0x0332dcb8, 0xd42ccacf, 0x787e3947, 0x1975095c,
0x2d523b0b, 0xf815be95, 0x00db9a2c, 0x6c08442b, 0x57a022bb, 0x9d5c84ed,
0x46a6d275, 0x4392dcf8, 0xfa6812e3, 0xe0f3a3e6, 0xc8ff3f61, 0xd518dbac,
0xbba7376a, 0x767a219a, 0x9d153119, 0x980b16f8, 0x79eb5078, 0xb869924d,
0x2e392cc2, 0x76c04f32, 0xe35ea788, 0xcb67fa62, 0x30efec79, 0x36f04ae0,
0x2212a5fc, 0x51c41de8, 0x2b0b84db, 0x6803ca1c, 0x39a248fd, 0xa0c31ee2,
0xb1ca22b6, 0x16e54056, 0x086f6591, 0x3825208d, 0x079c157b, 0xe51c15a6,
0x0dd1c66f, 0x8267b8ae, 0xf06b4f85, 0xc68b27ab, 0x31bcd5fc, 0x34d563b7,
0xc4d2212e, 0x1e770199, 0xaf797061, 0x824d4853, 0x526e18cd, 0x4bb8a0dc,
0xeb9377fe, 0x04fda73c, 0x2933f8a6, 0xe16c0432, 0x40ea1bd5, 0x9efcd77e,
0x92be9e55, 0x003c1128, 0x48442cf9, 0x80b4fb31, 0xfe1e3df3, 0x1d28e14d,
0xe99c0f9d, 0x521d38c2, 0x0082c4f1, 0xcff25d56, 0x0d3e7186, 0xe72b98f0,
0xefaa5689, 0x74051ed5, 0x6b7e7fff, 0x822b1944, 0x77a94732, 0x8d0b9aaf,
0x7a8ee958
};

const uint32_t LOADERKEY_B[RSA_NUM_WORDS + 1] = {
0xeea8b39f, 0xdfa457a1, 0x8b81fdc3, 0xb0204c84, 0x297b9db2, 0xaa70318d,
0x8cd41a68, 0x4aa0f9bb, 0xf63f9d69, 0xf0fe64b0, 0x96e42e2d, 0x5e494b1d,
0x066cefd0, 0xde949c16, 0xc92499ed, 0x92229990, 0x48ac3b1a, 0x1dfc2388,
0xda71d258, 0x826ddedf, 0xd0220e70, 0x6140dedf, 0x92bcdec7, 0xcdf91c22,
0xaa110aed, 0xc371c2f9, 0xa3fedf2a, 0xfd2c6a07, 0xe71aabce, 0x7f426484,
0x0ac51128, 0x4bab4ca2, 0x0162d0b9, 0x49fef7e3, 0xeda8664e, 0x14b92b7a,
0x0397dbb7, 0x5b9eb94a, 0x069b5059, 0x3851f46b, 0x45bbcaba, 0x0b812652,
0x7cd8b10b, 0xcaeccc32, 0x0ffd08e3, 0xfe6f0306, 0x8c02d5f7, 0xafdc4595,
0xe0edda47, 0x0cc821db, 0x50beeae5, 0xb9868c18, 0xefd2de11, 0xdfecd15c,
0xa8937a70, 0x223d9d95, 0x1b70848b, 0x54fa9176, 0x8bf012ef, 0xd37c1446,
0xf9a7ebeb, 0xbf2dfa9a, 0xdc6b8ea0, 0xe5f8bc4d, 0x539222b5, 0x192521e4,
0xe7088628, 0x2646bb56, 0x6fcc5d70, 0x3f1cd8e9, 0xae9cec24, 0xf53b6559,
0x6f091891, 0x5342fa61, 0xbfee50e9, 0x211ad58a, 0xd1c5aa17, 0x252dfa56,
0x17131164, 0x4630a459, 0x2f681f51, 0x3fb9ab3c, 0x6c8e0a70, 0xa34a868b,
0xe960e702, 0xa470d241, 0x00647369, 0xa4c25391, 0xd1926cf9, 0x5fce5488,
0xd171cb2e, 0x8a7c982e, 0xc89cbe39, 0xc0e019d8, 0x82cd1ebe, 0x68918fce,
0x5ec138fd
};


Anyone with the private factors to either RSA modulus, can reflash the Cr50 firmware trivially, via the debug cable. The vendor's flash update utility accepts any candidate update that passes the board revision and version increment check; however, the update will be written to a temporary buffer, and RSA-signature-tested prior to being copied into the "read only" (i.e. active) partition of the flash. Got the key? reflash to your heart's delight. No key? no update. Just like in other "Tivos", e.g., the Apple iPhone, but in this case with an extra helping of Open Sores artificial flavouring!

But this is not even the only backdoor: there are at least two. The second one known to me thus far is the "RMA unlocker". Anyone with access to a certain elliptic key can reset the Cr50 into a manufacturing test mode, and do whatever he likes.

Google even seems to offer an accidentally-"public" API for requesting this type of reset. Let's try it and see what happens:


$ python cr50_rma_open.py -g -i "BOB E25-A6A-A7I-E9Q-A4R"
Running cr50_rma_open version 2
SERIALNAME: 02034029-90EBD060
DEVID: 0x02034029 0x90ebd060
testing /dev/ttyUSB0
sysinfo
Reset flags: 0x00000800 (hard)
Reset count: 0
Chip: g cr50 B2-C
RO keyid: 0xaa66150f(prod)
RW keyid: 0xde88588d(prod)
DEV_ID: 0x02034029 0x90ebd060
Rollback: 2/2/2

ABXFG CMDAD UJFPQ 7J8MQ
UUSTG XGTRT VJ6Z5 48PWC
8AGMG T2QJ4 BT3TW 4HJVU
4XLPA SB4GE 78RSB KYEHC
RLZ: ASUO
CHALLENGE: ABXFGCMDADUJFPQ7J8MQUUSTGXGTRTVJ6Z548PWC8AGMGT2QJ4BT3TW4HJVU4XLPASB4GE78RSBKYEHC
HWID:BOB E25-A6A-A7I-E9Q-A4R
GOTO:
https://www.google.com/chromeos/partner/console/cr50reset?challenge=ABXFGCMDADUJFPQ7J8MQUUSTGXGTRTVJ6Z548PWC8AGMGT2QJ4BT3TW4HJVU4XLPASB4GE78RSBKYEHC&hwid=BOB
E25-A6A-A7I-E9Q-A4R
If the server fails to debug the challenge make sure the RLZ is
whitelisted


Sadly, the result of loading this URL was... a GMail login prompt. So I log in with a GMail account, and get:

Failed to start authentication.

Quod licet Iovi, non licet bovi! or what exactly did you expect?

And so, dear reader, if you know how to disable this landmine -- or are merely interested in advancing the state of the art in vermin removal -- join us on #trilema! (Ask one of the speaking folks, for voice.)

To be continued.