hi there,
so not ones ppl are dealing to crack slow hashs or have to deal with big hash list .
to me it happen more than ones.
and this is a pin in the butt if u want to crack hashs which have not much keyspace such as ?d?d?d?d or ?d?d?d?d?d?d and so on.
most of the time hashcat will optimize the gpus for it to work as it base.
however, some time hashcat dont make use of all ur hardware , for example if hashcat "thinks" its a small keyspace for 8 gpus and for this hash (slow\fast hash), it wont use 8 of ur gpus, since it does not to consider how many hash candidate there is and does not make the use of all gpus.
so on my journey to find out a way to use all gpus to optimize all of ur hardware i acounter some bugs?
my initial idea is trying to supply more work to my 8 gpus by manually carving up the keyspace for the attack and running 8 separate hashcat jobs, one for each GPU.
^
by that i mean to take a certain keyspace and split it to 8,
maybe by doing skip/limit between the gpus will make them work togther.
in my example when i ran ?d?d?d?d?d?d on a 2.3~mil+ hash candidates only 1 gpu was used and the others did not, which is a shame. because hashcat "thinks" its a small number to cover. (which is ! if u have only one candidate.)
however in the proccess of trying my idea i came to a weird bug.
remember what i want is to split manualy the workload by skip/limit to give each gpu a job .
in attack one, i havent use any skip limit, this is just showing that only 1 gpu is working and it took around 40min+- to complete this simple job. if 8 gpus was working on the same job it would be 1/8 of time time that it took me (5min~ instead of 40~)
in attack 2 and 3 i decide to put my idea to the test.
as u can see i have put skip/limit to make it easier.
funny fact is, by giving the work to one gpu only , it show a less cracking hashrate.
first attack less keyspace. less hashrate , only one gpu , take less time.
second and third attack, are splited work. , less hashrate per gpu, less keyspace , take more\same time as one gpu on first attack would.
anyhow my idea failed perhaps because of an hashcat bug.
but maybe by spliting the workload between the gpus for the same job with skip/limit within the same job all gpus will be used.
i've read the FAQ , and i understand that when gpus are not "working" that mean they dont have enough work to work on
i know that by when appending some stuff like rules etc.. that mean i must skip what i want to find, for example i want to find x6 ?d if i append something to create "more work" that mean gota skip this x6 ?d ..
mp64 ?d?d?d?d?d?d | hashcat .... was the same result.
so not ones ppl are dealing to crack slow hashs or have to deal with big hash list .
to me it happen more than ones.
and this is a pin in the butt if u want to crack hashs which have not much keyspace such as ?d?d?d?d or ?d?d?d?d?d?d and so on.
most of the time hashcat will optimize the gpus for it to work as it base.
however, some time hashcat dont make use of all ur hardware , for example if hashcat "thinks" its a small keyspace for 8 gpus and for this hash (slow\fast hash), it wont use 8 of ur gpus, since it does not to consider how many hash candidate there is and does not make the use of all gpus.
so on my journey to find out a way to use all gpus to optimize all of ur hardware i acounter some bugs?
my initial idea is trying to supply more work to my 8 gpus by manually carving up the keyspace for the attack and running 8 separate hashcat jobs, one for each GPU.
^
by that i mean to take a certain keyspace and split it to 8,
maybe by doing skip/limit between the gpus will make them work togther.
in my example when i ran ?d?d?d?d?d?d on a 2.3~mil+ hash candidates only 1 gpu was used and the others did not, which is a shame. because hashcat "thinks" its a small number to cover. (which is ! if u have only one candidate.)
however in the proccess of trying my idea i came to a weird bug.
remember what i want is to split manualy the workload by skip/limit to give each gpu a job .
in attack one, i havent use any skip limit, this is just showing that only 1 gpu is working and it took around 40min+- to complete this simple job. if 8 gpus was working on the same job it would be 1/8 of time time that it took me (5min~ instead of 40~)
in attack 2 and 3 i decide to put my idea to the test.
as u can see i have put skip/limit to make it easier.
Code:
attack one.
hashcat64.exe -m 2711 -a 3 "t1m3l1n3 .left7" -o "t1m3l1n3.out" --session t1m3l1n3 -w 4 -1 ?l?u?d!@#$ -i --increment-min=6 ?d?d?d?d?d?d -O --remove
Session..........: t1m3l1n3
Status...........: Running
Hash.Type........: vBulletin >= v3.8.5
Hash.Target......: t1m3l1n3 .left7
Time.Started.....: Sat Jul 07 17:47:24 2018 (39 mins, 0 secs)
Time.Estimated...: Sat Jul 07 18:29:22 2018 (2 mins, 58 secs)
Guess.Mask.......: ?d?d?d?d?d?d [6]
Guess.Charset....: -1 ?l?u?d!@#$, -2 Undefined, -3 Undefined, -4 Undefined
Guess.Queue......: 1/7 (14.29%)
Speed.Dev.#1.....: 919.0 MH/s (0.59ms) @ Accel:64 Loops:100 Thr:1024 Vec:2
Speed.Dev.#2.....: 0 H/s (0.00ms) @ Accel:64 Loops:100 Thr:1024 Vec:2
Speed.Dev.#3.....: 0 H/s (0.00ms) @ Accel:64 Loops:100 Thr:1024 Vec:2
Speed.Dev.#4.....: 0 H/s (0.00ms) @ Accel:64 Loops:100 Thr:1024 Vec:2
Speed.Dev.#5.....: 0 H/s (0.00ms) @ Accel:64 Loops:100 Thr:1024 Vec:2
Speed.Dev.#6.....: 0 H/s (0.00ms) @ Accel:64 Loops:100 Thr:1024 Vec:2
Speed.Dev.#7.....: 0 H/s (0.00ms) @ Accel:64 Loops:100 Thr:1024 Vec:2
Speed.Dev.#8.....: 0 H/s (0.00ms) @ Accel:64 Loops:100 Thr:1024 Vec:2
Speed.Dev.#*.....: 922.2 MH/s
Recovered........: 18461/2435603 (0.76%) Digests, 18461/2435561 (0.76%) Salts
Recovered/Time...: CUR:517,N/A,N/A AVG:427,25647,615551 (Min,Hour,Day)
Progress.........: 2271729000000/2435561000000 (93.27%)
Rejected.........: 0/2271729000000 (0.00%)
Restore.Point....: 0/10000 (0.00%)
Candidates.#1....: 120123 -> 688373
Candidates.#2....: [Generating]
Candidates.#3....: [Generating]
Candidates.#4....: [Generating]
Candidates.#5....: [Generating]
Candidates.#6....: [Generating]
Candidates.#7....: [Generating]
Candidates.#8....: [Generating]
HWMon.Dev.#1.....: Temp: 48c Fan: 90% Util: 57% Core:1885MHz Mem:4811MHz Bus:16
HWMon.Dev.#2.....: Temp: 32c Fan: 90% Util: 0% Core: 139MHz Mem: 405MHz Bus:16
HWMon.Dev.#3.....: Temp: 26c Fan: 90% Util: 0% Core: 139MHz Mem: 405MHz Bus:16
HWMon.Dev.#4.....: Temp: 28c Fan: 90% Util: 0% Core: 139MHz Mem: 405MHz Bus:16
HWMon.Dev.#5.....: Temp: 30c Fan: 90% Util: 0% Core: 139MHz Mem: 405MHz Bus:16
HWMon.Dev.#6.....: Temp: 30c Fan: 90% Util: 0% Core: 139MHz Mem: 405MHz Bus:16
HWMon.Dev.#7.....: Temp: 31c Fan: 90% Util: 0% Core: 139MHz Mem: 405MHz Bus:16
HWMon.Dev.#8.....: Temp: 27c Fan: 90% Util: 0% Core: 139MHz Mem: 405MHz Bus:16
attack 2
hashcat64.exe -m 2711 -a 3 "t1m3l1n3 .left7" -o "t1m3l1n3.out" --session t1m3l1n3 -w 4 -1 ?l?u?d!@#$ -i --increment-min=6 ?d?d?d?d?d?d -O --remove -d1 -l 1250
Session..........: t1m3l1n3
Status...........: Quit
Hash.Type........: vBulletin >= v3.8.5
Hash.Target......: t1m3l1n3 .left7
Time.Started.....: Sat Jul 07 20:02:06 2018 (2 mins, 17 secs)
Time.Estimated...: Sat Jul 07 20:34:37 2018 (30 mins, 14 secs)
Guess.Mask.......: ?d?d?d?d?d?d [6]
Guess.Charset....: -1 ?l?u?d!@#$, -2 Undefined, -3 Undefined, -4 Undefined
Guess.Queue......: 1/1 (100.00%)
Speed.Dev.#1.....: 154.8 MH/s (0.46ms) @ Accel:64 Loops:100 Thr:1024 Vec:2
Recovered........: 1/2415740 (0.00%) Digests, 1/2415698 (0.00%) Salts
Recovered/Time...: CUR:0,N/A,N/A AVG:0,0,0 (Min,Hour,Day)
Progress.........: 21043375000/301962250000 (6.97%)
Rejected.........: 0/21043375000 (0.00%)
Restore.Point....: 0/10000 (0.00%)
Candidates.#1....: 120123 -> 688220
HWMon.Dev.#1.....: Temp: 42c Fan: 90% Util: 34% Core:1885MHz Mem:4811MHz Bus:16
attack 3
Session..........: t1m3l1n31
Status...........: Quit
Hash.Type........: vBulletin >= v3.8.5
Hash.Target......: t1m3l1n3 .left7
Time.Started.....: Sat Jul 07 20:02:09 2018 (2 mins, 12 secs)
Time.Estimated...: Sat Jul 07 20:34:41 2018 (30 mins, 20 secs)
Guess.Mask.......: ?d?d?d?d?d?d [6]
Guess.Charset....: -1 ?l?u?d!@#$, -2 Undefined, -3 Undefined, -4 Undefined
Guess.Queue......: 1/1 (100.00%)
Speed.Dev.#2.....: 309.4 MH/s (0.46ms) @ Accel:64 Loops:100 Thr:1024 Vec:2
Recovered........: 1/2415740 (0.00%) Digests, 1/2415698 (0.00%) Salts
Recovered/Time...: CUR:0,N/A,N/A AVG:0,0,0 (Min,Hour,Day)
Progress.........: 342634250000/905886750000 (37.82%)
Rejected.........: 0/342634250000 (0.00%)
Restore.Point....: 1250/10000 (12.50%)
Candidates.#2....: 120301 -> 688242
HWMon.Dev.#2.....: Temp: 47c Fan: 90% Util: 60% Core:1885MHz Mem:4811MHz Bus:16
funny fact is, by giving the work to one gpu only , it show a less cracking hashrate.
first attack less keyspace. less hashrate , only one gpu , take less time.
second and third attack, are splited work. , less hashrate per gpu, less keyspace , take more\same time as one gpu on first attack would.
anyhow my idea failed perhaps because of an hashcat bug.
but maybe by spliting the workload between the gpus for the same job with skip/limit within the same job all gpus will be used.
i've read the FAQ , and i understand that when gpus are not "working" that mean they dont have enough work to work on
i know that by when appending some stuff like rules etc.. that mean i must skip what i want to find, for example i want to find x6 ?d if i append something to create "more work" that mean gota skip this x6 ?d ..
mp64 ?d?d?d?d?d?d | hashcat .... was the same result.