PDFBOX2.X - Read wrong Data from acroForm - pdfbox

Question

We are facing issue while reading data from acroform.
We are using PDFBOX2.x version to create PDF file. Our goal was to make pdf executable means we can download pdf file which contains acroform. We can collect data and later we can upload it to sync with database.
We are facing issue in which PDFBox debugger or we can say in upload file. Our textbox value is getting changed automatically.
PLease see more details in below image.
We have used PDF Debugger tool to check PDF content. You can see that totalBuyoffCount value is 0. But it should be 3.
I have used iTextDebugger to check same field
It is totally random behavior and we have noticed following things
Sometimes 0 or 1 value became N or Y
Very few fields are affected but it causes NumberFormat exception if it’s converted into String value.
It’s makes our whole file corrupted.
If it cannot be fixed then could you tell me in which area we need to see so that we can understand and debug why it’s value changed or from where value is retrieved so in case if we find then we can change or override this behavior

Answer 1

Looking at the PDF object in question (1499, gen 0) one finds
1499 0 obj
<<
/FT /Tx
/Q 0
/V (0)
/Ff 1
/Rect [0.0 1.0 1.0 1.0]
/Type /Annot
/Subtype /Widget
/T <77A2A671303FC282631C0C903EA8F40F>
/DA <2C85B77C2A5D81D53C5A3EB571EDBA1C>
/F 6
>>
endobj
So one might be tempted to say you see "/V (0)". And not 3.
While this is correct, it unfortunately does not mean a lot because the file is encrypted!
Thus, the question burns down to whether the string 0 in object 1499, generation 0, decrypts to "0" or to "3".
I have not implemented a PDF decrypter myself, so I cannot claim to check this with my own code.
The second best I can do is check against what Adobe decrypts that value to. My good old Adobe Acrobat 9.5 Preflight shows:
Apparently Adobe just like iText decrypts this 0 to "3". Additional checks with an online PDF decrypter or two support this decryption result.
Thus, it appears that PDFBox does not properly decrypt this 0 string.
Considering the OP's further observation "Sometimes 0 or 1 value became N or Y Very few fields are affected" it looks like PDFBox sometimes does not correctly decrypt single character strings.
An alternative option would be that there is some issue in the encryption parameters of the file in question. I don't really believe this but I cannot preclude it.
The bug
As Tilman already hinted at in his comments to PDFBOX-4453, the bug is due to the way PDFBox and in particular the SecurityHandler keeps track of which objects already have been decrypted and which still have to be: The already decrypted objects are stored in the HashSet SecurityHandler.objects; when asked to decrypt an object, SecurityHandler.decrypt first checks whether that object is in that set, and only if it is not, it is actually decrypted and added to the set.
Thus, if a still encrypted object equals an already decrypted one, a call to decrypt this encrypted object won't do anything at all.
In the file at hand there has been a string before that has been decrypted to "0". Thus, when the encrypted value of totalBuyoffCount, 0, is sent to the SecurityHandler for decryption, the value falsely is assumed to already be decrypted, so it remains as it is.
For longer strings this usually is no issue as their encrypted versions usually are completely garbled, so they won't be found among the already decrypted objects. Short strings, in particular single-character ones, on the other hand might have encrypted versions that make sense, so collisions may happen.
Options to fix this are discussed in the referenced Apache Jira issue. One option would be to replace the mentioned set by a flag of the individual objects in question but other options also are possible.