Pour cet article, on se propose d’écrire un driver qui effectuera ce hook et qui détournera RDTSC afin de rendre les valeurs 11223344 et 55667788 respectivement dans EAX et EDX lorsqu’on l’appelle. Je présente en premier lieu la théorie nécessaire pour l’attaque, puis décris comment l’implémenter sous Linux. Enfin, je détaille une difficulté majeure à laquelle on peut faire face sur les distributions récentes telles qu’ArchLinux : le flag TIF_NOTSC.

L’instruction RDTSC et le flag TSD

RDTSC signifie « ReaD TimeStamp Counter », autrement dit elle permet de lire le compteur de temps du processeur, incrémenté à chaque cycle d’horloge. Ce compteur n’est autre que le MSR IA32_TIME_STAMP_COUNTER (cf manuel 3B d’Intel, section 18.11). Celui-ci fait 64 bits et est retourné dans EDX et EAX lors de l’appel à RDTSC. Les applications classiques s’en servent généralement pour :

• Effectuer des mesures de performance (benchmark) sans passer par les fonctions du noyau
• Générer des nombres pseudo-aléatoires, à cause du caractère à priori non prévisible de ce compteur (surtout des bits de poids faible)
• Détecter des débogueur en mesurant des deltas entre deux instructions fixes ; si un débogueur est présent et qu’un breakpoint a été posé (ou que le mode step-by-step a été utilisé), le temps écoulé sera beaucoup plus long donc il est facile à l’application de quitter.

Cependant, ce n’est pas exactement comme cela qu’est décrit l’instruction RDTSC dans le manuel 2B d’Intel. En effet, on peut y lire le pseudo-code suivant :

IF (CR4.TSD = 0) or (CPL = 0) or (CR0.PE = 0)
THEN EDX:EAX ? TimeStampCounter;
ELSE (* CR4.TSD = 1 and (CPL = 1, 2, or 3) and CR0.PE = 1 *)
#GP(0);
FI;

On y apprend que le registre CR4 possède un flag TSD qui, s’il est activé, provoquerait une exception lorsque RDTSC est appelé dans un ring supérieur à 0 (mode protégé). Cette exception est la General Protection Fault, notée #GP et définie à l’index 13 dans l’IDT (table des interruptions). L’OS traite cette exception par une routine du noyau qui n’est généralement pas prévue pour gérer ce cas, donc on aura par défaut droit à un crash du programme ayant appelé RDTSC. Sous Linux, cela se traduit par l’envoi d’un signal SIGSEGV au processus, causant une segmentation fault.

IDT hooking

Pour hooker RDTSC, il faut donc dans un premier temps mettre à 1 le flag TSD (bit 2) de CR4 pour déclencher une #GP. Mais ce que nous voulons, c’est appeler notre fonction et non celle du noyau lors de l’exception. Il va donc falloir patcher l’IDT en remplaçant l’adresse du handler 13 par le notre ; autrement dit, faire du IDT hooking.

L’IDT recense des descripteurs explicités à la section 5.11 du manuel 3A d’Intel. Les descripteurs suivant plus ou moins le même format :

Descripteur d'interruption

Comme d’habitude dans la doc Intel, le schéma se lit de bas en haut et de droite à gauche (little endian, quand tu nous tiens…). A la mode des autres descripteurs propres à l’architecture x86, on constate que le champ Offset est découpé en deux parties : poids forts et poids faibles. C’est ce champ qui pointe vers le handler à exécuter lors de l’exception. Il suffit de remplacer sa valeur par l’adresse d’une de nos fonctions, et nous pourrons alors détourner le flux d’exécution lors d’un appel ring 3 à RDTSC.

Trouver l’IDT

Pour pouvoir faire un hook de l’IDT, il faut d’abord savoir la trouver. En fait, il est nécessaire de préciser que pour les processeurs multi-coeur, il n’y a pas une seule IDT mais plusieurs :  une par cœur. Il est donc en théorie nécessaire de hooker toutes les IDT pour éviter les problèmes. Pour connaître l’IDT référencée par un cœur, il suffit d’utiliser l’instruction SIDT sur ce cœur. Cette instruction est accessible en ring 3 ; voici un code qui l’illustre. Cependant, si vous utilisez Linux dans une machine virtuelle telle que VirtualBox, il se peut que vous rencontriez des problèmes en fonction de vos options de virtualisation. En effet, l’instruction SIDT n’est pas toujours bien émulée par l’hyperviseur et il se peut que la valeur qu’elle retourne soit erronée. Préférez-donc la solution suivante si vous tenez à faire vos tests dans une VM.

Même si un procceseur peut avoir plusieurs IDT, Linux n’en utilise qu’une car chaque cœur référence la même. Celle-ci est définie dans le noyau par le symbole idt_table. Pour connaître son adresse, tentez :

grep idt_table /proc/kallsyms

Le premier champ retourné est l’addresse de l’IDT. Si cela ne vous renvoie rien, il vous faudra à la place utiliser le fichier /boot/Symbol.map, généré à la compilation du noyau. Il se peut que son nom soit quelque peu différent ; par exemple sous Ubuntu il suit le format /boot/System.map-$(uname -r) alors que sous ArchLinux il s’appelle /boot/System.map26.

Conception du handler

Une bonne conception du nouveau handler d’interruption est cruciale pour éviter de rendre instable tout le système. En effet, #GP est utilisée non seulement pour RDTSC mais aussi à chaque fois qu’un check de privilèges échoue (pour une bonne ou une mauvaise raison) dans l’OS, autrement dit un sacré paquet de fois… Autant dire qu’il est préférable de laisser l’OS gérer ces cas là tout seul.

Pour cela, il va falloir filtrer dans un premier temps les #GP dues à RDTSC et celles dues à une autre instruction. Détecter l’instruction fautive est facile vu que l’EIP a été empilé ; il suffit de le regarder, d’examiner ce qu’il pointe et de comparer cette valeur à l’opcode de RDTSC : 0F 31, soit 0x310F en mot de 16 bits little endian. Si cela ne correspond pas, on saute sur le handler de base de l’OS pour ne pas tout crasher.

Ce n’est pas tout : les programmes ring 3 de l’OS aussi utilisent RDTSC. Si nous leur rendons des valeurs comme 0×11223344, ils risquent d’avoir un comportement plutôt imprévisible, surtout s’ils s’en servent comme base de temps. J’ai d’ailleurs testé sous Linux ; Cron a segfaulté instantanément et la machine est devenue inutilisable en quelques secondes.

Bref, il faut se débrouiller pour rendre la bonne valeur à ces programmes. La solution est d’émuler RDTSC dans le driver, et de transmettre les résultats dans EAX et EDX au ring 3. Mais comment savoir quand retourner les bonnes et valeurs et les fakes ? La solution la plus simple qui m’est venue à l’esprit est d’utiliser le PIDs du processus courant, en supposant que l’on connaisse le PID à hooker. Pour transmettre au driver le PID du processus en question, on peut utiliser des IOCTLs, justement prévues pour la communication ring 3 – ring 0. Une fois que l’on a le PID, il suffit de consulter le PID courant et on peut savoir si on doit émuler RDTSC ou forger les valeurs.

Récupération du PID courant

Nous avons quasiment tout ce qu’il faut pour implémenter cette attaque sous Linux. La seule chose qu’il nous manque, c’est un moyen dé récupérer le PID du processus courant lorsque l’on est dans un handler d’interruption. Après lecture en diagonale du chapitre 7 d’Understanding The Linux Kernel 3rd edition, on constate qu’il existe une macro nommée current qui permet de récupérer un pointeur vers le descripteur de processus courant. Après avoir testé cette macro, je me suis rendu compte qu’elle ne marche en fait pas dans le contexte d’un handler d’interruption. Il faut utiliser à la place la fonction current_thread_info() qui marche à tous les coups. A partir de là, récupérer le PID est très simple, via l’expression suivante : current_thread_info()->task->pid.

Implémentation 1

Nous pouvons maintenant implémenter l’attaque. Je l’ai réalisé sans problèmes particulier sur une Ubuntu 9.04 avec un noyau 2.6.28, sur processeur AMD dualcore. Les sources sont disponibles plus bas ; voici les points principaux.

//Typedefs
typedef unsigned char u_int8;
typedef unsigned short u_int16;
typedef unsigned int u_int32;
typedef unsigned long long int u_int64;

/**
 * An IDT entry. Cf Intel SDM 3A
 */
typedef struct {
 u_int16 low_offset;
 u_int16 selector;
 u_int8 unused_lo;
 u_int8 segment_type:4;
 u_int8 system_segment_flag:1;
 u_int8 DPL:2;
 u_int8 P:1;
 u_int16 hi_offset;
} __attribute__((packed)) IDTENTRY_ST, *P_IDTENTRY_ST;

Dans un premier temps, on déclare la structure d’un descripteur d’interruption. On fera particulièrement attention à bien spécifier __attribute__((packed)) pour spécifier au compilateur de ne pas faire de padding entre les champs. La fonction effectuant le hook est ci-après :

//Interrupt handlers
u_int32 old_int_handler, new_int_handler2;

void HookOneIDT (P_IDTENTRY_ST _p_IDT, u_int32 _interrupt_number,
                 u_int32* _old_address, u_int32 _new_address)
{
 asm("cli\n\t");

 *_old_address =  ((_p_IDT[_interrupt_number].hi_offset << 16)
                | (_p_IDT[_interrupt_number].low_offset));
 _p_IDT[_interrupt_number].hi_offset = (_new_address >> 16) & 0xFFFF;
 _p_IDT[_interrupt_number].low_offset = (_new_address & 0xFFFF);

 asm("sti\n\t");
}

Rien de particulier ici, à part une désactivation temporaires des interruptions. D’ailleurs, pour être plus rigoureux, il aurait fallu les désactiver sur tous les cœurs, mais comme cette fonction sera appelée avec interrupt_number = 13, qui n’est de toutes façon pas masquable, il n’y a pas de risque.

Le nouveau handler d’interruption est codé à part dans un fichier assembleur. Il s’agit en fait d’un squelette qui sauvegarde le contexte et appelle une fonction C, pour des raisons de commodité :

.globl interrupt_handler

//The interrupt handler.
//This function must be naked. Since it's not possible with gcc on x86 platforms, we put it in a separate asm file.
interrupt_handler: 

 //Save registers
 pusha
 pushf

 //Call our hook function and  the parameter
 //Since convention call of my_func_handler is fastcall, parameter has to be in %ecx
 mov %esp, %ecx
 call my_func_handler

 //Check the return value
 cmp $1, %eax

 //If 1, throw the exception away
 je  my_exit

 //Otherwise, restore registers
 popf
 popa

 //Jump to the original handler
 jmpl * old_int_handler

my_exit:

 //Restore registers
 popf
 popa

 //Pop interrupt error code
 add $4, %esp

 //Return from interrupt
 iret

La fonction appelée, my_func_handler, doit déterminer la nature de l’exception et la traiter si besoin en détournant RDTSC. On utilise son code de retour pour savoir si l’on repasse la main au handler par défaut de Linux, ou si on se contente de retourner en userland.

//Opcode for RDTSC : 0F 31 => 31 OF in little endian
#define RDTSC_OPCODE 0x310F

//Size of RDTSC instruction
#define RDTSC_SIZE   2

/**
 * Interrupt stack structures
 */
typedef struct
{
 u_int32 edi;
 u_int32 esi;
 u_int32 ebp;
 u_int32 esp;
 u_int32 ebx;
 u_int32 edx;
 u_int32 ecx;
 u_int32 eax;
} PUSHA_ST, *P_PUSHA_ST;

typedef struct
{
 u_int32 error_code;  // !! Check Intel Manuals to see if the error code is present or not
 u_int32 eip;
 u_int32 cs;
 u_int32 eflags;
 u_int32 esp;
 u_int32 sp;
} INT_STACK_HARD_ST, P_INT_STACK_HARD_ST;

typedef struct
{
 u_int32              eflags;

 PUSHA_ST             pusha_st;
 INT_STACK_HARD_ST    int_stack_hard_st;

} MY_INT_STACK_ST, *P_MY_INT_STACK_ST;

/**
 * Return current PID
 */
unsigned int GetCurrentPID (void)
{
 // !!! The 'current' macro doesn't work in interrupt context !
 // !!! We have to use current_thread_info()->task instead
 return current_thread_info()->task->pid;
}

/**
 * Function called by the interrupt handler.
 *  !! WARNING !! Don't call printk() inside, or the kernel will freeze !
 *
 * @param stack pointer to the stack
 * @return 0 if this is a normal #GP exception,
 * 1 if it is due to our RDTSC hook
 */
u_int32  __attribute__((__fastcall__))
         my_func_handler (P_MY_INT_STACK_ST stack)
{
 //nb_interrupts++;+
 asm volatile("lock incl nb_interrupts\n\t");

 //Detect if the instruction that triggered the exception is RDTSC
 if(* (u_int16*) stack->int_stack_hard_st.eip == (u_int16) RDTSC_OPCODE)
 {
 //Check who is executing RDTSC
 if(GetCurrentPID() == pid_to_hook)
 {
 //Change EAX and EDX with magic values
 stack->pusha_st.eax = 0x11223344;
 stack->pusha_st.edx = 0x55667788;
 }
 else
 {
 //Perform a normal call to RDTSC
 RDTSC_ST rdtsc;
 RDTSC(&rdtsc);

 stack->pusha_st.eax = rdtsc.eax;
 stack->pusha_st.edx = rdtsc.edx;
 }

 //Increment EIP
 stack->int_stack_hard_st.eip += RDTSC_SIZE;

 return 1;
 }
 else
 {
 return 0;
 }

}

Il y a plusieurs détails qui ont leur importance. D’une part,on définit des structures correspondant à l’état de la pile lors de l’appel à cette fonction. Cela inclut les registres généraux pushés par PUSHA ainsi que les valeurs pushés automatiquement par le processeur. Il faut faire attention à bien inverser leur ordre relativement aux specifications d’Intel, vu que la pile croît des addresses hautes vers les basses. On récupère l’EIP empilé, on déréférence ce pointeur et on compare le mot de 16 bits avec l’opcode de RDTSC renversé (vu qu’il se trouve en mémoire, donc en little-endian). On émule RDTSC su besoin, et on n’oublie pas d’incrémenter EIP afin de sauter par dessus l’instruction lors du retour. On notera que le debug de cette fonction n’est pas trivial, car il est impossible d’utiliser des fonctions comme printk() à l’intérieur.

Voici désormais la partie relative aux IOCTLs. Je n’ai pas détaillé cette partie précédemment car elle fait plutôt partie d’un choix d’implémentation.

#include <linux/ioctl.h>

//The device name in /proc/devices
#define DEVICE_NAME        "rdtsc_exploit"

//The name of the device file in /dev
#define DEVICE_FILE_NAME   "/dev/rdtsc_exploit"

//IOCTL command codes
#define IOCTL_SET_PID    _IOWR(0, 0, unsigned int)

//Device major and minor numbers
static dev_t g_device_num;

//Count the number of hooked interrupts
extern volatile unsigned int nb_interrupts;

//The file_operation structure, to link the device
//to the appropriate handlers
static struct file_operations g_fops = {
 .owner   = THIS_MODULE,
 .ioctl   = my_ioctl,
};

//Char device structure
static struct cdev g_device;

Sous Linux, pour pouvoir communiquer avec un module en utilisant des IOCTLs, il faut créer un périphérique virtuel en mode caractère (char device) et lui assigner un handler l’ioctl. Ce device possèdera un numéro majeur dynamiquement alloué par le noyau. Pour le numéro mineur, nous choisissons simplement 0. Une fois ces ressources allouées, nous enregistrons le device ce qui a pour effet de le faire apparaître dans /proc/devices. Tout ce procédé est fort bien décrit aux chapitres 3 et 6 de Linux Device Drivers, 3rd edition, livre libre que je vous conseille vivement.

/**
 * Create the device
 */
int create_device (void)
{
 //Allocate the device major and minor
 if(alloc_chrdev_region(&g_device_num, 0, 1, DEVICE_NAME))
 {
 printk(KERN_INFO "ERROR: alloc_chrdev_region FAILED\n");
 return -1;
 }

 //Initialise the device
 cdev_init(&g_device, &g_fops);

 //Fill in some fields (optional)
 g_device.owner = THIS_MODULE;
 g_device.ops = &g_fops;

 //Register the device into the kernel
 if(cdev_add(&g_device, g_device_num, 1))
 {
 printk(KERN_INFO "ERROR: cdev_add FAILED\n");
 return -1;
 }

 printk(KERN_INFO "Device registrated successfully - name = %s, "
                  "major = %d, minor = %d\n", DEVICE_NAME,
                  MAJOR(g_device_num), MINOR(g_device_num));

 return 0;
}

/**
 * Delete the device
 */
void delete_device (void)
{
 //Unregister the device
 cdev_del(&g_device);

 //Unregister the device number
 unregister_chrdev_region(g_device_num, 1);
}

Ces deux fonctions réalisent la création et la suppression du device.

Pour manipuler le flag TSD de CR4, on cree les fonctions suivantes :

//Flag of CR4 that disable RDTSC in userland
#define FLAG_DISABLE_USER_RDTSC 0x4

/**
 * Get CR4 value
 */
u_int32 GetCR4 (void)
{
 u_int32 res = 0;

 asm volatile (
 "push %%eax\t\n"
 "mov %%cr4, %%eax\t\n"
 "mov %%eax, %0\t\n"
 "pop %%eax\t\n"
 : "=m"(res));

 return res;
}

/**
 * Set CR4 value
 */
void SetCR4 (u_int32 _new_cr4)
{
 asm volatile(
 "push %%eax\t\n"
 "mov %0, %%eax\t\n"
 "mov %%eax, %%cr4\t\n"
 "pop %%eax\t\n"
 : : "m" (_new_cr4));
}

/**
 * Enable userland calls to RDTSC
 */
void EnableUserRDTSC (void)
{
 SetCR4(GetCR4() & ~FLAG_DISABLE_USER_RDTSC);
}

/**
 * Disable userland calls to RDTSC
 */
void DisableUserRDTSC (void)
{
 SetCR4(GetCR4() | FLAG_DISABLE_USER_RDTSC);
}

On notera au passage la syntaxe assez inhabituelle de l’assembleur inline de GCC, notemment les doubles % nécessaires puisque l’on utilise des références (%0), ainsi que les \n\t en fin de ligne. Et bien entendu, les arguments inversés par rapport à la syntaxe officielle d’Intel.

Lors du chargement du driver, il suffira de hooker l’IDT et de positionner le flag CR4.TSD. Cependant, cette dernière opération doit être faite sur tous les coeurs. On utilisera donc la macro on_each_cpu().

//Hook the General Protection Fault handler (0x0D)
#define INTERRUPT_VECTOR_TO_HOOK 0x0D

#include <linux/module.h>  /* Needed by all modules */
#include <linux/kernel.h>  /* Needed for KERN_ALERT */
#include <linux/init.h>     // Needed for the macros

#include "../include/defines.h"
#include "hook.h"
#include "device.h"

static int module_load(void)
{
 Hook();
 create_device();

 //Must return 0, otherwise the module is not loaded
 return 0;
}

static void module_unload(void)
{
 delete_device();
 UnHook();
}  

module_init(module_load);
module_exit(module_unload);

/**
 * Hook
 */
void Hook ()
{
 //Get the IDT address (all CPUS use the same)
 P_IDTENTRY_ST pIDT = GetIDTSoft();

 printk(KERN_INFO "interrupt_handler = %08x\n", (u_int32) interrupt_handler);

 //Hook interrupt handler
 HookOneIDT(pIDT, INTERRUPT_VECTOR_TO_HOOK,
            &old_int_handler, (u_int32) interrupt_handler);

 //Hook RDTSC
 on_each_cpu(DisableUserRDTSC, 0, 0);
}

/**
 * Unhook
 */
void UnHook ()
{
 //Unhook RDTSC
 on_each_cpu(EnableUserRDTSC, 0, 0);

 //Unhook interrupt handler
 HookOneIDT(GetIDTSoft(), INTERRUPT_VECTOR_TO_HOOK,
            &new_int_handler2, old_int_handler);
}

Dans mon prototype, je récupère l’adresse de l’IDT en userland dans le Makefile…

IDT_ADDRESS = "0x`grep idt_table /boot/System.map-2.6.28-11-generic
               | cut -d ' ' -f 1`"

… que je passe en paramètre à GCC lors de la compilation avec le flag -D. Le module la récupère comme une constante pré-processeur :

/**
 * Get a pointer to the IDT - the soft way.
 * Works perfectly in VMs, but we either have to hardcode the IDT offset,
 * or read it from userland ('grep idt_table /proc/kallsyms'
 * or 'grep idt_table /boot/System.map').
 */
P_IDTENTRY_ST GetIDTSoft (void)
{
 P_IDTENTRY_ST pIDT = 0;

 pIDT = (P_IDTENTRY_ST) IDT_ADDRESS;

 return pIDT;
}

En userland, il faudra transmettre le PID à hooker au device, ce qui se fait par le code suivant :

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#include <fcntl.h>
#include <sys/ioctl.h>

#include "defines.h"

int main(int ac, char **av)
{

 //int i;
 int fd;
 int pid_to_hook;

 if(ac != 2)
 {
 printf("Usage: set_pid pid\n");
 printf("Set the pid to hook.\n\n");
 exit(0);
 }

 pid_to_hook = atoi(av[1]);

 if(pid_to_hook <= 0)
 {
 fprintf(stderr, "Error, pid must be > 0.\n");
 exit(1);
 }

 //Open the device in order to communicate with the driver
 fd = open(DEVICE_FILE_NAME, O_RDONLY);

 if(fd == -1)
 {
 printf("Error: %s does not exist!\n", DEVICE_FILE_NAME);
 exit(1);
 }

 //Send IOCTLs to the driver to set the pid do hook
 if(ioctl(fd, IOCTL_SET_PID, pid_to_hook))
 {
 fprintf(stderr, "Error setting the pid.\n");
 }
 else
 {
 printf("pid set successfully.\n");
 }

 //Close the device
 close(fd);

}

Enfin, la routine de traitement de l’IOCTL qui sert à récupérer le PID dans le module est relativement simple :

/**
 * IOCTL handler
 */
int my_ioctl (struct inode * _inode, struct file * _file,
              unsigned int _ioctl_num, unsigned long _ioctl_param)
{
 struct task_struct *task;

 switch(_ioctl_num)
 {
 //Set the PID
 case (IOCTL_SET_PID):

 pid_to_hook = (unsigned int) _ioctl_param;

 break;

 default:
 printk(KERN_INFO "rdtsc_exploit: ERROR: Unsupported ioctl code: "
                  "%08x.\n", _ioctl_num);
 }
 return 0;
}

Test

Après avoir compilé le tout, on charge le module :

# insmod module/rootkit.ko
# grep rdtsc_exploit /proc/devices
250 rdtsc_exploit
# mknod /dev/rdtsc_exploit c 250 0

On lance le programme exécutant RDTSC dans un shell à part :

$ exe/rdtsc/rdtsc
Press <Enter> to call rdtsc. Press q to quit.

RDTSC result (edx : eax) = (0000126d : 8c1cc9a2)

RDTSC result (edx : eax) = (0000126d : a38e75be)

Puis on envoie son PID au module avec :

# exe/set_pid/set_pid $(pidof rdtsc)
pid set successfully.

Et on revient au terminal précédent, en constatant que le hook fonctionne bien :

RDTSC result (edx : eax) = (55667788 : 11223344)

RDTSC result (edx : eax) = (55667788 : 11223344)

RDTSC result (edx : eax) = (55667788 : 11223344)

On n’oubliera pas de décharger le module avec :

# rmmod rootkit
# rm /dev/rdtsc_exploit

Problème avec ArchLinux

En testant l’implémentation précédente avec deux distributions ArchLinux de noyaux 2.6.29 et 2.6.30, j’ai constaté qu’ell ne marchait tout simplement pas. En faisant plusieurs tests, je constate que le handler de #GP est bien hooké, mais RDTSC ne l’est pas du tout car le programme de test affiche toujours des valeurs normales. J’affiche la valeur de CR4.TSD à plusieurs reprises, et je vois que de temps en temps, il repasse à 0, ce qui expliquerait pourquoi RDTSC n’est pas détournée.

Après plusieurs recherches, je tombe sur ce blog, qui pointe du doigt quelques bizarreries du noyau Linux concernant justement le flag TSD. Apparemment, il serait possible de l’activer ou non pour certains processus seulement. Il s’agit du Thread Information Flag TIF_NOTSC définit dans le fichier arch/x86/include/asm/thread_info.h du noyau. Ce flag est plus ou moins l’équivalent du flag TSD, mais dans le contexte de chaque processus. Il est possible de le définir avec l’appel système prctl en utilisant l’option PR_SET_TSC. La valeur PR_TSC_ENABLE revient à positionner TSD = 0, tandis que PR_TSC_SIGSEGV est équivalent à TSD = 1.

Ces flags existent déjà dans les noyaux 2.6.28 d’Ubuntu 9.04 ; je n’ai pas encore bien saisi pourquoi ceuxi-ci sont effectivement appliqués sur ArchLinux. Le blog cité précédemment parle de l’option de configuration CONFIG_SECCOMP du noyau, présente sur ArchLinux, mais visiblement désactivée ia le flag TIF_SECCOMP qui vaut 0 pour tous les processus. Je vais continuer mes recherches de ce côté… Si toutefois vous avez des explications, je suis preveur .

Implémentation 2

En attendant, il reste tout de même effectuer le hook de RDTSC. Il suffit de positionner le flag TIF_NOTSC du processus en question à PR_TSC_SIGSEGV. Cela peut se faire en appelant prctl, mais cette technique n’est pas vraiment convenable car un hook se doit d’être extérieur au processus. La technique consiste donc à émuler le fonctionnement de cet appel système au sein de notre module. Il nous suffit de parcourir la liste chainée des processus, d’isoler celui qui a le bon PID, et à positionner son flag. Cela revient à modifier la fonction my_ioctl() comme ceci :

/**
 * IOCTL handler
 */
int my_ioctl (struct inode * _inode, struct file * _file,
              unsigned int _ioctl_num, unsigned long _ioctl_param)
{
   struct task_struct *task;

   switch(_ioctl_num)
   {
      //Set the PID
      case (IOCTL_SET_PID):

         pid_to_hook = (unsigned int) _ioctl_param;
         printk(KERN_INFO "rdtsc_exploit: pid_to_hook = "
                          "%d.\n", pid_to_hook);

         for_each_process(task) {
            if(task->pid == pid_to_hook){
               test_and_set_ti_thread_flag(task_thread_info(task), TIF_NOTSC);
               printk("TIF_NOTSC set for process %d\n", task->pid);
            }
         }

      break;

      default:
         printk(KERN_INFO "rdtsc_exploit: ERROR: Unsupported ioctl code: "
                          "%08x.\n", _ioctl_num);
   }
   return 0;
}

La macro for_each_process() définie dans linux/sched.h permet d’itérer très simplement sur les threads du système. On utilise la fonction test_and_set_ti_thread_flag() afin de positionner le flag TIF_NOTSC du thread en question. On notera qu’il n’y a même plus besoin de modifier à la main CR4 à l’initialisation.

Sources

Téléchargez les sources

Les sources incluent l’implémentation 2, sachant que celle-ci fonctionne aussi bien sur les deux distributions que j’ai testées (Ubuntu et ArchLinux). Les lignes spécifiques à la 1ère implémentation sont commentées, donc vous pouvez toujours jouer avec et voir le résultat que vous obtenez.

Pour compiler, invoquez simplement make à la racine de rdtsc_exploit. Si jamais cela ne compile pas, éditez le fichier module/Makefile, et indiquez le bon chemin vers votre fichier /boot/System.map. Vérifiez également que le fichier module/handler.S a bien un S majuscule concernant son extension.

Les fichiers fournis sont organisés comme ceci :

• module/ contient les sources du module
• exe/ contient deux sources d’exécutables :
  • rdtsc : programme de test exécutant RDTSC à chaque appui sur une touche. Il contient aussi un fichier de test du noyau, disable-tsc-test.c, que j’ai jugé intéressant de garder pour des tests. A compiler séparément.
  • set_pid : programme prenant en paramètre le PID de rdtsc et l’envoyant au module par ioctl
• scripts/ contient trois scripts permettant d’automatiser le chargement du module et la création du device. load_hook.sh et unload_hook.sh appellent en réalité load.sh, capable de charger/décharger un module et créer/détruire son device.

Applications

Pour terminer, voici quelques possibilités offertes par le hook de RDTSC :

• Empoisonnement des générateurs de nombres pseudo-aléatoires : Certaines applications utilisent RDTSC comme source d’aléa, pour générer des valeurs pseudo-aléatoires qui peuvent par exemple être utilisées pour la génération de clé de chiffrement. En forçant à RDTSC à renvoyer des valeurs bien précise, on peut injecter des valeurs bien précises dans l’algorithme de génération et pouvoir prédire plus facilement son résultat.
• Anti-anti-debuging : Comme dit au premier paragraphe, une technique d’anti-debug consiste à utiliser RDTSC pour estimer le temps passé entre deux instructions et le comparer à une valeur seuil. Une technique d’anti-anti-debug peut donc être de hooker RDTSC et de retourner des valeurs plausibles à l’application, en masquant le fait que celle-ci est en train de se faire déboguer. C’est précisément ce que fait le plugin Olly Advanced d’OllyDbg.
• Communication offusquée entre une application et un driver : Puisqu’avec cette technique RDTSC est exécutée en ring 3 et provoque une exception #GP en ring 0, c’est un moyen de donner la main à un driver afin qu’il effectue des opérations « ni vu ni connu », dans le sens ou il n’y a aucun appel explicite vers fonction noyau dans l’application ring 3.

Conclusion

Cette technique n’est pas nouvelle, mais encore assez peu connue (enfin sans doute pas des reversers :p). Cependant, elle peut se révéler très intéressantes dans de multiples occasions. Si je devais donner un conseil, ce serait d’éviter de l’utiliser en ring 3, pour deux raisons principales de sécurité :

• Il existe des générateurs aléatoires reconnus comme fiables, il est donc préférable de les utiliser plutôt que de se faire son propre algorithme.
• L’OS fournit généralement des appels systèmes permettant d’appeler RDTSC en ring 0 et de retourner sa valeur (cf NtQueryPerformanceCounter() sous Windows). Comme l’appel est en ring 0, la méthode de hook décrite précédemment ne marche plus.

Références

• The Art of Unpacking, Marc Vincent Yason, BlackHat 2007
• Intel Software Devloper’s Manuals 2B, 3A
• Understanding the Linux kernel, 3rd edition, Daniel Pierre Bovet, Marco Cesati, O’Reilly
• Nibbles – SMP : IDT et GDT, j0rn
• Linux Device Drivers, 3rd edition, Jonathan Corbet, Alessandro Rubini, Greg Kroah-Hartman, O’Reilly
• CR0′s blog : Time-stamp counter disabling oddities in the Linux kernel
• Man prctl

PR_SET_TSC

Après avoir lu de nombreux articles sur l’injection de DLL sous Windows, j’ai commencé à en avoir assez à ne pas trouver d’équivalent sous Linux.  Le peu d’information que j’ai trouvé pour Linux datent d’au moins 5 ans, et se révèlent non adaptables aux distributions récentes. C’est pourquoi je me suis lancé dans l’idée de réaliser ce genre d’outil moi même. Ainsi, après m’être heurté à plusieurs obstacles, j’ai finalement réussi à développer un outil fonctionnel : InjecSO.

Cet outil marche très bien sur ma machine qui est une Ubuntu 8.10, avec un noyau 2.6.27, sans outil de protection de la mémoire comme PaX (la technique utilisée ne marchera pas si la pile n’est pas exécutable), et avec une Libc de version 2.8.90. Je n’ai pas eu l’occasion de tester sur d’autres machines, mais je pense qu’il devrait fonctionner aussi bien, les deux seuls obstacles étant l’implémentation de la librairie standard et les éventuels patches appliqués au noyau.

InjecSO in a nutshell

Voyons dans un premier temps comment utiliser InjecSO dans un cas simple.

Téléchargement

Télécharger InjecSO au format tar.gz

Présentation rapide

InjecSO se présente sous la forme de deux outils.

• injecso est le cœur du programme utilisé pour l’injection de code. Il s’agit d’un programme écrit en C qui prend 3 arguments : le pid du processus cible, le chemin absolu de la librairie à injecter, et l’adresse de la fonction __libc_dlopen_mode() dans l’espace mémoire du processus cible. Cette dernière est une fonction spéciale de la libc qui rend l’injection possible et est décrite précisément dans la deuxième partie de l’article. Localiser cette adresse précise dans le processus cible est faisable mais rébarbatif ; c’est pourquoi j’ai développé un deuxième outil pour se faciliter la vie.
• injecso.sh est un script Bash qui a justement pour but de calculer cette adresse de façon automatique. Il ne prend donc que deux paramètres : le pid et le nom de la librairie à injecter. Il appelle automatiquement le programme précédent en lui fournissant le paramètre manquant. De plus, le chemin de la librairie peut être relatif car l’outil calcule le chemin absolu automatiquement.

J’entends déjà des remarques venir :  «Pourquoi ne pas avoir tout intégré dans un seul programme ?». La réponse est simple : cela aurait été faisable, mais m’aurait nécessité beaucoup plus de temps pour au final arriver au même résultat. Le calcul de l’adresse nécessite d’analyser la mémoire du processus et le code de la libc, et il se trouve qu’il existe déjà des outils qui font cela très bien sous Linux. Ainsi, injecso.sh ne fait qu’exploiter ces ressources pour calculer rapidement l’adresse de la fonction voulue. Je suis conscient que cela a ses avantages et ses inconvénients ; en particulier, le script nécessite que vous ayez certaines dépendances d’installées, dont readelf et perl (pour parser la sortie produite par ces outils). Je ne pense pas que cela soit une exigence trop forte, puisque ces outils sont en général présents sur beaucoup de systèmes, et sont au pire facilement installables surtout si votre distribution comprend un système de paquets.

Compiler le programme

Décompressez l’archive et utilisez le Makefile pour compiler l’exécutable :

$ tar xzvf injecso-1.0tar.gz
$ make

Exemples d’utilisation

L’outil est capable d’injecter n’importe quelle librairie dans n’importe quel type de processus, pour peu que vous ayez les droits suffisants (n’espérez pas injecter du code dans un processus appartenant à root si vous ne l’êtes pas vous-même). Comme exemple, prenons un processus simple tel que l’éditeur de texte vi et une librairie dynamique qui affiche « Hello World! » nommée libhelloworld.so. Voici le code de libhelloworld.c :

#include <stdlib.h>
#include <stdio.h>

void __attribute__ ((constructor)) hello_world(void);

void hello_world(void){
  printf("Hello World!n");
}

La directive __attribute__ ((constructor)) indique au compilateur qu’il devra ajouter cette fonction à la liste des fonctions à appeler au chargement de la libairie. Si vous êtes familier du monde Windows, c’est plus ou moins l’équivalent de la directive DllMain(). Compilez le code avec :

$ gcc libhelloworld.c -o libhelloworld.so -shared -fPIC

Vous pouvez placer cette librairie ou bon vous semble, le plus simple étant de la mettre dans le même dossier qu’InjectSO. Lancez vi, récupérez son pid avec la commande pidof vi et lancez l’injection !

$ ./injecso.sh $(pidof vi) ./libhelloworld.so
[+] Found __libc_dlopen_mode at 0xb7e44210
[+] Launching: injecso 9796 libhelloworld.so 0xb7e44210
[+] Attaching...
[+] Waiting for process...
[+] Copying shellcode to 0xbfa0b02e...
[+] Setting eip and esp...
[+] Detaching...

Regardez à présent la fenête où vous avez lancez vi… Vous devriez voir un petit Hello World! en haut de la console

Vous pouvez aussi bien injecter votre librairie dans des plus gros processus comme par exemple Firefox — pour les applications graphiques, le message s’affichera dans la console ayant l’ancé le programme —, et complexifier votre librairie. Les possibilités n’ont de limite que votre imagination : création d’un client ou serveur, dump de la mémoire, log d’événements, hooking de fonctions de la PLT… Notez que votre librairie peut à son tour appeler d’autres librairies (dynamiques ou pas) sans aucun problème.

Remarque concernant les threads

Il est important de noter qu’InjecSO ne crée aucun thread dans le processus cible. A la différence des outils d’injection de code sous Windows qui effectuent un appel à CreateRemoteThread(), le code injecté est directement exécuté dans le contexte courant du processus, qui est sauvegardé avant l’injection puis restauré. Si le code de votre librairie est gros ou effectue des opérations gourmandes en cycles CPU, le processus cible en sera ralenti. Cette remarque ‘est particulièrement valable si votre librairie effectue des entrées/sorties disque ou réseau (si vous comptez coder un serveur…). C’est pourquoi dans ces cas il est préférable de créer un nouveau thread, en utilisant par exemple la libairie pthread.

Détails d’implémentation

Cette section décrit en détails comment InjecSO est implementé. Je commence par faire un tour d’horizon des techniques utilisées, puis je détaille le code de l’outil.

ptrace() et dlopen()

Il faut reconnaître que sous Linux, l’attirail disponible pour injecter des librairies est très limité, en tout cas beaucoup plus que sous Windows. A vrai dire, il n’y a tout simplement pas d’appel de fonction tel que  OpenProcess() et CreateRemoteThread(), donc manipuler un processus devient beaucoup plus délicat. Le seul outil dont nous disposons est ptrace().  Il s’agit d’un appel système qui est utilisé majoritairement pour le débogage de processus. Il est relativement simple à utiliser ; on commence par s’attacher au processus à tracer, qui se bloque. On peut alors récupérer son état, ses registres et sa mémoire d’un processus, et les modifier. Une fois les opérations de tracage terminées, on se détache, et le processus reprend son cours. Nous allons voir comment InjecSO utilise cet appel système par la suite ; en attendant je vous renvoie au manuel si vous voulez en savoir plus.

Pour charger une librairie dynamique sous Unix, on utilise la fonction dlopen() qui est plus ou moins l’équivalent de LoadLibraryA() sous Windows. Cette fonction prend en paramètre le nom de la librairie à charger, ainsi qu’un flag qui indique la manière dont doivent être résolus les symboles. Cela n’a guère d’importance pour notre application, aussi nous spécifierons arbitrairement que les symboles doivent tous être résolus au chargement.

Un premier problème : dlopen()

A première vue, ptrace() et dlopen() constituent de bonnes bases pour notre injection. Seulement, ce n’est pas si simple : il se trouve que la fonction dlopen() n’est pas une fonction standard, mais se situe dans une librairie séparée nommée libdl… qui n’est pas toujours chargée par tous les processus. Autrement dit, un processus lambda ne possède pas forcément le moyen de charger une librairie dynamique, car la fonction qui permet de charger des librairies se trouve justement dans une librairie dynamique !

C’est là qu’on peut se dire «OK, mais alors comment fait un processus quand il veut charger une librairie ?». Réponse : c’est le programmeur qui spécifie au moment de la compilation et de l’édition des liens qu’il vaut lier son programme avec libdl qui sera alors chargée à son lancement. Sauf que dans notre cas, nous ne sommes pas forcément le développeur du programme cible, et nous ne voulons de toute manière pas modifier le code du programme…

La solution : __libc_dlopen_mode()

En cherchant de la documentation sur les détails d’implémentation de dlopen(), j’ai finalement trouvé un papier datant de 2003 [1] qui explique que les fonctions de libdl sont pour la plupart des stubs qui appellent des fonctions qui se trouvent en réalité dans la libc. Rappelons que la libc est chargée dans quasiment tous les processus, donc cette découverte parraît très intéressante. Selon le papier, dlopen() appelle en fait _dl_open(). Après vérification, je me rend compte que ce n’est pas/plus le cas, du moins sur ma machine. Mais il semblerait qu’il y ait une fonction similaire avec un nom assez proche : __libc_dlopen_mode(). Voici la mise en évidence en images :

$ pidof bash
10712 9864 8911
$ cat /proc/10712/maps | grep libc
b7d61000-b7eb9000 r-xp 00000000 08:08 51577   /lib/tls/i686/cmov/libc-2.8.90.so
b7eb9000-b7ebb000 r--p 00158000 08:08 51577   /lib/tls/i686/cmov/libc-2.8.90.so
b7ebb000-b7ebc000 rw-p 0015a000 08:08 51577   /lib/tls/i686/cmov/libc-2.8.90.so
$ readelf -s -D /lib/tls/i686/cmov/libc-2.8.90.so | grep dlopen
 2188 744: 0011d210   156    FUNC GLOBAL DEFAULT  11 __libc_dlopen_mode
 2188 966: 0011d210   156    FUNC GLOBAL DEFAULT  11 __libc_dlopen_mode

Dans un premier temps, on récupère les pid d’un processus quelconque, ici Bash, on obtient le chemin complet de la libc (ici /lib/tls/i686/cmov/libc-2.8.90.so) et on utilise readelf pour afficher les symboles dynamiques de la librairie. Résultat : il y a bien une fonction qui a l’air similaire à dlopen().

Mais que fait cette fonction, et quel est son prototype ? Pour cela, le plus simple est de récupérer le code source de la librairie standard et de le parcourir. C’est ce que j’ai donc fait, et je suis finalement tombé sur cela :

extern void *__libc_dlopen_mode  (__const char *__name, int __mode);

Comparons cela au prototype original de dlopen() :

void *dlopen(const char *filename, int flag);

Hum… cela paraît très similaire, pour ne pas dire identique ! Je m’empresse donc de coder un petit programme en C qui appelle cette fonction, et m’aperçois alors que la libraire est bien chargée, comme avec dlopen() ! Super, nous pouvons donc nous contenter de cette fonction.

Deuxième problème : randomization des adresses

Ok, nous avons maintenant un nom de fonction pour charger la librairie. Cependant, pour pouvoir l’appeler dans le processus cible, il nous faut son adresse. Comment l’obtenir, sachant qu’elle se trouve dans l’espace mémoire du processus cible ? Nous savons que la fonction réside dans la libc ; pour déterminer son adresse nous pouvons utiliser le même programme que précédamment, readelf. Lors de notre dernière commande, cet outil nous a indiqué que la fonction se situe à l’offset 0x0011d210 dans l’image mémoire de la librairie. Comment obtenir l’adresse globale à partir de cet offset ? Simplement en additionnant cet offset avec l’adresse de base à laquelle est chargée la libc. Mais quelle est l’adresse de base de la libc ? Observons le résultat de la commande ldd :

$ ldd /bin/bash | grep libc
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7ee4000)

Nous utilisons cette commande sur Bash, et filtrons la sortie pour n’afficher que ce qui nous intéresse. Notez que le chemin de la libc est ici différent de précédamment, mais cela n’a pas d’importance pour ce que je cherche à illustrer ici.  Ce qu’il faut noter ici, c’est que ldd nous affiche que la libc est chargée à l’adresse 0xb7ee4000. Mais il y a un léger hic… En effet, si on relance la même commande une deuxième fois…

$ ldd /bin/bash | grep libc
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7ef0000)

Oups. L’adresse a changée ! Pourquoi donc ? Parce que depuis relativement récamment (quelques années), Linux a introduit un système de randomization des adresses. Autrement dit, l’adresse à laquelle une librairie est chargée n’est pas constante et varie pour toutes les exécutions d’un programme donné. Autant dire que cela ne va pas nous faciliter la tâche pour calculer l’adresse de __libc_dlopen_mode()…

Solution : /proc/<pid>/maps

Tout n’est pas perdu. Linux possède un système de fichier virtuel, nommé /proc/, qui va nous permettre de nous en sortir. En effet, lorsqu’un processus est créé, Linux crée un répertoire /proc/<pid>/ (<pid> étant le nom du processus en question) contenant plein d’informations. En particulier, le fichier /proc/<pid>/maps contient la liste de toutes les sections mappées mémoires dans l’espace du processus. Voyons ce que nous pouvons obtenir…

$ pidof bash
10712 9864 8911
$ cat /proc/10712/maps | grep libc
b7d61000-b7eb9000 r-xp 00000000 08:08 51577  /lib/tls/i686/cmov/libc-2.8.90.so
b7eb9000-b7ebb000 r--p 00158000 08:08 51577  /lib/tls/i686/cmov/libc-2.8.90.so
b7ebb000-b7ebc000 rw-p 0015a000 08:08 51577  /lib/tls/i686/cmov/libc-2.8.90.so

On s’aperçoit que la libc est mappée 3 fois dans l’espace mémoire de Bash : une fois en lecture et exécution, une fois en lecture seule, et une fois en lecture et écriture. En ce qui nous concerne, nous souhaitons exécuter une fonction, donc nous avons intérêt à choisir la section exécutable. Son adresse est 0xb7d61000 ; ajoutons à cela l’offset précédent (0x0011d210), et nous obtenons l’adresse de __libc_dlopen_mode() ! Sa valeur n’a pas d’importance dans cet exemple car nous voulons juste un moyen de la calculer automatiquement pour n’importe quel processus.

Injecso.sh : calcul de l’adresse

Si nous rassemblons tout ce que nous venons de voir, nous savons désormais calculer l’adresse de __libc_dlopen_mode() pour un processus donnée. Il ne reste plus qu’à mettre tout cela dans un script ; c’est le but d’injecso.sh. Le script a volontairement été raccourci ici pour n’afficher que les bouts intéressants.

#!/bin/bash
# Param renaming
pid=$1
lib=$2

Nous commençons par récupérer la ligne de /proc/<pid>/maps qui nous intéresse, et nous allons extraire d’une part l’adresse de base de la librairie, et son nom.

# Get the map of process and get the line
# that correspond to the executable section of libc
line=$(cat /proc/$pid/maps | grep "libcb" | grep r-x | head -n 1)

# Extract the base address of that section and the name of the library
libc_baseaddr=$(echo "$line" | cut -d "-" -f1)                # first field
libc_name=$(echo "$line" | perl -n -e '/(S+$)/ && print $1') # last field

Nous utilisons ensuite readelf pour extraire l’offset de __libc_dlopen_mode().

# Use readelf to find the offset of __libc_dlopen_mode
dlopen_offset=$(readelf -s -D $libc_name | grep __libc_dlopen_mode |
  head -n 1 | perl -n -e '/^s*S+s+S+s+(S+)/ && print $1') # 3rd field

L’adresse est obtenue en additionnant cet offset avec l’adresse de base.

# Compute the actual addresses
dlopen_addr=$(expr $(printf "%d" 0x$libc_baseaddr) 
  + $(printf "%d" 0x$dlopen_offset))
dlopen_addr_hex=$(printf "0x%x" $dlopen_addr)

echo "[+] Found __libc_dlopen_mode at $dlopen_addr_hex"
echo "[+] Launching: injecso $pid $lib $dlopen_addr_hex"

Il ne reste plus qu’a passer les paramètres adéquats à notre injecteur.

# Launch InjecSO
$(dirname $0)/injecso $pid $(pwd)/$lib $dlopen_addr_hex

Voila, nous venons de faire le tour du script. Plutôt simple, la difficulté majeure étant de parser la sortie des différents outils utilisés.

Structure de l’injection

Bon, ce n’est pas tout, mais nous n’avons toujours pas vu comment se déroule l’injection ! C’est là que nous allons utiliser ptrace()… Comme je l’ai dit précédemment, cet appel système permet de modifier la mémoire et les registres d’un processus cible. Comment l’utiliser à fin d’injecter un appel à __libc_dlopen_mode() ? La solution la plus simple est d’injecter un shellcode qui va réaliser l’appel. Il y a plusieurs possibilités pour ce faire ; j’ai choisi la plus simple c’est à dire d’injecter le shellcode dans la pile. Notez que cela requirt que la pile soit exécutable, ce qui n’est pas toujours le cas.

De plus, il va nous falloir faire très attention car nous ne voulons pas crasher le processus cible. Comme notre shellcode sera susceptible de s’exécuter n’importe quand dans le processus, il doit rester « invisible ». Autrement dit, il faut que l’état du processeur avant et après l’exécution du shellcode soit « quasiment » le même. Pour cela, nous allons devoir sauvegarder les registres avant d’exécuter la charge utile du shellcode, et les restaurer ensuite.

Là encore, il y a plusieurs solutions pour résoudre ce problème ; je vais détailler celle que j’ai retenue pour injecSO. Voici un shema de la pile avant l’appel au shellcode :

 |               |
 |               |
 |               |
 |               |
 |               |
 +---------------+
 |    donnees    | <- esp
 |               |

Dans ce schéma, les adresses croissent vers le bas, mais rappelez-vous que la pile croît en sens inverse. Au moment de l’injection, nous allons effectuer les opérations suivantes en utilisant ptrace():

• Sauvegarder l’adresse de l’instruction courante (contenue dans eip) sur la pile
• Allouer le shellcode sur la pile
• Faire pointer  eip et esp sur le shellcode

Voici donc la pile après l’injection :

 |               |
 +---------------+
 |   shellcode   | <- eip, esp
 |               |
 |               |
 |               |
 +---------------+
 |  ancien eip   |
 +---------------+
 |    donnees    |
 |               |

Pour que cela fonctionne, le shellcode devra avoir une structure particulière :

• Quelques nops afin de compenser un éventuel décalage dans les adresses.
• pushal afin de sauvegarder les registres sur la pile.
• Charge utile du shellcode (en gros, push des arguments et call __libc_dlopen_mode )
• popal pour restaurer les registres
• addl $size, %esp ($size étant la taille du shellcode) afin de repositionner esp sur l’adresse de retour
• ret qui dépilera et restaurera l’adresse de retour

L’injecteur va dans un premier temps générer le shellcode suivant ce modèle. Cependant, ce modèle est incomplet car le shellcode nécessite des paramètres qui ne seront connus qu’à l’exécution : l’adresse de __libc_dlopen_mode, le nom de la librairie à injecter, ainsi que la taille du shellcode (comprenant le nom de la librairie). Ainsi, l’injecteur va devoir compléter/patcher le shellcode à plusieurs endroits avant qu’il soit fonctionnel.

Le shellcode

Voici le code du shellcode utilisé ; je pense que les commentaires sont assez explicites :

  .text
  .globl shellcode_code
  .globl shellcode_code_end

shellcode_code:

  /* Some nops */
  nop
  nop
  nop
  nop
  nop
  nop
  nop

  /* Save all registers */
  pushal

  /* Get the name of the library into ebx */
  jmp       libname

call_dlopen:
  popl      %ebx

  /* 0x11111111 will be later replaced by
     the address of __lib_dlopen_mode */
  movl      $0x11111111, %eax
  pushl     $2      /* RTLD_NOW */
  pushl     %ebx    /* name of the library */
  call      *%eax   /* call __lib_dlopen_mode */

  /* Clean args on the stack */
  addl      $8, %esp

  /* Restore all registers */
  popal

  /* 0x12345678 will be later replaced by
     the size of the shellcode (+ delta) */
  addl      $0x12345678, %esp

  /* Return to where we were before */
  ret

libname:
  call call_dlopen
shellcode_code_end:
/*
 * End of shellcode
 * The string corresponding to the library name
 * will be put here later
 */

Comme je le disais, le shellcode est encore incomplet. En particulier, il manque encore le nom de la librairie, qui sera ajouté à la fin. Pour récupérer son adresse relative, nous utilisons l’astuce du jmp/call, assez célèbre. Concernant l’adresse de __libc_dlopen_mode et la taille du shellcode, nous laissons des offsets bidon pour le moment que nous allons patcher ensuite. Voila justement le début du code de l’injecteur, qui a pour but d’assembler/patcher le shellcode :

int main(int argc, char **argv){
  char * shellcode;
  int shellcode_size, libname_size;
  char * ptr;
  int i;
  int pid;
  char * libname;
  int dlopen_addr;

  //Check parameters
  check_params(argc, argv, &pid, &libname, &dlopen_addr);

Ici, nous venons de récupérer les paramètres de l’injecteur, c’est à dire le pid, le nom de la librairie et l’adresse de __libc_dlopen_mode. Je ne pense pas que cette fonction soit sufisamment intéressante et complexe pour être détaillée ici.

  //Compute the size of the library name and deduce the shellcode size
  libname_size = strlen(libname);
  shellcode_size = (char *) shellcode_code_end - (char *) shellcode_code 
                   + libname_size + 1;

  //Allocate the shellcode buffer
  shellcode = malloc(shellcode_size);

La copie du shellcode commence ici, puis le nom de la librairie y est ajouté.

  //Copy the shellcode code into the buffer
  for(i = 0, ptr = (char *) shellcode_code;
      ptr != (char *) shellcode_code_end;
      ptr++, i++){
    shellcode[i] = *ptr;
  }

  //Copy the library name at the end of the shellcode
  for(ptr = libname; *ptr != 0; ptr++, i++){
    shellcode[i] = *ptr;
  }

Maintenant, c’est le moment de patcher le shellcode. Le début du shellcode ayant une taille fixe, nous connaissons précisément les offsets à patcher (il suffit d’assembler le shellcode une première fois et de compter).

  //Patch the shellcode by inserting the real address of __libc_dlopen_mode
  //(replace 0x11111111 by dlopen_addr)
  *((int *) &(shellcode[12])) = dlopen_addr;

  //Patch the shellcode to include its own size
  *((int *) &(shellcode[27])) = shellcode_size + DELTA_SHELLCODE_EIP_BAK;

Il y a un petit détail dont je n’ai pas parlé : l’expérience montre que le shellcode inséré tel quel juste après l’adresse de retour ne marche pas ; la fin du shellcode se retrouve écrasée pour une raison que je n’ai pas encore bien comprise. Pour éviter ça, j’ai introduit une petit décalage (delta) de quelques octets entre l’adresse de retour et la fin du shellcode, afin de garantir qu’elle ne sera pas touchée. Il faut juste prendre en compte ce décalage dans certains calculs, bref rien de très compliqué.

  //Inject!
  inject(pid, shellcode, shellcode_size);

Le shellcode est désormais prêt, place à l’injection !

L’injection de code

Voici enfin la routine qui effectue l’injection.

void inject(int pid, char * shellcode, int shellcode_size){

  long res;
  struct user_regs_struct regs;
  char * addr_shellcode;
  int i;

  //Attach to the process
  printf("[+] Attaching...n");
  res = ptrace(PTRACE_ATTACH, pid, NULL, NULL);
  if(res == -1){
    perror("Attaching");
  }

Après s’être attaché au processus, il faut impérativement l’attendre, sans quoi il risque de ne pas être prêt.

  //Wait for the process
  printf("[+] Waiting for process...n");
  waitpid(pid, NULL, 0);

  //Set option for interrupted syscalls
  res = ptrace(PTRACE_SETOPTIONS, pid, NULL, PTRACE_O_TRACESYSGOOD);
  if(res == -1){
    perror("Setting ptrace option");
  }

Cette option n’est pas obligatoire, mais est préférable dans le cas où le processus a été interompu en plein milieu d’un appel système.

  //Get the registers of the process
  res = ptrace(PTRACE_GETREGS, pid, NULL, &regs);
  if(res == -1){
    perror("Getting registers");
  }

Nous avons les registres du processus, nous pouvons maintenant les manipuler comme nous voulons. Nous commençons par calculer l’adresse à laquelle le shellcode devra être chargé, puis nous sauvegardons l’adresse de retour sur la pile

  //Compute the address where the shellcode will be copied
  //We keep 4 bytes for old eip and a delta between this
  //and the end of the shellcode
  addr_shellcode = (char *) regs.esp - shellcode_size 
                    - DELTA_SHELLCODE_EIP_BAK - 4;

  //Save eip on the stack (esp orig - 4)
  res = ptrace(PTRACE_POKEDATA, pid, regs.esp-4, regs.eip);
  if(res == -1){
    perror("Saving eip");
  }

Il faut maintenant copier le shellcode. Attention : lors des transferts de données, ptrace() copie les octets 4 par 4. Il faut donc faire attention lors de l’itération, et ne pas oublier la fin du shellcode.

  //Copy shellcode
  printf("[+] Copying shellcode to 0x%x...n", (int) addr_shellcode);
  for(i = 0; i < shellcode_size/4; i++){
    res = ptrace(PTRACE_POKEDATA, pid, &addr_shellcode[i*4], 
         (int) *((int*) &shellcode[i*4])); //Copy 4 bytes each time
    if(res == -1){
      perror("Copying shellcode");
    }
  }
  if((shellcode_size % 4) != 0){
    res = ptrace(PTRACE_POKEDATA, pid, &addr_shellcode[i*4], 
         (int) *((int*) &shellcode[i*4])); //Copy the last 3- bytes if necessary
    if(res == -1){
      perror("Copying shellcode");
    }
  }

Le shellcode a été copié, il ne reste plus qu’à mettre à jour esp et eip en les faisant pointer sur le shellcode. En fait, nous décalons légèrement eip afin d’être sûr de tomber au milieu des nops.

  //Make eip and esp point to the shellcode
  printf("[+] Setting eip and esp...n");
  regs.eip = (int) addr_shellcode+2;
  regs.esp = (int) addr_shellcode;
  res = ptrace(PTRACE_SETREGS, pid, NULL, &regs);
  if(res == -1){
    perror("Setting eip and esp");
  }

Mission accomplie, plus qu’à se détacher pour libérer le processus.

  //Detach from the process
  printf("[+] Detaching...n");
  res = ptrace(PTRACE_DETACH, pid, NULL, NULL);
  if(res == -1){
    perror("Detaching");
  }

Pour comprendre en détails les arguments de chaque appel à ptrace(), je vous conseille fortement de lire le manuel.

Conclusion

Ca y est, nous venons d’arriver au bout de l’injection. J’espère que vous avez désormais une idée plus claire sur le fonctionnement général de l’injection de code sous Linux. Cela m’aura pris 3 jours pour arriver à un prototype fonctionnel, mais je ne suis vraiment pas déçu compte tenu du résultat. Si vous avez des remarques, n’hésitez pas !

Références

• [1] Linux X86 run-time process manipulation, skape, Uninformed, 2003

Rappels théoriques

Tout d’abord, il convient de faire quelques rappels sur la compilation et l’édition de liens des binaires. Quand on compile un programme qui fait appel à des fonctions situées dans d’autres bibliothèques (telles que la librairie standard), l’édition de liens peut être faite de deux façons différentes. La première méthode, dite statique, consiste à intégrer à l’exécutable toutes les librairies dont il a besoin pour fonctionner. A l’exécution, tous les symboles sont donc résolus, et les appels sont immédiats. Si cette méthode a été la plus utilisée dans les versions anciennes des OS, elle est toutefois largement dépassée. En effet, il s’agit d’un gouffre à espace disque, puisqu’elle oblige à dupliquer chaque librairie autant de fois qu’il y a d’exécutables qui l’utilisent. Les exécutables générés sont donc volumineux, puisqu’il suffit par exemple d’un simple appel à printf() pour que toute la librairie standard du C soit intégrée à l’exécutable !

Depuis les versions « récentes » de Linux, c’est la deuxième méthode d’édition de liens, dite dynamique, qui est utilisée par défaut. Avec cette méthode, chaque librairie est compilée une fois pour toute dans une librairie dynamique, ou partagée (shared) ayant l’extension .so (équivalent des .dll sous Windows). Lorsque l’on compile un programme qui y fait référence, on y insère juste le nom du symbole (fonction ou variable) dont il a besoin, ainsi que le nom de la librairie. C’est à l’exécution du programme que l’éditeur de liens dynamique (ou dynamic linker), nommé ld.so, charge les libraires nécessaire et effectue la résolution des symboles manquants en temps réel. C’est donc la vitesse d’exécution qui s’en retrouve pénalisée, même si nous verrons que cette perte est toutefois relative car compensée par un système de mise en cache des adresses.

Enfin, il convient de clarifier la notion de PIC, ou Position Independant Code. Un code exécutable est dit PIC s’il peut être mappé à l’importe quelle région mémoire tout en pouvant s’exécuter convenablement. Dans de tels exécutables, aucune adresse absolue ne doit apparaître, puisque si l’exécutable se retrouve translaté en mémoire, les adresses absolues ne seront plus valides. Dans Linux, les librairies dynamiques sont en PIC. C’est le linker dynamique, ld.so, qui les charge en mémoire à l’exécution, et leur place en mémoire peut varier d’une exécution à une autre. Ainsi, l’adresse des fonctions de la libraire standard, telles que printf(), changent de place à chaque exécution. Pourtant, un programme qui utilise printf() n’est compilé qu’une seule fois. Comment les processus arrivent-ils donc à s’exécuter tout en prenant en compte cette variation d’adresses ? C’est là tout l’objectif de cet article…

Un programme de test

Place à la pratique ! Dans la suite, je considérerais que nous somme sur une Ubuntu Hardy (noyau 2.6.24), avec gcc 4.2.3 et gdb 6.8. Nous allons utiliser le programme en C suivant :

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(){
  char c1[] = "chaine1";
  char c2[] = "chaine2";

  int res = strcmp(c1, c2);

  printf("c1 == c2 ? %dn", res);

  return 0;
}

Pour illustrer ce que nous venons de voir, compilons-le avec les deux méthodes, statique et dynamique :

$ gcc -o bin_str bin_str.c
$ gcc -static -o bin_str_static bin_str.c

Notez au passage que gcc linke les exécutable dynamiquement par défaut, et que l’option -static permet de forcer l’édition de liens statique. A l’exécution, les deux produisent exactement le même résultat :

$ ./bin_str
c1 == c2 ? -1
$ ./bin_str_static
c1 == c2 ? -1

Cependant, quand on compare la taille des exécutables…

$ ls -lh bin_str bin_str_static
-rwxrwxrwx 1 root root 6,6K 2008-07-21 19:12 bin_str
-rwxrwxrwx 1 root root 545K 2008-07-21 19:12 bin_str_static

On constate que le binaire lié statiquement (545K) est 80 fois plus volumineux que le binaire lié dynamiquement (qui ne pèse que 6.6K) ! En effet, c’est toute la librairie standard qui a été incorporée au binaire durant l’édition de liens.

Lançons-les avec gdb et désassemblons le main de chacun :

$ gdb ./bin_str_static
(gdb) disas main
Dump of assembler code for function main:
...
0x0804823b <main+75>:   call   0x804dd70 <strcmp>
...
0x08048251 <main+97>:   call   0x8048c70 <printf>
...
(gdb) quit

$ gdb ./bin_str
(gdb) disas main
Dump of assembler code for function main:
...
0x0804844f <main+75>:   call   0x8048364 <strcmp@plt>
...
0x08048465 <main+97>:   call   0x8048344 <printf@plt>
...

On constate que dans le binaire lié statiquement, printf() et strcmp() ont bien été intégrées dans la région .text de l’exécutable. Dans le binaire lié dynamiquement, les deux appels n’ont cependant pas lieu dans la .text, mais dans une région spécifique à l’édition de lien dynamique : la .plt. La PLT, pour Procedure Linkage Table, est une table sertvant à faire le lien avec les fonctions situées dans des bibliothèques dynamiques.

La PLT et la GOT

Dans la suite, on ne travaillera évidemment qu’avec le binaire lié dynamiquement. Listons les régions actuellement mapées dans l’espace mémoire de l’exécutable:

(gdb) info files
...
0x080482e4 - 0x08048314 is .init
0x08048314 - 0x08048374 is .plt
0x08048380 - 0x0804852c is .text
0x0804852c - 0x08048548 is .fini
0x08048548 - 0x0804856f is .rodata
0x08048570 - 0x08048574 is .eh_frame
0x08049574 - 0x0804957c is .ctors
0x0804957c - 0x08049584 is .dtors
0x08049584 - 0x08049588 is .jcr
0x08049588 - 0x08049658 is .dynamic
0x08049658 - 0x0804965c is .got
0x0804965c - 0x0804967c is .got.plt
0x0804967c - 0x08049688 is .data
0x08049688 - 0x0804968c is .bss

La région .plt est donc mappée entre les adresses 0×08048314 et 0×08048374. Il est important de noter que cette section se trouve à des adresses fixes. On vérifie au passage que les adresses appelées par les deux calls du main (0×8048364  pour strcmp et 0×8048344 pour printf) appartiennent bien à cette zone. Désassemblons à présent la région .plt :

(gdb) disas 0x08048314 0x08048374
Dump of assembler code from 0x8048314 to 0x8048374:
0x08048314 <_init+48>:  pushl  0x8049660
0x0804831a <_init+54>:  jmp    *0x8049664
0x08048320 <_init+60>:  add    %al,(%eax)
0x08048322 <_init+62>:  add    %al,(%eax)
0x08048324 <__gmon_start__@plt+0>:      jmp    *0x8049668
0x0804832a <__gmon_start__@plt+6>:      push   $0x0
0x0804832f <__gmon_start__@plt+11>:     jmp    0x8048314 <_init+48>
0x08048334 <__libc_start_main@plt+0>:   jmp    *0x804966c
0x0804833a <__libc_start_main@plt+6>:   push   $0x8
0x0804833f <__libc_start_main@plt+11>:  jmp    0x8048314 <_init+48>
0x08048344 <printf@plt+0>:      jmp    *0x8049670
0x0804834a <printf@plt+6>:      push   $0x10
0x0804834f <printf@plt+11>:     jmp    0x8048314 <_init+48>
0x08048354 <__stack_chk_fail@plt+0>:    jmp    *0x8049674
0x0804835a <__stack_chk_fail@plt+6>:    push   $0x18
0x0804835f <__stack_chk_fail@plt+11>:   jmp    0x8048314 <_init+48>
0x08048364 <strcmp@plt+0>:      jmp    *0x8049678
0x0804836a <strcmp@plt+6>:      push   $0x20
0x0804836f <strcmp@plt+11>:     jmp    0x8048314 <_init+48>
End of assembler dump.

Globalement, on constate que la section .plt est composée de plusieurs sous-sections de taille égale (0×10 soit 16 octets), que nous appellerons entrées. L’entrée 0 (composée des 4 premières instructions) est un peu spéciale ; nous y reviendrons plus tard. Les autres entrées, à compter de la 1 jusqu’à la dernière, sont composées de 3 instructions qui suivent toujours le même schéma. Un premier jmp a lieu, dont l’adresse de saut n’est pas explicitement donnée dans l’instruction, mais par l’intermédiaire d’un pointeur. Par exemple, dans le cas de l’entrée 3 correspondant à printf, l’adresse de saut se trouve dans les 4 octets pointés par l’adresse 0×8049670 qui fait donc office de pointeur. On remarque que la 2ème instruction de l’entrée 0 comporte aussi un jmp avec pointeur. En regardant de plus près chaque pointeur, y compris celui de l’entrée 0 (0×8049664), on s’aperçoit qu’ils se trouvent tous les uns à la suite des autres. En effet, on a ici : 0×8049664, 0×8049668, 0x804966c, 0×8049670, 0×8049674, et 0×8049678. Pour savoir où se trouvent ces pointeurs, il suffit de regarder à nouveau la liste des sections mappées en mémoire :

(gdb) info files
...
0x0804957c - 0x08049584 is .dtors
0x08049584 - 0x08049588 is .jcr
0x08049588 - 0x08049658 is .dynamic
0x08049658 - 0x0804965c is .got  <=====
0x0804965c - 0x0804967c is .got.plt

Ces adresses se situent donc dans la section nommée .got.plt. Les régions nommées ici .got et .got.plt font en réalité partie d’une table, que l’on nomme la GOT, pour Global Offset Table. Le rôle de cette table sera explicité dans la suite.

Affichons maintenant son contenu. Étant donné que cette région contient des pointeurs, il s’agit de données et non d’instructions ; pour afficher son contenu il convient donc d’utiliser l’instruction x de gdb, et non pas disas. De plus, la commande précédente nous indique que la section fait 0×20 = 32 octets de long, soit 8 pointeurs de 4 octets.

(gdb) x/8x 0x0804965c
0x804965c <_GLOBAL_OFFSET_TABLE_>:      0x08049588      0x00000000
                                        0x00000000      0x0804832a
0x804966c <_GLOBAL_OFFSET_TABLE_+16>:   0x0804833a      0x0804834a
                                        0x0804835a      0x0804836a

Je rappelle que pour le moment, le programme n’a pas encore été lancé. Le contenu de cette section est fixe, du moins avant chaque exécution. Il est tout à fait possible de le voir en utilisant d’autres outils tels que objdump.

Comme nous venons de le voir, les entrées de la PLT référencent des pointeurs situés dans la GOT. Pour comprendre le rôle de ces deux tables, regardons comment se déroule un appel à strcmp(). Cette fonction est située dans l’entrée 3 de la PLT :

0x08048364 <strcmp@plt+0>:      jmp    *0x8049678
0x0804836a <strcmp@plt+6>:      push   $0x20
0x0804836f <strcmp@plt+11>:     jmp    0x8048314 <_init+48>

Le 1er jmp référence un pointeur (0×8049678) situé dans la GOT. Voyons ce qu’il contient :

(gdb) x 0x8049678
0x8049678 <_GLOBAL_OFFSET_TABLE_+28>:   0x0804836a

Sa valeur veut 0x0804834a, qui correspond… à une adresse de la PLT, et plus précisément à l’adresse de l’instruction juste après le jmp. En d’autres termes, lorsque strcmp() sera appelée, on saute dans la PLT, et on exécute le 1er jmp, qui se contente de sauter sur l’instruction suivante. Cela peut paraître inutile à première vue, mais nous verrons l’astuce qui se cache derrière plus tard. Continuons le fil de l’exécution : après ce 1er jmp, on rencontre un push, qui empile une certaine valeur, ici 0×20. Enfin, on rencontre un jmp, et en examinant l’adresse de saut on s’aperçoit qu’il nous emmène sur l’entrée 0 de la PLT.

Une fois sur l’entrée 0, on rencontre deux instructions (les deux suivantes ne sont pas vraiment des instructions, mais correspondent aux opcodes 0×0000) :

0x08048314 <_init+48>:  pushl  0x8049660
0x0804831a <_init+54>:  jmp    *0x8049664

On commence par empiler une valeur, qui se révèle être l’entrée 1 de la GOT. On effectue ensuite un jmp sur le contenu d’un pointeur, se situant lui aussi dans la GOT mais à l’entrée 2. Pour le moment, ce pointeur ne contient que des zéros, vu que l’exécution n’a pas encore commencée. Plaçons un breakpoint sur l’appel à strcmp(), et examinons la valeur du pointeur.

(gdb) b *0x0804844f         //Correspond au call   0x8048364 <strcmp@plt>
Breakpoint 1 at 0x804844f

(gdb) r
Starting program: /media/echange/Hacking/Reversing_Linux/plt_got/bin_str

Breakpoint 1, 0x0804844f in main ()
Current language:  auto; currently asm

(gdb) x 0x8049664
0x8049664 <_GLOBAL_OFFSET_TABLE_+8>:    0xb7f12c40

On constate qu’une fois le programme lancé, la valeur du pointeur a été modifiée. C’est la procédure de lancement de l’exécutable qui a en fait initialisé cette valeur. Où pointe-t-elle ?

(gdb) info files
...
0x08049658 - 0x0804965c is .got
0x0804965c - 0x0804967c is .got.plt
0x0804967c - 0x08049688 is .data
0x08049688 - 0x0804968c is .bss
0xb7f000f4 - 0xb7f001b4 is .hash in /lib/ld-linux.so.2
0xb7f001b4 - 0xb7f00298 is .gnu.hash in /lib/ld-linux.so.2
0xb7f00298 - 0xb7f00468 is .dynsym in /lib/ld-linux.so.2
0xb7f00468 - 0xb7f005fc is .dynstr in /lib/ld-linux.so.2
0xb7f005fc - 0xb7f00636 is .gnu.version in /lib/ld-linux.so.2
0xb7f00638 - 0xb7f00700 is .gnu.version_d in /lib/ld-linux.so.2
0xb7f00700 - 0xb7f00760 is .rel.dyn in /lib/ld-linux.so.2
0xb7f00760 - 0xb7f00788 is .rel.plt in /lib/ld-linux.so.2
0xb7f00788 - 0xb7f007e8 is .plt in /lib/ld-linux.so.2
0xb7f007f0 - 0xb7f157af is .text in /lib/ld-linux.so.2  <=====
0xb7f157b0 - 0xb7f158e1 is __libc_freeres_fn in /lib/ld-linux.so.2
0xb7f15900 - 0xb7f19320 is .rodata in /lib/ld-linux.so.2
0xb7f19320 - 0xb7f1941c is .eh_frame_hdr in /lib/ld-linux.so.2
0xb7f1941c - 0xb7f19850 is .eh_frame in /lib/ld-linux.so.2
0xb7f1acc0 - 0xb7f1af28 is .data.rel.ro in /lib/ld-linux.so.2
0xb7f1af28 - 0xb7f1afe0 is .dynamic in /lib/ld-linux.so.2
0xb7f1afe0 - 0xb7f1afe8 is .got in /lib/ld-linux.so.2
0xb7f1aff4 - 0xb7f1b014 is .got.plt in /lib/ld-linux.so.2
0xb7f1b020 - 0xb7f1b5b0 is .data in /lib/ld-linux.so.2
0xb7f1b5b0 - 0xb7f1b5b4 is __libc_subfreeres in /lib/ld-linux.so.2
0xb7f1b5b4 - 0xb7f1b668 is .bss in /lib/ld-linux.so.2
0xb7d9c174 - 0xb7d9c194 is .note.ABI-tag in /lib/tls/i686/cmov/libc.so.6
0xb7d9c194 - 0xb7d9fcbc is .gnu.hash in /lib/tls/i686/cmov/libc.so.6
0xb7d9fcbc - 0xb7da8a8c is .dynsym in /lib/tls/i686/cmov/libc.so.6
0xb7da8a8c - 0xb7dae274 is .dynstr in /lib/tls/i686/cmov/libc.so.6
...

La région contenant cette adresse d’est rien d’autre que la .text du linker dynamique, ld.so ! On se trouve dans la fonction du linker permettant d’appeler la véritable fonction strcmp().

La résolution des symboles

Mais comment le linker sait-il qu’il faut appeler strcmp() et pas une autre fonction ? Tout simplement grâce au push 0×20 précédent : 0×20 correspond en fait à un offset correspondant ici à strcmp(). Les instructions de la PLT l’ont empilé afin de le passer en paramètre à la fonction du linker.

Désassemblons cette fonction :

(gdb) disas 0xb7ff6c40 0xb7ff6c40+28
//Le +28 a été trouvé en tatonnant jusqu'à trouver un ret
Dump of assembler code from 0xb7f12c40 to 0xb7f12c5c:
0xb7f12c40:     push   %eax
0xb7f12c41:     push   %ecx
0xb7f12c42:     push   %edx
0xb7f12c43:     mov    0x10(%esp),%edx
0xb7f12c47:     mov    0xc(%esp),%eax
0xb7f12c4b:     call   0xb7f0d350
0xb7f12c50:     pop    %edx
0xb7f12c51:     mov    (%esp),%ecx
0xb7f12c54:     mov    %eax,(%esp)
0xb7f12c57:     mov    0x4(%esp),%eax
0xb7f12c5b:     ret    $0xc
End of assembler dump.

Cette fonction est relativement courte ; elle ne fait en réalité qu’appeler la véritable fonction de résolution des adresses. Lorsqu’elle est appelée, le sommet de pile contient une adresse (correspondant à GOT[1], qui a été pushée à l’entrée 0 de la PLT), et juste en dessous se trouve l’index de strcmp, soit 0×20. Vérifions en plaçant un breakpoint au début et en examinant la pile :

(gdb) b *0xb7f12c40
Breakpoint 2 at 0xb7f12c40

(gdb) c
Continuing.

Breakpoint 2, 0xb7f12c40 in ?? () from /lib/ld-linux.so.2

(gdb) x/2x $esp
0xbfbf50b4:     0xb7f1b668      0x00000020

Vérifions que le 1er pointeur correspond bien à l’entrée 1 de la GOT :

(gdb) x 0x8049660
0x8049660 <_GLOBAL_OFFSET_TABLE_+4>:    0xb7f1b668

Bingo ! On a bien en sommet de pile l’adresse contenue dans GOT[1] et juste en dessous l’index de strcmp(), 0×20.

Revenons au code de cette fonction.

(gdb) disas 0xb7f12c40 0xb7f12c40+28
Dump of assembler code from 0xb7f12c40 to 0xb7f12c5c:
0xb7f12c40:     push   %eax
0xb7f12c41:     push   %ecx
0xb7f12c42:     push   %edx
0xb7f12c43:     mov    0x10(%esp),%edx
0xb7f12c47:     mov    0xc(%esp),%eax
0xb7f12c4b:     call   0xb7f0d350
0xb7f12c50:     pop    %edx
0xb7f12c51:     mov    (%esp),%ecx
0xb7f12c54:     mov    %eax,(%esp)
0xb7f12c57:     mov    0x4(%esp),%eax
0xb7f12c5b:     ret    $0xc
End of assembler dump.

Elle commence par 3 push, permettant de sauvegarder des registres. Ainsi, nos deux valeurs en sommet de pile vont être décalées de 3*4 = 12 octets. Juste après ces 3 push, on a deux mov. Le premier place dans %edx une valeur située sur la pile à l’offset 0×10 soit 16 = 4 * 4 octets. Il s’agit donc de l’index de strcmp(), 0×20. Le second place dans %eax la valeur suivante, soit celle de GOT[1]. Puis un appel de fonction a lieu.

On arrive alors dans une fonction relativement complexe, qui se situe toujours dans la section .text de ld.so. C’est elle qui est chargée d’effectuer la résolution des symbolesen recherchant dans les librairies. Si vous essayez de la désassembler, vous constaterez qu’elle est relativement longue et complexe. Comme ici le but n’est pas d’être exhaustif, je ne la détaillerai pas. En plus, je n’ai pas encore eu le courage de la reverser dans sesmoindres détails…

Continuons donc. Plaçons un breakpoint juste après le call de cette fonction, en 0xb7f12c50.

(gdb) b *0xb7f12c50
Breakpoint 3 at 0xb7f12c50

(gdb) c
Continuing.

Breakpoint 3, 0xb7f12c50 in ?? () from /lib/ld-linux.so.2

Les instructions suivantes manipulent des registres. Dans le cadre de cet article, seules deux instructions sont intressantes :

0xb7f12c54:     mov    %eax,(%esp)
et
0xb7f12c5b:     ret    $0xc

Le mov place la valeur de %eax en sommet de pile, tandis que le ret ordonne au CPU de continuer l’exécution du code à l’adresse située sur le sommet de pile. Autrement dit, juste après le call de la fonction de résolution des symboles, on saute sur l’adresse contenue dans %eax ! Regardons ce que vaut ce registre…

(gdb) info registers
eax            0xb7e0dd20       -1210000096
ecx            0x0      0
edx            0x8049678        134518392
ebx            0xb7ee6ff4       -1209110540
esp            0xbfbf50a8       0xbfbf50a8
ebp            0xbfbf50f8       0xbfbf50f8
esi            0xb7f1ace0       -1208898336
edi            0x0      0
eip            0xb7f12c50       0xb7f12c50
...

Que peut bien représenter l’adresse 0xb7e0dd20 ?

(gdb) info files
...
0xb7d9c174 - 0xb7d9c194 is .note.ABI-tag in /lib/tls/i686/cmov/libc.so.6
0xb7d9c194 - 0xb7d9fcbc is .gnu.hash in /lib/tls/i686/cmov/libc.so.6
0xb7d9fcbc - 0xb7da8a8c is .dynsym in /lib/tls/i686/cmov/libc.so.6
0xb7da8a8c - 0xb7dae274 is .dynstr in /lib/tls/i686/cmov/libc.so.6
0xb7dae274 - 0xb7daf42e is .gnu.version in /lib/tls/i686/cmov/libc.so.6
0xb7daf430 - 0xb7daf730 is .gnu.version_d in /lib/tls/i686/cmov/libc.so.6
0xb7daf730 - 0xb7daf770 is .gnu.version_r in /lib/tls/i686/cmov/libc.so.6
0xb7daf770 - 0xb7db2140 is .rel.dyn in /lib/tls/i686/cmov/libc.so.6
0xb7db2140 - 0xb7db2188 is .rel.plt in /lib/tls/i686/cmov/libc.so.6
0xb7db2188 - 0xb7db2228 is .plt in /lib/tls/i686/cmov/libc.so.6
0xb7db2230 - 0xb7eb2d84 is .text in /lib/tls/i686/cmov/libc.so.6  <=====
0xb7eb2d90 - 0xb7eb3de8 is __libc_freeres_fn in /lib/tls/i686/cmov/libc.so.6
0xb7eb3df0 - 0xb7eb4082 is __libc_thread_freeres_fn in /lib/tls/i686/cmov/libc.so.6
0xb7eb40a0 - 0xb7ecf090 is .rodata in /lib/tls/i686/cmov/libc.so.6
0xb7ecf090 - 0xb7ecf0a3 is .interp in /lib/tls/i686/cmov/libc.so.6
0xb7ecf0a4 - 0xb7ed1c90 is .eh_frame_hdr in /lib/tls/i686/cmov/libc.so.6
0xb7ed1c90 - 0xb7ee1544 is .eh_frame in /lib/tls/i686/cmov/libc.so.6
0xb7ee1544 - 0xb7ee19b0 is .gcc_except_table in /lib/tls/i686/cmov/libc.so.6
0xb7ee19b0 - 0xb7ee4d28 is .hash in /lib/tls/i686/cmov/libc.so.6
0xb7ee51ec - 0xb7ee51f4 is .tdata in /lib/tls/i686/cmov/libc.so.6
...

Tiens, elle se trouve dans la .text… Par hasard, ce ne serait pas l’adresse de strcmp ?

(gdb) p strcmp
$1 = {<text variable, no debug info>} 0xb7e0dd20 <strcmp>

Eh si ! Autrement dit, la fonction de résolution des symboles a résolu correctement strcmp et a placé son adresse dans %eax.

Et la GOT dans tout ça ?

Nous venons de voir le cheminement (d’un point de vue assez haut niveau) d’un appel de fonction situé dans une bibliothèque partagée. Comme on a pu le constater, chaque appel de fonction entraîne à priori une résolution de symbole, ce qui paraît fastidieux. Fort heureusement, par défaut, ld.so ne résoud pas un symbole à chaque fois qu’on tente d’y accéder, mais uniquement la 1ère fois. Par exemple, si vous avez 10 appels à strcmp() dans un programme, le 1er appel entraînera une résolution, et l’adresse de strcmp() sera gardée en mémoire pour les 9 appels suivant. C’est ce que l’on appelle l’évaluation fainéante : on ne fait que le minimum d’opération, et juste à temps.

Où et comment les adresses des symboles sont-elles gardées en mémoire une fois résolues ? Réponse : dans la GOT ! Pour le comprendre, relançons le programme et plaçons un breakpoint dans l’entrée de la PLT correspondant à strcmp.

$ gdb ./bin_str

(gdb) disas 0x08048314 0x08048374   //Les adresses de la PLT, qui restent fixes
Dump of assembler code from 0x8048314 to 0x8048374:
0x08048314 <_init+48>:  pushl  0x8049660
0x0804831a <_init+54>:  jmp    *0x8049664
0x08048320 <_init+60>:  add    %al,(%eax)
0x08048322 <_init+62>:  add    %al,(%eax)
0x08048324 <__gmon_start__@plt+0>:      jmp    *0x8049668
0x0804832a <__gmon_start__@plt+6>:      push   $0x0
0x0804832f <__gmon_start__@plt+11>:     jmp    0x8048314 <_init+48>
0x08048334 <__libc_start_main@plt+0>:   jmp    *0x804966c
0x0804833a <__libc_start_main@plt+6>:   push   $0x8
0x0804833f <__libc_start_main@plt+11>:  jmp    0x8048314 <_init+48>
0x08048344 <printf@plt+0>:      jmp    *0x8049670
0x0804834a <printf@plt+6>:      push   $0x10
0x0804834f <printf@plt+11>:     jmp    0x8048314 <_init+48>
0x08048354 <__stack_chk_fail@plt+0>:    jmp    *0x8049674
0x0804835a <__stack_chk_fail@plt+6>:    push   $0x18
0x0804835f <__stack_chk_fail@plt+11>:   jmp    0x8048314 <_init+48>
0x08048364 <strcmp@plt+0>:      jmp    *0x8049678
0x0804836a <strcmp@plt+6>:      push   $0x20
0x0804836f <strcmp@plt+11>:     jmp    0x8048314 <_init+48>
End of assembler dump.

(gdb) b *0x08048364
Breakpoint 1 at 0x8048364

(gdb) r
Starting program: /media/echange/Hacking/Reversing_Linux/plt_got/bin_str

Breakpoint 1, 0x08048364 in strcmp@plt ()
Current language:  auto; currently asm

(gdb) x 0x8049678
0x8049678 <_GLOBAL_OFFSET_TABLE_+28>:   0x0804836a

L’entrée correspondante de la GOT contient toujours l’adresse de l’instruction suivante dans la PLT. Quel intérêt ? A ce moment, il faut noter que le symbole strcmp n’est pas encore résolu, donc il est normal que cette entrée ne comporte aucune valeur intéressante. Plaçons un watchpoint sur cette entrée de la GOT afin de voir si elle change au fil du temps.

(gdb) watch *0x8049678
Hardware watchpoint 2: *134518392

(gdb) c
Continuing.
Hardware watchpoint 2: *134518392

Old value = 134513514
New value = -1209639648
0xb7f6545d in ?? () from /lib/ld-linux.so.2

Apparamment, la valeur de l’entrée a changé ! Observons sa nouvelle valeur :

(gdb) x 0x8049678
0x8049678 <_GLOBAL_OFFSET_TABLE_+28>:   0xb7e65d20

(gdb) p strcmp
$1 = {<text variable, no debug info>} 0xb7e65d20 <strcmp>

Ainsi on s’aperçoit qu’elle correspond désormais à l’adresse de strcmp(). Désormais, si le programme souhaîte faire d’autres appels à strcmp(), il n’aura plus à effectuer la résolution de symbole puisque le jmp situé dans l’entrée de la PLT référence directement l’adresse de strcmp() !

Quand cette valeur a-t-elle été écrite ? Pour cela, il suffit de regarder %eip et de voir dans quelle zone nous sommes.

(gdb) info registers
eax            0xb7e65d20       -1209639648
ecx            0x0      0
edx            0x8049678        134518392
ebx            0xb7f72ff4       -1208537100
esp            0xbfae4f58       0xbfae4f58
ebp            0xbfae4f90       0xbfae4f90
esi            0xb7f56858       -1208653736
edi            0xb7f73668       -1208535448
eip            0xb7f6545d       0xb7f6545d
eflags         0x246    [ PF ZF IF ]
cs             0x73     115
ss             0x7b     123
ds             0x7b     123
es             0x7b     123
fs             0x0      0
gs             0x33     51

(gdb) disas $eip-3 $eip+20
Dump of assembler code from 0xb7f6545a to 0xb7f65471:
0xb7f6545a:     mov    %eax,(%edx,%ecx,1)
0xb7f6545d:     lea    -0xc(%ebp),%esp
0xb7f65460:     pop    %ebx
0xb7f65461:     pop    %esi
0xb7f65462:     pop    %edi
0xb7f65463:     pop    %ebp
0xb7f65464:     ret
0xb7f65465:     xor    %edx,%edx
0xb7f65467:     jmp    0xb7f653de
0xb7f6546c:     lea    -0x2477(%ebx),%eax
...

En cherchant un peu, on remarque qu’on se trouve juste à la fin de la fonction de résolution des symboles. L’instruction responsable de l’écriture de l’adresse dans la GOT est le mov %eax,(%edx,%ecx,1). En inspectant les registres, on voit que cela correspond bien à l’opération *0×8049678 = 0xb7e65d20 (l’adresse de strcmp).

On notera que cette méthode est comparable aux systèmes de caches des processeurs : l’objectif est d’accelérer les accès futurs aux fonctions en accédant une fois pour toute à une donnée et en la plaçant dans une zone d’accès plus rapide. Pour information, il est tout à fait possible de désactiver ce système de mise en cache en utilisant des variables d’environnement reconnues par ld.so. Par exemple, la variable d’environnement LD_BIND_NOT, si elle est définie, permet ainsi de désactiver complétement l’écriture des adresses dans la GOT, tandis que la variable LD_BIND_NOW indique à ld.so d’effectuer toutes les résolutions dès le début, donc de remplir la GOT dès le lancement de l’exécutable. Pour plus de renseignements, consultez le man de ld.so.

Récapitulatif

Le schéma suivant retrace le fil de l’exécution lors d’un appel à strcmp(), et récapitule les différents liens entre la PLT et la GOT.

1er appel de strcmp : symbole non encore résolu

main:
...
call   0x8048364 <strcmp@plt> ----+
mov    %eax,-0x1c(%ebp)           |
...                               |
                                  |
                                  |
0x8048364 (Entrée de la PLT) : <--+
jmp    *0x8049678  -----------------------> 0x8049678 (Entrée de la GOT) :
push   $0x20  <------------------------------ 0x0804836a
jmp    0x8048314 <_init+48> --------+
                                    |
                                    |
0x8048314 (Entrée 0 de la PLT) : <--+
pushl  0x8049660
jmp    *0x8049664  -----------------------> 0x8049664 (Header de la GOT) :
                                              0xb7f12c40 --+
                                                           |
                                                           |
0xb7f12c40 (.text de ld.so, résolution + appel) : <--------+
push   %eax              // Sauvegarde de registres
push   %ecx
push   %edx
mov    0x10(%esp),%edx   // Récupération du code de la fonction strcmp (0x20)
mov    0xc(%esp),%eax
call   0xb7f4c350  -------> Appel de la fonction de résolution des symboles
                            L'adresse du symbole (strcmp) est placé dans %eax.
                            L'entrée de la .got est patchée avec cette adresse.
... <---------------------- Retour de la fonction
mov    %eax,(%esp)       // L'adresse de strcmp (0xb7e65d20) est empilée
...
ret    $0xc ------------------------------+ // On saute sur strcmp
                                          |
                                          |
0xb7e65d20 (strcmp, .text de la libc): <--+
...
ret                      // Retour au main

2ème appel de strcmp : symbole déjà résolu

main:
...
call   0x8048364 <strcmp@plt>  ---+
mov    %eax,-0x1c(%ebp)           |
...                               |
                                  |
                                  |
0x8048364 (Entrée de la .plt) : <-+
jmp    *0x8049678  ----------------> 0x8049678 (Entrée de la GOT) :
                                       0xb7e65d20 --+ // Symbole résolu !
push   $0x20                                        | // Les instructions
jmp    0x8048314 <_init+48>                         | // suivantes ne sont pas
                                                    | // exécutées.
                                                    |
0xb7e65d20 (strcmp, .text de la libc): <------------+
...
ret                      // Retour au main

Références

Comme le précise l’introduction, je n’avais pas Internet quand j’ai réalisé cet article ; je ne peux donc pas citer de page Web. Je me suis beaucoup aidé de la documentation off-line des programmes que j’avais sous la main, à savoir :

• Le man de ld.so (man ld.so)
• L’aide de gdb (commande help de gdb)

J’ai donc galéré une première fois pour changer l’encodage d’Ubuntu, souhaitant le passer en ISO8859-15. Des tas de techniques existent, mais chez moi aucune n’a marché jusqu’à ce que je sois finalement tombé sur un excellent post qui explique la manipulation, que je me suis permis de le traduire :

Changer les locales supportées
Éditez le fichier /var/lib/locales/supported.d/local (en root) en y ajoutant les lignes suivantes :

fr_FR ISO-8859-1
fr_FR@euro ISO-8859-15

Regénérer les  locales
Lancez la commande suivante :

sudo dpkg-reconfigure locales

Changer la locale par défaut
Éditez le fichier /etc/environment pour y ajouter :

LANGUAGE="fr_FR:fr"
LANG="fr_FR@euro"

Rebooter !

Cela permet ainsi de résoudre, dans un premier temps, les problèmes liés à l’encodage par défaut du système. Si vous lancez la commande locale charmap dans un shell, vous devriez obtenir l’affichage suivant :

ISO-8859-15

Dans un deuxième temps, j’ai rencontré un deuxième problème : lorsque je connecte mon disque dur externe, il se monte, mais il est incapable de gérer les accents dans les noms de fichiers. Pour s’en rendre compte, c’est très simple : il suffit de tenter de créer un fichier avec un nom comportant un accent. Chez moi, konqueror m’affichait une erreur…

D’après mes recherches, ce problème serait dû à HAL, le module chargé de monter automatiquement les disques, car celui-ci monte par défaut tous les systèmes de fichiers… en UTF8 ! Pour résoudre ce problème, il m’a fallu un peu de temps avant de trouver cette manip :

Supprimer le lien symbolique /sbin/mount.ntfs-3g :

 sudo rm /sbin/mount.ntfs-3g

Le remplacer (créer un fichier de même nom) avec ce contenu :

#!/bin/bash
/bin/ntfs-3g $1 $2 -o locale=fr_FR@euro

Le rendre exécutable : sudo chmod +x /sbin/mount.ntfs-3g

Et voila ! Normalement, en rebranchant le disque dur externe, celui-ci est correctement monté et les accents sont supportés.

Merci aux deux auteurs de ces solutions !

Tout d’abord, téléchargez les derniers drivers d’Aircrack pour profiter de l’injection, puis décompressez-les :

wget http://rt2x00.serialmonkey.com/rt73-cvs-daily.tar.gz
tar -zxvf rt73-cvs-daily.tar.gz
cd rt73-cvs*/Module

Si ce n’est pas déjà fait, blacklistez les anciens modules qui peuvent empêcher rt73 de fonctionner en éditant /etc/modprobe.d/blacklist et en y ajoutant :

blacklist rt73usb
blacklist rt2570
blacklist rt2500usb
blacklist rt2x00lib

Au cas où, déchargez ces modulez éventuels :

sudo modprobe -r rt73usb
sudo modprobe -r rt2570
sudo modprobe -r rt2500usb
sudo modprobe -r rt2x00lib

Puis compilez et installez le module :

make
sudo make install

Si jamais vous obtenez un message du style :

!!! WARNING: Module file much too big (>1MB)
!!! Check your kernel settings or use 'strip'

Alors lancez les commandes :

make
strip -S rt73.ko
sudo make install

Ensuite, copiez le module :

sudo mkdir /lib/modules/$(uname -r)/extra
sudo cp rt73.ko /lib/modules/$(uname -r)/extra/rt73.ko

Puis chargez-le :

sudo depmod -ae
sudo modprobe rt73

Normalement, vous devriez pouvoir activer votre interface :

sudo ifconfig wlan0 up

Notez que désormais l’interface a un nom du style wlan* et non plus en rausb*.

Maintenant, votre connexion Wifi et Aircrack devraient fonctionner à nouveau. Vous devrez très certainement éditer votre /etc/network/interfaces pour remplacer les occurrences de rausb0 par wlan0.

Et voila ! Au besoin, référez-vous au README situé dans l’archive des drivers, il est bien fourni et décrit les configurations classiques (WEP, WPA, WPA2) de la carte.

Sources :

• Forum Ubuntu
• Aircrack, drivers rt73

#!/bin/bash

LOG_STDIN=/path/du/log/stdin.log
LOG_STDOUT=/path/du/log/stdout.log
PROG="/path/du/prog avec parametres eventuels"

tee $LOG_STDIN | $PROG | tee $LOG_STDOUT

Comme vous pouvez le voir, ce script repose sur la commande tee qui permet de dupliquer un flux.Il suffit de lancer ce script à la place du programme que vous souhaitez espionner. Cette astuce pourra être utile aussi bien au développeur qu’au reverse-engineer…

Pour la petite histoire, j’ai développé ce petit script dans le cadre d’un projet d’intelligence artificielle. Le but est de réaliser un joueur artificiel de Jeu de Go. Notre équipe a choisis d’utiliser le protocole GTP qui permet de faire communiquer des joueurs avec des interfaces graphiques. Ce script nous permet donc de déboguer plus facilement notre joueur car il permet de garder une trace des trames GTP échangées. Nous l’avons également utiliser pour avoir une idée des commandes GTP échangées entre une interface comme qGo et un joueur déjà existant tel que GNUGo.

sudo update-manager -d -c

Le problème, c’est qu’update-manager indiquait qu’aucune mise à jour n’était disponible. Même en enlevant le paramètre -d, rien à faire. Le pire c’est que je n’obtenais aucun message d’erreur.

Il faut aussi préciser que j’étais contraint de passer par un proxy HTTP. Pour qu’APT fonctionne, j’avais inséré ceci dans mon /etc/apt/apt/conf :

Acquire::http::Proxy "http://mon.proxy:8080/";

De même, mon fichier /etc/wgetrc contenait la ligne :

http_proxy = http://mon.proxy:8080/

Ces deux directives permettent aux outils comme aptitude et apt-get de télécharger correctement les paquets en passant par le proxy. Jusqu’ici, tout fonctionnait correctement, du moins avec ces deux outils.

Mais revenons à mon problème de départ : update-manager ne parvenait pas à trouver les mises à jour. J’ai passé un certain temps à rechercher la solution, et j’ai finalement trouvé la réponse sur le forum officiel.

L’explication est assez bizarre. Il se trouve qu’update-manager, lorsqu’on l’utilise avec l’option -d (précisant de rechercher une mise à jour instable), ne tient pas du tout compte des deux fichiers de configuration précédents (apt.conf et wgetrc). C’est donc parce qu’il n’arrivait pas à se connecter qu’il indiquait qu’aucune mise à jour n’était disponible !

La solution est finalement très simple : il faut configurer le proxy dans Synapic ! Vu que je n’utilise jamais ce logiciel, je ne l’avais pas configuré… Je l’ai donc lancé, configuré correctement, et relancé update-manager -d. Et là, la nouvelel mise à jour était disponible…

Moralité : Même si vous ne l’utilisez pas, pensez à configurer le proxy de Synaptic, où vous risquez d’avoir des surprises !

Pour information, j’ai rajouté cette manip dans le Wiki d’Ubuntu-fr.

Pour concevoir une application parallèle, on utilise assez souvent la programmation par messages. Dans le cadre de notre projet, nous utilisons la bibliothèque LAM/MPI qui fournit toute une API permettant d’envoyer des messages à des processus tournant sur des machines distantes. De plus, le but étant d’injecter des fautes, nous avons choisit de provoquer ces fautes lors des envois et réceptions de messages. Ainsi nous pouvons facilement simuler aussi bien les pannes logicielles (déni de service) et matérielles (coupure de lien d’un réseau, paquet perdu ou corrompu). Pour détourner les fonctions fournies par la bibliothèque LAM/MPI, nous utilisons la variable d’environnement LD_PRELOAD. Cette variable des systèmes UNIX/Linux permet de charger dynamiquement une bibliothèque au lancement d’une application. Le point intéressant est que cette bibliothèque peut redéfinir des fonctions qui existent déjà dans les autres bibliothèques, donc peut potentiellement les appeler tout en modifiant leur comportement.

LD_PRELOAD permet alors de modifier le comportement d’une application tout en n’ayant pas besoin de la recompiler ! Il est toutefois important de préciser que cette technique ne permet de détourner (hooker) que les fonctions définies dans des librairies dynamiques. C’est un point crucial et qui nous a posé quelques problèmes. En effet nous utilisions au départ la librairie MPICH 1, et il se trouve que lorsqu’une application est compilée avec, les appels MPI sont liés de manière statique. Un simple appel à la commande ldd permet de le voir. C’est pourquoi nous avons choisis d’utiliser LAM/MPI à la place.

Ainsi, nous avons développé une bibliothèque dynamique (fichier .so) dont le but est de venir d’interposer entre l’application parallèle et LAM/MPI. Cette bibliothèque (que nous avons nommé bibliothèque d’interposition) redéfinit les fonctions MPI_Send() et MPI_Recv() en injectant des fautes comme des corruptions de données et des dénis de service. Les fautes ne sont pas générées de manière permanentes ; nous utilisons en plus un processus qui tourne en tâche de fond (démon) qui communique avec la librairie par l’intermédiaire d’un segment de mémoire partagé. Ce démon est en réalité un serveur utilisant CORBA. Son rôle est de rester en attente de requêtes et de dialoguer avec la librairie pour déclencher l’injection de fautes. Il surveille également l’application ainsi que le système par l’intermédiaire de sondes logicielles afin de suivre en temps réel les valeurs de quelques variables, comme la charge CPU, l’occupation mémoire, etc. Ces valeurs sont sauvegardées dans une base de données pour être retraitées plus tard par un module de statistiques.

Sur chaque machine tournent donc : une instance de l’application distribuée, une instance de la bibliothèque d’interposition, et une instance du démon. Mais en plus de tout cela, il faut être capable de déployer l’application parallèle. Nous avons donc conçu un module dédié à cela, le simulateur. Il est contrôlable en ligne de commande ou via une interface graphique. Son but est de lancer l’application parallèle, les démons et activer le détournement de fonction en exportant la variable LD_PRELOAD sur toutes les machines.

Ce projet, bien que relativement complexe, se révèle très intéressant. Cela nous a permis de découvrir et d’utiliser des libraires et des technologies très utiles, comme CORBA, MPI, Boost, MySQL++. Nous utilisons également Flex et Bison pour la conception de l’interpréteur de commandes du simulateur.

Au fut et à mesure du développement, je mettrai sans doute en ligne quelques billets exposant de façon plus détaillée la conception de certains des modules.

Compilation du driver

Voici donc la marche à suivre pour compiler et utiliser ces drivers. Tout d’abord, placez-vous en root dans le dossier /usr/src :

sudo -s

cd /usr/src

Assurez-vous d’avoir les outils pour la compilation (GCC et compagnie). Au cas où, installez le paquet build-essential :

aptitude install build-essential

Ensuite, téléchargez le driver, et décompressez-le :

wget http://homepages.tu-darmstadt.de/~p_larbig/wlan/rt73-k2wrlz-2.0.1.tar.bz2

tar jxvf rt73-k2wrlz-2.0.1.tar.bz2

Placez-vous dans le dossier du driver, compilez-le et installez-le :

cd rt73-k2wrlz-2.0.1/Module

make

make install

Si jamais vous obtenez un message d’erreur de ce type à la compilation (après « make ») :

!!! WARNING: Module file much too big (>1MB)
!!! Check your kernel settings or use 'strip'

Dans ce cas (et dans ce cas seulement), il faut utiliser l’utilitaire « strip » et recompiler le driver :

strip -S rt73.ko

make

make install

Une fois que c’est fait, il faut bannir (blacklister) les modules Wifi de base d’Ubuntu en ajoutant ceci à la fin du fichier /etc/modprobe.d/blacklist, si ce n’est pas déjà fait :

blacklist rt73usb
blacklist rt2570
blacklist rt2500usb
blacklist rt2x00lib

Pour être sur que l’ancien driver ne provoque pas de conflit, déchargeons tous les modules susceptibles de causer des problèmes :

modprobe -r rt73usb

modprobe -r rt2570

modprobe -r rt2500usb

modprobe -r rt2x00lib

Testons maintenant le driver ! Allumez votre interface (si vous disposez d’un bouton Wifi sur votre machine), chargez le driver et testez l’interface :

modprobe rt73

ifconfig rausb0 up

Normalement, ça marche ! Au cas où ça ne serait pas le cas, une possibilité est de prendre une version antérieure du driver sur la page http://homepages.tu-darmstadt.de/~p_larbig/wlan/ (allez dans la section « RaLink RT73 USB Enhanced Driver« ) et réeffectuez les étapes précédentes (en adaptant le nom de l’archive).

Utiliser le WPA

Pour ceux qui sont toujours connectés en WEP, permettez-moi de vous rappeler que cette méthode d’encryption est depuis longtemps dépassée car trop facilement crackable ! Avec Aircrack et quelques connaissances, il faut environ 30min pour cracker une clé, et avec la dernière version (et un peut de chance) on peut même atteindre quelques minutes seulement. Si j’ai le temps, je montrerai dans un prochain billet comment utiliser Aircrack pour casser une clé WEP. Mais en attendant, passez donc au WPA !

Pour activer le WPA sur l’interface, ce n’est pas bien compliqué. Tout se passe dans le fichier /etc/network/interfaces. Il faut que vous ajoutiez des lignes de configuration basées sur ce modèle :

auto rausb0
iface rausb0 inet dhcp
        pre-up ifconfig rausb0 up  # a enlever si ca marche pas
        pre-up iwconfig rausb0 essid Livebox-XXXX  # le nom du réseau
        pre-up iwconfig rausb0 mode managed
        pre-up iwpriv rausb0 set AuthMode=WPAPSK
        pre-up iwpriv rausb0 set EncrypType=TKIP
        pre-up iwpriv rausb0 set WPAPSK="XXXXXXXXXXXXXXXXXXXXXXXXXX" # la clé WPA

Cette configuration est celle que j’utilise pour me connecter sur ma livebox en WPA. Adaptez-la si besoin. Et assurez-vous que le WPA est activé sur la borne… Attention toutefois pour les Livebox Inventel : il faut absolument prendre l’option « WPA seulement » et pas « WEP et WPA » dans le menu de configuration, sinon cela ne marche pas. Si votre borne Wifi nécessite l’appui sur une touche pour permettre l’association Wifi de nouveaux périphériques, appuyez dessus sinon vous ne pourrez pas vous connecter (c’est le cas pour les Livebox)

Ensuite, redémarrez les interfaces réseau :

/etc/init.d/networking restart

Et si tout va bien, vous devriez obtenir une adresse IP et vous serez alors connectés ! Si jamais cela ne marche pas, c’est probablement du à une erreur dans la clé, ou bien à un conflit avec une autre interface. En effet, n’essayez pas de vous connecter à la fois en filaire et en Wifi, car au niveau des adresses IP attribuées par le DHCP, il risque d’y avoir des problèmes (elles seront toutes les deux dans le même réseau). Essayez de désactiver votre interface réseau en tapant :

ifconfig eth0 down

Assurez-vous également qu’il n’y a pas de ligne du type « auto eth0″ dans le fichier /etc/network/interfaces, et redémarrez une nouvelle fois les interfaces.

Si vous obtenez un message du style

DHCPACK from 192.168.1.1
bound to 192.168.1.161 -- renewal in 32485 seconds.

alors vous êtes connectés !

Attention, le module installé ne fonctionnera pas avec les outils graphiques du style NetworkManager. Enfin, n’oubliez pas qu’à chaque mise à jour de noyau, il faudra le recompiler (refaire un « make » et « make install » dans le dossier des sources du driver).

Conclusion

J’espère que ce billet vous aura été utile, car trouver toute cette procédure m’aura demandé un certain temps de recherche. Voici quelques pages qui m’ont pas mal servi :

• La page des drivers rt73 sur Arcrack
• Les drivers Ralink supportant l’injection
• La page WPA sur la doc d’Ubuntu-fr (la partie intéressante est à la fin, nommée « Méthode alternative« )

Enfin bref, j’ai décidé récemment d’en finir avec ces problèmes et de revenir à une installation. J’ai réinstallé XP et Kubuntu 7.10 proprement à partir des CD. En plus, j’étais motivé pour tester l’édition 64bits, alors c’était le moment ou jamais. Cependant, comme tout installation, cela nécessite du temps, et rencontrer quelques soucis n’est pas rare… J’en profite donc pour détailler ici quelques problèmes que j’ai eu et les solutions que j’ai trouvées pour les résoudre. J’explique aussi comment restaurer les paramètres principaux de l’ancienne distribution sur la nouvelle, en espérant que cela aide les gens qui hésitent encore à réinstaller leur OS ou qui ne savent pas comment configurer certains paramètres du système.

Sauvegarde

Avant tout, je commence par sauvegarder mes données personnelles sur un disque dur externe :

• ma partition /home/ avec tous mes fichiers et paramètres personnels
• le dossier /etc/ contenant les fichiers de configuration
• les bases de données MySQL, situées dans le dossier /var/mysql/lib/

Ceci étant fait, je boote sur un cd live de Kubuntu Gutsy et je supprime la totalité de mes partitions avec gparted. Souhaitant installer un dual boot WinXP / Kubuntu, je commence naturellement à installer Windows étant donné que si je fais l’inverse, celui-ci écrasera Grub… Une fois Windows installé (je vous passe les détails, ce n’est pas le sujet du billet) sur la moitié de mon disque, je lance l’Alternate CD de Kubuntu 7.10 x64 et j’installe le système. Tout se passe bien jusqu’au redémarrage : là commence l’aventure…

Les problèmes après l’installation

Tout d’abord, je constate que dès que Grub lance le noyau, mon écran devient noir et affiche «NO SIGNAL»… Visiblement, il y a un problème concernant la résolution de l’écran. Deuxième souci : les disques durs se mettent à gratter et le PC semble figé. Par contre cette fois-ci je sais d’où vient le coupable : fsck s’est lancé au démarrage et à fait un scan des disques alors que je ne lui avais rien demandé. Toujours à l’aveuglette (vu que l’écran est noir) je quitte ce scan par Ctrl Alt Suppr. 30 secondes plus tard, l’écran se rallume et le curseur de la souris apparaît ainsi que l’écran de KDM, victoire ! Mais étant donné que j’ai stoppé fsck, le noyau n’a pas chargé les partitions (hormis la principale). Je retourne donc en mode console, avec Ctrl Alt F1. Je me logue, et je monte manuellement la partition /home avec :

sudo mount /home

Ensuite, je retourne en graphique (Ctrl Alt F7) et je me logue et KDE se charge sans problème. Il est désormais temps de configurer tout ça… après avoir résolu les deux soucis précédents bien sûr. Concernant l’écran noir, après un peu de recherche, il semblerait que le paquet usplash (gérant le splashscreen du démarrage) soit buggé pour AMD64. Je désactive donc le splashscreen en éditant le fichier de conf de Grub :

sudo nano -w /boot/grub/menu.lst

Je retire simplement le mot «splash» situé à la fin de la ligne concernant mon noyau.

Pour éviter que fsck ne se lance à chaque démarrage sur mon disque, j’édite /etc/fstab et je remplace la ligne suivante

UUID=XXXX-XXXX  /media/sdb5     vfat    defaults,utf8,umask=007,gid=46 0       1

par :

UUID=XXXX-XXXX  /media/sdb5     vfat    iocharset=iso8859-15,

codepage=850,umask=000 0       0 # sur la meme ligne

Cette ligne concerne en fait mon disque dur Sata qui a la fâcheuse tendance à se faire checker par fsck à chaque fois que j’installe Ubuntu ; je commence à avoir l’habitude car cela m’était arrivé quand j’avais installé ce même OS cet été sur un autre PC. En fait, il suffisait de remplacer le dernier 1 par un 0, mais étant donné que j’ai conservé mon ancien fstab, j’ai carrément collé la ligne dans le fichier. Les options que j’ai changé servent à ne pas avoir de problèmes pour accéder au disque en tant que simple utilisateur, et pour (normalement) ne pas avoir de soucis dans l’encodage des noms de fichiers.

Configuration générale

Les deux problèmes étant résolus, passons à la configuration. Étant donné que je suis en chambre universitaire et que notre réseau utilise un proxy, il me faut rajouter le proxy dans les paramètres de wget :

sudo nano -w /etc/wgetrc

Il suffit de décommenter les deux lignes correspondant au proxy en mettant le bon host et port :

#http_proxy = http://proxy.yoyodyne.com:18023/

#ftp_proxy = http://proxy.yoyodyne.com:18023/

Ensuite, je constate que KDE a détecté ma carte graphique, je clique donc sur l’icône en bas à droite ce qui ouvre le gestionnaire de pilotes propriétaires (restricted-manager-kde) et j’active le pilote. On me demande de redémarrer mais je n’ai pas encore fini alors je refuse.

Je continue la configuration en éditant le fichier des sources d’APT :

sudo nano -w /etc/apt/sources.list

Je commente la ligne correspondant au CD qui n’a pas été commentée, j’en profite pour décommenter tous les dépots, je quitte et je met la liste des paquets à jour avec le classique

sudo aptitude update

Firefox

Maintenant qu’APT est configuré, j’installe quelques programmes de base comme Firefox, Thunderbird, et VLC :

sudo aptitude install firefox thunderbird vlc

Je lance Firefox, je configure le proxy et en surfant je me rappelle que Flash n’est plus installé. Après quelques recherches et tentatives je trouve que pour AMD64 il faut prendre une autre version du paquet et l’installer manuellement :

wget http://launchpadlibrarian.net/10804892/flashplugin-nonfree_9.0.115.0ubuntu2_amd64.deb

sudo dpkg -i flashplugin-nonfree_9.0.115.0ubuntu2_amd64.deb

Je redémarre Firefox, et vérifie que Flash est bien installé en tapant «about:plugins» dans la barre d’URL. Ensuite, je me rends compte que les polices Microsoft ne sont pas installées sur mon système ; je lance donc :

sudo aptitude install msttcorefonts

Je continue en installant mes extensions favorites, à savoir :

• Adblock Plus, pour bloquer la pub
• Adblock Filterset.G Updater, pour mettre à jour les filtres d’Adblock
• All-in-one Sidebar, pour avoir une barre latérale sympa avec tout de regroupé dedans
• Tab Mix Plus, qui rajoute plein d’options indispensables pour a gestion des onglets
• Urlparams, permettant de manipuler les paramètres GET et POST des pages Web (pour le débug d’application Web)
• Web developer, une barre d’outils très utile, toujours pour développeur Web
• Firebug, un outil d’une puissance remarquable pour le développement et surtout le débogage (CSS, JavaScript…)

Pour terminer la configuration de Firefox, je copie les fichiers bookmarks.html, signons2.txt et key3.db situé dans mon dossier de profil firefox de l’ancien /home que j’ai sauvegardé (rappelons que le dossier de profil de Firefox a un nom du style ~/.mozilla/firefox/XXXXXXXX.default). En relançant Firefox, je me retrouve alors avec tous mes mots de passes enregistrés, et tous mes marques pages. Pratique…

Le son

Soudainement j’ai envie d’écouter de la musique, je lance donc un MP3 dans Amarok. Immédiatement, l’application me signale que le MP3 n’est pas lisible par défaut et me propose de télécharger les paquets pour le support ; je ne vais pas dire non ! L’installation est automatique, il n’y a rien à faire. Concernant es paramètres d’ALSA et de disposition des hauts parleurs de mon 5.1, je copie le .asoundrc de mon ancien /home. Ainsi, j’ai directement du son sur tous mes hauts parleurs : un vrai bonheur… J’utilise ensuite la commande «alsamixer» pour régler le volume de chaque haut parleur, et je sauvegarde les paramètres avec :

sudo alsactl store

Le réseau

Après cela je me décide à restaurer le réseau que j’ai établi dans ma chambre universitaire. Je commence par vérifier que mes 2 interfaces réseau ont bien été détectées et que leur ordre ne risque pas de changer dans la suite (cela m’est déjà arrivé…) :

sudo nano -w /etc/udev/rules.d/70-persistent-net.rules

Et j’ai bien fait puisque je constate que les 2 interfaces ont été inversées par rapport à ma préférence ; en effet j’aime mieux que le réseau de l’intranet soit attribué à eth0, et avoir l’interface eth1 reliée à mon PC portable situé dans ma chambre. Je modifie donc les deux lignes du style

SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="XX:XX:XX:XX:XX", NAME="eth0"

avec l’adresse mac de la carte réseau à la place des X.

Ceci étant fait, je configure /etc/network/interfaces pour avoir un fichier qui ressemble à cela :

# Reseau general

auto eth0

iface eth0 inet dhcp

# Reseau interne

auto eth1

iface eth1 inet static

        address 192.168.0.1

        netmask 255.255.255.0

Et je relance les interfaces avec :

sudo /etc/init.d/networking restart

Bilan

Voilà, je pense que j’ai fait le tour de toutes les modifications que j’ai apportées. Après un redémarrage, tout semble correct, mise à part le fait que je n’ai plus de splashscreen au démarrage. Je vais essayer de me documenter sur ce point car j’avoue que cela me manque

Sinon, j’ai toujours un problème de locale : je voudrais que mon système soit de base en ISO8859-15 alors qu’il est de base en UTF-8. C’est particulièrement gênant pour les noms de fichiers et même pour leur contenu, surtout quand on doit éditer des fichiers qui ne sont pas encodés de la même façon…

Si je devais faire un bilan de cette installation, je dirais que je suis assez satisfait. En installant la version 64bits, je m’attendais à rencontrer des problèmes, et à part le problème du splash et l’installation de Flash non conventionnelle, je n’ai rencontré aucun soucis propre à cette architecture. Je pense que c’est notamment grâce au fait que les paquets Ubuntu ont eu le temps de mûrir, car l’installation de certains paquets en 64bits il y a plusieurs mois était autrement plus complexe.

Comparé à mon ancienne version 32bits, je constate un gain appréciable en performances. Après, je ne sais pas si cela vient du 64bits ou simplement du fait que l’installation est propre et pas une upgrade d’upgrade bidouillée dans tous les coins. En tout cas je sens la différence, et même si j’étais sceptique sur le 64bit au début, je pense que je vais adopter cette version.

Je me rends également compte à quel point restaurer les paramètres d’un tel système est simple : quelques lignes de commande, deux ou trois fichiers à copier ou à éditer, et on gagne un temps fou en évitant de tout reconfigurer. Attention toutefois de ne pas tomber dans l’extrème et de restaurer brutalement tout son /etc ou son /home ! Cela pourrait poser des problèmes de compatibilité ; de plus si vous aviez des bugs dûs à des problèmes de configuration dans votre ancienne distribution, ils seront propagés dans la nouvelle… Par contre, concevoir un petit script Bash peut être une solution afin d’automatiser ce qui peut l’être, comme la copie de certains fichiers, et l’installation des paquets principaux.

J’espère que la marche à suivre aura aidé ceux qui se sont posés les mêmes questions que moi concernant la réinstallation d’une distribution. Un dernier conseil : surtout, n’oubliez pas de faire un backup total de vos données personnelles (le /home, le /etc et les éventuelles bases de données dans /var/mysql/lib) avant. Si vous avez des choses à ajouter, les commentaires sont là pour ça ! Bon surf