[File] [PATCH] Magdir/windows MS Windows crash dump- wrong details + extension
Christos Zoulas
christos at zoulas.com
Mon May 15 16:47:34 UTC 2023
Committed, thanks!
christos
> On May 13, 2023, at 12:43 PM, Jörg Jenderek <joerg.jen.der.ek at gmx.net> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
>
> Some weeks ago i send patch for X-Window screen dump image. Sometimes
> the file name suffix dmp is used. For control reason i looked for
> other file formats with that suffix. That suffix is also used for
> Microsoft Windows crash dumps.
>
> When running file command version 5.44 and newer on such DMP samples
> i get an at first glance not bad looking output like:
> 043022-18703-01.dmp: MS Windows 64bit crash dump
> , 8341923 pages
> 050322-24890-01.dmp: MS Windows 64bit crash dump
> , 3142425 pages
> MEMORY-full.DMP: MS Windows 64bit crash dump
> , 4992030524978970960 pages
> MEMORY.DMP: MS Windows 64bit crash dump
> , 4992030524978970960 pages
> Mini111013-01.dmp: MS Windows 32bit crash dump
> , PAE
> , 1162297680 pages
>
> With option -i only generic application/octet-stream and with
> option --extension only ??? is displayed.
>
> For comparison reason i run the file format identification utility
> TrID ( See https://mark0.net/soft-trid-e.html). The 64-bit samples
> are described with highest priority as "Windows 64bit Memory Dump" by
> dmp-64.trid.xml. The 32-bit samples are described with highest
> priority as "Windows memory dump" by dmp.trid.xml (See appended
> trid-v-dmp.txt.gz).
>
> For comparison reason i also run the file format identification
> utility DROID ( See https://sourceforge.net/projects/droid/).
> Here my examples are not recognized.
>
> The mentioned web site does not exist any more. So i changed it to an
> archived variant. In the end i found and used win_dump_defs.h
> C-header file of qemu. That is expressed inside Magdir/windows by
> comment lines like:
> # https://web.archive.org/web/20101125060849/
> # https://computer.forensikblog.de/
> # en/2008/02/64bit_magic.html
> # Reference: http://mark0.net/download/triddefs_xml.7z
> # defs/d/dmp.trid.xml
> # https://gitlab.com/qemu-project/qemu/-/blob/master/
> # include/qemu/win_dump_defs.h
>
> In current Magdir/windows the description starts by lines like:
> 0 string PAGE
>> 4 string DUMP MS Windows 32bit crash dump
>>> 0x05c byte 0 \b, no PAE
>>> 0x05c byte 1 \b, PAE
>>> 0xf88 lelong 1 \b, full dump
>>> 0xf88 lelong 2 \b, kernel dump
>>> 0xf88 lelong 3 \b, small dump
>>> 0x068 lelong x \b, %d pages
>> 4 string DU64 MS Windows 64bit crash dump
>>> 0xf98 lelong 1 \b, full dump
>
> The first test looks for string PAGE (called char Signature[4] in
> header file). Then the second test afterwards look for string DUMP or
> DU64 for 64-bit variant (called char ValidDump[4] in header file).
> For the 64 bit variant the dump type should be printed by following
> lines like:
>>> 0xf98 lelong 1 \b, full dump
>>> 0xf98 lelong 2 \b, kernel dump
>>> 0xf98 lelong 3 \b, small dump
> But these lines are false! That is not visible at first glance. In
> the advanced system settings GUI on Windows, i changed the conditions
> but i get no output here. So first i replaced/added a line like:
>>> 0xf98 ulelong x \b, DumpType %#x
> Then i get on Windows 8/10/11 3 different values:
> value german english
> 4 Kleines Speicherabbild (256 KB) small
> 5 vollständiges Speicherabbild full
> 6 Kernelspeicherabbild kernel
> Then i count variables and length according to c-header file.
> According to that at offset 3992 (=0xf98) the variable uint32_t
> DumpType is stored. So far as i can see that must be expressed by
> lines like:
>>> 0xf98 ulelong x \b,
>>>> 0xf98 lelong 5 full dump
>>>> 0xf98 lelong 6 kernel dump
>>>> 0xf98 lelong 4 small dump
>>>> 0xf98 default x DumpType
>>>>> 0xf98 ulelong x (%#x)
> Just in case that more than 3 observed cases occur print DumpType
> with hexadecimal value. I tried to understand why the dump types are
> reported wrong. On server learn.microsoft.com i found a page with
> Overview of memory dump file options for Windows. There the current
> used values are listed. But these values are used for variable
> CrashDumpEnabled inside Windows registry. There is not written that
> these values are stored inside crash dumps itself. So i add the other
> fields of header. Some maybe are not so interesting to i add such
> fields as comment lines. After verifying by mentioned tools i show
> some interesting facts. The version (with major and minor version)
> is shown by lines like:
>>> 8 ulelong x \b, version %u
>>> 12 ulelong x \b.%u
> So for major version i get value like 15 and for minor version i get
> values like 9600 19041 22621. This depends on or described the used
> windows system.
> The number of processors is shown by variable NumberProcessors via
> line like:
>>> 52 ulelong x \b, %u processors
> So here i get values like 2 or 4.
> For 64-bit branch the MachineImageType variable value is always 8664
> hexadecimal. So this just an additional hint for correct
> interpretation of fields by line like:
>>> 48 ulelong !0x8664 \b, MachineImageType %#x
>
> I tried to verify the variables and values by NirSoft and tool of
> Windows Kit by lines like:
> Dumpchk.exe 043022-18703-01.dmp
> BlueScreenView.exe 043022-18703-01.dmp
> Unfortunately the last items are there not shown, but other facts are
> shown.
>
> The last line was
>>> 0x090 lequad x \b, %lld pages
> Here i get values like:
> 3142425 8341923 8366500 1162297680 4992030524978970960
> Some values are too high in my opinion. So i do not know if this is
> true, but according to header source at offset 144 (=0x090) this is
> also stored as uint64_t NumberOfPages inside WinDumpPhyMemDesc64.
> Maybe an windows expert can check it this right or false. So i just
> keep it.
>
> Then do the same steps for 32 bit branch. Here i get 14c (for intel
> x86) and the processor type is done like above but at other offset.
> This is done by lines like:
>>> 32 ulelong !0x14c \b, MachineImageType %#x
>>> 36 ulelong x \b, %u processors
>
> Unfortunately for 32 bit the situation is more unclear. According
> to header file i get value 45474101 for uint32_t reserved0. This is
> interpreted by lines like:
>>> 0x05c byte 0 \b, no PAE
>>> 0x05c byte 1 \b, PAE
> So i do not know if this is true. Maybe an expert can check this.
>
> The dump type is interpreted similar to 64 bit branch, but at other
> offset. This is done by lines like:
>>> 0xf88 lelong 1 \b, full dump
>>> 0xf88 lelong 2 \b, kernel dump
>>> 0xf88 lelong 3 \b, small dump
> But according to qemu source at offset 3976 (=0xf88) this is part
> of uint8_t reserved1[3200] in dump header. But for the one of my
> observed sample i also got value 4 here. So i add afterwards one
> more line like:
>>> 0xf88 lelong >3 \b, dump type (%#x)
>
> The last line in 32 bit branch was
>>> 0x068 lelong x \b, %d pages
> Here i get again high value like: 1162297680
> This value is too high in my opinion. So i do not know if this is
> true, but according to header source at offset 104 (=0x068) this is
> also stored as uint32_t NumberOfPages inside WinDumpPhyMemDesc32.
> Maybe an windows expert can check it this right or false. So i just
> keep this.
>
> Instead of generic application/octet-stream i choose an user
> defined one. The dump examples are stored as c:\Windows\MEMORY.DMP
> or something like c:\Windows\Minidump\020322-18890-01.dmp or
> 043022-18703-01.dmp. So these facts are now expressed by additional
> lines like>
> !:mime application/x-ms-dmp
> !:ext dmp
>
> After applying the above mentioned modifications by patch
> file-5.44-windows-dmp.diff then my dump samples are now described
> with more correct details. This now then looks like:
>
> 043022-18703-01.dmp: MS Windows 64bit crash dump
> , version 15.9600, 4 processors
> , small dump
> , 8341923 pages
> 050322-24890-01.dmp: MS Windows 64bit crash dump
> , version 15.19041, 2 processors
> , small dump
> , 3142425 pages
> MEMORY-full.DMP: MS Windows 64bit crash dump
> , version 15.22621, 2 processors
> , full dump
> , 4992030524978970960 pages
> MEMORY.DMP: MS Windows 64bit crash dump
> , version 15.22621, 2 processors
> , kernel dump
> , 4992030524978970960 pages
> Mini111013-01.dmp: MS Windows 32bit crash dump
> , version 15.2600, 2 processors, PAE
> , dump type (0x4)
> , 1162297680 pages
>
> With best wishes,
> Jörg Jenderek
> - --
> Jörg Jenderek
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iF0EARECAB0WIQS5/qNWKD4ASGOJGL+v8rHJQhrU1gUCZF++JwAKCRCv8rHJQhrU
> 1lOEAJ0ehPh5/2rLVz7MzMRblUddUwo5FgCfbBd3jI0HPmNqD8aXe+la4ncjJss=
> =UZe4
> -----END PGP SIGNATURE-----
> <trid-v-dmp.txt.gz><file-5_44-windows-dmp_diff.DEFANGED-5530><file-5_44-windows-dmp_diff_sig.DEFANGED-5531>--
> File mailing list
> File at astron.com
> https://mailman.astron.com/mailman/listinfo/file
> <sanitizer.log>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP
URL: <https://mailman.astron.com/pipermail/file/attachments/20230515/f7ce5ed3/attachment-0001.asc>
More information about the File
mailing list