LabVIEW
Ni Labview vim files cannot password protection, Is any other method to protect .vim files?
@Andrey_Dmitriev wrote:
@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.
I was a bit brief in my explanation. With LabVIEW graph data I meant the binary heap data in the VI describing the diagram as a directed graph. While that is in itself not really rocket science it is simply nowhere documented outside of NI and hence pretty hard to make any sense of. This used to be a LabVIEW representation that was directly transformed into machine code with limited optimization options, although the LabVIEW compiler was even then amazingly good. Nowadays it is in DFIR and that gets massaged for various optimizations and other reasons into the final, logically often more complex DFIR representation that is then handed of to the LLVM compiler backend to turn into machine code. And yes this part is fairly complex and the generated code is often hard to recognize from the original diagram. LLVM itself does various transformations too, as more complex assembly instruction sequences can be faster on modern CPUs than a single special purpose operation, due to pipeline stalling and other multicore features of nowadays CPUs.
I wasn't referring to the actual machine code generated by LabVIEW actually, as I never tried to really look at that, but expect it to be rather involved and difficult to interpret.
What I meant was all those people claiming that LabVIEW password protection was a joke and real world software using a C compiler was much more secure. It isn't, as most of that code can be fairly easily reconstructed from the disassembly code. C++ software tends to be more difficult since the execution flow is not as clear and most code is indirectly referenced through class method tables and following the code flow that way is pretty cumbersome to rather difficult to do. If someone believes that C# code is any securer than a LabVIEW diagram, they should go and read the Microsoft specification. The actual virtual CPU that the .Net engine uses to execute IL code is trivial to intercept and unless you use highly advanced obfuscators the actual IL code in an assembly is nearly 1 to 1 translatable back to C#, although you may loose original symbol names, depending how much the assembly was stripped during build.
Basically, the most cumbersome (but by far not secure) code is from compiled C++ code, then comes compiled C code and C# without some advanced obfuscators has pretty much no obscurity even in the compiled code.
@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.
Sure. It's an abstraction that could (with enough effort) be extracted, either automatically or manually.
It's not security...
I've never found a compiled LV application that had IP so interesting I had to look in the compiled assembler code. There are easier ways to understand what a LV program is doing.
But at some point in time some hacker somewhere might just make something, just for the fun of it (that is what hackers do).
Search LabVIEW like a graph! 
