Mike与猴子深入挖掘三星Gallery3d应用垃圾数据
这一切始于Michael Lacombe在2021年11月初在Physical and RAW Mobile Forensics Google群组上发布的一个帖子。该帖子涉及一个案例，三星手机用户声称收到了特定图片，但在访问后立即被删除。Mike被问及是否有可能确定这一点。由于不知道这个问题的直接答案，他开始分析三星Android 9设备。
Mike发现在local.db SQLite数据库中有一些三星Gallery3d应用的删除痕迹可见。具体来说，他在"log"表中看到了各种带时间戳的日志条目，这些条目与编码字符串相关联。在论坛成员"Tony"提示这些字符串是base64编码后，Mike开始了更深入的研究。
在研究过程中，他发现了Cheeky4n6monkey在2016年发布的这篇帖子。将该信息与他当前的案例数据进行比较后，他发现这些年来情况发生了很大变化，但这足以促使他进行更深入的挖掘。Mike询问这只猴子是否想一起参与，于是冒险开始了...
研究过程中的发现
总有新事物需要研究
三星Gallery3d应用已经存在多年，根据Google Play，它最后更新于2019年，版本为5.4.11.0。从测试设备的Gallery3d Android包(APK)中打开AndroidManifest.xml文件显示：
android:versionCode="1020000021"
android:versionName="10.2.00.21"
根据Android开发者文档，versionName显示给用户，而versionCode是一个正整数，随着每个版本发布而增加，可用于防止降级到早期版本。
这个应用更新频繁。在搜索测试数据时，我们发现几乎我们查看的每个设备都包含不同版本的应用，这反过来导致应用程序文件夹和数据库本身存储的信息也不同。
挖掘应用痕迹可带来当前未被解析的额外信息
据我们确定，目前没有商业或非商业取证工具处理三星Gallery3d应用数据库的删除痕迹。
我们用于分析数据和APK的一些开源工具包括：
数据分析：
- DB Browser for SQLite - 查看/导出SQLite数据库
- Cyberchef - base64解码字符串
- Base64 Decode and Encode网站 - base64解码字符串
- Epochconverter - 确认时间戳类型
- Android Studio
APK逆向：
- dex2jar - 将APK的classes.dex转换为Java .jar
- JD-GUI - 从.jar文件查看源代码
- JADX - 直接从APK文件查看源代码
我们还编写了自己的Python3脚本来协助批量转换base64编码字符串并输出到制表符分隔变量(TSV)格式。
三星Gallery3d应用的观察结果
这是安装在三星设备上的库存应用。它具有属于三星Android框架部分的库依赖项。因此，似乎没有简单的方法（如果有的话）在非三星设备上安装该应用程序。
三星Gallery3d应用位于用户数据分区：
/data/com.sec.android.gallery3d
从应用内发送到垃圾箱的文件位于：
/media/0/Android/data/com.sec.android.gallery3d
由于应用程序每个版本的差异以及研究由Mike的案例驱动，我们决定将本博客重点放在该应用程序版本(10.2.00.21)上。
缓存目录
在/data/com.sec.android.gallery3d/cache/内有多个缓存子目录。在这种情况下，/0文件夹包含较大的缩略图图像，宽度范围225-512像素，高度范围256-656像素，而/1文件夹有较小的缩略图，宽度范围51-175像素，高度范围63-177像素。还有/2、/3和/4文件夹。/2和/3为空，/4有一个大小为320x320的单个缩略图。
除了缩略图本身之外，这里似乎没有什么有用的东西。缩略图的名称似乎使用哈希算法生成。
数据库目录
/data/com.sec.android.gallery3d/cache/databases/中包含local.db SQLite数据库。
此数据库包含各种信息，包括：
- 画廊中的相册（"album"表）
- 记录与应用相关的各种操作的日志（"log"表），例如移动到垃圾箱、清空垃圾箱
- 当前在垃圾箱中的项目（"trash"表）
在后期版本中，我们注意到另一个名为"filesystem_monitor"的表。它包含时间戳、应用包名称（例如com.sec.android.gallery3d）和base64编码的文件路径。但是，由于此表不在Mike的案例数据中，我们不确定是什么触发了这些记录，需要进一步研究。
表观察
"album"表
以下是"album"表模式：
CREATE TABLE album (_id INTEGER PRIMARY KEY AUTOINCREMENT,
__bucketID INTEGER UNIQUE NOT NULL,
__absPath TEXT,
__Title TEXT,
folder_id INTEGER,
folder_name TEXT,
default_cover_path TEXT,
cover_path TEXT,
cover_rect TEXT,
album_order INTEGER,
album_count INTEGER,
__ishide INTEGER,
__sefFileType INTEGER DEFAULT 0,
__isDrm INTEGER DEFAULT 0,
__dateModified INTEGER DEFAULT 0)
重要字段：
_bucketID：通过对相册完整路径("_abspath")调用Java hashcode算法生成_abspath：相册的路径，例如：/storage/emulated/0/DCIM/Screenshotsdefault_cover_path：与相应相册关联的图像album_count：相册中当前存储的文件数
"log"表
以下是"log"表模式：
CREATE TABLE log (_id INTEGER PRIMARY KEY AUTOINCREMENT,
__category INTEGER NOT NULL,
__timestamp TEXT,
__log TEXT)
重要字段：
_timestamp：特定日志条目发生的时间戳文本字符串（格式为YYYY-MM-DD HH:MM:SS本地时间）_log：专有格式文本字符串，列出执行的"操作"和相关文件的base64编码路径
观察到的日志"操作"包括：
MOUNTED：未知何时触发，告知当前垃圾箱中有多少文件MOVE_TO_TRASH_SINGLE：用户从时间线或画廊视图将单个文件移动到垃圾箱时发生MOVE_TO_TRASH_MULTIPLE：用户从时间线或画廊视图将多个文件移动到垃圾箱时发生EMPTY_SINGLE：手动清空垃圾箱且当时垃圾箱中有一个文件时发生EMPTY_MULTIPLE：手动清空垃圾箱且包含多个文件时发生EMPTY_EXPIRED：文件在垃圾箱中停留预定时间后自动删除时发生
Base64编码字符串解码示例
原始值：
[MOVE_TO_TRASH_SINGLE][1][0][location://timeline?position=9&mediaItem=data%3A%2F%2FmediaItem%2F-575841975&from_expand=false][eTgcy4piFL3Pil4904piFb+KXj3LimIVh4pePZ2Uv4pePZeKXj2114pePbOKYhWHimIV0ZeKXj2TimIUvMOKYhS9EQ+KYhUlN4piFL1PimIVj4piFcmXil49l4pePbuKXj3Pil49ob3TimIVzL1PimIVj4piFcmXil49lbnNo4pePb3TimIVf4piFMjAxOTHimIUy4pePM+KXjzEtMeKXjznimIUyMeKXjzXil4844piFX+KXj1Nu4pePYeKYhXBjaGF0LmrimIVw4pePZw==bakWlla]
解码过程：
- 复制[ ]中的base64字符串
- 移除最后7个字符
- 从字符串开头移除3-6个字符，直到长度是4的倍数
- Base64解码字符串
- 移除填充字符，如Black Star和Black Circle
"trash"表
以下是"trash"表模式：
CREATE TABLE trash (__absPath TEXT UNIQUE NOT NULL,
__Title TEXT,
__absID INTEGER,
__mediaType INTEGER,
__width INTEGER,
__height INTEGER,
__orientation INTEGER,
__originPath TEXT,
__originTitle TEXT,
__deleteTime INTEGER,
__storageType INTEGER,
__burstGroupID INTEGER,
__bestImage INTEGER,
__cloudServerId TEXT,
__cloudTP TEXT,
__restoreExtra TEXT,
__volumeName TEXT,
__volumeValid INTEGER,
__expiredPeriod INTEGER)
重要字段：
__absPath：已删除文件的当前路径和文件名__Title：已删除文件的当前文件名__originPath：原始路径和文件名__originTitle：原始文件名__deleteTime：UNIX毫秒时间（UTC）__restoreExtra：JSON格式，包含各种元数据
脚本编写
编写了初步的Python 3脚本来解析"log"和"trash"表。由于观察到不同的"__log"字段格式，为"log"表编写了两个版本：samsung_gallery3d_log_parser_v10.py和samsung_gallery3d_log_parser_v11.py。
这些脚本提取"log"表中的各种字段，并对我们在数据中观察到的任何编码路径名称进行base64解码。
还编写了java-hashcode.py脚本将给定路径转换为"album"表中看到的"__bucketID"值。
总结
所有这些研究导致对逆向工程Android应用、新的独特哈希码算法和不同编码技术的更深入理解。进一步研究可能/可能不被现有工具解析的应用数据库仍然可以带来新的信息、感兴趣的文件夹、日志文件等。您可能会发现Android或特定应用的新版本中引入的新数据。
对于Mike的案例，使用本文的研究和脚本显示用户习惯于截屏或下载图像，然后在短时间内删除它们并清空垃圾箱。网络浏览器用于访问有问题的图像，但删除网络历史记录也是一个频繁的过程。恢复的截屏名称显示用户在特定时间使用了网络浏览器。不幸的是，这些日期和时间与有问题的时间不匹配，但这确实导致了在其他解析数据中未找到的其他调查时间。
与Mike一起研究这篇文章让猴子学到了更多关于三星Gallery应用的知识，获得了逆向工程Android APK的进一步经验，并保持了他的Python技能新鲜。像任何语言一样，流利度会因缺乏使用而退化。
编写了各种Python 3脚本来协助从三星Gallery3d应用(v10.2.00.21)解析"log"和"trash"表。这些表可能存储有关从三星Gallery3d应用内执行的图像删除的信息，例如时间戳和原始文件路径。
本文还展示了协作研究如何导致增加的输出/新工具。例如将Mike的测试观察与猴子的脚本编写相结合。与具有不同知识、技能、经验和新鲜视角的其他人合作的机会是无价的。利用这种经验可能与参加培训课程或网络研讨会一样好，甚至更好。
更多精彩内容 请关注我的个人公众号 公众号（办公AI智能小助手）
对网络安全、黑客技术感兴趣的朋友可以关注我的安全公众号（网络安全技术点滴分享）
公众号二维码
公众号二维码
