Random Nugget 1 : Post-build EXE customisation

[Intaris]

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....

[Intaris]

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....

[Intaris]

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

[shew82]

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

[Intaris]

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.

[Intaris]

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.

[Ben]

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.

[Intaris]

---

@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.

[dan_u]

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.

[tst]

---

@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.