Log in

View Full Version : Stacks in Olly and IDA

WaxfordSqueers
November 19th, 2012, 06:13
Have a problem with stack offsets in Olly and IDA. The problem began when IDA2ICE complained that certain functions had very large stack offsets. One of them is listed as [ebp-0FA0Ch], which seems really wild. The same address in Olly is listed as MOV [LOCAL.16003], 0

Here's the code snippet from that section of code:

Code:




87F190 55                                        push    ebp

87F191 8B EC                                    mov     ebp, esp

87F193 B8 0C FA 00 00                        mov     eax, 0FA0Ch

87F198 E8 23 F4 2A 00                        call    sub_B2E5C0

87F19D A1 84 6B F8 00                        mov     eax, lParam

87F1A2 33 C5                                     xor     eax, ebp

87F1A4 89 45 FC                                 mov     [ebp-4], eax

87F1A7 C7 85 F4 05 FF FF 00 00 00 00    mov     dword ptr [ebp-0FA0Ch], 0

87F1B1 C6 45 F7 00                             mov     byte ptr [ebp-9], 0

87F1B5 8B 45 10                                 mov     eax, [ebp+10h]


One of the problems is this line here:

87F1A7 C7 85 F4 05 FF FF 00 00 00 00 mov dword ptr [ebp-0FA0Ch], 0

How can a a base pointer have an offset of -0x0FAC?? And in Olly, is it normal to have the same offset at LOCAL.16003? In fact, what the hey does LOCAL.16003 mean?

Can anyone interpret the machine code to see if that seems correct?
ZaiRoN
November 20th, 2012, 04:43
"LOCAL.16003" is a name created by Olly. Use "remove analysis from module" and you'll see the right value in Olly too
WaxfordSqueers
November 20th, 2012, 07:43
Quote:
[Originally Posted by ZaiRoN;93742]"LOCAL.16003" is a name created by Olly. Use "remove analysis from module" and you'll see the right value in Olly too


Thanks for tip, ZaiRoN. It now shows up in Olly as MOV [DWORD PTR SS:[EBP+FFFF05F4], 0

The FFFF05F4 negates to FA0B which is close to the offset IDA claims. It just seems like a large offset for a stack segment but I guess IDA2ICE didn't like it too much, referring to it as an inconvenient overhead.

I wonder if there's a way to get IDA to list the offset in the brackets rather than listing them as args before the function. I'll have to check.
blabberer
November 22nd, 2012, 02:26
Quote:
ZaiRoN
"LOCAL.16003" is a name created by Olly. Use "remove analysis from module" and you'll see the right value in Olly too

no need to nuke a fly with an ICBM
options->debugging options-> (alt+o) ->Analysis 1 & (check-mark / remove check-mark ) show Args and Locals in procedures

@waxford
anything below ebp viz ebp -1 to ebp - as much stack as available == LOCALS
anything above ebp viz ebp+1 to ebp + as much parameters as allowed for a function == ARGS

in c if you do
int blah (foo ,faa, fee) {
int moo;
int goo;

.....
}

foo faa fee are args
moo and goo are locals

foo faa fee accessed in assembly would have
mov / lea / whatever do something would be [ebp+0xXXX]

moo / goo / whatever do anything might resemble [ebp-0xXXXX]

if ebp is not used (Frame Pointer Omission) it would be stack based ie esp +0xXXXX or register based

i cant comment on ida2kayaker

but - fa0c can be a valid stack pointer


compile the code below and see the output

Code:




C:\DOCUME~1\Admin\Desktop\FA0CWAX>dir /b

fa0cwax.cpp



C:\DOCUME~1\Admin\Desktop\FA0CWAX>cl fa0cwax.cpp



C:\DOCUME~1\Admin\Desktop\FA0CWAX>dir /b

fa0cwax.cpp

fa0cwax.exe

fa0cwax.obj



C:\DOCUME~1\Admin\Desktop\FA0CWAX>fa0cwax.exe

struct blah.foo3 contains c



C:\DOCUME~1\Admin\Desktop\FA0CWAX>type fa0cwax.cpp

#include <windows.h>

#include <stdio.h>

typedef struct _MYSTRUCT

{

        char foo07;

        char foo06;

        char foo05;

        char foo04;

        char foo03;

        char foo02;

        char foo01;

        char crapbuff[0xfa00];

} mystruct, *pmystruct;

int main(void)

{

        mystruct blah;

        memset(&blah,0,sizeof(blah));

        memset(&blah.foo03,'c',1);

        printf("struct blah.foo3 contains %c\n",blah.foo03);

        return 0;

}



C:\DOCUME~1\Admin\Desktop\FA0CWAX>cdb -c "uf 401000;q" fa0cwax.exe | grep -i fa0

c

CommandLine: fa0cwax.exe

00401031 8d8df405ffff    lea     ecx,[ebp-0FA0Ch]

00401040 0fbe95f405ffff  movsx   edx,byte ptr [ebp-0FA0Ch]



C:\DOCUME~1\Admin\Desktop\FA0CWAX>


btw FFFF05F4 is not fa0b but fa0c just signed and unsigned representation

Code:




:\>set /a 0xffff05f4 & echo.& set /a 0xfa0c

-64012

64012

:\>
WaxfordSqueers
November 22nd, 2012, 18:11
Quote:
[Originally Posted by blabberer;93757]
i cant comment on ida2kayaker

but - fa0c can be a valid stack pointer


It seems in your code you defined crapbuf at 0x0f00. I was talking about a local stack pointer referencing a value at an offset of 0xfA0. It doesn't really matter but the author of IDA2ICE was aware of the issue, and presumably he thought it was an issue with IDA and could be fixed. However, Olly saw it the same way. Mind you, that was from an initial disassembly right after the app was loaded, not while the code was being traced.

When you look at the IDA args/locals listing before the function there are many such offsets and that's why it was complaining.

The app I am working on has serious issues based on past incarnations of the code. I say that because Win 7 reports it as having memory leaks and it tends to hog the focus when working on an intensive process like a sort. I am wondering if the offset problem is caused by poor programming.

Do you know of a way to turn off the args/labels list in IDA? I find it annoying.