Come avrete ormai capito nella nostra Rubrica WiFi su RedHotCyber, abbiamo intrapreso un viaggio tecnico e pratico nel mondo delle reti wireless, partendo dalla loro origine storica fino ad arrivare agli attacchi reali che colpiscono quotidianamente utenti e infrastrutture.

Dopo aver esplorato:

• la natura delle reti 802.11 e il loro funzionamento di base;
• i falsi miti più diffusi tra gli utenti (HTTPS, VPN, reti nascoste);
• e aver dimostrato sul campo vulnerabilità e tecniche di attacco (sniffing, DNS spoofing, captive portal hijacking),

abbiamo iniziato ad analizzare anche le prime contromisure, come l’introduzione dei sistemi AAA combinati ai captive portal, utili a regolamentare l’accesso e tracciare gli utenti.

Con questo articolo vogliamo fare un passo in più: andare oltre la semplice segmentazione delle reti e affrontare un aspetto spesso trascurato ma fondamentale, ovvero l’isolamento del traffico locale a livello Layer 2. Perché, come vedremo, segmentare senza isolare è come mettere delle porte… ma senza pareti.

Segmentazione L3

In molti articoli di cybersecurity si enfatizza l’importanza della segmentazione a livello Layer 3, ovvero la suddivisione logica del traffico tramite subnet IP e dispositivi di routing come firewall o router di livello 3. In questo approccio, ogni gruppo di utenti o dispositivi viene collocato in una subnet distinta, e il traffico tra i segmenti viene regolato da apposite policy di accesso definite sul firewall perimetrale.

Questa architettura si basa su tre principi fondamentali:

• Privilegio minimo: ogni dispositivo o utente deve poter accedere solo alle risorse strettamente necessarie, riducendo così la superficie di attacco.
• Definizione chiara dei confini: i segmenti devono essere separati da barriere ben definite per impedire movimenti laterali non autorizzati.
• Monitoraggio continuo: è essenziale rilevare tempestivamente attività sospette o traffico anomalo tra i segmenti per reagire rapidamente a eventuali violazioni.

Per applicare correttamente questo tipo di segmentazione, ogni dispositivo deve essere classificato in base alla funzione e al rischio, e assegnato al segmento più appropriato. Un esempio pratico potrebbe essere:

• VLAN X – Guest WiFi → 192.168.X.0/24
• VLAN Y – Uffici → 192.168.Y.0/24
• VLAN Z – Server → 192.168.Z.0/24

Sulla base del principio del privilegio minimo, le policy di firewall potrebbero essere strutturate così:

• VLAN X (Guest): nessuna comunicazione verso altre VLAN; accesso solo a Internet, con limiti di banda e filtraggio contenuti.
• VLAN Y (Uffici): accesso selettivo solo ad alcuni server (es. DNS, posta, file server), e priorità maggiore sulla navigazione rispetto ai guest.

Tuttavia, nelle reti WiFi Guest e BYOD (Bring Your Own Device), la segmentazione L3 non è sufficiente. Anche se i dispositivi sono assegnati a VLAN distinte e soggetti a regole firewall, possono comunque comunicare tra loro a livello Layer 2.

Questo apre la porta e ci espone a diverse tecniche di attacco interne. Non dimentichiamo una delle regole fondamentali della cybersecurity: bloccare la minaccia il più vicino possibile alla fonte. E il Layer 2 è il punto più vicino al dispositivo e all’utente, dove il controllo deve essere immediato e puntuale

Per questo motivo, non basta segmentare: è fondamentale isolare il traffico anche a livello Layer 2, impedendo ogni comunicazione diretta tra dispositivi all’interno dello stesso segmento. Solo così si può garantire una reale sicurezza in ambienti condivisi o ad alto rischio.

Andiamo a capire quindi come possiamo isolare il traffico a livello 2.

Client Isolation su WiFi:

La funzione di Client Isolation, disponibile su molti access point e controller WiFi, è progettata per impedire la comunicazione diretta tra dispositivi wireless connessi allo stesso SSID. Questa misura agisce a livello Layer 2 dell’infrastruttura WiFi, bloccando il traffico locale (come pacchetti ARP, broadcast, o traffico multicast) tra i dispositivi client.

In pratica, quando un dispositivo tenta di comunicare con un altro client sulla stessa rete wireless, i pacchetti vengono intercettati e bloccati direttamente dall’infrastruttura WiFi. Ciò previene attacchi interni come:

Esistono principalmente due modalità operative per implementare il Client Isolation a livello Layer 2:

1. Dinamica basata su DHCP e Default Gateway
   In questa modalità, al momento della connessione alla rete WiFi, il client riceve un indirizzo IP tramite DHCP, e viene automaticamente autorizzato a comunicare esclusivamente con il MAC address del gateway predefinito. L’infrastruttura applica un filtro a livello Layer 2 che blocca qualsiasi altra comunicazione locale.
   
   • ✅ Vantaggi:
     
     • Non richiede configurazioni manuali.
     • Funziona in modo automatico con la maggior parte dei dispositivi.

     
     

   • ⚠️ Limiti:
     
     • Se un dispositivo utilizza un IP statico, potrebbe non essere riconosciuto correttamente e il traffico verrà bloccato.
     • Per evitare queste situazioni, è consigliabile abilitare la funzione di DHCP enforcement a livello di SSID (quando supportata). Ne parleremo in dettaglio nei prossimi articoli.

     
     

   
   

2. Statica basata su whitelist MAC
   In questa modalità, è possibile configurare manualmente una whitelist di indirizzi MAC autorizzati, come ad esempio quelli del gateway o di eventuali dispositivi di servizio specifici. Così facendo, tutte le comunicazioni locali verso dispositivi diversi da quelli in whitelist vengono bloccate.
   
   • ✅ Vantaggi:
     
     • Maggiore controllo e sicurezza: si evitano automatismi e si definisce in modo esplicito con chi i client possono comunicare.

     
     

   • ⚠️ Limiti:
     
     • Richiede una configurazione manuale: qualsiasi cambiamento del MAC del gateway (per esempio in caso di failover o sostituzione del router) impone l’aggiornamento della whitelist.
     • Meno adatta a reti dinamiche o con variazioni frequenti nella topologia.

     
     

   
   

Entrambe le modalità possono essere scelte o combinate in base al livello di controllo desiderato e alle funzionalità disponibili sugli apparati di rete.

In ogni caso, il principio resta invariato: impedire qualsiasi comunicazione diretta tra i client wireless e garantire che ogni flusso di dati passi attraverso un punto di controllo Layer 3, dove possono essere applicate regole e policy centralizzate.

Private Vlan e Port Protect sulla rete di trasporto:

Come accennato in precedenza, l’isolamento del traffico a livello di rete di trasporto è una misura fondamentale per garantire la sicurezza delle comunicazioni, specialmente in contesti in cui si connettono dispositivi non gestiti, come nelle reti WiFi Guest o BYOD. Questo isolamento diventa cruciale per prevenire attacchi interni e ridurre il rischio di compromissioni tra dispositivi collegati alla stessa rete.

Anche quando la Client Isolation è abilitata a livello wireless, il traffico Layer 2 può comunque propagarsi attraverso la rete cablata, se non vengono adottate ulteriori misure. Questo accade, ad esempio, quando abbiamo, più access point che bridgeano localmente il traffico, inoltrandolo direttamente sulle porte di rete degli switch senza tunnelizzarlo verso un controller centralizzato. In questi casi, i dispositivi connessi a diversi AP potrebbero comunque riuscire a comunicare tra loro attraverso la rete di trasporto, vanificando di fatto l’isolamento previsto sulla rete WiFi.

NB: Se l’access point tunnelizza il traffico guest verso un controller centrale (es. CAPWAP o GRE), l’isolamento può essere gestito a monte, rendendo opzionale l’isolamento locale delle porte. In caso di bridge locale, l’isolamento Layer 2 è invece fondamentale.

Per impedire che dispositivi connessi alla stessa infrastruttura possano comunicare direttamente tra loro, è necessario adottare meccanismi di isolamento Layer 2 a livello switch. Le due tecniche principali per raggiungere questo obiettivo sono:

• Private VLAN (PVLAN): Consente di creare segmentazioni avanzate per isolare i dispositivi connessi alla rete.
• Port Protect: Fornisce un’alternativa leggera e semplice per bloccare la comunicazione diretta tra porte configurate sugli switch.

Entrambe le configurazioni aiutano a:

• Limitare la comunicazione diretta: Bloccare il traffico Layer 2 tra dispositivi connessi.
• Proteggere i dispositivi collegati: Prevenire attacchi interni come sniffing, spoofing o man-in-the-middle.
• Migliorare la sicurezza complessiva: Garantire che ogni dispositivo comunichi solo con entità autorizzate o attraverso un controllo Layer 3.

La scelta tra PVLAN e Port Protect dipende da diversi fattori, tra cui la complessità dell’infrastruttura di rete e i requisiti specifici di isolamento.
Le Private VLAN offrono un isolamento più granulare e flessibile, ideale per ambienti complessi, multi-tenant o con alta densità di utenti.
Al contrario, la funzione Port Protect rappresenta una soluzione più semplice e veloce da implementare, perfetta per contesti meno strutturati o dove è richiesta una configurazione rapida.

NB: Inoltre, va considerato che molti switch entry-level supportano solo Port Protect e non le PVLAN. In questi casi, Port Protect diventa l’unica opzione praticabile per garantire un isolamento Layer 2.

Private VLAN (PVLAN)

Per garantire l’isolamento del traffico a livello di rete di trasporto, è altamente consigliato configurare le Private VLAN (PVLAN). Questa tecnica consente di limitare la comunicazione diretta tra porte all’interno della stessa VLAN, permettendo il traffico solo verso porte specifiche come gli uplink.:

Cos’è una PVLAN?

Una Private VLAN è un’estensione delle VLAN tradizionali

Una Primary VLAN può includere diverse Secondary VLAN, che si classificano in due categorie:

• Isolated VLAN
• Community VLAN

A queste si aggiunge la possibilità di assegnare alla Primary VLAN delle Promiscuous Port.

Tipologie di porte in una PVLAN

1. Promiscuous Ports (Porte Promiscue):
   
   • Possono comunicare con tutte le porte ( comprese le isolate e community).
   • Tipicamente utilizzata per uplink verso router, firewall, gateway o server condivisi.

   
   

2. Isolated Ports (Porte Isolate):
   
   • Non può comunicare con altre porte isolate, ma solo con la promiscuous.
   • Ideale per client guest o dispositivi che non devono mai comunicare tra loro (es. le porte che sono verso gli AP).

   
   

3. Community Ports (Porte Comunitarie):
   
   • Può comunicare con altre porte della stessa community e con la promiscuous, ma non con le porte isolate.
   • Utile per piccoli gruppi che condividono risorse, come stampanti o NAS interni. Le porte community solitamente non vengono utilizzate in una rete guest o BYOD.

   
   

Come Funziona una PVLAN

Lo schema rappresenta una configurazione Private VLAN (PVLAN) su uno switch gestito, con porte suddivise in diverse tipologie:

Promiscuous Port (P)

• Situata a sinistra dello switch, è collegata al router/firewall, ovvero il punto di uscita verso la rete esterna.
• Tutti i dispositivi nello schema possono comunicare con questa porta.
• Serve come gateway centralizzato per l’accesso a Internet o a servizi comuni.

Community Ports (C1 e C2)

• I PC grigi in alto sono collegati a porte di tipo C1 (Community 1).
• I PC blu a destra sono collegati a porte di tipo C2 (Community 2).

Comportamento:

• I dispositivi C1 possono comunicare tra loro e con la promiscuous (P), ma non con i dispositivi C2 o I.
• I dispositivi C2 possono comunicare tra loro e con la promiscuous (P), ma non con i dispositivi C1 o I.

👉In questo modo abbiamo più “gruppi di lavoro” indipendenti sulla stessa VLAN, ciascuno isolato dagli altri ma con accesso condiviso a internet.

Isolated Ports (I)

• I tre PC rossi in basso sono connessi a porte isolate.

Comportamento:

• Questi dispositivi non possono comunicare tra loro.
• Possono parlare solo con la porta promiscuous (P), quindi accedere a internet tramite il router/firewall.
• Sono perfetti per ambienti guest WiFi o dispositivi non affidabili che devono essere completamente separati l’uno dall’altro e dagli altri apparati di rete

Collegamento tra Switch

• In basso a sinistra è presente un uplink verso un secondo switch.
• Le porte di uplink tra switch in una rete PVLAN devono essere configurate come trunk, trasportare tutte le VLAN coinvolte (Primary + Secondary), e non devono avere alcun ruolo PVLAN assegnato.
• L’obiettivo è mantenere la struttura di isolamento identica su tutta la dorsale della rete.

Sintesi comportamentale

Questa configurazione garantisce un isolamento di livello 2 molto preciso, mantenendo allo stesso tempo l’accesso centralizzato alle risorse comuni. È particolarmente utile in ambienti ad alta densità, come hotel, data center, coworking o reti BYOD.

Port Protect: l’alternativa semplice alle PVLAN

La funzione Port Protect, disponibile su molti switch gestiti, è una soluzione pratica per impedire la comunicazione diretta tra dispositivi connessi a porte Layer 2 sullo stesso dominio di broadcast.

A differenza delle PVLAN, Port Protect lavora a livello di porta, non richiede configurazione VLAN secondarie e risulta particolarmente utile quando:

• l’infrastruttura non supporta PVLAN
• si opera in ambienti più semplici, dove è sufficiente un isolamento minimo ma efficace .

Possiamo vedere la protect port come una soluzione rapida e semplice da implementare, anche senza policy complesse.

Esempio pratico della port protect

Analizzando lo schema in alto possiamo quindi affermare che tutti PC possono parlare con il router/firewall ma non tra di loro.

Tabella comparativa: PVLAN vs Port Protect

Scenari pratici – quale soluzione adottare?

Conclusioni

Le reti WiFi aperte, per loro natura, nascono come insicure: nessuna autenticazione, traffico in chiaro, utenti non tracciati.
Ma questo non significa che non possiamo fare nulla per migliorare la situazione.

Una delle contromisure più efficaci è l’isolamento del traffico a livello Layer 2.
Bloccare la comunicazione diretta tra dispositivi connessi alla stessa rete – WiFi o cablata – è fondamentale per prevenire attacchi laterali come sniffing, ARP spoofing o accessi non autorizzati.

Tecnologie come le Private VLAN e la Port Protect ci permettono di ottenere questo isolamento in modo efficace e adattabile al tipo di infrastruttura.

Queste soluzioni, insieme ad altre contromisure che stiamo approfondendo nella nostra rubrica (come Captive Portal e AAA), trasformano una WiFi aperta in un ambiente più sicuro.

Non possiamo sempre impedire ad un attaccante di entrare in una rete pubblica aperta.
Ma possiamo – anzi dobbiamo – fare tutto quello che è in nostro potere per evitare che possa nuocere ad altri.

L'articolo Reti WiFi Guest: Segmentare senza isolare è come mettere porte senza pareti. proviene da il blog della sicurezza informatica.

Пиратская партия России, являясь партией-основательницей и неотъемлемой частью международного пиратского движения, публикует заявление пиратского интернационала об эскалации конфликта на Ближнем Востоке.

Мы в Пиратском интернационале с глубокой обеспокоенностью наблюдаем за последней эскалацией между Израилем и Ираном. Израиль заявляет, что нанёс упреждающие удары по ядерным и военным объектам Ирана. Однако режим Нетаньяху уже ведет разрушительную войну в Газе, и его военные действия, похоже, продиктованы в большей степени политическим выживанием и стремлением укрепить своё наследие, чем реальной безопасностью. Международное сообщество вправе требовать четких доказательств и прозрачности в отношении этих атак.

С другой стороны, режим Хаменеи в Иране также правит жестоко. Иран продолжает наносить удары по гражданским объектам, намеренно выбирая цели, далёкие от законных военных объектов. Иранскому режиму необходимо немедленно прекратить разработку ядерного оружия, поддержку терроризма против еврейских общин и поставки вооружения таким группировкам, как хуситы в Йемене и «Хезболла» в Ливане.

Пиратский интернационал подчёркивает, что дипломатические решения должны иметь приоритет над военной агрессией. Мы глубоко обеспокоены конфликтом, который угрожает миллионам невинных жизней, создаёт риск серьёзных ядерных инцидентов и становится всё более непредсказуемым. Общественность справедливо опасается, что ядерные арсеналы уже могут быть задействованы, ставя под угрозу мирных жителей, которые не могут полагаться исключительно на системы ПВО и бомбоубежища.

Мы однозначно призываем к немедленному прекращению огня.

Наше движение объединяет людей по всему миру, включая членов Пиратской партии в Израиле, сочувствующих в Иране и многих выходцев из Ирана, живущих в изгнании. По-настоящему отрадно, что наши израильские и иранские коллеги конструктивно обсуждают этот кризис, открыто исследуя пути к миру. Мы лишь можем пожелать, чтобы политические лидеры, укоренившиеся в обоих правительствах, проявили такую же мудрость и человечность.

Мы выступаем за большую свободу, прозрачность и права человека для всех пострадавших народов. Мы настоятельно призываем к возобновлению диалога на уровне гражданского общества и открытию каналов связи между жителями Израиля и Ирана, которых объединяет общий интерес к миру и согласию. Прошлые попытки объединить эти сообщества напоминают нам, что солидарность и взаимопонимание достижимы.

Мы призываем все стороны ставить жизнь мирных жителей выше любых политических амбиций. Пиратский интернационал твёрдо выступает за мир, прозрачность и силу людей, а не режимов.

Оригинал на английском: pp-international.net/2025/06/i…

Сообщение Заявление Пиратского интернационала об эскалации конфликта на Ближнем Востоке появились сначала на Пиратская партия России | PPRU.

#fiom #Firenze

When [Ben Eater] talks, hackers everywhere listen. In his latest video [Ben] shows us how to make computer noises using square waves and a 6502 microprocessor.

[Ben] uses the timer in the W65C22 Versatile Interface Adapter to generate the square waves which generate a tone. He then adds support for a new BEEP command into his MS BASIC interpreter. We covered [Ben Eater]’s MS BASIC here at Hackaday back in April, so definitely check that out if you missed it.

After checking the frequency of oscillation using his Keysight oscilloscope he then wires in an 8Ω 2W speaker via a LM386 audio amplifier. We can’t use the W65C22 output pin directly because that can only output a few milliwatts of power. [Ben] implements the typical circuit application from the LM386 datasheet to drive the speaker. To complete his video [Ben] writes a program for his BASIC interpreter which plays a tune.

Thanks to [Mark Stevens] for writing in to let us know about this one. If you’re planning to play along at home a good place to start is to build your own 6502, like [Ben] did!

youtube.com/embed/tIOR7kRevPU?…

hackaday.com/2025/06/19/ben-ea…

When we were kids, it was a rite of passage to read the newly arrived Edmund catalog and dream of building our own telescope. One of our friends lived near a University, and they even had a summer program that would help you measure your mirrors and ensure you had a successful build. But most of us never ground mirrors from glass blanks and did all the other arcane steps required to make a working telescope. However, [La3emedimension] wants to tempt us again with a 3D-printable telescope kit.

Before you fire up the 3D printer, be aware that PLA is not recommended, and, of course, you are going to need some extra parts. There is supposed to be a README with a bill of parts, but we didn’t see it. However, there is a support page in French and a Discord server, so we have no doubt it can be found.

It is possible to steal the optics from another telescope or, of course, buy new. You probably don’t want to grind your own mirrors, although good on you if you do! You can even buy the entire kit if you don’t want to print it and gather all the parts yourself.

The scope is made to be ultra-portable, and it looks like it would be a great travel scope. Let us know if you build one or a derivative.

This telescope looks much different than other builds we’ve seen. If you want to do it all old school, we’ve seen a great guide.

hackaday.com/2025/06/19/build-…

Thanks to everyone who helped map surveillance cameras in Harvard Square. We identified nearly 50 surveillance cameras between JFK Street, Mount Auburn Street, Bow Street and Massachusetts Avenue.

Join us this Saturday, June 21st, at the Boxborough Fifers Day. Tell us if you will help us at the table. It is a wonderful event that celebrates our Revolutionary War history.

masspirates.org/blog/2025/06/1…

We’ve seen a lot of projects based on the Pi Pico, but a nuclear reactor simulation is a new one. This project was created by [Andrew Shim], [Tyler Wisniewski] and another group member for Cornell’s ECE 4760 class on embedded design (which should silence naysayers who think the Pi Pico can’t be a “serious” microcontroller), and simulates the infamous soviet RMBK reactor of Chernobyl fame.

The simulation uses a 4-bit color VGA model. The fission model includes uranium fuel, water, graphite moderator, control rods and neutrons. To simplify the math, all decayed materials are treated identically as non-fissile, so no xenon poisoning is going to show up, for example. You can, however, take manual control to both scram the reactor and set it up to melt down with the hardware controller.

The RP2040’s dual-core nature comes in handy here: one core runs the main simulation loop, and the main graphic on the top of the VGA output; the other core generates the plots on the bottom half of the screen, and the Geiger-counter sound effect, and polls the buttons and encoders for user input. This is an interesting spread compared to the more usual GPU/CPU split we see on projects that use the RP2040 with VGA output.

An interesting wrinkle that has been declared a feature, not a bug, by the students behind this project, is that the framebuffer cannot keep up with all the neutrons in a meltdown simulation. Apparently the flickering and stuttering of frame-rate issues is “befitting of the meltdown scenario”. The idea that ones microcontroller melts down along with the simulated reactor is rather fitting, we agree. Check it out in a full walkthrough in the video below, or enjoy the student’s full writeup at the link above.

This project comes to us via Cornell University’s ECE 4760 course, which we’ve mentioned before. Thanks to [Hunter Adams] for the tipoff. You may see more student projects in the coming weeks.

youtube.com/embed/SqB7Jm-Cdmk?…

hackaday.com/2025/06/19/fissio…

It’s sometimes useful for a system to not just have a flat 2D camera view of things, but to have an understanding of the depth of a scene. Dual RGB cameras can be used to sense depth by contrasting the two slightly different views, in much the same way that our own eyes work. It’s considered an economical but limited method of depth sensing, or at least it was before FoundationStereo came along and blew previous results out of the water. That link has a load of interactive comparisons to play with and see for yourself, so check it out.
A box of disordered tools at close range is understood very well, and these results are typical for the system.
The FoundationStereo paper explains how researchers leveraged machine learning to create a system that can not only outperform existing dual RGB camera setups, but even active depth-sensing cameras such as the Intel RealSense.

FoundationStereo is specifically designed for strong zero-shot performance, meaning it delivers useful general results with no additional training needed to handle any particular scene or environment. The framework and models are available from the project’s GitHub repository.

Microsoft may have discontinued the Kinect and Intel similarly discontinued RealSense, but depth sensing remains an enabling technology that opens possibilities and gives rise to interesting projects, like a headset that allows one to see the world through the eyes of a depth sensor.

The ability to easily and quickly gain an understanding of the physical layout of a space is a powerful tool, and if a system like this one can deliver such fantastic results with nothing more than two RGB cameras, that’s a great sign. Watch it in action in the video below.

youtube.com/embed/R7RgHxEXB3o?…

hackaday.com/2025/06/19/dual-r…

A hacker’s view on ESD protection can tell you a lot about them. I’ve seen a good few categories of hackers neglecting ESD protection – there’s the yet-inexperienced ones, ones with a devil-may-care attitude, or simply those of us lucky to live in a reasonably humid climate. But until we’re able to control the global weather, your best bet is to befriend some ESD diodes before you get stuck having to replace a microcontroller board firmly soldered into your PCB with help of 40 through-hole pin headers.

Humans are pretty good at generating electric shocks, and oftentimes, you’ll shock your hardware without even feeling the shock yourself. Your GPIOs will feel it, though, and it can propagate beyond just the input/output pins inside your chip. ESD events can be a cause of “weird malfunctions”, sudden hardware latchups, chips dying out of nowhere mid-work – nothing to wish for.

Worry not, though. Want to build hardware that survives? Take a look at ESD diodes, where and how to add them, where to avoid them, and the parameters you want to keep in mind. Oh and, I’ll also talk about all the fancy ways you can mis-use ESD diodes, for good and bad alike!

How It’s Made

The simplest ESD diode is just two diodes in series, with the protected signal connected at midpoint. The wiring is easy to remember – wire the diodes in a way that they don’t conduct from 3.3 V to GND, so, in reverse, same way you’d wire up a diode to shunt a relay coil. It’s only meant to conduct in unprecedented circumstances, not normally.

Say, you use a diode with 0.7 V forward voltage drop. Then, such a configuration will shunt voltages above – into your power rails and ground, both low-impedance with plenty of capacitance and inductance, enough to dissipate the shock energy. Lower than GND – 0.7 V, and higher than VCC + 0.7 V – ever seen that mentioned in datasheets, by the way?

The overwhelming majority of ICs come with ESD diodes built-in. CMOS logic, overwhelmingly prevalent these days, basically requires them – FETs are overwhelmingly sensitive to ESD events, especially their gates. Don’t believe me? Here’s a highly persuasive video we’ve covered, that shows a FET easily dying from an ESD event!

So, is your job done here? Can you just rely on IC-internal ESD diodes? No, sadly. IC-internal ESD diodes are nice and a must have, but not sufficient for a large portion of shock. Effectively, they’re there for lower-grade GPIO protection. If your GPIOs go, or could easily go, to the outside world, or maybe they’re near high-power rails, maybe you’re driving a speaker or some motors with part of your circuit, or if maybe you want to touch your board with your fingers sometimes – you will want to add your own ESD diodes into the mix.

Let’s Protect Some GPIOs

You can use two diodes in a pinch – two 1N4148’s are a valid form of ESD protection. Better yet, you can buy a two-diode component ready to go. Here’s a part number – BAV99; it’s two diodes in series, in SOT23, with midpoint being on pin 3. Top pin to VCC, bottom pin to GND, middle pin goes to your signal – what could be easier to route? BAV99 isn’t quite intended to be an ESD diode, but it will perform wonderfully. This is the most basic protection you can give a GPIO – throw in a low-value series resistor too, if you’re generous. If you’re doing, say, a RP2040 circuit, you will already have some 27R resistors in series – just sprinkle some more of those on your board, and you’re golden.

But Wait, There’s More

Is that all you can do with these? No, there’s more! Remember how you have to put a diode across a relay coil or a motor that you’re driving with a transistor? Here’s a fun relay for you – Omron G6SK-2. It’s a tiny relay for switching signals (think analog audio switching), and what’s cool about it, it’s latching. You know how you need to reverse the voltage polarity on a DC motor in order to reverse the direction it spins? This relay uses polarity reversal to switch, instead of a coil that requires constant power draw to keep one set of contacts connected.

So, a tiny relay for signals, that requires zero power to stay on. Now, how do you drive it? With motors, you drive them with a H-bridge – one transistor from VCC, one from GND, for each pole, and these four transistors are typically put inside a single IC. However, using a whole H-bridge IC on a tiny relay that barely needs any power to begin with? Feels quite wasteful!

A GPIO set to output is electrically equivalent to a H-bridge. Put the relay’s coil between two GPIOs instead, and you can effortlessly switch it. What about a back EMF protection diode? Can’t put it across the coil anymore, then you couldn’t switch polarity. Instead, just put a pair of ESD diodes on the GPIOs, and you’re good.

You can drive a fair bit of stuff this way – not just cool low-power relays, but also linear actuators like iPhone’s Taptic Engines, vibromotors, and tiny electromagnets. So, if you needed to stock up on BAV, this is your extra reason to do so.

Where would you commonly put these kinds of diodes? On external GPIOs, yes, but also buttons – even if they’re behind a thin layer of plastic!, – and keypads, user-touchable pogo pins, off-board connectors, headphone jacks, iButton pads, and so on. These are not the only diodes you’ll ever want, of course. Let’s talk about ESD diode capacitance and where it starts to matter.

High Speed, High Demands

Imagine a Pi Pico. On it, there are GPIOs worth protecting. What else? The USB port, for sure – and if you’re daring enough to wire Ethernet to a Pico, also those pins. However, if you do use BAV, you might experience signal degradation, or other unexpected side effects. Why? One major reason is ESD diode capacitance.

High-capacitance diodes will mess with high-speed signals. That’s why we have lower-capacitance ESD diodes, though. SRV-05 is one of these – it’s an old and trusty part, with many pin-compatible successors and clones alike. Four diodes inside, one pin for VCC, one for GND – it just works, whether you do USB2, Ethernet 100 or 1000 – or even capacitive touch pads! Captouch benefits a whole lot from ESD protection, as you might guess, and low-capacitance diodes are a must – just remember to also check the docs of the captouch chip you’re using and see what it says about the matter.

Using a SOT23-6 pack like this to protect USB lines? Watch out for how you’re supposed to wire it up. Some diode packs have internal connections and expect you to interrupt the signal under them, and other ones require you to pull wires under the package; some of them include inductors. Check the datasheet for an example schematic and compare with yours.

Another pitfall to mind. Remember how there’s one path to GND and one to VCC? Well… What if your GPIO is powered, but your VCC isn’t? Power will flow from the GPIO into VCC – you might remember this one from the cut-down ATTiny we’ve featured. This is also a problem you can stumble upon if you put chips with multiple power inputs and don’t think about it.

Where else could this situation appear? Why, USB-C. If you’re connecting ADC channels to CC pins, like you would if you want to check that you do get 3A at 5V, you’ll want to protect that. Or maybe you have a PD controller on your board – you’ll want to protect its CC pins, for sure. Now, remember how CC negotiation works? A PSU has a resistor from its VBUS to the CC pin(s), and it measures the CC voltages, expecting a 5.1K resistor. What if your VBUS isn’t powered and you use a VBUS-connected ESD diode on CC? Part of the CC pullup current flows into VBUS, voltage sags, CC voltage is lower than expected, and the PSU never ends up supplying VBUS.

No VBUS, No Problems

Bad? Bad. I’ve stumbled upon this one recently, in my own project, was quite a headscratcher. Thankfully, you don’t actually need a VBUS connection – really, all you need is to shunt voltage if it exceeds a certain threshold. We have diodes for that, too! They’re called TVS – it’s kind of like a Zener, but better. In fact, since SOT23-6 ESD diodes tend to contain a TVS, you might be able to disconnect VBUS from your SOT23-6 altogether. However, you should still know about yet another breed of ESD diodes – for a start, they’re probably the flattest ESD diodes you’ll work with.

In VBUS-less ESD diodes, instead of a VBUS connection, the top point goes to a TVS diode to ground. When the top point voltage raises above the TVS diode’s threshold voltage, the diode starts conducting. The TVS diode has to dissipate the ESD shock energy now, but they’re big boy TVS diodes, they can handle it.

DFN25-10 format diodes. Where have you seen them? A Raspberry Pi, for one – there, they’re right next to the HDMI connector(s), three of them at the very least! These diodes are great for general purpose protecting whatever you want, too – you can put them on USB, Ethernet, USB CC pins, keyboard matrix pins. My fave part number is TPAZ1043, but don’t hold onto that – just look up DFN2510 and you’ll find alternatives aplenty.

Any catches with these? The threshold voltage, for one. If you’re doing 3.3V GPIOs, you want to make sure your diode won’t start shunting them – and if you buy a diode aimed at protecting modern-day interfaces like USB3, its threshold might very well be 3.3V or a little below – borderline if not outright disqualifying if you want your GPIO (or a USB2 connection) to stay unaffected. It’s a wonderful diode, of course, just, the wrong application.

They’re the nicest to route, too. Put them inline with signals, put a via down to your GND (0.5/0.3 via will do wonders), and you’re set. The catch with that? You might relax a little too much when using them, gotta remember to keep on your toes.

A Key Element

Think we’re done? Not yet. Remember that they’re very flat? Now, where could you use some very flat diodes? How about… a handheld keyboard with NKRO? NKRO needs diodes on every key, but if you’re doing a even 50-key handheld keeb, you might not necessarily want to use 50 separate diodes. Not to worry – the to-ground diodes inside the DFN2510 ESD diode pack are still good to go. Able to connect four keys per diode pack, these are way easier to handle and pick-and-place than regular tiny-package SMD diodes, and they make sure your keyboard can do all sorts of key combos. You know, to compensate for the lower amount of keys.

The hacks are cool, of course, but above all, ESD diodes are meant to make sure that your hardware lasts. Whether you’re building a devboard, a captouch arts installation, a trusty pocket electronics multitool, a custom clock to gift to your kid, or the tiniest keyboard ever, ESD diodes are your friends. You should sprinkle them on your circuits, keep them in your stock, spread the word, and they will protect you in turn.

Liked this article? Check out one of the previous Hacker Tactic installments, where I’ve shown you how to detect internal ESD diodes with a multimeter, specifically, to probe wiring continuity and reverse-engineer circuits! You should know about it, too.

If you’re a retro Nintendo fan you can of course carry a NES and a Game Boy around with you, but the former isn’t very portable. Never fear though, because here’s [Chad Burrow], who’s created a neat handheld console that emulates both.

It’s called the Acolyte Handheld, and it sports the slightly unusual choice for these parts of a PIC32 as its main processor. Unexpectedly it can use Sega Genesis controllers, but it has the usual buttons on board for portable use. It can drive either its own LCD or an external VGA monitor, and in a particularly nice touch, it switches between the two seamlessly. The NES emulator is his own work, while Game Boy support comes courtesy of Peanut-GB.

We like the design of the case, and particularly that of the buttons. Could it have been made smaller by forgoing some of the through-hole parts in favour of SMD ones? Quite likely, but though it’s chunky it’s certainly not outsized.

Portable Nintendo-inspired hardware is popular around here, as you can see with this previous handheld NES

hackaday.com/2025/06/19/game-b…

Gli sviluppatori di Veeam hanno rilasciato delle patch che risolvono diverse falle in Veeam Backup & Replication (VBR), tra cui una vulnerabilità critica legata all’esecuzione di codice remoto (RCE). Il problema, a cui è stato assegnato l’identificatore CVE-2025-23121 (9,9 punti sulla scala CVSS), è stato scoperto dagli esperti di watchTowr e CodeWhite e sembrerebbe che la vulnerabilità riguardi solo le installazioni aggiunte a un dominio.

Come spiegato da Veeam in un bollettino di sicurezza, la vulnerabilità potrebbe essere sfruttata dagli utenti autenticati del dominio per eseguire codice da remoto sul server di backup. Il bug riguarda Veeam Backup & Replication versione 12 e successive ed è stato risolto nella versione 12.3.2.3617. Sebbene CVE-2025-23121 riguardi solo le installazioni VBR aggiunte a un dominio, può essere sfruttato da qualsiasi utente di dominio, facilitandone l’abuso in tali casi.

Si è notato che molte aziende collegano i propri server di backup a un dominio Windows, ignorando le raccomandazioni di Veeam, nonostante l’azienda insista sempre nell’utilizzare una foresta di Active Directory separata e nel proteggere gli account amministrativi con l’autenticazione a due fattori.

È opportuno notare che a marzo 2025 gli specialisti di watchTowr Labs avevano già scoperto una vulnerabilità simile (CVE-2025-23120), che rappresentava un problema di deserializzazione nelle classi .NET Veeam.Backup.EsxManager.xmlFrameworkDs e Veeam.Backup.Core.BackupSummary.

Questa vulnerabilità, come altri bug precedenti, era correlata a BinaryFormatter, un componente legacy che, secondo Microsoft, non è affidabile per la deserializzazione dei dati e non può essere protetto in alcun modo. In altre parole, l’applicazione non gestiva correttamente i dati serializzati, il che consentiva l’introduzione di oggetti e gadget dannosi in grado di eseguire codice pericoloso.

La radice del nuovo problema CVE-2025-23121 risiede probabilmente nella stessa area. Pertanto, a marzo, lo specialista di watchTowr Anton Gostev ha scritto che finché BinaryFormatter non verrà rimosso da VBR, tali problemi di sicurezza si ripresenteranno inevitabilmente.

Si consiglia ora alle aziende che utilizzano Veeam Backup & Replication di eseguire l’aggiornamento alla versione 12.3.2.3617 il prima possibile.

L'articolo Allarme sicurezza Veeam! falla critica consente RCE sui server di backup proviene da il blog della sicurezza informatica.

Where’s the best place for a datacenter? It’s an increasing problem as the AI buildup continues seemingly without pause. It’s not just a problem of NIMBYism; earthly power grids are having trouble coping, to say nothing of the demand for cooling water. Regulators and environmental groups alike are raising alarms about the impact that powering and cooling these massive AI datacenters will have on our planet.

While Sam Altman fantasizes about fusion power, one obvious response to those who say “think about the planet!” is to ask, “Well, what if we don’t put them on the planet?” Just as Gerald O’Niell asked over 50 years ago when our technology was merely industrial, the question remains:

“Is the surface of a planet really the right place for expanding technological civilization?”

O’Neill’s answer was a resounding “No.” The answer has not changed, even though our technology has. Generative AI is the latest and greatest technology on offer, but it turns out it may be the first one to make the productive jump to Earth Orbit. Indeed, it already has, but more on that later, because you’re probably scoffing at such a pie-in-the-sky idea.

There are three things needed for a datacenter: power, cooling, and connectivity. The people at companies like Starcloud, Inc, formally Lumen Orbit, make a good, solid case that all of these can be more easily met in orbit– one that includes hard numbers.

Sure, there’s also more radiation on orbit than here on earth, but our electronics turn out to be a lot more resilient than was once thought, as all the cell-phone cubesats have proven. Starcloud budgets only 1 kg of sheilding per kW of compute power in their whitepaper, as an example. If we can provide power, cooling, and connectivity, the radiation environment won’t be a showstopper.

Power

There’s a great big honkin’ fusion reactor already available for anyone to use to power their GPUs: the sun. Of course on Earth we have tricky things like weather, and the planet has an annoying habit of occluding the sun for half the day but there are no clouds in LEO. Depending on your choice of orbit, you do have that annoying 45 minutes of darkness– but a battery to run things for 45 minutes is not a big UPS, by professional standards. Besides, the sun-synchronous orbits are right there, just waiting for us to soak up that delicious, non-stop solar power.
Sun Synchronous Orbit, because nights are for squats. Image by Brandir via Wikimedia.
Sun-synchronous orbits (SSOs) are polar orbits that precess around the Earth once every sidereal year, so that they always maintain the same angle to the sun. For example, you might have an SSO that crosses the equator 12 times a day, each time at local 15:00, or 10:43, any other time set by the orbital parameters. With SSOs, you don’t have to worry about ever losing solar power to some silly, primitive, planet-bound concept like nighttime.

Without the atmosphere in the way, solar panels are also considerably more effective per unit area, something the Space Solar Power people have been pointing out since O’Neill’s day. The problem with Space Solar Power has always been the efficiencies and regulatory hurdles of beaming the power back to Earth– but if you use the power to train an AI model, and send the data down, that’s no longer an issue. Given that the 120 kW array on ISS has been trouble-free for decades now, we can consider it a solved problem. Sure, solar panels degrade, but the rate is in fractions of a percent per year, and it happens on Earth too. By the time solar panel replacement is likely to be the rest of the hardware is likely to be totally obsolete.

Cooling

This is where skepticism creeps in. After all, cooling is the greatest challenge with high performance computing hardware here on earth, and heat rejection is the great constraint of space operations. The “icy blackness of space” you see in popular culture is as realistic as warp drive; space is a thermos, and shedding heat is no trivial issue. It is also, from an engineering perspective, not a complex issue. We’ve been cooling spacecraft and satellites using radiators to shed heat via infrared emission for decades now. It’s pretty easy to calculate that if you have X watts of heat to reject at Y degrees, you will need a radiator of area Z. The Stephan-Boltzmann Law isn’t exactly rocket science.
Photons go out, liquid cools down. It might be rocket science, but it’s a fairly mature technology. (Image: EEATCS radiator deployment during ISS Flight 5A, NASA)
Even better, unlike on Earth where you have changeable things like seasons and heat waves, in a SSO you need only account for throttling– and if your data center is profitable, you won’t be doing much of that. So while you need a cooling system, it won’t be difficult to design. Liquid or two-phase cooling on server hardware? Not new. Plumbing cooling a loop to a radiator in the vacuum of space? That’s been part of satellite busses for years.

Aside from providing you with a stable thermal environment, the other advantage of an SSO is that if one chooses the dawn/dusk orbit along the terminator, while the solar panels always face the sun, the radiators can always face black space, letting them work to their optimal potential. This would also simplify the satellite bus, as no motion system would be required to keep the solar panels and radiators aligned into/out of the sun. Conceivably the whole thing could be stabilized by gravity gradient, minimizing the need to use reaction wheels.

Connectivity

One word: Starlink. That’s not to say that future data centers will necessarily be hooking into the Starlink network, but high-bandwidth operations on orbit are already proven, as long as you consider 100 gigabytes per second sufficient bandwidth. An advantage not often thought of for this sort of space-based communications is that the speed of light in a vacuum is about 31% faster than glass fibers, while the circumference of a low Earth orbit is much less than 31% greater than the circumference of the planet. That reduces ping times between elements of free-flying clusters or clusters and whatever communications satellite is overhead of the user. It is conceivable, but by no means a sure thing, that a user in the EU might have faster access to orbital data than they would to a data center in the US.

The Race

This hypothetical European might want to use European-owned servers. Well, the European Commission is on it; in the ASCEND study (Advanced Space Cloud for European Net zero Emission and Data sovereignty) you can tell from the title they put as much emphasis on keeping European data European as they do on the environmental aspects mentioned in the introduction. ASCEND imagines a 32-tonne, 800 kW data center lofted by a single super-heavy booster (sadly not Ariane 6), and proposes it could be ready by the 2030s. There’s no hint in this proposal that the ASCEND Consortium or the EC would be willing to stop at one, either. European efforts have already put AI in orbit, with missions like PhiSat2 using on-board AI image processing for Earth observation.
You know Italians were involved because it’s so stylish. No other proposal has that honeycomb aesthetic for their busy AI bees. Image ASCEND.

AWS Snowcone after ISS delivery. The future is here and it’s wrapped in Kapton. (Image NASA)
The Americans, of course, are leaving things to private enterprise. Axiom Space has leveraged their existing relationship with NASA to put hardware on ISS for testing purposes, staring with an AWS snowcone in 2022, which they claimed was the first flight-test of cloud computing. Axiom has also purchased space on the Kepler Relay Network satellites set to launch late 2025. Aside from the 2.5 Gb/s optical link from Kepler, exactly how much compute power is going into these is not clear. A standalone data center is expected to follow in 2027, but again, what hardware will be flying is not stated.

There are other American companies chasing venture capital for this purpose, like Google-founder-backed Relativity Space or the wonderfully-named Starcloud mentioned above. Starcloud’s whitepaper is incredibly ambitious, talking about building an up to 5 GW cluster whose double-sided solar/radiator array would be by far the largest object ever built in orbit at 4 km by 4 km. (Only a few orders of magnitude bigger than ISS. Not big deal.) At least it is a modular plan, that could be built up over time, and they are planning to start with a smaller standalone proof-of-concept, Starcloud-2, in 2026.
You can’t accuse Starcloud of thinking small. (Image Starcloud via Youtube.)A closeup of one of the twelve “Stars” in the Three Body Computing Constellation. This times 2,800. Image ADA Space.
Once they get up there, the American and European AIs are are going to find someone else has already claimed the high ground, and that that someone else speaks Chinese. A startup called ADA Space launched 12 satellites in May 2025 to begin building out the world’s first orbital supercomputer, called the Three Body Computing Constellation. (You can’t help but love the poetry of Chinese naming conventions.)

Unlike the American startups, they aren’t shy about its capabilities: 100 Gb/s optical datalinks, with the most powerful satellite in the constellation capable of 744 trillion operations per second. (TOPS, not FLOPS. FLOPS specifically refers to floating point operations, whereas TOPS could be any operation but usually refers to operations on 8-bit integers.)

For comparison, Microsoft requires an “AI PC” like the copilot laptops to have 40 TOPS of AI-crunching capacity. The 12 satellites must not be identical, as the constellation together has a quoted capability of 5 POPS (peta-operations per second), and a storage capacity of 30 TB. That’s seems pretty reasonable for a proof-of-concept. You don’t get a sense of the ambition behind it until you hear that these 12 are just the first wave of a planned 2,800 satellites. Now that’s what I’d call a supercluster!
A man can dream, can’t he? Image NASA.
High-performance computing in space? It’s no AI hallucination, it’s already here. There is a network forming in the sky. A sky-net, if you will, and I for one welcome our future AI overlords. They already have the high ground, so there’s no point fighting now. Hopefully this datacenter build-out will just be the first step on the road Gerry O’Neill and his students envisioned all those years ago: a road that ends with Earth’s surface as parkland, and civilization growing onwards and upwards. Ad astra per AI? There are worse futures.