當前位置:首頁 » 編程軟體 » 如何防止編譯逆向

如何防止編譯逆向

發布時間: 2022-07-02 18:19:48

① 如何防止代碼被反編譯

由於apk是Android虛擬機載入的,它有一定的規范,加密apk後Dalvik無法識別apk了。完全避免是不可能的,總有人能夠破解你的代碼。但是有幾種方式來提高被反編譯取代碼的難度。
1 關鍵代碼使用jni調用本地代碼,用c或者c++編寫,因此相對比較難於反編譯

2 混淆java代碼。混淆是不改變代碼邏輯的情況下,增加無用代碼,或者重命名,使反編譯後的源代碼難於看懂。 網上開源的java代碼混淆工具較多,一般是用ant的方式來編譯的。

1 . 在工程文件project.properties中加入下proguard.config=proguard.cfg , 如下所示:
target=android-8
proguard.config=proguard.cfg
Eclipse會通過此配置在工程目錄生成proguard.cfg文件

2 . 生成keystore (如已有可直接利用)
按照下面的命令行 在D:\Program Files\Java\jdk1.6.0_07\bin>目錄下,輸入keytool -genkey -alias android.keystore -keyalg RSA -validity 100000 -keystore android.keystore
參數意義:-validity主要是證書的有效期,寫100000天;空格,退格鍵 都算密碼。
命令執行後會在D:\Program Files\Java\jdk1.6.0_07\bin>目錄下生成 android.keystore文件。

3. 在Eclipce的操作
File -> Export -> Export Android Application -> Select project -> Using the existing keystore , and input password -> select the destination APK file

經過混淆後的源代碼,原先的類名和方法名會被類似a,b,c。。。的字元所替換,混淆的原理其實也就是類名和方法名的映射。
但4大組件並沒有混淆(所有在清單文件定義的組件不能被混淆),因為系統需要通過清單文件來查找和運行應用程序。

proguard.cfg 文件代碼解讀
-optimizationpasses 5 ->設置混淆的壓縮比率 0 ~ 7
-dontusemixedcaseclassnames -> Aa aA
- ->如果應用程序引入的有jar包,並且想混淆jar包裡面的class
-dontpreverify
-verbose ->混淆後生產映射文件 map 類名->轉化後類名的映射

-optimizations !code/simplification/arithmetic,!field/*,!class/merging/* ->混淆採用的演算法.

-keep public class * extends android.app.Activity ->所有activity的子類不要去混淆
-keep public class * extends android.app.Application
-keep public class * extends android.app.Service
-keep public class * extends android.content.BroadcastReceiver
-keep public class * extends android.content.ContentProvider
-keep public class * extends android.app.backup.BackupAgentHelper
-keep public class * extends android.preference.Preference
-keep public class com.android.vending.licensing.ILicensingService

-keepclasseswithmembernames class * {
native <methods>; -> 所有native的方法不能去混淆.
}

-keepclasseswithmembers class * {
public <init>(android.content.Context, android.util.AttributeSet);
-->某些構造方法不能去混淆
}

-keepclasseswithmembers class * {
public <init>(android.content.Context, android.util.AttributeSet, int);
}

-keepclassmembers class * extends android.app.Activity {
public void *(android.view.View);
}

-keepclassmembers enum * { -> 枚舉類不能去混淆.
public static **[] values();
public static ** valueOf(java.lang.String);
}

-keep class * implements android.os.Parcelable { -> aidl文件不能去混淆.
public static final android.os.Parcelable$Creator *;
}

② 如何給自己的app加密,怎樣防止反編譯資源文件和防二次打包要怎麼做

app加密,防反編譯的辦法有很多。代碼混淆(proguard)也可以使用偽加密(apk本身是zip,對zip末尾加位元組的方式防止apktool逆向,但是該方法在電腦上有些手機助手無法識別apk文件,手機上可以識別)。還有就是可以交給第三方的加密平台,不需要什麼技術要求。同時也可以在XML文件查看有沒有添加東西。有家叫做愛加密的免費平台還不錯。

③ 如何對編譯的dll文件進行加密來防止反編譯

為防止這類反向工程的威脅,最有效的辦法是模糊。
模糊工具運用各種手段達到這一目標,但主要的途徑是讓變數名字不再具有指示其作用的能力、加密字元串和文字、插入各種欺騙指令使反編譯得到的代碼不可再編譯。
例子:
對未經模糊處理的代碼執行反向工程:
Private
Sub
CalcPayroll(ByVal
employeeGroup
As
SpecialList)
While
employeeGroup.HasMore
employee
=
employeeGroup.GetNext(True)
employee.updateSalary
DistributeCheck(employee)
End
While
End
Sub
同樣的代碼,經過模糊處理再執行反向工程:
Private
Sub
a(ByVal
b
As
a)
While
b.a
a
=
b.a(True)
a.a
a(a)
End
While
End
Sub
顯然,兩段代碼的處理邏輯相同。但是,要說清楚第二段代碼到底在做些什麼極其困難,甚至要判斷它正在訪問哪些方法、哪些變數也很困難。
這種改變變數名稱的功能是可配置的,例如,假設正在構造一個DLL,可以要求不改動API,有趣的是,這一處理過程顯然只是簡單地把大量變數的名稱簡縮成單個字元,但獲得了非常好的模糊效果。

④ 如何保護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 題庫管理模塊和其它部分的交互過程圖

⑤ android如何做到防止反編譯,保護自己的資源圖片拜託了各位謝謝

1.進行源碼保護檢測。檢測DEX文件保護,查看DEX文件是否做了保護,避免法分子反編譯得到程序源碼,從而杜絕惡意插入廣告、惡意植入扣費代碼等行為,保證用戶體驗以及APP的功能完整。2.源碼混淆保護檢測。該項目主要用來彌補程序開發人員利用混淆源碼做程序的漏洞,因為混淆源碼作為一種常見的基礎保護措施,並不嚴密,如果被專業人士利用,還是會造成相當程度的破壞。3.資源文件保護檢測。APP程序中的各種音頻、視頻、圖片、文字等文件資料如果缺乏有效的保護,很容易被惡意篡改、替換和盜竊。比如程序中的音頻格式或文字內容,如果被篡改,做成廣告畫面或違禁色情圖片等,也是對開發人員和用戶的權益侵害。4.Android主配文件保護檢測。該免費源碼檢測平台可以有效對Android主配置文件中的各個組件進行安全保護,預防其他人員在XML文件中插入代碼,破壞和盜取相關信息,篡改應用程序的功能設定。5.APK防二次打包保護檢測。二次打包就是程序人員對下載的程序進行解壓,刪除原有的簽名,自己設定一個簽名工具在安裝包上簽名,這是一種盜用行為,侵害了原版程序設計人員的權益和利益。通過免費檢測平台,可以有效查看安裝包簽名是否有過改動,可以有效防止二次打包的出現。6、so文件保護,防止APP應用被第三方修改打包。7.愛加密http://www.ijiami.cn/

⑥ C#怎樣防止反編譯

我使用的方法是利用加殼工具:virboxProtectorStandalone。直接進行加殼。高級混淆、虛擬化代碼、智能壓縮等加密策略。如果要授權控制,可使用許可版本的virboxProtector。

未經加殼保護的 ILspy 反編譯效果如下:

public int add(int a, int b){
return a + b;}public int div(int a, int b){
return a / b;}public int mul(int a, int b){
return a * b;}public int sub(int a, int b){
return a - b;}

解決方案:

深思自主研發了為 C# .net 語言做保護的外殼(Virbox Protector)。將C# .net 編譯成的執行程序(.exe),動態庫(.dll)直接拖入加殼工具即可完成保護操作,十分方便。並且在效果上已經完全看不到源碼中的邏輯。

加密後的效果

public int add(int a, int b){
return (int)dm.dynamic_method((object)this, System.Reflection.MethodBase.GetCurrentMethod(), 16416u, 21, 16384u, 32u, 31516u, 5).Invoke(this, new object[]
{
this,
a,
b
});}
public int div(int a, int b){
return (int)dm.dynamic_method((object)this, System.Reflection.MethodBase.GetCurrentMethod(), 16956u, 21, 16924u, 32u, 31516u, 2).Invoke(this, new object[]
{
this,
a,
b
});}
public int mul(int a, int b){
return (int)dm.dynamic_method((object)this, System.Reflection.MethodBase.GetCurrentMethod(), 16776u, 21, 16744u, 32u, 31516u, 3).Invoke(this, new object[]
{
this,
a,
b
});}
public int sub(int a, int b){
return (int)dm.dynamic_method((object)this, System.Reflection.MethodBase.GetCurrentMethod(), 16596u, 21, 16564u, 32u, 31516u, 4).Invoke(this, new object[]
{
this,
a,
b
});}

架構支持

IIS 服務架構的後台邏輯 DLL 文件

windows PC 應用程序 EXE 文件

windows PC 應用程序動態庫 DLL 文件

UG等第三方繪圖工具使用的 DLL 文件

Unity3d 編譯使用的 DLL 文件

⑦ 如何防止程序員反編譯

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

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

C# 編寫的代碼通過VS編譯器生成 dll 或 exe ,很容易被一些反編譯工具查看到源碼或對源碼進行修改。
為防止代碼被反編譯或被篡改,我們可以進行一定的防範措施。但不能杜絕,因為DotNet編寫代碼運行必須編譯成IL 中間語言,IL是很規則,同時也很好反編譯。

反編譯防範措施:

  • 設置項目代碼反匯編屬性

  • 混淆

  • 方法一:防止 Ildasm.exe(MSIL 反匯編程序) 反匯編程序集

    方法很簡單在項目文件AssemblyInfo.cs中增加SuppressIldasm屬性。

    效果很明顯,很難看出反編譯代碼所寫的真正邏輯。

    缺點:
    C#代碼通過混淆工具生成後,增加了很多轉換過程。這使得反編譯工具無法很直觀看到源碼真正邏輯。但源碼代碼過多轉換會使軟體本身運行效率降低,甚至會出現報錯情況。

python如何防止反編譯

Python 編譯生成 pyc 僅僅為了提升載入速度,並不是為了防止破解,反編譯後和原來一模一樣。pyinstaller,py2exe,只是把 pyc 打個包,同樣很弱。代碼混淆也只能增加看懂代碼的難度,但並不能防止破解。所以最為穩妥的辦法只有修改Python解釋器,對源代碼進行加密,解釋器載入源代碼時再解密,這種方法雖然可以防止破解,但給自己帶來麻煩不說,發布程序是需要打包自己修改後的解釋器,相當麻煩。

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

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

熱點內容
靠譜java培訓 發布:2022-08-10 14:05:14 瀏覽:183
車床鑽孔編程 發布:2022-08-10 14:03:28 瀏覽:156
解壓自我調節 發布:2022-08-10 13:59:31 瀏覽:229
導出資料庫的sql語句 發布:2022-08-10 13:56:41 瀏覽:609
如何設置2重密碼 發布:2022-08-10 13:52:19 瀏覽:605
資料庫及sql培訓 發布:2022-08-10 13:48:48 瀏覽:297
手機軟體怎麼安裝存儲卡 發布:2022-08-10 13:48:37 瀏覽:573
圖書館資料庫有哪些 發布:2022-08-10 13:48:29 瀏覽:50
python可變不可變 發布:2022-08-10 13:47:40 瀏覽:711
監控聯網伺服器地址 發布:2022-08-10 13:46:59 瀏覽:406