remove password protection

[JonDJ]

Just to end: I am not blaming the tool maker. I just hope the tool make can provide service.

Business man point of view:

It already happenned and :

1. If deal with the previous programmer how soon he/she can give the password and if go for law court how long it will take and how musch it will cost and .... I still need to pay for the new programmer.

2. If the tool maker provide the service to unlock it , then how much it will cost as compare to write new program?

3. Is the investment for buying this tool worthy.

4. from this lesson I can prevent the new programer to cause same problem as per your suggestion (good code practice, etc) and No one perfect all learn day by day through mistake.

Regards,

Jonas

[rolfk]

---

@JonDJ wrote:

The problem: I request the tool maker for help, but I only got silent from them. At least if they offer some assistant or perhaps ways to help, it would be better. Yes, beautiful program but fragile.

I believe the tool maker must support and protect the customer too.

---

And this is exactly done by not providing back doors. How could NI assess that your story is true and not just made up to get at some code you have no right to look at? Yes they could start a legalize process for such cases, where your company must sign about 2 dozen documents stating that it owns the rights to that software, is willing to allow you to have a look at that code, and will defend NI in every court case that might follow out of unlocking that said code. It would cost several weeks of paper work, at least half a dozen lawayers getting involved and in the end it all would still be fragile to the max.

So don't blame them for not going that route. Blame your HR department for not having proper procedures in place when one of the programmers leaves the company, and management for not having a useful code backup strategy in place.

[Hooovahh]

---

@Jeff Bohrer wrote:

---

@Johnner wrote:
In case anyone is alarmed at Waldemar's proposition, I report that my LabVIEW takes around 100 ms for one unsuccessful "Set lock state" attempt. Even with a reduced valid character set of around 75, it will take my poor computer 4,000,000 years to crack an 8-character password!

Probably not a problem for the folks at NSA, but I am fairly comfortable that no armchair LabVIEW hacker is going to brute-force his/her way into my password-protected VIs (if I had any password-protected VIs). Anyone using short passwords should definitely change their ways, though.

--John

---

Well you have a better than a %50 shot of cracking it in the first 1,587,280 years!

---

You could go with the MD5 cracking approach.  I've seen screenshots of BarsWF running at over 3 Billion hashes/second.  That's just under 3 days for a 8 character password that checks 72 different characters.  After seeing that I start to wonder if NI's encryption methods aren't good enough.

[TorPedoCXC]

I would recommend using web-based rainbow tables and other tools to attack the MD5-hash. It's really simple that way. I just tested it on the GOOP Object repository vi. The password can be found by googling the corresponding MD5-hash. Never thought it would be THAT easy.

Now I finally know what hides inside - nothing spectacular after all 🙂

[AEI_JR]

I have NO idea what any of that means, let alone how to duplicate it.  Is it possible to translate your answer to English?

[JGruenberg]

A rainbow table is a table of strings and the corresponding hash.  If you know the hash, you use this table to look up the corresponding initial string.  

There are still ways to throw a wrench into this method.  NI could add a salt to the hash which makes it more difficult (but not impossible) to get the original password.

[MD_John]

If it really was you VI, one could copy the MD5 digest out and find reverse from google, no need to wait for a slow NI loop.

John

[davidqk]

Here's a brute force vi that I created for hacking passwords of up to 5 characters, where you can specify a character library from which to choose the characters.  This VI was created in LabVIEW 7.1.  To get the password in a reasonable amount of time, the password must be short and you need to limit the character library.  I hacked one of my old VIs this way.

(Because of the time delay in the "Set Lock State" invoke node, the execution time is slow).  But it might work for you.

[altenbach]

---

@davidqk wrote:

Here's a brute force vi that I created for hacking passwords of up to 5 characters, where you can specify a character library from which to choose the characters.

---

Code like that has been floating around for a long time (example), but yours seem overly complicated. Why do you write to local variables in the innermost loop, while the terminals are sitting there disconnected? Try to do it fully scaleable with a single loop, instead of stacks and stacks of loops. The code shouldn't need to be rewritten if the number of digits changes, for example. A good programming execise! 😄

[davidqk]

---

@altenbach wrote:

---

@davidqk wrote:

Here's a brute force vi that I created for hacking passwords of up to 5 characters, where you can specify a character library from which to choose the characters.

---

Code like that has been floating around for a long time (example), but yours seem overly complicated. Why do you write to local variables in the innermost loop, while the terminals are sitting there disconnected? Try to do it fully scaleable with a single loop, instead of stacks and stacks of loops. The code shouldn't need to be rewritten if the number of digits changes, for example. A good programming execise! 😄

---

That link is broken.  But yeah.. the code is not scalable or optimized.  But it doesn't matter that the code is not optimized, because the "bottleneck" for computation is "Set Lock State" invoke node.  And it also doesn't matter that the code has stacks of loops instead of being fully scalable.  If the password is longer than 5 characters, then you're hosed anyway.  You'll never find it in a reasonable amount of time.