Anyone know how Acrobat Reader authenticates its plugins?

Plugins made with the SDK work nicely in Adobe Acrobat, but the reader requires the use of an additional "integration key" which costs $$$ and requires signing some general agreements (like not to save files etc).

The resource dir of Acroreader contains a field API_ADOBE_PUBLIC_KEY and the default plugins contain the fields API_DIGITAL_CERTIFICATE and API_CRYPTO_DIGEST (or some such). This suggest some procedure like:

1) Vendor key derived from adobe secret key used for certificate (API_DIGITAL_CERTIFICATE)
2) Hash of plugin code and data? (API_CRYPTO_DIGEST)
3) Some sort of signature scheme to verify the above.

I would expect the system to cryptographicly sound, but it would be interesting if there was some way around it without patching the executable.

Anyone know anything about this?

I started half-heartedly disassembling the reader, but it's really ugly and convoluted C++ code.

Dizzy

any url for downloading the sdk and all the stuff?
Thanks

That would be: http://partners.adobe.com/asn/developer/acrosdk/main.html for the SDK.

I just found out that Acrobat Reader does a md5 check on every plugin, but only on the PE header/optional header/data directories. So this means that it should be possible to cram any code you like into an old certified plugin as long as you retain the headers and the resource entries for the certificate. Haven't tried it yet, but at least some random patching seems to work.

Writing a handy version-independent plugin to remove printing restritctions etc is left as an excercise for the interested reader. Or why not a decryptor for some of the completely braindead pdf encryption systems around. The standard encryption does take some heavy brute forcing, though.

Dizzy

I believe Adobe may use an elliptic curve public-key cryptosystem made by Certicom. I remember seeing a statement on Certicom's website mentioning that Adobe was one of the companys licensing their products. If this is indeed the case, you aren't touching the crypto. Your best bet would to attack the implementation, but it'll still be a challenge. Good luck and be sure to let us know what you find out!

Regards,
Kythen

It may be that the plugin authentication is done with elliptic curves. Anyway, as I already said, keeping the PE headers intact should allow us to get around that.

The standard security handler, btw, doesn't use any fancy crypto stuff, it's essentially a md5 hash of the password (and possibly some other stuff) used as a key to rc4. The specs are available on the web if you search a little. Also, there are brute force hackers against the 40 bit exportable version, although none of them are freely available AFAIK.

Dizzy