\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".
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".