Ich nutze momentan den Obfuscator "CONFUSER" und Ich wollte mal fragen, ob Confuser auf Stufe "Maximum" oder "Aggressiv" wenichsdens etwas Schutz bietet und das Dekompilieren erschwert.

Nein.

Also wenn Ich ein Programm dekompilieren würde und auf folgendes stoßen würde hatte Ich aber erst mal Probleme es zu verstehen..
溙儺ῌ䃸ꪴ漞꩑ၴ.쒈梱駈�ퟟⱓ늨⑄(this.皊⊐嫰䗅혾꽴魌, 峮齏嬴乕棕蝝ꤐ);

100% Sicher ist eh nix.. Und Dekompilieren ist 100% auch nicht sehr schwer.. Aber sofort die Strings auslesen geht aber damit nicht und das Dekompilieren ist aufwendiger.

und nun schau dir mal den gesamten Quellcode an und suche nach genau dieser Stelle. Obfuskatoren verschlechtern die menschliche lesbarkeit, aber wer sich auch damit auseinandersetzt kommt irgendwann zum ziel.

Dagegen gibt es reihenweise Deobfuscator. Wer Deinen QuellCode sehen will, der wird ihn sehen können. Es bietet keinen Schutz, egal was Du machst.

EDIT: Vor allem Strings lassen sich wunderbar entschlüsseln. Wenn Dein Vorhaben ist, Zugangsdaten in den QuellCode zu schreiben => vergiss es.

Das es nicht zu 100% Sicher ist ist mir bewusst, aber es erschwert zumindest das Dekompilieren bzw. macht es aufwendiger. Und als "Täter" würde Ich jedenfalls die Lust verlieren mich damit auseinander zu setzen wenn Ich auch sowas stoße.

Es macht es nicht aufwendiger. Ich lad mir den Deobfuscator runter, entschlüssle Dein Programm und klaue Deine Zugangsdaten. Zeitaufwand: < 1 Minute. Vergiss es, dass irgendwelche Sachen Deinen QuellCode schützen.

@timchen100:: Überlege Dir, ob Dein Programm tatsächlich geschützt werden muss.
Du kannst es verschlüsseln und über einen Dongle starten, das ist sehr sicher, aber teuer.
Du kannst aber die schützenswerten Teile Deines Codes in eine C++-DLL auslagern oder diese als Lib an eine CLR-DLL als Wrapper hängen.
Dann hast Du eine (öffentliche) Exe und eine sehr gut geschützte DLL.

Hört sich Interessant an, könntest du mir vielleicht kurz beschreiben wie Ich z.b. Zugangsdaten in einer DLL auslagern könnte?

timchen100 schrieb:

Zugangsdaten

nein, denn das DLL-Interface ist ja .NET und kann abgefragt werden
oder
es ist C, dann kann es deobfo-dingst werden.
Dieses Herangehen ist zum Schutz von Algorithmen.
----
Schreib erst mal, was Du schützen willst.

RodFromGermany schrieb:

u kannst aber die schützenswerten Teile Deines Codes in eine C++-DLL auslagern oder diese als Lib an eine CLR-DLL als Wrapper hängen.

Wie das geht wollte ich wissen..

Das bringt dir auch nichts. Auch in C-Libraries können Strings einfach ausgelesen werden und auch wenn die Zugangsdaten angenommen gut Verschlüsseln könntest. So ist die Schwachstelle die Einbindung in dein Programm, denn du musst die Library einbinden und Aufrufen damit sie dir die Zugangsdaten gibt (die stehen dann z.B. auch im Speicher und könnten da ausgelesen werden) aber eben jeder andere könnte ebenfalls die DLL in ein Projekt einbinden und die Funktion aufrufen die die Zugangsdaten zurück gibt.

Hmm.. Und wie kannte ich sie dann etwas sicherer ins Programm einbauen? Muss ja nicht 100% sicher sein.. Nur dass man sie nicht auf den ersten Blick findet.

Aha.

1. Projektmappe anlegen
   
2. Hauptprogramm: .NET-Exe (egal, was für eine Sprache)
   
3. ein CLR-DLL-Projekt hinzufügen (das ist eine Managed C++-DLL, also voll .NET-kompatibel und obfuskierbar)
   
4. ein natives C++-Projekt hinzufügen
   
5. die Output-LIB des nativen C++-Projektes dem CLR-Projekt als Referenz hinzufügen
   
6. den Code ausfüllen
   

Diese Herangehensweise hat den Vorteil, dass es nur eine DLL gibt, in der der managed und der unmanaged C++-Code drin sind.
Man kann auch in ein CLR-Projekt direkt unmanaged Code reinschreiben, aber der ist so wiederum lesbar.

Auch das Auslagern in native Libraries bringt herzlich wenig. Der einzige Unterschied ist, dass man ein anderes Tool verwendet, um sie auseinander zu nehmen. Diese können mittlerweile relativ gut lesbaren C-Pseudocode aus nativen Assemblys erzeugen. Man benötigt noch etwas Hintrtgrundwissen, aber einen Algorithmus damit zu "schützen" bringt einem genauso weit wie .NET.

Von Confuser ist abzuraten: Er bietet genauso viel "Schutz" wie alle anderen Obfuscator (keinen), sorgt aber dafür, dass viele AVs anschlagen, obwohl das Programm nichts böses macht.

Da man davon ausgehen kann, dass man bei sowas immer verloren hat, wenn die Assembly auf einem Rechner landet, der nicht der eigene ist, verfolge ich die Phisolophie, es einfach open source zu machen. Mittlerweile sehe ich kein Problem mehr darin, wenn sich jemand meinen Code anschaut und sich diesen als Beispiel nimmt. Bei mir kommt außerdem noch dazu, dass ich mich nicht mit meinem Code blamieren will und dadurch alles sauberer implementiere.
Ich vertrete deshalb die Meinung, dass wenn etwas sicher ist, es das auch ist, wenn es quelloffen wäre (private Schlüssel einer PKI natürlich ausgenommen).

timchen100 schrieb:

Hmm.. Und wie kannte ich sie dann etwas sicherer ins Programm einbauen? Muss ja nicht 100% sicher sein.. Nur dass man sie nicht auf den ersten Blick findet.

Gar nicht, Zugangsdaten gehören niemals in den Code!

Gar nicht ... erkläre was du vor hast, gibt vlt. andere Möglichkeiten das Problem zu lösen als die Zugangsdaten in das Programm zu packen. Willst du z.B. mit einer SQL Datenbank kommunizieren wird das nicht mit externem Zugriff gemacht sondern du Kommunizierst nur einem Interface (bsp. PHP Script) welches die Daten entgegen nimmt und in die DB einträgt oder ausließt.

Wenne ne native Dll durchn Disassembler jagts, bekommst du den kompletten Quellcode wieder (in Assembler). Der kann auch wieder in C umgewandelt werden, aber lesbar ist das ganz sicher nicht, bringt den Angreifer aber zum Ziel. Sicher sind nur sichere Verfahren, da muss und kann man nicht an der PE rumbasteln