This part tells you a couple of issues you must know earlier than you get began, corresponding to what you’ll want for {hardware} and software program, the place to seek out the mission recordsdata for this guide, and extra.
This part will cowl the fundamentals of utilizing LLDB, Apple’s software program debugger. You’ll discover an utility named Indicators, an Goal-C/Swift utility that illustrates how Unix indicators might be processed inside an utility. You’ll be taught some methods to seek out and create Swift syntax-style breakpoints in addition to Goal-C fashion breakpoints. By the tip of this part, you’ll be capable to wield the debugger to carry out a lot of the primary duties wanted for debugging, in addition to create your individual easy customized instructions.
On this chapter, you’re going to get acquainted with LLDB and examine the method of introspecting and debugging a program. You’ll begin off by introspecting a program you didn’t even write — Xcode!
Similar to any respectable developer instrument, LLDB ships with a wholesome quantity of documentation. Figuring out tips on how to navigate by way of this documentation — together with among the extra obscure command flags — is important to mastering LLDB.
Now that you have discovered in regards to the two most important instructions, assist and apropos, it is time to examine all of the methods LLDB can connect itself to a course of.
Whether or not you’re utilizing Swift, Goal-C, C++, C, or a completely totally different language in your expertise stack, you’ll must learn to create breakpoints. It’s simple to click on on the facet panel in Xcode to create a breakpoint utilizing the GUI, however the LLDB console may give you rather more management over breakpoints.
Discover ways to question and manipulate the software program you’re debugging. On this chapter, you’ll be taught in regards to the **`expression`** command, which lets you question variables and execute arbitrary code.
You’ve discovered tips on how to create breakpoints, tips on how to print and modify values, in addition to tips on how to execute code whereas paused within the debugger. However to this point you’ve been left excessive and dry on tips on how to transfer round within the debugger and examine information past the instant. On this chapter, you’ll learn to transfer the debugger out and in of code whereas `lldb` has suspended a program.
It is time to discover the most effective instruments for locating code of curiosity by way of the powers of lldb. On this chapter, you will take a deep dive into the picture command.
Study a lovely different to creating breakpoints by monitoring reads or writes to reminiscence.
On this chapter, you’ll learn to create easy, customized instructions after which persist them for utilizing each time you launch `lldb`.
On this chapter, you’ll learn to create instructions that may take inputs.
Figuring out what the pc is doing with all these 1s and 0s beneath your code is a wonderful ability to have when digging for helpful details about a program. This part will set you up with the idea you’ll want for the rest of this guide as a way to create advanced debugging scripts — and introduce you to the essential concept behind reverse-engineering code.
Now you’ve gained a primary understanding of tips on how to maneuver across the debugger, it’s time to take a step down the executable Jenga tower and discover the 1s and 0s that make up your supply code. This part will concentrate on the low-level elements of debugging.
On this chapter, you’ll discover how a program executes. You’ll take a look at a particular register used to inform the processor the place it ought to learn the subsequent instruction from, in addition to how totally different sizes and groupings of reminiscence can produce very totally different outcomes.
What does being “handed on the stack” imply precisely? It’s time to take a deeper dive into what occurs when a perform is named from an meeting standpoint by exploring some “stack associated” registers in addition to the contents within the stack.
With a basis of assembler concept solidly beneath you, it’s time to discover different elements of how applications work. This part is an eclectic grab-bag of bizarre and enjoyable research into reverse engineering, seldom-used APIs and debugging methods.
On this chapter, you’ll study a particular API that permits debugging and even disables different processes from debugging the calling course of.
Shared libraries are important for any program to run. This chapter focuses on the compilation and linking course of, highlighting tips on how to write code that makes use of private and non-private APIs.
It’s time to be taught in regards to the complementary expertise of creating with these frameworks. On this chapter, you’re going to study strategies and methods to “hook” into Swift and C code in addition to execute strategies you wouldn’t usually have entry to.
The file format used for a compiled program working on any Apple {hardware}. This chapter discusses tips on how to learn this data.
Now that you have discovered the idea, it is time to have some enjoyable. Discover ways to seek for curse phrases in Apple frameworks and cheat at playing video games.
This chapter provides you with a primary overview of how code signing works by having you decide aside an iOS utility and learn to re-sign and set up it onto your iOS machine.
You’ve discovered the essential LLDB instructions, the meeting that goes into code and the miscellaneous low-level ideas that make a program…nicely, a program.
It’s time to place that data collectively to create some very highly effective and complicated debugging scripts. As you’ll quickly see, you’re solely restricted by your ability and creativeness — and discovering the proper class (or header file) to do your debugging bidding.
LLDB ships with an built-in Python module that means that you can entry most components of the debugger by way of Python. This allows you to leverage all the ability of Python (and its modules) to assist uncover no matter darkish secrets and techniques vex you.
Subsequent up within the tradeoff between comfort and complexity is LLDB’s script bridging. With script bridging, you are able to do almost something you want. Script bridging is a Python interface LLDB makes use of to assist prolong the debugger to perform your wildest debugging goals.
You want a methodical method to determine what went flawed in your LLDB script so that you don’t pull your hair out. On this chapter, you’ll discover tips on how to examine your LLDB Python scripts utilizing the Python pdb module, which is used for debugging Python scripts.
You’ve discovered the necessities of working with LLDB’s Python module, in addition to tips on how to right any errors utilizing Python’s PDB debugging module. Now you’ll discover the primary gamers inside the lldb Python module for a very good overview of the primary components. On this chapter, you’ll add some arguments to this script and take care of some annoying edge circumstances, such dealing with instructions in a different way between Goal-C and Swift.
Once you’re making a customized debugging command, you’ll usually need to barely tweak performance primarily based upon choices or arguments provided to your command. A customized LLDB command that may do a job just one method is a boring one-trick pony. On this chapter, you’ll discover tips on how to move non-compulsory parameters (aka choices) in addition to arguments (parameters that are anticipated) to your customized command to change performance or logic in your customized LLDB scripts.
To date, when evaluating JIT code (i.e. Goal-C, Swift, C, and so on. code that’s executed by way of your Python script), you’ve used a small set of APIs to guage the code. It’s time to speak a couple of new class within the lldb Python module, SBValue, and the way it can simplify the parsing of JIT code output.
For the remainder of the chapters on this part, you will concentrate on Python scripts. As alluded to within the earlier chapter, the picture lookup -rn command is on its method out. Once you end this chapter, you’ll have a brand new script named “lookup” which queries in a a lot cleaner method.
When LLDB comes up in opposition to a stripped executable (an executable devoid of DWARF
debugging data), LLDB received’t have the image data to provide the stack hint. As a substitute, LLDB will generate an artificial title for a way it acknowledges as a way, however doesn’t know what to name it. On this chapter, you’ll construct an LLDB script that can resymbolicate stripped Goal-C capabilities in a stack hint.
For the ultimate chapter on this part, you’ll undergo the identical steps I actually took to know how the MallocStackLogging setting variable is used to get the stack hint when an object is created. From there, you’ll create a customized LLDB command which supplies you the stack hint of when an object was allotted or deallocated in reminiscence — even after the stack hint is lengthy gone from the debugger.
What? Youve by no means heard of DTrace?! It’s AWESOME! DTrace is a instrument that allows you to discover code in dynamic & static methods.
http://dtrace.org/information/preface.html
You’ll be able to create DTrace probes to be compiled into your code (static), or you possibly can examine any code that’s already compiled and working (dynamic). DTrace is a flexible instrument: it may be a profiler, an analyzer, a debugger or something you need.
I usually will use DTrace to solid a wide-reaching internet over code I need to discover, when I’ve no clue the place I ought to begin.
You’ll discover a really small part of what DTrace is able to doing by tracing Goal-C code in already compiled purposes. Utilizing DTrace to watch iOS frameworks (like UIKit) may give you an unbelievable perception into how the authors designed their code.
This chapter will act as a grab-bag of extra DTrace fundamentals, damaging actions (yay!), in addition to tips on how to use DTrace with Swift. On this chapter, you will be taught further methods DTrace can profile code, in addition to tips on how to increase current code with out laying a finger on the precise executable itself.
