C/C++ Encrypt/Decrypt Functions & Memory At Runtime

Posts 16–30 of 39 · Page 2 of 3

Originally Posted by WasserEsser

The main problem persists, the signature is easily scannable ( without ANY problems at all ) if the file is just loaded from disk into memory.

Welp, that's why I included the spoiler in the thread. This can be useful for other purposes tho, and that's why I also posted it on C/C++ programming forum.
Never reversed VAC my self so couldn't really know. And this wasn't even purposely written to circumvent VAC or any other anti-cheats. Just fun experimenting

Originally Posted by nullptr_t

More efficient compared to using only the same key.

It makes more sense now, that may be in some appearances efficient(yes, just some appearences, because there are some obvious disadvantages), but not compared to the actual polymorphism.

edit:

Just fun experimenting

Try to apply and show your idea of generating new keys for each encrypting of functions, and so save every key in a queue of keys, after you do your work, decrypt.
Finally, compare it with an actual polymorphism.

Then show here the results of your work

(if you want).

Originally Posted by WasserEsser

I've gone ahead and downloaded your tool and used SigBench against it.
It's a tool which compares two files by getting signatures out of the first file and testing them against the second file.

Since polymorphism is done at runtime, i've started your tool and dumped the live memory twice ( restarted the executable inbetween, even though it should change each time a function / semantic is getting executed ).

As you can see in the screenshot, these two files are 0 % different, meaning they are the exact same. Your tool is not polymorphic.

Well, I tried the code (now with random key)

Code:

void XorBlock(DWORD dwStartAddress, DWORD dwSize, DWORD dwKey)
{
	__asm
	{
		push eax
		push ecx
		mov ecx, dwStartAddress          // Move Start Address to ECX
		add ecx, dwSize                  // Add the size of the function to ECX
		mov eax, dwStartAddress          // Copy the Start Address to EAX
		mov ebx, dwKey                   // <---- LOAD dwKey into EBX

		crypt_loop :                         // Start of the loop
		xor byte ptr ds : [eax], bl     // XOR The current byte with 0x4D
			inc eax                         // Increment EAX with dwStartAddress++
			cmp eax, ecx                     // Check if every byte is XORed
			jl crypt_loop;                      // Else jump back to the start label

		pop ecx // pop ECX from stack
			pop eax // pop EAX from stack
	}
}

Created two memory dumps out of the program with processhacker (restarted in between dumps),
tried both with 16 & 64 sig size and got this:

- - - Updated - - -

Originally Posted by javalover

It makes more sense now, that may be in some appearances efficient(yes, just some appearences, because there are some obvious disadvantages), but not compared to the actual polymorphism.

edit:

Try to apply and show your idea of generating new keys for each encrypting of functions, and so save every key in a queue of keys, after you do your work, decrypt.
Finally, compare it with an actual polymorphism.

Then show here the results of your work

(if you want).

Done

/2short

Originally Posted by nullptr_t

Well, I tried the code (now with random key)

Code:

void XorBlock(DWORD dwStartAddress, DWORD dwSize, DWORD dwKey)
{
	__asm
	{
		push eax
		push ecx
		mov ecx, dwStartAddress          // Move Start Address to ECX
		add ecx, dwSize                  // Add the size of the function to ECX
		mov eax, dwStartAddress          // Copy the Start Address to EAX
		mov ebx, dwKey                   // <---- LOAD dwKey into EBX

		crypt_loop :                         // Start of the loop
		xor byte ptr ds : [eax], bl     // XOR The current byte with 0x4D
			inc eax                         // Increment EAX with dwStartAddress++
			cmp eax, ecx                     // Check if every byte is XORed
			jl crypt_loop;                      // Else jump back to the start label

		pop ecx // pop ECX from stack
			pop eax // pop EAX from stack
	}
}

Created two memory dumps out of the program with processhacker (restarted in between dumps),
tried both with 16 & 64 sig size and got this:

- - - Updated - - -

Done

/2short

I was refering to telilingan.

Your approach is still not polymorphic and really naive. As you can see, your two dumps are exactly the same except for very very few signatures that differ. Signature scanners have a million places to choose to grab a signature and still detect your binary. 1 % is basically nothing.

Originally Posted by nullptr_t

Done

/2short

You did not. I've also suggested you to compare your idea against actual polymorphic code.

Originally Posted by nullptr_t

I just noticed that you're passing a key via the parameters. That one is in no way more effective than your previous method, since its still somewhat static. You can just grab the key from the stack / opcodes ( if hardcoded ).

xor'ing the bytes is in general not effective.

Originally Posted by WasserEsser

I made Ad hoc polymorphism.
I used sigbench a week ago to make sure my Kimcil have differences each other. But, i don't know how to calculate my polymorphism.
btw, how to calculate the polymorphism using sigbench ? I just drop the same files, right ? or Do you have any process to calculate it ?
because i never calculate my polymorphism hahaha

Originally Posted by telilingan

Are you sure you know what polymorphic code is?
Your binaries aren't polymorphic at all.
Not even one single byte is different.

Ad hoc polymorphism is still no polymorphic code and i don't know why it even has the term polymorphism since it has nothing to do with it.

Originally Posted by WasserEsser

Ad hoc polymorphism is still no polymorphic code and i don't know why it even has the term polymorphism since it has nothing to do with it.

In context of oop programming, polymorphism is a different concept. But since we are not talking of oop, we could call it polymorphism, if we want.
If we want to be more pedantic, we would call it polymorphic code with the purpose of not doing confusions.