如何解決.NET程序容易被反編譯的問題？

01-25

如何有效防止.NET程序被反編譯呢？具體的解決方案有哪些？

其實名字混淆在阻撓「人」去理解代碼意圖已經相當有效了。名字變了，理解意圖就需要花更多時間，如果破解意圖不強的話可能也就此不繼續搞了。

要更徹底的話，只有像.NET Native那樣的事先徹底編譯到native code的做法才比較靠譜。

其它做法都有比較直接的對應解法…

歡迎跟另一帖聯動：

請教：對Java類庫jar文件，有什麼好的防止反編譯辦法，最好是加密/解密方案，而不是代碼混淆方案。 - RednaxelaFX 的回答

以及：

如何理解ByteCode、IL、彙編等底層語言與上層語言的對應關係？ - RednaxelaFX 的回答

有空再添加一些反編譯的實現技巧的講解上去。

.NET有一種加密位元組碼的方式是通過hook住JIT編譯器的入口來做的：位元組碼經過加密/混淆存在文件里，等被CLR載入了，某個方法要執行而需要被JIT編譯時，hook住JIT編譯器的入口攔截住這個編譯請求，然後去把對應的位元組碼解密之後再傳給JIT編譯器。

這種做法基本上只能唬唬小朋友，知道了原理之後很好解，可以輕鬆的獲取解密後的位元組碼然後扔給常規的反編譯器去處理。但現實的說，大部分用戶在「試圖解密」方面都是小朋友，所以倒也算是一種可行方案。

關於JIT hooking的一些資料和工具：

.NET Internals and Code Injection

UbbeCode | Tag jit-hook

Category:.NET MSIL Dumpers

還是SaaS吧。。。代碼在服務端。。。完美。

基於.Net實現一個虛擬機，然後自己寫一門語言，用自己的compiler編譯bytecode，然後放到虛擬機上跑就好了。如果配合.Net Native使用就更加安全。由於你的虛擬機指令集以及compiler不開源，此方法的安全系數最高。

其次就是單純的使用.Net Native，但是對熟悉反彙編的人來說並不難操作，畢竟x86下太多現成的動態反彙編和調試工具了。

至於混淆嘛。。根本不痛不癢，一點作用都沒有。能看到的代碼照樣看得到，只是變量名變了，代碼結構紋絲不動。

1.見過某系統用了vmp的殼，至少以我的能力是真找不出方法獲得源碼了

2.SmartAssembly 紅門家的混淆工具，混淆後的代碼連de4dot都反不回來

基於「防止反編譯」就是為了防止獲取源碼，想到了兩種方式