Moved to wordpress

Since I spent 90% of the time to format text and especially code, and had to do it all over when blogger decides to restructure the html, I moved to Wordpress. Now I can spend 90% of the time on content instead.

So for more recent posts go to: http://mflerackers.wordpress.com/.

Using decorators and closures in python

Decorators

A decorator wraps a class or method to extend it. In python the syntax used to wrap the original function is @decoratorname. For example let's say the original function A needs to be decorated with B:

def B(a):
  def C(*args):
    return 2 * a(*args);
  return C

@B
def A(x, y):
  return x + y;

print A(2, 3)

Some essential developer tools for OS X

When first turning on a Mac, the first thing I did was installing Xcode 4. I actually expected something on the level of Visual Studio on Windows, though I was a bit disappointed. Sure there are some nice tools, like svn/git repository support, llvm compiler integration and minimal refactoring tools, but the way to work with projects, project dependencies and settings in general is quite puzzling. Maybe in that respect I've been spoiled by Visual Studio, which makes this very very easy. Besides a C/C++/Objective-C IDE there were still some tools I was missing though:

The cloud might be good for something after all

Another day, another rant about how developers underestimate potential crackers. While I actually wanted to write a review about developing on Mac OS X vs Windows, or the fresh install I did of Windows 8, once again I'm surprised by the naiveness of some developers when it concerns security measures in software.

Using encryption doesn't necessarily make your software more secure.

Let's assume you have communication between two applications using network sockets. You don't want to use ssl, but your own solution. This solution consists of encrypting certain traffic using AES and a secret key. Is this more secure than a ROT13? Well, not really. I compare such solutions with sticking a piece of tape to cover the hole of a lock. It might stall a cracker for a moment, but it's not a real deterrent. The security given by the encryption is imaginary.

"But they can't know the encryption method".

Well, even without looking at the code segment, it is still easy to find out the encryption method. Let's go over the possibilities of how the encryption code is linked:

1. You use operating system provided methods.
2. You use OpenSSL as a dynamic library.
3. You use OpenSSL as a static library.
4. You compile your own AES code.

For 1 and 2, a cracker can see which methods your exe links to, so that's very easy. For 3 and 4, a cracker doesn't need your obfuscated code, he can just search the data segment. For AES for example, you need the Rijndael S-box. This is a constant block of data which is easy to spot. So at this point we can agree that they know your method. (People using method 4 might be so smart to obfuscate their data of course).

"But they can't know the secret key".

From the data, they can look for code which uses the data (the calls that use offsets to that data). This code is eventually called from a place where you pass the secret key, which is also constant data. So all in all your secret key isn't that secret.

"But you can obfuscate the key".

True, but all those obfuscation methods can be read and copied, since the binary code is public knowledge.

"So encryption is useless?".

It is, unless a completely secure scheme is used. Using a known secret key is good if that key is external, For example when you encrypt a document, or a user needs to provide it each time. Using a secret key in your application however is not a smart thing to do. Instead use a key exchange mechanism like Diffie Hellman, and (in case of two user apps which can't be verified), a third party service to compare and make sure the shared secrets match and there's no man-in-the-middle (for more information on this see my previous post).

The cloud might be the best solution.

Even though some people believe in obfuscation tools, code will never become unreadable. A machine can read it, so a human with enough knowledge can too. The only possible solution to avoid giving away the code, but still let people use the application might be the cloud. If part of the application runs on the cloud, there's no use in trying to hack the client part. A document editor might allow a user to edit a document, but it is stored on a server, and exporting to desktop formats is also done on the server. Likewise with WebGL it is possible to build a 3D modeler, but the scene is stored on the server, and exporting or rendering is done there as will. While I'm not keen on storing my documents on a service which might disappear any moment, with a good sync to desktop capability I like this solution a lot more than schemes like UEFI Secure Boot.

How not to protect your software

I wrote my first (completed) software package 14 years ago. It was an animation program for creating 2.5D cut-out animation. Once it was ready for distribution, I needed a way to keep users from copying the software. Naively I opted for a simple key registration mechanism which was defeated not long after its release, and a crack was out in no time.

Fixing Sublime Text 2 for a Japanese Windows system

Sublime Text 2 is a programmer’s text editor with build-in Python scripting. Usually I use Programmer’s Notepad as a lightweight text editor, but I decided to give Sublime a try.

Misconceptions about network security

When looking for a secure Flash protocol for our audio and video call transcoding server we preferred supporting RTMPE (and the tunnelled version RTMPTE) since this was more lightweight than the SSL versions. However users didn’t want to use these protocols, and preferred Adobe's media protocol over HTTPS and SSL (both called RTMPS, though the latter one is also known as native RTMPS). They read online (even on wikipedia) that the RTMPE version were not secure. It is hard to argue with users when they have already read the "truth" on internet. While there certainly are issues with the protocol when you don't know what you are doing, it showed that users have a lot of misconceptions about security.