Jump to content

Security of VI passwords


Recommended Posts

On Stackoverflow someone posted a question on how to recover a VI's password

To my surprise there was a thorough answer containing two methods:

  1. Look up the stored MD5 hash in a VI file
    I can understand this, and am not really concerned, this might be a valid method if you know a password is from a given list (choosing a password from a dictionary is dumb anyway).
  2. Modify the LabVIEW executable binary to ignore the password checking.
    I have not tried this on LabVIEW 2011, but if this works it basically means that passwords are just a sign that says 'Do not trespass'

Can anyone verify the LabVIEW edit function in 2011.

On a more general discussion, does this troubles you anyway?

Ton

  • Like 1
Link to post
Share on other sites
  • Replies 74
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Yep. The password can't encrypt the diagram. The whole point is that the diagram is still readable so that it can be recompiled. If you want security, you have to save your VIs without diagrams and gi

We've posted a Knowledge Base (KB) article on this subject; Security of LabVIEW VI Password Protection vs. Removing VI Block Diagrams, which explains, in some detail, why the VI password protection fe

The byte sequence will change every re-compile-so it is unlikely to persist exactly as in that post across versions or even the same versions with different bitness. But at some point you have to say

Posted Images

There was a follow-up to a 2006 thread made over at the NI forums by the user TorPedoCXC claiming he could crack passwords using his GPU (http://forums.ni.com/t5/LabVIEW/VI-s-password/td-p/310730/highlight/false/page/3). He was basically saying the same thing about the MD5 hash. Maybe it's the same user.

The second method won't work with 2011 since that hex pattern doesn't exist. I checked. I also looked for the method he described in going and searching around a starting offset. No go. Not too surprising since the original was in reference to LabVIEW 8.6.1.

Does it trouble me? No, not really. If it can be cracked it will be. The protection is there to prevent those of us who are just "mundanes" to be able to skirt the protection. Anyone who's determined will get around the protection. Of course, the legal repercussions of doing so are another matter.

Link to post
Share on other sites

The second method won't work with 2011 since that hex pattern doesn't exist. I checked. I also looked for the method he described in going and searching around a starting offset. No go. Not too surprising since the original was in reference to LabVIEW 8.6.1.

I checked in 2009 and 8.6.1 - with no luck too.

Link to post
Share on other sites

The byte sequence will change every re-compile-so it is unlikely to persist exactly as in that post across versions or even the same versions with different bitness. But at some point you have to say "Is it? or Isn't it? a correct password" and finding it is easier if there is a dialogue since you know where to start.

I think most of NIs password protected files are purely to hide the terrible coding. Not that bothered if someone sees mine.

Edited by ShaunR
  • Like 2
Link to post
Share on other sites

I checked in 2009 and 8.6.1 - with no luck too.

Actually, I can confirm that the basic concept does apply in 2009 and probably in later versions as well. The reason for this is simple - LV needs to access the source code in order to compile it to machine code. Since the user can't be expected to provide the passwords (since, for instance, some of the VIs in the hierarchy were written by someone else) LV needs to be able to read the code even without the password. That means that the code itself can't be encrypted.

Then, as Shaun mentioned, you get a place in the code where you need to check if the user's password matches the VI's password in order to show the BD and if you patch the LV executable to override that check - voila.

In any case, it should be pointed out that other IDEs don't have password protection for source code, at least not as far as I know. I understand why NI put it there, but it should be clear that it's not something you can rely on if you expect to protect your code from someone determined.

  • Like 2
Link to post
Share on other sites

Well, the "hackability" is still there - it's just that the specifics detailed in the reply on Stackoverflow didn't seem to apply directly to LabVIEW 2011. But then I'm not an expert in interpreting assembly language.

Of course, I wonder if NI can sue that poster for providing such details which, to me, seem to be a blatant violation of the license agreement.

Link to post
Share on other sites

And just to add a bit to it. Even if you find that location where the password is checked, things get a lot more complicated if you take password protected libraries (and maybe classes) into the picture. Those do not use the same code paths to check for password protection and the passwords of each are actually used in the hash of the other.

Link to post
Share on other sites

Instead of "leave it at that" I think you meant to say "fur-geht abou' dit".

My brain tried to process that as German. It didn't go well.

My perspective on passworded diagrams is that they are not for the protection of IP - it's more about keeping developers away from code that's fragile or not ready for public consumption. The true protection for source code is, like AQ said, to remove the diagrams altogether. If it's code which needs cross-version compatibility, you're going to need another copy of the code saved into the other LV version anyway, right? The only thing this truly prevents is ad infinitum cross-version compatibility, but I can justify that as more of safeguard than a restriction.

Link to post
Share on other sites

> you're going to need another copy of the code saved into the other LV version anyway, right?

Not if you turn on Source Only which allows us to have multiple binary versions for the same source VI.

Link to post
Share on other sites

IF this work,NI will cry. :thumbup1:

Nope, It affects the users more than NI. Ni are probably more worried that their whole licensing scheme has been compromised since 2009.

Edited by ShaunR
  • Like 1
Link to post
Share on other sites

Nope, It affects the users more than NI. Ni are probably more worried that their whole licensing scheme has been compromised since 2009.

Where does the licensing scheme even remotely touch password security of VIs? Anything license related is really handled in the LabVIEW kernel itself so not sure what the ability to unlock a password protected VI would do there.

Following is not directed at you Shaun but at anyone being high in the arms about the insufficient protection password protected VIs give them to protect their oh so precious IP:

Password protection of diagrams is not meant to protect your IP. There exists only one really secure way to protect your IP, and that is to put it in a heavy steel safe, destroy all copies of your idea and dump the safe in the North Pacific above the Mariana Trench. Save of some alian race with super high tech, nobody will be able to get at those secrets. Chances are however high that someone else has already developed the same idea independently and will go to market with it and earn some money with it.

Another slightly less secure means is to hire a whole army of lawyers who will involve anybody into a legal battle who might even just appearing to try to steal that IP, so that they can fight for the rest of their life, robbing them of any time to invest into monetizing the stolen idea.

Both of them are highly unpractical and costly! :shifty:

Get over it and accept that password protection of diagrams is only to keep out the nosy. If you do need to protect your IP don't distribute the source at all! Bite the bullet and remove at least the diagram. Yes it's inconvenient as such VIs can only be loaded into the LabVIEW version in which it was created and also only on that platform but anything else means LabVIEW has to be able to get at the diagram somehow without knowing the password (or worse yet store the password in the VI somehow too) and that also means that anybody with enough determination will be able to circumvent any kind of protection the LabVIEW developers can come up with to prevent others than LabVIEW itself to get at that diagram.

I think the best long term protection in that respect is actually the semi annual release cycle of LabVIEW as it obsoletes any of the more promising hacking solutions each time.

  • Like 1
Link to post
Share on other sites

Where does the licensing scheme even remotely touch password security of VIs? Anything license related is really handled in the LabVIEW kernel itself so not sure what the ability to unlock a password protected VI would do there.

I never said it was. I was simply pointing out that NI wouldn't "cry" over a password protection hack and that since the licensing has been compromised; they would be more concerned about that-if at all

Edited by ShaunR
Link to post
Share on other sites

Does anybody remember an old DOS program from around 1992? If memory serves me correctly it was called Burp-Cotch-Spit!

Googling that came up with some interesting results... I never used it, but definitely played around with similar tools. I messed around with all sorts of Apogee and 3D Realms games...

Link to post
Share on other sites

I'm not a cryptology at all, zero experience what so ever, but I've often mentioned how not secure the password protection method is (despite a few NI employees telling me otherwise). But I'm starting to understand now why it is done the way it is. I thought that the whole VI should be encrypted, making it impossible to find the MD5 of the password in the file. I now know why NI can't do that.

Using a few graphics cards you can get above 3 Billion hashes/second (if you are going the MD5 route). Which would still be pretty secure for passwords 10 characters or greater (which aren't susceptible to dictionary attacks).

But as already mentioned there is the LabVIEW.exe modifications that can take place as well (which are against NI's agreement).

Link to post
Share on other sites

But as already mentioned there is the LabVIEW.exe modifications that can take place as well (which are against NI's agreement).

It's a violation of the license agreement indeed, though I doubt a hacker feels much bothered by that :cool: .

The other issue is that you need to do disassemble and that is not trivial. It is made extra hard by the sheer size of the LabVIEW executable nowadays. Even a very good disassembler takes a few hours to get a raw disassembly for such a huge executable. And then you can sift through million lines of assembly code to find the places where the MD5 hash is checked. And looking at assembly for even a 100k DLL is already a rather boring job.

The fact that every half year a new executable is released makes the task even more hopeless. So while I'm sure there exist hackers who have hacked one or two versions of LabVIEW to that extend they really won't keep on doing that over the years as the gain of this is minimal. There is very little you can really see from most password protected VIs. Bragging rights don't apply because if someone does that, he might get a cease and desist letter or even worse, signed by the legal department of NI.

I have at some point looked at the possibility to simply modify the VI and that seemed just as hopeless. Especially with VI libraries involved, which contain also a password whose hash is even out in the clear in the library XML code. And those passwords even seem to be interwoven with each other.

As to the licensing. I believe there exist Key generators to fake-license LabVIEW installations. Never mind that most of those key generators have also some stealth load inside, that packs a few viruses and/or troyans on every computer they are executed on. After all why should a hacker who doesn't respect intellectual property respect someones privacy?

Link to post
Share on other sites

The fact that every half year a new executable is released makes the task even more hopeless. So while I'm sure there exist hackers who have hacked one or two versions of LabVIEW to that extend they really won't keep on doing that over the years as the gain of this is minimal.

You say that because new executables are released every 6 months, that this would deter the hackers. But then you mention the license generating hacks.

As to the licensing. I believe there exist Key generators to fake-license LabVIEW installations.

And these surely change with every version of LabVIEW released (likely every 6 months). I would be surprised if there didn't exist a license generator for all versions of LabVIEW. I also don't know what techniques the hackers use to create license generators, but from your explanation it sounds like alot of work went into figuring out how to modify this one version of LabVIEW to open VIs with passwords.

I guess the point of this post is that I believe someone out there has the ability to open VIs with passwords, in all versions of LabVIEW. I haven't seen it, but this post leads me to believe that.

If I did find some page on the internet that explains how to hack all versions of LabVIEW, I'm not sure I would post it. Even this thread makes me nervous. Are we spreading the word on hacking LabVIEW, by just talking about it? However not talking about it may give the false sense of security, thinking that LabVIEW is secure when protecting source code.

EDIT: It seems rightfully so, that the page at StackOverflow has been removed.

  • Like 1
Link to post
Share on other sites

You say that because new executables are released every 6 months, that this would deter the hackers. But then you mention the license generating hacks.

Your reasoning mixes again two rather unrelated things. That of hacking password protected VIs and that of hacking the LabVIEW license. For both you do need to to dig into disassembly if you don't want to go the brute force attack through GPU path, but they are not directly related to each other.

And these surely change with every version of LabVIEW released (likely every 6 months). I would be surprised if there didn't exist a license generator for all versions of LabVIEW. I also don't know what techniques the hackers use to create license generators, but from your explanation it sounds like alot of work went into figuring out how to modify this one version of LabVIEW to open VIs with passwords.

I haven't looked at the details for some time, but from what I saw earlier the license generators you could find were always tied to very specific LabVIEW versions. I think the license technic hasn't changed since about LabVIEW 7.1 so it might be possible to generate a key generator that works across versions, but I don't know.

I guess the point of this post is that I believe someone out there has the ability to open VIs with passwords, in all versions of LabVIEW. I haven't seen it, but this post leads me to believe that.

I'm not sure if there is a single person who knows how to open password protected VIs in all possible LabVIEW versions, but I'm certain there exist people who can open password protected VIs in certain versions of LabVIEW. And they don't work for NI, as NI has of course the ability to work on the source code directly to circumvent such protection.

This means, don't trust your super secret 5 million dollar idea to password secured VIs but also don't expect or require NI to provide such a possibility. It is technically simply not feasable to create a really secure protection without at the same time throwing away the advantage of not having to remove the diagram and making a VI only readable in the specific version and platform it was created in.

Link to post
Share on other sites

Your reasoning mixes again two rather unrelated things.

What I was trying to say is hackers adapt every 6 months or so to crack the latest LabVIEW, which makes me think that the same effort could be put into cracking LabVIEW passwords.

This means, don't trust your super secret 5 million dollar idea to password secured VIs but also don't expect or require NI to provide such a possibility.

Well put.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By X___
      The title is made up, but explains what I have been experiencing for years, hoping that it would be fixed in the next version, but it never has, so I am starting to suspect nobody is caring or possibly maybe nobody even noticed it?
      Anyway, the symptoms are:
      when I drag a VI (from either a palette or from the icon of an open VI) into a target VI's diagram, I am frequently encountering this odd and annoying¬†ūüöꬆsymbol where my cursor is (it's not red and it is slanted the other way, but this is the closest emoji to the real thing I could find), instead of the "androgynous" cursor (a mix of¬†‚ôÄÔłŹand¬†‚ôāÔłŹ) which tells me that I am going to copy that object where the cursor is.
      I would move the cursor around, seeing a¬†ūüöꬆwherever I go, until¬†I would fleetingly¬†grasp a cursor with the + index (the "androgynous" cursor)¬†over some random location, and then, painstakingly try to go back to that region to find the sweet spot (pixel really) where I am able to drop the VI. Of course, once dropped on the diagram I can move the VI anywhere where I was forbidden to drop it during my initial attempts.
      That's got to be the most annoying bug in a graphical programming environment ever...
      Am I the only one to experience this?
      I am using 2019 SP1 64 bit, but that has been around for several versions already.
    • By smidsy
      Hi,
      I would like to implement a Run-time license checking mechanism that will enable or disable some parts of my LabVIEW API depending on a license status. 
      After reading numerous discussions here on the forum (We need a new password cracker :( , Low level VI data editor (warning: not for production use!) , I found some more hidden INI keys, Password Security in LabVIEW) I realised few things:
      - reverse engineering in a LabVIEW-related field seems to be a doable task for some smart people, 
      - password protection on block diagrams does not protect your IP, it is more of a "read-only" or a "private property" sign,
      - removing block diagrams or compiling it into an executable are the ways to go, and finally,
      - there are few tools out there, that seem to have a potential to "unflatten" VI data and modify/extract its data even without block diagrams.
       
      Back to my task. I decided to remove block diagrams. Inside my protected VI I call an external library that does the actual license checking. So the code only gets this status and returns it back to other VIs. Then the VIs do not perform their main functions, and the user gets an error. 
      Do you think I am safe here?
      Is it possible to extract sensitive string information out of my VIs (without BD)?
      Is there a way to change wiring rules/connector pane on my VIs?
      Should I worry about DLL hijacking? 
      Does NI have some kind of a tutorial for protecting your run-time API? 
      How do you protect your API knowing all that? Do you sleep well?
      Thanks
       
       
    • By A Scottish moose
      Hey everyone!
      I'm working on a test system right now that requires the operators to sign the test reports.  In the previous generation this was done by the print/sign/scan method.  During one of the meetings it was mentioned that getting around this requirement would be nice.  I recommended we look into a digital signature pad and see what would be required to integrate one.  I've been thinking about ordering one and just giving it a go but I thought first I'd ask and see who has done this with LabVIEW before.  I know someone has, I just haven't found the documentation online yet.  
      Here's how I expect it would go:
      1. The software prompts the user to sign at the end of the test.  
      2. The signature pad saves the image location to the hard drive or provides it to the client through an API (any experience on how this usually works is appreciated) 
      3. My software would aquire the image and save it to a named range in Excel using the report gen toolkit.  Currently my report writing tool of choice.  
      4... Profit!
      Does this theory match with reality?  What are your experiences?  Do you have any models you prefer to work with?  
      I dug for a few minutes on this and didn't come up with much so perhaps a discussion on the subject is valuable.
       
      Thanks for the help!
      Tim
    • By lisam
      I am trying to connect a PostgreSQL database (ver 9.6) with LabVIEW (2016) on Windows 10.
      I followed the following tutorial:
      https://decibel.ni.com/content/docs/DOC-30308
      Without access to a cRIO, I have followed the steps to create the database, table and block diagram. Please see block diagram attached.The system exec.vi calls the psql.exe with SELECT command using database "lisam" and database user "postgres".
      When I execute the same code I am asked for the password for user postgres. When I type in the password, the box closes and reopens. This continues in a loop until I press abort. I get no errors and when I write the same script into the cmd - the password is accepted and the table is displayed, see attachment.
      PROBLEM:
      Password request from the psql.exe file when executing LabVIEW code Type password, psql.exe closes and opens again SELECT query works without while loop (password accepted once) but insert and clear does not without the loop condition What I've tried...
      Created a pgpass.conf file in a postgresql folder in %AppData% in the following format:- hostname:port:database:username:password, where lisam is the database, postgres is the user. Host name as localhost '127.0.0.1' - password still requested.
      127.0.0.1:5432:lisam:postgres:password Host name as 'localhost' - psql.exe flashes continously and LabVIEW crashes. localhost:5432:database:username:password
      Host name as database client address '::1' - password loop with the psql.exe.
      ::1:5432:database:username:password Host name to '*' -
      *:5432:lisam:postgres:password Able to:
      Access the database through the cmd WITHOUT password
      C:/Program Files/PostgreSQL/9.6/bin/psql -c "SELECT * FROM demo1" lisam postgres Problems:
      Execution in Labview - psql.exe flashes continuously and the program crashes. Accessing database through psql.exe directly - password requested and ERROR received
      "psql: FATAL: password authentication failed for user C:\Program Files" 2.Changed the authentication method in pg_hba.conf to trust for:
      localhost (127.0.0.1)- a password is still requested. 127.0.0.1 AND ::1 - Can access the database on psql without a password, but the psql.exe LabVIEW completely crashes.
      I tried adding the host and port to the code
      C:/Program Files/PostgreSQL/9.6/bin/psql -c "%s" -h 127.0.0.1 -p 5432 lisam postgres
      And the psql.exe flashes continously and won't abort.
      The password is called at the system exec VI in the cmd. Tried concatenating the password (as a control) with space constant to the command line string inbetween the format into string and the system exec VI. But the password is given before it is called. In summary I am able to use .pgpass.conf to authenticate the password when using the cmd, but not in LabVIEW. Does anyone know a way around this? Or another way to define the password at the system exec VI?
      Your help is greatly needed.
      Lisa
      Info:
      database name: lisam database user: postgres IPv4 local connections-
      host all all 127.0.0.1/32 md5 IPv6 local connections-
      host all all ::1/128 md5 DB:lisam Client Address ::1 psql Client address 127.0.0.1  
       
       


    • By PoSpineLopatoy
      Hi guys, i tryin connect to labview web serv through java application, and have some troubles.
      I already readed this:
      http://muree.psut.edu.jo/Documents/DEV4.2-Services%20Adaptation%20to%20Connect%20Remote%20Labs%20to%20VLE-Securing%20WS%20in%20LabVIEW.pdf

      http://www.ni.com/white-paper/7749/en/

      How i must encrypt my body through java? What happened with data when they go to Encrypt Vi?



      Thx for ur help



×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.