7z & Multi-volume archives

May 5, 2020 in Anti-Forensics, File Formats ZOO

This post is pretty much a summary of what I twitted the other day. I thought it will be good to post it in one place in case anyone is interested.

7z is a very flexible archiver and its support for multi-volume archives is just a natural consequence of other archivers supporting this feature, including Rar and Winrar that have it implemented since like… for-e-v-e-r.

While experimenting with 7z I noticed that it’s possible to make multi-volume archives with its first file being just… 1 byte. I was perplexed by it and started digging, because if this is the case, all the forensic tools that look for file magic, or even file extensions may need to rewrite their parsers.

So, for starters… you can run this:

7z a foo.7z -v1 -v10M

This creates a number of 7z archives with the first one being just one byte long:

The naming convention is interesting. As you can see, the standard .7z file extension is followed by a 001, 002 for two consecutive volumes created:

  • foo.7z.001
  • foo.7z.002

When I tested the same thing for Zip archives (still using 7z), I ran this:

7z a foo.zip -tzip -v2 -v10M

I noticed that for Zip files 7z needs at least 2 bytes in its first volume, but everything else works the same way as for .7z.

Finally, you can use Rar / WinRar to build a Rar archive, and then keep ‘R’ – the first character of the Rar! signature – in the first volume file, and the rest of the archive in another as demonstrated on this picture:

When I looked at the actual code of 7z to see how it interpretes file extensions:

I noticed that the code is relying on only the first character of its file extension to determine whether it is a zip or rar multi-volume archive. So… you can rename the volumes to:

  • foo.r.01
  • foo.r.02

or

  • foo.z.01
  • foo.z.02

And you will still be able to process these with 7z.

While the good ol’ Unix tools can do the same (split, cat, gzip, etc.) it is still an interesting find. 7z is used a lot on Windows boxes and people w/o much technical knowledge could use these built-in features w/o a need to learn much of *NIX CLI.

It really kinda changes the dynamics of the way file extensions should be understood and processed, and how access to archive files – especially these that by design are multi-volume – should be handled, especially by security tools. And in particular, these that help in malware detection and post-intrusion analysis. And perhaps… this is just a tip of the iceberg.

Share this :)

Comments are closed.