Here is a little trick that saved my life a few month back when I was dealing with a virtual pure function been called.

In a program I wrote, I had a very very rare bug where the code would crash in a completely improbable way. I finally figured out that it was due to abort() beeing called, and that was crashing the all other threads in random place. Now, where did that call come from was the big question. With one lucky crash dump, I was able to find that it was due to a virtual pure call, obviously due to a boggus cast.

By default, it seems that the virtual pure handler in gcc just call abort, making it hard to debug. The trick I used to find the actual bug was to override the default virtual pure handler:

extern "C" {

static int __cxa_pure_virtual() __attribute__((noinline, used));
static int __cxa_pure_virtual()
{
    assert(0);
    return 0;
}

}

That way, every time a virtual pure function will be called, it will assert instead of simply aborting, giving way more useful information about what's happening.

I don't know if this fits exactly in the "Rant" category, or if I should create a "Praise" one, because I'm not sure if I'm utterly amazed or disgusted, but this definitely gets my attention.

There's one addon for World of Warcraft called Carbonite, which made a controversy some time ago, because it wasn't free. It was even subscription-based, costing a couple of dollars a month to be able to use it. I've been wondering a long time how they were able to do a proper license check, but the addon itself was heavily obfuscated using several layers.

Obfuscating something in a language that's actually plain text is somehow very difficult. I've seen HTML pages encapsulated in a javascript file that would self-unencrypt using RC4 where you have to provide the password, for example. But in the case of Carbonite, the authors wanted to match a certain number of criterias:

1. The process had to be transparent for their subscribers, as they only had to log in with their registered character to unlock the addon;
2. The process had to be limited in time;
3. The process had to be strong and very difficult to circumvent.

Now, when Blizzard decided to release a new policy about addons, forbidding to sell or obfuscate addons, the people at Carbonite released their version 3.001 which was free and somehow unobfuscated. You may want to have a look at this old beast as it's still available for download at wowinterface, but allow me to show you what's interesting in it. Note that future versions of the addon got rid of what I'm going to show there.

In my previous entry, I've been ranting about compiler bugs. I finally discovered that it's absolutely RedHat's fault. Their compiler is a bug pit of hell. I ran the latest gcc testsuite on it, and on Debian's compiler in order to compare. I've stopped after finding 15 bugs in the first batch of basic test, which is like one tenth of the whole list of tests. This is just not acceptable. RedHat's compiler is deliberately buggy, maybe for the sake of "Backward Compatibility", but that's bullshit, especially since we're always writing crossplatform code. We're expecting that a piece of code that compiles and runs fine on one platform would also compile and run fine on a similar one. Which isn't guaranteed by RedHat. I'm now officially boycotting RedHat. Don't use their compiler, and don't use their distribution, because it's compiled with this compiler as well, so you can't possibly trust it at all. Don't bother with RedHat, it's a waste of time and money.

For your interest, here's a list of all the basic gcc bugs I've found active in RedHat's compiler. Again, this is not an exhaustive list, as I got fed up seeing all of these.

19606 28778 32244 33779 34971 35456 35472 36013 36077 36093 36137 36691 38151 38819 40404

UPDATE:

Well, it seems a retail 4.1.2 has them too. Well, not all of them. So I'd need to cross-check them. Well, whatever... RedHat's gcc still has more.

We will be starting a serie about the compiler myths. What people assume the compiler is doing, while the reality is way different. The first part is about static class initialisation.

What defines a good encryption ? Well, it depends on a lot of factors, including the fact if you're shipping or not the encryption algorithm with the encrypted data.

In the case of a PlayStation game, where the hardware doesn't have any built-in encryption system that'll keep the secret algorithm and keys in a safe piece of silicon, you have to be very good at embedding the algorithm, in order to try keeping people out of it as much as possible.

Of course, this is only valid if... the algorithm is actually sensible. Let's see what we have here in the case of Valkyrie Profile, a game that I hacked apart in order to create a french translation of it. Its authors tried to be smart and sneaky, but they failed miserably, probably because they actually tried too much, without proper background knowledge of encryption.