Audio Eavesdropping Exploit Might Make That Clicky Keyboard Less Cool

Despite their claims of innocence, we all know that the big tech firms are listening to us. How else to explain the sudden appearance of ads related to something we’ve only ever spoken about, seemingly in private but always in range of a phone or smart speaker? And don’t give us any of that fancy “confirmation bias” talk — we all know what’s really going on.

And now, to make matters worse, it turns out that just listening to your keyboard clicks could be enough to decode what’s being typed. To be clear, [Georgi Gerganov]’s “KeyTap3” exploit does not use any of the usual RF-based methods we’ve seen for exfiltrating data from keyboards on air-gapped machines. Rather, it uses just a standard microphone to capture audio while typing, building a cluster map of the clicks with similar sounds. By analyzing the clusters against the statistical likelihood of certain sequences of characters appearing together — the algorithm currently assumes standard English, and works best on clicky mechanical keyboards — a reasonable approximation of the original keypresses can be reconstructed.

If you’d like to see it in action, check out the video below, which shows the algorithm doing a pretty good job decoding text typed on an unplugged keyboard. Or, try it yourself — the link above implements KeyTap3 in-browser. We gave it a shot, but as a member of the non-mechanical keyboard underclass, it couldn’t make sense of the mushy sounds it heard. Then again, our keyboard inferiority affords us some level of protection from the exploit, so there’s that.

Editors Note: Just tried it on a mechanical keyboard with Cherry MX Blue switches and it couldn’t make heads or tails of what was typed, so your mileage may vary. Let us know if it worked for you in the comments.

What strikes us about this is that it would be super simple to deploy an exploit like this. Most side-channel attacks require such a contrived scenario for installing the exploit that just breaking in and stealing the computer would be easier. All KeyTap needs is a covert audio recording, and the deed is done.

Continue reading “Audio Eavesdropping Exploit Might Make That Clicky Keyboard Less Cool”

The TPM module that Viktor designed, inserted into the motherboard

TPM Module Too Expensive? DIY Your Own Easily!

Since Windows 11 has announced its TPM module requirement, the prices for previously abundant and underappreciated TPM add-on boards for PC motherboards have skyrocketed. We’ve been getting chips and soldering them onto boards of our own design, instead – and [viktor]’s project is one more example of that. [Viktor] has checked online marketplace listings for a TPM module for his Gigabyte AORUS GAMING 3 motherboard, and found out they started at around 150EUR – which is almost as much as the motherboard itself costs. So, as any self-respecting hacker, he went the DIY way, and it went with hardly a hitch.

Following the schematic from the datasheet, he quickly made a simple KiCad layout, matching it to the pinout from his motherboard’s user manual, then ordered the boards from PCBWay and SLB9665 chips from eBay. After both arrived, [viktor] assembled the boards, and found one small mistake – he designed a module for 2.54mm pin headers, but his motherboard had 2.0mm headers. He wired up a small adapter to make his assembled V1.0 boards work, and Windows 11 installed without any TPM complaints. He shows that he’s designed a new, V1.1 version with an updated connector, too, and published its (untested but should work) design files for us on GitHub. These modules can vary, by manufacturer and motherboard series, but with each module published, a bunch of hackers can save money – and get a weekend project virtually guaranteed to work out.

Regardless of whether the goal of running Windows 11 is ultimately worthwhile, it has been achieved. With scalpers preying on people who just want to use their hardware with a new OS, rolling your own TPM PCB is a very attractive solution! Last time we covered a DIY TPM module for ASrock server motherboards, we had a vivid discussion in the comments, and if you’re looking to create your own TPM board, you could do worse than checking them out for advice and insights!

The microcontroller described in the article, on the PCB taken out of the kettle

Dumping Encrypted-At-Rest Firmware Of Xiaomi Smart Kettle

[aleaksah] got himself a Mi Smart Kettle Pro, a kettle with Bluetooth connectivity, and a smartphone app to go with it. Despite all the smarts, it couldn’t be turned on remotely. Energized with his vision of an ideal smart home where he can turn the kettle on in the morning right as he wakes up, he set out to right this injustice. (Russian, translated) First, he tore the kettle down, intending to dump the firmware, modify it, and flash it back. Sounds simple enough — where’s the catch?

This kettle is built around the QN9022 controller, from the fairly open QN902X family of chips. QN9022 requires an external SPI flash chip for code, as opposed to its siblings QN9020 and QN9021 which have internal flash akin to ESP8285. You’d think dumping the firmware would just be a matter of reading that flash, but the firmware is encrypted at rest, with a key unique to each MCU and stored internally. As microcontroller reads the flash chip contents, they’re decrypted transparently before being executed. So, some other way had to be found, involving the MCU itself as the only entity with access to the decryption key.

Continue reading “Dumping Encrypted-At-Rest Firmware Of Xiaomi Smart Kettle”

For Once, The Long Arm Of John Deere Presses The Right Button

Over many years now we’ve covered right-to-repair stories, and among them has been a constant bête noire. The American farm machinery manufacturer John Deere whose instantly recognisable green and yellow tractors have reliably tilled the soil for over a century, have become the poster child for inappropriate use of DRM. It’s enough to make any farmer see red, but there’s a story from CNN which shows another side to manufacturer control. A Deere dealership in Melitopol, Ukraine, was looted by invading Russian forces, who took away an estimated $5m worth of farm machinery. The perfect crime perhaps, save for the Deere computer system being used to remotely disable them leaving the crooks with combine harvesters they can’t even start.

It makes for a good news story showing the Ukranians getting one over on the looters, and since on-farm thefts are a hot topic anywhere in the world it’s not entirely unexpected that Deere would have incorporated a kill-switch in their products. Recently we covered a look at how the relationship between motor vehicle owner and manufacturer is changing from one of product ownership to software licence, and this is evidently an example of the same thing in the world of machinery. It’s reported that the looters are seeking the help of tractor hackers, which may be unfortunate for them since the world’s go-to source for hacked Deere software is Ukraine. Perhaps they would be better remembering that Russia has legendary tractors of its own.

Thanks [Robert Piston] for the tip.

This Week In Security: Android And Linux, VirusTotal, More Psychic Signatures

To start our week of vulnerabilities in everything, there’s a potentially big vulnerability in Android handsets, but it’s Apple’s fault. OK, maybe that’s a little harsh — Apple released the code to their Apple Lossless Audio Codec (ALAC) back in 2011 under the Apache License. This code was picked up and shipped as part of the driver stack for multiple devices by various vendors, including Qualcomm and MediaTek. The problem is that the Apple code was terrible, one researcher calling it a “walking colander” of security problems.

Apple has fixed their code internally over the years, but never pushed those updates to the public code-base. It’s a fire-and-forget source release, and that can cause problems like this. The fact that ALAC was released under a permissive license may contribute to the problem. Someone (in addition to Apple) likely found and fixed the security problems, but the permissive license doesn’t require sharing those fixes with a broader community. It’s worth pondering whether a Copyleft license like the GPL would have gotten a fix distributed years ago.

Regardless, CVE-2021-0674 and CVE-2021-0675 were fixed in both Qualcomm and MediaTek’s December 2021 security updates. These vulnerabilities are triggered by malicious audio files, and can result in RCE. An app could use this trick to escape the sandbox and escalate privileges. This sort of flaw has been used by actors like the NSO group to compromise devices via messaging apps. Continue reading “This Week In Security: Android And Linux, VirusTotal, More Psychic Signatures”

The dash of Xiaomi Mi 1S scooter, with the top panel taken off and an USB-UART adapter connected to the dashboard, sniffing the firmware update process

Xiaomi Cryptographically Signs Scooter Firmware – What’s Next?

[Daljeet Nandha] from [RoboCoffee] writes to us, sharing his research on cryptographic signature-based firmware authenticity checks recently added to the Xiaomi Mi scooter firmware. Those scooters use an OTA firmware update mechanism over BLE, so you can update your scooter using nothing but a smartphone app – great because you can easily get all the good new features, but suboptimal because you can easily get all the bad new features. As an owner of a Mi 1S scooter but a hacker first and foremost, [Daljeet] set up a HTTPS proxy and captured the firmware files that the app downloaded from Xiaomi servers, dug into them, and summarized what he found.

Scooter app firmware update dialog, saying "New firmware update available. Update now?"
Confirming this update will indefinitely lock you out of any third-party OTA updates

Unlike many of the security measures we’ve seen lacking-by-design, this one secures the OTA firmware updates with what we would consider the industry standard – SHA256 hash with elliptic cryptography-backed signing. As soon as the first firmware version implementing signature checks is flashed into your scooter, it won’t accept anything except further firmware binaries that come with Xiaomi’s digital signature. Unless a flaw is found in the signature checking implementation, the “flash a custom firmware with a smartphone app” route no longer seems to be a viable pathway for modding your scooter in ways Xiaomi doesn’t approve of.

Having disassembled the code currently available, [Daljeet] tells us about all of this – and more. In his extensive writeup, he shares scripts he used on his exploration journey, so that any sufficiently motivated hacker can follow in his footsteps, and we highly recommend you take a look at everything he’s shared. He also gives further insights, explaining some constraints of the OTA update process and pointing out a few security-related assumptions made by Xiaomi, worth checking for bypassing the security implemented. Then, he points out the firmware filenames hinting that, in the future, the ESC (Electronic Speed Control, responsible for driving the motors) board firmware might be encrypted with the same kind of elliptic curve cryptography, and finds a few update hooks in the decompiled code that could enable exactly that in future firmware releases.

One could argue that these scooters are typically modified to remove speed limits, installed there because of legal limitations in a variety of countries. However, the legal speed limits are more nuanced than a hard upper boundary, and if the hardware is capable of doing 35km/h, you shouldn’t be at mercy of Xiaomi to be able to use your scooter to its full extent where considerate. It would be fair to assert, however, that Xiaomi did this because they don’t want to have their reputation be anywhere near “maker of scooters that people can modify to break laws with”, and therefore we can’t expect them to be forthcoming.

Furthermore, of course, this heavily limits reuse and meaningful modification of the hardware we own. If you want to bring a retired pay-to-ride scooter back to usefulness, add Bluetooth, or even rebuild the scooter from the ground up, you should be able to do that. So, how do we go around such restrictions? Taking the lid off and figuring out a way to reflash the firmware through SWD using something like a Pi Pico, perhaps? We can’t wait to see what hackers figure out.

This Week In Security: Java’s Psychic Signatures, AWS Escape, And A Nasty Windows Bug

Java versions 15, 16, 17, and 18 (and maybe some older versions) have a big problem, ECDSA signature verification is totally broken. The story is a prime example of the dangers of unintended consequences, the pitfall of rolling your own crypto, and why to build a test suite for important code. In Java 15, the ECDSA verification code was re-written, moving the code from C++ to a Java-native implementation. The new code misses an important check, that the initialization and proof values are both non-zero.

Continue reading “This Week In Security: Java’s Psychic Signatures, AWS Escape, And A Nasty Windows Bug”