Reverse Engineering A Keyboard Driver Uncovers A Self-Destruct Code

September 19, 2024 by Dave Rowntree 22 Comments

Should you be able to brick a keyboard just by writing a driver to flash the lights on it? We don’t think so either. [TheNotary] got quite the shock when embarking on a seemingly straightforward project to learn C++ on the x86-64 architecture with Windows and sent it straight to Silicon Heaven with only a few seemingly innocent USB packets.

The project was a custom driver for the XVX S-K80 mechanical keyboard, aiming to flash LED patterns across the key LEDs and perhaps send custom images to the integrated LCD. When doing this sort of work, the first thing you need is the documentation of the communications protocols. Obviously, this was not an option with a closed-source project, so the next best thing is to spy on the existing Windows drivers and see how they worked. Using Wireshark to monitor the USB traffic whilst twiddling with the colour settings, it was clear that communications were purely over HID messages, simplifying subsequent analysis. Next, they used x32dbg (now x64dbg, but whatever) to attach to the existing driver process and trap a few interesting Windows system calls. After reading around the Windows API, a few candidate functions were identified and trapped. This gave them enough information to begin writing code to reproduce this behaviour. Then things got a bit odd.

Continue reading “Reverse Engineering A Keyboard Driver Uncovers A Self-Destruct Code” →

PC Floppy Copy Protection: Electronic Arts Interlock

September 17, 2024 by Maya Posch 8 Comments

Continuing the series on floppy copy protection, [GloriousCow] examines Electronic Arts’ Interlock system. This was used from 1984 to 1987 for at least fourteen titles released on both 5.25″ and 3.5″ floppies. Although not officially advertised, in the duplication mark sector the string ELECTRONIC ARTS IBM INTERLOCK. appears, hence the name. Compared to other copy protection systems like Softguard Superlok this Interlock protection poses a number of somewhat extreme measures to enforce the copy protection.

The disk surface of Side #0 of the 1984 mystery-adventure title, Murder on the Zinderneuf (Credit: GloriousCow) — The disk surface of Side #0 of the 1984 mystery-adventure title, *Murder on the Zinderneuf* (Credit: GloriousCow)

Other than the typical issues that come with copying so-called ‘booter’ floppies that do not use DOS but boot directly into the game, the protection track with Interlock is rather easy to spot, as seen on the right. It’s the track that lights up like a Christmas tree with meta data, consisting out of non-consecutive sector IDs. Of note is the use of ‘deleted’ sector data marks (DDAM), which is a rarity in normal usage. Along with the other peculiarities of this track it requires an exact query-response from the disk to be accepted as genuine, including timings. This meant that trying to boot a straight dump of the magnetic surface and trying to run it in an emulated system failed to work.

Reverse-engineering Interlock starts with the stage 0 bootloader from the first sector, which actually patches the End-of-Track (EOT) table parameter to make the ridiculous number of sectors on the special track work. The bootloader then loads a logo, which is the last thing you’ll see if your copy is imperfect.

Decrypting the second stage bootloader required a bit of disassembly and reverse-engineering, which uncovered some measures against crackers. While the actual process of reverse-engineering and the uncovered details of Interlock are far too complex to summarize here, after many hours and the final victory over the handling of an intentional bad CRC the target game (Murder on the Zinderneuf from 1984) finally loaded in the emulator.

After confirming the process with a few other titles, it seems that Interlock is mostly broken, with the DOS-based title ArcticFox (1987) the last hurdle to clear. We just hope that [GloriousCow] is safe at this point from EA’s tame lawyers.

Interested in more copy protection deep dives? Check out the work [GloriousCow] has already done on investigating Softguard’s Superlok and Formaster’s Copy-Lock.

Train Speed Signaling Adapted For Car

September 11, 2024 by Bryan Cockfield 33 Comments

One major flaw of designing societies around cars is the sheer amount of signage that drivers are expected to recognize, read, and react to. It’s a highly complex system that requires constant vigilance to a relatively boring task with high stakes, which is not something humans are particularly well adapted for. Modern GPS equipment can solve a few of these attention problems, with some able to at least show the current speed limit and perhaps an ongoing information feed of the current driving conditions., Trains, on the other hand, solved a lot of these problems long ago. [Philo] and [Tris], two train aficionados, were recently able to get an old speed indicator from a train and get it working in a similar way in their own car.

The speed indicator itself came from a train on the Red Line of the T, Boston’s subway system run by the Massachusetts Bay Transportation Authority (MBTA). Trains have a few unique ways of making sure they go the correct speed for whatever track they’re on as well as avoid colliding with other trains, and this speed indicator is part of that system. [Philo] and [Tris] found out through some reverse engineering that most of the parts were off-the-shelf components, and were able to repair a few things as well as eventually power everything up. With the help of an Arduino, an I/O expander, and some transistors to handle the 28V requirement for the speed indicator, the pair set off in their car to do some real-world testing.

This did take a few tries to get right, as there were some issues with the power supply as well as some bugs to work out in order to interface with the vehicle’s OBD-II port. They also tried to use GPS for approximating speed as well, and after a few runs around Boston they were successful in getting this speed indicator working as a speedometer for their car. It’s an impressive bit of reverse engineering as well as interfacing newer technology with old. For some other bits of train technology reproduced in the modern world you might also want to look at this recreation of a train whistle.

Continue reading “Train Speed Signaling Adapted For Car” →

PC Floppy Copy Protection: Softguard Superlok

September 9, 2024 by Maya Posch 15 Comments

Many have sought the holy grail of making commercial media both readable and copy-proof, especially once everyone began to copy those floppies. One of these attempts to make floppies copy-proof was Softguard’s Superlok. This in-depth look at this copy protection system by [GloriousCow] comes on the heels of a part one that covers Formaster’s Copy-Lock. Interestingly, Sierra switched from Copy-Lock to Superlok for their DOS version of games like King’s Quest, following the industry’s quest in search of this holy grail.

The way that Superlok works is that it loads a (hidden) executable called CPC.COM which proceeds to read the 128 byte key that is stored on a special track 6. With this key the game’s executable is decoded and fun can commence. Without a valid ‘Play’ disk containing the special track and CPC.COM executable all one is instead left with is a request by the game to ‘insert your ORIGINAL disk 1’.

As one can see in the Norton Commander screenshot of a Sierra game disk, the hidden file is easily uncovered in any application that supports showing hidden files. However, CPC.COM couldn’t be executed directly; it needs to be executed from a memory buffer and passed the correct stack parameters. Sierra likely put in very little effort when implementing Softguard’s solution in their products, as Superlok supports changing the encryption key offset and other ways to make life hard for crackers.

Sierra was using version 2.3 of Superlok, but Softguard would also make a version 3.0. This is quite similar to 2.x, but has a gotcha in that it reads across the track index for the outer sector. This requires track wrapping to be implemented. Far from this kind of copy protection cracking being a recent thing, there was a thriving market for products that would circumvent these protections, all the way up to Central Point’s Copy II PC Option Board that would man-in-the-middle between the floppy disk drive and the CPU, intercepting data and render those copy protections pointless.

As for the fate of Softguard, by the end of the 1980s many of its customers were tiring of the cat-and-mouse game between crackers and Softguard, along with issues reported by legitimate users. Customers like Infographics Inc. dropped the Superlok protection by 1987 and by 1992 Softguard was out of business.

Reverse-Engineering The AMD Secure Processor Inside The CPU

August 18, 2024 by Maya Posch 10 Comments

On an x86 system the BIOS is the first part of the system to become active along with the basic CPU core(s) functionality, or so things used to be until Intel introduced its Management Engine (IME) and AMD its AMD Secure Processor (AMD-SP). These are low-level, trusted execution environments, which in the case of AMD-SP involves a Cortex-A5 ARM processor that together with the Cryptographic Co-Processor (CCP) block in the CPU perform basic initialization functions that would previously have been associated with the (UEFI) BIOS like DRAM initialization, but also loading of encrypted (AGESA) firmware from external SPI Flash ROM. Only once the AMD-SP environment has run through all the initialization steps will the x86 cores be allowed to start up.

In a detailed teardown by [Specter] over at the Dayzerosec blog the AMD-SP’s elements, the used memory map and integration into the rest of the CPU die are detailed, with a follow-up article covering the workings of the CCP. The latter is used both by the AMD-SP as well as being part of the cryptography hardware acceleration ISA offered to the OS. Where security researchers are interested in the AMD-SP (and IME) is due to the fascinating attack vectors, with the IME having been the most targeted, but AMD-SP having its own vulnerabilities, including in related modules, such as an injection attack against AMD’s Secure Encrypted Virtualization (SEV).

Although both AMD and Intel are rather proud of how these bootstrapping systems enable TPM, secure virtualization and so on, their added complexity and presence invisible to the operating system clearly come with some serious trade-offs. With neither company willing to allow a security audit, it seems it’s up to security researchers to do so forcefully.

Hacker Tactic: Pimp Your Probes

August 14, 2024 by Arya Voronova 30 Comments

Is your multimeter one of your trusty friends when building up boards, repairing broken gadgets, and reverse-engineering proprietary ones? Is it accompanied by a logic analyzer or an oscilloscope at times?

Having a proper probing setup is crucial for many a task, and the standard multimeter probes just won’t do. As a PCB is slipping under your grip as you’re trying to hold the standard multimeter probes on two points at once, inevitably you will ponder whether you could be doing things differently. Here’s an assortment of probing advice I have accumulated.

Beyond The Norm

There’s the standard advice – keep your board attached firmly to a desk, we’ve seen gadgets like the Stickvise help us in this regard, and a regular lightweight benchtop vise does wonders. Same goes for using fancy needle probes that use gravity to press against testpoints – they might be expensive, but they are seriously cool, within limits, and you can even 3D-print them!

Continue reading “Hacker Tactic: Pimp Your Probes” →

Ryobi Battery Pack Gives Up Its Secrets Before Giving Up The Ghost

August 14, 2024 by Dan Maloney 43 Comments

Remember when dead batteries were something you’d just toss in the trash? Those days are long gone, thankfully, and rechargeable battery packs have put powerful cordless tools in the palms of our hands. But when those battery packs go bad, replacing them becomes an expensive proposition. And that’s a great excuse to pop a pack open and see what’s happening inside.

The battery pack in question found its way to [Don]’s bench by blinking some error codes and refusing to charge. Popping it open, he found a surprisingly packed PCB on top of the lithium cells, presumably the battery management system judging by the part numbers on some of the chips. There are a lot of test points along with some tempting headers, including one that gave up some serial data when the battery’s test button was pressed. The data isn’t encrypted, but it is somewhat cryptic, and didn’t give [Don] much help. Moving on to the test points, [Don] was able to measure the voltage of each battery in the series string. He also identified test pads that disable individual cells, at least judging by the serial output, which could be diagnostically interesting. [Don]’s reverse engineering work is now focused on the charge controller chip, which he’s looking at through its I2C port. He seems to have done quite a bit of work capturing output and trying to square it with the chip’s datasheet, but he’s having trouble decoding it.

This would be a great place for the Hackaday community to pitch in so he can perhaps get this battery unbricked. We have to admit feeling a wee bit responsible for this, since [Don] reports that it was our article on reverse engineering a cheap security camera that inspired him to dig into this, so we’d love to get him some help.