[Reversing.kr] Easy Unpack

3번째 문제 Easy Unpack 입니다.

문제의 제목을 보아 언팩 시키는 문제임을 알 수 있지만

아직 어떠한 답을 찾아내는지 모르기 때문에

문제의 압축 파일을 풀어 ReadMe.txt 텍스트 파일을 열어봅시다.

ReadMe.txt 텍스트 파일을 읽어보면

Find the OEP, 프로그램 본래의 EntryPoint를 찾아내는 문제입니다.

패킹된 프로그램의 경우 IDA로 분석하는 것에는 한계가 있으므로

디버거로 분석해보도록 하죠.

디버거로 EP에 도착하게 되면 이상한 점 하나를 느끼실 수 있습니다.

이상하게 정상적인 프로그램과는 다르게

.text 섹션이 아닌 .GWan 섹션에 있는 인스트럭션이 나타나네요.

.text 섹션에 있는 인스트럭션을 살펴보지만

알 수 없는 인스트럭션 또는 이상한 흐름의 루틴이 존재하고 있습니다.

어떻게 된 일일까요?

'현재 이 프로그램은 패킹되었다'라는 사실을 바탕으로 시나리오를 그려본다면

.text 섹션에 있는 인스트럭션들은 패킹된 상태이고

.GWan 섹션에 있는 언패킹 루틴이 .text 섹션에 있는 패킹된 데이터를 언패킹하고

기존 프로그램에서 사용할 IAT를 세팅하며

필요한 작업을 다 마친 후 OEP로 실행 흐름을 옮길 것이라는 시나리오를 그릴 수 있습니다.

문제의 패커의 난이도가 쉬운 편이기에 세세하게 설명해드리도록 하겠습니다.

EP 근처의 인스트럭션을 살펴본다면

0x00409000부터 0x004094EE까지 루프를 돌면서

0x10, 0x20, 0x30, 0x40, 0x50으로 차례대로 XOR 언패킹 해주고 있는 루틴을 볼 수 있습니다.

0x00409000 주소는 .Gogi 섹션의 주소이며 .Gogi 섹션의 언패킹 루틴이 끝난 후

.Gogi 섹션의 메모리에는 Dll 파일 이름, 해당 Dll에서 가져올 API 이름이 있는 것을 보아

기존 프로그램에서 쓸 IAT를 세팅하기 위해 필요한 문자열로 보입니다.

기존 IAT가 있는 .rdata 섹션에는 Write할 권한이 없기에

VirtualProtect() API를 사용하여 .rdata 섹션의 메모리 보호 속성을 PAGE_READWRITE으로 변경해주고

.Gogi 섹션의 메모리 주소를 1씩 증가시키며 해당 메모리에 있는 데이터와 0xABCDEF를 비교해줍니다.

0xABCDEF와 비교하는 이유는

IAT 세팅에 필요한 문자열의 주소를 찾거나 올바른 데이터인지 검증하기 위함이겠죠?

만약 시그니처 0xACDF와 비교하여 해당할 경우 Dll 이름 문자열이기에

LoadLibraryA() API를 사용하여 라이브러리를 로드해주고

해당 라이브러리에서 필요한 API를

GetProcAddressForCaller() API를 사용하여 API 주소를 획득한 후 IAT를 세팅해줍니다.

아직 언패킹이 되지 않은 섹션 .text, .data은 이전에 했던 언패킹 방법과 같이

VirtualProtect() API를 사용하여 메모리 보호 속성을 PAGE_READWRITE으로 변경해주고

차례대로 XOR 0x10, 0x20, 0x30, 0x40, 0x50 하여 언패킹을 해줍니다.

언패킹을 마친 후 아래 인스트럭션 JMP 0x00401150 으로

실행 흐름을 변경해주는데 점프하는 주소가 OEP 인지 확인해보면 진짜 OEP 임을 알 수 있습니다.

Easy Unpack의 정답은 00401150 입니다.