• als kleine auffrischung und zum starten hat mir foglendes sehr geholfen:


    http://www.milw0rm.com/papers/42


    und wenns dann doch etwas komplizierter wurde hat kein weg daran vorbeigefuehrt, auch mal hier nen blick hineinzuwerfen:


    http://www.intel.com/products/processor/manuals/index.htm


    vor allem "Volume 2A: Instruction Set Reference, A-M" und "Volume 2B: Instruction Set Reference, N-Z". fuers grundsaetzliche verstaendnis lohnt sich sicherlich auch ein blick in "Volume 1: Basic Architecture"


    hoffe, es hilft euch auch weiter


    mfg wicked

  • Quote

    Ja, das Problem hab ich im Moment auch bei prog8 und gdb. Ich kann zwar einen Breakpoint auf "_init" setzen, dann kann ich mich bis zur main durchsteppen (z.b. mit stepi statt step). Irgendwann bin ich dann aber wieder in ?? () und komme nicht wirklich weiter.


    Ich hab mal einen Breakpoint auf strncpy gesetzt - damit kommt man zumindest bis check_serial...
    Ist die Funktion handle_checks wichtig zum Lösen der Aufgabe!? - bis dahin hab ich's mit gdb nämlich noch nicht geschafft.


    Hat jemand eine Erklärung dafür warum das mit den Segmentation-Faults sobald man Breakpints einfügt passiert?

  • Wie kann man in C den Overflow berechnen? Ich bekomme nur den unteren Teil des Ergebnisses und wenn ich auf long long konvertiere ebenfalls. Bzw. kommt bei long long ein segmentation fault.


    Ich verwende folgendes:

    Code
    1. long long blub = (long long)eax * (long long)ecx;
    2. edx = (blub & 0xFFFFFFFF00000000) >> 32;
    3. eax = blub & 0xFFFFFFFF;

    Wie oben erklärt, landet der Overflow-Teil in edx.


    Quote

    Ist die Funktion handle_checks wichtig zum Lösen der Aufgabe!?

    Imho nein.

  • Quote


    Hat jemand eine Erklärung dafür warum das mit den Segmentation-Faults sobald man Breakpints einfügt passiert?

    Ich nehm mal an, das wird ein anti-debug-mechanismus sein. Ich muss sagen, dass ich von anti-debugging-techniken unter linux nicht wirklich ahnung hab und ich auch gdb nicht wirklich sooo gut kenn, aber es wäre möglich, dass folgendes passiert:
    - wenn du in gdb einen breakpoint setzt, schreibt dir gdb an die angegebene stelle ein 0xcc (int 03). sobald im programmfluss dieses int 03 erreicht wird, wird die kontrolle an den debugger übergeben, der überschreibt das 0xcc wieder mit dem original-byte an der adresse und du kannst fröhlich befehl für befehl tracen.
    - im programm befindet sich eine kleine routine, die das eigene image nach 0xcc absucht und wenn die routine fündig wird, bringt sie das programm zum absturz, weil dann klar ist, dass das programm debuggt wird (oder es wird einfach eine checksum berechnet und verglichen).


    wie gesagt bin ich aber zu wenig linux/gdb-guru um mehr als vermutungen anzustellen. ich hab kurz nach einer solchen check-routine gesucht, wurde aber nicht fündig. allerdings ist der serial-check von prog8 glücklicherweise relativ simpel gehalten, sodass statische code-analyse eigentlich ausreicht (zugegebenermaßen habe ich für die statische analyse aber nicht mit objdump sondern mit ida gearbeitet - das macht die sache irgendwie angenehmer :p).


    EDIT: ich weiß nicht ob die sache mit prog7 und nicht vollständiger lösung noch aktuell ist. anyway: wenn man einen CALL auf eine funktion ausNOPt, wird die funktion nicht aufgerufen. klingt banal, ist es auch. allerdings sollte man, bevor man dies tut, genau wissen was die funktion macht. und damit meine ich nicht, dass den serialcheck-algorithmus verstehen sollte. es ist viel einfacher. man muss sich nur die funktion genau ansehen - von anfang bis ende.

    [chaas4747]: What the hell is a defence?
    [dermalin3k]:
    It's that wall in deyard between dehouses.

    Edited once, last by onkel_keks ().

  • Danke Leute für die hilfreichen Links, jetzt komme ich so langsam weiter. Eine Frage noch zum objdump:

    Code
    1. movzbl %al,%edx


    Mit welchem Wert wird %al initialisiert? Im ganzen Assembler-Code wird nur lesend darauf zugegriffen. Ich gehe inzwischen einfach mal davon aus, dass es mit 0 initialisiert wird.

  • Servus, hat jemand noch Tipps zu prog8? prog7 war kein problem...


    Ich kann mir im Debugger auch Schritt für Schritt die funktionsweise anschaun, nur weis ich nicht mal was in den Registern hier zu beginn drinnen steht...

  • Ok,


    Dann hab ich dort jetzt Werte stehen, nur versteh ich nicht ganz was ich mit diesen Werten in Verbindung bringen soll...


    Was steht beim Aufruf von check_serial in EAX, EBX, ECX, EDX? ich hab da nur irgendwelche Zahlen oder sind das eben wieder nur Pointer auf die richtigen Werte?

  • Was beim Aufruf von check_serial in den einzelnen Registern steht, brauchst du denk ich nicht weiter beachten, die werden nämlich in der Funktion immer zuerst initialisiert, bevor lesend darauf zugegriffen wird. eax-edx sind Hilfsregister, mit denen in der Funktion verschiedene Zwischenergebnisse gespeichert werden, das können je nach Befehl Pointer oder Werte sein, aber das sieht man denk ich eh leicht an der Zahl die drinnen steht.


    Die einzigen Parameter, die die Funktion hat, liegen oberhalb des Base pointers, die lokalen Variablen darunter. Ich hab die immer mit "x $ebp+offset" bzw. "x $ebp-offset" angeschaut, evtl. gehts aber auch einfacher mit gdb. Wenig überraschend benötigt die Methode nur Pointer auf die beiden Argument-Strings.


    Ich hab die Aufgabe so gelöst:
    Zuerst hab ich mir zu jeder Assembler-Zeile einen Kommentar gemacht, was der Befehl macht (http://www.itis.mn.it/linux/quarta/x86/ war da eine große Hilfe). Dabei hab ich Speicheraddressen durch Variablen ersetzt, wenn ich var1 =... schreib ist das schon wesentlich lesbarer als 0xfffffffe8(%ebp). Dann bin ich das Programm durchgesteppt im Debugger und hab nachkontrolliert, ob sich die Register und lokalen Variablen auch wirklich so ändern, wie ich das erwartet habe.
    Wenn du dir dann am Schluss die lokalen Variablen anschaust, ist es dann nicht mehr so schwer und du siehst, welche Teile du nachbauen musst.
    Du musst nicht unbedingt die ganze Methode genau durchanalysieren, nur ungefähr die Hälfte ist relevant, der Zugriff auf handle ist mir z.B. immer noch schleierhaft. Welche Teile du brauchst, siehst du dann aber eh beim durchsteppen im gdb, wenn du die lokalen Variablen immer mitverfolgst.


    Dann muss man nur mehr die Assembler-Codes in C umwandeln und man ist fertig. Die Fallen, die ich da noch erlebt hab, waren nicht so schlimm, ich erwähn sie aber trotzdem:
    -Beim Shiften aufpassen, dass es ein logischer Shift ist und kein arithmetischer.
    -Bei den Datentypen-Größen aufpassen (eh schon erwähnt hier)
    -Man muss sich noch überlegen, was das Programm macht, wenn die Eingabestrings "zu kurz" sind für den Algorithmus. Das geschieht denk ich schon in main, aber es reicht wenn man sich die Auswirkung anschaut und dann nachbaut.

    "Sausen Sie mit mir ins Laplace-Land" - KAISER 4ever :D

  • Hätt ne Frage wegen den hier beschrieben Overflow ;)


    Per Debugger bekomm ich bei der Rechnung 233 * 0E6C2B449 => edx = 0xd2 = 210


    nun hab ich probiert den Hexadezmialen Wert in Dez umzuwandeln int x = 3214609862


    und mit der hier vorgestellten Overflow Berechnung von Cocolus versucht und bekomme da leider das Ergebnis c5 = 197 | weiß nicht was ich falsch mache *G*


    Thx for any Tip ;)

    Edited once, last by Uter ().

  • thx für den Tipp ;) ich war einfach zu blöd hex in dec zu rechnen *G*


    so hänge nun am Lookup -> weiß noch nicht wie ich den implementieren soll...

  • so hänge nun am Lookup -> weiß noch nicht wie ich den implementieren soll...


    weil weihnachten kommt:


    Code
    1. //movzx eax, byte ptr [edx+8049AC0h]
    2. //lookup in the (printable) ascii-table
    3. char pascii[] = "!$%&/()=?abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
    4. eax = pascii[edx];
  • thx schon geschafft ;)


    letztes einziges Prob ist bei mir die letzte Stelle (die NOT)


    wollte nur fragen ob eax durch var_F (bevor operation not durchgeführt wird) 84 immer ist. (nach not -85)....

  • Danke für die vielen guten Kommentare, ums bedanken kümmere ich mich lieber später... *g*


    Könnte mir jemand bitte sagen was
    movzbl 0xffffffe9(%ebp, %eax, 1), %eax
    genau bedeutet?


    Mit einem "Argument" ist es mir ja klar, aber was bewirkt das "%eax, 1"?


    EDIT: Meine Güte... so kann man auf der Leitung stehen. Danke, ist klar...

  • Vielen Dank an alle Beteiligten, ich habe mich gerade bei den wichtigsten Posts bedankt.


    Gerade nochmal gutgegangen... :D Für die nächste Challenge muss ich definitiv früher anfangen: Das hält man im Kopf nicht aus... :shiner: