Ams Plugin Maker - Trial to full patch
Hello fam. As i recived a storm of people asking about internals of APM and very courious about how its generating plugins with assambler i got some time by beigh sick with heavy fly and decided to bring some light on the matter, I wanted with this educate on tweaking your apps without the need of patching binaries or injecting code. This ended up on create this patch that includes all the sources, like always
First of all, APM trial, as found on the original website is a trial build. It doesn't contain the logic of "when you buy it" so theres no byte replacement magic patch possibility. It will generate plugins with a code that will only work on the pc that builds it as its saving the code in a local file on a temp path. The plugin will only have a reference of the path to this code.
To be less invasive possible i choosed to replace flac.exe (4789708.dat) and polink.exe (8685379.dat) with some executables i generated with c# .net2 command line apps. Those executables will show a MessageBox useful to debug files if build fails.
The objective of this files is to edit sources, then call the original executable, having at this point compiler events for compiling and linking stage of build.
APM is using assambler templates from a zip (9240294.dat pw: 004327892802480769698585903882293893984064072385782079435320) to build a object file with the plugin definitions with flat.exe (Flat assambler) and also extracting from the main executable some other precompiled objects that contain all the real logic of plugin (action.o for actions object.o, objecti.o and object.p for objects) then a makefile is generated to link those objects alongside with other needed objects with polink.exe, geneting the plugin.
I choosed to edit the ASM file before it is compiled by flac, and add a call to a custom generated library (roachlib.obj) that directly loads the code and redefine variables with the real content found on the file that contain the logic. For cleaning propourses, i set the values of sizes to 0 for default APM calls and renamed real sizes so i could still access them on the custom code, but core sees 0, so it wont load bullshit to lua engine.
Then, on the linker event MakeFile.make is edited to include a reference of custom library generated to load lua code and a patched object (action.o/object.o) is replaced that has changed a byte to not show the alert, executing the code anyways (thats why i set sizes to 0 before)
This will produce a final plugin with code inside and loading it on time.
Also a brief on (((encryption))) of these codes, its using a shitty xor swapping agains some random bytes called XMLX for some dumb reason. As i suspect, plugins generated with full version shoud be same as produced with this patch, so content and key to decrypt are just right after the other. Extracting and editing those codes inside the dll will be so easy, as its no real encryption. Also the tool "lua buffer dumper" ive posted should ejaculate all the code as its using loadbuffer, like all the AMS coding events.
AMS PLUGIN MAKER 184.108.40.206 [[TRIAL TO FULL]] v1.1 Patch by @Pabloko
- Go to Data path (usually is C:\Program Files (x86)\AmsPluginMaker\Data)
and rename "Resource" folder to "Resource_original"
- Unzip "Resource" path from this archive
- Compile your previously locally tested plugins as usual. :)
- Extra: You can restore those folders as you want to avoid
debugging limitations on development stage.
Known limitations / bugs:
- Transitions are not yet implemented
- Code block limit is 1Mb (can be incremented)
- Debugging won't work for plugin loading. APC won't displays
- A nasty fopen call still happening at loading. Its left there
due architecture of path, keeping at minimum possible the core