I've tried the following this morning, REAL.hash is SHA1(SHA1(password)), and password is CHAR [NULL] CHAR [NULL] CHAR [NULL]
SHA1(SHA1(A[NULL]B[NULL]C[NULL])) = C6876C05F745140F51A200F82159463C91B2522F
SHA1(SHA1(1[NULL]2[NULL]3[NULL])) = EF5EA59F73ED422686786822FA17B3B0DF1B953D
The file NULL.hcchr is the single null character, and I'm looking through upper alphabet, and numbers (to cover ABC and 123)
I'm not -i them, as I know the length already:
cudaHashcat64.exe -a 3 -m 4500 REAL.hash -1 ?d?u -2 NULL.hcchr ?1?2?1?2?1?2
It doesn't find either of them, I've swapped around the ?2?1 as well, just in case (though the debugger shows the byte array as "char, 0" 3 times ).
I think oclHashcat doesn't support the [NULL] character at all!
What with it being a string terminator in C and C++.
Does this make passwords with [NULL] added in the code as the password impossible to crack as it stands?
no, oclhashcat supports the full 0x00-0xff range. but i'm not sure you can get oclHashcat to read a null character from an hcchar file since getline(3) is null-terminated. (edit: actually no, it does indeed read a null character from a hcchar file just fine.)
normally if you want to use null in a custom charset, you need to use --hex-charset. you can also use $HEX[00] in a wordlist, or use --hex-wordlist.
First of all, the topic of this thread is really disgusting.
The problem at the other hand, is very easy and you should probably easy understand it (indeed here:
https://hashcat.net/forum/thread-3518-po...l#pid20148 you even say that you have the code to produce it)... While Double SHA1 (and Double MD5 etc) are using the hex representation as input for the second round (i.e. sha1_hex (sha1_hex ($pass))), the algo that is used in your example is very different (i.e. sha1_hex (sha1 (encode ("UTF-16LE", $pass)))).
Note the difference between hex representation and binary represenation (=> input to second sha1_hex call)
So I don't know if you can say you beated hashcat with an algorithm that is totally different (and currently not supported).
Hope this helps to understand why the results are different
Ps. NULL bytes are no problem for *hashcat at all, but if you try some hashes that were generated w/ a very different hash algo you ofc can't recover them w/ Double SHA1
Sure your hash type is right? I was able to recover A\0B\0C\0 without issue (plain sha1):
a9b1640a163865c75b3a97c7f927750297a1969a:$HEX[410042004300]
% cat dict| xxd
0000000: 4100 4200 4300 0a A.B.C..
% ./oclHashcat64.bin -m 100 test -a 3 -1 null.hcchr '?u?1?u?1?u?1'
...
a9b1640a163865c75b3a97c7f927750297a1969a:$HEX[410042004300]
...
cat null.hcchr| xxd
0000000: 00
(07-03-2014, 08:05 AM)radix Wrote: [ -> ]Sure your hash type is right? I was able to recover A\0B\0C\0 without issue (plain sha1):
a9b1640a163865c75b3a97c7f927750297a1969a:$HEX[410042004300]
% cat dict| xxd
0000000: 4100 4200 4300 0a A.B.C..
% ./oclHashcat64.bin -m 100 test -a 3 -1 null.hcchr '?u?1?u?1?u?1'
...
a9b1640a163865c75b3a97c7f927750297a1969a:$HEX[410042004300]
...
cat null.hcchr| xxd
0000000: 00
Bol****s!
Let me just run through the code:
To confirm, bytBytes() contains: 49,0,50,0,51,0 {Length=6}
Code:
makeHash("ABC")
Public Sub makeHash(ByVal strData As String)
Dim objEncoding As UnicodeEncoding = New UnicodeEncoding()
Dim objSHA As SHA1Managed = New SHA1Managed()
Dim bytPlainPassword() As Byte = objEncoding.GetBytes(strData)
Dim hexPlainPassword As String = byteArrayToHexString(bytPlainPassword)
Dim bytHashPass1Password() As Byte = objSHA.ComputeHash(bytPlainPassword)
Dim bytHashPass2Password() As Byte = objSHA.ComputeHash(bytHashPass1Password)
Dim hexHashPass1Password As String= byteArrayToHexString(bytHashPass1Password)
Dim hexHashPass2Password As String= byteArrayToHexString(bytHashPass2Password)
Debug.Print("Pass : " & strData)
Debug.Print("Encoded: " & hexPlainPassword)
Debug.Print("Hash 1 : " & hexHashPass1Password)
Debug.Print("Hash 2 : " & hexHashPass2Password)
End Sub
This comes back with:
Code:
Pass : ABC
Encoded: 410042004300
Hash 1 : A9B1640A163865C75B3A97C7F927750297A1969A
Hash 2 : C6876C05F745140F51A200F82159463C91B2522F
Hash 2 comes back with the same hash I posted earlier:
SHA1(SHA1(A[NULL]B[NULL]C[NULL])) = C6876C05F745140F51A200F82159463C91B2522F
I noticed you posted a single pass hash which I never posted! =)
: a9b1640a163865c75b3a97c7f927750297a1969a
Oooo, what's this, I'm on a windows box?
I see it's showing the encoded password, but I was wondering if it's a step I need?
cat dict| xxd
Your command: ./oclHashcat64.bin -m 100 test -a 3 -1 null.hcchr '?u?1?u?1?u?1'
Looks very similar to my 2xSHA1 version, I wonder if it's a Windows implementation bug I've found, or I'm making a mistake elsewhere?
(07-03-2014, 08:00 AM)philsmd Wrote: [ -> ]First of all, the topic of this thread is really disgusting.
The problem at the other hand, is very easy and you should probably easy understand it (indeed here: https://hashcat.net/forum/thread-3518-po...l#pid20148 you even say that you have the code to produce it)... While Double SHA1 (and Double MD5 etc) are using the hex representation as input for the second round (i.e. sha1_hex (sha1_hex ($pass))), the algo that is used in your example is very different (i.e. sha1_hex (sha1 (encode ("UTF-16LE", $pass)))).
Note the difference between hex representation and binary represenation (=> input to second sha1_hex call)
So I don't know if you can say you beated hashcat with an algorithm that is totally different (and currently not supported).
Hope this helps to understand why the results are different
Ps. NULL bytes are no problem for *hashcat at all, but if you try some hashes that were generated w/ a very different hash algo you ofc can't recover them w/ Double SHA1
Hiyah!
> the algo that is used in your example is very different (i.e. sha1_hex (sha1 (encode ("UTF-16LE", $pass)))).
The command I used in my post should do that algorithm for the limited situation I've given. (ASCII A, B, C)
>Note the difference between hex representation and binary represenation (=> input to second sha1_hex call)
The code I've posted to Radix shows the hashing algorithm I used in detail. The hashes are SHA1(SHA1()) - it's just converted to ASCII to post here.
Radix posted that he was able to find the password - but he used a single SHA1 pass, with a hash I didn't give in my examples. =)
But - his command parameters are very similar to mine (apart from the -m 4500) so my usage appears sound.
From the commands he uses, he must be using Linux, or Unix... perhaps I'm seeing a unique bug on the Windows version?
I wanted to check my setup is correct before calling it/reporting it though.
(07-03-2014, 07:54 AM)epixoip Wrote: [ -> ]no, oclhashcat supports the full 0x00-0xff range. but i'm not sure you can get oclHashcat to read a null character from an hcchar file since getline(3) is null-terminated. (edit: actually no, it does indeed read a null character from a hcchar file just fine.)
normally if you want to use null in a custom charset, you need to use --hex-charset. you can also use $HEX[00] in a wordlist, or use --hex-wordlist.
Hi epixoip!
Thank's for your time.
I'm in work for the next 9 hours, otherwise I'd try to answer these questions myself by testing.
>normally if you want to use null in a custom charset, you need to use --hex-charset.
AH!
So my command here:
cudaHashcat64.exe -a 3 -m 4500 REAL.hash -1 ?d?u -2 NULL.hcchr ?1?2?1?2?1?2
Do I need to add in :
cudaHashcat64.exe -a 3 -m 4500
--hex-charset REAL.hash -1 ?d?u -2 NULL.hcchr ?1?2?1?2?1?2
For my tests I've been putting the ACTUAL value 0 in NULL.hcchr.
Instead, should I be using the ASCII hex representation: 00 ? (x30x30)
EDIT:
I found the answer for --hex-charset! I can use ascii hex for the charset file. Cool! =)
It prompts the question... I wonder what happened when I didn't include that switch, and the charset file contents contained the [null].. Hmmm.
--hex-charset: Tells oclHashcat-lite that our charset is given in hex
https://www.sch0.org/?blog=4&paged=5
Again, thank you - I appreciate the chance to learn lots!
you're missing the most important part, and that is the fact that the specific algorithm you are trying to crack is not supported.
-m 4500 is sha1_hex(sha1_hex(pass))
your algorithm is sha1_hex(sha1_raw(pass))
so -m 4500 will not work for what you are doing.
Seems you didn't get it.
Therefore I will explain it again with an example:
sha1_hex (sha1 ($pass)) == the one you NEED
Code:
$ echo -en "A\x00B\x00C\x00" | sha1sum # first 'iteration'
a9b1640a163865c75b3a97c7f927750297a1969a
$ echo -en "\xa9\xb1\x64\x0a\x16\x38\x65\xc7\x5b\x3a\x97\xc7\xf9\x27\x75\x02\x97\xa1\x96\x9a" | sha1sum
c6876c05f745140f51a200f82159463c91b2522f
The one -m 4500 == Double SHA1 does (double means to take the hex and apply SHA1 again, not use the binary version and use SHA1 afterwards):
Code:
$ echo -en "A\x00B\x00C\x00" | sha1sum # first 'iteration'
a9b1640a163865c75b3a97c7f927750297a1969a
$ echo -n a9b1640a163865c75b3a97c7f927750297a1969a | sha1sum
cf26c5ff00eeec70ce091fc2e6e9114b6bf16cd2
It is as I said above, a different algo (w/ different input) produces a different result.
-m 4500 uses the hex represenation, while the algo you need does not (it uses the non-ascii representation)
This algo that you need is currently not supported.
(07-03-2014, 10:29 AM)philsmd Wrote: [ -> ]Seems you didn't get it.
Therefore I will explain it again with an example:
sha1_hex (sha1 ($pass)) == the one you NEED
Code:
$ echo -en "A\x00B\x00C\x00" | sha1sum # first 'iteration'
a9b1640a163865c75b3a97c7f927750297a1969a
$ echo -en "\xa9\xb1\x64\x0a\x16\x38\x65\xc7\x5b\x3a\x97\xc7\xf9\x27\x75\x02\x97\xa1\x96\x9a" | sha1sum
c6876c05f745140f51a200f82159463c91b2522f
The one -m 4500 == Double SHA1 does (double means to take the hex and apply SHA1 again, not use the binary version and use SHA1 afterwards):
Code:
$ echo -en "A\x00B\x00C\x00" | sha1sum # first 'iteration'
a9b1640a163865c75b3a97c7f927750297a1969a
$ echo -n a9b1640a163865c75b3a97c7f927750297a1969a | sha1sum
cf26c5ff00eeec70ce091fc2e6e9114b6bf16cd2
It is as I said above, a different algo (w/ different input) produces a different result.
-m 4500 uses the hex represenation, while the algo you need does not (it uses the non-ascii representation)
This algo that you need is currently not supported.
OH!
Sorry - I understand you now. Bollocks. Woe is me.
Actually - it looks like the hashes are system use are safe .. for now. =)
Thanks again for your support, I appreciate it!