We’re plotting the satellite’s orbit according to the data the satellite is sending, but the resulting orbit is clearly nonsense. My first instinct was to track down where I was parsing the data format incorrectly. To my dismay, these bits are what the satellites are beaming down, and I was pretty sure I was parsing the data fields correctly. Next line of attack: I knew that the satellites also transmitted parity bits for error detection. I had been ignoring these parity bits up to now. Perhaps it’s a good time to check against them?

We can reliably track our satellites over many minutes! We’ve surmounted one of the major challenges in building out gypsum, and now just one obelisk stands before us: computing the user’s position. This brings us to the really fun part: reading and decoding the bits that these satellites are transmitting! Unfortunately, this isn’t as easy as I imagined at the start. Reading off bits from the satellite requires a peculiar methodology due to the way that the data bits are encoded on top of the PRN code and the carrier wave.

We’re getting there! We’ve set up a pipeline that can read vast quantities of floating point samples from our radio hardware, and can pick out the hums of the GPS satellites amongst the noise. Our acquisition phase told us which GPS satellites are within view of the user, and has given us a coarse estimate of each satellite’s Doppler shift and PRN sequence phase. However, these satellites are extremely precise devices in a noisy and changing environment, and our coarse estimates won’t nearly cut it.

Have you ever noticed that your Maps app still works during a flight? It can feel illicit, like someone just forgot to turn off the signal, and that watching yourself crawl along the earth should be done without drawing undue attention. A few months ago I learned that there were only around 30 GPS satellites serving the entire planet. This piqued my interest, because it reminded me of the 13 root DNS servers from which all resolution flows. Perhaps GPS has a similar design in which the ‘source of truth’ is diluted by several layers of signal repeaters? I navigated to gps.gov, and was presented with this delightful image. I became even more excited to learn about what these satellites do!

I made a graphical IRC client that runs in UEFI. It’s written in Rust and leverages the GUI toolkit and TrueType renderer that I wrote for axle’s userspace. I was able to develop it thanks to the vmnet network backend that I implemented for QEMU. You can connect to an IRC server, chat and read messages, all from the comfort of your motherboard’s pre-boot environment. “Why”? What kind of question is “why”?

In 2019, I built a work-for-hobby iOS simulator on a strict regimen of weekends and coffee. While the full details of this project will stay in-house, there’s enough I can share to hopefully be interesting! First up, here’s what this looks like running against a simple demo app. On the right is the bona-fide iOS simulator from Xcode, and on the left is the simulator I built.

Text is the medium of digital interaction, and text rendering has an outsized impact on the overall fit and finish of any system. It therefore pains me that axle has for years relied on a low-resolution 8x8 bitmap font. Let’s fix it! Take a look at the characters composing this sentence. Note the curves, the negative space, the use of size and distance. If you’ve got a magnifying glass handy, you can even see how ‘black-on-white’ text uses many shades of gray to make the text smoother on the eyes.

We’ve managed to flash and boot a modified iOS distribution! We’re now in the home-stretch of a user-facing jailbreak. The main thing that end-users typically expect from a jailbreak is that they can open up Cydia and install some runtime modifications that alter the behavior of system processes such as SpringBoard. I wasn’t sure exactly how jailbreaks install Cydia, aside from a loose guess that the jailbreak ships a copy of Cydia.app and copies it to /Applications/. This is roughly right, but there’s more to the story.

The Authentication error string that asr would usually print out after it decides to reject the filesystem is interesting, though. Maybe we can poke further at that to try to find an approachable patch-point? Huh, zero hits! That’s curious, because asr is definitely printing this out… Let’s search the whole ramdisk for this string. Ah! This is coming from /usr/lib/libSystem.B.dylib, which is dynamically loaded and used by asr. It seems odd that anything to do with verifying a filesystem image would live here, though… Let’s take a closer look.

Eventually, I managed to glean the structure of what happens next: The Restore ramdisk contains a traditional, but heavily trimmed down, OS distribution. It has all the fun directories, like /usr/sbin/ and /System/Library/PrivateFrameworks/. It also ships with some standard UNIX utilities, such as /bin/cat. The kernel loads and executes /etc/rc.boot from the ramdisk to drive the next piece of work. Remarkably, this is not a text file!

One thing that I initially found quite surprising about this whole process is that, with this approach of breaking each successive stage’s image validation and uploading patched images, the system we’re booting is arguably no longer iOS. It’s a custom OS distribution that’s very similar to iOS, but is based on custom firmware images that are essentially authored by the jailbreak developer when they apply their patches. To my sensibilities, this makes this approach to jailbreaking less of a “pure” jailbreak than exploiting and modifying a running system post-hoc, once it’s already booted.

Now that we’ve gained confident control of the SecureROM environment, let’s move on to something more ambitious: booting iOS. Of course, running unsigned code in DFU mode, then handing the reigns back to a secure boot chain kind of defeats the purpose of running unsigned code in the first place. What would be great is if we could boot iOS, but in a special way that disables all the security mechanisms present after the SecureROM. This is jailbreaking! Recall our chain of trust from earlier:

Years ago, I was active in the iOS tweak development scene. I made many products and tools, distributed on Cydia, that modified iOS system behavior and added new functionality to SpringBoard. This was a really fun time, and gave me valuable early career exposure to reverse engineering closed-source binaries, interacting directly with the Objective-C runtime, and entrepreneurship. I’m really grateful for those years. One aspect of the jailbreak scene that always seemed like black magic to me, though, was the process of jailbreaking itself.

I’m currently working on a huge project. Since I’d like to finish it soon, I’m instead going to spend an evening implementing a bespoke newsletter service. A couple of months ago, I added a prominent RSS button to the overview of this blog, acquiescing to the venture capital overlords that line my pockets on the promise of a dedicated audience willing to trudge through inane jokes like this one. Don’t see it?

When I’m being first-order productive, I’m programming: creating and interacting with a system. This first-order productivity is great, but it isn’t discoverable for others: there’s generally a high bar to entry for comprehending another person’s work when it’s expressed solely as a structured program. Second-order productivity is when I’m writing about programming, or about systems. This kind of productivity is generally more accessible and distributable, and forms most of the content of this blog!

Recently, the epic yak shave that is my life dragged me down into oblong pits of page table corruption. I’ve made it out the other side, with a primary takeaway of “how the hell did this ever work?”, followed closely by “what the hell is still hiding?”. Picture this: you’re carefree, healthy, “hey, I should rewrite axle’s network stack in Rust!”. Sinister snap of the violin. Sad oboe, crying clown. OK, this can’t be too bad. Let’s start with the basics: we’ll fire up the network card driver to jog our memory about where we left things off.

I had a hankering to tweak this blog’s presentation a bit. Here’s what it looked like this morning: Bleugh! Straightforward content? Simple design? Restraint? Thanks, but no. It’s like this guy’s never heard of responsive web pages. First, let’s make each of those posts pop a little bit more. Yeah, yeah! Subtle, I like it. Tiny thing, it needs more color. Now we’re talking. I manually picked out some pastels and selected one randomly for each blog post chip.

Programming the computer allows you to take something you see and rearrange the pieces a bit to better fit your needs. It’s really a delightful and powerful thing. A few weeks ago, Daisy and I were staying in a cottage with poor internet speeds. We were trying to stream a series of videos, but the embedded player would only get through a few seconds of playback before it choked for several minutes on the next chunk.

axle used to be a 32-bit-only OS. In late 2021, I had a hankering to fix this longstanding limitation, and plunge into a world that expanded not just our address spaces, but our hope. Roughly, if you want to add support for x86_64 to an existing x86 OS, you’ll need to update these components: Global descriptor table, interrupt descriptor table, interrupt handlers, hand-coded assembly routines, multitasking, paging and virtual memory manager, linker scripts, ELF loader, ported software, disable the red zone, …

Over the course of developing an operating system, things are going to crash, and they’re going to crash a lot. One way to make crashes slightly less annoying is to isolate them: the rest of the system continues running, and you can poke around further after an unexpected condition arises in one process. Perhaps surprisingly, it took me several years before this became feasible! Previously, when any code path, in any process, encountered an error condition (such as a page fault, or an explicit assert()), the kernel would spew some debug information over the serial port, then lock up to prevent further shenanigans. This is pretty overzealous and often unnecessary.

Every hobby operating system developer dreams of the day that a stack wrought from their own blood, sweat, and keystrokes renders its first webpage. Back in early 2021, I decided to break ground on the first step towards this goal. Before we can connect to the web, we need to handle all the necessary protocols to exchange packets over both the web and our humble local network link. This includes implementing protocols such as TCP, DNS, and ARP. But before we even think about talking in protocols, we need the bare-bones: some way to send packets out, and get packets in.

In the beginning, Intel created the 8086. This has been widely regarded as a bad move, but boy is it popular. The enduring success of the 8086 has been bought on the blood altar of Compatibility: software written for the original 8086, even very low-level software that runs without any supporting OS infrastructure, must continue to function on every new x86-line CPU manufactured today. This selling point enforces some pretty annoying constraints on both the advancement of the x86 line and on developers who need to interface directly with x86 CPUs.

Syscalls are a fundamental piece of the processes model within contemporary operating systems. OS’s generally like to provide the abstraction that a given program is running on the CPU, linearly and largely in an uninterrupted fashion, from start to finish. Of course, this isn’t the case; programs are interrupted all the time, for a variety of reasons. Some examples of times the kernel needs to step in: The kernel needs to handle an event from a peripheral device The program has page-faulted and needs the kernel’s VMM to make everyone play nice The program has been preempted to give other programs the chance to use the CPU for a few milliseconds The underlying reality of what the CPU spends its time on is a complex juggling act of contexts scheduling in and out.

Chess.com is a great online chess server and content creator. One of their hallmark features is their chess puzzles: Present the player with a position The player needs to find the ’tactic’: the best sequence of moves, typically resulting in an advantage over the opponent The quicker the player completes a puzzle, the more points they earn They look like this: Puzzles are nice because they help players train their pattern recognition and develop their intuition for chess.

Imagine you have a compass. Instead of the 4 cardinal directions, mark the compass with 10 evenly-divided indications. Let’s play a game together. You’re standing on a plane, and in front of you is a ball. I’m going to tell you a number. Push the ball with enough force to impart a 1 meter-per-second change in velocity in the direction matching the number’s annotation on your compass. For example, if I gave you the number 7:

The Nintendo GameBoy is an exceptionally well-documented system, perfect for anybody who’d like to take a crack at emulation. Publicly-maintained resources like the Pan Docs make it both approachable and convenient to get an overview of the GameBoy’s address space layout, to understand the mechanics of hardware peripherals, and to learn about various edge-case behaviors that some games depend on. Over the past three weeks, I’ve been writing a GameBoy emulator my very own. This is not a unique project! I was inspired by the blog post of another adventurer doing the same thing.