i guess the check for nRead==8 has been placed there for a good reason (maybe crashing because of trying to copy data while there were fewer bytes).

but i was already trying some other stuff, but i'll continue later.

well, i could read everything into a 'chain' at once, not using nIndexS and nIndexE, then the chain is masked and shifted when those values are needed, like this:



it might be a little faster in the end, but i don't think it's making the code more readable. And everything will probably change on the next version anyway, as there might be checkpoints in use, and PowerBlade is working on RTI2 format. We'll see about it later

Here is version 0.4 WITH source !

Changes:

* Memory usage down to about 50% (tnx sc00bz for pointing out the inefficiency, tnx jci for helping with the code)
* Works under linux!
* Speed up: implemented MD4 reference implementation, not using OpenSSL for NTLM anymore (tnx Bitweasil for supplying 98% of the code )
* Speed up: using OpenSSL a lot faster (tnx jci for pointing that out)
* Probably some more small things i forgot

I left some notes in the source, crediting bitweasil and jci, hope you don't mind

Compile under linux (can't be bothered to verify right now ):

pausing and skipping lm2ntlm doesn't work under linux, couldn't be bothered for now.

The Windows binary now comes with 2 dlls: one for openssl, one for posix threads.

About readability, you could:
1) use a union, with a struct for the nIndexEnd, with 3 "filling" so the real value starts at byte 6.
2) use 2 simple defines


You might be right about the other points though, but meanwhile - IMHO - if this works, uses 50% less RAM, and is at least as fast (if not faster), then why not ?

i used an array instead of a struct before, but i somehow found it a little lame to use
(i have no clue about programming 'decency' and such... so usually i really don't care )

i'll leave it with version 0.4 as it is right now (memory down to 50% and i didn't notice any drop in speed (reading from disk is way slower anyway)), and we'll try to make it nice and clean when the new changes are introduces.

small & quick reply :
_ i had an error, i just replaced the libeay32.dll by "my own" libeay32.dll and it works fine now (don't ask me what was wrong, same dll version)
_ do you think it's possible to use normal/perfect rainbow tables with it (.rt) ?

Thx in advance
(and good work)

if more people have that error, i'll swap the dll with the one that came with 'original' rcracki

why would you want to use normal rt's with rcracki? (and to answer your question, yes, should be possible, but don't think it will be done)

because the original rcrack isn't multithreaded
because i have rti and rt files in the same directory
because it's easier to have one exe wich works with both than 2 exe (one for rt and another one for rti)
because making it "compatible" could be usefull
because upgrading one binary is easier than 2 (routines, etc)

that's a nice list

so i guess you still have .rt tables which don't have a similar (or better) .rti variant ?

Having a few issues building on Linux, but mainly the file ChainWalkContext.cpp that's missing

I think what should use there is "rto2rti" oh, wait...

you don't want to rto2rti with every old rto... the current rto2rti does indexing, but also perfecting... so you'd reduce success rate.

and ehm, oops about that file

[edit]i uploaded a new src zip
btw, what other errors do you get? i only tested on an ubuntu 8.04 32bit

I'm building with gcc 4.3+ (Ubuntu 8.10)

my changes:

in Public.h, "u_int64_t" is not defined (throws a LOT of errors everywhere):


in hash_md4.h "__int32" is not defined:


a lot of undefined references to memset, memcpy, etc
in public.h:


Also, in CHashRoutine.cpp, a lot of hashes could use the "MD?_NEW" functions instead of openssl, and drop "<openssl/md?.h"> altogether

Edit:
To build on Linux use "-lpthread" and not "-pthreads"

Build it under debian etch with the changes of jci successful. Thanks a lot for your work.
Regards goody

I am benchmarking the MD4_NEW ... with mixed results:

with lengths aligned to 2 bytes performance is good, but for odd lengths (5,7,etc) its... slow...

length 4, 6 is about the same:


length 5:


length 7, with 2 threads:


If you want to, have a look at these:

MD4:
fast_md4.c fast_md4.h

MD5 (slightly faster than MD5_NEW):
fast_md5.c fast_md5.h


Edit:
I've made a few small modifications to your routine, it's now almost twice as fast on odd lengths, and a tad faster on evens too.
It's also faster than my own version , (maybe due to smaller code / not supporting any give length?)
(by the way, it crashed on any length > 31, i added a check so it just returns incorrect hashes )

length 7, 2 threads: