Siamo stati impegnati questa settimana, ancora indietro con le nostre e-mail, ma andando forte con lo sviluppo di Kali. Abbiamo confezionato alcuni nuovi strumenti che la community ha indicato come mancanti, come inguma , aracni , prepotente , libbra , uniscan , automazione , così come ha iniziato a creare un framework di librerie e patch per lo sniffing bluetooth e gli strumenti ubertooth. Abbiamo anche corretto il menu Kali in modo che fosse nuovamente modificabile.
Con oltre 300 strumenti nel nostro repository, è quasi impossibile per noi mantenere *ogni* strumento aggiornato all'ultima versione di git, tutto il tempo. Un buon esempio di ciò è accaduto qualche giorno fa, quando abbiamo aggiornato il SET pacchetto. Due giorni dopo aver aggiornato il pacchetto, abbiamo ricevuto una richiesta di "aggiornamento dello strumento" per SET nel nostro bug tracker, poiché il nostro pacchetto era già obsoleto. Sembra un po' estremo? Forse no, considera il seguente enigma :
Domani hai un audit e stai preparando i tuoi strumenti. Avvia Kali Linux, esegui un "apt-get update &&apt-get upgrade ” per assicurarti di eseguire le ultime versioni stabili di $your_favorate_tool . Dopo l'aggiornamento, noti che $your_favorate_tool ha un pacchetto che è stato aggiornato la scorsa settimana nei nostri repository. Tuttavia, la scorsa settimana, sono stati aggiunti alcuni fantastici aggiornamenti a $your_favorate_tool a monte e hai davvero bisogno di queste nuove funzionalità per la valutazione imminente. Che cosa fai?
Cosa peggiore da fare.
Supponendo che tu non stia usando Kali come "istanza butta via", la cosa peggiore da fare in questo caso è sovrascrivere i file compressi. Ad esempio, i seguenti comandi per aggiornare uno strumento che viene aggiornato frequentemente sono assolutamente da evitare e alla fine interromperà la tua installazione in futuro.
# dont update tools like this!
cd /usr/share/
rm -rf $your_favorate_tool
git clone $your_favorate_tool
OK per fare…ma, Meh.
Dal momento che non dovresti pasticciare con i file compressi , l'opzione più comune è svn o git checkout $your_favorate_tool in una directory temporanea e utilizzarlo da lì come mostrato di seguito. Nella maggior parte dei casi, tutte le dipendenze necessarie per lo strumento aggiornato di solito esistono già in Kali. In alternativa, puoi scegliere di ricostruire il pacchetto sorgente, che include gli aggiornamenti e le modifiche.
cd ~
mkdir work
cd work
git clone $your_favorate_tool
cd $your_favorate_tool
./your_favorate_tool
La nostra soluzione.
Abbiamo detto *chiudi* all'impossibile, giusto? Vedendo questo scontro tra la frequenza di aggiornamento di alcuni strumenti e la necessità (di alcune persone, non di tutti) di “avere sempre l'ultima revisione di $your_favorate_tool ”, abbiamo trovato una soluzione interessante. Abbiamo impostato un "bordo sanguinante di Kali" di attivazione ” repository che contiene build giornaliere per diversi strumenti utili e frequentemente aggiornati. Questi repository sono ancora altamente sperimentali (il che significa che ci aspettiamo che le cose si interrompano di tanto in tanto fino a quando non riceviamo più feedback dalla community). Se vuoi provare questa funzione, puoi aggiungere il repository bleeding edge come mostrato di seguito, tuttavia, ricorda che il termine "bleeding edge ”. C'è una ragione per il sangue.
echo deb http://http.kali.org/kali kali-bleeding-edge contrib non-free main >> /etc/apt/sources.list
apt-get update
apt-get upgrade
Al momento abbiamo una manciata di strumenti in questo repository, che includono se-toolkit (impostato), aircrack-ng , dnsrecon , mappa sql , rfidiota , beef-xss , libnfc , libfreefare , mfoc e mfcuk . Ci aspettiamo che questo elenco cresca con il tempo.