Page 2 of 2
Posted: Mon Feb 19, 2007 4:41 am
by AJ
Hi,
Just another thought - why not parse the header file for parameter information and only let the user enter functions found in the provided header - kind of like how code completion works? That way you could provide code completion as additional functionality too.
Cheers,
Adam
Posted: Mon Feb 19, 2007 4:44 am
by pcmattman
The point of the program is that it asks the user to type/select a function, then enter in it's arguments, then run the function.
It's my job on the project to write the actual nitty-gritty part of things - the functions that call the function in the file. To get more info, go to SourceForge and find APICaller.
While you're at it, take a look at my project, MLC... it's not much yet but I'm getting there
...
Posted: Mon Feb 19, 2007 5:07 am
by os64dev
ok, if i understand correctly you just want to call a user specified function from a user specified dll/exe with user defined parameters. The first two are rather easy but that latter might give some headaces.
Code: Select all
#include <windows.h>
int main(int argc, char * argv[]) {
//- argv[1] contains dll.
//- argv[2] contains func.
//- argv[3] onwards should contain the parameters.
DWORD func;
HMODULE hmod;
if((hmod = LoadLibrary(argv[1])) != 0) {
if((func = GetProcAddress(hmod, argv[2])) != 0) {
//- ok, we have got the requested address. now call it.
<<see below>>
}
}
}
the difficulty is now how to call the function with the different parameters as each function can have a different number of parameters as well as different types and even different call methods
cdecl, stdcall, fastcall etc. so you first have to study the different call methods and then mimic the behaviour and problably use assembly to call the function. for instance cdecl uses the stack. so you could:
1) build a local stack
2) push the parameters in the correct order
3) call the function (assembly using the local stack)
4) save the return value
5) restore the program stack
6) return the saved return value
The concept is rather easy but getting it to work might not be. good luck.
Posted: Mon Feb 19, 2007 5:43 am
by Solar
Combuster wrote:And yes, using getprocaddress is bad for security, but then again, who runs winamp as admin and leaves the plugin directory open for non-admin users? (or: why not find another hole in IE instead)
You shouldn't run MSIE as admin, either - that doesn't mean that it's OK to turn a blind eye towards its bugs. Consider the combination of such an easy stack-smashing attack and a user priviledge escalation bug in a different component...
In my eyes, telling management "shouldn't be done" is a very valid technical decision. At least get your doubts stated in writing, so they won't hang
you out to dry when things go wahoonie-shaped.
Posted: Mon Feb 19, 2007 10:12 am
by Brendan
Hi,
pcmattman wrote:It's my job on the project to write the actual nitty-gritty part of things - the functions that call the function in the file. To get more info, go to SourceForge and find APICaller.
I did...
As a utility intended for quality assurance and test purposes I can't see what the point is, considering that most functions rely on "state" (e.g. global data and/or data loaded from files), and that most people who have access to source code usually have access to "cut & paste".
I'd also be skeptical of a project where the leader knows less than you do (unless you're being paid well, in which case grab the cash while you can).
Compare this paragraph (from the
main page):
"
API Caller is a software for extracting API functions from any executable and can be used to call them. With this tool, quality can easily be checked by calling functions and checking them if they are error-free."
To this paragraph (from the
tracker):
"
coding a function in API caller for calling the APIs itself, this function
can used with any type of parameters (e.g. bool, int, char) and can also
return any type. And also any number of parameters. Also, please make
another separate function to load the executable and the header in C++, if
necessary also it's library. It's up to you how the function is named and
how the parameters can be entered. If there's a problem, please tell me.
Thanks for your help."
Is it just me, or does this sound a lot like "I'm building a time machine, but I can't figure out how to travel through time. All help appreciated..."...
Once you've done all of the hard work (um, written the little function) what will the "project leader" add to the project? Some user interface fluff, or a little documentation?
Cheers,
Brendan
Posted: Tue Feb 20, 2007 12:17 am
by Solar
A pretty twisted approach to what is generally refered to as "test drivers". You usually want them to reside in code, alongside the stuff that is being tested, because the real value of a test driver is that it can be run repeatedly so you can compare results...