Jump to content

Recommended Posts

3 hours ago, hooovahh said:

Years ago we were in a meeting with a few LabVIEW champions and LabVIEW R&D ...

I don't know if that was the same meeting I was in or if I was pulled in after the fact, but that was where I tried to argue against having password protection at all. The answer I got back was, "This isn't a security feature. It's a feature to keep developers and production line techs from accidentally modifying VIs they didn't intend to modify, and providing a way (by using the common password) to unlock specific subsets of VIs when editing is desired."

That seemed like a useful concept to me. Ever since then, I've been fine with basic security around the password, as long as we make it clear to users that the password isn't intended to protect intellectual property. And that's what we do:

Quote

From our online help for "Creating Password-Protected VIs":

Caution  VI password protection does not encrypt block diagrams. For maximum security, remove the block diagrams from your VIs. Refer to the KnowledgeBase at ni.com for more information about the security differences between password protection and removing block diagrams.

There's a lot more detail in that KB entry. We document this in a few other places as well.

Edited by Aristos Queue

Share this post


Link to post
Share on other sites
9 minutes ago, Aristos Queue said:

That seemed like a useful concept to me. Ever since then, I've been fine with basic security around the password, as long as we make it clear to users that the password isn't intended to protect intellectual property.

Not trying to derail the thread even more, but every time I hear that argument I say that is why you can lock a VI without passwording it.  Which is what my Pre-Build action on building a package does.  Need to edit it and do a test?  Sure just unlock it.  Drilling down into a VI and not realize it is part of the reuse library?  You will when you see it is locked.  But whatever.

I still tell the quote from NI R&D saying off the record that the protection you get from password protecting a VI, is about the level of protection you get from tissue paper. 

Share this post


Link to post
Share on other sites

I implemented both interface counting and sequential check (called it brute-force). Will try to check whether there's a pattern in interface selection - I would prefer not to base that on guessing, as I'd like a tool which exports the VI to a set of XMLs and BINs, and then re-creates VI from scratch, using only the exported files.

I could make the "salt interface index" a part of exported XMLs. But maybe the pattern is simple.

Share this post


Link to post
Share on other sites
On 11/4/2019 at 1:14 PM, hooovahh said:

Not trying to derail the thread even more, but every time I hear that argument I say that is why you can lock a VI without passwording it.  Which is what my Pre-Build action on building a package does.  Need to edit it and do a test?  Sure just unlock it.  Drilling down into a VI and not realize it is part of the reuse library?  You will when you see it is locked.  But whatever.

I still tell the quote from NI R&D saying off the record that the protection you get from password protecting a VI, is about the level of protection you get from tissue paper. 

Just locking doesn't suffice:

1. It doesn't give you the ability to unlock specific subsets of VIs.

2. It doesn't keep production line engineers from "just unlocking it"

Share this post


Link to post
Share on other sites
14 hours ago, Aristos Queue said:

Just locking doesn't suffice:

It really depends on what you are trying to do so I get that.  For me even just setting the VI file to read-only would be enough, but I ran into a few times when a mass compile would want to overwrite the VI despite it having separate compile code, but that was years ago.  For me the purpose was that a developer would be drilling into the code and not realize they were in a reuse function and would start messing around with it and changing things that will now make the program behave differently on one developers machine, than the others.  A gentle reminder to not mess with something was all we needed.  But I get your points.

  • Like 1

Share this post


Link to post
Share on other sites
9 hours ago, hooovahh said:

It really depends on what you are trying to do so I get that. 

Different users, different use cases... and for some, the passwords have real value. So they linger.

Just occurred to me: maybe we should call it something other than a "password", since that sounds like security. Instead of "Set password", call it "Join editing region". Instead of "Enter password", use "Enable editing for region". It preserves the functionality but steps us away from this constant drumbeat of "your security is broken!"

Share this post


Link to post
Share on other sites

Back to the salt - the algorithm seem to use some additional data to select which interface is used. It may be some kind of count.

I executed my reader on all the VIs built into LabView 2014 Well not quite.. I was too lazy to extract VIs from LLBs. But it was still over 13000 files. Anyway, in large majority of cases the counts were taken from LAST interface. For less than 4% only zeros were used instead, and for less than 1% - the interface used was previous to last, not the last. There were also single cases where even earlier interface was used.

If anyone would like to take a look, attached it the result of the following commands:

find ./vi.lib -name '*.vi' -o  -name '*.ctl' | sed 's/'"'"'/\\'"'"'/g' | xargs -I {} ./readRSRC.py -vvv -p -i '{}' 2>&1 | tee log_vi_lib.txt

sed -n 's/^.*: \(Found matching salt .*\)$/\1/p' log_vi_lib.txt | sort | uniq -c

Figuring out the specifics of interface selection would require deep dive into RE libraries, so I'll skip it for now.

Now I want to make a function to export the data into some modificable form, and re-import again into proper VI. I will leave most data in binary form, only the parts I need will be fully parsed.

Any comments / advice?

lv14_builtin_vi_lib_all_salts.txt

Share this post


Link to post
Share on other sites
On 11/8/2019 at 1:00 AM, Mefistotelis said:

Back to the salt - the algorithm seem to use some additional data to select which interface is used. It may be some kind of count.

Figuring out the specifics of interface selection would require deep dive into RE libraries, so I'll skip it for now.
...
Any comments / advice?

Well, in case you ever consider going that way, I'll recommend you start by looking at the LinkIdentity parts of the code ;)

Another vector for information could also be to look at the codestreams in the "Ned, the friendly debugger" interface.
While I haven't peeked much at Flarn's later progress, I do know that NED will let you switch the format of some VI resources into XML (Heap Save Format) - dunno if Flarn is utilizing that?!
(be warned though - this will most likely certainly cause LabVIEW to crash if trying to load the VI afterwards)

Also, for quick low-level access to the Resource Fork of LabVIEW VI's and a lot of other NI resource files -from inside LabVIEW- I suggest using the REdLoadResFile/REdSaveResFile (interface)functions found in LabVIEW.exe.
That at least cut away one level of abstraction for me, back when I had the time to immerse myself in this kind of 'research'.

Now off to figure out the "Keep code streams for heap peek" option..

Edited by Stinus Olsen
Added REdLoadResFile/REdSaveResFile info..
  • Like 1

Share this post


Link to post
Share on other sites

Thanks @Stinus Olsen, will look into some of these.

 

The tool I made can now extract and re-create most VIs, like this:

./readRSRC.py -vvv -x -i './examples/empty_vifile_lv14f1.vi'
./readRSRC.py -vvv -c -m './empty_vifile_lv14f1.xml'
cmp -l './examples/empty_vifile_lv14f1.vi' './empty_vifile_lv14f1.vi'

Though there are still a few for which `cmp` shows difference between original file and re-created one (I've run it on the standard VIs from LV2014, on thousands of files only a few had differences).

Also, it currently leaves all Blocks as BIN files - does not parse their content.

Edited by Mefistotelis

Share this post


Link to post
Share on other sites

How cute - NI is protecting some values stored in memory at runtime by XOR'ing them with seed which depends on the VMA.

Here's what it does to an MD5 checksum stored at `ptr` (hence size=16), code comes from LV14:

  seed = ptr ^ 0xDEADCAFE;
  i = 0;
  do
  {
    *(uint8_t *)(i++ + ptr) ^= seed;
    seed >>= 1;
  }
  while ( i < 16 );

 

Share this post


Link to post
Share on other sites
20 hours ago, Mefistotelis said:

How cute - NI is protecting some values stored in memory at runtime by XOR'ing them with seed which depends on the VMA.

Code from an older time when people thought such security was meaningful. There's some ROT13 password "encryption", if you look hard enough. 

Share this post


Link to post
Share on other sites
11 hours ago, Aristos Queue said:

There's some ROT13 password "encryption", if you look hard enough. 

As mentioned here :

?

Share this post


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.


×
×
  • Create New...

Important Information

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