From gammah at gmail.com Sun Mar 30 13:52:16 2008 From: gammah at gmail.com (Gammah Radiation) Date: Sun, 30 Mar 2008 12:52:16 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' Message-ID: Weeeee.... So, am I talking on this list only to nummish at this point? From mjg at 0x90.org Sun Mar 30 14:20:17 2008 From: mjg at 0x90.org (Michael Goffin) Date: Sun, 30 Mar 2008 14:20:17 -0400 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: I'm also here :) On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation wrote: > Weeeee.... > > So, am I talking on this list only to nummish at this point? > _______________________________________________ > XSO mailing list > XSO at 0x90.org > http://0x90.org/mailman/listinfo/xso > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://0x90.org/pipermail/xso/attachments/20080330/56e8a286/attachment.htm From nummish at 0x90.org Sun Mar 30 20:33:21 2008 From: nummish at 0x90.org (nummish) Date: Sun, 30 Mar 2008 19:33:21 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: 2008/3/30 Michael Goffin : > I'm also here :) > > On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation 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." From gammah at gmail.com Sun Mar 30 13:52:16 2008 From: gammah at gmail.com (Gammah Radiation) Date: Sun, 30 Mar 2008 12:52:16 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' Message-ID: Weeeee.... So, am I talking on this list only to nummish at this point? From mjg at 0x90.org Sun Mar 30 14:20:17 2008 From: mjg at 0x90.org (Michael Goffin) Date: Sun, 30 Mar 2008 14:20:17 -0400 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: I'm also here :) On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation wrote: > Weeeee.... > > So, am I talking on this list only to nummish at this point? > _______________________________________________ > XSO mailing list > XSO at 0x90.org > http://0x90.org/mailman/listinfo/xso > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://0x90.org/pipermail/xso/attachments/20080330/56e8a286/attachment.html From nummish at 0x90.org Sun Mar 30 20:33:21 2008 From: nummish at 0x90.org (nummish) Date: Sun, 30 Mar 2008 19:33:21 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: 2008/3/30 Michael Goffin : > I'm also here :) > > On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation 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." From gammah at gmail.com Sun Mar 30 13:52:16 2008 From: gammah at gmail.com (Gammah Radiation) Date: Sun, 30 Mar 2008 12:52:16 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' Message-ID: Weeeee.... So, am I talking on this list only to nummish at this point? From mjg at 0x90.org Sun Mar 30 14:20:17 2008 From: mjg at 0x90.org (Michael Goffin) Date: Sun, 30 Mar 2008 14:20:17 -0400 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: I'm also here :) On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation wrote: > Weeeee.... > > So, am I talking on this list only to nummish at this point? > _______________________________________________ > XSO mailing list > XSO at 0x90.org > http://0x90.org/mailman/listinfo/xso > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://0x90.org/pipermail/xso/attachments/20080330/56e8a286/attachment-0001.html From nummish at 0x90.org Sun Mar 30 20:33:21 2008 From: nummish at 0x90.org (nummish) Date: Sun, 30 Mar 2008 19:33:21 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: 2008/3/30 Michael Goffin : > I'm also here :) > > On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation 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." From gammah at gmail.com Sun Mar 30 13:52:16 2008 From: gammah at gmail.com (Gammah Radiation) Date: Sun, 30 Mar 2008 12:52:16 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' Message-ID: Weeeee.... So, am I talking on this list only to nummish at this point? From mjg at 0x90.org Sun Mar 30 14:20:17 2008 From: mjg at 0x90.org (Michael Goffin) Date: Sun, 30 Mar 2008 14:20:17 -0400 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: I'm also here :) On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation wrote: > Weeeee.... > > So, am I talking on this list only to nummish at this point? > _______________________________________________ > XSO mailing list > XSO at 0x90.org > http://0x90.org/mailman/listinfo/xso > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://0x90.org/pipermail/xso/attachments/20080330/56e8a286/attachment-0002.html From nummish at 0x90.org Sun Mar 30 20:33:21 2008 From: nummish at 0x90.org (nummish) Date: Sun, 30 Mar 2008 19:33:21 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: 2008/3/30 Michael Goffin : > I'm also here :) > > On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation 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." From gammah at gmail.com Sun Mar 30 13:52:16 2008 From: gammah at gmail.com (Gammah Radiation) Date: Sun, 30 Mar 2008 12:52:16 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' Message-ID: Weeeee.... So, am I talking on this list only to nummish at this point? From mjg at 0x90.org Sun Mar 30 14:20:17 2008 From: mjg at 0x90.org (Michael Goffin) Date: Sun, 30 Mar 2008 14:20:17 -0400 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: I'm also here :) On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation wrote: > Weeeee.... > > So, am I talking on this list only to nummish at this point? > _______________________________________________ > XSO mailing list > XSO at 0x90.org > http://0x90.org/mailman/listinfo/xso > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://0x90.org/pipermail/xso/attachments/20080330/56e8a286/attachment-0003.html From nummish at 0x90.org Sun Mar 30 20:33:21 2008 From: nummish at 0x90.org (nummish) Date: Sun, 30 Mar 2008 19:33:21 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: 2008/3/30 Michael Goffin : > I'm also here :) > > On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation 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." From gammah at gmail.com Sun Mar 30 13:52:16 2008 From: gammah at gmail.com (Gammah Radiation) Date: Sun, 30 Mar 2008 12:52:16 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' Message-ID: Weeeee.... So, am I talking on this list only to nummish at this point? From mjg at 0x90.org Sun Mar 30 14:20:17 2008 From: mjg at 0x90.org (Michael Goffin) Date: Sun, 30 Mar 2008 14:20:17 -0400 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: I'm also here :) On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation wrote: > Weeeee.... > > So, am I talking on this list only to nummish at this point? > _______________________________________________ > XSO mailing list > XSO at 0x90.org > http://0x90.org/mailman/listinfo/xso > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://0x90.org/pipermail/xso/attachments/20080330/56e8a286/attachment-0004.html From nummish at 0x90.org Sun Mar 30 20:33:21 2008 From: nummish at 0x90.org (nummish) Date: Sun, 30 Mar 2008 19:33:21 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: 2008/3/30 Michael Goffin : > I'm also here :) > > On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation 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." From gammah at gmail.com Sun Mar 30 13:52:16 2008 From: gammah at gmail.com (Gammah Radiation) Date: Sun, 30 Mar 2008 12:52:16 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' Message-ID: Weeeee.... So, am I talking on this list only to nummish at this point? From mjg at 0x90.org Sun Mar 30 14:20:17 2008 From: mjg at 0x90.org (Michael Goffin) Date: Sun, 30 Mar 2008 14:20:17 -0400 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: I'm also here :) On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation wrote: > Weeeee.... > > So, am I talking on this list only to nummish at this point? > _______________________________________________ > XSO mailing list > XSO at 0x90.org > http://0x90.org/mailman/listinfo/xso > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://0x90.org/pipermail/xso/attachments/20080330/56e8a286/attachment-0005.html From nummish at 0x90.org Sun Mar 30 20:33:21 2008 From: nummish at 0x90.org (nummish) Date: Sun, 30 Mar 2008 19:33:21 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: 2008/3/30 Michael Goffin : > I'm also here :) > > On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation 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." From gammah at gmail.com Sun Mar 30 13:52:16 2008 From: gammah at gmail.com (Gammah Radiation) Date: Sun, 30 Mar 2008 12:52:16 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' Message-ID: Weeeee.... So, am I talking on this list only to nummish at this point? From mjg at 0x90.org Sun Mar 30 14:20:17 2008 From: mjg at 0x90.org (Michael Goffin) Date: Sun, 30 Mar 2008 14:20:17 -0400 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: I'm also here :) On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation wrote: > Weeeee.... > > So, am I talking on this list only to nummish at this point? > _______________________________________________ > XSO mailing list > XSO at 0x90.org > http://0x90.org/mailman/listinfo/xso > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://0x90.org/pipermail/xso/attachments/20080330/56e8a286/attachment-0006.html From nummish at 0x90.org Sun Mar 30 20:33:21 2008 From: nummish at 0x90.org (nummish) Date: Sun, 30 Mar 2008 19:33:21 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: 2008/3/30 Michael Goffin : > I'm also here :) > > On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation 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." From gammah at gmail.com Sun Mar 30 13:52:16 2008 From: gammah at gmail.com (Gammah Radiation) Date: Sun, 30 Mar 2008 12:52:16 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' Message-ID: Weeeee.... So, am I talking on this list only to nummish at this point? From mjg at 0x90.org Sun Mar 30 14:20:17 2008 From: mjg at 0x90.org (Michael Goffin) Date: Sun, 30 Mar 2008 14:20:17 -0400 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: I'm also here :) On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation wrote: > Weeeee.... > > So, am I talking on this list only to nummish at this point? > _______________________________________________ > XSO mailing list > XSO at 0x90.org > http://0x90.org/mailman/listinfo/xso > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://0x90.org/pipermail/xso/attachments/20080330/56e8a286/attachment-0007.html From nummish at 0x90.org Sun Mar 30 20:33:21 2008 From: nummish at 0x90.org (nummish) Date: Sun, 30 Mar 2008 19:33:21 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: 2008/3/30 Michael Goffin : > I'm also here :) > > On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation 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." From gammah at gmail.com Sun Mar 30 13:52:16 2008 From: gammah at gmail.com (Gammah Radiation) Date: Sun, 30 Mar 2008 12:52:16 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' Message-ID: Weeeee.... So, am I talking on this list only to nummish at this point? From mjg at 0x90.org Sun Mar 30 14:20:17 2008 From: mjg at 0x90.org (Michael Goffin) Date: Sun, 30 Mar 2008 14:20:17 -0400 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: I'm also here :) On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation wrote: > Weeeee.... > > So, am I talking on this list only to nummish at this point? > _______________________________________________ > XSO mailing list > XSO at 0x90.org > http://0x90.org/mailman/listinfo/xso > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://0x90.org/pipermail/xso/attachments/20080330/56e8a286/attachment-0008.html From nummish at 0x90.org Sun Mar 30 20:33:21 2008 From: nummish at 0x90.org (nummish) Date: Sun, 30 Mar 2008 19:33:21 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: 2008/3/30 Michael Goffin : > I'm also here :) > > On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation 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." From gammah at gmail.com Sun Mar 30 13:52:16 2008 From: gammah at gmail.com (Gammah Radiation) Date: Sun, 30 Mar 2008 12:52:16 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' Message-ID: Weeeee.... So, am I talking on this list only to nummish at this point? From mjg at 0x90.org Sun Mar 30 14:20:17 2008 From: mjg at 0x90.org (Michael Goffin) Date: Sun, 30 Mar 2008 14:20:17 -0400 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: I'm also here :) On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation wrote: > Weeeee.... > > So, am I talking on this list only to nummish at this point? > _______________________________________________ > XSO mailing list > XSO at 0x90.org > http://0x90.org/mailman/listinfo/xso > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://0x90.org/pipermail/xso/attachments/20080330/56e8a286/attachment-0009.html From nummish at 0x90.org Sun Mar 30 20:33:21 2008 From: nummish at 0x90.org (nummish) Date: Sun, 30 Mar 2008 19:33:21 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: 2008/3/30 Michael Goffin : > I'm also here :) > > On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation 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." From gammah at gmail.com Sun Mar 30 13:52:16 2008 From: gammah at gmail.com (Gammah Radiation) Date: Sun, 30 Mar 2008 12:52:16 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' Message-ID: Weeeee.... So, am I talking on this list only to nummish at this point? From mjg at 0x90.org Sun Mar 30 14:20:17 2008 From: mjg at 0x90.org (Michael Goffin) Date: Sun, 30 Mar 2008 14:20:17 -0400 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: I'm also here :) On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation wrote: > Weeeee.... > > So, am I talking on this list only to nummish at this point? > _______________________________________________ > XSO mailing list > XSO at 0x90.org > http://0x90.org/mailman/listinfo/xso > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://0x90.org/pipermail/xso/attachments/20080330/56e8a286/attachment-0010.html From nummish at 0x90.org Sun Mar 30 20:33:21 2008 From: nummish at 0x90.org (nummish) Date: Sun, 30 Mar 2008 19:33:21 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: 2008/3/30 Michael Goffin : > I'm also here :) > > On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation 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." From gammah at gmail.com Sun Mar 30 13:52:16 2008 From: gammah at gmail.com (Gammah Radiation) Date: Sun, 30 Mar 2008 12:52:16 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' Message-ID: Weeeee.... So, am I talking on this list only to nummish at this point? From mjg at 0x90.org Sun Mar 30 14:20:17 2008 From: mjg at 0x90.org (Michael Goffin) Date: Sun, 30 Mar 2008 14:20:17 -0400 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: I'm also here :) On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation wrote: > Weeeee.... > > So, am I talking on this list only to nummish at this point? > _______________________________________________ > XSO mailing list > XSO at 0x90.org > http://0x90.org/mailman/listinfo/xso > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://0x90.org/pipermail/xso/attachments/20080330/56e8a286/attachment-0011.html From nummish at 0x90.org Sun Mar 30 20:33:21 2008 From: nummish at 0x90.org (nummish) Date: Sun, 30 Mar 2008 19:33:21 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: 2008/3/30 Michael Goffin : > I'm also here :) > > On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation 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." From gammah at gmail.com Sun Mar 30 13:52:16 2008 From: gammah at gmail.com (Gammah Radiation) Date: Sun, 30 Mar 2008 12:52:16 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' Message-ID: Weeeee.... So, am I talking on this list only to nummish at this point? From mjg at 0x90.org Sun Mar 30 14:20:17 2008 From: mjg at 0x90.org (Michael Goffin) Date: Sun, 30 Mar 2008 14:20:17 -0400 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: I'm also here :) On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation wrote: > Weeeee.... > > So, am I talking on this list only to nummish at this point? > _______________________________________________ > XSO mailing list > XSO at 0x90.org > http://0x90.org/mailman/listinfo/xso > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://0x90.org/pipermail/xso/attachments/20080330/56e8a286/attachment-0012.html From nummish at 0x90.org Sun Mar 30 20:33:21 2008 From: nummish at 0x90.org (nummish) Date: Sun, 30 Mar 2008 19:33:21 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: 2008/3/30 Michael Goffin : > I'm also here :) > > On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation 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." From gammah at gmail.com Sun Mar 30 13:52:16 2008 From: gammah at gmail.com (Gammah Radiation) Date: Sun, 30 Mar 2008 12:52:16 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' Message-ID: Weeeee.... So, am I talking on this list only to nummish at this point? From mjg at 0x90.org Sun Mar 30 14:20:17 2008 From: mjg at 0x90.org (Michael Goffin) Date: Sun, 30 Mar 2008 14:20:17 -0400 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: I'm also here :) On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation wrote: > Weeeee.... > > So, am I talking on this list only to nummish at this point? > _______________________________________________ > XSO mailing list > XSO at 0x90.org > http://0x90.org/mailman/listinfo/xso > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://0x90.org/pipermail/xso/attachments/20080330/56e8a286/attachment-0013.html From nummish at 0x90.org Sun Mar 30 20:33:21 2008 From: nummish at 0x90.org (nummish) Date: Sun, 30 Mar 2008 19:33:21 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: 2008/3/30 Michael Goffin : > I'm also here :) > > On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation 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." From gammah at gmail.com Sun Mar 30 13:52:16 2008 From: gammah at gmail.com (Gammah Radiation) Date: Sun, 30 Mar 2008 12:52:16 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' Message-ID: Weeeee.... So, am I talking on this list only to nummish at this point? From mjg at 0x90.org Sun Mar 30 14:20:17 2008 From: mjg at 0x90.org (Michael Goffin) Date: Sun, 30 Mar 2008 14:20:17 -0400 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: I'm also here :) On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation wrote: > Weeeee.... > > So, am I talking on this list only to nummish at this point? > _______________________________________________ > XSO mailing list > XSO at 0x90.org > http://0x90.org/mailman/listinfo/xso > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://0x90.org/pipermail/xso/attachments/20080330/56e8a286/attachment-0014.html From nummish at 0x90.org Sun Mar 30 20:33:21 2008 From: nummish at 0x90.org (nummish) Date: Sun, 30 Mar 2008 19:33:21 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: 2008/3/30 Michael Goffin : > I'm also here :) > > On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation 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." From gammah at gmail.com Sun Mar 30 13:52:16 2008 From: gammah at gmail.com (Gammah Radiation) Date: Sun, 30 Mar 2008 12:52:16 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' Message-ID: Weeeee.... So, am I talking on this list only to nummish at this point? From mjg at 0x90.org Sun Mar 30 14:20:17 2008 From: mjg at 0x90.org (Michael Goffin) Date: Sun, 30 Mar 2008 14:20:17 -0400 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: I'm also here :) On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation wrote: > Weeeee.... > > So, am I talking on this list only to nummish at this point? > _______________________________________________ > XSO mailing list > XSO at 0x90.org > http://0x90.org/mailman/listinfo/xso > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://0x90.org/pipermail/xso/attachments/20080330/56e8a286/attachment-0015.html From nummish at 0x90.org Sun Mar 30 20:33:21 2008 From: nummish at 0x90.org (nummish) Date: Sun, 30 Mar 2008 19:33:21 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: 2008/3/30 Michael Goffin : > I'm also here :) > > On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation 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." From gammah at gmail.com Sun Mar 30 13:52:16 2008 From: gammah at gmail.com (Gammah Radiation) Date: Sun, 30 Mar 2008 12:52:16 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' Message-ID: Weeeee.... So, am I talking on this list only to nummish at this point? From mjg at 0x90.org Sun Mar 30 14:20:17 2008 From: mjg at 0x90.org (Michael Goffin) Date: Sun, 30 Mar 2008 14:20:17 -0400 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: I'm also here :) On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation wrote: > Weeeee.... > > So, am I talking on this list only to nummish at this point? > _______________________________________________ > XSO mailing list > XSO at 0x90.org > http://0x90.org/mailman/listinfo/xso > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://0x90.org/pipermail/xso/attachments/20080330/56e8a286/attachment-0016.html From nummish at 0x90.org Sun Mar 30 20:33:21 2008 From: nummish at 0x90.org (nummish) Date: Sun, 30 Mar 2008 19:33:21 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: 2008/3/30 Michael Goffin : > I'm also here :) > > On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation 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." From gammah at gmail.com Sun Mar 30 13:52:16 2008 From: gammah at gmail.com (Gammah Radiation) Date: Sun, 30 Mar 2008 12:52:16 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' Message-ID: Weeeee.... So, am I talking on this list only to nummish at this point? From mjg at 0x90.org Sun Mar 30 14:20:17 2008 From: mjg at 0x90.org (Michael Goffin) Date: Sun, 30 Mar 2008 14:20:17 -0400 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: I'm also here :) On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation wrote: > Weeeee.... > > So, am I talking on this list only to nummish at this point? > _______________________________________________ > XSO mailing list > XSO at 0x90.org > http://0x90.org/mailman/listinfo/xso > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://0x90.org/pipermail/xso/attachments/20080330/56e8a286/attachment-0017.html From nummish at 0x90.org Sun Mar 30 20:33:21 2008 From: nummish at 0x90.org (nummish) Date: Sun, 30 Mar 2008 19:33:21 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: 2008/3/30 Michael Goffin : > I'm also here :) > > On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation 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." From gammah at gmail.com Sun Mar 30 13:52:16 2008 From: gammah at gmail.com (Gammah Radiation) Date: Sun, 30 Mar 2008 12:52:16 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' Message-ID: Weeeee.... So, am I talking on this list only to nummish at this point? From mjg at 0x90.org Sun Mar 30 14:20:17 2008 From: mjg at 0x90.org (Michael Goffin) Date: Sun, 30 Mar 2008 14:20:17 -0400 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: I'm also here :) On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation wrote: > Weeeee.... > > So, am I talking on this list only to nummish at this point? > _______________________________________________ > XSO mailing list > XSO at 0x90.org > http://0x90.org/mailman/listinfo/xso > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://0x90.org/pipermail/xso/attachments/20080330/56e8a286/attachment-0018.html From nummish at 0x90.org Sun Mar 30 20:33:21 2008 From: nummish at 0x90.org (nummish) Date: Sun, 30 Mar 2008 19:33:21 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: 2008/3/30 Michael Goffin : > I'm also here :) > > On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation 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." From gammah at gmail.com Sun Mar 30 13:52:16 2008 From: gammah at gmail.com (Gammah Radiation) Date: Sun, 30 Mar 2008 12:52:16 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' Message-ID: Weeeee.... So, am I talking on this list only to nummish at this point? From mjg at 0x90.org Sun Mar 30 14:20:17 2008 From: mjg at 0x90.org (Michael Goffin) Date: Sun, 30 Mar 2008 14:20:17 -0400 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: I'm also here :) On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation wrote: > Weeeee.... > > So, am I talking on this list only to nummish at this point? > _______________________________________________ > XSO mailing list > XSO at 0x90.org > http://0x90.org/mailman/listinfo/xso > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://0x90.org/pipermail/xso/attachments/20080330/56e8a286/attachment-0019.html From nummish at 0x90.org Sun Mar 30 20:33:21 2008 From: nummish at 0x90.org (nummish) Date: Sun, 30 Mar 2008 19:33:21 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: 2008/3/30 Michael Goffin : > I'm also here :) > > On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation 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." From gammah at gmail.com Sun Mar 30 21:51:35 2008 From: gammah at gmail.com (Gammah Radiation) Date: Sun, 30 Mar 2008 20:51:35 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: On Sun, Mar 30, 2008 at 7:33 PM, nummish wrote: > That is until Gammah mentions an obscure flag to pass to otool that > does all of this for me. "--xso" of course! :) From gammah at gmail.com Sun Mar 30 13:52:16 2008 From: gammah at gmail.com (Gammah Radiation) Date: Sun, 30 Mar 2008 12:52:16 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' Message-ID: Weeeee.... So, am I talking on this list only to nummish at this point? From mjg at 0x90.org Sun Mar 30 14:20:17 2008 From: mjg at 0x90.org (Michael Goffin) Date: Sun, 30 Mar 2008 14:20:17 -0400 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: I'm also here :) On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation wrote: > Weeeee.... > > So, am I talking on this list only to nummish at this point? > _______________________________________________ > XSO mailing list > XSO at 0x90.org > http://0x90.org/mailman/listinfo/xso > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://0x90.org/pipermail/xso/attachments/20080330/56e8a286/attachment-0020.html From nummish at 0x90.org Sun Mar 30 20:33:21 2008 From: nummish at 0x90.org (nummish) Date: Sun, 30 Mar 2008 19:33:21 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: 2008/3/30 Michael Goffin : > I'm also here :) > > On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation 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." From gammah at gmail.com Sun Mar 30 21:51:35 2008 From: gammah at gmail.com (Gammah Radiation) Date: Sun, 30 Mar 2008 20:51:35 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: On Sun, Mar 30, 2008 at 7:33 PM, nummish wrote: > That is until Gammah mentions an obscure flag to pass to otool that > does all of this for me. "--xso" of course! :) From nummish at 0x90.org Mon Mar 31 00:32:07 2008 From: nummish at 0x90.org (nummish) Date: Sun, 30 Mar 2008 23:32:07 -0500 Subject: [XSO] CFString in a binary Message-ID: The section is in the format: C8 07 00 00 XX XX XX XX YY YY YY YY XX XX XX XX is an offset to the asciz string being referenced. YY YY YY YY is a little endian value equal to the non-terminated length of X What could C8 07 00 00 be? My first assumption is that it would be the string encoding of the CFString stored in the binary, but I can't find any reference to that value directly and it doesn't look like values would be ORed together like that. Thoughts? -- "Continued expansion diluted the talent pool, forcing owners to recruit heavily from prisons, mental institutions, and Texas." From gammah at gmail.com Sun Mar 30 13:52:16 2008 From: gammah at gmail.com (Gammah Radiation) Date: Sun, 30 Mar 2008 12:52:16 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' Message-ID: Weeeee.... So, am I talking on this list only to nummish at this point? From mjg at 0x90.org Sun Mar 30 14:20:17 2008 From: mjg at 0x90.org (Michael Goffin) Date: Sun, 30 Mar 2008 14:20:17 -0400 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: I'm also here :) On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation wrote: > Weeeee.... > > So, am I talking on this list only to nummish at this point? > _______________________________________________ > XSO mailing list > XSO at 0x90.org > http://0x90.org/mailman/listinfo/xso > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://0x90.org/pipermail/xso/attachments/20080330/56e8a286/attachment-0021.html From nummish at 0x90.org Sun Mar 30 20:33:21 2008 From: nummish at 0x90.org (nummish) Date: Sun, 30 Mar 2008 19:33:21 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: 2008/3/30 Michael Goffin : > I'm also here :) > > On Sun, Mar 30, 2008 at 1:52 PM, Gammah Radiation 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." From gammah at gmail.com Sun Mar 30 21:51:35 2008 From: gammah at gmail.com (Gammah Radiation) Date: Sun, 30 Mar 2008 20:51:35 -0500 Subject: [XSO] ruby -e 'p "osx".reverse' In-Reply-To: References: Message-ID: On Sun, Mar 30, 2008 at 7:33 PM, nummish wrote: > That is until Gammah mentions an obscure flag to pass to otool that > does all of this for me. "--xso" of course! :) From nummish at 0x90.org Mon Mar 31 00:32:07 2008 From: nummish at 0x90.org (nummish) Date: Sun, 30 Mar 2008 23:32:07 -0500 Subject: [XSO] CFString in a binary Message-ID: The section is in the format: C8 07 00 00 XX XX XX XX YY YY YY YY XX XX XX XX is an offset to the asciz string being referenced. YY YY YY YY is a little endian value equal to the non-terminated length of X What could C8 07 00 00 be? My first assumption is that it would be the string encoding of the CFString stored in the binary, but I can't find any reference to that value directly and it doesn't look like values would be ORed together like that. Thoughts? -- "Continued expansion diluted the talent pool, forcing owners to recruit heavily from prisons, mental institutions, and Texas."