oclHashcat-plus 0.15b3 vs hashcat 0.45b1
#1
Experienced a situation, several times, when using a large md5 hash
list and run with oclHascat-plus 0.15b3 with best64.rule.
Then run the same simple command line again. No result should be
expected, I guess, but I got once a new, not duplicated, result !
Why wasn't found at the first run ? Don't know.

Then use this same hash file, after using oclHascat, with less hashes,
obviously, and using the same best64.rule with hashcat, I was expecting
to get only passwords above 16 characters, but no, I also get lower than
16, even with 6 characters simple lower-numeric.

Anyone else experienced this ? It's normal to happen this ?
Might this be the reason: "oclHashcat does not perform all the iterations involved in the algorithm and skips a few."

A note yet to know why the docs where what's new from one version to
a another, in hashcat, nothing is there about changes from 0.44 to 0.45...
#2
good input.

the first one might be a bug, but i can not reproduce it. can you give me some commandline examples please?

2nd one might be because oclhashcat works a lot different internal with its memory handling in rules than hashcat. for example oclhashcat-plus does have only a 16 byte temporary buffer and does not skip once a not matching rule is applied. for example, if the input word has the length 9 and you use the double rule it gets length 18 last 2 byte not are missing in oclhashcat. in hashcat that would not happend. now if another rule is aplied that would remove lets say the first 4 characters, then the length becomes length 15 so its "ok", however, in oclhashcat the 2 byte got missing ffrom the first so the length in oclhashcat-plus will be length 11 Smile

about the changes in 0.45 its strange i see something:


type: feature
file: hashcat-cli
desc: dropped predefined charsets ?h, ?F, ?G and ?R
trac: #55

type: feature
file: hashcat-cli
desc: added a collection of language-specific charset-files for use with masks
trac: #55

type: bug
file: hashcat-cli
desc: fixed a null-pointer dereference that can lead to a segmentation fault
trac: #104
#3
I'll try to replicate the situation and back with results: command line used, file and results.
May take a while.

About the changes... maybe I downloaded the file too soon ? I have to download it
again and see if the text is now there (thanks).
#4
(03-31-2013, 12:34 PM)atom Wrote: 2nd one might be because oclhashcat works a lot different internal with its memory handling in rules than hashcat. for example oclhashcat-plus does have only a 16 byte temporary buffer and does not skip once a not matching rule is applied. for example, if the input word has the length 9 and you use the double rule it gets length 18 last 2 byte not are missing in oclhashcat. in hashcat that would not happend. now if another rule is aplied that would remove lets say the first 4 characters, then the length becomes length 15 so its "ok", however, in oclhashcat the 2 byte got missing ffrom the first so the length in oclhashcat-plus will be length 11 Smile

That makes sense and I think I understand that Smile hey there has to be a first time Big Grin

I am trying to word this next bit very carefully, as I don't want to sound ungrateful or critical.

I am noticing more and more problems, both with things I would like to do personally and things others are experiencing independently which seem to be coming down to the password length restrictions in oclhashcat.

Like I say, I am massively grateful for oclhashcat and I do not pretend to understand the difficulties in writing such software. Just speaking purely as a humble user the "password length issue" is starting to become a real problem for me and others.

I understand you are considering the options regarding this and also working out the difficulties. Can you please give us a news update and perhaps let us know your thoughts as to where you are taking oclhashcat ?

Thank you.
#5
yes, truecrypt is next target
#6
(03-31-2013, 12:34 PM)atom Wrote: about the changes in 0.45 its strange i see something:


type: feature
file: hashcat-cli
desc: dropped predefined charsets ?h, ?F, ?G and ?R
trac: #55

type: feature
file: hashcat-cli
desc: added a collection of language-specific charset-files for use with masks
trac: #55

type: bug
file: hashcat-cli
desc: fixed a null-pointer dereference that can lead to a segmentation fault
trac: #104

Downloaded once again hashcat-0.45b1.7z and what I see
inside the docs folder, the "changes" file, is this:

[Image: abg3D4iJ.jpg]
#7
Yeah you are right. Next version will have it fixed Smile
#8
Did a few screen captures before start, and at the finish.
The first time, and a second time were done with the same command line, same options,
same hash file, and, as the 4th screen shoot shows, oclhashcat found 40 more on the 2nd run,
that were not found in the first run.
This is not happening all the time, but after this, it's better to run at least twice with the same
command line to prevent that, any new founds looks like new, but they arean't.
They simply were not found on the first run.
Here are the screen shoots to better illustrate the situation:

[Image: acr3eB4T.jpg] [Image: ado101pm.jpg] [Image: abnWCN9M.jpg] [Image: abiYcl3G.jpg]