The Oven

Project World => Project Street => Topic started by: noelBlanc on February 02, 2016, 10:41:27 AM

Title: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on February 02, 2016, 10:41:27 AM
( See the end of this first post for the files to download)

The tutorial will come may be after this learning.

Like many beginners, I want to understand how one can modify a Winpe10 (boot.wim) and adapt it to its needs or the desire.
And mainly adds native Windows desktop (explorer.exe).

Understanding requires to investigate in the heart of Winpe with tools like "procmon, procexp", etc. And above all it requires a method of investigation.
But for me it is not easy to describe a method of investigation.
Also, not really knowing describe a method, I have recorded information which seem to me essential to start the investigation on a given point.
As of the beginning of writing, I realized that it needed a starting point, that is to say a minimum body of knowledge.
And this so do not write all the details lose sight of the whole.

During the investigation and the collection, should introduce changes into the boot.wim file to validate assumptions.
Then put in place a tool to reproduce the generation of this inhospitable Winpe.

But the investigation does not necessarily the good result the first time. Should be many changes to achieve a result.
And of many flashbacks and multiple injections.

I quickly realized that needed a simple and modifiable tool quickly.
At the end, the rudimentary tool will contain all of the identified changed data.

In addition, I adopt the following principles:
-This tool will only use the programs available in the host Win10 system or the ADK.
-It requires the installation of the ADK and Assembly of the Win10Entreprise Evaluation version to download install.wim file.

Regarding the essential information, I grouped them into a pdf file.. They are necessarily incomplete. And in french for the moment.

I can try to translate them into English if I have feedback that leads me.http://theoven.org//Smileys/IPB/wink.gif

Concerning the minimum knowledge, it would be possible to detail a day.

Concerning the script injection, it is written in powershell. I have added a simplistic GUI. To look pretty.
This script is not an end, it is a way, assistance. Each to appropriate it. Or use other means.
The part "processing" of the script will always be evolving as it allows to memorize the discoveries.
Each therefore make his additions on the basis of the progress of its own discoveries.
The initial script contains what I have implemented so far thanks in part to WinPeSe.
Development issues have made me lose sight of compartmentalized and rigorous scripts WinPeSe structure which served as me a reference
So my scripts are not "pretty".

It is quite clear that my purpose is different from that of Win10PeSe.
My goal is to understand how it happens to be able to make available to everyone a product like WinPeSe.
This script MicroWinpeBuider is only a tool to facilitate the injection of data and not to lose the findings resulting from its own investigation.

The minimum information to know:
-modify BCD with bcdedit.exe.
-use ICSB to Mount/unmount an image (boot.wim for example)
-load/unload a hive with regedit
-modify the ACLs for a key in a hive with regedit
-write a small script in powershell
-create a vhd with diskmgr.msc (at worst with diskpart)
-generate a BCD to start a VM with a 'flat' winpe

You can read the pdf then think to add a feature.

Note: further enrich the part 'method'.
Translated with bing.translator
----------------------------------------------

MicroWinpeBuilder pour adapter son propre Winpe : tutorial ou "under the hood" ?

Le tutorial viendra peut être après cet apprentissage.

Comme de nombreux débutants, je souhaite comprendre comment on peut modifier un Winpe10 (boot.wim) et l'adapter à son besoin ou à son envie.
Et principalement comment ajouter le bureau natif de Windows (explorer.exe).

Comprendre nécessite d'investiguer au coeur de Winpe avec des outils comme "procmon, procexp", etc. Et surtout cela demande une méthode d'investigation.
Mais pour moi ce n'est pas facile de décrire une méthode d'investigation.
Aussi, ne sachant pas vraiment décrire une méthode, j'ai consigné les informations qui me semblent essentielles pour démarrer l'investigation dans Winpe.
Car dés le début de la rédaction, je me suis aperçu qu'il fallait un point de départ, c'est à dire un ensemble de connaissances minimum.
Et cela afin de ne pas écrire tous les détails faisant perdre de vue l'ensemble.

Pendant l'investigation et la collecte, il faut introduire les modifications dans le fichier boot.wim pour valider les hypothèses.
Puis mettre en place un outil pour reproduire la génération de ce Winpe adpaté.

Mais l'investigation ne donne pas forcément le bon résultat du premier coup. Il faut faire de nombreuses modifications pour arriver à un résultat.
Et de nombreux retours en arrière et de nombreuses injections.

J'ai vite compris qu'il fallait un outil simple et modifiable rapidement.
A la fin, l'outil rudimentaire contiendra l'ensemble des données modifiées identifiées.

De plus, j'adopte les principes suivants :
- cet outil utilisera uniquement les programmes disponibles dans le système hôte Win10 ou dans l'ADK.
- il nécessite l'installation de l'ADK et le montage du fichier install.wim  de la version Win10Entreprise Evaluation à télécharger.

Concernant les informations essentielles, je les ai regroupées dans un fichier pdf. Elles sont forcément incomplètes. Et en français pour l'instant.
Je peux tenter de les traduire en anglais si j'ai des retours qui m'y incitent.

Concernant les connaissances minimales, il serait possible de les détailler un jour.

Concernant le script d'injection, il est écrit en powershell. J'ai rajouté une ihm simpliste. Pour faire joli.
Ce script n'est pas une fin, c'est un moyen, une aide. A chacun de se l'approprier. Ou d'utiliser une autre moyen.
La partie "traitement" du script sera toujours en évolution puisqu'elle permet de mémoriser les découvertes.
A chacun donc de faire ses ajouts en fonction de l'avancée de ses propres découvertes.
Le script initial contient ce que j'ai mis en oeuvre à ce jour grâce en partie à WinPeSe.
Les problèmes de mise au point m'ont fait perdre de vue la structure cloisonnée et rigoureuse des scripts de WinPeSe qui me servait de référence.
Donc mes scripts ne sont pas "jolis".

Il est bien évident que mon but est différent de celui de Win10PeSe.
Mon but est de comprendre comment on arrive à pouvoir mettre à disposition de chacun un produit comme WinPeSe .
Ce script MicroWinpeBuider n'est qu'un outil pour faciliter l'injection des données et ne pas perdre les découvertes résultant de sa propre investigation.

Les informations minimales à connaître :
- modifier le BCD avec bcdedit.exe.
- utiliser DSIM pour monter/démonter une image (boot.wim par exemple)
- charger/décharger une ruche avec regedit
- modifier les ACL d'une clé dans une ruche avec regedit
- écrire un petit script en powershell
- créer un vhd avec diskmgr.msc ( au pire avec diskpart )
- générer un BCD pour démarrer une VM avec un winpe "flat"

A vous de lire le pdf puis de réfléchir pour ajouter une fonctionnalité.

Note : il faut encore enrichir la partie "méthode".

version V2 (2016.02.05...) too old: automatic language detection added
version V3 (2016-02-18-microWinpeBuilder.7z) : connect/deconnect Wifi in PS, ***** get WOW64 with a PS script ! ******  and correct many bugs !!!
version V4 (2016-02-24-microWinpeBuilder.7z) : Gui in English (translate with bing.translator), wow64 even whith software from winpe, messagebox in the foreground
version V5  (2016-02-29-microWinpeBuilder.7z) : Gui with 'form resizing', scripts PS to modify fbwf.sys for scratchSpace greater than 512 Mo
version V6  (2016-04-23-microWinpeBuilder.7z) : session administrator, BITS, WinRm, a piece of IE
-----------the end for build 10586-------
version V7 ( V7-build14393-MicroWinpeBuilder_V7.7z ) : first work for adaptation to build 14393, explorer OK, session adm nearly OK, but many NOK...
version V8 (2016-10-07-microWinpeBuilder-14393.7z) : many bug in script traitements.ps1,  explorer, session adm, Wow64, modif themecpl, mstsc = ok; wmp and other ...=NOK
version V8 (2016-10-31-microWinpeBuilder-14393.7z) : first try for printer over the LAN
version V9 (2016-11-04-microWinpeBuilder-14393.7z) : printer USB ( adm and system) and network ( adm )
version V10 (2016-11-30-microWinpeBuilder-14393.7z) : printer PDF/XPS automatically started
version V11 (2016-12-14-microWinpeBuilder-14393.7z) : add mciSendString for play audio file, WMP can read MP3  (pb adm and vhd see post 79)
version V12 (2017-02-05-microWinpeBuilder-14393.7z) : session ADM and a better IE64 for ADM only ( download ok, HS : qwant.com , F12...)

version V13 (2017-02-09-microWinpeBuilder-14393.7z) : better IE64 for ADM with f12 (network trace ok)

PDF V2 translate in English with bing/translator
PDF V2.1 45pages in french 45 pages in English, corrections, etc.
PDF V2.2 update for Mstsc with NLA
PDF V2.3: how to add WireShark and Win10Pcap in winpe after it starts. Orca or 7Z? you can choice !
PDF V2.4: modify themecpl.dll to modify wallpaper ( and color task bar ) : not too complex
PDF V2.5: printer USB ans network
PDF V2.6: printer PDF and XPS, scanner
PDF V2.7: note for mciSendString
PDF V2.8: add "winpe in a VHD" ( simple and yet... ) : pb adm and vhd see  "Reply #105"
PDF V2.9: update vhd and session adm ( correct some translations )
PDF V3   : update for session ADM ans IE64 ok for Adm
PDF V3.1 : corrections and clarifications
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: ChrisR on February 03, 2016, 12:31:06 AM
I have Very quickly read your tutorial, it's quite pretty full, Congratulation  :thumbsup:  :thumbsup:
Well, it is French  :wink:
I would look further, when I find some free time. There is a really interesting work behind   :great:

It may lack a little guide to try your powershell script or my first diagonally read was too fast.
1 ) ADK CopyPE.cmd
Then, MicroWinpeBuilder_V1.Ps1, traitement.ps1 ?

I have to go, real life  :wink:
I hope others will look to MicroWinPEbuilder to try, test and help to improve  :smile:
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: Atari800xl on February 03, 2016, 05:11:59 AM
noelBlanc, thanks you for your contribution!
I have downloaded your 7z pack, and using Google translate and my very limited French language skills, I'm having a great time trying to understand the PDF!  :thumbsup:
The PDF looks very well written and organised, so it's actually kind of fun to slowly "crawl" through it.

Like ChrisR, I would also like some more hints on the exact method of using the .cmd and .ps

Once again, very nice work and I hope you will continue supporting this!
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on February 03, 2016, 08:38:24 AM
Thank you for your encouragement ChrisR Atari800xl

I kinda rushed to transmit the scripts. It is certain that they contain errors, including strings "fr - fr", which are remained.
I put emphasis on the Pdf and the explanations to investigate in winpe.
The script is only an aid. And I had tried to document its functioning and its interactions with copype.cmd in GUI tabs.
But it is true that must already be at launch.

It has three files:
-MicroWinpeBuilder_V1.Ps1: it is a graphical interface which offers tabs and a 'launch' button
   There are two main tabs: input and configuration
   Input: to fill in the three basic informations
      -the base directory:
         It is the one that will receive the result of copype.cmd. But it can also use an existing tree and produced by a manually launched copype.cmd
      -the directory containing the ADK: an automatic search in the registry key provides the path resulting from its installation
      -the reference win10 directory: a directory containing "install.wim" unzipped (e.g. with DISM/mount-wim...)
   Configuration: two options
      -use REG. EXE or the API of the C3 for loading/unloading of the hives. At the beginning I had too many errors.
         I have a long time to find the impact of GC (garbage collector) on the "runspace" PS (resources not released)
      -choose between the software hive taken into 'install.wim' (in full) or winpe (the 'partial' word is somewhat ambiguous)
         I couldn't find how to display the wallpaper and I tried one and other opportunities. In addition it demonstrates
         the purpose of the script: modify to understand.

-treatment. Ps1: it is activated when you click on the 'launch' button
Initially, I wanted to do full of menus to offer plenty of choice but I made simple: an automatic succession of three steps.
   + If the root directory does not contain the file "media\sources\boot.wim" then the lance copype.cmd script
   + If the root directory does not contain "media\sources\boot.wim.AvecPaquetsDeBase.export" then it launches the "DISM / Add – Package":
   It is long because the script installs all of the packages available in the ADK (modification if needed in the script)
   and then creation of the 'end of this stage' indicator: copy of bootm.wim with another name
   + the next step is always achieved: it is the injection of the modif in the boot.wim file containing the packages (and renamed) to not crush

-the ProductOptions.txt file that contains the information that I know not find elsewhere

To start:
-Open a console PS as 'administrator'
-type in the path of MicroWinpeBuilder_V1.Ps1
-the console is then hidden and a few seconds more later (depending on processor speed) the GUI will be displayed
I left the button "exit" and the "system" menu at the top right (it is a script and the user knows what it does)

Log: the contents of the console is written to the file 'racine\lastlog.txt' when processing is complete.
"A debug mode" rudimentary to search for PS errors:
Type "racine\MicroWinpeBuilder_V1.Ps1 - debug true":
the GUI is not launched in a runspace
the "hideConsole" function is deactivated
PS errors are displayed in the console PS

Be it that I try a translation with bing?

I dare not ask how JFX found the missing driver for dwm 10586 but I wish I knew. Your methdes of investigation are more effective than mine.

@Atari800xl : perhaps i can help you to translate pdf or ps... and speak about content
Thanks again.

--------
Merci pour vos encouragement ChrisR Atari800xl

Je me suis un peu précipité pour transmettre les scripts. Il est certain qu'ils contiennent des erreurs, notamment des chaînes "fr-fr" qui sont restées.
J'ai mis l'accent sur le Pdf et les explications pour investiguer dans winpe.
Le script n'est qu'une aide. Et j'avais essayé de documenter son fonctionnement et ses interactions avec copype.cmd dans les onglets de l'interface graphique.
Mais c'est vrai qu'il faut déjà arriver à le lancer.

Il a trois fichiers :
- MicroWinpeBuilder_V1.Ps1 : c'est l'interface graphique qui propose des onglets et un bouton "lancement"
   Il y a deux onglets principaux : saisie et configuration
   Saisie : pour renseigner les trois information de base
      - le répertoire de base :
         c'est celui qui recevra le résultat de copype.cmd. Mais on peut aussi utiliser une arborescence déjà existante et produite par un copype.cmd lancé manuellement
      - le répertoire contenant l'ADK : une recherche automatique dans la clé du registre propose le chemin résultant de son installation
      - le répertoire de la référence win10 : un répertoire contenant "install.wim" décompressé ( par exemple avec DISM /mount-wim... )
   Configuration : deux options
      - utiliser REG.EXE ou les API du C3 pour chargement/déchargement des ruches. Au début j'avais trop d'erreurs.
         J'ai mis longtemps pour trouver l'impact du [GC] ( garbage collector ) sur les "runspace" de PS ( ressources non libérées )
      - opter entre la ruche software prise dans 'install.wim' ( en totalité ) ou celle de winpe ( le mot 'partielle' est un peu ambigu )
         je ne trouvais comment faire afficher le fond d'écran et j'ai tenté l'un et l'autre des possibilités. De plus cela illustre
         le but du script : modifier pour comprendre.
- traitement.PS1 : il est activé lorsque l'on clique sur le bouton "lancement"
   Au début, je voulais faire plein de menus pour proposer plein de choix mais j'ai fait simple : un enchaînement automatique de trois étapes.
   + si le répertoire racine ne contient pas le fichier "media\sources\boot.wim" alors le script lance copype.cmd
   + si le répertoire racine ne contient pas "media\sources\boot.wim.AvecPaquetsDeBase.export" alors on lance les "DISM /Add-Package" :
      c'est long car le script installe tous les paquets disponibles dans l'ADK ( modification si besoin dans le script )
      puis création de l'indicateur 'fin de cette étape' : copie de bootm.wim avec un autre nom
   + l'étape suivante est toujours réalisée : c'est l'injection des modif dans le fichier boot.wim contenant les paquets ( et renommé pour ne pas l'écraser )
- le fichier ProductOptions.txt qui contient l'information que je ne sais pas trouver ailleurs

Pour le lancer :
   - ouvrir une console PS en tant que 'administrateur'
   - taper le chemin de MicroWinpeBuilder_V1.Ps1
   - la console est alors masquée et quelques secondes plus tard ( selon la rapidité du processeur ) l'interface graphique s'affiche
   J'ai laissé le bouton "exit" et le menu "system" en haut à droite ( c'est un script et l'utilisateur sait ce qu'il fait )

Log : le contenu de la console est écrit dans le fichier 'racine\lastlog.txt' lorsque le traitement est terminé.
Un mode "debug" rudimentaire pour chercher les erreurs PS :
   taper "racine\MicroWinpeBuilder_V1.Ps1 -debug true" :
      l'ihm n'est pas lancé dans un runspace
      la fonction "hideConsole" est neutralisée
      les erreurs de PS s'affichent dans la console PS

Faut il que je tente une traduction avec bing?

Je n'ose pas demander comment JFX a trouvé le pilote manquant pour dwm 10586 mais je voudrais bien savoir. Vos méthdes d'investigation sont plus efficace que la mienne.
Encore merci.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: JFX on February 03, 2016, 09:29:37 AM
Looks very good so far  :thumbsup:
Sadly I don't have much free time these days.

I dare not ask how JFX found the missing driver for dwm 10586 but I wish I knew. Your methdes of investigation are more effective than mine.
Well, I would not really call my methods effective.
Since the usual ways did not work on dwm, I used a complete Windows 10 an started removing services and files.

In HKLM\SYSTEM\Setup
SystemSetupInProgress, SetupType and CmdLine can be used to disable user logon and instead launch a program as nt authority\system.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on February 03, 2016, 10:53:01 AM
Thank you JFX

I had never thought to do so.
It takes a lot of rigor to strip Windows and avoid the false trails


Ps : i uploaded twice the same link by error. Is it possible to delete one?
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: ChrisR on February 03, 2016, 01:27:53 PM
i uploaded twice the same link by error. Is it possible to delete one?
Done. With 11 posts, you should able to modify a previous post now, I believe  :thumbsup:
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: ChrisR on February 03, 2016, 01:30:46 PM
Image boot.wim created and started successfully  :great:
Using install.wim x64 fr-FR extracted folder.
At the first attempt, it did the whole process but failed at the end on Dism /Unmount-Wim (it sometimes happens with Explorer open).
I deleted and re-create the mount folder, then I closed explore before restarting and bing, SUCCESS  :thumbsup:
For WiFi, PENetwork would be good. Also a start menu like SIB++ would be a bonus.

[attach=1]

If you want to integrate packages, following language ($Langue), you can probably write something like this (au3 here)
Code: [Select]
$UILanguages = RegEnumKey($HKLM & "\src_System\ControlSet001\Control\MUI\UILanguages", 1)
IniWrite($inifile, 'Languages', 'UILanguages', $UILanguages)
$LCID = RegRead($HKLM & "\src_System\ControlSet001\Control\MUI\UILanguages\" & $UILanguages, "LCID")
IniWrite($inifile, 'Languages', 'LCID', $LCID)

[Languages]
UILanguages=fr-FR
LCID=1036  (0x40c)
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on February 03, 2016, 09:56:20 PM
Thank you ChrisR. I'm glad it's work for you. I was a little affraid.

One thing more : when Dism Unmount failed, have you seen a messagebox behind the GUI ? It said "close explorer" and it retry unmount /discard. The boot.wim is created even if unmount failed.  On my Pc, it work so.
I don't know how to put the messagebox in the foreground. All msgbox are behind. I shall search ...

For autodetection language ( if i understand well that you say ), it's a good idea. It's better than a choice because GUI in script is too long to write. I put in a next version.
And correct the 3 references to "fr-fr" in the script.

Sib++ is  usefull but not 'technical', i prefere 'speak" about Wow64 ( more near MS technologie, i have the error 'sxs in not goog' ) and about the call to syswow64\dllhost  in a full 64bits version. I began to find it in 2012 (http://reboot.pro/topic/17870-winpe4-et-explorer-pour-débutant-comme-moi/)

Encore merci pour avoir fait le test. Ce n'est pas simple de comprendre et d'utiliser les 'bouts de machins mal ficelés' faits par un autre.

(i try without translator)
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: ChrisR on February 04, 2016, 03:38:46 AM
I received the message, indeed "Close explorer...Retry unmount /discard"
As the MessageBox is long enough, no worry to see it but it would be better in front if you find how.
If error on the first Unmount / Commit, you could possibly test the mount folder size.
and if 0, considered as good and delete and recreate the mount folder and maybe dism /Cleanup-Wim.

I believe that you are not so far for the multilanguage support, if you retrieve the language from Install.wim registry.
$Langue ="xx-xx",  $srcPaquetsLangue    = join-path $sourceFichiersWinpe "\amd64\WinPE_OCs\$Langue"
It should be good then for language pack (if not en-US) and other localized packages.
and you can also use it to copy .mui file (if exist \$Langue\File.mui > Copy else if exist \en-US\File.mui > Copy)
It should allow other install.wim language source :thumbsup: and have more feedback then.

Dans le tuto, tu as écrit:
Quote
Cela reste possible car la ruche software de install.wim contient déjà des « X : », ce qui est très bizarre.
Aurais je modifié ce fichier lors de mes manipulations ?
Oui, tu as du modifier la ruche software, par défaut elle est avec C: (ou D:) et il doit être modifié en X: pour PE

A+
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on February 04, 2016, 11:24:41 AM
@ChrisR : Merci pour le test, la lecture, et les conseils pour le langage et le test unmount. Pour les mui, je teste et copie systématiquement les fichiers des 2 langues, en-us et aussi %langue ='autre' (un tableau envoyé dans le pipeline de PS ). Pourquoi les 2? ceinture et bretelle. Pendant la mise au point, on fait des tests et le code reste.
 
For language, test the size of mount, i'll modify the script saturday .

For a long time I asked myself the question about the presence of the X: in the ISO file.
Tonight I took the time to do the audit of the units contained in the freshly downloaded ISO file.

My test:

I download (it is long) from https://www.microsoft.com/fr-fr/evalcenter/evaluate-windows-10-enterprise?i=1
Read in the HTML page:
<a href="http://care.dlservice.microsoft.com/dl/download/8/5/C/85CA9FB3-CC7F-44FD-A352-EF960FC181AD/10586.0.151029-1700.TH2_RELEASE_CLIENTENTERPRISEEVAL_OEMRET_X64FRE_FR-FR.ISO"> <input class="btn greenbtn" type="button" value="telecharger"></a>

I mount the ISO file.

I open...\sources\install.wim with 7Z.

I extract the software hive in c:\temp

I load this hive in hkey_users with the name "z_software"

I sailed with hkey_users\z_software\Microsoft\windows\currentversion

And I read: ProgramFilesDir = X:\Program Files

I sailed hkey_users\z_software\Microsoft\windows Nt\currentversion

And I read: SystemRoot = X:\WINDOWS

I'm amazed. X: !!! not C: !!!

Is this a mistake on my part?

It would be nice if someone had the time to do this (long) test and attempt to provide an answer.

Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: ChrisR on February 04, 2016, 11:53:20 AM
I just checked, you are right, I had not seen, in 10586 it is X: in most keys but it remains C: in RTM 10240 and in Enterprise 2015 LTSB.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on February 05, 2016, 12:59:04 PM
hello,

Version 2 : Added automatic detection of language from the ISO file or the directory for reference.

Thank you ChrisR for the help about language.

It will be not enough for non-French uses script. Should I translate in English the text of the script tabs.
But no one claims this translation, or pdf also. It is that this is not very useful. It is true that it is a game to me also...

If someone can try with another language...

Concerning what I call the surprise COM64-32 that can highlight year launching desk.cpl for example, the 'system' event log in Winpe reports of an error at the launch of c:\windows\syswow64\dllhost.dll. I regret not to have an IDA 64 version. I will try out Windbg now that I have a new idea.
The "security" event log is almost empty. It seems no longer evolve after startup.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: ChrisR on February 05, 2016, 01:57:26 PM
I'm not sure to have enough time on my side to help further, to test... PESE is already too much, currently :wink:
Also, I have no Powershell knowledge to help on, but your program seem already well advanced and commented (in french :wink:).
I leaves room for others with more free time, to test or go further, in your all-in-one design.
:cheers:

Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on February 07, 2016, 10:14:59 AM
@ChrisR, Merci pour tout ce que tu as fait pour moi. Je t'en suis infiniment reconnaissant. J'avais un peu peur de paraître ridicule. Tu m'as rassuré.
@Atari800XL, may i help you? ( 6502 versus 8080 ? a dilemma in my youth )

Several people have downloaded the 7z file containing a pdf and PS scripts.
I was hoping to have some returns.

Please, tell me what you were hoping to find in these files.

Would you like to:
-an English translation of the pdf?
-an English translation of the text of the scripts?

Version 2 allows automatic detection of the language of the 'ISO' reference as proposed by ChrisR.
But I do not know to remove version 1.

Do not hesitate, give me your opinion, even negative with some comments as ' needed English, pdf useful/useless, script works/does not work '...

The development of scripts (error with reg load/unload) made me abandoned the structure organized for ' build ' each of the components as well as WinPeSe doest it  in these scripts. This will be useful if I body script by creating a file by component as the sections of the WinPeSe scripts?

translated by bing....
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: Atari800xl on February 07, 2016, 11:01:43 AM
NoelBlanc, that final paragraph was translated very badly, I have no idea what that was about... ("Body script by creating a file by component"?)

About your other questions: I'm looking forward to reading the full PDF, also trying the scripts, I just didn't have time for it this weekend, sorry.
I really like the way you describe the whole process, the French language is just a bit of a problem for me, maybe we can work together on the English translation. But in that case, it would be best if I try the scripts first, so I know what's going on.
I think it would be best if I try it on an en-US version (event though I'm Dutch myself).
Please don't abandon your project, it's very informative and I like to learn more in-depth stuff about PE creation and modification. Thanks!

Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on February 08, 2016, 12:44:42 AM
Hello Atari800xl. Thank you for your encouragement and interest that you wear to the documentation.
No worries if you don't have time available at this time. This can wait.

Note: version 1 scripts contained only the version fr-fr of winpe. I do not know how to delete the first post 7Z and replace it with version 2.

For the translation (and the increase in information), your help will be invaluable as I am unable to write in English.
You will be the 'head/Director' for this.

About the 'last paragraph':

in the current script, injection of a component, for example, like Wi-Fi requires various categories like "files to copy, to copy keys, keys to add (this is not the same thing as 'the key to copy'), the drivers to load ', etc."
These actions are scattered throughout the script. They are not easily identifiable.
I did not want that the script is accompanied by a multitude of small files. 3 files, this is already much in my opinion. I would like to avoid the presence of the 'productOption.txt' file.

This is not very educational because it will be difficult for someone else to introduce a new component: it is precisely the purpose of this script.
It seems to me important to integrate all these actions/data "correctly" in the script, in a class of object, for example.
But it will be a little long.

To explain why I had put aside a good structure of the data (the data are intermingled and spaghetti):
I lost a lot of time with:
-the conflict of access to the hives with Dism I met early in the development of the script
(- handles non-released by powershell: I put long before finding a parade on internet with [GC]:...)
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: Atari800xl on February 08, 2016, 01:43:41 AM
Well, when I said "work together", I was thinking of more people than just you and me  :embarrassed:

For now, please continue your very interesting project, I will follow it even when it is in French!!
You have a very clear and "informative" writing style, so I'm sure that I will be able to follow, with a little help from Google Translate, and maybe additional questions in this thread.
I think a translation will always be a bit "out of date" compared to your originals, so that might pose extra problems and inconsistencies.

 :thumbsup:
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: Atari800xl on February 09, 2016, 03:59:27 AM
I must admit I am even dumber than I had feared  :ohmy:

Seriously: When I wanted to test your scripts yesterday, I had sort of forgotten all the steps for a "normal" PE: 64bit host OS necessary, MS ADK necessary (big download), copype.cmd only runs from the ADK prompt, etc. etc. As I said, I forgot how "strict" and "unflexable" this is.
Good thing the PESE projects are so much easier: HostOS can be "anything", no big extra downloads, etc.

I am still very impressed with your excellent Powershell scripting abilities, so I do hope you will continue this projects, but I'm afraid I might have been a bit too enthousiastic. Too bad I don't have a lot of time at the moment either...
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on February 09, 2016, 05:29:15 AM
the script copype.cmd is started automatically by the PS script. We just need adk is installed on the PC. The injection of the packets is also automatic.
Downloading and installing the adk are the only actions that the user must perform.

It must also mount the install.wim file from the iso in a reference directory.
And it's true we need a pc under win10 (regardless of the build).

No problem if you do not have the necessary time.

In the next version 3, I use a PS script to establish WIFI connection with the C # API. There is an example  in c# on the codeplex site.

I'm on holiday but it rains again and again. I will try to investigate in order to add Wow64 in microWinpebuilder.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: Atari800xl on February 09, 2016, 06:52:48 AM
Downloading and installing the adk are the only actions that the user must perform.
It must also mount the install.wim file from the iso in a reference directory.

Both of these sentences can't be true at the same time  :wink:

By "it", you mean the script, right? Not the user? The user only has to download and install the adk, then the script ("it") mounts the install.wim?

Sorry for being stupid (I warned you about that), but maybe other readers of this topic are even more stupid?  :wink:

I hope for you the rain will stop and the sun will come out of hiding.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on February 10, 2016, 10:39:43 PM
Sorry, I trusted to the translator.

You have good reason to seek clarification. Please, continuous, it is a great help for me.

You spoke about copype. I introduced an ambiguity by adding a line dealing with install.wim.
In summary, the user must perform the following actions before running the script:
-Download and install Adk (for winpe)
-extract install.wim ISO and unpack it to a directory (for windows reference)

If I can in a future version, I made active radio-buttons. And would suggest 3 choices to the user:
-Enter the path of the Windows ISO
-Enter the path in the install.wim file
-Enter the path of the directory in which the user unpacked install.wim
Currently, only the latter is operational


Rain became snow and we left more to the South in Avignon. Sun this morning
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: Atari800xl on February 11, 2016, 01:53:13 AM
noelBlanc, yesterday I managed to create a USB with your script! (Even before your last message).

It turned out to be even simpler than I thought  :thumbsup:

I was under the impression that the user would have to do a lot more preparation work himself, but it turns out your script does (pretty much) all the work itself!
I am very impressed with your (powershell and other) skills, very nice job!

On the other hand, I must also admit that the resultant PE is not as "useful" to me as a WinPESE version, but of course that is not the point: If I understand your PDF correctly, you want to study how everything works, and how it can be done without the use of external tools. In that respect your scripts are even more impressive!

I hope I can do some more reading next weekend.
 :thumbsup:
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on February 11, 2016, 04:09:21 AM
Atari 800 XL, thank you for the test. I'm glad that the script has run.
Have you used version 2 for the language en-US?

You're right: microWinpeBuilder is micro. Its first name was 'mini' but I changed to 'micro'. Perhaps 'nano' is better.http://theoven.org//Smileys/IPB/wink.gif
It is only useful to help illustrate the progression of learning and facilitate the implementation of the tests.

This is of course WinPeSe team that does all the work. But reading the scripts' WinPe is difficult for me.

This morning I launched setwow64 of WinPeSe. Thanks WinPeSe.
The source code is complicated. Did you explain that?

And with Procmon, I quickly found a few files (obvious ...) to be added in order to run ... \ syswow64 \ cmd.exe and WinObj.exe of sysinternals.
Because I wanted to confirm that the right click on the screen and "Display Settings" launched the dll 'dllhost' 32-bit and showed the window for changing the screen resolution, for example.

the event log is acting strangely. I do not know if it is proposed in WinPeSe.
Eventvwr.msc generates an error message. It seems that the eventlog Service is testing the key 'MININT'.
And if I delete this key, starts the service eventlog 'and recreates the key, then eventvwr.msc displayed newspapers.
I identified this behavior when I took my first steps with older versions of winpe.
This was also the case for cmdlet 'remote powershell'. I would look later.

I prepare a version 3 with a PS script for the Wifi connection ( many c# ). I must also give some explanations on Wifi and netsh in the PDF.
As I often use PS I added powershell_ise.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on February 20, 2016, 07:30:28 AM
Hello,

Version 3:

-a connecting/disconnecting wifi PS script: it's big, it works correctly on windows 10.
         But the use of the API is complex.
-a script PS to enable the 32-bit subsystem (my principle: do not use external program)
        To full employment of wow64, use WinPeSe: it is made for this. My scripts are only 'educational'.

To show that 'explorer' 64-bit version uses the COM 32-bit dll 'surrogate' mechanism... \syswow64\dllhost.dll,
i added the 32-bit subsystem as WinPeSe by writing a piece of c# code visible in the PS script.
This is a light version of WinPeSe setwow64.exe. But it is Ps!

With the 32 active subsystem, the right click on the wallpaper and menu 'display settings' or 'personnalize' works.

It remains to understand if it is desk.cpl which forces the use of ' surrogate' 32-bit.

The pdf contains explanations that seem important and concerning the above points.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: sezz on February 20, 2016, 09:01:42 PM
Love it  :thumbsup:
It would be even better, if I could understand a single word in french.

BTW: WinObj.exe doesn't run, should it? ("The application has failed to start because its side by side configuration is incorrect.")
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on February 20, 2016, 10:53:53 PM
hello sezz,

Winobj would work. It works in my vm.

In the tab "configuration du script", have you select "install.wim" ? i note this in the first tab but it's not easy to read.
For the option "source software hive = winpe",  i'll modify and add the missed keys in ...Windows\cur...\sydebysyde.

I can translate with bing.translator. What part do you want in first? the text in the script ? The comment in the scripts? the pdf ?

Thanks. Merci.
Note : i write this without a translator. If hope you can read me.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: sezz on February 21, 2016, 05:10:34 AM
In the tab "configuration du script", have you select "install.wim" ? i note this in the first tab but it's not easy to read.

Thanks, that fixed it :)

I can translate with bing.translator. What part do you want in first? the text in the script ? The comment in the scripts? the pdf ?

I think it would be the best to start with the GUI.
That way everyone who's interested can quickly test it and decide if he likes it or not ;)

Note : i write this without a translator. If hope you can read me.

Sure. I learned french in school for 2 years, but the only phrase I still know is "je n'est sais pas" :embarrassed:
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: sezz on February 21, 2016, 07:15:00 AM
(Can't edit my posts yet, sorry.)

Added my PE modifications from my batch and PowerShell files and it looks really good - I think everything of my stuff works.

But I couldn't figure out how to pass long directory/file names with spaces and other characters like ()[] to DISM using your lancerUnPrg, any suggestions?

Regedit_ works with long names after I changed the launch command to
Code: [Select]
Start-Process -Wait regedit.exe -ArgumentList "/s `"$fichier`""

PS: Yes I know, nobody likes long names, but It's not like they have been invented yesterday and I like to keep things organized and readable :smile:
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on February 21, 2016, 01:15:48 PM
to sezz,
can you give me a complete line that doesn't works? I try ...
but i think you have the solution with 'altgr + 7' .

I use it here : lancerUnPrg $DISM "/Image:$mount /Add-Package /PackagePath:`"$srcPaquets\$_.cab`"" $ModeLine

I modify also my scripts for 'regedit_' .
Thank you very mutch

Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: sezz on February 23, 2016, 12:13:47 PM
to sezz,
can you give me a complete line that doesn't works? I try ...

I think I found the problem.

DISM.LOG:
Code: [Select]
2016-02-23 22:25:38, Error                 DISM   DISM.EXE: Failed validating command line: "C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\AMD64\DISM\Dism.exe" /English /Image:"F:\MWPE\Output\mount\" /Add-Driver /Driver:"F:\Windows 10 (Custom Setup)\Settings\Drivers-AMD64" /Recurse

EchoArgs output:

Code: [Select]
Arg 0 is </English>
Arg 1 is </Image:F:\MWPE\Output\mount" /Add-Driver /Driver:F:\Windows>
Arg 2 is <10>
Arg 3 is <(Custom>
Arg 4 is <Setup)\Settings\Drivers-AMD64 /Recurse>
Command line:
"C:\Program Files (x86)\PowerShell Community Extensions\Pscx3\Pscx\Apps\EchoArgs.exe" /English /Image:"F:\MWPE\Output\mount\" /Add-Driver /Driver:"F:\Windows 10 (Custom Setup)\Settings\Drivers-AMD64" /Recurse

The path in $Mount ends with \ and DISM thinks I want to escape the " that comes after the path...

My fault  :frusty:, lancerUnPrg is fine!

Now it works:

Code: [Select]
lancerUnPrg $DISM ("/English /Image:`"" + $Mount.TrimEnd("\") + "`" /Add-Driver /Driver:`"" + $sPathDrivers.TrimEnd("\") + "`" /Recurse") $ModeLine

Output:

Code: [Select]
02/23/2016 23:07:17 Commande : C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\AMD64\DISM\Dism.exe /English /Image:"F:\MWPE\Output\mount" /Add-Driver /Driver:"F:\Windows 10 (Custom Setup)\Settings\Drivers-AMD64" /Recurse
Deployment Image Servicing and Management tool
Version: 10.0.10586.0
Image Version: 10.0.10586.0
Searching for driver packages to install...
Found 4 driver package(s) to install.
Installing 1 of 4 - F:\Windows 10 (Custom Setup)\Settings\Drivers-AMD64\Acronis\IScsi\iscsi.inf: The driver package was successfully installed.
Installing 2 of 4 - F:\Windows 10 (Custom Setup)\Settings\Drivers-AMD64\Acronis\IScsi\mpdev.inf: The driver package was successfully installed.
Installing 3 of 4 - F:\Windows 10 (Custom Setup)\Settings\Drivers-AMD64\Acronis\IScsi\mpio.inf: The driver package was successfully installed.
Installing 4 of 4 - F:\Windows 10 (Custom Setup)\Settings\Drivers-AMD64\Acronis\IScsi\msiscdsm.inf: The driver package was successfully installed.
The operation completed successfully.
02/23/2016 23:07:20 Retour : 0
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on February 24, 2016, 01:01:05 AM
@ sezz: bravo!
I also delete the "\" if it occurs at the end of the entries in the GUI.
If I understand correctly, you modified the PS scripts for add Acronis drivers in one dism command.
And there, you are very strong. You have the right to say that my scripts are similar to packages of spaghetti.

In the V4 version, I've simplified the GUI to update a file in English translated by bing.translator. If you wanted to tell me if this is understandable, it would be nice. I also added keys and files (sideBySide) missing to make active the WOW32 subsystem using the winpe software hive.
And I changed API for the messagebox appear forward plan.

I'll try to modify the fbwf.sys driver to remove the limit of "cmp eax, 0 x 400" in the cache write in X:. I managed to use in a PS the win32 API script to read the checksum. The writing is simple in PS. I still have to find how to sign the driver with a test certificate.
This is not very useful but it is for the game.

I'd also remove the filter from the "registry". But I have still no information on the subject. The interest for me would be that in the VM "registry" changes remain persistent. If anyone has any information on the subject, please let me enjoy.

V4   2016-02-24-microWinpeBuilder.7z : GUI in English, wow even for software from winpe, messagebox in the forground
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: sezz on February 27, 2016, 05:05:11 PM
If I understand correctly, you modified the PS scripts for add Acronis drivers in one dism command.

It's the Microsoft iSCSI Initiator. Acronis adds it when it creates a bootable WinPE ISO. I didn't check if it really needs it, I only took all the files and registry changes and patched TrueImage.exe to not call NtShutdownSystem when I close it.

In the V4 version, I've simplified the GUI to update a file in English translated by bing.translator. If you wanted to tell me if this is understandable, it would be nice.

I can understand it, but I'm not good at english either. It propably takes someone who's fluent in french and english to get good translations ;)

Some minor GUI related changes to allow frame resizing:

Code: [Select]
--- MicroWinpeBuilder_V4.original.Ps1 2016-02-24 11:03:08.477995000 +0100
+++ MicroWinpeBuilder_V4.Ps1 2016-02-26 23:55:09.215858400 +0100
@@ -757,6 +757,7 @@
     $tabControl1.SelectedIndex = 0;
     $tabControl1.Size = New-Object System.Drawing.Size(796, 373);
     $tabControl1.TabIndex = 1;
+    $tabControl1.Anchor = "Top,Bottom,Left,Right"
     #$tabControl1.Appearance = "Buttons"
     #
     # tabPage_Presentation
@@ -784,6 +785,7 @@
     $textBox4.TabStop = $false;
     #$textBox4.Text = resources.GetString("textBox4.Text");
     $textBox4.Text = $TextPresentation;
+    $textBox4.Anchor = "Top,Left,Bottom,Right";
     #
     # tabPage_Saisie
     #
@@ -963,6 +965,8 @@
     $textBox_Console.ReadOnly = $true;
     $textBox_Console.ScrollBars = [System.Windows.Forms.ScrollBars]::Vertical;
     $textBox_Console.Size = New-Object System.Drawing.Size(782, 329);
+ $textBox_Console.Anchor = "Top,Left,Bottom,Right";
+ $textBox_Console.Font = New-Object System.Drawing.Font("Consolas", 8);
     $textBox_Console.TabIndex = 0;
     #
     # button_Exit
@@ -975,6 +979,7 @@
     $button_Exit.UseVisualStyleBackColor = $true;
     #$button_Exit.Click += New-Object System.EventHandler($button_Exit_Click);
     $button_Exit.Add_Click($button_Exit_OnClick);
+    $button_Exit.Anchor = "Bottom,Right";
     #
     # statusStrip1
     #
@@ -1043,6 +1048,7 @@
     $button_Excution.Enabled = $false
     #$button_Excution.Click += New-Object System.EventHandler($button_Excution_Click);
     $button_Excution.Add_Click($button_Excution_OnClick);
+    $button_Excution.Anchor = "Left,Bottom,Right";
     #
     # button_GetInfoWim
     #
@@ -1054,6 +1060,7 @@
     $button_GetInfoWim.UseVisualStyleBackColor = $true;
     #$button_Exit.Click += New-Object System.EventHandler($button_Exit_Click);
     $button_GetInfoWim.Add_Click($button_GetInfoWim_OnClick);
+    $button_GetInfoWim.Anchor = "Left,Bottom";
 
     #
     # radioButton1
@@ -1177,9 +1184,10 @@
     $form1.AutoScaleMode = [System.Windows.Forms.AutoScaleMode]::Font;
     $form1.ClientSize = New-Object System.Drawing.Size(867, 496);
     $form1.MinimumSize = $form1.Size
-    $form1.MaximumSize = $form1.Size
     $form1.Name = "Form1";
     $form1.Text = " $NomDeBase : une aide à l'injection de modifications dans Winpe 10 build 10586";
+    $form1.StartPosition = [System.Windows.Forms.FormStartPosition]::CenterScreen;
+    $form1.Font = New-Object System.Drawing.Font("Segoe UI", 9, [System.Drawing.FontStyle]::Regular, [System.Drawing.GraphicsUnit]::Point, 0);
     #
     # ajout des controls à la form
     #

And some changes to traitement.ps1, because it complained about missing french files and also a small WOW64 fix :

Code: [Select]
--- traitement.original.ps1 2016-02-24 09:32:15.225624600 +0100
+++ traitement.ps1 2016-02-27 00:16:03.697317100 +0100
@@ -295,6 +295,7 @@
 $DestinationWinpe    = $so.Racine                   # c'est le répertoire qui va contenir le futur winpe
 $KitsRoot            = $so.SrcAdk                   # la source de l'adk contenant les outils winpe
 $Langue              = $so.Langue                   # la langue de la référence windows
+$LangShort           = $Langue.Split("-")[0]
 $RefWindows          = $so.RefWindows               # le répertoire contenant la référence
 # déchargement des ruches : choix reg.exe ou API de c#                   
 $flg_RegExe          = $so.flg_RegExe               # true si on utilise reg.exe, false si on utilise c#
@@ -990,18 +991,18 @@
 ;
 WINDOWS\assembly\GAC_MSIL\MMCEx\3.0.0.0__31bf3856ad364e35\MMCEx.dll
 ;WINDOWS\assembly\GAC_MSIL\MMCEx.Resources\3.0.0.0_en_31bf3856ad364e35\MMCEx.Resources.dll
-;WINDOWS\assembly\GAC_MSIL\MMCEx.Resources\3.0.0.0_fr_31bf3856ad364e35\MMCEx.Resources.dll
+;WINDOWS\assembly\GAC_MSIL\MMCEx.Resources\3.0.0.0_$LangShort_31bf3856ad364e35\MMCEx.Resources.dll
 WINDOWS\assembly\GAC_MSIL\MMCEx.Resources\
 WINDOWS\assembly\GAC_MSIL\MMCFxCommon\3.0.0.0__31bf3856ad364e35\MMCFxCommon.dll
 ;WINDOWS\assembly\GAC_MSIL\MMCFxCommon.Resources\3.0.0.0_en_31bf3856ad364e35\MMCFxCommon.Resources.dll
-;WINDOWS\assembly\GAC_MSIL\MMCFxCommon.Resources\3.0.0.0_fr_31bf3856ad364e35\MMCFxCommon.Resources.dll
+;WINDOWS\assembly\GAC_MSIL\MMCFxCommon.Resources\3.0.0.0_$LangShort_31bf3856ad364e35\MMCFxCommon.Resources.dll
 WINDOWS\assembly\GAC_MSIL\MMCFxCommon.Resources\
 WINDOWS\assembly\GAC_MSIL\Microsoft.ManagementConsole\3.0.0.0__31bf3856ad364e35\Microsoft.ManagementConsole.dll
 ;wsman
 WINDOWS\Microsoft.NET\assembly\GAC_MSIL\Microsoft.WSMan.Management\v4.0_3.0.0.0__31bf3856ad364e35\Microsoft.WSMan.Management.dll
 WINDOWS\Microsoft.NET\assembly\GAC_MSIL\Microsoft.WSMan.Management.Activities\v4.0_3.0.0.0__31bf3856ad364e35\Microsoft.WSMan.Management.Activities.dll
 ;WINDOWS\Microsoft.NET\assembly\GAC_MSIL\Microsoft.WSMan.Management.Resources\v4.0_3.0.0.0_en_31bf3856ad364e35\Microsoft.WSMan.Management.resources.dll
-WINDOWS\Microsoft.NET\assembly\GAC_MSIL\Microsoft.WSMan.Management.Resources\v4.0_3.0.0.0_fr_31bf3856ad364e35\Microsoft.WSMan.Management.resources.dll
+WINDOWS\Microsoft.NET\assembly\GAC_MSIL\Microsoft.WSMan.Management.Resources\v4.0_3.0.0.0_$LangShort_31bf3856ad364e35\Microsoft.WSMan.Management.resources.dll
 WINDOWS\Microsoft.NET\assembly\GAC_MSIL\Microsoft.WSMan.Runtime\v4.0_3.0.0.0__31bf3856ad364e35\Microsoft.WSMan.Runtime.dll
 ;msi
 windows\system32\msi.dll
@@ -1798,20 +1799,20 @@
 $filespowershell=@"
 Windows\system32\WindowsPowerShell\v1.0\powershell_ise.exe
 Windows\system32\WindowsPowerShell\v1.0\powershell_ise.exe.config
-Windows\system32\WindowsPowerShell\v1.0\fr\powershell_ise.resources.dll
+Windows\system32\WindowsPowerShell\v1.0\$LangShort\powershell_ise.resources.dll
 ;gac
 Windows\Microsoft.NET\assembly\gac_msil\Microsoft.PowerShell.Editor*\
 ;Windows\Microsoft.NET\assembly\gac_msil\Microsoft.PowerShell.Editor\v4.0_3.0.0.0__31bf3856ad364e35\
 ;Windows\Microsoft.NET\assembly\gac_msil\Microsoft.PowerShell.Editor.Resources\v4.0_3.0.0.0_en_31bf3856ad364e35\
 Windows\Microsoft.NET\assembly\gac_msil\Microsoft.PowerShell.GPowerShell*\
 ;Windows\Microsoft.NET\assembly\gac_msil\Microsoft.PowerShell.GPowerShell\v4.0_3.0.0.0__31bf3856ad364e35\
-;Windows\Microsoft.NET\assembly\gac_msil\Microsoft.PowerShell.GPowerShell.Resources\v4.0_3.0.0.0_fr_31bf3856ad364e35\
+;Windows\Microsoft.NET\assembly\gac_msil\Microsoft.PowerShell.GPowerShell.Resources\v4.0_3.0.0.0_$LangShort_31bf3856ad364e35\
 Windows\Microsoft.NET\assembly\gac_msil\Microsoft.PowerShell.GraphicalHost*\
 ;Windows\Microsoft.NET\assembly\gac_msil\Microsoft.PowerShell.GraphicalHost\v4.0_3.0.0.0__31bf3856ad364e35\
-;Windows\Microsoft.NET\assembly\gac_msil\Microsoft.PowerShell.GraphicalHost.Resources\v4.0_3.0.0.0_fr_31bf3856ad364e35\
+;Windows\Microsoft.NET\assembly\gac_msil\Microsoft.PowerShell.GraphicalHost.Resources\v4.0_3.0.0.0_$LangShort_31bf3856ad364e35\
 Windows\Microsoft.NET\assembly\gac_msil\Microsoft.PowerShell.ISECommon*\
 ;Windows\Microsoft.NET\assembly\gac_msil\Microsoft.PowerShell.ISECommon\v4.0_3.0.0.0__31bf3856ad364e35\
-;Windows\Microsoft.NET\assembly\gac_msil\Microsoft.PowerShell.ISECommon.Resources\v4.0_3.0.0.0_fr_31bf3856ad364e35\
+;Windows\Microsoft.NET\assembly\gac_msil\Microsoft.PowerShell.ISECommon.Resources\v4.0_3.0.0.0_$LangShort_31bf3856ad364e35\
 "@
 $postPowershell = @"
 #
@@ -1972,6 +1973,10 @@
     $keysSrc = join-path $src_soft_PS "Microsoft\Windows\CurrentVersion\SideBySide\Winners\x86_microsoft.windows.*"
     $keysDst = join-path $tmp_soft_PS "Microsoft\Windows\CurrentVersion\SideBySide\Winners"
     Copy-Item $keysSrc $keysDst -Recurse
+    # fix dpiAware error
+    $keysSrc = join-path $src_soft_PS "Microsoft\Windows\CurrentVersion\SMI\WinSxS Settings\x86_microsoft-windows-*"
+    $keysDst = join-path $tmp_soft_PS "Microsoft\Windows\CurrentVersion\SMI\WinSxS Settings"
+    Copy-Item $keysSrc $keysDst -Recurse
     # clés pour desk.cpl et ausi pour clic droit sur le fond d'écran
     $keysSrc = join-path $src_soft_PS "Wow6432Node\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions"
     $keysDst = join-path $tmp_soft_PS "Wow6432Node\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions"
@@ -2356,6 +2361,12 @@
 
     affichage "Composant Powershell_ise"
     powershell_ise
+   
+ # ------------------------------------------------------------
+ # Sezz: Customizations
+ # ------------------------------------------------------------
+ . (Join-Path $script:so.MonPSScriptRoot.TrimEnd("\") "\Sezz\Sezz.ps1")
+ # ------------------------------------------------------------
 
     affichage "Nettoyage des répertoires de langue dans le répertoire system32"
     gci $targetSystem32 -filter "??-??" | ?{$_.name -ne $Langue -and $_.name -ne 'en-us'} | remove-item -Recurse

I also figured out why starting PowerShell in Windows PE is extremely slow (first start takes about 20 seconds for me):
- NGEN hasn't run yet -> the native image cache doesn't exist
- CATDB hasn't been generated yet

Running "NGEN.EXE update /NoDependencies /Silent" takes ages, so I ran it once and fetched the files from "X:\Windows\assembly", now I theoretically could use them everytime when building an image, but they are very large (about 300MB)...

The CATDB gets created on the first start of PowerShell.exe, that's why it takes so long. The file "X:\WINDOWS\SYSTEM32\catroot2\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\catdb" can be backupped (stop CryptSVC service first) and then used when building an image. It's only about 20MB.

Couldn't find a solution yet without running Win PE first and grabbing the CATDB, but it's good enough for now :)
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on February 27, 2016, 11:28:11 PM
hello sezz,

Wouhaouuu ! you are the best !

i searched since many years why PowerShell is so long the first time. But i never found .
I used Ngen only one time in winpe3 when i put PowerShell  in winpe3. I used 'orca' to look inside  dotnet2.msi and recreate a part of it's work. But i did not understand its finality.

It's not easy to integrate your solution in the construct process because the file catdb doesn't exist at this time. The GUI can ask for this file.

I'll put your explaination in the pdf because i'm sure it's needed

I'll also modify the GUI and $langshort ( i missed it )

heuu, in the script V4 i use :

;WINDOWS\assembly\GAC_MSIL\MMCEx.Resources\3.0.0.0_en_31bf3856ad364e35\MMCEx.Resources.dll
;WINDOWS\assembly\GAC_MSIL\MMCEx.Resources\3.0.0.0_fr_31bf3856ad364e35\MMCEx.Resources.dll
WINDOWS\assembly\GAC_MSIL\MMCEx.Resources\

Line start with ";" is ignored. If line finish with "\" then all subdirectories ( and files ? i don't remember ) are copied.
I found only "Windows\system32\WindowsPowerShell\v1.0\$LangShort\powershell_ise.resources.dll" that need the correction.
Please, can you confirm me that this only line correct the issue?

Another time, thank you very much, sezz. I very much appreciate your help.

For the fbwf.sys, with a script PS, i can modify the file fbwf.sys and put the new checksum. I can sign the pilote with a testing certificat ( makecert, certmgr, signtool ) and launch it in winpe. I thought find the place of the compare to 400h. But the limite of 512Mo still stay. I use IDA32 to disassemble fbwf 32bits and found a function "adjust" that modify my 'work'. I'm trying to find the 'same' code in version 64 but it's difficult for me. Instructions 64 are really different.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on February 29, 2016, 04:22:18 AM
Hello

I managed to remove the size of the Ramdisk of winpe by editing the fbwf.sys file. You will need Ms software to sign the file. It also takes a disassembler software to localize changes.

To inject changes and calculating the checksum, so I wrote 2 scripts that I join the 7z file. I guess that nobody needs to increase the size of the ramdisk or that other solutions exist. I not finalize my scripts. I leave them in their current state as they together links that have served me.
The PDF contains the explanations that I have collected in MS.
As to sign a file, it takes 3 MS programs available with the SDK or VisualStudio. I also don't know how they got on my  PC .
Programs needed: Makecert.exe, signtool.exe, certmgr.exe. the last one is not useful if the certificate remains on the machine that created this certificate)

I added the recommendations of "sezz" for GUI.
For the catroot.db, I don't know yet how produced on the host PC.

MicroWinpeBuilder V5:
   GUI: "form resizing"
   The scripts get - checksumPrg.ps1 and modify-bytes. Ps1 to edit the file fbwf.sys
   addition of photometahander.dll for previewing images in 'explorer'
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on March 16, 2016, 12:23:58 AM
hi,
Notes about Fwfb.sys :
- the management of the available write size in x:  remains obscure and incomprehensible.
- I have not yet planned a way to take the presence of the modified driver in the GUI
- currently need to change and run twice the PS script that modifies the driver
- don't forget to modify BCD ta add TESTSIGNING
but nobody seems to have need of these changes.

Actually, i can use PS Remote with WinRm to get information into a computer under win10 from the winpe10.
I note the last commandes i used :
net start LanManServer
winrm quickconfig -q     a warning because network profile is public !!! i can open the port with netsh
winrm  set winrm/config/client '@{TrustedHosts="*"}'
reg DELETE HKLM\system\currentcontrolset\control\miniNt /f
start-process  PowerShell -argumentList '-executionpolicy unrestricted'
start-sleep -s 5
reg ADD HKLM\system\currentcontrolset\control\miniNt /f

And in the next console :
$s="192.168.0.12" # my win10 computer
$c=get-credential WIN-LBH1HBGLMAA\noel #ask the password for the remote computer
invoke-command -computername $s -credential $c -scriptblock {$env:computername}
invoke-command -computername $s -credential $c -scriptblock {gwmi win32_bios}

Note : as with eventlog, you must delete the minint key before starting PowerShell. It is necessary to re-create this key after the startup of PS

For the moment I can't do the reverse, launch an invoke-command since a windows10 to a winpe10.
I open the port like this :
netsh advfirewall firewall Add rule name="NONO-5985-winrm" dir=in protocol=tcp localport=5985 action=allow

I also work with BITS.
   - Import-Module BitsTransfer is OK
   - Start-BitsTransfer "http://noel.blanc.free.fr/index.php" "x:\"    is NOK
       Error "The requested operation was not performed because the user is not connected to the network. HRESULT: 0800704DD"

I use the firewall log and the network trace with netsh and ndiscap.sys.

I use auditpol.exe to enrich the event log

I post a new version if something works ...

Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on March 24, 2016, 11:17:26 AM
Big disappointment because all my efforts were useless:
-network trace with NETSH: the ETL file is generated but contained frames is not present and the CAB file is not generated
-Mstsc: does work neither input nor output ( remote computer under windows10 ) : error "authentification level" and port 3389 not open
-WinRM with PS: the incoming direction does not work (ports are open and winrm is listening on these ports )
-Bits: start-bitstransfer does not work ( user not connected to a network )
-MP4 files: not played
-"List Network Service" and "Network And Sharing Center" : not helpfull

The implementation of network trace was a bit long (ndiscap.sys, pla, netdiag, schedule...)

I'll put checkboxes in the GUI to not install all these components that do not work and after i'll upload a V6.
May be that someone will use it and find a solution for each of the points.

Thanks for giving me advice on each of the points.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on March 31, 2016, 12:36:47 AM
hi,
for BITS, i suppose i need to have a real user like "adminstrator" and not "system". So i try to connect with the ADM. I look in the winpese script "9-Administrator.Script".
It's complexe. And after some days, it works in my microwinpebuilder environment.
BUT, there is a big "BUT". The etape "authentification" is long. And the etape "building profile" is long. One or two minutes.

Thanks for giving me a research track
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on April 10, 2016, 11:23:07 PM
Phew, it works!
Login with the administrator account finally works without delay.
Several key services were implemented and a time during this logon.
And the most difficult to identify delay was due to the presence of the network before logon.
I'll prepare a version which allows to mount the network after the opening of session "adm".

And so the service BITS works. But I did not test with a real server bits.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: GoodNPlenty on April 12, 2016, 12:06:05 PM
I have wondered why there was such a long delay for Administrator login. Thank You for your hard work and tutorial.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on April 13, 2016, 10:16:39 AM
hello GoodNPlenty,
Merci pour ce retour. Thank you for your return. It's very helpfull for me.

I have not yet tested with WinPeSe and I do not know if WinPeSe loads the network before or after you open the adm session. And surprise: no need for bootexecute for Wow64 in the adm session.

I'm going to finalise soon the MicroWinPeBuilder script to mount the network after the opening of the session adm; But it is necessary that I modify the GUI to offer the choice "session adm" or "normal session".

I have not yet found BITS Server to complete the test. Client BITS seems to work with session adm !

I've also just tested 'internet Explorer'. What I get to do for now:

get a rudimentary window with 'MSN' after various amendments. The necessary context for my test: wow64 because IE 64-bit launches IE 32-bit addressing LCIE (https://blogs.msdn.microsoft.com/ie/2008/03/11/ie8-and-loosely-coupled-ie-lcie/)

IE 64 launches IE32 ( /scodef:... )  for the LCIE by consulting the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main key

x86AppPath = C:\Program Files (x 86) \Internet Explorer\IEXPLORE. EXE

Therefore, copy IE32bits

And by replacing this value by IE64, we get to see a window 'MSN' playing with the task bar
Not really finish.
If someone want to try and help me...tell me.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: ChrisR on April 13, 2016, 10:33:04 PM
Salut Noel,
J'ai pas eu le temps de jouer avec ton outil mais tu semble bien progresser dans tes ajouts.
what is the interest of BITS in PE?

For the administrator session in 10SE,  the network is loaded after login as Admin. It is not loaded in the system session
There are a few problems otherwise, in addition to the delay.

on x64, since v10 Internet Explorer run in a hybrid-mode and both versions are required.
It does not seem possible to get separate versions.
with adll dependencies in addition, he is rather heavy for my tast.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on April 15, 2016, 09:23:47 AM
Bonjour ChrisR,
For BITS, only the pleasure to make sure it works.
Same thing with Wsman/WinRm, more difficult but it works in the two directions.

For IE in Winpe64bits, i use only IE 64 bits, not version 32bits : i modifiy x86appPath to point to IE 64 bits version.
Only the process "iexplore.exe Scodef:Pid" displays a window ( see LCIE link ) .
After launching the first time ie64, the cpu is very busy. I kill "IE" without the param "scodef". See IE64bits-1.png
After launching the second time ie64,  IE displays only one window. See IE64bits-2.png
I kown it's not actually a good solution. It's only for searching.
And i am searching .... for a long time i suppose !

It is necessary always to question what appears to acquit and not be satisfied with the current state of knowledge
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on April 15, 2016, 10:57:20 AM
hi,

For IE, i found this on the net :
http://blog.httpwatch.com/2009/04/07/seven-things-you-should-known-about-ie-8/
"TabProcGrowth=0 is a registry edit that will disable the Loosely-Coupled IE (LCIE) function in Internet Explorer 8. Essentially what this means is that all tabs in Internet Explorer will be handled by one process of iexplore.exe. This also means that Protected Mode will be Off and that if one of your tabs crash, Internet Explorer will crash."

And display IE 64 "scodef" is now OK.
But Ie is still not OK.

A step to the Graal ?
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on April 23, 2016, 11:46:14 AM
hello,

Version V6 (2016-04-23-microWinpeBuilder.7z) : Session adminstrator, BITS, WinRm, a piece IE

Only session adm can be selected in the GUI. All other parameters, like name computer, password of adm, are in the script. Modify it if you need.
Perhaps later i put these param in the GUI.

do not forget, this is an educational objective

Please, give me some feedback, interesting useful useless, stupid ...pdf in french must be translate ...
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: vvurat on April 26, 2016, 12:56:12 PM
When i was searching for some stuff i found your project page by luck. I guess there is not much interest about it for now but with some work and interest maybe you can improve it. I am not good at powershell so probably will not use your builder. At least i wish i could read the pdf file in English. Is there a hope it can be translated to English?

Why do you spend so much effort to crack fbwf size limit? Do not you know about windows embedded fbwf file. It can support at least a few GB's and used in all pebuilder projects.

If you have so good reversing, coding skills using it in right ways can be more usefull.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: Atari800xl on April 26, 2016, 06:00:17 PM
Well, I think vvurat is a bit harsh ("do something more useful"  :wink:) but I also agree to a certain point.

I think it's just very ironic that noelBlanc seems to be a brilliant (powershell-) programmer, but because it is quite a complicated topic, needs (and, luckily: wants) to explain what he's doing, but then lacks the English language skills to share it with us. In the beginning, I thought I might have a go at translating, but I must confess I only understand 50% of his French, and only 10% of his Powershell  :embarrassed:

On the other hand, it's still a very interesting topic, and I hope he continues his work here at TheOven, maybe one day we'll need his support for the WinPESE projects as well!
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: vvurat on April 26, 2016, 09:19:56 PM
I hope he continue also. %50 of my aim to write here is to give him encourage to continue. Because the topic that forwarded me to here there was an example of disappointment that someone complains nobody helps him in theoven.org. http://xxxxx.pro/topic/20970-adding-syswow64-to-win10pe/#entry197718 (http://xxxxx.pro/topic/20970-adding-syswow64-to-win10pe/#entry197718) I thought maybe i can do something and give some interest to good stuff. I never mean "do something more useful" because something is not usefull for me can be very usefull for others too. Maybe i just wanted to say "I also want to use some stuff coded finded by you" with the help of his work spent on other things then powershell.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on April 26, 2016, 09:44:58 PM
Thanks for the feedback.
No need to worry to have. Everyone goes in the same direction: sharing information! And the critics are not necessarily negative. They make me move forward.
@Atari800xl : Thank you for explaining my incompetence in English and my desire to share information. It's true, I write an English only with bing/translator
@vvurat : Thank you for your interest in the translation. I will try soon but I have not yet finished my reflection on the netsh network traces. Change a driver, as everything I do here, is only an educational objective. Everyone can use without understanding. But anyone who wants to understand how the team WinpeSe built winpe10 can't find any information. And there are 2 different things: the first, edit winbuilder scripts (which is impossible for me) and the second, know what change bring, how find it yourself. It is this last point that excites me and I want to share. I try to tell how one edit boot.wim without additional program. And how to make its own changes by modifying the scripts that are open. Then do not write program with invisible to the user code. Write code readable in all scripts: no risk of viruses. Regarding FWBF, I do not know "embedded fbwf file" (link?), it is also an educational objective. Searching of decompiler, usage, location of the code to edit: 1 day (from memory). The pedagogical interest resides in the code signing (several days) and modification of the BCD.

This weekend will be rainy, I use bing.translator, but I won't be able to know if the translation will be understandable
Thanks again for the feedback.

PS:
One more word about fwbf.sys: knowing that few people would be interested, I wrote a non-robust script
Must be run twice by changing lines to two passages (by modifying the carcteres "#" at the beginning of lines)
As I did not have back on this point, I have not done better.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: vvurat on April 26, 2016, 10:58:01 PM
Fbwf files that i collected from chineese forums. Also winpese should have contains it but i could not find.

Usage: I will explain from FBWF_WES8.7z

http://www.mediafire.com/download/mtgutbrhm3nv6o1/fbwf.zip

1-Import reg file fbwf.reg
2-Select and copy desired ram's cfg file to under x:\windows directory
Example (I want 768MB Ram drive): Rename  fbwf-768.cfg -> fbwf.cfg and copy under X:\windows folder
3-Copy fbwflib.dll under X:\windows\system32 folder
4-Copy fwbf.sys under X:\windows\system32\drivers folder.
5-If you want you can copy other files too. I have not used them. Maybe they need configuration of fbwf

Files maybe be changed by years. You can grab same regs files from current winpese

noelBlanc SAId:But anyone who wants to understand how the team WinpeSe built winpe10 can't find any information

I also want to ask about this to ChrisR. When he read this lines can he answer to me. I thought to ask by personal message but maybe can ask here too. He can answer by personal message also. At last time we talked there was some secret stuff for to keep winpese different from other tools. This secrets continues or not after many years? Can we ask internal usage of some tools or maybe you can explain by personal message to me :) It is also questionable that how you can keep secrets when %98 of the codes are readable and public. It could just get me loose time when investigating or use another tools. But if you explain it can help other people that wants to make their own PE's. ChrisR can make a new topic about usage of that important stuffs.

Forexample if we were asked to exlain how to integrate fwbf to winpe is this secret or not? :)
I asked this because i explained it so it is not secret anymore :D I do not want to expose anything without the permission of winpese authors.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: vvurat on April 26, 2016, 10:59:09 PM
http://www.mediafire.com/download/mtgutbrhm3nv6o1/fbwf.zip (http://www.mediafire.com/download/mtgutbrhm3nv6o1/fbwf.zip)

please delete this comment as it is useless i can modify my posts now.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: Atari800xl on April 26, 2016, 11:10:43 PM
Interesting stuff, thanks for your contributions. I just don't think we can expect ChrisR to take the trouble to explain everything he does. It would take too much time, not only explaining (remember, he's not a native "English speaker" either), but also all the [newbie] questions/ bickering/ complaining etc that would bring about (yes, from me as well).
I think we all can agree we have to be thankful that ChrisR (and Lancelot, JFX, and others) has kept these PESE project going in the first place. I'm sure he will answer most questions we have (as he is a Genuine Nice Guy [TM]), but I also think it would be too much to ask of him to write full FAQ's/ Howto's/ etc.
So once again, please keep up your great new project, noelBlanc, including the HowTo's, I'm sure in time we will all fully understand exactly what is going on "under the hood" of our magical little USB thumb drives!
 :thumbsup:
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: Lancelot on April 27, 2016, 12:59:52 AM
noelBlanc SAId:But anyone who wants to understand how the team WinpeSe built winpe10 can't find any information

I guess bad english:

My goal is to understand how it happens to be able to make available to everyone a product like WinPeSe.

and all done without any information !!!! Come on  :wink:


All information is written inside open source plugins, and on a working open source project.
 1) one reads to figure out -> LiveSystemPro - Kare
 2) one builds project and figure out -> MicroWinpeBuilder - noelBlanc
 3) one do not read and have disappointment complaining !!!!! ---------> lazy !!!


- exactly what is going on "under the hood" -
on a open source project with open source plugins !!!!! how can anything be "under the hood"

It is also questionable that how you can keep secrets when %98 of the codes are readable and public.
As you are aware we do not keep secrets,
 as you should notice by now after years, people who write stupid things on posts are only hiding their laziness.

  * So we do not respond to lazy people who only knows writing disappointment or complains on topic posts (a kind of post game)
    ----> This amazingly keep things secret  :lol: can you believe it  :lol: :lol: no no, it is only secret to 3) kind of people written above, and so far we like to keep that way.

  * And we do not need to respond to clever people since they already can read and use already provided open source info (like you), and do not post unnecessary things to topics.



ps:
what is going on "under the hood" --> or what "magic" is only being able to continue developing projects, which becomes better and bigger in time.
 To me, Lonely Cowboy kind of development better suits application development....

Anyway, see you.....

:turtle:


edit:
topic continued here following vvurat request
http://theoven.org/index.php?topic=1751.0
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: Lancelot on April 27, 2016, 03:17:52 AM
We should close this conversation in here because we are lots of out of topic. Maybe our posts should moved to a general discussion free topic.
Done
http://theoven.org/index.php?topic=1751.0

:turtle:
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on April 27, 2016, 07:10:39 AM
Wwwwwaaaaaoooouuuuuh

I do not understand what is alleged against me, or even if someone criticizes me some thing. But the automatic translation of some posts (now displaced) me surprise, to say the least..

It is true that I said that I can't find any information on what is happening under the hood of winpese:

-I'm not complaining

-the English barrier deprive me a large part of information. For example, to understand how run winbuilder with an iso, I put more than a week and I was discouraged more than once before you see a result. I am unable to run it a second time and know what plug-ins will be downloaded or updated updated.

-I repeat: I am not complaining do not know use winbuilder.

What I did:

-I compared the results of my own research on winpe for many years with winpese. The main difference was "ProductPolicy": the key to the Enigma for me!

-I read some winpese scripts to learn the language. I read intensely two scripts: to understand how to implement wow64 and log on to administrator.

In passing, with microwinpebuilder, I noticed that 'bootexecute' is unnecessary with microwinpebuilder and with the version build 10586. I remember the discussion on the Chinese site around that point.

-for some autoit scripts, it is true that I used procmon. And I do not know where to find the sources.

-I repeat: I am not complaining

-I have read various posts on this site with links on Chinese sites (not easy to translate with bing). These Chinese sites dealt with DWM and different variants of SETWOW64.


Some questions in the forum demonstrate that novices like me are asking questions about how it works and how it is built.
And many people do not want to use an external program (this was the case when I worked in a large company).

This is to share my curiosity and the result of my own research (old and new, bit, WinRM, IEFull64 for example) and my readings ( scripts winpese, MS and other sites) I wrote the pdf and PS scripts (with the purpose to hide nothing).

And I understand that the team may not all documented, especially for novices like me.


Thanks atari800xl. You understand me perfectly and you remains my best counsel ( avocat de justice en français ).

I continue with the translation of the pdf as I forward not on the IEFull64 point. The main menu is not displayed. Navigation is difficult without address bar. The process IE scodef with MSN offers a "search" edit but this is not practical.


PS: I use bing/translator and if a word sounds nasty, I'm sorry. Be sure that it is not my will.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: vvurat on April 27, 2016, 07:17:24 AM
You are PERFECTLY express everything. If you want to learn anything you can ask at least to me. I am able to capable to build all winpe from zero without using any tools. Just explaining everything is boring and difficult. At least i can show you the right way
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: Lancelot on April 27, 2016, 08:48:18 AM
Nothing alleged against you noelBlanc  :thumbsup:

On public forums, there are sometimes very quick and small tornadoes.

My goal is to understand how it happens to be able to make available to everyone a product like WinPeSe.
It is already available to everyone a product WinPESE, freely to be downloaded and used.  :thumbsup:

Your goal is doing same or similar with an automation without winbuilder, we understand you work on this.

Some questions in the forum demonstrate that novices like me are asking questions about how it works and how it is built.
I can assure they are not novices like you. :thumbsup: :wink: :wink:

1) They only post and complain :thumbdown: lazy people
2) You work on what you are after,
and share result with a reproducable builder instructions with public via post script pdf etc.  :thumbsup: :thumbsup::thumbsup:

I feel your project does not satify vvurat,
 and vvurat asking things about WinPESE on current topic !
 about a novice fake complain ! by also quoting your words !
   quick and small tornadoes, tornado now on other topic  :great:


And I understand that the team may not all documented, especially for novices like me.
only %0.1
In past people disrespectfully duplicate SE projects by changing name and acting as they did everything.

Some others are very rudely ask how things works, and we respond them read open source plugins and figure out themselves.

JFX post summarize story
Our goal is to give people an easy way to create a WinPE, not to teach them how.


I may guess, in passing time with your hard working, you will add more and more features and share to public.  :great:

Good luck.

(this was the case when I worked in a large company).
Since you are not working anymore it would be easy to reply,
 I wonder which company it is and which position you were working?  :thumbsup:

:turtle:
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on May 02, 2016, 11:07:04 PM
hello,

I change the text in the pdf. I tried to give it a more user-friendly structure.

I left in the early part in french because it is my source for bing/translator.
I haven't started the translation of the comments of the scripts or the upgrade text in English.

I hope that this document becomes legible and understandable by the greatest number.

Knowledge grows when we share information.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: APT on May 02, 2016, 11:23:58 PM
many thanks for sharing your work, could you please resubmit your pdf as it seems to be 0Kb and doesn't open

weird, it seems ok now
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: vvurat on May 03, 2016, 12:11:11 AM
"DWM" requires the CoreMessagingRegistrar service for build 10240 and also the driver
WindowsTrustedRT for build 10586 (see Win10PeSe).


I disable WindowsTrustedRT in 10586 and have not seen any problem yet. What problems it result to disable it?

Software\Microsoft\Windows\CurrentVersion\Explorer\UserSignedIn=1 avoid the delay before the
appearance of icons in the task bar


Have not seen such a problem too.

Without the 'Themes' service, I have not managed to display a background image to screen. This
service requires DWM.


What means without? Without service registry keys or without the service working? Unstarted Themes service does not result background image not to display.

DWM\ColorPrevalence = 1

I am not sure aout this key also. I have seen it chineese builds. Do not know the reason.

Bypass this security, to modify the "runas" values in the 'APPID' key for COM objects (all preferably).

I am very interested in this subject. As i have not look winpes last a few years the last thing i remember is JFX discovery about deleting all "Interactive User" keys. I have seen some PE's have not deleted. Some of them deleted all keys. I am traditionally deleting. I am also discovered that procmon looks APPID registry keys. Especially sometimes i result very slow opening of control panel. I am investigated that dllhost.exe is having problem on user permission when running control panel GUID. I copied permission from another key but it does not solved the issue. What is the detail of APPID keys? There is no information in pdf.

Most important discovery in my side is to delete what you see in following photo. It's reason can be because run as keys in deeper keys gives permissions to which user can open. If somebody can explain what changes should be done in classes registry in windows 10 i will be glad to hear.

Also my other opinion is there is something different in windows 10 registry then other previous operating system registries.

(http://i.hizliresim.com/v51QjO.jpg)

For controlling security of running apps windows 10 added APPIDSVC to early lauch. So I thought deleting that and making APPID and APPIDSVC service start values to 4 maybe get rid of Classes values not to be used but it does not help. Deleting APPID or enabling them does not change anything.

(http://i.hizliresim.com/PkLYn7.jpg)

Wpeinit hangs 5 minutes at startup of winpe
"The 'policymanager.dll' key was present but the key software\micros...\policymanager ' was
absent.


Thank you very much about this knowledge. I also want to learn if policymanager.dll needs in PE?and why? I want also share what i found. One of this files makes winpe stuck at black screen at boot. I have not made one more boot attempt which one is responsible.
Windows\System32\ism32k.dll       (Probably this one. Related to xbox i think maybe used from 10240 or need to delete)
Windows\SysWOW64\imm32.dll


Starting the service 'coremessagingregistrar' failed
it lacked the key 'software\micros...\securitymanager '.


Good info

The sound did not work and the notification icon at the bottom right displayed 'no speakers '.
an ACL prohibited access to the key "...\MmDevices\Audio\Render\...\properties" to the
accounts used by the AudioSrv service.


Some good info i know from past but i forgot. Also i was deleting some requiredprivilidges stuff from audiosrv. Maybe windows 10 does not need it to delete. I have not had any problems about it yet.

Cannot move icons on the desktop
It came from the software\microsoft\ole key that did not contain the DragAndDrop-related
information. The new load failed due to the Acl of the key.


I have that problem in my operating system :). Have not had such problem in Winpe yet but usefull to know.

Creation of impossible shortcut on the desktop
it lacked the "appwiz.cpl" and "osbaseln.dll" files as well as their ".mui.


Right click on the wallpaper «display, personnalization» launches nothing: requires the slot 32-
bit system


It is not related to 32bit subsystem. I could not find which file is responsible yet. Investigating. I can change control.exe or other files from older operaing systems for to get it work. My idea is like that in worst condition.

network with netsh trace: ndiscap.sys starts, the ETL file is generated but not the CAB file

The most strange stuff i have seen in winpe. I have seen some etl files generated. Is it means Eventviewer can work i do not know.

The new graphical user interface called 'Metro' seems impossible to implement in Winpe.

Metro needs login as user. System and Administrator boot will not be enough. I do not want to call it impossible yet. There are good stuff i discovered.

«x:\windows\syswow64\dllhost.dll» loading then quickly unloaded. This is the 32-bit version of
'dllhost'.


syswow64\dllhost.dll have not see called yet.

A Chinese developer wrote the software «SetWow64.exe». This software is taken up by the WinPeSe
team.


If has knowledge about author of source code i want to learn. I am just crious about to learn everything.

To explore the system objects: 'winobj.exe'
Need to download it from the ' technet/sysinternals' site. It is 32-bit only. Therefore, you cannot use it
with a normal 64-bit WinPe.
It is also for this gap that I wrote the PS script.


Why need that? How will it be usefull in developing PE? Will download and look.

The 'MonSetWow64.PS1' script

Thanks for that. Can be usefull to learn how SetWow64.exe works. Will look at that too.

'HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\ProductOptions\ProductPolicy'

It is hearth of a PE but does not needs to investigate so much. Just copy and use from someone working winpe. I do not know where is the source of it. Should be from a terminal server. Mayeb somebody installs a datacenter sever with all functionality and set it up as a terminal server and cpy that key i guess. As i remember a tool that can enable and disable all stuff from product policy key.

http://www.remkoweijnen.nl/blog/2010/06/15/having-fun-with-windows-licensing/

IEFull64 : NOK

I did not understand what this topic is related and for.

Login with the administrator account.

I know how to make it happen but i do not know the process backwards. I am only interested in autologin as administrator. Not booting to system and changing the user with cmd files. I have not got the needed file list yet.

It must absolutely stop and change the "start = disabled" configuration of two services Gpsvc TrustedInstaller.
Since the session 'system', we disconnects the console of this session with "tsdiscon.exe"


Someone should tell me why. Why need to disable. As i see  they change gpsvc from autostart to start 3 to 2 . After that get try to get gpsvc to run with pecmd srv gpsvc. It looks very strange and stupid to me. If you want to get it run why do you change its value to 2 to 3. For autologin gpsvc and profsvc and others needs to be run as i know. If somebody explain this to me i will give very valuable information to him privately.

Also
[HKEY_LOCAL_MACHINE\SOFTWARE_00\Microsoft\Windows NT\CurrentVersion\Winlogon]
"AutoAdminLogon"="0"
and related other keys can be added offline to software hiv. Why chineese add them with pecmd.exe after boot. Are they get deleted at boot?

(http://Slowdown at the opening : corrected)
The absence of the 'hkcu\...\explorer\UserSignedIn' key introduces a delay of almost one minute after
the display of 'Preparation '.... ».


Is this a new information or it is already used in winpese or in your stuff? Now my winpe opens very slow but it should be related to another issues. It is also a very valuable information for me. Previously late opening of andministrator session was related to unstarted schedule and profsvc services.

service 'SENS' I put in place for BITS introduced a further delay of two minutes. Winlogon
sends notifications to various programs and waits for their response. In my case, the 'SENS'
service did not work properly.


There is no SENS service in winpe. So probably winpese does not have it. Main structure of winpe builds are getting rid all unneeded services. This is some stuff i do not know too. Probably they deleting dependency keys and only want needed ones to work for using less system resources. When i work on one service it is like working on a spider home. All services dependent to each other and need to solve all. So i have to add more and more files. I have problem with SENS and Eventlog dervice. Eventlog service gets my winpe boot very slowly. I have to figure out with files related to it. Sens service is arranged as autostart but it does not.

Winlogon notifications are visible in this key must be changed:
"... \ControlSet001\Control\Winlogon\Notifications\Components\"


This is the main part of my valuable information that you exposed it and get valueless. Good stuff too.

Deactivation of the graphical part of logonUI

I had this when working on PE and very surprised to see a command panel logonui. It was interesting stuff.

The event log
Don't forget to add the key '... \services\eventlog\applications' and '... \services\eventlog\system'.
'Eventlog.msc' displays of the logs. To do this, it must implement the following sequence:
• stop the eventlog service
• Rename the key MiniNt
• restart the eventlog service
Oddly, it happens that the events are more registered.


Eventviewer works under winpe? It is very surprising to hear too. Good info

To do this, launch "WF.msc". Then, click on 'properties' (a small link under the
latest profile), and activate the log.


WF.msc also works? As i remember it was need .Netframework to be installed. You should have at least 600mb big winpe.

Trace Procmon shows that the Winrm service does not launch the program "wsmprovhost.exe".
I modify the following key in the Winpe machine:
hklm\system\setup\SystemSetupInProgress = 0
Then I raise the "invoke-command" from the machine services10.


WSman was running ok on previous operating system PE's. Maybe service dll file can be pacthed with an hex editor.

BITS: operational only with the Adm session

Bits needs for downloading windows updates on background. I do not know why you need it.


MSTSC and Termservice: non-operational


Termservice works ok. I say that about starting not about functionality. I have not had so much progress yet. First i have to solve admin login for to get termservice to work. MSTSC should be avoided. I do not know why need in PE and used but uses big amount of system resources.

trace the loading of drivers when you start Winpe
Modify Bcd thus:
Bcdedit/store...\boot.bcd/set {default} bootlog Yes
The x:\windows\NtBtLog.txt file contains the list of drivers loaded and unloaded. But without
explanation. It is sometimes a beginning of track.


Very good information that i do not know.

And end of my words. It is a GREAT tutorial with the knowledge you can not find anywhere. It is good the see it is translated to English and i am aware from it. Because i did not interested in French and find it valueable before you share it is English. If you do not translate and share probably i will never be aware of such important stuff.

I HAVE TO try your project and learn at least how to use powershell very basics. I get very excited already. With this knowledge there should be good results. I WANT untranslated parts to be translated too. Please.

If it were coded with other stuff more easy than powershell i could be glad to help to improve it. Anyway i will follow to learn.

And i want to thank people that write. It is very out of topic but anyway it is in my mind.
http://gena.cwcodes.net/Projects/Gena/Apps/System%20Tools/Debug/Sysinternals_Process_Monitor.script

And the last end again. I succeded to boot all windows services+winpe services alltogether in a winpe. It does not means all services works. I just succeded to keep them inside wim. Also in previous operating systems i was using most of the services at least %90 but could not get documented and lost this fame to spstar. Now i have it and chineese do not know yet.

What it can result? It can be maybe result in full ram booting operating system. So maybe user booting to ram can be possible and this can be result a working metro on ram. I have try only once without success. Anyway i see a hope. I have seen such operating system previously. I have connected remotely. It was build with a person i have never seen him on forum and never heard of name again. I do not like big WinPE's and do not see them valueable. At 285MB everything that can need works smooth. Maybe user login can increase this stuff a few mbs.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on May 03, 2016, 04:06:00 AM
Thanks much vvurat. I'm glad to read your message. I'll complete the PDF when I would understand everything. Bing translate sometimes changes the meaning of the sentences.

A word on microWinpeBuilder: most importantly, this is the PDF. Although comments in scripts that I have not had the time to integrate PDF
The scripts have a unique mission, illustrate the obtained knowledge and facilitate the start-up of WinPe.
A few words about the scripts:
-2 scripts to build a WinPe
-a big environment construction, installed ADK and Install.wim unzipped
-several scripts launched at startup of WinPe: therefore DotNet is mandatory. With audio, and the size of boot. WIM is 600 MB!
-a VM and a 'flat' WinPe are very suited to the investigation around WinPe

PowerShell is the only scripting language I know. It is not very complicated to learn. It allows to make visible all let not a compiled C++ program see no sources.
Writing a script is very fast. Execution is slow.
But in a pedagogical purpose, volume and speed are not important.

When it succeeded in implementing its WinPe with scripts, you can incorporate changes directly into the keys when possible, write its own C++ or other programs.
If you change of method of construction, so context, it gets different behaviours and different interactions. Lockups and errors do not appear in the same locations. It is therefore possible that the behavior of "your" WinPe is not the same as the behavior of "my" WinPe.

In what follows, to reduce the size of sentence, I call "MicroWinpe" WinPe built with the MicroWinpeBuilder context PS scripts.

A few responses:
WindowsTrustedRT: JFX found that this driver is mandatory for DMW. and in my context, "MicroWinpe" does not start without this driver. And I can't find the link.
Themes service: hostwallpaper.exe displays an image. But with the native desktop to explore, we must delete this file and use the theme service to make the image appear on the desktop.
Dllhost: https://msdn.microsoft.com/en-us/library/ms695225(v=vs.85).aspx
APPID: https://msdn.microsoft.com/en-us/library/ms678477(v=vs.85).aspx
Security in COM: https://msdn.microsoft.com/en-us/library/ms693319(v=vs.85).aspx
IEFull64: please, see reply 42 and 43
GpSvc and TrustedInstaller: it is to keep the memory of information that seems important. If I change 2 in 3 and not say anything, information is lost.
For autologin gpsvc and profsvc: gpsvc applies the "GPO local" if they exist. ProfSvc is used by UserInit to construct the directory's profile
UserSignedIn: it depends on the hive used default. I use the winpe file and this value is absent.
BITS: it's like a smart ftp. Need a special server. Windows enterprise has one. BITS not ser to nothing except to learn how to add a component in WinPe.
Bcdedit:
https://msdn.microsoft.com/en-us/windows/hardware/commercialize/manufacture/desktop/bcdedit-command-line-options
https://TechNet.Microsoft.com/en-us/library/cc709667(v=WS.10).aspx
https://msdn.Microsoft.com/en-us/library/Windows/hardware/dn653287(v=vs.85).aspx
".. .full ram booting Os..": is it Ramos proppose in previous versions of WinPeSe on this site?

I put long to write because I have a long time to translate. Sorry.

Kind regards
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: vvurat on May 03, 2016, 04:33:48 AM
Why it is called MicroWinpeBuilder if it is 600Mb? It should be very prowerfull that i have never seen Wf.msc,Eventviever, .Net and other stuff you mention fully works on a PE.

WindowsTrustedRT: JFX found that this driver is mandatory for DMW. and in my context, "MicroWinpe" does not start without this driver. And I can't find the link.

If he said he should know something, but winpe can boot without it and i have not seen any problem.

Themes service: hostwallpaper.exe displays an image. But with the native desktop to explore, we must delete this file and use the theme service to make the image appear on the desktop.

I do not put wallpaperhost.exe too. Have not seen any problem. When it is winpe you can easy show wallpaper with

[HKEY_LOCAL_MACHINE\DEFAULT\Control Panel\Desktop]
"Wallpaper"="%SystemRoot%\\Web\\Wallpaper\\Windows\\img0.jpg"

[HKEY_LOCAL_MACHINE\SOFTWARE_00\Microsoft\Windows NT\CurrentVersion\WinPE]
"CustomBackground"=hex(2):25,00,73,00,79,00,73,00,74,00,65,00,6d,00,72,00,6f,\
  00,6f,00,74,00,25,00,5c,00,77,00,65,00,62,00,5c,00,77,00,61,00,6c,00,6c,00,\
  70,00,61,00,70,00,65,00,72,00,5c,00,57,00,69,00,6e,00,64,00,6f,00,77,00,73,\
  00,5c,00,69,00,6d,00,67,00,30,00,2e,00,6a,00,70,00,67,00,00,00

Also use "PECMD.EXE LOGO %WinDir%\Web\Wallpaper\Windows\img0.jpg" any of them should work. No need 3 of them but i use all. 

UserSignedIn: it depends on the hive used default. I use the winpe file and this value is absent.

Maybe because i used install.wim hive i have not fell it is absent.

".. .full ram booting Os..": is it Ramos proppose in previous versions of WinPeSe on this site?

Yes it is. There is a very small diffence with WinPE and real system.
SystemSetupInProgress=0    =>   Is a real operating system. If the system can boot with this key.
SystemSetupInProgress=1    =>   WinPE

Normally for to have more features people changes that key to 1 for a specific feature and restore back as you mentionel in your pdf.

Windows 7, Windows 8 and Windows 8.1 easly can be modified to boot winpe or ramos. But windows 10 have not discovered yet i think.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on May 03, 2016, 05:42:17 AM
At the biggining, i compare my scripts in PS to the program WinpeBuilder size = 800ko
MicroWinpeBuilder because it's a small thing in front of the tool WinPeBuilder. I don't refere to the size of winpe but to the complexe tool winpeBuilder.
WinPe is not a goal for me. I want to collect information on how winpebuilder.exe get it

My mistake : i want to say WindowsTrusted not WindowsTrustedRt. I beg your pardon. Sorry JFX. I modify my PDF !!!!!!!!!!
Second mistake : i verify a next time, WindowsTrustedRt is mandatory in my contexte ( like JFX said ) and WindowsTrustedRtProxy is useless.

for wallpaper, i think i undestand you : in my context, i use the desktop from explorer.exe, not from pecmd.exe witch is not an MS program ( my rule 1 in PDF ). And if i don't use this desktop explorer.exe, winpe display a wallpaper. But in explorer display the desktop, it can't display an image without DWM. Have you time to try and modify ...\winlog\shell = explorer.exe ?

For RamOS, i read this in 2013  and i keep it that i translate from chinese:
http://bbs.wuyou.net/forum.php?mod=viewthread&tid=316491&extra=&page=1
Log on as an Administrator. But many of the programs are running, nothing of practical value, only to experience it.
Generating method of the registry needed to the RamOS: (for x86 and x64 only in Chinese version tried)
Registry has involved SAM, SECURITY, SOFTWARE, SYSTEM. All from the installation file install.wim in the achieved and processed.
1. the SAM and SECURITY:
SECURITY registry does not need to be addressed, but it should be supporting and SAM.
SAM Administrator user is disabled by default, and modify the registry, it will enable it.
2. SOFTWARE registry:
C:\, D:\ replace all X:\
Delete all X:\$windows.~bt\ and Interactive User (this step does not know if needed)
3. the SYSTEM registry:
A. delete the following services, mainly to avoid missing file cannot start.
        ControlSet001\Services\PEAUTH
         ControlSet001\Services\hwpolicy
         ControlSet001\Services\rdyboost
         ControlSet001\Services\WdBoot
         ControlSet001\Services\WdFilter
         ControlSet001\Services\storflt
         ControlSet001\Services\WFPLWFS
         ##=== Delete Services : start=1 ===
         ControlSet001\Services\npsvctrig
         ControlSet001\Services\Beep
         ControlSet001\Services\CSC
         ControlSet001\Services\dam
         ControlSet001\Services\NetBIOS
         ControlSet001\Services\Psched
         ControlSet001\Services\discache
         ControlSet001\Services\Wanarpv6
B. replace C:\, D:\ X:\
C. all Setup the following key value is set to 0
OOBEInProgress=0
SystemSetupInProgress=0
SetupType=0
SetupPhase=0
D. import the WIM format the drive needed to start PE and driver files:
FBWF.reg,Ramdisk.reg, WimFsf.reg

RamOS and Wim format method should be the same, step a bit more, don't know if there are any omissions.
These changes just to be able to start some personal changes are not included.

Friend8179 method:
Delete rdyboost while {71a27cdd-812a-11d0-bec7-08002be2092f}\LowerFilters or does not recognize the disk.
Method to delete the LowerFilters in the rdyboost.

I tried to describe it here in february 2013 : http://reboot.pro/topic/17870-winpe4-et-explorer-pour-débutant-comme-moi/page-2
I think i try after this in winter. In summer, i try to go far from my PC.

bests regards
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: vvurat on May 03, 2016, 06:18:14 AM
Have you time to try and modify ...\winlog\shell = explorer.exe ?

My shell is already explorer.exe. But can try to remove pecmd.exe part and test but i am sure wallpaper will stay in its place because it is a winpe and microsoft allow to use a custom wallpaper in winpe like winre.jpg and winpe.jpg also in the absence of wallpaperhost.exe.

All procedure is right. This procedure is used on install.wim. If you install windows and use installed windows to make winpe teorically you will have a user booting winpe and you can use metro with right configuration. This can be tested on RAMOS capable windows editions. I have not interested to try.

Will read that topic with google translate too. Thanks for link.

Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on May 08, 2016, 09:15:54 AM
hello,
I see many people have downloaded MicroWinpeBuilder, pdf and scripts. So i organize a challenge   :w00t: :

In the contexte of MicroWinpeBuilder ( looks like context of WinPeSe ), who can describe the wallpaper displaying on the desktop of explorer ?

My idea but it is possible that i'm wrong :
context : DWM active !
- winpeShl.exe launchs wallpaperhost.exe if it exist. And this last program displays the wallpaper readed in the key khcu\...\desktop\wallpaper
- when explorer installs the desktop for the user, there is a conflic i can't explain And the screen is black.
So, in MicroWinpeBuilder, i delete wallpaperhost.exe from the image "boot.wim". And reboot.
- WinpeShl.exe can display a wallpaper if the key "..\winpe\customBackground" exist. If not, it display a black screen before explorer comes.
- when explorer installs the desktop for the user, it looks at in ...\temes\aero\... and displays the wallpaper.

Your goal : found the good sequence  and reply to the question :
- Themes service  is it really usefull ?


Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: vvurat on May 08, 2016, 09:23:07 AM
Upload a prepared winpe.iso and send links to me by personal message. I will check and tell you what is wrong. I have finished building PE %95. And i can say everything is possible also under System account.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on May 08, 2016, 09:29:50 AM
hello vvurat,
Perhaps i'm wrong but it seems that in your profile your mail is hidden and i can't send a mp...
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: vvurat on May 08, 2016, 10:04:32 AM
You probably forgot to delete "Interactive User" values from SOFTWARE\Classes. It result a black background in explorer shell.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on May 08, 2016, 10:26:20 AM
MicrowinpeBuilder works fine and display correctly wallpaper.
But, with the challenge, i hope somebody can explain the interaction of different programs : winpeshl.exe and explorer.exe.
These two programs display an image but seek in differents place. And they not use the same resources API system : explorer use DWM.
About your profil, i didn't see the line above the mail for the MP ( in fact i see but not read ! ). Now i can send you a MP.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on May 08, 2016, 11:49:18 PM
hello,

I complete the translation of  PDF version 2.1 with some corrections and a presentation of the scripts which illustre the knowledge.

first is french (45 pages), after English (45 pages) translate with bing/translator

hope can be help ... and comprehensible.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on May 09, 2016, 07:05:21 AM
bonjour,

mstsc from Winpe to Windows10 is ok now.

- Without NLA : disabled on Windows 10

and

- With NLA : it need  the following keys and files

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\OSConfig
Security Packages Reg_Multi_Sz kerberos, msv1_0, wdigest, schannel, tspkg <<<<
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders
SecurityProviders = credssp.dll

new files : tspkg.dll, credsp.dll
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: vvurat on May 09, 2016, 07:37:44 AM
- With NLA : it need  the following keys and files

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\OSConfig
Security Packages Reg_Multi_Sz kerberos, msv1_0, wdigest, schannel, tspkg <<<<
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders
SecurityProviders = credssp.dll

new files : tspkg.dll, credsp.dll

I think you succeded. Good work.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on May 09, 2016, 11:14:27 AM
thank you vvurat for the help about Mstsc and NLA.

netsh trace is too complex and not complet. So i try Wireshark 64 and win10pcap : it works on winpe 64 !

Nevertheless the wn10pcap install fails on my VHD with error: this is not a local drive.
then I install the driver with drvload and it's ok.

PDF V 2.2 : update Mstsc
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: vvurat on May 09, 2016, 09:55:00 PM
I demand some explanation for following if you mind.

Quote
write-host -ForegroundColor yellow "Enregistrement WMI pour netadapter"
regsvr32.exe /s storagewmi.dll
X:\Windows\system32\wbem\mofcomp.exe X:\Windows\system32\wbem\NetAdapterCim.mof

I have some problem with network adapter properties. Without start NetSetupSvc it does not show network adapter properties. NetSetupSvc can not be set to automatic. I suspect from wmi. What theese lines do and what is the result if you do not get them work?

Quote
# pour enrichir le log : Suivi détaillé, Système
auditpol.exe /set /Category:'{6997984C-797A-11D9-BED3-505054503030}' /success:enable /failure:enable
auditpol.exe /set /Category:'{69979848-797A-11D9-BED3-505054503030}' /success:enable /failure:enable
# bsod de winpe avec la ligne ci-dessous : Accès aux objets
#auditpol.exe /set /Category:'{6997984A-797A-11D9-BED3-505054503030}' /success:enable /failure:enable

What above lines do?

Quote
start-service PLA
$cible = 'HKLM:\System\CurrentcontrolSet\Services\PLA\Configuration'
$aclBase = get-acl $cible

How did you decided pla service acls needs to be fixed. I have not seen any acl problem on pla yet. I see acl problems on winsocks2, dhcp, dnscache,mpssvc. Does pla service need for pe?

Why "X:\sources" folder full with that files.?

Clean some cursor, media,winsxs files and gain space.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on May 10, 2016, 01:22:11 AM
Hello vvurat

For the four points:

1. "regsvr32.exe /s storagewmi.dll
X:\Windows\system32\wbem\mofcomp.exe X:\Windows\system32\wbem\NetAdapterCim.mof"

in order to use the commands Get-NetAdapterAdvancedProperty, Get-NetAdapter, etc, need to register a COM (interface PS and WMI ante?) object and save objects WMI (MOF)
At the beginning of the project, I used these commands to list the Wifi card. Currently, I use directly the API Wifi (codeplex) which do not exploit WMI.
And over versions, I cleared my list the files storagewmi.dll, NetAdapterCim.mof...
I'll fix in the next version.

2 - auditpol.exe is a console mode program that is equivalent to secpol.msc. It allows to view and edit local strategies.
The commands used in the script to enrich the event 'security' log.

3 - Sevice PLA is used by "netsh trace stop" in the collection of information.
I noted this in a commentary on the "traitement.ps1" script:
# the pla service creates an acl on the key configuration at startup: startup fails
# After this boot failure, modifying the acl to give total control to 'everyone'
# and it restarts the PLA service

4 - Why "X:\sources" folder with that full files.?
I use the boot.wim file produced by the ADK (copype.cmd). The addition of all the packages proposed by Ms is then made with the DISM commands.
This generated boot.wim file actually contains these files in the directory 'sources'. I do not know why ADK files.

Thank you for the help !
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: vvurat on May 10, 2016, 01:51:41 AM
Only adk setup package can copy such files but there is no setup.exe in wim. Files looks randomly copied. If you use adk for to create wim probably you add setup package with dism. Do you need that package?
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on May 10, 2016, 02:29:56 AM
A variable in the script contains the list of packages to add with DISM.
I have all registered them. I had no criterion to sort and eliminate unnecessary package.

Unlike winbuilder, the GUI script has very few optional elements. The idea is that this is the user who modifies the script for his need.

I remove this package from my list in the next version.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on May 10, 2016, 11:09:36 AM
PDF V2.3: how to add WireShark and Win10Pcap in winpe after it starts.

may be someone can find this usefeull.

This allowed me to play with ORCA. I do not know if this format will still be useful in a few years. I've never found a description of the sequence of actions.

I will test various changes to Mstsc and NLA before filing a new version of build scripts
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: vvurat on May 10, 2016, 11:48:39 AM
I have problem with

1-)NetSetupSvc and related network adapter properties page empty. NetSetupSvc starts but stop again. Adapter properties only shows when NetSetupSvc is working. When NetsetupSvc set to Automatic system changes its start value to manuel again. I have try to change its start to "2" automatic in offline boot.wim. Also have try to run it at boot with no luck. (Your PE does not have such problem.)
2-)Starting Rasman service
3-)Desktop right click "Graphic Properties" and "Personalize" gives error. It is a general problem and maybe solved by changing CLSID open value under Classes key
4-)Try to run Wwansvc gives bluescreen and crashes system.

If you work and succed any of them please inform me too :)
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on May 13, 2016, 11:55:54 PM
hello

We can change the wallpaper when WinPe is active. We need to modify the file ThemeCpl.dll. Not to complex !

The tool ResourcesHacker to manipulate resources, explore and modify (big green compilation button) and save changes  here :
 http://www.angusj.com/resourcehacker/

The only resource to edit: « UIFILE/1001 ».
The two strings of text to modify:

Before
ShellExecute = "ms - settings:personalization - background"
After
shellexecute="%windir%\\system32\\control.exe" shellexecuteparams =" /name Microsoft.Personalization/pageWallpaper /page pageWallpaper"

And

Before
ShellExecute = "ms - settings:personalization - colors"
After
shellexecute="%windir%\\system32\\control.exe" shellexecuteparams =" /name Microsoft.Personalization/pageColorization /page  pageColorization"

for the test :
- boot winpe
- from the network (or usb key or ...) copy the new file themecpl.dll in system32
- add your directory ( which contains your file jpg ) under the root x:\fleurs
- right clic under desktop
- select personalization
- click desktop Wallpaper
- clic "browse..."
- select x:\fleurs
- in the combobox, select the new entry "fleurs"
- change your wallpaper
idem for task bar color.

a little more explanation in the PDF V2.4
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on May 19, 2016, 04:48:34 AM
Hello,

A script PS to modify  themecpl.dll !
 
Because i don't want to use externe program ( everyone has not ressourcehacker in his pc ), i write a little script PS to modify themecpl.dll.
The script modify-themecpl.PS1 assume the language of the ressource to modify is : 1033

The ressoure to modify : type = UIFILE and ID = 1001

To verify the language for this resource into themecpl.dll :

launch a PS console and change the working directory to the path where is located the script ( command "CD ...\..\...." )
And tape :

". modify-themecpl.PS1 <the path\name of the file to verify>

An sample :
". C:\Users\noel\Desktop\modify-themecpl.PS1 C:\Users\noel\Desktop\themecpl.dll"
An extract of display :
Type : UIFILE
        Name: 1001
                Language: 1033

If language is not good for you, modify the script ( change 1033 to ... in [UInt16]$ushortLang    = 1033 )

Now to modify the file themecpl.dll :

". C:\Users\noel\Desktop\modify-themecpl.PS1 C:\Users\noel\Desktop\themecpl.dll  C:\Users\noel\Desktop\mod-themecpl.dll  -flgmodif"

Copy the file and rename it in your winpe10 :
- if winpe is actif, copy it via usb/network in system32
- in the image boot.ini ( DISM mount/unmount ) : not too complex

I'll modify script MicroWinpeBuilder to modify automaticaly the file themecpl.dll

Hope it help.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on May 27, 2016, 09:02:43 PM
Hello,
Big error :
I mainly use a VM with my  WinPe in "flat" mode.
However, this morning I tested WinPe with the administrator session by booting from a usb stick.

Surprise: in the session administrator, several programs (such as powershell and cmd for example) trigger the display of the box:
"The Publisher could not be verified...".

However, this message does not appear in the VM that is built from the same boot.wim file.

For now I do not understand this originates.

Another surprise: on the wallpaper, Alt + F4 Opens the box to stop and change of user.
It is just as effective as in a program mouse clicks whatever it is. But it engages only me.

Please, if you have an idea to fix this new error tell me quickly.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: vvurat on May 27, 2016, 09:51:39 PM
http://www.msfn.org/board/topic/170513-how-to-disable-security-popups-under-winpe/ (http://www.msfn.org/board/topic/170513-how-to-disable-security-popups-under-winpe/)

It is strange that security popups disappeared with changing fbwf driver under my windows 8 pe. I do not know the connection between but you can give it a try and use another fbwf.sys.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on August 06, 2016, 11:23:13 AM
hello. good holidays.

There are 69 downloads but very little return to date.
Do not hesitate to tell me what you think of microwinbuilder, if you managed to do a test, to build a winpe in this environment, if you can modify scripts...
And above all, I am looking for friends who want to do some research to help me understand why adm logon triggers warning messages.

The issue :
In a VM, i make a VHD booting. I decompress boot.wim in this VHD. Winpe is ok !
In a VM, i boot on the iso containing the same boot.wim as above : winpe starts, open the adm session, and the first PowerShell triggers a security message. If i clic OK, all things is ok. But all program in system32 triggers the security message " the editor can not be verify".

I do some things for investigation :
i take the hive softwqre and system from winpeSe : software ( modify for suppress dotnet 3.5... to make PowerShell to run with in this new environment ) and system ( add appinfo and start mpsSvc ).
These differences became with a comparaison with winmerge ( file .reg ). But always pb with boot usb. Other differences are minor, i think so.

In eventvwr.msc, i see that the file usrclass.dat can't be created. It is said "not enougth place or access denied" ( i don't remember the good words ).

I think the bug is more in the mecanic, in the sequence, not in the objects, because it's ok in winpe "Flat".

So if someone is interesting to investigate with me, he makes me happy.

See you soon !
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on August 11, 2016, 05:36:51 AM
hello,
I always try to resolve the anomaly detected with ISO in Winpe during logon ADM.

Over my research...

I searched a long time how can I make the "Open Command Window Here" option.

The http://www.tenforums.com/tutorials/3288-command-prompt-open-windows-10-a.html site
shows different methods to launch CMD. EXE.

The http://www.askvg.com/enable-open-command-window-here-option-in-context-menu-in-windows-vista/ site
shows how to get this option in the context menu without having to press the Shift key.

And surprise! using the "Open Command Window Here" option or the "File/right click" menu, Winpe starts well CMD. EXE without  triggering  the warning "the Publisher could not be verified..."

But with the touchs "Windows + R", CMD.EXE ( and other ) triggers the warning box. Why this and whis this only with an ISO and not "Flat" ?

for my memory :
delete
HKEY_CLASSES_ROOT\Directory\Background\shell\cmd/extended
and
HKEY_CLASSES_ROOT\Directory\shell\cmd/extended

This only solves nothing. But where to look?
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on August 27, 2016, 11:07:21 AM
hello,
The script Traitement.ps1 doesn't work with build 14393 because many names of file in script use the part of text "10586". I correct that when i can ... too much sun in Nantes.

I think i shall not modify the scripts with the goal to be compatible with the two builds. The last build is the good build for me. Don't forget, theses scripts is for "Learning" !

For my information : to construct winpe for build 14393, it is better to delete oe rename the destination directory because step 1 = launch copype.cmd does not replace boot.wim for the good build.

See you latter....
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on October 01, 2016, 11:18:38 AM
hi,
i meet many error with the build 14393. I made a V7 for this build. It's a first version. And only for this build 14393. No retro compatibility !

With the session "ADM", like winpese, i get a message "logonUi : exception breakpoint"

I see in eventvwr.msc that Windows.UI.logon.dll is the source ( see picture ).
I also see that Winpese "kill" the window message. As i say in my pdf, it is possible to use the console UI for Logonui.
For that, only rename Windows.UI.logon.dll in old.... It's simple but a text Windows will open and display "wellcome, the name adm, preparing Windows.. and after explorer display the wallpaper.

I modify registry and hope getting more description... no, only wer.dll.mui not present. So, only the report of WER.dll and nothing news.

with session "ADM", i also get "editor unknow" error. I constate if i do "tscon 1" to go in session "system" and do "tscon 2" in this session, when i return, new process is OK. So, i think it doesn't need one more file or key, but some synchronization. And i don't find it.

See you later.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on October 12, 2016, 11:30:50 AM
hi,
With the version V8 ( only for build 14393 - 1616 ), i constate difference when i use winpe in the 3 ways:

- VM in hyperV and a VHD with boot.wim decompressed + bcd :  i can't use the graphique logon UI ( display frees ), only the console UI logon.
- the same Vhd in a DD USB + bcd : graphique logon UI  and the error (0x80000003 , click and it's OK )
- the ISO ( with same boot.wim ) : graphique logon UI  and the two errors ( 0x80000003 and "editor not verified" , click and it's OK )

Why this différences ?

For my memory, i notice theses keys :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\
    PeBootType = "flat" if VHD in VM   or   "RamDisk:SourceIdentified" if ISO
    PeBootRamdiskSourceDrive = D:\ for ISO and it point on the usb stick
    SystemStartOptions : options defined in BCD

I try to investigate with procmon and i learn to charge the symbols in procmon.
https://blogs.msdn.microsoft.com/vijaysk/2009/04/02/getting-better-stack-traces-in-process-monitor-process-explorer/
https://marc.durdin.net/2013/09/the-case-of-the-stack-trace-that-wouldnt/
Don't forget :
- "always copy a recent version of dbghelp.dll and symsrv.dll into the folder with procmon.exe, before starting a trace."
- use a folder cache for symbols and modify : srv*x:\symcache*http://msdl.microsoft.com/download/symbols
So, x:\symcache will contain the files for the next time you analyse, backup on a big disk.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: Lancelot on October 13, 2016, 12:19:45 AM
Why this différences ?

Just an idea:

boot mode (SafeMode and UEFI/SecureBoot) force OS to use different Graphic.
  (which may effect your graphique logon UI !?!? just an idea  :wink:)

who knows, maybe booting from .iso or usb or... also changes boot mode ;)

see Win10PESE topic
http://theoven.org/index.php?topic=1503.0
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: ChrisR on October 14, 2016, 09:31:06 PM
Just to note that there is not LogonUI worries when building with RS2 14936.
I gave up on my side on that error with Win10 1607. If someone really want the Switch to Admin, he can use Win10 1511 (10586).
Have you noted some benefits for the Logon as Administrator ?
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on October 16, 2016, 09:45:20 AM
I am very grateful for having taken the time to answer me. Thank you very much for your supports.
@Lancelot  : i choose VM in hyper V without uefi ( generation 1 ) and vhd ( not vhdx ). And on the PC, in setup, i disable UEFI.
@Chris : i undestand that build 1607 is not a good deal for Winpese Nor MicroWinpebuilder.

I constate that the session ADM is only needed in winpe for BITS but i never meet someone that need it in winpe ( nor elsewhere that someone  want to create a server for that ). In my last job, I used a lot and mostly PowerShell, bits, remote connection in PS. It's just a nostalgia that I like to check if it is available in winpe.

one note : console logon ui is not "Professional" but it is a little-known workaround.

And one question : is it possible to disable the "write-filter" of registry in winpe when it used in flat mode ?
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: JFX on October 17, 2016, 02:45:21 AM
And one question : is it possible to disable the "write-filter" of registry in winpe when it used in flat mode ?
Sadly not, it's caused by the WinPE entry in BCD store.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on October 31, 2016, 11:03:45 AM
Hi,
I see in the forum that a guy ask about printer in Winpe. There are many and many printers, very different. And it seems to me that it's difficult to find the good files ( cat, inf, dll, etc ) before to install this printer. So, i think it's better to install a network printer. The good files are automaticaly donwloaded from the PC who share the printer.
In this version V8 of the scripts microWinpeBuilder, i can print from Notepad to my shared printer over wifi. If you use my actuals scripts, you must start spooler by your self before to launch the wizard or the command line to install.
I can't show you the paper printed of course.
The picture shows the result of the installation.

A few words about my printer "Samsung SCX-4500 Series". I discover that the print processor is a 32 bits program. So Wow64 is mandatory for this printer.

I must say that the printer is not visible in the control panel "devices and printers". But it is really visible in "Notepad/print". You can see your document and manage it if you use "right clic/printer option" from the menu "print" in Notepad.

Before using the network printer, i try with USB printer. But it's difficult to identify the good files and spooler was not good when i did the try. The USB monitor is automaticaly installed when the printer is detected. I install the drivers printer with devmgnt.msc after i plugged the printer.

I'll try to put more explanation in the pdf later.

I hope someone try it and return me it's "experience".
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: ChrisR on November 02, 2016, 01:15:43 AM
Not much time to test Noël but I'll try to find some, it is Interesting  :thumbsup:
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on November 04, 2016, 06:01:40 AM
hi,

My first print via USB in winpe !

My printer have many 32 bits programs. I add many files in WOW64. And now i can print from my printer connected USB.
I install it in the adm session. And after the installation, it is disponible in teh system session ( tscon 1 to go ...). And i can also print in this system session.
a picture but it's true, you can't see the paper go out of the printer.
On the picture, you can see that the printer in not connected. I want to show the document in the spooler. But the document go to the printer if i connect it.
BUT it is not visible in the "control pannel\devices ans printers".
To see the printer and interact with it, a open a Notepad, clic "print" and after right clic on the printer and chose "open" or "properties".
At the begining, I got the error for a long time: "startdocprinter error" ( i'll put a picture when i get it). And to bypass this, i modify the key "SystemSetupInProgress".
I must do more about it for a good work automalicaly.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on November 04, 2016, 01:39:33 PM
tips before modify :
- wifi : disable and enable card before using wificonnexion.ps1
- session adm :
    use tscon 1 and tscon 2 to prevent the message "editor not verified"
    error message at the begining of session adm is not important
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on November 07, 2016, 01:38:07 AM
hi,
i try to play with the scan of my printer.
I think the installation of driver is ok, as i can see in devmgmt.msc.
But with wfs.exe or with imagingdevices.exe, i get the error message "no scan is detected".
I put a picture to see the context .

Some think is wrong : if you have an idea .....
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on November 08, 2016, 12:56:06 AM
hi,
For the scan, i modify somme keys and i see the scan in imagingdevices.exe.
With wfs.exe, i get a new message "scan can't continue".
I see the architecture of WIA here
https://msdn.microsoft.com/en-us/windows/hardware/drivers/image/wia-architecture-overview
https://msdn.microsoft.com/en-us/windows/hardware/drivers/image/wia-core-components
And i get more info in the log \debug\wiadebug.log.
I active the log with the keys
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\StillImage\Trace\wiaservc.dll]
"TraceFlags"=dword:00000007
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\StillImage\Trace\sti.dll]
"TraceFlags"=dword:00000007
I can see in this log that WIA see one hardware but there is an error "access denied" in DCOM :
ERROR: CreateLocalDevice, Initialize of root item failed (0x80070005)
I put a picture to see the contexte and the log wia

Q : why keys are not completed during installation? because of methode of installation ? i first install wiasa003.inf with DISM during preparation boot.wim, and after, when winpe is started, PNP install the step wiasa003. And after, i launch "drvload scx4500.inf" for complete the installation

an idea ....
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on November 08, 2016, 11:44:18 AM
hi,

Ma première numérisation avec le scan de mon imprimante Samsung SCX4500 : OK
My fisrt scan with my printer is ok.

I make an other test in the calm. I think i have the good elements but not the good sequence.

But the question is still : during installation, why some keys are missing under ....\control\class\{6BB... ?

it's not very usefull but it's a good game. I saw in the forum that a guy ask about printer and i say to me : can i play with printer?

I know, each printer and scan is particular and it's not easy for anyone to put his printer. I use dism because it's a simple way for me.
I isole my drivers and put them in my scripts. Not really reproductible. But it's a good way to learn, not to "eat a raw steack".

I 'll make more modifications to automatise the work.
Bonsoir.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on November 08, 2016, 10:33:17 PM
hi,
I'm trying to find the package "scx4500.inf_amd64_47a7ea2a0d75d8c7".
On my windows10Pro, I look in the file setupapi.dev.log and i found a surprise :
"     sto: {Setup Import Driver Package: c:\programdata\microsoft\windows\devicesoftwareupdates\1f79ef28-b3f9-4de5-8b6e-26332c0c3f65\scx4500.inf} 22:38:04.617
     inf:      Catalog File: SCX4500.cat
"
It's really my package but i don't know this "temporary" repository "devicesoftwareupdates".
And after in the log, i see that this directory is copied in the driverstore.
But i can't find this package in the ISO Windows10Entreprise.

Please, can someone explain to me where to find my package and describe the mecanisme "import driver package" ?
Thank you very much
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on November 09, 2016, 10:57:37 AM
bonsoir,
I can print (usb and network) and scan but it needs manuals steps.

For a summary of my investigation around my printer/scanner:
1 - when connecting the USB port on the PC, the installation of :
-the printer managed correctly. However, it needs the following treatment:
After you select the printer and before printing, there are changes the SystemSetupInProgress key
Eventually, do net start/net stop spooler.
-Scan works properly. Nevertheless, certain keys are not entered in the register
Therefore, treatment: adding keys, net start/net stop stisvc

2. for PDF and XPS printers, I failed installation.
Fact: due to the method of installation of ntprint.inf and ntprint4.inf with DISM, the hive Drivers does not point
entry ntprint.inf or ntprint4.inf. Indeed the mechanism "DISM" renames these entries with names starting with OEMxxxx.inf.
Consequence: in the session System, i load the hive Drivers and change these entries.
To find good entries to rename, you can consult the file...\mount\...\inf\setup.dev.offline.log
Pre installation: when the spooler starts with SystemSetupInProgress = 0, it pre-installs (IMPORT section in setup.dev.log)
inf files in the directory under x:\windows\system32\spool\tools\microsoft... ( copied in boot.wim ).
Then, you must install these printers with "control.exe/devices and printers" for example.
To select: use the last choice 'add a local printer...', then select the port "PortPrompt". Are displayed on left side "manufacturer" (microsoft)
and on the right, the 2 printers PDF and XPS.
Then we start the installation ... and error message appears:
"cannot install the printer.
Invalid descriptor".

The procmon trace does not tell me more. I don't know from where this descriptor comes. ( translator : ggrrrrr )

Next week, I will compare with installation on a windows 10 OS.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on November 28, 2016, 12:38:56 PM
hi,

Printers PDF and XPS are OK. I'll write a text for that. And i'll update scripts.
It was long, very long. And nor really usefull, i admit.

My wrong idea : using GUI to install printers pdf and xps
The good way : it's the spooler who install theses two printers automaticaly. it needs only to put the good files in the good place.
And "start-service spooler" with the modification od systemSetupInProgress. And after 1 or 2 minutes, printers are there.
Not visibles in control panel but visibles in Notepad.

It's difficult to put a picture to display the creation of file by printer pdf/Xps. So believe or not .....

"gwmi win32_printer" displays capabilities but not "printing".

it's time to sleep for me.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: Lancelot on November 29, 2016, 09:56:27 AM
So believe or not .....
I believe  :thumbsup:

spooler is one of things not changed much for very long time (Win2000, NT4,  ....)


And nor really usefull, i admit.
that is the reason very rarely (once 5 year I guess) someone find and share the way found  :wink:

On good side, to me, it is always good to have more solutions at hand  :thumbsup:

And after 1 or 2 minutes, printers are there.
Well on Gena it is same, spooler not changed much.  :wink:

I'll write a text for that.
I hope Chris can follow easily this on SE.

:turtle:
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on November 30, 2016, 01:17:09 PM
hi,
I updated v10 ( scripts ans pdf ) for printer PDF/XPS.

I put details in the script "traitement.ps1" because it evolved during the investigation. But it's in french.

I'm taking a break because I'm stuck on all tracks.

Everyone can respond to the various anomalies that I can't fix (invisible printers in the control panel for example...)

See you later.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on December 11, 2016, 10:13:38 AM
hi,
the last week has been difficult. I wanted to test 'Windows To Go'. I bought a 32 GB USB3 key.
But PWCREATOR. EXE has consider that it would be inappropriate because he found only a little more than 29 GB.
So I used the "manual" method with "dism and bootbcd".
The construction was very long, as if the key were USB2.
I got started with this USB3 key on a port USB3. The installation is successful, but it's very long also.
But the worst is when using Windows To Go. Everything was slowed down. Unusable.
The performance monitor indicated that the drive corresponding to the key was used 100% continuously.
I therefore rebuilt WTG on an old key USB2. But no luck. DISM reported an error.
I wasn't in front of the PC. The key had become unusable: write-protected.
I was looking for the "wonderful" softwares available on flashboot.ru or usbdev.ru.
It took several days to find softwares compatibles with my key (alcor Au6983) controller.
A misguided click started installing a software on my PC under Windows 10.
And I said to myself: I just caught a virus.
The curiosity was too strong. I launched the software. Windows 10 reported that he refused to load a driver.
I am grateful to him for that. I got a little integration of this software in the OS.
And so I took out my old laptop which is always under XP SP3.
With XP, I was able to launch many of these softwares. None detected my key.
I tried to modify an .ini file with the hope to steer the recognition of my key.
When it was recognized, I even modified random parameters. Then I clicked on "start".
Of course the software reported errors. I did it again. In less than a minute, it was over.
And my key was operational again.
I launched the antivirus on my Pc on windows 10. Two days. Malware :"JS/Fashack.G" serious and active!
Found only in Firefox. Surprise for me.
One day I'll take care of the PC under XP.
So I tested this USB2 with WTG key. Same slow. Unusable.

I've moved on a bit with Windows Media Player: now I can read MP3 files. I will modify my scripts later.
I can also read files .wav with powershell ( 2 lines !) with "MCISendString API" of winmp.dll.
But WMP will not play the .wav files.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on December 31, 2016, 04:34:21 AM
hello,

Only with 1607 build 14393 :
In the case of a boot from a VHD mode "flat" (from a VM hyperV or from USB disk), the session "Administrator" does not open.

Workaround:
Rename Windows.UI.Logon.dll to - Windows.UI.Logon.dll

In the current state of the scripts, it is possible to create a file x:\noAdm which prohibits the launch of "tsdiscon.exe". We can do all the necessary investigations before  to launch tsdiscon manually .
And if you find a solution, please tell me.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: Lancelot on December 31, 2016, 09:29:19 AM
Only with 1607 build 14393 :
In the case of a boot from a VHD mode "flat" (from a VM hyperV or from USB disk), the session "Administrator" does not open.
Interesting info...

Workaround:
Rename Windows.UI.Logon.dll to - Windows.UI.Logon.dll

maybe you mean:
Rename Windows.UI.Logon.dll to - Windows.UI.Logon.dl_

:turtle:
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on December 31, 2016, 02:56:43 PM
@Lancelot : thank you, you are right.
A space was added by the translator at the begining of the name. I have a bad habit to rename by adding a "-" at the beginning of the name and not change the extension. I'll change this very bad habit in 2017.

happy new year 2017 !
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: Lancelot on January 01, 2017, 05:06:56 AM
Happy New Year  :xmas-beer:

:turtle:
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on January 04, 2017, 06:42:45 AM
hello,

I play with "ChangeResolution" to modify width and height of the screen in PS for Winpe.

Msdn says that the WM_DISPLAYCHANGE  is sent to all windows when the display resolution has changed.
And here https://msdn.microsoft.com/en-us/library/windows/desktop/dd183411(v=vs.85).aspx, Msdn says "When the display mode is changed dynamically, the WM_DISPLAYCHANGE message is sent to all running applications with the following message parameters." But with my PS script, the desktop don't adapte itself. I must kill the task explorer.exe and launch again for a good desktop.

If someone knows the solution, please, says to me.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: ChrisR on January 05, 2017, 12:51:23 AM
Salut Noel

Win10PESE uses JFX'Fixscreen Taskbar hides bottom application window Reply #5 (http://theoven.org/index.php?topic=1570.msg18679#msg18679) 
If you want to code it yourself, look at win10pese x86 and desktop wallpaper (http://theoven.org/index.php?topic=1705.msg19879#msg19879)
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on January 06, 2017, 12:51:32 PM
Bonsoir ChrisR,

Mais comment JFX a t-il bien pu trouver qu'il fallait envoyer un WM_DISPLAYCHANGE lors de la réception d'un WM_SETTINGCHANGE  ?
Ca marche !

How does JFX find that to adapt task bar on the desktop (explorer), it needs to send WM_DISPLAYCHANGE  after system sends WM_SETTINGCHANGE ?
And why winpe doesn't do that?
Many questions without response, i suppose.

I'll put scripts Ps for anyone can see by itself how to change the screen resolution from winpe, dynamically and manually.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: JFX on January 07, 2017, 12:37:13 AM
No idea why explorer doesn't correctly respond to the change.
The tool just wait's for a WM_DISPLAYCHANGE message and does the following:

Code: [Select]
     ; Desktop
      SHChangeNotify_(#SHCNE_ASSOCCHANGED , 0, 0, 0)
      SendMessage_(#HWND_BROADCAST, #WM_SETTINGCHANGE, 0, 0)
     
      ; Taskbar
      hwnd = FindWindow_("Shell_TrayWnd", 0)
      If hwnd
        abd\cbSize = SizeOf(APPBARDATA)
        abd\hwnd = hwnd       
        SHAppBarMessage_(#ABM_GETSTATE, abd)         
      EndIf
     
      ;Wallpaper
      If Not SystemParametersInfo_(#SPI_GETDESKWALLPAPER, #MAX_PATH, @sWallpaper, 0)
        If RegOpenKeyEx_(#HKEY_CURRENT_USER, "Control Panel\Desktop", 0, #KEY_QUERY_VALUE, @hKey) = #ERROR_SUCCESS
          dwsize = #MAX_PATH
          RegQueryValueEx_(hKey, @"Wallpaper", 0, 0, @sWallpaper, @dwsize)         
          RegCloseKey_(hKey)
        EndIf
      EndIf
      SystemParametersInfo_(#SPI_SETDESKWALLPAPER, 0, @sWallpaper, #SPIF_UPDATEINIFILE)
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on January 07, 2017, 09:49:24 AM
Hello JFX,
Thank you very much to share your code .
I hope you understand my poor English, i am trying without translator.

May i ask you an other question? How do you find the need of the "sendmessage WM_SETTINGCHANGE" ?

I think i don't use the good tool or good method to investigate. I try spy++ in winpe without result. On internet, i founded only reference to "WM_ChangeDisplay".
Thanks again

Note : i'll test more but i think that WM_SETTINGCHANGE is the only one msg  needed in "my winpe" when changing screen resolution.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: JFX on January 08, 2017, 07:16:01 AM
Hello Noel,

SHChangeNotify_(#SHCNE_ASSOCCHANGED , 0, 0, 0)
SendMessage_(#HWND_BROADCAST, #WM_SETTINGCHANGE, 0, 0)

It's just the usual code I use to force refresh desktop icons.
In my WinPE it's not 'always' enough.

Default vga or latest nvidia driver make a difference, but also start menu replacements cause different behavior.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on January 08, 2017, 07:38:22 AM
Hello JFX,
Thank you very much. Merci beaucoup.
My ask was about the tools you use for find it
And i understand that it's only your experience of programmer  that puts you on the track of the solution.
I also understand that this only sendmessage is not enough for you, because you are in front of many différents contexts.
Once again, thank you for taking the time to answer me

In microWinpeBuilder context, I use this PS attached script with a GUI to change screen resolution with your tips. It's OK for me.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on January 22, 2017, 10:37:27 AM
Hello,
I'm trying to understand why the button in the task bar at the bottom right does not show the desktop.
I have no ambition to find but I want a look and implement some tools like spy ++ and windbg.
1 - address of the WndProc of the button whose class is "TrayShowDesktopButtonWClass".
It is easily found with spy ++. But I can not find it with the API GetWindowLongPtr.
The following code snippet returns 0 and GetLastError returns 50 (decimal): The request is not supported.
While I get all other indexes (hinstall, type).
I don't understand why I get "GWL_HINSTANCE" but not "GWL_WNDPROC".
If someone can explain to me...
Code: [Select]
$code=@'
using System;
using System.Runtime.InteropServices; 
namespace Win32_API
{
public enum GWL
{
     GWL_WNDPROC =    (-4),
     GWL_HINSTANCE =  (-6),
     GWL_HWNDPARENT = (-8),
     GWL_STYLE =      (-16),
     GWL_EXSTYLE =    (-20),
     GWL_USERDATA =   (-21),
     GWL_ID =     (-12)
}
public class Win32_API_Class
{
[DllImport("user32.dll", EntryPoint="GetWindowLongPtr", SetLastError = true )]
public static extern IntPtr GetWindowLongPtr(IntPtr hWnd, int nIndex);

[DllImport("kernel32.dll")]
public static extern uint GetLastError();
//https://blogs.msdn.microsoft.com/adam_nathan/2003/04/25/getlasterror-and-managed-code/
[DllImport("user32.dll", SetLastError = true)]
public static extern IntPtr FindWindow(string lpClassName, string lpWindowName);
[DllImport("user32.dll", SetLastError = true)]
public static extern IntPtr FindWindowEx(IntPtr parentHandle, IntPtr childAfter, string className,  string windowTitle);
        static public IntPtr GetWindowLongPtr_(IntPtr hWnd, int nIndex)
        {
  IntPtr ret = GetWindowLongPtr( hWnd, nIndex);
  if (ret == IntPtr.Zero){
  Console.Write("GetLastError : {0}", GetLastError());
  }
  return ret;
}
}
}
'@
add-type -TypeDefinition $code
$h1 = [Win32_API.Win32_API_Class]::FindWindow("Shell_TrayWnd", "");
$h2 = [Win32_API.Win32_API_Class]::FindWindowEx($h1, 0, "TrayNotifyWnd", "");
$handle  = [Win32_API.Win32_API_Class]::FindWindowEx($h2, 0, "TrayShowDesktopButtonWClass", "");
"Handle de TrayShowDesktopButtonWClass : {0:x}" -f [int]$handle
$hinst=[Win32_API.Win32_API_Class]::GetWindowLongPtr( $handle, [int][Win32_API.GWL]::GWL_HINSTANCE)
"hinst : {0:x}" -f [int64]$hinst

[Win32_API.Win32_API_Class]::GetWindowLongPtr_( $handle, [int][Win32_API.GWL]::GWL_WNDPROC)
#WindowProc fournie par Spy++ : c68D1FB0 mais il n'y a pas de segment, juste l'offset


2 - Trace the WndProc of "TrayShowDesktopButtonWClass" with WinDbg code in a normal 10 windows
As Spy ++ provides the WndProc and PID, I can use WinDbg with the "segment" Hinstance. Otherwise, I do not know what use segment.
The WndProc addresses different "WM_message", as 0x81 (WM_NCCREATE), and 0x82 (WM_NCDESTROY).
Messages that activate the display seems to be: WM_LBUTTONDOWN = 0x201 and WM_LBUTTONUP = 0x202.
These messages are identified by spy ++
The passage of the parameters with X 64 is a little disturbing.
Explore! CWRLImpWndProc <CShowDesktopButton>: s_WndProcBase:--->>> param: handle = RCX, Msg = RDX, wParam = R8, and lParam = R9.

The WM_LBUTTONUP code is currently analysing. There's a piece of interesting code:
Explorer!CShowDesktopButton::_HandleLButtonUp+0x7f:
00007ff6`c69addd3 e8f85affff         call    Explorer!CShowDesktopButton::_ActivateLivePreview (00007ff6`c69a38d0)
00007ff6`c69addd8 e8df020000      call    Explorer!CShowDesktopButton::_ToggleDesktop (00007ff6`c69ae0bc)

This last function sends a WM_message = 0x579 at the window "Shell_TrayWnd".
And if launches a SendMesssage (need test with postMessage!), then the desktop is displayed in Windows10 normal .
But he does not appear in Winpe.
I conclude that must also trace "Shell_TrayWnd", which will be much longer!
Code: [Select]
$signature = @"
[DllImport("user32.dll", SetLastError = true)]
public static extern IntPtr FindWindow(string lpClassName, string lpWindowName);
[DllImport("user32.dll")]
public static extern int SendMessage(int hWnd, int hMsg, int wParam, int lParam);
"@
#Add the SendMessage function as a static method of a class
$Win32_API = Add-Type -MemberDefinition $signature -Name "C_Win32_API" -Namespace Win32Functions -PassThru
$h1 = $Win32_API::FindWindow("Shell_TrayWnd", "");
"{0:x}" -f [int]$h1

$Win32_API::SendMessage($h1,0x579,3,0)

Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on February 02, 2017, 03:59:23 AM
hello,
Chris find the solution for "session ADM".
And during this reseach, i find why ie64 doesn't work well. A file missing in microWinpeBuilder : ieframe.dll.mui
So, i'm glad to write this reply from IE64 in MicroWinpeBuilder in a VHD mode flat.  :smile:
I test to download a file = OK
I put a picture ...
I am preparing a new version of my PDF(verson 3) to explain for ie64. i'll post as soon as possible.

PS : with ie64 in winpe, i meet difficulties for sign in this site : i receive many times the page "verify cookies..."
        manage password seem not working
        download and historique dowload = OK
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: ChrisR on February 02, 2017, 06:09:31 AM
Chris find the solution for "session ADM".
Thanks, but you can write We  :thumbsup:

About IE32, IE64, do you have it also in the System Session with the download feature or only with the administrator account ?
For the password, maybe you can take a look at Win8.1SE IE11 plugin if it can help.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on February 02, 2017, 06:32:02 AM
I reply from session System. But download doesn't work.
I try to investigate ..... But security for system is an enfer/evil
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on February 02, 2017, 07:07:07 AM
@ChrisR
From Session System : files are downloaded well but not display
I find them ( many try before i see in directory) in directory.
See picture...
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on February 08, 2017, 07:31:17 AM
I continue to play with IE11-64bits in the ADM session. I wanted to use the debugger F12. At first, it miss some files.
Now, i can get the network trace. it use the service "diagnosticshub.standardcollector.service".
I tryed also "fiddler". In my first test, fiddler ask to install its certificat for https. I install it with certutil.exe.
Not a revolution.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on March 08, 2017, 07:03:57 AM
Hello,
Today, i play with windbg.exe. I look into the code of Shell_TrayHwd.
As said in some posts before, with SPY, and as it was said in old posts in theoven, the message 0x579 is send to the wndproc Shell_TrayHwd when you want swap to/from the desktop. With windbg, i find a byte in this wndproc which enable the displying of the desktop, and the reverse swap.
I put here some informations from IE in winpe ( yes, it woks enougth but i can't attach a file ).
I translate as soon as possible.

A -Configure the symbol servers and the network for windbg

B - We saw with spy ++ thewindow Shell_TrayHwd receives the message 0 x 579 with wParam = 3

C - identify the handle and address of WndProc to Shell_TrayHwd
   with spy ++ that gives the offset of this window and the handle
   with a bit of PS that gives the Hinstance which we keep the segment
   7ff7`B8714A40

D - so we can attach windbg to process explorer.exe (office administrator)

1 - We put a conditional breakpoint with:
   bp 7ff7`B8714A40 ".if (rcx == 0x2007E  &  rdx == 0x579 &  r8 == 3) {.echo msg ok} .else {gc;}"

E - we click below and to the right of the screen

F - activity of windbg greatly slows the process 'explore': wait

2 - code analysis activity: the wndproc begins with a big "switch" to process messages WM_xxxxxxxx

3 - symbols and step by step allow to navigate in the code
   Explorer!CImpWndProc::s_WndProc      : pour la wndproc
   Explorer!CTray::v_WndProc                    : for the treatments carried out by this wndproc, other messages are sent to "child" windows (I suppose)

4 - the switch is sometimes complex because optimized by the compiler certainly.
   Here the value of the message 0 x 579 is manipulated pure become an index into a table of pointers
   Explorer!CTray::v_WndProc+0x404:
   00007ff7`b8716964 8d83affaffff    lea     eax,[rbx-551h]
   00007ff7`b871696a 83f87d          cmp     eax,7Dh
   00007ff7`b871696d 779c            ja      Explorer!CTray::v_WndProc+0x3ab (00007ff7`b871690b) [br=0]
   00007ff7`b871696f 488d158a96fbff  lea     rdx,[Explorer!std::_Uninit_move<Microsoft::WRL::ComPtr<IBadgeVisualRenderRequest> * __ptr64,Microsoft::WRL::ComPtr<IBadgeVisualRenderRequest> * __ptr64,std::allocator<Microsoft::WRL::ComPtr<IBadgeVisualRenderRequest> >,Microsoft::WRL::ComPtr<IBadgeVisualRenderRequest> > <PERF> (Explorer+0x0) (00007ff7`b86d0000)]
   00007ff7`b8716976 0fb68402607b0400 movzx   eax,byte ptr [rdx+rax+47B60h] ds:00007ff7`b8717b88=0d
   00007ff7`b871697e 8b8c82a87a0400  mov     ecx,dword ptr [rdx+rax*4+47AA8h] ds:00007ff7`b8717adc=0004698a
   00007ff7`b8716985 4803ca          add     rcx,rdx
   00007ff7`b8716988 ffe1            jmp     rcx {Explorer!CTray::v_WndProc+0x42a (00007ff7`b871698a)}

5 - Continuing the step by step, we find a call whose name is evocative
   Explorer!CTray::v_WndProc+0x43d:
   00007ff7`b871699d e88af1ffff      call    Explorer!CTray::_RaiseDesktop (00007ff7`b8715b2c)

6 -Continuing, we find a test that sends in a case of mistaken (my assumption at the time because of there also evocative text)
   Explorer!CTray::_RaiseDesktop+0x29:
   00007ff7`b8715b55 3899f9020000    cmp     byte ptr [rcx+2F9h],bl ds:00007ff7`b88f5b19=01  <<<<<<<<<<<<<<< the byte !!!
   00007ff7`b8715b5b 0f85ab5a0700    jne     Explorer!`TileBadgeProviderLogging::Instance'::`2'::`dynamic atexit destructor    for 'wrapper''+0x13dcc (00007ff7`b878b60c) [br=1]

G - I leave windbg and the stimulus to place a single breakpoint on this cmp instruction in order to change the value of this byte
   bp 00007ff7`b8715b55 ".if (r8 == 0x579 &  r9 == 3) {.echo msg ok} .else {gc;}"

H - I click at the bottom right of the screen

I - i change the byte

J - toggles the display takes place! It persists as long as I am not leaving the administrator session.

Conclusion: this isn't a huge step forward. But this has occupied my day.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on March 21, 2017, 01:17:40 PM
hello,
It was very long, but i get it : with a hook DLL, i can reset the byte "base +2F9".

And now, the touch "Windows + D" is enabled/active. :wink:

Yes, winPeSe got it since a long time with the use of  "wind.exe and MsgHook.dll".
And Yes, this solution is not a good idea because with the next version of winpe, the address will be modify.

But now, with windbg, it become perhaps possible to find why and when this byte is set to 1.

For my memory, the base is given by SPY++ in the "windows Bytes".

I put the tow codes here. I compile them with VSCommunity 2013 in 64bits only. Create a project and add these codes seems simple.
And yes, my code is horrible, i'm not a good developper.

For install : in a cmd,  launch the program, it puts a hook in Shell_TrayWnd and wait, so explorer launch the dll, the dll modify the byte, you can press a touch in the cmd , so the program remove the hook. If explorer is killed ( tscon 1 for sample) the byte decomes set to 1. And it need to do again.
Sorry for my english. I hope someone can understand...
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: JFX on March 22, 2017, 12:46:55 AM
Great work Noel  :thumbsup:

For x86 it's *CTrayObj + 0x231
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on March 22, 2017, 01:13:33 AM
@JFX   I am very touched by your words of encouragement.

It's true that I leave completely to one side the 32-bit version. I'm not quite good to manage multiple environments.
Currently, I'm trying to follow the creation of this byte with windbg. The breakpoint "ba r 1 adr" when loading to explore does not fire when setting to 1. Here, I do not understand.
Perhaps not the good method....

PS : Do you think it will be possible to find "automaticaly" the address of this byte for the next versions ?
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: JFX on March 22, 2017, 02:51:34 AM
Hmm, will be difficult to find it for other version.
Would be easier if we could find the reason why this byte is set in WinPE.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on March 23, 2017, 12:21:53 AM
hello,
Not easy to follow the life of this byte. The "ba r 1 adr" breakpoint does not work when this bit is set to 1. But he triggered when readings. The doc makes it clear that the option "r" means "read and write". I tried to "go back" since the RegisterClass call. But this byte is already positioned before the first call.
Quote
0:000 &gt; db 7FF7 '93FC5B19--->>> 00007ff7' 93fc5b19 00
BP USER32! RegisterClassExW
g
ModLoad: 00007ff8 '18840000 00007ff8' 1886e000 X:\windows\System32\IMM32. DLL
ModLoad: 00007ff8 '18f60000 00007ff8' 190bb000 X:\windows\System32\MSCTF.dll
Breakpoint 0 hit
0:000 &gt; db 7FF7 '93FC5B19--->>> 00007ff7' 93fc5b19 01
Seeking a little more (even a long time), I find a loop (n = 0 x 19): call msvcrt! _guard_dispach_icall_fptr. It is located in msvcrt! initterm + 0x3d. Byte changes value between 0xB and 0x16 iterations. I missed a good time.
As it is certainly the initialization of global data, I guess that the default value is 1. And so this byte must certainly change its value by an external action (message or subsequent test).
It seems more sensible to put a breakpoint "ba" on this byte in loading a explore in w10. But I must say that I am a little tired today. :sad:
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on March 23, 2017, 06:22:48 AM
Today it's raining.
I just follow changes to the byte 2F9 in "explorer.exe" in Windows 10 build 14393.rs1_release_inmarket.170303 - 1614. But I think that would be the same in all versions of this build 14393.
The attached file contains the trace of the windbg and my comments in french.
I translate the most important here.
Getting started: check the address and the 'windows bytes' with spy ++ to the window "Shell_TrayWnd".
Start windbg. Kill Explorer.exe. In windbg, open the program "explorer.exe".
compute the address of the byte: the basis is provided by spy ++ in the 'windows bytes'. Add 2F9 for build 14393.
Note: I don't remember if I explained how to find this address.
Place the breakpoint:
ba w 1 00007ff6'01e76b59
and GO (g in the file)
explore starts and loads more other dll.
If the address is correct then the breakpoint is triggered.
Breakpoint 0 hit
explore! CTray:v_WndProc + 0xfa6:
00007ff6'01c96a86 84c0 test al, al                                     it is the previous instruction which is important!

Now, how to get le code before this instruction ?
Because it's really the previous code that will tell who and how this byte is changed. Try to deassemble going up in addresses, we quickly found that it is not possible to identify the address of the "jmp" that brought on this "move in 00007ff6'01c96a7f" in my case.
Therefore start from the entrance of the WndProc of a window.

But by looking at the values of the registers and in constant statements following the code launch a "PostMessage", I think that the treatment should not be very long and that may be what would be a response to another message and why "0X5BA" contained in the registers "rbx" and r8.

so we go to the WndProc with:
u explore! CTray::v_WndProc
see the code in the file if you need...

I guess that the msg = 5BA like i see in rbx and r8 at the time of the "BA" breakpoint
I need to get the good address :
00007ff6`01c95ef6 0fb68402e0700400 movzx   eax,byte ptr [rdx+rax+470E0h]
00007ff6`01c95efe 8b8c8228700400  mov     ecx,dword ptr [rdx+rax*4+47028h]
00007ff6`01c95f05 4803ca          add     rcx,rdx
00007ff6`01c95f08 ffe1            jmp     rcx
So :
rax = 0x5BA -0x551  = 0x69
rdx = 00007ff6'01c50000? the charging base of the prg according to the logic of loading to a prg in PE format
byte * ptr = [rdx + rax + 470E0h] = 00007ff6'01c50000 + 0x69 + 0x470E0 = 00007ff6'01c97149 = 0x1B
0:010 d 00007ff6'01c97149
00007ff6'01c97149 1b 1c 2d 1d 1e 1f 2d 20-21 22 23 24 25 26 27 2d... -...- !" #$%&'-
DWORD * ecx = [rdx + rax * 4 + 47028 h] = 00007ff6'01c50000 + (0x1B * 4) + 0 x 47028 = 00007ff6'01c97094
0:010 d 00007ff6'01c97094
00007ff6'01c97094 74 6a 04 00 e0 65 04 00-45 6a 04 00 63 04 00 tj b9 e... EJ... c...
                  74 6a 04 00 in memory = 0004674 in address
rcx = 00007ff6'01c50000 + 0x00046A74 = 00007ff6'01c96a74

And jmp     rcx !
And there's the code in 00007ff6'01c96a86 at the breakpoint :smile:

Quote
0:010> u 00007ff6`01c96a74
explorer!CTray::v_WndProc+0xf94:
00007ff6`01c96a74 397d88          cmp     dword ptr [rbp-78h],edi
00007ff6`01c96a77 0f8526660700    jne     explorer!`TileBadgeProviderLogging::Instance'::`2'::`dynamic atexit destructor for 'wrapper''+0x15123 (00007ff6`01d0d0a3)
00007ff6`01c96a7d 8bc7            mov     eax,edi
00007ff6`01c96a7f 418887f9020000  mov     byte ptr [r15+2F9h],al >>>>>>>>>>>>>>>>> on retrouve bien l'adresse du ba
00007ff6`01c96a86 84c0            test    al,al
00007ff6`01c96a88 0f851f660700    jne     explorer!`TileBadgeProviderLogging::Instance'::`2'::`dynamic atexit destructor for 'wrapper''+0x1512d (00007ff6`01d0d0ad)
00007ff6`01c96a8e 4138bff8020000  cmp     byte ptr [r15+2F8h],dil
00007ff6`01c96a95 0f8512660700    jne     explorer!`TileBadgeProviderLogging::Instance'::`2'::`dynamic atexit destructor for 'wrapper''+0x1512d (00007ff6`01d0d0ad)
0:010> u
explorer!CTray::v_WndProc+0xfbb:
00007ff6`01c96a9b 440fb6c0        movzx   r8d,al
00007ff6`01c96a9f 4533c9          xor     r9d,r9d
00007ff6`01c96aa2 ba0c040000      mov     edx,40Ch
00007ff6`01c96aa7 498b8fa0000000  mov     rcx,qword ptr [r15+0A0h]     DESTINATAIRE INCONNU unknow dest but but but .....
00007ff6`01c96aae ff15c4431800    call    qword ptr [explorer!_imp_SendMessageW (00007ff6`01e1ae78)]
00007ff6`01c96ab4 e918f3ffff      jmp     explorer!CTray::v_WndProc+0x2f1 (00007ff6`01c95dd1)
Summarizes:
someone sends the message 0x5BA with Wparam = 0 and lParam = 0 at the window "Shell_TrayWnd"

The final test: winpe into this piece of PS
Code: [Select]
$code=@'
using System;
using System.Runtime.InteropServices; 
namespace Win32_API
{
public class Win32_API_Class
{
[DllImport("user32.dll", SetLastError = true)]
public static extern IntPtr FindWindow(string lpClassName, string lpWindowName);
[DllImport("user32.dll", SetLastError = true)]
public static extern IntPtr FindWindowEx(IntPtr parentHandle, IntPtr childAfter, string className,  string windowTitle);
[DllImport("user32.dll")]
public static extern int SendMessage(int hWnd, int hMsg, int wParam, int lParam);
}
}
'@
add-type -TypeDefinition $code

$handle = [Win32_API.Win32_API_Class]::FindWindow("Shell_TrayWnd", "");
$iRet   = [Win32_API.Win32_API_Class]::SendMessage($handle, 0x5BA, 0, 0);

Et Bingo !

It would be interesting to know who is the sender of this message 5BA.
Is it a method without  windbg?
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: JFX on March 23, 2017, 07:07:00 AM
You rock man  :thumbup:

Seems it's explorer himself who send this message.

[attach=1]
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on March 23, 2017, 07:18:12 AM
@JFX: thanks for the encouragement

I think I recognise a listing generated by IDA. Isn't it ?
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: JFX on March 23, 2017, 07:26:45 AM
Yes it's IDA 6.8 with loaded x64 explorer.exe version 14393.

I guess the CTray object has it's own function to enable\disable the show desktop functionallity.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on March 23, 2017, 07:38:29 AM
is IDA 64bits 6.8  free of charge ?

With windbg i can see explorer!CTray::ModeChanged.
I don't know if i can find some thing if i put a BP.
Perhaps with the crossref....

Merci.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on March 23, 2017, 12:24:35 PM
hello,
i open explorer.exe in windbg on my windows10 "normal"
i  put a breakpoint on explorer!CTray::ModeChanged.
And "go" with "g" : No hit !
I try twice.
I don't understand why. Is it possible that there are an other code in explorer that send the 5BA message ?
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on March 23, 2017, 10:22:19 PM
hello,
I put a "ba w 1 add_2F9" in a explorer on windows10 "normal".
I can't see the transmitter's handle. But i can see the destinataire's handle of the msg 0X40C (send when the byte is reset).
It's "TrayNotifyWnd".
If i suppose transmitter is also the destinataire. Do you think so ?
In this case, can we imagine a handshaking ( i hope it's the good word ) between these 2 windows?
- shell_TrayWnd sets by default the flag 2F9 : witch means that TrayNotifyWnd is not create
- TrayNotifyWnd sends the msg 5BA : that means that TrayNotifyWnd is ok
- shell_TrayWnd  resets the byte and now can operate the events ( keyboard, menu, msg ) about  "display desktop"
If so, why is it different in winpe?
A long way to explore TrayNotifyWnd ....
Sun is shining so i go to cycle :smile:

PS : during the manipulation, in windbg, I used the "p" command to execute the call to postMessage 40 c. Then I let the program continue with "g". And now wanting to shut down the pc, I see that the 'windows' key and click 'mouse' on the window at the bottom left are inactive as in Winpe. Something to follow can be...
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: JFX on March 27, 2017, 07:16:48 AM
Hi Noel,

Good weather here, so I'm not going into the headache of why WinPE not sends this message.
I've updated my WinPE loader to fire this message on every time it receives a wm_taskbarcreated message.
This seems to be a perfect solution.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on March 27, 2017, 11:43:08 AM
Hi JFX,
Good thing !
I must say that i don't know the wm_taskbarcreated message before you speak about it.
Thanks for sharing the information
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on March 29, 2017, 11:38:39 AM
hello,
But who sent this message 0x5BA in the case of a "normal" windows10?
Quickly...

We therefore have a breakpoint in Windows 10 "normal" on the address of the function PostMessage:

BA r 8 explore! _imp_PostMessageW ".if(rdx == 0x5BA) {.echo msg 5BA} .else {gc};"

There are several exceptions that activate Windbg. I do not account. And finally, the breakpoint is triggered with the 0x5BA message.
Quote
USER32!PostMessageW:
00007ff9`610dafa0 48895c2410      mov     qword ptr [rsp+10h],rbx ss:00000000`0326ef88=00007ff6a3496890
:010> r
rax=0000000000000000 rbx=00007ff6a3496860 rcx=000000000005021e
rdx=00000000000005ba rsi=0000000000000004 rdi=0000000000000000
rip=00007ff9610dafa0 rsp=000000000326ef78 rbp=000000000326efd0
 r8=0000000000000000  r9=0000000000000000 r10=00000fff28e681da
r11=0000000004010000 r12=00007ff6a3429040 r13=000000000005021e
r14=0000000000000000 r15=0000000000000003
iopl=0         nv up ei pl zr na po nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
USER32!PostMessageW:
00007ff9`610dafa0 48895c2410      mov     qword ptr [rsp+10h],rbx ss:00000000`0326ef88=00007ff6a3496890
0:010> k
 # Child-SP          RetAddr           Call Site
00 00000000`0326ef78 00007ff6`a32ba651 USER32!PostMessageW
01 00000000`0326ef80 00007ff6`a32b76d0 explorer!CTray::_RegisterForNotifications+0xf5
02 00000000`0326f000 00007ff6`a32f2b27 explorer!CTray::StartTaskbar+0xf4
03 00000000`0326f050 00007ff6`a32b7880 explorer!CTray::_StartTaskbarApiSurface+0x37
04 00000000`0326f080 00007ff6`a32b7a79 explorer!CTray::_StartParallelTasks+0xd8
05 00000000`0326f0c0 00007ff6`a32b6425 explorer!CTray::_HandleStartupProgress+0x155
06 00000000`0326f100 00007ff6`a32b4112 explorer!CTray::v_WndProc+0x945
07 00000000`0326f630 00007ff9`610d1c24 explorer!CImpWndProc::s_WndProc+0xe2
08 00000000`0326f680 00007ff9`610d156c USER32!UserCallWinProcCheckWow+0x274
09 00000000`0326f7e0 00007ff6`a32bac69 USER32!DispatchMessageWorker+0x1ac
0a 00000000`0326f860 00007ff6`a32f7ae3 explorer!CTray::_MessageLoop+0x149
0b 00000000`0326f8f0 00007ff9`5eef5aad explorer!CTray::MainThreadProc+0x43
0c 00000000`0326f920 00007ff9`60e88364 SHCORE!Microsoft::WRL::Details::RuntimeClass<Microsoft::WRL::Details::InterfaceList<CRandomAccessStreamBase,Microsoft::WRL::Details::InterfaceList<Windows::Storage::Streams::IRandomAccessStreamWithContentType,Microsoft::WRL::Details::InterfaceList<Windows::Storage::Streams::IContentTypeProvider,Microsoft::WRL::Details::InterfaceList<Microsoft::WRL::Implements<Microsoft::WRL::RuntimeClassFlags<3>,Microsoft::WRL::CloakedIid<IRandomAccessStreamMode>,Microsoft::WRL::CloakedIid<IRandomAccessStreamFileAccessMode>,Microsoft::WRL::CloakedIid<IObjectWithDeferredInvoke>,Microsoft::WRL::CloakedIid<IObjectWithFileHandle>,Microsoft::WRL::CloakedIid<IUnbufferedFileHandleProvider>,Microsoft::WRL::CloakedIid<IRandomAccessStreamPrivate>,Microsoft::WRL::CloakedIid<ITransactedModeOverride>,Microsoft::WRL::CloakedIid<CFTMCrossProcServer>,Microsoft::WRL::Details::Nil>,Microsoft::WRL::Details::Nil> > > >,Microsoft::WRL::RuntimeClassFlags<3>,1,1,0>::~RuntimeClass<Microsoft::WRL::Details::InterfaceList<CRandomAccessStreamBase,Microsoft::WRL::Details::InterfaceList<Windows::Storage::Streams::IRandomAccessStreamWithContentType,Microsoft::WRL::Details::InterfaceList<Windows::Storage::Streams::IContentTypeProvider,Microsoft::WRL::Details::InterfaceList<Microsoft::WRL::Implements<Microsoft::WRL::RuntimeClassFlags<3>,Microsoft::WRL::CloakedIid<IRandomAccessStreamMode>,Microsoft::WRL::CloakedIid<IRandomAccessStreamFileAccessMode>,Microsoft::WRL::CloakedIid<IObjectWithDeferredInvoke>,Microsoft::WRL::CloakedIid<IObjectWithFileHandle>,Microsoft::WRL::CloakedIid<IUnbufferedFileHandleProvider>,Microsoft::WRL::CloakedIid<IRandomAccessStreamPrivate>,Microsoft::WRL::CloakedIid<ITransactedModeOverride>,Microsoft::WRL::CloakedIid<CFTMCrossProcServer>,Microsoft::WRL::Details::Nil>,Microsoft::WRL::Details::Nil> > > >,Microsoft::WRL::RuntimeClassFlags<3>,1,1,0>+0x135
0d 00000000`0326fa10 00007ff9`61a470d1 KERNEL32!BaseThreadInitThunk+0x14
0e 00000000`0326fa40 00000000`00000000 ntdll!RtlUserThreadStart+0x21
The PostMessage call came from the "explore! CTray::_RegisterForNotifications".
Quote
explorer!CTray::_RegisterForNotifications+0xc6:
00007ff6`a32ba622 488b4df0        mov     rcx,qword ptr [rbp-10h]
00007ff6`a32ba626 488b01          mov     rax,qword ptr [rcx]
00007ff6`a32ba629 488d5538        lea     rdx,[rbp+38h]
00007ff6`a32ba62d 488b4018        mov     rax,qword ptr [rax+18h]
00007ff6`a32ba631 ff15b1191800    call    qword ptr [explorer!_guard_dispatch_icall_fptr (00007ff6`a343bfe8)]
00007ff6`a32ba637 85c0            test    eax,eax
00007ff6`a32ba639 7817            js      explorer!CTray::_RegisterForNotifications+0xf6 (00007ff6`a32ba652)
00007ff6`a32ba63b 4c634538        movsxd  r8,dword ptr [rbp+38h]
0:010> u
explorer!CTray::_RegisterForNotifications+0xe3:
00007ff6`a32ba63f 4533c9          xor     r9d,r9d
00007ff6`a32ba642 baba050000      mov     edx,5BAh >>>>>>>>>>>>>>>>>>>>> breakpoint
00007ff6`a32ba647 488b4b08        mov     rcx,qword ptr [rbx+8]
00007ff6`a32ba64b ff158f071800    call    qword ptr [explorer!_imp_PostMessageW (00007ff6`a343ade0)]
00007ff6`a32ba651 90              nop
00007ff6`a32ba652 488d4df0        lea     rcx,[rbp-10h]
00007ff6`a32ba656 e80534fcff      call    explorer!Microsoft::WRL::ComPtr<Windows::Foundation::IAsyncOperation<Windows::Foundation::Collections::IVectorView<Windows::ApplicationModel::StartupTask * __ptr64> * __ptr64> >::InternalRelease (00007ff6`a327da60)
00007ff6`a32ba65b 4c897540        mov     qword ptr [rbp+40h],r14
Found the code to send the 0x5BA message
The call to explore! CTray::_EnsureImmersiveShellPointer in Winpe will certainly pose a concern.
Quote
explorer!CTray::_RegisterForNotifications+0x29:
00007ff6`083eb005 e8dea6ffff      call    explorer!CTray::_EnsureImmersiveShellPointer (00007ff6`083e56e8)
0:010> p
explorer!CTray::_RegisterForNotifications+0x2e:
00007ff6`083eb00a 85c0            test    eax,eax
0:010> r
rax=0000000080040154 rbx=00007ff6085c5820 rcx=0000000000000000
rdx=0000000080040154 rsi=0000000000000004 rdi=0000000000000000
rip=00007ff6083eb00a rsp=000000000361eeb0 rbp=000000000361ef00
 r8=000000000361e9c8  r9=00000000000021f5 r10=0000000000000000
r11=000000000361ec30 r12=00007ff608550d20 r13=0000000000030114
r14=0000000000000000 r15=0000000000000003
iopl=0         nv up ei pl nz na pe nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
explorer!CTray::_RegisterForNotifications+0x2e:
00007ff6`083eb00a 85c0            test    eax,eax
00007ff6`083eb00c 0f8860010000    js      explorer!CTray::_RegisterForNotifications+0x196 (00007ff6`083eb172) [br=1]
Code return rax = 0000000080040154 = class not registered.
The jump prohibits sending the msg 5BA.
The function "explore! CTray::_EnsureImmersiveShellPointer"use DCOM.
Quote
0:010> u explorer!CTray::_EnsureImmersiveShellPointer
explorer!CTray::_EnsureImmersiveShellPointer:
00007ff6`083e56e8 4883ec38        sub     rsp,38h
00007ff6`083e56ec 4881c158030000  add     rcx,358h
00007ff6`083e56f3 33c0            xor     eax,eax
00007ff6`083e56f5 483901          cmp     qword ptr [rcx],rax
00007ff6`083e56f8 0f84fc5c0700    je      explorer!`TileBadgeProviderLogging::Instance'::`2'::`dynamic atexit destructor for 'wrapper''+0x13bba (00007ff6`0845b3fa)
00007ff6`083e56fe 4883c438        add     rsp,38h
00007ff6`083e5702 c3              ret
00007ff6`083e5703 cc              int     3
explorer!`TileBadgeProviderLogging::Instance'::`2'::`dynamic atexit destructor for 'wrapper''+0x13bba:
00007ff6`0845b3fa 48894c2420      mov     qword ptr [rsp+20h],rcx
00007ff6`0845b3ff 4c8d0d92381100  lea     r9,[explorer!GUID_6d5140c1_7436_11ce_8034_00aa006009fa (00007ff6`0856ec98)]
00007ff6`0845b406 488d0d139c1100  lea     rcx,[explorer!GUID_c2f03a33_21f5_47fa_b4bb_156362a2f239 (00007ff6`08575020)]
00007ff6`0845b40d 33d2            xor     edx,edx
00007ff6`0845b40f 41b804040000    mov     r8d,404h
00007ff6`0845b415 ff159dee1000    call    qword ptr [explorer!_imp_CoCreateInstance (00007ff6`0856a2b8)]
00007ff6`0845b41b 90              nop
00007ff6`0845b41c e9dda2f8ff      jmp     explorer!CTray::_EnsureImmersiveShellPointer+0x16 (00007ff6`083e56fe)
Quote
rcx = explorer!GUID_c2f03a33_21f5_47fa_b4bb_156362a2f239 -->> HKCR/c2f03a33_21f5_47fa_b4bb_156362a2f239/default=Immersive Shell, APPID={316cded5-e4ae-4b15-9113-7055d84dcc97} ( appid/runas=Interactive User )
rdx = NULL
r8  = 404h -->>> CLSCTX_LOCAL_SERVER = 0x4   CLSCTX_NO_CODE_DOWNLOAD = 0x400,
r9  = explorer!GUID_6d5140c1_7436_11ce_8034_00aa006009fa --------------->>>>>>>>>>>>> ?????????????

[HKEY_CLASSES_ROOT\CLSID\{c2f03a33-21f5-47fa-b4bb-156362a2f239}]
@="Immersive Shell"
"AppID"="{316cded5-e4ae-4b15-9113-7055d84dcc97}"
[HKEY_CLASSES_ROOT\AppID\{316CDED5-E4AE-4B15-9113-7055D84DCC97}]
@="Immersive Shell"
"RunAs"="Interactive User"
[HKEY_CLASSES_ROOT\Interface\{6D5140C1-7436-11CE-8034-00AA006009FA}]
@="IServiceProvider"
[HKEY_CLASSES_ROOT\Interface\{6D5140C1-7436-11CE-8034-00AA006009FA}\ProxyStubClsid32]
@="{A6FF50C0-56C0-71CA-5732-BED303A59628}"
[HKEY_CLASSES_ROOT\CLSID\{A6FF50C0-56C0-71CA-5732-BED303A59628}]
@="PSFactoryBuffer"
[HKEY_CLASSES_ROOT\CLSID\{A6FF50C0-56C0-71CA-5732-BED303A59628}\InProcServer32]
@="C:\\Windows\\System32\\OneCoreCommonProxyStub.dll" ------------------------------>>>>>>>>>>>>> ?????????????
"ThreadingModel"="Both"

How to go further?
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on April 06, 2017, 11:09:44 PM
Actually i work to get mstsc with RemoteDesktop Gateway server.
And i find that my scripts traitement.ps1  can't work with language en-us.
I 'll fix soon.
Constat : scripts not usefull because no one send me that scripts doesn't work.
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: slore on April 14, 2017, 11:53:51 PM
Hi,noelBlanc

nice to see the problem(ShowDesktop) has perfect solution! :thumbsup:

Yes, winPeSe got it since a long time with the use of  "wind.exe and MsgHook.dll".
And Yes, this solution is not a good idea because with the next version of winpe, the address will be modify.
You wrong, wind.exe will deal with all version.

I'm not good as your in disassembling program, I just debug explorer.exe with
Visual Studio, find the message.
I hook the massage, and MinimizeAll/UnMinimizeAll the Windows with my code.
(compare to make origin explorer function work, this is easy for me, just write 100 lines code in 1 or 2 hours.)

but follow your description I try and got the same thing in 10.0.15063.  :great:
(code has a bit different.)

I want make a hard patch to switch the default jump, but the explorer.exe cann't startup with the change... :confused:

Code: [Select]
00007ff6`01c96a7f 418887f9020000  mov     byte ptr [r15+2F9h],al >>>>>>>>>>>>>>>>> on retrouve bien l'adresse du ba
00007ff6`01c96a86 84c0            test    al,al
00007ff6`01c96a88 0f851f660700    jne     explorer!`TileBadgeProviderLogging::Instance'::`2'::`dynamic atexit destructor for 'wrapper''+0x1512d (00007ff6`01d0d0ad)
00007ff6`01c96a8e 4138bff8020000  cmp     byte ptr [r15+2F8h],dil
00007ff6`01c96a95 0f8512660700    jne     explorer!`TileBadgeProviderLogging::Instance'::`2'::`   >>>>>>>>> change jne to je
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: noelBlanc on April 15, 2017, 01:02:24 AM
Hi slore,
Thank for your feedback. My English is so poor that sometime, someone can't undestrand me.
When i said
Quote
And Yes, this solution is not a good idea because with the next version of winpe, the address will be modify.
I speak about "my" solution because address base + 2F9 can change with a new version of windows.
And yes, the WinpeSe team's solution with wind+MsgHook" is the best solution because it doesn't use an "hard" address but implement all the code that explorer.exe doesn't do.
And no, i'm not good in disassembling program. I use Windbg like a beginner.
Quote
just write 100 lines code in 1 or 2 hours
Bravo! i don't be able to do that.

You said
Quote
I want make a hard patch to switch the default jump, but the explorer.exe cann't startup with the change
- i use a exe and hook.dll to do that "dynamicaly" and put it on early posts
- do you modify the checksum of the file explorer after modify it ? I suppose yes but you don't say that. so i ask ....
- can you see with procmon64 some thing or make a save file .PML ?

note : as i understand the code and my test, it is also the first jne that must be disable not only the second. The flag is base + 2F9 in build 14393. And i don't know the role of Base+2F8. 
Quote
00007ff6`01c96a7f 418887f9020000  mov     byte ptr [r15+2F9h],al >>>>>>>>>>>>>>>>> on retrouve bien l'adresse du ba
00007ff6`01c96a86 84c0            test    al,al
00007ff6`01c96a88 0f851f660700    jne     explorer!`TileBadgeProviderLogging::Instance'::`2'::`dynamic atexit destructor for 'wrapper''+0x1512d (00007ff6`01d0d0ad)
00007ff6`01c96a8e 4138bff8020000  cmp     byte ptr [r15+2F8h],dil
00007ff6`01c96a95 0f8512660700    jne     explorer!`TileBadgeProviderLogging::Instance'::`2'::`   >>>>>>>>> change jne to je
So, twice 6  "NOP" ( one for each jne ) seems to me to be better because "je" need to calculate the "delta" of offset.

See you later
Title: Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
Post by: slore on April 15, 2017, 07:57:46 AM
hi, noelBlanc

so quick reply.

>just write 100 lines code in 1 or 2 hours
EnumWindow,check window state and save them, then ShowWindow(Sync), some thing like this,
for me that is easy rather than ~"Windbg" things.~

>- do you modify the checksum of the file explorer after modify it ? I suppose yes but you don't say that. so i ask ....
yes, 0f85xxxxx -> 0f84xxxxx, and PEchecksum.exe explorer_modifed.exe.

- can you see with procmon64 some thing or make a save file .PML ?
I will try this.

>note : as i understand the code and my test, it is also the first jne that must be disable not only the second. The flag is base + 2F9 in build 14393. And i don't know the role of Base+2F8. 
sorry, I had a typo on it.I was changed the first jne not the second one.
(learn the windbg skill from you, I follow the Tray::ModeChange message get the BASE+171h in my version,and it is the first check in Tray::_RaiseDesktop)

>use a exe and hook.dll to do that "dynamicaly" and put it on early posts
I change the BASE+171h,or the jne to je in  "dynamicaly" with Visual Studio, That also worked.

>twice 6  "NOP" ( one for each jne ) seems to me to be better because "je" need to calculate the "delta" of offset.
I will try the 909090909090

thank again, that you is sharing your research(also the process), and How to  disassemble explorer.exe with windbg. :thumbsup: