Programm vor Disassemblern, Debugging schützen

um den Spaßfaktor einer Analyse noch etwas zu verringen, kann man noch:

* verwirrende Bezeichner einführen. Wichtig klingende Namen für völlig unwichtige Klassen, Hauptklassen dagegen mit kryptischen, selbstausgedachten Abkürzungen oder belanglosen namen belegen.

Wichtig: Der Name eines wichtigen Bezeichners darf nie auf die wahre Funktion hinweisen. Der Input-Buffer heißt "outputStack" usw

* Codeteile einbauen, die gar nicht benutzt werden. Trivialitäten mit Komplexität aufblasen und mehrfach wrappen.

* Code-Kommentare gelegentlich mit Lügen würzen

* Bezeichner mit leicht verwechselbaren Buchstaben wählen: o O 0 1 i I l | S $

Mehr Tips gibt's mit Suche nach: how to write unmaintainble code

Sqwan

Kommentare werden garnicht mitcompiliert und nicht verwendete Zeilen code machen
a) keinen Sinn, da leicht erkannt
b) können sie sehr schnell die performance behindern

Außerdem ist es für einen selbst nicht grade von vorteil das dingen so zu schreiben das man selbst nichts mehr von versteht.

Auch ähnliche Zeichen sind der totale Blödsinn. Ich guck mir so ein Programm doch nicht in Word mit irgend einer komischen schrift an.

In Eclipse oder auch VS gibt es wohl wenig probleme die Buchstaben zu unterscheiden...

EDIT: Nicht verwendeter code wird in der Regel wegoptimiert...

Sqwan schrieb:

nicht verwendete Zeilen code machen
a) keinen Sinn, da leicht erkannt
b) können sie sehr schnell die performance behindern

hängt von der Fantasie und den Fähigkeiten des Programmierers ab ...

Wenn man beispielsweise den Code eines gängigen Zufallsgenerators so frisiert, daß die Ausgaben stets ein gesetztes Bit 3 haben, und dann

if( zuf(x) & 8 ){
...
/* verwendet oder nicht? */
...
}

muß der Leser erstmal mathematisch dazu in der Lage sein, einen faulen
Zufallsgenerator zu erkennen.

Individuelle Obfuskation ist schon möglich, die Frage ist eher, ob es den Aufwand lohnt. Daß es sich lohnt, eine Klartext-Version zurückzubehalten, dürfte der Programmierer spätestens bei Eintreffen des ersten bugreports merken

Sqwan

Was hast du von einem faulen zufallsgenerator?
Und wie viele leute die einen code für wirtschaftliche Zwecke wieder herstellen, wie auch immer sie das machen, haben wohl das Hintergrundwissen so einen quatsch heraus zu finden...

SeppJ

!rr!rr_. schrieb:

um den Spaßfaktor einer Analyse noch etwas zu verringen, kann man noch:

* verwirrende Bezeichner einführen. Wichtig klingende Namen für völlig unwichtige Klassen, Hauptklassen dagegen mit kryptischen, selbstausgedachten Abkürzungen oder belanglosen namen belegen.

Bezeichner sind im Maschinencode nicht mehr vorhanden. Klassen sind im Maschinencode nicht mehr vorhanden. Hauptklassen sind im Maschinencode nicht mehr vorhanden.

* Codeteile einbauen, die gar nicht benutzt werden. Trivialitäten mit Komplexität aufblasen und mehrfach wrappen.

Unbenutzter Code ist (in der Regel) im Maschinencode nicht mehr vorhanden und selbst wenn einfach zu identifizieren.

* Code-Kommentare gelegentlich mit Lügen würzen

Kommentare sind im Mascinencode nicht mehr vorhanden.

* Bezeichner mit leicht verwechselbaren Buchstaben wählen: o O 0 1 i I l | S $

Bezeichner sind im Maschinencode nicht mehr vorhanden.

Mehr Tips gibt's mit Suche nach: how to write unmaintainble code

Du redest von einem ganz anderen Thema als (vermutlich) gefragt. Das hilft vielleicht um Java Code zu verschleiern, aber da der Threadersteller von Disassemblern und Decompilern spricht, wird das wohl nicht gemeint sein.

Sqwan

Kommentare sind sogar bei Java weg.
Auch der rest ist in Java blödsinn... Damit stellt man sich selbst ein Bein!

Erhard Henkes

Da reden die Einäugigen mit den Blinden.

hustbaer

@Erhard Henkes:
Das kannst du in vermutlich 80% der Beiträge hier schreiben, was macht diesen Thread so besonders

Sqwan

Nichts! Besonders wäre er erst gewesen, hätten die Erleuchteten ein brauchbares Satement abgegeben...

Bitte ein Bit

Als ich mein erstes Program mit dem IDA PRO Free mal angeschaut habe, habe ich nicht schlecht gestaunt was der zurückliefert. Der ist durchaus in der Lage kleinere Funktionen lesbar darzustellen.

Meine Tips beziehen sich mit C++ und WinAPI/MFC/... entwickelten Programme.

Verschleiere wichtige Funktionen mittels Code Obfuscation. Schaue dir diese mittels IDA Pro Free an, und versuche deinen Code soweit leserlich zu versauen dass das Debugging mit IDA Pro Free keinen Spaß macht. Nutze sinnlosen, aufgeblähten, redundanten, Inline Code um dein Program zu verschleiern. Code auf dem Stack gibt dabei Extrapunkte.

Prüfe ob ein Debugger in der Release Version läuft und ändere dein Programverhalten s.d. dieser scheinbar öfters abstürzt oder Werte falsch berechnet.

Denkbar wäre auch dass das Program die Integrität der eigenen Exe überprüft.

Las einfach deinen Spieltrieb freien Lauf, deinem Gegenüber das Reverse Engineering zu versauen

Quellen:
http://www.symantec.com/connect/articles/windows-anti-debug-reference
http://www.heise.de/security/artikel/Comic-ueber-Reverse-Engineering-270144.html
http://www.marx.com/ftp/pub/techdocs/manuals/CRYPTO-BOX/SmarxOS/SmarxOS_Compendium_de.pdf, Seite 297 Professioneller Softwareschutz

Sqwan

BiSt du einäugig oder blind?

Bitte ein Bit

Vermutlich blind.

Vielleicht habe ich aber auch nicht so die letzen Posting's verstanden. Also könntest du mir bitte mal erklären warum ich blind oder einäugig sein soll ???

Sqwan

Erhard Henkes schrieb:

Da reden die Einäugigen mit den Blinden.

Was weiß denn ich. Ich hab die Theorie nicht aufgestellt.

SeppJ

Sqwan schrieb:

Erhard Henkes schrieb:

Da reden die Einäugigen mit den Blinden.

Was weiß denn ich. Ich hab die Theorie nicht aufgestellt.

Es geht wohl darum, dass hier viele glauben, Sourcecodeobfuscation würde groß was am Maschinencode oder gar an der Rückübersetzung ändern. Damit macht man sich bloß selbst das Leben schwer, der Reverse Engineeer merkt davon aber noch nicht einmal was (außer man verwendet absichtlich obskure Algorithmen, aber es ging ja darum die guten Algorithmen zu schützen).

Grüße

Ein Einäugiger.

Sqwan

Joa. Aber was unterscheidet dann den Einäugigen vom Sehenden?
Wenn ich davon ausgehe, das die die sagen, "Verbau nicht unnötig code, bei der Rückübersetzung merkt man eh nichts davon", die Einäugigen sind.

hustbaer

SeppJ schrieb:

Sqwan schrieb:

Erhard Henkes schrieb:

Da reden die Einäugigen mit den Blinden.

Was weiß denn ich. Ich hab die Theorie nicht aufgestellt.

Es geht wohl darum, dass hier viele glauben, Sourcecodeobfuscation würde groß was am Maschinencode oder gar an der Rückübersetzung ändern.

Nur um das klarzustellen: ich meinte mit Obfuskatoren Programme die den fertigen Maschinencode verhunzen.

SeppJ

hustbaer schrieb:

Nur um das klarzustellen: ich meinte mit Obfuskatoren Programme die den fertigen Maschinencode verhunzen.

Ja, das hatte ich auch so verstanden. Ich bezog mich auf den Rest des Threads.

SeppJ schrieb:

Klassen sind im Maschinencode nicht mehr vorhanden. Hauptklassen sind im Maschinencode nicht mehr vorhanden.

aus dem Anfangsposting geht aber nicht hervor, daß es sich um Maschinencode handelt, nicht einmal, um welche Sprache.

Mit so allgemeinen behauptungen wäre ich - je nach Sprache, bytecode oder Binärformat - eher vorsichtig.

SeppJ schrieb:

Unbenutzter Code ist (in der Regel) im Maschinencode nicht mehr vorhanden und selbst wenn einfach zu identifizieren.

Da hast du aber einen sehr schlauen Compiler (patentiert?)

SeppJ schrieb:

Bezeichner sind im Maschinencode nicht mehr vorhanden.

s. Antwort 1)

SeppJ schrieb:

Du redest von einem ganz anderen Thema als (vermutlich) gefragt.

als ob das hier immer eine Rolle spielt Nein, im Ernst - ich kann deine Voraussetzungen nachvollziehen, wenn wir spezifisch von (sagen wir) C/C++ und Kompilaten in einem bestimmten Binärformat reden. Die Frage liest sich aber für mich allgemeiner.

SeppJ schrieb:

aber da der Threadersteller von Disassemblern und Decompilern spricht, wird das wohl nicht gemeint sein.

Die Bagger und die Compiler gibt es auch für Sprachen, die nach Bytecode kompilieren.

Bitte ein Bit

SeppJ schrieb:

Es geht wohl darum, dass hier viele glauben, Sourcecodeobfuscation würde groß was am Maschinencode oder gar an der Rückübersetzung ändern. Damit macht man sich bloß selbst das Leben schwer, der Reverse Engineeer merkt davon aber noch nicht einmal was (außer man verwendet absichtlich obskure Algorithmen, aber es ging ja darum die guten Algorithmen zu schützen).

Die Idee schützenswerte Algorithmen mittels Obfuscation zu schützen, finde ich auch ein wenig übertrieben. Denn erstens geht das Ganze im kompletten Maschinencode unter und zweitens sind die meisten Algorithmen schon so kompliziert genug das man froh ist wenn man einen leicht lesbaren fehlerfreien Code hat. Und viele Algorithmen findet man eh veröffentlicht im Netz (CiteSeer und Co). Also warum schützen ?

Wenn sich jemand den Spaß macht und einen Algorithmus aus einem Wust von Maschinencode extrahiert, dann lasse ihn. Das ist schlichtweg nur eins: Arbeitsbeschaffungsmaßnahme vom Feinsten für den Reverse Engineerer. Ich möchte mal jemand sehen der das Rebalancieren eine B-Baumes aus einem Disassembly zieht.

Etwas anderes ist es aber wenn man Kopierschutz-Funktionen beschützen möchte. Dann würde ich die von mir genannten Dinge in den Code bringen.

ach, übrigens - selbst wenn wir es auf C++ einschränken:

wenn ich das da: ...

#include<typeinfo>
using namespace std;
class flupp { };
int main(){
  flupp plop;
  typeid(plop).name(); }

... bei mir kompiliere, dann gibt mir das da ...

strings a.out | grep flupp

... den String

5flupp

aus. Soviel zum Thema "Klassen kommen in der ausführbaren Datei nicht vor". Potzblitz