Jump to content

Self-reproducing code


Recommended Posts

Hi, people.

I've been rummaging through this idea and I have managed to create a piece of self-reproducing code (I have to admit it's no difficult). It copies it's own code in other VIs, then when those VIs execute, they copy that code in others, etc. As a concept I find it fascinating, but it's a little nasty if you aren't careful.

So, does scripting suppose a new danger to free VI sharing, like in forums? What do you think? Probably this is one reason NI doesn't want people playing too much with these new tools. Maybe in a few years we'll need antivirus for LabVIEW :blink: .

Saludos,

Aitor

Oh, excuse me for not attaching the code, for obvious reasons ;)

Link to comment
Hi, people.

I've been rummaging through this idea and I have managed to create a piece of self-reproducing code (I have to admit it's no difficult). It copies it's own code in other VIs, then when those VIs execute, they copy that code in others, etc. As a concept I find it fascinating, but it's a little nasty if you aren't careful.

So, does scripting suppose a new danger to free VI sharing, like in forums? What do you think? Probably this is one reason NI doesn't want people playing too much with these new tools. Maybe in a few years we'll need antivirus for LabVIEW :blink: .

Not sure what the problem would be. I can write a small demo VI that does the equivalent of rm -r / (obviously for unix ;-) and post it and anyone not being smart enough to check the VI diagram before executing it would be deleting his entire harddrive. So what?

Of course this would be different if I hide the diagram code behind a password, but then it may be a good idea do know from whom you get the code before even attempting to run it!

Rolf Kalbermatter

Link to comment
Not sure what the problem would be. I can write a small demo VI that does the equivalent of rm -r / (obviously for unix ;-) and post it and anyone not being smart enough to check the VI diagram before executing it would be deleting his entire harddrive. So what?

Of course, you can easily destroy almost everything in the computer or even copy a VI a million times. But I think this is more subtly. The code keeps copying itself inside other VIs diagram without destroying their original purpose, and so each infected VI acts as a new propagation point. And you could hide the code, for example, in an invisible (or not immediately visible) zone, such as inside a frame, behind something, etc. So it's possible that, after some time, you discover all the VIs in your application (even most LabVIEW VIs) have been infected, retarding the execution and forcing you to a complex and long cleaning :thumbdown:.

Saludos,

Aitor

Link to comment
So, does scripting suppose a new danger to free VI sharing, like in forums? What do you think? Probably this is one reason NI doesn't want people playing too much with these new tools. Maybe in a few years we'll need antivirus for LabVIEW :blink: .

:) I understand and fully appreciate your concerns, and I think that you've touched on a very real idea, but I prefer to look at it from another angle - with power comes responsibility :ninja: , and I see this as an extremely powerful technique. Like any file that you download from the net - if you don't trust it, then don't use it. At least with LabVIEW VIs you can open the file without fear, so you can check the BD for rougue scripting nodes.

But look on the upside! For example (hypothetically speaking of course ;) ), wouldn't it be great if there was a tool out there that could automatically paste a code snippet in all of the structures on all of your diagrams within a project to register wether every portion of the code in a project ran? Sort of like a statement converage tool?

PS: Commercial: Oh, and if you'd prefer to stay out of the theoretical world and could use such a tool, it's part of our VISTA toolkit - contact Wyatt Meek at V I Engineering :D

Link to comment
At least with LabVIEW VIs you can open the file without fear, so you can check the BD for rougue scripting nodes.

You forget the XNodes. They have the ability to run in the block diagram.

...ok, you need a vi that begins with ";...". But it can be hidden in a fairly complicated example (like the rmb-menu example). :thumbdown:

EDIT:

The combination of XNodes and self-reproducing code makes a powerful "copyright watermark" or an extremely dangerous virus: a vi that runs from the moment you open the block diagram and copies itself to all the vi's (if it doesn't exist there already) of the project or found on HD. You end opening vis, removing the code and when you open the next block diagram it is back there on the "cleaned" vis. :wacko:

Link to comment
I've been rummaging through this idea and I have managed to create a piece of self-reproducing code (I have to admit it's no difficult). It copies it's own code in other VIs, then when those VIs execute, they copy that code in others, etc. As a concept I find it fascinating, but it's a little nasty if you aren't careful.

You're orbiting around the concept of a LabVIEW quine. I've been meaning to raise the same idea in this forum for a few weeks, but I wanted to play around with VI scripting a bit more seriously before bringing it up.

Quines are mostly an academic exercise (unless you're Evil... :ninja:), but they're really fascinating from that point of view. I'd love to see a quine done in LabVIEW. More importantly, I'd love to see lots of different quines done by different LabVIEWers. Care to share the code?

Justin

Link to comment
You're orbiting around the concept of a LabVIEW quine. I've been meaning to raise the same idea in this forum for a few weeks, but I wanted to play around with VI scripting a bit more seriously before bringing it up.

But what would be considered a quine in LabVIEW? In text languages, usually such a program has a string output that contains its code. But in LV, that's not possible (I think). I have developed a VI who creates a new VI with its same code. Does that count? What's my prize? :D

And if so, is it really worth the risk that it gets in the wrong hands?

I'm not sure. It would be a pity some day we should start quarantining all VIs to be sure they have no malign code. On the other hand, the tools are there, easily available to everybody. And when scripting licenses become available, the possibilities will grow much further (documentation, access to all functions and objects...) :ninja:.

Saludos,

Aitor

Link to comment
But what would be considered a quine in LabVIEW? In text languages, usually such a program has a string output that contains its code. But in LV, that's not possible (I think). I have developed a VI who creates a new VI with its same code. Does that count? What's my prize? :D

Since LabVIEW source code is binary by nature (rather than text-based), I think the only way a quine makes sense is if you generate the code into the development environment (e.g. via Scripting). Another idea would be to actually write the binary representation of the VI to disk. I think that would still qualify.

The trick, however, is that a true quine can't require access to its own source code to do its magic. I.e. a LabVIEW quine should run correctly even if its block diagram has been removed.

I'm not sure. It would be a pity some day we should start quarantining all VIs to be sure they have no malign code. On the other hand, the tools are there, easily available to everybody. And when scripting licenses become available, the possibilities will grow much further (documentation, access to all functions and objects...) :ninja:.

Exactly. Just because an idea or tool can be used maliciously, that's no reason for everyone to run away from it. Malicious code is a fact of life in every other language, and humanity still limps along in spite of it.

I suppose some day we'll all wake up and find someone screaming on LAVA about their whole project tree being ruined, and that will suck. But one could argue that having proofs of concept floating around would allow the LabVIEW world to prepare itself for that.

Justin

Link to comment
<snip>

The trick, however, is that a true quine can't require access to its own source code to do its magic. I.e. a LabVIEW quine should run correctly even if its block diagram has been removed.

<snip>

Justin

Does this mean that it can't just copy its diagram/front panel into the new VI? It would have to build it from scratch, right? Hmmmmmm. I am sure that would be difficult.

I think that scripting could do it, however whenever they get around to licensing it.

Thanks,

Bob Young

Link to comment
No, neither the warning text. I think it wouldn't be difficult, but would add more properties and my aim was a code as simple as could be ;-).

Saludos,

Aitor

Now I just add a Run VI method as the last node and I hit the Run Arro(&(*&!@HJ(*&47_)(* :( --- DISCONNECTED

Link to comment
  • 4 weeks later...
  • 2 weeks later...

Although this can be a bit dangerous, as jpdrolet indicates, if it is defanged and modified, then combined with a few other snippets it could be a pretty useful tidbit. I referenced this thread to the guy over on the Inline subVI thread, then I added ref's to a few other threads. If he puts them all together it could result in something pretty powerful if he codes it well.

This is one of the most encouraging things about LAVA to me. Enough people have donated enough snippets that you can search and combine and now come up with answers to a lot of things people ask for that were impossible just a short while ago.

Link to comment

Join the conversation

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

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
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.