We need a new password cracker :-(

[Sparkette]

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?

Edited January 13, 2013 by flarn2006

[Sparkette]

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.

[Sparkette]

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.

Edited January 13, 2013 by flarn2006

[Rolf Kalbermatter]

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.

[ShaunR]

We need a new password cracker :-(

 

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

[Rolf Kalbermatter]

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.

[Mr Mike]

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.

 

Edit: I'm not 100% sure this check only happens on password protected VIs, so I'm redacting that part of the statement

[Rolf Kalbermatter]

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?

 

The person who wrote that cracker definitely had inside knowledge about the LabVIEW sources. I doubt he still works in a position that would allow him such access to checkout how the changed password check is done, so it is rather unlikely that he will be able to "fix" it.

[ShaunR]

but somewhere, deep deep down in the loading routine of LabVIEW.exe is a branch instruction that allows or denies this.

Softice is the tool of choice. However. There are easier ways that don't require "cracking" the file or finding the "branch".

It's a bit of a moot point with regards to LV though. Most of the time it's just used to prevent critisism of messy diagrams and there are no real secrets hidden. If IP is the problem it's buried in the exe. So apart from the exercise or the challenge, there isn't a lot of point in cracking diagrams. You're better off spending the time going out and getting laid.

Edited January 14, 2013 by ShaunR

[Sparkette]

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.

Edited January 14, 2013 by flarn2006

[Djed]

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.

[Sparkette]

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

Edited January 14, 2013 by flarn2006

[ShaunR]

IMO, what would be best is to just get rid of the password protection entirely in LV 2013. 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 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.

/rant

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 )

Edited January 14, 2013 by ShaunR

[Sparkette]

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.

Edited January 14, 2013 by flarn2006

[Sparkette]

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?

Edited January 14, 2013 by flarn2006

[Rolf Kalbermatter]

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? 

 

Well, in all other languages you have only the choice to distribute the source code or binary compiled files, although .Net binary code is easily decompiled into very readable C# code if the creator didn't put it through an obfuscator and for most obfuscators there exist pretty good working deobfuscators already too.

 

LabVIEW is not much different, except that it adds an extra password protection option, which is a bit between those two extremes. Obfuscation of the binary code is so far useless since there doesn't exist any working decompiler so far, unlike for .Net bytecode or CPU assembly codes. So you can say what you want, and correctly state that the password protection is not an ideal solution for a very sensitive code, however any form of distribution of that code will pose a certain risk and I would consider compiled C code not much more secure than a password protected LabVIEW diagram, and definitely less secure than a diagram removed LabVIEW VI.

 

Does that entitle you to claim that password protection is unrightful and wrong? By no means!

And does that opinion entitle you to try to circumvent that protection? In most western juridications in no way legally and morally you have to decide yourself! However your decision will certainly have influence on your professional merits.

[ned]

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?

 

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.

[Sparkette]

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.

[ShaunR]

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.

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.

Edited January 15, 2013 by ShaunR

[Sparkette]

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.

Edited January 21, 2019 by flarn2006

[Sparkette]

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...)

Edited January 15, 2013 by flarn2006

[Antoine Chalons]

I found a hack to remove the time limit to edit your posts, see here

[Sparkette]

I found a hack to remove the time limit to edit your posts, see here

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.

[JamesMc86]

The other thing to consider is, right or wrong, there are a number of people using this feature out there already. (I don't know numbers or anything but I have certainly seen it). I don't think they would be impressed in NI turned around and said its been compromised but we aren't going to attempt to improve the protection you are using on your IP. I do always recommend removing the diagram if it is highly sensitive though.

[Rolf Kalbermatter]

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...)

 

Well in the same way you can of course argument that users do not want to pay for contents and software and therefore it is legal to crack software and put it on the street for free. However there are users who rather pay some money for something useful and also enjoy the added benefit to not download viri festered content that way (most crack download and password cracker sites contain nowadays mostly unhealthy junk if they even contain a single working crack of what they claim to do).

 

And as Djed and James pointed out, the password protection is there because of user request, not to protect the few NI secrets they have (they are better protected by putting them in the 30MB of binary compiled LabVIEW executable code nowadays, and a few more 1000MB of compiled shared libraries). So which user do you want to protect with your password crack? The one who feels nobody has a right to prevent him from seeing a diagram, or the one who produces content for people to use, without wanting to throw all the details on the street.

 

There have been numerous cases of people posting "their" own libraries on various LabVIEW sites, some of them copying open source VIs verbatim, others copying functions from commercial toolkits. If your  position is that nobody has a right to hide his code from you you may have to live with the consequences that that code is not developed anymore for sale, but kept internally, so nobody can profit from it anymore.

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.

 

Well, why do you think someone being very much active on this forum and providing contents and answers should pay, while someone who mostly uses this forum to talk about how to hack the software the forum is about shouldn't?