I hope to find some more time in the next weeks to improve my algorithm before the contest ends at the end of february.

One might expect that the return value of open() is checked and if it is undefined, the die() function is executed. But what actually happens is that the string “>$pidfile” is checked. And if it is undefined, the die() function is executed. Since this string will never be undefined (at least “>” will always be present), the die() statement also will never be executed. So if open() ever fails, you simply wouldn’t notice.

The solution is simple: parantheses!
open(PID, ">$pidfile") || die "Can't open pid file: $!\n";

The concept is simple: macros. Predefined and selfdefined macros. The following is some very basic C-code which should give an impression on how it can be done:

#include <stdio.h>

#define LOG(str)    log_msg(__FILE__, __LINE__, str);

void log_msg( const char *file, int line, const char *str ) {
    printf("[%s:%d] %s\n", file, line, str);
}

int main( void ) {
    LOG("foo");
    LOG("bar");
    return 0;
}

__LINE__ and __FILE__ are predefined macros which get expanded to the respective line number and file name.
The output of the program is:

[test.c:10] foo
[test.c:11] bar

• prestige
• money

While this makes sense for companies, from private researches one would expect nobler reasons like the simple desire to learn and share knowledge. For some researchers this might be the case, but there are not too many of them. One not so good example of the recent past is the stoned bootkit which was presented at the Black Hat 2009 in Las Vegas.

The author claims that his bootkit breaks TrueCrypt. High words. When looking at the project in detail, one finds out that the main concept of bootkits is not new. In fact, the theory is well known since a couple of years. In addition, many projects already implemented this concept.

The basic idea of a bootkit is similar to a rootkit. A bootkit is malicious software which gets written to the master boot record (= MBR) of a computer. But when are attackers able to write to the MBR of a victims computer? Basically there are two possibilities:

• The attacker has physical access to the machines
• The attacker has administrator privileges on the machine

In both cases, the game is simply over. An attacker which has either physical access or administrator privileges is no attacker anymore. He then owns the computer. Everything which happens from this point on is not of relevance anymore. Also, no software can help in such a case. The machine must be reinstalled.

Since the stoned bootkit lives in the MBR, the author implicitly assumes the victims computer to be already compromised. Otherwise, the bootkit simply can not reach the MBR. Of course, this does not break TrueCrypt in any way. Not even approximately. How can TrueCrypt ever defend a computer which already got compromised? How can any software do this? The answer is: It’s not possible. Security software is meant to defend healthy machines which are not compromised. As expected the TrueCrypt developers correctly identified the stoned bootkit attack as bogus.

The author of the bootkit did not just drew wrong and misleading conclusions, he also flamed the TrueCrypt developers in a pretty rude way – despite the fact that the TrueCrypt developers explained the situation to him in a simple and polite way.

This example should perfectly illustrate the “prestige”-factor which is intrinsic to the IT-security industry. The shameless self-portrayel of many individuals harms the whole security industry. Unaware people who stumble across one of the many badly researched articles about the stoned bootkit might get the impression that TrueCrypt suffers from a design flaw – which obviously is not the case.

Finally, the destruction of things will never require the same level of skill as the creation of things. Everybody is able to destroy a house. You just need a hammer and can start smashing the house wherever you want. But just some people have the skill to build a house. You need knowledge, experience and adequate material. The same applies to software development. Breaking software will never be as difficult and challenging as developing software. Unfortunately, inexperienced developers like the author of the stoned bootkit often receive much more approval than the people who actually deserve it: The TrueCrypt developers who do a very good job since many years.

$ dd if=/dev/urandom bs=100 count=10000 | ./datropy.py
information density: 7.99979695074 bit

As you would expect from a reasonable good PRNG, all 256 characters of the 8-bit alphabet are (practically) equally probable. Thus, the information density is very high. Of course, /dev/zero does not output any entropy at all since it is a 0-bit alphabet:

$ dd if=/dev/zero bs=100 count=10000 | ./datropy.py
information density: 0.0 bit

Another example: A 1-bit alphabet in which the character “a” occurs twice as often as the character “b”:

$ echo -n "aab" | ./datropy.py
information density: 0.918295834054 bit

There are many domains in which entropy analysis can be of good use: Malware analysis, anomaly detection,… Concerning malware analysis, check out pytropy.py which analyses and graphically displays the sections of PE-files.

bpython is a fancy interface to the Python interpreter for Unix-like operating systems

bpython has some very neat features like syntax highlighting and auto-completion. Also, the written code can be sent to pastebin with just one keystroke. After playing around a bit, I ended up writing my own colorscheme which can be installed as follows:
mkdir -p ~/.bpython && wget http://files.7c0.org/pwr.theme -O ~/.bpython/pwr.theme

Finally, you have to edit your ~/.bpython.ini and set color_scheme = pwr

In insert mode, one can just enter “dts” which immediately expands to a string like “(18 Jun 2009, 03:27pm)”. This can be useful when adding TODOs in source code. Then they look like:
TODO (18 Jun 2009, 03:27pm): foobar