Autor Beitrag
FinnO
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Beiträge: 1331
Erhaltene Danke: 123

Mac OSX, Arch
TypeScript (Webstorm), Kotlin, Clojure (IDEA), Golang (VSCode)
BeitragVerfasst: Mo 22.01.24 15:29 
Moin,

ich habe mal ein Thema, von dem ich hoffe, dass es hier in der EE gut beantwortet werden kann.

Ich muss für ein Projekt verschiedene .NET (8.0) Anwendungen und Bibliotheken obfuskieren, da die enthaltenen Algorithmen als schützenswert erachtet worden sind. Eine erste Sichtung der verfügbaren Obfuscation Tools hat mir zwar schon ein paar Ideen gegeben, welche davon ich einsetzen könnte, allerdings wäre ich insbesondere an aktueller Hands-On Erfahrung zur Code Obfuscation interessiert.

Wichtig für mich wäre eure (professionelle) Erfahrung mit:

- Eure Erfahrung mit potentiellen Problemen, die durch Obfuscation entstehen.
- Developer Experience des Toolings
- Integration in CI/CD (bei diesem Projekt wird Azure DevOps genutzt, aber alles was eine CLI hat, kriegen wir zum Laufen)
- Performance
- ggf. Support des Herstellers / Entwicklers

Auch andere Hinweise und Erfahrungsberichte oder Links zu solchen würden mich prinzipiell interessieren.

Grüße
Finn
Ralf Jansen
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 4701
Erhaltene Danke: 991


VS2010 Pro, VS2012 Pro, VS2013 Pro, VS2015 Pro, Delphi 7 Pro
BeitragVerfasst: Mo 22.01.24 16:18 
Erfahrung ist das bestimmte Dinge nicht einfach gehen und das ist leider abhängig vom eingesetzten Tool und man muß seinen Programmierstil dem im Grenzen anpassen.
Jedes Obfuscation Tool hat leicht anderes Verhalten jenseits vom üblichen und bekannten "Reflection geht nicht" und muß beachtet werden.

Auch muß man immer die Obfuscatierung kontrollieren sonst gehen einem Dinge durch. Zum Beispiel alles was public ist wird (aus offensichtlichen Gründen) meist nicht automatisch obfuskiert.
Heißt Sichtbarkeiten müßen genauer bedacht werden als sonst und regelmäßig per ILSpy-äquivalenten gecheckt werden ob die Obfuskierung auch wirklich gegriffen hat.
Also ständig kontrollieren und Sichtbarkeiten fixen bzw., was die meisten Tools tun, per Attributen das Verhalten des Obfukators je Klasse/Methode anpassen.

Punkt den man auf dem Schirm haben muß ist das man seine eigene Software ja auch irgendwie supporten will. Heißt der eigene Support wird irgendwann auf einen obfuskierten Stacktrace schauen. Wenn der irgendwie Sinn machen soll muß du denn deobfuskieren können. Das solltest du gezielt durchspielen und den Obfuskator deiner Wahl auf Herz und Nieren checken.
Ist jeder Build anders obfuskiert? Wenn ja wie bekomme ich anhand des Stacktraces raus welche "Version" das war um den richtigen Deobfuskator Schritt zu tun.

Was den Aufwand betrifft. Wenn irgendwie möglich halte die schützenswerten Assemblies am besten außer Reichweite von Usern (z.B. auf einem eigenen Server) und habe dann keinen Bedarf für Obfuskierung. Obfuskierung über die Lebenszeit einer Software zu pflegen ist Aufwand. Das was ich beobachtet habe ist das man mit guter Obfuskierung startet aber über die Zeit die immer schlechter wird (in dem Sinn das immer weniger Teile der Software sinnvoll obfuskiert sind). Aufwand heißt kosten und für Obfuskierung zahlen tun die wenigsten Auftraggeber.

Für diesen Beitrag haben gedankt: FinnO
FinnO Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Beiträge: 1331
Erhaltene Danke: 123

Mac OSX, Arch
TypeScript (Webstorm), Kotlin, Clojure (IDEA), Golang (VSCode)
BeitragVerfasst: Mo 22.01.24 16:53 
Moin Ralf, danke für deine ausführliche Antwort!

user profile iconRalf Jansen hat folgendes geschrieben Zum zitierten Posting springen:
Erfahrung ist das bestimmte Dinge nicht einfach gehen und das ist leider abhängig vom eingesetzten Tool und man muß seinen Programmierstil dem im Grenzen anpassen.
Jedes Obfuscation Tool hat leicht anderes Verhalten jenseits vom üblichen und bekannten "Reflection geht nicht" und muß beachtet werden.


Gibt es konkrete Tools, die du empfehlen bzw. nicht empfehlen kannst?

user profile iconRalf Jansen hat folgendes geschrieben Zum zitierten Posting springen:
Punkt den man auf dem Schirm haben muß ist das man seine eigene Software ja auch irgendwie supporten will. Heißt der eigene Support wird irgendwann auf einen obfuskierten Stacktrace schauen. Wenn der irgendwie Sinn machen soll muß du denn deobfuskieren können. Das solltest du gezielt durchspielen und den Obfuskator deiner Wahl auf Herz und Nieren checken.
Ist jeder Build anders obfuskiert? Wenn ja wie bekomme ich anhand des Stacktraces raus welche "Version" das war um den richtigen Deobfuskator Schritt zu tun.


Guter Punkt, danke dir!

user profile iconRalf Jansen hat folgendes geschrieben Zum zitierten Posting springen:
Was den Aufwand betrifft. Wenn irgendwie möglich halte die schützenswerten Assemblies am besten außer Reichweite von Usern (z.B. auf einem eigenen Server) und habe dann keinen Bedarf für Obfuskierung.


Diese Möglichkeit haben wir leider nicht, da die Software isoliert vom Internet laufen wird.


user profile iconRalf Jansen hat folgendes geschrieben Zum zitierten Posting springen:
Aufwand heißt kosten und für Obfuskierung zahlen tun die wenigsten Auftraggeber.


Das Problem haben wir gottseidank nicht :-)
Ralf Jansen
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 4701
Erhaltene Danke: 991


VS2010 Pro, VS2012 Pro, VS2013 Pro, VS2015 Pro, Delphi 7 Pro
BeitragVerfasst: Mo 22.01.24 19:00 
Zitat:
Gibt es konkrete Tools, die du empfehlen bzw. nicht empfehlen kannst?

Im Einsatz ist noch Babel Obfuscator. Der tut soweit was er soll.
Im Einsatz aber eher weil alle anderen Anbieter die ich mal zwischenzeitlich benutzt habe über die Lebenszeit der Software wo obfuskieren relevant war weggestorben sind.
Sozusagen ist Babel der Last Obfuskator Standing. Möglicherweise sind in der letzten Zeit neue Player aufgetaucht, die habe ich aber nicht auf dem Schirm.

Für diesen Beitrag haben gedankt: FinnO