distributed cracking: relation between -s/-l value and Restore.Point value when cracked

[ytbe.use3]

This question is also within the most frequently asked questions (wiki page): https://hashcat.net/faq#what_is_a_keyspace

Can you explain what does base loop mask and mod loop mask mean? I am not able to understand it. I have similar use case of @jason that I need to distribute the masked workload across different computers. Also, I have the same question as pointed in the below link, load is not being properly distributed 
https://hashcat.net/forum/thread-6447-po...l#pid34362

My situation: I need to distribute the load of a hash with "?l?l?l?l?l?l" and I did some testing locally before doing in distributed setup. Below are my observations (I know my password is: liminj and Im just doing some testing)

First,
1. I tried with no -s / -l flags and result as is attache in 1.png. As you can see that the restore point says 159744 (which I am assuming that it checked for 159744 combinations and then found the password).

2. So, what I did next was keeping flags -s 0 -l 150000 and as expected result was as attached in 2.png (keyspace was exhausted as I have given a number less than 159744 which I found in step 1). I also tried giving -s 160000 -l 10000, and it failed for the same explanation

3. Next, I tried with -s 150000 -l 10000 (as in 3.png) and Im now expecting it to crack the hash as initially it was able to find it at 159744 which s between 150000 and 150000+10000= 160000 but it still says keyspace is exhausted.

Why is it happening? and where am I understanding it wrong?

4. With the same system setup etc. I tried with as 4.png , it cracked it well. Again, why? 

5. Next, for the same password hash I gave as attached in 5.png (-s 160000 and no -l, which I am assuming that the tool would start cracking the hashes from 160000 which should not involve 159744 where we earlier found the password). I am expecting to not get the hash cracked as it is searching 160000+ and our 159744 is less than that but it found the password. Why? Is it searching for 0-160000? instead of 160000+?

[philsmd]

You shouldn't make this type of connection between -s/-l value and the value you see at the time the hashes were cracked in the Restore.Point line (there are additional features that might influence it... like markov etc!, you could try with --markov-disable).

Please use --outfile-format 11 up to --outfile-format 15 to see the exact crack position.

To sum up, you shouldn't really worry about which node cracks the hashes etc, there might be further factors that influence it a little bit.

[ytbe.use3]

You shouldn't make this type of connection between -s/-l value and the value you see at the time the hashes were cracked in the Restore.Point line (there are additional features that might influence it... like markov etc!, you could try with --markov-disable).

Please use --outfile-format 11 up to --outfile-format 15 to see the exact crack position.

To sum up, you shouldn't really worry about which node cracks the hashes etc, there might be further factors that influence it a little bit.

Sure. So, you say that, dividing as you described here https://hashcat.net/forum/thread-6448-po...l#pid34346 will make sure that only one of the nodes cracks the password. Right?

Also, I am assuming that the keyspace can be divided unequally with the same example you described in the above link (off course, without overlapping keyspace). Please let me know if this can cause some issues. For ex: 

hashcat -m 0 -a 3 --skip        0 --limit 16290126 hash_file.txt ?a?a?a?a?a?a?a  (Assigned twice load)
hashcat -m 0 -a 3 --skip 16290126 --limit 8145063  hash_file.txt ?a?a?a?a?a?a?a
hashcat -m 0 -a 3 --skip 24435189 --limit 8145063  hash_file.txt ?a?a?a?a?a?a?a
hashcat -m 0 -a 3 --skip 32580252 --limit 8145063  hash_file.txt ?a?a?a?a?a?a?a
hashcat -m 0 -a 3 --skip 40725315 --limit 8145063  hash_file.txt ?a?a?a?a?a?a?a
hashcat -m 0 -a 3 --skip 48870378 --limit 8145063  hash_file.txt ?a?a?a?a?a?a?a
hashcat -m 0 -a 3 --skip 57015441 --limit 8145063  hash_file.txt ?a?a?a?a?a?a?a
hashcat -m 0 -a 3 --skip 65160504                  hash_file.txt ?a?a?a?a?a?a?a (Assigned all remaining load)

[atom]

Sure. So, you say that, dividing as you described here https://hashcat.net/forum/thread-6448-po...l#pid34346 will make sure that only one of the nodes cracks the password. Right?

Yes, but only if the password matches the mask.

[ytbe.use3]

Sure. So, you say that, dividing as you described here https://hashcat.net/forum/thread-6448-po...l#pid34346 will make sure that only one of the nodes cracks the password. Right?

Yes, but only if the password matches the mask.

Thank you. Got it! Also, is my assumption about dividing the keyspace unevenly which also makes sure that the password is cracked by only one node true? (off course, again if password matches mask). 

Sorry if I am being over cautious, as I do not know how internal implementations are done and wanted to make sure before I use it within my project.

[atom]

There's no problem dividing the keyspace unevenly. In fact, I wouldn't even do it that way. It's just a nice way to explain the system to new users. For advanced -l calculation you'd use --progress-only to find out the ideal -l size.

[ytbe.use3]

There's no problem dividing the keyspace unevenly. In fact, I wouldn't even do it that way. It's just a nice way to explain the system to new users. For advanced -l calculation you'd use --progress-only to find out the ideal -l size.

Sounds good. I will look more into that flag. Do you have some links / resources where this is demonstrated with examples?