The new release is brought to you by neinbrucke and I. It may be found at http://rcracki.sourceforge.net

From the changelog for the release:
* Fixed x86_64 linux compilation
* Fixed x86_64 linux segmentation fault
* Fixed 64bit support in md4 code
* Added support for: FreeBSD, NetBSD, OpenBSD, and MacOSX

If you encounter any problems feel free to post them here, pm us, or add a bug to the sourceforge tracker.

Neinbrucke is continuing his work on SSE support and is something to look forward to in a later release.

sssh, SSE2 support was supposed to be a surprise

oh and preferably add bugs through the SF tracker.

rcracki crack md5(16bit) ????

(32bit)md5: e10adc3949ba59abbe56e057f20f883e

rcracki_mt -h e10adc3949ba59abbe56e057f20f883e [path_to_specific_table]\*


(16bit)md5: 49ba59abbe56e057

????????????????????????????

How to explain md5(bit)

32bit_md5: e10adc3949ba59abbe56e057f20f883e
16bit_md5: ***********49ba59abbe56e057*******

32bit_md5>>16it_md5

16it_md5<>32bit_md5

MD5 when represented as a hex encoded value is 32 bytes long. I think where you used bit you need to replace it with byte. The item you are calling 16bit_md5 is certainly not md5.

MD5 is 32 hits (hex digit) or
MD5 is 16 bytes (16 bytes * 8 bits = 128 bits)
And boo on you for double posting jifan.

Hits is a new one for me. Yes the binary representation of an MD5 is 16 bytes but I didn't mention that as what he posted was not a binary representation and I didn't want to add information that was likely to just be confusing.

Feature request:
Rcracki_mt displays the read time for index and table files, and a summary with time spent on disk access and cryptanalysis. Any chance you could also include time spent on pre-calculation, per-hash average and/or total time? The info below is from my i7-920@3.6Ghz, using a 2x1TB SATA RAID0 (bios/software), Windows 7 64bit, 12GB DDR3 memory, searching for 2 NTLM hashes through the 290 files in ntlm_mixalpha_numeric_1-8_0 (using 7 threads, left one HT core for downloading 1-8_3 files...). If i observed correctly, i'm using double the time pre-calculating the NTLM hashes compared to LM hashes - approx 32-35 seconds per LM pash, and approx 65-70 seconds per NTLM hash. Oh, and the hashes and passwords are just for testing of course. No live system.

ntlm_mixalpha-numeric#1-8_0_40000x67108864_distrrtgen[p][i]_053.rti:
reading index... 243713404 bytes read, disk access time: 1.17 s
reading table... 536870912 bytes read, disk access time: 2.56 s
verifying the file... ok
searching for 1 hash...
plaintext of a4f49c406510bdcab6824ee7c30fd852 is Password
cryptanalysis time: 0.19 s

statistics
-------------------------------------------------------
plaintext found: 2 of 2 (100.00%)
total disk access time: 204.10 s
total cryptanalysis time: 151.19 s
total chain walk step: 1599880002
total false alarm: 12548
total chain walk step due to false alarm: 184369812

result
-------------------------------------------------------
0552f87b4a775ec18fa566bcd239cbd4 S3cr3T10 hex:5333637233543130
a4f49c406510bdcab6824ee7c30fd852 Password hex:50617373776f7264

Added to the feature request tracker on the project page: https://sourceforge.net/tracker/?func=d ... id=1127534

This is something I already thought about adding but was saving for after the latest release since the *nix side needs to have a lot of work on the timing code anyway.