Obfuscated code c++

The whole idea behind obfuscated code is that it's almost impossible to maintain manually. That's why you have a program do it for you. If you want to just write bad code, with single-letter variable names and no whitespace, go for it.

Let me ask you this-- what exactly do you think obfuscated code is? What do you think it's useful for?

http://mindprod.com/unmain.html

Obfuscated code is unreadable to a human mind.I've read it's usefull for minizing the code size and most important making reverse engineering.Correct?

So what's the point of IOCCC if they all use software for doing such thing for them? I thought it's the human that does that.So whoever's program makes the best code, wins.Huh!

Fruny, thanks for the link and thank you both for replies.

Quote:

Original post by bsdpowa I've read it's usefull for minizing the code size

Source code size is not a problem.

Quote:

and most important making reverse engineering. Correct?

No. Obfuscated code does not produce an obfuscated executable. Usually, people who have the code are the maintainers. You do not want to make life harder for them.

You are confusing writing obfuscated code with obfuscating executables, which is an issue for platforms which produce easily reverse-engineerable bytecode (Java, .NET)... This obfuscation is definitely not done by hand.

Quote:

So what's the point of IOCCC if they all use software for doing such thing for them?

Goals of the Contest

Obfuscate: tr.v. -cated, -cating, -cates. 1. a. To render obscure.
b. To darken. 2. To confuse: his emotions obfuscated his judgment.
[LLat. obfuscare, to darken : ob(intensive) + Lat. fuscare,
to darken < fuscus, dark.] -obfuscation n. obfuscatory adj

To write the most Obscure/Obfuscated C program under the rules below.
To show the importance of programming style, in an ironic way.
To stress C compilers with unusual code.
To illustrate some of the subtleties of the C language.
To provide a safe forum for poor C code. :-)

Quote:

Original post by bsdpowa Obfuscated code is unreadable to a human mind.I've read it's usefull for minizing the code size

For C/C++ code, minimizing the source code length does not minimize the object code length.

Quote:

and most important making reverse engineering.Correct?

For C/C++ code, obfuscating the source code doesn't make it any more difficult to reverse engineer the object code. Thus, the situations in which you need obfuscation are few and far between.

Quote:

So what's the point of IOCCC if they all use software for doing such thing for them? I thought it's the human that does that.So whoever's program makes the best code, wins.Huh!

We're talking about two different things here, so I'll differentiate between the two.

Your average non-IOCCC code obfuscation usually comes about as the result of a nervous manager who's anxious to protect the intellectual property contained in source code that's being licensed out. In this situation, obfuscation isn't germane to the software's function; it's something you do to it afterwards. Nobody wants to program directly in obfuscated code, so you'd have to maintain two codebases, one obfuscated. A programmer would have to take pains to keep the functionality of the two codebases in sync. It would take a huge amount of time, for no good reason. This is where obfuscation programs are useful.

IOCCC is a little different. Here, the very point of the code is to be obfuscated, and the judges have all seen all the regular obfuscation techniques before and are bored by it. It's a more creative effort than anything else, and the results are rarely useful. It is, however, a fun way to keep up to speed on the more obscure features of a language (see my recent post here [wink]).

It should be noted that IOCCC entrants will sometimes write programs specifically to help them generate their entries, simply because to do it by hand would be impossibly involved. These programs are often ingenious in themselves.

Thank you very much.

EDIT:

Quote:

Original post by Sneftel These programs are often ingenious in themselves.

True.

Thanks again guys for clearing some misunderstandings about it.

Quote:

Original post by Sneftel Quote: Original post by bsdpowa Obfuscated code is unreadable to a human mind.I've read it's usefull for minizing the code size For C/C++ code, minimizing the source code length does not minimize the object code length.

Technically, using shorter global variable names/function names/class names will probably reduce the size of the symbol table. On the order of, oh, say a few kilobytes in a multi-gigabyte project - time much better spent in other areas.

Example:

panda@industry:~$ cat pie.cc#include <iostream>using namespace std;void pie ( void ){        cout << "pie" << endl;}int main ( void ){        pie();}panda@industry:~$ cat p.cc#include <iostream>using namespace std;void p ( void ){        cout << "pie" << endl;}int main ( void ){        p();}panda@industry:~$ g++ pie.cc -o piepanda@industry:~$ g++ p.cc -o ppanda@industry:~$ ./piepiepanda@industry:~$ ./ppiepanda@industry:~$ ls -l pie p-rwxr-xr-x  1 panda panda 14010 Apr 10 09:20 p-rwxr-xr-x  1 panda panda 14016 Apr 10 09:20 pie

In this case, we saved a WHOPPING 6 bytes, or about 0.0428% of the total size.

I saved more bytes on my windows computer, but the EXE weighed in at over 500k instead of this measly 14k, meaning the percentage was even smaller. I'm guessing turning on optimization would likely further reduce the size difference.

Quote:

Original post by MaulingMonkey Technically, using shorter global variable names/function names/class names will probably reduce the size of the symbol table. On the order of, oh, say a few kilobytes in a multi-gigabyte project - time much better spent in other areas.

Which gets stripped anyway.

Quote:

Original post by Fruny Quote: Original post by MaulingMonkey Technically, using shorter global variable names/function names/class names will probably reduce the size of the symbol table. On the order of, oh, say a few kilobytes in a multi-gigabyte project - time much better spent in other areas. Which gets stripped anyway.

Assuming it's not a dynamically linked library - which is actually a valid assumption most of the time. To continue on the above example:

panda@industry:~$ strip p piepanda@industry:~$ ls -l p pie-rwxr-xr-x  1 panda panda 4280 Apr 10 09:26 p-rwxr-xr-x  1 panda panda 4280 Apr 10 09:26 pie

Yup, exporting loads of symbols from a DLL can be very painful with regard to image size, especially if they are namespaced. Essentially the mangled version of the function is exported, and it is not short by any means.

Quote:

Original post by MaulingMonkey Quote: Original post by Sneftel Quote: Original post by bsdpowa Obfuscated code is unreadable to a human mind.I've read it's usefull for minizing the code size For C/C++ code, minimizing the source code length does not minimize the object code length. Technically, using shorter global variable names/function names/class names will probably reduce the size of the symbol table. On the order of, oh, say a few kilobytes in a multi-gigabyte project - time much better spent in other areas.

[/quote][/quote]

The symbol table in only included in debug builds, and it's most useful if it's descriptive.

Quote:

Original post by MaulingMonkey Quote: Original post by Fruny Quote: Original post by MaulingMonkey Technically, using shorter global variable names/function names/class names will probably reduce the size of the symbol table. On the order of, oh, say a few kilobytes in a multi-gigabyte project - time much better spent in other areas. Which gets stripped anyway. Assuming it's not a dynamically linked library - which is actually a valid assumption most of the time. To continue on the above example:

In which case you should be using a construction method and an interface defined in a header or somewhere else - i.e. COM.