oclhc+ -m 1100 (dcc) salt length limitation

[acubens]

Hi there,

I get line length exceptions in oclHashcat+ when cracking dcc and traced this to hashes salted with a username > 8 chars. It would be great if this could be extended...

Further, when saving results to file with the -o option, the username gets an Ascii newline (hex 0a) appended.

Great program, by the way, if only I had the right hardware

Best
-J

[atom]

ok, i think i can get v0.26 to double the username size to 16 chars. that should be enough? however it will decrease performance a bit. but what do you mean with newline appended?

[acubens]

Sorry the newline stuff wasn't quite clear. If you have a line in a file with dcc hashes (username "test" and password "test") like this:

c8a8098c7c1c9b3674753eb4b753a1f0:test

When hc+ finds the password, it writes the following line into the outfile (see the special char after the username):

c8a8098c7c1c9b3674753eb4b753a1f0:test�:test

It seems that hc+ reads the whole line including the ascii line feed (hex 0a) without trimming whitespace from the hash file and appends ":[found password]". Not a big deal, just cosmetics. By the way, I am using the 32 bit cudaHashcat+ binary (on a BT4 R2 system, hence 32 bit).

Many thanks for your attention to the username length issue - I think in a real world scenario, (at least german) usernames can often be longer than 8 chars.

Best
-J

[acubens]

ok, i think i can get v0.26 to double the username size to 16 chars. that should be enough? however it will decrease performance a bit. but what do you mean with newline appended?

ah, i missed this: v0.26 (i.e. oclHashcat) deals without problems with longer salts (at least it doesn't complain), this is an oclHashcat+ v0.3 only issue

Best
-J

[atom]

i am not sure if i can make it for oclhc+. maybe in a later version.

[acubens]

i am not sure if i can make it for oclhc+. maybe in a later version.

Understood, many thanks.

Best
-J