Security of VI passwords

[Ton Plomp]

On Stackoverflow someone posted a question on how to recover a VI's password

To my surprise there was a thorough answer containing two methods:

1. Look up the stored MD5 hash in a VI file
   I can understand this, and am not really concerned, this might be a valid method if you know a password is from a given list (choosing a password from a dictionary is dumb anyway).
   
2. Modify the LabVIEW executable binary to ignore the password checking.
   I have not tried this on LabVIEW 2011, but if this works it basically means that passwords are just a sign that says 'Do not trespass'
   

Can anyone verify the LabVIEW edit function in 2011.

On a more general discussion, does this troubles you anyway?

Ton

[Saverio]

There was a follow-up to a 2006 thread made over at the NI forums by the user TorPedoCXC claiming he could crack passwords using his GPU (http://forums.ni.com/t5/LabVIEW/VI-s-password/td-p/310730/highlight/false/page/3). He was basically saying the same thing about the MD5 hash. Maybe it's the same user.

The second method won't work with 2011 since that hex pattern doesn't exist. I checked. I also looked for the method he described in going and searching around a starting offset. No go. Not too surprising since the original was in reference to LabVIEW 8.6.1.

Does it trouble me? No, not really. If it can be cracked it will be. The protection is there to prevent those of us who are just "mundanes" to be able to skirt the protection. Anyone who's determined will get around the protection. Of course, the legal repercussions of doing so are another matter.

[jgcode]

The second method won't work with 2011 since that hex pattern doesn't exist. I checked. I also looked for the method he described in going and searching around a starting offset. No go. Not too surprising since the original was in reference to LabVIEW 8.6.1.

I checked in 2009 and 8.6.1 - with no luck too.

[ShaunR]

The byte sequence will change every re-compile-so it is unlikely to persist exactly as in that post across versions or even the same versions with different bitness. But at some point you have to say "Is it? or Isn't it? a correct password" and finding it is easier if there is a dialogue since you know where to start.

I think most of NIs password protected files are purely to hide the terrible coding. Not that bothered if someone sees mine.

Edited October 6, 2011 by ShaunR

[Yair]

I checked in 2009 and 8.6.1 - with no luck too.

Actually, I can confirm that the basic concept does apply in 2009 and probably in later versions as well. The reason for this is simple - LV needs to access the source code in order to compile it to machine code. Since the user can't be expected to provide the passwords (since, for instance, some of the VIs in the hierarchy were written by someone else) LV needs to be able to read the code even without the password. That means that the code itself can't be encrypted.

Then, as Shaun mentioned, you get a place in the code where you need to check if the user's password matches the VI's password in order to show the BD and if you patch the LV executable to override that check - voila.

In any case, it should be pointed out that other IDEs don't have password protection for source code, at least not as far as I know. I understand why NI put it there, but it should be clear that it's not something you can rely on if you expect to protect your code from someone determined.

[jgcode]

Actually, I can confirm that the basic concept does apply in 2009 and probably in later versions as well...

So how do you hack it then...

[Saverio]

Well, the "hackability" is still there - it's just that the specifics detailed in the reply on Stackoverflow didn't seem to apply directly to LabVIEW 2011. But then I'm not an expert in interpreting assembly language.

Of course, I wonder if NI can sue that poster for providing such details which, to me, seem to be a blatant violation of the license agreement.

[ShaunR]

So how do you hack it then...

Should you really be asking that question?

[Aristos Queue]

but if this works it basically means that passwords are just a sign that says 'Do not trespass'

Yep. The password can't encrypt the diagram. The whole point is that the diagram is still readable so that it can be recompiled. If you want security, you have to save your VIs without diagrams and give up the ability to recompile for different platforms and different LV versions.

You're just lucky no one has build an equivalent of Reflector for LabVIEW. It can regenerate C# source code from the binary compiled DLLs or EXEs, even without the debug info being included.

In the modern world, you have three choices:

• don't share your code in the first place
  
• only give it to users who aren't dedicated to getting into your code or for whom it is cheaper to buy it than to crack it
  
• get a lawyer to enforce your copyright and terms of use. Small claims court is your friend here.
  

Those are your options.

Of course, I wonder if NI can sue that poster for providing such details which, to me, seem to be a blatant violation of the license agreement.

Let's just say his next PXI chasis will be "calibrated differently" and leave it at that.

[Wire Warrior]

Aristos,

Instead of "leave it at that" I think you meant to say "fur-geht abou' dit".

Jason

[Rolf Kalbermatter]

And just to add a bit to it. Even if you find that location where the password is checked, things get a lot more complicated if you take password protected libraries (and maybe classes) into the picture. Those do not use the same code paths to check for password protection and the passwords of each are actually used in the hash of the other.

[asbo]

Instead of "leave it at that" I think you meant to say "fur-geht abou' dit".

My brain tried to process that as German. It didn't go well.

My perspective on passworded diagrams is that they are not for the protection of IP - it's more about keeping developers away from code that's fragile or not ready for public consumption. The true protection for source code is, like AQ said, to remove the diagrams altogether. If it's code which needs cross-version compatibility, you're going to need another copy of the code saved into the other LV version anyway, right? The only thing this truly prevents is ad infinitum cross-version compatibility, but I can justify that as more of safeguard than a restriction.

[Aristos Queue]

> you're going to need another copy of the code saved into the other LV version anyway, right?

Not if you turn on Source Only which allows us to have multiple binary versions for the same source VI.

[hhliliang]

IF this work,NI will cry.

[ShaunR]

IF this work,NI will cry.

Nope, It affects the users more than NI. Ni are probably more worried that their whole licensing scheme has been compromised since 2009.

Edited October 11, 2011 by ShaunR

[Rolf Kalbermatter]

Nope, It affects the users more than NI. Ni are probably more worried that their whole licensing scheme has been compromised since 2009.

Where does the licensing scheme even remotely touch password security of VIs? Anything license related is really handled in the LabVIEW kernel itself so not sure what the ability to unlock a password protected VI would do there.

Following is not directed at you Shaun but at anyone being high in the arms about the insufficient protection password protected VIs give them to protect their oh so precious IP:

Password protection of diagrams is not meant to protect your IP. There exists only one really secure way to protect your IP, and that is to put it in a heavy steel safe, destroy all copies of your idea and dump the safe in the North Pacific above the Mariana Trench. Save of some alian race with super high tech, nobody will be able to get at those secrets. Chances are however high that someone else has already developed the same idea independently and will go to market with it and earn some money with it.

Another slightly less secure means is to hire a whole army of lawyers who will involve anybody into a legal battle who might even just appearing to try to steal that IP, so that they can fight for the rest of their life, robbing them of any time to invest into monetizing the stolen idea.

Both of them are highly unpractical and costly!

Get over it and accept that password protection of diagrams is only to keep out the nosy. If you do need to protect your IP don't distribute the source at all! Bite the bullet and remove at least the diagram. Yes it's inconvenient as such VIs can only be loaded into the LabVIEW version in which it was created and also only on that platform but anything else means LabVIEW has to be able to get at the diagram somehow without knowing the password (or worse yet store the password in the VI somehow too) and that also means that anybody with enough determination will be able to circumvent any kind of protection the LabVIEW developers can come up with to prevent others than LabVIEW itself to get at that diagram.

I think the best long term protection in that respect is actually the semi annual release cycle of LabVIEW as it obsoletes any of the more promising hacking solutions each time.

[ShaunR]

Where does the licensing scheme even remotely touch password security of VIs? Anything license related is really handled in the LabVIEW kernel itself so not sure what the ability to unlock a password protected VI would do there.

I never said it was. I was simply pointing out that NI wouldn't "cry" over a password protection hack and that since the licensing has been compromised; they would be more concerned about that-if at all

Edited October 12, 2011 by ShaunR

[asbo]

Does anybody remember an old DOS program from around 1992? If memory serves me correctly it was called Burp-Cotch-Spit!

Googling that came up with some interesting results... I never used it, but definitely played around with similar tools. I messed around with all sorts of Apogee and 3D Realms games...

[Ton Plomp]

peek and poke on the Commodore 64 after loading the game but before running it!

Ton

[hooovahh]

I'm not a cryptology at all, zero experience what so ever, but I've often mentioned how not secure the password protection method is (despite a few NI employees telling me otherwise). But I'm starting to understand now why it is done the way it is. I thought that the whole VI should be encrypted, making it impossible to find the MD5 of the password in the file. I now know why NI can't do that.

Using a few graphics cards you can get above 3 Billion hashes/second (if you are going the MD5 route). Which would still be pretty secure for passwords 10 characters or greater (which aren't susceptible to dictionary attacks).

But as already mentioned there is the LabVIEW.exe modifications that can take place as well (which are against NI's agreement).

[Rolf Kalbermatter]

But as already mentioned there is the LabVIEW.exe modifications that can take place as well (which are against NI's agreement).

It's a violation of the license agreement indeed, though I doubt a hacker feels much bothered by that .

The other issue is that you need to do disassemble and that is not trivial. It is made extra hard by the sheer size of the LabVIEW executable nowadays. Even a very good disassembler takes a few hours to get a raw disassembly for such a huge executable. And then you can sift through million lines of assembly code to find the places where the MD5 hash is checked. And looking at assembly for even a 100k DLL is already a rather boring job.

The fact that every half year a new executable is released makes the task even more hopeless. So while I'm sure there exist hackers who have hacked one or two versions of LabVIEW to that extend they really won't keep on doing that over the years as the gain of this is minimal. There is very little you can really see from most password protected VIs. Bragging rights don't apply because if someone does that, he might get a cease and desist letter or even worse, signed by the legal department of NI.

I have at some point looked at the possibility to simply modify the VI and that seemed just as hopeless. Especially with VI libraries involved, which contain also a password whose hash is even out in the clear in the library XML code. And those passwords even seem to be interwoven with each other.

As to the licensing. I believe there exist Key generators to fake-license LabVIEW installations. Never mind that most of those key generators have also some stealth load inside, that packs a few viruses and/or troyans on every computer they are executed on. After all why should a hacker who doesn't respect intellectual property respect someones privacy?

[hooovahh]

The fact that every half year a new executable is released makes the task even more hopeless. So while I'm sure there exist hackers who have hacked one or two versions of LabVIEW to that extend they really won't keep on doing that over the years as the gain of this is minimal.

You say that because new executables are released every 6 months, that this would deter the hackers. But then you mention the license generating hacks.

As to the licensing. I believe there exist Key generators to fake-license LabVIEW installations.

And these surely change with every version of LabVIEW released (likely every 6 months). I would be surprised if there didn't exist a license generator for all versions of LabVIEW. I also don't know what techniques the hackers use to create license generators, but from your explanation it sounds like alot of work went into figuring out how to modify this one version of LabVIEW to open VIs with passwords.

I guess the point of this post is that I believe someone out there has the ability to open VIs with passwords, in all versions of LabVIEW. I haven't seen it, but this post leads me to believe that.

If I did find some page on the internet that explains how to hack all versions of LabVIEW, I'm not sure I would post it. Even this thread makes me nervous. Are we spreading the word on hacking LabVIEW, by just talking about it? However not talking about it may give the false sense of security, thinking that LabVIEW is secure when protecting source code.

EDIT: It seems rightfully so, that the page at StackOverflow has been removed.

[ShaunR]

I would be surprised if there didn't exist a license generator for all versions of LabVIEW.

There is.It also activates all the tool-kits and addons.

[Rolf Kalbermatter]

You say that because new executables are released every 6 months, that this would deter the hackers. But then you mention the license generating hacks.

Your reasoning mixes again two rather unrelated things. That of hacking password protected VIs and that of hacking the LabVIEW license. For both you do need to to dig into disassembly if you don't want to go the brute force attack through GPU path, but they are not directly related to each other.

And these surely change with every version of LabVIEW released (likely every 6 months). I would be surprised if there didn't exist a license generator for all versions of LabVIEW. I also don't know what techniques the hackers use to create license generators, but from your explanation it sounds like alot of work went into figuring out how to modify this one version of LabVIEW to open VIs with passwords.

I haven't looked at the details for some time, but from what I saw earlier the license generators you could find were always tied to very specific LabVIEW versions. I think the license technic hasn't changed since about LabVIEW 7.1 so it might be possible to generate a key generator that works across versions, but I don't know.

I guess the point of this post is that I believe someone out there has the ability to open VIs with passwords, in all versions of LabVIEW. I haven't seen it, but this post leads me to believe that.

I'm not sure if there is a single person who knows how to open password protected VIs in all possible LabVIEW versions, but I'm certain there exist people who can open password protected VIs in certain versions of LabVIEW. And they don't work for NI, as NI has of course the ability to work on the source code directly to circumvent such protection.

This means, don't trust your super secret 5 million dollar idea to password secured VIs but also don't expect or require NI to provide such a possibility. It is technically simply not feasable to create a really secure protection without at the same time throwing away the advantage of not having to remove the diagram and making a VI only readable in the specific version and platform it was created in.

[hooovahh]

Your reasoning mixes again two rather unrelated things.

What I was trying to say is hackers adapt every 6 months or so to crack the latest LabVIEW, which makes me think that the same effort could be put into cracking LabVIEW passwords.

This means, don't trust your super secret 5 million dollar idea to password secured VIs but also don't expect or require NI to provide such a possibility.

Well put.