Ni Labview vim files cannot password protection, Is any other method to protect .vim files?

[JeanCao]

Our development team report, we used NI Labview 2022 Q3, When we used .vim library and created new .vim file, then we cannot do password protection. when we do password proword protection. Have other team has the same issue or Ni change Vi password protection method?

Please let me know.

Thanks,

Jean Cao

[santo_13]

I don't think vim can be password protected. If the code is shared within the org, password protection seem to be too restrictive, instead you can make it read-only, so, no accidental save occurs.

[wiebe@CARYA]

The error is quite clear about password protected vims:

It's a bit of a farce, as LV can obviously access the diagram of PW protected, for instance to recompile it for newer versions or if a subVI's CP's changes.

I think the problem is that to modify the diagram on this level, a VIServer reference is needed and when there is a reference, that's a way in for others (there is, it's not hard)... So the PW protection is on obtaining a diagram reference, which is needed for .vims.

[JeanCao]

This answer is not real what we want. Our dev team still like to have some kind of protection for the vim file for security reason and protection for engineering work.

[Kyle97330]

VIM files don't supply any run-time functionality on their own that a regular VI can't.  All they do is that during compile time, they internally adapt to data types passed in automatically and may change the data types they pass out as a result.

So if you absolutely must have a password on every VI with no exceptions, then you can't use VIMs directly.  You have 3 alternatives:

1. Stop using VIMs completely.

2. Change all VIMs to polymorphic VIs.  You will have to construct each instance of this separately.

3. Whenever you place a VIM, right-click it and choose "Convert Instance VI to Standard VI", add a password to that standard VI, and then save it.

[raphschru]

4. Have your VIM call a non-malleable password-protected core subVI that does all the "sensitive" work. Then your VIM is just a basic wrapper for edit-time data type adaptation, which is rarely something crazy that would require password protection IMO.

[wiebe@CARYA]

---

@JeanCao wrote:

This answer is not real what we want. Our dev team still like to have some kind of protection for the vim file for security reason and protection for engineering work.

---

Heads up: this is also not the answer you want 😁.

To paraphrase @rolfk: A VI's password is like a door lock. It tells people it's not legal to enter, but it doesn't prevent people from getting in if they really want to.

I think you have to wait for quantum computers to be a household item. Maybe then we'd be able to supply software encrypted on a per user level in a way it's not reversible. I doubt it though.

You can put a sequence structure around all the code. Then binary modify the BD Heap so the sequence is either hidden or it's diagram coordinates don't match the coordinates.

I did that 15 years ago. Since then the heap format changed, the VI's (PW) hashes changed. Even then, it would work, except on a German version of LabVIEW... So expect complications.

And of course this is 'easily' reversible (, like a VI's password)...

Or refactor the .vims with polymorphic VIs...

Or use variants in normal PW protected VIs.

Or deliver compiled code (no .vims though).

Or use another language that does offer IP protection.  Let us know if you find one...(Spoiler: if the CPU understands it WE can understand it).

[Andrey_Dmitriev]

---

wiebe@CARYA wrote:

---

@JeanCao wrote:

This answer is not real what we want. Our dev team still like to have some kind of protection for the vim file for security reason and protection for engineering work.

---

Heads up: this is also not the answer you want 😁.

To paraphrase @rolfk: A VI's password is like a door lock. It tells people it's not legal to enter, but it doesn't prevent people from getting in if they really want to.

...

Or refactor the .vims with polymorphic VIs...

Or use variants in normal PW protected VIs.

Or deliver compiled code (no .vims though).

Or use another language that does offer IP protection.  Let us know if you find one...(Spoiler: if the CPU understands it WE can understand it).

---

... or not using password protection at all. Lets imagine our ideal world without any secrets, where everything is open source and available to everyone. But in general password protection is almost nothing, the only way to hide the code is to remove block diagrams completely, then reverse engineering will be a little bit more complicated (but impossible is nothing).

[rolfk]

---

wiebe@CARYA wrote:

---

Or use another language that does offer IP protection.  Let us know if you find one...(Spoiler: if the CPU understands it WE can understand it).

---

More correctly: If the CPU can read it, which is a requirement for executable code, we can read it too. It may be assembly code but I consider assembly code easier to understand than LabVIEW binary graph data.

[Andrey_Dmitriev]

---

@rolfk wrote:

---

wiebe@CARYA wrote:

---

Or use another language that does offer IP protection.  Let us know if you find one...(Spoiler: if the CPU understands it WE can understand it).

---

More correctly: If the CPU can read it, which is a requirement for executable code, we can read it too. It may be assembly code but I consider assembly code easier to understand than LabVIEW binary graph data.

---

I've disassembled binary code from LabVIEW's VIs several times using Ghidra or IDA Disassembler (from DLL, generated from LabVIEW as well as from code chunks), and it is not so easy to understand, some cycles or conditions could be recognized, but overall logic is relative hard to understand. In theory we can collect some "patterns" and reconstruct original code from binary (may be with help of pre-trained AI), but also with trivial C language, which is compiled to compact machine code it is not always possible to recover original code back due to several reasons. LabVIEW-generated machine code contains lot of "overhead" instructions, which make understanding slightly more complicated. Also explored execution under debuggers (WinDBG and x64dbg) and here also some LabVIEW-specific points, like dynamically created threads, which adding some additional complexity to reverse engineering procedures.