### Repository-Checkout```powershell
git clone https://github.com/warpedatom/OffsetInspect.git
cd OffsetInspect
Import-Module ./module/OffsetInspect/OffsetInspect.psd1 -Force

## Offset-Inspektion

### Menschenlesbare Ausgabe```powershell
Invoke-OffsetInspect ./sample.bin 0x200

### Strukturierte Objekte```powershell
$inspectParameters = @{
    FilePaths    = './script.ps1'
    OffsetInputs = 0x80, 0x100
    PassThru     = $true
}
$results = Invoke-OffsetInspect @inspectParameters

$results | Where-Object BytesDiffer

Der JSON-Modus gibt immer ein Array aus, auch für ein einzelnes Ergebnis.

### Binärvergleich```powershell
$compareParameters = @{
    FilePaths    = './before.bin'
    OffsetInputs = 0x200
    CompareFile  = './after.bin'
    PassThru     = $true
}
Invoke-OffsetInspect @compareParameters

Textmodus verwendet `AmsiScanString`, durchsucht Unicode-Skalar-Präfixe, ohne Surrogatpaare zu teilen, mappt das erkannte Präfix über die validierte Quellkodierung und gibt Indizes für Unicode-Skalare, UTF-16-Code-Einheiten und Quell-Datei-Bytes zurück. Eingebettete NUL-Zeichen werden im Textmodus abgelehnt; verwenden Sie für solche Dateien den Rohbyte-Modus.

### AMSI-Rohbyte-Scan```powershell
Invoke-OffsetThreatScan ./content.bin -Engine AMSI -ScanMode RawBytes

Der Defender-Provider:

- Ermittelt den Pfad der neuesten installierten `MpCmdRun.exe`-Plattform.
- Schreibt Präfixe in ein eindeutiges temporäres Benutzerverzeichnis.
- Verwendet einen benutzerdefinierten Scan mit `-DisableRemediation`.
- Behandelt Zeitüberschreitungen, Providerfehler, lokalisierte/unbekannte Ausgaben und mehrdeutige Marker als nicht endgültig.
- Löscht den temporären Arbeitsbereich, wenn der Scan abgeschlossen ist.

### Grenzsemantik

Ein Ergebnis wie `DetectionPrefixLength = 841` bedeutet:

- Präfixlänge 840 wurde als sauber/nicht erkannt klassifiziert.
- Präfixlänge 841 wurde als erkannt/blockiert klassifiziert.
- Wiederholte Prüfungen bestimmen, ob dieser Übergang stabil ist.

Es beweist **nicht**, dass Byte 840 die vollständige Signatur, das einzige beitragende Byte oder der gesamte schädliche Bereich ist. Antiviren-Entscheidungen können von Tokenisierung, umgebendem Kontext, Dateityp, Providerstatus und Signaturaktualisierungen abhängen.

### Praxisbeispiel: zwei Engines, eine Datei

Das Scannen derselben Probe (PowerUp.ps1, ein öffentliches Red-Team-Skript, 445.954 Bytes) mit beiden Providern zeigt, was eine Grenze ist und wie weit man zwei Engines vertrauen kann, dass sie übereinstimmen. AMSI im Textmodus:```text
Threat boundary scan: C:\Ops\Samples\PowerUp.ps1
SHA-256:              7abc87d9620aef493617a4fc1f823850f32fb26ca9ae0f3befeadb04971e0246
Engine:               AMSI
Scan mode:            Text
Initial status:       Detected
Scans performed:      25
Provider probes:      25 (see -Verbose or the ProbeLog property for the full audit trail)
Duration:             22771.419 ms
Known clean prefix:   445953
Detected prefix:      445954
Boundary offset:      445953 (0x6CE01)
Unicode scalar index: 445953
UTF-16 code-unit idx: 445953
Stable:               True
Confidence:           High

Line number:          4586
Byte in line:         46
Target byte:          0A (10)

--- Source Context ---
   4585 | Set-Alias Get-CurrentUserTokenGroupSid Get-ProcessTokenGroup
   4586 | Set-Alias Invoke-AllChecks Invoke-PrivescAudit
                                                       ^

Engine:               Defender
Scan mode:            RawBytes
Initial status:       Detected
Scans performed:      25
Duration:             15370.562 ms
Known clean prefix:   445951
Detected prefix:      445952
Boundary offset:      445951 (0x6CDFF)
Stable:               True
Confidence:           High
Signature:            Trojan:Win32/Kepavll!rfn

Line number:          4586
Byte in line:         44
Target byte:          69 (105)

--- Hex Dump ---
0006CDBF  74 2D 50 72 6F 63 65 73 73 54 6F 6B 65 6E 47 72   t-ProcessTokenGr
0006CDCF  6F 75 70 0A 53 65 74 2D 41 6C 69 61 73 20 49 6E   oup.Set-Alias In
0006CDDF  76 6F 6B 65 2D 41 6C 6C 43 68 65 63 6B 73 20 49   voke-AllChecks I
0006CDEF  6E 76 6F 6B 65 2D 50 72 69 76 65 73 63 41 75 64   nvoke-PrivescAud
0006CDFF  69 74 0A                                          it.
```
Beide Engines konvergieren auf **Zeile 4586** – die Grenze von Defender fällt in das abschließende `it` von `Invoke-PrivescAudit`, die von AMSI auf den Zeilenumbruch, der dieselbe Zeile beendet, zwei Bytes später. Keiner der Offsets ist „die Signatur“: Es handelt sich um das früheste Präfix, das der jeweilige Anbieter noch markiert, und die Zwei-Byte-Diskrepanz ist exakt der oben beschriebene Tokenisierungs-/Kontexteffekt. Defender benennt zusätzlich, was er erkannt hat (`Trojan:Win32/Kepavll!rfn`); AMSI meldet keinen Signaturnamen, weshalb `Invoke-OffsetThreatScanRegion` und `Get-OffsetDetectionTrigger` existieren, um einen AMSI-Treffer zu charakterisieren.

Beide Scans kosten 25 Anbieter-Sonden für eine ~436 KiB große Datei – die Bisektion ist logarithmisch zur Dateigröße, und jede Sonde wird in `ProbeLog` protokolliert.

Siehe [Threat-Scanning-Design](https://github.com/warpedatom/offsetinspect/blob/HEAD/docs/THREAT-SCANNING.md) für den Anbietervertrag und Hinweise zur Interpretation, [Provider-Schnittstelle](https://github.com/warpedatom/offsetinspect/blob/HEAD/docs/PROVIDER-INTERFACE.md) für den Scannervertrag und wie ein Anbieter hinzugefügt wird, ohne den Suchkern zu berühren, [Threat-Scanning-Herkunft](https://github.com/warpedatom/offsetinspect/blob/HEAD/docs/PROVENANCE.md) für Implementierungsgrenzen und Zuschreibung sowie [Ausgabeschema](https://github.com/warpedatom/offsetinspect/blob/HEAD/docs/OUTPUT-SCHEMA.md) für den versionierten Objektvertrag.

### Berichte zu Erkennungsgrenzen

`Export-OffsetThreatReport` wandelt ein oder mehrere Scanergebnisse in einen eigenständigen Markdown- oder HTML-Bericht um – Zusammenfassung pro Datei, Anbieter-/Signatur-/Engine-Metadaten, den vollständigen `ProbeLog`-Prüfpfad und Warnungen – zum Anhängen an einen Engagement-Bericht. Er liest nur Ergebnisse und scannt nie erneut, läuft also plattformübergreifend. Fügen Sie `-IncludeIoc` hinzu, um ein Hash-/Entropie-/PE-Indikator-Panel (dieselben Daten wie `Get-OffsetIOC`) in jeden Berichtseintrag aufzunehmen, und `-IncludeTrigger`, um für jedes Ergebnis mit einer Grenze eine Analyse des Erkennungsauslösers (siehe unten) hinzuzufügen.```powershell
Invoke-OffsetThreatScan ./sample.ps1 -Engine AMSI -ScanMode Text -PassThru |
    Export-OffsetThreatReport -Path ./report.html -Format Html

# Aggregate many scans into one report, with an indicators panel and trigger analysis per file:
$results | Export-OffsetThreatReport -Path ./engagement.md -IncludeIoc -IncludeTrigger
```
Bei Berichten im Korpusmaßstab durchsucht `-IncludeIoc` jede Datei erneut in PowerShell, was langsam ist. Die begleitende native Engine [OffsetScan](https://github.com/warpedatom/OffsetScan) erzeugt schemagleiche IOC-JSON weitaus schneller; weisen Sie den Bericht mit `-IocJsonPath` darauf hin, und er bezieht jedes Panel aus dieser JSON (und fällt nur für Dateien, die darin fehlen, auf ein Live-`Get-OffsetIOC` zurück):```powershell
offsetscan ioc ./corpus --recurse > ./ioc.json
$results | Export-OffsetThreatReport -Path ./engagement.md -IocJsonPath ./ioc.json
```
### Batch-/Korpus-Scan

`Invoke-OffsetThreatScanBatch` löst Dateien, Verzeichnisse und Platzhalter in eine Dateiliste auf, scannt jede davon (wobei Fehler einzelner Dateien übersprungen werden) und gibt ein Ergebnis pro Datei zurück. `-Summary` gibt eine flache Erkennungsmatrix zurück; die vollständigen Ergebnisse können direkt in den Berichtsgenerator eingespeist werden. Provider-Scanning ist nur unter Windows verfügbar.```powershell
Invoke-OffsetThreatScanBatch ./payloads -Recurse -Engine AMSI |
    Export-OffsetThreatReport -Path ./engagement.html -Format Html

Invoke-OffsetThreatScanBatch ./samples -Summary |
    Format-Table File, DetectionPrefixLength, Confidence, ProbeCount
```
### Erkennungsdiff / Regression

`Compare-OffsetThreatResult` vergleicht zwei Scanergebnisse - zum Beispiel dieselbe Datei vor und nach einem Signaturdefinitions-Update - und klassifiziert die Änderung (`NewlyDetected`, `NoLongerDetected`, `BoundaryEarlier`, `BoundaryLater`, `BoundaryUnchanged`, `BothClean`) mit dem Boundary-Delta und den geänderten Feldern.```powershell
$before = Invoke-OffsetThreatScan ./sample.ps1 -Engine Defender -PassThru
# ... update Defender signature definitions ...
$after  = Invoke-OffsetThreatScan ./sample.ps1 -Engine Defender -PassThru
Compare-OffsetThreatResult -Reference $before -Difference $after
```
### Multi-Region-Entdeckung

Die Präfixsuche findet die *erste* Erkennungsgrenze. `Invoke-OffsetThreatScanRegion` findet *mehrere* unabhängig erkennbare Regionen, indem die Datei in Segmente aufgeteilt und jedes einzeln über AMSI **vollständig im Speicher** gescannt wird - nichts Erkanntes wird auf die Festplatte geschrieben, sodass der Echtzeitschutz von Defender nie ausgelöst oder neu konfiguriert wird. Jeder Treffer wird innerhalb seines Segments halbiert, um die genaue auslösende Grenze einem absoluten Datei-Offset zuzuordnen.```powershell
Invoke-OffsetThreatScanRegion ./payload.bin -SegmentCount 16 |
    Select-Object -ExpandProperty DetectedRegions |
    Format-Table SegmentIndex, StartOffset, EndOffset, AbsoluteBoundaryOffset, SignatureName
```
Dies meldet Regionen, die eigenständig eine Erkennung auslösen; es kann Signaturen übersehen, die nur im Volldateikontext zum Tragen kommen oder eine Segmentgrenze überspannen. Behandeln Sie die Regionen daher als Hinweise, die mit `Invoke-OffsetThreatScan` und manueller Validierung bestätigt werden müssen. AMSI (im Speicher) ist die einzige hier unterstützte Engine - das Dateiscannen durch Defender würde erfordern, erkannten Inhalt auf die Festplatte zu schreiben.

### Korrelation der Erkennungsauslöser

Eine Grenze zeigt Ihnen, *wo* die Erkennung umschlägt; `Get-OffsetDetectionTrigger` zeigt Ihnen, *was* sich dort befindet. Da eine Präfixgrenze das letzte Byte des frühesten erkannten Präfixes ist, ist der auslösende Inhalt eine Bytefolge, die an diesem Offset endet. Der Befehl meldet die PE-Sektion, in die die Grenze fällt, die Entropie der Bytefolge bis zu diesem Punkt (Klartext vs. gepackt/kodiert) und die extrahierten Zeichenfolgen, die an ihr enden oder sie überspannen, sortiert nach Nähe - den Kandidaten-Signaturinhalt - mit einer einzeiligen Interpretation. Er liest nur Bytes und scannt nie erneut, daher läuft er plattformübergreifend auf gespeicherten Ergebnissen.```powershell
Invoke-OffsetThreatScan ./flagged.ps1 -Engine AMSI -PassThru | Get-OffsetDetectionTrigger

# Or point it at a file and a known boundary directly:
Get-OffsetDetectionTrigger -FilePath ./sample.bin -BoundaryOffset 0x4A1 |
    Select-Object Interpretation, Section, PreBoundaryEntropy -ExpandProperty CandidateStrings
```
### Erkennungsdrift-Protokoll

„Es wurde vorher erkannt und jetzt nicht mehr“ hat drei sehr unterschiedliche Ursachen: Die Datei hat sich geändert, die Signaturen haben sich geändert oder der Anbieter ist nicht deterministisch. `Add-OffsetDriftEntry` zeichnet Append-only-NDJSON-Snapshots auf – Datei-SHA-256, Status, Grenze, Signaturname und die lokalen Defender-Signatur-/Engine-Versionen – und `Get-OffsetDrift` liest diesen Verlauf und ordnet jede Änderung der richtigen Ursache zu.```powershell
# Record a snapshot over time (from a scan result, or directly):
Invoke-OffsetThreatScan ./sample.ps1 -Engine AMSI -PassThru | Add-OffsetDriftEntry
Add-OffsetDriftEntry -FilePath ./sample.ps1 -Status Detected -Engine AMSI -SignatureName 'Trojan:PowerShell/X'

# Later, explain what changed:
Get-OffsetDrift -FilePath ./sample.ps1 | Select-Object -ExpandProperty Transitions
```
Jeder Übergang ist gekennzeichnet: Eine SHA-256-Änderung gilt als **Dateimodifikation**; eine Statusänderung, bei der die Datei unverändert bleibt, aber die Defender-Signaturversion sich geändert hat, gilt als **Signaturdrift**; eine Statusänderung ohne beides gilt als **nicht-deterministisches** Providerergebnis. Das Journal liegt standardmäßig unter `%LOCALAPPDATA%\OffsetInspect\drift.ndjson`; überschreiben Sie diesen Pfad mit `-JournalPath`.

### Signatur-Robustheitstest (nur für autorisierte Nutzung)

`Invoke-OffsetMutationTest` beantwortet eine Frage der Erkennungsentwicklung: Ist eine Signatur ein fragiler exakter Literal-Abgleich oder robust gegenüber gängiger Verschleierung? Bei einer Probe, die AMSI derzeit erkennt, wendet es Standard-Perturbationen an - Umkehrung der Groß-/Kleinschreibung, String-Literal-Verkettung, Kommentar-Einfügung, Leerraum-Injektion - und scannt jede Variante erneut, um zu berichten, welche Klassen die Erkennung neutralisieren. **Alles geschieht im Speicher** über die In-Process-Schnittstelle von AMSI; keine Variante wird auf die Festplatte geschrieben, sodass keine ausweichenden Artefakte erzeugt werden und der Echtzeitschutz von Defender nicht beteiligt ist. Der Befehl verweigert die Ausführung ohne `-AuthorizedEngagement` und ist nur für Proben gedacht, die Sie testen dürfen.```powershell
Invoke-OffsetMutationTest -FilePath ./flagged.ps1 -AuthorizedEngagement |
    Select-Object RobustnessSummary -ExpandProperty Results
```
Ein Ergebnis wie etwa "brittle: neutralized by StringConcatenation, CommentInsertion" sagt einem Verteidiger, dass die Signatur auf einem zusammenhängenden Literal beruht und verbreitert werden sollte; einem autorisierten Operator sagt es dasselbe über die Abdeckung einer Kontrolle.

### Telemetriekorrelation

Das Erkennen einer Grenze sagt dir, was die *Engine* sieht; `-CaptureTelemetry` sagt dir, was der *Verteidiger* sieht. Es erfasst vor dem Scan die Hochwassermarke jedes zugänglichen Windows-Telemetrieprotokolls und berichtet dann, ob die Aktion einen Alarm ausgelöst hat, mit welchem Kontext und welche Quellen blind waren - die Frage "Sichtbarkeit annehmen, dann validieren", beantwortet mit Belegen.```powershell
$r = Invoke-OffsetThreatScan ./flagged.ps1 -Engine AMSI -CaptureTelemetry -PassThru
$r.Telemetry | Format-List AlertGenerated, CorrelationConfidence, Findings
$r.Telemetry.Alert | Format-List ThreatName, SeverityName, SourceName, ProcessName, DetectionUser
```
The `Telemetry` property (`OffsetInspect.TelemetryCorrelation`) reports:

- `AlertGenerated` / `Alert` - ob eine Microsoft-Defender-Erkennung (Ereignis 1116/1117) für den Scan protokolliert wurde, und ihr Kontext (Bedrohungsname, Schweregrad, Erkennungsquelle, Prozess, Benutzer).
- `CorrelationConfidence` - **Hoch** nur wenn die Quelle der Erkennung mit dem Anbieter übereinstimmt **und** ihr Prozess mit dem Scan-Host übereinstimmt, sodass eine zufällige gleichzeitige Erkennung nie behauptet wird; Mittel bei nur Quelle; Niedrig bei keiner von beiden.
- `SourcesAccessible` / `SourcesUnavailable` - welche Telemetrie-Logs lesbar und welche blind waren (Sysmon fehlt, das Sicherheitsprotokoll erfordert erhöhte Rechte). Eine Sichtbarkeitslücke ist selbst ein Befund.
- `Findings` - Schlussfolgerungen in einfacher Sprache: ein Alert mit vollem Kontext, ein Alert ohne Bedrohungsnamen, gar keine Telemetrie oder eine fehlende Quelle.

Die primäre Quelle ist das Microsoft-Defender-Betriebsprotokoll, das ohne erhöhte Rechte lesbar ist; die Korrelation erfolgt über die Ereignis-`RecordId` (monoton und zeitzonenunabhängig). Nur für Windows und wirkungslos, außer `-CaptureTelemetry` wird übergeben.

## Statische Triage-Helfer

Drei plattformübergreifende statische Analysebefehle unterstützen die Malware-Triage und lassen sich mit dem Offset-Kern kombinieren:

- `Get-OffsetEntropy` - Shannon-Entropie pro Fenster (Bits/Byte) zum Lokalisieren gepackter oder verschlüsselter Bereiche; die markierten Fenster mit den Erkennungen von `Invoke-OffsetThreatScanRegion` abgleichen.
- `Get-OffsetString` - druckbare ASCII- und UTF-16LE-Zeichenketten mit Byte-Offsets; Offsets zur Kontextanalyse in `Invoke-OffsetInspect` weiterleiten.
- `Get-OffsetPEInfo` - PE-Maschine/Bitness, Einstiegspunkt, Abschnittstabelle, **Importe und Imphash**, Erkennung angehängter **Overlay**-Daten und Ressourcengröße, wobei `-Offset` einen Byte-Offset auf seinen Abschnitt (`.text`, `.rsrc`, ...) abbildet. Imphash verwendet den Standard-`library.function`-MD5 und ist nachweislich byte-identisch mit pefile/VirusTotal - einschließlich der Ordinal-Auflösung spezieller Bibliotheken, sodass ein aus `ws2_32`/`wsock32`/`oleaut32` importierter Ordinalwert auf seinen tatsächlichen Funktionsnamen aufgelöst wird; jeder andere Ordinal-Import wird als `ordNNN` dargestellt, genau wie bei pefile.
- `Get-OffsetIOC` - ein einzelnes Indikator-Panel, das die obigen Funktionen kombiniert: MD5/SHA-1/SHA-256 (in einem Durchgang), Gesamtentropie, Anzahl druckbarer Zeichenketten sowie PE-Maschine/Imphash/Overlay, sofern zutreffend.```powershell
Get-OffsetEntropy ./sample.bin -HighOnly | Select-Object -ExpandProperty Windows
Get-OffsetString ./sample.bin -MinimumLength 6 | Where-Object Value -match 'http|\.dll'
Get-OffsetPEInfo ./sample.exe | Select-Object Machine, EntryPointHex, ImpHash, ImportedDllCount, HasOverlay, OverlaySize
Get-OffsetIOC ./sample.exe | Format-List
```
### YARA-Scanning

`Invoke-OffsetYaraScan` führt von Analysten erstellte YARA-Regeln aus und gibt jeden Treffer mit seinem Byte-Offset zurück - ergänzt die Sicht auf die Erkennungsgrenzen von AMSI/Defender um Signaturen, die Sie kontrollieren, und benötigt keine installierte Antivirensoftware (nur die YARA-Engine, z. B. `winget install VirusTotal.YARA`). Die Offsets fließen direkt in den Inspector ein.```powershell
Invoke-OffsetYaraScan ./sample.bin -RulePath ./rules/malware.yar |
    ForEach-Object { Invoke-OffsetInspect $_.File $_.Offset -ContextLines 2 }
```
### ClamAV-Scanning

`Invoke-OffsetClamScan` scannt eine Datei mit der ClamAV-On-Demand-Engine und gibt ein normalisiertes Ergebnis zurück (`Clean` / `Detected` / `Error` sowie den Signaturnamen). Da `clamscan` bei jedem Aufruf die gesamte Signaturdatenbank lädt, ist es ein Einzeldatei-Detektor und keine Grenzsuch-Engine (dafür wäre der `clamd`-Daemon erforderlich). Es erfordert, dass ClamAV installiert **und** seine Signaturdatenbanken heruntergeladen sind – `freshclam` wird erst ausgeführt, wenn eine Konfigurationsdatei vorhanden ist:```powershell
# One-time setup: create the freshclam config (remove the sample's "Example" line), then fetch databases.
Copy-Item "$env:ProgramFiles\ClamAV\conf_examples\freshclam.conf.sample" "$env:ProgramFiles\ClamAV\freshclam.conf"
(Get-Content "$env:ProgramFiles\ClamAV\freshclam.conf") -notmatch '^\s*Example\s*$' |
    Set-Content "$env:ProgramFiles\ClamAV\freshclam.conf"   # requires admin to write under Program Files
& "$env:ProgramFiles\ClamAV\freshclam.exe"

Invoke-OffsetClamScan ./sample.bin
```
Verwenden Sie `-DatabasePath`, um auf ein Signaturverzeichnis an einem beschreibbaren (Nicht-Admin-)Speicherort zu verweisen, und `-ClamScanPath`, falls `clamscan` nicht im `PATH` ist.

## Ergebnisobjekte

`Invoke-OffsetInspect -PassThru` gibt `OffsetInspect.Result`-Objekte zurück, die Folgendes enthalten:

- Kanonischer Dateipfad, Dateigröße, dezimale und hexadezimale Offsets.
- Angeforderte und erkannte Kodierung.
- Zeilennummer, Quellvorschau, Kontextzeilen, Byteposition und Zeichenposition.
- Zielbyte und begrenzter Hex-Dump.
- Optionales Vergleichsbyte und Differenzstatus.
- Warnungen, Dauer, Erfolgsstatus und Fehlermeldung.

`Invoke-OffsetThreatScan -PassThru` gibt `OffsetInspect.ThreatScanResult`-Objekte zurück, die Folgendes enthalten:

- Datei-SHA-256, UTC-Scanzeitstempel, Engine, Scanmodus, anfänglicher Providerstatus und Provider-Metadaten.
- Bekannt-saubere und bekannt-erkannte Präfixlängen.
- Byte- und optionale Zeichengrenze.
- Stabilität, Konfidenz, Scananzahl, wiederholte Grenzstatus und ggf. Signaturname.
- Ein `ProbeLog`-Auditpfad für jede einzelne Provider-Probe (in der CSV-Ausgabe als `ProbeCount` sichtbar und mit `-ProbeLogPath` in ein JSON-Transkript exportierbar); siehe [Ausgabeschema](https://github.com/warpedatom/offsetinspect/blob/HEAD/docs/OUTPUT-SCHEMA.md).
- Verschachtelter `OffsetInspect.Result`-Kontext an der zugeordneten Grenze.

## Leistungsmodell

Die Implementierung im v1-Stil las und dekodierte für jeden Offset eine vollständige Datei erneut. Version 2 gruppiert die Arbeit nach Datei:```text
Previous approach: approximately O(file size × offset count)
Version 2:         approximately O(file bytes scanned once + requested windows)
```
Das Source-Mapping verwendet eine Streaming-Zustandsmaschine und behält nur die vorhergehenden/nachfolgenden Zeilendeskriptoren, die für angeforderte Offsets erforderlich sind. Extrem lange einzelne Zeilen werden über eine begrenzte Vorschau angezeigt, die durch `-MaxLineBytes` gesteuert wird.

## Repository-Struktur```text
OffsetInspect.ps1                 Thin offset-inspection CLI wrapper
OffsetThreatScan.ps1              Thin threat-scan CLI wrapper
module/OffsetInspect/             Complete Gallery package
  OffsetInspect.psd1
  OffsetInspect.psm1
  OffsetInspect.Format.ps1xml
  Public/
  Private/
tests/                            Pester tests
benchmarks/                       Reproducible performance harness
build/                            Validation, packaging, signing, publishing
.github/workflows/                CI, dependency review, release publishing
docs/                             Architecture, schemas, provider design, release checklist
```
## Entwicklung

Installiere die festgepinnten Validierungswerkzeuge:```powershell
Install-Module Pester -RequiredVersion 5.7.1 -Scope CurrentUser
Install-Module PSScriptAnalyzer -RequiredVersion 1.25.0 -Scope CurrentUser
```
Führen Sie das vollständige lokale Gate aus:```powershell
./build/Test-Module.ps1
```
Führe das deterministische Benchmark-Harness aus:```powershell
./benchmarks/Measure-OffsetInspect.ps1 -FileSizeMiB 64 -OffsetCount 5000
```
Benchmark-Ergebnisse variieren je nach Speicher, Host-Last, PowerShell-Edition und Dateiform. Dokumentieren Sie diese Eingaben beim Vergleich von Commits.

Erstellen Sie ein deterministisches Release-Archiv und eine SHA-256-Datei:```powershell
./build/New-ReleasePackage.ps1
```
CI validiert PowerShell 7 unter Windows und Linux, Windows PowerShell 5.1, PSScriptAnalyzer, isolierte Modulpaketierung und das Release-Archiv. Release-Maintainer sollten außerdem der [Release-Checkliste](https://github.com/warpedatom/offsetinspect/blob/HEAD/docs/RELEASE-CHECKLIST.md) folgen.

## Sicherheit und verantwortungsvoller Einsatz

OffsetInspect ist für autorisierte defensive Forschung, Detection Engineering, Reverse Engineering, Malware-Analyse und Sicherheitstests gedacht. Threat-Provider-Funktionen analysieren Inhalte, deaktivieren, umgehen oder konfigurieren jedoch keine Endpoint-Schutzmaßnahmen neu.

`Invoke-OffsetMutationTest` erzeugt Erkennungsumgehungs-Varianten zur Bewertung der Signaturrobustheit. Es arbeitet vollständig im Speicher (keine Variante wird auf die Festplatte geschrieben) und weigert sich, ohne die ausdrückliche Bestätigung `-AuthorizedEngagement` ausgeführt zu werden. Verwenden Sie es nur gegen Proben und Kontrollen, die Sie testen dürfen.

Lesen Sie [SECURITY.md](https://github.com/warpedatom/offsetinspect/blob/HEAD/SECURITY.md), bevor Sie eine Schwachstelle melden. Reichen Sie keine sensiblen Beispiele über öffentliche GitHub-Issues ein.

## Lizenz

OffsetInspect wird unter der [MIT License](https://github.com/warpedatom/offsetinspect/blob/HEAD/LICENSE) veröffentlicht.