Obfuscation challenge

[Black Pearl]

Here the idea:

Code is placed inside structure (sequence or other); auto grow of; sized to Icon size

VI is placed on top of structure to hide the code

Both are grouped or locked, so moving the Vi don't reveal the code below.

Problem 1:

I can't size any structure small enough to fit behind a standard icon. Not even with private properties.

Workaround: Place it behind an express VI (ha, finally found out what they are good for!).

Problem 2:

I can't lock or group the elements. A private property (write only) exists, though.

I don't want to dig into (use) external nodes (I use LV 7!), because of upward compatibility issues. But they hide behind icons (though unlocking with the ini keys shows larger sequences). Even more, they are protected from resizing and grouped with the loop (using private properties I see the timed loop having to structures beside, can't resize these with private properties though).

Any ideas?

Felix

[jdunham]

QUOTE (Black Pearl @ May 6 2009, 09:37 AM)

Any ideas?

Umm, what problem are you trying to solve? If its for fun or are you looking for the best way to hide some intellectual property?

[Black Pearl]

QUOTE (jdunham @ May 6 2009, 06:50 PM)

Umm, what problem are you trying to solve? If its for fun or are you looking for the best way to hide some intellectual property?

Both.

Felix

[jdunham]

It seems like the VI Analyzer will make short work of your attempts to hide code, so personally I would choose a different approach for keeping secrets secret. At the very least make sure there is lots of other stuff on the diagram, but in general, steganography is never as secure as cryptography.

[asbo]

Some ideas I've stumbled across:

- Dump everything into a subVI and paint the VI's icon to look like a wire.

- Put everything in a sequence structure, turn off Auto-Grow, and resize it to hide what you don't want seen.

- Paste a plain-white bitmap over top of everything.

Like jdunham said though, if you're looking to protect code, use proper methods like passwording the BD.

[Black Pearl]

Ok, now it's more going to be fun in hacking than real work (*).

Some more specs on that point:

- No SubVis, because it is the absolute easy hacker's trick to exploit the SubVi boundary in pre LV8 code. The Inlining VI (with some messing up and removing documentation) is already done, but not polished yet.

- I want to inform the (informed) developer (via placed icon) that security Vi is in place.

Furthermore, I'm pretty sure I can even fool VI analyzer, just by using the boundary trick and loading a Filter VI of the same name in the Analyzer context, that just skips the VI where that code resides.

* So why I would say it's more on the fun side now, is that the skills you need to hack that would easily allow you to write the code on your own in less time.

Felix

[PaulG.]

QUOTE (Black Pearl @ May 6 2009, 03:03 PM)

I'm pretty sure I can even fool VI analyzer, just by using the boundary trick and loading a Filter VI of the same name in the Analyzer context, that just skips the VI where that code resides ..

The VI Analyzer? I don't know about that but I don't know how you can be invisible to the View>VI Hierarchy window.

[Black Pearl]

QUOTE (PaulG. @ May 6 2009, 09:19 PM)

The VI Analyzer? I don't know about that but I don't know how you can be invisible to the View>VI Hierarchy window.

I havn't tested, but if you can mimik the VI that passes all VI references (by loading a vi with the same name in the same context/namespace before the user launches the analyzer), and then you can filter. Just name the original file something else, and you don't loose the original functionality. Including it in your distribution will be illagal, but you can load a copy into memory, rename it, and discard it when done.

As said, I can't promis that it works. I hav tried (unsucessfully) to hack the 'New...' dialog to get access to control templates (*.ctt) there, but they used a reference to a tree control (only way to deal with trees, so no intention I guess), otherwise I would just have renamed the original Vi and addded the ctt.*'s to the dialog.

Felix

[jzoller]

QUOTE (PaulG. @ May 6 2009, 01:19 PM)

The VI Analyzer? I don't know about that but I don't know how you can be invisible to the View>VI Hierarchy window.

Wasn't there a system flag that allowed VI's to be hidden from the hierarchy?

Rolf mentions it at http://forums.lavag.org/index.php?s=&s...ost&p=11539

Joe Z.,

[PJM_labview]

QUOTE (jzoller @ May 6 2009, 02:18 PM)

Wasn't there a system flag that allowed VI's to be hidden from the hierarchy?

Rolf mentions it at http://forums.lavag.org/index.php?s=&s...ost&p=11539

Joe Z.,

Ya, system VIs (not a flag but a property or method ).

But again this is easy to work around this.

PJM

[gb119]

QUOTE (Black Pearl @ May 6 2009, 07:03 PM)

Ok, now it's more going to be fun in hacking than real work (*).

[...]

* So why I would say it's more on the fun side now, is that the skills you need to hack that would easily allow you to write the code on your own in less time.

Felix

I think it would more fun to have a coding challenge to write the most obfuscated code that does some defined task that does not employ any 'graphical' code hiding techniques and instead relies on daft ways to achieve a trivial operation. One my favourites is something like the following:

http://lavag.org/old_files/monthly_05_2009/post-3951-1241686658.png' target="_blank">

Of course this sort of the challenge is also a good test of the LabVIEW compiler's ability to optimise the code...

[Grampa_of_Oliva_n_Eden]

QUOTE (Gavin Burnell @ May 7 2009, 05:00 AM)

I think it would more fun to have a coding challenge to write the most obfuscated code that does some defined task that does not employ any 'graphical' code hiding techniques and instead relies on daft ways to achieve a trivial operation. One my favourites is something like the following:

Of course this sort of the challenge is also a good test of the LabVIEW compiler's ability to optimise the code...

About four years ago we started an "Obfuse Code" challenge in the Braekpoint on The Dark-Side where we where trying to implement the "Hello World" example from the world of C. In post #40 of that thread I posted an example (that is now probably dated) that has the binary of a sub-VI saved as a constant on the diagram. The constant was writtein to disk and the VI server was used to run the sub-VI... and I think I deleted after teh run. That method escapes the VI Analyzer. Check out that thread for some interesting obfuse examples. Technically the competions is still open becuase we never agreed on the rules.

Ben

[Rolf Kalbermatter]

QUOTE (neBulus @ May 7 2009, 07:45 AM)

About four years ago we started an http://forums.ni.com/ni/board/message?board.id=BreakPoint&view=by_date_ascending&message.id=128#M128' target="_blank">"Obfuse Code" challenge in the Braekpoint on The Dark-Side where we where trying to implement the "Hello World" example from the world of C. In post #40 of that thread I posted an example (that is now probably dated) that has the binary of a sub-VI saved as a constant on the diagram. The constant was writtein to disk and the VI server was used to run the sub-VI... and I think I deleted after teh run. That method escapes the VI Analyzer. Check out that thread for some interesting obfuse examples. Technically the competions is still open becuase we never agreed on the rules.

In newer versions of LabVIEW the need to save the VI to disk would not even be necessary since you can create an in memory VI object just from the binary stream using private methods.

Rolf Kalbermatter

[shoneill]

QUOTE (rolfk @ May 7 2009, 04:12 PM)

In newer versions of LabVIEW the need to save the VI to disk would not even be necessary since you can create an in memory VI object just from the binary stream using private methods.

Rolf Kalbermatter

Example?

Shane.

[Rolf Kalbermatter]

QUOTE (shoneill @ May 7 2009, 09:50 AM)

Example?

Shane.

Just a quick and dirty example. I didn't try to get around having to supply a valid path to the method note.

Download File:post-349-1241721479.zip

It's LV 8.0 because although the node is there, it returns an unimplemented error in 7.1.
 

(04/20/2014rk, the original link got lost in an earlier LAVAG server crash)

 

Attached is a more user friendly version of that VI. It uses the OpenG file library to create a temporary file name and makes the turnaround through a disk file in LabVIEW versions prior to 8.0.

 

VISRV Create VI from Binary Buffer.vi

[gb119]

QUOTE (rolfk @ May 7 2009, 06:38 PM)

Just a quick and dirty example. I didn't try to get around having to supply a valid path to the method note.

http://lavag.org/old_files/post-349-1241721479.zip'>Download File:post-349-1241721479.zip

It's LV 8.0 because although the node is there, it returns an unimplemented error in 7.1.

Rolf Kalbermatter

Hmmm, I think for a competition one might want to disallow undocumented methods - I was thinking of possible "unhelpful but working" solutions to homework problems. The sort of thing that if you can explain why it works then you'd probably have been able to the LabVIEW homework already type.

For the original purpose of concealing algorithms that is pretty sneaky - I assume the buffer contains the compiled code, so presumeably a simple constant holding the buffer would break on LV version changes ?

I sure hope that my equipment suppliers don't start pulling these tricks in the code they ship with kit - some off them are a little twitchy about their control algorithms which wouldn't be a problem if the rest of their code wasn't so dire.

[Grampa_of_Oliva_n_Eden]

QUOTE (Gavin Burnell @ May 7 2009, 03:33 PM)

... break on LV version changes ?

...

Not much different than sharing a VI with the diagram removed.

Ben

[Rolf Kalbermatter]

QUOTE (Gavin Burnell @ May 7 2009, 02:33 PM)

For the original purpose of concealing algorithms that is pretty sneaky - I assume the buffer contains the compiled code, so presumeably a simple constant holding the buffer would break on LV version changes ?

Actually its a bit more flexible than that I think. However there are for sure difficulties.

Rolf Kalbermatter

[crelf]

Not an obfuscation per se, but check out this little snippet I found in someone's code:

[TobyD]

QUOTE (crelf @ May 11 2009, 01:40 PM)

Not an obfuscation per se, but check out this little snippet I found in someone's code:

Nice. :thumbup:

I saw a similar piece of code a couple of days ago. Mine can't be reduced to a constant, but there is a lot of room for improvement...

http://lavag.org/old_files/monthly_05_2009/post-8758-1242078190.png' target="_blank">

[jcarmody]

QUOTE (Gavin Burnell @ May 7 2009, 03:33 PM)

I was thinking of possible "unhelpful but working" solutions to homework problems.

That would be HILARIOUS!!! Solving HH questions with obfuscated (or Rube Goldberg) code!

I guess we'd have to give them at least one chance to demonstrate a willingness to do the work themselves before posting anything unkind...

[LAVA 1.0 Content]

Thought experiments, please answer the following questions without using LabVIEW

QUOTE (crelf @ May 11 2009, 10:40 PM)

What is the output value of the 'Select Function'

1. The same as the input value
   
2. The invert of the input value
   
3. True
   
4. False
   

QUOTE (TobyD @ May 11 2009, 11:46 PM)

Nice. :thumbup:

With which primitive(s) could the Equal and Select primitives be replaced?

1. and
   
2. 
   
3. , with y = 1
   
4. , with Type as Boolean
   
5. and , with Type as Boolean
   
6. Another code snippet
   

Ton

[Rolf Kalbermatter]

First question:

1. True
   

Second:

1. , with y = 1
   

It always amazes me to see such code snippets in someone elses program. I once had an application that was using the Select function exclusively to do just about every possible Boolean operation you can think of including AND, OR, NOT. I just can't imagine this to be easier to do than using the proper primitive instead.

But maybe that is because I did actually learn Boolean Algebra in my electronics education.

Rolf Kalbermatter

[gb119]

QUOTE (jcarmody @ May 11 2009, 11:11 PM)

That would be HILARIOUS!!! Solving HH questions with obfuscated (or Rube Goldberg) code!

Actually I did it for real http://forums.lavag.org/who-will-help-me-t9851.html&p=40521#entry40521' target="_blank">once last year but nobody else got it on the act (possibly because writing artisctically bad code is hard work !)

[hooovahh]

I haven't dabbled in scripting much, but could you code a VI using scripting? I realize that there are many steps to creating objects on the block diagram, but could I write a VI which makes a VI and runs it?

It would be confusing to people who have never heard of scripting, they would just see a whole lot of property/invoke nodes and when they run it a whole UI with code would appear.