kvmfield.blogg.se

Open source is the way to go, and NI shouldn't help people hide their code if those people choose to release it unencrypted.

If they care so much about their precious code, they can just remove the block diagrams, and deal with the side-effects. As for intellectual property, it's their fault for expecting miracles from what is essentially security through obscurity. Existing password-protected VIs would just open normally as if there wasn't a password. IMO, what would be best is to just get rid of the password protection entirely for LV 2013.

If you are having a problem accessing your own VIs due to mutation issues, please contact support. Our own diagrams that we do password protect are much less important than protecting our customers' IP. Off the record, NI put in stronger VI password protection purely as a user-feature, not as some sort of DRM.

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. 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.Īs to the request for creating a new password cracker: be my guest! 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. 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. Such a check is definitely not any significant cost in comparison to anything else necessary when opening a VI. 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. We don't really want anything else slowing down opening of VIs.