Let's keep it short, new plaintext generation, caching:
Old speed: ~200 Mhashes/s
New speed: ~315 Mhashes/s
Just shows the algorithm should not always be the main target of optimization.
Files:
EnTibr_0.3_win32.zip
EnTibr_0.3_src.zip
Wednesday, August 5, 2009
Subscribe to:
Post Comments (Atom)
Great work! I appreciate it.
ReplyDeleteI have e6750 on windows vista but my speed is only 72Mhashes/s. My CPU is only use at 50% on 2 threads. 60% for core1 and 40% for core 2. I have the same bug with a e8400 on windows xp.
ReplyDeletethat seems a bit strange yes. so you are actually using -t 2 to use 2 threads and you start a job that's long enough?
ReplyDeleteat least the e8400 should be able to get about half my performance as it's like exactly the same cpu, just that mine has 4 cores instead of 2. E8400 is clocked at 3.0 Ghz, mine is overclocked to 3.2 Ghz. So i'd say you should be able to get like 140-150 Mhashes/s on that one.
thanks, that was my mistake, I forget -t 2.
ReplyDeleteoff topic but any chance you could make a brute force tool to attack cisco IOS hashes?
ReplyDeletei don't think so, at least not in the near future.
ReplyDeleteLove the projects :) but I've been thinking about if you could create a LM brute forcer? This would be very handy and hopefully you can get it as fast as NTLM hashing in which case, simple alpha-numeric charset upto 7 chars would not take long at all. This would ultimatly mean I would not need my 24GB of rainbow tables, just your LM brute forcer ;)
ReplyDeletehi md5decryptor admin, it's on my wish list... but i'm pretty sure it'll just stay on that list :p
ReplyDeleteShame :( I've created one already but it takes around 1 min to do upto 4 chars with alpha-numeric. LM needs upto 7 obviously.
ReplyDeleteThanks amazing performance on my Q6600@3ghz, commercial software(elcomsoft) reaches 28Mhashes/s, your algorithm reached 130Mhashes/s.
ReplyDeleteJust though i'd post my speed on here. I currently have an Intel Q9450 @ 3.2ghz with 6gb ram and i get 316.20 Mhashes/s
ReplyDeleteCheers
Thanks very much for writing EnTibr NTLM and improving it so much! I have two quad-xeons, X5570s at 2.93GHz and am getting 520 MPS! Question: is there a way to stop the program and then restart it from the same password?
ReplyDeletetnx for the speedpost jack, that matches mine :)
ReplyDeleteJimmy, nice speed as well.. and i'm sorry, no restore points
thanks for the update.
ReplyDeleteLength 7 - 11% in 11448.83 s (648.31 Mhashes/s)
getting some good speeds here on a stock i7 920. unfortunately this is going to take days :)
Thanks for the answer, Daniel. Another question, if I may: is there a way to select a character set that, for example, uses lower-alpha plus special characters and the space?
ReplyDeletejimmy, some combinations are easy to add to EnTibr. but the way my brute forcers currently work do not allow a truly custom character set to be specified. Plaintext generation works with 1 to 3 ranges of characters, a range being for example 0x61-0x7A (lowercase). Any character set that you can compose of such 3 ranges is easy to implement currently.
ReplyDeleteWould be nice a restore point like rracki :D
ReplyDeleteBut anyway, thanks for the tool
Daniel hi.
ReplyDeleteThe way you have compiled EnTibr, it runs on processors without SSE2 (for example AthlonXP), but never find passwords.
I think you have to recompiled it in a way to prevent non-SSE2 processors to run it.
Sources for GNU/Linux users : http://bobotig.fr/contenu/programmes/EnTibr_0.3_src_gnulinux.7z
ReplyDeleteGreat job and good continuation ;)
Hello, Daniel. I just ran EnTibr on our newest machine. It's a Win 64, with 2, 6-core Xeon X5670s running at 2.93GHz with 24GB RAM. Using the lowerapha-numeric set with a length of 8, EnTibr was pushing 873 Mhashes/s at 24 threads!! Very impressive! I can send a screen shot if you wish.
ReplyDeleteJimmy_W, if you recompile the source with Intel C++ Compiler, you will break 1 Bhashes/s. My estimation for your system is a speed of 1.1 BHashes/s
ReplyDeleteThanks, Nikos. I do forensics- I'm not a coder, so I have no experience in compiling source code. I will, however, check this out and see what I can learn.
ReplyDeleteI checked with one of our coders. He said that EnTibr's source also uses a separate set of code that was developed for running the multiple threads (pthread), and that code is not yet available as a 64-bit library. Hence, I guess that I'm running as optimally as I can for a 64-bit system. Still, the speed is incredible!
ReplyDeleteJimmy_W: shouldn't matter, every 64-windows has a 32-bit "subsystem" or whatever you wanna call it, just compile it 32-bit..
ReplyDeleteas every modern processor, Xeon X5670 has the 32 instructions.
it goes less than 100 on ubuntu, around 180 on Win7...
ReplyDelete(using gcc 4.5 and mingw-gcc4.5)
would be good if someone could debug this... :(
(only tested on core i7 820...
oh, and 820 is 1 of the worst i7 processors :p)
I've Tried the same thing as Hans,
ReplyDeleteit looks like on a ubuntu system the speed is much slower.
thank you very much for a very usefull/great program.