Exploring the iOS screen framebuffer– a kernel reversing experiment

It’s been over two years since I last published a blog, so I thought I’d give this another go in 2020 and kick it off by writing about an iOS-related project I’ve been working on over the last couple weeks – a reverse engineering task involving the iOS screen frame-buffer.

First of all, my inspiration to start looking at this came shortly after the release of the checkra1n jailbreak for the iPhone 5S – iPhone X. If you haven’t yet played with checkra1n, check it out here – https://checkra.in/.

One of the things checkra1n does during the jailbreaking process is display a series of debug messages on the phone’s screen to let the user know about the progress of the jailbreak, and allow them to see what went wrong in the event of the jailbreak failing.

These debug messages are written to the display over the top of the standard boot screen. I was intrigued by this and started to wonder how the checkra1n team had implemented it. I heard some phrases thrown around online mentioning the use of a “framebuffer” and that the jailbreak tool was somehow “writing” to it.

So I set myself the challenge of figuring out how this worked and how I could replicate this in order render some characters on the screen by directly manipulating the pixels.

Locating the iOS frame-buffer in kernel memory

The first step towards reaching my goal of writing custom characters to the screen was to find where in memory the screen pixel data was stored.

The checkra1n tool manipulates pixels in the framebuffer during the iBoot stage of the boot process, which is why we see the debug messages printed over the Apple boot-logo. I decided to take a different approach and focus on an already-booted iPhone.

The only difference meant dealing with kernel memory as opposed to iBoot memory, and dealing with the kernel memory seemed like the simpler approach as I could get started right away without having to construct a fully patched boot-chain etc.