Seguridad Wireless - Wifi
Suite Seguridad Wireless => Live wifislax => Mensaje iniciado por: Zup en 05-01-2022, 08:40 (Miércoles)
-
Pues eso, que me fallan varios actualizadores. Algunos los he conseguido arreglar, otros no. Ahí va una lista de problemas y algunas soluciones...
Actualizadores que no detectan (bien) la versión (con soluciones):
- pocl_updater, xxHash_updater y wpscan_updater no detectan bien la versión a bajar, en todos los casos aparece como 'ref' (y no actualiza). La solución para los tres es la misma: ir a la línea 24 del updater (la que empieza por VERSION) y sustituir 'cut -d/ -f5' por 'cut -d/ -f7'
- arp-scan_updater tampoco lee bien la versión (aparece como arp-scan-arp-scan-1.9). La solución es ir a la línea 24 y sustituir '$WEB/releases' por '$WEB/tags'. No hay versión más actual, pero imagino que así funcionará para futuras actualizaciones.
Actualizador que no apunta a donde debe (con solución):
- rtl88x2bu_updater no compila. Descarga un texto donde dice que el repositorio está en otra parte. Para que descargue (y compile), hay que cambiar la línea 20 para que diga 'SRCNAM=88x2bu-20210702'.
¿Qué pasa con los actualizadores de realtek?
Hay un par de actualizadores que SIEMPRE dicen que hay versión nueva (sea cierto o no). Uno de ellos (rtl8188eus) creo que lee mal la versión... tendré que darle una vuelta a ver si lo arreglo.
Paquetes a NO instalar o actualizar:
Probando he descubierto que openssh y polkit no deben ser instalados o actualizados (lo que es una pena porque openssh es el que nos permite usar scp). El problema (en ambos) es que esos paquetes txz tienen scripts de instalación que modifica ficheros en /etc (/etc/passwd, /etc/shadow y /etc/group). Al convertirlos a xzm, estos ficheros no se incluyen y provocan que Wifislax no arranque (se queda pidiendo contraseña y las rechaza todas).
La solución al no arranque es quitar el módulo donde hayamos instalado/actualizado estos paquetes. Actualizarlos ya es más peliagudo... una posible solución sería descomprimir los ficheros txz, poner los ficheros correspondientes y después recomprimir a txz y convertir a xzm... no lo he probado. En cualquier caso, una solución permanente y automatizada conllevaría modificar el script que convierte a xzm o incluir ambos paquetes en la distribución base y crearles updaters específicos.
Otros módulos que NO actualizan:
- wireshark: Varios fallos de compilación, no sé si son debidos a que no se genera bien config.h o a fallos en el repositorio. La última versión que me compiló es la 3.4.5, ahora van por la 3.6.1. Lo más lejos que he llegado ha sido incluyendo <stdint.h> en el fichero ui/qt/rtp_audio_file.h e incluyendo <string.h> en el fichero wsutil/glib-compat.h (y aún así no compila). Se eliminan todos los errores de compilación (solo hay warnings), pero ld protesta porque no encuentra qInitResources_about().
- gslapt y slapt-get. Un caso curioso, protestan (casi) por las mismas cosas. He conseguido compilar slapt-get comentando la línea 64 del Makefile (en esta línea intenta hacer más pequeños los ejecutables, pero los encuentra), pero luego Wifislax falla al intentar conseguir la lista de paquetes (¿fallo al generar el xzm?¿hay que modificar el script?). Curiosamente si slapt-get se compila correctamente, el actualizador de gslapt funciona bien... y gslapt sí es capaz de obtener la lista de paquetes.
- firmwares... por algúin extraño la primera vez que se lanza (manualmente) no recupera la versión, pero la segunda vez sí.
-
Hola , voy a intentar explicar algunas cosas , para que se e tienda por que a veces , sin saberlo , creamos conflictos de paquete.
Los actualizadores basciamente comparan la version del sistema con la que se detecte en la web del autor , si no son igual se determina que la de la pagina web es mas nueva y por lo tanto veremos el mensaje de evrsion nueva.
Normalmente un paquete trabaja con numeros enteros de esta forma
paquete-1.1
paquete-1.2
de manera que el script aunque tengas varias versiones , siempre compara el numero mas alto del sistema , con la de la pagina web.
con los drivers , eso no funciona , por que no usan numeros enteros ...usan el commit identificador de movimiento mas reciente en el codigo , y pueden ser cosas asi
12dcg4
rft6548
por lo que ordenar alfabeticamente o numericamente no sirve de nada
cuando guardais algo en modules en un xzm , lo que haceis es que teneis la version vieja + la nueva , cuando lo ideal seria tener solo siempre la mas nueva. si son paquetes que se identifican en version con numeros enteros , no hay problema aunque haya varios , con los drivers si , por que no se reflejan igual.
Juraria que para el modo live , las actualizaciones estan desactivadas por que maneterlo para live es mas complicado que en hdd ya que en live tendrias que saber donde esta cada cosa , para simplemente actualizarla en lugar de ir sumando versiones en modules.
Por eso los drivers realtek , te van a decir siempre que hay versiones nuevas , sea verdad o no , por que tienes mas de una en modo live.
-----------------------------
tema wireshark , no compilan las versiones nuevas , no se por que , ni tampoco lo voy a mirar , este mes saldra version nueva de wifislax con todo actualizado , no voy a perder tiempo en un problema de una version anterior.
---------------------------
temas actualizadores que no ven correctamente la version y necesitan ajustes ... los puedo arreglar.
-
me acabo de dar cuenta que hablas de actualizadores que no estan ni en wifislax 2.4 ...
¿que version estas usando?
no doy soporte a versiones viejas, asi que hasta aqui he llegado.
-
Utilizo una Wifislax 2.4 en pendrive USB, el kernel es 5.4.91. El fichero changelog tiene entradas hasta el 20/01/2021.
Al margen de eso, tiene instalados los siguientes módulos en \wifislax64\modules:
- Driver_nvidia-460.32.03-x86_64-1wifislax.xzm
- cudatoolkit-10.2.89-x86_64-1slackbuilds.xzm
- Multilib-kit-14.2-2wifislax.xzm
- multimedia-common-1.0-8wifislax.xzm
- webkit2gtk-kit-2.20.5-1wifislax.xzm
Los actualizadores han sido actualizados mediante el menú, la versión instalada es del 20220106.
Los dos únicos paquetes que menciono que no tienen updaters propios (se instalan a través de gslapt) son openssh y polkit. Por lo que he visto, slapt-get y gslapt tienen actualizadores propios pero también pueden instalarse a través de gslapt (no están bloqueados como el resto de librerías).
(Otra posible "solución" al problema de openssh y polkit sería incluir ambos en la distribución base y marcarlos como "bloqueados" en slapt-get/gslapt para que no actualicen nunca)
Añado un listado de los updaters que están presentes cuando arranco:
Auditoria:
aircrack-ng_updater
arp-scan_updater
bully_updater
ettercap_updater
hashcat-utils_updater
hashcat_updater
hydra_updater
ipscan_updater
johnny_updater
nmap_updater
patrones-conocidos_updater
pixiewps_updater
wireshark_updater
Drivers:
rtl8188eus_updater
rtl8192eu_updater
rtl8814au_updater
rtl88XXau_updater
rtl88x2bu_updater
Funciones:
funciones_updater
Internet:
frostwire_updater
teamviewer_updater
xampp_updater
Juegos:
four-in-a-row_updater
kde-games_updater
Librerias:
ffmpeg_updater
libnfc_updater
libquicktime_updater
pocl_updater
transcode_updater
xxHash_updater
Multimedia:
HandBrake_updater
ardour_updater
audacity_updater
avidemux_updater
bluray-keys_updater
exaile_updater
kodi_updater
lives_updater
vlc_updater
Navegadores:
firefox_updater
google-chrome_updater
Oficina:
libreoffice-helppack_updater
libreoffice-langpack_updater
libreoffice_updater
openoffice_updater
Pentest:
WebSploit-Framework_updater
armitage_updater
bulk_extractor_updater
burpsuite_updater
facebook_hack_tool_updater
metasploit_updater
pentbox_updater
web-sorrow_updater
wpscan_updater
Sistema:
firmwares_updater
gslapt_updater
jdk_updater
linux_updater
slapt-get_updater
wifislax-updaters_updater
EDITO: Arrancando la ISO en una máquina virtual fallan los mismos updaters y de la misma manera. El fichero que uso es wifislax64-2.4-final.iso con md5 15a709c588e85de6157645e8d64fa2ed
-
(Otra posible "solución" al problema de openssh y polkit sería incluir ambos en la distribución base y marcarlos como "bloqueados" en slapt-get/gslapt para que no actualicen nunca)
claro claro ;D
Mientras lo hagas solo para ti ,adelante ;D
-
Volviendo al tema de los drivers (y posiblemente otros actualizadores basados en git)...
Por algún extraño motivo, la detección de versiones en los Drivers me sigue fallando como una escopeta de feria. Alguno de los drivers no se ha actualizado en meses y me cambia de versión cada día.
Mi sugerencia (por ahora creo que me funciona) sería ir a la página de commits y coger el número más reciente. En el caso del actualizador rtl8188eus, sólo habría que cambiar una línea y quedaría como esta:
VERSION="5.3.9_$(curl -s $WEB/commits/v5.3.9|grep commit/|head -1|cut -d / -f7|cut -c 1-7)"
Otra sugerencia, mejorando un poco la usabilidad sería cambiar el número de versión por la fecha del último commit. En estos actualizadores, creo que la versión es algo informativo y que siempre se descarga la última versión mediante git clone, por lo que cambiar un número de commit por su fecha no debería afectar al resto del script. En el mismo actualizador, esto se conseguiría con esta líneas:
VERSION=$(curl -s $WEB/commits/v5.3.9|grep "Commits on"|head -1|cut -d'>' -f2 | cut -d '<' -f1| cut -d' ' -f3-5)
Yendo un poco más lejos, se puede reordenar la fecha para que se pueda ver más rápido si la versión es más reciente...
FECHA=$(curl -s $WEB/commits/v5.3.9|grep "Commits on"|head -1|cut -d'>' -f2 | cut -d '<' -f1| cut -d' ' -f3-5)
ANO=$(echo $FECHA | cut -c 9-12)
MES=$(echo $FECHA | cut -c 1-3)
DIA=$(echo $FECHA | cut -c 5-6)
VERSION="5.3.9_${ANO}${MES}${DIA}"
...aunque esto último solo sería útil si se convirtiera el MES en un número y se hiciera una actualización totalmente automatizada (sin consultar al usuario).
-
Volviendo al tema de los drivers (y posiblemente otros actualizadores basados en git)...
Por algún extraño motivo, la detección de versiones en los Drivers me sigue fallando como una escopeta de feria. Alguno de los drivers no se ha actualizado en meses y me cambia de versión cada día.
Mi sugerencia (por ahora creo que me funciona) sería ir a la página de commits y coger el número más reciente. En el caso del actualizador rtl8188eus, sólo habría que cambiar una línea y quedaría como esta:
VERSION="5.3.9_$(curl -s $WEB/commits/v5.3.9|grep commit/|head -1|cut -d / -f7|cut -c 1-7)"
Otra sugerencia, mejorando un poco la usabilidad sería cambiar el número de versión por la fecha del último commit. En estos actualizadores, creo que la versión es algo informativo y que siempre se descarga la última versión mediante git clone, por lo que cambiar un número de commit por su fecha no debería afectar al resto del script. En el mismo actualizador, esto se conseguiría con esta líneas:
VERSION=$(curl -s $WEB/commits/v5.3.9|grep "Commits on"|head -1|cut -d'>' -f2 | cut -d '<' -f1| cut -d' ' -f3-5)
Yendo un poco más lejos, se puede reordenar la fecha para que se pueda ver más rápido si la versión es más reciente...
FECHA=$(curl -s $WEB/commits/v5.3.9|grep "Commits on"|head -1|cut -d'>' -f2 | cut -d '<' -f1| cut -d' ' -f3-5)
ANO=$(echo $FECHA | cut -c 9-12)
MES=$(echo $FECHA | cut -c 1-3)
DIA=$(echo $FECHA | cut -c 5-6)
VERSION="5.3.9_${ANO}${MES}${DIA}"
...aunque esto último solo sería útil si se convirtiera el MES en un número y se hiciera una actualización totalmente automatizada (sin consultar al usuario).
Lo de usar la fecha en lugar del identificador de commit, es lo unico en lo que pense hace un tiempo y lo unico que valdria la pena
quedando las versiones algo asi
5.3.8_220220124 por ejemplo.
De todas formas tu problema lo sigues generando tu solito , por que en lugar de coger el modulo wifislax-drivers y actualizarlos, lo que haces es ir hechando modulos a la carpeta modules sin quitar las versiones viejas dentro de los modulos que lo contengan , ese es tu problema real y ningun otro , mas aun cuando vienen desactivados en el modo live , y que se activan al instalar en hdd , en donde el instalador realmente puede eliminar la version vieja cuando instala la nueva dejando solo la ultima en lugar de acumular versiones.
Estudiare lo de la fecha , por que es lo unico que vale la pena mirar ;)
-
Ten en cuenta que los "actualizadores" ,pueden actualizar en un sistema instalado , pero en un live , el script bajara y hara el modulo ...pero tu debes ser quien finalmente hagas esa actualizacion permanente , mediante la eliminacion/actualizacion.
Lo que decias de los problemas de polkit ............idem , tu solito te creas los problemas , por que en lugar de coger el modulo de slackware que tiene la version vieja , y actualizarla , lo ue haces es meter una mas en modules ... ;D