Winner, Name that Ware January 2014

February 10th, 2014

The Ware for January 2014 was a Chipcom ORnet fiber optic transceiver. Per guessed the ware correctly, and is thus the winner. Congrats, email me for your prize! And thanks again to Mike Fitzmorris for the contribution.

Make: Article on Novena

January 9th, 2014

Recently, the Make: blog ran an article on our laptop project, Novena. You can now follow @novenakosagi for updates on the project. I’d also like to reiterate here that the photos shown in the article are just an early prototype, and the final forms of the machine are going to be different — quite different — from what’s shown.

Below is a copy of the article text for your convenient reading. And, as a reminder, specs and source files can be downloaded at our wiki.

Building an Open Source Laptop

About a year and a half ago, I engaged on an admittedly quixotic project to build my own laptop. By I, I mean we, namely Sean “xobs” Cross and me, bunnie. Building your own laptop makes about as much sense as retrofitting a Honda Civic with a 1000hp motor, but the lack of practicality never stopped the latter activity, nor ours.

My primary goal in building a laptop was to build something I would use every day. I had previously spent several years at chumby building hardware platforms that I’m ashamed to admit I rarely used. My parents and siblings loved those little boxes, but they weren’t powerful enough for a geek like me. I try to allocate my discretionary funds towards things based on how often I use them. Hence, I have a nice bed, as I spend a third of my life in it. The other two thirds of my life is spent tapping at a laptop (I refuse to downgrade to a phone or tablet as my primary platform), and so when picking a thing to build that I can use every day, a laptop is a good candidate.

SONY DSC I’m always behind a keyboard!

The project was also motivated by my desire to learn all things hardware. Before this project, I had never designed with Gigabit Ethernet (RGMII), SATA, PCI-express, DDR3, gas gauges, eDP, or even a power converter capable of handling 35 watts – my typical power envelope is under 10 watts, so I was always able to get away with converters that had integrated switches. Building my own laptop would be a great way for me to stretch my legs a bit without the cost and schedule constraints normally associated with commercial projects.

The final bit of motivation is my passion for Open hardware. I’m a big fan of opening up the blueprints for the hardware you run – if you can’t Hack it, you don’t Own it.

Back when I started the project, it was me and a few hard core Open ecosystem enthusiasts pushing this point, but Edward Snowden changed the world with revelations that the NSA has in fact taken advantage of the black-box nature of the closed hardware ecosystem to implement spying measures (“good news, we weren’t crazy paranoids after all”).

Our Novena Project is of course still vulnerable to techniques such as silicon poisoning, but at least it pushes openness and disclosure down a layer, which is tangible progress in the right direction.

While these heady principles are great for motivating the journey, actual execution needs a set of focused requirements. And so, the above principles boiled down to the following requirements for the design:

  • All the components should have a reasonably complete set of NDA-free documentation. This single requirement alone culled many choices. For example, Freescale is the only SoC vendor in this performance class where you can simply go to their website, click a link, and download a mostly complete 6,000-page programming manual. It’s a ballsy move on their part and I commend them for the effort.
  • Low cost is not an objective. I’m not looking to build a crippled platform based on some entry-level single-core SoC just so I can compete price-wise with the likes of Broadcom’s non-profit Raspberry Pi platform.
  • On the other hand, I can’t spec in unicorn hair, although I come close to that by making the outer case from genuine leather (I love that my laptop smells of leather when it runs). All the chips are ideally available off the shelf from distributors like Digi-Key and have at least a five year production lifetime.
  • Batteries are based off of cheap and commonly available packs used in RC hobby circles, enabling users to make the choice between battery pack size, runtime, and mass. This makes answering the question of “what’s the battery life” a bit hard to answer – it’s really up to you – although one planned scenario is the trans-Siberian railroad trek, which is a week-long trip with no power outlets.
  • The display should also be user-configurable. The US supply chain is weak when it comes to raw high-end LCD panels, and also to address the aforementioned trans-Siberian scenario, we’d need the ability to drive a low-power display like a Pixel Qi, but not make it a permanent choice. So, I designed the main board to work with a cheap LCD adapter board for maximum flexibility.
  • No binary blobs should be required to boot and operate the system for the scenarios I care about. This one is a bit tricky, as it heavily limits the wifi card selection, I don’t use the GPU, and I rely on software-only decoders for video. But overall, the bet paid off; the laptop is still very usable in a binary-blob free state. We prepared and gave a talk recently at 30C3 using only the laptops.
  • The physical design should be accessible – no need to remove a dozen screws just to pull off the keyboard. This design requires removing just two screws.
  • The design doesn’t have to be particularly thin or light; I’d be happy if it was on par with the 3cm-thick Thinkpads or Inspirons I would use back in the mid 2000′s.
  • The machine must be useful as a hardware hacking platform. This drives the rather unique inclusion of an FPGA into the mainboard.
  • The machine must be useful as a security hacking platform. This drives the other unusual inclusion of two Ethernet interfaces, a USB OTG port, and the addition of 256 MiB DDR3 RAM and a high-speed expansion connector off of the FPGA.
  • The machine must be able to build its own firmware from source. This drives certain minimum performance specs and mandates the inclusion of a SATA interface for running off of an SSD.

After over a year and a half of hard work, I’m happy to say our machines are in a usable form. The motherboards are very reliable, the display is a 13” 2560×1700 (239ppi) LED-backlit panel, and the cases have an endoskeleton made of 5052 and 7075 aluminum alloys, an exterior wrapping of genuine leather, an interior laminate of paper (I also love books and papercraft), and cosmetic panels 3D printed on a Form 1. The design is no Thinkpad Carbon X1, but they’ve held together through a couple of rough international trips, and we use our machines almost every day.

Laptop parked in front of the Form1 3D printer used to make its body panels.

I was surprised to find the laptop was well-received by hackers, given its homebrew appearance, relatively meager specs and high price. The positive response has encouraged us to plan a crowd funding campaign around a substantially simplified (think “all in one PC” with a battery) case design. We think it may be reasonable to kick off the campaign shortly after Chinese New Year, maybe late February or March. Follow @novenakosagi for updates on our progress!

The first two prototypes are wrapped in red sheepskin leather, and green pig suede leather.

Detail view of the business half of the laptop.

Name that Ware January 2014

January 7th, 2014

The ware for January is shown below.

Thanks to my buddy Mike Fitzmorris for contributing yet another wonderful ware to this competition.

Winner, Name that Ware December 2013

January 7th, 2014

The Ware for last December 2013 is the beloved 555 timer, specifically the TLC555 by TI, fabricated in their “LinCMOS” process. I was very excited when T. Holman allowed me to post this as a ware, partially because I love die shots, and partially because the 555 is such a noteworthy chip and up until now I had never seen the inside of one.

The huge transistor on the top left is the discharge N-FET, and the distinctive, round FETs are I believe what makes LinCMOS special. These are tailor-designed transistors for good matching across process conditions, and they form the front ends of the two differential comparators that are the backbone of the threshold/trigger circuit inside the 555.

Picking a winner this time was tough — many close guesses. I’m going to name “eric” the winner, as he not only properly identified the chip, but also gave extensive analysis in his answer as well. DavidG had a correct guess very early on, but no explanation. Jonathan had the right answer, but the divider underneath the big transistor wasn’t done with resistors, it’s done with FETs, and steveM2 also was very, very close but called it a TLC551Y. So congrats to eric, email me to claim your prize.

On Hacking MicroSD Cards

December 29th, 2013

Today at the Chaos Computer Congress (30C3), xobs and I disclosed a finding that some SD cards contain vulnerabilities that allow arbitrary code execution — on the memory card itself. On the dark side, code execution on the memory card enables a class of MITM (man-in-the-middle) attacks, where the card seems to be behaving one way, but in fact it does something else. On the light side, it also enables the possibility for hardware enthusiasts to gain access to a very cheap and ubiquitous source of microcontrollers.

In order to explain the hack, it’s necessary to understand the structure of an SD card. The information here applies to the whole family of “managed flash” devices, including microSD, SD, MMC as well as the eMMC and iNAND devices typically soldered onto the mainboards of smartphones and used to store the OS and other private user data. We also note that similar classes of vulnerabilities exist in related devices, such as USB flash drives and SSDs.

Flash memory is really cheap. So cheap, in fact, that it’s too good to be true. In reality, all flash memory is riddled with defects — without exception. The illusion of a contiguous, reliable storage media is crafted through sophisticated error correction and bad block management functions. This is the result of a constant arms race between the engineers and mother nature; with every fabrication process shrink, memory becomes cheaper but more unreliable. Likewise, with every generation, the engineers come up with more sophisticated and complicated algorithms to compensate for mother nature’s propensity for entropy and randomness at the atomic scale.

These algorithms are too complicated and too device-specific to be run at the application or OS level, and so it turns out that every flash memory disk ships with a reasonably powerful microcontroller to run a custom set of disk abstraction algorithms. Even the diminutive microSD card contains not one, but at least two chips — a controller, and at least one flash chip (high density cards will stack multiple flash die). You can see some die shots of the inside of microSD cards at a microSD teardown I did a couple years ago.

In our experience, the quality of the flash chip(s) integrated into memory cards varies widely. It can be anything from high-grade factory-new silicon to material with over 80% bad sectors. Those concerned about e-waste may (or may not) be pleased to know that it’s also common for vendors to use recycled flash chips salvaged from discarded parts. Larger vendors will tend to offer more consistent quality, but even the largest players staunchly reserve the right to mix and match flash chips with different controllers, yet sell the assembly as the same part number — a nightmare if you’re dealing with implementation-specific bugs.

The embedded microcontroller is typically a heavily modified 8051 or ARM CPU. In modern implementations, the microcontroller will approach 100 MHz performance levels, and also have several hardware accelerators on-die. Amazingly, the cost of adding these controllers to the device is probably on the order of $0.15-$0.30, particularly for companies that can fab both the flash memory and the controllers within the same business unit. It’s probably cheaper to add these microcontrollers than to thoroughly test and characterize each flash memory chip, which explains why managed flash devices can be cheaper per bit than raw flash chips, despite the inclusion of a microcontroller.

The downside of all this complexity is that there can be bugs in the hardware abstraction layer, especially since every flash implementation has unique algorithmic requirements, leading to an explosion in the number of hardware abstraction layers that a microcontroller has to potentially handle. The inevitable firmware bugs are now a reality of the flash memory business, and as a result it’s not feasible, particularly for third party controllers, to indelibly burn a static body of code into on-chip ROM.

The crux is that a firmware loading and update mechanism is virtually mandatory, especially for third-party controllers. End users are rarely exposed to this process, since it all happens in the factory, but this doesn’t make the mechanism any less real. In my explorations of the electronics markets in China, I’ve seen shop keepers burning firmware on cards that “expand” the capacity of the card — in other words, they load a firmware that reports the capacity of a card is much larger than the actual available storage. The fact that this is possible at the point of sale means that most likely, the update mechanism is not secured.

In our talk at 30C3, we report our findings exploring a particular microcontroller brand, namely, Appotech and its AX211 and AX215 offerings. We discover a simple “knock” sequence transmitted over manufacturer-reserved commands (namely, CMD63 followed by ‘A’,'P’,'P’,'O’) that drop the controller into a firmware loading mode. At this point, the card will accept the next 512 bytes and run it as code.

From this beachhead, we were able to reverse engineer (via a combination of code analysis and fuzzing) most of the 8051′s function specific registers, enabling us to develop novel applications for the controller, without any access to the manufacturer’s proprietary documentation. Most of this work was done using our open source hardware platform, Novena, and a set of custom flex circuit adapter cards (which, tangentially, lead toward the development of flexible circuit stickers aka chibitronics).

Significantly, the SD command processing is done via a set of interrupt-driven call backs processed by the microcontroller. These callbacks are an ideal location to implement an MITM attack.

It’s as of yet unclear how many other manufacturers leave their firmware updating sequences unsecured. Appotech is a relatively minor player in the SD controller world; there’s a handful of companies that you’ve probably never heard of that produce SD controllers, including Alcor Micro, Skymedi, Phison, SMI, and of course Sandisk and Samsung. Each of them would have different mechanisms and methods for loading and updating their firmwares. However, it’s been previously noted that at least one Samsung eMMC implementation using an ARM instruction set had a bug which required a firmware updater to be pushed to Android devices, indicating yet another potentially promising venue for further discovery.

From the security perspective, our findings indicate that even though memory cards look inert, they run a body of code that can be modified to perform a class of MITM attacks that could be difficult to detect; there is no standard protocol or method to inspect and attest to the contents of the code running on the memory card’s microcontroller. Those in high-risk, high-sensitivity situations should assume that a “secure-erase” of a card is insufficient to guarantee the complete erasure of sensitive data. Therefore, it’s recommended to dispose of memory cards through total physical destruction (e.g., grind it up with a mortar and pestle).

From the DIY and hacker perspective, our findings indicate a potentially interesting source of cheap and powerful microcontrollers for use in simple projects. An Arduino, with its 8-bit 16 MHz microcontroller, will set you back around $20. A microSD card with several gigabytes of memory and a microcontroller with several times the performance could be purchased for a fraction of the price. While SD cards are admittedly I/O-limited, some clever hacking of the microcontroller in an SD card could make for a very economical and compact data logging solution for I2C or SPI-based sensors.

Slides from our talk at 30C3 can be downloaded here, or you can watch the talk on Youtube below.

Team Kosagi would like to extend a special thanks to .mudge for enabling this research through the Cyber Fast Track program.