Reverse Engineering The Icebreaker POV Toy

December 21, 2011 by Mike Szczys 2 Comments

[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]

Reverse Engineering Bluetooth Using Android And SPOT As An Example

December 5, 2011 by Mike Szczys 4 Comments

[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.

Reverse Engineering A Korg Monotribe

December 3, 2011 by Brian Benchoff 19 Comments

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.

Getting Useful Data From A Dirt Cheap RFID Reader

November 19, 2011 by Mike Nathan 21 Comments

cheap-rfid-reader

[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…

Snooping Around In The Iclicker Hardware And Firmware

October 23, 2011 by Mike Szczys 26 Comments

[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.

Reverse Engineering VxWorks (which Replaces Linux On Newer Routers)

July 8, 2011 by Mike Szczys 25 Comments

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]

VFD Hacking

July 7, 2011 by Mike Nathan 10 Comments

vfd_hacking

[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.