做好的apk檔案，被檢測工具檢測出一大堆風險問題，是不是感覺自己的付出白費了，今天咱就聊聊android的安全防范問題，
一，先說安全檢查方面的吧
1，源檔案安全問題方面
- 1 篡改和二次打包風險
- 2 應用簽名未校驗風險
- 3Java代碼反編譯風險檢測
- 4代碼未混淆風險檢測
- 5資源檔案泄露風險檢測
2，資料存盤安全問題方面
2.1 WebView明文存盤密碼風險檢測
2.2Internal Storage資料全域可讀寫風險檢測
3.3加密演算法不安全使用風險
4.4日志資料泄露風險
4.5URL硬編碼風險
3，組件風險
3.1Activity組件匯出風險
3.2Service組件匯出風險
3.3Content Provider組件匯出風險
3.4Broadcast Receiver組件匯出風險
3.5WebView遠程代碼執行漏洞
3.6Intent Scheme URL攻擊風險
4，安全防護能力
4.1Java層代碼動態除錯風險
4.2C層代碼動態除錯風險
4.3動態注入攻擊風險
4.4模擬器運行風險
4.5啟動隱藏服務風險
4.6Root設備運行風險
5，內容風險
5.1自定義詞匯
5.2敏感文本
5.3敏感圖片
這種型別的風險存在于發布文章類或資訊類應用，“涉黃”，“賭博”等詞匯與圖片需要進行敏感內容識別或過濾，為了節約成本，可以人工審核資訊來完成，當然，這樣作業量太大，要是有Money的話可以介入專業的
檢測公司API，來讓應用的內容安全做的更嚴密些，
二，在自己沒錢的情況下，看我們能做哪些事吧
1，打包應用，基本要加的就是混淆了，當然，我們還要再創建一個簽名檔案
2，要是我們應用體積大了，還可以再壓縮一下資源檔案，我用 的是 AndResGuard
3，沒錢，沒辦法啊，那就來個免費的加固服務吧，
做到這些，是不是大家都覺得，我也是這樣做的，是的，一般我們程式都會做這些基本的操作，但是我們還可以再做些什么？
情況1，應用被反編譯后二次打包了----apk在正式打包后生成hash簽名保存在服務端，應用每次啟動后校驗當前應用hash與服務端保存的是不是一致，以此來校驗應用是不是合法的，嘿嘿，是不是解決問題的一種方法了
上代碼：
/**
* 根據apk MD5摘要獲取對應的哈希值
*
* @param context
* @return
*/
public static String getApkHashValue(Context context) {
String apkPath = context.getPackageCodePath(); // 獲取Apk包存盤路徑
try {
MessageDigest dexDigest = MessageDigest.getInstance("MD5");
byte[] bytes = new byte[1024];
int byteCount;
FileInputStream fis = new FileInputStream(new File(apkPath)); // 讀取apk檔案
while ((byteCount = fis.read(bytes)) != -1) {
dexDigest.update(bytes, 0, byteCount);
}
/* BigInteger bigInteger = new BigInteger(1, dexDigest.digest()); // 計算apk檔案的哈希值
String sha = bigInteger.toString(16);*/
//解決MD5在特殊情況下丟失0的情況
StringBuffer buf = new StringBuffer();
byte[] b = dexDigest.digest();
int i;
for (int offset = 0; offset < b.length; offset++) {
i = b[offset];
if (i < 0) {
i += 256;
}
if (i < 16) {
buf.append("0");
}
buf.append(Integer.toHexString(i));
}
fis.close();
return buf.toString();
} catch (NoSuchAlgorithmException e) {
e.printStackTrace();
return "";
} catch (FileNotFoundException e) {
e.printStackTrace();
return "";
} catch (IOException e) {
e.printStackTrace();
return "";
}
}情況2；很多時候apk被反編譯或被破壞，多通過模擬器或者獲取root權限來操作
沒辦法，只能給模擬器說再見了，正式發布程式后，代碼檢測運行設備是否是模擬器，如果是的話，就不讓運行了，root 設備一樣的驗證邏輯，簡單粗暴!!!
但是root或模擬器檢測并沒有官方的或權威的檢測代碼，誰讓android品牌太多太雜了捏，沒辦法，真遇到這種兼容性問題的話，沒事，我們可以再做檢查邏輯時，留一手服務端驗證，
由服務端來控制這個版本或者某個用戶走不走這部分驗證邏輯額~~~~~，后邊的可以自行發揮解決，
情況3，動態除錯，記憶體讀取......
和情況2思路一致，均是通過代碼來檢測是否有除錯等工具在除錯程式，然后做出相應的判斷處理
其他情況都比較常見了，隨便百度就能找到解決方法，這里就不啰嗦了，嘿嘿
最后，要是你們公司很有錢，那就不考慮那么多了，來個專業機構加密，一下風險就降到最低，只要有money~
沒有絕對的安全，我們能做的就是把安全風險降到最低，歐力給！
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/273748.html
標籤：其他
上一篇：Andriod anim 補間（Tween）影片與Interpolator以及setCustomAnimations方法
下一篇：macOS部署Appium