Finding some weird features (rules)
#1
I'm finding some weird features when trying to optimize the rules.

Take 1b34b9287ad35d9ec421b26fd3ad9456:RAGNAROK for example.

The word ragnarok is in the dictionnary but not ragnarok1.
I tested the following rules to see if they find the RAGNAROK

Code:
u      - yes
@1u    - no
^1@1u  - yes
$1@1u  - no
i81@1u - yes

It seems that u is not processed if @1 can't find a 1. If you add the 1 at the beginning with ^1, @1 is happy, if you do it at the end with $1 it isn't. If you add it at the end with i81, @1 is happy again.

It seems as if some rules have precedence of other. Maybe because they are applied in a fixed order? Is this wanted, and if yes, is this order documented ?
#2
there is something wrong with your test, because $1@1u should find it. you sure you tried it correct? here is my log on which you will see its found:

Quote:root@sf:~/hashcat-0.40# cat > hash
1b34b9287ad35d9ec421b26fd3ad9456
root@sf:~/hashcat-0.40# cat > word
ragnarok
root@sf:~/hashcat-0.40# ./hashcat-cli64.bin --quiet hash word
root@sf:~/hashcat-0.40# echo u > rule
root@sf:~/hashcat-0.40# ./hashcat-cli64.bin --quiet hash word -r rule
1b34b9287ad35d9ec421b26fd3ad9456:RAGNAROK
root@sf:~/hashcat-0.40# echo @1u > rule
root@sf:~/hashcat-0.40# ./hashcat-cli64.bin --quiet hash word -r rule
root@sf:~/hashcat-0.40# echo ^1@1u > rule
root@sf:~/hashcat-0.40# ./hashcat-cli64.bin --quiet hash word -r rule
1b34b9287ad35d9ec421b26fd3ad9456:RAGNAROK
root@sf:~/hashcat-0.40# echo '$1@1u' > rule
root@sf:~/hashcat-0.40# ./hashcat-cli64.bin --quiet hash word -r rule
1b34b9287ad35d9ec421b26fd3ad9456:RAGNAROK
root@sf:~/hashcat-0.40# echo 'i81@1u' > rule
root@sf:~/hashcat-0.40# ./hashcat-cli64.bin --quiet hash word -r rule
1b34b9287ad35d9ec421b26fd3ad9456:RAGNAROK

rules are executed from left to right. if some function return bad result, the rule rejects and hashcat does not try to crack it. thats why @1u can not find it, because @1 does not hit anything, so it rejects.
#3
on the other hand, "$1@1u" works fine for me and it seems it works as well for atom.
#4
of course it does. didnt i say that? Smile
#5
(03-31-2012, 12:10 AM)frekvent Wrote: take the rules i42@2 and @2. They should be identical but they're not. When I test them separately against the phpbb hashes, i42@2 gives me 7520 hits but @2 gives me only 264.

i believe i42@2 would add 2 in the 4th position and delete it:: like
password2 >w/ i42@2> pass2word2 >then> password
@2 would::
password2 >w/ @2> password
directly..
same with $1@1u - u

i really cant find any difference between them.. can u explain with examples plz?? : )
#6
i42@2 <- it was just obfuscation
#7
(03-31-2012, 12:34 AM)atom Wrote: i42@2 <- it was just obfuscation

ok.. but how can u explain this..

frekvent Wrote:i42@2 gives me 7520 hits but @2 gives me only 264.
#8
because it will reject all words that do not contain the char "2".
#9
(03-31-2012, 12:52 AM)atom Wrote: because it will reject all words that do not contain the char "2".

nice..
after making two rulez files::
r1.rule
Code:
:
i42@2
r2.rule
Code:
:
@2
run them with hash and dict
they both gave exact same number of cracked hashes.. so it was about rejection
THANKs atom
#10
I find another possible weirdness. I'm trying to understand why the rules "x24" and "x42" are different. "x24" gives me 569 hits and "x42" gives me 336 hits when I run them against the phpbb hashes. I understand that the rules won't work with words shorter than four characters. Are the indices different when you delete from 4 to 2 compared to when you delete from 2 to 4?