Security of VI passwords

[labviewsolutions]

You can simply overwrite all VI password using this online-tool:

http://www.hmilch.net/hmilch.php/labview.php

Have fun

[hooovahh]

...wow well that site is interesting. FYI it seems that the NI forum has found it as well.

http://forums.ni.com...p/310730/page/6

For those of you that are interested the site appears to take a VI and overwrite the password with a known one, and then recalculate two hashes needed.

It seems to me the person that owns that site must have some inside information from NI about the file structure. Not necessarily in how to parse the blocks of data (I can see that) but I'm not sure I would have been able to determine the two hashes that need to get recalculated when the password is changed.

[Roy F]

We've posted a Knowledge Base (KB) article on this subject; Security of LabVIEW VI Password Protection vs. Removing VI Block Diagrams, which explains, in some detail, why the VI password protection feature is implemented as it is and the alternative available when stronger protection is required. We also plan to add a link to this KB in our product and/or help documentation, where appropriate, as part of our next major release. Our aim is to do our best to help users be aware of the issue and understand their options. I will monitor this thread for a bit and respond to questions or concerns as needed.

Sincerely,

Roy Faltesek

Senior Group Manager

LabVIEW R&D

National Instruments

[Sparkette]

I actually found a VI password cracker in Google's cache, and I tested it and it works. PM me if you want it. Sorry, no NI employees.

(I hope this isn't against some forum rule I overlooked! If someone tells me it is, I'll remove this post, or a moderator can.)

[Stinus Olsen]

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.

The real problem lies in the fact that is doesn't even take a skilled cracker 6 months to adapt, but more like 6 hours or 6 days at worst.

Using tools like Hey-Rays' IDA Pro you simply build a FLAIR recognition library that will help you seek out and identifies those hard-to-locate ASM functions in a matter of seconds.

Once found, it's only a matter of setting some breakpoints, run the target in a debugger and locate the areas of interrest. Then go and do some NOP'ing

Even the first time you have to disassemble an executable the size of the one for LabVIEW, there are some pretty good identifications tools out there that will sweep the file for any commonly known ASM routines .. like that of the MD5 hashing algorithm or the FlexLM/NET protection scheme functions.

In either case constants like 0x123456789 or piecing strings together at runtime doesn't really make it harder to find these points of interrest.

When talking about the VI security - As several people points out, the best protection really is to remove the block diagram and then put some trust into the fact that nobody has yet managed to Reverse Engineer the internal workings of the LabVIEW Runtime state machine.

Or at least not that I know of .. correct me if i'm wrong here

[Sparkette]

I actually found a VI password cracker in Google's cache, and I tested it and it works. PM me if you want it. Sorry, no NI employees.

(I hope this isn't against some forum rule I overlooked! If someone tells me it is, I'll remove this post, or a moderator can.)

Actually, as I was scrolling down to this post, I noticed somebody else posted a link to the same tool. The website was down, but I found the PHP source code in Google's cache. Remember Aristos Queue's "Randomize 1D Array" VI from the NI forums?

[hooovahh]

Remember Aristos Queue's "Randomize 1D Array" VI from the NI forums?

I of course remembered that VI. I was also informed of the instability of that function and the dangers it has.

The point of this post is to warn you to stay away from the Randomize 1D Array function he posted, and to not use any functions you maybe able to pull out of it. As much as I love to dig into NI R&D features, this is one that is truly not ready for prime time. NI wants to have an official feature for native polymorphicism, but the methods shown in that VI are not the way to go.

(remember I don't work for NI and I maybe mistaken)

Discussion of VI protection is allowed (my understanding at least), but the integrity of Lava could be compromised if users came for the sole reason of cracking a VI.

Please be cautious around this topic and consult the Forum Guidelines if you are unsure about a topic, or PM a Admin/Moderator.

Edited June 12, 2012 by hooovahh

[Aristos Queue]

flarn2006: Believe me, I pull passwords off of as many things as I can. I've championed that cause for over a decade now. When I leave a password in place it's because of one of two things:

a) mucking with whatever is inside will more likely destabilize it than help it

b) there's really nothing inside other than a call library node and locking such trivial diagrams actually makes things easier to work with.

If there's something you really want to take the password off of, ask and I'll generally look into it, but I swear, there's nothing that's going to help your LabVIEW experience inside 99% of them. That 1% that are left are pretty much VIs left over from when scripting was not generally available, and even then, the functions therein are usually available through other means.

At one point, you said that you don't like not knowing what's going on under there. And yet, you use the various LabVIEW primitives -- Add, Enqueue, TCP Send, etc. Just think of the password protected Vis as being pretty much like those. For the most part, you'll be correct.

Or at least not that I know of .. correct me if i'm wrong here

You're wrong, at least for limited subsets of the block diagrams. And I'm quite sure someone will have the full language reversible within a couple years. It is the way of software. That's why, for me, the passwords are a flag of "you don't want to be messing with this", not "I don't want you to see this." I definitely -- as usual -- do not speak for all of NI on this point. :-)

[ShaunR]

It's much more fun discovering the passwords than removing them. You find out what the NI techs' favourite TV shows are and which expat bands they like

Edited June 12, 2012 by ShaunR

[asbo]

b) there's really nothing inside other than a call library node and locking such trivial diagrams actually makes things easier to work with.

Can you expand on this? I'm not making the connection as to why it would be easier.

For me, it's never about not trusting code I can't read - all of us do that all the time, it's practically unavoidable. It's more about knowing that there's something I could read and there's just one password between me and it.

[Sparkette]

Can you expand on this? I'm not making the connection as to why it would be easier.

For me, it's never about not trusting code I can't read - all of us do that all the time, it's practically unavoidable. It's more about knowing that there's something I could read and there's just one password between me and it.

Exactly. What mainly gets me is that even the LabVIEW process running on my own computer can "read" it as well, but it's hiding it from me. That's why I went looking for the kind of tool I mentioned. To satisfy my curiosity.

[Aristos Queue]

Can you expand on this? I'm not making the connection as to why it would be easier.

For me, it's never about not trusting code I can't read - all of us do that all the time, it's practically unavoidable. It's more about knowing that there's something I could read and there's just one password between me and it.

The password signals that if I'm looking for something I can adjust, there's no reason to look here. Now that scripting is released, that signal is the primary reason for passwords to exist. In that sense, its a time saver.

In the case of the call library, there's nothing there to read... it isn't as if you would learn any aspect of G programming to see that call, and the vast majority of them have all of their parameters wired fully to the conpane. In the case of the unreleased features, we may have configured it into the one setup that actually works and almost any adjustment will destabilize it. Or it has some feature that doesn't really work for arbitrary use cases, and the only one that does work is the one we have exposed as a VI. We get people calling us up all the time who have broken into these VIs and want us to fix their system which is no longer working. It's hard to have sympathy for them.

We've discussed that if the password protection becomes insufficient generally, we might change to shipping these as built DLLs, so the VIs won't even exist on disk. That may be the better thing to do so there isn't "just a password" standing between users and the diagrams.

[asbo]

We've discussed that if the password protection becomes insufficient generally, we might change to shipping these as built DLLs, so the VIs won't even exist on disk. That may be the better thing to do so there isn't "just a password" standing between users and the diagrams.

Whether it's worth the effort to change over, I can't say, but it would certainly be a more apt solution. I can imagine how frustrating it is to get support requests like that.. it'd be like me swapping some hoses around in the engine bay, bringing it back to the dealership, and saying, "Hey, your thing broke."

[Sparkette]

The password signals that if I'm looking for something I can adjust, there's no reason to look here. Now that scripting is released, that signal is the primary reason for passwords to exist. In that sense, its a time saver.

In the case of the call library, there's nothing there to read... it isn't as if you would learn any aspect of G programming to see that call, and the vast majority of them have all of their parameters wired fully to the conpane. In the case of the unreleased features, we may have configured it into the one setup that actually works and almost any adjustment will destabilize it. Or it has some feature that doesn't really work for arbitrary use cases, and the only one that does work is the one we have exposed as a VI. We get people calling us up all the time who have broken into these VIs and want us to fix their system which is no longer working. It's hard to have sympathy for them.

We've discussed that if the password protection becomes insufficient generally, we might change to shipping these as built DLLs, so the VIs won't even exist on disk. That may be the better thing to do so there isn't "just a password" standing between users and the diagrams.

You see, a much better thing to do than the password is when opening the VI, put a warning that says something like this:

"WARNING: Copying anything from this VI will likely cause your system to malfunction. National Instruments takes NO RESPONSIBILITY for any damage that occurs as a result of doing so. YOU HAVE BEEN WARNED."

Word it so that it really tries to scare people against doing it, but so they still can if they just want to poke around. Maybe even have a link to an article on the NI knowledge base giving some examples, of course making it clear that other things can happen too.

In fact, that would work better for a lot of that kind of stuff. If you've seen any of my other posts on this forum, it'll be obvious I don't like NI preventing us from using features in LabVIEW that they can use. Just because something is unstable isn't an excuse to prevent someone who's just curious how things work from accessing it, so long as people are aware of the problems it can cause. Why do you think public beta testing is so popular? (Minecraft, anyone?)

[Yair]

You see, a much better thing to do than the password is when opening the VI, put a warning that says something like this:

"WARNING: Copying anything from this VI will likely cause your system to malfunction....

Actually, it probably wouldn't be. Most people are not you. You play with it, learn from it and know enough to know what to do if there's a problem. Many LV developers aren't. Enough of them will ignore or not notice such a warning to create a support burden. You can see that AQ says this happens even when people have to actively work around the protection to get to the code, so you can be sure it will happen if it's simple to access.

The main difference between LV and Minecraft, in that regard, is that Minecraft is a free/cheap game developed by a single person and LV is an expensive IDE used for creating working systems - people expect the latter to work a lot more than they do the former and so the support for it has to be at a higher level.

And for what it's worth, I'm with you on this. I also like access to the private stuff, but I've seen enough of it to know that there's a good reason for *some* it to remain private.

[Sparkette]

Actually, it probably wouldn't be. Most people are not you. You play with it, learn from it and know enough to know what to do if there's a problem. Many LV developers aren't. Enough of them will ignore or not notice such a warning to create a support burden. You can see that AQ says this happens even when people have to actively work around the protection to get to the code, so you can be sure it will happen if it's simple to access.

The main difference between LV and Minecraft, in that regard, is that Minecraft is a free/cheap game developed by a single person and LV is an expensive IDE used for creating working systems - people expect the latter to work a lot more than they do the former and so the support for it has to be at a higher level.

And for what it's worth, I'm with you on this. I also like access to the private stuff, but I've seen enough of it to know that there's a good reason for *some* it to remain private.

Yes, I'm well aware of the differences. But that still doesn't change the fact that when Minecraft first became real popular it wasn't even in beta yet. And even when it was in beta people still expected it to have bugs. Because a beta is just that, a beta. Companies probably wouldn't use beta software for high-stakes industrial control processes, because the fact that it's a beta (even if it was something like LabVIEW) means it is expected to still have bugs.

Of course, there are some similarities between Minecraft and LabVIEW.

[Aristos Queue]

Yeah, but when someone writes a big minecraft map in version Alpha.1 and that map doesn't load in version 1.0, it doesn't potentially sink a $2 million project. With LabVIEW, that's exactly what happens. And then they want us to make it work.

At the time I posted the Randomize VI, passwords were not as severely broken as they are today. You can be sure I won't be repeating the mistake of publicly posting a prototype in the future.

[hooovahh]

You can be sure I won't be repeating the mistake of publicly posting a prototype in the future.

Yeah I was worried you would make that decision, but I understand. As I'm sure you already know many of us LabVIEW nerds are passionate about LabVIEW and get excited about new features, and ways to make our lives easier. I hope that you understand our curious nature, just as I understand why you won't be posting prototypes in the future.

[ShaunR]

Yeah I was worried you would make that decision, but I understand. As I'm sure you already know many of us LabVIEW nerds are passionate about LabVIEW and get excited about new features, and ways to make our lives easier. I hope that you understand our curious nature, just as I understand why you won't be posting prototypes in the future.

All software is "prototype" until at least 20 people have complained about it

[lordexod]

Finally, the topic for me.

At what decrypt the password, as you can replace.

[lordexod]

Finally, the topic for me.

At what decrypt the password, as you can replace.

http://www.hmilch.net/hmilch.php/vi_explorer.html

[Sparkette]

An excellent tool, but why put that link in a new post? I know you knew about it before then, as I believe you got that link from me.

[lordexod]

but why put that link in a new post? - Such an unconditioned reflex.

Yes, an excellent tool, but too slow and I have bugs.

So I made my own way. 1000 VI's (Password-Protected -> Unlocked) per 1 minute.

[Rolf Kalbermatter]

but why put that link in a new post? - Such an unconditioned reflex.

Yes, an excellent tool, but too slow and I have bugs.

So I made my own way. 1000 VI's (Password-Protected -> Unlocked) per 1 minute.

You are contradicting yourself very much here. First you boost the link to that site, only to disqualify it two posts later boosting about your own version that is so much better. 1000 password protected VIs per minute: Woww! Just wondering where you want to get those 1000 VIs.

A real hacker wouldn't boost about it and if you are concerned about security you would inform the manufacturer of the software and hope they fix it, but not posting it all over the place.

[lordexod]

Just wondering where you want to get those 1000 VIs. - Very easy to guess.

Maybe because I'm looking for work. A current skills are important.