DIY TENS Machine is a Pain-Relief PCB

Transcutaneous Electrical Nerve Stimulation (TENS) is one of those things that sounds like it must be woo when you first hear of it. “A trickle of current that can deal with chronic pain better than the pills we’ve been using for decades? Yeah, and what chakras do you hook this doo-hickie up to?” It seems too good to be true, but in fact it’s a well-supported therapy that has become part of scientific medicine. There are no crystals needed, and you’re applying electrodes to the effected area, not your chakras. Like all medical devices, it can be expensive if you have to buy the machine out-of-pocket… but it is just a trickle of current. [Leon Hillmann] shows us its well within the range of hackability, so why not DIY?

[Leon]’s TENS machine is specifically designed to help a relative with hand problems, so breaks out electrodes for each finger, with one on the palm serving as a common ground. This type of TENS is “monophasic”– that is, DC, which is easier than balancing current flowing in two directions through quivering flesh. The direct current is provided at 32 V to the digit electrodes, safely kept to a constant amperage with a transistor-based current limiting circuit. The common ground in the palm is pulsed at a rate set by an ATmega32U4 and thus controllable: 14 Hz is given as an example.

Obviously if you want to reproduce this work you’re doing it at your own risk and need to consult with relevant medical professionals (blah blah blah, caveat gluteus maximus) but this particular sort of medical device is a good fit for the average hacker. Aside from prosthetics, we haven’t seen that much serious medical hacking since the pandemic. Still, like with synthesizing medical drugs, this is the kind of thing you probably don’t want to vibe code.

hackaday.com/2025/11/22/diy-te…

Building an Acoustic Radiometer

A Crookes radiometer, despite what many explanations claim, does not work because of radiation pressure. When light strikes the vanes inside the near-vacuum chamber, it heats the vanes, which then impart some extra energy to gas molecules bouncing off of them, causing the vanes to be pushed in the opposite direction. On the other hand, however, it is possible to build a radiometer that spins because of radiation pressure differences, but it’s easier to use acoustic radiation than light.

[Ben Krasnow] built two sets of vanes out of laser-cut aluminium with sound-absorbing foam attached to one side, and mounted the vanes around a jewel bearing taken from an analog voltmeter. He positioned the rotor above four speakers in an acoustically well-sealed chamber, then played 130-decibel white noise on the speakers. The aluminium side of the vanes, which reflected more sound, experienced more pressure than the foam side, causing them to spin. [Ben] tested both sets of vanes, which had the foam mounted on opposite sides, and they spun in opposite directions, which suggests that the pressure difference really was causing them to spin, and not some acoustic streaming effect.

The process of creating such loud sounds burned out a number of speakers, so to prevent this, [Ben] monitored the temperature of a speaker coil at varying amounts of power. He realized that the resistance of the coil increased as it heated up, so by measuring its resistance, he could calculate the coil’s temperature and keep it from getting too hot. [Ben] also tested the radiometer’s performance when the chamber contained other gasses, including hydrogen, helium, carbon dioxide, and sulfur hexafluoride, but none worked as well as air did. It’s a bit counterintuitive that none of these widely-varying gasses worked better than air did, but it makes sense when one considers that speakers are designed to efficiently transfer energy to air.

It’s far from an efficient way to convert electrical power into motion, but we’ve also seen several engines powered by acoustic resonance. If you’d like to hear more about the original Crookes radiometers, [Ben]’s also explained those before.

youtube.com/embed/lAeJvZfVLbE?…

hackaday.com/2025/11/22/buildi…

“Vogliamo Hackerarvi Ancora!”. La NSO Group non ci sta nella causa di WhatsApp per Pegasus

L’azienda israeliana NSO Group ha presentato ricorso contro una decisione di un tribunale federale della California che le vieta di utilizzare l’infrastruttura di WhatsApp per diffondere il software di sorveglianza Pegasus.

La vicenda, aperta ormai da diversi anni, trae origine da una denuncia di WhatsApp dopo la scoperta di un attacco su larga scala ai propri utenti. L’operazione sfruttava vulnerabilità “zero-day” e tecniche “zero-click”, permettendo l’installazione dello spyware senza alcuna azione da parte delle vittime.

Lo scorso ottobre la giudice Phyllis Hamilton ha stabilito che i server di WhatsApp erano stati impiegati in maniera impropria, consentendo l’infezione di circa 1.500 dispositivi. Secondo la sentenza, NSO avrebbe aggirato i sistemi di sicurezza della piattaforma e instradato traffico malevolo attraverso la sua rete. Da qui l’ingiunzione che impedisce all’azienda di continuare a sfruttare l’infrastruttura del servizio di messaggistica per distribuire malware.

NSO Group, nel tentativo di ribaltare la decisione, sostiene che il divieto mette a rischio la sopravvivenza stessa dell’azienda e compromette le attività di governi e agenzie di sicurezza che utilizzano Pegasus per indagini e operazioni contro il terrorismo.

La società accusa inoltre il tribunale di aver frainteso il funzionamento del software e di aver interpretato in modo errato il Computer Fraud and Abuse Act statunitense, influenzando così l’esito del procedimento.

Dal canto suo, WhatsApp respinge le argomentazioni di NSO e considera il ricorso un ulteriore tentativo di sottrarsi alle responsabilità.

Un portavoce della piattaforma ha ribadito che manipolare le comunicazioni degli utenti e sostituire i meccanismi di sicurezza viola la legge americana, e ha annunciato l’intenzione di chiedere la conferma definitiva del divieto in appello.

L'articolo “Vogliamo Hackerarvi Ancora!”. La NSO Group non ci sta nella causa di WhatsApp per Pegasus proviene da Red Hot Cyber.

RavynOS: Open Source MacOS with Same BSD Pedigree

That MacOS (formerly OS X) has BSD roots is a well-known fact, with its predecessor NeXTSTEP and its XNU kernel derived from 4.3BSD. Subsequent releases of OS X/MacOS then proceeded to happily copy more bits from 4.4BSD, FreeBSD and other BSDs.

In that respect the thing that makes MacOS unique compared to other BSDs is its user interface, which is what the open source ravynOS seeks to address. By taking FreeBSD as its core, and crafting a MacOS-like UI on top, it intends to provide the MacOS UI experience without locking the user into the Apple ecosystem.

Although FreeBSD already has the ability to use the same desktop environments as Linux, there are quite a few people who prefer the Apple UX. As noted in the project FAQ, one of the goals is also to become compatible with MacOS applications, while retaining support for FreeBSD applications and Linux via the FreeBSD binary compatibility layer.

If this sounds good to you, then it should be noted that ravynOS is still in pre-release, with the recently released ravynOS “Hyperpop Hyena” 0.6.1 available for download and your perusal. System requirements include UEFI boot, 4+ GB of RAM, x86_x64 CPU and either Intel or AMD graphics. Hardware driver support for the most part is that of current FreeBSD 14.x, which is generally pretty decent on x86 platforms, but your mileage may vary. For testing systems and VMs have a look at the supported device list, and developers are welcome to check out the GitHub page for the source.

Considering our own recent coverage of using FreeBSD as a desktop system, ravynOS provides an interesting counterpoint to simply copying over the desktop experience of Linux, and instead cozying up to its cousin MacOS. If this also means being able to run all MacOS games and applications, it could really propel FreeBSD into the desktop space from an unexpected corner.

hackaday.com/2025/11/22/ravyno…