[Docker Apps] Exegol : un environnement dédié à la sécurité offensive

Violence

I. Présentation

Et si votre boîte à outils offensive était plus simple à déployer qu’un docker run ? Dans cet article, nous allons parler d’une solution d’outillage pour la cybersécurité offensive nommée Exegol. Nous verrons le fonctionnement de cet outil, son origine, sa philosophie et bien sûr, une démonstration de son utilisation.

La cybersécurité offensive est un domaine complexe qui fait appel à de multiples technologies, langages et outils. L’un des éléments les plus importants est bien sûr la boîte à outils que l’ont choisi d’utiliser pour se former, s’entrainer ou mener des tests réels.

De nombreuses solutions existent, des systèmes d’exploitations “tout-en-un” à la configuration from scratch. Parmi ces différentes options, une solution légère, à jour, efficace et simple d’utilisation est récemment apparue : Exegol.

II. Un environnement complet pour la sécurité offensive

A. Des images Dockers et un wrapper Python : simple et efficace

Exegol est une boîte à outils offensive basée sur Docker. Il s’agit d’une solution d’une grande simplicité, tant dans sa conception que dans son utilisation. Il repose sur quelques briques connues et robustes que nous allons décrire ici :

Docker : permet d’isoler des environnements, ce qui est très important pour la sécurité offensive
Des images Docker pré-construites, personnalisables, maintenues à jour et optimisées pour des scénarios spécifiques (web, OSINT, AD)
Un wrapper Python qui facilite, via la ligne de commande, la gestion des différents conteneurs et images Docker, mais aussi l’utilisation des fonctionnalités propres à Exegol
Des ressources hors lignes, comme des dictionnaires de mots, différents exécutables et scripts d’énumération, des portes dérobées, etc
Un gestionnaire d’historique et d’identifiants, une journalisation des commandes, et tout un tas de fonctionnalités ;
Vos propres outils et ressources.

– Regardez plutôt :

En quelques secondes, démarrage éclair d’un conteneur, accès instantané à tous mes outils, tests en cours et documents du workspace, tout est déjà là, prêt à l’emploi. Un simple changement de conteneur, et je bascule vers mon projet en cours, avec son propre contexte, ses données et ses outils configurés.

Je peux même totalement détruire ou modifier mon conteneur, mon hôte restera sain et je pourrai simplement recréer un conteneur à partir de la même image ensuite.

Pour mieux comprendre les raisons de la naissance et du succès actuel d’Exegol, il faut que je vous parle un peu de mon expérience de pentester avec les outils plus traditionnels et de leurs limites.

B. Les limites des outils actuels

Je travaille dans la cybersécurité depuis bientôt 10 ans et j’ai toujours eu une partie de cybersécurité offensive opérationnelle dans mes missions (autrement dit, du pentest, des tests d’intrusion). Jusqu’à il y a peu, je travaillais avec une VM Kali Linux qui était installée sur mon poste. D’abord, parce que c’était le choix “par défaut” quand j’ai commencé, mais aussi faute d’alternative sérieuse et peu chronophage.

Cette solution semblait intéressante : avoir une machine virtuelle permet de revenir à un état initial grâce aux snapshots en fin de mission, on a une isolation vis-à-vis de l’hôte, on peut avoir autant de VM que de clients, etc. Cependant, l’utilisation quotidienne de cette solution a fait apparaître plusieurs problèmes que je n’ai jamais vraiment résolus complètement :

Ressources sous tension : en pratique, une VM peine à suivre sur des opérations gourmandes (scans automatisés, cassage de mots de passe). Multiplier les clones pour isoler les missions ? Le stockage sature vite, et les performances sont limitées.
Instabilité chronique : même avec des hyperviseurs matures, les bugs restent mon quotidien : freezes intempestifs, problèmes d’affichage, ou copier-coller qui tombe en rade. Des heures perdues en maintenance plutôt qu’en tests.
Cloisonnement théorique : on le sait, une VM par client, c’est la règle. Qu’il s’agisse de “refaire un petit test vite fait” sur un périmètre précédent, ou un simple PoC (Proof of Concept), on ne prend dans les faits pas toujours le temps de revenir au snapshot d’origine, d’autant plus si l’on est en pleine mission. Cela implique donc des risques pour la séparation des données.
Personnalisation fragile : un outil installé pour une mission ? Après un retour au snapshot ou une mise à jour, il faut tout recommencer. Sans parler des configs et raccourcis à réappliquer systématiquement.
Dépendance aux mises à jour : les distributions “tout-en-un” accusent un retard critique sur les versions des outils. Résultat : je me retrouve à compiler depuis les sources, perdant le bénéfice d’une solution intégrée.

Pour un pentester, disposer des dernières versions des outils est indispensable, le rythme de parution des vulnérabilités et de leurs correctifs ne rend pas envisageable d’attendre plus de quelques jours (voir heures) pour faire des opérations efficaces.

Pourquoi c’est bloquant ? En pentest, chaque minute compte. Une VM qui ralentit, des outils obsolètes ou une config à refaire à chaque fois, c’est du temps volé à ce qui importe le plus : l’efficacité opérationnelle.

Après de nombreuses années à utiliser Kali Linux, j’avais automatisé l’installation de nombreux outils et ressources spécifiques à ma méthodologie et mes besoins. Cependant, je dois bien avouer que les différentes limitations mentionnées étaient pesantes et ralentissaient mon travail au quotidien. J’ai donc bousculé mes habitudes et ma résistance au changement (tout le monde vieillit) et ai donné une chance à Exegol.

C. Mon avis sur Exegol : testé et approuvé

Je dois dire que j’étais réticent à l’idée de changer mes habitudes tant j’avais passé de temps à créer mon petit setup Kali Linux. Mais, à force d’entendre mes collègues parler de cet outil, et surtout de ne pas trouver de solutions aux différentes limitations, je me suis dit : pourquoi pas !

Parmi les principaux a priori que j’avais sur la solution :

Ça doit être galère pour accéder à des outils graphiques qui tourne sous Docker, est-ce que c’est vraiment fait pour ça ?

C’est l’un des nombreux avantages du wrapper Python. Par défaut, il configure les conteneurs pour qu’ils partagent leur interface X11, ce qui permet l’exécution d’outils graphiques (BurpSuite par exemple). L’interface graphique apparaîtra sur l’hôte ! (Source : Exegol - wrapper - x-11-sharing-gui)

Également, il est possible d’utiliser l’option --desktop, ce qui exposera l’interface graphique (bureau) du conteneur sur une interface accessible en HTTP ou VNC. (Source : Exegol - wrapper - desktop)

Pour accéder à des outils en écoute locale, pour les attaques réseaux, mon CyberChefou interface Bloodhound, comment fait-on ?

Un conteneur Docker partage la configuration réseau de son hôte, il peut donc accéder à l’interface Wi-Fi, Ethernet, et même avoir son propre accès VPN. Les outils en écoute locale sur le conteneur seront accessibles depuis l’hôte. La liste des services disponibles parmi les outils d’Exegol et leurs ports d’écoute est présente ici : Exegol - Service list

Une image Docker, c’est statique, je ne pourrai pas ajouter mes propres outils dedans ? Et, mes traces lorsque le conteneur s’arrête ?

Différents répertoires montés entre l’hôte et les conteneurs permettent de partager des outils ou des ressources qui seront toujours disponibles. Différents dossiers de configuration sont également disponibles pour installer ses propres outils supplémentaires, configurer automatiquement son Zsh, Firefox, Tmux ou encore Vim selon ses préférences lors de la création d’un nouveau conteneur.

Enfin, chaque conteneur dispose d’un workspace (dossier) dédié et partagé avec l’hôte. Ainsi, pas de risque de mélanger deux dossiers relatifs à des missions ou des contextes différents :

# Liste des workspaces de chaque conteneur : ai, projet_1, projet_2, htb
$ ls ~/.exegol/workspaces/ -al
total 166540
drwxrwxr-x  6 mickael mickael      4096 juil. 30 21:14 .
drwxrwxr-x  5 mickael mickael      4096 juil.  6 21:50 ..
drwxrwsr-x  7 mickael mickael      4096 juil. 20 22:53 ai
drwxrwsr-x  2 mickael mickael      4096 juil. 30 22:13 projet_1
drwxrwsr-x  2 mickael mickael      4096 juil. 30 22:14 projet_2
drwxrwsr-x 22 mickael mickael      4096 juil. 03 22:56 htb

Par exemple, insérer les instructions suivantes dans le fichier .exegol/my-resources/setup/load_user_setup.sh aura pour effet d’exécuter ces commandes (et donc, d’installer quelques outils supplémentaires) à chaque création d’un nouveau conteneur :

pipx install git+https://github.com/infosec-au/altdns
pipx install git+https://github.com/devanshbatham/paramspider.git

Bref, le wrapper Python et le fonctionnement d’Exegol ont permis de répondre à tous les cas de figure pour lesquels j’ai eu un doute sur la compatibilité de l’outil avec mes méthodes de travail. La liste complète des features d’Exegol se trouve sur cette page :

Exegol - Features

J’ai donc passé quelques jours à découvrir la solution, tester les différentes images, commencer à modifier mon setup, mes notes (notamment avec une intégration de TheHackerRecipes), et ma méthodologie. J’ai ensuite rapidement compris que c’était la solution à nombre des problèmes inhérents à l’utilisation de Kali Linux, ParrotOS, des machines virtuelles, etc.

J’ai décidé de passer définitivement à cette solution, bien plus légère, facile à personnaliser et correspondant bien mieux à ce qu’une boîte à outils offensive doit être.

Si je devais résumer un peu ce que je pense des différentes solutions que sont Kali Linux (et ses équivalents) et Exegol, je dirais que Kali Linux est très bien pour découvrir la cyber et les outils. Un fond d’écran un peu dark, un menu graphique, une organisation des outils par thématique ou TPP, etc. Mais, pour du sérieux et de l’opérationnel, il vaut mieux passer sur Exegol. Cet outil est plus rapide, plus à jour et plus simple à gérer au quotidien. Le tout me permet de me concentrer et de passer mon temps sur le principal et l’opérationnel : faire des tests d’intrusion, plutôt de gérer des snapshots, gérer des problèmes de copier-coller ou des freeze intempestifs.

III. Un outil Français et une philosophie

Je n’en ai pas encore parlé ? Exegol est fait par un Français (cocorico), et même si l’outil est relativement récent (première release : mars 2020) il a déjà une renommée internationale chez les pros de la cybersécurité.

Il a été créé par ShutDown (Charlie Bromberg), également auteur d’une ressource incontournable : TheHackerRecipes, qui regroupe un ensemble de méthodologie, explications et commandes autour des cyberattaques, notamment à propos de l’Active Directory. C’est d’ailleurs la grande qualité de TheHackerRecipes qui m’a réellement donné envie de tester Exegol.

Soit dit en passant, entre GentilKiwi (Benjamin Delpy), auteur de Mimikatz, Vincent Le Toux, auteur de PingCastle, et ShutDown (et j’en oublie certainement un tas d’autres) la France n’a pas à rougir de ses contributions au monde de la cybersécurité.

Charlie Bromberg a accepté de répondre à nos questions dans le cadre de la rédaction de cet article, voici la synthèse de nos échanges.

Exegol : une solution née de la collaboration et tournée vers l’efficacité

Exegol a vu le jour en 2020, porté par une idée simple : mutualiser les efforts plutôt que de voir chaque utilisateur développer, dans son coin, des solutions similaires et souvent éphémères. Le projet a été conçu pour répondre aux problèmes concrets rencontrés par les professionnels de la cybersécurité offensive. Open source depuis son lancement, son modèle de prix à évolué pour devenir hybride, avec une offre Pro destinée à financer son développement tout en préservant son accessibilité et son esprit communautaire. Le code, lui, est resté totalement open source.

Une base solide, simple et extensible

L’ambition d’Exegol est claire : proposer une solution robuste et intuitive, couvrant 80 % des besoins des utilisateurs, tout en offrant des options de personnalisation pour les 20 % restants. Grâce à une architecture ouverte et extensible, l’outil permet à chacun d’adapter l’environnement à ses besoins spécifiques.

Une sélection rigoureuse des outils

Contrairement à des distributions comme Kali Linux, souvent critiquées pour leur accumulation d’outils peu maintenus ou redondants, Exegol privilégie une approche ciblée et qualitative. Chaque intégration est soigneusement évaluée selon trois critères : légèreté, soutien communautaire et pertinence opérationnelle. A l’inverse, si un outil devient obsolète ou moins utilisé, il peut être retiré après consultation de la communauté, assurant ainsi une solution toujours en phase avec les pratiques des professionnels.

Un outil professionnel, accessible à tous

Destiné en priorité aux experts et aux futurs professionnels de la cybersécurité offensive, Exegol séduit aussi d’autres publics, comme les administrateurs système. Sa simplicité d’utilisation et son approche conteneurisée permettent de créer des environnements jetables et sécurisés, idéaux pour s’initier aux outils offensifs (Nmap, BloodHound, etc.) ou renforcer ses défenses.

– Au centre, le logo d’Exegol.

IV. Installation et découverte d’Exegol

A. Comment installer Exegol sur mon Linux

Nous allons à présent passer à la découverte un peu plus concrète de ce qu’est Exegol, à commencer par son installation. Pour cette démonstration, je suis sur un système Linux Ubuntu 24.04. Exegol peut aussi être installé sur MacOS, Windows et même utilisé via WSL2 (avec quelques limitations).

Pour l’installation, il faut au préalable disposer sur son système de Docker, git, Python3 et pipx. La procédure d’installation complète, ainsi que celle de ces différentes dépendances, est présente dans la documentation officielle : docs.exegol.com/first-install.

# Installation d'exegol via pipx
pipx install exegol
# Ajout d’un alias pour exécuter exegol via sudo
echo "alias exegol='sudo $(echo ~/.local/bin/exegol)'" >> ~/.bash_aliases && source ~/.bash_aliases

Voici le retour que nous aurons dans notre terminal :

–Installation d’exegol sous Linux via pipx.

Sans oublier d’ouvrir un nouveau terminal pour que ce nouvel alias prenne effet, nous pouvons vérifier que la commande exegol est fonctionnelle. La première commande à exécuter est exegol info, elle permet d’afficher les conteneurs actifs (pour l’instant, nous n’en avons pas) mais aussi les images disponibles et téléchargeables :

– Exécution de la commande exegol info et liste des images téléchargeables.

Les images partagent entre elles certains outils, en télécharger une permet donc de diminuer le temps de téléchargement (et la place de stockage) des autres.

Notez que l’image free est largement suffisante pour débuter et découvrir Exegol. La commande suivante permet donc de télécharger une image à partir du repo d’Exegol :

# Téléchargement de l'image Docker Exegol:free
exegol install free

Quelles sont les différences entre les images disponibles ?

La liste des outils de chaque image est disponible dans cet espace de la documentation Exegol : docs.exegol.com/images/tools. Vous pouvez y télécharger un fichier CSV par image listant tous les outils disponibles :

– Extrait de la liste des outils disponibles dans l’image free (plus de 400 au total)

C’est la liste des outils disponibles qui est la seule différence entre chaque image. L’image free possède un léger retard dans l’application des mises à jour, mais contient une liste complète d’outils qui est largement suffisante pour l’utiliser sur des missions non pro, apprendre et s’entrainer à la cybersécurité offensive.

Voici la vue que nous aurons lors du téléchargement d’une image Docker Exegol, l’image free prendra environ 50 Go d’espace disque :

– Téléchargement de l’image exegol free depuis le terminal.

Plusieurs avertissements apparaitront concernant le téléchargement des ressources additionnelles et le fait d’avoir un antivirus sur son hôte (on télécharge quand même des outils offensifs).

Passons à présent à la gestion de nos conteneurs Docker via Exegol et leur cycle de vie au cours d’une mission ou d’un projet.

B. Gérer ses conteneurs et images Exegol

Une fois que le téléchargement est terminé, nous pourrons confirmer que l’image est disponible à nouveau avec la commande exegol info. Comme nous l’avons vu, elle permet d’afficher les conteneurs créés, actifs (pour l’instant, nous n’en avons pas) mais aussi les images disponibles et téléchargeables :

– Exécution d’exegol info avec une image téléchargée.

Ici, la commande m’indique que j’ai la dernière version de l’image free de disponible sur mon poste. Voici un schéma qui expose le cycle de vie classique d’un conteneur via Exegol :

– Cycle de vie d’un conteneur Exegol

La phase de préparation est généralement assez courte. Nous retrouvons donc la commande exegol install qui permet d’installer une image, ce qui se fait en général une fois lors de la première utilisation de l’outil. Par la suite, nous pourrons utiliser exegol update <nom image> pour mettre à jour nos images et profiter des nouveaux outils et des mises à jour à disposition.

La création d’un conteneur basé sur une image disponible passe par la commande exegol start <nom conteneur> <nom image>. Si je souhaite créer un conteneur nommé lab basé sur l’image free, voici la commande à utiliser :

# Création d'un nouveau conteneur basée sur une image via exegol
exegol start <nom conteneur> <nom image>
# Exemple
exegol start lab free

À la fin d’un projet, ou d’une mission, nous pourrons supprimer le conteneur avec la commande exegol remove <nom conteneur>, et si souhaité, le workspace associé. Généralement, le workspace perdure un peu plus longtemps afin de pouvoir traiter les données collectées (pour un rapport par exemple). Attention néanmoins à ne pas les oublier trop longtemps, pour rappel, les workspaces de chaque conteneur se trouvent par défaut dans le répertoire ~/.exegol/workspace/ de l’hôte.

Passons à présent au cœur du sujet, nous allons entrer dans notre premier conteneur et voir ce qui s’y trouve !

C. Démonstration, un pentest via exegol

Pour entrer dans un conteneur, il suffit de réexécuter sa commande de démarrage (s’il existe déjà, le nom de l’image n’est plus utile), soit :

# Créer un conteneur basé sur une image et obtenir un shell
exegol start lab free
# Entrer dans un conteneur déjà existant et obtenir un shell
exegol start lab

Remarquez ici les informations qui nous sont affichées, elles donnent un aperçu du paramétrage de notre conteneur, mais aussi des nombreuses fonctionnalités uniques d’Exegol :

– Démarrage d’un conteneur Exegol.

On retrouve le nom du conteneur, la version de son image, puis :

Credentials : les identifiants générés pour l’utilisateur root, utiles dans certains cas pour un accès SSH distant, par exemple ;
Le statut de l’option remote desktop: elle permet d’afficher la GUI du conteneur dans une interface web ou un service VNC ;
L’activation de la console GUI: permet d’afficher sur l’hôte les interfaces graphiques du conteneur, par exemple BurpSuite ou un client local comme Dbeaver ;
Le réseau dans lequel se trouve le conteneur, que nous pouvons d’ailleurs totalement isoler pour des cas spécifiques ou même démarrer automatiquement avec une configuration VPN ;
Le partage de la timezone (fuseau horaire) avec l’hôte ;
Les chemins vers les différents répertoires de partage des ressources, des setups personnalisés et du workspace ;
Le statut de la journalisation des commandes/sorties dans le conteneur ;
Le statut privilégié ou non du conteneur.

Toutes ces options répondent à des besoins concrets et sont gérables via des options dédiées. La liste complète des features disponibles dans Exegol, incluant l’isolation d’un conteneur au niveau réseau, la journalisation des commandes, le partage de répertoire ou de port avec l’hôte et j’en passe, est disponible ici : docs.exegol.com/wrapper/features

Les options que j’utilise le plus souvent sont la journalisation des commandes ainsi que le démarrage d’un shell tmux, qui me permet de gérer plusieurs terminaux rapidement :

# Démarrage d'un conteneur lab avec un shell tmux et la journalisation des commandes/sorties
exegol start lab fee --shell=tmux --log

Vos options préférées, si elles diffèrent de celles par défaut, peuvent être enregistrées dans le fichier ~/.exegol/config.yml.

Intéressons-nous à présent aux principaux répertoires d’un conteneur Exegol :

Répertoire conteneur	Description
`/opt/tools/`	Contient tous les outils présents dans l’image Docker utilisée, l’image `free` en possède plus de 400 ! Ce répertoire est présent dans la variable `$PATH`, les outils sont donc utilisables depuis n’importe où.
`/workspace/`	Répertoire permanent entre l’hôte et le conteneur, utilisé notamment pour y garder vos traces et données après la suppression du conteneur. Ce répertoire est propre à chaque conteneur et n’est pas partagé d’un conteneur à l’autre*. Sur l’hôte, les workspaces* sont présents dans le répertoire `~/.exegol/workspaces`.
`/opt/my-resources/`	Vos propres ressources, celles que vous souhaitez ajouter à Exegol, qu’il s’agisse de binaires, de données ou de configurations. *Il s’agit d’un bind mount Docker (montage) vers le répertoire `~/.exegol/my-resources/` de l’hôte.*
`/opt/resources/`	Contient les ressources offlines proposées par Exegol, des binaires d’énumération, de tunneling, tout ce qui peut être déposé sur un hôte compromis. *Il s’agit d’un bind mount Docker (montage) vers le répertoire `~/.exegol-resources/` de l’hôte.*
`/opt/lists/`	Contient un ensemble de dictionnaires (liste de mots) pour le cassage de mot de passe, le fuzzing et le brute force
`/opt/rules`	Contient un ensemble de règles de cassage de mots de passe utilisables par l’outil `hashcat`.

Un mot concernant la gestion des données

Le cloisonnement des données dans les workspaces, mais aussi celui permit par l’utilisation de conteneurs uniques à chaque mission ou contexte est très important. Certaines réglementations et contrôles imposent aux auditeurs de cloisonner strictement les périmètres techniques et données entre leurs clients. Exegol offre à ce sujet une option possible pour se mettre en conformité pour les audits dans de tels contextes.

À partir d’ici, libre à vous de faire les expérimentations et tests que vous souhaitez sur votre conteneur. J’en profite pour vous montrer deux fonctionnalités d’Exegol qui me font gagner beaucoup de temps : les variables d’environnement et l’historique basé sur TheHackerRecipes.

Pour rappel, TheHackerRecipes une base de connaissances gérée par ShutDown, elle référence un grand nombre d’attaques, principalement autour de l’Active Directory.

Chose intéressante, la plupart des commandes présentes dans cette base de connaissance (et bien plus) ont été insérées dans l’historique de vos conteneurs Exegol. Ainsi, en saisissant le début d’une commande, Zsh nous propose en autocomplétion la commande complète probable, et on peut chercher dans cet historique avec la saisie habituelle Ctrl + R :

– Démonstration de l’utilisation de l’historique des commandes intégrées à Exegol

Comme vous pouvez le voir, les commandes présentes dans cet historique (comme celles proposées dans TheHackerRecipes) utilisent des variables que chacun doit modifier/remplacer pour coller à son contexte. On peut alors préconfigurer ces variables par rapport à notre contexte dans notre terminal :

# Définition des variables d'environnement bash
USER=cersei.lannister
PASSWORD=il0vejaime
DOMAIN=sevenkingdoms.local
DC_HOST=192.168.56.10

Puis faire appel très rapidement à toutes les commandes qui utilisent ces variables, sans avoir à ressaisir le login, le mot de passe, le domaine, l’adresse IP de la cible, etc :

– Démonstration de l’utilisation des variables d’environnement avec l’historique des commandes Exegol.

Et comme vous pouvez le voir, le ZSH par défaut d’Exegol réinsère dans le prompt du terminal le contexte (utilisateur@domaine) dans lequel on se trouve, ce qui permet de ne pas faire d’erreur, de s’y retrouver facilement lorsque l’on a plusieurs terminaux ouverts et d’afficher clairement ce contexte dans une éventuelle preuve pour un rapport, etc. Je trouve cela très pratique et intelligent !

L’utilitaire “exh” ou “exgol-history” peut aussi être utilisé pour gérer ces variables d’environnements. On utilisera par exemple “exh add creds” ou “exh set creds” pour ajouter des identifiants (fonction en beta pour le moment ).

V. Conclusion

Exegol est une ressource devenue incontournable lorsque l’on veut se former, s’entrainer, mais aussi et surtout pour les pros de la cybersécurité offensive. Je l’utilise très fréquemment depuis maintenant plusieurs mois et je n’envisage pas un retour sur des solutions comme Kali Linux.

La meilleure manière de se faire une idée de l’efficacité de l’outil reste de l’essayer, je ne peux que vous encourager vivement à le faire, que vous soyez étudiant, passionné ou un professionnel de la cybersécurité.

– Pour aller plus loin, je vous laisse ici quelques liens vers le dépôt d’Exegol et sa documentation :

Exegol Documentation
Exegol Github

– Et n’oubliez pas d’aller faire un tour sur TheHackerRecipes, l’une des meilleures base de connaissances à jour sur les techniques d’attaques :

– TheHackerRecipes

– Source :

https://www.it-connect.fr/exegol-un-environnement-dedie-a-la-securite-offensive/

Aerya

Merci, très intéressant et pratique à mettre en œuvre en effet. Je me garde ça sous le coude.

Planète Warez

Light

Dim

Dark