Reverse Engineering σε περιβάλλον Linux, Μέρος 1

1. Εισαγωγή

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

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

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

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

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

7. Πρόκληση

[1. Εισαγωγή]

Το πρώτο μέρος του άρθρου (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]

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

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

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

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

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

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

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

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

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

Οι εντολές:

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

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

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

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

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

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

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

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

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

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

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

[2.2 Εξετάζοντας τα δεδομένα]

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

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

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

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

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

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

Η προσπέλαση στη μνήμη γίνεται με την εντολή 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

Το ίδιο σε hex

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

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

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

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

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

[2.3 Εκτελώντας τον κώδικα]

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

Breakpoints-Watchpoints

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

[2.4 Πληροφορίες για το εκτελέσιμο]

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

Καταρχάς δίνεται το path και το είδος του εκτελέσιμου.

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

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

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

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

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

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

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

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

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

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

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

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

[3.1 strace]

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 συναρτήσεις που βρίσκονται σε βιβλιοθήκες, και έτσι οι διευθύνσεις που θα λαμβάνουμε δεν θα είναι και πολύ χρήσιμες.

πχ

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

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

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]

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 ...

[4. Υλοποίηση των breakpoints]

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

[4.1 Software Breakpoints]

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

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

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

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

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

1: 05_rce2-5.html#c_call

[4.2 Hardware Breakpoints]

Τα 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]

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

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

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

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

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

[5.1 The C calling convention]

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

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

Μια πρώτη προσέγγιση θα ήταν να παίρνει τα δεδομένα του (παραμέτρους και τοπικές μεταβλητές) από συγκεκριμένες απόλυτες διευθύνσεις μνήμης. Όλα ωραία και καλά μέχρι να χρειαστεί να υλοποιήσουμε αναδρομικές συναρτήσεις (συναρτήσεις που καλούν τον εαυτό τους). Για παράδειγμα η f η οποία εκτυπώνει τους αριθμούς από το 1 μέχρι το 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) μεταφράζεται σε:

[IMG]

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

[IMG]

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

[IMG]

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

Σχηματικά:

[IMG]

Τώρα σε κάθε συνάρτηση ο κώδικας για την προσπέλαση των τοπικών δεδομένων είναι ο ίδιος. Αν υποθέσουμε πως έχουμε επεξεργαστή και λειτουργικό 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:

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

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

[5.2 System Calls]

Τα σύγχρονα λειτουργικά συστήματα που σέβονται τον εαυτό τους, φροντίζουν να ξεχωρίζουν το "χώρο" του πυρήνα (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. Έτσι μια τυπική κλήση είναι:

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

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

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

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

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

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

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

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

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

Μόλις αποκτήσαμε δύο σπουδαίες πληροφορίες.

Κοιτάξτε καλά τη __libc_start_main().

Συνεχίστε να την κοιτάζετε.

H __libc_start_main(), εκτός των άλλων, φροντίζει να κληθεί και το δικό μας κυρίως πρόγραμμα.

Κοιτάξτε λίγο ακόμα...

H __libc_start_main() πρέπει να γνωρίζει που βρίσκεται ο δικός μας κώδικας. Επομένως...

Για να σας βγάλω από την αγωνία, σας λέω πως η πρώτη παράμετρος της __libc_start_main() πρόκειται για τη διεύθυνση της main (0x0804851c)!

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

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

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

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

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

2: 05_rce2-2.html#gdb_asm

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

3: 05_rce2-5.html#c_call

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

Ακολουθεί ένα μυστηριώδες "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 εντολές για να το αποφύγει!

Εδώ στον 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:

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

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

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

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

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

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

[7. Πρόκληση]

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

Στην προηγούμενη πρόκληση ο σκοπός ήταν να βρείτε ποιος κωδικός αντιστοιχεί στο όνομα σας. Το μεγάλο πρόβλημα που είχα ήταν ότι για να υπάρξει 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() είναι:

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

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

Hall Of Fame

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

1. Λαμπής Μιχαήλ

2. Γιώργος Πρέκας

3. Αρχισυντάκτης (...με ανάγκασε να τον συμπεριλάβω στο hall of fame!)

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

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

[7.2 Πρόκληση #1]

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

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

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

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

Αρχική Σελίδα