Entwickler-Ecke
Open Source Units - Passwort abfrage.
detke - Mo 22.05.06 13:41
Titel: Passwort abfrage.
Hi,
hier mal eine Passwort abfrage in Delphi geschrieben.
Warscheinlich kommt noch eine Version mit Benutzernam raus, aber da warten wir mal ab.
Edit: habe die Daten anhänge entfernt da ihr sie ja schlecht findet.
Gruss Detlef
Delete - Mo 22.05.06 14:10
Das ist jetzt nicht dein Ernst oder? Was hat das für ein Wert? So eine einfache if-Abfrage dürfte jeder hinbekommen, wohl schon ein Anfänger nach fünf Minuten. Zu dem steht das Passort hardgecodet in der Exe. Ich habe es mal gecrackt. Eventuell findest du ja das neu Passort raus.
JayEff - Mo 22.05.06 14:10
Ähm tut mir leid, dass ich darüber herziehe, aber ... was bitte soll das?!
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7: 8:
| procedure TForm1.Button1Click(Sender: TObject); begin if edit1.text = 'ihr Passwort' then begin end else begin
end; |
Das ist das einzige, das du selbst geschrieben hast. Der Rest erzeugt Delphi ja selbst.. Dann eine Form2, auf der steht: (Ein Label) "Hier dann ihr Unit statt dieser Unit ihre Unit einfügen". Gut gedeutscht! Aber sorry, wenn ich eine Passwortabfrage will, dann muss das Passwort verschlüsselt gespeichert sein, und zwar am besten gehasht. und selbst wenn ich mir ein Programm schreiben müsste, in dem das vorkommt, wären diese 30 Sekunden Programmieren (Ich hab ne md5 Unit die ich einbinden kann) niemals Wert, ein Grundgerüst dafür als Open Source Unit(!) ins DF zu stellen... Nix für ungut aber .... xD
detke - Mo 22.05.06 14:13
müsst ihr mich jetzt so in den dreck stellen?
Und wie haste es gecrackt?
JayEff - Mo 22.05.06 14:19
Mit einem Hexeditor vermutlich... es geht aber auch mit notepad. Ich versuch grad sein PW rauszufinden ... hm ... *grml* hast du da irgent was dran gemacht? verschlüsselt oder so? *grml*
Gausi - Mo 22.05.06 14:25
Nach einer kleinen Pause ist das Thema nun wieder offen. Bitte bleibt bei der Kritik sachlich und freundlich. :D
detke - Mo 22.05.06 18:21
Hi,
wie wäre es wenn wir zusammen die Passwort abfrage verbessern?
Gruss Detlef
JayEff - Mo 22.05.06 22:04
Mal abgesehen davon, dass du nicht die Worte eines Mods 1:1 kopieren solltest....... ( ;> )
Naja, man sollte auf jeden fall das Passwort nicht unverschlüsselt speichern, denn wie du gesehen hast, war es kein Probelm für Luckie, dein Programm zu cracken, und btw, die Lösung für Luckies Programm ist "crak". ich habs selbst rausgefunden. Einfach per Hex-editor. Der Trick bei so einem Programm: HASH. Ein sog. Hash ist eine Zahl die sich aus einer Zeichenkette errechnen lässt. Es ist beinahe unmöglich, vom Hash auf die Zeichenkette zu kommen, aber die Zeichenkette in einen Hash zu verwandeln ist einfach. Das heist: Speichere in deinem Programm den Hash des Passworts und errechne bei der Passworteingabe den Hash des eingegebenen Passworts. Wenn beide Hashs übereinstimmen, hat der Benutzer das richtige Passwort eingegeben, ansonsten nicht.
Der Sinn der ganzen Sache ist mir zwar nicht ganz klar, aber mit dieser Änderung kannst du eine ziemlich sichere Passwortabfrage erzeugen. Das ganze ist eine gute Übung und vielleicht brauchst du ja irgentwann genau sowas.
Um an Informationen über den Hash ran zu kommen, empfehle ich
http://www.wikipedia.de und die Entwickler-Ecke-Suche. (Ganz zu schweigen von Google.)
Ach ja und ...: Nix für ungut, was meine Äußerungen von vorher betrifft ;>
elundril - Di 23.05.06 21:29
ich wollt nur sagen:
Lass dich nicht entmutigen detke!! jeder hat mal klein angefangen!! und wenn die anderen deine Unit nicht brauchen dann vielleicht ja du!!! also immer weiter programmieren!!
F34r0fTh3D4rk - Mi 24.05.06 18:07
dem hash braucht man auch keine beachtung schenken, einfach aus dem = ein <> gemacht und fertig ist der lack ;)
bzw lässt sich auch glaube ich die stelle des MOV einfach noppen
JayEff - Mi 24.05.06 19:28
Danke für deinen Beitrag, FotD, nur wäre es nicht einfacher, es GLEICH so zu schreiben, dass es Normalsterbliche verstehen? :shock: ^^ Bitte nochmal, und wenns nur für mich ist ^^ Ich hab kein Wort verstanden. Wieso dem Hash keine beachtung schenken, wieso welches = in ein <> verwandeln? HÄ? -.-
Born-to-Frag - Mi 24.05.06 19:34
Damit man in einem Hex-Editor das Passwort nicht mehr so einfach auslesen kann ;)
JayEff - Mi 24.05.06 19:39
statt if pw='hallo' then schreibe ich if not (pw<>'hallo') then und schon ist mein Passwort nicht mehr hardgecoded? aha! toll! WARUM?!
F34r0fTh3D4rk - Mi 24.05.06 20:04
nein wenn man den vergleich crackt, dann ist es egal wie gut die verschlüsselung ist, du musst nur ein falsches passwort finden und du hast zugriff
Delete - Mi 24.05.06 20:06
Hi Leute.
JayEff hat folgendes geschrieben: |
statt if pw='hallo' then schreibe ich if not (pw<>'hallo') then und schon ist mein Passwort nicht mehr hardgecoded? aha! toll! WARUM?! |
Natürlich ist es noch hardgecoded. Er meinte nur, wenn er mit dem Hex-Editor im
fertigen Programm aus einem
if pw = 'hallo' then ein
if pw <> 'hallo' then macht, dann ist die Passwortabfrage
futsch!
Edit: Wups... Ich sollte öfters refreshen... :oops:
JayEff - Do 25.05.06 13:33
Achso, jetzt hab ichs gebkickt ... *grml* ok, und? wie verhindere ich das? Denn das is ja das Thema: Wie mach ich die Abfrage sicherer?
F34r0fTh3D4rk - Do 25.05.06 14:02
tja das ist die zentrale frage, du kannst den cracker mit wuselcode verwirren, aber es wird nie unmöglich sein
Jakob Schöttl - Do 25.05.06 14:13
WArum macht ihr nicht das mit dem Hash?
Das ist doch nicht soo schwer:
Eine klassische Einwegfunktion ist z. B. f(x) = (m^x) mod 256;
bzw. f := power(m,x) mod 256;, wobei m = 33 sein könnte...
Die funktion liefert einen Byte, den kannst du dann auch als char in einen string schreiben. Das musst du natürlich schon machen, bevor du das Programm compilierst.
Und Die Benutzereingabe wird genauso umgerechnet und dann mit dem Hashwert verglichen.
so brauchst du den cracker mit wuselcode gar nicht irritieren!
... und so wird es im prinzip bei den windowspasswörtern auch gemacht.
Ich hoffe ich hab nichts falsch verstanden
F34r0fTh3D4rk - Do 25.05.06 14:32
geht trotzdem genauso zu cracken, einfach <> und irgendnen dreck eingeben und fertig ist das ding, am ende ist es ja doch:
Delphi-Quelltext
1:
| if Hash(Code) = Hash then |
JayEff - Do 25.05.06 14:32
Du hast da was falsch verstanden. Ich hab den Hash bereits in meinem ersten Beitrag erwähnt, nur wurde ich davon überzeugt, dass das die sicherheit nur minimal erhöht: Der Cracker macht nichts weiter, als in der fertigen Exedatei per Assembler aus dem if x=y vergleich einen if x<>y Vergleich, und schon braucht er nur ein FALSCHES Passwort eingeben, um an den Zugriff zu kommen! Folglich bringt der Hash nix.
/edit: ach mist. klar sind die, die weniger schreiben, schneller als ich -.- *grmbl*
Sebi82 - Mi 31.05.06 10:19
Hi!
Es gibt noch eine Möglichkeit, die Schwachstelle JE (Jump if equal) in JNE (Jump if not equal) zu umgehen: Man sollte den Hash des Passworts einfach in viele Stellen des Codes mit einbinden. Bespiel: Wert:=andererWert * (HASHeingabe/HASHvorgabe) .Bei korrekter Eingabe passiert nichts. Dies soll nur ein anschauliches Beispiel sein.
Mir ist natürlich bewusst, dass damit eine *versehentliche* Falscheingabe des Passworts das Programm zunichte macht, aber ich bin mir sicher, dass man da auch irgendeine moderate Lösung findet! Hab nur gerade keine Zeit darüber nachzudenken...
JayEff - Mi 31.05.06 12:09
Hm klingt gut...! Wie wärs damit:
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7:
| i:=2*(hashEingabe div hashKorrekt); try (FindComponent('Form'+IntToStr(i)) as TForm2).Show; Form1.Hide; except Showmessage('Falsches Passwort!'); end; |
Is das ein Ansatz oder hat das die gleiche Schwachstelle?
Hack Gott - Mi 31.05.06 13:17
Ich hab mich mal kurz hingesetzt und auch einen kleinen Passwortdialog zusammen geschustert, schaut mal ob ihr des passwort ändern, oder zumindestens knacken könnt.
Ich bin gespannt.
rizla - Mi 31.05.06 14:07
Wie lame ist das denn? Aus dem "je" ein "jmp" zu machen,, um den Hash zu umgehen?
oh oh :wink:
rizla - Mi 31.05.06 14:15
I8N zum letzten crackme ;)
cuejo - Mi 31.05.06 15:59
Gibt es denn eine Möglichkeit einen Vergleich von zwei Werten - sei es nun simpler Text, ein Hash oder was auch immer - so zu gestalten, dass ein cracker nicht mehr diese anscheinend doch sehr simple Methode (= durch <> ersetzten) benutzen kann? Ich weiß, dass man keine Passwortabfrage wirklich 100%ig sicher machen kann, aber wenn ich sehe, dass ihr diese Programme alle gecrackt habt, dann gibt mir das doch zu denken.
rizla - Mi 31.05.06 16:33
Alles was auf Softwarebasis gelöst wird, wird auch auf Softwarebasis ausgehebelt. Punkt!
Das Problem ist ja, dass Du immer etwas vergleichen musst, also kann ich das
// asm
cmp realserial, fakeserial
je registration_complete
//
immer patchen (unelegant, wie ich immer noch finde)..
Sollte es so eine Lösung geben, dann.. *NEIN* gibts nicht. Wie gesagt - Punkt! Aus!
:mahn:
:wink:
rgs rizla
Jakob Schöttl - Mi 31.05.06 17:10
Ach jetzt hab ichs verstanden
o_o Das ist ja fies!
Aber ziemlich unwarscheinlich, dass es jemand schafft.
rizla - Mi 31.05.06 17:13
Aber ziemlich unwahrscheinlich das jemand was schafft?? :?!?:
Horschdware - Mi 31.05.06 17:33
man muss es dem cracker halt wie gesagt insofern schwer machen, dass er sich zum einen durch spaghetticode durchwühlen muss und zum anderen mehrfach auf die passwortabfrage trifft. d.h. im programm gibt der benutzer einmal das passwort ein und das programm prüft das ganze dann an mehreren stellen ab.
man kann das ganze nicht verhindern - aber man kann es schön schwer und umständlich machen
rizla - Mi 31.05.06 20:55
Ja sicher, das ist schon nicht so einfach, es dem cracker schwer zu machen, außer man nimmt zum proggen visual basic :mrgreen:
ich sag mal so: beim crackme von Hack Gott wars in etwa so:
1. ollydb öffnen,
2. alle referenced strings anschauen,
3. doppelklick auf "falsch",
4. den call davor tracen,
5. irgendwann mal auf edx achten
6. et voila - passwort da!
ne sache von 1 minute.
*sorry* hack gott, aber es reversern schwer zu machen, ist schwer.
ist halt keine 5 minuten sache.
eine andere sache wäre, softice und olly gar nicht erst zuzulassen.
aber dann gibts auch wieder patches, ist halt wie gesagt - alles software.
ich finde, die diskussion führt ins leere, die frage ist eher, kann man gute freeware schreiben.
Ein indianischer Spruch dreht sich irgendwie so:
der rote Mann ist reich, wenn er geschenke machen kann,
der weiße Mann, wenn er anhäufen kann.
Ich weiß, wir leben nicht im Lande der Apachen und auch nicht im Sozialismus,
aber wenn man kreativ und begabt ist, sollte man andere Leute daran teilhaben lassen, so seh ich das.
:rizla:
JayEff - Fr 02.06.06 00:03
Letzte möglichkeit: Verschlüssle das komplette Programm und mach daraus eine "Selbstextrahierende" Datei, soll heissen: Man gibt den Schlüssel ein, und das Programm wird entschlüsselt, ganz gleich, ob der Schlüssel richtig oder falsch ist. Problem dabei ist das Verschlüsselungsverfahren... Möglich sind natürlich sowohl symetrische als auch asymetrische... ein Onetimepad-style kommt nicht in Frage, darum sind wohl die asymetrischen interessanter ... naja... da können sich dann die Kryptographen austoben. Ich glaube mich zu erinnern, dass es hier mal ein Freeware prog gab, das jede beliebige Exedatei verschlüsselte und beim starten wurde ein Passwort dialog angezeigt.... *hmm...*
rizla - Fr 02.06.06 09:18
Vorsicht :mahn:
JayEff hat folgendes geschrieben: |
Man gibt den Schlüssel ein, und das Programm wird entschlüsselt, ganz gleich, ob der Schlüssel richtig oder falsch ist. Problem dabei ist das Verschlüsselungsverfahren... |
Das Problem liegt hierbei ganz woanders: Wird das Programm mit dem falschen Schlüssel decodiert und ausgeführt, kann das unter Umständen ziemlich böse Folgen haben (u.U. dass man sich den Rechner zerschrottet!). Der Code, der dann nämlich im Speicher ist, kann ja sonst was tun (auch wenn es durch den falschen Schlüssel scheinbar nur Müll ist, irgendwas macht die *sinnlose* copefolge schon *g*). Ich hatte das mal, als ich vor etlichen Jahren mit Assembler angefangen hab - ich habs abschließende int20 resp. 4c@21 :wink: vergessen, das programm hat auch schön "hello world" ausgegeben, aber leider auch gleich 's bios zerschossen. :?
:rizla:
JayEff - Fr 02.06.06 16:36
Pech für den Cracker, der versucht hat, das Programm zu öffnen... 8(
Naja.. Muss man halt noch nen Passwort bestätigen Dialog einfügen. :/
rizla - Fr 02.06.06 21:34
JayEff hat folgendes geschrieben: |
Pech für den Cracker, der versucht hat, das Programm zu öffnen... |
Und Pech für den User, der sich vertippt hat! :nut:
Born-to-Frag - Fr 02.06.06 21:58
Aber so macht es doch z.B. WinRAR: Man gibt ein Passwort ein, es wird extrahiert und danach wird die CRC-Summe mit der verglichen die in dem Archiv angegeben wird. Und dann gibt es erst eine Meldung aus "wrong password?".
Nervt echt bei großen Archiven :D
rizla - Fr 02.06.06 22:16
ja, kann man ja machen. aber dann muss auch eine crc routine rein - aber davon wurde bis jetzt noch nicht gesprochen ;)
so, muss nun feiern
schönes we allen
:rizla:
JayEff - Sa 03.06.06 16:58
rizla hat folgendes geschrieben: |
JayEff hat folgendes geschrieben: | Pech für den Cracker, der versucht hat, das Programm zu öffnen... |
Und Pech für den User, der sich vertippt hat! :nut: |
Der user vertippt sich 2 mal? :roll:
moddin - Sa 10.06.06 00:51
Lösungsansätze :
Zeiger und Zeigervergleiche anstatt if (lstrcmp etc)
und diese Prüfvorgange tausendmal (nicht als proceduraufruf
sondern im quelltext direkt 1000 mal :lol: )
CRC selbstcheck ob verändert wurde
Edit : Ach ja Compileroptimierungen ausschalten,Die 1000Zeilen Procedur immer mit sinnlosen
if bedingungen (erzeugen immer "jmp"s) füllen
NAhc leute ;-)
root_at_localhost - Sa 10.06.06 01:11
Man kann ja auch bei Start des Programms das PW überprüfen und wenn falsch aussteigen. Später im Programm prüft man noch ein paar mal, wenn das Programm nicht modifiziert wurde is das dann immer OK, aber PW-Testroutinen zu finden, die das Programm nach 10-15 Minuten Betrieb, bei Speichern von Dokumenten, etc. mit einer nichtssagenden Access-Violation abstürzen lassen is doch schon unangenehmer...
BenBE - Sa 10.06.06 01:21
Lasst doch einfach über den Prüfroutinen Code nen brauchbaren Obfuscator drüberlaufen ... Weiterhin mitten im Programm als Code-Blöcke die CRCs verstecken Back-Referenz-JMP-SHORTs einbinden, die Cross-Procedure Inter-Instruction die Proceduren anspringen ... (Ist aber leider nur für die Schutzroutinen machbar, da ansonstn das gesamte Programm ASM sein müsste) ...
Also in der Art: Wenn man eine Routine anspringt an Label A wird Pi berechnet, springt man sie dagegen an Labelö B an, wird e berechnet und wenn man sie an Label C anspringt und das richtige PW angegeben hat, erzeugt der Source dieser Procedure einen SMC-Block im RAM, der den Anwendungssource im RAM entpackt ... Ach ja: Mit entsprechend vielen asm DB $CC ends dazwischen, schön vielen Quersprüngen in der Routine und auch sonst dem besten C-Style (Spaghetti-Source mit Unlesbarkeitsgarantie) und man sollte bei Release-Zyklen von 14 Tagen, die jeweils nominale Enhancements enthalten, keine Probleme mehr mit Crackern haben ;-)
Ach ja: Die korrekte Prüfsumme des Serials ist dabei in dem SMC-Block so unterzubringen, dass eine Falscheingabe die Ausführung des MOV CR0, EAX-Befehls hervorruft oder per SSDT-Hook ein Bluescreen on Demand (gibt's echt!!! Ist ein Feature von Windows!!!) initiiert wird ;-)
Lassen wir also der kreativen Ader kurz freien Lauf und sehen dann: Noch schöner wird das ganze, wenn man sich Techniken aus der Demo-Szene zu nutze macht, und nicht die eigentlichen Programmdaten speichert, sondern die Aufbau-Vorschrift um die gewünschte Datenfolge zu generieren ... Heißt: Wenn man in 3D nen Würfel darstellen will, speichert man nicht die 8 Eckpunkte, sondern eine Vorschrift, wie man diese 8 Eckpunkte erhält ;-)
Naja, die Liste ist fortsetzbar :P Wichtig ist nur, dass jegliche Sources selbstmodifizierend und vom PW bzw. dessen Prüfsumme abhängig sein müssen ... Eine Verteilung der Aufrufe für die Prüf-Codes auf möglichst viele Stellen ist ratsam *g*
root_at_localhost - Sa 10.06.06 01:29
BenBE hat folgendes geschrieben: |
... dass eine Falscheingabe die Ausführung des MOV CR0, EAX-Befehls hervorruft oder per SSDT-Hook ein Bluescreen on Demand (gibt's echt!!! Ist ein Feature von Windows!!!) initiiert wird ;-) |
Das interessiert mich jetzt, was bewirkt MOV CR0, EAX und was ist ein BSOD on Demand, bzw. wie und wozu generiert man sowas??
BenBE - Sa 10.06.06 01:37
root_at_localhost hat folgendes geschrieben: |
BenBE hat folgendes geschrieben: | ... dass eine Falscheingabe die Ausführung des MOV CR0, EAX-Befehls hervorruft oder per SSDT-Hook ein Bluescreen on Demand (gibt's echt!!! Ist ein Feature von Windows!!!) initiiert wird ;-) |
Das interessiert mich jetzt, was bewirkt MOV CR0, EAX und was ist ein BSOD on Demand, bzw. wie und wozu generiert man sowas?? |
MOV CR0, EAX wird genutzt, um zwischen Real Mode und Protected Mode hin und Herzuschalten ... Die Erwähnung von SSDT-Hooks an dieser Stelle ist notwendig, da dieser Befehl nur auf Ring0 (Kernel-Modus unter Windows) ausgeführt werden kann.
@BSOD on Demand: Zum Testen von Treibern unter Windows, kann man über die Registry eine Tasten-Kombination (IIRC Strg+Alt+Break\Break) aktivieren, die dafür sorgt, dass Windows einen Bluescreen auslöst ... Damit kann man bei Treibern die Fehlerbehandlung testen ... (Ich glaub, M$ hat dieses Feature nie selbst genutzt ...)
root_at_localhost - Sa 10.06.06 23:28
Danke für die Infos, wieder was gelernt...
Hack Gott - Fr 07.07.06 16:04
HÄHÄ
Ich hab ne neue Idee. Schauts euch doch mal an, ich denke das hier zu knacken ist ein Ding der unmöglichkeit (denke/hoffe ich zumindestens).
Hack Gott - Fr 07.07.06 16:08
Achja, für die jenigen dis unbedingt schaffen wollen startet es einfach mit dem paramenter schwach 8) dann werden die punkte falls sie richtig sind markiert.
Wenns richtig ist öffnet sich ein fenster mit dem inhalt korrekt.
Delete - Fr 07.07.06 16:17
Zwei mal kreisen.
BenBE - Fr 07.07.06 16:17
Vom Grundprinzip ne nette Idee, je nach Umsetzung aber sicherlich im Bereich von ner halben Stunde machbar ...
Hack Gott - Fr 07.07.06 16:29
BenBE hat folgendes geschrieben: |
Vom Grundprinzip ne nette Idee, je nach Umsetzung aber sicherlich im Bereich von ner halben Stunde machbar ... |
Stimmt, aber das kann man ja um sehr viele weitere Punkte ergänzen, ich überprüfe bis jetzt nur 4. Und umso mehr, umso komlizierter wird es ja. Und knacken kann man es ja nicht mehr auf die herkömmliche weise.
root_at_localhost - Fr 07.07.06 16:34
eben, was hindert mich daran per programm einfach jeden punkt abzufahren?
uall@ogc - Fr 07.07.06 16:57
Oder was hindert mich daran es zu cracken?
LLCoolDave - Fr 07.07.06 16:59
Is ja völlig umsonst, da wackelt man bischen mit der Maus drüber und fertig...
Hack Gott - Fr 07.07.06 17:00
root_at_localhost hat folgendes geschrieben: |
eben, was hindert mich daran per programm einfach jeden punkt abzufahren? |
kann man ja eine kleine sperre einbauen, das es nach ca. 200 (oder mehr) punkten die falsch waren zurücksetzt.
uall@ogc hat folgendes geschrieben: |
Oder was hindert mich daran es zu cracken? |
Verdammt, ist die selbe schwachstelle wie oben, nachdenken bevor posten! (ist an mich gerichtet)
rizla - Fr 07.07.06 19:47
grüße an HG,
ich dachte, das thema wäre durch :gruebel:
.:rizla:.
Locke - Do 20.07.06 12:29
Hack Gott hat folgendes geschrieben: |
Ich hab mich mal kurz hingesetzt und auch einen kleinen Passwortdialog zusammen geschustert, schaut mal ob ihr des passwort ändern, oder zumindestens knacken könnt.
Ich bin gespannt. |
Passwort: Gut!
Benötigte Zeit: nicht mehr als 10 Sekunden :P
Also ich denke nicht das jemand eine unknackbare Passwortabfrage hinkriegt, zumahl es nicht mal die Software Firmen wie z.B. Adobe, Steinberg, etc. schaffen. Wird immer wieder geknackt ;)
mfg Locke
azubi_20 - Do 20.07.06 13:42
Ich hab hier auch mal ne recht simple Passwortabfrage gebastelt.
Wer kann mir am schnellsten das Passwort sagen ? :-)
Wenn's geklappt hat gibts ne entsprechende Meldung, sonst passiert nix.
PS: Mit welchen Werkzeugen arbeitet ihr so um zu Cracken (Hexeditoren, ResEditoren...)?
azubi_20 - Fr 21.07.06 10:32
10 mal runtergeladen und keiner hats geschafft ?
Scheint wohl doch nicht so einfach zu sein. :wink:
Also nochmal : Wer stellt sich der Herausforderung ? :lupe:
BenBE - Fr 21.07.06 12:11
Die Frage bei sowas ist weniger "Wie lautet das Passwort?", sondern "kommt man auch ohne an's Ziel?" ;-)
azubi_20 - Fr 21.07.06 12:40
ok, dann formulieren wir das mal um :
wer schafft es die Paswortabfrage zu umgehen ?
Chryzler - Sa 22.07.06 17:19
Das Passwort hab ich noch nicht, aber ich glaube ich weiß was kommt, wenn man's weiß:
"Du hast es geknackt."
EDIT: und irgendwas mit "C:\allPasswords.txt" war noch drin...
uall@ogc - Sa 22.07.06 17:53
Bei
00457227 74 0A JE SHORT Project1.00457233
noppen. 34 Sekunden.
GTA-Place - Sa 22.07.06 20:07
Mh... Wie findest du das immer so schnell? Hatte das nach Minuten noch net - und dann keine Lust mehr ;-). Da der Jump auf einen XOR-Befehl geht: Kann es sein, dass du nach XOR geguckt hast? Bitte erklären.
BenBE - Sa 22.07.06 21:49
Eigentlich simpel:
OllyDbg starten --> String-Index der Datei öffnen --> Doppelklicken auf oben erwähnte Meldung --> Haltepunkt setzten --> Aufrufenden Source-Rahmen suchen --> Bedingten Jump-Befehl aufspüren ...
Mit ein wenig Übung und dem richtigen Blick ohne Probleme in der Zeit machbar ...
GTA-Place - So 23.07.06 10:52
OllyDbg starten --> Das schaff ich noch ^^.
String-Index der Datei öffnen --> Ich denke du meinst "all referenced strings" - ok.
Doppelklicken auf oben erwähnte Meldung --> Auch noch gut.
Haltepunkt setzten --> Ja, klappt auch noch.
Aufrufenden Source-Rahmen suchen --> Was soll ich suchen? o_O Und wie? ^^
uall@ogc - So 23.07.06 12:42
Also bis dahin isses schonmal klar. Aus den vorherigen Posts konnte ich halt sehen, dass es so ne Meldung gibt.
BP an den Beginn (PUSH EBP) und mal was eingeben und Button klicken -> der breakt dann sogar. Also bis dahin richtig.
Dann wird üblicherweise nach TEST EAX, EAX bzw TEST AL, AL gesucht. gibts da auch, den jmp danach abgeändert (je nachdem ob er mit falschem Passwort springen will oder nicht) und geschaut -> hat funktioniert.
Ansonsten müsste man halt schauen was genau gemacht wird (Text aus dem Edit ausgelesen, nach Dateien gesucht mit FindFirstFile usw.)
Aber dafür war das Programm einfach zu einfach zum cracken.
Chryzler - So 23.07.06 12:46
Das Passwort haben wir immernoch nicht :(
Es kommen zwar so Sachen wie "so gehts" oder "geheimes Passwort" vor, aber die Beiden gehen nicht.
GTA-Place - So 23.07.06 12:51
Hey, danke. Das war ja wirklich relativ einfach.
@Chryzler: Für was brauch ich ein Passwort, wenn ich das auch umgehen kann?
JayEff - So 23.07.06 12:58
Wooooow Leute das is ja SOWAS von Offtopic xD Dashier ist "Open Source Units" !! ^^
GTA-Place - So 23.07.06 13:05
Ja - und wir versuchen die Unit besser zu machen, in dem wir lernen, wie man ne Passwort-Umfrage umgeht.
JayEff - So 23.07.06 13:40
Alles klar - Dann fehlen hier aber links zu ollydbg, denn sowas braucht man ja, um "mit zu spielen" ...? Ausserdem wärs doch interessant, zu wissen, wie man die Assembler Befehle auszuwerten hat.. ich mein ich kenne JMP und TEST und sowas... Ihr versteht was ich meine :D Ich schreib auch mal kurz eine PW abfrage ... moment.. so ...
uall@ogc - So 23.07.06 15:17
Adresse in
Quelltext
1: 2:
| 00450F1C FEC2 INC DL 00450F1E 90 NOP |
abändern.
JayEff - So 23.07.06 15:24
Äh .. HÄ? Erklär mal bissl genauer ... Dass ihr da schnell drauf kommt dacht ich mir, aber würd trotzdem gern wissen, wie du das gemacht hast x_X
uall@ogc - So 23.07.06 15:37
selbe wie oben nur diesmal der String
00450F12 |. BA 5C0F4500 MOV EDX,Project1.00450F5C ; ASCII "44721f5b3b0424f095529d6005646e55"
GTA-Place - So 23.07.06 16:25
Was bedeutet "SETE DL"? Das steht bei mir an der angegebenen Stelle.
uall@ogc - So 23.07.06 16:59
SETE DL = set byte on condition, set byte if equal (zerobit) (DL = lower part of EDX)
setzt also DL auf 1 wenn zerobit = 1, also DL := ZeroBit (wenn ich mich jetzt richtig erinnere)
Deshalb auch INC EDX/DL, damit DL gesetzt wird weils vorher eben 0 ist.
http://faydoc.tripod.com/cpu/sete.htm
BenBE - So 23.07.06 17:36
Bin selbst auch grad dabei, eine kleine Idee umzusetzen ;-) Muss nur noch einen Bug beheben ;-) Wird sicherlich noch die Tage werden, dass Ihr euch mal üben dürft ;-)
mattl - Do 03.08.06 13:06
So... Hab auch mal eine pw abfrage zusammengeschrieben
wer das pw herausfindet bzw. es umgehen kann darf mir dan erklären wie er es gemacht hat :lol:
Chryzler - Do 03.08.06 14:11
Bei 00457048 und 00456063 noppen 8)
- Wieder alle Strings in der EXE angesehen
- "Richtig" herausgesucht und doppelgeklickt
- Davor die beiden JNZ's genoppt
- Fertig
mattl - Do 03.08.06 14:34
wie öffnest du die exe?
Chryzler - Do 03.08.06 14:36
mit OllyDbg
Marc. - Do 03.08.06 14:40
sag mal, schließt sich dein programm bei richtigem passwort? :roll:
Ist das richtige passwort "=::=::" ?
Chryzler - Do 03.08.06 14:43
Das Programm schließt sich IMMER wenn man 6 Zeichen eingibt :wink:
Marc. - Do 03.08.06 14:44
:oops: Gut zu wissen..
mattl - Do 03.08.06 14:53
so hab mir ollydbg besorgt nur wie das jetzt mit den strings suchen usw. funzt kapier ich nicht
Chryzler - Do 03.08.06 15:02
1. OllyDbg öffnen
2. In OllyDbg deine EXE öffnen
3. Rechter Mausklick im CPU Fenster -> Search for -> all referenced text strings
4. 'Richtig' im neuen Fenster suchen und doppelklicken
5. Im CPU Fenster müsste jetzt eine MOV Anweisung markiert sein. Du gehst jetzt Anweisung für Anweisung immer weiter nach oben, bis du auf eine JNZ Anweisung kommst. Bei der dann rechtsklicken -> Binary -> Fill with NOPs. Das ganze wiederholst du bis du auf eine zweite JNZ Anweisung kommst, bei der du das gleiche machst.
6. Oben in der Symbolleiste auf den Start-Button klicken oder F9 drücken
TIPP: Wenn du die beiden JNZ's nicht findest schaust du einfach, dass ganz links von der Zeile 00457048 bzw. 00456063 steht.
mattl - Do 03.08.06 15:10
ok thx hat sofort funktioniert
Chryzler - Do 03.08.06 15:13
Weiß jemand, wie man den gecrackten Assemblercode auch wieder zu einer EXE macht? Brauch ich dafür einen extra Assembler, oder geht das auch in OllyDbg?
BenBE - Do 03.08.06 15:30
Haste direkt in OllyDbg eine Funktion im Kontextmenü, um deine Änderungen in eine EXE zu schreiben ... Schau dort einfach mal. Ansonsten im Patch-Fenster mal das Kontextmenü.
Chryzler - Do 03.08.06 15:40
THX habs gefunden: Rechtsklick -> Copy to executable -> All modifications
mattl - Do 03.08.06 16:05
So hab jetzt noch ein paar änderungen vorgenommen
möchte wissen ob ihr das jetzt auch cracked
sry hab edit mit zitat verwechselt deswegen der nächste beitrag
mattl - Do 03.08.06 16:06
.
GTA-Place - Do 03.08.06 20:43
Ist die Zugriffsverletzung geplant?
mattl - Do 03.08.06 22:14
upps das ist keine absicht da hat sich noch wo ein fehler eingeschlichen
JayEff - Do 03.08.06 22:58
das ist ne ERROR_CLASS_DOES_NOT_EXIST (00000583) oder?
bei 0040350B . 8B10 MOV EDX,DWORD PTR DS:[EAX]
gibts dann ne ERROR_SUCCESS (00000000) oder? x_X Zumindest interpretiere ich ollydbg so ... Kenn mich damit nicht aus ^^
Chryzler - Fr 04.08.06 08:36
mattl hat folgendes geschrieben: |
upps das ist keine absicht da hat sich noch wo ein fehler eingeschlichen |
Hab ich mir doch gedacht.
Chryzler hat folgendes geschrieben: |
Das Programm schließt sich IMMER wenn man 6 Zeichen eingibt :wink: |
Ist das auch ein Fehler oder ist das Absicht?
mattl - Fr 04.08.06 08:45
das ist eigentlich absicht hat aber eigentlich keinen sinn
eruhenon - Do 30.11.06 19:41
wie wärs wenn ihr das programm nach nem schluessel einfach verschluesseln würdet und anstelle eines pw vergleichs einfach den teil des programms verschlüsselt. Dann bräuchtet ihr den schluessel für den algorithmus um den passwortbereich zu betreten...
wies realisiert wird einen bereich unverschluesselt und den anderen verschluesselt zu habn weiss ich zwar grad nich aber es gibt hier mit sicherheit ideen.
mfg
Jan
azubi_20 - Do 30.11.06 20:07
Titel: Lösung für mein prog
ach ja, falls sich jemand dafür interessiert :
mein Programm im Beitrag vom 20.07.06 12:42 (Seite 3 dieses threads) ist folgendermaßen zur erfolgreichen weiterführung zu bringen :
im Edit-Feld dreimal [ESC]-Taste drücken, dann auf Button bestätigen. (und zwar nur so)
die "tricks", die das knacken schwieriger machen :
- die Tastaturschläge werden mitprotokolliert
-> bei einem Eingabe-Fehler muss das Programm neugestartet werden
- kein Vergleich mit dem Editfeld
- Phantom-Funktionen und "offensichtliche" Strings, die aber nichts mit der eigentlichen Abfrage zu tun haben
- viele unnötige Sprünge
- Vergleich von Key-Konstanten und nicht von Strings
- zusammengesetzte Vergleichsbedingungen mit verteilten Funktionen
- nicht sinnhafte "Benamung" von Variablen und Funktionen
Quellcode habe ich leider nicht mehr...
Marc. - Do 30.11.06 20:11
Ich habe damals für dein Programm keine Minute gebraucht, azubi ;)
azubi_20 - Do 30.11.06 20:18
@ marc : bist ja auch ein Profi :wink:
ne, ich hab von Assembler kein Plan, meine aber mal gelesen zu haben, dass früher einige Shareware-Autoren versucht haben, ihre Software mit solchen Tricks schwieriger knackbar zu machen.
jaenicke - Do 30.11.06 20:55
Tja, klar wurde das verwendet. Aber erstens sind diese Methoden auch bekannt und man merkt dann oft, wenn es sich um einen Trick handelt. Und zweitens sind auch die Debugger besser geworden...
azubi_20 - Do 30.11.06 23:09
ja, habe mir schon gedacht, dass das nicht mehr aktuell ist, aber manchmal bin ich halt etwas nostalgisch :lol:
Chryzler - Sa 02.12.06 18:45
eruhenon hat folgendes geschrieben: |
wie wärs wenn ihr das programm nach nem schluessel einfach verschluesseln würdet und anstelle eines pw vergleichs einfach den teil des programms verschlüsselt. Dann bräuchtet ihr den schluessel für den algorithmus um den passwortbereich zu betreten...
wies realisiert wird einen bereich unverschluesselt und den anderen verschluesselt zu habn weiss ich zwar grad nich aber es gibt hier mit sicherheit ideen.
mfg
Jan |
Dann versucht doch mal, dieses kleine Progrämmchen zu cracken...
EDIT:
Hinweis: Wenn das Passwort richtig ist, kommt eine entsprechende ShowMessage.
F34r0fTh3D4rk - Sa 02.12.06 20:30
genau, das programm entschlüsselt den teil von sich selbst, der für die abfrage zuständig ist, das würde die sache knifflig machen, wäre auch sicher nicht leicht umzusetzen.
Chryzler - Sa 02.12.06 20:34
F34r0fTh3D4rk hat folgendes geschrieben: |
genau, das programm entschlüsselt den teil von sich selbst, der für die abfrage zuständig ist, das würde die sache knifflig machen, wäre auch sicher nicht leicht umzusetzen. |
Ich habe eine einfache XOR-Verschlüsselung eingesetzt. Wenn man aber zum Beispiel Blowfish mit SHA1-Hash nimmt, dürfte es fast unmöglich werden, den verschlüsselten Code ohne Passwort zu bekommen. Da ist dir was tolles eingefallen,
eruhenon ;)
jaenicke - Sa 02.12.06 20:37
Chryzler hat folgendes geschrieben: |
Ich habe eine einfache XOR-Verschlüsselung eingesetzt. |
Ich sehs, ich mach mich gerade über deinen Code her:
Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34: 35: 36: 37: 38: 39: 40: 41: 42: 43: 44: 45: 46: 47: 48: 49: 50: 51: 52: 53: 54: 55: 56: 57: 58: 59: 60: 61: 62: 63: 64: 65: 66: 67: 68: 69: 70: 71: 72: 73: 74: 75: 76: 77: 78: 79: 80: 81: 82: 83: 84: 85: 86: 87: 88: 89: 90: 91: 92: 93: 94: 95: 96: 97: 98: 99: 100: 101: 102: 103: 104: 105: 106: 107: 108: 109: 110: 111: 112: 113: 114: 115: 116: 117: 118: 119: 120: 121: 122: 123: 124: 125: 126: 127: 128: 129: 130: 131: 132: 133: 134: 135: 136: 137: 138: 139: 140: 141: 142: 143: 144: 145: 146: 147: 148: 149: 150: 151: 152: 153: 154: 155: 156: 157: 158: 159: 160: 161: 162: 163: 164: 165: 166: 167: 168: 169: 170: 171: 172: 173: 174: 175: 176: 177: 178: 179: 180: 181: 182: 183: 184: 185: 186: 187: 188: 189: 190:
| (* 00456EF4 55 push ebp 00456EF5 8BEC mov ebp, esp 00456EF7 83C484 add esp, -$7C 00456EFA 53 push ebx 00456EFB 56 push esi 00456EFC 57 push edi 00456EFD 33C9 xor ecx, ecx 00456EFF 894D84 mov [ebp-$7C], ecx 00456F02 894D88 mov [ebp-$78], ecx 00456F05 894D8C mov [ebp-$74], ecx 00456F08 894D90 mov [ebp-$70], ecx 00456F0B 8BF0 mov esi, eax 00456F0D 33C0 xor eax, eax 00456F0F 55 push ebp
* Possible String Reference to: 'éÏÈúÿëë_^[‹å]Ã' | 00456F10 6834704500 push $00457034
***** TRY | 00456F15 64FF30 push dword ptr fs:[eax] 00456F18 648920 mov fs:[eax], esp 00456F1B C6459400 mov byte ptr [ebp-$6C], $00 00456F1F 8D5590 lea edx, [ebp-$70]
* Reference to control TForm1.Edit1 : TEdit | 00456F22 8B8634030000 mov eax, [esi+$0334]
| 00456F28 E837CDFDFF call 00433C64 00456F2D 8B4590 mov eax, [ebp-$70]
| 00456F30 E883D2FAFF call 004041B8 00456F35 8BF8 mov edi, eax 00456F37 85FF test edi, edi 00456F39 7E22 jle 00456F5D 00456F3B BB01000000 mov ebx, $00000001 00456F40 8D558C lea edx, [ebp-$74]
* Reference to control TForm1.Edit1 : TEdit | 00456F43 8B8634030000 mov eax, [esi+$0334]
| 00456F49 E816CDFDFF call 00433C64 00456F4E 8B458C mov eax, [ebp-$74] 00456F51 0FB64418FF movzx eax, byte ptr [eax+ebx-$01] 00456F56 304594 xor [ebp-$6C], al 00456F59 43 inc ebx 00456F5A 4F dec edi 00456F5B 75E3 jnz 00456F40 00456F5D 807D9429 cmp byte ptr [ebp-$6C], $29 00456F61 0F85A8000000 jnz 0045700F
* Reference to: kernel32.GetCurrentProcessId() | 00456F67 E830F0FAFF call 00405F9C 00456F6C 50 push eax 00456F6D 6A00 push $00 00456F6F 68FF0F1F00 push $001F0FFF
* Reference to: kernel32.OpenProcess() | 00456F74 E81BF1FAFF call 00406094 00456F79 8945FC mov [ebp-$04], eax 00456F7C 8D45F8 lea eax, [ebp-$08] 00456F7F 50 push eax 00456F80 6A64 push $64 00456F82 8D4594 lea eax, [ebp-$6C] 00456F85 50 push eax 00456F86 6890704500 push $00457090 00456F8B 8B45FC mov eax, [ebp-$04] 00456F8E 50 push eax
* Reference to: kernel32.ReadProcessMemory() | 00456F8F E810F1FAFF call 004060A4 00456F94 33DB xor ebx, ebx 00456F96 8D7D94 lea edi, [ebp-$6C] 00456F99 8D5588 lea edx, [ebp-$78]
* Reference to control TForm1.Edit1 : TEdit | 00456F9C 8B8634030000 mov eax, [esi+$0334]
| 00456FA2 E8BDCCFDFF call 00433C64 00456FA7 8B4588 mov eax, [ebp-$78]
| 00456FAA E809D2FAFF call 004041B8 00456FAF 50 push eax 00456FB0 8BC3 mov eax, ebx 00456FB2 5A pop edx 00456FB3 8BCA mov ecx, edx 00456FB5 99 cdq 00456FB6 F7F9 idiv ecx 00456FB8 52 push edx 00456FB9 8D5584 lea edx, [ebp-$7C]
* Reference to control TForm1.Edit1 : TEdit | 00456FBC 8B8634030000 mov eax, [esi+$0334]
| 00456FC2 E89DCCFDFF call 00433C64 00456FC7 8B4584 mov eax, [ebp-$7C] 00456FCA 5A pop edx 00456FCB 0FB60410 movzx eax, byte ptr [eax+edx] 00456FCF 3007 xor [edi], al 00456FD1 43 inc ebx 00456FD2 47 inc edi 00456FD3 83FB64 cmp ebx, +$64 00456FD6 75C1 jnz 00456F99 00456FD8 8D45F8 lea eax, [ebp-$08] 00456FDB 50 push eax 00456FDC 6A64 push $64 00456FDE 8D4594 lea eax, [ebp-$6C] 00456FE1 50 push eax 00456FE2 6890704500 push $00457090 00456FE7 8B45FC mov eax, [ebp-$04] 00456FEA 50 push eax
* Reference to: kernel32.WriteProcessMemory() | 00456FEB E814F1FAFF call 00406104 00456FF0 8B45FC mov eax, [ebp-$04] 00456FF3 50 push eax
* Reference to: kernel32.CloseHandle() | 00456FF4 E833EFFAFF call 00405F2C 00456FF9 B894AB4500 mov eax, $0045AB94
* Possible String Reference to: 'Vgoh%bhfl++Nxz!>1z|c5r~|9cti=zp' | 00456FFE BA4C704500 mov edx, $0045704C
| 00457003 E844CFFAFF call 00403F4C
| 00457008 E883000000 call 00457090 0045700D EB0A jmp 00457019
* Possible String Reference to: 'Wrong password!' | 0045700F B880704500 mov eax, $00457080
* Reference to : TMessageForm._PROC_0042DEDC() | 00457014 E8C36EFDFF call 0042DEDC 00457019 33C0 xor eax, eax 0045701B 5A pop edx 0045701C 59 pop ecx 0045701D 59 pop ecx 0045701E 648910 mov fs:[eax], edx
****** FINALLY |
* Possible String Reference to: '_^[‹å]Ã' | 00457021 683B704500 push $0045703B 00457026 8D4584 lea eax, [ebp-$7C] 00457029 BA04000000 mov edx, $00000004
| 0045702E E8E9CEFAFF call 00403F1C 00457033 C3 ret
| 00457034 E9CFC8FAFF jmp 00403908 00457039 EBEB jmp 00457026
****** END | 0045703B 5F pop edi 0045703C 5E pop esi 0045703D 5B pop ebx 0045703E 8BE5 mov esp, ebp 00457040 5D pop ebp 00457041 C3 ret
*) |
F34r0fTh3D4rk - Sa 02.12.06 21:02
stimmt man kann auch einfach die passwort abfrage durch eine entschlüsselung des relevanten codes ersetzen, so muss man das passwort eingeben.
mfg
Chryzler - Sa 02.12.06 21:06
Man kann auch einfach (so würde ich es machen) den verschlüsselten Teil entschlüsseln, in der EXE überschreiben, und dann nen JMP vor der internen Entschlüsselungsroutine setzen.
eruhenon - Mo 04.12.06 21:58
@Chryzler thx
nur mal als frage da wir uns ja in opensource units befinden wie haste das denn realisiert?
hab nämlich keinen ansatz wie ich die theorie in die praxis umsetzten kann.
jaenicke - Mo 04.12.06 22:04
Naja, also das mit in der Exe überschreiben ist nicht möglich. Ansonsten wäre das schon machbar. Code in den Speicher entschlüsseln und dann in Assembler dorthin jumpen. Das probier ich mal aus...
Aber ist ziemlich kompliziert... Mal sehen, ob ich das hinbekomme.
rizla - Mo 04.12.06 22:33
@Chryzler:
hmm.. sehr verdächtig: wenn ich als PW ")" (klammer zu) eingebe, wird in deinem crkme ein check als positiv bewertet und dein crkme beginnt, code zu entschlüsseln, der dann auch ausgeführt wird. bis jetzt läuft mein rechner noch, aber ich krieg immer wieder faults gemeldet (ich habe das dumpfe gefühl, dein crkme führt einfach alles aus). solltest vllt ne chksum einbauen, bevor der code ausgeführt wird oder aber zumindest verhindern, dass destruktiver code ausgeführt wird! :gruebel:
eruhenon - Di 05.12.06 00:14
rizla hat folgendes geschrieben: |
@Chryzler:
hmm.. sehr verdächtig: wenn ich als PW ")" (klammer zu) eingebe, wird in deinem crkme ein check als positiv bewertet und dein crkme beginnt, code zu entschlüsseln, der dann auch ausgeführt wird. bis jetzt läuft mein rechner noch, aber ich krieg immer wieder faults gemeldet (ich habe das dumpfe gefühl, dein crkme führt einfach alles aus). solltest vllt ne chksum einbauen, bevor der code ausgeführt wird oder aber zumindest verhindern, dass destruktiver code ausgeführt wird! :gruebel: |
allerdings könnte hier wieder nen problem vorliegen. wennde ne checksum reinpackst is es zwar als md5 (oder wie auch immer du das machen willst) in dem programm drin aber es ist drin. somit kann man wieder das passwort auslesen und entsprechend per brute force (wenns unbedingt sein muss) entschlüsseln. man hat zumindest schon nen anhaltspunkt für das passwort.
wenn man es einfach ausführt dann hat zumindest der angreifer keine anhaltpunkte.
Chryzler - Di 05.12.06 15:10
rizla hat folgendes geschrieben: |
@Chryzler:
hmm.. sehr verdächtig: wenn ich als PW ")" (klammer zu) eingebe, wird in deinem crkme ein check als positiv bewertet und dein crkme beginnt, code zu entschlüsseln, der dann auch ausgeführt wird. bis jetzt läuft mein rechner noch, aber ich krieg immer wieder faults gemeldet (ich habe das dumpfe gefühl, dein crkme führt einfach alles aus). solltest vllt ne chksum einbauen, bevor der code ausgeführt wird oder aber zumindest verhindern, dass destruktiver code ausgeführt wird! :gruebel: |
Ich hab schon so ne kleine Checksum eingebaut, aber es ist klar, dass du immer wieder ein Passwort findest (z.B. ")"), das die selbe Checksum hat wie das Original-Passwort. Es ging ja auch eher so um's Prinzip. In Echt würde ich da natürlich SHA1 oder MD5 nehmen.
eruhenon hat folgendes geschrieben: |
rizla hat folgendes geschrieben: | @Chryzler:
hmm.. sehr verdächtig: wenn ich als PW ")" (klammer zu) eingebe, wird in deinem crkme ein check als positiv bewertet und dein crkme beginnt, code zu entschlüsseln, der dann auch ausgeführt wird. bis jetzt läuft mein rechner noch, aber ich krieg immer wieder faults gemeldet (ich habe das dumpfe gefühl, dein crkme führt einfach alles aus). solltest vllt ne chksum einbauen, bevor der code ausgeführt wird oder aber zumindest verhindern, dass destruktiver code ausgeführt wird! :gruebel: |
allerdings könnte hier wieder nen problem vorliegen. wennde ne checksum reinpackst is es zwar als md5 (oder wie auch immer du das machen willst) in dem programm drin aber es ist drin. somit kann man wieder das passwort auslesen und entsprechend per brute force (wenns unbedingt sein muss) entschlüsseln. man hat zumindest schon nen anhaltspunkt für das passwort.
wenn man es einfach ausführt dann hat zumindest der angreifer keine anhaltpunkte. |
Wenn du ein genügend langes Passwort wählst, dürfte auch das kein Problem mehr sein.
eruhenon hat folgendes geschrieben: |
@Chryzler thx
nur mal als frage da wir uns ja in opensource units befinden wie haste das denn realisiert?
hab nämlich keinen ansatz wie ich die theorie in die praxis umsetzten kann. |
Sieh dir mal
diesen Thread [
http://www.delphi-forum.de/viewtopic.php?t=66968] an. Dann kommst du bestimmt drauf. ;)
Chryzler
eruhenon - Di 05.12.06 16:47
wenn cih dich jetzt richtig verstanden hab lädst du den code innen speicher und überschreibst ihn dann duch den (aus dem speicher ausgelesenen) entschlüsselten code...
oder hab ichs falsch verstanden?
Chryzler - Di 05.12.06 17:39
eruhenon hat folgendes geschrieben: |
wenn cih dich jetzt richtig verstanden hab lädst du den code innen speicher und überschreibst ihn dann duch den (aus dem speicher ausgelesenen) entschlüsselten code...
oder hab ichs falsch verstanden? |
1. Ich kopiere den verschlüsselten Teil an eine andere Stelle im Speicher
2. Ich entschlüssle den kopierten Teil
3. Ich schreibe den entschlüsselten Teil zurück an die originale Stelle
4. Ich rufe die nun entschlüsselte Stelle auf.
5. Ich gib den nicht mehr benötigten Speicher frei
Jetzt dürfte eigentlich alles klar sein. :)
Sobald das Prog gecrackt wurde, könnt ihr von mir aus auch noch den Quellcode haben ;)
Chryzler
eruhenon - Di 26.12.06 18:10
sieht nicht so aus als würde das hier jemand noch hinkriegn...
hagbart06 - Mi 27.12.06 13:33
Luckie hat folgendes geschrieben: |
Das ist jetzt nicht dein Ernst oder? Was hat das für ein Wert? So eine einfache if-Abfrage dürfte jeder hinbekommen, wohl schon ein Anfänger nach fünf Minuten. Zu dem steht das Passort hardgecodet in der Exe. Ich habe es mal gecrackt. Eventuell findest du ja das neu Passort raus. |
So das Passwort ist Crak, ist ganz einfach, muss man nur mit dem Editor öffnen, braucht nicht mal einen Hex-Editor
Leuchtturm - Mi 27.12.06 13:36
Das steht schon irgendwo auf der ersten/zweiten Seite :roll:
Chryzler - Mi 27.12.06 13:37
Ist nicht wirklich was neues ;)
JayEff hat folgendes geschrieben: |
Naja, man sollte auf jeden fall das Passwort nicht unverschlüsselt speichern, denn wie du gesehen hast, war es kein Probelm für Luckie, dein Programm zu cracken, und btw, die Lösung für Luckies Programm ist "crak". ich habs selbst rausgefunden. Einfach per Hex-editor. |
hagbart06 - Mi 27.12.06 13:43
Ohh man, tut mir leid, habe gar nicht gemerkt das es mehrere Seiten gibt, haben ur die erste gelesen
zongo-joe - Mi 27.12.06 14:37
Da habt Ihr einen gewieften Passwortschutz gefunden. (wenn Ihr mir die Bemerkung erlauben wollt)
Nur: wer soll den benutzen ?
- Wenn man wenige Progs verkauft, braucht man keinen so aufwendigen Schutz, weil entweder keiner Interesse am Crack hat oder das Prog mit Passwort kopiert wird.
- Wenn man viele Progs verkauft, muss man für jedes Programm ein eigenes PW erstellen und dann aber auch jedes verkaufte Programm separat verschlüsseln und brennen, und das ist etwas viel Aufwand, oder ?
Trotzdem, echt keine schlechte Idee !
afk
DarkLord05 - Mi 27.12.06 14:48
Ich finde es schon alleine intressant das aus einer einfach geposteten "if-Abfrage" etwas deartiges entsteht. Den Leuten hier gehts glaub ich nicht darum das es irgendwo in nem teuren Programm benutzt wird, sondern eher darum, das sie eine Abfrage schaffen, die man nicht so einfach knacken kann. Also rein ums Prinzip würd es hier voll treffen denk ich mal. Verfolge das hier schon seit dem 1. Post und es ist sehr intressant was da so bisher rauskommt.
Chryzler - Mi 27.12.06 15:10
zongo-joe hat folgendes geschrieben: |
Da habt Ihr einen gewieften Passwortschutz gefunden. (wenn Ihr mir die Bemerkung erlauben wollt)
Nur: wer soll den benutzen ?
- Wenn man wenige Progs verkauft, braucht man keinen so aufwendigen Schutz, weil entweder keiner Interesse am Crack hat oder das Prog mit Passwort kopiert wird.
- Wenn man viele Progs verkauft, muss man für jedes Programm ein eigenes PW erstellen und dann aber auch jedes verkaufte Programm separat verschlüsseln und brennen, und das ist etwas viel Aufwand, oder ?
Trotzdem, echt keine schlechte Idee !
afk |
Hinweis: Diese Passwortabfrage dient schon seit Threadbeginn nicht als Shareware-Schutz o.ä.. Sie dient
nur dazu, einen Teil des Programms oder das gesamte Programm so einzuschränken, dass man diesen Teil nur mit einem Passwort asuführen kann. Du könntest zum Beispiel ein Spiel programmieren und es mit dieser Passwortabfrage versehen, sodass nur du das Spiel spielen kannst, und nicht dein nerviger Bruder. ;)
Als Shareware-Schutz ist das überhaupt nicht geeignet. Sobald jemand das Passwort mit der dazugehörigen EXE hat, kann er die Datei problemlos von Hand entschlüsseln und patchen. Dann wären wir wieder auf Seite 1.
GTA-Place - Mi 27.12.06 15:15
Dann ist das Ziel das PW geheim zu halten und zwar so geheim, dass es nichtmal der Programmierer weiß ;-).
Sirke - Mi 27.12.06 15:38
Ich hoffe ich habe nicht irgend eine Seite vergessen oder einen Beitrag überlesen, aber es ist total Sinnlos eine If-Abfrage so zuverwandeln, dass man Sie umgehen kann! Man muss nur einmal daran denken wozu man diesen Passwort-Schutz benötigt bzw. was man Schützen möchte.
Einen Gegenstand ein einem Raum einzuschließen und die Tür mit verschiedenen Schlüsseln oder Vorhängeschlössern zu versehen bringt doch gar nichts wenn man einfach die Wand einreißt und sich den Gegenstand holt :/
Ich weiß der Vergleich hinkt ein wenign aber auch bei Programmen kann man ja diese gesammt Abfrage "rausschmeißen" und so das Programm ausführen!
Ich denke man möchte damit Inhalte Schützen, also sollte man nicht eine Tür vor den Inhalt bauen sondern den Inhalt verändern, sodass dieser einem nichts bringt, wenn man ihn ließt. KURZ: Verschlüssel die Daten für z.B. jeden Benutzer mit dem Hash des PWs! - An diesem Punkt sollte man seiner Fantasie freien Lauf lassen und nicht an der Tür die man eh umgehen kann!
Mfg Sirke
F34r0fTh3D4rk - Mi 27.12.06 15:45
joah das hatten wir hier schon besprochen, das ist die einzig sinnvolle möglichkeit, die auch effektiv genug ist.
mfg
Chryzler - Mi 27.12.06 17:15
Hi!
Da das Crackme in absehbarer Zeit wohl doch nicht mehr gecrackt wird, habe ich mich entschlossen, das Passwort, den Original-Quelltext, sowie ein Mini-Tutorial zu veröffentlichen. Ich beschreibe hier, wie ich beim Crackme vorgegangen bin. Es mag auch einfachere Wege geben.
Passwort: bruteFORCE
Entschlüsselung:
Edit1.Text enthält das eingegebene Passwort
EncProc ist die verschlüsselte Prozedur.
L ist vorerst nur ein Dummy-Wert, der später korrigiert wird.
1.
Damit bei einem falschen Passwort nicht unnötig versucht wird, Code zu entschlüsseln und auszuführen (was gar nicht mal so ungefährlich ist), habe ich eine kleine Prüfsumme des richtigen Passwortes eingebaut. Allerdings sollte man darauf achten, dass das Passwort genügend lang gewählt wurde, da man per Bruteforce möglicherweise durch den Hash das Passwort herausfinden könnte. Hier wurde folgende Hashmethode eingesetzt:
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7: 8:
| function Hash(S: String): Byte; var i: Integer; begin Hash := $00; for i := 1 to Length(S) do Hash := Hash xor Ord(S[i]); emd; |
Die Hashlänge beträgt hier nur 1 Byte, was in der Praxis viel zu wenig wäre. Zu Demonstrationszwecken genügt dies jedoch auf jeden Fall. Vor der Verschlüsselung wird das eingegebene Passwort gehasht und mit dem internen Wert (Hash des richtigen Passwortes) verglichen. Stimmen die beiden Werte überein, gehts mit der Entschlüsselung weiter, sind sie verschieden, wird eine Meldung angezeigt, dass das Passwort falsch ist.
2.
Nun entschlüsseln wir den entsprechenden Speicherbereich mit dem zuvor eingesetzten Verschlüsselungsverfahren. Hier habe ich eine der einfachsten Verfahren benutzt, die XOR-Verschlüsselung, die allerdings auf keinen Fall sicher ist.
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18:
| const L = 123; var p: PByte; i: Integer; begin if Hash(Edit1.Text) = $2E then begin p := @EncProc; for i := 0 to L - 1 do begin p^ := p^ xor Ord(Edit1.Text[(i mod Length(Edit1.Text)) + 1]); inc(p); end; end else ShowMessage('Das eingegebene Passwort ist falsch.'); end; |
Der Zeiger
p wird Byte für Byte verschoben und an die Stelle im Speicher, an die er hinzeigt, der entschlüsselte Wert geschrieben.
3. Als letzen Schritt rufen wir nun die entschlüsselte Prozedur auf.
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19:
| const L = 123; var p: PByte; i: Integer; begin if Hash(Edit1.Text) = $2E then begin p := @EncProc; for i := 0 to L - 1 do begin p^ := p^ xor Ord(Edit1.Text[(i mod Length(Edit1.Text)) + 1]); inc(p^); end; EncProc; end else ShowMessage('Das eingegebene Passwort ist falsch.'); end; |
Verschlüsselung:
1.
Als erstes muss das gesamte Programm fertig sein, mit Entschlüsselungsroutine und allem drum und dran. Lediglich die Prozedur, die später verschlüsselt werden soll, ist noch unverschlüsselt. Wir öffnen die fertige EXE-Datei mit einem Disassembler, z.B. OllyDbg, und suchen im Code die Stelle, die verschlüsselt werden soll. Am Besten geht das mit der String-Suche. Wenn wir die Stelle gefunden haben, lassen wir uns anzeigen, aus wieviele Bytes die gesamte Prozedur einschließlich
RETN besteht. Diesen Wert benötigen wir später, deshalb schreiben wir ihn uns auf. Im Disassembler kopieren wir uns die gesamte Prozedur noch in eine neue Datei.
2.
Diese Datei verschlüsseln wir nun mit dem gewünschten Passwort. Die Implementierung einer einfachen, aber unsicheren XOR-Verschlüsselung könnte so aussehen:
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17:
| procedure Encrypt; var i: Integer; psw: String; FSIn, FSOut: TFileStream; Buf: Byte; begin FSIn := TFileStream.Create('C:\proc.txt', fmOpenRead); FSOut := TFileStream.Create('C:\proc_enc.txt', fmCreate); i := 0; repeat FSIn.Read(Buf, 1); Buf := Buf xor Ord(psw[(i mod Length(psw)) + 1]); FSOut.Write(Buf, 1); inc(i); until FS.Position = FS.Size; end; |
3.
Mittels eines Hex-Editors oder eines Disassemblers kopieren wir nun den Inhalt der neuen Datei zurück in unser Programm, genau an die Stelle, wo die zu verschlüsselnde Prozedur ist.
4.
Da wir zur Entwicklungszeit noch nicht wussten, wie groß der zu verschlüsselnde Teil später einmal in der EXE sein wird, müssen wir diesen Wert nachträglich wieder korrigieren. Wir suchen also im Disassembler die Stelle, wo
L definiert wird (im Beispielprogramm bekommt L den Wert 123) und überschreiben diesen Wert mit der zuvor am Anfang aufgeschriebenen Zahl. Wir speichern alle Änderungen ab.
5.
Nun können wir unser Programm starten und die Passwortabfrage testen. Viel Spaß!
Anmerkungen:
Alle Variablen, die man in der Prozedur, die verschlüsselt wird, deklariert und initialisiert, werden
nicht verschlüsselt. Das liegt daran, dass die Daten für die Variablen nicht zwischen dem eigentlichen Quelltext stehen, sondern außerhalb der Prozedur.
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7:
| procedure EncProc; var S: String; begin S := 'Hallo, das kann niemand lesen'; ShowMessage('Das auch nicht'); end; |
Um diese "Sicherheitslücke" zu umgehen müsste man jede einzelne Variable verschlüsseln, oder aber Delphi dazubringen, die Daten für Variablen innerhalb des Codes zu speichern. Ob letzeres möglich ist und wie, kann ich euch auch nicht sagen.
Chryzler
GTA-Place - Mi 27.12.06 18:14
Klingt gut, wenn auch kompliziert. Ich guck das später mal genauer an.
ConditionZero - Mi 27.12.06 19:18
So mal was ganz hartes ;)
Hab des Teil von
http://www.Hackquest.com
da gehts um solche aufgaben.
Da ich gemerkt hab hier sind welche wo sich auskennen hab ich halt mal die schwerste
Aufgabe aus dem Bereich CrackIt genommen :P
Würd mich bei Freuen wenn es jmd. schafft und mir erklärt wie denn das habe ich selber noch nicht hinbekommen...
Chryzler - Mi 27.12.06 20:27
Beschreibung aktualisiert. Man kann das ganze OpenProcess, ReadProcessMemory, usw. weglassen. Dadurch verkürzt sich der Code erheblich. Ich hoffe, dass ich jetzt keinen Fehler reingebracht habe.
Flamefire - Do 31.07.08 15:52
hab den thread hier durch zufall mal ausgegraben, da ich selber grade dateien von mir schütze
das crackit12 da ist das einfachste was ich gesehen hab...aspack gepackt und mit 1 abfrage geschützt:
http://www.sendspace.com/file/429pt1
da habter die gecrackte version ^^ (jedes pw geht)
der mechanismus von Chryzler gefällt mir
man kann ja mal ein programm schreiben, dass das automatisch macht
das sinnvollste ist es tatsächlich, einen möglichst variablen schlüssel zu nehemen der die wichtigsten daten entschlüsselt
ich hab das mit nem serverseitigen login geregelt. dann noch obfuscater drüber und es ist nicht mehr knackbar (ok doch ist es, aber seeehr umständlich)
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2024 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!