08-19-2007 03:07 PM
08-20-2007 07:45 AM - edited 08-20-2007 07:45 AM
@Jim Kring wrote:
I'm sorry to be the one to break the news (but, I'm sure I'm not the first to say this):
Yepp, you are right
http://forums.ni.com/ni/board/message?board.id=170&message.id=192756&query.id=395047#M192756
that thread is more than one year old, I still wonder there is no unlocking tool somewhere in the net. I expect that all it needs is just a 'patch' of the regular LV to skip or inverse the result of the password validation because the diagram not even seems to be encrypted.
Message Edited by Henrik Volkers on 08-20-2007 02:57 PM
08-20-2007 08:01 AM - edited 08-20-2007 08:01 AM
Message Edited by shoneill on 08-20-2007 03:02 PM
08-21-2007 10:41 AM
@Henrik Volkers wrote:
Yepp, you are right
http://forums.ni.com/ni/board/message?board.id=170&message.id=192756&query.id=395047#M192756
that thread is more than one year old, I still wonder there is no unlocking tool somewhere in the net. I expect that all it needs is just a 'patch' of the regular LV to skip or inverse the result of the password validation because the diagram not even seems to be encrypted.
08-21-2007 10:45 AM
@shoneill wrote:
On a side note, what so we suggest as an alternative? Encryption with password protection?
08-21-2007 11:24 AM
08-21-2007 11:31 AM
@shoneill wrote:
Is there really a practical solution to the problem? Would encrypting the block diagram add a sufficient barrier to prying eyes
08-23-2007 05:48 PM
As far as I know (and I don't know that much about development environment), LabVIEW is (one of) the only development environments that provides a mean to "protect" actual code. As I understand it (and this all in logic), you are actually working with LabVIEW to provide access to the code, because in this instance you can view LabVIEW as some sort of interpreters that knows how to render the VI code. Other than that, the code has always been there.
Others already has expressed their concern about the password protection mechanisms. Rolf K. has always trying to explain it as best as he understand it. GeorgeZou has gone as far to say something like that it is not real protection and that's why he distribute his VIs compiled. When you compile it, the code is there, but in machine form, which is really as far as you can go to "protect" executable code without going into esoteric solutions.
Once I mentioned that the VI protection relies on National Instruments reputation. That is an extension to the fact that they are not telling how the mechanism works - you have to trust them when they say "it works". I am not trying to defend National Instruments, but the fact that they are not telling does not imply "security by obscurity". It means it is unknown. "Security by obscurity" also means that once the mechanism is known, it is broken. If some day somebody publish how the VI protection works, and by having that information the mechanism is broken, then it is confirmed that it was indeed security by obscurity. But, the fact that they are not telling do raise suspicions. You just need the final evidence.
I always ask the question “what is that you are really protecting?” Surprisingly, most of the time is not the algorithm, it is the data that is processed, and it is not confidentiality the main concern – it is integrity. But customers usually does not understand that unless you educate them and ask the right questions.
Another question I ask is “from who? The competition? An employee?” It is important not to be paranoid about security. Secondly, when you heavily invest in information security (which is at the level we are talking) is because you already invested well in the other three areas above this, have you?
At this point it is pretty clear that that little VI protection mechanism is truly “false sense of security” if they really believed that’s all the security they needed, given that the code is really that sensitive.
So, I don’t dwell much about it. Most of the time is not even close to be a security solution.
03-23-2008 06:24 PM
07-12-2008 04:44 PM