Versucht es zu cracken !

  • PE: 0xad0024 + 0x91bff.

    Code
    0046C10D     2.   Active    jnz     short 0046C11B            jnz     short 0046C10F
    0046C568     2.   Active    jnz     short 0046C590            jnz     short 0046C56A
    0046C9E2     2.   Active    jnz     short 0046CA0A            jnz     short 0046C9E4


    53, 57, 192.168.69.79. ;)


    /edit: Les' dir ein paar grundlegendere Tutorials zur Thematik durch, die Frage lässt sich nicht so ohne Weiteres umfassend beantworten - solche Fragen haben auch schon Bücher gefüllt. ;)

    [SIZE=1]» xor byte ptr [edi+78], al[/SIZE]

    Einmal editiert, zuletzt von f0Gx ()

  • Gut, hatte nicht wirklich darauf geachtet und den passenden - nun eben nicht konstanten - Wert manuell eingetragen. Die aufgeführten Patches umgehen das Problem so oder so.


    Ebenso kann der Start der zweiten PE (die erste Adresse, die ich gepostet habe) natürlich variieren, hatte gerade meinen Notepad-Inhalt gepastet.

  • Syler: mit Hashcracking hat es aber auch nichts am Hut ;)


    Topic:
    Solange nach einem Check ein JNZ/JE folgt, bringen auch ausgeklügelte Algos nichts ;).
    Dasselbe gilt für Plaintextvergleich (also Key berechnen und mit Eingabe direkt vergleichen).
    1. Man sollte mit Fehler/Erfolgsmeldungen sparsam umgehen (sonst ist das Auffinden der Prüfroutine ein Kinderspiel). Wenn es sich nicht vermeiden lässt, sollte so eine Meldung zeitverzögert ausgegeben werden (und damit meine ich nicht einen "Sleep" vor der Ausgabe ;) - Timer+Threads wären hier richtiger)).
    Dazu auch die wichtigen Strings verschlüsselt vorliegen und erst unmittelbar vor der Nutzung entschlüsselt werden.
    2.Man sollte auch immer mit der Usereingabe rechnen. Der komplizierteste Hashalgo bringt nichts, wenn es dann so aussieht:

    Code
    if (super_hash(name)==eingabe then "Erfolg" else "Fehler!"

    Vergleichsroutine sollte man selber schreiben. Dabei aber auf simple boolean Rückgaben verzichten (also wiederum nicht:

    Code
    if(super_hash(key)==RSA(getHWID(myKeyCode)) then "Super!" else "FAAALSCH!!!")

    - es bringt nichts, da hier letzendlich ein CALL XYZ, JNZ _false_ generiert wird.


    Ideal wäre es, informationen zu verwenden vom Cracker nicht ohne weiteres nachvollzogen werden können.
    Sollte also eher in die Richtung gehen:

    Code
    Beim Programmstart:starte_irgendwo_unauffällig_den_false_Msg_thread;der Thread checkt z.B einen Flag und wenn der gesetzt sein sollte, gibt er die Falschmeldung aus....unmittelbare prüfung:lese_möglichst_unauffällig_die_eingabe;...check_eingabe(eingabe){  werte_array=berechne_paar_werte(eingabe) <- darf sehr gro� sein und viel Junkcode enthalten  noch_ein_arry=berechne_weitere_werte(werte_array); <-- dasselbe  function_adress_datatype myFunc=noch_ein_array  if (CRC(myFunc==XYZ)) then call(myFunc) else  {setze_false_flag};}

    Der Code berechnet einen Wert, der als Adress für einen Funktionsaufruf genutzt wird. Das patchen des Vergleichs wird nur zum Absturz führen.


    Der Cracker muss also erstmal die richtige Adresse finden/einen gültigen Key haben. Gegen Keyweitergabe könnte man noch paar HWIDs mit in die Berechnung einbauen.


    Hier eine kleine Demo mit TurboPascal:


    Sollte auch In Delphi genauso umsetzbar sein (eventuell Datentypen anpassen). Der Richtige Key hier:
    364838918
    "super_hash" ist natürlich bewusst einfach gehalten ;). Jedoch wird man bei einer grö�eren Anwendung ohne einen gültigen Key nur schwer weiterkommen können. Und der Aufwand zur Implementierung hält sich in Grenzen.