L'idée est la suivante : partager des connaissances permettant l'investigation autour de Explorer.exe et de twinui.dll dans winpe10.
Aussi, si vous avez des compléments d'informations à donner ou des pistes à proposer, s'il vous plait, répondez moi.
- la fonctionnalité "affichage du bureau" ( Win + D, clic dans le coin bas et gauche...) :
J'ai pu identifer les enchaînements de messages "WM_xxx" entre différentes fenêtres de "explorer.exe" en utilisant spy++ et windbg.
Et j'ai ainsi pu mettre en évidence que l'envoi du message 0x5BA permet de débloquer le mécanisme de bascule de cet affichage.
A la réception de ce message, "explorer.exe" met à zéro un flag. Il rend ainsi opérationnel les messages qui demandent la bascule de l'affichage du bureau.
Voir mon document sur le site http://t he ov en.org/index.php?topic=1639.msg19180#msg19180
Mais je n'ai pas trouvé "qui" envoyait ce message lors du démarrage de "explorer.exe".
L'investigation était assez simple car seul le mécanisme de messages inter-fenêtres était mis en oeuvre.
Et aussi parce que l'usage de spy++ et windbg était facile dans ce context.
-la fonctionnalité "Win + X"
Mes premiers constats dans un windows10 "normal" avec spy++ montrent que deux fenêtres interviennent dans le traitement de "Win + X" :
- une fenêtre dont le nom est "WorkerW" ( attention : il en existe plusieurs du même nom)
- la fenêtre "LauncherTipWnd" qui affiche le menu "Win+X"
Le thread qui traite ces 2 fenêtres est contenu dans TwinUi.dll.
Or, dans winpe10 ( avec le bureau de "explorer.exe" ), cette dll n'est pas chargée.
Quelques éléments à noter :
- le livre "inside Com+" est très utile (http://thrysoee.dk/InsideCOM+/)
- S'agissant d'une dll, l'implémentation "in-process" est la seule qui me semble pertinente ( à mon avis ) et je vais tenter de ne pas me polluer avec les autres implémentations.
Ma supposition du moment : lors de son premier démarrage, "explorer.exe" crée, entre autres choses, un objet qui implique le chargement de "twinui.dll". Or, dans Winpe, quelque chose interdit ce chargement. Mais quoi et comment le trouver ?
Question 1 : quel est le principe de chargement de TwinUi.dll et de ses objets COM ?
Question 2 : comment tracer avec windbg le chargement de TwinUi.dll qui est un "très gros" objet "COM" (7MO)? où placer un bp ?
Question 3 : comment explorer les objets COM de TwinUi.dll ?
Question 4 : les CLSID de twinui.dll ne possèdent pas de ProgId : peut on manipuler ces objets avec Powershell par exemple ? comment identifier les méthodes, leurs paramètres, les variables ?
Question 5 : comment peut on créer le fichier "typelibrary" (.tlb) à partir de Twinui.dll ? est ce utile?
Question 6 : je ne vois pas les interfaces de TwinUi.dll avec OLEView.exe du SDK (lancè en tant que ADM) : pourquoi ?
Voici mes quelques essais avec "Win+X":
tentative 1 - Clic droit sur la fenêtre "Start" et désassemblage de wndProc de "Start"
identifier les éléments nécessaires avec Spy++ et un bout de PS :
Segment et offset de la wndProc de "Start"
identifier les messages WM_xxx avec spy++ que reçoit cette fenêtre
déassembler la WndProc de la fenêtre "Start"
--->>> conduit à une impasse car le msg 205h ne semble pas traité par cette wndProc.
il semble acheminé vers la la procédure par défaut DefWindowProcW
Tentative 2 - clic droit sur la fenêtre "Start" et désassemblage de wndProc de "Shell_TrayWnd"
identifier les éléments nécessaires avec Spy++ et un bout de PS :
Segment et offset de la wndProc de "Shell_TrayWnd"
identifier les messages WM_xxx avec spy++ que reçoit cette fenêtre
désassembler la WndProc de la fenêtre "Shell_TrayWnd" : je me suis perdu dans le code
poser un BP conditionnel sur le msg (205h) : il ne se déclenche jamais !
Mon erreur : la fenêtre "Shell_TrayWnd" reçoit WM_SETCURSOR (20h) avec wParam = hWnd de "start"
Tentative 3 - action sur les touches "Win X"
avec spy++, rechercher le processus qui reçoit les messages de cette combinaison de touches :
identifier les messages WM_xxx avec spy++ que reçoit le processus "explorer"
puis identifier par son handle la fenêtre qui reçoit les messages WM_HOTKEY ( car il existe plusieurs fenêtres "workerW" )
identifier les éléments nécessaires avec Spy++ et un bout de PS :
Segment et offset de la wndProc du bon handle "workerW"
7fff`6089ef30 --->>> twinui.dll
twinui!CImmersiveWindowMessageService::s_MessageMsgWndProc [shell\twinui\windowmessageservice\lib\windowmessageservice.cpp @ 565]:
Reste à poser un bp conditionnel sur cette wndProc
bp 7fff`5ff4ef30 ".if (rdx == 0x312 ) {.echo msg ok} .else {gc;}"
Tentative 4 - recherche du thread et de la fenêtre gérant l'affichage du menu X
classe de fenêtre : LauncherTipWnd
elle reçoit WM_INITMENUPOPUP ( 117h )
wndProc = 60b27bc0
hinst : 7fff60860000
u 7fff`60b27bc0
twinui!CWRLImpWndProc<CLauncherTipContextMenu>::s_WndProcBase [shell\inc\cwndproc_wrl.h @ 15]:
Informations relatives à twinui.dll :
cette dll exporte seulement 3 fonctions pour gérer un serveur COM/DCOM
DllGetClassObject
DllCanUnloadNow
DllGetActivationFactory
Son point d'entrée est bien sûr "DllMain"
Ps : je ne maîtrise pas assez l'anglais pour écrire dans un forum en anglais. Mais je peux essayer.
Edited by noel, 11 January 2018 - 09:21 PM.
