nion's blog

I participated together with some friends in this years edition of the smpCTF quals (actually it took place for the first time). Since we also qualified for the finals we had to submit a writeup of all challenges. For those who are interested, our submission is located on: http://nion.modprobe.de/smpctf/smpctf.html.

All in all I had fun during this weekend but I also have to say that I've had more at other CTFs in the past. What disappointed me especially is that I'm aware of at least 2 challenges that seem to be only slight alterations of challenges from the DEFCON and Codegate quals. I also missed creativity when it comes to the binary exploitation challenges, most of them have not been challenging. But as said, I enjoyed this weekend, had lots of fun and a big plus was the radio stream during the competition with support from dubstep.fm

Anyway, congrats to team nibbles who've won the CTF

Today I had a nice WTF moment. I was looking into when gcc is going to print (null) rather than segfaulting on trying to dereference a NULL pointer. I knew newer gcc versions are doing that in some situations. But it turns out this is more complex than I initially thought.

So here we have 5 little test programs:

Now I expected some kind of consistent behaviour at least apart from the last snippet as from the C programming point of view the source does exactly the same. But it seems this is not the case.

The first snippet is straightforward, even in the generated assembler the code dereferences a NULL pointer in puts and therefore results in a segfault. But wasn't it printf from the GNU libc that replaces such cases with (null)? Yes it was but it turns out only in some cases. Now here is the fun part. If we look at the generated code for the first example we see:



Huh? puts? Now that is interesting. It seems like gcc sees the format string "%s\n" and after that a pointer (void *) so it assumes the usage of puts does make sense so it optimizes the call.
Now for the second code snippet this is not the case:


In this case gcc sees the format string and an integer so it can't just use this with puts in a way that makes sense. printf is used and the result is (null).

Until this point the behaviour is somehow predictable at least if you know that.
But it becomes even more strange. The third and the fourth example both result in the usage of printf and therefore the displayed result is (null). In my opinion it seems that gcc is testing exactly for "%s\n" (as puts prints a newline at the end anyway). So these two examples don't segfault as well. If there's a newline gcc is - or at least that's my impression - already concatenating the format string with the pointer value.

In the last case the newline is present again. However there is a leading string in front of the format string %s. Here gcc is not seeing this as a whole thing concatenating it and calling puts. It's using printf again and results bla: (null).

I have no idea what the reason behind this behaviour is, I guess there are good arguments for that by the gcc people. But honestly, it SUCKS and is highly inconsistent, *grrr*. The whole behaviour isn't even consistent between different gcc versions.

The above results are tested with gcc (Debian 4.3.4-2) 4.3.4. I also tested with gcc (GCC) 3.4.3, in this case all of the above examples result in a segmentation fault (not sure when this (null) replacement feature in the glibc was introduced though). You can also disable this "optimization" by using -fno-builtin-printf btw.

I just uploaded openbox-3.4.7-2 to Debian unstable and wrote a patch that enables to set next or prev to the monitor attribute of the MoveResizeTo action. Without this patch you need to explicitly set a monitor number you want to send a window to but can't just toggle a window from one workspace to the other with one keybinding or to move it to the next/prev if you have 3 or more monitors. So if you use openbox with a xinerama setup it would be nice if you could test that and report bugs in case of errors.

A keybinding for that could like like:

People often are not sure which characters they should escape to prevent for example common flaws in web applications.
Just stumbled over a list by the w3c in their web security FAQ.

&;`'\"|*?~<>^()[]{}$\n\r

you may also want to remove null bytes.

I just released a new version of yacpi. yacpi displays various ACPI information like batteries, ac status, thermal zones, fans and some information about CPU.

The new release is a complete rewrite based on libacpi (yacpi is now the 3rd tool using libacpi).
For those of you already using yacpi here are the relevant changes:

• yacpi now depends on libacpi, compile, install, ldconfig


• -m option removed, default is to display just the present batteries, use -n if you want to see not found items too


• Removed interactive delay input in ncurses interface, restart yacpi if you feel like changing it


• Samples are not needed anymore, I rewrote the algorithm to compute remaining time in libacpi


• Immediate reaction on user input in ncurses interface, thanks select(2), fuck halfdelay(3)


• New options for every feature, the default is to print everything but you can now decide what you exactly want to see, check yacpi -h for new parameters.

Quite some things changed so if you use yacpi in shell scripts, check for the new command line options.

Ncurses:


Plain-Text (yacpi -p):
| BAT0 = 100% discharging rtime 04:49 h | ac = off-line | THRM = 50 C | gov = ondemand | cpu = 600/1500 mhz

Have fun: http://www.ngolde.de/download/yacpi-3.0.tar.gz, http://www.ngolde.de/download/libacpi-0.2.tar.gz.

Just uploaded the new version of stfl a library which implements a curses-based widget set for text terminals.

The new version of the package introduces unicode awareness of stfl (introduced in stfl 0.9, Clifford released very often : ) and the often requested packages for the bindings stfl ships, namely ruby(1.8/1.9), python, perl and spl.

The package is now going through NEW, in the meantime you can get the packages (for i386) on:
http://nion.modprobe.de/stfl/

Oh and Michael Mende is my new Co-Maintainer, also thanks to him for his help!

I can just announce if you need more documentation on libacpi you can look into some source apart from
test-libacpi.c.

Today I got a mail by Folkert Vanheusden (author of several cool programs) telling me that he wrote
acpitail which shows acpi information in a tail(1) like interface.

338 SLOC using libacpi , rocks!

After asking for testers of a libacpi snapshot I got a fair amount of test mails. Thanks to all the people who tried it and helped me!!

Now I finished with coding, testing and documenting everything and happy to release version 0.1 of libacpi.

It is a general purpose shared library for programs gathering ACPI information. It fully implements information about fans, batteries, ac states and thermal zones (apart from trap points).

Try it out on: http://www.ngolde.de/download/libacpi-0.1.tar.gz.

There is also an online documentation (well doxygen generated) on http://www.ngolde.de/libacpi/doc/html/.
test-libacpi.c is an example on how to write programs using libacpi.

For more information download the tarball, have a look into the manual, test-libacpi.c, README and the doxygen documentation.

The next step for me is to port yacpi to libacpi which was also the reason for libacpi since I first wanted to rewrite it and thought it might be useful to have the functionality in a library. There are not yet Debian packages for it because I am really busy at the moment so if you want to maintain it, feel free to do so.

To quote the site I found today:

This is a dictionary of algorithms, algorithmic techniques, data structures, archetypal problems, and related definitions. Algorithms include common functions, such as Ackermann's function. Problems include traveling salesman and Byzantine generals. Some entries have links to implementations and more information. Index pages list entries by area and by type. The two-level index has a total download 1/20 as big as this page.

Very useful at least for the guys studying computer science.

http://www.nist.gov/dads/

During the last time I developed a general purpose library for ACPI on linux.
Initially I just wanted to rewrite yacpi but since there is no shared lib for acpi information I decided to
put the important stuff in a seperate library.

Before releasing it I want some people to test it because my notebook doesn't support all of the information it can gather.

If you want to help me a bit, download a snapshot from:
http://nion.modprobe.de/libacpi-unreleased.tar.gz.

Install cmake, unpack the tarball and do:
$ cmake .
$ make
$ ./test-libacpi

and send me the output of test-libacpi together with tmpfile which should be generated like:

for i in `find /proc/acpi -type f`; do
    echo -e "FILE: $i ================\n" >> tmpfile
    cat $i >> tmpfile
done

via mail to:


Thanks!

UPDATE: yes I totally fucked up the install instructions and the generation of the tmpfile Sorry.
And in case I didn't reply to every mail I got until now, thanks very much for you help all!