I tested this with win 10 and GnuWin32's wc command.
The differences between linux and windows are the following.
Linux:
windows:
The line counts are exactly the same, what changes are the total bytes in the output: but the explanation is very simple, hashcat uses "\r\n" (carriage return and new line) for windows because otherwise (with only "\n") some windows users claim that "there is only a single line in this file).
That means that 6412929824 / (5 + 2) is the same as 5496796992 / (5 + 1) and the result is both of the times 916132832 (the expected line count, which can be calculated also by (26+26+10) ^ 5 , total charset to the power of the password length).
So we can't make any conclusion by just seeing a difference in bytes in the output (even though what makes me wondering is why you get 624817152 bytes in the output).
The differences between linux and windows are the following.
Linux:
Code:
./hashcat -a 3 --stdout -i --increment-min 5 --increment-max 5 -1 ?d?u?l ?1?1?1?1?1?1?1?1 | wc
916132832 916132832 5496796992Code:
hashcat64.exe -a 3 --stdout -i --increment-min 5 --increment-max 5 -1 ?d?u?l ?1?1?1?1?1?1?1?1 | wc
916132832 916132832 6412929824The line counts are exactly the same, what changes are the total bytes in the output: but the explanation is very simple, hashcat uses "\r\n" (carriage return and new line) for windows because otherwise (with only "\n") some windows users claim that "there is only a single line in this file).
That means that 6412929824 / (5 + 2) is the same as 5496796992 / (5 + 1) and the result is both of the times 916132832 (the expected line count, which can be calculated also by (26+26+10) ^ 5 , total charset to the power of the password length).
So we can't make any conclusion by just seeing a difference in bytes in the output (even though what makes me wondering is why you get 624817152 bytes in the output).