hi,

i've attached a little crackme. im not using code obfuscation, import wrapping or antidebugging stuff at all, but im pretty sure the exe isn't patchable.

any feedback is appreciated

thx


if it won't run because of missing dlls, please download mfc redistributables from http://www.microsoft.com/downloads/details.aspx?FamilyId=32BC1BEE-A3F9-4C13-9C99-220B62A191EE&displaylang=en

ok, second try

this time its a b s o l u t l y impossible to patch it (beware sarcasm)

well, it should be harder

ive changed the backend, opcode encryption isn't used anymore, so all opcodes are plain in the vmdata.

the checkfunc is the check export

the resultmessages are also plain in the vmdata

try to change the messages, or the try to patch the "algorithm" (make it accepting different numbers)

the sourcecode this time is:

sourcecode of testcon:

Well done Orp, things are getting hard! Maybe, it's really impossible to patch... Let's see

I gave it a very quick look, 0rp, because you said it's a VM.
But since I am ve-e-ery lazy, I would like to ask you a thing. I found your 'test' instruction block, and this is my question:

What's happen if I hook&log all the calls to that instruction, and then start 'flipping' every bad boy of it back re-executing it, until I get a good result?
:P

Orp: I patched the Good/Bad boy jump, is this a valid solution?
(If yes I'll explain how I did it.)

wow ZaiRoN, you are hardcore

i knew crcing only one dword of each input is bad idea, but i couldnt imagine it could be exploited like this

congratulations

and yes, i will fix this issue :]

and i would like to read your explanation

logging the vm is prolly the best way to see how it works. but be carefully with your hooks, since they will break some crcs and make it crash

what do you mean with "flipping every bad boy of it back re-executing it" ?

eheh, i discovered CRC the bad way, when the error reporting kindly requested to start ^^

then i re-traced manually and 'noted' them eheh

This time the problems arise when you have to change one or more bytes because the entire VM instructions are surrounded by a nasty anti-patch check. I don't describe the VM used in the crackme but I'll focus my attention over the instruction I want to patch, the good/bad boy conditional jump:
The idea is to patch the conditional jump at 415638 letting it to accept any serial, the new instruction would be:If you try to patch the instruction the crackme won't run anymore because an exception will occour. As I said before there are some anti-patch checks; the crackme uses the VM instructions in his anti-patch cheching routine and you can't patch the VM's instructions. So, what can I do? The first thing to do is to start looking at the code which lead me to the snippet above:
This is the last part of the VM instruction that preceed the check I showed you above. Obviously the snippet above is called many times (because an instruction is called many times ) and each time the loop (40D8E2/40D8ED) extracts the offset of the next instruction. The next instruction address is obtained adding the offset to the base address (which is 40CF60). Well, seems to be unpatchable or atleast very hard to patch but there's a little flow in it.

Maybe you can't patch a byte of a generic VM instruction but you can surely patch something else, I'm talking about the dwords from 41555F to 41557B. Firstly these bytes are not inside a VM instruction, they won't be executed; secondly they are not used in the code, I mean they are not used in the various anti-patch routines. So, I can change them a little. I don't need to change all the bytes, one dword is enough.

The idea is to create a new VM instruction, almost similar to the one I wanted to patch. The new instruction will have:
instead of:
In this way I always pass through the good boy. I'll add the new instruction's bytes starting from address 409704.
Now, let's see how can I do such a change. First of all, it's better to look at the last iteraction of the loop:
Ok, this is the normal situation. As I said before the new instruction is at 409704 so if I want to find the new value of [41555F] I have to go backward:
Crackme solved!

in case any1 is interested, i gave up

theres a very simple way to remove even the strongest crcing: simply redirect all used opcodes to new opcodes, that basically do the same, but use a backup for crcing

those new opcodes could do anything, like logging, or inversing conditions or stuff, and i dont have an idea how to prevent this

i could make life harder with using obfuscation, but security by obscurity doesnt solve the problem

ok mister

this is the last try. now its even more impossible than ever before.

whats different:
- each vm-step has its own opcode-code
- each opcode is encrypted
- to decrypt opcode i, you need opcode i-1, since nobody else knows the key
- to get the key of opcode i, opcode i-1 needs to crc the vm, the crcresult, together with some reminder value makes the decryption key

now please proof me that i've overseen something.
again.

p.

Well, I'm not sure what I was supposed to do here, but after patching check()'s first argument from 123h to 2ah(=42) I've got this:
---------------------------
mhmmhm
---------------------------
oh, youve keygenned me
---------------------------
OK
---------------------------

Is that all?

no, the challenge is to patch the checkfunc itself, and make it accepting all numbers

Don't know if this counts, but I made a little script which decrypts all encrypted code and fixes up the jumps between chunks. After that it's enough just to patch one conditional jump (at .40F95C).

hehe, yes, your little script counts

mh

looks like i need to make the codeflow less static

mhmhm