I removed Block Diagram from a VI. Is it all I have to do to protect my IP and hide sensitive data?

[smidsy]

Hi,

I would like to implement a Run-time license checking mechanism that will enable or disable some parts of my LabVIEW API depending on a license status. 

After reading numerous discussions here on the forum (We need a new password cracker :( , Low level VI data editor (warning: not for production use!) , I found some more hidden INI keys, Password Security in LabVIEW) I realised few things:

- reverse engineering in a LabVIEW-related field seems to be a doable task for some smart people, 

- password protection on block diagrams does not protect your IP, it is more of a "read-only" or a "private property" sign,

- removing block diagrams or compiling it into an executable are the ways to go, and finally,

- there are few tools out there, that seem to have a potential to "unflatten" VI data and modify/extract its data even without block diagrams.

 

Back to my task. I decided to remove block diagrams. Inside my protected VI I call an external library that does the actual license checking. So the code only gets this status and returns it back to other VIs. Then the VIs do not perform their main functions, and the user gets an error. 

Do you think I am safe here?

Is it possible to extract sensitive string information out of my VIs (without BD)?

Is there a way to change wiring rules/connector pane on my VIs?

Should I worry about DLL hijacking? 

Does NI have some kind of a tutorial for protecting your run-time API? 

How do you protect your API knowing all that? Do you sleep well?

Thanks

 

 

[smithd]

I think if we've learned anything in the past few decades, its that a dedicated attacker can do a lot. I tend to think a password is sufficient -- those people looking for passwords are either:

• Looking because they have a legitimate reason like they locked themselves out
• Were never going to pay for it anyway

So while I don't know your particular market or customers, I wouldn't generally lose sleep over it.

As to the specific question, this may help:

http://digital.ni.com/public.nsf/allkb/831F38C46BCBDADE8625793A0054BB19

It sounds like removing diagrams should be sufficient in line, with the only additional comment I have being that you should remove front panels for any code which may have sensitive data on it -- for example, a license key which gets passed to a function. If someone manages to get that function to open its front panel, I believe its possible to extract the data.

[hooovahh]

Most front panels are removed automatically when building an EXE or DLL.  I'm unsure of what the rules are but basically if the VI doesn't have settings to show it then they are removed.

Password protecting the VIs seems to be sufficient for most tools network developers, but yes there is a risk of cracking them open.  But even removing block diagrams and front panels, doesn't mean the VI can't be called similar to a compiled DLL.  You might not know what is going on inside but it can be called with inputs and an output be returned.  It may also be possible to load a VI of the same name in memory and have your functions link to the new one (assuming they aren't in libraries or classes).  Protecting LabVIEW IP is a tricky one for sure.  Even things like code obstruficators are rendered useless with block diagram cleanup most of the time.

[infinitenothing]

The bad news is that DRM is fundamentally flawed. A dedicated hacker would probably modify your DLL/object code and "wire" a true constant to your case structure that enables the functionality.

Your best DRM is probably a team of rabid lawyers .

Have you seen the third party licensing toolkit?

Regarding sensitive string, no, that's never totally safe.

Edited November 21, 2017 by infinitenothing

[smidsy]

23 hours ago, smithd said:

Looking because they have a legitimate reason like they locked themselves out

Yes, I agree, if something isn't right with a third-party toolkit, and you need to fix it quickly, you would probably want to look inside instead of exchanging emails with a support team. An then you open the block diagram with your favourite password cracker and realize, that the paid toolkit code is ugly and dirty, and you can definitely make it better. You copy and paste (or just take some ideas from the code), adjust it here and there, and reuse. It is not that bad in general, but my boss would not be happy 

 

23 hours ago, smithd said:

you should remove front panels for any code which may have sensitive data on it

Good point. Not sure that this is enough though. Will inlining make it more secure? Does inlining dll nodes force a host VI to be running in UI thread? 

 

22 hours ago, hooovahh said:

It may also be possible to load a VI of the same name in memory and have your functions link to the new one

Interesting! It is kind of a game without knowing the rules.  You don't know what to expect, so it is better to be prepared for everything. So I will come to my boss and will say to him that we will put the licensing check into a private class method with inlining with no block diagram and with no front panel with a name like "get last user string" or even better "general error handler" and we put it into a dll and wrap it into dvr and do not forget pack into packed library but even if we do this there is still no warranty that we missed something trivial and well known by LabVIEW community

Or maybe we should just put a password on our block diagram...

21 hours ago, infinitenothing said:

A dedicated hacker would probably modify your DLL/object code and "wire" a true constant to your case structure that enables the functionality.

Yes, exactly. So we may build huge walls and forget about the roof. What are the measures against this? DLL signing, hash digest or similar? I am a noob here, sorry

 

21 hours ago, infinitenothing said:

Have you seen the third party licensing toolkit?

 

Yes, I tried it with a normal password protected VIs. Not sure if it supports VIs with removed BD. Will check this.

 

[infinitenothing]

Hash digest? That's just another equal sign to change right?

Or they could license it on a virtual machine appliance and distribute the appliance right? Or install it on a server, wrap it in a TCP interface and make it accessible over the network.

Go through my links. If you really want to protect something it has to be running on your physically secured hardware. Everything else is just obfuscation.

If you just want to make it challenging to hack, then you've probably done enough by removing the FP and BD and using the TPLAT. It's hard to give more specific advice without understanding the code better.

Edited November 21, 2017 by infinitenothing