__ __ __ ___ / // /__ _____/ /__ ___ _ / _ \___ ___ __ / _ / _ `/ __/ '_/ / _ `/ / // / _ `/ // / /_//_/\_,_/\__/_/\_\ \_,_/ /____/\_,_/\_, / retro edition /___/Now optimized for embedded devices!!
| About | Successes | Retrocomputing guide | Email Hackaday |
In our hubris, we pat ourselves on the back when we’re able to pull data off our old SCSI drives. [Chris Fenton]‘s attempt to get an OS for a homebrew Cray-1 puts us rightfully to shame.
Last year we saw [Chris]‘ fully functional 1/10th scale Cray-1 supercomputer built around FPGA. While the reproduction was nearly cycle-accurate, [Chris] hasn’t had an opportunity to test out his system because of the lack of available Cray software. A former Cray employee heard of his plight and loaned an 80 Megabyte CDC 9877 disk pack to in the hope of getting some system software.
[Chris] acquired a monstrous 100 pound disk drive to read the disk pack, but after 30 years in storage a lot of electrical problems cropped up. Since reading the drive digitally proved to be an exercise in futility, [Chris] hit upon the idea of taking analog data straight from the read head. This left him with a magnetic image of the disk pack that was ready for some data analysis.
After the disk image was put up on the Internet, the very talented [Yngve AAdlandsvik] figured out the data, header, and error correction formats and sent [Chris] a Python script to tease bits from the analog image. While no one is quite sure what is on the disk pack provided by the Cray employee, [Chris] is remarkably close to bringing the Cray-1 OS back from the dead. There’s also a great research report [Chris] wrote as penance for access to the CDC disk drive. Any Hack A Day readers feel like looking over the data and possibly giving [Chris] a hand?
The iRobot Warrior 710 is shown here touting a new toy called an APOBS or Anti-Personnel Obstacle Breaching System. The system is comprised of an explosive rope pulled by a rocket. We know that sounds pretty awesome, and you can see in the video that it is, in fact, pretty awesome. We don’t condone violence, or war. We do, however, love blowin’ stuff up. This footage was just so pretty, we thought we had to share it. What’s even more amazing is that these guys aren’t battling Apple over the name iRobot.
[via botjunkie]
We dropped in on [Charlie Miller]‘s fuzzing seminar at the end of the day yesterday. Fuzzing become a fairly popular topic in the last year and essentially involves giving a program garbage input, hoping that it will break. If it can’t handle the fake data and fails in a non-graceful fashion, you could have found a potentially exploitable bug. Fuzzing is a fairly simple idea, but as Charlie points out, without some thinking while you’re doing it it’s unlikely to be very productive.
Say you wanted to fuzz a PDF reader. You take a random good PDF file and use a fuzzing program iterate through multiple mutations of that file. This brings up the question of how long do you fuzz something? Do you let it run 24hrs, is that enough time? Charlie applies the principles of code coverage to determine exactly how much of the code his fuzzing is actually testing. He used the PNG library as an example. He picked a random PNG to mutate from and it tested a small percentage of the code. Studying the PNG spec he found that there are 21 different chunk types possible in a PNG file so he grabbed 1600 random PNGs and mutated off of those. These many different seed files gave him a lot more code coverage because the files feature almost all the different chunk types. The principle idea being if you don’t execute a line of code you’ll never find the bug in that line of code.
Charlie was part of the team that’s credited for finding the first iPhone exploit. They used code coverage to determine where to start working. Apple’s WebKit is open source and there is a note that says to use Mozilla’s test suite to test modifications the JavaScript core. Using gcov, which is part of gcc, they ran the test against the code. The tool showed what code was executed by the test suite. They ignored that code and started poking at the large block of untested code they found since that was more likely to contain a bug. That’s where they found the Perl RegEx parser which was eventually exploited.
This isn’t just for programs with the source; you can also use code coverage tools like Pei Mei with IDA Pro to determine what part of a binary file the specific code you’re looking for lives. Then you can write smarter generators that will hit more of that particular code.
Greetings from CES day 2!
[programing4fun] has been playing around with his Kinect-based 3D display and building a holographic WALL-E controllable with a Windows phone. It’s a ‘kid safe’ version of his Terminator personal assistant that has voice control and support for 3d anaglyph and shutter glasses.
When we saw [programming4fun]‘s Kinect hologram setup last summer we were blown away. By tracking a user’s head with a Kinect, [programming] was able to display a 3D image using only a projector. This build was adapted into a 3D multitouch table and real life portals, so we’re glad to see [programming4fun] refining his code and coming up with some really neat builds.
In addition to robotic avatars catering to your every wish, [programming4fun] also put together a rudimentary helicopter flight simulator controlled by tilting cell phone. It’s the same DirectX 9 heli from [programming]‘s original build. with the addition of Desert Strike-esque top-down graphics. This might be the future of gaming here, so we’ll keep our eyes out for similar head-tracking 3D builds.
As always, videos after the break.
