MSI Structured, Powerful, Transparent
An MSI is not just a file — it's a relational database. Under the hood it contains tables: Property, Feature, Component, CustomAction, Registry, File, Upgrade. Each one is queryable, diffable, and auditable before a single byte executes. That's the transparency advantage MSI has over every other format.
- ProductCode & UpgradeCode (identity)
- Manufacturer and version strings
- Full registry write manifest
- Service definitions and modifications
- Every custom action and its execution type
- Complete file inventory before install
The structure is always visible. The behavior can still be dangerous. MSI gives you transparency, not safety — but transparency is exactly what makes pre-deployment analysis possible.
Deferred custom actions running cmd.exe, encoded PowerShell stored in the Binary table, and network calls triggered at install time are all structurally invisible until analyzed. pkgprobe extracts and flags each of these automatically — catching behavior that MSI's own structure deliberately obscures.
MSIX Containerized and Constrained
MSIX was Microsoft's attempt to fix MSI's behavioral freedom problem. By enforcing containerization, clean uninstall semantics, controlled file locations, and manifest-driven permissions, it trades flexibility for predictability. The AppxManifest.xml is structured, human-readable, and defines everything the package is allowed to do — before it runs.
- App identity via signed manifest
- Declared capabilities (explicit permission model)
- Execution alias and entry points
- Package identity and publisher
- Declared dependencies and framework refs
The containerized model eliminates entire categories of risk — registry sprawl, orphaned services, install-time code execution. But MSIX's safety boundaries apply to the container, not to embedded payloads. An MSIX wrapping a malicious EXE is still a malicious installer. Validation still matters.
EXE The Wild West
EXE installers are the most common format and the least predictable. An EXE can be anything: NSIS, Inno Setup, InstallShield, Squirrel, WiX Burn, a custom compiled installer, a wrapper around MSI, a wrapper around another EXE, or something entirely proprietary. There is no structural contract. Analysis is entirely heuristic.
framework_detected NSIS detection_method string match → "NullsoftInst" confidence 0.91 silent_flags_ranked ├─ /S score: 0.93 ├─ /silent score: 0.41 └─ /VERYSILENT score: 0.12 (NSIS-specific override) signature SIGNED — Acme Corp embedded_payloads 1 detected — secondary EXE
Detection relies on signatures and heuristics: NullsoftInst strings suggest NSIS, Inno Setup Setup Data sections identify Inno, BurnManifest resources indicate WiX Burn. Confidence scoring becomes the critical output — not just a guess, but a ranked probability.
- Digital signature and certificate chain
- PE headers and version resources
- Embedded string indicators
- Framework fingerprints (with confidence score)
04 Silent Install Reality Across Formats
Silent install behavior is where the format differences become most operationally painful. MSI is standardized. MSIX sidesteps the problem entirely. EXE is framework-dependent chaos — and every team rediscovers this independently.
- /qn
- /passive
- /quiet
- Add-AppxPackage (PowerShell)
- winget install
- AppInstaller protocol
- /S (NSIS)
- /silent (various)
- /VERYSILENT (Inno)
- /quiet (various)
- --silent (modern)
05 Security Posture Comparison
Across the three dimensions that matter for pre-deployment validation — how much you can see, how predictably it behaves, and where risk concentrates — each format has a distinct profile:
| Format | Transparency | Predictability | Primary risk surface |
|---|---|---|---|
| MSI | High | Medium | Custom action execution |
| MSIX | Medium–High | High | Embedded legacy components |
| EXE | Low | Low | Behavioral (all of the above) |
06 Format-Specific Validation Strategy
Different formats require different validation approaches. Treating an EXE the same as an MSI means missing the behavioral analysis that EXEs require — and over-engineering the analysis that MSI already makes trivial. Here's the right strategy for each:
- Inspect all custom actions and execution types
- Validate signature and publisher match
- Confirm UpgradeCode stability across versions
- Extract and audit registry write footprint
- Flag encoded payloads in Binary table
- Validate manifest capabilities against policy
- Confirm signing chain integrity
- Inspect for embedded MSI or EXE payloads
- Audit external runtime dependencies
- Verify publisher identity matches declaration
- Detect installer framework with confidence score
- Rank silent switch candidates by reliability
- Validate digital signature and chain
- Perform behavioral inference via string analysis
- Flag secondary payloads and download logic
07 The Real Insight
Three things that sound reassuring — but aren't guarantees on their own:
The only reliable approach is analysis — format-aware, field-by-field, behavior-informed analysis. The format tells you what tools to use. It doesn't tell you whether to trust the result.
Installers are not just delivery mechanisms. They are execution environments. If you don't know what format you're dealing with — and what that format implies — you're deploying blind.
Understand the format. Then analyze it. The two steps are sequential for a reason — the right analysis strategy depends entirely on what you're looking at. pkgprobe handles both automatically, adapting its analysis depth and output to the format it detects.
Analyze MSI, MSIX, and EXE before they deploy
Drop any installer into pkgprobe and get format-aware risk analysis — signature state, custom action audit, framework detection, CVE matches, and more.