Jump to content











Photo
- - - - -

winpe10 et explorer : échange d'informations


  • Please log in to reply
6 replies to this topic

#1 noel

noel

    Member

  • Members
  • 71 posts
  • Location:nantes
  •  
    France

Posted 11 January 2018 - 09:17 PM

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.

  • Nuno Brito likes this

#2 noel

noel

    Member

  • Members
  • 71 posts
  • Location:nantes
  •  
    France

Posted 12 January 2018 - 11:43 PM

L'idée de ce soir : analyser le démarrage de "explorer.exe".

 

On trouve rapidement une piste avec  %LOCALAPPDATA%\Microsoft\Windows\explorer\ExplorerStartupLog.etl

Ce fichier existe sur ma machine. Donc il doit être possible de le générer dans winpe.

 

Si j'ai bien analysé le code, il faut mettre une valeur supérieure à 1 dans la valeur :

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer

ExplorerStartupTraceRecorded =  2 ou plus ?

 

Le niveau de détail est codé en dur et vaut 4 = TRACE_LEVEL_INFORMATION  ( API EnableTraceEx2, voir MSDN ).

 

Je n'ai pas encore regardé le contenu de ce fichier. Je viens d'essayer avec "WPA.exe" mais impossible de voir quelque chose.

Je ne comprends rien à ce "GUI". Il est question de symboles à charger mais le menu est grisé.

Si quelqu'un peut m'aider ....


  • Nuno Brito likes this

#3 noel

noel

    Member

  • Members
  • 71 posts
  • Location:nantes
  •  
    France

Posted 13 January 2018 - 06:28 PM

Dans win10, en activant la trace avec ExplorerStartupTraceRecorded =  2 ou plus, et en relançant "explorer.exe" (kill and restart), le fichier ".etl" est bien créé.
On peut le lire en l'ouvrant dans la MMC "eventvwr.msc" (journal enregistré).
Mais comme le dit une page de ce site http://www.geoffchap...s/shell/events/, on ne trouve pas d'informations importantes.
Il manque des informations dans "la registry" pour une meilleure lecture.

Donc je vais retourner à l'analyse du code de "explorer" pour tenter de comprendre le lien entre "explorer" et "twinui.dll".
Néanmoins, en parcourant le site de geoffchappell, j'ai un peu compris que "explorer" n'est en fait qu'un "lanceur" d'objets COM et que je vais vite être bloqué.

 

Au fait, dans winpe, cette trace n'est pas créée. Il me semble qu'il manque la variable d'environnement %LOCALAPPDATA%. Et peut être d'autres choses encore.

 

annexe:
http://www.geoffchap...s/shell/events/
"All the Windows Shell executables have code for WPP Software Tracing. Some, such as SHELL32.DLL, contribute to two trace providers. In turn, each provider acts for multiple executables. As usual for WPP Software Tracing, these providers are not configured for use with tools such as the Event Viewer. The data they collect is arguably useful only to Microsoft’s own programmers who work on the source code or at least have it available for reference. "
http://www.geoffchap...events/core.htm
http://www.geoffchap...shell/index.htm
http://www.geoffchap...index.htm?tx=27


  • Nuno Brito likes this

#4 noel

noel

    Member

  • Members
  • 71 posts
  • Location:nantes
  •  
    France

Posted 01 February 2018 - 12:37 AM

L'idée est de mettre en oeuvre les traces dans explorer.exe puisqu'il y a un enregistrement WPP.
Mais avant cela, je veux commencer par un apprentissage avec windbg.
Le mécanisme de trace me parait identique dans explorer.exe et dans termsrv.dll.
J'ai depuis longtemps envie de comprendre comment mettre en oeuvre windbg dans un service.
Et un wrapper autour de termsrv.dll a attiré mon attention par la complexité de son code et ses quelques lignes.
J'ai donc commencer par tenter de mettre en oeuvre Windbg pour comprendre comment activer les traces dans termsrv.

 

(le fichier DebugService.txt contient le journal de mes "recherches".
le fichier note.txt contient les bouts de code qui me semblaient utiles pour progresser.)

Je ne sais pas comment les télécharger

 

La conclusion d'un bon mois de lecture et d'analyse :

  • les traces ETW sont disponibles dans winpe
  • leur mise en oeuvre avec logman a fonctionné seulement dans mon environnement "full-flat" (si cela intéresse quelqu'un, je peux rajouter une description de mon environnement "full-flat")
  • les traces apportent des informations qui ne sont pas dans le journal des événements ( terminal...) mais sont moins bavardes (verbose) que je le croyais. Il n'y a pas le suivi des fonctions (le code n'est pas présent ou je ne sais pas l'activer)
  • logman produit un fichier ETL
  • les fichiers MOF sont absents, donc tracertp ne produit pas de "csv" et eventvwr.msc n'affiche rien

Question : la version "checked" des binaires de l'os apporterait elle un meilleur résultat?
note : je ne sais même pas comment l'obtenir et son volume doit être énorme.



#5 noel

noel

    Member

  • Members
  • 71 posts
  • Location:nantes
  •  
    France

Posted 01 February 2018 - 02:05 PM

Ne pouvant pas déposer de fichier, je place un lien sur mes documents :

http://noel.blanc.free.fr/

 

Pour MicroWinpeBuilder :

  • Le pdf contient ce qui me semble important
  • Le script traitement.ps1 contient aussi des détails. Je n'ai peut être pas mentionnés tous ces détails dans le pdf (souvent parce que je les suppose déjà connus).

 

L'idée est de partager les informations.



#6 noel

noel

    Member

  • Members
  • 71 posts
  • Location:nantes
  •  
    France

Posted 05 February 2018 - 05:49 PM

Un mot sur ce que j'appelle mon environnement "full-flat".

  • ce n'est pas une nouveauté puisque cela existait depuis bien longtemps. J'avais trouvé dans un site chinois le terme "ramos".
  • le principe de construction est décrit sur le net mais je n'ai plus de lien, donc le voici:

installer windows 10 dans un vhd

modifier quelques clés dans les ruches system et software

copier et supprimer quelques fichiers dans system32, dont le BCD

utiliser Sam, Security de winpe

 

Résultat : on dispose du maximum de clés et fichiers. Il y en a trop pour certaines fonctionnalités qui bien sûr ne fonctionnent pas.

La raison des limites est toujours là même : la sécurité dans winpe ! 

 

L'apport de "full-flat" :

Ce simple test dans cet environnement "full-flat" permet de savoir si la nouvelle fonctionnalité a une chance de fonctionner. Ensuite reste une comparaison pour identifier les éléments manquants.

 

Le cas d'école :

les traces de termservice avec logman fonctionnaient dans mon environnement "full-flat" et non dans mon winpe normal.

En comparant avec procmon et avec un peu de réflexion, j'ai assez vite trouvé (2 services nécessaires et 1 répertoire):

  • le service schedule car logman planifie ses actions
  • le service timebrokerSvc car schedule l'utilise
  • le répertoire windows\tasks\Microsoft\windows qui est consulté par schedule. Ce répertoire est vide dans mon cas mais doit exister.

 

Il me reste à mieux comprendre les traces de termsrv.dll et à faire les modifications préconisées par le wrapper pour le plaisir de le faire une fois.

 

Rien de merveilleux et tout cela, c'est simplement la préparation pour tenter de tracer explorer.exe (lors de la mise en place du bureau).

Sans les fichiers ".MOF", ca va pas être simple !

Oui, je sais, je peux utiliser des shell graphiques. Mais ce n'est pas mon objectif.

En poussant le bouchon un peu plus loin, il existe Linux !


Edited by noel, 05 February 2018 - 05:49 PM.


#7 noel

noel

    Member

  • Members
  • 71 posts
  • Location:nantes
  •  
    France

Posted 15 February 2018 - 05:53 PM

Après de long errements, je suis arrivé à identifier l'élément qui conduisait à l'erreur de "logman start.." dans mon environnement winpe.

La méthode a été compliquée a mettre au point et longue dans sa mise en oeuvre.

 

J'ai donc localisé la clé ....\control\WMI. Je n'ai pas encore compris ce qui est nécessaire dans son contenu.

Mais en copiant cette clé ( et sous clés ) dans une ruche system de mon winpe, la commande "logman start..." réussit.

 

Je vais pouvoir me concentrer maintenant sur la mise en oeuvre des traces depuis winpe.

Il reste vrai que sans les .mof ...






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users