Hail To The King, Baby: Reverse Engineering Duke

June 8, 2019 by Tom Nardi 15 Comments

If you’re a fan of DOS games from the 1990s, you’ve almost certainly used DOSBox to replay them on a modern computer. It allows you to run software in a virtual environment that replicates an era-appropriate computer. That’s great for historical accuracy, but doesn’t do you much good if you’re trying to leverage modern computing power to breathe some new life into those classic titles. For that, you need to dig in a little deeper.

For the last two and a half years, [Nikolai Wuttke] has been doing exactly that for 1993’s Duke Nukem II. The end result is RigelEngine, an open source drop-in replacement for the original game binary that not only runs on a modern Windows, Linux, or Mac OS machine, but manages to improve on the original in a number of ways. An accomplishment made even more impressive once you learn that the original source code for the game has been lost to time, and that he had to do everything blind.

In a blog post chronicling his progress so far, [Nikolai] explains the arduous process he used to make sure his re-implementation was as accurate as possible to the original game. He spent untold hours studying the original game’s disassembled code in Ida Pro, handwriting out pages of notes and pseudocode as he tried to understand what was happening behind the scenes. Once a particular enemy or element of the game was implemented in RigelEngine, he’d record the gameplay from his version and compare it to the original frame by frame so he could fine tune the experience.

So what’s the end result of more than two years of work and over 25K lines of code? Thanks to the incredible advancements in computing power since the game’s release nearly 30 years ago, [Nikolai] has managed to remove the need for loading screens. His engine is also capable of displaying an unlimited number of particle effects on the screen at once, and multiple sound effects can now be played simultaneously. In the future he’s looking to implement smooth character movement (in the original game, movement was in 8 pixel increments) and adaptive volume for sound effects based on their distance from Duke. Ultimately, RigelEngine should be able to replace the original graphics with new high resolution textures once some issues with the rendering buffer gets sorted out.

It’s hard to overstate how important some of these classic games are to those who grew up playing them. With John Romero still releasing DLC for the original DOOM and hackers disassembling nearly 40 year old games to fix bugs, it doesn’t seem like they’re in any danger of being forgotten.

Continue reading “Hail To The King, Baby: Reverse Engineering Duke” →

Your Table Is Ready, Courtesy Of HackRF

June 4, 2019 by Tom Nardi 28 Comments

Have you ever found yourself in a crowded restaurant on a Saturday night, holding onto one of those little gadgets that blinks and vibrates when it’s your turn to be seated? Next time, bust out the HackRF and follow along with [Tony Tiger] as he shows how it can be used to easily fire them off. Of course, there won’t actually be a table ready when you triumphantly show your blinking pager to the staff; but there’s only so much an SDR can do.

Even if you aren’t looking to jump the line at your favorite dining establishment, the video that [Tony] has put together serves as an excellent practical example of using software defined radio (SDR) to examine and ultimately replicate a wireless communications protocol. The same techniques demonstrated here could be applied to any number of devices out in the wild with little to no modification. Granted these “restaurant pagers” aren’t exactly high security devices to begin with, but you’d be ~~horrified~~ surprised how many other devices out there take a similarly cavalier attitude towards security.

[Tony] starts by using inspectrum to examine the Frequency-shift keying (FSK) modulation used by the 467.750 Mhz devices, and from there, uses Universal Radio Hacker to capture the actual binary data being sent over the air. Between studying the transmissions and the information he found online, he was eventually able to piece together the packet structure used by the restaurant’s base station.

Finally, he wrote a Python script which generates packets based on which pager he wants to set off. If he’s feeling particularly mischievous, he can even set them all off at once. The script outputs a binary file which is then loaded into GNU Radio for transmission via the HackRF. [Tony] says he’s not quite ready to release his script yet, but he gives enough information in the video that the intrepid hacker could probably get their own version up and running by the time he gets it posted up to GitHub anyway.

We saw some very similar techniques demonstrated at the recent WOPR Summit security conference, so once you’re done hacking the local restaurants, you can take these same lessons and apply them to the rest of the Internet of Things. If you’re wondering, it’s even easier to eavesdrop on the non-restaurant pagers.

Continue reading “Your Table Is Ready, Courtesy Of HackRF” →

Solving The Final Part Of The IClicker Puzzle

May 21, 2019 by Tom Nardi 9 Comments

The regular Hackaday reader might remember the iClicker from our previous coverage of the classroom quiz device, or perhaps you even had some first hand experience with it during your university days. A number of hackers have worked to reverse engineer the devices over the years, and on the whole, it’s a fairly well understood system. But there are still a few gaps in the hacker’s map of the iClicker, and for some folks, that just won’t do.

[Ammar Askar] took it upon himself to further the state of the art for iClicker hacking, and has put together a very detailed account on his blog. While most efforts have focused on documenting and eventually recreating how the student remotes send their responses to the teacher’s base station, he was curious about looking at the system from the other side. Specifically, he wanted to know how the base station was able to push teacher-supplied welcome messages to the student units, and how it informed the clients that their answers had been acknowledged.

He started by looking through the base station’s software update tool to find out where it was downloading the firmware files from, a trick we’ve seen used to great effect in the past. With the firmware in hand, [Ammar] disassembled the AVR code in IDA and got to work piecing together how the hardware works. He knew from previous group’s exploration of the hardware that the base station’s Semtech XE1203F radio is connected to the processor via SPI, so he started searching for code which was interacting with the SPI control registers.

This line of logic uncovered how the radio is configured over SPI, and ultimately where the data intended for transmission is stored in memory. He then moved over to running the firmware image in simavr. Just like Firmadyne allows you to run ARM or MIPS firmware with an attached debugger, this tool allowed [Ammar] to poke around in memory and do things such as simulate when student responses were coming in over the radio link.

At that point, all he had to do was capture the bytes being sent out and decode what they actually meant. This process was complicated slightly by the fact the system uses to use its own custom encoding rather than ASCII for the messages, but by that point, [Ammar] was too close to let something like that deter him. Nearly a decade after first hearing that hackers had started poking around inside of them, it looks like we can finally close the case on the iClicker.

Analog Failures On RF Product Cause Production Surprise

May 13, 2019 by Kerry Scharfglass 15 Comments

A factory is a machine. It takes a fixed set of inputs – circuit boards, plastic enclosures, optimism – and produces a fixed set of outputs in the form of assembled products. Sometimes it is comprised of real machines (see any recent video of a Tesla assembly line) but more often it’s a mixture of mechanical machines and meaty humans working together. Regardless of the exact balance the factory machine is conceived of by a production engineer and goes through the same design, iteration, polish cycle that the rest of the product does (in this sense product development is somewhat fractal). Last year [Michael Ossmann] had a surprise production problem which is both a chilling tale of a nasty hardware bug and a great reminder of how fragile manufacturing can be. It’s a natural fit for this year’s theme of going to production.

Surprise VCC glitching causing CPU reset

The saga begins with [Michael] receiving an urgent message from the factory that an existing product which had been in production for years was failing at such a high rate that they had stopped the production line. There are few worse notes to get from a factory! The issue was apparently “failure to program” and Great Scott Gadgets immediately requested samples from their manufacturer to debug. What follows is a carefully described and very educational debug session from hell, involving reverse engineering ROMs, probing errant voltage rails, and large sample sizes. [Michael] doesn’t give us a sense for how long it took to isolate but given how minute the root cause was we’d bet that it was a long, long time.

The post stands alone as an exemplar for debugging nasty hardware glitches, but we’d like to call attention to the second root cause buried near the end of the post. What stopped the manufacturer wasn’t the hardware problem so much as a process issue which had been exposed. It turned out the bug had always been reproducible in about 3% of units but the factory had never mentioned it. Why? We’d suspect that [Michael]’s guess is correct. The operators who happened to perform the failing step had discovered a workaround years ago and transparently smoothed the failure over. Then there was a staff change and the new operator started flagging the failure instead of fixing it. Arguably this is what should have been happening the entire time, but in this one tiny corner of the process the manufacturing process had been slightly deviated from. For a little more color check out episode #440.2 of the Amp Hour to hear [Chris Gammell] talk about it with [Michael]. It’s a good reminder that a product is only as reliable as the process that builds it, and that process isn’t always as reliable as it seems.

This Owner Took Control Of Their Proprietary Alarm System

April 27, 2019 by Jenny List 22 Comments

When a tip comes in and the tipster feels they have to reassure us that despite appearances their subject is not facilitating crime, it certainly gets our attention. [Flam2006] has a Brinks home security system which can only be configured using a special device only available to installers, and though they managed to secure one through an eBay sale they went to the trouble of reverse engineering its protocol and writing a software emulator in Python. When an owner hacks their own security system to gain full control of something they own, that’s right up our street.

The communication is via an RS485 serial line, and follows a packetised structure with binary rather than ASCII data. There is an almost plug-and-play system for identifying devices connected to a controller, though it is restricted to those devices which the controller already knows about. There is a video of the official method of programming the controller, as well as one of the software in action. We’ve posted them below the break for your delectation.

The ability to perform these tasks on your own property is an important right that has at times been placed under threat by legislation such as the DMCA. We’ve touched upon it countless times, but probably the most high-profile example that we and the wider media have covered are those stories concerning the parts lockdown on John Deere tractors.

Continue reading “This Owner Took Control Of Their Proprietary Alarm System” →

Rooting Your Ride: Jailbreaking A Subaru QNX

April 16, 2019 by Jenny List 18 Comments

A modern car still drives in the same way as the one you would have bought thirty years ago, it still has a steering wheel and all the other controls. What has changed in the cabin lies mostly beneath the dash, where enough computing power to launch several Moon shots takes care of everything from air-conditioning to entertainment. As you might expect these systems attract the curiosity of security researchers, and through their work we gain an insight into their operation.

[Scott Gayou] has a Subaru, a car that has an all-in-one entertainment system head unit that is typical of what you’d find across a host of manufacturers. His account of jailbreaking it is a lengthy essay and a fascinating read for anyone. He starts with a serial port, then an SSH prompt for a root password, and a bit of searching to find it was made by Harman and that it runs the closed-source realtime OS QNX. From there he finds an official Subaru update, from which he can slowly peel away the layers and deduce the security mechanism. The write-up lays bare his techniques, for example at one point isolating the ARM assembler for a particular function and transplanting it bodily into his own code for investigation.

Eventually he could penetrate the filesystem of the update, and from there he could find that while the root user had a password there were two other accounts that while heavily locked down, had none. The discovery came that files on USB drives plugged into the system were given user-level execute permissions, at which point under the locked-down user he could execute arbitrary code from USB drives. He could then create and modify copies of the device’s filesystem which he could flash onto it, and thus place a modified password validation function into it and gain root access.

Some Hackaday readers will be accomplished in security work such as this, but many of us are hardware specialists for whom it remains something of a dark art. A comprehensive and accessible write-up such as this one is therefore invaluable, because it gives us an insight into the techniques used and perhaps more importantly, into some of the security pitfalls a hardware engineer might unwittingly introduce into their creations.

QNX is a real-time operating system with a long history of appearances in industrial and automotive applications. Readers with long memories may recall their demo floppies from the 1990s which packed a fully functional GUI, Internet connectivity, and modern (for the time) web browser onto a single 1.44Mb floppy disk. We’ve talked about it in the past in a little detail, as when someone made a desktop OS using it.

Imitating Art In Life With A Reverse-Engineered Tattoo

March 23, 2019 by Dan Maloney 6 Comments

In general, tattoo artists are not electrical engineers. That’s fine; the world needs both professions. But when you need a circuit designed, you’re better off turning to an EE rather than a tattoo artist. And you certainly don’t want an EE doing your new ink. Disaster lies that way.

Surprisingly, [Missa]’s tattoo of a heart-shaped circuit turned out at least to be plausible design, even if it’s not clear what it’s supposed to do. So her friend [Jeremy Elson] took up the challenge to create a circuit that looked like the tattoo while actually doing something useful. He had to work around the results of tattoo artistic license, like sending traces off to the board’s edge and stranding surface-mount components without any traces. The artist had rendered an 8-pin DIP device, albeit somewhat proportionally challenged, so [Jeremy] went with an ATtiny85, threw on a couple of SMD resistors and a cap, and placed two LEDs for the necessary blinkenlights. Most of the SMDs are fed from traces on the back of the board that resurface through vias, and a small coin cell hidden on the back powers it. One LED blinks “Happy Birthday [Missa]” in Morse, while the other blinks prime numbers from 2 to 23 – we’ll assume this means it was [Missa]’s 23rd birthday.

There’s a surprising amount of crossover between the worlds of electronics and tattooing. We’ve featured functional temporary tattoo circuits, prison-expedient tattoo guns, and even a CNC tattoo machine.

Continue reading “Imitating Art In Life With A Reverse-Engineered Tattoo” →