GCS d--(---) s: !a C+++ UL++>+++ P- L+++>$ E--- W++ N o? K+ w$ O-- M- V? PS+++ PE- Y+>++ PGP++ t+@ 5 X++@ R* tv+>- b+>++ DI-- D- G++ e+>+++ h--- r+++ z+ [what the hell is this]

Top pegasus

Feb 2012. About a week ago I was looking into thc-hydra, a fast network logon cracker which supports many different services. Actually, the only service I was interested in was the http-post-form module which allows dictionary attacks on web forms. So I did a few tests on my local services. First I tried to brute-force a very simple, straight forwad application (no cookies, no redirects) and hydra performed as expected and found the correct password. The second test involved cookies but no redirects and again hydra found the correct credentials. On the thrid test, however, consiting of cookies and redirects hydra failed completely. Why's that?

I did some investigations using wireshark and found out that the problem was solely related to redirection code in hydra (HTTP 400, Bad Request). So I did some further testing and contacted van Hauser (vh), hence I don't want to go into technical details. Anyway, vh replied within 24hrs and from the code I received so far it looks like the issue will be resolved very shortly (thx vh, appreciate it). But what about pegasus?

As mentioned above vh is very close but he's not there yet (2012-02-03 03:50:00 PM GMT+1) and I was just getting the itch. That's why I thought, while waiting for the hydra fix it would be fun to get my hands on some python and code a simple http-form-tickler myself. Don't get me wrong, pegasus only works for http posts and is by no means comparable with hydra. The python code is also far from production quality and I am sure there are plenty of issues which will show up once I use it on a bigger scale. None the less, feel free to download, comment and improve but remember: use for legal purposes only!

Top 28c3 (behind enemy lines)

Jan 2012. Although getting ticket was even harder than the previous years, the 28c3 itself lived well up to all my expectations. As usual 10 out of 10!

Top vkey

Nov 2011. Virtual keyboards come in handy if you need to change the keyboard layout but have not enough privileges to do so. For instance you may need characters form a language the current layout does not support.

It may also be used in cases where you cannot trust the underlying hardware e.g. to reduce the risk of keystroke logging. This is because it is more difficult for malware to monitor the display and mouse to obtain the data entered via a virtual keyboard, than it is to monitor real keystrokes.

However, keep in mind that it is still possible to monitor your input, for example by recording screenshots at regular intervals or upon each mouse click. It is also more difficult to keep your input secret from sholder surfers as it is trivial for an observer to read the data from the screen. Hence do not use a virtual keyboard for sensitive data unless you are sure you are not being watched - but can you ever be?

NOTE: The virtual keyboard is embeded from an external source by means of an <iframe> and in order to use it you will need to have javascript enabled. Please see virtualkeyboard.ws for terms of service.

Top postdata

Oct 2011. Post data to any page sepecified in the Form Url textbox. There are basically two ways you can use postdata. Either use an internal proxy or post your data directly.

If you use Proxy Post your request will be sent to the according server using an internal proxy and the server's response will be displayed, t.i. you will not be directed to the remote page. This is useful if you are more interested in the server's http respose than the actual page itself. Another way to use postdata is to prepare you request first and then send it to the server directly. This will direct your browser to the address specified and can be used e.g. as a generic login.

Top shellexecute

Sep 2011. Sometimes you debug a piece of code (for reasons of safety in a VM) and you discover that your EIP points to some binary gibberish e.g. on the stack. Ah, you think, could be shellcode - but what is it doing? You are probably lucky as your debugger has already disassembled the zeros and ones and you should at least have a slight clue about what's going (wr)on(g). To make sure you step through it and you get away with a greeting message from the NSA.

But imagine a situation where you cannot use a debugger (e.g. web based crimeware) and the only thing you can do is static code analysis. You will be left with the binary gibberish and most probably not able to figure out what's going to happen once it will execute. Ok, you could load it into IDA and force code conversion but afaik you will still not be able to step through the code and confirm the greetings. shellexecute allows you to do just that. Copy the shellcode into a file (binary or text format), load it into shellexecute and run it in your debugger.

here is an example ...

Imagine your shellcode looks like this (nevermind the zeros):

55 89 e5 31 c0 05 01 00 00 00 89 ec 5d c3

you can simply load it into shellexecute and start your debugger (if it was a binary file you could also load it into IDA and force code conversion). But with shellexecute you could also step through it and that's the real point. I admit this example is not worth stepping through as it simply disassembles to:

push ebp
mov  ebp, esp
xor  eax, eax
add  eax, 1
mov  esp, ebp
pop  ebp
retn

on the other hand side, what does the following piece of code disassemble to and what does it do?

31 C0 31 DB 31 C9 31 D2 51 68 6C 6C 20 20 68 33
32 2E 64 68 75 73 65 72 89 E1 BB 7B 1D 80 7C 51
FF D3 B9 5E 67 30 EF 81 C1 11 11 11 11 51 68 61
67 65 42 68 4D 65 73 73 89 E1 51 50 BB 40 AE 80
7C FF D3 89 E1 31 D2 52 51 51 52 FF D0 31 C0 50
B8 12 CB 81 7C FF D0

linux vs. windows ...

shellexecute works for both linux and windows (tested on xp-sp3) as it merely makes use of a function pointer to execute the shellcode. However, as current versions of the linux kernel do not allow you to execute code on the stack (and that's what we are basically doing) you will have to use the -fno-stack-protector -z execstack gcc options. Here is the main (not really magical) magic:

unsigned char* shellcode = NULL;

int main (int argc, char** argv)
{
  void (*func)();
  size_t size, offset, bytes;
  int topt;
  int xor;

  parse_opt(argc, argv, &offset, &bytes, &xor, &topt);
  shellcode = load_shellcode(argv[optind], &size, offset, bytes, xor, topt);

  func = (void (*)()) shellcode;
  printf("shellcode length is : %d\n", size);
  printf("about to execute shellocde ...\n");

  (void)(*func)();

  free(shellcode);
  return 0;
}

gdb ...

Although gdb might not be as convenient as IDA or OllyDbg it is still extremly powerful and sometimes it will be the only debugger at hand. So let me guide you through the simple sample shown above. Load shellexecute into gdb, disassemble the main and look for calls. The last call will be to free and the call before that will be your breakpoint target. Set you breakpoint to this very address (don't forget the * infront of the address) and run the executable with the proper command line arguments (-t linux-simple.txt). Once we break EAX will point to our shellcode. However, if we try to disassemble the code pointed to by EAX gdb will tell us that no function contains the specified address (rightly so because EAX points to the stack and gdb does not expect excutable code to be on the stack). However, if we use x /10i $eax we are nonetheless able to disassemble the code and if we singel-step (si) into the code and use x /i $eip we can force gdb to treat the bytes refered to by EIP as instructions which helps us analyze as well as single-step through our shellcode.

gdb shellexecute
...
(gdb) disassemble main
...
0x08048c90 <+169>: mov    0x3c(%esp),%eax
0x08048c94 <+173>: call   *%eax       ; <- our breakpoint
0x08048c96 <+175>: mov    0x804b08c,%eax
0x08048c9b <+180>: mov    %eax,(%esp)
0x08048c9e <+183>: call   0x80485f0   ; <- call to free
0x08048ca3 <+188>: mov    $0x0,%eax
0x08048ca8 <+193>: add    $0x48,%esp
0x08048cab <+196>: pop    %ebx
0x08048cac <+197>: pop    %esi
0x08048cad <+198>: mov    %ebp,%esp
0x08048caf <+200>: pop    %ebp
0x08048cb0 <+201>: ret    
(gdb) break *0x08048c94
(gdb) run -t linux-simple.txt
Starting program: /YOUR_PATH/shellexecute -t linux-simple.txt

shellcode length is : 14
about to execute shellocde ...

Breakpoint 1, 0x08048c94 in main ()
(gdb) info reg eax
eax     0x804c008   34529032
(gdb) disassemble $eax
No function contains specified address.
(gdb) x /10i $eax
   0x804c008:  push   %ebp
   0x804c009:  mov    %esp,%ebp
   0x804c00b:  xor    %eax,%eax
   0x804c00d:  add    $0x1,%eax
   0x804c012:  mov    %ebp,%esp
   0x804c014:  pop    %ebp
   0x804c015:  ret    
   0x804c016:  add    %al,(%eax)
   0x804c018:  add    %al,(%eax)
   0x804c01a:  add    %al,(%eax)
(gdb) si
0x0804c008 in ?? ()
(gdb) x /i $eip
=> 0x804c008:    push   %ebp
(gdb) si
0x0804c009 in ?? ()
(gdb) x /i $eip
=> 0x804c009:    mov    %esp,%ebp
(gdb) si
0x0804c00b in ?? ()
(gdb) x /i $eip
=> 0x804c00b:    xor    %eax,%eax
(gdb) si
0x0804c00d in ?? ()
(gdb) x /i $eip
=> 0x804c00d:    add    $0x1,%eax
(gdb) si
0x0804c012 in ?? ()
(gdb) x /i $eip
=> 0x804c012:    mov    %ebp,%esp
(gdb) si
0x0804c014 in ?? ()
(gdb) x /i $eip
=> 0x804c014:    pop    %ebp
(gdb) si
0x0804c015 in ?? ()
(gdb) x /i $eip
=> 0x804c015:    ret    
(gdb) c
Continuing.

Program exited normally.
(gdb)

I also thought it would be a nice feature also to disassemble the shellcode. You can use the -d option to disassemble the shellcode and together with the -n no-execution option the shellcode will be disassembled but not executed. For disassembling I used libdisasm, so make sure it is installed on your system.

Top FSEQF

Aug 2011. FSEQF is just a silly abbreviation for Firefox Search Engine Quick Fix. As I am using an en-US installation of Linux the default search engine for Amazon was pointing to www.amazon.com and from within firefox I was unable to change the search location to say to: www.amazon.co.jp. So I came up with this very cheap but quick fix:

  1. locate the firefox default profile directory, e.g. /home/yourname/.mozilla/firefox/vkoodfuk.default
  2. in the default profile directory open the search.json file and search for "Amazon" (without quotes and case insensitive)
  3. remember the path Amazon.com points to, e.g. /usr/lib/firefox-addons/searchplugins/en-US/amazondotcom.xml
  4. edit this file and replace all occurences of "amazon.com" with "amazon.co.jp" (you need to be root to do this)
  5. restart firefox
  6. you are now using esoteric fonts for your amazon searches ;)

Top SE14

Jun 2011.  London SE14 is the postal code of New Cross (Borough of Lewisham). I stayed there for a bit more than 3.5 years and it was almost exactly ten years ago when I decided to leave for a new challenge.

SE14 might not be one of London's fanciest addresses but it was one of the most thriving places I have ever been to. Predominantly people from the Caribbian, lots of students and lots of nice places to go. As I learned from friends a lot of things have changed though. However, to mark the 10-year-leaving-anniversary I collected a some links ;)

Top bm(bak|get)

May 2011. I know, there are a lot of bookmark syncing tools (plugins, etc.) for Firefox out there. But none of them, at least I did not find one, fits my needs.

So the easy way out would be to backup and encrypt places.sqlite in the default profile (this is where Firefox 3.0 and above stores bookmarks, see the MozillaZine Knowledge Base for details), ftp it to my web server and then download, decrypt and install it on whichever computer I want. To be fair there are some preconditions which I luckily met.

bmbak ...

encrypts the places.sqlite file and calculates an MD5 over the plain places.sqlite file so that I don't have to download and install the bookmark file if it has not changed. Basically bmbak creates two files bookmarks-enc.tgz and places.sqlite-md5.txt which I then ftp to my web server.

bmget ...

downloads the places.sqlite-md5.txt file from the web server, checks if the local places.sqlite is out-of-date, and if so downloads, decrypts and replaces the local bookmark file with the one from the server. The local bookmark file is also backed-up before it is replaced so that it can be restored in case of "mind-shift".

Although bmbak and bmget suffice all my needs they are only prototypes and the whole idea needs a lot of improvement to be interesting for a broader user base. To be honest the the preconditions in particular are (as is) very limiting.

nice-to-haves

however ...

Top genopt

May 2011. Writing options for C programs is tiresome. Although getopt eases the pain a little bit there is still some repetitve typing involved. Ease the pain with genopt

new-0.7.tgz now also supports genopt

Top w00zl3.net archive

Jan 2011. As this page got loaded more and more I decided to put older foo-bar-baz stuff on a seperate page. You can now find older (but I hope still interessting) stuff in the w00zl3.net archive

Top 27c3 (we come in peace)

Jan 2011. One could be tempted to say, "same old story". But no, due to the CSC (Chaostreff Salzburg Contingent) this congress had something special.

Top chaostreff salzburg

Dec 2010. As Mark Twain said the secret of getting ahead is getting started. However, it took me almost a year to get my arse into gear but at last there is a chaostreff in Salzburg (Austria). In the end it turned out to be merely a matter of writing some e-mails and setting up a date for an initial meeting (which took place on Oct 22nd 2010).

In the meantime things are well underway, an irc channel, mailing list and a forum have been set up and the 2nd meeting took place on Nov 26th with 21 chaotics attending. Well, seems we are not that lazy after all.

So, if you are interessted in the chaostreff salzburg check out the following links and remembert that H4ck3r5 are people too.

Top November 17 2010 † O.Univ.-Prof.Dr. Jochen Pfalzgraf

Top ret2libc

Sep 2010. Buffer overflows are always great fun. First, overwrite the buffer with your shellcode and then overwrite the original return address to point to the beginning of you shellcode, job done!

The problem is that in most books and/or online tutorials an executable stack is assumed, which most probably will not be the case. Another problem, although hardly ever mentioned, with this technique is that your shellcode has to fit into the buffer. For example, if the buffer being overwritten allocates 16 bytes on the stack but your shellcode consists of 24 bytes, tough luck. So only if the stack is executable and the buffer is big enough to hold your entire shellcode the previous steps will lead to success.

Most of the time, however, modern operating systems will not allow you to execute code placed on the stack (WP: NX bit). Therefore most examples provided in books and/or online tutorials relying on an executable stack will simply not work and may cause frustration amongst readers. On the other hand they can also lead to a dangerous conclusion: I can't do it, therefore nobody can do it, hurrah we are secure against buffer overflows!

But surly enough there are many ways to circumvent these restrictions and one of them is using a technique called return-to-libc (ret2libc). The basic idea behind ret2libc is that even though the stack is not executable it can still be overwritten and corrupted. But instead of returning to code placed on the stack we divert code execution to one of the fucnctions provided by libc (such as system(), execl(), exit() etc.). Since these functions do not reside on the stack we can bypass the stack protection and execute their code. This also means that our shellcode is not restricted by the size of the buffer. Voilà!

first things first

prerequisite: You should be familiar with assembler language (at least with the basics), gdb, objdump and understand the genearl concepts of the stack. For a general knowledge of how buffer overflow exploits work I would like to refere you to the Buffer Overflow Primer by Vivek Ramachandran.
platform: Ubuntu 10.4 (kernel: 2.6.32-24-generic)
compiler: gcc 4.4.3

Our goal is to exploit a buffer overflow vulnerability to spawn a shell. We will use an environment variable (EGG) to pass the payload to the vulnerable application. This environment variable will be created by another application called exploit which calls execle() to invoke the vulnerable application. The source code of the vulnerable application will look as follows:

/* vuln.c */

#include <stdlib.h>
#include <string.h>

int main(int argc, char** argv)
{
  char buf[16];

  char* ptr = getenv("EGG");
  if (ptr)
    strcpy(buf, ptr);

  return 0;
} /* exploit.c */

#include <stdlib.h>
#include <string.h>
#include <stdio.h>
#include <unistd.h>

int main(int argc, char** argv)
{
  char buf[208];
  char* myshell="myshell=/bin/sh";
  char* env[3] = {buf, myshell, 0};

  memcpy(buf, "EGG=", 4);

  /* fill up buf with shellcode */

  memcpy(buf + 204, "\x00\x00\x00\x00", 4);

  execle("./vuln", "./vuln", 0, env, 0);
}

NOTE: As this episode focuses on ret2libc and stack protection we will perform the following steps to disable other security mechanisms which would make our lives more difficult.

classical ret2libc

To explain the classical ret2libc technique I will use the standard C system() function which as a parameter takes a C string containing the system command to be executed (/bin/sh in our case).

So how do we have to layout our shellcode in order to spawn a shell? First of all we have to fill up the buffer plus 4 bytes for the ebp with arbitrary byte vlaues (I usually fill it with NOPs (0x90)). Then we have to replace the original return address with the address of our libc call (system() in our case). Before we put the parameter for the system() function into our shellcode we have to specify an address which we will jump to after returning from the system() call. This could be just a fake address but in order to avoid a segfault we will but the address of the exit() function here. Finally we specify the address to the /bin/sh string.

ret2libc classical

To retrieve the addresses of the system() and exit() functions we can use gdb. We load the vulnerable application (in fact we could use any other application as well) into gdb, set a breakpoint at main and run the application. Once we break we can determine the required addresses using gdb's print command.

(gdb) b main
Breakpoint 1 at 0x8048477
(gdb) run
Starting program: /home/w00zl3/ret2libc/vuln

Breakpoint 1, 0x08048477 in main ()
(gdb) print system
$1 = {<text variable, no debug info>} 0x167100 <system>
(gdb) print exit
$2 = {<text variable, no debug info>} 0x15d200 <exit>
(gdb)

Well, we got 0x167100 for the system() and 0x15d200 for the exit() function (0x00167100 and 0x0015d200 as fully qualified 32-bit addresses). Ouch! We are in trouble here! But why? Let's imagine what would happen if we used these addresses in our shellcode. As these addresses contain zero-bytes (0x00) and strcpy() takes a zero-terminated C string as its 2nd parameter these bytes would be interpreted as string terminators. So as we will not be able to inject all of our shellcode into the buffer and thus classical ret2libc is not a real option for us.

Anyway, even if we assume that our addresses do not contain any zero-bytes the classical approach has other essential limitations. First, it is impossible to call another function which requires paramters. Imagine what happens when function_1 (system() in our case) returns. It calls function_2 (exit() in our case) but parameters to function_2 would have to be in the same location as parameters to function_1. And where would we jump when function_2 returns? However, for exit() this would not matter and sometimes this limitation may not be a problem at all but usually it is. Secondly, no paramters to function_1 could contain zero-bytes (t.i. if the overflow is caused by string manipulation such as strcpy() which is the case in our sample). But it's not all over now!

NOTE: If our function addresses did not contain these zere-bytes or we used the fread() function in vuln.c to copy data to the buffer this technique would work perfectly!

ret2libc - frame faking

To overcome the limitations of the classical ret2libc we can use a technique called frame fakeing. It has to mentioned that this technique is not truly generic in contrast to the classical approach. As frame faking heavily relies on the frame pointer (ebp) the vulnerable applications must have been compiled without the -fomit-frame-pointer option (there are, however, other techniques such as esp lifting which I will not cover in this episode). The basic idea behind frame faking is to use faked frame pointers and leaverets to build up a sequence of functions being executed.

So let's look at what I mean by the term leaveret. As we know functions typically start with a prolog and end with an epilog (calling conventions). But what exactly does leaveret do and how can we use it in our exploit?

leave   ⇔  mov %ebp, %esp
ret        pop %ebp
           ret

Now imaginge the following shellcode:

ret2libc frame fake

I admit that it may be a bit tricky to visualize what is happening once our shellcode gets executed but I will try to explain. When the vulnerable function (strcpy() called in main) returns, code execution resumes right after the call (0x08048441 see disasemly of main below) and main's epilog (leave; ret;) is triggered. The leave instruction puts fake_ebp0 into ebp and the ret instruction diverts code execution to leaveret (this is the the leaveret we overwrote the original return address with). This time leave puts fake_ebp1 into ebp and ret diverts code execution to system() which can see its appropriate parameter (/bin/sh). So now system() executes and spawns our shell! If we now type exit to quit the shell the epilog of system() puts fake_ebp2 into ebp and its ret instruction diverts execution to the second leaveret of the shellcode. The following leave instruction puts fake_ebp3 into ebp but as we don't have a fake_ebp3 it simply puts garbage into ebp and we don't mind. Now the ret instruction diverts code execution to exit() which obvioulsy can see its parameter (exit_code). That's it, we spawned a shell and even exited without a segfault, wow!

It may take a while to unviel all the underlying secrets and I think it's a good idea to use pen and paper and/or play around with gdb until you really understand what's going on. It's all a matter of walking down the yellow brick road ...

So how would this help us in solving the zero-bytes-problem concerning our addresses? As we are able to string together shellcode of arbitrary length and are now able to use as many functions as we like, we are not restricted to using system() as our first function. Instead we could jump to strcpy() first - we know it must be accessable via the Procedure Linkage Table (PLT), as the vulnerable application is using it. As parameters we could pass it the location of our zero-byte poisoned system() function address and the location of a zero-byte in the vulnerable executable (we most definately will find one). Obviously we will have to "call" strcpy() several times before actually "calling" a libc function. We will have to make sure all necessary bytes of our libc function addresses and possible zero-bytes which we will use as parameters to these functions are nullified. This also means that we will have to mask our addresses and zero-parameters in our overflow payload. For example, we could mask the address for system() which is 0x00167100 to look like 0xAA1671AA and then use the technique described to patch it back to 0x00167100. See where I'm going?

From the dump produced by objdump -d vuln (see below) we can now determine the addresses for strcpy() (0x08040350), leaveret (0x08048446) and a pointer to a zero byte at 0x08048442.

08048414 <main>
 8048414:  55                      push %ebp
 8048415:  89 e5                   mov %esp,%ebp
 8048417:  83 ec 1c                sub $0x1c,%esp
 804841a:  c7 04 24 10 85 04 08    movl $0x8048510,(%esp)
 8048421:  e8 0a ff ff ff          call 8048330 <getenv@plt>
 8048426:  89 45 fc                mov %eax,-0x4(%ebp)
 8048429:  83 7d fc 00             cmpl $0x0,-0x4(%ebp)
 804842d:  74 12                   je 8048441 <main+0x2d>
 804842f:  8b 45 fc                mov -0x4(%ebp),%eax
 8048432:  89 44 24 04             mov %eax,0x4(%esp)
 8048436:  8d 45 ec                lea -0x14(%ebp),%eax
 8048439:  89 04 24                mov %eax,(%esp)
 804843c:  e8 0f ff ff ff          call 8048350 <strcpy@plt>
 8048441:  b8 00 00 00 00          mov $0x0,%eax
 8048446:  c9                      leave
 8048447:  c3                      ret

As the name frame faking suggests we will have to know the exact addresses of our fake-ebps. So if we know the exact start address of our buffer we will also be able to calculate the addresses for our fake-ebps. In order to find the start address of the buffer we can use gdb. We simply supply invalid addresses (e.g. 0x05060708) in our payload and have our vulnerable application cause a segfault which produces a core dump. We then load the core dump into gdb (gdb vuln core) and look at the values in the esp and eip registers. The eip register will point to 0x05060708 as this is the address code execution sould have resumed. But we are much more interested in the value of esp. If we poke around the stack memory a bit (esp - 0x20 is a good starting point) we will finally find the starting address of our buffer and as we disabled ASLR this address should not change. We can now use this address to calculate all the needed fake_ebps.

NOTE: On many systems core dumps have to be enabled manually with the ulimit command (How do I enable core dumps for everybody).

There is one detail I missed out completely so far. How will we pass the string parameter /bin/sh to the system() fucntion? We could do that using an environment variable which holds exactly that string (/bin/sh) and could pass its address as the parameter of the system() function. This method can also be used when working with classical ret2libc. However, this requires that we know the exact address of the according environmet variable and getting this address turns out to be a bit cumbersome. A better method would be to include the parameter string (/bin/sh) in the payload (with its zero-termiation masked) and then patch the terminating zero with the another "call" to strcpy(). As we know the starting address of our buffer we can easily calculate the address of the string itself as well as the patch address for the terminating zero.

That's basically all there is to say, although, surly, this episode is by no means complete nor does it intend to be the sole representation of the topic. All information provided is very platform specific and may become obsolete with future kernel and/or compiler releases. However, I think it should still be useful as a convenient reference.

Top Iceland 2010

Aug 2010. No need to say that Iceland is an outstanding country (but with Trolls, one never knows). You can look at tons of pictures of the waterfalls, volcanoes, lakes, rivers, etc but actually being there beats them all - it's simply overwhelming.

The frist 6 days we (t.i. my wife and I) stayed at a little hotel in Kópavogur and explored Reykjavík and lots of the Greater Reykjavík Area (including Smáralind). We then rented a small jeep (a Suzuki Jimny) and drove to Selfoss, a small town in the south of Iceland where we spent the remaining 8 days in a cosy bungolow. From Selfoss we did day trips, among others, to the Eyjafjallajökull volcano or the Sögusetrið at Hvolsvöllur.

There is no point in describing things such as trolling in Hafnarfjörður, horse riding at Egilsstadir 1, laying on the beach in Stokkseyri or climbing the lava fieds of Vestmannaeyjar as they are must-have-felts!

What we did not expect is that Iceland is a fast food nation. It seems that they are hooked on hamburgers, pizza, hotdogs, sandwiches and coke. But never mind, we adjusted to that pretty well;-)

Links:

PS: Sorry to Hakkavélin that we did not come for a visit, I got the days mixed up :-(

Top August 5 2010 11:00:00 GMT+2 ∞

Top 3.141592653589793 ...

Aug 2010. There is a new attraction in the LAB. It's a 55.1" x 39.4" Blue-LED-π sign. And as it is rather hard to only describe it I will post two images here.

blue pi led sign blue pi led sign in lab context

I have been thinking about the whole thing for almost a year but I either didn't have time or I was simply to lazy to organize/buy all the needed stuff. Last week, though, I went to the my favourite DIY store bought some black paint and brushes, took two wooden frames and did some painting, drilling, screwing ...

In the end it took me only one day putting it all together.

Top easter(h)egg 2010 - Munich

Apr 2010. On the way to Munich Henx introduced me to geocaching and i found my first little treasure. Erverything cool here, much cosier than at the congress; still, the geeks and the «Tschunk » are erverywhere. Thumbs up!

Top 26c3 (here be dragons)

Jan 2010. The best annual freak show on earth - multicultural, colourful, mind-blowing, relaxing, chaotic, blinking, technical, social ...

Well, well, sure enough: Little Bobby Tables helped to secure the internet, thx $!

Top text_me

Jan 2010. Finally, all the hardware has arrived and the text_me is up and running. At the moment it says:  " good bait catches fine fish! "

05.01.2010 00:46:36 CET - press return
05.01.2010 00:47:41 CET - restate my assumptions: 1. mathematics is the language of nature. 2. everything around us can be represented and understood through numbers. 3. if you graph the numbers of any system, patterns emerge. therefore: there are patterns everywhere in nature. evidence: exists.

... for more foo-bar-baz stuff visit the w00z3.net archive

Top Downloads:

File Name Size Last Modified
aes-256-cbc-0.3.tgz121628/05/2011 14:05:57
avl-tree-0.1.0.tgz301222/05/2009 18:05:59
bmbak-0.3.tgz202228/05/2011 14:05:04
bmget-0.3.tgz221828/05/2011 14:05:12
calling_conventions.pdf28532220/12/2007 14:12:06
chaOS-0.0.11.7.13.img.tar.gz5007421/07/2011 20:07:33
clink-0.1.0.tgz187326/04/2008 11:04:36
dec2base-0.1.1.tgz133810/11/2008 06:11:06
entropy-0.1.0.tgz447631/10/2008 18:10:37
genopt-0.3.1.tgz534120/05/2011 02:05:50
hev-0.1.0.0.tgz796209/11/2007 16:11:50
hooking-0.1.0.rar7593305/09/2008 19:09:14
hwnd-1.0.0.1.rar371022/02/2008 13:02:25
mkfile-0.3.tgz220918/03/2011 08:03:37
nasdk-0.2.0.tgz3762510/08/2011 12:08:13
new-0.7.tgz427621/10/2011 16:10:47
pegasus-0.1.tgz402503/02/2012 15:02:40
php-localizer-0.1.0.tgz348906/02/2009 18:02:02
primetunes-0.1.0.rar585022/12/2008 17:12:40
primetunes-0.2.0.rar783105/01/2009 18:01:00
shellexecute-3.0.tgz11683305/10/2011 15:10:57
tex2png_remote-0.3.0.tgz878111/12/2009 17:12:45