You are browsing the archive for GoodWare.

PDBs… from the the good sauce…

April 12, 2020 in GoodWare, PDB Paths

One of the early public sample clustering attempts I have ever made was a search for the username that was the most prevalent among the PDB paths extracted from my malware repository circa … 2013. Long time ago. Yup. The winner account was (unsurprisingly): ‘Administrator’.

7 years later we are seeing more PDB path research and Steve Miller at FireEye did a lot work in this space. Nick, who is one of my fav malware researchers, chipped in on the Twitter thread related to Steve’s research and pointed readers to my old blog posts, so I felt somehow obliged to follow up.


By looking at PDBs from the goodware.



Not only malware embeds the PDB paths, but also lots of goodware, that is…. drivers, installers, do-something files from your favorite or not so favorite vendor (aka it’s often a vendor that happens to be supporting your video, audio cards, as well as vendors installing lots of OEM software crappe on your laptops with a lot software pre-installed ‘out of the box’).

Still interested?

You should be… A list of good PDB paths can be easily turned into a ‘Good Yara’ repo. And that means.. you can exclude many of clean samples early as they come in by just looking at their PDB paths.

So… how these ‘good’ PDB paths look like?

Here are some stats….

D:\binaries.x86fre\SCP_WPA	50766
e:\SourceCode\AsMultiLang\AsMultiLang\release	37478
c:\CCView$\jmerchan_view_ASE_Installers\ASE_Installers\Iif2\Installer\Hdmi\Resource\Src\Release	34064
c:\CCView\jgonz2x_Staging_view\ASE_Installers\Iif2\Installer\Hdmi\Resource\Src\Debug	25642
c:\share\anarayan_latest_main\gfx_Development\SourceCUI2\igfx\TvWizIns\TVconfig\Resource\NEW_SRC	22776
c:\ccviews\atjes_L10N_ASE_Staging\ASE_Installers\Iif2\Installer\Chipset\Resource\Src\Debug	21446
e:\hdaudio\srv03\source\drivers\oem\src\wdm\audio\drivers\hdaudio\hdaudbus\azalia\objfre_wnet_x86\i386	18614
e:\hdaudio\srv03\source\drivers\oem\src\wdm\audio\drivers\hdaudio\hdaudio\objfre_wnet_x86\i386	18614
e:\hdaudio\srv03\source\drivers\oem\src\wdm\audio\drivers\hdaudio\hdaudpropshortcut\objfre_wnet_x86\i386	18614
e:\hdaudio\srv03\source\drivers\oem\src\wdm\audio\drivers\hdaudio\hdaudprop\objfre_wnet_x86\i386	18614
E:\projects 2009\DLL\AsAcpi\AsAcpi\Release	15693
c:\ccview\jgonz2_RCR1022521_view\ASE_Installers\IIF2\Installer\HDMI\Resource\SRC\Debug	15044
e:\Code\Eddy\AI Suite II\Source\AI-Suite II	11434
V:\TPMCLIENT\Bin\Win32\Release	10689
o:\BTW\btw1.2\bin\amd64	10246
G:\binaries.x86fre\SCP_WPA	10227
y:\ASE_Installers\Iif2\Installer\Hdmi\Resource\Src\Release	9940
c:\documents and settings\administrator\my documents\projects\dll\pngio\release	9856
C:\Symbols\Release	9674

This is just a top 20, and one can definitely build some Yara sigs around these. If you want the whole list DM me.

Is there a risk malware guys will re-use these? Absolutely. This is why only publish the top 20.

What about the usernames?

Looking at the stats I can pinpoint the following user accounts:

Chunyung	40752
cc4build	10161
chunyung	7822
test	5945
releng	5120
chunyung.RTDOMAIN	3905
dnandy	3520
newport10gc	3505
karl	2993
DEV	2811
tachun.cmedia	2667
SW	2618
cvcctest	2575
Test	2422
ws	2385
rkosana	2119
Administrator	2103
vyeh	1993
jim	1837
celitc	1799

Yes, it doesn’t tell us much other than indicating my ‘good’ sampleset is somehow biased toward productions of the mystical ‘Chunyung’. I have to work it out and add more diversity to this corpora… In the meantime… whatever doesn’t match these ‘good’ PDB paths is probably… a bad guy. So yeah… if you want to build some ‘goodware’ sigs out of it, please DM me and I will share the full PDB dataset with you.

In terms of the directories, the stats show us this:

D:\binaries.x86fre\SCP_WPA\	82596
e:\SourceCode\AsMultiLang\AsMultiLang\release\	69012
c:\ccviews\atjes_L10N_ASE_Staging\ASE_Installers\Iif2\Installer\Chipset\Resource\Src\Debug\	66753
c:\CCView$\jmerchan_view_ASE_Installers\ASE_Installers\Iif2\Installer\Hdmi\Resource\Src\Release\	59019
c:\CCView\jgonz2x_Staging_view\ASE_Installers\Iif2\Installer\Hdmi\Resource\Src\Debug\	52848
c:\ccview\jgonz2_RCR1022521_view\ASE_Installers\IIF2\Installer\HDMI\Resource\SRC\Debug\	51078
c:\share\anarayan_latest_main\gfx_Development\SourceCUI2\igfx\TvWizIns\TVconfig\Resource\NEW_SRC\	45916
V:\TPMCLIENT\Bin\Win32\Release\	32175
E:\8168\vc98\self\bin\x86\	29523
E:\projects 2009\DLL\AsAcpi\AsAcpi\Release\	28525
E:\8665\vc98\mfc\\src\	27055
E:\8972\vc98\self\bin\x86\	25890
e:\hdaudio\srv03\source\drivers\oem\src\wdm\audio\drivers\hdaudio\hdaudbus\azalia\objfre_wnet_x86\i386\	25555
e:\hdaudio\srv03\source\drivers\oem\src\wdm\audio\drivers\hdaudio\hdaudpropshortcut\objfre_wnet_x86\i386\	25554
e:\hdaudio\srv03\source\drivers\oem\src\wdm\audio\drivers\hdaudio\hdaudprop\objfre_wnet_x86\i386\	25554
e:\hdaudio\srv03\source\drivers\oem\src\wdm\audio\drivers\hdaudio\hdaudio\objfre_wnet_x86\i386\	25554
y:\ASE_Installers\Iif2\Installer\Hdmi\Resource\Src\Release\	24840
C:\Symbols\Release\	23829
T:\__test_sys\__outputs\NNT-SNB32-W86_andmitri\mediasdk_tags_Win7_MFTs_15.31_promoted_53672\samples\_build\Win32\Release\	21504
E:\8447\vc98\mfc\\src\	20980

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