LabVIEW
DLL secure when distributed with Installer?
battler. wrote:Hi all,
I have written an application which I build into an executable with an internal processing function.
I was considering converting the processing function into a DLL and calling it from the main application.
The main advantage is that if I need to update the internal processing function then users can simply replace the DLL in the programs folder without uninstalling the main application. DLLs are also more efficient and hence faster, are they not?
My concern is the security of this DLL. My main program is protected. If someone could access the internal processing function DLL then they wouldn't need my main application.
If I give out a DLL is it accessible from anything other than my main application? Is it protected? What would people need to use it, just the header file?
I hope this question is clear. I do not have any experience with DLLs.
Thanks for your help.
Battler.
First, DLLs are not faster. In the DLL there is the original compiled and stripped VI and the DLL builder creates a C stub that invokes the LabVIEW runtime, loads the VI into it, passes all parameters to the VI and on return copies all return data back into the DLL output parameters. If you do use C datatypes (C pointer arrays and C pointer strings) to pass tothe DLL, your DLL is compatible to any caller that can call a DLL function but some data copying is involved between the C pointers and the internal LabVIEW data inside the DLL. No big deal for skalars and small arrays and strings but it can be a clear preformance hog if you intend to pass huge arrays or strings.
If you decide to use LabVIEW datatypes instead the copies are not necessary, if and only if the DLL is compiled in the same LabVIEW version as the calling LabVIEW application. The downside is that the DLL will not be callable by anything but LabVIEW.
A DLL is a DLL. In the case of a LabVIEW DLL it even includes some sort of typelibrary that allows LabVIEW to actually setup the Call Library Node automatically and correctly. This is actually a MS feature which is nowhere else used AFAIK. So yes anyone having LabVIEW could take your DLL and create a VI for every function in it, and guessing at the function of each parameter use it in anyway he or she wants.
If you give out a DLL it is only protected in whatever way you have implemented specifically in that DLL. In the case of LabVIEW there is actually an additional protection since the real meat of the function is in a VI, whose binary format is undocumented and hence unknown to anyone not working in the LabVIEW development team, so disassembling such a DLL is almost impossible. For normal DLLs a disassembly is very easily done and you need to go through a lot of trouble to prevent that. However as pointed out before, to use the DLL, the header file won't even be necessary. The LabVIEW DLL contains that information and even more in its internal typelibrary already, although I'm not aware of any tools other than LabVIEW that do make use of that.
Taking all your posts you seem to spend a lot of effort to protect your program. From experience with other similar cases I can tell you that in 95% of the cases such protection is wasted time, since the product protected in such a way is never sold in any quantities that would warrant such an effort.
Rolf Kalbermatter
battler. wrote:Interesting Rolf.
So if I implement protection in my DLL which is required for it to work (i.e. a password string) then that is a way of protecting it from being used?
Yes but not a very high security. I would simply replace the DLL through a wrapper call that intercepts the parameters and passes them on to the real DLL and voila your secretly held password is out on the streets to be used.
Rolf Kalbermatter
battler. wrote:Suppose the "password" is linked with the hardware of the machine. Then it would not matter if the user could intercept it because they would not know how to generate it for other machines. Sound plausible?
Battler.
To some extend. It's not a very high class protection but you have to know about this. Im not in the business of using nor providing such protection schemes for our products.
In fact I'm avoiding such protection schemes whenever possible including in the tools I use.
Rolf Kalbermatter
