Obfuskierte Stack-Traces lesen: Umbenennungs-Maps und Crash-Deobfuskierung

Umbenennen ist das Erste, was die meisten .NET-Obfuskatoren tun, und der billigste Gewinn, den sie bieten: Billing.InvoiceService.Charge wird zu a.b.c, und ein Decompiler reicht einem Leser Ihre Architektur nicht mehr gratis. Der Haken zeigt sich Wochen später, beim ersten echten Crash, der aus dem Feld zurückkommt. Der Stack-Trace ist da, die Zeile stimmt — aber jeder Frame liest sich als a.b(c), und Sie können nicht erkennen, was kaputtging. Der Instinkt ist, das Umbenennen abzuschalten. Der richtige Zug ist, die Umbenennungs-Map aufzubewahren und zu lernen, durch sie hindurch zu lesen.

Warum der Trace verwürfelt, aber nicht verloren ist

Ein .NET-Stack-Trace wird zum Wurfzeitpunkt aus Metadaten erstellt, die in der ausgelieferten Assembly liegen: die Methoden-Tokens auf dem Aufruf-Stack, aufgelöst zu ihren Namen. Die Obfuskierung hat diese Namen vor der Auslieferung umgeschrieben, also meldet der Trace treu die Namen, die tatsächlich im Binary stehen — die obfuskierten. Nichts ist beschädigt. Der Ausnahmetyp, die Nachricht, die Aufrufreihenfolge und (wenn Sie Symbole behalten haben) die Zeilennummern sind alle echt. Das Einzige, was fehlt, ist das Wörterbuch, das die ausgelieferten Namen auf Ihre zurückabbildet.

Dieses Wörterbuch ist die Umbenennungs-Map, und ein guter Obfuskator gibt eine pro Build aus. Sie wird nicht mit der App ausgeliefert — das gäbe einem Angreifer die exakte Umkehrung der Obfuskierung. Sie ist ein Build-Artefakt, das Sie neben den PDBs dieser Version archivieren.

Was ein Map-Eintrag tatsächlich enthält

Man ist versucht, sich die Map als flache Tabelle aus alterName → neuerName vorzustellen, aber das zerfällt sofort, weil Obfuskatoren kurze Namen aggressiv wiederverwenden. a könnte hundert unzusammenhängende Methoden sein; b ein Dutzend Typen. Der Geltungsbereich hält sie auseinander, also ist jeder Map-Eintrag vollständig qualifiziert — deklarierender Typ plus vollständige Signatur — nicht nur ein Blattname. Konzeptuell sehen ein paar Zeilen so aus:

# original (fully qualified)                        => obfuscated
Billing.InvoiceService::Charge(Customer, Money)      => a.b::c(a.d, a.e)
Billing.InvoiceService::.ctor(IClock)                => a.b::.ctor(a.f)
Core.Money::FromMinor(Int64, String)                 => a.e::a(System.Int64, System.String)

Die echte Datei ist meist XML oder ein werkzeugspezifisches Format, aber die Form ist dieselbe: ein ursprüngliches Element, identifiziert durch Namespace, Typ, Member und Signatur, gepaart mit seiner obfuskierten Form. Weil der Schlüssel der vollständige Frame ist, sind A::a(int) und B::a(string) getrennte Zeilen, auch wenn beide Blätter a sind. Ein Deobfuskator, der nur über den kurzen Namen abgleicht, übersetzt falsch; einer, der über den qualifizierten Frame abgleicht, ist exakt.

Einen Trace deobfuskieren, Frame für Frame

Hier ist ein obfuskierter Trace, wie er in einem Crash-Bericht eintreffen könnte:

System.InvalidOperationException: Sequence contains no elements
   at a.e.a(Int64 A_0, String A_1)
   at a.b.c(a.d A_0, a.e A_1)
   at a.g.b(a.d A_0)
   at X.<>c__DisplayClass4_0.a()

Ihn mit der Map dieses Builds zurückzulesen verwandelt jeden Frame in seine ursprüngliche Identität:

System.InvalidOperationException: Sequence contains no elements
   at Core.Money.FromMinor(Int64 minor, String currency)
   at Billing.InvoiceService.Charge(Customer customer, Money amount)
   at Billing.BatchRunner.Run(Customer customer)
   at Billing.BatchRunner.<Run>b__4_0()   // lambda in Run

Zwei Details sind hier wichtig. Erstens werden compilergenerierte Frames — die <>c__DisplayClass-Closure, die b__-Lambda — vom Umbenennen meist unangetastet gelassen, weil der Compiler, nicht Sie, sie benannt hat; eine gute Map löst dennoch die enthaltende Methode auf, damit Sie wissen, dass die Lambda in Run lebte. (Falls Ihnen dieser Teil unbekannt ist, wie Lambdas zu Display-Klassen werden behandelt die Form.) Zweitens erscheinen Parameternamen wie A_0, weil der Obfuskator die Originale entfernt hat; wenn Sie sie zurück wollen, bewahren Sie die Parameternamen in der Map auf oder deaktivieren Sie das Umbenennen von Parametern für die Frames, die Ihnen wichtig sind.

Die Übersetzung selbst ist mechanisch: Zerlegen Sie den Trace in Frames, und schlagen Sie für jeden Frame (deklarierender Typ, Member, Signatur) in der Map nach und ersetzen Sie das Original. Die einzige echte Feinheit ist das Abgleichen — Sie müssen die obfuskierte Signatur genauso normalisieren, wie die Map sie gespeichert hat (vollständig qualifizierte Parametertypen, einschließlich der bereits obfuskierten Typnamen), sonst geht die Suche daneben.

Die Map sicher und auffindbar halten

Eine Map ist nur nützlich, wenn Sie Monate nach dem Ausliefern eines Builds die exakte Map für diesen Build finden können — und nur Sie es können. Drei Praktiken machen das verlässlich:

• Archivieren Sie eine Map pro Build, indiziert nach Version und Modul. Legen Sie sie neben den PDBs als Build-Artefakt ab, benannt nach Assembly-Version und idealerweise der Mvid des Moduls (die GUID, die in jedes kompilierte Modul eingebrannt ist). Wenn ein Crash eintrifft, nennt der Bericht die Version; das wählt die Map ohne Raten aus.
• Lassen Sie die Map nie in die Nähe des Clients. Sie gehört nicht in den Installer, das App-Verzeichnis, ein NuGet-Paket oder einen öffentlichen Symbol-Server. Behandeln Sie sie wie einen Signaturschlüssel: interner Speicher, zugriffskontrolliert. Eine ausgelieferte Map ist eine deobfuskierte App.
• Deobfuskieren Sie serverseitig, bei der Annahme. Verdrahten Sie die Übersetzung dort, wo Crash-Berichte landen, sodass eingehende obfuskierte Traces automatisch gegen die passende archivierte Map aufgelöst werden. Ihre Dashboards zeigen dann echte Namen; der Nutzer sieht nie eine Map und braucht nie eine.

Wann Sie einen Frame lesbar lassen wollen

Vollständiges Umbenennen plus eine private Map ist der richtige Standard, aber manchmal nehmen Sie bewusst ein paar Member vom Umbenennen aus — eine öffentliche SDK-Oberfläche, an die Aufrufer per Name binden, einen Plugin-Vertrag oder eine Handvoll Einstiegspunkte oberster Ebene, die Sie auch ohne Map lesbar wollen. Diese Frames kommen in einem Trace so lesbar an, wie sie sind, und alles darunter bleibt obfuskiert. Nebula lässt Sie das Umbenennen mit Einschluss-/Ausschlussregeln genau dafür eingrenzen: Schützen Sie die internen Teile aggressiv, bewahren Sie die bewusst öffentlichen Namen, und geben Sie eine Map aus, die den Rest abdeckt.

Der rote Faden: Ein obfuskierter Stack-Trace ist kein verlorener Stack-Trace. Der Crash ist echt und die Information ist intakt — sie ist in den tatsächlich ausgelieferten Namen geschrieben. Bewahren Sie die Map pro Build auf, lösen Sie Traces auf Ihrer Seite auf, und Sie erhalten den vollen Schutz des Umbenennens ohne die Debugging-Steuer. Deaktivieren Sie das Umbenennen, um Traces lesbar zu machen, und Sie haben dem Leser schlicht Ihre Symbol-Map gratis gereicht; bewahren Sie stattdessen die Map auf, und nur Sie können sie lesen.