How to calculate the exact size of a piece of code?

Hi guys,
I'm currently trying to inject some code in a target.
Say that code is a function named void Func()
(I don't want to use assembler, I'm going to coding all
in C/C++.) I use the WriteProcess API to write the code in the target.
The code is written in a buffer allocated using the
VirtualAllocEx API.
I need to calculate the exact number of bytes occupies Func()
so I can pass this information to the writeprocessmemory.
How can i do that?
cheers
z.

Hello,

Take a look at this interesting paper:

http://www.codeproject.com/threads/winspy.asp

or

http://www.codeguru.com/Cpp/W-P/system/processesmodules/article.php/c5767/

(same article)

title: Three Ways to Inject Your Code into Another Process

It's all in C++ , have fun !

Regards, Neitsa.

Originally Posted by zaratustra

I need to calculate the exact number of bytes occupies Func() so I can pass this information to the writeprocessmemory.
How can i do that?

For example this way:

void __declspec(naked) BeginOfCode() {}

void __stdcall Wrapper()
{
   [...your code... ]
}

void __declspec(naked) EndOfCode() {}

void Inject()
{
   WriteProcess(
     ...
     Wrapper,
     EndOfCode - BeginOfCode,
     ...
}

Naked attribute used to strip any dummy code in output object

[TQN]

I think your method will not work. BeginOfCode and EndOfCode are empty functions. In VS and VS .NET, when compile your code in Release mode, compiler optimization can remove or move two above function to another location. So I think we need a #pragma optimize(off) at begin of block code, and another turnoff options.
Regards,
TQN

Originally Posted by TQN

I think your method will not work. BeginOfCode and EndOfCode are empty functions

Trust me It works...
Optimizer can't strip these functions because they used in code. And of couse we have to disable incremental linking.

it works, indeed. i used a similar method too, although i didn't like it much, but there is no clean solution to do so (at least, none that i know of)

This will not necessarily work because function code is NOT contingues in memory. Function code can be splitted in several code segments.
The only thing do get the real size is via debug symbols.

xMaster

Even if the functions are in the same segment, the result is probably always a multiple of 16, because the functions are usually aligned to paragraph borders (historical reasons) and the room is filled with nops or int 3-s. So in the best case you get the size of your function rounded up to be dividable by 16.

No I would say it is aligned on 16 byte (or whatever) because of cpu/memory caching reasons.
This is not neccessaryly 16 Byte. CPU data cacheline size on current modern cpu's is 64 Byte.

xmaster

very helpfull... thanks

Having the target on a 16 byte boundry is very important for performance reasons on a non-P4 (or even a P4/P4 Xeon if the target is not in the uOP cache). The reason is the IFetch buffers are loaded directly from tag lines, and thus, if they are not aligned, you are paying for fluff (i.e. bytes will be loaded that are never used).

As xMaster said, in an ideal world, 64 bytes would be even better, but could you imagine 63 bytes-o-NOPs between single ret functions? Only Microsoft... (I kid, actually their compilers arent that bad).