Anti-dumping techniques

Question

After handing on some crackmes using packed codes, I am now curious about anti-dumping techniques. For the crackmes I have encoutered, my method is as follows: after the program unpacks itself, I take a memory snapshot (using IDA), then analysis the unpacked code (this approach has been proposed also by Igor in the answer of this question).

Since these crackmes are not sophisticated enough, this method works. But I am quite sure that there are more sophisticated techniques can bypass this method. The most detail document I can find is this article, however the discussed techiques are all about inserting (e.g. Nanomites) special codes into original ones or changing them completely (e.g. VMProtect, Code Virtualizer); or some other tricks to fool debuggers/disassemblers.

So my question is: are there existing techniques that prevent us from understanding the program by taking memory snapshot, while they do not change the original codes?

NB1. I have found a very close question and answer here

Modern protectors do not unpack/decrypt the code completely. Decryption is done as and when necessary. Sometimes a code block is re-encrypted after execution. Thus you never reach a point where the entire code has been decrypted and memory snapshots/dumping aren't effective. — 0xec, Sep 26 '15 at 05:44
Thanks a lot @ExtremeCoders, I know about "dynamic obfuscation" using just-in-time code generation and an implementation by Tigress. But this kind of self-modifying code may not "cruel" enough. Are there some "underground techniques" and real world samples? — Ta Thanh Dinh, Sep 26 '15 at 08:35
I hear only about the approach of Armadillo but I have not try it. — Ta Thanh Dinh, Sep 26 '15 at 08:54
Thanks a lot @JasonGeffner, consuming the articles in your links is not easy. I will start with them. — Ta Thanh Dinh, Sep 26 '15 at 18:09

Anti-dumping techniques

0 Answers0