OK, but it's easier if it supports the 32 hex hashes as well as 16, not like its hard to do as all it need to do it split the 32 hex hash into 2 x 16 hex hashes.
I'll just have 2 write a script 2 do it.
(09-06-2012, 02:39 AM)M@LIK Wrote: [ -> ]-m3000(FAGGOT!): -a0 fails to crack len_6 passwords unless it's piped using echo -n and not a dict. -a1, -a7 appends a char if the pass was len_7, See details here.
OK, fixed with RC3, thanks!
(09-06-2012, 02:39 AM)M@LIK Wrote: [ -> ]-m131: Fails to crack any password containing lowercase char in it, all attack-modes, all lengths.
That is because all input into oclHashcat-plus for mode -m 131 (and -m 3000 and -m 3100 as well) is converted into uppercase because these systems do not support passwords in lower case. Why should oclHashcat-plus try them? Maybe your hash generator did generate hashes based on lowercase input, which is wrong.
(09-06-2012, 02:39 AM)M@LIK Wrote: [ -> ]This bug seems to be present in previous versions as well, but I didn't notice it for some reason. I changed all my plains\hashes now.
- It would much nicer if hashes of algos related to strtolower (-m1100, -m2100 and -m121) does NOT get lowered by force in left list and output. In other words, keeping the username's case as it is.
Thats right, I agree, but its not easy to fix. In theory this would require to keep a copy of the original string to each salt which would increase the required memory again. Additionally, the salt structure for the host and gpu are the same, so this data would be required to be copied to the GPU as well even its totally useless on there. So yeah, it would work but its a lot of effort. Is that really required? I dont think so.
(09-06-2012, 02:39 AM)M@LIK Wrote: [ -> ]Other:
- Nothing was done about my previous report.
- If -i is not set, the mask will start AND stop at the first place-holder.
Code:
e6d96502596d7e7887b76646c5f615d9:car
hc64p -a3 --force e6d96502596d7e7887b76646c5f615d9 ?l?l?l
Status.......: Exhausted
Input.Mode...: Mask (?l)
...
Fixed with RC3 - thanks!
(09-06-2012, 09:58 AM)blandyuk Wrote: [ -> ]OK, but it's easier if it supports the 32 hex hashes as well as 16, not like its hard to do as all it need to do it split the 32 hex hash into 2 x 16 hex hashes.
I'll just have 2 write a script 2 do it.
Yeah, its annoying. Its not the splitting, its the merging. For example there is --show, --left, the outfile - which can have 8 different formats! to either stdout or/and to outfile and the remove option.
Fantastic! Thanks to you!
atom Wrote: [ -> ]That is because all input into oclHashcat-plus for mode -m 131 (and -m 3000 and -m 3100 as well) is converted into uppercase because these systems do not support passwords in lower case. Why should oclHashcat-plus try them? Maybe your hash generator did generate hashes based on lowercase input, which is wrong.
Ah, I see. Looks like I need to fix some bugs myself. Thanks for the info!
atom Wrote: [ -> ]Thats right, I agree, but its not easy to fix. In theory this would require to keep a copy of the original string to each salt which would increase the required memory again. Additionally, the salt structure for the host and gpu are the same, so this data would be required to be copied to the GPU as well even its totally useless on there. So yeah, it would work but its a lot of effort. Is that really required? I dont think so.
Yea, I can imagine all this. And no, it's not that important.
Reporting back:
- Great! --outfile-format=4 works fine now.
- Masks are working like a charm. -i switch is lovely too, will use that some day.
-m131: Working flawlessly after generating correct hashes. (Sorry!)
- -m3000: Finally! -a1, -a6 and -a7 are no longer giving wrong cracks, hopefully. BUT It annoys me that -a0 still does NOT crack 6_len passes. (EXCEPT with echo -n)
- .\docs\user_manuals.txt, line_3: "currently oudated" ou... What? xD