Log in

View Full Version : Help with dissasembly

n00b
June 3rd, 2009, 08:01
Hi guys i do allot of exploit development and found a nice heap overflow triggered in an application when adding FFFFFFF to the header of a file.

I put it in ida pro and got some disassembly of the vulnerable function i was wondering if any one could explain in better detail what was happing just before the exception is triggered.

I have provided disassembly of the memcpy() function below.If any one could help it would be greatly appreciated thank you for your time.


Code:




0044E9B1 sub_44E940



.text:0044E9A1

.text:0044E9A1 loc_44E9A1:

.text:0044E9A1 mov     eax, [ebx+4]

.text:0044E9A4 mov     ecx, [esp+0Ch+Count]

.text:0044E9A8 mov     edx, [esp+0Ch+DstBuf]

.text:0044E9AC push    eax             ; File

.text:0044E9AD push    ecx             ; Count

.text:0044E9AE push    1               ; ElementSize

.text:0044E9B0 push    edx             ; Dst



===============================================================================

0053C3B7 int __cdecl sub_53C39F(void *DstBuf, size_t ElementSize, size_t Count,

FILE *File)

push    ebp

.text:0053C3A0 mov     ebp, esp

.text:0053C3A2 push    esi

.text:0053C3A3 push    [ebp+File]

.text:0053C3A6 call    __lock_file

.text:0053C3AB push    [ebp+File]      ; File

.text:0053C3AE push    [ebp+Count]     ; Count

.text:0053C3B1 push    [ebp+ElementSize] ; ElementSize

.text:0053C3B4 push    [ebp+DstBuf]    ; DstBuf

.text:0053C3B7 call    _fread

================================================================================

0053C42C size_t __cdecl fread(void *DstBuf, size_t ElementSize, size_t Count,

FILE *File)



.text:0053C428

.text:0053C428 loc_53C428:             ; Size

.text:0053C428 push    edi

.text:0053C429 push    dword ptr [esi] ; Src

.text:0053C42B push    ebx             ; Dst

.text:0053C42C call    _memcpy_0



00540923 void *__cdecl memcpy_0(void *Dst, const void *Src, size_t Size)

.text:00540925 jmp     dsff_540A38[


the last instruction the eip adress is loaded with the location on _MEMCPY+33
Aimless
June 3rd, 2009, 12:40
Search for:

How to smash the stack for fun and profit
Aleph One
P49-14.txt

Have Phun
n00b
June 3rd, 2009, 13:22
Thats not what i was hoping for ive released many exploits for all different applications im looking in the disassembly of the vulnerable function that is all.


http://www.milw0rm.com/author/664

I dont need any help with exploits i need to try and see what this memcpy() function is doing.
evaluator
June 3rd, 2009, 15:38
then.. Load.. In.. Debugger.. And.. see.. what.. this.. "function is doing"

BTW:
it must do it's NAME: MEM-CPY :: MEMORY COPY
n00b
June 3rd, 2009, 16:09
Quote:

then.. Load.. In.. Debugger.. And.. see.. what.. this.. "function is doing"

How do you think the heap overflow was found .

Its ok im going to look into this more tonight i know what the functions mean in c c++.
arc_
June 8th, 2009, 05:18
memcpy is a standard C function that copies X bytes from address Y to address Z... I don't see why you would want to disassemble it . It is also probably one of the most optimized functions of the standard library, so you may have a hard time understanding it...
Maximus
June 8th, 2009, 09:20
uhm... what a strange question.
Especially because you did not give all the essential informations about..

However, your 'exploit' should be started in the
Code:


.text:0044E9AD push    ecx             ; Count

which could use the 'header' field value as an effective size without sanitizing it, and then passing to the fread that calls the memcpy with the 0xFFFFFF size (it depends on how memcpy is implemented), which might try to move 4 gb from an address to another, which causes an access violation much before a segment violation.

How can you develop exploits and do not know memcpy?
A 'practical' approach: run with a working header, check if the header field is in ecx, then set it to your exploit value... if it crash, than it is.
WaxfordSqueers
June 15th, 2009, 18:16
Quote:
[Originally Posted by n00b;80913]I have provided disassembly of the memcpy() function below.
Code:


.text:0044E9A1

.text:0044E9A1 loc_44E9A1:

.text:0044E9A1 mov     eax, [ebx+4]

.text:0044E9A4 mov     ecx, [esp+0Ch+Count]

.text:0044E9A8 mov     edx, [esp+0Ch+DstBuf]

.

.

.text:0053C42C call    _memcpy_0
That's not the code for memcpy...you can see the call to memcpy at the bottom. You can tell because memcpy deals with the ECX, ESI and EDI registers mainly. Your code is loading a value into EDX, but you can see the value loaded into ECX is marked as 'count'. That is the number of bytes to be transfered.

If you trace into memcpy, you'll see the ECX being loaded with the number of bytes to be transfered, then the number will be divided by four if the transfer is in dwords. The source of the data to be transfered goes into ESI and EDI points to the destination. With large transfers, the repne movsd or an equivalent statement is encountered. That does the bulk transfer till ECX=0. Sometimes, the transfer is done byte by byte and the EAX is used. A byte at [ESI] id transfered to EAX and that byte is transfered to [EDI].
n00b
June 21st, 2009, 06:57
Thanks for all your help and comments i have not done much with reverse engineering but im wanting to learn as much as i can from this as it was not just a bog standard AAAAAAAAAAA fill the buffer overwrite eip with a jmp esp.

Ill look more close at the functions this time.Thank you for your time.

Quote:

How can you develop exploits and do not know memcpy?

I do know what the memcpy function is for.
Bengaly
June 21st, 2009, 16:34
memcpy - Copy block of memory

Copies the values of num bytes from the location pointed by source directly to the memory block pointed by destination.

The underlying type of the objects pointed by both the source and destination pointers are irrelevant for this function; The result is a binary copy of the data.

The function does not check for any terminating null character in source - it always copies exactly num bytes.

To avoid overflows, the size of the arrays pointed by both the destination and source parameters, shall be at least num bytes, and should not overlap (for overlapping memory blocks, memmove is a safer approach).

Parameters

destination
Pointer to the destination array where the content is to be copied, type-casted to a pointer of type void*.
source
Pointer to the source of data to be copied, type-casted to a pointer of type void*.
num
Number of bytes to copy.


Return Value
destination is returned.

Example
/* memcpy example */
#include <stdio.h>
#include <string.h>

int main ()
{
char str1[]="Sample string";
char str2[40];
char str3[40];
memcpy (str2,str1,strlen(str1)+1);
memcpy (str3,"copy successful",16);
printf ("str1: %s\nstr2: %s\nstr3: %s\n",str1,str2,str3);
return 0;
}



Output:
str1: Sample string
str2: Sample string
str3: copy successful