Should I bring all my shoes and glasses?

// >> February 2011

GPU acceleration of brute-force password cracking – some test numbers
| 25. February, 2011

I realize this isn’t a new topic and even a few years ago at the law firm we considered buying Elcomsoft’s GPU cracker for the lab.  The reason I think this is somewhat relevant today is that previously the cost to build a cluster of CPU-based crackers was somewhat prohibitive.  Since we know GPU performance far exceeds the CPU when it comes to processing encryption or hashing algorithms it makes sense to transition the brute-force, and even rainbow table, attacks to a GPU-based system.  Thanks to nVidia and CUDA people can develop these apps, and thanks to Bitweasil over at cryptohaze.com and the CUDA-Multiforcer app we can all mess around with this functionality.

So I decided to run some tests.  Part of this was to confirm the results that others have posted, but I also wanted to determine what my old GTX260 card could do.  Here is the test: I generated a NTLM hash of an 8 character password consisting of only lower alpha characters and numbers for testing (1deron10).  The tests consisted of breaking the hash on 2 different systems (my system and a GPU cluster instance in the Amazon’s EC2 cloud) .  I also used 2 different tools for comparison, Multiforcer (both 0.70 and 0.80) and JTR 1.6.37 patched for NTLM.  For full disclosure I did feed Multiforcer with the loweralphanumeric character set file only.

Here are the results:

My system (Multiforcer):

  • Software – Multiforcer 0.80 on the GTX260 (192 cores)
  • Average speed- 199M pw/sec
  • Time to crack – 2 hours, 33 minutes (cracked at 75% of the key space)

My system (JTR)

  • Software – JTR v1.6.37 patched for NTLM on a Core 2 (Q6600) Quad Core overclocked to 2.8GHz
  • Average speed- 1.9M pw/sec
  • Time to crack – 2 hours, 42 minutes (cracked at 0.6% of key space)

Amazon EC2 (Multiforcer)

  • Multiforcer 0.70 on (1) Tesla 2050 card (488 cores)
  • Average – 722M pw/sec
  • Time to crack – 57 minutes (same as before, cracked at 75% of key space)

So while Multiforcer and JTR both took about the same amount of time on my system I’m going to claim that JTR got lucky this time.  More tests to come.  What do these results mean?  Well, password lengths of 8 or less are no longer secure…even for NTLM/MD4 hashes…assuming you only use 2 of the 4 possible options from lower, upper, numbers, and symbols.  At the same rate, using lower, upper, and numbers in an 8 character password gives you a key space of 62^8, or 218 trillion possibilities.  At the rate of my system using the GPU it would take 13 days to check 100% of the space.  On something with a little more power, say the RenderStream box (www.secmaniac.com), it would take 2 hours and 45 minutes at 22B pw/sec rates.  That is pretty damn reasonable.

One final thought.  If Multiforcer supported multiple cards on multiple cluster systems, then we could spin up 5 EC2 GPU instances giving us a total of 4880 CUDA cores to play with…that should get you much closer to the RenderStream box, but in place of spending $14k you’d use this at a $10.50 rate per hour (or 56 days of continuous use before I hit $14k)…well, that also doesn’t factor in the power draw from the RenderStream J

If I get time to test other options, lengths, and so on I’ll post an update.

Westinghouse monitor EDID issue – part 2
| 23. February, 2011

Ok, so this is actually unrelated to what I was planning on posting, which was GPU brute-force password cracking and some stats I pulled using Multiforcer and different nVidia cards I had laying around.  In order to get Multiforcer to run I needed to update my nVidia driver to the latest version, which is 266.58.  The problem is I have a Westinghouse LM2410 monitor that has the good old EDID issue with the nVidia drivers.  No problem, easy fix right?  Modify the inf file with the correct values for my monitor in the OverrideEDIDFlags0 and we are back in business.  Problem is that, with the new driver anyway, adding the binary value for the EDID override via the inf file on Windows 7 64-bit doesn’t seem to actually add the value to the required key.  But, as this approach was simply adding a binary value to the registry during install, and it is just as easy to add it manually post driver install.  If you’re not familiar here are some simple steps to manually add the value:

1. Run regedit, find the Video key under HKLM/System/CurrentControlSet/Control/Video

2. Inside you should see a bunch of GUIDs, open each one until you find the one with two folders, 0000 and 0001, that also have subkeys of Display, Settings, and VolatileSettings.

3. Create a .reg file to add this key, or do it manually.  The binary value you need to add under the 0000 key is going to be specific to your monitor, so if you don’t have a LM2410 then do not use these settings.  Here is what I added (right click in in the pane showing the contents of the 0000 key, choose new -> binary value):

Value name: OverrideEdidFlags0 (that’s a zero)

Value: 5c,85,80,51,00,ff,ff,04,00,00,00,7e,01,00

4. Reboot and your LM2410 should now be recognized as a monitor, not a HDTV, and should look good as new.

If you don’t have the LM2410 monitor then this probably isn’t going to help you.  I know other people have posted this issue and solutions for Acer and Viewsonic monitors on other sites…good luck.  Now I can brute-force those damn NTLM hashes and not strain my eyes doing so.  Hope this works for you.

Theme made by Igor T. | Powered by WordPress | Log in | | RSS | Back to Top