Optimizing Software With Zero-Copy And Other Techniques

An important aspect in software engineering is the ability to distinguish between premature, unnecessary, and necessary optimizations. A strong case can be made that the initial design benefits massively from optimizations that prevent well-known issues later on, while unnecessary optimizations are those simply do not make any significant difference either way. Meanwhile ‘premature’ optimizations are harder to define, with Knuth’s often quoted-out-of-context statement about these being ‘the root of all evil’ causing significant confusion.

We can find Donald Knuth’s full quote deep in the 1974 article Structured Programming with go to Statements, which at the time was a contentious optimization topic. On page 268, along with the cited quote, we see that it’s a reference to making presumed optimizations without understanding their effect, and without a clear picture of which parts of the program really take up most processing time. Definitely sound advice.

And unlike back in the 1970s we have today many easy ways to analyze application performance and to quantize bottlenecks. This makes it rather inexcusable to spend more time today vilifying the goto statement than to optimize one’s code with simple techniques like zero-copy and binary message formats.

Continue reading “Optimizing Software With Zero-Copy And Other Techniques”

MSP430-Based CTF Hardware Hacking Challenge

Hardware 'Flag'

Hacking conferences often feature a Capture the Flag, or CTF event. Typically, this is a software hacking challenge that involves breaking into targets which have been set up for the event, and capturing them. It’s good, legal, hacking fun.

However, some people are starting to build CTFs that involve hardware hacking as well. [Balda]’s most recent hardware hacking challenge was built for the Insomni’hack 2014 CTF. It uses an MSP430 as the target device, and users are allowed to enter commands to the device over UART via a Bus Pirate. Pull off the exploit, and the wheel rotates to display a flag.

For the first challenge, contestants had to decompile the firmware and find an obfuscated password. The second challenge was a bit more complicated. The password check function used memcpy, which made it vulnerable to a buffer overflow attack. By overwriting the program counter, it was possible to take over control of the program and make the flag turn.

The risk of memcpy reminds us of this set of posters. Only abstaining from memcpy can 100% protect you from overflows and memory disclosures!