Reverse Engineering

211 Articles

Getting Root On Cheap WiFi Repeaters, The Long Way Around

September 5, 2024 by 13 Comments

What can you do with a cheap Linux machine with limited flash and only a single free GPIO line? Probably not much, but sometimes, just getting root to prove you can is the main goal of a project. If that happens to lead somewhere useful, well, that’s just icing on the cake.

Like many interesting stories, this one starts on AliExpress, where [Easton] spied some low-cost WiFi repeaters, the ones that plug directly into the wall and extend your wireless network another few meters or so. Unable to resist the siren song, a few of these dongles showed up in the mailbox, ripe for the hacking. Spoiler alert: although the attempt on the first device had some success by getting a console session through the UART port and resetting the root password, [Easton] ended up bricking the repeater while trying to install an OpenWRT image.

The second attempt, this time on a different but similar device, proved more fruitful. The rudimentary web UI provided no easy path in, although it did a pretty good job enumerating the hardware [Easton] was working with. With the UART route only likely to provide temptation to brick this one too, [Easton] turned to a security advisory about a vulnerability that allows remote code execution through a specially crafted SSID. That means getting root on these dongles is as simple as a curl command — no hardware hacks needed!

As for what to do with a bunch of little plug-in Linux boxes with WiFi, we’ll leave that up to your imagination. We like [Easton]’s idea of running something like Pi-Hole on them; maybe Home Assistant would be possible, but these are pretty resource-constrained machines. Still, the lessons learned here are valuable, and at this price point, let the games begin.

Reverse-Engineering The AMD Secure Processor Inside The CPU

August 18, 2024 by 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 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 44 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.

If You Give A Dev A Tricked Out Xbox, They’ll Patch Halo 2

August 11, 2024 by 2 Comments

[Ryan Miceli] had spent a few years poring over and reverse-engineering Halo 2 when a friend asked for a favor. His friend created an improved Xbox with significant overclocks, RAM upgrades, BIOS hacks, and a processor swap. The goal was simple: patch the hardcoded maximum resolution from 480p to 720p and maybe even 1080p. With double the CPU clock speed but only a 15% overclock on the GPU, [Ryan] got to work.

Step one was to increase the size of the DirectX framebuffers. Increasing the output resolution introduced severe graphical glitches and rendering bugs. The game reuses the framebuffers multiple times as memory views, and each view encodes a header at the top with helpful information like width, height, and tiling. After patching that, [Ryan] had something more legible, but some models weren’t loading (particularly the water in the title screen). The answer was the texture accumulation layer. The Xbox has a hardware limitation of only sampling four textures per shader pass, which means you need a buffer the size of the render resolution to accumulate the textures if you want to sample more than four textures. Trying to boot the game resulted in an out-of-memory crash. The Xbox [Ryan] was working on had been upgraded with an additional 64MB of RAM, but the memory allocator in Halo 2 wasn’t taking advantage of it. Yet.

To see where the memory was going, [Ryan] wrote a new tool called XboxImageGrabber to show where memory was allocated and by whom. Most games make a few substantial initial allocations from the native allocator, then toss it over to a custom allocator tuned for their game. However, the extra 64MB of RAM was in dev consoles and meant as debug RAM, which meant the GPU couldn’t properly access it. Additionally, between the lower 64MB and upper is the Xbox kernel. Now, it became an exercise of patching the allocator to work with two blobs of memory instead of one contiguous one. It also moved runtime data into the upper 64MB while keeping video allocations in the lower. Ultimately, [Ryan] found it easier to patch the kernel to allow memory allocations the GPU could use in the upper 64MB of memory. Running the game at 720p resulted in only a semi-playable framerate, dropping to 10fps in a few scenes.

After some initial tests, [Ryan] concluded that it wasn’t the GPU or the CPU that was the bottleneck but the swap chain. Halo 2 turns VSync on by default, meaning it has to wait until a blank period before swapping between its two framebuffers. A simple tweak is to add a third frame buffer. The average FPS jumped 10%, and the GPU became the next bottleneck to tweak. With a light GPU overclock, the game was getting very close to 30fps. Luckily for [Ryan], no BIOS tweak was needed as the GPU clock hardware can be mapped and tweaked as an MMIO. After reverse engineering, a debugging feature to visual cache evictions, [Ryan] tuned the texture and geometry cache to minimize pop-ins that the original game was infamous for.

Overall, it’s an incredible hack with months of hard work behind it. The code for the patch is on Github, and there’s a video after the break comparing the patched and unpatched games. If you still need more Halo in your life, why not make yourself a realistic battle rifle from the game?

Continue reading “If You Give A Dev A Tricked Out Xbox, They’ll Patch Halo 2“ →

Laser Fault Injection On The Cheap

August 9, 2024 by 8 Comments

One can only imagine the wonders held within the crypto labs of organizations like the CIA or NSA. Therein must be machines of such sophistication that no electronic device could resist their attempts to defeat whatever security is baked into their silicon. Machines such as these no doubt bear price tags that only a no-questions-asked budget could support, making their techniques firmly out of reach of even the most ambitious home gamer.

That might be changing, though, with this $500 DIY laser fault injection setup. It comes to us from Finnish cybersecurity group [Fraktal], who have started a series of blog posts detailing how they built their open-source reverse-engineering rig. LFI is similar to other “glitching” attacks we’ve covered before, such as EMP fault injection, except that a laser shining directly on a silicon die is used to disrupt its operation rather than a burst of electromagnetic energy.

Since LFI requires shining the laser very precisely on nanometer-scale elements of a bare silicon die, nanopositioning is the biggest challenge. Rather than moving the device under attack, the [Fraktal] rig uses a modified laser galvanometer to scan an IR laser over the device. The galvo and the optical components are all easily available online, and they’ve started a repo to document the modifications needed and the code to tire everything together.

Of course, this technique requires the die in the device under study to be exposed, but [Fraktal] has made that pretty approachable too. They include instructions for milling away the epoxy from the lead-frame side of a chip, which is safer for the delicate structures etched into the top of the die. The laser can then shine directly through the die from the bottom. For “flip-chip” packages like BGAs, the same milling technique would be done from the top of the package. Either way, we can imagine a small CNC mill making the process safer and quicker, even though they seem to have done pretty well with a Dremel.

This looks like a fantastic reverse engineering tool, and we’re really looking forward to the rest of the story.
Continue reading “Laser Fault Injection On The Cheap” →

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

August 3, 2024 by 10 Comments

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” →