bufferoverflow ????

[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.

[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:

Code: Select all

mov esp,ebp
pop ebp

[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 ?

[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.

[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.

[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.

[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

Code: Select all

.text:77E30D34 000                 retn    8

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.

[Gigasoft]

Strings are stored in forward order. The lowest address contains the first character.