Portable Executable: coming soon

In the upcoming 0.8.1 release of the Profiler initial support for PE files has been introduced. 🙂

Optional Header

Most of the work went into optimizing the UI and allowing for complex custom views to be built easily, while maintaining great speed. Even the grid control you can see here displayed is a custom control.

In the following screenshot you can see a complex view displaying the section headers.

Section Headers

And here’s a more basic view for the import directory.

Import Directory

Another eye candy screenshot of the section headers with entropy computation for one section.

Section Entropy

What will be present in this first PE edition is mainly about the file format itself. What is going to be missing is a viewer for the resources and one for the .NET directory, because we need first to implement an efficient and customizable tree control. Also ranges won’t be supported as long as the whole file format isn’t supported. This is due to the fact that the PE is one of the most studied and documented file formats around, hence the necessity to be very precise when calculating data ranges.

Also, soon we’ll release a demo of the Profiler. Stay tuned!

Entropy

The upcoming version 0.8.0 version of the Profiler features computation of entropy and the representation of it through a graphical plot. The algorithm used for the calculation is the one described by Ero Carrera on his blog.

When foreign data is present in a file, its entropy is automatically calculated. This is very important, because foreign data can be completely harmless and entropic analysis hugely helps evaluating the risk factor of it.

Normal PDF foreign entropy

In this case the analyzed PDF contains 0x0A separators between objects and since it contains many objects, there’s also a lot of foreign data. However, since the entropy is extremely low, it is possible to assume that the foreign data doesn’t have a purpose.

Let’s take a look at a malicious PDF with foreign data. As one can see, the entropy is very high in this case.

Malicious PDF foreign entropy

Of course, it’s also possible to calculate the entropy in any hex view of a custom range of bytes and block size through the action Data->Entropy. This is the entropy for an entire malicious PDF with a block size of 256 bytes.

Malicious PDF entropy

The encrypted malware begins at the position where the entropy raises and remains steady.

In the future the plot control will be exposed to the Python SDK so that plugin writers can use it too.

Enjoy!

Info-Tech Storage Format support

The Info-Tech Storage Format (ITSF) is the primary format that has been adopted by Microsoft for online help files since Windows 98. Due to its popularity, it has been used (and exploited) by many other third parties, mostly because of the support provided by documentation utilities like Doxygen.

With the upcoming 0.8.0 release, the Profiler comes with full compatibility for the following file extensions: CHM, CHI, CHQ, CHW, KPD.

InfoTech Storage Format support

Despite the name (Microsoft Compiled HTML Files), the image above shows the Profiler analyzing a CHM containing not only HTML, but also fonts and PDF documents. These files tend to contain a lot of information, and may require you to increase the unpack limit from the settings.

PDF object search output

In the upcoming 0.8.0 version of the Profiler it will be possible to print out the matches of PDF object searches. This comes very handy during analysis if we want to know, for instance, all values for a given key. The option can be activated in the initial configuration dialog.

PDF object search output option

In this case we’re going to search for URI keys (which specify links).

URI results

URI search has also been added as a predefined search.

Zip bomb

While the Profiler was designed for document analysis and currently has virtual memory limitations, let’s see how it performs with a Zip bomb. 🙂

A friend of mine linked me the Zip file on this page.

The file contains 16 zipped files, which again contains 16 zipped files, which again contains 16 zipped files, which again contains 16 zipped, which again contains 16 zipped files, which contain 1 file, with the size of 4.3GB.

That’s 16^5 or 1048576 files. If we try to scan it with the Profiler, it will just take endless time trying to scan all the files. It won’t crash nor exhaust memory, just take ages. But we want to analyze the file right now, so how do we do it?

It’s very easy. By default the Profiler has quite a huge nesting limit (10), we can decrease that limit from the Setup -> Limits page. The nesting limit tells the Profiler at which depth of embedding/referencing the scan should stop.

Nesting limit

In this case I have decreased it to 1, but 2 or 3 would still have been reasonable. A value of 1 means that only files at the first level will be analyzed. By inserting a value of 0, the file will be opened without any scanning of sub-files.

Zip bomb level 1

But what if we want to analyze more in depth one or more branches in the hiearchy? The nesting limit applies only to automatic analyzes, not to manual ones, which means that we can activate items and get the analysis for them (and their children).

Zip bomb manual analysis

As you can see, we’re now analyzing the Zip bomb at the fourth level of nesting. 🙂

PDF AES256 (Revision 6)

The upcoming version 0.7.9 of the Profiler features support for the still to be publicly released PDF symmetric encryption revision 6. While the PDF specifications are not yet freely available, Adobe has already started supporting the new standard.

This is part of our effort of keeping the product up-to-date with the latest standards.

Zip archives support

Among other additions, the new 0.7.8 version of the Profiler features support for Zip archives and an improved interface for displaying the file hierarchy.

Zip Archive

The supported decompression methods are Deflate and BZIP2 (more will be added). All popular encryption technologies are supported: ZipCrypto and WinZip AES. Support for the undocumented and proprietary PKWare encryption technology is still missing.

One of the handy UI improvements is the in depth risk report.

Risk tooltip

In this case the global risk signals that the calculated risk is 45% but could be more because some files could not be analyzed, since their format is not supported. This risk reporting is available both for the global risk and individual files.

Risk tooltip 2

In this case the main file “nested_crypto.zip” was decrypted but the decryption of the embedded file “test.zip” failed, because I didn’t enter the password for it. We can see that “test.zip” has not been decrypted (nor the files it contains) because of the e character next to the risk percentage. The meaning of these kind of characters is explained by the tooltip.

The Zip format covers an enourmous amount of extensions and hugely increases the usefulness of the Profiler. Enjoy! 😉

XML Indenter

With the release of the 0.7.7 we’ve bundled a new Python action particularly useful when dealing with unformatted XML.

The following is an excerpt of an embedded XML file taken from a malicious PDF document.

XML Indenter

Focusing on security, this beautifier does not try to validate the content of the document, having also the advantage of being faster than other tree-based indenters.
As a side note, this plugin is compatible with any SMGL-based such as HTML and XHTML.

MicroType Express

MicroType Express is the (optional) compression technology used by Embedded OpenType fonts. It was specifically designed to compress TrueType fonts. These fonts are generally to be found in web pages or Office documents.

Internet Explorer with EOT fonts

In this screenshot we have Internet Explorer displaying fonts download from remote. It is very easy to embed fonts in a web page.

@font-face {
    font-family: Piefont;
    font-style:  normal;
    font-weight: normal;
    src: url(PIE0.eot);
  }
@font-face {
    font-family: GS;
    font-style:  normal;
    font-weight: normal;
    src: url(GOUDYST2.eot);
  }
  @font-face {
    font-family: Garabold;
    font-style:  normal;
    font-weight: 700;
    src: url(GARAMON5.eot);
  }
  @font-face {
    font-family: Garanorm;
    font-style:  normal;
    font-weight: normal;
    src: url(GARAMON4.eot);
  }
  @font-face {
    font-family: Script;
    font-style:  normal;
    font-weight: normal;
    src: url(SCRIPTM2.eot);
  }

What happens when Internet Explorer tries to open EOT fonts is that it loads T2Embed.dll from the System32 directory.

T2Embed DLL

The job of this DLL is to convert EOT fonts back to the original OpenType format which is then parsed and displayed. Thus, EOT fonts are subject to exploits either in their MicroType Express layer or in the resulting OpenType font. In fact, lzcomp, the custom compression algorithm based on lz77 used by MicroType Express, has been exploited as a vector for remote code execution. It should be noted that the vulnerability has been reported in 2010 and the W3 submission by Microsoft of the MicroType Express standard is dated 2008. The lzcomp decompression code contained in the W3 submission does not include the patches introduced after the vulnerability was reported (I checked). So while probably few will use the code anyway, they should be careful to add safety checks in order to not include the above mentioned vulnerability in their own code.

While already with version 0.7.6 the Profiler had support for uncompressed Embedded OpenType fonts, only with the upcoming 0.7.7 version a partial support for MicroType Express has been added. I say partial because, although the embedded OpenType font gets completely decompressed, only the glyf and loca tables out of those which are deconstructed are rebuilded in order to allow the disassembling of bytecode. Tables which are not yet rebuilded are: cvt, hdmx and VDMX. The use of the T2Embed.dll for conversion was not an option, since it doesn’t fit with the Profiler safety standards.

Word doc with fonts

This is a Word Document containing Embedded OpenType fonts.:)

Compact Font Format, Type2 and OpenType

The Compact Font Format (CFont) was developed by Adobe and it is a container for one or more fonts. Although not compressed, it’s a format designed to save space as the name suggests.

Compact Font Format

The bytecode contained in CFonts is either Type1 or Type2, both very similar and supported by the Profiler, although nothing prevents from storing another type of bytecode.

OpenType

The support of this font format also improves the support for OpenType fonts, because these fonts can store glyph outlines in a CFF table, rather than in a glyf table such as TrueType fonts. CFF tables contain Compact Fonts.

PDF Fonts

In this last screenshot we can see an example of font detection inside of a PDF.