+++
title = 'Reverse Engineering σε περιβάλλον Linux, Μέρος 1'
date = '2003-06-01T00:00:00Z'
description = ''
author = 'Φραντζής Αλέξανδρος (aka Alf) alf82 at freemail dot gr'
issue = ['Magaz 33']
issue_weight = 5
+++

**1. Εισαγωγή**
--------------------------------------

**2. Χρήση του GDB για assembly debugging**
------------------------------------------------------------------

-   [2.1 Εξετάζοντας τον κώδικα assembly και άλλα παρεμφερή](#ss2.1)
-   [2.2 Εξετάζοντας τα δεδομένα](#ss2.2)
-   [2.3 Εκτελώντας τον κώδικα](#ss2.3)
-   [2.4 Πληροφορίες για το εκτελέσιμο](#ss2.4)
-   [2.5 Καλώντας συναρτήσεις και ψάχνοντας για σύμβολα](#ss2.5)

**3. Άλλα χρήσιμα εργαλεία**
---------------------------------------------------

-   [3.1 strace](#ss3.1)
-   [3.2 ltrace](#ss3.2)

**4. Υλοποίηση των breakpoints**
-------------------------------------------------------

-   [4.1 Software Breakpoints](#ss4.1)
-   [4.2 Hardware Breakpoints](#ss4.2)
-   [4.3 Hints and Tips - Home-made Traps](#ss4.3)

**5. Χρήσιμες έως **πολύ** χρήσιμες πληροφορίες**
------------------------------------------------------------------------

-   [5.1 The C calling convention](#ss5.1)
-   [5.2 System Calls](#ss5.2)

**6. Hands-on Παράδειγμα**
-------------------------------------------------

**7. Πρόκληση**
--------------------------------------

-   [7.1 Προηγούμενη πρόκληση - Λύση και Hall Of Fame](#ss7.1)
-   [7.2 Πρόκληση \#1](#ss7.2)


### [1. Εισαγωγή]{#s1}

Το πρώτο μέρος του άρθρου (2-3) έχει βασικό σκοπό την παρουσίαση των πιο κοινών εργαλείων που υπάρχουν στο linux και που μπορούν να ενισχύσουν την προσπάθεια
κατανόησης της λειτουργίας ενός εκτελέσιμου. Βέβαια, αυτά τα εργαλεία δεν είναι τα μόνα που υπάρχουν και μια αναζήτηση στο διαδίκτυο θα εμφανίσει πολλούς
θησαυρούς. Το πρόβλημα με τα περισσότερα από τα προγράμματα που ίσως βρείτε, είναι ότι πρόκειται περί \"diamonds in the rough\". Θα σας ταλαιπωρήσουν μέχρι να
τα στήσετε σωστά και μετά ποιος ξέρει τι άλλα προβλήματα θα εμφανιστούν.

Στο δεύτερο μέρος (4-6) θα ασχοληθούμε με πιο γενικές πληροφορίες σε σχέση με το RCE. **Προσοχή**: δεν πρόκειται για περιττές πληροφορίες αλλά για βασικές
γνώσεις, χωρίς τις οποίες θα δυσκολευτείτε να κατανοήσετε τι πραγματικά συμβαίνει.

Για την καλύτερη κατανόηση του άρθρου είναι επιθυμητή μια στοιχειώδης, το λιγότερο, γνώση της γλώσσας assembly. Θα προσπαθήσω να εξηγώ όπου χρειάζεται, όμως
σίγουρα δεν πρόκειται να μετατρέψω το κείμενο σε assembly tutorial. Πολλοί ίσως να θεωρούν την assembly παρωχημένη γλώσσα άλλα να είστε σίγουροι πως RCE χωρίς
assembly δε νοείται. Μια αναζήτηση για \"x86 assembly tutorial\" στο google θα σας δώσει πληροφορίες που θα σας απασχολήσουν για πολύ καιρό.

Τέλος όπως κάθε φορά υπάρχει η πρόκληση του μήνα. Στόχος είναι να σας επιτρέψει να εξασκήσετε τις ικανότητές σας, να γνωρίσετε τα όρια σας και να χαρείτε από
πρώτο χέρι τη διαδικασία του RCE!

Επίσης οτιδήποτε σχόλιο δεκτό: θεωρείτε τις προκλήσεις πολύ εύκολες/δύσκολες, θα θέλατε να καλυφθεί κάποιο θέμα ή να καλυφθεί εκτενέστερα;

Στο επόμενο τεύχος θα συνεχίσουμε με τη δομή των ELF, το objdump, το /proc filesystem, περισσότερα hands-on παραδείγματα και ποιος ξέρει τι άλλο :)

Καλό RCE και κυρίως **καλό καλοκαίρι**!


### [2. Χρήση του GDB για assembly debugging]{#s2}

Στο μέρος αυτό θα εξετάσουμε τις δυνατότητες του GDB για assembly debugging. Το case-study πρόγραμμα θα είναι το ίδιο με την προηγούμενη φορά:

----------------------------------------------------------------------------------------------------------------------------------------------------------------

    #include <stdio.h>

    int main(int argc, char **argv)
    {
            int num;

            if (argc<2) {
                    printf("Usage: %s <number>\n",argv[0]);
                    exit(1);
            }

            num=alf(argv[1]);

            if (num>10) 
                    printf("Ok!\n");
            else 
                    printf("Failed!\n");
    }

    int alf(char *s)
    {
            return atoi(s);
    }

----------------------------------------------------------------------------------------------------------------------------------------------------------------

Κάντε compile με : gcc \[-g\] -o rce1 rce1.c

Αυτή τη φορά η παράμετρος \"-g\" δεν είναι απαραίτητη αλλά και να την χρησιμοποιήσουμε δε μας ενοχλεί. Το φόρτωμα του προγράμματος στον GDB γίνεται ως συνήθως:

>     bash$ gdb rce1
>     (gdb)

Αν δοκιμάσουμε να δούμε τον πηγαίο κώδικα του προγράμματος χωρίς να έχουμε κάνει compile με -g:

>     (gdb) list
>     1       init.c: No such file or directory.
>             in init.c
>     (gdb)

O GBD δε βρίσκει το αρχείο \"init.c\". Ε, και τι έγινε θα πείτε; Το δικό μας αρχείο είναι το \"rce1.c\"! Το πρόβλημα είναι ότι το εκτελέσιμο δεν περιλαμβάνει
καμία πληροφορία για το ποιο είναι το πηγαίο αρχείο του και ο GDB υποθέτει το όνομα \"init.c\". To \"init.c\" είναι το αρχείο πηγαίου κώδικα που αντιστοιχεί
στην αρχικοποίηση της libc. Αν δημιουργήσουμε ένα αρχείο με το όνομα \"init.c\", τότε η **list** θα μας δείξει το περιεχόμενο του αρχείου αυτού. Αλλά και πάλι
δεν μπορούμε να κάνουμε δουλειά, διότι ο debugger δεν γνωρίζει ποιες εντολές assembly αντιστοιχούν σε ποιες γραμμές C κώδικα. Αν πχ έχουμε αντιγράψει το
\"rce1.c\" σε \"init.c\":

>     bash$ cp rce1.c init.c
>     bash$ gdb -q rce1
>     (gdb) break main
>     Breakpoint 1 at 0x8048392
>     (gdb) r
>     Starting program: /home/alf/projects/magaz/issue1/rce1
>     Breakpoint 1, 0x08048392 in main ()
>     (gdb) n
>     Single stepping until exit from function main,which has no line number
>     information.
>     Usage: /home/alf/projects/magaz/issue1/rce1 <number>
>
>     Program exited with code 01.
>     (gdb)

Όταν πήγαμε να προχωρήσουμε μία γραμμή πηγαίου κώδικα με την **n**, ο GDB παραπονέθηκε πως δεν έχει τις απαραίτητες πληροφορίες και αποφάσισε να προχωρήσει
μέχρι το τέλος της main(). Για πλάκα μπορούμε να συγχύσουμε τον GDB (και τους εαυτούς μας) αν κάνουμε compile με το -g flag και μετά αντικαταστήσουμε το source
αρχείο μας με ένα άσχετο :)

Αφού λοιπόν δεν έχουμε τον πηγαίο κώδικα αυτό ήταν\... ας πάμε να παίξουμε τάβλι καλύτερα. Αλλά μια φωνή μέσα μας (τουλάχιστον μέσα σε εμένα!) αρνείται να
παραδώσει τα όπλα. The gate is now open, welcome to the world of RCE!

### [2.1 Εξετάζοντας τον κώδικα assembly και άλλα παρεμφερή]{#ss2.1}

Αφού λοιπόν δεν αποθαρυνθήκαμε, ας εξετάσουμε το assembly listing της main. Αυτό γίνεται (κυρίως) με την εντολή **disassemble \<διεύθυνση\> \[\<τελική
διεύθυνση\>\]**. Αν ορίσουμε μόνο μια παράμετρο, τότε εμφανίζεται ο κώδικας **όλης της συνάρτησης** στην οποία ανήκει η διεύθυνση. Το πρόβλημα είναι πως αν ο
GDB δε γνωρίζει σε ποια συνάρτηση ανήκει η διεύθυνση (πχ όταν δεν υπάρχουν σύμβολα στο εκτελέσιμο), είτε θα παραπονεθεί και δε θα τυπώσει τίποτα είτε θα
συγχυστεί με προηγούμενα σύμβολα και θα μας εκτυπώσει κατεβατά ολόκληρα. Για παράδειγμα:

>     (gdb) disas main
>     Dump of assembler code for function main:
>     0x804838c <main>:       push   %ebp
>     0x804838d <main+1>:     mov    %esp,%ebp
>     0x804838f <main+3>:     sub    $0x8,%esp
>     0x8048392 <main+6>:     and    $0xfffffff0,%esp
>     0x8048395 <main+9>:     mov    $0x0,%eax
>     0x804839a <main+14>:    sub    %eax,%esp
>     0x804839c <main+16>:    cmpl   $0x1,0x8(%ebp)
>     0x80483a0 <main+20>:    jg     0x80483c1 <main+53>
>     0x80483a2 <main+22>:    sub    $0x8,%esp
>     0x80483a5 <main+25>:    mov    0xc(%ebp),%eax
>     0x80483a8 <main+28>:    pushl  (%eax)
>     0x80483aa <main+30>:    push   $0x8048464
>     0x80483af <main+35>:    call   0x80482ac <printf>
>     0x80483b4 <main+40>:    add    $0x10,%esp
>     0x80483b7 <main+43>:    sub    $0xc,%esp
>     0x80483ba <main+46>:    push   $0x1

Οι εντολές:

>     (gdb) disas main+44
>     (gdb) disas 0x80483f7

και γενικά όσες διευθύνσεις περιέχονται στη main θα έχουν ως αποτέλεσμα να εκτυπωθεί όλη η main (ακριβώς όπως παραπάνω). Προσοχή πως το \"main\" είναι απλώς ένα
σύμβολο που αντιστοιχεί σε κάποια διεύθυνση, εδώ την 0x804838c. Η έκφραση main+44 είναι και αυτή μια διεύθυνση (0x80483b8). Δεν έχει σημασία που δεν αποτελεί
την αρχή κάποιας εντολής ( είναι το δεύτερο byte της sub \$0xc,%esp), αρκεί που ανήκει μέσα στη συνάρτηση main.

[]{#gdb_asm} Η ερώτηση που τίθεται είναι η εξής: που ξέρει ο GDB που αρχίζει και τελειώνει μια συνάρτηση; Και η απάντηση: ο GDB ξέρει μόνο που αρχίζει η
συνάρτηση και υποθέτει ότι συνεχίζει η ίδια συνάρτηση μέχρι να βρει κάποιο άλλο σύμβολο που είναι σύμβολο συνάρτησης.

Αν τα σύμβολα στο εκτελέσιμο κατά σειρά αύξουσας διεύθυνσης είναι:

>     0804838c  main
>     08048406  alf
>     0804841c  __do_global_ctors_aux

O GDB θεωρεί πως ό,τι βρίσκεται μεταξύ των διευθύνσεων main και alf ανήκει στη συνάρτηση main, ό,τι βρίσκεται μεταξύ των alf και \_\_do\_global\_ctors\_aux
ανήκει στη συνάρτηση alf κτλ. Το γεγονός πως τα όρια της κάθε συνάρτησης (για την ακρίβεια το τέλος) δεν είναι γνωστά, προκαλεί το πρόβλημα που αναφέρθηκε
παραπάνω (ο GDB δε μπορεί να βρει σε ποια συνάρτηση ανήκει η διεύθυνση ή κάνει λάθος). Ας δούμε το πρόβλημα στην πράξη:

>     bash$ strip -s rce1 
>     bash$ gdb rce1
>     (no debugging symbols found)...
>     (gdb)

H εντολή strip \"απογυμνώνει\" ένα object αρχειο από όλα τα σύμβολα που μπορεί. Γράφω \"μπορεί\", διότι υπάρχουν μερικά που δε έχει νόημα να αφαιρέσει, όπως για
παράδειγμα αυτά που αναφέρονται σε εξωτερικές συναρτήσεις και δεδομένα. Ο λόγος είναι ότι στο στάδιο του linking (είτε αυτό είναι dynamic είτε όχι) δε θα
μπορέσει να βρει τις διευθύνσεις τους αν δε γνωρίζει το όνομα τους!

>     (gdb) disas main
>     No symbol table is loaded.  Use the "file" command.

Το σύμβολο main δε βρέθηκε αλλά εμείς ξέρουμε τη διεύθυνση του.

>     (gdb) disas 0x804838c
>     Dump of assembler code for function atoi:
>     0x80482cc <atoi>:       jmp    *0x804958c
>     0x80482d2 <atoi+6>:     push   $0x18
>     0x80482d7 <atoi+11>:    jmp    0x804828c
>     0x80482dc <atoi+16>:    xor    %ebp,%ebp
>     0x80482de <atoi+18>:    pop    %esi

Και ιδού\... Ο GDB τα \"πήρε\" :)

Το μόνο σύμβολο που υπάρχει αμέσως πριν τη διεύθυνση της main είναι το atoi οπότε ο debugger θεωρεί πως η διεύθυνση 0x804838c ανήκει στη συνάρτηση atoi(). Το
σύμβολο atoi δείχνει σε μια εξωτερική συνάρτηση για αυτό και δεν αφαιρέθηκε. Σε αυτές τις περιπτώσεις είναι χρήσιμη η εναλλακτική μορφή της disassemble στην
οποία ορίζουμε τόσο την αρχική όσο και την τελική διεύθυνση για το disassembly :

>     (gdb) disas 0x804838c 0x80483a0
>     Dump of assembler code from 0x804838c to 0x80483a0:
>     0x804838c <atoi+192>:   push   %ebp
>     0x804838d <atoi+193>:   mov    %esp,%ebp
>     0x804838f <atoi+195>:   sub    $0x8,%esp
>     0x8048392 <atoi+198>:   and    $0xfffffff0,%esp
>     0x8048395 <atoi+201>:   mov    $0x0,%eax
>     0x804839a <atoi+206>:   sub    %eax,%esp
>     0x804839c <atoi+208>:   cmpl   $0x1,0x8(%ebp)
>     End of assembler dump.

Μπορεί ο GDB να πιστεύει πως βρισκόμαστε 192 bytes από την αρχή της atoi αλλά εμείς ξέρουμε πως ουσιαστικά είμαστε στην αρχή της main!

Κλείνοντας αυτό το κομμάτι θα ασχοληθούμε λίγο με τη μορφή του listing. Όσοι έχετε ασχοληθεί με assembly στον x86 η σύνταξη των προηγούμενων listing ίσως σας
φανεί λίγο παράξενη. Αυτή ονομάζεται AT&T syntax και ένα βασικό χαρακτηριστικό της είναι ότι στις εντολές της έχει ανάποδα την πηγή και τον προορισμό, σε σχέση
με την άλλη μορφή την Intel syntax. Πχ για να μετακινήσουμε το περιεχόμενο του καταχωρητή ebx στον eax :

>     mov %ebx, %eax  AT&T
>     mov eax, ebx    Intel

Βέβαια υπάρχουν και άλλες διαφορές αλλά δε θα μας απασχολήσουν εδώ. Επίσης υπάρχουν και παραλλαγές των παραπάνω όπως η σύνταξη που χρησιμοποιεί ο Nasm (Netwide
Assembler) η οποία βασίζεται στην Intel αλλά κατά τη γνώμη είναι πιο ξεκάθαρη Παρακάτω θα χρησιμοποιήσουμε τη σύνταξη της Intel διότι είναι γενικά πιο
διαδεδομένη για τους επεξεργαστές της. Στον GDB η σύνταξη ορίζεται στην εσωτερική μεταβλητή disassembly-flavor:

>     (gdb) set disassembly-flavor intel
>     (gdb) disas main
>     Dump of assembler code for function main:
>     0x804838c <main>:       push   ebp
>     0x804838d <main+1>:     mov    ebp,esp
>     0x804838f <main+3>:     sub    esp,0x8
>     0x8048392 <main+6>:     and    esp,0xfffffff0
>     0x8048395 <main+9>:     mov    eax,0x0
>     0x804839a <main+14>:    sub    esp,eax
>     0x804839c <main+16>:    cmp    DWORD PTR [ebp+8],0x1
>     0x80483a0 <main+20>:    jg     0x80483c1 <main+53>
>     0x80483a2 <main+22>:    sub    esp,0x8
>     0x80483a5 <main+25>:    mov    eax,DWORD PTR [ebp+12]
>     0x80483a8 <main+28>:    push   DWORD PTR [eax]
>     0x80483aa <main+30>:    push   0x8048464
>     0x80483af <main+35>:    call   0x80482ac <printf>
>     0x80483b4 <main+40>:    add    esp,0x10
>     0x80483b7 <main+43>:    sub    esp,0xc
>     0x80483ba <main+46>:    push   0x1
>     0x80483bc <main+48>:    call   0x80482bc <exit>
>     0x80483c1 <main+53>:    sub    esp,0xc
>     0x80483c4 <main+56>:    mov    eax,DWORD PTR [ebp+12]
>     0x80483c7 <main+59>:    add    eax,0x4
>     0x80483ca <main+62>:    push   DWORD PTR [eax]
>     0x80483cc <main+64>:    call   0x8048406 <alf>
>     0x80483d1 <main+69>:    add    esp,0x10
>     0x80483d4 <main+72>:    mov    DWORD PTR [ebp-4],eax
>     0x80483d7 <main+75>:    cmp    DWORD PTR [ebp-4],0xa
>     0x80483db <main+79>:    jle    0x80483ef <main+99>
>     0x80483dd <main+81>:    sub    esp,0xc
>     0x80483e0 <main+84>:    push   0x8048478
>     0x80483e5 <main+89>:    call   0x80482ac <printf>
>     0x80483ea <main+94>:    add    esp,0x10
>     0x80483ed <main+97>:    jmp    0x80483ff <main+115>
>     0x80483ef <main+99>:    sub    esp,0xc
>     0x80483f2 <main+102>:   push   0x804847d
>     0x80483f7 <main+107>:   call   0x80482ac <printf>
>     0x80483fc <main+112>:   add    esp,0x10
>     0x80483ff <main+115>:   mov    eax,0x1
>     0x8048404 <main+120>:   leave
>     0x8048405 <main+121>:   ret
>     End of assembler dump.
>     (gdb)

### [2.2 Εξετάζοντας τα δεδομένα]{#ss2.2}

Τα δεδομένα που μας ενδιαφέρουν όταν ασχολούμαστε με low-level debugging μπορούν να βρίσκονται είτε σε κάποιον καταχωρητή είτε στη μνήμη.

#### Εξετάζοντας καταχωρητές

Ο βασικός τρόπος για να δούμε τα περιεχόμενα των καταχωρητών είναι με την **info registers**/ **i r** \[reg\]. Χωρίς όρισμα εκτυπώνει όλους τους ακέραιους
καταχωρητές με τα περιεχόμενα τους σε δεκαεξαδική και δεκαδική μορφή, αλλιώς τυπώνει μόνο αυτόν που ορίσαμε.

>     (gdb) i r
>     eax            0x0      0
>     ecx            0x4      4
>     edx            0x4014f1ec       1075114476
>     ebx            0x40153234       1075130932
>     esp            0xbffff730       0xbffff730
>     ebp            0xbffff738       0xbffff738
>     esi            0x40014020       1073823776
>     edi            0xbffff794       -1073743980
>     eip            0x804839c        0x804839c
>     eflags         0x386    902
>     cs             0x23     35
>     ss             0x2b     43
>     ds             0x2b     43
>     es             0x2b     43
>     fs             0x0      0
>     gs             0x0      0
>     fctrl          0x37f    895
>     fstat          0x0      0
>     ftag           0xffff   65535
>     fiseg          0x0      0
>     fioff          0x0      0
>     foseg          0x0      0
>     fooff          0x0      0
>     fop            0x0      0
>     mxcsr          0x1f80   8064
>     orig_eax       0xffffffff       -1
>     (gdb) i r edx
>     edx            0x4014f1ec       1075114476
>     (gdb)

Υπάρχει και η εντολή **info all-registers** η οποία τυπώνει όλους τους καταχωρητές ( integer και floating-point και ΜΜΧ και ΧΜΜ για x86).

To πρόβλημα με την εντολή **i r** είναι πως μας επιτρέπει μόνο να δούμε τις τιμές των καταχωρητών, ενώ αρκετά συχνά θέλουμε να τις αλλάξουμε ή να τις
χρησιμοποιήσουμε σε κάποια έκφραση. Στον GDB για κάθε καταχωρήτη υπάρχει μια ψευδο-μεταβλητή της οποία το όνομα αποτελείται από το \'\$\' και το όνομα του
καταχωρήτη πχ \$eax. Ο μηχανισμός αυτός προσφέρει μεγάλη ευελιξία και ευκολία:

>     (gdb) print $eip
>     $1 = (void *) 0x804839c
>     (gdb) set $eip=$eip+1
>     (gdb) print $eip
>     $2 = (void *) 0x804839d
>     (gdb) set $eip--
>     (gdb) print $eip
>     $3 = (void *) 0x804839c

#### Εξετάζοντας τη μνήμη

Η προσπέλαση στη μνήμη γίνεται με την εντολή **x**. Η πλήρης σύνταξη είναι **x/FMT** όπου FMT είναι μια ακολουθία τριών στοιχείων \<repeat
count\>\<size\>\<format\>. To πρώτο ορίζει πόσα αντικείμενα να εκτυπωθούν, το δεύτερο δηλώνει τι μέγεθος θα έχει το κάθε αντικείμενο ( b(byte 1), h(halfword 2)
, w(word 4) ,g(giant 8) και τέλος το format σε τι μορφή να εκτυπωθούν ( o(octal), x(hex), d(decimal), u(unsigned decimal), t(binary), f(float), a(address),
i(instruction), c(char) και s(string). )

Πχ Εκτύπωσε 5 bytes σε οκταδική μορφή αρχίζοντας από τη διεύθυνση main

>     (gdb) x/5bo main
>     0x804838c <main>:       0125    0211    0345    0203    0354

Το ίδιο σε hex

>     (gdb) x/5bx main
>     0x804838c <main>:       0x55    0x89    0xe5    0x83    0xec

Εκτύπωσε 3 λέξεις (4 bytes η κάθε μία) σε δεκαεξαδική μορφή αρχίζοντας από τη διεύθυνση main

>     (gdb) x/3wx main
>     0x804838c <main>:       0x83e58955      0xe48308ec      0x0000b8f0

Εκτύπωσε τις πρώτες δέκα εντολές της main( όχι τις γνωστές δέκα\...)

>     (gdb) x/10i main
>     0x804838c <main>:       push   %ebp
>     0x804838d <main+1>:     mov    %esp,%ebp
>     0x804838f <main+3>:     sub    $0x8,%esp
>     0x8048392 <main+6>:     and    $0xfffffff0,%esp
>     0x8048395 <main+9>:     mov    $0x0,%eax
>     0x804839a <main+14>:    sub    %eax,%esp
>     0x804839c <main+16>:    cmpl   $0x1,0x8(%ebp)
>     0x80483a0 <main+20>:    jg     0x80483c1 <main+53>
>     0x80483a2 <main+22>:    sub    $0x8,%esp
>     0x80483a5 <main+25>:    mov    0xc(%ebp),%eax

Η τελευταία εντολή έχει το ίδιο αποτέλεσμα με την εντολή **disassemble main main+25**.

Συχνά χρειάζεται να εξετάζουμε συνέχεια μια θέση μνήμης και καταντάει κουραστικό να γράφουμε την εντολή **x/FMT** . Σε τέτοιες περιπτώσεις βολεύει η εντολή
**display** που συντάσεται ακριβώς όπως η **x/FMT** και μαζί με κάθε gdb prompt μας εμφανίζει τα δεδομένα που της ζητήσαμε. Ένα πολύ χρήσιμο παράδειγμα της
display είναι το παρακάτω:

>     (gdb) display/5i $eip
>     (gdb) break main
>     Breakpoint 1 at 0x8048392
>     (gdb) r
>     Starting program: /home/alf/projects/magaz/issue1/rce1
>
>     Breakpoint 1, 0x08048392 in main ()
>     2: x/5i $eip
>     0x8048392 <main+6>:     and    $0xfffffff0,%esp
>     0x8048395 <main+9>:     mov    $0x0,%eax
>     0x804839a <main+14>:    sub    %eax,%esp
>     0x804839c <main+16>:    cmpl   $0x1,0x8(%ebp)
>     0x80483a0 <main+20>:    jg     0x80483c1 <main+53>
>     (gdb) ni
>     0x08048395 in main ()
>     2: x/5i $eip
>     0x8048395 <main+9>:     mov    $0x0,%eax
>     0x804839a <main+14>:    sub    %eax,%esp
>     0x804839c <main+16>:    cmpl   $0x1,0x8(%ebp)
>     0x80483a0 <main+20>:    jg     0x80483c1 <main+53>
>     0x80483a2 <main+22>:    sub    $0x8,%esp

Μετά από κάθε **ni** (next instruction, δείτε λίγο παρακάτω) εμφανίζονται αυτόματα οι 5 επόμενες εντολές assembly. Για να εξετάσουμε ποια auto-display έχουμε
στο σύστημα μας γράφουμε info display ενώ για να ακυρώσουμε μια εντολή display χρησιμοποιούμε την **undisplay \[\#num\]** ή **delete display \[\#n\]**.

### [2.3 Εκτελώντας τον κώδικα]{#ss2.3}

Είναι ωραίο να βλέπουμε τον κώδικα του προγράμματος μας και τα δεδομένα του αλλά είναι καλύτερο να μπορούμε και να το εκτελούμε! Για το σκοπό αυτό οι εντολές
που χρειαζόμαστε είναι οι **ni**/**nexti** (next instruction) και **si**/**stepi**. Αυτές λειτουργούν αντίστοιχα με τις **next** και **step** αλλά σε επίπεδο
εντολών assembly και όχι σε επίπεδο γραμμών πηγαίου κώδικα. Οι **nexti** και **stepi** εκτελούν την επόμενη εντολή assembly αλλά η **nexti** δεν ακολουθεί τις
κλήσεις συναρτήσεων.

>     (gdb) display/1i $eip
>     (gdb) ni
>     0x080483ca in main ()
>     2: x/i $eip  
>     0x80483ca <main+62>:       push   DWORD PTR [eax]
>     (gdb) ni
>     0x080483cc in main ()
>     2: x/i $eip  
>     0x80483cc <main+64>:       call   0x8048406 <alf>
>     (gdb) ni
>     0x080483d1 in main ()
>     2: x/i $eip  
>     0x80483d1 <main+69>:       add    esp,0x10
>     (gdb) ni
>     0x080483d4 in main ()
>     2: x/i $eip  
>     0x80483d4 <main+72>:       mov    DWORD PTR [ebp-4],eax
>     (gdb) ni
>     0x080483ca in main ()
>     2: x/i $eip  
>     0x80483ca <main+62>:       push   DWORD PTR [eax]
>     (gdb) ni
>     0x080483cc in main ()
>     2: x/i $eip  
>     0x80483cc <main+64>:       call   0x8048406 <alf>
>     (gdb) si
>     0x08048406 in alf ()
>     2: x/i $eip  
>     0x8048406 <alf>:           push   ebp
>     (gdb) ni
>     0x08048407 in alf ()
>     2: x/i $eip  
>     0x8048407 <alf+1>:         mov    ebp,esp
>     (gdb) ni
>     0x08048409 in alf ()
>     2: x/i $eip  
>     0x8048409 <alf+3>:         sub    esp,0x8
>     (gdb) ni
>     0x0804840c in alf ()
>     2: x/i $eip  
>     0x804840c <alf+6>:         sub    esp,0xc

**Breakpoints-Watchpoints**

Για τα breakpoints και τα watchpoints ισχύουν όσα είχαν γραφτεί στο προηγούμενο τεύχος. Απλώς λόγω έλλειψης συμβόλων χρησιμοποιείται αρκετά η μορφή που περιέχει
απλή διεύθυνση πχ **break \*0x8045333**.

### [2.4 Πληροφορίες για το εκτελέσιμο]{#ss2.4}

Η εντολή **info files** τυπώνει πληροφορίες για το εκτελέσιμο:

>     (gdb) info files
>     Symbols from "/home/alf/projects/magaz/issue1/rce1".
>     Local exec file:
>             `/home/alf/projects/magaz/issue1/rce1', file type elf32-i386.
>             Entry point: 0x8048330
>             0x080480f4 - 0x08048107 is .interp
>             0x08048108 - 0x08048128 is .note.ABI-tag
>             0x08048128 - 0x08048160 is .hash
>             0x08048160 - 0x080481f0 is .dynsym
>             0x080481f0 - 0x0804824e is .dynstr
>             0x0804824e - 0x08048260 is .gnu.version
>             0x08048260 - 0x08048280 is .gnu.version_r
>             0x08048280 - 0x08048290 is .rel.dyn
>             0x08048290 - 0x080482b8 is .rel.plt
>             0x080482b8 - 0x080482cf is .init
>             0x080482d0 - 0x08048330 is .plt
>             0x08048330 - 0x080484ac is .text
>             0x080484ac - 0x080484c7 is .fini
>             0x080484c8 - 0x080484f6 is .rodata
>             0x080494f8 - 0x08049504 is .data
>             0x08049504 - 0x08049508 is .eh_frame
>             0x08049508 - 0x080495d0 is .dynamic
>             0x080495d0 - 0x080495d8 is .ctors
>             0x080495d8 - 0x080495e0 is .dtors
>             0x080495e0 - 0x080495e4 is .jcr
>             0x080495e4 - 0x08049608 is .got
>             0x08049608 - 0x08049610 is .bss
>     (gdb)

Καταρχάς δίνεται το path και το είδος του εκτελέσιμου.\
Αμέσως μετά δίνεται το entry point, δηλαδή η διεύθυνση της πρώτης εντολής που θα εκτελεστεί όταν αρχίσει το πρόγραμμα. **Προσοχή: αυτή συνήθως δεν είναι η
διεύθυνση της main αλλά είναι η αρχή του κώδικα που αρχικοποιεί την libc!**

Όλα τα υπόλοιπα είναι τα sections του ELF και οι διεύθυνσεις μνήμης που καταλαμβάνουν.

### [2.5 Καλώντας συναρτήσεις και ψάχνοντας για σύμβολα]{#ss2.5}

Εδώ θα αναφερθούμε σε δύο αρκετά χρήσιμες εντολές που μάλλον θα ταίριαζαν περισσότερο στο προηγούμενο άρθρο.

Η πρώτη εντολή είναι η **call** η οποία χρησιμοποιείται για να καλέσουμε μια οποιαδήποτε συνάρτηση. Η σύνταξη που χρησιμοποιεί εξαρτάται από την τρέχουσα γλώσσα
και στη C είναι γνωστή η **call func(arg1,arg2,\...)**.

>     bash$ gdb rce1
>     (gdb) call alf("123")
>     evaluation of this expression requires the target program to be active
>     (gdb) break main
>     Breakpoint 1 at 0x80483f0: file rce1.c, line 7.
>     (gdb) r
>     Starting program: /home/alf/magaz/issue1/rce1
>
>     Breakpoint 1, main (argc=1, argv=0xbffff7a4) at rce1.c:7
>     7           if (argc<2) {
>     (gdb) call alf("123")
>     $1 = 123
>     (gdb) call alf("747")
>     $2 = 747
>     (gdb) print $1
>     $3 = 123
>     (gdb) print $+1
>     $4 = 124

Η τιμή που επιστρέφει η συνάρτηση αποθηκεύεται στη μεταβλητή που μας δείχνει ο GDB πχ \$1. Η μεταβλητή \$ περιέχει την τελευταία τιμή που παράχθηκε.

Η επόμενη εντολή είναι η **info functions \[name\]**. Η εντολή αυτή εμφανίζει όλες τις συναρτήσεις που ξέρει ο GDB μαζί με τη διεύθυνση τους (αμέτρητες!). Αν
καθορίσουμε κάποιο όνομα θα εμφανιστούν μόνο οι συναρτήσεις που περιέχουν αυτό το όνομα. Αν και γενικά τα πράγματα είναι απλά, υπάρχουν μερικά σκοτεινά σημεία
που ίσως σας προβληματίσουν.

Για παράδειγμα έστω ότι έχουμε ένα πρόγραμμα που καλεί την fprintf(). Αφου το φορτώσουμε στο GDB έχουμε:

>     (gdb) info functions fprintf
>     All functions matching regular expression "fprintf":
>
>     Non-debugging symbols:
>     0x080482e0  fprintf
>     (gdb) break main
>     Breakpoint 1 at 0x80483f0: file rce1.c, line 7.
>     (gdb) r
>     Starting program: /home/alf/tst
>
>     Breakpoint 1, main (argc=1, argv=0xbffff7a4) at rce1.c:7
>     7           if (argc<2) {
>     (gdb) info functions fprintf
>     All functions matching regular expression "fprintf":
>
>     Non-debugging symbols:
>     0x080482e0  fprintf
>     0x4006e5c0  _IO_vfprintf
>     0x4006e5c0  _IO_vfprintf_internal
>     0x4006e5c0  __GI_vfprintf
>     0x4006e5c0  vfprintf
>     0x40072b40  buffered_vfprintf
>     0x400788f0  _IO_fprintf
>     0x400788f0  __GI_fprintf
>     0x400788f0  fprintf
>     0x4007c8d0  buffered_vfprintf

Αρχικά (πριν εκτελέσουμε το πρόγραμμα) το μόνο σύμβολο fprintf που υπήρχε ήταν στη διεύθυνση 0x080483e0. Η διεύθυνση αυτή ανήκει στο δικό μας πρόγραμμα και
επομένως δεν μπορεί να είναι η αρχή της fprintf()! Στην πραγματικότητα είναι ένα jmp προς την κανονική fprintf(). Αφού τρέξουμε το πρόγραμμα, ο GDB
συνειδητοποιεί πως φορτώθηκαν βιβλιοθήκες και προσθέτει τα σύμβολα των συναρτήσεων στη λίστα του. Μια από αυτές που φορτώθηκε ήταν η libc έτσι προστέθηκε μεταξύ
άλλων το σύμβολο fprintf στη διεύθυνση 0x400788f0 που αποτελεί και τη πραγματική αρχή της συνάρτησης.

>     bash$ gdb tst
>     (gdb) break fprintf
>     Breakpoint 1 at 0x80482e0
>     (gdb) r 
>     Starting program: /home/alf/tst 
>     Breakpoint 1 at 0x400788f6
>
>     Breakpoint 1, 0x400788f6 in fprintf () from /lib/libc.so.6
>     (gdb)

Παρατηρήστε ότι ενώ το αρχικό breakpoint ήταν στη διεύθυνση 0x80482e0 το break έγινε στη διεύθυνση 0x400788f6. Ο GDB αναγνωρίζει ότι το σύμβολο fprintf στη
διεύθυνση 0x80482e0 έχει ειδική σημασία, και όταν φορτωθεί η πραγματική fprintf() ανανεώνει το breakpoint. Περισσότερα για το θέμα στο επόμενο τεύχος όταν
εξετάσουμε το ELF.


### [3. Άλλα χρήσιμα εργαλεία]{#s3}

Παρακάτω παρουσιάζονται εν συντομία δύο πολύ χρήσιμα εργαλεία που υπάρχουν σε κάθε σύγχρονο linux σύστημα. Βασίζονται και τα δύο στο ptrace() system call που
επιτρέπει τον έλεγχο διεργασιών στο linux.

### [3.1 strace]{#ss3.1}

To strace (system call trace) καταγράφει τα system calls ενός προγράμματος. Από default καταγράφει όλα τα syscalls αλλά υπάρχει η δυνατότητα να προσδιοριστούν
μόνο κάποια συγκεκριμένα. Δέχεται πολλές παραμέτρους και ρυθμίσεις αλλά εδώ θα ασχοληθούμε μόνο με τις πιο βασικές (εξάλλου δεν υπάρχει λόγος να επαναλαμβάνουμε
τη manpage!)

Η βασική σύνταξη είναι **strace \[options\] \[-o outputfile\] \[objfile \[args\]\]**.\
Αν δεν καθορίσουμε κάποιο αρχείο για output τα syscalls εμφανίζονται στo stderr.

Χρήσιμες παράμετροι είναι:\
**-e call1,call2,\...** ή **-e trace=call1,call2,\...,callΝ**\
Καθορίζει ποια syscalls να παρακολουθήσει το πρόγραμμα. Αν πριν από κάποιο όνομα υπάρχει το \'!\' σημαίνει να μην παρακολουθηθεί το syscall αυτό. H default τιμή
είναι -e trace=all.\
**-p pid**\
καθορίζει σε ποια διεργασία να \"αγκιστρωθεί\" το πρόγραμμα ώστε να αρχίσει να παρακολουθεί. Προφανώς στην περίπτωση αυτή είναι περιττό να καθοριστεί το
objfile.\
**-i**\
Πριν από κάθε syscall εμφανίζεται η τιμή του IP (instruction pointer) τη στιγμή της κλήσης. Η επιλογή αυτή είναι λιγότερο χρήσιμη από ότι φαίνεται, διότι τα
syscalls καλούνται μέσα από wrapper συναρτήσεις που βρίσκονται σε βιβλιοθήκες, και έτσι οι διευθύνσεις που θα λαμβάνουμε δεν θα είναι και πολύ χρήσιμες.

πχ

>     bash$ strace -e trace=write rce1
>     write(1, "Usage: rce1 <number>\n", 21Usage: rce1 <number>
>     )  = 21

Το παραπάνω είναι λίγο μπερδεμένο διότι το strace αρχίζει να καταγράφει το syscall write στο stderr(που από default είναι η οθόνη), ύστερα εκτυπώνεται το
κείμενο μας και μετά τελειώνει η καταγραφή με την τιμή επιστροφής της write. Αν είχαμε χρησιμοποιήσει το option -ο δε θα υπήρχε πρόβλημα.

>     bash$ strace -o rce1.trace -e trace=write rce1
>     Usage: rce1 <number>
>     bash$ cat rce1.trace
>     write(1, "Usage: rce1 <number>\n", 21)  = 21

Ας δούμε τώρα το πλήρες trace από το αγαπημένο μας rce1.

>     bash$ strace -o rce1.trace rce1
>     Usage: rce1 <number>
>     bash$ cat -n rce1.trace
>          1  execve("./rce1", ["rce1"], [/* 51 vars */]) = 0
>          2  brk(0)                                  = 0x8049598
>          3  open("/etc/ld.so.preload", O_RDONLY)    = -1 ENOENT (No such file or
>     directory)
>          4  open("/etc/ld.so.cache", O_RDONLY)      = 3
>          5  fstat64(3, {st_mode=S_IFREG|0644, st_size=64466, ...}) = 0
>          6  old_mmap(NULL, 64466, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40015000
>          7  close(3)                                = 0
>          8  open("/lib/libc.so.6", O_RDONLY)        = 3
>          9  read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\\\1\000"...,
>     1024) = 1024
>         10  fstat64(3, {st_mode=S_IFREG|0755, st_size=1435624, ...}) = 0
>         11  old_mmap(NULL, 1256740, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
>     0x40025000
>         12  mprotect(0x4014f000, 36132, PROT_NONE)  = 0
>         13  old_mmap(0x4014f000, 20480, PROT_READ|PROT_WRITE,
>     MAP_PRIVATE|MAP_FIXED, 3, 0x12a000) = 0x4014f000
>         14  old_mmap(0x40154000, 15652, PROT_READ|PROT_WRITE,
>     MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40154000
>         15  close(3)                                = 0
>         16  old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
>     -1, 0) = 0x40158000
>         17  munmap(0x40015000, 64466)               = 0
>         18  fstat64(1, {st_mode=S_IFCHR|0700, st_rdev=makedev(136, 0), ...}) = 0
>         19  old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
>     -1, 0) = 0x40015000
>         20  write(1, "Usage: rce1 <number>\n", 21)  = 21
>         21  munmap(0x40015000, 4096)                = 0
>         22  semget(1, 4096, IPC_CREAT|0x40150140|0400) = -1 ENOSYS (Function not
>     implemented)
>         23  _exit(1)                                = ?

**1:** Εδώ καλείται η execve() ώστε να εκτελεστεί το πρόγραμμα μας. Η επόμενη γραμμή είναι πιο ενδιαφέρουσα.

**2:** Η brk() χρησιμοποιείται για να αλλάξει το μέγεθος του data segment. Παίρνει ως παράμετρο το νέο τέλος του data segment και επιστρέφει 0 αν όλα πήγαν καλά
και -1 σε περίπτωση λάθους (όλα αυτά σύμφωνα με την man page που έχει ξεμείνει απο το linux 0.9.11). Εδώ η παράμετρος είναι 0 και η τιμή επιστροφής είναι ένας
μια διεύθυνση. Μόλις μάθαμε ότι η brk(NULL) επιστρέφει το τρέχον τέλος του data segment :)

Τώρα ο dynamic linker αναλαμβάνει δράση.\
**3-4:** Παρατηρούμε μια προσπάθεια να ανοίξουν δύο αρχεία: το \"/etc/ld.so.preload\" και το \"/etc/ld.so.cache\". Το πρώτο περιέχει μια λίστα με το ποιες
βιβλιοθήκες να φορτωθούν πριν από οποιαδήποτε βιβλιοθήκη του συγκεκριμένου εκτελέσιμου και στο δικό μου σύστημα δεν υπάρχει (θα ήταν ύποπτο αν υπήρχε\...). Το
δεύτερο περιέχει μια λίστα με όλες τις βιβλιοθήκες που γνωρίζει ο dynamic linker (δες man ldconfig) και ανοίγει επιτυχώς με file descriptor 3.

**5-7:** Με την fstat ο linker πληροφορείται για το αρχείο που μόλις άνοιξε. Η πληροφορία που τον ενδιαφέρει πιο πολύ είναι το μέγεθος st\_size=64466 (δες man
fstat). Ύστερα το αρχείο γίνεται mapped(αντιστοιχείται) στη μνήμη στη διεύθυνση 0x40015000 (δες man mmap) και το αρχείο κλείνει.

**8-15:** Ο linker βλέπει πως το εκτελέσιμο χρειάζεται τη βιβλιοθήκη libc.so.6. Έχοντας τις πληροφορίες από το προηγούμενο βήμα βρίσκει το path και το ανοίγει.
Ύστερα διαβάζει τα πρώτα 1024 bytes που περιέχουν τον ELF(Executable and Linkable Format) header του αρχείου και αφού επιβεβαιώσει ότι όντως πρόκειται για
shared βιβλιοθήκη φορτώνει τα διάφορα sections της.

**16-17:** Γίνονται map ανώνυμα 4Kbytes και ελευθερώνεται(unmapped) ο χώρος που αντιστοιχεί στο \"/etc/ld.so.cache\".

**18-19:** Λαμβάνονται πληροφορίες για τον file descriptor 1 (stdout) και γίνονται map ανώνυμα άλλα 4Kbytes

**20:** Εδώ γράφεται στον fd 1 το κείμενο μας. Εμείς δεν χρησιμοποιήσαμε την write κατευθείαν αλλά η printf τελικά καλεί την write.

**21-23:** Ελευθερώνεται το block που δεσμεύτηκε στη γραμμή 19, καλείται η semget() η οποία δεν έχει υλοποιηθεί(!) ακόμα στον δικό μου πυρήνα (2.4.20) και το
πρόγραμμα τερματίζει.

### [3.2 ltrace]{#ss3.2}

To ltrace είναι αντίστοιχο με το strace αλλά όπως δηλώνει και το όνομα του (library trace) παρακολουθεί κλήσεις συναρτήσεων από βιβλιοθήκες. Πρόκειται για ένα
αρκετά χρήσιμο πρόγραμμα που δίνει μια εποπτική εικόνα της ροής του προγράμματος. Βέβαια όπως και το strace μας δίνει απλώς μια ακολουθία από συμβάντα και
καθόλου πληροφορίες για τα κομβικά σημεία της διεργασίας (πχ κάποιος έλεγχος).

H σύνταξη είναι : **ltrace \[options\] \[-o outputfile\] \[objfile \[args\]\]**

Χρήσιμες παράμετροι είναι:\
**-e call1,call2,\...**\
Το πρόγραμμα παρακολουθεί μόνο τις call1,call2\... Αν πριν από κάποια συνάρτηση υπάρχει \'!\' τότε να μην παρακολουθηθεί.\
**-p pid**\
Καθορίζει σε ποια διεργασία να \"αγκιστρωθεί\" το πρόγραμμα ώστε να αρχίσει να παρακολουθεί. Προφανώς στην περίπτωση αυτή είναι περιττό να καθοριστεί το
objfile.\
**-i**\
Πριν από κάθε call εμφανίζεται η τιμή του IP (instruction pointer) τη στιγμή της κλήσης. Σε αντίθεση με την strace η επιλογή είναι πολύ χρήσιμη, διότι οι
κλήσεις συναρτήσεων βιβλιοθήκης γίνονται συνήθως κατευθείαν από τον κώδικα που μας ενδιαφέρει και όχι από κάποια μυστική γωνιά κάποιας απέραντης βιβλιοθήκης.\
**-l libfilename**\
Καθορίζει τις συναρτήσεις ποιων βιβλιοθηκών να παρακολουθεί η ltrace. Για περισσότερες από μια βιβλιοθήκες πρέπει να επαναληφθεί το \'-l\' πχ -l lib1 -l lib2
\...

>     πχ
>     bash$ ltrace -orce1.ltrace  -i rce1
>     Usage: rce1 <number>
>     bash$ cat rce1.ltrace
>     [080482fd] __libc_start_main(0x0804838c, 1, 0xbffff784, 0x08048274, 0x08048440
>     <unfinished ...>
>     [080483b4] printf("Usage: %s <number<\n", "rce1")                          
>     = 21
>     [080483c1] exit(1 <unfinished ...>
>     [ffffffff] +++ exited (status 1) +++


### [4. Υλοποίηση των breakpoints]{#s4}

Τα breakpoints, όπως είχαμε πει και στο προηγούμενο τεύχος, είναι σημεία στον κώδικα όπου διακόπτεται η εκτέλεση του προγράμματος και ο έλεγχος επιστρέφει στον
debugger. Όσον αφορά στον τρόπο υλοποίησης τους μπορούν να χωριστούν σε δύο κατηγορίες: τα software και τα hardware.

### [4.1 Software Breakpoints]{#ss4.1}

Είναι το είδος που απαντάται πιο συχνά διότι δεν απαιτεί κάποια υποστήριξη από τον επεξεργαστή. Όταν ορίζουμε ένα software breakpoint σε κάποια διεύθυνση μνήμης
τότε ο debugger, αφού αποθηκεύσει την εντολή που βρίσκεται σε εκείνο το σημείο την αντικαθιστά με μια εντολή trap (software interrupt). Ο debugger έχει
φροντίσει να αποκτήσει τον έλεγχο του trap αυτού. Επομένως, όταν εκτελεστεί η trap ο έλεγχος επιστρέφει στον debugger, ο οποίος επανατοποθετεί τα bytes της
αρχικής εντολής και περιμένει οδηγίες. Αφού προχωρήσουμε στο πρόγραμμα τοποθετείται πάλι η trap, αν πρόκειται για μόνιμο breakpoint. Στους x86 επεξεργαστές ως
trap χρησιμοποιείται η \"int 3\" με opcode 0xCC.

Ας δούμε ένα παράδειγμα:

>     0x8048429       :       0xff 0x75 0xf0              push   DWORD PTR [ebp-16]
>     0x804842c       :       0xff 0x75 0xf4              push   DWORD PTR [ebp-12]
>     0x804842f       :       0xe8 0x8c 0xfe 0xff 0xff    call   0x80482c0 
>     0x8048434       :       0x83 0xc4 0x10              add  esp,0x10

Έστω ότι τοποθετούμε ένα breakpoint στην εντολή call 0x80482c0. Αυτό που συμβαίνει είναι ότι ο debugger αντικαθιστά το πρώτο byte της εντολής με \"0xcc\" αφού
βέβαια σώσει κάπου το 0xe8. Οπότε τώρα έχουμε στην πραγματικότητα:

>     0x804842f       :       0xcc                        int 3
>     0x8048430       :       0x8c 0xfe 0xff 0xff     ... (σκουπίδια)
>     0x8048434       :       0x83 0xc4 0x10                  add  esp,0x10

Τα bytes που απέμειναν από την call (0x8c - 0xff) ίσως να σχηματίζουν μια καινούργια εντολή αλλά πάντως όχι μια που είναι επιθυμητή! Μην περιμένετε την παραπάνω
εικόνα της μνήμης να τη δείτε ποτέ μέσα από τον debugger με τον οποίο έχετε τοποθετήσει το breakpoint. Αυτό διότι ο ίδιος φροντίζει να μας εμφανίζει το
\"αυθεντικό\" περιεχόμενο της μνήμης όταν του το ζητάμε. Πάντως, παρόλο που δε μπορείτε να τα δείτε εύκολα, τα software breakpoints όντως υπάρχουν! Το παρακάτω
πρόγραμμα είναι αρκετό για να πείσει ακόμα και τους πιο \"δύσκολους\" από εσάς:

----------------------------------------------------------------------------------------------------------------------------------------------------------------

    #include <stdio.h>

    int main(void)
    {
        
        if (*((unsigned char *)main+6)==0xcc)
                printf("Software Breakpoint detected at main()!\n");
        else
                printf("No software breakpoint at main()!\n");

        return 0;
    }

----------------------------------------------------------------------------------------------------------------------------------------------------------------

>     bash$ gcc -o bp_test bp_test.c
>     bash$ ./bp_test
>     No software breakpoint at main()!
>     bash$ gdb bp_test
>     (gdb) r
>     Starting program: /home/alf/projects/magaz/issue1/bp_test
>     No software breakpoint at main()!
>
>     Program exited with code 01.
>     (gdb) break main
>     Breakpoint 1 at 0x804832e
>     (gdb) r
>     Starting program: /home/alf/projects/magaz/issue1/bp_test
>
>     Breakpoint 1, 0x0804832e in main ()
>     (gdb) c
>     Continuing.
>     Software Breakpoint detected at main()!
>
>     Program exited with code 01.

Ο λόγος που ο έλεγχος γίνεται στο 7 byte της main() (main+6) και όχι στο πρώτο (main), είναι ότι ο GDB τοποθετεί τα breakpoints μετά από τον [πρόλογο της
συνάρτησης](05_rce2-5.html#c_call).

### [4.2 Hardware Breakpoints]{#ss4.2}

Τα hardware breakpoints βασίζονται στο υλικό και για αυτό ο ακριβής τρόπος υλοποίησης διαφέρει ανάλογα με τον επεξεργαστή. Στην αρχιτεκτονική x86 (386+) μέσα
στον επεξεργαστή υπάρχουν 4 debug registers DR0-DR3. Σε κάθε έναν από αυτούς μπορεί να ανατεθεί ο έλεγχος μιας θέσης μνήμης, ώστε να προκαλεί ένα interrupt όταν
η διεύθυνση μνήμης που τον αφορά διαβαστεί, γραφτεί, διαβαστεί ή γραφτεί ή εκτελεστεί ως μέρος της τρέχουσας εντολής (R, W, RW, X). Στα τρία πρώτα modes έχουμε
λειτουργία watchpoint και πρόκειται για τον μόνο πρακτικό τρόπο υλοποίησης τους. Με software, το μόνο που θα μπορούσαμε να κάνουμε είναι να ελέγχουμε κάθε
εντολή για προσπελάσεις στη μνήμη, διαδικασία **εξαιρετικά** χρονοβόρα. Εκμεταλλευόμενοι το hardware, κάθε προσπέλαση στη μνήμη συγκρίνεται σιωπηλά με τα
περιεχόμενα των DR\'s και αν υπάρξει κάποιο ταίριασμα επεμβαίνει ο debugger. Οι έλεγχοι γίνονται παράλληλα με την υπόλοιπη λειτουργία του επεξεργαστή και για
αυτό δεν υπάρχει καμία καθυστέρηση.

Για να χρησιμοποιήσουμε hardware breakpoints στον GDB αντί για την εντολή **break** χρησιμοποιούμε την **hbreak**. H σύνταξη είναι ακριβώς όμοια με την
**break**.

### [4.3 Hints and Tips - Home-made Traps]{#ss4.3}

Συχνά χρειάζεται να σταματήσουμε ένα κομμάτι κώδικα πριν εκτελεστεί αλλά δεν μπορούμε να το κάνουμε με τη break του GDB διότι πχ ο κώδικας βρίσκεται σε μια
shared βιβλιοθήκη που δεν έχει φορτωθεί ακόμα. Ένας τρόπος να πετύχουμε το σκοπό μας είναι να τοποθετήσουμε μια εντολή trap (0xCC για x86) στο σημείο που
θέλουμε, αφού γράψουμε κάπου πιο byte ήταν πριν εκεί. Αυτό βέβαια θα πρέπει να γίνει στο αρχείο με έναν hex editor. Όταν τρέξει ο επιθυμητός κώδικας θα δούμε
κάτι σαν το παρακάτω:

>     Program received signal SIGTRAP, Trace/breakpoint trap.
>     0x0804835d in function ()
>     (gdb) print $eip$1 = (void *) 0x804835d
>     (gdb) set *(--(char *)($eip))=0x55
>     (gdb) r
>      ...

Αυτό που κάνουμε είναι ουσιαστικά ότι ακριβώς κάνει ο debugger όταν βρει ένα breakpoint που έχουμε τοποθετήσει με την **break**.Η εντολή

>     set *(--(char *)($eip))=0x55

Πιo καθαρά θα μπορούσε να γραφτεί:

>     (gdb) set $eip=$eip-1
>     (gdb) set *(char *)$eip=0x55 ή (gdb) set {char}$eip=0x55

Χρειάζεται να μειώσουμε τον eip, διότι όταν προκληθεί το trap ο έλεγχος επιστρέφει στον GDB με τον eip να δείχνει στην αμέσως επόμενη εντολή. Επομένως,
πηγαίνουμε μια θέση πίσω στη μνήμη και γράφουμε το αυθεντικό byte (εδώ το 0x55, push ebp). Προσοχή στο casting σε (char \*). Είναι απαραίτητο γιατί αλλιώς ο GDB
νομίζει (από default) πως θέλουμε να γράψουμε τον **ακέραιο** 0x55 (0x00000055) και έτσι θα γράψει 4 bytes αντί 1 που θέλουμε εμείς!

>                  


### [5. Χρήσιμες έως **πολύ** χρήσιμες πληροφορίες]{#s5}

### [5.1 The C calling convention]{#ss5.1}

Στο κομμάτι αυτό θα εξετάσουμε τον τρόπο με τον οποίο γίνεται το πέρασμα των παραμέτρων στις συναρτήσεις αλλά και πως υλοποιούνται οι τοπικές μεταβλητές.
Ύστατος σκοπός είναι η εξοικείωση με τον υλοποίηση των συναρτήσεων σε χαμηλό επίπεδο ώστε η μελέτη των assembly listings να είναι γρήγορη και οδηγεί σε ξεκάθαρα
συμπεράσματα.

Υπάρχουν βέβαια διάφορες επιλογές αλλά εδώ θα δούμε την πιο κοινή, η οποία χρησιμοποιείται στα προγράμματα της C (και όχι μόνο). Η κλήση μιας συνάρτησης έχει ως
αποτέλεσμα τη μεταφορά του ελέγχου σε κάποιο αυθαίρετο κομμάτι κώδικα. Τα μεγάλα ερωτήματα που τίθενται είναι τα εξής:

-   1\. πως ξέρει αυτό το κομμάτι που βρίσκονται οι παράμετροι που περιμένει;
-   2.που αποθηκεύει τις τοπικές μεταβλητές;

Μια πρώτη προσέγγιση θα ήταν να παίρνει τα δεδομένα του (παραμέτρους και τοπικές μεταβλητές) από συγκεκριμένες απόλυτες διευθύνσεις μνήμης. Όλα ωραία και καλά
μέχρι να χρειαστεί να υλοποιήσουμε αναδρομικές συναρτήσεις (συναρτήσεις που καλούν τον εαυτό τους). Για παράδειγμα η f η οποία εκτυπώνει τους αριθμούς από το 1
μέχρι το x:

>     void f(int x)
>     {       
>         if (x>1)
>             f(x-1);
>         printf("%d ",x);
>     }

και έστω πως η συνάρτηση περιμένει την παράμετρο x στη διεύθυνση 100 (τι πρωτότυπους αριθμούς που χρησιμοποιώ!)

Αν έχουμε την κλήση f(2) εμείς περιμένουμε το αποτέλεσμα \"1 2\". Ας δούμε πιο αναλυτικά τι όντως θα συμβεί: Όταν κληθεί για πρώτη φορά η f όλα είναι όπως
πρέπει, η διεύθυνση 100 περιέχει το αρχικό x (το 2). Το 2 είναι μεγαλύτερο από το 1 οπότε καλείται η f(x-1) δηλαδή η f(1). H διεύθυνση 100 περιέχει τώρα τον
αριθμό 1. Το τρέχον x δεν είναι μεγαλύτερο του 1 οπότε απλώς εκτελείται η printf και εκτυπώνεται το \"1\". Η συνάρτηση f(1) επιστρέφει και εκτελείται η printf η
οποία εκτυπώνει \... πάλι \"1\". Η προηγούμενη τιμή του x (το 2) έχει χαθεί :(

Η μαγική λέξη για την αποφυγή τέτοιων προβλημάτων είναι ο σωρός (stack). Κάθε πρόγραμμα διατηρεί το δικό του σωρό, ο οποίος αρχίζει από υψηλές διευθύνσεις και
μεγαλώνει προς της χαμηλές. Η σύμβαση της C για την κλήση συναρτήσεων λέει πως οι παράμετροι \"σπρώχνονται\" στο σωρό από τα δεξιά προς τα αριστερά. Επίσης η
συνάρτηση που έκανε την κλήση είναι υπεύθυνη για να καθαρίσει τον σωρό (να τον φέρει στην αρχική κατάσταση). Για παράδειγμα η κλήση της συνάρτησης f(x,y,z)
μεταφράζεται σε:

>     push z
>     push y
>     push x
>     call f       -------> f: ...
>                              ...
>                              ret
>     add esp,12     (4bytes * 3 παραμέτρους)        

![](/33/img/stack01.png)

Οι τοπικές μεταβλητές αποθηκεύονται και αυτές στο σωρό σε χώρο που δεσμεύεται μετά τη διεύθυνση επιστροφής της συνάρτησης. Αυτό γίνεται απλά με την μείωση του
stack pointer esp (δείκτη στην \"κορυφή\" του σωρού) κατά τόσες θέσεις όσες τα bytes που χρειαζόμαστε για τις τοπικές μεταβλητές.

![](/33/img/stack02.png)

Για να προσπελάσουμε κάποιο δεδομένο χρησιμοποιούμε τον esp και τη σχετική απόσταση του από αυτόν. Για παράδειγμα η τελευταία τοπική μεταβλητή (σε σχέση με τη
σειρά που τις έχουμε δηλώσει στον κώδικα) βρίσκεται στη διεύθυνση esp+0.Το πρόβλημα με το παραπάνω σχέδιο είναι ότι κανείς δεν εγγυάται πως ο esp δεν θα αλλάξει
τιμή κατά τη διάρκεια της συνάρτησης. Για παράδειγμα αν εκτελεστεί μία εντολή push eax, η τελευταία τοπική μεταβλητή είναι πια στη θέση esp+4 και όχι esp+0.
Έτσι ο compiler πρέπει να φροντίσει να ακολουθεί τις αλλαγές και να παράγει σωστά offsets για τις τοπικές μεταβλητές.

![](/33/img/stack03.png)

Μια πιο βολική προσέγγιση χρησιμοποιεί την έννοια του \"πλαισίου\". Με κάθε κλήση συνάρτησης δημιουργείται στο σωρό ένα \"πλαίσιο\" (frame) που περιέχει τα
δεδομένα της συγκεκριμένης κλήσης (παραμέτρους, τοπικές μεταβλητές και διεύθυνση επιστροφής) και επίσης τη διεύθυνση του πλαισίου της προηγούμενης συνάρτησης
(αυτή που κάλεσε την τρέχουσα). Μέσα σε κάθε πλαίσιο ο τρόπος πρόσβασης στα τοπικά δεδομένα είναι ανεξάρτητος από τις αλλαγές του δείκτη του σωρού. Η δημιουργία
του πλαισίου απαιτεί 4 μικρές αλλαγές σε σχέση με τη προηγούμενη προσέγγιση:

-   1.Ένας καταχωρητής δεσμεύεται καθολικά για να συγκρατεί την τρέχουσα διεύθυνση πλαισίου. Στους x86 αυτός είναι ο ebp.
-   2.Πριν τη δέσμευση χώρου για τις τοπικές μεταβλητές αποθηκεύεται στο σωρό η διεύθυνση του προηγούμενου πλαισίου.
-   3.Μετά το (1) η διεύθυνση που περιέχει ο esp (κορυφή του σωρού) γίνεται η διεύθυνση του τρέχοντος πλαισίου και αποθηκεύεται στον ebp.
-   4.Πριν την επιστροφή της συνάρτησης επανατοποθετείται στον ebp η διεύθυνση του προηγούμενου πλαισίου.

Σχηματικά:

![](/33/img/stack04.png)

Τώρα σε κάθε συνάρτηση ο κώδικας για την προσπέλαση των τοπικών δεδομένων είναι ο ίδιος. Αν υποθέσουμε πως έχουμε επεξεργαστή και λειτουργικό 32-bit (πχ linux
:) ) τότε η πρώτη παράμετρος της συνάρτησης βρίσκεται στη θέση ebp+8, η δεύτερη στην ebp+12 κτλ Ομοίως η πρώτη τοπική μεταβλητή βρίσκεται στη θέση ebp-4, η
δεύτερη στη θέση ebp-8.Αυτό ισχύει ακόμα και όταν οι παράμετροι και οι τοπικές μεταβλητές είναι πιο μικροί από 4 bytes (πχ char). O compiler προτιμά να
σπαταλήσει λίγη μνήμη για λόγους ομοιογένειας στον παραγόμενο κώδικα αλλά κυρίως για λόγους απόδοσης, αφού με αυτόν τον τρόπο όλα τα δεδομένα είναι
ευθυγραμμισμένα (aligned) σε όρια των 4bytes (ανοίξτε κάποιο βιβλίο αρχιτεκτονικής υπολογιστών για να μάθετε γιατί\...). Βέβαια, υπάρχουν και προφανείς
εξαιρέσεις όταν για παράδειγμα έχουμε \"δεδομένα\" μεγαλύτερα των 4 bytes όπως structs.

Οι περισσότεροι compilers δίνουν επιλογή πιο από τους δύο τρόπους να χρησιμοποιήσουν. Ο gcc χρησιμοποιεί πλαίσια ως default επιλογή και με το flag
\"-fomit-frame-pointer\" προσπαθεί να το αποφύγει όπου γίνεται. Από το info:

>     -fomit-frame-pointer     
>          Don't keep the frame pointer in a register for functions that
>          don't need one. This avoids the instructions to save, set up and
>          restore frame pointers; it also makes an extra register available
>          in many functions.  *It also makes debugging impossible on some     
>          machines.*

Mια συνάρτηση που χρησιμοποιεί frames τυπικά αρχίζει με την ακολουθία: []{#c_call}

>     push ebp
>     mov ebp,esp         ; Function prologue
>     sub esp, M

και τελειώνει:

>     mov esp, ebp
>     pop ebp             ; Function epilogue
>     ret
>
>     ή
>
>     leave           
>     ret

### [5.2 System Calls]{#ss5.2}

Τα σύγχρονα λειτουργικά συστήματα που σέβονται τον εαυτό τους, φροντίζουν να ξεχωρίζουν το \"χώρο\" του πυρήνα (kernel space) από το \"χώρο\" τον χρηστών (user
space). Αυτό γίνεται ώστε να μη μπορεί οποιοσδήποτε τυχαίος χρήστης να πειράξει τον πυρήνα(ή να εκτελεί κώδικα του πυρήνα αυθαίρετα) και να θέσει σε κίνδυνο την
ασφάλεια του συστήματος. Ο χωρισμός αυτός υλοποιείται με τη χρήση μηχανισμών που προσφέρει ο εκάστοτε επεξεργαστής (πχ paging, segmentation).

Βέβαια, με κάποιο τρόπο πρέπει οι εφαρμογές να επικοινωνούν με τον πυρήνα για διάφορες εργασίες (πχ Ι/Ο). Η λύσεις είναι τα λεγόμενα call gates (όχι colgates,
αυτά είναι οδοντόκρεμες\...) και τα software interrupts. Και τα δύο έχουν ως σκοπό να ορίσουν διακριτά σημεία εισόδου στον πυρήνα. Μπορείτε να τα σκεφτείτε ως
\"gateways\" για το τοπικό δίκτυο του πυρήνα.

Στο linux χρησιμοποιούνται τα call gates για εκτελέσιμα που έρχονται από άλλα λειτουργικά πχ solaris και το software interrupt 0x80 για native εφαρμογές. Στο
κείμενο αυτό θα ασχοληθούμε μόνο με την δεύτερη τεχνική (για την πρώτη θα έπρεπε πρώτα να αναφερθεί όλος ο μηχανισμός των descriptors στους x86). Το interrupt
0x80 όταν κληθεί μεταφέρει τον έλεγχο στον πυρήνα, μαζί με πληροφορίες για την εργασία που πρέπει να εκτελέσει.

Κατά την κλήση ενός syscall (για την αρχιτεκτονική x86) στον eax υπάρχει ο αριθμός του syscall και στους ebx, ecx, edx, esi, edi, ebp(πυρήνες 2.4 και πάνω) οι
μέχρι έξι παράμετροι που δέχεται το συγκεκριμένο syscall. Έτσι μια τυπική κλήση είναι:

>     mov ebx, 0
>     mov eax, 1  ; syscall 1: exit
>     int 0x80    

Φυσικά, επειδή το να γράφουμε τέτοιο κώδικα κάθε φορά που θέλουμε κάτι από τον πυρήνα δεν είναι και πολύ ευχάριστο, η libc έχει φροντίσει να δημιουργήσει τις
αντίστοιχες wrapper συναρτήσεις. Έτσι αντί για το παραπάνω εμείς αρκεί να γράφουμε exit(0).


### [6. Hands-on Παράδειγμα]{#s6}

Έστω ότι μια μέρα πέφτει στα χέρια σας το παρακάτω εκτελέσιμο : [rce2.bz2 (1.7k)](rce2.bz2)

Όλο χαρά το εκτελείτε:

>     bash$ rce2
>     Say the password: sesame
>     What???
>     bash$ rce2
>     Say the password: kuku
>     What???

Ποιο να είναι άραγε το μυστικό password;

Ας ετοιμαστούμε λοιπόν για αντιμετωπίσουμε ατελείωτα listing με εκατομμύρια γραμμές ακατανόητου κώδικα! Η ας δοκιμάσουμε κάτι πιο απλό:

>     bash$ strings rce2
>     ...

Η **strings** τυπώνει όλες τις εκτυπώσιμες ASCII ακολουθίες που υπάρχουν στο εκτελέσιμο και έχουν μήκος πάνω από 4 χαρακτήρες (default).

Μέσα στη λίστα με τα strings θα παρατηρήσετε κάποιο πιο ενδιαφέρον από τα υπόλοιπα :) Σπάνια βέβαια συμβαίνει να υπάρχουν plain-text κωδικοί μέσα στο εκτελέσιμο
αλλά δε χάνουμε τίποτα να δοκιμάσουμε!

Για εκπαιδευτικούς σκοπούς, θεωρήστε ότι η προηγούμενη διαδικασία δε απέδωσε καρπούς. Ας δούμε τι μπορούμε να μάθουμε για τη ροή του προγράμματος.

>     bash$ ltrace -i -o rce2.ltr rce2
>     Say the password: sesame
>     What???
>     bash$ cat rce2.ltr
>     [080483b5] __libc_start_main(0x0804851c, 1, 0xbffff784, 0x0804830c, 0x08048594
>     <unfinished ...>
>     [080484d5] printf("%s: ", "Say the password")                               =
>     18
>     [080484e1] fflush(0x40150340)                                               = 0
>     [080484f5] fgets("sesame\n", 20, 0x401501e0)                                =
>     0xbffff700
>     [0804849c] isspace(10, 0x40153234, 0xbffff700, 0xbffff784, 0xbffff6e8)      =
>     8192
>     [0804849c] isspace(101, 0x40153234, 0xbffff700, 0xbffff784, 0xbffff6e8)     = 0
>     [08048557] puts("What???")                                                  = 8
>     [ffffffff] +++ exited (status 0) +++

Μόλις αποκτήσαμε δύο σπουδαίες πληροφορίες.\
Κοιτάξτε καλά τη \_\_libc\_start\_main().\
Συνεχίστε να την κοιτάζετε.\
H \_\_libc\_start\_main(), εκτός των άλλων, φροντίζει να κληθεί και το δικό μας κυρίως πρόγραμμα.\
Κοιτάξτε λίγο ακόμα\...\
H \_\_libc\_start\_main() πρέπει να γνωρίζει που βρίσκεται ο δικός μας κώδικας. Επομένως\...\
Για να σας βγάλω από την αγωνία, σας λέω πως η πρώτη παράμετρος της \_\_libc\_start\_main() πρόκειται για τη διεύθυνση της main (0x0804851c)!

Αυτή η πρώτη πληροφορία οδηγεί στη δεύτερη. Παρατηρήστε ότι όλες οι διευθύνσεις μετά την \_\_libc\_start\_main() και μέχρι πριν την puts() είναι μικρότερες από
την αρχή της main(). Άρα είναι ασφαλές να υποθέσουμε πως δεν ανήκουν σε αυτή αλλά σε κάποια άλλη συνάρτηση.

Το τρίτο πράγμα που μάθαμε, είναι ότι στη διεύθυνση 0x08048557 έχει ήδη αποφασιστεί αν το password μας είναι σωστό ή όχι.

Ας χρησιμοποιήσουμε το βαρύ πυροβολικό\...

>     bash$ gdb rce2
>     (no debugging symbols found)...(gdb) break main
>     Function "main" not defined.
>     (gdb)

Ουπς. Το εκτελέσιμο δεν περιέχει σύμβολα αλλά εμείς ξέρουμε τη διεύθυνση της main()!

>     (gdb) break *0x804851c
>     Breakpoint 1 at 0x804851c
>     (gdb) r
>     Starting program: /home/alf/projects/magaz/issue1/rce2
>     (no debugging symbols found)...
>     Breakpoint 1, 0x0804851c in printf ()
>     (gdb) x/30i $eip
>     0x804851c <printf+408>: push   ebp
>     0x804851d <printf+409>: mov    ebp,esp
>     0x804851f <printf+411>: push   edi
>     0x8048520 <printf+412>: push   esi
>     0x8048521 <printf+413>: sub    esp,0x20
>     0x8048524 <printf+416>: and    esp,0xfffffff0
>     0x8048527 <printf+419>: push   esi
>     0x8048528 <printf+420>: push   0x13
>     0x804852a <printf+422>: lea    esi,[ebp-40]
>     0x804852d <printf+425>: push   esi
>     0x804852e <printf+426>: push   0x80485bd
>     0x8048533 <printf+431>: call   0x80484bc <printf+312>
>     0x8048538 <printf+436>: mov    edi,0x80485ce
>     0x804853d <printf+441>: mov    ecx,0xb
>     0x8048542 <printf+446>: cld
>     0x8048543 <printf+447>: add    esp,0x10
>     0x8048546 <printf+450>: repz cmps ds:[esi],es:[edi]
>     0x8048548 <printf+452>: jne    0x8048564 <printf+480>
>     0x804854a <printf+454>: sub    esp,0xc
>     0x804854d <printf+457>: push   0x80485d9
>     0x8048552 <printf+462>: call   0x8048354 <puts>
>     0x8048557 <printf+467>: add    esp,0x10
>     0x804855a <printf+470>: lea    esp,[ebp-8]
>     0x804855d <printf+473>: pop    esi
>     0x804855e <printf+474>: xor    eax,eax
>     0x8048560 <printf+476>: pop    edi
>     0x8048561 <printf+477>: leave
>     0x8048562 <printf+478>: ret
>     0x8048563 <printf+479>: nop
>     0x8048564 <printf+480>: sub    esp,0xc

O GDB νομίζει πως βρισκόμαστε 408 bytes από την αρχή της printf για τους [γνωστούς λόγους](05_rce2-2.html#gdb_asm). Πριν αρχίσουμε σαν παλαβοί να κάνουμε single
step ας δούμε τι μπορούμε να συνάγουμε από το listing.

    push   ebp
    mov    ebp,esp
    push   edi
    push   esi

Καταρχάς η main είναι [frame-based](05_rce2-5.html#c_call) κάτι που φαίνεται από το γνώριμο πρόλογο. Επίσης σώζονται στο σωρό οι καταχωρητές esi και edi ώστε να
μπορούν να ανακτηθούν οι τιμές τους πριν το τέλος της συνάρτησης. Το γιατί γίνεται αυτό πρόκειται για μια εσωτερική υπόθεση του compiler (o gcc διατηρεί τους
ebx, esi και edi κατά τις κλήσεις διότι τους χρησιμοποιεί για δικά του θέματα (πχ προσωρινή αποθήκευση τιμών).

    sub    esp,0x20
    and    esp,0xfffffff0

Μετά δεσμεύεται χώρος στο σωρό για 0x20 bytes και επίσης ο esp μειώνεται(πιθανότατα) και άλλο ώστε να έρθει σε όριo των 16 bytes. Η όλη διαδικασία είναι
αποτέλεσμα του optimization και δεν είναι απαραίτητο πως το πρόγραμμα θα χρησιμοποιήσει όλη τη μνήμη που δεσμεύτηκε τελικά.

    push   esi <--- ??
    push   0x13
    lea    esi,[ebp-40]
    push   esi
    push   0x80485bd
    call   0x80484bc <printf+312>
    ...
    add    esp,0x10

Ακολουθεί ένα μυστηριώδες \"push esi\" και ύστερα μια κλασική κλήση συνάρτησης. Η συνάρτηση δέχεται τρεις παραμέτρους: func\_0x804845c( 0x80485bd, 0x13,
ebp-40). H τελευταία παράμετρος είναι η διεύθυνση μιας τοπικής μεταβλητής, αφού έχει αρνητικό offset από τον ebp. Το αναμενόμενο \"add esp, X\" (διόρθωση του
σωρού) βρίσκεται λίγες γραμμές πιο κάτω. Ο λόγος που δε βρίσκεται αμέσως μετά την call, είναι ότι ο gcc αποφάσισε να αλλάξει τη σειρά των εντολών για λόγους
optimization (έχει να κάνει με τα pipelines του pentium). Όλα εντάξει;

Ελπίζω να μην απαντήσατε \"ναι\"! Κάτι δεν πάει καλά σε όσα έχω πει ως τώρα: γιατί δέχτηκα με τόση σιγουριά πως η συνάρτηση δέχεται τρεις παραμέτρους, ενώ όχι
μόνο γίνονται τέσσερα push πριν από αυτή αλλά κυρίως, ο σωρός διορθώνεται κατά 0x10 = 4\*4 bytes (4 bytes για κάθε παράμετρο). Λοιπόν, εκτός από το γεγονός ότι
εγώ έγραψα το πρόγραμμα και το ξέρω :), υπάρχει ένας επιπλέον λόγος. Όταν γίνεται το πρώτο \"push esi\", ο esi δεν έχει αρχικοποιηθεί μέσα στη main() και έτσι
έχει μια άγνωστη τιμή. Γιατί να περάσουμε σε μια συνάρτηση μια παράμετρο με άγνωστη τιμή;

Η απάντηση για ακόμα μια φορά είναι το optimization (περιττό να σας πω ότι το πρόγραμμα έγινε compile με -Ο2). Ο compiler θέλει να κρατάει τον esp σε
διευθύνσεις πολλαπλάσιες των 16 bytes! Το κόστος προσπέλασης σε μη aligned διευθύνσεις είναι τόσο σημαντικό, ώστε ο gcc εισάγει dummy εντολές για να το
αποφύγει!

    mov    edi,0x80485ce
    mov    ecx,0xb
    cld
    ...
    repz cmps ds:[esi],es:[edi]
    jne    0x8048564 <printf+480> 

Εδώ στον edi φορτώνεται μια διεύθυνση μνήμης και στον edi η τιμή 11. Μετά \"καθαρίζεται\" το direction flag. Ακολουθεί η εντολή \"repz cmps
ds:\[esi\],es:\[edi\]\", η οποία με λίγα λόγια λέει: όσο τα bytes που βρίσκονται στις διευθύνσεις που δείχνουν esi και edi είναι ίσα και ο ecx δεν είναι 0
αύξησε (αν το direction flag είναι 0/clear) τους esi και edi κατά ένα byte και έλεγξε ξανά (η μαγεία των CISC επεξεργαστων\...). Ουσιαστικά κάνει ακριβώς την
ίδια δουλειά με μια κλήση strncmp(esi,edi,ecx), ελέγχει αν τα πρώτα \#ecx bytes δύο string που αρχίζουν στις διευθύνσεις esi και edi είναι ίσα.

Ωραία, ξέρουμε την τιμή του edi αλλά ο esi τη τιμή έχει; Λίγο πιο πάνω υπάρχει η \"lea esi,\[ebp-40\]\" και επειδή ξέρουμε ότι ο gcc φροντίζει να μην αλλάζει ο
esi από συναρτήσεις, είμαστε σίγουροι ότι έχει ακόμα την ίδια τιμή.

Για να συνοψίσουμε, το πρόγραμμα καλεί μια συνάρτηση της οποίας μια παράμετρος είναι η διεύθυνση μιας τοπικής μεταβλητής (ebp-40) και μετά συγκρίνει τα bytes
που βρίσκονται εκεί με κάποια άλλα που βρίσκονται σε μια σταθερή θέση. Δε ξέρω τι λέτε εσείς αλλά εμένα μου φαίνεται πως εδώ γίνεται ο έλεγχος του password!

Η επόμενη εντολή είναι η jne (jump if not equal/zero). Αν η σύγκριση είναι επιτυχής τότε το zero flag έχει ενεργοποιηθεί από το προηγούμενο βήμα και έτσι
**δεν** ακολουθούμε το άλμα. Αν το password είναι λάθος το ZF=0 και το άλμα γίνεται.

Για να δούμε ποίο είναι το password:

>     (gdb) break *0x8048546
>     Breakpoint 2 at 0x8048546
>     (gdb) c
>     Continuing.
>     Say the password: sesame
>
>     Breakpoint 2, 0x08048546 in printf ()
>     (gdb) x/5i $eip
>     0x8048546 <printf+450>: repz cmps ds:[esi],es:[edi]
>     0x8048548 <printf+452>: jne    0x8048564 <printf+480>
>     0x804854a <printf+454>: sub    esp,0xc
>     0x804854d <printf+457>: push   0x80485d9
>     0x8048552 <printf+462>: call   0x8048354 <puts>
>     (gdb) x/s $esi
>     0xbffff720:      "sesame"
>     (gdb) x/s $edi
>     0x80485ce <_IO_stdin_used+26>:   .......... xe xe!

Η παραπάνω τεχνική, όπου βρίσκουμε ένα σωστό password/serial εντοπίζοντας το σημείο που γίνεται η σύγκριση με αυτό που έχουμε εισάγει εμείς, λέγεται
**password/serial fishing**

Εντάξει, μάθαμε το password, γιατί όμως να σταματήσουμε εδώ; Γιατί να μην πειράξουμε το πρόγραμμα ώστε να δέχεται ως σωστό κάθε password; Για να το πετύχουμε,
αρκεί να μην ακολουθούμε ποτέ το άλμα. Ξέρουμε ότι η jne (σε αυτή τη μορφή) καταλαμβάνει στη μνήμη 2 bytes, διότι η επόμενη εντολή αρχίζει δύο bytes πιο μετά.

>     (gdb) x/2b 0x8048548
>     0x8048548 <printf+452>: 0x75    0x1a

Το 0x75 είναι το opcode της εντολής ενώ το 0x1a η (προσημασμένη) απόσταση του άλματος. Αν γίνει το άλμα ο έλεγχος θα μεταφερθεί 0x1a bytes από το τέλος της
εντολής(αρχή της επόμενης), εδώ 0x804854a + 0x1a = 0x8048564.

Για να πετύχουμε το σκοπό μας, αρκεί να αντικαταστήσουμε τα δύο αυτά bytes με nop (no operation, opcode 0x90). Φυσικά δεν έχει νόημα να το κάνουμε αυτό μόνο στη
μνήμη αλλά στο image του εκτελέσιμου που βρίσκεται στο αρχείο. Το πρόβλημα είναι να εντοπίσουμε σε ποιο σημείο του αρχείου βρίσκεται ο κώδικας που θέλουμε να
πειράξουμε. Ο ELF header έχει όλες τις πληροφορίες που χρειαζόμαστε αλλά αφού δεν έχουμε αναφερθεί ακόμα σε αυτόν θα κάνουμε κάτι άλλο: θα ψάξουμε το αρχείο για
να βρούμε την αρχική ακολουθία από bytes. Υπάρχει περίπτωση η ίδια ακολουθία να υπάρχει σε πολλά σημεία και πρέπει να είμαστε σίγουροι πως πειράζουμε το σωστό.
Για αυτό χρειαζόμαστε αρκετά bytes γύρω από την εντολή (το context).

>     (gdb) x/10b 0x8048548-5
>     0x8048543 <printf+447>: 0x83    0xc4    0x10    0xf3    0xa6    0x75   
>     0x1a    0x83
>     0x804854b <printf+455>: 0xec    0x0c

Αν ψάξετε για αυτά τα bytes στο αρχείο(με έναν hexeditor πχ του mc) θα τα βρείτε μόνο μια φορά και το offset του 0x75 0x1a είναι 0x548. Αντικαταστήστε τα δύο
αυτά bytes με 0x90 0x90.

>     bash$ ./rce2
>     Say the password: qrwrwr
>     Hooray!
>     bash$ ./rce2
>     Say the password: sdfeg4453
>     Hooray!

Συγχαρητήρια, μόλις \"σπάσατε\" το πρόγραμμα!


### [7. Πρόκληση]{#s7}

### [7.1 Προηγούμενη πρόκληση - Λύση και Hall Of Fame]{#ss7.1}

Στην προηγούμενη πρόκληση ο σκοπός ήταν να βρείτε ποιος κωδικός αντιστοιχεί στο όνομα σας. Το μεγάλο πρόβλημα που είχα ήταν ότι για να υπάρξει source listing
πρέπει εκτός από το compilation με το -g να είναι διαθέσιμο και το αντίστοιχο source αρχείο. Θα μπορούσα απλώς να σας το δώσω και να σας προτρέψω να μην το
κοιτάξετε. Κάτι μου λέει όμως ότι πολλοί δε θα μπορούσαν να αντισταθούν στο πειρασμό ;) Για αυτό το λόγο το κυρίως αρχείο είναι απλώς ένα container που περιέχει
τόσο το εκτελέσιμο challenge όσο και τον κώδικα του (στοιχειωδώς κρυπτογραφημένο με xor). Κατά την εκτέλεση τα κάνει dump σε δύο κρυφά αρχεία(\".ch0src\" και
\".alfch0\") στον τρέχοντα κατάλογο και τρέχει το \".alfch0\" ή τον gdb. Τα αρχεία αυτά διαγράφονται μόλις τελειώσει το πρόγραμμα.

Το challenge αυτό καθεαυτό είναι σχετικά απλό, για αυτό και άλλαξα τον πηγαίο κώδικα ώστε να έχει ανούσια ονόματα μεταβλητών και συναρτήσεων. Αρχικά προτρέπει
τον χρήστη για το όνομα και τον κωδικό (συνάρτηση \"f\"), και μετά παράγει δύο αριθμούς, έναν για το όνομα(συνάρτηση \"f1\") και έναν για τον κωδικό(συνάρτηση
\"f45\"). Aν οι δύο αριθμοί συμπίπτουν και το μήκος το ονόματος και του κωδικού είναι μη μηδενικά τότε όλα ΟΚ!

Η συνάρτηση f1 περιέχει μια πιθανώς one-way hash function (σημ: δεν έχει αποδειχτεί ότι τέτοιες συναρτήσεις υπάρχουν) ενώ η f45 είναι σαφώς
αντιστρέψιμη(υπολογιστικά πάντα). Αν και η f45 ήταν δύσκολα αντιστρέψιμη, τότε η πρόκληση θα ήταν πρακτικά άλυτη. Για όσους αρέσκονται στoυς τύπους:

Ν=f1(name)\
P=f45(pass)

Εμείς γνωρίζουμε τo name, την f1(), την f45() και μπορούμε να υπολογίσουμε το Ν. Το πρόβλημα είναι να βρούμε το pass ώστε το P να είναι ίσο με το N.

Η f45() είναι:

>     long int f45(char *s,int l)
>     {
>         unsigned long int h;
>
>         h=strtoul(s,NULL,16);
>         if (h!=0) {
>             h^=0x55555555;
>             if (h&1)
>                 h^=0x00badbad;
>             else
>                 h^=0x00dabdab;
>         }
>         return h;
>     }

Η αντιστρεψιμότητα(υπολογιστική) της f45() βασίζεται στο γεγονός ότι η xor είναι συμμετρική και εδώ έχουμε μόνο xor. Επίσης με το if(h&1) {\...} υπάρχει
κίνδυνος να κάνουμε την f45() μη αντιστρέψιμη(μαθηματικά) αλλά οι τιμές είναι επιλεγμένες ώστε να μη συμβαίνει αυτό. Βέβαια η μαθηματική μη αντιστρεψιμότητα δεν
είναι πρόβλημα, απλώς θα υπήρχαν περισσότεροι από ένας σωστοί κωδικοί για κάθε όνομα.

Επομένως η f\_45() (αντίστροφη):

>     unsigned long f_45(unsigned long h)
>     {
>         unsigned long r;
>        
>         r=h;
>
>         if (r!=0) {
>             r^=0x55555555;
>             if (r&1)
>                 r^=0x00badbad;
>             else
>                 r^=0x00dabdab;
>         }
>         
>         return r;
>     }

**Hall Of Fame**

Συγχαρητήρια στους:

1\. Λαμπής Μιχαήλ\
2. Γιώργος Πρέκας\
3. Αρχισυντάκτης (\...με ανάγκασε να τον συμπεριλάβω στο hall of fame!)

Για τις δωρεάν συνδρομές ενοχλείστε τον αρχισυντάκτη :)

Ο κώδικας του προηγούμενου challenge: [magaz-ch0-src.tar.bz2 (15k)](magaz-ch0-src.tar.bz2)

### [7.2 Πρόκληση \#1]{#ss7.2}

Αυτή τη φορά τα πράγματα είναι κάπως πιο πολύπλοκα. Το εκτελέσιμο δεν περιέχει debugging πληροφορίες. Σκοπός είναι το σύστημα να σας πει ότι το authentication
έγινε με επιτυχία. Καλή εξερεύνηση\...

Το εκτελέσιμο: [challenge1.bz2 (6.3k)](challenge1.bz2)

Όσοι επιθυμούν ας μου στείλουν ένα mail εξηγώντας συνοπτικά πως λειτουργεί το πρόγραμμα και τα δεδομένα-απαντήσεις. Αν κάποιος έχει όρεξη ας φτιάξει και έναν
key generator! Ως συνήθως όσοι τα καταφέρουν θα μπουν στο επόμενο Hall Of Fame!

Στείλτε σχόλια, διορθώσεις, προσθήκες στο alf82 at freemail dot gr.

