1

I am trying to decrypt an .xml file, but I do not know what it contains.

What I do know:

  • starts with 6 character alphanumeric passphrase

  • passphrase is hashed by md5, or SHA1/2

  • AES128/256 encryption of xml file with hash key

If I am looking at this problem correctly, that means I have 62^6 possible passphrase variations. Assuming I can test around one million/s that means ~15hrs of decryption multiplied by 6 variations in hash/encryption algorithm. At that speed it seems not unreasonable to be able to brute force given a few days?

Any recommendations as to how to verify plaintext output in the decrypted XML file? My coding skills are not on the level of being able to figure this one out.
I know I will be able to visually tell when this file is decrypted properly, but are there any decryption programs that can do such a thing automatically?

techraf
  • 9,141
  • 11
  • 44
  • 62
Buster
  • 11
  • 1
  • 2
  • Depending on how it was encrypted there should be a checksum. Otherwise you can run an xml parser on the output [expat](http://expat.sourceforge.net/) is still the quickest one. You shall not get many valid XML files out. On the other hand running an XML parser will be a lot slower. – grochmal Aug 31 '16 at 02:22
  • Is it an element in the XML file that is encrypted or the whole file is? – techraf Aug 31 '16 at 04:54
  • i would use a regexp pre-filter (look for `/<\/\w+>/`) before passing to a full xml parser. – dandavis Aug 31 '16 at 20:28

3 Answers3

1

If you know the file truly contains an encrypted XML document, check the first decoded block for the existence of an XML prolog string: <?xml version="1.0" encoding="UTF-8"?>. (Version and encodings vary, of course.) At least look at the first five characters for the <?xml marker.

Of course, the prolog is optional, so it might not be present at all. It would help if you could see a decrypted file to know for sure what kind of crib to expect. Alternately, you could look at the destination application to see if you can learn what the schema is that it's expecting; then expand your first-block searching to include looking for the expected root node of the schema.

You won't get many false positives that decrypt the first five bytes to <?xml by coincidence. Anything you recover that much of, you can afford to evaluate the rest of the results by eyeball.

John Deters
  • 33,650
  • 3
  • 57
  • 110
0

Maybe this isn't what you're looking for, but if time is no option and you have the given code to brute force generate your potential password list, you just need to know when your file is actually decrypted, just attempt to parse the output with an XML library. Just about every language has one. Just something like:

for password in brute_force_list:
  # 1. Decrypt xml file into an in memory string
  # 2. Try to parse said string into an object
  # 3. If parsing was successful return the string
onetwopunch
  • 101
  • 2
0

The TrID tool would be the best bet. It can detect many different file types based on its contents. It can even tell what specific type of xml file it is. It has a command line and GUI version. Best bet would be to use the "-ae" option which will add the guessed extension to the file name.

ARau
  • 619
  • 4
  • 9