Teniendo cuenta la buena acogida que tuvo el «reverse me» anterior entre el público asistente, les dejo mi última creación. Para que todo el mundo pueda hacerlo sin caer en la tentación de ver la respuesta, pedimos que no se publiquen las soluciones en los comentarios del blog. Los que tengan la solución antes del próximo jueves 2 de agosto me la pueden enviar a plusvic[at]yahoo[dot]com, después de ese día publicaremos todas las soluciones enviadas. Aclaro que es bastante fácil encontrar un fichero de licencia válido sin entender el algoritmo de verificación, el objetivo del «reverse me» es entender el algoritmo. Así que….

…come on baby crack my file,
come on baby crack my file,
try to set the key on…… file.

Hola!,

Ahora que alguien ya ha resuelto el reverseme! de Victor, enhorabuena a Tora y a Miguel : dice erg0t que eres una VM humana! ;-), aprovecho para postear mi solución, con código fuente incluido :-).

Lo primero era echar un vistazo al reverseme! de Victor y ver que perrerías nos había puesto, después de pasar su algoritmo a C, con un poquito de asm inline para ver el estado de la FPU 😉 , nos quedamos con algo como lo siguiente …

(más…)

El sábado me quedé con ganas de Hack it en la Euskal . Está mal que lo diga yo, pero formamos un dream team que arrasó con las pruebas finales en tiempo récord, y al final todos nos quedamos deseando que hubieran más pruebas por hacer. Así que mientras regresaba en el metro me puse a pensar en un algoritmo interesante para un «reverse me», y el resultado ha sido este.

Solo adelantaré que no es demasiado difícil, y que hay que desempolvar un poco las matemáticas elementales. ¿Alguna pregunta o comentario…?

Hola,
Pues nada siguiendo la estela de «iDefense acaba de publicar» xD , iDefense acaba de publicar un advisory del año de la pana. El fallo lo descubrí en febrero de 2006 así que os hacéis una idea. La movida esta en las funciones del DirectX Direct3D que se usan para mapear una textura en memoria.

Uno de los formatos soportados era el TGA, pero DirectX cometía un fallo gordo a la hora de copiar el tga mapeado a un buffer que era dinámicamente reservado usando campos en la header del tga. Es decir, esos campos los puedes modificar a tu gusto. Entonces tenemos un buffer en la heap cuyo tamaño es calculado usando : (Width*Height)*bpp. Por otro lado DirectX mantenía una estructura interna donde el tamaño del fichero era obtenido de la función GetFileSize. A la hora de copiar el fichero mapeado hacia el buffer, usaba el resultado obtenido de GetFileSize por lo que el overflow está claro. Todo el rollo técnico y el código lo podéis leer en el advisory.

Esta vulnerabilidad se probó que era remótamente explotable, incluso con una intervención mínima del usuario, pero ya ves por misterios de la vida Microsoft decidió no publicar un boletin de seguridad y hasta donde yo se, arreglarla silenciosamente. Cosas de Microsoft…

Bueno, aquí podéis descargar el advisory.

Un saludo.

iDefense acaba de publicar una vulnerabilidad en el driver symTDI de los productos de seguridad de Symantec que les mandé hace tiempo. Y por supuesto, despues de una mierda de semana con mal tiempo, tenia que ser justo hoy que hace buen tiempo y me quería ir a la playa cuanto antes. Y eso es lo que pienso hacer, asi que vamos al grano.

La vulnerabilidad es una simple escalada local de privilegios debido a la validación incorrecta del userBuffer de un IRP en el envio del IOCTL 0x83022323 al device \\symTDI\. Me ha quedado bonita la frase 🙂 . Lo mas negativo es que este tipo de vulnerabilidades ya se les habían colado con anterioridad a los desarrolladores de Symantec, como en las que descubrió Ruben en los drivers «navex15.sys» y «naveng.sys».

Por último os dejo el advisory y el exploit. El exploit es un Poc que utiliza una dirección de memoria hardcodeada y que tras algunos parches de microsoft ya no es valida. Creo que debería ser cuestion minutos volver a hacerlo funcional…

Y ahora a la playa 🙂