onsoim의 연구 일지

readme.txt

readme.txt 파일을 읽어보면, file 을 복호화하는 것이 목표이며 그 암호화된 파일은 EXE 인 것 같습니다.

unpack UPX

암호화하는 프로그램으로 추정되는 run.exe 의 정보를 확인해 보면, upx 로 압축되어 있습니다.

따라서 이를 먼저 풀어줍니다.

anti Hexray

run.exe 프로그램을 보면 중간중간 분석을 방해하기 위해서 특정한 목적없이 무의미한 명령어를 반복하는 부분이 있는데, 이로 인하여 디컴파일 도구에서 제대로 분석하지 못하도록 방해하고 있습니다. 따라서 이것들을 먼저 제거해 줍니다.

바이트 코드를 확인해 보면 60 61 90 50 58 53 5B 가 반복이 되는데, 이를 010 editor 같은 도구를 이용하여 90 * 7 으로 치환합니다.

이제 90으로 채워져서 NOP 으로 채워져 있지만, 디컴파일에 시간을 잡아먹기 때문에 이 NOP 공간을 점프하는 명령어를 넣습니다.

JMP 할 공간의 offset 은 0x125C7 로 동일하며, 명령어에 사용되는 5바이트를 빼주고 90 의 끝에서 다음 주소를 가리켜야 하기 때문에 1을 더해줍니다.

따라서 E9 C3 25 01 00 을 90 공간의 맨 앞부분에 넣어줍니다.

그러면 위와 같이 중간에 NOP 코드를 생략하는 것을 확인할 수 있습니다. 근데 위의 코드도 자세히 보면 레지스터 값을 넣고, 그대로 빼는 의미없는 함수입니다.

실제로 이 함수를 여러번 호출하는데, 이를 통해 디컴파일을 방해하려는 목적인 것 같습니다.

복호화 루틴

sub_41355e0 함수를 보면, 이 함수에서 복호화가 진행되는 것을 알 수 있습니다.

복호화에 사용할 키를 0x44d370 에 입력받습니다.

입력으로 들어온 Key 의 길이를 구합니다.

그 후 file 이라는 파일을 열고,

파일의 크기를 구하고, 파일 포인터를 처음으로 돌려 놓습니다.

그 후 파일의 내용을 받아서, dword [ebp - 0x8] + 0x5415b8 영역에 올립니다.

그 후 key 와 파일의 내용을 1바이트 씩 가져와서 xor 연산을 수행한 후, 그 값에 0xff 를 xor 즉 ~ 연산을 수행합니다.

그 후 그 내용을 file 에 다시 씁니다.

복호화 하기

파일의 마지막 부분을 보면, 평소 0으로 채워져 있어야 할 영역을 확인할 수 있습니다.

특정 문자열이 13개씩 반복되는 것으로 보아, 키는 13자리인 것을 추측할 수 있습니다.

또한 exe 라면 dos stub 에 위치한 This program cannot be run in DOS mode 를 이용하여 키를 구해보겠습니다.

위에서 찾은 키를 이용하여, 암호화된 파일을 복호화하겠습니다.

복호화 key 는 letsplaychess 이며, 그 키를 이용하여 file 을 복호화하였습니다.

복호화가 된 파일을 확인해 보면, upx 로 압축된 pe32 파일임을 알 수 있습니다.

Flag

복호화한 EXE 에서 플래그를 찾아보겠습니다.

먼저 UPX로 압축이 되어 있기 때문에, 이를 먼저 풀어줍니다.

그 후 출력하는 부분을 확인해 보면, Key -> Colle System 라는 문자열을 출력합니다.

이 부분외에는 출력하는 부분이 없는 것으로 보아, Colle System 이 플래그인 것 같습니다.

인증

_start 함수

_start 함수를 보면 main 함수를 호출한다.

main 함수

main 함수를 보면 eax 값이 1이 아니면 Wrong 이라는 문자열로 보아 sub_804851 의 return 값이 1이 되어야 한다.

sub_8048451 함수

함수의 return 값이 1이 되어야 하는데, 위에서 return 을 할 수 있는 루틴은 맨 왼쪽으로 진행되는 루틴 이외에는 존재하지 않는다. 따라서 해당 루틴으로 갈 수 있는 조건들을 확인해 본다.

data_804a021 == 0x31
data_804a024 == 0x7c
data_804a025 == 0x00
data_804a022 == 0x7c
data_804a020 == 0x78
data_804a023 == 0xdd

위에서 부터 위의 조건들을 모두 성립해야 return 1을 한다.

data_804a020 == 0x78
data_804a021 == 0x31
data_804a022 == 0x7c
data_804a023 == 0xdd
data_804a024 == 0x7c
data_804a025 == 0x00

이를 순서대로 정리해 보면 아래와 같이 된다.

하지만 중간에 위치한 xor 도 있기 때문에 이를 적용해 본다.

data_804a020 ^= 0x34
data_804a020 == 0x78
data_804a021 == 0x31
data_804a022 ^= 0x32
data_804a022 == 0x7c
data_804a023 ^= -0x78
data_804a023 == 0xdd
data_804a024 == 0x7c
data_804a025 == 0x00

이를 최종적으로 정리해 보면 아래와 같은 조건들을 만족해야 한다.

data_804a020 == 0x78 ^ 0x34        // L
data_804a021 == 0x31                    // 1
data_804a022 == 0x7c ^ 0x32        // N
data_804a023 == 0xdd ^ -0x78        // U
data_804a024 == 0x7c                    // X
data_804a025 == 0x00                    // End of String

그러면 data_804a020 부터 있는 문자열은 어디서 오는지 확인을 해본다.

data_804a020 데이터

아까 main 함수에서 sub_8048451 함수를 호출하기 전에 sub_8048434 함수를 호출한다.

이를 확인해 보면, scanf 함수를 호출하는데 입력받은 값을 data_804a020 에 넣는다.

따라서 data_804a020 는 사용자가 입력한 값이며, 이 값이 위의 조건문을 성립할 경우에만 Correct! 라는 문자열을 확인할 수 있다.

정답

0x0 Packer

0x01 Compression

• PE 파일의 용량을 줄이기 위한 용도로 활용

0x02 Protector

• 리버싱을 방해하기 위하여 사용
• ex) 카카오톡, 악성코드 등

0x1 Manual Unpacking

0x2 PEiD

플러그인 분석

0x3 Reference

1. grazfather: manual-unpacking
2. OEP 찾기
3. UPX 언패킹
4. virtualprotect

루틴 분석

sub_401000

시리얼 생성

이름 복구

문자열 확인

루틴 분석

Reference