乌云白帽大会“送票题”(一)

今年的第二届乌云白帽子大会的官网上放了四道“送票题”,不造小伙伴们有没有关注呢?小编觉得这四道题出的还真是让人看完想直呼“学习了”的感觉。贴心的91Ri小编帮大家从大会官网把题目和write up整理了下,发出来以供大家学(mo)习(bai)。

送票题之一——Android方向

题目:这个 Android 应用程序中隐藏了怎样的信息?(提示:不要放过任何一点蛛丝马迹)

Tip:flag为32位字符串

附件下载:http://pan.baidu.com/s/1hq7x5vm(解压密码:2qsb)

Write Up

首先give me five,然后发现apk解包之后那个牛逼的音乐名字叫five five five。

然后看了一下音乐里面有啥东西,发现有6条音轨,其中2条为正常音频的音轨,其余四条如下:

1

其中后三条音轨明显跟第一条音轨是降噪关系。所以音乐中并没听出来。

然后上位换为1,下位换为0,输出为文本:

查看一共有128位,可转换为16进制,得到32位字符串:

2

所以结果就是:

writeup by darksn0w

91Ri小编语:说实话,小编也有尝试解这题,因为我自己也有接触过一些初级的Android开发,平时又喜欢自己做些小音频,所以当看到这份write up时内心还是比较鄙视自己的。如果有下载官网上给出的附件zip的小伙伴会发现,在压缩文件中有一个MAC编辑过后留下的标(xuan)志(fu)文件夹_MACOSX,在这个文件夹有一个._givemefive.apk的文件,当你用记事本打开时,里面刚好有一个32位字符串,于是小编就这么傻傻地相信了TAT只能说我还是太天真啊[/此处满满全是泪]

送票题之二——逆向方向

题目:请对该程序通过逆向工程,计算出一组可用的 key 和授权文件 wooyun.lic。最后请提交 flag 与 wooyun.lic。

(1) 程序只能运行在 Windows 7 / 8 / 8.1 x64 系统上。

(2) 程序由两部分组成。需要先逆向分析第一部分,才能得到第二个程序。

更新说明:之前使用的大数库有一个整数溢出的 bug,新版本中已经修复了。该 bug 不影响解题,也不影响之前计算出的 key 的有效性。感谢 Riatre 同学指出该问题!仅更新了 enc.bin

2015-06-16 19:00

附件下载http://pan.baidu.com/s/1hqerqwG(解压密码:mm32)

Write Up

CrptoMat

Description

程序只能运行在 Windows 7 / 8 / 8.1 x64 系统上。

程序由两部分组成。需要先逆向分析第一部分,才能得到第二个程序。

CrptoMat: Initial Observation

这是描述中提到的需要逆向分析以得到第二部分的“第一部分”。首先观察下载得到的压缩包CrptoMat-1.7z,里面包含两个文件,CrptoMat.exe及enc.bin。 其中CrptoMat.exe是一个32位Windows Console应用程序,而enc.bin根据文件名猜测,应为加密后的“第二个程序”。

这样,描述中的“程序只能运行在 Windows 7 / 8 / 8.1 x64 系统上。”成为了一个疑点:为什么要求x64呢?

程序在我这里运行时会直接Crash,故决定先在IDA中载入CrptoMat.exe观察一下。 IDA识别出了main函数,其中最后一个printf的参数不是有意义的字符串,且前后有以’\x10’为单字节key对其xor解密。 针对这种类型的操作,我们可以写一段简单的 IDAPython 脚本,在idb中将其解密,以方便分析。

接下来执行 xor(0x423480, 32, 1, 0x10) 即可解密该字符串。不幸的是,进行完这一步后,该字符串仍然不是有意义的字符串。

检查该字符串的xref,可以发现还有另一处地方对其进行了xor解密,追踪调用来源可以发现,这个exe注册了三个TLS Callback,会在程序加载时被执行。三个TLS回调函数中分布着两种混淆。

CrptoMat: Obfuscation

这些函数中使用了大量形如 74 01 0F 的花指令。对应方式为将0F的部分直接nop掉即可。(在IDA中,可以使用Edit -> Patch program -> Change byte在idb中进行简单的patch。

除此之外,这些函数开始的位置还有大量的在64位及32位代码段间切换的指令。参考roy g biv的Heaven’s Gate: 64-bit code in 32-bit file。形如

可以注意到,切换后立刻切了回来,并且中间没有夹杂任何x64代码,因此这一段也只是作为简单的反调试 & 花指令,不对实际分析以及Hex-Rays Decompiler的工作产生任何影响。 简单的将其整段替换为nop即可。

去除所有上文描述的干扰,并用Alt+K手动调整一些IDA分析错的call带来的栈影响后,Hex-Rays Decompiler(所谓的F5)已经可以正常工作了。 虽然这三个TLS Callback逻辑比较简单,没有Hex-Rays插件也可以很容易理解。

CrptoMat: Constants

第一个TLS Callback主要是利用IsDebuggerPresent进行了简单的反调试。

第二及第三个TLS Callback中使用简单的xor解密了一些常量,填充了另一个常量。将其都按上文的方式还原后,这个程序的逻辑变得清晰了起来。

CrptoMat: Decryption

程序在main中,利用TEB进行了简单的反调试(如果检测到有DebugFlag则会修改之前填充的一个常量)。 然后首先在0x403620处获取了一些系统API的地址。 接下来位于0x403280处的函数打开并读入enc.bin,调用位于0x402B70处的函数解密,并写入输出文件checkkey.exe。

下面重点关注解密函数,其首先调用位于0x4012B0的函数进行了初始化,这个函数开头动态填充了一些常量表,将之前在TLS Callback中填充的一个32字节的常量再次逐字节xor了0x73,然后存入栈中。不妨认为这是Key。 后半段则有一些类似于某些对称加密算法中的Key Schedule的过程,但其中使用的所有常量表都是动态填充的,不方便识别具体算法。

先不管他,回到解密函数中,可以发现逻辑非常复杂的循环的次数为 19329 , 注意到 $ 19329 \times 16 $ 恰好等于enc.bin文件的大小。我们不妨猜测这是一个块大小为16字节的块加密算法。

那么,块大小为16字节,密钥长度为32字节的对称加密算法,首先想到的大概就是 AES-256 了吧。不妨试一试,万一是真的呢 XD

没有IV,先假装它是ECB模式,试试吧。

 

看上去解密成功了,然而很快发现,输出的文件看上去并不是原始的checkkey.exe。看上去有一些“多余”的部分。

在懒得分析CrptoMat.exe中具体的逻辑的情况下,对着该文件脑补,并且观察CrptoMat.exe中的解密代码,每解密一块16字节,仅输出8字节。 不妨认为只要取每16字节的前8字节即可。

然后发现这样是对的 :)

checkkey: Initial Observation

我们得到了一个checkkey.exe,简单观察后可以发现,它是一个x64 Windows Console应用程序。 拉进IDA分析,程序明显的分为了两个部分,第一部分验证命令行参数传入的key,第二部分验证wooyun.lic,并和key似乎有某种关联。

这个程序代码上没有任何故意设置的干扰,Hex-Rays Decompiler可以工作,虽然由于编译优化的原因,得到的部分结果不太容易理解。

checkkey: check_key

检查key的函数对输入的key进行了各种检查,要求满足一些条件(具体条件直接见以下代码),我们使用Z3来求解符合条件的串。

运行即可在0.3s左右的时间内得到一组解,xVAH6xh67H34IaBPZpKqtIdO9vrqbP9P。

checkkey: check_license

经分析可知,check_license首先计算了文件前4字节以外的部分的”CRC32″校验和,并与前4字节表示的DWORD进行比较。 注意这里的”CRC32″与规范的CRC32不同,有一处移位时故意用算术右移代替了逻辑右移。

接下来,程序计算了除前20字节以外的部分的MD5哈希,并与文件+0x4处开始的16字节进行比较,期望其相等。 然后,程序期望接下来的8字节为00 07 11 F9 F6 AB 13 AE。

满足以上所有条件后,程序用类似于外层CrptoMat中的方式在内存中xor解密了两个字符串,分别为:

相信比较敏感同学看到65537之后会立刻将第一个字符串作为一个十进制整数丢进 yafu 或 msieve & ggnfs 中分解。一边让机器跑着一边进行接下来的逆向 #_#

随后,程序对文件+0x28处开始直到文件结尾的内容进行了“某种计算”,期望得到的结果长度大于等于30,并将得到的结果与命令行输入的key比较,期望相符。 此外,还计算了得到的结果的MD5哈希,并与文件+0x18处开始的16个字节比较,期望相符。

我们有充足的理由相信这里的“某种计算”就是RSA。稍作逆向后可以发现没有Padding,直接将字节作为256进制的Big Endian整数解释。 到了这里,把它分解出来,然后根据私钥计算出一个合法的license即可。

checkkey: factorization

该模数N有120位十进制数位,如果没有特意包含比较弱的因子的话,应当是使用 msieve + GGNFS 分解比较迅速,约需要5~6小时。 然而,由于不能排除其故意带有比较弱的因子的可能性,先交给 yafu 去pretest一下吧 :)

结果 yafu 在10秒后给出了分解结果。

有趣的是,它一共有5个素因子,所谓的RSA-MP,不过这并没有影响。

checkkey: Tiro Finale

最后,写个简单的脚本生成wooyun.lic。

 

Trivia

checkkey.exe中实现的高精度减法处理借位的时候有一个小bug,导致取模在一些边界情况下也是错的。比如$2^{65537} \mod N$就算不对。 不过实际解题时需要的计算并不会遇上这样的边界问题 :-)

91Ri小编语:由于没有接触过逆向,所以小编对这道题还是没什么说话权的,不过当初这倒题目刚出来的时候,我很积极地把链接发给了会逆向的小伙伴,当时exe只要点开就会崩,小伙伴发现了出问题的地方,但很遗憾当时并不能完全解决,本来以为是脑洞题。后来write up出来之后,小伙伴说不是脑洞题,只是解题中用到的一个相关知识他没有接触过,所以不会,总的来说还是很遗憾的,小伙伴表示这道题32位与64位代码段间切换的技巧好棒
(反正没接触过逆向的我是听不懂TAT)。大家有没有和我一样觉得write up写的好详细好有条理呢?~

另外,据小道消息,这道题是蓝莲花的同学解出来的,不愧是冠军团队,赞赞赞!~

一共四道题,我们先整理两道出来供大家学习吧~至小编写完这篇稿子为止,还木有人解出最后一到题目喔,各位同学可以到乌云白帽子大会的官网去试试看喔,说不定最后一张门票就是你的啦~

链接在这里http://summit.wooyun.org/puzzle/detail#!