A tale of (un)bricking a $10k Microsoft Surface unit

We’ve all had that sinking feeling as a piece of hardware stops responding and the nasty thought of “did I just brick this thing?” rockets to the front of our minds. [Florian Echtler] recently experienced this in extremis as his hacking on the University of Munich’s Microsoft Surface 2.0 left it unresponsive. He says this is an 8,000 Euro piece of hardware, which translates to around $10,000! Obviously it was his top priority to get the thing working again.

So what’s the first thing you should do if you get your hands on a piece of hardware like this? Try to run Linux on the thing, of course. And [Florian] managed to make that happen pretty easily (there’s a quick proof-of-concept video after the break). He took a Linux kernel drive written for a different purpose and altered it to interface with the MS Surface. After working out a few error message he packaged it and called to good. Some time later the department called him and asked if his Linux kernel work might have anything to do with the display being dead. Yikes.

He dug into the driver and found that a bug may have caused the firmware on the USB interface chip to be overwritten. The big problem being that they don’t just distribute the image for this chip. So he ended up having to dump what was left from the EEPROM and rebuild the header byte by byte.

20 thoughts on “A tale of (un)bricking a $10k Microsoft Surface unit

  1. I have to laugh at this one. A prime example of why I reserve desktop Linux for legacy hardware. If it fries your machine (and it does have the regrettable propensity to do just that), who cares?

    1. If Linux fries your machine then your hardware is crap. You cannot rely on software to properly validate your input the same way you cannot rely on users to properly validate software’s input. Anyway, this is Microsoft branded so no wonder here.

    2. If this hardware is this easily bricked, it deserves to be bricked.
      Typical Microsoft engineering, I suspect just like all the little deliberate gottcha’s in ACPI.

      Somehow I think the LambdaTable at the EVL was more robust.

      1. Any microcontroller with integrated program memory can be bricked by setting the wrong fuses (e.g. wrong clock source setting and code protection). Total control always means you can f*** up totally.

  2. Im surprised they bave real firmware for EZ-ESB in the eprom, usually you just load it from host after USB enumeration.

  3. Somehow, I think a ‘bug’ (being a chip whose firmware can be overwritten without specific command) should be covered under Microsoft’s extensive support contract for these things.

  4. ‘Bricking’ – really?? What are you guys doing to the language?? Bricking used to mean catastrophic damage – turning the device into a brick or doorstop. I equate calling ‘whacking a couple of bytes of firmware’ bricking [sure someone was really nervous over their own destruction, but that has nothing to do with 'bricked' or 'not bricked'] with being as inaccurate as what the newzz calls ‘hacking’.
    6lz

    1. Where have you been? We’ve referred to anything that requires one to, for example, hook up their device to a serial port to recover the device as “bricking” for a few years now. We’ve done so mostly because the new definition simply seems to be “to make unusable to the average and maybe intermediate user but not necessarily everyone”.

      What’s bricked for you may be a small stumbling stone for me.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s