Powering USB Devices With A Bench Supply Adapter Board

Sometimes you wanna test a piece of USB hardware, but you don’t just want to plug it into a random old phone charger. [KS-Elektronikdesign] has whipped up a useful tool for just that case, allowing one to easily power USB hardware from a common bench supply.

It would have been simple enough to whip up an adapter board to connect banana jacks to the power pins of a regular USB port. Easing the hookup process was indeed a part of the motivation for this project, in making it easy to power hardware that hooks up via USB-A and USB-C. However, it also goes a little further. It includes TUSB319 chip to handle the all-important power negotiation, without which many USB devices will not feel confident drawing their required amount of current.

There is also polarity protection and over-voltage protection to stop you from blowing stuff up if you hook the board up wrong, which might save you a smartphone or three in the lab. The board will allow negotiated output power up to 10 W via USB-A and 15 W via USB-C, which isn’t heaps, but will be fine for lots of smaller devices. You can up that to 25 W and 35 W respectively if the board is switched to pass-through mode. We particularly like the physical design—the board will plug straight into the banana plugs on any supply with a jack spacing of 19 to 23 mm.

Overall, this is a useful tool to have in the lab if you want to run USB hardware with the flexibility of the voltage and current limits available on your bench supply. There are other ways to power modern USB devices, too, and you can do all kinds of wild stuff if you learn about USB PD and USB PPS. If you’re working up your own nifty lab tools for similar purposes, we’d love to know about it on the tipsline.

This Week In Security: Linux Flaws, Python Ownage, And A Botnet Shutdown

The ides of security March are upon us — Qualys reports the discovery by their threat research unit of vulnerabilities in the Linux AppArmor system used by SUSE, Debian, Ubuntu, and Kubernetes as an additional security mechanism and application firewall.

AppArmor was added to Linux in 2010, and the vulnerabilities Qualys discovered have been present since 2017, and allow unprivileged (non-root) local users to elevate privileges by executing arbitrary code in the kernel, gaining root access, or perform a denial-of-service attack across the entire system by replacing all AppArmor behavior with “deny all” rules.

All Linux kernels since Linux 4.11 are vulnerable. If your Linux distribution enables AppArmor, and quite a few do, you’ll want to be updating as soon as fixes are available from your distribution maintainers. On systems with untrusted users, such as shared environments, VPS server environments, and the like, this is even more critical and urgent. Even on single-user systems, vulnerabilities like these allow other exploits, like the Python attack below, mechanisms to elevate their access and persistence.

At the time of writing, the full details of the AppArmor vulnerability are limited until the Linux Kernel team releases a stable version with the fixes for distribution maintainers. Qualys has published the technical write-up with the currently public information.

Python Projects Compromised

StepSecurity reports on a new campaign to infect Python projects on GitHub with a complex malware that, once deployed, appears to be yet another crypto and login stealer.

The attacker first gains access to the GitHub credentials via another info stealing worm – the Glassworm stealer infects VSCode extensions with over 35,000 downloads of infected extensions in October of 2025. Glassworm harvests NPM, GitHub, and OpenVSX credentials and sends them to a remote command and control (C2) server. It also harvests a wide range of crypto currency wallet extensions to steal crypto directly. Continue reading “This Week In Security: Linux Flaws, Python Ownage, And A Botnet Shutdown”

Google Unveils New Process For Installing Unverified Android Apps

It’s no secret that Google really doesn’t like it that people are installing Android applications from any other source than the Play Store. Last year they proposed locking everyone into their official software repository by requiring all apps to be signed by verified developers, an identity which would be checked against a Google-maintained list. After a lot of pushback a so-called ‘advanced flow’ for installing even unsigned APKs would be implemented, and we now know how this process is supposed to work.

Instead of the old ‘allow installing from unknown sources’ toggle, you are now going to have to dig deep into the Developer Options, to tap the Allow Unverified Packages setting and confirm that nobody is forcing you to do this. This starts a ‘security delay’ of twenty-four hours after you restart the device, following which you can finally enable the setting either temporarily or permanently. It would seem these measures are in place to make it more difficult for a scammer to coerce a user into installing a malicious app — whether or not that’s a realistic concern or not, we’re not sure.

When we last covered this issue this ‘advanced flow’ had just been introduced as an appeasement option. In addition to this a limited free developer account was also pitched, which now turns out to allow for up to only 20 device installations. If you want more than this, you have to pay the $25 fee and provide your government ID.

Although Google’s public pitch is still that this is ‘for user security’, it will also mean that third-party app stores are swept up in these changes, with developers who publish on these stores subject to the same verification rules. This means that Android users will have to learn quickly how to enable this new option as it will be rolled out to more countries over the coming months.

The reality is that scammers will simply work around this issue by buying up already verified developer accounts. At the same time, it’ll cripple third-party app stores and indie developers who had intended to distribute their Android app by simply providing an APK download.

A Candle-Powered Game Boy For Post-Apocalyptic Tetris

We’re not exactly worried about Armageddon here at Hackaday, but should we end up facing the end of the world as we know it, having something to pass the time would be nice. That’s why we were intrigued by [Janus Cycle]’s latest video where he both plays and powers a Game Boy by candlelight.

You’ve probably figured out the trick already: he’s using a Peltier module as a thermoelectric generator. Candles, after all, release a lot more energy as heat than light, and all that high-quality heat is just begging to be put to use somehow. It’s hardly a new idea; [Janus] references space-age radioisotope thermoelectric generators (RTGs) in the video, but back in the day the Soviets had a thermoelectric collar that fit around a kerosene lantern to power their tube radios.

In [Janus]’s case, he’s using a commercial module sandwiched between two heatsinks with the rather-questionable choice of a cardboard box reinforced with wooden skewers to hold it over the candle. Sure, as long as the flame doesn’t touch the cardboard, it should be fine, but you will not be at all surprised to see the contraption catch fire in the video’s intro. For all that, he doesn’t get enough power for the Game Boy — one module gets him only 2 V with tea light, but he has a second module and a second candle.

Doubling the energy more than doubles the fun, since a working Game Boy is way more than twice as fun as an un-powered one. But one candle should be more than enough power, so [Janus] goes back and optimizes his single-Peltier setup with a tall candle and actual thermal grease, and gets the Game Boy going again. Any fire marshals in the audience should look away, though, as he never gives up on keeping a candle in a cardboard box.

The “power something with a Peltier module” project is probably a right of passage for electronics enthusiasts, but most are more likely to play with the irony of candle-powered LEDs, or fans to cool the cold-side heatsink. We did see a phone charger one time, and that didn’t even involve open flames, which seems much safer than this. Remember — no matter how much you want to game after the end of the world, it’s not worth burning down your fallout shelter.

Continue reading “A Candle-Powered Game Boy For Post-Apocalyptic Tetris

Recording HDR Video With A Raspberry Pi

The Raspberry Pi line of single-board computers can be hooked up with a wide range of compatible cameras. There are a number of first party options, but you don’t have to stick with those—there are other sensors out there with interesting capabilities, too. [Collimated Beard] has been exploring the use of the IMX585 camera sensor, exploiting its abilities to capture HDR content on the Raspberry Pi.

The IMX585 sensor from Sony is a neat part, capable of shooting at up to 3840 x 2160 resolution (4K) in high-dynamic range if so desired. Camera boards with this sensor that suit the Raspberry Pi aren’t that easy to find, but there are designs out there that you can look up if you really want one. There are also some tricks you’ll have to do to get this part working on the platform. As [Collimated Beard] explains, in the HDR modes, a lot of the standard white balance and image control algorithms don’t work, and image preview can be unusable at times due to the vagaries of the IMX585’s data format. You’ll also need to jump some hurdles with the Video4Linux2 tools to enable the full functionality of these modes.

Do all that, recompile the kernel with some tweaks and the right drivers, though, and you’ll finally be able to capture in 16-bit HDR modes. Oh, and don’t forget—you’ll need to find a way deal with the weird RAW video files this setup generates. It’s a lot of work, but that’s the price of entry to work with this sensor right now. If it helps convince you, the sample shots shared by [Collimated Beard] are pretty good.

If you’re looking to record some really juicy, colorful imagery with the Raspberry Pi, this is a difficult but viable way to go. We’ve seen some other hardcore Raspberry Pi camera hacks of late, too.

Continue reading “Recording HDR Video With A Raspberry Pi”

Studying A Battle Born LFP Battery’s Death Under Controlled Conditions

The test setup for the Battle Born LFP cycling. (Credit: Will Prowse, YouTube)
The test setup for the Battle Born LFP cycling. (Credit: Will Prowse, YouTube)

There has been quite a bit of news recently about the  Battle Born LiFePO4 (LFP) batteries and how they are dying in droves if not outright melting their plastic enclosures. Although the subsequent autopsies show molten plastic spacers on the bus bars and discolored metal in addition to very loose wiring, it can be educational to see exactly what is happening during repeated charge-discharge cycles at a fraction of the battery’s rated current. Thus [Will Prowse] recently sacrificed another Battle Born 75 Ah LFP battery to the Engineering QA Gods.

This time around the battery was hooked up to test equipment to fully graph out the charging and discharging voltage and current as it was put through its paces. To keep the battery as happy as possible it was charged and discharged at a mere 49A, well below its rated 100A.

Despite this, even after a mere 14 cycles the battery’s BMS would repeatedly disconnect the battery, as recorded by the instruments. Clearly something wasn’t happy inside the battery at this point, but the decision was made to push it a little bit harder while still staying well below the rated current.

Continue reading “Studying A Battle Born LFP Battery’s Death Under Controlled Conditions”

Real Robot Makes Debut In Programming Game

Sometimes the right tool for the right job appears almost out of nowhere. That was certainly the case for [Jonathan] who came across an unusual but well-designed robot at a secondhand shop. The robot needed a bit of work to get back into a usable condition, but after that it was ready for use. For such a unique machine, it needed a unique place to work as well, so in this build [Jonathan] uses it as a real robot to recreate a popular board game meant to teach programming to children.

In the original board game, called Robot Turtles, there are no actual robots. Instead, players use cards to control turtles to reach objectives in much the same way that a programmer would solve a similar problem with a computer. A board game with such a name almost demands a robot, so [Jonathan] found a larger playing surface in the form of soft matting blocks, each with a number or letter, that can be assembled into a grid. To make the game, he built a Python application on top of the interface he reverse-engineered in a previous build. It handles the robot interface, control, input, and a PyGame GUI. The game can either be played in real-time, or the robot’s moves can be queued.

In addition to keyboard input, the bot can also be controlled by putting cards from the actual board game itself on an NFC reader he made. [Jonathan] has a four-year-old at home, so he hopes that all of these projects will have an impression and encourage experimentation and discovery of computers and programming.

Continue reading “Real Robot Makes Debut In Programming Game”