Broken Code (window31)

 

 

요즈음 EXE 암호화에 대한 사람들의 관심이 많아지고 인식이 높아지고 있는 가운데
Themida라는 프로젝터가 아주 최고의 인기를 달리고 있다.

Xprotector시절에는 드라이버 깔고 SDT정상화 하고 난리치는 와중에 정상 실행되는 횟수보다
리붓된 횟수가 더 많았다는 속설이 있을 만큼 불안정 했는데,

Themida 1.x대 버전으로 오면서 커널 드라이버를 제거했음에도 불구하고 더욱 강력해졌으며
안정성 면에서도 다른 기타 패커에게 꿀리지 않을 점수를 획득하며 프로텍터계의 입지를
굳혀가고 있다.

보통의 경우 프로텍터는 Anti-Debugging, Debugger-detect, Memory guard,
inject dummy code, Monitor block, Resource Encrypt 등 많은 기능을 제공하는데,

나에게 있어서 Themida는 API re-direct가 가장 사람을 환장하게 만드는 거 같다.

일반적으로 한두번만 슥슥 위치를 왔다리 갔다리 하는 스탠다드한 프로텍터와는 달리,
Themida는 수십번 이상의 리다이렉트를 시킨다.

또 걍 점프만 하는 리다이렉트가 아니고 중간중간 별 희안한 짓거리를 하기도 한다 ;

따라서 리버싱 할때하나의 API를 확인하려 해도 엔터를 수십번 연타해야 하는
심한 짜증을 유발시킨다.

대표적인 예를 들어 보겠다. 다음과 같은 코드가 있다.

// Start the child process.
if ( !CreateProcess( NULL, // No module name (use command line).
 szMyExeParam, // Command line.
 NULL,             // Process handle not inheritable.
 NULL,             // Thread handle not inheritable.
 FALSE,            // Set handle inheritance to FALSE.
 0,                // No creation flags.
 NULL,             // Use parent's environment block.
 NULL,             // Use parent's starting directory.
 &si,              // Pointer to STARTUPINFO structure.
 &pi )             // Pointer to PROCESS_INFORMATION structure.
 )
{
 MY_LOG("CreateProcess szNssExeParam fail");
}

걍 프로세스 생성하는 CreateProcess라는 별거 아닌 API를 사용한 코드다.
이걸 디버거로 붙혀보면,

머 뻔한 코드다. 리버싱 할때도 '응 여기서 새 프로세스 생성하는구나' 하고 넘어가면 될 문제다.

하지만 이걸 Themida로 프로텍팅 한 후에 리버싱 해보면,

API call 이 표시되지 않고, 0x02B20000번지로 콜 하는 것을 알 수 있다. 일단 리다이렉트 시킨다는
것 까진 알겠다. 그럼 리다이렉트 수준이 어느정도일까, 한번 따라가 보았다.

(아, 그런데 미리 말해두지만 여기서부터 스크롤의 압뷁이니 검지손가락에 힘 꽉 주고 열심히
내려줄 준비를 해 두는게 좋겠다)















자 지금까지 15번 정도 리다이렉트 했다... 언제까지 가야 하는 것일까..;;


















실수로 화면 캡쳐를 같은걸 두개했다ㅠ ㅠ 워낙 많으니 헷갈린 ;







아 드디어 나왔다 !!! CreateProcessInternal 로 뛰는게 보인다.... 헉헉..

걍 점프만 하는것도 아니고 더하고 빼고 XOR 하고 아주 난리를 친다.
이러니 올리가 해석을 못해준다.

그까짓 CreateProcess한번 하려고 이런 짓거리를 하다니...

역공학시에는 눈으로 걍 슥 훑고 지나가야 하는 API가 상세분석해야 할 API보다 훨씬 많은데,
Themida는 이렇게 엥간한 API를 다 베베꼬아 놓으니, 쌩까고 지나가야 할 곳까지 샅샅이 훑도록
시간을 빼앗는다. 즉, 해커 입장에선 상당히 괴로운 것이다.

그래서 Themida로 프로텍팅한 것을 리버싱 할 때는 평소보다 시간이 배로 걸리며
짜증유발, 스트레스 유발, 정신건강에 심한 타격을 입는다.

분석을 아예 못하게 만든다는 목표를 이루어낼 수 없으면 최소한 공격자를 괴롭혀 주자
라는 명제를 아주 충실이 이행한 부분이라 할 수 있겠다

어쨌든 이와 같은 리다이렉트 때문에 순수 디스어셈블링에도 상당한 시간이 걸리는데,

하지만 이와 같은 re-direct를 무력화 할 수 있는 분석 도구를 개발하는것도 불가능할 것 같진 않다.

점프문이나 콜문을 일일이 쫓아가면서 트레이스와 동시에 점프하는 타겟이 현재 속해 있는 dll인지
시스템 dll 인지 등에 대해 계산하면서 분석해주는 알고리즘을 자동화 시킨다면, Themida가 API를
re-direct시켜도 툴로 스캔하여 분석의 시간을 절약할 수 있을 것 같다.
(Olly에 플러그인 용도로 개발한다면 더욱 좋을 듯. 혹시 짱개넘들은 이미 만들엇을지도 모르겟네)

시간이 날때 한번 만들어봐야겠다.

그럼 마무리 하는 기분으로 Themida 프로텍팅인지 확인하는 두가지 팁에 대해 간략히 적어보겠다.

팁1), Themida는 최신 PEiD스캐너에도 시그너쳐가 없으므로 Nothing found라고 나온다.
하지만 이때 섹션 이름을 보면 Themida라고 적혀 있는 것을 참고로 Themida 프로텍팅임을
짐작할 수 있다.

팁2) 프로텍팅 후 섹션 이름을 제거하거나 다른 이름으로 바꾸는 꽁수를 부리는 경우도 있으므로
이때는, API call 의 번지를 확인하여 0x02XXXXXX 번지 대로 뛰는지 알아본다. 이 영역은
Themida가 프로텍팅 시에 자신의 더미 코드, 안티 디버깅 코드를 할당하는 곳이므로
(MEMORY_BASIC_INFORMATION의 type은 MEM_PRIVATE) 저 번지대로 놀아나는 곳은
Themida임을 짐작할 수 있다.


window31. 2007년 8월.