LabVIEW and Python - any Python build outputs that LabVIEW can utilize?

[LuminaryKnight]

I'm no Python guru by any means.  But there are things in Python I'd like to use in my LabVIEW code.  So far, I have been feeding source .py files to the Python nodes.  But this approach needs to stop moving forward to protect code from being hacked and reverse engineered. Do the Python nodes run .pyc files?  From what I'm reading, .pyc files are easily reverse compiled back into source.  Anyone know if there are other Python build methods that can still use the Python nodes?  If not, outside of building into an executable you run via CMD line, any other options?  Like building Python into a DLL?

[avogadro5]

There's a lot of discussion on this here https://stackoverflow.com/questions/261638/how-do-i-protect-python-code-from-being-read-by-users

It appears there's nothing you can do except easily reversed obfuscation.

[LuminaryKnight]

---

@avogadro5 wrote:

There's a lot of discussion on this here https://stackoverflow.com/questions/261638/how-do-i-protect-python-code-from-being-read-by-users

It appears there's nothing you can do except easily reversed obfuscation.

---

I been reading up on Cython as a potential option.  Maybe then turn code into DLLs.  Wonder if there's any value there.

[Jay14159265]

---

@LuminaryKnight wrote:

---

@avogadro5 wrote:

There's a lot of discussion on this here https://stackoverflow.com/questions/261638/how-do-i-protect-python-code-from-being-read-by-users

It appears there's nothing you can do except easily reversed obfuscation.

---

I been reading up on Cython as a potential option.  Maybe then turn code into DLLs.  Wonder if there's any value there.

---

If you want to write closed source code, Python should be more to the bottom of the list of languages to use for this. Which python library do you want to use in LabVIEW? 

[rolfk]

It's always the same: 😁

I want to use an easy to use, ubiquitous programming language but I also want to create highly protected and virtually impossible to hack binary executable code.

And the response to that is basically: You can't have the cake and eat it too!

Either you use highly customized build tools that nobody knows about, or you use generic tools and there will be people out there who will hack it easily while being fully blindfolded and with their arms tied on their back! 😁

In terms of security against hackability, compiled LabVIEW code scores pretty high on the list together with C++ with heavy virtual class use. Next are fully compiled procedural languages like C and its brethren. Not as hard with a good disassembler but still a lot of work.

All byte code languages like Java. .Net. Lua, and of course your beloved Python, score extremely bad on that list. That's thanks to the generic byte code architecture, which favors simple, fast to execute and generic execution commands to complex, convoluted and very hard to manage command opcodes. There is no sense in creating an x86/64 convoluted virtual monster clone if you want to have a platform agnostic command execution format.

Obfuscation by replacing the easy to read original symbol names from the source code with generic gibberish, helps a little, and more advanced obfuscators will try to convolute the actually generated code but that can have performance consequences.

JKI did at some point go the obfuscation path even for their VIPM application which is basically a build LabVIEW executable. They replaced all the VI names during build with randomly generated GUID strings. A lot of work and maybe it prevented a programmer or two to take a glimpse at the VIs in there, which have anyhow no diagram and usually no front panel too, and find out that it was for large parts using OpenG Build tool libraries. But I can only imagine the hassle it gave them to go there. And that is not just for the tool to name mangle the VI names during build. But imagine getting error reports with things like "VI 435AB349BFDA5678.vi generated error -23476". Good luck in finding which VI that was when trying to find out what happened and how to fix it! 😁

[LuminaryKnight]

---

@rolfk wrote:

In terms of security against hackability, compiled LabVIEW code scores pretty high on the list together with C++ with heavy virtual class use. Next are fully compiled procedural languages like C and its brethren. Not as hard with a good disassembler but still a lot of work.

---

This is what I say at my job on a regular basis.  The Python users hate anything that isn't Python.  The Text Based developers think LabVIEW is a joke.  And I tell them, if you want to deploy to China and protect your code, LabVIEW is a very solid choice.  They then throw something at me and someone kicks me out of the meeting.