本文仅作学习记录，如有侵权，请联系删除！
前言：
App渗透我几乎没有了解过，于是找了几个相关的app安全检测的pdf文件来学习学习
APP渗透测试要点：
APK文件结构：
- Assets目录：用来存放需要打包到 Android 应用程序的静态资源文件，例如图片资源文件、JSON 配置文件、渠道配置文件、二进制数据文件、HTML5离线资源文件等。与res/raw 目录不同的是，assets 目录支持任意深度的子目录，同时该目录下面的文件不会生成资源ID。
- Lib目录：主要用于存储通过 JNI（Java Native Interface）机制使用的本地库文件，并且会按照其支持的架构，分别创建对应的子目录。存放的是当前app所用得到的so动态链接库文件，so文件就是利用底层的c、c++代码实现的。
- META-INF目录：类似于 JAR 文件，APK 文件中也包含了 META-INF 目录，用于存放代码签名等文件，以便于用来确保 APK 文件不会被人随意修改。存放的是所用到的证书签名文件，包括：MANIFEST.MF（摘要文件）、CERT.SF和CERT.RSA。其中MANIFEST.MF文件是对每个文件的SHA-256-Digest；CERT.SF是对每个文件的头3行进行SHA-256-Digest；CERT.RSA这个文件保存了签名和公钥证书。
- Res目录：该目录主要包含了 Android 应用引用的资源，如图片，动画，字符串、颜色、菜单等，并且会按照资源类型进行存储。主要还有一个 value 文件夹，包含了各类属性资源。这个目录下面的资源都会出现在资源清单文件 R.java 的索引中。
- AndroidManifest.xml：Android项目的系统清单文件，主要用于声明应用程序的名称，组件，权限等基本信息，Android应用的四大组件（Activity、Service、BroadcastReceiver和 ContentProvider ）均在此配置和声明。
- classes.dex：该文件是 dalvik 虚拟机对应的可执行文件，包含应用程序的可执行代码。若APP有多个dex，是因为当前的方法数超过65535，进行了分包处理。如果未超过，则只有一个dex。Android的所有代码都集中在此。可以通过反编译工具dex2jar转化成jar包，再通过jd-gui查看其代码。
- resources.arsc：资源索引表，用来描述具有ID值的资源的配置信息。该文件主要是应用程序编译后的二进制资源以及资源位置与资源 id 之间的映射关系，如字符串。
- colors.xml→颜色资源
dimens.xml--->尺寸资源
strings--->字符串资源
styles.xml→样式资源
应用安装涉及到的如下几个目录：
system/app ---------------系统自带的应用程序，获得adb root权限才能删除
data/app ---------------用户程序安装的目录。安装时把apk文件复制到此目录
data/data ---------------存放应用程序的数据
data/dalvik-cache--------将apk中的dex文件安装到dalvik-cache目录下(dex文件是dalvik虚拟机的可执行文件,其大小约为原始apk文件大小的四分之一)
客户端程序安全：
1、安装包签名：
在 Android 中，包名相同的两个 APK 会被认为是同一个应用。当新版本覆盖旧版本时，
签名证书必须一致，否则会被拒绝。（即使开启了“允许未知来源的应用”）。如果 APK 没有
使用自己的证书进行签名，将会失去对版本管理的主动权。本项检测是检测客户端是否经过
恰当签名（正常情况下应用都应该是签名的，否则无法安装），签名是否符合规范
详情可参考：移动安全（二）|APK打包流程及签名安全机制初探
使用Jdk自带的jarsigner.exe对app的签名进行检查：
jarsigner.exe -verify "C:\Users\sws123\Desktop\apk\huazhu_7.9.9993_guanwang.apk" -verbose -certs
当输出结果为“jar 已验证”时，表示签名正常。
这时还需检测签名的 CN 及其他字段是否正确标识客户端程序的来源和发布者身份：
注意：只有在使用直接客户的证书签名时，才认为安全。Debug 证书、第三方（如
开发方）证书等等均认为风险。
如下图就认为存在风险：
威胁等级:
若客户端安装包签名有异常（例如签名证书为第三方开发商而不是客户端发布方），此
时高风险；若无异常则无风险。
2、反编译检测：
测试客户端安装程序，判断是否能反编译为源代码，java 代码和 so 文件是否存在代码混淆等保护措施。未作保护的 java 代码，可以轻易分析其运行逻辑，并针对代码中的缺陷对客户端或服务器端进行攻击。
成功的反编译将使得攻击者能够完整地分析 APP 的运行逻辑，尤其是相关业务接口协议、和通信加密的实现。
把 apk 当成 zip 并解压，得到 classes.dex 文件（有时可能不止一个 dex 文件，但文
件名大多类似）：
这里利用到dex2jar，dex2jar是用于将Android的.dex格式转换为Java的.class格式的工具
项目地址：https://github.com/pxb1988/dex2jar
使用指南：https://github.com/pxb1988/dex2jar/wiki/UserGuide
利用jdk版本：jdk1.7.0_80：
d2j-dex2jar.bat C:\Users\sws123\Desktop\apk\com.cjia.pms.apk
然后再换成jdk1.8版本，使用 jd-gui 打开 jar 文件，即可得到 JAVA 代码：
如上图，逆向后发现是没混淆的情况，是不安全的。
如果代码经过混淆，或者有加壳措施，不能完整恢复源代码的，都可以认为此项安全，混淆
后的代码样例，除了覆写和接口以外的字段都是无意义的名称。如下图已加密混淆，除了覆
写和接口以外的字段都是无意义的名称：
威胁等级：
若客户端进行加壳保护，此时认为无风险。
若大部分代码（包括核心代码）经过混淆，此时低风险。
若部分代码混淆，关键代码（加密或通信等）可以获知其关键代码，此时中风险
防御措施：
客户端程序可以把关键代码以 JNI 方式放在 so 库里。so 库中是经过编译的 arm 汇编代码，可以对其进行加壳保护，以防止逆向分析
注意：有时用 apktool 能够解包并查看 smali，但 dex2jar 却不行。如果 dex2jar 反编
译失败，可以试试看能不能恢复 smali 代码
+ 补充：
得到源码后，可以全局搜索诸如 ：username、password、host、hostname 、domain 、secretkey、publickey、upload之类的字眼，可能可以直接得到一些可利用的硬编码信息或可未授权访问的敏感接口
3、应用完整性校检：
这里得提一下APK的签名机制：
Apk中的每个文件会做一次算法(数据SHA1摘要+Base64编码)，保存到MANIFEST.MF文件中，具体作法可以理解为程序遍历APK包中的所有文件，对非目录、非签名文件的文件，逐个用SHA1生成摘要信息，再用Base64进行编码后保存。基于此文件的安全机制可以进行文件完整性校验：如果APK包的文件被修改，在APK安装校验时，被修改的文件与MANIFEST.MF的校验信息不同，程序将无法正常安装，同理CERT.SF和CERT.RSA文件同样应用于apk的完整性校验
风险点：
测试客户端程序是否对自身完整性进行校验。攻击者能够通过反编译的方法在客户端程序中植入自己的木马，客户端程序如果没有自校验机制的话，攻击者可能会通过篡改客户端程序窃取手机用户的隐私信息。
项目地址：https://github.com/iBotPeaches/Apktool
用 ApkTool 将目标 APK 文件解包：
# -f apk 文件路径 -o 解包目标文件夹
java -jar apktool_2.4.1.jar d -f C:\Users\sws123\Desktop\apk\com.cjia.tenement.apk -o C:\Users\sws123\Desktop\apk\123
这里同时也能够得到 smali 代码
这里随便找一个解包目录里的资源文件进行修改，推荐找到 logo 之类的图进行修改，这样容易确定结果：
将APK拖入Androidkiller 进行反编译，获取图标的文件名：
打开res(资源存放目录)目录文件夹，点击右键，选择”打开方式“，再点击”打开文件路径“：
根据icon文件名进行搜索：
刚好最近在完糖豆人，换张我吃鸡的照片~图片分辨率不变：
将待打包的文件夹进行APK编译并签名：
如果我们不使用 Android Killer，可以通过 Apktool 将解包目录重新打包成未签名的 APK 文件：
java -jar apktool_2.4.1.jar b -f 待打包的文件夹 -o 输出 apk 路径
再用 SignApk，对未签名的 APK 文件进行签名：
java -jar signapk.jar testkey.x509.pem testkey.pk8 待签名 apk 文件路径 签名后输出 apk 路径
将签了名的 APK 安装、运行、确认是否存在自校验；
需要注意的是，如果之前安装的 APK 和修改后的 APK 签名不同，就不能直接覆盖安装，一般来说，先卸载之前安装的 APP 即可。
推荐修改 apk 中 assets 目录下或 res/raw 目录下的文件。将修改后的 apk 文件导入到
/data/app 目录下，覆盖原文件，然后重启客户端，观察客户端是否会提示被篡改
注意：APK 必须进行签名后，方可安装和运行。如果开启了“允许未知来源的应用”，那么 Debug 证书、自签名证书、过期证书的签名都是可以的，但是不可以不签名。
在模拟器里下载原版apk进行安装：
卸载重新安装以后：
安卓手机成功安装：
说明上述apk没有经过自校验的情况，若经过自校检的情况，则修改后无法正常启动。
威胁等级：
1、若应用完整性校验不使用 MANIFEST.MF 中的数据，且核心代码通过 JNI 技术写入.so
库，同时于服务端进行相关校验，此时无风险。
2、若应用完整性于本地进行验证而不存在其他问题或使用 MANIFEST.MF 中的数据作为验
证凭证（有新文件时提示应用完整性验证失败），此时低风险。
3、若在本地进行验证的基础上只通过 MANIFEST.MF 对客户端原有文件进行校验而忽略新
增文件的检验，此时中风险；若未进行应用完整性校验此时高风险。
防御措施：
客户端在每次开机启动时进行客户端自身的应用完整性校验，在验证逻辑中不使用 MANIFEST.MF 中的数据作为验证凭证，同时需验证是否有不属于该客户端版本的新文件添加，验证过程于服务器端完成。
AndoridManifest.xml风险点：
-
debug模式
客户端软件 AndroidManifest.xml 中的 android:debuggable="true"标记如果开启，可被Java 调试工具例如 jdb 进行调试，获取和篡改用户敏感信息，甚至分析并且修改代码实现的业务逻辑
检查方法：
检查 AndroidManifest.xml 文件中的 debuggable 属性（MobSF） -- 检查是否能被调
试（或者我们可以直接使用MobSF的静态检测）
-
应用程序数据可备份：
Android 2.1 以上的系统可为 App 提供应用程序数据的备份和恢复功能，该由AndroidMainfest.xml 文件中的 allowBackup 属性值控制，其默认值为 true。当该属性没有显式设置为 false 时,攻击者可通过 adb backup 和 adb restore 对 App 的应用数据进行备份和恢复,从而可能获取明文存储的用户敏感信息。
检查方法：
检查应用 AndoridManifest.xml 文件中的配置是否为：
android:allowBackup="true"，即为 allowBackup 开启，记录漏洞，停止测试
-
应用权限测试：
检查应用 AndoridManifest.xml 文件，将应用权限和业务功能需要权限做对比，检查申请应用权限是否大于业务需要权限，有即存在安全隐患
或者我们也可以使用MobSF进行静态检测，它列举了被检测App在AndroidManifest.xml文件中申请的所有权限，并标出了每个权限的危险指数，对于有安全隐患的权限标记为危险
再或者利用github上的项目：https://github.com/antitree/manitree
python manitree.py -f AndroidManifest.xml
篇幅有限，暂且写到这~
参考如下：
App安全检测指南-V1.0.pdf
android app 渗透测试方法大全.pdf
Android逆向破解：Android Killer使用
初次使用Android Killer,修改apk/app图标及软件名(简单测试)
移动安全（二）|APK打包流程及签名安全机制初探
网友评论