1

I am actually working for the side of software protection. But in order to properly protect my source code ( be it .Net or C++), I would need to understand what is achievable ( and not achievable) from hacker's point of view .

I can protect/obfuscate/encrypt/virtualize my code all the way I want, but when the source code is loaded into the memory, it will have to be unprotected in order to run. So at this point of time, can hacker dump the source code out from the memory, and thus recover my source code in full, unadulterated fashion?

If yes, how this can be done? Using what tools?

Edit: from my finding, it seems that this is doable, and there are protection tools that can prevent this, such as Agile.Net:

Method Level Code Encryption - Encrypts all the MSIL code and keeps it in a secure storage. When the assembly is loaded Agile.NET binds to the .NET runtime engine and manages decrypting the MSIL on a per method basis. Agile.NET creates a runtime environment that executes the original MSIL code by decrypting one method at a time, this important virtue minimizes the exposure of MSIL code in memory thus prevents dumping the code from physical memory.

But I have no idea how, can anyone shed some lights on this?

5
  • Review your knowledge of the compilation process. Unless you are actively compiling your source code, it will never reside in memory.
    – Jongware
    Commented Sep 7, 2016 at 8:33
  • Why am I downvoted?
    – Graviton
    Commented Sep 7, 2016 at 8:34
  • @RadLexus, would you like to expand your comment into a proper answer?
    – Graviton
    Commented Sep 7, 2016 at 8:34
  • @RadLexus, I'm not too sure about the validity of your claim; see the updated question
    – Graviton
    Commented Sep 7, 2016 at 9:45
  • For .NET you can use any of ILSpy, Reflector or DotPeek to retrieve C# code from a .DLL or .EXE (as long as it is 100% managed code). Commented Sep 7, 2016 at 17:34

1 Answer 1

4

Just to be clear: You can not reconstruct source code from .net or c++ binaries. You can try to recover it using heuristics, embedded symbols and knowledge about the assembler, but you already lost the necessary information in translation.

You should differentiate between packing and obfuscation.

Packing means you encrypt (and / or compress) parts of your compiled code and have a decryption / unpacking stub at the beginning, fetching the encrypted blocks and unpacking them. This can be often observed in the case of malicious software. In this case, you can dump the memory right after the decryption process and it will be unencrypted.

There are more sophisticated means of packing like VM-packing, which increase the challenge of dumping the data noticeably, but there has been a lot of research in this area. That being said, something like a general unpacker does not exist.

Obfuscation on the other hand alters the code directly in a fashion which makes it still able to be executed. For example, a common technique is obfuscating the control flow though the use of spaghetti code, e.g. inserting unnecessary branches and jumps. These operations can principally not be undone and increase the challenge of reversing significantly.

-> You can not hide the logic you want to execute from the machine you want it to run on. You can only make it harder for humans to figure out what your code does.

7
  • "you can dump the memory right after the decryption process and it will be unencrypted"-- so this means that the packed source code can be unpacked, by dumping it out from the memory using appropriate decompilers?
    – Graviton
    Commented Sep 7, 2016 at 9:48
  • If yes, how? any tools/resources to recommend?
    – Graviton
    Commented Sep 7, 2016 at 9:51
  • You can dump the machine code at any time utilizing an debugger. Other common tools are the Process Explorer or dumping the whole memory using a virtual machine.
    – Nordwald
    Commented Sep 7, 2016 at 10:28
  • Norward, how do you view the claim that MSIL code in memory can be exposed ( see my updated question), is it possible, and if yes, how it can be done?
    – Graviton
    Commented Sep 7, 2016 at 11:20
  • All memory can be dumped. The advantage of function-level-encryption is that you decrypt each function just before it is executed. To be able to dump the whole code, you would need to dump the memory at each function call or decrypt the code yourself (reverse the encryption). Code which shall be executed has to reside in memory.
    – Nordwald
    Commented Sep 7, 2016 at 11:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.