LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Random Nugget 1 : Post-build EXE customisation

I'm posting a random (trivial) Nugget here about something which I remember hearing about in LV 6.1 but which is still possible.

 

We all know more or less that a LV application is made up of VIs contained within, right? Correct.

 

We know we can load VIs from the command line in the LV IDE by calling "LabVIEW.exe Stuff.vi" right? Correct.

 

Did you know that you can load a VI into the same application space as an EXE AFTER building by calling "MyApp.vi Stuff.vi"? Wait, what?

 

This can be interesting and I'm only going to scratch the surface here.

 

1. If you are using a Queue-based Producer-Consumer system, you can launch a small Queue monitor (if the Queue is named) via command-line. 

2. You can even REPLACE VIs which are incorporated into the application by specifying a new path to a different VI with the same name.

 

I have the feeling this is something most people are not aware of.  Maybe it's even a bug, who knows......

 

Here's an example of a VERY small program showing the behaviour.... I have included two shortcuts, one for the default VI included in the build and another to override the default VI.  Let me know how you get on...

 

Shane

 

PS I just realised that the paths for the shortcuts need to be updated to wherever you place the fuiles on your computer..... My bad....

Message 1 of 26
(4,181 Views)

Of course, needless to say that the VI being "piggy-backed" into the EXE needs to be runnable and saved in the same version of LV as the EXE was compiled.

 

Anyone else have interesting ideas using this method?  I can think of a few, but what do you guys think?

 

Shane.

 

Spoiler

Made you look!

Spoiler

Seriously, any ideas appreciated....

Message 2 of 26
(4,164 Views)

Here's another small example of loading a Queue monitor (very trivial example) after building.

 

Again I have included two shortcuts whose paths need to be modified for them to work, but the principle is shown.

 

One such usage I could imagine would be for debugging a built application.  Of course we don't always know WHAT we want to debug before building, so the ability to poke into the application post-build could prove useful.

 

Shane

0 Kudos
Message 3 of 26
(4,158 Views)

I thought that in newer versions of LV's names and VIs etc were properly isolated between application instances, so whilst you could spy on a Q of another app in the development environment, you cant spy on an EXE's named Q?

 

Am I wrong??!!?

 

PS. I dont have the ability to try your code right now

0 Kudos
Message 4 of 26
(4,140 Views)

While sperate application isntances are shielded from one another (more or less - VI Server may still work) this is different.

 

This method INJECTS a VI into the SAME application instance as the built application.  That way you CAN spy on named Queues and so on.  That's the trick.

 

So while you're not wrong, you've missed the point of the exercise just a fraction (Which is understandable since you haven't tried it out).

 

Shane.

0 Kudos
Message 5 of 26
(4,126 Views)

I do suspect there might be certain (nasty) security aspects to this method and to be honest, I could live quite well with a build option to prevent exactly this kind of thing going on.  Just thinking of the kind of access this could give to you in ANY build application is kind of scary.....

 

Even if you don't have named Queues, as soon as you have a control or indicator with a Queue refnum in it means that an "attacker" could gain access (and control of) that Queue.....

 

Shane.

0 Kudos
Message 6 of 26
(4,121 Views)

A blood queue sucking parasite consuming queue elements would cause havoc as well.

 

Named queues are rare animals on my diagrams but I will watch for them now.

 

Ben

Spoiler

 

PS: If you ever plan to visit NI week, you should save these nuggets up and present them so you can personally witness heads exploding.

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 7 of 26
(4,117 Views)

 


@Ben wrote:

A blood queue sucking parasite consuming queue elements would cause havoc as well.

 

Named queues are rare animals on my diagrams but I will watch for them now.

 

Ben

Spoiler

 

 

PS: If you ever plan to visit NI week, you should save these nuggets up and present them so you can personally witness heads exploding.

 


 

The question floating around in my mind at the moment is whether we've reached the point in LabVIEW's maturity cycle where we need to start considering code security and robustness against exactly this kind of exploit..... I know there are a lot of people doing a lot of work on code security for the Linux Kernel for example.  Do we need to start considering this kind of approach to LabVIEW?

 

I mean, even with unnamed Queues, a single control or indicator with the Queue Refnum blows a hole in your code the size of Canada!

 

Shane.

0 Kudos
Message 8 of 26
(4,114 Views)

I used this once to create a plug-in architecture. Users were able to write plugins (with a given VI connector) that will run in the exe context.

For instance you could let the user write a filter plugin that filters the data with the user's algorithm, using a call by reference node on the plugin VI.

We used it in the way that the user could write a DAQ VI that provides a measurement when called (in our case used for slow measurements, e.g. 2 samples/second). This data was then available for further processing, display, analysis in our software.

 

While this works nicely, the the restriction that the user has to use the same LV version that was used to build the exe was too strict in our case, so we didn't continue this path.

 

0 Kudos
Message 9 of 26
(4,104 Views)

 


@Intaris wrote:

 

The question floating around in my mind at the moment is whether we've reached the point in LabVIEW's maturity cycle where we need to start considering code security and robustness against exactly this kind of exploit....


If you'll remember, this was also the point I was concerned about last time we discussed this (and if you don't, here's the link). And I stil am. I haven't checked your code here, but I'm sure hoping that loading a new VI does NOT replace the old VI. That would not make sense.

 


___________________
Try to take over the world!
0 Kudos
Message 10 of 26
(4,068 Views)