C

Cet après midi, j’ai eu une mauvaise surprise. Je fus en effet étonné de constater qu’en compilant pkgin sous GNU/Linux, les appels du type :

tronquaient a avec uniquement unechaine.

Evidemment, mon premier reflexe fut de blâmer GNU/Linux puisque ce code passait sans aucun soucis sur NetBSD, DragonFly BSD et même Solaris. Et pourtant. C’est gl qui m’informa que ce document issu de l’ISO et l’IEC explique clairement que le fait d’appeler snprintf() de la sorte rendait le résultat “imprévisible”. Dont acte.

En comparant le projet qui m’obsède jour et nuit et les outils similaires déjà existants (crunchgen(1), rescue), j’en suis venu à me poser des questions sur le cas d’un mode “full static”. Pour mémoire, BeastieBox “trouve” la fonction à appeler fonction de argv[0], et je pars du principe que chaque nom de fonction doit être construit dynamiquement. Ce tour de passe-passe est facilement geré par les fonctions dlopen(3) / dlsym(3) dans le cas d’un binaire compilé dynamiquement, mais quid d’un binaire beastiebox compilé à l’aide du swtich -static ? Point de ld.so_elf à la rescousse ici, la seule solution qui m’est apparue… c’est d’attaquer le binaire comme le fait précisemment ld.so_elf, en mmap‘ant le binaire et en l’adressant via les structures ELF.

Y’a quelques jours, je me suis lancé dans un nouveau projet. Plus pour le fun que par réelle nécéssité, je me suis mis en tête d’ecrire un BusyBox-like orienté BSD. J’en suis pour le moment aux balbutiements du projet, mais quelques commandes sont déjà fonctionnelles.

Mon approche est un tantinet differente du fonctionnement de BusyBox. Afin de permettre l’écriture simple et rapide de plugins, je supporte deux modes, un mode statique (ala BB), et un mode dynamique grace aux interfaces DLFCN(3).