You are browsing the archive for File Formats ZOO.

Sailing on the Seven Zips – its few less-known tricks & a trick to trick it into doing more tricks

September 9, 2015 in File Formats ZOO, Forensic Analysis, Incident Response, Malware Analysis, Reversing

7zip is an awesome tool and recently its new version (15.06 beta) has been released. While most of us typically use it as a handy (and free) replacement for both free and commercial zip and rar compressors it has a lot more to offer to file carvers and reversers. In this post I will demo a few things you can do with 7z that you might have never heard of.

If you are curious about the title, it’s a reference to an old school song by OMD.

PE files

7Zip treats PE files as containers and allows us to extract parts of it, including:

  • sections
  • .tls
  • certificates
  • appended data

that is, if you want to extract a certificate (signature) from the PE file you just need to run:

7z x <filename> CERTIFICATE

When you extract certificate this way, you still need to strip first 8 bytes before it can be parsed to produce meaningful ASN output, but it’s still very handy f.ex. for extracting strings from it.

If you want to extract appended data, you need to type:

7z x <filename>  [0]

Another handy option is ‘l’ which is listing objects that 7z finds inside a given container.

When used on the PE file, it gives not only a list of whats inside (sections, etc.), but also produces some info about PE file characteristics f.ex.:

  • Is it a 32- or 64- bit executable
  • Is it CLI or GUI executable
  • Section and File alignments
  • Code, Data size
  • Linker version
  • OS version required to run the program
  • Version info
  • etc.

This may come handy if you don’t have access to some tools and 7z is available (typical IR function in large companies :).

The below is what it shows for notepad.exe (from Windows 7):

7z-2There is also an option ‘-slt’ that can be added to the ‘l’ command which will give more information about each object listed with ‘l’.

Nullsoft Installers

One of the most interesting functions of 7z is ability to unpack Nullsoft installers. This functionality was present in older versions of 7zip, then if memory serves me right was removed for quite some time. Now it seems to be back (although extraction of the script doesn’t seem to be possible as it was in older versions).


7z l Wireshark-win32-1.12.7.exe

(on latest version of 32-bit Nullsoft installer for Wireshark)

can give us a nice list of files inside the installer.


7z x Wireshark-win32-1.12.7.exe

extracts all the files, including Nullsoft plug-ins.

This is actually very useful. Let’s remember that some installers for malware include not only the payload, but also malicious plug-ins. They can’t be found on the file system after the installation as they are extracted to TEMP folder, loaded and immediately deleted after they are no longer needed. If you do manual analysis you need to ‘catch’ them before they are deleted; with 7z you can extract them directly from the installer and can do analysis.

Calculating hashes

Another handy feature of 7z is ability to calculate hashes of files. Again, may come useful in an environment where you can’t use other tools.

To calculate hashes of the file you need to run the following command:

7z h -scrc* <filename>

The switch’s name is a bit misleading (suggesting CRC), but it basically tells 7z to calculate a hash, or a checksum. The default is CRC32, but the following are available:

  • CRC32
  • SHA1
  • SHA256
  • CRC64
  • BLAKE2sp

If you use an asterisk, all of them will be included:

7z-7Why Md5 is not on the list is a mystery to me.

The list of all hash types, as well as file formats and codecs in your version of 7z can be listed using the ‘7z i’ command.

Access to raw physical drive and volumes

I left this one to the end, as it is pretty cool, but has one caveat.

According to the documentation 7Zip Manager allows to view (and potentially even parse) raw volumes.

To access this functionality one needs to open 7Zip Manager as an admin and access the \\.  folder.

7z-3where you should see a list of drives + physical devices:

7z-4Unfortunately, it doesn’t work for C: and you will always receive the following message:

7z-5If this gets fixed at source it may become a handy raw file extractor.

Still, it’s pretty cool.


Couple of reasons.

  • Reason #1
    • Because it works for other drives which are not in use.
  • Reason #2
    • Because command line tool (7z) also supports it.
  • Reason #3
    • Because I will show you how to make it work with C: :)

So, what can we do with it?

Let’s start with a demo for a drive NOT in use.

We can f.ex. list the files on the drive by using the following command

7z l \\.\k:

This will give us a list of all files on that drive extracted directly from $MFT:

7z-8Using the file naming convention shown on the screenshot, we can extract the $MFT file using the following command:

7z x \\.\k: [SYSTEM]\$MFT

Pretty useful, isn’t?

Now, how to make it work for C:?

Since it works for other volumes it should for C: a well (principles for all live $MFT parsers are similar). After quick analysis I discovered that the author(s) of 7zip made a mistake in the way they open the volume. They call CreateFile with the parameters that prevent other applications from accessing the volume for writing and this obviously causes a problem for C: drive which is constantly in use.

The parameter in question is dwShareMode of the CreateFile function. In order to open a volume one has to specify both FILE_SHARE_READ and FILE_SHARE_WRITE, basically allowing other processes/system components to access the device. Authors(s) of 7z only use FILE_SHARE_READ.

Knowing what’s wrong we can fix it. You can either recompile 7z, or just do a quick binary patch.

I will show you the binary patch as it’s really quick.

FILE_SHARE_READ is equal to 1 and FILE_SHARE_WRITE is equal to 2, so the proper argument for CreateFile needs to be a sum of them: FILE_SHARE_READ + FILE_SHARE_WRITE = 3.

To locate where the change the binary, the easiest is to make a breakpoint on CreateFileW in ollydbg, then wait for it to hit on \\.\c:, and then step down to the procedure which actually sets the parameters for the function.

Then you can also go back to IDA Pro to see the actual code of the function which is shown below:


or      al, 1 ;  FILE_SHARE_READ

located at 00406839 to


allows us to make it work for drive C: as seen on the below screenshot (taken from Windows XP):

7z-AYou can follow the same process for 64-bit binary.

Craving for time? Carve some timestamps out… – TimeCraver v0.1

August 22, 2015 in File Formats ZOO, Forensic Analysis, Malware Analysis, Software Releases

Analysis of binary data is always challenging. Data can be encrypted, encoded, and stored in a number of proprietary formats. Understanding of what data represents and how it is stored is non-trivial. It typically involves either analysis of the code that writes stuff to a file, or trying our luck by guessing what is a possible structure of the actual data. The typical approach is to simply look at it and its properties.

This can involve checking its entropy and how it changes over the file, looking for patterns typically associated with popular compression algorithms, attempting to brute-force various trivial encryption algos, checking if any data is recognized as a string, Unicode string, localized string, a potential absolute or relative offset to other data, or maybe a byte-, word-, dword- long length preceding data etc.

One of the most popular tools that is used to analyze unknown data is binwalk and it helped me on many occasions by providing hints on what is possibly ‘in the file’. Sometimes, even if it didn’t recognize anything interesting was also a good hint – typically meaning encryption, or something really unusual/proprietary.

Existing tools are always handy, but I can’t count how many quick & dirty (and often completely stupid) scripts I wrote to get some data to look more ‘reasonable’ and ‘normal’.

In today’s post I am showing a simple example of such ‘unknown data analysis script’.

When we see a binary file, we typically run ‘strings’ on them and we gather a nice readable ‘printable’ data for analysis.The ‘non-printable’ is also interesting though, so another tool I often run is a strings-like script that carves timestamps out. This comes handy for smaller files, especially for these that look like a config, a quarantine, and anything really that looks like may have  a potential timestamps embedded in it.

Carving works following a simple rule – read 4/8 bytes, convert it to an epoch using various conversion algos (based on assumed timestamp format), see if epoch converts to a date between years 2000-2015, and if it does – just print it out, together with the offset and some extra metadata.


     00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F   0123456789ABCDEF
00 : 80 86 F6 34 00 C0 5D CE 56 CF CD 01 00 40 FA 13   ...4..].V....@.. 00
10 : 0F 00 CE 01 00 40 8B B7 0F 16 CE 01 00 80 59 DA   .....@........Y. 16
20 : 6B 2E CE 01 00 00 BE D2 FE 45 CE 01 00 A4 03 01   k........E...... 32
30 : 85 95 C2 01                                       ....             36

Looking at such binary data doesn’t give us much useful information.

Running timecraver over it, gives us the following:

 TimeCraver v0.1,, 2015-08-23
00000000,DOSTIME ,44C257B0,2006-07-22 16:52:00,8086F634
00000004,FILETIME,50B94880,2012-12-01 00:00:00,00C05DCE56CFCD01
0000000A,EPOCH   ,400001CD,2004-01-10 13:44:45,CD010040
0000000C,FILETIME,510B0580,2013-02-01 00:00:00,0040FA130F00CE01
00000012,EPOCH   ,400001CE,2004-01-10 13:44:46,CE010040
00000014,FILETIME,512FEF7F,2013-02-28 23:59:59,00408BB70F16CE01
0000001C,FILETIME,5158CDFF,2013-03-31 23:59:59,008059DA6B2ECE01
00000024,FILETIME,51805B00,2013-05-01 00:00:00,0000BED2FE45CE01
00000026,EPOCH   ,45FED2BE,2007-03-19 18:13:18,BED2FE45
0000002C,FILETIME,3DE3D068,2002-11-26 19:50:00,00A403018595C201

The first column is an offset, followed by the timestamp type, then hexadecimal EPOCH calculated from the data, then its YYYY-MM-DD hh:mm:ss representation and finally the actual bytes from the file that are converted to EPOCH.

The data is immediately more readable and certain conclusions can be drawn. If you look at the offsets, distance between them and type of timestamps you may actually ‘see through’ the data and potentially ‘define’ a reasonable structure.

In this particular case, we can see that FILETIME is

00000004, 0000000C
00000014, 0000001C
00000024, 0000002C

– looks like a sequence of FILETIME records. Following this logic, we can guess that structure of the file is potentially like this:

00000000,DOSTIME ,44C257B0,2006-07-22 16:52:00,8086F634
00000004,FILETIME,50B94880,2012-12-01 00:00:00,00C05DCE56CFCD01
0000000C,FILETIME,510B0580,2013-02-01 00:00:00,0040FA130F00CE01
00000014,FILETIME,512FEF7F,2013-02-28 23:59:59,00408BB70F16CE01
0000001C,FILETIME,5158CDFF,2013-03-31 23:59:59,008059DA6B2ECE01
00000024,FILETIME,51805B00,2013-05-01 00:00:00,0000BED2FE45CE01
0000002C,FILETIME,3DE3D068,2002-11-26 19:50:00,00A403018595C201

I can confirm it since it is one of the test files I created :)

The script can be found here.

Happy craving & carving !

Bonus: if you look at the data in Registry, you will find more timestamps than you thought are actually there. This is a subject for another post :)


Bonus will be here faster than expected – turns out Andrew Case, Jerry Stormo, Joseph Sylve, and Vico Marziale wrote an awesome python script for timestamp carving in Registry