IT'S MONDAY, AND THIS IS DIGITAL POLITICS. I'm Mark Scott, and I have many feelings about Sora, OpenAI's new AI-generated social media platform. Many of which are encapsulated by this video by Casey Neistat. #FreeTheSlop.

— The world's largest platforms have failed to respond to the highest level of global conflict since World War II.

— The semiconductor wars between China and the United States are creating a massive barrier between the world's two largest economies.

— China's DeepSeek performs significantly worse than its US counterparts on a series of benchmark tests.

Let's get started:

digitalpolitics.co/newsletter0…

DLL hijacking is a common technique in which attackers replace a library called by a legitimate process with a malicious one. It is used by both creators of mass-impact malware, like stealers and banking Trojans, and by APT and cybercrime groups behind targeted attacks. In recent years, the number of DLL hijacking attacks has grown significantly.

Trend in the number of DLL hijacking attacks. 2023 data is taken as 100% (download)

We have observed this technique and its variations, like DLL sideloading, in targeted attacks on organizations in Russia, Africa, South Korea, and other countries and regions. Lumma, one of 2025’s most active stealers, uses this method for distribution. Threat actors trying to profit from popular applications, such as DeepSeek, also resort to DLL hijacking.

Detecting a DLL substitution attack is not easy because the library executes within the trusted address space of a legitimate process. So, to a security solution, this activity may look like a trusted process. Directing excessive attention to trusted processes can compromise overall system performance, so you have to strike a delicate balance between a sufficient level of security and sufficient convenience.

Detecting DLL hijacking with a machine-learning model

Artificial intelligence can help where simple detection algorithms fall short. Kaspersky has been using machine learning for 20 years to identify malicious activity at various stages. The AI expertise center researches the capabilities of different models in threat detection, then trains and implements them. Our colleagues at the threat intelligence center approached us with a question of whether machine learning could be used to detect DLL hijacking, and more importantly, whether it would help improve detection accuracy.

Preparation

To determine if we could train a model to distinguish between malicious and legitimate library loads, we first needed to define a set of features highly indicative of DLL hijacking. We identified the following key features:

• Wrong library location. Many standard libraries reside in standard directories, while a malicious DLL is often found in an unusual location, such as the same folder as the executable that calls it.
• Wrong executable location. Attackers often save executables in non-standard paths, like temporary directories or user folders, instead of %Program Files%.
• Renamed executable. To avoid detection, attackers frequently save legitimate applications under arbitrary names.
• Library size has changed, and it is no longer signed.
• Modified library structure.

Training sample and labeling

For the training sample, we used dynamic library load data provided by our internal automatic processing systems, which handle millions of files every day, and anonymized telemetry, such as that voluntarily provided by Kaspersky users through Kaspersky Security Network.

The training sample was labeled in three iterations. Initially, we could not automatically pull event labeling from our analysts that indicated whether an event was a DLL hijacking attack. So, we used data from our databases containing only file reputation, and labeled the rest of the data manually. We labeled as DLL hijacking those library-call events where the process was definitively legitimate but the DLL was definitively malicious. However, this labeling was not enough because some processes, like “svchost”, are designed mainly to load various libraries. As a result, the model we trained on this data had a high rate of false positives and was not practical for real-world use.

In the next iteration, we additionally filtered malicious libraries by family, keeping only those which were known to exhibit DLL-hijacking behavior. The model trained on this refined data showed significantly better accuracy and essentially confirmed our hypothesis that we could use machine learning to detect this type of attacks.

At this stage, our training dataset had tens of millions of objects. This included about 20 million clean files and around 50,000 definitively malicious ones.

We then trained subsequent models on the results of their predecessors, which had been verified and further labeled by analysts. This process significantly increased the efficiency of our training.

Loading DLLs: what does normal look like?

So, we had a labeled sample with a large number of library loading events from various processes. How can we describe a “clean” library? Using a process name + library name combination does not account for renamed processes. Besides, a legitimate user, not just an attacker, can rename a process. If we used the process hash instead of the name, we would solve the renaming problem, but then every version of the same library would be treated as a separate library. We ultimately settled on using a library name + process signature combination. While this approach considers all identically named libraries from a single vendor as one, it generally produces a more or less realistic picture.

To describe safe library loading events, we used a set of counters that included information about the processes (the frequency of a specific process name for a file with a given hash, the frequency of a specific file path for a file with that hash, and so on), information about the libraries (the frequency of a specific path for that library, the percentage of legitimate launches, and so on), and event properties (that is, whether the library is in the same directory as the file that calls it).

The result was a system with multiple aggregates (sets of counters and keys) that could describe an input event. These aggregates can contain a single key (e.g., a DLL’s hash sum) or multiple keys (e.g., a process’s hash sum + process signature). Based on these aggregates, we can derive a set of features that describe the library loading event. The diagram below provides examples of how these features are derived:

Feature extraction from aggregates

Loading DLLs: how to describe hijacking

Certain feature combinations (dependencies) strongly indicate DLL hijacking. These can be simple dependencies. For some processes, the clean library they call always resides in a separate folder, while the malicious one is most often placed in the process folder.

Other dependencies can be more complex and require several conditions to be met. For example, a process renaming itself does not, on its own, indicate DLL hijacking. However, if the new name appears in the data stream for the first time, and the library is located on a non-standard path, it is highly likely to be malicious.

Model evolution

Within this project, we trained several generations of models. The primary goal of the first generation was to show that machine learning could at all be applied to detecting DLL hijacking. When training this model, we used the broadest possible interpretation of the term.

The model’s workflow was as simple as possible:

1. We took a data stream and extracted a frequency description for selected sets of keys.
2. We took the same data stream from a different time period and obtained a set of features.
3. We used type 1 labeling, where events in which a legitimate process loaded a malicious library from a specified set of families were marked as DLL hijacking.
4. We trained the model on the resulting data.

First-generation model diagram

The second-generation model was trained on data that had been processed by the first-generation model and verified by analysts (labeling type 2). Consequently, the labeling was more precise than during the training of the first model. Additionally, we added more features to describe the library structure and slightly complicated the workflow for describing library loads.

Second-generation model diagram

Based on the results from this second-generation model, we were able to identify several common types of false positives. For example, the training sample included potentially unwanted applications. These can, in certain contexts, exhibit behavior similar to DLL hijacking, but they are not malicious and rarely belong to this attack type.

We fixed these errors in the third-generation model. First, with the help of analysts, we flagged the potentially unwanted applications in the training sample so the model would not detect them. Second, in this new version, we used an expanded labeling that included useful detections from both the first and second generations. Additionally, we expanded the feature description through one-hot encoding — a technique for converting categorical features into a binary format — for certain fields. Also, since the volume of events processed by the model increased over time, this version added normalization of all features based on the data flow size.

Third-generation model diagram

Comparison of the models

To evaluate the evolution of our models, we applied them to a test data set none of them had worked with before. The graph below shows the ratio of true positive to false positive verdicts for each model.

Trends in true positives and false positives from the first-, second-, and third-generation models

As the models evolved, the percentage of true positives grew. While the first-generation model achieved a relatively good result (0.6 or higher) only with a very high false positive rate (10^⁻³ or more), the second-generation model reached this at 10^⁻⁵. The third-generation model, at the same low false positive rate, produced 0.8 true positives, which is considered a good result.

Evaluating the models on the data stream at a fixed score shows that the absolute number of new events labeled as DLL Hijacking increased from one generation to the next. That said, evaluating the models by their false verdict rate also helps track progress: the first model has a fairly high error rate, while the second and third generations have significantly lower ones.

False positives rate among model outputs, July 2024 – August 2025 (download)

Practical application of the models

All three model generations are used in our internal systems to detect likely cases of DLL hijacking within telemetry data streams. We receive 6.5 million security events daily, linked to 800,000 unique files. Aggregates are built from this sample at a specified interval, enriched, and then fed into the models. The output data is then ranked by model and by the probability of DLL hijacking assigned to the event, and then sent to our analysts. For instance, if the third-generation model flags an event as DLL hijacking with high confidence, it should be investigated first, whereas a less definitive verdict from the first-generation model can be checked last.

Simultaneously, the models are tested on a separate data stream they have not seen before. This is done to assess their effectiveness over time, as a model’s detection performance can degrade. The graph below shows that the percentage of correct detections varies slightly over time, but on average, the models detect 70–80% of DLL hijacking cases.

DLL hijacking detection trends for all three models, October 2024 – September 2025 (download)

Additionally, we recently deployed a DLL hijacking detection model into the Kaspersky SIEM, but first we tested the model in the Kaspersky MDR service. During the pilot phase, the model helped to detect and prevent a number of DLL hijacking incidents in our clients’ systems. We have written a separate article about how the machine learning model for detecting targeted attacks involving DLL hijacking works in Kaspersky SIEM and the incidents it has identified.

Conclusion

Based on the training and application of the three generations of models, the experiment to detect DLL hijacking using machine learning was a success. We were able to develop a model that distinguishes events resembling DLL hijacking from other events, and refined it to a state suitable for practical use, not only in our internal systems but also in commercial products. Currently, the models operate in the cloud, scanning hundreds of thousands of unique files per month and detecting thousands of files used in DLL hijacking attacks each month. They regularly identify previously unknown variations of these attacks. The results from the models are sent to analysts who verify them and create new detection rules based on their findings.

securelist.com/building-ml-mod…

Introduction

Our colleagues from the AI expertise center recently developed a machine-learning model that detects DLL-hijacking attacks. We then integrated this model into the Kaspersky Unified Monitoring and Analysis Platform SIEM system. In a separate article, our colleagues shared how the model had been created and what success they had achieved in lab environments. Here, we focus on how it operates within Kaspersky SIEM, the preparation steps taken before its release, and some real-world incidents it has already helped us uncover.

How the model works in Kaspersky SIEM

The model’s operation generally boils down to a step-by-step check of all DLL libraries loaded by processes in the system, followed by validation in the Kaspersky Security Network (KSN) cloud. This approach allows local attributes (path, process name, and file hashes) to be combined with a global knowledge base and behavioral indicators, which significantly improves detection quality and reduces the probability of false positives.

The model can run in one of two modes: on a correlator or on a collector. A correlator is a SIEM component that performs event analysis and correlation based on predefined rules or algorithms. If detection is configured on a correlator, the model checks events that have already triggered a rule. This reduces the volume of KSN queries and the model’s response time.

This is how it looks:

A collector is a software or hardware component of a SIEM platform that collects and normalizes events from various sources, and then delivers these events to the platform’s core. If detection is configured on a collector, the model processes all events associated with various processes loading libraries, provided these events meet the following conditions:

• The path to the process file is known.
• The path to the library is known.
• The hashes of the file and the library are available.

This method consumes more resources, and the model’s response takes longer than it does on a correlator. However, it can be useful for retrospective threat hunting because it allows you to check all events logged by Kaspersky SIEM. The model’s workflow on a collector looks like this:

It is important to note that the model is not limited to a binary “malicious/non-malicious” assessment; it ranks its responses by confidence level. This allows it to be used as a flexible tool in SOC practice. Examples of possible verdicts:

• 0: data is being processed.
• 1: maliciousness not confirmed. This means the model currently does not consider the library malicious.
• 2: suspicious library.
• 3: maliciousness confirmed.

A Kaspersky SIEM rule for detecting DLL hijacking would look like this:
N.KL_AI_DLLHijackingCheckResult > 1
Embedding the model into the Kaspersky SIEM correlator automates the process of finding DLL-hijacking attacks, making it possible to detect them at scale without having to manually analyze hundreds or thousands of loaded libraries. Furthermore, when combined with correlation rules and telemetry sources, the model can be used not just as a standalone module but as part of a comprehensive defense against infrastructure attacks.

Incidents detected during the pilot testing of the model in the MDR service

Before being released, the model (as part of the Kaspersky SIEM platform) was tested in the MDR service, where it was trained to identify attacks on large datasets supplied by our telemetry. This step was necessary to ensure that detection works not only in lab settings but also in real client infrastructures.

During the pilot testing, we verified the model’s resilience to false positives and its ability to correctly classify behavior even in non-typical DLL-loading scenarios. As a result, several real-world incidents were successfully detected where attackers used one type of DLL hijacking — the DLL Sideloading technique — to gain persistence and execute their code in the system.

Let us take a closer look at the three most interesting of these.

Incident 1. ToddyCat trying to launch Cobalt Strike disguised as a system library

In one incident, the attackers successfully leveraged the vulnerability CVE-2021-27076 to exploit a SharePoint service that used IIS as a web server. They ran the following command:
c:\windows\system32\inetsrv\w3wp.exe -ap "SharePoint - 80" -v "v4.0" -l "webengine4.dll" -a \\.\pipe\iisipmd32ded38-e45b-423f-804d-34471928538b -h "C:\inetpub\temp\apppools\SharePoint - 80\SharePoint - 80.config" -w "" -m 0
After the exploitation, the IIS process created files that were later used to run malicious code via the DLL sideloading technique (T1574.001 Hijack Execution Flow: DLL):
C:\ProgramData\SystemSettings.exe
C:\ProgramData\SystemSettings.dll
SystemSettings.dll is the name of a library associated with the Windows Settings application (SystemSettings.exe). The original library contains code and data that the Settings application uses to manage and configure various system parameters. However, the library created by the attackers has malicious functionality and is only pretending to be a system library.

Later, to establish persistence in the system and launch a DLL sideloading attack, a scheduled task was created, disguised as a Microsoft Edge browser update. It launches a SystemSettings.exe file, which is located in the same directory as the malicious library:
Schtasks /create /ru "SYSTEM" /tn "\Microsoft\Windows\Edge\Edgeupdates" /sc DAILY /tr "C:\ProgramData\SystemSettings.exe" /F
The task is set to run daily.

When the SystemSettings.exe process is launched, it loads the malicious DLL. As this happened, the process and library data were sent to our model for analysis and detection of a potential attack.

Example of a SystemSettings.dll load event with a DLL Hijacking module verdict in Kaspersky SIEM

The resulting data helped our analysts highlight a suspicious DLL and analyze it in detail. The library was found to be a Cobalt Strike implant. After loading it, the SystemSettings.exe process attempted to connect to the attackers’ command-and-control server.
DNS query: connect-microsoft[.]com
DNS query type: AAAA
DNS response: ::ffff:8.219.1[.]155;
8.219.1[.]155:8443
After establishing a connection, the attackers began host reconnaissance to gather various data to develop their attack.
C:\ProgramData\SystemSettings.exe
whoami /priv
hostname
reg query HKLM\SOFTWARE\Microsoft\Cryptography /v MachineGuid
powershell -c $psversiontable
dotnet --version
systeminfo
reg query "HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware Drivers"
cmdkey /list
REG query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v PortNumber
reg query "HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Servers
netsh wlan show profiles
netsh wlan show interfaces
set
net localgroup administrators
net user
net user administrator
ipconfig /all
net config workstation
net view
arp -a
route print
netstat -ano
tasklist
schtasks /query /fo LIST /v
net start
net share
net use
netsh firewall show config
netsh firewall show state
net view /domain
net time /domain
net group "domain admins" /domain
net localgroup administrators /domain
net group "domain controllers" /domain
net accounts /domain
nltest / domain_trusts
reg query HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
reg query HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce
reg query HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
reg query HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Run
reg query HKEY_CURRENT_USER\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\RunOnce
Based on the attackers’ TTPs, such as loading Cobalt Strike as a DLL, using the DLL sideloading technique (1, 2), and exploiting SharePoint, we can say with a high degree of confidence that the ToddyCat APT group was behind the attack. Thanks to the prompt response of our model, we were able to respond in time and block this activity, preventing the attackers from causing damage to the organization.

Incident 2. Infostealer masquerading as a policy manager

Another example was discovered by the model after a client was connected to MDR monitoring: a legitimate system file located in an application folder attempted to load a suspicious library that was stored next to it.
C:\Program Files\Chiniks\SettingSyncHost.exe
C:\Program Files\Chiniks\policymanager.dll E83F331BD1EC115524EBFF7043795BBE
The SettingSyncHost.exe file is a system host process for synchronizing settings between one user’s different devices. Its 32-bit and 64-bit versions are usually located in C:\Windows\System32\ and C:\Windows\SysWOW64\, respectively. In this incident, the file location differed from the normal one.

Example of a policymanager.dll load event with a DLL Hijacking module verdict in Kaspersky SIEM

Analysis of the library file loaded by this process showed that it was malware designed to steal information from browsers.

Graph of policymanager.dll activity in a sandbox

The file directly accesses browser files that contain user data.
C:\Users\<user>\AppData\Local\Google\Chrome\User Data\Local State
The library file is on the list of files used for DLL hijacking, as published in the HijackLibs project. The project contains a list of common processes and libraries employed in DLL-hijacking attacks, which can be used to detect these attacks.

Incident 3. Malicious loader posing as a security solution

Another incident discovered by our model occurred when a user connected a removable USB drive:

Example of a Kaspersky SIEM event where a wsc.dll library was loaded from a USB drive, with a DLL Hijacking module verdict

The connected drive’s directory contained hidden folders with an identically named shortcut for each of them. The shortcuts had icons typically used for folders. Since file extensions were not shown by default on the drive, the user might have mistaken the shortcut for a folder and launched it. In turn, the shortcut opened the corresponding hidden folder and ran an executable file using the following command:
"%comspec%" /q /c "RECYCLER.BIN\1\CEFHelper.exe [$DIGITS] [$DIGITS]"
CEFHelper.exe is a legitimate Avast Antivirus executable that, through DLL sideloading, loaded the wsc.dll library, which is a malicious loader.

Code snippet from the malicious file

The loader opens a file named AvastAuth.dat, which contains an encrypted backdoor. The library reads the data from the file into memory, decrypts it, and executes it. After this, the backdoor attempts to connect to a remote command-and-control server.

The library file, which contains the malicious loader, is on the list of known libraries used for DLL sideloading, as presented on the HijackLibs project website.

Conclusion

Integrating the model into the product provided the means of early and accurate detection of DLL-hijacking attempts which previously might have gone unnoticed. Even during the pilot testing, the model proved its effectiveness by identifying several incidents using this technique. Going forward, its accuracy will only increase as data accumulates and algorithms are updated in KSN, making this mechanism a reliable element of proactive protection for corporate systems.

IoC

Legitimate files used for DLL hijacking
E0E092D4EFC15F25FD9C0923C52C33D6 loads SystemSettings.dll
09CD396C8F4B4989A83ED7A1F33F5503 loads policymanager.dll
A72036F635CECF0DCB1E9C6F49A8FA5B loads wsc.dll

Malicious files
EA2882B05F8C11A285426F90859F23C6 SystemSettings.dll
E83F331BD1EC115524EBFF7043795BBE policymanager.dll
831252E7FA9BD6FA174715647EBCE516 wsc.dll

Paths
C:\ProgramData\SystemSettings.exe
C:\ProgramData\SystemSettings.dll
C:\Program Files\Chiniks\SettingSyncHost.exe
C:\Program Files\Chiniks\policymanager.dll
D:\RECYCLER.BIN\1\CEFHelper.exe
D:\RECYCLER.BIN\1\wsc.dll

securelist.com/detecting-dll-h…

Airbags are an incredibly important piece of automotive safety gear. They’re also terrifying—given that they’re effectively small pyrotechnic devices that are aimed directly at your face and chest. Myths have pervaded that they “kill more people than they save,” in part due a hilarious episode of The Simpsons. Despite this, they’re credited with saving tens of thousands of lives over the years by cushioning fleshy human bodies from heavy impacts and harsh decelerations.

While an airbag is generally there to help you, it can also hurt you in regular operation. The immense sound pressure generated when an airbag fires is not exactly friendly to your ears. However, engineers at Mercedes-Benz have found a neat workaround to protect your hearing from the explosive report of these safety devices. It’s a nifty hack that takes advantage of an existing feature of the human body. Let’s explore how air bags work, why they’re so darn loud, and how that can be mitigated in the event of a crash.

A Lot Of Hot Air

The first patent for an airbag safety device was filed over 100 years ago, intended for use in aircraft. Credit: US Patent Office
Once an obscure feature only found in luxury vehicles, airbags became common safety equipment in many cars and trucks by the mid-1990s. Indeed, a particular turning point was when they became mandatory in vehicles sold in the US market from late 1998 onwards, which made them near-universal equipment in many other markets worldwide. Despite their relatively recent mainstream acceptance, the concept of the airbag actually dates back a lot farther.

The basic invention of the airbag is typically credited to two English dentists—Harold Round and Arthur Parrott—who submitted a patent for the concept all the way back in 1919. The patent regarded the concept of creating an air cushion to protect occupants in aircraft during serious impacts. Specific attention was given to the fact that the air cushion should “yield readily without developing the power to rebound,” which could cause further injury. This was achieved by giving the device air outlet passages that would vent as a person impacted the device, which would allow the cushion to absorb the hit gently while reducing the chance of injury.

The concept only later became applicable to automobiles when Walter Linderer filed for a German patent in 1951, and John W. Hetrick filed for a US patent in 1952. Both engineers devised airbags that were based on the release of compressed air, triggered either by human intervention or automated mechanical means. These concepts proved ultimately infeasible, as compressed air could not be feasibly be released to inflate an airbag quickly enough to be protective in an automobile crash.

It would only be later in the 1960s that workable versions using explosive or pyrotechnic inflation came to the fore. The concept was simple—use a chemical reaction to generate a great deal of gas near-instantaneously, inflating the airbag fractions of a second before vehicle occupants come into contact with the device. The airbags are fitted with vents that only allow the gas to escape slowly. This means that as a person hits the airbag, they are gently decelerated as their impact pushes the gas out of the restrictive vents. This helps reduce injuries that would typically be incurred if the occupants instead hit interior parts of the car without any protection at all.
In a crash, it’s much nicer to faceplant into an air-filled pillow than a hard, unforgiving dashboard. Credit: DaimlerChrysler AG, CC BY SA 3.0

The Big Bang

The use of pyrotechnic gas generators to inflate airbags was the leap forward that made airbags practical and effective for use in automobiles. However, as you might imagine, releasing a massive burst of gas in under 50 milliseconds does create a rather large pressure wave—which we experience as an incredibly loud sound. If you ever seen airbags detonated outside of a vehicle, you’ve probably noticed they sound rather akin to fireworks or a gun going off. Indeed, the sound of an airbag can exceed 160 decibels (dB)—more than enough to cause instant damage to the ear. Noise generated in a vehicle impact is often incredibly loud, too, or course. Ultimately, this isn’t great for the occupants of the vehicle, particularly their hearing. Ultimately, an airbag deployment is a carefully considered trade-off—the general consensus is that impact protection in a serious crash is preferable, even if your ears are worse for wear afterwards.

However, there is atechnique that can mitigate this problem. In particular, Mercedes-Benz developed a system to protect the hearing of vehicle occupants in the event that the airbags are fired. The trick is in using the body’s own reactions to sound to reduce damage to the ear from excessive sound pressure levels.
In humans, the stapedius muscle can be triggered reflexively to protect the ear from excess sound levels, though the mechanism is slow enough that it can’t respond well to sudden loud impulses. However, pre-emptively triggering it before a loud event can be very useful. Credit: Mercedes Benz
The stapedius reflex (also known as the acoustic reflex) is one of the body’s involuntary, instantaneous movements in response to an external stimulus—in this case, certain sound levels. When a given sound stimulus occurs to either ear, muscles inside both ears contract, most specifically the stapedius muscle in humans. When the muscle contracts, it has a stiffening effect on the ossicular chain—the three tiny bones that connect the ear drum to the cochlea in the inner ear. Under this condition, less vibrational energy is transferred, reducing damage to the cochlea from excessive sound levels.

The threshold at which the reflex is triggered is usually 10 to 20 dB lower than the point at which the individual feels discomfort; typical levels are from around 70 to 100 dB. When triggered by particularly loud sounds of 20 dB above the trigger threshold, the muscle contraction is enough to reduce the sound level at the cochlea by a full 15 dB. Notably, the reflex is also triggered by vocalization—reducing transmission through to the inner ear when one begins to speak.

Mercedes-Benz engineers realized that the stapedius reflex could be pre-emptively triggered ahead of firing the airbags, in order to provide a protective effect for the ears. To this end, the company developed the PRE-SAFE Sound system. When the vehicle’s airbag control unit detects a collision, it triggers the vehicle’s sound system to play a short-duration pink noise signal at a level of 80 dB. This is intended to be loud enough to trigger the stapedius reflex without in itself doing damage to the ears. Typically, it takes higher sound levels closer to 100 dB to reliably trigger the reflex in a wide range of people, but Mercedes-Benz engineers realized that the wide-spread frequency content of pink noise enable the reflex to be switched on at a much lower, and safer, sound level. With the reflex turned on, when the airbags do fire a fraction of a second later, less energy from the intense pressure spike will be transferred to the inner ear, protecting the delicate structures that provide the sense of hearing.

youtube.com/embed/vTmLYY-Z2rc?…

Mercedes-Benz first released the technology in production models almost a decade ago.

The stapedius reflex does have some limitations. It can be triggered with a latency of just 10 milliseconds, however, it can take up to 100 milliseconds for the muscle in the ear to reach full tension, conferring the full protective effect. This limits the ability of the reflex to protect against short, intense noises. However, given the Mercedes-Benz system triggers the sound before airbag inflation where possible, this helps the muscles engage prior to the peak sound level being reached. The protective effect of the stapedius reflex also only lasts for a few seconds, with the muscle contraction unable to be maintained beyond this point. However, in a vehicle impact scenario, the airbags typically all fire very quickly, usually well within a second, negating this issue.

Mercedes-Benz was working on the technology from at least the early 2010s, having run human trials to trigger the stapedius reflex with pink noise in 2011. It deployed the technology on its production vehicles almost a decade ago, first offering PRE-SAFE Sound on E-Class models for the 2017 model year. Despite the simple nature of the technology, few to no other automakers have publicly reported implementing the technique.

Car crashes are, thankfully, rather rare. Few of us are actually in an automobile accident in any given year, even less in ones serious enough to cause an airbag deployment. However, if you are unlucky enough to be in a severe collision, and you’re riding in a modern Mercedes-Benz, your ears will likely thank you for the added protection, just as your body will be grateful for the cushioning of the airbags themselves.

hackaday.com/2025/10/06/how-me…

We’ve covered plenty of interesting human input devices over the years, but how about an instrument? No, not as a MIDI controller, but to interact with what’s going on-on screen. That’s the job of GuitarPie, a guitar-driven pie menu produced by a group at the University of Stuttgart.

The idea is pretty simple: the computer is listening for one specific note, which cues the pie menu on screen. Options on the pie menu can be selected by playing notes on adjacent strings and frets. (Check it out in action in the video embedded below). This is obviously best for guitar players, and has been built into a tablature program they’re calling TabCTRL. For those not in the loop, tablature, also known as tabs, is an instrument-specific notation system for stringed instruments that’s quite popular with guitar players. So TabCTRL is a music-learning program, that shows how to play a given song.

With this pairing, you can rock out to the tablature, the guitarist need never take their hands off the frets. You might be wondering “how isn’t the menu triggered during regular play”? Well, the boffins at Stuttgart thought of that– in TabCTRL, the menu is locked out while play mode is active. (It keeps track of tempo for you, too, highlighting the current musical phrase.) A moment’s silence (say, after you made a mistake and want to restart the song) stops play mode and you can then activate the menu. It’s well a well-thought-out UI. It’s also open source, with all the code going up on GitHub by the end of October.

The neat thing is that this is pure software; it will work with any unmodified guitar and computer. You only need a microphone in front of the amp to pick up the notes. One could, of course, use voice control– we’ve seen no shortage of hacks with that–but that’s decidedly less fun. Purists can comfort themselves that at least this time the computer interface is a real guitar, and not a guitar-shaped MIDI controller.

youtube.com/embed/ItJGNO-IQDw?…

hackaday.com/2025/10/06/guitar…

The Czech Pirate Party won 18 seats in the October 2025 election for Parliament!

Unfortunately, the main winner of the election was the populist billionaire and former prime minister Andrej Babiš and his ANO movement. He has expressed skepticism toward support for Ukraine and has drawn closer to authoritarian leaders such as Viktor Orbán in Hungary. The Czech Pirates run on a diametrically opposed platform. The overall result of 8.7% of the vote makes them the 3rd largest party in the country. While the success is not quite as monumental as when they won 22 seats in 2017. It does represent a vast improvement from just 4 seats that the the Pirates won in 2021. In that year they ran in the Pirates and Mayors (STAN) alliance. That alliance won 37 seats in total. The Pirates ran independently this year after separating from STAN.

The Czech Pirate Party is a member of Pirate Parties International. We appreciate the strong support they provide internationally, and we wish them good luck with their upcoming term!

pp-international.net/2025/10/c…

The GOP wants to shutdown the federal government.

It is true that Congress failed to pass a 2026 appropriation bill. The GOP controlled House passed an extension spending bill, but it did not pass in the Senate. It failed in the Senate because it did not have the 60 votes needed to close debate (i.e. cloture) and the Democrats were not willing to provide those votes without changes such as rolling back the GOP’s increase in health insurance premiums for Affordable Care Act recipients or blocking Trump’s unconstitutional efforts to not spend money Congress has already appropriated.

Requiring 60 votes to close debate is a Senate rule that can be changed by a simple majority vote in the Senate. There is nothing in the constitution that requires it. The GOP majority in the Senate could change the rule to close debate with a majority and pass their appropriations extension.

They choose not to. It allows GOP office holders to blame anyone, except themselves. The corporate media parrot their lies.

The GOP wants the federal government shutdown.

I am not talking about the changes in the bill. It is awful, of course, and would continue to let Trump use ICE to illegally round up people in apartment buildings, whether citizens, or immigrants documented or not. Trump could still force national guard members to illegally act like police in cities in other states. Trump has already laid off 12% of federal all workers and the bill would continue to let him illegally hold back billions of dollars Congress appropriated. Billions that should be given to clean energy projects, state transportation projects, VA benefits and needed medical research.

The GOP wants the federal government shutdown.

They want millions of federal workers to suffer from being furloughed unable to provide needed government services. They want us to face uncertainty and loss because those services are not available or require us to waste even more of our time to access them.

Since Trump was inaugurated the GOP has sought a federal government shutdown. Through the DOGEbros, they started their government shutdown as they held back funding and pushed illegal layoffs. The cost has been high to the rest of us. The economy and hiring has flatlined. Prices increased.

They don’t care.

The GOP wants the federal government shutdown and they will use any tool they have to make it happen.

Vote Pirate!

masspirates.org/blog/2025/10/0…

Steve, Joe and James discuss HorizonMass/BINJ effort to use public records requests to determine if the drones over the Boston Dominican Parade and Caribbean Carnival were owned by the Boston Police Department. We also discussed the Trump administration’s recent efforts to censor free speech and an ex-Florida sheriff’s deputy attempt to spread disinformation from Russia.

youtube.com/embed/rHy8jXfhQVw?…

Sign up to our newsletter to get notified of new events or volunteer. Join us on:

• Mastodon;
• Facebook;
• Blue Sky;
• Twitter.

Some links we mentioned:

• Our Administrative Coup Memory Bank;
• Our Things to Do when Fascists are Taking Over;
• Did The BPD Fly A Surveillance Drone Over The Dominican Parade? They Won’t Tell Us.
• Disney Plus Subscribers Quit in Droves Over Jimmy Kimmel Axe;
• 2025 shootings of Minnesota legislators;
• Russian fake-news network, led by an ex-Florida sheriff’s deputy, storms back into action with 200+ new sites.

Image Credit: CC-By-2.0 image via Wikipedia Commons by Maurizio Pesce.

uspirates.org/mass-pirate-news…