Mysterious Files PH

This week Jonathan chats with Philippe Humeau about Crowdsec! That company created a Web Application Firewall as on Open Source project, and now runs it as a Multiplayer Firewall. What does that mean, and how has it worked out as a business concept? Watch to find out!

• https://github.com/crowdsecurity/crowdsec
• https://crowdsec.net
• https://www.linkedin.com/company/53443483

Did you know you can watch the live recording of the show right on our YouTube Channel? Have someone you’d like us to interview? Let us know, or have the guest contact us! Take a look at the schedule here.

Direct Download in DRM-free MP3.

If you’d rather read along, here’s the transcript for this week’s episode.

Theme music: “Newer Wave” Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 4.0 License

If you’ve used Linux for a long time, you know that we are spoiled these days. Getting a new piece of hardware back in the day was often a horrible affair, requiring custom kernels and lots of work. Today, it should be easier. The default drivers on most distros cover a lot of ground, kernel modules make adding drivers easier, and dkms can automate the building of modules for specific kernels, even if it isn’t perfect.

So ordering a cheap WiFi dongle to improve your old laptop’s network connection should be easy, right? Obviously, the answer is no or this would be a very short post.

Plug and Pray

The USB dongle in question is a newish TP-Link Archer TX50U. It is probably perfectly serviceable for a Windows computer, and I got a “deal” on it. Plugging it in caused it to show up in the list of USB devices, but no driver attached to it, nor were any lights on the device blinking. Bad sign. Pro tip: lsusb -t will show you what drivers are attached to which devices. If you see a device with no driver, you know you have a problem. Use -tv if you want a little more detail.

The lsusb output shows the devices as a Realtek, so that tells you a little about the chipset inside. Unfortunately, it doesn’t tell you exactly which chip is in use.

Internet to the Rescue?

My first attempt to install a Realtek driver from GitHub failed because it was for what turned out to be the wrong chipset. But I did find info that the adapter had an RTL8832CU chip inside. Armed with that nugget, I found [morrownr] had several versions, and I picked up the latest one.

Problem solved? Turns out, no. I should have read the documentation, but, of course, I didn’t. So after going through the build, I still had a dead dongle with no driver or blinking lights.

Then I decided to read the file in the repository that tells you what USB IDs the driver supports. According to that file, the code matches several Realtek IDs, an MSI device, one from Sihai Lianzong, and three from TP-Link. All of the TP-Link devices use the 35B2 vendor ID, and the last two of those use device IDs of 0101 and 0102.

Suspiciously, my dongle uses 0103 but with a vendor ID of 37AD. Still, it seemed like it would be worth a shot. I did a recursive grep for 0x0102 and found a table that sets the USB IDs in os_dep/linux/usb_intf.c.

Of course, since I had already installed the driver, I had to change the dkms source, not the download from GitHub. That was, on my system, in /usr/src/rtl8852cu-v1.19.22-103/os_dep_linux/usb_intf.c. I copied the 0x0102 line and changed both IDs so there was now a 0x0103 line, too:

 {USB_DEVICE_AND_INTERFACE_INFO(0x37ad, 0x0103, 0xff, 0xff, 0xff), .driver_info = RTL8852C}, 
/* TP-Link Archer TX50U */

Now it was a simple matter of asking dkms to rebuild and reinstall the driver. Blinking lights were a good sign and, in fact, it worked and worked well.

DKMS

If you haven’t used DKMS much, it is a reasonable system that can rebuild drivers for specific Linux kernels. It basically copies each driver and version to a directory (usually /usr/src) and then has ways to build them against your kernel’s symbols and produce loadable modules.

The system also maintains a build/install state database in /var/lib. A module is “added” to DKMS, then “built” for one or more kernels, and finally “installed” into the corresponding location for use by that kernel. When a new kernel appears, DKMS detects the event — usually via package manager hooks or distribution-specific kernel install triggers — and automatically rebuilds registered modules against the new kernel headers. The system tracks which module versions are associated with which kernels, allowing parallel kernel installations without conflicts. This separation of source registration from per-kernel builds is what allows DKMS to scale cleanly across multiple kernel versions.

If you didn’t use DKMS, you’d have to manually rebuild kernel modules every time you did a kernel update. That would be very inconvenient for things that are important, like video drivers for example.

Of course, not everything is rosy. The NVidia drivers, for example, often depend on something that is prone to change in future Linux kernels. So one day, you get a kernel update, reboot, and you have no screen. DKMS is the first place to check. You’ll probably find it has some errors when building the graphics drivers.

Your choices are to look for a new driver, see if you can patch the old driver, or roll back to a previous working kernel. Sometimes the changes are almost trivial like when an API changes names. Sometimes they are massive changes and you really do want to wait for the next release. So while DKMS helps, it doesn’t solve all problems all the time.

Extras and Thoughts

I skipped over the part of turning off secure boot because I was too lazy to add a signing key to my BIOS. I’ll probably go back and do that later. Probably.

You have to wonder why this is so hard. There is already a way to pass the module options. It seems like you might as well let a user jam a USB ID in. Sure, that wouldn’t have helped for the enumeration case, but it would have been perfectly fine to me if I had just had to put a modprobe or insmod with a parameter to make the card work. Even though I’m set up for rebuilding kernel modules and kernels, many people aren’t, and it seems silly to force them to recompile for a minor change like this.

Of course, another fun answer would be to have vendors actually support their devices for Linux. Wouldn’t that be nice?

You could write your own drivers if you have sufficient documentation or the desire to reverse-engineer the Windows drivers. But it can take a long time. User-space drivers are a little less scary, and some people like using Rust.

What’s your Linux hardware driver nightmare story? We know you have one. Let us hear about it in the comments.

Last summer we took a look at FreeDOS as part of the Daily Drivers series, and found a faster and more complete successor to the DOS of old. The sojourn into the 16-bit OS wasn’t perfect though, as we couldn’t find drivers for the 2010-era network card on our newly DOS-ified netbook. Here’s [Inkbox] following the same path, and bringing with it a fix for that networking issue.

The video below is an affectionate look at the OS alongside coding a TRON clone in assembler, and it shows a capable environment within the limitations of the 16-bit mode. The modern laptop here can’t emulate a BIOS as it’s UEFI only, and after trying a UEFI-to-BIOS emulator with limited success, he hits on a different approach. With just enough Linux to support QEMU, he has a lightweight and extremely fast x86 BIOS platform with the advantage of legacy emulation of network cards and the like.

The point of Daily Drivers is wherever possible to use real hardware and not an emulator, as it’s trying to be the machine you’d use day to day. But we can see in a world where a BIOS is no longer a thing it becomes ever more necessary to improvise, and this approach is better than just firing up an emulator from a full-fat Linux desktop. If you fancy giving it a try, it seems less pain than the route we took.

You can read our look at FreeDOS 1.4 here.

FreeDOS logo: Bas Snabilie for the FreeDOS Project, CC BY 2.5.

Nobody likes power cords, and batteries always need recharging or replacing. What if your device could run on only the power it could gather together by itself from the world around it? It would be almost like free energy, although without breaking the laws of physics.

Hackaday’s 2026 Green-Powered Challenge asks you to show us your devices, contraptions, and hacks that can run on the power they can harvest. Whether it’s heat, light, vibration, or any other source of energy that your device gathers to keep running, we’d like to see it.

The top three entries will receive $150 shopping sprees courtesy of the contest’s sponsor, DigiKey, so get your entry in before April 24, 2026, to be eligible to win.

Honorable Mentions

As always, we have several honorable mention categories to get your creative juices flowing:

• Solar: In terms of self-powered anything, photovoltaic cells are probably the easiest way to go, but yet good light-harvesting designs aren’t exactly trivial either. Let’s see what you can run on just the sun. (Or even room lighting?)
• Anything But PV: Harnessing the light is too easy for you, then? How about piezo-electric power or a heat generator? Show us your best self-powering projects that work even when it’s dark out.
• Least Power: Maybe the smartest way to make your project run forever is to just cut down on the juice. If your project can run on its own primarily because of clever energy savings, it’s eligible for this mention.
• Most Power: How much of a challenge is building a solar-powered desk calculator in 2026? How about pushing it to the other extreme? Let’s see how much power you can consume while still running without batteries or cords. Does your off-grid shack count here? Let’s see it!

Prior Art

We’ve seen a lot of green-powered projects on Hackaday over the years, ranging from a solar-powered web server to a microcontroller powered by a BPW34 photodiode. Will your entry run off the juice harvested by an LED? It’s not inconceivable!

Solar cells only work when the sun shines, though. As long as your body is putting out heat, this Seebeck-effect ring will keep on running. (Matrix vibes notwithstanding!) Or maybe you want to go straight from heat to motion with a Stirling engine. And our favorite environmental-energy-harvester of all has to be the Beverly Clock and its relatives, running on the daily heat cycles and atmospheric pressure changes.

Your Turn

So what’s your energy-harvesting project? Batteries are too easy. Take it to the next level! All you have to do to enter is put your project up on Hackaday.io, pull down the “Submit Project to…” widget on the right, and you’re in. It’s that easy, and we can’t wait to see what you are all up to.

And of course, stay tuned to Hackaday, as we pick from our favorites along the way.

Before it became viable to distribute and play music tracks on home computers, the use of FM and Wavetable synthesis was very common, with MIDI Wavetable-based devices like the Roland MT-32 and SC-55 still highly sought after today. The Creative Midi Blaster MB-10 that [Yeo Kheng Meng] reviewed and tore down for an analysis isn’t quite as famous or sought after, but it provides a good example of what Creative Labs was doing at the time in this space.

Released in 1993, it definitely has more of a popular style vibe to it than the utilitarian Roland devices, even if this means highly impractical curves. In the list of features it claims Roland MT-32 emulation, which would have made it quite a bit more useful to the average user, including gamers of the era. Games like DOOM supported these MIDI devices for audio, for example.

In terms of price only the Roland SC-55ST comes close to the MB-10, similarly dropping a screen and a host of features. In terms of features the MB-10 claims far fewer instruments than the SC-55 variants, with even with the slightly higher priced SC-55ST massively outgunning it in raw specs. So would you ever buy the MB-10 back then and consider it a ‘good deal’? If $100 in 1990s money was worth losing full MIDI compatibility for, then it seems the answer was ‘yes’.

During the teardown of the MB-10 we can find an 8051-based Siemens processor that handles the MIDI interfaces and a Dream SAM8905 effects processor. Most of the remaining ICs are ROM chips that contain the firmware and MIDI banks, with the ROM dumps found in this GitHub repository.

The analog output stage includes the venerable TL074CN opamp and TDA1545 DAC, as well as a TDA2822M power amplifier IC. All of which is typical off-the-shelf for the era and also not something where Creative spent big bucks. It also appears that the 20-note polyphony claims on the box are false, as the Dream processor can only do 16 notes, which a quick test confirmed.

Despite being the cheaper option, it seems that most people with the spare cash to splurge on an external MIDI Wavetable device opted for a Roland one. These days it’s correspondingly quite hard to find an MB-10 for sale, unlike Roland MT-32 and SC-55 variants, yet considering software compatibility you really want to just stick with MT-32 and SC-55 compatibility anyway.

A lot of making goes on in this community these days, but sometimes you’ve just gotta do some old fashioned hacking. You might have grabbed an old Speak and Spell that you want to repurpose as an interface for a horrifyingly rude chatbot, or you’ve got a calculator that is going to become the passcode keypad for launching your DIY missiles. You want to work with the original hardware, but you need to figure out how to interface all the buttons yourself.

Thankfully, this is usually an easy job. The vast majority of buttons and keypads and keyboards are all implemented pretty much the same way. Once you know the basics of how to work with them, hooking them up is easy. It’s time to learn about key matrixes!

Wire ‘Em Up

Imagine you have a piece of consumer hardware, like a desk phone or an old control panel or something. You’d like to hook up a microcontroller to read all the buttons. Only, there’s 10, or 20, or 100 buttons… and your microcontroller just doesn’t have that many I/O pins! If you’re only familiar with hooking up a couple of push buttons to a couple of pins on an Arduino with some pull-up resistors, this can feel like an overbearing limitation. However, thankfully—there is a better way!

Enter the key matrix. It’s a very simple way of hooking up more buttons to less I/O pins. Imagine, for example, a nine-digit keypad, arranged in a 3 x 3 square. Assign three pins for columns, and three pins for rows. Each button in the keypad is hooked up to one row pin and one column pin. You can then, for example, energize each row pin in turn with a high output on a microcontroller, and detect whether any of the column pins go high by setting them to inputs. Do this quickly enough, and you can detect the state of all nine buttons with just six pins. In fact, the technique is generalizable—for n pins, you can address (n/2)² buttons. For six pins, that’s nine buttons.

You can even take it further, if you abandon the concept of a grid-like row-and-column layout. You can instead take six pins, for example, treating each one as its own “row.” You then place a button between it and every other pin, doing the same for each following pin in turn. You can then energize pin 1, while scanning pins 2 through six to see which buttons were pressed, and so on through the rest of the pins. This will net you a higher amount of buttons per pin—(n²-n)/2, in fact. For our six pin example, you could address 15 buttons this way.

When you expect multiple button presses at a time, you should add diodes into the button matrix to prevent current paths taking unexpected directions, and you might be lucky enough to find that your device already has them. There are even more advanced techniques, like Charlieplexing, that can address n² – n switches, but you’re less likely to come across this in the wild except for pin-constrained LED circuits.

These techniques are commonly referred to as multiplexing, and you’ll find it in all sorts of places. Everything from TV remotes to desktop calculators use this sort of technique to address many buttons without requiring lots of individual I/O pins.

Once you’re aware of this, it generally becomes straightforward to open up any such piece of hardware and figure out how the buttons work. All you need to do is hunt down the traces that connect from button to button, and slowly map out how they’re all connected. Mapping out the board can be challenging, though, because designers don’t always make the traces easy to follow. While something like a keypad may be logically connected in a grid-type layout, for example, it might not actually look like that on the PCB. The traces might be going every which way, complicating your efforts to figure out what’s connected to what.

A multimeter set to continuity mode is a great tool for this work. It lets you tap around a PCB to figure out which side of each button is connected to which other buttons, allowing you to figure out how the matrix is laid out. For example, if you were working with a phone keypad, you might start by putting a multimeter lead on one of the contacts of the “1” button. You might then find that it’s connected to one side of the buttons for 3, 5, 9, and *. You can then probe the other side of each of those buttons to find out what they’re connected to as well. Put all this data into a spreadsheet, and you’ll eventually see which two pins you need to check to determine the status of any button on the keypad.

Generally, you’ll also find all the traces lead back to some main chip or connector, where you can easily solder on leads to hook up your own microcontroller to read all the buttons. It’s not always this easy—some boards will help you out with accessible test pads, while others will only provide tiny solder points for fine pitch connectors. In a worst case scenario, you might have to scrape solder resist off some traces so you can solder your wires in that way.

Once you’ve got a microcontroller hooked up to your button pads, the hard part is over. You just need to write some simple code to scan the key matrix and detect button presses. You can use a pre-baked library if you so desire, or you can do it yourself. Ultimately, a simple way is to just energize a row with an output I/O pin while setting all the column pins to inputs to see if any buttons are currently pressed, and stepping through the rows from there. You can get fancier about it if you like if things like latency or anti-ghosting are critical to you, but that’s a discussion for another time. With the high clock speeds of modern microcontrollers, it’s trivial to read even a large key matrix at a rapid pace.

Figuring out how to interface button pads on random hardware is a fun hacking skill to learn, and is accessible for beginners.

It’s worth noting that you might also have to cut some traces going to components of the original circuit, depending on what you’re hacking on. Oftentimes it’s not necessary, particularly if you’re unfussed what happens to any original circuitry on the board. For example, if you do intend to restore the item you’re hacking to original function, it might not be good to be probing the keypad with a 5  V microcontroller when the original hardware all ran at 3.3V. You might hurt the original chips on board if some voltage ends up where you didn’t intend it to go.

If you’ve ever dreamed of turning an air conditioner remote into a secret access panel for your home security system, or making your microwave into a cellular phone, these techniques will serve you well. Go forth, hunt down the matrix, and hack an appliance’s original user interface into the control panel of your dreams.

Considering that the Serial Peripheral Interface bus semi-standard has been around since the early 1980s, it’s perhaps not that shocking that the controllers of the Super Nintendo Entertainment System (SNES) would take at least some strong design hints for the used protocol. This does however raise the question of exactly how compatible a SNES controller is when connected to the SPI master peripheral of any random MCU. Recently [James Sharman] set out to answer this question decisively.

The impetus for answering this question came after [James] designed a separate SNES controller board for his homebrew computer system, which led to many comments on that video saying that he could just have hooked the controller up to the SPI board in said homebrew system.

Here the short answer is that the SNES controller protocol is very close to SPI Mode-1, with a similar arrangement of clock/data/chip select (latch) lines and clocking. If you think of the SNES controller as an SPI device with just a MISO line, you’re basically there already. The only niggle that popped up was that the ‘MISO’ line does not get pulled into a high-impedance state when the active-low latch connection is pulled high.

This was fixable by introducing a 74HC125 tri-state buffer IC, after which both the original SD card and twin SNES controllers could be used simultaneously.