IArchiveExtractorTestItem Method

ContentResult TestItem(
	int index,
	out long testedSize,
	string password = null
)

Parameters

index  Int32

The archive item given by this zero-offset index to extract to test. An item's index is given by the Index property. See ChildDocuments. ArchiveContent is derived from class DocumentContent.

testedSize  Int64

The tested expansion (de-compressed) size of the archive item. If the returned result Ok then this value will hold the tested item's expanded size in bytes. A value of -1 indicates that the test failed for this item.

password  String  (Optional)

Optional password (default is null). Archive items can have individual item passwords except for solid compressed archives where all items have the same password because they are compressed together into solid blocks.

Check the returned ContentResult value, if WrongPassword is the value then this archive item requires a decryption password. User can make subsequent calls to this method using a password until Ok is returned or there are no more passwords to try.

Return Value

Upon a successful test completion (Ok returned), the archive item's tested expansion size will be given by the [out] argument 'testedSize'.

Users should test the true expansion size of archive items before extracting items from an archive for the following reasons:

• Archive file is not a trusted one created by user or created within user's organization.
• To aid in "zip bomb" detection. A zip bomb is a malicious archive file designed to crash or render useless the program or system extracting it. Zip bombs are usually small file size that can expand to tera-bytes or even peta-bytes. For more information on zip bombs see https://en.wikipedia.org/wiki/Zip_bomb.
• Archive item metadata such as true expansion size can be corrupted intentionally or through accidental means. A zip bomb may have intentionally corrupted archive item header information such as expansion size, fooling the user into thinking it is safe to extract the item to the file system.
• Some single item archive formats such as bzip2 do not have item metadata such as expansion size so there is no way of knowing the extracted size of an item until it has finished being extracted.

There are other forms of zip-bomb attacks, such as self-replicating archives, that simply testing for item expansion size will not protect against. A self-replicating archive is one where the single extracted item is an exact duplicate of the archive***. Fortunately, if user calculates and keeps an accounting of parent/child binary hashes (see MD5BinaryHash or SHA1BinaryHash) a self-replicating archive can be quickly spotted - as there should be no repeating binary hashes in the parent/child hierarchy.

*** There are more sophisticated self-replicating archives where the top most archive parent and first extracted item are different formats but an overall pattern will repeat at some point, e.g., a GZIP archive whose child item is a TAR file and this TAR archive's child is an exact copy of the original GZIP (pattern: GZIP -> TAR -> GZIP -> TAR -> and on and on...). In this case, all extracted GZIPs will have the same binary hash as will all extracted TAR archives, so again, calculating binary hashes and checking the parent/child hierarchy for repeating binary hashes can help in spotting a self-replicating archive.

Reference