Satori's tech blog

A tech blog I always forget to update

Creating an iOS Debugger: Part 0: Introduction

Welcome to the first of my posts in a series about creating a debugger for iOS (and possibly OS X too). This post will mainly be covering what the series will cover, and what to expect in the next posts.

Before I get started, I would just like to say that this blog is new, and as such very cluttered. Please ignore all the dust while I figure wordpress out.

The project background

Long ago in an iOS version far far away, there was a debugger called GDB. This debugger was perfect for the iOS developers, especially the jailbreak community. It was easy to use, yet had many advanced features. This made it popular on many linux distributions, but the evil megacorp Apple™ didn’t like GDB. They thought it wasn’t appropriate for their vision. Apple devilishly replaced GDB with their own debugger, the infamous LLDB. LLDB was equally as advanced as GDB, but it was frowned upon by the jailbreak community due to it’s hard to use design. Things like requiring the user to have OS X and copying LLDB’s chief-of-mischief, debugserver to the device made LLDB very unpopular (and even unusable for some).

This is where I come in. I have had quite enough of the ridiculous requirements to run LLDB, so I have decided to make my own debugger. It definitely won’t be as advanced as LLDB or GDB, but I hope to support the main features a debugger should have.

Of course, when I decided to do this (a few months ago), I had no idea how debuggers worked, or how to make one. In fact, I am still a bit hazy now. This series will therefore be a written example of me learning to make a debugger.

The project aims

As I said before, I don’t intend to make some monstrous debugger with 100,000’s of lines of code. I aim to make a simple lightweight debugger which doesn’t use many resources and can be easily adapted to other projects.

Here is a list of major targets I am aiming to achieve:

  • Support breakpoints, watchpoints and tracepoints
  • Support thread frame backtracing
  • Support disassembling instructions at runtime
  • inspecting memory at runtime

And here is a list of other targets that I would like to achieve but I doubt I will.

  • Integration with cycript (for the ultimate debugging experience)
  • Port to OS X
  • Integration with Objective-C and Swift objects at runtime
  • Create a static library edition of the debugger that can be used in other peoples projects
  • Interaction with UI applications (similarly to FLEX)

Structure

These posts will not just be to show others how to make a debugger, they also serve as documentation for me in the future. I plan to have visual items like pictures along with the text when creating these posts, some pictures may be more cringe-worthy than others.

b63d7fc470c4ea6d65b5626f70022dc7c31da75bc23ed1b8cd69a925f1a4a7da

Summary

Overall, This project aims to create a lightweight debugger for use on iOS (and maybe OS X too). I really doubt I will ever finish this project, but one can always live in hope. If I haven’t done anything on this project for a while, feel free to leave a comment or tweet me @Razzileful. Also, please leave a comment if you see that I have done something wrong or missed something important out.

This project’s source code will be available at http://git.satorify.org while it is in early stages. Once it is more mature, I will move it onto my GitHub account.

That’s all from me for now.

– Satori

Part 1: Backtracing

comments powered by Disqus