Hi,

i am pretty new to the fasm assembler and i must confess, i do have "ZERO" assembly language knowledge compared to others here. Before i posted this question, i had a look in the faq, did a search in the board, also try to find any information in the documentation, but unfortunately i couldnt find a answer to my question. I try to load machine code "dynamically" from a binary file into my C program and execute it by allocating memory, mark it executable and get a pointer to it by using a function pointer cast to the memory filled with the binary code. Finally i call the function and get the result. In general i am doing this not that way, instead i use a library with exported functions or a static library to incorporate code into my application. Here comes the problem:

I try to assemble e.g. these simple instructions into a "flat" file (i am using fasmw 1.70.03 and i simply enter these instructions (without any prolouge/epilouge) in the IDE:


mov eax,[esp+8]
mov ecx,[esp+4]
add eax,ecx
ret 8


where flat stands for the raw assembling into machine code, without any sections/headers etc. But the result i get seems to be using only the 16 it parts of the registers (which for sure isnt the problem at all) and the rest is "padded" somehow. But trying to load and execute this (i am on nt based windows 32 bit) fails with an access violation. The translation into binary code ends up in this:

Dump of File Image
0x00000000 67 66 8B 44 24 08 67 66 8B 4C 24 04 66 01 C8 C2 gf.D$.gf.L$.f... +00
0x00000010 08 00 .. +10

and decompiles into this:

MOV AX,WORD PTR [ESP+0x8]
MOV CX,WORD PTR [ESP+0x4]
ADD AX,CX
RET 0x8

but i need this which i get by doing hex editing the final result:

Dump of File Image
0x00000000 8B 44 24 08 8B 4C 24 04 01 C8 C2 08 00 .D$..L$...... +00

which correctly decompiles into the original instructions:

MOV EAX,DWORD PTR [ESP+0x8]
MOV ECX,DWORD PTR [ESP+0x4]
ADD EAX,ECX
RET 0x8

and this can be executed without any problems.

What can i do, to get the the result i want? I guess its some meta instruction in the source files header, but i couldnt find anything than could help me.

thanks in advance

TRP

[ Post removed by author. ]

VirtualAlloc, VirtualProtect, VirtualFree is clear so far and the way i am doing it already, but what do you mean with 16bytes padded with no operation instructions?

[ Post removed by author. ]

AFAIU this is the multiple of 16 and if yes, why the multiple of 16? I had 18 bytes on the original output and i nop'ed it to 32 bit, but it still looks like this:

0x00000000 67668B442408 MOV AX,WORD PTR [ESP+0x8]
0x00000006 67668B4C2404 MOV CX,WORD PTR [ESP+0x4]
0x0000000C 6601C8 ADD AX,CX
0x0000000F C20800 RET 0x8
0x00000012 90 NOP
0x00000013 90 NOP
0x00000014 90 NOP
0x00000015 90 NOP
0x00000016 90 NOP
0x00000017 90 NOP
0x00000018 90 NOP
0x00000019 90 NOP
0x0000001A 90 NOP
0x0000001B 90 NOP
0x0000001C 90 NOP
0x0000001D 90 NOP
0x0000001E 90 NOP
0x0000001F 90 NOP

use32

I found it, its the use32 directive that must be placed in thea sources header section.

Yes, i found it, its documented here:

http://flatassembler.net/docs.php?article=manual#2.4

Thanky you anyway.

[ Post removed by author. ]

Thank you for the example, but this could "possibly" not work in Windows and could possibly also not work in *nix systems and its also not eaxctly the answer to my OP. The OP question was how i could make the input assembly instructions go output into 32 bit assembly and not the 16 bit variant. Your example uses correct bytes to run, but you are using the wrong methods. As you pointed out by yourself, one should use the Virtual* functions, but malloc() uses internall malloc->HeapAlloc->RtlAllocateHeap accross three dynamic link libraries and the heap allocated memory could, must not be executable due to memory protection mechanisms. This could lead to a segmentation fault. In *nix you use mmap() and mprotect() for this. Even though the memory will be freed by the OS kernel on app termination, one should always use free() on *nix or VirtualFree() on Windows systems to release the memory previously allocated.

[ Post removed by author. ]

I guess it "can" work on *nix systems, but if memory protection comes in, it will fail in some way.