Hello trid users,
some weeks ago i handled Windows Policy Administrative Template with file
name extension ADM. These contains instructions that in the end are stored
in the Windows registry files.
So i checked all my Windows registry examples again. The registry examples
with POW file name extension are Microsoft Windows power schema. These
examples can be exported or imported by Microsoft command line power
configuration tool POWERCFG.EXE.
When i run TrID with triddefs.trd definition from 8 September 2021 on such
examples these are described correct but unspecific like "Windows NT
Registry Hive (generic)" by definition hiv.trid.xml (see appended
output/trid-v-old.txt).
For comparison reason i also run the file utility (version 5.40). This
describes the examples in similar way as "MS Windows registry file, NT/2000
or above", but classification with file name extension and mime type is
missing or generic. (see appended output/file-5.40.txt).
When i run a patched file command according to unofficial documentation,
then 3 examples are described with sub type "backup or power scheme". (see
appended output/file.tmp).
I also downloaded the XML definitions and extract 7 hiv definitions. These
are:
hiv-95.trid.xml
hiv-log1.trid.xml
hiv-log2.trid.xml
hiv-log6.trid.xml
hiv-normal.trid.xml
hiv-sav.trid.xml
hiv.trid.xml
When i rebuild TRD definition based on these 7 XML examples and run TrID i
get more identifications. All examples are now described with higher
preference as "Windows NT Registry Hive (primary)" by hiv-normal.trid.xml.
Three examples (maximal.pow MyPower.pow powerscheme2.pow) are described
correctly ( SAV or POW file name extension) as "Windows NT Registry Hive
(SAV/POW)" by hiv-sav.trid.xml (see appended output/trid-v-xml.txt)
That are the same as identified by patched file command. How is this
done. According to documentation from offset 48 til 111 64 bytes hold last
part full file name encoded as UTF-16LE. This is shown by patched file
command. Unfortunately in some examples there only nil bytes are found. This
was found for backup copies of registry parts with SAV file name extension
and in exported power scheme profiles. So i assumed that this always true
but obviously i was wrong. So i found also 4 power examples (high.pow
Energiesparmodus.pow optimal.pow PowerScheme1.pow ) which contain such
embedded file name. Unfortunately i do not know on which conditions this
depends on. I tried to create such examples but on 64-bit Windows 8 and 10 i
get again the nil variants. Later i found an explanation. When created for
the first time i get nil variant with sequence number 1 ( offset 4 and
8). When i load the structure sequence number gets raised up to 2 and i get
file name part. Because of access problems i later was successful to change
such registry part by Sysinternal command like:
PsExec.exe -i -d -s %windir%\regedit.exe
Now after changing some values i get sequence number 3 in test4.pow.
And of course you get no information from Microsoft. This company is still
not able to mention the simple fact that exported power profiles use the
registry format and internals of the registry of course are not
mentioned. Like in the climate catastrophe i believe this company will
vanish or shrink like IBM when their leading chiefs continue the current
course.
So i generate a definition variant hiv-pow.trid.xml for such Power profiles
with embedded file names. in my first examples sequence number was 2. That
together with starting magic this was expressed by XML construct like:
<Pattern>
<Bytes>726567660200000002000000</Bytes>
<ASCII> r e g f</ASCII>
<Pos>0</Pos>
</Pattern>
After considering more examples like test4.pow with sequence number 3 this
has become like:
<Pattern>
<Bytes>72656766</Bytes>
<ASCII> r e g f</ASCII>
<Pos>0</Pos>
</Pattern>
<Pattern>
<Bytes>000000</Bytes>
<Pos>5</Pos>
</Pattern>
<Pattern>
<Bytes>000000</Bytes>
<Pos>9</Pos>
</Pattern>
So with higher sequence numbers this must be expressed by surviving XML
construct like:
<Pattern>
<Bytes>72656766</Bytes>
<ASCII> r e g f</ASCII>
<Pos>0</Pos>
</Pattern>
Second XML construct looks like:
<Pattern>
<Bytes>01010000000300000000000000010000002000000000</Bytes>
<Pos>19</Pos>
</Pattern>
At offset 12 til 19 the modification file time is stored inside 8 bytes. If
the times of examples are not too different i got same value 01 at offset
19. So for more examples especially in the future this will vanish.
At offset 20 the major version is stored as 4 byte little endian
integer. This is 1 from Windows NT til 10.
At offset 24 the minor version is stored as 4 byte little endian
integer. This is often 3 from Windows NT 4 til 10, but can be also 4,5 or 6
in some newer Windows versions. In may inspected examples this complete
version was always 1.3.
At offset 28 the file type is stored as 4 byte little endian integer. 0
means primary type and unequal values (1,2,6) are used for transaction
registry ( with additional file name extensions LOG LOG1 LOG2).
At offset 32 the file format is stored as 4 byte little endian integer. 1
means direct memory load. This was true for all my examples.
At offset 36 the root key offset is stored as 4 byte little endian
integer. In my examples this was always 20h.
At offset 40 the Hive bins data size is stored as 4 byte little endian
integer. in my examples i found 1000 3000. The hive bin size is multiple of
4096 bytes (100h). So the lower byte at offset 40 is always 0.
So with all available modification file times these observations are now
expressed by updated second XML construct:
<Pattern>
<Bytes>010000000300000000000000010000002000000000</Bytes>
<Pos>20</Pos>
</Pattern>
Third XML construct looks like:
<Pattern>
<Bytes>000001000000</Bytes>
<Pos>42</Pos>
</Pattern>
Because the hive bins data size was "low" the 2 upper bytes were nil, but in
theory bigger examples my exist. Than these 2 nil bytes vanish.
At offset 44 the Clustering factor is stored as 4 byte little endian
integer. In my examples this value was always 1.That means sector size 512.
Assuming also bigger hive sizes third XML construct now becomes like:
<Pattern>
<Bytes>01000000</Bytes>
<Pos>44</Pos>
</Pattern>
At offset 48 til 111 64 bytes hold last part full file name encoded as
UTF-16LE. If the names are ASCII like then at the odd offsets appear nil
bytes. That is expressed by short nil XML constructs like:
<Pattern>
<Bytes>00</Bytes>
<Pos>49</Pos>
</Pattern>
...
<Pattern>
<Bytes>000000</Bytes>
<Pos>109</Pos>
</Pattern>
Assuming that also exotic characters like Chinese are possible i delete
these patterns and just keep a trailing nil character expressed by XML
construct like:
<Pattern>
<Bytes>0000</Bytes>
<Pos>110</Pos>
</Pattern>
At offset 112 and 128 the RmId and LogId GUIDs with 16 bytes are
stored. Apparently by lucky circumstances in the examples the used GUID are
not too different. So value 11 appear in all samples at fixed
positions. That was expressed by 2 XML constructs like:
<Pattern>
<Bytes>11</Bytes>
<Pos>119</Pos>
</Pattern>
<Pattern>
<Bytes>11</Bytes>
<Pos>135</Pos>
</Pattern>
Assuming that also other different GUID can be used here these 2 constructs
vanish.
At offset 144 the bit mask flags are stored as 4 byte little endian
integer. In my examples this was always 0. This is expressed by XML
construct like:
<Pattern>
<Bytes>00000000</Bytes>
<Pos>144</Pos>
</Pattern>
At offset 148 til 163 the TmId GUID with 16 bytes is stored. Apparently by
lucky circumstances in the examples the used GUID are not too different. So
value 11 appear again in all samples at fixed positions. That was expressed
by XML construct like:
<Pattern>
<Bytes>11</Bytes>
<Pos>155</Pos>
</Pattern>
Assuming that also other different GUID can be used here this construct
vanish.
At offset 164 a GUID signature is stored as 4 byte. According to
documentation that expressed as sting look like rmtm. That is expressed by
XML construct like:
<Pattern>
<Bytes>726D746D</Bytes>
<ASCII> r m t m</ASCII>
<Pos>164</Pos>
</Pattern>
At offset 168 til 175 the modification file time is stored inside 8
bytes. If the times of examples are not too different i got same value D701
at offset 174. So for more examples especially in the future this will
vanish.
Afterwards from offset 176 til 507 332 bytes are declared as
"reserved". These bytes seem to be nil. So with other "reorganized" time
stamps this should be expressed by XML construct like:
<Bytes>000000000000000000000000000000000000000000000000000000000000000000000000...
<Pos>176</Pos>
At offset 512 a XOR-32 checksum of the previous bytes is stored inside 4
bytes. So here values are different in examples.
Afterwards from offset 512 til 2047 1536 bytes are declared as
"reserved". These bytes seem to be nil. So this is expressed by XML
construct like:
<Bytes>0000000000000000000000000000000000000000000000000000000000000000...
<Pos>512</Pos>
To understand what is characteristic it is probably the best way to load
such POW hives and then export structures in human readable form as REG and
TXT file. One main key is GUID 245d8541-3943-4422-b025-13a784f679b7. Ah that
is the Power Setting GUID or also called "power plan type". This key
contains dword variables with names ACSettingIndex and DCSettingIndex. This
ware expressed inside global section by 3 lines like:
<String>$'''245D8541-3943-4422-B025-13A784F679B7</String>
<String>ACSETTINGINDEX</String>
<String>DCSETTINGINDEX</String>
So these three lines seems to be the specific characteristics for POW hives.
The Power Setting GUID contains also string variables with names
FriendlyName and Description. This is expressed inside global string section
by lines like:
<String>FRIENDLYNAME</String>
<String>DESCRIPTION</String>
In my first attempts in global string section i get lines like:
<String>.'P'O'W</String>
<String>T'E'M</String>
The first line was obviously triggered by samples with embedded file names
with ".POW" extension. The second lines is probably trigger by exporting few
examples in same temporarily directory with name like TEMP. So after running
tridscan on nil name variants and in other directories this has become like:
<String>P'O'W</String>
When creating power profiles i often have choose names like
MyPowerScheme. This description text is stored as value inside variable
FriendlyName. So i create examples like test4.pow and test_5.pow with
different names like TEST4 and TEST_5. After running tridscan with these 2
examples the above line vanish.
With the new variant now all my Power configurations are recognized with
embedded file name and also with out that ( see appended
trid-v-new.txt). TrID definition and output are stored in archive pow.zip. I
hope that the XML file can be used in future version of triddefs.
After considering the procedure of generating that trid definition i believe
that is also possible to generate specific definitions at least for BCD (Boot
Configuration Data) and WFW (Windows Fire Wall). I will try to do that in a
future session.
With best wishes
Jörg Jenderek
