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.
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.
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.
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.
Se n’è parlato molto poco di questo avvenimento, che personalmente reputo strategicamente molto importante e segno di un forte cambiamento nella gestione delle vulnerabilità non documentate in Italia.
A marzo 2024 scrissi un articolo in cui descrivevo un panorama italiano pressoché desolante: la cultura dei bug non documentati, gli zero-day, era praticamente inesistente, e non c’era alcuna CNA (CVE Numbering Authority) attiva nel nostro paese.
La gestione delle vulnerabilità spesso è lasciata al caso o, peggio, nascosta dietro un velo di segretezza e incapace di creare un dialogo con la comunità dei ricercatori. Quel pezzo, pubblicato su Red Hot Cyber, rimbalzò sui social e suscitò molte reazioni – sinonimo che qualcosa stava cambiando – ma allora pochi potevano immaginare che avrebbe prefigurato un cambiamento reale.
L’approccio italiano e il cambiamento
L’approccio prevalente in Italia tra i produttori di software è spesso caratterizzato dalla mancanza di conoscenza delle pratiche di gestione delle vulnerabilità non documentate, oppure dalla scelta della “security by obscurity“, nella convinzione che nascondere i bug possa garantire sicurezza.
Questo modello, sebbene diffuso, è intrinsecamente fragile: ignora la realtà della cybersicurezza contemporanea, in cui ogni vulnerabilità non gestita rappresenta una porta aperta per attacchi mirati, sofisticati e sempre più frequenti.
Infatti, la cultura dell’oscurità, ha spesso significato di trascuratezza, lentezza nella risposta e, in ultima analisi, rischi concreti per cittadini, istituzioni e clienti fino ad arrivare alla sicurezza nazionale.
Oggi, finalmente, le cose stanno cambiando. Da settembre 2024, due grandi realtà italiane, Almaviva e Leonardo, sono diventate ufficialmente CNA.
Questo significa che possono assegnare identificativi CVE alle vulnerabilità che scoprono o gestiscono tramite la community hacker, entrando così in un circuito internazionale di sicurezza responsabile. Non è un dettaglio tecnico: è la dimostrazione che l’Italia sta iniziando a prendere sul serio le vulnerabilità non documentate e a strutturare processi di sicurezza coerenti con gli standard globali. Immagine presa da cve.org al 06/10/2025
Coordinated Vulnerability Disclosure: la chiave di volta
La transizione non riguarda solo la scoperta dei bug, ma il modo stesso in cui la sicurezza viene concepita. La CVD (Coordinated Vulnerability Disclosure)diventa lo strumento attraverso cui le aziende collaborano con i ricercatori, condividono informazioni in sicurezza e risolvono le problematiche senza lasciare spazio a sfruttamenti malevoli prima del rilascio delle patch. La CVD è, in pratica, quel ponte tra la scoperta delle vulnerabilità e la gestione responsabile, un principio che fino a poco tempo fa sembrava quasi utopico nel contesto italiano.
Ciò che impressiona è come questo nuovo approccio dimostri che trasparenza, etica e collaborazione non sono ostacoli al business, ma fattori che lo rafforzano.
Gestire i bug in modo aperto riduce drasticamente i rischi di attacco, migliora la reputazione aziendale e crea fiducia nei clienti e nei partner. L’Italia sta imparando che la sicurezza non è un valore accessorio, ma un fattore abilitante che può generare valore tangibile. Questo è il risultato anche di un lento ma significativo cambiamento nella cultura della sicurezza informatica in Italia, sostenuto dagli sforzi dell’Agenzia per la Cybersicurezza Nazionale (ACN), che, con costanza e determinazione, sta tracciando un percorso di maggiore consapevolezza e professionalità nel settore.
L’eredità dell’Open Source e la “destinazione”
Se guardiamo all’esperienza dell’open source, troviamo un modello consolidato: i progetti open prosperano grazie alla collaborazione e alla condivisione delle conoscenze. Bug, patch e miglioramenti diventano patrimonio comune e l’intera comunità beneficia dei risultati. La lezione è chiara: soprattutto nella sicurezza informatica, la cooperazione non è un rischio, ma una risorsa preziosa, capace di trasformare potenziali minacce in opportunità di crescita.
Spesso ho sottolineato un concetto chiave: ‘l’hacking è un percorso, non una destinazione’. Per le aziende italiane, il passaggio dalla mancanza di cultura sugli zero-day, o peggio dalla security by obscurity, a una gestione aperta e responsabile delle vulnerabilità non è solo un atto tecnico: è un vero e proprio percorso di crescita, un cambiamento culturale profondo che richiede visione, consapevolezza e apertura al dialogo con la comunità dei ricercatori.
Significa accettare che la sicurezza non può essere trattata come un segreto commerciale, ma come un impegno condiviso verso la comunità, i clienti e la società nel suo complesso. Richiede coraggio, visione e leadership, ma apre la strada a ecosistemi digitali più resilienti e sostenibili.
Due CNA italiane: un impegno concreto al cambiamento
Almaviva e Leonardo mostrano concretamente la via: non solo riconoscono la responsabilità verso i propri clienti, ma valorizzano il ruolo etico dei ricercatori indipendenti e della comunità hacker e adottando standard e processi che possano consentire una gestione delle vulnerabilità non documentate.
Questo modello dimostra che trasparenza e collaborazione non sono incompatibili con la competitività, ma anzi la rafforzano, trasformando il rischio in un’opportunità di innovazione continua e miglioramento del prodotto.
Il nuovo corso italiano riflette anche un cambiamento di mentalità più ampio: la sicurezza non è solo tecnica, ma sociale, culturale ed etica. La gestione responsabile delle vulnerabilità richiede dialogo, fiducia e cooperazione tra aziende, ricercatori e comunità, principi che costituiscono il fondamento di un ecosistema digitale sano e sostenibile.
Il percorso è ancora lungo, e la strada per diffondere CNA e CVD in tutte le aziende italiane è appena iniziata. Ma il fatto che oggi possiamo contare su due CNA ufficiali rappresenta un cambiamento concreto, la prima traccia di un nuovo paradigma.
E un sogno nel cassetto
Nonostante i passi avanti compiuti, oggi l’Italia e tutta l’Europa continuano a fare affidamento sui processi degli Stati Uniti per la gestione delle vulnerabilità: dal National Vulnerability Database (NVD) alle autorità di numerazione CNA, è il modello statunitense a dettare gli standard globali.
Anche se esiste un progetto europeo, il European Vulnerability Database (EUVD)gestito da ENISA, questo rimane ancora embrionale e lontano dall’avere un modello di classificazione delle vulnerabilità strutturato come quello statunitense sviluppato da MITRE e NIST.
In un’ottica di autonomia strategica europea, sarebbe auspicabile sviluppare un sistema simile a quello statunitense, che integri numerazione, valutazione del rischio e gestione coordinata delle vulnerabilità. Un modello che già esiste in Cina con il CNNVD, il repository nazionale che affianca numerazione e processi di valutazione dei rischi, dimostrando come un approccio nazionale (ed europeo) possa garantire controllo, coerenza e tempestività nella gestione dei bug critici.
Il sogno, quindi, è vedere un sistema europeo maturo e indipendente, in cui ENISA possa gestire un modello europeo della classificazione e gestione dei bug non documentati, con standardchiari, processi di valutazione del rischio condivisi e un repository trasparente accessibile a ricercatori, aziende e istituzioni. Non sarebbe solo un atto tecnico: rappresenterebbe un salto culturale e strategico per tutta la comunità di sicurezza informatica, un segnale che l’Europa vuole costruire autonomia nella cybersicurezza, valorizzare la collaborazione con la comunità hacker e proteggere i cittadini con strumenti propri, moderni e affidabili.
Fino ad allora, ogni passo compiuto dalle aziende italiane, ogni CNA istituita e ogni CVD gestita responsabilmente resta un piccolo ma fondamentale tassello di questo lungo percorso: un percorso che conduce dalla dipendenza dagli altri verso una sicurezza consapevole, etica e autonoma.
I dati sono il sangue dell’intelligenza artificiale. È così che Nello Cristianini parla del motore dell’IA. Per intendere che sono i dati la materia grezza da cui la macchina estrae le proprie predizioni e decisioni. Il professore italiano che insegna intelligenza artificiale all’Università di Bath lo dice in Datacrazia. Politica, cultura, algoritmica e conflitti al tempo dei big data (d editore) un libro del 2018, precedente alla sua famosa trilogia per i tipi de Mulino: La scorciatoia (2023), Machina Sapiens (2024) e Sovrumano (2025), sollevando una questione su cui non sembra avere cambiato idea. O, almeno per quanto riguarda il valore dei dati, che devono essere precisi e affidabili, per consentire alle macchine di «pensare». Pensare come preconizzato da Turing, e cioè nel senso di macchine in grado di simulare un comportamento intelligente, come poi si riveleranno capaci di fare, senza ritenere però che sia lo stesso «pensare» degli esseri umani.
Il libro che è una raccolta collettanea a cura di Daniela Gambetta, e affronta i risvolti socio-politici della gestione dei dati – dalla produzione creativa digitale all’incetta che ne fanno i social network – per arrivare e metterci in guardia dai bias presenti nell’addestramento dell’IA. Timori che hanno già avuto una certa attenzione ma che non sono ancora studiati abbastanza. Ed è per questo che nella parte in cui il libro se ne occupa è possibile affermare che i contributori al libro siano stati capaci di deinire un framework interpretativo critico dell’innovazione che può essere una guida nell’analisi delle tecnologie di rete, indipendentemente dall’attualità delle soluzioni sviluppate proprio nell’IA.
Alla data del libro per esempio, il campione Gary Kasparov era stato già battuto a scacchi da un sistema di machine learning e lo stesso era accaduto a Lee Sedol nel gioco del GO; il chatbot Tay di Facebook era stato già avvelenato nei suoi dati di addestramento dall’esercito di troll su Twitter fino a congratularsi con Hitler, ma ChatGPT era ancora da venire. E, tuttavia le questioni etiche poste dal libro sono ancora irrisolte. Chi decide cosa è bene e cosa è male? La macchina o l’uomo? Viene facile dire l’uomo che la governa, ma cosa accade con i sistemi autonomi che non prevedono l’intervento umano? Ecco, Datacrazia pone quei temi, sociali e filosofici su cui ci interroghiamo ancora oggi: dalla sovranità digitale alle fake news potenziate dall’IA.
S/PDIF has been around for a long time; it’s still a really great way to send streams of digital audio from device A to device B. [Nathan Ladwig] has got the ESP32 decoding SPDIF quite effectively, using an onboard peripheral outside its traditional remit.
On the ESP32, the Remote Control Transceiver (RMT) peripheral was intended for use with infrared transceivers—think TV remotes and the like. However, this peripheral is actually quite flexible, and can be used for sending and receiving a range of different signals. [Nathan] was able to get it to work with S/PDIF quite effectively. Notably, it has no defined bitrate, which allows it to work with signals of different sample rates quite easily. Instead, it uses biphase mark code to send data. With one or two transitions for each transmitted bit, it’s possible to capture the timing and determine the correct clock from the signal itself.
[Nathan] achieved this feat as part of his work to create an ESP32-based RTP streaming device. The project allows an ESP32 to work as a USB audio device or take an S/PDIF signal as input, and then transmitting that audio stream over RTP to a receiver which delivers the audio at the other end via USB audio or as an SPDIF output. It’s a nifty project that has applications for anyone that regularly finds themselves needing to get digital audio from once place to another. It can also run a simple visualizer, too, with some attached LEDs.
It’s not the first time we’ve seen S/PDIF decoded on a microcontroller; it’s quite achievable if you know what you’re doing. Meanwhile, if you’re cooking up your own digital audio hacks, we’d love to hear about it. Digitally, of course, because we don’t accept analog phone calls here at Hackaday. Video after the break.
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.
Status
Total
Unique files
Unknown
~ 18M
~ 6M
Malicious
~ 50K
~ 1,000
Clean
~ 20M
~ 250K
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:
We took a data stream and extracted a frequency description for selected sets of keys.
We took the same data stream from a different time period and obtained a set of features.
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.
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.
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
It takes quite a bit of effort to get a 0 out of 10 repairability score from iFixit, but in-ears like Apple’s AirPods are well on course for a clean streak there, with the AirPod Pro 3 making an abysmal showing in their vitriolic teardown video alongside their summary article. The conclusion is that while they are really well-engineered devices with a good feature set, the moment the battery wears out it is effectively e-waste. The inability to open them without causing at least some level of cosmetic damage is bad, and that’s before trying to glue the device back together. Never mind effecting any repairs beyond this.
Worse is that this glued-together nightmare continues with the charging case. Although you’d expect to be able to disassemble this case for a battery swap, it too is glued shut to the point where a non-destructive entry is basically impossible. As iFixit rightfully points out, there are plenty of examples of how to do it better, like the Fairbuds in-ears. We have seen other in-ears in the past that can have some maintenance performed without having to resort to violence, which makes Apple’s decisions here seem to be on purpose.
Although in the comments to the video there seem to be plenty of happy AirPod users for whom the expected 2-3 year lifespan is no objection, it’s clear that the AirPods are still getting zero love from the iFixit folk.
Seacom, operatore africano di infrastrutture sottomarine, ha annunciato il lancio di Seacom 2.0, un sistema di cavi internazionali progettato per collegare Europa, Medio Oriente, Africa e Asia.
Il progetto prevede un tracciato lungo 25.000 chilometri (15.534 miglia), dotato di 48 coppie di fibre ottiche, con 20 punti di atterraggio distribuiti in 15 paesi.
Secondo la società, il nuovo cavo risponde alla domanda crescente di servizi per l’intelligenza artificiale, il cloud e il trasferimento di dati in tempo reale. Seacom dichiara che la rete potrebbe ridurre i costi di connettività fino al 300%, favorendo lo sviluppo di servizi cloud, fintech e dell’ecosistema tecnologico regionale. Il percorso pianificato ha inizio a Marsiglia (Francia); attraversa il Mar Mediterraneo e il Mar Rosso prima di diramarsi in due rami: il primo prosegue verso est fino a Singapore, attraversando India e Pakistan; il secondo serve le coste del Nordafrica, dell’Africa occidentale e dell’Africa meridionale.
Nel comunicato ufficiale il CEO Alpheus Mangale ha definito Seacom 2.0 come “più di un semplice cavo“, sottolineando che l’iniziativa intende consolidare la sovranità digitale della regione e promuovere accesso aperto e integrazione regionale. L’azienda indica come obiettivo la creazione di una rete resiliente, sostenibile e inclusiva.
Dal punto di vista tecnico, Seacom 2.0 è concepito come una infrastruttura ad alta capacità e bassa latenza ottimizzata per i carichi di lavoro dell’intelligenza artificiale. È prevista la trasformazione delle stazioni di atterraggio in veri e propri “nodi di comunicazione dell’intelligenza artificiale”, volti a collegare l’infrastruttura AI sovrana africana ai data center globali.
Il progetto include obiettivi strategici economici e operativi: stimolare la crescita del PIL – sulla scia dell’impatto positivo già osservato da precedenti cavi sottomarini, che hanno contribuito a incrementare il PIL pro capite africano di oltre il 6% – supportare infrastrutture intelligenti (porti abilitati all’IoT, pianificazione urbana basata su AI, edge computing) e potenziare le piccole e medie imprese con connettività di livello aziendale per l’accesso al cloud e ai mercati digitali.
Seacom 2.0 si poggia sulla rete esistente dell’operatore, avviata nel 2009 in collaborazione con Tata Communications. Seacom gestisce stazioni di atterraggio lungo la costa orientale dell’Africa e detiene capacità su principali sistemi internazionali come WACS, TEAMS, EASSy, Main One, Equiano e Peace. Tra gli investitori figurano Industrial Promotion Services (Aga Khan Fund for Economic Development), Remgro, Solcon Capital e Sanlam.
L’annuncio richiama inoltre proiezioni macro: Seacom posiziona Seacom 2.0 in previsione di 10 miliardi di agenti di intelligenza artificiale entro il 2030 e della crescita demografica prevista per il bacino dell’Oceano Indiano, che secondo le stime ospiterà metà della popolazione mondiale entro il 2050.
Some things are more fun when there are more folks involved, and enjoying time in the pool is one of those activities. Knowing this, [Bert Wagner] started thinking of ways to best coordinate pool activities with his kids and their neighborhood friends. Out of this came the Splashflag, an IoT device built from the ground up that provides fun pool parties and a great learning experience along the way.
The USB-powered Splashflag is housed in a 3D-printed case, with a simple 2×16 LCD mounted on the front to display the notification. There’s also a small servo mounted to the rear that raises a 3D-printed flag when the notification comes in—drawing your attention to it a bit more than just text alone would. Hidden on the back is also a reset button: a long press factory-resets the device to connect to a different Wi-Fi network, and a quick press clears the notification to return the device to its resting state.
Inside is an ESP32-S3 that drives the servo and display and connects to the Wi-Fi. The ESP32 is set up with a captive portal, easing the device’s connection to a wireless network. The ESP32, once connected, joins an MQTT broker hosted by [Bert Wagner], allowing easy sending of notifications via the web app he made to quickly and easily send out invitations.
Thanks, [Bert Wagner], for sharing the process of building this fun, unique IoT device—be sure to read all the details on his website or check out the code and design files available over on his GitHub. Check out some of our other IoT projects if this project has you interested in making your own.
What the Flock? It’s probably just some quirk of The Almighty Algorithm, but ever since we featured a story on Flock’s crime-fighting drones last week, we’ve been flooded with other stories about the company, some of which aren’t very flattering. The first thing that we were pushed was this handy interactive map of the company’s network of automatic license plate readers. We had no idea how extensive the network was, and while our location is relatively free from these devices, at least ones operated on behalf of state, county, or local law enforcement, we did learn to our dismay that our local Lowe’s saw fit to install three of these cameras on the entrances to their parking lot. Not wishing to have our coming and goings documented, we’ll be taking our home improvement dollars elsewhere for now.
But it’s a new feature being rolled out by Flock that really got our attention: the addition of “human distress” detection to their Raven acoustic gunshot detection system. From what we understand, gunshot detection systems use the sudden acoustic impulse generated by the supersonic passage of a bullet, the shock wave from the rapidly expanding powder charge of a fired round, or both to detect a gunshot, and then use the time-of-arrival difference between multiple sensors to estimate the shot’s point of origin. Those impulses carry a fair amount of information, but little of it is personally identifiable, at least directly. On the other hand, human voices carry a lot of personal information, and detecting the sounds of distress, such as screaming, would require very different monitoring techniques. We’d imagine it would be akin to what digital assistants use to monitor for wake words, which would mean turning the world — or at least pockets of it — into a gigantic Alex. We don’t much like the idea of having our every public utterance recorded and analyzed, even with the inevitable assurances from the company that the “non-distress” parts of the audio stream will never be listened to. Yeah, right.
Botnets are bad enough when it’s just routers or smart TVs that are exploited to mine crypto or spam comments on social media. But what if a botnet were made of, you know, actual robots? That might be something to watch out for with the announcement of a vulnerability in certain Unitree robots, including several of their humanoid robots. The vulnerability, still unpatched at the time of the Spectrum story, lies in the Bluetooth system used to set up the robots’ WiFi configuration. It sounds like an attacker can easily craft a BLE packet to become an authenticated user, after which the WiFi SSID and password fields can be used to inject arbitrary code. The fun doesn’t end there, though, since a compromised robot could then go on to infect any other nearby Unitree bots via BLE. And since Unitree seems to be staking out a market position as the leader in affordable humanoid robots, who’s to say what could happen? If you want a zombie robot apocalypse, this seems like a great way to get it.
Also from the “Bad Optics for Robots” files comes this story about a Waymo car that went just a little off course. Or rather, on course — a golf course, to be precise. Viral video shows a Waymo self-driving Jaguar creeping slowly across a golf course fairway as bemused golfers look on. But you can relax, because the robotaxi company says that this isn’t a case of their AI driving system going awry, but rather a human-driven robotaxi preparing for an event at the golf course. The company seems to think this absolves them, and perhaps it does officially and legally. But a very distinctive car that’s well-known for getting into self-driving mischief, appearing in a place one doesn’t typically associate with vehicles larger than golf carts, seems like a bad look for the company.
And finally, back in December of 2023, we dropped a link to My Mechanics’ restoration of a 1973 Datsun 240Z. He’s been making slow but steady progress on the car since then, with the most recent video covering his painstaking restoration of the rear axle and suspension. Where most car rebuild projects use as many replacement parts as possible, My Mechanics prefers to restore the original parts wherever possible. So, where a normal person might look at the chipped cooling fins on the original Z-car’s brake drums and order new ones, My Mechanics instead pulls out the TIG welder and lays up some beads to patch the broken fins. He used a similar technique to restore the severely chowdered compression fittings on the brake lines, something we’ve never seen down before. Over the top? You bet it is, but it still makes for great watching. Enjoy!
There are all kinds of air quality sensors on the market that rely on all kinds of electro-physical effects to detect gases or contaminants and report them back as a value. [lucascreator] has instead been investigating a method of determining air quality that is closer to divination than measurement—using computer vision and a trained AI model.
The system relies on an Unihiker K10—a microcontroller module based around the ESP32-S3 at heart. The chip is running a lightweight convolutional neural network (CNN) trained on 12,000 images of the sky. These images were sourced from a public dataset; they were taken in India and Nepal, and tagged with the relevant Air Quality Index at the time of capture. [lucascreator] used this data to train their model to look at an image taken with a camera attached to the ESP32 and estimate the air quality index based on what it has seen in that existing dataset.
It might sound like a spurious concept, but it does have some value. [lucascreator] cites studies where video data was used for low-cost air quality estimation—not as a replacement for proper measurement, but as an additional data point that could be sourced from existing surveillance infrastructure. Performance of such models has, in some cases, been remarkably accurate.
[lucascreator] is pragmatic about the limitations of their implementation of this concept, noting that their very compact model didn’t always perform the best in terms of determining actual air quality. The concept may have some value, but implementing it on an ESP32 isn’t so easy if you’re looking for supreme accuracy. We’ve featured some other great air quality projects before, though, if you’re looking for other ways to capture this information. Video after the break.
The idea of using the Apple II home computer for digital photography purposes may seem somewhat daft considering that this is not a purpose that they were ever designed for, yet this is the goal that [Colin Leroy-Mira] had, requiring some image decoder optimizations. That said, it’s less crazy than one might assume at first glance, considering that the Apple II was manufactured until 1993, while the Apple QuickTake digital cameras that [Colin] wanted to use for his nefarious purposes saw their first release in 1994.
These QuickTake cameras feature an astounding image resolution of up to 640×480, using 24-bit color. Using the official QuickTake software for Apple Macintosh System 7 through 9 the photographs in proprietary QTK format could be fetched for display and processing. Doing the same on an Apple II would obviously require a bit more work, not to mention adapting of the image to the limitations of the 8-bit Apple II compared to the Motorola 68K and PowerPC-based Macs that the QuickTake was designed to be used with.
Targeting the typical ~1 MHz 6502 CPU in an Apple II, the dcraw QTK decoder formed the basis for an initial decoder. Many memory and buffer optimizations later, an early conversion to monochrome and various other tweaks later – including a conversion to 6502 ASM for speed reasons – the decoder as it stands today manages to decode and render a QTK image in about a minute, compared to well over an hour previously.
Considering how anemic the Apple II is compared to even a budget Macintosh Classic II system, it’s amazing that displaying bitmap images works at all, though [Colin] reckons that more optimizations are possible.
Se sfruttate con successo, queste falle avrebbero potuto indurre l’intelligenza artificiale a rubare dati e ad altre attività dannose.
Gli esperti di Tenable affermano che le vulnerabilità hanno interessato tre diversi componenti di Gemini:
Iniezioni di prompt in Gemini Cloud Assist. Il bug ha permesso agli aggressori di compromettere servizi e risorse cloud sfruttando la capacità dello strumento di riepilogare i log estratti direttamente dai log grezzi. Ciò ha consentito loro di nascondere un prompt nell’intestazione User-Agent nelle richieste HTTP a Cloud Functions e ad altri servizi, tra cui Cloud Run, App Engine, Compute Engine, Cloud Endpoints, Cloud Asset API, Cloud Monitoring API e Recommender API.
Iniezioni di ricerca nel modello di personalizzazione della ricerca Gemini. Il problema consentiva l’iniezione di prompt e il controllo del comportamento dell’IA per rubare le informazioni memorizzate e i dati sulla posizione di un utente. L’attacco funzionava come segue: l’aggressore manipolava la cronologia delle ricerche di Chrome della vittima utilizzando JavaScript, rendendo il modello incapace di distinguere le query legittime dell’utente dai prompt iniettati esternamente.
Iniezioni indirette di prompt nello strumento di navigazione Gemini. Questa vulnerabilità potrebbe essere utilizzata per estrarre informazioni utente e dati sulla posizione memorizzati su un server esterno. Lo sfruttamento funzionava tramite una chiamata interna effettuata da Gemini per riassumere il contenuto di una pagina web. Ciò significava che l’aggressore avrebbe inserito un prompt dannoso sul proprio sito web e, quando Gemini ne avesse riassunto il contenuto, avrebbe eseguito le istruzioni nascoste dell’aggressore. I ricercatori hanno osservato che queste vulnerabilità hanno consentito di incorporare dati privati degli utenti nelle richieste dell’aggressore, senza che Gemini avesse bisogno di visualizzare link o immagini.
“Uno degli scenari di attacco più pericolosi si presenta così: un aggressore inserisce un prompt che ordina a Gemini di interrogare tutte le risorse accessibili al pubblico o di trovare errori di configurazione IAM, per poi generare un collegamento ipertestuale con questi dati sensibili”, spiegano gli esperti, citando come esempio un bug di Cloud Assist. “Questo è possibile perché Gemini ha le autorizzazioni per interrogare le risorse tramite la Cloud Asset API.”
Nel secondo caso, gli aggressori dovevano attirare la vittima su un sito web predisposto per iniettare query di ricerca dannose con prompt Gemini nella cronologia del browser dell’utente, infettandola. Quindi, quando la vittima accedeva a Gemini Search Personalization, le istruzioni degli aggressori venivano eseguite, rubando dati riservati.
Dopo aver ricevuto informazioni sulle vulnerabilità, gli specialisti di Google hanno disabilitato il rendering dei collegamenti ipertestuali nelle risposte durante il riepilogo dei log e hanno inoltre implementato ulteriori misure di protezione contro le iniezioni rapide.
“Le di Gemini Trifecta dimostrano che l’intelligenza artificiale può diventare non solo un bersaglio, ma anche uno strumento di attacco. Quando si implementa l’intelligenza artificiale, le organizzazioni non possono trascurare la sicurezza“, sottolineano i ricercatori.
Aiming for small scale, [James] began with 6 mm blue phosphor glass tube, which was formed to reference Pink Pony Club, one of Chappell Roan’s more popular songs. The glass was then filled with pure neon up to a relatively low pressure of just 8 torr. This was an intentional choice to create a more conductive lamp that would be easier to run off a battery supply. The use of pure neon also made the tubes easy to repair in the event they had a leak and needed a refill. A Midget Script gas tube power supply is used to drive the tiny tubes from DC power. In testing, the tubes draw just 0.78 amps at 11.8 volts. It’s not a light current draw, but for neon, it’s pretty good—and you could easily carry a battery pack to run it for an hour or three without issue.
If you’re not a glass blower, fear not—you can always make stuff that has a similar visual effect with some LEDs and creativity. Meanwhile, if you’ve got your own neon creations on the go—perhaps for Halloween?—don’t hesitate to light up the tipsline!
Three friends an I are going to see Chappel Roan later this week in Queens. I like her pink pony club, and have been making a variety of pink ponies lately.
I decided to make some tiny pink "pony"s that the four of us could wear as necklaces to the concert. They also could be clipped onto hats. I got the tiniest 6mm blue phosphor glass I could get my hands on and filled them to just 8 torr neon (normally 18torr at this size) so they are nice an conductive an the battery lasts longer. Pure neon fill- so I can fix em if they break.
I do have to double check the rules of forest hills. I guess I could lie an say they are LEDs :). One of my friends requested a heart tiara (I think the tour has hearts in its theme) so I made two lil ones filled for battery life :).
I sure hope we can dance with the neon as a pink pony club :)
Skateboards were organically developed in the 1940s and 1950s; 30 years would then pass before the ollie was developed, unlocking new realms for skaters dedicated to the artform. The advent of powerful batteries and motors would later make the electric skateboard a practical and (un?)fashionable method of transport in more recent years. Now, [Ivan Miranda] is pushing the cutting edge of skateboarding even further, with an entirely weird build of his own design.
The build was inspired by one-wheels, which [Ivan] considers fun but ultimately too dangerous. Most specifically, he fears crashing when the one-wheel is tilted beyond a critical angle at which the motor can restore it to a level heading. His concept was to thus create a two-wheeled board that is nonetheless controlled with the leaning interface of a one-wheel.
The frame is assembled from a combination of 3D-printed brackets and aluminium extrusion. The rider stands on a platform which rides on rollers on top of the frame, tilting it to control the drive direction of the board. Detecting the angle is handled by an Arduino Due with an MPU6050 IMU onboard. The microcontroller is then responsible for commanding the speed controller to move the board. Drive is from a brushless DC motor, hooked up to one of the wheels via a toothed belt. Power is courtesy of three power tool batteries.
Early testing showed the design to be a bit of a death trap. However, with refinement to the control system code and an improved battery setup, it became slightly more graceful to ride. [Ivan] notes that more tuning and refinement is needed to make the thing safer than a one-wheel, which was the original goal. We’ve seen some other great builds from [Ivan] before, too. Video after the break.
The counter wheel and white worm gear inside the counter. (Credit: Anthony Francis-Jones, YouTube) Recently [Anthony Francis-Jones] decided to take a closer look at the inhaler that his son got prescribed for some mild breathing issues, specifically to teardown the mechanical counter on it. Commonly used with COPD conditions like asthma, these inhalers are designed to provide the person using it with an exact dose of medication that helps to relax the muscles of the airways. Considering the somewhat crucial nature of this in the case of extreme forms of COPD, the mechanical counter that existed on older versions of these inhalers is very helpful to know how many doses you have left.
Disassembling the inhaler is very easy, with the counter section easily extracted and further disassembled. The mechanism is both ingenious and simple, featuring the counter wheel that’s driven by a worm gear, itself engaged by a ratcheting mechanism that’s progressed every time the cylinder with the medication is pushed down against a metal spring.
After the counter wheel hits the 0 mark, a plastic tab prevents it from spinning any further, so that you know for certain that the medication has run out. In the video [Anthony] speculates that the newer, counter-less inhalers that they got with the latest prescription can perhaps be harvested for their medication cylinder to refill the old inhaler, followed by resetting the mechanical counter. Of course, this should absolutely not be taken as medical advice.
04/10/2025 – Darkforums.st: “303” Rivendica Data Breach di 9 GB su Apple.com
Nelle prime ore del 4 ottobre 2025, sul forum underground Darkforums è comparsa una rivendicazione di data breach proveniente dall’utente “303” (profilo: Java Maniac, rank “GOD”, reputazione 197, registrato gennaio 2025). Darkforums si posiziona tra le principali piazze di scambio di dati, vulnerabilità e servizi cybercriminali del dark web, offrendo visibilità a threat actors emergenti e consolidati. L’attore “303” è noto per precedenti annunci di compromissioni e attività orientate al reputation building, con partecipazione a discussioni e thread di rilievo nella community.
È pratica comune per i threat actor utilizzare il logo dell’azienda bersaglio, invece di quello di un fornitore terzo coinvolto nella presunta violazione; pertanto, questa informazione va interpretata con la massima cautela.
Attualmente, non possiamo confermare l’autenticità della notizia, poiché l’organizzazione non ha ancora pubblicato un comunicato ufficiale sul proprio sito web in merito all’incidente. Le informazioni riportate provengono da fonti pubbliche accessibili su siti underground, pertanto vanno interpretate come una fonte di intelligence e non come una conferma definitiva.
Descrizione della[strong]Descrizione della Rivendicazione Rivendicazione[/strong]
L’attore “303” ha pubblicato il seguente annuncio:
“Apple.com Was breached by @303 compromising JSON APIs, java compiled files, and more. price: 5,000 USD Contact: session: 0567de4ad12b1fa9f16930f881de1d2b24733d69041442b90b79be0ada5cadef59 qtox: 751A97D90B14BBD927ACCAFD0F3923AAE144CBC56D579A22722AD3B250E07144ED026A214927”
Sono state allegate porzioni di codice e presunti “sample” che rappresenterebbero strutture dati JSON, nominalmente tratte da API interne AWS Backup (CreateBackupPlanInput, CopyJob, ecc.), oltre a riferimenti a file Java compilati, ma senza prove reali di contenuti esclusivi Apple. Nel thread sono anche presenti tag a presunti gruppi noti (“@KaruHunters”, “@UNIT_PEGASUS”, “@NodeSillent”), apparentemente per amplificare visibilità e credibilità all’annuncio.
[strong]Dati Commerciali e Condizioni di Venditaerciali Forniti[/strong]
Il prezzo richiesto dall’attore per il presunto pacchetto di dati exfiltrati è di 5.000 USD, con contatti pubblici via session e qtox. Non vengono offerte anteprime verificate, e i sample visibili sono compatibili con documentazione pubblica AWS, senza elementi univoci Apple.
Apple Inc. è una delle principali multinazionali mondiali nella produzione di hardware, software e servizi digitali. Nel 2024 ha registrato un fatturato di circa 391 miliardi di dollari, segnando un nuovo record storico per l’azienda. Gli utenti Apple ID attivi sono stimati oltre 1,5 miliardi, coerentemente con la vasta base di dispositivi iPhone e altri prodotti Apple in uso a livello globale. L’infrastruttura tecnologica di Apple si basa principalmente su cloud provider leader come Amazon Web Services (AWS) e Google Cloud, integrata da proprie strutture dedicate. Apple è riconosciuta come un punto di riferimento per la sicurezza e la protezione dei dati, pur essendo ciclicamente target di attacchi informatici sofisticati e campagne di disinformazione.
Elementi Tecnici e Social Engineering
I sample pubblicati corrispondono perfettamente a strutture pubbliche della documentazione AWS Backup, reperibili da chiunque online e non riconducibili univocamente a sistemi Apple. Il tagging di altri gruppi cybercriminali e il tono dell’annuncio denotano una strategia tipica di reputation building.
Conclusioni
Fino a conferme ufficiali, la presunta compromissione di Apple deve essere considerata un caso da monitorare con attenzione. Al momento, la rivendicazione risulta priva di prove tecniche concrete e legate direttamente all’ambiente Apple, e non evidenzia un impatto significativo sull’ecosistema aziendale.
Si consiglia di mantenere alta la vigilanza per eventuali sviluppi o pubblicazioni successive.
Red Hot Cyber seguirà la vicenda per aggiornamenti e nuove notizie tramite il blog. Invitiamo chiunque avesse informazioni a fornirle in modo anonimo tramite la mail crittografata dedicata al whistleblower.
[Tim] noticed recently that a large number of projects recreating discrete logic tend to do so with technology around 70 years old like resistor-transistor logic (RTL) or diode-transistor logic (DTL). To build something with these logic families nowadays requires an intense treasure hunt of antique components bordering on impossible and/or expensive. Rather than going down this rabbit hole he decided to invent a somewhat new logic system using analog components in this entry in our Component Abuse Challenge.
The component in question here is an analog multiplexer, which is normally used to select one of two (or several) signal lines and pass them through to an output. Unlike digital multiplexers which only pass 1s and 0s, analog multiplexers can pass analog signals since the transistors aren’t driven to saturation. He has come up with an entire system of logic gates using these components, with trickier devices like latches eventually implemented with help from a capacitor.
The first attempt at using this logic system had a small mistake in it which caused these latches to behave as oscillators instead, due to a polarity mistake. But a second attempt with simplified design and reduced component count ended up working, proving out [Tim]’s concept. Not only that but his second prototype is functioning at an impressive 15 MHz, with a possibility of an even higher clock speed in future designs. Not bad!
These days, you can buy full graphical LCD or OLED displays for just a few dollars. However, if you’re so inclined, you can actually get your own segmented LCDs made to suit your own projects. [Icoso Labs] explains how it’s done, with plenty of handy tips along the way.
There are three primary things you need to do to design a segmented LCD. First, you need to design it visually, laying out all the individual elements you want on the display. Then you need to determine how you want to split them up into segments. Some elements you’ll just want to be a single monolithic on-or-off shape, while other areas you might want to create things like seven-segment numerals for displaying numbers and so on. With that done, you also need to specify various engineering details—such as whether you want a transmissive, reflective, or transflective display, and thicknesses, colors, and other important things. Armed with all that, you can take your design to a manufacturer and get them to make a bunch for you. Often, there’s a moderately high tooling cost to start a run, but you can then turn out more examples of your design for just a few bucks apiece.
It’s a neat guide to designing something few of us have ever considered sourcing for ourselves. We’ve featured other insights into the world of segmented LCDs before, too. Video after the break.
The Zynq-7000 usage at the core of the robot controller. (Credit: Excessive Overkill, YouTube) Industrial robots like robotic arms are basically everywhere, albeit usually out of the public’s eye in factories. This also means that they get replaced and scrapped all the time, making for many opportunities to snap up an industrial robot that once cost as much as a pretty fancy car for essentially peanuts. Over the years the bloke behind the [Excessive Overkill] YouTube channel did this a lot, which also revealed the main issue with these ‘cheap’ robots: the electronics and associated software, with the manufacturer rarely going out of their way to appease to hobbyists trying to fix up one of these units, never mind for free.
That said, if you’re persistent enough, you can reverse-engineer these beasts to the point where you can develop your own controller hardware and software solution. This is exactly what was done, resulting in an open source controller, found on the ExcessiveMotion GitHub page, that should allow you to control many of these industrial robots. At the core is a Zynq-7000 hybrid FPGA-ARM SoC chip, running real-time Linux (with preemptive scheduling patch) on the SoC side and custom HDL on the FPGA side to handle the hard real-time tasks. The controller during testing. (Credit: Excessive Overkill, YouTube) The controller is made to be modular, with a backplane that can accept various interface cards in addition to the current RS-485 and RS-422 interfaces that are commonly used in industrial settings, such as here for controlling the individual servo drives of the robots. To make assembly and testing interesting, the first controller and integration with a robot was made ready for display at the Open Sauce 2025 event, requiring things to be rushed along, including reverse-engineering the servo protocol for a small-ish industrial robot suitable for public display and use, as well as developing the kinematics for the robotic arm.
With the controller now demonstrated, clearly this is the perfect time to rush out and get one of these fun industrial robots for a few hundred bucks. Currently the controller is still being finalized, with the author asking for feedback on what it should be able to support. If you have a particularly unusual industrial robot lounging around without the requisite controller, this might be your chance to revive it.
The modern era of virtual reality really kicked off in earnest just over a decade ago, when the Oculus Rift promised 3D worlds beyond your wildest dreams. Since then, nobody’s been able to come up with a killer app to convince even a mild fraction of consumers to engage with the technology. Still, if you’re keen to tinker, you might like to make your own headset like [CNCDan] has done.
The build is based almost entirely on 3D-printed components and parts sourced from AliExpress. It offers 2880x1440p resolution, thanks to a pair of square 1440×1440 LCD displays, one for each eye, paired with a couple of 34 mm lenses. The headset has adjustable interpupiliary distance so you can dial the view in to properly suit your eyes. The 3D-printed housing is designed to be compatible with headrest pads from the HTC Vive Pro for comfort’s sake. Head tracking is also available, with the inclusion of an IMU and an Arduino onboard. [CNCDan] apparently put the build together for under $150, which is not bad compared to the price of a commercial off-the-shelf unit. Files are on Github for the curious.
[CNCDan] reports good results with the DIY headset, using it primarily with his racing simulator setup. He has had some issues, however, with his LCD screens, which don’t properly run at a 90 Hz refresh rate at full resolution, which is frustrating. It’s an issue he’s still looking into. We’ve seen some other neat VR builds over the years, too. Video after the break.
As an example, [Nicola] demonstrates the concept using an AVR128DA28 microcontroller. It’s paired with a 4052 multiplexer IC and a CH340 USB-to-serial chip. Everything is wired up such that the 4052 acts as a switch for the signal coming from the CH340. When the RTS flow-control signal is set high, it switches the 4052 to hook up the CH340’s RX and TX pins to the UDPI interface on the AVR microcontroller. Conversely, when the RTS signal is set low, the CH340 is instead hooked up to the serial UART on the microcontroller. From there, it’s a simple matter of configuring avrdude to properly set the RTS pin when attempting to program the attached device.
If you’re working with UPDI devices and you want to be able to talk to them and program them with a minimum of fuss, this project might be useful for you. We’ve looked at dedicated UPDI programmers before, too. If you’re cooking up your own nifty microcontroller hacks, don’t hesitate to let us know on the tipsline.
It was one of those weeks last week at Hackaday’s home office. My mother-in-law handed me her favorite power bank and said “it’s not charging”. She had every expectation that I’ll open it up, desolder the weary pouch inside, scrounge a LiPo out of some corner of the basement, and have it back up and running before the weekend. And of course that’s what happened, although maybe it looks a little worse for wear because it was hard to open the sealed case without excessive force. Sorry about that!
Then on the weekend, I finally got fed up with the decomposing foam on the face seal on my FPV goggles. It was leaking light all over the place. Of course I could have bought a new seal, but then I’d have to wait a week or so for delivery. So I pulled the velcro backing off, tossed it in the bed scanner, pulled the image up in Inkscape, converted it to Gcode, and cut out a couple seals out of EVA foam on the laser. Not only are they essentially indestructible, but I was able to customize them a little bit, and the fit is now better than ever.
And then, one of our neighbors bought a new garage door fob, flipped the DIP switches into the right configuration, and couldn’t figure out why it wouldn’t open the garage door. Knock knock knock. Using the tried-and-true RF probe that everyone with a scope probe has sitting around, namely hooking the ground pin to the tip and putting the radio device in the loop, it was clear that the sense of the DIP switches was inverted from what it said in the instructions. That was a fun little puzzle.
It was the garage door opener that triggered me to think about how normal people would handle any of these situations. “How do the normies even get by?” were the exact words that went through my head. And let’s face it: we’re not entirely normal. Normal people don’t have a soldering setup just sitting around ready to get hot 24/7, or a scope to diagnose a garage door RF transmitter at the drop of a hat. But these things seem to happen to me all the time. How do the normal people survive? Maybe they all know someone with a scope?
I take it as my service to the world to be “that guy” for most of our friends and family, and I pretty much do it without complaint. “With great power” and all that. My wife is just about as gracious when she’s stuck debugging a parent’s Windows setup, so I’m not saying I’m the only saint in the world, either. Surely you have similar stories.
But last week it made me reflect on how good we’ve got it, and that does make me want to pay it forward a little bit. If you’re one of the people who can, try to help out those who can’t.
This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter. Want this type of article to hit your inbox every Friday morning? You should sign up!
It’s a well-known conundrum that while most computers these days are digital in nature, almost nothing in nature is. Most things we encounter in the real world, whether it’s temperature, time, sound, pressure, or any other measurable phenomenon comes to us in analog form. To convert these signals to something understandable by a digital converter we need an analog-to-digital converter or ADC, and [Igor] has built a unique one from scratch called a delta sigma converter.
What separates delta sigma converters apart is their high sampling rate combined with a clever way of averaging the measurements to get a very precise final value. In [Igor]’s version this average is provided by an op-amp that integrates the input signal and a feedback signal, allowing for an extremely precise digital value to be outputted at the end of the conversion process. [Igor] has built this one from scratch as well, and is using it to interface a magnetic rotary encoder to control digital audio playback.
Although he has this set up with specific hardware, he has enough detail in his video (including timing diagrams and explanations of all of the theory behind these circuits) for anyone else to build one of these for other means, and it should be easily adaptable for plenty of uses. There are plenty of different ADC topologies too, and we saw many different ones a few years ago during our op-amp challenge.
La storia di SoopSocks è quella che, purtroppo, conosciamo bene: un pacchetto PyPI che promette utilità — un proxy SOCKS5 — ma in realtà introduce un impianto malevolo ben orchestrato.
Non stiamo parlando del solito script improvvisato; dietro SoopSocks c’è una catena di azioni pensata per ottenere persistenza, ridurre il rumore e stabilire un canale di comando/controllo stabile. Il pacchetto è stato pubblicato su PyPI (Python Package Index), il registro ufficiale dei pacchetti Python.
Il pacchetto ingannevole, denominato “soopsocks“, ha totalizzato 2.653 download prima di essere rimosso. È stato caricato per la prima volta da un utente di nome “soodalpie” il 26 settembre 2025, la stessa data di creazione dell’account. Questa combinazione è pensata per massimizzare la percentuale di successo: componenti compilati per l’esecuzione, script per l’integrazione e meccanismi nativi per la persistenza. Il risultato è un pacchetto che funziona come “utility” e nello stesso tempo costruisce un punto di appoggio remoto.
Strategia dell’attaccante: stealth e affidabilità
SoopSocks si presentava come una libreria Python, riportano i ricercatori di sicurezza, per offrire un proxy SOCKS5. In realtà, su Windows metteva in piedi un piccolo impianto di backdoor persistente: si installava come servizio, apriva la porta giusta sul firewall, rimaneva attivo ai riavvii e inviava periodicamente informazioni all’esterno.
Come entra e si installa: dopo l’installazione, il pacchetto non si limitava ai moduli Python. In alcune versioni depositava un eseguibile compilato (scritto in Go) e uno o più script di orchestrazione (PowerShell/VBScript). Questi componenti servivano per:
installare un servizio Windows con avvio automatico (così si riaccendeva ad ogni boot);
predisporre un piano B di persistenza tramite un’attività pianificata, se la creazione del servizio falliva;
eseguire comandi PowerShell in modalità “silenziosa” (bypassando le execution policy e riducendo i messaggi a schermo) per configurarsi e restare sotto traccia.
Cosa fa una volta attivo
Ufficialmente esponeva un proxy SOCKS5 (tipicamente sulla porta 1080). Dietro le quinte:
aggiungeva regole al firewall per aprire la porta del proxy, così il traffico in ingresso non veniva bloccato;
manteneva persistenza (servizio + task) in modo da sopravvivere a riavvii o tentativi di “pulizia” incompleti;
avviava una telemetria a basso profilo: a intervalli regolari raccoglieva informazioni sulla macchina (nome host, versione del sistema, configurazione e stato della rete, indirizzi IP) e le spediva verso l’esterno usando canali comuni (HTTPS), di solito con pacchetti piccoli e frequenti per non dare nell’occhio.
Perché è difficile da notare
Molte azioni passavano per strumenti legittimi di Windows (PowerShell, Task Scheduler, gestione firewall). Agli occhi di un monitoraggio basato solo su firme, queste operazioni possono sembrare normali attività amministrative. Inoltre, offrendo davvero un SOCKS5 “funzionante”, il pacchetto abbassava la soglia di sospetto: chi lo provava vedeva che “fa il suo dovere” e raramente andava a controllare i componenti extra.
Il punto chiave
SoopSocks univa funzionalità utile (il proxy) e meccaniche di intrusione/persistenza ben note. Questo mix trasformava una libreria apparentemente innocua in un punto d’appoggio remoto: un host che l’attaccante può usare come proxy controllabile e da cui raccogliere dati, con un profilo di “rumore” di rete volutamente basso.
Questa strategia dimostra una conoscenza pratica di come operano team di difesa aziendali: gli attaccanti progettano le loro tecniche per apparire «normali» rispetto al profilo operativo quotidiano. L’utilizzo di ambienti di sviluppo, come punto di diffusione, permette di creare punti di persistenza per movimenti laterali. Inoltre l’utilizzo i repository interni/locali possono conservare versioni malevoli anche dopo che sono state rimosse online, perché restano in cache. Senza regole di verifica e pulizia periodica, i team di sviluppo rischiano di continuare a usarle senza accorgersene.
SoopSocks non ha rivoluzionato il panorama delle minacce, ma ha mostrato come la combinazione di componenti legittimi e tecniche già collaudate possa trasformare una libreria in un serio vettore di compromissione. Per le organizzazioni la sfida non è solo tecnica, ma soprattutto processuale: difendere la filiera software richiede controlli e procedure
The MOS Technologies 6581, or SID, is perhaps the integrated circuit whose sound is most sought-after in the chiptune world. Its three voices and mix of waveforms define so much of our collective memories of 1980s computing culture, so it’s no surprise that modern musicians seek out SID synthesisers of their own. One of these is the MIDISID, produced by [MIDI IN], and in a recent video she investigates an unexpected tuning problem.
It started when she received customer reports of SIDs that were out of tune, and in the video she delves deeply into the subject. The original SID gained its timing from a clock signal provided by the Commodore 64, with thus different timing between NTSC and PAL versions of the machine. This meant European SID music needed different software values to American compositions, and along the way she reveals a localisation error in that the British Commodore 64 manual had the wrong table of values.
Modern SIDs are emulated unless you happen to have an original, and her problem came when switching from one emulated SID to another. The first one used that clock pin while the second has its own clock, resulting in some music being off-tune. It’s a straightforward firmware fix for her, but an interesting dive into how these chips worked for the rest of us.
In un noto forum underground è recentemente apparso un post che sta attirando l’attenzione della comunità di cybersecurity. Un utente con il nickname KaruHunters, figura già conosciuta per la sua attività all’interno di circuiti criminali digitali, ha pubblicato un annuncio in cui sostiene di essere in possesso dei dati compromessi di RIPE NCC (Réseaux IP Européens Network Coordination Centre).
Disclaimer: Questo rapporto include screenshot e/o testo tratti da fonti pubblicamente accessibili. Le informazioni fornite hanno esclusivamente finalità di intelligence sulle minacce e di sensibilizzazione sui rischi di cybersecurity. Red Hot Cyber condanna qualsiasi accesso non autorizzato, diffusione impropria o utilizzo illecito di tali dati. Al momento, non è possibile verificare in modo indipendente l’autenticità delle informazioni riportate, poiché l’organizzazione coinvolta non ha ancora rilasciato un comunicato ufficiale sul proprio sito web. Di conseguenza, questo articolo deve essere considerato esclusivamente a scopo informativo e di intelligence.
Il post nel forum underground
Nel post, KaruHunters dichiara esplicitamente: “Today I am selling RIPE NCC Data Breach, thanks for reading and enjoy!”. L’attore rivendica un presunto attacco informatico avvenuto nell’ottobre 2025 ai danni del RIPE NCC, che avrebbe portato all’esfiltrazione di codice sorgente privato e strumenti interni dell’organizzazione. Viene menzionata anche una compromissione che include un’alberatura dei dati, senza tuttavia fornire dettagli tecnici concreti nel messaggio pubblico.
Un elemento di particolare rilievo è la parte commerciale dell’annuncio: i dati vengono messi in vendita a partire da 500 dollari (con possibilità di negoziazione), mentre l’accesso interno ai sistemi compromessi viene offerto a 1.200 dollari. KaruHunters aggiunge inoltre che le informazioni sottratte riguarderebbero un’entità con un fatturato dichiarato di 37,5 milioni di dollari, sebbene questa cifra debba essere trattata con cautela e verificata.
Il post è stato corredato da un logo del RIPE NCC, un dettaglio che rientra spesso nelle strategie di social engineering adottate dai criminali per conferire maggiore credibilità alle loro offerte. Tuttavia, come spesso accade in questi casi, non sono state fornite prove verificabili a supporto della presunta intrusione, almeno non nel messaggio pubblico. È probabile che eventuali “proof of concept” vengano condivise soltanto in trattative private con potenziali acquirenti.
Cos’è il RIPE
Il RIPE NCC (Réseaux IP Européens Network Coordination Centre) è il Regional Internet Registry (RIR) responsabile per l’Europa, il Medio Oriente e alcune parti dell’Asia centrale. Si tratta di un’organizzazione no-profit con sede ad Amsterdam, fondata nei primi anni ’90, che ha il compito principale di gestire e distribuire le risorse numeriche di Internet, come gli indirizzi IP e i Numeri di Sistema Autonomo (ASN).
Il RIPE NCC non va confuso con il RIPE (Réseaux IP Européens), che è una comunità aperta di operatori di rete e specialisti. Mentre la comunità RIPE si occupa di definire politiche e linee guida per il funzionamento della rete, il RIPE NCC è l’entità che mette in pratica tali decisioni attraverso la gestione operativa delle risorse.
Tra i compiti principali del RIPE NCC rientrano:
l’assegnazione e la registrazione di indirizzi IPv4 e IPv6;
la distribuzione dei Numeri di Sistema Autonomo (ASN);
la gestione del RIPE Database, un archivio pubblico che contiene informazioni tecniche e amministrative relative a indirizzi IP e ASN;
il supporto tecnico alla comunità di operatori e provider;
attività di ricerca e monitoraggio della stabilità di Internet a livello globale.
Il ruolo del RIPE NCC è cruciale per il funzionamento ordinato e trasparente della rete, poiché garantisce che l’allocazione delle risorse IP avvenga in modo equo, tracciabile e conforme alle politiche stabilite dalla comunità. In sostanza, rappresenta una delle fondamenta invisibili ma indispensabili per il funzionamento di Internet come lo conosciamo oggi.
Il profilo del threat actors e i potenziali impatti
Il profilo di KaruHunters all’interno del forum mostra un livello di reputazione piuttosto elevato, con 154 punti e la qualifica di “GOD”, indice di un certo riconoscimento da parte della community. L’utente risulta registrato dal mese di agosto 2024, con all’attivo 26 post e 18 thread aperti. Questo dato rafforza l’idea che non si tratti di un nuovo arrivato, ma di un soggetto che ha saputo conquistare credibilità nel contesto criminale.
Se confermato, un data breach ai danni di RIPE NCC avrebbe conseguenze potenzialmente gravi per l’intero ecosistema di internet europeo e non solo, poiché l’organizzazione gestisce informazioni sensibili legate alla connettività di rete globale. Tuttavia, non è raro che su questi forum vengano pubblicati annunci esagerati o falsi, utilizzati più come operazioni di marketing criminale che come reali vendite di dati compromessi.
In conclusione, il post di KaruHunters va preso con la dovuta cautela. Da un lato, la reputazione dell’utente nel forum conferisce un certo peso alla sua dichiarazione; dall’altro, l’assenza di prove tangibili impone di attendere verifiche indipendenti. Quel che è certo è che la semplice comparsa di questo annuncio rappresenta un campanello d’allarme per il settore della sicurezza informatica, ricordando quanto gli attori malevoli siano costantemente alla ricerca di punti critici nelle infrastrutture che regolano internet stesso.
Come nostra consuetudine, lasciamo sempre spazio ad una dichiarazione dell’organizzazione qualora voglia darci degli aggiornamenti su questa vicenda e saremo lieti di pubblicarla con uno specifico articolo dando risalto alla questione. RHC monitorerà l’evoluzione della vicenda in modo da pubblicare ulteriori news sul blog, qualora ci fossero novità sostanziali.
Once upon a time, ham radio was all about CW and voice transmissions and little else. These days, the hobby is altogether richer, with a wide range of fancy digital data modes to play with. [KM6LYW Radio] has been tinkering in this space, and whipped up a compact ham radio data rig that you can build for well under $100.
Radio-wise, the build starts with the Baofeng UV-5R handheld radio. It’s a compact VHF/UHF transceiver with 5W output and can be had for under $25 USD if you know where to look. It’s paired with a Raspberry Pi Zero 2W, which is the brains of the operation. The Pi is hooked up to the All-In-One-Cable which is basically a soundcard-like interface that plugs into USB and hooks up to the mic and speaker outputs of the Baofeng handheld. The final pieces of the puzzle are a USB PD battery pack and a small OLED screen to display status information.
What does that kit get you? The capability to transmit on all sorts of digital modes with the aid of the DigiPi software package. You can send emails, jump on APRS, or even chat on the web. You can configure all of this through a web interface running on the Raspberry Pi.
The 600W is not the output rating, despite all appearances. (Credit: Denki Otaku, YouTube) We have seen many scam USB chargers appear over the years, with a number of them being enthusiastically ripped apart and analyzed by fairly tame electrical engineers. Often these are obvious scams with clear fire risks, massively overstated claims and/or electrocution hazards. This is where the “600W” multi-port USB charger from AliExpress that [Denki Otaku] looked at is so fascinating, as despite only outputting 170 Watt before cutting out, it’s technically not lying in its marketing and generally well-engineered.
The trick being that the “600W” is effectively just the model name, even if you could mistake it for the summed up output power as listed on the ports. The claimed GaN components are also there, with all three claimed parts counted and present in the main power conversion stages, along with the expected efficiency gains.
While testing USB-PD voltages and current on the USB-C ports, the supported USB-PD EPR wattage and voltages significantly reduce when you start using ports, indicating that they’re clearly being shared, but this is all listed on the product page.
The main PCB of the unit generates the 28 VDC that’s also the maximum voltage that the USB-C ports can output, with lower voltages generated as needed. On the PCB with the USB ports we find the step-down converters for this, as well as the USB-PD and other USB charging control chips. With only a limited number of these to go around, the controller will change the current per port dynamically as the load increases, as you would expect.
Considering that this particular charger can be bought for around $30, is up-front about the limitations and uses GaN, while a genuine 300 Watt charger from a brand like Anker goes for $140+, it leads one to question the expectations of the buyer more than anything. While not an outright scam like those outrageous $20 ‘2 TB’ SSDs, it does seem to prey on people who have little technical understanding of what crazy amounts of cash you’d have to spend for a genuine 600 Watt GaN multi-port USB charger, never mind how big such a unit would be.
When taking pictures of the night sky, any noise picked up by the sensor can obscure the desired result. One major cause of noise in CMOS sensors is heat—even small amounts can degrade the final image. To combat this, [Francisco C] of Deep SkyLab retrofitted an old Canon T1i DSLR with an external cooler to reduce thermal noise, which introduces random pixel variations that can hide faint stars.
While dedicated astrophotography cameras exist—and [Francisco C] even owns one—he wanted to see if he could improve an old DSLR by actively cooling its image sensor. He began with minor surgery, removing the rear panel and screen to expose the back of the sensor. Using a sub-$20 Peltier cooler (also called a TEC, or Thermoelectric Cooler), he placed its cold side against the sensor, creating a path to draw heat away.
Reassembling the camera required some compromises, such as leaving off the LCD screen due to space constraints. To prevent light leaks, [Francisco C] covered the exposed PCBs and viewfinder with tape. He then tested the setup, taking photos with the TEC disabled and enabled. Without cooling, the sensor started at 67°F but quickly rose to 88°F in sequential shots. With the TEC enabled, the sensor remained steady at 67°F across all shots, yielding a 2.8x improvement in the signal-to-noise ratio. Thanks to [Francisco C] for sharing this project! Check out his project page for more details, and explore our other astrophotography hacks for inspiration.
The tides! Such a unique thing, because on Earth, we don’t just have oceans full of liquid water—we also have a big ol’ moon called Moon to pull them around. You might like to keep track of the tides; if so, this tide clock from [rabbitcreek] could come in handy.
The motions of the tides are moderately complex; it was in the late 19th century that Sir William Thomson figured out a reasonable method to predict the tides mathematically and with a mechanical contrivance of his own design. These days, though, you don’t need pulleys and ropes to build a tide clock; you can just use electronics for display and the NOAA API to get the information you need.
[rabbitcreek’s] build is based around the Xiao ESP32 S3, which is charged with using its Wi-Fi connection to query NOAA up-to-date tide height data. It then uses this information to drive the position of a servo, installed inside a 3D-printed housing. The servo rotates a little red Moon indicator around a central Earth, with our home planet surrounded by a stretched blue marker indicating the swelling of the tides as influenced by the Moon’s gravity.
If you’re a surfer or beach driver that’s always wanting to know the tidal state at a glance, this clock is for you. We’ve featured other tide clocks before, but never any projects that can actually influence the tides themselves. If you’ve figured out how to mess with gravity on a planetary scale, consider applying for a Nobel Prize—but do notify the tipsline before you do.
If you need to create a high vacuum, there are basically two options: turbomolecular pumps and diffusion pumps. Turbomolecular pumps require rotors spinning at many thousands of rotations per minute and must be carefully balanced to avoid a violent self-disassembly, but diffusion pumps aren’t without danger either, particularly if, like [Advanced Tinkering], you use mercury as your working fluid. Between the high vacuum, boiling mercury, and the previous two being contained in fragile glassware, this is a project that takes steady nerves to attempt – and could considerably unsteady those nerves if something were to go wrong.
A diffusion pump works by boiling a some working fluid – usually silicone oil – and creating a directed stream of vapor. The vapor molecules collide with air molecules and impart momentum to them, drawing them along with the vapor stream into a condenser. The condenser liquefies the working fluid, while a backing vacuum pump just past the condenser removes the entrained air molecules. The working fluid then flows back into the heating chamber to begin the cycle again. The earliest diffusion pumps did use mercury as a working fluid, a practice which has almost completely died out, but which did have one significant advantage: if, for some reason, air did flood back into the vacuum chamber, there was no risk of setting hot oil vapor on fire.
[Advanced Tinkering]’s diffusion pump is made of glass, which gives a good view of the internal process; It’s in equal parts fascinating and disquieting to see droplets of metal condensing on the glass parts. A Dewar flask of liquid nitrogen holds two cold traps to condense any mercury vapors leaving the pump: one on the line between the diffusion pump and the backing pump, and one between the diffusion pump and a vacuum gauge to make sure that mercury’s vapor pressure isn’t throwing off measurements. Another vacuum gauge is connected to the backing pump’s inlet, which lets the diffusion pump’s performance be measured. After a few hours of running, the pressure at the diffusion pump’s inlet was two orders of magnitude lower than at its outlet, and more vacuum-tight connections could probably have brought it even lower.
This isn’t [Advanced Tinkering]’s first time working with dangerous liquid metals, nor his first time building equipment for high vacuum. If you’re still looking for a safer vacuum, check out this budget diffusion pump.
Elliot Williams and Al Williams got together to share their favorite hacks of the week with you. If you listen in, you’ll hear exciting news about the upcoming SuperCon and the rare occurrence of Al winning the What’s That Sound game.
For hacks, the guys talk about the IEEE’s take on the “best” programming languages of 2025 and how they think AI is going to fundamentally transform the job of a programmer. On a lighter note, there’s an industrial robot who retired to bartending, a minimal drum machine, a high-powered laser, and a Fortran flight simulator reborn with Unity 3D.
In the “can’t miss” category, you’ll learn how not to switch Linux distributions and what to expect when you need surgery while on your next mission to outer space.
There’s lots more. Want to follow along? Check out the links below. As always, tell us what you think about this episode in the comments!
Al made short work of the sound again this week, racking up an uncharacteristic streak of two. Congrats to [Absolutely the Best Podcast: A Work in Progress] for getting the printing press right too!
Finding, collecting, and restoring vintage tech is the rewarding pastime of many a Hackaday reader. Working with old-school gear can be tough, though, when documentation or supporting resources are hard to find. If you’re in need of an old manual or a little scrap of software, you might find the Vintage Technology Digital Archive (VTDA) a useful destination.
The VTDA is a simple website. There is no search function, or fancy graphical way to browse the resources on offer. Instead, it’s merely a collection of files in a well-ordered directory tree. Click through /pics/DiskSleeves/VTDA/ and you’ll find a collection of high-resolution scans of various old diskettes and their packaging. /docs/computing/Centronics/ will give you all kinds of useful documentation, from press releases to datasheets for printers long forgotten. You can even find Heathkit schematics and old Windows bootdisk images if you dive into the depths.
While it doesn’t have everything, by any means, the VTDA has lots of interesting little bits and pieces that you might not find anywhere else. It’s a great counterpart to other archival efforts out on the web, particularly if you’re a member of the retrocomputing massive.
This week a reader sent me a story about a CVE in Notepad++, and something isn’t quite right. The story is a DLL hijack, a technique where a legitimate program’s Dynamic Link Library (DLL) is replaced with a malicious DLL. This can be used for very stealthy persistence as well as escalation of privilege. This one was assigned CVE-2025-56383, and given a CVSS score of 8.4.
This is key when evaluating a vulnerability write-up. What exactly is the write-up claiming? And what security boundary is actually being broken? The Common Weakness Enumeration (CWE) list can be useful here. This vulnerability is classified as CWE-427, an uncontrolled search path element — which isn’t actually what the vulnerability claims, and that’s another clue that something is amiss here. In reality this “vulnerability” applies to every application that uses a DLL: a CVSS 0.
Smish Boxes
There’s a trend to replace land lines with cellular modems. While wearing my phone tech hat, I’ve even installed a few cellular routers in hotel telecom closets. It turns out there’s a potential problem with that particular arrangement. Hotels and other commercial installations often assign a public IP address to each piece of equipment, and as a result it’s not uncommon for that equipment to be directly exposed to the Internet. And what happens when cellular routers are exposed to the Internet, sometimes with vulnerabilities or even default credentials? Naturally, scammers use them to send spammy SMS messages.
The scale of the problem is surprising. After researchers at Sekoia discovered the problem, they discovered 18,000 of these devices accessible on the Internet. It seems like this campaign may be responsible for the majority of the SMS spam being sent in modern smishing campaigns. It also appears that there may be an unknown 0-day being exploited in the campaign.
VMWare
VMware just fixed CVE-2025-41244, a local privilege escalation vulnerability that has been in use in the wild since at least October of last year. This vulnerability is in the service discovery feature of VMware Aria. The idea is that the installed VMware Tools can discover running services and probe for version numbers.
On a Linux guest, this probe works by listing the currently running processes, and if the a process matches one of the regular expressions, that process is run with the -v flag. As root. Yes, this vulnerability that was being actively exploited in the wild by a Chinese threat actor for over a year, was as simple as an over-matching regex and carelessly running binaries as root. The trick favored by the attackers was to place a malicious binary at /tmp/httpd, run it as a regular user, and just wait for the VMware tooling to come along and run it as root.
Sudo Chwoot
The maintainers behind sudo fixed a pair of vulnerabilities back in June that allowed a local attacker to escalate privileges. The most interesting of the two abuses is in the handling of the chroot option, resulting in an attack [Rich Mirch] refers to as “chwoot”.
The actual weakness is that sudo would use the chroot() system call while setting up the chroot environment, prior to dropping privileges. In this state, sudo performs Name Service Switch calls as root, which results in looking for /etc/nsswitch.conf inside the chroot directory. This config file can trigger a shared library load, and since it’s happening in the context of a chroot, that library is also first loaded from the chroot directory if it exists there, resulting in a handy escalation to root.
This behavior is enabled for all users by default, resulting in a serious vulnerability on many Linux machines. It was fixed and disclosed back in June, but has now been added to the CISA list of known exploited vulnerabilities.
Not in the Threat Model
Intel and AMD both have trusted computing solutions for encrypted VMs, that among other things, encrypt the bits in memory so even a compromised kernel can’t extract data from the running VM. The approaches from both companies are similar, using symmetric encryption with the memory location as part of the encryption Initialization Vector (IV). This means that while the same key is in use, a plaintext value in a given memory location will always be represented by the same encrypted value. Two pieces of research came out this week suggesting that this codebook-like behavior has security ramifications.
Before we dive into the rest of the details, it’s worth pointing out that asymmetric encryption is likely not a viable option for VM memory encryption, due to the processing latency overhead. The exploit here is to physically connect to the memory sticks inside a target computer, and record the encrypted bits. In some cases, an attacker can later run a malicious VM on the same hardware, and use the physical hack to replay the captured bits, allowing easy decryption. Another option is to replay the VM attestation report, falsely claiming that the virtual machine is still fully protected.
What’s initially surprising is that both Intel and AMD have maintained that their SGX and SEV-SNP systems are not intended to protect against physical access. But seeing what is possible with physical modification to system memory, it’s no longer a surprising line to draw. The other interesting note is that so far these attacks are limited to DDR4, as DDR5 memory has a higher data rate, making the entire operation even more difficult.
RCE Security dug into a product called TRUfusion Enterprise, a data transfer solution that is marketed as undergoing regular audits. It came as a surprise that they found four vulnerabilities that could be called low-hanging fruit. The takeaway: not all audits are created equal, and there’s no guarantee that this style of code review will catch every bug.
Our last two links are both about memory management. The first is from Cybervelia, looking at how to find uninitialized memory access with just a program binary and no source code. Binary Ninja is the tool that really shines here, but it’s certainly not an easy task.
La Community di Red Hot Cyber ha avuto l’opportunità di partecipare a “Oltre lo schermo”, l’importante iniziativa della Polizia Postale dedicata ai giovani del 2 ottobre, con l’obiettivo di invitarli a vivere la realtà oltre i confini dei social network. Un evento che conferma come, ormai da alcuni anni, la cyber security awareness sia diventata un pilastro fondamentale nei percorsi di formazione giovanile.
L’Auditorium Parco della Musica di Roma, gremito da oltre 1.200 studenti provenienti dalla capitale e dalla sua provincia, ha fatto da cornice all’incontro promosso dalla Polizia di Stato, in collaborazione con Google e One More Pictures. L’iniziativa rientra nella 13ª edizione di “Una Vita da Social”, la storica campagna educativa itinerante che porta nelle scuole italiane strumenti e riflessioni per un utilizzo sicuro e consapevole del web.
Il focus di quest’anno è stato il confronto tra i modelli di perfezione proposti dai social e l’identità dei più giovani, con particolare attenzione alla body positivity e alla riscoperta del valore delle relazioni autentiche nella vita reale.
Il messaggio delle istituzioni
Ad aprire l’incontro, il Capo della Polizia Vittorio Pisani che ha ricordato ai ragazzi di non farsi condizionare dall’identità digitale:
“I rapporti umani sono quelli che arricchiscono davvero e vi preparano a fare la differenza nella vita quotidiana e nel futuro mondo del lavoro”.
Il prefetto ha ringraziato gli insegnanti, riconoscendo il loro compito fondamentale nel trasmettere valori e responsabilità alle nuove generazioni. Anche l’on. Federico Mollicone ha sottolineato, con un messaggio il valore sociale ed educativo del tema, definendo l’educazione digitale una sfida decisiva per il futuro.
Storie ed emozioni: il cortometraggio (IM)PERFETTA
Il momento più atteso è stato la proiezione del cortometraggio “(IM)PERFETTA”, prodotto da One More Pictures con Rai Cinema e presentato alla Mostra del Cinema di Venezia.
La storia di una ragazza che, dopo una delusione amorosa, si rifugia nei social inseguendo un ideale di perfezione, ha emozionato gli studenti. La protagonista scopre infine che la vera unicità sta nelle imperfezioni, ciò che rende autentici e irripetibili.
Scritto da Margherita Pezzella, il corto ha stimolato un confronto sincero, in cui molti giovani si sono riconosciuti. Magistrale il finale del corto nel quale la protagonista, come un novello Amleto, fissa le pillole dimagranti prima della sfumatura finale lasciando allo spettatore sempre presente lo spettro della tentazione mai sopita delle scorciatoie (ingannevoli) verso il risultato.
Testimonianze e ospiti
A rendere speciale l’evento, la partecipazione del cast del film, di artisti, sportivi e personalità del mondo della comunicazione. Non sono mancati i videomessaggi dei calciatori di A.S. Roma e S.S. Lazio, che hanno invitato i ragazzi a credere nel sacrificio, nel lavoro di squadra e nel valore della vita reale rispetto a quella virtuale.
Il conduttore radiofonico Renzo Di Falco e la Dottoressa Roberta Mestichella hanno guidato la giornata con energia, lasciando spazio a riflessioni e interventi anche in collegamento: da New York con Marco Camisani Calzolari, esperto di comunicazione digitale, e da un set cinematografico in Trentino Alto Adige.
Educazione digitale e responsabilità condivisa
Il confronto tra istituzioni e aziende ha ribadito la necessità di un’alleanza tra pubblico e privato.
Barbara Strappato, direttrice della Prima Divisione della Polizia Postale, e Martina Colasante di Google Italia hanno sottolineato l’impegno per sviluppare tecnologie sicure e costruite su misura per i più giovani.
Il produttore Carlo Raffronti ha ricordato che oggi il rischio è l'”analfabetismo digitale”, invitando i ragazzi a domandarsi sempre perché un contenuto viene loro proposto online.
Quasi tutti gli ospiti del talk hanno posto l’accento sul valore delle emozioni reali, più durature di quelle virtuali.
Un invito a scegliere quindi la realtà e ad utilizzare i social responsabilmente
Il filo conduttore dell’evento è stato chiaro: educazione, rispetto e accettazione di sé e degli altri come strumenti per contrastare fenomeni come il cyberbullismo. “Non esistono scorciatoie” hanno ricordato gli sportivi di Roma e Lazio presenti con un video messaggio, “servono sacrificio e dedizione, nello sport come nella vita”.
Durante i vari speech della giornata, ogni partecipante ha ricevuto un kit con materiali informativi: un quaderno Comix, un volantino della Polizia Postale con utili consigli per una navigazione sicura e il “The Future Report” di Google, ricerca veramente accurata sugli adolescenti europei e il loro rapporto con internet e l’intelligenza artificiale.
Più che un evento, un messaggio alle nuove generazioni ed ai loro genitori
“Oltre lo schermo” non è stato solo un momento di riflessione, ma un invito a vivere la tecnologia senza subirla, a non lasciarsi ingannare dalle illusioni dei social e a dare valore alle relazioni autentiche.
Perché, come ha ricordato uno dei relatori, “ciò che conta davvero è quello che pensano di voi le persone che vi conoscono nella vita reale, coloro che vi vogliono bene, non i commenti sui social”.
Volevo ringraziare Marco Bani e Lorenzo Basso per avermi regalato il loro libro “Il secolo dell’IA, capire l’intelligenza artificiale, decidere il futuro” (Il Mulino -Arel, 2025).
Mi è piaciuto molto e mi sono segnato diversi passaggi interessanti.
Il motivo è che di libri sull’IA ne ho letti parecchi in italiano, meno in inglese, a cominciare da quando studiavo psicologia a Stanford e giochicchiavo con le reti neurali negli anni ’90.
Ho letto il bellissimo Vita 3.0 di Max Tegmark, ho letto i libri di Luciano Floridi come Etica dell’Intelligenza artificiale, il libro di Cingolani, L’altra Specie; ho letto i libri di Guido Scorza e Alessandro Longo, quelli del mio amico Massimo Chiriatti (hashtag#humanless, Incoscienza artificiale), di Fabio Lazzini, e Andrea Colamedici (L’algoritmo di Babele): ho letto Breve e universale storia degli algoritmi di Luigi Laura, Nel paese degli algoritmi di Aurélie JEAN, Ph.D., L’economia dell’intelligenza artificiale di Stefano da Empoli; la trilogia di Nello Cristianini (La Scorciatoia, Machina Sapiens, Sovrumano); AI Work di Sergio Bellucci; Intelligenza Artificiale e democrazia di Oreste Pollicino e Pietro Dunn, Human in the Loop di Paolo Benanti eccetera eccetera… scusate non vi cito tutti.
Il libro di Bani e Basso mi è piaciuto per essere chiaro, sintetico, diretto. Con un forte afflato etico e con una impronta politica ma non partigiana. Volendo essere un libro divulgativo, il loro libro mi pare una buona summa del dibattito pubblico in corso pure senza essere un libro accademico o rivelatore.
Ottimo entry level, insomma, ha il pregio di poter essere compreso da un liceale come da un politico. I riferimenti sono corretti, la bibliografia discreta. un bel lavoro. Insomma, è da leggere. Funziona anche nei momenti di relax quando non hai voglia di studiare.
