If you want read-only memory today, you might be tempted to use flash memory or, if you want old-school, maybe an EPROM. But there was a time when that wasn’t feasible. [Igor Brichkov] shows us how to make a core rope memory using a set of ferrite cores and wire. This was famously used in early UNIVAC computers and the Apollo guidance computer. You can see how it works in the video below.

While rope memory superficially resembles core memory, the principle of operation is different. In core memory, the core’s magnetization is what determines any given bit. For rope memory, the cores are more like a sensing element. A set wire tries to flip the polarity of all cores. An inhibit signal stops that from happening except on the cores you want to read. Finally, a sense wire weaves through the cores and detects a blip when a core changes polarity. The second video, below, is an old MIT video that explains how it works (about 20 minutes in).

Why not just use core memory? Density. These memories could store much more data than a core memory system in the same volume. Of course, you could write to core memory, too, but that’s not always a requirement.

We’ve seen a resurgence of core rope projects lately. Regular old core is fun, too.

youtube.com/embed/cdeHAdR83b8?…

youtube.com/embed/ndvmFlg1WmE?…

hackaday.com/2025/05/14/your-o…

Treat dispensers are old hat around here, but what if kitty doesn’t need the extra calories — and actually needs to drop some pounds? [MethodicalMaker] decided to link the treat dispenser to a cat wheel, and reward kitty for healthy behaviors. The dispenser can be programmed to make the cat run long enough to burn the calories of its treat. Over time, kitty can be trained to run longer between treats to really melt off the pounds.

The wheel itself is an off the shelf model called “One Fast Cat”; apparently these are quite cheap second hand as most cats don’t really see the point in exercise. [MethodicalMaker] glued evenly-spaced magnets along the rim in order to track the rotation with a hall effect sensor. A microcontroller is watching said sensor, and is programmed to release the treats after counting off a set number of revolutions. Control over the running distance and manual treat extrusion is via web portal, but the networking code had difficulty on the Arduino R4 [MethodicalMaker] started with, so he switched to an ESP32 to get it working.

The real interesting part of this project is the physical design of the treat dispenser: it uses a double-auger setup to precisely control treat release. The first auger lives inside a hopper that holds a great many treats, but it tended to over-dispense so [MethodicalMaker] methodically made a second auger that sits beneath the hopper. The handful of treats extruded by the first auger are dispensed individually by the second auger, aided by a photosensor inside the exit chute to count treats. This also lets the machine signal when it needs refilled. For precise control, continuous servos are used to drive the augers. Aside from the electronics, everything is 3D printed; the STLs are on Printables, and the code is on GitHub.

If you don’t have a cat wheel, DIY is an option. If you don’t have a cat, we’ve also highlighted dog treat dispensers. If you don’t have either, check with your local animal shelter; we bet good money there are oodles ready to adopt in your town, and then you’ll have an excuse to enter one of your projects into our ongoing Pet Hacks Contest.

youtube.com/embed/nUOUaUAySG0?…

hackaday.com/2025/05/14/2025-p…

Negli Stati Uniti è emerso un nuovo potenziale rischio per la sicurezza delle infrastrutture energetiche.

Alcuni esperti del settore hanno scoperto dispositivi di comunicazione non documentati all’interno di inverter solari di produzione cinese, componenti fondamentali utilizzati per connettere pannelli solari e turbine eoliche alla rete elettrica. Questi dispositivi non erano elencati nella documentazione ufficiale e potrebbero rappresentare una minaccia se utilizzati per accedere da remoto ai sistemi energetici.

Gli inverter di potenza, prodotti principalmente in Cina, sono utilizzati in tutto il mondo per collegare pannelli solari e turbine eoliche alla rete elettrica. Sono presenti anche in batterie, pompe di calore e caricabatterie per veicoli elettrici.

Gli inverter, infatti, sono progettati per permettere aggiornamenti e manutenzione a distanza, ma negli Stati Uniti le aziende di servizi pubblici installano firewall per bloccare le comunicazioni dirette con server cinesi. Tuttavia, la presenza di apparecchiature di comunicazione non autorizzate – tra cui radio cellulari – aggira potenzialmente questi controlli. Negli ultimi nove mesi, componenti simili sono stati rinvenuti anche in batterie e altri dispositivi provenienti da diversi fornitori cinesi.

Il timore degli esperti è che questi sistemi possano essere utilizzati per interferire con la rete elettrica nazionale, causando malfunzionamenti o blackout mirati. Un precedente caso nel novembre 2024, in cui alcuni inverter sono stati disattivati da remoto dalla Cina, ha rafforzato i sospetti e spinto le autorità statunitensi a intensificare le ispezioni su tutte le tecnologie connesse alla rete.

A livello internazionale, alcuni paesi stanno già adottando misure concrete. La Lituania, ad esempio, ha introdotto una nuova legislazione che vieta l’accesso remoto ai produttori cinesi di inverter nei siti con capacità superiore a 100 kilowatt. La norma si applica alle nuove installazioni dal 1° maggio 2025, e richiede agli impianti esistenti di adeguarsi entro maggio 2026, rafforzando così la protezione della propria infrastruttura energetica.

Questa vicenda sottolinea quanto sia cruciale garantire la sicurezza dei dispositivi collegati alla rete, soprattutto in un contesto di transizione energetica globale sempre più dipendente dalla tecnologia digitale.

La trasparenza nella produzione e nella documentazione tecnica dei componenti elettronici sarà fondamentale per prevenire rischi futuri e tutelare la sovranità tecnologica delle nazioni.

L'articolo Infrastrutture Energetiche Nel Mirino! Gli Inverter Cinesi Sono Controllati Da Remoto proviene da il blog della sicurezza informatica.

Earlier this month we covered the brewing controversy over libogc, the community-developed C library that functions as the backbone for GameCube and Wii homebrew software. Questions about how much of the library was based on leaked information from Nintendo had been circulating for decades, but the more recent accusations that libogc included code from other open source projects without proper attribution brought the debate to a head — ultimately leading Wii Homebrew Channel developer Hector Martin to archive the popular project and use its README as a central point to collect evidence against libogc and its developers.

At the time, most of the claims had to do with code being taken from the Real-Time Executive for Multiprocessor Systems (RTEMS) project. Martin and others in the community had performed their own investigations, and found some striking similarities between the two codebases. A developer familiar with both projects went so far as to say that as much as half the code in libogc was actually lifted from RTEMS and obfuscated so as to appear as original work.

While some of these claims included compelling evidence, they were still nothing more than accusations. For their part, the libogc team denied any wrongdoing. Contributors to the project explained that any resemblance between libogc code and that of either leaked Nintendo libraries or other open source projects was merely superficial, and the unavoidable result of developing for a constrained system such as a game console.

But that all changed on May 6th, when the RTEMS team released an official statement on the subject. It turns out that they had been following the situation for some time, and had conducted their own audit of the libogc code. Their determination was that not only had RTEMS code been used without attribution, but that it appeared at least some code had also been copied verbatim from the Linux kernel — making the license dispute (and its solution) far more complex.

Permissive vs Restrictive

At first glance, this all might seem like something of a non-issue. After all, libogc, RTEMS, and the Linux kernel are all open source projects. Surely, the point of releasing these projects as open source in the first place was to facilitate and even encourage the sharing of source code. In a sense, this could be looked at as the system working as intended.

Indeed, it’s not the reuse of code that’s really the issue here. The problem stems from the licenses by which the respective projects have made their source code available, and more specifically, how well those licenses integrate with each other.

When the complaint was that libogc was using large swaths of code from RTEMS, the path towards compliance was simple as latter project was released under what’s known as a permissive license, namely, the 2-Clause BSD License. As the name implies, permissive licenses such as this give the user broad rights on how they can reuse the code

For example, one could take BSD-licensed code, merge it as-is into a closed source project, and sell the resulting software for profit without violating the license. All the original project asks in return is that you give proper attribution. In this case, that means acknowledging you used code from said project in the documentation, and including a copy of the license.

Returning to libogc, the issue at hand could be resolved with a single commit to the project’s GitHub repository. A simple notice that the project used code from RTEMS and a copy of the BSD license is all it would take to satisfy the requirements. That the libogc developers will not make even such a simple concession in the face of overwhelming evidence that they did indeed reuse code is frankly indefensible; a sentiment expressed in the statement from the RTEMS developers:

RTEMS is open source and this means RTEMS can be copied and used as long as the license conditions are met and copyright is maintained. We are at a loss why there has been removal of license details and copyright and a general disregard to apply appropriate attributions. As a result the RTEMS license and copyright holders reserve their rights in relation to the copying of RTEMS code.

That being said, the revelation that libogc would appear to include code from the Linux kernel complicates matters considerably. Unlike RTEMS, Linux is licensed under the GPL v2 — a license that is not only far more restrictive, but viral in nature.

The Case for Kernel Code

It’s that viral aspect of the license that promises to give libogc the most trouble. If they did indeed use code from the Linux kernel, that would mean there are only two solutions. Either the offending code must be removed, or the entire project will need to be re-licensed under the GPL v2.

For a codebase as old as libogc, changing the license would be a massive undertaking, as every person who’s added code to the project would have to agree to have their individual contribution re-licensed. The libogc repository lists dozens of contributors, and that’s only since project was added to GitHub. As there appears to be no CREDITS file that lists the contributions before the advent of Git, there may be no way to know at this point how many contributors there actually are and what they added.

So the question of whether or not libogc uses Linux code is going to be critical to determining how the project moves forward. The RTEMS statement doesn’t go into great detail about this claim, simply stating that the “spinlock implementation is copied directly from Linux circa 2.4 or 2.6 release series.” Sure enough, when comparing the file spinlock.h file from the latest version of libogc to linux-2.6.0/include/asm-ppc/spinlock.h there are indeed functions which are nearly identical:

That said, this may not be as damning as it seems. To play Devil’s advocate, one could argue that the terse nature of assembly code means that a certain level of similarity is unavoidable between the two implementations. Of course, convention can only get you so far. It’s one thing to independently arrive at the same assembly code, but this explanation becomes harder to believe when you consider the identical variable names and comments.

What’s Next?

As of this writing, the libogc project has not made an official statement on the situation. We reached out to maintainer Dave [WinterMute] Murphy before going to press with this article, but he declined to comment, saying that he first needed to confer with the original developer of the library, Michael [shagkur] Wiedenbauer.

At the same time, our contacts within the RTEMS project have indicated they believe they have sufficient evidence to have libogc removed from GitHub if necessary. However, they’re understandingly hesitant to disrupt the Wii homebrew community over an issue that could ultimately be resolved with a simple discussion. While the potential use of Linux code does add a considerable wrinkle to the overall situation, if the libogc project would at least acknowledge the use of RTEMS code and properly attribute it after all these years, it would at least be a step in the right direction.

We’ll continue to keep an eye on the situation, and bring you updates as we have them. In the meantime, we think the final line of the RTEMS statement nicely summarizes the biggest takeaway from this whole mess:

Our goal now is to provide education on how the behavior engaged in by the devkitPro/libOGC project is a very good example of what not to do.

hackaday.com/2025/05/14/rtems-…

When [Kasyan] was six years old, he saw a RADUGA computer, a Russian unit from the 1990s, and it sparked his imagination. He has one now that is a little beat up, but we feel like he sees it through his six-year-old eyes as a shiny new computer. The computer, which you can see in the video below, was a clone of the Spectrum 48K.

The box is somewhat klunky-looking, and inside is also a bit strange. The power supply is a — for the time — state-of-the-art switching power supply. Since it wasn’t in good shape, he decided to replace it with a more modern supply.

The main board was also not in good shape. A Zilog CPU is on a large PCB with suspicious-looking capacitors. The mechanical keyboard is nothing more than a array of buttons, and wouldn’t excite today’s mechanical key enthusiast.

The computer isn’t working yet. [Kasyan] is looking for someone who has the exact schematic, although he’s found a similar one and identified at least some of the problems on the board.

The USSR did a lot of work with early computing, but we don’t hear as much about it. That’s surprising, as they had a very active home computer scene.

youtube.com/embed/HxvSitPXkg4?…

hackaday.com/2025/05/14/raduga…

I ricercatori hanno individuato una nuova campagna malware che sfrutta gli attacchi ClickFix. Ora gli aggressori prendono di mira anche gli utenti Linux.

Gli attacchi ClickFix sono una forma di ingegneria sociale. Di recente si sono diffuse diverse varianti di tali attacchi. In genere, le vittime vengono attirate su siti truffaldini e indotte con l’inganno a eseguire comandi PowerShell dannosi, infettando di fatto manualmente il loro sistema con un malware. Ad esempio, gli aggressori giustificano la necessità di eseguire determinati comandi risolvendo problemi di visualizzazione del contenuto nel browser oppure chiedendo all’utente di risolvere un CAPTCHA falso.

In genere, tali attacchi prendono di mira i sistemi Windows e inducono la vittima a eseguire uno script di PowerShell, che provoca l’infezione da malware. Tuttavia, in una nuova campagna individuata dai ricercatori di Hunt.io, gli aggressori hanno adattato per la prima volta questa tecnica ai sistemi Linux.

La campagna, che gli esperti attribuiscono al gruppo di hacker pakistano APT36 (noto anche come Transparent Tribe), utilizza un falso sito web del Ministero della Difesa indiano contenente un collegamento a un presunto comunicato stampa ufficiale. Quando i visitatori arrivano su questo sito, la piattaforma rileva il loro sistema operativo e lancia un attacco appropriato.

In questo modo, agli utenti Windows viene mostrata una pagina a schermo intero con un avviso sui diritti limitati per l’utilizzo del contenuto. Facendo clic sul pulsante Continua viene avviato JavaScript che copia il comando dannoso MSHTA negli appunti della vittima, invitandola a incollarlo ed eseguirlo in un terminale Windows.

Questo avvia un loader basato su .NET che si connette all’indirizzo dell’attaccante e l’utente visualizza un file PDF che dovrebbe indurlo in un falso senso di sicurezza e far sembrare la situazione più plausibile.

Se il visitatore utilizza Linux, viene reindirizzato a una pagina con un CAPTCHA falso, dove, premendo il pulsante “Non sono un robot“, un comando shell viene copiato negli appunti. Alla vittima viene quindi chiesto di premere ALT+F2, incollare il comando e premere Invio per eseguirlo.

Il comando avvia il payload mapeal.sh sul sistema dell’utente, il quale, secondo i ricercatori, non esegue ancora alcuna azione dannosa, limitandosi a ricevere in background un’immagine JPEG dal server degli aggressori (trade4wealth[.]in).

Gli esperti ritengono che i membri di APT36 stiano attualmente semplicemente testando l’efficacia di tali attacchi su Linux, poiché è sufficiente sostituire l’immagine con uno script shell per installare il malware ed eseguire altre azioni dannose.

L’adattamento di ClickFix a Linux è un’ulteriore prova dell’efficacia di tali attacchi. Le varianti di ClickFix sono ora disponibili per tutti e tre i principali sistemi operativi desktop. La versione di ClickFix per macOS è stata individuata già nell’ottobre dell’anno scorso.

L'articolo ClickFix Sbarca su Linux! Il Malware ora si installa anche per gli utenti del Pinguino proviene da il blog della sicurezza informatica.

Qualcuno esperto in #legge , magari un #avvocato, mi aiuti a capire, per favore.

Tutto felice e contento ho firmato il referendum di cui si parla, condiviso da alcuni amici, ma sembrerebbe che sia addirittura controproducente una raccolta firme. Che fare, in questo caso? Sarà corretto quello che dice la rete Lenford? (fonte in chiusura del post).

Sono davvero amareggiato e confuso.

"NON ESISTE UN REFERENDUM SUL MATRIMONIO TRA PERSONE DELLO STESSO SESSO
In questi giorni sta circolando online la richiesta di firme per un referendum, che viene descritto dal partito promotore con queste parole: ‘si firma per il referendum sul matrimonio delle coppie same sex’.
Non è così.
Anche se si raccogliessero almeno 500.000 firme entro il 3 agosto 2025 e anche se il referendum venisse giudicato ammissibile (e, quindi, effettivamente proponibile) dalla Corte costituzionale, un esito favorevole nelle urne NON introdurrebbe in Italia il matrimonio per coppie formate da persone dello stesso sesso.
Quel referendum, infatti, vuole mantenere le unioni civili introdotte nel 2016, eliminando le parti che le differenziano dal matrimonio anche rispetto alla filiazione.
La conseguenza di una vittoria dei ‘SÌ’ sarebbe, perciò, questa: le coppie same sex potrebbero continuare soltanto a unirsi civilmente, parificando gli effetti della loro unione a quelli matrimoniali, ma non potrebbero sposarsi.
Questo è un punto che deve essere molto chiaro e che Rete Lenford, nata nel 2007 proprio con la campagna ‘Affermazione civile’ volta a introdurre in Italia il matrimonio per persone dello stesso sesso, ha il dovere di chiarire pubblicamente, a seguito di decine di richieste che ci stanno giungendo nelle ultime ore.
Nei prossimi giorni, e con ampio margine di anticipo rispetto alla scelta che potrà essere fatta sulla firma della proposta referendaria, Rete Lenford lavorerà a una nota illustrativa con uno sguardo ‘bifocale’:
1) tecnico, per un approfondimento sui singoli quesiti e sulla loro dubbia ammissibilità, anche (e soprattutto) per le contraddittorie conseguenze in punto di filiazione, specialmente con riguardo alle coppie conviventi e alla legge sulla procreazione medicalmente assistita (la quale, anche dopo il referendum, continuerebbe a mantenere il requisito esplicito della ‘diversità di sesso’ della coppia richiedente);
2) politico, per le significative implicazioni che questo referendum potrebbe generare sia sul percorso di introduzione del ‘matrimonio same sex’, sia su quello di riconoscimento delle famiglie omogenitoriali.
Naturalmente, e anche al fine di elaborare una posizione condivisa in vista del termine del 3 agosto prossimo, non mancheremo di attivare un confronto con le altre realtà associative, tenute sorprendentemente escluse da questa iniziativa partitica.
Nel frattempo, ci è risultato doveroso prenderci del tempo, ma allo stesso tempo chiarire sin da subito quale sarebbe l’esito del referendum, così da favorire soltanto firme consapevoli da parte di chi, già in questi giorni, decidesse di non aspettare una elaborazione delle realtà LGBT+ e volesse esprimere online la propria posizione."

facebook.com/Rete.Lenford/post…

@Alberto

#lgbt
#LGBTQIA #samesexmarriage #MatrimonioEgualitario

Rete Lenford - Avvocatura per i diritti LGBTI+

NON ESISTE UN REFERENDUM SUL MATRIMONIO TRA PERSONE DELLO STESSO SESSO In questi giorni sta circolando online la richiesta di firme per un referendum, che viene descritto dal partito promotore con...

^{www.facebook.com}

There was a time when version control was an exotic idea. Today, things like Git and a handful of other tools allow developers to easily rewind the clock or work on different versions of the same thing with very little effort. I’m here to encourage you not only to use version control but also to go even a step further, at least for important projects.

My First Job

The QDP-100 with — count ’em — two 8″ floppies (from an ad in Byte magazine)
I remember my first real job back in the early 1980s. We made a particular type of sensor that had a 6805 CPU onboard and, of course, had firmware. We did all the development on physically big CP/M machines with the improbable name of Quasar QDP-100s. No, not that Quasar. We’d generate a hex file, burn an EPROM, test, and eventually, the code would make it out in the field.

Of course, you always have to make changes. You might send a technician out with a tube full of EPROMs or, in an emergency, we’d buy the EPROMs space on a Greyhound bus. Nothing like today.

I was just getting started, and the guy who wrote the code for those sensors wasn’t much older than me. One day, we got a report that something was misbehaving out in the field. I asked him how we knew what version of the code was on the sensor. The blank look I got back worried me.

Seat of the Pants

Version control circa 1981 alongside a 3.5-inch floppy that held much more data
Turns out, he’d burn however many EPROMs were required and then plow forward developing code. We had no idea what code was really running in the field. After we fixed the issue, I asked for and received a new rule. Every time we shipped an EEPROM, it got a version number sticker, and the entire development directory went on an 8″ floppy. The floppy got a write-protect tab and went up on the shelf.

I was young. I realize now that I needed to back those up, too, but it was still better than what we had been doing.

Enter Meta Version Control

Today, it would have been easy to label a commit and, later, check it back out. But there is still a latent problem. Your source code is only part of the equation when you are writing code. There’s also your development environment, including the libraries, the compiler, and anything else that can add to or modify your code. How do you version control that? Then there’s the operating system, which could interact with your code or development tools too.

Maybe it is a call back to my 8″ floppy days, but I have taken to doing serious development in a virtual machine. It doesn’t matter if you use QEMU or VirtualBox or VMWare. Just use it. The reason is simple. When you do a release, you can backup the entire development environment.

When you need to change something five years from now, you might find the debugger no longer runs on your version of the OS. The compiler fixed some bugs that you rely on or added some that you now trip over. But if you are in your comfy five-year-old virtual environment, you won’t care. I’ve had a number of cases where I wish I had done that because my old DOS software won’t run anymore. Switched to Linux? Or NewOS 2100^tm? No problem, as long as it can host a virtual machine.

Can’t decide on which one to use? [How to Simple] has some thoughts in the video below.

youtube.com/embed/pZjvyGMBiOQ?…

How About You?

How about it? Do you or will you virtualize and save? Do you use containers for this sort of thing? Or do you simply have faith that your version-controlled source code is sufficient? Let us know in the comments.

If you think Git is just for software, think again.

hackaday.com/2025/05/14/versio…

L’8 maggio 2025, un attaccante criminale noto con lo pseudonimo xuii ha annunciato la pubblicazione di dati riservati provenienti dal Pakistan Intelligence Bureau (IB), promettendo una versione a pagamento contenente file classificati come “Confidenziali” e “Top Secret”. Questo evento rappresenta una delle più gravi minacce informatiche alla sicurezza nazionale del Pakistan, con potenziali implicazioni anche per la sicurezza nucleare del Paese.

Dettagli dell’Attacco

Secondo quanto riportato da xuii su un noto forum underground, l’attacco ha colpito in modo diretto:

• Il Bureau dell’Intelligence del Pakistan (IB), inclusi:
• L’Intelligence Bureau Division (IBD)
• L’Intelligence Bureau Headquarters (IBHQ)
• L’Inter-Services Intelligence (ISI), con la promessa di future fughe di dati altamente sensibili.

La rete di comunicazione nazionale, provocando – secondo le dichiarazioni dell’attore – un blackout totale delle comunicazioni, con l’interruzione dei segnali mobili e militari.

Motivazioni e Obiettivi

L’attacco sembra avere una duplice finalità:

Economica: monetizzare la vendita di dati riservati tramite una versione a pagamento della fuga di informazioni.

Strategica: destabilizzare le infrastrutture critiche del Pakistan, in particolare quelle legate alla difesa e alla comunicazione.

Impatto sulle Infrastrutture Critiche

L’attacco ha colpito in modo trasversale:

• Settore delle telecomunicazioni: blackout delle torri mobili e dei segnali militari.
• Sistemi di comunicazione militare: compromissione delle reti di comando e controllo.
• Sicurezza nazionale: rischio di esposizione di dati nucleari e operazioni segrete.
• Contenuti della Fuga di Dati

Sebbene i dettagli completi non siano ancora stati divulgati, sono stati pubblicati online diversi file e immagini che sembrano appartenere a personale dell’intelligence pakistana. Le immagini caricate includono nomi, volti e potenzialmente informazioni identificative di agenti e funzionari.

Conclusione

L’attacco informatico rivendicato da xuii rappresenta un’escalation senza precedenti nella guerra cibernetica contro il Pakistan. La possibilità che vengano divulgati dati nucleari o operazioni dell’ISI solleva preoccupazioni a livello globale. È fondamentale che le autorità pakistane rispondano con prontezza, adottando misure di sicurezza rafforzate e collaborando con la comunità internazionale per prevenire ulteriori compromissioni.

Sebbene i rapporti ufficiali tra Pakistan e Stati Uniti non siano attualmente dei migliori, complicati da divergenze strategiche e da un crescente avvicinamento di Islamabad a Mosca e Pechino, fonti diplomatiche suggeriscono che un intervento tecnico e di mediazione da parte di Washington possa aver contribuito a contenere l’escalation. Questo supporto, se confermato, dimostrerebbe come la cooperazione internazionale in ambito cibernetico resti un elemento cruciale per la stabilità globale, anche tra Paesi con relazioni bilaterali complesse.

L'articolo Shock in Pakistan: Un Hacker Criminale ruba dati “Top Secret” dai servizi segreti proviene da il blog della sicurezza informatica.

As the saying goes, modern problems require modern solutions. When the modern problem is that your smart light is being hijacked by the neighbors, [Wjen]’s modern solution is to reverse engineer and replace the mainboard.

The light in question is a Phillips Hue Ambiance, and [Wjen]’s excellently-documented six part series takes us through the process of creating a replacement light driver. It’s a good read, including reverse-engineering the PWM functions to get the lights to dim exactly like stock, and a dive into the Zigbee protocol so his rebuild light could still talk to the Philips Hue hub. The firmware [Wjen] wrote for the ESP32C6 he chose to use for this project is on GitHub, with the PCB in a second repo.

We want to applaud [Wjen] for his excellent documentation and open-sourcing (the firmware and PCB are under GPL v3). Not only do we get enough information to replicate this project perfectly if we so choose, but by writing out his design process, [Wjen] gives everyone reading a good head start in doing something similar with other hardware. Even if you’re scratching your head wondering why a light switch isn’t good enough anymore, you have to appreciate what [Wjen] is offering the community.

We’ve covered domestic brain transplants in the past — which is easier in this sort of light than the close confines of a smart bulb. If you’re still wondering why not just use a light switch, perhaps you’d rather hack the light to run doom instead.

Before you go, can we just take a moment to appreciate how bizarre the world has become that we have a DOOM-capable computer to run fancy light fixture? If you’re using what might have been a decent workstation in days of yore to perform a painfully mundane task, let us know on the tips line.

hackaday.com/2025/05/14/a-brai…