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/Screenshots

• default_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]

解码过程：

1. 复制[ ]中的 base64 字符串

2. 移除最后 7 个字符

3. 从字符串开头移除 3-6 个字符，直到长度是 4 的倍数

4. Base64 解码字符串

5. 移除填充字符，如 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 智能小助手）对网络安全、黑客技术感兴趣的朋友可以关注我的安全公众号（网络安全技术点滴分享）

公众号二维码

办公AI智能小助手

公众号二维码

网络安全技术点滴分享