導航:首頁 > 源碼編譯 > 反編譯人員

反編譯人員

發布時間:2022-09-28 08:46:47

A. 如何防止class被反編譯,の頤塹鬧恫

可以使用代碼混淆是對Class文件進行重新組織和處理,使得處理後的代碼與處理前代碼完成相同的功能(語義)。但是混淆後的代碼很難被反編譯,即反編譯後得出的代碼是非常難懂、晦澀的,因此反編譯人員很難得出程序的真正語義。
從理論上來說,如果有足夠的時間,被混淆的代碼仍然可能被破解,甚至目前有些人正在研製反混淆的工具。但是從實際情況來看,由於混淆技術的多元化發展,混淆理論的成熟,經過混淆的java代碼還是能夠很好地防止反編譯。
app開發完後,最好做一下掃描和加固,應用掃描可以通過靜態代碼分析、動態數據跟蹤,定位出風險代碼,同時監控敏感數據的異常行為。
加固可以在一定程度上保護自己核心代碼演算法,提高破解/盜版/二次打包的難度,緩解代碼注入/動態調試/內存注入攻擊等。
目前市面上有很多第三方加固的平台, 如果新應用發布前需要掃描或者加固的話,可以先試試免費的,例如騰訊御安全,建議自己先去掃描測試下。

B. android app怎麼防止反編譯

APK在PC上面就被看作一個壓縮格式文件,在手機上面它就算一個可執行格式文件。兩種格式對它的讀取要求也有區別,所以說利用這個區別來實現偽加密。對PC端來講偽加密的APK沒法被解包無法被反編譯,但是對android系統來說它完全不會影響正常的安裝運行(對4.2以前的系統)。

偽加密的原理:讀取APK的位元組,找到連續4位位元組標記為」P K 01 02」的後第5位位元組,如果是0表示不加密,如果是1就表示加密(偽加密就強行改成1 反偽加密就是把1改成0就可以了)。
2
偽加密前和偽加密後的對比圖如下:
偽加密前:

3
偽加密後:

END
使用第三方平台加密

步驟如下:
登錄/注冊→上傳APK→等待系統加密→完成後下載APK→給APK簽名→完成!

2
愛加密作為移動安全行業的第三方平台,為Android APP移動應用提供專業的加固保護方案,包括DEX文件保護、資源文件保護、XML主配文件保護、防二次打包保護、so文件保護、內存保護、高級混淆等,全方位保護Android App,防止被反編譯、破解等,維護廣大開發者朋友的切身利益!

C. 怎樣對ssh框架結構的編譯之後的.class進行混淆處理,防止反編譯。

下面是我從論壇上靠過來的 希望對你有幫助

常用的保護技術
由於Java位元組碼的抽象級別較高,因此它們較容易被反編譯。本節介紹了幾種常用的方法,用於保護Java位元組碼不被反編譯。通常,這些方法不能夠絕對防止程序被反編譯,而是加大反編譯的難度而已,因為這些方法都有自己的使用環境和弱點。
隔離Java程序
最簡單的方法就是讓用戶不能夠訪問到Java
Class程序,這種方法是最根本的方法,具體實現有多種方式。例如,開發人員可以將關鍵的Java
Class放在伺服器端,客戶端通過訪問伺服器的相關介面來獲得服務,而不是直接訪問Class文件。這樣黑客就沒有辦法反編譯Class文件。目前,通
過介面提供服務的標准和協議也越來越多,例如 HTTP、Web
Service、RPC等。但是有很多應用都不適合這種保護方式,例如對於單機運行的程序就無法隔離Java程序。這種保護方式見圖1所示。
圖1隔離Java程序示意圖
對Class文件進行加密
為了防止Class文件被直接反編譯,許多開發人員將一些關鍵的Class文件進行加密,例如對注冊碼、序列號管理相關的類等。在使用這些被加密的類之前,程序首先需要對這些類進行解密,而後再將這些類裝載到JVM當中。這些類的解密可以由硬體完成,也可以使用軟體完成。
在實現時,開發人員往往通過自定義ClassLoader類來完成加密類的裝載(注意由於安全性的原因,Applet不能夠支持自定義的
ClassLoader)。自定義的ClassLoader首先找到加密的類,而後進行解密,最後將解密後的類裝載到JVM當中。在這種保護方式中,自定
義的ClassLoader是非常關鍵的類。由於它本身不是被加密的,因此它可能成為黑客最先攻擊的目標。如果相關的解密密鑰和演算法被攻克,那麼被加密的
類也很容易被解密。這種保護方式示意圖見圖2。
圖2 對Class文件進行加密示意圖
轉換成本地代碼
將程序轉換成本地代碼也是一種防止反編譯的有效方法。因為本地代碼往往難以被反編譯。開發人員可以選擇將整個應用程序轉換成本地代碼,也可以選擇關鍵模塊轉換。如果僅僅轉換關鍵部分模塊,Java程序在使用這些模塊時,需要使用JNI技術進行調用。
當然,在使用這種技術保護Java程序的同時,也犧牲了Java的跨平台特性。對於不同的平台,我們需要維護不同版本的本地代碼,這將加重軟體支持和維護的工作。不過對於一些關鍵的模塊,有時這種方案往往是必要的。
為了保證這些本地代碼不被修改和替代,通常需要對這些代碼進行數字簽名。在使用這些本地代碼之前,往往需要對這些本地代碼進行認證,確保這些代碼沒有被黑客更改。如果簽名檢查通過,則調用相關JNI方法。這種保護方式示意圖見圖3。
代碼混淆
圖3 轉換成本地代碼示意圖
代碼混淆是對Class文件進行重新組織和處理,使得處理後的代碼與處理前代碼完成相同的功能(語義)。但是混淆後的代碼很難被反編譯,即反編
譯後得出的代碼是非常難懂、晦澀的,因此反編譯人員很難得出程序的真正語義。從理論上來說,黑客如果有足夠的時間,被混淆的代碼仍然可能被破解,甚至目前
有些人正在研製反混淆的工具。但是從實際情況來看,由於混淆技術的多元化發展,混淆理論的成熟,經過混淆的Java代碼還是能夠很好地防止反編譯。下面我
們會詳細介紹混淆技術,因為混淆是一種保護Java程序的重要技術。圖4是代碼混淆的示意圖。
圖4 代碼混淆示意圖
幾種技術的總結
以上幾種技術都有不同的應用環境,各自都有自己的弱點,表1是相關特點的比較。
混淆技術介紹
表1 不同保護技術比較表
到目前為止,對於Java程序的保護,混淆技術還是最基本的保護方法。Java混淆工具也非常多,包括商業的、免費的、開放源代碼的。
Sun公司也提供了自己的混淆工具。它們大多都是對Class文件進行混淆處理,也有少量工具首先對源代碼進行處理,然後再對Class進行處理,這樣加
大了混淆處理的力度。目前,商業上比較成功的混淆工具包括JProof公司的1stBarrier系列、Eastridge公司的JShrink和
4thpass.com的SourceGuard等。主要的混淆技術按照混淆目標可以進行如下分類,它們分別為符號混淆(Lexical
Obfuscation)、數據混淆(Data Obfuscation)、控制混淆(Control
Obfuscation)、預防性混淆(Prevent Transformation)。
符號混淆
在Class中存在許多與程序執行本身無關的信息,例如方法名稱、變數名稱,這些符號的名稱往往帶有一定的含義。例如某個方法名為
getKeyLength(),那麼這個方法很可能就是用來返回Key的長度。符號混淆就是將這些信息打亂,把這些信息變成無任何意義的表示,例如將所有
的變數從vairant_001開始編號;對於所有的方法從method_001開始編號。這將對反編譯帶來一定的困難。對於私有函數、局部變數,通常可
以改變它們的符號,而不影響程序的運行。但是對於一些介面名稱、公有函數、成員變數,如果有其它外部模塊需要引用這些符號,我們往往需要保留這些名稱,否
則外部模塊找不到這些名稱的方法和變數。因此,多數的混淆工具對於符號混淆,都提供了豐富的選項,讓用戶選擇是否、如何進行符號混淆。
數據混淆
圖5 改變數據訪問
數據混淆是對程序使用的數據進行混淆。混淆的方法也有多種,主要可以分為改變數據存儲及編碼(Store and Encode Transform)、改變數據訪問(Access Transform)。
改變數據存儲和編碼可以打亂程序使用的數據存儲方式。例如將一個有10個成員的數組,拆開為10個變數,並且打亂這些變數的名字;將一個兩維數組轉化為一個一維數組等。對於一些復雜的數據結構,我們將打亂它的數據結構,例如用多個類代替一個復雜的類等。
另外一種方式是改變數據訪問。例如訪問數組的下標時,我們可以進行一定的計算,圖5就是一個例子。
在實踐混淆處理中,這兩種方法通常是綜合使用的,在打亂數據存儲的同時,也打亂數據訪問的方式。經過對數據混淆,程序的語義變得復雜了,這樣增大了反編譯的難度。
控制混淆
控制混淆就是對程序的控制流進行混淆,使得程序的控制流更加難以反編譯,通常控制流的改變需要增加一些額外的計算和控制流,因此在性能上會給程序帶來一定的負面影響。有時,需要在程序的性能和混淆程度之間進行權衡。控制混淆的技術最為復雜,技巧也最多。這些技術可以分為如下幾類:
增加混淆控制
通過增加額外的、復雜的控制流,可以將程序原來的語義隱藏起來。例如,對於按次序執行的兩個語句A、B,我們可以增加一個控制條件,以決定B的執行。通過
這種方式加大反匯編的難度。但是所有的干擾控制都不應該影響B的執行。圖6就給出三種方式,為這個例子增加混淆控制。
圖6 增加混淆控制的三種方式
控制流重組
重組控制流也是重要的混淆方法。例如,程序調用一個方法,在混淆後,可以將該方法代碼嵌入到調用程序當中。反過來,程序中的一段代碼也可以轉變為一個函數
調用。另外,對於一個循環的控制流,為可以拆分多個循環的控制流,或者將循環轉化成一個遞歸過程。這種方法最為復雜,研究的人員也非常多。
預防性混淆
這種混淆通常是針對一些專用的反編譯器而設計的,一般來說,這些技術利用反編譯器的弱點或者Bug來設計混淆方案。例如,有些反編譯器對於
Return後面的指令不進行反編譯,而有些混淆方案恰恰將代碼放在Return語句後面。這種混淆的有效性對於不同反編譯器的作用也不太相同的。一個好
的混淆工具,通常會綜合使用這些混淆技術。
案例分析
在實踐當中,保護一個大型Java程序經常需要綜合使用這些方法,而不是單一使用某一種方法。這是因為每種方法都有其弱點和應用環境。綜合使用這些方法使得Java程序的保護更加有效。另外,我們經常還需要使用其它的相關安全技術,例如安全認證、數字簽名、PKI等。
本文給出的例子是一個Java應用程序,它是一個SCJP(Sun Certificate Java
Programmer)的模擬考試軟體。該應用程序帶有大量的模擬題目,所有的題目都被加密後存儲在文件中。由於它所帶的題庫是該軟體的核心部分,所以關
於題庫的存取和訪問就成為非常核心的類。一旦這些相關的類被反編譯,則所有的題庫將被破解。現在,我們來考慮如何保護這些題庫及相關的類。
在這個例子中,我們考慮使用綜合保護技術,其中包括本地代碼和混淆技術。因為該軟體主要發布在Windows上,因此轉換成本地代碼後,僅僅需要維護一個版本的本地代碼。另外,混淆對Java程序也是非常有效的,適用於這種獨立發布的應用系統。
在具體的方案中,我們將程序分為兩個部分,一個是由本地代碼編寫的題庫訪問的模塊,另外一個是由Java開發的其它模塊。這樣可以更高程度地保護題目管理模塊不被反編譯。對於Java開發的模塊,我們仍然要使用混淆技術。該方案的示意圖參見圖7。
圖7 SCJP保護技術方案圖
對於題目管理模塊,由於程序主要在Windows下使用,所以使用C++開發題庫訪問模塊,並且提供了一定的訪問介面。為了保護題庫訪問的介面,我們還增加了一個初始化介面,用於每次使用題庫訪問介面之前的初始化工作。它的介面主要分為兩類:
1. 初始化介面
在使用題庫模塊之前,我們必須先調用初始化介面。在調用該介面時,客戶端需要提供一個隨機數作為參數。題庫管理模塊和客戶端通過這個隨機數,按
一定的演算法同時生成相同的SessionKey,用於加密以後輸入和輸出的所有數據。通過這種方式,只有授權(有效)的客戶端才能夠連接正確的連接,生成
正確的SessionKey,用於訪問題庫信息。非法的客戶很難生成正確的SessionKey,因此無法獲得題庫的信息。如果需要建立更高的保密級別,
也可以採用雙向認證技術。
2. 數據訪問介面
認證完成之後,客戶端就可以正常的訪問題庫數據。但是,輸入和輸出的數據都是由SessionKey所加密的數據。因此,只有正確的題庫管理模塊才能夠使用題庫管理模塊。圖8時序圖表示了題庫管理模塊和其它部分的交互過程。
圖8 題庫管理模塊和其它部分的交互過程圖

D. 如何保護Java程序 防止Java反編譯

Java是一種跨平台的、解釋型語言。Java 源代碼編譯中間「位元組碼」存儲於class文件中。Class文件是一種位元組碼形式的中間代碼,該位元組碼中包括了很多源代碼的信息,例如變數名、方法名等。因此,Java中間代碼的反編譯就變得非常容易。目前市場上有許多免費的、商用的反編譯軟體,都能夠生成高質量的反編譯後的源代碼。所以,對開發人員來說,如何保護Java程序就變成了一個非常重要的挑戰。本文首先討論了保護Java程序的基本方法,然後對代碼混淆問題進行深入研究,最後結合一個實際的應用程序,分析如何在實踐中保護Java程序。 反編譯成為保護Java程序的最大挑戰 通常C、C++等編程語言開發的程序都被編譯成目標代碼,這些目標代碼都是本機器的二進制可執行代碼。通常所有的源文件被編譯、鏈接成一個可執行文件。在這些可執行文件中,編譯器刪除了程序中的變數名稱、方法名稱等信息,這些信息往往是由內存地址表示,例如如果需要使用一個變數,往往是通過這個變數的地址來訪問的。因此,反編譯這些本地的目標代碼就是非常困難的。 Java語言的出現,使得反編譯變得非常容易而有效。原因如下:1.由於跨平台的需求,Java的指令集比較簡單而通用,較容易得出程序的語義信息;2.Java編譯器將每一個類編譯成一個單獨的文件,這也簡化了反編譯的工作;3.Java 的Class文件中,仍然保留所有的方法名稱、變數名稱,並且通過這些名稱來訪問變數和方法,這些符號往往帶有許多語義信息。由於Java程序自身的特點,對於不經過處理的Java程序反編譯的效果非常好。 目前,市場上有許多Java的反編譯工具,有免費的,也有商業使用的,還有的是開放源代碼的。這些工具的反編譯速度和效果都非常不錯。好的反編譯軟體,能夠反編譯出非常接近源代碼的程序。因此,通過反編譯器,黑客能夠對這些程序進行更改,或者復用其中的程序。因此,如何保護Java程序不被反編譯,是非常重要的一個問題。 常用的保護技術 由於Java位元組碼的抽象級別較高,因此它們較容易被反編譯。本節介紹了幾種常用的方法,用於保護Java位元組碼不被反編譯。通常,這些方法不能夠絕對防止程序被反編譯,而是加大反編譯的難度而已,因為這些方法都有自己的使用環境和弱點。 隔離Java程序 最簡單的方法就是讓用戶不能夠訪問到Java Class程序,這種方法是最根本的方法,具體實現有多種方式。例如,開發人員可以將關鍵的Java Class放在伺服器端,客戶端通過訪問伺服器的相關介面來獲得服務,而不是直接訪問Class文件。這樣黑客就沒有辦法反編譯Class文件。目前,通過介面提供服務的標准和協議也越來越多,例如 HTTP、Web Service、RPC等。但是有很多應用都不適合這種保護方式,例如對於單機運行的程序就無法隔離Java程序。這種保護方式見圖1所示。 圖1隔離Java程序示意圖 對Class文件進行加密 為了防止Class文件被直接反編譯,許多開發人員將一些關鍵的Class文件進行加密,例如對注冊碼、序列號管理相關的類等。在使用這些被加密的類之前,程序首先需要對這些類進行解密,而後再將這些類裝載到JVM當中。這些類的解密可以由硬體完成,也可以使用軟體完成。 在實現時,開發人員往往通過自定義ClassLoader類來完成加密類的裝載(注意由於安全性的原因,Applet不能夠支持自定義的ClassLoader)。自定義的ClassLoader首先找到加密的類,而後進行解密,最後將解密後的類裝載到JVM當中。在這種保護方式中,自定義的ClassLoader是非常關鍵的類。由於它本身不是被加密的,因此它可能成為黑客最先攻擊的目標。如果相關的解密密鑰和演算法被攻克,那麼被加密的類也很容易被解密。這種保護方式示意圖見圖2。 圖2 對Class文件進行加密示意圖 轉換成本地代碼 將程序轉換成本地代碼也是一種防止反編譯的有效方法。因為本地代碼往往難以被反編譯。開發人員可以選擇將整個應用程序轉換成本地代碼,也可以選擇關鍵模塊轉換。如果僅僅轉換關鍵部分模塊,Java程序在使用這些模塊時,需要使用JNI技術進行調用。 當然,在使用這種技術保護Java程序的同時,也犧牲了Java的跨平台特性。對於不同的平台,我們需要維護不同版本的本地代碼,這將加重軟體支持和維護的工作。不過對於一些關鍵的模塊,有時這種方案往往是必要的。 為了保證這些本地代碼不被修改和替代,通常需要對這些代碼進行數字簽名。在使用這些本地代碼之前,往往需要對這些本地代碼進行認證,確保這些代碼沒有被黑客更改。如果簽名檢查通過,則調用相關JNI方法。這種保護方式示意圖見圖3。 代碼混淆
圖3 轉換成本地代碼示意圖 代碼混淆是對Class文件進行重新組織和處理,使得處理後的代碼與處理前代碼完成相同的功能(語義)。但是混淆後的代碼很難被反編譯,即反編譯後得出的代碼是非常難懂、晦澀的,因此反編譯人員很難得出程序的真正語義。從理論上來說,黑客如果有足夠的時間,被混淆的代碼仍然可能被破解,甚至目前有些人正在研製反混淆的工具。但是從實際情況來看,由於混淆技術的多元化發展,混淆理論的成熟,經過混淆的Java代碼還是能夠很好地防止反編譯。下面我們會詳細介紹混淆技術,因為混淆是一種保護Java程序的重要技術。圖4是代碼混淆的示意圖。
圖4 代碼混淆示意圖 幾種技術的總結 以上幾種技術都有不同的應用環境,各自都有自己的弱點,表1是相關特點的比較。 混淆技術介紹 表1 不同保護技術比較表
到目前為止,對於Java程序的保護,混淆技術還是最基本的保護方法。Java混淆工具也非常多,包括商業的、免費的、開放源代碼的。Sun公司也提供了自己的混淆工具。它們大多都是對Class文件進行混淆處理,也有少量工具首先對源代碼進行處理,然後再對Class進行處理,這樣加大了混淆處理的力度。目前,商業上比較成功的混淆工具包括JProof公司的1stBarrier系列、Eastridge公司的JShrink和4thpass.com的SourceGuard等。主要的混淆技術按照混淆目標可以進行如下分類,它們分別為符號混淆(Lexical Obfuscation)、數據混淆(Data Obfuscation)、控制混淆(Control Obfuscation)、預防性混淆(Prevent Transformation)。 符號混淆 在Class中存在許多與程序執行本身無關的信息,例如方法名稱、變數名稱,這些符號的名稱往往帶有一定的含義。例如某個方法名為getKeyLength(),那麼這個方法很可能就是用來返回Key的長度。符號混淆就是將這些信息打亂,把這些信息變成無任何意義的表示,例如將所有的變數從vairant_001開始編號;對於所有的方法從method_001開始編號。這將對反編譯帶來一定的困難。對於私有函數、局部變數,通常可以改變它們的符號,而不影響程序的運行。但是對於一些介面名稱、公有函數、成員變數,如果有其它外部模塊需要引用這些符號,我們往往需要保留這些名稱,否則外部模塊找不到這些名稱的方法和變數。因此,多數的混淆工具對於符號混淆,都提供了豐富的選項,讓用戶選擇是否、如何進行符號混淆。 數據混淆 圖5 改變數據訪問 數據混淆是對程序使用的數據進行混淆。混淆的方法也有多種,主要可以分為改變數據存儲及編碼(Store and Encode Transform)、改變數據訪問(Access Transform)。 改變數據存儲和編碼可以打亂程序使用的數據存儲方式。例如將一個有10個成員的數組,拆開為10個變數,並且打亂這些變數的名字;將一個兩維數組轉化為一個一維數組等。對於一些復雜的數據結構,我們將打亂它的數據結構,例如用多個類代替一個復雜的類等。 另外一種方式是改變數據訪問。例如訪問數組的下標時,我們可以進行一定的計算,圖5就是一個例子。 在實踐混淆處理中,這兩種方法通常是綜合使用的,在打亂數據存儲的同時,也打亂數據訪問的方式。經過對數據混淆,程序的語義變得復雜了,這樣增大了反編譯的難度。 控制混淆 控制混淆就是對程序的控制流進行混淆,使得程序的控制流更加難以反編譯,通常控制流的改變需要增加一些額外的計算和控制流,因此在性能上會給程序帶來一定的負面影響。有時,需要在程序的性能和混淆程度之間進行權衡。控制混淆的技術最為復雜,技巧也最多。這些技術可以分為如下幾類: 增加混淆控制 通過增加額外的、復雜的控制流,可以將程序原來的語義隱藏起來。例如,對於按次序執行的兩個語句A、B,我們可以增加一個控制條件,以決定B的執行。通過這種方式加大反匯編的難度。但是所有的干擾控制都不應該影響B的執行。圖6就給出三種方式,為這個例子增加混淆控制。 圖6 增加混淆控制的三種方式 控制流重組 重組控制流也是重要的混淆方法。例如,程序調用一個方法,在混淆後,可以將該方法代碼嵌入到調用程序當中。反過來,程序中的一段代碼也可以轉變為一個函數調用。另外,對於一個循環的控制流,為可以拆分多個循環的控制流,或者將循環轉化成一個遞歸過程。這種方法最為復雜,研究的人員也非常多。 預防性混淆 這種混淆通常是針對一些專用的反編譯器而設計的,一般來說,這些技術利用反編譯器的弱點或者Bug來設計混淆方案。例如,有些反編譯器對於Return後面的指令不進行反編譯,而有些混淆方案恰恰將代碼放在Return語句後面。這種混淆的有效性對於不同反編譯器的作用也不太相同的。一個好的混淆工具,通常會綜合使用這些混淆技術。 案例分析 在實踐當中,保護一個大型Java程序經常需要綜合使用這些方法,而不是單一使用某一種方法。這是因為每種方法都有其弱點和應用環境。綜合使用這些方法使得Java程序的保護更加有效。另外,我們經常還需要使用其它的相關安全技術,例如安全認證、數字簽名、PKI等。 本文給出的例子是一個Java應用程序,它是一個SCJP(Sun Certificate Java Programmer)的模擬考試軟體。該應用程序帶有大量的模擬題目,所有的題目都被加密後存儲在文件中。由於它所帶的題庫是該軟體的核心部分,所以關於題庫的存取和訪問就成為非常核心的類。一旦這些相關的類被反編譯,則所有的題庫將被破解。現在,我們來考慮如何保護這些題庫及相關的類。 在這個例子中,我們考慮使用綜合保護技術,其中包括本地代碼和混淆技術。因為該軟體主要發布在Windows上,因此轉換成本地代碼後,僅僅需要維護一個版本的本地代碼。另外,混淆對Java程序也是非常有效的,適用於這種獨立發布的應用系統。 在具體的方案中,我們將程序分為兩個部分,一個是由本地代碼編寫的題庫訪問的模塊,另外一個是由Java開發的其它模塊。這樣可以更高程度地保護題目管理模塊不被反編譯。對於Java開發的模塊,我們仍然要使用混淆技術。該方案的示意圖參見圖7。 圖7 SCJP保護技術方案圖 對於題目管理模塊,由於程序主要在Windows下使用,所以使用C++開發題庫訪問模塊,並且提供了一定的訪問介面。為了保護題庫訪問的介面,我們還增加了一個初始化介面,用於每次使用題庫訪問介面之前的初始化工作。它的介面主要分為兩類: 1. 初始化介面 在使用題庫模塊之前,我們必須先調用初始化介面。在調用該介面時,客戶端需要提供一個隨機數作為參數。題庫管理模塊和客戶端通過這個隨機數,按一定的演算法同時生成相同的SessionKey,用於加密以後輸入和輸出的所有數據。通過這種方式,只有授權(有效)的客戶端才能夠連接正確的連接,生成正確的SessionKey,用於訪問題庫信息。非法的客戶很難生成正確的SessionKey,因此無法獲得題庫的信息。如果需要建立更高的保密級別,也可以採用雙向認證技術。 2. 數據訪問介面 認證完成之後,客戶端就可以正常的訪問題庫數據。但是,輸入和輸出的數據都是由SessionKey所加密的數據。因此,只有正確的題庫管理模塊才能夠使用題庫管理模塊。圖8時序圖表示了題庫管理模塊和其它部分的交互過程。 圖8 題庫管理模塊和其它部分的交互過程圖

E. Android項目里如何混淆自己打的jar包或者防止被反編譯

Android之防止反編譯技巧:

1. 判斷程序是否運行在模擬器上

boolean isRunningInEmualtor() {
boolean qemuKernel = false;
Process process = null;
DataOutputStream os = null;
try{
process = Runtime.getRuntime().exec("getprop ro.kernel.qemu");
os = new DataOutputStream(process.getOutputStream());
BufferedReader in = new BufferedReader(new InputStreamReader(process.getInputStream(),"GBK"));
os.writeBytes("exit\n");
os.flush();
process.waitFor();
// getprop ro.kernel.qemu == 1 在模擬器
// getprop ro.proct.model == "sdk" 在模擬器
// getprop ro.build.tags == "test-keys" 在模擬器
qemuKernel = (Integer.valueOf(in.readLine()) == 1);
Log.d("com.droider.checkqemu", "檢測到模擬器:" + qemuKernel);
} catch (Exception e){
qemuKernel = false;
Log.d("com.droider.checkqemu", "run failed" + e.getMessage());
} finally {
try{
if (os != null) {
os.close();
}
process.destroy();
} catch (Exception e) {

}
Log.d("com.droider.checkqemu", "run finally");
}
return qemuKernel;
}

2. 檢測keystore簽名,再與之前得做比較

public int getSignature(String packageName) {
PackageManager pm = this.getPackageManager();
PackageInfo pi = null;
int sig = 0;
try {
pi = pm.getPackageInfo(packageName, PackageManager.GET_SIGNATURES);
Signature[] s = pi.signatures;
sig = s[0].hashCode();
} catch (Exception e1) {
sig = 0;
e1.printStackTrace();
}
return sig;
}

3. 檢測包名,版本名和版本號,然後做判斷:

private String getAppInfo() {
try {
String pkName = this.getPackageName();
String versionName = this.getPackageManager().getPackageInfo(
pkName, 0).versionName;
int versionCode = this.getPackageManager()
.getPackageInfo(pkName, 0).versionCode;
return pkName + " " + versionName + " " + versionCode;
} catch (Exception e) {
}
return null;
}

4. 把jpg圖片寫成是png格式得圖片 但是最新版本的apktool已經修復了

5. 花指令,影響jd-gui 但是最新版本的jd-gui已經修復
private static final char[] wJ = "0123456789abcdef".toCharArray();
public static String imsi = "204046330839890";
public static String p = "0";
public static String keyword = "電話";
public static String tranlateKeyword = "%E7%94%B5%E8%AF%9D";
在每個類裡面加入 如上欄位。。。。

https://***/ 一個第三方得」愛加密「網站 1.需要使用官方的打包key工具打包後上傳到"愛加密"網站進行處理,然後到網站上面下載,下載後還要用"愛加密"的打包工具再次進行打包即可。

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

防止Java開發出來的程序被別人反編譯有很多種方法,下面給你介紹幾種:

1、隔離Java程序

最簡單的方法就是讓用戶不能夠訪問到Java Class程序,這種方法是最根本的方法,具體實現有多種方式。例如,開發人員可以將關鍵的Java Class放在伺服器端,客戶端通過訪問伺服器的相關介面來獲得服務,而不是直接訪問Class文件。這樣黑客就沒有辦法反編譯Class文件。目前,通過介面提供服務的標准和協議也越來越多,例如 HTTP、Web Service、RPC等。但是有很多應用都不適合這種保護方式,例如對於單機運行的程序就無法隔離Java程序。

2、對Class文件進行加密

為了防止Class文件被直接反編譯,許多開發人員將一些關鍵的Class文件進行加密,例如對注冊碼、序列號管理相關的類等。在使用這些被加密的類之前,程序首先需要對這些類進行解密,而後再將這些類裝載到JVM當中。這些類的解密可以由硬體完成,也可以使用軟體完成。

3、轉換成本地代碼

將程序轉換成本地代碼也是一種防止反編譯的有效方法。因為本地代碼往往難以被反編譯。開發人員可以選擇將整個應用程序轉換成本地代碼,也可以選擇關鍵模塊轉換。如果僅僅轉換關鍵部分模塊,Java程序在使用這些模塊時,需要使用JNI技術進行調用。

4、代碼混淆

代碼混淆是對Class文件進行重新組織和處理,使得處理後的代碼與處理前代碼完成相同的功能(語義)。但是混淆後的代碼很難被反編譯,即反編譯後得出的代碼是非常難懂、晦澀的,因此反編譯人員很難得出程序的真正語義。從理論上來說,黑客如果有足夠的時間,被混淆的代碼仍然可能被破解,甚至目前有些人正在研製反混淆的工具。但是從實際情況來看,由於混淆技術的多元化發展,混淆理論的成熟,經過混淆的Java代碼還是能夠很好地防止反編譯。

不同保護技術比較希望能給大家帶來參考:

G. CHM文件如何加密 不被人反編譯

我作為一個軟體開發人員我想對您提一下幾個意見:

  1. CHM在程序中是一種幫助文件與軟體說明文件其類型與Windows幫助文件HLP文件是同一種類型的文件所以在程序設計的角度上CHM文件根本不用進行秘鑰加密.

  2. CHM加密是為了怕有反編譯人員對CHM進行反編譯

  3. 如果要進行再防止反編譯類型的加密上可以用這個程序

H. JAVA游戲JAR反編譯後,游戲的公司名、客服、開發人員信息在哪個文件找不到,是不是反編譯有問題

java編譯的時候,不會編譯注釋!
你反編譯,當然就沒有你所說的那些信息了。

I. 如何防止程序員反編譯

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就得跟著這個項目到處走啊!

J. mt管理器反編譯是什麼意思

MT管理器是一款強大的文件管理工具和APK逆向修改神器。軟體有漢化應用、替換資源、修改布局、修改邏輯代碼、資源混淆、去除簽名校驗等功能主要功能- 文件復制、移動、創建軟鏈接、重命名、刪除、創建文件(夾),文件批量操作。

反編譯

反編譯是將可執行的(准備運行的)程序代碼(也稱為目標代碼)轉換為某種形式的高級編程語言,使其具有更易讀的格式。反編譯是一種逆向工程,它的作用與編譯器的作用相反。它與編譯相反。完成此任務的工具稱為反編譯器。反編譯有許多不同的原因,例如理解程序、恢復源代碼以進行存檔或更新、查找病毒、調試程序和翻譯過時的代碼。完全自動化的反編譯是不可能的。沒有反編譯器可以獲得開發人員編寫的確切源代碼。

反編譯有時被不道德地用於復制源代碼以在未經版權所有者許可的情況下重復使用或改編。反編譯 APK 文件並不是一項非常艱巨的任務。它需要將 dex 文件轉換為 jar 文件,然後將這些 jar 文件轉換為 java 源代碼,從而獲取應用程序源代碼。可以通過保護性手段(例如代碼復雜性和混淆)將程序設計為抗反編譯。這包括反調試技術、限制調試器、跟蹤檢查、優化和剝離二進制文件。

閱讀全文

與反編譯人員相關的資料

熱點內容
帶一點黃的小說 瀏覽:257
法國倫理電影小僕人 瀏覽:187
印度搶打火機的電影叫什麼 瀏覽:291
求在線觀看資源2020年 瀏覽:946
聚優電影可以在哪些影院使用 瀏覽:124
阿里雲伺服器怎麼安裝bt面板 瀏覽:630
霍爾瓦特大街小說 瀏覽:857
可以看的網址大全 瀏覽:416
一個名叫尼克和保姆的電影 瀏覽:613
電影里有戒尺的 瀏覽:845
徐英演的哪些大尺度電影 瀏覽:412
鬼片英文版 瀏覽:600
《前度2》完整未刪減 瀏覽:851
大陸類似春的森林電影 瀏覽:526
1受多攻獸世 瀏覽:849
軍嫂肉文 瀏覽:935
javamariadb 瀏覽:876
未刪減的網站在線觀看 瀏覽:899
雞雞加長叫什麼電影 瀏覽:387
愛情電影網址 瀏覽:726