Why would the list run only on Linux?

[DoNoHarm]

Hello everyone,

For some reasons I have to use hashcat on both The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali) and windows 10. The issue is that the wordlist runs fine on The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali), but on windows all the candidates are hex values and unreadable charts. This applies for all the candidates and only for this newly made wordlist, previously everything went great on both The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali) and windows (well, thanks Atom!). I tried to inject a known password to the wordlist but still it wasn't recognized by hashcat. I used iconv on The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali) to convert the wordlist to ASCII, UTF-8, and others but no luck (sometimes I see only the rules and no words at all). I tried to use MS word and online encoding services to figure it out but also nothing worked.

The newly made wordlist is made via web-crawling apps such as wordhound and cewl and also via manual search in web pages and copy/paste. Originally it contained many languages (Chinese, Russian, Arabic, and u name it!) but they were cleaned (manually, by sorting it and deleting words in the beginning and end of the list) and I only kept European languages (exception is Russia). It was originally made in the The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali) machine. Size of the list is 1.5 MB

This is the first customized wordlist I make so I wonder what did I miss?

[atom]

Maybe the hashes which you're trying to crack were not created on a server using utf8 but some codepage/iso encoding.

[DoNoHarm]

That could be, but I have already cracked +40% of the hashes using wordlists from the Internet so why would the problem appear only now?

Note: the list (txt file) looks fine when I open it with windows applications e.g. notepad or MS word.

Update: it turned out that most of the lists I used from the internet are in iso-8859-1 and not utf-8. I just converted my list and will update the thread as soon as I try it.

[DoNoHarm]

Changing the encoding did not work. I changed it to iso-8859-1, Windows 1252 and UTF7 but no luck at all. I still find it very weird because I am using exactly the same wordlist and exactly the same hashes, but it works on one OS and not the other. At the beginning of the process, hashcat states that there are 143500 words in The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali) and 143522 words in Windows, so I thought maybe I should mention this too. I am attaching an image to show the difference in candidates. All the candidates in the windows machine look similar and my interpretation is that hashcat is only seeing/trying the rules and can't see/try the words for some reasons.

[atom]

Hashcat uses binary loading of the wordlist, there's no functions used that somehow do a textual interpretation of the data (and automatically convert them). Therefore it makes absolute no sense what you're describing. Please do a md5sum of the wordlists on both systems first to make sure they are actually the same.

[DoNoHarm]

You are right and the md5sum was not identical. However, now the md5sum is identical and the word count before the cracking process is the same, but the problem persists. So here is what is happening:

1 - Some of hashes are already cracked using over-the-internet lists
2 - Made new list in The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali) and copied it to windows machine, md5sum is identical
3 - Started the crack using the new list on The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali), everything is good.
4 - Started the crack using the new list on Windows, not good. Candidates are shown in the previous post.
5 - Double checked the md5sum of both the hashes list and wordlist, still identical
6 - Added a new stdout line and now the batch file looks like:

Code:

hashcat64.exe -m 5500 Hashes.txt collection3.txt --stdout
hashcat64.exe -m 5500 Hashes.txt collection3.txt

7 - The stdout shows the correct list and is the same as the stdout in the The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali) machine
8 - When the cracking process starts, still the same problem! The words on the list are not used as candidates.
9 - I thought maybe they are used but not in the candidates column because the list is too small, so I added dive's rule to take a longer look at the candidates but still the same problem.

[atom]

I don't know, I find this really hard to understand to what you said in the beginning:

For some reasons I have to use hashcat on both The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali) and windows 10. The issue is that the wordlist runs fine on The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali), but on windows all the candidates are hex values and unreadable charts.

I don't find any connection. You maybe want to explain everything again from the beginning.