Request: NT Hash (actually MD4)

[Bitweasil]

Not publicly available. I'd have to dig up an old version of my code, but I was faster on slower hardware before I revised it to handle large numbers of hashes in parallel. Slower for a single hash, but runs around 20B-25B hash checks per second on the 8800GTX depending on length.

Do you have any non-ICQ contact methods? PM me, I'd be interested in discussing some implementation details.

[Bitweasil]

Yea, I'm getting 485M/s on my single hash NTLM brute forcer, length 5 (didn't implement it beyond that, didn't need it beyond that for my project). This is on an 8800GTX, which has a rather significantly slower shader clock than the 9800GTX. I'm seeing 645M/s on a GTX260 (192SP version). I could probably tweak it to go faster, but development forked in a different direction.

[neinbrucke]

why would it be faster to crack multiple md4 hashes in parallel? ok, it's more efficient, but aren't you only creating more 'overhead' because you have to do more compares?

[Bitweasil]

why would it be faster to crack multiple md4 hashes in parallel? ok, it's more efficient, but aren't you only creating more 'overhead' because you have to do more compares?

You slow the "step rate" (the rate you are going through hashes) dramatically with large numbers of hashes in parallel, yes. My brute forcer drops from the above listed figures down to around 20M hashes per second generated with a load of 1000 hashes in it (max I can reasonably fit, 16kb shared memory minus charset space, and 16 bytes per hash). However, 20M * 1000 = 20B, which is my effective check rate.

It's a lot quicker to do that than to run 1000 hashes through a brute forcer running at 600M/s.

[BarsMonster]

why would it be faster to crack multiple md4 hashes in parallel? ok, it's more efficient, but aren't you only creating more 'overhead' because you have to do more compares?

You slow the "step rate" (the rate you are going through hashes) dramatically with large numbers of hashes in parallel, yes. My brute forcer drops from the above listed figures down to around 20M hashes per second generated with a load of 1000 hashes in it (max I can reasonably fit, 16kb shared memory minus charset space, and 16 bytes per hash). However, 20M * 1000 = 20B, which is my effective check rate.

It's a lot quicker to do that than to run 1000 hashes through a brute forcer running at 600M/s.

You can improve performance for large number of hashes by having a hash map in constant memory, and only if hash is in hash map, check list of hashes

[Bitweasil]

Interesting concept. I'll have to look into uses of constant memory, as I've not played with it at all. Later implementation.

[neinbrucke]

However, 20M * 1000 = 20B, which is my effective check rate.

oh ok, than i understand you... but it's kind of strange giving that number as the effective rate... as this counts for all brute forces on unsalted hashes... in my opinion the actual strength of a brute forcer is in it's speed of generating one hash... all the other functions such as generating input and comparing output are just overhead and should just be kept as low as possible (apparently your implementation has quite some overhead for the comparison, which is a shame considering your fairly fast brute forcer ).

[Bitweasil]

Testing 1000 hashes against a reference value isn't cheap to do, even with good memory access. Plus, by nature, it forces the code to branch, which hurts GPU execution times.

I agree with your comments on the point of a brute forcer, but I wasn't writing mine to be a general case system - it functions as a prefilter to the rest of my system, pulling the "easy" hashes out, so, for my purposes, my implementation works very effectively, and filters out the short NTLM passwords quickly (for a large input set), letting the GPU work on more useful things.

[blazer]

aww damn i wish i was on 64bit could really test this out.

Got a question though, what are the speeds like for the NTLM cracker compared to elcomsofts CUDA accelerated cracker? Anyone tested both of them yet?

[Bitweasil]

aww damn i wish i was on 64bit could really test this out.

Got a question though, what are the speeds like for the NTLM cracker compared to elcomsofts CUDA accelerated cracker? Anyone tested both of them yet?

http://www.elcomsoft.com/edpr.html

Apparently for NTLM, they're claiming around 365M/s for the 8800GTX. So, slow.

[TrashCanMan]

Remember to post here asking for the 32bit version, so I don't forget about it.

Any word on that 32bit version for NTLM? Thanks for all the work you guys do - this is absolutely the best cracker out there!

[BarsMonster]

Remember to post here asking for the 32bit version, so I don't forget about it.

Any word on that 32bit version for NTLM? Thanks for all the work you guys do - this is absolutely the best cracker out there!

http://3.14.by/files/NTLM_CUDA_x32.zip

[Bitweasil]

Ugh. EXE format? Bah.

[the_drag0n]

lol what do you expect ?! open source ?! lol!

[BarsMonster]

lol what do you expect ?! open source ?! lol!

Not all guys are on windows

[Bitweasil]

lol what do you expect ?! open source ?! lol!

No, as I don't, but 64-bit Linux binaries would be nice for those of us who prefer to run operating system that are well suited to incredibly compute-heavy, sustained tasks, or prefer our worm and virus prone OSes securely wrapped in a nice isolated VM environment without direct access to hardware. You should be able to compile CUDA binaries without actually having a full Linux box - run a VM, install the CUDA SDK, compile the binaries, and distribute. You shouldn't actually need the Linux environment to be able to touch a CUDA device to compile the code.

[BarsMonster]

lol what do you expect ?! open source ?! lol!

No, as I don't, but 64-bit Linux binaries would be nice for those of us who prefer to run operating system that are well suited to incredibly compute-heavy, sustained tasks, or prefer our worm and virus prone OSes securely wrapped in a nice isolated VM environment without direct access to hardware. You should be able to compile CUDA binaries without actually having a full Linux box - run a VM, install the CUDA SDK, compile the binaries, and distribute. You shouldn't actually need the Linux environment to be able to touch a CUDA device to compile the code.

x4d3 promised to port it to linux, I hope he would success soon .
Personally I already installed Ubuntu 8.04 64 bit, spent 2 hours just to install AMD video drivers on it
BTW that's worth 50$, is that still free OS? (Just kidding, I know that's a learning curve)

[TrashCanMan]

http://3.14.by/files/NTLM_CUDA_x32.zip

Thanks, BarsMonster. The MD5 cracker is utilizing 4 CPUS plus my GPU, yet this NTLM cracker is listing CPU @ 0.00 per/sec. Am I doing something wrong or is this feature just not supported in NTLM yet? Thanks in advance.

[BarsMonster]

There is no SSE2 code in NTLM, as it requires additional work.

[Bitweasil]

NTLM Multiforcer

http://3.14.by/forum/viewtopic.php?f=8&t=60

[Corni]

SSE2 MD4, which can be easily turned into NTLM...
http://freerainbowtables.com/phpBB3/vie ... 8248#p8248
If optimize that code please tell me what you did, as i'm currently cracking a mscash-hash with it, and I neither have a CUDA-card nor a decent quadcore/supercomputer, so I need every hash/s I can get

[x4d3]

Have some projects with short deadlines right now. But you can still expect the linux version sometime mid-December.

[neinbrucke]

Have some projects with short deadlines right now. But you can still expect the linux version sometime mid-December.

really?

[Bitweasil]

I'd add that Cryptohaze as a very nice Windows/Linux NTLM brute forcer - check the forum for the 0.7 binaries, as it's a LOT faster than the 0.6 ones on the front page.

[mastercracker]

What happened to the LM - CUDA development? I agree on the fact that most passwords can be found extremely fast with Rainbow tables but there are a couple of annoying LM hash that I could not crack because they are including weird characters like Ì or Ů. In this case the - X switch would be very useful. If this program ever go to multi-hash, the LM-CUDA could overrule the Rainbow tables also.