Software Defined Radio Gets Physical Control

December 12, 2019 by Tom Nardi 16 Comments

Software Defined Radio (SDR) is a great technology, but there’s something so satisfying about spinning a physical knob to cruise the airwaves. Wanting to restore that tactile experience, [Tysonpower] purchased a cheap USB volume knob and set out to get it working with his software. Unfortunately, getting it up and running took a lot more work than you’re probably expecting.

After verifying that the knob worked for volume control on his computer, [Tysonpower] decided to try and pull the firmware from the device’s STM32 microcontroller. Unfortunately, this is where things got tricky. It turned out the chip had Code Protection enabled, so when it was wired up to a programmer and put into DFU mode, the firmware got wiped. Oops.

That left [Tysonpower] with no choice but to write a new firmware from scratch, which naturally required reverse engineering the device’s hardware. Step one was reading up on STM32 development and getting the toolchain working, which paved the way to getting the knob’s LED to blink. A couple more hours worth of work and some multimeter poking later, and he was able to read the knob’s movement. He describes getting USB HID working as a nightmare due to lack of documentation, but eventually he got that sorted out as well.

The end result is a firmware allows the volume knob to mimic a mouse scroll wheel, which can be used for tuning in many SDR packages. But we think the real success story is the experience [Tysonpower] gained with reverse engineering and working with the STM32 platform. After all, sometimes the journey is just as important as the end result. Continue reading “Software Defined Radio Gets Physical Control” →

Reverse Engineering An Old Bus Display

December 11, 2019 by Tom Nardi 14 Comments

When his makerspace was gifted a pair of Luminator LED signs of the sort you might see on the front of a bus, [PWalsh] decided to pull one apart to see what made it tick. Along the way, he managed to reverse engineer its control protocol and replace its original control board with a WiFi-connected Raspberry Pi. Now they can use the LED signs to show whatever they want; no bus required.

As they were designed for automotive use, the signs were wired for 12 volts DC. So the first order of business was fitting it with an AC/DC converter so it could be plugged into the wall. After he measured the display’s current consumption, [PWalsh] estimated it’s maximum energy consumption and determined an old ATX computer power supply was more than up to the task.

With the sign happily running battery-free, he could begin figuring out how to talk to it. Noticing a MAX485 RS-485 converter on the PCB, gave a pretty good idea of what language it was speaking, and with the aid of his trusty oscilloscope, he was able to suss out the baud rate. A cheap USB to RS-485 converter was then wired in between the sign and its control board so he could sniff the data passing over the line.

From there, the final piece of the puzzle was studying the captured data and figuring out the protocol. [PWalsh] was able to identify packet headers and ASCII characters, and pretty soon knew enough about how the sign communicated that he was able to remove the control board entirely and just push text and images to it right from the Pi. He’s even made his framework available for anyone else who might have a similar piece of bus-signage laying around.

Even if you’re not looking to add one of these signs to your lab, this project is a fantastic example of protocol reverse engineering with low-cost tools and simple techniques. We always love to see the process broken down step by step like this, and our hat’s off to [PWalsh] for delivering the goods in a big way.

This isn’t the first time we’ve seen these sort of LED signs get the “Internet of Things” treatment, and if you’re content with a somewhat scaled down version, you could always just build your own display rather than waiting on the local public transit vehicle to get parted out.

Rescue An Expensive Servo With Some Reverse Engineering

December 11, 2019 by Donald Papp 9 Comments

[Andrew] had a servo damaged by someone connecting the power supply to the wrong pins (whoops) which fried the microcontroller and a logic level shifter. With a bit of reverse engineering, he successfully restored basic servo functionality by writing some new code. The new code implements only basic features, but that’s enough to save the device from the junk bin.

FAULHABER 2232DBHHO ring any bells? Google came up empty.

Why bother reverse engineering a servo? Well, if dollars are reasons then there are many for saving a HerkuleX DRS-0602 from the junk heap; they cost around 320 USD before shipping. Another reason to try is that the microcontroller turned out to be an AVR XMega, which gave [Andrew] confidence in writing some new code.

If you want to understand more about how these servos work, [Andrew] provides good photos of the insides and identifies the major components and their connections and functions. There are some mysteries (such as details of the motor and embedded encoder, which are FAULHABER 2232DBHHO) but [Andrew] figured out enough to write some basic code to allow the servo to work as a standard servo with a UART interface.

Sometimes curiosity drives reverse engineering and repair efforts, sometimes it’s cost, and sometimes it’s both. A $320 servo is certainly worth trying to save, and so are huge observatory telescopes with obsolete servo amps.

Swapping The ROMs In Mini Arcade Cabinets

December 6, 2019 by Tom Nardi 10 Comments

You’ve probably seen a few of these miniature arcade games online or in big box retailers: for $20 USD or so you get scaled-down version of a classic arcade cabinet, perfect for a desk toy or to throw up on a shelf as part of your gaming collection. Like any good Hackaday reader, you were probably curious about what makes them tick. Thanks to [wrongbaud], we don’t have to wonder anymore.

Over the course of several blog posts, [wrongbaud] walks readers through the hardware and software used in a few of these miniature games. For example, the Rampage cabinet is using a so-called “NES on a Chip” along with a SPI flash chip to hold the ROM, while Mortal Kombat is using a Genesis emulation solution and parallel flash. It wouldn’t be interesting if they didn’t throw you a few curves now and again, right?

But these are more than simple teardowns. Once [wrongbaud] gives an overview of the hardware, the next step is reading the respective flash storage and trying to make sense of the dumped data. These sort of games generally reuse the hardware among a number of titles, so by isolating where the game ROM is and replacing it, they can be made to play other games without hardware modification. Here, this capability is demonstrated by replacing the ROM data for Rampage with Yoshi’s Cookie. Naturally it’s one of those things that’s easier said than done, but it’s an interesting proof of concept.

The Mortal Kombat cabinet is a newer addition to the collection, so [wrongbaud] hasn’t progressed quite as far with that one. The parallel flash chip has been dumped with the help of an ESP32 and a MCP23017 I/O expander, and some Genesis ROM headers are identifiable in the data, but there’s still some sifting to be done before the firmware structure can be fully understood.

Even if you’re not in the market for a diminutive arcade experience, the information that [wrongbaud] has collected here is really phenomenal. From understanding protocols such as I2C and SPI to navigating firmware dumps with a hex editor, these posts are an invaluable resource for anyone looking to get started with reverse engineering.

Why Buy Toys When You Can Build Them Instead?

November 8, 2019 by Tom Nardi 10 Comments

Like many creative individuals who suddenly find themselves parents, [Marta] wanted to make something special for his children to play with. Anybody can just purchase an off-the-shelf electronic toy, but if you’ve got the ability to design one on your own terms, why not do it? But even compared to the fairly high standards set by hacker parents, we have to admit that the amount of time, thought, and effort that was put into the “Marta Musik Maschine” is absolutely phenomenal.

[Marta] was inspired by the various commercial offerings which use RFID and other technologies to identify which characters the child is playing with and respond accordingly. But since he didn’t want to get locked into one particular company’s ecosystem and tinkering with the toys seemed frowned upon by their creators, he decided to just come up with his own version.

Over the course of many posts on the Musik Maschine’s dedicated website, [Marta] explains his thought process for every design consideration of the toy in absolutely exquisite detail. Each of the writeups, which have helpfully been broken down for each sub-system of the final toy, are arguably detailed and complete enough to stand as their own individual projects. Even if you’re not looking to get into the world of DIY electronic toys, there’s almost certainly an individual post here which you’ll find fascinating. From the finer points of interfacing your Python code with arcade buttons to tips for designing 3D printed enclosures, there’s really something for everyone here.

The children of hackers are often the envy of the neighborhood thanks to the one-of-a-kind playthings provided by their parents, and considering the level of commitment [Marta] has put into a toddler toy, we can’t wait to see what he comes up with next.

Continue reading “Why Buy Toys When You Can Build Them Instead?” →

Reverse Engineering A Two-Wire Intercom

October 27, 2019 by Jenny List 13 Comments

There was a time when an intercom was simply a pair of boxes with speakers joined by a couple of wires, with an audio amplifier somewhere in the mix. But intercoms have like everything else joined the digital age, so those two wires now carry a load of other functionality as digital signalling. [Aaron Christophel] installs these devices for a living, and has posted a fascinating reverse engineering video that we’ve also placed below the break.

Power for the system is present as a constant 24V DC, and the audio is still an old-fashioned analogue signal that we’ll all be familiar with. On that 24V DC though are imposed a series of pulse trains to trigger the different alarms and other functions, and he describes extracting these with an oscilloscope before showing us the circuitry he’s used to send and receive pulses with an Arduino. The bulk of the video is then devoted to the software on the Arduino, which you can also find in a GitHub repository.

The result is an interesting primer for anyone who fancies a bit of serial detective work, even if they don’t have a intercom to hand.

Continue reading “Reverse Engineering A Two-Wire Intercom” →

Reverse-Engineering Xiaomi IoT Firmware

October 24, 2019 by Sharon Lin 13 Comments

IoT devices rarely ever just do what they’re advertised. They’ll almost always take up more space than they need to – on top of that, their processor and memory alone should be enough to run a multitude of other tasks while not necessarily compromising the task they were built to do.

That’s partially the motivation for rooting any device, but for Xiaomi devices, it’s a bit more fun – that is to say, it’s a little bit harder when you’re reverse engineering its firmware from scratch.

Similar to his other DEF CON 26 talk on modifying ARM Cortex-M firmware, [Dennis Giese] returns with a walkthrough of how to reverse-engineer Xiaomi IoT devices. He starts off talking about the Xiaomi ecosystem and the drawbacks of reusing firmware across all the different devices connected to the same cloud network before jumping into the walkthrough for accessing the devices.

Continue reading “Reverse-Engineering Xiaomi IoT Firmware” →