티스토리 뷰
카테고리
matrix
문제
32 bit elf 바이너리가 주어진다.
이 바이너리는 code.txt를 해석하여 인스트럭션들을 실행한다.
인스트럭션을 호출하는 부분은 위 그림 중 22번 째 줄 부분이다.
여기서 instruction_table 배열에는 mov, add, sub, xor, cmp, jmp, je, jne, jl, jg, call, ret, push, pop, syscall 이 순서대로 있고, 각각의 함수들은 바이너리 내부에 구현되어 있다.
예를 들어서 coce.txt의 첫 번째 바이트가 0x0c 라면, 열 두 번째 함수인 push가 실행된다.
다음 실행할 인스트럭션은 세 번째 바이트의 값 + 3 만큼 건너뛴 위치가 된다.
만약 방금 실행한 인스트럭션이 pc 값을 변경할 만한 함수(jmp, ret 등) 이었다면 다음 실행할 인스트럭션을 구하는 과정은 생략하고, 변경된 위치의 인스트럭션을 수행한다.
matrix 카테고리에는 세 문제가 있었는데 xorxor는 그 중 두 번째 문제이다.
세 문제 모두 이런 식의 구조를 갖고 있었는데 xbox를 떠올리게 한다.
xorxor 문제에서는 code.txt 파일이 주어져 있다.
첫 번째 바이트가 0x0C이기 때문에 그에 해당하는 push 함수가 불리고, 세 번째 바이트가 0x01이기 때문에 여기에 3을 더한 위치인 0x04 위치가 다음 실행할 인스트럭션 위치가 된다.
여기서는 첫 번째 바이트가 0x00이기 때문에 그에 해당하는 mov 함수가 불리고, 세 번째 바이트가 0x02 이기 때문에 총 5 바이트 떨어진 위치인 0x09위치가 다음 실행할 인스트럭션 위치가 된다.
이런 식으로 code.txt를 해석하여 실행시켜주는데, code.txt의 동작을 해석하여 알맞은 key를 입력하는 것이 문제이다.
문제의 의도된 풀이는 디스어셈블러를 제작하는 것이었지만 직접 분석하는게 더 빠를 것 같아서 GDB를 사용했다.
문제가 xor라는 것을 알기 때문에 xor 함수 중 xor 연산이 일어난 곳에 break point를 설정하고, 연산 되는 값을 확인했다.
첫 번째로 확인한 xor 함수에서, edx 레지스터에는 사용자의 입력 값, eax에는 0x74f403d5 가 들어있었다.
xor 함수는 총 여덟 번 불리며, 사용자의 입력 값과 연산 되는 값들은 다음과 같았다.
0x74f403d5, 0xaeab8936, 0x0da991c4, 0x8f8cd017, 0x7f2d3e0b, 0xb1663b96, 0x99ff0820, 0xacf158f3
xor 연산을 수행했으니 결과값을 비교해야 할 것이다. cmp 함수에도 break point를 설정했다.
위에서 xor 연산 된 결과를 어떤 값과 비교하고 있는 것을 확인 할 수 있었다.
cmp는 여러 번 불리지만 그 중에서 xor 연산의 결과값을 비교하는 부분들을 찾을 수 있었고, 비교되는 값들은 다음과 같았다.
0x5f776f6e, 0x615f6577, 0x625f6572, 0x6d6f6365, 0x5f676e69, 0x666f7270, 0x69737365, 0x6c616e6f
(now_we_are_becoming_professional 이라는 문자열이다)
이렇게 찾아낸 각각의 숫자들을 xor 연산해주면 원래 입력해야 할 key 값을 알아낼 수 있다.
0x2b836cbb, 0xcff4ec41, 0x6ff6f4b6, 0xe2e3b372, 0x204a5062, 0xd70949e6, 0xf08c7b45, 0xc090369c
알아낸 값들을 서버에 접속하여 입력하면 플래그를 얻을 수 있다.
Exploit
'해킹 > CTF' 카테고리의 다른 글
[2016 POX CTF final] keygen (100) write-up (0) | 2016.11.12 |
---|---|
[2016 POX CTF final] watch out (150) write-up (0) | 2016.11.12 |
[2016 layer7 CTF] UP AND UP !! write-up (0) | 2016.11.04 |
asdf (0) | 2016.09.14 |
[WhiteHat Contest 12] Pwn001 write-up (2) | 2016.09.11 |