[Alex] of YouTube channel [EastMakes] wrote into tell me about his fantastic QWERTY ‘hexpansion’ board for the 2024 EMF Tildagon badge, and [Alex], I’m super glad you did. The system works!

Let’s back up a bit. Essentially, the idea is to have a badge that can be used beyond a single camp, with the creation of expansion boards being the other main attraction. Our own [Jenny List] covered the badge in detail back in June 2024 when she got her hands on one.

Image by [EastMakes] via YouTube[Alex] started by importing the Tildagon into Fusion360 and designing a way for the keyboard to attach to it physically. He then modeled the keyboard after the Blackberry types that can be found on Ali using the official EMF buttons established in earlier badges.

This QWERTY hexpansion is based on the RP2040, which is soldered around back and visible through the 3D-printed backplate. In order for the 90°-oriented board to align with the… not-90° connector, [Alex] built a little meander into the PCB.

The default OS on the Tildagon doesn’t know natively what to do with the serial messages from the keyboard, so [Alex] wrote an application that reads them in and decodes them. Be sure to check out the build and walk-through video after the break.

youtube.com/embed/5mLt09UtY2E?…

More, Children, Is Just a Slot Away

[New-Concentrate6308] is cooking up something new in the form of a 50% keyboard with a cartridge slot! The custom layout has been dubbed Esul, and has the Esc to the left of Tab, among other other interesting features.

Image by [New-Concentrate6308] via redditInspired by [mujimanic]’s giga 40, the cartridges add modules to the keyboard. If you want a screen, just slot one in. You could also up the RGB, or add something useful like a knob, or even some more keys.

You may have noticed the lack of an up arrow key. It’s there, it’s just a tap away on the right Shift, which if you hold it down, becomes Shift.

This thing is not going to be for everyone, but that’s not the point. (Is it ever?) The point is that [New-Concentrate6308] wanted a fun keyboard project and found it in spades. Plus, it looks fantastic.

The Centerfold: At the Corner of Practical and Paradise

Image by [jamesvyn] via redditDo I really need to say anything here? Can we all just enjoy the beauty of Switzerland for a moment?

[jamesvyn] recently switched from two monitors to a wide boi and is loving every minute of it. I particularly like the base — something about that shape is quite pleasing.

I bet it was difficult to find a wallpaper that does the view any justice. I have almost no details here, but I can tell you that the pager-looking thing near the mouse is a Pomodoro timer. And that’s an interesting wrist rest block-thing. Not sure I could use that for an extended period of time. Could you?

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: the Oliver

Today, we can not only see what we type as we type it, we can do things like correct entire words with a simple key combination (Ctrl + Backspace).
An Oliver no. 2 machine. Image via The Antikey Chop
In the late 1800s, though, seeing what you were typing as well as we do now was a pipe dream until the Oliver typewriter came along. It is thought that inventor Rev. Thomas Oliver sought to create a machine that would make his sermons more legible.

Oliver typewriters were quite distinct with their three-row keyboards and so-called ‘batwing’ typebar arrangement. This style, wherein the typebars struck the platen downward instead of upward made it a partially visible typewriter. Since it would be years until fully visible Underwoods and Royals came along, this made the Oliver quite the sought-after machine.

Unfortunately, this three-row design did not stay in vogue. As the four-row, single-Shift layout became standard, the writing was on the wall for the Oliver. Adding a fourth row of keys would have meant even taller batwings and an even heavier machine.

Some Oliver models were re-badged for foreign markets and carried names such as Courier, Stolzenberg, Jwic, Fiver, and Revilo. Stateside, the No. 2 was rebranded by Sears & Roebuck as the Woodstock.

Finally, the Clicks Keyboard Case Comes to Android

Do you miss your Blackberry or Sidekick? I miss my Palm Centro’s bubble-poppy keyboard, and I’d love to have a Sidekick or something comparable today. Or like, anything with a keyboard.

Image by [Clicks] via New AtlasIf you don’t mind having an even bigger phone, then the dream is alive in the form of the Clicks keyboard case, which has finally made its way to Android phones beginning with the the Google Pixel 9 and 9 Pro.

The Android Clicks cases will be even better than those created for the iPhone, with upgrades like larger, backlit, domed metal keys, a flexible TPU shell, and a felt lining to protect the phone. Also, there will be Qi wireless charging right through the case, which will accept magnetic accessories as well.

While cases for the Pixel 9s are available for pre-order at $99, there is also the option to reserve Clicks for the 2024 Motorola razr as well as the Samsung Galaxy S25. Check out the overview video if you want to know more, and you can also see it in action on the aforementioned phones.

Or — hear me out — we could just get devices with physical keyboards again. There’s obviously a demand. Your move, manufacturers.

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.

hackaday.com/2025/03/11/keebin…

Unless you’ve got an especially small lap, calling the Toshiba Libretto a laptop is a bit of a stretch. The diminutive computers from the mid-1990s had a lot of the usual laptop features, but in an especially compact and portable case that made them a great choice for anyone with an on-the-go lifestyle.

Fast-forward thirty years or so, and the remaining Librettos haven’t fared too well. Many of them have cases that crumble at the slightest touch, which is what led [polymatt] to undertake this meticulous case replacement. The effort started with a complete teardown; luckily, the lower aluminum-alloy shell was in fine shape, but the upper case parts were found to be almost too deteriorated to handle. Still, with a little patience and the judicious application of tape, [polymatt] was able to scan the case pieces on a flatbed scanner and import them into his CAD package. Great tip on the blue-tack for leveling the parts for accurate scanning, by the way.

After multiple rounds of printing and tweaking, [polymatt] had a case good enough to reassemble the Libretto. Unfortunately, the previous owner left an unwanted gift: a BIOS password. Disconnecting the CMOS battery didn’t reset it, but a little research told him that shorting a few pins on the parallel port on the machine’s dock should do the trick. It was a bit involved, requiring the design and subsequent bodging of a PCB to fit into the docking port connector, but in the end he was able to wake up a machine to all its Windows 95 glory. Better get patching.

In a time when laptops were more like lap-crushers, the Libretto was an amazing little machine, and thirty years on, they’re well worth saving from the scrap heap. Hats off to [polymatt] for the effort to save this beauty, and if he needs tips on reading data from any PCMCIA cards that may have come with it, we’ve got him covered.

youtube.com/embed/AdeswJreJ98?…

hackaday.com/2025/03/11/tiny-l…

In the world of programming languages it often feels like being stuck in a Groundhog Day-esque loop through purgatory, as effectively the same problems are being solved over and over, with previous solutions forgotten and there’s always that one jubilant inventor stumbling out of a darkened basement with the One True Solution to everything that plagues this world beset by the Unspeakable Horror that is the C programming language.

As the latest entry to pledge its fealty at the altar of the Church of the Holy Memory Safety, TrapC promises to fix C, while also lambasting Rust for allowing that terrible unsafe keyword. Of course, since this is yet another loop through purgatory, the entire idea that the problem is C and some perceived issue with this nebulous ‘memory safety’ is still a red herring, as pointed out previously.

In other words, it’s time for a fun trip back to the 1970s when many of the same arguments were being rehashed already, before the early 1980s saw the Steelman language requirements condensed by renowned experts into the Ada programming language. As it turns out, memory safety is a miniscule part of a well-written program.

It’s A Trap

Pretty much the entire raison d’être for new programming languages like TrapC, Rust, Zig, and kin is this fixation on ‘memory safety’, with the idea being that the problem with C is that it doesn’t check memory boundaries and allows usage of memory addresses in ways that can lead to Bad Things. Which is not to say that such events aren’t bad, but because they are so obvious, they are also very easy to detect both using static and dynamic analysis tools.

As a ‘proposed C-language extension’, TrapC would add:

• memory-safe pointers.
• constructors & destructors.
• the trap and alias keywords.
• Run-Time Type Information.

It would also remove:

• the goto and union keywords.

The author, Robin Rowe, freely admits to this extension being ‘C++ like’, which takes us right back to 1979 when a then young Danish computer scientist (Bjarne Stroustrup) created a C-language extension cheekily called ‘C++’ to denote it as enhanced C. C++ adds many Simula features, a language which is considered the first Object-Oriented (OO) programming language and is an indirect descendant of ALGOL. These OO features include constructors and destructors. Together with (optional) smart pointers and the bounds-checked strings and containers from the Standard Template Library (STL) C++ is thus memory safe.

So what is the point of removing keywords like goto and union? The former is pretty much the most controversial keyword in the history of programming languages, even though it derives essentially directly from jumps in assembly language. In the Ada programming language you also have the goto keyword, with it often used to provide more flexibility where restrictive language choices would lead to e.g. convoluted loop constructs to the point where some C-isms do not exist in Ada, like the continue keyword.

The union keyword is similarly removed in TrapC, with the justification that both keywords are ‘unsafe’ and ‘widely deprecated’. Which makes one wonder how much real-life C & C++ code has been analyzed to come to this conclusion. In particular in the field of embedded- and driver programming with low-level memory (and register) access the use of union is widely used for the flexibility it offers.

Of course, if you’re doing low-level memory access you’re also free to use whatever pointer offset and type casting you require, together with very unsafe, but efficient, memcpy() and similar operations. There is a reason why C++ doesn’t forbid low-level access without guardrails, as sometimes it’s necessary and you’re expected to know what you’re doing. This freedom in choosing between strict memory safety and the untamed wilds of C is a deliberate design choice in C++. In embedded programming you tend to compile C++ with both RTTI & exceptions disabled as well due to the overhead from them.

Don’t Call It C++

Effectively, TrapC adds RTTI, exceptions (or ‘traps’), OO classes, safe pointers, and similar C++ features to C, which raises the question of why it’s any different, especially since the whitepaper describes TrapC and C++ code usually looking the same as a feature. Here the language seems to regard itself as being a ‘better C++’, mostly in terms of exception handling and templates, using ‘traps’ and ‘castplates’. Curiously there’s not much focus on “resource allocation is initialization” (RAII) that is such a cornerstone of C++.

Meanwhile castplates are advertised as a way to make C containers ‘typesafe’, but unlike C++ templates they are created implicitly using RTTI and one might argue somewhat opaque (C++ template-like) syntax. There are few people who would argue that C++ template code is easy to read. Of note here is that in embedded programming you tend to compile C++ with both RTTI & exceptions disabled due to the overhead from them. The extensive reliance on RTTI in TrapC would seem to preclude such an option.

Circling back on the other added keyword, alias, this is TrapC’s way to providing function overloading, and it works like a C preprocessor #define:
void puts(void* x) alias printf("{}n",x);
Then there is the new trap keyword that’s apparently important enough to be captured in the extension’s name. These are offered as an alternative to C++ exceptions, but the description is rather confusing, other than that it’s supposedly less complicated and does not support cascading exceptions up the stack. Here I do not personally see much value either way, as like so many C++ developers I loathe C++ exceptions with the fire of a thousand Suns and do my utmost to avoid them.

My favorite approach here is found in Ada, which not only cleanly separates functions and procedures, but also requires, during compile time, that any return value from a function is handled, and implements exceptions in a way that is both light-weight and very informative, as I found for example while extensively using the Ada array type in the context of a lock-free ring buffer. During testing there were zero crashes, just the program bailing out with an exception due to a faulty offset into the array and listing the exact location and cause, as in Ada everything is bound-checked by default.

Memory Safety

Much of the safety in TrapC would come from managed pointers, with its author describing TrapC’s memory management as ‘automatic’ in a recent presentation at an ISO C meeting. Pointers are lifetime-managed, but as the whitepaper states, the exact method used is ‘implementation defined’, instead of reference counting as in the C++ specification.

Yet none of this matters in the context of actual security issues. As I noted in 2024, the ‘red herring’ part refers to the real-life security issues that are captured in CVEs and their exploitation. Virtually all of the worst CVEs involve a lack of input validation, which allows users to access data in ‘restricted’ folders and gain access to databases and other resources. None of which involve memory safety in any way or form, and thus the onus lies on preventing logic errors, solid input validation and preventing lazy or inattentive programmers from introducing the next world-famous CVE.

As a long-time C & C++ programmer, I have come to ‘love’ the warts in these languages as well as the lack of guardrails for the freedom they provide. Meanwhile I have learned to write test cases and harnesses to strap my code into for QA sessions, because the best way to validate code is by stressing it. Along the way I have found myself incredibly fond of Ada, as its focus on preventing ambiguity and logic errors is self-evident and regularly keeps me from making inattentive mistakes. Mistakes that in C++ would show up in the next test and/or Valgrind cycle followed by a facepalm moment and recompile, yet somehow programming in Ada doesn’t feel more restrictive than writing in C++.

Thus I’ll keep postulating that the issues with C were already solved in 1983 with the introduction of Ada, and accepting this fact is the only way out of this endless Groundhog Day purgatory.

hackaday.com/2025/03/11/trapc-…

Si sa, il settore sanitario si conferma essere decisamente fuzzy per quanto riguarda l’aspetto della gestione dei dati personali. Soprattutto quando si parla di sicurezza, pressoché ogni istruttoria del Garante Privacy si trova ad affrontare l’affermazione all’interno delle memorie difensive relative a delle “difficoltà organizzative”. Le quali sono più che comprensibili durante il corso dell’emergenza Covid, ma oramai non è che possono fondare una scusa sempiterna, distorcendo il tempo alla pari di un wormhole a comando simile al buco portatile della ACME.

Eppure, il sottotesto drammatico ricorrente è un qui salviamo vite, non c’è tempo per la privacy. Falsa argomentazione, perpetrata per ignoranza o malafede, ma terribilmente suadente. E stavolta rivela una capacità di gestione del tempo pari a quella del Bianconiglio. Gran parte del settore sanitario – pubblico o privato che sia – ha coltivato l’abitudine di porre la protezione dei dati in secondo piano. Anzi: in un piano che forse non può nemmeno ambire al podio.

Si può auspicare che nel caso di interventi sanzionatori da parte del Garante Privacy nel settore pubblico l’attenzione alla responsabilizzazione degli apicali venga rilevata da opportune indagini della magistratura contabile, mentre per il settore privato saranno gli stakeholder a formulare i rilievi del caso.

Se questo porterà, nel tempo, ad una maggiore attenzione agli aspetti della privacy da parte di chi decide, resterà sempre il problema di fondo: una cultura della privacy incompiuta o distorta. In pratica, quella che induce l’utenza dei servizi a sottostimare le conseguenze di un data breach ed è effetto di una narrazione da parte di chi ovviamente ha voluto far passare proprio l’idea che in fondo una violazione dei dati sanitari possa essere un niente di che in quanto non si tratta di segreti di Stato.

I principali artefici di questa narrazione sono però gli stessi soggetti che hanno tutto da guadagnare dall’effetto di una deresponsabilizzazione diffusa, dal momento che il conto di una mancata o pessima gestione della sicurezza sarà pagato per lo più dagli interessati coinvolti. I quali avranno anche meno critiche da porre in caso di illeciti o violazioni, e potranno accettare di buon grado di riqualificare il tutto come disguidi o burocrazie.

Eppure, l’opera di svilire l’autorità di controllo o ridurre privacy e sicurezza come meri adempimenti burocratici ha contribuito ad aumentare la frequenza delle violazioni e ad aggravarne le conseguenze negative.

Cosa succede quando vengono violate le proprie analisi del sangue

Prendiamo infatti il caso di un data breach che ha coinvolto delle analisi del sangue. L’argomento fantoccio impiegato per minimizzare l’accaduto è: che problema c’è se il cybercriminale conosce il mio emocromo?

Peccato però che siano presenti dati personali che:

• identificano l’interessato (nome, cognome, codice fiscale);
• consentono di contattarlo (solitamente e-mail e telefono);
• rivelano informazioni relative allo stato di salute (esito delle analisi);

ma non solo. Infatti, è possibile trarre informazioni dal semplice fatto di aver svolto delle analisi in quella determinata struttura sanitaria e prevedere, ad esempio, che l’interessato stia attendendo una comunicazione da parte della struttura.

Questo è un elemento di valore per un cybercriminale il quale se ne potrà giovare per organizzare campagne mirate di phishing e confidare in una maggiore efficacia delle leve impiegate. L’elemento dell’aspettativa espone infatti l’interessato a ritenere come maggiormente affidabile una comunicazione contraffatta per conto della struttura sanitaria presso cui ha svolto delle analisi e non farsi troppe domande a riguardo

In pratica: quel non essere sorpreso nel ricevere quella comunicazione comporta minori cautele da parte del destinatario. E questo è noto al cybercriminale. Così, la comunicazione sarà impiegata come vettore d’attacco, potendo contare proprio su una maggiore probabilità che degli interessati poco accorti o inconsapevoli – poiché non allertati o anestetizzati dalla narrativa del ma che vuoi che sia – vadano a cliccare un link o un allegato malevolo.

Beninteso, questo è solo uno dei molti esempi possibili perché occorre sempre pensare al peggiore utilizzo dei dati violati da parte di un malintenzionato (*) per essere in grado di adottare le cautele più adeguate ed essere così in grado di mitigare le conseguenze negative di una violazione. Motivo per cui una comunicazione di data breach ai sensi dell’art. 34 GDPR è un adempimento fondamentale.

(*) l’unico limite è la fantasia e la motivazione dell’attaccante. Nulla toglie che questi possa avvalersi dell’indirizzo dell’abitazione, o altrimenti spacciarsi per un operatore sanitario (è sufficiente una ricerca online per avere alcuni nomi utili a tale scopo) che deve dare una comunicazione molto urgente per acquisire facilmente la fiducia di qualche familiare particolarmente preoccupato e farsi aprire ogni porta. O consegnare altri documenti. O chissà cosa. Ricorda nulla il “So cosa hai fatto”?

Solo andando oltre la narrazione di un’anticultura della privacy è però possibile alimentare una maggiore sensibilità diffusa da parte di tutti gli stakeholder coinvolti, primi fra tutti gli interessati i quali dovranno pretendere un approccio responsabile alla protezione dei propri dati personali in ambito sanitario.

Attenzione, però: la consapevolezza rende immuni alle scuse di deresponsabilizzazione.

Anche a quelle che ci siamo raccontati o a cui vorremmo tanto credere.

A ciascuno il suo

Tutto qui? Non proprio. In fondo quando c’è un problema diffuso – e questo è il caso – si può sempre scegliere se essere parte del problema, o altrimenti operarsi per risolverlo. Beninteso: nel caso si opti per la comodità dell’inerzia, si è comunque parte del problema.

Bisogna quindi fare i conti con la realtà dei fatti: se lo stato dell’arte piace, ben vengano attacchi e ogni conseguenza negativa ulteriore. Accettando anche tutte quelle ipotesi in cui sono colpiti o i propri interessi o quelli dei propri cari.

Per coerenza, che lo si dichiari senza problemi a questo punto. In fondo non sono queste le persone che si vantano di non avere niente da nascondere? Che facciano di conseguenza un bel virtue signaling sulla pelle delle vittime di una violazione di sicurezza dicendo che in fondo quel data breach non è niente di che così come non è niente di che l’esporsi a tutti i pericoli che ne derivano.

Chissà se si capirà prima o poi che la privacy riguarda chi non ha nulla da nascondere ma tutto da proteggere.

L'articolo Ma che data breach, mi hanno solo fregato le analisi del sangue! proviene da il blog della sicurezza informatica.

L'idea meravigliosa di Von Der Leyen: se la NATO non interessa più agli USA, paghiamo tutto noi pur di restare negli anni '50. E poi l'idea meravigliosa del Parlamento di Sua Maestà britannica per "superare" il GDPR.

spreaker.com/episode/dk-9x21-c…

Popular Science has an excellent article on how Josephine Cochrane transformed how dishes are cleaned by inventing an automated dish washing machine and obtaining a patent in 1886. Dishwashers had been attempted before, but hers was the first with the revolutionary idea of using water pressure to clean dishes placed in wire racks, rather than relying on some sort of physical scrubber. The very first KitchenAid household dishwashers were based on her machines, making modern dishwashers direct descendants of her original design.
Josephine Cochrane (née Garis)
It wasn’t an overnight success. Josephine faced many hurdles. Saying it was difficult for a woman to start a venture or do business during this period of history doesn’t do justice to just how many barriers existed, even discounting the fact that her late husband was something we would today recognize as a violent alcoholic. One who left her little money and many debts upon his death, to boot.

She was nevertheless able to focus on developing her machine, and eventually hired mechanic George Butters to help create a prototype. The two of them working in near secrecy because a man being seen regularly visiting her home was simply asking for trouble. Then there were all the challenges of launching a product in a business world that had little place for a woman. One can sense the weight of it all in a quote from Josephine (shared in a write-up by the USPTO) in which she says “If I knew all I know today when I began to put the dishwasher on the market, I never would have had the courage to start.”

But Josephine persevered and her invention made a stir at the 1893 World’s Fair in Chicago, winning an award and mesmerizing onlookers. Not only was it invented by a woman, but her dishwashers were used by restaurants on-site to clean tens of thousands of dishes, day in and day out. Her marvelous machine was not yet a household device, but restaurants, hotels, colleges, and hospitals all saw the benefits and lined up to place orders.

Early machines were highly effective, but they were not the affordable, standard household appliances they are today. There certainly existed a household demand for her machine — dishwashing was a tedious chore that no one enjoyed — but household dishwashing was a task primarily done by women. Women did not control purchasing decisions, and it was difficult for men of the time (who did not spend theirs washing dishes) to be motivated about the benefits. The device was expensive, but it did away with a tremendous amount of labor. Surely the price was justified? Yet women themselves — the ones who would benefit the most — were often not on board. Josephine reflected that many women did not yet seem to think of their own time and comfort as having intrinsic value.

Josephine Cochrane ran a highly successful business and continued to refine her designs. She died in 1913 and it wasn’t until the 1950s that dishwashers — direct descendants of her original design — truly started to become popular with the general public.

Nowadays, dishwashers are such a solved problem that not only are they a feature in an instructive engineering story, but we rarely see anyone building one (though it has happened.)

We have Josephine Cochrane to thank for that. Not just her intellect and ingenuity in coming up with it, but the fact that she persevered enough to bring her creation over the finish line.

hackaday.com/2025/03/11/joseph…

Since the beginning of the year, we’ve been tracking in our telemetry a new wave of DCRat distribution, with paid access to the backdoor provided under the Malware-as-a-Service (MaaS) model. The cybercriminal group behind it also offers support for the malware and infrastructure setup for hosting the C2 servers.

Distribution

The DCRat backdoor is distributed through the YouTube platform. Attackers create fake accounts or use stolen ones, then upload videos advertising cheats, cracks, gaming bots and similar software. In the video description is a download link to the product supposedly being advertised. The link points to a legitimate file-sharing service where a password-protected archive awaits, the password for which is also in the video description.

YouTube video ad for a cheat and crack

Instead of gaming software, these archives contain the DCRat Trojan, along with various junk files and folders to distract the victim’s attention.

Archives with DCRat disguised as a cheat and crack

Backdoor

The distributed backdoor belongs to a family of remote access Trojans (RATs) dubbed Dark Crystal RAT (DCRat for short), known since 2018. Besides backdoor capability, the Trojan can load extra modules to boost its functionality. Throughout the backdoor’s existence, we have obtained and analyzed 34 different plugins, the most dangerous functions of which are keystroke logging, webcam access, file grabbing and password exfiltration.

DCRat builder plugins on the attackers’ site

Infrastructure

To support the infrastructure, the attackers register second-level domains (most often in the RU zone), which they use to create third-level domains for hosting the C2 servers. The group has registered at least 57 new second-level domains since the start of the year, five of which already serve more than 40 third-level domains.

A distinctive feature of the campaign is the appearance of certain words in the second-level domains of the malicious infrastructure, such as “nyashka”, “nyashkoon”, “nyashtyan”, etc. Users interested in Japanese pop culture will surely recognize these slang terms. Among anime and manga fans, “nyasha” has come to mean “cute” or “hon”, and it’s this word that’s most often seen in the second-level domains.

C2 server addresses with characteristic naming approach

Victims

Based on our telemetry data since the beginning of 2025, 80% of DCRat samples using such domains as C2 servers were downloaded to the devices of users in Russia. The malware also affected a small number of users from Belarus, Kazakhstan and China.

Conclusion

Kaspersky products detect the above-described samples with the verdict
Backdoor.MSIL.DCRat.
Note that we also encounter campaigns distributing other types of malware (stealers, miners, loaders) through password-protected archives, so we strongly recommend downloading game-related software only from trusted sources.

securelist.com/new-wave-of-att…

Il mondo della cybersecurity potrebbe essere di fronte a un nuovo possibile attacco che avrebbe colpito una delle icone dell’automotive britannico. Jaguar Land Rover (JLR), il prestigioso produttore di veicoli di lusso, sarebbe stato menzionato in un presunto Data Breach rivendicato da un cybercriminale noto come “Rey”, che affermerebbe di aver ottenuto e pubblicato dati aziendali altamente sensibili.

Al momento, non possiamo confermare la veridicità della notizia, poiché l’organizzazione non ha ancora rilasciato alcun comunicato stampa ufficiale sul proprio sito web riguardo l’incidente. Pertanto, questo articolo deve essere considerato come ‘fonte di intelligence’.

Dettagli del post nel Forum Underground

Secondo quanto riportato nel post sul Dark Web, il presunto data breach includerebbe circa 700 documenti interni, tra cui development logs, tracking data e persino codice sorgente. Inoltre, si parla di un set di dati dei dipendenti che conterrebbe informazioni sensibili come nome utente, e-mail, nome visualizzato, fuso orario e altro ancora.

Se queste informazioni fossero autentiche, potrebbero includere dati riservati su progetti in sviluppo, strategie aziendali e informazioni personali dei dipendenti, con possibili rischi legati a furti d’identità, attacchi di spear phishing e spionaggio industriale. Quali sarebbero le conseguenze per JLR? Se il leak contenesse informazioni su modelli futuri o innovazioni tecnologiche, il danno potrebbe estendersi ben oltre il singolo attacco, impattando la competitività dell’azienda nel lungo periodo.

Un attacco mirato o una falla sfruttata?

Al momento, non ci sono conferme ufficiali sulla dinamica dell’attacco, né sulla sua autenticità. Non è chiaro se si tratti di un’infiltrazione mirata o se Rey avrebbe semplicemente sfruttato una vulnerabilità nei sistemi di JLR. Tuttavia, le informazioni circolate suggerirebbero una possibile preparazione accurata e un’azione coordinata. Se vero, sarebbe un segnale allarmante per l’intero settore automotive, sempre più esposto alle minacce informatiche.

Un segnale d’allarme per il settore automotive?

Se confermato, questo attacco non sarebbe un caso isolato: il settore automobilistico è sempre più nel mirino dei cybercriminali, che vedono nelle aziende automotive un’enorme quantità di dati preziosi e infrastrutture critiche da compromettere. Con l’avvento dei veicoli connessi e delle supply chain digitalizzate, il rischio di intrusioni informatiche diventa sempre più elevato.

Conclusione

Ancora una volta, se queste informazioni fossero veritiere, dimostrerebbero quanto sia cruciale adottare strategie di sicurezza avanzate e rafforzare le misure di protezione per prevenire fughe di dati e attacchi devastanti. La domanda che rimane aperta è: quanto è davvero preparato il settore automotive a contrastare questa escalation di 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 Jaguar Land Rover nel mirino: un Threat Actor rivendica la pubblicazione di dati riservati! proviene da il blog della sicurezza informatica.

How many cars go down your street each day? How fast were they going? What about folks out on a walk or people riding bikes? It’s not an easy question to answer, as most of us have better things to do than watch the street all day and keep a tally. But at the same time, this is critically important data from an urban planning perspective.

Of course, you could just leave it to City Hall to figure out this sort of thing. But what if you want to get a speed bump or a traffic light added to your neighborhood? Being able to collect your own localized traffic data could certainly come in handy, which is where TrafficMonitor.ai from [glossyio] comes in.

This open-source system allows the user to deploy an affordable monitoring device that will identify vehicles and pedestrians using a combination of machine learning object detection and Doppler radar. The system not only collects images of all the objects that pass by but can even determine their speed and direction. The data is stored and processed locally and presented via a number of graphs through the system’s web-based user interface.

While [glossyio] hopes to sell kits and even pre-built monitors at some point, you’ll have to build the hardware yourself for now. The documentation recommends a Raspberry Pi 5 for the brains of your monitor, backed up by a Coral AI Tensor Processing Unit (TPU) to help process the images coming in via the Pi Camera Module 3.

Technically, the OPS243-A Doppler radar sensor is listed as optional if you’re on a tight budget, but it looks like you’ll lose speed and direction sensing without it. Additionally, there’s support for adding an air quality sensor to see what all those passing cars are leaving behind.

This isn’t the first time we’ve seen the Raspberry Pi used as an electronic traffic cop, but it’s undoubtedly the most polished version of the concept we’ve come across. You might consider passive radar, too.

hackaday.com/2025/03/11/homebr…

Nel 2021, un team di ricercatori composto da scienziati e specialisti della sicurezza informatica ha scoperto una vulnerabilità nel Great Firewall cinese, denominata Wallbleed (che deriva dal famigerato problema Heartbleed in OpenSSL). Per studiare il funzionamento interno del firewall è stata sfruttata una vulnerabilità legata alla fuga di dati.

Nonostante il nome, gli esperti sottolineano che il problema non ha nulla a che fare con l’Heartbleed originale. La vulnerabilità è anche legata alla lettura fuori dai limiti, ma grazie a questo aiuto i ricercatori sono riusciti a rivelare solo 125 byte alla volta.

Ricordiamo che il “Grande Firewall Cinese” è apparso alla fine degli anni ’90 e nel tempo è diventato sempre più complesso. Il suo scopo principale è impedire ai cittadini cinesi di visitare determinati siti web stranieri e rallentare il traffico internet legittimo tra la Cina e i paesi stranieri.

In genere, il ruolo del Grande Firewall cinese è quello di filtrare e bloccare i contenuti intercettando le richieste DNS e fornendo risposte non valide che reindirizzano gli utenti lontano da determinati siti.

La vulnerabilità Wallbleed è stata individuata nel sottosistema di iniezione DNS, responsabile della generazione di false risposte DNS quando un utente dalla Cina tenta di visitare risorse proibite.

Quando una persona tenta di accedere a un sito web vietato, il suo dispositivo richiede l’indirizzo IP del dominio tramite DNS per stabilire una connessione con esso. Il sistema rileva e intercetta questa richiesta DNS e invia all’utente una risposta DNS con un indirizzo IP falso che non porta da nessuna parte.

La vulnerabilità Wallbleed è causata da un bug nel parser delle query DNS che, in determinate condizioni, restituisce involontariamente fino a 125 byte di dati aggiuntivi dalla memoria al client insieme alla risposta. Ciò significa che i dati fuoriuscivano dalle macchine che controllavano le query DNS e che probabilmente era necessario bloccarle. Grazie a una progettazione accurata delle query DNS, i ricercatori sono riusciti a ottenere 125 byte di memoria dai server del Great Firewall che controllavano tali query.

Si noti che il “Grande Firewall cinese” utilizza da molti anni iniezioni DNS per implementare il filtraggio e che almeno tre di questi sistemi operano contemporaneamente. Esistono però altri sottosistemi. Di conseguenza, anche se l’utente riesce a ottenere una risposta DNS corretta, vengono attivati ​​altri meccanismi e l’accesso rimane comunque bloccato.

Nel loro rapporto, i ricercatori sottolineano che la vulnerabilità Wallbleed “ha fornito una visione senza precedenti del Grande Firewall cinese” e ha contribuito notevolmente al suo studio. In particolare, Wallbleed è stato in grado di estrarre i dati sul traffico di rete in testo chiaro, di comprendere per quanto tempo i byte rimangono nella memoria (solitamente da zero a cinque secondi) e di trarre conclusioni sull’architettura del processore (x86_64).

È stato inoltre scoperto che alcuni dispositivi intermediari vulnerabili erano in grado di intercettare il traffico proveniente da centinaia di milioni di indirizzi IP in Cina. Vale a dire che, come previsto, elaborano il traffico proveniente da tutto il Paese. Vale la pena notare che in passato sono stati condotti vari studi, ma gli esperti del Great Firewall Report sostengono che in precedenza non si sapeva molto sui dispositivi intermedi e sulla struttura interna del firewall.

Ad esempio, nel 2010, su Twitter è stato pubblicato uno script di una sola riga che, grazie a un difetto del DNS, consentiva di visualizzare 122 byte della memoria del Great Firewall cinese. Questo problema è stato risolto solo nel novembre 2014. Ora, i ricercatori hanno utilizzato una macchina presso l’Università del Massachusetts ad Amherst per eseguire Wallbleed ininterrottamente per monitorare l’infrastruttura del firewall tra ottobre 2021 e marzo 2024. Grazie a ciò è stato possibile scoprire come viene supportato il Great Firewall of China.

Il rapporto includeva infine la vulnerabilità Wallbleed v1, presente prima della prima patch, e Wallbleed v2, una nuova iterazione dello stesso bug che ha consentito agli esperti di studiare il firewall fino a marzo 2024, dopodiché il bug è stato finalmente risolto.

L'articolo Wallbleed: La Falla Del Great Firewall Cinese che ha Svelato Molto Sul Suo Funzionamento proviene da il blog della sicurezza informatica.