When I was growing up, about 4 or 5 years old, I had an unorthodox favourite type of reading material: service manuals for my dad’s audio equipment. This got to the point that I kept asking my parents for more service manuals, and it became a running joke in our family for a bit. Since then, I’ve spent time repairing tech and laptops in particular as a way of earning money, hanging out at a flea market in the tech section, then spending tons of time at our hackerspace. Nowadays, I’m active in online hacker groups, and I have built series of projects closely interlinked with modern-day consumer-facing tech.
Twenty three years later, is it a wonder I have a soft spot in my heart for schematics? You might not realize this if you’re only upcoming in the hardware hacking scene, but device schematics, whichever way you get them, are a goldmine of information you can use to supercharge your projects, whether you’re hacking on the schematic-ed device itself or not. What’s funny is, not every company wants their schematics to be published, but it’s ultimately helpful for the company in question, anyway.
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.0Not 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.
It’s our great pleasure to announce that Joe [Kingpin] Grand is going to be our keynote speaker at the 2022 Supercon!
If you don’t know Joe, he’s a hacker’s hacker. He’s behind the earliest DEFCON electronic badges, to which we can trace our modern #badgelife creative culture. He was at the l0pht when it became the most publicly visible hackerspace in the USA, at the dawn of what we now think of as cybersecurity. And moreover, he’s a tireless teacher of the art of hardware hacking.
Back in high school, I joined the stage crew — because of course I did. As student theater groups go, it was pretty active, and with two shows to produce each year, there was always a lot of work to do. I gravitated to the lighting crew, which was a natural fit for me. Besides the electrical part of the job, there was also a lot of monkeying around on scaffolding and rickety ladders to hang the lights, which was great fun for the young and immortal. Plus there was the lighting console to run during performances, a job I eventually took over for my last two years.
Unfortunately, the lighting system was a bit pathetic. The console was mounted in the stage right wings, rather than out in the front of the house where a sensible person would put it. And despite being only about ten years old, the dimmers were already starting to fail. The board had about 20 channels, but you could always count on one of the channels failing, sometimes during a show, requiring some heroics to repatch the lights into one of the dimmers we always left as a spare, just for the purpose.
My niece’s two favorite classes in high school this year are “Intro to AI” and “Ethical Hacking”. (She goes to a much cooler high school than I did!) In “Hacking”, she had an assignment to figure out some bug in some body of code. She was staring and staring, figuring and figuring. She went to her teacher and said she couldn’t figure it out, and he asked her if she’d tried to search for the right keywords on the Internet.
My niece responded “this is homework, and that’d be cheating”, a line she surely must have learned in her previous not-so-cool high school. When the teacher responded with “but doing research is how you learn to do stuff”, my niece was hooked. The class wasn’t abstract or academic any more; it became real. No arbitrary rules. Game on!
But I know how she feels. Whether it’s stubborn independence, or a feeling that I’m cheating, I sometimes don’t do my research first. But attend any hacker talk, where they talk about how they broke some obscure system or pulled off an epic trick. What is the first step? “I looked all over the Internet for the datasheet.” (Video) “I found the SDK and that made it possible.” (Video) “Would you believe this protocol is already documented?” In any serious hack, there’s always ample room for your creativity and curiosity later on. If others have laid the groundwork for you, get on it.
If you have trouble overcoming your pride, or NIH syndrome, or whatever, bear this in mind: the reason we share information with other hackers is to give them a leg up. Whoever documented that protocol did it to help you. Not only is there no shame in cribbing from them, you’re essentially morally obliged to do so. And to say thanks along the way!
This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter.
Want this type of article to hit your inbox every Friday morning? You should sign up!
Nobody likes opening up a hacking target and finding a black epoxy blob inside, but all hope is not lost. At least not if you’ve got the dedication and skills of [Jeroen Domburg] alias [Sprite_tm].
It all started when [Big Clive] ordered a chintzy Chinese musical meditation flower and found a black blob. But tantalizingly, the shiny plastic mess also included a 2 MB flash EEPROM. The questions then is: can one replace the contents with your own music? Spoiler: yes, you can! [Sprite_tm] and a team of Buddha Chip Hackers distributed across the globe got to work. (Slides here.)
[Jeroen] started off with binwalk and gets, well, not much. The data that [Big Clive] dumped had high enough entropy that it looks either random or encrypted, with the exception of a couple tiny sections. Taking a look at the data, there was some structure, though. [Jeroen] smelled shitty encryption. Now in principle, there are millions of bad encryption methods out there for every good one. But in practice, naive cryptographers tend to gravitate to a handful of bad patterns.
Bad pattern number one is XOR. Used correctly, XORing can be a force for good, but if you XOR your key with zeros, naturally, you get the key back as your ciphertext. And this data had a lot of zeros in it. That means that there were many long strings that started out the same, but they seemed to go on forever, as if they were pseudo-random. Bad crypto pattern number two is using a linear-feedback shift register for your pseudo-random numbers, because the parameter space is small enough that [Sprite_tm] could just brute-force it. At the end, he points out their third mistake — making the encryption so fun to hack on that it kept him motivated!
Decrypted, the EEPROM data was a filesystem. And the machine language turned out to be for an 8051, but there was still the issue of the code resident on the microcontroller’s ROM. So [Sprite_tm] bought one of these flowers, and started probing around the black blob itself. He wrote a dumper program that output the internal ROM’s contents over SPI. Ghidra did some good disassembling, and that let him figure out how the memory was laid out, and how the flow worked. He also discovered a “secret” ROM area in the chip’s flash, which he got by trying some random functions and looking for side effects. The first hit turned out to be a memcpy. Sweet.
[Neil555]’s Rosetta StoneMeanwhile, the Internet was still working on this device, and [Neil555] bought a flower too. But this one had a chip, rather than a blob, and IDing this part lead them to an SDK, and that has an audio suite that uses a derivative of WMA audio encoding. And that was enough to get music loaded into the flower. (Cue a short rick-rolling.) Victory!
Well, victory if all you wanted to do was hack your music onto the chip. As a last final fillip, [Sprite_tm] mashed the reverse-engineered schematic of the Buddha Flower together with [Thomas Flummer]’s very nice DIY Remoticon badge, and uploaded our very own intro theme music into the device on a badge. Bonus points? He added LEDs that blinked out the LSFR that were responsible for the “encryption”. Sick burn!
Editor’s Note: This is the last of the Remoticon 2 videos we’ve got. Thanks to all who gave presentations, to all who attended and participated in the lively Discord back channel, and to all you out there who keep the hacking flame alive. We couldn’t do it without you, and we look forward to a return to “normal” Supercon sometime soon.
Apple’s AirTags have caused a stir, but for all the wrong reasons. First, they turn all iPhones into Bluetooth LE beacon repeaters, without the owner’s permission. The phones listen for the AirTags, encrypt their location, and send the data on to the iCloud, where the tag’s owner can decrypt the location and track it down. Bad people have figured out that this lets them track their targets without their knowledge, turning all iPhone users into potential accomplices to stalkings, or worse.
Naturally, Apple has tried to respond by implementing some privacy-protecting features. But they’re imperfect to the point of being almost useless. For instance, AirTags now beep once they’ve been out of range of their owner’s phone for a while, which would surely alert the target that they’re being tracked, right? Well, unless the evil-doer took the speaker out, or bought one with the speaker already removed — and there’s a surprising market for these online.
If you want to know that you’re being traced, Apple “innovated with the first-ever proactive system to alert you of unwanted tracking”, which almost helped patch up the problem they created, but it only runs on Apple phones. It’s not clear what they meant by “first-ever” because hackers and researchers from the SeeMoo group at the Technical University of Darmstadt beat them to it by at least four months with the open-source AirGuard project that runs on the other 75% of phones out there.
Along the way, the SeeMoo group also reverse engineered the AirTag system, allowing anything that can send BLE beacons to play along. This opened the door for [Fabian Bräunlein]’s ID-hopping “Find You” attack that breaks all of the tracker-detectors by using an ESP32 instead of an AirTag. His basic point is that most of the privacy guarantees that Apple is trying to make on the “Find My” system rely on criminals using unmodified AirTags, and that’s not very likely.
To be fair, Apple can’t win here. They want to build a tracking network where only the good people do the tracking. But the device can’t tell if you’re looking for your misplaced keys or stalking a swimsuit model. It can’t tell if you’re silencing it because you don’t want it beeping around your dog’s neck while you’re away at work, or because you’ve planted it on a luxury car that you’d like to lift when its owners are away. There’s no technological solution for that fundamental problem.
But hackers are patching up the holes they can, and making the other holes visible, so that we can at least have a reasonable discussion about the tech’s tradeoffs. Apple seems content to have naively opened up a Pandora’s box of privacy violation. Somehow it’s up to us to figure out a way to close it.
This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter.
Want this type of article to hit your inbox every Friday morning? You should sign up!