High-Resolution MIDI Controller

January 5, 2024 by Bryan Cockfield 20 Comments

For an older standard, MIDI has remarkable staying power in the music industry. It remains the de facto digital interface between computers and instruments thanks to its open nature, but its age does show a little bit. Sending control change (CC) messages, for example, was originally designed to fit within seven bits, which doesn’t give particularly fine resolution compared to more capable modern computers. To work around that, a fourteen-bit message is possible, doubling the resolution, and this MIDI interface uses this larger amount of data to send these high-resolution CC messages.

The 14-bit messages are actually fairly well documented but are a bit obscure, with very limited hardware support. To that end, [Gero] set about building this control interface to solve that problem. It’s made up of only eight knobs, each of which is mapped one-to-one to a parameter on the computer, allowing the interface to feel more like an analog device where the knob corresponds directly to a change in an aspect of the sound. The platform is built around a Teensy 4.0 and some multiplexers to handle all of the knobs, with the open source software available for anyone to use to modify their actions. [Gero] was aiming for high fidelity for all aspects of this controller, not just the improved digital resolution, and made a number of other improvements to it as well like re-greasing the potentiometer knobs and a custom 3D printed enclosure.

All of the software is available for use, as well as the files to print the case. [Gero] is also working on a PCB to make the construction of the device a little more streamlined, but for now, it requires a bit of soldering off-the-shelf parts together. The MIDI standard is open as well, which allows for a lot of innovation in the creation of musical instruments from unique hardware. This project builds a MIDI synthesizer with parts from a Sega Genesis.

This Week In Security: Bitwarden, Reverse RDP, And Snake

January 5, 2024 by Jonathan Bennett 10 Comments

This week, we finally get the inside scoops on some old stories, starting with the Bitwarden Windows Hello problem from last year. You may remember, Bitwarden has an option to use Windows Hello as a vault unlock option. Unfortunately, the Windows credential API doesn’t actually encrypt credentials in a way that requires an additional Windows Hello verification to unlock. So a derived key gets stored to the credential manager, and can be retrieved through a simple API call. No additional biometrics needed. Even with the Bitwarden vault locked and application closed.

There’s another danger, that doesn’t even require access to the the logged-in machine. On a machine that is joined to a domain, Windows backs up those encryption keys to the Domain Controller. The encrypted vault itself is available on a domain machine over SMB by default. A compromised domain controller could snag a bitwarden vault without ever even running code on the target machine. The good news is that this particular problem with Bitwarden and Windows Hello is now fixed, and has been since version 2023.10.1.

Reverse RDP Exploitation

We normally think about the Remote Desktop Protocol as dangerous to expose to the internet. And it is. Don’t put your RDP service online. But reverse RDP is the idea that it might also be dangerous to connect an RDP client to a malicious server. And of course, multiple RDP implementations have this problem. There’s rdesktop, FreeRDP, and Microsoft’s own mstsc that all have vulnerabilities relating to reverse RDP.

The technical details here aren’t terribly interesting. It’s all variations on the theme of not properly checking remote data from the server, and hence either reading or writing past internal buffers. This results in various forms of information leaks and code executions problems. What’s interesting is the different responses to the findings, and then [Eyal Itkin]’s takeaway about how security researchers should approach vulnerability disclosure.

So first up, Microsoft dismissed a vulnerability as unworthy of servicing. And then proceeded to research it internally, and present it as a novel attack without properly attributing [Eyal] for the original find. rdesktop contained quite a few of these issues, but were able to fix the problem in a handful of months. FreeRDP fixed some issues right away, in what could be described as a whack-a-mole style process, but a patch was cooked up that would actually address the problem at a deeper level: changing an API value from the unsigned size_t to a signed ssize_t. That change took a whopping 2 years to actually make it out to the world in a release. Why so long? Continue reading “This Week In Security: Bitwarden, Reverse RDP, And Snake” →

Getting Root Access On A Tesla

January 5, 2024 by Bryan Cockfield 36 Comments

A growing number of manufacturers are locking perfectly good hardware behind arbitrary software restrictions. While this ought to be a bigger controversy, people seem to keep paying for things like printers with ink subscriptions, cameras with features disabled in firmware, or routers with speed restrictions, ensuring that this practice continues. Perhaps the most blatant is car manufacturers that lock features such as heated seats or even performance upgrades in the hopes of securing a higher price for their vehicles. This might be a thing of the past for Teslas, whose software has been recently unlocked by Berlin IT researchers.

Researchers from Technische Universität Berlin were able to unlock Tesla’s driving assistant by inducing a two-microsecond voltage drop on the processor which allowed root access to the Autopilot software. Referring to this as “Elon mode” since it drops the requirement for the driver to keep their hands on the steering wheel, they were able to access the full self-driving mode allowing autonomous driving without driver input. Although this might be a bad idea based on the performance of “full self-driving” in the real world, the hack at least demonstrates a functional attack point and similar methods could provide free access to other premium features.

While the attack requires physical access to the vehicle’s computer and a well-equipped workbench, in the short term this method might allow for owners of vehicles to use hardware they own however they would like, and in the long term perhaps may make strides towards convincing manufacturers that “features as a service” isn’t a profitable strategy. Perhaps that’s optimistic, but at least for Teslas it’s been shown that they’re not exactly the most secured system on four wheels.

Two pictures of the mobo side by side, both with kapton tape covering everything other than the flash chip. On the left, the flash chip is populated, whereas on the right it's not

Enabling Intel AMT For BIOS-over-WiFi

January 5, 2024 by Arya Voronova 28 Comments

Intel ME, AMT, SMT, V-Pro… All of these acronyms are kind of intimidating, all we know about them is that they are tied to remote control technologies rooted deep in Intel CPUs, way deeper than even operating systems go. Sometimes though, you want remote control for your own purposes, and that’s what [ABy] achieved. He’s got a HP ProDesk 600 G3 Mini, decided to put it into a hard to reach spot in his flat, somewhere you couldn’t easily fetch a monitor and a keyboard for any debugging needs. So, he started looking into some sort of remote access option in case he’d need to access the BIOS remotely, and went as far as it took to make it work. (Google Translate)

The features he needed are covered by Intel AMT — specifically, BIOS access over a WiFi connection. However, his mini PC only had SMT enabled from the factory, the cut-down version of AMT without features like wireless support. He figured out that BIOS dumping was the way, promptly did just that, found a suitable set of tools for his ME region version, and enabled AMT using Intel’s FIT (Flash Image Tool) software.

Now, dumping the image could be done from a running system fully through software, but apparently, flashing back requires an external programmer. He went with the classic CH341, did the 3.3 V voltmod that’s required to make it safe for flash chip use, and proceeded to spend a good amount of time making it work. Something about the process was screwy, likely the proprietary CH341 software. Comments under the article highlight that you should use flashrom for these tasks, and indeed, you should.

This article goes into a ton of detail when it comes to working with Intel BIOS images — whichever kind of setting you want to change, be it AMT support or some entirely different but just as tasty setting, you will be well served by this write-up. Comments do point out that you might want to upgrade the Intel ME version while at it, and for what it’s worth, you can look into disabling it too; we’ve shown you a multitude of reasons why you should, and a good few ways you could.