hashcat Forum

Full Version: Custom hash derived from DES encrypted pass
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I have a hash derived from a password where the password was first encrypted using DES and THEN hashed with SHA1.

Now, I am looking at 2 methods of reversing the hash:
1) I can crack the hash directly using hex characters 0x00-0xFF with a fixed length of 8.
2) I am not familar with all the hash mechs in hashcat, is there a hash supported which is devived this way? (I doubt it).

So, looks like I'm stuck with option 1. Now, I also have been reading through the forums and it looks like there are a lot of undocumented commands, such as "minlen=", i.e. commands that don't show up when using help -h.

So, I'm thinking of using minlen=8 with -hex-char and a characterset like this:
00010203...FF to get my full range hex set.

Is this the best way, or, will it take so long I'm wasting my time?

Thanks all!
So you have a password, that was encrypted with DES, then hashed with SHA1 right? So sha(des($pass)). No, by default hashcat doesn't support this. If you want to continue, you will need to first recover the DES string from SHA, then try to recover the plain from DES.

minlen= is not a hashcat option. You don't need to set a min/max since the length of your mask will determine what is run.
Wait, encrypted with DES? You mean really encrypted with DES or DEScrypt? DEScrypt is the thing in /etc/passwd, the one which results in length 13. If its encrypted with DES, it can have any length.
Some more info..

The hash is derived via code. I have the DES key and iv. The password, which is exactly 8 characters is encrypted with DES. Then the first 8 bytes of the DES ciphertext is hashed with SHA1. I have this hash.

So, I'm thinking I can do a hashcat crack using a custom charset of 0x00 - 0xFF. This is a long charset.

I'm unsure of how to pass in this charset to hashcat. Will hashcat take a hexstring like this:

00010203040506...FF? Or is there a better way?

Thanks much. I saw that hashcat has a charset of 0xC0 - FF, I am curious why the first 0xBF bytes are omitted.
(01-09-2013, 10:04 PM)damiank Wrote: [ -> ]I'm unsure of how to pass in this charset to hashcat. Will hashcat take a hexstring like this:

00010203040506...FF? Or is there a better way?

Thats the way you need to do it. It looks ugly, but its a very special case. At least it works Smile
For anyone else who ends up doing a hex crack, first off, it's not possible, for 7 characters, it'll take over a year. Actually, I wonder why all passwords aren't encoded this way, it's so simple, yet makes cracking next to impossible.

Anyway, the command used was:
oclHashcat-lite32.exe -m 100 --outfile outcrack --outfile-format 4 --hex-charset -1 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f404142434445464748494a4b4c4d4e4f505152535455565758595a5b5c5d5e5f606162636465666768696a6b6c6d6e6f707172737475767778797a7b7c7d7e7f808182838485868788898a8b8c8d8e8f909192939495969798999a9b9c9d9e9fa0a1a2a3a4a5a6a7a8a9aaabacadaeafb0b1b2b3b4b5b6b7b8b9babbbcbdbebfc0c1c2c3c4c5c6c7c8c9cacbcccdcecfd0d1d2d3d4d5d6d7d8d9dadbdcdddedfe0e1e2e3e4e5e6e7e8e9eaebecedeeeff0f1f2f3f4f5f6f7f8f9fafbfcfdfeff <hash> ?1?1?1?1?1?1?1?1

Seriously though, if passwords were simple encrypted before hashing is would make them infinitely impossible to crack.

Thanks,
so, one year is "infinitely impossible" to you?

for one, you must have an awfully slow system. 256^7 at 23 G/s would take no more than five weeks. two, if you have access to the hashes you almost certainly have access to the encryption keys as well (and you do.)

so in the case of sha1(des(pass)), you are guaranteed 100% recovery of the entire password database in about a month, nearly regardless of the size of the database. that's less time than most people spend cracking large databases for only an 85-90% recovery rate.

it's purely security though obscurity. in the end, it ends up being significantly weaker than actually properly protecting the password.