Problems when using C# dll or C dll

[alii001]

---

@rolfk  已写:

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.

---

so, is it difficult to protect my software by using LabVIEW to develop it?

I have heared that it is impossoble to decompile the exe file developed by LabVIEW, so I think LabVIEW is a good way to hide and protect my code.

But now,from your saying,it seems quite easy to debug the .exe file and even dig out the VIs by some professional tool.

I am a little disappointed,what shall I do?Is there a way LabVIEW mix the VIs absolutely when building exe and never be cracked?

[rolfk]

Well if that helps, it is even easier when you create a DLL in C or some other compiled language. And yes that includes also IL code in .Net, even with obfuscation. So just deal with it. The only way to make software 100% safe from cracking is by locking it in a steel safe, destroy every other copy and then sink the safe in the  Mariana Trench. I can guarantee you that there will be for the next 100 years nobody who ever breaks that code. 

[alii001]

---

@rolfk  已写:

Well if that helps, it is even easier when you create a DLL in C or some other compiled language. And yes that includes also IL code in .Net, even with obfuscation. So just deal with it. The only way to make software 100% safe from cracking is by locking it in a steel safe, destroy every other copy and then sink the safe in the  Mariana Trench. I can guarantee you that there will be for the next 100 years nobody who ever breaks that code. 

---

eh, what does "that" mean ? I indeed make that DLL by C language, I considerd that C is safer than C#.

It seems we are far away from the origional question I asked, I want to avoid the code 5 error when read the DLL file by binary. You told me to set the parameter on FILE OPEN block, but I am a little puzzled about that method .

First , as I metioned , It should be the DLL who decide allow others open it or not , not the new thread or software,are you willing to explain more about ?

Second , I glanced the OPEN block ,belows are the total input of them ,which input should I modify ?

[wiebe@CARYA]

---

@alii001 wrote:

 First , as I metioned , It should be the DLL who decide allow others open it or not , not the new thread or software, are you willing to explain more about ?

---

AFAIK, the dll has no say in that whatsoever.

A dll is loaded and executed by the system. I don't think it cares at all if the file is loaded or locked by other threads and\or software. If the file can be loaded, it will run.

[rolfk · Accepted solution]

---

@alii001 wrote:

eh, what does "that" mean ? I indeed make that DLL by C language, I considerd that C is safer than C#.

Ever heard of something called Disassembler? A DLL can be simply loaded in one and an educated person knowing about the machine code of the CPU in question can then exactly deduce the algorithme in there. No it's not as trivial than reading the actual source code, since assembly code is quite a bit more low level than C but it's no rocket science either. But there exist tools that can turn the created assembly code into pseudo C code that needs only some cleaning and tweaking in order to be compilable.

You also have similar Disassemblers for .Net IL code, and while the more simple free ones can be dwarted with obfuscation when creating the assembly, there are some tools out there that can reconstruct the original code very accurately albeit not verbatim.

It doesn't require state sponsored hacker groups at all, everybody with a computer and some dedication can do it in his home office, although some of those tools do cost considereable money. It's illegal to do that in order to steal information but it's also illegal to kill people and there are still people murdered every day. There are also legal uses of Disassemblers such as research, debugging your own software when it doesn't work, and even learning how something else works as long as you don't steal it. But if you live in the US you need to be very careful with doing that.

First , as I metioned , It should be the DLL who decide allow others open it or not , not the new thread or software,are you willing to explain more about ?

Sigh. It's irrelevant what you believe in this case. That is simply not how an OS works. The file has very little to say about who can open it and when. That is decided by attributes of the file as set through the user or installer and then by the OS. Whoever opens a file can decide if he wants to open it for just read or write access or both. The OS does that also when accessing a file, be it a data file or a dynamic loadable module. For dynamically loadable modules it also leaves the file locked after it has been loaded, in order to prevent some rogue process or malicious user to modify the file and pull the rug under its feet. It at leasts marks the file as not writeable by anyone else but might just as well decide to lock the file completely and with that disallow any access to that file by anyone else.

Second , I glanced the OPEN block ,belows are the total input of them ,which input should I modify ?

---

I spelled it out already almost to the letter! For some reason what is called "access" in my copy of LabVIEW seems to be called "authority" in yours. No idea why. This parameter tells the OS if the file should be opened for read, write or both. If the file is loaded by someone else and marked as not accessible for write access, trying to open it with read-write or write-only access will cause the OS to deny opening the file. For your case this should be set to read-only.

[wiebe@CARYA]

---

@rolfk wrote:

For some reason what is called "access" in my copy of LabVIEW seems to be called "authority" in yours. No idea why. 

All of those inputs have different names that the usual. For me it's also "access", or more precise "access (0:read/write)". And "disable buffering (F)" iso "forbidden cache ( F )". Weird.

[alii001]

---

wiebe@CARYA  已写:

---

@rolfk wrote:

For some reason what is called "access" in my copy of LabVIEW seems to be called "authority" in yours. No idea why. 

All of those inputs have different names that the usual. For me it's also "access", or more precise "access (0:read/write)". And "disable buffering (F)" iso "forbidden cache ( F )". Weird.

---

Sorry ,these words are translated by me and Google, thus not enough correct, because my LabVIEW is Chinese language Version. 

That is why I put the diagram picture there, I am aiming to give you enough information.

[alii001]

---

@rolfk  已写:

---

@alii001 wrote:

eh, what does "that" mean ? I indeed make that DLL by C language, I considerd that C is safer than C#.

It doesn't require state sponsored hacker groups at all, everybody with a computer and some dedication can do it in his home office, although some of those tools do cost considereable money. It's illegal to do that in order to steal information but it's also illegal to kill people and there are still people murdered every day. There are also legal uses of Disassemblers such as research, debugging your own software when it doesn't work, and even learning how something else works as long as you don't steal it. But if you live in the US you need to be very careful with doing that..

---

I live in a country that you may know,not like in the US. and I myself have to pay much more attention on protecting my codes and idea……

[alii001]

---

@rolfk  已写:

---

@alii001 wrote:

eh, what does "that" mean ? I indeed make that DLL by C language, I considerd that C is safer than C#.

Ever heard of something called Disassembler? A DLL can be simply loaded in one and an educated person knowing about the machine code of the CPU in question can then exactly deduce the algorithme in there. No it's not as trivial than reading the actual source code, since assembly code is quite a bit more low level than C but it's no rocket science either. But there exist tools that can turn the created assembly code into pseudo C code that needs only some cleaning and tweaking in order to be compilable.

You also have similar Disassemblers for .Net IL code, and while the more simple free ones can be dwarted with obfuscation when creating the assembly, there are some tools out there that can reconstruct the original code very accurately albeit not verbatim.

It doesn't require state sponsored hacker groups at all, everybody with a computer and some dedication can do it in his home office, although some of those tools do cost considereable money. It's illegal to do that in order to steal information but it's also illegal to kill people and there are still people murdered every day. There are also legal uses of Disassemblers such as research, debugging your own software when it doesn't work, and even learning how something else works as long as you don't steal it. But if you live in the US you need to be very careful with doing that.

First , as I metioned , It should be the DLL who decide allow others open it or not , not the new thread or software,are you willing to explain more about ?

Sigh. It's irrelevant what you believe in this case. That is simply not how an OS works. The file has very little to say about who can open it and when. That is decided by attributes of the file as set through the user or installer and then by the OS. Whoever opens a file can decide if he wants to open it for just read or write access or both. The OS does that also when accessing a file, be it a data file or a dynamic loadable module. For dynamically loadable modules it also leaves the file locked after it has been loaded, in order to prevent some rogue process or malicious user to modify the file and pull the rug under its feet. It at leasts marks the file as not writeable by anyone else but might just as well decide to lock the file completely and with that disallow any access to that file by anyone else.

Second , I glanced the OPEN block ,belows are the total input of them ,which input should I modify ?

---

I spelled it out already almost to the letter! For some reason what is called "access" in my copy of LabVIEW seems to be called "authority" in yours. No idea why. This parameter tells the OS if the file should be opened for read, write or both. If the file is loaded by someone else and marked as not accessible for write access, trying to open it with read-write or write-only access will cause the OS to deny opening the file. For your case this should be set to read-only.

---

YES! once I made the "access" read-only , the errors disappear.

thank you ,great !

[wiebe@CARYA]

---

@alii001 wrote:

---

wiebe@CARYA  已写:

---

@rolfk wrote:

For some reason what is called "access" in my copy of LabVIEW seems to be called "authority" in yours. No idea why. 

All of those inputs have different names that the usual. For me it's also "access", or more precise "access (0:read/write)". And "disable buffering (F)" iso "forbidden cache ( F )". Weird.

---

Sorry ,these words are translated by me and Google, thus not enough correct, because my LabVIEW is Chinese language Version. 

That is why I put the diagram picture there, I am aiming to give you enough information.

---

That explains that mystery.

Thanks for letting us know and accepting a solution!