At this point in the tech dystopia cycle, it’s no surprise that the initial purchase price of a piece of technology is likely not the last payment you’ll make. Almost everything these days needs an ongoing subscription to do whatever you paid for it to do in the first place. It’s ridiculous, especially when all you want to do is charge your electric motorcycle with electricity you already pay for; why in the world would you need a subscription for that?
That was [Maarten]’s question when he picked up a used EVBox wall mount charger, which refused to charge his bike without signing up for a subscription. True, the subscription gave access to all kinds of gee-whiz features, none of which were necessary for the job of topping off the bike’s battery. A teardown revealed a well-built device with separate modules for mains supply and battery charging, plus a communications module with a cellular modem, obviously the bit that’s phoning home and keeping the charger from working without the subscription.
These days, when something electronic breaks, most folks just throw it away and get a new one. But as hackers, we prefer to find out what the actual problem is and fix it. [Bonsembiante] took that very tack when a MOTU brand audio interface wasn’t booting. As it turns out, a bit of investigative work led to a simple and viable fix.
The previous owner had tried to get the unit fixed multiple times without success. When it ended up on [Bonsembiante]’s bench, reverse engineering was the order of the day. Based around an embedded Linux system, there was lots to poke and prod at inside, it’s just that… the system wasn’t booting, wasn’t showing up over USB or Ethernet, or doing much of anything at all.
Extracting the firmware only revealed that the firmware was actually valid, so that was a dead end. However, after some work following the boot process along in Ghidra, with some external help, the problem was revealed. Something was causing the valid firmware to fail the bootloader’s checks—and with that fixed, the unit booted. You’ll have to read the article to get the full juicy story—it’s worth it!
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.
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)
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.
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.
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’.
Sierra’s King Quest v1.0 for DOS.
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.
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.
