Salvaged LCD Screen Hacking

May 21, 2012 by Mike Szczys 17 Comments

You can find all kinds of LCD screens in broken electronics. But it’s often a chore to figure out how they are controlled if you don’t have a working device that can be used to sniff the communications protocol. [Justin] grabbed this character LCD screen from an old Brother printer and decided to see if he could reuse it in his own projects. Luckily the driver card still worked so he patched into the LCD’s control lines and sniffed the signals when the printer is powered on.

He used the OpenBench Logic Sniffer for this project. It easily captured the data, and also provided analysis tools. The SPI analyzer managed to decode the command signals and message of “Please wait” that pops up at power up. After a bit of folly with the pin out of the display, he is now able to control it thanks to an Arduino library which he wrote. Check out the demo after the break to seem him scrolling through a bunch of different functions for the device.

Continue reading “Salvaged LCD Screen Hacking” →

Reverse Engineering An Oscilloscope Circumvents Vendor Crippleware

March 5, 2012 by Mike Nathan 28 Comments

The crew over at the Hungarian Autonomous Center for Knowledge (H.A.C.K.) say they aren’t the most well-funded organization out there, so they were stoked when they found they could afford to bring a slightly used UNI-T UT2025B digital oscilloscope into the shop. As they started to tinker with it, the scope revealed one major shortcoming – screenshots were only accessible via a USB connection to a Windows computer.

Since they didn’t have any Windows boxes in house, [András Veres-Szentkirályi] decided he would try reverse-engineering the protocol so they could get access to this useful feature.

He set up a Windows VM, and using Wireshark on the host Linux box, [András] sniffed the data passing over the scope’s USB interface. He was able to identify what looked like image packets being sent to the VM, which he was able to decode using a small Python script. The resultant images were monochrome and they didn’t look quite right, but it was a start. As he dug further [András] found that he was overlooking some of the color data packed into the images, and after a bit of fiddling he got the sharp, colorful image you see above.

It turns out that while the scope has a monochrome LCD, it sends 16-bit color images over the USB interface – images that the Windows’ client degrades before displaying them on the screen. So in the end, he was not only able to get the scope working on any OS with the ability to run Python, he was able to grab far better images than the manufacturer ever intended – A very nice hack if we do say so.

Be sure to swing by the H.A.C.K. wiki as well as the project’s github repository if you have one of these scopes and are looking to wring some better images out of the hardware.

Repair A Misbehaving Motor Controller Board

February 20, 2012 by Mike Szczys 10 Comments

It can be a real drag to fix a circuit board which has stopped working as intended, especially if you don’t have any reference material for the product. That’s the position that [Todd Harrison] found himself in when the controller for his mini-lathe gave up the ghost. He undertook and hefty repair process and eventually mapped out and repaired the driver board.

First off, we’re happy to report his success at the end of a year-long troubleshooting process; the entirety of which occupies six different posts. The link at the top is the conclusion, and you’ll find his final test video after the break. But as you can see from the image above, he was met with a lot of problems along the way. The first two segments show him reverse engineering the PCB, with a giant schematic coming out of the process. In part 3 he then started probing the board while it was live, with the smell of hot electronics causing him to disconnect the power every thirty seconds. One time he took too long and blew a resistor with the pictured results.

In the end it was a shorted PWM chip to blame. He tested a couple of different replacement options, dropped in the new part, and is now back in business. Continue reading “Repair A Misbehaving Motor Controller Board” →

Help [Chris] Boot His Cray-1 Supercomputer

January 10, 2012 by Brian Benchoff 72 Comments

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

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.