![[HaBo]](/styles/default/logoklein.png){kind=small}
Ultimate CrackMe .net 2.0
- Themenstarter Mad0xx
- Beginndatum
Wie ganz normal in Plain Text oder musstest du es noch entschlüsseln?
Was mich auch noch ineteressieren würde ist, wie lange hast du dafür gebraucht und wie schwer fandest du es?
Gepackt war der Crack ja erst mit .net Reactor und dann noch Themida bzw. Winlicense.
Hast du diese Packer wieder entpackt oder einfach umgangen ... ?
Was mich auch noch ineteressieren würde ist, wie lange hast du dafür gebraucht und wie schwer fandest du es?
Gepackt war der Crack ja erst mit .net Reactor und dann noch Themida bzw. Winlicense.
Hast du diese Packer wieder entpackt oder einfach umgangen ... ?
Also läuft das so ab:
dass das Programm beim OK drücken
gleichzeitig das Passwort aus der dll (die mit xbundler ins Programm gebündelt wurde) entschlüsselt im speicher behält und mit der eingabe vergleicht.
Du hast also aus dem Speicher das Passwort ausgelesen und nicht aus der Exe?
Wie kann ich das laden in den Speicher denn verhindern?
Oder gibts ne andere Möglichkeit für das vergleichen?
Edit:
Wäre es denn besser die Eingabe zu verschlüsseln und mit dem Passwort zu vergleichen,
als das PAsswort zu entschlüsseln und mit der Eingabe zu vergleichen?
Gruß
@M4CH!N3
Das war pure Ironie^^
dass das Programm beim OK drücken
gleichzeitig das Passwort aus der dll (die mit xbundler ins Programm gebündelt wurde) entschlüsselt im speicher behält und mit der eingabe vergleicht.
Du hast also aus dem Speicher das Passwort ausgelesen und nicht aus der Exe?
Wie kann ich das laden in den Speicher denn verhindern?
Oder gibts ne andere Möglichkeit für das vergleichen?
Edit:
Wäre es denn besser die Eingabe zu verschlüsseln und mit dem Passwort zu vergleichen,
als das PAsswort zu entschlüsseln und mit der Eingabe zu vergleichen?
Gruß
@M4CH!N3
Das war pure Ironie^^
... war das hier wohl auch?
omg
Manchmal frage ich mich wirklich. Was kommt als nächstes? "Wie kann ich verhindern dass ein Programm in der CPU ausgeführt wird, damit niemand hinter die Serial kommt?"
Evtl. wären die Basics mal angebracht, danach kannst du immer noch super krasse crackmes erstellen
(bitte nicht allzu böse nehmen)Ne ist schon in Ordnung.
Programmieren ist nicht meine Stärke, was aber auch nicht heißen soll "Junge lass es lieber..."
Ich mach grade ein weiteres Update des Crackmes, wo das Passwort nicht in den Speicher geladen wird ( zumindest nicht als Plain)
Mal gucken ob es dann wieder in 4min zu knacken ist.
Programmieren ist nicht meine Stärke, was aber auch nicht heißen soll "Junge lass es lieber..."
Ich mach grade ein weiteres Update des Crackmes, wo das Passwort nicht in den Speicher geladen wird ( zumindest nicht als Plain)
Mal gucken ob es dann wieder in 4min zu knacken ist.
+++ATH0
0
Ich weiss gar nicht wie ich anfangen soll.
Deine Methode ist eigentlich kein richtiges "Sicherheitskonzept".
Bzw. kommt es drauf an WAS du genau schützen willst. Da fallen mir zwei Möglichkeiten ein:
A) Den Programmteil, der nach richtiger Passworteingabe ausgeführt werden soll. (Applikation)
B) Das Passwort selbst. (Information)
Angewendet auf beide Möglichkeiten hat dein Sicherheitskonzept leider komplett versagt.
Zumindest für Fall B) gibt es einige "realistisch unknackbare" Methoden, die mit einem Bruchteil der Komplexität auskommen, die dein Crackme innehat. Damit meine ich mathematisch als sicher befundene gängige Verschlüsselungsverfahren.
(Gibt es theoretisch auch für Fall A), sogar hausgemacht. Man nehme beliebige Software und packe sie in ein passwortgeschütztes und verschlüsseltes Archiv (rar, zip...)
Dass man sich darauf nicht verlassen kann ist klar. Hat der erste die Software gekauft und den Schlüssel erfahren, hindert ihn keiner daran ihn weiterzusagen oder besser die unverschlüsselte Software weiterzugeben, da man ihn anhand des Schlüssels, sollte er einmalig sein, ihn indentifizieren könnte.
Aber eigentlich kommt es bei Crackmes nie allein auf B) an. Denn unabhängig davon wie gut geschützt das Passwort / der Serial ist. Der Programmteil, der nach erfolgreicher Überprüfung ausgeführt werden soll ist komplett und ohne Umschweife zugänglich.
So vorzustellen:
Selbstbedienungskauf von Kartoffeln an einem Bauernhof. Die allermeisten bezahlen erst und bedienen sich an den Kartoffeln. Das Bezahlen kann man aber theoretisch komplett weglassen (umgehen).
So verhält es sich mit deinem Schutz. Eigentlich noch etwas schlimmer. Stell dir eine Club-Kneipe in der Seitengasse vor, die man durch mehrere Türen betreten kann. Alle Türen sind unbewacht ausser eine.
Bei dieser bestimmten Tür kommst du nur mit einem Passwort herein, dass du dem Türsteher durch das Schiebefenster in der Tür sagen musst. Sobald er das Schiebefenster öffnet, entdeckst du im Innenraum an der Wand ein Plakat auf dem das Passwort einfach so steht.
Du kommst also rein, weil du erstens das Passwort frei lesen kannst ( B) ) und weil es noch andere Zugänge gibt, die nicht geschützt sind ( A) ).
Nun. Ich hoffe ich habe dir den Mut nicht genommen.
Deine Methode ist eigentlich kein richtiges "Sicherheitskonzept".
Bzw. kommt es drauf an WAS du genau schützen willst. Da fallen mir zwei Möglichkeiten ein:
A) Den Programmteil, der nach richtiger Passworteingabe ausgeführt werden soll. (Applikation)
B) Das Passwort selbst. (Information)
Angewendet auf beide Möglichkeiten hat dein Sicherheitskonzept leider komplett versagt.
Zumindest für Fall B) gibt es einige "realistisch unknackbare" Methoden, die mit einem Bruchteil der Komplexität auskommen, die dein Crackme innehat. Damit meine ich mathematisch als sicher befundene gängige Verschlüsselungsverfahren.
(Gibt es theoretisch auch für Fall A), sogar hausgemacht. Man nehme beliebige Software und packe sie in ein passwortgeschütztes und verschlüsseltes Archiv (rar, zip...)
Dass man sich darauf nicht verlassen kann ist klar. Hat der erste die Software gekauft und den Schlüssel erfahren, hindert ihn keiner daran ihn weiterzusagen oder besser die unverschlüsselte Software weiterzugeben, da man ihn anhand des Schlüssels, sollte er einmalig sein, ihn indentifizieren könnte.
Aber eigentlich kommt es bei Crackmes nie allein auf B) an. Denn unabhängig davon wie gut geschützt das Passwort / der Serial ist. Der Programmteil, der nach erfolgreicher Überprüfung ausgeführt werden soll ist komplett und ohne Umschweife zugänglich.
So vorzustellen:
Selbstbedienungskauf von Kartoffeln an einem Bauernhof. Die allermeisten bezahlen erst und bedienen sich an den Kartoffeln. Das Bezahlen kann man aber theoretisch komplett weglassen (umgehen).
So verhält es sich mit deinem Schutz. Eigentlich noch etwas schlimmer. Stell dir eine Club-Kneipe in der Seitengasse vor, die man durch mehrere Türen betreten kann. Alle Türen sind unbewacht ausser eine.
Bei dieser bestimmten Tür kommst du nur mit einem Passwort herein, dass du dem Türsteher durch das Schiebefenster in der Tür sagen musst. Sobald er das Schiebefenster öffnet, entdeckst du im Innenraum an der Wand ein Plakat auf dem das Passwort einfach so steht.
Du kommst also rein, weil du erstens das Passwort frei lesen kannst ( B) ) und weil es noch andere Zugänge gibt, die nicht geschützt sind ( A) ).
Nun. Ich hoffe ich habe dir den Mut nicht genommen.
