Lo primero es añadir la DLL como recurso dentro del ejecutable. Segundo cargar el recurso en runtime en un buffer.

Ahora tienes dos formas de cargar dicha DLL en runtime:

La primera es escribir el buffer en disco con formato .DLL. Después cargas la DLL con LoadLibrary y listo. El problema es que guarda en disco, podrias Unlodear la lib al final de la ejecucción y borrarla de disco antes de que termine el programa.

La segunda es implementar tu mismo un loader que cargue la lib en runtime, así no escribes en disco. La ventaja de la primera es que el loader de Win$ ya te la carga. El loader tendrá que mapear la DLL en la memoria virtual del proceso y tener en cuenta ciertos parámetros de las cabeceras PE. Hay material de sobra acerca de esto.

Para llenar un buffer en runtime con el contenido del recurso mira esto: https://stackoverflow.com/questions/9240188/how-to-load-a-custom-binary-resource-in-a-vc-static-library-as-part-of-a-dll

Saludos!

¿Te refieres a la falta de actividad en el foro? La revista la veo más enfocada a incluir temas del estilo de los blogs de ciertos usuarios de este foro. Así todo el conocimiento aportado por los mismos quedaría retratado en una compilación individual. Además de incluir referencias (links) a la bibliografía utilizada (si la hay) y blogs de los participantes. De esta forma gente que tiene pequeños espacios web (blogs etc) pueda dar a conocer el mismo.

Creo que sería positivo para la comunidad y para los usuarios: para la comunidad porque recibiría mas audiencia/visitas y para los usuarios porque más gente empezaría a leer las entradas de sus blogs.

Los contenidos de cada sección serían a elección propia, solo habría que ponerse de acuerdo entre los usuarios para que cada uno escoja un tema.


 

Saludos!

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 !

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!

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.

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!

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:


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!

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!