用什麼開發的軟體不被反編譯

❶ 如何讓C++寫的dll不被反編譯

簡單回答：
1、理論上不能保證程序不被反編譯。
2、一些加殼軟體可以做到加大被反編譯的難度，迫使操作者先解殼才能做反編譯，但同時會降低程序的運行效率。
3、當前的技術條件下，一般而言，反編譯出的「源代碼」一般而言並不能作學習，參考的源代碼，多數情況下只能用於分析區部片斷分析，主要用於破解或小范圍類修改。
4、一些簡單的加殼軟體：ASPACK、UPX、PECompact等，如果想嘗試，自個去搜索下載後試試。加殼後的軟體還有可能被某些殺軟當成惡意軟體。
5、這也正是很多對安全要求高的系統使用「三層架構」（類似訪問網頁/網站）的原因。因為在三層架構中，核心軟體、數據不被用戶直接接觸。

************以下是相關知識，有耐心可看看************
一、關於反編譯與破解。
1、以當前的技術來說，理論上，所有的程序都存在被反編譯的可能。
2、但是反編譯出來的代碼並不一定能被技術不高的人看懂，因為反編譯出來的「源代碼」與編寫者寫出的原代碼在80%以上是不同的。這是因為反編譯的原理是根據機器碼（或中間碼），讓機算機進行反向生成高級語言，而不是找出編寫者原有的代碼，找出原有的代碼是不可能的。反編譯出來的代碼在可理解性、可閱讀性上，一般而言是非常差的。
3、但是，這並不代碼反編譯出來的「源代碼」沒有價值，對於內行來說，分析反編譯出來的代碼中的某些特定片段，就可以對程序進行破解，找出程序的關鍵點、口令、數據來源等等。因為破壞總是比建設要容易，分析局部比規劃全局要容易得多。
4、如果考慮到被反編譯將關鍵代碼進行特殊處理的話，可能加大相關的難度，比如將特定的字元串分成多個字串在程序中存儲，或是進行加密後存儲，在使用時合成/生成，不用時即時在內存中清除等等……。
5、反編譯後對關鍵部分的定位往往是根據字元串來進行的，比如在用戶沒有注冊時，跳出一行對話，告訴用戶「請注冊後再使用」，破解者就會在反編譯後追查這個字串所在，然後查到這個字串對應的變數與地址，再追查調用這個變數或地址的代碼，然後再延伸查到什麼情況下調用「調用這個變數或地址的代碼」，最後，設定跳過語句。這就是最典型的破解注冊的方法。破解完再將修改了的「源代碼」進行編譯，或是根據「源代碼」直接修正程序中對應的代碼，OK，破解版正式完成。
二、關於加殼。
1、理論上，同樣，沒有破解不了的殼。
2、但是有些加殼軟體使用了一些特別的方法，使得破解殼的難度變得非常難，技術不夠的朋友很難下手，比如將原程序代碼拆分、變型、植入自校驗等等技術。
3、但加殼軟體同樣是程序，它自身就存在被反編的可能，加了殼可以類比成，在一個木箱外面再加個保險櫃。但千萬別以為保險櫃就一定是保險的，面對各種技術開鎖、暴力開箱，再強的保險櫃也只能是加大難度而已。
4、越復雜的加殼，就會使得程序運行時效率降得越低，這是必然的，因為原本只關注目標任務的程序現在還要時時提防著被提取、被監測。

❷ 如何有效的防止java程序被反編譯和破解

由於Java位元組碼的抽象級別較高，因此它們較容易被反編譯。下面介紹了幾種常用的方法，用於保護Java位元組碼不被反編譯。通常，這些方法不能夠絕對防止程序被反編譯，而是加大反編譯的難度而已，因為這些方法都有自己的使用環境和弱點。
1.隔離Java程序
最簡單的方法就是讓用戶不能夠訪問到Java Class程序，這種方法是最根本的方法，具體實現有多種方式。例如，開發人員可以將關鍵的Java Class放在伺服器端，客戶端通過訪問伺服器的相關介面來獲得服務，而不是直接訪問Class文件。這樣黑客就沒有辦法反編譯Class文件。目前，通過介面提供服務的標准和協議也越來越多，例如 HTTP、Web Service、RPC等。但是有很多應用都不適合這種保護方式，例如對於單機運行的程序就無法隔離Java程序。
2.對Class文件進行加密
為了防止Class文件被直接反編譯，許多開發人員將一些關鍵的Class文件進行加密，例如對注冊碼、序列號管理相關的類等。在使用這些被加密的類之前，程序首先需要對這些類進行解密，而後再將這些類裝載到JVM當中。這些類的解密可以由硬體完成，也可以使用軟體完成。
在實現時，開發人員往往通過自定義ClassLoader類來完成加密類的裝載(注意由於安全性的原因，Applet不能夠支持自定義的ClassLoader)。自定義的ClassLoader首先找到加密的類，而後進行解密，最後將解密後的類裝載到JVM當中。在這種保護方式中，自定義的ClassLoader是非常關鍵的類。由於它本身不是被加密的，因此它可能成為黑客最先攻擊的目標。如果相關的解密密鑰和演算法被攻克，那麼被加密的類也很容易被解密。
3.轉換成本地代碼
將程序轉換成本地代碼也是一種防止反編譯的有效方法。因為本地代碼往往難以被反編譯。開發人員可以選擇將整個應用程序轉換成本地代碼，也可以選擇關鍵模塊轉換。如果僅僅轉換關鍵部分模塊，Java程序在使用這些模塊時，需要使用JNI技術進行調用。當然，在使用這種技術保護Java程序的同時，也犧牲了Java的跨平台特性。對於不同的平台，我們需要維護不同版本的本地代碼，這將加重軟體支持和維護的工作。不過對於一些關鍵的模塊，有時這種方案往往是必要的。為了保證這些本地代碼不被修改和替代，通常需要對這些代碼進行數字簽名。在使用這些本地代碼之前，往往需要對這些本地代碼進行認證，確保這些代碼沒有被黑客更改。如果簽名檢查通過，則調用相關JNI方法。
4.代碼混淆
代碼混淆是對Class文件進行重新組織和處理，使得處理後的代碼與處理前代碼完成相同的功能(語義)。但是混淆後的代碼很難被反編譯，即反編譯後得出的代碼是非常難懂、晦澀的，因此反編譯人員很難得出程序的真正語義。從理論上來說，黑客如果有足夠的時間，被混淆的代碼仍然可能被破解，甚至目前有些人正在研製反混淆的工具。但是從實際情況來看，由於混淆技術的多元化發展，混淆理論的成熟，經過混淆的Java代碼還是能夠很好地防止反編譯。下面我們會詳細介紹混淆技術，因為混淆是一種保護Java程序的重要技術。

❸ app防破解方法，防止APK程序反編譯怎麼做，目前有什麼好用方法

防破解是個熱門話題，最近很多熱門的應用都用了採用了第三方的加密服務，畢竟現在通用的加密方法都是很容易被破解的。像史上最坑爹游戲、美食傑、這些熱門都用了一個叫愛加密的第三方加密服務，可以防止這個apk反編譯，代碼注入，山寨盜版的行為。你自己去查一下吧，希望有幫助

❹ .net軟體,用什麼軟體加密狗加密,能防止代碼反編譯

.Net軟體的特點,一些強大的編譯工具可以對.Net可執行文件進行反編譯操作,並得出相應的IL代碼甚至是源代碼。即使是採用混淆工具以及強命名工具也不能從根本上解決問題,代碼依然會很容易地被Reflectoer等工具反編譯源代碼。
軟體加密狗：威步(WIBU)的CodeMeter,AxProtector(for.net)兩款軟體加密狗性能非常不錯
反編譯的問題,與傳統的代碼混淆工具（Obfuscator）不同,AxProtector可以完全阻止對.NET
程序集（由
C#,
VB.NET,
Delphi.NET,
ASP.Net…
等語言編寫）的反編譯。通俗的講,AxProtector在破解者和您的
.NET
代碼之間構建了強大的防破解保護屏障,生成一個基於
Windows
的而不是基於
MSIL
的兼容格式文件。原始的
.NET
代碼完整的被加密後封裝在本地代碼內,無論何時都不會釋放到硬碟,對於破解者是不可見的。
與單純的.net加密軟體不同,AxProtector與CodeMeter硬體加密狗配套餐使用,採用了更為嚴密的密鑰管理,及最先進的AES、RSA、ECC等加密演算法存儲或傳輸密鑰,保證通訊安全。
.Net代碼編譯後生成的
.class
中包含有源代碼中的所有信息（不包括注釋）,尤其是在其中保存有調試信息的時候。所以一個按照正常方式編譯的.class
文件可以非常輕易地被反編譯。一般軟體開發商會採用一種叫做混淆器的工具。混淆器的作用是對編譯好的代碼進行混淆,使得其無法被反編譯或者反編譯後的代碼混亂難懂。由於混淆器只是混淆了方法名稱或流程,而不能防止源代碼被反編譯,因此混淆器的作用只是增加了反編譯的難度,最終的結果也是治標不治本。對於一些掌握工具的人來說幾乎還是透明的。AxProtector是一款真正意義的加密源代碼、防止反編譯的.net軟體加密軟體。
AxProtector加密了.net原代碼,任何時候原代碼都不可能被還原到硬碟當中。採用AxProtector加密後的.net代碼只有在程序調用或執行某一段函數的時候,才能通過AxProtectorClass在內存中解密後返回到程序中執行,運行之後迅速立即加密。這種隨機加密、按需解密原代碼的功能,能很好的防止.Net程序的反編譯,同時能夠很好地防止API加密點被摘除。有效地保證了源代碼的執行效率和安全性。

❺ 怎麼防止開發出來的程序被別人反編譯

1.本地數據加密
iOS應用防反編譯加密技術之一：對NSUserDefaults，sqlite存儲文件數據加密，保護帳號和關鍵信息
2.URL編碼加密
iOS應用防反編譯加密技術之二：對程序中出現的URL進行編碼加密，防止URL被靜態分析
3.網路傳輸數據加密
iOS應用防反編譯加密技術之三：對客戶端傳輸數據提供加密方案，有效防止通過網路介面的攔截獲取數據
4.方法體，方法名高級混淆
iOS應用防反編譯加密技術之四：對應用程序的方法名和方法體進行混淆，保證源碼被逆向後無法解析代碼
5.程序結構混排加密
iOS應用防反編譯加密技術之五：對應用程序邏輯結構進行打亂混排，保證源碼可讀性降到最低

❻ 防止自己的APP被反編譯或破解，通常有哪些方法

混淆代碼：
Android APP的源碼進行混淆後混淆器將代碼中的所有變數、函數、類的名稱加密為簡短的英文字母代號，在APP被破解後增加破解者對代碼的閱讀難度。 但是混淆的功效只能運作在APP已經被破解後，而且只是增加破解者的難度時間，對其防止破解的作用意義不是很大。
防二次打包：
二次打包是指將APK拆包後重新打包，二次打包必將丟失原有的簽名。大多數的Android開發者都是將簽名信息作為認證標准，所以只要原有的簽名信息改變，APK就無法正常運行。但是如果將這個認證信息功能屏蔽掉，防二次打包就失效了！
我們先通過APK安全保護平台，對這款Android APK進行安全保護。
步驟如下：
登錄/注冊→上傳APK→等待系統加密→完成後下載APK→給APK簽名→完成！

注意：
在APK源代碼安全保護平台，個人信息要填寫完整，否則無法正常使用。APK加密完成後，系統會發出郵件通知加密完成。最後下載APK包再次完成簽名，就可以正常使用了!

❼ c# 代碼加殼軟體或者混淆器哪個比較好，能防止反編譯的。跪求

現在最好的是
1.DNGuard HVM 這個是基於內核級別的加密。不會讓IL代碼被反編譯或被從內存中剝離。

2. IL Protected

這個兩個都比較好。其餘的都很垃圾，

————————————————————————————————————

Dotfuscator VS默認帶的工具，不過是個社區版 強度不大

dotNET Reactor 使用了NativeCode 和混淆的形式 ,可從內存中剝離

Xenocode Postbuild 專業工具，還是比較可以的，但是要看你怎麼用

{smartassembly}.Setup.msi 這個是 RedGate出品的，

————————————————————————————————————

除了我說的第一、第二個工具，你可以嘗試用其他的工具混淆加密，然後把你的測試程序發給我，我可以完美破解。都是親身測試過的。

❽ C#如何防止被別人反編譯

C#
編寫的代碼通過VS編譯器生成
dll
或
exe
，很容易被一些反編譯工具查看到源碼或對源碼進行修改。
為防止代碼被反編譯或被篡改，我們可以進行一定的防範措施。但不能杜絕，因為DotNet編寫代碼運行必須編譯成IL
中間語言，IL是很規則，同時也很好反編譯。
反編譯防範措施：
設置項目代碼反匯編屬性
混淆
方法一：防止
Ildasm.exe（MSIL
反匯編程序）
反匯編程序集
方法很簡單在項目文件AssemblyInfo.cs中增加SuppressIldasm屬性。
當項目中增加SuppressIldasm屬性後在使用ildasm.exe反編譯代碼，會提示:"受保護的模塊
--
無法進行反匯編"
ildasm.exe
讀取項目中包含
SuppressIldasm
屬性就不對此程序集進行反編譯。但ILSyp，Reflector等反編譯工具針對程序集設置SuppressIldasm屬性置之不理，一樣可以反編譯源碼。
缺點：
可見SuppressIldasm
屬性只針對ildasm.exe工具起效果，同時也能刪除ildasm.exe工具的此項限制。參考：《去掉ILDasm的SuppressIldasmAttribute限制》
方法二：混淆
混淆原理：將VS編譯出的文件(exe
或
dll)通過ildasm對文件進行重命名,字元串加密，移動等方式將原始代碼打亂。這種方式比較常見。
VS2013
自帶混淆工具：工具-->PreEmptive
Dotfuscator
and
Analytics
但VS2013自帶Dotfuscator
5.5
需購買激活才能使用全部功能。目前網路提供
DotfuscatorPro
4.9
破解版版本下載。
打開
DotfuscatorPro
4.9
主界面
Settings->Global
Options
全局配置
常用功能配置：Disable
String
Encryption=NO
啟用字元串加密
選擇需混淆C#編譯代碼(dll
或
exe)
其中Library不要勾選，否則有些類、變數等等不會混淆；
Rename
重命名配置
常用功能配置：
勾選
=
use
enhanced
overload
inction
使用增強模式
重命名方案
Renaming
Scheme
=
Unprintable
（不可列印字元，即亂碼），也可以選擇其他如小寫字母、大寫字元、數字的方式。
String
Encryption
字元串加密
勾選需要加密字元串文件(exe
或
dll)
可根據各自需求可進行其他相關配置。（如：control
flow,Output,Setting
->Build
Settings,Settings
-->
Project
Properties等）
最後生成混淆文件
Build
Project。
Build
Project
生成混淆項目錯誤：
Could
not
find
a
compatible
version
of
ildasm
to
run
on
assembly
C:Users***.exe.??This
assembly
was
originally
built
with
.NET
Framework
v4.0.30319.
Build
Error.
處理方法:
ILASM_v4.0.30319
=
C:WindowsMicrosoft.NETFrameworkv4.0.30319ilasm.exe
ILDASM_v4.0.30319
=
C:Program
Files
(x86)Microsoft
SDKsWindowsv8.1AinNETFX
4.5.1
Toolsildasm.exe
[安裝VS版本不同對應目錄會有所變化]
混淆代碼對比
未使用混淆工具，反編譯出的源碼：
使用混淆工具，反編譯出的源碼：
效果很明顯，很難看出反編譯代碼所寫的真正邏輯。
缺點：
C#代碼通過混淆工具生成後，增加了很多轉換過程。這使得反編譯工具無法很直觀看到源碼真正邏輯。但源碼代碼過多轉換會使軟體本身運行效率降低，甚至會出現報錯情況。

❾ 如何防止程序員反編譯

Java從誕生以來，其基因就是開放精神，也正因此，其可以得到廣泛愛好者的支持和奉獻，最終很快發展壯大，以至於有今天之風光！但隨著java的應用領域越來越廣，特別是一些功能要發布到終端用戶手中（如Android開發的app），有時候，公司為了商業技術的保密考慮，不希望這裡面的一些核心代碼能夠被人破解（破解之後，甚至可以被簡單改改就發布出去，說嚴重點，就可能會擾亂公司的正常軟體的市場行為），這時候就要求這些java代碼不能夠被反編譯。

這里要先說一下反編譯的現象。因為java一直秉持著開放共享的理念，所以大家也都知道，我們一般共享一個自己寫的jar包時，同時會共享一個對應的source包。但這些依然與反編譯沒有什麼關系，但java的共享理念，不只是建議我們這樣做，而且它自己也在底層上「強迫」我們這么做！在java寫的.java文件後，使用javac編譯成class文件，在編譯的過程，不像C/C++或C#那樣編譯時進行加密或混淆，它是直接對其進行符號化、標記化的編譯處理，於是，也產生了一個逆向工程的問題：可以根據class文件反向解析成原來的java文件！這就是反編譯的由來。

但很多時候，有些公司出於如上述的原因考慮時，真的不希望自己寫的代碼被別人反編譯，尤其是那些收費的app或桌面軟體（甚至還有一些j2ee的wen項目）！這時候，防止反編譯就成了必然！但前面也說過了，因為開放理念的原因，class是可以被反編譯的，那現在有這樣的需求之後，有哪些方式可以做到防止反編譯呢？經過研究java源代碼並進行了一些技術實現（結果發現，以前都有人想到過，所以在對應章節的時候，我會貼出一些寫得比較細的文章，而我就簡單闡述一下，也算偷個懶吧），我總共整理出以下這幾種方式：

代碼混淆

這種方式的做法正如其名，是把代碼打亂，並摻入一些隨機或特殊的字元，讓代碼的可讀性大大降低，「曲線救國」似的達到所謂的加密。其實，其本質就是打亂代碼的順序、將各類符號（如類名、方法名、屬性名）進行隨機或亂命名，使其無意義，讓人讀代碼時很累，進而讓人乍一看，以為這些代碼是加過密的！

由其實現方式上可知，其實現原理只是擾亂正常的代碼可讀性，並不是真正的加密，如果一個人的耐心很好，依然可以理出整個程序在做什麼，更何況，一個應用中，其核心代碼才是人們想去了解的，所以大大縮小了代碼閱讀的范圍！

當然，這種方式的存在，而且還比較流行，其原因在於，基本能防範一些技術人員進行反編譯（比如說我，讓我破解一個混淆的代碼，我寧願自己重寫一個了）！而且其實現較為簡單，對項目的代碼又無開發上的侵入性。目前業界也有較多這類工具，有商用的，也有免費的，目前比較流行的免費的是：proguard（我現象臨時用的就是這個）。

上面說了，這種方式其實並不是真正加密代碼，其實代碼還是能夠被人反編譯（有人可能說，使用proguard中的optimize選項，可以從位元組流層面更改代碼，甚至可以讓JD這些反編譯軟體可以無法得到內容。說得有點道理，但有兩個問題：1、使用optimize對JDK及環境要求較高，容易造成混淆後的代碼無法正常運行；2、這種方式其實還是混淆，JD反編譯有點問題，可以有更強悍的工具，矛盾哲學在哪兒都是存在的^_^）。那如何能做到我的class代碼無法被人反編譯呢？那就需要我們下面的「加密class」！

加密class

在說加密class之前，我們要先了解一些java的基本概念，如：ClassLoader。做java的人已經或者以後會知道，java程序的運行，是類中的邏輯在JVM中運行，而類又是怎麼載入到JVM中的呢（JVM內幕之類的，不在本文中闡述，所以點到為止）？答案是：ClassLoader。JVM在啟動時是如何初始化整個環境的，有哪些ClassLoader及作用是什麼，大家可以自己問度娘，也不在本文中討論。

讓我們從最常見的代碼開始，揭開一下ClassLoader的一點點面紗！看下面的代碼：

Java代碼

• publicclassDemo{

• publicstaticvoidmain(String[]args){

• System.out.println(「helloworld!」);

• }

• }

上面這段代碼，大家都認識。但我要問的是：如果我們使用javac對其進行編譯，然後使用java使其運行（為什麼不在Eclipse中使用Runas功能呢？因為Eclipse幫我們封閉，從而簡化了太多東西，使我們忽略了太多的底層細節，只有從原始的操作上，我們才能看到本質），那麼，它是怎麼載入到JVM中的？答案是：通過AppClassLoader載入的（相關知識點可以參考：http://hxraid.iteye.com/blog/747625）！如果不相信的話，可以輸出一下System.out.println(Thread.currentThrea().getContextLoader());看看。

那又有一個新的問題產生了：ClassLoader又是怎樣載入class的呢？其實，AppClassLoader繼承自java.lang.ClassLoader類，所以，基本操作都在這個類裡面，讓我們直接看下面這段核心代碼吧：





看到這里，已經沒有必要再往下面看了（再往下就是native方法了，這是一個重大伏筆哦），我們要做的手腳就在這里！

手腳怎麼做呢？很簡單，上面的代碼邏輯告訴我們，ClassLoader只是拿到class文件中的內容byte[]，然後交給JVM初始化！於是我們的邏輯就簡單了：只要在交給JVM時是正確的class文件就行了，在這之前是什麼樣子無所謂！所以，我們的加密的整個邏輯就是：

• 在編譯代碼時（如使用ant或maven），使用插件將代碼進行加密（加密方式自己選），將class文件裡面的內容讀取成byte[]，然後進行加密後再寫回到class文件（這時候class文件裡面的內容不是標準的class，無法被反編譯了）

• 在啟動項目代碼時，指定使用我們自定義的ClassLoader就行了，而自定義的部分，主要就是在這里做解密工作！

如此，搞定！以上的做法比較完整的闡述，可以仔細閱讀一下這篇文章：https://www.ddtsoft.com/#developerworks/cn/java/l-secureclass/文章中的介紹。

通過這個方法貌似可以解決代碼反編譯的問題了！錯！這里有一個巨大的坑！因為我們自定義的ClassLoader是不能加密的，要不然JVM不認識，就全歇菜了！如果我來反編譯，呵呵，我只要反編譯一下這個自定義的ClassLoader，然後把裡面解密後的內容寫到指定的文件中保存下來，再把這個加了邏輯的自定義ClassLoader放回去運行，你猜結果會怎樣？沒錯，你會想死！因為你好不容易想出來的加密演算法，結果人家根本不需要破解，直接就繞過去了！

現在，讓我們總結一下這個方法的優缺點：實現方式簡單有效，同時對代碼幾乎沒有侵入性，不影響正常開發與發布。缺點也很明顯，就是很容易被人破解！

當然啦，關於缺點問題，你也可以這么干：先對所有代碼進行混淆、再進行加密，保證：1、不容易找到我們自定義的那個ClassLoader；2、就算找到了，破解了，代碼可讀性還是很差，讓你看得吐血！（有一篇文章，我覺得寫得不錯，大家可以看一看：http://www.scjgcj.com/#blog/851544）

嗯，我覺得這個方法很好，我自己也差點被這個想法感動了，但是，作為一個嚴謹的程序員，我真的不願意留下一個隱患在這里！所以，我繼續思索！

高級加密class

前面我們說過有個伏筆來著，還記得吧？沒錯，就是那個native！native定義的方法是什麼方法？就是我們傳說中的JNI調用！前面介紹過的有一篇文章中提到過，其實jvm的真實身份並不是java，而是c++寫的jvm.dll（windows版本下），java與dll文件的調用就是通過JNI實現的！於是，我們就可以這樣想：JNI可以調用第三方語言的類庫，那麼，我們可不可以把解密與裝載使用第三方語言寫（如C++，因為它們生成的庫是不好反編譯的），這樣它可以把解密出來的class內容直接調jvm.dll的載入介面進行初始化成class，再返回給我們的ClassLoader？這樣，我們自定義的ClassLoader只要使用JNI調用這個第三方語言寫的組件，整個解密過程，都在黑盒中進行，別人就無從破解了！

嗯，這個方法真的很不錯的！但也有兩個小問題：1.使用第三方語言寫，得會第三方語言，我說的會，是指很溜！2.對於不同的操作系統，甚至同一操作系統不同的版本，都可能要有差異化的代碼生成對應環境下的組件（如window下是exe，linux是so等）！如果你不在乎這兩個問題，我覺得，這個方式真的挺不錯的。但對於我來說，我的信條是，越復雜的方式越容易出錯！我個人比較崇尚簡潔的美，所以，這個方法我不會輕易使用！

對了，如果大家覺得這個方法還算可行的話，可以推薦一個我無意中看到的東西給大家看看（我都沒有用過的）：jinstall，

更改JVM

看到這個標題，我想你可能會震驚。是的，你沒看錯，做為一個程序員，是應該要具有懷疑一切、敢想敢做的信念。如果你有意留心的話，你會發現JVM版本在業界其實也有好幾個版本的，如：Sun公司的、IBM的、Apache的、Google的……

所以，不要阻礙自己的想像力，現在沒有這個能力，並不代表不可能。所以，我想到，如果我把jvm改了，在裡面對載入的類進行解密，那不就可以了嗎？我在設計構思過程中，突然發現：人老了就是容易糊塗！前面使用第三方語言實現解密的兩個問題，正好也是更改JVM要面對的兩個問題，而且還有一個更大的問題：這個JVM就得跟著這個項目到處走啊！