You are browsing the archive for Forensic Analysis.

Beyond good ol’ Run key, Part 32

September 12, 2015 in Anti-Forensics, Autostart (Persistence), Compromise Detection, Forensic Analysis, Malware Analysis

Here are some more persistence tricks combined into a single post. I normally don’t post links, but sometimes it really makes sense and here is one of such cases. The below is a list of links covering many interesting persistence mechanisms that popped up on my radar and I don’t want to write about them in separate blog entries as others already did a great job researching and covering them – lots of very interesting concepts covered here:


After I posted this entry redp (author of blog) pinged me (thanks!) to add one more item I missed:

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.