7

I have a Windows 10 machine that keeps crashing. I am thinking of posting the dump files (.dmp) publicly online for help. Can this be a security or privacy concern, and if yes, how can I censor the information to mitigate the threat?

  • I would guess so, otherwise M$ won't put a big privacy policy link in the error dump dialogue in Windows XP. I don't think commercial software have memory-dump privay in mind when they coded it. – billc.cn Dec 9 '16 at 17:54
  • @billc.cn then the question is, can it be censored? – Celeritas Dec 9 '16 at 17:59
  • It would be difficult. Every memory address will have to be marked as privacy censitive or not by the application. I am not aware of any language that supports doing this. M$ can probably remove some user data for apps they created tough, but this is likely with the help of an error reporting plugin and not doable in general. – billc.cn Dec 9 '16 at 18:07
4

Please consider: Microsoft collects such files via Windows Error Reporting and companies can get access to those files collected by Microsoft by signing an NDA. Microsoft takes actions to only make the crash dumps available to companies who can prove that it's their driver that causes the crash. It requires a digital certificate to do so.

You would post that information for everyone publically, so I'm glad you care. Personally I'd not post such a file on the Internet.

It requires only a few commands to get the most important information out of it, if you have an Internet connection. The output of

.symfix c:\symbols
.reload /f
!analyze -v

and removing the line that contains ANALYSIS_SESSION_HOST should suffice for someone to either solve the problem or give more instructions on what is needed. It may take a few moments longer for asking and answering, but using above steps gives you human readable text that you can check for sensitive data.

The most important data is such a line:

BugCheck 117, {fffffa80188fb4e0, fffff88004248e9c, 0, 0}

If you still consider posting it, here's what it may contain: An OS crash (bluescreen) will generate a kernel dump. Such a dump contains

  • crash information (exception information),
  • processor information,
  • the executables that are running,
  • crash time and uptime of your PC,
  • the drivers you loaded and
  • potentially all contents of physical RAM (everything what is in memory at the time of the crash).

This may give hackers an attack vector: given they find your IP address and they know the version of a vulnerable driver you have in use, they might start attacking.

However, it heavily depends on the settings with which the crash dump was captured. By default it will be "Small memory dump (256 kb)" (on Windows 7 at least), so it does not contain all information from RAM but only a very small subset which is related to the crash. This may still include drivers and version numbers. Usually the small crash dump is sufficient to solve problems.

If you have a full kernel crash dump, you can convert it into a small one using WinDbg and the .dump command, so you'll finally have the original full dump and a small dump.

Example information contained in a small kernel dump:

Windows 7 Kernel Version 7601 (Service Pack 1) MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.23418.amd64fre.win7sp1_ldr.160408-2045

Debug session time: Sun Jul  3 15:37:39.242 2016 (UTC + 1:00)
System Uptime: 0 days 6:59:28.965

0: kd> lmDvmAtihdW76
start             end                 module name
fffff880`04f5f000 fffff880`04f7b000   AtihdW76   (deferred)             
    Image path: AtihdW76.sys
    Image name: AtihdW76.sys
    Browse all global symbols  functions  data
    Timestamp:        Wed Feb 24 19:28:17 2016 (56CDF641)
    CheckSum:         000201BA
    ImageSize:        0001C000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4

So I can find out that in July I was using the ATI graphics card with a driver AtihdW76.sys from February. That might already suffice for an attack, if I leave other traces, e.g. your IP.

Note that this information is not included in the textual output of !analyze -v, so it seems not relevant for the analysis:

0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

VIDEO_TDR_TIMEOUT_DETECTED (117)
The display driver failed to respond in timely fashion.
(This code can never be used for a real bugcheck.)
Arguments:
Arg1: fffffa80188fb4e0, Optional pointer to internal TDR recovery context (TDR_RECOVERY_CONTEXT).
Arg2: fffff88004248e9c, The pointer into responsible device driver module (e.g owner tag).
Arg3: 0000000000000000, The secondary driver specific bucketing key.
Arg4: 0000000000000000, Optional internal context dependent data.

Debugging Details:
------------------

DUMP_CLASS: 1
DUMP_QUALIFIER: 400
BUILD_VERSION_STRING:  7601.23418.amd64fre.win7sp1_ldr.160408-2045
DUMP_TYPE:  2
BUGCHECK_P1: fffffa80188fb4e0
BUGCHECK_P2: fffff88004248e9c
BUGCHECK_P3: 0
BUGCHECK_P4: 0

FAULTING_IP: 
atikmpag+ce9c
fffff880`04248e9c ??              ???

DEFAULT_BUCKET_ID:  GRAPHICS_DRIVER_TDR_TIMEOUT
TAG_NOT_DEFINED_202b:  *** Unknown TAG in analysis list 202b

CPU_COUNT: 4
CPU_MHZ: c25
CPU_VENDOR:  GenuineIntel
CPU_FAMILY: 6
CPU_MODEL: 2a
CPU_STEPPING: 7
BUGCHECK_STR:  0x117
PROCESS_NAME:  System
CURRENT_IRQL:  0
ANALYSIS_SESSION_HOST:  REMOVETHIS
ANALYSIS_SESSION_TIME:  12-09-2016 19:03:01.0993
ANALYSIS_VERSION: 10.0.14321.1024 amd64fre

STACK_TEXT:  
fffff880`05bad2c0 fffff880`044b27e7 : fffffa80`188fb4e0 00000000`00000024 fffffa80`182fc800 fffff880`044b2488 : watchdog!WdDbgReportRecreate+0xa3
fffff880`05bad7e0 fffff880`044b2c1e : 00000000`00001000 fffff8a0`3dd1c8e0 00000000`00000008 00000000`00004000 : dxgkrnl!TdrUpdateDbgReport+0xcb
fffff880`05bad830 fffff880`044b3ed2 : fffffa80`188fb4e0 fffffa80`188fb4e0 fffffa80`182fc800 fffffa80`0dd73410 : dxgkrnl!TdrCollectDbgInfoStage1+0x2e6
fffff880`05bad8d0 fffff880`0455bfbf : fffffa80`188fb4e0 00000000`00000000 fffffa80`182fc800 fffffa80`0dd73410 : dxgkrnl!TdrIsRecoveryRequired+0x17a
fffff880`05bad900 fffff880`04585d09 : 00000000`ffffffff 00000000`00189d69 00000000`00000000 00000000`00000002 : dxgmms1!VidSchiReportHwHang+0x40b
fffff880`05bad9e0 fffff880`0458444f : 00000000`00000102 00000000`00000000 00000000`00189d69 00000000`00000000 : dxgmms1!VidSchiCheckHwProgress+0x71
fffff880`05bada10 fffff880`045572e6 : ffffffff`ff676980 fffffa80`0dd73410 00000000`00000000 00000000`00000000 : dxgmms1!VidSchiWaitForSchedulerEvents+0x1fb
fffff880`05badab0 fffff880`0458400e : 00000000`00000000 fffffa80`182fc800 00000000`00000080 fffffa80`0dd73410 : dxgmms1!VidSchiScheduleCommandToRun+0x1da
fffff880`05badbc0 fffff800`03713bc6 : 00000000`02c4d1a9 fffffa80`0ddb5060 fffffa80`0ca00720 fffffa80`0ddb5060 : dxgmms1!VidSchiWorkerThread+0xba
fffff880`05badc00 fffff800`0346d6a6 : fffff800`035fae80 fffffa80`0ddb5060 fffff800`03608cc0 fffffa80`0da82d90 : nt!PspSystemThreadStartup+0x5a
fffff880`05badc40 00000000`00000000 : fffff880`05bae000 fffff880`05ba8000 fffff880`05bac2b0 00000000`00000000 : nt!KxStartSystemThread+0x16


STACK_COMMAND:  kb
THREAD_SHA1_HASH_MOD_FUNC:  711770ee3782c8990d4679145cf9108ec8a862f4
THREAD_SHA1_HASH_MOD_FUNC_OFFSET:  cc3ee750d9914b4f5449ea07474e889f95552a7e
THREAD_SHA1_HASH_MOD:  36a574ce8074060aba5fc87a076613c500071d03

FOLLOWUP_IP: 
atikmpag+ce9c
fffff880`04248e9c ??              ???

SYMBOL_NAME:  atikmpag+ce9c
FOLLOWUP_NAME:  MachineOwner
MODULE_NAME: atikmpag
IMAGE_NAME:  atikmpag.sys
DEBUG_FLR_IMAGE_TIMESTAMP:  56effafd
FAILURE_BUCKET_ID:  X64_0x117_IMAGE_atikmpag.sys
BUCKET_ID:  X64_0x117_IMAGE_atikmpag.sys
PRIMARY_PROBLEM_CLASS:  X64_0x117_IMAGE_atikmpag.sys
TARGET_TIME:  2016-07-03T14:37:39.000Z
OSBUILD:  7601
OSSERVICEPACK:  1000
SERVICEPACK_NUMBER: 0
OS_REVISION: 0
SUITE_MASK:  272
PRODUCT_TYPE:  1
OSPLATFORM_TYPE:  x64
OSNAME:  Windows 7
OSEDITION:  Windows 7 WinNt (Service Pack 1) TerminalServer SingleUserTS
OS_LOCALE:  
USER_LCID:  0
OSBUILD_TIMESTAMP:  2016-04-09 07:46:22
BUILDDATESTAMP_STR:  160408-2045
BUILDLAB_STR:  win7sp1_ldr
BUILDOSVER_STR:  6.1.7601.23418.amd64fre.win7sp1_ldr.160408-2045
ANALYSIS_SESSION_ELAPSED_TIME: 493
ANALYSIS_SOURCE:  KM
FAILURE_ID_HASH_STRING:  km:x64_0x117_image_atikmpag.sys
FAILURE_ID_HASH:  {fa4b6286-8c4a-e9c2-c89f-5612619e000e}
Followup:     MachineOwner
---------
| improve this answer | |
  • RE: " It requires only a few commands to get the most important information out of it, if you have an Internet connection. " what do you run this in? I tried CMD but .symlink is not a recognized command. – Celeritas Dec 9 '16 at 22:57
  • @Celeritas: The command is .symfix, not .symlink. The question is about WinDbg, not CMD, so you need to use the command inside WinDbg. – Thomas Weller Dec 11 '16 at 10:34
-1

Anyone in posession of your dump file can potentially obtain the passwords for every user on the machine in plain text.

http://carnal0wnage.attackresearch.com/2013/07/mimikatz-minidump-and-mimikatz-via-bat.html

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.