VI's password

[tst]

Well, you could use an EXE, but even if you could be bothered, it wouldn't help you.

Let's assume that my computer is pretty slow (it is) and that by running on a dedicated server you could get 10,000,000 attempts every second (that's about thirty times faster than my quick benchmark).

At that speed, cracking an 8 letter password, if you assumed only ASCII 32-127 was used, would take close to three years. If you don't know how many letters you have then that time would increase significantly. You could split the workload, but you would need several computers, and I don't think there is any VI that is actually worth it.

I did spend a while once in trying to see if I could analyze the VI itself to narrow down the list of possible characters, but I didn't make any real progress. I do have a friend who's a real cryptographer (he cracked the GSM encryption), so if I ever really wanted to hack the encryption system I would probably go to him for help.

[Conseils]

Well that's the basis of my 15 character selection, as I assumed simialr speeds and a farm of machines.

Now if only the code was worth all this effort

[rolfk]

---

@tst wrote:

I did spend a while once in trying to see if I could analyze the VI itself to narrow down the list of possible characters, but I didn't make any real progress. I do have a friend who's a real cryptographer (he cracked the GSM encryption), so if I ever really wanted to hack the encryption system I would probably go to him for help.

---

This won't be very easy. LabVIEW uses MD5 to calcluate a hash from your password and really only stores this MD5 hash with the VI. MD5 while not a state of the art security hash anymore is not really a reversible algorithme. There are nowadays lookup table attacks for MD5 hashes since there are some limitations in the hash generation and with 128bit length they are in the range of heavy duty hardware systems. But it is not something you could run a joe averages PC and then you also first have to find the 16bytes inside the VI binary data that represent this MD5 hash.

Rolf Kalbermatter

[tst]

---

rolfk wrote:

This won't be very easy. LabVIEW uses MD5 to calcluate a hash from your password and really only stores this MD5 hash with the VI.

---

I suspected as much, which is why I didn't put much effort into this.

---

you also first have to find the 16bytes inside the VI binary data that represent this MD5 hash.

---

This actually seems to be fairly simple (I'm sure you can guess how  ), which is why I gave this method a try in the first place.

[rolfk]

---

@tst wrote:

---

you also first have to find the 16bytes inside the VI binary data that represent this MD5 hash.

---

This actually seems to be fairly simple (I'm sure you can guess how  ), which is why I gave this method a try in the first place.

---

Only if you have the possibility to change the password yourself. But for an already password protected VI this option is not available and the internal VI data structure is rather conplicated so the offset of the different data parts between different VIs won't be the same at all.

Rolf Kalbermatter

[tst]

---

@rolfk wrote:

the offset of the different data parts between different VIs won't be the same at all.

---

I didn't get far enough along to realize that, although I assume that can also be figured out if someone really wanted to.
Thanks.

[MD5 John]

Finding the hash would only take seconds, but you cannot easly reverse it.  One must use long passwords with special characters, less that 7 characters could be broke in a day on a PC.  Of course it's in the same place ( considering version differences ), the program has to locate it to compare to the password you would enter. 

[Ben]

Now now I think we have said quite enough on this topic.

Let us sufice to say that that it is quite secure and is suficient to thwart the attacks of even the most knowledgable amoung us.

BTW

I think the delay was introduced about LV 6.1. I did try the brute force aproach before the delay was introduced but failed due to lack of CPU and time..

Ben

See ya on LAVA

http://forums.lavag.org/forums.html

[rolfk]

---

@MD5 John wrote:
Finding the hash would only take seconds, but you cannot easly reverse it.  One must use long passwords with special characters, less that 7 characters could be broke in a day on a PC.  Of course it's in the same place ( considering version differences ), the program has to locate it to compare to the password you would enter. 

---

That's the nicety of a binary data format. You can structure it however you like and I know for sure that LabVIEW uses a sort of dictionary like format similar to how Macintosh resources are stored. That means the location of specific data is never the same for different VIs and even can change for the same VI due to minimal modifications to it. You have to know what resource you are looking for, then lookup the resource dictonary entry for it and from there lookup the correct data. Without knowing the exact binary format of a LabVIEW VI you can basically forget to find any data other than readable string data inside a LabVIEW binary file.

Rolf Kalbermatter

[MD5 John]

The hash is easy to locate, and is in the same place (considering versions).

I don’t have any interest in posting the information, but it can easy be located in seconds.  So what if you find the hash?  For any long reasonable password, it cannot be reversed period.

If it is you own VI, you could make a list of guesses and possible recover using methods already discussed. 

I was prompted to investigate the VI security for the protection of my own code, I’m confident that it is secure enough for me to sleep at night.   Use a long password with special characters.

Of course the hash cannot be simply replaced with one you know the reverse for that would be no protection at all.  You would have to consider the hash of the password and the program contents, etc…..