This week Elliot Williams was joined by fellow Europe-based Hackaday staffer Jenny List, to record the Hackaday Podcast as the dusk settled on a damp spring evening.
On the agenda first was robotic sport, as a set of bipedal robots competed in a Chinese half-marathon. Our new Robot overlords may have to wait a while before they are fast enough chase us meatbags away, but it demonstrated for us how such competitions can be used to advance the state of the art.
The week’s stand-out hacks included work on non-planar slicing to improve strength of 3D prints. It’s safe to say that the Cartesian 3D printer has matured as a device, but this work proves there’s plenty more in the world of 3D printing to be developed. Then there was a beautiful record cutting lathe project, far more than a toy and capable of producing good quality stereo recordings.
Meanwhile it’s always good to see the price of parts come down, and this time it’s the turn of LIDAR sensors. There’s a Raspberry Pi project capable of astounding resolution, for a price that wouldn’t have been imaginable only recently. Finally we retrned to 3D printing, with an entirely printable machine, including the motors and the hot end. It’s a triumph of printed engineering, and though it’s fair to say that you won’t be using it to print anything for yourself, we expect some of the very clever techniques in use to feature in many other projects.
The week’s cant-miss articles came from Maya Posch with a reality check for lovers of physical media, and Dan Maloney with a history of x-ray detection. Listen to it all below, and you’ll find all the links at the bottom of the page.
In the 2000s, the DVD industry was concerned about piracy, in particular the threat to their business model presented by counterfeit DVDs and downloadable movies. Their response was a campaign which could be found embedded into the intro sequences of many DVDs of the era, in which an edgy font on a black background began with “You wouldn’t steal a car.. “. It was enough of a part of the background noise of popular culture that it has become a meme in the 2020s, reaching many people with no idea of its origins. Now in a delicious twist of fate, it has been found that the font used in the campaign was itself pirated. Someone should report them.
The font in question is FF Confidential, designed by [Just van Rossum], whose brother [Guido] you may incidentally know as the originator of the Python programming language. The font in the campaign isn’t FF Confidential though, as it turns out it’s XBAND Rough, a pirated copy of the original. What a shame nobody noticed this two decades ago.
It’s a bit of fun to delight in an anti-piracy campaign being caught using a dodgy font, but if this story serves to tell us anything it’s that the web of modern intellectual property is so labyrinthine as to be almost impossible to navigate without coming a cropper somewhere. Sadly the people caught out in this case would be the last to call for reform of the intellectual property environment, but as any sane heads would surely agree, such reform is overdue.
Today Melissa Lewis over on BlueSky pointed out that the font used nin the infamous "You wouldn't steal a car" anti-piracy campaign was actually designed by Just van Rossum, whose brother, Guido, created the Python programming language (bsky.app/profile/melissa.news/post/3ln7hx5rhcj2v)
She also pointed out that the font had been cloned and released illegally for free under the name "XBAND Rough". Naturally, it would be hilarious if the anti-piracy campaign actually turned out to have used this pirated font, so I went sleuthing and quickly found a PDF from the campaign site with the font embedded (web.archive.org/web/20051223202935/http://www.piracyisacrime.com:80/press/pdfs/150605_8PP_brochure.pdf).
So I chucked it into FontForge and yep, turns out the campaign used a pirated font the entire time!
Researchers at Aikido run the Aikido Intel system, an LLM security monitor that ingests the feeds from public package repositories, and looks for anything unusual. In this case, the unusual activity was five rapid-fire releases of the xrpl package on NPM. That package is the XRP Ledger SDK from Ripple, used to manage keys and build crypto wallets. While quick point releases happen to the best of developers, these were odd, in that there were no matching releases in the source GitHub repository. What changed in the first of those fresh releases?
The most obvious change is the checkValidityOfSeed() function added to index.ts. That function takes a string, and sends a request to a rather odd URL, using the supplied string as the ad-referral header for the HTML request. The name of the function is intended to blend in, but knowing that the string parameter is sent to a remote web server is terrifying. The seed is usually the root of trust for an individual’s cryptocurrency wallet. Looking at the actual usage of the function confirms, that this code is stealing credentials and keys.
The releases were made by a Ripple developer’s account. It’s not clear exactly how the attack happened, though credential compromise of some sort is the most likely explanation. Each of those five releases added another bit of malicious code, demonstrating that there was someone with hands on keyboard, watching what data was coming in.
The good news is that the malicious releases only managed a total of 452 downloads for the few hours they were available. A legitimate update to the library, version 4.2.5, has been released. If you’re one of the unfortunate 452 downloads, it’s time to do an audit, and rotate the possibly affected keys.
Zyxel FLEX
More specifically, we’re talking about Zyxel’s USG FLEX H series of firewall/routers. This is Zyxel’s new Arm64 platform, running a Linux system they call Zyxel uOS. This series is for even higher data throughput, and given that it’s a new platform, there are some interesting security bugs to find, as discovered by [Marco Ivaldi] of hn Security and [Alessandro Sgreccia] at 0xdeadc0de. Together they discovered an exploit chain that allows an authenticated user with VPN access only to perform a complete device takeover, with root shell access.
The first bug is a wild one, and is definitely something for us Linux sysadmins to be aware of. How do you handle a user on a Linux system, that you don’t want to have SSH access to the system shell? I’ve faced this problem when a customer needed SFTP access to a web site, but definitely didn’t need to run bash commands on the server. The solution is to set the user’s shell to nologin, so when SSH connects and runs the shell, it prints a message, and ends the shell, terminating the SSH connection. Based on the code snippet, the FLEX is doing something similar, perhaps with -false set as the shell instead:
$ ssh user@192.168.169.1
(user@192.168.169.1) Password:
-false: unknown program '-false'
Try '-false --help' for more information.
Connection to 192.168.169.1 closed.
It’s slightly janky, but seems set up correctly, right? There’s one more step to do this completely: Add a Match entry to sshd_config, and disable some of the other SSH features you may not have thought about, like X11 forwarding, and TCP forwarding. This is the part that Zyxel forgot about. VPN-only users can successfully connect over SSH, and the connection terminates right away with the invalid shell, but in that brief moment, TCP traffic forwarding is enabled. This is an unintended security domain transverse, as it allows the SSH user to redirect traffic into internal-only ports.
Next question to ask, is there any service running inside the appliance that provides a pivot point? How about PostgreSQL? This service is set up to allow local connections on port 5432 — without a password. And PostgreSQL has a wonderful feature, allowing a COPY FROM command to specify a function to run using the system shell. It’s essentially arbitrary shell execution as a feature, but limited to the PostgreSQL user. It’s easy enough to launch a reverse shell to have ongoing shell access, but still limited to the PostgreSQL user account.
There are a couple directions exploitation can go from there. The /tmp/webcgi.log file is accessible, which allows for grabbing an access token from a logged-in admin. But there’s an even better approach, in that the unprivileged user can use the system’s Recovery Manager to download system settings, repack the resulting zip with a custom binary, re-upload the zip using Recovery Manager, and then interact with the uploaded files. A clever trick is to compile a custom binary that uses the setuid(0) system call, and because Recovery Manager writes it out as root, with the setuid bit set, it allows any user to execute it and jump straight to root. Impressive.
Power Glitching an STM32
Micro-controllers have a bit of a weird set of conflicting requirements. They need to be easily flashed, and easily debugged for development work. But once deployed, those same chips often need to be hardened against reading flash and memory contents. Chips like the STM32 series from ST Microelectronics have multiple settings to keep chip contents secure. And Anvil Secure has some research on how some of those protections could be defeated. Power Glitching.
The basic explanation is that these chips are only guaranteed to work when run inside their specified operating conditions. If the supply voltage is too low, be prepared for unforeseen consequences. Anvil tried this, and memory reads were indeed garbled. This is promising, as the memory protection settings are read from system memory during the boot process. In fact, one of the hardest challenges to this hack was determining the exact timing needed to glitch the right memory read. Once that was nailed down, it took about 6 hours of attempts and troubleshooting to actually put the embedded system into a state where firmware could be extracted.
MCP Line Jumping
Trail of Bits is starting a series on MCP security. This has echoes of the latest FLOSS Weekly episode, talking about agentic AI and how Model Context Protocol (MCP) is giving LLMs access to tools to interact with the outside world. The security issue covered in this first entry is Line Jumping, also known as tool poisoning.
It all boils down to the fact that MCPs advertise the tools that they make available. When an LLM client connects to that MCP, it ingests that description, to know how to use the tool. That description is an opportunity for prompt injection, one of the outstanding problems with LLMs.
Bits and Bytes
Korean SK Telecom has been hacked, though not much information is available yet. One of the notable statements is that SK Telecom is offering customers a free SIM swapping protection service, which implies that a customer database was captured, that could be used for SIM swapping attacks.
WatchTowr is back with a simple pre-auth RCE in Commvault using a malicious zip upload. It’s a familiar story, where an unauthenticated endpoint can trigger a file download from a remote server, and file traversal bugs allow unzipping it in an arbitrary location. Easy win.
SSD Disclosure has discovered a pair of Use After Free bugs in Google Chrome, and Chrome’s Miracleptr prevents them from becoming actual exploits. That technology is a object reference count, and “quarantining” deleted objects that still show active references. And for these particular bugs, it worked to prevent exploitation.
Alvin Lucier was an American experimental composer whose compositions were arguably as much science experiments as they were music. The piece he is best known for, I Am Sitting in a Room, explored the acoustics of a room and what happens when you amplify the characteristics that are imparted on sound in that space by repeatedly recording and playing back the sound from one tape machine to another. Other works have employed galvanic skin response sensors, electromagnetically activated piano strings and other components that are not conventionally used in music composition.
While he was still alive, Lucier entered into a collaboration with a team of artists and biologists to create an exhibit that would push art, science and our notions of what it means to live beyond one’s death into new ground.
The resulting exhibit, titled Revivication, is a room filled with gong-like cymbals being played via actuators by Lucier’s brain…sort of. It is a brain organoid, a bundle of neurons derived from a sample of his blood which had been induced into pluripotent stem cells. The organoid sits on a mesh of electrodes, providing an interface for triggering the cymbals. A brain organoid derived from Alvin Lucier’s blood cells sits on a mesh of electrodes. “But the organoid isn’t aware of what’s happening, it’s not performing” we hear you say. While it is true that the bundle of neurons isn’t likely to have intuited hundreds of years of music theory or its subversion by experimental methodology, it is part of a feedback loop that potentially allows it to “perceive” in some way the result of its “actions”.
Microphones mounted at each cymbal feed electrical stimulus back to the organoid, presumably providing it with something to respond to. Whether it does so in any meaningful way is hard to say.
The exhibit asks us to think about where creativity comes from. Is it innate? Is it “in our blood” so to speak? Do we have agency or are we being conducted? Can we live on beyond our own deaths through some creative act? What, if anything, do brain organoids experience?
Older versions of Android contained various vulnerabilities that allowed gaining root access to the device. Many malicious programs exploited these to elevate their system privileges and gain persistence. The notorious Triada Trojan also used this attack vector. With time, the vulnerabilities were patched, and restrictions were added to the firmware. Specifically, system partitions in recent Android versions cannot be edited, even with superuser privileges. Ironically, this has inadvertently benefited malicious actors. While external malware now faces greater permission restrictions, pre-installed malware within system partitions has become impossible to remove. Attackers are leveraging this by embedding malicious software into Android device firmware. This is how one of our earlier findings, the Dwphon loader, functioned. It was built into system apps for over-the-air (OTA) updates. In March 2025, our research highlighted the Triada Trojan’s evolved tactics to overcome Android’s enhanced privilege restrictions. Attackers are now embedding a sophisticated multi-stage loader directly into device firmware. This allows the Trojan to infect the Zygote process, thereby compromising every application running on the system.
Key takeaways:
We discovered new versions of the Triada Trojan on devices whose firmware was infected even before they were available for sale. These were imitations of popular smartphone brands, and they remained available from various online marketplaces at the time of our research.
A copy of the Trojan infiltrates every application launched on an infected device. The modular architecture of the malware gives attackers virtually unlimited control over the system, enabling them to tailor functionality to specific applications.
In the current version of Triada, the payloads we have analyzed exhibit several malicious behaviors depending on the host application. Specifically, they can modify cryptocurrency wallet addresses during transfer attempts, replace links in browsers, send arbitrary text messages and intercept replies, and steal login credentials for messaging and social media apps.
The complete infection chain looks like this:
Triada Trojan infection chain
Kaspersky products detect the new version of Triada as Backdoor.AndroidOS.Triada.z..
System framework with a malicious dependency
Our initial investigation focused on native libraries included in the firmware of several devices, located in:
/system/framework/arm/binder.so
/system/framework/arm64/binder.so
The file is not present in a reference Android version. We discovered that the suspicious library was loaded into Zygote, the parent process for every Android application, by an infected AOT-compiled Android system framework ( boot-framework.oat) located in the same directory.
Malicious dependency in boot-framework.oat
The binder.so library registers a native method, println_native, for the android.util.Log class, used by applications installed on the device to write messages to Logcat. The implementation of this method calls a suspicious function, _config_log_println.
Call to the suspicious function
The _config_log_println function then calls two other functions that deploy three modules, contained in the rodata section of the malicious library, into every process launched on the device. One of the functions runs every time, while the other one only runs if the Android OS on the device is Version 9 or earlier.
Execution of the two malicious functions
Let us take a closer look at the modules that these launch.
1. Auxiliary module
This module from the rodata section of the malicious library is written to the application’s internal data directory under the name systemlibarm64\_%N%.jar, where N is a random number.
Loading the auxiliary module
The auxiliary module registers a receiver that can load arbitrary code files, although we did not see this happen in the cases described below. We would later call this module auxiliary because other payloads relied on it to perform their malicious functions. For example, for the com.android.core.info.config.JvmCore class from this module, binder.so registers native methods that can intercept calls to arbitrary methods within the process where the malware is running.
2. The mms-core.jar backdoor
This module undergoes a double XOR decryption process with different keys pulled from the rodata section of the malicious library. After decryption, it is saved to disk as /data/data/%PACKAGE%/mms-core.jar and then loaded using DexClassLoader. Once the loading is complete, the payload file is deleted.
Loading the backdoor
This mms-core.jar is a new iteration of a backdoor we mentioned in our earlier reports. In contrast to past versions, which exploited and modified system files to load itself into Zygote, the malware now achieves reliable Zygote access by leveraging a compromised system framework. Similar to previous versions, the backdoor downloads and executes other payloads.
3. Crypto stealer or dropper?
Immediately upon starting, the binder.so library reads the file /proc/%PID%/cmdline, with %PID% representing the system process ID. This is how the Trojan determines the package name of a running app.
Package name check
Based on the package name, binder.so loads either a crypto stealer loader (if the application is cryptocurrency-related) or a dropper from the rodata section. Neither payload is encrypted.
Triada crypto stealer
In previous Triada versions we analyzed, cryptocurrency applications were immediately infected with a crypto stealer. However, in these latest samples, the malicious module is a loader specifically targeting apps with the following package names: com.binance.dev com.wrx.wazirx com.coinex.trade.play com.okinc.okex.gp pro.huobi com.kubi.kucoin The entry point for this malicious loader is the onCreate method within the com.hwsen.abc.SDK class. In latest versions this module requests a configuration from a GitHub repository. Using a pseudo-random number generator, the sample selects a number (0, 1, or 2), each corresponding to a specific repository address.
Loading the configuration
All field values within the configuration are encrypted using AES-128 in ECB mode and then encoded with Base64. An example of a decrypted configuration is shown below: { addr: { durl: app-file.b-cdn[.]net/poctest/p… durl2: app-file.b-cdn[.]net/poctest/p… durl3: app-file.b-cdn[.]net/poctest/p… ver: 17, vname: pc2215202501061400.zip, online: true, rom: true, update: true, pkg: com.android.system.watchdog.x.Main, method: onCreate, param: t } } If online equals true, the loader downloads a payload from the URL specified in the durl field. If errors occur, it uses durl2 and durl3 as backup links. The downloaded payload is decrypted using XOR with a hardcoded key and saved to the application’s internal data directory under the name specified in the vname parameter. The pkg and method fields represent the class name and method, respectively, that will be called after the crypto stealer is loaded via DexClassLoader.
The downloaded payload attempts to steal the victim’s cryptocurrency using various methods. For example, it monitors running activities at preset intervals. This allows the Trojan to intercept attempts at withdrawing cryptocurrency and replace the victim’s crypto wallet addresses in the relevant text fields with addresses belonging to the attackers. To achieve this, the malware runs a depth-first search for all graphical sub-elements within the current frame, identifying the blockchain to which the funds are being sent. The Trojan then swaps the crypto wallet address with a hardcoded one and replaces the click handlers of all buttons in the application with a proxy handler that swaps the crypto wallet address again, ensuring the attackers can steal the funds. Interestingly, the crypto stealer also replaces image elements with generated QR codes containing attacker-controlled wallet addresses.
Text and image replacement
The Trojan also monitors the clipboard contents and, if it finds a crypto wallet address, it gets replaced with an address belonging to the attackers.
Clipboard hijacking
Dropper
If the binder.so library happens to run in an app unrelated to cryptocurrency, it downloads a different payload. This is a dropper that calls the onCreate method within the com.system.framework.api.vp2130.services class. Depending on the version, it can extract up to three Base64-encoded additional modules from its own contents.
The dropper loads a com.android.packageinstaller.apiv21.ApiV21 class from the first module inside the system APK installer app. This class registers a receiver that allows other modules to install arbitrary APKs on the device and also uninstall any apps.
Malicious receiver
Beginning with Android 13, apps from untrusted sources are restricted from accessing sensitive permissions, such as those for accessibility services. To bypass these restrictions for sideloaded apps, the receiver installs them through an installation session in newer Android versions.
The com.system.framework.audio.Audio class is loaded from the second module to block network connections. Depending on the system architecture, it decodes and loads a native helper library. This library uses the xhook library to intercept calls to the getaddrinfo and android_getaddrinfofornet functions. These functions handle communication with the dnsproxyd service in Android, which performs DNS requests using a client-server model. If the attackers have sent a command to block a specific domain, its name is replaced by a hook redirecting to 127.0.0.1, making access to the original domain impossible.
Intercepting the dnsproxyd communications functions
Thus, the malware can block requests to anti-fraud services unless they use a custom DNS implementation.
The com.system.framework.api.init.services class is also loaded from the third module to download arbitrary payloads. For this purpose, the malware periodically transmits a wealth of device information (MAC address, model, CPU, manufacturer, IMEI, IMSI, etc.), along with the host application name and version, to its command-and-control server. Before being sent, the data is encrypted using AES-128 in CBC mode and then encoded with Base64. The C2 responds with a JSON file containing information about the payload, also encrypted with AES-128 in CBC mode. The infected device receives the key and initialization vector (IV) RSA-encrypted from the C2 within the same JSON.
Decoding, loading, and running the payload
For convenience, we will refer to this module as the Triada backdoor going forward. It is this module that holds the greatest interest for our research, as it provides the malware with a wide range of capabilities. A closer look at the Triada threat actor’s objectives yielded a somewhat surprising result. Whereas previous malicious samples mainly displayed ads and signed users up for paid subscriptions, the attackers’ priorities have now drastically changed.
What Triada downloads
To understand exactly how the attackers’ priorities have shifted, we decided to try downloading the payloads for various popular apps. We observed that the binder.so malicious library passes a flag to the dropper upon starting if the application’s name is on a list within its code. This list included both system apps and popular apps from official stores.
Some apps from binder.so
This list served as the starting point for our investigation. For all the listed applications, we sent requests to the malware C2, and some of them returned links to download payloads. As an example, this is the response we received from the Trojan after requesting a payload for Telegram: { a: 0, b: 40E315FB00M8EP2G49008INIK7000002, c: 1373225559, d: [{ a: 72, b: ompe2.7u6h8[.]xyz/tgzip/44a08d… c: com.tgenter.tmain.Engine, d: start, e: 32, f: 44a08dc22b45b9418ed427fd24c192c6, g: mp2y3.sm20j[.]xyz/tgzip/44a08d… }, { a: 127, b: ompe2.7u6h8[.]xyz/tgzip/tgnetu… c: com.androidx.tlttl.tg.CkUtils, d: init, e: 7, f: 37fd87f46e95f431b1977d8c5741d2d5, g: mp2y3.sm20j[.]xyz/tgzip/tgnetu… } ], e: 245, g: [com.instagram.android], h: org.telegram.messenger.web,org.telegram.messenger,com.whatsapp.w4b,com.fmwhatsapp,com.gbwhatsapp,com.yowhatsapp,com.facebook.lite,com.facebook.orca,com.facebook.mlite,com.skype.raider,com.zhiliaoapp.musically,com.obwhatsapp,com.ob3whatsapp,com.ob2whatsapp,com.jtwhatsapp,com.linkedin.android,com.zhiliaoapp.musically.go,com.opera.browser.afin,com.heytap.browser,com.sec.android.app.sbrowser,org.mozilla.firefox,com.microsoft.emmx,com.microsoft.emmx.canary,com.opera.browser } The payload information from the C2 server was received as an array of objects, with each containing two download URLs (primary and backup), the MD5 hash of the file to download, the module’s entry point details, and its ID. After downloading, the modules were decrypted twice using XOR with different keys.
Triada decrypting the payload
In addition to this, the response from the C2 contained other package names. By using these, we were able to obtain various further payloads.
It should be noted that according to the Android security model, unprivileged users do not normally have access to certain application data. However, as mentioned earlier, the malware is loaded by the Zygote process, which allows it to bypass OS restrictions because each payload runs within the process of the app it targets. This means the modules can obtain any application data, and the attackers actively exploit this in subsequent stages of infection. Furthermore, each additional malware payload can use all the permissions available to the app.
During module analysis, we also noted the significant skill of the Triada creators: each payload is tailored to the target app’s characteristics. Let us see which modules the Trojan loaded into some popular Android apps.
Telegram modules
For the Telegram messaging app, the Triada backdoor downloaded two modules at the time of this research. The first module (b8a745bdc0e083ffc88a524c7f465140) launches a malicious task within the messaging app’s context once every 24 hours. We believe that the attackers thoroughly examined Telegram’s internal workings before coding this task.
Malicious task code
Initially, the malicious task tries to obtain the victim’s account details. To do this, the module reads a string associated with the user key from the key-value pairs saved using SharedPreferences in the app settings XML file named userconfig. The string contains Base64-encoded serialized data about the Telegram user, which the messaging client code deserializes to communicate with the API. The malware takes advantage of this: Triada tries several reflection-based methods to read the user data.
Deserializing victim account details
The malware sends the following user information to the C2 server if it has not done so previously:
A serialized string containing the victim’s account details.
The victim’s phone number.
The contents of the tgnet.dat file from the application’s data directory. This file stores Telegram authentication data including the user’s token, which allows the attackers to gain complete control over the victim’s account.
The string with id=1 from the params table in the cache4.db database.
This payload also contains unused code for displaying ads.
The second module (fce117a9d7c8c73e5f56bda7437bdb28) uses Base64 to decode and then execute another payload (8f0e5f86046faed1d06bca7d3e48c0b8). This payload registers its own observer for new Telegram messages, which checks their content. If the message text matches regular expressions received by the Trojan from the C2 server, the message is deleted from the client. This module also attempts to delete Telegram notifications about new sessions.
Filtering messages based on content
Additionally, the malware tries to initiate a conversation with a bot that was no longer there at the time of our research.
Initiating communication with an unknown bot
Instagram module
This module (3f887477091e67c6aaca15bce622f485) starts by requesting the device’s advertising ID from Google Play services, which it then uses as the victim ID. After that, a malicious task runs once every 24 hours, sequentially scanning all XML files used by SharedPreferences until it finds the first file whose name begins with UserCookiePrefsFile_. This file contains the cookies for active Instagram sessions, and intercepting these sessions allows the attackers to take over the victim’s account. The task also collects all files ending in batch from the analytics directory inside data.
The malware reading the internal files
These files, along with information about the infected device, are encoded in Base64 and sent to the C2 server.
Browser module
This module (98ece45e75f93c5089411972f9655b97) is loaded into the browsers with the following package names:
com.android.chrome
org.mozilla.firefox
com.microsoft.emmx
com.microsoft.emmx.canary
com.heytap.browser
com.opera.browser
com.sec.android.app.sbrowser
com.chrome.beta
First, it establishes a connection with the C2 server over TCP sockets. Then, using the RSA algorithm, it encrypts an IV and key concatenation for AES-128 in CBC mode. The Trojan uses AES to encrypt the information about the infected device and then combines it with the key and IV into a single large buffer, which it sends to the TCP socket.
Code snippet for C2 communication
The C2 server responds with a buffer encrypted with the same parameters as the request it received from the infected device. The response contains a task to periodically substitute links opened in the browser. An example of this task is shown below. { a: 0, b: 1, c: 65, d: { a: 17, b: stas.a691[.]com/, c: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23], d: 2880 } } The link replacement works as follows. The module first checks the version and name of the browser that it is running in to register hooks for the methods that the browser uses for opening links.
Launching browser-specific functionality
We noted earlier that in the initial stages, the Trojan downloaded an auxiliary module that implements its functionality to intercept arbitrary methods. The browser module utilizes this to interfere with the process of opening pages in various browsers.
Using the auxiliary module
In addition, the malware uses reflection to replace the Instrumentation class instance for the app. The execStartActivity method, which launches app activities, is replaced in the proxy class.
Malicious call in the Instrumentation proxy class
In Android, application activities are launched by broadcasting an intent with a specific action. If the application has an activity with an intent filter that declares the ability to handle the action, Android will launch it. When an application opens a link in a browser, it creates and sends an Intent instance with the action android.intent.action.VIEW, including the URI to be opened. Triada substitutes the URI in the received Intent instance.
Replacing the link in the Intent instance
In the samples we analyzed, the C2 server sent links to advertising resources. However, we believe that the malware creators could also use this functionality for, say, phishing.
WhatsApp modules
For WhatsApp, the Trojan’s C2 server would provide two modules. One of these (d5bc1298e436424086cb52508fb104b1) runs a malicious task within the WhatsApp client’s context every five minutes. This task reads various keys essential for the client’s operation, as well as data about the active session.
The Trojan reading WhatsApp login credentials
This data, along with information about the victim’s device, is forwarded to the C2 server, giving the attackers complete access to the victim’s WhatsApp account.
The other module (dc731e55a552caed84d04627e96906d5) starts by intercepting WhatsApp client functions that send and receive messages. The threat actor employed an interesting technique to work around class name obfuscation in WhatsApp code. The module’s code contains the names of the class and method being intercepted, specific to different WhatsApp versions. This likely required the attackers to manually analyze how each version worked. It is worth noting too that if the module’s code lacks the class names for the specific client version, the malware can request an interception configuration from the attackers’ C2 server.
If the interception is successful, the module continues its operation by sending data about the infected device to the C2 server and receiving a TCP socket IP address in response. Commands are then transmitted through this socket, allowing the malware to perform the following actions:
Send arbitrary WhatsApp messages.
Delete sent messages on the device to cover its tracks.
Close the connection.
Snippet of the command handler
LINE module
This module (1d582e2517905b853ec9ebfe77759d15) runs inside the LINE messaging app. First, the malware gathers information about the infected device and sends it to the C2 server. Subsequently, every 30 seconds, it collects internal app data, specifically the PROFILE_AUTH_KEY and PROFILE_MID values from the settings table in the naver_line database. The malicious module also obtains the User-Agent string and additional information to mimic HTTP requests as if they were coming from the messaging client itself. Additionally, the malware decrypts the user’s phone number and region from the naver_line database and uses reflection to obtain the application’s access token, which allows it to take over the victim’s account.
Obtaining an access token
The module sends the data it collects to the C2 server.
Collecting and sending data
Skype module
This module (b87706f7fcb21f3a4dfdd2865b2fa733) runs a malicious task every two minutes that attempts to send information about the infected device to the C2. Once the C2 accepts the request, the task stops, and the Trojan begins reading internal Skype files every hour. Initially, the module tries to extract a token that allows access to the Skype account from the React Native framework keychain.
Triada extracting a token from the keychain
Failing to obtain the token through this method, the malware then tries to locate it within WebView cookies.
Extracting a token from the cookies
This token is then sent to the Trojan’s C2 server, thus compromising the victim’s account.
The versions of Triada we have seen contain no payloads for Microsoft Teams or Skype for Business. However, we believe that after Microsoft sunsets Skype, the attackers might add new malicious modules for these apps.
TikTok module
This module (993eb2f8bf8b5c01b30e3044c3bc10a3) sends information about the infected device to the attackers’ server once a day. Additionally, the malware collects a variety of data about the victim’s account. For example, it reads cached TikTok cookies from an internal directory, which might have been used by WebView within the app. The attackers are interested in the msToken in these cookies, as it is necessary for interacting with the TikTok API. The module also extracts other information from the TikTok client, such as the user ID ( secUID), the User-Agent for API requests, and more. We believe that the attackers need this data to bypass TikTok API restrictions and simulate a real device when making API requests. Every five minutes, the malicious module attempts to send all data it collects to the attackers’ server.
Stealing TikTok account data
Facebook modules
One of such modules (b187551675a234c3584db4aab2cc83a9) runs a malicious task every minute that compares the parent app package name against the following list:
com.facebook.lite
com.facebook.mlite
com.facebook.orca
If the name matches one of the above, the malware steals the Facebook authentication cookies.
Stealing Facebook credentials
Another module (554f0de0bddf30589482315fe336ea72) sends data about the infected device to the C2. The server responds with a link to be opened in WebView, as well as JavaScript code to execute on the page. The malware can upload certain elements from this page to the C2 server, which potentially could be used by attackers to steal the victim’s account data.
SMS modules
These malicious components are injected into SMS apps. One of them (195e0f334beb34c471352179d422c42f) starts by registering its own proxy receiver for incoming SMS and MMS messages, as well as its own message observer. Following this, the malware retrieves rules from the C2 server, storing these in a separate database. The content of each received message is filtered on the basis of these rules.
Checking message content
The flexibility of these rules enables the malware to respond to specific SMS messages by extracting codes using regular expressions. We believe the Trojan creators primarily use this capability to sign victims up for paid subscriptions. Additionally, the module can send arbitrary SMS messages when instructed by the C2 server.
Interestingly, the module contains unused code snippets that are valuable for analysis — they also function as message filtering rules. Each rule includes a string value that defines its type: an MD5 hash of certain data. The module code contains methods named matchWhatsapp and matchRegister that use the same rule type. Analysis of matchWhatsapp revealed that this malicious component previously could cover other modules’ tracks and delete SMS messages containing verification codes for logging in to the victim’s WhatsApp account. The use of the same rule type suggests that matchRegister is also employed by the malicious module to conceal its activity, possibly to secretly register accounts. This method is likely obsolete because the malware now supports receiving rules from the C2 server.
Rule for intercepting WhatsApp verification SMS messages
The second module (2ac5414f627f8df2e902fc34a73faf44) is likely an auxiliary component for the first one. The thing is, Android performs a check on the addressee when an SMS is being sent. If the message is being sent to a short code (premium SMS), the user will be prompted to confirm their intention to send. This measure aims to prevent financial losses for device owners encountering SMS Trojans. The SMSDispatcher class in the Android framework checks if the app has permission to send premium SMS messages. To do this, it calls the getPremiumSmsPermission method within the SmsUsageMonitor class, which stores premium SMS sending policies for each application using the SharedPreferences mechanism with the key premium-sms-policy. The policies are integers that can take the following values:
1: User confirmation is required before sending a premium SMS.
2: The app is prohibited from sending premium SMS messages.
3: Sending premium SMS messages is allowed, and user confirmation is not required.
The malicious module sets the policy value for SMS messaging apps to 3, thereby clearing obstacles for the previous module. Notably, this is an undocumented Android feature, which further highlights the malware authors’ advanced skill level.
Method for overriding premium SMS sending policies
Reverse proxy
As far as we know, this module (3dc21967e6fab9518275960933c90d04), integrates into the Google Play Services app. Immediately upon starting, it transmits information about the infected device to the C2 server. The server responds with an IP address and port, which the malware uses to listen for commands via a modified version of the EasySocket library. The commands are integers that can take three values:
1: Establish a connection with an arbitrary TCP endpoint, assigning to it the ID transmitted in the command.
2: Terminate the TCP connection with the specified ID.
4: Send data over the TCP connection with the specified ID.
Processing received data
Thus, the main purpose of this module is to turn the infected device into a reverse proxy, essentially giving the attackers network access through the victim’s device.
Call interception
This module (a4f16015204db28f5654bb64775d75ad) is injected into the device’s phone app. It registers a malicious receiver that, upon receiving intents, can execute arbitrary JavaScript code using WebView.
Executing arbitrary code via the malicious receiver
The malware provides the JavaScript code with an interface to call certain Java functions. One of these functions takes the victim’s phone number and sends an intent that includes it.
An intent with a phone number
The command number is transmitted in the type field of the intent. However, the module lacks a handler for this number. We assume that it is implemented in a different payload that we were unable to obtain during our investigation.
We also believe that this module is still under development. For example, similar to the browser module, it replaces the Instrumentation class to substitute the number opened using the android.intent.action.VIEW intent. However, the module lacks number substitution code.
Instrumentation proxy class
We strongly believe the number substitution functionality exists in another version of this module or will be added in the near future.
Clipper
Our data indicates that this module (04e485833e53aceb259198d1fcba7eaf) integrates into the Google Play app. Upon starting, it requests a comma-separated list of attackers’ cryptocurrency wallet addresses from the C2 server. If it cannot get the addresses, the Trojan uses hardcoded ones. After that, the module checks the clipboard every two seconds. If it finds a cryptocurrency wallet address, it replaces it with one controlled by the attackers. Additionally, the malware registers an event handler for clipboard changes, where it also checks and swaps the content.
Clipboard hijacking
Additional module
In our previous report, we described the malicious modules downloaded by the initial Triada backdoor. We decided to check if the list of payloads had changed. Unfortunately, at the time of our research, the backdoor C2 server was not sending links to download additional modules. However, we noticed that the module entry points used a consistent special naming format – we will discuss this in more detail later. This allowed us to find another Triada malware sample in our telemetry. The module is named BrsCookie_1004 (952cc6accc50b75a08bb429fb838bff7), and is designed for stealing Instagram cookies from web browsers.
Stealing cookies
Campaign features
Our analysis of this Trojan revealed several interesting details. For example, it shows similarities to earlier versions of Triada (308e35fb48d98d9e466e4dfd1ba6ee73): these implement the same logic for loading additional modules as the mms-core.jar backdoor deployed by the infected framework.
Loading modules in older Triada versions
Loading modules in mms-core.jar
Furthermore, lines starting with PPP appear regularly in the module code.
Creating log entries in an older Triada version
Loading a module in binder.so in a newer Triada version
Functions from the binder.so malicious library set system properties similar to those in previous Triada versions. These and other similarities lead us to believe that the sample we analyzed is a new version of Triada.
While analyzing the modules, we encountered comments in Chinese, suggesting that the developers are Chinese native speakers. Additionally, one of the C2 servers used by the Triada modules, g.sxim[.]me, caught our attention. This domain was also used as a C2 server for a module of the Vo1d backdoor, suggesting a potential link to Triada.
Distribution vector
In all known infection cases, the device firmware had a build fingerprint whose last letter differed from officially published firmware fingerprints. Searching for similar fingerprints led us to discussion boards where users complained about counterfeit devices purchased from online stores. It is likely that a stage in the supply chain was compromised, with the vendors in online stores possibly being unaware that they were distributing fake devices infected with Triada.
User complaining about a counterfeit device
Translation: “The journey of a counterfeit device bought in [redacted]. <…> Please keep this discussion in case it helps some poor fellow like me to restore the phone on their own. <…> Previous version: 8Gb / 256Gb / 14.0.6.0 (TGPMIXN). Current version: 4Gb / 128Gb / 14.0.6.0 (TGPMIXM)”
Victims
According to KSN telemetry, our security solutions have detected over 4500 infected devices worldwide. The highest numbers of affected users were detected in Russia, the United Kingdom, the Netherlands, Germany, and Brazil. However, the actual number of infected devices could be much higher, given the unusual distribution method described in this article. The diagram below shows the TOP 10 countries with the highest numbers of users attacked between March 13 and April 15, 2025.
TOP 10 countries with the highest numbers of users attacked by Triada, March 13 – April 15, 2025 (download)
Separately, we decided to calculate the amount of cryptocurrency the Triada creators have stolen. To do this, we queried the Trojan’s C2 servers, receiving replacement wallet addresses in response. Findings from open-source research indicated that since June 13, 2024, the attackers had amassed more than $264,000 in various cryptocurrencies in wallets under their control. Below is a diagram showing the balance of several attacker-controlled wallets.
A profitability chart for the threat actor’s TRON wallets (download)
Conclusion
The new version of the Triada Trojan is a multi-stage backdoor giving attackers unlimited control over a victim’s device. The modular architecture provides its authors with a range of malicious capabilities, including targeted delivery of new modules and mass infection of specific applications. If your phone has been infected with Triada, we recommend following these rules to minimize the consequences of malicious activity:
Install a clean firmware on your device.
Avoid using messaging apps, crypto wallets, or social media clients currently on your device before installing new firmware.
“TheC64” is a popular recreation of the best selling computer of all time, the original Commodore 64. [10p6] enjoys hacking on this platform, and recently whipped up a new mod — adding a 9-pin Atari joystick connector for convenience.
When it comes to TheC64 units, they ship with joysticks that look retro, but aren’t. These joysticks actually communicate with the hardware over USB. [10p6]’s hack was to add an additional 9-pin Atari joystick connector into the joystick itself. It’s a popular mod amongst owners of TheC64 and the C64 Mini. All one needs to do is hook up a 9-pin connector to the right points on the joystick’s PCB. Then, it effectively acts as a pass-through adapter for hooking up other joysticks to the system.
While this hack could have been achieved by simply chopping away at the plastic housing of the original joystick, [10p6] went a tidier route. Instead, the joystick was granted a new 3D printed base that had a perfect mounting spot for the 9-pin connector. Clean!
While tools like CRISPR have blown the field of genome hacking wide open, being able to predict what will happen when you tinker with the code underlying the living things on our planet is still tricky. Researchers at Stanford hope their new Evo 2 DNA generative AI tool can help.
Trained on a dataset of over 100,000 organisms from bacteria to humans, the system can quickly determine what mutations contribute to certain diseases and what mutations are mostly harmless. An “area we are hopeful about is using Evo 2 for designing new genetic sequences with specific functions of interest.”
To that end, the system can also generate gene sequences from a starting prompt like any other LLM as well as cross-reference the results to see if the sequence already occurs in nature to aid in predicting what the sequence might do in real life. These synthetic sequences can then be made using CRISPR or similar techniques in the lab for testing. While the prospect of building our own Moya is exciting, we do wonder what possible negative consequences could come from this technology, despite the hand-wavy mention of not training the model on viruses to “to prevent Evo 2 from being used to create new or more dangerous diseases.”
When you start building lots of something, you’ll know the value of accurate fixturing. [Chris Borge] learned this the hard way on a recent mass-production project, and decided to solve the problem. How? With a custom fixturing tool! A 3D printed one, of course.
Chris’s build is simple enough. He created 3D-printed workplates covered in a grid of specially-shaped apertures, each of which can hold a single bolt. Plastic fixtures can then be slotted into the grid, and fastened in place with nuts that thread onto the bolts inserted in the base. [Chris] can 3D print all kinds of different plastic fixtures to mount on to the grid, so it’s an incredibly flexible system.
3D printing fixtures might not sound the stoutest way to go, but it’s perfectly cromulent for some tasks. Indeed, for [Chris]’s use case of laser cutting, the 3D printed fixtures are more than strong enough, since the forces involved are minimal. Furthermore, [Chris] aided the stability of the 3D-printed workplate by mounting it on a laser-cut wooden frame filled with concrete. How’s that for completeness?
[Bill Dudley] had a problem. He had an Onkyo AV receiver that did a great job… until it didn’t. A DSP inside failed. When that happened, the main microprocessor running the show decided it wouldn’t play ball without the DSP operational. [Bill] knew the bulk of the audio hardware was still good, it was just the brains that were faulty. Thus started a 4-month operation to resurrect the Onkyo receiver with new intelligence instead.
[Bill’s] concept was simple. Yank the dead DSP, and the useless microprocessor as well. In their place, an ESP32 would be tasked with running things. [Bill] no longer cared if the receiver had DSP abilities or even the ability to pass video—he just wanted to use it as the quality audio receiver that it was.
His project report steps through all the hard work he went through to get things operational again. He had to teach the ESP32 to talk to the front panel display, the keys, and the radio tuner. More challenging was the core audio processor—the obscure Renaisys R2A15218FP. However, by persevering, [Bill] was able to get everything up and running, and even added some new functionality—including Internet radio and Bluetooth streaming.
It’s a heck of a build, and [Bill] ended up with an even more functional audio receiver at the end of it all. Bravo, we say. We love to see older audio gear brought back to life, particularly in creative ways. Meanwhile, if you’ve found your own way to save a piece of vintage audio hardware, don’t hesitate to let us know!
Most people have wished for the ability to talk to other animals at some point, until they realized their cat would mostly insult them and ask for better service, but researchers are getting closer to a dolphin translator.
DolphinGemma is an upcoming LLM based on the recordings from the Wild Dolphin Project. Using the hours and hours of dolphin sounds recorded by researchers over the decades, the hope is that the LLM will allow us to communicate more effectively with the second most intelligent species on the planet.
The LLM is designed to run in the field on Google Pixel phones, due to it being based on Google’s in-house Gemini product, which is a bit less cumbersome than hauling a mainframe on a dive. The Wild Dolphin Project currently uses the Georgia Tech developed CHAT (Cetacean Hearing Augmentation Telemetry) device which has a Pixel 6 at its heart, but the newer system will be bumped up to a Pixel 9 to take advantage of all those shiny new AI processing advances. Hopefully, we’ll have a better chance of catching when they say, “So long and thanks for all the fish.”
In un mondo dove ogni giorno si registrano migliaia di attacchi informatici, molte aziende continuano a sottovalutare l’importanza della cybersecurity, affidandosi a “sedicenti esperti” improvvisati o poco competenti. Da questa triste realtà nasce la nuova serie satirica di Red Hot Cyber: Amiocuggino – le action figure della cyber security.
Una provocazione, certo.
Ma anche uno specchio fedele di ciò che troppo spesso accade nel panorama aziendale italiano e non solo: ci si affida a persone prive di reali competenze, con la convinzione che “tanto basta saper smanettare” oppure “che vuoi che accada a noi?”. Il risultato? Sistemi vulnerabili, dati esposti, e un falso senso di protezione.
Quando il risparmio diventa un costo enorme
La verità è semplice: nella cybersecurity, il risparmio può diventare il tuo peggior investimento.
Le conseguenze di un data breach non sono molto economiche. Le perdite reputazionali possono devastare l’immagine di un’azienda, minare la fiducia di clienti e partner, e compromettere anni di lavoro.
E se l’attacco è di tipo ransomware, il danno può diventare esponenziale: intere filiere produttive si bloccano, la produzione si arresta, gli ordini non vengono evasi, e ogni giorno fermo si traduce in migliaia – se non milioni – di euro persi.
Tutto per non aver investito in modo serio in prevenzione, monitoraggio e risposta.
La cybersecurity oggi, non è un optional
Investire in cybersecurity oggi non è un fattore accessorio, ma è un valore abilitante per il tuo business.
È la base su cui costruire continuità operativa, innovazione e fiducia digitale. Senza di essa, qualsiasi trasformazione digitale rischia di essere una bomba a orologeria pronta a esplodere.
La serie Amiocuggino vuole proprio colpire con ironia il cuore del problema: ridicolizzare l’approccio superficiale per stimolare una presa di coscienza. Non basta un “cuggino che ci capisce di computer” per difendere un’azienda dalle minacce complesse, servono persone esperte.
Conclusione
Purtroppo la chiave è che la cybersecurity deve divenire una cultura e non un obbligo.
Non può essere trattata come una scocciatura normativa o una casella da spuntare per adeguarsi al GDPR. Deve diventare parte integrante del pensiero strategico di ogni organizzazione. Come la sicurezza sul lavoro o la qualità dei prodotti, anche la sicurezza digitale richiede attenzione quotidiana, aggiornamento continuo e consapevolezza diffusa a tutti i livelli aziendali.
Solo se siamo consapevoli dei rischi, possiamo essere davvero resilienti agli attacchi informatici. Solo comprendendo le dinamiche delle minacce, l’evoluzione degli attacchi e i punti deboli della nostra infrastruttura, possiamo costruire processi difensivi solidi, flessibili e adattabili. La sicurezza non è un obiettivo da raggiungere una volta per tutte: è un percorso e mai una destinazione.
Perché in fondo, se lasci la sicurezza del tuo business in mano ad Amiocuggino… sai già come andrà a finire. Certo, gli attacchi informatici avvengono a tutti. È una realtà con cui ogni organizzazione deve fare i conti. Ma non confondiamo il fatto che “tanto succederà, occorre solo capire quando” con l’atteggiamento pericoloso del “non faccio nulla, tanto fai o non fai è la stessa cosa”.
Questa è una trappola mentale che spinge molte aziende all’inazione, a rimandare, a minimizzare. E proprio lì, in quel vuoto di responsabilità, si insinuano le minacce. La differenza tra un’azienda che subisce un attacco e si rialza in fretta, e una che crolla sotto il peso delle conseguenze, sta nella preparazione, nella formazione e nella cultura.
Investire in cybersecurity non serve ad evitare ogni incidente, ma a limitare l’impatto, a reagire con lucidità, a garantire continuità e fiducia. È una scelta strategica, non un costo. È la base per costruire aziende resilienti, capaci di affrontare l’innovazione digitale senza paura, ma con consapevolezza.
Perché oggi, non è più una questione di “se verrai attaccato”, ma di quanto sarai pronto quando accadrà. E lì, credimi, Amiocuggino non ti salverà.
A bicycle is perhaps one of the most repairable pieces of equipment one can own — no matter what’s wrong with it, and wherever you are on the planet, you’ll be able to find somebody to fix your bike without too much trouble. Unfortunately as electric bikes become more popular, predatory manufacturers are doing everything they can to turn a bike into a closed machine, only serviceable by them.
That’s bad enough, but it’s even worse if the company happens to go under. As an example, [Fransisco] has a bike built by a company that has since gone bankrupt. He doesn’t name them, but it looks like a VanMoof to us. The bike features a light built into the front of the top tube of the frame, which if you can believe it, can only be operated by the company’s (now nonfunctional) cloud-based app.
The hack is relatively straightforward. The panel for the VanMoof electronics is removed and the works underneath are slid up the tube, leaving the connector to the front light. An off the shelf USB-C Li-Po charger and a small cell take the place of the original parts under a new 3D printed panel with a switch to run the light via a suitable resistor. If it wasn’t for the startling green color of the filament he used, you might not even know it wasn’t original.
We would advise anyone who will listen, that hardware which relies on an app and a cloud service should be avoided at all costs. We know most Hackaday readers will be on the same page as us on this one, but perhaps it’s time for a cycling manifesto to match our automotive one.
“Elusive Comet”, un gruppo di hacker motivati finanziariamente, prende di mira gli utenti e i loro wallet di criptovalute con attacchi di ingegneria sociale che sfruttano la funzionalità di controllo remoto di Zoom per indurre gli utenti a concedere loro l’accesso ai propri computer. La funzione di controllo remoto di Zoom permette ai partecipanti di assumere il controllo del computer di un altro partecipante.
“La metodologia ELUSIVE COMET rispecchia le tecniche alla base del recente attacco informatico da 1,5 miliardi di dollari a Bybit a febbraio, in cui gli aggressori hanno manipolato flussi di lavoro legittimi anziché sfruttare le vulnerabilità del codice”, spiega il rapporto Trail of Bits. L’azienda è venuta a conoscenza di questa nuova campagna dopo che gli autori della minaccia hanno tentato di condurre un attacco di ingegneria sociale contro il suo CEO tramite X messaggi diretti.
L’attacco inizia con un invito a un’intervista “Bloomberg Crypto” tramite Zoom, inviato a obiettivi di alto valore tramite account fittizi su X o via e-mail (bloombergconferences[@]gmail.com). Gli account falsi impersonano giornalisti specializzati in criptovalute o testate giornalistiche Bloomberg e raggiungono le vittime tramite messaggi diretti sulle piattaforme dei social media.
Gli inviti vengono inviati tramite link di Calendly per pianificare una riunione su Zoom. Poiché sia gli inviti/link di Calendly che quelli di Zoom sono autentici, funzionano come previsto e riducono i sospetti del destinatario. Durante la chiamata Zoom, l’aggressore avvia una sessione di condivisione dello schermo e invia una richiesta di controllo remoto alla vittima. Il trucco utilizzato in questa fase è che gli aggressori rinominano il loro nome visualizzato su Zoom in “Zoom”, in modo che il messaggio visualizzato dalla vittima reciti “Zoom richiede il controllo remoto del tuo schermo”, facendolo apparire come una richiesta legittima da parte dell’app.
Tuttavia, l’approvazione della richiesta fornisce agli aggressori il pieno controllo remoto sul sistema della vittima, consentendo loro di rubare dati sensibili, installare malware, accedere a file o avviare transazioni crittografiche.
L’aggressore potrebbe agire rapidamente per stabilire un accesso persistente impiantando una backdoor furtiva per sfruttarla in un secondo momento e disconnettersi, lasciando alle vittime poche possibilità di rendersi conto della compromissione.
There was a time when each and every printer and typesetter had its own quirky language. If you had a wordprocessor from a particular company, it worked with the printers from that company, and that was it. That was the situation in the 1970s when some engineers at Xerox Parc — a great place for innovation but a spotty track record for commercialization — realized there should be a better answer.
That answer would be Interpress, a language for controlling Xerox laser printers. Keep in mind that in 1980, a laser printer could run anywhere from $10,000 to $100,000 and was a serious investment. John Warnock and his boss, Chuck Geschke, tried for two years to commercialize Interpress. They failed.
So the two formed a company: Adobe. You’ve heard of them? They started out with the idea of making laser printers, but eventually realized it would be a better idea to sell technology into other people’s laser printers and that’s where we get PostScript.
Early PostScript and the Birth of Desktop Publishing
PostScript is very much like Forth, with words made specifically for page layout and laser printing. There were several key selling points that made the system successful.
First, you could easily obtain the specifications if you wanted to write a printer driver. Apple decided to use it on their LaserWriter. Of course, that meant the printer had a more powerful computer in it than most of the Macs it connected to, but for $7,000 maybe that’s expected.
Second, any printer maker could license PostScript for use in their device. Why spend a lot of money making your own when you could just buy PostScript off the shelf?
Finally, PostScript allowed device independence. If you took a PostScript file and sent it to a 300 DPI laser printer, you got nice output. If you sent it to a 2400 DPI typesetter, you got even nicer output. This was a big draw since a rasterized image was either going to look bad on high-resolution devices or have a huge file system in an era where huge files were painful to deal with. Even a page at 300 DPI is fairly large.
If you bought a Mac and a LaserWriter you only needed one other thing: software. But since the PostScript spec was freely available, software was possible. A company named Aldus came out with PageMaker and invented the category of desktop publishing. Adding fuel to the fire, giant Lionotype came out with a typesetting machine that accepted PostScript, so you could go from a computer screen to proofs to a finished print job with one file.
If you weren’t alive — or too young to pay attention — during this time, you may not realize what a big deal this was. Prior to the desktop publishing revolution, computer output was terrible. You might mock something up in a text file and print it on a daisy wheel printer, but eventually, someone had to make something that was “camera-ready” to make real printing plates. The kind of things you can do in a minute in any word processor today took a ton of skilled labor back in those days.
Take Two
Of course, you have to innovate. Adobe did try to prompt Display PostScript in the late 1980s as a way to drive screens. The NeXT used this system. It was smart, but a bit slow for the hardware of the day. Also, Adobe wanted licensing fees, which had worked well for printers, but there were cheaper alternatives available for displays by the time Display PostScript arrived.
In 1991, Adobe released PostScript Level 2 — making the old PostScript into “Level 1” retroactively. It had all the improvements you would expect in a second version. It was faster and crashed less. It had better support for things like color separation and handling compressed images. It also worked better with oddball and custom fonts, and the printer could cache fonts and graphics.
Remember how releasing the spec helped the original PostScript? For Level 2, releasing it early caused a problem. Competitors started releasing features for Level 2 before Adobe. Oops.
They finally released PostScript 3. (And dropped the “Level”.) This allowed for 12-bit colors instead of 8-bit. It also supported PDF files.
PDF?
While PostScript is a language for controlling a printer, PDF is set up as a page description language. It focuses on what the page looks like and not how to create the page. Of course, this is somewhat semantics. You can think of a PostScript file as a program that drives a Raster Image Processor (RIP) to draw a page. You can think of a PDF as somewhat akin to a compiled version of that program that describes what the program would do.
Up to PDF 1.4, released in 2001, everything you could do in a PDF file could be done in PostScript. But with PDF 1.4 there were some new things that PostScript didn’t have. In particular, PDFs support layers and transparency. Today, PDF rules the roost and PostScript is largely static and fading.
What’s Inside?
Like we said, a PostScript file is a lot like a Forth program. There’s a comment at the front (%!PS-Adobe-3.0) that tells you it is a PostScript file and the level. Then there’s a prolog that defines functions and fonts. The body section uses words like moveto, lineto, and so on to build up a path that can be stroked, filled, or clipped. You can also do loops and conditionals — PostScript is Turing-complete. A trailer appears at the end of each page and usually has a command to render the page (showpage), which may start a new page. A simple PostScript file running in GhostScript A PDF file has a similar structure with a %PDF-1.7 comment. The body contains objects that can refer to pages, dictionaries, references, and image or font streams. There is also a cross-reference table to help find the objects and a trailer that points to the root object. That object brings in other objects to form the entire document. There’s no real code execution in a basic PDF file.
If you want to play with PostScript, there’s a good chance your printer might support it. If not, your printer drivers might. However, you can also grab a copy of GhostScript and write PostScript programs all day. Use GSView to render them on the screen or print them to any printer you can connect to. You can even create PDF files using the tools.
% Draw text "Hackaday" centered in the circle /Times-Roman findfont 12 scalefont setfont % Choose font and size (Hackaday) dup stringwidth pop 2 div % Calculate half text width 150 exch sub % X = center - half width 150 % Y = vertical center moveto (Hackaday) show
showpage
If you want to hack on the code or write your own, here’s the documentation. Think it isn’t really a programming language? [Nicolas] would disagree.
I criminali informatici sono a caccia. Sona a caccia di VPN Ivanti e la prossima potrebbe essere quella installata nella tua organizzazione!
I cybercriminali infatti sono alla ricerca di VPN Ivanti da sfruttare e lo stanno facendo attivando scansioni mirate. Un aumento delle attività di scansione rivolte ai sistemi VPN Ivanti Connect Secure (ICS) e Ivanti Pulse Secure (IPS), sono state rilevate recentemente e questo segnala un potenziale sforzo di ricognizione coordinato da parte degli autori della minaccia.
Questo aumento delle scansioni avvengono dopo la pubblicazione della vulnerabilità critica di buffer overflow basata sullo stack in Ivanti Connect Secure (versioni 22.7R2.5 e precedenti), Pulse Connect Secure 9.x (ora fuori supporto), Ivanti Policy Secure e Neurons per i gateway ZTA. Il bug di sicurezza è monitorato dal National Vulnerability Database con il codice CVE-2025-22457.
Anche l’Agenzia per la Cybersicurezza Nazionale italiana (ACN) aveva pubblicato un bollettino riportato la fase di sfruttamento attivo del bug di sicurezza all’inizio del mese di aprile. Inizialmente sottovalutata, si è poi scoperto che questa falla permetteva invece l’esecuzione di codice remoto (RCE) non autenticato, consentendo agli aggressori di eseguire codice arbitrario su dispositivi vulnerabili. L’11 febbraio 2025 è stata rilasciata una patch per CVE-2025-22457 (versione ICS 22.7R2.6), ma molti dispositivi legacy rimangono senza patch e sono esposti.
I sistemi di monitoraggio di GreyNoise hanno segnalato scansioni massive attraverso i loro tag scanner ICS dedicati, che tracciano gli IP che tentano di identificare sistemi ICS/IPS accessibili tramite Internet .
Il picco, che ha registrato oltre 230 indirizzi IP univoci che hanno sondato gli endpoint ICS/IPS in un solo giorno, rappresenta un aumento di nove volte rispetto alla tipica base di riferimento giornaliera di meno di 30 IP univoci.
I tre principali Paesi di origine delle attività di scansione sono Stati Uniti, Germania e Paesi Bassi, mentre i principali obiettivi sono le organizzazioni in questi Paesi. Negli ultimi 90 giorni sono stati osservati 1.004 IP univoci che hanno eseguito scansioni simili, con le seguenti classificazioni: 634 Sospetto, 244 Malizioso, 126 Benigno.
È importante notare che nessuno di questi IP era falsificabile, il che indica che gli aggressori hanno sfruttato infrastrutture reali e tracciabili. Gli IP dannosi precedentemente osservati in altre attività nefaste provengono principalmente dai nodi di uscita Tor e da noti provider cloud o VPS.
Lo sfruttamento in natura è già stato confermato, con gruppi APT (Advanced Persistent Threat) come UNC5221 che hanno sottoposto la patch a reverse engineering per sviluppare exploit funzionanti. Per mitigare i rischi, le organizzazioni dovrebbero:
Installare immediatamente le patch più recenti su tutti i sistemi ICS/IPS (ICS 22.7R2.6 o successive).
Esaminare i registri per rilevare sospette ricerche e tentativi di accesso da IP nuovi o non attendibili.
Bloccare gli IP sospetti o dannosi identificati da GreyNoise e altri feed di threat intelligence.
Monitorare attività di autenticazione insolite, in particolare da Tor o da IP ospitati sul cloud.
Utilizza lo strumento Integrity Checker (ICT) di Ivanti per identificare i segnali di compromissione.
GreyNoise continua a monitorare questa minaccia in evoluzione e consiglia ai team di sicurezza di restare vigili.
There’s just something about a satisfying “click” that our world of touchscreens misses out on; the only thing that might be better than a good solid “click” when you hit a button is if device could “click” back in confirmation. [Craig Shultz] and his crew of fine researchers at the Interactive Display Lab at the University of Illinois seem to agree, because they have come up with an ingenious hack to provide haptic feedback using readily-available parts. An array of shapes showing some of the different possibilities for hapticoil soft buttons. The “hapticoil”, as they call it, has a simple microspeaker at its heart. We didn’t expect a tiny tweeter to have the oomph to produce haptic feedback, and on its own it doesn’t, as finger pressure stops the vibrations easily. The secret behind the hapticoil is to couple the speaker hydraulically to a silicone membrane. In other words, stick the thing in some water, and let that handle the pressure from a smaller soft button on the silicone membrane. That button can be virtually any shape, as seen here.
Aside from the somewhat sophisticated electronics that allow the speaker coil to be both button and actuator (by measuring inductance changes when pressure is applied, while simultaneously driven as a speaker), there’s nothing here a hacker couldn’t very easily replicate: a microspeaker, a 3D printed enclosure, and a silicone membrane that serves as the face of the haptic “soft button”. That’s not to say we aren’t given enough info replicate the electronics; the researchers are kind enough to provide a circuit diagram in figure eight of their paper.
In the video below, you can see a finger-mounted version used to let a user feel pressing a button in virtual reality, which raises some intriguing possibilities. The technology is also demonstrated on a pen stylus and a remote control.
[Agatha] sent us this stunning multimeter she built as a gift for her mom. Dubbed the Mohmmeter — a playful nod to its ohmmeter function and her mom — this project combines technical ingenuity with heartfelt craftsmanship.
At its core, a Raspberry Pi Pico microcontroller reads the selector knob, controls relays, and lights up LEDs on the front panel to show the meter’s active range. The Mohmmeter offers two main measurement modes, each with two sub-ranges for greater precision across a wide spectrum.
She also included circuitry protections against reverse polarity and over-voltage, ensuring durability. There was also a great deal of effort put into ensuring it was accurate, as the device was put though its paces using a calibrated meter as reference to ensure the final product was as useful as it was beautiful.
The enclosure is a work of art, crafted from colorful wooden panels meticulously jointed together. Stamped brass plates label the meter’s ranges and functions, adding a steampunk flair. This thoughtful design reflects her dedication to creating something truly special.
Want to build a meter for mom, but she’s more of the goth type? The blacked-out Hydameter might be more here style.
In un precedente articolo abbiamo esplorato il calcolo parallelo nel mondo dell’informatica. Ora ci concentreremo su come le più recenti innovazioni tecnologiche nelle architetture hardware per il calcolo ad alte prestazioni costituiscano la base delle moderne rivoluzioni tecnologiche. La diffusione di tecnologie come l’intelligenza artificiale, cybersicurezza e la crittografia avanzata possono risultare disorientante per chi non le conosce. Con questo breve articolo, ci proponiamo di offrire una “lampada di Diogene”, per illuminare un tratto della complessa strada verso la comprensione di queste nuove tecniche, aiutandoci ad affrontarle con spirito critico e consapevole, anziché accettarle passivamente come dei moderni oracoli di Delfi.
Analizzeremo il percorso storico del calcolo parallelo, dalla macchina Colossus di Bletchley Park degli anni ’40 fino all’attuale evoluzione tecnologica. Approfondiremo i meccanismi che hanno guidato questo sviluppo e sveleremo qualche dettaglio dei meccanismi fondamentali del calcolo parallelo.
La storia dei supercomputer inizia con la macchina Colossus, che affrontava enormi problemi con una potenza che ricordava quella di Golia. Oggi, invece, servono strategie più sofisticate. Con l’aumento della complessità e dei limiti fisici, spingere la velocità dei processori (il clock) e seguire la Legge di Moore è diventato sempre più impegnativo. Per questo motivo, il parallelismo si è rivelato una soluzione cruciale per migliorare le prestazioni. I moderni processori sono dotati di più core. Utilizzano tecniche come l’hyperthreading, che consente l’elaborazione contemporanea di più thread su un unico processore, e impiegano unità vettoriali per eseguire più istruzioni simultaneamente. Grazie a questi sviluppi, persino dispositivi come notebook, workstation o smartphone possono competere con le capacità dei supercomputer di vent’anni fa, che occupavano intere stanze.
Proprio come nella celebre sfida tra Davide e Golia, i supercomputer sono progettati per eseguire calcoli e risolvere problemi estremamente complessi – dalle previsioni meteorologiche alle simulazioni per la creazione di nuovi farmaci e modelli per l’esplorazione dell’universo – mentre i personal computer, agili e accessibili, rispondono alle esigenze quotidiane.
La classificaTop 500 di Jack Dongarra, aggiornata due volte all’anno, testimonia questa incessante competizione tecnologica. Tra i protagonisti del 2024, spicca il supercomputer El Capitan, che ha raggiunto la vetta con una capacità di calcolo di 1.742 exaflop.
Sviluppato presso il Lawrence Livermore National Laboratory negli Stati Uniti, questo sistema utilizza processori AMD di quarta generazione e acceleratori MI300A, garantendo prestazioni straordinarie grazie a un’architettura avanzata basata sul Symmetric Multiprocessing (SMP). L’approccio, paragonabile a un’orchestra in cui i processori collaborano armonicamente condividendo la stessa memoria, rappresenta il culmine della potenza del calcolo parallelo..
Cos’è un Supercalcolatore?
Un supercalcolatore è un sistema informatico progettato per garantire prestazioni di calcolo straordinarie, nettamente superiori a quelle dei computer tradizionali. La sua definizione non è cristallizzata nel tempo, ma si evolve costantemente con i progressi tecnologici. Un sistema considerato all’avanguardia nel 2000 potrebbe oggi essere del tutto obsoleto, a causa dei rapidi avanzamenti dell’informatica.
Queste macchine rivestono un ruolo fondamentale nell’affrontare problemi complessi, tra cui simulazioni scientifiche, analisi di enormi volumi di dati e applicazioni avanzate di intelligenza artificiale. Inoltre, sono strumenti chiave anche nel campo della cybersicurezza, dove la capacità di elaborare dati in tempi rapidi può fare la differenza.
Classificare i Supercalcolatori
I supercalcolatori vengono valutati in base a differenti parametri, tra cui il concetto di application-dependent, ossia il tempo necessario per risolvere un problema specifico. Un sistema può eccellere in un compito ma risultare meno efficiente in un altro, a seconda della natura dell’applicazione.
Dal 1993, la lista Top500 classifica i 500 supercalcolatori più potenti al mondo e viene aggiornata due volte l’anno (giugno e novembre). La classifica si basa sul benchmark LINPACK, che misura la capacità di risolvere sistemi di equazioni lineari, impiegando il parametro chiave Rmax (prestazione massima ottenuta).
Nell’edizione di novembre 2024, El Capitan domina al primo posto, essendo il terzo sistema a superare la soglia dell’exascale computing (10^18 FLOPS), seguito da Frontier e Aurora. Il supercomputer europeo Leonardo, ospitato dal Cineca di Bologna, si posiziona al nono posto, con 1,8 milioni di core, un Rmax di 241,20 PFlop/s (milioni di miliardi di operazioni al secondo) e una prestazione teorica di picco di 306,31 PFlop/s.
Viaggio nei Benchmark del Calcolo
Fin dagli albori dell’era informatica, il benchmarking ha rappresentato uno strumento fondamentale per valutare le prestazioni dei computer. Il primo esempio risale al 1946, quando l’ENIAC utilizzò il calcolo di una traiettoria balistica per confrontare l’efficienza tra uomo e macchina, prefigurando un lungo percorso evolutivo nel campo della misurazione computazionale.
Negli anni ‘70, il benchmarking assunse una forma più sistematica. Nel 1972 nacque Whetstone, uno dei primi benchmark sintetici, ideato per misurare le istruzioni per secondo -una metrica chiave per comprendere come una macchina gestisse operazioni di base – e successivamente aggiornato per includere le operazioni in virgola mobile. Nel 1984 arrivò Dhrystone, concepito per valutare le prestazioni nei calcoli interi; questo benchmark fu adottato come standard industriale fino all’introduzione della suite SPECint, che offrì una misurazione più aderente ai carichi di lavoro reali.
Parallelamente, nel 1979, Jack Dongarra introdusse Linpack, un benchmark dedicato alla risoluzione di sistemi di equazioni lineari e divenuto un riferimento nel calcolo scientifico. Questo strumento non solo ispirò lo sviluppo di software come MATLAB, ma pose anche le basi per l’evoluzione dei benchmark destinati ai supercomputer. Con l’evolversi delle esigenze computazionali, Linpack si trasformò nell’HPL (High Performance Linpack), attualmente utilizzato per stilare la prestigiosa classifica Top500, che evidenzia il continuo progresso nella misurazione della potenza di calcolo.
Il panorama dei benchmark si è ulteriormente arricchito con l’introduzione di strumenti come HPC Challenge e i NAS Parallel Benchmarks. L’era del machine learning ha, infine, visto la nascita di benchmark specifici per il training e l’inferenza, capaci di valutare le prestazioni sia di dispositivi a risorse limitate sia di potenti data center. Questi strumenti sono nati in risposta a precise esigenze operative e di mercato, dimostrando come ciascuna innovazione nel campo del benchmarking risponda a uno stadio evolutivo ben definito della tecnologia.
Avendo tracciato in modo cronologico l’evoluzione dei benchmark, appare naturale approfondire anche i modelli teorici che hanno permesso lo sviluppo di tali tecnologie. In questo contesto, la tassonomia di Flynn è essenziale, in quanto ha gettato le basi per l’architettura parallela moderna e continua a guidare la progettazione dei sistemi informatici odierni. Data Center
Tassonomia di Flynn e l’Ascesa del SIMT
Per comprendere meglio il funzionamento di CUDA, è utile considerare la Tassonomia di Flynn, un sistema di classificazione delle architetture dei calcolatori proposto da Flynn nel 1966. Questo schema classifica i sistemi di calcolo in base alla molteplicità dei flussi di istruzioni (instruction stream) e dei flussi di dati (data stream) che possono gestire, risultando in quattro categorie principali:
SISD (Single Instruction, Single Data): Un computer sequenziale in cui l’unità di elaborazione esegue un’unica istruzione su un singolo flusso di dati in ogni ciclo di clock. Questa architettura, molto datata, era tipica dei vecchi sistemi a CPU singola.
SIMD (Single Instruction, Multiple Data): Un tipo di computer parallelo nel quale le unità di elaborazione possono eseguire la stessa istruzione su diversi flussi di dati in ogni ciclo di clock. Architettura impiegata in array di processori e pipeline vettoriali, è utilizzata anche nelle GPU moderne.
MISD (Multiple Instruction, Single Data): Diversi processori eseguono istruzioni differenti sullo stesso dato. Questa configurazione è estremamente rara e principalmente teorica.
MIMD (Multiple Instruction, Multiple Data): Diverse unità di elaborazione eseguono istruzioni differenti su dati distinti. Questa architettura è utilizzata nei supercomputer più avanzati e nei computer multicore moderni.
Le GPU NVIDIA adottano un modello denominato SIMT (Single Instruction, Multiple Thread), nel quale una singola istruzione viene eseguita da numerosi thread in parallelo. Ciascun thread, però, può seguire un percorso leggermente diverso a seconda dei dati e delle condizioni locali. Questo approccio combina l’efficienza del SIMD con la flessibilità del MIMD, risultando estremamente efficace per risolvere problemi complessi in tempi ridotti.
L’evoluzione degli HPC: Ibridismo ed Eterogeneità
Dalle prime architetture MIMD – con memoria condivisa o distribuita – il calcolo ad alte prestazioni (HPC) ha subito una trasformazione profonda. Oggi, i supercomputer non si basano più su un’unica tipologia architetturale, ma su sistemi sempre più complessi e flessibili. Spesso composti da componenti molto diversi tra loro. Questo approccio, detto eterogeneo, permette di unire più paradigmi di elaborazione in un unico sistema, sfruttando al massimo i punti di forza di ciascun componente.
Un esempio evidente è l’uso combinato di CPU e GPU, che rappresentano due filosofie di calcolo diverse ma complementari. Non a caso, le unità grafiche -un tempo riservate esclusivamente al rendering grafico – oggi sono il fulcro dell’HPC e si trovano persino nei laptop di fascia media, rendendo queste tecnologie accessibili a un pubblico molto più ampio. Se la tassonomia di Flynn continua a offrire un utile punto di partenza per classificare i modelli di parallelismo (SISD, SIMD, MISD, MIMD), la realtà attuale va oltre: oggi si parla di sistemi ibridi, dove coesistono differenti stili di parallelismo all’interno dello stesso sistema, e di sistemi eterogenei, in cui unità di calcolo con architetture diverse collaborano sinergicamente.
Questa evoluzione ha aperto nuove frontiere in termini di prestazioni, ma ha anche aumentato la complessità nella valutazione e nel benchmarking dei sistemi, rendendo le misurazioni più difficili e meno lineari.
CUDA
Verso la fine degli anni 2000, NVIDIA ha rivoluzionato il calcolo parallelo introducendo CUDA (Compute Unified Device Architecture). Secondo la letteratura scientifica, CUDA è stata lanciata ufficialmente nel 2006, in concomitanza con l’architettura G80, la prima a supportare pienamente questo modello di programmazione general-purpose su GPU.
CUDA ha reso possibile l’impiego delle GPU per compiti di calcolo generale (GPGPU), superando il loro utilizzo tradizionale nel solo rendering grafico. Grazie al supporto per linguaggi ad alto livello come C, C++ e Fortran, ha semplificato significativamente la programmazione parallela per ricercatori e sviluppatori.
Il paradigma CUDA consente di suddividere problemi complessi in migliaia di task paralleli, eseguiti simultaneamente sulle numerose unità di elaborazione delle GPU. Questo approccio ha avuto un impatto profondo in molteplici ambiti, dalle simulazioni scientifiche all’intelligenza artificiale, fino all’analisi massiva dei dati. L’introduzione della serie G80 ha segnato un punto di svolta, consolidando il modello di calcolo unificato su GPU e aprendo la strada a nuove soluzioni hardware e software.
Il successo di CUDA ha in seguito stimolato la nascita di standard aperti come OpenCL, sviluppato dal Khronos Group e rilasciato nel 2008. OpenCL rappresenta un’alternativa cross-platform e cross-vendor per il calcolo parallelo su hardware eterogeneo, inclusi GPU, CPU e FPGA.
Dal punto di vista architetturale, CUDA si basa sul modello di programmazione SIMT (Single Instruction, Multiple Threads), che consente l’esecuzione di una stessa istruzione su migliaia di thread paralleli, ciascuno con dati e percorsi di esecuzione distinti. Un programma CUDA è composto da due sezioni: una che gira sulla CPU (host) e una che viene eseguita sulla GPU (device). La parte parallelizzabile del codice viene lanciata sulla GPU come kernel, una funzione che viene eseguita da un elevato numero di thread secondo il modello SPMD (Single Program, Multiple Data).
GPU CUDA
Le GPU CUDA sono organizzate in array di Streaming Multiprocessors (SM), unità operative che integrano CUDA Core, una memoria condivisa veloce e uno scheduler per gestire e distribuire i task. Questi SM permettono di ottenere elevate prestazioni nel calcolo parallelo, grazie anche a una memoria globale ad alta velocità (GDDR) con ampia banda passante.
CUDA C/C++, estensione dei linguaggi C e C++ realizzata da NVIDIA, consente agli sviluppatori di accedere direttamente alle risorse parallele delle GPU, abbattendo le barriere che tradizionalmente ostacolavano l’adozione della programmazione parallela. Questo ha favorito la crescita delle applicazioni GPGPU ad alte prestazioni in ambito scientifico, industriale e accademico.
In sintesi, CUDA ha segnato un vero cambio di paradigma nel calcolo parallelo, rendendo accessibile a un pubblico più ampio la possibilità di sfruttare la potenza delle GPU per applicazioni general-purpose e aprendo la strada a innovazioni nei settori più avanzati dell’informatica.
Da GPU a GPGPU: Il Potere del Calcolo Parallelo
L’evoluzione delle GPU ha portato alla nascita delle GPGPU (General-Purpose GPU), trasformandole da unità dedicate al rendering grafico in acceleratori di calcolo parallelo complementari alle CPU.
Grazie alla loro architettura con molti core semplici, le GPGPU eccellono nell’elaborazione simultanea di grandi volumi di dati, offrendo vantaggi significativi:
Scalabilità: Permettono l’integrazione di un numero elevato di core.
Efficienza: Bilanciano il carico di lavoro tra i core in maniera uniforme.
Velocità: Accelerano i calcoli ripetitivi e paralleli.
A differenza delle CPU, ottimizzate per gestire compiti complessi con pochi core potenti e una cache veloce, le GPGPU brillano in operazioni ripetitive. La loro struttura, paragonabile a una squadra di numerosi operai che lavorano simultaneamente su un mosaico di dati, consente di completare attività in tempi significativamente ridotti. Tuttavia, le GPGPU non sostituiscono le CPU, ma le supportano, gestendo compiti paralleli e migliorando l’efficienza complessiva in campi come l’intelligenza artificiale e l’analisi dei dati.
Streaming Multiprocessors: La Fucina del Parallelismo
Gli Streaming Multiprocessors (SM) rappresentano le unità operative fondamentali all’interno di un acceleratore grafico. Ogni SM include i CUDA Core, una sezione di memoria condivisa e uno scheduler dedicato, incaricato di organizzare e distribuire il lavoro tra i core.
A differenza delle CPU, che adottano un’architettura MIMD per gestire compiti eterogenei, le GPU sfruttano gli SM per eseguire in parallelo operazioni ripetitive su grandi insiemi di dati, facendo affidamento su una memoria globale ad alta velocità. Questa organizzazione consente di ottenere un’elevata efficacia computazionale nelle applicazioni di calcolo parallelo, come evidenziato da studi pubblicati su riviste scientifiche certificate, tra cui IEEE e ACM.
Breve Storia dell’Evoluzione della GPU
Dai controller VGA ai processori grafici programmabili
All’inizio dell’era informatica, il concetto stesso di GPU non esisteva. La grafica sui PC era gestita da un semplice controller VGA (Video Graphics Array), un gestore di memoria e generatore di segnale video collegato a una memoria DRAM.
Negli anni ’90, grazie ai progressi nella tecnologia dei semiconduttori, questi controller iniziarono a integrare capacità di accelerazione grafica tridimensionale: hardware dedicato per la preparazione dei triangoli, la rasterizzazione (scomposizione dei triangoli in pixel), il mapping delle texture e lo shading, ovvero l’applicazione di pattern o sfumature di colore.
Con l’inizio degli anni 2000, il processore grafico divenne un chip singolo capace di gestire ogni fase della pipeline grafica, una prerogativa fino ad allora esclusiva delle workstation di fascia alta. A quel punto il dispositivo assunse il nome di GPU, per sottolineare la sua natura di vero e proprio processore specializzato.
Nel tempo, le GPU si sono evolute in acceleratori programmabili massivamente paralleli, dotati di centinaia di core e migliaia di thread, capaci di elaborare non solo grafica ma anche compiti computazionali generici (GPGPU). Sono state inoltre introdotte istruzioni specifiche e hardware dedicato alla gestione della memoria, insieme a strumenti di sviluppo che permettono di programmare queste unità con linguaggi come C e C++, rendendo le GPU veri e propri processori multicore altamente parallelizzati.
In sintesi, l’evoluzione dal Colossus fino alle moderne unità grafiche e architetture ibride racconta un percorso tecnologico dinamico e in continua trasformazione. Queste innovazioni non solo hanno rivoluzionato il modo di elaborare dati, ma stanno anche ridefinendo le possibilità in settori strategici come l’intelligenza artificiale e la cybersicurezza e la crittografia.
Guardando al futuro, è evidente che l’integrazione di paradigmi eterogenei continuerà a guidare lo sviluppo di sistemi sempre più potenti ed efficienti, ponendo sfide avvincenti per ricercatori, ingegneri e sviluppatori di tutto il mondo.
We have been tracking the latest attack campaign by the Lazarus group since last November, as it targeted organizations in South Korea with a sophisticated combination of a watering hole strategy and vulnerability exploitation within South Korean software. The campaign, dubbed “Operation SyncHole”, has impacted at least six organizations in South Korea’s software, IT, financial, semiconductor manufacturing, and telecommunications industries, and we are confident that many more companies have actually been compromised. We immediately took action by communicating meaningful information to the Korea Internet & Security Agency (KrCERT/CC) for rapid action upon detection, and we have now confirmed that the software exploited in this campaign has all been updated to patched versions.
Timeline of the operation
Our findings in a nutshell:
At least six South Korean organizations were compromised by a watering hole attack combined with exploitation of vulnerabilities by the Lazarus group.
A one-day vulnerability in Innorix Agent was also used for lateral movement.
Variants of Lazarus’ malicious tools, such as ThreatNeedle, Agamemnon downloader, wAgent, SIGNBT, and COPPERHEDGE, were discovered with new features.
Background
The initial infection was discovered in November of last year when we detected a variant of the ThreatNeedle backdoor, one of the Lazarus group’s flagship malicious tools, used against a South Korean software company. We found that the malware was running in the memory of a legitimate SyncHost.exe process, and was created as a subprocess of Cross EX, legitimate software developed in South Korea. This potentially was the starting point for the compromise of further five organizations in South Korea. Additionally, according to a recent security advisory posted on the KrCERT website, there appear to be recently patched vulnerabilities in Cross EX, which were addressed during the timeframe of our research.
In the South Korean internet environment, the online banking and government websites require the installation of particular security software to support functions such as anti-keylogging and certificate-based digital signatures. However, due to the nature of these software packages, they constantly run in the background to interact with the browser. The Lazarus group shows a strong grasp of these specifics and is using a South Korea-targeted strategy that combines vulnerabilities in such software with watering hole attacks. The South Korean National Cyber Security Center published its own security advisory in 2023 against such incidents, and also published additional joint security advisories in cooperation with the UK government.
Cross EX is designed to enable the use of such security software in various browser environments, and is executed with user-level privileges except immediately after installation. Although the exact method by which Cross EX was exploited to deliver malware remains unclear, we believe that the attackers escalated their privileges during the exploitation process as we confirmed the process was executed with high integrity level in most cases. The facts below led us to conclude that a vulnerability in the Cross EX software was most likely leveraged in this operation.
The most recent version of Cross EX at the time of the incidents was installed on the infected PCs.
Execution chains originating from the Cross EX process that we observed across the targeted organizations were all identical.
The incidents that saw the Synchost process abused to inject malware were concentrated within a short period of time: between November 2024 and February 2025.
In the earliest attack of this operation, the Lazarus group also exploited another South Korean software product, Innorix Agent, leveraging a vulnerability to facilitate lateral movement, enabling the installation of additional malware on a targeted host of their choice. They even developed malware to exploit this, avoiding repetitive tasks and streamlining processes. The exploited software, Innorix Agent (version 9.2.18.450 and earlier), was previously abused by the Andariel group, while the malware we obtained targeted the more recent version 9.2.18.496.
While analyzing the malware’s behavior, we discovered an additional arbitrary file download zero-day vulnerability in Innorix Agent, which we managed to detect before any threat actors used it in their attacks. We reported the issues to the Korea Internet & Security Agency (KrCERT) and the vendor. The software has since been updated with patched versions.
Installing malware through vulnerabilities in software exclusively developed in South Korea is a key part of the Lazarus group’s strategy to target South Korean entities, and we previously disclosed a similar case in 2023, as did ESET and KrCERT.
Initial vector
The infection began when the user of a targeted system accessed several South Korean online media sites. Shortly after visiting one particular site, the machine was compromised by the ThreatNeedle malware, suggesting that the site played a key role in the initial delivery of the backdoor. During the analysis, it was discovered that the infected system was communicating with a suspicious IP address. Further examination revealed that this IP hosted two domains (T1583.001), both of which appeared to be hastily created car rental websites using publicly available HTML templates.
Appearance of www.smartmanagerex[.]com
The first domain, www.smartmanagerex[.]com, seemed to be masquerading as software provided by the same vendor that distributes Cross EX. Based on these findings, we reconstructed the following attack scenario. Attack flow during initial compromise
Given that online media sites are typically visited quite frequently by a wealth of users, the Lazarus group filters visitors with a server-side script and redirects desired targets to an attacker-controlled website (T1608.004). We assess with medium confidence that the redirected site may have executed a malicious script (T1189), targeting a potential flaw in Cross EX (T1190) installed on the target PC, and launching malware. The script then ultimately executed the legitimate SyncHost.exe and injected a shellcode that loaded a variant of ThreatNeedle into that process. This chain, which ends with the malware being injected into SyncHost.exe, was common to all of the affected organizations we identified, meaning that the Lazarus group has conducted extensive operations against South Korea over the past few months with the same vulnerability and the same exploit.
Execution flow
We have divided this operation into two phases based on the malware used. The first phase focused primarily on the execution chain involving ThreatNeedle and wAgent. It was then followed by the second phase which involved the use of SIGNBT and COPPERHEDGE.
We derived a total of four different malware execution chains based on these phases from at least six affected organizations. In the first infection case, we found a variant of the ThreatNeedle malware, but in subsequent attacks, the SIGNBT malware took its place, thus launching the second phase. We believe this is due to the quick and aggressive action we took with the first victim. In subsequent attacks, the Lazarus group introduced three updated infection chains including SIGNBT, and we observed a wider range of targets and more frequent attacks. This suggests that the group may have realized that their carefully prepared attacks had been exposed, and extensively leveraged the vulnerability from then on.
Chains of infection across the operation
First-phase malware
In the first infection chain, many updated versions of the malware previously used by the Lazarus group were used.
Variant of ThreatNeedle
The ThreatNeedle sample used in this campaign was also referred to as “ThreatNeedleTea” in a research paper published by ESET; we believe this is an updated version of the early ThreatNeedle. However, the ThreatNeedle seen in this attack had been modified with additional features.
This version of ThreatNeedle is divided into a Loader and Core samples. The Core version retrieves five configuration files from C_27098.NLS to C_27102.NLS, and contains a total of 37 commands. The Loader version, meanwhile, references only two configuration files and implements only four commands.
The Core component receives a specific command from the C2, resulting in an additional loader file being created for the purpose of persistence. This file can be disguised as the ServiceDLL value of a legitimate service in the netsvcs group (T1543.003), the IKEEXT service (T1574.001), or registered as a Security Service Provider (SSP) (T1547.005). It ultimately loads the ThreatNeedle Loader component.
Behavior flow to load ThreatNeedle Loader by target service
The updated ThreatNeedle generates a random key pair based on the Curve25519 algorithm (T1573.002), sends the public key to the C2 server, and then receives the attacker’s public key. Finally, the generated private key and the attacker’s public key are scalar-operated to create a shared key, which is then used as the key for the ChaCha20 algorithm to encrypt the data (T1573.001). The data is sent and received in JSON format.
LPEClient
LPEClient is a tool known for victim profiling and payload delivery (T1105) that has previously been observed in attacks on defense contractors and the cryptocurrency industry. We disclosed that this tool had been loaded by SIGNBT when we first documented SIGNBT malware. However, we did not observe LPEClient being loaded by SIGNBT in this campaign. It was only loaded by the variant of ThreatNeedle.
Variant of wAgent
In addition to the variant of ThreatNeedle, a variant of the wAgent malware was also discovered in the first affected organization. wAgent is a malicious tool that we documented in 2020, and a similar version was mentioned in Operation GoldGoblin by KrCERT. The origin of its creation is still shrouded in mystery, but we discovered that the wAgent loader was disguised as liblzma.dll and executed via the command line rundll32.exec:\Programdata\intel\util.dat,afunix1W2-UUE-ZNO-B99Z (T1218.011). The export function retrieves the given filename 1W2-UUE-ZNO-B99Z in C:\ProgramData, which also serves as the decryption key. After converting this filename into wide bytes, it uses the highest 16 bytes of the resulting value as the key for the AES-128-CBC algorithm and decrypts (T1140) the contents of the file located in C:\ProgramData (T1027.013). The upper four bytes of the decrypted data subsequently represent the size of the payload (T1027.009), which we identified as an updated version of the wAgent malware.
The variant of wAgent has the ability to receive data in both form-data and JSON formats, depending on the C2 server it succeeds in reaching. Notably, it includes the __Host-next-auth-token key within the Cookie field in the request header during the communication (T1071.001), carrying the sequence of communication appended by random digits. In this version, the new observed change is that an open-source GNU Multiple-Precision (GMP) library is employed to carry out RSA encryption computations, which is a previously unseen library in malware used by the Lazarus group. According to the wAgent configuration file, it is identified as the x64_2.1 version. This version manages payloads using a C++ STL map, with emphasis on receiving additional payloads from the C2 and loading them directly into memory, along with creating a shared object. With this object, the main module is able to exchange command parameters and execution results with the delivered plugins.
Operational structure of the wAgent variant
Variant of the Agamemnon downloader
The Agamemnon downloader is also responsible for downloading and executing additional payloads received from the C2 server. Although we did not obtain the configuration file of Agamemnon, it receives commands from the C2 and executes the payload by parsing the commands and parameters based on ;; characters, which serve as command and parameter delimiters. The value of the mode in response passed with a 2 command determines how to execute the additional payload, which is delivered along with a 3 command. There are two methods of execution: the first one is to load the payload reflectively (T1620), which is commonly used in malware, whereas the second one is to utilize the open-source Tartarus-TpAllocInject technique, which we have not previously seen in malware from the Lazarus group.
Structure of the commands where additional data is passed
The open-source loader is built on top of another open-source loader named Tartarus’ Gate. Tartarus’ Gate is based on Halo’s Gate, which is in turn based on Hell’s Gate. All of these techniques are designed to bypass security products such as antivirus and EDR solutions, but they load the payload in different ways.
Innorix Agent exploit for lateral movement
Unlike the previously mentioned tools, the Innorix abuser is used for lateral movement. It is downloaded by the Agamemnon downloader (T1105) and exploits a specific version of a file transfer software tool developed in South Korea, Innorix Agent, to fetch additional malware on internal hosts (T1570). Innorix Agent is another software product that is mandatory for some financial and administrative tasks in the South Korean internet environment, meaning that it is likely to be installed on many PCs of both corporations and individuals in South Korea, and any user with a vulnerable version is potentially a target. The malware embeds a license key allegedly bound to version 9.2.18.496, which allows it to perform lateral movement by generating malicious traffic disguised as legitimate traffic against targeted network PCs.
The Innorix abuser is given parameters from the Agamemnon downloader: the target IP, URL to download a file, and file size. It then delivers a request to that target IP to check if Innorix Agent is installed and running. If a successful response is returned, the malware assumes that the software is running properly on the targeted host and transmits traffic that allows the target to download the additional files from the given URL due to a lack of traffic validation.
Steps to deploy additional malware via the Innorix abuser
The actor created a legitimate AppVShNotify.exe and a malicious USERENV.dll file in the same path via the Innorix abuser, and then executed the former using a legitimate feature of the software. The USERENV.dll was sideloaded (T1574.002) as a result, which ultimately led to the execution of ThreatNeedle and LPEClient on the targeted hosts, thus launching the infection chain on previously unaffected machines.
We reported this vulnerability to KrCERT due to the potentially dangerous impact of the Innorix abuser, but were informed that the vulnerability has been exploited and reported in the past. We have confirmed that this malware does not work effectively in environments with Innorix Agent versions other than 9.2.18.496.
In addition, while digging into the malware’s behavior, we identified another additional arbitrary file download vulnerability that applies to versions up to 9.2.18.538. It is tracked as KVE-2025-0014 and we have not yet found any evidence of its use in the wild. KVE is a vulnerability identification number issued exclusively by KrCERT. We successfully contacted Innorix to share our findings containing the vulnerabilities via KrCERT, and they managed to release a patched version in March with both vulnerabilities fixed.
Second phase malware
The second phase of the operation also introduces newer versions of malicious tools previously seen in Lazarus attacks.
SIGNBT
The SIGNBT we documented in 2023 was version 1.0, but in this attack, version 0.0.1 was used at the forefront. In addition, we identified a more recent version, SIGNBT 1.2. Unlike versions 1.0 and 0.0.1, the 1.2 version had minimal remote control capabilities and was focused on executing additional payloads. The malware developers named this version “Hijacking”.
In the second phase of this operation, SIGNBT 0.0.1 was the initial implant executed in memory in SyncHost.exe to fetch additional malware. In this version, the C2 server was hardcoded without reference to any configuration files. During this investigation, we found a credential dumping tool that was fetched by SIGNBT 0.0.1, identical to what we have seen in previous attacks.
As for version 1.2, it fetches the path to the configuration file from its resources and retrieves the file to obtain C2 server addresses. We were able to extract two configuration file paths from each identified SIGNBT 1.2 sample, which are shown below. Another change in SIGNBT 1.2 is that the number of prefixes starting with SIGN are reduced to only three: SIGNBTLG, SIGNBTRC, and SIGNBTSR. The malware receives an RSA public key from the C2 and encrypts a randomly generated AES key using the public key. All traffic is encrypted with the generated AES key.
{ proxylist: [{ // C2 server list proxy: "https%0x3A//builsf[.]com/inc/left.php" }, { proxy: "https%0x3A//www.rsdf[.]kr/wp-content/uploads/2024/01/index.php" }, { proxy: "http%0x3A//www.shcpump[.]com/admin/form/skin/formBasic/style.php" }, { proxy: "https%0x3A//htns[.]com/eng/skin/member/basic/skin.php" }, { proxy: "https%0x3A//kadsm[.]org/skin/board/basic/write_comment_skin.php" }, { proxy: "http%0x3A//bluekostec[.]com/eng/community/write.asp" }, { proxy: "http%0x3A//dream.bluit.gethompy[.]com/mobile/skin/board/gallery/index.skin.php" }], wake: 1739839071, // Timestamp of Tuesday, February 18, 2025 12:37:51 AM status: 1 // It means the scheduled execution time is set. }
COPPERHEDGE
COPPERHEDGE is a malicious tool that was named by US-CERT in 2020. It is a Manuscrypt variant and was primarily used in the DeathNote cluster attacks. Unlike the other malware used in this operation, COPPERHEDGE has not changed dramatically, with only several commands being slightly changed compared to the older versions. This version, however, retrieves configuration information such as the C2 server address from the ADS %appdata%\Microsoft\Internet Explorer\brndlog.txt:loginfo (T1564.004). The malware then sends HTTP traffic to C2 with three or four parameters for each request, where the parameter name is chosen randomly out of three names in any order.
First HTTP parameter name: bih, aqs, org
Second HTTP parameter name: wib, rlz, uid
Third HTTP parameter name: tib, hash, lang
Fourth HTTP parameter name: ei, ie, oq
The actor primarily used the COPPERHEDGE malware to conduct internal reconnaissance in this operation. There are a total of 30 commands from 0x2003 to 0x2032, and 11 response codes from 0x2040 to 0x2050 inside the COPPERHEDGE backdoor.
The evolution of Lazarus malware
In recent years, the malware used by the Lazarus group has been rapidly evolving to include lightweighting and modularization. This applies not only to newly added tools, but also to malware that has been used in the past. We have observed such changes for a few years, and we believe there are more on the way.
During our investigation into this campaign, we gained extensive insight into the Lazarus group’s post-exploitation strategy. After installing the COPPERHEDGE malware, the actor executed numerous Windows commands to gather basic system information (T1082, T1083, T1057, T1049, T1016, T1087.001), create a malicious service (T1569.002, T1007) and attempt to find valuable hosts to perform lateral movement (T1087.002, T1135).
While analyzing the commands executed by the actor, we were able to identify the actor’s mistake when using the taskkill command: the /im parameter when using taskkill means imagename, which should specify the image name of the process, not the process id. This shows that the actor is still performing internal reconnaissance by manually entering commands.
Infrastructure
Throughout this operation, most of the C2 servers were legitimate but compromised websites in South Korea (T1584.001), further indicating that this operation was highly focused on South Korea. In the first phase, other media sites were utilized as C2 servers to avoid detection of media-initiated watering hole attacks. However, as the infection chain turned to the second phase, legitimate sites in various other industries were additionally exploited.
Unlike other cases, LPEClient’s C2 server was hosted by the same hosting company as www.smartmanagerex[.]com, which was deliberately created for initial compromise. Given that LPEClient is heavily relied upon by the Lazarus group for delivering additional payloads, it is likely that the attackers deliberately rented and configured the server (T1583.003), assigning a domain under their control to maintain full operational flexibility. In addition to this, we also found that two domains that were exploited as C2 servers for SIGNBT 0.0.1 resolved to the same hosting company’s IP range.
We confirmed that the domain thek-portal[.]com belonged to a South Korean ISP until 2020 and was the legitimate domain of an insurance company that was acquired by another company. Since then, the domain had been parked and its status was changed in February 2025, indicating that the Lazarus group re-registered the domain to leverage it in this operation.
Attribution
Throughout this campaign, several malware samples were used that we managed to attribute to the Lazarus group through our ongoing and dedicated research conducted for a long time. Our attribution is supported by the historical use of the malware strains, as well as their TTPs, all of which have been well documented by numerous security solutions vendors and governments. Furthermore, we have analyzed the execution time of the Windows commands delivered by the COPPERHEDGE malware, the build timestamps of all malicious samples we described above, and the time of initial compromise per host, demonstrating that the timeframes were mostly concentrated between GMT 00:00 and 09:00. Based on our knowledge of normal working hours in various time zones, we can infer that the actor is located in the GMT+09 time zone.
Timeline of malicious activity
Victims
We identified at least six software, IT, financial, semiconductor manufacturing and telecommunication organizations in South Korea that fell victim to “Operation SyncHole”. However, we are confident that there are many more affected organizations across a broader range of industries, given the popularity of the software exploited by Lazarus in this campaign.
Conclusion
This is not the first time that the Lazarus group exploited supply chains with a full understanding of the software ecosystem in South Korea. We have already described similar attacks in our analysis reports on the Bookcode cluster in 2020, the DeathNote cluster in 2022, and the SIGNBT malware in 2023. All of these cases targeted software developed by South Korean vendors that required installation for online banking and government services. Both of the software products exploited in this case are in line with past cases, meaning that the Lazarus group is endlessly adopting an effective strategy based on cascading supply chain attacks.
The Lazarus group’s specialized attacks targeting supply chains in South Korea are expected to continue in the future. Our research over the past few years provided evidence that many software development vendors in Korea have already been attacked, and if the source code of a product has been compromised, other zero-day vulnerabilities may continue to be discovered. The attackers are also making efforts to minimize detection by developing new malware or enhancing existing malware. In particular, they introduce enhancements to the communication with the C2, command structure, and the way they send and receive data.
We have proven that accurate detection and quick response can effectively deter their tactics, and in the meantime, we were able to remediate vulnerabilities and mitigate attacks to minimize damage. We will continue to monitor the activity of this group and remain agile in responding to their changes. We also recommend using reliable security solutions to stay alert and mitigate potential risks. Our product line for businesses helps identify and prevent attacks of any complexity at an early stage.
Kaspersky products detect the exploits and malware used in this attack with the following verdicts: Trojan.Win64.Lazarus.*, Trojan.Win32.Lazarus.*, MEM:Trojan.Win32.Cometer.gen, MEM:Trojan.Win32.SEPEH.gen, Trojan.Win32.Manuscrypt.*, Trojan.Win64.Manuscrypt.*, Trojan.Win32.Zenpak.*.
[Michal Sapka] wanted to learn a new skill, so he decided on the Commodore 64 assembly language. We didn’t say he wanted to learn a new skill that might land him a job. But we get it and even applaud it. Especially since he’s written a multi-part post about what he’s doing and how you can do it, too. So far, there are four parts, and we’d bet there are more to come.
The series starts with the obligatory “hello world,” as well as some basic setup steps. By part 2, you are learning about registers and numbers. Part 3 covers some instructions, and by part 4, he finds that there are even more registers to contend with.
One of the great things about doing a project like this today is that you don’t have to have real hardware. Even if you want to eventually run on real hardware, you can edit in comfort, compile on a fast machine, and then debug and test on an emulator. [Michal] uses VICE.
The series is far from complete, and we hear part 5 will talk about branching, so this is a good time to catch up.
Strenghtening FDM prints has been discussed in detail over the last years. Solutions and results vary as each one’s desires differ. Now [TenTech] shares his latest improvements on his post-processing script that he first created around January. This script literally bends your G-code to its will – using non-planar, interlocking sine wave deformations in both infill and walls. It’s now open-source, and plugs right into your slicer of choice: PrusaSlicer, OrcaSlicer, or Bambu Studio. If you’re into pushing your print strength past the limits of layer adhesion, but his former solution wasn’t quite the fit for your printer, try this improvement.
Traditional Fused Deposition Modeling (FDM) prints break along layer lines. What makes this script exciting is that it lets you introduce alternating sine wave paths between wall loops, removing clean break points and encouraging interlayer grip. Think of it as organic layer interlocking – without switching to resin or fiber reinforcement. You can tweak amplitude, frequency, and direction per feature. In fact, the deformation even fades between solid layers, allowing smoother transitions. Structural tinkering at its finest, not just a cosmetic gimmick.
This thing comes without needing a custom slicer. No firmware mods. Just Python, a little G-code, and a lot of curious minds. [TenTech] is still looking for real-world strength tests, so if you’ve got a test rig and some engineering curiosity, this is your call to arms.
These days you can run Doom anywhere on just about anything, with things like porting Doom to JavaScript these days about as interesting as writing Snake in BASIC on one’s graphical calculator. In a twist, [Patrick Trainer] had the idea to use SQL instead of JS to do the heavy lifting of the Doom game loop. Backed by the Web ASM version of the analytical DuckDB database software, a Doom-lite clone was coded that demonstrates the principle that anything in life can be captured in a spreadsheet or database application.
Rather than having the game world state implemented in JavaScript objects, or pixels drawn to a Canvas/WebGL surface, this implementation models the entire world state in the database. To render the player’s view, the SQL VIEW feature is used to perform raytracing (in SQL, of course). Any events are defined as SQL statements, including movement. Bullets hitting a wall or impacting an enemy result in the bullet and possibly the enemy getting DELETE-ed.
The role of JavaScript in this Doom clone is reduced to gluing the chunks of SQL together and handling sprite Z-buffer checks as well as keyboard input. The result is a glorious ASCII-based game of Doom which you can experience yourself with the DuckDB-Doom project on GitHub. While not very practical, it was absolutely educational, showing that not only is it fun to make domain specific languages do things they were never designed for, but you also get to learn a lot about it along the way.
When was the last time you saw a computer actually outlast your weekend trip – and then some? Enter the Evertop, a portable IBM XT emulator powered by an ESP32 that doesn’t just flirt with low power; it basically lives off the grid. Designed by [ericjenott], hacker with a love for old-school computing and survivalist flair, this machine emulates 1980s PCs, runs DOS, Windows 3.0, and even MINIX, and stays powered for hundreds of hours. It has a built-in solar panel and 20,000mAh of battery, basically making it an old-school dream in a new-school shell.
What makes this build truly outstanding – besides the specs – is how it survives with no access to external power. It sports a 5.83-inch e-ink display that consumes zilch when static, hardware switches to cut off unused peripherals (because why waste power on a serial port you’re not using?), and a solar panel that pulls 700mA in full sun. And you guessed it – yes, it can hibernate to disk and resume where you left off. The Evertop is a tribute to 1980s computing, and a serious tool to gain some traction at remote hacker camps.
For the full breakdown, the original post has everything from firmware details to hibernation circuitry. Whether you’re a retro purist or an off-grid prepper, the Evertop deserves a place on your bench. Check out [ericjenott]’s project on Github here.
This week, Jonathan Bennett and Randal Schwartz chat with Allen Firstenberg about Google’s AI plans, Vibe Coding, and Open AI! What’s the deal with agentic AI, how close are we to Star Trek, and where does Open Source fit in? Watch to find out!
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 contact the guest and have them contact us! Take a look at the schedule here.
Drumboy and Synthgirl from Randomwaves are a a pair of compact electronic instruments, a drum machine and a synthesiser. They are commercial products which were launched on Kickstarter, and if you’re in the market for such a thing you can buy one for yourself. What’s made them of interest to us here at Hackaday though is not their musical capabilities though, instead it’s that they’ve honoured their commitment to release them as open source in the entirety.
So for your download, you get everything you need to build a pair of rather good 24-bit synthesisers based upon the STM32 family of microcontrollers. We’re guessing that few of you will build your own when it’s an easier job to just buy one from Randomwaves, and we’re guessing that this open-sourcing will lead to interesting new features and extensions from the community of owners.
It will be interesting to watch how this progresses, because of course with the files out there, now anyone can produce and market a clone. Will AliExpress now be full of knock-off Drumboys and Synthgirls? It’s a problem we’ve looked at in the past with respect to closed-source projects, and doubtless there will be enterprising electronics shops eyeing this one up. By our observation though it seems to be those projects with cheaper bills of materials which suffer the most from clones, so perhaps that higher-end choice of parts will work in their favour.
Either way we look forward to more open-source from Randomwaves in the future, and if you’d like to buy either instrument you can go to their website.
It’s amazing how quickly medical science made radiography one of its main diagnostic tools. Medicine had barely emerged from its Dark Age of bloodletting and the four humours when X-rays were discovered, and the realization that the internal structure of our bodies could cast shadows of this mysterious “X-Light” opened up diagnostic possibilities that went far beyond the educated guesswork and exploratory surgery doctors had relied on for centuries.
The problem is, X-rays are one of those things that you can’t see, feel, or smell, at least mostly; X-rays cause visible artifacts in some people’s eyes, and the pencil-thin beam of a CT scanner can create a distinct smell of ozone when it passes through the nasal cavity — ask me how I know. But to be diagnostically useful, the varying intensities created by X-rays passing through living tissue need to be translated into an image. We’ve already looked at how X-rays are produced, so now it’s time to take a look at how X-rays are detected and turned into medical miracles.
Taking Pictures
For over a century, photographic film was the dominant way to detect medical X-rays. In fact, years before Wilhelm Conrad Röntgen’s first systematic study of X-rays in 1895, fogged photographic plates during experiments with a Crooke’s tube were among the first indications of their existence. But it wasn’t until Röntgen convinced his wife to hold her hand between one of his tubes and a photographic plate to create the first intentional medical X-ray that the full potential of radiography could be realized. “Hand mit Ringen” by W. Röntgen, December 1895. Public domain. The chemical mechanism that makes photographic film sensitive to X-rays is essentially the same as the process that makes light photography possible. X-ray film is made by depositing a thin layer of photographic emulsion on a transparent substrate, originally celluloid but later polyester. The emulsion is a mixture of high-grade gelatin, a natural polymer derived from animal connective tissue, and silver halide crystals. Incident X-ray photons ionize the halogens, creating an excess of electrons within the crystals to reduce the silver halide to atomic silver. This creates a latent image on the film that is developed by chemically converting sensitized silver halide crystals to metallic silver grains and removing all the unsensitized crystals.
Other than in the earliest days of medical radiography, direct X-ray imaging onto photographic emulsions was rare. While photographic emulsions can be exposed by X-rays, it takes a lot of energy to get a good image with proper contrast, especially on soft tissues. This became a problem as more was learned about the dangers of exposure to ionizing radiation, leading to the development of screen-film radiography.
In screen-film radiography, X-rays passing through the patient’s tissues are converted to light by one or more intensifying screens. These screens are made from plastic sheets coated with a phosphorescent material that glows when exposed to X-rays. Calcium tungstate was common back in the day, but rare earth phosphors like gadolinium oxysulfate became more popular over time. Intensifying screens were attached to the front and back covers of light-proof cassettes, with double-emulsion film sandwiched between them; when exposed to X-rays, the screens would glow briefly and expose the film.
By turning one incident X-ray photon into thousands or millions of visible light photons, intensifying screens greatly reduce the dose of radiation needed to create diagnostically useful images. That’s not without its costs, though, as the phosphors tend to spread out each X-ray photon across a physically larger area. This results in a loss of resolution in the image, which in most cases is an acceptable trade-off. When more resolution is needed, single-screen cassettes can be used with one-sided emulsion films, at the cost of increasing the X-ray dose.
Wiggle Those Toes
Intensifying screens aren’t the only place where phosphors are used to detect X-rays. Early on in the history of radiography, doctors realized that while static images were useful, continuous images of body structures in action would be a fantastic diagnostic tool. Originally, fluoroscopy was performed directly, with the radiologist viewing images created by X-rays passing through the patient onto a phosphor-covered glass screen. This required an X-ray tube engineered to operate with a higher duty cycle than radiographic tubes and had the dual disadvantages of much higher doses for the patient and the need for the doctor to be directly in the line of fire of the X-rays. Cataracts were enough of an occupational hazard for radiologists that safety glasses using leaded glass lenses were a common accessory. How not to test your portable fluoroscope. The X-ray tube is located in the upper housing, while the image intensifier and camera are below. The machine is generally referred to as a “C-arm” and is used in the surgery suite and for bedside pacemaker placements. Source: Nightryder84, CC BY-SA 3.0. One ill-advised spin-off of medical fluoroscopy was the shoe-fitting fluoroscopes that started popping up in shoe stores in the 1920s. Customers would stick their feet inside the machine and peer at a fluorescent screen to see how well their new shoes fit. It was probably not terribly dangerous for the once-a-year shoe shopper, but pity the shoe salesman who had to peer directly into a poorly regulated X-ray beam eight hours a day to show every Little Johnny’s mother how well his new Buster Browns fit.
As technology improved, image intensifiers replaced direct screens in fluoroscopy suites. Image intensifiers were vacuum tubes with a large input window coated with a fluorescent material such as zinc-cadmium sulfide or sodium-cesium iodide. The phosphors convert X-rays passing through the patient to visible light photons, which are immediately converted to photoelectrons by a photocathode made of cesium and antimony. The electrons are focused by coils and accelerated across the image intensifier tube by a high-voltage field on a cylindrical anode. The electrons pass through the anode and strike a phosphor-covered output screen, which is much smaller in diameter than the input screen. Incident X-ray photons are greatly amplified by the image intensifier, making a brighter image with a lower dose of radiation.
Originally, the radiologist viewed the output screen using a microscope, which at least put a little more hardware between his or her eyeball and the X-ray source. Later, mirrors and lenses were added to project the image onto a screen, moving the doctor’s head out of the direct line of fire. Later still, analog TV cameras were added to the optical path so the images could be displayed on high-resolution CRT monitors in the fluoroscopy suite. Eventually, digital cameras and advanced digital signal processing were introduced, greatly streamlining the workflow for the radiologist and technologists alike.
Get To The Point
So far, all the detection methods we’ve discussed fall under the general category of planar detectors, in that they capture an entire 2D shadow of the X-ray beam after having passed through the patient. While that’s certainly useful, there are cases where the dose from a single, well-defined volume of tissue is needed. This is where point detectors come into play. Nuclear medicine image, or scintigraph, of metastatic cancer. 99Tc accumulates in lesions in the ribs and elbows (A), which are mostly resolved after chemotherapy (B). Note the normal accumulation of isotope in the kidneys and bladder. Kazunari Mado, Yukimoto Ishii, Takero Mazaki, Masaya Ushio, Hideki Masuda and Tadatoshi Takayama, CC BY-SA 2.0. In medical X-ray equipment, point detectors often rely on some of the same gas-discharge technology that DIYers use to build radiation detectors at home. Geiger tubes and ionization chambers measure the current created when X-rays ionize a low-pressure gas inside an electric field. Geiger tubes generally use a much higher voltage than ionization chambers, and tend to be used more for radiological safety, especially in nuclear medicine applications, where radioisotopes are used to diagnose and treat diseases. Ionization chambers, on the other hand, were often used as a sort of autoexposure control for conventional radiography. Tubes were placed behind the film cassette holders in the exam tables of X-ray suites and wired into the control panels of the X-ray generators. When enough radiation had passed through the patient, the film, and the cassette into the ion chamber to yield a correct exposure, the generator would shut off the X-ray beam.
Another kind of point detector for X-rays and other kinds of radiation is the scintillation counter. These use a crystal, often cesium iodide or sodium iodide doped with thallium, that releases a few visible light photons when it absorbs ionizing radiation. The faint pulse of light is greatly amplified by one or more photomultiplier tubes, creating a pulse of current proportional to the amount of radiation. Nuclear medicine studies use a device called a gamma camera, which has a hexagonal array of PM tubes positioned behind a single large crystal. A patient is injected with a radioisotope such as the gamma-emitting technetium-99, which accumulates mainly in the bones. Gamma rays emitted are collected by the gamma camera, which derives positional information from the differing times of arrival and relative intensity of the light pulse at the PM tubes, slowly building a ghostly skeletal map of the patient by measuring where the 99Tc accumulated.
Going Digital
Despite dominating the industry for so long, the days of traditional film-based radiography were clearly numbered once solid-state image sensors began appearing in the 1980s. While it was reliable and gave excellent results, film development required a lot of infrastructure and expense, and resulted in bulky films that required a lot of space to store. The savings from doing away with all the trappings of film-based radiography, including the darkrooms, automatic film processors, chemicals, silver recycling, and often hundreds of expensive film cassettes, is largely what drove the move to digital radiography.
After briefly flirting with phosphor plate radiography, where a sensitized phosphor-coated plate was exposed to X-rays and then “developed” by a special scanner before being recharged for the next use, radiology departments embraced solid-state sensors and fully digital image capture and storage. Solid-state sensors come in two flavors: indirect and direct. Indirect sensor systems use a large matrix of photodiodes on amorphous silicon to measure the light given off by a scintillation layer directly above it. It’s basically the same thing as a film cassette with intensifying screens, but without the film.
Direct sensors, on the other hand, don’t rely on converting the X-ray into light. Rather, a large flat selenium photoconductor is used; X-rays absorbed by the selenium cause electron-hole pairs to form, which migrate to a matrix of fine electrodes on the underside of the sensor. The current across each pixel is proportional to the amount measured to the amount of radiation received, and can be read pixel-by-pixel to build up a digital image.
Una recente analisi condotta dai FortiGuard Labs di Fortinet ha rivelato una sofisticata campagna di phishing volta a diffondere una nuova variante del malware FormBook, un infostealer noto per la sua capacità di sottrarre dati sensibili dai dispositivi compromessi. La campagna sfrutta la vulnerabilitàCVE-2017-11882 presente nei documenti Microsoft Word per infettare i sistemi degli utenti
Il vettore iniziale dell’attacco è un’email di phishing che simula un ordine di vendita, contenente un documento Word denominato “order0087.docx”. Questo file, salvato in formato Office Open XML (OOXML), include un riferimento a un file esterno “Algeria.rtf” attraverso il nodo “” nel file document.xml.
Quando l’utente apre il documento, Word carica automaticamente il file RTF esterno, avviando il processo di infezione. Il file RTF “Algeria.rtf” è offuscato con dati inutili per eludere le analisi statiche. Una volta de-offuscato, rivela due oggetti binari incorporati. Il primo è un file DLL a 64 bit denominato “AdobeID.pdf”, che viene estratto nella cartella temporanea del sistema. Il secondo è un oggetto OLE che contiene dati appositamente creati per sfruttare la vulnerabilitàCVE-2017-11882 nel Microsoft Equation Editor 3.0.
Questa vulnerabilità consente l’esecuzione di codice arbitrario quando Word elabora il file RTF, portando all’esecuzione del file DLL malevolo.
Il file DLL “AdobeID.pdf” funge da downloader e installatore per il malware FormBook. Una volta eseguito, stabilisce la persistenza nel sistema aggiungendo una chiave nel registro di Windows sotto “HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run“, assicurando l’esecuzione automatica del malware ad ogni avvio del sistema.
Successivamente, il malware si inietta in processi legittimi di Windows, come “explorer.exe”, per eseguire le sue attività dannose senza destare sospetti. FormBook è progettato per sottrarre informazioni sensibili, tra cui credenziali memorizzate, sequenze di tasti, screenshot e dati dagli appunti. Inoltre, può ricevere comandi da un server di controllo (C2) per eseguire ulteriori azioni dannose sul dispositivo infetto.
La sua capacità di iniettarsi in processi legittimi e di comunicare con server remoti lo rende particolarmente insidioso e difficile da rilevare
Per proteggersi da minacce come FormBook, è fondamentale mantenere aggiornati tutti i software, in particolare le suite di produttività come Microsoft Office.
Inoltre, è consigliabile implementare soluzioni di sicurezza avanzate che possano rilevare comportamenti anomali e bloccare attività sospette. La formazione degli utenti sull’identificazione di email di phishing e l’adozione di pratiche di navigazione sicura sono altrettanto cruciali per prevenire infezioni da malware.
Sometimes in fantasy fiction, you don’t want to explain something that seems inexplicable, so you throw your hands up and say, “A wizard did it.” Sometimes in astronomy, instead of a wizard, the answer is dark matter (DM). If you are interested in astronomy, you’ve probably heard that dark matter solves the problem of the “missing mass” to explain galactic light curves, and the motion of galaxies in clusters.
The Central Molecular Zone is a region near the heart of the Milky Way that has a very high density of interstellar gases– around sixty million times the mass of our sun, in a volume 1600 to 1900 light years across. It happens to be more ionized than it ought to be, and ionized in a very even manner across its volume. As astronomers cannot identify (or at least agree on) the mechanism to explain this ionization, the CMZ ionization is mystery number one. Feynman diagram of electron-positron annihilation, showing the characteristic gamma-ray emission. Mystery number two is a diffuse glow of gamma rays seen in the same part of the sky as the CMZ, which we know as the constellation Sagittarius. The emissions correspond to an energy of 515 keV, which is a very interesting number– it’s what you get when an electron annihilates with the antimatter version of itself. Again, there’s no universally accepted explanation for these emissions.
So [Pedro De la Torre Luque] and team asked themselves: “What if a wizard did it?” And set about trying to solve the mystery using dark matter. As it turns out, computer models including a form of light dark matter (called sub-GeV DM in the paper, for the particle’s rest masses) can explain both phenomena within the bounds of error.
In the model, the DM particles annihilate to form electron-positron pairs. In the dense interstellar gas of the CMZ, those positrons quickly form electrons to produce the 511 keV gamma rays observed. The energy released from this annihilation results in enough energy to produce the observed ionization, and even replicate the very flat ionization profile seen across the CMZ. (Any other proposed ionization source tends to radiate out from its source, producing an uneven profile.) Even better, this sort of light dark matter is consistent with cosmological observations and has not been ruled out by Earth-side dark matter detectors, unlike some heavier particles.
Further observations will help confirm or deny these findings, but it seems dark matter is truly the gift that keeps on giving for astrophysicists. We eagerly await what other unsolved questions in astronomy can be answered by it next, but it leaves us wondering how lazy the universe’s game master is if the answer to all our questions is: “A wizard did it.”
Building a Commodore 64 is among the easier projects for retrocomputing fans to tackle. That’s because the C64’s core chipset does most of the heavy lifting; source those and you’re probably 80% of the way there. But what if you can’t find those chips, or if you want more of a challenge than plugging and chugging? Are you out of luck?
Hardly. The video below from [DrMattRegan] is the first in a series on his scratch-built C64 that doesn’t use the core chipset, and it looks pretty promising. This video concentrates on building a replacement for the 6502 microprocessor — actually the 6510, but close enough — using just a couple of EPROMs, some SRAM chips, and a few standard logic chips to glue everything together. He uses the EPROMs as a “rulebook” that contains the code to emulate the 6502 — derived from his earlier Turing 6502 project — and the SRAM chips as a “notebook” for scratch memory and registers to make a Turing-complete random access machine.
[DrMatt] has made good progress so far, with the core 6502 CPU built on a PCB and able to run the Apple II version of Pac-Man as a benchmark. We’re looking forward to the rest of this series, but in the meantime, a look back at his VIC-less VIC-20 project might be informative.
Nel pomeriggio del 19 aprile, una notifica Telegram proveniente dai nostri sistemi di telemetria ci segnala la registrazione di un nuovo dominio: breached.fi. I record DNS risultano correttamente configurati. Il dubbio che si tratti dell’ennesimo dominio scam ci assale.
Sì, il dubbio è più che legittimo: da quando Breach Forums è andato offline il 15 aprile, ne abbiamo viste e sentite di tutti i colori. Si è parlato di un sequestro da parte dell’FBI nel contesto di una presunta operazione internazionale, dell’arresto di IntelBroker, fino alla comparsa di un nuovo “BreachForums” con registrazione a pagamento, rivelatosi poco dopo uno scam clamoroso.
Dopo il nostro articolo pubblicato il 15 aprile, abbiamo scelto di non intervenire ulteriormente, ma abbiamo continuato a monitorare l’evolversi della situazione, valutando con attenzione le fonti e confrontandoci all’interno del nostro gruppo DarkLab.
Nei giorni successivi si è scatenato un vero e proprio tam-tam mediatico: annunci da “strilloni da mercato medievale”, dichiarazioni contrastanti e versioni discordanti. Ognuno ha cercato di imporre la propria narrazione.
Per questo abbiamo deciso di fare ordine. Abbiamo selezionato solo le informazioni che riteniamo più attendibili e, come si fa in ogni seria attività di Cyber Threat Intelligence, abbiamo esaminato con metodo e rigore l’affidabilità delle fonti.
La truffa del dominio breachedforums.cc
La prima falsità emersa in questa vicenda riguarda l’attivazione del dominio breachedforums.cc, che inizialmente invitava gli utenti a registrarsi, facendo credere che il “nuovo” BreachForums fosse diventato a pagamento. Dopo poche ore, però, compare un banner che annuncia la messa in vendita del dominio. La prima truffa è servita.
Alle 09:56 UTC, DarkStorm annuncia sul proprio canale Telegram di aver lanciato un attacco DDoS contro BreachForums. Peccato che a quell’ora il sito fosse già irraggiungibile da diverse ore non a causa di un Denial of Service, bensì perché i record DNS erano stati eliminati. In altre parole, il dominio non esisteva più.
Inoltre, fonti dirette e affidabili in contatto con il nostro team DarkLab ci confermano che nessun attacco DDoS è mai stato eseguito e che DarkStorm non ha avuto alcun ruolo nella scomparsa di BreachForums. Una dichiarazione a effetto, dunque, ma totalmente priva di fondamento.
Il presunto arresto di IntelBroker e i chiarimenti da parte di Rey di HellCat
Da più fonti viene strillata la notizia dell’arresto di IntelBroker (insieme ad altri presunti admin di BreachForums), ma nessuna conferma ufficiale viene rilasciata.
Poche ore dopo, Rey (ndr: HellCat Group) interviene con una risposta molto chiara a un post su X, smentendo in modo netto le voci circolate.
Anche in questo caso, le informazioni raccolte dal nostro team DarkLab confermano che IntelBroker non è stato arrestato e che si tratta con ogni probabilità di una campagna di disinformazione.
Il nuovo BreachForum sarà presto on-line!
Arriviamo dunque al 20 Aprile alle ore 17.57 il nuovo dominio breached.fi viene attivato e i record DNS pubblicati. La home page è quella che tutti conosciamo di BF, contiene però solo un disclaimer da parte dell’admin Anastasia circa il fatto che il sito sarà completamente online tra il 23 e il 24 Aprile 2025. Rey di HellCat posta un messaggio sul suo profilo X invitando a visitare il nuovo sito. Stay tuned – aggiorneremo questo articolo con ulteriori sviluppi.
If you’ve ever fumbled through circuit simulation and ended up with a flatline instead of a sine wave, this video from [saisri] might just be the fix. In this walkthrough she demonstrates simulating a Colpitts oscillator using NI Multisim 14.3 – a deceptively simple analog circuit known for generating stable sine waves. Her video not only shows how to place and wire components, but it demonstrates why precision matters, even in virtual space.
You’ll notice the emphasis on wiring accuracy at multi-node junctions, something many tutorials skim over. [saisri] points out that a single misconnected node in Multisim can cause the circuit to output zilch. She guides viewers step-by-step, starting with component selection via the “Place > Components” dialog, through to running the simulation and interpreting the sine wave output on Channel A. The manual included at the end of the video is a neat bonus, bundling theory, waveform visuals, and circuit diagrams into one handy PDF.
If you’re into precision hacking, retro analogue joy, or just love watching a sine wave bloom onscreen, this is worth your time. You can watch the original video here.
Using steam to produce electricity or perform work via steam turbines has been a thing for a very long time. Today it is still exceedingly common to use steam in this manner, with said steam generated either by burning something (e.g. coal, wood), by using spicy rocks (nuclear fission) or from stored thermal energy (e.g. molten salt). That said, today we don’t use steam in the same way any more as in the 19th century, with e.g. supercritical and pressurized loops allowing for far higher efficiencies. As covered in a recent video by [Ryan Inis], a more recent alternative to using water is supercritical carbon dioxide (CO2), which could boost the thermal efficiency even further.
In the video [Ryan Inis] goes over the basics of what the supercritical fluid state of CO2 is, which occurs once the critical point is reached at 31°C and 83.8 bar (8.38 MPa). When used as a working fluid in a thermal power plant, this offers a number of potential advantages, such as the higher density requiring smaller turbine blades, and the potential for higher heat extraction. This is also seen with e.g. the shift from boiling to pressurized water loops in BWR & PWR nuclear plants, and in gas- and salt-cooled reactors that can reach far higher efficiencies, as in e.g. the HTR-PM and MSRs.
In a 2019 article in Power goes over some of the details, including the different power cycles using this supercritical fluid, such as various Brayton cycles (some with extra energy recovery) and the Allam cycle. Of course, there is no such thing as a free lunch, with corrosion issues still being worked out, and despite the claims made in the video, erosion is also an issue with supercritical CO2 as working fluid. That said, it’s in many ways less of an engineering issue than supercritical steam generators due to the far more extreme critical point parameters of water.
If these issues can be overcome, it could provide some interesting efficiency boosts for thermal plants, with the caveat that likely nobody is going to retrofit existing plants, supercritical steam (coal) plants already exist and new nuclear plant designs are increasingly moving towards gas, salt and even liquid metal coolants, though secondary coolant loops (following the typical steam generator) could conceivably use CO2 instead of water where appropriate.
In the dark ages, before iOS and Android phones became ubiquitous, there was the PDA. These handheld computers acted as simple companions to a computer and could often handle calendars, email, notes and more. Their demise was spelled by the smartphone, but the nostalgia of having a simple handheld and romanticizing about the 90’s and 2000’s is still there. Fortunately for the nostalgic among our readers, [Ashtf] decided to give us a modern take on the classic PDAs.
The device is powered by an ESP32-S3 connected to two PCBs in a mini-laptop clamshell format. It features two displays, a main eInk for slow speed interaction and a little i2c AMOLED for more tasks which demand higher refresh then an eInk can provide. Next to the eInk display is a capacitive slider. For input, there is also a QWERTY keyboard with back resin printed keycaps and white air dry clay pressed into embossed lettering in the keys and finally sealed using nail polish to create a professional double-shot looking keycap. The switches are the metal dome kind sitting on the main PCB. The clamshell is a rather stylish clear resin showcasing the device’s internals and even features a quick-change battery cover!
The device’s “operating system” is truly where the magic happens. It features several apps including a tasks app, file wizard, and text app. The main purpose of the device is on the go note taking so much time has been taken with the excellent looking text app! It also features a docked mode which displays tasks and time when it detects a USB-C cable is connected. Plans exist in the future to implement a calender, desktop sync and even Bluetooth keybaord compatibility. The device’s previous iteration is on GitHub with future plans to expand functionality and availability, so stay tuned for more coverage!
Back in the day, one of the few reasons to prefer compact cassette tape to vinyl was the fact you could record it at home in very good fidelity. Sure, if you had the scratch, you could go out and get a small batch of records made from that tape, but the machinery to do it was expensive and not always easy to come by, depending where you lived. That goes double today, but we’re in the middle of a vinyl renaissance! [ronald] wanted to make records, but was unable to find a lathe, so decided to take matters into his own hands, and build his own vinyl record cutting lathe.
[ronald’s] record cutting lathe looks quite professional.It seems like it should be a simple problem, at least in concept: wiggle an engraving needle to scratch grooves in plastic. Of course for a stereo record, the wiggling needs to be two-axis, and for stereo HiFi you need that wiggling to be very precise over a very large range of frequencies (7 Hz to 50 kHz, to match the pros). Then of course there’s the question of how you’re controlling the wiggling of this engraving needle. (In this case, it’s through a DAC, so technically this is a CNC hack.) As often happens, once you get down to brass tacks (or diamond styluses, as the case may be) the “simple” problem becomes a major project.
The build log discusses some of the challenges faced–for example, [ronald] started with locally made polycarbonate disks that weren’t quite up to the job, so he has resigned himself to purchasing professional vinyl blanks. The power to the cutting head seems to have kept creeping up with each revision: the final version, pictured here, has two 50 W tweeters driving the needle.
That necessitated a better amplifier, which helped improve frequency response. So it goes; the whole project took [ronald] fourteen months, but we’d have to say it looks like it was worth it. It sounds worth it, too; [ronald] provides audio samples; check one out below. Every garage band in Queensland is going to be beating a path to [ronald’s] door to get their jam sessions cut into “real” records, unless they agree that physical media deserved to die. hackaday.com/wp-content/upload…
We all know periscopes serve for observation where there’s no direct line-of-sight, but did you know they can allow you to peer through history? That’s what [msylvain59] documented when he picked up a British military night vision periscope, snagged from a German surplus shop for just 49 euros. Despite its Cold War vintage and questionable condition, the unit begged for a teardown.
The periscope is a 15-kilo beast: industrial metal, cryptic shutter controls, and twin optics that haven’t seen action since flares were fashionable. One photo amplifier tube flickers to greenish life, the other’s deader than a disco ball in 1993. With no documentation, unclear symbols, and adjustment dials from hell, the teardown feels more like deciphering a British MoD fever dream than a Sunday project. And of course, everything’s imperial.
Despite corrosion, mysterious bulbs, and non-functional shutters, [msylvian59] uncovers a fascinating mix of precision engineering and Cold War paranoia. There’s a thrill in tracing light paths through mil-spec lenses (the number of graticules seen that are etched on the optics) and wondering what secrets they once guarded. This relic might not see well anymore, but it sure makes us look deeper. Let us know your thoughts in the comments or share your unusual wartime relics below.
As computers have gotten smaller and less expensive over the years, so have their components. While many of us got our start in the age of through-hole PCBs, this size reduction has led to more and more projects that need the use of surface-mount components and their unique set of tools. These tools tend to be more elaborate than what would be needed for through-hole construction but [Tobi] has a new project that goes into some details about how to build surface-mount projects without breaking the bank.
The project here is interesting in its own right, too: a display module upgrade for the classic Game Boy based on an RP2350B microprocessor. To get all of the components onto a PCB that actually fits into the original case, though, surface-mount is required. For that [Tobi] is using a small USB-powered hotplate to reflow the solder, a Pinecil, and a healthy amount of flux. The hotplate is good enough for a small PCB like this, and any solder bridges can be quickly cleaned up with some extra flux and a quick pass with a soldering iron.
The build goes into a lot of detail about how a process like this works, so if you’ve been hesitant to start working with surface mount components this might be a good introduction. Not only that, but we also appreciate the restoration of the retro video game handheld complete with some new features that doesn’t disturb the original look of the console. One of the other benefits of using the RP2350 for this build is that it’s a lot simpler than using an FPGA, but there are perks to taking the more complicated route as well.
Over the course of more than a decade, physical media has gradually vanished from public view. Once computers had an optical drive except for ultrabooks, but these days computer cases that even support an internal optical drive are rare. Rather than manuals and drivers included on a data CD you now get a QR code for an online download. In the home, DVD and Blu-ray (BD) players have given way to smart TVs with integrated content streaming apps for various services. Music and kin are enjoyed via smart speakers and smart phones that stream audio content from online services. Even books are now commonly read on screens rather than printed on paper.
With these changes, stores selling physical media have mostly shuttered, with much audiovisual and software content no longer pressed on discs or printed. This situation might lead one to believe that the end of physical media is nigh, but the contradiction here comes in the form of a strong revival of primarily what used to be considered firmly obsolete physical media formats. While CD, DVD and BD sales are plummeting off a cliff, vinyl records, cassette tapes and even media like 8-track tapes are undergoing a resurgence, in a process that feels hard to explain.
How big is this revival, truly? Are people tired of digital restrictions management (DRM), high service fees and/or content in their playlists getting vanished or altered? Perhaps it is out of a sense of (faux) nostalgia?
A Deserved End
Ask anyone who ever has had to use any type of physical media and they’ll be able to provide a list of issues with various types of physical media. Vinyl always was cumbersome, with clicking and popping from dust in the grooves, and gradual degradation of the record with a lifespan in the hundreds of plays. Audio cassettes were similar, with especially Type I cassettes having a lot of background hiss that the best Dolby noise reduction (NR) systems like Dolby B, C and S only managed to tame to a certain extent.
Add to this issues like wow and flutter, and the joy of having a sticky capstan roller resulting in tape spaghetti when you open the tape deck, ruining that precious tape that you had only recently bought. These issues made CDs an obvious improvement over both audio formats, as they were fully digital and didn’t wear out from merely playing them hundreds of times.
Although audio CDs are better in many ways, they do not lend themselves to portability very well unlike tape, with anti-shock read buffers being an absolute necessity to make portable CD players at all feasible. This same issue made data CDs equally fraught with issues, especially if you went into the business of writing your own (data or audio) CDs on CD-Rs. Burning coasters was exceedingly common for years. Yet the alternative was floppies – with LS-120 and Zip disks never really gaining much market share – or early Flash memory, whether USB sticks (MB-sized) or those inside MP3 players and early digital cameras. There were no good options, but we muddled on.
On the video side VHS had truly brought the theater into the home, even if it was at fuzzy NTSC or PAL quality with astounding color bleed and other artefacts. Much like audio cassette tapes, here too the tape would gradually wear out, with the analog video signal ensuring that making copies would result in an inferior copy.
Rewinding VHS tapes was the eternal curse, especially when popping in that tape from the rental store and finding that the previous person had neither been kind, nor rewound. Even if being able to record TV shows to watch later was an absolute game changer, you better hope that you managed to appease the VHS gods and had it start at the right time.
It could be argued that DVDs were mostly perfect aside from a lack of recording functionality by default and pressed DVDs featuring unskippable trailers and similar nonsense. One can also easily argue here that DVDs’ success was mostly due to its DRM getting cracked early on when the CSS master key leaked. DVDs would also introduce region codes that made this format less universal than VHS and made things like snapping up a movie during an overseas vacation effectively impossible.
This was a practice that BDs doubled-down on, and with the encryption still intact to this day, it means that unlike with DVDs you must pay to be allowed to watch BDs which you previously bought, whether this cost is included in the dedicated BD player, or the license cost for a BD video player for on the PC.
Thus, when streaming services gave access to a very large library for a (small) monthly fee, and cloud storage providers popped up everywhere, it seemed like a no-brainer. It was like paying to have the world’s largest rental store next door to your house, or a data storage center for all your data. All you had to do was create an account, whip out the credit card and no more worries.
Combined with increasingly faster and ubiquitous internet connections, the age of physical media seemed to have come to its natural end.
The Revival
US vinyl record sales 1995-2020. (Credit: Ippantekina with RIAA data) Despite this perfect landscape where all content is available all the time via online services through your smart speakers, smart TVs, smart phones and so on, the number of vinyl record sales has surged the past years despite its reported death in the early 2000s. In 2024 the vinyl records market grew another few percent, with more and more new record pressing plants coming online. In addition to vinyl sales, UK cassette sales also climbed, hitting 136,000 in 2023. CD sales meanwhile have kept plummeting, but not as strongly any more.
Perhaps the most interesting part is that most of newly released vinyl are new albums, by artists like Taylor Swift, yet even the classics like Pink Floyd and Fleetwood Mac keep selling. As for the ‘why’, some suggest that it’s the social and physical experience of physical media and the associated interactions that is a driving factor. In this sense it’s more of a (cultural) statement, as a rejection of the world of digital streaming. The sleeve of a vinyl record also provides a lot of space for art and other creative expressions, all of which provides a collectible value.
Although so far CD sales haven’t really seen a revival, the much lower cost of producing these shiny discs could reinvigorate this market too for many of the same reasons. Who doesn’t remember hanging out with a buddy and reading the booklet of a CD album which they just put into the player after fetching it from their shelves? Maybe checking the lyrics, finding some fun Easter eggs or interesting factoids that the artists put in it, and having a good laugh about it with your buddy.
As some responded when asked, they like the more intimate experience of vinyl records along with having a physical item to own, while streaming music is fine for background music. The added value of physical media here is thus less about sound quality, and more about a (social) experience and collectibles.
On the video side of the fence there is no such cheerful news, however. In 2024 sales of DVDs, BDs and UHD (4K) BDs dropped by 23.4% year-over-year to below $1B in the US. This compares with a $16B market value in 2005, underlining a collapsing market amidst brick & mortar stores either entirely removing their DVD & BD section, or massively downsizing it. Recently Sony also announced the cessation of its recordable BD, MD and MiniDV media, as a further indication of where the market is heading.
Despite streaming services repeatedly bifurcating themselves and their libraries, raising prices and constantly pulling series and movies, this does not seem to hurt their revenue much, if at all. This is true for both audiovisual services like Netflix, but also for audio streaming services like Spotify, who are seeing increasing demand (per Billboard), even as digital track sales are seeing a pretty big drop year-over-year (-17.9% for Week 16 of 2025).
Perhaps this latter statistic is indicative that the idea of ‘buying’ a music album or film which – courtesy of DRM – is something that you’re technically only leasing, is falling out of favor. This is also illustrated by the end of Apple’s iPod personal music player in favor of its smart phones that are better suited for streaming music on the go. Meanwhile many series and some movies are only released on certain streaming platforms with no physical media release, which incentivizes people to keep those subscriptions.
To continue the big next-door-rental-store analogy, in 2025 said single rental store has now turned into fifty stores, each carrying a different inventory that gets either shuffled between stores or tossed into a shredder from time to time. Yet one of them will have That New Series, which makes them a great choice, unless you like more rare and older titles, in which case you get to hunt the dusty shelves over at EBay and kin.
It’s A Personal Thing
Humans aren’t automatons that have to adhere to rigid programming. They have each their own preferences, ideologies and wishes. While for some people the DRM that has crept into the audiovisual world since DVDs, Sony’s MiniDisc (with initial ATRAC requirement), rootkits on audio CDs, and digital music sales continues to be a deal-breaker, others feel no need to own all the music and videos they like and put them on their NAS for local streaming. For some the lower audio quality of Spotify and kin is no concern, much like for those who listened to 64 kbit WMA files in the early 2000s, while for others only FLACs ripped from a CD can begin to appease their tastes.
Reading through the many reports about ‘the physical media’ revival, what jumps out is that on one hand it is about the exclusivity of releasing something on e.g. vinyl, which is also why sites like Bandcamp offer the purchase of a physical album, and mainstream artists more and more often opt for this. This ties into the other noticeable reason, which is the experience around physical media. Not just that of handling the physical album and operating of the playback device, but also that of the offline experience, being able to share the experience with others without any screens or other distractions around. Call it touching grass in a socializing sense.
As I mentioned already in an earlier article on physical media and its purported revival, there is no reason why people cannot enjoy both physical media as well as online streaming. If one considers the rental store analogy, the former (physical media) is much the same as it always was, while online streaming merely replaces the brick & mortar rental store. Except that these new rental stores do not take requests for tapes or DVDs not in inventory and will instead tell you to subscribe to another store or use a VPN, but that’s another can of worms.
So far optical media seems to be still in freefall, and it’s not certain whether it will recover, or even whether there might be incentives in board rooms to not have DVDs and BDs simply die. Here the thought of having countless series and movies forever behind paywalls, with occasional ‘vanishings’ might be reason enough for more people to seek out a physical version they can own, or it may be that the feared erasure of so much media in this digital, DRM age is inevitable.
Running Up That Hill
Original Sony Walkman TPS-L2 from 1979. The ironic thing about this revival is that it seems influenced very much by streaming services, such as with the appearance of a portable cassette player in Netflix’s Stranger Things, not to mention Rocket Raccoon’s original Sony Walkman TPS-L2 in Marvel’s Guardians of the Galaxy.
After many saw Sony’s original Walkman in the latter movie, there was a sudden surge in EBay searches for this particular Walkman, as well as replicas being produced by the bucket load, including 3D printed variants. This would seem to support the theory that the revival of vinyl and cassette tapes is more about the experiences surrounding these formats, rather than anything inherent to the format itself, never mind the audio quality.
As we’re now well into 2025, we can quite confidently state that vinyl and cassette tape sales will keep growing this year. Whether or not new (and better) cassette mechanisms (with Dolby NR) will begin to be produced again along with Type II tapes remains to be seen, but there seems to be an inkling of hope there. It was also reported that Dolby is licensing new cassette mechanisms for NR, so who knows.
Meanwhile CD sales may stabilize and perhaps even increase again, in the midst of still a very uncertain future optical media in general. Recordable optical media will likely continue its slow death, as in the PC space Flash storage has eaten its lunch and demanded seconds. Even though PCs no longer tend to have 5.25″ bays for optical drives, even a simple Flash thumb drive tends to be faster and more durable than a BD. Here the appeal of ‘cloud storage’ has been reduced after multiple incidents of data loss & leaks in favor of backing up to a local (SSD) drive.
Finally, as old-school physical audio formats experience a revival, there just remains the one question about whether movies and series will soon only be accessible via streaming services, alongside a veritable black market of illicit copies, or whether BD versions of movies and series will remain available for sale. With the way things are going, we may see future releases on VHS, to match the vibe of vinyl and cassette tapes.
In lieu of clear indications from the industry on what direction things will be heading into, any guess is probably valid at this point. The only thing that seems abundantly clear at this point is that physical media had to die first for us to learn to truly appreciate it.
As we were looking into a cyberincident in April 2025, we uncovered a rather sophisticated backdoor. It targeted various large organizations in Russia, spanning the government, finance, and industrial sectors. While our investigation into the attack associated with the backdoor is still ongoing, we believe it is crucial to share our preliminary findings with the community. This will enable organizations that may be at risk of infection from the backdoor to take swift action to protect themselves from this threat.
Impersonating a ViPNet update
Our investigation revealed that the backdoor targets computers connected to ViPNet networks. ViPNet is a software suite for creating secure networks. We determined that the backdoor was distributed inside LZH archives with a structure typical of updates for the software product in question. These archives contained the following files:
action.inf: a text file
lumpdiag.exe: a legitimate executable
msinfo32.exe: a small malicious executable
an encrypted file containing the payload (the name varies between archives)
After analyzing the contents of the archive, we found that the action.inf text file contained an action to be executed by the ViPNet update service component (itcsrvup64.exe) when processing the archive:
[ACTION]action=extra_command extra_command=lumpdiag.exe --msconfig As evident from the file content above, when processing extra_command, the update service launches lumpdiag.exe with an --msconfig argument. We mentioned earlier that this is a legitimate file. However, it is susceptible to the path substitution technique. This allows attackers to execute the malicious file msinfo32.exe while lumpdiag.exe is running.
Downloadable payload
The msinfo32.exe file is a loader that reads the encrypted payload file. The loader processes the contents of the file to load the backdoor into memory. This backdoor is versatile: it can connect to a C2 server via TCP, allowing the attacker to steal files from infected computers and launch additional malicious components, among other things. Kaspersky solutions detect this threat as HEUR:Trojan.Win32.Loader.gen.
Multi-layered security is key to preventing sophisticated cyberattacks
The complexity of cyberattacks carried out by APT groups has significantly increased over the years. Attackers can target organizations in highly unusual and unexpected ways. To prevent sophisticated targeted attacks, it is essential to employ multi-layered, defense-in-depth security against cyberthreats. This is the type of security architecture implemented in our Kaspersky NEXT product line, capable of protecting businesses from attacks similar to the one described in this article.
The last parts of the central solenoid assembly have finally made their way to France from the United States, making both a milestone in the slow development of the world’s largest tokamak, and a reminder that despite the current international turmoil, we really can work together, even if we can’t agree on the units to do it in. The central solenoid is in the “doughnut hole” of the tokamak in this cutaway diagram. Image: US ITER. The central solenoid is 4.13 m across (that’s 13′ 7″ for burger enthusiasts) sits at the hole of the “doughnut” of the toroidal reactor. It is made up of six modules, each weighing 110 t (the weight of 44 Ford F-150 pickup trucks), stacked to a total height of 59 ft (that’s 18 m, if you prefer). Four of the six modules have be installed on-site, and the other two will be in place by the end of this year.
Each module was produced ITER US, using superconducting material produced by ITER Japan, before being shipped for installation at the main ITER site in France — all to build a reactor based on a design from the Soviet Union. It doesn’t get much more international than this!
This magnet is, well, central to a the functioning of a tokamak. Indeed, the presence of a central solenoid is one of the defining features of this type, compared to other toroidal rectors (like the earlier stellarator or spheromak). The central solenoid provides a strong magnetic field (in ITER, 13.1 T) that is key to confining and stabilizing the plasma in a tokamak, and inducing the 15 MA current that keeps the plasma going.
When it is eventually finished (now scheduled for initial operations in 2035) ITER aims to produce 500 MW of thermal power from 50 MW of input heating power via a deuterium-tritium fusion reaction. You can follow all news about the project here.
Gli esperti di Check Point avvertono che lo sfruttamento di una nuova vulnerabilità NTLM di Windows ha avuto inizio circa una settimana dopo il rilascio delle patch il mese scorso.
La vulnerabilità in questione è il CVE-2025-24054 (punteggio CVSS 6,5), che è stata risolta come parte del Patch Tuesday di marzo 2025. Questo problema determina la divulgazione dell’hash NTLM, consentendo agli aggressori di eseguire attacchi di spoofing.
Secondo Microsoft, per sfruttare con successo questo bug è necessaria un’interazione minima da parte dell’utente. Pertanto, la vulnerabilità può essere attivata semplicemente selezionando un file dannoso o cliccandoci sopra con il tasto destro.
Come hanno ora segnalato gli analisti di Check Point, appena una settimana dopo il rilascio delle patch per CVE-2025-24054, gli aggressori hanno iniziato a sfruttare la vulnerabilità per attaccare agenzie governative e organizzazioni private in Polonia e Romania.
“La vulnerabilità viene esposta quando un utente decomprime un archivio ZIP contenente un file .library-ms dannoso. Questo evento fa sì che Esplora risorse di Windows avvii una richiesta di autenticazione SMB al server remoto e, di conseguenza, porta alla perdita dell’hash NTLM dell’utente senza la sua partecipazione”, scrivono gli esperti. Una volta esposto l’hash NTLM, gli aggressori possono eseguire un attacco brute-force per ottenere la password dell’utente o organizzare un attacco relay.
A seconda dei privilegi dell’account compromesso, gli hacker hanno la possibilità di muoversi nella rete, aumentare i propri privilegi e potenzialmente compromettere l’intero dominio. Sebbene Microsoft non abbia ancora annunciato che la vulnerabilità CVE-2025-24054 sia stata sfruttata dagli hacker, i ricercatori affermano di aver scoperto più di una dozzina di campagne dannose che prendevano di mira la vulnerabilità tra il 19 e il 25 marzo. Gli hash NTLM sono stati estratti su server SMB in Australia, Bulgaria, Paesi Bassi, Russia e Turchia.
“Una campagna sembra aver avuto luogo intorno al 20-21 marzo 2025. I suoi obiettivi principali erano i governi polacco e rumeno e organizzazioni private. Alle vittime sono stati inviati via email link di phishing contenenti un file di archivio scaricato da Dropbox“, spiega Check Point.
Uno dei file nell’archivio era collegato a un’altra vulnerabilità simile, il CVE-2024-43451, utilizzata anch’essa per esporre l’hash NTLM. Un altro file faceva riferimento a un server SMB associato al gruppo APT Fancy Bear (noto anche come APT28, Forest Blizzard e Sofacy). Tuttavia, va notato che non ci sono ancora dati sufficienti per attribuire con certezza gli attacchi.
Check Point avverte inoltre che almeno una campagna del 25 marzo 2025 ha distribuito il file dannoso .library-ms in formato non compresso.
![Appearance of www.smartmanagerex[.]com](https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2025/04/22201230/operation-synchole-watering2.png "Appearance of www.smartmanagerex[.]com")
![photograph of [ronald's] setup](https://poliverso.org/photo/link/299575 "photograph of [ronald's] setup")
