http://b.webring.com/navcgi?ring=esolang;list

Use an interpreter and one of these languages. Consider unlambda--only three core intructions, and two for I/O. This, for example, is an Unlambda program that calculates and prints the Fibonacci numbers (as lines of asterisks)



Minimalist languages (obviously) are extraordinarily difficult to understand. Feel free to remove all debugging tricks, etc., because no one will *ever* understand this code enough to patch it. Use it for routines that are necessary but that don't have to execute quickly. Use huffmann coding to compress it tremendously and reduce readability even more.

Writing programs in Unlambda is very easy; function and variable definition is done via macros. Your source can look a lot like scheme or lisp. But when it's "compiled"... abandon all hope ye who enter here!

The interpreter will still execute asm..


Actually, I do worry about this somewhat because with the speed of today's computers, you could do things such as this without too much penalty.

-nt20

Of course. But what are you going to do? Patch the interpreter? This is most useful when you don't want someone to reverse engineer something rather than prevent them from copying.

It would make it next to impossible to keygen, for instance. (RSA can do that, too)

It would protect something like a proprietary neural net whose weights you don't want revealed.

You could implement your symmetric decryption code here and not worry about revealing the key. (I'm not sure why you'd need to do this, since the whole point of public key crypto is that you don't have to worry about revealing the key.)

I wonder if you can prove anything about the difficulty of writing an unlambda decompiler...

Hi Mike

Your idea for using minimalist languages to obfuscate programs is very interesting.
You can find similar idea here:
http://www.woodmann.net/fravia/new_anor.htm
I believe that obfuscation is one of the most powerfull ways of software protection.
Somebody else?

Greetings!
Maldoror

While on some levels I agree with you, eventually the whole thing kinda has that rotting smell to it.

This is the old syndrome of what I have heard deemed "security through obscurity". In fact, if you think about it, almost all "security" features nowadays consist of this technique, especially in the software market. For example, when AsProtect first started making its rounds, one of it's "strengths" no doubt was how it mucks the import table on you. SO now here you have a program that is "protecting" your software, thru the glorious method of hoping no one knows what it is doing. In fact in my opinion this is a very lame technique. Of course along came some people that knew how to use a debugger and understood the PE file format, and figured out what it was doing in that area, and took it down for the count.

:the weakness is in the outside world:

Unless you come up with your own propietary interpreter, there will always exist documentation on how the interpreter works, and therefore the *racker is 60 to 75% closer to his goal. That is why commercial protection in my opinion becomes easier, you have a trial to follow at least.

I was running a web server at one time and I didn't have a firewall, etc. A guy once asked me why not and I told him that no one knew the IP address, and even if they did, they wouldn't know what the server was, or what the password was to get in. So he mentioned to me "security through obscurity, eh?". Of course yes that was what I was hoping to do. But as you think about it, is that really "security" ? NO, it's just a matter of time. The only reason you can get away with it for a while is because the information is not public. I don't consider a security system simply based on witholding information as very secure. (although there are many today). For example, having a voice or fingerprint scanner at a bank to allow you into the vault would be more TRUE security than having a code key pad with a password.

The best protection you CAN have in my opinion is the encrypted code fragment, such as ASProtect now allows you to do. This is still a method of "obscurity", in that you would need to know the correct "key" to decrypt the code, but it is not some lame attempt to simply mess with the O.S. and basically pretend that you know more about file formats than anyone. This is actually REAL security. However, no matter what you write, once it gets on the machine, it will be executing intel opcode, and thus can be reversed, since that opcode is well documented. I do not believe that it would be long for someone to watch what the interpreter is doing and pretty much figure out its operation. The whole history of compilers and interpreters is very commonplace and most new ones no doubt use the same techniques (for instance, LEXX and YACC). Once you know the syntax, the code is at your feet.

But I do agree that initially it would make things more difficult, and basically your true defense lies in teh *racker's boredom !


PS: Geez, Ulambda, Mouse, reMouse; who has time to write all this swill?....a program you can't read after you've written it isn't worth much..

-nt20

I know that obscuring code usually gets you nowhere. I've reversed enough obscured code to know how futile it is (I wrote almost all of AccessData's password crackers). It's just that in this case, the instruction set is particularly suited to obfuscation in a way I've never seen before.

I'd advertise that it's written in ulambda. I know that you can trace the execution, it's just that it's so mindbogglingly dense that trying to 'grok' the code (often referred to a zen around here) is virtually impossible. It might be possible to 'decompile' it by some kind of pattern matching, but I don't know how hard that is; thus the comment about proving some measure of difficulty. Writing decompilers is hard in a nice readable language like C. This could be a nightmare. Remember, there are no numbers, variables, data structures, labels, or functions with more than one variable built in to ulambda, so they'd all have to be pattern-matched from the code.

You wouldn't actually code in ulambda; you'd have a macro language that 'compiles' to ulambda. I don't think it would be very hard to write a program that translates from scheme to ulambda, for instance. The code you maintain is in scheme, much friendlier.

If the interpreted language is very high level, like VB or java, we all know how easy it is to crack. This is akin to cracking a program that has been converted to a big net of nand gates.

If you want an example, take a look at the Solar crackme in the Hall of Fame part of the crackmes.de site. It looks like it's been around for a few years now, and no solutions have been posted.

Cheers!
Kythen