Flux RSS

Code Rant

Where we rant about programming failures.

Entries feed - Comments feed

Wednesday, September 30 2009

Lua tricks: Carbonite obfuscation

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.

Continue reading...

Saturday, September 26 2009

Don't trust... the other devs

Picture the situation. You've just spent 2 days trying to figure out a bug that randomly crash your application. You've nailed it down to a memory corruption somewhere, and you finally find that it's due to an out of bound access to an array. A single little assert you have saved you hours of heavy debugging...

Continue reading...

Saturday, September 19 2009

Don't trust the compiler, especially RedHat's

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.

Friday, September 18 2009

Don't trust the compiler: part #2

In his previous article, yazoo gives an example about why you shouldn't trust the compiler. But all in all, this is because of the user (you, me...), and not because of the compiler. Instead of saying "don't trust the compiler", we should rather say "don't trust your knowledge of the compiler", as a hint about the fact WE need to make the right code in input, and then we trust the compiler to do the right thing at the end, right ?

All in all, if some programmers won't trust the compiler about the optimization of the code, most programmers will trust it about the correctness of the code. Having a code that runs properly is usually way more important than a code that runs fast. So we trust the compiler religiously about its correctness, but we're wrong. Here's why.

Continue reading...

Monday, September 14 2009

Don't trust the compiler: part #1

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.

Continue reading...

- page 3 of 4 -