Hello trid users,
some days ago i migrate a Windows 7 system to 10 and a HP printer does
not work afterwards. To remove failed printer driver i look at device
driver files inside inf sub directory of windows directory. Just for
interest i run trid on precompiled Windows precompiled INF. These PNF
samples are now described as "Unknown!", whereas PNF samples found on
older Windows versions are identified correctly by pnf.trid.xml.
When running tridscan on new samples in updated trid definition now
minor version byte vanish. So in front block section the first
pattern disappears. That was expressed by XML construct:
<Bytes>01</Bytes>
<Pos>0</Pos>
Furthermore the only non null patter is generated by lucky
circumstances. If stored file time is not so different you get a
pattern like
<Bytes>01</Bytes>
<Pos>31</Pos>
So in final pnf.trid.xml only some null pattern survive and in global
string section only two words are left. That are expressed by lines
like:
<String>W'I'N'D'O'W'S</String>
<String>V'E'R'S'I'O'N</String>
So no real characteristics are now contained any more in updated trid
definition file. Not surprising, because pnf.trid.xml describes the
average of different PNF versions.
Furthermore the mentioned reference URLs mentioned in pnf.trid.xml and
pnf-old.trid.xml does not exist any more.
So i look for a new one. There does not exist an official file format
specification. So i search for source header file with structure
like _PNF_HEADER. Unfortunately such information is only found on
temporarily available sites referring to leaked, older Windows
sources. In the end i used site expressed by link
<RefURL>
http://en.verysource.com/code/10350344_1/inf.h.html</RefURL>
According to that header information PNF samples start with a byte for
minor version. Often this variable has the value 1, but for newer
Windows 10 version like 18362 that value is 3 and for older builds
like 14393 that value is 2.
The second byte contains the major version number. I found value 1 for
Windows 98 and XP. For Windows Vista and newer i found value 3. I do
not know if there exist a Windows version with value 2.
So i run tridscan on samples with same major and minor version. For
Windows 98 i generate pnf-v1,1-ascii.trid.xml and refine definition.
There PNF files have version 1.1 and InfStyle has value 2, which seems to
be true in most cases except for very old inf examples found in
Windows 3.x, but for my inspected examples this is not the
case. These facts are now expressed by XML construct:
<Bytes>01010200</Bytes>
<Pos>0</Pos>
At offset PNF Flags are stored as 4 byte little endian value. Highest
mentioned flag for such older windows version has value 0x20 for
digitally signed. So 3 upper bytes are unused. That is expressed by
construct:
<Bytes>000000</Bytes>
<Pos>5</Pos>
Many values are stored as 4 byte integer. So in theory values til high
limit of 4 GiB can be used. In real examples only "low" values occur.
At offset 8 InfSubstValueListOffset is stored at 4 byte integer where
only 2 lower bytes are used. That was expressed by construct:
<Bytes>0000</Bytes>
<Pos>10</Pos>
But there is no guarantee that this always true. So i remove this
pattern and do this also for other such null pattern.
The PNF header has a size of about hundred bytes (88 for Windows
98). So any null pattern above this limit is triggered by lucky
circumstances. So i remove that patterns too.
At offset 68 variable WinDirPathOffset is stored as 4 byte little
endian integer. For my inspected sample the windir path is directly
stored after the header part. For me this seems to be logical and i
assume that this is always true. So found value has constant value
58h. That is is 88 in decimal. That is expressed by construct:
<Bytes>58000000</Bytes>
<Pos>68</Pos>
So at offset 88 the WinDirPath is stored as ASCII string. Typical
value is C:\WINDOWS, but if windows system is installed on RAM disc
also other value like X:\MININT can be found. So in general the colon
and back slash characters are always found at that position. That is
expressed by construct:
<Bytes>3A5C</Bytes>
<ASCII> : \</ASCII>
<Pos>89</Pos>
Triggered by ram disc installed variants in global strings sections
the following line vanish:
<String>WINDOWS</String>
In my first attempts the construct looks like
<Bytes>000000FD0107040000000000000000433A5C57494E444F5753</Bytes>
<ASCII> . . . . . . . . . . . . . . . C : \ W I N D O W S</ASCII>
<Pos>73</Pos>
According to source this is OsLoaderPathOffset below 0x100,
StringTableHashBucketCount 0x1fd, LanguageId 0x0407, InfSourcePathOffset
0 and OriginalInfNameOffset 0. LanguageId value 0x0407 is only true
for a german Windows. I also assume that other variables can have
other values with one exception. Often OsLoaderPathOffset is zero, but
for machine.PNF i found value 0x68 which means after the WinDirPath
OsLoaderPath like C:\ is stored. This seems to be logical. That also
means that 3 upper bytes of dword integer are always zero. That is
expressed by:
<Bytes>000000</Bytes>
<Pos>73</Pos>
Furthermore mentioned the observed characteristics in a remark line. This
first new trid definition replaces pnf-old.trid.xml.
For Windows XP i generate pnf-v1,1.trid.xml and refine
definition. Here PNF files have also version 1.1. Most samples have
short integer InfStyle value 2 but mdmchipv.PNF has value 1. So this
is here expressed by construct:
<Bytes>00</Bytes>
<Pos>3</Pos>
In Windows XP now also some of the upper undocumented bits used. In
all my inspected samples PNF flag 0x100 was set and some times
0x01000000 or 0x02000000 are set. This is now expressed by construct
<Bytes>0100</Bytes>
<Pos>5</Pos>
I do not know what this means and if this is always true. So mention
these facts in a remark line. Also the flag 0x1 value for unicoded is
always used. So in my first attempts the WinDirPath stored as UTF-16
was expressed by construct like:
<Bytes>000043003A005C00570049004E0044004F005700530000000000</Bytes>
<ASCII> . . C . : . \ . W . I . N . D . O . W . S</ASCII>
<Pos>86</Pos>
When installing windows system for example on a ram disk, then windir
path is not C:\WINDOWS any more. Then in general only the colon and
backslash part remains. This is exopressed by
<Bytes>003A005C00</Bytes>
<ASCII> . : . \ .</ASCII>
<Pos>89</Pos>
For major version 2 i found no example. For Windows vista,7 and 8.1 i
generate pnf-v3,1.trid.xml and refine definition. Here PNF files have
version 3.1. All inspected samples have short integer InfStyle value
2. In my inspected examples value unknown 0x80 value in PNF flags and
some other low bits (unicoded, has strings) are set. That was
expressed by construct:
<Bytes>01030200830000</Bytes>
<Pos>0</Pos>
When assuming that other flags combination are possible i do not rely
on PNF flags and expression now becomes
<Bytes>01030200</Bytes>
<Pos>0</Pos>
Many values are stored as 4 byte integer. So in theory values til high
limit of 4 GiB can be used. In real examples only "low" values occur.
So many null pattern also ocurr here. So i remove such patterns.
Here also the WinDirPath construct appears, but now at higher
offset 96=60h. This now becomes like
<Bytes>60000000</Bytes>
<Pos>80</Pos>
<Bytes>003A005C00</Bytes>
<ASCII> . : . \ .</ASCII>
<Pos>97</Pos>
Furtmermore the language is not only stored as short LanguageId
variable like 0407h, but afterwords an offset to language string like
en-US or de-DE is now stored.
For older Windows 10 like build 14393 generate pnf-v3,2.trid.xml and
refine definition. Here PNF files have version 3.2. Same characteristics
as for version 3.1. So i remove null patterns. PNF header now
apparently contains more fields. So offset for WinDirPath is raised by
8 bytes again and construct now looks like
<Bytes>68000000</Bytes>
<Pos>80</Pos>
<Bytes>003A005C00</Bytes>
<ASCII> . : . \ .</ASCII>
<Pos>105</Pos>
For "newer" Windows 10 like build 18362 generate pnf-v3,3.trid.xml and
refine definition. Here PNF files have version 3.3. Windows path is the
same as for version 3.2.
With the five new trid definitions all my inspected PNF samples are
now described. But i am not sure about the meaning of InfStyle, higher
PNF bit flags and additional PNF header fields in newer Windows
versions. So i apreciate for more informations from other users.
TrID definition stored in archive pnf_xml.zip. I hope that my new XML
files can be used in future version of triddefs.
With best wishes
Jörg Jenderek
