本文仅作学习记录，如有侵权，请联系删除！
使用备份功能来提取应用数据：
Android 从 4.0 起引入了使用adb的备份功能。 此功能可用于创建应用程序的备份及其整个数据。 这在取证上非常有用，因为取证员可以捕获应用程序及其整个数据
1、通过在终端中执行adb backup命令，后面附带应用程序的包名来完成。 如果我们不知道应用程序的准确包名称，我们可以使用pm列出所有包，然后过滤应用程序名称：
adb shell pm list package | grep ""
# 或者：其中-f标志指定要在包名称中查找的字符串。
adb shell pm list package -f lastpass
2、备份任何我们需要的应用程序：
adb backup [package name] -f [destination file name]
abd backup com.whatsapp -f whatsapp_backup.ab
3、一旦我们运行命令，它将暂停，并要求我们在设备上确认，如下面的截图所示：
4、解压此备份，以便从.ab文件获取数据库。 为此，我们将使用dd和openssl创建一个.tar文件，然后我们可以解压它：
dd if=whatsapp_backup.ab bs=24 skip=1 | openssl zlib -d > whatsapp.tar
1、数据文件
1.1 不安全的文件存储：（检查私有目录下的文件权限）
通常，开发人员为应用程序存储数据时，未指定文件的正确文件权限。 这些文件有时被标记为全局可读，并且可以由任何其它应用程序访问而不需要请求权限。
对 android 的每一个应用，android 系统会分配一个私有目录，用于存储应用的私有数据。
此私有目录通常位于“／data／data／应用名称／”。在测试时，建议完全退出客户端后，再进行私有文件的测试，以确保测试结果的准确性。（有些客户端在退出时会清理临时文件）
首先查看相关文件的权限配置。正常的文件权限最后三位应为空（类似“rw-rw----” ），即除应用自己以外任何人无法读写； 目录则允许多一个执行位（类似“rwxrwx—x” ）。如下图所示，（lib 子目录是应用安装时由 android 系统自动生成，可以略过）
区分文件夹和文件：
1、第一个代表文件的类型(d代表目录，-表示文件）
2、有显示文件大小的为文件，否则为文件夹
注意：当客户端使用 MODE_WORLD_READABLE 或 MODE_WORLD_WRITEABLE 模式创建文件时，shared_prefs 目录下文件的权限也会多出一些，这不一定是安全问题（Google 已不推荐使用这些模式）：
假设存在一个userinfo.xml文件，它储存了应用的用户的用户名和密码，不安全的文件存储可能导致任何其他应用程序也可以查看和窃取用户的机密登录凭据。 可以通过在开发应用程序时指定正确的文件权限，以及一起计算密码与盐的散列来避免此漏洞。
1.2 检查客户端程序存储在手机中的 SharedPreferences 配置文件：
权限检测完整后，再检查客户端程序存储在手机中的 SharedPreferences 配置文件，通常是对本目录下的文件内容（一般是 xml）进行检查，看是否包含敏感信息。
1.3 检查客户端程序存储在手机中的 SQLite 数据库文件：
由于大多数应用程序也使用数据库来存储数据，我们注意到在名为directory的包中有另一个名为databases的文件夹。 这里需要注意的一点是，这只会帮助我们从使用数据库的应用程序中提取信息，以便转储应用程序和其他相关信息
SQLite 是一个开源数据库，具有许多类似于其他关系数据库（如 SQL）的功能。在 Android 中选择 SQLite 的原因是其内存占用较低。 Android 开发者喜欢 SQLite 的原因是它不需要设置或配置数据库，并且可以在应用程序中直接调用。
SQLite 数据库的文件格式大多是前面提到的.db，但它们也可以为.sqlite，.sqlitedb或开发人员在创建应用程序时指定的任何其他扩展名。
我们可以使用命令行工具sqlite3来操作数据库：
# 1、打开数据库：
sqlite3 [databasename]
# 2、命令列出我们当前的数据库：
.databases
# 3、查看数据库中包含的表：
.tables
# 4、查看有关表的更多信息，例如列字段：
.schema
查询来查看列字段中的数据：
SELECT * from USER_RECORDS;
#其他补充：
.output # 将之后的 SQL 查询的输出保存到指定的文件
- 创建一个列表，包含从数据库创建到现在为止所执行的所有 SQL 操作：
sqlite> .dump
手动提取所有数据库的步骤：
- 进入设备，并创建一个文件夹来存储所有数据库
- 查找所有.db文件并将其复制到创建的文件夹
- 压缩文件夹并拉取它
# 1、在 SD 卡中创建一个名为BackupDBS的文件夹
adb shell
mkdir /mnt/sdcard/BackupDBS
# 2、查找所有.db文件并将其复制到BackupDBS
find . -name "*.db" -type f -exec cp {} /mnt/sdcard/BackupDBS \;
# 3、压缩并拉取文件
tar cvf backups.tar BackupDBS/
adb pull /mnt/sdcard/backups.tar backups.tar
检测 SQLite 数据库文件，在私有目录及其子目录下查找以.db 结尾的数据库文件。对于使用了 webView 缓存的应用，会在 databases 子目录中保存 webview.db 和 webviewCache.db。其中有可能会记录 cookies 和提交表单等信息。
将其下载到PC，用数据库查看工具即可查看这些文件中是否有敏感信息
nox_adb.exe pull /data/data/com.mwr.example.sieve/databases/database.db e:\adb-file\
1.4 检查客户端程序 apk 包中是否保存有敏感信息：
有些时候，客户端程序 apk 包中也是是保存有敏感信息的，比如检查 apk 包中各类文件是否包含硬编码的的敏感信息等（反编译 so 库和 5.逆向 classes.dex，检查 apk 包中各类文件是否包含硬编码的的敏感信息。对可执行文件可通过逆向方法寻找，也可以直接使用 16 进制编辑器查找）。
比如密钥硬编码导致阿里云OSS账户接管
直接在app里搜“Accesskeyid”，“aliyuncs” 等字符串也可以发现此类漏洞
1.5 检查客户端程序的其他文件存储数据，如缓存文件和外部存储：
在应用的私有目录以及 SD 卡中包含应用名称的子目录中进行遍历，检查是否有包含敏感信息的文件。查找应用和文件 IO 相关的系统调用（如 open，read，write 等），对客户端读写的文件内容进行检查
1.6 检查手机客户端程序的敏感信息是否进行了加密，加密算法是否安全：
查找保存在应用私有目录下的文件。检查文件中的数据是否包含敏感信息。如果包含非明文
信息，在 Java 代码中查找相应的加密算法，检查加密算法是否安全。（例如，采用 base64
的编码方法是不安全的，使用硬编码密钥的加密也是不安全的。）
威胁等级：
根据敏感信息泄露的程度进行威胁等级评分。若私有目录中存在存储了用户登陆密码（明文或只进行过一次单项哈希散列），手势密码（明文或只进行过一次单项哈希散列）或曾经访问过网址的 Cookie 等敏感信息的文件，此时为高风险，若不存在则无风险。
安全建议：
尽量避免在文件、数据库、日志等位置写入敏感信息。如果确实需要存储，应当进行加密。对于内存中的信息泄露，可以通过反注入、反调试来解决。此外，正常的文件权限最后三位应为空（类似“rw-rw----”），目录则允许多一个执行位（类似“rwxrwx—x”）
2、logcat 日志
本项主要是检查客户端程序存储在手机中的日志是否含有敏感信息
MemSpcetor 中提供了搜索功能，可以将内存 DUMP 到 SD 卡（注意，虚拟机得先配置 SD 卡），然后用 adb 或 monitor 复制到主机上查看
使用 adb 工具连接设备：
adb devices //查看安卓设备列表
adb -s 设备名称 其它命令 //当连接了多个设备时，选择操作的目标设备，否则会出错
# 使用 adb 查询 logcat 日志：
nox_adb.exe shell logcat -d > e:\1.txt
在 adb shell 中，有下列命令可用：
logcat # 持续输出日志，直到 Ctrl+C
logcat -d # 一次性输出日志缓存，不会阻塞
logcat -c # 清空日志缓存
测试步骤：
1、安装应用后，对应用进行使用。
2、同时使用 androidSDK 中的%ANDROID%/tools/monitor.bat 捕获输出的日志，
3、如果输出的日志中包含敏感信息，记录漏洞，停止测试
威胁等级：
根据敏感信息泄露的程度进行威胁等级评分。若相关信息中存在存储了用户登陆密码（明文或只进行过一次单项哈希散列），手势密码（明文或只进行过一次单项哈希散列）或曾经访问过网址的 Cookie 等敏感信息，此时为高风险，若不存在则无风险。
安全建议：
数据传输应做到加密处理，敏感信息不要输出在 logcat 日志中
