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

alist3r · « **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 · « **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.

Cita de: alister en 03-09-2013, 14:39 (Martes)

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 · « **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 · « **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 · « **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...

geminis_demon · « **Respuesta #145 en:** 24-11-2013, 19:22 (Domingo) »

Cita de: peluzza 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...

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.

peluzza · « **Respuesta #146 en:** 24-11-2013, 21:05 (Domingo) »

Cita de: geminis_demon en 24-11-2013, 19:22 (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 · « **Respuesta #147 en:** 24-11-2013, 22:31 (Domingo) »

Cita de: peluzza en 24-11-2013, 21:05 (Domingo)

Cita de: geminis_demon en 24-11-2013, 19:22 (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 · « **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

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

ouyeah!

bdpurcell · « **Respuesta #149 en:** 25-11-2013, 12:02 (Lunes) »

Cita de: peluzza 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

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 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 · « **Respuesta #150 en:** 26-11-2013, 00:36 (Martes) »

Cita de: bdpurcell en 25-11-2013, 12:02 (Lunes)

Cita de: peluzza 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

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 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)/

cenomeno1 · « **Respuesta #151 en:** 02-12-2013, 12:24 (Lunes) »

por que mepone ap bloqueada espere 60 segundos pero no raciona como puedo evitarlo

Noticias:

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

alist3r

Re: BULLY para tontos | BULLY for dummies

alist3r

Re: BULLY: Mejoras, bugs, aclaraciones, etc.

eskasi

Re: BULLY: Mejoras, bugs, aclaraciones, etc.

eskasi

Re: BULLY: Mejoras, bugs, aclaraciones, etc.

peluzza

Re: BULLY: Mejoras, bugs, aclaraciones, etc.

geminis_demon

Re: BULLY: Mejoras, bugs, aclaraciones, etc.

peluzza

Re: BULLY: Mejoras, bugs, aclaraciones, etc.

vk496

Re: Re: Re: BULLY: Mejoras, bugs, aclaraciones, etc.

peluzza

Re: BULLY: Mejoras, bugs, aclaraciones, etc.

bdpurcell

Re: BULLY: Mejoras, bugs, aclaraciones, etc.

peluzza

Re: BULLY: Mejoras, bugs, aclaraciones, etc.

cenomeno1

Re: BULLY: Mejoras, bugs, aclaraciones, etc.