What's wrong with AMD & RAR3-HP

[Lithium]

Hi, there!
My system:
i5-4590, 8gb RAM, 2x R9 380, i have installed windows 10 (Radeon Software Version 16.12.2) and Ubuntu 14.04 (Radeon Crimson 15.12 drivers) now.
A day ago i tried to test my own tests for R9 380, Quadro K6000 and GTX1080 with cracking some types of hashes.
When i saw it i was very confusing with results of RAR3-Hp. Similar problem posted here: Rx 480 Fails , but i have old and known R9 380s.
My results with benchmark for -m 12500 on Windows is: Quadro K6000: 7700  h/s, GTX1080:  29600 h/s, R9 380x2: 4630 kh/s, results on Ubuntu i got only for R9x380: 36150 h/s
I can't believe, that changing OS may improve performance with one type of hashes at thousand times, so i created test archive with RAR3-HP and password 123aA, got hash using rar2john, and start test @Ubuntu. Password was found after few hours, then i copy command-line to file, delete potfile and started test again, now on Windows 10.
My commandline is:
hashcat64.exe -a 3 -m 12500 -i --increment-min 5 --increment-max 5 -1 ?d?u?l d:\cat1-123.txt ?1?1?1?1?1?1?1?1
(d:\cat1-123.txt contains hash string: $RAR3$*0*b14426c0cf7c919a*e2efc1a653fae0b5999818f79f1ff014)
Hashcat ran for few minutes then exit without password found.

Is there any differences in .exe and .bin? Or something wrong with windows version?
Tested on hashcat-3.30, 3.10.

[Lithium]

Oh, and yes - stdout file formed under Windows 10 has 624 817 152 bytes long and doesn't contain desired password, but file from ubuntu contains and it's 5 496 796 992 bytes long.

[atom]

Please try to reproduce with latest beta (88) and report back

[Lithium]

It looks like problem still exists.
Yes, stdout forms file bigger than from Ubuntu version, but started with hash hashcat can't find password.

[philsmd]

I tested this with win 10 and GnuWin32's wc command.
The differences between linux and windows are the following.
Linux:

Code:

./hashcat -a 3 --stdout -i --increment-min 5 --increment-max 5 -1 ?d?u?l ?1?1?1?1?1?1?1?1 | wc
916132832 916132832 5496796992

windows:

Code:

hashcat64.exe -a 3 --stdout -i --increment-min 5 --increment-max 5 -1 ?d?u?l ?1?1?1?1?1?1?1?1 | wc
916132832 916132832 6412929824

The line counts are exactly the same, what changes are the total bytes in the output: but the explanation is very simple, hashcat uses "\r\n" (carriage return and new line) for windows because otherwise (with only "\n") some windows users claim that "there is only a single line in this file).

That means that 6412929824 / (5 + 2) is the same as 5496796992 / (5 + 1) and the result is both of the times 916132832 (the expected line count, which can be calculated also by (26+26+10) ^ 5 , total charset to the power of the password length).

So we can't make any conclusion by just seeing a difference in bytes in the output (even though what makes me wondering is why you get 624817152 bytes in the output).

[Lithium]

philsmd, i thought in the same way and thank you for giving good explanation.

But problem exists, and it looks very strange after test with 88 build. I have 3 stdout files: from Win-hashcat3.30, Win-hashcat3.30-88 and ubuntu-hashcat3.30. Password that i searching for exists in stdout of '88'-version, but hashcat fails.

Code:

$ cat cat1-123_win_std-88.out | grep "123aA"
123aA
$ cat cat1-123_win_std.out | grep "123aA"
$ cat cat1-123_ub_std.out | grep "123aA"
123aA

[Lithium]

Tested 155 build under ubuntu 16.04 and amdgpu-pro-16.60-379184 (with --force), and i'm really discouraged...
It can't find combination for hash now under ubuntu same as under windows

Code:

./hashcat64.bin -a 3 -m 12500 --force -i --increment-min 5 --increment-max 5 -1 ?d?l?u cat1-123.txt ?1?1?1?1?1?1?1?1?1?1

hashcat (v3.30-155-g8743d75) starting...
/sys/bus/pci/devices/0000:01:00.0/pp_dpm_pcie: No such file or directory
/sys/bus/pci/devices/0000:01:00.0/pp_dpm_sclk: No such file or directory
/sys/bus/pci/devices/0000:01:00.0/pp_dpm_mclk: No such file or directory
/sys/bus/pci/devices/0000:06:00.0/pp_dpm_pcie: No such file or directory
/sys/bus/pci/devices/0000:06:00.0/pp_dpm_sclk: No such file or directory
/sys/bus/pci/devices/0000:06:00.0/pp_dpm_mclk: No such file or directory

OpenCL Platform #1: Advanced Micro Devices, Inc.
================================================
* Device #1: Tonga, 1764/1936 MB allocatable, 28MCU
* Device #2: Tonga, 1802/2037 MB allocatable, 28MCU
* Device #3: Intel(R) Core(TM) i5-4590 CPU @ 3.30GHz, skipped

Hashes: 1 digests; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates

Applicable Optimizers:
* Zero-Byte
* Single-Hash
* Single-Salt
* Brute-Force

Watchdog: Temperature abort trigger set to 90c
Watchdog: Temperature retain trigger set to 75c

Cracking performance lower than expected? Append -w 3 to the commandline!

INFO: approaching final keyspace, workload adjusted      

Session..........: hashcat                                
Status...........: Exhausted
Hash.Type........: RAR3-hp
Hash.Target......: $RAR3$*0*b14426c0cf7c919a*e2efc1a653fae0b5999818f79f1ff014
Time.Started.....: Mon Feb 13 09:43:31 2017 (5 mins, 3 secs)
Time.Estimated...: Mon Feb 13 09:48:34 2017 (0 secs)
Input.Mask.......: ?1?1?1?1?1 [5]
Input.Charset....: -1 ?d?l?u, -2 Undefined, -3 Undefined, -4 Undefined
Input.Queue......: 1/1 (100.00%)
Speed.Dev.#1.....:  5970.0 kH/s (3.62ms)
Speed.Dev.#2.....:   185.1 kH/s (11.23ms)
Speed.Dev.#*.....:  6155.1 kH/s
Recovered........: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.........: 916132832/916132832 (100.00%)
Rejected.........: 0/916132832 (0.00%)
Restore.Point....: 1835008/14776336 (12.42%)
Candidates.#1....: XypOx -> XXvZv
Candidates.#2....: XkIes -> XW5E1
HWMon.Dev.#1.....: Temp: 54c Fan: 16%
HWMon.Dev.#2.....: Temp: 54c Fan: 16%

Started: Mon Feb 13 09:43:28 2017
Stopped: Mon Feb 13 09:48:35 2017

[atom]

This is another episode of the great AMD OpenCL runtime! I've just tested it locally with my NV GTX1080 and AMD RX480 with the same hashcat version (v3.30-157):

NV:

$RAR3$*0*b14426c0cf7c919a*e2efc1a653fae0b5999818f79f1ff014:123aA
                                                         
Session..........: hashcat
Status...........: Cracked
Hash.Type........: RAR3-hp

AMD

Session..........: hashcat                                
Status...........: Exhausted
Hash.Type........: RAR3-hp

And just to verify it's not some code related problem, I've tested with Intel as well and it worked:

$RAR3$*0*b14426c0cf7c919a*e2efc1a653fae0b5999818f79f1ff014:123aA
                                                          
Session..........: hashcat
Status...........: Cracked
Hash.Type........: RAR3-hp

The problem with AMD (and NV, too) is that they don't care much about OpenCL as this is a nieche product that is not used by many customer. If we report bugs they will stay open forever, that's why we stopped reporting them. We can try to find a workaround for the problem, usually for the price of the performance drop, but finding such a workaround isn't guaranteed, too.

[atom]

I've found a workaround using a volatile variable, but I can't say how much it dropped the performance because the value before was wrong because of that OpenCL runtime error. Anyway, it should work on AMD now, too. You can download the binary beta here: https://hashcat.net/beta/ or build from sources

[Lithium]

Thanks a lot! Yes, these builds found test password under both OpSystems (in windows i tested 160 build, in ubuntu - 158).