>>126
ah, interesting.
that sounds very much like you used the bitslice code, the output is 64bit binary there, does not include the salt, and it looked like converting it back would be possible.
"bitslicing" is class III vooodoo that treats one N-bit CPU like N 1-bit CPUs. john has a (already somewhat optimized) "normal" DES implemtation (that generates 128bit output with the salt mangeled in), and a even more insane bitslice one that does 32 or 64 crypt()-like operations "in parallel".

some stats, 1GHz athlon, custom framework (based on 4brute.c) doing targeted discovery on about 4k targets, kcps == kilo crypt()-equivalent-operations per second, including comparison, and measured against process user-time (not wallclock. so its equivalent to johns "virtual" rate.):

'John 1.6.38 / 64/64 BS MMX' => 279kcps (this is the "bitslice" version)
'OpenSSL 0.9.7e 25 Oct 2004' => 71kcps
'John 1.6.38 / 48/64 4K MMX' => 64kcps (this is the "normal" one)
'UFC-crypt 1c, 1.9 03/02/92' => 37kcps
'glibc2.3.4 slackware crypt' => 30kcps

this session taught me some things i didnt really expect:
1) forget ufc-crypt unless you have prehistoric hardware.
2) openssl fcrypt() is a very good starting point.
3) at 279kcps, the framework spends 10-15% of the cputime on generating the next input plaintext and comparing output against targets. and that is after some serious optimization in those areas. was more like 60% before that.