Hello trid users,
Some days ago i run the cleaning tool czkawka found on
https://qarmin.github.io/czkawka/. One menu item concerns bad
extensions. After running tool i looked in saved file list
results_bad_extensions.txt for bad extension examples.
One listed extension is ARN. These files were generated by autorun tools
from Microsoft Sysinternals suite on my systems. So i run trid utility on my
ARN examples.
Many especially older are described correctly as "Sysinternals Autoruns
data" by arn-autoruns.trid.xml. Some middle aged examples ( like
WIN8-27Mai2021.arn and WIN8-4Dez2019.arn) are described as "Unknown!" (See
appended output/trid-v-old.txt)
For comparison reason i check these examples by file command utility. When
running file command (version 5.43) here all ARN examples are not recognized
and only described as data (See appended output/file-5.43.txt). A newer
patched file command describes all these examples as "Microsoft sysinternals
AutoRuns data" (See appended output/file.tmp) and with mime type
application/x-ms-arn (See appended output/file-i.tmp).
For comparison reason i also run the file format identification utility
DROID ( See
https://sourceforge.net/projects/droid/). This does not
recognize the ARN examples.
After running tridscan to update definition arn-autoruns.trid.xml i looked
what has changed and why. The second XML construct looked like:
<Pattern>
<Bytes>424D7E00</Bytes>
<ASCII> B M ~</ASCII>
<Pos>28</Pos>
</Pattern>
This now becomes like:
<Pattern>
<Bytes>424D</Bytes>
<ASCII> B M</ASCII>
<Pos>28</Pos>
</Pattern>
<Pattern>
<Bytes>00</Bytes>
<Pos>31</Pos>
</Pattern>
When extracting parts with starting BM string (for example by dd command) we
get BMP PC bitmaps. So i mention this recognized facts about embedded BMP
inside a remark line. Unfortunately i find not something like a file format
specification for ARN samples. But a least there exist an official usage
page for autoruns tools. So this extracted images can be further inspected
by TrID of file command (patched for embedded BMP images). These images can
also be viewed by graphic tools like XnView or IrfanView. Apparently these
bitmaps are icons of listed programs, where apparently first embedded bitmap
is "lowest" resolution and color depth variant followed by bigger program
icon bitmap. Depending on resolution and color depth the image size and also
the BMP size grows. That information is shown for example by file commando
as cbSize value. For recognized samples this value was 126 ( hexadecimal
7E). For not detected samples this value was 158 ( hexadecimal 9E). That
value is stored 4 byte little integer behind BM magic. So that is the reason
why above patterns has changed. What i do not understand is the following
When first image is "little" than also the cbSize should be "low". So the
upper bytes of 4 bytes should be nil. So i would also expect to see also a
construct like:
<Pattern>
<Bytes>0000</Bytes>
<Pos>32</Pos>
</Pattern>
The original definition does not contain nil pattern at that offset. When
definition is based on 7E-cbSize samples then we are able to calculate the
offset of the possible second image. That would then be offset 0x9a for
second bitmap as shown by patched file command. So at that offset the next
BM string part should appear. So i think that the original definition maybe
was "cleaned too much".
With the updated trid definition now all my old ARN examples are described
(see appended output/trid-v-new.txt). TrID definition and output are stored
in archive arn_old.zip. I hope that my XML file can be used in future
version of triddefs.
Not all sysinternal ARN recognized. This is true for examples from middle of
year 2021. Apparently the described file format is only produced by old
autrun versions. The highest old version i got was 13.100. The ARN examples
produced by version 14.0 and 14.09 use a completely other file format. So
apparently the described only applies to version number til 13. And from
version 14 an other format is used. I will try to handle this in a future
session.
With best wishes
Jörg Jenderek
