PureBoard

Ein schwererer Ansatz (aber letztenendes auch crackbar) und ein paar Tipps:

Schreibe in PB einen eigenen Interpreter der Bytecode interpretiert *). In dieser Sprache hinterlegst Du in deinem Programm die Berechnung und Prüfung deiner Seriennummern (zB in Form von SHA256 Hashcodes). Der Hacker findet also den Bytecode deiner Scriptsprache, den er erstmal entschlüsseln muss. Dann muss er darin die passenden Stellen finden und das dann umgehen (Manipulation deines Scriptes). Das macht die Sache recht schwierig. Die Scriptsprache sollte aber nicht nur ein TRUE/FALSE liefern, denn das kann man mit jedem Debugger ganz einfach suchen und "umkehren". Es könnte auch sein, dass dein Programm eine "Magic Number" in irgend einem Algorithmus benötigt um korrekte Werte zu ergeben. Diese Magic-Number könnte das Ergebnis deiner Sicherheitsprüfung sein. Dann wird es echt hart, wenn man den korrekten Wert gar nicht kennt (zB Faktoren einer Grafikroutine oder einen wichtigen Multiplikator etc.).

Wichtig ist, dass Du nicht den Hash oder gar einen echten Key als String im Code hinterlegst. Du könntest den Hashcode in eine Zahl umwandeln (zB durch Addition des jeweiligen ASCII-Wertes + Zeichenposition) und dann diese Zahl hinterlegen. Das nötigt dem Hacker auch etwas mehr Anstrengungen ab. Oder den Hash wenigstens mit was anderem XOR codieren oder so...

Ein weiterer gemeiner Trick: Wenn Du im Programm den falschen Code entdeckst, erstmal so machen als wenn alles in Ordnung ist. Aber dann ein wenig später im Code einen Teil Quellcode ausführen der den Stack durcheinander bringt. Das hier schmiert erst ein paar Befehle später ab (auch im ASM-Debugger wie zB OllyDbg. InlineASM einschalten.): !Sub Esp,4 (muss am besten in einer Prozedur aufgerufen werden). Das verschiebt den Stack des Prozessors um 4 Byte. Wenn dann später irgend ein Code auf den Stack zugreift (oder Prozedur-Rücksprung), dann kracht es. Kann Hacker ganz schön ärgern, weil man die Stelle an der das gemacht wird nicht so einfach finden kann...

*) http://de.wikipedia.org/wiki/Bytecode und http://de.wikipedia.org/wiki/Interpreter

Kukulkan

[EDIT] Link zu dem Absturz-Thema aus 2007: http://www.purebasic.fr/german/viewtopi ... =3&t=14422 [/EDIT]

Ich habs jetzt selbst mal probiert, weils mich einfach gereizt hat :
Sollte doch nicht mehr sooo leicht zu knacken sein, reicht auf jeden Fall für Hobby-Projekte:

http://www.file-upload.net/download-332 ... 0.exe.html

Den Source veröffentliche ich in 1,2 Tagen. Bis dahin frohes knacken, Key auslesen ... ^^

Gruß, Alex

hab mich gestern abend, inspiriert von diesem thema, auch mal an ein crackme gewagt:

so leicht sollte es auch nicht zu knacken sein, hab aber weiter keine erfahrung auf dem gebiet^^

CRACKME!!!!!!!!!

Interessanter Ansatz, mit Debugger-Erkennung für Ollydbg ^^ Aber die hab ich schon überlistet

Mal sehen wie weit ich komme ...

Gruß, Alex

Interessanter Ansatz, mit Debugger-Erkennung für Ollydbg ^^ Aber die hab ich schon überlistet

ist auch nicht sonderlich schwer (debugger brauchts nicht, reicht ein hex-editor für ^^)

bei dir hab ich auch schon ne idee, aber leider noch kein funktionierendes resultat.
(will sie hier aber nicht verraten )

Da ich dieses sehr lieb gewonnene Thema durch euch, eröffnet habe, hier mein nächster Vorschlag meinerseits:

Variante A:

Die Executable komplett in den Speicher laden und von da aus ausführen, dadurch ist ein manipulieren nicht möglich ohne zwangsweise auf ein IMA zu stoßen, oder irre ich da?

Variante B:

Den kompletten auszuführenden Programmcode in eine DLL auslagern und beim execute nach und nach in den Speicher laden.
Dann würde nur der Teil durch die Executable laufen die gerade aufgerufen wird, der Rest steckt noch immer in der DLL.


Sind einer der Varianten erfolgreich nicht geknackt zu werden?
Wobei ich euch gern noch eine Zugabe geben möchte.

Variante C:
NICHT CRACKBAR !

Beim ausführen wird eine Datei mit einem bestimmten Schlüssel benötigt die nur jeweils für eine ID gültig ist (Ansatz meiner allerersten Unique File Key Methode von vor 3 Jahren)
Vorgang (Nicht mit Lösung des Inhalts der Datei aus dem Internet):

Software.exe
- Besitzt eine Select Abfrage welche verschiedene IDs durchläuft
- Jede Software hat so ihren eigenen Unique File Key !
Wie das zustande kommt?
Sagen wir mal, die ID steht als Datei-Detail (Token) oder mitten in der Executable, so wird beim aktivieren (Bei einer erfolgreichen UFK-Eingabe) eine Zugehörige File vom Server bezogen welche nur für diese ID gültig ist
- Durch das aktivieren des gültigen UFK, bekommt man die Datei in das Verzeichnis der Anwendung kopiert (Drin steht der unmöglich wissende Schlüssel der von der Executable auf Gültigkeit geprüft wird)
- Aushebeln durch Jump nicht möglich da die Abfrage NICHT NUR in der Executable steht, sondern auch außerhalb des Program-Verzeichnis


Kurz, welche Variante ist möglich und welche erachtet ihr als wirklich sinnvoll (Außer Program mit "guten/starken" Features auszubauen, was ich sowieso versuche so gut es geht auszubauen^^)


Viele Grüße

Renovatio

ich zitiere mal cxAlex:

Selbes Vorgehen wie zuvor. Mit ollydbg einfach den richtigen jump geändert

Gruß, Alex

dein code kann noch so klever erstellt sein, wenn die überprüfung/vergleich billig ist!!!!!
dein vergleich würde in ass in etwa so aussehen:
(etwas einfacher erklärt)

man-in-black hat geschrieben:ich zitiere mal cxAlex:

Selbes Vorgehen wie zuvor. Mit ollydbg einfach den richtigen jump geändert

Gruß, Alex

dein code kann noch so klever erstellt sein, wenn die überprüfung/vergleich billig ist!!!!!
dein vergleich würde in ass in etwa so aussehen:

Code: Alles auswählen

cmp eax,ebx         ;vergleich (dein code, benutzereingabe)
je FFFFFFFF         ;jump an eine bestimmte adresse (bei richtigem code zum fertig-fenster)

(etwas einfacher erklärt)

Ich sagte es schon, NICHT möglich.
Die Abfrage ist ebenfalls außerhalb des Programs hinterlegt worauf kein Hacker zugriff hat, da er diese Quelle nicht kennt.
Obgleich als Internet, als zweite Executable woanders (Dem Benutzer einem unbekanntem Verzeichnis - gibt in Win viele erlaubte z.B. AppData\... oder Temp \...)

Dann bringt die Executable selber auch nichts, wenn man sie versucht zu cracken.
Hierzu ein Beispiel eines sehr großen und bekannten Developer als auch Publisher:

Dieses Entwickler-Studio programmiert ihre Abfrage in die Windows-Registry oder auch mal in *.dat Dateien.

Noch etwas zum aushebeln: Wenn man aus einer IF eine IF NOT Abfrage macht, fügt das Wort "NOT" mehr Bytes dem Programm, also der Executable hinzu, wodurch man durch prüfen der Bytes eine Fälschung bzw. Manipulation herausfinden könnte.


Gruß

Renovatio

@Renovatio

Du verschwendest wirklich zu viele Gedanken an dieses Thema ...

Noch etwas zum aushebeln: Wenn man aus einer IF eine IF NOT Abfrage macht, fügt das Wort "NOT" mehr Bytes dem Programm, also der Executable hinzu, wodurch man durch prüfen der Bytes eine Fälschung bzw. Manipulation herausfinden könnte.

Man fügt nicht wirklich ein NOT hinzu, sonden ändert einfach den "Befehl" IF in IF NOT, das sind vereinfachtgesagt nur "Bytes" entweder 123 oder 124 (ausgedachte zahlen)

Natürlich kannst du mit Prüfsummen feststellen das die EXE verändert wurde, aber was sollte es bringen das zu wissen ?
Sobalt du irgendwo die aktuele Prüfsumme mit der "festen" Prüfsumme vergleichen MUSST, wird vom Hacker einfach diese Stelle in der EXE verändert, indem die Prüfsumme direkt verändert wird, wieder ein NOT oder sonst was ...

Wie schon mal erwähnt, du bist nicht der erste der sich über das Anti-Hacken gedanken macht, und ich bezweifel auch, das du (nur weil du denkst du hast viele Ideen die immer verstricker sind) einen "guten" Anti-Hack code entwickeln kannst.

Und irgendwelche Abfragen "nach außen" zu legen ist genau blödsinnig, schließlich interessieren den Hacker nicht alle einzelschritte, sondern nur der EINE der dafür sogt, ob das Programm läuft oder nicht.
Da kannst du noch so viele IFs verschachteln oder ANDs einbauen wie du willst, s bleibt eine "Stelle" an der entschieden wird, und die wird gehackt!

Nebenbei bringt das auslagern der Routinen in externe Dateien (DLL) zusätzliche Sicherheitslücken, z.B. Binary-Planting. Ich Analysiere einfach deine DLL und bilde die Funktionen nach und gebe einfach für jeden Schlüssel 'Ok' zurück.

Gruß Alex