Documentation<Précédent | Table des matières | Suivant>
9.1. Modification des packages Kali
La modification des packages Kali est généralement une tâche pour les contributeurs et les développeurs de Kali : ils mettent à jour les packages avec les nouvelles versions en amont, ils peaufinent la configuration par défaut pour une meilleure intégration dans la distribution, ou ils corrigent les bogues signalés par les utilisateurs. Mais vous pourriez avoir des besoins spécifiques non satisfaits par les packages officiels et savoir comment construire un package modifié peut donc être très précieux.
Vous pourriez vous demander pourquoi vous devez vous embêter avec le paquet. Après tout, si vous devez modifier un logiciel, vous pouvez toujours récupérer son code source (généralement avec jet) et exécutez la version modifiée directement à partir de l'extraction des sources. C'est bien quand c'est possible et quand vous utilisez votre répertoire personnel à cette fin, mais si votre application nécessite une configuration à l'échelle du système (par exemple, avec un make install step) alors il polluera votre système de fichiers avec des fichiers inconnus de dpkg et créera bientôt des problèmes qui ne peuvent pas être détectés par les dépendances de package. De plus, avec des packages appropriés, vous pourrez partager vos modifications et les déployer sur plusieurs ordinateurs beaucoup plus facilement ou annuler les modifications après avoir découvert qu'elles ne fonctionnaient pas aussi bien que vous l'espériez.
Alors, quand voudriez-vous modifier un package ? Voyons quelques exemples. Tout d'abord, nous supposerons que vous êtes un gros utilisateur de SET et que vous avez remarqué une nouvelle version en amont, mais les développeurs de Kali sont tous occupés pour une conférence et vous souhaitez l'essayer immédiatement. Vous souhaitez mettre à jour le package vous-même. Dans un autre cas, nous supposerons que vous avez du mal à faire fonctionner votre carte MIFARE NFC et que vous souhaitez reconstruire « libfreefare » pour activer les messages de débogage afin d'avoir des données exploitables à fournir dans un rapport de bogue que vous êtes en train de préparer. Dans un dernier cas, nous supposerons que le programme « pyrit » échoue avec un message d'erreur cryptique. Après une recherche sur le Web, vous trouvez un commit qui devrait résoudre votre problème dans le référentiel GitHub en amont et vous souhaitez reconstruire le package avec ce correctif appliqué.
Nous passerons en revue tous ces exemples dans les sections suivantes. Nous essaierons de généraliser les explications pour que vous puissiez mieux appliquer les consignes à d'autres cas mais il est impossible de couvrir toutes les situations que vous pourriez rencontrer. Si vous rencontrez des problèmes, faites preuve de bon sens pour trouver une solution ou allez chercher de l'aide sur les forums les plus appropriés (voir chapitre 6, « Vous aider et obtenir de l'aide» [page 124]).
Quelle que soit la modification que vous souhaitez apporter, le processus général est toujours le même : récupérez le paquet source, extrayez-le, apportez vos modifications, puis construisez le paquet. Mais pour chaque étape, il existe souvent plusieurs outils qui peuvent gérer la tâche. Nous avons sélectionné les outils les plus pertinents et les plus populaires, mais notre examen n'est pas exhaustif.