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

Hi orp,
Thanks for sharing with us (but im pretty sure the exe won't be patched by me)

Did you submitted it on crackmes ressources sites like crackmes.de ?

Regards.

yes i did

http://www.crackmes.de/users/mcmof/xm/

Hi Orp.

The crackme is patchable.
Don't know if you wanted to say "exe" or "dll"; it doesn't have sense to patch the exe because the protection routine is all inside xm.dll file.

In case you wanted to say "the dll isn't patchable":
I can patch xm.dll and let it to show the right congratulation message ("oooh, youve beaten me (die plz)". When you know the nature of the serial you can get the right message just changing a single byte inside the dll. Obviously, changing some more bytes you can register the crackme with any kind of serial.
If you wanted to say "the exe isn't patchable.":
the answer is yes it's patchable. You can change the exe's bytes paying attention to the checksum, which is inside the dll (which is patchable...).

So, in any case the crackme is patchable

The basic idea behind the crackme is really nice btw. It's not so easy to understand how and where the protection routine was hidden. The serial/name algorithm used by the crackme is pretty easy but I'm sure Orp used the most simplest one just to give out a proof of concept. The real protection is not the algorithm.
I won't say anything else because I don't know if someone else is working on the crackme but I encourage you to try it, it's really enjoyable!

hi ZaiRoN,

really nice job :>

i bet you simply grabbed the key for the not equal opcode and build a new one, with same key but inverse semantic

i need to fix this hole :]

ive appended the orig script and the compiled frontend code, in case you are interested

thxalot
p.

Yes, offset 0xCDF0 from 8D to 8C

I wrote a little text about the crackme, see the attachment.
I would like to see a software approach to the problem; I mean, is it hard to write a program (or to modify the dll) able to capture only the necessary instructions?

hi zairon,

your description is brilliant, i wonder how much time it took to figure out how this works.




the vm contains some opcodes, that must not be encrypted. those opcodes are namely the enter and exit opcodes (they cant be encrypted since the mem required for decryption isnt existing then). the loop above is a small crc check. it loops over those unencrypted opcodes. to continue at the correct next opcode, the 'hash' it gets like this from those unencrypted parts need to be ok, or it would crash.


so since you have completly destroyed my vm thingie, you are responsible for repairing it :>

i was thinking about adding more (a lot of) crcing stuff. that would prevent patching at all. it seems that runtime decryption isnt too usefull, so i should remove it completly and replace it with crcloops that are required to get from opcode a to opcode b

or do you have better ideas?

How much time? Well, not much. Once you recognize the same pattern in every decrypted code you are almost done

Don't know if it's really usefull to add more crcs or not, personally I think that an annoying protection is really hard to break. Just an example, your decryption routine could be written in many other ways; I mean, a simple "xor edx, eax" instruction is equal to:
following this idea you can change all the instructions inside your decryption routine mixing them all together. Writing some differents decryption routines would have increase the level of your protection routine a little bit. Just a thought...