Microsoft Word - iOSAppReverseEngineering.docx

Figure 10- 14 [CKMessageEntryTextView setPlaceholderText:]

So the breakpoint should be set at 0x1eac000 + 0x2693BCE0 = 0x287E7CE0.

(lldb) br s -a 0x287E7CE0

Breakpoint 1: where = ChatKit`-[CKMessageEntryTextView setPlaceholderText:], address =

0x287e7ce0

Next, let’s change “bbs.iosre.com” to “[email protected]”, an email address that

supports iMessage, to see if the process stops. As a result, we can find that while we’re editing

the address, the breakpoint is triggered multiple times, meaning [CKMessageEntryTextView

setPlaceholderText:] has been called a lot. Well, here comes a new question: among these calls,

how can we know which one is the call that changes placeholderText from “Text Message” to

“iMessage”? We can do a trick with LLDB’s “com” command:

(lldb) br com add 1

Enter your debugger command(s). Type 'DONE' to end.

> po $r2

> p/x $lr

> c

> DONE

This command is very straightforward; when the breakpoint gets triggered, LLDB prints the

Objective-C description of R2, i.e. the only argument of setPlaceholderText:, then prints LR in

hexadecimal, i.e. the return address of [CKMessageEntryTextView setPlaceholderText:]. If R2 is

“iMessage”, it indicates that the argument is the 1st data source. Meanwhile, since LR is inside

the caller, we can trace the 2nd data source from inside the caller. Clear the address entry and

enter “[email protected]”, then observe when LLDB prints “iMessage”:

<object returned empty description>

(unsigned int) $11 = 0x28768b33

Process 200596 resuming

Command #3 'c' continued the target.

<object returned empty description>

(unsigned int) $13 = 0x28768b33

Process 200596 resuming

Command #3 'c' continued the target.

<object returned empty description>

(unsigned int) $15 = 0x28768b33

Process 200596 resuming

Command #3 'c' continued the target.

Text Message

(unsigned int) $17 = 0x28768b33

Process 200596 resuming

Command #3 'c' continued the target.