1 tb zip drives

And, individual external hard drives often start at 1 TB of storage, with larger options going past 32 TB. The average user stores a mix of photos, videos, and documents.

When you're setting up a backup plan, it's hard to gauge how many photos and videos 1 terabyte of data can hold. If your phone runs out of space, you're probably not carrying around a second one. For backing up your Apple or Microsoft computer, clunky portable hard drives are fragile, and small flash drives are easy to lose. Plus, the way you connect them to a computer seems to change every year. Your old external USB 3.

The cloud gives you an easier way to store a large amount of data, including photos, videos, and important files, without ever having to worry about disk space. When you store content in the cloud, you'll be able to do more with it, like:. Dropbox has plans for individuals, families, and teams with 1 TB or more of storage and can grow with your needs. Store all your photos, videos, personal files, and work projects with ease.

How much is 1 TB of storage? Share this. What is a terabyte? Two factors work in our advantage: all files share a common suffix the kernel , and the uncompressed kernel is a string of repeated bytes.

We will represent CRC as a matrix product—this will allow us not only to compute the checksum of the kernel quickly, but also to reuse computation across files. You can model CRC as a state machine that updates a bit state register for each incoming bit. The basic update operations for a 0 bit and a 1 bit are:.

To see why, observe that multiplying a matrix by a vector is just summing the columns of the matrix, after multiplying each column by the corresponding element of the vector. This representation is called homogeneous coordinates. The matrices M 0 and M 1 are shown. The benefit of a matrix representation is that matrices compose. Suppose we want to represent the state change effected by processing the ASCII character 'a', whose binary representation is 2.

We can represent the cumulative CRC state change of those 8 bits in a single transformation matrix:. And we can represent the state change of a string of repeated 'a's by multiplying many copies of M a together—matrix exponentiation.

For example, the matrix representing the state change of a string of 9 'a's is. The square-and-multiply algorithm is useful for computing M kernel , the matrix for the uncompressed kernel, because the kernel is a string of repeated bytes. To produce a CRC checksum value from a matrix, multiply the matrix by the zero vector. The zero vector in homogeneous coordinates, that is: 32 0's followed by a 1.

Here we omit the minor complication of pre- and post-conditioning the checksum. To compute the checksum for every file, we work backwards. Continue the procedure, accumulating state change matrices into M , until all the files have been processed. Earlier we hit a wall on expansion due to limits of the zip format—it was impossible to produce more than about TB of output, no matter how cleverly packed the zip file.

It is possible to surpass those limits using Zip64 , an extension to the zip format that increases the size of certain header fields to 64 bits. Support for Zip64 is by no means universal , but it is one of the more commonly implemented extensions.

As regards the compression ratio, the effect of Zip64 is to increase the size of a central directory header from 46 bytes to 58 bytes, and the size of a local directory header from 30 bytes to 50 bytes.

Referring to the formula for optimal expansion in the simplified model, we see that a zip bomb in Zip64 format still grows quadratically, but more slowly because of the larger denominator—this is visible in the figure below in the Zip64 line's slightly lower vertical placement. In exchange for the loss of compatibility and slower growth, we get the removal of all practical file size limits.

Suppose we want a zip bomb that expands to 4. How big must the zip file be? Using binary search, we find that the smallest zip file whose unzipped size exceeds the unzipped size of With Zip64, it's no longer practically interesting to consider the maximum compression ratio, because we can just keep increasing the zip file size, and the compression ratio along with it, until even the compressed zip file is prohibitively large.

An interesting threshold, though, is 2 64 bytes 18 EB or 16 EiB —that much data will not fit on most filesystems. Binary search finds the smallest zip bomb that produces at least that much output: it contains 12 million files and has a compressed kernel of 1.

The total size of the zip file is 2. I didn't make this one downloadable, but you can generate it yourself using the source code. Probably the second most common algorithm is bzip2 , while not as compatible as DEFLATE, is probably the second most commonly supported compression algorithm. Empirically, bzip2 has a maximum compression ratio of about 1.

Ignoring the loss of compatibility, does bzip2 enable a more efficient zip bomb? Yes—but only for small files. So it is not possible to overlap files and reuse the kernel—each file must have its own copy, and therefore the overall compression ratio is no better than the ratio of any single file. There is still hope for using bzip2—an alternative means of local file header quoting discussed in the next section. Additionally, if you happen to know that a certain zip parser supports bzip2 and tolerates mismatched filenames, then you can use the full-overlap construction , which has no need for quoting.

So far we have used a feature of DEFLATE to quote local file headers, and we have just seen that the same trick does not work with bzip2. There is an alternative means of quoting, somewhat more limited, that only uses features of the zip format and does not depend on the compression algorithm.

At the end of the local file header structure there is a variable-length extra field whose purpose is to store information that doesn't fit into the ordinary fields of the header APPNOTE. TXT section 4. The extra field is a length—value structure: if we increase the length field without adding to the value, then it will grow to include whatever comes after it in the zip file—namely the next local file header. Each local file header "quotes" the local file headers that follow it by enclosing them within its own extra field.

It does not chain: each local file header must enclose not only the immediately next header but all headers which follow. The extra fields increase in length as they get closer to the beginning of the zip file. We want a header ID that will make parsers ignore the quoted data, not try to interpret it as meaningful metadata. Zip parsers are supposed to ignore unknown header IDs, so we could choose one at random, but there is the risk that the ID may be allocated in the future, breaking compatibility.

The figure illustrates the possibility of combining extra-field quoting with bzip2, with and without Zip Both "extra-field-quoted bzip2" lines have a knee at which the growth transitions from quadratic to linear.

The line stops completely when the number of files reaches , and we run out of room in the extra field. In the Zip64 case, the knee occurs at files, after which the size of files can be increased, but not their number. It increases the compression ratio of zbsm. Gynvael Coldwind has previously suggested slide 47 overlapping files. Pellegrino et al.

We have designed the quoted-overlap zip bomb construction for compatibility, taking into consideration a number of implementation differences, some of which are shown in the table below. The resulting construction is compatible with zip parsers that work in the usual back-to-front way, first consulting the central directory and using it as an index of files. Among these is the example zip parser included in Nail , which is automatically generated from a formal grammar.

The construction is not compatible, however, with "streaming" parsers, those that parse the zip file from beginning to end in one pass without first reading the central directory.

By their nature, streaming parsers do not permit any kind of file overlapping. The most likely outcome is that they will extract only the first file.

They may even raise an error besides, as is the case with sunzip , which parses the central directory at the end and checks it for consistency with the local file headers it has already seen.

If you need the extracted files to start with a certain prefix so that they will be identified as a certain file type, for example , you can insert a data-carrying DEFLATE block just before the block that quotes the next header. Not every file has to participate in the bomb construction: you can include ordinary files alongside the bomb files if you need the zip file to conform to some higher-level format.

The source code has a --template option to facilitate this use case. PDF is in many ways similar to zip. It has a cross-reference table at the end of the file that points to objects earlier in the file, and it supports DEFLATE compression of objects through the FlateDecode filter.

Didier Stevens writes about having contained a 1 GB stream inside a 2. Detecting the specific class of zip bomb we have developed in this article is easy: look for overlapping files. In general, though, rejecting overlapping files does not by itself make it safe to handle untrusted zip files. There are zip bombs that do not rely on overlapping files, and there are malicious zip files that are not bombs. Furthermore, any such detection logic must be implemented inside the parser itself, not as a separate prefilter.

One of the details omitted from the description of the zip format is that there is no single well-defined algorithm for locating the central directory in a zip file: two parsers may find two different central directories and therefore may not even agree on what files a zip file contains slides 67— See the "permits too-short file size" row in the compatibility table.

Robust protection against zip bombs involves sandboxing the parser to limit its use of time, memory, and disk space—just as if you were processing image files, or any other complex file format prone to parser bugs.

Compatibility of selected zip parsers with various zip features, edge cases, and zip bomb constructions. The background colors indicate a scale from less restrictive to more restrictive. For best compatibility, use DEFLATE compression without Zip64, match names in central directory headers and local file headers, compute correct CRCs, and avoid the maximum values of bit and bit fields.

Daniel Ketterer reported that the --template option was broken after the addition of --giant-steps. The workshop talk video, slides, and transcript are available. The source code of the paper is available. The artifacts prepared for submission are zipbomb-woot Did you find a system that chokes on one of these zip bombs?

Did they help you demonstrate a vulnerability or win a bug bounty? Let me know and I'll try to mention it here. It does eventually finish, and it deletes the temporary files as it goes, so it's only a temporary DoS that doesn't fill up the disk.

I tried the zip bombs against a local installation of addons-server, which is part of the software behind addons. The system handles it gracefully, imposing a time limit of s on extraction. The zip bomb expands as fast as the disk will let it up to the time limit, but after that point the process is killed and the unzipped files are eventually automatically cleaned up.

Mark Adler wrote a patch for UnZip to detect this class of zip bomb. Personally, I would dispute that UnZip's or any zip parser's ability to process a zip bomb of the kind discussed here necessarily represents a security vulnerability, or even a bug. It's a natural implementation and does not violate the specification in any way that I can tell. The type discussed in this article is only one type of zip bomb, and there are many ways in which zip parsing can go wrong that are not bombs.

If you want to defend against resource exhaustion attacks, you should not try to enumerate, detect, and block every individual known attack; rather you should impose external limits on time and other resources so that the parser cannot misbehave too much, no matter what kind of attack it faces.

There is nothing wrong with attempting to detect and reject certain constructions as a first-pass optimization, but you can't stop there. If you do not eventually isolate and limit operations on untrusted data, your system is likely still vulnerable. Consider an analogy with cross-site scripting in HTML: the right defense is not to try and filter out bytes that may be interpreted as code, it's to escape everything properly. Mark Adler's patch made its way into Debian in bug There were some unanticipated consequences: problems parsing certain Java JARs bug and problems with the mutant zip format of Firefox's omni.

Shortly after the publication of this article, Joran Dirk Greef published a restrictive zip parser JavaScript that prohibits irregularities such as overlapping files or unused space between files.

While it may thereby reject certain valid zip files, the idea is to ensure that any downstream parsers will receive only clean, easy-to-parse files. Overall, it seems that malware scanners have slowly begun to recognize zip bombs of this kind or at least the specific samples available for download as malicious. It would be interesting to see whether the detection is robust or brittle.

You could reverse the order of the entries in the central directory, for example, and see whether the zip files are still detected. In the source code , there's a recipe for generating zbsm. Another simple variant is inserting spacer files between the bomb files , which may fool certain overlap-detection algorithms.

Tavis Ormandy points out that there are a number of "Timeout" results in the VirusTotal for zblg. The results for zbsm. Interestingly, there are no timeouts in the results for zbxl.

Forum user reported that a certain ESET product did not detect zbxl. An update in the thread three days later showed the product being updated to detect it. An initial patch to detect overlapping files turned out to be incomplete because it only checked adjacent pairs of files. I personally mishandled this issue by posting details of a workaround on the bug tracker, instead of reporting it privately. A later patch imposed a time limit on file analysis. In my web server logs, I noticed a number of referers that appear to point to bug trackers.

I didn't directly experience this myself, but reports online say that Chrome and Safari may automatically unzip files after downloading. Rzah : "Yet another reason why 'Open Safe files after downloading' is a stupid default setting for a web browser.

Chromium commit f04d9b15bd1cbaadbc3ebffd0e3bb is perhaps related:. These metrics will measure how often that occurs. Something I didn't anticipate: unzipping one of the bombs on a compressed filesystem can be relatively safe. I only have the standard LZ4 compression enabled, no dedup.