How to remove CLI Header or how to disable dissasembling of my app
-
Hi. I want to know on how to remove the cli header. I actualy dont know what this is... but i tried to dissasemble a random app. (.exe) with .NET Reflector and it said that it cannot be disass. because it does not contain a CLI Header. If i try to dissasemble my .NET applications (just to create a new project and build it and then try to disassemble it) - it disassembles. Anyway on how to prevent on making this possible? Thank you in advance!
Regards, Matjaž
-
Hi. I want to know on how to remove the cli header. I actualy dont know what this is... but i tried to dissasemble a random app. (.exe) with .NET Reflector and it said that it cannot be disass. because it does not contain a CLI Header. If i try to dissasemble my .NET applications (just to create a new project and build it and then try to disassemble it) - it disassembles. Anyway on how to prevent on making this possible? Thank you in advance!
Regards, Matjaž
The reason it did not work (does not contain a CLI Header) is that it is a native app, rather than a .NET managed app. These do not work with reflection. As regards your .NET apps, the best you can do is obfuscate[^] it.
No trees were harmed in the sending of this message; however, a significant number of electrons were slightly inconvenienced. This message is made of fully recyclable Zeros and Ones
-
The reason it did not work (does not contain a CLI Header) is that it is a native app, rather than a .NET managed app. These do not work with reflection. As regards your .NET apps, the best you can do is obfuscate[^] it.
No trees were harmed in the sending of this message; however, a significant number of electrons were slightly inconvenienced. This message is made of fully recyclable Zeros and Ones
Correct. I will just add that it's still of course possible to disassemble any application; a native app just requires a native disassembler rather than a .net one. And native apps don't contain the metadata to reconstruct high-level code like .net apps do. So it would seem an alternative to obfuscation could be to write your secret code in C++ and compile it natively, then create a .net assembly that is a thin wrapper to use this native .dll in your .net apps. But it's not an attractive route to go imo if you're a .net programmer, especially if you haven't made native apps before and don't plan to do so anyway. Isn't copyright enough? :)
-
Correct. I will just add that it's still of course possible to disassemble any application; a native app just requires a native disassembler rather than a .net one. And native apps don't contain the metadata to reconstruct high-level code like .net apps do. So it would seem an alternative to obfuscation could be to write your secret code in C++ and compile it natively, then create a .net assembly that is a thin wrapper to use this native .dll in your .net apps. But it's not an attractive route to go imo if you're a .net programmer, especially if you haven't made native apps before and don't plan to do so anyway. Isn't copyright enough? :)
dojohansen wrote:
Isn't copyright enough?
Um. I can think of a few sites that have been on the news recently that imply not... :~ :laugh:
No trees were harmed in the sending of this message; however, a significant number of electrons were slightly inconvenienced. This message is made of fully recyclable Zeros and Ones
-
The reason it did not work (does not contain a CLI Header) is that it is a native app, rather than a .NET managed app. These do not work with reflection. As regards your .NET apps, the best you can do is obfuscate[^] it.
No trees were harmed in the sending of this message; however, a significant number of electrons were slightly inconvenienced. This message is made of fully recyclable Zeros and Ones
Ok. Thanks. I went over the documentation u gave me and will try to work something out. Thanks for your help! :)
Regards, Matjaž
