Appending/Replacing data in exe without breaking its digital signature - exe

Background:
I have an application to which I want to pass a param at download time, which is actually the id of the advertiser from which it got downloaded. We use this id to report successful installation.
This param will be different for different advertisers. Somebody suggested me here to append the param data at the end of the exe and fetch it. I was able to do so perfectly.
Problem:
The problem now is that if we append in the exe, it breaks the digital signature of exe. If I replace the data with same amount of other data, the digital signature tab remains, but the digital signature becomes invalid.
So is there any way to append/replace data in exe without bothering its digital signature?

It doesn't sound too achievable, maybe make the download a zip with the signed exe and a text file with the code (which it then reads).
Bit of a wild stab in the dark would be to try using NTFS Alternate Data Streams
This may or may not invalidate the signature
You may or may not be able to configure mime types such that the exe could be a single download.
The additional data may or may not be preserved when a file is zipped.

Related

Data Security Issue - Printing PDF - "deleted" information gets printed

The Problem
I recieved a pdf file at work which I then printed. In the pdf file there were several optional fields where one could enter information such as "place of birth" etc. If I open the pdf file on my computer, I can see a set of input information A (a travel request with dates from this year 2017).
If I print the pdf on the local printer, the printed document contains a set of information B which for example contained travel request dates from 2015.
This information was not visible when opening the file on my computer.
I have been able to reproduce the error multiple times.
Why is this a problem?
It seems that previous entries into the pdf were yet somehow stored in the pdf contrary to what was visible when opening the pdf. When printing, the printer seems to access only the oldest entries and prints those.
This is a potential breach regarding data privacy and security since the pdf file seems to save all previous entries without anyone knowing.
Especially at work, some of these pdfs contains bank account information and other identity related information.
The Question
Did anyone experience a simliar issue or knows how to delete the invisible old information yet stored in the pdf?
UPDATE1: I could not reproduce the error on other printers. It seems this error is caused by the specific printer. Yet the information must be present in the PDF file, which is the specific cause of my question.
UPDATE2: Using the information from the accepted answer, I used the program "PDF CHAIN" and selected the option "drop XFA from document". I then saved the manipulated document again and printed it on the same printer.
Finally, the correct information was printed.
At a guess (and that's all it is without being able to see the original file) the PDF contains optional content or annotations which contain different field data for Print and Screen.
If you open the file using a PDF consumer (eg Acrobat) then what you see is the 'screen' result. Depending on the consumer you are using it may then either send the screen data to the printer, or substitute with the 'Print' data.
The printer you note as being a problem is capable of direct PDF printing, you haven't stated if that's how you are printing the PDF file, or whether you are using an application, nor whether the other printers are PDF capable or not.
My guess is that there is a different decision being made somewhere in the 2 print paths as to which is the 'correct' information to print.
Note that this does not mean that the PDF 'seems to save all previous entries without anyone knowing'; that's not really possible with a PDF file.
A malicious PDF processing application could do so, by adding comments to the PDF file, but only that application would be able to retrieve it.
But it is possible to have multiple entries of different types for different purposes, and if they aren't the same (because of the tool used to edit the file) then you can get strange results like this.
Note that if this is a problem for you then you probably shouldn't be using PDF, but you can mitigate the issue by digitally signing your documents. Signed PDF files include means (secure cryptographic hash) for verifying that the document has not been tampered with . Of course, you can't then edit the PDF file without re-signing it.
Oh, one other possibility would be that the PDF was actually an XFA form; its possible to have part of the document be a valid PDF which prints 'something' when a PDF consumer can't handle an XFA form, but that need bear no relation to what you see when you use an XFA processor.
My money's on optional content, AcroForm fields, or annotations where the Print data is different from the Screen data though.

Bouncycastle - how to distinguish attached from detached signature file programmatically

I am working on an application that is used to sign/verify files according to pkcs7. I am using bouncycastle. The problem is that whenever i pass in (to verify!) a file containing a signature i cannot find a way to distinguish whether the file contains both signature and signed data or just a signature. The point is to ask the user to select a second file if the first one contains only signature /and display appropriate error/.
Is there any way around this problem?
To construct the CMSSignedData (the first time, before you know whether it has encapsulated content), just use the CMSSignedData(byte[]) constructor, where byte[] is the full contents of the file.
Once you have the CMSSignedData instance, then getSignedContent() simply returns null if the content was not encapsulated.
Once you have the basics working, if you are dealing with very large files, you may want to look at CMSSignedDataParser as a more advanced option that will avoid reading in the entire file.

ZIP archive comment

Currently I'm developing a minimalist ZIP 2.0 library.
In keeping with the motto "Read the f*ckin' manual!", I read PKWARE's appnote, so I know a ZIP archive containing only the "end of central directory record" is considered empty. This record defines a variable size "archive comment" in the end, which is why one has to scan backwards in search for the signature "PK\5\6" when loading the central directory. This leaves me with two questions:
1) What should I do when the user tries to add an archive comment containing this sequence?
2) Is an empty archive allowed to have a comment? (WinRAR isn't able to show it when the archive is empty while 7-Zip is)
UPDATE:
I have had email contact with Mr Roshal, lead developer of WinRAR. He confirmed 2) to be a bug in WinRAR that is now fixed.
The ZIP file format does not specify what is valid for the content of a file comment or zipfile comment. In one place their documentation describes the comment as "text information", but elsewhere, the comment is described as "bytes of data", and the appnote itself doesn't say anything about what can go in a comment.
However, even if the spec does allow arbitrary binary data in a comment, that doesn't mean that you have to allow it using your library, and if you choose to allow it, that doesn't mean you have to make it easy.
So, here's a list of possible ways of handling the comment. Choose one.
Refuse to allow binary data in comments.
Allow binary data, but refuse to allow the specific signature.
Allow arbitrary binary data, but require the user to provide some sort of extra confirmation, if they try to include the signature.
Allow arbitrary binary data, don't worry about the signature.
Of course, for any option where imbedding the signature is possible, the documentation should warn the user that doing this will result in an invalid ZIP file.

How to use ImageMagick to test if received input is an image (for security purposes)?

Imagine an environment in which users can upload images to a website by either uploading it from their pc or referring to a remote url.
As part of some security checks I'd like to make sure that the referenced object is indeed an image.
In the case of a remote-url, I of course check the content-type, but this isn't bullet-proof.
I figured I could use ImageMagick to do the task. Perhaps executing the ImageMagick.identify() method and if no error is returned and returned type is either JPG|GIF|,etc. the content is an image. (In a quick check I noticed that TXT files are identified correctly as well, so I have to blacklist these)
Is there any better way in doing this?
You could probably simply load the image via ImageMagick's appropriate function for your language of choice. If the image isn't formatted properly (in terms of internal formatting, not its aesthetic properties, that is), I would expect ImageMagick to refuse to load it and report an error. In PHP, for example, readImage returns false if the image fails to load.
Alternatively, you could read the first few hundred bytes of the file and determine if the expected image file format headers are present; e.g., "GIF89" etc.
These checks may backfire, if your image is in a compressable format (PNG, GIF) and it is constructed in a way similar to a zip bomb https://en.wikipedia.org/wiki/Zip_bomb
Some examples at ftp://ftp.aerasec.de/pub/advisories/decompressionbombs/pictures/ (nothing special about that site, I just googled decompression bombs)
Another related issue is that formats like SVG are in fact XML and some image processing tools are prone to a variant of "billion laughs" attack https://en.wikipedia.org/wiki/Billion_laughs
You should not store the original file. The generally recommended approach is to always re-process the image and convert it to an entirely new file. There have been vulnerabilites exploited inside valid image files (see GIFAR), so checking for this would have been useless.
Never expose your visitors to an image file that you have not written out yourself and for which you did not choose the file name yourself.

How to digitally sign Images like JPG TIFF and BMP

I wish to digitally sign my image collection which consists of JPG , TIFF , BMP , SWf , Fla files.
My question is how to digitally sign these images? If I sign JPG or Tiff , whether signature will get attached to these files (as it happens in document files like PDF or MS word etc)? If so where it get store in file metadata fields , or remain outside? Can i extract signature data?
Please note I wish to sign these images Individually and do not want to get converted into any other format like PDF. Also I donot wish to sign it using email client.
In general those formats were not designed with signing in mind, so your best option is to create a detached signature and keep it near the file. An alternative is to use wrapping signature but then other software won't be able to display the image until you remove the wrapper.
Storing the signature in metadata can be possible for some formats but what applications would be able to handle this?
I know it has been a long time, but you might want to look into steganography. Metadata can be extracted and removed from files. Steganography will allow you to embed digital signatures(encrypted phrases) in a way that is almost only detectable using statistical analysis.
You can also create a mime container which will contain the original image and a detached signature.
Attached signatures are only useful for specific apps, as they are not standard.
Try answering the posters question folks, and not giving another unneeded and unwanted opinion, it's way to common these days in my humble opinion.
Obviously what the poster asked for is to use a signature to copyright his works, so you need to sign the image, period, And a method to do so.
So let's see... grab Gimp or Photoshop. Get your image and create a new layer with transparent background. write in a signature with your mouse or digital pen in an area near the bottom right edge. Choose merge layers and flatten image. Seems like that would do it.

Resources