What regex strings can distinguish files containing "PE null null L" from "PE null null d"

I need a quick and easy way to know how many dlls are 32-bit and how many are 64-bit in a given directory. I was about to write a PowerShell script when I thought of a much simpler solution. I've shown below that my idea can work but I need a little regex help to make it work properly.

It has been demonstrated that a dll file can be opened in Notepad to reveal the bitness (32 or 64) simply by checking the character after the first "PE". The letters "L" and "d" imply 32-bit and 64-bit respectively reference. Notepad++ or a hex editor will more accurately show there are actually 2 null characters between the "PE" and the other character as shown in the image below copied from Notepad++.

Unfortunately some of my directories contain hundreds of dlls so it's not practical to open them one at a time with Notepad or any other utility. There are, however powerful "grep-capable" file search utilities that can search a directory for files containing a specified search string. Moreover, some of these can do regular expression (regex) searches. Since I know the unique strings that differentiate 32-bit and 64bit dlls (shown above), such a file search utility should be able to quickly inventory the types of dlls in any directory. The best such file search utility in my opinion is grepWin which can be downloaded and installed for free.

My first attempt was the regex search string ".PE("\x00")*" which can be broken down as follows.

$break downs of regex string ".PE("\x00")*"$

The image below shows results of a search done using grepWin and the search string ".PE("\x00")*" for a specified directory that had 276 dll files in it. It shows that 276 of the 276 dlls found contained "PE" followed by multiple null characters. It also shows that actually thousands of matches were found. This is because the regex search continued after the first match and found many more matches in larger files that inevitably appear "randomly".

The table below shows search results from regex strings "PE.{2}L" and "PE.{2}d" proposed by O-O-O. These search strings find all the files but unfortunately some of the dll files are being counted twice because the sum of the 32-bit and 64-bit dlls exceeds the total number of dll files in the directory.

The screen shots below of the search results using "PE.{2}L" and "PE.{2}d" show that the matches exceed the number of files found meaning that the regex searches are going beyond the first match.

So I only need to know how to modify these regex search strings to stop searching 3 characters after the first "PE" is found. I know this can be done using the ".*?" modifiers but I haven't been able to get it to work. Here is my question.

• How can these search strings be modified to stop reading 3 characters after the first "PE" is found?

Any regex search strings can be verified by searching any directory of dlls with grepWin. To be correct, the search strings must produce an equal number of matches as files unlike the examples shown above. This will verify that the search stopped after the first match was found.

Solution

This can't be true:

The regex .PE("\x00")* would search for:
1. any character (Why at all? To exclude finding it right with the file's start?)
2. the character P
3. the character E
4. the group of:
  1. the character "
  2. the character corresponding to the byte value 00
  3. the character "
  ...as per * with an amount of matchings from never to countless (Why not wanting exactly 2?)
Wouldn't it be better to search for PE\x00\x00? Unless grepWin comes with its own flavor of regular expressions where quotation marks in groups have a special meaning. But I highly doubt that.
The regexes PE.{2}L and PE.{2}d are like phrases that nobody would use. Why not writing PE..L straight away?

From a technical point of view

We can further restrict a regular expression to not overly match too many false positives and to not ignore things we should also check (it helps knowing how a Portable Executable's layout looks like):

Each executable starts with a DOS header, which is always 64 bytes long and almost always starts with MZ (in rare/historical cases also ZM or NE, but not for our case).
The NT header always starts with PE\0\0 (or in hexadecimal 50 45 00 00, or in regex PE\x00\x00), which is then followed by either \x64\x86 (for 64 bit) or \x4c\x01 (for 32 bit). This header can start much later, but we can safely assume to find it within the first 2048 bytes of the file (most likely after 240 bytes already).

Also 18 bytes later we have most likely the bytes \x0b\x01 or \x0b\x02 (or in rare cases \x07\x01).

The better regex

For x64 (64 bit) search for ^MZ.{62,2046}PE\x00\x00\x64\x86.{18}\x0b[\x01\x02] and
for x86 (32 bit) search for ^MZ.{62,2046}PE\x00\x00\x4c\x01.{18}\x0b[\x01\x02].

If your target software crashes (although it praises its regex support, like grepWin) then

either omit matching the DOS header entirely (removing ^MZ.{62,2046}
or try reducing the repetition to a smaller one, f.e. {62,280}.

Explanation:

starting at the begin of the file (actually only the start of a "line")
characters M and Z (Mark Zbikowski)
any character for at least 62 times, but at max 2046 times (a text editor like Notepad++ might complain that our regex would be too complex, that's why we also define a maximum)
characters P and E (Portable Executable)
bytes 00 00
the CPU architecture:
- bytes \x64\x86 for 64 bit (AMD), or
- bytes \x4c\x01 for 32 bit (Intel 386 or later).
Don't rely on opticals only (d and L), because then you ignore half of the value and just risk more false positives).
any character for exactly 18 times
byte 0b
either byte 01 or 02

Successfully tested

with Notepad++ 8.4.8 x64 (make sure to tick that . matches newline)
on C:\Windows\System32\quartz.dll
using Windows 7 x64 (so the DLL should be 64 bit):

Notepad++ regex matching DOS and NT headers

The big advantage here is that this regex most likely only matches once instead of multiple times, especially in DLLs. However, since executables have no "end" mark they can carry any format of data afterwards. Unbound to the intention (good = self extracting archives, bad = viruses) there's hardly a way to exclude those - if we're lucky our ^ helps us.