Tag me if you can… driver

Posted on by

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:

and

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…

Update

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