arrow_back Is self-modifying code alive?

5 votes
Good afternoon, recently came across this topic. It is supposedly called as polymorphic code, but it is extremely difficult to find it under that name because of the OOP technique with the same name...
Well, all the articles about this technique are dated 2005 or even later, I could not find anything more recent, but it is still interesting to know what happened to such an interesting direction.

I wonder if this direction is still alive and dead or has it evolved into something more interesting? (In fact, the articles say that this technique is kind of dead because of windows, which is a little bit covered ability to execute code on the stack and poorly documented information about the functions that help execute code on the stack)

I am interested in this topic because I am interested in the topic of reversing and anti-reversing and, in theory, this is one of the directions of anti-reversing.

Since I know python, I can say that if we close our eyes to the fact that python is interpreted and many other things, we can say that the dead polymorphism descendant is also in it, which is implemented by the exec function that executes the code.

Well that's basically it, interesting to hear, information on this topic.

Link to two articles about what I mean:


Ternick but rather cite those very articles in your question. To better understand what exactly you want to ask about.
Yevgeny Shatunov Well, for example, the article on Habra, * KUSE *

3 Answers

Best answer
0 votes
self-modified code is much harder to understand and debug than the same functionality, but not self-modified code :).
Given the modern development and the terrible cheapness of hardware resources on the background of the high cost of human resources, died out as a redundancy.

In the early days of computers, I remember reading a description of a game in which some game functions were formed directly while the game was running.
I remember there was a big set of executable chunks in a file, from which a chain of execution was formed by copying into memory, at the beginning of which control was given by CALL, and at the end of which RET was obligatory.
periodically the chains were re-formed.
1 vote
It looks like this has now been replaced by machine learning and processing the data from the client's work with the software back into the system.
That is, games that adjust to your playthrough style or capabilities. Or, for example, DLSS 2.0 from NVidia, which allows you to increase the picture without any apparent loss of quality, if the developers train the algoroitm, etc.
That is, the behavior changes because of some external factors. The machine instructions themselves do not change. I think everything has evolved in this direction.


Stalker_RED I've already figured it out. I figured out how it should look like with correction for system bans. I had to use VirtualAlloc or VirtualProtect with ReadWriteExecute access type and I didn't notice any difference. In fact I didn't find anything "complicating the reverser's work", you can of course write a couple of tricks to detect cleverly made debuggers and check what's going on around the application and think, run your "hidden potential" or terminate the process. I have another question on this topic, but more on that later. Otherwise, you're right, he wrote a completely off-topic post :)
The question was about something else, changing program behavior depending on external factors - this is quite "normal" behavior. The author of the question is interested in the methods when you have an exe-sheet in the folder, but when you run it, it changes itself, and at runtime a DIFFERENT binary is running in memory, different from the one that is in the folder.
Once upon a time, such tricks were easy to pull off, and they made it difficult for all sorts of keygen writers to do their jobs. Nowadays, they don't make it much harder, and anti-viruses are fighting, and even the OS is against it.
2 votes
Explore Lisp