The Intel Edison is an incredibly small and cheap x86 computing platform, and with that comes the obvious applications for robotics and wearable computing. [mz] had another idea: what if the Edison could do work that is usually done by workstations? Would it make economic sense to buy a handful of Edisons over a single quad-core Xeon system?
[mz] thought the Edison would be an ideal platform for fuzz testing, or sending random, automated data at a program or system to figure out if they’ll misbehave in interesting ways. After figuring out where to solder power and ground wires to boot an Edison without a breakout board, [mz] got to work benchmarking his fuzz testing setup.
Comparing the benchmarks of a fuzzing job running on the Edison and a few servers and workstations, calculations of cost-efficiency worked out well for this tiny x86 system on module. For parallelizable tasks, the Edison is about 8x less powerful than a reasonably modern server, but it’s also about 5-8x cheaper than a comparable desktop machine. Although renting a server is by far the more economic solution for getting a lot of computing power easily, there are a few use cases where a cluster of Edisons in your pocket would make sense.
Here’s a quick prototype from [Travis Goodspeed]. It’s a smart card built around an MSP430 microcontroller. We’ve used the MSP430 in the past because of its low power demands. He says this business card currently supports 1.8V to 3.3V, but a future design will have 5V as well. Technologies like Java Card exist for running applets on smart cards, but a familiar microcontroller like the MSP430 could certainly make development much faster. Knowing [Travis], there’s a reader somewhere about to go through some serious fuzzing.
[I)ruid] from BreakingPoint Labs has been doing quite a bit of protocol reverse engineering as part of his work. He put together a post covering some of the tools that have been useful for this task. Text-based protocols have a lot of human readable characters that can help you identify fields. Binary protocols don’t have this luxury though. He recommends the Protocol Informatics Project for tackling these situations. It applies bioinformatics algorithms to network traffic. You give it a packet dump of the protocol and it compares them to find similarities the same way genetic sequences are compared. It can be confused by protocols that waste a lot of space, but it’s still a very clever approach to reversing.
Which is a better method for finding vulnerabilities, fuzzing or static-code analysis? The question will be put to the test at next month’s Black Hat USA conference, where two experienced
hackers security researchers will be given a piece of mystery code and one hour to find all the vulnerabilities they can using one of the two methods. [Charlie Miller] from Independent Security Evaluators will use fuzzing and [Sean Fay] from Fortify Software will use static-code analysis to detect the vulnerabilities in the code. We reported on [Miller]’s fuzzing talk while at Toorcon 9.
The pair will be allowed to use their own equipment, but they won’t see the code until the moment the showdown begins. For an added bit of fun, conference attendees are welcome to join in the contest. The audience member who finds the most exploits within the hour wins a free dinner at a new Las Vegas restaurant. But you don’t have to wait until then to weigh in; go ahead and post your thoughts on fuzzing vs. static-code analysis in the comments, just be ready to back up your claims.