Sparkette

Then I'm afraid I won't be posting it. It's a shame, really, but I really don't want NI's lawyers to go after me. I've seen some posts before about people having lost the password to their own VIs; could I get in trouble if I offered to unlock those for them as a favor? (and then, of course, actually did so?) In that case, I wouldn't be going against anyone's wishes, except maybe NI (though if they just need help with their own IP, I don't see why they would care.)

Exactly. This is purely for fun; it would be idiotic to use this in any important VIs. Here's a tip for editing objects: copy something to the clipboard, and then select BDHP Clipboard or FPHP Clipboard on the left (for block diagram or front panel, respectively) and select the object on the right with an asterisk before its name.

I wouldn't try to make a profit off somebody else's block diagram without their permission, password protected or otherwise, but I don't see anything wrong with messing around with it, as nobody is any worse off than they were before. Also, of course I wouldn't force open someone else's door to look around their house. With a password-protected VI, on the other hand, I'm not doing anything with anyone else's property (intellectual property aside.) Intellectual property is very different from physical property. The latter makes perfect sense, as it can only be in physical possession of one person, and if someone else takes it, they're depriving me of it. The former, however, exists only in the form of information. The idea of a certain sequence of bytes being the possession of one person any more than any other is purely a legal invention. As long as I'm not making a profit, depriving someone of something, or falsely claiming credit, I don't see any moral issues. Back on topic: can I get an answer from an NI employee about what exactly could happen if I post how to bypass the password protection: Obviously I won't want to post it if I could get sued or something, but if not, I'd love to share my findings.

I never said I have any less of a moral obligation to pay as anyone else; just that I don't think a premium membership is worth it. I'm 19; I don't have a steady income yet. Also, the only reason I feel entitled to look at the diagram is because it's in the VI file. If it's on my computer, I feel I have a right to look at it. If LabVIEW didn't have access to the block diagram, I wouldn't necessarily feel I should, but seeing as it's on my computer in an unencrypted form, I see it as fair game. Understand? I'm not trying to "protect" anyone with this hack. Nor is it taking away any protection. By leaving the block diagram in the VI, they are throwing all the details on the street, as you put it.

Well played. I can't say I was aware of that, but I don't think it's a big enough issue to warrant spending $40 per year, especially considering I'm not always active on this forum. Thanks, though.

So I'm aware that OpenG can be downloaded directly from Sourceforge. However, it's not obvious how to actually install it. I would use VI Package Manager, but it won't run on my computer and just crashes. I've had this problem since version 2011. So what I'm asking is has anyone made a guide to install OpenG manually?

Also, even if NI "fixes" this exploit, it's just going to keep getting cracked. If the block diagram isn't encrypted, there's no way to prevent it. And I think it's worth mentioning that I have a strong moral aversion to any kind of "features" like this, where programs are specifically designed to go against the user's wishes. When I see something like that, there's nothing I want more than to find a way around it. (Why is there a time limit for editing posts here? It's simple on every other forum...)

I hacked the Bounds property of an Add node...when you move it you can see it's trying to draw a really wide , but it doesn't seem to be erasing properly. Also, the terminals don't scale with it.

I don't know if anyone else has thought of this, but you know that Heep Peek window? It's mainly used outside of NI for getting rid of insane objects, but another thing it tells you is the addresses of VI objects' data. How is this useful? Well, there's this program called Cheat Engine that lets you edit memory. It's designed for games, and that's what it's mainly used for, but it can also be used for this purpose. Here's a screenshot of the Heap Peek window. See those green boxes I added? Those are the addresses in LabVIEW's memory for the objects. Now in Cheat Engine, you'd target LabVIEW.exe by selecting the computer icon in the upper-left corner, and selecting it from the list. The Memory View button will open a window showing a hex dump, and you can right-click that and select Goto Address to browse to one of these addresses. Now you'll see an editable hex dump of this object's data. The bottom of the Heap Peek window shows the order of the values, and it should be relatively simple to look for those values in the hex dump, but I don't know a surefire way to get the address of any item at the bottom. One thing I managed to do by editing the flags value of a Terminal object is make a constant with a terminal that acted as an input rather than an output. Connecting a control to it and running the VI gave me a broken run arrow, with an error saying LabVIEW needs more memory. If you're wondering how to open the Heap Peek window, just add "LVdebugKeys=true" to the end of LabVIEW.ini. Then relaunch LabVIEW and press Ctrl+Shift+D, then Ctrl+Shift+H. It should go without saying that editing these values is purely for exploration purposes, and should NOT be used in any production VIs. This is definitely not supported by NI, and neither they nor I take any responsibility for anything you may mess up by editing these values. Even more so than Generic VIs, SuperSecretPrivateSpecialStuff, XNodes, or any of that stuff. It is very possible to crash LabVIEW and/or corrupt VI's by editing these values. Here's the VI I mentioned. It contains a numeric constant connected to an indicator with a broken wire. Changing the indicator to a control makes the wire no longer broken, and running it gives a memory error. Obviously dangerous in a production environment, and definitely not supported by NI, so be warned! constant to indicator error.vi

How am I a script kiddie if I found the hack on my own? Also what do you mean the "adult way"? If I was just going to tell NI about it, I wouldn't have gone to the trouble of finding it in the first place. Who would telling NI help? (Other than NI, of course.) Who do you think I'm more interested in helping: a large company that makes millions of dollars from selling expensive software and hardware, or those products' community of users? Again, I'd really like to release this hack, but I'm holding off because I'm not a lawyer, nor do I have a lawyer, and I'm not sure what kind of trouble if any I could get in by doing so. If anyone has any questions about the contents of one of NI's password-protected VI's, of course I'll answer them. EDIT: Really late edit here. (Guess they removed that time limit!) Felt like clarifying something. I'm not being petulant; I am taking a moral position. My moral position puts the wishes of the owner of the device that has information on it above those of the person who created that information. And yes, I would feel the same way even if the roles were reversed. If someone makes a VI, and puts a password on it because they don't want anyone else having access to the block diagram, and someone else obtains that VI and wants access, then in my mind, they ought to have access, despite the creator's wishes. To me, if such a tool is available, that is a moral good. Morals are subjective; just because you don't find something moral doesn't mean no one who does that thing has an adult, morally-based reason for it. It just means they don't have a morally-based reason that you personally find valid. I could just as easily see you as childish for insisting that no one can have any moral reason for doing something you find immoral, without considering others' points of view. I don't think you're being childish though, so don't take that the wrong way.

That still doesn't mean it's smart for them to rely on it. Remember I said I was trying to get past the password protection? I was able to do so by changing only two bytes. As I said before though, I'm not comfortable posting it until I know for a fact I won't get sued.

NI should spread the word on how this password protection works, and maybe do a poll about just how important this anti-feature is to people. It is strange that NI seems to be putting this above things that seem more important to developers... I remember someone posted a LabVIEW.exe mod to disable password protection on Stack Overflow once, but it got removed. (It was for an old version of LabVIEW; wouldn't work in 2012.) If I find a similar modification myself, and post it here, what's the worst that could happen? Could I get sued or anything like that?

Well it's not like I'm trying to make a profit from what I'm doing. Despite what I said before, I'm still not sure about posting what I find if I do figure anything out for that reason, but I can do what I want with my own computer if it doesn't affect anyone else. Think about it like changing a setting, only more complicated: something isn't working the way I want, so I want to change it so it does. I don't see anything to "take me to task" over, as nobody's losing anything.

IMO, what would be best is to just get rid of the password protection entirely for LV 2013. Hell, even put it in 2012 f4. Existing password-protected VIs would just open normally as if there wasn't a password. As for intellectual property, it's their fault for expecting miracles from what is essentially security through obscurity. If they care so much about their precious code, they can just remove the block diagrams, and deal with the side-effects. 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 the block diagram is accessible to LabVIEW, but it doesn't obey the user who wants to view it, that is certainly not user-friendly, and I could even go so far as to classify it as a bug. Though unfortunately I doubt NI will see it my way. Also, does anyone else see the irony in describing a "feature" designed specifically to go against the wishes of the user whose computer it's running on, as a "user-feature"? And how is that not DRM? If I can find a way to remove this P.O.S. code that doesn't belong in any commercial application, I'll do so in a heartbeat. /rant

Uhh...didn't I? In the image? No offense.

Well, I'm messing around with Cheat Engine right now. It's not just for games, you know. I'll let you know if I figure anything out. Also, it's not as simple as it sounds--as I'm sure you know, the hard part isn't just writing the program, but rather figuring out how to crack the password in the first place.

Also, I think I figured out how Aristos made the controls generic. All that's needed in order to select Genericity is to add SuperSecretPrivateSpecialStuff=true to your LabVIEW.ini file.

Good news, everyone! Despite what AQ said about implementing a "revocation" for Generic VI's, they apparently still work in LabVIEW 2012, just as they did before. I doubt all the problems with them have been fixed though, so use the same caution you always have. (Too bad they had to break something else...)

The end doesn't always justify the means, you know. Does anyone know of a password cracker that's compatible with LV 2012? Also, "Could not load front panel" is bullshit and you know it, NI.

They were too busy programming things we'd be better off without.

Tried to open a password protected VI using VI Explorer. Got the following message: No, it's not another user, it's still me! I'd use LabVIEW 2011, but I had uninstalled it, and what if I want to open a VI that uses features unsupported in 2011? I sent the person who wrote it an email. Anyone know of one that works with LabVIEW 2012?

I found one that probably won't be made public, but it's still interesting. Create an Application property node, and then go to Application->Defer Drawing in the menu. Wire a True constant to it, and then click the Run arrow. It will look like it's still running, but it's not. It just didn't update the appearance. Try changing the constant to False, or making some other edit, and it will work, but you won't see it. It's kind of trippy, like as if LabVIEW got drunk or something.

Oh okay, thanks. That type descriptor thing will probably be useful when editing variants. But I'm still kind of disappointed that I didn't discover something that hadn't been released.

I was fooling around with variants earlier by flattening them to strings, editing the bytes, and converting them back, then creating constants from them with scripting. By editing a string variant, I was able to make this: This is a fixed-length string. If I right-click it, it gives me an option called "Set String Length", which isn't there on normal strings. It lets me set fixed, bounded, or variable (which changes it to a regular string and removes the menu option), as well as setting a length. I tried Googling it, and I couldn't find anything about it. I also can't find anything in LabVIEW's help files. Can anyone from NI enlighten me as to what this is for? Is it some kind of hidden data type that's still being tested? I wouldn't find that hard to believe, considering the Set String Length dialog looks like it was quickly thrown together (no offense!) Is this used anywhere, and is there any way to create this other than hacking variants or VI files? EDIT: Found how to do it: preAllocateStringsUIEnabled=True preAllocateUIEnabled=True preAllocateEnabled=True Then the aforementioned menu item will always appear.

I'm pretty sure that's already been done.