|
Cheat Engine The Official Site of Cheat Engine
|
View previous topic :: View next topic |
Author |
Message |
Dr.Disrespect Grandmaster Cheater Reputation: 3
Joined: 17 Feb 2016 Posts: 526
|
Posted: Tue Jan 24, 2017 3:14 am Post subject: Question about decompiling C++and .NET program. |
|
|
I am wondering the difference between native C++ and .NET languages, like C#. More specifically:
1. Why is it so easy to decompile C# application? I can use dotPeek to do so, but not on application written in native C++.
I have done some research, some says it is because "the c++ language is linked to the processor for optimal performance. This means that the language is translated to assembly, which then translates to binary." So, if this is correct, what is C# source code translated into? Is it first translated or compiled into IL(intermediate language)? Is this the reason why C# can be decompiled easier than native C++?
I really want to know the difference, but don't know where to start with.
2. Is object code similar to assembly code? Or are they the same thing?
3. I made a C# application and used TripleDESCryptoServiceProvider class to encrypt some data. However, the C# application can be easily decompiled by dotPeek, which means the source code that contains the encryption key can be obtain by anyone using dotPeek, as a result, my encryption is futile.
Is there a way to prevent that? Or at least making it more difficult to decompile? BTW, I know how to obfuscate the code, but I don't think that's enough tho.
Thanks in advance.
_________________
**************
A simple example is better then ten links. |
|
Back to top |
|
|
atom0s Moderator Reputation: 199
Joined: 25 Jan 2006 Posts: 8518 Location: 127.0.0.1
|
Posted: Tue Jan 24, 2017 2:10 pm Post subject: |
|
|
1. C++ is a native language. It compiles down to machine code which can be highly optimized and altered by the compiler and linker. It leaves little room to be decompiled back to its original source. The only tool close to having this happen is the HexRays plugin for IDA. It is far from perfect and does not produce the most readable output but it is more of a 'here's an idea of what's going on' type thing.
C# on the other hand is a managed language. Rather than compiling down to machine code, it compiles to IL code which has a specific set of instructions for what goes on. It is extremely easy to translate IL code back to its original source (or extremely close to it) because of how little is done between what you write and what happens to the code.
2. Object code is the result of what a compiler makes after you compile a program. It will typically be machine code or a another low-level form of code based on the compiler itself. It is not the same as assembly code since machine code is general in binary form.
3. The only thing you can do is use / create obfuscation on your program to obscure what is decompiled. There is no 100% guaranteed method of preventing people from decompiling your programs written in .NET languages, because of how .NET works. Obfuscators like ConfuserEx are a good place to start when learning about protections that can be added to .NET programs, but just keep in mind if you use something pre-made, like stock ConfuserEx with no changes, you are going to have your program unpacked easily. Code flow obfuscation is key to making it difficult to reading your file.
_________________
- Retired. |
|
Back to top |
|
|
Dr.Disrespect Grandmaster Cheater Reputation: 3
Joined: 17 Feb 2016 Posts: 526
|
Posted: Wed Jan 25, 2017 3:26 pm Post subject: |
|
|
atom0s wrote: | 1. C++ is a native language. It compiles down to machine code which can be highly optimized and altered by the compiler and linker. It leaves little room to be decompiled back to its original source. The only tool close to having this happen is the HexRays plugin for IDA. It is far from perfect and does not produce the most readable output but it is more of a 'here's an idea of what's going on' type thing.
C# on the other hand is a managed language. Rather than compiling down to machine code, it compiles to IL code which has a specific set of instructions for what goes on. It is extremely easy to translate IL code back to its original source (or extremely close to it) because of how little is done between what you write and what happens to the code.
2. Object code is the result of what a compiler makes after you compile a program. It will typically be machine code or a another low-level form of code based on the compiler itself. It is not the same as assembly code since machine code is general in binary form.
3. The only thing you can do is use / create obfuscation on your program to obscure what is decompiled. There is no 100% guaranteed method of preventing people from decompiling your programs written in .NET languages, because of how .NET works. Obfuscators like ConfuserEx are a good place to start when learning about protections that can be added to .NET programs, but just keep in mind if you use something pre-made, like stock ConfuserEx with no changes, you are going to have your program unpacked easily. Code flow obfuscation is key to making it difficult to reading your file. |
First of all, sorry for the late reply. I was kinda busy for the past two days.
Thank you so much, atom0s. Your explanation has offered great help as always.
One more follow up questions tho:
How does IL language get translated into machine code? Because with C++, it's pretty straight forward:
C++ source code ------> machine code
But for C#:
C# source code ------> IL ------>? --------> machine code
The question mark above is my "question".
Thanks again.
_________________
**************
A simple example is better then ten links. |
|
Back to top |
|
|
STN I post too much Reputation: 42
Joined: 09 Nov 2005 Posts: 2672
|
Posted: Wed Jan 25, 2017 3:40 pm Post subject: |
|
|
C# source code ------> IL(MSIL) ------>JIT --------> machine code
Just in time compilation
_________________
|
|
Back to top |
|
|
atom0s Moderator Reputation: 199
Joined: 25 Jan 2006 Posts: 8518 Location: 127.0.0.1
|
Posted: Wed Jan 25, 2017 8:48 pm Post subject: |
|
|
fmanager wrote: | First of all, sorry for the late reply. I was kinda busy for the past two days.
Thank you so much, atom0s. Your explanation has offered great help as always.
One more follow up questions tho:
How does IL language get translated into machine code? Because with C++, it's pretty straight forward:
C++ source code ------> machine code
But for C#:
C# source code ------> IL ------>? --------> machine code
The question mark above is my "question".
Thanks again. |
For languages like C# (similar is Java in how its compiled and used etc.) the code you write is compiled into a bytecode that is known as IL.
If you open the compiled exe in a decompiler and view the raw IL code, you will see the bytecode information that is translated from the code you wrote.
For example, if you have a simple function like this:
Code: | static bool IsTrueFalse(bool value)
{
if (value == true)
return true;
else
return false;
} |
This will compile down to the following bytecode (IL): (Labels for jumps omitted etc.)
Code: |
nop
ldarg.0
stloc.0
ldloc.0
brfalse.s
ldc.i4.1
stloc.1
br.s
ldc.i4.0
stloc.1
br.s
ldloc.1
ret
|
When you run a .NET program, it runs a 'pseudo' virtual environment. The CLR, the VM, will compile the code on the fly as its needed and used, which is known as JIT'ing. When the code is compiled during runtime through JITing, this is where it is then translated to machine code and understood by the underlying system it is running on.
Given how a VM works in this nature, the CLR for instance, you can technically compile C# fully down to machine code instead of having it run within the VM. However, this is not something Microsoft built into the C# language and tools as a standard feature. Microsoft more or less recently offered the tool "ngen" to do this but it has some limitations, such as while your project will be compiled to native code, the runtimes (CLR/framework) will still be required.
_________________
- Retired. |
|
Back to top |
|
|
Dr.Disrespect Grandmaster Cheater Reputation: 3
Joined: 17 Feb 2016 Posts: 526
|
Posted: Thu Jan 26, 2017 9:23 pm Post subject: |
|
|
atom0s wrote: | fmanager wrote: | First of all, sorry for the late reply. I was kinda busy for the past two days.
Thank you so much, atom0s. Your explanation has offered great help as always.
One more follow up questions tho:
How does IL language get translated into machine code? Because with C++, it's pretty straight forward:
C++ source code ------> machine code
But for C#:
C# source code ------> IL ------>? --------> machine code
The question mark above is my "question".
Thanks again. |
For languages like C# (similar is Java in how its compiled and used etc.) the code you write is compiled into a bytecode that is known as IL.
If you open the compiled exe in a decompiler and view the raw IL code, you will see the bytecode information that is translated from the code you wrote.
For example, if you have a simple function like this:
Code: | static bool IsTrueFalse(bool value)
{
if (value == true)
return true;
else
return false;
} |
This will compile down to the following bytecode (IL): (Labels for jumps omitted etc.)
Code: |
nop
ldarg.0
stloc.0
ldloc.0
brfalse.s
ldc.i4.1
stloc.1
br.s
ldc.i4.0
stloc.1
br.s
ldloc.1
ret
|
When you run a .NET program, it runs a 'pseudo' virtual environment. The CLR, the VM, will compile the code on the fly as its needed and used, which is known as JIT'ing. When the code is compiled during runtime through JITing, this is where it is then translated to machine code and understood by the underlying system it is running on.
Given how a VM works in this nature, the CLR for instance, you can technically compile C# fully down to machine code instead of having it run within the VM. However, this is not something Microsoft built into the C# language and tools as a standard feature. Microsoft more or less recently offered the tool "ngen" to do this but it has some limitations, such as while your project will be compiled to native code, the runtimes (CLR/framework) will still be required. |
Thank you so much again, at0mos, and also, STN.
I've done some research about Negen.exe on Microsoft's website:https://msdn.microsoft.com/en-us/library/6t9t5wcf(v=vs.110).aspx
If I understand correctly, I can use Ngen to further "compile" or "process" my .NET exe application, and it can not only makes others more difficult to decompile my app, but also may increase the performance of my app. Is that right?
_________________
**************
A simple example is better then ten links. |
|
Back to top |
|
|
atom0s Moderator Reputation: 199
Joined: 25 Jan 2006 Posts: 8518 Location: 127.0.0.1
|
Posted: Fri Jan 27, 2017 2:05 am Post subject: |
|
|
fmanager wrote: | If I understand correctly, I can use Ngen to further "compile" or "process" my .NET exe application, and it can not only makes others more difficult to decompile my app, but also may increase the performance of my app. Is that right? |
Yes and no. It really depends on your application and its purpose. The ngen page explains the goods and bads fairly well on what will and won't be affected. Ideally, if your concern is for security, then compiling down to native code will be better in the end. But in terms of performance it does not always mean it will be better.
_________________
- Retired. |
|
Back to top |
|
|
Dr.Disrespect Grandmaster Cheater Reputation: 3
Joined: 17 Feb 2016 Posts: 526
|
Posted: Sat Jan 28, 2017 2:27 pm Post subject: |
|
|
atom0s wrote: | fmanager wrote: | If I understand correctly, I can use Ngen to further "compile" or "process" my .NET exe application, and it can not only makes others more difficult to decompile my app, but also may increase the performance of my app. Is that right? |
Yes and no. It really depends on your application and its purpose. The ngen page explains the goods and bads fairly well on what will and won't be affected. Ideally, if your concern is for security, then compiling down to native code will be better in the end. But in terms of performance it does not always mean it will be better. |
Thank you atom0s.
_________________
**************
A simple example is better then ten links. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum
|
|