Keepass 1.x issue
#3
Hi.

That is not my hash in the kdb, i just opened a test .kdb with passphtrase "test" and created it to see if that would be picked up by hashcat, but it was the same as with my real hash, that is why i left the hash. I know hashes are not allowed but it's just a test hash so someone could compare and check because passphrase for this is "test".

I did not use the --username because this was not the username. This is just how keepass2john outputed the format. If my .kdb is named "test.kdb" when i run keepass2john.exe on it outputs it that way
test:$keepass$hash*test

I would really need to include hashes here because there are some discrepancies i noticed in jtr and not sure if it's the same for hashcat, and if i dont include the hash how can i explain the discrepancies?

To answer your questinos
1. I did not post the real hash, but a hash example that is the same format as my real hash and both are not being picked up by hashcat
2. I double checked with example hash from jtr list details and there are differences, but im not sure why is keepass2john not outputting the same format as the one in it's details and what the actual differences are since i know this keepass should be a sha256 from some other page where i quote
Quote:In order to generate the 256-bit key for the block ciphers, the Secure Hash Algorithm SHA-256 is used. This algorithm compresses the user key provided by the user (consisting of password and/or key file) to a fixed-size key of 256 bits. This transformation is one-way, i.e. it is computationally infeasible to invert the hash function or find a second message that compresses to the same hash.

The recently discovered attack against SHA-1 [2] doesn't affect the security of SHA-256. SHA-256 is still considered as being very secure [3].

Key Derivation:
If only a password is used (i.e. no key file), the password plus a 128-bit random salt are hashed using SHA-256 to form the final key (but note there is some preprocessing: Protection against Dictionary Attacks). The random salt prevents attacks that are based on pre-computed hashes.
but why is the length of the one i get from keepass2john different then the one in the example and im not even sure what keepass hash consists in the example as it consists of 2-3 sha256 length hashes.

3. Full command was just that
hashcat64 -m 13400 test.txt
Where test.txt was the has above in the above format, but i did test with the hash when test was removed (instead of test:$keepass$hash*test) i tried $keepass$hash* but that didnt work as well.

4. Here is the full output but nothing else there
Code:
D:\downloads\hashcat-3.5>hashcat64 -m 13400 test.txt
hashcat (v3.5.0) starting...

* Device #1: WARNING! Kernel exec timeout is not disabled.
            This may cause "CL_OUT_OF_RESOURCES" or related errors.
            To disable the timeout, see: https://hashcat.net/q/timeoutpatch
OpenCL Platform #1: NVIDIA Corporation
======================================
* Device #1: GeForce GTX 970, 1024/4096 MB allocatable, 13MCU

Hashfile 'test.txt' on line 1 (test:$keepass$*1*6000*0*hash*0*test): Signature unmatched
No hashes loaded.

Started: Mon Apr 17 19:45:39 2017
Stopped: Mon Apr 17 19:45:39 2017

D:\downloads\hashcat-3.5>


Problem here is that keepass2john is outputting out wrong format from the .kdb as the length is not the same as in examples, but why? I tried the python script as mentioned, it gives the same stuff keepass2john does. The .kdb are also not corrupt because, as i said i open the db normaly in keepass (the test kdb i created)


Messages In This Thread
Keepass 1.x issue - by sandokan - 04-17-2017, 08:46 PM
RE: Keepass 1.x issue - by philsmd - 04-18-2017, 09:21 AM
RE: Keepass 1.x issue - by sandokan - 04-18-2017, 10:40 AM