Alarm Panel Hack Defeats Encryption By Ignoring It

January 19, 2024 by Dan Maloney 23 Comments

As frustrating as it may be for a company to lock you into its ecosystem by encrypting their protocols, you have to admit that it presents an enticing challenge. Cracking encryption can be more trouble than it’s worth, though, especially when a device gives you all the tools you need to do an end-run around their encryption.

We’ll explain. For [Valdez], the encrypted communication protocols between a DSC alarm panel and the control pads on the system were serious impediments to integration into Home Assistant. While there are integrations available for these alarm panels, they rely on third-party clouds, which means that not only is your security system potentially telling another computer all your juicy details, but there’s also the very real possibility that the cloud system can either break or be shut down; remember the Chamberlain MyQ fiasco?

With these facts in mind, [Valdez] came up with a clever workaround to DSC encryption by focusing on physically interfacing with the keypad. The device has a common 16×2 LCD and a 25-key keypad, and a little poking around with a multimeter and a $20 logic analyzer eventually showed that the LCD had an HD44780 controller, and revealed all the lines needed to decode the display with an ESP32. Next up was interfacing with the keypad, which also involved a little multimeter work to determine that the keys were hooked up in a 5×5 matrix. Ten GPIOs on the ESP32 made it possible to virtually push any key; however, the ten relays [Valdez] originally used to do the switching proved unwieldy. That led to an optocoupler design, sadly not as clicky but certainly more compact and streamlined, and enabling complete control over the alarm system from Home Assistant.

We love this solution because, as [Valdez] aptly points out, the weakest point in any system is the place where it can’t be encrypted. Information has to flow between the user and the control panel, and by providing the electronic equivalents to eyes and fingers, the underlying encryption is moot. Hats off to [Valdez] for an excellent hack, and for sharing the wealth with the HA community.

Haier Threatens Legal Action Against Home Assistant Plugin Developer

January 19, 2024 by Maya Posch 109 Comments

Appliance manufacturer Haier has been integrating IoT features into their newer products, and as is so common these days, users are expected to install their “hOn” mobile application to access them. Not satisfied with that limitation, [Andre Basche] reverse engineered the protocol used by the app, and released a Python library and associated Home Assistant plugin to interface with a wide array of Haier appliances, which includes brands like Hoover, Candy, GE Appliances and others.

Unfortunately, it looks like his efforts have gotten him into a bit of legal hot water. In an issue recently opened on the project’s GitHub page, [Andre] explains the circumstances and legal options that have led him to consider pulling the repositories completely — mostly due to the cost of mounting a legal defense to the cease & desist from Haier Europe.

What’s ironic here is that Haier has been part of the Connectivity Standard Alliance (CSA) since 2022, whose goal is to ‘promote universal open IoT standards’, including Matter.

It’s possible that a legal defense will be mounted against this C&D from Haier within the coming days. Yet regardless of the outcome here, it remains problematic that these IoT-enabled Haier appliances are connected to the Haier servers. Ideally they would be controlled locally, which is the goal of projects like [Miguel Ángel López Vicente]’s ESP Haier, that uses an ESP8266 to connect Haier AC units to the local WiFi and e.g. HA instances, all without requiring internet access.

This is sadly just one more example of why building your own off-line smart home can be such an incredible struggle.

Thanks to [Ar3itrary] for the tip.

Remembering ISDN

January 15, 2024 by Al Williams 89 Comments

We are definitely spoiled these days in terms of Internet access. In much of the world gigabit speeds are common and even cheap plans are likely to be measured in 100s of megabits. But there was a time not long ago when a fast modem received at 56 kilobits per second. If you couldn’t justify a dedicated T1 line and you had a lot of money, you might have thought about ISDN – the Integrated Services Digital Network. [Tedium] has a great retrospective now that the UK has decided to sunset ISDN in 2025. ISDN started in the UK in the mid-1980s.

ISDN offered two 64-kilobit channels that could be bonded to reach 128 kilobits. There was also a slower third channel for commands and signaling (although you could use it for data, too, using an X.25-like protocol). If you wanted phone service, your voice was on one 64K channel and the data on the other. No need to tie up your phone just to get online. Voice was digitized at 8 kHz with 8 bits of G.711 encoding.

Continue reading “Remembering ISDN” →

Skip The Radio With This Software-Defined Ultrasound Data Link

January 13, 2024 by Dan Maloney 21 Comments

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

January 11, 2024 by Bryan Cockfield 11 Comments

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

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