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

August 14, 2024 by Dan Maloney 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 Matthew Carlson 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 Dan Maloney 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 Dan Maloney 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” →

Reverse-Engineering A Shahed-136 Drone Air Data Computer

July 15, 2024 by Maya Posch 22 Comments

Top of the air data computer module, with pressure sensors, RS232 driver and DC-DC converter visible. (Credit: Le Labo de Michel, YouTube)

An air data computer (ADC) is a crucial part of an avionics package that can calculate the altitude, vertical speed, air speed and more from pressure (via pitot tubes) and temperature inputs. When your airplane is a one-way attack drone like Iran’s Shahed-136, you obviously need an ADC as well, but have to focus on making it both cheap and circumvent a myriad of sanctions. As [Michel] recently found out while reverse-engineering one of these ADCs. Courtesy of the Russo-Ukrainian war, hundreds of these Shahed drones are being destroyed every month, with some making it back down again intact enough for some parts to end up on EBay.

The overall design as captured in the schematic is rather straightforward, with the component choice probably being the most notable, as it uses an STM32G071 MCU and Analog Devices ADM3232 RS-232 driver, in addition to the two pressure sensors (by Silicon Microstructures Inc., now owned by TE). The DC-DC converter is a Mornsun URB24055-6WR3.

With the board in working condition, [Michel] hooks it up to a test setup to see the output on the serial interface when applying different pressures to the pressure sensor inputs. This results in a lot of ASCII data being output, all containing different values that were calculated by the firmware on the STM32 MCU. In the drone this data would then be used by the flight computer to make adjustments. Overall it’s a rather basic design that doesn’t seem to have a dedicated temperature sensor either, though [Michel] is still analyzing some details. A firmware dump would of course be rather fascinating as well.

Continue reading “Reverse-Engineering A Shahed-136 Drone Air Data Computer” →

Looking At Standard-Cell Design In The Pentium Processor

July 9, 2024 by Maya Posch 12 Comments

Die photo of the Intel Pentium processor with standard cells highlighted in red. The edges of the chip suffered some damage when I removed the metal layers. (Credit: Ken Shirriff)

Whereas the CPUs and similar ASICs of the 1970s had their transistors laid out manually, with the move from LSI to VLSI, it became necessary to optimize the process of laying out the transistors and the metal interconnects between them. This resulted in the development of standard-cells: effectively batches of transistors with each a specific function that could be chained together. First simple and then more advanced auto-routing algorithms handled the placement and routing of these standard elements, leading to dies with easily recognizable structures under an optical microscope. Case in point an original (P54C) Intel Pentium, which [Ken Shirriff] took an in-depth look at.

Using a by now almost unimaginably large 600 nm process, the individual elements of these standard cells including their PMOS and NMOS components within the BiCMOS process can be readily identified and their structure reverse-engineered. What’s interesting about BiCMOS compared to CMOS is that the former allows for the use of bipolar junction transistors, which offer a range of speed, gain and output impedance advantages that are beneficial for some part of a CPU compared to CMOS. Over time BiCMOS’ advantages became less pronounced and was eventually abandoned.

All in all, this glimpse at the internals of a Pentium processor provides a fascinating snapshot of high-end Intel semiconductor prowess in the early 1990s.

(Top image: A D flip-flop in the Pentium. Credit: [Ken Shirriff] )

Hackable Ham Radio Gives Up Its Mechanical Secrets

July 9, 2024 by Dan Maloney 4 Comments

Reverse-engineered schematics are de rigeur around these parts, largely because they’re often the key to very cool hardware hacks. We don’t get to see many mechanical reverse-engineering efforts, though, which is a pity because electronic hacks often literally don’t stand on their own. That’s why these reverse-engineered mechanical diagrams of the Quansheng UV-K5 portable amateur radio transceiver really caught our eye.

Part of the reason for the dearth of mechanical diagrams for devices, even one as electrically and computationally hackable as the UV-K5, is that mechanical diagrams are a lot less abstract than a schematic or even firmware. Luckily, this fact didn’t daunt [mdlougheed] from putting a stripped-down UV-K5 under a camera for a series of images to gather the raw data needed by photogrammetry package RealityCapture. The point cloud was thoughtfully scaled to match the dimensions of the radio’s reverse-engineered PC board, so the two models can work together.

The results are pretty impressive, especially for a first effort, and should make electromechanical modifications to the radio all the easier to accomplish. Hats off to [mdlougheed] for the good work, and let the mechanical hacks begin.