安卓测试
<h4>安卓测试</h4>
<h5>1.数字签名检查</h5>
<p><strong>jarsigner.exe(在java自带有)</strong>
C:\Program Files\Java\jdk1.8.0_111\bin\jarsigner.exe -verify APK 文 件 路 径
-verbose –certs
说明：要说明的是，只有在使用直接客户的证书签名时，才认为安全。 Debug 证书、第三方（如
开发方）证书等等均认为风险。</p>
<h4>2.反编译测试</h4>
<p><strong>dex2jar</strong>
把apk当成zip并解压、得到classes.dex文件，
java -jar dex2jar.jar classes.dex +classes.dex得到<strong>classes.dex.jar</strong> 然后再用<strong>jd-gui</strong>打开 jar文件即可得到java代码</p>
<h4>3.反编译为smali代码</h4>
<p><strong>apktool</strong>
apktool d +app路径 +保存路径
<img src="https://www.showdoc.com.cn/server/api/attachment/visitfile/sign/ff90b7e0d6a137a514bb33e7dc1d3c55?showdoc=.jpg" alt="" /></p>
<h4>4.应用完整性校验</h4>
<p><strong>解包：</strong>java -jar apktool.jar d -f apk 文件路径 -o 解包目标文件夹
<strong>更改文件：</strong>随便找一个解包目录里的资源文件，修改之，推荐找到 logo 之类的图进行修改（因为容
易确认结果）；
<strong>再次打包：</strong>java -jar apktool.jar b -f 待打包的文件夹 -o 输出 apk 路径
<strong>apk签名：</strong>：java -jar signapk.jar testkey.x509.pem testkey.pk8 待签名 apk 文件路径 签名后输出
apk 路径
（将签了名的 APK 安装、运行、确认是否存在自校验；
需要注意的是，如果之前安装的 APK 和修改后的 APK 签名不同，就不能直接覆盖安装，
一般来说，先卸载之前安装的 APP 即可。
【注： APK 必须进行签名后，方可安装和运行。如果开启了“允许未知来源的应
用”，那么 Debug 证书、自签名证书、过期证书的签名都是可以的，但是不可以不签名。】
将客户端程序文件反编译，修改源码或资源文件后重新打包安装运行）</p>
<h4>5.可debug模式</h4>
<p>AndroidManifest.xml
android:debuggable="true"标记如果开启：可被
Java 调试工具例如 jdb 进行调试，获取和篡改用户敏感信息，甚至分析并且修改代码实现
的业务逻辑</p>
<h4>6.应用程序数据可备份</h4>
<p>android:allowBackup="true"，即为 allowBackup 开启</p>
<h4>7.应用权限测试</h4>
<p>可用MobSF进行测试。</p>
<h4>8.组件安全测试</h4>
<p>显式声明了 android:exported="true"，则可导出；
显示声明了 android:exported="false"，则不可导出；
未显示声明 android:exported：
若组件不是 Content Provider：
i. 若组件包含<intent-filter>则可导出，反之不可；
b) 若组件是 Content Provider：</p>
<h4>9.Activity</h4>
<p>Android 每一个 Application 都是由 Activity、Service、content Provider 和 Broadcast
Receiver 等 Android 的基本组件所组成
一个界面就是一个Activity
drozer命令：
run app.activity.info -a packagename</p>
<h4>10.Service</h4>
<p>一个 Service是没有界面且能长时间运行于后台的应用组件、其他应用组件可以启动一个服务运行于后台，即使用户切换到另一个应用也会继续运行
run app.service.info -a packename</p>
<h4>11.Broadcast Reciever</h4>
<p>Broadcast Recevier 广播接收器是一个专注于接收广播通知信息，并做出对应处理的组件。
很多广播是源自于系统代码的──比如，通知时区改变、电池电量低、拍摄了一张照片或者
用户改变了语言选项。应用程序也可以进行广播──比如说，通知其它应用程序一些数据下
载完成并处于可用状态。应用程序可以拥有任意数量的广播接收器以对所有它感兴趣的通知
信息予以响应
1、反编译后检索 registerReceiver()，查找动态广播接收器。也可以使用可使用工具 Drozer
扫描，命令如下：
<strong>run app.broadcast.info -a android -i</strong>
2、同时留意 android:exported="true"权限的组件。
3、尝试向应用程序的 receiver 组件发送空值，am broadcast -a MyBroadcast -n
com.isi.vul_broadcastreceiver/.MyBroadCastReceiver，查看是否能够造成应用程序崩溃，
形成拒绝服务。</p>
<h4>12.content provider</h4>
<p>Android Content Provider 存在文件目录遍历安全漏洞，该漏洞源于对外暴露 Content
Provider 组件的应用，没有对 Content Provider 组件的访问进行权限控制和对访问的目标
文件的 Content Query Uri 进行有效判断，攻击者利用该应用暴露的 Content Provider
的 openFile()接口进行文件目录遍历以达到访问任意可读文件的目的。在使用 Content
Provider 时，将组件导出，提供了 query 接口。由于 query 接口传入的参数直接或间接由
接口调用者传入，攻击者构造 sql injection 语句，造成信息的泄漏甚至是应用私有数据的
恶意改写和删除。
<strong>run app.provider.info -a cn.etouch.ecalendar</strong></p>
<h4>13.Internet本地拒绝服务检测</h4>
<p>Android 应用本地拒绝服务漏洞源于程序没有对 Intent.getXXXExtra()获取的异常或者畸
形数据处理时没有进行异常捕获，从而导致攻击者可通过向受害者应用发送此类空数据、异
常或者畸形数据来达到使该应用 crash 的目的，简单的说就是攻击者通过 intent 发送空数
据、异常或畸形数据给受害者应用，导致其崩溃
run app.activity.info –a com.mwr.example.sieve</p>
<h4>14.组件通信分析</h4>
<p>1.使用 mercury 查看那 APP 的组件信息
2.使用 mercury 查找 APP Content Provider 组件漏洞，包括组件暴露，SQL 注入，文件目录遍历。
1.确定包名
<strong>run app.package.list</strong>
2.查看指定包的基本信息，例如数据存储路径 uid，gid，permissions
<strong>run app.package.info -a com.android.browser</strong>
3.列出 APP 中的 activity 组件
<strong>run app.activity.info -a com.android.browser</strong>
4.列出 APP 中的 service 组件
<strong>run app.service.info -a com.android.browser</strong>
5.列出 APP 中的 Content Provider 组件
<strong>run app.provider.info -a com.android.browser</strong>
6.查找可以读取的 Content Provider 的 URI
<strong>run scanner.provider.finduris -a com.sina.weibo</strong>
7.读取 Content Provider 指定 URI 中的内容
<strong>run app.provider.query content://settings/secure --selection</strong>
name='adb_enabled'
8.扫描是否存在 content provider 目录遍历的漏洞
<strong>run scanner.provider.traversal -a com.android.browser</strong>
9.读取 content provider 指定的目录
<strong>run app.provider.read content://com.mwri.fileEncryptor.localfile/system/etc/hosts/</strong>
10.扫描是否存在 SQL 注入
<strong>run scanner.provider.injection -a com.android.browser</strong>
11.利用 SQL 注入
*<em>run scanner.provider.query content://com.example.bsideschallenge.evilPlannerdb
--projection </em> from cards --<strong>
12.查看指定包的 AndroidManifest.xml 文件
</strong>run app.package.manifest com.example.bsidechallenge<strong>
13.查看指定包的 AndroidManifest.xml 文件
</strong>run app.package.manifest com.example.bsidechallenge**</p>
<h4>15.检查私有目录下的文件权限</h4>
<p>此私有目录通常位于“／data／data／应用名称／”。在测试时，建议完全退出客户端后，
再进行私有文件的测试，以确保测试结果的准确性。（有些客户端在退出时会清理临时文件）
首先查看相关文件的权限配置。正常的文件权限最后三位应为空（类似“rw-rw----” ），
即除应用自己以外任何人无法读写； 目录则允许多一个执行位（类似“rwxrwx—x” ）。
如下图所示，（lib 子目录是应用安装时由 android 系统自动生成，可以略过）</p>
<h4>16.检查客户端程序存储在手机中的SharedPreferences 配置文件</h4>
<p>权限检测完整后，再检查客户端程序存储在手机中的 SharedPreferences 配置文件，
通常是对本目录下的文件内容（一般是 xml）进行检查，看是否包含敏感信息。</p>
<h4>17.检查客户端程序存储在手机中的SQLite数据库文件</h4>
<p>最后在检测 SQLite 数据库文件，在私有目录及其子目录下查找以.db 结尾的数据库文
件。对于使用了 webView 缓存的应用，会在 databases 子目录中保存 webview.db 和
webviewCache.db，如图所示。其中有可能会记录 cookies 和提交表单等信息</p>
<h4>18.检查客户端程序apk包中是否存在敏感信息</h4>
<p>还有些时候，客户端程序 apk 包中也是是保存有敏感信息的，比如检查 apk 包中各
类文件是否包含硬编码的的敏感信息等（反编译 so 库和 5.逆向 classes.dex，检查 apk
包中各类文件是否包含硬编码的的敏感信息。对可执行文件可通过逆向方法寻找，也可以直
接使用 16 进制编辑器查找。）。如下图 APP 的相关编码信息</p>
<h4>19.检查客户端程序的其他文件存储数据，如缓存文件和外部存储</h4>
<p>在应用的私有目录以及 SD 卡中包含应用名称的子目录中进行遍历，检查是否有包含敏感
信息的文件。查找应用和文件 IO 相关的系统调用（如 open，read，
write 等），对客户端读写的文件内容进行检查</p>
<h4>20.检查手机客户端程序的敏感信息是否进行了加密，加密算法是否安全</h4>
<p>查找保存在应用私有目录下的文件。检查文件中的数据是否包含敏感信息。如果包含非明文
信息，在 Java 代码中查找相应的加密算法，检查加密算法是否安全。（例如，采用 base64
的编码方法是不安全的，使用硬编码密钥的加密也是不安全的。）
或者使用 Dexter 在线检测环境（或 sanddroid）来做，如图所示，Exported 为对号的
是已经导出的组件，可能存在安全问题。（注意：Dexter 对 Content Provider 判断不一
定准确。）</p>
<h4>21.内存残余日志</h4>
<p>adb shell logcat -d > E:\1.txt</p>
<h4>22.密码软键盘安全性测试</h4>
<p>安装安卓按键记录工具（ns_keylogger.apk），在设置中选择我们的输入法，启动 APP，输
入框长按空格，选择我们的测试键盘，使用 logcat/DDMS 查看测试键盘记录 -- 查看
APP 案件能否被测试键盘记录。
安 装 android 击键 记 录 测 试工 具 。 然后 在“ 语 言 和键 盘 设 置” 中 选择
“Sample Soft Keyboard”。然后启动客户端，在输入框长按，弹出提示框后选择“input
method”（输入法），选择我们安装的软键盘。
下图是书写短信息时，使用软键盘输入，在 logcat 日志中可以看到所有的击键</p>
<h4>23.屏幕录像</h4>
<p>使用 ADB 进行测试：
adb shell /system/bin/screencap -p 输出 png 路径（安卓设备中）成功截图, 攻击者可以在用户进入登录页面，在输入密码的同时，进行连续截图，即可记录
用户输入的密码。如果没有防截屏，那么即使是随机分布的、没有视觉反馈的软键盘也会被
记录.</p>
<h4>23.密码复杂度检测</h4>
<p>人工测试，尝试将密码修改为弱口令，如：123456，654321，121212，888888 等，查
看客户端是否拒绝弱口令。也可以阅读逆向后的客户端 java 代码，寻找对用户输入口令的
检查方法。</p>
<h4>24.账号登录限制</h4>
<p>测试一个帐号是否可以同时在多个设备上成功登录客户端，进行操作。</p>
<h4>25.账号锁定策略</h4>
<p>测试客户端是否限制登录次数、防止木马使用穷举法暴力破解用户密码。</p>
<h4>26.私密问题验证</h4>
<p>测试对账号某些信息（如单次支付限额）的修改是否有私密问题验证。私密问题验证是
否将问题和答案一一对应。私密问题是否足够私密、</p>
<h4>27.会话安全设置</h4>
<p>测试客户端在超过 20 分钟无操作后，是否会使会话超时并要求重新登录。超时时间设
置是否合理。
一段时间无操作 -- 检测应用是否要求用户重新登陆退出应用再打开 -- 检测应用是
否要求用户登陆。</p>
<h4>28.界面切换保护</h4>
<p>检查客户端程序在切换到其他应用时，已经填写的账号密码等敏感信息是否会清空，防止用
户敏感信息泄露。如果切换前处于已登录状态，切换后一定时间内是否会自动退出当前
会话。
人工检测。在登录界面（或者转账界面等涉及密码的功能）填写登录名和密码，然后切出，
再进入客户端，看输入的登录名和密码是否清除。登录后切出，5 分钟内自动退出为安
全。
输入登陆密码后，切换到其他应用，再切换回来 -- 检测是否会将用户输入的密码等敏感
信息清空登陆之后，切换到其它应用，过一段时间切换回来 -- 检测当前会话是否退出</p>
<h4>29.界面切换保护</h4>
<p>检查客户端程序在切换到其他应用时，已经填写的账号密码等敏感信息是否会清空，防止用
户敏感信息泄露。如果切换前处于已登录状态，切换后一定时间内是否会自动退出当前
会话。
人工检测。在登录界面（或者转账界面等涉及密码的功能）填写登录名和密码，然后切出，
再进入客户端，看输入的登录名和密码是否清除。登录后切出，5 分钟内自动退出为安
全。
输入登陆密码后，切换到其他应用，再切换回来 -- 检测是否会将用户输入的密码等敏感
信息清空登陆之后，切换到其它应用，过一段时间切换回来 -- 检测当前会话是否退出</p>
<h4>29.UI信息泄露</h4>
<p>检查客户端的各种功能，看是否存在敏感信息泄露问题。
人工测试。使用错误的登录名或密码登录，看客户端提示是否不同。在显示卡号等敏感信息
时是否进行部分遮挡。
查看 APP 各界面 -- 检测是否对用户的真实姓名、身份证号、银行卡号、手机号等进行
适当遮挡</p>
<h4>30.验证码安全</h4>
<p>测试客户端在登录和交易时是否使用图形验证码。验证码是否符合如下要求：由数字和字母
等字符混合组成；采取图片底纹干扰、颜色变换、设置非连续性及旋转图片字体、变异。
体显示样式等有效方式，防范恶意代码自动识别图片上的信息；具有使用时间限制并仅能
使用一次；验证码由服务器生成，客户端文件中不包含图形验证码文本内容。
观察验证码组成，若简单，可以尝试使用 PKAVHttpFuzzer 的验证码识别工具进行识别</p>
<h4>31.安全退出</h4>
<p>检查客户端在退出时，是否向服务端发送终止会话请求。客户端退出后，还能否使用退
出前的会话 id 访问登录后才能访问的页面。
在客户端登出账号之后，继续使用之前的会话 token 进行操作 -- 检测用户登出后会话
token 是否在服务端被正确销毁</p>
<h4>31.密码修改验证</h4>
<p>尝试在修改密码时使用错误的旧密码 -- 检测服务端是否验证旧密码的正确性</p>
<h4>32.Activity界面劫持</h4>
<p>检查是否存在 activity 劫持风险，确认客户端是否能够发现并提示用户存在劫持
安装 HijackActivity.apk，使用 activity 界面劫持工具，在工具中指定要劫持的应用进程
名称（进程查看和监视 ps/top）。如图所示，从列表中选择被测试的应用，点击 OK。打
开应用，测试工具会尝试用自己的窗口覆盖被测的应用。测试工具试图显示自己的窗口时，
安全的客户端应该弹出警告提示。如果劫持成功，会出现如下界面：
<img src="https://www.showdoc.com.cn/server/api/attachment/visitfile/sign/c1308a716416d3219d869c9d50e2552a?showdoc=.jpg" alt="" /></p>
<h4>33.登录界面设计</h4>
<p>检查移动客户端的各种功能，看是否存在敏感信息泄露问题
试使用不存在的用户名登陆，尝试使用存在的用户名及错误密码登陆 -- 检测是否可根据
界面提示进行用户名枚举</p>
<h4>34.弱密钥算法审查</h4>
<p>使用反编译工具进行反编译
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 公钥时通常会绑定一个 padding，原因是为了防止一些依赖于 no 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");
cipher.init(Cipher.DECRYPT_MODE, key);
4、没有安全的初始化向量
初始化向量时，使用了硬编码到程序的常量。风险代码样例：
byte[] iv = { 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 };
IvParameterSpec ips = new IvParameterSpec(iv)
5、 使用了不安全的加密模式
SecretKeySpec key = new SecretKeySpec(keyBytes, "AES");
Cipher cipher = Cipher.getInstance("AES/ECB/PKCS7Padding", "BC");
cipher.init(Cipher.ENCRYPT_MODE, key);
6、 使用了不安全的密钥长度
public static KeyPair getRSAKey() throws NoSuchAlgorithmException {
KeyPairGenerator keyGen = KeyPairGenerator.getInstance("RSA");
keyGen.initialize(512);
KeyPair key = keyGen.generateKeyPair();
return key;
}</p>
<h4>35.应用权限测试</h4>
<p>1、使用反编译工具反反编译
2、打开源码后，检查应用 AndoridManifest.xml 文件，将应用权限和业务功能需要权限
做对比，检查申请应用权限是否大于业务需要权限，有即存在安全隐患。</p>
<h4>36.手势密码安全测试</h4>
<p>测试客户端手势密码复杂度，观察是否有点位数量判断逻辑。</p>
<ol>
<li>进入客户端设置手势密码的页面进行手势密码设置。</li>
<li>进行手势密码设置，观察客户端手势密码设置逻辑是否存在最少点位的判断。</li>
<li>反编译 APK 为 jar 包，通过 jd-gui 观察对应代码逻辑是否有相应的判断和限制
条件。（一般设置手势密码若输入点数过少时会有相应的文字提示，通过此文字提示可以快
速定位到代码位置）
<h4>37.手势密码的修改和取消</h4>
<p>检测客户端在取消手势密码时是否会验证之前设置的手势密码，检测是否存在其他导致
手势密码取消的逻辑问题</p></li>
<li>进入客户端设置手势密码的位置，一般在个人设置或安全中心等地方。</li>
<li>进行手势密码修改或取消操作，观察进行此类操作时是否需要输入之前的手势密码
或普通密码。</li>
<li>观察在忘记手势密码等其他客户端业务逻辑中是否存在无需原始手势或普通密码即
可修改或取消手势密码的情况。</li>
<li>多次尝试客户端各类业务，观察是否存在客户端逻辑缺陷使得客户端可以跳转回之
前业务流程所对应页面。若存在此类逻辑（例如手势密码设置），观察能否修改或取消手势
密码。</li>
<li>反编译 APK 为 jar 包，通过 jd-gui 观察对应代码逻辑，寻找客户端对于手势密
码的修改和删除是否存在相应的安全策略。
<h4>38.手势密码的本地信息保存</h4>
<p>检测在输入手势密码以后客户端是否会在本地记录一些相关信息，例如明文或加密过的
手势密码。</p></li>
<li>首先通过正常的操作流程设置一个手势密码并完整一次完整的登陆过程。</li>
<li>寻找/data/data 的私有目录下是否存在手势密码对应敏感文件，若进行了相关的
信息保存，基本在此目录下。（关键词为 gesture， key 等）</li>
<li>若找到对应的文件，观察其存储方式，为明文还是二进制形式存储，若为二进制形
式， 观察其具体位数是否对应进行 MD5（二进制 128 位，十六进制 32 位或 16 位）、
SHA-1（二进制 160 位，十六进制 40 位）等散列后的位数。如果位数对应，即可在反编
译的 jar 包中搜索对应的关键字以迅速对应代码。</li>
<li>通过代码定位确认其是否进行了除单项哈希散列之外的加密算法，若客户端未将手
势密码进行加密或变形直接进行散列处理可认为其不安全，一是因为现阶段 MD5、SHA-1
等常用的哈希算法已被发现碰撞漏洞，二是网络中存在 www.somd5.com 等散列值查询
网站可以通过大数据查询的方式获取散列前的明文手势密码。
<h4>39.手势密码的锁定策略</h4>
<p>测试客户端是否存在手势密码多次输入错误被锁定的安全策略。防止木马使用穷举法暴力破
解用户密码。因为手势密码的存储容量非常小，一共只有 9！=362880 种不同手势，若手
势密码不存在锁定策略，木马可以轻易跑出手势密码结果。手势密码在输入时通常以 a[2][2]
这种 3*3 的二维数组方式保存，在进行客户端同服务器的数据交互时通常将此二维数组中
数字转化为类似手机数字键盘的 b[8]这种一维形式，之后进行一系列的处理进行发送.</p></li>
<li>首先通过正常的操作流程设置一个手势密码。</li>
<li>输入不同于步骤 1 中的手势密码，观察客户端的登陆状态及相应提示。若连续输
入多次手势密码错误，观察当用户处于登陆状态时是否退出当前的登陆状态并关闭客户端；
当
客户未处于登录状态时是否关闭客户端并进行一定时间的输入锁定。</li>
<li>反编译 APK 为 jar 包，通过 jd-gui 观察对应代码逻辑，寻找客户端是否针对输.入次
数及锁定时间有相应的逻辑处理
<h4>40 手势密码的抗攻击测试</h4>
<p>验证是否可以通过插件绕过手势密码的验证页面。</p></li>
<li>下载并安装 Xposed 框架及 SwipeBack 插件。</li>
<li>启动客户端并进入手势密码输入页。</li>
<li>启动 SwipeBack 插件，观察是否可以通过滑动关闭手势密码输入页的方式进入登
陆后的页面
<h4>41.是否对数据的完整性进行校验</h4>
<p>app 向服务器提交的数据易被中间人篡改，对用户数据的完整性造成影响，可以对业务操
作进行任意重放，造成如用户信息被破解利用等问题。
测试描述：使用 webproxy 获取业务操作请求数据进行分析。
第一步：
1.部署代理程序，启动 app，正常操作 app；
2.分析web请求中的提交的字段，是否存在较长加密的 header参数或者POST/GET 参数；
3.在 app 上对提交的数据进行修改，重新提交，查看这些参数的值有无变化；
4.对获取数据包参数进行修改并重放，查看是否可正常返回；
5.若无正常返回，或者提示数据错误，停止测试；
6.否则说明 app 请求参数未进行完整性校验。
第二步：
1.对 app 进行反编译；
2.分析某个特定动作的代码逻辑，如 login；
3.查看提交参数是否有单独的校验函数，如 MD5、SHA 等 hash 函数；
4.若有，对该哈希函数的源码进行查看，若无法找到函数地址，测试停止；
5.若函数执行方式清晰可见，分析的所校验参数；
6.尝试使用 web 代理程序 payload 处理进行重放，是否可重放成功。</p>
<h4>42.短信重放攻击</h4>
<p>检测应用中是否存在数据包重放攻击的安全问题。是否会对客户端用户造成短信轰炸的困扰。尝试重放短信验证码数据包是否可以进行短信轰炸攻击</p>
<h4>43.访问控制</h4>
<p>测试客户端访问的 URL 是否仅能由手机客户端访问。是否可以绕过登录限制直接访问登录。后才能访问的页面，对需要二次验证的页面（如私密问题验证），能否绕过验证。在 PC 机的浏览器里输入 URL，尝试访问手机银行页面。</p>
<h4>44.通信加密</h4>
<p>客户端和服务端通信是否强制采用 https 加密为了对服务器端进行测试，至少要先弄清楚
客户端与服务器的通信协议。
一般来说，有以下三种情况：</p></li>
<li>如果使用 HTTP(S)协议，大多可以通过设置系统 HTTP 代理来进行操作客户端的网络
访问。这种情况占绝大多数：
a) 在电脑上开启 Burp/Fiddler 等代理工具，并设置允许远程连接；
b) 如果是 Emulator 虚拟机：
i. Emulator 默认使用 3G 网络 NAT；
ii. 在设置->无线和网络(->更多)->移动网络->接入点名称/APN->Telerik，
即可设置代理地址和端口；
iii. 一般来说，设置成物理机的出口网卡 IP 即可；
c) 如果是 Genymotion 虚拟机：
i. Genymotion 默认使用 WIFI 网络 NAT；
ii. 在设置->无线和网络->WLAN->长按连接的 WIFI 名称->修改网络->代理:
手动，即可设置代理地址和端口；
iii. 同上，设置成物理机的出口网卡 IP 即可；
d) 如果是真实手机：
i. 使用 netsh wlan 开启承载网络（具体方法请自行百度）；
ii. 用手机连接电脑的 WIFI，其余部分同 Genymotion。</li>
<li>如果是 HTTP(S)协议，但是不接受操作系统代理：
a) 如果设备已经 root，可以安装一个叫做“ProxyDroid”的 APP；
i. Emulator 的 root 方法参考三、注释；
b) 如果设备不能 root，但电脑性能充足，可以把安卓虚拟机装在 Windows 虚拟
机里，在 Windows 虚拟机上安装 Proxifier，挂到物理机的代理工具上；
c) 如果都不行，可参考 3.；</li>
<li>如果不是 HTTP 协议：
a) 那么一般就是由 TCP 或 UDP 实现的私有协议，大多数是 TCP；
b) 虽然也可以用一些办法来操作 TCP 网络访问（比如用 WPE 附加到 Emulator 的
进程上），但由于 TCP 是全双工流式协议，传输层上没有明确的报文边界。如果私有协议
是请求-响应式的还勉强可以编辑，如果是委托-回调式，或者其它复杂形式的协议，使用通
用工具进行操作是非常困难的。
c) 这种情况可以通过 Wireshark 抓包分析，如果协议不复杂，可以自行实现代码
进行仿制；
d) 如果协议复杂，就需要对 APP 的代码进行分析，找到通信的部分，将其摘出并
调用，或者自行实现代码进行仿制；
此外，通信过程如果有加密、签名等措施，通常需要从客户端代码入手，进行传统逆向
分析以破解其加密。如果其实现非常复杂，此项可以认为安全。
逆向分析的常见入手位置主要有数据（字符串内容等）和特定 API（如界面、网络、文件、
Native 操作等）两种。
有时会遇到客户端检查了 HTTPS 证书的情况（表现为，代理工具如果不替换 SSL 证书
则正常代理，替换 SSL 证书则客户端网络异常），会有以下两种情况：</li>
<li>客户端使用操作系统证书链验证服务端证书：
a) 此种情况下，可以从代理工具中导出证书，然后安装到安卓设备中。</li>
<li>客户端预存了服务端证书的公钥或 Hash，甚至整个证书：
a) 此种情况下，如果客户端本身缺少完整性校验，可以尝试分析其代码，并修改其存储
的证书信息为代理工具的证书信息；
所有需要对客户端程序/设备进行操作后，才能解除的保密性或完整性措施，不算作风
险。
加密签名措施的破解，最终还是要根据客户端的具体实现方式进行分析。
下面的例子（从界面按钮的响应入手，找到 JAVA 层常量中存储对称密钥）可供参考。
首先在手机终端设置 HTTP 代理，指向电脑上的代理工具（BurpSuite、fiddler</li>
</ol>