
The tale of how the Autoplay Media Studio 8.5.3.0 kettle broke

As it’s not hard to guess, the teapot is me.
The other day I wanted to look into the source of one utility, obviously made using AMS (a .cdd file next to .exe and a couple of lua * .dll). A couple of years ago I analyzed in detail one program made by similar means and the idea of packing .cdd, which is a regular zip archive with a password, is available. Well, without hesitation, I pushed AMSUnpacker and received an unpacking error. Well, from this moment the most interesting thing began ...
The first thought that occurred to me was that the file was packed with something other than UPX (which I naturally unpacked). Well, I just didn’t check it (DIE, Exeinfo PE, Nauz File Detector) and everyone convinces me that no, it’s not packed. Well, I think I will compare the banal .exe using Total Commander with the previously unpacked program and this one, and it turned out that .exe is very different (previously I compared other programs on AMS and the difference was only in single bytes, in fact, in a password written in plain text just in .exe itself and in the resource part). It became clear that this is either some kind of modified and just a new version of AMS. I believed with the last difficulty, knowing (well, I thought at first that I knew) that the developers had beaten the program for a long time, but did not begin to check it whether it was this or not, and it would hardly have given anything.
I started to delve into more details, somehow in x64dbg, with which I on “You”, found in the old version of the program a place where the password is “read”. Rummaging the same x64dbg in the “new” version, it turned out that they are not so different, but there are simply more functions in it than in the old one. I found a similar place where instead of the coveted push <address where the password is stored> there was some mov <something there> and several calls to some other functions, and a few lines below the code is similar to the one in the old version.

(on the left - the old version, on the right - the new one)
And then I was depressed, because my debugger knowledge is clearly not enough to figure it all out.
There was one thought - to find some other similar unpackable program and compare their .exe. Such a program was found by the same author as the one I tried to unpack. And file comparison gave its result. In addition to minor differences, a whole block of various data was found:

And the joy that I found that unique place where the password apparently was contained, and the disappointment that this was clearly not a password, in the form as it was in previous versions.
There was no choice but to understand the debugger. The whole “trouble” is that I know the assembler at the level of several commands, with a very superficial representation of what they are doing, and the debugger itself is at the level of several videos watched on youtube and with little experience in using it, mainly by the “poke method”.
After an hour of running the debugger and countless restarts, I somehow found a place where the coveted bytes are read and a little later I found a piece of code that does some manipulation of these bytes:

It took a long time to understand what was being done there.
Somehow I figured out that this is some kind of cipherpad, where there are two tables, one is an encrypted password, where the corresponding character simply indicates the position in the second notepad.

In general, replacing the values of the lower table with the corresponding values from the upper table, we get an array of bytes: 7B 10 DD 5A 4D 26 72 EE B2 2A 04 2B 6E F7 14 E2 F9 14 F8 9E 8A 99 28 AE B8 4B C0 D7 42 DA AD .
For what other unique arrays of bytes, before and after I needed to decrypt the password, I did not understand, but I did not really delve into it either. I suspect that there are some checksums ...
And then it's up to you to convert it to a string and unpack the cherished .cdd archive with this password. A small problem was that the resulting line could not be inserted into the archiver via Ctrl + C -> Ctrl-V, because characters "break" in the clipboard (especially did not delve into the essence). Unpacking is only possible programmatically. Fortunately, there is some knowledge of C # (the level of which in general does not differ much from the level of knowledge of the debugger) and little experience in studying the principle of operation of the previously mentioned AMSUnpacker, which is also written in C # and it’s not difficult to see what it is doing there.
Almost on the knee he piled up a utility to check the operability of the previously studied algorithm, and voila, it works.
You can download it here .

The program, similar to the previously mentioned AMSUnpacker, creates the extracted_cdd folder next to the .exe with the contents of the .cdd archive.
After successfully unpacking the coveted .cdd file, I learned that this is the “new” version (from the end of 2018) AMS 8.5.3.0. And on the site they read about the new version: Feature: Enhanced the security of the commercial version's data file. . Well, apparently it didn’t work out very well ...
I have a question for those who know, such an algorithm for hiding a password, is it part of some standard encryption algorithm (I mean it is now applicable in programs, and not historically), or is it, most likely, the developers thought of it?
PS I know that it is easiest to get the source code for lua programs (which uses AMS) through the patched lua * .dll that surf the Internet and / or the external hook of the lua_load () function in the same lua * .dll. This is all I once did. In this situation, it was a purely sports interest to figure out how to get a password for .cdd. And I also understand perfectly well that it is unlikely that anyone will need it and does not bear any practical value.
I probably exaggerated regarding the "teapot", because there is little experience in programming and reverse, but this is just a small hobby "for myself" and there is not much time or desire to delve deeply into this.
PPS This is my first article on Habré, as, probably, generally the first of this type.