I am looking for a way to make sure that a particular archive file does not contain any sort of malicious code. From time to time new vulnerabilities pop up (e.g. gzip, 7zip) so I though a good idea would be to convert archive from one format to another before opening it on the secure system.

I assume this operation would make exploiting nearly impossible. I am not concerned about files compressed inside the archive (lets say they are ascii plain text), only about the archive format itself. This trick works well with image formats, where converting a suspicious file ( e.g. jpeg to bmp) bypasses file execution and returns sanitized image. For example, to mitigate MS14-013.

Is there similar way of converting archive without decompressing it/compressing again? Perhaps someone knows a better method?

  • Which jpeg exploit are you referring to? Jun 25, 2015 at 14:31
  • For example MS14-013. But I guess many others not discovered yet.
    – TextF
    Jun 25, 2015 at 14:45

2 Answers 2


The way you convert a jpg to a bmp would be to essentially decompress the jpg and write it as a bmp. To convert one archive format to another you'd have to decompress the original first and then compress in the new format.

Whether this is "safer" or not depends on whether the tool you're using to automatically decompress has different vulnerabilities to the tool that you use to open the archive normally. There are not too many advantages of automated conversion. The only ones I see are if the conversion took place on an isolated machine where any exploit triggered could do limited damage. Additionally, if the vulnerability is not in the compression algorithm itself, then using an automated tool may carry less risk as it would be less likely to be the target of attackers.

Also, I can't see the benefit in changing format. If you're concerned about vulnerabilities in a compressed file, why not make your automated checker decompress the files and then add them to a new archive in the same format before sending it to you? This would remove anything encoded into the archive file itself unless the exploit was a function of the compressed files themselves. If it was, changing format wouldn't help you as a targeted attack would simply use the files to exploit this but add it to a different archive format knowing you would then convert them.

  • 1
    "I can't see the benefit in changing format" - I guess there could be a vulnerability that is exploited any time a carefully formatted file F appears in an archive of type T. If that were the case, putting F into a different type of archive would remove this threat. That said, I think the odds that such a vulnerability exists and won't be executed when the conversion is done is very slim. Jun 25, 2015 at 15:17
  • That's what I alluded to at then end. For a secure system you have to make the assumption the attacker knows what you are doing. The only secret things should be private keys and passwords (and the data they protect). If the attacker knows you convert from 7zip to gzip then he puts the carefully formatted file F in a 7zip knowing that when F appears in T the exploit is triggered... T is gzip, not the original format. Jun 25, 2015 at 15:23
  • I thought it is possible to convert a format somehow bypassing the normal decompression that uses vulnerable software or libraries. If it is not possible, then obviously all your comments are true (thanks for them by the way!). Triggering exploits on the isolated machine is not an option - it must stay clean.
    – TextF
    Jun 25, 2015 at 15:37
  • BTW, assuming that we cannot decompress an archive safely, the automated checker does not make much sense - it can be exploited and forced to put the malicious code into the new archive. I guess I am left with plain text files.
    – TextF
    Jun 25, 2015 at 15:44

Being able to convert an archive from one format to another without decompressing it is very rare. Different formats use different file structures and algorithms that are incompatible and you'll be forced to decompress the source format at some point.

When conversion by decompression is done, many of the vulnerabilities could be exploitable. The attack surface might even get bigger than before since several programs are used when doing decompression, compression, and again decompression.

If you are receiving the files from untrusted sources you could specify that only a certain archive formats are allowed. Choosing which one to support is not easy since none of the formats are "safer" than the others. You could argue that the ones with more CVEs is less secure, but that also means that a lot of issues in them have already been fixed. Is zip safer because it has less CVEs? Not necessarily, the vulnerabilities might not have been disclosed to the public, or less research might have been done.

If you stick to the most common archive formats (7z, zip, gz) and keep your software up to date, you should be fine.

  • Thank you for the quick reply. In that case my assumption about decompression was wrong, thinking I can transform one format into another bypassing the risky part. As we all know, keeping software up to date is not enough for the most advanced malware, so I am looking for more radical solution. I guess using uncompressed plain text and bitmaps (and validating them) is the answer.
    – TextF
    Jun 25, 2015 at 15:59
  • 2
    Keeping software up to date would protect you from all attacks that use crafted archives leveraging known vulnerabilities in earlier versions. Defending against an attack that takes advantage of a previously unknown vulnerability is almost impossible, and minimizing the damage is the best you can do (eg. by virtualization). 0-day attacks are generally expensive and are only used in very sophisticated attacks. Jun 25, 2015 at 16:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.