[HaBo]

the_uxreal

Anzeige

Hallo Leute,

wie der Titel schon sagt möchte ich Anwendungen möglichst sicher vor Crackern machen. Ich hab schon einen Thread erstellt, wo auch ein Teil der fragen beantwortet werden, jedoch nur der Schutz vor Dekompilieren Schutz vor dekompilieren von C#-Anwendungen bzw. von .NET .
Einer meine Fragen sind beispielsweise:

• Wie kann ich mich davor schützen, dass man Strings nicht aus dem Arbeitsspeicher auslesen kann?
• Wie kann man sich vor dem lesen von Assembler-Code schützen? Falls es möglich ist.
• Welche Sprache ist am "sichersten"?

Was gibt es für Möglichkeiten sich davor zu schützen bzw. gibts Tricks o.ä.? Ideen oder Vorschläge sind auch erwünscht.

the_uxreal

01

http://www.s-a-ve.de/faq/Anti-Cracking-Tips-1.txt
http://en.wikibooks.org/wiki/Reverse_Engineering
tsehp.cjb.net
cip-re.6x.to
reteam.org
reverse-engineering.net
reversing.be
absolutelock.de
exetools.com

1. Strings nicht direkt ablegen sondern erst zur Laufzeit zusammenbauen/dekodieren indem z.B. jeder Character wieder +1 den richtigen ergibt

2.Es gibt ein paar Codebrocken an denen sich die gängigen Disassembler/Debugger verschlucken bzw. die diese erkennen.

3.ASM denn da siehst du was du machst Eigentlich alles was nicht sehr gebräuchlich ist und wo die Disassembler nicht die Links zu den API Calls auflösen können

Ich will dir jetzt nicht den Spass verderben und es ist für Coder sehr gut sich mit Cracken bzw. Reversing zu beschäftigen aber du wirst deine Software nicht schützen können so eine gew. Verbreitung erreicht wurde. Ich würde die Zeit lieber in Verbesserungen investieren so dass mehr Leute sich darüber freuen und dich unterstützen wollen.

Generell, lass die Finger von Packern/Unpackern/Obfuscators machen Ärger und es gibt genügend 1-Klick Entpacker. Sei so wenig standard wie möglich, nutze in den kritischen Routinen nicht die Standart Funktionen sondern mache viel per Hand -> Sinn muss man durch tracen erst erschließen -> Zeit+Frust. Baue viel Müll ein. Gib harte Demoversionen raus also die die Funktionalität nicht enthalten (und auch nicht nachrüstbar sind).

All dass wird dich aber nicht vor einer Armee hochtallentierter Cracker retten die zur Höchstform auflaufen wenn es darum geht als erster dein Tool als Release rauszugeben

Elderan

Hallo,
@01 zu 3:
ASM ist vermutlich einer der 'unsichersten' Sprachen.

Egal in welcher Sprache man sein Programm schreibt, in die Maschinensprache kann man es zurückübersetzen. Bei manchen geht sogar der Transfer in die Hochsprache, z.B. Java oder C#/.Net, da hier nicht direkt Assembler genutzt wird sondern eine Zwischensprache.


Ansonsten kann man jede Sprache, die direkt ausführbare Programme erstellt, in Assembler zurückübersetzen. ASM ist da besonders unsicher, da man, wenn man den ASM Code selber noch verstehen will, ihn sauber schreiben muss, was dem Angreifer zugute kommt.
Ansonsten bist du mit C/C++ gut beraten, evt., wenn du gcc nutzt, noch Optimierung (-O3) einstellen.
Ansonsten gibts diverse Tools, die das reversee engineering erschweren, indem sie den Code unübersichtlich machen.

sw33tlull4by

Was du auchnoch machen koenntest waeren Codebloecke die nur dem Schutz des Programmes dienen aber im Programm selbst keinen zweck erfuellen.
z.B. wird in C alles so angelegt wie du es schreibst.
Also koenntst du folgendes machen:

c = random%255
int wasauchimmer[c];
-<wichtiger codebereich>-

Dadurch wandert der Codebereich immer durch den Stack, was einen Angriff mittels z.b:Exploitstrings schwierig macht.

Heinzelotto

das ist nicht möglich, da die größe eines arrays immer schon zur compilezeit bekannt sein muss. Eben aus dem grund, weil es nicht möglich ist, dass der codebereich im stack herumwandert.
Man könnte zwar int* c = new int[rand()]; machen, aber dann würde lediglich der pointer im stack abgelegt werden, der speicher würde im heap alloziiert werden.

sw33tlull4by

Verdammt.
Hast recht.
Sollte mal wieder ein bischen mehr Programmieren
Aber es geht definitiv mit malloc,
dann soltle man aber noch den Speicher freigeben also einen Pointer auf dem Begin von malloc bereithalten, und dann
free mallocpointer
mfg

sw33t

Heinzelotto

meinst du so?

damit würde der wichtige codeblock aber nur um die größe eines pointers verschoben werden. Dieser Pointer zeigt dann auf irgendeinen abschnitt im speicher, den malloc vom OS zugeteilt bekomen hat. Dieser Abschnitt wird sich aber nicht vor den "<<codeblock>>" schieben.

sw33tlull4by

stimmt, allociert ja ganz woanders im speicher.
k
ich hab genung meiner,in einem Jahr gewachsensn unwissenheit weiter die bloesse zu geben.

waerst du vielleicht so freundlich mir einen Wink mit dem Zaunpfahl zu geben wie man das programmiert?
jetzt komplett ohne irgendwelche speziell dafuer vorgesehenen libaries?
mfg

sw33t