Penso che fare una donazione sia importante, prima di tutto per portare un minimo di sollievo ai palestinesi ma anche perché su quei 30 euro che doniamo ci scriviamo che il mondo non è tutto Trump, Meloni e compagnia bella, che ci siamo anche noi. E credo che loro riescano a leggerlo.

E da ultimo serve anche a noi, per la soddisfazione che dà sentirsi dalla parte giusta in un mondo che sembra correre a rompicollo nella direzione sbagliata.

unponteper.it/it/campagna/acqu…

There are many ways to learn, but few to none of them compare to that of spending time standing over the shoulder of a master of the craft. This awesome page sent in by [JohnU] is a fantastic corner of the internet that lets us all peek over that shoulder to see someone who’s not only spent decades learning the art of of creating cable harnesses, but has taken the time to distill some of that vast experience for the rest of us to benefit from.

This page is focused on custom automotive and motorcycle modifications, but it’s absolutely jam-packed with things applicable in so many areas. It points out how often automotive wiring is somewhat taken for granted, but it shouldn’t be; there are hundreds of lines, all of which need to work for your car to run in hot and cold, wet and dry. The reliability of wiring is crucial not just for your car, but much larger things such as the 530 km (330 mi) of wiring inside an Airbus A380 which, while a large plane, is still well under 100 m in length.

This page doesn’t just talk about cable harnessing in the abstract; in fact, the overwhelming majority of it revolves around the practical and applicable. There is a deep dive into wiring selection, tubing and sealing selection, epoxy to stop corrosion, and more. It touches on many of the most common connectors used in vehicles, as well as connectors not commonly used in the automotive industry but that possess many of the same qualities. There are some real hidden gems in the midst of the 20,000+ word compendium, such as thermocouple wiring and some budget environmental sealing options.

There is far more to making a thing beyond selecting the right parts; how it’s assembled and the tools used are just as important. This page touches on tooling, technique, and planning for a wire harness build-up. While there are some highly specialized tools identified, there are also things such as re-purposed knitting needles. Once a harness is fully assembled it’s not complete, as there is also a need for testing that must take place which is also touched on here.

Thanks to [JohnU] for sending in this incredible learning resource. If this has captured your attention like it has ours, be sure to check out some of the other wire harness tips we’ve featured!

hackaday.com/2025/07/12/wire-l…

Il gruppo di criminali informatici RansomedVC, tornato sulla scena nel 2025, ha pubblicando sul suo sito web ufficiale una fuga di notizie di corrispondenza interna del gruppo di hacker Medusa, uno dei più noti gruppi di ransomware al mondo. La pubblicazione è stata programmata in concomitanza con il lancio di un nuovo Data Leak Site (DLS) che ha coinvolto due vittime, una statunitense e una brasiliana. Si è trattato della prima azione di alto profilo da quando RansomedVC è tornato sulla scena informatica.

RansomedVC si è concentrato sulla divulgazione delle chat di Medusa risalenti all’11 dicembre 2022 e al marzo 2023. La corrispondenza suggerisce che il gruppo utilizzava un account chiamato MediaTeam per promuovere le proprie attività su Telegram e YouTube.

Medusa è un gruppo che ha raggiunto la notorietà nel 2023. Contrariamente a quanto si potrebbe pensare, il loro modello di business è molto diverso dal classico Ransomware as a Service e operano su una divisione monitorata di sottogruppi. Ultimamente abbiamo notato uno strano comportamento da parte dell’amministratore, come confermato da altri affiliati: sembra completamente assente e insensibile alle esigenze dei suoi membri. Ha recentemente eliminato tutti i gruppi sul server di RocketChat senza preavviso, lasciando agli affiliati solo due plausibili motivi: exit scam o arresto dell’amministratore da parte delle autorità. Vi fidereste di Medusa se tornasse attivo? Di seguito vi abbiamo lasciato un interessante elenco di affiliati che partecipano al programma Medusa, ora sapete dove ripopolare il gruppo e guadagnare un sacco di soldi con le vostre competenze 😀

Per accedere ai sistemi, erano necessari degli hash dump e Medusa preferiva il servizio put.io con un piano da 10 TB e Mega Pro 2 come storage cloud. Le informazioni sulle versioni software delle vittime sono state raccolte dalla documentazione ufficiale delle aziende. L’utility GMER è stata utilizzata per gestire i rootkit, mentre gli strumenti Volatility e LSADump sono stati utilizzati per estrarre le password. Tra gli obiettivi menzionati figuravano Green Cloud e StoreOnce.

Annuncio di fuga di notizie su Medusa su RansomedVC

Sono stati utilizzati exploit specifici su sistemi vulnerabili, tra cui CVE-2022-26134 , una vulnerabilità critica in Atlassian Confluence. Sono stati inoltre discussi la vulnerabilità ProxyNotShell , che colpisce Outlook Web App, e i problemi di bypass antivirus in Windows Defender.

Tra i membri di Medusa menzionati ci sono circa 20 nickname affiliati. Tra questi c’è “drumrlu”, ampiamente conosciuto sui forum underground come Initial Access broker (IaB). In precedenza, aveva fornito accesso al gruppo Thanos. In uno degli episodi, si lamenta del fatto che il firewall Fortinet bloccasse tutto il traffico e descrive come ha aggirato il problema installando Anydesk tramite TOR e configurando un proxy per il controllo remoto: la sessione è durata un’ora.

La chat rivela anche conflitti interni: quando uno dei partecipanti, Ray, ha chiesto a drumrlu uno script, questi ha rifiutato, temendo di “bruciare” il metodo, ma ha espresso il suo supporto. Anche la traccia linguistica è caratteristica: il partecipante Jester scriveva costantemente in russo. Atari ha mostrato interesse nell’aggirare Windows Defender e nopiro ha confermato di aver sfruttato la suddetta vulnerabilità di Confluence. Si ritiene che il datastore del partecipante fosse in precedenza membro di Makop, un altro noto gruppo ransomware .

Il presunto leader di Medusa, nascosto sotto il soprannome di “boss”, propose di inviare messaggi sull’attacco hacker a tutti i dipendenti delle aziende e ai giornalisti, sperando in questo modo di attirare l’attenzione del pubblico. Si discusse anche di formazione su YouTube: i video sulla disattivazione delle protezioni di Windows erano molto richiesti.

La pubblicazione delle chat ha coinciso con la creazione di una nuova versione del sito di RansomedVC l’8 luglio 2025. Ciò suggerisce che la fuga di notizie fosse stata pianificata in anticipo e mirasse ad aumentare l’interesse per il gruppo testando la reazione alle prime due vittime. In questo modo, RansomedVC sta cercando di affermarsi come un attore di rilievo nell’ecosistema dei ransomware, cercando al contempo di minare la reputazione dei suoi concorrenti.

Di particolare interesse è stata la corrispondenza in cui Ray ha condiviso uno script volto ad attivare la Modalità provvisoria in Windows per disabilitare i meccanismi di protezione. Lo script crea un servizio, lo registra nel registro e commuta il sistema in Modalità provvisoria con un successivo riavvio. Tuttavia, errori di sintassi e presupposti relativi al funzionamento della rete in Modalità provvisoria si sono rivelati un fallimento per gli hacker: la rete non funziona in questa modalità di default e, senza ulteriori accorgimenti, l’accesso remoto viene perso. Inoltre, alcuni parametri erano scritti in modo errato, il che rendeva instabile l’avvio del servizio.

Le chat mostrano che Medusa si sta concentrando sui prodotti Fortinet: sia le chat che gli eventi del 2024 menzionano tentativi di sfruttare le SQL injection in questi sistemi. Tutte le attività indicano un focus sugli Stati Uniti, il Paese più spesso menzionato tra gli obiettivi.

RansomedVC sottolinea di aver avuto accesso a questi dati grazie a “insider“. Considerando l’arco temporale della corrispondenza e il ritorno del gruppo stesso, non si può escludere che uno dei membri di RansomedVC abbia collaborato con Medusa in passato. Ciò potrebbe anche indicare un conflitto interno o un tentativo di destabilizzare un concorrente attraverso una fuga di notizie deliberata.

La struttura stessa del mondo della criminalità informatica sta diventando più aggressiva e competitiva: i gruppi si contendono partner affiliati, massimizzano il numero delle vittime, offrono supporto personalizzato durante le negoziazioni, si dedicano al rebranding, lottano per la reputazione e lo spazio informativo. La fuga di notizie di Medusa si sta inserendo in questa lotta e RansomedVC la sta sfruttando per tornare in gioco.

L'articolo Criminal Hacker contro Criminal hacker! RansomedVC umilia Medusa pubblicando le chat del gruppo proviene da il blog della sicurezza informatica.

I ricercatori di Huntress hanno rilevato lo sfruttamento attivo di una vulnerabilità critica in Wing FTP Server, appena un giorno dopo la sua divulgazione pubblica. La vulnerabilità CVE-2025-47812 ha ricevuto il massimo livello di gravità (CVSS 10.0), in quanto consente l’esecuzione remota di codice arbitrario su un server vulnerabile. Il problema è stato scoperto e segnalato dagli specialisti di RCE Security, che ne hanno tuttavia pubblicato i dettagli tecnici solo il 30 giugno, più di un mese dopo il rilascio della patch.

Wing FTP Server è una popolare soluzione multipiattaforma per il trasferimento file che supporta i protocolli FTP, FTPS, SFTP e HTTP/S. Secondo gli sviluppatori, il programma è utilizzato da oltre 10.000 clienti in tutto il mondo, tra cui Airbus, Reuters e l’Aeronautica Militare statunitense. La vulnerabilità riguarda il meccanismo di gestione dei nomi utente nell’interfaccia web di Wing FTP. Quando viene trasmesso un nome utente contenente un byte nullo ( ), tutto ciò che segue viene interpretato come codice Lua. Questo codice viene salvato nel file di sessione e quindi eseguito durante la deserializzazione, consentendo a un aggressore di ottenere il pieno controllo del server.

Secondo Huntress, i primi attacchi sono iniziati il 1° luglio, meno di 24 ore dopo la divulgazione della vulnerabilità. Gli aggressori si sono chiaramente basati su informazioni tecniche pubblicate. Inizialmente, i ricercatori hanno registrato tre connessioni al server della vittima, dopodiché è comparso un quarto aggressore, che ha iniziato a scansionare attivamente il file system, creando nuovi utenti e cercando di introdursi nel sistema. Tuttavia, le sue azioni hanno rivelato un basso livello di preparazione: i comandi contenevano errori, PowerShell si è bloccato e un tentativo di scaricare un trojan è fallito: il file è stato intercettato da Microsoft Defender. L’analisi dei log ha mostrato che a un certo punto l’aggressore ha persino provato a cercare su Internet come utilizzare l’utilità curl e poi, probabilmente, ha chiesto aiuto: un quinto partecipante si è connesso al server.

Dopo diversi tentativi falliti, l’aggressore ha tentato di caricare un file dannoso, ma il server si è bloccato poco dopo e l’organizzazione lo ha messo in quarantena, impedendo ulteriori azioni. Nonostante l’inefficacia dell’attacco, Huntress avverte che la vulnerabilità CVE-2025-47812 è attivamente sfruttata e rappresenta una minaccia reale. I ricercatori raccomandano vivamente a tutti gli utenti di Wing FTP di aggiornare alla versione 7.4.4, che contiene la correzione.

L’incidente ha anche evidenziato la vulnerabilità dei protocolli legacy. FTP è stato creato negli anni ’70 e la sicurezza non era una priorità all’epoca. Sebbene Wing FTP supporti protocolli più sicuri come SFTP e MFT, questi sono disponibili solo in versioni commerciali. Molti progetti moderni come Chrome, Firefox e Debian hanno da tempo abbandonato il supporto per FTP, riflettendo un generale cambiamento di atteggiamento nei confronti del protocollo negli ambienti professionali.

L'articolo Una vulnerabilità RCE in Wing FTP Server da score 10 apre le porte a 10.000 aziende proviene da il blog della sicurezza informatica.

One of the tropes of the space race back in the 1960s, which helped justify the spending for the part of the public who thought it wasn’t worth it, was that the technology developed for use in space would help us out here back on earth. The same goes for the astronomical expenses in Formula 1, or even on more pedestrian tech like racing bikes or cinematography cameras. The idea is that the boundaries pushed out in the most extreme situations could nonetheless teach us something applicable to everyday life.

This week, we saw another update from the Minuteman project, which is by itself entirely ridiculous – a 3D printer that aims to print a 3D Benchy in a minute or less. Of course, the Minuteman isn’t alone in this absurd goal: there’s an entire 3D printer enthusiast community that is pushing the speed boundaries of this particular benchmark print, and times below five minutes are competitive these days, although with admittedly varying quality. (For reference, on my printer, a decent-looking Benchy takes about half an hour, but I’m after high quality rather than high speed.)

One could totally be forgiven for scoffing at the Speed Benchy goal in general, the Minuteman, or even The 100, another machine that trades off print volume for extreme speed. But there is definitely trickle-down for the normal printers among us. After all, pressure advance used to be an exotic feature that only people who were using high-end homemade rigs used to care about, and now it’s gone mainstream. Who knows if the Minuteman’s variable temperature or rate smoothing, or the rigid and damped frames of The 100, or its successor The 250, will make normal printers better.

So here’s to the oddball machines, that push boundaries in possibly ridiculous directions, but then share their learnings with those of us who only need to print kinda-fast, but who like to print other things than little plastic boats that don’t even really float. At least in the open-source hardware community, trickle-down is very real.

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!

hackaday.com/2025/07/12/trickl…

Sometimes, all you need to make something work is to come at it from a different angle from anyone else — flip the problem on its head, so to speak. That’s what [Keizo Ishibashi] did to create his Cantareel, a modified guitar that actually sounds like a hurdy-gurdy.

We wrote recently about a maker’s quest to create just such a hybrid instrument, and why it ended in failure: pressing strings onto the fretboard also pushed them tighter to the wheel, ruining the all-important tension. To recap, the spinning wheel of a hurdy-gurdy excites the strings exactly like a violin bow, and like a violin bow, the pressure has to be just right. There’s no evidence [Keizo Ishibashi] was aware of that work, but he solved the problem regardless, simply by thinking outside the box — the soundbox, that is.

Unlike a hurdy-gurdy, the Cantareel keeps its wheel outside the soundbox. The wheel also does not rub directly upon the strings: instead, it turns what appears to be a pair of o-rings. Each rosined o-ring bows 2 of the guitar’s strings, giving four strings a’ singing. (Five golden rings can only be assumed.) The outer two strings of this ex-six-string are used to hold the wheel assembly in place by feeding through holes on the mounting arms. The guitar is otherwise unmodified, making this hack reversible.

It differs from the classic hurdy-gurdy in one particular: on the Cantareel, every string is a drone string. There’s no way to keep the rubber rings from rubbing against the strings, so all four are always singing. This may just be the price you pay to get that smooth gurdy sound out of a guitar form factor. We’re not even sure it’s right to call it a price when it sounds this good.

youtube.com/embed/1fVSCuUCHtA?…

Thanks to [Petitefromage] for the tip. If you run into any wild and wonderful instruments, don’t forget to let us know.

hackaday.com/2025/07/12/the-ca…

Few electronic ICs can claim to be as famous as the 555 timer. Maybe part of the reason is that the IC doesn’t have a specific function. It has a lot of building blocks that you can use to create timers and many other kinds of circuits. Now [Stoppi] has decided to make a 555 out of discrete components. The resulting IC, as you can see in the video below, won’t win any prizes for diminutive size. But it is fun to see all the circuitry laid bare at the macro level.

The reality is that the chip doesn’t have much inside. There’s a transistor to discharge the external capacitor, a current source, two comparators, and an RS flip flop. All the hundreds of circuits you can build with those rely on how they are wired together along with a few external components.

Even on [stoppi]’s page, you can find how to wire the device to be monostable, stable, or generate tones. You can also find circuits to do several time delays. A versatile chip now blown up as big as you are likely to ever need it.

Practical? Probably not, unless you need a 555 with some kind of custom modification. But for understanding the 555, there’s not much like it.

We’ve seen macro 555s before. It is amazing how many things you can do with a 555. Seriously.

youtube.com/embed/pK1dVKZuLpk?…

hackaday.com/2025/07/12/the-55…

I noti esperti di sicurezza informatica e cacciatori di bug Sam Curry e Ian Carroll hanno scoperto che il chatbot Olivia, utilizzato da McDonald’s per assumere dipendenti, rivelava i dati dei candidati. In totale, il database conteneva oltre 64 milioni di record.

I ricercatori hanno iniziato a interessarsi a quanto stava accadendo dopo aver letto numerose lamentele da parte degli utenti di Reddit riguardo alle risposte “inadeguate” di Olivia. Olivia è un’applicazione di Paradox.ai, un’azienda che sviluppa software di intelligenza artificiale. Il bot viene utilizzato da McDonald’s per selezionare i candidati, richiedere le loro informazioni di contatto e i loro curriculum e indirizzarli ai test.

A volte l’intelligenza artificiale fraintende anche le domande più semplici, ed è per questo che è diventata “famosa” sui social media. “Ho pensato che fosse piuttosto unico e distopico rispetto al tipico processo di assunzione, quindi ho voluto approfondire l’argomento”, racconta Carroll. “Ho iniziato a candidarmi per un lavoro e nel giro di 30 minuti avevamo accesso completo a quasi tutte le candidature inviate a McDonald’s nel corso degli anni”.

Inizialmente, gli esperti volevano testare Olivia per verificarne la vulnerabilità alle iniezioni di prompt, ma non hanno trovato nulla di interessante. Hanno quindi deciso di verificare cosa sarebbe successo se si fossero registrati come affiliati McDonald’s, tentando di accedere al backend del sito. Invece, gli esperti hanno trovato un curioso link di accesso per i dipendenti di Paradox.ai su McHire.com.

Carroll scrive di aver provato inizialmente due delle combinazioni di credenziali più comuni: prima “admin/admin” e poi “123456/123456”. La seconda di queste due combinazioni ha funzionato. “Questo è più comune di quanto si possa pensare”, osserva il ricercatore. “Si scopre anche che la pagina di login di Paradox.ai non supporta l’autenticazione a più fattori.”

Utilizzando queste credenziali, Carroll e Curry hanno ottenuto l’accesso amministrativo a un ristorante di prova McDonald’s su McHire e hanno scoperto che tutti i dipendenti lì elencati erano sviluppatori Paradox.ai provenienti dal Vietnam. Trovarono anche un link a presunte offerte di lavoro di prova per questo McDonald’s inesistente, cliccarono su una di queste, si candidarono e visualizzarono la propria candidatura nel sistema back-end, a cui ora avevano accesso. Poi Carroll e Curry hanno scoperto la seconda vulnerabilità critica in McHire. Dopo aver provato a modificare l’ID della loro candidatura (un numero che superava i 64 milioni), si resero conto che avrebbero potuto semplicemente ridurlo e ottenere l’accesso ai dati e alle informazioni di contatto di altri candidati (inclusi nomi, indirizzi email e numeri di telefono).

I ricercatori erano titubanti nel presentare una richiesta di accesso di massa ai registri, temendo violazioni della privacy e accuse di hacking. Tuttavia, hanno controllato diversi documenti d’identità e ottenuto dati reali da persone reali. Gli esperti osservano che le informazioni personali esposte a seguito di questi problemi non erano tra le più sensibili. Tuttavia, i rischi per i candidati erano aumentati dal fatto che i dati erano direttamente correlati a informazioni sul loro lavoro presso McDonald’s o sulla loro intenzione di lavorare lì.

“Se qualcuno dovesse usare questa cosa, i rischi di phishing sarebbero molto alti”, spiega Curry. “Non si tratta solo di informazioni personali e curriculum. Si tratta di informazioni su persone che cercano lavoro da McDonald’s o che ci lavorano, persone che attendono con ansia le email. Ad esempio, se si cercasse di mettere in atto una sorta di frode sulle buste paga, questa sarebbe un’ottima opzione”.

I rappresentanti di Paradox.ai hanno pubblicato una dichiarazione ufficiale sul loro blog, affermando che l’account di prova con la password “123456” a cui gli esperti hanno avuto accesso non era stato utilizzato dal 2019 e avrebbe dovuto essere disattivato molto tempo fa. Si sottolinea che nessuno, a parte Curry e Carroll, ha sfruttato questa vulnerabilità e non ha ottenuto l’accesso ai dati dei candidati. I ricercatori hanno inoltre avuto accesso solo a sette record, cinque dei quali contenevano effettivamente informazioni personali di persone che interagivano con il sito di McHire.

L’azienda ha aggiunto che lancerà un programma bug bounty per identificare meglio le vulnerabilità nei suoi sistemi in futuro. A loro volta, i rappresentanti di McDonald’s hanno dichiarato a Wired che la colpa di quanto accaduto ricade interamente su Paradox.ai.

L'articolo Il chatbot di McDonald’s ha portato a 64 milioni di record esposti per una password “123456” proviene da il blog della sicurezza informatica.

Il presidente Donald Trump ha lasciato Maria Bartiromo brevemente senza parole durante un’intervista quando ha insinuato che gli Stati Uniti stanno hackerando i sistemi cinesi. Il presidente ha sottolineato il “grande deficit commerciale con la Cina” e ha affermato che il Paese “pagheranno molti dazi”. Tuttavia, ha affermato di avere un “ottimo rapporto” con il presidente cinese Xi Jinping.

Tutto questo è avvenuto in una intervista dove il presidente degli Stati Uniti Donald Trump ha minimizzato l’importanza delle azioni aggressive legate a Pechino, tra cui i recenti arresti di due cittadini cinesi accusati di aver introdotto illegalmente un pericoloso agente patogeno negli Stati Uniti.

Trump ha dichiarato a Fox News riguardo alle aggressioni nel cyberspace che Washington si comporta in modo simile. “Lo facciamo, facciamo un sacco di cose”, all’interno del programma Sunday Morning Futures con Maria Bartiromo che è rimasta sbalordita dalle sue parole.

“È così che funziona il mondo. È un mondo schifoso.”.

Ha aggiunto: “Penso che andare d’accordo con la Cina sia un’ottima cosa, ma loro stanno pagando tariffe doganali sostanziali”. E’ anche vero che la Casa Bianca ha segnalato progressi negli scambi commerciali con la Cina, con un funzionario che ha affermato che entrambe le parti hanno raggiunto un’intesa su questioni quali l’accelerazione delle spedizioni di terre rare negli Stati Uniti.

Yunqing Jian, 33 anni, e Zunyong Liu, 34 anni, sono accusati di cospirazione, contrabbando, false dichiarazioni e frode sui visti. Il Dipartimento di Giustizia degli Stati Uniti ha affermato che i due hanno cospirato per introdurre di nascosto negli Stati Uniti un fungo chiamato Fusarium graminearum, che causa la “carcinoma della spiga”, una malattia che colpisce grano, orzo, mais e riso.

Trump ha minimizzato la cosa, dicendo: “Non si sa da dove venga, però. Voglio dire, viene dal paese o sono tre pazzi che per caso portavano qualcosa?” Riferendosi alla guerra commerciale tra Stati Uniti e Cina , Trump è sembrato dichiarare di essere soddisfatto, affermando: “Stiamo andando d’accordo con la Cina”.

Dopo i colloqui svoltisi a Ginevra a maggio, Washington e Pechino hanno concordato di ridurre temporaneamente i dazi doganali sui rispettivi prodotti.

L'articolo Donald Trump ammette che gli Stati Uniti Stanno hackerando la Cina: “E’ così che va il mondo” proviene da il blog della sicurezza informatica.

La criminalità informatica, secondo l’Interpol, rappresenta ormai oltre il 30% dei reati denunciati in Africa occidentale e orientale, e il suo aumento è particolarmente significativo nel resto del continente.

Ha citato dati relativi al 2024 affermando che:

• Le notifiche di sospette truffe sono aumentate del 3000% in alcuni paesi africani (Kaspersky)
• Secondo Trend Micro, i rilevamenti di ransomware sono stati più elevati in Sud Africa (17.849), Egitto (12.281), Nigeria (3.459) e Kenya (3.030).
• 11 paesi africani rappresentano la maggior parte delle attività BEC, con gruppi di minaccia nell’Africa occidentale particolarmente sofisticati e ben finanziati
• Il 60% dei paesi africani membri ha segnalato un aumento delle segnalazioni di sextortion digitale

Per avere una comprensione più approfondita della criminalità informatica in Africa, bisogna analizzare il modo in cui gli hacker utilizzano strumenti open source offensivi per eseguire attacchi informatici contro le società finanziarie del continente. Tra le principali sfide che le forze dell’ordine africane devono affrontare, vi sono la mancanza di cooperazione tra le nazioni, l’inadeguatezza dei quadri giuridici e la carenza di infrastrutture per la sicurezza informatica.

Secondo le statistiche più recenti riferite al 2024, si è registrato un aumento considerevole delle segnalazioni di possibili frodi in varie nazioni africane, che ha raggiunto la percentuale del 3000%. I dati, resi noti da Kaspersky, mettono in evidenza l’incremento della minaccia rappresentata dalla criminalità informatica nell’ambito del continente.

I dati resi noti da Kaspersky indicano che la minaccia della criminalità informatica nel continente è in crescita. Di conseguenza, urge una collaborazione tra le forze dell’ordine e le organizzazioni finanziarie africane, mediante la condivisione di informazioni e l’elaborazione di strategie efficaci per contrastare tale fenomeno.

È inoltre essenziale che le istituzioni finanziarie africane assegnino una priorità alla sicurezza informatica, mediante investimenti in tecnologie e soluzioni d’avanguardia, al fine di proteggere i propri sistemi e clienti dalle minacce informatiche. A tal proposito, potrebbero valutare l’implementazione di sistemi per il rilevamento e la prevenzione degli attacchi, nonché fornire formazione in materia di sicurezza informatica al loro personale.

Le istituzioni finanziarie africane devono riconoscere l’importanza cruciale della sicurezza informatica nel panorama digitale attuale. Con l’aumento delle minacce informatiche, è fondamentale che queste istituzioni adottino misure proattive per proteggere i propri sistemi e clienti.

Investire in tecnologie e soluzioni d’avanguardia è essenziale per garantire la sicurezza dei sistemi finanziari. Ciò include l’implementazione di sistemi per il rilevamento e la prevenzione degli attacchi, che possono aiutare a identificare e bloccare le minacce in tempo reale.

La formazione in materia di sicurezza informatica è un altro aspetto fondamentale per la protezione delle istituzioni finanziarie africane. È importante che i dipendenti siano consapevoli delle minacce informatiche e sappiano come affrontarle, al fine di prevenire gli attacchi.

Le istituzioni finanziarie africane devono inoltre considerare l’implementazione di soluzioni di sicurezza avanzate, come l’autenticazione a due fattori e la crittografia dei dati. Queste soluzioni possono aiutare a proteggere i dati sensibili e a prevenire l’accesso non autorizzato.

La collaborazione tra le istituzioni finanziarie africane e le autorità di regolamentazione è fondamentale per affrontare le minacce informatiche. È importante che le autorità di regolamentazione forniscano linee guida e standard per la sicurezza informatica, al fine di aiutare le istituzioni finanziarie a implementare misure di sicurezza efficaci.

In conclusione, la sicurezza informatica è una priorità assoluta per le istituzioni finanziarie africane. Investendo in tecnologie e soluzioni d’avanguardia, implementando sistemi di rilevamento e prevenzione degli attacchi, fornendo formazione in materia di sicurezza informatica e collaborando con le autorità di regolamentazione, le istituzioni finanziarie africane possono proteggere i propri sistemi e clienti dalle minacce informatiche e garantire la stabilità del sistema finanziario.

L'articolo Crescita della criminalità informatica in Africa: sfide e soluzioni proviene da il blog della sicurezza informatica.

Nel corso di un’intervista al podcast Manifold, Omar Shams, responsabile del progetto Google Agents, ha sottolineato che oltre ai chip, l’altro grande limite allo sviluppo dell’IA è energetico. Spesso si pensa che l’innovazione passi solo da hardware più potenti, ma senza un’adeguata capacità di alimentazione, qualsiasi algoritmo avanzato rimane sulla carta.

Shams ha confrontato la crescita dell’energia elettrica tra Cina e Stati Uniti, evidenziando come la prima aumenti ogni anno quanto la produzione cumulata di paesi come Regno Unito e Francia. Negli USA, invece, le infrastrutture tendono a ristagnare a causa dei vincoli normativi. Un’assenza di potenza sufficiente significa che gli investimenti in IA potrebbero restare inespresso sul piano operativo .

Per superare questo vincolo, il manager ha proposto soluzioni che sembrano fantascientifiche: centrali solaris spaziali posizionate su orbita lunare o in punti di Lagrange, capaci di generare e trasmettere energia senza i limiti terrestri. Pur riconoscendo la difficoltà e i costi astronomici di una tale impresa, ritiene che sia una strada valida nel lungo termine.

Shams ha raccontato le sue esperienze in Mutable, startup pionieristica nel campo degli strumenti di programmazione assistita da IA, nata quasi contemporaneamente a GitHub Copilot. Tra i progetti chiave c’era “Auto Wiki”, un sistema che analizza il codice per generare documentazione automatica in stile wiki: un modo per semplificare la comprensione e sfruttare meglio i modelli linguistici .

Parlando di impatto sul lavoro, Shams ha spiegato che gli “smart agent” stanno rivoluzionando il settore software: i task ripetitivi e di base vengono delegati all’IA e l’incidenza dei programmatori junior diminuisce, lasciando spazio a figure più senior che possiedono esperienza tecnica e capacità di leadership per integrare e gestire questi agenti.

Infine, Shams ha ricordato che il successo dei progetti IA dipenderà sempre più da quel “sapere tacito” acquisito con anni di pratica, intuizione e capacità di giudizio, elementi che nessun algoritmo può sostituire. Per i giovani che investono sul loro futuro nel settore, il consiglio è chiaro: oltre a studiare, serve fare tanta esperienza “sul campo” e imparare a valutare contesti reali .

L'articolo L’IA bloccata dai limiti energetici, servono soluzioni spaziali innovative proviene da il blog della sicurezza informatica.

Magnetic Core memory was the RAM at the heart of many computer systems through the 1970s, and is undergoing something of a resurgence today since it is easiest form of memory for an enterprising hacker to DIY. [Han] has anexcellent writeup that goes deep in the best-practices of how to wire up core memory, that pairs with his512-bit MagneticCoreMemoryController on GitHub.

Magnetic core memory works by storing data inside the magnetic flux of a ferrite ‘core’. Magnetize it in one direction, you have a 1; the other is a 0. Sensing is current-based, and erases the existing value, requiring a read-rewrite circuit. You want the gory details? Check out [Han]’s writeup; he explains it better than we can, complete with how to wire the ferrites and oscilloscope traces to explain why you want to wiring them that way. It may be the most complete design brief to be written about magnetic core memory to be written this decade.

This little memory pack [Han] built with this information is rock-solid: it ran for 24 hours straight, undergoing multiple continuous memory tests — a total of several gigabytes of information, with zero errors. That was always the strength of ferrite memory, though, along with the fact you can lose power and keep your data. In in the retrocomputer world, 512 bits doesn’t seem like much, but it’s enough to play with. We’ve even featured smaller magnetic core modules, likethe Core 64. (No prize if you guess how many bits that is.) One could be excused for considering them toys; in the old days,you’d have had cabinets full of these sorts of hand-wound memory cards.

Magnetic core memory should not be confused withcore-rope memory, which was a ROM solution of similar vintage. The legendaryApollo Guidance Computer used both.

We’d love to see a hack that makes real use of these pre-modern memory modality– if you know of one, send in a tip.

hackaday.com/2025/07/11/get-ro…

Recently AI risk and benefit evaluation company METR ran a randomized control test (RCT) on a gaggle of experienced open source developers to gain objective data on how the use of LLMs affects their productivity. Their findings were that using LLM-based tools like Cursor Pro with Claude 3.5/3.7 Sonnet reduced productivity by about 19%, with the full study by [Joel Becker] et al. available as PDF.

This study was also intended to establish a methodology to assess the impact from introducing LLM-based tools in software development. In the RCT, 16 experienced open source software developers were given 246 tasks, after which their effective performance was evaluated.

A large focus of the methodology was on creating realistic scenarios instead of using canned benchmarks. This included adding features to code, bug fixes and refactoring, much as they would do in the work on their respective open source projects. The observed increase in the time it took to complete tasks with the LLM’s assistance was found to be likely due to a range of factors, including over-optimism about the LLM tool capabilities, LLMs interfering with existing knowledge on the codebase, poor LLM performance on large codebases, low reliability of the generated code and the LLM doing very poorly on using tactic knowledge and context.

Although METR suggests that this poor showing may improve over time, it seems fair to argue whether LLM coding tools are at all a useful coding partner.

hackaday.com/2025/07/11/measur…

Who doesn’t want an X-ray machine? But you need a special tube and super high voltage, right? [Project 326] says no, and produces a USB-powered device that uses a tube you can pick up two for a dollar. You might guess the machine doesn’t generate X-rays with a lot of energy, and you’d be right. But you can make up for it with long exposure times. Check out the video below, with host [Posh Arthur].

The video admits there are limitations, of course. We were somewhat sad that [Project 326] elected not to share the exact parts list and 3D printed files because in the unlikely event someone managed to hurt themselves with it, there could be a hysterical reaction. We agreed, though, that if you are smart enough to handle this, you’ll be smart enough to figure out how to duplicate it — it doesn’t look that hard, and there are plenty of not-so-subtle clues in the video.

The video points out that you can buy used X-ray tube for about $100, but then you need a 70kV power supply. A 1Z11 tube diode has the same basic internal structure, but isn’t optimized for the purpose. But it does emit X-rays as a natural byproduct of its operation, especially with filament voltage.

The high voltage supply needs to supply at least 1mA at about 20 kV. Part of the problem is that with low X-ray emission, you’ll need long exposure times and, thus, a power supply needs to be able to operate for an extended period. We wondered if you could reduce the duty cycle, which might make the exposure time even longer, but should be easier on the power supply.

The device features a wired remote, allowing for a slight distance between the user and the hot tube. USB power is supplied through a USB-C PD device, which provides a higher voltage. In this case, the project utilizes 20V, which is distributed to two DC-DC converters: one to supply the high-voltage anode and another to drive the filament.

To get the image, he’s using self-developing X-ray film made for dental use. It is relatively sensitive and inexpensive (about a dollar a shot). There are also some lead blocks to reduce stray X-ray emission. Many commercial machines are completely enclosed and we think you could do that with this one, if you wanted to.

You need something that will lie flat on the film. How long did it take? A leaf image needed a 50-minute exposure. Some small ICs took 16 hours! Good thing the film is cheap because you have to experiment to get the exposure correct.

This really makes us want to puzzle out the design and build one, too. If you do, please be careful. This project has a lot to not recommend it: high voltage, X-rays, and lead. If you laugh at danger and want a proper machine, you can build one of those, too.

youtube.com/embed/jLOBMBN8A4A?…

hackaday.com/2025/07/11/diy-x-…

Building a simple 8-bit computer is a great way to understand computing fundamentals, but there’s only so much you can learn by building a system around an existing processor. If you want to learn more, you’ll have to go further and build the CPU yourself, as [MINT] demonstrated with his EPROMINT project (video in Polish, but with English subtitles).

The CPU began when [MINT] began experimenting with uses for his collection of old memory chips, and quickly realized that they could do quite a bit more than store data. After building a development board for single-chip based programmable logic, he decided to build a full CPU out of (E)EPROMs. The resulting circuit spans four large pieces of perfboard, weighs in at over half a kilogram, and took several weeks of soldering to create.

The star of the system is the ALU, which runs an instruction set inspired by the Z80, but with some optimizations and added features. In particular, it has new operations for multiplication, division, bitstream operations, more advanced bit shifting, and a wide range of mathematical functions, including exponents, roots, and trigonometric functions. [MINT] documented all of this in a nicely-formatted offline booklet, available under the project’s GitHub repository. It’s currently only possible to program for the CPU using opcodes or a custom flavor of assembly, but there are plans to write a C compiler for it.

Even without being able to write in a higher-level language than assembly, [MINT] was able to drive a VFD screen with the EPROMINT, which he used to display some clips from The Matrix. This provided an opportunity to demonstrate basic debugging methods, which involved dumping and analyzing the memory contents after a failed program execution.

Using memory chips as programmable logic gates is an interesting hack, and we’ve seen Lisp programs written to make this easier. Of course, this isn’t the first CPU we’ve seen built without any chips intended for logic operations.

youtube.com/embed/xBB1nAUvuqU?…

Thanks to [Piotr] for the tip!

hackaday.com/2025/07/11/design…

Sixteen Israeli experts in international law warned in a public letter that the plans presented by Israel's defense minister to concentrate Gaza's population in a "humanitarian city" constitute a manifestly illegal order and a war crime.

us18.campaign-archive.com/?e=0…

Over on YouTube, [Technology Connections] has a new video: Induction lamps: fluorescent lighting’s final form.

This video is about a wireless fluorescent light which uses induction to transfer power from the electrical system into the lamp. As this lamp doesn’t require wiring it is not prone to “sputtering” as typical fluorescent lights are, thus improving the working life by an order of magnitude. As explained in the video sputtering is the process where the electrodes in a typical fluorescent lamp lose their material over time until they lose their ability to emit electrons at all.

This particular lamp has a power rating of 200 W and light output of 16,000 lumens, which is quite good. But the truly remarkable thing about this type of lighting is its service life. As the lamp is simply a phosphor-coated tube filled with argon gas and a pellet of mercury amalgam it has a theoretically unlimited lifespan. Or let’s call it 23 years.

Given that the service life is so good, why don’t we see induction lamps everywhere? The answer is that the electronics to support them are very expensive, and these days LED lighting has trounced every lighting technology that we’ve ever made in terms of energy efficiency, quality of light, and so on. So induction lamps are obsolete before they ever had their day. Still pretty interesting technology though!

youtube.com/embed/SaKKzZRrPIg?…

Thanks to [Keith Olson] for writing in about this one.

hackaday.com/2025/07/11/an-ind…

My first encounter with C++ was way back in the 1990s, when it was one of the Real Programming Languages that I sometimes heard about as I was still splashing about in the kiddie pool with Visual Basic, PHP and JavaScript. The first formally standardized version of C++ is the ISO 1998 standard, but it had been making headways as a ‘better C’ for decades at that point since Bjarne Stroustrup added that increment operator to C in 1979 and released C++ to the public in 1985.

Why did I pick C++ as my primary programming language? Mainly because it was well supported and with free tooling: a free Borland compiler or g++ on the GCC side. Alternatives like VB, Java, and D felt far too niche compared to established languages, while C++ gave you access to the lingua franca of C while adding many modern features like OOP and a more streamlined syntax in addition to the Standard Template Library (STL) with gobs of useful building blocks.

Years later, as a grizzled senior C++ developer, I have come to embrace the notion that being good at a programming language also means having strong opinions on all that is wrong with the language. True to form, while C++ has many good points, there are still major warts and many heavily neglected aspects that get me and other C++ developers riled up.

Why We Fell In Love

Cover of the third edition of The C++ Programming Language by Bjarne Stroustrup.
What frightened me about C++ initially was just how big and scary it seemed, with gargantuan IDEs like Microsoft’s Visual Studio, complex build systems, and graphical user interface that seemed to require black magic far beyond my tiny brain’s comprehension. Although using the pure C-based Win32 API does indeed require ritual virgin sacrifices, and Windows developers only talk about MFC when put under extreme duress, the truth is that C++ itself is rather simple, and writing complex applications is easy once you break it down into steps. For me the breakthrough came after buying a copy of Stroustrup’s The C++ Programming Language, specifically the third edition that covered the C++98 standard.

More than just a reference, it laid out clearly for me not only how to write basic C++ programs, but also how to structure my code and projects, as well as the reasonings behind each of these aspects. For many years this book was my go-to resource, as I developed my rudimentary, scripting language-afflicted skills into something more robust.

Probably the best part about C++ is its flexibility. It never limits you to a single programming paradigm, while it gives you the freedom to pick the desire path of your choice. Although an astounding number of poor choices can be made here, with a modicum of care and research you do not have to end up hoisted with your own petard. Straying into the C-compatibility part of C++ is especially fraught with hazards, but that’s why we have the C++ bits so that we don’t have to touch those.

Reflecting With C++11

It would take until 2011 for the first major update to the C++ standard, by which time I had been using C++ mostly for increasingly more elaborate hobby projects. But then I got tossed into a number of commercial C and C++ projects that would put my burgeoning skills to the test. Around this time I found the first major items in C++ that are truly vexing.

Common issues like header-include order and link order, which can lead to circular dependencies, are some of such truly delightful aspects. The former is mostly caused by the rather simplistic way that header files are just slapped straight into the source code by the preprocessor. Like in C, the preprocessor simply looks at your #include "widget/foo.h" and replaces it with the contents of foo.h with absolutely no consideration for side effects and cases of spontaneous combustion.

Along the way, further preprocessor statements further mangle the code in happy-fun ways, which is why the GCC g++ and compatible compilers like Clang have the -E flag to only run the preprocessor so that you can inspect the preprocessed barf that was going to be sent to the compiler prior to it violently exploding. The trauma suffered here is why I heartily agree with Mr. Stroustrup that the preprocessor is basically evil and should only be used for the most basic stuff like includes, very simple constants and selective compilation. Never try to be cute or smart with the preprocessor or whoever inherits your codebase will find you.

If you got your code’s architectural issues and header includes sorted out, you’ll find that C++’s linker is just as dumb as that of C. After being handed the compiled object files and looking at the needed symbols, it’ll waddle into the list of libraries, look at each one in order and happily ignore previously seen symbols if they’re needed later. You’ll suffer for this with tools like ldd and readelf as you try to determine whether you are just dense, the linker is dense or both are having buoyancy issues.

These points alone are pretty traumatic, but you learn to cope with them like you cope with a gaggle of definitely teething babies a few rows behind you on that transatlantic flight. The worst part is probably that neither C++11 nor subsequent standards have addressed either to any noticeable degree, with a shift from C-style compile units to Ada-like modules probably never going to happen.

The ‘modules at home‘ feature introduced with C++20 are effectively just limited C-style headers without the preprocessor baggage, without the dependency analysis and other features that make languages like Ada such a joy to build code with.

Non-Deterministic Initialization

Although C++ and C++11 in particular removes a lot of undefined behavior that C is infamous for, there are still many parts where expected behavior is effectively random or at least platform-specific. One such example is that of static initialization, officially known as the Static initialization order fiasco. Essentially what it means is that you cannot count on a variable declared static to be initialized during general initialization between different compile units.

This also affects the same compile units when you are initializing a static std::map instance with data during initialization, as I learned the hard way during a project when I saw random segmentation faults on start-up related to the static data structure instance. The executive summary here is that you should not assume that anything has been implicitly initialized during application startup, and instead you should do explicit initialization for such static structures.

An example of this can be found in my NymphRPC project, in which I used this same solution to prevent initialization crashes. This involves explicitly creating the static map rather than praying that it gets created in time:
static map<UInt32, NymphMethod*> &methodsIdsStatic = NymphRemoteClient::methodsIds();
With the methodsIds() function:
map<UInt32, NymphMethod*>& NymphRemoteClient::methodsIds() {
static map<UInt32, NymphMethod*>* methodsIdsStatic = new map<UInt32, NymphMethod*>();
return *methodsIdsStatic;
}
It are these kind of niggles along with the earlier covered build-time issues that tend to sap a lot of time during development until you learn to recognize them in advance along with fixes.

Fading Love

Don’t get me wrong, I still think that C++ is a good programming language at its core, it is just that it has those rough spots and sharp edges that you wish weren’t there. There is also the lack of improvements to some rather fundamental aspects in the STL, such as the unloved C++ string library. Compared to Ada standard library strings, the C++ STL string API is very barebones, with a lot of string manipulation requiring writing the same tedious code over and over as convenience functions are apparently on nobody’s wish list.

One good thing that C++11 brought to the STL was multi-tasking support, with threads, mutexes and so on finally natively available. It’s just a shame that its condition variables are plagued by spurious wake-ups and a more complicated syntax than necessary. This gets even worse with the Filesystem library that got added in C++17. Although it’s nice to have more than just basic file I/O in C++ by default, it is based on the library in Boost, which uses a coding style, type encapsulation obsession, and abuse of namespaces that you apparently either love or hate.

I personally have found the POCO C++ libraries to be infinitely easier to use, with a relatively easy to follow implementation. I even used the POCO libraries for the NPoco project, which adapts the code to microcontroller use and adds FreeRTOS support.

Finally, there are some core language changes that I fundamentally disagree with, such as the addition of type inference with the auto keyword outside of templates, which is a weakly typed feature. As if it wasn’t bad enough to have the chaos of mixed explicit and implicit type casting, now we fully put our faith into the compiler, pray nobody updates code elsewhere that may cause explosions later on, and remove any type-related cues that could be useful to a developer reading the code.

But at least we got [url=https://en.cppreference.com/w/cpp/language/constexpr.html]constexpr[/url], which is probably incredibly useful to people who use C++ for academic dissertations rather than actual programming.

Hope For The Future

I’ll probably keep using C++ for the foreseeable future, while grumbling about all of ’em whippersnappers adding useless things that nobody was asking for. Since the general take on adding new features to C++ is that you need to do all the legwork yourself – like getting into the C++ working groups to promote your feature(s) – it’s very likely that few actually needed features will make it into new C++ standards, as those of us who are actually using the language are too busy doing things like writing production code in it, while simultaneously being completely disinterested in working group politics.

Fortunately there is excellent backward compatibility in C++, so those of us in the trenches can keep using the language any way we like along with all the patches we wrote to ease the pains. It’s just sad that there’s now such a split forming between C++ developers and C++ academics.

It’s one of the reasons why I have felt increasingly motivated over the past years to seek out other languages, with Ada being one of my favorites. Unlike C++, it doesn’t have the aforementioned build-time issues, and while its super-strong type system makes getting started with writing the business logic slower, it prevents so many issues later on, along with its universal runtime bounds checking. It’s not often that using a programming language makes me feel something approaching joy.

Giving up on a programming language with which you quite literally grew up is hard, but as in any relationship you have to be honest about any issues, no matter whether it’s you or the programming language. That said, maybe some relationship counseling will patch things up again in the future, with us developers are once again involved in the language’s development.

hackaday.com/2025/07/11/deares…

This week, Hackaday’s Elliot Williams and Kristina Panos joined forces to bring you the latest news, mystery sound, and of course, a big bunch of hacks from the previous week.

In Hackaday news, the One Hertz Challenge ticks on. You have until Tuesday, August 19th to show us what you’ve got, so head over to Hackaday.IO and get started now! In other news, we’ve just wrapped the call for Supercon proposals, so you can probably expect to see tickets for sale fairly soon.

On What’s That Sound, Kristina actually got this one with some prodding. Congratulations to [Alex] who knew exactly what it was and wins a limited edition Hackaday Podcast t-shirt!

After that, it’s on to the hacks and such, beginning with a ridiculously fast Benchy. We take a look at a bunch of awesome 3D prints a PEZ blaster and a cowbell that rings true. Then we explore chisanbop, which is not actually K-Pop for toddlers, as well as a couple of clocks. Finally, we talk a bit about dithering before taking a look at the top tech of 1985 as shown in Back to the Future (1985).

Check out the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

html5-player.libsyn.com/embed/…

Download in DRM-free MP3 and savor at your leisure.

Where to Follow Hackaday Podcast

Places to follow Hackaday podcasts:

• iTunes
• Spotify
• Stitcher
• RSS
• YouTube
• Check out our Libsyn landing page

Episode 328 Show Notes:

News:

• Announcing The 2025 Hackaday One Hertz Challenge

What’s that Sound?

• Congratulations to [Alex] for knowing it was the Scientist NPC from Half-Life.

Interesting Hacks of the Week:

• Managing Temperatures For Ultrafast Benchy Printing
  
  • 3D-Printed Parts Don’t Slow Down This Speedy Printer

  
  

• When Is A Synth A Woodwind? When It’s A Pneumatone
• Budget Brilliance: DHO800 Function Generator
  
  • Android-Powered Rigol Scopes Go Wireless

  
  

• I Gotta Print More Cowbell
• Kids Vs Computers: Chisanbop Remembered
• Pez Blaster Shoots Candy Dangerously Fast
  
  • Hackaday Supercon 2024: Lightning Talks – YouTube

  
  

Quick Hacks:

• Elliot’s Picks:
  
  • IR Point And Shoot Has A Raspberry Heart In A 35mm Body
  • Turning PET Plastic Into Paracetamol With This One Bacterial Trick
  • Five-minute(ish) Beanie Is The Fastest We’ve Seen Yet

  
  

• Kristina’s Picks:
  
  • CIS-4 Is A Monkish Clock Inside A Ceiling Lamp
  • 3D Printer Turbo-Charges A Vintage Vehicle
  • Shadow Clock Shows The Time On The Wall

  
  

Can’t-Miss Articles:

• Dithering With Quantization To Smooth Things Over
• Back To The Future, 40 Years Old, Looks Like The Past

hackaday.com/2025/07/11/hackad…

Il laboratorio di ricerca Security Explorations ha presentatoi risultati di mesi di lavoro volti a svelarevulnerabilità nel cuore della tecnologia eSIM. L’attenzione si è concentrata sulla scheda eUICC di Kigen, certificata secondo gli standard GSMA e basata su un’implementazione proprietaria della macchina virtuale Java Card.

Nonostante i meccanismi di sicurezza multistrato dichiarati, tra cui la certificazione EAL4+, l’isolamento della memoria integrato e la resistenza agli attacchi di terze parti, il prodotto era suscettibile a un attacco riuscito che non solo consentiva il controllo dell’eSIM, ma dimostrava anche un crollo completo del modello di sicurezza affidabile nell’ecosistema eUICC.

La ricerca ha dimostrato che le vulnerabilità segnalate da Security Explorations nel 2019, ma all’epoca ignorate, non sono solo reali, ma anche potenzialmente devastanti. All’epoca, Oracle definì questi problemi “preoccupanti” e si rifiutò di riconoscerne la criticità. Oggi è chiaro: i bug ignorati nell’implementazione del bytecode di Java Card, come il type confusion tra oggetti e array, non sono stati risolti né nell’implementazione di riferimento di Oracle né in prodotti di terze parti come Kigen eUICC.

Security Explorations ha compromesso con successo una scheda eUICC Kigen, incluso il profilo di test TS.48, simulando l’installazione di un’applicazione Java dannosa sul canale SMS-PP. L’attacco ha estratto la chiave privata ECC che identifica la scheda GSMA, consentendo all’attaccante di scaricare e decriptare senza problemi i profili eSIM di diversi operatori di telefonia mobile, tra cui AT&T, Vodafone, Orange, T-Mobile e altri. Questi profili contenevano non solo impostazioni di rete, ma anche chiavi OTA sensibili, ID abbonato, applicazioni Java e parametri di servizio. In alcuni casi, le applicazioni estratte potevano essere modificate e reinstallate senza essere rilevate dall’operatore.

Uno dei test più significativi è stato un attacco alla rete Orange. I ricercatori hanno dimostrato la possibilità di clonazione di eSIM: un profilo duplicato installato su un altro dispositivo ha permesso l’intercettazione di chiamate e SMS in arrivo. Mentre il dispositivo malevolo era acceso, l’utente legittimo non ha ricevuto alcun messaggio, che la rete ha considerato recapitato. Tale comportamento minaccia non solo la privacy, ma anche l’affidabilità dei servizi di autenticazione a due fattori utilizzati da banche, servizi postali e altri sistemi critici.

Kigen ha riconosciuto la vulnerabilità e ha iniziato a collaborare con i ricercatori. L’azienda ha pagato una ricompensa di 30.000 dollari per un rapporto tecnico dettagliato e ha accettato un periodo di riservatezza di 90 giorni prima della pubblicazione. In seguito all’analisi, sono stati effettuati tentativi di eliminare la vulnerabilità implementando il controllo dei tipi in tutti i bytecode di Java Card. Tuttavia, Security Explorations ha osservato che il tentativo era formale e inefficace: il sistema controllava solo la parte superiore dello stack senza tracciare il flusso di controllo, il che lasciava decine di scenari vulnerabili. In altre parole, il “controllo universale” introdotto si è rivelato non funzionale, lasciando oltre 100 potenziali punti per gli attacchi.

In risposta alle vulnerabilità, la GSMA ha rivisto la specifica TS.48 per disabilitare la possibilità di installare applicazioni Java nei profili di test. Ha inoltre pubblicato un documento speciale con raccomandazioni per gli operatori del settore, che sottolinea la necessità di controllare le chiavi di gestione remota delle applicazioni. Tuttavia, i ricercatori ritengono che questi passaggi siano poco convincenti e non risolvano la radice del problema: una debolezza architetturale nella macchina virtuale Java Card, su cui è basato l’intero ecosistema eSIM.

È interessante notare che Kigen, nonostante la sua dichiarata indipendenza da Oracle, ha creato una propria implementazione della macchina virtuale, che tuttavia riproduceva gli stessi errori concettuali riscontrati nella Java Card Reference Implementation di Oracle. Allo stesso tempo, l’azienda ha dichiarato di non essere a conoscenza delle vulnerabilità segnalate da Security Explorations nel 2019. Tuttavia, secondo i ricercatori, un tentativo di contattare Kigen è stato effettuato già a novembre 2020 tramite un modulo di feedback dopo il webinar congiunto dell’azienda con Orange.

Uno dei risultati più allarmanti è stato che i server di Remote SIM Provisioning, inclusi quelli di IDEMIA e Thales, non riconoscevano i certificati eUICC compromessi. Ciò indica una mancanza sistemica di convalida e monitoraggio, che consente attacchi su larga scala senza essere rilevati. Inoltre, l’analisi ha mostrato che molte eSIM non implementano la verifica completa del bytecode Java Card, nonostante le raccomandazioni in tal senso contenute nella specifica SGP.25.

Il set di strumenti utilizzato dagli esperti ha permesso non solo di hackerare le schede ed estrarne il contenuto, ma anche di verificare la presenza di problemi di sicurezza tipici delle Java Card. È in grado di controllare automaticamente memoria, stack, variabili locali ed eseguire analisi del bytecode. Questi strumenti sono stati utilizzati sia per l’analisi eUICC di Kigen che per test su reti reali.

Gli autori dello studio sottolineano che il loro lavoro è stato svolto a proprie spese, senza finanziamenti esterni e, con un adeguato supporto, sarebbero pronti a fornire i risultati gratuitamente a tutti i membri GSMA. L’obiettivo dello studio è dimostrare il valore dell’analisi di sicurezza indipendente e l’importanza di prestare attenzione a dettagli sistematicamente ignorati dal settore per molti anni.

L'articolo Vulnerabilità critiche nella tecnologia eSIM: un attacco può compromettere la rete di qualsiasi operatore proviene da il blog della sicurezza informatica.