API Redirect 기법이 적용된 Protector 에 대한 교과서적 접근 방법

 OEP 찾는 것도 찾는 것이지만 기껏 OEP 찾았더니 주요 API 개미 새끼 한 마리 안 나오는 경우가 있다. 거의 API Redirect 가 적용된 case 이다. 악성코드 분석이나 패치 작업 시에 자주 쓰는 API 를 호출하는 부분을 위주로 분석하면 (예를 들어 시리얼 처리 루틴을 분석하고 싶으면 GetDlgItemText 함수를 호출하는 부분 위주로 분석) 상당히 작업을 단축할 수 있다. 하지만 API 를 모르면 분석 작업이 굉장히 고달파진다. 이처럼 API 를 숨겨주는 기능을 API Redirect 기법이라고 한다. 정확히는 결국 API 호출하는 것은 맞지만 대놓고 해당 API 주소가 있는 IAT 가 아닌 Protector 가 독단적으로  구성한 테이블을 참고해서 호출하도록, 말 그대로 Redirect 하는 방식이다. 

 원 상태의 IAT 를 복구하기 위해서는 자동화 툴을 사용한다. 하지만 자동화 툴이 만사는 아니다. 가끔은 API Redirect 루틴을 찾아서 패치해야 할 때가 있다. 예를 들어 GetCommandLineA 함수를 Redirect 시킬려면 GetCommandLineA 함수의 원래 주소를 알아야 할 것이다. OllyDbg 기준으로 Ctrl+G 에서 GetCommandLine 를 치면 Entry 로 들어가는데, Stolen Byte 기법을 사용하는 Protector 들은 십중팔구 해당 주소의 내용에 Access 한다. HW BP 를 이용해 Access 조건으로 BP 를 걸면 Redirect 부분을 Tracing 할 수 있다. 해당 부분을 패치해서 IAT 를 원상태로 만든다.

 특히 Stolen Byte 와 API Redirect 기법을 동시에 사용하는 Protector 분석에 유용하고, Unpacking Tutorial 에서 기본적으로 알려주는 방법이기도 하다. 특히 옛날 버전의 A*Pro***t 와 PE Sp*n 등 구닥다리 Protector 분석 시에 요긴하게 써먹는다.

 핵심적인 내용은 Virtualization 을 하든 무슨 종류의 Polymorphism 을 적용시키든 간에 원래의 API 코드는 호출된다는 점이다. 각종 Deobfuscation 연구에서 Backtracing 을 많이 활용하는 이유다.