The Juno spacecraft was launched towards Jupiter in August of 2011 as part of the New Frontiers series of spacecraft, on what would originally have been a 7-year mission, including a nearly 5 year cruise to the planet. After a mission extension, it’s currently orbiting Jupiter, allowing for many more years of scientific data to be gathered using its instruments. One of these instruments is the JunoCam (JCM), a visible light camera and telescope. Unfortunately the harsh radiation environment around Jupiter had led many to believe that this camera would fail before long. Now it seems that NASA engineers have successfully tested a fix.
Location of the Juno spacecraft’s science instruments.
Although the radiation damage to JCM was obvious a few dozen orbits in – and well past its original mission’s 34 orbits – the big question was exactly was being damaged by the radiation, and whether something could be done to circumvent or fix it. The good news was that the image sensor itself was fine, but one of the voltage regulators in JCM’s power supply was having a bad time. This led the engineers to try annealing the affected part by cranking up one of the JCM’s heaters to a balmy 25°C, well above what it normally is kept at.

This desperate step seemed to work, with massively improved image quality on the following orbits, but soon the images began to degrade again. Before an approach to Jupiter’s moon Io, the engineers thus tried it again but this time cranked the JCM’s heater up to eleven and crossed their fingers. Surprisingly this fixed the issue over the course of a week, until the JCM seems as good as new. Now the engineers are trying their luck with Juno‘s other instruments as well, with it potentially providing a blueprint for extending the life of spacecraft in general.

Thanks to [Mark Stevens] for the tip.

hackaday.com/2025/07/23/anneal…

La Red Hot Cyber Conference ritorna!

Dopo il grande successo della terza e quarta edizione, torna l’appuntamento annuale gratuito ideato dalla community di RHC! Un evento pensato per avvicinare i più giovani alle tecnologie digitali e, allo stesso tempo, una conferenza dedicata a professionisti ed esperti del settore.

La nuova edizione della RHC Conference 2026 si svolgerà a Roma, nella stessa location delle ultime due edizioni, presso la prestigiosa cornice del Teatro Italia nei giorni lunedì 18 e martedì 19 maggio 2026. Il Teatro Italia si trova in Via Bari, 18 00161 Roma e può ospitare fino ad 800 persone.

La location risulta distante:

• 2 km dalla Stazione Termini o dall’Università La Sapienza, raggiungibile con una passeggiata a piedi di circa 20 minuti o con 6 minuti di Taxi;
• 600 metri dalla stazione della Metro B di Piazza Bologna, raggiungibile con una passeggiata di 6 minuti a piedi o con 3 minuti di Taxi.

youtube.com/embed/J1i9S4LOWSA?…
Video riassunto della Red Hot Cyber Conference 2025

La quarta edizione del 2025

La quarta edizione della Red Hot Cyber Conference si è svolta a Roma il 19 e 20 aprile 2024, registrando oltre 800 partecipanti effettivi e più di 1.400 iscrizioni complessive.

Durante le due entusiasmanti giornate, si sono tenuti workshop pratici ‘hands-on’, la competizione di hacking ‘Capture The Flag’ (CTF), e una conferenza in cui numerosi esperti italiani, provenienti sia dal settore privato che pubblico, hanno condiviso le loro conoscenze sul palco.

Di seguito potete trovare una serie di link che mostrano le due giornate del 2025, compresi i video degli interventi.

• I Workshop “Hands On”
• La Capture The Flag (CTF)
• Gli Ospiti
• La Conferenza
• I Video dell’evento

Accoglienza alla Red Hot Cyber Conference 2024 Persone in fila per l’accoglienza alla Red Hot Cyber Conference 2024 Una foto dello STAFF Al completo della Red Hot Cyber Conference 2024Immagini dell’evento del 2025

Come si articolerà la Red Hot Cyber Conference 2026

Visto il format vincente della scorsa edizione, il programma della Red Hot Cyber Conference 2026 sarà articolato in modo simile all’edizione del 2025.

A differenza delle prime tre edizioni, i workshop “hands-on” si terranno nella sola giornata di lunedì 18 Maggio, mentre la Conferenza sarà l’unica protagonista della scena di martedì 19 Maggio. In entrambe le giornate, in una location parallela al teatro si terrà la capture the flag (CTF), con la premiazione prevista alla fine della giornata di martedì 19 maggio. Di seguito il programma (ancora in bozza) delle due giornate.

Lunedì 18 Maggio

• Workshop “hands-on”: In tarda mattinata verranno avviati i Workshop pratici, incentrati nell’approccio “hands-on”. Durante questi workshop, verranno affrontati temi quali ethical hacking, intelligenza artificiale e altro ancora. I partecipanti, muniti del proprio laptop, avranno l’opportunità di ascoltare i workshop e poi cimentarsi nello svolgere gli esercizi pratici supervisionati dai nostri esperti per poter toccare con mano la tecnologia. I workshop termineranno la sera dell’18 maggio;
• Capture The Flag (CTF): Nel pomeriggio, partirà anche la Capture The Flag (CTF) che terminerà il 19 Maggio alle ore 17:00. Si tratta di una competizione tra hacker etici che si terrà sia online che presso il Teatro Italia. I partecipanti presenti presso il Teatro Italia (i quali avranno una sala dedicata per poter partecipare), avranno la possibilità di sfidarsi in “flag fisiche” appositamente progettate da Red Hot Cyber per cimentarsi in attacchi locali RF/IoT. Queste attività forniranno la possibilità di accumulare maggiore punteggio per salire nella classifica. Sarà possibile cimentarsi nelle flag fisiche in entrambe le giornate.

Martedì 19 maggio

• Red Hot Cyber Conference: La giornata sarà interamente dedicata alla RHC Conference, un evento di spicco nel campo della sicurezza informatica. Il programma prevede un panel con ospiti istituzionali che si terrà all’inizio della conferenza. Successivamente, numerosi interventi di esperti nel campo della sicurezza informatica si susseguiranno sul palco fino alle ore 19:00 circa, quando termineranno le sessioni. Prima del termine della conferenza, ci sarà la premiazione dei vincitori della Capture The Flag prevista per le ore 18:00.

Si precisa che i Workshop non saranno disponibili nella giornata di martedì 19 di maggio ma solo nella giornata di lunedì 18 Maggio.

Il Programma Sponsor per la Red Hot Cyber Conference 2026

Come negli scorsi anni, sarà presente la possibilità di adesione come “sponsor sostenitore”. Si tratta delle prime aziende che crederanno in questa iniziativa e che permetteranno a Red Hot Cyber di avviare i lavori relativi alla conferenza.

Oltre agli sponsor sostenitori, come di consueto saranno presenti 3 livelli di sponsorizzazione che sono rispettivamente Platinum, Gold e Silver. Solo i Sostenitori e i Platinum avranno la possibilità di svolgere uno speech all’interno della conferenza. Abbinati ad ogni sponsorizzazione della conferenza, sarà sempre presente un pacchetto di Advertising che permetterà agli sponsor di disporre di una serie di vantaggi all’interno del circuito Red Hot Cyber.

Solo una azienda potrà aggiudicarsi la “Workshop Sponsorship”, un’opportunità unica per assumere un ruolo centrale nell’evento e collaborare fianco a fianco con Red Hot Cyber nell’organizzazione della giornata dedicata ai workshop pratici “hands-on” rivolti ai ragazzi. Anche per il 2026, per la terza edizione consecutiva, Accenture Italia sarà partner di Red Hot Cyber, con l’obiettivo di trasmettere ai giovani la passione per il mondo digitale.

Per richiedere informazioni per la sponsorizzazione della Red Hot Cyber Conference 2026 oltre che accedere al “Media Kit” e alle altre informazioni che riassumono i vantaggi della sponsorizzazione, scrivete a sponsor@redhotcyber.com.

La Red Hot Cyber Conference 2026 è orgogliosa di avere al suo fianco alcuni dei principali attori del panorama tecnologico e della cybersecurity, come Media Partner: i Fintech Awards Italia, Cyber Actors, Università E-Campus, Women4Cyber, Ri-Creazione, la Federazione Italiana Dei Combattenti Alleati e il Digital Security Summit e AIPSI. Queste collaborazioni rafforzano l’impegno comune nel promuovere la sicurezza digitale e la formazione per un futuro sempre più consapevole e sicuro.

L'articolo Red Hot Cyber Conference 2026. La Quinta edizione a Roma lunedì 18 e martedì 19 Maggio proviene da il blog della sicurezza informatica.

Nel febbraio 2025 avevamo già osservato il funzionamento di DDoSIA, il sistema di crowd-hacking promosso da NoName057(16): un client distribuito via Telegram, attacchi DDoS contro obiettivi europei, premi in criptovalute.
Una macchina semplice, brutale, ma efficace.

Il suo punto di forza non è la sofisticazione tecnica, ma la capacità di mobilitare rapidamente migliaia di utenti, anche privi di esperienza, trasformandoli in cyber-mercenari occasionali. Bastano uno smartphone, un canale Telegram e un link di download per entrare nella “guerra patriottica”. Nessuna formazione, nessuna competenza, solo click automatizzati e una dashboard con i bersagli assegnati.

Poi è arrivata l’Operazione Eastwood, guidata [strong]nei giorni scorsi da Europol, che ha portato allo smantellamento di oltre 100 server in cinque Paesi europei, con arresti in Francia e Spagna.[/strong]

Ma ciò che emerge va oltre l’immagine dell’attivismo patriottico: prende forma un ecosistema dove propaganda, infrastrutture digitali e strumenti di controllo culturale si intrecciano. Un sistema che colpisce bersagli informatici, ma che — in parallelo — intercetta e indirizza identità, giovani e narrazioni.

L’illusione del volontariato: un comando silenzioso

Nei mesi scorsi, un pattern ricorrente ha sollevato sospetti. Più volte, una stessa macchina è apparsa in un database pubblico per attività di port scanning aggressivo, proprio nelle stesse ore in cui NoName057(16) rivendicava attacchi DDoS su Telegram. Un esempio emblematico: l’8 luglio e poi il 14 luglio. Stesso comportamento, stessa macchina, nuova rivendicazione. Analizzando il client DDoSia, distribuito ai volontari, emerge un dettaglio cruciale: un endpoint remoto non dichiarato nel codice. Questo serverC2 (Command and Control) agisce come un ‘cervello’ nascosto, inviando comandi criptati per coordinare attacchi simultanei.

Nessun annuncio pubblico, nessun messaggio su Telegram. Solo un task. Non è un attacco spontaneo. È un ordine distribuito.

Questo conferma, se mai ce ne fosse stato bisogno, che il client non è soltanto uno strumento distribuito per “volontari patriottici”, ma riflette una logica centralizzata e funzionale, che solleva dubbi sull’autonomia effettiva del collettivo.
NoName057(16) si configura così non solo come una community, ma come una possibile interfaccia tecnica di un sistema più esteso, in cui compaiono nomi, ruoli e infrastrutture riconducibili — direttamente o indirettamente — a contesti istituzionali

Oltre il client: chi c’è dietro?

Il sistema funziona. Il client attacca. Il messaggio circola.

Ma chi lo ha costruito? Chi lo comanda davvero?

Due nomi cominciano a emergere: Maxim Lupin e Mihail Burlakov.

Grazie all’operazione Eastwood, i mandati internazionali e le evidenze OSINT, emergono due figure chiave:

• Maxim Nikolaevič Lupin: Direttore Generale del CISM (Centro per lo Studio e il Monitoraggio dell’Ambiente Giovanile);
• Mihail Evgenyevich Burlakov: professore associato in cybersecurity all’Università aerospaziale di Samara, e vice-direttore dello stesso CISM.

Burlakov è noto nei canali Telegram del gruppo come ddosator3000 o @darkklogo. Risulta premiato nei ranking interni del malware DDoSia. Secondo Europol, ha progettato il codice del client, affittato server illegali per la gestione degli attacchi e partecipato attivamente alla distribuzione del software.

Il suo numero di telefono, pubblicato nei contatti ufficiali dell’università, è associato a un profilo Telegram registrato proprio con l’alias @darkklogo. Gli indirizzi IP collegati a quell’utenza risultano non anonimizzati e riconducibili a una zona ad alta densità istituzionale: il Cremlino

Nessuna precauzione. Nessun anonimato. Solo la certezza dell’impunità.

Meno esposto nei canali tecnici, ma centrale nella struttura, è Maxim Nikolaevič Lupin, direttore generale del CISM e figura istituzionale legata a progetti educativi, di sicurezza dell’informazione e “prevenzione ideologica”.

Lupin è accreditato presso la Presidenza della Federazione Russa. Ha lavorato come specialista in sicurezza informatica per l’organizzazione filogovernativa dei veterani Combat Brotherhood e come project manager per ZephyrLab, una società che sviluppa siti web per ministeri federali. È anche sospettato di gestire una piattaforma di trading online illegale.

Se Burlakov scrive il codice, Lupin ne decide l’uso

Il CISM: la macchina ideologica

Il Centro per lo Studio e il Monitoraggio della Gioventù (CISM) non è un centro studi.
Nato su impulso diretto del Cremlino, riceve oltre 2 miliardi di rubli per progetti che mirano, ufficialmente, a “proteggere i giovani da contenuti distruttivi”.

In realtà, è un’infrastruttura che fonde:

• algoritmi di sorveglianza,
• classificazione semantica automatica,
• schedatura psicopolitica.

Il cuore tecnologico del CISM è il sistema AIS “Prevenzione”, che scandaglia oltre 540 milioni di profili social analizzando post, like, emoji, commenti, hashtag, silenzi.

Ogni adolescente riceve due indici:

• un coefficiente di distruttività (comportamento, vocabolario, tono);
• un indice di opposizione (posizioni politiche, relazioni, appartenenze).

I dati vengono de-anonimizzati, profilati e segnalati.
Secondo i documenti trapelati dal Cremlino e analizzati nel progetto investigativo Kremlin Leaks — a cura di Der Spiegel, iStories, VSquare e Frontstory.pl — il sistema è attualmente attivo in almeno 44 regioni russe ed è in fase di integrazione con i database del Ministero dell’Interno.

È intelligenza artificiale al servizio dell’ideologia.

I bambini ucraini deportati

Il CISM lavora a stretto contatto con il Ministero dell’Istruzione e il Centro federale RPSP per gestire i minori deportati dai territori ucraini occupati.

Il modello è chiaro:

• identificazione,
• classificazione psicologica,
• rieducazione comportamentale.

Secondo documenti interni ottenuti da Meduza, il Ministero dell’Istruzione ha avviato un monitoraggio sistematico dei minori adottati provenienti dalle regioni occupate. Nella prima metà del 2023, almeno cinque bambini sono deceduti. In un caso documentato, si è trattato di suicidio. Le cause non sono state rese note.

In risposta, è stato attivato un “lavoro preventivo” che include il coinvolgimento diretto del CISM: dietro la retorica della tutela si cela un sistema di sorveglianza algoritmica. Il Centro elabora profili psico-sociali di rischio, ma non per offrire sostegno: l’obiettivo è classificare i minori in base alla loro “devianza”, “opposizione” o fragilità ideologica.

Ogni adolescente schedato riceve una scheda personale con dati identificativi, tracciamento online e indicatori predittivi generati da reti neurali, usati per segnalazioni alle autorità. Il risultato è una schedatura automatizzata basata su comportamenti digitali e opinioni politiche, che cancella ogni anonimato.

Non ci sono prove che il CISM, come istituzione, sia direttamente coinvolto negli attacchi. Ma quando sia il direttore che il vice direttore risultano legati alle stesse infrastrutture usate da NoName057(16), il confine tra “tutela giovanile” e operazioni cibernetiche diventa sempre più sottile. E sempre meno credibile.

Conclusione

NoName057(16), DDoSIA, CISM, AIS Prevenzione, @darkklogo, Maxim Lupin.
Questi nomi compaiono in contesti diversi, ma a volte si sfiorano, si sovrappongono, si parlano.

Non c’è una prova che li unisca in modo diretto.
Ma ci sono pattern, coincidenze temporali, ruoli doppi, infrastrutture condivise.
E soprattutto: assenze strategiche di anonimato, come se non fosse necessario nascondere nulla.

Forse non è un’operazione centralizzata. Forse sì.
Quel che è certo è che non tutto ciò che appare spontaneo lo è davvero.
Il rischio oggi non è solo tecnico, ma culturale.

E capire dove finisce il rumore digitale e dove comincia un disegno strutturato è il primo passo per difendere non solo i server, ma anche la nostra capacità di leggere il presente.

Perché quando algoritmi ideologici schedano i bambini come “oppositivi”, e quando gli stessi architetti digitali progettano sia strumenti di rieducazione che piattaforme d’attacco, il confine tra cybersicurezza e controllo sociale diventa troppo sottile per essere ignorato.

L'articolo Codice Patriottico: da DDoSia e NoName057(16) al CISM, l’algoritmo che plasma la gioventù per Putin proviene da il blog della sicurezza informatica.

The flow battery is one of the more interesting ideas for grid energy storage – after all, how many batteries combine electron current with fluid current? If you’re interested in trying your hand at building one of these, the scientists behind the Flow Battery Research Collective just released the design and build instructions for a small zinc-iodide flow battery.

The battery consists of a central electrochemical cell, divided into two separated halves, with a reservoir and peristaltic pump on each side to push electrolyte through the cell. The cell uses brass-backed grafoil (compressed graphite sheets) as the current collectors, graphite felt as porous electrodes, and matte photo paper as the separator membrane between the electrolyte chambers. The cell frame itself and the reservoir tanks are 3D printed out of polypropylene for increased chemical resistance, while the supporting frame for the rest of the cell can be printed from any rigid filament.

The cell uses an open source potentiostat to control charge and discharge cycles, and an Arduino to control the peristaltic pumps. The electrolyte itself uses zinc chloride and potassium iodide as the main ingredients. During charge, zinc deposits on the cathode, while iodine and polyhalogen ions form in the anode compartment. During charge, zinc redissolves in what is now the anode compartment, while the iodine and polyhalogen ions are reduced back to iodides and chlorides. Considering the stains that iodide ions can leave, the researchers do advise testing the cell for leaks with distilled water before filling it with electrolyte.

If you decide to try one of these builds, there’s a forum available to document your progress or ask for advice. This may have the clearest instructions, but it isn’t the only homemade flow cell out there. It’s also possible to make these with very high energy densities.

hackaday.com/2025/07/23/an-ope…

Le vulnerabilità critiche recentemente scoperte nell’infrastruttura Cisco sono già state sfruttate attivamente dagli aggressori per attaccare le reti aziendali. L’azienda ha confermato ufficialmente che il suo Public Security Incident Response Team (PSIRT) ha registrato tentativi di sfruttamento di queste vulnerabilità in condizioni reali. Stiamo parlando di violazioni nei prodotti Cisco Identity Services Engine (ISE) e nel modulo Passive Identity Connector (ISE-PIC).

Cisco ISE svolge un ruolo chiave nel controllo degli accessi: determina chi può connettersi alla rete aziendale e a quali condizioni. Compromettere l’integrità di questa piattaforma offre agli aggressori accesso illimitato ai sistemi interni dell’azienda, consentendo loro di aggirare i meccanismi di autenticazione e logging, trasformando di fatto il sistema di sicurezza in una porta aperta.

Nella notifica ufficiale, l’azienda ha elencato tre vulnerabilità critiche con il punteggio CVSS più alto, pari a 10 su 10. Tutte e tre consentono a un aggressore remoto non autorizzato di eseguire comandi su un dispositivo vulnerabile come utente root, ovvero con i diritti più elevati nel sistema:

• CVE-2025-20281 e CVE-2025-20337 sono correlate alla gestione delle richieste API. Una convalida insufficiente dell’input dell’utente consente a un aggressore di creare una richiesta appositamente creata che può essere utilizzata per eseguire codice arbitrario sul server ISE;
• CVE-2025-20282 riguarda un’API interna priva di un adeguato filtraggio dei file caricati, consentendo a un aggressore di caricare un file dannoso e di eseguirlo in una directory protetta, anche con privilegi di root.

Tecnicamente, queste vulnerabilità derivano dalla mancanza di convalida dell’input (nei primi due casi) e da un controllo insufficiente sui percorsi di caricamento dei file (nel terzo). Le opzioni di sfruttamento spaziano dall’invio di una richiesta API appositamente predisposta al caricamento di un file preparato su un server. In entrambi gli scenari, un aggressore può aggirare i meccanismi di autenticazione e ottenere il pieno controllo del dispositivo.

Nonostante vengano attivamente sfruttate, Cisco non ha ancora reso noto chi ne sia l’autore o quanto sia diffusa la situazione. Tuttavia, il fatto stesso che siano comparsi exploit sottolinea la gravità della situazione.

L’azienda ha rilasciato patch per risolvere tutte le vulnerabilità e raccomanda vivamente ai propri clienti di aggiornare immediatamente il software alle versioni più recenti. I sistemi privi di patch sono a rischio di attacchi di tipo “remote takeover” senza necessità di autenticazione, il che è particolarmente pericoloso per le reti che operano sotto un elevato carico normativo o per le infrastrutture critiche.

Oltre a installare gli aggiornamenti, gli esperti consigliano agli amministratori di sistema di analizzare attentamente i registri delle attività per individuare segnali di richieste API sospette o tentativi di scaricare file non autorizzati, soprattutto se i componenti ISE sono accessibili esternamente.

La situazione di Cisco ISE dimostra ancora una volta quanto possano essere vulnerabili anche gli elementi chiave di un’architettura di sicurezza se le interfacce e i controlli dei dati utente non vengono adeguatamente controllati. Data la prevalenza di queste soluzioni negli ambienti aziendali, la loro compromissione può essere fatale per la sicurezza dell’intera rete interna.

L'articolo Vulnerabilità critiche in Cisco ISE: aggiornamenti urgenti necessari proviene da il blog della sicurezza informatica.

La Red Hot Cyber Conference ritorna!

Dopo il grande successo della terza e quarta edizione, torna l’appuntamento annuale gratuito ideato dalla community di RHC! Un evento pensato per avvicinare i più giovani alle tecnologie digitali e, allo stesso tempo, una conferenza dedicata a professionisti ed esperti del settore.

La nuova edizione della RHC Conference 2026 si svolgerà a Roma, nella stessa location delle ultime due edizioni, presso la prestigiosa cornice del Teatro Italia nei giorni martedì 18 e mercoledì 19 maggio 2026. Il Teatro Italia si trova in Via Bari, 18 00161 Roma e può ospitare fino ad 800 persone.

La location risulta distante:

• 2 km dalla Stazione Termini o dall’Università La Sapienza, raggiungibile con una passeggiata a piedi di circa 20 minuti o con 6 minuti di Taxi;
• 600 metri dalla stazione della Metro B di Piazza Bologna, raggiungibile con una passeggiata di 6 minuti a piedi o con 3 minuti di Taxi.

youtube.com/embed/J1i9S4LOWSA?…
Video riassunto della Red Hot Cyber Conference 2025

La quarta edizione del 2025

La quarta edizione della Red Hot Cyber Conference si è svolta a Roma il 19 e 20 aprile 2024, registrando oltre 800 partecipanti effettivi e più di 1.400 iscrizioni complessive.

Durante le due entusiasmanti giornate, si sono tenuti workshop pratici ‘hands-on’, la competizione di hacking ‘Capture The Flag’ (CTF), e una conferenza in cui numerosi esperti italiani, provenienti sia dal settore privato che pubblico, hanno condiviso le loro conoscenze sul palco.

Di seguito potete trovare una serie di link che mostrano le due giornate del 2025, compresi i video degli interventi.

• I Workshop “Hands On”
• La Capture The Flag (CTF)
• Gli Ospiti
• La Conferenza
• I Video dell’evento

Accoglienza alla Red Hot Cyber Conference 2024 Persone in fila per l’accoglienza alla Red Hot Cyber Conference 2024 Una foto dello STAFF Al completo della Red Hot Cyber Conference 2024Immagini dell’evento del 2025

Come si articolerà la Red Hot Cyber Conference 2026

Visto il format vincente della scorsa edizione, il programma della Red Hot Cyber Conference 2026 sarà articolato in modo simile all’edizione del 2025.

A differenza delle prime tre edizioni, i workshop “hands-on” si terranno nella sola giornata di martedì 18 Maggio, mentre la Conferenza sarà l’unica protagonista della scena di mercoledì 19 Maggio. In entrambe le giornate, in una location parallela al teatro si terrà la capture the flag (CTF), con la premiazione prevista alla fine della giornata di mercoledì 19 maggio. Di seguito il programma (ancora in bozza) delle due giornate.

Martedì 18 Maggio

• Workshop “hands-on”: In tarda mattinata verranno avviati i Workshop pratici, incentrati nell’approccio “hands-on”. Durante questi workshop, verranno affrontati temi quali ethical hacking, intelligenza artificiale e altro ancora. I partecipanti, muniti del proprio laptop, avranno l’opportunità di ascoltare i workshop e poi cimentarsi nello svolgere gli esercizi pratici supervisionati dai nostri esperti per poter toccare con mano la tecnologia. I workshop termineranno la sera dell’18 maggio;
• Capture The Flag (CTF): Nel pomeriggio, partirà anche la Capture The Flag (CTF) che terminerà il 19 Maggio alle ore 17:00. Si tratta di una competizione tra hacker etici che si terrà sia online che presso il Teatro Italia. I partecipanti presenti presso il Teatro Italia (i quali avranno una sala dedicata per poter partecipare), avranno la possibilità di sfidarsi in “flag fisiche” appositamente progettate da Red Hot Cyber per cimentarsi in attacchi locali RF/IoT. Queste attività forniranno la possibilità di accumulare maggiore punteggio per salire nella classifica. Sarà possibile cimentarsi nelle flag fisiche in entrambe le giornate.

Mercoledì 19 maggio

• Red Hot Cyber Conference: La giornata sarà interamente dedicata alla RHC Conference, un evento di spicco nel campo della sicurezza informatica. Il programma prevede un panel con ospiti istituzionali che si terrà all’inizio della conferenza. Successivamente, numerosi interventi di esperti nel campo della sicurezza informatica si susseguiranno sul palco fino alle ore 19:00 circa, quando termineranno le sessioni. Prima del termine della conferenza, ci sarà la premiazione dei vincitori della Capture The Flag prevista per le ore 18:00. Si precisa che i Workshop non saranno disponibili nella giornata di mercoledì 19 di maggio ma solo nella giornata di martedì 18 Maggio.

Il Programma Sponsor per la Red Hot Cyber Conference 2026

Come negli scorsi anni, sarà presente la possibilità di adesione come “sponsor sostenitore”. Si tratta delle prime aziende che crederanno in questa iniziativa e che permetteranno a Red Hot Cyber di avviare i lavori relativi alla conferenza.

Oltre agli sponsor sostenitori, come di consueto saranno presenti 3 livelli di sponsorizzazione che sono rispettivamente Platinum, Gold e Silver. Solo i Sostenitori e i Platinum avranno la possibilità di svolgere uno speech all’interno della conferenza. Abbinati ad ogni sponsorizzazione della conferenza, sarà sempre presente un pacchetto di Advertising che permetterà agli sponsor di disporre di una serie di vantaggi all’interno del circuito Red Hot Cyber.

Solo una azienda potrà aggiudicarsi la “Workshop Sponsorship”, un’opportunità unica per assumere un ruolo centrale nell’evento e collaborare fianco a fianco con Red Hot Cyber nell’organizzazione della giornata dedicata ai workshop pratici “hands-on” rivolti ai ragazzi. Anche per il 2026, per la terza edizione consecutiva, Accenture Italia sarà partner di Red Hot Cyber, con l’obiettivo di trasmettere ai giovani la passione per il mondo digitale.

Per richiedere informazioni per la sponsorizzazione della Red Hot Cyber Conference 2026 oltre che accedere al “Media Kit” e alle altre informazioni che riassumono i vantaggi della sponsorizzazione, scrivete a sponsor@redhotcyber.com.

La Red Hot Cyber Conference 2026 è orgogliosa di avere al suo fianco alcuni dei principali attori del panorama tecnologico e della cybersecurity, come Media Partner: i Fintech Awards Italia, Cyber Actors, Università E-Campus, Women4Cyber, Ri-Creazione, la Federazione Italiana Dei Combattenti Alleati e il Digital Security Summit e AIPSI. Queste collaborazioni rafforzano l’impegno comune nel promuovere la sicurezza digitale e la formazione per un futuro sempre più consapevole e sicuro.

L'articolo Red Hot Cyber Conference 2026. La Quinta edizione a Roma martedì 18 e mercoledì 19 Maggio proviene da il blog della sicurezza informatica.

Premessa: il GDPR non ha eliminato i dati sensibili.

Per gli spiritosoni che dicono “i dati sensibili che sono? quelli che si offendono?” sparandosi la gimmick da espertoni di GDPR, faccio notare che la definizione del GDPR categorie particolari di dati è quella presenta già nella direttiva 95/46/CE all’art. 8 mentre invece i dati sensibili resistono e vivono pur nella nuova normativa ma in accordo con il loro significato dal punto di vista della sicurezza delle informazioni.

Il presente regolamento prevede anche un margine di manovra degli Stati membri per precisarne le norme, anche con riguardo al trattamento di categorie particolari di dati personali («dati sensibili»). (considerando n. 10 GDPR)

Meritano una specifica protezione i dati personali che, per loro natura, sono particolarmente sensibili sotto il profilo dei diritti e delle libertà fondamentali, dal momento che il contesto del loro trattamento potrebbe creare rischi significativi per i diritti e le libertà fondamentali. (considerando n. 51 GDPR)

(…) che potenzialmente presentano un rischio elevato, ad esempio, data la loro sensibilità (considerando n. 91 GDPR)

Quindi: no, i dati sensibili non sono affatto scomparsi per effetto del GDPR ma anzi trovano una collocazione letterale e sistematica maggiormente corretta. Sono sensibili quei dati il cui trattamento è idoneo a presentare un rischio elevato. Possiamo anche dire che sono dati il cui impatto, in seguito a un evento di data breach, è tutt’altro che trascurabile ma anzi particolarmente significativo e rilevante.

Tanto premesso, ci sono alcuni fraintendimenti piuttosto ricorrenti che vorrebbero collegare le responsabilità collegate al GDPR (e quindi, anche alla gestione della sicurezza) ai soli dati sensibili. Peccato che questo non sia scritto da nessuna parte…

Il GDPR si applica a tutti i dati personali.

Not-so-fun fact: il GDPR si applica a tutti i dati personali e non solo ai dati sensibili. Questo errore concettuale di fondo comporta solitamente il non pensare all’aspetto della protezione dei dati personali quando vengono trattati dei dati personali che non hanno natura sensibile, come ad esempio i dati di contatto.

Eppure il GDPR è terribilmente chiaro nel definire l’ambito di applicazione materiale:

Il presente regolamento si applica al trattamento interamente o parzialmente automatizzato di dati personali e al trattamento non automatizzato di dati personali contenuti in un archivio o destinati a figurarvi. (art. 2)

Parla di dati personali. Anzi, del trattamento di dati personali. Ma questa è un’altra storia.

Restando sul punto: le prescrizioni in materia di protezione dei dati personali riguardano i trattamenti di tutti i dati personali. Ovverosia, quei dati che possono identificare direttamente o indirettamente una persona fisica (et voilà, l’interessato è servito sul piatto delle definizioni!), rendendola distinguibile all’interno di un gruppo e di un contesto di riferimento tenendo conto dei mezzi ragionevolmente impiegabili nonché di tutti gli ulteriori elementi informativi che possono essere disponibili. Questo perché un elemento informativo può contribuire a ricostruire una determinata persona fisica.

Ecco perché il concetto di dato personale dev’essere chiaro e va mai limitato ai soli identificatori diretti.

Quindi, trattare dati personali non sensibili non esonera dal rispettare i principi del GDPR, notificare o comunicare un data breach, istruire chi è autorizzato ad accedervi, o gestire gli aspetti di sicurezza.

La sicurezza riguarda tutte le informazioni.

Per gestire correttamente la sicurezza delle informazioni, bisogna fare riferimento a tutte le informazioni. Dopodiché, ci sarà il sottoinsieme di informazioni sensibili e non sensibili. E fra queste, si possono distinguere dati personali e non personali.

Non gestire la sicurezza di una parte delle informazioni significa avere una postura incompleta perché si è rinunciato a svolgere anche la più semplice attività di analisi a riguardo. Nel migliore dei casi comporta una non conformità, mentre nel peggiore una vulnerabilità ignota per effetto della scelta consapevole di chi, semplicemente, ha accetta il rischio “al buio”. Concetto che nell’ambito degli appuntamenti può riservare sempre qualche sorpresa positiva, ma nella sicurezza fonda ogni premessa per un fallimento epico. Da cui conseguono una serie di responsabilità il cui peccato originale è proprio il non aver voluto gestire dei rischi. Cosa ben diversa rispetto all’aver approntato misure di mitigazione che si sono rivelate inadeguate.

Spiacevole verità: ispirarsi al quokka per una strategia di difesa sperando che un attaccante si fermi a fagocitare o violare i soli dati non sensibili (o anche: non personali e non sensibili) non è mai una buona idea.
Questo è più il meme. In realtà non è proprio così.
Che i dati siano sensibili o no, l’importante è avere la capacità di mantenerne il controllo.

Quando non è possibile proteggerli (o garantirne la liceità del trattamento), bisogna trovare un’alternativa.

Che talvolta può significare anche scegliere di non trattarli.

L'articolo I dati sensibili non si sono offesi: esistono ancora (e il GDPR li cita pure) proviene da il blog della sicurezza informatica.

I nostri eroi Matteo Errera e Roberto Zaccardi e il Cyberpandino hanno raggiunto Istanbul dopo cinque giorni di viaggio e oltre 5.000 km macinati dalla partenza da Lampedusa e si riparte per la Cappadocia!Un traguardo importante, ma che è solo l’inizio di un’avventura che prevede altri circa 20.000 km (più o meno… ma chi li conta davvero?) verso le strade più improbabili del pianeta.

La prima vera sfida si è presentata nel cuore di Maslak, il quartiere dei meccanici di Istanbul, dove una perdita di benzina dal serbatoio ha costretto l’equipaggio a una sosta tecnica non prevista. Con l’aiuto dei ragazzi di @exclusivegaragetr, problema tappato e motore pronto a ruggire di nuovo. Almeno fino al prossimo imprevisto, perché di questi tempi pare che non manchino mai.

Dalla Turchia all’entroterra più selvaggio, il Cyberpandino ha continuato la sua corsa tra crateri lunari, villaggi fantasma e strade che in realtà non esistono nemmeno sulle mappe.

Finora la piccola panda ha affrontato una vera e propria lista nera di guasti: tubo della benzina esploso, serbatoio che si svita, puleggia dell’albero motore rotta, filtro tappato da benzina tagliata con acqua e, per non farsi mancare nulla, tubo del collettore di aspirazione devastato. Ma al nostro Magic team, Matteo Errera e Roberto Zaccardi non importa, si va avanti con grande determinazione.

E come se non bastasse, dopo una lunga notte alla frontiera tra attese infinite, controlli e caffè imbevibili, il Cyberpandino è finalmente arrivato in Turchia. Con lui ora c’è anche un nuovo compagno di viaggio: @jonny_pickup, reporter e videomaker inglese che non parla una parola di italiano, pronto a immortalare ogni istante di questa corsa surreale. Più teste a bordo significano anche più zaini da incastrare nel bagagliaio, ma la vecchia panda continua a reggere con una dignità meccanica tutta sua.

Il prossimo grande passaggio sarà la frontiera con la Russia, prevista per il 27 luglio. Fino ad allora, il viaggio continua, tra imprevisti, pezzi di ricambio e paesaggi che tolgono il fiato. Perché il Mongol Rally non è solo una gara: è un esperimento di follia su ruote, dove anche le rotture diventano storie da raccontare. E il Cyberpandino, nonostante tutto, non molla mai.

E intanto, il Cyberpandino diventa sempre più una casa viaggiante. Hanno parcheggiato sulle rive di un lago così remoto in Turchia che persino i cammelli hanno chiesto indicazioni. Location esclusiva per veri esploratori… o per chi sbaglia strada con convinzione.

Perché questo è il Mongol Rally: una partenza, un traguardo lontano… e in mezzo, solo strade da inventare e avventure da vivere.

Il Cyberpandino ha tirato fuori tutto l’arsenale da campeggio in puro “Panda-luxe”: la tenda laterale che si monta in cinque minuti, la power station da 1500W per alimentare luci e condizionatore (perché dentro si sfiorano i 40°, praticamente un hammam con più zanzare), wifi satellitare per restare connessi anche in mezzo al nulla… e ovviamente la pasta, perché puoi togliere l’italiano dall’Italia, ma non la pentola.

Ora si punta verso la Georgia, forse Armenia. Riuscirà il Cyberpandino a convincere la dogana che non è un’astronave low-cost atterrata per sbaglio in Anatolia?

Stay tuned: la strada è lunga, la tenda ancora storta e la pasta… quasi pronta.

L'articolo Prima Tappa: Istanbul. Il Cyberpandino macina 5.000 km, tra guasti e imprevisti… ma non si ferma! proviene da il blog della sicurezza informatica.

Continuiamo la nostra serie di articoli sugli Initial Access Broker con un articolo su JohnDoe7 (anche noto come LORD1) che, come vedremo in seguito, usa un nome/moniker che richiama alla cinematografia o al mondo legal negli Stati Uniti.

Exploit di vulnerability 1-day

KELA Cyber ha osservato la costante offerta di exploit per vulnerabilità 1-day, il che conferma che gli IAB, come altri attori, sono interessati a colpire le aziende che non hanno applicato patch al loro ambiente in modo tempestivo. Qui in figura, su Exploit nell’Ottobre 2020, LORD1 offre un exploit RCE e LPE il cui prezzo parte da 5.000 dollari.
LORD1 offre exploit di un giorno (RCE, LPE), con prezzo a partire da 5000$

Il caso del software MOVEit Transfer

Nel giugno 2023, johndoe7 aka LoRD1 su XSS ed Exploit ha offerto uno script dannoso personalizzato per sfruttare la vulnerabilità di Progress MOVEit Transfer (CVE-2023-34362). Nel maggio 2023, il gruppo ransomware CL0P ha preso di mira MOVEit Transfer di Progress Software, comunemente utilizzato dalle organizzazioni per gestire le operazioni di trasferimento dei file. Hanno sfruttato la vulnerabilità zero-day SOL injection (CVE-2023-34362) per infiltrarsi nelle applicazioni web di MOVEit Transfer e ottenere un accesso non autorizzato ai database archiviati. Ciò potrebbe far pensare ad un legame tra johndoe7 e la gang CL0P …

Nel successivo esempio nei forum XSS e Exploit, gli attori malevoli “0x90” e “Present” manifestano il loro interesse nel comprare degli exploit per la CVE-2023-3519 (RCE su Citrix) e per la CVE-2022-24527 (LPE su Microsoft Connected Cache).

–

–

Report di Soc RADAR su attacchi a crypto/NFT

Secondo un report di SOCRadar, LORD1 è molto attivo nella compromissione di credenziali relative al mondo delle criptovalute e delle NFT; le analisi condotte dal gruppo di ricerca di SOCRadar rivelano che la maggior parte delle circa 1.700 minacce uniche del Dark Web rilevate dal 2021 a oggi riguardano la vendita di dati utente compromessi su scala globale. Pertanto, gli attori malevoli prendono di mira il settore delle criptovalute e delle NFT rappresentano una minaccia globale per tutti gli utenti.

La minaccia più diffusa nel settore delle criptovalute e NFT è la compromissione e la successiva vendita di informazioni personali degli utenti del settore sui forum del Dark Web.

Nel grafico precedente, fatto 100 il totale dei casi di compromissione credenziali analizzati nel periodo da SOCRadar, ogni segmento mostra la percentuale di contributo attribuita a ciascuno attore malevolo: LORD1 figura al quinto posto della TOP 10 con un contributo pari al 14 per cento.

Scenari di altre CVE sfruttate dallo IAB

ATLASSIAN BITBUCKET COMMAND INJECTION (CVE-2022-36804)

Resa nota nell’agosto 2022, CVE-2022-36804 è una vulnerabilità di iniezione di comandi che interessa più API endpoint dei server di Bitbucket. Utilizzando questa vulnerabilità, gli aggressori con accesso a un repository pubblico o con permessi di lettura a un repository Bitbucket privato, possono eseguire codice arbitrario inviando una richiesta HTTP dannosa.

FORTINET: AUTHENTICATION BYPASS VULNERABILITY (CVE-2022-40684)

Resa nota nel settembre 2022, questa vulnerabilità consente a un aggressore non autenticato di eseguire operazioni sull’interfaccia amministrativa dell’apparato FORTINET tramite richieste HTTP o HTTPs appositamente create tramite bypass dell’autenticazione utilizzando un percorso o un canale alternativo [CWE-288] in Fortinet FortiOS versione 7.2.0 fino a 7.2.1 e 7.0.0 fino a 7.0.6, FortiProxy versione 7.2.0 e versione 7.0.0 fino a 7.0.6 e FortiSwitchManager versione 7.2.0 e 7.0.0.

XSS Forum

Altre tracce di Johndoe7 dal 2022 nel forum XSS ( xss.ist/forums/104 )

–

–

–

SEVEN / SE7EN

Curiosità, “John Doe” è il nome del villain/il cattivo del film SE7EN

villains.fandom.com/it/wiki/Jo…

Negli USA il nome John Doe è usato per una vittima o un imputato sconosciuto o che si intende mantenere anonimo in un caso legale. È inoltre il nome che viene attribuito d’ufficio ai cadaveri di sconosciuti.

In Italia è l’equivalente di Ignoto o NN (dal latino Nomen Nescio).

NotaBene su 1-day: che cos’è una vulnerabilità 1-day?

Le vulnerabilità 1-day sono vulnerabilità note per le quali è disponibile una remediation patch o una mitigation, ma che non sono ancora state applicate. Il termine “un giorno” si riferisce al periodo che intercorre tra la divulgazione della vulnerabilità e l’applicazione della patch ai sistemi interessati.

A volte queste vulnerabilità vengono definite “n-day”, poiché il periodo è spesso molto più lungo di un giorno, dato che il tempo medio per l’applicazione di una patch (MTTP) è di solito compreso tra i 60 e i 150 giorni.

Purtroppo, lo sfruttamento delle vulnerabilità 1-day è spesso accelerato dal rilascio di codice exploit PoC (Proof-of-Concept) prima che gli utenti interessati abbiano il tempo necessario ad applicare una patch ai propri sistemi. Questa pratica sembra essere peggiorata da quando alcuni ricercatori di cybersecurity cercano di mettere in mostra le proprie capacità tecniche creando delle PoC, nonostante i danni che derivano da ciò.

Mentre threat actors più sofisticati effettuano il reverse-engineering di una patch per capire quale problema fosse essa destinata a risolvere e quindi sviluppano i propri exploit sulla base delle loro scoperte, i meno tecnici adottano/usano il codice della PoC disponibile pubblicamente. In questo modo la vulnerabilità può essere sfruttata da attori malevoli con minori skill tecniche che altrimenti non avrebbero avuto questa capacità senza assistenza esterna.

Un esempio recente e rilevante di vulnerabilità one-day è rappresentato da CVE-2024-1708, una falla di tipo “Autenthication bypass”, e da CVE-2024-1709, una falla di tipo Path traversal, nei server ScreenConnect di ConnectWise: solo un giorno dopo l’annuncio delle vulnerabilità, diversi ricercatori hanno rilasciato il codice di exploit PoC e i dettagli tecnici relativi alle vulnerabilità. Questo codice, unito alla facilità di identificare istanze ScreenConnect vulnerabili tramite scanner web online, ha portato a uno sfruttamento di massa e alla distribuzione di ransomware e altro malware su server privi di patch.

Conclusione

In questo articolo della serie sugli initial access broker abbia visto come il furto di credenziali possa avvenire anche attraverso attacchi che sfruttino vulnerabilità di tipo RCE e LPE e come sia fondamentale applicare patches e remediations il prima possibile … Quindi ricordiamo alcune delle best practice menzionate in precedenza per essere pronti ad ogni evenienza

• Aggiornamento costante dei sistemi
• Monitoraggio Continuo e Rilevamento delle Minacce
• Controlli di Accesso Forti/uso di Multi Factor Authentication
• Formazione e Consapevolezza dei Dipendenti
• Segmentazione/micro segmentazione della rete

Riferimenti

KelaCyber 2022 Q2 Report kelacyber.com/wp-content/uploa…

Outpost24 IAB Report outpost24.com/wp-content/uploa…

Soc Radar report socradar.io/wp-content/uploads…

Cyble underground report osintme.com/wp-content/uploads…

XSS Forum xss.ist/forums/104

Seven (Film, 1995) it.wikipedia.org/wiki/Seven

L'articolo Alla scoperta dell’IaB JohnDoe7: accessi in vendita dall’uomo qualunque proviene da il blog della sicurezza informatica.

Another entry in the world of interesting FDM filaments comes courtesy of CC3D with their 72D TPU filament, with [Dr. Igor Gaspar] putting it to the test in his recent video. The use of the Shore hardness D scale rather than the typical A scale is a strong indication that something is different about this TPU. The manufacturer claims ‘nylon-like’ performance, which should give this TPU filament much more hardness and resistance to abrasion. The questions are whether this filament lives up to these promises, and whether it is at all fun to print with.
The CC3D 72D TPU filament used to print a bicycle’s handlebar. (Credit: My Tech Fun, YouTube)
TPU is of course highly hydrophilic, so keeping the filament away from moisture is essential. Printing temperature is listed on the spool as 225 – 245°C, and the filament is very bendable but not stretchable. For the testing a Bambu Lab X-1 Carbon was used, with the filament directly loaded from the filament dryer. After an overnight print session resulted in spaghetti due to warping, it was found that generic TPU settings at 240ºC with some more nylon-specific tweaks seemed to give the best results, with other FDM printers also working well that way.

The comparison was against Bambu Lab’s 68D TPU for AMS. Most noticeable is that the 72D TPU easily suffers permanent deformation, while being much more wear resistant than e.g. PLA. That said, it does indeed seem to perform more like polyamide filaments, making it perhaps an interesting alternative there. Although there’s some confusion about whether this TPU filament has polyamide added to it, it seems to be pure TPU, just like the Bambu Lab 68D filament.

youtube.com/embed/158prgcHcTE?…

hackaday.com/2025/07/22/nylon-…

Although Charles Hall conducted his first successful run of the Hall-Héroult aluminium smelting process in the woodshed behind his house, it has ever since remained mostly out of reach of home chemists. It does involve electrolysis at temperatures above 1000 ℃, and can involve some frighteningly toxic chemicals, but as [Maurycy Z] demonstrates, an amateur can now perform it a bit more conveniently than Hall could.

[Maurycy] started by finding a natural source of aluminium, in this case aluminosilicate clay. He washed the clay and soaked it in warm hydrochloric acid for two days to extract the aluminium as a chloride. This also extracted quite a bit of iron, so [Maurycy] added sodium hydroxide to the solution until both aluminium and iron precipitated as hydroxides, added more sodium hydroxide until the aluminium hydroxide redissolved, filtered the solution to remove iron hydroxide, and finally added hydrochloric acid to the solution to precipitate aluminium hydroxide. He heated the aluminium hydroxide to about 800 ℃ to decompose it into the alumina, the starting material for electrolysis.

To turn this into aluminium metal, [Maurycy] used molten salt electrolysis. Alumina melts at a much higher temperature than [Maurycy]’s furnace could reach, so he used cryolite as a flux. He mixed this with his alumina and used an electric furnace to melt it in a graphite crucible. He used the crucible itself as the cathode, and a graphite rod as an anode. He does warn that this process can produce small amounts of hydrogen fluoride and fluorocarbons, so that “doing the electrolysis without ventilation is a great way to poison yourself in new and exciting ways.” The first run didn’t produce anything, but on a second attempt with a larger anode, 20 minutes of electrolysis produced 0.29 grams of aluminium metal.

[Maurycy]’s process follows the industrial Hall-Héroult process quite closely, though he does use a different procedure to purify his raw materials. If you aren’t interested in smelting aluminium, you can still cast it with a microwave oven.

hackaday.com/2025/07/22/the-ha…

While it might not be accurate to say VHS is dead, it’s certainly not a lively format. It continues on in undeath thanks to dedicated collectors and hobbyists, some of whom may be tempted to lynch Reddit user [CommonKingfisher] for embedding a video player inside a VHS tape.
Miniaturization in action. The video player probably cost about the same as the original VHS when you account for inflation.
The hack started with a promotional video card via Ali Express, which is a cheap enough way to get a tiny LCD player MP4 playing micro. As you can see, there was plenty of room in the tape for the guts of this. The tape path is obviously blocked, so the tape is not playable in this format. [CommonKingfisher] claims the hack is “reversible” but since he cut a window for the LCD out of the casing of the cassette, that’s going to be pretty hard to undo. On the other hand, the ultrasonic cutter he used did make a very clean cut, and that would help with reversibility.

The fact that the thing is activated by a magnetic sensor makes us worry for the data on that tape, too, whether or not the speaker is a peizo. Ultimately it doesn’t really matter; in no universe was this tape the last surviving copy of “The Matrix”, and it’s a lot more likely this self-playing “tape” gets watched than the VHS was going to be. You can watch it yourself in the demo video embedded below.

VHS nostalgia around here usually involves replicating the tape experience, rather than repurposing the tape. We’re grateful to [George Graves] for the tip. Tips of all sorts are welcome on our friendly neighborhood tips line.

youtube.com/embed/BYrY3nFrsho?…

hackaday.com/2025/07/22/video-…

We did explicitly ask for projects that use a 555 timer for the One Hertz Challenge, but we weren’t expecting the 555 to be the project. Yet, here we are, with [matt venn]’s Open Source 1Hz Blinky, that blinks a light with a 555 timer… but not one you’d get from Digikey.

Hooking a 555 to blink an LED at one hertz is a bog-simple, first-electronics-project type of exercise, unless you have to make the 555 first. Rather than go big, as we have seen before, [matt venn] goes very small, with a 555 implemented on a tiny sliver of Tiny Tapeout 6.

We’ve covered projects using that tapeout before, but in case you missed it, Tiny Tapeout gives space to anyone to produce ASICs on custom silicon using an open Process Design Kit, and we have [matt venn] to thank for it. The Tiny Tapeout implementation of the 555 was actually designed by [Vincent Fusco].

Of course wiring it up is a bit more complicated than dropping in a 555 timer to the circuit: the Tiny Tapeout ASIC must be configured to use that specific project using its web interface. There’s a demo video embedded below, with some info about the project– it’s not just a blinking LED, so it’s worth seeing. The output isn’t exactly One Hertz, so it might not get the nod in the Timelord category, but it’s going to be a very strong competitor for other 555-based projects– of which we could really use more, hint-hint. You’ve got until August 19th, if you think you can use a 555 to do something more interesting than blink an LED.

youtube.com/embed/QrB6msn3UzM?…

hackaday.com/2025/07/22/2025-o…

Nel corso degli ultimi mesi, YouTube ha intensificato la sua attività di contrasto contro campagne di disinformazione e operazioni di influenza coordinate, rimuovendo un numero considerevole di canali legati a vari paesi. Tra questi, spiccano 43 canali chiusi per attività legate alla Turchia: la campagna diffondeva contenuti in lingua turca a sostegno del Partito della Vittoria. Parallelamente, 12 canali, un account pubblicitario, un account AdSense e nove domini sono stati bloccati per una campagna pro-Romania a favore di un partito politico specifico.

Le attività riconducibili alla Russia hanno portato alla chiusura di centinaia di canali. Solo in alcuni esempi, sono stati chiusi 1.045 canali e bloccati due domini per una campagna collegata a una società di consulenza russa; ulteriori 507 canali sono stati rimossi per contenuti pro-Russia e critici verso Ucraina e Occidente; altri 392 canali, sempre riconducibili a una società di consulenza russa, sono stati eliminati per motivi analoghi. A questi si aggiungono decine di altri canali chiusi per campagne in diverse lingue, tra cui inglese, francese, spagnolo, ucraino e polacco.

Anche la Repubblica Popolare Cinese (PRC) è stata coinvolta in modo massiccio. In particolare, YouTube ha chiuso 1.545 canali per una rete inautentica che pubblicava contenuti in cinese e inglese su Cina e affari esteri statunitensi, e ulteriori 3.592 canali nei mesi successivi per attività simili. Nel mese di giugno, sono stati rimossi altri 2.598 canali e bloccato un dominio, sempre per operazioni legate alla PRC. Questi interventi confermano trend già documentati in precedenti report.

Non sono mancate azioni contro campagne legate ad altri paesi. In Azerbaijan sono stati chiusi 356 canali in un caso, 457 in un altro, e ulteriori 228 canali per campagne che diffondevano contenuti critici verso l’Armenia e oppositori del governo azero. In Iran sono stati chiusi 12 canali per contenuti a favore del governo iraniano e della Palestina e critici verso Israele; inoltre, sono stati bloccati due domini per campagne in arabo critiche verso Stati Uniti, Israele e Occidente.

Infine, YouTube ha agito anche contro campagne più circoscritte: quattro canali chiusi per attività legate a Israele con contenuti critici verso la Palestina; un canale e un dominio bloccati in Ghana per una campagna legata alle elezioni presidenziali; e quattro canali chiusi per attività pro-Cina e critiche verso le Filippine. Questi interventi, realizzati tra aprile e giugno, testimoniano la costante attività della piattaforma contro la disinformazione globale e le reti inautentiche.

L'articolo Pulizia storica su YouTube: eliminati oltre 10.000 canali collegati a Mosca, Pechino e Teheran proviene da il blog della sicurezza informatica.

We’ve all felt the frustration of cheap consumer electronics — especially when they aren’t actually cheap. How many of us have said “Who designed this crap? I could do better with an Arduino!” while resisting the urge to drop that new smart doorbell in the garbage disposal?

It’s an all-too familiar thought, and when it passed through [Mathieu]’s head while he was resetting the time and changing the batteries in his son’s power-hungry Pokémon alarm clock for the umpteenth time, he decided to do something about it.

The only real design requirement, imposed by [Mathieu]’s son, was that the clock’s original shell remained. Everything else, including the the controller and “antique” LCD could go. He ripped out the internals and installed an ESP32, allowing the clock to automatically sync to network time in the event of power loss. The old-school LCD was replaced with a modern, full-color TFT LCD which he scored on AliExpress for a couple of Euros.

Rather than just showing the time, the new display sports some beautiful pixel art by Woostarpixels, which [Mathieu] customized to have day and nighttime versions, even including the correct moon phase. He really packed as much into the ESP32 as possible, using 99.6% of its onboard 4 MB of flash. Code is on GitHub for the curious. All in all, the project is a multidisciplinary work of art, and it looks well-built enough to be enjoyed for years to come.

youtube.com/embed/mHJeMg9Hzjg?…

hackaday.com/2025/07/22/2025-o…

Picture this: it’s January 19th, 2038, at exactly 03:14:07 UTC. Somewhere in a data center, a Unix system quietly ticks over its internal clock counter one more time. But instead of moving forward to 03:14:08, something strange happens. The system suddenly thinks it’s December 13th, 1901. Chaos ensues.

Welcome to the Year 2038 problem. It goes by a number of other fun names—the Unix Millennium Bug, the Epochalypse, or Y2K38. It’s another example of a fundamental computing limit that requires major human intervention to fix.

By and large, the Y2K problem was dealt with ahead of time for critical systems. An amusing example of a Y2K failure was this sign at the École Centrale de Nantes, pictured on January 3, 2000. Credit: Bug de l’an 2000, CC BY-SA 3.0
The Y2K problem was simple enough. Many computing systems stored years as two-digit figures, often for the sake of minimizing space needed on highly-constrained systems, back when RAM and storage, or space on punch cards, were strictly limited. This generally limited a system to understanding dates from 1900 to 1999; when storing the year 2000 as a two-digit number, it would instead effectively appear as 1900 instead. This promised to cause chaos in all sorts of ways, particularly in things like financial systems processing transactions in the year 2000 and onwards.

The problem was first identified in 1958 by Bob Bemer, who was working on longer time scales with genealogical software. Awareness slowly grew through the 1980s and 1990s as the critical date approached and things like long-term investment bonds started to butt up against the year 2000. Great effort was expended to overhaul and update important computer systems to enable them to store dates in a fashion that would not loop around back to 1900 after 1999.

Unlike Y2K, which was largely about how dates were stored and displayed, the 2038 problem is rooted in the fundamental way Unix-like systems keep track of time. Since the early 1970s, Unix systems have measured time as the number of seconds elapsed since January 1st, 1970, at 00:00:00 UTC. This moment in time is known as the “Unix epoch.” Recording time in this manner seemed like a perfectly reasonable approach at the time. It gave systems a simple, standardized way to handle timestamps and scheduled tasks.

The trouble is that this timestamp was traditionally stored as a signed 32-bit integer. Thanks to the magic of binary, a signed 32-bit integer can represent values from -2,147,483,648 to 2,147,483,647. When you’re counting individual seconds, that gives you about plus and minus 68 years either side of the epoch date. Do the math, and you’ll find that 2,147,483,647 seconds after January 1st, 1970 lands you at 03:14:07 UTC on January 19th, 2038. That’s the final time that can be represented using the 32-bit signed integer, having started at the Unix epoch.
The Unix time integer immediately prior to overflow.
What happens next isn’t pretty. When that counter tries to increment one more time, it overflows. In two’s complement arithmetic, the first bit is a signed bit. Thus, the time stamp rolls over from 2,147,483,647 to -2,147,483,648. That translates to December 13th, 1901. In January 2038, this will be roughly 136 years in the past.
Unix time after the 32-bit signed integer has overflowed.
For an unpatched system using a signed 32-bit integer to track Unix time, the immediate consequences could be severe. Software could malfunction when trying to calculate time differences that suddenly span more than a century in the wrong direction, and logs and database entries could quickly become corrupted as operations are performed on invalid dates. Databases might reject “historical” entries, file systems could become confused about which files are newer than others, and scheduled tasks might cease to run or run at inappropriate times.

This isn’t just some abstract future problem. If you grew up in the 20th century, it might sound far off—but 2038 is just 13 years away. In fact, the 2038 bug is already causing issues today. Any software that tries to work with dates beyond 2038—such as financial systems calculating 30-year mortgages—could fall over this bug right now.
In 2012, NetBSD 6.0 introduced 64-bit Unix time across both 32-bit and 64-bit architectures. There is also a binary compatibility layer for running older applications, though they will still suffer the year 2038 problem internally. Credit: NetBSD changelog
The obvious fix is to move from 32-bit to 64-bit timestamps. A 64-bit signed integer can represent timestamps far into the future—roughly 292 billion years in fact, which should cover us until well after the heat death of the universe. Until we discover a solution for that fundamental physical limit, we should be fine.

Indeed, most modern Unix-based operating systems have already made this transition. Linux moved to 64-bit time_t values on 64-bit platforms years ago, and since version 5.6 in 2020, it supports 64-bit timestamps even on 32-bit hardware. OpenBSD has used 64-bit timestamps since May 2014, while NetBSD made the switch even earlier in 2012.

Most other modern Unix filesystems, C compilers, and database systems have switched over to 64-bit time by now. With that said, some have used hackier solutions that kick the can down the road more than fixing the problem for all of foreseeable time. For example, the ext4 filesystem uses a complicated timestamping system involving nanoseconds that runs out in 2446. XFS does a little better, but its only good up to 2486. Meanwhile, Microsoft Windows uses its own 64-bit system tracking 100-nanosecond intervals since 1 January 1601. This will overflow as soon as the year 30,828.

The challenge isn’t just in the operating systems, though. The problem affects software and embedded systems, too. Most things built today on modern architectures will probably be fine where the Year 2038 problem is concerned. However, things that were built more than a decade ago that were intended to run near-indefinitely could be a problem. Enterprise software, networking equipment, or industrial controllers could all trip over the Unix date limit come 2038 if they’re not updated beforehand. There are also obscure dependencies and bits of code out there that can cause even modern applications to suffer this problem if you’re not looking out for them.
In 2022, a coder called Silent identified a code snippet that was reintroducing the Year 2038 bug to new software. Credit: Silent’s blog via screenshot
The real engineering challenge lies in maintaining compatibility during the transition. File formats need updating and databases must be migrated without mangling dates in the process. For systems in the industrial, financial, and commercial fields where downtime is anathema, this can be very challenging work. In extreme cases, solving the problem might involve porting a whole system to a new operating system architecture, incurring huge development and maintenance costs to make the changeover.

The 2038 problem is really a case study in technical debt and the long-term consequences of design decisions. The Unix epoch seemed perfectly reasonable in 1970 when 2038 felt like science fiction. Few developing those systems thought a choice made back then would have lasting consequences over 60 years later. It’s a reminder that today’s pragmatic engineering choices might become tomorrow’s technical challenges.

The good news is that most consumer-facing systems will likely be fine. Your smartphone, laptop, and desktop computer almost certainly use 64-bit timestamps already. The real work is happening in the background—corporate system administrators updating server infrastructure, embedded systems engineers planning obsolescence cycles, and software developers auditing code for time-related assumptions. The rest of us just get to kick back and watch the (ideally) lack of fireworks as January 19, 2038 passes us by.

hackaday.com/2025/07/22/the-ep…

L’ultimo aggiornamento di sicurezza per Windows Server 2019, rilasciato l’8 luglio, contiene un fastidioso problema che può compromettere il funzionamento di interi cluster. L’aggiornamento, numero KB5062557, causa errori nel Servizio Cluster, un componente fondamentale che gestisce i nodi di elaborazione distribuita e ne garantisce l’interazione fluida. Dopo l’installazione della patch, il sistema potrebbe iniziare a comportarsi in modo imprevedibile: il Servizio Cluster si avvia, quindi si blocca immediatamente, i nodi si disconnettono dal cluster, entrano in stato di isolamento e le macchine virtuali in questa infrastruttura si riavviano ripetutamente.

Secondo una notifica interna ottenuta da BleepingComputer, il problema si manifesta con errori persistenti con codice evento 7031 nei log di sistema. In pratica, ciò significa che il cluster è instabile, le macchine si comportano in modo irregolare e l’amministratore riscontra una serie di problemi anziché ricevere un aggiornamento di routine. La situazione è particolarmente problematica per chi utilizza BitLocker su dischi Cluster Shared Volumes (CSV): tali configurazioni sono soggette a ulteriori errori quando si tenta di riconnettere i nodi al cluster.

Microsoft conferma il problema, lo definisce noto e invita i clienti a non farsi prendere dal panico, ma non offre ancora soluzioni indipendenti. Invece di una patch universale, l’azienda offre soluzioni individuali: se un’organizzazione riscontra il problema descritto, è necessario contattare il servizio di supporto aziendale Microsoft. Solo tramite questo servizio è possibile ottenere istruzioni temporanee su come mitigare le conseguenze e aggirare il bug.

Non esiste una tempistica specifica per il rilascio di una correzione completa. Microsoft chiarisce solo che sta lavorando per includere la soluzione definitiva in una delle prossime versioni di Windows Update. Dopodiché, tutte le misure temporanee ricevute dal supporto tecnico diventeranno irrilevanti e non sarà necessario applicarle.

Non è la prima volta che gli aggiornamenti di Windows Server causano problemi. All’inizio di luglio, Microsoft ha risolto un altro grave problema che impediva a WSUS (Windows Server Update Services) di sincronizzarsi correttamente con Microsoft Update, bloccando l’installazione di nuovi aggiornamenti. Un’altra conseguenza dell’aggiornamento di giugno è stato il blocco del servizio DHCP su alcuni server: questo problema è stato fortunatamente risolto nella build cumulativa di luglio.

Nel frattempo, gli amministratori che gestiscono Windows Server 2019 dovrebbero prestare la massima attenzione durante l’installazione dell’ultimo aggiornamento, soprattutto se l’infrastruttura utilizza il clustering e la crittografia dei volumi BitLocker. Prima di aggiornare i sistemi di produzione, è meglio verificare se questo possa causare un disastro improvviso.

L'articolo Aggiornamento Windows Server 2019: problemi al servizio cluster e BitLocker proviene da il blog della sicurezza informatica.