Why a PC is not a Play Station

A few days ago, I bought a game: the Perry Rhodan Adventure (German only). I'm a subscriber of the weekly 64-page novels and yes, I've read all 2436 of them.

The game is nice and I can recommend it.

There is just one issue with it: It doesn't run on Linux. At least not without some pains. First of all, game distributors waste some of the money you pay for a game for a copy protection. I say "waste" because it takes only a few intimate moments with Google to find a patch for this. So the copy protection is a waste of money since it's so easily circumvented, it's a pain for the paying customers (like me who can't play the game) and it doesn't bother the crackers because they never see it.

So after installing the no-CD patch, I could start the game but it would crash. Fiddling with the options in Cedega didn't help, so in a last desperate attempt, I tried the "fail safe settings". Finally, I could enjoy a few hours of gaming.

Final result: After paying good money for the game, I wasted one hour trying to make it work and then three hours to play. That could have been four hours of pure fun.

That's why I usually only buy games for my PS2. I take the DVD and two minutes later, I can play. Two minutes, because the game has a 1 minute 40 second intro. No installation, no driver hell, no looking for the joystick, no bugs, no crashes, no instant messenger which pops up during the last boss fight and you haven't saved for an hour.

Automatically Hacking Computers

Imagine, you had access to the Windows Update servers. What could you do?

No, no write access. Just read access.

Not to the harddisk or the OS, just the normal patch download access via HTTP.

You could automatically hack any software that Microsoft patches (or anyone who supplies security patches for their software for that matter).

Confused?

Okay. Follow along on a little thought experiment. Security patches contain fixes for security bugs. Security bugs allow to do bad things with your computer like turning it into a spam zombie. Or make it steal your bank account data. Or allow someone you've never met to put illegal stuff on your computer like stolen music or pr0n.

The security patch fixes that. But there is a catch. The security fix is a little piece of program with instructions how to install it. Basically, it replaces a piece of program that is already on your computer.

How could someone possibly abuse this? Isn't the security hole fixed after the patch?

Actually, for the kind of attack we're talking about here, this is irrelevant. What is interesting is this: The patch is almost identical with the program that you already have. The difference is a few bytes which fix the security hole.

While it is usually very hard to find a security hole in a program (you'd have to analyze a whole lot of code), the security patch is actually a map to the hole. It tells you exactly what was broken and how it was fixed.

That allows for two kinds of attack: First, you can now easily write a program which can successfully attack all computers which don't have the patch, yet. And you can check if the guys made a mistake with the fix. If they did, you now have a perfect recipe for disaster.

To make things worse, there is only a limited amount of ways to make a program break in such a way that you get a security hole. This means: It is possible to write a program which compares the original code and the patch and which comes up with a virus for the hole which has just been fixed (or not). Automatically.

This program could just sit there, watch the Windows Update servers, wait for a new patch to come up, create a virus from that and distribute it to already cracked websites.

Scientists from three different universities were able to show that it is actually possible to do this.

For you, this means two things: Firstly, whenever a security patch is available, you must install it immediately. Secondly, you must not visit any website until you have installed all available security patches. Otherwise, you're risking to be infected by visiting an innocent website that someone has hacked. Remember, those are vulnerable to the same kind of attack: A cracker could have gained access to the computer of one of the administrators of the site with the attack described above and could have got a copy of the password with the help of a keylogger.

In a few years, we'll have an immune system for the Internet.

Or we won't have an Internet anymore.

Creating a Visual XML Editor

A long time ago, I've complained about XML editors and that there is no decent XML editor out there which you can use as the basis for a nice visual editor for your custom XML format.

It seems my prayers have been heard.

Rewind for GDB

Every developer has used a debugger once in a while. And sometimes, you had this "stepped once too many" problem: You ran your code too far. Since there is no way to go back, your only option was to start all over again.

A guy called "teawater" has just published a patch for GDB which does just that: It allows to reverse the program execution. Kind of an undo for the CPU registers, stack and memory. Can't wait to see this for Java!

Public Talk: Quantum Computing (2nd Try)

After my back is back, I'll give the talk about quantum computing this week, Thursday 17th of April. See this page for details.

IllegalStateException: The PluginDescriptor for the plugin ... was not found

Ever saw this error?

java.lang.IllegalStateException: The PluginDescriptor for the plugin Plugin [org.apache.maven.plugins:maven-resources-plugin] was not found.
        at org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:325)
        at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:212)
        at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:176)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1274)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1542)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:1033)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:997)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:477)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)

When you see this, check:

1. That the JAR file of the plug-in is okay and that it contains a file META-INF/maven/plugin.xml
2. That the pom.xml of the plug-in exists and is valid.
3. That all parent POMs exist and are valid.

Good luck. I've opened this issue to get a better error message.