Página 1 de 1

AutoPlay Media Studio | LA PEOR SEGURIDAD JAMAS VISTA

Publicado: 16 Sep 2016 06:46
por Dow Sher
Don’t cling to AMS. If you’re a noob, use it as a stepping stone to learn a real programming language. All the effort the few paranoid people undertake could very well go into learning how to use other great IDEs like Visual Basic, Lazarus or Visual C. This also ends the whole source stealing debate. Anyway, I’m not holding my breath for the next big security innovation of AMS 9. After 8 major version releases and 15 years in the market, Indigorose’s attempts at securing their software still equal those of early 90’s indie-games companies. They clearly showcased that they don’t employ any talents in the security department, so don’t keep your hopes up.
https://xiaopang333.wordpress.com/2012/ ... ia-studio/

Y aquí la prueba de todos los intentos fallidos por asegurar AMS

Re: AutoPlay Media Studio | LA PEOR SEGURIDAD JAMAS VISTA

Publicado: 18 Sep 2016 11:33
por Pabloko
Son articulos interesantes sobre temas que ya conocemos de sobra.

En realidad el modelo de autoplay es muy sencillo, y hackeable con distintos metodos facilmente. Algo de lo que no hay apenas nada escrito es sobre el _proj.dat. Este archivo contiene una clase derivada de CObList serializada en binario, esto es, un objeto contenedor que contiene arrays de objetos y que toman las propiedades de las clases c++ que lo forman. Para que me entendais mejor, un objeto con sus propiedades y eventos se escriben en posiciones determinadas, con lo que lugo al cargar este archivo en memoria y castearlo como el tipo de objeto definido se obtendra una clase con las propiedades del mismo.

En realidad la tarea de pasar de _proj.dat a un proyecto xml usable en autoplay es batante sencillo pero requiere un tiempo de desarrollo que no merece la pena (hay que recolectar las tablas de posiciones de todos los objetos, crear accesores para los plugins etc... controlar paginas y dialogos, y controlar un sinfin de propiedades internas de autoplay.)

Como he escrito en otras ocasiones, el principal punto fuerte de autoplay, que es el scripting lua, es tambien su punto debil. Lua es extremadamente flexible y facil pero no esta diseñado para ofrecer mucha seguridad de ejecucion de codigo, de hecho con cualquier vm de lua es posible inyectar bytecode x86 (muy malo maloso). Aparte de esto, el diseño de lua hace extremadamente facil la ingenieria inversa, por ejemplo, al registrar funciones nativas en lua, se hace en una tabla donde se referencia el puntero despues del string con el nombre, obviamente sera mas facil trabajar en el si sabes el naming de cada metodo.

De hecho, si tuviera que hacer un decompilador, mi intento seria mas bien por el lado de lua:

-Inyectar un modulo en la aplicacion objetico con el metodo CreateRemoteThread
-Obtener el puntero de la funcion loadbuffer de lua5.1.dll una vez se carge
-Crear un objeto CIRPluginObject y funciones lua para obtener el listado de eventos de cualquier objeto.
-Dejar que se ejecute loadbuffer 2 veces (global action code, on startup code) enviando a loadlibrary codigo en blanco, se podria usar la segunda ejecucion (on startup) para inyectar el codigo de dumping
-Listar todas las paginas con Application.GetPages, obtener sus scripts con Ap...GetPageScript y dejarlos en blanco con SetPageScript (idem con los dialogos)
-Navegar por todas las paginas (y dialogs), y obtener un listado de objetos con Page.ListObjects, en caso de ser un object plugin, utilizar el cirpluginobject dummy para obtener el string de configuracion, en caso de plugin del ams, llamar a su funcion GetPropiets, el cual contiene la info hasta con el mismo naming del xml.
-Salir de la aplicacion, se ejecutara un ultimo loadbuffer con el codigo on shutdown, robar tambien y guardar el xml (o am8 para que lo reconozca autoplay como proyecto)

De esta forma se podria convertir un app de autoplay en proyecto ams de forma mucho mas simple que tener que hacer mucho reversing