Great moments in protection failure!

It seems that more and more these days I find protection to talk about here only because of the epic badness of it. I'm sure there's some good out there, but I haven't seen any of it lately. Anyway, on with today's installment of "Great moments in protection failure!"

Looking through an anonymous application that does a whole boat load of decryption of data from a source. The main application was compiled, and released with the symbols still in it, so IDA gives me not only function names, but function prototypes, and in a few places, variable names. You know, this could be a simple mistake, and crap happens, so I'll cut them some slack on this, as this isn't even the failure in question.

While digging through the application and analyzing the encryption bits (the only things really interesting in there to be honest), I find that the guts of the encryption routines have been pseudo-obfuscated. I'm assuming that this code is from a library that probably came this way from the original manufacturer. By the looks of it, it's some tool that they run after they compile the library, and it changes all the non-exported function names in the library to a long string of hex characters. For example, they might have a function named "000b00f05c86d185". So, when you're looking at the disassembly, you see:

call _00b00f05c86d185

This is fine, and a good idea if you're trying to hide what your functions do, but now to the facepalm moment.

In this code, they call the obfuscated functions, and if they return an error value, they print a nice debug string that contains all the details about the error. Including the original name of the function!

So, all their attempted obfuscation is undermined by their proficient use of error messages.

Let's use our example function from above. You'd see something like this (in C pseudo-code).

if(00b00f05c86d185() != 1)
{
printf("GetKeyValue() returned error\n");
return 1;
}

Gee. I wonder what the REAL name of "00b00f05c86d185" is?