Page 2 of 2
Re: bufferoverflow ????
Posted: Fri Jun 11, 2010 11:05 pm
by Sam111
Code: Select all
08048481 <bufferoverflow>:
8048481: 55 push ebp
8048482: 89 e5 mov ebp,esp
8048484: 83 ec 38 sub esp,0x38
8048487: 8b 45 08 mov eax,DWORD PTR [ebp+0x8]
804848a: 89 44 24 04 mov DWORD PTR [esp+0x4],eax
804848e: 8d 45 e4 lea eax,[ebp-0x1c]
8048491: 89 04 24 mov DWORD PTR [esp],eax
8048494: e8 db fe ff ff call 8048374 <strcpy@plt>
8048499: c9 leave
804849a: c3 ret
Ok, I get what your saying
for some alignment reason or something it does sub esp,0x38
the next 4 statements after that basically put the pointer char * str into esp+0x4 and the address of [ebp-0x1c] (which should point to the buffer[20]) into [esp] then it calls <strcpy@plt>.
What I am confused about is I see no statement that actually puts the values of the buffer[20] on the stack?
They only call the strcpy@plt with [esp] pointing to the random address put on by
Code: Select all
804848e: 8d 45 e4 lea eax,[ebp-0x1c]
and [esp + 4] pointing to the address of char * str.
So I am wondering what is putting these buffer[20] characters on the stack?
Also is leave necessary what is this doing... I see it right before alot of function ret statements curious.
Re: bufferoverflow ????
Posted: Sat Jun 12, 2010 6:22 am
by Gigasoft
It doesn't put anything in the buffer, because you haven't told it to. What it contains before calling strcpy is irrelevant, since strcpy will fill it.
The leave instruction does the same as:
Re: bufferoverflow ????
Posted: Sat Jun 12, 2010 11:39 am
by Sam111
Gotcha,
except when it calls the strcpy@plt I cann't follow where it is loading the buffer[20] chars...
Code: Select all
Disassembly of section .plt:
08048334 <__gmon_start__@plt-0x10>:
8048334: ff 35 f8 9f 04 08 push DWORD PTR ds:0x8049ff8
804833a: ff 25 fc 9f 04 08 jmp DWORD PTR ds:0x8049ffc
8048340: 00 00 add BYTE PTR [eax],al
...
08048344 <__gmon_start__@plt>:
8048344: ff 25 00 a0 04 08 jmp DWORD PTR ds:0x804a000
804834a: 68 00 00 00 00 push 0x0
804834f: e9 e0 ff ff ff jmp 8048334 <_init+0x30>
08048354 <write@plt>:
8048354: ff 25 04 a0 04 08 jmp DWORD PTR ds:0x804a004
804835a: 68 08 00 00 00 push 0x8
804835f: e9 d0 ff ff ff jmp 8048334 <_init+0x30>
08048364 <__libc_start_main@plt>:
8048364: ff 25 08 a0 04 08 jmp DWORD PTR ds:0x804a008
804836a: 68 10 00 00 00 push 0x10
804836f: e9 c0 ff ff ff jmp 8048334 <_init+0x30>
08048374 <strcpy@plt>:
8048374: ff 25 0c a0 04 08 jmp DWORD PTR ds:0x804a00c
804837a: 68 18 00 00 00 push 0x18
804837f: e9 b0 ff ff ff jmp 8048334 <_init+0x30>
08048384 <printf@plt>:
8048384: ff 25 10 a0 04 08 jmp DWORD PTR ds:0x804a010
804838a: 68 20 00 00 00 push 0x20
804838f: e9 a0 ff ff ff jmp 8048334 <_init+0x30>
This plt section is kind of werid I was expecting a loop thur the buffer chars moveing them into the stack space...
But I don't really see it. It looks like it is just jumping to a pointer to the buffer char's then pushing some random number like 0x18 or 0x20 ,...etc then doing another jump to _init+0x30 which is the function <__gmon_start__@plt-0x10>.
<__gmon_start__@plt-0x10> I see no moving on the stack here either ?
Re: bufferoverflow ????
Posted: Sat Jun 12, 2010 1:02 pm
by Gigasoft
There's no such thing as "jumping then doing ...". It's jumping to the address stored at 0x804a00c, which points to the strcpy function in the C library (the operating system fills in this address so that it points to the correct function). What you are looking at is a set of stub functions whose only function is to redirect execution to a system library.
Why do you think strcpy should load any characters from the destination buffer? It loads the characters from the source and copies them to the destination, that's what it does.
Re: bufferoverflow ????
Posted: Sat Jun 12, 2010 1:47 pm
by Sam111
well once the call strcpy@plt is executed it jumps here
Code: Select all
08048374 <strcpy@plt>:
8048374: ff 25 0c a0 04 08 jmp DWORD PTR ds:0x804a00c
804837a: 68 18 00 00 00 push 0x18
804837f: e9 b0 ff ff ff jmp 8048334 <_init+0x30>
Ok , I see your point the first jmp statement jumps to the address stored at ds:0x804a00c which the os puts the exact location of the strcpy function ..etc
But then what is the point of all the other crap like push 0x18 , jmp 8048334 <_init+0x30> ,...etc.
Why doesn't it just return to the bufferoverflow function once strcpy function is done what is the point of this extra stuff in strcpy@plt?
Why do you think strcpy should load any characters from the destination buffer? It loads the characters from the source and copies them to the destination, that's what it does.
Yes,
well I was just curious when strcpy moves the 20 chars ,...etc onto the part of the stack that buffer[20] was reserved for in the bufferoverflow function code.
But apparently I was thinking that strcpy@plt was the strcpy function which was confusing me for the first time ...
Now I know it is just a stub and I would have to disassembly the strcpy function in the lib to see the actual moving of the source char * str into the destination buffer[20] on the stack...etc.
Re: bufferoverflow ????
Posted: Sat Jun 12, 2010 2:04 pm
by Gigasoft
The code, of course, never reaches 0x804837a. The strcpy function returns straight to the caller. The code at 0x804837a has to do with delayed loading. It's purpose is to jump to a function in the system which causes the library containing strcpy to be loaded, and replaces the instruction at the beginning of the stub with a jump to the real strcpy. When using delayed loading, the instruction at the beginning is something else initially, probably just nops.
Strcpy functions can be confusing to understand, depending on how they are implemented (they often use tricks to get them up to speed). Here is a disassembly of lstrcpyA from Windows, which is a very simple implementation of strcpy.
Code: Select all
.text:77E30D05 ; LPSTR __stdcall lstrcpyA(LPSTR lpString1, LPCSTR lpString2)
.text:77E30D05 public lstrcpyA
.text:77E30D05 lstrcpyA proc near
.text:77E30D05
.text:77E30D05 ms_exc = CPPEH_RECORD ptr -18h
.text:77E30D05 arg_0 = dword ptr 8
.text:77E30D05 arg_4 = dword ptr 0Ch
.text:77E30D05
.text:77E30D05 000 push 8 ; lstrcpy
.text:77E30D07 004 push offset dword_77E30D38
.text:77E30D0C 008 call __SEH_prolog4
.text:77E30D11 02C and [ebp+ms_exc.disabled], 0
.text:77E30D15 02C mov ecx, [ebp+arg_4]
.text:77E30D18 02C mov edx, [ebp+arg_0]
.text:77E30D1B
.text:77E30D1B loc_77E30D1B: ; CODE XREF: lstrcpyA+1Ej
.text:77E30D1B 02C mov al, [ecx]
.text:77E30D1D 02C mov [edx], al
.text:77E30D1F 02C inc ecx
.text:77E30D20 02C inc edx
.text:77E30D21 02C test al, al
.text:77E30D23 02C jnz short loc_77E30D1B
.text:77E30D25 02C mov [ebp+ms_exc.disabled], 0FFFFFFFEh
.text:77E30D2C 02C mov eax, [ebp+arg_0]
.text:77E30D2F
.text:77E30D2F loc_77E30D2F: ; CODE XREF: .text:77E5E11Aj
.text:77E30D2F 02C call __SEH_epilog4
.text:77E30D34 000 retn 8
.text:77E30D34 lstrcpyA endp
The __SEH_prolog4 and __SEH_epilog4 functions deal with exception handling and with setting up a stack frame, but other than that there's no mystery.
Re: bufferoverflow ????
Posted: Sat Jun 12, 2010 2:52 pm
by Sam111
Ah , their it is
Code: Select all
text:77E30D15 02C mov ecx, [ebp+arg_4]
.text:77E30D18 02C mov edx, [ebp+arg_0]
.text:77E30D1B
.text:77E30D1B loc_77E30D1B: ; CODE XREF: lstrcpyA+1Ej
.text:77E30D1B 02C mov al, [ecx]
.text:77E30D1D 02C mov [edx], al
.text:77E30D1F 02C inc ecx
.text:77E30D20 02C inc edx
.text:77E30D21 02C test al, al
.text:77E30D23 02C jnz short loc_77E30D1B
The other stuff
Code: Select all
.text:77E30D05 000 push 8 ; lstrcpy
.text:77E30D07 004 push offset dword_77E30D38
.text:77E30D0C 008 call __SEH_prolog4
.text:77E30D11 02C and [ebp+ms_exc.disabled], 0
and this part
Code: Select all
.text:77E30D25 02C mov [ebp+ms_exc.disabled], 0FFFFFFFEh
.text:77E30D2C 02C mov eax, [ebp+arg_0]
.text:77E30D2F
.text:77E30D2F loc_77E30D2F: ; CODE XREF: .text:77E5E11Aj
.text:77E30D2F 02C call __SEH_epilog4
are alittle shade but as you said it is just for the exception handling etc...stuff.
And because it is a stdcall the called function must clean the 2 parameters off the stack so we have this
instead of just ret. (like the cdecl convention where the caller is responsible for cleaning the stack )
So I am assuming if I where to do the samething as you did I would see this loop in strcpy libc,...etc
Curious when it moves the characters for buffer[20] on the stack does it place it like this
H
e
l
l
o
or
o
l
l
e
H
basically is the characters for buffer[20] put on the stack little endian (like return address , and function parameter are ) or big endian? "just curious if everything on the stack follows little endian at least on my x86 machines"
Going by your code it seems like it would be the second olleH string.
Awesome ...
Gigasoft you know your ****.
Thanks for all your help.
Re: bufferoverflow ????
Posted: Sat Jun 12, 2010 6:27 pm
by Gigasoft
Strings are stored in forward order. The lowest address contains the first character.