增加反編譯難度
① 如何防止代碼被反編譯
由於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 *;
}
② goto語句放在程序中是否可增加反編譯難度c++
goto語句放在程序中是否可增加反編譯難度c++。
沒有這種說法吧,反編譯的技術難度本身並不在於goto語句吧。
只是goto正常開發都不建議使用,會影響對於程序的閱讀理解。所以說增加反編譯難度也有一定道理。
③ 如何有效的防止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程序的重要技術。
④ 如何讓C++寫的dll不被反編譯
簡單回答:
1、理論上不能保證程序不被反編譯。
2、一些加殼軟體可以做到加大被反編譯的難度,迫使操作者先解殼才能做反編譯,但同時會降低程序的運行效率。
3、當前的技術條件下,一般而言,反編譯出的「源代碼」一般而言並不能作學習,參考的源代碼,多數情況下只能用於分析區部片斷分析,主要用於破解或小范圍類修改。
4、一些簡單的加殼軟體:ASPACK、UPX、PECompact等,如果想嘗試,自個去搜索下載後試試。加殼後的軟體還有可能被某些殺軟當成惡意軟體。
5、這也正是很多對安全要求高的系統使用「三層架構」(類似訪問網頁/網站)的原因。因為在三層架構中,核心軟體、數據不被用戶直接接觸。
************以下是相關知識,有耐心可看看************
一、關於反編譯與破解。
1、以當前的技術來說,理論上,所有的程序都存在被反編譯的可能。
2、但是反編譯出來的代碼並不一定能被技術不高的人看懂,因為反編譯出來的「源代碼」與編寫者寫出的原代碼在80%以上是不同的。這是因為反編譯的原理是根據機器碼(或中間碼),讓機算機進行反向生成高級語言,而不是找出編寫者原有的代碼,找出原有的代碼是不可能的。反編譯出來的代碼在可理解性、可閱讀性上,一般而言是非常差的。
3、但是,這並不代碼反編譯出來的「源代碼」沒有價值,對於內行來說,分析反編譯出來的代碼中的某些特定片段,就可以對程序進行破解,找出程序的關鍵點、口令、數據來源等等。因為破壞總是比建設要容易,分析局部比規劃全局要容易得多。
4、如果考慮到被反編譯將關鍵代碼進行特殊處理的話,可能加大相關的難度,比如將特定的字元串分成多個字串在程序中存儲,或是進行加密後存儲,在使用時合成/生成,不用時即時在內存中清除等等……。
5、反編譯後對關鍵部分的定位往往是根據字元串來進行的,比如在用戶沒有注冊時,跳出一行對話,告訴用戶「請注冊後再使用」,破解者就會在反編譯後追查這個字串所在,然後查到這個字串對應的變數與地址,再追查調用這個變數或地址的代碼,然後再延伸查到什麼情況下調用「調用這個變數或地址的代碼」,最後,設定跳過語句。這就是最典型的破解注冊的方法。破解完再將修改了的「源代碼」進行編譯,或是根據「源代碼」直接修正程序中對應的代碼,OK,破解版正式完成。
二、關於加殼。
1、理論上,同樣,沒有破解不了的殼。
2、但是有些加殼軟體使用了一些特別的方法,使得破解殼的難度變得非常難,技術不夠的朋友很難下手,比如將原程序代碼拆分、變型、植入自校驗等等技術。
3、但加殼軟體同樣是程序,它自身就存在被反編的可能,加了殼可以類比成,在一個木箱外面再加個保險櫃。但千萬別以為保險櫃就一定是保險的,面對各種技術開鎖、暴力開箱,再強的保險櫃也只能是加大難度而已。
4、越復雜的加殼,就會使得程序運行時效率降得越低,這是必然的,因為原本只關注目標任務的程序現在還要時時提防著被提取、被監測。