Analyse

Wie man einen Installertyp konkret identifiziert.

Die Dateiendung allein reicht selten. In der Praxis identifiziert man eine Engine ueber mehrere Indizien: Dateityp, Hilfetext, eingebettete Strings, Child-Prozesse, Logausgaben und die Artefakte nach einem Testlauf.

Wichtige Grundregel

Ein einzelner Treffer ist fast nie ein Beweis. Erst wenn mehrere Hinweise zusammenpassen, ist die Engine belastbar bestimmt.

Ziel der Analyse

Du willst nicht nur einen Namen erraten, sondern den technisch richtigen Installationspfad finden: msiexec, Add-AppxPackage, herstellerspezifische EXE-Schalter oder einen Wrapper mit internem MSI.

Beste Reihenfolge

Dateiendung, Dateieigenschaften, Hilfetext, Strings, Testlauf mit Logging und Beobachtung von Child-Prozessen. Diese Reihenfolge liefert schnell brauchbare Belege.

Was oft schiefgeht

Viele paketieren direkt mit einem vermuteten Schalter. Das fuehrt zu stillen Fehlschlaegen, falscher Detection oder Wrappern, die intern ganz anders arbeiten.

Schnellentscheid

Die erste Einordnung in 60 Sekunden

Diese Entscheidung ist nur der Start. Danach braucht es trotzdem mindestens einen kontrollierten Testlauf.

Dateiendung

  • .msi = direkt MSI und damit msiexec
  • .msix oder .appx = MSIX/AppX-Pfad
  • .exe = weitere Analyse noetig

Erste EXE-Heuristik

  • /S oder Nullsoft-Strings = NSIS-Verdacht
  • /VERYSILENT, /SP- oder /NORESTART = Inno-Verdacht
  • /s /v, setup.iss, isscript = InstallShield-Verdacht
  • Startet intern msiexec.exe = Wrapper statt reine EXE

Konkrete Befehle

Was man wirklich ausfuehrt

Diese Befehle geben dir schnell verwertbare Hinweise. Nicht jeder Treffer ist beweisend, aber die Kombination ist in der Praxis sehr stark.

PowerShell
$file = Get-Item .\setup.exe
$file.VersionInfo | Format-List FileDescription, CompanyName, ProductName, OriginalFilename

Start-Process .\setup.exe -ArgumentList '/?' -Wait
Start-Process .\setup.exe -ArgumentList '/help' -Wait
Start-Process .\setup.exe -ArgumentList '/silent' -Wait
PowerShell
$bytes = [System.IO.File]::ReadAllBytes((Resolve-Path .\setup.exe))
$text = [System.Text.Encoding]::ASCII.GetString($bytes)

$patterns = 'Nullsoft','NSIS','/VERYSILENT','/SP-','InstallShield','setup.iss','msiexec'
foreach ($pattern in $patterns) {
    if ($text -match [regex]::Escape($pattern)) {
        "Treffer: $pattern"
    }
}

Indizienmatrix

Woran man die gaengigen Engines erkennt

MSI

MSI

Klare Dateiendung, oeffnet mit Windows Installer, laeuft ueber msiexec. ProductCode, UpgradeCode und Tabellen lassen sich direkt auslesen.

Zur MSI-Seite
NSIS

NSIS / Nullsoft

Haefig Treffer auf Nullsoft, NSIS oder Hilfetext mit /S. Uninstall-String und Artefakte nach Testlauf bestaetigen den Verdacht.

Zur NSIS-Seite
Inno

Inno Setup

Typische Schalter sind /VERYSILENT, /SP-, /NORESTART, /LOG. Auch Tasks und Components sind ein starker Hinweis auf Inno.

Zur Inno-Seite
InstallShield

InstallShield

Oft Wrapper-Verhalten, Treffer auf setup.iss, isscript oder internen MSI-Aufruf. Nicht selten muss man Child-Prozesse beobachten, um die echte Engine zu finden.

Zur InstallShield-Seite
MSIX

MSIX / AppX

Andere Paketlogik mit Signierung, Abhaengigkeiten und AppX-Kommandos. Hier geht es nicht um klassische Silent-Schalter, sondern um Deployment-Kontext und Paketstruktur.

Zur MSIX-Seite
Wrapper

Wrapper und Launcher

Viele EXE-Dateien sind nur ein Frontend. Wenn intern msiexec.exe oder ein weiteres Setup startet, musst du diese Ebene sichtbar machen und getrennt bewerten.

Wrapper-Artikel lesen

Testlauf

Wie man die Vermutung belastbar bestaetigt

Hilfetext sammeln

Teste /?, /help, -h und dokumentiere den exakten Output. Schon hier tauchen oft klare Engineschalter auf.

Child-Prozesse beobachten

Wenn die EXE intern msiexec.exe, ein zweites Setup oder Entpackstufen startet, ist der sichtbare Installer oft nur der Wrapper.

Logs erzwingen

Nutze alle bekannten Logging-Optionen und beobachte, welche Dateien wirklich geschrieben werden. Auch Logformat und Dateiname liefern starke Hinweise.

Artefakte nachher sichern

Uninstall-String, Registry, installierte Dateien und Produktcodes nach dem Testlauf sind haeufig der endgueltige Beleg fuer die echte Engine.

Praxisfaelle

Drei typische Fehlannahmen

/S heisst nicht automatisch NSIS

Andere Installer oder Hersteller-Wrapper koennen denselben Schalter anbieten. Erst Help-Text, Strings und Artefakte zusammen machen die Aussage belastbar.

Eine EXE kann intern MSI sein

Wenn ein Wrapper am Ende doch msiexec startet, willst du fuer Logging, Exitcodes und Detection die MSI-Ebene verstehen, nicht nur den EXE-Aufruf.

Herstellerdoku kann unvollstaendig sein

Dokumentation ist ein guter Hinweis, aber nie der Abschluss. Gerade bei aelteren Setups oder repackten Herstellervarianten weicht das reale Verhalten ab.

Passender naechster Schritt

Wenn du nach der Engine-Bestimmung direkt in die eigentliche Paketierung willst, ist der Workflow die naechste sinnvolle Seite.

Zum Workflow

Engine danach vertiefen

Sobald die Richtung klar ist, geh in die konkrete Installerseite. Dort stehen Schalter, Errorcodes, PowerShell-Beispiele und Praxisartikel.

Zu den Installern