Themida 2.3.1 Unpacking #0

오래간만에 포스팅한다. 언젠가 Themida를 뜯어야겠다는 생각을 했다. 요즘 게임이든 서비스 어플리케이션이든 악성코드든 분석당하기 원하지 않기 때문에 프로텍터들을 많이 씌운다. 그 중에서 유명한 프로텍터는 ASProctect, VMProtect, Themida가 있다. 이 중에서 극악의 언패킹 난이도를 지니는 프로텍터는 VMProtect와 Themida이다. (절대로 ASProtect가 언패킹이 쉽다는 이야기는 아니다. Advanced Import Protect는 코드 가상화 방식과 유사하게 핸들러를 이용한 API 난독화를 한다.) 

대상은 Themida 2.3.0 Unpackme 이며 다음 세 단계의 작업을 통해 언패킹 시도를 할 것이다.

1.각종 안티디버깅 걷어내기 (STI 명령을 이용한 예외처리 등)

2.OEP 찾기

3.난독화 된 API 복구

특히 1번 단계의 경우 아래 사진과 같이 코드 중간중간에 STI 명령들이 난무하다. 

예외처리를 통한 안티디버깅 방식은 유명한데 STI 명령은 ring0 레벨의 명령으로 ring3 레벨에서 실행하면 예외가 발생한다.(인터럽트) 이 때 아래 사진처럼 미리 깔아둔 SEH를 통해 예외처리하는 방식으로 프로그램의 흐름을 이어가는데 이 핸들러에는 디버깅 탐지 루틴이 포함되어 있거나 아무일도 하지 않고 흐름을 계속 진행하는 루틴이 있다. 뭐가 되었든 프로그램에서 미리 설치한 SEH에서가 아닌, 디버거가 예외를 처리하게 되면 정상적인 흐름으로 진행되지 않을 것이다. STI 명령을 듣도보도 못했더라도 그냥 예외처리를 통한 안티디버깅 방식 중 하나일 뿐이다. 

대부분 Themida를 씌워서 배포되는 어플리케이션이나 게임들에서 사용하는 버전에서는 STI 명령을 수도없이 넣어서 안티디버깅 장치를 찾기 어렵게한다.

어쨋든 이를 걷어내는 방법은 모든 예외를 디버거가 아닌 프로그램에 넘기는 것이다. 단, SEH에 또 다른 안티디버깅 장치가 있다면 역시 걷어낸다. 계속 진행하면 몇 차례의 Access Violation 예외가 발생한 뒤 디버거가 죽는다. 혹시나 해서 STI 명령 예외처리 핸들러가 중간에 다른걸로 바뀌지 않나 확인해봤으나 중간에 sti 명령이 다른 명령으로 변조되었는지 체크하는 핸들러 외에는 특별한 건 없었다.

상당히 골치아프다. 우선은 Access Violation 부분을 확인하고  안티디버깅 우회에 성공하면 다음 편을 연재하겠다.