首页 > WriteUp > N1CTF 2017中Misc2(APFS)题解及感悟

N1CTF 2017中Misc2(APFS)题解及感悟

2018年3月13日 发表评论 阅读评论

题目信息

题目描述

Apple released the brand new APFS on WWDC 2017 with a bunch of new features. With curiousity, Ben tried it out at once. Also, he left some surprise for you 🙂

题目提示

1. This challenge is not related to the version of your MacOS
2. look CAREFULLY at the challenge description apfs_snapshot
3. HFS+: 1 sec APFS: 10^-9 sec
4. A ^ B = F
5. L1: 16bytes-aligned L2: hint “apfs_snapshot” L3: hint “HFS+: 1 sec APFS: 10^-9 sec” L4: mtime LSB, A ^ B = zip

附件信息

文件名:497e2194-d11f-4dfd-9246-b9746f289bc7.dmg
文件哈希:5fcfa02736ea8bf82c01f37a0309369a(MD5)
文件大小:8,543,242 Byte

解题思路

下载得到一个dmg文件,dmg为macOS中的磁盘镜像格式。所以直接双击打开,发现需要密码


一开始以为是macOS的密码提示那个漏洞,尝试使用了低版本macOS(10.12.6)发现并没有密码提示,然后这时候提示1也出来了,所以明白点不在这。
于是拖到010editor中查看,在文件尾发现了密码N1CTF_APFS

输入密码后成功挂载。
挂在之后发现只有一个名为ctf的文件夹,里面存放了531个0 Byte的txt

然后在这里思路卡壳,队里评一个朋友发现这个dmg里还有一层快照

于是使用如下命令查看快照信息

发现快照名为ctf


然后尝试恢复快照,这里遇到了一个巨大的坑,在新版的macOS(10.13.3)上没有快照恢复的相关指令。于是又去py出题人,出题人表示没有问题。让我再去看看,网上找找相关介绍,找了一圈发现有个文章上说可以用apfs_snapshot来恢复
然而我cd到/System/Library/Filesystems/apfs.fs/Contents/Resources发现并没有apfs_snapshot,吐血…

不得已问朋友借了一个低版本的macOS(10.12.6)进行恢复的


然后在磁盘管理当中卸载然后重新挂载该磁盘即可
后来讨论也可以使用如下指令直接把这层快照挂载出来。

于是得到了镜像前后的磁盘


在这里为了获取快照前后的情况,花了好几个小时。。然后去py出题人,出题人表示提没问题,也和 macOS 版本无关,当时真的想吐血。
在我搞定了快照前后的磁盘之后。。。提示(提示2)又恰到好处的放出来了。。
接下来在这里思路卡壳了好久。尝试进行了数据恢复,找出来一大堆没用的东西,也浪费了很多时间。然后去py出题人,出题人表示让我认真读题。好好看看加粗的**with a bunch of new features**。然后我滚去把 WWDC 2017 中关于 APFS 所有的的新特性都看过去了。看来看去就一个快照,快照已经用过了。这时候提示3出来了。讲道理这提示我一时摸不着头脑,做了如下猜想

1. APFS 比 HFS+ 读写快,但是不可能快9个数量级啊,划掉
2. APFS 比 HFS+ 索引快,但是依然不可能快9个数量级啊,而且 APFS 里实际的数据只存一份,有点像Linux的硬链接,不对不对,划掉划掉
3. 肯定与什么东西是1秒(s)和1纳秒(ns)的差距,找找就行,Bingo

于是Google it,终于在Apple的开发者中心找到了这个详情。


原来 APFS 中记录的时间戳精确到纳秒,而 HFS+ 只精确到秒。看来问题在时间戳了
然后写 python 脚本提取时间戳,这里又遇到一个坑。我的python的os.path.getmtime()只能精确到小数点后两位时间,我对着这时间发了一小时呆。。。
不得已又去py出题人,出题人骂了我一顿,并表示爱莫能助。后来跟出题人进行了深入交流之后,出题人表示要不你换个工具,比如coreutils,然后就是 brew 启动!coreutils 安装!
终于可以看到精确的时间戳了

然后卡壳。这特么能看出个鬼。然后继续py出题人,出题人把我从头鄙视到脚,鄙视进每一个细胞。每一个粒子。在我诚心成念我是渣之后,出题人给出了有用的信息,去看看修改时间(mtime),好的,然后把快照前后的修改时间全部提取出来

取出来的数据如下图


此时提示4也上了,那A B 就很明确了,A表示快照前,B表示快照后,二者异或就行了
好的,异或,异或完了,我对着这数据又发呆了,这能看出来个鬼啊。不管了,继续py出题人,出题人问我你知道 LSB 么,我说我不知道(说的同时 Google 了一下),大概看了一下,最低有效位,用来做一些标志,比如0为正1为负之类的。
原来如此,那我把最后一位取出来,看下是奇还是偶不就拿到二进制数据了么,还没弄完就想了一下,不对啊,这才531个bit,够干嘛啊。继续问出题人,出题人表示让我仔细观察。那行,我先拿出来再看看
写了个py来提取最低位,最低位拿出来的数据如下

然后仔细观察。发现(和出题人py)数据的范围都是0-7,没有8和9,然后出题人提示2 ^ 3 = 8让我联想
然后想到八进制,这不刚好就是8进制么,每个数字就是3个bit,所以最终能得到一个531 bit * 3 = 1593 bit 的数据,然后此时提示4也很明白了,A为快照前,B为快照后,异或就行了,然后写程序处理一下。获得了所有数的二进制

然后得到拼接在一起的二进制数据


然后就简单了,每8 bit转一字节,然后写到文件,依然用python处理

得到了一个result文件,file一下发现是个zip包


直接解压,发现需要密码。

一开始以为是伪加密,但是修改了加密位之后发现还是如此,所以猜测是真加密,尝试使用之前的密码N1CTF_APFS,一次成功,得到flag

个人感悟

在做题的过程中始终与出题人保持联系,中间也有聊到一些有的没的,出题人表示这个题目是取材于真实的取证工作当中的,完完全全的还原了当时取证的详细过程。
做题过程中不断地在吐槽出题人脑洞,在做完这个题之后返回来看看,出题人并不脑洞,只能说自己当时的心态确实出现了问题。
自己认认真真的思考了一下比赛环境与真实环境的差异,以及什么是取证,怎么才算取证等等。
感觉到自己之前的眼界还是太局限,仅仅停留在比赛是远远不够的,在真实的取证工作中,不会有任何的提示,细心才是唯一的法宝,数据可能藏在任何地方,不漏掉任何蛛丝马迹,不放过一分一毫才是取证的真谛。
同时也感觉到自己的底子实在是太弱了,在了解到出题人的一些经历之后觉得自己还差得太远,除了基础性知识缺失,相关经验也十分匮乏。
在CTF中能够见到这种十分贴近于实战的题目是非常开心的,希望未来能够遇见更多这样的题目,CTF不是为了比赛而比赛,而是信安爱好者交流技术,切磋技能的平台。

其他说明

如需转载烦请注明出处
来自于LinE's Blog
From: http://blog.l1n3.net
谢谢~~

分类: WriteUp 标签:
  1. 本文目前尚无任何评论.
  1. 本文目前尚无任何 trackbacks 和 pingbacks.