Reverse Engineering A Keyboard Driver Uncovers A Self-Destruct Code

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”

Hackaday Links Column Banner

Hackaday Links: May 28, 2023

The Great Automotive AM Radio War of 2023 rages on, with the news this week that Ford has capitulated, at least for now. You’ll recall that the opening salvo came when the US automaker declared that AM radio was unusable in their EV offerings thanks to interference generated by the motor controller. Rather than fixing the root problem, Ford decided to delete the AM option from their EV infotainment systems, while letting their rolling EMI generators just keep blasting out interference for everyone to enjoy. Lawmakers began rattling their sabers in response, threatening legislation to include AM radio in every vehicle as a matter of public safety. Ford saw the writing on the wall and reversed course, saying that AM is back for at least the 2024 model year, and that vehicles already delivered without it will get a fix via software update.

Continue reading “Hackaday Links: May 28, 2023”

A picture of the bottom of the Pi 4 PCB, showing the three points you need to use to tap into the Pi 4 I2C bus going to the PMIC

Dead Raspberry Pi Boards, PMICs, And New Hope

Since the Raspberry Pi 3B+ release, the Pi boards we all know and love gained one more weakpoint – the PMIC chip, responsible for generating all the power rails a Pi needs. Specifically, the new PMIC was way more vulnerable to shorting 5V and 3.3V power rails together – something that’s trivial to do on a Raspberry Pi, and would leave you with a bricked board. Just replacing the PMIC chip, the MxL7704, wouldn’t help since the Raspberry Pi version of this chip is customized – but now, on Raspberry Pi forums, [Nefarious19] has reportedly managed to replace it and revive their Pi.

First off, you get a replacement PMIC and reflow it – and that’s where, to our knowledge, people have stopped so far. The next step proposed by [Nefarious19] is writing proper values into the I2C registers of the PMIC. For that, you’d want a currently-alive Pi – useful as both I2C controller for writing the values in, and as a source of known-good values. That said, if you go with the values that have been posted online, just having something like a Pi Pico for the I2C part ought to be enough.

[Nefarious19] reports a revived Pi, and this is way more hopeful than the “PMIC failures are unfixable” conclusion we’ve reached before. The instructions are not quite clear – someone else in the thread reports an unsuccessful attempt doing the same, and it might be that there’s a crucial step missing in making the values persist. However, such an advancement is notable, and we trust our readers to take the lead.

A week ago, [Mangy_Dog] on Hackaday Discord brought up fixing Raspberry Pi boards – given that the Raspberry Pi shortages are still an issue, digging up your broken Pi and repairing it starts making sense budget-wise. It’s no longer the ages where you could buy broken Pi boards by the hundred, and we imagine our readers have been getting creative. What are your experiences with fixing Raspberry Pi boards?

An RGB laser projector opened up on a workbench

Laser Projector Needs Hardware Hack After Software Mod

You probably recognize that dreadful feeling when you reboot a gadget after updating its firmware, only to be greeted by a blank screen and an unresponsive device. This apparently happened to the previous owner of a bricked RGB laser projector that [Buy It Fix It] got his hands on: it briefly flashed its laser on power-up but otherwise remained completely dead.

A thorough inspection of the major components didn’t reveal any physical damage, so the issue had to be in software. [Buy It Fix It] managed to connect his Segger J-link programmer to the STM32 main processor and downloaded the contents of its firmware, only to find the remains of a PDF file which seemed to have been accidentally flashed into the chip’s program space. Fixing the device should then just be a matter of restoring the proper firmware, but [Buy It Fix It] wasn’t able to find a copy of it anywhere.

A PCB with a few mod wires on itWhat he did find was Maximus64’s GitHub repository that contained a software mod for a different projector model, as well as its original firmware. Flashing that version didn’t fix [Buy It Fix It]’s projector either, although it did now start to actuate its galvos.

A bit of reverse engineering revealed that the two projectors were very similar from a hardware point of view, but had their laser drivers hooked up to different I/O pins: simply cutting the board traces and soldering some wires to re-route the signals was enough to bring the projector back into a working state.

Having to modify hardware in order to make it fit a piece of software is unfortunate, but sometimes you just have to make do with what you’ve got. If you’ve got no firmware to begin with, then you might even have to write your own from scratch.

Continue reading “Laser Projector Needs Hardware Hack After Software Mod”

The Meraki AP PCB on a desk, case-less, with three USB-UARTs connected to its pins - one for interacting with the device, and two for monitoring both of the UART data lines.

Flashing Booby-Trapped Cisco AP With OpenWrt, The Hard Way

Certain manufacturers seriously dislike open-source firmware for their devices, and this particular hack deals with quite extreme anti-hobbyist measures. The Meraki MR33, made by Cisco, is a nice access point hardware-wise, and running OpenWrt on it is wonderful – if not for the Cisco’s malicious decision to permanently brick the CPU as soon as you enter Uboot through the serial port. This AP seems to be part of a “hardware as a service” offering, and the booby-trapped Uboot was rolled out by an OTA update some time after the OpenWrt port got published.

There’s an older Uboot version available out there, but you can’t quite roll back to it and up to a certain point, there was only a JTAG downgrade path noted on the wiki – with its full description consisting of a “FIXME: describe the process” tag. Our hacker, an anonymous user from the [SagaciousSuricata] blog, decided to go a different way — lifting, dumping and modifying the onboard flash in order to downgrade the bootloader, and guides us through the entire process. There’s quite a few notable things about this hack, like use of Nix package manager to get Python 2.7 on an OS which long abandoned it, and a tip about a workable lightweight TFTP server for such work, but the flash chip part caught our eye.

The flash chip is in TSOP48 package and uses a parallel interface, and an iMX6.LL devboard was used to read, modify and flash back the image — hotswapping the chip, much like we used to do with old parallel-interface BIOS chips. We especially liked the use of FFC cables and connectors for connecting the flash chip to the devboard in a way that allows hotswapping – now that we can see it, the TSOP 0.5 mm pitch and 0.5 mm FFC hardware are a match made in heaven. This hack, of course, will fit many TSOP48-equipped devices, and it’s nice to have a toolkit for it in case you don’t have a programmer handy.

In the end, the AP got a new lease of life, now governed by its owner as opposed to Cisco’s whims. This is a handy tutorial for anyone facing a parallel-flash-equipped device where the only way appears to be the hard way, and we’re glad to see hackers getting comfortable facing such challenges, whether it’s parallel flash, JTAG or power glitching. After all, it’s great when your devices can run an OS entirely under your control – it’s historically been that you get way more features that way, but it’s also that the manufacturer can’t pull the rug from under your feet like Amazon did with its Fire TV boxes.

We thank [WifiCable] for sharing this with us!

(Ed Note: Changed instances of “OpenWRT” to “OpenWrt”.)

Ethics Whiplash As Sonos Tries Every Possible Wrong Way To Handle IoT Right

We’re trying to figure out whether Sonos was doing the right thing, and it’s getting to the point where we need pins, a corkboard, and string. Sonos had been increasing the functionality of its products and ran into a problem as they hit a technical wall. How would they keep the old speakers working with the new speakers? Their solution was completely bizarre to a lot of people.

First, none of the old speakers would receive updates anymore. Which is sad, but not unheard of. Next they mentioned that if you bought a new speaker and ran it on the same network as an old speaker, neither speaker would get updates. Which came off as a little hostile, punishing users for upgrading to newer products.

The final bit of weirdness was their solution for encouraging users to ditch their old products. They called it, “trading in for a 30% discount”, but it was something else entirely. If a user went into the system menu of an old device and selected to put it in “Recycle Mode” the discount would be activated on their account. Recycle Mode would then, within 30 days, brick the device. There was no way to cancel this, and once the device was bricked it wouldn’t come back. The user was then instructed to take the Sonos to a recycling center where it would be scrapped. Pictures soon began to surface of piles of bricked Sonos’s. There would be no chance to sell, repair, or otherwise keep alive what is still a fully functioning premium speaker system.

Why would a company do this to their customers and to themselves? Join me below for a guided tour of how the downsides of IoT ecosystem may have driven this choice.

Continue reading “Ethics Whiplash As Sonos Tries Every Possible Wrong Way To Handle IoT Right”

Shorting Pins On A Raspberry Pi Is A Bad Idea; PMIC Failures Under Investigation

You may have noticed, we’re fans of the Raspberry Pi here at Hackaday. Hardly a day goes by that we don’t feature a hack that uses a Pi somewhere in the build. As useful as the Pis are, they aren’t entirely without fault. We’ve talked about the problems with the PoE hat, and multiple articles about keeping SD cards alive. But a new failure mode has popped that is sometimes, but not always, caused by shorting the two power rails on the board.

The Pi 3 B+ has a new PMIC (Power Management Integrated Circuit) made by MaxLinear. This chip, the MxL7704, is a big part of how the Raspberry Pi foundation managed to make the upgrades to the Pi 3 without raising the price over $35.

A quick look at the Raspberry Pi forum shows that some users have been experiencing a specific problem with their new Raspberry Pi 3 B+ units, where the power LED will illuminate but the unit will not boot. The giveaway is zero voltage on the 3v3 pin. It’s a common enough problem that it’s even mentioned in the official boot problems thread.

Make sure the probe you are measuring with does not slip, and simultaneously touches any of the other GPIO pins, as that might instantly destroy your PI, especially shorting the 3V3 pin to the 5V pin will prove to be fatal.

Continue reading “Shorting Pins On A Raspberry Pi Is A Bad Idea; PMIC Failures Under Investigation”