It’s Alpine Linux, On A Kindle Paperwhite 3

November 6, 2026 by No comments

As computing power becomes cheaper and microprocessors become more capable, a steady trend over recent decades has been to see more everyday devices hiding Linux under the hood somewhere. Sadly in most cases that’s where it stays, but some such machines have a level of hackability. One such is the 7th generation Kindle PaperWhite 3, for which [pragyaangaur] has produced a distro that gives it the Alpine Linux userspace and a few other tricks.

As you might expect, the Kindle must be jailbroken, and is limited to the rather ancient Amazon kernel. The distro comes with a few extras for the custom front end. There’s a selection of games, a browser, an ArXiv search client, an ePub reader, and Quill, a local chatbot running SmolLM2 over llama.cpp on the Kindle’s own processor. At 1.7 words per second it may not be the fastest, but the important thing is that everything stays on the device. Best of all, it’s easy enough to return your Kindle to stock should you tire of the distro.

A quick look at everyone’s favourite auction site finds these readers available for well under $100, so should you wish to join the fun it at least shouldn’t cost an arm and a leg. Meanwhile, Kindle hacking is somewhere we’ve taken you before.

MousePods Reverse Engineers Head Tracking Data From Stubborn AirPods

November 6, 2026 by No comments

[Matteo Gaudioso] released MousePods, a Python tool which accesses the motion sensors in Apple AirPods on Linux, turning them into mouse input. No Apple host required. Doing this required reverse-engineering how the devices work and communicate, because it turns out the AirPods 3 do things differently than other models.

Everything runs in a single Linux app, no Apple host involved.

Head tracking with AirPods has been around for years. Apple uses the motion data for spatial audio and gesture detection, and there are a number of open source tools to access that data. But there was always a blind spot: no one could figure out how to talk to the AirPods 3.

[Matteo] enlisted the help of Claude Code in digging out what was different, and found Claude pretty useful for running hundreds of probes and tests to the AirPods to eventually tease out what was going on, among other things. The findings are nicely summarized here. One interesting one is how the sensor data was indirectly hidden by the fact that on Linux the default MTU (Maximum Transmission Unit) is too small to hold the whole payload complete with motion sensors. Once the Linux MTU is increased to match the considerably larger iOS default, everything appears.

There’s one other feature we like: the ability to send the data to opentrack to use as head tracking input to things like flying or racing simulators. We’ve seen this done with flight sims using headphones for head tracking, which is a great way to use sensor data that already exists without impacting the audio functionality.

Some features are still experimental, but MousePods is confirmed to work with the Apple AirPods 3 and AirPods Pro 2. Check out the MousePods website for a bit more info if you’d like to give it a try.

Using Halftone Images In QR Codes Without Upsetting Scanners

November 6, 2026 by No comments

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

November 6, 2026 by 1 Comment

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

November 6, 2026 by 8 Comments

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

November 6, 2026 by 22 Comments

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

November 6, 2026 by 7 Comments

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