Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Often, you can work from what you know towards what you don't. This is likely used to implement a public CoreGraphics API; if you can find a function with known parameters calling this, you can pretty readily work out the parameters of this function.</p> <p>You can work out how many arguments the function has by looking at the arguments it pulls off the stack. For example:</p> <pre><code> +18 0008987c 8b4508 movl 0x08(%ebp),%eax +21 0008987f 85c0 testl %eax,%eax +23 00089881 740c je 0x0008988f </code></pre> <p>You can tell from this that the first argument is most likely a 32-bit value. It's being tested against zero. Since this is a <code>CGContext</code> function, the first argument is almost certainly <code>CGContextRef ctx</code>, so these three instructions correspond to:</p> <pre><code>if (NULL == ctx) goto L0; </code></pre> <p>where I have glossed 0x008988f with L0 in the assembly.</p> <pre><code> +25 00089883 8b4508 movl 0x08(%ebp),%eax +28 00089886 81780854585443 cmpl $0x43545854,0x08(%eax) +35 0008988d 7424 je 0x000898b3 if (0x43545854 == ((int *)ctx)[2]) goto L1; </code></pre> <p>And here we see a comparison of a structure member against some known value that's being special-cased. It could be a magic number to verify the validity of the context. The code at the target address might reveal why it's being treated special.</p> <pre><code> +37 0008988f 8b5508 movl 0x08(%ebp),%edx +40 00089892 89542408 movl %edx,0x08(%esp) void *f0 = *ctx; </code></pre> <p>This dereferences the context pointer. If it's an Obj-C object behind the scenes, then this will be the <code>isa</code> pointer referencing an Obj-C class. If not, then the context is likely some other sort of structure, and the code has just grabbed out some data from the very start of the structure. Setting a breakpoint here and trying to <code>print-object</code> the provided address should answer which of these is true. (I'm betting on the Obj-C object case.)</p> <pre><code> +44 00089896 8d836ce16f00 leal 0x006fe16c(%ebx),%eax +50 0008989c 89442404 movl %eax,0x04(%esp) +54 000898a0 8d8341ae6f00 leal 0x006fae41(%ebx),%eax </code></pre> <p>Too bad you stopped there. Looks like it's setting up for a function call: stick the arguments on the stack, then call through. You can see it grabbing some relocated addresses based on a known address from early in the function (which the function found via that nifty <code>call/pop</code> trick it did during the prologue).</p> <p>I recommend you grab a copy of <a href="http://otx.osxninja.com/" rel="noreferrer"><code>otx</code></a> – grab and build the SVN version, as it can handle x86_64. This does some work upfront to help you understand the disassembly, as well as formatting the disassembly nicely into basic blocks.</p> <p>Also pick up <a href="http://www.codethecode.com/projects/class-dump/" rel="noreferrer"><code>class-dump</code></a>. This examines the Obj-C segments of the binaries you run it on and dumps out Obj-C header files for all the classes, categories, and protocols found in the binary.</p> <p>Running both of these on the binary you're interested in can give you a big leg up.</p> <p>If you're willing to spring for it, IDA Pro is considered the best tool out there for reverse engineering. I have never used it, but I can see where it would be tremendously helpful.</p> <p>Other resources:</p> <ul> <li>The <a href="http://www.intel.com/products/processor/manuals/" rel="noreferrer">Intel ISA documents</a> describe the IA-32 and IA-64 architectures and their instructions.</li> <li><a href="http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/LowLevelABI/000-Introduction/introduction.html" rel="noreferrer">"Introduction to Mac OS X ABI Function Call Guide"</a> describes how arguments are passed to functions.</li> <li>Rich Wareham's <a href="http://www.osnews.com/story/10366" rel="noreferrer">"A Brief Tutorial on Reverse Engineering OS X"</a> looks helpful for a beginner.</li> <li>The <a href="http://reverse.put.as/" rel="noreferrer">"Reverse Engineering OS X" blog</a> has a lot of interesting content, but I don't know how helpful it will be for you.</li> </ul> <p>One more thing: Apple is generally pretty regular in its naming of functions. A function like <code>CGContextDrawImages</code> has two likely signatures, depending on how the images are passed:</p> <pre><code>/* CGImageRefs contained in a Core Foundation array. */ void CGContextDrawImages(CGContextRef ctx, CFArrayRef images); /* CGImageRefs passed in a C array. */ void CGContextDrawImages(CGContextRef ctx, CGImageRef images[], size_t count); </code></pre> <p>There might also be a "where to draw this" <code>CGRect</code> argument or array of arguments. But at least you're not completely in the dark about what the function prototype should be.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload