There are still a few days before the doors open on this year’s Hackaday Supercon in Pasadena, but for the most dedicated attendees, the badge hacking has already begun…even if they don’t have a badge yet.

By referencing the design files we’ve published for this year’s Communicator badge, [Thomas Flummer] was able to produce this gorgeous 3D printed case that should be immediately recognizable to fans of the original Star Trek TV series.
Metal hinge pin? Brass inserts? Scotty would be proud.
Although the layout of this year’s badge is about as far from the slim outline of the iconic flip-up Trek communicator as you can get, [Thomas] managed to perfectly capture its overall style. By using the “Fuzzy Skin” setting in the slicer, he was even able to replicate the leather-like texture seen on the original prop.

Between that and the “chrome” trim, the finished product really nails everything Jadzia Dax loved about classic 23rd century designs. It’s not hard to imagine this could be some companion device to the original communicator that we just never got to see on screen.

While there’s no denying that the print quality on the antenna lid is exceptional, we’d really like to see that part replaced with an actual piece of brass mesh at some point. Luckily, [Thomas] has connected it to the body of the communicator with a removable metal hinge pin, so it should be easy enough to swap it out.

Considering the incredible panel of Star Trek artists that have been assembled for the Supercon 2025 keynote, we imagine this won’t be the last bit of Trek-themed hacking that we see this weekend — which is fine by us.

hackaday.com/2025/10/29/superc…

This week Jonathan and Rob chat with Cody Zuschlag about the Xen project! It’s the hypervisor that runs almost everywhere. Why is it showing up in IoT devices and automotive? And what’s coming next for the project? Watch to find out!

• xenproject.org/
• devrel.codyfactory.eu/feed//
• linkedin.com/in/cody-zuschlag/
• xenproject.org/contribute/ci/s…

youtube.com/embed/z1bXf5mTzcY?…

Did you know you can watch the live recording of the show right on our YouTube Channel? Have someone you’d like us to interview? Let us know, or have the guest contact us! Take a look at the schedule here.

play.libsyn.com/embed/episode/…

Direct Download in DRM-free MP3.

If you’d rather read along, here’s the transcript for this week’s episode.

Places to follow the FLOSS Weekly Podcast:

• Spotify
• RSS

Theme music: “Newer Wave” Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 4.0 License

hackaday.com/2025/10/29/floss-…

There’s a part you’ll find in almost every mains powered switch mode power supply that might at first appear to have only one application. An optocoupler sits between the low voltage and the high voltage sides, providing a safely isolated feedback. Can it be used for anything else? [b.kainka] thinks so, and has proved it by making an optocoupler powered LED flasher.

If a part can be made to act as an amplifier with a gain greater than one, then it should also be possible to make it oscillate. We’re reminded of the old joke about it being very easy to make an oscillator except when you want to make one, but in this case when an optocoupler is wired up as an inverting amplifier with appropriate feedback, it will oscillate. In this case the rather large capacitor leading to a longish period, enough to flash an LED.

We like this circuit, combining as it does an unexpected use for a part, and a circuit in which the unusual choice might just be practical. It’s part of our 2025 Component Abuse Challenge, for which you just about still have time to make an entry yourself if you have one.

hackaday.com/2025/10/29/2025-c…

Una interruzione del servizio DNS è stata rilevata il 29 ottobre 2025 da Microsoft, con ripercussioni sull’accesso ai servizi fondamentali come Microsoft Azure e Microsoft 365. Un’ anomalia è stata rilevata alle 21:37 GMT+5:30, provocando ritardi generalizzati in varie applicazioni e bloccando l’accesso degli utenti all’ area amministrativa di Microsoft 365.

Secondo i primi resoconti, difficoltà nella risoluzione DNS stavano ostacolando la corretta gestione del traffico, con effetti negativi sugli endpoint relativi all’autenticazione e ai servizi. La dipendenza da tali piattaforme per servizi di posta elettronica, collaborazione e cloud computing ha portato problemi di indisponibilità dei servizi.

La sospensione ha colpito numerose aree geografiche, suscitando molti reclami sui social media e sui forum tecnologici in Nord America, Europa e Asia. I responsabili della gestione dei tenant di Office 365 si sono trovati di fronte ad errori, mentre gli utenti riscontravano ritardi nelle applicazioni come SharePoint, Teams e Outlook.

I servizi di archiviazione e le macchine virtuali di Azure hanno registrato episodi di indisponibilità intermittente, il che potrebbe comportare l’interruzione dei flussi di lavoro di sviluppo e delle operazioni di elaborazione dati.

Gli specialisti della sicurezza informatica hanno notato che, nonostante l’assenza di segnalazioni di violazioni dei dati, l’evento ha messo in luce le debolezze presenti nelle catene di dipendenza cloud, dove un’anomalia DNS isolata può ripercuotersi in maniera estesa su servizi interconnessi.

La pagina di stato di Microsoft ha confermato che l’ambito includeva i portali di amministrazione e gli strumenti di produttività principali, ma ha risparmiato alcune funzionalità ausiliarie come la sincronizzazione dei file OneDrive in casi isolati.

I team di ingegneri di Microsoft hanno rapidamente identificato la causa principale del problema: un’infrastruttura di rete e di hosting non funzionante. Alle 21:51 GMT+5:30, hanno iniziato a sbloccare i sistemi interessati e a ridistribuire il traffico per mitigare il problema.

Un successivo aggiornamento alle 21:58 ha fornito dettagli su un’analisi più approfondita dello stato di salute dell’infrastruttura, seguito dal reindirizzamento verso percorsi alternativi sani annunciato alle 22:06.

Quindi un problema interno isolato, non un attacco informatico. Gli sforzi per il ripristino mentre scriviamo risultano ancora in corso e Microsoft ha invitato gli utenti a tenere d’occhio la pagina di stato di Azure per ricevere aggiornamenti in tempo reale. L’azienda ha confermato che i lavori di ripristino proseguivano senza sosta.

Negli ultimi giorni abbiamo assistito a una serie di problemi a cui si aggiunge ora questo incidente; i blocchi e i disservizi su AWS (come avvenuto qualche giorno fa) o su Azure (come adesso) causano facilmente problemi a cascata prevedibili e controllabili.

L'articolo Microsoft 365 va giù: un’anomalia DNS paralizza servizi in tutto il mondo proviene da Red Hot Cyber.

È interessante notare che, mentre grandi aziende come Microsoft e Google stanno attivamente aggiungendo funzionalità di intelligenza artificiale ai loro browser, il team di sviluppo di Tor ha scelto di rimuoverle.

@henry, un collaboratore del progetto Tor, ha sottolineato che il team non è riuscito a verificare completamente il processo di addestramento e il comportamento “black box” dei modelli di intelligenza artificiale, quindi ha deciso di eliminare prima i rischi.

Sebbene alcuni utenti potrebbero essere disposti ad “accettare i rischi di Mozilla” per determinate funzionalità, il progetto Tor dà esplicitamente la priorità a non integrare queste funzionalità.

Tra i componenti rimossi figurano la barra laterale della chat basata sull’intelligenza artificiale di Mozilla, introdotta a marzo di quest’anno, e la funzionalità di anteprima del link di riepilogo della pagina, lanciata a maggio.

Inoltre, Tor Browser 15.0a4 ha rimosso anche alcuni elementi del branding di Mozilla/Firefox, come l’icona della volpe, la homepage di Firefox e la nuova barra laterale della cronologia. La barra laterale della cronologia è stata ripristinata alla vecchia interfaccia di Tor Browser versione 14.5 ed è accessibile tramite la scorciatoia Ctrl+H.

Per quanto riguarda la visualizzazione della barra degli indirizzi, Tor Browser non nasconderà più la parte del protocollo dell’URL (come http o https) nella versione desktop, ma questa parte sarà comunque nascosta sulla piattaforma mobile Android.

Altri aggiornamenti minori includono: rendering emoji migliorato sulla piattaforma Linux (ora integrato con il font Noto Color Emoji), l’aggiunta del font Jigmo per ottimizzare la visualizzazione dei caratteri cinesi, giapponesi e coreani e supporto migliorato del tema scuro per l’interfaccia esclusiva del browser Tor

L'articolo Tor Browser dice di NO all’intelligenza artificiale! La sicurezza viene prima di tutto proviene da Red Hot Cyber.

A journalistic and editorial assessment of the presentation by Schoresch Davoodi (Pirate Party) at the Hack the Promise Festival 2025, Basel

Where does freedom end when algorithms decide? How do you hack power without taking it over? These core questions were the focus of this year’s “Hack the Promise 2025.” A highlight: the keynote speech by Schoresch Davoodi, Board Member of the Pirate Party International (PPI), who redefined the attitude of the “Hacker” – as a necessary tool for democratic resilience.

From Radical Upheaval to Precision: The New Hacker Stance

by Schoresch Davoodi

In his presentation, Davoodi spanned the arc from the idealised freedom myths of the turn of the millennium (from “The Matrix” to net culture) to the present, where sovereignty over technology and discourses is fiercely contested.

While the revolutionary dreams of a fresh start and radical upheaval, Davoodi posits that the attitude of the hacker is paramount today:

“Only those who understand systems can safely change them – and preserve freedom within them.”

The core message: True change doesn’t need “arsonists,” but people who understand, analyse, and deliberately improve existing systems, rather than just tearing them down. Anyone serious about political change must endure complexity – and face new challenges with the spirit of the Enlightenment: Sapere aude – dare to use your own understanding.

Between Filter Bubble and Digital Attack

The threats to democracy are more diverse than ever in 2025: Digital violence, disinformation, and targeted manipulation are not just isolated incidents but systematically undermine the foundations of democracy.

Davoodi warned not only against the lure of authoritarian simplifications but also against a “dogma-driven politics” within progressive movements. A critical perspective was directed at the role of NGOs, think tanks, and activist networks:

• The Filter Bubble Effect: Those who conduct debates only through their own “filter bubble” risk narrowing plurality instead of courageously expanding it.
• The Demand: Those who remain critically aware of their own filters protect democratic diversity and self-determination.

The “Inner Hack”: More Than Just Net Policy

How must this hacker ethos become politically concrete? Davoodi outlined a practice that goes beyond mere symbolic politics:

The “inner hack” thus means: enduring complexity, opposing propaganda, and viewing maturity and resilience as central political tools. That is democracy in action.

Conclusion: The Small Hack for Great Freedom

Schoresch Davoodi’s presentation is not a manifesto for upheaval, but an invitation to enlightened further thought. In the face of global uncertainties and hybrid threats, the Pirate Party 2025 is increasingly focusing on resilience, strengthening critical infrastructures, and a democratically legitimised security architecture – expressly without serving authoritarian tendencies.

The future belongs to those who have the courage to work on systems precisely, objectively, and openly – and never lose sight of freedom as a core value.

Key Quote: “The revolutionary dreams of a blank slate; the hacker repairs the existing system with precision and courage.”

In this spirit: Hack the System. At least a little – whenever it is most urgently needed.

Would you like me to summarise this British English article into a short, punchy version suitable for a social media post?

piratetimes.info/hack-the-syst…

The following is a report from PPI´s representative at the United Nations Office of Vienna, Mr. Kay Schroeder, who attended the UNODC Conference on Illegal Finance and Crypto.

Reflections from the 9th Global Conference on Criminal Finance and Crypto – UN Vienna

Yesterday I attended the 9th Global Conference on Criminal Finance and Crypto, hosted at the
United Nations in Vienna with support from UNODC. While no official UN representatives were
present, the event offered a revealing glimpse into how private sector challenges—particularly those
surrounding crypto finance—are increasingly reframed as matters of public concern.
The conference celebrated the growing institutional acceptance of crypto assets, shifting the
narrative from speculative private losses to regulated public affairs. This reframing was not just
semantic—it was strategic. Legal frameworks now position crypto as a legitimate asset class,
despite its origin as replicable code. The symbolic elevation of crypto into the realm of public
policy raises fundamental questions about value, legitimacy, and institutional responsibility.
At its core, blockchain technology is designed to reduce transaction costs. Its native tokens—like
BNB on the Binance Smart Chain—are meant to facilitate efficiency, not store value. Yet the market
treats these tokens as assets, creating artificial scarcity and speculative value.

This contradiction was starkly illustrated during a presentation by Francesco Venditti, who proudly described the
seizure of BNB as a value store, while simultaneously labeling a lesser-known BEP-20 token as a
rug pull. Ironically, the logic of blockchain suggests the opposite: BNB should devalue with
increased use, while any token’s value depends on its legal and economic framing.
The deeper issue lies in the off-chain dominance of crypto transactions—estimated at 80–90%—
which undermines the transparency and decentralization that blockchain promises. Centralized
exchanges (CEXs) and DeFi platforms act as both gatekeepers and service providers, facilitating
flows that often bypass the very technology they claim to represent. This dual role complicates
efforts to combat illicit finance, especially when the same actors who enable laundering also claim
to fight it.

Stablecoins deserve particular scrutiny. Pegged 1:1 to fiat currencies, they are technically simple
tokens maintained off-chain. They are not cryptocurrencies in the traditional sense, but rather
symbolic representations of fiat value. Their presence in blockchain ecosystems injects artificial
stability into systems designed to devalue through scalability. In this sense, stablecoins function as
Trojan horses—vehicles through which the fiat system reasserts control over decentralized
infrastructure.

The economic implications are profound. Blockchain tokens represent a new category of economic
goods—ones that devalue with increased use. This defies conventional market logic, where utility
and demand typically reinforce value. If transaction costs approach zero, and those costs are tied to
the token itself, then the token’s value must also approach zero. Yet institutional actors continue to
frame these tokens as stores of value, creating a performative economy that contradicts its own
technological foundations.

During the conference, I posed a question to the panel of lawmakers and lobbyists exploring
solutions to “illegal finance and crypto”:

“What is your opinion on forbidding stablecoins to remove the artificial valuation of
blockchain tokens, which naturally devalue due to scaling requirements?”

The question remains open. But the conversation is shifting—from retail scams to structural
manipulation, from private speculation to public framing. As crypto continues its institutional
ascent, we must remain vigilant about the symbolic and economic contradictions embedded in its
architecture.”

pp-international.net/2025/10/i…

Eremita in una foresta incantata, per Hannah Jadagu il tempo smette di scorrere mentre scrive un album catartico, arrivato da un altra dimensione per scavarci dentro.

iyezine.com/hannah-jadagu-desc…
@Musica Agorà

Hannah Jadagu - Describe

^{Leonardo Pulcini (In Your Eyes ezine)}

If I mention nuclear reactor accidents, you’d probably think of Three Mile Island, Fukushima, or maybe Chernobyl (or, now, Chornobyl). But there have been others that, for whatever reason, aren’t as well publicized. Did you know there is an International Nuclear Event Scale? Like the Richter scale, but for nuclear events. A zero on the scale is a little oopsie. A seven is like Chernobyl or Fukushima, the only two such events at that scale so far. Three Mile Island and the event you’ll read about in this post were both level five events. That other level five event? The Windscale fire incident in October of 1957.

If you imagine this might have something to do with the Cold War, you are correct. It all started back in the 1940s. The British decided they needed a nuclear bomb project and started their version of the Manhattan Project called “Tube Alloys.” But in 1943, they decided to merge the project with the American program.

The British, rightfully so, saw themselves as co-creators of the first two atomic bombs. However, in post-World War paranoia, the United States shut down all cooperation on atomic secrets with the 1946 McMahon Act.

We Are Not Amused

The British were not amused and knew that to secure a future seat at the world table, it would need to develop its own nuclear capability, so it resurrected Tube Alloys. If you want a detour about the history of Britan’s bomb program, the BBC has a video for you that you can see below.

youtube.com/embed/8WcMm31RbMw?…

Of course, post-war Britain wasn’t exactly flush with cash, so they had to limit their scope a bit. While the Americans had built bombs with both uranium and plutonium, the UK decided to focus on plutonium, which could create a stronger bomb with less material.

Of course, that also means you have to create plutonium, so they built two reactors — or piles, as they were known then. They were both in the same location near Seascale, Cumberland.

Inside a Pile

The Windscale Piles in 1951 (photo from gov.uk website).
The reactors were pretty simple. There was a big block of graphite with channels drilled through it horizontally. You inserted uranium fuel cartridges in one end, pushing the previous cartridge through the block until they fell out the other side into a pool of water.

The cartridges were encased in aluminum and had cooling fins. These things got hot! Immediately, though, practical concerns — that is, budgets — got in the way. Water cooling was a good idea, but there were problems. First, you needed ultra-pure water. Next, you needed to be close to the sea to dump radioactive cooling water, but not too close to any people. Finally, you had to be willing to lose a circle around the site about 60 miles in diameter if the worst happened.

The US facility at Hanford, indeed, had a 30-mile escape road for use if they had to abandon the site. They dumped water into the Columbia River, which, of course, turned out to be a bad idea. The US didn’t mind spending on pure water.

Since the British didn’t like any of those constraints, they decided to go with air cooling using fans and 400-foot-tall chimneys.

Our Heros

Most of us can relate to being on a project where the rush to save money causes problems. A physicist, Terence Price, wondered what would happen if a fuel cartridge split open. For example, one might miss the water pool on the other side of the reactor. There would be a fire and uranium oxide dust blowing out the chimney.

The idea of filters in each chimney was quickly shut down. Since the stacks were almost complete, they’d have to go up top, costing money and causing delays. However, Sir John Cockcroft, in charge of the construction, decided he’d install the filters anyway. The filters became known as Cockcroft’s Follies because they were deemed unnecessary.

So why are these guys the heroes of this story? It isn’t hard to guess.

A Rush to Disaster

The government wanted to quickly produce a bomb before treaties would prohibit them from doing so. That put them on a rush to get H-bombs built by 1958. There was no time to build more reactors, so they decided to add material to the fuel cartridges to produce tritium, including magnesium. The engineers were concerned about flammability, but no one wanted to hear it.

They also decided to make the fins of the cartridges smaller to raise the temperature, which was good for production. This also allowed them to stuff more fuel inside. Engineers again complained. Hotter, more flammable fuel. What could go wrong? When no one would listen, the director, Christopher Hinton, resigned.

The Inevitable

The change in how heat spread through the core was dangerous. But the sensors in place were set for the original patterns, so the increased heat went undetected. Everything seemed fine.

It was known that graphite tends to store some energy from neutron bombardment for later release, which could be catastrophic. The solution was to heat the core to a point where the graphite started to get soft, which would gradually release the potential energy. This was a regular part of operating the reactors. The temperature would spike and then subside. Operations would then proceed as usual.

By 1957, they’d done eight of these release cycles and prepared for a ninth. However, this one didn’t go as planned. Usually, the core would heat evenly. This time, one channel got hot and the rest didn’t. They decided to try the release again. This time it seemed to work.

As the core started to cool as expected, there was an anomaly. One part of the core was rising instead, reaching up to 400C. They sped up the fans and the radiation monitors determined that they had a leak up the chimney.

Memories

Remember the filters? Cockcroft”s Follies? Well, radioactive dust had gone up the chimney before. In fact, it had happened pretty often. As predicted, the fuel would miss the pool and burst.

With the one spot getting hotter, operators assumed a cartridge had split open in the core. They were wrong. The cartridge was on fire. The Windscale reactor was on fire.

Of course, speeding up the fans just made the fire worse. Two men donned protective gear and went to peek at an inspection port near the hot spot. They saw four channels of fuel glowing “bright cherry red”. At that point, the reactor had been on fire for two days. The Reactor Manager suited up and climbed the 80 feet to the top of the reactor building so he could assess the backside of the unit. It was glowing red also.

Fight Fire with ???

The fans only made the fire worse. They tried to push the burning cartridges out with metal poles. They came back melted and radioactive. The reactor was now white hot. They then tried about 25 tonnes of carbon dioxide, but getting it to where it was needed proved to be too difficult, so that effort was ineffective.

By the 11th of October, an estimated 11 tonnes of uranium were burning, along with magnesium in the fuel for tritium production. One thermocouple was reading 3,100C, although that almost had to be a malfunction. Still, it was plenty hot. There was fear that the concrete containment building would collapse from the heat.

You might think water was the answer, and it could have been. But when water hits molten metal, hydrogen gas results, which, of course, is going to explode under those conditions. They decided, though, that they had to try. The manager once again took to the roof and tried to listen for any indication that hydrogen was building up. A dozen firehoses pushed into the core didn’t make any difference.

Sci Fi

If you read science fiction, you probably can guess what did work. Starve the fire for air. The manager, a man named Tuohy, and the fire chief remained and sent everyone else out. If this didn’t work, they were going to have to evacuate the nearby town anyway.

They shut off all cooling and ventilation to the reactor. It worked. The temperature finally started going down, and the firehoses were now having an effect. It took 24 hours of water flow to get things completely cool, and the water discharge was, of course, radioactive.

If you want a historical documentary on the even, here’s one from Spark:

youtube.com/embed/S0DXndsQ0H4?…

Aftermath

The government kept a tight lid on the incident and underreported what had been released. But there was much less radioactive iodine, cesium, plutonium, and polonium release because of the chimney filters. Cockcroft’s Folly had paid off.

While it wasn’t ideal, official estimates are that 240 extra cancer cases were due to the accident. Unofficial estimates are higher, but still comparatively modest. Also, there had been hushed-up releases earlier, so it is probably that the true number due to this one accident is even lower, although if it is your cancer, you probably don’t care much which accident caused it.

Milk from the area was dumped into the sea for a while. Today, the reactor is sealed up, and the site is called Sellafield. It still contains thousands of damaged fuel elements within. The site is largely stable, although the costs of remediating the area have been, and will continue to be staggering.

This isn’t the first nuclear slip-up that could have been avoided by listening to smart people earlier. We’ve talked before about how people tend to overestimate or sensationalize these kinds of disasters. But it still is, of course, something you want to avoid.

Featured image: “HD.15.003” by United States Department of Energy

hackaday.com/2025/10/29/this-r…

Over on YouTube [CuriousMarc] and [TubeTimeUS] team up for a multi-part series E&L MMD-1 Mini-Micro Designer Restoration.

The E&L MMD-1 is a microcomputer trainer and breadboard for the Intel 8080. It’s the first ever single-board computer. What’s more, they mention in the video that E&L actually invented the breadboard with the middle trench for the ICs which is so familiar to us today; their US patent 228,136 was issued in August 1973.

The MMD-1 trainer has support circuits providing control logic, clock, bus drivers, voltage regulator, memory decoder, memory, I/O decoder, keyboard encoder, three 8-bit ports, an octal keyboard, and other support interconnects. They discuss in the video the Intel 1702 which is widely accepted as the first commercially available EPROM, dating back to 1971.

In the first video they repair the trainer then enter a “chasing lights” assembly language program for testing and demonstration purposes. This program was found in 8080 Microcomputer Experiments by Howard Boyet on page 76. Another book mentioned is The Bugbook VI by David Larsen et al.

In the second video they wire in some Hewlett-Packard HP 5082-7300 displays which they use to report on values in memory.

A third episode is promised, so stay tuned for that! If you’re interested in the 8080 you might like to read about its history or even how to implement one in an FPGA!

youtube.com/embed/eCAp3K7yTlQ?…

youtube.com/embed/Sfe18oyRvGk?…

hackaday.com/2025/10/29/restor…

We’ll be honest. If you had told us a few decades ago we’d teach computers to do what we want, it would work some of the time, and you wouldn’t really be able to explain or predict exactly what it was going to do, we’d have thought you were crazy. Why not just get a person? But the dream of AI goes back to the earliest days of computers or even further, if you count Samuel Butler’s letter from 1863 musing on machines evolving into life, a theme he would revisit in the 1872 book Erewhon.

Of course, early real-life AI was nothing like you wanted. Eliza seemed pretty conversational, but you could quickly confuse the program. Hexapawn learned how to play an extremely simplified version of chess, but you could just as easily teach it to lose.

But the real AI work that looked promising was the field of expert systems. Unlike our current AI friends, expert systems were highly predictable. Of course, like any computer program, they could be wrong, but if they were, you could figure out why.

Experts?

As the name implies, expert systems drew from human experts. In theory, a specialized person known as a “knowledge engineer” would work with a human expert to distill his or her knowledge down to an essential form that the computer could handle.

This could range from the simple to the fiendishly complex, and if you think it was hard to do well, you aren’t wrong. Before getting into details, an example will help you follow how it works.

From Simple to Complex

One simple fake AI game is the one where the computer tries to guess an animal you think of. This was a very common Basic game back in the 1970s. At first, the computer would ask a single yes or no question that the programmer put in. For example, it might ask, “Can your animal fly?” If you say yes, the program guesses you are thinking of a bird. If not, it guesses a dog.

Suppose you say it does fly, but you weren’t thinking of a bird. It would ask you what you were thinking of. Perhaps you say, “a bat.” It would then ask you to tell it a question that would distinguish a bat from a bird. You might say, “Does it use sonar?” The computer will remember this, and it builds up a binary tree database from repeated play. It learns how to guess animals. You can play a version of this online and find links to the old source code, too.

Of course, this is terrible. It is easy to populate the database with stupid questions or ones you aren’t sure of. Do ants live in trees? We don’t think of them living in trees, but carpenter ants do. Besides, sometimes you may not know the answer or maybe you aren’t sure.

So let’s look at a real expert system, Mycin. Mycin, from Stanford, took data from doctors and determined what bacteria a patient probably had and what antibiotic would be the optimal treatment. Turns out, most doctors you see get this wrong a lot of the time, so there is a lot of value to giving them tools for the right treatment.

This is really a very specialized animal game where the questions are preprogrammed. Is it gram positive? Is it in a normally sterile site? What’s more is, Mycin used Bayesian math so that you could assign values to how sure you were of an answer, or even if you didn’t know. So, for example, -1 might mean definitely not, +1 means definitely, 0 means I don’t know, and -0.5 means probably not, but maybe. You get the idea. The system ran on a DEC PDP-10 and had about 600 rules.

The system used LISP and could paraphrase rules into English. For example:
(defrule 52
if (site culture is blood)
(gram organism is neg)
(morphology organism is rod)
(burn patient is serious)
then .4
(identity organism is pseudomonas))
Rule 52:
If
1) THE SITE OF THE CULTURE IS BLOOD
2) THE GRAM OF THE ORGANISM IS NEG
3) THE MORPHOLOGY OF THE ORGANISM IS ROD
4) THE BURN OF THE PATIENT IS SERIOUS
Then there is weakly suggestive evidence (0.4) that
1) THE IDENTITY OF THE ORGANISM IS PSEUDOMONAS

In practice, the program did as well as real doctors, even specialists. Of course, it was never used in practice because of ethical concerns and the poor usability of entering data into a timesharing terminal. You can see a 1988 video about Mycin below.

youtube.com/embed/a65uwr_O7mM?…

Under the Covers

Mycin wasn’t the first or only expert system. Perhaps the first was SID. In 1982, SID produced over 90% of the VAX 9000’s CPU design, although many systems before then had dabbled in probabilities and other similar techniques. For example, DENDRAL from the 1960s used rules to interpret mass spectrometry data. XCON started earlier than SID and was DEC’s way of configuring hardware based on rules. There were others, too. Everyone “knew” back then that expert systems were the wave of the future!

Expert systems generally fall into two categories: forward chaining and backward chaining. Mycin was a backward chaining system.

What’s the difference? You can think of each rule as an if statement. Just like the example, Mycin knew that “if the site is in the blood and it is gram negative and…. then….” A forward chaining expert system will try to match up rules until it finds the ones that match.

Of course, you can make some assumptions. So, in the sample, if a hypothetical forward-chaining Mycin asked if the site was the blood and the answer was no, then it was done with rule 52.

However, the real Mycin was backward chaining. It would assume something was true and then set out to prove or disprove it. As it receives more answers, it can see which hypothesis to prioritize and which to discard. As rules become more likely, one will eventually emerge.

If that’s not clear, you can try a college lecture on the topic from 2013, below.

youtube.com/embed/ZhTt-GG7PiQ?…

Of course, in a real system, too, rules may trigger more rules. There were probably as many actual approaches as there were expert systems. Some, like Mycin, were written in LISP. Some in C. Many used Prolog, which has some features aimed at just the kind of things you need for an expert system.

What Happened?

Expert systems are actually very useful for a certain class of problems, and there are still examples of them hanging around (for example, Apache Drools). However, some problems that expert systems tried to solve — like speech recognition — were much better handled by neural networks.

Part of the supposed charm of expert systems is that — like all new technology — it was supposed to mature to the point where management could get rid of those annoying programmers. That really wasn’t the case. (It never is.) The programmers just get new titles as knowledge engineers.

Even NASA got in on the action. They produced CLIPS, allowing expert systems in C, which was available to the public and still is. If you want to try your hand, there is a good book out there.

Meanwhile, you can chat with Eliza if you don’t want to spend time chatting with her more modern cousins.

hackaday.com/2025/10/29/expert…

Per la seconda volta negli ultimi mesi, Google è stata costretta a smentire le notizie di una massiccia violazione dei dati di Gmail. La notizia è stata scatenata dalle segnalazioni di un “hacking di 183 milioni di account” diffuse online, nonostante non vi sia stata alcuna violazione o incidente reale che abbia coinvolto i server di Google.

Come hanno spiegato i rappresentanti dell’azienda, non si tratta di un nuovo attacco, ma piuttosto di vecchi database di login e password raccolti dagli aggressori tramite infostealer e altri attacchi degli ultimi anni.

“Le segnalazioni di una ‘violazione di Gmail che ha interessato milioni di utenti’ sono false. Gmail e i suoi utenti sono protetti in modo affidabile”, hanno dichiarato i rappresentanti di Google. L’azienda ha inoltre sottolineato che la fonte delle voci di una fuga di dati importante era un database contenente i log degli infostealer, nonché credenziali rubate durante attacchi di phishing e altri attacchi.

Il fatto è che questo database è stato recentemente reso pubblico tramite la piattaforma di analisi delle minacce Synthient ed è stato poi aggiunto all’aggregatore di perdite Have I Been Pwned (HIBP).

Il creatore di HIBP, Troy Hunt, ha confermato che il database di Synthient contiene circa 183 milioni di credenziali, inclusi login, password e indirizzi web su cui sono state utilizzate. Secondo Hunt, non si tratta di una singola fuga di dati: queste informazioni sono state raccolte nel corso degli anni da canali Telegram, forum, dark web e altre fonti. Inoltre, questi account non sono correlati a una singola piattaforma, ma a migliaia, se non milioni, di siti web e servizi diversi.

Inoltre, il 91% dei record era già apparso in altre fughe di notizie ed era presente nel database HIBP, mentre solo 16,4 milioni di indirizzi erano nuovi.

I rappresentanti di Synthient hanno confermato che la maggior parte dei dati nel database non è stata ottenuta tramite attività di hacking, ma infettando i sistemi dei singoli utenti con malware. In totale, i ricercatori hanno raccolto 3,5 TB di informazioni (23 miliardi di righe), inclusi indirizzi email, password e indirizzi di siti web esposti in cui sono state utilizzate le credenziali compromesse.

Google sottolinea che l’azienda scopre e utilizza regolarmente tali database per i controlli di sicurezza, aiutando gli utenti a reimpostare le password trapelate e a proteggere nuovamente i propri account.

L’azienda sottolinea inoltre che, anche se Gmail non è stato hackerato, i vecchi nomi utente e password già trapelati potrebbero comunque rappresentare una minaccia. Per mitigare questi rischi, Google consiglia di abilitare l’autenticazione a più fattori o di passare alle passkey, che sono più sicure delle password tradizionali.

Ricordiamo che, nel settembre 2025, Google aveva già smentito le segnalazioni di una massiccia violazione dei dati degli utenti di Gmail. All’epoca, erano emersi resoconti sui media secondo cui Google avrebbe inviato una notifica di massa a tutti gli utenti di Gmail (circa 2,5 miliardi di persone) per chiedere loro di cambiare urgentemente le password e abilitare l’autenticazione a due fattori. I rappresentanti di Google hanno poi negato la veridicità di tale notizia.

L'articolo 183 milioni di account Gmail hackerati! E’ falso: era solo una bufala proviene da Red Hot Cyber.

Nvidia non ha sviluppato un proprio computer quantistico, ma il CEO Jensen Huang scommette che l’azienda avrà un ruolo chiave nel futuro della tecnologia. Nel suo discorso di apertura alla Global Technology Conference (GTC) di Nvidia a Washington, D.C., martedì, Huang ha annunciato NVQLink, una tecnologia di interconnessione che collega i processori quantistici ai supercomputer di intelligenza artificiale di cui hanno bisogno per funzionare efficacemente.

Ha affermato: “NVQLink è la chiave per collegare i supercomputer quantistici e quelli classici”. I processori quantistici rappresentano un modo completamente nuovo di fare calcolo, utilizzando i principi della fisica quantistica per risolvere problemi che gli attuali computer classici non sono in grado di risolvere.

Le loro applicazioni sono vaste, dalla scoperta scientifica alla finanza. Tuttavia, per fornire risultati significativi per aziende e ricercatori, devono essere integrati con computer classici ad alte prestazioni, che eseguono calcoli che non sono in grado di completare e correggono gli errori naturali nelle loro risposte, un processo noto come correzione degli errori.

Tim Costa, General Manager di Ingegneria Industriale e Quantum di NVIDIA, ha affermato che nel settore esiste un consenso generale sulla necessità di questa infrastruttura ibrida che coinvolge processori quantistici (QPU) e chip di intelligenza artificiale come le GPU NVIDIA, in parte perché l’esecuzione di una correzione completa degli errori richiede l’intelligenza artificiale.

Costa ha affermato che alcune aziende hanno già tentato di integrare processori quantistici con supercomputer di intelligenza artificiale, ma queste tecnologie non sono riuscite a fornire la velocità e la scalabilità necessarie per ottenere una correzione degli errori rapida e scalabile. NVIDIA afferma che la sua nuova tecnologia di interconnessione è la prima soluzione a fornire la velocità e la scalabilità necessarie per realizzare la vera promessa del calcolo quantistico su larga scala.

A tal fine, NVIDIA sta collaborando con oltre una dozzina di diverse aziende quantistiche, tra cui IonQ, Quantumuum e Infleqtion, nonché con diversi laboratori nazionali, tra cui i Sandia National Laboratories, l’Oak Ridge National Laboratory e il Fermi Laboratory. Questa tecnologia di interconnessione si basa su un’architettura aperta ed è adatta a diverse modalità quantistiche, tra cui ioni intrappolati, superconduttori e fotoni. Costa ha affermato che questa apertura è cruciale, il che significa che i laboratori nazionali saranno ora in grado di sviluppare supercomputer per utilizzare le capacità quantistiche non appena saranno disponibili.

Costa ha affermato che in futuro “ogni supercomputer utilizzerà processori quantistici per ampliare la gamma di problemi che può elaborare, e ogni processore quantistico si affiderà ai supercomputer per funzionare correttamente”. Quando vedremo le tecnologie quantistiche generare un valore commerciale significativo? Costa di Nvidia ha affermato che qualsiasi risposta potesse dare sarebbe sbagliata.

L'articolo Nvidia lancia NVQLink per il calcolo quantistico proviene da Red Hot Cyber.

Il panorama della sicurezza informatica è stato recentemente scosso dalla scoperta di una vulnerabilità critica di tipo Remote Code Execution (RCE) nel servizio Windows Server Update Services (WSUS) di Microsoft.

Identificata come CVE-2025-59287 e con un punteggio CVSS di 9.8 (Critico), questa falla rappresenta un rischio elevato e immediato per le organizzazioni che utilizzano WSUS per la gestione centralizzata degli aggiornamenti.

La vulnerabilità è particolarmente pericolosa perché consente a un aggressore remoto e non autenticato di eseguire codice arbitrario con privilegi di sistema sui server WSUS interessati.

Dopo il rilascio di una patch di emergenza “out-of-band” da parte di Microsoft il 23 ottobre 2025, necessaria in quanto la patch iniziale di ottobre non aveva risolto completamente il problema, è stata subito osservata una attività di sfruttamento attiva in rete.

L’Agenzia statunitense per la cybersicurezza e la sicurezza delle infrastrutture (CISA) ha aggiunto rapidamente questa vulnerabilità al suo Catalogo delle vulnerabilità sfruttate note (KEV), sottolineando l’urgenza di una risposta immediata da parte degli amministratori di sistema.

Dettagli sul problema

WSUS è uno strumento fondamentale nelle reti aziendali, fungendo da sorgente fidata per la distribuzione delle patch software.

La sua natura di servizio infrastrutturale chiave lo rende un obiettivo ad alto valore, poiché un suo compromesso può fornire una testa di ponte per il movimento laterale e la compromissione diffusa della rete.

La radice del problema risiede in un caso di “deserializzazione non sicura di dati non attendibili” (unsafe deserialization of untrusted data) e rientra tra le cause del RCE (Remote Code Execution) come effetto finale.

Questo difetto tecnico può essere sfruttato in diverse vie d’attacco note:

• Endpoint GetCookie(): un aggressore può inviare una richiesta appositamente elaborata all’endpoint GetCookie(), inducendo il server a deserializzare in modo improprio un oggetto AuthorizationCookie utilizzando il non sicuro BinaryFormatter.
• Servizio ReportingWebService: un percorso alternativo mira al ReportingWebService per innescare una deserializzazione non sicura tramite SoapFormatter.

In entrambi gli scenari, l’aggressore può indurre il sistema ad eseguire codice dannoso con il massimo livello di privilegi: System

La vulnerabilità è specifica per i sistemi su cui è abilitato il ruolo Server WSUS e risultano vulnerabili Microsoft Windows Server 2012, 2012 R2, 2016, 2019, 2022 (inclusa la versione 23H2) e 2025.

Dettagli Tecnici dell’Exploit

A seguito della recente divulgazione pubblica di un Proof-of-Concept (PoC) per l’exploit, abbiamo condotto un test di laboratorio per analizzare il funzionamento e l’impatto potenziale.

Il PoC, reperibile al link: gist.github.com/hawktrace/76b3…

Questo è specificamente progettato per colpire le istanze di Windows Server Update Services (WSUS) esposte pubblicamente sulle porte TCP predefinite 8530 (HTTP) e 8531 (HTTPS).

L’esecuzione del PoC è semplice, occorre avviare lo script indicare il target http/https vulnerabile come argomento.

Questo innesca l’avvio di comandi PowerShell maligni tramite processi figlio e utilizza la seconda modalità di exploit spiegata precedentemetne (ReportingWebService), in questo caso specifico viene aperto il processo calc.exe (calcolatrice di sistema).

I comandi dannosi sono presenti in formato Base64 codificato e vengono eseguiti durante una fase di deserializzazione all’interno del servizio WSUS.

Questo meccanismo di deserializzazione rappresenta il punto cruciale in cui un aggressore può iniettare qualsiasi altro comando per condurre attività di ricognizione o post-sfruttamento.

La sequenza di processi nel test di laboratorio è stata la seguente:

WsusService.exe -> Cmd.exe -> Calc.exe -> win32calc.exe

Qui i processi figli spawnati dai processi legittimi WSUS (wsusservice.exe).

(Nota: in questo specifico PoC, l’esecuzione di calc.exe (Calcolatrice di sistema) funge da prova non distruttiva della corretta esecuzione del codice remoto).

Il comando oltretutto rimane persistente: al riavvio del server o del servizio viene eseguita la RCE precedentemente iniettata. Lo stesso accade quando si avvia la console MMC (Microsoft Management Console) con lo snap-in di WSUS, utilizzato per configurare e monitorare il servizio.

Video Dimostrativo: Il funzionamento completo di questo PoC è visibile nel video disponibile a questo link: youtube.com/watch?v=CH4Ped59SL…

youtube.com/embed/CH4Ped59SLY?…

Punti Chiave di Monitoraggio e Artefatti

La tabella seguente riassume gli artefatti cruciali da esaminare e i relativi criteri di rilevamento per identificare una possibile compromissione da questa CVE:

Qui un esempio del log durante i test.

Il contenuto di SoftwareDistribution.log

E infine anche il log di IIS dove è presente appunto un useragent anomalo.

(questo log è accessibile solo se installato la funzionalità “HTTP Logging” nella sotto-categoria “Web server/Health and Diagnostics del server”)

Superficie di attacco globale

La superficie di attacco associata a questa vulnerabilità è estremamente significativa.

Allo stato attuale, migliaia di istanze WSUS rimangono esposte a Internet a livello globale e sono potenzialmente vulnerabili. Una ricerca condotta su Shodan evidenzia oltre 480.000 risultati a livello mondiale, di cui più di 500 solo in Italia, classificati come servizi aperti in nelle due port di default riconducibili a WSUS.

Raccomandazioni e Mitigazioni

La raccomandazione principale è di implementare immediatamente le patch di sicurezza di emergenza rilasciate da Microsoft.

Per le organizzazioni che non sono in grado di distribuire immediatamente gli aggiornamenti, sono state suggerite da Microsoft le seguenti misure temporanee per mitigare il rischio, da intendersi come soluzioni provvisorie:

1. Disabilitare il ruolo WSUS server: Disabilitare/Rimuovere completamente il ruolo WSUS dal server per eliminare il vettore di attacco. Si noti che ciò interrompe la capacità del server di gestire e distribuire gli aggiornamenti ai sistemi client.
2. Bloccare le porte ad alto rischio: Bloccare tutto il traffico in entrata sulle porte TCP 8530 e 8531 tramite il firewall a livello host. Come per la disabilitazione del ruolo, questa azione impedisce al server di operare.

È fondamentale che le organizzazioni seguano queste indicazioni e si impegnino in attività di threat hunting per rilevare eventuali segni di compromissione o tentativi di sfruttamento pregressi.

L'articolo Tasting the Exploit: HackerHood testa l’Exploit di Microsoft WSUS CVE-2025-59287 proviene da Red Hot Cyber.