LabVIEW
Building exe applications with PPLs without giving away too much
@BertMcMahan wrote:
wiebe@CARYA wrote:
@BertMcMahan wrote:
It would be nice to get that idea exchange entry re-opened since it was declined due to NXG.
That 1st idea comment mentions NXG had plans to sign the modules:
"As such, the decision is that we will at some point add the ability to sign compiled modules for LabVIEW NXG."
Signing has a completely different use case.
Signing would allow detecting modification of PPLs used in an exe, but it would not prevent others from using the PPL.
You'd have to encrypt the PPL to make it a little harder to use the PPL. But there simply isn't a way to completely prevent it. It's exactly the same scenario as PW protecting VI diagrams:
A (exe\LV) needs access to B (PPL\BD), while A (exe\LV) is available, C (someone else) can get access to B (PPL\BD)too.
Preventing this is just obfuscation, unless you run the decryption through a remote server. That would make it harder, but not more than that.
The OP of this post and the idea exchange entry were both to just embed the PPL into the exe,
Yes, but it quickly turned into signing ppls in NXG (and that it was never going to happen in CG).
Now that the idea is back on, it seems to me that iff something is going to happen, it will be that ppls can be signed.
@BertMcMahan wrote:
making it basically act like an exe today does with regular VI's (i.e., you can't get at VI's once they're inside an exe, as far as I know- at least, not easily). I'm not familiar with signing code so I can't speak to that.
Why not use a .vilib then?
PPLs would be a bit faster during development (loading, compiling), but if you don't want an external API, you can sacrifice that benefit...
Search LabVIEW like a graph! 
@BertMcMahan wrote:
The OP of this post and the idea exchange entry were both to just embed the PPL into the exe, making it basically act like an exe today does with regular VI's (i.e., you can't get at VI's once they're inside an exe, as far as I know- at least, not easily).
You definitely can. But it is indeed not trivial. The VIs in the exe do normally not include a diagram (unless the exe was compiled for debugging) but it's possible to extract the VI names if you really feel that gives you some information. And there are people who tried to extract some of the information from even diagram less VIs and they did get to some results. It's however several magnitudes more obscure and complicated than disassembling normal DLLs, and that is more complex than disassembling .Net assemblies.
I'm not familiar with signing code so I can't speak to that.
Signing does nothing to hide or obscure content. It's purely meant to provide a method to verify that the signed document (text or also a binary executable) is still the same as when it was signed by the original authority. Basically as long as the private key of the certificate used to sign that document has not been preached, you can verify that the signature in the file was indeed generated by the authority whose certificate was used to sign it AND that there were no material or other changes to the document since that point. It does not guarantee that the original authority has no maleficent intends nor is it meant to hide (encrypt) anything in the document. That would be a seperate step before the document is signed but in the case of a LabVIEW program it is impossible to do in a way that can not easily be circumvented. The LabVIEW runtime and/or OS needs to be able to retrieve the code without prompting the user every time for a decryption key. And once you give out such a decryption key to let them use your software others can get it in their hands too, even if the encryption is made super complicated.
