Identify LabVIEW as DLL caller

[Raistlin]

I would like to be able to identify LabView as being the calling process of a C++ DLL (inside the DLL code). This way I can differentiate the behaviour of the DLL based on whether it is called from LabVIEW or from another programming environment. Does anyone have an idea how I could do this ?

Message Edited by Raistlin on 08-03-2006 09:13 AM

[Christian Mergl]

Hi Raistlin,

The only way to do this would be to set a parameter depending on the programming environment calling the dll within this environment

and differentiate the behaviour of the DLL based on this parameter. (For LabVIEW see ....\LabVIEWx.x\examples\dll\ )

Christian

[Wiebe@CARYA]

"Raistlin" <x@no.email> wrote in message news:1154616010268-399965@exchange.ni.com...
I would like to be able to identify LabView as being the calling process of a C++ DLL (inside the DLL code). This way I can differentiate the behaviour of the DLL based on whether it is called from LabVIEW or from another programming environment. Does anyone have an idea how I could do this ?Message Edited by Raistlin on 08-03-2006 09:13 AM


You can query the module name using windows functions (GetCurrentProcess, GetInstance and GetModuleFileNameEx) in the DLL.


You can also call GetCommandLine, and see if it starts with "Labview.exe". Should work when called from the dll.


Both don't work if you create an executable with LabVIEW (the exe name will be the name of the executable).


Another way is to enumerate all modules (see "Enumerating All Modules For a Process" in the MSDN) and see if there is a module used by the running process (lvrt.dll or something).


Or you could simply make an export function in the DLL that sets a global in the DLL.


Regards,


Wiebe.

[Raistlin]

There are some interesting suggestions there. In fact, it should not only be able to identify if LabVIEW calls the DLL, it should also be impossible to act as if LabVIEW calls the DLL. It is in fact in the context of an SDK which we distribute to customers, which should be waterproof in terms of security. Only if it is called from LabVIEW certain possiblilities (such as a demo mode) should exist. We could off course work with two versions to make things easier.

[Wiebe@CARYA]

"Raistlin" <x@no.email> wrote in message news:1154967007977-401167@exchange.ni.com...
There are some interesting suggestions there. In fact, it should not only be able to identify if LabVIEW calls the DLL, it should also be impossible to act as if LabVIEW calls the DLL. It is in fact in the context of an SDK which we distribute to customers, which should be waterproof in terms of security. Only if it is called from LabVIEW certain possiblilities (such as a demo mode) should exist. We could off course work with two versions to make things easier.


In security, there is no such thing as waterproof. Any mechanism you build in can be removed or faked. Even self modifying code, compressed code, debugging traps, etc. can be removed.


Settle for a mechanism that is waterproof enough. Removing it should cost (much) more than the official release. Spending one day to remove security mechanism from a 100$ toolkit would be kinda stupid. Also consider what public will use it. Big companies will usually not work with illegal software. The number of users is also important. If you're making something like Windows, or Word with millions of users, it will be cracked sooner that a LabVIEW SDK, with (hopefully for you) hundreds or max. thousends of users.


I'd use GetProcAddress, with NULL and any of LabVIEW.exe's export functions. LabVIEW will have them, the created executable won't. It will be very easy:


If (!tested)
{
If (GetProcAddress(NULL, "ASCIITime"))
{
labview=true;
}
tested==true;
}


Easy to make. Also easy to remove if you're making a c or c++ dll.


Let us know how it turns out.


Regards,


Wiebe.

[Raistlin]

Thank you for that last suggestion. This seems to be a nice solution, and it works like a charm. And you are right, it would take some work to overcome such a protection.