Guelton Serge

Cet article s'inscrit dans la continuation d'une série d'articles sur les artefacts bas niveau que l'on peut rencontrer dans un binaire compilé à partir de sources en C++. Cet épisode aborde (enfin !) un des morceaux les plus indigestes de la traduction de C++ en assembleur : la gestion d'exceptions sous Linux, suivant la spécification dite Itanium.

On trouve des compilateurs partout : quand on construit des programmes, bien sûr, mais aussi quand on visite la page web des Éditions Diamond — elle embarque du JavaScript, qui est probablement compilé à la volée par un composant de votre navigateur. Quand on utilise un Notebook Jupyter pour du calcul scientifique — ne serait-ce que pour la compilation en bytecode du source Python. Quand on installe un APK pour ART, celui-ci est transformé en code natif depuis son bytecode Dalvik… encore de la compilation. Et nous allons voir que le domaine de la compilation peut aussi très largement intéresser celui de la sécurité informatique et du reverse engineering.

En sécurité sous les drapeaux... du compilateur, ces fameux -fstack-protector-strong et autres -D_FORTIFY_SOURCE=2 que l’on retrouve dans de plus en plus de logs de compilation. Cet article se propose de parcourir quelques-uns des drapeaux les plus célèbres, en observant les artefacts dans le code généré qui peuvent indiquer leur utilisation, tout en discutant de leur support par gcc et clang. Après tout, nombre d’entre eux sont utilisés par défaut sous Debian ou Fedora, ils méritent bien qu’on s’y intéresse un peu.

Cet article est le troisième d'une mini-série sur le C++, ou plutôt sur les binaires compilés depuis C++, leurs particularités, comment les concepts du langage se retrouvent parfois dans le binaire final.

Cet article est le second d'une mini-série sur le C++, ou plutôt sur les binaires compilés depuis C++, leurs particularités, comment les concepts du langage se retrouvent parfois dans le binaire final.

Cet article est le premier d'une mini-série sur le C++, ou plutôt sur les binaires compilés depuis C++, leurs particularités et comment les concepts du langage se retrouvent parfois dans le binaire final.

Au siècle dernier, Sartre écrivait : « Plus claire la lumière, plus sombre l'obscurité… Il est impossible d'apprécier correctement la lumière sans connaître les ténèbres. » C'est cette pensée qui va nous guider tout au long de cet article : découvrir et comprendre quelques techniques d'obfuscation, mais surtout appréhender les mécanismes qui les guident, pour en implémenter de plus robustes, ou pour mieux les contrer.

La première partie de cette article nous a montré, entre autres, les avantages et inconvénients dont disposent les processeurs multi-coeurs modernes. Nous allons voir ici quels sont les autres moyens permettant de rendre une application scalable. Nous nous intéresserons aux performances de toutes ces technologies, et aux applications possibles au domaine de la sécurité informatique.

Depuis quelques années, la création d'applications performantes et capables de tirer partie de la capacité de calcul de une à plusieurs (milliers de) machines, traitant et créant des quantités d'informations de plus en plus importantes, est devenue un problème auquel de plus en plus d'industriels et divers corps de métiers font face. Cela va du traditionnel calcul scientifique, au domaine de la finance ou encore de la « business intelligence ».