Keepass2john: Support newer format XML keyfile

[magnumripper]

Despite comments in code, the existing support appeared to be v1 only. This new clause is tested with a v4 database and keyfile.

[solardiz]

I don't know anything about the "newer format", but I made some comments on the code assuming it can end up running on arbitrary/wrong input.

[magnumripper]

Samples added to john-samples.

The new (well it was many many years ago) format for an XML keyfile is like this:

<?xml version="1.0" encoding="UTF-8"?>
<KeyFile>
    <Meta>
        <Version>2.0</Version>
    </Meta>
    <Key>
        <Data Hash="50BD7B21">
            4C772D15 A5D58BEC 0C707345 ECEBDFE2
            18F0529A 4882FE3C D48F00E5 4B733073
        </Data>
    </Key>
</KeyFile>

The 50BD7B21 is supposedly a CRC32 of the following 32 bytes of key data, not required and not used nor needed in any way for opening (or cracking) a database. If that attribute exists, KeePass would warn if it doesn't match. We don't currently even validate it (I fail to arrive at the CRC above, and I didn't care to figure out why - maybe endianess).

The old format (which we already supported) was more like this (IIRC) for the same 32 byte key:

  <?xml version="1.0" encoding="UTF-8"?>
  <KeyFile>
      <Meta>
          <Version>1.0</Version>
      </Meta>
      <Key>
          <Data>THctFaXVi+wMcHNF7Ovf4hjwUppIgv481I8A5UtzMHM=</Data>
      </Key>
  </KeyFile>

I think there might be whitespace between <Data> and the Base64. We now handle that.

We don't have such sample (the samples we had are "any file used as a key file", not XML). I may try to create one for john-samples later just for completeness.

[magnumripper]

Sorry I jumped the gun with requesting a review, I think it's good to go now. Tested with v2 and mockup v1.

[magnumripper]

We don't currently even validate it (I fail to arrive at the CRC above, and I didn't care to figure out why - maybe endianess).

Turns out KeePass 2.x and KeePassXC calculate this CRC differently, making it pretty much useless. I will not add any check, it's just overkill.

[solardiz]

Added a comment on one code issue. Also, maybe remove unsigned from definition of buffer instead of all the casts?

[solardiz]

Should probably be != 44 rather than < 44 here. That would be consistent with the check for hex.

[magnumripper]

Actually no, because there may be whitespace (of any sort) between the Base64 and </Data>.

Admittedly we don't know they are 44 actual Base64 characters anyway. I'll see if base64_convert_cp returns something useful. BTW I don't recognize that _cp suffix, need to check what the heck that is.

[magnumripper]

OK so I can get an output size from base64_convert... but it returns 64 no matter what garbage I feed it. There are also means for an error variable but it always returns "no error". I'm ignoring this for now.