Issue with Optimized kernel

[Arthur.pendragon]

Hello,

When I do an hybrid dict + mask attack with optimized kernel mode, some password are not found. When I omit the "-O" parameter, all passwords are found correctly.

I'm using the version 6.2.6.

Do you have a solution?

Thank you 
Arthur

[penguinkeeper]

Which -m number are you using?

[Snoopy]

optimized kernels reduce (most times, every time?) the max length of passwords which can be found, i bet this is the "problem" here

[penguinkeeper]

Yeah, some other things that get lost are encoding/translation problems. Optimised vs Pure trade-offs are very situational so it's hard to know exactly what might be going on without knowing the -m but yeah, for most algorithms, the max password length is reduced, especially on sha256crypt etc

[Arthur.pendragon]

Which -m number are you using?

I'm using -m 1000

[Arthur.pendragon]

optimized kernels reduce (most times, every time?) the max length of passwords which can be found, i bet this is the "problem" here

Hi,
No the password is short : 8 characters

[penguinkeeper]

Which -m number are you using?

I'm using -m 1000

Perfect, yeah. -m 1000 has the encoding problems I mentioned earlier. NTLM is MD4(UTF16-LE($plain)) and the optimised version doesn't do the UTF16-LE step fully, it takes a shortcut so that especially non-ASCII characters aren't hashed properly and therefore don't get cracked. I'd strongly recommend using pure only if possible and if you know there's a chance there can be multibyte/non-ASCII characters in any of the plains. There is already a Github issue for this, to better explain to the user the limitations.

https://www.github.com/hashcat/hashcat/issues/3958

[Arthur.pendragon]

Which -m number are you using?

I'm using -m 1000

Perfect, yeah. -m 1000 has the encoding problems I mentioned earlier. NTLM is MD4(UTF16-LE($plain)) and the optimised version doesn't do the UTF16-LE step fully, it takes a shortcut so that especially non-ASCII characters aren't hashed properly and therefore don't get cracked. I'd strongly recommend using pure only if possible and if you know there's a chance there can be multibyte/non-ASCII characters in any of the plains. There is already a Github issue for this, to better explain to the user the limitations.

https://www.github.com/hashcat/hashcat/issues/3958

Very interesting but these passwords don't contain special characters. I suppose, I found another reason : very old passwords. With these ones, the hash algorithm was probably different. We have an Active Directory that was set more that 10 years ago.

[penguinkeeper]

That shouldn't be, it should be the same algorithm the whole time but as I say, it's likely just the encoding issue. Use pures when you can