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

January 7, 2024 by Maya Posch 30 Comments

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

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” →

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

December 30, 2023 by Elliot Williams 11 Comments

[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

December 29, 2023 by Jenny List 39 Comments

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

December 23, 2023 by Al Williams 17 Comments

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.

Beyond The Basics: Exploring Exotic Scope Trigger Modes

December 20, 2023 by Al Williams 15 Comments

Will Rogers once said that veterinarians are the best doctors because their patients can’t tell them where it hurts. I’ve often thought that electronic people have a similar problem. In many cases, what’s wrong with our circuits isn’t visible. Sure, you can visually identify a backward diode, a bad solder joint, or a blown fuse. But you can’t look at a battery and see that it is dead or that a clock signal isn’t reaching some voltage. There are lots of ways to look at what’s really going on, but there is no substitute for a scope. It used to be hard for the average person to own a scope, but these days, it doesn’t require much. If you aren’t shopping for the best tech or you are willing to use it with a PC, oscilloscopes are quite affordable. If you spend even a little, you can now get scopes that are surprisingly capable with features undreamed of in years past. For example, many modern scopes have a dizzying array of triggering options. Do you need them? What do they do? Let’s find out.

I’ll be using a relatively new Rigol DHO924S, but none of the triggering modes are unique to that instrument. Sometimes, they have different names, and, of course, their setup might look different than my pictures, but you should be able to figure it out.

What is Triggering?

In simple terms, an oscilloscope plots time across the X-axis and voltage vertically on the Y-axis. So you can look at two peaks, for example, and measure the distance between them to understand how far apart they are in time. If the signal you are measuring happens repeatedly — like a square or sine wave, for example — it hardly matters which set of peaks you look at. After all, they are all the same for practical purposes.

Pretty square waves all in a row. Channel 2 is 180 degrees out of phase (inverted). But is that all there is?

The problem occurs when you want to see something relative to a particular event. Basic scopes often have level triggering. They “start” when the input voltage goes above or below a certain value. Suppose you are looking at a square wave that goes from 0 V to 5 V. You could trigger at about 2.5 V, and the scope will never start in the middle of a cycle.

Digital scopes tend to capture data before and after the trigger, so the center of the screen will be right on an edge, and you’ll be able to see the square waves on either side. The picture shows two square waves on the screen with the trigger point marked with a T in the top center of the display. You can see the level in the top bar and also marked with a T on the right side of the screen.

What happens if there are no pulses on the trigger source channel? That depends. If you are in auto mode, the scope will eventually get impatient and trigger at random. This lets you see what’s going on, but there’s no reference. If you are in normal mode, though, the scope will either show nothing or show the last thing it displayed. Either way, the green text near the top left corner will read WAIT until the trigger event occurs. Then it will say T’D.

Continue reading “Beyond The Basics: Exploring Exotic Scope Trigger Modes” →

The Dark Side Of Hacking XMas Lights, Literally

December 17, 2023 by Maya Posch 18 Comments

When looking at the piles of cheap RGB, Bluetooth-controlled LED strips you can find for sale just about anywhere these days, integrating them into a home-automation setup is very tempting. Normally these strips are controlled via a special smartphone app, that speaks whatever dodgy protocol was thrown together for the LED strip controller in question. Reverse-engineering this Bluetooth protocol is fairly easy these days, as [Will Cooke] describes in a recent tutorial, although for him there was a bit of a tragic ending with one particular RGB set.

With previous experiences reverse-engineering the Bluetooth protocol with Wireshark under his belt and having published the BJ_LED repository for LED strips that use the MohuanLED app, reverse-engineering this new LED strip with the associated “iDeal LED” app seemed fairly routine. Initially it was indeed routine, with just a curveball in the form of some encryption that the Jadx decompiler used on the app couldn’t help with. Fortunately the key ended up floating around on the internet, and the protocol was wide open. That’s when disaster struck.

While trying to throw payloads at the LED controller to find hidden modes and settings, [Will] found that he could indeed increase the brightness beyond what the app supported, but poking at lighting modes beyond the 10 presets gave a nasty shock. Modes 1 through 10 worked fine, 11 also did something new, but when the controller was asked to switch to mode 12, it shut off. Permanently. Whether this corrupted the firmware or caused some other issue is unknown, but it’s a clear warning that reverse-engineering comes with potentially fried hardware.

We hope that [Will] can get an autopsy performed on this controller to see the cause of this seemingly permanent failure that persisted across hard resets and disconnecting from power overnight. The protocol for this controller has been published on GitHub for those who’d like to take their chances.

LED lights: LadyAda, CC BY-SA 4.0.