Using Halftone Images In QR Codes Without Upsetting Scanners

Although quick-response (QR) codes are rather simple monochrome affairs, adding embellishments to them is a popular activity, if only to make QR codes not stick out like a sore thumb in e.g. flashy marketing flyers. The most simple approach here is to put any regular graphic in e.g. the center of said QR code and lean on the scanner’s error-correcting features to route around the damage, but a more sophisticated approach uses halftone images that are blended with the QR code, as first demonstrated in 2013 by [Hung-Kuo Chu] et al.

A number of online halftone image QR generators exist that use the methodology in said 2013 paper to allow you to generate any mesh-up you like. Here [Jorge C. Lucero] provides a JavaScript-based version written from scratch that can run client-side. According to [Jorge] this was a weekend’s project created out of sheer curiosity.

The basic way that this algorithm works is by using each of the data modules of the QR code as a 3×3 grid of submodules, using only the center sub-module as the module’s color. The other sub-modules are thus free to be assigned a halftone color grade that creates the final module’s appearance.

Although this should generally work without leaning on the scanner’s error-correction features, an ‘enhancement’ mode is possible that enhances the image clarity at the cost of introducing some scanning errors that will require correction. Overall it provides a pretty clear improvement over simple binary image embedding, especially when higher resolution QR codes are used.

Why The ULC Audio Codec Is A Perfect Fit For The N64

Although the Nintendo 64 could deliver solid 3D graphics with assets loaded at a blistering speed from the game cartridge, audio-wise it was a bit more hampered. The main challenge here was that streaming PCM audio data from a roomy CD as on the PlayStation wasn’t an option, and using compressed audio samples was impaired by Nintendo’s refusal to open up more than the CPU for third-party codecs, leading to most N64 games using so-called ‘sound fonts’ that use sample-based tracks.

Once the N64’s RSP vector processor became available for use by developers it became possible to use MP3s without clobbering the CPU, but this was still an imperfect solution. In a recent article by [Dominic Szablewski] it is thus argued that the Ultra Low Complexity (ULC) codec might be a match made in haven for the N64 hardware.

This still uses the same modified discrete cosine transform (MDCT) as many lossy audio codecs including MP3 do, but the ULC code is designed to be extremely light-weight for decoding. [Dominic] first came across it in the form of an old Game Boy Advance demo that played a 70 kbps file with no issues on the 16 MHz ARM CPU.

Naturally the ULC codec’s creator [Aikku93] didn’t employ any unusual black magic to achieve this feat, mostly just foregoing some of the heavier elements of e.g. MP3 like splitting the signal into bands, and using a light-weight syntax to store transformed coefficients.

Here [Dominic]’s goal was to port the ULC code to work with the N64’s RSP so as to offload as  much of the decoding as possible. This required becoming extremely intimate with MIPS assembly, with [Dominic] eventually giving up and asking an LLM coding chatbot to translate bits of ULC C code to [Max Bebök]’s RSP language (RSPL) syntax instead.

The good news here is thus that the open source N64 SDK libDragon now has ULC support, just in case you want more than simple tracker-based music for your homebrew N64 game and do not feel like clobbering the RSP and CPU at the same time with something like MP3 or Ogg Vorbis.

This Week In Security: More Linux Bugs, Biggest Crypto Theft Ever, Prusa Printers, Residential Proxies

Linux kernel bugs which can be triggered remotely, without any login, are rare. Most kernel vulnerabilities need an attacker to already be running code on the machine. CVE-2026-98432 is one of those: a use-after-free in the IPv4 TCP handshake code, rated CVSS 9.8, which Atlas has written up in detail. It goes all the way back to Linux 4.4.

A use-after-free is exactly what it sounds like: the program releases a chunk of memory, but some other code keeps using it. If an attacker can get their own data placed into that freed memory before it’s used again, they can influence what the kernel does next. In this case, when a server accepts a connection whose SYN packet carries IPv4 header options (a rarely used feature of IPv4), the kernel hands those options from the half-open connection to the full connection without copying them, then frees them while another CPU core may still be reading them. The fix is a four-line change, from “kfree()” to “kfree_rcu()”, which waits until every reader is done before freeing the memory. A lost race simply fails the handshake, so an attacker can keep trying.

The bug was reported by Xinyang Ge at Anthropic, and Anthropic says its Claude model wrote a working proof-of-concept that gets root on “Linux servers with a multipath TCP listener.” Multipath TCP (MPTCP) lets a single connection use several network paths at once, like WiFi and cellular, and you might assume almost nobody runs it on servers. Unfortunately, as Marcus Hutchins points out, Debian kernels enable MPTCP by default, and Go 1.24 and newer open MPTCP listening sockets by default when the kernel allows it, so anything built in Go (including the Caddy web server) is potentially exposed. Hutchins’ scans found about 2.1 million servers reachable over MPTCP on port 443, and he’s already seeing scanning from residential proxies and Russian VPNs which looks like it’s specifically hunting for this bug.

Upstream stable kernels were fixed in mid October, but as of October 31, Ubuntu and Red Hat were both still listed as vulnerable, with fixes in progress. If you can’t patch yet, you can check for MPTCP listeners with “ss -Mlnp”, and disable MPTCP with “sysctl net.mptcp.enabled=0”, but note that this doesn’t affect sockets which are already open, so you’ll need to restart any services using them. Red Hat and AlmaLinux have also published firewall rules which drop TCP packets carrying IPv4 options, which basically no legitimate traffic uses.

We haven’t seen bulk exploitation of this vulnerability yet, which might hint that it’s less trivial to trigger than the severity might indicate, but it’s a great time to get servers up to date. “Not exploited yet” has a nasty habit of turning into “every vulnerable server exploited in a day”.

Meanwhile, on the local side, OpenAI has published the results of pointing an automated pipeline, built on an unreleased “cyber-focused” model, at the kernel. In a run in mid October, it found 2,300 candidate bugs, reproduced 1,700 of them, and produced 948 working local privilege escalation exploits against a stock desktop Linux distribution, for about $1.2 million in API credits, or roughly $1,279 per root exploit. That’s not cheap, but for comparison, Pwn2Own has historically paid $20,000 for a single Linux kernel privilege escalation. Local privilege escalation is the step after an attacker gets a foothold: turning an ordinary user account, a compromised web app, or a sandboxed process into full control of the machine. Coupled with even a basic vulnerability in other code, it can allow an attacker to take full control of the system and hide the compromise much more effectively.

OpenAI says it’s working with the kernel community to report the bugs and submit patches, starting with the most critical, and that during the ten days the scan was running, more than 100 other kernel privilege escalation bugs were patched by other contributors, with about 300 more being discussed publicly. The most sobering line in the report is that, for now, a low-privileged account on an unpatched system “should be considered functionally equivalent to root access for a well-resourced threat actor.” It’s been quite a week for kernel developers, and it’s not going to slow down any time soon.

The flood of AI discovered vulnerabilities seems to continue unabated, and it’s easy to feel under attack from them. Consider, however, how often the open source community has called for companies using open source tools and libraries as core elements of their business to help support those tools and community. There’s still a significant burden placed on the community maintainers when almost 2000 bug reports land in a week, but over $1 million investment in securing Linux isn’t nothing, and the patches at least appear to be reasonably scoped and accurate. I’m pretty sure we’d see an article covering Linus’s response if they weren’t.

Continue reading “This Week In Security: More Linux Bugs, Biggest Crypto Theft Ever, Prusa Printers, Residential Proxies” →

The Goat Emoji Is 100% Valid Machine Code, And It Doesn’t Stop There

Did you know emojis can be executables? Well, they are if you treat them like Intel 8088 or 8086 machine code, anyway. [GloriousCow] shared this clever revelation, demonstrating that executable programs could be created entirely from emojis. To really appreciate why, it’s necessary to take a small step back.

It all started when [GloriousCow] happened to notice, entirely by chance, that 🐐 (the goat emoji) was F0 9F 90 90. Anyone familiar with x86 assembly language probably recognizes 90h as nop,  or null operation, or “spend a cycle doing nothing”. What about F0 and 9F? Together they are lock lahf (assert the bus lock signal then copy some status flags into register AH) which, on an 8088 and 8086, essentially does nothing.

This means the goat emoji (F0 9F 90 90) is 100% technically valid machine code. It doesn’t do anything, but here’s where it gets even more interesting.

A short string of emojis is machine code that writes HELLO (lower right) by writing directly to video memory.

There are loads of emojis, and many of them start with F0 9F followed by two more bytes, and many of those other two-byte combinations are surely also valid machine code. Could one create a meaningful executable program consisting entirely of emojis? The answer is yes, and [GloriousCow] crafted a simple Hello World program to demonstrate.

The simple program looks like this: 🐸☺️🐰🐎♐🗃️🧯🧯🧯🐮💗🦮🪏♐🐰🐹🗃️🧯🧯🧯🧯💗🪗🧯😗🧮🫪😗🧮😗🐮😪😔⭐. Save that string of emojis to a file, give it a .com extension, and run it in DOSBox with CPU type set to 8086. It’ll print HELLO at the bottom-right of the screen by writing directly to video memory.

There are loads more details on the original blog post, including plenty of resources and tips for writing your own executables with emojis. There’s also a much more involved VGA demo program made from emojis, so give it a look.

Some of you may be aware that ASCII characters can also be used in a similar way (and more flexibly, since they are not four-byte combinations like emojis). This was used in BASIC programs as a way to cleverly embed machine code in things like REM statements, creating odd-looking code that did things in BASIC that shouldn’t have been possible.

Making Xibalba 64, A New N64 Release In 2026

[Dominic Szablewski] created something that we don’t see every day: a no-kidding new physical Nintendo 64 game for sale, complete with cartridge, manual, and box art. He wrote about what it was like to make Xibalba 64, a 3D FPS game built using his own game engine. It even supports two-player couch co-op and four-player deathmatch.

The N64 was a groundbreaking console that brought analog controls and fully 3D game worlds to mainstream console gaming. Architecture-wise it has its share of quirks, including a tiny (4 kB!) amount of texture memory to go around all that fancy 3D content.

Xibalba was originally a demo game for [Dominic]’s MIT-licensed game engine, high_impact. Turning it into a full-fledged title for the N64 meant revisiting all sorts of things from level and gameplay design to sound and music. [Dominic] talks about it all, including the fact that his engine is technically for 2D content but he makes it work for the 3D game by ensuring levels have no elevation. Since levels are flat, the engine never has to deal with a dimension beyond its understanding. Xibalba 64 even maintains a stable 60 frames per second, dipping somewhat only in four-player split-screen.

The N64 still gets a lot of action from dedicated enthusiasts, and there’s no need to start from scratch if you find yourself with a retro gaming itch and a desire to push a vintage console in directions it never knew. For example, we’ve seen an open world game engine for the N64, complete with long drawing distances that didn’t seem possible on the hardware.

Translating An Old Display To A New One

A quick search through AliExpress will find PCBs that take HDMI or VGA and translate them to DSI lanes for TFT panels, and even boards that translate DSI to HDMI in the other direction. Usually they need dedicated silicon or if you’re doing it yourself, an FPGA, but depending on the display that need not be the case. As an example, [Voltage Ventures] has replaced a defective STN display with a more modern one using nothing more complex than a Raspberry Pi Pico.

The display comes as part of a Samsung cash register that looks as though it comes from the 1990s, which is in keeping with it having a monochrome STN display. A replacement was going to cost a fortune, so some way of translating between the two was in order. It has a 4-bit data bus, so there’s a description of how they sampled the bus and identified the timing used. It’s hardly the highest resolution display by today’s standards, being a meager 320 by 240 pixels. Once the format is known it’s a case of transposing it to monochrome VGA in the microcontroller. Initial work was done with an STM series chip, later this was moved to the RP2040.

We like this project, and it’s a reminder that even something broken and old can still be rescued.

Reviving Google Cardboard, Without Google Or Cardboard

Remember Google Cardboard? The late, unlamented practice of strapping a phone to your face so you could get motion sickness in a virtual environment? [brenpoly] wants you to reconsider, because in the years since Google pulled the plug on mobile VR, phones have gotten really, really good and he’s got a project called CardboardXR on GitHub that the project video enbedded below bills as “A 5$ Apple Vision Pro”

Well, it’s 5$ if you already happen to have a flagship phone like the Pixel 9 Pro or iPhone 15 Pro he’s using for testing– otherwise you’d be out a rather larger chunk of change in order to pick up such a pocket supercomputer. In any case, he’s able to get 6 Degree of Freedom (DOF) tracking from these units, along with using the cameras for passthrough and object detection, hand tracking, and gesture control– everything the big boys net you, in other words. That’s pretty impressive compared to the 3DOF, and zero tracking or pass-through mobile VR used to get you.

He’s also built adjustable optics into his 3D-printed replacement for Google’s old face-hugging cardboard, which you can get on Makerworld.  On the other hand, presumably you could just cut a hole for the camera bumps in one of those if you’re the kind of person who throws nothing out. Either way you’d be using the same lenses; it turns out they’re still available online, so that’s what [brenpoly] spec’d.

All these fancy features aren’t entirely [brenpoly]’s own work: his software is based on Unity which has some slick VR/AR tools and the ability to build in all the relevant machine learning models for things like hand tracking. He’s also taking some major inspiration from the Google Cardboard SDK, which Google open-sourced back around the time they gave up on it. It’s still a very impressive project regardless of the toolchain involved, though there’s a certain irony that [brenpoly] is now strapping a phone to his face after his last project we featured  was all about getting him to put it down.

Continue reading “Reviving Google Cardboard, Without Google Or Cardboard” →