A software-defined radio system in a 3D-printed case with a 7" display and an array of knobs and switches

Hackaday Prize 2023: A Software-Defined Radio With Real Knobs And Switches

September 25, 2023 by Robin Kearey 16 Comments

When cheap digital TV dongles enabled radio enthusiasts to set up software defined radio (SDR) systems at almost zero cost, it caused a revolution in the amateur radio world: now anyone could tune in to any frequency, with any modulation type, by just pointing and clicking in a computer program. While this undoubtably made exploring the radio waves much more accessible, we can imagine that some people miss the feeling of manipulating physical buttons on a radio while hunting for that one faint signal in a sea of noise. If you’re one of those people, you’re in luck: [Kaushlesh C.] has built a portable, self-contained SDR system with real knobs and switches, called SDR Dock 1.0. Continue reading “Hackaday Prize 2023: A Software-Defined Radio With Real Knobs And Switches” →

USB And The Myth Of 500 Milliamps

July 3, 2024 by Arya Voronova 91 Comments

If you’re designing a universal port, you will be expected to provide power. This was a lesson learned in the times of LPT and COM ports, where factory-made peripherals and DIY boards alike had to pull peculiar tricks to get a few milliamps, often tapping data lines. Do it wrong, and a port will burn up – in the best case, it’ll be your port, in worst case, ports of a number of your customers.

Want a single-cable device on a COM port? You might end up doing something like this.

Having a dedicated power rail on your connector simply solves this problem. We might’ve never gotten DB-11 and DB-27, but we did eventually get USB, with one of its four pins dedicated to a 5 V power rail. I vividly remember seeing my first USB port, on the side of a Thinkpad 390E that my dad bought in 2000s – I was eight years old at the time. It was merely USB 1.0, and yet, while I never got to properly make use of that port, it definitely marked the beginning of my USB adventures.

About six years later, I was sitting at my desk, trying to build a USB docking station for my EEE PC, as I was hoping, with tons of peripherals inside. Shorting out the USB port due to faulty connections or too many devices connected at once was a regular occurrence; thankfully, the laptop persevered as much as I did. Trying to do some research, one thing I kept stumbling upon was the 500 mA limit. That didn’t really help, since none of the devices I used even attempted to indicate their power consumption on the package – you would get a USB hub saying “100 mA” or a mouse saying “500 mA” with nary an elaboration.

Fifteen more years have passed, and I am here, having gone through hundreds of laptop schematics, investigated and learned from design decisions, harvested laptops for both parts and even ICs on their motherboards, designed and built laptop mods, nowadays I’m even designing my own laptop motherboards! If you ever read about the 500 mA limit and thought of it as a constraint for your project, worry not – it’s not as cut and dried as the specification might have you believe.
Continue reading “USB And The Myth Of 500 Milliamps” →

This Week In Security: TunnelVision, Scarecrows, And Poutine

May 10, 2024 by Jonathan Bennett 9 Comments

There’s a clever “new” attack against VPNs, called TunnelVision, done by researchers at Leviathan Security. To explain why we put “new” in quotation marks, I’ll just share my note-to-self on this one written before reading the write-up: “Doesn’t using a more specific DHCP route do this already?” And indeed, that’s the secret here: in routing, the more specific route wins. I could not have told you that DHCP option 121 is used to set extra static routes, so that part was new to me. So let’s break this down a bit, for those that haven’t spent the last 20 years thinking about DHCP, networking, and VPNs.

So up first, a route is a collection of values that instruct your computer how to reach a given IP address, and the set of routes on a computer is the routing table. On one of my machines, the (slightly simplified) routing table looks like:

# ip route default via 10.0.1.1 dev eth0 10.0.1.0/24 dev eth0

The first line there is the default route, where “default” is a short-hand for 0.0.0.0/0. That indicate a network using the Classless Inter-Domain Routing (CIDR) notation. When the Internet was first developed, it was segmented into networks using network classes A, B, and C. The problem there was that the world was limited to just over 2.1 million networks on the Internet, which has since proven to be not nearly enough. CIDR came along, eliminated the classes, and gave us subnets instead.

In CIDR notation, the value after the slash is commonly called the netmask, and indicates the number of bits that are dedicated to the network identifier, and how many bits are dedicated to the address on the network. Put more simply, the bigger the number after the slash, the fewer usable IP addresses on the network. In the context of a route, the IP address here is going to refer to a network identifier, and the whole CIDR string identifies that network and its size.

Back to my routing table, the two routes are a bit different. The first one uses the “via” term to indicate we use a gateway to reach the indicated network. That doesn’t make any sense on its own, as the 10.0.1.1 address is on the 0.0.0.0/0 network. The second route saves the day, indicating that the 10.0.1.0/24 network is directly reachable out the eth0 device. This works because the more specific route — the one with the bigger netmask value, takes precedence.

The next piece to understand is DHCP, the Dynamic Host Configuration Protocol. That’s the way most machines get an IP address from the local network. DHCP not only assigns IP addresses, but it also sets additional information via numeric options. Option 1 is the subnet mask, option 6 advertises DNS servers, and option 3 sets the local router IP. That router is then generally used to construct the default route on the connecting machine — 0.0.0.0/0 via router_IP.

Remember the problem with the gateway IP address belonging to the default network? There’s a similar issue with VPNs. If you want all traffic to flow over the VPN device, tun0, how does the VPN traffic get routed across the Internet to the VPN server? And how does the VPN deal with the existence of the default route set by DHCP? By leaving those routes in place, and adding more specific routes. That’s usually 0.0.0.0/1 and 128.0.0.0/1, neatly slicing the entire Internet into two networks, and routing both through the VPN. These routes are more specific than the default route, but leave the router-provided routes in place to keep the VPN itself online.

And now enter TunnelVision. The key here is DHCP option 121, which sets additional CIDR notation routes. The very same trick a VPN uses to override the network’s default route can be used against it. Yep, DHCP can simply inform a client that networks 0.0.0.0/2, 64.0.0.0/2, 128.0.0.0/2, and 192.0.0.0/2 are routed through malicious_IP. You’d see it if you actually checked your routing table, but how often does anybody do that, when not working a problem?

There is a CVE assigned, CVE-2024-3661, but there’s an interesting question raised: Is this a vulnerability, and in which component? And what’s the right solution? To the first question, everything is basically working the way it is supposed to. The flaw is that some VPNs make the assumption that a /1 route is a bulletproof way to override the default route. The solution is a bit trickier. Continue reading “This Week In Security: TunnelVision, Scarecrows, And Poutine” →

This Week In Security: Filename Not Sanitized, MonikerLink, And Snap Attack!

February 16, 2024 by Jonathan Bennett 7 Comments

Reading through a vulnerability report about ClamAV, I came across a phrase that filled me with dread: “The file name is not sanitized”. It’s a feature, VirusEvent, that can be enabled in the ClamnAV config. And that configuration includes a string formatting function, where the string includes %v and %s, which gets replaced with a detected virus name and the file name from the email. And now you see the problem, I hope: The filename is attacker supplied input.

Where this really gets out of hand is what ClamAV does with this string. execle("/bin/sh", "sh", "-c", buffer_cmd, NULL, env). So let’s talk defensive program design for a minute. When it comes to running a secondary command, there are two general options, system() and the exec*() family of system calls. system() is very simple to use. It pauses execution of the main process and asks the operating system to run a string, just as if the user had typed that command into the shell. While this is very convenient to use, there is a security problem if any of that command string is user-supplied. All it takes is a semicolon or ampersand to break assumptions and inject a command.

To the rescue comes exec(). It’s a bit more complicated to use, requiring the programmer to manually call fork() and wait(). But it’s not running the command via the shell. exec() executes a program directly, totally eliminating the potential for command injection! Except… oops.

Yeah, exec() and related calls don’t offer any security protections when you use them to execute /bin/sh. I suspect the code was written this way to allow running a script without specifying /bin/sh in the config. The official fix was to disable the filename format character, and instead supply it as an environment variable. That certainly works, and that fix is available in 1.0.5, 1.2.2, and 1.3.0.

The real danger here is that we have another case where some hardware appliance manufacturer has used ClamAV for email filtering, and uses this configuration by default. That’s how we get orders from CISA to unplug your hardware, because it’s already compromised. Continue reading “This Week In Security: Filename Not Sanitized, MonikerLink, And Snap Attack!” →

DisplayPort: A Better Video Interface

July 11, 2023 by Arya Voronova 75 Comments

Over the years, we’ve seen a good number of interfaces used for computer monitors, TVs, LCD panels and other all-things-display purposes. We’ve lived through VGA and the large variety of analog interfaces that preceded it, then DVI, HDMI, and at some point, we’ve started getting devices with DisplayPort support. So you might think it’s more of the same. However, I’d like to tell you that you probably should pay more attention to DisplayPort – it’s an interface powerful in a way that we haven’t seen before.

The DisplayPort (shortened as DP) interface was explicitly designed to be a successor to VGA and DVI, originating from the VESA group – an organization created by multiple computer-display-related players in technology space, which has previously brought us a number of smaller-scale computer display standards like EDID, DDC and the well-known VESA mount. Nevertheless, despite the smaller scale of previous standards, DisplayPort has since become a hit in computer display space for a number of reasons, and is more ubiquitous than you might realize.

You could put it this way: DisplayPort has all the capabilities of interfaces like HDMI, but implemented in a better way, without legacy cruft, and with a number of features that take advantage of the DisplayPort’s sturdier architecture. As a result of this, DisplayPort isn’t just in external monitors, but also laptop internal displays, USB-C port display support, docking stations, and Thunderbolt of all flavors. If you own a display-capable docking station for your laptop, be it classic style multi-pin dock or USB-C, DisplayPort is highly likely to be involved, and even your smartphone might just support DisplayPort over USB-C these days. Continue reading “DisplayPort: A Better Video Interface” →

M.2 For Hackers – Expand Your Laptop

October 27, 2022 by Arya Voronova 55 Comments

You’ve seen M.2 cards in modern laptops already. If you’re buying an SSD today, it’s most likely an M.2 one. Many of our laptops contain M.2 WiFi cards, the consumer-oriented WWAN cards now come in M.2, and every now and then we see M.2 cards that defy our expectations. Nowadays, using M.2 is one of the most viable ways for adding new features to your laptop. I have found that the M.2 standard is quite accessible and also very hackable, and I would like to demonstrate that to you.

If you ever searched the Web trying to understand what makes M.2 tick, you might’ve found one of the many confusing articles which just transcribe stuff out of the M.2 specification PDF, and make things look more complicated than they actually are. Let’s instead look at M.2 real-world use. Today, I’ll show you the M.2 devices you will encounter in the wild, and teach you what you need to know to make use of them. In part 2, I will show you how to build your own M.2 cards and card-accepting devices, too!

Well Thought-Out, Mostly

You can genuinely appreciate the M.2 standard once you start looking into it, especially if you have worked with mPCIe devices for some amount of time. mPCIe is what we’ve been using for all these years, and it gradually became a mish-mash of hardly-compatible pinouts. As manufacturers thought up all kinds of devices they could embed, you’d find hacks like mSATA and WWAN coexistence extensions, and the lack of standardization is noticeable in things like mPCIe WWAN modems as soon as you need something like UART or PCM. The M.2 specification, thankfully, accounted for all of these lessons.

Continue reading “M.2 For Hackers – Expand Your Laptop” →

Hackaday Links: August 15, 2021

August 15, 2021 by Dan Maloney 13 Comments

Unless you’re in the market for a new car, household appliance, or game console, or if you’re involved in the manufacture of these things, chances are pretty good that the global semiconductor shortage hasn’t directly impacted you yet. But we hobbyists might be due for a comeuppance as the chip shortage starts to impact our corner of the market. We suppose it’s natural that supplies of the chips needed to build Arduinos and Raspberry Pis would start to dry up, as semiconductor manufacturers realign their resources to service their most lucrative markets. Still, it was all sort of abstract until now, but seeing dire quotes from the likes of Adafruit, Pololu, and Sparkfun about the long lead times they’re being quoted — some chips won’t be seen until 2023! — is disheartening. As are the reports of price gouging and even hoarding; when a $10 part can suddenly command $350, you know something has gone seriously wrong.

But have no fear — we’re certain the global chip shortage will have no impact on the planned 2027 opening of the world’s first space hotel. Voyager Station — once dubbed Von Braun Station but renamed for some reason — looks for all the world like Space Station V in “2001: A Space Odyssey”, or at least half of it. The thing is enormous — witness the Starship docked in the center hub, as well as the several dozen shuttle-like craft — escape pods, perhaps? — attached to the outer rim. The renders are imaginative, to say the least — the station looks very sleek, completely unfettered by such banalities as, say, solar panels. We get that a private outfit needs to attract deep-pocketed investors, and that one doesn’t do that by focusing on the technical details when they can sell a “premium experience”. But really, if you’re going to space, do you want basically the same look and feel as a premium hotel on Earth, just with a better view? Or would you rather feel like you’ve actually traveled to space?

Speaking of space, did you ever wonder what the first programmable calculator in space was? Neither did we, but that doesn’t mean we didn’t find this detailed story about the HP-65 that was sent up on the Apollo-Soyuz Test Project in 1975 pretty fascinating. The ASTP was the last hurrah of Apollo, and an often underappreciated engineering challenge. Linking up the two spacecraft safely was not trivial, and a fair number of burn calculations had to be made in orbit to achieve rendezvous and docking, as well as to maintain orbit. The HP-65, a programmable calculator that went for about $750 at the time (for the non-space-rated version, of course) had several programs loaded onto its removable magnetic cards, and the Apollo crew used it to verify the results calculated by the Apollo Guidance Computer (AGC).

Facebook, a company that exists by providing people with a product they don’t need but now somehow can’t live without, is now dipping a toe into weird, weird waters: reverse-passthrough virtual reality. The idea, we take it, is that as users more widely adopt VR and integrate it into their daily lives, the VR headsets everyone will be wearing will make face-to-face contact more difficult. So what better way to solve that problem than by projecting a live image of the VR user’s eyes onto a screen outside the VR rig, for any and all to see? Pure genius, and not the least bit creepy. They’ve perhaps got a bit of work to go before achieving their goal of “seamless social connection between real and virtual worlds”.

And speaking of eyes, it’s good to know that developers are still hard at work keeping the most vital applications running at peak efficiency on today’s hardware. Yes, the venerable XEyes, a program for the X Window System on Unix-like operating systems that draws a pair of googly eyes on the screen to follow your mouse movements, has finally moved to version 1.2.0. It’s been 11 years since the 1.1.0 upgrade, so it was a long time coming. If you haven’t had the chance to play with XEyes, fear not — just about any Linux machine should be able to show you what you’ve been missing. Or, you know, you could even run it on a camera as the video below the break shows.

Continue reading “Hackaday Links: August 15, 2021” →