-
-
[原创]看雪6月 京东 2018CTF 第十二题——在纸老虎的海洋中寻求破解之道
-
2018-7-8 22:55 2763
-
0x00 前言
一道纸老虎的题目,关键校验函数F5出来有2k多行,看起来可怕难逆,实际上很多没用的代码,解题关键在于定位有用的代码。
0x01 寻找校验函数
随便翻一下发现0x140002E00
这个函数很像关键校验函数,F5一看,很可怕,2400多行。xref一下,发现调用他的很可能是main函数,动态调试发现的确是(通过命令行参数识别,这题输入是命令行参数)。再看看校验函数,一开始觉得这题估计做不出了。(做题靠猜233)
(话说IDA没法自动识别64位PE的main函数的吗?还是做了混淆?)
看了一下加上动态调试发现0x14000E55C
很可能是一个strcpy
函数
然后main函数如下
if ( argc == 2 ) { my_strcpy(input, 260i64, argv[1], 260i64); check(&retaddr); result = 0; } else { //else里面的代码也很恐怖 //但是题目明显参数不为2就会给出"input like this:crackme.exe mykey"的提示 //猜测是一个动态生成字符串并输出的功能 }
strcpy
会把输入复制到一个全局变量,然后check会去访问它,并且校验。
0x02 纸老虎check函数
回到看起来很难逆check函数,思路是,不可能一行行逆这个东西,要找关键代码,即,它在哪里访问了输入,怎么访问的?说的高端点,叫做静态污点分析。
check 1
那么直接定位到访问input的地方,首先我看到的是这个:
if ( sub_140002AC0(iter) == -5808510693665524758i64 )// check [0:9] { iter[0] = input[1]; if ( sub_140002AC0(iter) == -5808494200991101593i64 ) { iter[0] = input[2]; if ( sub_140002AC0(iter) == -5808519489758550446i64 ) { iter[0] = input[3]; if ( sub_140002AC0(iter) == -5808507395130640125i64 ) { iter[0] = input[4]; if ( sub_140002AC0(iter) == -5808522788293435079i64 ) { iter[0] = input[5]; if ( sub_140002AC0(iter) == -5808606351177179115i64 ) { iter[0] = input[6]; if ( sub_140002AC0(iter) == -5808608550200435537i64 ) { iter[0] = input[7]; if ( sub_140002AC0(iter) == -5808609649712063748i64 ) { iter[0] = input[8]; if ( sub_140002AC0(iter) == -5808599754107409849i64 ) { v42 = 0i64; v37 = 0; v43 = 329472i64; } else { v42 = 0x100000000i64; v43 = 3750656i64; } //其他else一样
很有可能是一个校验,动态调试也发现input并未被改变,那么逐字节爆破
signed __int64 __fastcall sub_140002AC0(char *a1) { char v1; // dl signed __int64 result; // rax signed __int64 v3; // rax v1 = *a1; for (result = -3750763034362895579i64; *a1; result = 1099511628211i64 * v3) { ++a1; v3 = result ^ v1; v1 = *a1; } return result; } signed __int64 arr[9] = { -5808510693665524758i64, -5808494200991101593i64, -5808519489758550446i64, -5808507395130640125i64, -5808522788293435079i64, -5808606351177179115i64, -5808608550200435537i64, -5808609649712063748i64, -5808599754107409849i64 }; for (size_t i = 0; i < 9; i++) { for (size_t j = 0; j < 256; j++) { if (sub_140002AC0((char*)(&j)) == arr[i]) { printf("%c", (char)j); } } }
得出答案为KXCTF2018
,试一下发现不对(怎么可能这么简单
check 2
接下来看到的是一个疑似长度的校验
do ++len; while ( input[len] ); LODWORD(v307) = len; HIDWORD(v307) = 5 - HIDWORD(len); v529 = ((unsigned int)len + ((unsigned __int64)HIDWORD(len) << 32)) >> 12; //无用代码,稍微有点长 if ( (len & 0xFFF) + (v529 << 12) == 30 ) //...
看起来很复杂的操作,但是稍微看一下加上动态调试一下的话,就能发现这是在检查长度为30
check 3
紧接着看后面的代码,又访问了input
if ( (len & 0xFFF) + (v529 << 12) == 30 ) { v8 = 0; i_1 = 0; if ( len ) { iter_input = input; do { v184 = 0; v11 = *iter_input; LOBYTE(v184) = v11; v12 = (char *)&v184; v13 = -3750763034362895579i64; if ( v11 ) { do { v13 = 1099511628211i64 * (v13 ^ v11); v11 = *++v12; }//实际上是内联了sub_140002AC0 while ( *v12 ); } v14 = v8 + 1; if ( v13 != -5808600853619038060i64 ) v14 = v8; v8 = v14; ++i_1; ++iter_input; } while ( i_1 < len ); v1 = 32i64; if ( v14 >= 3 ) // 3个以上的9 { //... }
大概逻辑是,满足sub_140002AC0((char*)(&j)) == -5808600853619038060i64
的,要有3个以上。
同样爆破一下
for (size_t j = 0; j < 256; j++) { if (sub_140002AC0((char*)(&j)) == check3more) { printf("%c", (char)j); } }
结果为9
check 4
if ( sub_140002AC0(input) == 5728707748789076223i64 )// check whole input { LODWORD(v46) = 31; LODWORD(v47) = 0; }
整个input的hash(sub_140002AC0
貌似是一个hash函数,但是又没有雪崩效应)的检查,很明显现在条件不足。
check 5
其实到现在为止,还并没有找到爆破点,只是一直在“猜”。因为一般来讲,一个判断,更加复杂(明显有更复杂的代码)或者更难到达(比方说等于情况,任意输入一般都是不等于的可能性要更大)的一条路径,是正确答案所需要被走到的。前面几个check,也是根据这个“猜”的。
现在走下一个check,
memset(dll_name, 0i64, 0x104ui64); v80 = strstr(input, "9"); v81 = v80; dll_name[0] = v80[1]; dll_name[1] = v80[2]; dll_name[2] = v80[3]; dll_name[3] = v80[4]; dll_name[4] = v80[5]; // 第一个9后面取5个字节 mystrcat(dll_name, 260ui64, ".DLL", 260ui64); v82 = strstr(v81 + 1, "9"); snd9 = v82; *strstr(v82 + 1, "9") = 0; memset(&proc_name, 0i64, 260ui64); my_strcpy(&proc_name, 260i64, snd9 + 1, 260i64); //取第二个9到第三个9之间的字符串
其中这些函数的识别,肯定不是通过静态逆向,点进去发现一堆SSE就能吓跑人了,识别是通过猜+调试。
然后这刚好对应大于3个9的check,说明应该没逆错。
其中有个strcat把.DLL
加在后面,难道是把输入作为一个dll名?看了一下发现题目并没有给出dll附件。
那么继续看先吧,看看这两个参数是怎么被用的。这后面又有大量的代码,不管它们,用xref。发现一个调用
module_addr = ((__int64 (__fastcall *)(char *))((char *)v94 + *(unsigned int *)((char *)&v94[*(unsigned __int16 *)((char *)v94 + 2 * v98 + (unsigned int)v95[9])] + (unsigned int)v95[7])))(dll_name); ::module_addr = module_addr;
函数地址貌似是动态生成的,猜测这是一个LoadLibrary函数,x64dbg一看,果然是。
然后proc_name
的下一次被使用(当然现在还不知道是proc_name
v116 = (__int64 (__fastcall *)(_QWORD, signed __int64))((__int64 (__fastcall *)(__int64, char *))((char *)v109 + *(unsigned int *)((char *)&v109[*(unsigned __int16 *)((char *)v109 + 2 * v111 + (unsigned int)v110[9])] + (unsigned int)v110[7])))( module_addr, &proc_name); // GetProcAddr if ( v116 ) { len_1 = -1i64; do ++len_1; while ( input[len_1] ); critical = v116(0i64, len_1); } else { //...大量垃圾代码 } if ( critical >= 0 ) { //错误 } else { //正确 }
动态调试,发现call的函数是GetProcAddr
。然后critical是关键,动态调试改eflags发现后面如果critical<0
,可以显示正确信息。而如果GetProcAddr
返回NULL
,else分支中永远会产生>=0
的critical
值,所以明显是要给个能用的dll名和相应的函数名,使得其调用返回负数。
所以flag大概应该是KXCTF20189AAAAA9XXXXXXXXXXXXX9
。
但是,windows的API,一般都是返回0或正的,错误返回负那是Linux的API。这里我又卡了很久,想了好多种方法,最后决定还是猜一猜。首先dll名要是5的长度,第一个想到的就是ntdll.dll
,然后去System32
目录下找,发现还有一个是wow64.dll
,其他的感觉有点偏,应该不会用上(目前先这么猜
然后把所有长度为13的导出函数弄下来,我用的是IDA(LordPE啥的并没有办法复制。。。
然后通过check 4的那个hash值,来判断。(就先不管负不负了
然后注意,windows文件系统不分大小写,所以ntdll
或者NTDLL
甚至NtDlL
都可以,这个坑了我很久,也是后面才想到的。
具体爆破代码
const char* funcs[81] = { "TppTimerpFree","TpReleaseWork","TpReleaseWait","RtlAreBitsSet","LdrpUnloadDll","LdrpSnapThunk","RtlUnlockHeap","RtlLoadString","TppTimerAlloc","EtwEventWrite","RtlStartRXact","RtlAbortRXact","TpWaitForWait","RealSuccessor","RebalanceNode","RtlGetVersion","RtlpNtOpenKey","RtlCopyString","RtlSetAllBits","RtlFreeHandle","ZwQueryObject","NtOpenProcess","NtOpenSection","ZwCreateEvent","ZwSetValueKey","NtCancelTimer","ZwAccessCheck","NtAlertThread","NtCompactKeys","NtCompressKey","ZwConnectPort","ZwCreateTimer","NtCreateToken","ZwFilterToken","ZwOpenSession","ZwQueryEaFile","ZwQueryMutant","NtRequestPort","NtSetUuidSeed","ZwStopProfile","ZwUnloadKeyEx","DbgBreakPoint","DebugService2","RtlFillMemory","RtlZeroMemory","StringCbCopyW","RtlRemoteCall","LdrpCreateKey","PfxFindPrefix","PfxInitialize","IsTimeExpired","WaitForWerSvc","WerpProcessId","DbgUiContinue","RtlpLockStack","RtlApplyRXact","TpReleasePool","TpWaitForWork","LdrReadMemory","ResCHitsFlush","RtlCreateHeap","RtlIdnToAscii","RtlpTpIoAlloc","LdrResRelease","Wow64LogPrint","NameToOrdinal","Wow64FreeHeap","whNtWriteFile","whNtReplyPort","whNtCreateKey","whNtOpenEvent","whNtDeleteKey","whNtLoadKeyEx","whNtOpenKeyEx","whNtOpenTimer","whNtRenameKey","whNtSaveKeyEx","whNtSetEaFile","whNtTestAlert","whNtUnloadKey","Wow64pLongJmp" }; const char* libs[] = { "NTDLL", "WOW64" }; char flag[31] = "KXCTF20189AAAAA9XXXXXXXXXXXXX9"; for (size_t l = 0; l < 2; l++) { memcpy(flag + 10, libs[l], 5); for (size_t b = 0; b < 32; b++) { for (size_t s = 0; s < 5; s++) { if (b & (1 << s)) { flag[10 + s] |= 0x20;//转成小写 } } for (size_t i = 0; i < 64; i++) { memcpy(flag + 16, funcs[i], 13); if (sub_140002AC0(flag) == 5728707748789076223i64) { printf("%s", flag); } } } }
最终输出为KXCTF20189NTDLL9DbgUiContinue9
0x03 多解的可能性
实际上,flag并不一定是要我所说的那种形式,KXCTF20189AAAAA9...9...
也是有可能的,其中函数名长度小于13,然后后面的找一个序列使得check 4哈希碰撞,毕竟那么多长度为5的dll,还有那么多导出函数,有没有这种可能性呢?(我是懒的弄了
[培训]《安卓高级研修班(网课)》月薪三万计划,掌握调试、分析还原ollvm、vmp的方法,定制art虚拟机自动化脱壳的方法