做好的apk文件,被检测工具检测出一大堆风险问题,是不是感觉自己的付出白费了,今天咱就聊聊android的安全防范问题。
一,先说安全检查方面的吧
1,源文件安全问题方面
- 1 篡改和二次打包风险
- 2 应用签名未校验风险
- 3Java代码反编译风险检测
- 4代码未混淆风险检测
- 5资源文件泄露风险检测
2,数据存储安全问题方面
2.2Internal Storage数据全局可读写风险检测
3.3加密算法不安全使用风险
4.4日志数据泄露风险
4.5URL硬编码风险
3,组件风险
3.3Content Provider组件导出风险
3.4Broadcast Receiver组件导出风险
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~
没有绝对的安全,我们能做的就是把安全风险降到最低,欧力给!