Initial commit

[Fist0urs]

Add support to Kerberos 5 TGS-REP (tickets ARC4 encrypted), so as in request for format #81

Entry to add in wiki would be (password "hashcat"):

$krb5tgs$23$user$realm$test/hashcat$08e2261b7a89e56f530b2f7e0620fe8b$ecdca97c13814c95810d7706faf986dad98d06ba033fc5a45fbe9b417b855db5

The part "$user$realm$test/hashcat$" is optional. At the moment, input formats supported are:

$krb5tgs$23$user$realm$spn$checksum$edata2
$krb5tgs$23$**$checksum$edata2
$krb5tgs$23$checksum$edata2

[jsteube]

Our first full algorithm PR since we went OSS. Hurray!

... And it looks pretty good :)

[Fist0urs]

Thanks :)

I forgot to mention that I implemented the input format the same I did in john the ripper. So that full compatibility either side ;)

[jsteube]

Btw, is this somehow related to: #81 ?

[Fist0urs]

Yes, it is (look at first post :-p )

TGS-REP == AP-REQ concerning ciphered part and as it is name krb5tgs in john, I named it that way

[epixoip]

Nicely done, this is ok to merge

[jsteube]

PR Merged, many thanks! Can we close #81 ?

[Fist0urs]

Yes!

[magnumripper]

@Fist0urs on what grounds do you deem it "must be very rare"? Are you checking as little as five bytes in some cases, or do I misread the code? If it's just five bytes, you will likely get a false positive even for just ?a?a?a?a?a?a?a and that is definitely not rare! That's why I asked you to add the extra check in JtR.

[Fist0urs]

It is 6bytes not 5 but same problem. Mmmh you're right, it was 8bytes in my mind, don't know why haha. I'll implement the final stuff then, thanks for notifying it! 👍

[jsteube]

Wait, if the function returns 0, then it's not cracked. Therefire I think the code, as it is, is fine. There's no need for extra checks with 12 bytes required.

[jsteube]

Oh wait, maybe that's what the confusion is coming from:

if (((out[2] & 0xff00ffff) != 0x30008163) && ((out[2] & 0x0000ffff) != 0x00008263)) return 0;

didn't you mean:

if (((out[1] & 0xff00ffff) != 0x30008163) || ((out[2] & 0x0000ffff) != 0x00008263)) return 0;

?

Also note the changed element number! Because if not, then there's actually only 5 bytes for check

[magnumripper]

Yeah it's a bit hard to read. Here's the JtR CPU code (for accepting, not rejecting)

if (((!memcmp(ddata + 8, "\x63\x82", 2)) && (!memcmp(ddata + 16, "\xA0\x07\x03\x05", 4)))
    ||
    ((!memcmp(ddata + 8, "\x63\x81", 2)) && (!memcmp(ddata + 16, "\x03\x05\x00", 3))))
{
    /* check the checksum to be sure */
    (...)
}

So worst case it's 5 bytes, best case is 6 bytes. That's far too small.

[Fist0urs]

Indeed it is a bit hard to read, the first line is to check if any of first 16bytes contains headers. This was to avoid to compute next 16bytes and increase performances.

But we have the case that "header 1" goes with "footer 2" and would say "good boy" whereas it should not, so we have to add the last check to avoir false positives :)

[magnumripper]

But we have the case that "header 1" goes with "footer 2" and would say "good boy"

That can be avoided but we'd still only test five bytes worst case. It's pretty clear in the JtR code.

[Fist0urs]

Yes, this will be fixed tomorrow 👍