You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by "Tilman Hausherr (JIRA)" <ji...@apache.org> on 2014/09/11 17:04:34 UTC
[jira] [Resolved] (PDFBOX-2341) WriteDecodedDoc cant decrypt pdf
correctly
[ https://issues.apache.org/jira/browse/PDFBOX-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tilman Hausherr resolved PDFBOX-2341.
-------------------------------------
Resolution: Won't Fix
Assignee: Tilman Hausherr
The old parser works as described, I traced through it, saved intermediate files etc. What really happened is a border case that can't be solved without creating trouble elsewhere: the encrypted stream has a hex 0D at the end. In the sequential parser that 0x0D isn't taken into the stream because it is assumed that it doesn't belong to it, i.e. one expects "stream-data 0D 0A endstream", or "stream-data 0D endstream". The non-sequential parser just takes the stream according to the length.
To prove that theory I changed your file so that there is one 0D more in the stream. Now it works with the sequential parser. This suggests that this missing 0D has a meaning for the decryption routine. I also did the opposite test, changed the length of the stream so that 0D isn't included, and not it failed with the nonsequential parser.
So long story in short: use nonseq :-)
> WriteDecodedDoc cant decrypt pdf correctly
> ------------------------------------------
>
> Key: PDFBOX-2341
> URL: https://issues.apache.org/jira/browse/PDFBOX-2341
> Project: PDFBox
> Issue Type: Bug
> Components: Parsing
> Affects Versions: 2.0.0
> Reporter: simon steiner
> Assignee: Tilman Hausherr
> Attachments: aes256_57.pdf
>
>
> java -jar ~/pdf-box-svn/app/target/pdfbox-app-2.0.0-SNAPSHOT.jar WriteDecodedDoc aes256_57.pdf tmp.pdf
> "Kind Regards" missing
> I guess you will ask me to use nonseq
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)