去年做的一道 CTF,清理文档

0x01 The .init and .fini Sections

参考下面链接:
http://www.ru.j-npcs.org/usoft/WWW/www_debian.org/Documentation/elf/node3.html

简单说一下,即.init中的指令,在main()函数之前执行,.fini中的指令,在main()函数返回后执行;

一段代码验证之:


#include <stdio.h> void my_init() __attribute__((constructor));
void my_fini() __attribute__((destructor)); void my_init()
{
printf("init?\n");
} void my_fini()
{
printf("fini?\n");
} int main()
{
printf("I'm in main()\n");
return 0;
}

输出结果:

ez[@ubuntu](http://my.oschina.net/u/555627):~/xdctf$ ./init
init?
I'm in main()
fini?

下面链接,有更详细介绍:

https://www.codeaurora.org/git/projects/qrd-gb-ssss-7225/repository/revisions/e34c19e51778b1f44682192040db577967da636b/entry/android/bionic/linker/README.TXT

DT_INIT:ELF loaded时执行
DT_INIT_ARRAY:其中的函数被顺序执行,完成main()前的初始化操作,通常存放于.init_array段
DT_FINI:ELF unloaded时或进程结束时执行
DT_FINI_ARRAY:与DT_INIT_ARRAY类似,用于main()后扫尾

0x02 IDA静态分析

用IDA打开re100,发现是一个Linux x86_64程序;没有main()函数,可能编译时修改了入口函数,可参考:

http://stackoverflow.com/questions/8116648/why-is-the-elf-entry-point-0x8048000-not-changeable-with-the-ld-e-option?lq=1

http://stackoverflow.com/questions/4272316/in-an-elf-file-how-does-the-address-for-start-get-detemined

没有_start函数,但发现有一处start函数与_start函数类似,猜测ld时被修改,具体可参考:

http://eli.thegreenplace.net/2012/08/13/how-statically-linked-programs-run-on-linux/

我们平常所说的__libc_start_main()函数,其实在_start()中被调用:


.text:0000000000400590 public _start
.text:0000000000400590 _start proc near
.text:0000000000400590 xor ebp, ebp
.text:0000000000400592 mov r9, rdx
.text:0000000000400595 pop rsi
.text:0000000000400596 mov rdx, rsp
.text:0000000000400599 and rsp, 0FFFFFFFFFFFFFFF0h
.text:000000000040059D push rax
.text:000000000040059E push rsp
.text:000000000040059F mov r8, offset __libc_csu_fini
.text:00000000004005A6 mov rcx, offset __libc_csu_init
.text:00000000004005AD mov rdi, offset main
.text:00000000004005B4 call ___libc_start_main
.text:00000000004005B9 hlt
.text:00000000004005B9 _start endp

比较一下正常的_start与该题目中的start函数发现,入口被从main()修改为了sub_4008E1():

### 修改后 start
.text:000000000040053E push rsp
.text:000000000040053F mov r8, offset nullsub_1
.text:0000000000400546 mov rcx, offset loc_400AA0
.text:000000000040054D mov rdi, offset sub_4008E1
.text:0000000000400554 call ___libc_start_main
### 正常的 _start
.text:000000000040059E push rsp
.text:000000000040059F mov r8, offset __libc_csu_fini
.text:00000000004005A6 mov rcx, offset __libc_csu_init
.text:00000000004005AD mov rdi, offset main
.text:00000000004005B4 call ___libc_start_main

继续分析sub_4008E1()函数,其开始处有ptrace()的简单反调试;如果需要gdb调试,则nop之即可,这里静态分析暂不管它;

初步分析此函数功能,首先栈上有两个字符串,分别为命名为g_key和g_enc:


0x0601280 g_key "\\|Gq\\@?BelTtK5L`\\|D`d42;"
0x6012A0 g_enc ";%#848N!0Z?7'%23]/5#1\"YX"

sub_4008E1()函数将用户输入的12个字符flag与g_key进行一系列异或运算后,与g_enc进行比较,如果相等,则输入的flag验证通过;

如果这样做,得出的结果永远是错的,其实题目也有个Hint,Don’t believe your eyes..因为我们忽略了.init_array和.fini_array中的代码,而这两段中的函数,对g_key和异或算法均有影响;由上面收集的资料可知,其分别会在sub_4008E1()函数之前和之后执行;

.init_array:0000000000601000 ; =============================================================
.init_array:0000000000601000
.init_array:0000000000601000 ; Segment type: Pure data
.init_array:0000000000601000 ; Segment permissions: Read/Write
.init_array:0000000000601000 ; Segment alignment 'qword' can not be represented in assembly
.init_array:0000000000601000 _init_array segment para public 'DATA' use64
.init_array:0000000000601000 assume cs:_init_array
.init_array:0000000000601000 ;org 601000h
.init_array:0000000000601000 off_601000 dq offset sub_400600 ; DATA XREF: .text:0000000000400AB1 o
.init_array:0000000000601008 dq offset sub_400669
.init_array:0000000000601008 _init_array ends
.init_array:0000000000601008
.fini_array:0000000000601010 ; ===============================================================
.fini_array:0000000000601010
.fini_array:0000000000601010 ; Segment type: Pure data
.fini_array:0000000000601010 ; Segment permissions: Read/Write
.fini_array:0000000000601010 ; Segment alignment 'qword' can not be represented in assembly
.fini_array:0000000000601010 _fini_array segment para public 'DATA' use64
.fini_array:0000000000601010 assume cs:_fini_array
.fini_array:0000000000601010 ;org 601010h
.fini_array:0000000000601010 off_601010 dq offset sub_4005E0 ; DATA XREF: .text:0000000000400AB9 o
.fini_array:0000000000601018 dq offset sub_400787
.fini_array:0000000000601018 _fini_array ends
.fini_array:0000000000601018

分析发现sub_400669()函数对g_key进行了异或操作,也就是我们用来异或的g_key并不是内存中的内容:


size_t sub_400669()
{
size_t result; // rax@1
int i; // [sp+Ch] [bp-14h]@2 result = dword_601340;
if ( dword_601340 != 1 )
{
dword_601340 = 1;
for ( i = 0; ; ++i )
{
result = strlen(key_str_1);
if ( i >= result )
break;
key_str_1[i] ^= 6u;
}
}
return result;
}

而sub_400787()函数中才是我们真正需要破解的代码:


char *sub_400787()
{
char *result; // rax@13
signed int v1; // [sp+8h] [bp-18h]@9
int i; // [sp+Ch] [bp-14h]@1
unsigned int j; // [sp+Ch] [bp-14h]@4
unsigned int k; // [sp+Ch] [bp-14h]@9 for ( i = 0; i < strlen(key_str_1); ++i )
char_array_24[i] = key_str_1[i] ^ char_array_16[i - 12 * (((0x0AAAAAAAAAAAAAAABLL * i) >> 64) >> 3)];
sub_4006D5(char_array_24, 24, 12);
for ( j = 0; j <= 0x17; ++j )
{
if ( char_array_24[j] <= 31 )
char_array_24[j] += 32;
}
v1 = 1;
for ( k = 0; ; ++k )
{
result = k;
if ( k > 0x17 )
break;
if ( char_array_24[k] != key_str_2[k] )
v1 = 0;
}
if ( v1 )
{
result = output_;
if ( output_ )
{
output_[15] = '!';
puts(output_);
exit(0);
}
}
return result;
}

根据算法逆推脚本如下:


def get_flag(g_enc, g_key):
flag = []
size = 24 for i in xrange(0, size, 1):
if ( ord(g_enc[i]) - 0x20) <= 0x1F:
flag.append(ord(g_enc[i])-0x20)
else:
flag.append(ord(g_enc[i])) for i in xrange(0,size/2,1):
flag[i] ^= flag[17-i]
flag[17-i] ^= flag[i]
flag[i] ^= flag[17-i] for i in xrange(0,size,1):
flag[i] = flag[i%(size/2)] ^ (ord(g_key[i])^6) for i in xrange(0,size/2,1):
flag[i] = chr(flag[i]) return "".join(flag[:size/2]) if __name__ == '__main__':
g_key = "\\|Gq\\@?BelTtK5L`\\|D`d42;"
g_enc = ";%#848N!0Z?7'%23]/5#1\"YX"
flag = get_flag(g_enc, g_key)
print flag
ez[@ubuntu](http://my.oschina.net/u/555627):~/xdctf$ python get_flag.py
U'Re_AwEs0Me

根据提示结果均为小写,最终flag为:XDCTF{u’re_awes0me}

XDCTF2015_re100的更多相关文章

随机推荐

  1. 一、JAVA内存区域与内存溢出异常

    在虚拟机自动内存管理机制的帮助下,不在需要为每一个操作区写相对应的delete/free代码来进行内存释放.进而不容易出现内存泄露和内存溢出的问题,由虚拟机管理内存,貌似这一切看起来很好.也正是因为j ...

  2. 牛客第二场Dmoney

    链接:https://www.nowcoder.com/acm/contest/140/D 来源:牛客网 题目描述 White Cloud has built n stores numbered to ...

  3. Linux 下Qt实现守护进程实例(转)

     原文地址:Linux守护进程的编程方法(含实例) 作者:lingdxuyan 参考文献 Linux信号列表(zz) Linux 守护进程的编程方法 linux上编写守护进程的例程 Linux下后台守 ...

  4. listener.ora和tnsnames.ora格式解析

    listener.ora是oracle数据库服务端的监听配置文件,包括协议.IP地址和端口等内容:tnsnames.ora是oracle数据库客户端的连接配置文件,也是对应的协议.IP地址和端口等内容 ...

  5. shiro过滤器解释类

    anon -- org.apache.shiro.web.filter.authc.AnonymousFilter authc -- org.apache.shiro.web.filter.authc ...

  6. win10打文件预览功能

  7. shell脚本分析一

    Shell 是一个用 C 语言编写的程序,它是用户使用 Linux 的桥梁.Shell 既是一种命令语言,又是一种程序设计语言.Shell 是指一种应用程序,这个应用程序提供了一个界面,用户通过这个界 ...

  8. NOIP2018复赛获奖名单

    根据<CCF NOIP2018复赛获奖分数线及名额分配办法>,现将NOIP2018复赛获奖名单公告如下: 复赛提高组一等奖获奖名单 复赛提高组二等奖获奖名单 复赛提高组三等奖获奖名单 复赛 ...

  9. window.open()打开页面

    一.window.open()支持环境:JavaScript1.0+/JScript1.0+/Nav2+/IE3+/Opera3+ 二.基本语法:window.open(pageURL,name,pa ...

  10. zookeeper集群环境搭建(纯zookeeper)

    1.首先在三台机子上放上zookeeper的解压包,解压. 然后的话zookeeper是依赖于jdk的,那么也应该安装jdk,这里不详细说明了. mv zookeeper-3.4.5 zookeepe ...