2008/3/30 Michael Goffin <mjg at 0x90.org>:
> I'm also here :)
>
> On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation <gammah at gmail.com> wrote:
> > Weeeee....
> >
> > So, am I talking on this list only to nummish at this point?
There's 4 people (including myself) on the list at the moment. I've
invited more people and will probably post a blog entry on OpenRCE
later this week.
I spent this weekend going through the __inst_meth section of
Mail.app, trying to propagate the function names.
Basically, __inst_meth is a section in the _OBJC segment which stores
data on the instance methods. There is a similar one for class methods
and instance variables. As far as I can tell they're grouped by class,
which is defined in an earlier section which I have yet to parse, but
IDA seems to identify the class structure.
In the __inst_meth section data follows this pattern:
uint32 zero; // Always zero
uint32 count; // Number of instance method structs
struct inst_meth[count]; // instance method definitions
byte padding[x]; // not sure what 'x' is, may be arbitrary
on the compiler
The inst_meth struct is defined as follows:
struct inst_meth {
uint32 selector_name_addr; // Offset to an asciz string containing
the name of the method
uint32 data_types; // Type Encoded (Objc guide p123) retval+args ..
need more info to parse
uint32 function_addr; // Offset to the actual function code
}
The IDAPython script to sort through this info is almost done, just
need to sort out the naming collisions. The objc section of the Mach-O
binary is pretty poorly documented as far as I can tell, but once I
get this stuff done, it should make a binary far more readable.
That is until Gammah mentions an obscure flag to pass to otool that
does all of this for me.
--
"Continued expansion diluted the talent pool, forcing owners to
recruit heavily from prisons, mental institutions, and Texas."
| 