Hello,

it there an efficient way to get the size of a C function from C code itself?
Wanting to inject code into a running process without using the DLL loading approach, I need to know how much space to allocate in the remote process. Obviously, how the compiler lays out the code inside the binary may play a role depending on how you try to calculate the size ...

Anyhow, I seem to be able to calculate a size that is always greater than the real size ... so this would be enough for it to work but I was wondering if there is any nice trick C/C++ gurus may suggest.

Obviously I could check how many bytes this function gets compiled into using a disassembler or a debugger ... but doing everything directly from the IDE editor and using C/C++ code would be so much better!! 

yaa

Posted on 2007-11-03 11:30:03 by yaa
Man, about 10 of your last topics are related to injecting the code into remote processes. And you're trying to get every possible info about a process which syggests that your code is supposed to be able to inject into ANY code and -possibly- patch it. What application are you trying to create, if I may ask? Don't take me wrongly - I'm just stictly against helping people to gain malicious knowledge. That's all.

(And of course I'll gladly help if you give me some legal purpose for such knowledge :) )
Posted on 2007-11-03 12:13:58 by ti_mo_n
Only my last 2 posts are about code injection and this is the very first time in my life that I play around with this topic! Trying to get every possible information about it??? Where??? There are plenty of articles (and source code too) around that deal with this topic (only on codeproject you may find at least 10 of them). How about relaxing a little? Why is people here so paranoic? How is your witch hunt going? Got any?

yaa

Posted on 2007-11-03 12:25:54 by yaa
What I'm doing can be clearly read at http://www.asmcommunity.net/board/index.php?topic=28782.0 ... and ti_mo_n, since you have read all my *last 10 topics* you should already known what I'm doing.

I already completed what I wanted to achieve using the remote DLL loading approach .. but I don't like the design (I hate the idea of an external DLL) so I'm reworking my coding using a different approach (all the code is written directly from my injector to the target process).

I have no real issue (rewriting IAT and eventually exports is no issue and even writing the code can be achieved easily enough). I was just wondering if from source code you can calculate the correct size of a C function. I can already do it .. but it is not precise. Enough to make it work ... not enough for my aesthetic pleasure.

yaa

Posted on 2007-11-03 12:54:33 by yaa

Only my last 2 posts are about code injection and this is the very first time in my life that I play around with this topic! Trying to get every possible information about it??? Where??? There are plenty of articles (and source code too) around that deal with this topic (only on codeproject you may find at least 10 of them). How about relaxing a little? Why is people here so paranoic here? How is your witch hunt going? Got any?


I know we just unlocked your other thread, but I wouldn't get so cocky, yet ;)

The reason we keep these topics on the down low is already mentioned in THIS thread. Like it or hate it, that is the reality of it all.


Man, about 10 of your last topics are related to injecting the code into remote processes. And you're trying to get every possible info about a process which syggests that your code is supposed to be able to inject into ANY code and -possibly- patch it. What application are you trying to create, if I may ask? Don't take me wrongly - I'm just stictly against helping people to gain malicious knowledge. That's all.

(And of course I'll gladly help if you give me some legal purpose for such knowledge :) )


The moderation team has determined that what he is trying to do is not malicious, as I think we have all been where he is. He might shoot himself in the foot since what he really wants is for XP drivers to work on 2K3 Server, but all the more power to him. We'll gladly help point that rifle at the most appropriate part of his foot and he can pull the trigger to see what happens :lol:
Posted on 2007-11-03 14:45:10 by SpooK

I know we just unlocked your other thread, but I wouldn't get so cocky, yet ;)


I've been around forums for years, and I just could never not stand people that seem to be on forums only to say "hey, you should not post here", "hey, you are violating this and that" .. if I were I had something to hide would I state my intent so openly?

Anyhow, I do not want to make drivers run on W2K3 but simply be able to install user mode software on W2K3. Recently I have had problems with webcam drivers, photoshop cs3 and windows live writer .. their installer will tell you that they may run only on XP or Vista and yet I have an entire laptop running W2K3 that uses device drivers that were written for XP and everything works just fine!

yaa
Posted on 2007-11-03 15:32:54 by yaa

I've been around forums for years, and I just could never not stand people that seem to be on forums only to say "hey, you should not post here", "hey, you are violating this and that"


In those terms, I've been around these forums for years+1 and I just could never stand people who think that this place is at their disposal.

I take a look at your posts and I can tell you are a taker, you have offered very little help as compared to the amount of help you have asked for.

On the other hand, you can take a good look at ti_mo_n's posting history and obviously see that he is more of a giver and has helped with many threads. He at least offered to help under the terms that what you were doing is not malicious/illegal. I think that is a fair trade, you just have to appeal to his morals.

So, as you can see, you have very little ground to stand on with your petty complaints and I would suggest that you show a little more respect towards those who have been helping out around here ;)


if I were I had something to hide would I state my intent so openly?


That's just it, you didn't state your intent... you only stated what you are trying to achieve. A moderator had to pull you to the side to ultimately determine your intent.


Anyhow, I do not want to make drivers run on W2K3 but simply be able to install user mode software on W2K3. Recently I have had problems with webcam drivers, photoshop cs3 and windows live writer .. their installer will tell you that they may run only on XP or Vista and yet I have an entire laptop running W2K3 that uses device drivers that were written for XP and everything works just fine!


OK, well, forcing the driver installer to install is still forcing the driver to work on a system it was not intended for... no matter how you look at it.

At any rate, good to hear that the process is going well for you :)
Posted on 2007-11-03 16:11:21 by SpooK
Well, first let me explain myself: I'm not a paranoid witch hunter. I just code for living and the last thing I'd like to do is to help someone write a crack for one of the apps/games I made. That's all. And you know: patching your own code is trivial, because you know the source. Patching someone's code (a patcher/crack) is more complex, but still quite easy. Now, writing a code wich is able to scan and patch ANY code is nontrivial and is required -for example- to write a self-replicating virus. That's why your questions alarmed me.

But, OK - to the topic.
There are many, as always, methods to approach this problem. First, the most obvious, is to scan for empty spaces (NOPs or INT3s) within the code. When we talk about binary format, it's easy to distinguish where a particular function (or cluster of functions) start and end (ret folowed by nops). The next step is to look for references. If any given chunk of code is (1) after a ret or jump and (2) not referenced by any jump or call, then it's most likely outside of any function (because it won't be executed).

These are the easiest (both to comprehend and to code) ways to approach the problem. Now, what precisely do you need to do? As they say: "the more precisely you ask, the more precisely they answer" (or something like that ^^').
Posted on 2007-11-03 16:19:30 by ti_mo_n
The reason for the applications that works even when cheated about the Windows version is because them actually want to prevent the ILLEGAL use of them. Where it is the illegality? Simple, home and/or workstation licences of a given product are normally a lot cheaper compared to its enterprise/server counterparts. So, depending on the context, convincing a program that the Windows version is different than what actually it is can be used for illegal proposes.

Of course sometimes the problem is that the program is afraid about newer versions because it is unaware of them and just don't work as a safety measure, but, in which scenario we are now?

Replaced "why" with "we". Don't ask how I did such mispelling because I don't know...
Posted on 2007-11-03 16:43:52 by LocoDelAssembly
about topic:
solution is very simple:
static xxxxx myFunction(....)
{
}
static void EndOfMyFunction(...){}

size = myFunction - EndOfMyFunction;

beware of the static keyword.


Anyhow, I do not want to make drivers run on W2K3 but simply be able to install user mode software on W2K3. Recently I have had problems with webcam drivers, photoshop cs3 and windows live writer .. their installer will tell you that they may run only on XP or Vista and yet I have an entire laptop running W2K3 that uses device drivers that were written for XP and everything works just fine!

Oh, please do not insult. Just left click on the application and check comp. mode. So, the all os version api just work like xp/9x (or what ever you select)
Posted on 2007-11-03 17:06:34 by Dite
Dite,

I suppose you meant size = EndOfMyFunction - myFunction;

That is what I was doing already. And I said in my initial post, it works, apart the fact that you often end up considering padding bytes between functions as part of the size count. But I suppose at this point that this is as good as one can get.

As for the compatibility mode, well, I tried it and, alas, it did not allow what I hoped for.

LocoDelAssembly, I believe support effort is the reason for restricting supported OS as much as possible. Why should I support my product on more OS if I know that one given OS has a small user base and support issues deriving from that single OS may be numerous? It's easier to just state that you don't support it.

yaa

Posted on 2007-11-03 18:12:04 by yaa

Now, what precisely do you need to do? As they say: "the more precisely you ask, the more precisely they answer" (or something like that ^^').


Based on what I've seen, code injection usually takes 2 forms: windows hooks and remote loading of DLLs. The last I've already done. Easy enough. What I don't like is the presence of this external DLL. Simply ugly. Another approach I'm trying is writing code to the remote process and redirecting the interested APIs (at the moment GetVersion, GetVersionExA, GetVerionExW and VerifyVersionInfo) to my code.

With the remotely loaded DLL everything is simplified, you can place any call in the DLL
(local call or API call) and everything will work fine (offsets are ok already and the DLL has it's on IAT so you can call anything you need).

With the code injected inside the remote process there are tricky areas to consider:

1) local function calls - either you maintain the same *distance* between functions/procedures inside the binary as there is in your injecting application or offsets will have to be edited

2) Windows APIs: IAT entry dwords will probably differ between you injecting application and the target process

CALL DWORD PTR DS:        ; xxxxxxxx will probably be different in the target process


3) static/global data: space will have to be allocated in the remote process and references to this data will have to be edited

I may still be missing other areas of attention ....

I suppose there is no other approach apart having the byte stream to inject (the functions that will handle the redirected API calls) and know which address bytes to edit inside the byte stream. I honestly don't like this approach because any change required to the functions requires editing the byte stream and changing the code responsible for patching the addresses (offset or absolute) inside the byte stream.

My questions are two at this point:

a) is there any other area of attention to consider when writing code that will be relocated (as the one that I will inject)?

b) is there any other more manageable solution apart the byte stream + address patching code approach?


yaa


Posted on 2007-11-03 19:13:38 by yaa
What I don't understand is that if you're trying to patch some specific, well known (at least for you) application, then why not simply scan it (manually with an editor), find its references to the aforementioned functions, find its relocations, etc, etc, and then change the jumps/calls appropriately. It's as easy as writing relocatable code which calls (real) functions, finding some place for it inside the exe, writing it there, and patching all references to real functions inside that exe.

So I either still don't understand what you're trying to say, or you're trying to do your work the hard way ^^'
Posted on 2007-11-03 20:28:00 by ti_mo_n
Well, the applications are those I mentioned. But I want to pull out a tool that will do the job the next time I encounter another application.
You asked for the details and I believe I've been as clear as I could be ... I do not see what it is that you still do not understand at this point.

yaa
Posted on 2007-11-03 20:34:48 by yaa

LocoDelAssembly, I believe support effort is the reason for restricting supported OS as much as possible. Why should I support my product on more OS if I know that one given OS has a small user base and support issues deriving from that single OS may be numerous? It's easier to just state that you don't support it.


I agree with that, but I mean the case in which the software producer sells another version that works in a Windows Server and it is more expensive. For example, Norton Anti-Virus don't allow you to install a home version of its product on a Windows Server, even though the binary is fully capable to run on it. So, by changing the result of GetVersion to WinXP Home or Professional you could save some bucks by purchasing a home license of the anti-virus, but such thing is illegal.

That is the example I'm talking about, but I think it is OK in the case that the program complains just because it is an unsupported OS to change GetVersion behaviour. (Even Windows itself allows something around this by the right-click on executable->compatibility mode as Dite said).
Posted on 2007-11-03 20:57:30 by LocoDelAssembly

The reason for the applications that works even when cheated about the Windows version is because them actually want to prevent the ILLEGAL use of them. Where it is the illegality? Simple, home and/or workstation licences of a given product are normally a lot cheaper compared to its enterprise/server counterparts. So, depending on the context, convincing a program that the Windows version is different than what actually it is can be used for illegal proposes.

Yes, some of the free antivirus programs, for instance, requires a license for server use - I sure hope this isn't what yaa is trying to circumvent (although you could argue that a Server OS used for a workstation, as I know many people are doing with win2k3, isn't really "server use" - still, it's a violation of license).

There's enough badly-written software that doesn't do it's version-checking right, though, and "compatibility mode" for some reason doesn't always get it right. So I guess this topic is okay, even if a bit "edgy".

yaa: get used to an external DLL when doing code injection, it is not ugly - the various workarounds people try to avoid it are far uglier. With the DLL method you don't have to jump through any hoops or write code specially, no delta-relativeness, manual fixups, etc etc etc. And anything you can try doing in C/C++ will eventually explode in your face if you change compiler, optimization settings, or the phase of the moon.

The only reason I can think of for not wanting an external DLL or calling it "ugly" is if you're writing malware and want a one-click-infector.exe that doesn't dump any temporary DLL files... for legitimate purposes, DLL injection is by far the cleanest and easiest way to go.

And legitimate purposes are what we're dealing with here, right?
Posted on 2007-11-04 14:50:58 by f0dder