jOEpardy at Easterhegg09

I held a jOEpardy session at Easterhegg09! I guess, you know what a Jeopardy is, if not, have a look at the Wikipedia πŸ˜›

The people were entertained and hopefully learned something πŸ˜‰ Sadly, the hardware didn’t really work πŸ™ The buzzer were somewhat broken so that we actually had to try to see (with our eyes) who pushed the button first. Funnily enough, I *did* test the setup extensively just 10 minutes before the gig! Very weird.

The Questions can be found here: Round 1, Round 2, Round 3, Round 4. But it doesn’t make much sense without the jOEpardy software, unless you parse the XML on your own.

The software is a Java Application which was initially written by TriPhoenix! I haven’t written Java for a long time and I have to admit, that writing Java with Eclipse is actually fun! Eclipse is so smart and tightly integrated in the build process that it’s quite easy to write, build and debug. I wish there was such a good IDE for C or Python. Sadly, I think that Java Code is bloated although <2.500 LoC for a jOEpardy is not too bad I’d say πŸ™‚

I actually thought I could release the jOEpardy code by now (and thus waited with this post…), but I still have to resolve copyright questions.

BufferOverflow Workshop at EasterHegg09

During Easterhegg I held a workshop together with hc. It was about Buffer Overflows, which used to be the most common security vulnerability a couple of years ago.

We gave a talk explaining the basic concepts of processes and how they work on x86 machines. This was heavily packed with information and I really think we couldn’t make everything clear in the first run. But as it was planned as workshop, we intended to give people stuff they can chew on πŸ˜‰ Basically, we took stuff from the excellent Phrack articleΒ  Smashing the Stack for Fun and Profit which is nearly 13 years old by now.

As modern operating systems protect themselves against the consequences of buffer overflows, we prepared a virtual machine with QEmu/KVM so that exploits will work. It’s an old debian woody with an SSH daemon and build essentials.

Of course I have changed the image in the last minutes, because I wanted to improve it. And of course something went terribly wrong: The root filesystem was corrupted and fsck deleted important files, leaving the image in a useless state. We had to port my changes back to the old image.

Of course, we wanted to distribute the ~1GB image among our workshop guests. As we expected 50 people to show up and didn’t want to stress the WiFi so much, I intended to use BitTorrent, but it’s not as easy and smart as it could be: We are NATted, so using an external tracker would FAIL. Also, it can’t multicast the packets, which would perfectly make sense if many people start to download the torrent in the same network. We ended up having a usb pendrive and a thttpd serving the tarred image. Not very smart or efficient.

After the people ran that images, they couldn’t login with SSH due to a mysterious heisenbug. I suspect our last-minutes changes to be the culprit but I can’t provide a more technical error description. The SSH daemon worked quite well *in* the image, but as soon as you wanted QEmu to redirect the traffic into the machine, it FAILed: The connection was established, but no data was transferred. Could be a bug in QEmu as well.
The people either worked through the QEmu widget or set up a TUN device to get the network up and running…
That pissed some people off which then left. We ended up with 20 people trying to hack themselves πŸ™‚

We prepared examples in the image, some of them copied from Gera, e.g.:

/* stack1.c                                     *
 * specially crafted to feed your brain by gera */

int main() {
	int cookie;
	char buf[80];

	printf("buf: %08x cookie: %08xn", &buf, &cookie);
	gets(buf);

	if (cookie == 0x41424344)
		printf("you win!n");
}

The people were supposed to make the program print “you win!”. If you know, how a stack works, it’s actually simple. Do you know, what input you have to feed in order to win!?
Oh, you don’t want to compile this program with anything other than -O0 because the compiler rearranges the variables on the stack so that you can’t overwrite the integer…

In the end, I think I am satisifed with the workshop, although things could have worked better. We had pretty smart people which were really curious how stuff works. They have learned a lot and I guess they had fun with that as well πŸ™‚

Bugsquadding Talk on GCDS

I just had my talk with Pedro and I think it went quite well.

We talked about how to do QA in GNOME and how to use our tools properly. There were about 30 people listening and discussing with us. It was a great honour to meet the bugsquad heros like Philip, Akhil and guenther. Thanks to Andre to look over our slides.

Besides telling about our infrastructure, we slightly discussed alternative ways to access our bug database: There seems to be DeskZilla and Mylyn to work with bugzilla through the XML-RPC API. I haven’t tried Deskzilla yet (the GNOME key link is broken atm), but Cosimo says it doesn’t work with the GNOME bugzilla probably because it’s heavily patched. I wonder when we’ll migrate to Bugzilla-3…
I tried Mylin but it unfortunately doesn’t work either πŸ™ You can query and show the bugs but you can’t update them. It’s a pity because I think that webinterfaces suck in general and our GNOME bugzilla in special.

Although the intended target group wasn’t there, we managed to recruit triagers πŸ™‚ Let’s hope they’ll stay with us for a while. You can find the bugsquad-slides.

I followed the KDE Bugsquad BoF and we discussed several things. They seem to have more fundamental problems than we do, especially getting the bugzilla used by the developers. I collected a couple of ideas: Given that you can’t edit bugs right away if you just have created an account, would it be good to automatically set editing right once a user has commit permissions on the VCS? What about a bugsquad (micro) blog to keep the community informed and involved? It could be a good idea to have kind of a monthly digest which will be sent around. I also envy the KDE Bugdays which apparently are a lot of work, but also potentially recruits new bug triagers. Maybe one could write an webapp for managing the work involved…

Creative Commons Attribution-ShareAlike 3.0 Unported
This work by Muelli is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported.