techno
techno

Reputation: 6518

Preventing Memory Dump of Packed .Net Executable?

Is there any way to prevent the Dumping of the Pure C# Assembly Executable loaded into the memory which is originally protected by a 32 Bit Exe Native Code Wrapper.

Upvotes: 2

Views: 5194

Answers (4)

Mecanik
Mecanik

Reputation: 1049

Whilst there is no full-proof way of preventing someone from dumping your .net executable, there are ways to make this much more harder.

Take a look at my repository for .net/c# anti-debug and anti-dumping techniques:

https://github.com/Mecanik/Anti-DebugNET

To answer your specific question, there is a method there to prevent "MegaDumper" from dumping your executable.

I hope this helps.

Upvotes: 0

rollsch
rollsch

Reputation: 2780

Write a windows driver that runs as a protected process. Only launch your program via this driver and launch it also as a protected process.

Not even anti virus programs will be able to scan the memory of your program if you do this. This is as if you attempt to call openprocess or readprocessmemory of a protected process you will recieve access denied.

The main issue here is the driver must be a windows certified driver which is time consuming to achieve.

Also you would have to implement a method to check the program has been called by the protected process driver and if it was not fail to open the program. This kind of check could be easily removed.

Upvotes: 0

Adam Mihalcin
Adam Mihalcin

Reputation: 14478

@Hasan is right in saying that there is no way to prevent a memory dump. However, I think there's a deeper issue here. When you write about a C# assembly being "originally protected by a 32 Bit Exe Native Code Wrapper" (emphasis mine), it seems that you want to prevent someone from examining the contents of the C# assembly itself.

As soon as someone has their hands on that assembly, they can crack it open and learn more about it than you expect. For instance, they can decompile it to C# source code using dotPeek or ILSpy. You can use an obfuscator to make your life more difficult for someone using these tools, but even obfuscation only goes so far.

The bottom line is: once you make it available to someone else, it's out of your hands. Expect that someone else will decompile your code and post copies on torrent sites (unless it's free anyway). Don't put your super-secret database password in your code, because someone can decompile the code and read the password off in plain text. Even if you're running this code on a server, don't put the password in the code, for reasons I describe in another SO answer here.

N.B. Once you start distributing your software, there is also no way to prevent someone from attaching a debugger to your running executable, so barring the issues with inspecting the executable itself, someone doesn't even need a memory dump in order to inspect runtime information.

Upvotes: 3

Muhammad Hasan Khan
Muhammad Hasan Khan

Reputation: 35146

There is no fool proof way of preventing memory dumps. You can put values in secure strings. Which are encrypted hence if someone takes a memory dump; they'll not be able to make sense out of it.

Upvotes: 2

Related Questions