The Google H1 Fritz Chip.


Edit (January 2023):

This machine is long out of print, but NSA lackeys continue to spread "squid ink" regarding the supposed harmlessness of its Fritz chip. So, for the thick:

Yes, it's a backdoor. The CR50 bypasses any user-installed OS, and can extract arbitrary secrets from disk and memory (or silently implant "incriminating" info) via the USB debug cable, in seconds (at e.g. an airport) and you cannot cement the port -- the machine is able to charge solely via USB. You cannot desolder the CR50 or cut any of its bus lines and expect the box to boot -- Google "glued it with broken glass" by integrating the PSU controller into the CR50. And you cannot install your own firmware on CR50 without the signing key. Google, however, can silently and remotely update it with anything they like (if you are using the stock Chrome OS), and so can a physical attacker (during an airport inspection, police search, etc.), and then extract any secrets -- or immediately fill the HDD with "prohibited bits", and go on to persuade any judge or jury that you were the one who had done it.

Also note that the attack could readily be carried out via a malicious USB peripheral, and hence does not at all require a physical "borrowing" of the Chromebook.


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.)


b0

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.

This entry was written by Stanislav , posted on Saturday June 09 2018 , filed under Chumpatronics, Cold Air, Copyrasty, FritzChip, Hardware, NonLoper, Reversing, SoftwareArchaeology, SoftwareSucks . Bookmark the permalink . Post a comment below or leave a trackback: Trackback URL.

5 Responses to “The Google H1 Fritz Chip.”

  • mic says:

    Cool tiger...

  • bonechewer says:

    Regarding RK3399 laptops, you might be interested in the "Pinebook Pro".

    That link is also relevant to your interests because it also shows a data center deployment of a couple dozen of the closely related ROCKPro64 RK3399-based SBC.

    What's undesirable about these is the flakiness (see here and here for examples).

    What's desirable: detailed information and schematics are available, and there is active development.

    For the earlier RK3328, the boot ROM has been decrypted; this has not AFAIK been done for the RK3399.

    However, blobless boot of the ROCKPro64 from eMMC is documented and working so maybe decryption of the onboard ROM is not necessary to prevent the trusting trust attack.

    • Stanislav says:

      Dear bonechewer,

      After seeing the original "Pinebook" (outrageous junk that I suspect even most respectable toy stores wouldn't stock) my interest in the vendor borders on zero. (And apparently now new version, with added coil whine and sudden death? No thanks.)

      "RockPro" is interesting but the addition of the on-board flash chip makes it unsuitable for my application.

      Yours,
      -S

      • bonechewer says:

        For what it's worth, I was under the impression that the SPI flash on the ROCKPro64 could be disabled via a jumper.

        You are probably sensible to consider the hardware flakiness a showstopper, though. I will look forward to blobless boot of some other RK3399-based SBC. Seems like work is underway.

        • Stanislav says:

          Dear bonechewer,

          I settled on RK3328 for my application not only because it can "run blobless", but also from the fact that it offered the lowest, bar none, cost of effective CPU horsepower while doing so.

          Meanwhile, the movement among ARM board vendors appears to be in the opposite direction -- adding useless, IMHO, peripherals, running up the unit cost, while eschewing the one screamingly obvious missing, for serious applications, feature -- expandable RAM.

          Yours,
          -S

Leave a Reply to mic

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre lang="" line="" escaped="" highlight="">


MANDATORY: Please prove that you are human:

121 xor 100 = ?

What is the serial baud rate of the FG device ?


Answer the riddle correctly before clicking "Submit", or comment will NOT appear! Not in moderation queue, NOWHERE!