Tale of how the maker Autoplay Media Studio 8.5.3.0 broke

As it is not difficult to guess, the kettle is me.



I wanted one of these days to look at the source of one utility, obviously made by means of AMS (.cdd file next to .exe and a pair of lua * .dll). A couple of years ago I made out in detail one program made with similar means and the idea of ​​packing .cdd, which is a regular zip archive with a password, is available. Well, I did not hesitate in AMSUnpacker stuffed and got an unpacking error. Well, from this moment began the most interesting ...

')

The first thought that came to mind that the file is packed with something other than UPX (which I naturally unpacked). Well, what I just did not check (DIE, Exeinfo PE, Nauz File Detector) and all convince me that no, not packed. Well, I think, I’ll compare the trite .exe means of Total Commander of the previously unpacked program and this one, and it turned out that the .exe is very different (previously it compared other programs on AMS and the difference was only in single bytes, in fact, in the password written in clear text just the .exe and resource part). It became clear that this is either a modified and just a new version of AMS. In the last I believed with difficulty, knowing (well, I thought so at first that I knew) that the developers had long been beaten up for the program, but didn’t check it out or not, and it’s unlikely that it would give anything.



I began to delve into more detail, somehow in x64dbg, with which I am on “You,” found in the old version of the program a place where the password is “read”. Having rummaged through the same x64dbg in the “new” version, it turned out that they are not that different, and there are more functions in it than in the old one. I found a similar place where instead of the cherished push <the address where the password is stored> there was some kind of mov <something there> and several calls of some other functions, and a few lines below the code is similar to that in the old version.





(on the left - the old version, on the right - the new)



And here I am depressed, because my knowledge of the debugger is clearly not enough to figure it all out.

One thought appeared - to find some other similar unpackable program and compare them with .exe. Such a program was found by the same author as the one I was trying to unpack. And the file comparison gave its result. In addition to minor differences, there was a whole block of different data:







And the joy that I found that unique place where apparently the password was contained, and the disappointment that this is clearly not a password, as it was in previous versions.



There was nothing left to understand the debugger. The whole “trouble” is that I know the assembler at the level of several commands, with a very superficial idea of ​​what they are doing, and the debugger itself is at the level of several watched videos on youtube and a little experience of its use, mainly “at random”.



After a bad hour of running the debugger and an incalculable number of restarts, I somehow found a place where the cherished bytes are read and a little later I found a piece of code that does some sort of manipulation with these bytes:







It took a lot of time to understand what was going on there.



Somehow I figured out that this is some kind of cipherblock, where there are two tables, one is an encrypted password, where the corresponding symbol indicates just the position in the second notebook.







In general, replacing the lower table values ​​with the corresponding values ​​from the upper table, we obtain 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 byte arrays, I did not understand before and after the decryption required for the password, but didn’t really get into it either. I suspect that there are some checksums ...



And then it’s already a matter of small things; convert it into a string and unpack the coveted .cdd archive with this password. A minor problem was that the resulting line could not be inserted into the archiver via Ctrl + C -> Ctrl-V, since characters "break" in the clipboard (especially the essence did not penetrate). You can unpack only in software. Fortunately, there is some knowledge of C # (the level of which in general is not much different from the level of knowledge of the debugger) and little experience in learning how the previously mentioned AMSUnpacker works, which is also written in C # and see what it does and how it works.



Practically on my knee I used the utility to test the performance of the previously studied algorithm, and voila, it works.



You can download it here .







The program, similar to the previously mentioned AMSUnpacker, creates an extracted_cdd folder next to the .exe with the contents of the .cdd archive.



After successful unpacking of the cherished .cdd file, I learned that this is a “new” version (from the end of 2018) AMS 8.5.3.0. And on the site they read about the new version: Feature: Enhanced. . Well, as you can see, it did not work out very well ...



I have a question for the knowledgeable, 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 the way that the developers most likely conceived it?



PS I know that the easiest way to get the source of the programs on lua (which uses AMS) is through patched lua * .dll, which walk on the Internet and / or external hook of the function lua_load () in the same lua * .dll. This is all I once did. In this situation, it was a purely sporting interest to figure out how to get the password for .cdd. And I also understand perfectly well that it is unlikely that anyone will need it and does not bear any particular practical value.



I probably exaggerated regarding the "kettle", because little programming and reverse experience is available, but this is just a small hobby “for oneself” and there is not much time or desire to delve deeply into it.



PPS This is my first article on Habré, as well as, probably, the first of this type.