cryptosystem.org

Since my last post about PicoDriveDS, 0.1.2 has been released. Changes:

• Switched from Cyclone 0.0080 to Reesy’s Cyclone 0.0084
• Switched from software scaling to hardware scaling
• Added three scale modes: Stretch, Aspect, and 1:1
• Cycle through scale modes with L
• Position the window in 1:1 mode by holding R and using the D-Pad
• Added soft reset (press select, takes you back to the ROM list)
• Added NDS banner information (shows up in WMB)

The links without version numbers will always point to the latest version, although I’m going to start making backup copies of each version in case people ever want an old one for some reason.

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

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.

I recently needed to print some size 10 envelopes using a Samsung ML-2010 laser printer under Linux. While printing envelopes using OpenOffice is possible, after a few trial runs I wasn’t really happy with the output and decided TeX/LaTeX might be better suited to the job. Adapting Michael Stutz’s code from here gave me the following:

% envelope.tex
% Print a #10 envelope

\font\cmssa = cmss12
\font\cmssc = cmss14

%setup:

\parindent 0 pt\nopagenumbers\parskip 10 pt
\hsize 9.5 in\vsize 3.25 in
\voffset 1.25 in
\cmssc

%document:

FROM-NAME

FROM-STREET ADDRESS

FROM-CITY, STATE, \ ZIP

\vskip .4 in\parindent 3.5 in

TO-NAME

TO-STREET ADDRESS

TO-CITY, STATE, \ ZIP
\end

Compile with:

tex envelope.tex; dvips -t landscape -m envelope.dvi

Then you can print with cupsdoprint or your favorite PostScript printing application. The envelopes should be inserted landscape-style, face up, open edge on the right side, in the center of the feed tray with all other paper removed and the guide tabs adjusted to fit the height of the envelope. The source TeX file is also available here.

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`

Well, I got an 80GB PQI mPack P800 a few days ago after a bit of searching. The iAudio X5-series devices were at the top of the list for quite a while, as I rip most of my albums to FLAC and it’s one of about four players that supports it. The video support appeared kind of tacked-on (low-resolution low-fps only), however, and since I would be spending the money anyway it was a feature I was looking for. The i-Station series portables got some consideration, but there are basically no US distributors. I looked over Archos’s offerings, but none seemed to play video files over 700×480 or so. The mPack’s availability from NewEgg, broad format support, and large drive space won me over in the end.

Sadly though, the device is far from perfect. The interface is pretty clumsy, and if you want to use the device in USB mass storage mode only without their Windows-only transfer utility, you lose the music database functionality and quite a few other things. If you have a directory structure like:

Funk/
 Funk.mp3
Funk Rock/
 Funk Rock.mp3
-Funk- Rock/
 -Funk- Rock.mp3

Then play Funk.mp3, it will just play it over and over instead of moving on to Funk Rock.

Worst of all, they’re blatantly violating the GPL (the firmware uses a modified Linux kernel, the main application embeds code from the GNU fileutils, and the firmware also uses dosfstools). I’ve requested the source from them, but I’m not too optimistic based on my experience in the past with these sorts of things (I’m the OP in the avsforum thread, and the Duke website which is no longer there was mine). Hilariously enough, the mPack apparently uses a Sigma Designs EM85XX.PVP chipset. Does Sigma distribute these things with a mandate that the manufacturers ignore and violate the GPL as much as possible?

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.

At work, my main focus for the present time is getting our massive LTSP/LDAP/HTTP/DHCP/ACRONYM Linux server up and going in to production. I thought it would be a good idea to set up a message server for employees to use for quick office communication, and Jabber seemed the obvious choice. There were a few little hitches getting it integrated with LDAP, so in case anyone else comes across this problem, here’s a small guide to the changes that need to be made to the jabberd2 conf files:

c2s.xml:

• Disable user registration.
• Change <host> in the LDAP section to the appropriate host.
• Hopefully you have your server resolving to a domain name, even if it’s an internal one such as “companyserver” (if you don’t, you should set it up now. You wouldn’t want to have your users showing up as username@192.168.100.1 or something). In the <local> section, set up a new realm such as <id realm='company'>companyserver</id>.
• Now that you’ve set up a new realm, you need to add an LDAP basedn for searching in that realm. In the LDAP section, add <basedn realm='company'>ou=people,dc=company,dc=com</basedn>, adjusting for your specific directory layout.
• There seem to still be some issues with LDAPv3 in the version of jabberd2 (2.0s3) that’s currently in my distro. Setting jabberd2 to use LDAPv3, slapd refuses the connection with “requested protocol version not allowed”. I had to leave v3 commented out and alter my slapd.conf to allow v2 connections.
• Change the backend module in the authreg section to “ldap”.

sm.xml:

• Turn on user auto-create by uncommenting it.
• Change the sm id to the realm you set up earlier. In the example’s case, this would be <id>companyserver</id>.

Now you should be able to restart jabberd2 and have users login as username@companyserver, authenticated against your LDAP directory.

If only I’d had this book beforehand: