dotfuscator反編譯
『壹』 VS怎樣給項目加強名稱，怎樣防止反編譯
.net 生成的dll 反編譯很簡單的
一般.net的dll防止反編譯 採用 加殼和混淆 兩種方案
加殼我沒怎麼研究過,一般加殼工具使用後會造成dll不能使用
最常用的就是混淆了,工具也很多 我一般使用Xenocode進行混淆
可以對 類名,變數名,屬性 等命名進行混淆 減小其反編譯後的可讀性
你可以自己嘗試一下 基本混淆後的程序 反編譯後 很難自己解讀出來
『貳』 C#如何防止被別人反編譯
C# 編寫的代碼通過VS編譯器生成 dll 或 exe ，很容易被一些反編譯工具查看到源碼或對源碼進行修改。
為防止代碼被反編譯或被篡改，我們可以進行一定的防範措施。但不能杜絕，因為DotNet編寫代碼運行必須編譯成IL 中間語言，IL是很規則，同時也很好反編譯。
反編譯防範措施：
設置項目代碼反匯編屬性
混淆
方法一：防止 Ildasm.exe（MSIL 反匯編程序） 反匯編程序集
方法很簡單在項目文件AssemblyInfo.cs中增加SuppressIldasm屬性。
效果很明顯，很難看出反編譯代碼所寫的真正邏輯。
缺點：
C#代碼通過混淆工具生成後，增加了很多轉換過程。這使得反編譯工具無法很直觀看到源碼真正邏輯。但源碼代碼過多轉換會使軟體本身運行效率降低，甚至會出現報錯情況。
『叄』 如何解決.NET程序容易被反編譯的問題
阻止不了,任何一個程序都可以被反編譯 當然了,並不是說反編譯以後就是源代碼 不知道你用的什麼語言,在.net里,一般都是用Dotfuscator之類的工具進行混淆干擾
.NET有一種加密位元組碼的方式是通過hook住JIT編譯器的入口來做的：位元組碼經過加密/混淆存在文件里，等被CLR載入了，某個方法要執行而需要被JIT編譯時，hook住JIT編譯器的入口攔截住這個編譯請求，然後去把對應的位元組碼解密之後再傳給JIT編譯器。
這種做法基本上只能唬唬小朋友，知道了原理之後很好解，可以輕松的獲取解密後的位元組碼然後扔給常規的反編譯器去處理。但現實的說，大部分用戶在「試圖解密」方面都是小朋友，所以倒也算是一種可行方案。
『肆』 C# dll 文件有什麼好的混淆工具防止反編譯
首先 C#沒有任何辦法反編譯其次 C#只能混淆代碼，起到一定的功效最後 C#混淆工具很多，VS自帶的並不強大，可以用些比如Dotfuscator、xeoncode、foxit等等
『伍』 vs2010 中的 Dotfuscator 能不能做成編譯出來的東西自動混淆
代碼混淆基本沒什麼用，可以被反編譯的。
最好的做法是結合非託管堆代碼實現如下兩個目的
一、不能看：.NET DLL可以包含託管堆代碼（可以被反編譯的）與非託管堆代碼（不能被反編譯，要反編譯也是更高層次的了，不在討范圍內），我們將核心邏輯代碼置於非托堆代碼中，由託管堆代碼提供介面供外部調用，調用時將非託管代碼通過.NET動態編譯特性編譯後返回執行結果。這樣就保證了不能看。
二、不能調：我們在非託管代碼中加入驗證調用者來源功能，判斷調用者的HASH值是不是與在非託管代碼中約定的HASH值(發布時需要提前生成相關引用者的HASH值存於非託管代碼，最後生成非託管代碼的DLL放於安裝包中)一致，如一致則通過執行返回結果，不一致則返回空。這樣就解決了非合法來源不能調的問題。
更多參考：http://www.cnblogs.com/dengxi/p/5750170.html
『陸』 c# 代碼加殼軟體或者混淆器哪個比較好，能防止反編譯的。跪求
現在最好的是
1.DNGuard HVM 這個是基於內核級別的加密。不會讓IL代碼被反編譯或被從內存中剝離。
2. IL Protected
這個兩個都比較好。其餘的都很垃圾，
————————————————————————————————————
Dotfuscator VS默認帶的工具，不過是個社區版 強度不大
dotNET Reactor 使用了NativeCode 和混淆的形式 ,可從內存中剝離
Xenocode Postbuild 專業工具，還是比較可以的，但是要看你怎麼用
{smartassembly}.Setup.msi 這個是 RedGate出品的，
————————————————————————————————————
除了我說的第一、第二個工具，你可以嘗試用其他的工具混淆加密，然後把你的測試程序發給我，我可以完美破解。都是親身測試過的。
『柒』 .net開發的exe安裝文件可以反編譯嗎
可以,用reflector 及其它
用混淆器加密及數字簽名,可擋掉大部分dll文件被人家反編譯．但魔高一尺,道高一丈, 要做到完全加密是很難的.
有些Dotfuscator防反編譯軟體可以參考, 但那些功能強大的Dotfuscator都是商業軟體，要花銀子買．
總之，不管你加密的如何好，只是延長破解和反編譯成可閱讀代碼的時間而以，所以不要放太多的精力在上面
『捌』 C#程序如何加密，不被反編譯
一般的企業為了保護知識產權，都是購買悶塵薯專業的加密軟體，多自己開發的程序進行加密，程螞者序被加密後就不能被反編譯了。還有一種比較普遍的方法是對代碼進行混淆，也是通過專業的軟體完成的，這類軟體包括dotfuscator等兄沖。
『玖』 為什麼用c#開發的程序可以被反編譯
因為C#開發的程序被編譯後並沒有成為可運行的二進制文件，而是一種中間狀態，是由MSIL語言寫成的程序文件。從理論上說，各種.NET語言只要完成的功能相似，編譯後的MSIL語言文件都是相似的，可見MSIL的代碼是對應著較為固定的高級語言結構的。所以，理論上，把MSIL語言進行返推，就可以將其反編譯為.NET中的任何一款高級語言。
『拾』 如何防止Unity3D代碼被反編譯
加密原理(無需Unity源碼):
1. IDA Pro打開libmono.so, 修改mono_image_open_from_data_with_name為
mono_image_open_from_data_with_name_0,
2. 替換實現mono_image_open_from_data_with_name,
extern mono_image_open_from_data_with_name_0(...);
mono_image_open_from_data_with_name(...) {
MonoImage *img = mono_image_open_from_data_with_name_0(...);
//發現數據文件頭不是DLL前綴則解密 img->raw_data, 相應修改img->raw_data_len
return img;
}
3. 重新打包libmono.so; 替換Unity3D中的android下的版本.
4. 另外寫個加密的工具，植入構建環境(MonoDeveloper或VS，添加一個打包後Build Phase來加密DLL); (IOS下禁用JIT固採用AOT編譯，DLL中沒有邏輯代碼，所以無需操心);
從AndroidManifest.xml中可以看出，騰訊的改造應該是修改並替換了入口的classes.dex，把以前的入口 UnityPlayerProxyActivity替換為com.tencent.tauth.AuthActivity. 然後去載入了自定義的幾個so: libNativeRQD.so. 周全考慮，為了防止第三方委託libmono去做解密而做了防護措施. 具體實現我還沒做深入分析, 應該也是老套路.
libmono.so中的mono_image_open_from_data_with_name也被替換成了mono_image_open_from_data_with_name_0.
解密(android):
方法一: ROOT android系統(最好是一部手機，別搞模擬器，慢死), 掛載LD_PRELOAD的API hook來實現.
方法二: 內存特徵碼提取，簡單高效無敵; 機器能讀，你就能讀;