1、安装包测试
安装包反编译测试
用例风险：源代码未做混淆使攻击者很轻易反编译出源代码导致代码泄漏风险。
执行步骤：使用反编译工具打开应用，如发现代码内未经过混淆，就说明存在应用可进行反编译，记录漏洞，停止测试。
预期结果：安装包中核心模块与敏感数据经过加密或者混淆
整改建议：建议使用Proguard等工具对源码进行进一步混淆，避免造成源码泄漏。
安装包签名测试
用例风险： Android签名机制是一种有效的身份标识，为了保证应用不被恶意修改后重新发布，需要检查应用签名是否有保护机制。
执行步骤
1、解压缩安装包.apk文件后，删除META-INF/目录下的xx.RSA和xxx.SF文件
2、使用自己的私钥对删除过后的apk文件进行重新签名，首先生成自己的私钥
`keytool -genkey -v -keystore [keystore路径] -alias [密钥别名] -keyalg RSA -keysize 2048 -validity [有效天数]`
3、然后对apk进行二次签名，签名命令格式如下
jarsigner -verbose -sigalg MD5withRSA -digestalg SHA1 -keystore [keystore名称] [apk文件] [密钥别名]
- -sigalg：签名算法名称
- -digestalg:信息摘要算法
- -keystore:签名文件
执行签名命令
jarsigner -verbose -sigalg MD5withRSA -digestalg SHA1 -keystore android.keystore kaoyan.apk android.keystore
4、安装重新签名后的apk文件，查看应用是否具有保护机制阻止程序运行。
预期结果：更换签名后，触发应用防御机制，应用无法启动或提示。
整改建议：内部代码实现apk二次打包鉴别机制，在程序运行时校验apk签名是否由官方私钥签名而来。
应用权限测试
用例风险：应用权限分配不合理，可能导致用户隐私数据泄露。
执行步骤
1、使用反编译工具反编译。
2、打开源码后，检查应用AndoridManifest.xml文件，将应用权限和业务功能需要权限做对比，检查申请应用权限是否大于业务需要权限，有即存在安全隐患。
预期结果：应用申请合理的系统权限。
整改建议：为应用分配合理的系统权限。
AllowBackup开启
用例风险：当allowBackup标志值为true时，即可通过adb backup和adb restore来备份和恢复应用程序数据，导致应用数据泄露。
执行步骤
1、打开AndroidManifest.xml文件；
2、检查应用AndoridManifest.xml文件中的配置是否为：android:allowBackup="true"，即为allowBackup开启，记录漏洞，停止测试。
预期结果：AllowBackup关闭。
整改建议：在AndroidManifest.xml文件设置allowBackup属性值为False。
备注：allowBackup属性未配置时默认为true。
debuggable开启
用例风险：当debuggable标志值为true时，即表示是App可调试的，存在安全泄露风险。
执行步骤
1、打开解析的AndroidManifest.xml文件；
2、检查应用AndoridManifest.xml文件中的配置是否为：android: debuggable="true"，即为debuggable开启。
预期结果： debuggable关闭。
整改建议：在AndroidManifest.xml文件设置debuggable属性值，其默认值为false。
备注：Debuggable属性未配置时默认为false。
弱加密算法审查
用例风险
使用弱加密算法会大大增加黑客攻击的概率，黑客可能会破解隐私数据、猜解密钥、中间人攻击等，造成隐私信息的泄漏，甚至造成财产损失。容易被破解的加密算法被称为弱加密算法，例如可以使用穷举法在有限的时间内破解DES算法。
执行步骤
1、使用反编译工具进行反编译。
2、打开源码后，查找代码中的敏感数据和敏感函数加密代码，是否使用DES弱加密算法，弱加密代码样例：
SecretKeySpec key = new SecretKeySpec(rawKeyData, "DES"); //指定加密方式
Cipher cipher = Cipher.getInstance("DES/ECB/PKCS5Padding"); //设置加密填充模式
cipher.init(Cipher.DECRYPT_MODE, key);
3、RSA中加密不使用Padding：RSA加密常用的填充模式有三种：
- RSA_PKCS1_PADDING
- RSA_PKCS1_OAEP_PADDING
- RSA_NO_PADDING
使用RSA公钥时通常会绑定一个Padding，原因是为了防止对RSA算法的攻击。风险代码样例如下：
Cipher rsa = null;
try {
rsa = javax.crypto.Cipher.getInstance("RSA/NONE/NoPadding");
}
catch (java.security.NoSuchAlgorithmException e) {
}
catch (javax.crypto.NoSuchPaddingException e) {
}
SecretKeySpec key = new SecretKeySpec(rawKeyData, "RSA");
Cipher cipher = Cipher.getInstance("RSA/NONE/NoPadding"); //选择了NoPadding加密模式
cipher.init(Cipher.DECRYPT_MODE, key);
4、使用了不安全的密钥长度，如下演示代码所示密码长度为512bits（常用的密钥长度有1024bits，2048bits等，使用RSA加密时，建议密钥长度大于1024bit）：
public static KeyPair getRSAKey() throws NoSuchAlgorithmException {
KeyPairGenerator keyGen = KeyPairGenerator.getInstance("RSA");
keyGen.initialize(512); //密码长度设置为512bits
KeyPair key = keyGen.generateKeyPair();
return key;
}
5、使用了不安全的加密模式，如下示例代码中AES加密使用了ECB模式：
SecretKeySpec key = new SecretKeySpec(keyBytes, "AES");
Cipher cipher = Cipher.getInstance("AES/ECB/PKCS7Padding", "BC");
cipher.init(Cipher.ENCRYPT_MODE, key);
ECB模式是最简单的模式，在其中明文和密文是一一对应的，相同的明文会被加密为相同的密文，这样可以通过观察密文得到明文中重复的组合，并以此为线索来破解密码。
预期结果：系统未使用包含风险的加密算法。
整改建议：
- 使用对称加密算法时避免使用DES算法；
- 使用RSA算法加密时不使用NoPadding；
- 在选择加密模式时避免使用ECB模式；
- 使用RSA加密时，建议密钥长度大于1024bit；
2、数据传输测试