Best practice to prevent to stolen ignition resources

I mean most of websites javascript’s only “security agaisnt theft” is bassicaly changing all variable and function names to incomprehensible letters and removing all formatting (space and tabs) xd As there isnt much else you can do since the browser on the client need to be able to run it

This obscurity model is no match for someone like @pturmel though

4 Likes

I mean getting the formatting back should be doable with a script…
But the names? Debugging a code with bad naming is so hard, good luck reverse enginering one xd
The problem is also it uses the same name multiple times if its out of its “scope”

The only way for Microsoft to make something that doesn’t suck would be for them to start making vacuum cleaners…

3 Likes

Compressing JS also give a slightly less download for each user, but we’re probably talking a few hundred of bytes on a normal JS file and a few kB for large scripts.

1 Like
5 Likes

Nice! I’m going to start writing all my code like that from now on :slight_smile: My co-workers will love it

1 Like

Check and see if Ignition has support for Brainf**k coding :smiley:

Rockstar would be much more fun in coding reviews.

@nader.chinichian
What did you end up doing?

Did you find a way to do encryption?
Or how did you secure your developments?

Holy cow, someone had far too much time on their hands with that language :joy:

Unfortunately, nothing you can do except some Intellectual property rights documents at your source or views.
It is something we talk about with IA and if they see there are quite a few people asking for it, they will do that.
As you see in this thread no one supports this concept!!!

1 Like

For resources going to a browser, it is entirely pointless. If the browser can run or render it, the obscuration can be undone (mostly). Lot's of tools in security research space for this, specifically to figure out what malware is doing.

For resources your client will run, same issue, just not in a browser. Even 3rd-party java modules--the highest level of IP protection available in the Ignition world--can be decompiled by any modern development environment.

I can understand IA's unwillingness to offer illusory protections. If only to avoid being targeted by angry developers when one of their "protected" resources is deobscured/decompiled.

10 Likes

What we need to encrypt mostly in script, binding, and component properties. I know every CSS, js, HTML can seem in Browser but it is not possible for other dev to get your resource as your resources are Python code that is running on the server side.

By the way, the cracking process is costly and it is not wise for other people to invest in that for such low-cost resources. They simply buy it.

What I saying here is done by other platforms already.

Another topic is source control of the Ignition resources in such Github, which encrypting may break it. But the important note here is we want to sell resources as the black box so there is no need to use it.
In develop phase of the resource in my office I simply turn encryption off and use resource control tools.

1 Like

What platform(s) are you referring to and what exactly are they claiming?

Wonderware Edge( indusoft), Yokogawa Fasttools, ABB 800xa,...

They offer to encrypted the resource by right click on it and select encrypt and ask a password.
Now your resource is run in client side.
And when you want to edit it or see the code double click to open it ask you password to decrypt it.

Even Microsoft Excel has this option for macros

This is just obfuscation.

If the resource is encrypted, then the runtime (Ignition Gateway, or whatever other software package we're talking about) must be able to decrypt it in order to understand/interpret it.

If the runtime can decrypt it, the password is stored in the runtime somewhere. Which means anybody with the means to poke around can find that password and decrypt it themselves.

5 Likes

Oh I thought you were talking about things that ran in a browser. But regardless exactly what @Kevin.Herron just said.

The only real security (in my naïve opinion) is network security and making sure only computers and users you explicitly want to have access to these projects has access (and everything that goes along with that). If your project is out on the internet for anyone, malicious parties with nothing better todo will poke around if they think there's potential for some ransomware.

The best security for now is to create really bad projects :joy:

9 Likes

I'm sure there a method to protect even runtime.
In any case it is not even easy task to hack for most people and other guys that can do that request money so at the end the end user is Williston buy it instead do the cracking.

1 Like