昨天收到一份安全檢測報(bào)告云芦，其中就有一個(gè)代碼保護(hù)不足的問題，簡單描述就是：通過反編譯得到程序代碼以后贸桶，惡意修改后重新編譯再簽名安裝舅逸。針對這個(gè)問題簡單的查了一些資料做一些記錄。但這些處理也不是很好皇筛，只是讓惡意破解麻煩了一點(diǎn)罷了（并未進(jìn)行實(shí)踐琉历，有時(shí)間要試驗(yàn)一下）。
ToolBar+DrawerLayout使用
Android 自定義側(cè)滑菜單效果(ViewDragHelper)
一站式CoordinatorLayout+ToolBar聯(lián)動(dòng)使用
多布局之RecyclerView與Json數(shù)據(jù)（GridLayoutManager實(shí)現(xiàn)）+多選
簽名校驗(yàn)
反編譯 dex设联，修改重新打包簽名后 apk 的簽名信息肯定會(huì)改變善已，所以可以在代碼中判斷簽名信息是否不一致灼捂，不一致就不進(jìn)入程序。
public static String getSignature(Context context) {
PackageManager pm = context.getPackageManager();
PackageInfo pi;
StringBuilder sb = new StringBuilder();
try {
pi = pm.getPackageInfo(context.getPackageName(), PackageManager.GET_SIGNATURES);
Signature[] signatures = pi.signatures;
for (Signature signature : signatures) {
sb.append(signature.toCharsString());
}
} catch (PackageManager.NameNotFoundException e) {
e.printStackTrace();
}
return sb.toString();
}
拿到字符串以后换团，可以對字符串進(jìn)行MD5加密等加密手段悉稠，然后與存放在本地的加密字符串作比較，不相等則不進(jìn)入APP艘包。originalSign為自己打包簽名文件所得到的字符串的猛。
public static boolean verifySignature(Context context, String originalSign){
String currentSign = getSignature(context);
if (originalSign.equals(currentSign)) {
return true;//簽名正確
}
return false;//簽名被篡改
}
對classes.dex文件完整性校驗(yàn)
DEX文件打包在APK文件中，針對APK代碼的篡改攻擊就是針對該文件想虎，比如使用apktool工具反編譯文件卦尊，修改smali代碼。以下就是通過檢查classes.dex文件的CRC32值來判斷文件是否被篡改舌厨。
其中R.string.str_code是存放在本地的crc加密后的值岂却，string.xml文件是不在dex文件中的，所以修改string.xml文件是不會(huì)造成crc值的變化（親測）裙椭，其實(shí)也可以把這個(gè)值存放在后臺(tái)躏哩，通過請求網(wǎng)絡(luò)來獲取。（感覺沒必要揉燃，為什么扫尺，往下看哈）
private void checkCRC() {
String orginalCrc = getString(R.string.str_code);
ZipFile zf;
try {
zf = new ZipFile(getApplicationContext().getPackageCodePath());
ZipEntry ze = zf.getEntry("classes.dex");
String strCrc = String.valueOf(ze.getCrc());
String MD5Crc = MD5Util.GetMD5Code(strCrc);
Log.e("checkcrc", MD5Crc);
if (!orginalCrc.equals(MD5Crc)) {
//ActivityManagerUtil.getScreenManager().removeAllActivity();
Process.killProcess(Process.myPid());
}
} catch (IOException e) {
e.printStackTrace();
}
}
還有其它幾種方法，比如校驗(yàn)APK包的完整性炊汤、對簽名文件中classes.dex哈希值的校驗(yàn)等正驻。其實(shí)都大同小異。
把這些手段用在了程序中抢腐，但是通過多次反編譯姑曙，都很容易確認(rèn)程序在什么地方做了這些處理（可全局搜索關(guān)鍵詞），惡意破解的話直接將修改返回值true或false,或者修改接收這個(gè)函數(shù)的if-else語句條件取個(gè)反氓栈，直接就繞過了判斷渣磷。
比較科學(xué)一點(diǎn)的辦法就是放在NDK層去校驗(yàn)了，這種校驗(yàn)稍微安全點(diǎn)授瘦，畢竟能逆向 C 和 C++ 的少一點(diǎn)醋界。這里就要借鑒大佬的博客了(→點(diǎn)我←)，里面有講到如果在NDK層來做校驗(yàn)提完。
