From gammah at gmail.com  Tue Apr  1 13:26:48 2008
From: gammah at gmail.com (Gammah Radiation)
Date: Tue, 1 Apr 2008 12:26:48 -0500
Subject: [XSO] CFString in a binary
In-Reply-To: <ad2d22a80803302132t7ff0ecb0w97c5d422a6fad9d2@mail.gmail.com>
References: <ad2d22a80803302132t7ff0ecb0w97c5d422a6fad9d2@mail.gmail.com>
Message-ID: <a77b1a520804011026g3ea28081ue492213b9e2bab7b@mail.gmail.com>

On Sun, Mar 30, 2008 at 11:32 PM, nummish <nummish at 0x90.org> wrote:
> The section is in the format:
>
>  C8 07 00 00 XX XX XX XX YY YY YY YY

I haven't looked much further than this, but from CFString.h I am
guessing it's related to the string encoding? This starts at line 119


enum {
    kCFStringEncodingMacRoman = 0,
    kCFStringEncodingWindowsLatin1 = 0x0500, /* ANSI codepage 1252 */
    kCFStringEncodingISOLatin1 = 0x0201, /* ISO 8859-1 */
    kCFStringEncodingNextStepLatin = 0x0B01, /* NextStep encoding*/
    kCFStringEncodingASCII = 0x0600, /* 0..127 (in creating CFString,
values greater than 0x7F are treated as corresponding Unicode value)
*/
    kCFStringEncodingUnicode = 0x0100, /* kTextEncodingUnicodeDefault
+ kTextEncodingDefaultFormat (aka kUnicode16BitFormat) */
    kCFStringEncodingUTF8 = 0x08000100, /* kTextEncodingUnicodeDefault
+ kUnicodeUTF8Format */
    kCFStringEncodingNonLossyASCII = 0x0BFF /* 7bit Unicode variants
used by Cocoa & Java */
#if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_4
    ,
    kCFStringEncodingUTF16 = 0x0100, /* kTextEncodingUnicodeDefault +
kUnicodeUTF16Format (alias of kCFStringEncodingUnicode) */
    kCFStringEncodingUTF16BE = 0x10000100, /*
kTextEncodingUnicodeDefault + kUnicodeUTF16BEFormat */
    kCFStringEncodingUTF16LE = 0x14000100, /*
kTextEncodingUnicodeDefault + kUnicodeUTF16LEFormat */

    kCFStringEncodingUTF32 = 0x0c000100, /*
kTextEncodingUnicodeDefault + kUnicodeUTF32Format */
    kCFStringEncodingUTF32BE = 0x18000100, /*
kTextEncodingUnicodeDefault + kUnicodeUTF32BEFormat */
    kCFStringEncodingUTF32LE = 0x1c000100 /*
kTextEncodingUnicodeDefault + kUnicodeUTF32LEFormat */
#endif /* MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_4 */
};
typedef CFStringEncoding CFStringBuiltInEncodings;


My guess would be those strings are UTF32 encoded perhaps? I just
reread your post and realize you have already read the above code
(likely), so that might not be a helpful response.

From nummish at 0x90.org  Tue Apr  1 14:23:03 2008
From: nummish at 0x90.org (nummish)
Date: Tue, 1 Apr 2008 13:23:03 -0500
Subject: [XSO] CFString in a binary
In-Reply-To: <a77b1a520804011026g3ea28081ue492213b9e2bab7b@mail.gmail.com>
References: <ad2d22a80803302132t7ff0ecb0w97c5d422a6fad9d2@mail.gmail.com>
	<a77b1a520804011026g3ea28081ue492213b9e2bab7b@mail.gmail.com>
Message-ID: <ad2d22a80804011123pdd37b24s6628505e19a33083@mail.gmail.com>

On Tue, Apr 1, 2008 at 12:26 PM, Gammah Radiation <gammah at gmail.com> wrote:
> On Sun, Mar 30, 2008 at 11:32 PM, nummish <nummish at 0x90.org> wrote:
>  > The section is in the format:
>  >
>  >  C8 07 00 00 XX XX XX XX YY YY YY YY
>
>  I haven't looked much further than this, but from CFString.h I am
>  guessing it's related to the string encoding? This starts at line 119
>
>
>  enum {
>     kCFStringEncodingMacRoman = 0,
>     kCFStringEncodingWindowsLatin1 = 0x0500, /* ANSI codepage 1252 */
>     kCFStringEncodingISOLatin1 = 0x0201, /* ISO 8859-1 */
>     kCFStringEncodingNextStepLatin = 0x0B01, /* NextStep encoding*/
>     kCFStringEncodingASCII = 0x0600, /* 0..127 (in creating CFString,
>  values greater than 0x7F are treated as corresponding Unicode value)
>  */
>     kCFStringEncodingUnicode = 0x0100, /* kTextEncodingUnicodeDefault
>  + kTextEncodingDefaultFormat (aka kUnicode16BitFormat) */
>     kCFStringEncodingUTF8 = 0x08000100, /* kTextEncodingUnicodeDefault
>  + kUnicodeUTF8Format */
>     kCFStringEncodingNonLossyASCII = 0x0BFF /* 7bit Unicode variants
>  used by Cocoa & Java */
>  #if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_4
>     ,
>     kCFStringEncodingUTF16 = 0x0100, /* kTextEncodingUnicodeDefault +
>  kUnicodeUTF16Format (alias of kCFStringEncodingUnicode) */
>     kCFStringEncodingUTF16BE = 0x10000100, /*
>  kTextEncodingUnicodeDefault + kUnicodeUTF16BEFormat */
>     kCFStringEncodingUTF16LE = 0x14000100, /*
>  kTextEncodingUnicodeDefault + kUnicodeUTF16LEFormat */
>
>     kCFStringEncodingUTF32 = 0x0c000100, /*
>  kTextEncodingUnicodeDefault + kUnicodeUTF32Format */
>     kCFStringEncodingUTF32BE = 0x18000100, /*
>  kTextEncodingUnicodeDefault + kUnicodeUTF32BEFormat */
>     kCFStringEncodingUTF32LE = 0x1c000100 /*
>  kTextEncodingUnicodeDefault + kUnicodeUTF32LEFormat */
>  #endif /* MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_4 */
>  };
>  typedef CFStringEncoding CFStringBuiltInEncodings;
>
>
>  My guess would be those strings are UTF32 encoded perhaps? I just
>  reread your post and realize you have already read the above code
>  (likely), so that might not be a helpful response.

Yeah, that's what I was thinking, but the 0x7c8 is throwing me through
a loop. I'm only using IDA 5.1 here, and in the release notes it's
mentioned there is better cfstring handling in 5.2. Does anyone have
IDA 5.2 and are willing to disasm Mail.app and see how it labels the
first part of the strings in the __cfstring section?

From gammah at gmail.com  Tue Apr  1 15:28:52 2008
From: gammah at gmail.com (Gammah Radiation)
Date: Tue, 1 Apr 2008 14:28:52 -0500
Subject: [XSO] CFString in a binary
In-Reply-To: <ad2d22a80804011123pdd37b24s6628505e19a33083@mail.gmail.com>
References: <ad2d22a80803302132t7ff0ecb0w97c5d422a6fad9d2@mail.gmail.com>
	<a77b1a520804011026g3ea28081ue492213b9e2bab7b@mail.gmail.com>
	<ad2d22a80804011123pdd37b24s6628505e19a33083@mail.gmail.com>
Message-ID: <a77b1a520804011228w2c10bd31xd3f079c28c5e20ef@mail.gmail.com>

Ok, so I have IDA5.2, but I'm pretty lame with IDA - looking at the
CFString structure reveals 4 fields in the struct
isa (self pointer)
info
data
length

info is the field containing 0x7c8

Still more looking to do, but alas work is calling my name


On Tue, Apr 1, 2008 at 1:23 PM, nummish <nummish at 0x90.org> wrote:
>
> On Tue, Apr 1, 2008 at 12:26 PM, Gammah Radiation <gammah at gmail.com> wrote:
>  > On Sun, Mar 30, 2008 at 11:32 PM, nummish <nummish at 0x90.org> wrote:
>  >  > The section is in the format:
>  >  >
>  >  >  C8 07 00 00 XX XX XX XX YY YY YY YY
>  >
>  >  I haven't looked much further than this, but from CFString.h I am
>  >  guessing it's related to the string encoding? This starts at line 119
>  >
>  >
>  >  enum {
>  >     kCFStringEncodingMacRoman = 0,
>  >     kCFStringEncodingWindowsLatin1 = 0x0500, /* ANSI codepage 1252 */
>  >     kCFStringEncodingISOLatin1 = 0x0201, /* ISO 8859-1 */
>  >     kCFStringEncodingNextStepLatin = 0x0B01, /* NextStep encoding*/
>  >     kCFStringEncodingASCII = 0x0600, /* 0..127 (in creating CFString,
>  >  values greater than 0x7F are treated as corresponding Unicode value)
>  >  */
>  >     kCFStringEncodingUnicode = 0x0100, /* kTextEncodingUnicodeDefault
>  >  + kTextEncodingDefaultFormat (aka kUnicode16BitFormat) */
>  >     kCFStringEncodingUTF8 = 0x08000100, /* kTextEncodingUnicodeDefault
>  >  + kUnicodeUTF8Format */
>  >     kCFStringEncodingNonLossyASCII = 0x0BFF /* 7bit Unicode variants
>  >  used by Cocoa & Java */
>  >  #if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_4
>  >     ,
>  >     kCFStringEncodingUTF16 = 0x0100, /* kTextEncodingUnicodeDefault +
>  >  kUnicodeUTF16Format (alias of kCFStringEncodingUnicode) */
>  >     kCFStringEncodingUTF16BE = 0x10000100, /*
>  >  kTextEncodingUnicodeDefault + kUnicodeUTF16BEFormat */
>  >     kCFStringEncodingUTF16LE = 0x14000100, /*
>  >  kTextEncodingUnicodeDefault + kUnicodeUTF16LEFormat */
>  >
>  >     kCFStringEncodingUTF32 = 0x0c000100, /*
>  >  kTextEncodingUnicodeDefault + kUnicodeUTF32Format */
>  >     kCFStringEncodingUTF32BE = 0x18000100, /*
>  >  kTextEncodingUnicodeDefault + kUnicodeUTF32BEFormat */
>  >     kCFStringEncodingUTF32LE = 0x1c000100 /*
>  >  kTextEncodingUnicodeDefault + kUnicodeUTF32LEFormat */
>  >  #endif /* MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_4 */
>  >  };
>  >  typedef CFStringEncoding CFStringBuiltInEncodings;
>  >
>  >
>  >  My guess would be those strings are UTF32 encoded perhaps? I just
>  >  reread your post and realize you have already read the above code
>  >  (likely), so that might not be a helpful response.
>
>  Yeah, that's what I was thinking, but the 0x7c8 is throwing me through
>  a loop. I'm only using IDA 5.1 here, and in the release notes it's
>  mentioned there is better cfstring handling in 5.2. Does anyone have
>  IDA 5.2 and are willing to disasm Mail.app and see how it labels the
>  first part of the strings in the __cfstring section?
>
>
> _______________________________________________
>  XSO mailing list
>  XSO at 0x90.org
>  http://0x90.org/mailman/listinfo/xso
>

From gammah at gmail.com  Tue Apr  1 15:31:49 2008
From: gammah at gmail.com (Gammah Radiation)
Date: Tue, 1 Apr 2008 14:31:49 -0500
Subject: [XSO] CFString in a binary
In-Reply-To: <a77b1a520804011228w2c10bd31xd3f079c28c5e20ef@mail.gmail.com>
References: <ad2d22a80803302132t7ff0ecb0w97c5d422a6fad9d2@mail.gmail.com>
	<a77b1a520804011026g3ea28081ue492213b9e2bab7b@mail.gmail.com>
	<ad2d22a80804011123pdd37b24s6628505e19a33083@mail.gmail.com>
	<a77b1a520804011228w2c10bd31xd3f079c28c5e20ef@mail.gmail.com>
Message-ID: <a77b1a520804011231s51f429d7y8c75e30dc48e733a@mail.gmail.com>

looks like my calling 'isa' the 'self' pointer was way wrong - it
appears to be the pointer to the object's class? Maybe someone can
correct me on this.

From nummish at 0x90.org  Tue Apr  1 21:22:42 2008
From: nummish at 0x90.org (nummish)
Date: Tue, 1 Apr 2008 20:22:42 -0500
Subject: [XSO] Arguments to objc_msgSend()
Message-ID: <ad2d22a80804011822o4e76d233w6d904f5efbe05e7f@mail.gmail.com>

The arguments passed to objc_msgSend() on an x86 binary generally
appear to be [ESP] for the recipient and [ESP+4] for the selector.
This throws a brutal monkey wrench into scripts designed to rename
variables to something more sensible where the stack offset changes
part of the way through a subroutine.

Assuming I'm not too worried about porting my IDA scripts to ARM
easily, is it safe to assume that:

   [ESP]     => Selector
   [ESP+4] => Recipient

for all non *_stret msgSend calls?

Anyways, if you're doing anything similar to what I'm doing, just keep
in mind that the function's frame as defined by IDA is the largest
frame, and not necessarily accurate at all portions of the function as
variables come in and out of scope.

</braindump>

From m4cpunk at gmail.com  Wed Apr  2 01:13:42 2008
From: m4cpunk at gmail.com (Dalton Cummings)
Date: Wed, 02 Apr 2008 00:13:42 -0500
Subject: [XSO] ruby -e 'p "osx".reverse'
Message-ID: <47F31606.3020204@gmail.com>

Teeheehee, I believe you can use class-dump for that, silly!

http://www.codethecode.com/projects/class-dump/

class-dump will give you a complete interface for all the Objective-C 
classes is a binary.

Also check out a decompiler based on class-dump by braden:

http://code-dump.sourceforge.net/

--Dalton

From gammah at gmail.com  Wed Apr  2 01:38:56 2008
From: gammah at gmail.com (Gammah Radiation)
Date: Wed, 2 Apr 2008 00:38:56 -0500
Subject: [XSO] ruby -e 'p "osx".reverse'
In-Reply-To: <a77b1a520804012238t1cbf71cy58cb45a84e0e3384@mail.gmail.com>
References: <47F31606.3020204@gmail.com>
	<a77b1a520804012238t1cbf71cy58cb45a84e0e3384@mail.gmail.com>
Message-ID: <a77b1a520804012238t3fe1138cyf7a18b9542519231@mail.gmail.com>

wait, was that mean?

From gammah at gmail.com  Wed Apr  2 01:38:43 2008
From: gammah at gmail.com (Gammah Radiation)
Date: Wed, 2 Apr 2008 00:38:43 -0500
Subject: [XSO] ruby -e 'p "osx".reverse'
In-Reply-To: <47F31606.3020204@gmail.com>
References: <47F31606.3020204@gmail.com>
Message-ID: <a77b1a520804012238t1cbf71cy58cb45a84e0e3384@mail.gmail.com>

otx > class-dump, "silly"

And if you actually ever attended AHA!, you might know that otool, otx
and classs-dump were all mentioned in a talk that was given there.
While class-dump might give you the .h file, otx will give you the
disassembled, symbolized .s (assembly) files for the objective C
classes.

kthxdonotpassgo.

On Wed, Apr 2, 2008 at 12:13 AM, Dalton Cummings <m4cpunk at gmail.com> wrote:
> Teeheehee, I believe you can use class-dump for that, silly!
>
>  http://www.codethecode.com/projects/class-dump/
>
>  class-dump will give you a complete interface for all the Objective-C
>  classes is a binary.
>
>  Also check out a decompiler based on class-dump by braden:
>
>  http://code-dump.sourceforge.net/
>
>  --Dalton
>
>
> _______________________________________________
>  XSO mailing list
>  XSO at 0x90.org
>  http://0x90.org/mailman/listinfo/xso
>

From m4cpunk at gmail.com  Wed Apr  2 16:26:40 2008
From: m4cpunk at gmail.com (Dalton Cummings)
Date: Wed, 02 Apr 2008 15:26:40 -0500
Subject: [XSO] ruby -e 'p "osx".reverse'
In-Reply-To: <a77b1a520804012238t3fe1138cyf7a18b9542519231@mail.gmail.com>
References: <47F31606.3020204@gmail.com>	<a77b1a520804012238t1cbf71cy58cb45a84e0e3384@mail.gmail.com>
	<a77b1a520804012238t3fe1138cyf7a18b9542519231@mail.gmail.com>
Message-ID: <47F3EC00.60300@gmail.com>

A bit, but it's okay. I was just trying to make a little humor, but it 
obviously missed its mark. ;-)

Gammah Radiation wrote:
> wait, was that mean?
> _______________________________________________
> XSO mailing list
> XSO at 0x90.org
> http://0x90.org/mailman/listinfo/xso
>
>   


From gammah at gmail.com  Wed Apr  2 16:31:36 2008
From: gammah at gmail.com (Gammah Radiation)
Date: Wed, 2 Apr 2008 15:31:36 -0500
Subject: [XSO] ruby -e 'p "osx".reverse'
In-Reply-To: <47F3EC00.60300@gmail.com>
References: <47F31606.3020204@gmail.com>
	<a77b1a520804012238t1cbf71cy58cb45a84e0e3384@mail.gmail.com>
	<a77b1a520804012238t3fe1138cyf7a18b9542519231@mail.gmail.com>
	<47F3EC00.60300@gmail.com>
Message-ID: <a77b1a520804021331y78e8e152h4d6409eaa3c88e2f@mail.gmail.com>

I seem to likewise have missed the mark! Perhaps I should have used
humor-dump instead? ;)))))))))

On Wed, Apr 2, 2008 at 3:26 PM, Dalton Cummings <m4cpunk at gmail.com> wrote:
> A bit, but it's okay. I was just trying to make a little humor, but it
>  obviously missed its mark. ;-)
>
>  Gammah Radiation wrote:
>  > wait, was that mean?
>
>
> > _______________________________________________
>  > XSO mailing list
>  > XSO at 0x90.org
>  > http://0x90.org/mailman/listinfo/xso
>  >
>  >
>
>  _______________________________________________
>  XSO mailing list
>  XSO at 0x90.org
>  http://0x90.org/mailman/listinfo/xso
>

From nummish at 0x90.org  Wed Apr  2 19:50:29 2008
From: nummish at 0x90.org (nummish)
Date: Wed, 2 Apr 2008 18:50:29 -0500
Subject: [XSO] IDA stack delta weirdness
Message-ID: <ad2d22a80804021650u4cbeb34cs35383687ef37552f@mail.gmail.com>

This is more of an IDA question, but before I go to openrce I figured
I'd check here first. I'm working on a variable traceback function. It
is simplistic and doesn't have delusions of grandeur, so when it sees
the stack pointer has changed, it bails. On going back through the
points where it bails (it conveniently adds a marked position until
all 1024 slots are full) I noticed something strange about the spd.

At 0x0016A282, the stack offset is 0x4C and drops to 0x48 after the
call (technically rises, but let's not be pedantic) but then later to
another call to msgSend at 0x0016A294 it doesn't modify the stack
offset. Is this some IDA weirdness that's correctable/preventable?
Does IDA know something about some unnamed class's superview property?
If so, how can I get these same psychic powers?

__text:0016A26A     sub_16A26A      proc near               ; DATA
XREF: __inst_meth:002A753C
__text:0016A26A
__text:0016A26A     msgSend_recipient= dword ptr -48h
__text:0016A26A     msgSend_selector= dword ptr -44h
__text:0016A26A     var_40          = dword ptr -40h
__text:0016A26A     var_3C          = dword ptr -3Ch
__text:0016A26A     var_2C          = dword ptr -2Ch
__text:0016A26A     var_28          = byte ptr -28h
__text:0016A26A     var_1C          = dword ptr -1Ch
__text:0016A26A     var_C           = dword ptr -0Ch
__text:0016A26A     arg_0           = dword ptr  8
__text:0016A26A
__text:0016A26A 000                 push    ebp
__text:0016A26B 004                 mov     ebp, esp
__text:0016A26D 004                 sub     esp, 48h
__text:0016A270 04C                 mov     eax, [ebp+arg_0]
__text:0016A273 04C                 mov     edx, [eax+8]
__text:0016A276 04C                 mov     eax, ds:off_2878C8
__text:0016A27B 04C                 mov     [esp+48h+msgSend_recipient], edx
__text:0016A27E 04C                 mov     [esp+48h+msgSend_selector], eax
__text:0016A282 04C                 call    _objc_msgSend   ; [[eax+8]
superview]
__text:0016A287 048                 mov     edx, ds:off_2878C8
__text:0016A28D 048                 mov     [esp+44h+var_40], edx
__text:0016A291 048                 mov     [esp+44h+msgSend_selector], eax
__text:0016A294 048                 call    _objc_msgSend
__text:0016A299 048                 mov     edx, ds:off_28819C
__text:0016A29F 048                 lea     ecx, [ebp+var_28]
__text:0016A2A2 048                 mov     [esp+44h+msgSend_selector], ecx
__text:0016A2A5 048                 mov     [esp+44h+var_3C], edx
__text:0016A2A9 048                 mov     [esp+44h+var_40], eax
__text:0016A2AD 048                 call    _objc_msgSend_stret
__text:0016A2B2 048                 mov     eax, [ebp+var_1C]
__text:0016A2B5 048                 mov     [ebp+var_C], eax
__text:0016A2B8 048                 movss   xmm0, [ebp+var_C]
__text:0016A2BD 048                 sub     esp, 4
__text:0016A2C0 04C                 subss   xmm0, ds:dword_26CAC0
__text:0016A2C8 04C                 movss   [ebp+var_2C], xmm0
__text:0016A2CD 04C                 fld     [ebp+var_2C]
__text:0016A2D0 04C                 leave
__text:0016A2D1 000                 retn
__text:0016A2D1     sub_16A26A      endp

From shadown at gmail.com  Thu Apr  3 11:23:51 2008
From: shadown at gmail.com (Sergio 'shadown' Alvarez)
Date: Thu, 03 Apr 2008 17:23:51 +0200
Subject: [XSO] IDA stack delta weirdness
In-Reply-To: <ad2d22a80804021650u4cbeb34cs35383687ef37552f@mail.gmail.com>
References: <ad2d22a80804021650u4cbeb34cs35383687ef37552f@mail.gmail.com>
Message-ID: <47F4F687.3030908@gmail.com>

Hi nummish,

I haven't even look at it but, did you check what those two calls do? 
there has to be some stack pointer modification/maths somewhere in them.
IDA use to be pretty good following these things.

I know I'm giving no answer and not being helpful, but if you would like 
to tell me what binary you are looking at, I could check it myself and 
come back to you.

Cheers,
   Sergio

nummish wrote:
> This is more of an IDA question, but before I go to openrce I figured
> I'd check here first. I'm working on a variable traceback function. It
> is simplistic and doesn't have delusions of grandeur, so when it sees
> the stack pointer has changed, it bails. On going back through the
> points where it bails (it conveniently adds a marked position until
> all 1024 slots are full) I noticed something strange about the spd.
> 
> At 0x0016A282, the stack offset is 0x4C and drops to 0x48 after the
> call (technically rises, but let's not be pedantic) but then later to
> another call to msgSend at 0x0016A294 it doesn't modify the stack
> offset. Is this some IDA weirdness that's correctable/preventable?
> Does IDA know something about some unnamed class's superview property?
> If so, how can I get these same psychic powers?
> 
> __text:0016A26A     sub_16A26A      proc near               ; DATA
> XREF: __inst_meth:002A753C
> __text:0016A26A
> __text:0016A26A     msgSend_recipient= dword ptr -48h
> __text:0016A26A     msgSend_selector= dword ptr -44h
> __text:0016A26A     var_40          = dword ptr -40h
> __text:0016A26A     var_3C          = dword ptr -3Ch
> __text:0016A26A     var_2C          = dword ptr -2Ch
> __text:0016A26A     var_28          = byte ptr -28h
> __text:0016A26A     var_1C          = dword ptr -1Ch
> __text:0016A26A     var_C           = dword ptr -0Ch
> __text:0016A26A     arg_0           = dword ptr  8
> __text:0016A26A
> __text:0016A26A 000                 push    ebp
> __text:0016A26B 004                 mov     ebp, esp
> __text:0016A26D 004                 sub     esp, 48h
> __text:0016A270 04C                 mov     eax, [ebp+arg_0]
> __text:0016A273 04C                 mov     edx, [eax+8]
> __text:0016A276 04C                 mov     eax, ds:off_2878C8
> __text:0016A27B 04C                 mov     [esp+48h+msgSend_recipient], edx
> __text:0016A27E 04C                 mov     [esp+48h+msgSend_selector], eax
> __text:0016A282 04C                 call    _objc_msgSend   ; [[eax+8]
> superview]
> __text:0016A287 048                 mov     edx, ds:off_2878C8
> __text:0016A28D 048                 mov     [esp+44h+var_40], edx
> __text:0016A291 048                 mov     [esp+44h+msgSend_selector], eax
> __text:0016A294 048                 call    _objc_msgSend
> __text:0016A299 048                 mov     edx, ds:off_28819C
> __text:0016A29F 048                 lea     ecx, [ebp+var_28]
> __text:0016A2A2 048                 mov     [esp+44h+msgSend_selector], ecx
> __text:0016A2A5 048                 mov     [esp+44h+var_3C], edx
> __text:0016A2A9 048                 mov     [esp+44h+var_40], eax
> __text:0016A2AD 048                 call    _objc_msgSend_stret
> __text:0016A2B2 048                 mov     eax, [ebp+var_1C]
> __text:0016A2B5 048                 mov     [ebp+var_C], eax
> __text:0016A2B8 048                 movss   xmm0, [ebp+var_C]
> __text:0016A2BD 048                 sub     esp, 4
> __text:0016A2C0 04C                 subss   xmm0, ds:dword_26CAC0
> __text:0016A2C8 04C                 movss   [ebp+var_2C], xmm0
> __text:0016A2CD 04C                 fld     [ebp+var_2C]
> __text:0016A2D0 04C                 leave
> __text:0016A2D1 000                 retn
> __text:0016A2D1     sub_16A26A      endp
> _______________________________________________
> XSO mailing list
> XSO at 0x90.org
> http://0x90.org/mailman/listinfo/xso

-- 
Sergio 'shadown' Alvarez
Security Researcher
===============================
email: shadown at gmail.com
gpg  : F140 A2E4 1675 BDB6 9FE4
        F53A 7969 7104 75CD B86E

From shadown at gmail.com  Thu Apr  3 12:18:02 2008
From: shadown at gmail.com (Sergio 'shadown' Alvarez)
Date: Thu, 03 Apr 2008 18:18:02 +0200
Subject: [XSO] IDA stack delta weirdness
In-Reply-To: <47F4F687.3030908@gmail.com>
References: <ad2d22a80804021650u4cbeb34cs35383687ef37552f@mail.gmail.com>
	<47F4F687.3030908@gmail.com>
Message-ID: <47F5033A.60004@gmail.com>

hey I've looked at it, as you said weird. I see you are still looking at 
Mail.app at the method (float)verticalPageScrollDistance of 
WebMessageDisplay, that is the only one that does that from that class 
in IDA, and yes I'm wondering why it got 'confused' did you have the 
chance debug the program to check if IDA is right or not?

Sergio 'shadown' Alvarez wrote:
> Hi nummish,
> 
> I haven't even look at it but, did you check what those two calls do? 
> there has to be some stack pointer modification/maths somewhere in them.
> IDA use to be pretty good following these things.
> 
> I know I'm giving no answer and not being helpful, but if you would like 
> to tell me what binary you are looking at, I could check it myself and 
> come back to you.
> 
> Cheers,
>   Sergio
> 
> nummish wrote:
>> This is more of an IDA question, but before I go to openrce I figured
>> I'd check here first. I'm working on a variable traceback function. It
>> is simplistic and doesn't have delusions of grandeur, so when it sees
>> the stack pointer has changed, it bails. On going back through the
>> points where it bails (it conveniently adds a marked position until
>> all 1024 slots are full) I noticed something strange about the spd.
>>
>> At 0x0016A282, the stack offset is 0x4C and drops to 0x48 after the
>> call (technically rises, but let's not be pedantic) but then later to
>> another call to msgSend at 0x0016A294 it doesn't modify the stack
>> offset. Is this some IDA weirdness that's correctable/preventable?
>> Does IDA know something about some unnamed class's superview property?
>> If so, how can I get these same psychic powers?
>>
>> __text:0016A26A     sub_16A26A      proc near               ; DATA
>> XREF: __inst_meth:002A753C
>> __text:0016A26A
>> __text:0016A26A     msgSend_recipient= dword ptr -48h
>> __text:0016A26A     msgSend_selector= dword ptr -44h
>> __text:0016A26A     var_40          = dword ptr -40h
>> __text:0016A26A     var_3C          = dword ptr -3Ch
>> __text:0016A26A     var_2C          = dword ptr -2Ch
>> __text:0016A26A     var_28          = byte ptr -28h
>> __text:0016A26A     var_1C          = dword ptr -1Ch
>> __text:0016A26A     var_C           = dword ptr -0Ch
>> __text:0016A26A     arg_0           = dword ptr  8
>> __text:0016A26A
>> __text:0016A26A 000                 push    ebp
>> __text:0016A26B 004                 mov     ebp, esp
>> __text:0016A26D 004                 sub     esp, 48h
>> __text:0016A270 04C                 mov     eax, [ebp+arg_0]
>> __text:0016A273 04C                 mov     edx, [eax+8]
>> __text:0016A276 04C                 mov     eax, ds:off_2878C8
>> __text:0016A27B 04C                 mov     
>> [esp+48h+msgSend_recipient], edx
>> __text:0016A27E 04C                 mov     
>> [esp+48h+msgSend_selector], eax
>> __text:0016A282 04C                 call    _objc_msgSend   ; [[eax+8]
>> superview]
>> __text:0016A287 048                 mov     edx, ds:off_2878C8
>> __text:0016A28D 048                 mov     [esp+44h+var_40], edx
>> __text:0016A291 048                 mov     
>> [esp+44h+msgSend_selector], eax
>> __text:0016A294 048                 call    _objc_msgSend
>> __text:0016A299 048                 mov     edx, ds:off_28819C
>> __text:0016A29F 048                 lea     ecx, [ebp+var_28]
>> __text:0016A2A2 048                 mov     
>> [esp+44h+msgSend_selector], ecx
>> __text:0016A2A5 048                 mov     [esp+44h+var_3C], edx
>> __text:0016A2A9 048                 mov     [esp+44h+var_40], eax
>> __text:0016A2AD 048                 call    _objc_msgSend_stret
>> __text:0016A2B2 048                 mov     eax, [ebp+var_1C]
>> __text:0016A2B5 048                 mov     [ebp+var_C], eax
>> __text:0016A2B8 048                 movss   xmm0, [ebp+var_C]
>> __text:0016A2BD 048                 sub     esp, 4
>> __text:0016A2C0 04C                 subss   xmm0, ds:dword_26CAC0
>> __text:0016A2C8 04C                 movss   [ebp+var_2C], xmm0
>> __text:0016A2CD 04C                 fld     [ebp+var_2C]
>> __text:0016A2D0 04C                 leave
>> __text:0016A2D1 000                 retn
>> __text:0016A2D1     sub_16A26A      endp
>> _______________________________________________
>> XSO mailing list
>> XSO at 0x90.org
>> http://0x90.org/mailman/listinfo/xso
> 

-- 
Sergio 'shadown' Alvarez
Security Researcher
===============================
email: shadown at gmail.com
gpg  : F140 A2E4 1675 BDB6 9FE4
        F53A 7969 7104 75CD B86E

From nummish at 0x90.org  Wed Apr  9 14:10:27 2008
From: nummish at 0x90.org (nummish)
Date: Wed, 9 Apr 2008 13:10:27 -0500
Subject: [XSO] Argument naming
Message-ID: <ad2d22a80804091110q13114f4biac9fc89fb74b916b@mail.gmail.com>

I posted something similar to this on openrce, but I figured I'd shout
out to all of you as well.

As you've probably noticed, gcc compiled binaries allocate the stack
space for function call arguments early on, and then mov instead of
push. For a function

function(arg1,arg2)

It is implemented as:

mov [esp+4], arg2
mov [esp], arg1
call function

Even though this is still cdecl, it differs from the push/call most
people are used to. Apparently this is referred to as SUB/MOV method
(thx Ero!) and is default for gcc. When IDA disassembles binaries
using this method, it looks somewhat weird:

mov     [esp+3C218h+var_3C214], arg2
mov     [esp+3C218h+var_3C218], arg1
call    function

I'm sure you've seen this all over the place, as this is how
objc_msgSend() gets it's arguments. My initial reaction to this was to
write a script that would jump to each function that called msgSend to
rename the [esp] variable to recipient and the [esp+4]. I did this by
taking the top two variables in the frame and renaming them. This was
a bad idea. What ended up happening is that in some functions the
stack offset changed part way through the function, causing the names
to be off about half the time.

The solution? OpAlt(). The Edit->Operand type->Manual.../Alt-F1. This
does not propagate like a standard variable renaming does,  it just
changes the one instance of that operand. This will cause a little bit
more work when scripting, but the results are somewhat more accurate.
Renaming the variable in the frame is still ok, but only if you check
that the stack offset for all outgoing calls are the same. This can be
done easily by collecting all the calls to msgSend in the function and
comparing the offsets, then if they differ, a simple backtrace up to
the non-IDA values for the operands.

RegNo = {-1:"R_none",0:"R_ax",1:"R_cx",2:"R_dx",  3:"R_bx",  4:"R_sp",
          5:"R_bp",  6:"R_si",  7:"R_di",  8:"R_r8",  9:"R_r9",  10:"R_r10",
         11:"R_r11",  12:"R_r12",  13:"R_r13",  14:"R_r14",15:"R_r15"}

# Recipient => [esp]
rec_lambda = lambda cursor, opnum: GetOpType(cursor, opnum) == o_phrase and \
        RegNo[get_instruction_operand(cvar.cmd,opnum).reg] == "R_sp"
# Selector => [esp+4]
sel_lambda = lambda cursor, opnum: GetOpType(cursor, opnum) == o_displ and \
        RegNo[get_instruction_operand(cvar.cmd,opnum).reg] == "R_sp" and \
        get_instruction_operand(cvar.cmd,opnum).addr == 4


note: GetSpd() gives you the stack offset. It's not easy to google for
if you didn't know that offhand.

From itsme at xs4all.nl  Thu Apr 10 01:23:53 2008
From: itsme at xs4all.nl (itsme)
Date: Thu, 10 Apr 2008 07:23:53 +0200
Subject: [XSO] Argument naming
In-Reply-To: <ad2d22a80804091110q13114f4biac9fc89fb74b916b@mail.gmail.com>
References: <ad2d22a80804091110q13114f4biac9fc89fb74b916b@mail.gmail.com>
Message-ID: <47FDA469.8040209@xs4all.nl>

nummish wrote:
>
> mov     [esp+3C218h+var_3C214], arg2
> mov     [esp+3C218h+var_3C218], arg1
> call    function
>
> I'm sure you've seen this all over the place, as this is how
this construction is quite common in ARM binaries, what i do there, is
rename
the top stack vars to  arg4, arg5, arg6, etc..  ( with ARM R0..R3 are
always the first 4 parameters )

register argument passing also is used quite often with objective-C code.
hex-rays will discover this automatically.

> What ended up happening is that in some functions the
> stack offset changed part way through the function, causing the names
> to be off about half the time.

a better solution would be to fix the sp-difference ( alt-k )
on the function calls which ida missed that change the ESP value.
usually these are calls to a function ptr ( for instance virtual method
calls )
where the called function ends with 'retn <number>'.


> note: GetSpd() gives you the stack offset. It's not easy to google for
> if you didn't know that offhand.
google?  why not search  path-to-ida\idc\idc.idc  ?

that is where it is documented.

willem



From nummish at 0x90.org  Thu Apr 10 13:14:35 2008
From: nummish at 0x90.org (nummish)
Date: Thu, 10 Apr 2008 12:14:35 -0500
Subject: [XSO] Argument naming
In-Reply-To: <47FDA469.8040209@xs4all.nl>
References: <ad2d22a80804091110q13114f4biac9fc89fb74b916b@mail.gmail.com>
	<47FDA469.8040209@xs4all.nl>
Message-ID: <ad2d22a80804101014s27d3dd9bp20da47fa5cfc5d98@mail.gmail.com>

On Thu, Apr 10, 2008 at 12:23 AM, itsme <itsme at xs4all.nl> wrote:
> nummish wrote:
>  >
>  > mov     [esp+3C218h+var_3C214], arg2
>  > mov     [esp+3C218h+var_3C218], arg1
>  > call    function
>  >
>  > I'm sure you've seen this all over the place, as this is how
>  this construction is quite common in ARM binaries, what i do there, is
>  rename
>  the top stack vars to  arg4, arg5, arg6, etc..  ( with ARM R0..R3 are
>  always the first 4 parameters )
>
>  register argument passing also is used quite often with objective-C code.
>  hex-rays will discover this automatically.

That's cool, I was curious how arm looked, I haven't had a chance to
go over any iphone binaries yet.

>  > What ended up happening is that in some functions the
>  > stack offset changed part way through the function, causing the names
>  > to be off about half the time.
>
>  a better solution would be to fix the sp-difference ( alt-k )
>  on the function calls which ida missed that change the ESP value.
>  usually these are calls to a function ptr ( for instance virtual method
>  calls )
>  where the called function ends with 'retn <number>'.

What about when the stack offset changes legitimately? It happens all
over the place in Mail.app. Having a script flying around and changing
the offset all over the place so variable names match up seems like a
bad idea. In this case, my original code was:

   function_addr = ScreenEA()

   frm = GetFrame(function_addr)
   firstM = GetFirstMember(frm)

   SetMemberName(frm, firstM, "msgSend_recipient")
   SetMemberName(frm, firstM+4, "msgSend_selector")

Which I think is similar to what you were suggesting at the top. This
didn't hold up very well for obj-c only binaries. Also I've been
looking at some carbon apps too, which make my naming choice pretty
poor if it's going to cover the whole function.

>  > note: GetSpd() gives you the stack offset. It's not easy to google for
>  > if you didn't know that offhand.
>  google?  why not search  path-to-ida\idc\idc.idc  ?
>
>  that is where it is documented.

as "delta". if you're thinking "offset" or "difference" and trying to
do a quick search instead of reading the whole file it won't come up.
But that's probably just laziness to actually read the docs on my
part.

From itsme at xs4all.nl  Thu Apr 10 13:32:29 2008
From: itsme at xs4all.nl (itsme)
Date: Thu, 10 Apr 2008 19:32:29 +0200
Subject: [XSO] Argument naming
In-Reply-To: <ad2d22a80804101014s27d3dd9bp20da47fa5cfc5d98@mail.gmail.com>
References: <ad2d22a80804091110q13114f4biac9fc89fb74b916b@mail.gmail.com>	<47FDA469.8040209@xs4all.nl>
	<ad2d22a80804101014s27d3dd9bp20da47fa5cfc5d98@mail.gmail.com>
Message-ID: <47FE4F2D.3030702@xs4all.nl>

nummish wrote:
> What about when the stack offset changes legitimately? It happens all
> over the place in Mail.app. 
can you show some examples of what you mean exactly?

i have Mail.app  from tiger 10.4.11
size:  4101940
md5sum: 80a4ad9b8ed6af6efdbdc884f68c0c98

willem



From nummish at 0x90.org  Thu Apr 10 14:57:06 2008
From: nummish at 0x90.org (nummish)
Date: Thu, 10 Apr 2008 13:57:06 -0500
Subject: [XSO] Argument naming
In-Reply-To: <47FE4F2D.3030702@xs4all.nl>
References: <ad2d22a80804091110q13114f4biac9fc89fb74b916b@mail.gmail.com>
	<47FDA469.8040209@xs4all.nl>
	<ad2d22a80804101014s27d3dd9bp20da47fa5cfc5d98@mail.gmail.com>
	<47FE4F2D.3030702@xs4all.nl>
Message-ID: <ad2d22a80804101157r41d01025rb1dab43d33b9fd41@mail.gmail.com>

On Thu, Apr 10, 2008 at 12:32 PM, itsme <itsme at xs4all.nl> wrote:
> nummish wrote:
>  > What about when the stack offset changes legitimately? It happens all
>  > over the place in Mail.app.
>  can you show some examples of what you mean exactly?
>
>  i have Mail.app  from tiger 10.4.11
>  size:  4101940
>  md5sum: 80a4ad9b8ed6af6efdbdc884f68c0c98

StationaryAnimator.endAnimation for example.

I'm working with Mail.app V3.2 (919/919.2)
MD5 (Mail) = ebd5dd7da7f1853ef3d46fa4a34ddc54

I'll paste part of the IDA dump to save time

__text:001DEB48     endAnimation    proc near               ; DATA
XREF: __inst_meth:002B01B4 o
__text:001DEB48
__text:001DEB48     msgSend_recipient= dword ptr -6Ch
__text:001DEB48     msgSend_selector= dword ptr -68h
__text:001DEB48     var_64          = dword ptr -64h
__text:001DEB48     var_60          = dword ptr -60h

...

__text:001DEB48 000                 push    ebp
__text:001DEB49 004                 mov     ebp, esp
__text:001DEB4B 004                 push    esi
__text:001DEB4C 008                 push    ebx
__text:001DEB4D 00C                 sub     esp, 60h
__text:001DEB50 06C                 mov     esi, [ebp+arg_0]
__text:001DEB53 06C                 mov     eax, ds:off_28769C
__text:001DEB58 06C                 mov     edx, [esi+0Ch]
__text:001DEB5B 06C                 mov     [esp+68h+var_64], eax
__text:001DEB5F 06C                 mov
[esp+68h+msgSend_selector], edx ; Note that this is [esp]
__text:001DEB62 06C                 call    _objc_msgSend   ; a =
[[esi+0Ch] window]
__text:001DEB67 06C                 mov     edx, [esi+10h]

...

__text:001DEC57 06C                 mov     eax, [ebp+var_34]
__text:001DEC5A 06C                 sub     esp, 4
__text:001DEC5D 070                 mov     [ebp+var_24], eax
__text:001DEC60 070                 mov     eax, [ebp+var_30]
__text:001DEC63 070                 mov     [ebp+var_20], eax
__text:001DEC66 070                 mov     eax, [ebp+var_2C]
__text:001DEC69 070                 movss   xmm0, [ebp+var_20]
__text:001DEC6E 070                 mov     [ebp+var_1C], eax
__text:001DEC71 070                 mov     eax, ds:off_28819C
__text:001DEC76 070                 movss   [ebp+var_3C], xmm0
__text:001DEC7B 070                 mov     edx, [esi+0Ch]
__text:001DEC7E 070                 mov     [esp+6Ch+msgSend_recipient], ebx
__text:001DEC81 070                 mov     [esp+8], eax
__text:001DEC85 070                 mov     [esp+6Ch+msgSend_selector], edx
__text:001DEC89 070                 call    _objc_msgSend_stret


.. I wonder if it's because this is a stret call, or if it's just a
bad example. I'll take a look for a better example later tonight.

From itsme at xs4all.nl  Thu Apr 10 16:02:48 2008
From: itsme at xs4all.nl (itsme)
Date: Thu, 10 Apr 2008 22:02:48 +0200
Subject: [XSO] Argument naming
In-Reply-To: <ad2d22a80804101157r41d01025rb1dab43d33b9fd41@mail.gmail.com>
References: <ad2d22a80804091110q13114f4biac9fc89fb74b916b@mail.gmail.com>	<47FDA469.8040209@xs4all.nl>	<ad2d22a80804101014s27d3dd9bp20da47fa5cfc5d98@mail.gmail.com>	<47FE4F2D.3030702@xs4all.nl>
	<ad2d22a80804101157r41d01025rb1dab43d33b9fd41@mail.gmail.com>
Message-ID: <47FE7268.9050809@xs4all.nl>

nummish wrote:
> .. I wonder if it's because this is a stret call, or if it's just a
> bad example. I'll take a look for a better example later tonight.
>   

yes, _objc_msgSend_stret  is an assembler function from the objective-C
runtime
source code can be found here: http://www.opensource.apple.com/darwinsource/
 look for 'objc4-XXX.tar.gz

that is a bit strange function, you can't really declare something like
that in C.

looking at the assembler source, it ends with 'retn 4',  and takes a
variable nr of arguments.

and ida incorrectly assumes it is a C style '__stdcall' type function
with 3 parameters
if you type ALT-K  on a line with 'call _objc_msgSend_stret'
it says '0xC'

you can fix this by going to the _objc_msgSend_stret function, and changing
'purged bytes' in alt-P  from 0xC to 0x4

then the stack will look fine everywhere.

_objc_msgForward  has the same issue.

willem



From nummish at 0x90.org  Thu Apr 10 17:25:27 2008
From: nummish at 0x90.org (nummish)
Date: Thu, 10 Apr 2008 16:25:27 -0500
Subject: [XSO] Argument naming
In-Reply-To: <47FE7268.9050809@xs4all.nl>
References: <ad2d22a80804091110q13114f4biac9fc89fb74b916b@mail.gmail.com>
	<47FDA469.8040209@xs4all.nl>
	<ad2d22a80804101014s27d3dd9bp20da47fa5cfc5d98@mail.gmail.com>
	<47FE4F2D.3030702@xs4all.nl>
	<ad2d22a80804101157r41d01025rb1dab43d33b9fd41@mail.gmail.com>
	<47FE7268.9050809@xs4all.nl>
Message-ID: <ad2d22a80804101425t79bf54efn6bd9ba47f59614ca@mail.gmail.com>

On Thu, Apr 10, 2008 at 3:02 PM, itsme <itsme at xs4all.nl> wrote:
> nummish wrote:
>  > .. I wonder if it's because this is a stret call, or if it's just a
>  > bad example. I'll take a look for a better example later tonight.
>  >
>
>  yes, _objc_msgSend_stret  is an assembler function from the objective-C
>  runtime
>  source code can be found here: http://www.opensource.apple.com/darwinsource/
>   look for 'objc4-XXX.tar.gz
>
>  that is a bit strange function, you can't really declare something like
>  that in C.
>
>  looking at the assembler source, it ends with 'retn 4',  and takes a
>  variable nr of arguments.
>
Ok, I'm not crazy.. here's a function that uses only standard msgSend
and no advanced ones that have different return types

ToDoBackgroundView.setToDo:

__text:000B4ADF     setToDo_        proc near               ; DATA
XREF: __inst_meth:002AE568o
__text:000B4ADF
__text:000B4ADF     msgSend_recipient= dword ptr -48h
__text:000B4ADF     msgSend_selector= dword ptr -44h
__text:000B4ADF     var_40          = dword ptr -40h
...
__text:000B4ADF     arg_0           = dword ptr  8
__text:000B4ADF     arg_4           = dword ptr  0Ch
__text:000B4ADF     arg_8           = dword ptr  10h
...
__text:000B4ADF 000                 push    ebp
__text:000B4AE0 004                 mov     ebp, esp
__text:000B4AE2 004                 push    edi
__text:000B4AE3 008                 push    esi
__text:000B4AE4 00C                 push    ebx
__text:000B4AE5 010                 sub     esp, 3Ch
__text:000B4AE8 04C                 mov     edi, [ebp+arg_0]
__text:000B4AEB 04C                 mov     eax, [ebp+arg_8]
__text:000B4AEE 04C                 mov     [ebp+var_1C], eax
...
__text:000B4BDE 04C                 mov     [esp+48h+msgSend_recipient], eax
__text:000B4BE1 04C                 call    _objc_msgSend
__text:000B4BE6 048                 mov     [esp+44h+var_3C], eax
__text:000B4BEA 048                 mov     eax, ds:off_28CF4C
__text:000B4BEF 048                 mov     [esp+44h+msgSend_selector], ebx
__text:000B4BF2 048                 mov     [esp+44h+var_40], eax
__text:000B4BF6 048                 call    _objc_msgSend
__text:000B4BFB 048                 mov     eax, ds:off_28DB68
__text:000B4C00 048                 mov     ebx, [edi+0B8h]
__text:000B4C06 048                 mov     [esp+44h+var_40], eax ; [ESP+4]
__text:000B4C0A 048                 mov     eax, [ebp+var_1C]
__text:000B4C0D 048                 mov
[esp+44h+msgSend_selector], eax ; [ESP]
__text:000B4C10 048                 call    _objc_msgSend   ; a =
[[ebp+var_1C] priorityEnabled]
...
__text:000B4CE6 048                 mov     [ebp+arg_8], eax; should be an int
__text:000B4CE9 048                 mov     eax, ds:off_289854;
selectItemAtIndex:
__text:000B4CEE 048                 mov     [ebp+arg_0], ebx
__text:000B4CF1 048                 mov     [ebp+arg_4], eax
__text:000B4CF4 048                 add     esp, 3Ch
__text:000B4CF7 00C                 pop     ebx
__text:000B4CF8 008                 pop     esi
__text:000B4CF9 004                 pop     edi
__text:000B4CFA 000                 leave
__text:000B4CFB 000                 jmp     _objc_msgSend
__text:000B4CFB     setToDo_        endp

There's a few interesting notes about this now that I'm looking at it
though. The SP has already zeroed by the time it hits the leave call,
which should be popping from the stack. I guess I'm back to my
question from the other day about how this can happen or at least be
detected automatically.

The other interesting part is the jmp to the last msgSend which will
return to the caller of this function. I've seen this some, my guess
is that it's indicating something along the lines of

return [ebx selectItemAtIndex:x];

From nemo at felinemenace.org  Thu Apr 10 17:30:57 2008
From: nemo at felinemenace.org (nemo)
Date: Thu, 10 Apr 2008 21:30:57 +0000
Subject: [XSO] Argument naming
In-Reply-To: <ad2d22a80804101425t79bf54efn6bd9ba47f59614ca@mail.gmail.com>
References: <ad2d22a80804091110q13114f4biac9fc89fb74b916b@mail.gmail.com>
	<47FDA469.8040209@xs4all.nl>
	<ad2d22a80804101014s27d3dd9bp20da47fa5cfc5d98@mail.gmail.com>
	<47FE4F2D.3030702@xs4all.nl>
	<ad2d22a80804101157r41d01025rb1dab43d33b9fd41@mail.gmail.com>
	<47FE7268.9050809@xs4all.nl>
	<ad2d22a80804101425t79bf54efn6bd9ba47f59614ca@mail.gmail.com>
Message-ID: <20080410213057.GK30730@felinemenace.org>

Just out of interest, why are you reversing Mail.app anyway, it's just a
thin wrapper around a bunch of open source libraries. 

Seems like there's plenty of bugs in libraries used by Mail.app that are
easy to find / exploit without any reverse engineering.

Just a thought ;O

On Thu, Apr 10, 2008 at 04:25:27PM -0500, nummish wrote:
> On Thu, Apr 10, 2008 at 3:02 PM, itsme <itsme at xs4all.nl> wrote:
> > nummish wrote:
> >  > .. I wonder if it's because this is a stret call, or if it's just a
> >  > bad example. I'll take a look for a better example later tonight.
> >  >
> >
> >  yes, _objc_msgSend_stret  is an assembler function from the objective-C
> >  runtime
> >  source code can be found here: http://www.opensource.apple.com/darwinsource/
> >   look for 'objc4-XXX.tar.gz
> >
> >  that is a bit strange function, you can't really declare something like
> >  that in C.
> >
> >  looking at the assembler source, it ends with 'retn 4',  and takes a
> >  variable nr of arguments.
> >
> Ok, I'm not crazy.. here's a function that uses only standard msgSend
> and no advanced ones that have different return types
> 
> ToDoBackgroundView.setToDo:
> 
> __text:000B4ADF     setToDo_        proc near               ; DATA
> XREF: __inst_meth:002AE568o
> __text:000B4ADF
> __text:000B4ADF     msgSend_recipient= dword ptr -48h
> __text:000B4ADF     msgSend_selector= dword ptr -44h
> __text:000B4ADF     var_40          = dword ptr -40h
> ...
> __text:000B4ADF     arg_0           = dword ptr  8
> __text:000B4ADF     arg_4           = dword ptr  0Ch
> __text:000B4ADF     arg_8           = dword ptr  10h
> ...
> __text:000B4ADF 000                 push    ebp
> __text:000B4AE0 004                 mov     ebp, esp
> __text:000B4AE2 004                 push    edi
> __text:000B4AE3 008                 push    esi
> __text:000B4AE4 00C                 push    ebx
> __text:000B4AE5 010                 sub     esp, 3Ch
> __text:000B4AE8 04C                 mov     edi, [ebp+arg_0]
> __text:000B4AEB 04C                 mov     eax, [ebp+arg_8]
> __text:000B4AEE 04C                 mov     [ebp+var_1C], eax
> ...
> __text:000B4BDE 04C                 mov     [esp+48h+msgSend_recipient], eax
> __text:000B4BE1 04C                 call    _objc_msgSend
> __text:000B4BE6 048                 mov     [esp+44h+var_3C], eax
> __text:000B4BEA 048                 mov     eax, ds:off_28CF4C
> __text:000B4BEF 048                 mov     [esp+44h+msgSend_selector], ebx
> __text:000B4BF2 048                 mov     [esp+44h+var_40], eax
> __text:000B4BF6 048                 call    _objc_msgSend
> __text:000B4BFB 048                 mov     eax, ds:off_28DB68
> __text:000B4C00 048                 mov     ebx, [edi+0B8h]
> __text:000B4C06 048                 mov     [esp+44h+var_40], eax ; [ESP+4]
> __text:000B4C0A 048                 mov     eax, [ebp+var_1C]
> __text:000B4C0D 048                 mov
> [esp+44h+msgSend_selector], eax ; [ESP]
> __text:000B4C10 048                 call    _objc_msgSend   ; a =
> [[ebp+var_1C] priorityEnabled]
> ...
> __text:000B4CE6 048                 mov     [ebp+arg_8], eax; should be an int
> __text:000B4CE9 048                 mov     eax, ds:off_289854;
> selectItemAtIndex:
> __text:000B4CEE 048                 mov     [ebp+arg_0], ebx
> __text:000B4CF1 048                 mov     [ebp+arg_4], eax
> __text:000B4CF4 048                 add     esp, 3Ch
> __text:000B4CF7 00C                 pop     ebx
> __text:000B4CF8 008                 pop     esi
> __text:000B4CF9 004                 pop     edi
> __text:000B4CFA 000                 leave
> __text:000B4CFB 000                 jmp     _objc_msgSend
> __text:000B4CFB     setToDo_        endp
> 
> There's a few interesting notes about this now that I'm looking at it
> though. The SP has already zeroed by the time it hits the leave call,
> which should be popping from the stack. I guess I'm back to my
> question from the other day about how this can happen or at least be
> detected automatically.
> 
> The other interesting part is the jmp to the last msgSend which will
> return to the caller of this function. I've seen this some, my guess
> is that it's indicating something along the lines of
> 
> return [ebx selectItemAtIndex:x];
> _______________________________________________
> XSO mailing list
> XSO at 0x90.org
> http://0x90.org/mailman/listinfo/xso

From itsme at xs4all.nl  Fri Apr 11 09:30:09 2008
From: itsme at xs4all.nl (itsme)
Date: Fri, 11 Apr 2008 15:30:09 +0200
Subject: [XSO] Argument naming
In-Reply-To: <20080410213057.GK30730@felinemenace.org>
References: <ad2d22a80804091110q13114f4biac9fc89fb74b916b@mail.gmail.com>	<47FDA469.8040209@xs4all.nl>	<ad2d22a80804101014s27d3dd9bp20da47fa5cfc5d98@mail.gmail.com>	<47FE4F2D.3030702@xs4all.nl>	<ad2d22a80804101157r41d01025rb1dab43d33b9fd41@mail.gmail.com>	<47FE7268.9050809@xs4all.nl>	<ad2d22a80804101425t79bf54efn6bd9ba47f59614ca@mail.gmail.com>
	<20080410213057.GK30730@felinemenace.org>
Message-ID: <47FF67E1.5010206@xs4all.nl>

nemo wrote:
> Just out of interest, why are you reversing Mail.app anyway, it's just a
> thin wrapper around a bunch of open source libraries. 
>
>   

the method of reverse engineering is the research object here, not the
specific application.

willem



From itsme at xs4all.nl  Fri Apr 11 12:05:59 2008
From: itsme at xs4all.nl (itsme)
Date: Fri, 11 Apr 2008 18:05:59 +0200
Subject: [XSO] Argument naming
In-Reply-To: <ad2d22a80804101425t79bf54efn6bd9ba47f59614ca@mail.gmail.com>
References: <ad2d22a80804091110q13114f4biac9fc89fb74b916b@mail.gmail.com>	<47FDA469.8040209@xs4all.nl>	<ad2d22a80804101014s27d3dd9bp20da47fa5cfc5d98@mail.gmail.com>	<47FE4F2D.3030702@xs4all.nl>	<ad2d22a80804101157r41d01025rb1dab43d33b9fd41@mail.gmail.com>	<47FE7268.9050809@xs4all.nl>
	<ad2d22a80804101425t79bf54efn6bd9ba47f59614ca@mail.gmail.com>
Message-ID: <47FF8C67.2060403@xs4all.nl>

nummish wrote:
> __text:000B4BDE 04C                 mov     [esp+48h+msgSend_recipient], eax
> __text:000B4BE1 04C                 call    _objc_msgSend
> __text:000B4BE6 048                 mov     [esp+44h+var_3C], eax
>
>   
after i change the function type ( type 'y' when vieing the msgsend
function ) of _objc_msgSend
from "int obj_msgSend()" to "int objc_msgSend(int, int, ...)"

this changes into: ( wait for ida to finish processing the changed type )

__text:000B4BDE                 mov     [esp+48h+var_48], eax
__text:000B4BE1                 call    _objc_msgSend
__text:000B4BE6                 mov     [esp+48h+var_40], eax

willem