ISCC2018_leftleftrightright-Writeup
leftleftrightright(150)
这个题学到了不少东西,值得认真写一下
下载好文件后发现是upx的壳,upx -d直接脱掉后运行,发现是经典的check输入的题目(作为一个linuxer,首先用wine模拟运行了一下,这也为我后来的解题减少了不少麻烦,后边会说到)
ISCC2018_re150 [master●●] file leftleftrightright.exe
leftleftrightright.exe: PE32 executable (console) Intel 80386, for MS Windows, UPX compressed
ISCC2018_re150 [master●●] upx -d ./leftleftrightright.exe
Ultimate Packer for eXecutables
Copyright (C) 1996 - 2013
UPX 3.91 Markus Oberhumer, Laszlo Molnar & John Reiser Sep 30th 2013
File size Ratio Format Name
-------------------- ------ ----------- -----------
18432 <- 10752 58.33% win32/pe leftleftrightright.exe
Unpacked 1 file.
ISCC2018_re150 [master●●] file leftleftrightright.exe
leftleftrightright.exe: PE32 executable (console) Intel 80386, for MS Windows
ISCC2018_re150 [master●●] chmod +x leftleftrightright.exe
ISCC2018_re150 [master●●] ./leftleftrightright.exe
0009:fixme:msvcp:_Locinfo__Locinfo_ctor_cat_cstr (0x32fcbc 1 C) semi-stub
aaaaaaa
0009:fixme:msvcp:_Locinfo__Locinfo_ctor_cat_cstr (0x32fd1c 1 C) semi-stub
try again!
请按任意键继续...%
拖到IDA里分析之前,先搜索了一波字符串,发现存在IsDebuggerPresent和疑似加密后的flag:s_imsaplw_e_siishtnt{g_ialt}F,如果需要调试,要先nop掉IsDebuggerPresent,先静态分析,拖到IDA里F5大法,main函数的伪代码和汇编都很乱,但大致可以看出把我们的输入经过一通操作后扔给sub_401090()函数check,通过即为正确的flag,同时能看出flag的长度为29(0x1D)
if ( sub_401090(v16) || v15 < 0x1D || (v17 = "flag is right!", v15 > 0x1D) )
v17 = "try again!";
v18 = sub_401BF0(std::cout, v17, sub_401E30);
std::basic_ostream<char,std::char_traits<char>>::operator<<(v18, v19);
system("pause");
这时首先想的是通过调试快速确定怎么对输入进行变化的,于是到windows下试图用Ollydbg调试(调试之前要先找到对IsDebuggerPresent的调用并nop掉,可以在IDA的import页面通过x交叉引用找到),这时遇到了第一个问题:文件在windows下直接crash
扔进OD单步调试,很快就能定位到crash出现的位置
crash出现的原因不难分析,此时[ds + 0x40600]是一个不可读的地址,这时候想起来windows vitia(writeup用的是windows 2008 server)及其以上版本引入了aslr技术,导致程序载入的基址是随机的,如果取值的地址是写死的(比如这道题),就很可能跳到不可读的地址,程序crash,细节可以看这里
一些trick:
- OD把代码当成数据分析时,可以选中,点退格让OD重新分析
- ctrl + A可以重新分析当前模块的代码,也能把误识别的数据转为代码
同时找到了一个很方便的工具可以固定程序的载入地址,固定程序的载入地址随机化后,打开程序,终于可以正常工作了,于是上OD调试,跟了几步指令后忽然意识到,check函数没有进行查表,亦或这些操作,只有很简单的位移,这说明我们的输入并不会发生改变,只会发生移位,如果我们能得到一串字符移位后的结果,就可以找到移位的规律,进而恢复出flag
//check函数不会改变输入
int __cdecl sub_401090(unsigned int a1)
{
int v1; // ecx
const char *v3; // esi
unsigned int v4; // edx
bool v5; // cf
unsigned __int8 v6; // al
unsigned __int8 v7; // al
unsigned __int8 v8; // al
if ( !a1 )
return 0;
v3 = "s_imsaplw_e_siishtnt{g_ialt}F";
v4 = a1 - 4;
if ( a1 < 4 )
{
LABEL_6:
if ( v4 == -4 )
return 0;
}
else
{
while ( *(_DWORD *)v1 == *(_DWORD *)v3 )
{
v1 += 4;
v3 += 4;
v5 = v4 < 4;
v4 -= 4;
if ( v5 )
goto LABEL_6;
}
}
v5 = *(_BYTE *)v1 < (const unsigned __int8)*v3;
if ( *(_BYTE *)v1 != *v3 )
return -v5 | 1;
if ( v4 != -3 )
{
v6 = *(_BYTE *)(v1 + 1);
v5 = v6 < v3[1];
if ( v6 != v3[1] )
return -v5 | 1;
if ( v4 != -2 )
{
v7 = *(_BYTE *)(v1 + 2);
v5 = v7 < v3[2];
if ( v7 != v3[2] )
return -v5 | 1;
if ( v4 != -1 )
{
v8 = *(_BYTE *)(v1 + 3);
v5 = v8 < v3[3];
if ( v8 != v3[3] )
return -v5 | 1;
}
}
}
return 0;
}
于是我们直接在check函数之后下断点
运行,输入29位不同的数据后观察
找到了移位前后的字符串,这样就可以恢复flag了,脚本如下:
ISCC2018_re150 [master●●] cat solve.py
#!/usr/bin/env python
# -*- coding: utf-8 -*-
__Auther__ = 'M4x'
encrypt = "s_imsaplw_e_siishtnt{g_ialt}F"
before = "abcdefghijklmnopqrstuvwxyzABC"
after = "onpqmlrskjtuihvwgfxyedzAcbBCa"
flag = [encrypt[after.find(c)] for c in before]
print "".join(flag)
ISCC2018_re150 [master●●] python solve.py
Flag{this_was_simple_isnt_it}
ISCC2018_re150 [master●●]
以上是写writeup时偶然发现的新解法,新解法出现的原因应该是windows 2008 server的load机制与windows 10不同,windows 2008 server的更低级,原解法如下:
固定exe的装载基址后,发现运行到cin时,程序又crash了,这时才想到windows10下dll的装载基址也是随机的,通过比较aslr_disabler.exe处理前后的exe,发现只对pe头的一个字段改了一位(可以通过010 editor的compare功能看出),于是想到了两种思路:
- 找到exe调用的dll,通过修改pe头固定其基址
- 在od调试的过程中手动指定其基址
很明显第一种方法得不偿失,麻烦不说,很有可能造成系统环境的崩溃。于是尝试在OD调试的过程中指定dll的基址,试了一下发现要改的地方太多,放弃了。这个时候想到用wine模拟时程序可以正常运行,于是搜索了一下调试wine加载的程序的方法,google的所有结果都指向一个工具winedbg,按照man手册的说明,还可以以gdb模式启动,尝试了一下,发现在自己电脑上各种报错,把patch后的exe发给一个用arch的大佬学弟试了一下,一次就成了(吐血),比较后发现是wine的版本问题,于是果断卸载了apt安装的2.0的wine,手动编译了一个3.8的wine,然后winedbg --gdb ./leftleftrightright.exe,终于跑起来了,之后的方法就和使用ollydbg时一样了,直接下断点查看处理前后的字符串即可
patch后的exe和解题脚本可以在我的github上找到
一些补充:
- 这道题目不难,但确实学到了不少东西,美中不足是把加密后的flag硬编码太弱了,根据题目名称leftleftrightright很容易猜出正确flag(我在编译wine时试了几次已经猜出了flag)
- winedbg使用gdb模式启动时,如果使用pwndbg作为插件,会卡到怀疑人生,使用peda或者gef就会快得多(这也是大佬学弟告诉我的)
- 刚开始也尝试过在windows vista以下的版本(如windows xp)上运行exe,但不兼容,搜索字符串可以看出这个程序是用vs2015编译的,搜索了一波发现除非重新编译,否则不能在exe上运行
- 通过以上分析可以得出load的随机化程度 wine ≈ xp < windows 2008 server < win10,这也能看出微软在安全性上做了不少工作
- 程序中还有一些0xcc(int 3),但分析过之后发现这些字节全在函数之间,不会被调用,因此对调试不会造成影响
- 如果非要去除的话,可以参考如下idapython脚本,patch完记得保存(Edit -> Patch Program -> Apply Patches to Input File)
- 如果非要去除的话,可以参考如下idapython脚本,patch完记得保存(Edit -> Patch Program -> Apply Patches to Input File)
- 对于一些细节,我还是没想明白,比如如何高效安全的固定dll的装载基质,IsDebuggerPresent在wine下为何失效(不patch此处的exe也可用winedbg调试),能否不重新编译使vs2015生成的exe兼容xp,为何从源码编译的wine会有下图中的报错以及如何解决(apt安装的2.0版wine没有如下报错)
- 如果有师傅对以上问题以及这篇writeup有任何见解,欢迎指教