Discussion :

[xwz]

Bonsoir à tous,

Je ne savais pas trop où poster la question, alors je le met dans adminsys. Si vous estimez que la question doit être déplacée, n'hésitez pas, et désolé d'avoir posté au mauvais endroit.

Je voudrais comprendre le fonctionnement des bibliothèques partagées sous Linux. En gros, si j'ai tout bien compris, quand on utilise les fonctions dlload/dlsym/... on doit faire le boulot du linker (et de ld.so), à savoir référencer les fonctions à utiliser. Ma question étant, comment sont chargées les bibliothèques avec ld.so pour que l'OS arrive à faire la résolution des symboles à la "volée". Avec strace j'ai compris qu'il lisait le reader du .so et que mprotect et mmap étaient utilisés pour réinterpréter le binaire, mais quelles sont les données qui sont transmisent à ces deux fonctions ? quels blocs sont utilisés ? Avez vous un lien/livre qui décrirait toutes la procédure et/ou le fonctionnement détaillé ? J'ai cherché mais rien trouvé de bien concluant.

Merci d'avance,

X.

[jlliagre]

La liste des bibliothèques partagées à charger se trouve dans la section dynamique des en-têtes privés des fichiers exécutables qui sont au format ELF sous Unix et Linux et beaucoup d'autres systèmes d'exploitation.

Tu peux les afficher avec la commande

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

objdump -p fichier

La commande ldd permet d'afficher plus de dépendances car elle analyse récursivement les bibliothèques trouvées.

[xwz]

Bonjour,

Oui, je connais la commande objdump, readelf, nm, ... mais ma question était plus coté fonctionnement bas niveau du chargement. Si par exemple moi je voulais faire cette étape à la main, il me faudrait faire des read, des mmap et mprotect, mais quelles sont les données à fournir à ces deux dernières fonctions ?

Par exemple, avec strace sur une petite app qui charge une bibliothèque HelloWorld, j'obtiens :

open("../lib-build/libHelloWorld.so", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\10\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=8072, ...}) = 0
getcwd("/home/xwz/dev/tests/protect/app", 128) = 32
mmap(NULL, 2101336, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fbb5aefa000
mprotect(0x7fbb5aefb000, 2093056, PROT_NONE) = 0
mmap(0x7fbb5b0fa000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0x7fbb5b0fa000
close(3) = 0

là on peut voir qu'un nouvel mmap est exécuté avec NULL et une taille de 2101336 et qu'elle renvoie : 0x7fbb5aefa000. Déjà, pourquoi une taille de 2101336 ?
ensuite, l'adresse du mprtect sort d'où ? Visiblement, c'est l'adresse retournée par mmap + 4096 (le pagesize), mais pourquoi un offset de 4096 là dessus ?

Et je suppose que dans le strace il manque des étapes, par exemple la copy du binaire du .so dans la zone mémoire du mmap ?

Merci.

[LittleWhite]

Sachant qu'il y a un fstat avant le mmap, je dirais : la taille du SO, afin de pouvoir charger la SO à travers le segment mémoire créé avec mmap. Mais en effet, il y a pas mal de chose intéressante, surtout qu'il ne faut pas oublier qu'il y a des mécanismes de protection (non-déterminisme d'où sera chargée la bibliothèque, fermeture en écriture du segment...).

[xwz]

Le .so fait 8072o, ce qui pourrait expliquer le 8192 (première puissance de 2 au dessus de 8072, je ne sais meme pas si c'est lié), mais pas les autres chiffres. C'est pourquoi j'aimerais trouver autre chose que les codes sources, parce que pour avoir regardé, c'est pas le code le plus simple à comprendre vu le nombre d'étapes et de vérifications.

[jlliagre]

Oui, je connais la commande objdump, readelf, nm, ... mais ma question était plus coté fonctionnement bas niveau du chargement. Si par exemple moi je voulais faire cette étape à la main, il me faudrait faire des read, des mmap et mprotect, mais quelles sont les données à fournir à ces deux dernières fonctions ?

J'ai bien compris la question et la réponse est toujours celle que j'ai déjà fourni:

La liste des bibliothèques partagées à charger se trouve dans la section dynamique des en-têtes privés des fichiers exécutables

L'approche consistant à vouloir faire du reverse-engineering en observant via strace ce que fait un exécutable est vaine. La mécanique est complexe mais tout est documenté et open-source.

Je te conseille plutôt d'analyser le format ELF et de regarder ce que font ldd et ld-linux.so à partir de leur code source.

Si tu n'arrive pas à trouver ton compte avec le code source, ce sera encore moins facile sans ...

[xwz]

La mécanique est complexe mais tout est documenté et open-source.
.

Je sais que tout est open-source et complexe. Pour le coté documenté, c'est justement ce que je cherche, mais je n'ai pas encore trouvé de documents (sites/livres) qui repondent à mes interrogations, donc si tu as ça dans un coin, je suis preneur.

[jlliagre]

Avec quel objectif souhaites-tu comprendre comment fonctionne le chargeur de bibliothèques partagées ?