New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initial commit #225

Merged
merged 1 commit into from Feb 17, 2016

Conversation

Projects
None yet
4 participants
@Fist0urs
Copy link
Contributor

Fist0urs commented Feb 16, 2016

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

This comment has been minimized.

Copy link
Member

jsteube commented Feb 16, 2016

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

... And it looks pretty good :)

@Fist0urs

This comment has been minimized.

Copy link
Contributor

Fist0urs commented Feb 16, 2016

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

This comment has been minimized.

Copy link
Member

jsteube commented Feb 16, 2016

Btw, is this somehow related to: #81 ?

@Fist0urs

This comment has been minimized.

Copy link
Contributor

Fist0urs commented Feb 16, 2016

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

This comment has been minimized.

Copy link
Member

epixoip commented Feb 16, 2016

Nicely done, this is ok to merge

jsteube added a commit that referenced this pull request Feb 17, 2016

@jsteube jsteube merged commit 0891e39 into hashcat:master Feb 17, 2016

@jsteube

This comment has been minimized.

Copy link
Member

jsteube commented Feb 17, 2016

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

@Fist0urs

This comment has been minimized.

Copy link
Contributor

Fist0urs commented Feb 17, 2016

Yes!

jsteube added a commit that referenced this pull request Feb 17, 2016

Merge pull request #228 from philsmd/master
minor: some formatting fixes re: #225 (-m 13100 = Kerberos 5 TGS-REP etype 23)
// TODO (or not): add RC4'ing of all edata2 then hmac-md5 and compare with
// checksum to be definitely sure that this is the correct pass (even if
// collisions must be very rare)

This comment has been minimized.

@magnumripper

magnumripper Feb 17, 2016

Contributor

@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.

This comment has been minimized.

@Fist0urs

Fist0urs Feb 17, 2016

Contributor

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

This comment has been minimized.

Copy link
Member

jsteube commented Feb 17, 2016

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

This comment has been minimized.

Copy link
Member

jsteube commented Feb 17, 2016

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

This comment has been minimized.

Copy link
Contributor

magnumripper commented Feb 17, 2016

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

This comment has been minimized.

Copy link
Contributor

Fist0urs commented Feb 17, 2016

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

This comment has been minimized.

Copy link
Contributor

magnumripper commented Feb 17, 2016

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

This comment has been minimized.

Copy link
Contributor

Fist0urs commented Feb 17, 2016

Yes, this will be fixed tomorrow 👍

Fist0urs added a commit to Fist0urs/hashcat that referenced this pull request Feb 19, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment