Automatic /r stripping by hashcat? - Printable Version +- hashcat Forum (https://hashcat.net/forum) +-- Forum: Support (https://hashcat.net/forum/forum-3.html) +--- Forum: hashcat (https://hashcat.net/forum/forum-45.html) +--- Thread: Automatic /r stripping by hashcat? (/thread-11967.html) |
Automatic /r stripping by hashcat? - KYMS - 05-10-2024 Hello, I have not found it documented that hashcat automatically strips /r (CR) characters but it seems to be doing so. I have been going under my apparently old understanding that, when present, /r needed to be removed manually (dos2unix, or similar). The steps I used to test this are: 1. I created two wordlists, nixlist and winlist with the same words. On each line in winlist I manually added carriage returns (/r) using CTRL-V CTRL-M in vim (I didn't have a Windows computer handy to make the file). 2. I confirmed the wordlist file structure using hexdump. 3. I manually hashed nixlist and winlist with openssl to confirm the /r was causing hashes to be different. 4. I then created a hashlist by hashing nixlist and saved it to a file named hashlist. 5. Next I ran hashcat on hashlist using winlist as the wordlist. Before doing so I made sure hashcat.potfile was empty and I also manually set the poftile to local.potfile. I was surprised to see that the winlist wordlist successfully recovered passwords in the nixlist-based hashlist. This suggests that hashcat is stripping /r. Can someone confirm this or specify my error? If it is documented somewhere, can you point me to that link? Command output: Quote:❯ cat winlist Quote:❯ hexdump -c winlist Quote:❯ for word in $(cat winlist); do echo -n "$word" | openssl sha1; done | awk '{print $2}' Quote:❯ cat nixlist Quote:❯ hexdump -c nixlist Quote:❯ for word in $(cat nixlist); do echo -n "$word" | openssl sha1; done | awk '{print $2}' Quote:❯ hashcat -m 100 -a 0 --potfile-path=local.potfile hashlist winlist Quote:❯ cat local.potfile Thank you for any help you can offer. RE: Automatic /r stripping by hashcat? - penguinkeeper - 05-10-2024 Almost all programs accept both \n and \r\n newlines. It's not that it's stripping them, it's just reading the line and accepting \r\n as the newline. Usually, \n is Linux and \r\n is Windows RE: Automatic /r stripping by hashcat? - KYMS - 05-10-2024 Hi penguinkeeper, I do not think it is about acceptance. I am content that /r/n and /n do not cause issues in almost all programs. But they do cause issues in some programs. Tools like shasum, md5sum, and openssl include them in their operations which results in a different hash for what humans see as the same word. I was under the impression that hashcat did as well. My testing yesterday and today suggest otherwise. If /r is there and hashcat is not including it when hashing the word then hashcat is "stripping" it (or some word that has the equivalent end result). How would you describe it if /r is part of the line but not considered by hashcat when hashing the word? RE: Automatic /r stripping by hashcat? - penguinkeeper - 05-10-2024 In the case of the \r being embedded inside a plain like a\rb, Hashcat would find it as it would any other, just as long as it's not at the end as then it'd be considered as a multibyte newline Code: $ echo -en "a\rb" | md5sum "610d62" being the hexadecimal representation of a \r b RE: Automatic /r stripping by hashcat? - KYMS - 05-10-2024 I agree with what you are saying. But in the command output below you can see that: A. The two wordlist files have the same words but hash to different values because of the presence of \r\n (hex 0d 0a) vs \n (hex 0a) at the end of each word. B. When I use the words in windowslist.txt in hashcat they are successful in recovering the hashes that were made using the other wordlist (linuxwords.txt). C. Using openssl or shasum the words in windowslist.txt hash to a different value that what hashcat successfully recovers. I am trying to understand why. Hashcat is doing something to/with the windowslist.txt wordlist that causes the words it contains to hash to different values than I get when using shasum or openssl to hash the list. The end result is the passwords are recovered (yay!) but the behavior is not what I expected. # linuxwords.txt and windowswords.txt look the same Code: ❯ cat linuxwords.txt |