Building exe applications with PPLs without giving away too much

[wwhitley]

In an application I am writing I used the actor framework a lot to build some instrument control and associated UIs. My application was taking time to build (25 mins) so I invested in converting all my AF libs to PPLs to speed up the build process. It took a long time to convert them all, but now the build time of the .exe is about 2 mins. Now my problem is that I see if I build an exe, the PPLs are freely accessible (from the data folder adjacent to the .exe) for someone else to put into LabVIEW and build their own application from. They wouldn't have the block diagrams, but my AF modules are fairly granular so my application could be replicated with some (probably quite a lot of) persistence.

I was hoping for a way to hide the PPLs or include them in the .exe like this suggestion: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Hide-PPLs-in-executable/idi-p/3964358 but it looks like that didn't go anywhere, sadly.

Does anyone have any suggestions for how to build or distribute an exe that uses PPLs in a way that makes the code hard to re-use? I'm in favour of open source generally, but this work is for the company I work at, so I don't want to get in trouble for having distributed the company's property improperly.

[Darren]

It's a trade-off. Either you have a monolithic EXE that hides your program structure, or you have a modular EXE that exposes its external dependencies. I don't know of another way to solve the problem. I'd be curious to hear if anybody else has a suggestion, as I've wondered about this topic as well.

[Kyle97330]

I can think of a few things.  They wouldn't be "super secure", i.e. they'd be in the realm of "security by obscurity".

You'd basically put tiny little "trap" VIs in your packed libraries.  Think... something that sits on an error wire before an important subVI, and runs on the first call but after that only rarely/randomly (to avoid performance hits).  They'd check something about your execution environment, and if it fails, they throw a random error on the wire every time after the failure until it passes, preventing your PPL from working when it detects the issue.  The random error would be vague enough that it wouldn't be obvious what was wrong unless it's you or someone from your company who sees it and knows that it means that your internal authentication failed.

Things that come to mind as things to check

• Named queues cross the "border" between the environment inside a packed library and outside of it.  You can do things like trying to get a reference to a very specifically named queue with the option to "create if not found" set to False, and if it can't find it then the error comes up.  You then add something to your main EXE startup that creates and preserves a queue with that name the entire time it runs.
  • (Remember to close but not destroy the reference you do get if successful...)
• Have your main VI open a TCP port to listen on.  Your packed library "trap" VI either tries to check to see if it can connect to that port, or it tries to open its own listener on that port and if it fails then it knows that your main EXE is already running.
  
  • Closing the port or connection immediately afterwards, of course.

There's probably a few more things you could check besides those.  I'm guessing you will need to run these on PCs outside your organization, but if not you could also add specific checks that would only pass inside your organization, such as checking the domain membership of the PC.

[BertMcMahan]

It would be nice to get that idea exchange entry re-opened since it was declined due to NXG.

[Darren]

---

@BertMcMahan wrote:

It would be nice to get that idea exchange entry re-opened since it was declined due to NXG.

---

Done. Kudo away!

[BertMcMahan]

Much appreciated, thanks!

...Unfortunately I still can't kudo it. Can someone else see if they can? It says "New" but when I try to kudo it, I get a little red X and a tip strip that says "This idea cannot receive kudos."

[Darren]

Sorry about that, I forgot that I have to both re-open the idea *and* unfreeze kudos. Try again.

[BertMcMahan]

That did it, thanks again!

[wiebe@CARYA]

---

@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.

[BertMcMahan]

---

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, 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.