For all Olly and coding GUru's

[MaRKuS-DJM]

i also believe the contest is just a "mask" in front of a protector. they want to get tricks to stop Olly.

btw dyn!o... did you make this undetectable Olly yourself? i also modified my Olly, but it is detectable through some methods.

All right with everyone in a word dyn!o - any contest - only commercial sh*t secret behind RE.

[dyn!o]

Yes, I modified it while encountering some poor detections based on well known OllyDbg vulnerabilities (as I remember you can find these exploits even on ExeTools) or even so funny "tricks" like OllyDbg executable and/or window name. By "undetectable" I mean the actual methods used by protectors. Theoretically and practically it is still detectable but it seems no developer (protector developer) seriously tries to deal with it, luckily for us.

They just understimate Olly... people (devs) would be surprised seeing how much can be done under ring3... also that was the reason of my first post in this thread (I supposed some developer noticed the possibilities of ring3 and tools like OllyDbg).

[MaRKuS-DJM]

hm... what about Process32First (used by some protectors, but also disallows other pograms to start it), ZwQueryInformationProcess (Used by new VBox HASP SL), and the method used by SDProtector (didn't analyse what it uses)?

all i do is writing tutorials, but not taking part in such contests which helps developing protectors. same as Code-Lock with their "special rulez" you have to explain them more or less how you cracked it (this thread about code-lock was created by you dyn!o )

[dyn!o]

"and the method used by SDProtector "
As I remember SDProtector used ZwQueryInformationProcess, DebugActiveProcess or RDTSC... Ehh, a little mess in my head... all these protectors are almost the same... I cannot remember which one but I vote for ZwQueryInformationProcess. Any problem? I do not think so (not for you) - just go and write small plugin or macro. If you will encounter RDTSC (but I feel it has been used in other protection) the same here - sounds terrible but it is terribly easy (macro or plugin - just check the actual instruction and skip it/them in case of RDTSC).

"Lock with their "special rulez" you have to explain them more or less how you cracked it (this thread about code-lock was created by you dyn!o )"
I remember that pretty well. I asked them if it is not assymetric cryptography key "trick" and to let me get in. They refused.

Good luck.

[MaRKuS-DJM]

it was more than half a year i looked at SDProtector. i didn't look at it again, but going to do so again most things i did through kernel-patching, not in olly itself. i did that because some tools got detected by anti-crack mechanisms and so (through kernel-patch) i fixed it for the whole system. next service pack will kick all the patches

that's the trick about the contests:
you should do what is requested but not like YOU want, you should do how THEY want

[dyn!o]

"it was more than half a year i looked at SDProtector. i didn't look at it again"
similar here.

"most things i did through kernel-patching"
wow, a hardcore. But the problem comes again with each OS update, as you noticed.

"most things i did through kernel-patching"
sure you can but try to patch RDTSC using this way .

"you should do what is requested but not like YOU want, you should do how THEY want"
damn right.

All in all I suggest you to consider taking the advantage of OllyDbg possibilities (macro/plugin) - it is really powerful.

Good luck and regards.

[MaRKuS-DJM]

kernel-patches are system wide and so more comfortable because they take effect to every cracking-software too

"sure you can but try to patch RDTSC using this way"
hehe, that must be really hardcore to do that. there was a reference in CBJ how to pass this but without kernel-patching