To content | To menu | To search

Code Rant

Where we rant about programming failures.

Entries feed - Comments feed

Thursday, March 3 2011

Why "open source" is good

Not so long ago, I made a post explaining Why open source is bad. I'll try to redeem a bit myself and try to explain why there are some very good aspects of it, and why closed source is sometime excessively bad. As I mentioned in my previous post, I don't think open source should be used as a selling point in the "it's open source so it has to be good" way. Instead, it should be used as a selling point in the "we're transparent" way.

Continue reading...

Tuesday, January 4 2011

How to fail encryption, part 2

One of the very first post I've made was talking about encryption, and how to fail it. Okay, that was a very easy encryption, but the base principles remain the same: don't be stupid, aka, know what you're doing. Well, I'm joining the bandwagon here, but it seems Sony's programmers didn't really try to understand their crypto handbook, and implemented it without really knowing what they were doing. As a result, all of the private keys for the PSP and the PS3 (including the one hardcoded in the CPU die) are leaking with simply two signatures made with them.

Good job, really.

Source: fail0verflow

Thursday, November 18 2010

OCCI-gateway, or why C++ is a horrible language

I don't really know to which category this should fit, but I guess "code rant" is probably quite appropriate. I'd like to discuss a bit about why C++ is a horrible language, by adding a few arguments towards Linus.

Continue reading...

Monday, December 14 2009

PS: Don't blow up the stack

The title of this article is actually something I wrote on the corner of the whiteboard at work. We've recently had a few issues which all dealt with stack abuses. We added some instrumentation to help us, and I thought about sharing that a bit.

Continue reading...

Friday, October 16 2009

Pure virtual handler

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.

Monday, October 12 2009

Don't trust the compiler: part #3

Okay, that's an easy one. But still. See how the compiler can actually turn good-looking code into code that contains security flaws:

http://threatpost.com/blogs/researcher-uses-new-linux-kernel-flaw-bypass-selinux-other-protections

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...

Sunday, August 30 2009

Another failed attempt at conceiling data

Another notable game developer also tried to conceil its game data on the disc. The game's Kingdom Hearts 2. Their idea was to identify each file by the hash of its name. Smart don't you think? Well, not quite...

Continue reading...

Friday, August 28 2009

Valkyrie Profile, or how to fail encryption

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.

Continue reading...