Cheat Engine Forum Index Cheat Engine
The Official Site of Cheat Engine
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 


Question about decompiling C++and .NET program.

 
Post new topic   Reply to topic    Cheat Engine Forum Index -> General programming
View previous topic :: View next topic  
Author Message
Dr.Disrespect
Grandmaster Cheater
Reputation: 3

Joined: 17 Feb 2016
Posts: 526

PostPosted: Tue Jan 24, 2017 3:14 am    Post subject: Question about decompiling C++and .NET program. Reply with quote

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. Very Happy
Back to top
View user's profile Send private message
atom0s
Moderator
Reputation: 198

Joined: 25 Jan 2006
Posts: 8516
Location: 127.0.0.1

PostPosted: Tue Jan 24, 2017 2:10 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Dr.Disrespect
Grandmaster Cheater
Reputation: 3

Joined: 17 Feb 2016
Posts: 526

PostPosted: Wed Jan 25, 2017 3:26 pm    Post subject: Reply with quote

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". Very Happy

Thanks again. Smile

_________________
**************

A simple example is better then ten links. Very Happy
Back to top
View user's profile Send private message
STN
I post too much
Reputation: 42

Joined: 09 Nov 2005
Posts: 2672

PostPosted: Wed Jan 25, 2017 3:40 pm    Post subject: Reply with quote

C# source code ------> IL(MSIL) ------>JIT --------> machine code

Just in time compilation

_________________
Cheat Requests/Tables- Fearless Cheat Engine
https://fearlessrevolution.com
Back to top
View user's profile Send private message
atom0s
Moderator
Reputation: 198

Joined: 25 Jan 2006
Posts: 8516
Location: 127.0.0.1

PostPosted: Wed Jan 25, 2017 8:48 pm    Post subject: Reply with quote

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". Very Happy

Thanks again. Smile


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
View user's profile Send private message Visit poster's website
Dr.Disrespect
Grandmaster Cheater
Reputation: 3

Joined: 17 Feb 2016
Posts: 526

PostPosted: Thu Jan 26, 2017 9:23 pm    Post subject: Reply with quote

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". Very Happy

Thanks again. Smile


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. Very Happy
Back to top
View user's profile Send private message
atom0s
Moderator
Reputation: 198

Joined: 25 Jan 2006
Posts: 8516
Location: 127.0.0.1

PostPosted: Fri Jan 27, 2017 2:05 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Dr.Disrespect
Grandmaster Cheater
Reputation: 3

Joined: 17 Feb 2016
Posts: 526

PostPosted: Sat Jan 28, 2017 2:27 pm    Post subject: Reply with quote

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. Smile

_________________
**************

A simple example is better then ten links. Very Happy
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Cheat Engine Forum Index -> General programming All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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


Powered by phpBB © 2001, 2005 phpBB Group

CE Wiki   IRC (#CEF)   Twitter
Third party websites