Wie schützt Codeverschlüsselung vor reverse engineering ?

[Micke]

Dem Begriff zufolge, wird bei dieser Code Transformation ein Schlüssel verwendet. D.h. zur Laufzeit muss sowohl dieser wie auch der Entschlüsselungs-Algo. lesbar im Kompilat vorliegen.
Vermutlich kann alternativ beides auch in einer Blackbox liegen, aber dann muss diese eine leicht zugängliche decode Funktion bereitstellen.
Das Suchen einer dieser 2 Türen wird aber vermutlich nicht die schützende Hürde sein. Sondern ?

b)
Werden nach der Entschlüsselung die Methoden/Daten in der selben Form im RAM gehalten, wie ohne eine Codeverschlüsselung ?
Folge ich hierzu der Erklärung von Secureteam.net:
"[our code encryption] creates a runtime environment that executes the original MSIL code by decrypting one method at a time, this important virtue minimizes the exposure of MSIL code in memory and thus prevents dumping the code from physical memory."
liegen die Daten verständlicherweise zur Laufzeit entschlüsselt im RAM.
Wieso soll man diese dann mittels memory dumping nicht abgreifen können ? Vor allem liegt ja eigentlich nie nur 1 Methode aufm call stack.
Welches puzzle fehlt mir zum Konzept ? Meine ich nicht ironisch, immerhin findet es ja Anwendung.

 

[Stanzlinger]

Selbst Denuvo hat bisher nicht geholfen, von daher wird es immer jemand geben, der es knackt

 

[KitKat::new()]

Es schützt nicht, es macht es nur schwerer.

EDIT: nachträgliche Ergänzungen auf Grund von Uneindeutigkeit:
Die Sicherheit, die du womöglich auf Grund von "Verschlüsselung" erwartest, gibt es schlicht weg nicht.
Das hat wenig damit zu tun, dass es keine absolute Sicherheit gibt im Sinne davon, dass der Verschlüsselungsalgorithmus eine Sicherheitslücke haben kann oder der Schlüssel durch eine winzige Wahrscheinlichkeit theoretisch erraten werden könnte.
Per Design bekommt die CPU bzw. der Speicher alles notwendige an die Hand um das Programm auszuführen.

Selbst irgendwelche Hardwaremodule helfen nicht, denn am Ende landen alle Instruktionen an der CPU bzw. dessen Programmcodequelle, die das eigentliche Programm ja letztendlich ausführen muss.
Im Worst Case musst du eine CPU nachbauen, die die Instruktionen dann für dich abspeichert ;-)
Das ist wesentlich einfacher als wirksame Verschlüsselung zu überwinden

 

[Marco01_809]

Ja also ne Codeverschlüsselung kann es nicht geben ohne Hardware-Unterstützung. Wie du sagst muss der Schlüssel dem Code beiliegen, dann ist das ganze nur noch n Encoding bzw. Obfuscation. In Hardware als 'Blackbox' gibts das durchaus, z.B. Intel SGX. Dieses Feature hat sich aber auch als unsicher erwiesen und ist von Consumer-CPUs wieder verschwunden.

Von welchem Produkt reden wir denn?

 

[Tornhoof]

Werden nach der Entschlüsselung die Methoden/Daten in der selben Form im RAM gehalten, wie ohne eine Codeverschlüsselung ?

Kommt drauf an.
Der Cryptor fügt einen Hook vor und nach der Methode ein, ähnlich einem Profiler. Der Hook deobfuscated die Methode (also die Instruktionen) und danach wird der Speicherbereich in den deobfuscated wurde, wieder gelöscht/gewiped.

Die Dumper wie z.b. für PEProtect oder ähnliches, funktionieren auch wieder wie ein Profiler, sie hooken jede Methode und dumpen dann den deobfuscated Speicherbereich in Datei und versuchen mehr oder weniger erfolgreich Methoden Intro, also z.b. Stack backup/recovery zu erzeugen.

Es gibt im allgemeinen diverse Varianten, jedesmal deobfuscaten und zurücksetzen ist halt potentiell wahnsinnig langsam

Die modernen machen da eh wenig selber, die gehen über Hardwareenklaven oder ähnliches, nutzen also die entsprechenden CPU mechanismen aus.

Ergänzung zu MSIL:
Die meisten obfuscaten nur identifiers, also z.b. klassenname, methodenname usw.
Vollständige Verschlüsselung von MSIL funktioniert mit modernen .NET versionen (.NET Core+) nur bedingt

 

[kieleich]

Und wieso soll man dies mittels memory dumping nicht abgreifen können ?

Kannst du aber im Dump ist dann einfach nicht alles drin. Es ist ein steiniger Weg.

Und anders als bei Daten Ver/Entschlüsslung, kann man bei Code, auch immer anders machen (Obfuscation mit einem Recompiler etc.) so ist dann auch schwer fest zu stellen, was man schon hat, was noch fehlt. Es ist eben noch eine Stufe schwieriger als, wenn ein Programm einmal entschlüsselt dann komplett im RAM liegt.

Am Ende ist es ein Kampf gegen Windmühlen. Und kostet Rechenleistung ohne ende

 

[Micke]

Ja also ne Codeverschlüsselung kann es nicht geben ohne Hardware-Unterstützung. ... z.B. Intel SGX.

Ich vermute du meinst Trusted Execution Environment, worin die SW geschützt ausgeführt wird. Ich denke das weicht von Code Verschlüsselung ab, weil der Benutzer Zugriff auf die SW hat, drumherum aber der Schutzwall ist. Bei Code Verschlüsselung soll der Code vor dem Benutzer geschützt werden (anti reverse engineering). Aber guter Punkt - weil stimmt, das gibt es als Schutz auch noch.

@Tornhoof aaah einleuchtend, mit den Hooks vermeidet man, daß alles einsehbar rumliegen muss. Danke für die Ausführlichkeit !

Ergänzung zu MSIL:
Die meisten obfuscaten nur identifiers, also z.b. klassenname, methodenname usw.
Vollständige Verschlüsselung von MSIL funktioniert mit modernen .NET versionen (.NET Core+) nur bedingt

Ok. Allerdings kann .Net mittlerweile auch native Kompilate erzeugen (AOT).

Kannst du aber im Dump ist dann einfach nicht alles drin. Es ist ein steiniger Weg.

Und anders als bei Daten Ver/Entschlüsslung, kann man bei Code, auch immer anders machen (Obfuscation mit einem Recompiler etc.) so ist dann auch schwer fest zu stellen, was man schon hat, was noch fehlt. Es ist eben noch eine Stufe schwieriger als, wenn ein Programm einmal entschlüsselt dann komplett im RAM liegt.

Einverstanden, der Aufwand alles wieder zusammenzusetzen ist der Schutz. Plausibel.