Profiler 2.9.2 – Windows 10 Heap

The version 2.9.2 of Profiler is out with two improvements. The first one, is more or less a rewrite of the CCITTFax decoder for PDFs, which has now been tested against more samples.

The second improvement is the addition of support for the new heap introduced in Windows 10.

This removes the limitation mentioned previously of heap parsing regarding certain Windows 10 processes such as: smss.exe, csrss.exe, services.exe, lsass.exe, svchost.exe, MicrosoftEdgeC, etc.

As with the older NT heap we use an aggressive approach to rebuild the Windows 10 heap as best as we can even if there are missing pages.

The schema below shows the number of chunks found using an aggressive approach versus a soft one in a Win10 x64 image.

Heap & File Carving

Along with the newly released 2.9 version of Profiler Advanced, we have improved support for memory images.

Before going into the main topics of this post, it is worth mentioning that loading and scanning times have been drastically improved for memory images. Apart from the important internal optimizations, the user is now given the choice of scanning or not the files in memory.

If the user chooses not to scan the files in memory right away (they are still scanned once individually opened in the UI), the loading process of the memory image takes only a few seconds if that.

One of the main news in 2.9 is the support for heap parsing for all Windows versions from Windows XP to Windows 10. The only limitation is that we don’t yet support the new heap type found in Metro/Modern applications. This new type of heap can also be found in certain Windows 10 processes such as: smss.exe, csrss.exe, services.exe, lsass.exe, svchost.exe, MicrosoftEdgeC, etc.

The heap of every process can be inspected in the UI.

It’s not trivial to parse a heap which might also be corrupted because of paged out memory regions. We put effort into parsing what is available.

You might wonder why the effort of parsing the heap in the first place. The main reason was due to a new feature introduced in Profiler 2.9, namely file identification in memory regions. Since we anyway wanted to identify files loaded in memory regions, we thought it was a good idea to try to identify files in the heap as well. Hence, the user can now enable file identification in memory regions and heap.

Of course, the user can inspect all the identified files in the UI. This for instance is an image found in the heap of the dwm process.

The user may also choose to dump all identified files to a specific folder.

The dump output is divided into directories, one for each process.

Each process contains one or all of the following directories and an info.txt file.

The info.txt file contains a list of dumped files and their respective names in the Profiler UI, along with possible errors:

We’ll further improve this feature in the next time, so stay tuned!

Windows Memory Forensics: Close to Release

We’re extremely proud to announce that the upcoming 2.8 version of Profiler Advanced comes with full-fledged support for raw Windows memory images! As few of our users might remember a two years old demo about this topic. Thanks to the work of the past months of our team, we could finalize that idea into a real product.

This is a hex view showing the user space regions of a process on Win8 x64.

We currently support WinXP to Win10 both x86 and x64. And, of course, the support for Windows memory forensics is available on all platforms which Profiler runs on: Windows, OS X and Linux.

Opening and exploring a raw memory image in Profiler is extremely simple. The first step is to open the memory image from the UI.

Profiler automatically tries to identify the correct Windows version and the user is presented with an options dialog, which allows modifications to the default parameters.

If the user decides to modify the parameters, he can verify the correctness of the results by exploring processes and other parts.

Once the users is satisfied with the configuration, he may press “OK” and let Profiler analyse the image. Once the detection and analysis of embedded modules and files is finished, the user is presented with the workspace.

In the workspace the user can explore executables loaded in memory (Wow64 is supported).

He may explore the PEB of a process.

Or its VAD tree.

The System Service Descriptor Table (SSDT).

The Processor Control Block (KPRCB).

And of course explore kernel memory and drivers as well.

As usual, once the initial analysis is finished, everything can be saved into a project along with notes, bookmarks, layouts and so on. Loading a memory image from a project is immediate and saves a lot of time when analysing the same memory image multiple times.

This is just the beginning: we have many ideas and expect to release more frequently than in the past. I’m sure, we’ll be able to pleasantly surprise you!