You are browsing the archive for Malware Analysis.

PE Compilation Timestamps vs. forensics

March 11, 2019 in File Formats ZOO, Forensic Analysis, Malware Analysis

If you use PE Viewers, Editors, Dumpers for forensic purposes, you are most likely using them to extract a compilation timestamp from a binary – to determine when a specific file was compiled.

There is a little ‘gotcha’ here.

Some of these tools show the timestamps as UTC, some localize them to your timezone. This is far from ideal. Without being sure, you may be writing down incorrect information in your report.

We can fix it.

If you don’t know the algorithm your tool of choice is using to display the time you can quickly test it.


As per the PE documentation, the Compilation timestamp is:

Date and time stamp value. The value is represented in the number of seconds that have elapsed since midnight (00:00:00), January 1, 1970, Universal Coordinated Time, according to the system clock. The time stamp can be printed by using the C runtime (CRT) time function.’

So, there is no better way to test your fav. programs other than using atest executable with a timestamp set to 0, and observe the results (make sure you change your timezone to a different one from UTC!).

If the result is 1970-01-01 00:00:00 then your tool is using UTC. If it is different, then it’s a local time, and perhaps in some cases, it may be wrong (better test with two different tools). As such, you may even see compilation year 1969!

Quick test shows that:

  • Die, IDA, Efd, PE Studio – use local time


  • PE Bear, PPEE, VirusTotal – use UTC

After I published this post, Brian provided additional comment (thx!):

I would also take note of daylight saving time. Offset of UTC changes from your local time zone.

And here is the test .exe I used, in case you need it.

Extracting and Parsing PE signatures en masse

March 3, 2019 in Clustering, Malware Analysis, Yara sigs

A few years back I was dealing with a large corpora of PE files, and many of them were PUA/Adware installers. Most of these were signed, so I thought it would be cool to automate writing yara sigs based on these PE signatures. So I did, and it helped me a lot with dividing the whole sampleset into clusters. I could then just exclude (a.k.a. delete) the uninteresting clusters of installers, and remove them from a scope of my further analysis.

Today someone reminded me of this project, and I thought I will jot down some notes + share the yara sig I generated at that time. I believe in automation a lot, and hope this will be useful to someone facing similar problems.

To extract signatures from a PE file, one can use the from Didier Stevens. Once we extract it, we can analyze it. The problem is that:

  • the extracted signature is in a binary form
  • parsing it is non-trivial, so we need to use existing tools to do so for us

After googling around, I eventually learned how to do it & wrote a simple batch file that I delegated this unpleasant task to. The batch file takes a name of a PE file from a command line, and extracts the binary signature using, and then parses it… in 3 different ways.

This is the batch file: extract "%1" "%1.cert"
if exist "%1.cert" (
openssl asn1parse -inform DER -i -in "%1.cert" > "%1.cert.asn"
openssl pkcs7 -inform DER -in "%1.cert" -text -print_certs > "%1.cert.asn2"
certutil -asn "%1.cert" > "%1.cert.asn3"

You may notice that I am using both openssl / certutil. Why double, or even triple the effort? This is because I discovered that relying on data extracted by only one tool was not enough. To be frank, I don’t know the intricate details of what is exactly stored inside the actual Authenticode signature, and how. The ASN format is not a pillow read either, hence I went with a ROI-driven approach and simply extracted the data in any possible way and format.

With that, I ran it over a corpora of samples. I then used a quick & dirty parser I wrote for the data outputted by these two tools, and generated a yara sig that covered most of the installers in the corpora.

You can download the Yara Sig file here. Note, I saved it as Unicode, so you can see localization issues one needs to take into account while parsing sigs.

Feel free to use it, but only on your own risk. I don’t guarantee that it’s error free. Also, if you are listed in the sig file, it’s only for purposes of samples’ clustering.