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 🤝
\(〇_o)/
May 12, 2019 08:15 AM
(This post was last modified: May 12, 2019 08:17 AM by Suspect..)
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
[email protected]
Discord: Lord_Suspect
[ 0x01] I do not deal elsewhere, these are my only accounts; confirm on site before conducting business!! [ 0x02]
OP go for Eazfuscator ;)
/thread
Жизнь это не те дни, что прошли, а те, что запомнились
May 12, 2019 08:35 AM
(This post was last modified: May 12, 2019 08:38 AM by JUSTIN.)
(May 12, 2019 07:36 AM)Jacked Wrote: 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 🤝
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 ;)
/thread
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....ualization
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.
(May 12, 2019 08:35 AM)JUSTIN Wrote: *snip*
Exactly, enjoy the +3
Жизнь это не те дни, что прошли, а те, что запомнились
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
(May 12, 2019 08:41 AM)Dotexe Wrote: Exactly, enjoy the +3
What if he doesn't want to enjoy the +3? 😠
DO NOT DEAL WITH THIS MEMBER
May 14, 2019 01:56 PM
(This post was last modified: May 14, 2019 01:58 PM by SwagotMcFaggot.)
(May 12, 2019 08:29 AM)Dotexe Wrote: OP go for Eazfuscator ;)
/thread
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.
(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....
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:- Eazfuscator (best)
- NETGuard
- Babelsoft
Native packers with virtualisation
Worth remembering that this isn't a foolproof method either, you'll benefit from implementing some of your own methods.
• 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.
Assert failure(PID 10704 [0x000029d0], Thread: 10960 [0x2ad0]): pBuffer != NULL
If you don't want to leak source code, don't give users access to the code. Simple as that.
May 15, 2019 08:01 AM
(This post was last modified: May 15, 2019 08:03 AM by tweety.)
host your code on a server where people cant touch it
/thread
edit; https://www.codeproject.com/Articles/496...he-network
DO NOT DEAL WITH THIS MEMBER
(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.
• 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.
Thisss.
(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.
|