I'm not entirely sure what is this for. This won't stop decompilation because it doesn't affect compiled code - constant folding is part of C language, "\x0A" is the same thing as "\n". I guess you are losing function names, but you could get the same by stripping debugging information. Strictly speaking, the only obfuscation that could be worth something (an optimization not mandated by the specification) is 0x0000000000000000 ^ thing, but the compiler likely would optimize that out realizing how silly that is.

I think a proper obfuscation tool for C should work at lower level than C source code.

Indeed, the current transformations implemented by my obfuscator aren't particularly sophisticated, at least in comparison to some of the obfuscator's I evaluated such as Tigress[1] which can transform your code into a JIT.

But for the use case that my dissertation supervisor had in mind it works very well (gravypod outlines this use case well[2]).

Most of the work in this project was the creation of the underlying architecture for parsing and transforming C and C++ code. Now that this is done, implementing more sophisticated transformations should be fairly trivial.

1 - http://tigress.cs.arizona.edu/

2 - https://news.ycombinator.com/item?id=17478448

I think this will not fly in court. Sourcecode is what you use to edit your program. Obfusicated code is like an assembler: an intermediate product. I think yoir use case doesn exist, at least here in Germany,

edit: I misunderstood your use case, still I dont think obfusicated code is source code by definition

> I think yoir use case doesn exist, at least here in Germany

that explains a lot.

People have been looking into Microsoft's Warbird obfuscation[1] and it looks pretty impressive.

[1] https://github.com/airbus-seclab/warbirdvm

It's sad and scary how far they're going in attempting to stop people from inspecting the code running on the machines they own.

How is it sad and scary? Warbird is usually used near license/DRM stuff. There's serious money on those parts of the code doing meaningful things.

Nice to see this getting some traction.

To give a bit more context: this is a C/C++ obfuscator I have built for my BSc Computer Science dissertation. It's built on the clang parser and while it doesn't implement any fancy obfuscations right now, it does offer a solid base for further obfuscations to be implemented. I figured I would submit it here to see what you guys think of it and to figure out whether I should pursue developing it further.

For those interested in the details, I have uploaded my dissertation here: https://picheta.me/c_cpp_obfuscator.pdf.

You really shouldn't open up a compiler running on your own device, especially as your own user. https://security.stackexchange.com/questions/138881/is-it-da...

Very true. I'm running it on a droplet that doesn't have anything else important on it, but I'll get the obfuscator dockerized anyway just in case.

Edit: It is done :)

As far as I can tell, the "rename identifiers" feature also renames externally-visible identifers, which should remain the same if the code ought to keep working.

Which identifiers did it rename that you think should have been kept?

The 'compare' and 'generic_fizz_buzz' ones in the Generic FizzBuzz example.

edit: Ah, so the algorithm is deterministic (compare is always mapped to o_9277c6cd6b1431c4622b3bb03df7c6ef) and the assumption is that all compilation units are subject to the same obfuscation mechanism? Doesn't really match the use case where you give the obfuscated code to someone else to build into their program.

How does it decide whether a call to compare should be replaced by a call to o_9277c6cd6b1431c4622b3bb03df7c6ef or whether compare is defined in some external library to be resolved at runtime? At the moment, it is unconditionally replaced, probably with some whitelist for libc functions?

edit2: nope, "memcmp(a, b, 42)" is also name-mangled into something else that won't result in a call to memcmp. What's keeping the qsort in the original GenFizzBuzz example?

I'd probably restrict the name mangling to local variables, functions without external linkage and possibly struct field names. Everything else is likely just too hard to do automatically and will require whole-program analysis which you almost certainly can't do if you're handing out obfuscated source code.

It checks whether the symbols are defined in an included header file. The `compare` and `generic_fizz_buzz` are not defined in any header files that are included so they are obfuscated.

One example of this is `printf`, it would be obfuscated if it wasn't for the fact that it's defined in `stdio.h`. You can try removing that `include` and you'll see that it is then renamed.

The name it creates for each identifier is the md5 of the identifier.

That explains the memcmp: I just declared it locally before calling it. I think it's not incorrect to do as long as my declaration exactly matches the actual libc one (otherwise, the behaviour is undefined). Not 100% sure, though.

Academically, kudos! This seems cool and a nice idea but...

Speaking practically this strikes me as one of "this shouldn't be an online tool" things.

It sends the source code to the server and presumably if you are obfuscating your code you want it to be kept secret. So, I'm not saying this site would do this, but sounds like a great way to harvest code people think is sensitive.

I agree completely. I'm warmly impressed that this is getting attention on HN. To give a bit more context: I wrote this obfuscator for my BSc dissertation and created a web version to better show it off and allow my supervisor to more easily play around with it.

I have now graduated and so I'm wondering what I should do with this project. Two options: open source it or try to sell it. Mainly I'm wondering whether there is actually a big enough market for something like this, I thought HN might help me answer that question so I submitted it :)

Also brand new: our fantastic online C/C++ de-obfuscator!

<joke>I assumed the title referred to an online meeting of the C++ standards committee.</joke>

c++ is self offuscating. Drive in the final nail by erasing the comments.

What’s the use of something like this

I'm assuming similar use cases to things like Proguard. If you need to provide your client with C code because they need to compile for a large range of architectures but they're not allowed to see the source code. It's a very unusual circumstance but it does happen.

Wouldn't you use a tool to do that automatically in your build process? I can't see using a web page to obfuscate an entire project, one file at a time.

I created the web page just as a demonstration more than a practical way to use it. So yes, you'd likely want a CLI app and feed your whole project to it.

wouldn't it be better to compile the libraries yourself? how many architectures are there? ia-32, amd64, arm, mips, power, ia-64 and that's about it.

Sometimes that may not be an option. It may not be linkable into an existing project's code base. Maybe the other project doesn't use an open source compiler. Maybe the client has a custom ISA.

Again if you're in need of a source code obfuscation tool you're already in a pretty strange place.

No template support?

template <typename T> T add(T a, T b) { return a + b; }

Is there a list of C++ features it supports?

Afraid I don't have a list right now. C++ is a large language so I didn't get a chance to test it all out and make sure it works.

Thanks for sharing this. I'm a C newbie so it was neat to play with. Don't stop making and sharing neat stuff!

It doesn't seem very keen on handling lambdas in C++ mode:

#include <stdio.h>

int main() { return [](){return 5;}(); }

Results in unhandled exceptions.

Indeed. I haven't implemented support for those yet :)

can it defeat moss? https://theory.stanford.edu/%7Eaiken/moss/

Doesn't work for basic C++:

#include <stdio.h>

#include <stdlib.h>

#include <iostream>

int main() {

    int someNum = 52;

    printf("Whale exists that does %d hz\n", someNum);

    std::cout << "Out";

    return 0;

}

/var/obfuscator/code_624952c3a4d4ebc7df41c830d3572272.c:3:10: fatal error: 'iostream' file not found

Stopping due to parsing error of severity Fatal

-----

Removing the include for iostream yields:

-----

/var/obfuscator/code_c963503bab4beb00483856ecd675548d.c:7:9: error: expected expression

Stopping due to parsing error of severity Error

You're compiling it in C mode. Switch to C++ using the dropdown.