The film scanner [xssfox] found, in the center of a table, with other stuff strewn across the table

Answering All Your ISCSI Scanner Questions

iSCSI is a widely used protocol for exposing SCSI devices over a network connection, and some scanners have in the past been equipped with SCSI ports. So, could you have an iSCSI network scanner? [xssfox] details her journey making a Canoscan FS4000US film scanner work over iSCSI, sparked by someone’s overly-confident StackOverflow comment that it couldn’t be done. Nothing in the spec said it couldn’t actually work, however, and after figuring out a tentative architecture, a hardware setup was put together.

No flatbed scanners with SCSI ports could be found on the cheap, so a film scanner had to be procured. After figuring out a few hitches with the loading mechanism and getting a test image locally, it was time to try and build up the software setup, tearing through SCSI compatibility and cabling, driver and PCI pass-through woes, bluescreens, and intermediate software having dropped some of the necessary features by now. Still, [xssfox] eventually exported the scanner as an iSCSI target – and, on the other end of the network, successfully connected to it and completed a scan. The StackOverflow answer was wrong, after all.

It’s fun to see how far old technology can go, and get answers to questions you never knew you had. Whether you’re reminiscing about SCSI days or wondering what the technology about, we’ve talked about it aplenty, from a retrospective to modern-day experiments, repurposing old SCSI hardware for modern SATA ports, a Raspberry Pi implementation, an emulator, and a fair bit more.

We thank [Valentijn Sessink] and [adistuder] for sharing this with us!

Two pictures of the same black dog, wearing two separate pairs of the AR glasses reviewed in these two articles

A Master-Class On Reverse-Engineering Six AR Glasses

Augmented reality (AR) tech is getting more and more powerful, the glasses themselves are getting sleeker and prettier, and at some point, hackers have to conquer this frontier and extract as much as possible. [Void Computing] is writing an open source SDK for making use of AR glasses, and, along the way, they’ve brought us two wonderful blog posts filled with technical information laid out in a fun to read way. The first article is titled “AR glasses USB protocols: the Good, the Bad and the Ugly”, and the second one follows as “the Worse, the Better and the Prettier”.

Have you ever wanted to learn how AR glasses and similar devices work, what’s their internal structure, which ones are designed well and which ones maybe not so much? These two posts have concise explanations, more than plenty of diagrams, six case studies of different pairs of AR glasses on the market, each pair demonstrated by our hacker’s canine assistant.

[Void Computing] goes in-depth on this tech — you will witness MCU firmware reverse-engineering, HID packet captures, a quick refresher on the USB-C DisplayPort altmode, hexdumps aplenty, and a reminder on often forgotten tools of the trade like Cunningham’s law.

If reverse-engineering lights your fire, these high-level retrospectives will teach you viable ways to reverse-engineer devices in your own life, and they certainly set a high bar for posts as far as write-ups go. Having read through these posts, one can’t help but think that some sort of AR glasses protocol standard is called for here, but fortunately, it appears like [Void Computing]’s SDK is the next best thing, and their mission to seize the good aspects of a tentative cyberpunk future is looking to be a success. We’ve started talking about AR glasses over a decade ago, and it’s reassuring to see hackers catching up on this technology’s advancements.

We thank [adistuder] for sharing this with us on the Hackaday Discord server!

The Minimalistic Dillo Web Browser Is Back

Over the decades web browsers have changed from the fairly lightweight and nimble HTML document viewers of the 1990s to today’s top-heavy browsers that struggle to run on a system with less than a quad-core, multi-GHz CPU and gigabytes of RAM. All but a few, that is.

Dillo is one of a small number of browsers that requires only a minimum of system resources and will happily run on an Intel 486 or thereabouts. Sadly, the project more or less ended back in 2016 when the rendering engine’s developer passed away, but with the recent 3.10 release the project seems to be back on track, courtesy of efforts by [Rodrigo Arias Mallo].

Although a number of forks were started after the Dillo project ground to a halt, of these only Dillo+ appears to be active at this point in time, making this project revival a welcome boost, as is its porting to Atari systems. As for Dillo’s feature set, it boasts support for a range of protocols, including Gopher, HTTP(S), Gemini, and FTP via extensions. It supports HTML 4.01 and some HTML 5, along with CSS 2.1 and some CSS 3 features, and of course no JavaScript.

On today’s JS-crazed web this means access can be somewhat limited, but maybe it will promote websites to have a no-JS fallback for the Dillo users. The source code and releases can be obtained from the GitHub project page, with contributions to the project gracefully accepted.

Thanks to [Prof. Dr. Feinfinger] for the tip.

This Week In Security: TunnelVision, Scarecrows, And Poutine

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”

Your Open-Source Client Options In The Non-Mastodon Fediverse

When things started getting iffy over at Twitter, Mastodon rose as a popular alternative to the traditional microblogging platfrom. In contrast to the walled gardens of other social media channels, it uses an open protocol that runs on distributed servers that loosely join together, forming the “Fediverse”.

The beauty of the Fediverse isn’t just in its server structure, though. It’s also in the variety of clients available for accessing the network. Where Twitter is now super-strict about which apps can hook into the network, the Fediverse welcomes all comers to the platform! And although Mastodon is certainly the largest player, it’s absolutely not the only elephant in the room.

Today, we’ll look at a bunch of alternative clients for the platform, ranging from mobile apps to web clients. They offer unique features and interfaces that cater to different user preferences and needs. We’ll look at the most notable examples—each of which brings a different flavor to your Fediverse experience.

Continue reading “Your Open-Source Client Options In The Non-Mastodon Fediverse”

Your Pi, From Anywhere

The Raspberry Pi finds a use in a huge variety of applications, and in almost any location you could imagine. Sadly those who use those machines might not be in the same place as the machines themselves, and thus there’s the question of providing a remote connection between the two. This may not be a huge challenge to those skilled with Linux and firewalls, but to many Pi users it’s a closed book. So the Pi folks have come up with a painless way to connect to your Pi wherever it is, and it’s called Raspberry Pi Connect.

To use the service all you need is a Pi running the latest 64-bit version of Raspberry Pi OS, so sadly that excludes base model Zeros and older models. Sign in to the Raspberry Pi Connect server, follow the instructions, and you’re on your way. Under the hood it’s the well-known VNC protocol at work, with the connection setup being managed via WebRTC. The Pi servers are intended to act simply as connection facilitators for peer-to-peer traffic, though they are capable of handling through traffic themselves. It’s a beta service with a single server in the UK at the time of writing, though we’d expect both the number of servers and the offering to evolve over time.

We think this is a useful addition to the Pi offering, and we expect to see it used in all manner of inventive ways. Meanwhile it’s a while since we had a look at connecting to a headless Pi, but much of the information is still relevant.

Bluepad32 Brings All The Controllers To Your MCU

As much as we enjoy spinning up our own solutions, there are times when you’ve got to look at what’s on the market and realize you might be out of your league. For example, take Bluetooth game controllers. Sure, you could make your own with a microcontroller, some buttons, and a couple joysticks. But between the major players like Microsoft, Nintendo, and Sony, as well as independent peripheral companies like 8BitDo, there’s some seriously impressive hardware out there that can be easily repurposed.

How, you ask? Well, Bluepad32 by [Ricardo Quesada] would be a great place to start. This Apache v2.0 licensed project allows you to easily interface with a wide array of commercially available BT controllers, and supports an impressive number of software and hardware platforms. Using the Arduino IDE on the ESP32? No problem. CircuitPython on Adafruit’s PyPortal? Supported. There’s even example code provided for using it on Linux and Mac OS. Sorry Windows fans — perhaps there’s a sassy paperclip or sentient dog built into your OS that can instruct you further.

A few of the controllers supported by Bluepad32.

The nature of the Bluetooth Human Interface Device (HID) protocol means that, at least in theory, pretty much all modern devices should be supported by Bluepad32 automatically. But even still, it’s hard not to be impressed by the official controller compatibility list. There’s also separate lists for Bluetooth mice and keyboards that are known to work with the project.

While it’s somewhat unlikely to be a problem in this particular community, there is an unusual quirk to this project which we think should at least be mentioned. Although Bluepad32 itself is free and open source software (FOSS), it depends on the BTstack library, which in turn uses a more ambiguous licensing scheme. BTstack is “open” in the sense that you can see the source code and implement it in your own projects, but its custom license precludes commercial use. If you want to use BTstack (and by extension, Bluepad32) in a commercial product, you need to contact the developers and discuss terms.

License gotchas aside, Bluepad32 is definitely a project to keep in the back of your mind for the future. You can always build your own controller if you’re looking a challenge, but you’ll have a hell of a time beating the decades of testing and development Sony has put into theirs.