Monday Nov 16, 2009

Fun With DTrace: The Windows-Key Prank

The current episode of the German HELDENFunk podcast features an interview with Chris Gerhard about one of his favourite subjects: DTrace (in English, beginning at 14:58):

After the interview, we hear a guy called "Konteener Kalle" express his love (in German) for DTrace by playing a prank on his boss: Whenever he presses the Windows key (on an OpenSolaris system, mind you), he's punished by watching the XScreensaver BSOD hack (of course not knowing that it's just a screensaver).

That little joke challenged me to actually implement this prank. Here's how to do it.

The Idea

The idea of this prank is to start the XScreensaver Blue-Screen-of-Death screensaver (which simulates a Windows crash experience) on an OpenSolaris system whenever the user presses a certain key a certain number of times. This could be the Windows-Key (which doesn't have any real use on an OpenSolaris machine) or any other key. We count the number of key presses and only execute the BSOD after a certain number of key presses in order to make the prank less obvious.

Step 1: Identify the Windows (or any other) Key

If you have a Windows-Keyboard, this is easy: Run xev and press the Windows-Key. Take note of the keycode displayed in the xev output. Of course you can use any other key as well to play this prank. In this case, I'm using the left Control-Key, because I don't have a Windows-Key on the system I'm working on. The Control key has the keycode 37.

Step 2: Configure XScreensaver for BSOD

XScreensaver comes with a great collection of "hacks" that do interesting stuff on the screen when the screensaver activates. Check out the /usr/lib/xscreensaver/hacks directory. Each hack can be run individually, but then it will only execute inside a new window. For the BSOD illusion to be realistic, we want to execute the BSOD hack in full-screen.

This can be achieved by telling XScreensaver to demo the BSOD hack for us. It will then create a full-screen window and execute the BSOD hack inside the new window. The following command will tell XScreensaver to run a hack for us:

xscreensaver-command -demo <number>

The <number> part is a little complicated: XScreensaver looks at its config file ~/.xscreensaver where it stores a list of programs and arguments after the keyword "programs:". <number> simply refers to the number of the hack on that list. Therefore, we must create an entry in our admin user's .xscreensaver file that starts bsod(6) with the right parameters and that gives us a known number to call xscreensaver-command with.

Let's put our entry at the top of the list so we can simply use the number "1" to execute the BSOD screensaver. Somewhere in our .xscreensaver, the programs section should look like this:

  textFile:       /etc/motd
  textProgram:    date

  programs:                                                                     \\
  -               "BSOD Windoze"  bsod -root -only nt         \\n\\
  -                "Qix (solid)"  qix -root -solid -segments 100              \\n\\
  -          "Qix (transparent)"  qix -root -count 4 -solid -transparent      \\n\\

You can test this by running xscreensaver-command -demo 1.

Step 3: Write a DTrace Script That Sets Up the Trap

Now it gets more interesting. How do we use DTrace to find out when a user presses a certain key? All we know is that the Xorg server processes the keystrokes for us. So let's start by watching Xorg in action. The following DTrace command will trace all function calls within Xorg:

pfexec dtrace -n pid`pgrep Xorg`:::entry'{ @func[probefunc] = count(); }'

Let's start it, press the desired key 10 times, then stop it with CTRL-C. You'll see a long list of Xorg functions, sorted by the number of times they've been called. Since we pressed the key 10 times, it's a good idea to look for functions that have been called ca. 10 times. And here, we seem to be lucky:

  miUnionO                                                          8
  DeviceFocusInEvents                                               9
  CommonAncestor                                                   10
  ComputeFreezes                                                   10
  CoreLeaveNotifies                                                10
  key_is_down                                                      11
  FreeScratchPixmapHeader                                          12
  GetScratchPixmapHeader                                           12
  LookupIDByType                                                   12
  ProcShmDispatch                                                  12
  ProcShmPutImage                                                  12

The key_is_down function looks like exactly the function we're looking for! In fact, some googling tells us that this function's 2nd argument is the keycode of the key that is down when the function is called.

Why do we see "11" and not "10" function calls to key_is_down? Because it also counted my pressing of the Ctrl-Key when I stopped the DTrace script through Ctrl-C :).

This gives us enough knowledge to create the following DTrace script:

  #!/usr/sbin/dtrace -s

   \* BSODKey.d

   \* This D script will monitor a certain key in the system. When this key is
   \* pressed, a shell script will be executed that simulates a BSOD.
   \* The script needs the process id of the Xorg server to tap into as its
   \* first argument.
   \* One example of using this script is to punish a user pressing the
   \* Windows key on an OpenSolaris system by launching the BSOD screen saver.

  #pragma D option quiet
  #pragma D option destructive

          ctrlcount = 0;

  /arg1 == keycode/
          ctrlcount ++;

  /ctrlcount == 10/
          ctrlcount = 0;
          system("/usr/bin/xscreensaver-command -demo 1");

First, we need to enable DTrace's destructive mode (ever heard of a "constructive prank"?) otherwise we can't call the system-command at the end. The script uses the pid provider to tap into Xorg. Therefore, we need to give it the PID of the Xorg server as an argument:

pfexec ./BSODKey.d `pgrep Xorg`

It then sets up a probe that fires whenever key_is_down is called with our keycode and counts the key presses. At the end of the key_is_down function call, it checks whether we reached 10 keypresses, then executes the BSOD screen saver and resets the counter. You may need to make sure that the DISPLAY variable is set correctly for the BSOD program to show up on the victim's screen when starting this script.

After hitting the Control-Key 10 times, we're rewarded with our beloved BSOD:


That wasn't too difficult, was it? Yes, one could have done the same thing by writing a regular script that taps into /dev/kbd or something similar. But the beauty of DTrace lies in the simplicity of this script (Tap into the right function while it's running) and in the fact that it now can be modified very easily to fire BSODs at any kind of event, including the user hitting a certain area of the screen with his mouse or selecting a particular text or whatever you choose it to be.

So, have fun with this script and let me know in the comments what kind of pranks (or helpful actions) you can imagine with DTrace!

Monday May 26, 2008

HELDENFunk Podcast featured in "Blick über den Tellerrand"

Our HELDENFunk podcast, part of the german sysadmin portal (If you don't understand German, you may prefer has been featured in episode #166 of Alex Wunschel's "Blick über den Tellerrand". Watch out after minute 21:50.

Blick über den Tellerrand cover artThe "Blick" is a weekly podcast in german about the "Blogosphere, Podosphere, Web x.0 and user/corporate-generated knick-knack". If you understand german and are interested in how social media is conquering Germany, this podcast is a must-listen. The german saying "Blick über den Tellerrand" means "glance across the edge of the plate", which is the german version of "glancing beyond one's nose".

The hot topic discussed in this and the preceding episodes is about Germany's public broadcasting agencies. On one hand, they get money from everybody who owns a radio, TV or a computer (read: Everyone, like a tax) and they're supposed to use it to create high-quality programming. On the other hand, the current draft of their "Rundfunkstaatsvertrag" (broadcasting state contract) forbids them to use more than 5% of the budget for online media. Their stance in this dilemma is published in the form of a controversial documentary called "Quoten, Klicks und Kohle" which can be loosely translated to "Vieweing Figures, Clicks and Dough".

You and I, but not enough people apparently, know that all media is significantly moving towards online ways of distribution. In fact, according to a study made by Bonn University and IBM, classic TV is losing importance, in particular among the younger generations and may become less siginificant than online media quite soon.

As part of this discussion, Alex is receiving quite a lot of feedback via email, phone and as MP3 files, which is where the HELDENFunk podcast is being mentioned in the current episode.

But who is this "Kontainer Kalle" guy?

Thursday Oct 25, 2007

Behind the scenes of the HELDENFunk podcast production

Marc, our heroic HELDENFunk producer Earlier this week, we posted episode 4 of the (german) HELDENFunk podcast to the site. It includes a CEC 2007 roundup with a pointer to Alec's excellent Futurology presentation, some information on the new UltraSPARC T2 based servers and some coverage of the Team Jefferson project.

Christian Müller, our studio guest in the latest episode told us that and the HELDENFunk podcast are now known as a great example of a well functioning "B2B messaging platform" (you have to excuse Christian, he's in marketing...) and he's busy travelling from marketing droid conference to marketing droid conference telling people what actually is. To me it's just a nice place for german sysadmins to hang out in :).

To the right, you see Marc Baumann, our heroic podcast producer while he's making sure that HELDENFunk listeners enjoy good sound. And so, let's take a look behind the scenes of the HELDENFunk podcast:

Once (now twice) per month we gather in a small conference room to record the next episode. Marc got us some nice microphones to record with: An Audio Technica AT-2020 for the moderator and two Røde NT5 for our guests. The audio goes through a Behringer Eurorack MX 802A Mixer where Marc can adjust the volume and pan for each individual speaker, then goes to a Native Instruments Audio Kontrol 1 A/D converter (which I already blogged about) and audio interface that is connected to my Apple Powerbook. We use Logic Audio Express 7 for recording (I'm still waiting for my upgrade to the new Logic Studio 8) and Marc uses Logic Studio 8 for mixdown and mastering (he already got his upgrade). Unfortunately, there are no good pro audio software solutions on Solaris, but who knows what the future will bring...

As you can see (and hear), good audio quality starts with good microphones and good mixing and A/D equipment. Still, post-processing is very important. I listen to a lot of podcasts while driving to work and these are the most common things that annoy me about podcast audio quality:

  • Overall low volume: It's such a hassle to have to turn up the volume a lot so you can actually understand what people say, then get yelled at once you switch from MP3 player to radio. Make sure your podcast has a volume that is comparable to radio or normal music. This usually means peak levels of just below 0 dB.
  • Poor audio quality: As said, 90% of a good sounding podcast is using good equipment before sound goes into the computer. Quality matters and the better quality audio comes into your computer, the better the outcome will be. For mastering, we prefer 128 kBit MP3 because it gives you reasonable audio quality (for a podcast) and maximum compatibility with devices at acceptable file sizes.
  • Large variations of speaker volume: When having multiple speakers, make sure their volume is more or less equal, otherwise some will yell while others will whisper. It's hard to adjust the volume while driving to work :). Using a compressor during post processing helps a lot here.

Me, talking to a microphone, trying not to look too silly.For the casual interview, we use a Zoom H2 audio recorder (here's a great and helpful review). This device offers excellent portable audio quality, ease of use, lots of recording options and great sensitivity, even in very difficult recording situations. For example, listen to the final episode of the CEC 2007 podcast (another podcast I was involved with) where we had a lot of background noise, still the voices could be heard nicely. Thanks to the 24 bit audio resolution, we can increase the volume way up for more distant or less loud speakers without introducing too much noise or artifacts. This can be heard during the second episode of the same podcast, where we spontaneously added John Fowler to the round of guests, while he was sitting at the other end of the table, more than a meter away from the microphone. Still, his voice can be understood quite well.

Yesterday, we recorded another interview for our next episode, which will be recorded next monday. With the new two week cycle, we now live in an "After the episode is before the episode" kind of world...

 If you understand german, try the HELDENFunk podcast. It's also listed in the iTunes podcast directory. And let us know your feedback and suggestions by writing to Thank you for listening!

Credits: Thanks a lot to Randy and Mel for shooting these pictures during the recording of episode 2.

Monday Oct 01, 2007

New HELDENFunk Podcast Episode Featuring 3 Interviews (2 in English)

HELDENFunk Episode 3 pictures 

Today, the 3rd episode of the HELDENFunk podcast went live. And we now have a jingle, too! I'm glad we reached this milestone: If we can bring out three regular episodes of this podcast, we can do 10, then maybe 100...

Even if this podcast is mostly in german, there are two very interesting interviews in english:

Of course, there's much more, albeit in german: Ulrich Gräf, OS Ambassador talks about Solaris 10 8/07 (update 4), we discuss Sun's newest servers based on Intel CPUs, the CFS acquisition, a nice case mod where one of our customers put a Solaris 10 server into his hand luggage, Solaris xVM and Project eTude and much, much more.

In fact, from episode 1 to 3, this podcast has ever increased in length. Maybe it's time to move to a bi-weekly schedule soon...

P.S.: If you understand german, make sure to participate in our sweepstake competition! 


Tune in and find out useful stuff about Sun Solaris, CPU and System Technology, Web 2.0 - and have a little fun, too!


« April 2014