云原生工件的取证分析

云原生工件的取证分析

摘要

云工件的取证分析仍处于起步阶段；当前的方法压倒性地遵循在客户端设备上收集产物的传统方法。在本研究中，我们提出了分析云原生数字产物的概念——即维持网页/SaaS应用程序持久状态的数据对象。与传统应用程序不同，传统应用的持久状态以本地文件系统中的文件形式存在，而网页应用则动态下载所需状态，且在本地存储中不留痕迹。

以谷歌文档作为案例研究，我们证明了此类产物可能具有完全不同的结构——其状态通常以完整的（或部分的）用户编辑操作日志形式保存。因此，获取产物在某一时刻的状态快照的传统方法从取证角度而言存在固有的缺陷，因为它忽略了有关文档随时间演变的潜在关键信息。此外，云原生artifacts没有标准化的外部表示，这对其长期保存和解释提出了疑问。

引言

软件行业的传统商业模式一直是软件即产品（SaaP）；也就是说，软件的获取方式与任何物理产品一样，一旦销售完成，所有者便可以在无限长的时间内按自己的意愿使用它。另一种模式——软件即服务（SaaS）——是一种基于订阅的模式，直到大约二十年前广泛的互联网接入出现后才开始变得切实可行。

从概念上讲，从SaaP向SaaS的转变将运行软件及其环境的责任从客户转移到提供商。从技术上讲，这种转变得益于互联网作为通用通信手段的发展，并且由于网页浏览器成为标准化的客户端用户界面（UI）平台而得以实现。

数字取证的传统分析模型是以客户端为中心的——调查人员处理物理证据载体，例如存储介质或集成计算设备（如智能手机）。在客户端（或独立）设备上，很容易识别出计算发生的位置以及结果/痕迹的存储位置。因此，研究重点一直放在发现和获取每一条日志和时间戳信息，并提取应用程序和操作系统可能遗留的每一丁点丢弃的数据。

Gmail于2004年的推出——首个被广泛使用的Web 2.0应用程序——表明，大规模基于Web的SaaS部署所需的所有关键技术前提已经具备。亚马逊在2006年推出首批公共云服务，使得任何供应商都可以租用可扩展的服务器端基础设施，并成为SaaS提供商。十年后，向SaaS的过渡正全速推进，从取证角度理解这一转变的需求也变得愈发关键。

这一巨大的技术变革为取证带来了全新的定性挑战；这种挑战无法通过简单调整工具和实践来解决。具体而言，SaaS模型打破了人们熟悉的以客户端为中心的世界：代码和数据都通过网络按需交付，因此成为动态的取证目标。例如，一个Google Docs文档在本地磁盘上仅显示为一个超链接；实际内容仅在浏览器中下载并可供编辑。

在这项工作中，我们通过直接访问数据源——服务提供商，利用公共和私有API以及数据结构来解决该问题。这催生了一种新方法，我们相信，这种方法预示了未来云取证工具的构建方式。

相关工作

基于客户端的数据获取与分析

钟等人（2012年）分析了四种云存储服务（亚马逊S3、谷歌文档、Dropbox和印象笔记），以查找这些服务在客户端系统上留下的可用于刑事案件的痕迹。他们报告称，所分析的服务可能会根据各自特定的功能产生不同的取证残留物，并提出了一种基于从客户端系统收集和分析目标云存储服务取证残留物的云存储服务取证调查过程模型。该流程包括从 Mac/Windows系统（如果可用）收集易失性数据，然后从互联网历史记录、日志文件以及目录中提取数据。对于移动设备，他们通过root安卓手机来收集数据；对于iPhone，则使用 iTunes信息，例如备份的iTunes文件。其目的是检查所收集的数据中是否存在云存储服务的痕迹。

在黑尔（2013年）中，黑尔分析了亚马逊云盘，并讨论了从计算机访问或操作亚马逊云盘账户后留下的数字取证残留物。操作亚马逊云盘账户有两种方式：一种是通过网页浏览器访问的网络应用，另一种是亚马逊提供的可在系统上安装的客户端应用。在对这两种方法进行分析后，他发现了存在于网页浏览器历史记录和缓存文件中的界面取证残留物。此外，他还发现了存在于Windows注册表、应用程序安装文件的默认位置以及用于跟踪待处理的上传/下载任务的SQLite数据库中的应用程序取证残留物。

Quickand Choo(2013)分析了Dropbox并讨论了在访问或操作Dropbox账户后留下的取证残留物。通过哈希分析和关键词搜索，他们试图确定Dropbox提供的客户端软件是否被使用过。这包括从浏览器历史记录（Mozilla Firefox、谷歌Chrome浏览器和Microsoft Internet Explorer）中提取账户用户名，以及通过多种途径检测Dropbox的使用情况，例如目录列表、预读取文件、链接文件、缩略图、注册表、浏览器历史记录和内存捕获。在后续研究中，奎克和朱（2014年）采用类似的概念方法分析谷歌云盘的客户端操作及其取证残留物，并为调查人员提供了入手点。

马蒂尼和朱（2013）研究了ownCloud的操作，这是一种自托管的文件同步和共享解决方案。因此，它占据了一个略有不同的细分领域，因为客户端和服务器端更有可能由同一个人或组织控制。他们能够恢复包括同步和文件管理元数据（日志、数据库和配置数据）、缓存文件（描述用户存储在客户端设备上并上传到云环境的文件，或反之）以及浏览器取证残留物在内的取证残留物。

基于API的数据获取与分析

到目前为止讨论的客户端获取方法都有一个共同的重大假设；即所有相关数据取证残留物都可以从客户端获取。问题是，在一般情况下这并不成立，且在通常情况下也可能不成立。如图1所示，客户端不再能被视为数据的原始来源。相反，它仅维护一个可能不完整（多方面原因）且可能过时的缓存版本。

考虑到上述功能架构，基于客户端的云托管数据获取存在三个主要缺陷：

部分复制。 最明显的问题是，使用云存储账户的客户端可能都没有数据的完整副本。目前，云存储服务提供商提供选择性复制，以避免本地存储空间较小的设备（如智能手机）不堪重负。随着数据在线累积，未来维护完整的本地副本将变得越来越不现实（也无必要）。亚马逊已提供每年60美元的无限存储服务，而要将如此大量的数据在本地克隆是不切实际的。从取证角度来看，基于客户端的取证获取无法掌握整体情况，也无法保证完整性。

取证残留物版本。 大多数存储服务提供自动版本跟踪功能，可保留先前版本的副本用户文件的版本。然而，这些版本不存在于客户端缓存中，只能通过网页界面按需调用。从取证角度而言，这是基于客户端的取证获取存在盲区且不完整的另一个方面。

云原生artifacts。 网络应用程序很少在客户端设备上存储持久状态。虽然存在一些显著的例外情况，例如用户凭证的缓存以及断开连接时的离线操作，但通常情况下所有数据都托管在服务器端。这就引出了云原生数据的概念，我们用它来描述 SaaS应用所使用的、未在客户端持久存储的内部数据结构。这显然给客户端方法带来了问题，因为具有取证价值的数据在本地并不存在。

在Roussev等人(2016)中，我们提出，要完全解决该问题的前两个方面，唯一的方法是利用服务提供商的官方API。我们开发了一款云盘取证获取工具fi，fikumodd，能够对四大主流云服务提供商进行完整的基于API的获取：kumodd，即谷歌云盘、Dropbox、Box和微软OneDrive。我们的工具可以枚举并下载与上述任一账户关联的所有文件及其所有修订版本。此外，它还能通过API获取云原生artifacts的快照，并以标准格式（如PDF）进行保存。

然而，kumodd无法获取云原生artifacts的原始形式，因为它们不属于官方支持的API的一部分。例如，一个谷歌文档文档以超链接形式表示，在API中没有方法可以获取其内容。从开发者的角度来看，此类取证残留物是内部数据结构，没有必要通过API提供对它们的访问。实际上，Web应用的客户端和服务器组件之间存在一种私有通信协议，该协议与公共协议一同使用（图1）。

本讨论的其余部分将重点放在云原生取证残留物的获取与分析上，并以谷歌文档作为案例研究。

理解谷歌文档

在本次讨论中，我们使用谷歌文档来指代谷歌提供的整套在线办公、生产力和协作工具。我们使用文档、表格、幻灯片等来指代该套件中的各个应用程序。

很可能，首个具有取证应用的云原生工具是Draf tBack(draftback.com)：由作家兼程序员詹姆斯 Somers开发的浏览器扩展，可重播文档的完整历史记录。该代码的主要目的是让作者能够回顾自己的写作过程，并分析他们的写作方式。巧合的是，这正是取证调查人员希望实现的功能——能够将文档回溯到其生命周期中的任意时间点，直至最开始的状态。

除了提供Quill开源编辑器（陈和马卢根）中所有纯文本编辑操作的浏览器内播放外，Draf tBack还提供了一个分析界面，该界面将编辑会话的时间映射到文档中的位置（图2）。

这对于长期存在的文档可以用来缩小调查范围。索默斯的研究虽然并非出于取证目的，但却是软件即服务分析的一个示例，该分析不依赖于客户端上驻留的跟踪数据，所有结果仅通过（部分）逆向工程网络应用的私有协议得出。假设调查人员拥有有效的用户凭据，或根据法律命令由谷歌提供此类凭据，则可在现场进行检查；任何具备浏览器和互联网连接的地方均可进行。

这些观察结果成为我们自身工作的起点，旨在构建一个真正理解调查过程需求的取证工具。

文档 2010年，Google推出了新版Google Docs（ Google,2010a），支持更强大的实时在线协作。新的文档编辑器名为kix，处理渲染元素的方式类似于传统文字处理器e明显区别于以往使用可编辑HTML元素的做法。Kix是“专门为基于字符的实时协作设计的操作转换”（Google, 2010b）。（操作转换是一种并发管理机制，它摒弃了预防性锁定，转而通过动态实时解决用户操作冲突，变换编辑操作以实现一致性。）另一个重要的技术决策是保留文档修订的详细历史，使用户可以回退到任意先前版本；此功能对拥有编辑权限的任何协作者均可用。

谷歌的存储修订版本方法也与大多数先前的解决方案不同——不是保留一系列快照，而是保留自文档创建以来完整的编辑操作历史记录。当需要特定版本时，日志从头开始重放，直到目标时间；重放整个日志即可得到当前版本。这种设计实际上意味着不存在不可逆转地销毁数据的删除操作，这具有重要的取证（和隐私）意义。

为了支持细粒度修订以及协同编辑，用户操作会根据输入速度每150毫秒就向服务器推送一次。在协作模式下，这些细粒度操作（主要是文本和图像的插入与删除）在服务器端合并，并记录文档的统一历史。经过可能的转换后，这些操作会被推送到其他客户端，以确保文档保持一致且最新的视图。

通过公共API可获取的主要修订版本数量与向用户显示的主要修订版本一致。主要样式更改似乎会促使更多此类修订的产生；例如，我们用于记录实验的工作文档拥有超过5100个增量修订，但仅有六个主要修订。然而，出于逆向工程目的而使用的测试文档，则有27个主要修订，而增量修订少于1000个。自上次编辑以来的时间流逝似乎也起到一定作用。开始一个新会话似乎不足以触发一个新的主要修订。

文档的内部表示在传递给客户端时，采用名为changelog的JSON对象形式。该结构深度嵌套，但每次修订包含一个数组，数组的大多数元素包含对象（键值对）。每个数组以该次修订的标识信息结尾，具体包括：Unix格式的纪元时间戳、作者的谷歌ID、修订编号、会话ID、会话修订编号以及修订内容本身。

每次文档被打开时，都会生成一个新会话，并跟踪该会话内发生的修订数量。某些修订（例如插入对象）以单个条目的形式出现，其中包含多个操作，表现为多重集合，该多重集合包含一系列嵌套字典。字典中的键是缩写（2e4个字符），几乎可以肯定是为了性能原因，但并非完全混淆。

变更日志包含一个特殊的分块快照对象，其中包含从起始修订版本创建文档所需的全部信息。快照的长度因嵌入的kix对象和段落的数量而有很大差异；对于从第1版开始的修订，它仅有两个条目（包含默认文本样式）。

对于文档中包含文本的任何修订，快照的第一个元素是由文档中所有文本组成的纯文本字符串，后跟标题、副标题和 h1到h6标题的默认样式、文档语言以及首个段落索引和段落样式。接下来的几个元素都是嵌入对象（如评论或建议）的kix锚点，然后列出每个连续格式区域及其应应用的样式，以及用于从目录跳转到这些区域的段落及其关联ID。

teethe最后三个字母“ent”的输入。因此，快照包含字符串 “Test docum”的文本插入（第4行，已高亮），以及一些默认样式定义和其他基本文档属性。文档的日志部分包含一个字符串“ent”的插入（第2行，已高亮），并带有相应的时间戳和标识信息。

更一般地，从修订版本x到修订版本y的文档描述将包含一个修订版本x时的状态快照，后跟y x个变更日志中的条目，用于描述修订版本x与y之间的每一次单独更改。通过能够选择要加载的更改范围，kix可以在允许用户回溯历史的灵活性与提高效率、避免重放过久远的文档历史之间取得平衡。

特定版本范围的变更日志可以通过使用现代浏览器内置的开发工具手动获取。登录并打开文档后，网络请求列表中包含以下形式的加载URL：
https://docs.google.com/documents/d/ /load?< doc_id>&start¼ &end¼ &token¼ ，其中doc_id是唯一的文档标识符，fier, start_rev是初始修订版本（快照），end_rev是修订版本的结束范围，而auth_token是身份验证令牌（图4）。修订版本从1开始，且不得超过实际的修订数量，且起始值不能大于结束值。

要从命令行检索文档，我们可以使用地址栏中的URL和必要的认证头来构造请求（谷歌Chrome浏览器提供了一个便捷的“复制为cURL”选项，可自动构建完整的命令行）。或者，也可以在浏览器窗口中打开该URL。

为了便于自动化采集，我们开发了一个名为kumodocs的 Python工具，该工具使用Google Drive API获取指定版本范围内的变更日志。它还能解析JSON结果，并将其转换为扁平化的CSV格式，以便利用现有工具进行自动化处理。每一行包含时间戳、用户ID、修订编号、会话ID、会话修订、操作类型，后跟一个字符串参数参与任何修改的键值对字典。这种格式更接近传统日志的格式，便于手动检查编辑事件以及使用命令行文本处理工具。样式修改被编码为字典，以便能够方便地（在Python或J avaScript中）用于在不同的编辑器中重放这些事件。

此过程的第一阶段是获取文档的纯文本内容，然后应用解码后的格式样式，并添加嵌入对象（如图像）。一旦获得变更日志，通过应用所有字符串插入和删除操作并忽略其他内容，获取纯文本相对容易。

操作页面元素（如表格、公式、图片等）的操作类型为ae（添加元素）、de（删除元素）或te（绑定元素）；其中后者与kix锚点和kix ID相关联。元素插入操作附带一个包含大量初始化值字典的样式调整多重集合。像评论和建议这类对象在变更日志中仅包含锚点和ID信息，没有实际的文本内容。

图片元素插入包含源位置（URL），上传的files包含可通过HTML5文件系统API访问的本地URL（filesystem: https://docs.google.com/persistent/docs/documents/ /image/ ）。从谷歌云盘插入图像时，变更日志中的源URL来自googleusercontent.com域名（谷歌的内容分发网络）。在进一步检查修订文档中的HTML元素后，我们发现即使在插入后立即查看，它们引用的是另一个CDN链接。正如预期，从URL插入的图像在内容分发网络中也有副本，因为源可能在插入后不可用。

通过分析网络请求，我们发现（内部）文档API具有一个renderdata方法。该方法使用POST请求，并采用与用于获取变更日志的加载方法相同的请求头和查询字符串：
https://docs.google.com/document/d/ /渲染数据?id¼

renderdata请求体实际上包含一个以如下形式的批量数据请求：

观察到的cosmoId值对应于变更日志中嵌入图片的i_cid属性，而容器是文档ID。渲染数据响应包含一组全球可读的 CDN托管的URL列表。

为了了解CDN存储的图像的行为，我们将两张全新拍摄的照片（从未在互联网上发布过）嵌入到一个新文档中；其中一张图像直接从本地文件系统嵌入，另一张通过谷歌云盘嵌入。在文档中删除这两张图像后，CDN托管的链接仍然可以访问（无需身份验证）；我们通过一个每小时下载一次这些图像的脚本进行了测试，这些链接在整个测试期间（72小时）始终保持可用。

在相关实验中，我们以类似新表格的方式嵌入了两张不同的图片。然后，我们从谷歌云盘中删除了整个文档；图片链接仍在内容分发网络上保持有效约一小时，之后才消失。综合来看，实验表明，只要文档的至少一个版本仍引用嵌入的图像，该图像就会继续在内容分发网络上可用；一旦所有引用都被删除，该对象就会被垃圾回收。从取证角度而言，这种行为非常有趣，有可能揭示出所有者早已认为已被销毁的非常陈旧的数据。

从安全角度来看，内容分发网络的设计并非不合理——它采用的是死投的安全模型：任何知道位置的人都可以访问。鉴于标识符的长度及其明显的随机性，要猜测它是不可行的。从应用设计的角度来看，有必要保留可能用于恢复文档先前版本的 CDN对象。然而，这种行为对用户而言并不一定直观，并可能导致早已被认为已删除的取证残留物重新出现。

恢复到先前版本是另一种不会破坏文档编辑历史的操作；相反，会向历史记录中添加一个包含所需新状态快照的恢复操作。换句话说，撤销操作本身可以稍后被回退，并且可以检查其之前的状态，这与谷歌选择的仅追加设计保持一致。

幻灯片和绘图

我们发现，幻灯片应用程序使用类似的变更日志方法来传输取证残留物的状态。也就是说，数据被作为抽象数据结构进行通信，并由JavaScript客户端代码解释和渲染。日志的整体格式相似，最主要的区别在于，它以数组的数组和值的形式发送，而不是像文档那样以字典和值的形式发送（图5）。看起来字典中的所有键都被移除，仅发送了对应的值，实际上相当于一个元组。这使得逆向工程稍微繁琐一些，但仍然允许我们像之前一样跟踪所选操作与其编码之间的映射关系。

每个更新中的第一个元素包含一个整数，用于编码类型字段，其中15对应字符串插入，16对应文本删除，3对应文本框创建，依此类推（附录提供了我们发现的总结）。在描述更复杂事件时使用的多重集合操作，例如新幻灯片的创建，其操作详细说明了所插入幻灯片的类型，随后是该幻灯片中每个文本框的若干插入操作。

第一张幻灯片包含一个标题和副标题，其中标题的ID为i0，副标题的ID为i1。其他每个文本框都有唯一的ID，例如 g675a3a03f_0_2，每当创建具有该ID的新文本框时，末尾的元素会递增。第一个数字似乎是版本/会话标识符，关闭幻灯片并重新打开网页会导致其增加1；10位前缀也会偶尔变化，但我们尚未确定确切情况。文本框描述包含一个六元素列表，用于描述页面中的起始x;y坐标、方向以及关联的标量大小。幻灯片的更改粒度比文档更高，因为每个字符都有自己的修订版本，而不是偶尔与其他字符组合在一起。每次插入都会详细说明文本框的ID以及要在该文本框中插入的索引，删除操作类似，提供文本框ID和范围。

添加幻灯片由一组操作（一个事务）组成，包括创建幻灯片、设置幻灯片属性以及根据模板插入文本框。复制幻灯片是一个较大的事务，包含创建相同类型的幻灯片，并对原幻灯片上的每个文本框执行添加Box操作，以及相应的文本和样式添加。删除是另一个事务，其中首先从幻灯片中逐个删除每个 Box，然后删除幻灯片本身。更改幻灯片主题会在事务内产生大量操作，包括创建一个全新的幻灯片，并为每个文本框进行创建操作，且每个文本框关联有30到40个修改操作，随后删除旧幻灯片的所有文本框，最后删除旧幻灯片本身。

如图6所示，绘图对象的变更日志结构是幻灯片变更日志的一个简化版本。与图5不同，此图显示了一个由单个包含字符串参数“Test”的文本框组成的绘图的完整产物。

表格

我们对Sheets应用采用了与之前相同的差异分析方法，并监控了与服务器的网络交互以了解其协议。结果显示，Sheets在每次更新后也支持增量版本控制，但其工作方式有所不同。当请求特定版本时，响应是一个可供浏览器直接使用的 HTML文档。换句话说，所有计算和HTML编码都在服务器端完成，最终结果被直接提供给浏览器进行渲染，无需动态调整。

尽管仍然可以提取每次更新后的电子表格状态，但关键信息（例如公式）无法获取。

解决此问题的方法是使用Google Sheets API，该API提供了提取单个单元格内容（包括公式）的手段。由于表格采用的通信协议与其他工具大不相同，因此这一工作超出了本次讨论的范围。用于检索单元格区域的API调用结果采用Atom聚合格式（RFC 4287, 5988）以XML编码，其解析复杂度将高于文档和幻灯片中所使用的轻量级JSON。

建议和评论

建议“trackchanges”是文档中标记的修改，协作者可以选择接受或拒绝；这类似于Microsoft Word中的功能。它们会出现在变更日志中，并被类似地处理为其他更改；然而，它们具有专用的操作类型，允许编辑器在格式和用户界面方面进行不同处理（图7）。

评论未在变更日志中明确表示；而是存在一个kix锚点ID（图8）。幸运的是，Google Drive API提供了一个list方法，该方法允许检索与文档关联的所有评论，包括已删除的评论。然而，已删除评论的实际内容已被移除；仅可获取当前和已解决的评论。

因此，评论和建议都是文档长期历史的一部分，并且可以通过公共或私有服务接口轻松恢复。

PoC工具：kumodocs

目前，我们的概念验证工具kumodocs可用于处理文档和幻灯片中的取证残留物。给定一个修订版本范围（对应于一个时间间隔），该工具将获取并解析变更日志，并生成指定最后修订版本时文档的纯文本版本。kumodocs还将获取在此期间至少部分时间内活跃的所有嵌入式图像。

对于幻灯片，我们将变更日志中的所有文本编辑映射到各个文本框，并将结果输出为一系列文件：slide0_box0.txt、slide0_box1.txt、slide1_box0.txt等（空文件被跳过）。我们还会获取与文档相关联的所有建议和评论，并将其保存为适当命名的文本文件。

摘要

我们分析三个谷歌文档应用程序的经验验证了我们的初衷。具体而言，我们发现即使在同一工具集套件中，维护和渲染取证残留物内部状态的方法也以非平凡的方式存在差异。根据观察到的差异，几乎可以确定这三种产品是由不同的团队开发的，每种产品都带有其设计者的印记。

文档最接近大多数网络应用的开发方式：数据以结构化的 JSON形式在抽象层面进行通信，并在客户端进行渲染。幻灯片的协议显然不是为人类可读而设计的，其设计似乎主要受效率考量支配。操作的数值编码和扁平数据结构（使用JSON仅是名义上的）使其在客户端的解析速度更快。与文档类似，数据以纯形式传输，所有渲染均由客户端完成。表格则采用完全以服务器为中心的方法：所有计算和所有渲染工作都在服务器上完成。

在没有标准化的外部表示形式（例如独立客户端应用程序所使用的那些）的情况下，显然有必要开发工具和（极有可能是）支持获取、长期保存和解释云原生artifacts的新格式。与DraftBack类似，我们的原型具备使用Quill开源编辑器进行文本编辑基本回放的能力。

讨论

根据我们的分析，对谷歌文档取证残留物的取证检查有若干有趣的启示。

在线预览。 一个意外的结果是，调查人员以编辑模式查看文档（以便访问自创建以来的所有修订版本）并非不合理。由于文档的历史记录是一个仅追加日志，任何用户都几乎不可能破坏文档，因为所有修改都可以轻松撤销。然而，整个文档删除仍然是一个问题，因此我们需要一个“写保护工具”应用/浏览器扩展，用于监控HTTP请求并过滤掉可能破坏证据的请求。

黄金一小时。 似乎谷歌的内容分发网络（用于托管嵌入对象（图像））在删除后仍会将这些对象保留大约一小时。通过结合浏览器和内存取证方法以及残留的CDN对象检索，可以借此机会从最后一刻的删除操作中进行潜在恢复。

逆向工程仍然至关重要。 我们的经验表明，在云取证环境中，尽管重点可能会转向网络协议，但逆向工程仍然是必需的。虽然先前的研究（Roussev等，2016）表明公共API是证据的重要来源，但此次经验重新凸显了通过逆向工程分析SaaS应用的私有协议和数据结构来理解其工作原理的必要性。幸运的是，这是一种灰盒（而非黑盒）分析，因为我们能够监控所有通信，并可在关键节点对客户端（JavaScript）代码进行插桩。

长期保存是一个挑战。 其中一个概念性挑战在于既要存储获取的证据，又要保留正确解释它的能力。内部数据（如变更日志）是不可替代的证据来源；然而，需要对其进行解释或渲染，才能对分析人员具有意义。与传统的独立应用程序不同，我们无法保留应用程序代码（该代码在客户端和服务器之间划分）；因此，任何解决方案都将涉及某些等效性翻译的层次。到目前为止，我们已经解决了最基本的问题——重放纯文本编辑命令以及获取嵌入式图像。更完整的解决方案是将日志转换为类似应用程序中的命令，从而忠实还原所有格式，保留原有的视觉外观。

谷歌文档的代表性如何？ 对于后续工作而言，了解谷歌文档的设计在多大程度上代表了更广泛的在线协作应用套件至关重要。我们对一些类似工具进行了初步研究，例如Zoho Writer、微软Word Online和Dropbox Paper。初步印象是，根据此类应用程序的实时要求，增量更新会持续发送到服务器，并且文档的细粒度版本会对用户（以及调查人员）可用。与谷歌文档不同，我们没有轻易识别出可以检索编辑操作日志的内部应用程序编程接口机制。然而，有迹象表明，日志本身很可能存在于服务器上，并且向用户显示的版本是由其动态生成的。还有一些迹象表明，仅追加日志这一概念对开发者具有吸引力；例如，在ZohoWriter中恢复到较早版本会导致该版本被添加到用户可选择的版本列表中（标记为“已恢复”）；Word和Paper具有类似的概念。

结论

在本研究中，我们对谷歌文档的取证残留物进行了初步检查，旨在理解云原生产物所带来的挑战与机遇。我们将此类产物定义为由托管在云基础设施中的网页/SaaS应用所使用的数据对象，且这些数据对象不会在客户端设备上持久存储。本文对领域的具体贡献如下：

问题的提出。 我们认为，客户端取证获取证据的传统方法完全无法察觉云原生artifacts。此外，最重要的产物是包含重要历史信息的内部数据结构。因此，我们需要开发能够获取并解释这些内部数据结构的取证工具。此外，我们还需要开发出能够独立还原产物历史以用于归档目的的方法。

取证残留物 &行为分析。 我们对谷歌文档的取证残留物进行了分析，主要关注文档和幻灯片应用程序及其变更日志内部数据结构。我们在萨默斯初步分析的基础上进行了大幅扩展，并系统地记录了我们的发现（附录：变更日志键）。此外，我们研究了将对象嵌入取证残留物所使用的技术，并表明谷歌的内容分发网络是可恢复数据的一个潜在巨大来源，且似乎具有无限时间范围。

PoC工具开发。 这项工作的主要实际成果是一套用于提取和处理文档及幻灯片历史记录的概念验证工具的开发。目前，我们能够提取文本content forany fi细粒度修订、嵌入的图像和绘图，以及与文档相关的评论历史。该工具名为kumodocs，可在GitHub上获取，地址为https://github.com/kumofx/kumodocs。

除了取证之外，该工具还可用于执行快速的隐私审计，因为它能够识别所有表面上已被删除但仍可恢复的图像、建议和评论。

在不久的将来，我们期望完成对谷歌文档套件中剩余应用程序的分析，并发布一份更完整的规范文档，类似于（梅茨，2012）。在此之后，我们期望构建一个完整的解决方案，以实现对谷歌文档证据的筛选、获取和长期保存。