hi all
i'm testing follow code

int add(int a,int b){
        return a+b;
}
int sub(int a,int b){
        return a-b;
}
int main(int argargv){
        int (*f)(int,int);
        f = add;
        printf("%d\n",f(5,6));
        char *mem;
        int pt1;
        int pt2;
        pt1 = (int)add;
        pt2 = (int)sub;
        mem = malloc(sub-add);
        if(mem==0){
                printf("cannot alloc %d bytes\n",sub-add);
                return 0;
        }
        memcpy(mem,(void *)add,sub-add);
        printf("copy %d bytes to %p\n",sub-add,mem);
        f=mem;
        printf("5+7=%d\n",f(5,7));
        return 0;
}

It's try to run a function that copied to the heap memory. i compiled it with visual studio 6.0 (test_6.exe) and vs2008 (test_2008.exe).
then try debug both of program with ollydbg, i saw that both of processes have heap memory pages are protect with PROTECT_READWRITE, i think it's mean that no code from this memory can be execute. Continue to run to end of program, test_6.exe still able to run the code from heap without any error reported, but test_2008.exe report an access violation error. And i don't know how vs2008 protect to heap from execute code?
any idea about this?
thanks.
Posted on 2009-08-03 04:20:56 by secmask
i've search arround and found that it's relate to DEP , thanks for reading.
Posted on 2009-08-03 04:52:25 by secmask
best to use VirtualAlloc instead of malloc, that way u can set PAGE_EXECUTE_READWRITE for the allocation protection, which keeps dep happy
if you use malloc you will have to use VirtualProtect on the area, and success may not be guaranteed..

generally though such things aren't really needed, and sometimes deemed as viral / malware activity.. and that may result in this thread
being closed due to it being 'suspicious'..
Posted on 2009-08-03 05:39:43 by evlncrn8
Actually throwing a procedure on the heap isn't really 'viral' or 'malware' as far as I can tell. It's used a little in object-oriented frameworks for various things like runtime method selection since all objects tend to be in the heap anyways. I don't see a problem with this thread as long as it doesn't go towards a heap based exploitation discussion. Just keep it localized to the current application and it should be within the scope of the forum rules. Otherwise, I'd suggest talking to a moderator and explain the reasoning before you get into remote process injection.

Regards,
Bryant Keller
Posted on 2009-08-03 07:19:58 by Synfire
Bry, that's not right, usually the object interface (pointer table) is on the heap - the functions are not.
Its not typical to execute code on the heap, it IS a malware trait.
Posted on 2009-08-03 10:57:45 by Homer
yeh, this test i made to get some more information to understand why firefox 3.5 bug allow code to run from heap. I saw that's firefox 3.5 maybe linked with vs2005 and it did not use DEP. In vs2008, DEP is enable by default, think it will be more safe , that's all  ;)
Posted on 2009-08-03 13:21:29 by secmask

Bry, that's not right, usually the object interface (pointer table) is on the heap - the functions are not.
Its not typical to execute code on the heap, it IS a malware trait.


Right mate, I'm aware of how the virt_table system works as I'm sure you know. Where I got that from was during one of my .NET classes the instructor explained that the framework supports a series of dynamic methods which may get loaded into the process heap for runtime selection of methods allowing already initialized objects to add and remove methods through the GC. An example of this is ILGenerator.Emit which loads MSIL instructions onto the heap for compilation by the JIT compiler.

I still don't see it as an explicitly malware trait, take for example self-generating code used to prevent debugging and reverse engineering (compressed/encrypted code segments). A lot of apps are moving away from using the WriteProcessMemory method of altering the code and have begun decoding/decompressing the code onto the heap to be executed there. It does actually have many viable uses.


yeh, this test i made to get some more information to understand why firefox 3.5 bug allow code to run from heap. I saw that's firefox 3.5 maybe linked with vs2005 and it did not use DEP. In vs2008, DEP is enable by default, think it will be more safe , that's all  ;)


Aside from my comments above, that is exactly the direction in which I requested that this conversation not go when I said "as long as it doesn't go towards a heap based exploitation discussion." ;)

I'm locking this thread as it's taking an ugly turn to where I had hoped it wouldn't. If anyone of the other moderators feel it should be deleted or unlocked, then by all means do so. Personally, I see no problem with the content as much as the reasoning which secmask has just made clear.

TOPIC LOCKED

Regards,
Bryant Keller
Posted on 2009-08-03 22:35:31 by Synfire