LabVIEW
Redirecting a call from lvanlys.dll
Well, a .h file won't help you to recompile the DLL. You need all of the .c files that NI uses to create that DLL and I'm sure there is no way to get at that with legal methods. You may feel that you can not recompile your executable for whatever reasons, but trying to recompile that DLL without source code available is about several magnitudes more impossible, no matter what your reasons are for not being allowed to recompile the application.
Also even if you had those sources, just replacing what that function does may have severe side effects for other LabVIEW analysis functions that might use this function internally too.
All the analysis VIs are open. The function header can be read in the call library function node...
DLL redirection (and\or function hooking) is possible, but it is hacking. It is simply not useful in a production environment. It might very well be illegal. And you won't find much resources on doing it from\to LabVIEW.
Mentioning that you're not allowed to recompile, and are required to make changes makes all kinds of alarm bells go off...
Search LabVIEW like a graph! So you want to generate a lvanlys.dll that exports all the functions the original does and then directly forwards all but this single function to a renamed copy of your lvanlys.dll?
Even if you had the headers that would be a huge undertaking to do if you wanted to do it in C. There might be ways by generating a delay load import library from the DLL export table only but it ain’t be neat nor easy to do.
Delay load import libraries contain a pointer for each import and on first call check for the function in the target dll and load it and store the pointer then make an immediate long jump to that pointer so that whatever parameters are on the stack will correctly been seen by the target. There are command line tools from Microsoft to do that from a module definition file .def. you can’t do this in C but need to directly generate assembly code instructions to make this work.
Then edit the import library to remove the import stub for your function (or leave it away from your .def file), create a c file that replaces the function in question and link the .lib, full .def and .obj together into your own lvanlys.dll.
Easy? By a long shot not!
Bogus? Very much!
Maintainable in the long run? No!
@Steve_Block wrote:
I don't need the source code because I can make a DLL call a DLL but do need the function prototypes to link everything together. It is just a huge amount that need to be matched.
You'd only need the prototypes of the functions that you're calling. You should know which functions you're using. If not, you'll find out soon enough if the functions are not present in the dummy dll...
I'd go for function hooking if, and only if, I really, really had to do it. And after explaining to all involved how futile it will be in the long run. And with 0% guarantee of success and 80% change of failure.
Once the function is loaded, you can get it's address. As this is your process' memory, you can write to it. So, load another function (LoadLibrary\GetProcAddress), and overwrite the function so it jumps to your function.
That is the theory, and if you get everything right, it should "work". "Work" as in "it does the job" not as in "it works out great".
IIRC, you can probably make it (a tiny bit) neater by using a debugging API, but that's been a while..
BTW. Have we mentioned it's a terrible idea?
