When /quiet lies: tearing down a WiX Burn installer that ignores its own silent flag

Every fleet admin has met this installer. You pass /quiet. You pass /S, /silent, -q, the works. And it opens its shiny wizard anyway, on 200 machines, as SYSTEM, where no one will ever click Next.

This is the story of one of those - Sony’s Catalyst Browse - and how to beat it. Not by finding a magic flag (there isn’t one), but by tearing the installer apart and running what’s inside it directly. The technique works on a whole class of Windows installers, so I’ll show the general method, not just the one fix.

The suspect: a WiX Burn bundle

A huge share of “setup.exe” installers are WiX Burn bundles: a small native stub with one or more CAB containers appended to the end of the .exe. The stub’s job is to extract its bootstrapper application (the BA - the thing that draws the UI and makes decisions) and then install a chain of packages: usually a runtime or two, then the real MSI.

You can spot one without running it. The PE file carries a section literally named .wixburn, and that section is a little table of offsets: where the stub ends, where the attached containers start, and how big they are.

Here’s the part that matters for silent installs: Burn’s stub parses /quiet correctly and hands it to the BA. But the BA decides what to do with it. The stock WiX BA behaves. A custom BA - and vendors love shipping custom .NET BAs with brand-heavy wizards - is free to ignore the command line entirely. When that happens, no flag you pass will ever work. The lie isn’t in Burn; it’s in the vendor’s UI code.

The teardown, step by step

Read .wixburn. The section header gives you the stub size and the container layout. Everything after the stub is CAB data.
Extract the first (UX) container. It’s a plain CAB holding the BA and its config. Any CAB extractor works once you’ve carved it out at the right offset.
Read BurnManifest.xml. Inside the UX CAB, MSZIP-compressed. This is the Rosetta stone: it names the BA, lists every payload with its real file name, and spells out the install chain in order.
Extract the attached container(s). That’s where the actual payloads live - the MSIs and EXEs the wizard would have installed for you.

For Catalyst Browse, the manifest told the whole story in two lines: the BA is a custom managed (.NET) bootstrapper, and the chain is just vc_redist x64, then CatalystBrowse.msi. All that wizard drama wraps a completely ordinary MSI.

(One rabbit hole from step 3, for fellow implementers: MSZIP is not one deflate stream. It’s per-block deflate where each block ends with BFINAL set, and every block after the first needs the previous block’s output preloaded as its dictionary. Concatenate the blocks naively and you get exactly 32 KB of manifest and then garbage. Ask me how I know.)

The fix: skip the liar, run the chain

Once you have the payloads, you don’t need the BA’s opinion:

vc_redist.x64.exe /install /quiet /norestart
msiexec /i CatalystBrowse.msi /qn /norestart

That’s it. Fully silent, fully supported by the payloads themselves - msiexec /qn never lies - and exactly what the wizard would have done. Package those two lines and the extracted payloads, and the app deploys like anything else in your fleet.

This generalizes: when a Burn bundle ignores silent flags, extract the chain and install it in order. The manifest even gives you each package’s detect conditions and install arguments if you want to be thorough.

Doing it without the hex editor

If you have the WiX toolset installed, dark.exe (or wix burn extract in v4+) will unpack a bundle. But most admins fighting this at 4pm on a Friday don’t, so we built two things:

SwitchHunt - drop an installer .exe into the browser and it x-rays it: engine, silent switches, and for Burn bundles the BA type, the package chain, and a “this BA may ignore silent flags” risk callout. Nothing uploads anywhere; it parses locally.
Extract-BurnBundle.ps1 - a free, dependency-free PowerShell script (linked on the SwitchHunt page) that does the full teardown: carves the containers, decompresses the manifest, and drops the payloads in a folder with their real names. Drag the .exe onto it and you’re done.

The takeaway

An installer that ignores /quiet feels like a dead end because you’re arguing with the wrong layer. The wizard is a costume. Underneath, it’s almost always a boring package chain that installs silently just fine - the vendor just never wired the flag through their custom UI.

So don’t fight the costume. Open the box.

If you’d rather your deployment tool handle installers like this for you, that’s the itch RFF exists to scratch - it’s free up to 100 endpoints, and there’s a live demo with no signup.