You are browsing the archive for Clustering.

Re-sauce, Part 1

April 24, 2020 in Archaeology, Clustering, File Formats ZOO, Forensic Analysis

PE Resources are like an unwanted child of malware analysis and reverse engineering. Almost no one talks about them and… this post is going to… make it worse ;).

Let’s take a large number of ‘bad’ samples, export their resource information, and do some data crunching… we now have some stats.

What are the most popular resources?

These are:

4720830   RT_ICON (3) -
4703093   RT_GROUP_ICON (14) -
3445748   RT_VERSION (16) -
2574034   RT_MANIFEST (24) -
2291058   RT_DIALOG (5) -
2022739   RT_STRING (6) -
1564623   RT_RCDATA (10) -
1193659   RT_BITMAP (2) -
1159726    'DVCLAL' -
1050941    'PACKAGEINFO' -
 931572    'MAINICON' -
 903265   RT_CURSOR (1) -
 884868   RT_GROUP_CURSOR (12) -
 557473    'BBABORT' -
 551898    'BBALL' -
 551836    'BBOK' -
 551785    'BBNO' -
 551023    'BBRETRY' -
 542886    'BBIGNORE' -
 542836    'BBHELP' -
 542834    'BBCLOSE' -
 542593    'BBYES' -
 541708    'BBCANCEL' -
 498816    'PREVIEWGLYPH' -
 497272    'DLGTEMPLATE' -
 358081   RT_MENU (4) -
 199615    'TFORM1' -
 174781   RT_ACCELERATOR (9) -

These with a RT_prefix are standard resource types defined by Microsoft, and the ones in apostrophes are strings that ‘tag’ (or ‘name’) the resources according to developer’s wishes…

Given a number of these ‘named’ ones used repeatedly (as shown by the list above) you can guess that they are somehow ‘known’, or a part of some ‘standard’ — and yup, these are primarily from Borland/Delphi/Embarcadero family of executables that include standard GUI elements from this platform. All ‘BB*’ and ‘T*’ come from this environment. Additionally ‘PACKAGEINFO’ is a resource I covered a little bit in the past – it lists all the packages the executable uses (a good IOC except no one writes malware in Delphi anymore).

Surprisingly, modern PE Viewers and Editors do not parse PE resources very well. They only show the most popular resource types, because the others are often … undocumented. I really don’t like to look at resources in hex view. We can do better.

Let’s start with these that are ‘kinda documented’.

For instance, Resource Hacker can handle some Delphi resources (e.g. forms) pretty well:

A popular ‘Typelib’ resource:

can be viewed with OleView:

The ‘Registry’ is typically an embedded ‘.reg’ file.

A ‘FOMB’ is a binary MOF that was described in this post by FireEye and can be decoded using bmfdec.

What about the others?

And this is where it gets really difficult…

Looking at resources embedded in Windows 10 exe, dll, ocx files one can very quickly build a list of more or less enigmatically-looking resource names:

  • AVI
  • CERT
  • DGML
  • DUI
  • FONT
  • GIF
  • HTML
  • HWB
  • IBC
  • ICON
  • JPEG
  • JS
  • JSON
  • MENU
  • MUI
  • PNG
  • TEXT
  • WAVE
  • XML
  • XSD

Yup. Some are easy to handle (just by looking at their name e.g. AVI, BITMAP, XML), but… this is just Windows 10.

Time will tell if we will ever see a PE editor/viewer that can handle all of, or at least most of these well.

In the meantime…

Resources is something you may want to look at more closely. Starting today.


Because of this guy:

I got it from resources of Norton SecureWorks circa 2002-2003. Do you even remember this software existed?

One of cool side-effects of poking around in many resources is coming across weird, unusual strings, texts, images, movies, you name it. You will find developer pictures that were not meant for general public, ‘tagging’ images with names of developers of project managers, jokes, and whatever else. Yes, there is cheezy, there is porn, there are obscenities, there are also Easter Eggs.

If you want to start building your own collection, it couldn’t be easier…

You can simply use:

  • 7z l <filename> .rsrc
    • to list all the resources of a <filename>
  • 7z x <filename> .rsrc’
    • to extract them.

And then start data crunching:

  • Icons are interesting, especially if re-used for malicious purposes (e.g. Adobe, Microsoft) –> there are existing yara sigs for these!
  • Manifest may include references to other executables/DLLs loaded
  • Manifest may also include references to rights required for running the executable (e.g. look for level=”requireAdministrator”)
  • Language information may be helpful with attribution (beware of false flags)
  • Version Information lists lots of interesting information that can be co-related with the information extracted from certificates / signatures, if present
  • Delphi resources are fairly well documented and can be extracted, especially the aforementioned package names — can help to at least cluster samples as per the modules used (may sometimes highlight similar families, plus good for yara sigs)
  • Everything else should be extracted and checked against typical file types/magic:
    • BMP
    • PNG
    • GIF
    • JPG
    • AVI
    • Wav
    • Rtf
    • Ico
    • Cur
    • PE files
    • LE files (older version of MZ executables)
    • MZ files (yup, plain DOS)
    • UTF8/Unicode BOMs
    • Office files
    • etc.

Resources are a very important metadata source for analysts. If you are lucky you may not only get the visuals, but also timestamps (e.g. in Delphi executables).

Be err… resourceful.

Tag me if you can… driver

April 9, 2020 in Clustering, Drivers, GoodWare

Developers of kernel drivers rely on these two memory allocation functions:

The Tag parameter that these 2 functions take is defined as:

The tag is a non-zero character literal of one to to four characters delimited by single quotation marks (for example, ‘Tag1’). The string is usually specified in reverse order (for example, ‘1gaT’). Each ASCII character in the tag must be a value in the range 0x20 (space) to 0x7E (tilde). Each allocation code path should use a unique pool tag to help debuggers and verifiers identify the code path.

While I am not a kernel mode driver developer, and somehow kernel mode was never even that interesting to me, I did a fair amount of code reading over the years… primarily focused on snippets from Microsoft Documentation (DDK/WDM), and rootkits’ source codes. And if there was one thing that stuck with me after reading all this code good/bad-ness… it was that most of the developers rarely changed the tags used by these two memory allocation functions from the tags used in Microsoft samples – that is, ‘Ddk ‘, and ‘Wdm ‘.

So… assuming everyone does it… I went on an adventure to find out what actual tags are being used out there apart from these memorable two.

To address the question I looked at the corpora of 60K+ signed drivers for both 32- and 64- bit architectures, did some automation, data crunching, and eventually came up with a list of which exempt is presented below. And in fairness, I did hope I can find some interesting, playful tags, but reality was actually pretty boring…

So, without further ado, these are the top 20 tags I found:

  • 6D437A41 107843 AzCm
  • 774E6350 65888 PcNw
  • 42434541 36356 AECB
  • 6D446266 30262 fbDm
  • 7A67554D 25411 MUgz
  • 56727444 24846 DtrV
  • 64417A41 23406 AzAd
  • 206D6457 20588 Wdm
  • 7453764E 20228 NvSt
  • 4D444351 15442 QCDM
  • 53537442 15104 BtSS
  • 6C4C7A41 14364 AzLl
  • 6D457674 13254 tvEm
  • 64577A41 12498 AzWd
  • 4D6253 11940 SbM
  • 65487A41 11662 AzHe
  • 6D507A41 11660 AzPm
  • 484C764E 11410 NvLH
  • 34387A41 10561 Az84
  • 5A41564E 9883 NVAZ

Yup. Boooooring!

‘Wdm ‘ is there on position 8, and the ‘Ddk ‘ was on position 40 (not shown on the list above).

Booooooring intensifies.

Unhappy, after not finding any groundbreaking results, I turned into the ‘scandalous’ area. I skimmed the list looking for obscenities, and lo and behold, I quickly discovered a driver that used the following tags:


Hooray. Thank you ‘O&O Software GmbH’. Finally this post has some meaning after all.

The hashes you are thinking of now are:

  • MD5 : A516F6C7738BDB447289A90824480D65
  • SHA1 : 692CF950D99E4DF33AF1A8EB29831692CB31FC9D
  • SHA256: 3DCD8EB2FE16232DDB7DE1EBFEE791E0FE29F13B0C75D704A9972E19E697B7C3

But it was still booooooring.

Then the other thing caught my eye. I was certainly perplexed by the findings that suggested a lot of tags are being reused by more than one, two companies. For instance, ‘AzCm’, ‘PcNw’, ‘AECB’, ‘MUgz’, ‘AzAd’, ‘QCDM’, ‘BtSS’, ‘AzWd’, and many more. I won’t list the companies, because I don’t want to get sued, but it is an interesting conundrum indeed. How come all of these companies use that particular tag, huh? The other striking discovery was that there is a lot of vendor-specific drivers that are re-using these tags and are at the same time signed by the ‘Microsoft Windows Hardware Compatibility Publisher’. I guess the latter phenomenon can be attributed to the Windows Hardware Compatibility Program (anyone knows?).

Back to these shared tags though… Is it possible that vendors either share code, get access to it via acquisition, or hire the same third party company to write their drivers?

This is a very important question…

If the answer is YES, then the same memory tags, code habits, and … bugs… propagate across a whole bunch of drivers. And this leads to a question: is hfiref0x right? His research is pretty much killing it when it comes to buggy driver analysis. As he is constantly, continuously and consistently pointing out…. the copypasta in a driver industry is a a HUGE driver (pun intended) for many drivers exhibiting the same buggy ‘features’…

Perhaps it’s time I run my corpora via the ScrewedDrivers


After I posted it, I got some feedback on Twitter which I am posting below (Thx @attrc!)

After cross-referencing with the ‘pooltag.txt’ file from the latest win10 sdk I I got the following result:

  • 6D437A41 107843 AzCm AzCm HD Audio Class Driver (AzCommon) – HDAudio.sys
  • 774E6350 65888 PcNw PcNw WDM audio stuff –
  • 42434541 36356 AECB #N/A #N/A
  • 6D446266 30262 fbDm #N/A #N/A
  • 7A67554D 25411 MUgz #N/A #N/A
  • 56727444 24846 DtrV #N/A #N/A
  • 64417A41 23406 AzAd AzAd HD Audio Class Driver (AzPcAudDev) – HDAudio.sys
  • 206D6457 20588 Wdm Wdm WDM –
  • 7453764E 20228 NvSt #N/A #N/A
  • 4D444351 15442 QCDM #N/A #N/A
  • 53537442 15104 BtSS #N/A #N/A
  • 6C4C7A41 14364 AzLl #N/A #N/A
  • 6D457674 13254 tvEm #N/A #N/A
  • 64577A41 12498 AzWd AzWd HD Audio Class Driver (AzWidget) – HDAudio.sys
  • 4D6253 11940 SbM #N/A #N/A
  • 65487A41 11662 AzHe #N/A #N/A
  • 6D507A41 11660 AzPm #N/A #N/A
  • 484C764E 11410 NvLH NvLH nVidia video driver –
  • 34387A41 10561 Az84 #N/A #N/A
  • 5A41564E 9883 NVAZ #N/A #N/A