Quantcast
Channel: CodeSection,代码区,网络安全 - CodeSec
Viewing all articles
Browse latest Browse all 12749

【WriteUp】labyrenth CTF windows track挑战(中)

0
0
【WriteUp】labyrenth CTF windows track挑战(中)

2016-09-09 14:11:06
来源:jmprsp 作者:默白

阅读:167次
点赞(0)
收藏





【WriteUp】labyrenth CTF windows track挑战(中)

文件: SquirtleChallenge.exe

SHA256:360BB1FF6D129C99BC7B361A7B52C4CBDE04E5710101C866893DBB7236815E15

加壳:无

体系结构: 32Bit

使用工具: exeinfo, IDA Pro

代码与二进制文件:https://github.com/jmprsp/labyrenth/tree/master/Window-Challenge-3

说明:这种挑战是用 C语言编写的,并且完全没有进行加壳。绕过标记需要很多反调试器的技巧。


【WriteUp】labyrenth CTF windows track挑战(中)

我们可以从上述的数字导出没有进行加壳的文件。

让我们尝试运行程序。


【WriteUp】labyrenth CTF windows track挑战(中)

我们估计需要加载 IDA Pro ,并且开始查找字符串。

我们首先需要知道密码是什么,每次输入错误都会导致 Squirtle出现问题。


【WriteUp】labyrenth CTF windows track挑战(中)

从上图我们不难发现主函数调用的是密码检查。


【WriteUp】labyrenth CTF windows track挑战(中)

所以我们定位了 squirtle 杀手,通过阅读装配说明我们可以看到,密码是"incorrect"。


【WriteUp】labyrenth CTF windows track挑战(中)

让我们再来看一下是否有squirtle出现问题。


【WriteUp】labyrenth CTF windows track挑战(中)

然而,answer.jpg 还是没有标记。

看起来像是存在很多反调试器检查防止我们生成正确的 answer.jpg。让我们简单修补一下二进制文件。


【WriteUp】labyrenth CTF windows track挑战(中)

一个简单的方法就是将mov eax,0 修补成 0x00401062;或者当它试验 eax 时修补程序调用方。下图所示就是Squirtle的活跃状态。


【WriteUp】labyrenth CTF windows track挑战(中)

上图演示的是一种非常常见的技术,用于检查是否存在调试器标记附加调试器。如果你一直在关注我的博客,这对你来说一定很熟悉了。对于这一种挑战来说似乎还是要调试。我仅仅是将jz 修补称 jnz @ 0x401684。如下图所示,Squirtle 也一切正常。


【WriteUp】labyrenth CTF windows track挑战(中)

只是修补 @ 0x401a45 (从 jbe 到ja) 指令,看一下是否可行。

我们成功了!Squirtle 不再出现问题了!


【WriteUp】labyrenth CTF windows track挑战(中)

让我们来看一下answer.jpg,接下来只需要解码。


【WriteUp】labyrenth CTF windows track挑战(中)

【WriteUp】labyrenth CTF windows track挑战(中)

标记: PAN{Th3_$quirtL3_$qu@d_w@z_bLuffiNg}


文件:JugsOfBeer.exe

SHA256:59E71EE7A6C110D77CB19337EF2E7DA26C9E367D44588C09C6A4635D91318D0A

加壳:无

体系结构:64Bit

使用工具:exeinfo, IDA Pro

代码与二进制文件:https://github.com/jmprsp/labyrenth/tree/master/Window-Challenge-4

说明:这种挑战是用c 语言编写的,并且使用64 位二进制编译。它是Water pouring puzzle修改后的版本。要解决这一挑战,需要找到最简洁的步骤达到指定的结束状态。


【WriteUp】labyrenth CTF windows track挑战(中)

所面临的挑战是来自用户的输入,这是否是典型的串行插件挑战?让我们检查看看它是否是通过exeinfo 和 IDA Pro.进行加壳的。从以下的数据可以看出该二进制文件没有进行加壳。


【WriteUp】labyrenth CTF windows track挑战(中)

【WriteUp】labyrenth CTF windows track挑战(中)

让我们开始分析。上图标出的是背跟踪字符串,其中遇到了@ 0x0140001280 函数。

如果你要分析函数,首先会遇到一个检查。


【WriteUp】labyrenth CTF windows track挑战(中)

从上图中我们可以看出,输入的字符串必须是32 个字符长。进一步深入之后我们会遇到检查,以确保输入的字符必须是 > = 0x31 并且< = 33。

若要手动检查,假设我们输入0,相当于 0x30。添加 0x30 到 0xFFFFFFCF 会返回 0xFFFFFFFF ,这样的检查测试就是失败的。

如果我们输入值是4,总和将会是 0x100000003。现在的检查只需要最后4 个字节,因此我们再比较 3和2。因为 3 大于 2,所以测试再次失败。

能够通过测试的唯一值就是在1 和 3 之间。


【WriteUp】labyrenth CTF windows track挑战(中)

如果我们设法清除所有验证测试,我们将会在(0x140001750)函数中到达该地址 0x14000151C 。如果此函数返回 0,我们会得到一个"再试一次"的消息。这么看来,我们需要确保此函数返回值是 1。


【WriteUp】labyrenth CTF windows track挑战(中)

缩放到@ 0x140001750 函数中,我们可以看到它为 0x0,0x0,0xD 0x7 设置了一个变量的初始状态。


【WriteUp】labyrenth CTF windows track挑战(中)

进一步深入函数,我们会看到0 x 的最终状态概览,(也可能是0xA,0xA或是0 x),代码将会设置检查值为 1!

可以观察到的是给定的输入数据以及相应的变量状态变化。换句话说,我们必须正确输入结束状态变量。

我们知道输入应该是32 个字符,这相当于 16 个组合。每个组合都可以是 0x11,0x12,0x13、 0x21、 0x22,0x23,0x31,0x32,0x33这些形式。但是状态不会改变,如果输入的值是 0x11,0x22,0x33,这将可能的输入减少到了只有 0x12,0x13,0x21,0x23,0x31,0x32这几种形式。

因此暴力破解永远不可能是一个明智的选择。

SMT Solver会做这项工作,但是让我们试试更容易的手动处理。我将0x140001750 的代码反编译到 php 脚本中。你可以在本文提供的 github 链接中找到脚本。现在让我们进一步观察。

如上图所示有一些有趣的东西。我们测试了6种 不同可能的组合作为第一个输入,我们最终只得到了3种不同的结果。第一个输入结果返回到初始状态,所以我们只有 2种不同结果。从下图中,我们只是需要顺着路径继续观察。


【WriteUp】labyrenth CTF windows track挑战(中)

假设我们只有这一条路径,我们可能永远达不到最终状态!


【WriteUp】labyrenth CTF windows track挑战(中)

【WriteUp】labyrenth CTF windows track挑战(中)

标记:PAN{C0ngr47ulaT1ons_buddy_y0Uv3_solved_the_re4l__prObL3M}



本文转载自 jmprsp
原文链接:https://jmprsp.wordpress.com/2016/09/03/labyrenth-ctf-windows-track-challenge-3

Viewing all articles
Browse latest Browse all 12749