We’ll take a guess that most readers have a set of digital calipers somewhere close to hand right now. The cheapest ones tend to be a little unsatisfying in the hand, a bit crusty and crunchy to use. But as [Matthias Wandel] shows us, these budget tools are quite hackable and a lot more precise than they appear to be.

[Matthias] is perhaps best known around these parts for making machine tools using mainly wood. It’s an unconventional material for things like the CNC router he loves to hate, but he makes it work through a combination of clever engineering and a willingness to work within the limits of the machine. To assess those limits, he connected some cheap digital calipers to a Raspberry Pi by hacking the serial interface that seems to be built into all of these tools. His particular calipers output a pair of 24-bit words over a synchronous serial connection a couple of times per second, but at a level too low to be read by the Pi. He solved this with a clever resistor ladder to shift the signals to straddle the 1.8 volt transition on the Pi, and after solving some noise problems with a few strategically placed capacitors and some software debouncing, he was gathering data on his Pi.

Although his setup was fine for the measurements he needed to make, [Matthias] couldn’t help falling down the rabbit hole of trying to milk better resolution from the calipers. On paper, the 24-bit output should provide micron-ish resolution, but sadly, the readings seem to fluctuate rapidly between two levels, making it difficult to obtain an average quickly enough to be useful. Still, it’s a good exercise, and overall, these hacks should prove handy for anyone who wants to dip a toe into automated metrology on a budget.

youtube.com/embed/0PA-KvnAwJM?…

Thanks to [Dragan] for the tip.

hackaday.com/2025/03/06/hackin…

If you came of age in the 1990s, you’ll remember the unmistakable auditory handshake of an analog modem negotiating its connection via the plain old telephone system. That cacophony of screeches and hisses was the result of careful engineering. They allowed digital data to travel down phone lines that were only ever built to carry audio—and pretty crummy audio, at that.

Speeds crept up over the years, eventually reaching 33.6 kbps—thought to be the practical limit for audio modems running over the telephone network. Yet, hindsight tells us that 56k modems eventually became the norm! It was all thanks to some lateral thinking which made the most of the what the 1990s phone network had to offer.

Breaking the Sound Barrier

The V.34 standard enabled transmission at up to 33.6 kbps, though many modems topped out at the lower level of 28.8 kpbs in the mid-1990s. Credit: Raimond Spekking, CC BY-SA 4.0
When traditional dial-up modems communicate, they encode digital bits as screechy analog tones that would then be carried over phone lines originally designed for human voices. It’s an imperfect way of doing things, but it was the most practical way of networking computers in the olden days. There was already a telephone line in just about every house and business, so it made sense to use them as a conduit to get computers online.

For years, speeds ticked up as modem manufacturers ratified new, faster modulation schemes. Speeds eventually reached 33.6 kbps which was believed to be near the theoretical maximum speed possible over standard telephone lines. This largely came down to the Shannon limit of typical phone lines—basically, with the amount of noise on a given line, and viable error correcting methods, there was a maximum speed at which data could reliably be transferred.

In the late 1990s, though, everything changed. 56 kbps modems started flooding the market as rival manufacturers vied to have the fastest, most capable product on offer. The speed limits had been smashed. The answer lay not in breaking Shannon’s Law, but in exploiting a fundamental change that had quietly transformed the telephone network without the public ever noticing.

Multiplexing Madness

Linecards in phone exchanges were responsible for turning analog signals into digital signals for further transmission through the phone network. Credit: Pdesousa359, CC BY-SA 3.0
In the late 1990s, most home users still connected to the telephone network through analog phone lines that used simple copper wires running to their houses, serving as the critical “last mile” connection. However, by this time, the rest of the telephone network had undergone a massive digital transformation. Telephone companies had replaced most of their long-distance trunks and switching equipment with digital technology. Once a home user’s phone line hit a central office, it was usually immediately turned into a digital signal for easier handling and long-distance transmission. Using the Digital Signal 0 (DS0) encoding, phone calls became digital with an 8 kHz sample rate using 8-bit pulse code modulation, working out to a maximum data rate of 64 kbps per phone line.

Traditionally, your ISP would communicate over the phone network much like you. Their modems would turn digital signals into analog audio, and pipe them into a regular phone line. That analog audio would then get converted to a DS0 digital signal again as it moved around the back-end of the phone network, and then back to analog for the last mile to the customer. Finally, the customer’s modem would take the analog signal and turn it back into digital data for the attached computer.

This fell apart at higher speeds. Modem manufacturers couldn’t find a way to modulate digital data into audio at 56 kbps in a way that would survive the DS0 encoding. It had largely been designed to transmit human voices successfully, and relied on non-linear encoding schemes that weren’t friendly to digital signals.

The breakthrough came when modem manufacturers realized that ISPs could operate differently from end users. By virtue of their position, they could work with telephone companies to directly access the phone network in a digital manner. Thus, the ISP would simply pipe a digital data directly into the phone network, rather than modulating it into audio first. The signal remained digital all the way until it reached the local exchange, where it would be converted into audio and sent down the phone line into the customer’s home. This eliminated a whole set of digital-to-analog and analog-to-digital conversions which were capping speeds, and let ISPs shoot data straight at customers at up to 56 kbps.
The basic concept behind 56 kbps operation. So-called “digital modems” on the ISP side would squirt digital signals directly into the digital part of the phone network. These would then be modulated to analog just once at the exchange level to travel the last mile over the customer’s copper phone line. Credit: ITU, V.90 standard
This technique only worked in one direction, however. End users still had to use regular modems, which would have their analog audio output converted through DS0 at some point on its way back to the ISP. This kept upload speeds limited to 33.6 kbps.
USRobotics was one of the innovators in the 56k modem space. Note the x2 branding on this SPORTSTER modem, denoing the company’s proprietary modulation method. Credit: Xiaowei, CC BY 3.0
The race to exploit this insight led to a minor format war. US Robotics developed its x2 standard, so named for being double the speed of 28k modems. Rival manufacturer Rockwell soon dropped the K56Flex standard, which levied the same trick to up speeds. ISPs quickly began upgrading to work with the faster modems, but consumers were confused with the competing standards.

The standoff ended in 1998 when the International Telecommnication Union (ITU) stepped in to create the V.90 standard. It was incompatible with both x2 and K56Flex, but soon became the industry norm.. This standardization finally allowed for interoperable 56K communications across vendors and ISPs. It was soon supplanted by the updated V.92 standard in 2000, which increased upload speeds to 48 kbps with some special upstream encoding tricks, while also adding new call-waiting and quick-connect features.

Final Hurrah

Despite the theoretical 56 kbps limit, actual connection speeds rarely reached such heights. Line quality and a user’s distance from the central office could degrade performance, and power limits mandated by government regulations made 53 kbps a more realistic peak speed in practice. The connection negotiation process users experienced – that distinctive modem “handshake” – often involved the modems testing line conditions and stepping down to the highest reliable speed. Despite the limitations, 56k modems soon became the norm as customers hoped to achieve a healthy speed boost over the older 33.6k and 28k modems of years past.

The 56K modem represents an elegant solution for a brief period in telecommunications history, when analog modems still ruled and broadband was still obscure and expensive. It was a technology born when modem manufacturers realized the phone network they were now working with was not the one they started with so many decades before. The average consumer may never have appreciated the nifty tricks that made the 56k modem work, but it was a smart piece of engineering that made the Internet ever so slightly more usable in those final years before DSL and cable began to dominate all.

hackaday.com/2025/03/06/why-56…

Negli ultimi giorni, un utente del forum underground “BreachForums” ha pubblicato un annuncio riguardante la presunta vendita di accessi a caselle di posta elettronica appartenenti al Ministero dell’Interno italiano (dominio “@interno.it”).

La notizia, al momento non confermata da fonti istituzionali, desta particolare preoccupazione poiché, qualora fosse fondata, potrebbe comportare serie implicazioni a livello di sicurezza nazionale.

Dettagli del Possibile Breach

• Origine del Post: L’inserzione compare su un popolare forum underground in cui spesso circolano dati sottratti a enti governativi o aziende di rilievo. L’autore si identifica con il nickname “DataSec” e risulta avere un discreto livello di “reputazione” sulla piattaforma.
• Data di Pubblicazione: Il post è stato pubblicato il 3 marzo 2025 e, secondo i metadati del forum, è stato modificato una volta nella mattinata del 4 marzo.
• Oggetto della Vendita: “DataSec” asserisce di possedere credenziali e accessi interni a varie caselle di posta riconducibili al Ministero dell’Interno italiano (dominio “@interno.it”). Vengono offerte dietro compenso in criptovaluta, secondo un metodo di pagamento ricorrente nel panorama cybercriminale.

Attendibilità della Fonte

BreachForums è noto per ospitare annunci di compravendita di dati sottratti, spesso veritieri, ma non mancano casi di “fake listing” finalizzati a truffare possibili acquirenti. Attualmente, non risultano prove tangibili (come dump di dati o screenshot comprovanti la compromissione) che confermino la reale esistenza di tali credenziali.

Red Hot Cyber (RHC) continuerà a monitorare la situazione, prestando particolare attenzione a eventuali evoluzioni della discussione su BreachForums o alla comparsa di ulteriori elementi di prova in altri ambienti sotterranei e canali Telegram di settore.

• Pubblicazioni Future: Se il Ministero dell’Interno o altre istituzioni rilasceranno comunicati ufficiali, RHC ne darà tempestivo riscontro, dedicando un articolo specifico alle dichiarazioni e alle evidenze emergenti.
• Segnalazioni Anonymous: Chiunque fosse a conoscenza di dettagli aggiuntivi o potesse fornire riscontri utili, può contattarci attraverso la nostra mail crittografata, garantendo il massimo livello di riservatezza.

Conclusioni

La presunta vendita di accessi email legati al Ministero dell’Interno italiano costituisce un potenziale campanello d’allarme per la sicurezza istituzionale. Sebbene al momento le informazioni disponibili non permettano di confermare l’effettiva compromissione, è fondamentale mantenere un alto grado di vigilanza e procedere, se necessario, con verifiche tecniche e legali approfondite.

La prudenza e la trasparenza sono elementi essenziali in circostanze in cui anche solo il dubbio di una violazione può minare la fiducia dei cittadini e la credibilità delle istituzioni coinvolte. RHC resta a disposizione per ospitare eventuali comunicazioni ufficiali e fornire aggiornamenti, qualora emergano sviluppi significativi.

Questo articolo è stato redatto attraverso l’utilizzo della piattaforma Recorded Future, partner strategico di Red Hot Cyber e leader nell’intelligence sulle minacce informatiche, che fornisce analisi avanzate per identificare e contrastare le attività malevole nel cyberspazio.

L'articolo Ministero dell’Interno Italiano sotto attacco? Accessi email in vendita nei forum underground! proviene da il blog della sicurezza informatica.

If you’re familiar with Java here in 2025, the programming language you know is a world away from what Sun Microsystems planned for it in the mid-1990s. Back then it was key to a bright coffee-themed future of write-once-run-anywhere software, and aside from your web browser using it to run applications, your computer would be a diskless workstation running Java bytecode natively on the silicon.

What we got was slow and disappointing Java applets in web pages, and a line of cut-down SPARC-based JavaStations which did nothing to change the world. [FatSquirrel] has one of these machines, and a quarter century later, has it running NetBSD. It’s an interesting journey both into 1990s tech, and some modern-day networking tricks to make it happen.

These machines suffer as might be expected, from exhausted memory backup batteries. Fortunately once the serial port has been figured out they drop you into an OpenBoot prompt, which, in common with Apple machines in the ’90s, gives you a Forth interpreter. There’s enough info online to load the NVRAM with a config, and the machine stuttered into life. To do anything useful takes a network with RARP and NFS to serve an IP address and disk image respectively, which a modern Linux machine is quite happy to do. The resulting NetBSD machine maybe isn’t as useful as it could be, but at risk of angering any Java enthusiasts, perhaps it’s more useful than the original JavaOS.

We remember the promise of a Java-based future too, and tasted the bitter disappointment of stuttering Java applets in our web pages. However, given that so much of what we use now quietly runs Java in the background without our noticing it, perhaps the shade of Sun Microsystems had the last laugh after all. This isn’t the first ’90s machine that’s been taught new tricks here, some of them have received Java for the first time.

hackaday.com/2025/03/06/the-fu…

Introduction

Among the most significant events in the AI world in early 2025 was the release of DeepSeek-R1 – a powerful reasoning large language model (LLM) with open weights. It’s available both for local use and as a free service. Since DeepSeek was the first service to offer access to a reasoning LLM to a wide audience, it quickly gained popularity, mirroring the success of ChatGPT. Naturally, this surge in interest also attracted cybercriminals.

While analyzing our internal threat intelligence data, we discovered several groups of websites mimicking the official DeepSeek chatbot site and distributing malicious code disguised as a client for the popular service.

Screenshot of the official DeepSeek website (February 2025)

Scheme 1: Python stealer and non-existent DeepSeek client

The first group of websites was hosted on domains whose names included DeepSeek model versions (V3 and R1):

• r1-deepseek[.]net;
• v3-deepseek[.]com.

As shown in the screenshot, the fake website lacks the option to start a chat – you can only download an application. However, the real DeepSeek doesn’t have an official Windows client.

Screenshot of the fake website

Clicking the “Get DeepSeek App” button downloads a small archive,
deep-seek-installation.zip. The archive contains the DeepSeek Installation.lnk file, which holds a URL.
At the time of publishing this research, the attackers had modified the fake page hosted on the
v3-deepseek[.]com domain. It now prompts users to download a client for the Grok model developed by xAI. We’re observing similar activity on the v3-grok[.]com domain as well. Disguised as a client is an archive named grok-ai-installation.zip, containing the same shortcut.
Executing the .lnk file runs a script located at the URL inside the shortcut:

This script downloads and unpacks an archive named
f.zip.

Contents of the unpacked archive

Next, the script runs the
1.bat file from the unpacked archive.

Contents of the BAT file

The downloaded archive also contains the
svchost.exe and python.py files. The first one is a legitimate file python.exe, renamed to mimic a Windows process to mislead users checking running applications in Task Manager.

It is used to launch
python.py, which contains the malicious payload (we’ve also seen this file named code.py). This is a stealer script written in Python that we haven’t seen in attacks before. If it’s executed successfully, the attackers obtain a wealth of data from the victim’s computer: cookies and session tokens from various browsers, login credentials for email, gaming, and other accounts, files with certain extensions, cryptocurrency wallet information, and more.

After collecting the necessary data, the script generates an archive and then either sends it to the stealer’s operators using a Telegram bot or uploads it to the Gofile file-sharing service. Thus, attempting to use the chatbot could result in the victim losing social media access, personal data, and even cryptocurrency. If corporate credentials are stored on the compromised device, entire organizations could also be at risk, leading to far more severe consequences.

Scheme 2: Malicious script and a million views

In another case, fake DeepSeek websites were found on the following domains:

• deepseek-pc-ai[.]com
• deepseek-ai-soft[.]com

We discovered the first domain back in early February, hosting the default Apache web server page with no content. Later, this domain displayed a new web page closely resembling the DeepSeek website. Notably, the fake site uses geofencing: when requests come from certain IP addresses, such as Russian ones, it returns a placeholder page filled with generic SEO text about DeepSeek (we believe this text may have been LLM-generated):

If the IP address and other request parameters meet the specified criteria, the server returns a page resembling DeepSeek. Users are prompted to download a client or start the chatbot, but either action results in downloading a malicious installer created using Inno Setup. Kaspersky products detect it as
Trojan-Downloader.Win32.TookPS.*.

When executed, this installer contacts malicious URLs to receive a command that will be executed using cmd. The most common command launches
powershell.exe with a Base64-encoded script as an argument. This script accesses an encoded URL to download another PowerShell script, which activates the built-in SSH service and modifies its configuration using the attacker’s keys, allowing remote access to the victim’s computer.

Part of the malicious PowerShell script

This case is notable because we managed to identify the primary vector for spreading the malicious links – posts on the social network X (formerly Twitter):

This post, directing users to
deepseek-pc-ai[.]com, was made from an account belonging to an Australian company. The post gained 1.2 million views and over a hundred reposts, most of which were probably made by bots – note the similar usernames and identifiers in their bios:

Some users in the comments dutifully point out the malicious nature of the link.

Links to
deepseek-ai-soft[.]com were also distributed through X posts, but at the time of investigation, they were only available in Google’s cache:

Scheme 3: Backdoors and attacks on Chinese users

We also encountered sites that directly distributed malicious executable files. One such file was associated with the following domains:

• app.delpaseek[.]com;
• app.deapseek[.]com;
• dpsk.dghjwd[.]cn.

These attacks target more technically advanced users – the downloaded malicious payload mimics Ollama, a framework for running LLMs such as DeepSeek on local hardware. This tactic reduces suspicion among potential victims. Kaspersky solutions detect this payload as
Backdoor.Win32.Xkcp.a.

The victim only needed to launch the “DeepSeek client” on their device to trigger the malware, which creates a KCP tunnel with predefined parameters.

Additionally, we observed attacks where a victim’s device downloaded the
deep_windows_Setup.zip archive, containing a malicious executable. The archive was downloaded from the following domains:

• deep-seek[.]bar;
• deep-seek[.]rest.

The malware in the archive is detected by Kaspersky solutions as
Trojan.Win32.Agent.xbwfho. This is an installer created with Inno Setup that uses DLL sideloading to load a malicious library. The DLL in turn extracts and loads into memory a payload hidden using steganography — a Farfli backdoor modification — and injects it into a process.
Both of these campaigns, judging by the language of the bait pages, are targeting Chinese-speaking users.

Conclusion

The nature of the fake websites described in this article suggests these campaigns are widespread and not aimed at specific users.

Cybercriminals use various schemes to lure victims to malicious resources. Typically, links to such sites are distributed through messengers and social networks, as seen in the example with the X post. Attackers may also use typosquatting or purchase ad traffic to malicious sites through numerous affiliate programs.

We strongly advise users to carefully check the addresses of websites they visit, especially if links come from unverified sources. This is especially important for highly popular services. In this case, it’s particularly noteworthy that DeepSeek doesn’t have a native Windows client. This isn’t the first time that cybercriminals have exploited the popularity of chatbots to distribute malware: they’ve previously targeted regular users with Trojans disguised as ChatGPT clients and developers with malicious packages in PyPI. Simple digital hygiene practices, combined with a cutting-edge security solution, can significantly reduce the risk of device infection and personal data loss.

Indicators of compromise

MD5

4ef18b2748a8f499ed99e986b4087518
155bdb53d0bf520e3ae9b47f35212f16
6d097e9ef389bbe62365a3ce3cbaf62d
3e5c2097ffb0cb3a6901e731cdf7223b
e1ea1b600f218c265d09e7240b7ea819
7cb0ca44516968735e40f4fac8c615ce
7088986a8d8fa3ed3d3ddb1f5759ec5d

Malicious domains

r1-deepseek[.]net
v3-deepseek[.]com
deepseek-pc-ai[.]com
deepseek-ai-soft[.]com
app.delpaseek[.]com
app.deapseek[.]com
dpsk.dghjwd[.]cn
deep-seek[.]bar
deep-seek[.]rest
v3-grok[.]com

securelist.com/backdoors-and-s…