Windows 10 Need to migrate MBR Win10Pro C drive HDD contents or my Macrium Reflect backups of it to new on-the-motherboard NVMe SSD device set to UEFI GPT

• extract the embedded PE to a new file,
• verify it looks like a PE,
• run the layout/extract switch, and
• what to do if /layout doesn't work.

• Check the first bytes (header) to confirm a PE:

• Try the common bootstrapper layout switches (still in elevated PowerShell):

show help (if available)​

try the typical layout switch (create a layout folder)​

alternates if the above fails​

• If the binary is a Wix/Burn bootstrapper it usually supports /layout and will extract the embedded MSIs into the folder you give.
• Run the one that succeeds. If a dialog appears when you double‑click the EXE, prefer running the /layout method from an elevated prompt.

• Use 7‑Zip or lessmsi on any SamsungInstaller64.msi found.

• The carve parameters were wrong (offset/length). Re-check for MZ offsets inside combined.bin.
• The embedded PE is not the bootstrapper but a different payload.
• The carved file is corrupted.

finds MZ offsets (fast-ish)​

• Run the carve script above (Step A) using the offset/length you already found (394394 / 3025380).
• Then run .\carved_container.exe /layout C:\Temp\SamsungExtract\layout
• If that succeeds, extract the MSI(s) with 7‑Zip and install the driver INF/SYS via pnputil or Device Manager.

• the Format-Hex output of carved_container.exe first 64 bytes,
• the exact error text you see running the carved_container.exe /layout command,
• or the list of files created in C:\Temp\SamsungExtract (dir /a /od).

print hex and ascii​

• Hex begins with 4D 5A (MZ) and
• ASCII includes "This program cannot be run in DOS mode."

• IMAGE machine values: 0x014C = 32-bit x86, 0x8664 = x64, 0xAA64 = ARM64, 0x0200 = Itanium. If it reports IA64 or ARM/ARM64 and your Windows is x64/x86, Windows may refuse to run it.

try help​

try layout (two syntaxes)​

• Wrong architecture (you saw IA64/ARM)
• The PE is still corrupted / incomplete
• The carved PE is actually not the bootstrapper but another PE (a DLL payload) — in that case the MSI might be elsewhere (in the container as PK.. entries).

find PK\x03\x04 offsets​

find OLE header (D0 CF 11 E0) offsets (MSI compound)​

example carve from $offset to end​

then try:​

• The hex output from step 1 (first 64 bytes)
• The Machine value from step 2
• The PK offsets / OLE offsets printed by step 4 attempt (the lists)
• The exact error when you attempt .\carved_container.exe /layout (copy the error)

• Run PowerShell elevated.
• Confirm carved_container.exe begins with MZ (step 1).
• Confirm machine type (step 2).
• If machine is compatible, try /layout (step 3).
• If /layout fails, search for PK / OLE signatures inside the carved binary and carve from those offsets (step 4).

• show file size,
• search for MZ / PK / OLE (PE / ZIP / MSI compound) signatures and list offsets,
• show a hex+ASCII preview around each offset,
• and (optionally) carve one of the hits to a new file you can test with 7‑Zip.

helper to find pattern offsets​

hex + ascii preview around offset​

 $start = [Math]::Max(0, $o - 48) $len = [Math]::Min(160, $bytes.Length - $start) $seg = $bytes[$start..($start + $len - 1)] $hex = ([BitConverter]::ToString($seg) -replace '-',' ') $ascii = ([System.Text.Encoding]::ASCII.GetString($seg) -replace '\0','·') " -> preview at offset $o (decimal) / 0x{0:X} (hex)" -f $o " context start=$start len=$len" $hex.Substring(0,[Math]::Min(200,$hex.Length) # print first part of long hex $ascii.Substring(0,[Math]::Min(200,$ascii.Length)
}

carve from offset to end (example)​

• If you see PK offsets: those are likely ZIP/CAB/MSI local-file headers. Carve from the PK offset and test with 7z.
• If you see OLE offsets: carve that offset to .msi and open with lessmsi / 7‑Zip / Orca.
• If you see an MZ at a non-zero offset: that tells us there are embedded PE(s); those could be resource-only DLLs or the bootstrapper. If the machine type appears incompatible (for example IA64 or ARM), Windows will refuse to run it — but you can still extract resources from it (wrestool/icoutils, Resource Hacker, or on Linux use cabextract/7z).
• If the scan finds nothing (no PK/OLE/MZ): the container may be compressed inside zlib chunks (as we saw earlier) — in that case we should decompress the .zlib parts and scan those dec outputs the same way. If you want I can give the decompress+scan commands for PowerShell too.

• print filename + size,
• search the carved file for MZ / PK / OLE signatures and list all offsets found,
• show a short hex+ASCII preview around each offset.

example usage:​

• If you get PK offsets: carve from the PK offset and try 7z l and 7z x, or rename to .zip/.cab/.msi and try 7z or msiexec /a to extract an MSI.
• If you get OLE offsets: carve to .msi and use msiexec /a package.msi /qb TARGETDIR=C:\Temp\out to extract, or open with lessmsi / 7‑Zip.
• If you get MZ offsets: those are embedded PEs; resources might be inside. You can extract resources with icoutils (wrestool) or Resource Hacker. If the PE is for a different CPU architecture, Windows will refuse to run it but resources can still be extracted.
• If the scan finds none: the data might be zlib chunks (you already found .zlib pieces earlier). In that case decompress the .zlib files and run this same scan on the decompressed outputs.

• The Samsung installer you have is a WiX/Burn bootstrapper: it contains an attached container (WixAttachedContainer) which itself holds MSI/CAB payloads (the driver MSIs and files).
• The goal is to find the byte offset where the embedded container or the MSI/CAB begins, carve out that region to a separate file, then open that carved file with 7‑Zip / msiexec / lessmsi / cab tools to extract the driver .inf/.sys files.
• The most robust approach is:
  1. scan the .exe/.bin for signatures (PK.. for ZIP/MSI/CAB, D0 CF 11 E0 for OLE/compound MSI, MZ for PE),
  2. carve from the correct signature offset into a new file,
  3. try to open that carved file with 7‑Zip or msiexec /a or cab extractors; if that fails, try carving different offsets or run binwalk/zlib extraction on segments.

• This script will scan a file for the 3 signatures, report offsets (decimal/hex), and provide a function to carve from any offset to a new file.

# set the file you want to scan
$fn = "C:\Temp\SamsungExtract\carved_container.exe" # change to combined.bin if you prefer Write-Host "File: $fn"
$bytes = [System.IO.File]::ReadAllBytes($fn)
$len = $bytes.Length
Write-Host "Size: $len bytes" function Find-Offsets([byte[]$pattern) { $res = New-Object System.Collections.Generic.List[int] for ($i=0; $i -le $bytes.Length - $pattern.Length; $i++) { $match = $true for ($j=0; $j -lt $pattern.Length; $j++) { if ($bytes[$i+$j] -ne $pattern[$j]) { $match = $false; break } } if ($match) { $res.Add($i); $i += $pattern.Length - 1 } } return $res
} # patterns
$patMZ = [byte[](0x4D,0x5A) # MZ (PE)
$patPK = [byte[](0x50,0x4B,0x03,0x04) # PK.. (ZIP/CAB/MSI local-file header)
$patOLE = [byte[](0xD0,0xCF,0x11,0xE0) # OLE2 (compound file / MSI) $maps = @{ 'MZ' = $patMZ; 'PK' = $patPK; 'OLE' = $patOLE } foreach ($k in $maps.Keys) { $offs = Find-Offsets $maps[$k] if ($offs.Count -gt 0) { Write-Host "`n$k offsets: $($offs -join ', ')" foreach ($o in $offs) { $start = [Math]::Max(0, $o - 48) $previewLen = [Math]::Min(160, $len - $start) $seg = $bytes[$start..($start + $previewLen - 1)] $hex = ([BitConverter]::ToString($seg) -replace '-',' ') $ascii = ([System.Text.Encoding]::ASCII.GetString($seg) -replace "`0",'·') Write-Host (" -> preview at offset {0} / 0x{0:X}" -f $o) Write-Host (" context start=$start len=$previewLen") Write-Host (" ASCII: " + $ascii.Substring(0,[Math]::Min(200,$ascii.Length) } } else { Write-Host "`n$k offsets: none" }
} # carve helper: write from a chosen offset to a file
function Carve-FromOffset([int]$offset, [string]$out) { $fs = [System.IO.File]::OpenRead($fn) try { $fs.Position = $offset $remain = $fs.Length - $offset $buff = New-Object byte[] $remain $fs.Read($buff,0,$remain) | Out-Null } finally { $fs.Close } Write-Host "Wrote $out size $((Get-Item $out).Length) bytes"
}

• How to use it:
  • Run the script block above once. Look for reported offsets under PK / OLE / MZ.
  • If you see a reasonable PK or OLE offset (e.g. a few hundred KB into the file), carve from that offset:
  • Example: Carve-FromOffset 394394 C:\Temp\SamsungExtract\carved_container_from_394394.bin
  • Then try: 7z l C:\Temp\SamsungExtract\carved_container_from_394394.bin
  • Or try msiexec admin extract (if .msi detected): msiexec /a "C:\path\to\carved.msi" /qb TARGETDIR="C:\Temp\out"

• If the preview ASCII around an offset contains "WixAttachedContainer", "SamsungInstaller64.msi", or other WiX strings, that’s a strong sign you found the right region (the Burn manifest is plain XML near the start of the bootstrapper). If you see "PK..", "D0 CF 11 E0" or "MSCF" nearby, that’s your extraction point.

• Use hexdump or grep like you did earlier, e.g.:

• grep -a -b $'\x50\x4b\x03\x04' combined.bin # for PK
• grep -a -b $'\x4d\x5a' combined.bin # for MZ
• grep -a -b $'\xD0\xCF\x11\xE0' combined.bin # for OLE

• dd if=combined.bin of=carvedfrom<offset>.bin bs=1 skip=<offset> status=progress

• 7z l carvedfrom<offset>.bin
• file carvedfrom<offset>.bin
• If it is an MSI/CAB: 7z x carvedfrom<offset>.bin -ocarved_out
• If it’s an MSI compound (OLE): try lessmsi (lessmsi x file.msi outdir) or msiexec /a on Windows.

• The carved file may be:
  • not starting at the real container start (try a few bytes earlier/later),
  • a proprietary container / compressed chunk (some attachments are zlib compressed),
  • an MSIX-like blob or concatenated pieces.
• Actions:
  • Re-scan the file for multiple PK/MZ/OLE offsets and try carving from each one (the script above makes that easy).
  • Run binwalk (Linux) to auto-detect and extract embedded archives: binwalk -e carved_file
  • Try scanning within carved_file for embedded PK headers again — sometimes you must carve from an earlier offset (the Bootstrapper XML may sit before the attached container).

• You saw first 64 bytes that are 0x00 — that indicates you carved at the wrong offset (or the container begins later). Use the script above to list offsets and preview ASCII: zeros mean you’re before the meaningful content.

• The bootstrapper contains the Burn Manifest XML near the start; it also mentions the attached container metadata, including the attached container filename and declared FileSize. Two ways to use that:
  1. Search the bootstrapper exe for the BurnManifest XML (it’s human‑readable). Using that you can find the Container "FileSize" or the Payload SourcePath (a0/a1 etc) and the AttachedIndex. That helps you calculate exact carve length to extract just the attached container region.
  2. If XML says Container FileSize=3025380 (example), carve exactly that many bytes starting at the attached container offset.

• In your earlier logs I can see a BurnManifest that lists:
  • Container FileSize="3025380" and FilePath="Samsung NVM Express Driver.exe" and AttachedIndex="1"
  • That tells you the attached container is 3,025,380 bytes long. If you find the offset where that container begins, carve exactly 3,025,380 bytes and save as .exe or .cab, then try 7z / cab extractors on it.
  • (If you don’t know the exact offset but find the "MZ" at or near the start of that container, carve from that MZ position and the length above.
  • —> So: find the offset of the container start (search for the MZ that starts the attached container), then dd skip=that_offset count=3025380 of=attached_container.bin

• 7‑Zip (7z) — very effective for ZIP/CAB/MSI inside userspace: 7z l foo.bin ; 7z x foo.bin -oout
• msiexec (Windows): msiexec /a foo.msi /qb TARGETDIR="C:\Temp\out" (administrative install extracts MSI contents)
• lessmsi (Windows, GUI/CLI) — extracts MSI contents reliably.
• cabextract / expand / makecab — for CAB files.
• binwalk — autoscans and extracts embedded formats; very helpful when offsets are not obvious.
• msitools (on Linux) / lessmsi — for OLE/compound MSI files.

• You already decompressed some .zlib segments into .dec files — those looked like resource blobs, not the MSIs. If the driver MSIs were embedded as zlib-compressed chunks across several fragments, you’d need to:
  • decompress each .zlib to .dec
  • search the .dec files for PK / OLE signatures
  • if a full MSI is distributed across multiple decompressed chunks, you’d need to concatenate the right sequence of .dec segments in the correct order (manifest or source offsets will tell you order) before feeding to 7z.

• A lot of bootstrapper .exe's refuse to launch if they were built for a different OS/bitness or rely on Windows features missing in your environment. That’s fine — we don’t need to run it to extract, we just carve the binary and extract payloads offline.

1. On Windows: run the PowerShell scan I posted above (change $fn if needed). Note every PK / OLE / MZ offset printed.
2. For each PK or OLE offset printed:
   • Carve from that offset to a file using Carve-FromOffset offset outname (use the function in the same PowerShell session).
   • Try opening with 7z: 7z l outname
   • If 7z recognizes it, extract: 7z x outname -oC:\Temp\SamsungExtract\carvedout<offset>
   • If it’s an MSI, use lessmsi or msiexec /a to extract driver files (INF, SYS).
3. If none of the offset carves are recognized:
   • Use binwalk -e on the carved file (on Linux/WSL). Or run binwalk on the original combined.bin (binwalk -e combined.bin).
   • Check for zlib fragments: grep for zlib signatures or .zlib fragments you already found — decompress them and rescan for PK/MZ inside the decompressed files.
4. If you want, send me the offsets the PowerShell script reports (copy the output here). I’ll point you to the exact offset(s) to carve and exactly which carve length to use (e.g., “carve from 394394 for 3025380 bytes”); that is the fastest way for me to tell you the single carve command that should produce a usable MSI/CAB.

• 7z “not an openable archive”: means your carved file likely doesn’t start exactly at the payload header, or it’s compressed/packed in a way 7z doesn’t recognize. Try different offsets or use binwalk.
• PowerShell Format-Hex on older PS versions: Format-Hex there may not support -Count; the manual byte-reading snippet you used is fine.
• In your PowerShell preview you saw the carved_container.exe first 64 bytes as zeros — that signals you carved at the wrong place; re-scan for signatures.

• review the exact output of the PowerShell scan you run and tell you the exact carve command (offset + length) to use,
• or give you the exact dd or PowerShell Carve-FromOffset command once you paste one good offset from the scan.

• Open PS in C:\Temp\SamsungExtract and run:
  .\extraction.ps1

• From the same folder:
  powershell -NoProfile -ExecutionPolicy Bypass -File .\extraction.ps1

• powershell -NoProfile -ExecutionPolicy Bypass -File .\extraction.ps1 > C:\Temp\SamsungExtract\scan_output.txt
• Then open scan_output.txt and paste the relevant lines (the offsets / previews).

• Confirm you’re in the right folder and the file exists:
  Get-Location
  Get-ChildItem -Force .\extraction.ps1
• Inspect the script if you suspect encoding/line-ending problems:
  Get-Content .\extraction.ps1 | more

• Run the script with one of the methods above and paste the part that shows the found offsets and ASCII previews (the lines that say "PK offsets", "OLE offsets", or "MZ offsets" and the preview context). I will then tell you the exact carve command (offset + length) and which extraction command to run next.

patterns​

• Try to list contents with 7-Zip:
  "C:\Program Files\7-Zip\7z.exe" l C:\Temp\SamsungExtract\carved_from_OFFSET.bin

• If the carved file is an MSI (OLE Compound), use msiexec administrative extract:
  msiexec /a "C:\Temp\SamsungExtract\carved_from_OFFSET.bin" /qb TARGETDIR="C:\Temp\SamsungExtract\msi_extracted"

• Use the same carve code but set $remain = <size> (instead of reading to EOF) and write exactly that many bytes.

• Look in the extracted folder for .inf, .sys, .cat — driver binaries are typically in Driver\ or x64\ or _64\ subfolders inside the MSI.
• If you get the MSI(s), extract and copy the .sys/.inf/.cat to install manually or package for Windows.

• Run the corrected extraction.ps1 and paste the printed offsets and previews (the lines that say PK/OLE/MZ offsets and the ASCII preview).
• Tell me which offset you want carved (or paste all offsets) and I will tell you the exact carve command to run and the extraction command for the most likely payload (msi/cab).

• If script returns no PK/OLE offsets: you may have already carved the inner container (carved_container.exe). In that case search the original combined.bin for the big WixAttachedContainer offsets (you already saw the BurnManifest earlier — you can carve using that attached index offset). But the script above should find any PK/MZ/OLE inside carved_container.exe.
• If 7z says "not an archive", try carving exactly the size reported in the manifest for the payload.
• If carved file starts with many NULs (like your earlier read), try carving from the next printed offset (sometimes there are spurious MZ signatures padded).

read whole file into memory (file is ~3 MB)​

signatures​

carve entire remainder starting at offset​

• Try listing with 7z:

• If 7z lists files, extract:

• If it’s an MSI (OLE compound), use msiexec administrative extract:

• The earlier Format-Hex error was because your PS version doesn’t accept -Count; the file-read snippets you already used are fine.
• If the script returns no PK/OLE offsets: either you already carved the right inner container (search combined.bin instead of carved_container.exe), or the payload is compressed/embedded differently. In that case paste the script output here and I’ll guide next steps. The Burn manifest you previously printed suggests the attached container contains payloads and gives payload sizes (use those sizes in Carve-Range).
• If 7z says “not an archive” on a carved file, try carving exact payload size (manifest size) rather than to EOF; also try carving from the exact PK or OLE offset the script reported (not from an earlier 0-padded area).

• Run the corrected extraction.ps1 and paste the output (the offsets and previews it prints).
• Or paste the offset you want me to assume (you earlier mentioned 394394 — if that’s the one printed by the script, tell me) and tell me whether you know the payload size (e.g. 1212416 for SamsungInstaller64.msi). If you give me offset + size I will give the exact Carve-Range command and the exact 7z / msiexec commands to extract the MSI and find the .sys/.inf files.

• typed array declarations like [byte got mangled (square-brackets removed or comments injected).
• multiple statements ended up on one physical line (PowerShell then treats the tokens unexpectedly).
• inline comments placed inside typed attributes (e.g. [byte # comment]) break the parser.

1. Open Notepad (or VS Code), paste exactly the script below, save as
   C:\Temp\SamsungExtract\extraction_fixed.ps1

1. Run it with execution policy bypass (from an elevated or non-elevated prompt — elevation not required for reading the file):
   powershell -NoProfile -ExecutionPolicy Bypass -File "C:\Temp\SamsungExtract\extraction_fixed.ps1"
2. Paste the script output here (the offsets & previews). I will tell you exactly which offset(s) to carve and the carve command to use.

• Your earlier extraction.ps1 had bracket/comment corruption (e.g. [byte # comment]) and some statements ended up on one line — PowerShell then threw parse errors. Code tags on a forum do not alter the code, but copying from some web pages can change characters or line breaks (or remove square brackets) — always verify the saved script looks exactly like the intended code (Get-Content extraction.ps1 | Select-String -Pattern '[byte').

• the offsets printed, and
• whether you want me to provide the exact carve commands (Carve-Range) and the 7‑Zip/msiexec commands to extract the MSI and then locate the .inf/.sys files.