oclHashcat returning incorrect results - Printable Version +- hashcat Forum (https://hashcat.net/forum) +-- Forum: Deprecated; Ancient Versions (https://hashcat.net/forum/forum-46.html) +--- Forum: Very old oclHashcat Support (https://hashcat.net/forum/forum-21.html) +--- Thread: oclHashcat returning incorrect results (/thread-445.html) |
oclHashcat returning incorrect results - TheFire - 08-28-2011 I find that for sha1($salt.$pass) mode on ATI hardware, it cracks the password, but displays and saves an incorrect string (lacking the right hand characters, or a weird corrupt unicode). This only seems to happen for runs that involve a dictionary (it works fine when I use only the rules). For what it's worth, the same issue is there in the hex output. A password of "nova1" becomes 0x6e6f76e1. It's marked as cracked, but the output is not correct. Additionally, the password "peaches3" gets truncated to simply "peaches" in the output (no weird unicode or hex). A typical run looks like this: http://pastebin.com/qA26rcjG oclHashcat returns: 7436bc3103e2c79f217f60d6f9d635292fc9d2ac:91f2b:1234jkl but sha1('91f2b1234jkl') = 58d213cc1cd8b969069879700a78707f14144c46 It seems to be omitting the right hand portion from the output. This problem is present in both the 32 and 64 bit versions. It'd be really nice if we had access to the previous version while this one is broken. I didn't save a copy, and am now unable to do anything other than brute force. RE: oclHashcat returning incorrect results - atom - 08-29-2011 hello! thanks for the report, but i can not reproduce it Quote:root@sf:~/oclHashcat-0.26# cat hash RE: oclHashcat returning incorrect results - TheFire - 08-30-2011 right, but what does it find if you tell it to solve 7436bc3103e2c79f217f60d6f9d635292fc9d2ac:91f2b That's the hash it screws up on. I know it starts with 1234jkl and has a special character at the end, but it won't print that character even when it finds a solution. RE: oclHashcat returning incorrect results - mastercracker - 11-12-2011 I was able to reproduce the problem with the mode 102. I am working on Windows Vista 32 bit with 2 x HD5750. I was doing a simple dictionary attack by using a dictionary on the left side with ?1 on the right side (-1 ?s?d?u?l) and the "]" rule for the left side. Out of 107 found passwords, 10 were correct, 50 were missing the last character and most of the remainder had a weird character at the end which you have to replace by 2 chars. I will PM you my file of found passwords so that you will have the hash, salt and passwords alltogether. RE: oclHashcat returning incorrect results - atom - 11-13-2011 i will not try to reproduce oclHashcat bugs any longer since all its features are getting migrated into oclHashcat-plus RE: oclHashcat returning incorrect results - forti - 12-11-2011 Just to complete the thread with more informations about configuration. Here is my test case : Configuration: SDK_NAME="AMD-APP-SDK-v2.5-RC2-lnx64.tgz Ubuntu 11.04 i7 / 8 Go Linux BigRed 2.6.38-12-generic #51-Ubuntu SMP Wed Sep 28 14:27:32 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux 2xATI HD6990 I provide the way I computed the hash from the password in case I made this wrong. Hash was generated this way using python: import hashlib salt = '\x41\x42\x43\x44' pwd = 'Der5?d3X' h = hashlib.sha1(salt + pwd).hexdigest().upper() print h 2DC595158F9EFEE2DF8BB8CC92CD38C61B425167 hashfile contains : 2DC595158F9EFEE2DF8BB8CC92CD38C61B425167:41424344 Command executed : ./oclHashcat64.bin --outfile-format=2 -m 102 --hex-salt ../hashfile -1 '?l?d?u?s' 'De?1?1?1' '?1?1?1' oclHashcat v0.26 by atom starting... Digests: 1 entries, 1 unique Salts: 1 entries, 1 unique Bitmaps: 8 bits, 256 entries, 0x000000ff mask, 1024 bytes Platform: AMD compatible platform found Watchdog: Temperature limit set to 90c Device #1: Cayman, 1024MB, 0Mhz, 24MCU Device #2: Cayman, 1024MB, 0Mhz, 24MCU Device #3: Cayman, 1024MB, 0Mhz, 24MCU Device #4: Cayman, 1024MB, 0Mhz, 24MCU NOTE: gpu-accel auto-adjusted to: 32 Device #1: Kernel ./kernels/4098/m0102.Cayman.64.kernel Device #2: Kernel ./kernels/4098/m0102.Cayman.64.kernel Device #3: Kernel ./kernels/4098/m0102.Cayman.64.kernel Device #4: Kernel ./kernels/4098/m0102.Cayman.64.kernel [s]tatus [p]ause [r]esume [q]uit => s Status.......: Running Hash.Type....: sha1($salt.$pass) Mode.Left....: Mask 'De?1?1?1' (857375) Mode.Right...: Mask '?1?1?1' (857375) Speed.GPU*...: 1160.1M/s Recovered....: 0/1 Digests, 0/1 Salts Progress.....: 569520881664/735091890625 (77.48%) Running......: 8 mins, 17 secs Estimated....: 2 mins, 22 secs HW.Monitor.#1: 24% GPU, 82c Temp HW.Monitor.#2: 24% GPU, 83c Temp HW.Monitor.#3: 24% GPU, 71c Temp HW.Monitor.#4: 24% GPU, 71c Temp 2dc595158f9efee2df8bb8cc92cd38c61b425167:41424344er5?X:446572353f580000 [s]tatus [p]ause [r]esume [q]uit => Status.......: Cracked Hash.Type....: sha1($salt.$pass) Mode.Left....: Mask 'De?1?1?1' (857375) Mode.Right...: Mask '?1?1?1' (857375) Speed.GPU*...: 1174.1M/s Recovered....: 1/1 Digests, 1/1 Salts Progress.....: 610918662144/735091890625 (83.11%) Running......: 8 mins, 53 secs Estimated....: 1 min, 45 secs HW.Monitor.#1: 22% GPU, 82c Temp HW.Monitor.#2: 21% GPU, 83c Temp HW.Monitor.#3: 21% GPU, 72c Temp HW.Monitor.#4: 21% GPU, 71c Temp Started: Sat Dec 10 22:49:23 2011 Stopped: Sat Dec 10 22:58:17 2011 The bug was quite reproductible using differents masks and passwords/hash combination It seems also to depends on the length of the mask used. |