Adobe Security handler cryptversion and 'NewCryptDataExProc' function question

[joblack]

solution a page down

[5aLIVE]

Couldn't you share you findings with us rather than delete you original question? I would been interested read how you reached a solution.

[joblack]

Couldn't you share you findings with us rather than delete you original question? I would been interested read how you reached a solution.

Sure.

As described in

http://livedocs.adobe.com/acrobat_sdk/9.1/Acrobat9_1_HTMLHelp/API_References/Acrobat_API_Reference/PD_Layer/PDDoc.html#PDCryptNewCryptDataExProc

the PDCryptNewCryptDataExProc is a callback function for the decryption routine. If you use a PDF Security handler this is the function which gives you the key to decrypt your pdf.

Syntax

void (*PDCryptNewCryptDataExProc)(PDDoc pdDoc, char **cryptData, ASInt32 *cryptDataLen, ASInt32 *cryptVersion)

The PDDoc is the PDF handle, the cryptData is a pointerpointer to the decryption key, the cryptDataLen is they decryption key lenth (in bytes).

So far so good - I just was puzzled about the cryptversion variable. A very popular plugin uses 1 or 2 as version.

The only difference between 1 and 2 is the key length (a little bit redundant but who knows why).

The algorithm is described in The Adobe PDF Reference (check under the Encryption section: V=1 or V=2 (not the password protection))). For further information: the algorithm is practially used in the ineptpdf scripts (getkey_v2 function).

As a quick and dirty solution for every unknown plugin (without any deeper inside). You can set a breakpoint on that function and get the key manually.

[5aLIVE]

Thanks for replying, I'm guessing the key length will either be either 40 or 128 bits in this case.
I've sent you a private message.

[joblack]

Thanks for replying, I'm guessing the key length will either be either 40 or 128 bits in this case.
I've sent you a private message.

Yes, but in theory there could be keys between 40 and 128 bits (in 8 bit steps -> padding).