java 代碼混淆 用什么命令

Jocky的下載和配置

我們提供的服務有：做網(wǎng)站、成都做網(wǎng)站、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認證、紅河ssl等。為1000+企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務，是有科學管理、有技術的紅河網(wǎng)站制作公司

OperaMasks上的下載鏈接已經(jīng)失效，請移步CSDN自行搜索下載

1、下載完成后解壓得到名為org.apusic.jocky_1.0.3的文件夾，把這個文件夾放到eclipse根目錄的plugins文件夾下(myeclipse和eclipse同理)。

2、重啟eclipse，右鍵一個工程文件，出現(xiàn)Jocky選項說明OK。

3、一般是先進行設置-Jocky Settings，然后進行Jocky Now!。以下是settings界面

Enable Jocky多選框選中

Jocky build file是在項目創(chuàng)建一個xml文件，根據(jù)里面的配置進行混淆

Scramble level是進行混淆的代碼等級，有none、private、package、protected、public、all，將根據(jù)設置對java文件中的相應修飾符修飾的方法代碼進行混淆

Target VM是java虛擬機的版本，有1.4和1.5，一般選擇1.5

Output directory是輸出文件夾，在項目根目錄下

點擊確認會自動根據(jù)項目的設置生成xml文件

4、jocky_build.xml，實際上是一個ant build文件，由系統(tǒng)自動生成，有幾處需要說明

pathelement location="bin"/ pathelement location="XXX.jar"/這類標簽代表項目編譯所需的jar包，由于是自動生成一般不用理睬，如果出現(xiàn)找不到相關的package之類的報錯，那么有可能是location路徑有問題。如果你安裝系統(tǒng)時是用戶名設置成了中文名，并且使用了maven，maven的jar包的下載路徑設置成了默認${user}/.m2/repository/，那么jocky這里的路徑會出現(xiàn)問題，中文名的用戶名會亂碼或者消失，請修改maven配置xml文件修改下載路徑localRepository[自己指定的路徑]/localRepository 。

javac destdir="${jocky.output.dir}/bin" target="${target}" encoding="UTF-8" 代碼中如果有中文名，必須手動設定編碼，默認是沒有的。

src path="src"/ 設定源文件的目錄，因為有時候我們只想輸出src目錄下的部分包而不是全部。

如何分析經(jīng)過混淆后的java代碼

混淆代碼 是為了防止class文件被反編譯用的 但是程序的功能還是正常的 和你正常運行一樣

如果連變量名都混淆了，就是說所有有具體意義的英文變量名都用a,b,c,x,y等等來表示，那這是不可能還原的，因為電腦也不可能知道你這個a實際上代表了你的年齡而那個c代表了你老婆的胸圍！

但如果只是個事混淆，那網(wǎng)上倒有不少工具可以格式化源代碼！自己搜一搜吧！推薦一款編輯器，IntelliJ，很不錯，值得一提的是，我用過的眾多編輯器中，這款編輯器的代碼格式化功能最強大！

求教Java web項目一般怎樣做代碼混淆或加密

一、java web項目混淆

proguard4.8工具，說是支持war的，可混淆過后少了classes目錄了，自然成功不了。網(wǎng)上搜的過程不詳說了，最后找著－－“J2EE-web工程ProGuard代碼混淆07_28”，網(wǎng)址：

根據(jù)提示一步步完成。

把web項目打成jar包后用proguard進行混淆，然后把混淆過后的class目錄替換發(fā)布包war中的對應目錄，啟動運行是正常的。

主要注意利用proguard生成xxx.pro文件，然后手動加工-keep class WebRoot.WEB-INFO.lib.* 等項目中不需要混淆的包和類。

二、java web項目打成.exe

沒找到免費的，這搜到個收費的－－Jinstall，試了下功能挺好，

可以加密、集成jdk、tomcat，如果數(shù)據(jù)庫是mysql也集成，其他數(shù)據(jù)庫的話要設置數(shù)據(jù)庫的url.

代碼反平庸嗎？

代碼反混淆（deobfuscation）和代碼混淆（obfuscation）對應，是其逆過程。維基百科將代碼混淆定義為故意生成人類難以理解的源代碼或機器碼的過程（"In software development, obfuscation is the deliberate act of creating source or machine code that is difficult for humans to understand."）。代碼反混淆可以理解為將原本人類難以理解的代碼轉(zhuǎn)化為簡單的、可理解的、直觀的代碼的過程。

這篇文章主要介紹一下

"Big Code" 在代碼反混淆領域的應用。更具體一點就是介紹一下提出 "JSNice" 和 "Deguard"

的兩篇文章，這兩篇文章雖然已經(jīng)發(fā)表快五年了，但至今沒有文章Follow這兩份工作，因為文章已經(jīng)將使用 "Big Code"

做代碼命名反混淆做到了極致。后來的人無法在這個問題上推陳出新，脫穎而出。

"Big Code"： 代碼托管網(wǎng)站如GitHub上的大量免費可用的高質(zhì)量代碼被稱為 "Big Code" ，這些數(shù)據(jù)結(jié)合統(tǒng)計推理或深度學習為新興的開發(fā)工具的出現(xiàn)提供了契機。

概率圖模型：概率圖模型是用圖來表示變量概率依賴關系的理論，結(jié)合概率論與圖論的知識，利用圖來表示與模型有關的變量的聯(lián)合概率分布。

問題

為了項目的安全，開發(fā)者在打包發(fā)布項目時會對代碼進行混淆加密，包括但不限于用無意義的短變量去重命名類、變量、方法，以免代碼被輕易破解泄露。另外由于JS腳本主要用于Web開發(fā)，對其進行混淆還能壓縮腳本的大小，使得瀏覽器下載、加載更加快速，提升用戶的瀏覽體驗。

這一類通過對類、變量、方法重命名的混淆方案確實能加大其他開發(fā)者對代碼的理解難度。其他開發(fā)者不干了，為了能方便理解他人混淆后的代碼，學習（抄襲）他人的經(jīng)驗，針對這一類混淆方法的反混淆方法也應運而生。

下面先展示一下安卓APP的代碼混淆技術：

圖1. Java程序的代碼混淆過程

經(jīng)過混淆的代碼在功能上是沒有變化的，但是去掉了部分名稱中的語義信息。因為種種限制，這類混淆也不可能對所有的名稱都進行替換。上圖中的SQLiteHelper、SQLiteDatabase和Cursor就是一個證明，這些名稱都是安卓API，如果將這些類名混淆會影響代碼的功能。

理論上一個有經(jīng)驗的安卓開發(fā)者可以在這些有限的提示下為所有的名稱找到富含語義的表示，所以反混淆只需要一個有經(jīng)驗的開發(fā)者（有經(jīng)驗的開發(fā)者：？？？我做錯了什么）。退一步，找不到有經(jīng)驗的開發(fā)者怎么辦，沒關系，GitHub有高質(zhì)量的各種項目，現(xiàn)訓練一個有經(jīng)驗的開發(fā)者也行。不過為了人道主義，消滅996剝削，程序員表示可以用程序代替人，正好可以用GitHub數(shù)據(jù)訓練一個程序做這個反混淆嘛！理論存在，實踐開始。

JSNice[1]

用程序代替人其實并不簡單，針對上圖中的反混淆問題，程序需要具有“聯(lián)想”和“推理”能力，比如從a

extends

SQLiteHelper這一句中，a應該很可能也是Helper類，結(jié)合類中有SQLiteDatabase實例推理出比較符合a的語義的類名是DBHelper。

針對以上兩點，程序需要先有關系的概念，能從一個詞“聯(lián)想”到另一個詞，然后還要有推理的能力，能通過約束從幾個候選詞中找到最符合的那個詞。怎么做這個事呢？雖然有很多的未混淆的JS腳本供程序?qū)W習，但在反混淆JS腳本時，程序無法理解復雜的JS腳本，所以需要將JS腳本表示成一種可以利用已知屬性推理未知屬性的結(jié)構，JSNice采用了概率圖模型。

概率圖模型相比其他學習算法的優(yōu)勢在于可以利用圖結(jié)構將已知信息帶入知識網(wǎng)絡，在使用概率圖模型之前，往往要求圖結(jié)構是已知的。現(xiàn)實中我們沒有這些先驗知識，但是有大量的樣本（未混淆代碼）。通過樣本學習出未混淆JS腳本的概率圖就是JSNice的核心。

具體到JSNice，這個工具想要做的是為JS腳本推測名稱（name）和類型（type）。先通過一張圖看看JSNice的推理過程。

圖2. 一段推理出名稱和類型的JavaScript程序及推理名稱的推理過程

由于JSNice推理名稱和推理類型的過程類似，本文就只闡述推理名稱的過程。

1. 確定已知和未知屬性

JS腳本中包含了各類代碼元素（elements）比如變量，常量，類，方法名，域等。對推理名稱問題，元素的屬性即帶有語義的名稱，一個需要推理名稱的元素，稱其屬性未知。不需要推理名稱的元素其屬性已知。首先需要確定JS腳本中的元素屬性是否已知。很容易看出圖2(a)代碼中屬性已知的元素包括：常量0和[]、feild名稱length和方法名稱push，其他的局部變量如e，t，n，r和i的屬性都是未知的。

將問題泛化，如何判斷任意的JS腳本中的任意元素的屬性是否已知是需要解決的第一個問題。JSNice采用程序分析和人工指定的方式確定元素屬性是否已知，簡單來說，JSNice認為JS腳本中的常量(constants)、對象屬性名(objects

properties)、方法名(methods)和全局變量名(global

variables)都是屬性已知的元素，而所有的局部變量的屬性都是未知的。值得注意的是JSNice將對象屬性名稱和API名稱直接看做是常量。這個劃分是否合理暫不去討論，但是其確實適用與大部分的JS腳本。有興趣的讀者可以自行研究。

2. 建立依賴網(wǎng)絡

第一步獲取了JS腳本中的所有元素（屬性已知或未知），接下來需要建立元素之間的關系，好方便后續(xù)的推理；圖2(c)中簡單的給出了一些關系，比如"var r = e.length"中可以得到(r, length, L=_.R)的關系。

JSNice實際考慮的元素關系十分復雜，主要有三類，這里簡單的進行描述：

句法關系，這一類關系主要通過AST得到，例子如下：

圖3. (a) 語句i + j amp;amp;amp;amp;amp;lt; k的AST. (b) 根據(jù)AST建立用于名稱預測的依賴網(wǎng)絡. (c) 用于類型預測的網(wǎng)絡.

這類關系的形式化定義如下

別名關系，這類關系通過standard alias analysis得到，將方法調(diào)用時傳入的arguments和方法聲明時的parameters進行關聯(lián)，形成ARG_TO_PM關系。

函數(shù)名稱關系，由于JS的語言特性，很多的局部變量本身是方法定義，MAY_CALL和MAY_ACCESS表示一個方法的可能調(diào)用方法關系和可能訪問對象域關系，這類關系可以通過program analysis得到。

類型推理采用的關系有所不同，但這里也不再詳述，有興趣的讀者直接移步原文。

3. 訓練和推理

現(xiàn)在整理一下對某個JS腳本x進行上述兩步分析能得到什么？得到了一個依賴網(wǎng)絡 ?，其中 ?為節(jié)點集，分別表示未知（unknow）屬性元素和已知屬性元素。 ?為邊集，表示兩個程序元素之間的關系以及關系類型。

現(xiàn)在不去考慮訓練的過程，直接看一下推理過程，JSNice采用貪婪算法，對未知屬性元素遍歷其所有的屬性可能，尋找到使score最大的屬性作為結(jié)果。

圖4. 建立網(wǎng)絡尋找未知屬性元素y的最佳屬性的模式

具體的算法如下：

JSNice在具體實現(xiàn)時對算法有所優(yōu)化，但是其基本思想和主要框架都沒變。其實對比前文提到人進行反混淆時需要的“聯(lián)想”和“推理”兩種能力，candidates函數(shù)擔負了“聯(lián)想”的重任，利用scoreEdges函數(shù)對不同的候選屬性計算score并選擇最大score對應屬性的過程就是”推理“。

將圖2的推理部分摘出來看：

r的candidates有l(wèi)en和length，t的candidates有step、j和q，i的candidates只有i。推理得到的(r、i、t)的屬性是(len、i、step)而不是(length、i、step)；是因為前者的綜合score是0.4+0.8+0.5=1.7，而后者的綜合score只有0.5+0.6+0.5=1.6。

那么怎么得到scoreEdges和candidates函數(shù)呢？

JSNice定義了一個條件隨機場：

x為給定某個JS腳本，y為未知屬性元素（復數(shù)）的任意分配屬性，score為指示屬性y和腳本x的匹配程度的函數(shù)，其返回值為實數(shù)，值越大越匹配。

Z是對應JS腳本x的一個懲罰系數(shù)，用來保證其Pr和為1

將score定義為k個特征函數(shù)的加權平均，得到

最終條件隨機場的表示形式為：

寫到這里，出現(xiàn)了第一個問題，score為k個特征函數(shù)的加權平均，如何確定k呢？

JSNice是在訓練階段的預處理步驟得到k的，實際上不僅僅這一步不僅獲得了k，還直接定義了k個 pairwise feature functions ?。

往前回一步，本文前面一直說GitHub有未混淆的代碼可供概率圖模型學習，這里定義訓練集 ?由t個未混淆的JS腳本組成。對 ?中的任意 ?元組，JSNice定義其特征的集合為

整個訓練集的所有特征集為

JSNice直接定義pairwise feature functions為每個特征三元組

的指示函數(shù)：

所以訓練集有多少特征三元組，k的值就有多大。

但說了這么多，還是沒有提到scoreEdges和candidates。別急，直接定義

如此把前面的公式都串起來了，整個公式組其實只有 ?是未知，條件隨機場的訓練過程其實就是計算 ?的過程。

請點擊輸入圖片描述

至于candidates，假設現(xiàn)在概率圖模型中的 ?已經(jīng)訓練完成，根據(jù)前面的定義， ?和 ?其實是一一對應的， ?本身是特征三元組的指示函數(shù)，也和三元組一一對應，所以可以使用權重 ?直接限制節(jié)點 ?的可能取值。定義 ?函數(shù)對輸入的特征三元組集合基于此權重返回top s的三元組。定義 ?。定義如下輔助函數(shù)：

最后：

candidates函數(shù)其實就是先在 ?中找到和 ?有 ?關系的 ?，然后利用 ?和 ?在訓練集中找到和 ?最相似的詞作為候選。比較方便的是輔助函數(shù)其實可以在預測之前提前計算并緩存下來。

由于筆者本身沒有不研究概率圖模型，所以訓練模型得到 ?的內(nèi)容就省略了，有興趣的讀者可以閱讀原文[1]，本文只簡單的描述：

JSNice采用判別式訓練，由于最大似然需要計算 ?，JSNice采用max-margin training，使用Structured Support Vector Machine (SSVM)并用scalable subgradient descent algorithm優(yōu)化。

請點擊輸入圖片描述

Deguard[2]

相對JSNice做的對JS腳本進行反混淆，Deguard對安卓APK做反混淆的難度要大了很多，放在眼前的一個問題就是項目規(guī)模，JSNice的應用scope其實是Web上的JS腳本，考慮網(wǎng)站的加載等限制，單個JS腳本必不會太大，而安卓APK不同，由于安卓本身事件驅(qū)動的編程方式，一個簡單的安卓APK的復雜度可能就能比得上十分復雜的JS腳本。并且安卓APK的大小一般也沒有限制。

還有一些安卓或者說Java需要的約束是建模時需要考慮的，比如一個Java類中的feilds名稱必須不一樣，一個package中的classes名稱必須不一樣。不滿足這些約束，對APK進行反混淆的結(jié)果就失去了其實用性。

考慮到安卓application的復雜性，選取合適的粒度建模是首要的問題，關系過于復雜不利于概率圖模型的學習，關系過于簡略可能導致無法預測準確的屬性，必須有一個權衡。

1. 確定程序元素（圖的節(jié)點 ?）

要為安卓APK定義一個依賴圖，首先確定圖上的節(jié)點，Deguard考慮了APK中的如下元素：

Types，不管是基本類型(int, long, float)，引用類型(Object, ArrayList)，還是數(shù)組類型(int[], Object[])都能做為節(jié)點

Feilds，APK中的任意類中定義的任意Feild都能做為節(jié)點

Packages，APK中的任意package能做為節(jié)點，像package a.b就可以做為兩個節(jié)點，a和a.b。

Methods，APK中的任意方法都能做為節(jié)點，但是如果有overrides關系，那么子類和父類的method公用一個節(jié)點表示。

Constant values and null

Access Modifiers，比如static，synchronized

Operations

這里沒有考慮Java語言中的泛型機制是因為在編譯過程中會消除泛型，APK本身就是編譯過后的文件。另外和JSNice不一樣的是，Deguard沒有考慮局部變量名和參數(shù)名，但考慮了局部變量的類型和參數(shù)的類型，一方面減少規(guī)模，另一方面就是變量名和參數(shù)名本身不在APK中。

2. 確定元素屬性是否已知

這里將元素屬性定義為節(jié)點是否被混淆，屬性已知說明節(jié)點名稱未被混淆，不需要預測名稱，屬性未知說明節(jié)點名稱已被混淆，需要預測名稱。

已知屬性元素包括

節(jié)點如果代表pakages，classes，methods和feilds且在安卓API中，那么這些節(jié)點是已知的，因為基于名稱的混淆工具并不會混淆這些名稱

構造函數(shù)名稱都是已知的

節(jié)點代表對安卓API方法重寫的方法也是已知的，因為前文已經(jīng)提過，重寫關系其實是用一個節(jié)點表示。

剩下的元素都是未知的，需要預測名稱

3. 構建依賴網(wǎng)絡

Deguard用一張圖詳細描述了其用于構建依賴網(wǎng)絡的關系

圖5. 安卓application采用的關聯(lián)程序元素的關系，第二列定義了邊的類型，如果滿足第三列提出的條件，一個關系就成立

相對JSNice中大部分的關系來自AST，Deguard選擇的關系明顯融合進了人的經(jīng)驗，更加的抽象。實際上本文的精華也是這一張圖，某種程度上這圖中展現(xiàn)出來了人類對具體問題具體分析的思考，而不是僅僅簡單的復用已有工作提出的各種關系。

剩下的內(nèi)容比如模型的訓練和推理其實和JSNice差不多，這里不會重復一遍，后續(xù)會講不一樣的地方，也就是Deguard如何處理Java程序帶來的關于各種名稱的約束。

Java中的名稱約束還是比較復雜的，這里拿一個例子講一下：

圖6. 展示方法命名顯示的例子

A.a(A)沒有任何約束，因為A作為參數(shù)的方法只有它一個

A.b(Object)不能被重命名為equals，因為這樣會override java.lang#

B.g()和B.h()方法重命名名稱必須不一樣，因為這兩方法的特征一樣

B.g()和A.c()方法重命名名稱必須不一樣，如果一樣就是隱式的繼承

B.h()和A.c()方法重命名名稱必須不一樣，也是由于method overriding的原因

C.x()和B.h()卻沒有沖突，因為B.h()是private的

相等約束（繼承重寫機制）可通過共用節(jié)點表示，不等約束也需要明確表示，所以Deguard提出了一個檢測方法名稱不等約束的算法

其他元素，比如類名，F(xiàn)eilds名稱的不等約束比較簡單，直接處理就行。

所有不等約束以集合 ?表示， ?， ?中任意兩個節(jié)點的名稱必須不一樣。

注意這個約束只用與預測階段，因為訓練數(shù)據(jù)（未混淆）本身滿足這些約束。很容易可以把這些約束結(jié)合到JSNice的算法1中。

Deguard的概率圖優(yōu)化算法和JSNice也不一樣，采用的是pseudo likelihood estimation。具體闡述推薦閱讀文章[3]。

值得注意的是，為什么JSNice就沒有Deguard中提到的相等約束和不等約束，筆者個人認為還是由問題和語言特性共同決定，JSNice的名稱預測其實只預測了局部變量，而JS的語言特性導致其本身不需要檢測局部變量的名稱沖突，只有執(zhí)行結(jié)果報錯才會說明程序出錯。也就是說其實JS本身語言特性就沒有這類約束，自然不需要建模。

JAVA 有對源代碼進行混淆的混淆器么

不需要對源代碼混淆。class有這種功能的，在J2ME中混淆是必須的，結(jié)果跟你說的一樣，不過原理不是你那么走的，混淆以后的class反編譯也會讓人看不懂，全部變成了a,b,c,d這樣的名字。

本文題目：java代碼混淆技術,javascript代碼混淆
文章源于：http://chinadenli.net/article14/dsesdge.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供建站公司、電子商務、全網(wǎng)營銷推廣、外貿(mào)建站、動態(tài)網(wǎng)站、

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)