Autor Tema: BULLY: Mejoras, bugs, aclaraciones, etc.  (Leído 75594 veces)

0 Usuarios y 1 Visitante están viendo este tema.

alist3r

  • Visitante
Re: BULLY para tontos | BULLY for dummies
« Respuesta #140 en: 06-10-2013, 00:59 (Domingo) »
Brian está pasado su próxima versión de bully al sistema gettext.
Por tanto, en próximas versiónes se ofrecerá apoyo multiidioma.

Mientras tanto, yo he dejado de mantener la copia en castellano del código y me estaré encargando de crear y mantener un fichero "es.po" con todos los textos en español.
así evitamos mantener una copia separada del mismo programa traducido, que supondría duplicar trabajo y buscarse problemas de todo tipo.

De momento, esta última versión tendrás que volver a traducirla tú, si la necesitas.
Espero que en breve Brian integre al 100% el apoyo para gettext y bully presente los textos en el ingles o español de forma automática basándose en el "locale" de la sesión.
De ese modo, incluso podrás modificar los PO por tí mismo usando herramientas como PoEdit si no te gustan las propuestas de textos iniciales.

saludos



alist3r

  • Visitante
Re: BULLY: Mejoras, bugs, aclaraciones, etc.
« Respuesta #141 en: 06-10-2013, 02:12 (Domingo) »
he actualizado el primer post con algunas peticiones de Brian.

nada que no fuera ya de sentido común.


Por favor, cuando informéis de posibles errores en BULLY, deberíais incluir los siguientes datos:

marca y modelo de dispositivo wifi utilizado. si es interno de un portatil, indicad marca y modelo de portatil.

el comando exacto que se está usando para lanzar bully

versión de bully (bully -V)

si el adaptador es PCI, adjuntad la salida del siguiente comando:
lspci -vvnnk
(solo la parte referente a vuestro adaptador, si aparece)

si el adaptador es USB (tanto externo como interno), adjuntad la salida del siguiente comando:
lsusb -v
(solo la parte referente a vuestro adaptador, si aparece)

si el adaptador es USB (tanto externo como interno), adjuntad la salida del siguiente comando:
lsmod

En caso de que no aportéis todos estos datos, se hace prácticamente imposible poder ayudaros a resolver vuestros problemas de uso o encontrar errores en el código.

Gracias
alist3r

eskasi

  • Visitante
Re: BULLY: Mejoras, bugs, aclaraciones, etc.
« Respuesta #142 en: 14-10-2013, 12:16 (Lunes) »
Probando la compilacion de bully para openwrt (de jar229), obtengo este mensaje:

  • Loading randomized pins from '/root/.bully/pins'
[X] Random pin file has incorrect size, exiting

Se ha corrompido el fichero de pins ?? Si no le hecho nada

eskasi

  • Visitante
Re: BULLY: Mejoras, bugs, aclaraciones, etc.
« Respuesta #143 en: 14-10-2013, 12:34 (Lunes) »
No he dicho nada....lo borre y lo volvio a crear.
Sigo leyendo el hilo para saber porque no me cambia el PIN.

peluzza

  • Visitante
Re: BULLY: Mejoras, bugs, aclaraciones, etc.
« Respuesta #144 en: 24-11-2013, 17:15 (Domingo) »
Hola! Estoy trabajando en una herramienta para automatizar ataques con bully, y me estoy encontrando un escollo bastante insalvable con el stdout de bully. (usando python)

Por lo visto, si se lanza desde la terminal muestra perfectamente la salida de la aplicación como cualquier programa, pero, tanto usando la opción -o para que derive la salida a un archivo de texto, como intentando parsear la stdout directamente, hay que esperar a que el programa termine su ejecución para poder obtener el contenido. Esto dificulta mucho el control sobre la aplicación, ya que no hay manera de pasar el feedback a la aplicación que ha de controlar el ataque.

Ejecutando otros comandos de ejecución continua como ping, top etc, puedo acceder facilmente a la salida del programa y capturarla, pero bully se me está poniendo cuesta ariiba...

¿Alguien ha tenido experiencias similares o sabe su arreglo? de momento ya le puse un ticket a bdpurcell en su repo, espero que le haga un poquito de caso...
« Última modificación: 24-11-2013, 17:26 (Domingo) por peluzza »

Desconectado geminis_demon

  • Colaborador
  • *
  • Mensajes: 2377
  • Prácticas precisas precisan práctica
Re: BULLY: Mejoras, bugs, aclaraciones, etc.
« Respuesta #145 en: 24-11-2013, 19:22 (Domingo) »
Hola! Estoy trabajando en una herramienta para automatizar ataques con bully, y me estoy encontrando un escollo bastante insalvable con el stdout de bully. (usando python)

Por lo visto, si se lanza desde la terminal muestra perfectamente la salida de la aplicación como cualquier programa, pero, tanto usando la opción -o para que derive la salida a un archivo de texto, como intentando parsear la stdout directamente, hay que esperar a que el programa termine su ejecución para poder obtener el contenido. Esto dificulta mucho el control sobre la aplicación, ya que no hay manera de pasar el feedback a la aplicación que ha de controlar el ataque.

Ejecutando otros comandos de ejecución continua como ping, top etc, puedo acceder facilmente a la salida del programa y capturarla, pero bully se me está poniendo cuesta ariiba...

¿Alguien ha tenido experiencias similares o sabe su arreglo? de momento ya le puse un ticket a bdpurcell en su repo, espero que le haga un poquito de caso...


Yo me encontré con el mismo problema cuando estuve haciendo el script BullyWPSdialog, y al final lo que hice fue parsear el log de bully para salvar el pin y la clave obtenidos.

La luz cree que viaja más rápido que cualquier otra cosa, pero se equivoca; da lo mismo lo rápido que pueda viajar, porque al final, la luz descubre que la oscuridad ha llegado antes que ella, y la está esperando.

peluzza

  • Visitante
Re: BULLY: Mejoras, bugs, aclaraciones, etc.
« Respuesta #146 en: 24-11-2013, 21:05 (Domingo) »
Yo me encontré con el mismo problema cuando estuve haciendo el script BullyWPSdialog, y al final lo que hice fue parsear el log de bully para salvar el pin y la clave obtenidos.

Por el log te refieres a la salida del stdout / -o ? o deja algun log de sistema?

Veo que tu script también tiene ese problema... en fin a ver si Brian me da una solución, porque veo inviable lanzar y matar bully cada minuto para sacar el log :/

La realidad es que necesito conocer dinámicamente como va el ataque, para ir ajustando tiempos de idle sobre la marcha, detectar EAP, llevar la cuenta de pins etc.

vk496

  • Visitante
Re: Re: Re: BULLY: Mejoras, bugs, aclaraciones, etc.
« Respuesta #147 en: 24-11-2013, 22:31 (Domingo) »
Yo me encontré con el mismo problema cuando estuve haciendo el script BullyWPSdialog, y al final lo que hice fue parsear el log de bully para salvar el pin y la clave obtenidos.

Por el log te refieres a la salida del stdout / -o ? o deja algun log de sistema?

Veo que tu script también tiene ese problema... en fin a ver si Brian me da una solución, porque veo inviable lanzar y matar bully cada minuto para sacar el log :/

La realidad es que necesito conocer dinámicamente como va el ataque, para ir ajustando tiempos de idle sobre la marcha, detectar EAP, llevar la cuenta de pins etc.

Para LINSET con wpa_supplicant haré eso, lanzar y matar cada X segundos xD

Salu2

Solo sé que no se nada...

peluzza

  • Visitante
Re: BULLY: Mejoras, bugs, aclaraciones, etc.
« Respuesta #148 en: 24-11-2013, 22:56 (Domingo) »
Pues indagando algo por ahí, he encontrado el motivo, y una posible solución.

El motivo es que las aplicaciones desarrolladas con  C Standard IO Library (todo lo que tenga  #include <stdio.h>) tratan el buffer de salida en bloque, lo que se conoce como block-buffered.
Si el desarrollador no especifica cuando liberar buffer, el programa se lo guarda hasta fin de ejecución. Por lo visto es más eficiente que hacer aplicaciones unbuffered, es decir, con salida en tiempo real.

La solución pasa por utilizar expect unbuffer para forzar la ejecucion liberando el deadlock. http://linuxcommand.org/man_pages/unbuffer1.html

Para python por suerte existe una librería instalada por defecto en python, Pexpect, que tiene un método unbuffer para este tipo de tareas.
http://www.noah.org/wiki/Pexpect#Q%3a_Why_not_just_use_a_pipe_.28popen.28.29.29.3F


vk496 me temo que para mi es inviable matar cada poco, ya que voy a intentar rizar el rizo lanzando ataques múltiples simultaneos con bully, y necesito llevar un control férreo sobre los PID que ejecuto.

Alister, tú que tienes mano con Brian, podrías echar un cable  ;D ;D


EDIT: confirmado que se debe al motivo que explico, y confirmado que mi script dispondrá de una killer feature: seguimiento en tiempo real de bully  8) ouyeah!
« Última modificación: 24-11-2013, 23:22 (Domingo) por peluzza »

bdpurcell

  • Visitante
Re: BULLY: Mejoras, bugs, aclaraciones, etc.
« Respuesta #149 en: 25-11-2013, 12:02 (Lunes) »
Pues indagando algo por ahí, he encontrado el motivo, y una posible solución.

El motivo es que las aplicaciones desarrolladas con  C Standard IO Library (todo lo que tenga  #include <stdio.h>) tratan el buffer de salida en bloque, lo que se conoce como block-buffered.
Si el desarrollador no especifica cuando liberar buffer, el programa se lo guarda hasta fin de ejecución. Por lo visto es más eficiente que hacer aplicaciones unbuffered, es decir, con salida en tiempo real.

La solución pasa por utilizar expect unbuffer para forzar la ejecucion liberando el deadlock. http://linuxcommand.org/man_pages/unbuffer1.html

Para python por suerte existe una librería instalada por defecto en python, Pexpect, que tiene un método unbuffer para este tipo de tareas.
http://www.noah.org/wiki/Pexpect#Q%3a_Why_not_just_use_a_pipe_.28popen.28.29.29.3F


vk496 me temo que para mi es inviable matar cada poco, ya que voy a intentar rizar el rizo lanzando ataques múltiples simultaneos con bully, y necesito llevar un control férreo sobre los PID que ejecuto.

Alister, tú que tienes mano con Brian, podrías echar un cable  ;D ;D


EDIT: confirmado que se debe al motivo que explico, y confirmado que mi script dispondrá de una killer feature: seguimiento en tiempo real de bully  8) ouyeah!

No problem, I will fix this as soon as I have time. Give me a day or two, por favor.

I am curious if running multiple instances of bully will work!

B

peluzza

  • Visitante
Re: BULLY: Mejoras, bugs, aclaraciones, etc.
« Respuesta #150 en: 26-11-2013, 00:36 (Martes) »
Pues indagando algo por ahí, he encontrado el motivo, y una posible solución.

El motivo es que las aplicaciones desarrolladas con  C Standard IO Library (todo lo que tenga  #include <stdio.h>) tratan el buffer de salida en bloque, lo que se conoce como block-buffered.
Si el desarrollador no especifica cuando liberar buffer, el programa se lo guarda hasta fin de ejecución. Por lo visto es más eficiente que hacer aplicaciones unbuffered, es decir, con salida en tiempo real.

La solución pasa por utilizar expect unbuffer para forzar la ejecucion liberando el deadlock. http://linuxcommand.org/man_pages/unbuffer1.html

Para python por suerte existe una librería instalada por defecto en python, Pexpect, que tiene un método unbuffer para este tipo de tareas.
http://www.noah.org/wiki/Pexpect#Q%3a_Why_not_just_use_a_pipe_.28popen.28.29.29.3F


vk496 me temo que para mi es inviable matar cada poco, ya que voy a intentar rizar el rizo lanzando ataques múltiples simultaneos con bully, y necesito llevar un control férreo sobre los PID que ejecuto.

Alister, tú que tienes mano con Brian, podrías echar un cable  ;D ;D


EDIT: confirmado que se debe al motivo que explico, y confirmado que mi script dispondrá de una killer feature: seguimiento en tiempo real de bully  8) ouyeah!

No problem, I will fix this as soon as I have time. Give me a day or two, por favor.

I am curious if running multiple instances of bully will work!

B


Already fixed via pexpect in python, see comments on github issue ;)
Thanks so much! >:(

https://foro.seguridadwireless.net/aplicaciones-y-diccionarios-linux/(desarrollo)-wps-qi-(wps-python-suite)/
« Última modificación: 26-11-2013, 00:40 (Martes) por peluzza »

cenomeno1

  • Visitante
Re: BULLY: Mejoras, bugs, aclaraciones, etc.
« Respuesta #151 en: 02-12-2013, 12:24 (Lunes) »
por que mepone  ap bloqueada espere 60 segundos  pero no raciona como puedo evitarlo