Wir waren diese Woche sehr beschäftigt, sind mit unseren E-Mails immer noch im Rückstand, aber mit der Entwicklung von Kali gut vorangekommen. Wir haben einige neue Tools gepackt, auf die von der Community als fehlend hingewiesen wurde, wie z. B. inguma , Arachni , Tyrann , lbd , uniscan , Automatisierer , sowie damit begonnen, ein Framework von Bibliotheken und Patches für Bluetooth-Sniffing- und Ubertooth-Tools zu erstellen. Wir haben auch das Kali-Menü repariert, damit es wieder bearbeitet werden kann.
Mit über 300 Tools in unserem Repository ist es für uns nahezu unmöglich, *jedes* Tool ständig auf die neueste Git-Version zu aktualisieren. Ein gutes Beispiel dafür ist vor ein paar Tagen passiert, als wir das SET aktualisiert haben Paket. Zwei Tage nachdem wir das Paket aktualisiert hatten, erhielten wir in unserem Bugtracker eine „Tool-Upgrade“-Anfrage für SET, da unser Paket bereits veraltet war. Klingt ein bisschen extrem? Vielleicht nicht, betrachten Sie das folgende Rätsel :
Sie haben morgen ein Audit und bereiten Ihre Werkzeuge vor. Sie booten Kali Linux und führen ein „apt-get update &&apt-get upgrade aus “, um sicherzustellen, dass Sie die neuesten stabilen Versionen von $your_favorate_tool ausführen . Nach dem Update bemerken Sie, dass $your_favorate_tool hat ein Paket, das letzte Woche in unseren Repositories aktualisiert wurde. In der vergangenen Woche wurden jedoch einige ziemlich tolle Updates zu $your_favorate_tool hinzugefügt Upstream, und Sie brauchen diese neuen Funktionen wirklich für die bevorstehende Bewertung. Was machst du?
Das Schlimmste, was zu tun ist.
Angenommen, Sie verwenden Kali nicht als „Throw Away Instance“, ist das Schlimmste, was Sie in diesem Fall tun können, gepackte Dateien zu überschreiben. Zum Beispiel sind die folgenden Befehle zum Aktualisieren eines Tools, das häufig aktualisiert wird, ein großes Nein-Nein und wird letztendlich Ihre Installation in der Zukunft beschädigen.
# dont update tools like this!
cd /usr/share/
rm -rf $your_favorate_tool
git clone $your_favorate_tool
Okay To Do…aber, Meh.
Da Sie nicht mit gepackten Dateien herumspielen sollten , ist die gebräuchlichste Option, svn oder git checkout $your_favorate_tool in einem temporären Verzeichnis und verwenden Sie es von dort aus wie unten gezeigt. In den meisten Fällen sind alle für das aktualisierte Tool erforderlichen Abhängigkeiten bereits in Kali vorhanden. Alternativ können Sie sich dafür entscheiden, das Quellpaket neu zu erstellen, das Ihre Aktualisierungen und Änderungen enthält.
cd ~
mkdir work
cd work
git clone $your_favorate_tool
cd $your_favorate_tool
./your_favorate_tool
Unsere Lösung.
Wir sagten *schließen* zu unmöglich, oder? Diesen Konflikt zwischen der Aktualisierungshäufigkeit einiger Tools und der Notwendigkeit (mancher Leute, nicht aller) zu sehen, „immer die neueste Version von $your_favorate_tool zu haben “, haben wir eine interessante Lösung gefunden. Wir haben ein Opt-in „Bleeding Edge von Kali“ eingerichtet ” Repository, das tägliche Builds für mehrere nützliche und häufig aktualisierte Tools enthält. Diese Repositories sind immer noch sehr experimentell (was bedeutet, dass wir davon ausgehen, dass die Dinge von Zeit zu Zeit kaputt gehen, bis wir mehr Feedback von der Community erhalten). Wenn Sie diese Funktion ausprobieren möchten, können Sie gerne das Bleeding-Edge-Repository wie unten gezeigt hinzufügen. Denken Sie jedoch bitte an den Begriff „Bleeding Edge “. Es gibt einen Grund für das Blut.
echo deb http://http.kali.org/kali kali-bleeding-edge contrib non-free main >> /etc/apt/sources.list
apt-get update
apt-get upgrade
Wir haben derzeit eine Handvoll Tools in diesem Repository, darunter se-toolkit (set), aircrack-ng , dnsrecon , sqlmap , rfidiot , Beef-xss , libnfc , libfreefare , mfoc und mfcuk . Wir erwarten, dass diese Liste mit der Zeit wächst.