Autor Tema: BullyWPSdialog v1.0 - Interface dialog para auditar WPS con bully (Leído 62921 veces)

USUARIONUEVO · « **Respuesta #20 en:** 24-09-2013, 22:12 (Martes) »

Cita de: warcry en 24-09-2013, 21:02 (Martes)

Cita de: geminis_demon en 24-09-2013, 20:53 (Martes)

Es mas efectivo desmontar el driver y volver a montarlo, que hacer un ifconfig wlan0 down

Además al hacer eso, también se desmonta automáticamente mon0 si es que existiera, por tanto me ahorro hacer otra función para desmontar las tarjetas que estén en modo monitor

pero yo creo que de ese modo te cepillas la wlanX y la atheros 9k no es capaz de recuperarse, y simplemente con un simple down/up consigues lo mismo.

a ver si newuser lo prueba y me dice de si asi no le da problemas la ath9k

en esta ocasion geminis esta mejor encaminado.

desmontar driver ya te la deja abajo , y ademas como recien estrenada.

solo un up y listo.

Con una ath9k , te conectas a un ap y te desconectas y la interface queda abajo , ...pues abajo ..NO VA CON REAVER NI NADA...SIN EMBARGO SI DESMONTAS EL DRIVER , y asi te queda abajo tambien , pero entonces si funciona con lo que es evidente que desmontar el driver es mucho mejor que down+up

Aqui solo falta saber por que con las usb atheros falla...por que todas las demas usb van bien ( realtek y ralink ).

Tengo que probar algo ... por que al desmontar el driver se supone que las interfaces en monitor deberian desaparecer sin embargo yo las sigo viendo up ...

creo que cuando hay mas de una athX , se equivoca de interface , pero noe estoy seguro.

warcry · « **Respuesta #21 en:** 24-09-2013, 22:28 (Martes) »

cuando haceis lo que decis, estais montando la interface como otro medio fisico.

Código: [Seleccionar]

wifislax ~ # iwconfig
wlan0     IEEE 802.11bgn  ESSID:off/any  
          Mode:Managed  Access Point: Not-Associated   Tx-Power=0 dBm   
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:on
          
lo        no wireless extensions.

eth0      no wireless extensions.

wifislax ~ # airmon-ng start wlan0


Found 1 processes that could cause trouble.
If airodump-ng, aireplay-ng or airtun-ng stops working after
a short period of time, you may want to kill (some of) them!

PID     Name
1898    dhcpcd


Interface       Chipset         Driver

wlan0           Ralink RT2870/3070      rt2800usb - [phy0]
                                (monitor mode enabled on mon0)

wifislax ~ # iwconfig
wlan0     IEEE 802.11bgn  ESSID:off/any  
          Mode:Managed  Access Point: Not-Associated   Tx-Power=35 dBm   
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:on
          
lo        no wireless extensions.

mon0      IEEE 802.11bgn  Mode:Monitor  Frequency:2.412 GHz  Tx-Power=35 dBm   
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Power Management:on
          
eth0      no wireless extensions.                                               
                                                                                
wifislax ~ # rmmod -f rt2800usb                                                 
wifislax ~ # iwconfig
lo        no wireless extensions.

eth0      no wireless extensions.

wifislax ~ # modprobe rt2800usb
wifislax ~ # iwconfig
wlan0     IEEE 802.11bgn  ESSID:off/any  
          Mode:Managed  Access Point: Not-Associated   Tx-Power=0 dBm   
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:on
          
lo        no wireless extensions.

eth0      no wireless extensions.

wifislax ~ # ifconfig wlan0 up
wifislax ~ # iwconfig
wlan0     IEEE 802.11bgn  ESSID:off/any  
          Mode:Managed  Access Point: Not-Associated   Tx-Power=35 dBm   
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:on
          
lo        no wireless extensions.

eth0      no wireless extensions.

wifislax ~ # airmon-ng start wlan0


Found 1 processes that could cause trouble.
If airodump-ng, aireplay-ng or airtun-ng stops working after
a short period of time, you may want to kill (some of) them!

PID     Name
1898    dhcpcd


Interface       Chipset         Driver

wlan0           Ralink RT2870/3070      rt2800usb - [phy1]
                                (monitor mode enabled on mon0)

wifislax ~ #

hemos pasado del phy0 al phy1, y cuanto mas veces se repita el script mas medios fisicos creareis... son infinitos

a mi me da que no

sin embargo con un simple down/up mantienes el medio fisico en este caso phy1

Código: [Seleccionar]

wifislax ~ # ifconfig wlan0 down
wifislax ~ # ifconfig wlan0 up
wifislax ~ # airmon-ng start wlan0


Found 1 processes that could cause trouble.
If airodump-ng, aireplay-ng or airtun-ng stops working after
a short period of time, you may want to kill (some of) them!

PID     Name
1898    dhcpcd


Interface       Chipset         Driver

wlan0           Ralink RT2870/3070      rt2800usb - [phy1]
                                (monitor mode enabled on mon0)

wifislax ~ #

no digo que esto sea el causante de lo que le pasa a las atheros 9k, pero bueno no tiene que ser tampoco...

USUARIONUEVO · « **Respuesta #22 en:** 24-09-2013, 22:54 (Martes) »

solo lo digo una vez mas..

ya no basta un simple down / up si lo quieres entender vale sino pues nada.

estos drivers no son iguales..y si ya te has conectado a un ap , por mucho up/down y la del medio ..el driver se queda pillao...necesita limpieza total.

esto sucede del 3.9 hacia arriba.

en el 3.9.11 aun funcionaba bien con un simple down y up ..pero ya no.

es por eso que las ath9k ( las pci ) , necesitan un up ...cuando antes no...sin embargo las ath9 USB , pueden pirular con la interface abajo ...aunque no probe a conectarme y desconectarme de un ap, para comprobar si el driver queda tocado.

mire todos los procesos y no hay ni wpa supplicant ni nada a lo que hechar la culpa...cuando desconectas desde wicd, este ya tumba todo el solo.

lo de la phy ya lo vi ... no hay problema en eso , ademas al reiniciar el equipo todo vuelve a cero.

warcry · « **Respuesta #23 en:** 24-09-2013, 23:08 (Martes) »

A ver que lo entienda yo, me estás diciendo que cuando utilizas wicd tienes que tirar el driver abajo para que funcione en modo monitor

Y de ser así, ninguna GUI, ni ninguna aplicacion, ni script anterior funcionará con este tipo kernel

geminis_demon · « **Respuesta #24 en:** 24-09-2013, 23:39 (Martes) »

Citar

Tengo que probar algo ... por que al desmontar el driver se supone que las interfaces en monitor deberian desaparecer sin embargo yo las sigo viendo up ...

creo que cuando hay mas de una athX , se equivoca de interface , pero noe estoy seguro.

Decias que esos chipset usaban 2 drivers, ¿has probado a desmontar los 2 y volver a montarlos maualmente?

Puede que el problema sea que el script solo detecta un driver y el otro lo deja desmontado.

Que rabia no tener un adaptador con ese chip para poder hacer las pruebas.. $:-\$

alist3r · « **Respuesta #25 en:** 25-09-2013, 01:03 (Miércoles) »

Cita de: warcry en 24-09-2013, 21:02 (Martes)

Cita de: geminis_demon en 24-09-2013, 20:53 (Martes)

Es mas efectivo desmontar el driver y volver a montarlo, que hacer un ifconfig wlan0 down

Además al hacer eso, también se desmonta automáticamente mon0 si es que existiera, por tanto me ahorro hacer otra función para desmontar las tarjetas que estén en modo monitor

pero yo creo que de ese modo te cepillas la wlanX y la atheros 9k no es capaz de recuperarse, y simplemente con un simple down/up consigues lo mismo.

a ver si newuser lo prueba y me dice de si asi no le da problemas la ath9k

la atheros de newuser no lo se, pero la mia, va mucho mejor reventando el driver para luego recargarlo.
no hay color.

alist3r · « **Respuesta #26 en:** 25-09-2013, 01:04 (Miércoles) »

Cita de: geminis_demon en 24-09-2013, 23:39 (Martes)

Citar
Tengo que probar algo ... por que al desmontar el driver se supone que las interfaces en monitor deberian desaparecer sin embargo yo las sigo viendo up ...

creo que cuando hay mas de una athX , se equivoca de interface , pero noe estoy seguro.

Decias que esos chipset usaban 2 drivers, ¿has probado a desmontar los 2 y volver a montarlos maualmente?

Puede que el problema sea que el script solo detecta un driver y el otro lo deja desmontado.

Que rabia no tener un adaptador con ese chip para poder hacer las pruebas.. $:-\$

los driver de tipo biblioteca no deberian dar problemas porque no son los que instancian a los dispositivos. son solo rutinas cargadas en la zona de memoria del núcleo.

USUARIONUEVO · « **Respuesta #27 en:** 25-09-2013, 10:53 (Miércoles) »

Cita de: warcry en 24-09-2013, 23:08 (Martes)

A ver que lo entienda yo, me estás diciendo que cuando utilizas wicd tienes que tirar el driver abajo para que funcione en modo monitor

Y de ser así, ninguna GUI, ni ninguna aplicacion, ni script anterior funcionará con este tipo kernel

si que funcionan , PERO , funcionan MUCHO mejor cuando el driver es recargado y limpiado despues de una conexion al ap.

solo eso , que va mejor si el driver es remonatado...ya que queda totalmente limpio.

alist3r · « **Respuesta #28 en:** 25-09-2013, 11:00 (Miércoles) »

y el que no lo entienda, le invito a hacer esta prueba:
recién inicializado, un adaptador está sin un canal asignado.
normalmente se queda saltando canales libremente, buscando redes que conoce.
si ejecutas iwconfig, no hay ningun dato relevante de frecuencua/canal.

cuando el adaptador ha estado conectado en un canal, obviamente ha tenido ajustado un canal especifico, y eso se queda ahí, en el kernel, mientras esa instancia del dispositivo siga en memoria.

intentad DES-setear el canal en el que ya ha estado la interfaz conectada previamente, usando comandos (esto tiene trampa

)
probad reaver/bully.

luego desinstanciad el driver totalmente con rmmod. cargadlo de nuevo. y sin pasar por el modo managed en absoluto, iniciliazadla en modo monitor.
probad de nuevo reaver/bully.

en mi atheros de la serie 9000 el resultado es diametralmente opuesto. y tembien tengo que recordaros que gran parte de los parches que se han introducido en el kenel 3.9 en adelante, son precisamente para sortear por las bravas el comportamiento del kernel, que oficialmente no permite instancias de interfaces en modo monitor mientras exista una sola instancia de la misma interfaz en modo managed, para evitar, precisamente, este problema del bloqueo de canales (que poro otro lado es totalmente lógico que se produzca, porque la instancia managed necesita forzosamente el bloqueo de canal)

USUARIONUEVO · « **Respuesta #29 en:** 25-09-2013, 11:21 (Miércoles) »

Bueno , de momento puedo decir y digo , que el problema de las usb atheros viene por la funcion de desmontar el driver.

si comento esa funcion , el adaptador tira bien en el script.

asi que , me tocara jugar a las 7 diferencias ...e intentar ver por que cuando se desmonta y remonta el driver , el adaptador no tira.

warcry · « **Respuesta #30 en:** 25-09-2013, 11:23 (Miércoles) »

Cita de: USUARIONUEVO en 25-09-2013, 11:21 (Miércoles)

Bueno , de momento puedo decir y digo , que el problema de las usb atheros viene por la funcion de desmontar el driver.

si comento esa funcion , el adaptador tira bien en el script.

asi que , me tocara jugar a las 7 diferencias ...e intentar ver por que cuando se desmonta y remonta el driver , el adaptador no tira.

estaba claro

alist3r · « **Respuesta #31 en:** 25-09-2013, 11:27 (Miércoles) »

Cita de: USUARIONUEVO en 25-09-2013, 11:21 (Miércoles)

Bueno , de momento puedo decir y digo , que el problema de las usb atheros viene por la funcion de desmontar el driver.

si comento esa funcion , el adaptador tira bien en el script.

asi que , me tocara jugar a las 7 diferencias ...e intentar ver por que cuando se desmonta y remonta el driver , el adaptador no tira.

respecto a las usb atheros no puedo ayudar en nada. eso si, parece claro que su comportamiento es totalmente diferente :-S

USUARIONUEVO · « **Respuesta #32 en:** 25-09-2013, 14:59 (Miércoles) »

Cita de: warcry en 25-09-2013, 11:23 (Miércoles)

Cita de: USUARIONUEVO en 25-09-2013, 11:21 (Miércoles)
Bueno , de momento puedo decir y digo , que el problema de las usb atheros viene por la funcion de desmontar el driver.

si comento esa funcion , el adaptador tira bien en el script.

asi que , me tocara jugar a las 7 diferencias ...e intentar ver por que cuando se desmonta y remonta el driver , el adaptador no tira.

estaba claro

el que estaba claro ?...si solo falla con los usb atheros..los demas chipsets usb resetean perfectamente.

USUARIONUEVO · « **Respuesta #33 en:** 25-09-2013, 15:05 (Miércoles) »

Bien , ..como soy un negado del bash ..

me he hecho un mini script con la funcion , y direcatmente el nombre de la interface (wlan1 )

Código: [Seleccionar]

#!/bin/bash

DRIVER="$(basename "$(ls -l "/sys/class/net/wlan1/device/driver")")"

echo "$DRIVER"

el cual me responde

ath9k_htc

PERO EN REALIDAD EL PADRE ES ..

ath9k

el que hay que resetear es ath9k ...

Creo que ningun driver wifi ..lleva la barra baja ...

¿ en DRIVER= UNa funcion cut para eliminar y dejar solo ath9k ? ?

alist3r · « **Respuesta #34 en:** 25-09-2013, 15:53 (Miércoles) »

Cita de: USUARIONUEVO en 25-09-2013, 15:05 (Miércoles)

Bien , ..como soy un negado del bash ..

me he hecho un mini script con la funcion , y direcatmente el nombre de la interface (wlan1 )

Código: [Seleccionar]
#!/bin/bash DRIVER="$(basename "$(ls -l "/sys/class/net/wlan1/device/driver")")" echo "$DRIVER"
el cual me responde

ath9k_htc

PERO EN REALIDAD EL PADRE ES ..

ath9k

el que hay que resetear es ath9k ...

Creo que ningun driver wifi ..lleva la barra baja ...

¿ en DRIVER= UNa funcion cut para eliminar y dejar solo ath9k ? ?

bueeeeno, ahora que lo dicessssss...
el caso de las atheros usb es interesante.

porque en lugar de tener un driver biblioteca y un driver especifico (como las rtl), tiene un driver general y un driver de capa.

el driver htc proporciona la capa de transporte hacia el usb, de toda la lógica implementada en el driver ath9k.

si me preguntan cuál de los dos sería bueno borrar y reinsertar....... no me atreveria a responder.

es posible que parte de la instancia del dispositivo la esté manejando el ath9k, ya que es él quien proporciona la lógica, la abstracción y la capa de comunicación con el stack wireless del kernel. sin embargo, ese modulo por si solo no podria controlar un usb dado que necesita el ath9k_htc.

seria bueno hacer las pruebas por separado. desinstanciando el htc y viendo si por sí solo es capaz de causar cambios.

alist3r · « **Respuesta #35 en:** 25-09-2013, 15:55 (Miércoles) »

Cita de: USUARIONUEVO en 25-09-2013, 15:05 (Miércoles)

Creo que ningun driver wifi ..lleva la barra baja ...

¿ en DRIVER= UNa funcion cut para eliminar y dejar solo ath9k ? ?

si, claro.

echo $DRIVER | cut -d"_" -f1

y listo.

de todos modos, hay que asegurarse de que esa suposición es acertada. podemos liarla, si no.

alist3r · « **Respuesta #36 en:** 25-09-2013, 15:56 (Miércoles) »

te paso un lsmod filtrado con las lineas que contienen guion bajo:

root@engetsu:~# lsmod | grep _
nls_utf8 12456 0
hid_generic 12393 0
hid 81782 2 hid_generic,usbhid
pci_stub 12429 1
binfmt_misc 12925 1
videobuf2_vmalloc 12848 1 uvcvideo
videobuf2_memops 12519 1 videobuf2_vmalloc
videobuf2_core 31098 1 uvcvideo
videodev 92451 2 uvcvideo,videobuf2_core
usb_storage 47976 1
snd_hda_codec_hdmi 31720 4
snd_hda_codec_realtek 32667 1
snd_hda_intel 31229 5
snd_hda_codec 122910 3 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_intel
snd_hwdep 13189 1 snd_hda_codec
snd_pcm_oss 41175 0
snd_mixer_oss 18034 1 snd_pcm_oss
snd_pcm 68435 4 snd_pcm_oss,snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel
crc32c_intel 21889 0
snd_page_alloc 13018 2 snd_pcm,snd_hda_intel
snd_seq_midi 12848 0
snd_seq_midi_event 13316 1 snd_seq_midi
snd_rawmidi 22995 1 snd_seq_midi
snd_seq 45106 2 snd_seq_midi_event,snd_seq_midi
snd_timer 22682 2 snd_pcm,snd_seq
sr_mod 21988 0
snd_seq_device 13176 3 snd_seq,snd_rawmidi,snd_seq_midi
iTCO_wdt 12831 0
sdhci_pci 17935 0
iTCO_vendor_support 12704 1 iTCO_wdt
cdrom 35173 1 sr_mod
snd 52903 22 snd_hda_codec_realtek,snd_pcm_oss,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_seq,snd_rawmidi,snd_hda_codec,snd_hda_intel,snd_seq_device,snd_mixer_oss
sdhci 27061 1 sdhci_pci
mmc_core 77769 2 sdhci,sdhci_pci
ehci_pci 12472 0
ehci_hcd 40590 1 ehci_pci
sparse_keymap 12760 0
mei_me 13568 0
lpc_ich 16757 0
mfd_core 12601 1 lpc_ich
usbcore 134644 7 btusb,uvcvideo,rtlwifi,usb_storage,ehci_hcd,ehci_pci,usbhid
usb_common 12440 1 usbcore
mei 45886 1 mei_me
serio_raw 12894 0
i2c_core 24353 3 drm,nvidia,videodev
toshiba_bluetooth 12641 0
thermal_sys 23137 3 video,thermal,processor

USUARIONUEVO · « **Respuesta #37 en:** 25-09-2013, 16:01 (Miércoles) »

aprovecho que estas ON...

lo que queria hacer es una variable if, para que en el caso de

$DRIVER=ath9k_htc

entonces aplicarle el cut ,perio no me sale, por que en realidad no se mucho de bash..

este es mi intento fallido.

Código: [Seleccionar]

#!/bin/bash

DRIVER="$(basename "$(ls -l "/sys/class/net/wlan1/device/driver")")"

if [ $DRIVER = "ath9k_htc" ]; then
DRIVER=`$DRIVER | cut -d "_" -f 1´
fi

echo "$DRIVER"

la idea asi es mucho mejor ..solo aplicaremos cut al driver ath9k , ...es mucho mejor , pero omo siempre ...estoy limitado , al final me saldria, por que cabezon soy un rato , pero no tengo mucho tiempo ahora...

si lo ves y me das la solucion o si entra geminis, lo pruebo rapido y os digo.

por que tengo ath9k usb ( 2 tarjetas )

y mas o menos me defiendo.

USUARIONUEVO · « **Respuesta #38 en:** 25-09-2013, 16:05 (Miércoles) »

la funcion original es esta..hay que meterle el if ...

Código: [Seleccionar]

reset_iface() {

DRIVER="$(basename "$(ls -l "/sys/class/net/$INTERFACE/device/driver")")"

rmmod -f "$DRIVER" >/dev/null 2>&1
modprobe "$DRIVER" >/dev/null 2>&1
ifconfig $INTERFACE up >/dev/null 2>&1
}

alist3r · « **Respuesta #39 en:** 25-09-2013, 16:10 (Miércoles) »

una especie de "driver filter" podría hacerse así:

Código: [Seleccionar]

case "$DRIVER" in


  ath9k)
  # aqui las transformaciones necesarias para el caso del driver ath9k
  # por ejemplo:
  DRIVER="ath9k_htc"
  ;;


  rtl8139se, rtl8139ce, rtl8139su, rtl8139blablabla)
  # aqui las transformaciones necesarias para el caso drivers diversos de realtek
  DRIVER="rtlwifi" # es un poco bestia, pero es un ejemplo
  ;;


  *)
  # aqui el codigo referente a casos que no encajan en ninguno de los anteriores
  blah=blah
  ;;


esac

todo esto, justo después de

Código: [Seleccionar]

DRIVER="$(basename "$(ls -l "/sys/class/net/$INTERFACE/device/driver")")"

Noticias:

Autor Tema: BullyWPSdialog v1.0 - Interface dialog para auditar WPS con bully (Leído 62921 veces)

warcry

warcry

alist3r

alist3r

alist3r

warcry

alist3r

alist3r

alist3r

alist3r

alist3r