How to make a custom version of ConfuserEx?

[andrewfamn]

This is more like a Q&A than an issue report but I don't know where to ask so I post it here. Therefore, I'm sorry about that. In your FAQ, you mention "a generic deobfuscator for different custom version of ConfuserEx would be virtually impossible to be created."

1. What classes in the source code should I work on in order to make a custom version?
2. Is it helpful if I provide a seed to crproj file?
3. If my application includes a strong name key, does it make harder being deobfuscated?
4. And how do I implement a plug-in? Thank you very much.

[yck1509]

1. The simplest way is to change some values in encryption algorithm. For example for constant protection, you could change the constant in here and here. If you want more modification, you could replace the encryption algorithm completely.
2. Seed is used to initialize the random mechanism used in ConfuserEx. Providing seed would ensure the output does not change each time you obfuscate. It might be helpful to find bugs in protection if sometimes the output crashes.
3. Strong Name Key is usually used to ensure the identity of the author. It has no effect in protection strength. Although some protector validate the strong name key in protection, ConfuserEx provides no such functionality as it can be defeated easily most of time.
4. Plugins are used to provide more protection in ConfuserEx. You could create a plugin by referencing Confuser.Core.dll in your project and inherits class Protection or Packer.

[andrewfamn]

Thank you, yck1509. It's very helpful information.

[damms005]

Please @yck1509 , I need help with these:

1. Which constants in this file can I change safely without breaking things?
2. Can you recommend a resource where I can learn the basics needed for me to know how to safely customize this same file further in order to improve the security of my obfuscated executable. For example, how can I know if it is safe to change the decimals (12, 25, and 27) in the code snippet below (still the same Constant.cs file):

var n = (uint)Mutation.KeyI1;
for (int i = 0; i < 0x10; i++) 
{
    n ^= n >> 12;
    n ^= n << 25;
    n ^= n >> 27;
    k[i] = n;
}

[Drizin]

As far as I remember Symmetric-Key cryptography, you are right that you should choose numbers carefully. That is confirmed by Wikipedia on xorshift, that explains that bad numbers could achieve short periods on your random numbers. And the longest the period of your random number key, the longer it would take for a brute-force attack to break your encryption.

I just noticed that Wikipedia xorshift example uses the exact same numbers as ConfuserEx. You can find here and here some more numbers that provide good random generators, although I guess they are using a different order for the left/right shifting.

Having said that, I guess that even if you choose some "bad numbers" for the shifting operations, I believe you'll still be safe against script kiddies, who probably won't use anything more than ready-made unpackers/deobfuscators. I mean: even if you choose a bad encryption key, what are the chances of someone brute-forcing your custom-obfuscator just to decrypt your constants? I haven't yet seen a deobfuscator doing brute-force. Probably it would take so long (even if you choose bad numbers) that it wouldn't worth it

PS: Please note that you should change those numbers on both EncodePhase.cs and Constant.cs.

PPS: A long period does not imply high quality.