![]() |
|
[C#] Protect soft so it won't leak the Source Code - Printable Version +- Hack Forums (https://hackforums.net) +-- Forum: Tech (https://hackforums.net/forumdisplay.php?fid=444) +--- Forum: Coding (https://hackforums.net/forumdisplay.php?fid=151) +---- Forum: Software Development (https://hackforums.net/forumdisplay.php?fid=118) +---- Thread: [C#] Protect soft so it won't leak the Source Code (/showthread.php?tid=5969206) |
Protect soft so it won't leak the Source Code - Jacked - May 12, 2019 Hey, I have done some research and I understand that any C# .NET app can be easily decompiled using different reflectors. I saw some solutions to that (at least make it harder to get the source code) but they all are old. What are the modern solutions to this problem? And one more question, is using a Crypter will help me prevent code leaking in this situation? Just to be clear, I don't make a malware, Just don't want my source code to be public so wondering if a Crypter will help. Thank you 🤝 RE: Protect soft so it won't leak the Source Code - Suspect. - May 12, 2019 Just use Netguard it’s pretty good. Might get some false positives from virus scans but that’s a go with any obfuscator really. It’s affordable and does the job. It’s tricky to reverse engineer but it’s not impossible ofc RE: Protect soft so it won't leak the Source Code - Dotexe - May 12, 2019 OP go for Eazfuscator ;) /thread RE: Protect soft so it won't leak the Source Code - JUSTIN - May 12, 2019 (May 12, 2019 07:36 AM)Qiwi Wrote: Hey, What you're referring to is known as obfuscation. There are loads of available programs used for .NET obfuscation, some are better than others. It's important to understand that no matter how hard you try to protect your code, it will always be readable to some extent if a reverse engineer is experienced enough. Sensitive information like server credentials/api keys/passwords should never be stored in a program that's being released to consumers. The only real purpose of obfuscation is to make it more difficult for people to understand/steal/crack your software. It should never be used as a means to protect truly sensitive data. That being said, I recommend choosing an obfuscator that has Code Virtualization. When you compile .NET, it doesn't turn into machine code. I explain this more in depth in a different post: JUSTIN pid='' dateline=' Wrote:well .net applications are actually compiled to a CIL, that being MSIL. MSIL = microsoft intermediate language, and it's the instruction set that .net is compiled to. JIT (Just-In-Time) converts the IL to machine code on the fly, but when you're analyzing the assembly itself, you'll typically be looking at either reflected code or IL instructions. The process of code virtualization in .NET removes the MSIL instructions of a function from the application and stores encrypted instructions elsewhere in the programs resources. This is much better than standard obfuscation. Whereas some more common methods simply make the code ugly and hard to read, code virtualization completely removes it from any .NET reflection software/decompilers. The reverse engineer would need a tool that can automatically find these functions in resources, decrypt them, and restore them to their original IL code. This is certainly possible and not uncommon, but like I said, obfuscation is simply about making your code more difficult to read. (May 12, 2019 08:29 AM)Dotexe҆ Wrote: OP go for Eazfuscator ;) By the way, EAZFuscator is one of the programs known for it's code virtualization. I use it on some of my software and I'd recommend it. The developer has his own break down of code virtualization that can be found here: https://www.gapotchenko.com/eazfuscator.net/features/virtualization It's also important to note that EAZFuscator wont automatically utilize this feature, you'll need to add attributes to specific functions that you'd like it to be used on. Obviously anything related to licensing/authentication should have this attribute. I believe Babel also has this feature. Not sure of any other ones, but they're typically paid and cost multiple hundred dollars. RE: Protect soft so it won't leak the Source Code - Dotexe - May 12, 2019 (May 12, 2019 08:35 AM)JUSTIN Wrote: *snip* Exactly, enjoy the +3 RE: Protect soft so it won't leak the Source Code - VENI - May 14, 2019 I suggest a virtualizer and not any modded public versions of confuserex. Like koi-vm it is a bit outdated but you can modify it as netguard is easy af to unpack same as trinity RE: Protect soft so it won't leak the Source Code - +Haze - May 14, 2019 (May 12, 2019 08:41 AM)Dotexe҆ Wrote: Exactly, enjoy the +3 What if he doesn't want to enjoy the +3? 😠 RE: Protect soft so it won't leak the Source Code - SwagotMcFaggot - May 14, 2019 (May 12, 2019 08:29 AM)Dotexe҆ Wrote: OP go for Eazfuscator ;) You should not go with Eazfuscator. I recommend creating your own obfuscator. There are many open sourced obfuscators online such as ConfuserEX. Otherwise Engima is a good option. RE: Protect soft so it won't leak the Source Code - JUSTIN - May 14, 2019 (May 14, 2019 01:56 PM)SwagotMcFaggot Wrote: You should not go with Eazfuscator. I recommend creating your own obfuscator. There are many open sourced obfuscators online such as ConfuserEX. Otherwise Engima is a good option. pretty useless post tbh. somebody who doesn't understand how .NET binaries are compiled and how their code is interpreted is not going to maically be able to create their own obfuscator, or add anything valuable to ConfuserEX. also, isn't Enigma a native packer? does it even obfuscate the .NET? i assume mega dumper or some other .NET unpacker will be able to dump the actual IL code from memory.... RE: Protect soft so it won't leak the Source Code - unknown2me - May 15, 2019 You can either use a .NET obfuscator which supports virtualisation or use a obfuscator with a native packer which does (as specified above). .NET obfuscators with virtualisation:
Native packers with virtualisation
Worth remembering that this isn't a foolproof method either, you'll benefit from implementing some of your own methods. RE: Protect soft so it won't leak the Source Code - Aristocles - May 15, 2019 • Using a crypter is bad because they are done to get FUD, not to prevent people from checking the source code (to some extent but its not strong). Also you will bring false positive due to the crypter's detection. • Modern solution is : SaaS, Software as a service, also known as "put your sensitive code in a remote server and execute the code remotely, not on customer's computer". This way nobody will ever decompile your sensitive code. No need obfuscator, crypter or whatever. RE: Protect soft so it won't leak the Source Code - +Haze - May 15, 2019 If you don't want to leak source code, don't give users access to the code. Simple as that. RE: Protect soft so it won't leak the Source Code - tweety - May 15, 2019 host your code on a server where people cant touch it /thread edit; https://www.codeproject.com/Articles/496593/LiteCode-Remotely-call-methods-over-the-network RE: Protect soft so it won't leak the Source Code - red - May 15, 2019 (May 15, 2019 04:39 AM)Aristocles Wrote: • Using a crypter is bad because they are done to get FUD, not to prevent people from checking the source code (to some extent but its not strong). Also you will bring false positive due to the crypter's detection. Thisss. RE: Protect soft so it won't leak the Source Code - Washi - May 15, 2019 (May 15, 2019 04:39 AM)Aristocles Wrote: • Modern solution is : SaaS, Software as a service, also known as "put your sensitive code in a remote server and execute the code remotely, not on customer's computer". This way nobody will ever decompile your sensitive code. No need obfuscator, crypter or whatever. Maybe, but this is not always possible nor always the best solution. An active network connection is necessary, which is not only always present, and also slows down your program a lot when lots of traffic is going. But more importantly, some code (such file operations, starting or stopping processes, etc.) simply cannot be put on a remote server. This is exactly like was discussed a few days ago. |