Programm vor Disassemblern, Debugging schützen

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

Sqwan

!rr!rr_.

Schreib nicht bevor du probiert hast. Mach aus der a.out mal wieder ne lesbare datei und du siehst die klasse ist weg.

Und das ist bei eigentlich allen Compilern so. Das ist beim besten willen nichts neues. Die Optimieren noch viel viel mehr.

Da wird evtl. auch einfach nur schon zur Compilezeit erkannt was für ein Typ plop hat, da wird sich zur Laufzeit ja nicht viel ändern und vielleciht wurde es eben schon statisch reinkompiliert. Strings kann man natürlich einfach auslesen.

hustbaer

Sobald RTTI aktiviert ist, stehen bei einigen Compilern die Klassennamen im Binary, egal was für Optimierungen etc. man verwendet.

Debuggt mal in einen dynamic_cast rein. Bei MSVC ist man da relativ schnell bei strcmp() angelangt.

Funktions- oder Variablennamen sollte man allerdings halbwegs zuverlässig loswerden können, die werden ja nur für die Debug-Info verwendet. Und natürlich für Dinge ala assert(), damit man anzeigen kann in welchem File und evtl. welcher Funktion das assert() steht -- aber die sind bei Release Builds ja normalerweise auch nicht aktiv.

rapso

!rr!rr_. schrieb:

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?)

dead code stripping patentieren? kommt man da nicht ein wenig zu spaet wenn VC++ (mit /OPT:REF) und GCC (ich glaube mit --gc-section) das schon eingebaut haben?