Installing Cydia 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.

Switching our approach 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? $ strings mounted_restore_ramdisk/usr/sbin/asr | grep "Authentication error" # No results Huh, zero hits! That’s curious, because asr is definitely printing this out… Let’s search the whole ramdisk for this string. $ grep -arl "Authentication error" mounted_restore_ramdisk mounted_restore_ramdisk/usr/lib/libSystem.

Recovering firm footing 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! It’s actually a Mach-O embedding a program tantamount to the following: ✱ Note Other utilities you might expect to find, such as uname or touch, are missing from the ramdisk.

Hatching a patch 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.

How do you boot iOS? … Carefully 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.

Note This series was discussed further on Hacker News. Introduction 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.

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!

Note This post was discussed further on Hacker News. 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!

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 Build system Years of assumptions that a memory address will fit in a u32 For a lot of these items, we’ll save ourselves headache and heartache if we have one interface to do a job, and swap out the details of the implementation based on the architecture we’re targeting.

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.

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.

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

Seeking the eternal satisfaction that’d come from a [email protected] email, I checked out the trusty internet marketplace. Hmm, I think I’d be willing to shell out a few hundred for the security of holding on to my own name. Ah! After speed-running The Art of the Deal, I was ready: $200 budget and complimentary Red Sox tickets in hand. The broker was certain over the phone he knew my game. Tennen, it is apparently well-known, means ’natural’ in Japanese.

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:

When a computer starts up, before the operating system can display applications, menus, and wallpapers, the operating system needs to first perform a complex initialization sequence. This sequence serves to get both the underlying hardware, and the operating system’s own software components, ready for further use. While the full details of this sequence are out of the scope of this blog post, here’s a rough rundown of what this might look like:

Similarly to how it’s nice and convenient to think of memory as one big list of bytes (but is, in reality, backed by lots of different peripherals whose access is mediated by the MMU), it’d be nice to live in a world in which all it took to display pixels was to write some RGB values to a pixel-list. Alas, things are never quite so straightforward. The GameBoy’s LCD display is driven by a subsystem called the Picture Processing Unit, or PPU.

Note This post was discussed further on Hacker News Discussion #1 Discussion #2 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.