74 replies to this topic

[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:

• 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).
  
• 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...ht/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 by ShaunR, 06 October 2011 - 02:58 PM.

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

[WireWarrior]

Aristos,

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

Jason

[rolfk]

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 by ShaunR, 11 October 2011 - 12:36 PM.

[rolfk]

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 by ShaunR, 12 October 2011 - 12:01 PM.

[neil]

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

The purpose was to allow the user to directly modify executables (mostly .exe and .com) so that you could get infinite lives in computer games etc. This worked by changing the compiled instructions so that the crucial bits of code (say the jump to game over when all lives were gone) were NOP'd out or similar. The trick was knowing which bits to change!

Good times...

This is (I think) the same technique described by the original poster, except a modern Windows executable is a lot more complicated than a DOS app from 1992. If you know where to modify the exe (and checksums if necessary) it is entirely do-able. Not east though...

[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