decompiling 2009 executable

[lvproggy]

I just discovered the sucurity hole and found this topic. I must say I don't agree with those who say "lay back, it's not that a big problem".

Suppose the following situation. I use a license for my application, and enable certain panels depending on the license. At startup I write license information in a global variable, to use in the sub-panels.

Do the following: unzip all the VIs in the EXE to a folder. With labview open the startvi. Everything works. Now open the global variable. You can just see everything. How many of you store a password in global? Asume you have a variable that contains your license or login level, you can simply change it and get access to all you need. Another thing you can do, open user interface vis which are normally behind a disbaled button and so on...

Like the other person said, if you have a VI that does important analysis (IP), anyone could use that.

This is a huge security hole, your program is public domain. Most of my programs are "products", if I tell this to my customers, I'm out of business with labview.

[rolfk]

---

lvproggy wrote:

Do the following: unzip all the VIs in the EXE to a folder. With labview open the startvi. Everything works. Now open the global variable. You can just see everything. How many of you store a password in global? Asume you have a variable that contains your license or login level, you can simply change it and get access to all you need. Another thing you can do, open user interface vis which are normally behind a disbaled button and so on...

---

If you store a password anywhere you have already lost. It will be in memory and memory can be easily scanned. As to licensing software I have my own meaning about that. But doing it hacky tacky, you should not be surprised it is hacked in no time

Protecting software, license, encryption, or just password is an art that even the big guys spend million of dollars to get it better and in fact is understood only by a very few. Going to claim that the possibility to look at your globals in a LabVIEW executable is a security risk only proofs that you do not understand real security but instead rely on security through obscurity.

Message Edited by rolfk on 12-15-2009 04:14 PM

[lvproggy]

If you store a password anywhere you have already lost. It will be in memory and memory can be easily scanned.

- Sorry but there is big difference between going to scan memory and simply opening a labview VI, this is pulled out of it's context.

As to licensing software I have my own meaning about that.

- You mean software should not be registered? where does my customer get his income, who is going to pay your engineering bills?

But doing it hacky tacky, you should not be surprised it is hacked in no time

- I know everything can be hacked. Again, you pull this out of it's context. There is big difference between doing a hacking attack and simply opening a labview VI. Even I could probably hack most labview applications, and I have no hacking experience.

[Norbert_B]

Hm, i don't think that lvproggy meant to store the password itself in the global. I rather think he tries to store "rights of access" in this global which is absolutely valid.

Nevertheless, everyone who is taking this as a serious "security hole" is forgetting something:

The person abusing this has to

a) have a LabVIEW version

b) know this approach (this post for example is a good source for such knowledge)

c) have the motiviation to abuse the EULA of the software product

So we see that abuse of this kind does not "happen by accident", but is an act of intention. And as Rolf put it: You can spend as much efford as you like into security of your software product, chance is high that someone around the world will be able (and motivated) to break the rules of usage.

In this case, i think that most of you can/should trust your own customers since i doubt that many developers here create code for the broad masses......

Norbert 

[Norbert_B]

---

lvproggy wrote:

If you store a password anywhere you have already lost. It will be in memory and memory can be easily scanned.

- Sorry but there is big difference between going to scan memory and simply opening a labview VI, this is pulled out of it's context.

[...] 

---

Nope, there is none. Both require certain tools (memory scanner, i think that sysinternals provide some vs. LV ADE) both require a certain knowledge and both require the motivation to do no good with the tool/knowledge......

[rolfk]

And storing such information in a functional global instead makes the whole story already a bit more complicated although the main use of them is in fact improved performance and better security from race conditions for most things.

[lvproggy]

I guess we will never agree about this, so here is my last reaction (for the moment).

The person abusing this has to

a) have a LabVIEW version. If that's the only requirement for stealing another company's intelligence, this is joke. You 2 sound like there are only a few Labview users on the world who know how labview works. By the way, in the about box we must advertise that it's build with labview. And then you think they don't know where to look?

b) know this approach (this post for example is a good source for such knowledge). every experienced programmer can figure this out quite quickly if asked to do so. Of course most labview programmers are not interested in that, we are on the other side.

c) have the motiviation to abuse the EULA of the software product. That's wat people do. Do you never cross a red light?

I trust my customers, but if there are people trying to figure out how we do things, we should make it difficult and not super easy. that's the whole point.

[Christian Mergl]

lvproggy said "...in the about box we must advertise that it's build with labview...."

This is not true. When distributing an application you are not required to include any extra copyright information concerning NI!

Christian

[lvproggy]

EULA

13.  Application Deployment. You may distribute or otherwise make available Authorized Applications (including applicable runtime engines for the SOFTWARE and applicable driver interface SOFTWARE that you may include as part of or together with your Authorized Applications), provided that you comply with each of the requirements set forth in sub-sections (A) and (B) below: A.    Distribution Requirements. (1.)  You include the following copyright notice "Copyright © [insert year] National Instruments Corporation. All Rights Reserved." in (a) the Authorized Application′s About Box (if applicable) and (b)(i) any applicable written documentation or, (ii) if no such documentation exists, in a "read me" or other .txt file distributed with each copy of the Authorized Application (you may include your own copyright notice with the notice(s) required above);

[rolfk]

It could be LabWindows CVI you know!