DnGuard Enterprise v3.34 Unpackme

[bball0002]

This is a crackme that Kurapica made. I just used it as a DnGuard example. This is the latest version of DnGuard HVM Enterprise, and all options were used when creating this unpackme.


Link: ~removed~

Updated crackme link: ~removed~

Requirements:

Restore the methods in the exe

*Get exe running (if possible)


__________________________________________________ __________________________
Post any updates on this protector here.

[kao]

Either you did not know how to use the protector or full version is not much better than trial.


private void Undefined23(object sender, EventArgs e)
{
bool flag = Operators.CompareString(TextBox1.Text.Trim(), "JFMVNJFURHGMCVNCHDU", false) == 0;
if (flag)
Interaction.MsgBox("Well done", MsgBoxStyle.Information, null);
else
Interaction.MsgBox("Try again !!", MsgBoxStyle.Critical, null);
}

I have recovered methods but assembly is not runnable yet. Will continue the research tomorrow.

[bball0002]

Good job. Can you explain how you recovered the methods? I hooked the JIT but only obtained the ZYXDNGuarder methods.

edit: lol.. should have looked at this protector a little more... devs were way too lazy. They do a nice job of protecting the IL code in MEMORY, but fail to encrypt the code in the actual exe. It is only moved to another place in the file. Nothing to see here. This protector isn't good at all.


I guess I shouldn't assume that a dev team would be stupid enough to go to great lengths to keep the IL code hidden in memory, but leave the actual code in the application still... I didn't even think to check that before.

[kao]

@bball0002: Yeah, IL code is there. Method headers, exception information, managed resources and #US stream must be fixed though..

Enterprise version is supposed to have HVM technology and does not enforce "High performance encryption method" (btw, that's a nice name for xor operation :D ).

Could you please try:
* use strong name key and resign protected assembly;
* uncheck "High performance encryption method";
* enable HVM and max those settings;
* use Declarative Obfuscation and Declarative Protection;

If assembly with such settings is equally simple to unpack, I'm declaring DNGuard a total crap. :)

Thanks again,
kao.

[bball0002]

lol... sadly HVM was enabled >_<, level 5...so I'm already declaring this protector crap, and everything else besides "name obfuscation mode on "destroy name heaps of metadata"" was checked.

I don't think strong name matters much at all in this case, but I do have a question for you. How did you recover all of the methods? And is the IL code placed in order or is it scrambled?

[Kurapica]

Never expected this one to be that easy !! or maybe kao was more than a guru :D

nice thread.

[bigmouse]

I have worked with an app protected by Professional v2.92.
it's more hard than this crackme.

seems to the ILCode was stored 'as is' in the last section of crackme.exe, just like the trial does.
but as i know, the professinal edtion does really encrypt the ilcode .

Either you did not know how to use the protector or there was a big bug in Enterprise edition.

@bball0002: did you checked "High performance encryption method".

Could you please try:
* uncheck "High performance encryption method";
* enable HVM and max those settings;

[bball0002]

@bigmouse: yeah sure, I will tell my friend to do that when he gets back on. I'll post in a bit.

[kao]

I do have a question for you. How did you recover all of the methods? And is the IL code placed in order or is it scrambled?
I made a static unpacker, it's not that hard. This log file has 90% of information you need. The remaining 10% (how to recover LocalVarSigTok and how to decrypt #US) you'll need to research by yourself, those procedures are not even virtualized. :)


Processing file CrackME.exe
DnGuard table at offset 2D078, version=6, expected checksum=58200AAA
[i] Encrypted method count: 0x0000003E, encrypted method table RVA: 0x00030960
[i] Method0001
original RVA=00030235 new RVA=00000000
probably a useless .cctor, ignored
[i] Method0002
original RVA=00030222 new RVA=00030244
FAT method RVA=00030244 ILCodeSize=20 datastart=30250
[i] Method0003
original RVA=00030222 new RVA=00030284
FAT method RVA=00030284 ILCodeSize=56 datastart=30290
Fixed LocalVarSigTok = 11000001
[i] Method0004
original RVA=00030222 new RVA=000302FA
Tiny method RVA=000302FA ILCodeSize=14 datastart=302FB
... skipped ...
[i] Method003E
original RVA=00030222 new RVA=00002E44
FAT method RVA=00002E44 ILCodeSize=B datastart=2E50
Fixed LocalVarSigTok = 11000021
[i] Managed Resource: 00000000 00000001 000010F8 00000000
Calculated size=000000B4
[i] Managed Resource: 000000B8 00000001 00001114 00000000
Calculated size=00027A7C
[i] Managed Resource: 00000000 00000001 000011F5 00000000
Resource RVA is incorrect, ignoring
[i] Managed Resource: 00FFFFFF 00000001 00001204 00000004
Resource RVA is incorrect, ignoring
Finished!


@bigmouse: yeah sure, I will tell my friend to do that when he gets back on. I'll post in a bit.
Could you please make that new unpackme, I'm curious how hard is to recover encrypted IL.. :)

Cheers,
kao.

[bball0002]

Here you go: ~removed~



Enabled all options except unchecked "High Performance Encryption Method" , and enabled HVM (again) and maxed the settings.


Updated first post.


Edit: yes, methods, bodies and headers, seem to be gone in this one. I knew it couldn't be that bad, lol.

[bball0002]

Had to take links down. My buddy got an email from DnGuard, guess their watermarking is good, lol.

[kao]

I noticed the watermarks while playing with the unpackme, but never expected that DNGuard would take any action. On the other hand, they are quite active in sending DMCA notices to Google as well. :D

@bball0002: Drop me a PM, please. Last time I checked, your inbox was full.

[bball0002]

PM sent. Maybe you can help with that other problem I was having too, lol.

[Kurapica]

I'm not skilled in native code like kao, but digging in olly can give much info about the mechanism.

I also noticed that the HVM DLL runs some code even before the initial call to "getJit" API.

still digging. :)

[bigmouse]

Hi all,
who can pm me the link of the new unpackeme?

[Kurapica]

check ur pm plz.

[kao]

DNGuard is using nice tricks to make our reversing tools crash. Here is a list why CFF Explorer crashes:
1) MethodPtr table is present. CFF Explorer does not support it;
2) Fields with invalid name (index into string heap = 0xFFFF). CFF Explorer does not perform boundary check;
3) Methods with invalid name (index into string heap = 0xFFFF). CFF Explorer does not perform boundary check;

Hopefully someday Daniel Pistelli will fix his tool. :) In the meantime, here is a hack-ish patch for latest CFF Explorer (version=7.8.6.4, size=2781184 bytes, MD5=9E9650DC165DF4793BB8F1AF67B8A1CA):

00000150: 53 F6
00000151: F3 C9
00000220: 7C 00
00000221: EC EE
0000023C: 40 60
0000023F: 40 60
0003B860: 8C 9E
0003B861: DA 78
0003B862: 01 1B
0003BC30: BC CE
0003BC31: D6 74
0003BC32: 01 1B
0003C45D: 8F A1
0003C45E: CE 6C
0003C45F: 01 1B
0019F3D0: 00 A4
0019F3D1: 00 3C
0019F3D2: 00 5F
0019F3D4: 00 90
0019F3D5: 00 3C
0019F3D6: 00 5F
001F2890: 00 4D
001F2892: 00 65
001F2894: 00 74
001F2896: 00 68
001F2898: 00 6F
001F289A: 00 64
001F289C: 00 50
001F289E: 00 74
001F28A0: 00 72
001F28A4: 00 06
001F28A8: 00 98
001F28A9: 00 FE
001F28AA: 00 59
001F28AC: 00 4D
001F28C0: 00 55
001F28C1: 00 8B
001F28C2: 00 EC
001F28C3: 00 83
001F28C4: 00 EC
001F28C5: 00 08
001F28C6: 00 89
001F28C7: 00 4D
001F28C8: 00 F8
001F28C9: 00 68
001F28CA: 00 8C
001F28CB: 00 A7
001F28CC: 00 5A
001F28CE: 00 68
001F28CF: 00 18
001F28D0: 00 C9
001F28D1: 00 5A
001F28D3: 00 8D
001F28D4: 00 45
001F28D5: 00 FC
001F28D6: 00 50
001F28D7: 00 8B
001F28D8: 00 4D
001F28D9: 00 F8
001F28DA: 00 E8
001F28DB: 00 D1
001F28DC: 00 26
001F28DD: 00 E7
001F28DE: 00 FF
001F28DF: 00 50
001F28E0: 00 8B
001F28E1: 00 4D
001F28E2: 00 F8
001F28E3: 00 E8
001F28E4: 00 88
001F28E5: 00 C3
001F28E6: 00 E6
001F28E7: 00 FF
001F28E8: 00 85
001F28E9: 00 C0
001F28EA: 00 74
001F28EB: 00 03
001F28EC: 00 8B
001F28ED: 00 45
001F28EE: 00 FC
001F28EF: 00 89
001F28F0: 00 EC
001F28F1: 00 5D
001F28F2: 00 C3
001F28F3: 00 90
001F28F4: 00 90
001F28F5: 00 90
001F28F6: 00 90
001F28F7: 00 90
001F28F8: 00 90
001F28F9: 00 90
001F28FA: 00 90
001F28FB: 00 90
001F28FC: 00 90
001F28FD: 00 90
001F28FE: 00 90
001F28FF: 00 90
001F2900: 00 90
001F2901: 00 90
001F2902: 00 FF
001F2903: 00 74
001F2904: 00 24
001F2905: 00 0C
001F2906: 00 FF
001F2907: 00 74
001F2908: 00 24
001F2909: 00 0C
001F290A: 00 FF
001F290B: 00 74
001F290C: 00 24
001F290D: 00 0C
001F290E: 00 E8
001F290F: 00 DD
001F2910: 00 61
001F2911: 00 E6
001F2912: 00 FF
001F2913: 00 8B
001F2914: 00 44
001F2915: 00 24
001F2916: 00 08
001F2917: 00 8B
001F2919: 00 50
001F291A: 00 51
001F291B: 00 8B
001F291C: 00 85
001F291D: 00 E8
001F291E: 00 DA
001F291F: 00 FF
001F2920: 00 FF
001F2921: 00 8B
001F2922: 00 88
001F2923: 00 70
001F2924: 00 01
001F2927: 00 E8
001F2928: 00 94
001F2929: 00 FF
001F292A: 00 FF
001F292B: 00 FF
001F292C: 00 59
001F292D: 00 2B
001F292E: 00 04
001F292F: 00 24
001F2930: 00 73
001F2931: 00 0A
001F2932: 00 8B
001F2933: 00 44
001F2934: 00 24
001F2935: 00 0C
001F2936: 00 C7
001F293C: 00 83
001F293D: 00 C4
001F293E: 00 04
001F293F: 00 B8
001F2940: 00 01
001F2944: 00 C2
001F2945: 00 0C


P.S. Even in full version, IL code is still present in executable, it's just encrypted (XOR or 16-round TEA or 32-round TEA). Full static unpacker is done. :rolleyes:

[bball0002]

Very nice. Thanks for the info

[bigmouse]

@kao
good job, and do you looked into jit hook.
i hooked jit, found the passed ilcode contains some invalid values.
for Professional v2.92, can get correct ilcode from jit hook.

[kao]

the passed ilcode contains some invalid values.

In 3.34 Pro version JIT is called twice for every method. First time invalid IL and fake method header is passed to JIT, JIT returns failure (eax is non-zero). DNGuard then calls JIT again, this time with correct method header, IL and exception handlers.

I wasn't paying much attention to exact mechanism, dynamic unpacking (profiler or JIT hook based) does not interest me.

[bigmouse]

@kao
do you real checked this?
i noticed that dnguard called jit twice.
for Professional v2.92, the second time with correct IlCode.
but this sample ,i found the Ilcode contians some invalid values.

[Kurapica]

I also noticed they use an API "CorBindToRuntimeEx" !

I was reading about those APIs and they seem helpful in many weird ways, for example to Inject a "Managed" DLL into a process !!!

more here : http://www.edgeofnowhere.cc/viewtopic.php?t=430074

[kao]

@bigmouse: I know that they decrypt 100% correct IL code first, that's all I was interested into. It is possible that they damage the IL code before calling JIT engine, I could check that. Can you give me example - which method (name or token) has that problem?

@Kurapica: are you going to write full analysis and tutorial? I could give you some information for that, since I'm too lazy to write one myself.. ;)

[Kurapica]

@kao : I don't think I have all the needed info or knowledge to write a tutor on this, but honestly the JIT hooking technology is a priority for me :D

a year ago I wanted to emulate bigmouse's work in his maxtocode unpacker and write a general purpose unpacker to defeat this kind of protection :O

I'm still at the beginning and the more I read the more lost I am :D so that I sleep too little lately :P

I need a vacation !!

[kao]

DNGuard uses some tricks to stop naive generic JIT-hook-based unpackers from working. Example code from lgcoree.cpp by Daniel Pistelli:

int __stdcall my_compileMethod(ULONG_PTR classthis, ICorJitInfo *comp, CORINFO_METHOD_INFO *info, unsigned flags, BYTE **nativeEntry, ULONG *nativeSizeOfCode)
...
// call original method
int nRet = compileMethod(classthis, comp, info, flags, nativeEntry, nativeSizeOfCode); //Bug1: errorcode is not checked
DisplayMethodAndCalls(comp, info);
...
return nRet;
}

VOID DisplayMethodAndCalls(ICorJitInfo *comp, CORINFO_METHOD_INFO *info)
{
...
szMethodName = comp->getMethodName(info->ftn, &szClassName); //Bug2: CRASH!
...
}

Bug 1: on first pass, DNGuard sends invalid IL to JIT. Unpacker should check the return value and handle error appropriately. Lgcoree dumps the invalid IL instead.
Bug 2: DNGuard passes evil CORINFO_METHOD_HANDLE to JIT compiler. Specifically, ICorMethodInfo->getMethodName() is invalid. Lgcoree does not check that and crashes with access violation. Proper unpacker should always call ICorMethodInfo->getMethodName() from .NET framework or use method tokens instead of names.

Have fun!

[bigmouse]

@kao: Thanks for the info
i have checked the ret value and never called .

you can see method 06000002.
compile is ok. but ilcode decompile error.

[kao]

Token 06000002. First call to JIT, IL code:

00CF5138 FF FE 8C 00 00 00 00 00 00 00 00 00 00 00 00 00
00CF5148 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
IL code is obviously invalid. Jitter returns EAX=80000001

Second call to JIT, IL code:

00CF5138 00 00 28 12 00 00 0A 28 13 00 00 0A 00 DE 02 00
00CF5148 DC 00 28 07 00 00 06 02 6F 14 00 00 0A 00 00 2A
which disassembles as:

IL_0000: /* 00 | */ nop
IL_0001: /* 00 | */ nop
IL_0002: /* 28 | (0A)000012 */ call bool [Microsoft.VisualBasic/*23000002*/]Microsoft.VisualBasic.ApplicationServices.WindowsF ormsApplicationBase/*0100000C*/::get_UseCompatibleTextRendering() /* 0A000012 */
IL_0007: /* 28 | (0A)000013 */ call void [System.Windows.Forms/*23000003*/]System.Windows.Forms.Application/*01000015*/::SetCompatibleTextRenderingDefault(bool) /* 0A000013 */
IL_000c: /* 00 | */ nop
IL_000d: /* DE | 02 */ leave.s IL_0011

IL_000f: /* 00 | */ nop
IL_0010: /* DC | */ endfinally
IL_0011: /* 00 | */ nop
IL_0012: /* 28 | (06)000007 */ call class CrackME.My.MyApplication/*02000002*/ CrackME.My.MyProject/*02000003*/::get_Application() /* 06000007 */
IL_0017: /* 02 | */ ldarg.0
IL_0018: /* 6F | (0A)000014 */ callvirt instance void [Microsoft.VisualBasic/*23000002*/]Microsoft.VisualBasic.ApplicationServices.WindowsF ormsApplicationBase/*0100000C*/::Run(string[]) /* 0A000014 */
IL_001d: /* 00 | */ nop
IL_001e: /* 00 | */ nop
IL_001f: /* 2A | */ ret

You need to recover proper exception handlers, but otherwise everything is good here.. Do you get different IL code? :confused:

[bigmouse]

@kao
i got first and second ilcode at different memory address.

ant got similar ilcode second time, most like the original one. but some bytes different.

i'm using .net v2.0.50727.42 with some custom patch.

[kao]

I was little bit wrong about DNGuard hooks. DNGuard overwrites pointer to compileMethod but it never calls original compileMethod() from mscorjit.dll. It calls mscorjit!jitNativeCode() directly.

mscorjit!compileMethod looks like this:

7906E7F4 55 push ebp
7906E7F5 8B EC mov ebp, esp
7906E7F7 83 EC 10 sub esp, 10h
7906E7FA FF 75 14 push [ebp+arg_C]
7906E7FD 8B 45 10 mov eax, [ebp+arg_8]
7906E800 8B 08 mov ecx, [eax]
7906E802 83 65 FC 00 and [ebp+var_4], 0
7906E806 83 65 F4 00 and [ebp+var_C], 0
7906E80A 83 65 F0 00 and [ebp+var_10], 0
7906E80E 83 65 F8 00 and [ebp+var_8], 0
7906E812 8D 55 F8 lea edx, [ebp+var_8]
7906E815 52 push edx
7906E816 8D 55 F4 lea edx, [ebp+var_C]
7906E819 52 push edx
7906E81A 8D 55 F0 lea edx, [ebp+var_10]
7906E81D 52 push edx
7906E81E FF 75 1C push [ebp+arg_14]
7906E821 8D 55 FC lea edx, [ebp+var_4]
7906E824 52 push edx
7906E825 8B 50 04 mov edx, [eax+4]
7906E828 50 push eax
7906E829 FF 75 0C push [ebp+arg_4]
7906E82C E8 10 00 00 00 call jitNativeCode(CORINFO_METHOD_STRUCT_ *,CORINFO_MODULE_STRUCT_ *,ICorJitInfo *,CORINFO_METHOD_INFO *,void * *,ulong *,void * *,void * *,void * *,uint)
7906E831 85 C0 test eax, eax
7906E833 75 08 jnz loc_7906E83D
7906E835 8B 4D 18 mov ecx, [ebp+arg_10]
7906E838 8B 55 FC mov edx, [ebp+var_4]
7906E83B 89 11 mov [ecx], edx
7906E83D C9 leave
7906E83E C2 18 00 retn 18h


and DNGuard does this:

;on entry:
; ESI = 0
; EDI = pointer to mscorjit!compileMethod (or hooked compileMethod, if JIT-based unpacker is running)

check_next_instruction:
lea eax, [esi+edi]
push eax
call x86_length_disassembler ; returns EAX=length of instruction
add esi, eax
cmp byte ptr [edi+esi+2], 0
jnz short ok
cmp byte ptr [esi+edi], 0C2h ; check opcode of the instruction
jnz short ok
cmp byte ptr [esi+edi+1], 18h
jz short exit_bad ; found C2 18 00, which is "retn 18h" and means end of this procedure
ok:
cmp byte ptr [esi+edi], 0E8h
jz short found_jitNativeCode ; found "call" instruction, that must be call to mscorjit!jitNativeCode()
cmp esi, 0C8h
jl short check_next_instruction ; check first 200 bytes
exit_bad2:
pop edi ; did not find "call" in first 200 bytes, that's bad
pop esi
retn
; ---------------------------------------------------------------------------
found_jitNativeCode:
mov ecx, [esi+edi+1] ; \
add ecx, esi ; calculate address of jitNativeCode()
lea edx, [ecx+edi+5] ; /
mov original_jitNativeCode, edx
exit_bad:
pop edi
pop esi
retn

If compileMethod() is hooked by unpacker, DNGuard will not find a correct call and crash at some point. So... a good JIT-based unpacker should hook jitNativeCode() instead.. ;)

[bigmouse]

@kao
i'm not hook this function, i hooked a function 2 levels deep than jitNativeCode.

what your sad doesn't affect to me, that's not the problem.

[kao]

@bigmouse: previous post was general information, I did not mean it a solution for your problem. ;) I checked it on 2 different PCs (one real, one inside VMWare, 32-bit XP SP2/SP3, .NET v2.0.50727.42 without custom patches) and it works fine for me on both. Really strange..

Could someone else, please, check that IL code?

[Kurapica]

kao is so right and here is the proof.

-----------------------------------------------
This is the second call to JitNativeCode after I clicked the button in the crackme.

http://img100.imageshack.us/img100/9919/60995806.png


the second pointer in the stack window which I shaded in blue is a pointer to the MethodInfo, and you can see that I also shaded to pointer to the MSIL code in the dump window.

If you follow the shaded pointer in the dump window you will see this

----------------------------------------

http://img38.imageshack.us/img38/2213/98688440.png


yeah baby !! It's the real MSIL code naked.

----------------------------------------------

and now every time you see the name "kao" please people stop what you are doing and say "Thanks" !!

[bigmouse]

[Please DO NOT quote whole messages]

yes, i checked this on vm xp with original .NET v2.0.50727.42 .
without any changes , got the original il code.

that's very strange. maybe some triggered on my pc.
i'll dig more

[bigmouse]

@kao
is there a better way to recover LocalVarSigTok from jit hook?

i'd like to make re-max more generic.

[jacky]

Dnguard v3.5 was released.

Encryption Improved.
Add several encryption Algorithms.
[+] Algorithms theirself been Protected.
HVM transform policy changed.
Fixed a bug in .Net Framework detection, which may cause HVM Engine not on.
[+] New HVM code transform at protect time, and also does a secondary random transform at runtime .
Engine internal changes.

[Kurapica]

the poor authors must be reading this thread :D

anyway they can't do much to keep fooling the clients.

[bigmouse]

@bball0002 did your receive my PM.
maybe i got sth. about hvm, and want to verify it.

[Git]

If you have something to say please say it in plain english. No code talk here please.

Git

[jacky]

@bigmouse check ur PM plz.
i know what your guys want. and i also want to know whether it was really improved or not.
i only care about their protection against jit-hook unpacker, since they can easily change encryption and add more encrypt algorithms, but difficult to change their core protection.

[bigmouse]

still can't recover LocalVarSigTok, it never restore the original LocalVarSigTok at runtime. but i noticed the CORINFO_SIG_INFO struct, the last member of CORINFO_METHOD_INFO, it would be possible to build a new one directly from this. now i'm trying this.

i'v checked the hvm, part of ilcode been transformed.
the transform was based on instruction, i noticed that only some instructions with inlineParams were transformed. seems to it just does a per instruction protection on this instructions .
still digging how the get back the transformed part.

[kao]

You guys have been busy! :D Sorry, I had to take a week off..

@bigmouse: LocalVarSigTok is index into StandAloneSig table. StandAloneSig table contains index into the Blob heap. Blob heap contains LocalVarSig.
DNGuard internally does not use LocalVarSigTok or StandAloneSig table from the protected assembly. For each procedure it stores encrypted offset of correct LocalVarSig in Blob heap. When needed, it decrypts index, allocates memory and copies correct LocalVarSig from Blob heap into allocated memory. This new copy of LocalVarSig is passed to JIT.
Advanced JIT hooker could use LocalVarSig passed to JIT and write new StandAloneSig tables and blob heap. It's not fun project but certainly doable.

@jacky: DNGuard 3.5 increased the level of obfuscation inside hvmruntm.dll, a desperate (and failed) attempt to stop analysis of their engine. They also changed some internal structures, but overall - protection is still crap.

[jacky]

thanks kao. it seems at least they improved the ecryption of "High performance encryption method". but true, this ecryption method must be simple.
no one can stop others to analyse their app, they can only make it more time consuming.

[bigmouse]

@kao: thanks, i'v noticed this yet and doing it.
now, i'm going to update my maxtocode unpacker.

@jacky: no doubt that they improved ecryption and added more Algorithms. that's very easy to do.

no fun in playing with their ecrytion, the only result was waste our time and help them to make their ecrytion more time consuming.
i prefer JIT hooking technology, the jit protection was more hard to change.
eg maxtocode, they used some Algorithms and their runtime was protected by themida, but their jit protection was broken. they update and changed protection many times, my original unpacker(based on the custom patched framework) still work on their new version. seems to they only able to add some special antis against the public unpacker.

[anyi]

Hi, Guys,

I have read all these posts, and was planning to use DNGuard to protect my .net application. But now I lose confidence in DNGuard.

Could any one of you, please suggest any .Net protector which is not a crap? I am looking forward to your suggestion and thank you in advance.

Anyi

[Poma]

All protections are crap. I don't know much about reverse engineering but it seems that it's much easier to break protection than to build it. Anyway, there's no unbreakable generic protection. If your app is good than there will be crack to it on the internet. So just don't spend much time protecting your app; spend it to develop new features and to support customers, make better marketing.

For my own software I use DNGuard (any jit-hook protector works fine enough) but scrambled a bit. Also I've renamed all strings wich contain 'dnguard', 'zuxuan' etc. So kiddies that use third-party generic unpackers can't detect what protection it is and therefore can't use their scripts. Experienced crackers will still easily break this protection, but they always can no matter what I do to stop them :)

Also it's always good to obfuscate your code using for example Smartassembly. So once cracker obtained IL code he can't use reflector do decompile it to easy-readable C# and has to read MSIL.