Human-Interfacing Devices: HID Over I2C

In the previous two HID articles, we talked about stealing HID descriptors, learned about a number of cool tools you can use for HID hacking on Linux, and created a touchscreen device. This time, let’s talk about an underappreciated HID standard, but one that you might be using right now as you’re reading this article – I2C-HID, or HID over I2C.

HID as a protocol can be tunneled over many different channels. If you’ve used a Bluetooth keyboard, for instance, you’ve used tunneled HID. For about ten years now, I2C-HID has been heavily present in laptop space, it was initially used in touchpads, later in touchscreens, and now also in sensor hubs. Yes, you can expose sensor data over HID, and if you have a clamshell (foldable) laptop, that’s how the rotation-determining accelerometer exposes its data to your OS.

This capacitive touchscreen controller is not I2C-HID, even though it is I2C. By [Raymond Spekking], CC-BY-SA 4.0
Not every I2C-connected input device is I2C-HID. For instance, if you’ve seen older tablets with I2C-connected touchscreens, don’t get your hopes up, as they likely don’t use HID – it’s just a complex-ish I2C device, with enough proprietary registers and commands to drive you crazy even if your logic analysis skills are on point. I2C-HID is nowhere near that, and it’s also way better than PS/2 we used before – an x86-only interface with limited capabilities, already almost extinct from even x86 boards, and further threatened in this increasingly RISCy world. I2C-HID is low-power, especially compared to USB, as capable as HID goes, compatible with existing HID software, and ubiquitous enough that you surely already have an I2C port available on your SBC.

In modern world of input devices, I2C-HID is spreading, and the coolest thing is that it’s standardized. The standardization means a lot of great things for us hackers. For one, unlike all of those I2C touchscreen controllers, HID-I2C devices are easier to reuse; as much as information on them might be lacking at the moment, that’s what we’re combating right now as we speak! If you are using a recent laptop, the touchpad is most likely I2C-HID. Today, let’s take a look at converting one of those touchpads to USB HID.

A Hackable Platform

Continue reading “Human-Interfacing Devices: HID Over I2C”

Logic Analyzers: Decoding And Monitoring

Last time, we looked into using a logic analyzer to decode SPI signals of LCD displays, which can help us reuse LCD screens from proprietary systems, or port LCD driver code from one platform to another! If you are to do that, however, you might find a bottleneck – typically, you need to capture a whole bunch of data and then go through it, comparing bytes one by one, which is quite slow. If you have tinkered with Pulseview, you probably have already found an option to export decoded data – all you need to do is right-click on the decoder output and you’ll be presented with a bunch of options to export it. Here’s what you will find:

2521888-2521888 I²C: Address/data: Start
2521896-2521947 I²C: Address/data: Address write: 22
2521947-2521954 I²C: Address/data: Write
2521955-2521962 I²C: Address/data: ACK
2521962-2522020 I²C: Address/data: Data write: 01
2522021-2522028 I²C: Address/data: ACK
2522030-2522030 I²C: Address/data: Start repeat
2522038-2522089 I²C: Address/data: Address read: 22
2522089-2522096 I²C: Address/data: Read
2522096-2522103 I²C: Address/data: ACK
2522104-2522162 I²C: Address/data: Data read: 91
2522162-2522169 I²C: Address/data: NACK
2522172-2522172 I²C: Address/data: Stop

Whether on the screen or in an exported file, the decoder output is not terribly readable – depending on the kind of interface you’re sniffing, be it I2C, UART or SPI, you will get five to ten lines of decoder output for every byte transferred. If you’re getting large amounts of data from your logic analyzer and you want to actually understand what’s happening, this quickly will become a problem – not to mention that scrolling through the Pulseview window is not a comfortable experience.

The above output could look like this: 0x22: read 0x01 ( DEV_ID) = 0x91 (0b10010001). Yet, it doesn’t, and I want to show you how to correct this injustice. Today, we supercharge Pulseview with a few external scripts, and I’ll show you how to transfer large amounts of Sigrok decoder output data into beautiful human-readable transaction printouts. While we’re at it, let’s also check out commandline sigrok, avoiding the Pulseview UI altogether – with sigrok-cli, you can easily create a lightweight program that runs in the background and saves all captured data into a text file, or shows it on a screen in realtime! Continue reading “Logic Analyzers: Decoding And Monitoring”

Adjustable Lights Help Peer Inside Chips With IR

If you’re used to working through a microscope, you’ve probably noticed that the angle of the light greatly affects how your workpiece looks. Most of us prefer the relatively flat lighting provided by a ring light, but variable angle side lighting can be useful too, especially when you’re peering inside ICs to make sure the silicon is what it’s supposed to be.

That’s what [Bunnie] is working on these days with his Project IRIS, short for “Infrared in situ,” a non-destructive method for looking inside chip packages. The technique relies on the fact that silicon is transparent to certain wavelengths of light, and that some modern IC packages expose the underside of the silicon die directly to the outside world. Initial tests indicated that the angle of the incident IR light was important to visualizing features on the metal interconnects layered onto the silicon, so [Bunnie] designed a two-axis light source for his microscope. The rig uses curved metal tracks to guide a pair of IR light sources through an arc centered on the focal point of the microscope stage. The angle of each light source relative to the stage can be controlled independently, while the whole thing can swivel around the optical axis of the microscope to control the radial angle of the lighting.

The mechanism [Bunnie] designed to accomplish all this is pretty complex. Zenith angle is controlled by a lead screw driving a connecting rod to the lights on their guide tracks, while the azimuth of the lights is controlled by a separate motor and pulley driving a custom-built coaxial bearing. The whole optical assembly is mounted on a Jubilee motion platform for XYZ control. The brief videos below show the lights being put through their paces, along with how changing the angle of the light affects the view inside a chip.

Continue reading “Adjustable Lights Help Peer Inside Chips With IR”

Hackaday Links Column Banner

Hackaday Links: March 31, 2024

Battlelines are being drawn in Canada over the lowly Flipper Zero, a device seen by some as an existential threat to motor vehicle owners across the Great White North. The story started a month or so ago, when someone in the government floated the idea of banning devices that could be “used to steal vehicles by copying the wireless signals for remote keyless entry.” The Flipper Zero was singled out as an example of such a nefarious device, even though relatively few vehicles on the road today can be boosted using the simple replay attack that a Flipper is capable of, and the ones that are vulnerable to this attack aren’t all that desirable — apologies to the 1993 Camry, of course. With that threat hanging in the air, the folks over at Flipper Devices started a Change.org petition to educate people about the misperceptions surrounding the Flipper Zero’s capabilities, and to urge the Canadian government to reconsider their position on devices intended to explore the RF spectrum. That last bit is important, since transmit-capable SDR devices like the HackRF could fall afoul of a broad interpretation of the proposed ban; heck, even a receive-only SDR dongle might be construed as a restricted device. We’re generally not much for petitions, but this case might represent an exception. “First they came for the Flipper Zero, but I did nothing because I don’t have a Flipper Zero…”

Continue reading “Hackaday Links: March 31, 2024”

Generator Control Panel Unlocked With Reverse Engineering Heroics

Scoring an interesting bit of old gear on the second-hand market is always a bit of a thrill — right up to the point where you realize the previous owner set some kind of security code on it. Then it becomes a whole big thing to figure out, to the point of blunting the dopamine hit you got from the original purchase.

Fear not, though, because there’s dopamine aplenty if you can copy what [Buy it Fix it] did to decode the PIN on a used generator control panel. The panel appears to be from a marine generator, and while it powered up fine, the menu used to change the generator’s configuration options is locked by a four-digit PIN. The manufacturer will reset it, but that requires sending it back and paying a fee, probably considerable given the industrial nature of the gear.

Instead of paying up, [Buy it Fix it] decided to look for a memory chip that might store the PIN. He identified a likely suspect, a 24LC08B 8-Kb serial EEPROM, and popped it off to read its contents. Nothing was immediately obvious, but blanking the chip and reinstalling it cleared the PIN, so he at least knew it was stored on the chip. Many rounds of soldering and desoldering the chip followed, blanking out small sections of memory each time until the PIN was located. The video below edits out a lot of the rework, but gives the overall gist of the hack.

To be honest, we’re not sure if the amount of work [Buy it Fix it] put into this was less than taking a couple of hours to punch in PINs and brute-force it. Then again, if he hadn’t done the reverse engineering he wouldn’t have stumbled upon where the generator parameters like running time and power figures were stored. And it’s not really his style, either; we’ve seen him perform similar heroics on everything from tractors to solar inverters, after all.

Continue reading “Generator Control Panel Unlocked With Reverse Engineering Heroics”

Extracting SecOC Keys From A 2021 Toyota RAV4 Prime

With the recently introduced SecOC (Secure Onboard Communication) standard, car manufacturers seek to make the CAN bus networks that form the backbone of modern day cars more secure. This standard adds a MAC (message authentication code) to the CAN messages, which can be used to validate that these messages come from a genuine part of the car, and not from a car thief or some third-party peripheral.

To check that it isn’t possible to circumvent SecOC, [Willem Melching] and [Greg Hogan] got their hands on the power steering (EPS) unit of a Toyota RAV4 Prime, as one of the first cars to implement this new security standard.

The 2021 Toyota RAV4 Prime's power steering unit on the examination bench. (Credit: Willem Melching)
The 2021 Toyota RAV4 Prime’s power steering unit on the examination bench. (Credit: Willem Melching)

As noted by [Willem], the ultimate goal is to be able to run the open source driver assistance system openpilot on these SecOC-enabled cars, which would require either breaking SecOC, or following the official method of ‘rekeying’ the SecOC gateway.

After dumping the firmware of the EPS Renesas RH850/P1M-E MCU via a voltage fault injection, the AES-based encryption routines were identified, but no easy exploits found in the main application. This left the bootloader as the next target.

Ultimately they managed to reverse-engineer the bootloader to determine how the update procedure works, which enabled them to upload shellcode. This script then enabled them to extract the SecOC keys from RAM and send these over the CAN bus. With these keys the path is thus opened to allow any device to generate CAN messages with valid SecOC MACs, effectively breaking encryption. Naturally, there are many caveats with this discovery.

Continue reading “Extracting SecOC Keys From A 2021 Toyota RAV4 Prime”

Mapping The Nintendo Switch PCB

As electronics have advanced, they’ve not only gotten more powerful but smaller as well. This size is great for portability and speed but can make things like repair more inaccessible to those of us with only a simple soldering iron. Even simply figuring out what modern PCBs do is beyond most of our abilities due to the shrinking sizes. Thankfully, however, [μSoldering] has spent their career around state-of-the-art soldering equipment working on intricate PCBs with tiny surface-mount components and was just the person to document a complete netlist of the Nintendo Switch through meticulous testing, a special camera, and the use of a lot of very small wires.

The first part of reverse-engineering the Switch is to generate images of the PCBs. These images are taken at an astonishing 6,000 PPI and as a result are incredibly large files. But with that level of detail the process starts to come together. A special piece of software is used from there that allows point-and-click on the images to start to piece the puzzle together, and with an idea of where everything goes the build moves into the physical world.

[μSoldering] removes all of the parts on the PCBs with hot air and then meticulously wires them back up using a custom PCB that allows each connection to be wired up and checked one-by-one. With everything working the way it is meant to, a completed netlist documenting every single connection on the Switch hardware can finally be assembled.

The final documentation includes over two thousand photos and almost as many individual wires with over 30,000 solder joints. It’s an impressive body of work that [μSoldering] hopes will help others working with this hardware while at the same time keeping their specialized skills up-to-date. We also have fairly extensive documentation about some of the Switch’s on-board chips as well, further expanding our body of knowledge on how these gaming consoles work and how they’re put together.