Jun 02, 2000 HI Peoples! I have some old VI's from LabView (4.x version). They are protected by a password. How can I open them (crack the password).

SolutionThere is currently no built-in way in LabVIEW to password protect VIs or deployed executables at run-time. Kit Easy Talk Manual more. It is possible to programmatically perform the same operation by having a top-level VI that loads the main program only if a password is passed in correctly. The easiest method uses the Prompt User for Input Express VI. This Express VI prompts the user for a password and passes out a true or false which can be handled as in the example below. It launches the main program if the password matches. Note that this example launches the subVI statically and the ExampleProgram.vi is configured to show its Front Panel at Run-Time.

This method requires the Password VI to remain open while the main VI runs. Additional Information The one downside of using the Prompt User for Input Express VI is that there currently is no way to replace the typed characters with asterisks as is commonly used in password entries.

If this is required, manually set up a top-level VI that handles the string input as seen in the example below. Note that this example loads the ExampleProgram.vi dynamically. This allows the password program to end while the main application runs.

Right click on the string control for the password and select Properties. In the Appearance tab, find the Display Style sub-category and select the Password radio button. This will replace any entered characters with asterisks.

The bit about could not load front panel is probably just their standard error handling. The new anti-tamper mechanism just probably sets some boolean somewhere saying load failed and then the rest happens automatically. Or it could just as well be true! In addition to making the password hash algorithme more complex they could in fact have added some password tamper checks to the opening of a VI altogether. Before the password protection was only checked when you tried to open the diagram, now there might be a check in the VI itself, when opening the front panel, not requesting a password entry but still failing completely for a tampered password, to prevent opening the VI altogether when the password hash is not consistent anymore. I really hope not. We don't really want anything else slowing down opening of VIs.

I have no problem with NI putting whatever security they see fit, as long as it does not impact on the performance of the IDE. Such a check is definitely not any significant cost in comparison to anything else necessary when opening a VI. As it seems, the performance bottleneck currently is in the maintenance of the linked lists that hold the project/library/class information as evidenced by those complains that seem to show a terrible slow down when opening a VI that is part of a several thousand VI hierarchy project in comparison to opening the same hierarchy outside of a project. It's not to surprising as the project needs to maintain dependency information for all the VIs in it and walking those linked list tables takes time and needs to be protected too from concurrent access to avoid inconsistencies. The password tamper check reads a few hundred bytes from the already opened VI resource (LabVIEW needs to open and load that file into memory no matter what) and then does some MD5 and possibly other hash checks on it, and that costs a LOT less time than walking the linked list even a single time for any non trivial project. As to the request for creating a new password cracker: be my guest! I'm not going to spend any time on this, as NI will and does have to modify the password check at least every time they get aware of the availability of such a cracker and even without such knowledge likely will change it every now and then just for the fun of it, to pester whoever may have made such a cracker in private.

I really hope not. We don't really want anything else slowing down opening of VIs. I have no problem with NI putting whatever security they see fit, as long as it does not impact on the performance of the IDE. The new password checking is significantly more complex in terms of what it checks in the comparison. However, the new values that it uses are already known (loaded and/or computed) by that point in load, so the extra time is on the order of tens of microseconds, maybe hundreds of microseconds in particularly complex cases. Disclaimer: this estimate is based on personal knowledge of the change and how it works, not on actual recorded measurements. There are always efforts to improve load time, so I think that any negative effects this had (which is only visible on password protected VIs) are more than compensated for.