Topic: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?  (Read 29906 times)

0 Members and 1 Guest are viewing this topic.

Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
« Reply #20 on: February 09, 2016, 10:52:48 AM »

Atari800xl

  • Code Baker
  • Sr. Chef
  • ****
  • Date Registered: Feb 2013
  • Posts: 789
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.

Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
« Reply #21 on: February 11, 2016, 02:39:43 AM »

noelBlanc

  • Chef
  • ***
  • Date Registered: Dec 2013
  • Posts: 121
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

Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
« Reply #22 on: February 11, 2016, 05:53:13 AM »

Atari800xl

  • Code Baker
  • Sr. Chef
  • ****
  • Date Registered: Feb 2013
  • Posts: 789
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:

Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
« Reply #23 on: February 11, 2016, 08:09:21 AM »

noelBlanc

  • Chef
  • ***
  • Date Registered: Dec 2013
  • Posts: 121
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.

Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
« Reply #24 on: February 20, 2016, 11:30:28 AM »

noelBlanc

  • Chef
  • ***
  • Date Registered: Dec 2013
  • Posts: 121
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.

Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
« Reply #25 on: February 21, 2016, 01:01:42 AM »

sezz

  • Apprentice
  • *
  • Date Registered: Feb 2016
  • Posts: 7
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.")

Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
« Reply #26 on: February 21, 2016, 02:53:53 AM »

noelBlanc

  • Chef
  • ***
  • Date Registered: Dec 2013
  • Posts: 121
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.
« Last Edit: February 21, 2016, 05:21:20 AM by noelBlanc »

Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
« Reply #27 on: February 21, 2016, 09:10:34 AM »

sezz

  • Apprentice
  • *
  • Date Registered: Feb 2016
  • Posts: 7
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:

Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
« Reply #28 on: February 21, 2016, 11:15:00 AM »

sezz

  • Apprentice
  • *
  • Date Registered: Feb 2016
  • Posts: 7
(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:

Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
« Reply #29 on: February 21, 2016, 05:15:48 PM »

noelBlanc

  • Chef
  • ***
  • Date Registered: Dec 2013
  • Posts: 121
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


Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
« Reply #30 on: February 23, 2016, 04:13:47 PM »

sezz

  • Apprentice
  • *
  • Date Registered: Feb 2016
  • Posts: 7
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

Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
« Reply #31 on: February 24, 2016, 05:01:05 AM »

noelBlanc

  • Chef
  • ***
  • Date Registered: Dec 2013
  • Posts: 121
@ 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

Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
« Reply #32 on: February 27, 2016, 09:05:11 PM »

sezz

  • Apprentice
  • *
  • Date Registered: Feb 2016
  • Posts: 7
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 :)

Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
« Reply #33 on: February 28, 2016, 03:28:11 AM »

noelBlanc

  • Chef
  • ***
  • Date Registered: Dec 2013
  • Posts: 121
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.
« Last Edit: February 28, 2016, 04:15:38 AM by noelBlanc, Reason: detect only one line with \'fr\' »

Re: MicroWinpeBuilder to adapt its own Winpe : tutorial or 'under the hood'?
« Reply #34 on: February 29, 2016, 08:22:18 AM »

noelBlanc

  • Chef
  • ***
  • Date Registered: Dec 2013
  • Posts: 121
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'

noelBlanc

  • Chef
  • ***
  • Date Registered: Dec 2013
  • Posts: 121
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 ...

« Last Edit: March 25, 2016, 03:53:00 PM by noelBlanc, Reason: add TESTSIGNING in BCD »

noelBlanc

  • Chef
  • ***
  • Date Registered: Dec 2013
  • Posts: 121
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.
« Last Edit: March 24, 2016, 04:19:48 PM by noelBlanc »

noelBlanc

  • Chef
  • ***
  • Date Registered: Dec 2013
  • Posts: 121
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

noelBlanc

  • Chef
  • ***
  • Date Registered: Dec 2013
  • Posts: 121
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.

GoodNPlenty

  • Apprentice
  • *
  • Date Registered: Jun 2013
  • Posts: 6
I have wondered why there was such a long delay for Administrator login. Thank You for your hard work and tutorial.

 

Powered by EzPortal