Hemos estado ocupados esta semana, todavía atrasados en nuestros correos electrónicos, pero avanzando con fuerza con el desarrollo de Kali. Empaquetamos algunas herramientas nuevas que la comunidad señaló que faltaban, como inguma , arachni , matón , libras , unisca , automatizador , así como comenzó a construir un marco de bibliotecas y parches para herramientas de detección de bluetooth y ubertooth. También arreglamos el menú de Kali para que se pueda volver a editar.
Con más de 300 herramientas en nuestro repositorio, es casi imposible para nosotros mantener *todas* las herramientas actualizadas a la última versión de git, todo el tiempo. Un buen ejemplo de esto sucedió hace unos días, cuando actualizamos el SET paquete. Dos días después de que actualizamos el paquete, recibimos una solicitud de "actualización de herramientas" para SET en nuestro rastreador de errores, ya que nuestro paquete ya estaba desactualizado. ¿Parece un poco extremo? Tal vez no, considere el siguiente enigma :
Tiene una auditoría mañana y está preparando sus herramientas. Inicia Kali Linux, ejecuta un "apt-get update &&apt-get upgrade ” para asegurarse de que está ejecutando las últimas versiones estables de $your_favorate_tool . Después de la actualización, observa que $your_favorate_tool tiene un paquete que se actualizó la semana pasada en nuestros repositorios. Sin embargo, la semana pasada, se agregaron algunas actualizaciones increíbles a $your_favorate_tool aguas arriba, y realmente necesita esas nuevas funciones para la próxima evaluación. ¿Qué haces?
Lo peor que hacer.
Suponiendo que no está utilizando Kali como una "instancia desechable", lo peor que puede hacer en este caso es sobrescribir los archivos empaquetados. Por ejemplo, los siguientes comandos para actualizar una herramienta que se actualiza con frecuencia es un gran no-no y finalmente romperá su instalación en el futuro.
# dont update tools like this!
cd /usr/share/
rm -rf $your_favorate_tool
git clone $your_favorate_tool
OK To Do…pero, Meh.
Ya que no deberías estar jugando con archivos empaquetados , la opción más común es svn o git checkout $your_favorate_tool en un directorio temporal y utilícelo desde allí como se muestra a continuación. En la mayoría de los casos, todas las dependencias necesarias para la herramienta actualizada ya existirán en Kali. Alternativamente, puede optar por reconstruir el paquete fuente, que incluye sus actualizaciones y cambios.
cd ~
mkdir work
cd work
git clone $your_favorate_tool
cd $your_favorate_tool
./your_favorate_tool
Nuestra Solución.
Dijimos *cerrar* a imposible, ¿verdad? Al ver este choque entre la frecuencia de actualización de algunas herramientas y la necesidad (de algunas personas, no de todos) de “tener siempre la última revisión de $your_favorate_tool ”, se nos ocurrió una solución interesante. Hemos configurado un opt-in "Borde sangriento de Kali ” que contiene compilaciones diarias para varias herramientas útiles y actualizadas con frecuencia. Estos repositorios aún son altamente experimentales (lo que significa que esperamos que las cosas se rompan de vez en cuando hasta que obtengamos más comentarios de la comunidad). Si desea probar esta función, puede agregar el repositorio de vanguardia como se muestra a continuación; sin embargo, recuerde el término "Breeding Edge ”. Hay una razón para la sangre.
echo deb http://http.kali.org/kali kali-bleeding-edge contrib non-free main >> /etc/apt/sources.list
apt-get update
apt-get upgrade
Actualmente tenemos un puñado de herramientas en este repositorio, que incluyen se-toolkit (conjunto), aircrack-ng , dnsrecon , sqlmap , rfidiota , carne-xss , libnfc , libfreefare , mfoc y mfcuk . Esperamos que esta lista crezca con el tiempo.