|
Now I get thread and other API errors in addition to the other ones. I don't get what changed, it just stopped compiling without any changes I'm aware of.
modified 12-Jul-20 21:01pm.
|
|
|
|
|
In some dynamic scenarios, I'm accustomed to calling LoadLibrary and GetProcAddress to load and call a function at runtime. However, in those cases the function pointer is defined in my code that specifies the function's signature. What if I don't know the signature?
Let's say I don't know the DLL and function name until runtime. Obviously, I can call the GetProcAddress as it simply requires a FARPROC address. However, how will I be able to call the function and pass params to it at this point?
One possibility is directly controlling the stack in code since I can't define what I want in code and have the compiler do that for me. Any ideas?
Cheers,
Tom Archer - Archer Consulting Group
"So look up ahead at times to come, despair is not for us. We have a world and more to see, while this remains behind." - James N. Rowe
|
|
|
|
|
Tom Archer wrote:
Let's say I don't know the DLL and function name until runtime. Obviously, I can call the GetProcAddress as it simply requires a FARPROC address. However, how will I be able to call the function and pass params to it at this point?
Do you know the number and types of parameters the function takes?
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
The DLL name, function name and parameter and return info are all passed to me via XML elements.
Cheers,
Tom Archer - Archer Consulting Group
"So look up ahead at times to come, despair is not for us. We have a world and more to see, while this remains behind." - James N. Rowe
|
|
|
|
|
Here goes..
//define your func
typedef DWORD (__stdcall *pFunction)(DWORD, DWORD, etc etc);
pFunction MyruntimeFunc;
//call it
int execute(char * runtimelib, char *runtimefunc)
{
char *TmpPtrToRuntimeFunc,MyRuntimeLib[150] ;
strcpy(MyRuntimeLib,runtimelib);
TmpPtrToRuntimeFunc=runtimefunc;
hLib = LoadLibrary(MyRuntimeLib);
if(hLib)
{
MyruntimeFunc = (pFunction)GetProcAddress(hLib,TmpPtrToRuntimeFunc);
if(MyruntimeFunc)
{
MyruntimeFunc(Param1,param2....);
return 0;
}
}
return -1;
}
//Hope it helps
|
|
|
|
|
I think this is not exactly what he is looking for (if I understood it well). The number and types of arguments are only known at runtime thus it is not possible to use a typedef for the function...
|
|
|
|
|
If you dont know the params either, two solutions
1. as you said... manipulate the stack itself. asm required. push each param onto the stack and call the func address. get ret value from eax.
2. Run-time compilation. Check "http://www.c-sharpcorner.com/Code/2003/Feb/RuntimeCompiler.asp" for a sample.
|
|
|
|
|
munawar1968 wrote:
1. as you said... manipulate the stack itself. asm required. push each param onto the stack and call the func address. get ret value from eax.
Agreed. But this is precisely what I don't know how to do.
Cheers,
Tom Archer - Archer Consulting Group
"So look up ahead at times to come, despair is not for us. We have a world and more to see, while this remains behind." - James N. Rowe
|
|
|
|
|
Thanks for the reply, but this was precisely what I said I can't do as I don't know the fcn signature until runtime.
Cheers,
Tom Archer - Archer Consulting Group
"So look up ahead at times to come, despair is not for us. We have a world and more to see, while this remains behind." - James N. Rowe
|
|
|
|
|
Tom Archer wrote:
The DLL name, function name and parameter and return info are all passed to me via XML elements.
Can you be certain they're correct? If the parameter info is wrong, then disaster could follow. Also, are you certain of what the calling convention is (C vs pascal etc.) as this affects how you should call it.
If you're sure it's safe, then the easiest way is probably to push the parameters on the stack in the right order and then call the method directly - some assembly required. It won't be very easy because you'll have to make sure that any intermediate operations you do in between pushing parameters (such as loading the next value, checking its type etc...) don't modify the stack (or at least leave it in the same state it began in). The return value (if there is one) will always be held in the EAX register (for an 8-bit to 32-bit return value) or EDX:EAX for a 64-bit value. For structures, I believe the EAX register hold the address of the return structure, but I'm not certain.
The other option is to dynamically compile some code that does the same thing, but again you'll run into difficulties passing the parameters.
One way I've had success in passing arbitrary parameter lists in the past is to assemble a block of memory that looks like the stack should, and then allocate space on the stack and copy the memory into it just before you call the function - much easier than managing pushes at the right time.
It would be much easier if you could narrow down the types and number of parameters a bit.
Anyway, I hope that helps a bit.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Hi Ryan,
The client is responsible for the function desc. If it sends the wrong data, then it's expected that bad things will happen. I kinda figured that inline assembler would be needed to push the params onto the stack, but that's exactly what I don't know how to do.
Cheers,
Tom Archer - Archer Consulting Group
"So look up ahead at times to come, despair is not for us. We have a world and more to see, while this remains behind." - James N. Rowe
|
|
|
|
|
Tom Archer wrote:
I kinda figured that inline assembler would be needed to push the params onto the stack, but that's exactly what I don't know how to do.
OK. I'll give a few examples. Hopefully you can extend them.
Say you've got the address of a function in a variable called funcPtr and you need to pass a float and an int and the function returned a char, then you could do something like this (assuming C style calling convention):
char callFunction(void *funcPtr, float parm1, int parm2)
{
__asm push parm1
__asm push parm2
__asm call funcPtr
}Of course this can be extended for more arguments, and it should work for doubles (64-bit values) as well. I'm not sure how it works for values less than 32 bits. I think the compiler pushes an entire zero-extended 32-bit value, so you'll need to take that into account (store smaller values in a 32-bit temporary variable first).
You should be able to put this in a loop as follows:
char callFunction(void *funcPtr, int *values, int numValues)
{
for (int i=0; i<numValues; i++)
{
__asm push values[i]
}
__asm call funcPtr
}It should work alright, but I have never had to do this, so I'm not 100% certain. If it has trouble with the array index, assign values[i] to a temporary variable first (make sure it's local to the function, not the for loop, or you'll have problems with stack corruption).
As I mentioned before, another way I've done it is to allocate a block of memory for the actual parameter contents as they would appear on the stack, and the copy it all in one go. It makes the inline assembly much easier and predictable:
char callFunction(void *funcPtr, void *stackPtr, int stackSize)
{
__asm sub esp,stackSize
__asm mov esi,stackPtr
__asm mov edi,esp
__asm mov ecx,stackSize
__asm rep movsb
__asm call funcPtr
}This version I have taken directly from some code I have written and tested, so I know it works. This is what I would recommend doing, as you can then assemble the stack information without using inline assembly (pointer arithmatic is much easier to understand  ) and just copy the data and call the function using a simple consistent method.
[edit]If you use the last technique, remember that for the C calling convention the parameters are passed in such a way that the highest address has the right-most parameter.[/edit]
Hopefully that gives you enough information to get it working.
Cheers,
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
I just realised my first two examples were wrong  The parameters should be pushed in the opposite order for both of them. The third is still correct though.
Sorry about that 
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Thanks Ryan for all your help.
Cheers,
Tom Archer - Archer Consulting Group
"So look up ahead at times to come, despair is not for us. We have a world and more to see, while this remains behind." - James N. Rowe
|
|
|
|
|
hi
Check out "Smashing the Stack for fun and profit" by Aleph One. great docu for understanding stack manipulation with lots of codes snippets . http://www.phrack.org/phrack/49/P49-14.
xx
|
|
|
|
|
Brilliant stuff. Thanks!
Cheers,
Tom Archer - Archer Consulting Group
"So look up ahead at times to come, despair is not for us. We have a world and more to see, while this remains behind." - James N. Rowe
|
|
|
|
|
Well, just wild guess and I tried it just today at morning, but under some limitations you can go (probably) this way:
If you can stick with the C call convention (no pascal, at least I think), and you can specify fixed type for return parameter, you can define the function signature as follows:
typedef DWORD (__stdcall *pFunction)(...);
Then you can call it in this way:
int execute()
{
MyruntimeFunc = (pFunction)GetProcAddress( NULL,"TestFunction");
MyruntimeFunc( 1 );
return -1;
}
extern "C"
{
__declspec( dllexport ) DWORD TestFunction( DWORD ard )
{
int x = 0;
return 0;
};
}
Because TestFunction knows what to look for on the stack, she'll find it. You only have to make you sure that you'll put the correct types (very important, (BYTE)1 is here not the same as (DWORD)1 ) in correct order.
It's just a morning idea, before I finally wake up, but maybe it will help you. I tested it inside one single .exe file, so maybe some of my assumptions are bad. But at least I tried
|
|
|
|
|
Hi,
is it possible, to start an executable file as a child process? And if not, how can i get an handle on the program I've started?
thanks, Michael
|
|
|
|
|
|
Can some please guide me to run an exe without clicking it & restarting the pc after modification in registry. Is there any way that it can be achieved ?
Regards,
Ibraheem
|
|
|
|
|
CreateProcess()
// Afterall, I realized that even my comment lines have bugs
If the sun were to blow up, it would take us 7-8 minutes to realize it.
|
|
|
|
|
how will it load itself (without clicking or any user interaction) .... ???? can u plz briefly explain
Regards
|
|
|
|
|
It's you who needs to explain. When do you want it to run ? If you want it to run on reboot, follow Tom's advice. If you want your code to cause it to run, use CreateProcess or ShellExecute. If you want it to run every time your PC starts, put it in the Run registry key, or the startup folder.
If you want precise advice, ask precise questions.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Alrtie ... plz see my new post ... I hope u get a better idea now
Regards,
Ibraheem
|
|
|
|
|
Christian is right. It is a little bit hard to interpret your question so I tried to guess. CreateProcess will launch the exe from within your code. ShellExecute too (this is easier to use but not recommended by Microsoft). It is impossible (a telepath would prove me wrong) to start a program without telling the computer to do so. Tom and Ravi gave you excellent answers when it comes to the exe being executed at startup without any user interaction.
// Afterall, I realized that even my comment lines have bugs
Time is the fire in which we burn.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
