solution a page down

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.

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