pin-in-CTF

十几个月前,在学习 fuzz 时,我接触了 intel-pin 这个动态插桩工具,当时发现对于一些 CTF reverse 题目,尤其是代码混淆比较严重的题目,可以编写 pintool 统计指令数等信息,多快好省的通过侧信道的方法逐位爆破出 flag,详见 pin-in-ctf: blog, pin-in-ctf: repo

但这种方法缺点也很多:

  • 动态插桩使得程序的 runtime overhead 成倍增长(~%100)
  • 对于比较复杂的程序,尤其是系统调用较多的程序,内核态指令数会占总指令数的很大一部分,影响用户判断
  • pintool 编写相对复杂
  • 只能对用户态的程序插桩,对内核态程序插桩需要较大的改动

intel-pt and perf

半年前在做毕设时,我接触了 intel-pt 这个硬件级别的 trace 工具,其同样具有记录程序指令的功能,并且由于直接在硬件层面实现,runtime overhead 可以缩小到惊人的 5%,同时通过用户态的系统分析工具 perf,用户也可以相当方便的调用 intel pt 的某些功能。而 perf 也就是本篇文章要介绍的主角。

前几个月的 oGeek 线上赛中,我有一道 pwn 一道 reverse 的出题任务,本来想打算用 intel-pt 的特性出一道逆向题,但因为时间紧张,构思尚不成熟,不想浪费想法,最终出了另外一道 NSIS script 的题目 King of KoF。在昨天的 ASIS Final 2019 的比赛中,遇到了一道题目 Cursed app,分析之后觉得使用 perf 解决十分合适,于是终于有了分享 perf-in-ctf 这个想法(并打理要长草的博客)的机会,接下来进入正文。

perf

perf 是 Linux 中分析性能的工具,具有很多强大的功能,详见 linux perf turtorial。本篇文章只对其统计指令数的用法进行介绍。

首先需要安装,以 ubuntu 18.04 为例,直接使用包管理安装:

sudo apt install linux-tools-common

查看功能简介:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
~ perf --version
perf version 5.0.21
~ tldr perf

  perf

  Framework for linux performance counter measurements.

  - Display basic performance counter stats for a command:
    perf stat gcc hello.c

  - Display system-wide real time performance counter profile:
    sudo perf top

  - Run a command and record its profile into "perf.data":
    sudo perf record command

  - Read "perf.data" (created by perf record) and display the profile:
    sudo perf report

这里只对 perf stat 功能进行介绍,参考 tldr 的例子,对 id 这个命令进行性能分析

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
~ sudo perf stat id
uid=0(root) gid=0(root) groups=0(root)

 Performance counter stats for 'id':

              1.71 msec task-clock                #    0.710 CPUs utilized          
                 1      context-switches          #    0.584 K/sec                  
                 0      cpu-migrations            #    0.000 K/sec                  
               122      page-faults               #    0.071 M/sec                  
         6,244,401      cycles                    #    3.647 GHz                    
         2,353,996      instructions              #    0.38  insn per cycle         
           459,910      branches                  #  268.614 M/sec                  
            18,201      branch-misses             #    3.96% of all branches        

       0.002412965 seconds time elapsed

       0.000000000 seconds user
       0.002342000 seconds sys


~ 

其中有指令数这个结果

1
2
3
...
         2,353,996      instructions              #    0.38  insn per cycle         
...

通过格式化输出简化显示

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
~ sudo perf stat -x : id
uid=0(root) gid=0(root) groups=0(root)
1.17:msec:task-clock:1167180:100.00:0.721:CPUs utilized
0::context-switches:1167180:100.00:0.000:K/sec
0::cpu-migrations:1167180:100.00:0.000:K/sec
121::page-faults:1167180:100.00:0.104:M/sec
4243048::cycles:1208711:100.00:3.635:GHz
2388158::instructions:1208711:100.00:0.56:insn per cycle
461917::branches:1208711:100.00:395.755:M/sec
18229::branch-misses:1208711:100.00:3.95:of all branches
~ 

只保留 instructions 这一条结果

1
2
~ sudo perf stat -x : -e instructions id 1>/dev/null
2359978::instructions:1819500:100.00::

只保留用户态的结果

1
2
~ sudo perf stat -x : -e instructions:u id 1>/dev/null
716210::instructions:u:1532634:100.00::

看到这,看过 pin-in-CTF 的朋友可能已经知道怎么做了,接下来通过 ASIS Final 2019 的 Cursed app 这个题目进行举例。

perf-in-CTF

binary here

64 位 linux 程序,通过读文件验证结果

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
Desktop check ./cursed_app.elf 
./cursed_app.elf: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l, BuildID[sha1]=7c0031d8c259457ca7f3bab1c5a5f40269167b5f, stripped
[*] '/home/m4x/Desktop/cursed_app.elf'
    Arch:     amd64-64-little
    RELRO:    No RELRO
    Stack:    No canary found
    NX:       NX enabled
    PIE:      PIE enabled
Desktop ./cursed_app.elf 
please locate license file, run ./app license_key
Desktop echo "ASIS{" > flag && ltrace ./cursed_app.elf ./flag
_setjmp(0x7ffc7e160590, 0x7ffc7e160758, 0x7ffc7e160770, 0x559e6789dbb0) = 0
fopen("./flag", "r")                                               = 0x559e68a2d260
fseek(0x559e68a2d260, 0, 2, 0)                                     = 0
ftell(0x559e68a2d260, 0x559e68a2d340, 0, 6)                        = 6
fseek(0x559e68a2d260, 0, 0, 0)                                     = 0
malloc(6)                                                          = 0x559e68a2e4a0
fread(0x559e68a2e4a0, 1, 6, 0x559e68a2d260)                        = 6
fclose(0x559e68a2d260)                                             = 0
puts("Bummer! You got the wrong flag!!"...Bummer! You got the wrong flag!!
)                        = 33
+++ exited (status 0) +++

根据题目描述

1
2
3
4
Description:
If we want to say 100, should we start at 1 and count until 100?

sha256(flag) = dd791346264fc02ddcd2466b9e8b2b2bba8057d61fbbc824d25c7957c127250d

已经可以猜到没必要逆清楚程序的整个逻辑。

使用 IDA 分析程序,发现程序的逻辑很简单

ida.png

读取文件内容后有多个判断,都通过才会执行到

1
2
3
.text:0000000000001F3B lea     rdi, s          ; "Congratz! You got the correct flag!!"
.text:0000000000001F42 call    _puts
.text:0000000000001F47 mov     [rsp+0F8h+var_F4]

简单调试了几个判断,发现是对文件内容的逐字节判断,因此必然每次输入的正确 flag 长度越长,程序执行的指令数就越多,可以利用这个特性用侧信道的方法得到 flag。

先使用 perf 验证可行性,已经知道 flag 格式为 ASIS{this_is_flag}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Desktop echo -n "0" > ./license && perf stat -x : -e instructions:u ./cursed_app.elf ./license 1>/dev/null 
167612::instructions:u:1000300:100.00::
Desktop echo -n "1" > ./license && perf stat -x : -e instructions:u ./cursed_app.elf ./license 1>/dev/null 
167614::instructions:u:1237218:100.00::
Desktop echo -n "2" > ./license && perf stat -x : -e instructions:u ./cursed_app.elf ./license 1>/dev/null 
167614::instructions:u:967846:100.00::
Desktop echo -n "A" > ./license && perf stat -x : -e instructions:u ./cursed_app.elf ./license 1>/dev/null 
167628::instructions:u:934691:100.00::
Desktop echo -n "A0" > ./license && perf stat -x : -e instructions:u ./cursed_app.elf ./license 1>/dev/null 
167631::instructions:u:1034616:100.00::
Desktop echo -n "A1" > ./license && perf stat -x : -e instructions:u ./cursed_app.elf ./license 1>/dev/null 
167629::instructions:u:1019846:100.00::
Desktop echo -n "A2" > ./license && perf stat -x : -e instructions:u ./cursed_app.elf ./license 1>/dev/null 
167630::instructions:u:504064:100.00::
Desktop echo -n "AS" > ./license && perf stat -x : -e instructions:u ./cursed_app.elf ./license 1>/dev/null 
167648::instructions:u:955516:100.00::
Desktop echo -n "AS0" > ./license && perf stat -x : -e instructions:u ./cursed_app.elf ./license 1>/dev/null 
167645::instructions:u:914409:100.00::
Desktop echo -n "AS1" > ./license && perf stat -x : -e instructions:u ./cursed_app.elf ./license 1>/dev/null 
167647::instructions:u:2748495:100.00::
Desktop echo -n "AS2" > ./license && perf stat -x : -e instructions:u ./cursed_app.elf ./license 1>/dev/null 
167646::instructions:u:677381:100.00::
Desktop echo -n "ASI" > ./license && perf stat -x : -e instructions:u ./cursed_app.elf ./license 1>/dev/null 
167664::instructions:u:564774:100.00::

可以看到,当我们猜到下一位正确的 flag 时,指令数会有较为明显的增长(这里只保留用户态的 instructions 提高稳定性)。

把上述过程封装为脚本,运行即可得到 flag

exploit here

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
#!/usr/bin/env python
# -*- coding: utf-8 -*-

# ASIS{y0u_c4N_s33_7h15_15_34513R_7h4n_Y0u_7h1nk_r16h7?__!!!}
from subprocess import *
import string
import sys

command = "perf stat -x : -e instructions:u ./cursed_app.elf ./license 1>/dev/null"

flag = 'ASIS{'

def write_file(cont):
    with open("./license", "wb") as f:
        f.write(cont)

write_file(flag)
'''
Desktop cat license
ASIS{
Desktop perf stat -x : -e instructions:u ./cursed_app.elf ./license 1>/dev/null
167689::instructions:u:377798:100.00::
'''
ins_count = 167689
while True:
    delta = 0
	count_chr = ''
	for i in string.printable:
        write_file(flag + i)
		target = Popen(command, stdout=PIPE, stdin=PIPE, stderr=STDOUT, shell=True)
		target_output = target.communicate()
        #  import pdb;pdb.set_trace()
        #  print(target_output)
		instructions = int(target_output[0].split(':')[0])
		if ins_count + 20 > instructions > ins_count + 10:
			count_chr = i
            delta = instructions - ins_count
			ins_count = instructions
            break
	flag += count_chr
        print(delta, flag)

整个过程耗时不到 1 分钟,远远快于使用 pintool 的方法。

这里使用了统计用户态总指令数这种相对粗糙的方法,有兴趣的同学还可以试试精确的只统计某种 pt packet(tnt, tip 等)数目来达到更为精准的结果。

summary

pin-in-CTF is dead, I prefer perf.

使用 perf 来解决这类问题有以下优点:

  • 基于硬件,runtime overhead < 5%
  • 可以通过只保留用户态指令或者只保留某种特定的 pt 数据包来达到更精确的效果
  • 工具较为成熟,直接使用即可
  • intel pt 本身就是内核模块,可以用于内核态

前文简单的展示了如何使用 perf 这个工具解决一部分 CTF reverse challenge,但也仅仅展现了 perf/intel pt 这个强大工具的冰山一角,更多的高级用法和 trick 还需要大家一起学习和脑洞。

reference