Mensajes

[Make elhacker great again.]

Hola compañeros ya es tiempo sin escribir ni nada, pero siempre os leo en las sombras 

No sé si se habrá preguntado antes pero estoy aquí para proponer la idea de lanzar una revista ¿mensual? donde usuarios del foro compartan sus conocimientos en distintas secciones.

La revista se organizaría en secciones, el contenido de las mismas tendrá que hacer referencia al título de los subforos de este foro. Así quedaría una sección para Seguridad, Bugs/Exploits, Análisis de Malware, Programación (todos los lenguajes), Win/Linux, Crypto etc

Los usuarios no tendrían porque ser parte del staff, aquellos usuarios que no formen parte podrían aplicar para escribir un artículo. Se acordarían unas pautas de redacción y presentación como: fuente y tamaño, márgenes y demás.

No me enrollo más porque no se si gustará, tengo más ideas para este proyecto pero primero he de saber si la gente será capaz de aportar.

Make elhacker great again.

Saludos !

kub0x, felicitaciones! eres el ganador de Abril Negro 2017!

Gracias WHK y a todos los que habeís apoyado mi proyecto, seguiré mejorándolo esta temporada. Un gran saludo a los demás participantes que también habeís hecho posible la realización de este evento, ha estado bien reanimarlo y se esperan mas ediciones.

Saludos!

Las dos, y luego de que pruebes esos abortos, usa debian.

Ubuntu vale, pero explícate por que Fedora es un aborto. Qué le ves tan malo a la que es posiblemente la top #2 distro de escritorio después de Arch.

- El buffer siempre debería ser multiplo de 64, de hecho mucho mejor si es múltiplo exacto del tamaño de 1 sector de disco.
- También puedes lograr mejor velocidad de escritura, si desactivas la caché. Dado que solo es 1 única escritura y no lectura, si puedes desactivar (o hay alguna función específica en el lenguaje), que deshabilita la caché del S.O. no pierde tiempo en ello. A veces el S.O. (en win2 al menos), se empeña en hacer uso de la caché, aún cuando tú solo vayas a leer o escribir una única vez (por ejemplo porque vas a hashear uno o varios ficheros).

Antes de nada yo hago uso de dos buffers, bueno realmente visible es 1, es decir, el buffer principal que varía su tamaño (si hay subsecuencia desde i hasta j, i incrementa recordemos), todo esto recalculando para no hacer overflow cada vez que finaliza una subsecuencia. Con longitud fija pues chupado. Y luego tenemos el buffer del descriptor del fichero el cual es múltiplo de 64KB o 64 KB depende del OS. La primera opción la he tenido en cuenta a la hora de lidiar con el buffer del descriptor de fichero. En C++ no había forma más que heredando y haciendo mi propia implementación así que use la interfaz de I/O de C.

Así que cuando el buffer principal ha llegado a casi el límite se guarda en chunks de 64 al fichero. Aquí entra en juego el punto número 2, pues también probe que el descriptor no usara buffer, es decir, escribe al file lo más pronto posible, con setbuf es posible desactivar el buffer del stream. ¿Es esto a lo que te refieres con quitarnos la cache de en medio (creo que no)? Tampoco noté mucha mejoría. Otra idea con sentido que tuve fue apuntar el stream del fd al buffer principal y hacer un flush (escribir al device y limpiar), pero sigo sin saber porque eso no funciona, si tan loca la idea no es y usaría solo un buffer, pero bueno parece que solo las primitivas estilo fputs o fwrite funcionan.

Y sobre la tercera, bueno de las primeras cosas que hice antes de meterme a la progamación son los cálculos matemáticos (como queda retratado en el paper) del storage con hashing y de words, por lo tanto tengo acceso al tamaño en bytes del fichero destino, claro que para secuencias grandes será descomunal, en esto si que no había caído y gracias por la recomendación sin duda lo probaré.

Un saludo!

[@NEBIRE:]

Antes de nada, acabo de publicar la v1.0.4 y pufff cada día me supero a mi mismo  Podemos decir que SPOK gana a maskprocessor en performance. He portado la lógica de buffering y write a C teniendo MUY en cuenta los tamaños de buffer para escritura en disco y caché de CPU.

He eliminado el multi-threading para I/O en fichero ya que eligiendo sabiamente el tamaño de buffer es innecesario, oye no te irás a la cama sin aprender nada nuevo. Al parecer con un tamaño de entre 4KB - 2MB approx. existe un balance entre overhead en syscalls aprovechando cache y bloques de página del disco duro. A parte por cada sub secuencia completa re-calculo el tamaño de buffer, todo al milímetro.

[kub0x@prism maskprocessor-0.73]$ time ./mp64.bin ?l?l?l?l?l?l -o 1.txt

real   0m5.614s
user   0m2.333s
sys   0m2.153s

[kub0x@prism Release]$ time ./spok -g 1.txt -i 6,6
Using default charset.
Total storage needed: 2062.24 MB
All words of length 6,6 have been generated.

real   0m5.470s
user   0m3.351s
sys   0m1.612s

[kub0x@prism Release]$ time ./spok -g 1.txt -c 0123456789ABCDEF -i 8,8
Total storage needed: 36864 MB
All words of length 8,8 have been generated.

real   2m03.121s
user   1m0.428s
sys   0m33.678s

Vamos que ni multi buffer ni gaitas. Escritura síncrona con tamaño de buffer estrictamente basado en hardware

__________________________________________________________________________________________________

@NEBIRE: Buenos benchmarks, supongo que será el tiempo que tarda el algoritmo en generar sin printear, ya que I/O en stdin/out es costoso, ni maskprocessor lo handlea bien (tarda mucho mas que escribir en disco).
Me he animado a hacer el benchmark con tu ejemplo de charset A-Z y length fija de 7:

[kub0x@prism Release]$ time ./spok -g 1.txt -i 7,7
Using default charset.
Total storage needed: 61277.8 MB
All words of length 7,7 have been generated.

real   0m20.817s
user   0m20.764s
sys   0m0.010s

Ojo sin printear ni logear en disco, sólo ver cuanto tarda el método en generar todas las secuencias (unos 401.10^6 / sec). También hay que tener en cuenta la CPU que utilizo. He añadido la opción de printear sin logear en disco, basta con quitar el parametro -g o --generate del input, todo esto siguiendo tu consejo.

Por cierto me ha gustado tu enfoque sobre:

Una particularidad muy interesante en todas estas implementaciónes del algoritmo2, es que cada carácter obtiene su propio alfabeto (de forma indirecta, tal como se explica a continuación)... aunque por defecto uno ponga A-Z, en realidad hay tres parámetros:
Valor minimo, ejemplo: AAAAAA
Valor Máximo, ejemplo: ZZZZZZ
Valor Inicial, ejemplo: GDAXCA

Esto permite que pueda indicar el valor mínimo y máximo de formas distintas, por ejemplo así:
Posiciones:      543210
------------------------------
Valor Minimo:  A0ZD9A
Valor Máximo: ZZAK0Z
Entonces, implica que, tiene definido un alfabeto (en estos casos siempre basado en el ASCII)
El carácter '0': A-Z  ---> 26 caracteres, incremento
El carácter '1': 9-0  ---> 10 caracteres (numéricos), decremento
El carácter '2': D-K ---> 13 caracteres incremento
El carácter '3': Z-A ---> 26 caracteres decremento
El carácter '4': 0-Z ---> 43 caracteres 0-9, 9-A, A-Z (10+7+26 si no he contado mal)
El carácter '5': A-Z ---> 26 caracteres.

Tengo pensado implementar cositas así tras optimizar todo, siempre me acuesto diciendo ya está optimizado pero cada vez saco algo  Estaría bien que me sugirierás alguna característica más, he pensado en máscaras o combinaciones de múltiples diccionarios. Para ello hay que pensar que contraseñas elige la gente. Me molaría probar tus algoritmos también, sobre todo el algoritmo 3, ya que repito que el mio tiene pinta de algoritmo 2.

He establecido un nuevo record, el modo verbose está claro que interfiere en los cálculos por minuto así que quitándolo se ve mucha mejoría.

Palabras de longitud 8 con charset hexadecimal:

time ./spok -g 1.txt -i 8,8 -c 0123456789ABCDEF

real   2m12.130s
user   1m29.713s
sys   1m0.373s

Es decir 1.950.337.075 palabras por minuto escritas al .txt usando solo un buffer, para que no se solapen al pasar al thread y no haya una reserva de memoria significante. Ganando a maskprocessor por un par de segundos en este contexto. Que decir que el paper ya ha quedado obsoleto en términos de diseño, programación y benchmark.

Como bien dices, dejaré la opción de guardar diccionarios opcional así con la de printear y un pipelina ya puedes hacer cosillas. Para particionar diccionarios se puede especificar una palabra de comienzo o cargar la sesión anterior.

EDIT: Liberada versión v1.0.3

Ejemplo de multibuffer:

real   2m8.108s
user   1m31.130s
sys   0m59.931s

Palabras por minuto: 2.011.568.658. He añadido un comando nuevo para especificar si el usuario quiere usar multi buffer o no. En los SSD tiene sentido usarlo ya que si se usa mono buffer tendrá que esperar a que la copia este vacia. Notese que el buffer principal siempre estará siendo llenado independientemente de si se necesita escribir en disco o no.

También he mejorado el verbose posicionándolo en el apartado de escritura de buffer, para no abusar las calls y ya por fin muestra los resultados reales de palabras por minuto 2.10^9, interesante sin duda. Optimizaciones varias (cambio de crono, ahorro de verificación parametro hash por cada ciclo etc..) y limpieza de código.

Saludos

Soy de Bilbao y esto es sin duda una agresión política ya que mete el tema de siempre, el de que somos etarras. Estamos ya cansados de esto, y sí, a mas de uno ya le ponía yo una bomba 

De los andaluces tengo muy buena impresión, y de Andalucia también ya que he visitado ciudades por allí y me gusta su estilo, esto no hace más que dar peor imagen a los Bilbotarras de los andaluces, no debería ser así pero muchos aquí tienen la impresión de que el andaluz es como dice el estereotipo. Y que decir de este tio, ojalá un dia vea tu esquela por ahí chaval.

Saludos!

Y sí, es sin escribir claves a disco. Ya he mencionado, que es estéril guardar un diccionario a disco, el tiempo necesario para ello es gigantesco comparado con el cálculo, además del espacio gigante que requieren. Cuando se precisa usar un diccionario, y más tarde se interrumpe, basta guardar la secuencia actual (última usada) y luego es relativamente fácil volver a ese punto y continuar. Esto hace inútil tener que requerir un diccionario en disco (un diccionario gigantesco, tampoco pasa nada por tener alguno de unos pocos cientos de Mb.)

Así es, en la herramienta SPOK puedes guardar el estado donde dejaste la ejecucción resumiendo la composición del diccionario desde la última palabra generada. Esto se hace después de introducir el buffer al fichero, se coge la última palabra del buffer (la de mayor longitud). Para no repetir subsecuencias (cuando i < j) idee una comprobación para la señalización.

Estoy contigo, hay que crear particionados de los diccionarios o crear una regla de composición que no sea muy masiva. ¿Tu programa printea las secuencias solamente entonces por pantalla?

El tema es que logear words en SPOK no es muy costoso debido al multi thread para que la copia del buffer pasada por referencia se escriba en el file mientras se siguen permutando los caracteres. El algoritmo de permutaciones si quito la parte de logear pues es ultra rápido, quizá edite este post para poner esta parte, ahora ando liado :/.

Saludos!

Hola NEBIRE gracias por tu tiempo y compartir las tres opciones.

En mi proyecto utilizo la el 2º ya que parto de una cadena donde los caracteres son iguales (primer caracter del charset) y luego permuto el último hasta que llega al caracter final del charset, así reinicio el último y permuto el anterior. Obviamente infinitamente mejor que la primera.

Sin embargo me ha llamado el interés la opción 3 que comentas. Hace tiempo estuve pensando en ella, pero la descarte por la facilidad con la que visualizaba en 2ndo. ¿Básicamente se trata de concatenar dos keyspace iguales para hacer su doble?
Y sobre todo el benchmark 1.6*10^9 por min esta genial para un equipo de ese año, pero en tal caso, ¿las claves estaban siendo escritas al disco? Dudo que sea tan rapido con un disco que es una tartana. Mi mejor benchmark son 1.2*10^9 por min con más de 10GB de escritura por minuto en un SSD semi decente con un i5 ya viejuno.

Para acabar, mi tool es capaz de guardar secuencias de longitud inferior es decir si le pongo 3,7 a partir de la secuencia de 7 genero el resto. Así no tengo que hacer las de 3, luego 4 (como se verá en el 2ndo benchmark). El alg de subsecuencias esta ultra optimizado, vamos que respeta una fórmula matematica iterativa para no gastar en ciclos. Anteriormente en la v.1.0.1 me daba igual que ciclara siempre pero porque tenía otras cosas en mente.

Ayer compartí contigo unos tiempos de ejecucción de la herramienta maskprocess VS mi herramienta SPOK. Bueno después del port a C y muchas otras optimizaciones, lo vuelvo a repetir:

Palabras de longitud 6 con charset [a-z]:

Spok:

real   0m6.884s
user   0m5.101s
sys   0m2.226s

maskprocessor:

real   0m6.478s
user   0m2.224s
sys   0m2.010s

Ahora viene lo bueno, maskprocessor también genera secuencias basadas en intervalos de length, es decir secuencias desde 4 hasta 7. Pero SPOK le gana pues con las de 7 hace el resto de sub secuencias:

time ./mp64.bin -i 4:6 ?l?l?l?l?l?l -o 1.txt

real   0m9.672s
user   0m2.324s
sys   0m2.183s

time ./spok -g 1.txt -i 4,6

real   0m7.019s
user   0m5.245s
sys   0m2.603s

Con secuencias de length 8 y usando charset hexadecimal (36GB):

time ./mp64.bin --custom-charset1=0123456789ABCDEF ?1?1?1?1?1?1?1?1 -o 1.txt

real   2m13.783s
user   0m37.507s
sys   0m41.316s

time ./spok -g 1.txt -i 8,8 -c 0123456789ABCDEF

real   2m10.155s
user   1m24.198s
sys   0m40.658s

Vamos que SPOK ha resultado ser tan bueno como maskprocessor, herramienta del team de HashCat en CPU. Estoy contento de que la tool esté preparada para competir.

Si quieres pasáme un code en C o C++ te lo compilo bajo Linux y vemos que tal corre escribiendo en mi disco. Ahora mismo en Windows me sería imposible :/ Sigo teniendo curiosidad por si el benchmark que hiciste lo hiciste logeando en disco o solo haciendo bruteforce.

Saludos!

Con un Proxy para hacer MITM en SSL/TLS necesitas un certificado firmado por una entidad de confianza, supongamos que NSA y similares lo tienen podrían realizar este sistema de espionaje pero...

Hay varias técnicas para evitar esto como puede ser Certificate pinning, Convergence (observatorio de certificados) y Certificate Transparency (repo de certs). Vamos que al que se la cuelan es por que quiere

Saludos!