With so much data being thrown at our eyeballs these days, it’s worryingly easy for the actually important stuff to slip by occasionally. So when [Liam Jackson] wanted a way to visualize the number of test failures popping up in the continuous integration system at work, he went with a novel but effective solution — universal motorcycle tachometers.

It turns out these little gauges can be had for under $10 a piece from the usual overseas retailers, and are very easy to drive with a microcontroller. As [Liam] explains, all you need to do other than providing them with 12 volts, is feed them a PWM signal. Even though the gauges are designed for a 12 V system, they apparently don’t have any problem responding to the 5 V logic level from the Arduino’s pins.

As for the frequency he says that 1,000 RPM corresponds to 16.66 Hz, so you can just multiply up from there to show whatever number you wish. That said, [Liam] warns that the gauges draw several hundred milliamps once the needle gets into the two digit range, so keep that in mind. Conveniently, those number happen to be in red anyway…

For his particular application, [Liam] put three of the gauges together to create a very handsome dashboard. If you want to recreate his setup exactly he’s made the STLs available for the gauge cluster housing. Note the small OLED at the center, this offers a way to show a bit more context than the three analog gauges alone can express, especially if you’ve got an application where you might be switching between multiple data sources.

Over the years we’ve seen several projects that repurposed analog gauges of various types, often for showing computer performance, but they generally involved having to drive the galvanometers directly. That these tachometers can simply be fed a simple digital signal should make implementing them into your project much easier.

hackaday.com/2025/01/18/puttin…

Buried in a talk on AI from an artist who is doing cutting-edge video work was the following nugget that entirely sums up the zeitgeist: “The tools are changing so fast that artists can’t keep up with them, let alone master them, before everyone is on to the next.” And while you might think that this concern is only relevant to those who have to stay on the crest of the hype wave, the deeper question resounds with every hacker.

When was the last time you changed PCB layout software or refreshed your operating system? What other tools do you use in your work or your extra-curricular projects, and how long have you been using them? Are you still designing your analog front-ends with LM358s, or have you looked around to see that technology has moved on since the 1970s? “OMG, you’re still using ST32F103s?”

It’s not a simple question, and there are no good answers. Proficiency with a tool, like for instance the audio editor with which I crank out the podcast every week, only comes through practice. And practice simply takes time and effort. When you put your time in on a tool, it really is an investment in that it helps you get better. But what about that newer, better tool out there?

Some of the reluctance to update is certainly sunk-cost fallacy, after all you put so much sweat and tears into the current tool, but there is also a real cost to overcome to learn the new hotness, and that’s no fallacy. If you’re always trying to learn a new way of doing something, you’re never going to get good at doing something, and that’s the lament of our artist friend. Honing your craft requires focus. You won’t know the odd feature set of that next microcontroller as well as you do the old faithful – without sitting down and reading the datasheet and doing a couple finger-stretching projects first.

Striking the optimal balance here is hard. On a per-project basis, staying with your good old tool or swapping to the new hotness is a binary choice, but across your projects, you can do some of each. Maybe it makes sense to budget some of your hacking time into learning new tools? How about ten percent? What do you think?

This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter. Want this type of article to hit your inbox every Friday morning? You should sign up!

hackaday.com/2025/01/18/learn-…

[Surya Chilukuri] writes in to share JTAGprobe — a fork of the official Raspberry Pi debugprobe firmware that lets you use the low-cost microcontroller development board for JTAG and SWD debugging just by flashing the provided firmware image.

We’ve seen similar projects in the past, but they’ve required some additional code running on the computer to bridge the gap between the Pico and your debugging software of choice. But [Surya] says this project works out of the box with common tools such as OpenOCD and pyOCD.

As we’ve cautioned previously, remember that the Pi Pico is only a 3.3 V device. JTAG and SWD don’t have set voltages, so in the wild you could run into logic levels from 1.2 V all the way to 5.5 V. While being able to use a bare Pico as a debugger is a neat trick, adding in a level shifter would be a wise precaution.

Looking to get even more use out of those Pi Picos you’ve got in the parts bin? How about using it to sniff USB?

hackaday.com/2025/01/18/jtag-s…

The ESP32 series of microcontrollers have been with us for quite a few years now and appeared in both Tensilica and RISC-V variants, both of which deliver an inexpensive and powerful device. It’s thus shown up in quite a few handheld computers, whether they be conference badges or standalone devices, and this is definitely a field in which these chips have more to give. We’re pleased then to see this e-ink PDA from [ashtf8], which we think raises the bar on this type of device.

At its heart is an ESP32-S3, on the back side of a QWERTY keyboard PCB, and for a display it has an e-ink screen. To get over the annoying e-ink refresh when typing text it uses a hybrid of e-ink and OLED, with a small OLED holding the current line which can be periodically sent to the e-ink. Perhaps the nicest thing about the hardware though is the clear resin printed clamshell case, and a hand-cast silicone membrane for the keyboard. That has always been a part considered difficult to produce, and here he is making one from scratch. Take a look at the video below the break.

Software-wise it has a range of apps with more promised, but even as it stands it looks useful enough to work with. If that’s not enough, then perhaps an ESP32 operating system would help.

youtube.com/embed/308KoLSLlCc?…

hackaday.com/2025/01/18/a-pda-…

Il panorama della cybersecurity è stato nuovamente scosso da IntelBroker, noto Threat Actor, che ha rivendicato una presunta violazione significativa ai danni di Hewlett Packard Enterprise (HPE).

Secondo quanto dichiarato su un forum nel Dark Web, l’attacco avrebbe esposto dati sensibili interni, tra cui codice sorgente, certificati e credenziali API. Sebbene i dettagli non siano ancora stati confermati ufficialmente, l’evento ha acceso un dibattito su possibili rischi e vulnerabilità per uno dei colossi dell’IT.

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’.

Le presunte prove del compromesso

IntelBroker non si è limitato a rivendicare la violazione, ma ha fornito dettagli per supportare le sue affermazioni. Tuttavia, è lecito chiedersi: le prove condivise sono davvero sufficienti per confermare un attacco di questa portata?

A supporto di queste dichiarazioni, IntelBroker avrebbe condiviso screenshot di sistemi interni (ora non più disponibili), endpoint API e documentazione tecnica, aumentando la credibilità delle sue affermazioni.

Le implicazioni di una possibile violazione

Se confermate, le conseguenze di questo attacco potrebbero essere devastanti per HPE. Ecco i principali rischi evidenziati:

• Abuso di credenziali: Le credenziali esposte potrebbero essere utilizzate per accedere a piattaforme integrate come Salesforce, causando ulteriori violazioni o manipolazioni di sistema.
• Manipolazione dei servizi: Conoscere dettagli operativi come tempi di esecuzione e frequenze di log potrebbe permettere agli attaccanti di alterare le prestazioni dei sistemi o coprire le loro tracce.
• Campagne di phishing mirate: Gli indirizzi email e i nomi associati potrebbero essere sfruttati per ingegneria sociale e campagne di phishing contro dipendenti e partner HPE.
• Danno reputazionale: Oltre ai rischi tecnici, la fiducia di clienti e partner potrebbe essere gravemente compromessa.

Chi è IntelBroker?

IntelBroker si è distinto negli ultimi anni per attacchi mirati contro grandi imprese, sfruttando vulnerabilità nei sistemi interni per massimizzare l’impatto delle sue operazioni. In questa presunta violazione, l’attore ha dimostrato un livello di sofisticazione elevato, mirato non solo all’esfiltrazione di dati, ma anche alla raccolta di informazioni critiche sui sistemi e le operazioni di HPE. Questo attacco, se confermato, rappresenterebbe una delle operazioni più significative attribuite a IntelBroker.

Come dovrebbe rispondere HPE?

HPE, di fronte a queste accuse, deve agire rapidamente per contenere i danni e rafforzare la propria sicurezza. Tra le azioni consigliate:

1. Gestione immediata dell’incidente: Bloccare l’accesso residuo e valutare l’ampiezza della violazione.
2. Rotazione delle credenziali: Revocare e rigenerare tutte le chiavi API, i certificati e le credenziali compromesse.
3. Audit di sicurezza approfondito: Analizzare i controlli nei repository, nei sistemi di sviluppo e nelle integrazioni API.
4. Comunicazione ai clienti: Informare tempestivamente i clienti coinvolti e fornire supporto per mitigare i rischi.
5. Monitoraggio delle minacce: Sorvegliare i forum nel Dark Web per individuare ulteriori pubblicazioni o transazioni relative ai dati sottratti.

Conclusione

Questa vicenda, anche se ancora in attesa di conferme definitive, mette in evidenza la necessità di un approccio proattivo alla sicurezza informatica. IntelBroker, con le sue azioni, non solo sottolinea le vulnerabilità di grandi organizzazioni come HPE, ma solleva anche dubbi fondamentali:

• Questo è un caso isolato o solo il primo di una serie di attacchi più complessi?
• Stiamo facendo abbastanza per proteggere le infrastrutture critiche?
• Come possiamo migliorare il monitoraggio delle minacce emergenti?

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 HPE nel mirino: IntelBroker Pubblica una massiccia violazione. Bluff sul Dark Web? proviene da il blog della sicurezza informatica.

If you needed to weld something in a pinch, what’s the minimum complement of equipment you could get away with? In [Professor Bardal]’s case, it’s a couple of motorcycle batteries and a roll of flux-core wire, and not much else.

We suspect this one is going to elicit quite a few comments, not least by the welding fans who no doubt will be triggered by just about everything in the video below, especially by characterizing this as MIG welding; it’s FCAW, or flux-core arc welding. But it bears some superficial similarities to MIG, at least insofar as there’s a consumable wire electrode through which a high-current DC supply flows, creating enough heat to melt it and the base metal. In this case, the current is provided by a pair of 12-volt motorcycle batteries hooked together in series. There’s also a torch of sorts — a short length of copper capillary tubing with a 1-mm inside diameter clamped in the jaws of a stick welder stinger, or a pair of locking pliers if you’re really in a pinch. The torch is connected to the negative terminal on the battery with a jumper cable, and the positive terminal is connected to the workpiece.

To create the weld, a piece of 0.8-mm flux-core welding wire is threaded through the capillary and into the joint, and fed by hand as it’s consumed. It’s awkward and awful, but it works. Of course, there’s no control over amperage as there would be with a legit welding machine, which would make it hard to adapt this method to different materials. Weld quality appears poor, too. But we suspect that if you were in a position to need a welder like this, you wouldn’t really care about any of that.

Fabricobbled welding rigs seem to be [Professor Bardal]’s thing — witness this much more professional MIG welder, complete with a baking soda and vinegar shielding gas generator.

youtube.com/embed/Z3cc_ph1Wv4?…

Thanks to [Danjovic] for the tip.

hackaday.com/2025/01/17/a-fiel…

A staple of starting off in electronics ion years past was the crystal set radio, an extremely simple AM radio receiver with little more than a tuned circuit and a point contact diode as its components. Point contact diodes have become difficult to find but can be replaced with a cats whisker type detector, but what about listening to the resulting audio? These circuits require a very high impedance headphone, which was often supplied by a piezoelectric crystal earpiece. [Tsbrownie] takes a moment to build a replacement for this increasingly hard to find part.

It shouldn’t have come as a surprise, but we were still slightly taken aback to discover that inside these earpieces lies the ubiquitous piezoelectric buzzer element. Thus given a 3D-printed shell to replace the one on the original, it’s a relatively simple task to twist up a set of wires and solder them on. The result is given a test, and found to perform just as well as the real thing, in fact a little louder.

In one sense this is such a simple job, but in another it opens up something non-obvious for anyone who needs a high impedance earpiece. The days of the crystal radios and rudimentary transistor hearing aids these parts were once the main target for may both have passed, but just in case there’s any need for one elsewhere, now we can fill it. Take a look at the video, below the break.

Fancy trying a crystal radio? We’ve got you covered.

youtube.com/embed/ARtfLB0nQ5k?…

hackaday.com/2025/01/17/no-cry…

We’re not sure how we managed to miss this one, but better late than never, right? This is Trinteract, a 3-DOF input device that’s both open-source and Arduino compatible. There’s even a neat 3D-printed clip to add it to the side of your laptop.

Imagine navigating 2D and 3D environments, or flying around in Minecraft with ease. [Görkem]’s custom PCB features a Hall effect sensor which picks up readings from the magnet embedded in the bottom of the joystick. You can use any magnetic object as input. In the video below the break, [Görkem] shows a 3D-printed sphere with a disc magnet trapped inside as an alternative. The super-neat part is that the thing moves around entirely on flexures. You know how much we love flexures around here.

[Görkem] has written up a fantastic guide for those who must have one of their own. As a bonus, the guide details the background and thought process behind the design, which we love to see.

Don’t like magnets? This space mouse uses an accelerometer and a spring.

youtube.com/embed/YoGgdORVARs?…

Thanks for the tip, [James]!

hackaday.com/2025/01/17/trinte…

Touch screen head units are pretty much the norm these days. Many compromise with annoying on-screen volume controls or tiny buttons. If you find yourself with such a unit, you might like to hack in a real volume knob. [Daniel Ross] shows us how to do just that.

The build uses an ATMega328 as the heart of the operation, though [Daniel] notes an Arduino Uno or Mini would have done just fine. It’s set up with a 74HC14 hex Schmitt trigger, and a CD4066 quad bilateral switch on a custom PCB. As for the volume knob itself, it’s not a real analog pot, instead it’s using a rotary encoder with a center push button. The way it works is that the Arduino reads the encoder, and figures out whether you’re trying to turn the volume up or down based on the direction you’re turning it. It then sends commands to the CD4066 to switch resistors in and out of circuit with lines going to the stereo to emulate the action of volume buttons on the steering wheel.

[Daniel’s] guide explains how everything works in greater detail, and how you can calibrate your head unit to accept these signals while preserving the function of your actual steering wheel volume buttons. Then you just have to find a neat way to integrate the knob into your existing dashboard.

We don’t see as many car stereo hacks in this era when infotainment systems rule all, but we’ve seen some great stuff from older vehicles over the years. Video after the break.

youtube.com/embed/dR6vM4ohU5A?…

hackaday.com/2025/01/17/androi…

As per a recent Bambu Lab blog post, its FDM printers in the X1 series will soon receive a firmware update that adds mandatory authentication for certain operations, starting with the firmware update on January 23rd for the aforementioned FDM printers. These operations include performing firmware upgrades, initiating a print job (LAN or cloud), remote video access and adjusting parameters on the printer. Using the printer directly and starting prints from an SD card are not affected.

As reasoning for this new feature Bambu Lab points to recent exploits that gave strangers access to people’s printers, though cheekily linking to an article on an Anycubic printer exploit. While admittedly a concern, this mostly affects internet-exposed printers, such as those that are tied into a ‘cloud’ account. Even so, LAN-based printing also falls under this new mandatory authentication system, with Bambu Lab offering a new tool called Bambu Connect for those who insist on using non-Bambu Lab branded software like OrcaSlicer. This allows for exported G-code files to be sent to a (property authenticated) Bambu Lab printer.

For those who do not wish to use this feature, not upgrading the firmware is currently the only recourse. Although this firmware update is only for X1-series printers, Bambu Lab promised that it’ll arrive for their other printers too in due time. While Bambu Lab printer owners consider installing the alternative X1 Plus firmware, the peanut gallery can discuss the potential security issues (or lack thereof) of an open Fluidd or similar UI on their LAN-connected, Klipper-based FDM printers.

Thanks to [mip] for the tip.

hackaday.com/2025/01/17/new-ba…

It’s podcast time again, and this week Dan sat down with Elliot for a look back at all the cool hacks we’ve written about. We started off talking about Hackaday Europe, which is coming up in March — seems unlikely that it’s just around the corner, but there it is. There’s also good news: the Hack Chat is back, and we started things off with a bang as Eben Upton stopped by to talk all things Pi. Separately, we talked about fault injection attacks, including how to find the hidden cup of 0xC0FFEE in an RP2350.

We saw a very cool piece of LED jewelry that does a fluid simulation, a direct conversion radio that’s all laid out in front of you, and the scrunchiest mechanical digital clock you’ll ever see. We saw blinkenlights for blinkenlights’ sake, all the ways to put threads in your prints, and how to ditch to coax and wire up your antennas with Cat 6 cable. Plus, it’s an Al Williams twofer in the Can’t-Miss Articles, with a look back at life before GPS and how you can tune into digital ham radio, no radio required.

html5-player.libsyn.com/embed/…
Where to Follow Hackaday Podcast

Places to follow Hackaday podcasts:

• iTunes
• Spotify
• Stitcher
• RSS
• YouTube
• Check out our Libsyn landing page

Download the zero-calorie MP3.

Episode 304 Show Notes:

News:

• Hackaday Europe 2025 Tickets On Sale, and CFP Extended Until Friday
• Eben Upton Hack Chat Transcript

What’s that Sound?

• Congratulations to [Egon] for getting the Ross ice shelf, and not some sci-fi computer at all.

Interesting Hacks of the Week:

• All The Attacks On The RP2350
• A Direct Conversion Receiver Anyone Can Build
  
  • Amateur Radio Homebrewing Hack Chat
  • Make Your Own Variable Inductor
  • DIY Tuning Capacitors From Washers And 3D-Printed Parts
  • A Variable Capacitor For Not A Lot

  
  

• Fluid Simulation Pendant Teaches Lessons In Miniaturization
• Using The ESP8266 For Low-Cost Fault Injection
• Comparing Ways To Add Threads To Your 3D Prints
• Springs And Things Make For A Unique Timepiece
  
  • Unique Clock Finally Unites Hackers And Sequins

  
  

Quick Hacks:

• Elliot’s Picks
  
  • Avian-Inspired Drones: How Studying Birds Of Prey Brings More Efficient Drones Closer
  • Audio On A Shoestring: DIY Your Own Studio-Grade Mic
  • Second CNC Machine Is Twice As Nice

  
  

• Dan’s Picks:
  
  • Forget The Coax, Wire Up Your Antennas With Cat 6 Cable
  • Procedurally Generated Terrain In OpenSCAD
  • Blinkenlights-First Retrocomputer Design

  
  

Can’t-Miss Articles:

• Before GPS There Was LORAN
• No Ham License? Listen Anyway In Your Browser

hackaday.com/2025/01/17/hackad…

Regular roller blades go way back, relying on a number of wheels mounted in a line and relying on regular bearings. [The Q] came up with an altogether more interesting design by handcrafting some tall skates with two hubless wheels apiece.

The build eliminates the hard work of creating the shoe part of the skates. Instead, an existing pair of roller blades was used, and modified to run the alternative hubless setup. The hubless wheels themselves were built by essentially wrapping a few large ball bearings with foam tires from an existing scooter wheel. The ball bearings have a large internal diameter, which creates the hubless look. They’re then mounted to a replacement steel frame that was mounted to the original skates.

Are there any benefits to hubless wheels in this application? Probably not, other than aesthetics. These skates are far heavier than before, and with poorer rolling resistance. However, we will note that the softer foam tires and large rolling diameter would probably offer some benefits on rougher surfaces. They even appear to work on hard-packed dirt, which is pretty impressive.

In any case, it’s always neat to see oddball designs that challenge our perception of what can and can’t be achieved on a mechanical level. These things don’t always have to make sense from an efficiency standpoint to be fun.

youtube.com/embed/M1pFmh8PQqY?…

hackaday.com/2025/01/17/you-ca…

Up first, go check your machines for the rsync version, and your servers for an exposed rsync instance. While there are some security fixes for clients in release 3.4.0, the buffer overflow in the server-side rsync daemon is the definite standout. The disclosure text includes this bit of nightmare fuel: “an attacker only requires anonymous read access to a rsync server, such as a public mirror, to execute arbitrary code on the machine the server is running on.”

A naive search on Shodan shows a whopping 664,955 results for rsync servers on the Internet. Red Hat’s analysis gives us a bit more information. The checksum length is specified by the remote client, and an invalid length isn’t properly rejected by the server. The effect is that an attacker can write up to 48 bytes into the heap beyond the normal checksum buffer space. The particularly dangerous case is also the default: anonymous access for file retrieval. Red Hat has not identified a mitigation beyond blocking access.

If you run servers or forward ports, it’s time to look at ports 873 and 8873 for anything listening. And since that’s not the only problem fixed, it’s really just time to update to rsync 3.4.0 everywhere you can. While there aren’t any reports of this being exploited in the wild, it seems like attempts are inevitable. As rsync is sometimes used in embedded systems and shipped as part of appliances, this particular bug threatens to have quite the long tail.

My Gmail is My Passport, Verify Me

Here’s an interesting question. What happens to those “Log In With Google” accounts that we all have all over the Internet, when the domain changes hands? And no, we’re not talking about gmail.com. We’re talking about myfailedbusiness.biz, or any custom domain that has been integrated with a Google Workspace. The business fails, the domain reverts back to unclaimed, someone else purchases it, and re-adds the admin@myfailedbusiness.biz Google Workspace account. Surely that doesn’t register as the same account for the purpose of Google SSO, right?

The answer to this question is to look at what actually happens when a user uses Google Oauth to log in. The service sends a message to Google, asking Google to identify the user. Google asks the user for confirmation, and if granted will send an ID token to the service. That token contains three fields that are interesting for this purpose. The domain and email are straightforward, and importantly don’t make any distinction between the original and new users. So when the domain and email change hands, so does ownership of the token.

Oauth does provide a sub (subject) field, that is a unique token for a given user/service combination. Seems like that solves the issue, right? The problem is that while that identifier is guaranteed to be unique, it’s not guaranteed to be consistent, and thus isn’t widely used as a persistent user identifier. Google is aware of the issue, and while they initially closed it as a “Won’t fix” issue, the concept did eventually earn [Dylan Ayrey] a nifty $1337 bounty and a promise that Google is working on unspecified fixes. There is no immediate solution, and it’s not entirely clear that this is strictly a Google problem. Other SSO solutions may have the same quirk.

Fortigate Under Attack

Fortiguard has reported that a vulnerability in FortiOS and FortiProxy is under active exploitation. Fortiguard lists quite a few Indicators of Compromise (IoCs), but as far as the nature of the vulnerability, all we know is that it is an authentication bypass in an Node.js websocket module that allows a remote attacker to gain super-admin privileges. Yoiks.

Actic Wolf has more details on the exploit campaign, which was first found back in early December, but appears to have begun with widespread scanning for the vulnerability as early as November 16. Attackers moved slowly, with the goal of establishing VPN access into the networks protected behind the vulnerable devices. Arctic Wolf has provided additional IoCs, so time to go hunting.

Ivanti Connect, Too

There’s another security device under attack this week, as watchTowr labs has yet another fun romp through vendor mis-security. This time it’s a two-part series on Ivanti Connect Secure, and the two buffer overflows being used in the wild.

Ivanti has already released a patch, so the researchers ran a diff on the strings output for the patched and unpatched binary of interest. Three new error messages are in the new version, complaining about client data exceeding a size limit. The diaphora binary diffing tool found some interesting debbuging data, like Too late for IFT_PREAUTH_INIT. “IF-T” turns out to be an open VPN standard, and that term led to a statement about backwards compatibility in Ivanti code that had terrible “code smell”.

The IF-T protocol includes the optional clientCapabilities field, and Ivanti’s implementation used a fixed length buffer to store it when parsing incoming connections. The client code almost gets it right, using a strlen() check on the data, and strncpy() to ensure the right number of bytes are copied. Except both of those best-practices are completely useless when the result from strlen() is fed directly into strncpy() as the maximum byte count, without checking whether it overflows the buffer.

The second watchTowr article goes through the steps of turning the vulnerability into a real exploit, but doesn’t actually give away any exploit code. Which hasn’t really mattered, as Proof of Concepts (PoCs) are now available. The takeaway is that Ivanti still has security problems with their code, and this particular exploit is both fully known, and being used in the wild.

Pentesting Mushrooms

The folks at Silent Signal have an off-the-beaten-path write-up for us: How to get hired as a pentester. Or alternatively, the story of hacking Mushroom Inc. See, they built an intentionally vulnerable web application, and invited potential hires to find flaws. This application included cross-site scripting potential, SQL injection, and bad password handling, among other problems. The test was to take 72 hours, and find and document problems.

Part of the test was to present the findings, categorize each vulnerability’s severity, and even make recommendations for how the fictional business could roll out fixes. Along the way, we get insights on how to get your job application dismissed, and what they’re really looking for in a hire. Useful stuff.

Bits and Bytes

Secure Boot continues to be a bit of a problem. Microsoft signed a UEFI application that in turn doesn’t actually do any of the Secure Boot validation checks. This is only an issue after an attacker has admin access to a machine, but it does completely defeat the point of Secure Boot. Microsoft is finally rolling out fixes, revoking the signature on the application.

And if compromising Windows 11 is of interest to you, HN Security has just wrapped a four-part series that covers finding a vulnerability in an old Windows kernel driver, and turning it into a real read/write exploit that bypasses all of Microsoft’s modern security hardening.

Do you have a website, and are you interested in how your API is getting probed? Want to mess with attackers a bit? You might be interested in the new baitroute tool. Put simply, it’s a honeypot for web APIs.

And finally, the minds behind Top10VPN have released another vulnerability, this time in tunneling protocols like IPIP, GRE, and 6in4. The problem is a lack of validation on incoming tunnel packets. This allows for easy traffic injection, and using the tunnel servers as easy proxies. One of the worst cases is where this flaw allows accessing an internal network protected behind a consumer router.

hackaday.com/2025/01/17/this-w…

Kids love their Power Wheels and other ride-on electric cars. Indeed, [Ashwin]’s son was digging his little ATV, but soon found that some care was needed on the pedal. It had no proper throttle control, instead turning the motor hard on or off and scaring the poor kid in the process. The solution? A bit of an upgrade from some off-the-shelf electronics.

Inspiration came from—where else—the /r/PowerWheelsMods subreddit. The main tweak was to install an off-the-shelf soft-start circuit to stop the motor banging hard on when the accelerator was pushed. Instead, when the accelerator is pushed, the module gradually ramps up its PWM output to the motor to smooth out the acceleration curve. This would make the ATV much easier to ride.

Implementing this off-the-shelf solution did take some doing, though. The first attempt ended with a short circuit and a blown fuse. However, [Ashwin] wasn’t deterred—a trip back online to do some research did the trick. With some careful wiring that took into account the crude forward and reverse circuit, [Ashwin] had a much smoother running ride-on for his son.

While most of the mods we see for these little ride-ons are all about power and speed, we do appreciate the occasional attempt to make the things a bit safer for younger drivers. If you’re brewing up your own fancy kidmobile at home—don’t hesitate to let us know!

hackaday.com/2025/01/17/moddin…

Introduction

This report covers the research of the Mercedes-Benz Head Unit, which was made by our team. Mercedes-Benz’s latest Head Unit (infotainment system) is called Mercedes-Benz User Experience (MBUX). We performed analysis of the first generation MBUX.

MBUX was previously analysed by KeenLab. Their report is a good starting point for diving deep into the MBUX internals and understanding the architecture of the system.

In our research we performed detailed analysis of the first generation MBUX subsystems, which are overlooked in the KeenLab research: diagnostics (CAN, UDS, etc.), connections via USB and custom IPC.

This article would not have been possible without the amazing work of Radu Motspan, Kirill Nesterov, Mikhail Evdokimov, Polina Smirnova and Georgy Kiguradze, who conducted the research, discovered the vulnerabilities, and laid the groundwork for this report.

Special thanks to Mercedes-Benz Group AG for their professionalism and prompt handling of all the identified vulnerabilities.

Diagnostic software

To get a first look at the vehicle architecture, it is helpful to use diagnostic software (which is available to certified users only) to scan the Electronic Control Unit (ECU), identify its version, and test the software’s diagnostic functionality. There are several diagnostic tools which make it possible to connect to the vehicle, using various types of communication. In our research, we used a combination of diagnostic tools: a certain hardware interface and a corresponding software application to communicate with the vehicle through the hardware device. This setup allowed us to establish communication over DoIP (Diagnostic Over Internet Protocol):

Communication between diagnostic software and hardware

The TCP communication between the diagnostic tool and the diagnostic hardware device is performed over Ethernet using custom protocols (Protocol Data Unit, PDU). At the first stage, the diagnostic hardware device uses a custom ASCII-based protocol (CSD). It performs user authentication, version check, configuration setup, and provides the initial environment to process the upper layer protocol (PDU).

The upper layer protocol has a binary format. It is used to send Universal Diagnostic Services (UDS) messages, trigger DoIP communication, and so on. To analyze this protocol, we used a script written in LUA:
[pduparser.lua]. Using this script, UDS commands can be easily distinguished from the regular network traffic of communication between the diagnostic software and hardware:

We examined the diagnostic tool interface and decoded the traffic, which allowed us to find various UDS commands, such as for resetting the ECU, turning off the engine, and locking the doors.

Architecture

The architecture of MBUX is as follows:

The main parts of MBUX are:

• MMB (Multi Media Board) — the main part of the head unit (HU) which contains all the subsystems;
• BB (Base Board) — the part with chips for various network communications;
• CSB (Country Specific Board) — the extended part which communicates with the MMB through internal Ethernet;
• RH850 — the module designed to provide communication between low level buses.

Full information on the MBUX architecture can be found in the KeenLab research.

Test setups

For our research we used two test setups:

• a real car — Mercedes B180;

• a testbed — our own platform for hardware and software testing, which we designed for the purpose of this study.

Anti-Theft

While modeling the testbed, we needed to bypass the original anti-theft feature, because after the actual vehicle is started up, the head unit waits for authentication over the CAN bus. As mentioned in the KeenLab research, specific commands should be sent over CAN to wake up the system. We couldn’t imitate this in our setup, so the head unit was entering anti-theft mode and the user couldn’t communicate with it. Taking an empirical approach, we discovered that some CAN messages force the head unit to reset the anti-theft status. In fact, these messages trigger the anti-theft check. For example, when the head unit tries to turn off the display, the CAN message initiates the anti-theft check, leaving the head unit still accessible for a few seconds. For seamless and stable investigation, we created a script that continuously sent this message in a loop.

As a result, the head unit becomes accessible for a long time, switching between an authenticated state and anti-theft mode.

Firmware

The MMB runs on Linux, and its filesystems are located on the eMMC. We needed to extract the eMMC from the printed circuit board by unsoldering it. Inside, there are several partitions:

MMB files can also be downloaded from a diagnostic tool website that provides updates for specific hardware part numbers.

Unpack update

Nowadays multimedia systems in cars are generally updated over-the-air. Car dealerships are one exception, however, as they can perform offline software updates with the diagnostic tool.

Several outdated update files can still be found online. Update file types can be divided into the following groups by their names:

• files with \*ALL\*, containing *.CFF, *.SMR-F and *.bin files;
• files with \*CFF\*, containing only *.CFF files;
• files with \*SMR-F\*, containing only *.SMR-F files.

In general, *.bin files are containers with a custom file structure. They can be encoded with zlib or other methods.

*.SMR-F files are compressed and they also have a custom file structure. Besides metadata in plaintext, they also contain encrypted data, which the diagnostic tool uses its shared libraries to decrypt. After decryption, the resulting file contains the metadata and a container, just like the *.bin files.

*.CFF files contain the same payload content as the *.SMR-F files, but uncompressed. This format was used for earlier head unit generations.

Custom IPC

Inside the head unit, firmware services use custom IPC protocols for communication between their own threads, other services and other ECUs. There are three main widely used protocols:

• thriftme;
• MoCCA;
• GCF.

These protocols can be used at the same time; moreover, each service can use all of them simultaneously. Knowing the internals and API of these protocols, it’s easier to understand the workflow of the services.

thriftme

This RPC protocol is based on the open-source protocol Apache Thrift. Its main distinctive feature is that thriftme allows subscribers to be notified about particular events. The UNIX socket, TCP, UDP, SSL, and so on can be used as a transport for this protocol. The core functionality of this protocol is implemented in the library libthriftme.so.2.7.2.

The base class in the thriftme RPC is “thrift::TServiceBroker”, which isolates the communication with transports and call interfaces of services and clients. In thriftme, the service broker version is the instance of “thrift::lisa::CTLisaServiceBroker”, which inherits from “thrift::TServiceBroker”.

Services in thriftme are inherited from “thrift::lisa::TLisaServerBase” (which, in turn, inherits from “thrift::TServiceProcessor”). Services are registered in the service broker through “thrift::TServiceProcessor::registerService”. Transport used by clients is registered through “thrift::lisa::CTLisaServiceBroker::addServers” (which wraps “thrift::TServiceBroker::addServer”). Service interface functions are registered through “thrift::TServiceProcessor::tmRegisterCallback”. The handler is passed to this export function in arguments, and it is called while processing the client request. So the instance of the service in memory looks as follows:

The “interface1” field contains functions which process the API of the service and their wrappers previously registered through “thrift::TServiceProcessor::tmRegisterCallback”. The “interface2” field contains functions which are called to notify subscribers of this service.

Clients in thriftme are inherited from “thrift::lisa::TLisaClientBase” (which, in turn, inherits from “thrift::TClient”). In fact, client instances are created by the service broker when the transport is successfully created. In our case, the service broker used the factory of a client, which is registered in the service broker through “thrift::TServiceBroker::tmRegCli”. The factory helps clients register handlers for notification about events through “thrift::TClient::tmRegisterCallback”. The sample instance layout of a thriftme client is the following:

The “interface1” field contains the handler is called after transport connection. Usually this handler is used to trigger a subscribe operation to receive event notifications. The “interface2” field contains functions which send requests to the service API. The “interface3” field contains functions which are called before initiating the “notify subscribers” operation of this service. Their wrappers were previously registered through “thrift::TClient::tmRegisterCallback”.

MoCCA

This RPC framework was developed by Harman and is based on the open-source DSI framework. The core functionality is implemented in the “/opt/sys/lib/libSysMoCCAFrameworkSharedSo.so.11” library. This framework is widely used for interthread communication.

During start-up, the service creates component instances through factory functions, for example “CHBApplicationBuilder::theCDiagnosisComponentCreator”. This instance inherits from the class “CHBComponent”. The global variable “CHBComponentInfo::spMap” contains the mapping between additional information about components and their names. The framework allows components to have their own aliases to access another components through “CHBComponentInfo::addComponentMapping”: “CHBComponentInfo::addComponentMapping(&unk_581498, “FsActionHandler”, “FilesystemMainActionHandler”)”. Components can contain multiple services and clients and can communicate with their own services or other component services. The following is the architecture of components:

For communication the following events are used:

An example of a client object is “CTraceServiceClientBase”, which inherits from “CHBClientBase” and uses the proxy object “CTraceServiceProxy” for transport. The proxy object inherits from “CHBProxyBase” and is created through the factory method “CTraceServiceProxy::findOrCreateInstance”. It tries to reuse already created proxy objects inside this component. The general layout of a client object is as follows:

The “IHBEventConsumer” interface is used to process response events in “CTraceServiceClientBase”. The entry point for processing is the “processEvent” method. It uses two values to find a handler, which are called as follows:

• use the “status” field to identify the response: standard response of a service, failed or invalid response;
• use the “internalID” field to identify the API function.

On the service side in our example we used the “CTraceServiceStub” class. Below is its layout:

The request event is processed in the “processEvent” method. It identifies the API function handler using the “internalID” field and calls the identified handler.

GCF

GCF is a custom protocol, which is used for RPC. It allows the services to be registered in the router. The router handles the following messages from services and clients:

• Control message (“CTRL”):
• “REGS” – used to register service;
• “REGF” – used to register RPC function of service;
• “EVNT” – used by service to notify clients about event;
• “CALL” – used by clients to call functionality of service;
• etc.

So during initialization, the services are registered in the router. The internal router table handles the flow of message processing. Finally, clients can send call requests to the router, which trigger predefined functions of registered services. The format of a call request is as follows:
CALL <ServiceName>:<Number> <ServiceCallName> <Params>

Internal network

As mentioned in the KeenLab research, there are some test points on the head unit, which are used by the CSB for connection to the MMB. We removed the default connection and connected the RJ45 cable to access the internal network of the head unit. This connection, labelled as
eth0, has some restrictions, as stated in the corresponding firewall rules in “firewall_prd.policy”:-A INPUT -s [IP]/32 -d [IP]/32 -i eth0 -m state –state NEW -j ACCEPT
-A OUTPUT -s [IP]/32 -d [IP]/32 -o eth0 -j ACCEPT
-A OUTPUT -s [IP]/32 -d [IP]/32 -o eth0 -m state –state NEW -j ACCEPT
Access to services on the MMB is established via an IP address, which is a default address for connecting the CSB to the MMB. The scan results of TCP ports on the MMB are as follows:

After connecting to the test point, we received a huge attack surface and access to the Diagnostic Log and Trace (DLT) subsystem, which is very helpful when testing and debugging:

DLT supports callback injection, which makes it possible to call specific handlers inside services. In the head unit this feature is widely used for product testing.

Identified vulnerabilities

The following findings were used to compromise the testbed. It is necessary for debugging the environment and searching for vulnerabilities in the subsystem that can be exploited in the real car.

CVE-2024-37600 (MoCCA)

The “servicebroker” service is a part of a DSI framework, which is used in MoCCA. This service is used to monitor services and clients.

It sets up HTTP servers using TCP ports. There are several POST commands, which can be processed. One of them is
disconnect, which takes a string as an argument.
The code in the
setup() function tries to parse this command with functions that provide unnecessarily excessive access to memory. According to the disassembled code, it performs read operations using sscanf on a stack buffer. As a result, there can be a stack buffer overflow:

In DLT logs we can identify crashes:

CVE-2023-34404 (GCF)

“MonitorService” is a service which can be accessed over GCF protocol. This service is initialized and started in the “scp” service. The latter, in turn, is a systemd service, which starts with the following configuration:
...

[Service]ExecStart=/opt/comm/swmp/wicome/bin/scp -f /var/opt/swmp/pss_config.cfg -s
wicome_config -r /opt/comm/swmp/wicome/bin -k VerboseLevel=5
ExecStop=/bin/kill $MAINPID
Environment=LD_LIBRARY_PATH=/opt/sys/lib:/opt/comm/swmp/wicome/lib
Environment=LOGNAME=root
EnvironmentFile=/opt/etc/lisa_env
Type=simple
Restart=on-failure
RestartSec=2
WatchdogSec=240
...
“MonitorService” uses the following configuration file “/var/opt/swmp/pss_config.cfg” to fine-tune its operation:
MonitorService.TimestampEnable = 1
MonitorService.ReceiveEnable = 1
MonitorService.MonitoringEnable = 1
MonitorService.MessageBufferSize = 1000
MonitorService.MessageBufferMemory = 512000
#1-file, 2-dlt, 3-both
MonitorService.LogMode = 2
#MonitorService.LogMode = 0
MonitorService.LogFileSize = -1
MonitorService.LogFileName = /tmp/wicom.log
MonitorService.LinefeedEnable = 1
MonitorService.HeaderEnable = 1
MonitorService.FileHeaderEnable = 1
#RH
MonitorService.Port = 2021
The “MonitorService.Port” variable handles the number of the TCP port that will be used by the server. The “MonitorService.ReceiveEnable” variable defines whether the server is able to handle requests from clients. Accordingly, “MonitorService”, containing the head unit configuration, can receive GCF messages from the client and transfer them through the GCF router.

The list of registered services in the GCF router includes “NetworkingService”. It has the following registered handlers:

The “NWS_PF_setMacAddrExceptionIP” handler adds rules to the firewall policy. It uses the following arguments:

• macAddress – MAC address for the rule;
• direction – defines the direction of rule: inbound or outbound;
• fate – defines the type of rule: allow or deny;
• command – the action to be performed: add the rule or remove it from the policy.

The control flow for processing this request is located in the following binaries: “MonitorService”, “libwicome_monitorservice.so” and “libwicode_gcf_core.so”. The call stack is the following:
sub_EE6E8 (NWS_PF_setMacAddrExceptionIP)
sub_E9D0C (sNWS_PF_setMacAddrExceptionIP)
sub_F275C (CGCFStub_PF::setMacAddrExceptionIP)
sub_F7AF4 (CGCFStub_PF::_int_setMacAddrExceptionIP)
snprintf
sub_F7EB4 (systemExec)
system
The
sub_F7AF4 function executes the system() call with arguments to the iptables binary:/* ... */
if ( v10 )
{
v11 = (const char *)PAL::CString::raw(direction);
v12 = (const char *)PAL::CString::raw(mac);
if ( snprintf(v22, 0xFFuLL, "iptables -%s %s -m mac --mac-source %s -j
%s ", (const char *)&v21, v11, v12, v20) < 0 )
{
/* ... */
v18 = 0;
}
if ( v18 )
{
if ( (unsigned __int8)systemExec(a1, v22) != 1 )
{
/* ... */
return 0;
}
}
}
/* ... */
When processing the request, the MAC address is neither checked nor restricted. That means an attacker can perform command injection during the
iptables command execution.

Privilege escalation

The head unit uses the outdated system Polkit, which is vulnerable to CVE-2021-4034. This is a local privilege escalation vulnerability that can result in unprivileged users gaining administrative rights on the target machine. There are a lot of publicly available exploits targeting it, enabling the execution of arbitrary commands as the user “phone” of group “comm”.

After successfully exploiting this vulnerability, an attacker can run commands to modify network interfaces, mount filesystems, and perform other privileged activities. Although some restrictions are imposed, a potential attacker can access the systemd command to further escalate their privileges.

The partition with root filesystem was mounted as a read-only filesystem. As mentioned in the KeenLab research, the head unit doesn’t have any enabled disk integrity protection features. That means the filesystem can be remounted with read and write rights, and the bash scripts that are run during start-up can be modified.

USB

USB is the most popular attack vector in terms of physical access. The head unit is built on a microservice architecture, where each service is rather isolated and communicates through an API. Each microservice of the head unit provides some internal functionality and one or more thriftme services, through which other microservices can communicate with it. This fact enables the emulation of a USB subsystem using QEMU user-mode version.

Preparation

The “DeviceManager” service is responsible for handling USB events: adding, removing, mounting or updating. Other services can subscribe to “DeviceManager” and use notify callbacks to perform actions when USB events occur. For example, such a service can start searching for specific files when the USB filesystem is mounted.

The “GDVariantCodingService” service is a frontend of variant coding. Other services use it to identify the parameters of the head unit and car.

Both of these services should be emulated to run a self-hosted USB subsystem. This task can be performed by emulating corresponding thriftme services. So, for successful emulation, we should perform the following actions:

1. Prepare the network for IP addresses used by services.
2. The services “DeviceManager” and “GDVariantCodingService” use UNIX sockets for transport. To emulate them, it’s easier to use TCP sockets so that we aren’t dependent on the filesystem. Perform forwarding using socat.
3. Run the emulated thriftme services. In our case, we created devicemgr.py, vehicle.py and varcoding.py. In devicemgr.py, the mounting of the USB filesystem is emulated to the path “/opt/sys/bin/aaaaa”.
4. Use QEMU user emulation in a “transparent” fashion.
5. In the chroot environment prepare folders and devices.

The USB subsystem is emulated.

Emulation of data export, import and tracing

The head unit has the functionality to import or export user profile files (seat position, favorite radio stations, etc.) to or from a USB storage. This task is handled by the “UserData” service — to be more precisely, by the thriftme service “CSystemProfileServiceImpl”.

The user profiles backup looks like a folder with the following directory structure:
.
└── MyMercedesBackup
├── shared
├── system
│ ├── rse.ud2
│ └── system.ud2
└── udxprofiles
├── profile0
│ ├── commuterroute.ud2
│ ├── emotions.ud2
│ ├── navidata.ud2
│ ├── pud.ud2
│ ├── uapreds.ud2
│ ├── vt_ab.ud2
│ └── vt_tuner.ud2
└── profileindex.xml
Some of the files are generated by “UserData” itself, but most of them are generated and processed by other services, like “CAPServer”. The most important component of data import and export processes is the thriftme service “UserDataExchangeService” in “UserData”. Services subscribe for notifications about data import and export in UserDataExchangeService.

“CSystemProfileServiceImpl” performs the following workflow when exporting the profiles backup:

1. Run timer for 100 seconds.
2. Notify client services through “UserDataExchangeService” using events that request data export. Such events contain the information about the exported data.
3. Services call API functions that verify the success of the data export. Their arguments are a data key and a path to the file.
4. “UserData” collects all received files, encodes them and stores them in the mounted USB filesystem.

The scheme is similar for the profile backup import:

1. “UserData” copies files from the USB to the local system and decodes them.
2. It notifies client services through events that request data import.
3. If the client service is handling the data key, it imports the data.
4. Services call API functions that verify the success of the data import.

The backup contains XML files and binary files. Binary files are considered more useful for vulnerability hunting:

When triggering backup import (restore) and export (backup), the following scripts were created:
triggerRestore.py and triggerBackup.py.
Almost all the services of the head unit support the trace system
HBTracePersistence, which allows tracing to be turned on and off for a specific module or function.
The “hbtc” file contains the tracing system configuration and determines the function tracing method. An example of the “hbtc” file is provided below:
HBTracePersistence 1.0.0
imp 00 08
imp_userdata_private_CSystemProfileManager ff 08
imp_userdata_private_CUserDataVehicleInformationAdapter ff 08
imp_userdata_private_CUserDataIF2Impl ff 08
imp_common_streamhelper_StreamHelper ff 08
imp_userdata_private_CUDXStructure ff 08
As mentioned previously, files in the backup are encoded — the algorithm is proprietary. The “CPUserDataEncodingHandler” class handles it. The script
ud2codec.py was prepared to be able to encode and decode files.

Identified vulnerabilities

The following vulnerabilities were tested on a real car.

CVE-2024-37601

The process of decoding files with the
*.ud2 extension contains the heap buffer overflow vulnerability.
“UserData” represents encoded data through the “CHBString” object, which processes data as a UTF string. Then the UD2-specific decoding characters should be deleted, and their indexes should remain constant. For this task we used the “CHBString::const_iterator::incrementSteps” function to get the pointer on the desired character and “CHBString::remove” to remove the character from the string. “CHBString::const_iterator::incrementSteps” incorrectly processes the character with code
0xe7: it will be decoded as 1 byte. But according to the table “UTF8LookUpTable”, which is used in “CHBString::remove” and “CHBString::CHBString”, the character with code 0xe7 is encoded with 3 bytes.
As a result, when performing the “CHBString::remove” function, the calculated pointer can be outside of the allocated buffer after UTF decoding with “UTF8LookUpTable”. The memmove function will be called with the third argument (size of buffer) equal to -1.
Without further exploitation by the attacker, this vulnerability triggers the crash of the “UserData” service during data import. This puts the system into a frozen state, which can be fixed only through an ECU hard reset.

CVE-2023-34402

As mentioned previously, the
vt_ab.ud2 file was decoded as vt_ab.xml during the profile backup export for vulnerability searching. This file’s contents resemble a binary and it is processed by the text-to-speech service.
The
vt_ab.xml file contains another file, describing which service will be dropped during processing. For this task it contains the name of the file to drop. This action is performed in the “UserDataExchangeServiceClient::unpackVoiceTagArchiveOptimized” function:

• get the content of the file describing what to drop;
• get the name of the file to drop and perform the dropping.

Because the checks are not being performed, an attacker can control the path which is used to write controllable content. As a result, the attacker can access arbitrary file writing with the same rights the service has.

CVE-2023-34399

After decoding, the
uapreds.ud2 file in the profile folder “MyMercedesBackup/udxprofiles/profile0” takes the form of uapreds.db. The system recognizes it as an SQLite database, which is parsed in the service that uses machine learning for creating efficient routes. The decoded file is processed in “capthrift::CapServer::requestImportBinaryData”, then it calls “capthrift::CapServer::setProfile” to load the database.
All values in the SQLite database tables are serialized as an archive to match the boost library. The format of this archive can be either XML or plain text. We used the plain text mode. Here is an example of an archive in the
learning_kernel row of the kvpair_table table:22 serialization::archive 11 0 2 0 1 0 0 1 0 1 0 0 0 0 1
0.00000000000000000e+00 0 0 0 0 0 0 0 0 1.00000000000000000e+00
...
The last publicly available version of the boost library, 1.81 (at the time of research), contains the integer overflow vulnerability. This vulnerability can be exploited when processing an entity pointer:

In (1), the value
cid was obtained from the attacker-controllable data. After that, in (2), this value is used as an array index to get the cobject_id object. (3.1) and (3.2) introduce restrictions for cid:

• whether the value of cid equals -1;
• whether the value of cid is greater than the size of the cobject_id_vector array.

These restrictions can be bypassed using the assigned value of
cid. This is possible because the definition of class_id_type is assigned an integer:

So if we assign the “–3” value to
cid, then the pointer co.bpis_ptr (2) will be corrupted.
Lastly, the triggered vulnerability in the debugger looks as follows:
Thread 63 hit Breakpoint 2, 0x0000004002f3cea4 in ?? ()
# cid value
(gdb) i r x2
x2 0xfffffffffffffffd -3
# cobject_id_vector size
(gdb) x/1hx $x20 + 0x58
0x405c01b278: 0x000e
# cobject_id_vector pointer
(gdb) x/1gx $x20 + 0x60
0x405c01b280: 0x000000405c017f00
# 1 element in the cobject_id_vector
(gdb) x/3gx *(void **)($x20 + 0x60) + 0 * 0x18
0x405c017f00: 0x000000400147f1c8 0x0000000000000000
0x405c017f10: 0x0000010000000002
# refferenced element
(gdb) x/3gx *(void **)($x20 + 0x60) + -3 * 0x18
0x405c017eb8: 0x5f72696170766b5f 0x00315f656c626174
0x405c017ec8: 0x0000000000000035
(gdb) c
Continuing.

Thread 63 received signal SIGSEGV, Segmentation fault.

Exploitation notes

At the first stage, it is assumed that the image base address is fixed and the vulnerability code is loaded to a specific address in the memory. We analyzed the vulnerability code and checked exactly how all the pointers are dereferenced and where the virtual call is performed. Here are the steps:

• By controlling the id, we can move the pointer (by moving it to negative offsets relative to the beginning of the array in the heap);
• By moving the pointer, we will get to an address where another address containing an object for bis_ptr is located;
• The address for bis_ptr should contain the address of the virtual call table.

Controlling only the offset to the corresponding object, we need to get to the address in the heap which contains a pointer to the pointer with the associated virtual table.

We can implement such a scenario using a spray of DDL entries inside the SQLite database that we can control. For such a spray, we need to create a lot of tables with long names. As a result, structures of a proper format will appear in the heap and a negative index will allow us to get to these structures.

Below is an example of such a SQLite-based file (the entry in
sqlite_schema is a table creation request):

So we can create a lot of tables with long names, which gives us a heap spraying primitive.

Using the heap spraying technique, an attacker can fully control the execution:

To import the
uapreds.db database to the “CAPServer” service, we need to copy it to the service’s working directory. Then “CAPServer” tries to load the database from its own working directory. As a result, if an attacker managed to import the database which triggers the vulnerability in the head unit, then each start-up of “CAPServer” will try to load it and crash. The “CAPServer” service gets started by “systemd” and is configured as follows:
[Service]ExecStart=/opt/prediction/bin/CAPServer /var/opt/prediction/
ExecStop=/bin/kill $MAINPID
Environment=LD_LIBRARY_PATH=/opt/sys/lib
EnvironmentFile=/opt/etc/lisa_env
Type=notify
WatchdogSec=30
Restart=on-failure
RestartSec=2
This means that after the crash, “systemd” will try to restart “CAPServer”. This triggers an infinite loop of service crashes, which can be helpful when trying to brute force the image base address.

Inside SQLite database, there is a pragma section which contains SQL commands to create tables. This feature can be used to create controllable data out of tables in the database based on the current time. The following script can be used to automate the process of creating an SQLite database, which might trigger this vulnerability according to the current time:
#!/bin/bash
DBPATH=test.db
STOP_TIME=$(date --date='-2 hours +10 seconds' +"%H:%M:%S")

echo "Trigger until < $STOP_TIME, clean after >= $STOP_TIME";

poc_value="CRASH the system"
clean_value="system work"

check() {
sqlite3 $DBPATH << EOF
SELECT strftime ('Time of database: %H:%M:%S', 'now');
select * from target_table;
.exit
EOF
}

rm $DBPATH

sqlite3 $DBPATH << EOF
CREATE VIEW target_table AS SELECT "key" AS varkey, "$poc_value" AS varval
WHERE TIME() < "$STOP_TIME" UNION SELECT "key" AS varkey, "$clean_value" AS
varval WHERE TIME() >= "$STOP_TIME";
.exit
EOF

check

sleep 10

check
As a result, an attacker can run image base address brute forcing for some time.

Attack vectors

During our research, we managed to compromise the testbed of the head unit and found several vulnerabilities for a real car via physical access.

The testbed compromise has three potential use cases:

• a criminal wanting to disable the anti-theft protection in a stolen head unit;
• a car owner tuning and unlocking prepaid services on their vehicle;
• a pentester conducting research to find new vulnerabilities.

In the case of a real car, the identified vulnerabilities can be triggered through an exposed USB service that is available to the general user.

Vulnerability list

During the process of vulnerability disclosure with the vendor, the following CVE IDs were assigned:

CVE-2024-37602
CVE-2024-37600
CVE-2024-37603
CVE-2024-37601
CVE-2023-34406
CVE-2023-34397
CVE-2023-34398
CVE-2023-34399
CVE-2023-34400
CVE-2023-34401
CVE-2023-34402
CVE-2023-34403
CVE-2023-34404

The CVE details will be published here: github.com/klsecservices/Advis….

securelist.com/mercedes-benz-h…

Microsoft ha ampliato i test della protezione dell’amministratore in Windows 11 consentendo agli utenti di Windows Insider di abilitare la funzionalità tramite le Impostazioni di sicurezza di Windows.

Introdotta per la prima volta in ottobre per il canale Canary, la Protezione amministratore utilizza un meccanismo nascosto per l’elevazione temporanea dei diritti e le richieste di autenticazione tramite Windows Hello, consentendo l’accesso ai diritti amministrativi solo quando necessario. La protezione ha lo scopo di impedire l’accesso non autorizzato alle risorse critiche del sistema.

Quando questa funzionalità è abilitata, gli amministratori che hanno effettuato l’accesso dispongono dei diritti utente standard e devono autenticarsi utilizzando Windows Hello (PIN o dati biometrici) quando installano nuove app o apportano modifiche al registro. Le richieste di autenticazione sono più difficili da aggirare rispetto al meccanismo esistente di controllo dell’account utente (UAC), rendendo più difficile la penetrazione di malware e aggressori.
Esempio di finestra delle credenziali con una nuova area colorata (più grande) sopra la descrizione dell’applicazione ( Microsoft)
La funzionalità è disabilitata per impostazione predefinita e può essere abilitata dagli amministratori tramite criteri di gruppo o strumenti di gestione come Intune.

Inoltre, ora gli utenti possono abilitarlo autonomamente tramite le impostazioni di sicurezza di Windows nella sezione Aggiornamento e sicurezza – Sicurezza di Windows – Protezione dell’account. La modifica richiede il riavvio del sistema.

Questa funzionalità è disponibile per i Windows Insider nel canale Canarie che hanno installato Windows 11 Insider Preview Build 27774. Microsoft prevede inoltre di introdurre presto una nuova funzionalità denominata Ripristino rapido sistema, che consente agli amministratori di risolvere in remoto i problemi che rendono inutilizzabili i dispositivi dopo gli aggiornamenti di Windows.

La nuova funzionalità, come molte altre opzioni di sicurezza, funziona come parte della Secure Future Initiative.

L'articolo Basta Privilege Escalation! Microsoft Potenzia Windows 11 contro le LPE proviene da il blog della sicurezza informatica.

When it comes to hacking niches, breathing new life into vintage devices is always an exciting challenge. [t0mg]’s recent project exemplifies this with his 1978 Sony FX-300 ‘Jackal’ radio. He’d already upgraded the radio in 2021 and turned it into a feature-packed marvel, but there’s always room for improvement.

[t0mg]’s initial 2021 build had its quirks: noisy sound, a subpar display, and a non-functional radio module. Determined to enhance these aspects, he sourced an IPS version of the original 3.2″ ILI9431 LCD, significantly improving viewing angles. To tackle the audio issues, he integrated an M5Stack Atom microcontroller, utilizing its Bluetooth A2DP capabilities to deliver cleaner digital sound via I2S to the Teensy audio board. The Teensy itself got a complete wire overhaul just for the sake of good craftmanship.

The new setup also enabled the display of song metadata. Additionally, [t0mg] incorporated a dedicated Arduino Nano clone to manage inputs, streamlining the overall design. The revamped ‘Jackal’ now boasts a bunch of impressive features such as displaying RDS data for FM stations, voice recording, and an NFC reader for personalized playlists.

If you’re into radio makeovers, look into this post for a real golden oldie, or start out with the basics. For [t0mg]’s earlier improved version of this Jackal, read our article on it here.

youtube.com/embed/Jtwbudb9z_4?…

hackaday.com/2025/01/17/packin…

Un misterioso post apparso recentemente sul noto forum underground Breach Forums ha scosso la comunità della cybersecurity. Un threat actor, che si fa chiamare ZeroSevenGroup, ha messo in vendita per 10.000 dollari l’accesso completo alla rete di un “Dipartimento di un Ministero in Italia” non meglio precisato,

L’annuncio, pubblicato il 15 gennaio 2025, descrive un accesso di tipo critico con privilegi di amministratore su Active Directory dell’infrastruttura violata, accesso tramite Comand & Control e tramite VPN.

Insomma, un bel bottino per un criminale informatico di stato, ma anche da profitto. Chi sia il bersaglio di questa vendita rimane avvolto nel mistero: l’identità del ministero o dipartimento colpito non è stata ancora resa nota.
Post sul forum breach Forums da parte del threat actors ZeroSevenGroup

Initial Access Broker: Gli “Apriporta” del Cybercrime

L’attività descritta nel post è un esempio classico del lavoro svolto dagli Initial Access Broker (IAB), una figura chiave nell’ecosistema del cybercrime. Gli IAB si specializzano nel compromettere le reti di aziende o enti pubblici per poi vendere l’accesso a organizzazioni criminali più strutturate, come le cyber gang ransomware. Questi gruppi acquistano tali accessi per sfruttarli in operazioni più ampie, che possono includere il lancio di ransomware, l’esfiltrazione di dati sensibili o altre attività malevole.

Il modus operandi degli IAB rappresenta un vero e proprio “mercato del crimine”: una divisione dei ruoli che consente ai vari attori di specializzarsi in segmenti specifici dell’attività illecita. Questo approccio è particolarmente utile alle cyber gang ransomware, che possono così concentrarsi sulla fase di attacco vero e proprio, delegando la compromissione iniziale ad esperti del settore come gli IAB.

La Reputation del Threat Actor

ZeroSevenGroup, l’autore dell’annuncio, è un “GOD User” sul forum, un titolo che riflette un’elevata reputazione all’interno della comunità. Con 73 post e 26 thread avviati dal luglio 2024, il threat actor gode di un punteggio di reputazione di 173, segnale di un’attività prolifica e di un certo grado di fiducia tra i suoi pari. Questo livello di reputazione indica che gli acquirenti ritengono affidabile ZeroSevenGroup, un fattore cruciale in un contesto in cui le transazioni si basano interamente sull’anonimato e sulla fiducia reciproca.

L’annuncio stesso evidenzia la professionalità dell’operazione, specificando che il pagamento avverrà tramite un “trusted middleman” (intermediario affidabile), un metodo comunemente utilizzato per ridurre il rischio di frodi tra venditore e acquirente.

Un Mistero Ancora da Svelare

Mentre l’identità del dipartimento ministeriale italiano rimane ignota, l’annuncio rappresenta un allarme serio per le istituzioni del Paese. La vendita di accessi a infrastrutture governative è un attacco diretto alla sicurezza nazionale e alla fiducia nelle istituzioni. Gli esperti di cybersecurity stanno monitorando da vicino la situazione, cercando di identificare il target e di prevenire eventuali conseguenze catastrofiche.

Questo caso evidenzia ancora una volta la pericolosità del mercato degli IAB e la necessità di adottare misure di sicurezza avanzate per proteggere le reti sensibili. Nel frattempo, il mistero continua, e con esso l’ansia di capire quale potrebbe essere il prossimo capitolo di questa vicenda.

Le nostre infrastrutture governative continuano a dimostrarsi poco resilienti agli attacchi informatici, evidenziando la necessità di interventi urgenti e significativi. In questo caso, se confermato, i criminali hanno avuto un accesso molto profondo all’infrastruttura di stato, effettuando molti movimenti laterali senza che nessuno si accorgesse di nulla.

Oggi, grazie al PNRR, esiste l’opportunità di migliorare la situazione, ma il tempo stringe. Una volta terminati i fondi, affrontare queste sfide potrebbe diventare enormemente più complicato. È il momento di agire, prima che sia troppo tardi.

Ma questo noi di Red Hot Cyber lo diciamo oramai da anni.

L'articolo Il Giallo del Ministero Italiano Hackerato! In Vendita L’Accesso Per 10.000 Dollari Nelle Underground proviene da il blog della sicurezza informatica.

Dopo tre giorni di attacchi alle infrastrutture italiane da parte degli hacktivisti filorussi di NoName057(16) attraverso tecniche di DDoS, il collettivo Anonymous Italia risponde con un’azione decisa e simbolica.

Il gruppo ha dichiarato di aver defacciato 101 siti web russi legati alla biglietteria online dei trasporti pubblici, inviando quello che sembra un chiaro messaggio di ritorsione.

La “dis-CARICA dei 101”

In un post pubblicato sul loro canale Telegram, Anonymous Italia ha condiviso il risultato della loro operazione, soprannominata “La dis-CARICA dei 101”. I siti colpiti includono portali legati al sistema di biglietteria dei bus russi, che sono stati violati e defacciati“In risposta agli attacchi degli hackerini di Putin alle infrastrutture italiane avvenuti recentemente”.

La lista dei siti è davvero lunghissima, pubblicata e accessibile sul loro sito.

Il messaggio principale pubblicato da Anonymous Italia sottolinea la volontà di rispondere agli attacchi subiti in maniera proporzionata, ma senza oltrepassare i limiti di un’etica hacktivista. Lo slogan “No more web and buses for Russian occupiers!” sottolinea l’obiettivo della campagna: colpire simbolicamente per lanciare un segnale politico.
Un sito hackerato da Anonymous italia

La Tecnica del Deface

Ma cosa significa “deface” e come funziona questa tecnica?

Il deface è una delle tecniche più comuni utilizzate dagli hacktivisti per inviare un messaggio di protesta. Consiste nella modifica non autorizzata della homepage o di altre pagine di un sito web, sostituendo il contenuto originale con immagini, video o messaggi testuali. Il defacing viene spesso utilizzato per attirare l’attenzione pubblica su una causa politica o sociale.

Come Avviene il Deface?

1. Individuazione di un Accesso o di Vulnerabilità: Gli attaccanti analizzano il sito web bersaglio per rilevare account compromessi o identificare falle di sicurezza, come errori di configurazione, software non aggiornato o password deboli.
2. Accesso al Server: Una volta identificata una vulnerabilità, l’hacker sfrutta exploit o tecniche di brute force per ottenere l’accesso al server che ospita il sito.
3. Modifica dei File: Dopo aver guadagnato l’accesso, l’attaccante sostituisce i file della pagina web con quelli che contengono il messaggio o l’immagine che desidera mostrare.
4. Pubblicazione del Messaggio: Infine, il sito compromesso mostra il contenuto defacciato. Questo serve sia come segnale al pubblico sia come avvertimento ai responsabili della piattaforma.

Obiettivi del Deface

• Visibilità: Un sito defacciato è facilmente notato dagli utenti e dai media, garantendo un’ampia diffusione del messaggio, alla stessa stregua di un attacco DDoS che manda in disservizio i server.
• Danno Reputazionale: Colpire un’infrastruttura simbolica, come i sistemi di biglietteria online, può mettere in imbarazzo l’organizzazione bersaglio.
• Simbolismo: Spesso i messaggi pubblicati sono altamente simbolici e mirano a inviare un messaggio diretto ai governi o alle aziende coinvolte.

Anonymous Italia, con questa operazione, ha dimostrato ancora una volta di essere pronto a difendere gli interessi italiani e i principi di libertà e giustizia. Ma resta aperta la domanda: quanto è efficace questa “guerra di messaggi” nel vasto campo della cyberguerra globale?

Tuttavia, sarebbe opportuno che questa situazione geopolitica cambi e che i potenti del mondo facciano il necessario per ritrovare una stabilità internazionale. Una pace duratura richiede dialogo, compromesso e l’impegno collettivo per evitare ulteriori escalation nel cyberspazio e nella vita reale.

L'articolo Anonymous Italia Al Contrattacco Degli Hacker Filorussi! Occhio Per Occhio, Dente Per Dente proviene da il blog della sicurezza informatica.

[WhiskeyTangoHotel] wanted to build an LED clock after seeing some great designs online. They elected to go after a ring clock design, based around the ever-popular WS2812B addressable LEDs.

The core of the build is the HELTEC WiFi 32 development board. It’s not one we’re intimately familiar with, but it’s based around the popular Expressif ESP32. Since it’s got WiFi, it’s able to simply dial up a network time server to always keep accurate time. It then drives a set of WS2812B LEDs set up in six rings. They display the current time with a layout akin to that of a typical analog clock.

What makes this build just a little more fun is the inclusion of Disco Mode. At the press of a button, the full set of LEDs flashes out some fun dancing patterns. The clock is also programmed to trigger the same display for sixty seconds at the top of each hour.

It’s a straightforward build—what might have been highly complicated to build two decades ago has been simplified with the magic of addressable LEDs. What’s also cool is that this clock was apparently inspired by another project shared on these very pages. If you’ve been spurred to build something cool yourself, don’t hesitate to notify the tipsline!

hackaday.com/2025/01/16/neat-r…

Wolfenstein 3D was a paradigm-shifting piece of software, using raycasting techniques to create a game with pseudo-3D graphics. Now, [izabera] has done something very similar, creating a raycasting display engine that runs entirely within bash.

The work was developed with an eye cast over an existing raycasting tutorial online. As you might imagine, implementing these graphical techniques in a text console proved difficult. The biggest problem [izabera] encountered was that bash is slow. It’s not supposed to display full frames of moving content at 25+ fps. It’s supposed to display text. Making it display graphics by using tons of colorful characters is really pushing the limits. Bash also doesn’t have any ability to work with floating points, so all the calculations are done with massive integers. Other problems involved the limited ways to read the keyboard in bash, and keeping track of the display as a whole.

It’s neat reading about how this was pulled off—specifically because it was hard. It might not be the kind of project you’d ever implement for serious work, but there are learnings to be had here that you won’t get anywhere else. Code is on Github, while there’s a visual storytelling of how it came together on imgur.

We’ve seen similar work before—with magical 3D graphics generated in Microsoft Excel. Will wonders never cease? We hope not, because we always like to see new ones on the tipsline. Keep us busy!

hackaday.com/2025/01/16/buildi…

The old cable in place on the Samsung monitor. (Credit: MisterHW)
Dumpster diving is one of those experiences that can net you some pretty cool gear for a reasonable price. Case in point the 24″ Samsung S24E650XW LCD monitor that [MisterHW] saved from being trashed. Apparently in very good condition with no visible external damage, the unit even powered up without issues. It seemed like a golden find until he got onto the Windows desktop and began to notice quaint red shimmering in darker areas and other issues that made it clear why the monitor had been tossed. Of course, the second best part about dumpster diving is seeing whether you can repair such issues.

Prior to disassembly it had been noted that percussive maintenance and bending of the frame changed the symptoms, suggesting that something was a bit loose inside. After taking the back cover and shielded enclosure off, a quick visual inspection of the boards and cables quickly revealed the likely suspect: broken traces on one of the cables.

Apparently somewhere during the assembly step in the factory the cable had been pushed against the PCB’s edge, causing the initial damage. Based on the listed assembly date the monitor had only been in use for a few years before it was tossed, so likely the symptoms would have begun and worsened as one after another of the traces gradually cracked and broke due to vibrations, thermal expansion, etc.

This issue made fixing the monitor very simple, however, assuming a suitable replacement cable could be found. The broken cable is a 30P 1.0 pitch PFC, with EBay throwing up a cable with similar specs for a Thomson brand TV. One purchase and anxious wait later, the replacement cable was installed as in the featured image alongside the old cable. Perhaps unsurprisingly it restored the monitor to full working order, demonstrating once again that dumpster diving is totally worth it.

hackaday.com/2025/01/16/repair…

The Strandbeest is a walking machine, a creation of the celebrated artist Theo Jansen. They can look intimidating in their complexity, but it’s quite possible to build your own. In fact, if you’ve got a 3D-printer, it can be remarkably straightforward, as [Maker 101] demonstrates.

The build relies on an Arduino Uno as the brains. It’s equipped with an L293D motor driver shield to run two DC gear motors which drive the walking assemblies. Power is courtesy of a 3-cell lithium-polymer battery. The chassis, legs, and joints are all 3D-printed, and rather attractively in complimentary colors, we might add.

Controlling this little Strandbeest is simple. [Maker 101] gave the Arduino an infrared sensor which can pick up signals from a simple IR remote control. It can be driven backwards and forwards or turned left and right. What’s more, it looks particularly elegant as it walks—a hallmark of a good Strandbeest design.

Design files are available online for the curious. We love a good Strandbeest build, and some can even be useful, too! Video after the break.

youtube.com/embed/TuZUcjsMT5Y?…

hackaday.com/2025/01/16/buildi…

Officially, the term “taser” refers to a particular brand of projectile-firing electric stun gun. However, the word is also colloquially used to refer to just about any device intended for delivering electric shocks to an adversary. The taser ring from [Penguin DIY] definitely fits that description, though we’d strictly advise you not to consider building this at home.

The build is a hacky one. An arc generator circuit was pulled out from a jet cigarette lighter, and reconfigured to fit in a small ring-based form factor. It was hooked up with a power switch and a small bank of 30 mAh lithium polymer cell for power, and a compact USB-C charger board was installed to keep the batteries juiced. The electronics were then delicately assembled into a ring-shaped mold, which was injected with resin to produce the final ring. Once cast, a pair of small metal electrodes were installed on the outside. Activating the taser function is as simple as squeezing the ring—easy to do just by making a fist.

We’ve seen projects like these before; our advice is usually to avoid them unless you really know what you’re doing. Whether you end up shocking someone else or accidentally shocking yourself, the results tend to be bad. The latter seems particularly easy to do if you’re wearing this thing on your finger. Given it’s a ring, don’t expect to be able to pull it off in a hurry, either. It’s hard to see how that ends well.

youtube.com/embed/84kltBvDQBM?…

hackaday.com/2025/01/16/taser-…

Il Gruppo Belsen ha pubblicato file di configurazione, indirizzi IP e credenziali VPN per 15.000 dispositivi FortiGate sul dark web, consentendo ad altri criminali di accedere facilmente a queste informazioni sensibili.

Il Gruppo Belsen è stato avvistato recentemente sui social network e nei forum di hacking. Per motivi di autopromozione, il gruppo ha creato un sito sulla darknet, dove ha pubblicato un dump gratuito con le informazioni dei dispositivi FortiGate, ora liberamente disponibili ad altri criminali.

“All’inizio dell’anno, e come inizio positivo per noi, e per consolidare il nome del nostro gruppo nella vostra memoria, siamo orgogliosi di annunciare la nostra prima operazione ufficiale: saranno pubblicati dati sensibili di oltre 15.000 obiettivi in ​​tutto il mondo (sia governativi che privati) che sono stati hackerati e i cui dati sono stati estratti”

L’archivio rilasciato da 1,6 GB include cartelle ordinate per paese. All’interno di ciascuna di queste sono presenti sottocartelle contenenti dati per ciascun indirizzo IP FortiGate. Secondo l’esperto di sicurezza Kevin Beaumont, ogni cartella con un indirizzo IP contiene un file Configuration.conf (un dump della configurazione di FortiGate), nonché un file vpn-passwords.txt, in cui alcune password sono scritte in chiaro. I file di configurazione contengono anche dati sensibili, comprese chiavi private e regole del firewall.

Beaumont ritiene che questa fuga di notizie sia legata alla vulnerabilità zero-day CVE-2022-40684, che è stata attivamente sfruttata dagli aggressori anche prima del rilascio delle patch. “Ho esaminato uno dei dispositivi nell’organizzazione interessata e gli artefatti presenti su di esso indicavano lo sfruttamento di CVE-2022-40684. Ho anche potuto confermare che i nomi utente e le password del dump corrispondevano ai dati del dispositivo”, spiega Beaumont.

I dati raccolti, secondo il ricercatore, risalgono all’ottobre 2022, quando la vulnerabilità è stata attivamente esposta agli attacchi. Il motivo per cui il dump è divenuto pubblico solo ora, più di due anni dopo questi eventi, non è chiaro.

Ricordiamo che nel 2022 Fortinet ha avvertito che gli aggressori stavano utilizzando CVE-2022-40684 per scaricare file di configurazione dai dispositivi FortiGate e creare nuovi account super_admin denominati fortigate-tech-support. Come riportato all’epoca dagli analisti di Heise, la fuga di notizie riguardava dispositivi con versioni FortiOS 7.0.0–7.0.6 e 7.2.0–7.2.2. Allo stesso tempo, in FortiOS 7.2.2 il problema CVE-2022-40684 era già stato risolto, quindi non è del tutto chiaro come siano stati interessati anche i dispositivi di questa versione.

Sebbene la fuga di notizie risalga al 2022, Beaumont avverte che i dati trapelati potrebbero ancora contenere informazioni critiche, comprese regole e credenziali del firewall. L’esperto ha affermato che intende pubblicare un elenco degli indirizzi IP interessati in modo che gli amministratori di FortiGate possano verificare se i loro dispositivi sono presenti in questo elenco.

L'articolo 15.000 Dispositivi FortiGate Compromessi: Belsen Pubblica Dati sul Dark Web a Scopo Promozionale proviene da il blog della sicurezza informatica.

In the annals of human history, clocks got boring there for a while. Most were just variations on hands spinning in a circle, with the occasional tweeting bird mechanism to liven things up. These days, we’re treated to all kinds of original and oddball designs, like this neat gimbal clock from [Twisted&Tinned].

The concept of the build is straightforward enough. It has four main vertical arms, each with a servo at the base that rotates about a vertical axis. Upon each arm are between one and three servos which rotate 3D printed structures in the shape of numbers. A Wemos D1 Mini microcontroller commands the servos to the correct positions to display the current time. It also uses its WiFi connection to get accurate time updates directly from a network time server.

It’s quite an artistic build—and it’s rather enjoyable to watch this one flex and twist its way into displaying the right time. It’s also easier to read at a glance than some of the more unintelligible designs out there. Indeed, we see all kinds of neat and innovative clocks around these parts.

youtube.com/embed/-7AOQCKWUV0?…

hackaday.com/2025/01/16/gimbal…

What’s Forgotten Internet? It is the story of parts of the Internet — or Internet precursors — that you might have forgotten about or maybe you missed out on them. This time, we’re looking at Unix-to-Unix Copy, more commonly called UUCP. Developed in the late 1970s, UUCP was a solution for sending messages between systems that were not always connected together. It could also allow remote users to execute commands. By 1979, it was part of the 7th Edition of Unix.
Ken Thompson and Dennis Ritchie may have used UUCP on a PDP-11 like this one. (Photo via Computer History Museum/Gwen Bell)
Operation was simple. Each computer in a UUCP network had a list of neighbor systems. Don’t forget, they weren’t connected, so instead of an IP address, each system had the other’s phone number to connect to a dial up modem. You also needed a login name and password. Almost certainly, by the way, those modems operated at 300 baud or less.

If a computer could dial out, when someone wanted to send something or do a remote execution, the UUCP system would call a neighboring computer. However, some systems couldn’t dial out, so it was also possible for a neighbor to call in and poll to see if there was anything you needed to do. Files would go from one system to another using a variety of protocols.

Under the Hood

UUCP was popular enough to have books written about it.
While UUCP was the name of the system (and UUCPNET the network of all computers reachable by UUCP), there were actually a few programs only one of which was named uucp. That program was the user’s interface to the system.

Other programs included uux for remote command execution, uucico which was the backend, and uustat which provided status information. Every hear of uuencode and uudecode? Those started here and were meant to convert binary to text and vice-versa, since you couldn’t be sure all the modems and computers could handle 8-bit data.

When uucico answers a call, it sends a Control+P along with a string indicating its host name. The caller responds with its own Control+P and host name, along with some options. If the caller isn’t recognized, the computer will hang up.

File Transfer

If the call continues, the caller can either send a file, request a file, send commands to execute, or ask for a hangup. Sending and receiving files or commands use g-protocol. Each packet was a Control+P, a number indicating packet size or type, a 16-bit checksum, the datatype, and a check digit for the header (the checksum didn’t cover the header).

The packet size was 1 to 8, corresponding to 32-4096 bytes. In practice, many small systems would only allow a value of 2, indicating 64 bytes. The size could also be 9 to indicate a control packet. There’s a lot of detail, but that’s the gist of it.

The g-protocol uses a sliding window system, which was innovative for its time and helpful, considering that systems often had long latencies between each other. In theory, a sender could have up to seven packets outstanding while sending data. In practice, many systems were fixed at a window size of three, which was not optimal for performance.

This led to the G-protocol (uppercase), which always used 4K packets with a window of three, and some implementations could do even better.

From the user’s perspective, you simply used the uucp command like the cp command but with a host name and exclamation point:
uucp enterprise!/usr/share/alist.txt alist.txt # copy alist.txt here from enterprise
uucp request.txt starbase12!/usr/incoming/requests # copy request.txt to remote system starbase12.
You might also use uux to run a remote command and send it back to you. You could run local commands on remote files or vice versa using a similar syntax where ! is the local machine and kelvin! is a computer named kelvin that UUCP knows about.

Reading the Mail

An important use of UUCP was early e-mail. Mail programs would cooperate with UUCP. UUCP E-mail addresses contain exclamation points (bangs) to identify the whole path to your machine. So, if you lived in New York and wanted to send an e-mail to Hackaday in California, it might require this address: NY4!east.node!center!west.node!CA8!Hackaday!alwilliams.
A USENET post from 2004 (GPL via Wikipedia)
It was common, then, to provide your e-mail address relative to some “well-known” node like “…!west.node!CA8!Hackaday!alwilliams.” It was up to the sender to fill in the first part. Your mail would travel through each computer. There could easily be more than one path to …!Hackaday!alwilliams even from the same starting point and there would almost certainly be different paths from different starting hosts.

Usenet was also distributed this same way. Usenet deserves its own Forgotten Internet installment, but it was an early form of what we think of today as discussion groups.

Keep in mind that in both cases, UUCP didn’t know anything about machines more than one hop away. It was up to the mail program to understand that it was running on west.node and that it should then dial up the CA8 computer and transmit the message to it.

Versions

[Mike Lesk] at Bell Labs originally developed the code, and by 1978, there was a UUCP network of 82 Unix machines internal to Bell Labs. Around 1983, there was an AT&T rewrite known as HoneyDanBer UUCP, referencing the authors’ names, that fixed some bugs.

Then [Ian Lance Taylor] wrote a GPL version in 1991, often known as Taylor UUCP. It was flexible and could communicate with other versions of UUCP. It could also go faster when talking to another Taylor UUCP instance.

There were UUCP programs for MSDOS, CP/M, Mac OS, and VMS. Probably even more than that. It was a very popular program.

All Good Things

Of course, full-time connections to the Internet would be the beginning of the end for UUCP. Sure, you could use UUCP over a network connection instead of a dial-up modem, but why? Of course, your phone bill would definitely go down, but why use UUCP at all if you can just connect to the remote host?

In 2012, a Dutch Internet provider stopped offering UUCP to the 13 users it had left on the service. They claimed that they were likely the last surviving part of the UUCP world at that time.

Of course, you can grab your modem and set up your own UUCP setup like [Chartreuse Kitsune] did recently in the video below.

Times were different before the Internet. It is amazing that over a single lifetime, we’ve gone from 300 baud modems to over 1 petabit per second.

youtube.com/embed/3mX2b-Ljt3A?…

hackaday.com/2025/01/16/forgot…

Back in 2020, we first brought you word of the Xiaomi LYWSD03MMC — a Bluetooth Low Energy (BLE) temperature and humidity sensor that could be had from the usual sources for just a few dollars each. Capable of being powered by a single CR2032 battery for up to a year, the devices looked extremely promising for DIY smart home projects. There was only one problem, you needed to use Xiaomi’s app to read the data off of the things.

Enter [Aaron Christophel], who created an open source firmware for these units that could easily be flashed using a web-based tool from a smartphone in BLE range and opened up all sorts of advanced features. The firmware started getting popular, and a community developed around it. Everyone was happy. So naturally, years later, Xiaomi wants to put a stop to it.

The good news is, [Aaron] and [pvvx] (who has worked on expanding the original custom firmware and bringing it to more devices) have found a workaround that opens the devices back up. But the writing is on the wall, and there’s no telling how long it will be until Xiaomi makes another attempt to squash this project.

We can’t imagine why the company is upset about an extremely popular replacement firmware for their hardware. Unquestionably, Xiaomi has sold more of these sensors thanks to the work of [Aaron] and [pvvx]. This author happens to have over a dozen of them all over the house, spitting out data in a refreshingly simple to parse format. Then again, the fact that you could use the devices without going through their software ecosystem probably means they loose out on the chance to sell your data to the highest bidder…so there’s that.

The duo aren’t releasing any information on how their new exploit works, which will hopefully buy them some time before Xiaomi figures out how to patch it. In the short video below, [Aaron] shows the modified installation process that works on the newer official firmware. Unfortunately you now have to connect each unit up to the Xiaomi app before you can wipe it and install the open firmware, but it’s still better than the alternative.

youtube.com/embed/NfZHh6wmTp8?…

hackaday.com/2025/01/16/fighti…

Sometimes it’s the simplest hacks that make the biggest impact.

Take these DIY magnetic PCB vises for example. Sure, you can go out and buy purpose-built tools, but [Dylan Radcliffe] just made a trip to the hardware store for some nuts and bolts. He chose 3/8″-16 bolts, which would probably be around M10 for the rest of the world. The head of each bolt is ground flat so a ceramic disc magnet can be attached to it with CA glue, while the head of the bolt gets a plastic washer glued to it. Another plastic washer gets glued to a nut, which when threaded onto the bolt provides the light clamping force needed to hold a PCB. Make four of those and stick them to a steel plate with the magnets, and you can stop chasing your boards around the bench with a soldering iron.

As much as we like this idea — and we do; we’re heading to Home Depot to buy the needed parts this very evening — we can think of a few useful modifications. With a long bolt and two nuts rather than one, you could make a set of vises that are easily adjustable along the Z-axis. This could prove useful to those of us working under a microscope. Also, rather than making the bolts the magnetic part we bet you could lay down a flexible magnetic sheet, the kind you can feed into a printer to roll your own fridge magnets. We suspect that would hold the bolts firmly enough for most work while still allowing easy repositioning. We’d also favor flange nuts over plain hex nuts, to give a larger clamping area. We’d still include the plastic washers, though, or possibly switch to rubber ones.

There’s more than one way to skin this cat, of course, especially if you’ve got a Harbor Freight nearby and a well-stocked Lego bin.

hackaday.com/2025/01/16/simple…

Cosa accade quando un esercito di bot prende di mira un sito web di una organizzazione?

Gli attacchi DDoS (Distributed Denial of Service) rappresentano una minaccia sempre più diffusa per le organizzazioni di ogni dimensione in un contesto geopolitico sempre più teso e complesso. Anche se si tratta di un momentaneo disservizio di un sistema – come spesso riportiamo su queste pagine, il lato psicologico lo fa da padrone in quanto gli hacktivisti cercano proprio la risonanza mediatica per poter ottenere il più ampio consenso.

Quindi non si tratta di un problema meramente tecnico, ma rappresenta una vera e propria sfida psicologica. Comprendere le dinamiche psicologiche legate a questi attacchi è fondamentale per sviluppare strategie di prevenzione e risposta più efficaci per il futuro. Andiamo a esplorare le implicazioni psicologiche di questi eventi, spesso sottovalutate.

La Psicologia dell’Impatto

Un attacco DDoS è una vera e propria emergenza per gli specialisti cyber, il management delle organizzazioni e tutti gli addetti ai lavori coinvolti. La pressione di dover ripristinare il servizio il più rapidamente possibile può generare un livello di stress estremamente elevato. La paura di non riuscire a risolvere la situazione può portare a errori di giudizio e a un peggioramento delle prestazioni.

La paura

L’improvvisa interruzione dei servizi essenziali genera un senso di impotenza e paura. La percezione di essere sotto attacco può scatenare la paura soprattutto quando le conseguenze economiche sono significative. La paura è decisamente l’emozione che maggiormente si respira nella nostra società ed è la prima emozione che prova chi è colpito da un attacco cyber. Inoltre, la consapevolezza di essere vittima di un crimine digitale può provocare ansia,soprattutto quando non si riesce a individuare l’aggressore o a ripristinare rapidamente il servizio

L’ansia

La parola ansia, negli ultimi tempi, è diventata talmente comune da allargare il suo utilizzo fino ad indicare, potenzialmente, qualsiasi situazione di paura o di incertezza. Ma siccome i modelli (anche linguistici) ci forgiano, è utile fare un pò di chiarezza sul significato del termine.

A differenza della paura, scatenata da un fatto preciso e destinata ad esaurirsi quando il pericolo si allontana, l’ansia può durare anche parecchio tempo. Può essere fisiologica o patologica. Quella generata da un attacco cyber, solitamente, è fisiologica e può durare anche diversi giorni. È costituita da un incrementarsi repentino di sensazioni paurose ed è legata a motivazioni reali.

Un attacco cyber, infatti, oltre agli stop dell’operatività ed agli enormi esborsi di denaro necessari a ripristinare i sistemi informatici compromette la reputazione aziendale. Il personale IT si trova spesso sotto pressione per ripristinare il sistema e per garantire la sicurezza informatica dell’azienda. Dovendo comunicare con il Management e spiegare la situazione con un continuo aggiornamento sul ripristino del sistema,vive dei veri e propri giorni di fuoco e corre sempre contro il tempo!

La consapevolezza di essere vittima di un crimine digitale può provocare rabbia e frustrazione, soprattutto quando non si riesce a individuare l’aggressore o a ripristinare rapidamente il servizio.

Chi è chiamato a gestire l’emergenza può sperimentare anche un forte burnout a causa dello stress e della pressione di dover risolvere rapidamente il problema.

Strategie di Difesa

Mitigare le conseguenze psicologiche degli attacchi DDoS richiede un approccio olistico che coinvolga sia l’azienda che i suoi leader. Investendo nella comunicazione, nel supporto psicologico e nella creazione di una cultura della sicurezza, le aziende possono proteggere non solo i propri sistemi informatici, ma anche il benessere dei propri dipendenti.

Azioni per le Organizzazioni

• Tempestività: informare tempestivamente i dipendenti e i clienti sull’accaduto, evitando speculazioni e allarmismi.
• Chiarezza: fornire informazioni chiare e comprensibili sull’entità del problema, sulle azioni intraprese e sui tempi di risoluzione.
• Empatia: esprimere comprensione per le preoccupazioni e le ansie dei dipendenti.
• Assistenza psicologica: mettere a disposizione servizi di assistenza psicologica per i dipendenti che ne hanno bisogno.
• Programmi di benessere: promuovere programmi di benessere aziendale che includano attività di mindfulness, yoga o altre tecniche di gestione dello stress.
• Workshop: organizzare workshop e seminari per aiutare i dipendenti a sviluppare competenze di resilienza e gestione dello stress.
• Simulazioni: simulare scenari di attacco per preparare i dipendenti a reagire in modo efficace in caso di emergenza.
• Incentivi: riconoscere e premiare i comportamenti virtuosi in materia di sicurezza.
• Sensibilizzazione: organizzare campagne di sensibilizzazione sulla sicurezza informatica per coinvolgere tutti i dipendenti.

Azioni per i Leader

• Essere un esempio: mostrare calma e determinazione di fronte alla crisi, trasmettendo un senso di sicurezza ai dipendenti.
• Empatia: essere empatici e comprensivi nei confronti delle preoccupazioni dei dipendenti.
• Delegare: affidarsi al team e affidare ai responsabili delle diverse aree le azioni da intraprendere per gestire la crisi.
• Monitorare: monitorare costantemente la situazione e fornire supporto ai team coinvolti.
• Collaborare: coinvolgere esperti e collaborare con altre aziende che hanno subito attacchi simili per condividere esperienze e best practice.

Perché è importante tutto questo?

• Aumenta la resilienza aziendale: un’azienda con dipendenti resilienti è più preparata ad affrontare le crisi e a riprendersi rapidamente.
• Migliora la reputazione aziendale: un’azienda che dimostra di prendersi cura dei propri dipendenti e di gestire le crisi in modo efficace rafforza la propria reputazione.
• Riduce il turnover: un ambiente di lavoro positivo e sicuro contribuisce a ridurre il turnover del personale.

Conclusioni

Gli attacchi DDoS non sono solo una minaccia tecnologica, ma una vera e propria battaglia psicologica.

Un attacco DDoS è come un terremoto che scuote le fondamenta della nostra società digitale. Le scosse possono essere contenute, ma le onde d’urto psicologiche si propagano a lungo, lasciando segni indelebili.

È nostro dovere costruire edifici più resistenti, sia fisicamente che psicologicamente. Per difenderci efficacemente, dobbiamo investire non solo in soluzioni tecniche, ma anche nella salute mentale dei nostri team.

È tempo di riconoscere che la cybersecurity è una disciplina che coinvolge tanto la mente quanto la macchina.

Il futuro della cybersecurity non è solo tecnologico, ma anche umano.

Dietro ogni attacco DDoS c’è una persona, una mente che ha deciso di seminare caos e distruzione.

La difesa contro gli attacchi DDoS richiede un approccio multidisciplinare che combini le più avanzate tecnologie di sicurezza con una profonda comprensione della psicologia umana. Solo così potremo proteggere le nostre infrastrutture critiche e garantire la continuità dei servizi essenziali.

Immaginiamo un mondo in cui la resilienza psicologica sia parte integrante delle nostre difese informatiche.

Un mondo in cui gli attacchi DDoS non siano più una minaccia, ma un’opportunità per rafforzare la nostra connessione umana.

L'articolo Italia e Attacchi DDoS: Quando il Caos Psicologico È Più Devastante del Blackout Tecnologico! proviene da il blog della sicurezza informatica.

I ricercatori hanno notato che nel periodo da ottobre a dicembre 2024, Telegram ha iniziato a fornire più spesso dati sugli utenti alle forze dell’ordine. Così, da gennaio a settembre 2024, Telegram ha accolto 14 richieste delle autorità americane relative alla divulgazione di indirizzi IP e numeri di telefono, che hanno interessato un totale di 108 utenti. Ma in tutto il 2024 le richieste di questo tipo sono state 900, per un totale di 2.253 utenti interessati.

Questi dati sono forniti dai giornalisti della pubblicazione 404 Media che hanno utilizzato il bot ufficiale Telegram Transparency Reports, che fornisce rapporti sulla trasparenza e statistiche sulla divulgazione dei dati degli utenti su richiesta del tribunale.

I giornalisti sottolineano che la stragrande maggioranza delle richieste completate è avvenuta nell’ultimo trimestre del 2024.

Vale la pena notare che le autorità americane non sono le prime in termini di numero di tali richieste. Secondo le statistiche del progetto di crowdfunding, supervisionato dal dipendente di Human Rights Watch Etienne Maynier, l’India è con un ampio margine leader in questo settore: nel 2024 Telegram ha soddisfatto 14.641 richieste provenienti da questo paese e ha comunicato alla legge i dati di 23.535 utenti. agenti delle forze dell’ordine.

La pubblicazione rileva che il forte aumento nella divulgazione dei dati degli utenti è chiaramente correlato all’arresto di Pavel Durov (detenuto in Francia nell’agosto 2024), nonché al fatto che poco dopo l’arresto di Durov la piattaforma ha modificato i suoi Termini di servizio e Informativa sulla privacy.

Come promemoria, gli indirizzi IP e i numeri di telefono delle persone che violano le regole di Telegram potrebbero essere divulgati alle autorità competenti in risposta a “richieste legali valide”. Ma se in precedenza i Termini di servizio prevedevano che Telegram potesse divulgare i dati dell’utente solo se fosse un sospetto terrorista, allora da settembre 2024 ciò sarà possibile “se Telegram riceve una richiesta ufficiale dalle autorità giudiziarie competenti, che confermi che siete sospettati in un procedimento penale per azioni illegali che violano l’Accordo con l’utente di Telegram.”

Questi cambiamenti sono stati precedentemente commentati dallo stesso Pavel Durov. Ha scritto che l’anno scorso gli sviluppatori di Telegram hanno reso la ricerca “molto più sicura” e ha osservato che anche prima che venissero apportate modifiche ai Termini di servizio e all’Informativa sulla privacy, dal 2018 il messenger poteva rivelare alle autorità gli indirizzi IP e i numeri di telefono dei sospetti nella maggior parte dei paesi .

L'articolo Telegram Cambia Pelle! Arriva il Boom Delle Divulgazioni alle Autorità nel 2024 proviene da il blog della sicurezza informatica.

The humble piezo disc buzzer is much more than something that makes tinny beeps in retro electronic equipment, it can also be used as a sensor. Tapping a piezo buzzer gives an interesting waveform, with a voltage spike followed by an envelope, and then a negative rebound voltage. It’s something [Igor Brichkov] is using, to make a simple but effective electronic drum.

First of all, the output of the buzzer must be tamed, which he does by giving it a little impedance to dissipate any voltage spikes. There follows some simple signal conditioning with passive components, to arrive at an envelope for the final drum sound. How to turn a voltage into a sound? Using a voltage controlled amplifier working on a noise source. The result is recognizably the drum sound, entirely in electronics.

In a world of digital music it’s easy to forget the simpler end of sound synthesis, using circuits rather than software. If you hanker for the Good Old Days, we have an entire series on logic noise, doing the job with 4000 series CMOS logic.

youtube.com/embed/R2vQ3F3-Kuk?…

hackaday.com/2025/01/15/piezo-…

A couple of years ago one of the Hackaday Prize finalists was a project to take highschoolers through building a direct conversion radio receiver for the 40 metre amateur band. It was originated by the SolderSmoke podcast, and we’re pleased to see that they’ve recently put up an overview video taking the viewer through the whole project in detail.

It’s a modular design, with all the constituent building blocks broken out into separate boards on which the circuitry is built Manhattan style. Direct conversion receivers are pretty simple, so that leaves us with only four modules for oscillator, bandpass filter, mixer, and audio amplifier. We particularly like that it’s permeability tuned using a brass screw and an inductor, to make up for the once-ubiquitous variable capacitors now being largely a thing of the past.

A point that resonated was that most radio amateurs never make something like this. Arguments can be made about off-the-shelf rigs and chequebook amateurs, but we’d like to suggest that everyone can benefit from a feel for analogue circuitry even if they rarely have a need for a little receiver like this one. We like this radio, and we hope you will too after seeing the video below the break.

Need reminding? See the Hackaday.io project page, and the Hackaday Prize finalists from that year.

youtube.com/embed/rLjxU2rMeXw?…

hackaday.com/2025/01/15/a-dire…

Raspberry Pi’s new microcontroller, the RP2350, has a small section of memory that is meant for storing secrets. It’s protected by anti-glitching and other countermeasures, and the Raspberries wanted to test it. So this summer, they gave them out, pre-programmed with a secret string, as part of the badge for DEFCON attendees. The results of the cracking efforts are in, and it’s fair to say that the hackers have won.

First place went to [Aedan Cullen], who also gave a great talk about how he did it at 38C3. One of the coolest features of the RP2350, from a hacker perspective, is that it has dual ARM and dual RISC-V cores onboard, and they can be swapped out by multiplexers. The security module has a critical register that has disable bits for both of these processors, but it turns out that the ARM disable bits have priority. When [Aedan] glitched the security module just right, it disabled the ARM cores but left the RISC-V cores running in the secure context, with full debug(!), and the game was over. As of yet, there is no mitigation for this one, because it’s baked into the secure boot module’s silicon.

[Marius Muench] managed to pre-load malicious code into RAM and glitch a reboot-out-of-secure-mode on the USB module. This one is possibly fixable by checking other reboot flags. [Kévin Courdesses] has a sweet laser fault-injection rig that’s based on the 3D-printable OpenFlexure Delta Stage, which we’ve seen used for microscopy purposes, but here he’s bypassing the anti-glitching circuitry by exposing the die and hitting it hard with photons.

Finally, [Andrew Zonenberg] and a team from IOActive went at the RP2350 with a focused ion beam and just read the memory, or at least the pairwise-OR of neighboring bits. Pulling this attack off isn’t cheap, and it’s a more general property of all anti-fuse memory cells that they can be read out this way. Chalk this up as a mostly-win for the offense in this case.

If you want to read up on voltage glitching attacks yourself, and we promise we won’t judge, [Matthew Alt] has a great writeup on the topic. And ironically enough, one of his tools of choice is [Colin O’Flynn]’s RP2040-based Chip Shouter EMP glitcher, which he showed us how to make and use in this 2021 Remoticon talk.

hackaday.com/2025/01/15/all-th…

These days, anything with copper in it is expensive. If you doubt that, a walk into any Home Depot electrical department, where the wire is locked up tighter than Fort Knox, will prove otherwise. Coaxial cable is a particularly expensive species, which is a pity for hams and other radio enthusiasts since it’s the only thing we can use for antenna feedlines.

Or is it? [Steve (VE6WZ)] has found a way to use ordinary Cat 6 Ethernet cable for antenna feed lines that seems pretty clever. As he points out, Ethernet cables are designed to handle frequencies that coincide nicely with most of the interesting amateur radio bands, and their insertion losses are acceptably low, especially for Cat 6 cable. The twisted pairs are also a balanced system that’s good at rejecting common mode noise. Cat 6 cable also has four pairs of conductors, allowing you to feed multiple antennas with one cable, or to distribute power to amplifiers and switches along with antenna feeds.

The downside? Cat6 conductor pairs have a characteristic impedance of around 100 ohms, which isn’t a match for the 50-ohm feedline impedance universally expected by ham radios. Also, the relatively small wires probably aren’t up to the job of carrying much current, limiting their use to feedlines for receive-only antennas. That works for [Steve] since he uses Cat 6 to support his massive Beverage antenna farm (Beverage antennas are non-resonant horizontal antennas that live close to the ground and point in the direction of the signal, rather than broadside to the signal as with a resonant antenna like a dipole.) Each antenna in his farm has a transimpedance amplifier that needs to be powered, plus switching relays so he can turn the correct antennas on for the signals he wants to receive. He describes the amps in detail in the video below, along with the custom impedance-matching transformers he uses and the combining gear.

Coax will probably still be the cable of choice for most feedline applications, but it’s nice to know there are alternatives. And who knows—if you stick to QRP work, maybe Cat 6 could even be used for transmitting.

youtube.com/embed/i44PU8NJf1M?…

hackaday.com/2025/01/15/forget…

This week, Jonathan Bennett and Aaron Newcomb chat with Simon Phipps and Stefano Maffulli about Open Source AI. Why did we need a new definition? Has it been controversial? And why did OSI step into this particular conversation?

• opensource.org/ai

youtube.com/embed/qQlw25Vwgzc?…

Did you know you can watch the live recording of the show Right on our YouTube Channel? Have someone you’d like us to interview? Let us know, or contact the guest and have them contact us! Take a look at the schedule here.

play.libsyn.com/embed/episode/…

Direct Download in DRM-free MP3.

If you’d rather read along, here’s the transcript for this week’s episode.

Places to follow the FLOSS Weekly Podcast:

• Spotify
• RSS

Theme music: “Newer Wave” Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 4.0 License

hackaday.com/2025/01/15/floss-…

The EPFL LisRaptor with adjustable wings and tail.
Throughout evolution, the concept of powered flight has evolved and refined itself multiple times across both dinosaurs (birds), mammals (bats) and insects. So why is it that our human-made flying machines are so unlike them? The field of nature-inspired flying drones is a lively one, but one that is filled with challenges. In a recent video on the Ziroth YouTube channel, [Ryan Inis] takes a look at these efforts, in particular those of EPFL, whose recent RAVEN drone we had a look at recently already.

Along with RAVEN, there is also another project (LisRaptor) based on the Northern Goshawk, a bird of prey seen in both Europe and North-America. While RAVEN mostly focused on the near-vertical take-off that smaller birds are capable of, this project studies the interactions between the bird’s wings and tail, and how these enable rapid changes to the bird’s flight trajectory and velocity, while maintaining efficiency.

The video provides a good overview of this project. Where the LisRaptor differs from the animal is in having a rudder and a propeller, but the former should ideally not be necessary. Obviously the kinematics behind controlled flight are not at all easy, and the researchers spent a lot of time running through configurations aided by machine learning to achieve the ideal – and most efficient – wing and tail configuration. As these prototypes progress, they may one day lead to a drones that are hard to differentiate from birds and bats.

youtube.com/embed/al-PRRAs2vI?…

hackaday.com/2025/01/15/avian-…

From a practical standpoint, [John] may be correct that his recent creation is the “world’s worst digital dash”, but we’re still oddly enamored with the idea of using a Nintendo Game Boy as a digital speedometer. Pulling it off meant interfacing the handheld with the vehicle’s CAN bus system, so whether you’re into retro gaming or car hacking, this project has something to offer.

Showing real-time vehicle speed on the Game Boy sounds like it should be relatively easy, but the iconic game system wasn’t exactly built for such a task. Its 2 MHz CPU and 160×144 pixel dot-matrix screen were every kid’s dream in 1989, but using it as a car dashboard is pushing it. To bridge that gap, [John] designed two custom circuit boards. One interfaces with the Game Boy, intercepting its memory requests and feeding it data from a microcontroller. The other processes the CAN bus signals, translating speed information into a form the Game Boy can display. [John] used inexpensive tools and software to read the CAN bus data, and used GBDK-2020 to write the software in C. His video goes in great detail on how to do this.

Months of work have gone into decoding the Game Boy’s data bus and creating a schematic for the interface board. Tricking the Game Boy into thinking it was loading a game, while actually displaying incoming speed data. The screen’s low resolution and slow refresh rate rendered it barely readable in a moving vehicle. But [John]’s goal wasn’t practicality — it was just proving it could be done.

Want to dive deep into the Game Boy? Have you seen the Ultimate Game Boy talk?

youtube.com/embed/xroxYBp9DOo?…

hackaday.com/2025/01/15/a-game…

Full disclosure: ham radio isn’t for everyone, and there are many different facets to it. What appeals to one person might bore another to death. One area of ham radio that has changed a lot in the last few years is more or less local and typically mobile operation on VHF or UHF. Not long ago, hams used HTs (walky-talkies or handi-talkies) or mobile radios via repeaters to talk to each other and — the golden prize back then — make phone calls from their cars. Cell phones have made that much less interesting, but there is still an active community of operators talking on repeaters. However, the traffic has gone digital, the Internet is involved, and people with inexpensive, low-powered radios can talk to each other across the globe. This is nothing new, of course. However, having digital services means that operators with special interests can congregate in what amounts to radio chat rooms organized by region or topic.

There’s a long history of people listening to ham radio conversations with shortwave radios, SDRs, and scanners. But with so much activity now carried on the Internet, you can listen in using nothing more than your web browser or a phone app. I’ll show you how. If you get interested enough, it is easy enough to get your license. You don’t need any Morse code anymore, and a simple Technician class license in the United States is all you need to get going.

A Quick DMR Primer

There are several digital ham networks around and like real networks, you can have different physical transport layers and then build on top of that. For the purposes of this post, I’m going to focus on DMR (digital mobile radio) on the Brandmeister network which is very large and popular ham network. You won’t need a license nor will you need to sign up for anything as long as you are content to just listen.

Here’s how it works: Brandmeister operates a large number of servers worldwide that communicate with each other and provide calling services, including group calls. So, if we set up a Hackaday talk group (fictitious, by the way) on group 1337, interested people could connect to that talk group and have a conversation.

Since we are just going to listen, I’m going to skip some of the details, but the trick is how people get to talk to these networks. In general, there are three ways. The classic way is to use a digital radio to talk to a repeater that is connected to the network. The repeater may have one or more talk groups on all the time, or you might request access to one.

However, another way to connect your radio to a “hotspot” connected to the Internet. That is, more or less, a special form of repeater that is very low power, and you have complete control over it compared to a repeater on some faraway hill. However, if you don’t mind operating using just a computer, you don’t need a radio at all. You simply talk directly to the nearest server, and you are on the network. Some of your audio will go to other computers, and it may go over the airwaves via someone else’s hotspot or repeater.

Talk Groups

Just a few of the 1,600+ talkgroups available on the network
The Brandmeister website has a lot of info and you don’t need to be logged in to see it. Head over to their site and you’ll see a lot of info including a network map and statistics about repeaters and hotspots. You can get an idea of who has been talking lately by clicking Last Heard link. While this is interesting, it isn’t as interesting as you’d think, because you really want to focus on talk groups, not individual users.

To see a list of all the talk groups on the system, you can click Information and then Talkgroups. You can filter the list and you can also download the dataset in different formats if you want to browse it in a different format.
The hoseline shows you all the activity across the network and lets you listen in, too.
There are three buttons on each row of the database. The LH button shows you the last heard stations for that group. The Wiki button takes you to a Wiki page that, for some groups, has more information about it. But the really interesting button is the one marked Hoseline. You can also open the Hoseline directly which is what I usually do.

What’s the Hoseline? It shows activity across the network as a bunch of boxes indicating recently active talk groups. Boxes with red lines around them have people actively talking on them. The others have been recently active. It is visually interesting, yes, but that’s not the big selling point.

If you click on a box, you will hear the activity on that talk group. That’s all there is to it.

Overwhelming

There are a lot of talk groups. You can filter at the top left part of the page where it says “Everything.” You’ll have to drop the list down and unselect Everything. Then, you can select any countries or areas you want to follow. If you are brave, you can click RegEx mode and enter regular expressions to match talk group numbers (e.g. ^310.*).

The “Player” button at the top right gives you more control. You can add multiple groups from a list, see information about who is talking, and stop or start the audio.
The hose is available on Android, too.
If you prefer to do your listening mobile, you can also get the hoseline on your Android device. Just install the app, and you’ll find it works the same way.

Finding Something Interesting

Lord Nelson once said, “The greatest difficulty in war is not to win the battle, but to find the enemy.” That’s accurate here, too. Finding an interesting conversation out of all those talk groups is somewhat a needle in a haystack. A quick look around at the talk group lists might help.

The 91 and 93 groups stay busy but generally with short exchanges since they cover a wide area. The USA bridge at 3100 sometimes has traffic, too.
Talk group 31484 (SE Texas) has 66 devices attached, some of which you can see here.
If you look at the group’s listing on the Web, you can click the group number and see what stations are connected to it. Keep in mind, some of these may be repeaters or gateways that could have no one on the other side, or could have dozens of people on the other side. But it can give you an idea if the talkgroup has any users at all.

You can also search the Internet for DMR nets and repeaters. Sometimes, it is interesting to listen to local repeaters. Sometimes, it is fun to listen to repeaters in other places. Want to find out what’s going on at your next vacation spot? Practice your French?

You can find many DMR repeaters using the RepeaterBook search page. There are also man lists of DMR nets.

Next Steps

There are many other similar networks, but they may not have a way to listen that doesn’t require some software, registration, or licenses. There’s plenty on Brandmeister to keep you busy. If you worry about people listening in, that’s no different than regular radio has been since the beginning.

You can always get your ham license and join in. Even without a radio, there are ways to talk on the network. [Dan Maloney] has advice for getting your “ticket.” It is easier than you think, and you can do a lot more with a license, including talking through satellites, sending TV signals over the air, and bouncing signals of meteors or the moon. If you want to listen to more traditional ham radio in your browser, try a Web-based SDR.

hackaday.com/2025/01/15/no-ham…

I ricercatori hanno scoperto una nuova versione dell’infostealer Banshee progettato per macOS. Il malware non controlla più se sui sistemi infetti è installata la lingua russa ed elude il rilevamento utilizzando la crittografia delle stringhe di Apple XProtect.

Ricordiamo che Banshee è un infostealer rivolto ai sistemi che eseguono macOS. È stato avvistato per la prima volta a metà del 2024. Quindi ha funzionato secondo lo schema stealer-as-a-service, e poteva raccogliere dati da browser, portafogli di criptovaluta e file che soddisfacevano determinati criteri. Il malware veniva venduto sulla darknet per 3.000 dollari al mese.

Nel novembre 2024, il codice sorgente del ladro è stato pubblicato sui forum di hacking, dopodiché il progetto è stato chiuso, ma altri criminali hanno avuto l’opportunità di creare il proprio malware basato su Banshee.

Come riferiscono ora gli esperti di Check Point , hanno scoperto una nuova variante di Banshee che è ancora attiva oggi e utilizza un nuovo metodo di crittografia che gli consente di eludere meglio il rilevamento. Inoltre, questa versione dello stealer non evita più i sistemi degli utenti russi, il che significa che gli aggressori cercano di ampliare la gamma dei possibili bersagli degli attacchi.

Apple XProtect è una tecnologia di rilevamento malware integrata in macOS. Utilizza una serie di regole, simili alle firme antivirus, per identificare e bloccare le minacce conosciute. La variante Banshee osservata dai ricercatori utilizza l’algoritmo di crittografia delle stringhe utilizzato da XProtect per proteggere i propri dati. Crittografando le stringhe e decrittografandole solo in fase di esecuzione, Banshee evita i metodi di rilevamento statico standard. Inoltre, gli esperti ritengono che anche macOS stesso e gli strumenti di sicurezza di terze parti trattino questo metodo di crittografia con meno sospetto, il che consente al ladro di rimanere inosservato più a lungo.

I ricercatori notano che questa versione di Banshee è distribuita principalmente attraverso repository fraudolenti su GitHub, che presumibilmente offrono vari software. Allo stesso tempo, gli operatori di malware attaccano anche gli utenti Windows, ma utilizzando lo stealer Lumma.

L'articolo Nuova Variante di Banshee per Apple macOS: Il Malware che Elude Apple XProtect proviene da il blog della sicurezza informatica.