'2013/01'에 해당되는 글 1건

  1. 2013.01.03 By-passing the parts of themida's anti-reversing (1)

2013.01.03 14:24 System

[+] Introduction 


 

새해 첫 포스팅입니다.

 

<Fig0. 2013년 어서와>

 

이 글 읽는 여러분 모두 죽음에 한발짝 더 다가오신걸 환영합니다 ^0 ^

 

아무튼 오늘의 주제는 널리 쓰이는 상용 Protector Themida 의 Anti reversing 중 몇 가지를 분석해보고자 합니다.

 

Themida는 API redirection에 Debugger Detection , Resource Encryption , Memory guard 등

 

온갖 기법을 사용합니다.

 

그 중에서도 이번에 타겟은 Debugger Detection 과 Monitor Blocker 입니다.

 

 

[+] Running shot


 

실제로 위 기법들이 동작했을 때의 모습을 살펴보죠.

 

<Fig1. Debugger Detection>

 

<Fig2. Monitor Blocker>

 

 

컴퓨터에 관심이 많으시고 게임을 꽤 즐기시는 분들은 몇번 씩 봤을 법한 Mesasge Box입니다.

 

"A monitor program has been found running in your system. Please, unload it from memory and restart your program."

 

위 Mesage를 보는건 아래와 같은 상황이겠죠.

 

1. Protection이 걸린 Program을 실행 시키고 Debugger를 실행했을 때 [ 혹은 그 반대 ]

 

2. Protection이 걸린 Program을 실행 시키고 Monitoring Program 을 실행했을 때 [ 혹은 그 반대 ]

2-1. Monitoring Program을 한번 이상 실행 시키고 종료 한 다음, Protection 이 걸린 Program 을 실행 했을 때

 

실행 중에도 잡아내는 것을 보면 Program 실행시에 한번 Check 하는 것이 아니라,

 

별도의 Thread가 주기적으로 확인한다는 것을 알 수 있습니다.

 

다만, 의문이 생기는건 2-1 번이죠. 왜 Monitoring Program을 종료시켰는데도 이런 Message가 뜨는가?

 

잠깐(?) , 머리 좀 식히려 게임을 켰을 때 반겨주는게 짱세고 귀여운 캐릭터가 아니라

 

흰색 바탕에 검정 글씨가 점철된 저런 기계적인 그래픽 덩어리라니!

 

우리에게 공부만 하라는 컴퓨터의 아름다운 배려에 현기증만 납니다.

 

<Fig2-1. 아 현기증 난단 말이에요>

 

저렇게 되면 재부팅을 하는 수밖에 없거든요.

 

Monitoring Program은 진작 껐는데 그걸 또 어떻게 알았는지 ...

 

이 현기증의 근원지는 뒤에서 설명하도록 하겠습니다.

 

 

 

 

[+] How to run


 

실제로 내부적으로 사용한 방법을 살펴보면 복잡하지 않습니다.

 

 

<Fig0-1. 진짜로 안복잡함 ㅋ>

 

다만 이 기법들 모두 실행 프로그램 내부에 포함되기 때문에 기법 자체도

 

Themida의 가호 아래 있게 되고, 이 때문에 파악하는데 애로사항이 꽃피게 됩니다.

 

1. API Name 및 인자 확인

 

우리가 Themida의 투명 망토를 걷고 확인해야 할 것은 API Name 및 인자입니다.

 

문제는 이 투명 망토 성능이 꽤 괜찮다는 건데요.

 

Themida 가 직접 호출하는 API는 기본 Hooking 방법으로는 알기 쉽지 않습니다.

 

API 초반부를 타지 않고 중반부터 타는 형식을 사용하거든요.

 

그 덕에 함수 초반에 거는 Hooking 방법은 무용지물이 됩니다.

 

[ 물론 특정 Hooking 하는 Service를 이용하기 위해 이 기법을 사용하지 않는 것도 Themida의 옵션에 존재합니다. ]

 

하지만 이 방법도 하위 함수가 존재하는 API 에서는 별 소용이 없습니다.

 

예를 들어 Printf 를 호출하면 내부에서 Writefile [ Windows의 경우 ] 를 다시 부르게 되는데

 

Writefile에 Hooking 을 걸고 Tracing 하면 얼추 어떤 함수를 호출했는지, 어떤 의도를 가지는지 확인 할 수 있다는 겁니다.

 

따라서 Themida 내부에서 사용하는 함수를 확인하기 위해서는 비교적 아래단의 함수를 Monitoring 하는 것이 좋습니다.

 

이를 통해 NTQuerySystemInformationRtlMultiByteToUnicodeN 을 주기적으로 호출함을 확인 할 수 있었습니다.

 

 

2. String 확인

 

많은 힌트가 되는 String 입니다.

 

Themida에서 사용하는 String 은 2가지 종류가 있을겁니다.

 

1. API 의 인자로 주는 String

2. 내부적으로 사용하는 Data String

 

전자의 예는 Fig1이나 2에서 보았던  A  ~ has been found 이런 Message 들입니다.

 

이 녀석들은 MessageBox 를 호출 할 때 인자를 평문으로 주어야 합니다. 

 

[ 물론 Program 내부에는 암호화 되어 들어가 있기 때문에 Program의 Hex 값을 검색해서는 나오지 않습니다. ]

 

그 때문에 이런 녀석들은 동작 중에 Memory Dump를 떠서 확인하면

 

그대로 찍히게 됩니다. 이 방법은 Program의 사용자가 지정한 문자열 역시 마찬가지겠죠.

 

 

<Fig3. Memory Dump를 뜨고 문자열을 확인한 모습>

 

후자는 약간 까다롭습니다.

 

예를 들어 문자열 비교를 할 때, 한 글자씩 비교 하는 함수를 임의로 만들어서 사용하거나

 

Hash 값 등을 사용하여 비교 한다고 하면 내부적으로 사용하는 문자열을 알기 귀찮아지죠.

 

다행인건 , Themida가 Hash 값 까진 쓰지 않았다는 겁니다.

 

친절하게도 Themida에서는 String을 Multi byte -> Unicode로 Converting 하는데 API 를 사용하고 있더군요.

 

하위 함수인 RtlMultiByteToUnicodeN 를 Monitoring 해서 사용하는 문자열을 긁어내면 다음과 같습니다.

 

<Fig4. Themida가 내부적으로 사용하는 String들>

 

String은 위대했습니다.

 

어떤 함수를 이용할건지도 대충 감이 오네요.

 

Thread를 돌면서 FindWindow 로 저들을 확인하고 있었던 거겠죠.

 

또 NtQuerySystemInformation 에서 얻어온 String 과 비교를 한 것이구요.

 

실제로 Loading 되는 Module Name을 확인해봅시다.

 

 

<Fig5. System에 Load 된 Driver>

 

Monitoring Program중 하나인 Process Monitor 에서 Load 시킨 PROCMON23.sys가 Unload 되지 않고 남아 있습니다.

 

이게 바로 Monitoring Program을 종료 시켜도 Themida에서 계속 잡는 이유죠.

 

 

 

[+] Bypassing!


 

Findwindows를 이용한 방법은 말 그대로 내부 class 이름을 죄다 바꿔주면 됩니다.

 

Debugger 쪽은 손쉽게 우회가 가능하죠.

 

그렇다면 Monitor blocker는 어떻게 우회할까요?

 

[ Themida 적용 Program 실행시에도 Monitoring Program을 실행하고자 한다면 Class 이름 바꾸는것은 물론 선행되어야 합니다. ]

 

저 Driver를 Unload 시켜야 하겠죠?

 

Process Monitor에서는 왜 Unload시키지 않을 까요?

 

Sysinternals의 admin group 중 한명이 이렇게 대답했다고 하는군요.

 

<Fig6. Driver를 Unload시키지 않는 이유>

 

<Fig7. Driver를 Unload 시키지 않는 이유>

 

뭐 둘다 같은 이야기를 하고 있는거 같네요.

 

이걸 Unload 시켜야 재부팅 하는 수고를 덜 수 있을 텐데 말이죠.

 

Anti Rootkit Program을 써서 이걸 강제로 삭제 시켜버리는 방법도 시도해봤습니다만 삭제가 안됩니다.

 

위에서 언급한 것처럼 강제로 하려고 했다간 BSOD 를 볼 것 같고 해서 강제로 Unload 시키는 방법 외에 다른 방법을 찾아봐야겠군요.

 

그럼 어떤 방법이 있을 까요?

 

Themida에서는 Driver의 문자열 정보만 확인 하는 걸로 보입니다.

 

그렇다면 다른 이름으로 저 Driver를 올리면 되죠.

 

Process Monitor 내에서 참조하는 모든 Driver Name을 임의의 문자열로 바꾸면 됩니다.

 

이렇게 하면 Monitor Driver를 강제로 Unload 하지 않고도 실행 할 수 있습니다.

 

 

[+] Conclusion


 

야호 재부팅 안해도 된다!

 

그냥 재부팅 하신다구여?

 

죄송해여..

 

근데 솔직히 이게 더 귀찮은듯

 

 

 

 

 

 

 

Posted by LinkC
이전버튼 1 이전버튼

블로그 이미지
LinkC

태그목록

Tistory Cumulus Flash tag cloud by BLUEnLIVE requires Flash Player 9 or better.

공지사항

Yesterday73
Today55
Total320,228

달력

 « |  » 2013.01
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    

최근에 받은 트랙백

글 보관함


. .