[Chris Fenton] needs your help. After constructing a 1/10th scale, cycle accurate Cray-1 supercomputer and finding a disk with Cray software on it, he’s ready to start loading the OS. There’s a small problem, though: no one knows how to boot the thing.

[Chris] posted a disk image for a Cray-1/X-MP with the help of the people at archive.org. Now he needs your help – if you think you can reverse engineer the file system, [Chris] will pay handsomely with a miniature model of a Cray printed on his MakerBot. In any case, it seems like a fun challenge.

From our quick glance at the disk image with a HEX editor, it looks like [Chris] has something special on his hands. We see a few references to “Cray memory and registers,” as well as “IOP-0 Kernel, Version 4.2.2″ in the header along with a few dates referencing July of 1989.  This is consistent with the history of the source disk pack. If you think you’ve got what it takes to reverse engineer the file system of a Cray-1, this is your chance.

[Ch00f] spent some serious time figuring out how the Icebreaker POV toy works. This is a pretty cool device about the size of a toothbrush holder. It’s in a clear plastic case, which lets the row of 32 surface mount LEDs shine through. But making light isn’t their only function. You can use the device to scan in a high-contrast design, then ‘play it back’ using the persistence of vision display properties of the LED strip.

Perhaps the biggest question on [Ch00f's] mind was how the sensing is done. He made a series of observations, then started monkeying around with the LEDs to investigate them. It seems that one LED is lit up while the ones around it are used as light sensors. This becomes more confusing once he realized that the display was multiplexed.

His write-up includes a collection of schematics that can be pieced together to conceptualize the entire circuit. The image above was taken during this process, using an LED to check the connections on a part. This let him prove that it’s an N-channel MOSFET. He plans to take what learned and roll it into his own project.

[via Reddit]

[Travis Goodspeed] wrote in to tell us about his work reverse engineering the Bluetooth communications on this SPOT module. He’s targeted the post as a general guide to sniffing Bluetooth transmissions, but was inspired to use the SPOT as an example after seeing this other SPOT hack. We know he’s a fan of getting things to work with his Nokia N900, and that’s exactly where he ended up with the project.

This module was manufactured to be controlled by an Android phone. But there’s no control app available for the Nokia handset. Since Android uses the open-source Bluez package for the Bluetooth protocol, it’s actually pretty easy to get your hands on the packets. After grabbing a few test sets he shows how he deciphered the packets, then wrote a quick Python script to test out his findings. After working his way through the various commands available (grabbing the SPOT serial number, getting position data from it, etc) [Travis] wrote up a frontend in QT mobility for use on the N900.

Yesterday, Korg released a firmware update to their ribbon controller synth, the Monotribe. The firmware is just an audio file that needs to be played to the sync input of the box. [gravitronic] thought this was rather interesting, so he decided to decode the monotribe firmware. It’s the first step to custom Monotribe firmware, and on the path towards reverse engineering this neat box.

After converting the firmware update to a .wav, [gravitronic] looked at the file with a hex editor and found that each sample is two bytes, and the left and right channels are the same. That made enough sense, so after getting rid of one channel, he sent it through Python to take a look at the patterns of ones and zeros.

Of course, [gravitronic] arbitrarily chose high = 1, low = 0, and little-endianness. The first result didn’t produce a nice “KORG SYSTEM FILE” in the header, so he tried other combinations until the output file looked reasonable. The result is the actual .bin file that’s going to serve as the basis for a nice homebrew firmware. You can grab [gravitronic]‘s Python script here and decode your own firmware.

[Aaron] was looking for a cheap RFID reader that had some easy to follow documentation and a standardized interface. Most everything he saw was pretty expensive, so he decided to buy a cheap $10 reader from eBay to see how easy it would be to work with.

The reader came with very little documentation, but [Aaron] did know that the device identifies itself as a USB keyboard, outputting scan tag data into a text editor. That functionality wasn’t incredibly useful, so he took it apart to see if he could interface with it in some other manner. Exposing the PCB revealed an unknown IC for which he could find no documentation, but the board did include some breakout pins, so [Aaron] started by probing those for data.

He tried reading the data in both a terminal program and with a logic analyzer, but nothing seemed to make a whole lot of sense. He turned the sampling rate of the sniffer down, and things started looking a little better. After comparing the data from the sniffer with known tag codes, he noticed that each digit had an offset of 39 applied, so he whipped up a bit of code to correct the numbers.

[Aaron] did a good amount of legwork to get usable data from the reader, but at a cost of $10 it can’t be beat. We certainly know what we’re going to be hunting for on eBay this afternoon…

[Arko] was compelled to purchase an iclicker to use in some of his college courses. It’s similar in size to a television remote control except it only has six buttons and it communicates via radio frequency instead of infrared light. The idea is that classrooms have a base station that the instructor uses, and he or she can ask questions of the class and have instant feedback. Results are often projected on a screen for all to see but only the instructor can get at the breakdown of who answered in what way. In [Arko's] case, the class awards participation points that you can only get by using this device. He decided to actually learn something from the expenditure by reverse engineering the device.

Preliminary hardware inspection told him that it uses an ATmega8 microcontroller and there’s a standard 6-pin ISP footprint just waiting to be populated with a surface mount pin header. Once he soldered on that header, he tried to read out the firmware but the iClicker reset itself. He guessed that there was something going on with the power and ground lines so he soldered directly to them and was able to dump the data–the security fuses are not set. He goes on to snoop in the EEPROM to find where the device ID is stored, and then to watch some of the SPI communications to see what the microcontroller is sending to the radio chip. But there’s a lot left to discover and he’s planning at least two follow-up post to share what he finds.

Just looking to repair your dead device? Check out this tip on battery problems with the iclicker.

The Linksys router seen about is a WRT54G version 1. It famously runs Linux and was the source of much hacking back in the heyday, leading to popular alternative firmware packages such as DD-WRT and Tomato. But the company went away from a Linux-based firmware starting with version 8 of the hardware. Now they are using a proprietary Real Time Operating System called VxWorks.

[Craig] recently put together a reverse engineering guide for WRT54Gv8 and newer routers. His approach is purely firmware based since he doesn’t actually own a router that runs VxWorks. A bit of poking around in the hex dump lets him identify different parts of the files, leading to an ELF header that really starts to unlock the secrets within. From there he carries out a rather lengthy process of accurately disassembling the code into something that makes sense. The tool of choice used for this is IDA Pro diassembler and debugger. We weren’t previously familiar with it, but having seen what it can do we’re quite impressed.

[Image via Wikimedia Commons]

[Mostafa] was a bit bored and had a broken DVD player sitting around, so he decided to take it apart to see what made the machine’s LCD panel tick. Once he popped it open, he discovered it wasn’t an LCD panel at all, it was a VFD.

The seven segment display looked to be controlled by an ET16312n VFD driver, so he dug around online and found a datasheet for the chip. After looking at the documentation he was pretty confident he could get things working without too much trouble. He started tracing the board for the STB, CLK, Din, and Dout leads he needed to set up serial communications with the panel and was on his way in no time.

He hooked the panel up to the parallel port on his computer, and got busy hammering out some C code to write text to the display. Right now, the code lets you scroll text across the display, which is about as far as [Mostafa] cares to take it. It was done mostly as a proof of concept exercise, but since this VFD is compliant with the same NEC programming standard that most VFDs use, his code can likely be reused to drive any similar display with very little tweaking.

[Phillip Torrone] gave us a heads up about a project he and [Limor Fried] along with [Mike Doell] have just wrapped up. Their aptly-named “iCufflinks” softly pulsate with light the same way in which you see many Mac products do.

The cufflinks are made from machined aluminum and have the ubiquitous “power symbol” milled into the face. Inside the cufflinks, you will find a small circuit board and a battery, which powers the device for up to 24 hours. The team reverse-engineered the soft LED pulse found in Mac products in order to deliver the exact same visualization in their cufflinks.

Ignoring for a minute, the name and the inspiration for the product, we think they are pretty darn cool. There’s nothing like a set of softly glowing cufflinks to spark conversation at any social gathering.

Like anything else you’ll find on Adafruit.com, the cufflinks are completely open source, so you can feel free to tweak and remix the design any way you’d like.

Continue reading to see a video of the cufflinks in action.

For an upcoming road trip, [Patrick] needed a small variable power supply. Instead of lugging around a bench supply, [Patrick] did the sensible thing and reverse engineered a cell phone charger to fit his requirements.

After cracking open an old Kyocera car charger, [Patrick] found a small PCB with completely labeled, all through-hole components – excellent reverse engineering potential. After finding an On Semi MC33063 IC, [Patrick] tore through the datasheets, generated a netlist, and developed a schematic that closely resembled the reference schematic given by the datasheets.

With all the grunt work done, [Patrick] set out to finish what he started – modifying the charger to output 3-10 Volts. After replacing a resistor with a 5k multiturn pot, [Patrick] was left with a power supply with a variable output from 2.8 to 8.8 Volts. Not exactly what was desired, but more than enough for the application at hand. While this hack isn’t a disco floor, it’s a great walkthough of the hacking process – building or modifying something to suit a need.

While not necessarily an easy thing to learn, the ability to reverse engineer embedded device firmware is an incredibly useful skill. Reverse engineering firmware allows you to analyze a device for bugs and vulnerabilities, as well as gives you the opportunity to add features if you happen to be so inclined. When it comes to things such as jailbroken iPhones, Android phones, and Nooks, you can guarantee that a close look at the firmware helped to move the process along.

[Craig] works with embedded systems quite frequently and put together a detailed walkthrough demonstrating how he reverse engineers device firmware. The subject of his hacking was a new firmware package he obtained for a Linksys WWAG120 Wireless-N router.

His tutorial walks through some of the most common reverse engineering methods and tools, which allow him to slowly unravel the firmware’s secrets. When finished, he had a working copy of the router’s boot loader, kernel, and file system – all ready to be further analyzed. His writeup includes tons of additional details, so be sure to swing by his site if reverse engineering is something you are interested in.

A few months ago [Jason] got his hands on a free Coby DP700WD digital picture frame and thought it would be fun to hack. After realizing that the frame did not run any sort of Linux-based OS he figured his options were pretty limited, but he gave it a shot anyways.

The frame came with a set of built in images, and his goal was to swap them out for pictures of his own. He started by trying to read data from the frame’s serial flash chip, but found that the processor was preventing him from doing so. He de-soldered the chip from the frame, mounted it on a makeshift breakout board, and started reading up on SPI.

He was eventually able to read the device’s flash chip and swapped out the built-in images with his own. After a bit of trial and error, he was able to replace the frame’s boot screen with his own custom image as well.

If you are looking to do something similar, be sure to swing by his site – all of the tools and code he used to hack his frame are available for the taking.

Continue reading to see his modified picture frame in action.

[Scott] was looking to source some LCD screens for an upcoming project, and was considering buying them from SparkFun. While the Nokia panels they sell are not expensive, they aren’t necessarily the cheapest option either – especially when building in volume.

He searched around for something he could use instead, and settled on Blackberry screens. Old Blackberry models were even more durable than the current offerings, plus companies are trying to get rid of old handsets by the truckload. The only problem was that he could not find any information online that would show him how to write to the screens.

It took a bit of digging, but he eventually determined which ICs were used to drive the LCD screen. He had no luck finding screen pinout information online, so after spending a few hours testing things with his multimeter, he came up with a full listing on his own.

He wired up a connector so that he could use the screen on a breadboard, then got busy writing code to display some text on the screen. Everything came together nicely as you can see in the video below, and he has released his code in case anyone else is looking to repurpose some old Blackberry screens.

All we want to know is what sort of project all these screens are going to be used in.

[Kenn] is working on building a quadrocopter from the ground up for a university project. Currently, his main focus is building an Inertial Measurement Unit, or rather re-purposing a PS3 Move controller as the IMU for his copter. He previously considered using a Wiimote Motion Plus, but the Move has a three-axis magnetometer, which the Wii controller does not.

The ultimate goal for this portion of his project is building custom firmware to run on the Move’s STM32-Cortex microcontroller, allowing him to obtain data from each of the controller’s sensors. Through the course of his research, he has thoroughly documented each sensor on his site, and dumped a full working firmware image from the Cortex chip as well. Recently, he was even able to run arbitrary code on the controller itself, which is a huge step forward.

[Kenn’s] project is coming along very nicely, and will undoubtedly be a great resource to others as he continues to dig through the inner workings of the Move. Be sure to swing by his site if you are looking for information, or if you have something to contribute.

The original PSP may be old news but there is an interesting relic of a website (translated) dedicated to the reverse engineering of a PSP (and exploring Saturn?). To determine the true capabilities of the PSP they desoldered most of the ball grid array chips and then hand soldered 157 jumper wires to allow for direct memory access. In later pictures it shows the PSP hooked up to external hardware for on the fly memory modification. Unfortunately the details are sparse and it doesn’t appear as if they will be updated anytime soon because the website has been “deleted and freezed because of spam. may ineffaceable curse prevail on the spammers.” Still this doesn’t detract too much some very impressive soldering.