Weird Issue Cracking 128-bit RC4 Acrobat 6.0 PDF from Acrobat 10.0 Paper Capture Plug

[Xtraeme]

I have been testing the -m 10400 through -m 10700 PDF functionality with a buddy and stumbled on a weird issue. Basically I started out with a PDF that has the owner password set, but the user password unset. Using Acrobat 11 Pro I generated a PDF using the owner password 'hashcat'. Then I extracted the hash using the latest pdf2john from github with the following hashcat parameters:

Code:

cudaHashcat64 -m 10500 -a 3 PDF-password-is-hashcat.hash ?l?l?l?l?l?l?l

The hash target specified in 'PDF-password-is-hashcat.hash' looked like this:

Code:

$pdf$2*3*128*-1028*1*16*XXXXee15d4b3e08fe5b9ecea0e02XXXX*32*XXXX9d72c7c670c42eeb4fca1d2XXXX000000000000000000000000000000000*32*XXXX3e868dc87604626c2b8c259297a14d58c6309c70b00afdfb1fbba10eXXXX

It only took about a half hour to crack on a GTX 670. So I imagine it'll be a lot faster on an ATI 7970.

Anyhow, here is where it gets weird.

The original file was output using the Adobe Acrobat 10.0 Paper Capture Plugin. The document security properties were identical other than a different password.



Since that worked I quickly put together a batch script to run through common password masks:

http://pastebin.com/2fDeQkQ6

The first line immediately threw an error:

Code:

WARNING: Hashfile 'PDF-password-is-...hash' in line 1 ($pdf$4*4*128*-1324*1*32*XXXXab525883d8493ece960c6038dcdcc75a428632fd4e45ba43bfe17ec3XXXX*32*XXXX566a10eba70977b1b24f23d0XXXX00000000000000000000000000000000*32*XXXX507dabd18be0aa0d9f4c70607c0fa183ba9cf5e503026a524319b5e7XXXX): Line-length exception
Parsed Hashes: 1/1 (100.00%)

The hash was extracted using the latest pdf2john.py the same way as how I extracted it with the first PDF. That got me curious. I tried several other versions of pdf2john (john-1.8.0-jumbo-1, john179j5, and older copy I have) and got similar output.

For example, john-1.8.0-jumbo-1 output:

Code:

PDF-password-is-...pdf:$pdf$4*4*128*-1324*1*32*XXXXab525883d8493ece960c6038dcdcc75a428632fd4e45ba43bfe17ec3XXXX*:::::PDF-password-is-...pdf

To make doubly sure the data was correct, I quickly grabbed a PDF-parser tool and wrote a companion script to convert the owner object hash to a hexstring for hashcat.

The two are clearly different:

pdf2john:
XXXX507dabd18be0aa0d9f4c70607c0fa183ba9cf5e503026a524319b5e7XXXX

manual extraction:
XXXX507dabd18be0aa5c5c729f4c70607c0fa183ba9cf5e503026a524319b5e7XXXX

To better show the difference:

Code:

XXXX507dabd18be0aa 0d     9f4c70607c0fa183ba9cf5e503026a524319b5e7XXXX
XXXX507dabd18be0aa 5c5c72 9f4c70607c0fa183ba9cf5e503026a524319b5e7XXXX

Looking at the PDF in a hex editor I see it shows 33 bytes in total (including the starting 0x0 and ending 0xf8):

Code:

_                start-v                          v-my script screws up as well?
008c5fc8:  38 2f 4f 28 XX XX 50 7d ab d1 8b e0 aa 5c 72 9f 4c 70 60 7c 0f a1 83 ba  :8/O(..P}.....\r.Lp`|....
008c5fe0:  9c f5 e5 03 02 6a 52 43 19 b5 e7 XX XX 29 2f 50 20 2d 31 33 32 34 2f 52  :.....jRC...u.)/P -1324/R
_                                               ^-end

I've tried all three versions (minus the spaces and trailing semi-colon + description):

Code:

XXXX507dabd18be0aa 0d     9f4c70607c0fa183ba9cf5e503026a524319b5e7XXXX : PDF2JOHN
XXXX507dabd18be0aa 5c5c72 9f4c70607c0fa183ba9cf5e503026a524319b5e7XXXX : Manual
XXXX507dabd18be0aa 5c72   9f4c70607c0fa183ba9cf5e503026a524319b5e7XXXX : Hex from file

And all of them give the same error.

0x5c 0x5c 0x72 translates to: \\r

So it looks like it's being processed as a carriage return.

Any ideas how to resolve this?

----

edited to obfuscate hashes

[philsmd]

Well, from you registration you should probably already know that posting hashes in here (yes, also pdf dumps) is strictly forbidden: see forum rules https://hashcat.net/forum/announcement-2.html

Did you try latest bleeding jumbo code (the latest pdf2john.py version): https://raw.githubusercontent.com/magnum...df2john.py

Btw: without the pdf file it is very difficult to troubleshoot what the problem in *parsing the file* is. If you do not want to upload the file on a third-party file hoster, you should probably get in direct contact with some hashcat dev/moderator and share the file to troubleshoot.

[Xtraeme]

Well, from you registration you should probably already know that posting hashes in here (yes, also pdf dumps) is strictly forbidden: see forum rules https://hashcat.net/forum/announcement-2.html

My bad. I edited the post so there's a leading and trailing series of XXXX for the hashes. I just wanted to make sure I included enough information to help debug through whatever's going on with this file since it looks like it's hash related.

Did you try latest bleeding jumbo code (the latest pdf2john.py version): https://raw.githubusercontent.com/magnum...df2john.py

I just tried it again and still get the 0x0d output that (presumably) results in the "line-length" exception. Or maybe it's the nonstandard 1324?

$pdf$4*4*128*-1324*1*32* ...

As compared to the other,

$pdf$2*3*128*-1028*1*16

Which I assume is just key length related.

Btw: without the pdf file it is very difficult to troubleshoot what the problem in *parsing the file* is. If you do not want to upload the file on a third-party file hoster, you should probably get in direct contact with some hashcat dev/moderator and share the file to troubleshoot.

I just uploaded the file. Who would be the best person to contact? Thanks for the advice philsmd.

[philsmd]

After analyzing this problem more carefully it seems that the only problem is the longer /ID element size *32* vs *16* (jtr does already load - and crack - this).

An example from here https://hashcat.net/wiki/doku.php?id=example_hashes shows that oclHashcat currently expects an id size of 16 bytes ($pdf$2*3*128*-1028*1*16* ... therefore something like $pdf$2*3*128*-1028*1*32*... is currently not supported, or in your case: $pdf$4*4*128*-1324*1*32*.... (note: the 32, it is not *16*).

If you want to request support for longer /ID elements in oclHashcat, you should open an enhancement trac ticket here: https://hashcat.net/trac/ (and link this thread)

[Xtraeme]

You are quick philsmd. I'm writing up a ticket now (ticket 594). For easier tracking I'm including the PDF encryption object. Both of the PDFs are backwards compatible to Acrobat 6.0. I obscured parts of the hash and substituted in # signs.

The problem file PDF-password-is-...pdf:

Code:

obj 1126 0
Type:
Referencing:

  <<
    /CF
      <<
        /StdCF
          <<
            /AuthEvent /DocOpen
            /CFM /V2
            /Length 16
          >>
      >>
    /Filter /Standard
    /Length 128
    /O '(\x##\x##P}\xab\xd1\x8b\xe0\xaa\\r\x9fLp`|\x0f\xa1\x83\xba\x9c\xf5\xe5\x03\x02jRC\x19\xb5\x##u\x##)'
    /P -1324
    /R 4
    /StmF /StdCF
    /StrF /StdCF
    /U '(\x##\x##Vj\x10\xeb\xa7\tw\xb1\xb2O#\xd0\x##\x##\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x##\x##)'
    /V 4
  >>

The file that worked PDF-password-is-hashcat.pdf:

Code:

obj 73 0
Type:
Referencing:

<<
    /CF
      <<
        /StdCF
          <<
            /AuthEvent /DocOpen
            /CFM /V2
            /Length 16
          >>
      >>
    /EncryptMetadata false
    /Filter /Standard
    /Length 128
    /O '(\x##t\x##0\t\xb8b\x8d\xba\x9e3\xc6\xcf\xf4\x98F\xff\xcb\x8eV \xe5\x81\xda\xd6\xce.#\xe0\x##R\x##)'
    /P -1324
    /R 4
    /StmF /StdCF
    /StrF /StdCF
    /U '(\x##S\x##\xf3\x10\xb8\xc9\x1f\x8d\xee\xc0=,\x##S\x##\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x##\x##)'
    /V 4
  >>