Hahcat is using weird random combinations instead of the files on dicitonary

[cesalbaral]

Hashcat has started to try some kind of weird randomly generated combination instead of trying out the actual words in the dicitonary file.

Here's the command that I entered:

Code:

hashcat64.exe -a 0 -m 2500 -w 3 --status --status-timer=60 -o "C:\Hacking\Hashcat\passwords.txt" --outfile-format=3 -r "C:\Hacking\my_rules\(uppercase,original) +symbol +123.rule" "C:\Users\cesal\o.hccapx" "C:\Hacking\Wordlist\cupp\chelsea.txt"

And these were the candidates that I saw on status:
Candidates.#3....: $HEX[2474406d66307264210d40313233] -> HEX[427279616e6164616d73313131390d40313233]

Even checking for lots of times with long intervals the status always shows these kind of candidates.

I have checked the wordlist and it doesnt contain any of those randomly generated characters.
Here are the examples of some words on the list:
F00tb@ll8573
F00tb@ll8574
F00tb@ll8575
F00tb@ll8576
F00tb@ll8577
F00tb@ll8578

I have also attached a screenshot of this error along with the post.

Does anyone have any idea, how to solve this annoying problem?

[philsmd]

$HEX[2474406d66307264210d40313233] means that hashcat is trying to use the string 2474406d66307264210d40313233 in hexadecimal notation (it's in hexadecimal because there are some non-printable or "escaped" characters, like colons etc).

2474406d66307264210d40313233 stands for $t@mf0rd!\r@123
427279616e6164616d73313131390d40313233 stands for Bryanadams1119\r@123

as said, these strings are represented in hexadecimal instead of ascii/utf8 because they contain some special characters (in your case the carriage return character \r). You can use a hex to ascii/utf8 converted to analyze the password candidates.

I would guess this has to to with your rules and/or dict file. If you do not want to use these special characters like carriage return you need to modify your dicts/rules.
My guess is that everything works as intended it's just a misunderstanding

[cesalbaral]

$HEX[2474406d66307264210d40313233] means that hashcat is trying to use the string 2474406d66307264210d40313233 in hexadecimal notation (it's in hexadecimal because there are some non-printable or "escaped" characters, like colons etc).

2474406d66307264210d40313233 stands for $t@mf0rd!\r@123
427279616e6164616d73313131390d40313233 stands for Bryanadams1119\r@123

as said, these strings are represented in hexadecimal instead of ascii/utf8 because they contain some special characters (in your case the carriage return character \r). You can use a hex to ascii/utf8 converted to analyze the password candidates.

I would guess this has to to with your rules and/or dict file. If you do not want to use these special characters like carriage return you need to modify your dicts/rules.
My guess is that everything works as intended it's just a misunderstanding

Thanks, I found that the problem was with the wordlist. The wordlist was craeted on windows using a python script called cupp. Converting it into UNIX Worldlist through this terminal command solved the problem:

Code:

tr -d '\015' <windows.txt >UNIX.txt

But I still don't know if it's necessary to do this or not. 
Is hashcat using the displayed hex codes or is it using those words on the list to perform attack? 
Anyway my problem has been solved for right now.

Also are you sure that you coverted those hexadecimal scripts correctly. That /r wasn't supposed to be in the password. 

[philsmd]

\r, 0x0d and '\015' are all just different forms of representing the carriage return character. Therefore yes I'm sure that it's \r, and *you* also remove the same character with your tr command.

I think you just need to do some more research on how one can represent the characters and how ascii and encoding etc work (and how to represent the same character in terms of hexadecimal, octal, binary or decimal numbers). It's just the same character.

The "hex codes" are just a different representation of the same strings (and in our case password candidates). Yeah, this is just a display thing. Hashcat will always use the raw version. That is why the status line shows $HEX[] to indicate that this is just a different representation of the string, but internally the raw password candidate converted to raw bytes (in general, hashing always works with the raw bytes) are being used.


BTW: your original list was not in a standard way. Hashcat can (automatically) deal with both \r\n (the windows version) and \n (the linux/mac version) of newlines. Not sure what the "new line" of your your original list was looking like, probably none of the versions mentioned above. maybe it was \n\r or some other strange and not supported variant of "new lines".