Sono stata assente dalla rete per svariati motivi: alcuni dei quali sono la stanchezza e il disorientamento, non per il passaggio da meta al fediverso, ma a livello psicologico.
Ora va meglio, anche se non benissimo.

Piccole ma importanti novità: martedì ho iniziato una formazione (formatrice - animazione di formazione, per adulti) che durerà fino a fine anno (corsi serali), vediamo dove mi porterà.
E lunedì prossimo avrò un colloquio di lavoro, il luogo di lavoro è a 2 km da casa e le condizioni sembrano buone🤞

Geothermal heat is a tantalizing source of energy that’s quite literally right below our feet. At the same time geothermal energy is hard to develop as the Earth’s crust is too thick in most places, limiting this to areas where magma is close enough to the surface and the underground rock permeable enough for water. The Utah FORGE facility is a field site were researchers are developing and testing ways to increase the scope of geothermal energy.

An Enhanced Geothermal System (EGS) is designed to be capable of using geothermal energy where this is normally not feasible through a technique that’s reminiscent of the hydraulic fracturing (‘fracking’) used by the oil and gas industry, but rather than creating more fractures, it instead uses hydro-shearing to prop open existing fractures and thus create the through-flow of water needed to extract geothermal energy.

So far FORGE has reported the successful creation of a geothermal reservoir where before there was none. This facility is located in the Milford valley in southwest Utah, which has some hydrothermal activity at the nearby Roosevelt Hot Springs, but through EGS other parts of this valley and similar areas could conceivably be used for generating electricity and for community heating as well. In a 2024 study by University of Utah scientists, it is described how the Milford valley’s volcanic past has left a large body of magma below a thick barrier of granitic rock that could provide access to geothermal resources with EGS to create the requisite fluid permeability.

FORGE is not the only facility working on EGS, but many other sites around the world having ceased activities after issues ranging from induced seismicity, susceptibility to earthquakes and budget shortages. Much like fracking, EGS is likely to cause earthquakes. Whether EGS can be made economically feasible still remains to be seen.

hackaday.com/2025/03/14/utahs-…

We would be remiss if we didn’t address the X Distributed Denial of Service (DDoS) attack that’s been happening this week. It seems like everyone is is trying to make political hay out of the DDoS, but we’re going to set that aside as much as possible and talk about the technical details. Elon made an early statement that X was down due to a cyberattack, with the source IPs tracing back to “the Ukraine area”.

The latest reporting seems to conclude that this was indeed a DDoS, and a threat group named “Dark Storm” has taken credit for the attack. Dark Storm does not seem to be of Ukrainian origin or affiliation.

We’re going to try to read the tea leaves just a bit, but remember that about the only thing we know for sure is that X was unreachable for many users several times this week. This is completely consistent with the suspected DDoS attack. The quirk of modern DDoS attacks is that the IP addresses on the packets are never trustworthy.

There are two broad tactics used for large-scale DDoS attacks, sometimes used simultaneously. The first is the simple botnet. Computers, routers, servers, and cameras around the world have been infected with malware, and then remote controlled to create massive botnets. Those botnets usually come equipped with a DDoS function, allowing the botnet runner to task all the bots with sending traffic to the DDoS victim IPs. That traffic may be UDP packets with spoofed or legitimate source IPs, or it may be TCP Synchronization requests, with spoofed source IPs.

The other common approach is the reflection or amplification attack. This is where a public server can be manipulated into sending unsolicited traffic to a victim IP. It’s usually DNS, where a short message request can return a much larger response. And because DNS uses UDP, it’s trivial to convince the DNS server to send that larger response to a victim’s address, amplifying the attack.

Put these two techniques together, and you have a botnet sending spoofed requests to servers, that unintentionally send the DDoS traffic on to the target. And suddenly it’s understandable why it’s so difficult to nail down attribution for this sort of attack. It may very well be that a botnet with a heavy Ukrainian presence was involved in the attack, which at the same time doesn’t preclude Dark Storm as the originator. The tea leaves are still murky on this one.

That ESP32 Backdoor

As Maya says, It Really Wasn’t a backdoor. The Bleeping Computer article and Tarlogic press release have both been updated to reflect the reality that this wasn’t really a backdoor. Given that the original research and presentation were in Spanish, we’re inclined to conclude that the “backdoor” claim was partially a translation issue.

The terminology storm set aside, what researchers found really was quite interesting. The source of information was official ESP32 binaries that implement the Bluetooth HCI, the Host Controller Interface. It’s a structured format for talking to a Bluetooth chip. The official HCI has set aside command space for vendor-specific commands. The “backdoor” that was discovered was this set of undocumented vendor-specific commands.

These commands were exposed over the HCI interface, and included low-level control over the ESP32 device. However, for the vast majority of ESP32 use cases, this interface is only available to code already running on the device, and thus isn’t a security boundary violation. To Espressif’s credit, their technical response does highlight the case of using an ESP32 in a hosted mode, where an external processor is issuing HCI commands over something like a serial link. In that very narrow case, the undocumented HCI commands could be considered a backdoor, though still requires compromise of the controlling device first.

All told, it’s not particularly dangerous as a backdoor. It’s a set of undocumented instructions that expose low-level functions, but only from inside the house. I propose a new term for this: a Basementdoor.

The Fake Recruitment Scam

The fake recruitment scam isn’t new to this column, but this is the first time we’ve covered a first-hand account of it. This is the story of [Ron Jansen], a freelance developer with impressive credentials. He got a recruiter’s message, looking to interview him for a web3 related position. Interviews often come with programming tasks, so it wasn’t surprising when this one included instructions to install something from Github using npm and do some simple tasks.

But then, the recruiter and CTO both went silent, and [Ron] suddenly had a bad feeling about that npm install command. Looking through the code, it looked boring, except for the dependency NPM package, process-log. With only 100-ish weekly downloads, this was an obvious place to look for something malicious. It didn’t disappoint, as this library pulled an obfuscated blob of JSON code and executed it during install. The deobfuscated code establishes a websocket connection, and uploads cookies, keychains, and any other interesting config or database files it can find.

Once [Ron] new he had been had, he started the infuriating-yet-necessary process of revoking API keys, rotating passwords, auditing everything, and wiping the affected machine’s drive. The rest of the post is his recommendations for how to avoid falling for this scam yourself. The immediate answer is to run untrusted code in a VM or sandbox. There are tools like Deno that can also help, doing sandboxing by default. Inertia is the challenge, with a major change like that.

Camel CamelCase RCE

Apache Camel is a Java library for doing Enterprise Integration Patterns. AKA, it’s network glue code for a specific use case. It sends data between endpoints, and uses headers to set certain options. One of the important security boundries there is that internal headers shouldn’t be set by outside sources. To accomplish that, those headers are string compared with Camel and org.apache.camel as the starting characters. The problem is that the string comparison is exact, while the header names themselves are not case sensitive. It’s literally a camelCase vulnerability. The result is that all the internal headers are accessible from any client, via this case trickery.

The vulnerability has been fixed in the latest release of Camel. The seriousness of this vulnerability depends on the component being connected to. Akamai researchers provided a sample application, where the headers were used to construct a command. The access to these internal values makes this case an RCE. This ambiguity is why the severity of this vulnerability is disputed.

Bits and Bytes

Researchers at Facebook have identified a flaw in the FreeType font rending library. It’s a integer underflow leading to a buffer overflow. An attacker can specify a very large integer value, and the library will add to that variable during processing. This causes the value to wrap around to a very small value, resulting in a buffer much too small to hold the given data. This vulnerability seems to be under active exploitation.

We don’t normally see problems with a log file leading to exploitation, but that seems to be the situation with the Below daemon. The service runs as root, and sets the logfile to be world readable. Make that logfile a symlink to some important file, and when the service starts, it overwrites the target file’s permissions.

Microsoft’s Patch Tuesday includes a whopping six 0-day exploits getting fixed this month. Several of these are filesystem problems, and at least one is an NTFS vulnerability that can be triggered simply by plugging in a USB drive.

The ruby-saml library had a weird quirk: it used two different XML parsers while doing signature validations. That never seems to go well, and this is not any different. It was possible to pack two different signatures into a single XML document, and the two different parsers would each see the file quite differently. The result was that any valid signature could be hijacked to attest as any other user. Not good. An initial fix has already landed, with a future release dropping one of the XML parsers and doing a general security hardening pass.

hackaday.com/2025/03/14/this-w…

Cisco ha recentemente pubblicato avvisi di sicurezza riguardanti diverse vulnerabilità nel suo software IOS XR, con particolare attenzione alla CVE-2025-20115, una grave falla di corruzione della memoria nell’implementazione della confederazione Border Gateway Protocol (BGP).

In telecomunicazioni e informatica il Border Gateway Protocol (BGP) è un protocollo di routing di tipo EGP usato per connettere tra loro più router che appartengono a sistemi autonomi (Autonomous System, AS) distinti e che vengono chiamati router gateway o router di bordo/confine. È quindi un protocollo di routing inter-AS, nonostante possa essere utilizzato anche tra router appartenenti allo stesso AS (nel qual caso è indicato con il nome di iBGP, Interior Border Gateway Protocol), o tra router connessi tramite un ulteriore AS che li separa (eBGP, External Border Gateway Protocol).

Il bug rilevato su IOS XR

Questa vulnerabilità, con un punteggio CVSS di 8,6, potrebbe consentire ad attaccanti remoti non autenticati di provocare una condizione di negazione del servizio (DoS) sull’infrastruttura di rete colpita. Il problema deriva da un errore di gestione della memoria che si verifica quando un aggiornamento BGP include un attributo AS_CONFED_SEQUENCE contenente 255 o più numeri di sistema autonomo (AS).

Secondo l’avviso di sicurezza pubblicato da Cisco il 12 marzo 2025, un attaccante potrebbe sfruttare questa vulnerabilità inviando aggiornamenti BGP manipolati, provocando un buffer overflow che causa il riavvio del processo BGP e un’interruzione della rete. Il rischio è particolarmente elevato per le organizzazioni che utilizzano IOS XR con la confederazione BGP attiva, comprese le versioni 7.11 e precedenti, 24.1 e precedenti, e da 24.2 a 24.2.20. L’exploit richiede che l’attaccante controlli uno speaker della confederazione BGP all’interno dello stesso sistema autonomo della vittima o che l’attributo AS_CONFED_SEQUENCE superi naturalmente la soglia critica.

Per mitigare il rischio, Cisco ha rilasciato aggiornamenti che risolvono la vulnerabilità nelle versioni 24.2.21, 24.3.1 e 24.4 di IOS XR. Le organizzazioni che non possono aggiornare immediatamente possono applicare una soluzione temporanea, limitando l’attributo AS_CONFED_SEQUENCE a un massimo di 254 numeri AS tramite una policy di routing dedicata. Gli amministratori di rete possono verificare la vulnerabilità dei propri dispositivi eseguendo il comando “show running-config router bgp”: se l’output include “bgp confederation peers”, il dispositivo potrebbe essere esposto al rischio.

Al momento, il Product Security Incident Response Team (PSIRT) di Cisco non ha segnalato attacchi attivi che sfruttano questa vulnerabilità. Tuttavia, le organizzazioni sono invitate ad aggiornare i propri sistemi o ad adottare le contromisure suggerite il prima possibile per ridurre il rischio di interruzioni di servizio e garantire la stabilità della rete.

L'articolo Reti BGP a rischio Crash! Un bug in Cisco IOS XR può causare il down delle reti! proviene da il blog della sicurezza informatica.

Il quarto round del concorso PQC (Post Quantum Cryptography) del National Institute of Standards and Technology (NIST) statunitense ha selezionato l’HQC come meccanismo di incapsulamento secondario delle chiavi (KEM) rispetto al precedente algoritmo post-quantistico ML-KEM (basato su CRYSTALS-Kyber).

L’HQC o “Hamming Quasi-Cyclic” è un KEM basato su codice che utilizza il problema di decodifica della Quasi-Cyclic syndrome, crittograficamente impegnativo, come base e costruito attorno al concetto di codici di correzione degli errori. Il NIST ha dichiarato di aver scelto l’HQC come algoritmo di riserva per ML-KEM, che utilizza un approccio matematico diverso.

ML-KEM è un algoritmo modulare basato su reticolo che è stato selezionato dal NIST nel 2022 e standardizzato nel Federal Information Processing Standard FIPS 203 nell’agosto 2024. Date queste differenze, se ML-KEM si rivela vulnerabile agli attacchi quantistici, l’HQC sarebbe improbabile avere la stessa vulnerabilità e potrebbe essere invece utilizzato.

“Le organizzazioni dovrebbero continuare a migrare i loro sistemi di crittografia agli standard NIST finalizzati nel 2024. Stiamo annunciando la selezione di HQC perché vogliamo avere uno standard di backup che si basa su un approccio matematico diverso rispetto a ML-KEM.” — Ha detto Dustin Moody, matematico presso NIST. Source.

Lo Status Report rilasciato al quarto round del concorso PQC discute i quattro algoritmi finalisti – HQC, BIKE, Classic McEliece e SIKE. Anche se ci sono vantaggi simili a BIKE in quanto potrebbe anche completare ML-KEM sulla base delle sue differenze matematiche, e la sua base in codice quasi-ciclico, il fattore decisivo per il NIST di selezionare l’HQC sopra gli altri algoritmi era la sua stima relativamente stabile e bassa Decryption Failure Rate (DFR) – dove il testo cifrato non può essere decodificato a causa di un errore.

Perché abbiamo bisogno della crittografia post-quantica?

Lo sviluppo sempre più rapido dell’informatica quantistica è una grande conquista del XXI secolo, tuttavia per la comunità della sicurezza informatica comporta un rischio molto elevato. Gran parte della crittografia che utilizziamo oggi potrebbe essere minacciata da un computer quantistico sufficientemente avanzato, che sfrutta alcuni principi fisici per ‘bypassare‘ le ipotesi matematiche che continuano a proteggere i dati dai tentativi di decrittazione dei computer classici.

Post-Quantum Cryptography (PQC) è la crittografia progettata per essere sicura da attacchi quantistici e classici, che possono essere eseguiti su macchine classiche. Man mano che vengono fatte sempre più scoperte con la tecnologia dei computer quantistici, compreso il recente annuncio di Majorana 1 da parte di Microsoft, l’avvento di un computer quantistico crittograficamente rilevante si avvicina.

Per garantire che la nostra vita digitale quotidiana continui ad essere protetta da una forte crittografia, è necessario sviluppare e attuare algoritmi speciali che non siano suscettibili di attacchi quantistici. Il concorso NIST PQC ha finora selezionato 5 algoritmi progettati per funzionare su computer classici, di cui tre già standardizzati lo scorso anno.

Il recente annuncio da parte del NIST della selezione di HQC come meccanismo chiave di incapsulamento post-quantistico segna un altro passo positivo per la sicurezza delle informazioni digitali nel l’era quantistica che si avvicina.

References:

• NIST Status Report 8545: nvlpubs.nist.gov/nistpubs/ir/2…
• NIST Announcement nist.gov/news-events/news/2025…
• HQC Website pqc-hqc.org/

L'articolo Il NIST sceglie il secondo algoritmo Post Quantum di incapsulamento delle chiavi KEM proviene da il blog della sicurezza informatica.

Il gruppo Volt Typhoon ha operato segretamente nei sistemi del Dipartimento di luce e acqua elettrica di Littleton, nel Massachusetts, per quasi un anno. L’attacco informatico faceva parte di un’operazione più ampia che, secondo le autorità statunitensi, è condotta dalla Cina. Lo scopo di tali attacchi è quello di preparare in anticipo un possibile conflitto e, se necessario, danneggiare infrastrutture critiche degli Stati Uniti.

L’FBI e la CISA sono stati i primi a venire a conoscenza della compromissione della rete aziendale. Venerdì pomeriggio, un dirigente della Littleton Electric ha ricevuto una chiamata dall’FBI che lo avvisava di un attacco informatico e, lunedì, agenti e specialisti della sicurezza informatica si sono presentati presso la sede dell’azienda.

Il dipartimento di luce elettrica e acqua di Littleton serve le città di Littleton e Boxborough e fornisce servizi di elettricità e acqua alle città da oltre 100 anni. Tuttavia, negli ultimi anni, l’azienda ha dovuto far fronte a una crescente minaccia di attacchi informatici. Dopo aver identificato la compromissione, gli specialisti di Dragos hanno avviato un’indagine e scoperto che Volt Typhoon era penetrato nelle reti dell’organizzazione già nel febbraio 2023.

Come si è scoperto, Volt Typhoon si è infiltrato nel sistema attraverso vulnerabilità nel firewall FortiGate 300D. Sebbene Fortinet abbia rilasciato una correzione a dicembre 2022, la società di gestione IT LELWD non ha aggiornato il firmware.

Di conseguenza, l’MSP responsabile della gestione della rete è stato licenziato. Entro dicembre 2023, il governo federale aveva installato i suoi sensori sulla rete LELWD e aveva chiesto di lasciare aperta la vulnerabilità per sorvegliare le attività degli hacker. Nonostante il timore che l’attacco potesse ripetersi, l’azienda ha deciso di collaborare con le autorità.

Gli hacker non solo hanno messo piede nei sistemi, ma si sono anche spostati nella rete e hanno rubato dati. Tuttavia, durante l’attacco non è stato compromesso alcun dato personale dei clienti. Grazie alle misure adottate, l’azienda ha modificato la propria architettura di rete, eliminando potenziali vulnerabilità che avrebbero potuto essere sfruttate dagli aggressori.

L’obiettivo di Volt Typhoon non era solo la presenza a lungo termine nel sistema: gli hacker volevano anche raccogliere informazioni sul funzionamento degli impianti di automazione industriale. In particolare, dati sulle procedure operative e sulla topografia della rete elettrica. Tali informazioni possono essere fondamentali se l’attacco non è mirato solo a interrompere le operazioni, ma anche a causare danni fisici all’infrastruttura.

Un rappresentante dell’azienda non sa ancora perché Volt Typhoon abbia scelto LELWD. Potrebbe essere stata parte di un’operazione di intelligence più ampia. “Le nostre sottostazioni e i nostri sistemi di pubblica utilità non sono stati compromessi, ma gli hacker sapevano dove si trovavano i firewall vulnerabili e hanno cercato di aggirarli”, ha affermato il portavoce. Per LELWD l’incidente ha rappresentato una seria lezione di sicurezza informatica.

Nonostante le misure adottate, alcuni dettagli dell’attacco restano top secret a causa delle indagini in corso da parte delle forze dell’ordine statunitensi. Allo stesso tempo, la Cina nega il suo coinvolgimento nell’operazione Volt Typhoon, nonostante la CISA e l’FBI abbiano ripetutamente avvertito che gli hacker stanno cercando di mettere piede nelle reti informatiche delle infrastrutture critiche americane per attacchi successivi.

L'articolo Colpire gli USA Silentemente ed in profondità. Gli hacker cinesi erano nella rete elettrica da un anno proviene da il blog della sicurezza informatica.

Do you like scientific calculators? Don’t bother answering that question, you’re reading Hackaday so we already know the answer. We also know you’re a fan of building things yourself and open source, which makes us fairly sure you’ll be just as interested in the recently announced ClockworkPi PicoCalc as we are.

On the surface, it looks like a chunky scientific calculator, though on further inspection you’ll note it comes equipped with a QWERTY keyboard. But open up the case and what you’ve really got is an elaborate carrier board for the Raspberry Pi Pico. The PicoCalc supports all variants of the microcontroller, but realistically we can’t think of any reason that you wouldn’t just use the latest version.

With the MCU connected, you’ll have access to the PicoCalc’s 320×320 4-inch IPS screen, backlit I2C-connected keyboard, SD card slot, 8 MB PSRAM, and dual PWM speakers. Power is provided by a pair of 18650 cells (which you’ll need to supply on your own), and the board has the necessary circuitry to charge them up over USB-C.

Everything is housed in an injection molded case, but the project page says all the necessary CAD files will be eventually be released under the GPL v3 so you can 3D print or CNC your own enclosure. For now though, the only thing of note that seems to be in the PicoCalc GitHub repository is a PCB schematic.

The software side of things is a little less clear. The page mentions a BASIC interpreter, MP3 playback, and support for various programming languages, but we get the impression that’s just a list of stuff you can run on the Pi Pico. There are a few images that clearly show the PicoCalc actually being used as a calculator however, so there may be an official firmware yet to be revealed.

The PicoCalc kit is on sale now, and will set you back $75 USD — which actually includes a first-generation Pi Pico, on the off chance that you don’t already have a few laying around. We’ve been impressed with the previous offerings from ClockworkPi, so assuming this new kit maintains that same build quality, it seems like a fair enough price.

hackaday.com/2025/03/14/clockw…

And, what's better than ⌊π⌋ great CCE's (Content Creators in Educational, or Circle Constant Enthusiasts) teaming together to celebrate #PiDay?
Well, of course, it's ⌈3.9⌉ amazing guys messing around with sliding blocks on an air table to calculate π=3.9 on #PiDay2025!
😍
youtube.com/watch?v=vlUTlbZT4i…

#MattParker #StandUpMaths @Matt Parker #SteveMould #3Blue1Brown @3blue1brown @Grant Sanderson #HughHunt

I responsabili di Mozilla avvisano gli utenti di Firefox di aggiornare il proprio browser all’ultima versione per evitare potenziali crash e problemi di sicurezza. Il fatto è che uno dei certificati di root sta per scadere.

Il certificato di Mozilla scade domani, 14 marzo 2025. Questo certificato è stato utilizzato per firmare contenuti, tra cui componenti aggiuntivi di vari progetti Mozilla e di Firefox stesso.

Si consiglia agli utenti di aggiornare i propri browser alla versione 128 di Firefox (rilasciata a luglio 2024) o successiva e alla versione ESR 115.13 o successiva per gli utenti ESR (Extended Support Release).

Si noti che il problema riguarda Firefox su tutte le piattaforme, tra cui Windows, Android, Linux e macOS, ad eccezione di iOS, che utilizza un sistema di gestione dei certificati radice indipendente.

“Il certificato root (la risorsa utilizzata per verificare che un componente aggiuntivo sia approvato da Mozilla) scade il 14 marzo, il che significa che gli utenti di Firefox che utilizzano versioni precedenti alla 128 (o ESR 115) non potranno utilizzare i loro componenti aggiuntivi”, ha affermato Mozilla in un post sul blog. “Vogliamo che gli sviluppatori ne siano a conoscenza nel caso in cui alcuni utenti utilizzino versioni precedenti di Firefox che potrebbero essere interessate dal problema.”

Un altro documento di supporto di Mozilla spiega che il mancato aggiornamento di Firefox potrebbe comportare rischi e problemi significativi per gli utenti. Per esempio:

• Le estensioni dannose possono compromettere i dati o la privacy degli utenti aggirando le misure di sicurezza;
• i certificati non attendibili ti consentiranno di visitare siti fraudolenti e non sicuri senza preavviso;
• Gli avvisi sulle password compromesse potrebbero smettere di funzionare, lasciando gli utenti ignari della potenziale minaccia di compromissione dell’account.

Mozilla fa notare che gli utenti delle vecchie versioni di Firefox possono continuare a utilizzare il browser anche dopo la scadenza del certificato, se accettano i possibili rischi. Tuttavia, ciò potrebbe compromettere seriamente le prestazioni e la funzionalità del browser.

“Sebbene sia possibile utilizzare Firefox senza aggiornarlo, potrebbero verificarsi problemi quali la disattivazione delle estensioni, difficoltà con i supporti DRM e altri problemi. Saltare un aggiornamento significherà anche perdersi importanti correzioni di sicurezza e miglioramenti delle prestazioni. Consigliamo vivamente di aggiornare il browser all’ultima versione per evitare questi problemi e garantirne la sicurezza e le prestazioni”, scrivono gli sviluppatori.

L’organizzazione ha creato un thread separato per gli utenti che riscontrano problemi o hanno bisogno di aiuto per aggiornare Firefox.

L'articolo Mozilla avvisa gli utenti: Il certificato scade domani, aggiorna subito! proviene da il blog della sicurezza informatica.

We love unique displays here at Hackaday. If you can figure out how to show information on some weird object, we’re all about it. So when [Julius Curt] wrote in to share his work on the Pasta Analog Display, we were hooked from the subject line.

But in reading his account, it ended up being even better than we hoped for. Because it turns out, getting pasta to behave properly in an electromechanical device is trickier than you might think. Oh sure, as [Julius] points out, those ridges on the side of penne might make them look like gears — but after spending the time and effort to build a particularly slick 3D printed frame to actually use them as such, it turns out they just won’t cooperate. You’d think the pasta makers of the world would have some respect for mechanical tolerances, but unfortunately not.

This version of the pasta display didn’t work, but we love the design.
So if [Julius] couldn’t use the natural shape of the penne to get them to rotate, what was the alternative? First, he switched to the far larger cannelloni. Their increased internal volume, most commonly used to hold spinach and ricotta, has in this case been stuffed with a 3D printed armature. Thus each cannelloni is physically attached to a gear, which means when one of them is rotated by a 28BYJ-48 stepper motor, the rest follow.

All that’s left is to apply some artwork to the pasta (again, easier said than done), and rotate them into position. Depending on how much you can cram onto each cannelloni, the display can be rotated to show several different messages. In the video below, [Julius] shows off three distinct images rendered at the push of a button.

If you get hungry while trying to turn pasta into a workable display medium, you can always cook and eat some of your building materials. Luckily, a couple years ago Barilla released the design for an open source device to help you cook their pasta more efficiently.

youtube.com/embed/mlT0Z5JhcTU?…

hackaday.com/2025/03/14/the-tr…

Have you seen Severance? Chances are good that you have; the TV series has become wildly popular in its second season, to the point where the fandom’s dedication is difficult to distinguish from the in-universe cult of [Kier]. Part of the show’s appeal comes from its overall aesthetic, which is captured in this description of the building of one of the show’s props.

A detailed recap of the show is impossible, but for the uninitiated, a mega-corporation called Lumon has developed a chip that certain workers have implanted in their brains to sever their personalities and memories into work and non-work halves. The working “Innies” have no memory of what their “Outies” do when they aren’t at work, which sounds a lot better than it actually ends up being. It’s as weird as it sounds, and then some.

The prop featured here is the “WoeMeter” from episode seven of season two, used to quantify the amount of woe in a severed worker — told you it was weird. The prop was built by design house [make3] on a short timeline and after seeing only some sketches and rough renders from the production designers, and had to echo the not-quite-midcentury modern look of the whole series. The builders took inspiration from, among other things, a classic Nagra tape recorder, going so far as to harvest its knobs and switches to use in the build. The controls are all functional and laid out in a sensible way, allowing the actors to use the device in a convincing way. For visual feedback, the prop has two servo-operated meters and a string of seven-segment LED displays, all controlled by an ESP-32 mounted to a custom PCB. Adding the Lumon logo to the silkscreen was a nice touch.

The prop maker’s art is fascinating, and the ability to let your imagination run wild while making something that looks good and works for the production has got to be a blast. [make3] really nailed it with this one.

Thanks to [Aaron’s Outie] for the tip.

hackaday.com/2025/03/13/the-my…