Random Nugget 1 : Post-build EXE customisation

[Intaris]

Tst, I hadn't found that old discussion but I certainly remember it.

My testing (feel free to try out the code) shows that the VI entered as a variable on the command line is loaded BEFORE the VIs of the EXE.  For example, if I set the new VI to "Run when opened" and I try to call a VI of the same name in the EXE I get an error when I start the EXE with these command options because the VI is already reserved because it's running.  This should never happen if the VI was not being replaced.

Makes me wonder what one could do if we would try to replace VIs like "Open/Create/Replace File" with our own intruder code.....

Shane.

[Kevin_Price]

Very interesting indeed.

There was a time back in LV 7.1 that I *wanted* this kind of feature but never found the method you describe.  I had a plugin architecture that allowed external vi's to add functionality to an executable, but I also wanted the ability to *replace* vi's that were already built into the executable.  Name collisions thwarted me because I hadn't been aware of your idea to load the replacement vi first before the same-named vi from the executable.

Configuration control issues ended up turning this into a "don't bother with the feature because we aren't willing to risk using it" issue, so I never really pursued it when later LV versions gave better control over the namespacing issues that had previously stopped me.

But I agree with your sense of foreboding -- this does seem like a big security hole.

-Kevin P

[AristosQueue (NI)]

---

@Ben wrote:

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

---

Ok, so you're going to avoid named queues because of this. Are you also going to avoid VIs? VI Server is a far greater threat. After all, if I load a VI into memory, I have to already know the name of the queue to get access to it or else get lucky guessing the name. But there's a VI Server method to give me the names of all VIs in memory, and after that, I can get a reference to all those VIs and inject values into panels, global variables, functional globals, etc.

Named queues are essentially irrelevant to the conversation. What Intaris has pointed out is that any LV-built EXE is a door to running arbitrary code as part of the executable.

[JÞB]

BRILLIANT-

A few moths ago I ran into a situation on the forums where the eventual solution became a "released test launcher" AKA Pizza

I had a few issues though in being able to deploy a post delivery / customer supportable utility integrator for those little engineering functions that would be nice but do not affect "test" and yet, still leverage existing modules.

BRILLIANT!

[F._Schubert]

Great nugget, I wasn't aware of this hack. But it really is scary to be able to inject code into an existing exe. The first thing my evil ego would do is to change the exe's ini file to open ports for the vi server to do more harm, just in case...

I really see more potential to do harm with this than to write some nice plug-in or debug functions.

Felix

[F._Schubert]

Some thinking: here is the fix for this hole.

Use a splash-screen-launcher for your exe (the OpenG builder has one if you need to see how to implement it). Then just close all vi's other than the launcher vi that run in this app instance.

I'm sorry but I don't have the time to code it right now.

Felix

[Ben]

---

@f. Schubert wrote:

Some thinking: here is the fix for this hole.

Use a splash-screen-launcher for your exe (the OpenG builder has one if you need to see how to implement it). Then just close all vi's other than the launcher vi that run in this app instance.

I'm sorry but I don't have the time to code it right now.

Felix

---

Nice!

I'll call that the "wash the plate before you eat" work-around.

Ben

[TCPlomp]

I haven't studied this, but you can protect your code a little better by using LabVIEW libraries. A library will only load VIs if they are at the expected path.

Now lock your library with a random password (upon build) that you don't even know.

That should work and protect you from the not-so-innocent.

Ton

[rolfk]

I smell a new option in the LabVIEW Build Options in LabVIEW 2011.

But I consider the named queue issue very minor. If someone knows the names of your queues in your app and can intelligently interact with them in a way that is dangerous, you have a much bigger problem. Aristos Queues remarks about VI server access is a much more critical problem eventhough I guess it could be hard to monitor my typical 1000+ VIs types applications with this in a meaningful way.

[Intaris]

Felix,

now THAT's an interesting idea.  But what are the intricacies of such an approach?

The splash screen would have to call all of the VIs dynamically since hard-wiring them would prevent LV from closing them.  The it would call the top-level VI (again dynamically)?

So basically the splash VI needs a list of all VIs int he finished application to be able to do it's thing....

Begs the question.... what happens if we override the splash VI?

Shane.