cryptosystem.org

While working on PicoDriveDS, I figured it would be easier to test if I used WMB instead of swapping SD cards all the time. I set up WMB, but much to my dismay, it didn’t appear to work correctly with my SCSD – the program would start, but it couldn’t read the files or directories. Due to testing by other people, I knew the CF version worked fine this way, but I didn’t have a CF cartridge to use. I did, however, have a 256Mbit GBA cart, and chishm’s FAT library has a driver called FCSR which can access a FAT image stored on a normal flash cart. The problem is finding instructions for how to build this properly. Here’s how I did it:

dd if=/dev/zero of=fat.img bs=512 count=32000
sudo losetup /dev/loop0 fat.img
sudo mkdosfs -F16 /dev/loop0
sudo losetup -d /dev/loop0

Now you can mount fat.img to your favorite mountpoint, copy files to it, then unmount. After that, what you have to do is open it up in a hex editor, go to offset 0×100 (nothing should be there, don’t worry), and insert the string “FCSR Chishm FAT”, ensuring it is null-terminated. For write support, following this null-terminated string should be the start sectors for 4 SRAM overlays, then followed by each of their sizes (I have not tested this). If you just want a filesystem on the cart so you can access it over WMB (like me), you can flash the image to a cart now. Otherwise, any rom you wish to use should be padded so that the image will be aligned on a multiple of 512 bytes, then prepended to the image.

Ported this over the weekend, I think it’s in a state now where some people will be able to use it. Initial reports are that it has issues running on CF-based carts, I only have a SuperCard SD to test with so I haven’t been able to debug it on CF to see what’s going on.

Built against SaTa’s modified FAT libraries from REIN (SD users probably want this):

• http://www.cryptosystem.org/projects/nds/picodriveds.nds
• http://www.cryptosystem.org/projects/nds/picodriveds.nds.gba

Built against chishm’s FAT libraries with just CF enabled:

• http://www.cryptosystem.org/projects/nds/picodriveds-cf.nds
• http://www.cryptosystem.org/projects/nds/picodriveds-cf.nds.gba

Copy it to your media, then copy over the Genesis ROMs you want to play (it should be able to play ROMs with .BIN, .GEN, and .SMD extensions). There’s no sound, but since it uses the Cyclone 68k core which is optimized for ARM it runs well for the most part. Scaling is done in-software right now so the downscale isn’t as fast or good as it could be. There’s no double buffering yet so you might see tearing on some games. Y/B/A are A/B/C.

Screenshots:

• http://www.cryptosystem.org/projects/nds/picodriveds-0.1-1.jpg
• http://www.cryptosystem.org/projects/nds/picodriveds-0.1-2.jpg
• http://www.cryptosystem.org/projects/nds/picodriveds-0.1-3.jpg
• http://www.cryptosystem.org/projects/nds/picodriveds-0.1-4.jpg

Video:

• http://www.cryptosystem.org/projects/nds/spaceharrier2.wmv

There’s been some commotion about the KittenAuth CAPTCHA and how effective it is or isn’t. Last weekend, I decided to give the PCA-SIFT algorithm a whirl against it and see how it went. After having wget grab a sufficient number of images, I deleted all duplicates and put the manually verified cats in a folder and got keypoints for them. Now finding out what is and isn’t a cat is as simple as a Perl script:

$ time find . -iname '0.*' -exec ./findkitty.pl {} \;
Finding keypoints...
64 keypoints found.
Finding keypoints...
105 keypoints found.
./www.thepcspy.com/images/dynamic/kitty/2/0.390180844063955 is a cat
Finding keypoints...
124 keypoints found.
./www.thepcspy.com/images/dynamic/kitty/3/0.390180844063955 is a cat
Finding keypoints...
96 keypoints found.
./www.thepcspy.com/images/dynamic/kitty/4/0.390180844063955 is a cat
Finding keypoints...
209 keypoints found.
Finding keypoints...
118 keypoints found.
Finding keypoints...
209 keypoints found.
Finding keypoints...
173 keypoints found.
Finding keypoints...
122 keypoints found.

real    0m6.045s
user    0m5.173s
sys     0m0.319s`

I used PCA-SIFT because, while it’s slower than a simple file hash (which would defeat this in its current form), it can still accurately match images which have been through a variety of modifications (i.e. pretty much all of the modifications I have seen suggested elsewhere).

It would be pretty hard to use the idea for this captcha and have a sufficiently large enough database that it could defeat the method I’m using to get around it. An attacker could just have it cache all the unique images it sees and only have to have a human look at any given picture once to classify it, and if you use a large source of known images that you wouldn’t have to classify (such as GIS or kittenwar), it’s reasonable to believe that an attacker could use it as well.

I’ve whipped up a short Perl script, available here, that converts a Netscape-style cookies file into the ELinks cookies format. This is useful for sites which have an image-based login captcha, so you can use Firefox to log in and then copy your cookies and have them in ELinks. Example usage:

./ns2elcookies.pl > ~/.elinks/cookies

By default, it does a find on ~/.mozilla/ for the first cookies.txt file it sees. You can also specify a cookies file as the first argument if that isn’t what you want. It should be fairly easy to modify the script so that it instead outputs in another browser’s cookie format, w3m for example.

Due to some changes in libavformat, the sample code at http://www.inb.uni-luebeck.de/~boehme/libavcodec_update.html no longer compiles correctly.

avcodec_sample.0.4.9.cpp: In function ‘int main(int, char**)’:
avcodec_sample.0.4.9.cpp:83: error: request for member ‘codec_type’ in 
    ‘pFormatCtx->AVFormatContext::streams[i]->AVStream::codec’, 
    which is of non-class type ‘AVCodecContext*’
avcodec_sample.0.4.9.cpp:92: error: cannot convert ‘AVCodecContext**’ 
    to ‘AVCodecContext*’ in assignment
avcodec_sample.0.4.9.cpp:105: error: ‘struct AVCodecContext’ has 
    no member named ‘frame_rate’
avcodec_sample.0.4.9.cpp:105: error: ‘struct AVCodecContext’ has 
    no member named ‘frame_rate_base’
avcodec_sample.0.4.9.cpp:106: error: ‘struct AVCodecContext’ has 
    no member named ‘frame_rate_base’

I’ve created a patch as well as a fixed example for the code. I’m not entirely sure about commenting out the frame rate correction hack, but those frame rate variables are no longer members of the AVCodecContext struct.

Also, for compiling under Debian, the recommended usage is not to change the include directives, but to use:

g++ `ffmpeg-config --cflags` -o filename filename.cpp 
    `ffmpeg-config --libs avformat --libs avcodec`

I have updated and modified Nikita Smirnov’s jabberd2 LDAP rosters/vCards patch for my own use, and thought some other people might be interested in it as well. This patch only includes the sm rosters and vCards modifications, and not the c2s ldapfull authentication method. It has been updated to patch cleanly with jabberd2-2.0s3. I have modified the roster publication for people using normal LDAP authentication, so the “@servername” text is appended automatically to the supplied LDAP uid before storing it in the roster (so you don’t have to maintain seperate uid’s and jid’s). I have also modified the sm.xml.dist.in example to be a little more clear. If you use a Debian-style distribution, you should be able to “apt-get source jabberd2″, put this in debian/patches, and run “debian/rules binary” to get a modified package.

All of this information is now being pulled from our LDAP server, which is pretty snazzy. You can get the patch here. So now, I have LDAP working for:

• user logins to Linux
• Samba PDC functionality (shares the same home directory etc. as their Linux account)
• company-wide addressbook (works in mail clients, as well as the copier/scanner machines)
• logins to intranet web apps (including the very cool Trac)
• Jabber authentication, rosters, and vCards
• postfix and Courier IMAP for mail handling
• pureftpd authentication

All in all, kind of a hassle to get going, but definitely worth it. There should be a free Linux distro that assumes you want to do this kind of stuff by default. Novell OES may come close, but it’s non-free in both the monetary sense and in that it relies on the closed-source eDirectory.

So there’s this really annoying bug that a lot of GNOME users have been experiencing, including myself. The first issue is that the default GNOME layout binds the “Windows” key to Super_L/Super_R, which prevents you from using it as a modifier key. This is a relatively easy fix; run gnome-keyboard-properties and change “Layout Options->Alt\Win Behavior” to “Meta is mapped to the Win-keys” (or just about anything other than “Default”, apparently). Now, you can open up gnome-keybinding-properties and use away. But wait! It mysteriously only works for some of the actions. This is because essentially two keybinding backends are used, gnome-settings-daemon and metacity. Turns out, gnome-settings-daemon ignores Mod4 (which is what the Windows key gets mapped to as a Meta). Thankfully, it’s an easy fix! Grab my patch or if you’re running Ubuntu/Debian, you can install these deb’s which already have the patch applied and restart GNOME (these have only been tested on Ubuntu Hoary). Now, rejoice that you can finally have Windows+L mapped to “lock screen”!

After struggling with this lovely error (”XML Parsing Error: not well-formed” while pointing to a nonexistant location in my code) for a while hacking around on Wereboy, I became a little frustrated. So I created a clean profile and added the extension, where it worked fine. Turns out that profiledir/XUL.mfasl will apparently keep around uninstalled plugin chrome then later confuse itself, resulting in this sort of breakage. You have to delete/move it then relaunch Firefox to force a rebuild.

This plugin lets you post Tomboy notes to a weblog through the magic of XML-RPC. Attached is the source (goes in tomboy-[ver]/Tomboy/Plugins/) and a diff/patch against the cvs tomboy-[ver]/Tomboy/Plugins/Makefile.am.

Notes:

• needs XmlRpcCS. Mono 1.1.x users, check my guide for installing it.
• there’s no pref’s dialog, you need gnome-blog, it currently reads your gnome-blog settings from GConf
• currently only supports the MetaWeblog API (MovableType, etc.)
• does not support post editing
• currently just uploads whatever the text value of the note is. If your blog supports setting a default formatting style (like Markdown), just use that in your note and it should show up properly.

Some ideas for enhancement:

• keep track of postID’s in an extra XML field (like width and height are now). This would allow you to upload a post, then edit/update it within Tomboy.
• move pref’s to Tomboy’s preferences dialog and GConf settings?
• let you sync your notes with your weblog. This would update your blog with local Tomboy changes, as well as pull down other posts not made from Tomboy into Tomboy.
• maybe a different icon?

Enjoy, feel free to enhance/update/improve/etc.

And yes, this post was made with it.

I was trying to work on some XML-RPC craziness under Mono, and came across XmlRpcCS and a nice tutorial. Problem is, since I’m running Mono 1.1.4, I could reference the built XmlRpcCS.dll assembly at compile-time with no problems, but the resulting program would die with:

WARNING **: Could not find assembly XmlRpcCS, references from
  ~/source/monoblog/monoblog.exe (assemblyref_index=3)

This is because with Mono 1.1.x, it seems you must register signed assemblies with gacutil. In order to do this with XmlRpcCS, you need to do the following:

1. Download the XmlRpcCS source file and unzip it.
2. cd to the XmlRpcCS directory and run “sn -k XmlRpcCS.snk” to generate your keyfile.
3. Edit the makefile and change the CSFLAGS line to “CSFLAGS=-define:__MONO__ -delaysign-“

4. Edit src/nwc/xmlrpc/AssemblyInfo.cs and add the following lines:

   [assembly: AssemblyDelaySign(false)]

   [assembly: AssemblyKeyFile("XmlRpcCS.snk")]

5. Run make

6. Run “sudo gacutil -i XmlRpcCS.dll -package XmlRpcCS“

Now when you need to compile against XmlRpcCS, just add “-r /usr/lib/mono/XmlRpcCS/XmlRpcCS.dll“, and it should work fine.