You have some fine pitch soldering to do, but all you have on hand is a big soldering iron. What do you do? There are a few possible answers, but [Mr SolderFix] likes to pull a strand from a large wire, file the point down, and coil it around the soldering iron. This gives you a very tiny hot tip. Sure, the wire won’t last forever, but who cares? When it gives up, you can simply make another one.

Many people have done things like this before — we are guilty — but we really liked [Mr Solder Fix’s] presentation over two videos that you can see below. He coils his wire over a form. In his case, he’s using a screwdriver handle and some tape to get to the right size. We’ve been known to use the shanks of drill bits for that purpose, since it is easy to get different sizes.

Truthfully, while sometimes you do really need a tiny tip, we prefer having a tip with some thermal mass. If you use something shaped like a slotted screwdriver blade, you can get contact area when you need it, or rotate the iron 90 degrees and get a very narrow profile.

But the copper coil method does work well, as you can see. This will work with nearly any iron. The first examples with fairly large resistors work predictably well. But we were really impressed with some of the very fine pitch connectors in part 2.

Of course, a fine tip is only part of the equation. It doesn’t hurt that he has a microscope and thin solder. If you want to up your SMD game, Oregon State University can help. We find it amusing that many products today are smaller than the components we used to use.

youtube.com/embed/jdWskB1ee_I?…

youtube.com/embed/JG3jD9eMc8g?…

hackaday.com/2025/10/13/smd-so…

Hyperspectral cameras aren’t commonplace items; they capture spectral data for each of their pixels. While commercial hyperspectral cameras often start in the tens of thousands of dollars, [anfractuosity] decided to make his own with the Waverider.

To capture spectral data from every pixel location in the camera, [anfractuosity] first needed a way to collect that data — for that, he used an AFBR-S20M2WV, a miniature USB spectrometer he picked up second-hand. This sensor allows for the collection of data from 225 nm all the way up to 1000 nm. Of course, the sensor can only do that for one single input, so to turn it into a camera, [anfractuosity] added a stepper-driven x-y stage controlled by a Raspberry Pi Pico and some TMC2130 stepper drivers.

With some 3D-printed parts to hold things together and a fiber-optic cable, [anfractuosity] now had a way to move the one-pixel camera through a wide range of locations, turning that one pixel into a much larger pixel array needed to get a recognizable image out. It’s not the fastest camera we’ve seen — with one 400 × 400 array of images taking almost 19 hours to capture — but it does produce an image that has far more than one RGB value per pixel.

Head over to [anfractuosity]’s site to check out all the images created and to find out more about this project, and check out some of our other single-pixel camera projects we’ve featured in the past. Or, maybe you can use your phone.

youtube.com/embed/ZXXJrwNGh8A?…

hackaday.com/2025/10/13/waveri…

È stata identificata unavulnerabilità critica nell’architettura di sicurezza hardware AMD SEV-SNP, che impatta i principali provider cloud (AWS, Microsoft Azure e Google Cloud). Tale bug consente a hypervisor dannosi di compromettere macchine virtuali crittografate e ottenere pieno accesso alla loro memoria.

L’attacco, denominato RMPocalypse, mina le fondamentali garanzie di riservatezza e integrità su cui si basa il modello di esecuzione attendibile SEV-SNP.

La ricerca presentata alla conferenza ACM CCS 2025 di Taipei, descrive in dettaglio come una vulnerabilità venga sfruttata durante l’inizializzazione della struttura chiave di SEV-SNP, la Reverse Map Table (RMP). Questa tabella mappa gli indirizzi fisici dell’host alle pagine virtuali guest ed è responsabile della prevenzione degli attacchi di page-spoofing noti dalle precedenti generazioni di SEV e SEV-ES. Tuttavia, la RMP stessa non esiste ancora all’avvio e pertanto non può proteggersi dalle scritture dei kernel x86 in esecuzione parallelamente al processo di inizializzazione.

La vulnerabilità è tracciata come CVE-2025-0033 (punteggio CVSS: 8,2) e colpisce i processori AMD basati sulle architetture Zen 3, Zen 4 e Zen 5, inclusi i chip server EPYC utilizzati attivamente nelle infrastrutture cloud. Il problema è un circolo vizioso: l’RMP dovrebbe proteggersi dalle modifiche, ma durante la fase di configurazione iniziale tale protezione non è ancora attiva. La gestione di questa fase è delegata al coprocessore Platform Security Processor (PSP), basato sull’architettura ARM. Crea barriere sotto forma di Trusted Memory Regions (TMR) sul controller di memoria e impedisce inoltre ai core x86 di scrivere in memoria. Tuttavia, come hanno dimostrato i ricercatori Benedikt Schlüter e Shweta Shinde dell’ETH di Zurigo, queste misure sono insufficienti.

Il funzionamento asincrono dei core x86 consente loro di scrivere linee di cache sporche nella memoria RMP prima che la PSP attivi la protezione completa. Quando i TMR vengono cancellati dopo l’inizializzazione, queste scritture non cancellate vengono scaricate nella DRAM, sovrascrivendo la tabella RMP con valori arbitrari.

Esperimenti condotti su EPYC 9135 (Zen 5), 9124 (Zen 4) e 7313 (Zen 3) hanno confermato che le sovrascritture avvengono senza errori, soprattutto su Zen 3, dove i problemi di coerenza aggravano la situazione. Sebbene il firmware della PSP contenga accenni di meccanismi di protezione come il flushing della cache, la mancanza di un flush TLB globale e la natura chiusa di alcuni componenti impediscono la protezione completa.

L’attacco RMPocalypse consente agli aggressori di mettere le pagine protette in uno stato in cui l’hypervisor può modificarle liberamente. Ciò consente quattro tipi di attacchi:

• Falsificazione dei report di attestazione . Un aggressore può sostituire le pagine di contesto con vecchie copie crittografate, ingannando così il sistema guest e fidandosi falsamente della macchina virtuale dannosa. Le pagine di contesto non sono protette dalla sovrascrittura perché prive di una firma di integrità crittografica.
• Abilitazione della modalità debug. Modificando silenziosamente un singolo bit nella policy di contesto, l’attacco abilita l’API SNPDEBUGDECRYPT/ENCRYPT, garantendo all’hypervisor pieno accesso alla memoria sensibile della macchina virtuale. Tutto ciò avviene senza violare l’attestazione e con un’affidabilità superiore al 99,9% in meno di 15 ms.
• Riproduzione dello stato VMSA. Questo vettore consente di ripristinare i registri della macchina virtuale a uno snapshot precedente, compromettendo l’integrità dell’esecuzione e aprendo la strada a rollback verso stati vulnerabili.
• Iniezione di codice arbitrario. L’aggressore utilizza SNPPAGEMOVE per falsificare i valori di tweak e iniettare traffico dannoso (ad esempio, pacchetti di rete) direttamente nel codice del kernel, bypassando la protezione crittografica e ASLR. L’intero processo richiede circa 5 ms.

Pertanto, SEV-SNP perde completamente le sue proprietà protettive in condizioni di hypervisor non attendibile. Questo è fondamentale per le attività che elaborano dati sensibili, dalle applicazioni aziendali ai modelli di intelligenza artificiale e all’archiviazione cloud.

AMD ha confermato la vulnerabilità e ha annunciato di essere al lavoro sulle patch, ma al momento della pubblicazione, le correzioni per i processori interessati non sono disponibili. Come soluzione temporanea, i ricercatori propongono di riconfigurare le barriere a livello di core, inclusa la pre-validazione delle cache prima della rimozione del TMR o l’imposizione di una cache globale e del flush del TLB dopo aver completato la configurazione RMP. Per Zen 3, questo è complicato dalla necessità di una sincronizzazione aggiuntiva dovuta a problemi di coerenza.

RMPocalypse si unisce agli attacchi CacheWarp e Heckler nel dimostrare quanto siano vulnerabili anche le tecnologie di confidential computing più avanzate. Sebbene AMD abbia parzialmente reso open source il firmware PSP, i componenti proprietari ne ostacolano ancora l’analisi e la mitigazione complete. Poiché la vulnerabilità può essere sfruttata in meno di 234 millisecondi durante la fase SNPINITEX, è necessario rivalutare la fiducia nei meccanismi di sicurezza hardware.

L'articolo RMPocalypse: Un bug critico in AMD SEV-SNP minaccia la sicurezza del cloud proviene da il blog della sicurezza informatica.

In the law enforcement context, “data retention” refers to the mandatory retention by providers of electronic communications services (email, private messaging, internet access providers, etc.) of metadata of all their users only for law enforcement purposes. Because it is applied to everyone indiscriminately, it constitutes a mass surveillance measure. After the former Data Retention Directive was struck down by the CJEU in 2014 as it violated fundamental rights, the Commission is seeking to adopt new rules at EU level, posing a clear threat to everyone’s digital rights.

The post Mass surveillance of telecommunications document pool appeared first on European Digital Rights (EDRi).

Sono apparse sul mercato le prime soluzioni realmente funzionali che utilizzano l’intelligenza artificiale per individuare vulnerabilità nel codice sorgente. La nuova generazione di sistemi AI-SAST, i cosiddetti “AI Security Engineer”, non si limitano più ad automatizzare l’analisi statica, ma imitano il pensiero di un auditor, identificando difetti logici, errori architetturali e incongruenze tra l’intento dello sviluppatore e l’implementazione.

Un ricercatore che ha testato questi prodotti ha riferito che ZeroPath, Corgea e Almanax attualmente offrono i risultati migliori. Questi strumenti possono individuare vulnerabilità ed errori reali in pochi minuti, inclusi difetti complessi nella logica di business, senza l’utilizzo di rigide regole di firma.

Analizzano il contesto, confrontano funzioni, variabili e dati tra file e generano persino potenziali correzioni del codice. Il tasso di falsi positivi è significativamente inferiore a quello delle piattaforme SAST classiche .

I motori di intelligenza artificiale di tali sistemi operano in un processo a più fasi. Innanzitutto, indicizzano il repository, costruiscono un albero sintattico astratto e determinano lo scopo dell’applicazione.

Quindi analizzano il codice in modo sequenziale, riga per riga, funzione per funzione e file per file, utilizzando algoritmi di ricerca proprietari, euristiche e query LLM. La fase finale prevede la verifica della raggiungibilità delle vulnerabilità, la valutazione della loro gravità e la deduplicazione automatica dei risultati. Alcune soluzioni, come ZeroPath, analizzano inoltre le dipendenze, determinando se le CVE pubbliche hanno un impatto su un progetto specifico e generando report SOC 2.

Durante i test, ZeroPath ha dimostrato un tasso di rilevamento prossimo al 100% per le vulnerabilità di test e ha identificato oltre 50 nuovi problemi in progetti open source, tra cui curl, sudo, Next.js, Avahi e Squid.

Tra questi, buffer overflow, gestione errata dei certificati, perdite di memoria, controllo improprio delle eccezioni e vulnerabilità nell’implementazione TLS.

Corgea ha ottenuto ottimi risultati nell’utilizzo di codice JavaScript e ha prodotto report dettagliati con grafici di analisi delle taint, sebbene abbia prodotto un numero elevato di falsi positivi. Almanax si è rivelato utile per individuare frammenti dannosi ed errori semplici all’interno di singoli file, ma è stato meno efficace nell’analisi delle relazioni tra i file.

Nonostante le limitate capacità di correzione automatica e i rari errori di classificazione, l’efficacia di tali sistemi è già impressionante. Possono controllare vecchi frammenti di codice, analizzare automaticamente i nuovi commit, integrarsi con CI/CD e aiutare gli sviluppatori a correggere le vulnerabilità prima del rilascio. Al loro attuale basso costo, queste soluzioni stanno diventando uno strumento estremamente conveniente per i penetration tester e i team di sicurezza aziendale.

La conclusione principale dell’autore è che le piattaforme AI-SAST rappresenteranno uno dei progressi tecnologici più significativi nella sicurezza informatica dalla rinascita del fuzzing negli anni 2010. Non sostituiranno completamente i penetration tester , ma svolgono già gran parte del lavoro di routine, migliorando la qualità del codice e riducendo il numero di vulnerabilità critiche.

L'articolo L’intelligenza artificiale entra nello Sviluppo Sicuro del codice: i nuovi strumenti AI-SAST proviene da il blog della sicurezza informatica.