Themida 가 사용하는 API Redirect

 Code 를 잔혹하게 난독화하는 것으로 유명한 Themida 라는 Protector 에서 주로 사용하는 기법은 Virtualization , API Redirect, 그리고 기타 Code Obfuscation 기법이 있겠다. 그 중에서 API Redirect 기법에 대해서 적어보겠다. 사실 API Redirect 기법은 오래 전부터 사용한 기법이다.

 예를 들어 CreateFile 함수를 호출하는 프로그램을 Protect 로 Packing 했다고 하자. PeSpin 경우에는 Call CreateFile 대신에 Call 2021453 와 같이 괴상한 주소로 Call 로 바꾼다. 그리고 2021453 으로 점프하면 mov edi,edi push ebp mov ebp,esp 명령이 있고 또 다시 JMP 문이 있고, 몇 번 점프를 하다보면 Call 7xxxxxx 와 같이 뜬금없는 Call 을 하고 실제 CreateFile 함수가 수행된다. CreateFile 은 Kernel32.dll 에 있는데 PeSpin 은 IAT 를 조사해서 Protect 대상 프로그램이 호출하는 API 를 전부 조사한다. 그 다음 각각의 API 를 사용하는 Dll 을 뒤져서 해당 API 의 주소를 알아낸다. 보통 단순한 Packer 들은 자신의 영역에 해당 API 주소를 복사한 다음에 API 호출 부분을 JMP 또는 Call 등을 이용해서 주소가 저장된 영역을 걸쳐서 호출하게 한다. 여기까지는 전형적인 API Redirect 의 사전 작업이다.

 하지만 PeSpin 은 API 주소에서 약 3~5줄 정도의 라인을 카피해서 자신의 테이블에 옮긴다음에 복사한 다음 명령으로 Call 을 시도한다. 그렇게 되면 API 함수 호출 주소로 점프하는 명령 부분만 찾는 방법은 통하지 않는다. 이 처럼 몇 바이트를 미리 쌔벼와서 자신의 테이블로 가져오는 것을 Stolen Byte 기법이라고 한다. 이를 응용해서 OEP 부분에 있는 push ebp mov ebp,esp 와 같은 함수 프롤로그 부분을 포함한 일부 바이트를 특정 영역에 꼼쳐넣고 점프시키는 방법으로 OEP 숨기는 기법이 있다.

 Themida 의 경우 테이블을 수십 개 만들어서 수십 번의 점프를 해야 원래 API 를 호출하는 부분이 나타난다. 버전이 비교적 높은 Themida 의 경우 더 악랄한데 원래 코드가 10줄 짜리 API 가 있다고 하자. 보통의 경우에는 3줄 정도를 꼼치고 나머지 7바이트 부분으로 점프시키는 경우가 고작인데, Themida 는 아예 10줄을 통째로 가져다가 쓴다. 그리고 코드 10줄을 한 파트로 모아두는 것이 아니라 여러 개의 파트로 나누어서 점프시킨다. 예를 들어 10줄 짜리를 5개의 파트로 나눈다면 각 파트에 원래 코드 2줄에 각종 쓰레기 코드 등을 섞어서 난독화 시켜서 Redirect 시킨다.

 결국 점프문을 타면 원래의 API 를 찾을 수 있기 때문에 분석을 아예 불가능하게 하지는 못한다. 하지만 불가능이 아니더라도 분석자의 정신을 피폐하기에는 충분하다. API 가 한 두개 정도면 노가다를 해서 찾을 수 있겠지만 수십 개의 API 만 해도 점프 횟수는 기하급수적으로 증가한다. 단순 F7 이나 F8 로 점프하면서 API 호출을 찾는 것은 매우 잔인한 작업이라 할 수 있겠다.

 이를 자동화 하는 방법을 생각할 수 있는데, 테이블 생성 시에 특정 패턴을 잡거나 실제 API 로 Call 할 때 사용하는 주소 (보통 0x7xxxxxxx) 만 필터링 해서 실질적인 주소를 찾는 방법 등이 있겠다. 그리고 구버전의 Themida 는 Call 0x02xxxxxx 으로 Redirect 한다고 한다. 이 영역은 각종 점프문과 난독화 된 코드로 도배되어 있다. 이와 같은 영역을 수십 개 통과해야 원래 API 로 점프한다. API 하나 호출하는데 사용되는 명령은 수 만개가 된다.

 하단 자료는 API 난독화와 관련된 문서이다. 꽤 오래된 자료이지만 점점 잔학해지는 난독화 기법 연구를 위해서는 필수적으로 연구할 내용이다. 다음은 '코드 가상화 기법이 적용된 악성코드 분석' 논문에서 API 추출 방법에서 발췌한 내용이다. 결국 가상화든 API Redirect 이든 간에 원본의 API 주소를 호출한다는 내용이다.

 "GetModuleHandleA, GetCommandLineA를 호출하는 코드는 가상화가 되었음에도 불구하고 정상적으로 호출되었음을 확인할 수 있다. 즉, 코 드 가상화가 적용이 되어있어도 시스템 dll에 있는 API호출하는 것은 동 일하다는 것을 확인 할 수 있다."

Analysis and Visualization of Common Packers.pdf

API-Deobfuscator-Resolving-Obfuscated-API-Functions-In-Modern-Packers.pdf