CHIP 8: The Pong Game’s Afoot!

Writing a computer game has always been hard. It is only the nature of the difficulty that changes. A modern game is as much about graphics, sound, and storytelling as it is about programming. But in the early days of computers, writing a game was a challenge because of limited graphics, slow CPUs, and tiny memory capacity. If you wanted to write a game for an early microcomputer, you generally wrote it in assembly language. BASIC was available on many machines, but it was usually too slow for anything requiring fast animation. Assembly language was fast, but it was also difficult to write, debug, and port to another machine.

RCA — in particular [Joseph Weisbecker], the architect of the 1802 — introduced the COSMAC VIP into the primordial 1977 home video game market. In addition to using ready-made games, the idea was that you could create your own. But writing games in 1802 assembly language would be beyond most of RCA’s customers. [Weisbecker] devised CHIP-8, a tiny virtual machine. It wasn’t quite a programming language. Instead, it was a simple instruction set implemented by an interpreter running on a real computer. You wrote programs for the imaginary CHIP-8 processor, and the interpreter made them run on the actual hardware. CHIP-8 is perfect for the kind of games you’d see in those days and still has a following among those who love retro games. Continue reading “CHIP 8: The Pong Game’s Afoot!” →

EV Batteries Are Proving Hardier Than Expected

Batteries have a habit of quietly getting worse. Anyone who has nursed an old smartphone through its final years knows the routine—it leaves the house at 100% and is begging for a charger by lunchtime. It’s no surprise, then, that one of the most common worries about electric cars is what happens to the pack after a few years and a lot of kilometres. Nobody wants to buy a used EV only to discover it can barely make it across town. Fears around battery degradation and high replacement costs were the catch cry of many EV doomers over the years.

The good news is that we now have a pretty big pile of data on the question. Austrian battery diagnostics company Aviloo has crunched the results of more than 500,000 tests on used EVs  covering 20 popular models from the likes of Tesla, Volkswagen, Hyundai and Nissan. The data thus far tells us that EV batteries are holding up far better than the naysayers would have you believe.

Continue reading “EV Batteries Are Proving Hardier Than Expected” →

DeviceTree For Hackers: Intro

Raspberry Pi has just leaked information on the Pi Zero 3W. They did it by publishing a DeviceTree file that describes the hardware of the Pi Zero. This is how we know it has the BCM2711 (Pi 4 CPU), makes use of PCIe (maybe it’s even exposed!), has an onboard power button, an extra power LED, and an eMMC option. If I were to guess, this will be the first dual-sided Pi Zero board, and if I were to have hope, it finally has USB-C.

Don’t believe it? Go read the DeviceTree file for yourself — it’s exceptionally easy to read it between the lines. DeviceTree files tell the Linux kernel, or other OS kernels, what CPU to expect, what drivers to load, which interfaces are exposed on your board, and the devices connected to those interfaces. Sometimes a proper DeviceTree file is the only thing you need to make a modern Linux OS run on a neglected SBC you own.

There are DeviceTree files powering technology all around you. Your phone has one, so does your router, your ARM laptop, and not even to speak of your SBCs. Some DeviceTree files are evil, being merely a thin layer between the Linux kernel and proprietary drivers; you will find these in phones with CPUs made by evil corporations. Most DeviceTree files are simply there to do their job.

Continue reading “DeviceTree For Hackers: Intro” →

UDP Broadcasting Meets The More Focused Multicasting

After previously exploring the basics of UDP broadcasting, why IPv4 subnets are an exciting feature that you really want to dive into, as well as the contentious topic of IPv6, there are still plenty of elephants to admire and cans of sardines to crack open. One of them being the topic of broadcasting versus multicasting, which at first glance sounds rather similar and may even have some wondering why you’d even bother with multicasting if you can just send-and-forget with IPv4 broadcast address.

Of course, we already found out that IPv4 broadcast addresses come in a few flavors, and that’s before you start even considering the implications of subnets and routing limits. When we then consider that in IPv6 broadcast addresses were dropped completely in favor of link-local multicast addresses, and that IPv4 also supports multicast, then this raises the question whether using IPv4 multicast’s own take on ‘link-local’ doesn’t make more sense.

Or perhaps more succinctly put, is IPv4’s take on link-local broadcasting as straightforward as IPv6’s?

Continue reading “UDP Broadcasting Meets The More Focused Multicasting” →

Radon Active

When you think about nuclear radiation, you often think about power plants, but it turns out there’s radioactive stuff all over the place: smoke detectors, granite counters, bananas, and potatoes can all be mildly radioactive. Even some old tape dispensers. But those are all puny sources.

Radon is a colorless, odorless gas that is heavier than air. It is a byproduct of uranium decay, amonth other pathways, decays by emitting an alpha particle, and has a half-life of just about four days. As a gas, it escapes from rocks or soil. Usually, there isn’t much of it, so it vents harmlessly to the atmosphere. But it can easily get trapped in a house and accumulate. You might think your house is solid, but there are plenty of cracks, joints, and pipes where gas can weasel through, especially if your inside pressure is slightly lower than the pressure in the soil below, which is common.

As the radon decays, it can produce more radioactive material, including tiny amounts of polonium. With or without dust particles, these tiny bits of radioactive material can go airborne and end up in your lungs. There, they can further decay, and alpha particles damage cells and DNA. According to the EPA, radon exposure is the second leading cause of lung cancer in the United States, next to smoking.

Not So Speedy

If you get enough carbon monoxide in your home, you probably won’t see the next sunrise. But radon works very slowly. It is odorless and colorless. You won’t show any general symptoms to warn you that you might get lung cancer.

The effect can take years or decades. Of course, you can also have a house that has very little radon. However, nearly all homes have some radon. The EPA estimates that about 7% of homes have elevated radon levels.

Some areas are more prone to radon than others, but even if your area has low risk, there’s no guarantee that your house is safe. If you are lucky enough to not have a radon problem, you have nothing to worry about. But how do you know? Like anything, you need to test.

Continue reading “Radon Active” →

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” →

I Think We Should See Other SBCs

Are you currently designing a project for a common single-board computer (SBC), and do you expect other people to build your project, too? We routinely feature projects that do exactly this. Well, turns out SBC availability is a problem now – and I’d like to teach you how to pick SBC alternatives, mostly to the Raspberry Pi boards.

We had SBC shortages before, but 2026 has beat them all, and it doesn’t look like it’ll stop within even a few months. RAM prices have incinerated the supply side of single-board computer availability, and I suspect that consumer SBC use in Russian drones had a noticeable impact, too.

Less-utilized SBCs always brought their own advantages to the table. If you didn’t like that the Pi Zero came with only 512MB of RAM, you could always buy an Orange Pi or a Radxa board with 2GB or 4GB for a meager increase in price. Now, there’s even more of a motivation to explore what’s on offer!

This year, SBC prices and availability have both jumped up tremendously, and even the Zero 2W stocks have evaporated. Me, I had to make a few of my projects way more flexible way quicker. Now, I have some experience to share!

Finding Your New SBC Friends

Continue reading “I Think We Should See Other SBCs” →