首先我們來看看Java程序的反加密，也就是通常所說的Crack過程，只有明白了這個過程，我們才能有效的對我們的程序進行加密。
通常我們得到的Java程序的Crack包有兩種，一種屬于KeyGen（注冊碼生成器）、一種屬于替換修改；
我們先看第一種，當我們找到一個應用程序的KeyGen的時候我們總是很佩服那個做出KeyGen的人，覺得他很厲害，但是你仔細分析一下，為什么他能做出KeyGen呢？只有
他對這個Java程序的加密算法了解的非常清楚；這種人有哪些呢？一個是那個公司里面的人，那不可能，除非內訌，還又呢，就是猜想，反推，這個可能嗎？呵呵，更不可能，那這個算法從哪里來呢？呵呵，往往泄漏秘密的就是秘密本身……回過頭來想想，Java應用程序怎么知道你輸入的注冊碼是否正確呢？呵呵，那你就該從應用程序入手……
得到的它的加密算法，自然KeyGen就不在話下了……（但是這也有列外，如果它是用的公鑰秘鑰對加密的，就沒有辦法嘍，只能用第二種方法。）
這種辦法只適合對付只要一個注冊號，別的什么都不要的情況，經典代表Borland JBuilder & Optimizeit Suite
再看第二種，為什么要用替換修改？我們是修改了那部分呢？不用想，肯定是License驗證的部分，為什么我們不像上面的方法那樣找加密算法呢？原因有兩種：（1）使用上面的辦法搞不定；（2）Java程序不僅要Key，還有其他的License配置；遇到這種情況，我們只要找到用于License驗證的類，進行修改替換就行了。
這種辦法使用于任何情況，經典代表BEA WebLogic
經過上面的分析，我們的問題就集中了，關鍵就是怎么找到用于License驗證的部分或加密算法的部分，我們需要3個工具：一個是Sun公司提供的標準JVM：），一個是你
的耐心和細心：），一個是Jad（經典Java反編譯工具）。
第一步是定位，這也是最關鍵的一步，我們這里以Together For JBuilder Edition為例，啟動Together，先看看長什么樣子？喔，上來就問我要License；Ok，
每關系，退出；找到Together的啟動Bat文件，找到它的啟動命令：java .....，OK，在Java啟動的時候給一個參數：“ -Xrunhprof:cpu=times”，保存，在啟動，還是要
License，退出，這個時候，我們可以發現，在這個目錄下多了一個“java.hprof.txt”文件，打開一看，就是我要的JVM的Dump文件，好多內容啊，沒關系，慢慢看來。
我們可以看見這個文件里面有好多熟悉的東西?。簀ava.*/com.sun.*/javax.*等等，但這個不是我們關心的，我們要的是com.togethersoft.*或者是一些沒有包名的zd.d等等。（這里插一句，幾乎所有的Java應用程序都會混淆的，其實混淆的原理也很簡單，我們后面再說。）先找找有沒有License有關的，Serach一下，嘿嘿，果然，474行：com.togethersoft.together.impl.ide.license.LicenseSetup.execute([DashoPro-V2-050200]:Unknown line)，Ok上那堆classpath中的Jar包里面找一下吧（推薦用WinRAR），找到了之后用Jad反編譯，一看，這個沒有混淆，但是用了一個zae的類，這個看名字就知道混淆過了，先不理它，再看看下面一句IdeLicenseAccess.setLicense(zae1)，Ok接著找到IdeLicenseAccess，哈哈，就這點名堂，所有的License驗證都是走的這個類，面向對象的思想不錯，呵呵：）
定位定完了，接下來的事情就是按猜想的方法修改這兩個類，屏蔽掉LicenseSetup里面execute方法的實際內容，修改IdeLicenseAccess，讓多有的驗證都返回true，然后編譯，替換；不要高興太早，這還沒有完呢，要有責任心?。覶ogether，果然，這下不要License了，有啟動畫面，進去了，但是一片灰色，怎么回事，一看控制臺，一堆錯，沒關系，就怕不出錯，查找根源，還有一個IdeLicenseUtil類出了問題，再反編譯，修改，替換；這下搞定了。再啟動，測試一下，OK MB7-222 70-210 1Y0-327 。
就這樣，一個Java應用程序搞定了?？纯雌鋵嵰埠芎唵巍?/p>
再來說說混淆，大家可能都知道沒有經過混淆的Java的Class反編譯回來連方法和變量的名字都不會變，這是什么原因呢？這就要追述到Class文件的結構了，簡單來說，Class文件種包含又一個常數池（constant pool）這個里面就存放了變量和方法的名稱等一下和Class相關的東西，我們通常所說的混淆就是用一種工具把這個常數池里面的東東弄的胡涂一點，這樣就能騙過反編譯器和你，呵呵：）這就是為什么有時候反編譯回來的東西編譯不過去的原因。
再回過頭來說說Java程序的加密；從上面的兩種方法來看，Java程序似乎是沒有什么完美的辦法進行加密的，其實不然，我們必須遵循一些原則，才能有效的保護你的產品。
原則一，盡量使用公鑰和秘鑰對進行加密；
原則二，不要在加密驗證的部分使用面向對象思想：）把驗證的方法寫在程序的各個角落，并標注為private final void，讓編譯器替你處理成內聯方法；
原則三，盡可能的大幅度混淆：）找個好點的混淆器