Reverse Engineering An Old Bus Display

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

[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

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?

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

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

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”

Reverse Engineering Liberates Dash Cam Video

If you’ve purchased a piece of consumer electronics in the last few years, there’s an excellent chance that you were forced to use some proprietary application (likely on a mobile device) to unlock its full functionality. It’s a depressing reality of modern technology, and unless you’re willing to roll your own hardware, it can be difficult to avoid. But [krishnan793] decided to take another route, and reverse engineered his DDPAI dash camera so he could get a live video stream from it without using the companion smartphone application.

Like many modern gadgets, the DDPAI camera creates its own WiFi access point that you need to connect to for configuration. By putting his computer’s wireless card into Monitor mode and running Wireshark, [krishnan793] was able to see that the smartphone was communicating with the camera using some type of REST API. After watching the clear-text exchanges for awhile, he not only discovered a few default usernames and passwords, but the commands necessary to configure the camera and start the video stream.

After hitting it with the proper REST messages, an nmap scan confirmed that several new services had started up on the device. Unfortunately, he didn’t get any video when he pointed VLC to the likely port numbers. At this point [krishnan793] checked the datasheet for the camera’s Hi3516E SoC and saw that it supported H.264 encoding. By manually specifying that as the video codec when invoking VLC, it was able to play a video stream from port 6200. A little later, he discovered that port 6100 was serving up the live audio.

Technically that’s all he wanted to do in the first place, as he was looking to feed the video into OpenCV for other projects. But while he was in the area, [krishnan793] also decided to find the download URL for the camera’s firmware, and ran it through binwalk to see what he could find out. Not surprisingly the security turned out to be fairly lax through the entire device, so he was able to glean some information that could be useful for future projects.

Of course, if you’d rather go with the first option and build your own custom dash camera so you don’t have to jump through so many hoops just to get a usable video stream, we’ve got some good news for you.