Sparkette

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

On 1/14/2013 at 10:10 PM, ShaunR said:

Well. The adult way to go about it is to furnish NI with the exploit so they have the chance of evaluating whether they want to expend the effort in plugging it before you release it into the public domain. This would allow you to gain a moral position rather than just looking like a petulant script kiddie. Careers have been made this way and the skills are usually prized rather than punished.

 

White hats and black hats come from the same milliners, however they are viewed and treated very differently both in the community and in the law courts.

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.

If you distribute code with the diagram removed, you're locking the users into that version of LabVIEW.  I don't think I'd buy a toolkit that I couldn't use with a newer version of LabVIEW, or couldn't move to a different LabVIEW platform than the one for which it was compiled.  At the very least that would be a significant limitation.  If the password protection makes it possible for companies to sell toolkits and be comfortable that their IP is sufficiently secure without removing the block diagrams, I'm fine with it.

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.

I am kinda with flarn on this one. Nobody should be distributing code with their BD still in place if there is anything inside they do not want others to see. The best password protection in the world does not help when probably quite a few people inside NI can look at the code. What other language would allow this kind of thing?

 

This is a non-feature for me. It irks me that features the developers want are not done, but things like this are.

 

How many on this forum can honestly say this is something they have been severely lacking? What percentage of LabVIEW developers develop libraries that they share with others where they have to contain the BD for portability reasons but still need to have it password protected? 

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?

You'd better hope that NI don't take you to task over the licensing of their closed-source, proprietary software then. (you admitted earlier that you are attempting to breach their licensing conditions )

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.

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

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

Just be aware that doing something like that is truly playing with fire.  flarn2006, I'd appreciate it you add a warning to your post to that effect, just like you did for the first one in this thread.

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

Why don't you write one as you seem to think it is indispensable?

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.

Now we know why there was no time to implement some of the great suggestions on the Idea Exchange 

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.

It is in the help file if you know what you're looking for

http://zone.ni.com/r...pe_descriptors/

See section titled String, Path, and Picture Data Types.

Br, Mike

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.

That's not a worry AQ, I have a couple of minutes spare this weekend to crack the NI License Manager...

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

App.Get Active VI Ref? That one could be useful, Darren.

I made another XNode that should greatly help with selecting coordinates. Place the XNode, which is resizable, and you can click anywhere to select a point. It will then output that point's coordinates as a cluster of two I32 values. If you right-click on it, you will get a menu where you can see the selected coordinates, or replace it with a standard cluster for if you want to distribute your VI without the XNode.

Point Selector Constant.zip

On this LabVIEW Wiki page, the following text can be found:

The capitalization of this chunkname makes sure the code is removed if someone alters the image, thus preventing the creation of malicious snippets.

I aim to show that this is not true. While most programs will remove the code if the image is altered, it's relatively simple to use a free tool called TweakPNG to put any VI into any PNG image.

First, download TweakPNG. Now, create a VI Snippet of whatever you want. I'll be using this as an example:

Run TweakPNG, and you'll see the following:

Next, open your VI Snippet in TweakPNG.

Select the item that's selected in that screenshot ("niVI") and then go to Edit->Export Chunk. Save the file wherever you want; you'll need it later.

Next, open whatever image you want to put the VI into in TweakPNG. I'll be using this image:

You'll see the following:

Once again, click the item I selected ("IEND"), but now go to Edit->Import Chunk. Remember the file you saved earlier? Select that. You'll see this:

Finally, go to File->Save in TweakPNG (or File->Save As if you don't want to overwrite the original image) and you'll now have a VI Snippet with a custom image.

Don't believe me? Here, save this image and drag it into LabVIEW:

I'm not encouraging anyone to make anything malicious as mentioned in the wiki article, but this does have legitimate uses. For instance, you may want to add some extra text to a VI Snippet explaining something, but don't want it to appear when it's dragged into LabVIEW. Or you may want to scale the image down a bit so it will fit somewhere on a web page. I'm sure there are many other uses.

No, I can't post a screenshot. Your curiosity will have to be satisfied with "a certain way we can configure the UI to make controls generic".

EDIT: Yes it is! LabVIEW.ini, "GenericsAreGo=True"

There doesn't seem to be any introduction explaining what this thread is. Is it about objects only placeable via the New VI Object node? Because if so, I made a thread pointing out two of these.

http://lavag.org/top...composevariant/

Does anybody know what these are for? It mentions in the context help that they're for internal experimental use only, and can only be placed via scripting (New VI Object). I'm just kind of surprised that if they are so dangerous (they say "warning: dangerous!" in the style enum list, and they even have skulls on them) that NI would even enable them to be used at all. Not that I don't think they should; it's just not like them. Are these always in the New VI Object Style list, or is it just because I have "SuperSecretPrivateSpecialStuff=True" in my LabVIEW.ini?

BTW, I tried Googling the names of these primitives, and all I got was a thread on this forum containing a list of everything in that Style list.

Lol, this is turning into the original discussion about Randomize 1D Array.

But yeah, I didn't realize that rounded to the nearest integer. I had always thought it just rounded toward 0. I would use , but I would like a universal solution that would work for negative numbers too, even though negative numbers wouldn't come up in that case. I could have it set up so it rounds up if a number is negative, or down if positive (using a case structure or the ever-useful ) but that seems too complicated for a task as simple as generating a random integer between two values—surely there must be a simpler way?

Maybe he's talking about employment by companies other than NI. While NI most likely wouldn't hire someone who breaks their EULA, other companies (especially competitors) would likely have no reason to care.

EDIT: My 69th post.