Hi
I have been reading a bit about selfmodifying code (I know how to code it), but I can't see what good selfmodifying code is ?
How can it be used to make a crack more difficult.

Under Win32 you would have to call the VirtualProtect API function at some point, and that will make it pretty obvious where you intend to do some modifying.

And yes if you wonder I'm a software programmer, the enemy if you will

Glx2k:

When you as a protectionist introduce one or several strategies, like sel-modif code, packing etc, you are increasing the time and effort necessary to crack your application and reducing the range of would-be crackers that have the expertise to attack and solve your protection. In other words, you are buying time. But, sooner or later, if a CPU can run your code, a reverse engineer will successfully crack it.

Self modifying code(SMC) provides a stretch of code that is not obvious in "dead listing" disassembly of the app, making the analysis of the program somewhat more complicated. If the SMC is copied or decoded into memory during limited intervals, it can be difficult to detect, isolate and modify its code during live tracing of the program.

As you rightly point, SMC has some weaknesses that make its implementation conspicuous to an experienced cracker and can be exploited to locate and neutralize it.

Yeah, if you were coding the SMC in C, you would have to use the Virtual Protect API... But this is not true in assembly. In ASM, coding simple self-modifying code is as easy as moving raw hex opcodes into the contents of a specified offset in your code section.

A *simple* example:

mov edi,offset smc2 ;address of code we want to replace
mov [edi],dword ptr 04E8C166h ;replace code
smc2: cmp ax,03330h
xor ebx,ebx
mov esi, offset serial
.
.

Here we replace a 4 byte instruction cmp ax,03330h with another 4 byte instruction shr al,04

I found hand coding more than a small number of SMC lines to be very tedious and difficult. Some commerical protectors / encryptors have "polymorphic engines" that generate SMC. An intriguing topic, IMO that I've always wanted to investigate further.

Anyway, you might want to check out the discussion on SMC in ASM that Kayaker and I had on the Mini Project Forum a while back.

http://www.woodmann.net/forum/showthread.php?s=&threadid=156&perpage=15&highlight=SMC&pagenumber=2

Cheers,
Clandestiny

glx2k,

get a program that use a polymorphic loop to decrypt its real code, and you will see the advantages of self-modifiyng code.

instruction patching and PIQ trick can be very annoying to reverse.

ancev

Hello ancev !

Polymorphic code and self-modifying code are two completely different things.

Polymorphic means that the code looks always different and it's really hard to guess what the code does, because there is very much junk code between the important instructions. But this code never get never modified in memory.

Self-modifying means that that the code gets modified in memory during runtime. This leads to prefetch problems on CPUs up to 486 and causes massive pipeline stalls on all CPUs from Pentium upwards. The first means that the code will run different on different CPUs and the second slows down the execution time, since the CPU needs to fill the prefetch queue again each time. This only applies if you're modifying code in the range of the prefetch queue. Of course you need write access to the code segment as some people already said.

dakiendx,

your vision of polymorphism is limited.

i found a url that show a virus using this technic, to illustrate. i know that there's antidebug tricks using this, used in several tools, since the DOS days.

http://www.avp.ch/avpve/file/d/darkpara.stm

the non-poly implementation where called 'running line' or something, dunno exactly.

ancev

ps: i have a good experience with poly engines

Hello ancev !

Yes, I know what the "running line" is. It was a method which executed an INT 01 after each command (via trap flag) to encrypt the last instruction and to decrypt the next instruction (or similar), to make code analysis nearly impossible, since only one instruction was present decrypted at a time. And you couldn't trace this code so easy with a debugger.

A polymorphic engine was used is viruses, to prevent anti-virus programs from detecting viruses simply by scanning for their signatures. It was used to write random decryptors, which produce different code every time, so there was no hardcoded signature. Better polymorphic engines could execute INT 01 and INT 03, but they did not use them for themselves, only for confusing debuggers.

The self-modifying code was maybe used when the polymorphic layer had decrypted the code, but this was an other layer, not polymorphic any more.

Great! The whole last three paragraphs I wrote are nearly the same on the page you link points to.

OK, then there was one virus in DOS days which used a polymorphic "running line". But DOS is nearly dead and I'm sure Windows wouldn't like it if some virus/protector is tracing through it's kernel code just for fun.

I don't think you are allowed to write directly to the memory of my process under NT. I tried something similar and got an access error.
Correct me if I'm wrong.

i think you must change your section's attributes to write if you want to write something to it