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:

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

found device /dev/ttyUSB0

DEVICE: /dev/ttyUSB0

RMA support added in: 0.3.3

Running Cr50 Version: 0.3.4

RLZ: ASUO

Cr50 setup ok

ccd: Restricted

wp: enabled

rma_auth output:

rma_auth

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.