Skip The Radio With This Software-Defined Ultrasound Data Link

We know what you’re thinking: with so many wireless modules available for just pennies, trying to create a physical data link using ultrasonic transducers like [Damian Bonicatto] did for a short-range, low-bitrate remote monitoring setup seems like a waste of time. And granted, there are a ton of simple RF protocols you can just throw at a job like this. Something like this could be done and dusted for a couple of bucks, right?

Luckily, [Damian] wanted something a little different for his wireless link to a small off-grid solar array, which is why he started playing with ultrasound in an SDR framework. The design for his “Software-Defined Ultrasonics” system, detailed in Part 1, has a pair of links, each with two ultrasonic transducers, one for receiving and one for transmitting. Both connect to audio amplifiers with bandpass filters; the received signal is digitized by the ADC built into an Arduino Nano, while the transmitted signal is converted to analog by an outboard DAC.

The transducers are affixed to 3D printed parabolic reflectors, which are aimed at each other over a path length of about 150′ (46 m). Part 2 of the series details the firmware needed to make all this work. A lot of the firmware design is dictated by the constraints introduced by using Arduinos and the 40-kHz ultrasonic carrier, meaning that the link can only do about 250 baud. That may sound slow, but it’s more than enough for [Damian]’s application.

Perhaps most importantly, this is one of those times where going slower helps you to go faster; pretty much everything about the firmware on this system applies to SDRs, so if you can grok one, the other should be a breeze. But if you still need a little help minding your Is and Qs, check out [Jenny]’s SDR primer.

A Dashboard Outside The Car

One of the biggest upsides of open communications standards such as CAN or SPI is that a whole world of vehicle hacking becomes available, from simple projects like adding sensors or computers to a car or even building a complete engine control unit from the ground up. The reverse is true as well; sensors and gauges using one of these protocols can be removed from a car and put to work in other projects. That’s the idea that [John] had when he set about using a vehicle’s dashboard as a information cluster for his home.

The core of the build is an Astra GTE dashboard cluster, removed from its host vehicle, and wired to an Arduino-compatible board, in this case an ESP32. The code that [John] wrote bit-bangs an SPI bus and after some probing is able to address all of the instrument gauges on the dashboard. For his own use at home, he’s also configured it to work with Home Assistant, where each of the gauges is configured to represent something his home automation system is monitoring using a bit mask to send data to specific dials.

While this specific gauge cluster has a lot of vehicle-specific instrumentation and needs a legend or good memory to tie into a home automation system without any other modification, plenty of vehicle gauges are more intuitive and as long as they have SPI they’d be perfect targets for builds that use this underlying software. This project takes a similar tack and repurposes a few analog voltmeters for home automation, adding a paper background to the meters to make them easier to read.

Continue reading “A Dashboard Outside The Car”

802.11ah Wi-Fi HaLOW: The 1 Kilometer WiFi Standard

You too can add long-distance WiFi to your laptop with this new not-quite dongle solution. (Credit: Ben Jeffery)
You, too, can add long-distance WiFi to your laptop with this new not-quite dongle solution. (Credit: Ben Jeffery)

The 802.11ah WiFi (HaLow) standard is fairly new, having only been introduced in 2017. It’s supposed to fall somewhere between standard WiFi used in domiciles and offices and the longer range but low-bitrate LoRaWAN, ZigBee, and others, with bandwidth measured in megabits per second. In a recent video, [Ben Jeffery] looks at the 802.11ah chipsets available today and some products integrating these.

The primary vendors selling these chipsets are TaiXin Semiconductor (TXW8301), Morse Micro (MM6108), and Newracom (NRC7394), with a range of manufacturers selling modules integrating these. Among the products using these, [Ben] found an Ethernet range extender kit (pictured) that takes 12V input as power, along with Ethernet. Running some distance tests in a quarry showed that 300 meters was no problem getting a strong signal, though adding some trees between the two transceivers did attenuate the signal somewhat.

Another interesting product [Ben] tested is what is essentially an 802.11ah-based WiFi extender, using an 802.11ah link between the server node – with an Ethernet socket – and a client that features a standard 2.4 GHz 802.11n that most WiFi-enabled devices can connect to. Using this, he was able to provide a solid ~10 Mbps link to a cabin near the main house (~10 meters) through two outside walls. What makes 802.11ah so interesting is that it is directly compatible with standard Ethernet and WiFi protocols and uses the 900 MHz spectrum, for which a wide range of alternative antennae exist that can conceivably extend the range even more.

(Thanks to [Keith Olson] for the tip)

Continue reading “802.11ah Wi-Fi HaLOW: The 1 Kilometer WiFi Standard”

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

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”

37C3: When Apple Ditches Lightning, Hack USB-C

[Thomas Roth], aka [Ghidraninja], and author of the [Stacksmashing] YouTube channel, investigated Apple’s Lightning port and created a cool debugging tool that allowed one to get JTAG on the device. Then, Apple went to USB-C for their new phones, and all his work went to waste. Oh well, start again — and take a look at USB-C.

Turns out, though, that the iPhone 15 uses the vendor-defined messages (VDM) capability of USB-PD to get all sorts of fun features out. Others had explored the VDM capabilities on Mac notebooks, and it turns out that the VDM messages on the phone are the same. Some more fiddling, and he got a serial port and JTAG up and running. But JTAG is locked down in the production devices, so that will have to wait for an iPhone 15 jailbreak. So he went poking around elsewhere.

He found some other funny signals that turned out to be System Power Management Interface (SPMI), one of the horribly closed and NDA-documented dialects owned by the MIPI Alliance. Digging around on the Interwebs, he found enough documentation to build an open-source SPMI plugin that he said should be out on his GitHub soon.

The end result? He reworked his old Lightning hardware tool for USB-C and poked around enough in the various available protocols to get a foothold on serial, JTAG, and SPMI. This is just the beginning, but if you’re interested in playing with the new iPhone, this talk is a great place to start. Want to know all about USB-C? We’ve got plenty of reading for you.

The Gopher Revival Is Upon Us

A maxim for anyone writing a web page in the mid 1990s was that it was good practice to bring the whole thing (including graphics) in at around 30 kB in size. It was a time when the protocol still had some pretence of efficient information delivery, when information was self-published, before huge corporations brought everything under their umbrellas.

Recently, this idea of the small web has been experiencing something of a quiet comeback. [Serge Zaitsev]’s essay takes us back to a time before the Internet as we know it was born, and reminds us of a few protocols that have fallen by the wayside. Finger or Gopher, both things we remember from our student days, but neither of which was a match for the browser.

All is not lost though, because the Gemini protocol is a more modern take on minimalist Internet information sharing. It’s something like the web, but intentionally without the layer upon layer of extraneous stuff, and it’s been slowly gathering some steam. Every time we look at its software list it becomes more extensive, and we live in hope that it might catch on for use with internet-connected microcontroller-based computing. The essay is a reminder that the internet doesn’t have to be the web, and doesn’t have to be bloated either.

Dial Up Over Discord

Some hacks are useful and some are just… well… for the fun of it, and we can appreciate that. Take, for example, [Cool Blog’s] recent experiments with dialup networking. If you think about it, the BBS systems of yesterday have been replaced with more modern tools like Discord. So why not run modems using audio chat over Discord and get the best of both worlds?

This was both easier and harder than we would have expected. The first hurdle was the lack of any actual modems. Luckily, there are software modem emulators like minimodem that makes a PC soundcard work like a modem. It supports some basic protocols, and that’s probably a good thing since the digital audio channel is probably unable to support anything too sophisticated.

Using some crude audio routing 300 baud data did flow. Increasing the baud rate all the way to 2,100 worked reliably. Combining some more sophisticated audio flows and managing sockets with systemd made the process easier. The goal was to, eventually, telnet over the link but that never worked. We would guess that it could work if you spent enough time.

But the proof is in the pudding, and the basic idea works. Why do it? We can’t think of a good reason. But if you want to give it a shot, you can find what you need on GitHub.

Hams still use modems. While we tend to have a soft spot for retrocomputing gear, we don’t miss acoustic couplers at all.