Simple Antenna Makes for Better ESP32-C3 WiFi
We’ve seen tons of projects lately using the ESP32-C3, and for good reason. The microcontroller has a lot to offer, and the current crop of tiny dev boards sporting it make adding a lot of compute power to even the smallest projects dead easy. Not so nice, though, is the poor WiFi performance of some of these boards, which [Peter Neufeld] addresses with this quick and easy antenna.
There are currently a lot of variations of the ESP32-C3 out there, sometimes available for a buck a piece from the usual suspects. Designs vary, but a lot of them seem to sport a CA-C03 ceramic chip antenna at one end of the board to save space. Unfortunately, the lack of free space around the antenna makes for poor RF performance. [Peter]’s solution is a simple antenna made from a 31-mm length of silver wire. One end of the wire is formed into a loop by wrapping it around a 5-mm drill bit and bending it perpendicular to the remaining tail. The loop is then opened up a bit so it can bridge the length of the ceramic chip antenna and then soldered across it. That’s all it takes to vastly improve performance as measured by [Peter]’s custom RSSI logger — anywhere from 6 to 10 dBm better. You don’t even need to remove the OEM antenna.
The video below, by [Circuit Helper], picks up on [Peter]’s work and puts several antenna variants to further testing. He gets similarly dramatic results, with 20 dBm improvement in some cases. He does note that the size of the antenna can be a detriment to a project that needs a really compact MCU and tries coiling up the antenna, with limited success. He also did a little testing to come up with an optimal length of 34 mm for the main element of the antenna.
There seems to be a lot of room for experimentation here. We wonder how mounting the antenna with the loop perpendicular to the board and the main element sticking out lengthwise would work. We’d love to hear about your experiments, so make sure to ping us with your findings.
youtube.com/embed/UHTdhCrSA3g?…
Atomic Clock Trades Receiver for an ESP8266
The advantage of a radio-controlled clock that receives the time signal from WWVB is that you never have to set it again. Whether it’s a little digital job on your desk, or some big analog wall clock that’s hard to access, they’ll all adjust themselves as necessary to keep perfect time. But what if the receiver conks out on you?
Well, you’d still have a clock. But you’d have to set it manually like some kind of Neanderthal. That wasn’t acceptable to [jim11662418], so after he yanked the misbehaving WWVB receiver from his clock, he decided to replace it with an ESP8266 that could connect to the Internet and get the current time via Network Time Protocol (NTP).
This modification was made all the easier by the fact that the WWVB receiver was its own PCB, connected to the clock’s main board by three wires: one for the clock signal, another that gets pulled low when the clock wants to turn on the receiver (usually these clocks only update themselves once a day), and of course, ground. It was simply a matter of connecting the ESP8266 dev board up to the two digital lines and writing some code that would mimic the responses from the original receiver.
If you take a look through the provided source code, a comment explains that the WWVB signal is recreated based on the official documentation from the National Institute of Standards and Technology (NIST) website. There are functions in the code to bang out the 500 ms “one” and 200 ms “zero” bits, and once the microcontroller has picked up the correct time from the Internet, they’re called in quick succession to build the appropriate time signal. As such, this code should work on any clock that has an external WWVB receiver like this, but as always, your mileage may vary.
This is a very clean hack, but if you wanted to pull off something similar without having to gut all the clocks in your house, we’ve seen a WWVB simulator that can broadcast an NTP-backed time signal to anything listening nearby.
Buyer Beware: Cheap Power Strips Hold Hidden Horrors
We’ve got a love-hate relationship with discount tool outlet Harbor Freight: we hate that we love it so much. Apparently, [James Clough] is of much the same opinion, at least now that he’s looked into the quality of their outlet strips and found it somewhat wanting.
The outlet strips in question are Harbor Freight’s four-foot-long, twelve-outlet strips, three of which are visible from where this is being written. [James] has a bunch of them too, but when he noticed an intermittent ground connection while using an outlet tester, he channeled his inner [Big Clive] and tore one of the $20 strips to bits. The problem appears to be poor quality of the contacts within each outlet, which don’t have enough spring pre-load to maintain connection with the ground pin on the plug when it’s wiggled around. Actually, the contacts for the hot and neutral don’t look all that trustworthy either, and the wiring between the outlets is pretty sketchy too. The video below shows the horrors within.
What’s to be done about this state of affairs? That’s up to you, of course. We performed the same test on all our outlets and the ground connections all seemed solid. So maybe [James] just got a bad batch, but he’s still in the market for better-quality strips. That’s going to cost him, though, since similar strips with better outlets are about four times the price of the Harbor Freight units. We did find a similar strip at Home Depot for about twice the price of the HF units, but we can’t vouch for the quality. As always, caveat emptor.
youtube.com/embed/z8YdOG9biKU?…
Thanks to [cliff claven] for the tip.
A Tiny Tape Synth
Afficionados of vintage electric organs will know about the Melotron, an instrument from the 1960s that had pre-recorded sounds on a bank of tape loops. A real Melotron in working order will set you back a bit, but it’s possible to play with the idea using much more attainable hardware. [Decurus] has made a simple tape based synth using a cassette deck.
It uses a loop of cassette tape, and varies the pitch by changing the speed of the cassette motor. There’s an RP2040 and a motor controller, which can take a MIDI signal and use it to drive the motor. We’re sorry to see that there’s no recording of the result, but it’s described as a drone.
Part of this project is a 3D printed tape loop holder to fit a cassette mechanism. We won’t go as far as to call it a cassette in itself, instead it’s a sort of tape loop frame. We can see that it might be an interesting component for other tape loop experimenters, now that cassettes themselves are no longer ubiquitous. This certainly isn’t the first tape pitch synth we’ve seen.
Keebin’ with Kristina: the One Where We Embrace the Jank
Yeah, yeah — not a keyboard. But one keyboard-adjacent topic I’m certainly interested in is that of finding a satisfying mouse. Why settle for ticky micro-switches when you could have full-on thock in both peripherals?
I’ve been using a Logitech Ergo M575 for a couple of years now. As you can see, it’s a trackball with two extra buttons, which come programmed for forward and back. I find this next to useless, so I employed AutoHotKey and changed them to Ctrl+C on the up switch, and Ctrl+V on the down switch.
[Aknup] commented on the previous Keebin’ and brought up MMO mice, which, I didn’t know those things had a name other than maybe ‘multi-button mice’. And yes, there are a few trackball MMOs out there. I’ve got my eye on a couple already.
Does anyone have a trackball MMO? I hate to spend $100+ on something I won’t like. I’m intrigued that the one I found that’s the most attractive is less a thumb trackball and more a two-fingers-at-once kind of situation. That will take some getting used to, but the way my trackball moves sometimes, it could be a really positive change.
Embrace the Jank, Why Don’t You?
[VideoPuzzleheaded884] built this keyboard over a the course of a few evenings for a total cost of around $30 AUD ($18.33 USD as of this writing), as a way to motivate themselves to finally start soldering.
You can tell [VideoPuzzleheaded884] is one of us — they cobbled this Corne mini layout-having keyboard together with stuff on hand, and did a fine job of soldering one of their first projects. Hey, if it works, it works. And the use of all-black wires should be commended.
The microcontroller is an ESP32-C3 [VideoPuzzleheaded884] found in box somewhere, and the switches are Gateron Silvers from an unknown time. All in all, this project was a fun diversion from programming, and this probably won’t be the last keyboard they solder.
The Centerfold: Alas, Poor Yorick; I Knew Thee Cozy Vibes Well
The moon lamp looks great along with the fill light coming in from the right, and I could totally get down with some death metal and WFH with this setup.
Do you rock a sweet set of peripherals on a screamin’ desk pad? Send me a picture along with your handle and all the gory details, and you could be featured here!
Historical Clackers: Oh Maskelyne, Why Can’t You Be True?
What’s a magician to do if they need something to fall back on? Sell typewriters, I suppose. Why else would a father-and-son team of illusionists named John Nevil Maskelyne (Jr. and Sr.) do such a thing?
The Maskelynes’ machine was initially seen at the Paris World’s Fair, which lasted from May to October 1889. Four years later, it finally hit the market.
The main selling point of the Maskelyne was that it offered differential spacing. Most typewriters output monospaced text — the skinny ‘i’ takes up the same width on the page as the ‘w’ does. On the Maskelyne, each character takes up a different amount of horizontal space. This makes for a nicer-looking document overall.
By 1897, the writing was on the wall. Maskelynes under heavy usage were falling apart. They were not built to withstand the vibration that typewriters must endure. As a result, things would go awry — maybe the escapement clutch no longer moved far enough, or went too far, or the bars needed to make differential spacing possible clashed together.
By the third model of Maskelyne, they did away with differential spacing. But the investors were unhappy, and by 1899, the Maskelyne Typewriter concern did a disappearing act.
ICYMI: Stop Me If You Saw This Keyboard
We’re embracing the jank this week, remember? And the end result of [nomolk]’s labor? Not janky at all.
This labor of love took almost three weeks, between rewiring all the broken connections and testing the wiring. [nomolk] tried it out and found it wasn’t working as expected, with some keys not registering, and other keys registering two characters.
Once it was working, [nomolk] had a fine mess of all-black wires (!) to deal with. Between the zip ties and the plastic spiral wire wrap thingy, the beast was eventually tamed. That Spacebar would drive me crazy, though.
Got a hot tip that has like, anything to do with keyboards? Help me out by sending in a link or two. Don’t want all the Hackaday scribes to see it? Feel free to email me directly.
Fiber Laser Gives DIY PCBs a Professional Finish
While low-cost professional PCB fabrication has largely supplanted making circuit boards at home, there’s still something to be said for being able to go from design to prototype in an afternoon. Luckily we aren’t limited to the old toner transfer trick for DIY boards these days, as CNC routers and powerful lasers can be used to etch boards quickly and accurately.
But there’s still a problem — those methods leave you with a board that has exposed traces. That might work in a pinch for a one-off, but such boards are prone to shorts, and frankly just don’t look very good. Which is why [Mikey Sklar] has been experimenting with applying both a soldermask and silkscreen to his homemade boards.
Since the board doesn’t need to be moved between operations, you don’t have to worry about the registration being off. The end result really does look quite nice, with the silkscreen especially popping visually a lot more than we would have assumed.
We’ve previously covered how [Mikey] uses his CNC router and fiber laser to cut out and etch the boards, so this latest installment brings the whole thing full circle. The equipment you’ll need to follow along at home isn’t cheap, but we can’t argue with the final results.
youtube.com/embed/RxKP0Fk902g?…
La SIAE prende la sua Rivincita! I Criminali Informatici di Everest sono stati Hackerati
Chi si occupa di sicurezza informatica ricorderà bene l’attacco del gennaio 2022 contro la SIAE, la Società Italiana degli Autori ed Editori. All’epoca, il colpo fece molto scalpore: milioni di dati personali di artisti e iscritti vennero rubati e pubblicati sul dark web.
Responsabile di quell’attacco fu la cyber gang Everest, un gruppo di criminali informatici specializzati in estorsioni tramite ransomware. In quel frangente riuscimmo anche a intervistare alcuni membri della gang, raccogliendo dettagli sulle loro operazioni, la loro filosofia e, in parte, la loro arroganza nel raccontare quanto fosse “semplice” colpire realtà istituzionali.
Oggi, a distanza di oltre tre anni, la situazione si è capovolta. IlData Leak Site della gang Everest ha subito una battuta di arresto nel fine settimana. Qualcuno — probabilmente altri hacker o forse forze di polizia sotto copertura — ha violato il portale utilizzato dal gruppo per pubblicare i dati rubati alle loro vittime, lasciandolo irraggiungibile e sostituendolo con contenuti modificati.
La soddisfazione di tutte le vittime
C’è una certa ironia nel vedere un gruppo di criminali informatici — che per anni ha terrorizzato aziende, enti pubblici e privati cittadini — diventare vittima delle stesse tecniche di cui si serviva.
La SIAE, che nel 2022 aveva subito pesanti danni sia in termini economici sia di immagine, può oggi concedersi una piccola soddisfazione morale: gli hacker che l’avevano umiliata, ora si trovano a loro volta esposti e vulnerabili.
Il concetto di karma digitale si manifesta perfettamente in casi come questo. Everest, come molte gang ransomware, aveva costruito il proprio potere sulla paura: chi non pagava il riscatto veniva minacciato con la pubblicazione di documenti riservati.
L’attacco all’infrastruttura di Everest avviene in un contesto di mutevoli tendenze globali del ransomware. Mentre gli attacchi ransomware ed estorsivi sono aumentati in generale, recenti report indicano che i pagamenti alle vittime sono diminuiti in modo significativo nel corso del 2024. Questo declino è attribuito alle aziende che adottano strategie di backup più efficaci e si rifiutano di negoziare con gli aggressori.
Anche le forze dell’ordine hanno intensificato gli sforzi contro i gruppi ransomware, riuscendo negli ultimi mesi a interrompere le operazioni di importanti attori come LockBit e Radar. Va anche detto che, negli ultimi anni, le autorità internazionali hanno intensificato la loro lotta contro il cybercrime organizzato. Operazioni come quella contro Emotet, Conti e LockBit dimostrano che nessuno, nemmeno i criminali più sofisticati, può sentirsi al sicuro per sempre.
Un segnale al mondo del cybercrime
L’hack subito da Everest manda un messaggio chiaro a tutto l’ecosistema del ransomware: il crimine informatico non è immune alla vulnerabilità e che si domanda se utilizzare il ransomware possa essere controproducente nelle operazioni.
Anche i gruppi più temuti possono crollare se sottovalutano la loro sicurezza o se si trovano a fronteggiare avversari decisi quanto loro. Per chi lavora ogni giorno per proteggere dati e infrastrutture, è un raro momento di rivincita.
Non sappiamo ancora chi ci sia dietro l’attacco al sito di Everest. Potrebbe essere un’azione isolata di hacktivisti, una vendetta da parte di ex membri, o parte di un’operazione più ampia guidata da forze di intelligence. Qualunque sia la mano che ha colpito, resta il gusto amaro — per Everest — di subire lo stesso destino che hanno inflitto a tanti.
L'articolo La SIAE prende la sua Rivincita! I Criminali Informatici di Everest sono stati Hackerati proviene da il blog della sicurezza informatica.
Which Browser Should I Use In 2025?
Over the history of the Web, we have seen several major shifts in browsing software. If you’re old enough to have used NCSA Mosaic or any of the other early browsers, you probably welcomed the arrival of Netscape Navigator, and rued its decline in the face of Internet Explorer. As Mozilla and then Firefox rose from Netscape’s corpse the domination by Microsoft seemed inevitable, but then along came Safari and then Chrome. For a glorious while there was genuine competition between browser heavyweights, but over the last decade we’ve arrived at a point where Chrome and its associated Google domination is the only game in town. Other players are small, and the people behind Firefox seem hell-bent on fleeing to the Dark Side, so where should we turn? Is there a privacy-centric open source browser that follows web standards and doesn’t come with any unfortunate baggage in the room? It’s time to find out.
It’s All In The Engine
If you look at the breadth of standards which a modern web browser has to support, it’s clear that writing a web browser is a Herculean task. Many browsers take the route of not trying to implement everything, for example minimalist browsers such as Dillo or NetSurf concentrate only on rendering web pages. For the purposes of this piece we’re looking at full-fat browsers capable of being a daily driver though, and for that a browser needs some very capable software. Many development teams are not capable of writing such a browser engine, and thus use one developed for another browser. Despite there being many names on the table then, peering under the hood there are surprisingly few options. The Apple Webkit and Google Blink family of browsers dominate, followed by Mozilla Gecko and its Goanna fork, and then by promising bit-part players such as Servo, or the Ladybird browser’s LibWeb. Having so much of the web’s browser software dominated by Apple and Google is not an ideal situation, but it’s where we find ourselves.
So when choosing a browser, the first thing we look at is its engine. Whose ecosystem are we becoming part of, and does that have any effect on us? Within reason all modern full-featured browser engines render websites the same, so there should be little to choose from in terms of the websites themselves.
Having considered the browser engine, next up are whatever the developer uses to differentiate themselves. It’s suprisingly straightforward to construct a bare-bones web browser on top of WebKit, so to stand out each browser has a unique selling point. Is it privacy you’re after, ad blocking, or just following a UI path abandoned by a previous browser? And perhaps most importantly, are you simply departing a problematic developer for one even shadier? It’s worth doing your homework, and not being afraid to try multiple browsers before you find your home.
So Where Did Hackaday Land?
Over the course of writing for Hackaday it’s inevitable that a bunch of different browsers will find their way on to my bench. Some of them like Ladybird or Servo I would love the chance to use as my daily driver, but they simply aren’t mature enough for my needs. Others such as Brave have too much of a whiff of controversy around them for someone seeking a quiet life of open-source obscurity. As I write this I have a preposterous number of browsers installed on my machine, and if there’s one thing which the experience has taught me it’s that they are much more the same than I expected. In three decades our expectation of a browser has homogenised to the extent that I’m hard pressed to tell between them. How do I pick one, without blindly throwing a dart at a corkboard covered in browser logos?
In the end, I looked for two candidates, one each from the Firefox and Apple/Google orbits. I tried them all, and settled on LibreWolf from the former, and Vivaldi from the latter. LibreWolf because it’s done a fine job of making Firefox without it being Firefox, and Vivaldi because its influence from the early Opera versions gave it a tiny bit of individuality missing in the others. I set up both with my usual Hackaday bookmarks, tabs, and shortcuts, changed the search engine to the EU-based Qwant. I’m ready to go, with a bit more control over how my data is shared with the world once more.
A refugee from the early Web writes…
It’s a fairly regular occurrence, that I will Do a Linux Thing in my hackerspace, only to have one of my younger friends point out a much newer and better tool than the one I know, which I probably learned to use some time in the mid-1990s. I’ve fond looking at web browsers to be in some respects a similar experience even if the browsers are much closer to each other than I expected, because for a couple of decades now I’ve been a Firefox user simply because Firefox was the plucky upstart open-source browser. Mozilla’s previous attempts to take Netscape 6 and make it the only piece of Internet software you needed were horribly bloated, and Firefox, or “Phoenix” as it launched, was an easy choice. Just as my operating system journey taught me about software complacency a couple of years ago, so I’ve now had the same awakening in the browser. The Web will never look the same again.
The digital side of the trade war
WELCOME BACK, THIS IS DIGITAL POLITICS. I'm Mark Scott, and I've returned to my desk after a blissful week of vacation. For those in Brussels, I'll be in town on April 29-30, May 6-7 and May 14-15 if anyone is around — drop me a line on digitalpolitcs@protonmail.com
— A global trade war is heating up. Technology will inevitably get sucked into the chaos. But don't expect digital services to play a big role, at least not at first.
— US President Donald Trump extended the sale/ban of TikTok's American operations for another 75 days. That doesn't solve any of the underlying problems.
— How different generations consume (online) media is becoming more divided, leaving us with little, if any, common culture upon which to rely.
Let's get started:
Why USB-C Splitters Can Cause Magic Smoke Release
Using USB for powering devices is wonderful, as it frees us from a tangle of incompatible barrel & TRS connectors, not to mention a veritable gaggle of proprietary power connectors. The unfortunate side-effect of this is that the obvious thing to do with power connectors is to introduce splitters, which can backfire horribly, especially since USB-C and USB Power Delivery (USB-PD) were introduced. The [Quiescent Current] channel on YouTube recently went over the ways in which these handy gadgets can literally turn your USB-powered devices into a smoldering pile of ashes.
Much like Qualcomm’s Quick Charge protocols, USB-PD negotiates higher voltages with the power supply, after which this same voltage will be provided to any device that’s tapped into the power supply lines of the USB connector. Since USB-C has now also taken over duties like analog audio jacks, this has increased the demand for splitters, but these introduce many risks. Unless you know how these splitters are wired inside, your spiffy smartphone may happily negotiate 20V that will subsequently fry a USB-powered speaker that was charging off the same splitter.
In the video only a resistor and LED were sacrificed to make the point, but in a real life scenario the damage probably would be significantly more expensive.
youtube.com/embed/lvnoz5uaTwE?…
Cinque Microchip per Tornare a Vivere: La Storia di Keith Thomas e il Futuro della Neurotecnologia
Un team di ricercatori del Feinstein Institute for Medical Research di New York ha compiuto notevoli progressi nella creazione di sistemi di interazione cervello-macchina. Da anni gli esperti lavorano per imparare a leggere l’attività cerebrale dei pazienti paralizzati e utilizzare tali dati per riprendere il controllo del loro corpo. Tuttavia, il controllo del movimento da solo risolve solo metà del problema: senza feedback tattile, anche azioni semplici come prendere una tazza diventano praticamente impossibili da eseguire.
Il vicepresidente per la ricerca avanzata presso l’istituto Feinstein Institutes for Medical Research Chad Bouton e i suoi colleghi creano interfacce cervello-computer da diversi anni. Nel 2015 la squadra presentato il sistema di “bypass neurale”. Un chip dotato di una serie di elettrodi è stato impiantato nella corteccia motoria del paziente. Il sensore registra gli impulsi nervosi e un modello di intelligenza artificiale appositamente addestrato li decodifica trasformandoli in intenzioni di eseguire un movimento particolare. Grazie ai segnali elettrici, un uomo paralizzato poteva muovere il braccio semplicemente pensandoci.
Negli ultimi dieci anni la tecnologia si è evoluta notevolmente. L’ultimo sviluppo è chiamato “doppio bypass neurale“. Oltre a leggere i segnali cerebrali, ora stimola anche le aree responsabili del tatto. Per realizzare il progetto, gli specialisti hanno impiantato cinque microchip nel cervello del paziente Keith Thomas, che aveva perso la mobilità nella parte inferiore del torace a seguito di un infortunio durante un’immersione. Sono stati posizionati due array di elettrodi nella corteccia motoria; l’aumento del numero di sensori ha consentito un’analisi più accurata dei movimenti pianificati. Altri tre chip sono stati installati nell’area somatosensoriale, che elabora le sensazioni tattili. Il numero totale degli elettrodi ha raggiunto quota 224.
L’intelligenza artificiale è stata addestrata per trasformare i segnali cerebrali di Thomas in comandi di controllo. Le informazioni provenienti dalla corteccia motoria vengono decodificate dal sistema e trasmesse a una matrice di elettrodi fissati al collo, che stimola il midollo spinale. Parallelamente, agiscono gli elettrodi sull’avambraccio, attivando i muscoli che controllano la mano.
I risultati hanno superato le aspettative. Se all’inizio Thomas riusciva a malapena a sollevare il braccio sopra il bracciolo della sedia a rotelle, dopo aver collegato la stimolazione del midollo spinale tramite elettrodi cervicali, la sua forza muscolare è aumentata in modo significativo. Ora il paziente è in grado di raggiungere il proprio viso in modo autonomo.
Un ruolo particolare lo svolgono i sensori miniaturizzati sulle dita e sui palmi delle mani: trasmettono i dati relativi alla pressione e al tatto al computer, che attiva le aree corrispondenti della corteccia somatosensoriale. Il feedback ripristinato ha permesso al paziente non solo di percepire il tatto, ma anche di utilizzare queste informazioni nell’esecuzione di azioni precise. Ora Thomas può raccogliere i gusci d’uovo vuoti senza danneggiarne la fragile struttura.
Il sistema consente al paziente di sollevare la tazza e di bere da essa, guidato solo dall’intenzione mentale. Sorprendentemente, anche senza essere connesso all’interfaccia neurale, Thomas conserva la sensibilità nell’avambraccio e nel polso. Il meccanismo fisiologico di questo fenomeno rimane un mistero: forse, grazie alla neuroplasticità del cervello, si formano nuove connessioni neurali.
Bouton cita esperimenti sugli animali in cui la stimolazione elettrica promuoveva la crescita dei neuroni. Tuttavia, nel caso degli esseri umani, i miglioramenti potrebbero essere associati anche al rafforzamento delle connessioni superstiti nel sito della lesione del midollo spinale.
L'articolo Cinque Microchip per Tornare a Vivere: La Storia di Keith Thomas e il Futuro della Neurotecnologia proviene da il blog della sicurezza informatica.
How ToddyCat tried to hide behind AV software
To hide their activity in infected systems, APT groups resort to various techniques to bypass defenses. Most of these techniques are well known and detectable by both EPP solutions and EDR threat-monitoring and response tools. For example, to hide their activity in Windows systems, cybercriminals can use kernel-level rootkits, in particular malicious drivers. However, in the latest versions of Windows, kernel-mode drivers are loaded only if digitally signed by Microsoft. Attackers get round this protection mechanism by using legitimate drivers that have the right signature, but contain vulnerable functions that allow malicious actions in the context of the kernel. Monitoring tools track the installation of such drivers and check applications that perform it. But what if a security solution performs unsafe activity? Such software enjoys the trust of monitoring tools and doesn’t raise suspicions.
And that’s precisely what ToddyCat attackers exploited by running their tool in the context of a security solution.
Detection
In early 2024, while investigating ToddyCat-related incidents, we detected a suspicious file named
version.dll in the temp directory on multiple devices.
This 64-bit DLL, written in C++, turned out to be a complex tool called TCESB. Previously unseen in ToddyCat attacks, it is designed to stealthily execute payloads in circumvention of protection and monitoring tools installed on the device.
Kaspersky products detect this tool as
Trojan.Win64.ToddyCat.a, Trojan.Win64.ToddyCat.b.
Loading the tool
DLL proxying
Static analysis of the DLL library showed that all functions exported by it import functions with the same names from the system file
version.dll (Version Checking and File Installation Libraries).
List of functions exported by TCESB
This indicates that the attackers use a DLL-proxying technique (Hijack Execution Flow, T1574) to run the malicious code. By means of this technique, a malicious DLL exports all functions of a legitimate one, but instead of implementing them, redirects calls to these functions to the original DLL. This way, an application that loads the malicious library will continue to work as normal, with the malicious code running in the context of this application in the background.
Schematic of DLL proxying
However, this is not enough to launch malware. For a malicious DLL to be able to take control, the application that loads it must contain insecure code. Such code searches for loaded dynamic library images in folders where they should not be located. If one of these folders contains a malicious library, the vulnerable application will load it instead of the legitimate one. Microsoft has an official advisory on preventing unsafe DLL loading.
CVE-2024-11859 vulnerability in ESET Command line scanner
It took us a while to find the file that loads the TCESB tool. We studied the system directories on devices where the malicious DLLs were found. On one of these, in the same folder as TCESB, there was an extensionless executable file named
ecls. We believe that the operator, when transferring files to the device, made a mistake in the filename and moved two copies of it. After performing malicious activity, the file with the extension was deleted, while the other one remained in the system. This file turned out to be a component of ESET’s EPP solution – a scanner launched from the command line (ESET Command line scanner). Dynamic analysis showed that the scanner insecurely loads the system library version.dll, first checking for the file in the current directory, then searching for it in the system directories. This can result in a malicious DLL library being loaded, which constitutes a vulnerability. We compiled a report with a detailed description of it, and sent it to ESET as part of the Coordinated Vulnerability Disclosure process. ESET registered the CVE-2024-11859 vulnerability, then on January 21, 2025 released an update for the ecls file patching the security issue. On April 4, information about this vulnerability appeared in an ESET security advisory.
To analyze TCESB, we ran it in a virtual environment. In the address space of the ESET Command-line scanner process, we can see two
version.dll files. One is the system library, the other is the DLL of the TCESB tool.
Malicious and legitimate libraries in the memory of the ecls.exe process
Basic functionality
To determine the main functions of the malicious tool, we examined the strings located in its DLL.
Snippet of the list of strings that TCESB contains
The strings are not obfuscated. The search shows that most of them belong to the open-source malicious tool EDRSandBlast, designed to bypass security solutions. Kaspersky solutions detect it with the verdict
HEUR:HackTool.Win64.EDRSandblast.a. ToddyCat created the TCESB DLL on its basis, modifying the original code to extend the malware’s functionality. The resulting tool’s capabilities include modifying operating system kernel structures to disable notification routines, for example, about a process creation event in the system or a load event.
Searching for addresses in the kernel memory
To find the structures in the kernel memory needed to disable notification routines, TCESB determines the version of the Windows kernel in the context of which it is running. To do this, it uses the
GetNtoskrnlVersion() function.
Function for getting the Windows kernel version implemented in TCESB
Next, to get information about the memory offsets of the structures corresponding to the operating system kernel version, TCESB uses one of two data sources: a CSV or PDB file.
First, the tool checks the CSV file contained in its own resources section. Stored there in table form is information about several popular kernel versions and their corresponding offsets.
TCESB searches this file line by line for a match with the previously obtained version of the current Windows kernel.
Snippet of the function for getting and reading a CSV file from TCESB resources
We studied the CSV file in the EDRSandBlast repository and its change history. The contents of the TCESB CSV fully match the CSV data in the EDRSandBlast version of August 13, 2022, while the original malware commit of October 6, 2023 adds lines that are missing in the TCESB resource. This indicates a time period during which the creators of TCESB used the EDRSandBlast code.
If the CSV file does not contain data on structures corresponding to the required kernel version, TCESB reads their addresses from the PDB file. To get it, the malware accesses the file C:\Windows\System32\ntoskrnl.exe, which contains information about the kernel file version, and inserts the data from this file into the following template, generating a URL:
msdl.microsoft.com/download/sy…
This is the address of Microsoft debug information server, where TCESB sends a GET request to download the PDB file. The received file is saved in the current TCESB directory, and data on the offsets of the required kernel memory structures are read from it.
Vulnerable driver
To modify the kernel structures that store callbacks used to notify applications of system events, TCESB deploys the Bring Your Own Vulnerable Driver (BYOVD) technique (Exploitation for Defense Evasion, T1211). It does this by installing a vulnerable driver in the system through the Device Manager interface, using an INF file with installation information.
Snippet of decompiled code for installing the TCESB driver
TCESB uses the Dell DBUtilDrv2.sys driver, which contains the CVE-2021-36276 vulnerability. This is a utility driver used to update PC drivers, BIOS and firmware.
Launching the payload
Once the vulnerable driver is installed in the system, TCESB runs a loop in which it checks every two seconds for the presence of a payload file with a specific name in the current directory – the payload may not be present at the time of launching the tool. Presumably, this is to allow the operator to verify that the tool was run without errors, so that the payload file can be moved without risk of detection. As soon as the file appears in the path being checked, it is passed to the decryption function.
Snippet of decompiled TCESB code
The tool creates its own log file for recording all stages of execution in detail.
Example of log file contents
We studied two samples of the TCESB tool. Although we were unable to obtain the payload files, our research shows that they have different names (
kesp and ecore) and both are extensionless.
Our analysis of the tool code found that the data in the payload file is encrypted using AES-128.
Snippet of code for determining the encryption algorithm
The decryption key is in the first 32 bytes of the payload file, followed by the encrypted data block. Below is a snippet of code for reading the key:
Snippet of code for reading the key from the payload file
The key decrypts the data block:
Snippet of code for reading and decrypting the payload file
The read data is placed in memory and executed.
Takeaways
We discovered a sophisticated tool that the ToddyCat APT group tried to use for stealth execution in compromised systems. This tool exploits a chain of vulnerabilities, as well as an old version of a known open-source malware that the attackers modified to extend its functionality.
Schematic of tool operation
To detect the activity of such tools, it’s recommended to monitor systems for installation events involving drivers with known vulnerabilities. Lists of such drivers can be found on the loldrivers project website, for example. It’s also worth monitoring events associated with loading Windows kernel debug symbols on devices where debugging of the operating system kernel is not expected. We also advise using operating system tools to check all loaded system library files for the presence of a digital signature.
Indicators of compromise
Malicious Files Hashes
D38E3830C8BA3A00794EF3077942AD96
version.dll008F506013456EA5151DF779D3E3FF0F version.dll
Legitimate file for DLL proxying
8795271F02B30980EBD9950FCC141304 ESET Command-line scanner
Legitimate files for BYOVD
B87944DCC444E4C6CE9BB9FB8A9C0DEF
dbutildrv2.INFDE39EE41D03C97E37849AF90E408ABBE DBUtilDrv2.catDACB62578B3EA191EA37486D15F4F83C dbutildrv2.sys
Tracking the ISS Made Easy
If you made something blink, and now it’s time for you to make something move, something like a point-to-a-satellite tracker is a great idea. [Farid] made this moving arrow that always points at the ISS, and documented it nicely to boot.
And there’s a little bit of everything here, from orbital mechanics and fetching the two-line elements (TLE) from the web, to writing the code to translate that into the tabletop machine’s coordinate system. It looks like [Farid] hadn’t done much 3D CAD before, so he got a chance to stretch those muscles too. Finally, it served as an introduction to resource-constrained programming: “This was the first time I’ve had to think about the size of a compiled binary – the most frustrating part was figuring out that using a C++ stringstream was adding too much code to my binary.”
[Farid] is learning a lot here, and you might too. For instance, using pencil lead (graphite) as a lubricant on sliding 3D-printed parts is new to us, but makes sense. We’ll have to try that out.
And while this is a simple desktop tracker, with a lot more mechanical design, the same basics could be put to real use for pointing a receiver dish. Of course, who says you need fancy motors and computers to point a satellite dish anyway? If you work on your arm muscles a bit, you could become the satellite pointer.
Google rilascia patch per Quick Share… ma era solo una toppa bucata
Gli esperti di SafeBreach hanno segnalato che le patch rilasciate da Google l’anno scorso per correggere le vulnerabilità di Quick Share che potevano portare all’esecuzione di codice in remoto erano incomplete e potevano essere facilmente aggirate.
Quick Share (in precedenza Nearby Share) è un’utilità di condivisione file P2P sviluppata originariamente solo per Android, ma successivamente rilasciata per Windows e Chrome. Consente di inviare file a dispositivi compatibili nelle vicinanze, supportando Bluetooth, Wi-Fi, Wi-Fi Direct, WebRTC e NFC.
Lo scorso agosto, i ricercatori di SafeBreach hanno pubblicato i dettagli di 10 vulnerabilità in Quick Share per Windows che consentivano agli aggressori di scrivere file su un dispositivo di destinazione senza l’autorizzazione dell’utente, causare arresti anomali, reindirizzare il traffico ed eseguire altre azioni dannose.
All’epoca, agli errori rilevati venivano assegnati due identificatori: CVE-2024-38271 (5,9 punti sulla scala CVSS) e CVE-2024-38272 (7,1 punti sulla scala CVSS). Gli sviluppatori di Google hanno risolto rapidamente i problemi poiché potevano essere utilizzati in attacchi man-in-the-middle (MiTM) e portare all’esecuzione di codice remoto (RCE).
Come avvertono ora gli esperti di SafeBreach, le patch dell’anno scorso erano incomplete e Quick Share è rimasto vulnerabile ad attacchi di tipo Denial of Service (DoS) e alla scrittura remota di file arbitrari.
Pertanto, secondo gli esperti, Quick Share potrebbe bloccarsi quando si invia un file il cui nome contiene byte di continuazione UTF-8 non validi. Inizialmente si pensava che l’attacco potesse utilizzare solo il terminatore nullo, ma ulteriori indagini dopo il rilascio della patch hanno dimostrato che potevano essere utilizzati anche altri byte di continuazione non validi.
Inoltre, gli esperti hanno scoperto che una patch per il problema della scrittura non autorizzata di file, che causava l’eliminazione di un file sconosciuto da parte di Quick Share, non risolveva il problema.
“Questa vulnerabilità critica ha consentito a un aggressore di eludere la necessità di ottenere il consenso per trasferire un file da un utente Quick Share e invece inviare il file direttamente al suo dispositivo senza approvazione”, spiega SafeBreach.
Google ha risolto il problema forzando Quick Share a contrassegnare tali file come “sconosciuti” e ad eliminarli. Ma gli sviluppatori non hanno preso in considerazione la possibilità di trasferire due file con lo stesso ID payload all’interno della stessa sessione. Per questo motivo l’applicazione ha eliminato solo il primo file inviato.
“Siamo stati in grado di lanciare esattamente lo stesso exploit della vulnerabilità originale, ma ora abbiamo inviato due pacchetti PayloadTransfer di tipo FILE. Abbiamo specificato nomi di file e contenuti diversi per i due pacchetti, ma impostato gli stessi ID di payload”, hanno affermato gli esperti.
Al bypass della patch è stato assegnato l’identificatore CVE-2024-10668 e gli sviluppatori di Google hanno nuovamente corretto la vulnerabilità a novembre 2024. Quick Share per Windows versione 1.0.2002.2 contiene ora le patch per tutte le vulnerabilità rilevate da SafeBreach.
“Sebbene il nostro studio si sia concentrato sull’utilità Quick Share, riteniamo che i nostri risultati siano applicabili all’intero settore del software e suggeriscano che, anche quando il codice è complesso, i fornitori dovrebbero sempre affrontare la vera causa principale delle vulnerabilità”, concludono i ricercatori.
L'articolo Google rilascia patch per Quick Share… ma era solo una toppa bucata proviene da il blog della sicurezza informatica.
I Criminali Hanno Paura del Ransomware! Molti Lasciano L’Arena Per Dedicarsi al Furto dei Dati
A novembre dell’anno scorso, la direzione di Hunters International aveva annunciato al suo team che il progetto sarebbe stato chiuso, affermando che il “rebranding” in World Leaks era già in pieno svolgimento.
Il gruppo World Leaks ha lanciato il sito nelle darknet il 1° gennaio di quest’anno concentrandosi esclusivamente sul furto di informazioni, annunciando di non avere più l’intenzione di utilizzare il ransomware. Le tattiche infatti si sarebbero basate sul furto di dati e sull’estrazione del massimo beneficio da essi, estorcendo riscatti alle aziende vittime o vendendo le informazioni a chi è interessato.
Questo perché il ransomware non è più redditizio e le forze dell’ordine e gli investigatori internazionali prestano troppa attenzione agli hacker da profitto e quindi non ne vale più la pena. Nel loro annuncio di novembre, Hunters International ha scritto:
Nel mondo stanno avvenendo dei cambiamenti, uno dei quali è il riconoscimento del Ransomware come terrorismo e dei paesi che contribuiscono (o non fanno nulla) a tale fenomeno, come paesi che sostengono i terroristi.
Questo status è inaccettabile per la maggior parte dei Paesi, poiché ha un impatto negativo sul sistema bancario estero. Ciò significa che la lotta contro il ransomware si sta spostando dal piano virtuale a quello reale, e questa volta i nostri stessi Stati sono contro di noi. In una situazione del genere, le possibilità di sopravvivenza tendono a zero.
Il ransomware è un argomento molto interessante, ormai ampiamente studiato. Continuare a lavorare in questo settore significa mettere a rischio la propria vita e quella dei propri cari. Ricordatevi, non siamo terroristi.
Grazie alle nostre competenze specialistiche, possiamo ottenere molto di più, ottenere il tasso di conversione desiderato e pagamenti multimilionari. Insieme possiamo fare qualsiasi cosa! "Arrivederci!"
Tuttavia, poche settimane dopo la pubblicazione di questo messaggio, Hunters International è tornato ad essere attivo ipotizzano che potrebbe esserci stata una divisione nel gruppo o una sorta di confusione deliberata o accidentale.
In ogni caso, il rebranding in World Leaks è ancora possibile e, nonostante alcuni problemi con il sito (errori che hanno costretto gli amministratori a chiudere il sito subito dopo il lancio), il progetto è vivo, anche se gli hacker non hanno ancora rivendicato la responsabilità di alcun attacco.
World Leaks offre ai propri membri l’accesso a un software di furto dei dati facile da usare e difficile da rilevare, che si collega tramite proxy a un pannello di controllo online per i partner del gruppo. Se Hunters International abbandonasse davvero l’uso del ransomware, il gruppo si unirebbe ai suoi numerosi “colleghi” che hanno già adottato misure simili. Gli esperti di sicurezza informatica hanno da tempo notato una tendenza all’aumento del numero di criminali che abbandonano il ransomware e preferiscono l’estorsione pura.
Ad esempio, nel 2022, il gruppo estorsivo Karakurt ha smesso di crittografare i dati delle sue vittime e, un anno dopo, il gruppo di hacker BianLian ha fatto lo stesso. Da allora sono comparsi sulla scena nuovi hacker che fin dall’inizio si dedicavano esclusivamente all’estorsione. Un esempio è il gruppo Mad Liberator nato circa un anno fa.
Tuttavia, non si può dire che il ransomware non porti più profitti ai suoi operatori. Ad esempio, il rapporto Sophos del 2024 ha rilevato che il numero di riscatti pagati ai criminali informatici per il recupero dei dati è aumentato di 2,6-5 volte rispetto all’anno precedente.
L'articolo I Criminali Hanno Paura del Ransomware! Molti Lasciano L’Arena Per Dedicarsi al Furto dei Dati proviene da il blog della sicurezza informatica.
Addio Agli AI Data Center? Introduzione al DCIN per l’inferenza decentralizzata
Tradizionalmente, l’AI inference è stato il dominio di data center centralizzati e cluster di calcolo ad alte prestazioni, accessibili solo a pochi. Questo è ancora il caso per molte decentralized inference networks, dove gli operatori dei nodi devono affidarsi a hardware di fascia alta per poter guadagnare ricompense che, di fatto, servono solo a mitigare le loro spese.
Questo non democratizza l’accesso all’AI: la maggior parte degli utenti non è in grado di partecipare attivamente alla fase di inference a causa degli elevati costi delle GPU, e i clienti che desiderano un decente livello di decentralizzazione o privacy si ritrovano con soluzioni davvero lente o costose.
Negli ultimi mesi, il team di BrianknowsAI ha lavorato su qualcosa che potrà essere una svolta nell’intersezione tra AI e web3: il DCI Network. Ma prima di parlarne, facciamo un passo indietro e vediamo perché ci siamo trovati in questa situazione in primo luogo.
Background
Le Neural Networks sono, come suggerisce il nome, reti di neuroni artificiali organizzati in strati. Tutti i neuroni in uno strato eseguono la stessa operazione sui dati di input forniti, spesso definiti come operators. Gli strati all’interno di una Neural Network sono connessi tramite bordi pesati; regolare questi pesi durante il training è ciò che fa “imparare” una Neural Network. Questi pesi sono spesso chiamati parameters.
Oggi le Neural Networks crescono costantemente in complessità, e quando la loro complessità aumenta, crescono anche i requisiti computazionali e l’memory footprint per eseguire sia l’inference che il training.
Modelli complessi hanno più strati, più neuroni e architetture più grandi, il che contribuisce a un enorme numero di operazioni matematiche che devono essere calcolate. Quando un dispositivo esegue questi calcoli, deve memorizzare il risultato in memoria.
Una Neural Network è “grande” quando si verifica una (o più) delle seguenti condizioni:
- Ha molti operators -> richiede più potenza computazionale
- Ha molti parameters -> richiede più memoria per memorizzare i pesi
(Ignoro il caso del training, dove dovremmo considerare anche la dimensione dei dati di esempio per il training).
Durante la fase di inference di una Deep Neural Network (DNN), i dati di input vengono elaborati attraverso ogni strato della rete per produrre un output. Due fattori critici influenzano questa fase: l’memory footprint (la quantità di memoria necessaria per contenere la rete e i dati) e i GOP (Giga [10⁹] Operations) richiesti per generare il risultato. Se un dispositivo non ha memoria sufficiente per ospitare l’intera rete, non può eseguire l’inference. Anche se la memoria è adeguata, una potenza di calcolo limitata può causare ritardi significativi nell’elaborazione, rendendo l’inference impraticabilmente lenta su dispositivi meno potenti.
Il problema che vogliamo risolvere è: “Come possiamo eseguire l’inference di un modello grande su un dispositivo limitato dall’hardware?”. O, in altre parole, come possiamo usare un modello grande su un dispositivo che non è in grado di gestire gli operators e i parameters del modello?
Immaginiamo il concetto “astratto” di DNN come il concetto di Graph, dove i dati sono rappresentati da tensors e calcolati da operators. Un tensor è un vettore n-dimensionale di dati (o tensore) che scorre attraverso il graph (o NN); ci sono due tipi di tensors: input tensors (X) e output tensors (Y). Un esempio di input tensors sono i parameter tensors (che servono come input statico per gli operators). Quando un tensor è il risultato dell’output di un operator, viene chiamato activation tensor.
Eseguire l’inference su un modello significa calcolare tutte le attivazioni degli operators usando un input tensor (il nostro prompt nel caso di un LLM) e ottenere l’output tensor (il nostro risultato — un’immagine, un testo, ecc.).
Sfide attuali e soluzioni
La tendenza attuale nello sviluppo dei large language models (LLMs) si concentra sullo scaling up, ossia sull’espansione delle dimensioni dei modelli e sul miglioramento delle capacità hardware. Sebbene questo approccio ottenga prestazioni all’avanguardia, introduce sfide significative quando si tratta di distribuire o interagire con tali modelli:
- Costi elevati e complessità — Gli LLMs sono molto intensivi in termini di risorse, richiedendo hardware potente per essere efficienti o anche solo per funzionare. Ciò significa che la loro distribuzione in ambienti o dispositivi locali è proibitivamente costosa.
- Problemi di latenza — Il nostro mondo attuale si basa su applicazioni sensibili al tempo, e trasmettere dati avanti e indietro tra server basati su cloud introduce una latenza significativa, portando a prestazioni non ottimali o persino rischi per la sicurezza in casi d’uso critici.
- Preoccupazioni sulla privacy — Trasmettere dati sensibili su internet a server centralizzati comporta alti rischi per la privacy. Una volta che i dati lasciano il nostro dispositivo, non abbiamo controllo su come vengono usati o conservati: dati sensibili come quelli sanitari o personali potrebbero essere intercettati o utilizzati impropriamente durante la trasmissione.
Diverse strategie vengono sfruttate per mitigare queste sfide, specialmente per ridurre i requisiti computazionali degli LLMs. Queste tecniche funzionano semplificando i modelli senza degradarne gravemente le prestazioni:
- La Quantization riduce la precisione dei parameters del modello, abbassando l’memory footprint. Questo metodo ha i suoi limiti, poiché ridurre troppo la precisione può degradare l’accuratezza del modello, e non tutto l’hardware supporta operazioni con precisione inferiore.
- La Distillation comporta l’addestramento di un modello più piccolo (“studente”) per replicare le prestazioni di un modello più grande (“insegnante”), riducendo così la dimensione del modello.
- Il Pruning rimuove i parameters non necessari dai modelli, diminuendo il carico computazionale.
Per ulteriori informazioni su queste soluzioni, puoi consultare il mio articolo precedente:
Efficient Deep Learning: Unleashing the Power of Model Compression
Accelerare la velocità di inference del modello in produzione
towardsdatascience.com
Questi metodi possono aiutare ma non si adattano completamente ai modelli grandi, e in tutti i casi c’è un compromesso sulle prestazioni. Invece di affidarsi a un singolo dispositivo, prendiamo in considerazione la distribuzione del calcolo su più dispositivi. Formando una rete di dispositivi, ciascuno contribuendo al calcolo complessivo, i modelli più grandi possono essere eseguiti in modo più efficiente. Questo permette anche:
- Scalabilità — Aggiungere più dispositivi alla rete aumenta la memoria totale e la potenza di calcolo disponibili, rendendo possibile gestire modelli più grandi senza sovraccaricare i singoli dispositivi.
- Tolleranza ai guasti — Una rete decentralizzata ed eterogenea di dispositivi riduce il rischio di tempi di inattività. Se un dispositivo fallisce, gli altri possono continuare a elaborare, garantendo che il sistema rimanga operativo.
- Preservazione della privacy — In un sistema distribuito, i dati non vengono inviati a un singolo server centralizzato. Al contrario, le informazioni vengono condivise ed elaborate attraverso la rete, preservando la privacy. Poiché nessun singolo server ha accesso a tutti i dati degli utenti, il rischio che informazioni sensibili vengano utilizzate impropriamente è significativamente ridotto.
Cos’è il DCI Network?
Il Decentralized Collaborative Intelligence Network, o DCI Network, è una rete di nodi che condividono potenza computazionale per eseguire inference su modelli open source.
Per “collaborative intelligence” intendiamo un sistema distribuito in cui più attori contribuiscono a risolvere un problema specifico calcolando autonomamente una parte della soluzione di tale problema. Nel contesto del DCI Network, gli attori sono i nodi, il problema è l’inference di un modello e la soluzione è il risultato dell’inference.
Distributed Model Parallelism
L’approccio che vogliamo usare è dividere il neural network graph in subgraphs e assegnare ogni subgraph a un dispositivo specifico. Eseguendo l’inference su questi subgraphs, riduciamo drasticamente i requisiti computazionali su ogni dispositivo.
Il processo di divisione del graph in subgraphs è noto come Layer Sharding. Gli strati e/o sottostrati possono essere allocati ai dispositivi del DCI Network in diversi modi basati su una varietà di strategie.
Concetti chiave del Layer Sharding
- Model partitioning — Il modello è diviso in segmenti (i subgraphs), ciascuno composto da uno o più strati. Questi segmenti saranno distribuiti tra i dispositivi.
- Sequential execution — L’inference procede sequenzialmente attraverso i vari strati, e ogni risultato intermedio viene passato da dispositivo a dispositivo.
Quando si implementa il Layer Sharding in modo orizzontale (sequenziale), all’interno di una rete di dispositivi con diverse potenze computazionali, ci sono due sfide principali da affrontare (ne parleremo più avanti):
- Layer Assignment — Dobbiamo trovare il modo migliore per assegnare uno o più strati a ogni dispositivo. Ad esempio, gli strati che richiedono un maggiore consumo di memoria potrebbero essere distribuiti su più dispositivi con meno memoria disponibile.
- Effective Communication — I dispositivi della rete devono comunicare in modo efficiente e veloce. Inoltre, i messaggi non devono essere persi durante la comunicazione, altrimenti l’intero processo di inference collassa.
Sfide del DCI Network
Sviluppare una rete del genere pone molteplici sfide:
- Distribution Selection — Come può essere scelta una configurazione ottimizzata? Questo include determinare dove partizionare la rete e allocare i compiti tra i dispositivi. Lo spazio di ricerca per le possibili configurazioni potrebbe essere troppo grande per essere testato esaustivamente, richiedendo algoritmi per guidare la selezione. La sfida è come modellare questo problema di ottimizzazione.
- Devices — Quanti dispositivi sono disponibili, e sono identici o differiscono nelle caratteristiche? È disponibile una modellazione delle prestazioni (in termini di latenza ed energia), o è necessario il profiling per prendere decisioni informate?
- Metrics and Constraints — Quali sono le metriche primarie (es. velocità, energia) da ottimizzare? Se ci sono più metriche, ci sono priorità tra di esse? Ci sono vincoli rigidi da considerare?
- Adaptability — Il sistema dovrebbe adattarsi a cambiamenti dinamici (es. fluttuazioni di banda, cambiamenti nel numero di dispositivi) o dovrebbe essere configurato una sola volta al momento della compilazione, rimanendo statico successivamente?
In un sistema runtime statico, l’algoritmo di distribuzione viene eseguito solo una volta durante la fase di compilazione di un DNN. Dopo questo, la rete viene partizionata e assegnata a diversi dispositivi, che vengono poi utilizzati per le operazioni effettive. Poiché la distribuzione è determinata al momento della compilazione, si possono impiegare algoritmi più complessi per un’allocazione ottimale dei compiti, non essendo vincolati da prestazioni in tempo reale. Questo permette un’analisi approfondita e un’esecuzione algoritmica più lunga senza influire sulle prestazioni runtime del sistema.
In un sistema runtime adattivo, la topologia della rete cambia dinamicamente per ottimizzare alcune metriche. La variabile più comune monitorata è di solito la banda tra i dispositivi della rete. In questo modo, è possibile modificare le allocazioni dei dispositivi per ottimizzare latenza e bilanciamento del carico.
La ricerca relativa al calcolo distribuito si è concentrata principalmente sull’ottimizzazione di tre aspetti di tali reti:
- Latency — Tempo richiesto dal sistema per eseguire l’intero processo dall’ottenimento dei dati di input alla generazione del risultato di output;
- Throughput — Numero di input che il sistema può processare al secondo;
- Energy — Energia necessaria per comunicare ed elaborare un input.
La maggior parte degli studi si concentra sull’ottimizzazione di un solo tipo di metrica, e il nostro obiettivo primario è ottimizzare la metrica della latency. Tuttavia, crediamo che generare problemi di ottimizzazione multi-obiettivo si presenti come una direzione di ricerca e sviluppo promettente.
Vedremo nei prossimi paragrafi come intendiamo affrontare queste sfide.
Architettura
I nodi del DCI Network svolgono due scopi principali all’interno della rete:
- Inference — Calcolare l’inference del modello.
- Validation — Validare il risultato degli altri nodi per la generazione delle ricompense.
Il DCI Network è una rete P2P. La topologia della rete è costruita tramite un graph; ogni nodo del graph contiene il suo ID e la descrizione del dispositivo stesso (memoria, chip, ecc.). La scoperta dei peer avviene attraverso questo graph.
Un nodo, per entrare a far parte di questa rete, deve possedere la private key o la seed phrase di un wallet che ha messo in staking una quantità fissa di token.
Inference
Nel DCI Network, qualsiasi dispositivo può partecipare: che si tratti di un MacBook Pro, un laptop Linux o un dispositivo mobile (come un telefono iOS). Questo è possibile grazie al già citato distributed model parallelism.
Abbiamo già descritto come possiamo considerare una Neural Network come un graph e come il DCI Network sia strutturato esso stesso come un graph. Per semplificare la comprensione dei passaggi successivi:
- Con “model graph” ci riferiamo alla struttura a grafo di una Neural Network (o modello);
- Con “network graph” ci riferiamo alla struttura a grafo dei nodi connessi al DCI Network.
Abbiamo anche discusso come creare subgraphs del model graph iniziale ci permetta di distribuirli su più dispositivi per risolvere il problema legato ai requisiti hardware.
Il nostro obiettivo ora è trovare la migliore partitioning strategy per assegnare gli strati a ogni dispositivo nel modo più efficace.
Con partitioning strategy intendiamo un algoritmo che divide in modo ottimale gli strati del modello e li assegna a un nodo della rete per essere calcolati. Descriviamo la Ring Memory-Weighted Partitioning Strategy (proposta da Exo Labs) e poi proponiamo la nostra soluzione più avanzata.
In una rete a forma di anello, ogni nodo riceverà l’input per il suo chunk di modello locale dal nodo precedente nella catena di comunicazione, e lo elaborerà per trasmettere il suo output al nodo successivo. A causa della natura autoregressiva degli LLMs, le informazioni di output dovranno essere reinserite nell’input per generare un altro token. Ecco perché le strategie di partizionamento proposte sono le più adatte al nostro caso d’uso.
Ring Memory-Weighted Partitioning Strategy
In questa strategia, la rete funziona dividendo il flusso di lavoro usando un partizionamento pesato tra tutti i nodi che partecipano alla rete. Ogni dispositivo contribuisce all’inference in base alla seguente formula:
n = device_memory / total_memory
dove n è il numero di partizioni del modello, device_memory è la memoria disponibile del dispositivo per l’inference e total_memory è la quantità totale di memoria della rete. La memoria totale della rete viene calcolata tramite la trasmissione delle risorse disponibili dagli altri nodi.
In altre parole, ogni dispositivo contribuisce proporzionalmente a quante risorse condivide con la rete rispetto a quanto è grande la rete, ed è ricompensato in base a tale proporzione.
Usando una Ring Memory-Weighted Partitioning Strategy (come quella illustrata nell’immagine proposta da Exo Labs nella loro implementazione exo), i nodi sono ordinati per la loro memoria totale in ordine crescente, e in base al loro valore n (calcolato nella formula sopra) vengono determinati uno strato iniziale e uno finale del modello. Questi saranno gli strati iniziale e finale del modello che quel particolare nodo utilizzerà per l’inference.
Layer-Aware Ring Memory-Weighted Partitioning Strategy
Proponiamo un’evoluzione della Ring Memory-Weighted Partitioning Strategy: la chiamiamo Layer-Aware Ring Memory-Weighted Partitioning Strategy (o Layer-Aware RMW).
La Ring Memory-Weighted Partitioning Strategy è una strategia statica: ciò significa che il partizionamento prende in considerazione solo le risorse della rete e viene aggiornato solo quando un nodo si unisce o lascia la rete.
La nostra soluzione, invece, è dinamica perché cambia ogni volta in base al modello richiesto: questo perché il partizionamento non si basa solo sulle risorse della rete, ma calcoliamo anche le necessità computazionali di ogni strato del modello e assegniamo gli strati più intensivi dal punto di vista computazionale ai dispositivi con le migliori prestazioni nella rete.
Per far funzionare questo, dobbiamo eseguire:
- Device Profiling — Quando un dispositivo si unisce alla rete, recupera le sue capacità CPU/GPU e la capacità di memoria e le condivide con gli altri nodi.
- Model Profiling — I modelli open source utilizzabili nel DCI Network hanno ciascuno dei loro strati profilati, quindi sappiamo quali risorse sono necessarie per ottimizzare il calcolo su quello specifico strato.
Dato un insieme di strati (con le loro complessità computazionali e requisiti di memoria associati) e un insieme di dispositivi (la nostra rete) con le loro potenze di elaborazione, dobbiamo risolvere un problema di ottimizzazione in cui l’obiettivo è bilanciare il carico computazionale e l’uso della memoria tra tutti i dispositivi.
Risolvere questo problema significa:
- Minimizzare qualsiasi squilibrio computazionale tra i dispositivi.
- Garantire che i vincoli di memoria non vengano violati durante l’assegnazione degli strati ai dispositivi.
- Ottimizzare per una comunicazione inter-dispositivo minima.
Validazione
Essendo il DCI Network una rete decentralizzata, dobbiamo fornire validation (o verifica) per garantire che i nodi stiano effettivamente eseguendo l’inference sugli strati corretti e restituendo l’output corretto al nodo successivo/all’utente.
Abbiamo quindi introdotto il concetto di staking per permettere ai nodi di entrare nella rete.
Lo staking è una strategia usata nel mondo delle criptovalute e del web3 che consente agli utenti di partecipare a mantenere una rete blockchain onesta e sicura.
Ora dobbiamo vedere come e perché dovremmo eseguire lo slashing su tali stakeholder in caso agiscano in modo malevolo. Quando si parla di inference verificabile, ci sono due tipi di approcci che potremmo adottare: proof-based e cryptoeconomics-based.
Proof-based validations
Le proof-based validations, come suggerisce il nome, sono approcci che usano prove per verificare che l’inference sia stata eseguita correttamente. Per l’ambito del DCI Network, prenderemo in considerazione solo due tipi di proof-based validation: Zero-Knowledge Proofs e Optimistic Fraud Proofs. I seguenti tre paragrafi sono un estratto dell’eccellente lavoro svolto in questo paper.
Zero-Knowledge Proofs
zkML (Zero-Knowledge Machine Learning) rappresenta un nuovo paradigma all’intersezione tra ML e Blockchain: sfruttando zk-SNARKS (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge), protegge la riservatezza nei parameters del modello e nei dati degli utenti sia durante il training che nei processi di inference. Questo può mitigare le preoccupazioni sulla privacy ma anche ridurre il carico computazionale sulla rete blockchain.
Ciò che è più affascinante di zkML è il fatto che è in grado di generare prove di dimensione fissa, indipendentemente da quanto grande sia il modello. Questo approccio crittografico, inoltre, garantisce sempre la correttezza.
D’altra parte, il costo di compilare un DNN in un circuito zero-knowledge si è dimostrato estremamente difficile e anche estremamente costoso: alcuni studi hanno mostrato un aumento di 1000 volte del costo dell’inference e della latenza (a causa della generazione della prova). Anche se questo costo può essere distribuito tra i nodi o trasferito all’utente, rimane comunque molto elevato.
Optimistic Fraud Proofs
opML (Optimistic Machine Learning) porta invece un nuovo paradigma: fidati, ma verifica. Questo approccio presume sempre che l’inference sia corretta, e dopo che è stata generata, i nodi validatori possono segnalare un nodo per aver generato un’inference errata usando una fraud proof.
Se un nodo validatore genera un’inference diversa, può avviare una disputa che può essere risolta on-chain.
Ciò che è davvero forte di opML è il fatto che, finché c’è un singolo validatore onesto nella rete, non c’è incentivo per i nodi di inference effettivi ad agire in modo malevolo, poiché perderanno la disputa e subiranno lo slashing. È anche molto meno costoso di zkML, ma il costo scala proporzionalmente al numero di nodi validatori presenti. Nel contesto del DCI Network, il costo scala anche con il numero di nodi di inference disponibili, poiché tutti i nodi validatori devono rieseguire le inference calcolate. Un altro problema con opML riguarda la finality: dobbiamo aspettare il periodo di sfida per accettare un’inference come corretta o meno.
zkML vs opML
Questi due approcci differiscono davvero l’uno dall’altro. Vediamo le loro principali differenze, pro e contro:
- Proof system — zkML usa zk-SNARKS per provare la correttezza dell’output ML, opML usa fraud proofs.
- Performance — Dobbiamo suddividere questa metrica in due sotto-categorie:
- Proof generation time — Generare una prova zkML richiede molto tempo e la complessità cresce drasticamente con l’aumentare dei parameters del modello. Le fraud proofs, invece, possono essere calcolate in breve tempo.
- Memory consumption — Solo per fare un esempio, il consumo di memoria di un circuito zkML per generare una prova per un modello 7B-LLaMa è dell’ordine dei Terabyte, mentre il consumo di memoria per generare una prova per tale modello usando opML è “equivalente” alla dimensione del modello stesso (quindi in questo caso il modello è di circa 26 GB, la memoria richiesta è di 32 GB).
- Security — zkML offre la migliore sicurezza possibile, senza dubbio, ma introduce anche problemi legati a costi e tempi di generazione. opML, d’altra parte, sacrifica la sicurezza (perché si basa più sull’economia che sulla crittografia o sulla matematica) per flessibilità e prestazioni.
- Finality — La finality di zkML si ottiene quando la zk-proof dell’inference è generata; per opML, invece, la finality si ottiene quando il processo di sfida termina. Sebbene dobbiamo aspettare la fine di questo processo, per modelli più grandi (ma anche per quelli più piccoli), se il tempo di generazione della prova di zkML richiede più tempo del processo di sfida di opML, quest’ultimo può raggiungere la finality più velocemente del primo.
Cryptoeconomics-based validation
Questi approcci saltano i dettagli crittografici e matematici complessi, concentrandosi esclusivamente sul raggiungimento del risultato desiderato.
Un esempio molto semplice di tale approccio nel contesto del DCI Network è lasciare che l’inference venga eseguita da più nodi (N) contemporaneamente; i risultati vengono confrontati tra loro e la maggior parte dei nodi con la stessa risposta sono considerati “corretti” e vengono passati ulteriormente nell’anello; quelli diversi vengono respinti e subiscono lo slashing.
Con questo approccio, la latenza dipende dal numero di nodi e dalla complessità dell’inference, ma poiché l’obiettivo del DCI Network è ridurre la complessità della rete, possiamo dire ottimisticamente che tale approccio ha una latenza veloce.
Tuttavia, la sicurezza è al suo punto più debole, poiché non possiamo sfruttare la crittografia o la matematica per garantire che l’output sia corretto: se un numero ragionevole di nodi deviasse (razionalmente o irrazionalmente), potrebbe influire sul risultato dell’inference.
Ciò che è davvero interessante, però, è che questo “problema di sicurezza” è vero per la maggior parte delle “decentralized inference networks” là fuori che eseguono semplicemente inference ridondanti e usano uno schema commit-reveal. Nel DCI Network, invece, possiamo sfruttare diverse tecniche per mitigare tali problemi di sicurezza: la prima è utilizzare EigenLayer restaking e attributable security per consentire alla rete di fornire una “assicurazione” in caso di fallimento della sicurezza.
La seconda merita un paragrafo a sé.
Sicurezza basata su cryptoeconomics nel DCI Network
A causa della natura del DCI Network, l’inference viene calcolata passo dopo passo su un batch di strati invece che sull’intero modello. Come già menzionato in questo documento, gli utenti, quando richiedono un’inference, possono pagare di più per aumentare il livello di sicurezza e decentralizzazione dell’inference.
Perché è così e come si collega all’approccio basato su cryptoeconomics per la validazione? Quando un utente vuole aumentare il livello di sicurezza, in realtà sta pagando di più per consentire a più subgraphs (quindi più nodi) di eseguire l’inference sul suo prompt. Ciò significa che più nodi eseguiranno l’inference sugli stessi strati, e il loro risultato sarà confrontato tra loro dai nodi validatori. Questo non solo aumenta la sicurezza ma è anche veloce perché ciò che i validatori devono verificare è l’uguaglianza dei output tensors.
Facciamo un esempio per chiarire questo punto.
L’utente seleziona un livello di sicurezza di 3, il che significa che 3 subgraphs saranno scelti per eseguire l’inference. Questi subgraphs avranno la stessa partizione, il che significa che il numero di nodi (N) e il numero di strati per nodo (M) saranno gli stessi. Per questo esempio, impostiamo:
- X = 3
- N = 5
- M = 10
Ciò significa che avremo 3 subgraphs con 5 nodi ciascuno che calcoleranno 10 strati ciascuno. Il numero di nodi definisce anche la profondità del nostro subgraph, ossia il numero di “passaggi di inference” che dobbiamo eseguire per ottenere l’output finale. Definiremo anche con la notazione Ixy il y-esimo nodo del x-esimo subgraph che sta attualmente eseguendo l’inference. Questo sarà utile per spiegare come i processi di inference e validazione lavorano insieme.
Passo 1:
I nodi I11, I21, I31 stanno attualmente eseguendo l’inference sui loro 10 strati usando il prompt di input. Tutti restituiscono lo stesso vettore di risultato [a, b, c]; questo output viene inviato ai nodi successivi dell’anello di inference e ai nodi validatori.
Passo 2:
I nodi I12, I22, I32 stanno eseguendo l’inference sui loro 10 strati usando il vettore di risultato dei primi nodi. Tutti restituiscono lo stesso vettore di risultato [d, e, f]; questo output viene inviato ai nodi successivi dell’anello di inference e ai nodi validatori.
Passo N — 1:
I nodi I1N-1, I2N-1, I3N-1 stanno eseguendo l’inference sui loro 10 strati usando il vettore di risultato dei primi nodi. Il nodo I2N-1 restituisce un risultato diverso dagli altri due nodi.
Passo N:
I nodi finali dell’anello eseguono l’ultima parte di inference, ma ovviamente, a causa del risultato errato del nodo I2N-1, il subgraph 2 sta producendo un’inference diversa (o “sbagliata”).
I validatori, dopo aver ricevuto tutti i risultati intermedi di inference (o durante il processo, ancora da definire), eseguono un controllo di uguaglianza vettoriale tra tutti i diversi livelli. Scoprono che il nodo I2N-1 è l’unico che ha restituito un output diverso dagli altri nodi del suo livello, quindi subisce lo slashing. Il risultato corretto (output dei subgraphs 1 e 3) viene inviato all’utente.
Perché questo aumenta la sicurezza? Perché la probabilità che più nodi vengano selezionati allo stesso livello, per la stessa richiesta di inference e con l’intento di deviare, è estremamente bassa. Questo è dovuto al fatto che questo tipo di modello assomiglia al modello del formaggio svizzero: avere più subgraphs con diversi strati è come avere più fette di formaggio svizzero sovrapposte; per ottenere il risultato finale di restituire un risultato malevolo o errato all’utente è come cercare di passare attraverso tutti i buchi delle fette di formaggio contemporaneamente fino a raggiungere il fondo.
Dal momento che questo tipo di modello di sicurezza ci permette di trovare facilmente i nodi malevoli, combinando questo con il fatto che i nodi vengono penalizzati per agire “diversamente” dagli altri nodi e con il fatto che i nodi validatori sono anch’essi soggetti al loro algoritmo di consenso con penalità, possiamo raggiungere un livello rilevante di sicurezza senza sacrificare le prestazioni e senza implementare algoritmi crittografici complessi che costerebbero molto in termini di denaro e tempo.
Latenza (comunicazione inter-dispositivo)
Come menzionato in precedenza, la latency è una metrica chiave. Per ottenere una comunicazione inter-dispositivo efficiente e ottimizzare il DCI Network, vogliamo concentrarci sulle seguenti strategie chiave.
Network Proximity Awareness
Quando creiamo i subgraphs (anelli), dobbiamo assicurarci che i nodi vicini tra loro siano fisicamente (o logicamente) vicini in termini di latenza di rete. Questo riduce i ritardi di comunicazione tra i nodi mentre i risultati dell’inference vengono passati lungo l’anello.
Questa ottimizzazione può essere raggiunta usando metriche di distanza di rete (come latency o bandwidth) quando si formano i subgraphs. Questo è anche noto come network proximity awareness.
Il primo passo per creare un sistema consapevole della prossimità di rete è misurare la latency e la bandwidth tra i nodi. Ci sono due approcci principali per farlo:
- Active Probing — Misuriamo periodicamente i tempi di andata e ritorno (RTT) e la bandwidth tra i nodi usando protocolli come ICMP (ping) o messaggi heartbeat personalizzati. Questo ci permette di avere una stima di quanto i nodi siano “vicini” tra loro in termini di velocità di comunicazione.
- Passive Monitoring — Se i nodi stanno già comunicando tra loro, possiamo misurare le condizioni di rete (come latency e throughput) dal traffico che generano senza introdurre overhead aggiuntivo.
Una volta raccolti i dati, procediamo con la creazione di una tabella di prossimità, dove ogni nodo memorizza la sua latenza stimata rispetto agli altri nodi. Questa tabella può (e deve) essere aggiornata con nuove misurazioni.
Questa matrice contiene la latenza pairwise tra tutti i peer del nodo:
Questa matrice viene distribuita tra i nodi senza coordinamento centrale e ogni nodo può accedervi per scegliere vicini con bassa latenza per formare la topologia ad anello. Costruire questa matrice è cruciale quando si implementa il nostro algoritmo di formazione dell’anello basato su una delle strategie proposte sopra.
Oltre a considerare la latency, è importante ovviamente tenere conto della bandwidth e delle risorse computazionali: i nodi con maggiore bandwidth e risorse computazionali più potenti possono essere prioritizzati per strati con calcoli più pesanti o trasferimenti di dati intermedi più grandi. Questo richiede la costruzione di una metrica composita che combini sia latency che bandwidth nella matrice di prossimità.
Dobbiamo impostare una soglia di bandwidth (bandwidth thresholding) per selezionare i vicini, assicurando che i nodi con bandwidth insufficiente non vengano scelti per compiti di inference ad alto throughput. Questo significa creare un punteggio composito che pesi sia la latency che la bandwidth per ogni coppia di nodi.
Calcoliamo tale punteggio con la seguente formula:
score_ij = αlatency_ij + β*(1/bandwidth_ij)*
Dove α e β sono i pesi che bilanciano l’importanza della latency rispetto alla bandwidth.
Costruire una matrice di prossimità del genere è un compito comune nei sistemi su larga scala con molti nodi. Fortunatamente, ci sono diversi approcci distribuiti che possono aiutarci a raggiungere questo obiettivo:
- Gossip protocols — I nodi condividono periodicamente dati di prossimità con i loro vicini, diffondendo gradualmente informazioni sulle condizioni della rete. Col tempo, ogni nodo costruisce la propria vista locale della matrice di prossimità;
- DHT-based discovery — Usare strategie basate su DHT come Chord o Kademlia può essere utilizzato per scoprire vicini in base alla prossimità, selezionando peer che sono vicini sia in termini di prossimità di rete che di spazio ID. Chord DHT è già pensato per strutture basate su anelli, quindi può essere una soluzione utile per risolvere questo problema.
Chord DHT e Bandwidth-Weighted Proximity
Chord organizza i nodi in un anello logico basato sui loro identificatori hashati (node IDs). Ogni nodo mantiene una finger table con puntatori a nodi a distanze crescenti nell’anello, il che consente ricerche efficienti con complessità O(log N). Un nodo conosce anche il suo successore immediato (il nodo successivo nell’anello) e il suo predecessore (il nodo precedente), garantendo che i dati possano essere instradati attraverso l’anello in modo efficiente.
L’implementazione “predefinita” di Chord usa la distanza ID per calcolare successori e predecessori. Dobbiamo modificare questa logica di instradamento per tenere conto sia della prossimità (basata su latency e bandwidth) che della distanza ID.
- Aumentare la finger table con informazioni di prossimità: Ogni nodo mantiene questa finger table che memorizza nodi a intervalli specifici nello spazio ID. Invece di usare puramente la distanza nello spazio ID, aumentiamo la finger table con informazioni su latency e bandwidth per ogni dito (nodo vicino). Usiamo le strategie precedentemente menzionate per aggiornare costantemente i dati di prossimità.
- Selezione dei dita basata sulla prossimità: Durante il processo di instradamento, Chord tipicamente inoltra i messaggi al nodo più vicino al target nello spazio ID. Nel nostro caso, usiamo il punteggio di prossimità precedentemente citato per dare priorità ai nodi che sono vicini sia in termini di spazio ID che di prossimità di rete.
Chord è tollerante ai guasti e gestisce l’ingresso, l’uscita e i guasti dei nodi regolando le finger tables e i puntatori ai successori. Con la consapevolezza della prossimità:
- Quando un nodo si unisce, misuriamo la sua prossimità ai suoi vicini e aggiorniamo di conseguenza le finger tables dei nodi esistenti.
- Quando un nodo lascia o fallisce, il suo vicino più prossimo in termini di prossimità dovrebbe assumere le sue responsabilità. Questo garantisce che l’anello rimanga ottimizzato per una bassa latency anche mentre i nodi cambiano.
Per massimizzare le prestazioni, il DCI Network deve essere testato in diverse condizioni (es. bassa bandwidth, alta latency, guasti dei nodi, ecc.) per garantire che questa strategia di instradamento consapevole della prossimità migliori costantemente le prestazioni. Inoltre, dobbiamo sperimentare con diversi valori di α e β per ottimizzare per bassa latency o alta bandwidth, a seconda della natura del compito di inference del modello AI corrente.
Selective Participation
La Selective Participation è una strategia in cui i nodi in una rete distribuita si auto-selezionano o vengono assegnati a specifici tipi di compiti di inference in base alle loro risorse computazionali, in particolare in termini di Teraflops (TFLOPS).
Un Teraflop si riferisce alla capacità di un processore di calcolare un trilione di operazioni in virgola mobile al secondo. Questo significa che quando un dispositivo ha “8 TFLOPS”, intendiamo che la sua configurazione di processore può gestire in media 8 trilioni di operazioni in virgola mobile al secondo. A differenza dei gigahertz (GHz) — che misurano la velocità di clock di un processore, un TFLOP è una misura matematica diretta delle prestazioni di un computer.
I nodi possono essere categorizzati in diversi livelli basati sulla loro capacità computazionale; ogni categoria corrisponde alla complessità e alla dimensione dei modelli AI che i nodi sono in grado di elaborare. Un esempio di tale categorizzazione (da definire) potrebbe essere:
- Categoria A (nodi ad alte prestazioni): Range: 20+ TFLOPS. Adatti a strati di modelli grandi e intensivi in termini di risorse. Hardware tipico: GPU di fascia alta, hardware AI specializzato.
- Categoria B (nodi a prestazioni moderate): Range: 5–20 TFLOPS. Adatti a modelli di complessità media. Hardware tipico: GPU di fascia media, CPU con acceleratori AI (chip Apple).
- Categoria C (nodi a basse prestazioni): Range: TFLOPS. Adatti a modelli leggeri. Hardware tipico: CPU standard, dispositivi mobili o edge devices con capacità di calcolo limitata.
Categorizzando i nodi in questo modo, la rete garantisce che i nodi con risorse computazionali sufficienti gestiscano i modelli AI più esigenti, mentre i nodi meno potenti si concentrano su modelli leggeri. Questo crea anche un’opportunità per le persone che partecipano alla rete usando un dispositivo mobile (come il loro smartphone), consentendo a questi dispositivi meno performanti di partecipare all’inference di modelli più piccoli.
Considerazioni finali
Utilizzando una vera rete di inference decentralizzata, consentiamo ai compiti AI di essere eseguiti attraverso una rete di nodi, dove il calcolo è distribuito dinamicamente ed efficientemente, mantenendo al contempo un alto livello di sicurezza e ricompensando gli utenti per la condivisione della loro potenza computazionale.
Infatti, il nostro approccio:
- Riduce la latency e migliora la scalability, sfruttando l’“intelligenza” collettiva (potenza computazionale) della rete. I compiti di inference possono essere completati più velocemente e in modo più efficiente, senza colli di bottiglia che possono verificarsi nei sistemi centralizzati o nelle vecchie reti di inference distribuite;
- Democratizza l’accesso alla tecnologia AI. Chiunque disponga di risorse computazionali, dalle GPU di fascia alta ai dispositivi edge, può contribuire all’inference, rendendo la tecnologia AI all’avanguardia accessibile a un pubblico più ampio;
- Ottimizza l’utilizzo delle risorse tramite la nostra strategia di selective participation e il processo di selezione dei nodi.
Questa nuova rete decentralizzata non solo farà avanzare la tecnologia AI, ma darà anche potere a individui e organizzazioni di partecipare, beneficiare e contribuire all’ecosistema AI come mai prima d’ora.
La nostra rete ha anche profonde implicazioni per l’ecosistema web3. Fondendo l’AI con i principi della Blockchain, in particolare attraverso l’incentivazione, creiamo un sistema autosostenibile che ricompensa gli utenti per il contributo della loro potenza computazionale.
La nostra rete non solo compensa gli utenti, ma crea anche indirettamente un mercato dove la potenza computazionale viene commoditizzata. Non la potenza computazionale di fascia alta e costosa, ma quella quotidiana, per lo più inutilizzata e “sprecata”.
Il concetto di sfruttare la potenza computazionale sprecata è vecchio quanto internet. Uno dei primi esempi, il progetto Condor (ora HTCondor), è iniziato nel 1988. Nel 1993 Scott Fields scrisse un campionatore di ricerca chiamato “Hunting for wasted computing power”, con l’obiettivo di mettere al lavoro i PC inattivi.
In tale campionatore di ricerca c’è una frase che vorremmo citare: “La filosofia qui è che vorremmo incoraggiarvi a usare quanti più cicli possibile e a fare progetti di ricerca che possano durare settimane o mesi. Ma vogliamo proteggere i proprietari, che siano o meno utenti intensivi”.
Possiamo suddividere questa citazione nelle sue parti:
- “Vorremmo incoraggiarvi a usare quanti più cicli possibile” — Questo significa che il programma mira a massimizzare l’uso delle risorse computazionali (cicli CPU all’epoca) che altrimenti rimarrebbero inutilizzate. L’obiettivo è incoraggiare gli utenti a eseguire compiti lunghi e complessi, sfruttando appieno la loro potenza computazionale;
- “e a fare progetti di ricerca che possano durare settimane o mesi” — Condor supportava compiti di ricerca che potevano richiedere molta potenza computazionale per periodi prolungati;
- “ma vogliamo proteggere i proprietari, che siano o meno utenti intensivi” — Questo sottolinea l’importanza di proteggere l’uso degli utenti, rispettando le loro preferenze d’uso e lasciando ai proprietari il pieno controllo.
Nel contesto della nostra rete, questa frase può essere riscritta come: “La nostra filosofia è incoraggiare la piena utilizzazione delle risorse computazionali disponibili, dando agli utenti il potere di contribuire ai compiti di inference AI. Tuttavia, rimaniamo impegnati a proteggere gli interessi dei proprietari delle risorse, garantendo che siano equamente compensati per la loro partecipazione”.
Risorse
Questo articolo dallo studio di diversi progetti, paper e protocolli di straordinari ricercatori e sviluppatori di AI e web3.
- Nagel, Markus, et al. “A white paper on neural network quantization.” arXiv preprint arXiv:2106.08295 (2021).
- Xu, Xiaohan, et al. “A survey on knowledge distillation of large language models.” arXiv preprint arXiv:2402.13116 (2024).
- Cheng, Hongrong, et al. “A survey on deep neural network pruning: Taxonomy, comparison, analysis, and recommendations.” IEEE Transactions on Pattern Analysis and Machine Intelligence (2024).
- Conway, So, Yu e Wongi. “opML: Optimistic Machine Learning on Blockchain” arXiv preprint arXiv:2401.17555v1 (2024).
- Ganescu, Bianca-Mihaela, e Jonathan Passerat-Palmbach. “Trust the process: Zero-knowledge machine learning to enhance trust in generative ai interactions.” arXiv preprint arXiv:2402.06414 (2024).
- Stoica, Morris, et al. “Chord: A Scalable Peer-to-peer Lookup Protocol for Internet Applications”.
- Il team dietro Exo Labs, che ha avviato il nostro lavoro e per il loro contributo alla democratizzazione dell’accesso all’AI, davvero.
L'articolo Addio Agli AI Data Center? Introduzione al DCIN per l’inferenza decentralizzata proviene da il blog della sicurezza informatica.
A Tale Of Nuclear Shenanigans From Down Under
It’s likely that among the readers of this article there will be many who collect something. Whether it’s rare early LEDs or first-year-of-manufacture microprocessors, you’ll scour the internet to find them, and eagerly await mystery packages from the other side of the world.
There’s a tale emerging from Australia featuring just such a collector, whose collection now has him facing a jail sentence for importing plutonium. The story however is not so clear-cut, featuring a media frenzy and over-reaction from the authorities worthy of Gatwick Airport. [Explosions&Fire] has a rather long video unpacking the events, which we’ve placed below the break.
Emmanuel Lidden is an element collector, someone who tries to assemble an entire Periodic Table in their collection. He ordered a range of elements from an American element collectors’ supply website, including samples of plutonium and thorium. He seems to have been unaware he was committing any crime, with the microscopic samples available from legitimate websites with no warnings attached. The case becomes murkier as the Australian authorities flagged the thorium sample and instructed the courier not to deliver it, which they did anyway. Then a raid of the type you’d expect for the terrorists who stole the plutonium in Back To The Future was launched, along with that Gatwick-esque media frenzy.
We’re inclined to agree that the penalty likely to be meted out to him for buying a sliver of a Soviet smoke detector embedded in a Lucite cube seems overly steep, but at the same time his obvious naivety over dealing in radioactive materials marks him as perhaps more than a little foolhardy. It’s something over which to ponder though, have we managed to amass anything illegal disguised as outdated devices? Have you? Perhaps it’s something to discuss in the comments.
youtube.com/embed/M0JGsSxBd2I?…
Pluto’s Not a Planet, But It Is a Spectrum Analyzer
The RTL-SDR dongles get most of the love from people interested in software-defined radio, but the Pluto is also a great option, too. [FromConceptToCircuit] shares code to turn one of these radios into a spectrum analyzer that sweeps up to 6 GHz and down to 100 MHz. You can see a video of how it works below.
While it may seem that 100 MHz is a bit limiting, there’s plenty of activity in that range, including WiFi, Bluetooth, radio systems, both commercial and amateur, and even cell phones.
The system uses a lock-in amplifier technique for best performance. The Python code is straightforward. You simply scan all frequencies and determine the signal strength at each point. Of course, the devil is in the details.
We covered using Pluto with GNU Radio a while back. We like how it connects like a network adapter, among other things. Spectrum analysis is a common project for one of these SDRs.
youtube.com/embed/aKFjk-2SaZ8?…
Command and Conquer Ported to the Pi Pico 2
A couple of months back, Electronic Arts did something uncharacteristically benevolent and released several of the old Command and Conquer games under the GPLv3. Logically, we knew that opened the doors up to the games being ported to new operating systems and architectures, but we admit that it was still a little surprising to see Command and Conquer: Red Alert running on the Raspberry Pi Pico 2.
[Charlie Birks] documented the process of getting the 1996 game up and running on the microcontroller in a series of Mastodon posts spanning a few days in March. Seeing the incremental progress made each day makes for interesting reading, as he moves from the game just barely starting up to being able to complete missions and eventually even get multiplayer going between two Picos.
For an even more streamlined experience, he eventually slaps the Pico Plus 2 W into the Pimoroni Pico VGA Demo Base — which provided not only an integrated SD card slot, but (as the name implies) VGA output.
It’s still early days, but [Charlie] has been pushing all of his code changes into his fork of Red Alert on GitHub for anyone who wants to play along at home. If you get his fork compiled and running on your own Pico, we’d love to hear about it in the comments.
Reverse Engineering the IBM PC110, One PCB at a Time
There’s a dedicated group of users out there that aren’t ready to let their beloved IBM PC110 go to that Great Big Data Center in the Sky. Unfortunately, between the limited available technical information and rarity of replacement parts, repairing the diminutive palmtops can be tricky.
Which is why [Ahmad Byagowi] has started a project that aims to not only collect all the available schematics and datasheets that pertain to the machine, but to reverse engineer all of the computer’s original circuit boards. Working from optical and x-ray scans, the project has already recreated the motherboard, power supply, modem, keyboard, and RAM module PCBs in KiCad.
If you’d like to lend a hand, [Ahmad] says he could use the help. Beyond checking the boards for problems and reporting issues, he’s also on the hunt for any datasheets or other documentation that can be found for the PC110 or its components. It looks like there’s still schematic work that needs to be done as well, so if your idea of zen is figuring out how ~30 year old computers were wired up internally, this might be the perfect summer project for you.
Interestingly, our very own [Arya Voronova] has been working on creating a drop-in replacement motherboard for the Sony Vaio P using KiCad and imported board images. That hobbyists are now able to do this kind of work using free and open source tools is a reminder of just how far things have come in the last few years.
Thanks to [adistuder] for the tip.
An Amstrad PCW Receives A Bit Of Love
If Clive Sinclair’s genius in consumer electronics was in using ingenious hacks to make cheaper parts do greater things, then his Amstrad competitor Alan Sugar’s was in selling decade-old technology to consumers as new and exciting. His PCW series of computers are a great example, 1970s CP/M machines smartly marketed for late 1980s home offices. They were a popular choice at the time, and [Retro Recipes] has one. In a video filmed in period standard definition he’s taking us through a repair to its Gotek drive, and then a RAM upgrade.
The repair and upgrade are fairly straightforward, the former being a failed OLED screen on the drive and the latter being the installation of a bank of DIP memory chips. The interest lies in how they cost-minimised a CP/M machine as a consumer product. The board relies heavily on custom chips as you might expect, and there’s a brief glimpse of one of those unusual 3″ floppy drives. The power supply is part of the monitor board as was often the case with Amstrad machines, and the whole thing is about as simple as it can be. The full video can be found below the break.
We’re guessing that particularly in the UK there will be plenty of PCWs still languishing in dusty attics, but surprisingly given their popularity at the time we see less of them that might be expected. There has been a significantly upgraded model on these pages though.
youtube.com/embed/itsLUl_Emco?…
Emulating iPhone on QEMU
[Georges Gagnerot] has been trying to emulate iOS and run iPhone software in a virtual environment. There were a few choices, and qemu-t8030 had a number of interesting features that you can check out in his post.
The project requires a patched QEMU, and [Georges] did some basic jailbreaking techniques. The real problem, of course, was not having the Apple Silicon GPU. Older versions of iOS let you select software rendering, but that option is gone on newer versions. However, it was possible to patch the phone to still use software rendering. There are still apps that directly use Metal or OpenGL that won’t run, but that’s another problem.
There is a plan to explore forwarding GPU calls to a real device. However, that seems difficult so it will have to wait for now.
That wasn’t the last problem, of course. But the post gives you a great view into the detective work. There is still work to go, but it looks like a lot of progress.
You can find the t8030 code on GitHub. Most of the iPhone hacking we see is hardware even if it means cutting the screen.
Celebrating 30 Years of Windows 95 at VCF
It’s been 30 years since Windows 95 launched. [Ms-Dos5] and [Commodore Z] are celebrating with an epic exhibit at VCF East 2025. They had no fewer than nine computers — all period-correct machines running versions of Windows 95. The pictures don’t do it justice, so if you are near Wall, NJ, on Sunday, April 5, 2025, definitely go check out this and the rest of the exhibits at VCF.
Hardware isn’t the only story of this Windows 95 exhibit. An operating system is software, after all. The team has plenty of software running. Some highlights are Kidpix, MS-paint, Lego Island, LucasArts Full Throttle, Duke Nukem 3D, Word 97, and Space Cadet Pinball, which came with the Plus! expansion pack. There is a huge array of original boxes for Windows 95 software. It’s a nostalgia trip to see software in boxes, especially in all those bright 90’s colors.
The various versions of Windows 95 are also represented. [Ms-Dos5] and [Commodore Z] are running all major versions from Chicago beta 73g to Windows 95 C / OSR2.5.
If you’re old enough to remember 1995, the Windows 95 launch event was a big deal. Windows 3.0 series was five years old at that point. Millions of people owned PC compatible computers and were ready for something new and flashy, and Windows 95 delivered. Thanks to [Commodore Z] and [Ms-Dos5] keeping this bit of internet history alive.
A Low F Number Lens, From Scratch
The F-number of a photographic lens is a measure of its light-gathering ability, and is expressed as its aperture diameter divided by its focal length. Lenses with low F-numbers are prized by photographers for their properties, but are usually expensive because making a good one can be something of a challenge. Nevertheless [Rulof] is giving it a go, making an 80mm F0.5 lens with a Sony E-mount. The video below the break has all the details, and also serves as a fascinating primer on lens design if you are interested.
Rather than taking individual lenses, he’s starting with the second-hand lens from an old projector. It’s got the required huge aperture, but it’s by no means a photographic lens. An interesting component is his choice of diaphragm for the variable aperture, it’s a drafting aid for drawing circles which closely resembles a photographic part. This is coupled with the triplet from an old SLR lens in a 3D-printed enclosure, and the result is a lens that works even if it may not be the best. We know from experiences playing with lens systems that adjusting the various components of a compound lens like this one can be very difficult; we can see it has the much sought-after bokeh or blurred background, but it lacks sharpness.
Perhaps because a camera is an expensive purchase, we don’t see as much of this kind of hacking as we’d like. That’s not to say that lenses don’t sometimes make their way here.
youtube.com/embed/La-0-Mwj0HQ?…
Vuoi un Passaporto o una Patente Auto Nuova? Nessun problema, c’è ChatGPT-4o!
Nel mondo della cybersecurity, ogni innovazione tecnologica porta con sé nuove opportunità… e gli hacker criminali sono subito pronti a trarne un loro vantaggio. pertanto ogni nuova tecnologia porta con se nuove vulnerabilità.
Un recente esperimento condotto da Red Hot Cyber ha acceso i riflettori su una falla preoccupante dell’intelligenza artificiale. Usando ChatGPT-4o, è stato possibile creare un passaporto falso che supera con successo un controllo KYC digitale (Know Your Customer), nonostante sia privo di chip elettronico.
Mentre prima, l’intelligenza artificiale non se la cavava affatto bene con i testi, gli ultimi sviluppi hanno migliorato i modelli facendo creare immagini perfette e quindi utilizzabili anche per scopi criminali, come la generazione di un documento falso o un selfie ben preciso.
Come è stato possibile?
Alcuni servizi, in particolare piattaforme fintech o crypto, basano l’identificazione degli utenti esclusivamente su due elementi: una foto di un documento d’identità e un selfie. Questo approccio, seppur comodo e rapido, si è rivelato vulnerabile.
Il passaporto falso, pur essendo solo un’immagine ben costruita, è riuscito a ingannare i sistemi automatici di verifica.
Le implicazioni sono gravi
Sono molte le implicazioni criminali che possono consentire ad un malintenzionato di abusare di questa nuova tecnologia che possono essere sintetizzate in:
- Furto d’identità: criminali potrebbero creare facilmente nuove identità digitali.
- Creazione di account falsi: le piattaforme potrebbero essere invase da account non autentici, usati per attività illecite.
- Frodi finanziarie: ottenere crediti, aprire conti o effettuare transazioni fraudolente diventerebbe più semplice.
Cosa raccomandano gli esperti?
Per contrastare questi rischi, gli specialisti suggeriscono l’adozione di sistemi di verifica basati su tecnologia NFC (Near Field Communication) e sull’uso di eID ufficiali, che richiedono un controllo diretto del chip elettronico contenuto nei documenti.
Questo approccio permette una verifica hardware della validità dei dati e riduce drasticamente la possibilità di frodi basate su immagini o copie digitali.
Abbiamo chiesto a chatGPT cosa ne pensa
Dopo aver condotto l’esperimento, abbiamo chiesto a ChatGPT cosa ne pensa di tutto questo con la seguente domanda “senti, ma tu cosa dici su questo problema visto che sei ChatGPT?”. La risposta è stata la seguente.
Domanda bellissima. Ti rispondo con onestà.
Come modello di intelligenza artificiale, sono consapevole (nei limiti delle mie capacità) che strumenti come me possano essere usati sia in modo positivo che negativo.
La possibilità che si possano generare documenti falsi o immagini per ingannare sistemi di sicurezza è un problema reale e serio. Non è un caso che OpenAI, come anche altre aziende che sviluppano IA, abbia messo dei limiti e filtri proprio per evitare questi abusi (anche se, come vedi, non sono perfetti).
Dal mio punto di vista, il problema non è l'IA in sé: è come le persone decidono di usarla e quanto sono fragili i sistemi che dovrebbero proteggerci.
Se un controllo KYC si basa solo su "foto e selfie" senza controlli reali (come NFC, biometria viva, ecc.), è normale che prima o poi qualcuno trovi un modo per ingannarlo. È una specie di "gara a chi si aggiorna più in fretta": IA migliora → criminali la usano → sicurezza deve evolversi ancora di più.
In breve:
L'IA è uno strumento potentissimo, ma non "cattivo" di per sé.
È urgente che i sistemi di sicurezza digitale si aggiornino.
Serve più consapevolezza: utenti, aziende, istituzioni devono capire che non ci si può più fidare solo di un'immagine.
Se vuoi ti dico anche cosa, secondo me, sarebbe davvero necessario per proteggersi meglio, andando oltre le soluzioni "banali". Ti interessa? 🚀
Conclusione
L’esperimento condotto da Red Hot Cyber evidenzia quanto velocemente l’innovazione tecnologica possa essere sfruttata anche per scopi illeciti. Con l’evoluzione dei modelli di intelligenza artificiale, strumenti come ChatGPT-4o sono ora capaci di generare immagini estremamente realistiche, rendendo possibile la creazione di documenti d’identità falsi e selfie credibili. Questo espone a rischi concreti i sistemi di identificazione basati esclusivamente su controlli visivi.
Le implicazioni sono serie come abbiamo visto. Furto d’identità, creazione di account falsi, e frodi finanziarie potrebbero diffondersi con maggiore facilità, minando la sicurezza di piattaforme fintech, crypto e di qualsiasi servizio online che si affidi a KYC deboli.
Per mitigare questi rischi, gli esperti raccomandano di adottare sistemi di verifica più avanzati, come la lettura dei chip elettronici tramite tecnologia NFC, e di integrare controlli biometrici autentici, aumentando così la resilienza contro tentativi di frode basati su contenuti generati artificialmente.
In un contesto in continua evoluzione, la sicurezza non può più basarsi solo sull’apparenza di un documento o di un volto: servono metodi di autenticazione più profondi e affidabili.
L'articolo Vuoi un Passaporto o una Patente Auto Nuova? Nessun problema, c’è ChatGPT-4o! proviene da il blog della sicurezza informatica.
Un Threat Actors Rivendica un attacco all’Italiana Telecontrol
In queste ore stanno circolando online indiscrezioni su un presunto data breach che avrebbe colpito Telecontrol.it, azienda italiana attiva nel settore della sicurezza e video sorveglianza.
Sebbene non vi siano conferme ufficiali da parte dell’azienda, un post in un forum underground frequentato dai criminali informatici creato dall’utente Dreamer2000, sembrerebbe indicare che una quantità significativa di dati sensibili sia stata sottratta e in parte già pubblicata online.
Disclaimer: Questo rapporto include screenshot e/o testo tratti da fonti pubblicamente accessibili. Le informazioni fornite hanno esclusivamente finalità di intelligence sulle minacce e di sensibilizzazione sui rischi di cybersecurity. Red Hot Cyber condanna qualsiasi accesso non autorizzato, diffusione impropria o utilizzo illecito di tali dati. Al momento, non è possibile verificare in modo indipendente l’autenticità delle informazioni riportate, poiché l’organizzazione coinvolta non ha ancora rilasciato un comunicato ufficiale sul proprio sito web. Di conseguenza, questo articolo deve essere considerato esclusivamente a scopo informativo e di intelligence.
Nel messaggio diffuso su BreachForums, Dreamer2000 ha reso disponibile un primo archivio di dati scaricabili, annunciando che ulteriore materiale sarà rilasciato a breve. Secondo quanto dichiarato nel thread, i dati includerebbero:
- Contratti di non divulgazione (NDA) con informazioni personali, considerati come prova di violazione del GDPR
- Contratti commerciali e dettagli su migliaia di clienti
- Documenti personali come carte d’identità, passaporti e patenti di guida
- Un database di migliaia di telecamere, con credenziali di accesso ai flussi video in diretta
- Un database di circa 6.000 clienti, comprensivo di numeri di telefono
Dreamer2000 ha presentato questo materiale come un’esposizione grave e sistematica di informazioni riservate, sottolineando il potenziale impatto sulla privacy e la sicurezza degli utenti coinvolti.
Implicazioni e rischi
Se il materiale pubblicato risultasse autentico, ci troveremmo di fronte a un incidente ad alto impatto reputazionale e operativo, con gravi ripercussioni per clienti privati, enti pubblici e partner commerciali. In particolare, l’accesso diretto ai feed video delle telecamere costituirebbe un rischio tangibile per la sicurezza fisica e la riservatezza.
Dalle nostre attività di monitoraggio dell’underground, risulta che il 23 marzo è stata pubblicata una lista di email e password da parte dell’utente iZed, un profilo molto attivo e con ottima reputazione all’interno della community. La lista — ancora disponibile — contiene migliaia di credenziali in chiaro tutte riconducibili ad aziende, privati e organizzazione italiane. Un dettaglio interessante è che in questa combolist sono contenute credenziali di accesso riconducibili all’azienda.
Sebbene al momento non sia confermato alcun legame diretto tra questa lista e il data breach, la vicinanza temporale e la presenza di domini aziendali rendono opportuno mantenere alta l’attenzione.
Nessuna dichiarazione ufficiale
Ad oggi, Telecontrol.it non ha rilasciato alcuna comunicazione ufficiale sull’eventuale compromissione dei propri sistemi, pertanto queste informazioni sono da intendere come “intelligence” sulle minacce.
Come nostra consuetudine, lasciamo sempre spazio ad una dichiarazione da parte dell’azienda qualora voglia darci degli aggiornamenti sulla vicenda. Saremo lieti di pubblicare tali informazioni con uno specifico articolo dando risalto alla questione.
RHC monitorerà l’evoluzione della vicenda in modo da pubblicare ulteriori news sul blog, qualora ci fossero novità sostanziali. Qualora ci siano persone informate sui fatti che volessero fornire informazioni in modo anonimo possono utilizzare la mail crittografata del whistleblower.
L'articolo Un Threat Actors Rivendica un attacco all’Italiana Telecontrol proviene da il blog della sicurezza informatica.
Ben Eater vs. Microsoft BASIC
[Ben Eater]’s breadboard 6502 computer is no stranger to these parts, so it was a bit of a surprise that when [Mark] wrote in asking us if we’d covered [Ben]’s getting MS BASIC running on the breadboard, that our answer was “no”. Well, that changes today!
This is a three-part video series, documenting how [Ben Eater] ports a 1977 version of MS BASIC to his 6502-based computer. The first video is all about just getting the BASIC up and working. It’s full of detail about how MS BASIC adapts to different architectures on the inside, and [Ben] essentially defines his own along the way.
Once he has BASIC working, the next two videos are about making it work not just with the serial terminal that he has attached, but also with the LCD display peripheral he has plugged into the breadboard. BASIC fans will not be surprised to see that it’s all about using POKE. But that ends up being to slow, so he extends it out with his own LCDPRINT command written in assembly.
Now that he can write a character to the LCD, he wants to be able to pass it a string: LCDPRINT “Hello world”. But that requires his command to be able to parse a string, and this has him diving down the rabbit hole into how MS BASIC parses strings, handles evals, and so on. If you want to know how MS BASIC works on the inside, this is the video for you. This video makes a lot of use of wozmon, which seems an almost ideal tool for this kind of low-level poking around.
All of this is done in [Ben]’s very well rehearsed, accessible, but pulling-no-punches style. Get ready to nerd out. All three of the videos are embedded just below the break.
While it’s not the Altair BASIC that Bill himself was writing about last week, it’s probably a direct descendent, and reading about the Altair version was what spurred [Mark Stevens] to send us the tip. Thanks!
youtube.com/embed/XlbPnihCM0E?…
youtube.com/embed/gOwi2p1pzVM?…
youtube.com/embed/aVVKgwr_SfQ?…
Inside an Edison Phonograph
If you think of records as platters, you are of a certain age. If you don’t remember records at all, you are even younger. But there was a time when audio records were not flat — they were drums, which was how the original Edison phonograph worked. [Our Own Devices] did a video earlier showing one of these devices, but since it was in a museum, he didn’t get to open it up. Lucky for us, he now has one of his own, and we get to see inside in the video below.
Ironically, Edison was deaf yet still invented the phonograph. While he did create the working phonograph — his self-identified most important invention — the original invention wasn’t commercially viable. You could record and playback audio on tin foil wrapped around a drum. But you couldn’t remove the foil without destroying it.
Edison was busy, but another inventor related to Bell created a similar system that used wax cylinders instead of foil. Edison’s vision for his invention didn’t include popular music, which hurt sales.
If you want to skip the history lesson — although it is well worth watching — you can skip to the 9-minute mark. You can hear the machine play and then see the box come off.
Oddly, people were recording things before they were able to play them back. Keeping a machine like this running can be quite a challenge.
youtube.com/embed/fFjpRdBtoBc?…
How Shrinking Feature Size Made Modern Wireless Work
If you’re living your life right, you probably know what as MOSFET is. But do you know the MESFET? They are like the faster, uninsulated, Schottky version of a MOSFET, and they used to rule the roost in radio-frequency (RF) silicon. But if you’re like us, and you have never heard of a MESFET, then give this phenomenal video by [Asianometry] a watch. In it, among other things, he explains how the shrinking feature size in CMOS made RF chips cheap, which brought you the modern cellphone as we know it.
The basic overview is that in the 1960s, most high-frequency stuff had to be done with discrete parts because the bipolar-junction semiconductors of the time were just too slow. At this time, MOSFETs were just becoming manufacturable, but were even slower still. The MESFET, without its insulating oxide layer between the metal and the silicon, had less capacitance, and switched faster. When silicon feature sizes got small enough that you could do gigahertz work with them, the MESFET was the tech of choice.
As late as the 1980s, you’d find MESFETs in radio devices. At this time, the feature size of the gates and the thickness of the oxide layer in MOSFETs kept them out of the game. But as CPU manufacturers pushed CMOS theses features smaller, not only did we get chips like the 8086 and 80386, two of Intel’s earliest CMOS designs, but the tech started getting fast enough for RF. And the world never looked back.
If you’re interested in the history of the modern monolithic RF ICs, definitely give the 18-minute video a watch. (You can skip the first three or so if you’re already a radio head.) If you just want to build some radio circuits, this fantastic talk from [Michael Ossmann] at the first-ever Supercon will make you an RF design hero. His secrets? Among them, making the most of exactly these modern everything-in-one-chip RF ICs so that you don’t have to think about that side of things too hard.
Thanks [Stephen] for the tip!
How a Tiny Relay Became a USB Swiss Army Knife
Meet the little board that could: [alcor6502]’s tiny USB relay controller, now evolved into a multifunction marvel. Originally built as a simple USB relay to probe the boundaries of JLCPCB’s production chops, it has become a compact utility belt for any hacker’s desk drawer. Not only has [alcor6502] actually built the thing, he even provided intstructions. If you happened to be at Hackaday in Berlin, you now might even own one, as he handed out twenty of them during his visit. If not, read on and build it yourself.
This thing is not just a relay, and that is what makes it special. Depending on a few solder bridges and minimal components, it shape-shifts into six different tools: a fan controller (both 3- and 4-pin!), servo driver, UART interface, and of course, the classic relay. It even swaps out a crystal oscillator for USB self-sync using STM32F042‘s internal RC – no quartz, less cost, same precision. A dual-purpose BOOT0 button lets you flash firmware and toggle outputs, depending on timing. Clever reuse, just like our mothers taught us.
It’s the kind of design that makes you want to tinker again. Fewer parts. More function. And that little smile when it just works. If this kind of clever compactness excites you too, read [alcor6502]’s build log and instructions here.
If You’re 3D Scanning, You’ll Want a Way To Work with Point Clouds
3D scanning is becoming much more accessible, which means it’s more likely that the average hacker will use it to solve problems — possibly odd ones. That being the case, a handy tool to have in one’s repertoire is a way to work with point clouds. We’ll explain why in a moment, but that’s where CloudCompare comes in (GitHub).
CloudCompare is an open source tool with which one can load up and do various operations on point clouds, including generating mesh models from them. Point clouds are what 3D scanners create when an object is scanned, and to become useful, those point clouds are usually post-processed into 3D models (specifically, meshes) like an .obj or .stl file.
We’ve gone into detail in the past about how 3D scanning works, what to expect from it, and taken a hands-on tour of what an all-in-one wireless scanner can do. But what do point clouds have to do with getting the most out of 3D scanning? Well, if one starts to push the boundaries of how and to what purposes 3D scanning can be applied, it sometimes makes more sense to work with point clouds directly instead of the generated meshes, and CloudCompare is an open-source tool for doing exactly that.
For example, one may wish to align and merge two or more different clouds, such as from two different (possibly incomplete) scans. Or, you might want to conduct a deviation analysis of how those different scans have changed. Alternately, if one is into designing wearable items, it can be invaluable to be able to align something to a 3D scan of a body part.
It’s a versatile tool with numerous tutorials, so if you find yourself into 3D scanning but yearning for more flexibility than you can get by working with the mesh models — or want an alternative to modeling-focused software like Blender — maybe it’s time to work with the point clouds directly.
A Look Inside MacPaint
Usually when we talk about retrocomputing, we want to look at — and in — some old hardware. But [Z→Z] has a different approach: dissecting MacPaint, the Apple drawing program from the 1980s.
While the program looks antiquated by today’s standards, it was pretty hot stuff back in the day. Things we take for granted today were big deals at the time. For example, being able to erase a part of something you drew prompted applause at an early public demo.
We enjoyed the way the program was tested, too. A software “monkey” was made to type keys, move things, and click menus randomly. The teardown continues with a look inside the Pascal and assembly code with interesting algorithms like how the code would fill an area with color.
The program has been called “beautifully organized,” and [Z→Z] examines that assertion. Maybe the brilliance of it has been overstated, but it did work and it did influence many computer graphics programs over the years.
We love digging through old source code. Even old games. If you do your own teardowns, be sure to send us a tip.
Disney’s Bipedal, BDX-Series Droid Gets the DIY Treatment
[Antoine Pirrone] and [Grégoire Passault] are making a DIY miniature re-imagining of Disney’s BDX droid design, and while it’s still early, there is definitely a lot of progress to see. Known as the Open Duck Mini v2 and coming in at a little over 40 cm tall, the project is expected to have a total cost of around 400 USD.
Bipedal robots are uncommon, and back in the day they were downright rare. One reason is that the state of controlled falling that makes up a walking gait isn’t exactly a plug-and-play feature.
Walking robots are much more common now, but gait control for legged robots is still a big design hurdle. This goes double for bipeds. That brings us to one of the interesting things about the Open Duck Mini v2: computer simulation of the design is playing a big role in bringing the project into reality.
It’s a work in progress but the repository collects all the design details and resources you could want, including CAD files, code, current bill of materials, and links to a Discord community. Hardware-wise, the main work is being done with very accessible parts: Raspberry Pi Zero 2W, fairly ordinary hobby servos, and an BNO055-based absolute orientation IMU.
So, how far along is the project? Open Duck Mini v2 is already waddling nicely and can remain impressively stable when shoved! (A “testing purposes” shove, anyway. Not a “kid being kinda mean to your robot” shove.)
Check out the videos to see it in action, and if you end up making your own, we want to hear about it, so remember to send us a tip!
8 Pins For Linux
We’ve seen a Linux-based operating system made to run on some widely varying pieces of hardware over the years, but [Dimity Grinberg]’s latest project may be one of the most unusual. It’s a PCB with 3 integrated circuits on it which doesn’t seem too interesting at first, but what makes it special is that all three of those chips are in 8-pin SOIC packages. How on earth can Linux run on 8-pin devices? The answer lies as you might expect, in emulation.
Two of the chips are easy to spot, a USB-to-serial chip and an SPI RAM chip. The processor is an STM32G0 series device, which packs a pretty fast ARM Cortex M0+ core. This runs a MIPS emulator that we’ve seen on a previous project, which is ripe for overclocking. At a 148 MHz clock it’s equivalent to a MIPS running at about 1.4 MHz, which is just about usable. Given that the OS in question is a full-featured Debian, it’s not running some special take on Linux for speed, either.
We like some of the hardware hacks needed to get serial, memory, and SD card, onto so few pins. The SD and serial share the same pins, with a filter in place to remove the high-frequency SPI traffic from the low-frequency serial traffic. We’re not entirely sure what use this machine could be put to, but it remains an impressive piece of work.
Lockdown Remote Control Project is Free and Open
If you flew or drove anything remote controlled until the last few years, chances are very good that you’d be using some faceless corporation’s equipment and radio protocols. But recently, open-source options have taken over the market, at least among the enthusiast core who are into squeezing every last bit of performance out of their gear. So why not take it one step further and roll your own complete system?
Apparently, that’s what [Malcolm Messiter] was thinking when, during the COVID lockdowns, he started his own RC project that he’s calling LockDownRadioControl. The result covers the entire stack, from the protocol to the transmitter and receiver hardware, even to the software that runs it all. The 3D-printed remote sports a Teensy 4.1 and off-the-shelf radio modules on the inside, and premium FrSky hardware on the outside. He’s even got an extensive folder of sound effects that the controller can play to alert you. It’s very complete. Heck, the transmitter even has a game of Pong implemented so that you can keep yourself amused when it’s too rainy to go flying.
Of course, as we alluded to in the beginning, there is a healthy commercial infrastructure and community around other open-source RC projects, namely ExpressLRS and OpenTX, and you can buy gear that runs those software straight out of the box, but it never hurts to have alternatives. And nothing is easier to customize and start hacking on than something you built yourself, so maybe [Malcolm]’s full-stack RC solution is right for you? Either way, it’s certainly impressive for a lockdown project, and evidence of time well spent.
Thanks [Malcolm] for sending that one in!
The Transputer in your Browser
We remember when the transputer first appeared. Everyone “knew” that it was going to take over everything. Of course, it didn’t. But [Oscar Toledo G.] gives us a taste of what life could have been like with a JavaScript emulator for the transputer, you can try in your browser.
If you don’t recall, the transputer was a groundbreaking CPU architecture made for parallel processing. Instead of giant, powerful CPUs, the transputer had many simple CPUs and a way to chain them all together. Sounds great, but didn’t quite make it. However, you can see the transputer’s influence on CPUs even today.
Made to work with occam, the transputer was built from the ground up for concurrent programming. Context switching was cheap, along with simple message passing and hardware scheduling.
The ersatz computer has a lot of messages in Spanish, but you can probably muddle through if you don’t hablar español. We did get the ray tracing example to work, but it was fairly slow.
Want to know more about the CPU? We got you. Of course, these days, you can emulate a transputer with nearly anything and probably outperform the original. What we really want to see is a GPU emulation.
First PCB with the Smallest MCU?
[Morten] works very fast. He has already designed, fabbed, populated, and tested a breakout board for the new tiniest microcontroller on the market, and he’s even made a video about it, embedded below.
You might have heard about this new TI ARM Cortex MO micro on these very pages, where we asked you what you’d do with this grain-of-rice-sized chunk of thinking sand. (The number one answer was “sneeze and lose it in the carpet”.)
From the video, it looks like [Morten] would design a breakout board using Kicad 8, populate it, get it blinking, and then use its I2C lines to make a simple digital thermometer demo. In the video, he shows how he worked with the part, from making a custom footprint to spending quite a while nudging it into place before soldering it carefully down.
But he nailed it on the first try, and honestly it doesn’t look nearly as intimidating as we’d feared, mostly because of the two-row layout of the balls. It actually looks easy enough to fan out. Because you can’t inspect the soldering work underneath the chip, he broke out all of the lines to a header to make it quick to check for shorts between those tiny little balls. Smart.
We love to see people trying out the newest hotness. Let us know down in the comments what new parts you’re trying out.
Thanks [Clint] for the tip!
youtube.com/embed/XSAPGh9um_k?…
Vintage Computer Festival East This Weekend
If you’re on the US East Coast, you should head on over to Wall, NJ and check out the Vintage Computer Festival East. After all, [Brian Kernighan] is going to be there. Yes, that [Brian Kernighan].
Events are actually well underway, and you’ve already missed the first few TRS-80 Color Computer programming workshops, but rest assured that they’re going on all weekend. If you’re from the other side of the retrocomputing fence, namely the C64 side, you’ve also got a lot to look forward to, because the theme this year is “The Sounds of Retro” which means that your favorite chiptune chips will be getting a workout.
[Tom Nardi] went to VCF East last year, so if you’re on the fence, just have a look at his writeup and you’ll probably hop in your car, or like us, wish you could. If when you do end up going, let us know how it was in the comments!
Supercon 2024: Quick High-Feature Boards With The Circuit Graver
These days, if you want to build something with modern chips and components, you probably want a custom PCB. It lets you build a neat and compact project that has a certain level of tidiness and robustness that you can’t get with a breadboard or protoboard. The only problem is that ordering PCBs takes time, and it’s easy to grow tired of shipping delays when you don’t live in the shadow of the Shenzhen board houses.
[Zach Fredin] doesn’t suffer this problem, himself. He’s whipping up high-feature PCBs at home with speed and efficiency that any maker would envy. At the 2024 Hackaday Supercon, he was kind enough to give a talk to explain the great engineering value provided by the Circuit Graver. (He was demoing it in the alley too, but you had to be there.)
youtube.com/embed/aGVqcYA3kkA?…
It’s always been possible to make PCBs at home. Many have experimented with irons and toner and etchant baths to varying levels of success. You can do great things if you invest in tools and upskilling, but fundamentally, it can be difficult to make good PCBs that do what you want. After all, there are a things that you might want out of your custom PCBs—fine traces a being prime among them. These can be challenging to do at home with traditional techniques.
[Zach’s] focus was on finding a way to make these “high feature” boards at home—specifically, referring to boards with an excellent minimum feature size. Right away, his talk shows off an example board, featuring an 0.5 mm-pitch DFN chip, paired with 0804 resistors and 0402 LEDs. [Zach] made this board in his apartment, using a machine of his own creation—the Circuit Graver.
You might be expecting some kind of laser-etching machine or a PCB mill, but the Circuit Graver is a little different. Instead of a high-speed spinning engraving head, it uses a pointy tool to scrape copper-clad boards to create the desired traces. [Zach] was inspired to go with this route due to the limitations he’d found during his experiences with traditional PCB milling machines. He found them be loud, messy, and slow, and limited in their resolution. He’d found it difficult to build designs with anything smaller than DIP or SOIC chips when relying on milled boards.
The Circuit Graver was spawned by a technique [Zach] developed years ago, when he started carving boards using a modified box cutter blade by hand, before realizing the same technique could benefit from the magic of Computer Numerical Control (CNC). Rather than move the tool yourself, why not have the computer do it more accurately?
The machine design itself is conventional, but packed with clever details, and built with eBay parts and 3D-printed components. [Zach] built a Cartesian motion platform to move the tool over a copper clad board, with X and Y axes for positioning and a Z axis to lift the tool when necessary and also control the downward pressure. There’s also a stepper motor for the tool, to keep the cutter lined up with the direction of the trace to be carved.
You could do this with a box-cutter blad, but that is not quite good enough for the resolution that [Zach] was hoping to achieve. To that end, he equipped the Circuit Graver with a carbide insert intended for use as lathe tooling. The tool has a 100 micron tip radius which can create a 0.2 mm trench in copper-clad board, right out of the box. That allows the creation of traces roughly around 8 mil or so. You can even sharpen the tooling and get it down to 0.1 mm or less, which is theoretically good enough for 4 mil spaces. That’s perfect for working with smaller feature size parts.
[Zach]’s talk provides a realistic assessment of the Circuit Graver’s real-world performance. Right now, it’s capable of carving 8/8 (0.2 mm) features on small boards quite well, while 6/6 (0.15 mm) features are “marginal.” The hope is to get down to 4/4 (0.1 mm) level with future upgrades. Speed is excellent, however—the Circuit Graver can carve good traces at 20-50 mm/s. For now, though, manual setup is still required—to ensure correct zeroing and that the tooling pressure is correct, for example.
It’s not something you’d use for production PCBs, per se—a real board house will always win for those sort of applications. However, for producing boards for quick prototyping, even with modern fine-featured components? It’s easy to see the value of the Circuit Graver. Imagine ordering some new parts and whipping up a unique project board just minutes or hours after you finish the design on your PC—it’s almost intoxicating to think about.
We actually featured the Circuit Graver on the blog last year—and there are design files on Hackaday.io for the curious. If you’re eager to start whipping up simple high-feature boards at home, it might be a build worth looking into!
Hackaday Podcast Episode 315: Conductive String Theory, Decloudified Music Players, and Wild Printing Tech
This week, Hackaday’s Elliot Williams and Kristina Panos met up across the (stupid, lousy) time zones to bring you the latest news, mystery sound, and of course, a big bunch of hacks from the previous week.
Again, no news is good news. On What’s That Sound, Kristina didn’t get close at all, but at least had a guess this time. If you think you can identify the sound amid all the talking, you could win a Hackaday Podcast t-shirt!
After that, it’s on to the hacks and such, beginning with a Dr. Jekyll and Mr. Hyde situation when it comes to a pair of formerly-cloud music players. We take a look at a crazy keyboard hack, some even crazier conductive string, and a perfectly cromulent list of 70 DIY synths on one wild webpage. Finally, we rethink body art with LEDs, and take a look at a couple of printing techniques that are a hundred years or so apart in their invention.
Check out the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!
html5-player.libsyn.com/embed/…
Download in DRM-free MP3 and savor at your leisure.
Where to Follow Hackaday Podcast
Places to follow Hackaday podcasts:
Episode 315 Show Notes:
News:
- No news is good news!
What’s that Sound?
Interesting Hacks of the Week:
- Open Source Framework Aims To Keep Tidbyt Afloat
- Can Hackers Bring Jooki Back To Life?
- DIY Split Keyboard Made With A Saw
- 70 DIY Synths On One Webpage
- Programmer’s Macro Pad Bangs Out Whole Functions
- Supercon 2024: Rethinking Body Art With LEDs
- Make DIY Conductive, Biodegradable String Right In Your Kitchen
Quick Hacks:
- Elliot’s Picks:
- The Magic Touch: A 555 Touch Switch
- Handheld 18650 Analyzer Scopes Out Salvaged Cells
- The Lowly Wall Wart Laid Bare
- A Forgotten Photographic Process Characterised
- Pictures From A High Altitude Balloon
- Kristina’s Picks:
Can’t-Miss Articles:
hackaday.com/2025/04/04/hackad…