Kirsle.net

Welcome to Kirsle.net! This is my personal homepage where I upload my software projects and other creative works, and it's where my web blog lives.

The site used to be on Cuvou.com but as of September 28 '09 I've decided to move it to kirsle.net -- all the old links on cuvou.com will redirect to their new locations here.

Redirect Audio Out to Mic In (Linux)

I discovered a neat trick you can do with PulseAudio: redirect the audio output of your computer to the microphone input, so that any application that supports recording from a mic will get your audio output instead.

I needed to do this because I was testing something at work that involved an Asterisk server calling a softphone running on my Linux box, and it wanted me to record a voice prompt and then hang up. This computer didn't have a microphone installed, so I started looking for a way to fake the mic input and make it record an MP3 or something instead.

If your system is using PulseAudio (every recent Fedora and Ubuntu distribution does), the steps to follow are:

1) Open PulseAudio Volume Control

This is pavucontrol on the command line, and in Fedora is provided by the package pavucontrol.

Go to the "Input Devices" tab, and select "Show: Monitors" from the bottom of the window. If your computer is currently playing audio, you should see a bar showing the volume of the output:

2) Start running an app that is recording audio, and go to the "Recording" tab and see if your app is listed.

In this screenshot I'm running Audacity and recording audio.

3) Click the input device button ("ALSA Capture from") and pick "Monitor of Internal Audio Analog Stereo")

And that's pretty much it. If you see volume bars on the Recording tab now then it's probably working, and the recording app is now recording your audio output.

Here's a full desktop screenshot of me running `play audiodump.wav` (a WMA-to-WAV conversion of the Windows XP Welcome Music) in a terminal, the PulseAudio Volume Control running, and Audacity recording from the mic.

Categories: Linux

[ 0 Comments | Leave a comment | Permalink ]

Linux Desktop Monitoring Software

Over a period of time I've put together two Perl scripts to help monitor a Linux desktop system.

Why? To see if anybody else uses my computer when I'm not there, and to see what they were doing with it.

screenspy - Linux desktop monitoring daemon

This is the visual desktop monitoring script. It takes quite a lot of screenshots during periods when the desktop is currently being used.

Basically, you run this script as root, and it monitors your major hardware input devices for any activity. By default it watches /dev/console (which, on Fedora systems, seems to output data whenever there's keyboard activity), and /dev/input/mice (which is a common node for the collective input of any and all mice attached to a computer).

When it sees any activity at all on either of these devices (it doesn't care what the devices are doing, it just cares that they're active), it begins taking screenshots. If you use the keyboard or mouse for a little bit, and then stop for 2 seconds, it takes a screenshot. If you use the keyboard or mouse constantly and don't stop, it will take a screenshot every 5 seconds.

So it essentially creates a visual log of everything you were doing on the computer; every time you type, stop typing, type like crazy, move the mouse, stop moving the mouse... anything that happens, a screenshot is taken.

It uses scrot to take the screenshot, since this is the lightest-weight screen capturing program I could find. Using ImageMagick's import command is slow, and makes the computer beep, and GNOME's screensaver application can't run without showing a GUI window.

You can check it out here. You'll be required to edit the script in the "configuration" section though, at least to change the directory where it saves the screenshots to.

Since the script runs as root, the images it creates are naturally owned by root as well, and can't be deleted by the nonprivileged user, even if the user does manage to find the screenshots. Better yet, you can have the screenshots saved under root's home directory, keeping them completely out-of-sight for the user. And, to kill the script, you have to be root since it will be a root-owned process. +1 if your unauthorized users don't know your root password!

keylog - A Simple Keylogger

This is just a simple keylogger that reads from one of the input event devices, like /dev/input/event0. You run it as root again, and it saves keystrokes to a file under /tmp.

Actually, it doesn't store all keystrokes; instead, it stores what the user "intended" to type. That is, if a user begins typing a sentence and makes a typo and hits backspace a few times and then continues typing, what gets logged is what they actually ended up typing... you don't see their typo; when they hit backspace, the log buffer also deleted the last character it logged, before saving it to disk.

It separates what they type based on certain "divider characters," which includes Tab, Return and Enter. So as they fill out a web form, the script would log one line of text for each field they filled out as they tab through the form. Also, if they delay their typing for a few seconds it will dump the current buffer to the log file as well, so if they're a particularly slow typer, one "sentence" may span multiple lines in the log file.

I can't recommend using this keylogger for malicious purposes, it's just being uploaded for educational purposes only and should only be used as a personal desktop monitoring solution, if it should be used at all.

Source code: keylog.

Categories: Perl, Linux, Blackhat

[ 0 Comments | Leave a comment | Permalink ]

2D Game Engine in Perl

Over the last month or so I've seen slowly piecing together some ideas and laying down some foundation code for a 2D game engine, written entirely in Perl.

The type of game I'll be making with it will be a 2D RPG type game, with a top-down perspective (think: Zelda, SNES-era Star Ocean, etc.). I feel that this type of game offers the most flexibility, having a wide-open game world where you can move your character in two dimensions.

I'm programming it in Perl, because I know Perl better than any other language (with Java coming in second place, but I'll avoid getting Java involved if I can help it). ;) However, it's highly possible that I'll need to switch languages down the line, so I'm future-proofing what code I am writing just in case any major changes need to happen.

For example, I like the model employed by Sierra and LucasArts when they made their games based on AGI (Adventure Game Interpreter) and SCUMM (Script Creation Utility for Maniac Mansion), respectively. Their game engines were programmed in who-knows-what language (likely C), but the games themselves--the scripts for dialog and interactions within the game--used a new, home-made programming language. This way, the game engine can be reprogrammed in a different language, and the existing games can "just run" on the new engine without any modification.

This is how ScummVM is able to run old SCUMM games; they've just re-implemented the SCUMM engine, and the existing games can "just run" on ScummVM without requiring them to be modified at all.

So, my game engine will be similar, using a new scripting language, so that if I have to scrap Perl in the future and go to Java, all I need to do is re-implement the engine in Java, and what game code I have written will "just work" on the new engine.

Now, as for the Perl stuff... I'm future-proofing my code against other Perl modules, too.

The engine runs out of a core Perl module, and it uses multiple "front-end plug-ins" to actually interact with the user. They're divided into three categories: Graphics Front-end, Sound Front-end, and Filesystem Front-end.

Graphics Front-end

The choice for graphics boiled down to two general options: Perl/Tk, which I already know really well, and SDL Perl, where SDL is usually used for 2D games in other programming languages.

Perl/Tk may be dated, and look ugly as hell on Unix, but if the Tk window only consists of a Canvas widget (which is what I'm planning for), you won't be able to tell. Compose a nice picture in a Canvas and it looks the same on all platforms.

Tk Canvas treats everything you draw in them as "objects", or sprites as far as my game will be concerned. It means that once you put an image in the canvas, you can move that image around later by its ID. SDL, on the other hand, is not sprite-based, but pixel-based, so to move a sprite you've already placed, you have to erase it and redraw it. Plus one for Tk.

Tk Canvas doesn't support layers, but it does support "implied layering"... that is, each object you place on the canvas gets an implicit Z-index that's one higher than the object you placed before it. This is the same as the default behavior in HTML. When you move sprites around after placing them, they'll either stay above or below other sprites, depending on the order the sprites were drawn. Therefore, by drawing sprites in the right order, layers can be simulated. SDL doesn't support layers either, so +1 for Tk here again.

At any rate, the graphics front-end won't be too integrated with the core game engine. Instead, it will register callbacks to the engine, so Tk will say "when you want me to draw a sprite, call this function of mine and I'll take care of it."

This way, the core engine just tells the graphics front-end what to do: what sprites to draw, where to move them to, etc. and the front-end just does as it's told. This way, the internals of Perl/Tk don't get caught up in the core engine; if I need to ditch Tk and use SDL instead, I just need to make SDL respond to the same commands from the core as Tk does and all is well.

Sound Front-end

One advantage SDL has over Tk is that SDL also handles audio. However, Perl's SDL implementation is a little bit lacking when compared to other programming languages; SDL-Perl can only play wav audio (for sound effects) and ogg vorbis (for music). Not exactly a lot of wiggle-room here for other formats.

Tk doesn't have any audio support of any kind. But fortunately, there are other Perl modules that can handle audio. For Windows computers, there is Win32::MediaPlayer, and for Linux there is GStreamer.

Win32::MediaPlayer and GStreamer both can play whatever codecs the user has installed. On Windows this means it can play mp3, wav, even midi music out-of-box. On Linux it means it can play wav, ogg, and other formats that aren't patented. If the Linux user installs MP3 support, though, GStreamer can play mp3 files too!

Similar to the graphics front-end, the sound front-end registers callbacks. When the core wants to play a sound effect, it calls a method in the sound front-end to do so, and the sound front-end does it.

If I stick with open audio formats, I can have an SDL audio front-end to get sound for Mac OS X too, since there isn't yet a Perl module to play sound natively on OS X.

Filesystem Front-end

The reason for the filesystem front-end is basically to keep the players from getting into the game's data files. I have plans to reprogram Archive::Tyd to make it support large archives, and to make read-only archives.

With such an archiving algorithm, the game could store all its data files (images and scripts) into a read-only archive, which only the game knows the password to. This stops the players from getting in there and seeing sprites for characters in the game they haven't seen yet themselves, and especially to prevent them from modifying the game's script if they do manage to get into the archive.

(By the way, my game engine will probably be released as open source software, so you'll be able to make your own games with it; just stay out of my games' files!)

Until Archive::Tyd is completed though, the game will just read files off the filesystem directly. But the filesystem front-end is there so that in the future, I can replace it with one that reads files out of Tyd archives instead.

Anyway, I've already gotten a few hundred lines of code written, and the general framework for the engine is already working (abstracting away the graphics front-end from the core, for example). I've recently completed a tileset handling Perl module which I intend to use for it.

When I get more work done, and especially when there's a playable demo of the game engine, I'll probably make a small website for it as a subdomain of kirsle.net.

Categories: Perl, KAGE

[ 1 Comments | Leave a comment | Permalink ]

SSH Port Forwarding

This blog post is primarily for my own reference, to avoid having to dig through the manual to look up the occasional edge case.

How to use SSH to do port forwarding. These assume you're on a Unix-like system (Linux or OS X) and not using some lame Windows client like PuTTy.

Forwarding Remote Ports to You

Example: you're behind a firewall at the office, and your home computer is listening on the SSH port. You can connect out of the office to your home computer, opening a port so that, once you're home, you can SSH back to the office again (bypassing the firewall).

ssh -R 9022:localhost:22 remotehost.com

This will open port 9022 on remotehost.com (loopback only; you can only connect to 9022 from the local remotehost.com, not from elsewhere on the internet), and forward it to "localhost:22", where "localhost" refers to your computer at the office, and 22 is of course the SSH port.

By default the remote host only would make port 9022 available on the loopback address, so from your home PC you can do ssh -p 9022 localhost and connect to it, but you can't do e.g. ssh -p 9022 remotehost.com and connect to it from somewhere else on the Internet.

To open the port on all interfaces (thus making it available on the internet too):

ssh -R *:9022:localhost:22 remotehost.com

Replace the * with any other bind address if you want.

Forwarding Local Ports to Remote

If your home computer is running a web server on port 80, and for some reason you can't get to it from the Internet (firewall blocking it, maybe), you can forward a local port on your office computer that gets you to port 80 on your home computer.

ssh -L 8080:localhost:80 remotehost.com

Here, 8080 is opened on your office computer, for the loopback interface only, and localhost:80 refers to port 80 on the remote (home) computer. It's the reverse of ssh -R.

Then you open Firefox and go to http://localhost:8080/ and yer in.

Another example: you have a VNC (remote desktop) server running on remotehost.com, but the VNC protocol itself is insecure, and you don't want your password being sent across the network in clear text to log in. So, you need your VNC traffic to be encrypted via SSH.

Here, remotehost.com is listening on port 5900 (the VNC port). You want to open a port on your local computer to the same number, so that you connect a VNC client to "localhost:5900" and it really connects you to "remotehost.com:5900" over a secure SSH tunnel:

ssh -L 5900:localhost:5900 remotehost.com

Then with your VNC client, just connect it to "localhost".

Using SSH as a Secure SOCKS 5 Proxy

As a bonus, here's how to open up a secure SOCKS 5 proxy over SSH:

ssh -D 8080 remotehost.com

Now you can configure your programs (e.g. Pidgin, Firefox) to use a SOCKS 5 proxy and have them connect to localhost:8080. All their internet traffic will be routed through the SSH tunnel to remotehost.com, secured, and then enter the cloud from there.

Categories: Linux

[ 0 Comments | Leave a comment | Permalink ]

Get FAT Drive Serial Numbers in Unix

There's not a lot of information about this on The Google, so hopefully this blog will help anyone who wants to know how to get the serial number of a FAT partition from within a Unix-like operating system (including Linux and Mac OS X).

First, this is what I mean about serial numbers. Suppose you're using a Windows system, have a floppy disk at drive A:/ and a regular USB flash drive at E:/, and you run these commands in the command prompt:

C:\>vol E:
 Volume in drive E is CRUZER
 Volume Serial Number is 955C-59BF

C:\>vol A:
 Volume in drive A has no label.
 Volume Serial Number is EC2B-36AF

These serial numbers are assigned when the drive is formatted; reformatting a floppy disk or flash drive will give it a different serial number.

According to The Wikipedia, the serial number (ID) is kept in two different places on the partition depending on the version of FAT being used.

In FAT12 and FAT16 (used with floppy disks), the ID begins at byte offset 0x27 (39 in decimal); in FAT32 (used with flash drives and external hard drives), the ID begins at 0x43 (67 in decimal).

So, with the handy dd utility that comes standard on pretty much any Unix-like system, you can extract this information and display it. Here are a couple of one-liners you can run in a Unix terminal. I'll explain how they work afterward.

# For FAT32 filesystems (modern flash drives)
dd if=/dev/sdb1 skip=67 bs=1 count=4 | hexdump -v -e '1/1 "%02X" " "' | xargs perl -e '@_=@ARGV; print "Serial Number: $_[3]$_[2]-$_[1]$_[0]\n"'

# For FAT12/16 filesystems (old floppy drives)
dd if=testfloppy.img skip=39 bs=1 count=4 | hexdump -v -e '1/1 "%02X" " "' | xargs perl -e '@_=@ARGV; print "Serial Number: $_[3]$_[2]-$_[1]$_[0]\n"'

I underlined the input file (if) and byte offset (skip) in both of these commands. In the first one, I ran the command on a real, physical, flash drive, that had a device node at /dev/sdb1 for its one and only partition. In the second one, I ran it on a floppy disk image file (who has a computer with a real floppy drive these days?)

If you're going to be using a physical device like in my first command, you need to run the command with root privileges (regular users can't read directly from the device node). My second example (using an image file) can be run as a regular user, however.

These commands printed in the terminal for me:

(for the flash drive)
4+0 records in
4+0 records out
4 bytes (4 B) copied, 3.3445e-05 s, 120 kB/s
Serial Number: 955C-59BF

(for the floppy image)
4+0 records in
4+0 records out
4 bytes (4 B) copied, 3.1551e-05 s, 127 kB/s
Serial Number: EC2B-36AF

And now, how the commands work. I'll use the flash drive command as the example. In this one-liner, three commands are being executed at once:

dd if=/dev/sdb1 skip=67 bs=1 count=4
hexdump -v -e '1/1 "%02X" " "'
xargs perl -e '@_=@ARGV; print "Serial Number: $_[3]$_[2]-$_[1]$_[0]\n"'

The dd command gets the operating system to read raw data from the flash drive at /dev/sdb1, skipping the first 67 bytes, reading only 1 byte at a time, and reading a total of 4 bytes. This gets the 4 byte serial number; now we need to display it in hexadecimal like Windows and DOS.

The hexdump command takes the 4 binary bytes and displays them in hexadecimal. On my flash drive, it looks like this: BF 59 5C 95. Note that the hex codes are out of order; Windows shows them as 955C-59BF - basically, the reverse of what hexdump shows. Hexdump is showing the correct order; Windows and DOS reverse them when they show you the serial number.

So, we run it through xargs (which turns the four hex numbers into four separate parameters) and sends them to a quick Perl script, which prints out "Serial Number:" and puts the hex codes in the correct order, to give the same result as Windows and DOS.

One could use this information to make a vol command for Unix. If the command checks other places in the filesystem headers to determine the version of FAT, it could automatically use the correct byte offset and get the serial number from both floppy disks and flash drives.

Categories: Linux, Windows, DOS

[ 0 Comments | Leave a comment | Permalink ]