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
Which -m number are you using?
optimized kernels reduce (most times, every time?) the max length of passwords which can be found, i bet this is the "problem" here
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
(06-04-2024, 01:58 PM)penguinkeeper Wrote: [ -> ]Which -m number are you using?
I'm using -m 1000
(06-04-2024, 02:03 PM)Snoopy Wrote: [ -> ]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
(06-05-2024, 10:14 AM)Arthur.pendragon Wrote: [ -> ] (06-04-2024, 01:58 PM)penguinkeeper Wrote: [ -> ]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
(06-05-2024, 12:10 PM)penguinkeeper Wrote: [ -> ] (06-05-2024, 10:14 AM)Arthur.pendragon Wrote: [ -> ] (06-04-2024, 01:58 PM)penguinkeeper Wrote: [ -> ]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.
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