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.