Reverse-Engineering The AMD Secure Processor Inside The CPU

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

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

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.

A Look Inside The Space Shuttle’s First Printer

There was even a day not too long ago when printers appeared to be going the way of the dodo; remember the “paperless office” craze? But then, printer manufacturers invented printers so cheap they could give them away while charging $12,000 a gallon for the ink, and the paperless office suddenly suffered an extinction-level event of its own. You’d think space would be the one place where computer users would be spared the travails of printing, but as [Ken Shirriff] outlines, there were printers aboard the Space Shuttle, and the story behind them is fascinating.

The push for printers in space came from the combined forces of NASA’s love for checklists and the need for astronauts in the early programs to tediously copy them to paper; Apollo 13, anyone? According to [Ken], NASA had always planned for the ability to print on the Shuttle, but when their fancy fax machine wasn’t ready in time, they kludged together an interim solution from a US military teleprinter, the AN/UG-74C. [Ken] got a hold of one of these beasts for a look inside, and it holds some wonders. Based on a Motorola MC6800, the teleprinter sported both a keyboard, a current loop digital interface, and even a rudimentary word processor, none of which were of much use aboard the Shuttle. All that stuff was stripped out, leaving mostly just the spinning 80-character-wide print drum and the array of 80 solenoid-powered hammers, to bang out complete lines of text at a time. To make the printer Shuttle-worthy, a 600-baud frequency-shift keying (FSK) interface was added, which patched into the spaceplane’s comms system.

[Ken] does his usual meticulous analysis of the engineering of this wonderful bit of retro space gear, which you can read all about in the linked article. We hope this portends a video by his merry band of Apollo-centric collaborators, for a look at some delicious 1970s space hardware.

Get Your Glitch On With A PicoEMP And A 3D Printer

We’re not sure what [Aaron Christophel] calls his automated chip glitching setup built from a 3D printer, but we’re going to go ahead and dub it the “Glitch-o-Matic 9000.” Has a nice ring to it.

Of course, this isn’t a commercial product, or even a rig that’s necessarily intended for repeated use. It’s more of a tactical build, which is still pretty cool if you ask us. It started with a proof-of-concept exploration, summarized in the first video below. That’s where [Aaron] assembled and tested the major pieces, which included a PicoEMP, the bit that actually generates the high-voltage pulses intended to scramble a running microcontroller temporarily, along with a ChipWhisperer and an oscilloscope.

The trouble with the POC setup was that glitching the target chip, an LPC2388 microcontroller, involved manually scanning the business end of the PicoEMP over the package. That’s a tedious and error-prone process, which is perfect for automation. In the second video below, [Aaron] has affixed the PicoEMP to his 3D printer, giving him three-axis control of the tip position. That let him build up a heat map of potential spots to glitch, which eventually led to a successful fault injection attack and a clean firmware dump.

It’s worth noting that the whole reason [Aaron] had to resort to such extreme measures in the first place was the resilience of the target chip against power supply-induced glitching attacks. You might not need to build something like the Glitch-o-Matic, but it’s good to keep in mind in case you run up against such a hard target. Continue reading “Get Your Glitch On With A PicoEMP And A 3D Printer”

Supercon 2023: Bringing Arcade Classics To New Hardware

The processing power of modern game consoles is absolutely staggering when compared to the coin-op arcade machines of the early 1980s. Packed with terabytes of internal storage and gigabytes of RAM, there’s hardly a comparison to make with the Z80 cabinets that ran classics like Pac-Man. But despite being designed to pump out lifelike 4K imagery without breaking a virtual sweat, occasionally even these cutting-edge consoles are tasked with running one of those iconic early games like Dig Dug or Pole Position. Nostalgia is a hell of a drug…

As long as there are still demand for these genre-defining games, developers will have to keep figuring out ways to bring them to newer — and vastly more complex — systems. Which is precisely the topic of Bob Hickman’s 2023 Supercon talk, The Bits and Bytes of Bringing Arcade Classics to Game Consoles. Having spent decades as a professional game developer, he’s got plenty of experience with the unique constraints presented by both consoles and handhelds, and what it takes to get old code running on new silicon.

Continue reading “Supercon 2023: Bringing Arcade Classics To New Hardware”

Hacking An IP Camera To Run Your Own Software

Ah, generic unbranded IP cameras. Safe, secure? Probably not. [Alex] has been hacking around with one of his very own, and he’s recently busted the thing wide open.

Determining that the camera had a software update function built in, [Alex] saw an opening for hijinks. The first issue was that the camera only accepts encrypted update packages, which complicates things somewhat. However, through some smart reverse engineering, the format of the updates and their encryption method became obvious to [Alex]. Oh, and partly because there was a GitHub repository online featuring the source code used by the manufacturer to encrypt their updates. That definitely helped. It also led [Alex] to suspect the manufacturer may not have properly respected the open source license of some of the routines involved.

In the demo of the exploit, [Alex] has the camera reach out to www.pudim.com.br instead of the servers of the original manufacturer. That’s a pretty clear way to show that the camera has been owned.

We first featured [Alex]’s work in this space all the way back in 2019. It’s come a long way since then!

Continue reading “Hacking An IP Camera To Run Your Own Software”