LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

remove password protection

I want to make some modification to the diagram of a VI which I forgot the password. I went in the VI properties->security and tried either to switch to no password or change the password but LabVIEW prompt me to enter the last password that I forgot. Is there a solution?. Otherwise I will to rewrite all the vi form the scratch.
0 Kudos
Message 1 of 42
(24,028 Views)
There is no solution. Not even NI will be able to help you. You will have to rewrite the VI.
0 Kudos
Message 2 of 42
(24,020 Views)
A solution for the future is to make backup copies of all source code and install kits for each version release.
~~~~~~~~~~~~~~~~~~~~~~~~~~
"It’s the questions that drive us.”
~~~~~~~~~~~~~~~~~~~~~~~~~~
0 Kudos
Message 3 of 42
(24,013 Views)
The solution is a brute force attack. Open a VI reference to the VI with the unknown password. Use the Invoke Node "Set lock state". You have to give the old password. Make a loop around it and generate all possible strings each character from \0 to \FF. Try it until the Invoke node returns no error. I tried this with a VI with a password of length 1. I don't have any experience if the password is lengthier how the runtime will increase.
Waldemar

Using 7.1.1, 8.5.1, 8.6.1, 2009 on XP and RT
Don't forget to give Kudos to good answers and/or questions
Message 4 of 42
(23,977 Views)
In case anyone is alarmed at Waldemar's proposition, I report that my LabVIEW takes around 100 ms for one unsuccessful "Set lock state" attempt. Even with a reduced valid character set of around 75, it will take my poor computer 4,000,000 years to crack an 8-character password!

Probably not a problem for the folks at NSA, but I am fairly comfortable that no armchair LabVIEW hacker is going to brute-force his/her way into my password-protected VIs (if I had any password-protected VIs). Anyone using short passwords should definitely change their ways, though.

--John
Message 5 of 42
(23,958 Views)
Dear John,

I think I made the test with LV 6.0.2. I used 'A' as password since I didn't want to implement the full code. I felt that the runtime was below the expected 6,500 ms from your measurement. If you did it with a newer version maybe NI was aware of this solution and implemented a wait if "Set Lock State" fails.

For explanation:
We maintain a library and we have password protected VIs. We need to have the block diagram in the LLB to allow the customers to convert it to the LV version they have. We need not to maintain the LLB for each LV version. I wrote a VI moving all the VI's into the LLB and setting a password. I was interested what chance is to get the password or unlock the VIs. So I wrote the 'A' test. I also tried to find out where the password is located in the VI I gave up after an hour looking in a hex editor at three VIs. One unlocked and the other two with a single character password. In this short time I couldn't find anything to locate the password and at least its length. All VIs were empty, really empty. Nothing on the FP and nothing on the BD.

If you take my results and that of John together Dennis is right, no solution.

Message Edited by waldemar.hersacher on 03-12-2005 10:43 AM

Message Edited by waldemar.hersacher on 03-12-2005 10:43 AM

Waldemar

Using 7.1.1, 8.5.1, 8.6.1, 2009 on XP and RT
Don't forget to give Kudos to good answers and/or questions
Message 6 of 42
(23,944 Views)
Still such a VI could be useful if the original poster has a relatively short list of possible passwords and permutations (e.g. I vaguely remember that the password was either some kind of fruit plus a 2digit number, or a river in South America with all "o"s replaced by zeroes, etc. ;)).
Message 7 of 42
(23,917 Views)
There is no way to locate the password in any way from a VI. The password is stored as an MD5 encoded string of the original password and there is no other way than a brute force attack to find the original password from an MD5 encoded string. I think that MD5 isn't exactly state of the art anymore but the biggest problem in passwords is usually more on the user side, such as poorly chosen passwords which are easily cracked with dictionary attacks.

Rolf Kalbermatter
Rolf Kalbermatter
My Blog
Message 8 of 42
(23,905 Views)

Please correct me, 

 

-The diagram is not encrypted

 

- It's the password that is encrypted

 

-It's LabVIEW  that doesn't allow you to see the diagram

 

=>   If you wan't to 'crack' a password protected vi, don't lock into the stored vi, look into LabVIEW. (What you don't do, because you have accepted the EULA 😉  

Old thread here

 

 

 

Greetings from Germany
Henrik

LV since v3.1

“ground” is a convenient fantasy

'˙˙˙˙uıɐƃɐ lɐıp puɐ °06 ǝuoɥd ɹnoʎ uɹnʇ ǝsɐǝld 'ʎɹɐuıƃɐɯı sı pǝlɐıp ǝʌɐɥ noʎ ɹǝqɯnu ǝɥʇ'


0 Kudos
Message 9 of 42
(23,115 Views)

Henrik Volkers wrote:

 

=>   If you wan't to 'crack' a password protected vi, don't lock into the stored vi, look into LabVIEW. (What you don't do, because you have accepted the EULA 😉  

Old thread here

 


In theory! In practice the VI data structures are very different on file than in memory. So there is little you can do by peeking at the memory. The whole diagram is stored as a directed graph and its format is both absolutely binary and completely undocumented so there is little you can gain there.

 

It's not to say that nobody might be able to crack it but it is very unlikely and a LOT of work to do so, and the benefit is quite limited.

 

Rolf Kalbermatter

Rolf Kalbermatter
My Blog
0 Kudos
Message 10 of 42
(23,104 Views)