Announcements: AMS decompiler to be released very soon, more

Aquí podrás hablar de cualquier tema que no tenga un sección específica.
Hello specialists!

This thread is an announcement of several things that will come soon to this forums:

First, i've just made the first autoplay decompiler script. This means that any autoplay app can be fully reverted back to autoplay project or obtain any kind of info from the source.

You may think that i've already did that with project dumper tool, but this works in totally different way, parsing the _proj.dat file structure statically, instead loading the code and injecting dumping api stubs dynamically.

As this is going to be a bit long post, ill write more about this in the next lines...

The other announcement, is that from next year we're renewing the forums, and id like to get some feedback from community in what you would do to make this better place. I'll reserve my own ideas now because id like to hear from people without biasing, but i can advance, we're going to have an online tool for all kinds of AMS manipulation (cdd password extraction, sfx extraction, _proj.dat reverser etc...) and probably a copy of the messages of this forums will be saved for historical propourses, but many thousands of dead links and useless walls of text will have to be archived in order to keep sanity and cleanlyness.

So for the 10th anniversary of AMSSpecialist were moving forward, releasing the definitive autoplay dumping tool, and starting new horizons... with our forums, and development.

The next milestone for amsspecialist is to start an open source clone of autoplay media studio. Id also gladly hear feedback on this, since theres a lot possibilities like solving old known problems but breaking compatibility with original ams. So it will be an interesting project for the community and to rebuild this community around better project. But that will come after were done with ams, ofcourse.

So, lets talk about AMS decompiler in full lenght:

It all started while i was looking at a tool called "kaitai struct", i wanted to learn using it, and real learning comes with practice, so i remembered the only data structure that ive never been able to unpack and given i have some knoweledge of it, would be an easy pick to practice with... the autoplay's _proj.dat.

In this post, ill try to describe details of the process and interesting stuff from this undocumented file.

To begin, id need to easily get _proj.dat files with small modifications quickly to be able of compare differences. usually, you generate an executable, get its password, then dump the _proj.dat from .cdd file, this was unaceptable for this proporuse, so ive prepared a msimg.dll hook that just writes the _proj.dat file contents to a file on the harddisk without any other protection.



Then, ive noticed the saving routine of AutoPlayDesign.exe is very similar to dump the _proj.dat and to save the .autoplay project, so it be more or less safe to assume most of the variables would appear in the same order on both files. This speed up the process by magnitudes as then only the type is unknown, and most of them are usually 4 byte integers.

To be clear, im working with ams 8.5.x.x demo and professional and now im in the process of reversing diffs with older executable versions, this is why tool is not out yet, since now i have a path of downstream changes until ams 6.0.0.0 wich is the last version im up to support but i still have to look at 5... also only cdd extraction is done yet to 8.5.x.x, so now im on the process of documenting older versions... maybe even some could help with that! dont heystate to offer your help...

The _proj.dat file is the product of MFC class serialization, via CArchive class using CSerializable and CObList derived objects, and also some few ATL data structures like maps and vectors, which are predeccesors of now popular std c++ extensions. All of this makes this task a bit harder since this libs are closed src from microsoft, but its simplicity of operation can help to reverse its format without looking so deep.

From a static analisys of the autoplay's executable, proj.dat seems to be readed in blocks, depending if there are some bytes in it at specific relative position. So we're not reading a serialized object, but a bunch of them. MFC serialization seems to require a short value (2 byte) indicating the class type to parse, and loading it for a first time using an optional string. This is true for the most part of the file, but many initial sections lack of this since the type is described on the runtime code.

Many values are unknown since they probably are autogenerated fill values, but may also contain data, so further reversing should be done on unknown values.

Order of the PE:
-Startup code, a blob containing _error_messages.lua + _notification_messages.lua + database init code
-AMS runtime ID: a series of values that identify the compiling ams runtime version, product and unix timestamp of compilation
-Window style: the global preferences, width, height, titlebar etc...
-Window options, style, auto bg music, transparent window, intro video... a bunch of properties with all the project settings.
-Globals code
-Clicksound and other defaults, like startup page
-Action plugin list
-menu bar
-Global coding events (On startup, on shutdown....)
-cjstyles: custom styles (probably only in ams 8)
-Pages (containing a subarray of data, events and objects)
-Dialogs (very similar to pages)

And thats it! obviosly it gets more complicated while going deep into objects, as they all share some strcuture but they have a custom property struct for each type of object.

Imagen

Here's a graphviz visualization where you can understand the magnitude of the task of decompiling this file, given that for it to correctly work there must be 0 (zero) errors on the data or the reversing process will fail miserably, and its must be described in full

This work has been done in 2 days, one of them being wasted in the default data of the tree object, that was interestingly hard to reverse.

Imagen

Sample decompiled to json: https://pastebin.com/E0fbAstE
and sample autoplay project: https://pastebin.com/HRzPWiR8

Imagen

How to test a decompilation of 8.5.x.x proj.dat, go to ide.kaitai.io and paste my decompiler script, drop your _proj.dat file to the ide and you will get it either totally parsed or catastophic error will happen. im interested into the problematic ones. My aim is to fully test the format then release a converter to ams project or apz. As i have the installer for older versions, ill need to get some time to go back installing them and dumping the cdd breaking + pe changes for all of them, then will be the time to revert back to project.

un excelente trabajo con https://ide.kaitai.io/.

Referente a los cambios en le foro estoy total mente de acuerdo en que se realicen los cambios en estructura y actualizar todos o en su mayoria los ejemplos compartidos para poder limpiar el foro de tanto material muerto.

con respecto al proyecto de código abierto se lee interesante y se podrían desarrollar nuevas utilidades en el ide para mayor robustez de las que carece ams.

con tu proyecto de decompilación sera un boom poder decompilar proyectos antiguos y nuevos sin dificultad todo con fines educativos y ver códigos de otros para conocer su trabajo.
you know one more than the devil :yeah-1417757020:
very interesting new........

I join agotaras for changes in the forum
I have some work on a Open Source version of AMS, runtime and IDE.

For the moment, theres a split decision to make, keep compatibility with plugins, lua lang, etc... or go to more modern implementation that would support multiplatform.

Id go for the second as ive already have written a nice Javascript engine using ChakraCore, wich have a JIT and debugger, compilable under any arch and shipped on windows thru JSRT api, its not outperforms v8 but its very near, compared to the small footprint size of chakra agains v8 that is +20mb. You may think im triying to clone nodejs, but in fact, nodejs has a core issue that this project would solve, the callback hell, our core would return promises instead being feeded with callbacks, wich let the user execute sync or async the code, that would run on a thread executor. This would bring absolute power of computing while multithreading. Already have this core working with complete FFI bidings

Then the UI would also have to be cross platform, i have in mind some code i have from professional projects where we could bring hw-accelerated painting and controls via skia/opengl, much like qt or javafx does. for this id bring some nice renderer like artist and subclass the core components of AMS and creating a few interesting new ones... id not bring com controls from windows but they can be done on plugins i guess...
Imagen

I've been experimenting on using libdom/libcss from netsurf web browser as window compositor/translator but probably ill code all of that using virtual dom in the own scripting, giving a lot of flexibility to core customization.

ill carefully plan this project on the coming months and start a public repo by next year
me gusta mas la idea de ir a una complementación más moderna que admita multiplataforma ya que de esa manera nos adentramos a las actualizaciones tecnológicas y nuestros proyectos no están atados a una única plataforma.
More announcements!!!

By popular demand, the new all-in-one static decompiler will support action and object plugins created with reteset's ActionPluginCompiler.

Ive discussed before this format, but i can show a peek on how this will be done on javascript in any browser. APC modules, in contrast with AMS, uses an assembly compiler and linker to generate the binary file. So... how a struct packer can defeat this? easy:

Kaitai comes with a handy "microsoft_pe" already made ksy script that we can use to get two key sections of the executable, ".code" where the first functions corresponds to methods generated in assembly, and ".data" section, wich contain the data associated to these methods, in this case, properties, source code and decrypt key.

Imagen

So, now having those section addresses and relative addresses, we can use Capstone.js, a wasm port of a very handy multipropourse dissambler.

Imagen

So now its just calculate the relative virtual offset from data table to address marked as RVA to obtain all the data.

For example, the method associated with the action plugin name, that would be on ordinal 14, dissambled tells me to look on RVA 0x1001C009, wich can be translated in the file offset 0x18E09 relative to .data section, wich just point to a null terminated string containing plugin name

Imagen

This is ofcourse valid for any plugin and object generated with APC and would generate a .apmproj from apo or lmd file and the code would be decrypted from the easy xor cipher that APC has with that fixed 36 chars key :celeryman-1418247558:
esto cada vez se esta poniendo mucho mejor el uso de Kaitai es muy amplio por lo que veo.
Agotaras123 escribió:
20 Oct 2021 04:51
esto cada vez se esta poniendo mucho mejor el uso de Kaitai es muy amplio por lo que veo.
Some demo of APC decompiling:



The kaitai parser for this is quite simple and decoding script even more. This is how code is decoded:

Código: Seleccionar todo

for(i=0;i<dec.code.length;i++)
	dec.code[i] = dec.code[i] ^ dec.key[i % dec.key.length]
pablo the brazilians have declared war on you :lol: :cabreado: :hypno:
usamakey escribió:
21 Oct 2021 07:55
pablo the brazilians have declared war on you :lol: :cabreado: :hypno:
the man vs the monkey hahahahah
Ya es hora que te folles a una garota
Pabloko escribió:
19 Oct 2021 21:37
I have some work on a Open Source version of AMS, runtime and IDE.

For the moment, theres a split decision to make, keep compatibility with plugins, lua lang, etc... or go to more modern implementation that would support multiplatform.

Id go for the second as ive already have written a nice Javascript engine using ChakraCore, wich have a JIT and debugger, compilable under any arch and shipped on windows thru JSRT api, its not outperforms v8 but its very near, compared to the small footprint size of chakra agains v8 that is +20mb. You may think im triying to clone nodejs, but in fact, nodejs has a core issue that this project would solve, the callback hell, our core would return promises instead being feeded with callbacks, wich let the user execute sync or async the code, that would run on a thread executor. This would bring absolute power of computing while multithreading. Already have this core working with complete FFI bidings

Then the UI would also have to be cross platform, i have in mind some code i have from professional projects where we could bring hw-accelerated painting and controls via skia/opengl, much like qt or javafx does. for this id bring some nice renderer like artist and subclass the core components of AMS and creating a few interesting new ones... id not bring com controls from windows but they can be done on plugins i guess...
Imagen

I've been experimenting on using libdom/libcss from netsurf web browser as window compositor/translator but probably ill code all of that using virtual dom in the own scripting, giving a lot of flexibility to core customization.

ill carefully plan this project on the coming months and start a public repo by next year
You have a great talent for challenges and trying to do the best :lol:
Necesitamos hacer una limpieza profunda del foro, hay demasiados hilos con enlaces muertos y pensaría también en un rediseño.

Sobre el clon de AMS, wow tremendo trabajo te has montado ya, me parece excelente tu decisión de no usar Node, opino lo mismo, el callback hell es horrible y me fascina que vayas directo a usar promesas. Ahora hablando del tema de la interfaz gráfica, creo que usar algo como Qt sería lo mejor, es multiplataforma y así podríamos implementar algo orientado a componentes al estilo React, Jetpack Compose o SwiftUI. Sí vamos a crear algo más moderno, es importante adoptar los patrones populares, MVVM, Flux/Redux. Con gusto me hago un port de redux a lua.
Quedo en nada todo lo relacionado a esta publicacion