19 replies to this topic

[noel]

Hi,

 

YES, I know, it's useless.
I could do puzzles or crossword puzzles. But I prefer to play with winpe.

 

For those who like general questions related to Winpe, here's what blocks my game.

 

Context:
I have a Winpe_FullFlat.VHDX file containing a Winpe in which MS SandBox has been running for several weeks.
This is a GPT disc. I make a clone of this Winpe as follows:
-I copy this file Winpe_FullFlat.VHDX into a file that I name New_Winpe.vhdx (same signature!)
-I mount this file New_Winpe.vhdx and I format the partition containing the Winpe files
-I mount the file Winpe_FullFlat.VHDX and I capture the entire partition containing Winpe with "Dism /capture-image"
-I apply this image in the partition of New_Winpe.vhdx with "Dism /apply-image"

 

The test:
I start a physical machine with the New_Winpe.vhdx disk. Winpe works well. Sandbox works well.
I stop the physical machine.
I start the physical machine with the same disk New_Winpe.vhdx. Winpe works well. Sandbox does not work.

 

So only one Winpe feature no longer works in New_Winpe.vhdx: SandBox and after the second Winpe startup.
In the Winpe_FullFlat.VHDX disk, SandBox works after all reboots!

 

Of course, it will not be possible for you to do the test. This does not prevent you from having an opinion and an idea.
And human intelligence is able to work on abstractions.

 

Winpe there are files ... and hives. This makes a significant number of objects.
In the 2 cases, the files created for the Sandbox persist in the VHDX and the Software keys for the "container" are lost with the shutdown.
All of these elements are rebuilt after the next boot.
In the trace of Procmon I don't see any files or keys missing... but such a trace is a large volume of data.

 

My questions:
What object can evolve after the first start of Winpe and how to identify it?

 

Thank you for your suggestions and comments.

Noel

[Tokener]

Hi,

 

YES, I know, it's useless.
I could do puzzles or crossword puzzles. But I prefer to play with winpe.

...

My questions:
What object can evolve after the first start of Winpe and how to identify it?

 

Thank you for your suggestions and comments.

Noel

Hello noel,

first file comes to my mind is "C:\Windows\bootstat.dat".

The file, existing, modified or not, influences system behavior.

I remember that blocked write access was useful in some cases, but killed the system in other cases.

 

Best regards.   T.

[erwan.l]

Hi Noel,

 

I am not too much into this windows feature (sandbox) but I believe Sandbox generates a dynamic base image.

Meaning it generates snapshots i.e a pointers to the original image.

 

Since you have used dism /capture-image & /apply-image which most probably does not generate a 1:1 copy of of the original partition (specially since you format that partition), that could be something to pay attention to.

Here by the way, I dont understand why you need to reimage your partition since you seem to copy the whole vhdx in the first place.

If you really need to reimage your partition, may be consider a bit to bit / dd like solution?

 

My 2 cents.

Oh and yes, winpe/booting/messing with your O.S is more fun than puzzles.

 

Bonne soirée,

Erwan.

[noel]

@Tokener,

 

first file comes to my mind is "C:\Windows\bootstat.dat".

thank you for your suggestions. I do not know the role of this file. I'm going to do some tests with its.
For "blocked write access",  it's a little more complicated for me to understand. The built of the sandbox environment need many files after winpe starts.

@Erwan,

Happy to see you....soon unmasked in France.

 

Meaning it generates snapshots i.e a pointers to the original image

In my winpe "fullFlat", but i think it's identical in a normal OS, i can delete all the "Containers" directory. All files for the new sandbox are rebuild during the next launched "windowsSandbox.exe" (need to be deleted from a winpe boot because ACL). And i delete in the two contexts, the "first" (or master) VHD and in the second (the imaged) VHD.

 

why you need to reimage your partition since you seem to copy the whole vhdx in the first place.

 i make this test with dism because i'm facing to an issue in a "normal" winpe (not FullFlat). And it's on the way of my tests. I compared files/keys, etc, and, at the end, i copied all files with differents methods or tools ( copyfile, dism ). I don't try to copy the file VHD itself because i'm sure sandbox will work (to copy a vhd file to an other vhd file is like a bit to bit copy (dd.exe))..

My surprise is that the imaged VHD works the first time : the sandbox is built from scratch, i can launch edge. After the reboot, Sandbox is rebuilt from scratch but the RDP connection is broken by the Sandbox'VM. (the exact error message out of my momory actually).

I think that the "bug" is somewhere in my sandbox context becasue it's the only one feature to be broken. I don't see the link with RDP connection....

Because "Winpe context", the System and Software hives are not modified. Because "vhd conrtext", many files are modifed.

I can continue some hours with my questions and notes. So i stop

 

thank you both very much for your ideas.

Noel

[noel]

I don't understand why you copy/past my other post taht i made in the "ennemy" site  :

https://the.o :v- en.org/viewtopic.php?f=23&t=122

What is your goal ?

[erwan.l]

I don't understand why you copy/past my other post taht i made in the "ennemy" site  :

https://the.o :v- en.org/viewtopic.php?f=23&t=122

What is your goal ?

 

fake post to advertise a remote site.

report as spammer and this post will be removed.

[noel]

HI,

I do not understand this new anomaly.
SandBox works in my winpe if and only if I format the partition before doing "dism /apply" of a previously made capture of the partition that works perfectly well.

I summarize to clarify the steps and the different files and partitions handled.

I have an "initial" VHD in which Sandbox has been running for a long time (regardless of the number of winpe reboots)
I made a capture of the partition C: of this "initial" VHD: "capture-initial.Wim"

I copied the file from the "initial" VHD to another file that I name "winpe-sandbox-copy.vhdx"

I start with this VHD "winpe-sandbox-copy.vhdx": Sandbox = OK
I restart with this VHD "winpe-sandbox-copy.vhdx": Sandbox = NO-OK

 

a - In another winpe, I mount this VHD "winpe-sandbox-copy.vhdx": the partition containing winpe = E:
I format this partition E:
I do "dism /apply" from the "capture-initial" file.Wim"
I start winpe on the VHD "winpe-sandbox-copy.vhdx": Sandbox = OK
I restart winpe on the VHD "winpe-sandbox-copy.vhdx": Sandbox = NO-OK

 

b - In another winpe, I mount this VHD "winpe-sandbox-copy.vhdx": the partition containing winpe = E:
I delete all the directories and all the files of the partition contenannt winpe (it's a bit long because of the ACLs on some files)
I do "dism /apply" from the "capture-initial" file.Wim"
I start winpe on the VHD "winpe-sandbox-copy.vhdx": Sandbox = NO-OK

 

I repeat more than 10 times steps a and b with always the same result.

My question: what can the formatting do that would have an impact on sandbox (the RDP connection is broken by the VM)?

The signature of the partition does not seem to me to be involved since there is no anomaly in the case of formatting.

Deleting all files does not leave the partition in the same state as formatting. But what is really changing? with an impact on RDP...
l

 

Let me know all your ideas, I don't have a single one anymore.

[Wonko the Sane]

What happens if you don't change the filename?

 

I mean:

\Original\capture-initial.Wim

copy/dima/apply/whatever to:

\New_test\capture-initial.Wim

 

Or if you dd the wim and change name?

 

I mean:

\Original\capture-initial.Wim

dd to:

\Original\any-other-name.Wim

 

You can also try to dd only the first sector of the whole vhd (the MBR) and the first sector of the volume (the PBR), this way both Disk Signature and Volume Serial will be the same.

 

Wonko

[noel]

@wonko: Thank you for those ideas. They allowed me to take a step back. I had focused on formatting. I had left out the capture.
So I redid a "capture" with the /NoRpFix parameter. But no evolution.

 

It is also true that it is not easy to understand the context of my test. I had 2 possibilities.
a - explain everything from the beginning, the purpose, the method, the tools, the implementation
b - simply extract a sticking point in my progress

So I'm going to do a little bit of the 2.

 

1 - the overall goal: to use SandBox in a Winpe (22000-194 FR)

identify the elements needed for Winpe
inject these elements into Winpe
Fix the current issue "RDP link broken by Sandbox VM" : my actual work

  identify an error-free context!

   many tests including FullFlat

  various means of investigation used (simultaneous or not)

   procmon: the analysis of traces makes it possible to locate the source of the anomaly, mainly thanks to the symbols.
   This gives me a good view of the logic, processes, and steps taken to build and operate the Sandbox VM. And I can now imagine tests to identify a solution, including this one:

   copying entire directories from another source: avoids unit search
       the choice of the directory: define a selection criterion
       various methods of copying depending on the presence or absence of ACL, the desirable time

    This is the starting point of my final question

 

2 - the context of implementation of the next test

the reference VHDX disk in which Sandbox works without anomaly (Winpe FullFlat)
a physical machine with a GPT hard drive
this GPT hard drive can start the test VHDX
the BCD of the hard drive of the physical machine is modified to start the test OS
the test VHDX is obtained by making a copy of the reference VHDX file: it is therefore identical to "dd"!

the test VHDX is also GPT type (but this does not impact the test)
the test VHDX therefore has 2 partitions, I designate here by "C:" the partition containing the test OS launched at startup
note: the first partition is FAT and it contains a BCD used to boot into HyperV (or another hypervisor)

 

3 - one of the blockages during my research: the copy of the entire partition at once

After attempting various copies, I want to copy the entire partition containing the OS of the reference VHDX disk
I tried 2 methods: copying with windows file explorer (but ACL), and copying with "dism capture / dism apply"
I could have tried "7z.exe" but I didn't.

In the case of the use of "dism", I followed this modus operandi:
  boot to another "winpe"
  mount the reference VHDX
  capture OS partition
  mount the test VHDX
  format "C:" partition of OS -> new signature for partition !!!
  apply the captured file in this blank partition
  disassemble the 2 VHDX
  reboot on the test VHDX
  Sanbox works  <- with the new signature !!!
  reboot on the test VHDX
  Sandbox does not work (RDP link is broken by sandbox VM)

I then did the test to apply the capture file without formatting the test VHDX: Sandbox does not work from the first reboot

 

4 - a point about the Sandbox

I forgot an important thing about capturing the reference partition and the Sandbox itself.
In this reference VHDX, I installed the Sandbox FOD with "DISM /ADD-FEATURE" in "offline" mode.
Then I started the VHDX to check that the FOD was present in "optionalFeature.exe".
Then I restarted another Winpe to capture the reference partition.
So, the next launch of "WindowsSandox.exe" will start on a blank environment.
And it will build all the necessary context for Sandbox.
And this will be true in the reference VHDX as in the test VHDX.
These 2 VHDX do not contain any reference to an already active Sandbox image.

 

5 - hence my question: what does the formatting that allows the first operation of Sandbox do?

note : I could try to describe the Sandbox anomaly more precisely but I don't know if it can be useful to you.

note : it is a Winpe context, so change in hives are not present on the next boot

note : it is a VHDX context, so change in files are present on the next boot

 

Thank you for taking the time to read and try to understand my question

[Wonko the Sane]

So, basically:

1) before formatting (please read as "before changing something in the volume that identifies it") everything works every time

2) after formatting (please read "after changing something in the volume that identifies it") it only works only once

 

AND we know that in a PE context:

a. changes on (virtual) disk are static
b. changes on (virtual by defiinition) registry are volatile

 

Now let us imagine that *somewhere* in the Registry there is a key that identifies volumes by their serial number or GUID (or *whatever*).

 

In case #1 above Registry and "volume identifier mechanism" are in sync

In case #2 above Registry and "volume identifier mechanism" are in sync the first time (more exactly in the SAME boot that you change the info) , but on subsequent boots the newly made entry for the "volume identifier mechanism" (which is volatile as per #b.) is lost (and so the Sandbox is *somehow* trying to "hook" a non-existing volume).

 

You need a Registry snapshot program, saving and comparing the Registries, find the differences, and then merge them to the backing Registry hives.

 

BEFORE that I would check the GUID's mountvol outputs and look in the online registry for their values.

 

It is a mess, only seemingly unrelated and JFYI:

http://reboot.pro/in...showtopic=22113

http://reboot.pro/in...showtopic=21931

 

Wonko

[noel]

@wonko,

I edited my post in the "same time" i receive your reply....

About "signatures": YES, I am looking for these signatures and it is possible that I missed something.

 

I thank you and I appreciate your comments which are always very educational and which will approach the problem from a new angle.

I know it's hard to come up with ideas without being able to manipulate objects yourself.

 

In the reference VHDX, as it is a Winpe FullFlat, the build process deletes the key

"HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices"

So, this reference VHDX  doesn't take care of old "mounted devices".

This key is still missing in all winpe built with ADK

 

In addition, the SAM and SECURITY hives are identical in both VHDX: this is achieved by the FullFlat construction process.

 

I used the SYSTEM and SOFTWARE hives of the winpe I built later (the one that put me on the road to this test)

 

It is possible that  the " Dism /add-feature"  action puts somewhere one signature or some ID. But why and where ? GGGGGggggggrrrrrrr (in french, it's stronger that    )

 

And other point about the error in SandBox :

I see in the trace of Procmon a little of the activity of the Sandbox VM: when the Sandbox VM needs a file, this file is loaded from the host and it is therefore visible to Procmon. And the eventlog service gives other good help. After the VM is started (read in enventlog), the WindowsSandox.Client.exe is launched. It uses MstscAx.dll, the client RDP. It prepare the credential for login in the VM. I see the name and the password in the eventlog. After that, i see that the VM needs "winlogon.exe". And after, i see that WindowsSandox.Client.exe displays an errorBox " Error 0x80072746 an existing connection was forcely closed by the remote host".

To be a little more complete, I still have to say that eventlog contains some of the commands sent directly to the VM by the Sandbox manager.
These commands are livable and readable in plain text in a binary file whose name I forgot.
I note here those that have a connection with the login action:
a command "NET.exe user ..." to create the user with their password
This user will be used for the RDP connection

 

With Windbg, i stopped the destruction mecanism of the VM. And i can open the VHDX of the Sandbox. I can see its eventlog. But no thing about winlogon.  I would say : no thing about winlogon error. I see that the logon for the user is OK (i can't copy/past its name because i don't use the test computer)

 

I can imagine security information based on the hardware ID to identify the login requestor.

 

I realize that I am drifting on the initial error that led me to try to copy whole sections of files from a context where Sandbox works

 

what kind of test can i do ?

[Tokener]

dear noel

did you try

dism.exe  /capture-ffu

command?

It will capture the attached (working) vhdx to a file.

If you have success doing the apply and boot with working sandbox, it is most likely that wonko is right with his assumption that disk-signature is part of your problem.

 

Regards   T.

[Wonko the Sane]

Actually I doubt it is Disk Signature, as it seems like the modifications are made to the volume only (and not to the whole disk), on the other hand, given last report by Noel, it is not the usual "MountedDevices" either, but there could well be other references to *some* volume identification elsewhere in the Registry.

 

Wonko 

[noel]

Dear Tokener,

I thank you very much for your idea.

I never used this command. I must take information and understand what it do.

I must make a pause for one week because "family" comes in my house for 10 days.

So, i'll test "ffu" when i'll be alone.

 

Until today I used  procmon trace to look at around the error "RDP broken" : it comes when windowsSandboxClient.exe makes login (logon ?) in the Sandbox VM.  Because all services started in VM, there are many many events. And filter are not allways good (missing the "good" event...)

And it's difficult because i can't see from the host what is done in the VM. I can see only the files that the VM "takes" in the host for using in the VM.

(i don't know if imy explaination is good)

And even in the other context that is winpe ( in this winpe context i don't use the Format/Apply method ), the behavior seems to me different if i reboot or not.  For a long time, i think that my changes are the source of the new behavior but now i must say "not".

So, i need to identify a  "sequence" and keep only one.

 

Hi Wonko,

i think so, VHDX and its ID is good with the VHDX copyfile. Volume ID changes with format. And i test also in the winpe context without "format" : the behavior change after reboot. I make a long time to understand this point.

 

It's true that it's difficult for me to imagine that Ms takes a signature for launching a Sandbox VM. Ms doesn't do that for HyperV and also not for WSL2. This two FOD (Feature On Demand) work fine in my winpe. Until now, i found many files missing and needed by the builder of the VM (CmImageWorker.exe ). And i learned how to make new tests from scratch (delete file and keys in hive for Sandbox). But maybe i miss a "byte in a corner".

 

I think that the culprit is between my keyboard and my head.I sometimes make erroneous observations because i don't notice all parameters. The tests and rechearch require rigor and also imagination. I don't have rigor. And sometimes, intuition makes me deviate from my path.... to complex for my poor english to explain.

 

I find a way (the "good time" in the process) to make a copy of the Sandbox VHDX (It is a file in the filesystem of the VHDX host. it is deleted when the Sandbox VM is closed). So, i can look at in this VHDX, in the eventlog. And i can identify many files with a wrong version : "Control Integrity" of OS complains about these files. But they come one by one. The version difference takes its source in the files brought by ADK during the construction. The next year, i'll modify this logic and i'll replace all files by the files from ISO : so all files will have the good version. But now, i still play with this difference.

 

This night, because i identified a sequence to test, i'll make the long test and notice what i observe. And last week, I'm going to do it for the Format/Apply, which is longer.

 

Thank you again for your suggestions

Noel

 

BTW, if someone want to try and search, i put the compressed (7z)  VHDX (10GB to 1.3GB)  in a share... (you can ask for the link). Because it's experimental, its start needs  some intuition...but i can help.

 

[Tokener]

hi noel

if you want to test the ffu command, I recommend

Dism Mount Service

I captured successfully a ffu-file from a Win11-PE vhdx today.

it has all commands available in the "disk"-tab.

good luck   T.

 

 

 

 

[wimb]

Actually I doubt it is Disk Signature, as it seems like the modifications are made to the volume only (and not to the whole disk), on the other hand, given last report by Noel, it is not the usual "MountedDevices" either, but there could well be other references to *some* volume identification elsewhere in the Registry.

 

Wonko 

 

Or the reference is in System Volume Information folder like with WIMBOOT using something like WimOverlay.dat  - More Info

[Wonko the Sane]

Or the reference is in System Volume Information folder like with WIMBOOT using something like WimOverlay.dat  - More Info

 

Yes, that could be it  , completely forgot about that.

@Noel

JFYI, it all started here:

http://reboot.pro/in...=21977&p=210598

 

Wonko

[noel]

Hi Wimb and hi Wonko

 

That seems a very good idea.  

This directory is exclude by "DISM /Capture-image". And any change in this directory  is present after reboot. And can influence the next behavior.

 

I must place it  in the "sequence of thinking" in my head and on a paper with format action .... because actions order is important.

More later..

Noel

[noel]

Hi,

I have no idea.
So I took the opportunity to do what has been in my head for a long time.
The Winpe produced by ADK contains files that make up a homogeneous whole. They don't all have the same version.
But MS chose them because they work properly in this context.
However, when we add features in winpe, we add files that are contained in an ISO of a newer version.
And it happens that we add files that are not "fully" compatible.
I have often noticed this. And recently when adding Explorer dnas Winpe 11.

So I modified my script to replace in Winpe all the files of System32 that do not have the right version with the files of the ISO.
My new Winpe works as well as the old one.
I tested Sandbox.
And, oh surprise! Sandbox works on the first boot.
During the second boot it is still the black screen (breaking the RDP link) that appears.

 

Until now, my Sandbox test followed the 2 steps of Sandbox:
-the first creation of the VHDX
-the subsequent use of this VHDX

So I took the opportunity to modify the test and keep the context of the first VHDX built.
After the first successful startup of Sansbox, I export the key that describes the Sandbox paths.
I restart Winpe.
I import the key.
The next Sandbox reboot succeeds perfectly.

For now, I do this import manually. And there is no urgency.
I will be able to focus on the construction step of the VHDX file.
By the way, I will look for a relationship with the anomaly related to the formatting of the VHD of FullFLat.
But I'm happy because I can now see and use the Sandbox in my Winpe.

 firstSandbox.png   528.82KB   1 downloads

[noel]

Hi,
I thought I had finished my research around Sandbox.
But the latest tests show the opposite. :sad:

 

Installing Sandbox now allows me to use Sandbox in all VHDs and machines.
But this requires this constraint: it is necessary to use a copy of the reference VHD with each machine :embarrassed:

 

I conclude that the first sandbox boot remembers an ID and stores it in disk.

And if I was not mistaken during my various tests, formatting re-initializes the procedure.

 

The current implementation is a bit complex.
This new VHD requires two phases with the system account (not Adm) on the same computer (VM or physical) with a copy of the reference VHD.

 

Phase 1:
- with a copy of the vhd reference
- boot, launch activation_hyperv.ps1 : it actives the Sandbox context
- launch of WindowsSandbox.exe (please wait 1 or 2 minutes)
- check that the Sandbox window is correct (when the desktop is visible and when you can interact with the desktop with the right click for example)
- export (regedit) the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Containers\CmService

 

Phase 2:
- with the same vhd used in phase 1 and modified by "sandbox" (files and ...?)
- boot, launch activation_hyperv.ps1 (possibility to convert to cmd, of course)
- import the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Containers\CmService
- launch of WindowsSandbox.exe (please wait 1 or 2 minutes)
- check that the Sandbox window is correct

 

If Sandbox is OK, we can check the bug. Two possibilities:
- using the same vhd used in phase 2 on another computer (VM or physical but i only test on a physical computer)
- testing phase 1 on one computer, then moving the vhd to another computer to then do phase 2

 

There is a third possibility, the one with Capture/format/apply of the primary partition in a copy of the reference vhd
note: I do not try this possibility because I have already done it with FullFlat which is "identical" to the new vhd reference.

 

Now the search for this ID is going to be long and complex. :mad:

And I have no ideas anymore

Noel