LabVIEW
Problems when using C# dll or C dll
Solved!
wiebe@CARYA 已写:
@rolfk wrote:
wiebe@CARYA wrote:
And for the reason... The dll is a licensing dll. The code validates the file's hash against a hardcoded hash, to make (reasonably) sure it's not modified.
Sounds like a maintenace hassle to me! Signing of the DLLs would seem more secure and part of the build process. For signed DLLs the OS will only load them if the signature is valid.
Didn't say it was a good reason
.
The maintenance is OK for now, the dll only changes once or twice over the few years. Maybe easier then managing certificates, the application is distributed to a lot of systems (>50?).
I can not quite get your attitude or opinion
, Do you agree my usage or agree the signing usage ?
If you still think that this is a superintelligent thing to do, you should look at the open mode of the File Open node. It's default value is NOT compatible with accessing a file that is already open by someone else.
ans: I have other solution but this, because the OEM supplier is for Internet usage ,just offering JAVA\PHP\C#\C source code as API, considering the security, the only way I can do is to bulid a DLL and call it .
As already mentionded, look at the default values of the File Open node! It is by default opening a file for read AND write access. That is not compatible with a file that is already open elsewhere. The error code that is returned by File Open could have told you that.
And for the reason... The dll is a licensing dll. The code validates the file's hash against a hardcoded hash, to make (reasonably) sure it's not modified.
yes ,you got my idea. but ,what does your "reasonably" mean ? are you saying "there is no use " ? do you have better method to ensure it ?
What is reasonable is in the eye of the beholder. But a simple hashing algorithme with a comparison to a fixed value will only dwart the casual hobby hacker. It will not keep out the determined hacker. Figuring out the hashing algorithme is not that difficult. It's actually a little more involved in LabVIEW since most people have no idea where the actual executable code is located in a LabVIEW program, but it is compiled code too, just as a normal DLL and can be therefore looked at with a debugger. From that its fairly easy to deduce the nature of simple algorithmes and slightly more complicated for more complex algorithmes.
@alii001 wrote:
wiebe@CARYA 已写:
@rolfk wrote:
wiebe@CARYA wrote:
And for the reason... The dll is a licensing dll. The code validates the file's hash against a hardcoded hash, to make (reasonably) sure it's not modified.
Sounds like a maintenace hassle to me! Signing of the DLLs would seem more secure and part of the build process. For signed DLLs the OS will only load them if the signature is valid.
Didn't say it was a good reason
The maintenance is OK for now, the dll only changes once or twice over the few years. Maybe easier then managing certificates, the application is distributed to a lot of systems (>50?).
I can not quite get your attitude or opinion
I read a .NET dll as file myself, for the same purpose of validation.
Signing might be a more elegant solution, although potentially also a hassle.
I'll stick with .NET file hash validation for now. It works for me, because the .NET dll is very stable. If the .NET dll would change often (e.g. recompile), the certificate signing might be worth exploring.
Validation of the file is the only 'good' reason I can think to read the .NET dll as a file. I quoted good, as it is a bit crude.
Search LabVIEW like a graph!
@alii001 wrote:
@rolfk 已写:
wiebe@CARYA wrote:
And for the reason... The dll is a licensing dll. The code validates the file's hash against a hardcoded hash, to make (reasonably) sure it's not modified.
How to sign the DLL ? when building exe or installer? Forgive me , I am not an experienced programmer， I am just good at engineering and want take my idea into practice. thank you
Although LabVIEW executables can be signed, this is about signing the .NET assembly. If the .NET assembly is signed, changing it will invalidate the signature, and Windows won't run it anymore.
So with a signed .NET assembly, you wouldn't have to change the LabVIEW hash that is embedded somewhere every time the .NET assembly is recompiled. That would be beneficial if the .NET assembly changes a lot, or if it is updated in a different cycle as the LabVIEW application.
I'd say the LabVIEW application would still need to check if the loaded .NET assembly is properly signed. If it doesn't the entire signed assembly can be replaced with an unsigned assembly, and Windows wouldn't mind as it's not signed at all.
I have no idea how to sign a .NET assembly. That's a question for a .NET forum, although I'd answer if I knew. But I don't.
