Broken Code (window31)

좀 오래된 플러그인이긴 한데, 별로 아시는 분이 없는 것 같아서 한번 소개해봅니다.
GODUP 라는 플러그인인데, 기능은 좀 잡종이라 이것저것 다 설명하긴 좀 그렇고요
(resource hack 이나 PE Scanner 같은 기능은 제쳐둡시다)
map loader 라는 기능, 이걸 한번 도마 위에 올려 보겠습니다 :)

이 기능이 어떤 것이냐면 map 파일을 플러그인에서 지정해 줄 경우,
현재 분석중인 바이너리를 map 파일로 매칭시켜서 디스어셈블리 창에 뿌려주는 겁니다.
즉, map 파일이 있는 바이너리를 분석할때는 아주 좋죠~
(map 파일이 없는 바이너리야 뭐 아무 상관없는 플러그인이지만...  ;;; )

한번 볼까요~

예를 들어 리버싱 시에 이런 코드가 있습니다.
뭐하는 call 문인지 안에 헤집고들어가서 후벼보기까진 알 수 없죠 :(


그런데 GODUP 로 한번 map 파일을 연결해주면 아래와 같이 바뀝니다!
올리디버거 상의 디스어셈블리 코드를 map 파일에 나온 함수명대로 연결시켜준겁니다 오 좋아요 ~!


자~ 이제 첫번째 call 문은 InitNSS() 라는 함수고, 두번째 call 문은 OnButtonStart() 라는
것을 알 수 있네요! 이름으로 추정해보면 대충 함수의 역할은 알 수 있죠 ㅎ 첫번째 함수는
초기화 루틴에 쓰일 것이고 두번째 것은 머 button handler 라는 것 까지 파악이 가능합니다 :)
그리고 이 함수는 CNSS_GUIDlg 라는 class 의 member 함수라는 것 또한 확인이 되고요

이런 기능 덕에 용이해지는 상황

1) 내 코드 리버싱
저희 같은 리버싱 떨거지 부류들은, 디버깅할 때 비주얼 스튜디오의 디버깅 환경을
이용하지 않고 (디버그 빌드 조차 안합니다 only Release Build ㅎㅎ) 자기가 만든
바이너리임에도 불구하고 ollyDBG 나 windbg에 붙혀서 디버깅 하죠 ㅋ
이런 상황일때 GODUP 는 아주 큰 힘을 발휘합니다.
적어도 내가 만든 코드를 보며 어디가 어딘지 몰라서 방황하는 시간은 확실히 줄여 줍니다 ;


2) 코드 컨설팅, 취약점 분석
코드 컨설팅 혹은 취약점을 찾고 있을 때
그 많은 코드를 모두 리버스 엔지니어링으로 확인하기는 사실 힘든 부분이 없지 않아 있죠.
그래서 부분적으로라도 개발팀에 소스를 요청하는데, 개발 보안 정책상 소스를 밖으로 빼낼
수 없는 경우도 있고, 컨설턴트 ㅅㅂ야 니가 어느정도 하나 보자 등 괜히 안줄때도 있습니다. :)

음 그럴땐 어떻게 어떻게 일단 map 파일이라도 받아냅니다.
그리고 그걸 현재 바이너리랑 맵핑시켜서 돌리면 오우~ㅋ
작업능률이 10배는 향상되죠.
그리고 소스 없이 리버스 엔지니어링만으로 상대방의 코드를 깔 수 있는 기회가
좀더 빠른 시간안에 생기는거죠 :p
(아으... 혹시 이 블로그를 보는 우리회사 개발자들 이제 저한테 맵파일 안주는거 아니겟죠 ;;; )

그래서 암튼 저는 주로 map file - exe file 맵핑에 이 플러그인을 많이 씁니다.

요점은 이런식으로 map 파일을 연결시켜주는 플러그인이 있고
그것을 올리디버거에서 이렇게 훌륭히 사용할 수 있다는 것이 되겠습니다 :)
그냥 악성코드만 보시는 분들은 필요 없는 플러그인이 될수도 있겠지만요...;

window31. 2009년 3월


ps
음 그냥 문맥상 코드를 깐다... 라고 표현했는데,
사실 실제 업무를 할때, 컨설팅 받는 입장이 더 고마운 것이긴 하지만
오히려 공격하는 입장에서 더 굽신굽신 해야 한다고 생각합니다.
코드를 공격하면서 거만하거나 매너 없는 사람... 크랙질이나 다를 바 없다고 보이거든요
진정한 남자라면 굽신모드.

그옛날 후킹이라는 주제를 처음 배울 때 인터넷이든 해외 사이트든 가장 먼저 설명하던
후킹의 종류는 IAT Hook 이었다고 생각합니다. IAT Hook을 먼저 안내하는 이유는 일단
PE를 공부하면서 Import Address Table 이라는 것에 대해 알아볼 때 부수적 효과로
덩달아 학습되기에 가장 적당한 주제이기도 하고, 또 후킹 구현이라는 데에 있어
inline hook 따위에 비하여 훨씬 쉽기도 하기 때문입니다.

그래서 보통 후킹에 대한 입문 하면 IAT Hook 부터 접하게 되는 것이 일반적이었다고
생각합니다. 따라서 저는 후킹이라는 주제를 하나의 큰 학문이라고 가정하고 그것을 수학에
비유한다면 IAT Hook 은 인수분해 쯤 되는 순서라고 봅니다. 또 그만큼 기초적이기도
하니까요.

하지만 쉬웠던 만큼 IAT Hook은 실전에선 그렇게 많이 써먹히지가 않았죠. 그 이유는
무엇일까요. 바로 IAT Hook 에는 "범용성" 이 없었습니다. 써먹을 타겟에 한계가 있던 것이죠.
IAT Hook 을 널리 전파하기에는 프로텍터와 패커라는 너무도 높은 관문이 있었습니다.
패킹한 바이너리의 IAT 를 찾는것은 패커의 종류마다 버전마다 너무도 많은 차이가 있고
또 그 각각의 IAT를 구하기도 쉽지 않습니다. 따라서 후킹하기에 앞서 모든 호환성이나
플랫폼을 감안하여야 하는 보안 솔루션 입장에선 IAT 는 건드리기 힘든 혹은 건드려서는
안되는 불모지 쯤으로 전락하게 됩니다.

그리고 역시 inline hooking 이 가장 범용적이면서 또 기능도 강력하기 때문에 사람들의
관심은 이쪽에 맞추어진 채로 지금까지 오게 됩니다. 그래서 inline hook 을 더 효율적으로
하는 여러가지 연구가 이루어집니다. 예를 들면 중간번지를 후킹한다거나 push address
retn, 트램벌린 코드 같은 시도가 그것들이죠. 처음 볼때마다 신기한 넘들이 등장하고
또 그것을 막거나 우회하기 위한 논의가 지속됩니다. IAT Hook은 버려져 있다고 생각하기
쉬운 이 시점에 overwrite hook은 계속 발전하고 있습니다.

하지만 최근에 실제 현업에서는 분위기는 또하나의 물결이 보이는 것 같습니다. 해커들에게
요즘의 대세는 IAT Hook 입니다. 보안업계 사람들이 버려둔채 이목이 집중이 되지 못하고
있는 영역인 것을 그들이 눈치라도 챈 듯, IAT 쪽을 최근 집중적으로 건드리고 있습니다.
특히 보안 모듈이나 보안 코드가 온전히 가동되고 있는 상황에 더욱 그렇습니다.

이들이 IAT 쪽을 공격하는 제가 나름대로 생각하는 이유를 적어보겠습니다.

1. 공격대상은 거의다 패킹된 바이너리이며 보안 코드 작성시 그 상태에서는 IAT 를
   쉽게 구할 수 없다. 따라서 검사하지 않을 것이다. 
2. 하지만 해킹툴을 만드는 입장에선 까짓거 노가다로 찾아서 하드코딩 해버리면 된다.
   (대부분이 이런 넘들임. 클라이언트가 패치하여 번지가 바뀌면 후킹하지 못함)
3. 보안 솔루션이 IAT 를 구하더라도 패커가 내부적으로 리다이렉트 시키는건지
   해킹툴이 훅을 하는건지 패커의 내부구조를 상당수 파악하기 전까진 분간하기 힘들다.
4. 훅을 해도 system dll 들의 메모리 CRC가 변경되지 않는다.

대략 이정도 같군요. 늘어놓고 보니 IAT Hook 이 공격하기에 꽤 매력적이라는 생각이
듭니다. 즉 이정도 이유만 되어도 IAT Hook 으로 공격할 당위성은 충분하다고 보입니다.

저는 르네상스 라는 단어를 좋아합니다. 르네상스는 문화의 부활 이라는 의미로 많이
사용되죠. 그래서 저는 IAT Hook 도 일종의 르네상스라고 보고 있습니다. 이전에
디버그랩에서 발표를 할 때에도 IAT Hook 의 르네상스라는 표현을 사용한 적이
있고 작년 마소에서 IRP Hook을 다룰 때에도 역시 마찬가지 비유를 들었던 기억이
있네요. 르네상스보다 사실 더 좋은 우리 선조들의 말씀도 있죠 "구관이 명관이다!"
예~ 역시 옛 것을 다시 살펴보는 것은 정말 중요한 것 같습니다.

마무리 짓자면 리버스 엔지니어링을 할 때 무언가 답은 나오지 않고 답답하다 싶으면
한번 IAT 쪽도 살펴보세요. 큰 힌트를 발견하게 될 수도 있습니다 :)

최근 들어 IAT 를 고도의 기술로 건드리며 우리를 당황하게 하는 중국애들을
보며 느낀 내용들입니다.


window31. 2009년 1월

오랫만에 리버스 엔지니어링 관련 글을 쓰게 되는 것 같네요 ^^;

오늘의 주제는 1byte Patch 입니다.
저희팀에서 같이 일하는 haru 라는 분이 예전에 간단히 만든건데요.
간단하면서도 나름 재미있는 부분이라 한번 설명해 보겠습니다.

윈도우즈의 계산기 calc 많이들 사용하시죠.

특히 개발자나 리버서들은 16진수 사용이 필수이기 때문에 보기 - 공학용 으로 변경하셔서
많이 사용하시곤 합니다.



근데 공학용 으로 셋팅을 바꾸면 윈도우즈에서 그 설정값을 기억하고 있기 때문에
계속 저런 모양이 되지만

16진수인 Hex 를 선택해도 종료한 뒤 다시 실행하면 Dec 로 바뀌어져 버립니다.
그래서 실행할때 마다 Hex로 바꾸어야 하는....
졸~~ 짜증나죠  ㅅㅂ

그래서 계산기 Dialog 가 셋팅될때 라디오버튼을 아예 Hex가 디폴트가 되도록 바꾸는 방법이
있습니다. 그 방법은? 초기화 코드에서 처음에 UI 설정을 할 때 10진수로 라디오버튼을 셋팅하는
부분을 16진수로 바까버리는 방법입니다.

그 부분을 한번 뜯어가 볼까요.

아래 이미지를 보시면 UI 초기화 루틴인데요,  0x1001DCD 번지의 콜문을 보세요.




여기가 계산기 진법 셋팅하는 루틴입니다. 인자는 진수고요. 인자를 esi에 넣고,
esi를 2, 8, 10, 16과 각각 비교하는 코드가 보입니다. 그 숫자는 2진법, 8진법, 10진법, 16진법에
대한 숫자겠죠 :)





그러므로 0x1001DCB에 들어가는 push 0Ah 를 push 10h 로 변경시켜주면
매번 16진수로 셋팅이 되어서 실행이 되겠죠 0x0A 를 0x10 으로 바꿔주기만 하면 됩니다.
간단한 1 byte patching 이죠 :p

아주 쉬운 내용입니다. 이것으로 앞으로 매번 실행시마다 16진수가 디폴트인 채로 사용할 수
있겠죠. 다음에는 몇가지 코드를 주입해서 쵸큼 더 지능적으로 바꿔보도록 하겠습니다. :)


window31. 2008년 9월.

서적 출간 소식입니다.
국내에서도 리버싱을 full 로 다룬 첫 서적이 나올 것 같네요 ^^

http://simples.co.kr/ 에서 esniper 님께서 리버싱관련 서적을 다음달 초에 내신다고 합니다.
아래는 목차고요. 목차에 대해 어느 보안 포럼에서는 이렇다 저렇다 논란 이 있긴 하지만
아직 알맹이도 보지 못한 상황에서 내용에 대해 왈가불가 하는 것 보다 리버싱 전문 서적의
첫 출간이라는 것에 더 큰 의의를 두어야 하지 않을까 싶네요.

(목차를 보며 그나마 할 수 있는 얘기는 코드 한줄한줄에 대한 Tracing 보다는
리버싱이라는 것을 다룰 때 포괄적으로 알아야 할 지식과 개념, 용어, Tool 등을
정리해놓았다는 생각이 정도? )

리버싱에 관심 있으신 분들 한권씩 지르세요 ^^;
리버싱 잘하시는분들도 지르세요ㅎㅎ 인식이 많이 높아지긴 했지만 리버싱은 아직도 희귀학문에
속하는 지라 "C++ 일주일이면 쵸큼 잘하게 된다" 이딴 책보다는 아무래도 매출이 적을테니
훌륭한 책을 널리 알리는데 다들 공헌해야 한다고 봅니다 :)

---------------------------------

1장 리버스엔지니어링에 대하여

1 리버스엔지니어링이란 무엇인가?

2 크래커에 의한 피해사례, 개발자들이 주의할 부분

3 리버스엔지니어링의 전망과 취업

4 리버스엔지니어링 관련 법률

5 라이센스 정책에 대한 정리

2장 리버스엔지니어링을 위한 기초지식

1. 올리디버거(OllyDBG) 설정 및 사용법

2. Jump구문제어 문제풀이

3. CPU레지스터와 어셈블리언어, 진수변환

  3-1. 진수변환

  3-2. CPU 레지스터

  3-3. 어셈블리 언어

  3-4. 상황별 어셈블리 명령어

4. WinApi 분석을 통한 문제풀이

5. 메뉴얼 Unpack과 Back To User모드

6. 키젠(KeygenMe)문제풀이를 통한 스택과 콜링컨벤션의 이해

7. KeyFile체크문제풀이와 바이너리 수정

8. NAG제거 문제를 통한 PE구조의 이해

3장 리버스엔지니어링 관련 툴

1. 툴을 사용하는 것에 대하여

2. 시스템 모니터링 툴(System-Monitoring Tools)

2-1. Filemon

2-2. Regmon

2-3. TcpView

2-4. Procexp

3. 디스어셈블러(Disassemblers)

3-1. IDA 설치 (Install)

3-2. 메뉴구성과 IDA 사용방법

3-3. 디버깅 (Debugging)

3-4. IDA에서 For문 분석하기

3-5. IDA에서 if문 분석하기

3-6. 크로스레퍼런스 기능과 지뢰찾기 분석

4. 디컴파일러(Decompilers)

4-1. 플래쉬 디컴파일러(sothink SWF Decompiler)

4-2. 닷넷 프로그램 디컴파일러(Reflector)

4-3. 델파이 디컴파일러(DeDe)

4-4. 자바 디컴파일러(JAD)

5. 메모리패치(Memory Patch)

5-1. 티서치(TSearch)

5-2. 치트엔진 (Cheat Engine)

6. 바이너리분석(Binary Analysis)

6-1. PEiD

6-2. 리소스해커

6-3. Strings

6-4. Dependency Walker와 DumpBin

7. 언패커(Unpacker)

7-1. Universal Extractor

7-2. VMUnpacker

8. 리빌더 (Rebuilder) - ImpRec

9. 헥스에디터(Hex-editors) - XVI32와 QuickBe

10. 루트킷탐지(Rootkit Detection)

10-1. GMER

10-2. IceSword

11. 네트워크 모니터링 툴(Network-Monitoring Tool) - Wireshark

12. 가상머신 (Virtual Machine)

12-1. Vmware

12-2. VirtualBox

4장 악성코드 분석

1. 악성코드란?

1-1. 파일 바이러스

1-2. 웜

1-3. 트로이 목마

1-4. 백도어

1-5. 스파이웨어

2. 악성코드 감염경로

2-1. 메신저에서의 파일 전송

2-2. 이메일에서 파일 다운

2-3. 의심스러운 사이트에서의 Activex 설치

2-4. P2P 사이트에서의 파일 다운

2-5. 인터넷에서 감염된 파일 다운

4.3 악성코드 분석 (IRC Bot) 

5장 안티디버깅(Anti Debugging)

01. 안티디버깅이란?

02. 안티디버깅의 종류

03. IsDebuggerPresent

04. Microsoft Visual Studio 2005 에서 컴파일 및 실행

05. Microsoft Visual Studio 6.0 에서 컴파일 및 실행

06. IsDebuggerPresent 우회방법

07. IsDebugged

08. IsDebugged 우회방법

09. NtGlobalFlags

10. NtGlobalFlags 우회방법

11. CheckRemoteDebuggerPresent

12. CheckRemoteDebuggerPresent 우회방법

13. FindWindow

14. FindWindow 우회방법


-----------------------------

개인적인 생각이지만, 사실 리버싱 글을 쓰기가 어려운 이유는
target 을 잡기가 힘들기 때문이라고 생각합니다.
無 에서부터 시작하는 일반 프로그래밍과는 달리, 리버싱은 분석을 당할 대상이 반드시 필요하고.

그 대상은 리버싱 당하다 보면 씹창이 나기 마련이며 씹창이 나다보면 취약점이나 허술한 부분이 까발려져서 개발자는 ㅄ이 되고 좋은 처리를 해 놔도, 그 아이디어가 오픈되어 역시 고생해서 코딩한 개발자는 짜증이 나고 결정적으로 상용 소프트웨어를 잘못 리버싱 했다가는 소송에 휘말리기 때문입니다.


그래서 대상을 선정하기 어렵고, 리버싱 하기 위해 ㅄ될 플그램을 직접 몇개 맹글어야 하고
하지만 리버싱하는거보다 코딩하는게 더 귀찮을 때가 있고
그리고 웬지 사람들 눈에는 UI도 제대로 없는 추리한 애플리케이션보다는
누구나 아는 익숙한 프로그램을 리버싱해주길 원하고
뭐 그런 ㅈ같은 현실 때문에 글 쓰는것, 그리고 크리티컬한 분석내용과 코멘트를 작성하는 것
이매우 힘든 것 같습니다.

이 서적을 쓰신 작가분도 그러한 고민을 하지 않았을까 하고 생각되네요.
리버싱이 P2P 프로그램 속도패치나 상용 S/W 시리얼 크랙 에만 이용되지 않고
좀더 전문적인 학문이 되려면 이같은 작가의 고민이나 현실적인 문제가 좀더 극복되어야 할 것
같습니다.

 

모 대학 컴퓨터시스템학과 학생들을 대상으로 리버싱 강의 요청이 와서
모교도 아니고 아무 상관없는 사람이지만 어쩌다가 강의를 하게 되었습니다.
저같은넘이 대학강단에 서보다니 학생들의 불운이 시작될거라고 제 친구가 그러는군요 ㅎㅎ
(음 날짜가 어제였는데, 3/15로 되어있네 타이핑 미스 ;; )

3시간이 넘는 강의였는데 그래도 조는 학생들 한명 없이 눈도 똘망똘망하게 뜨고 잘 경청해줘서
감사 드립니다. 질문도 많이 해 주셔서 고맙고요.

강의자료와 사용 툴, 바이너리는(공격코드 제외) 교수님을 통해 전달해드리도록 하겠습니다.

핵 드라이버에서 종종 발견되는 코드
정말 이거 싫다
대책이 있을랑가 ㅋ
무슨 코드인지 알만한 분들은 다 아실겁니다 :p
머 이 드라이버 만든 사람도 제 블로그 보고 있을지 모르겟지만 ;;

저는 컴터를 쓰다가 하루에도 여러번씩 내 컴터에 깔린 커널 드라이버 리스트를 확인합니다.
드라이버를 은밀하게 깔아서 할 수 있는 짓이 워낙 많다 보니.. 저 또한 피해자의 예외대상은
아니라고 생각되어 걍 머 버릇처럼 확인하고 있습니다.

그런데 오늘 출근해서 보니 vzthni.sys 라는 묘한 드라이버가 올라와 있더군요 -_-
파일 날짜를 보니 어제 퇴근 시간 직전 시간입니다.
어떤 개쉑이 내 PC에 기 들어와서 이상한거 깔아놓은건가 하는 압뷁에 순간 혼미해지더군요
저희가 짱개들로부터 해킹 공격을 하도 많이 받다 보니 그런 생각이 더했습니다.
그리고 제 PC는 워낙 음흉한 자료가 많다보니 ㅎㅎㅎ 더 심장이 조여오더군요 -_-

일단 바이러스 토탈에 먼저 넣어 봤습니다.

2개 백신에서 걍 오진인지 휴리스틱의 원인인지 암튼 의심스럽다 정도만을 내뱉는거 빼고는
아주 깔끔합니다 -_-

사실 깔끔해서 더 무섭더군요.
보통은 세상에 등장하지 않은 갓 태어난 싱싱한 바이러스에게 공격당하는 경우가 많거든요.
그 경우는 백신이 당연히 본적이 없는 바이러스이기 때문에 진단이 되지 않는것은 당연하고요 -_-

아무튼 드라이버를 얼른 뜯어 봤습니다.
크기도 상당히 크고, 의심스러운 짓을 너무나 많이 하더군요.

노티파이 루틴이 있어서 새 프로세스 생성도 감지하고 있고
그리고 SDT 도 건드리고 있는데, 테이블을 후킹하는게 아니고 오버라이트 훅을 하더군요
루트킷 디텍터에 걸리지 않으려고 아주 지대로 만들었군 하는 생각에 더 두려움에 떨었습니다....;
TCP접속도 체크하더군요.
난 완전 당한거야 무슨 파일들이 나갔을까 떨면서 IDA를 계속 보고 있는데
뭔가 이상합니다....

어디서 언젠가 본 드라이버 같아요.....

다시 한번 잘 뜯어보았습니다...
그리고 어제 퇴근시간 전에 실행했던 프로그램들을 생각해 보았습니다..

아악!!!! 하는 생각이 온몸에 휘감으면서
드라이버의 PE Header를 살펴보았습니다.
그리고 얼른 어떤 프로그램을 띄워서 그 프로그램의 드라이버를 로딩시킨 후
WinHex Kernel로 그 프로그램의 PE를 보았습니다...


오........이런....


File name : C:\Documents and Settings\window31\바탕 화면\vzthni.sys

== File Header ==
Machine              : 0x14C (Intel 386)
NumberOfSections     : 0x5
TimeDateStamp        : 0x46919405 (Mon Jul 09 10:48:53 2007)

두 드라이버의 타임스탬프를 비교해니 아주 명확하죠? (0x05 0x94 0x91 0x46)
vzthni.sys 의 범인은 IceSword의 드라이버였습니다 -_-

생각해보니 어제 퇴근시간 직전에 뭔가 확인해 볼 것이 있어서 IceSword를 실행했는데
이상하게 잘 실행되지 않고 좀비 상태로 멈췄길래 다시 한번 더 실행했던 기억이 나네요.
그때 오리지날 파일명인 IsDrv112.sys로 올라가지 않고 이상한 이름으로 드라이버가
로드되었던 것 같습니다.

IceSword가 실행될때 ㅄ이 되면 드라이버를 다른 이름으로 바꿔서 재 로드를 시도하는
코드가 있나 봅니다. 메인 exe는 아직 뜯어보지 않아서 더 구체적인 내용은 모르겠네요.

암튼 이상한 드라이버 때문에 십년 감수 했다는 -_-

아침부터 삽질 좀 했네요 ;;
머 덕분에 아이스스워드의 오리지날 드라이버 파일을 깔끔하게 획득 했습니다만 :p



걍 회의들어가기 전에 시간이 애매하게 남아서 끄적거려봤습니다.



(참고, IceSword의 드라이버는 로드시킨후 지워버리기 때문에 메모리에서 보아야 합니다
그래서 WinHex Kernel을 사용했습니다)


window31. 2008년 2월.

리버스 엔지니어링은 어디까지 지켜보아야 할까...
window31.


해킹/보안 분야에서 어떠한 주제를 화두에 올린다는 것은 정말 신선한 것이 될 수도 있지만
한편으로는 정말 위험한 행동이 될 수도 있습니다. 그 이유는 당연히 보안이라는
분야가 반드시 해킹이라는 전제가 선행되기에 따라오는 테마이며, 해킹이라는 전제가 등장하게
된다면 반드시 관련 프로그램의 취약점이나 유린할 수 있는 소재들이 꼬리에 붙기 때문이죠.
그리고 또 이것은 매우 위험한 행동과 직결되는 수도 있습니다 (법적인 문제까지)

그래서 해킹이나 특히 리버스 엔지니어링에 대한 어떠한 언급을 하기가 매우 조심스러워 집니다.
리버스 엔지니어링 쪽에 대해 한가지 주제가 나오게 된다면 당연히 리버싱 당할 Target 이
나올 것이고 이는 대부분 상용 소프트웨어거나 현재 End User에게 서비스 되고 있는 프로그램들이
대부분일 가능성이 높습니다. 이쯤 되었을 때 어느 정도 보안 쪽 경력이 있고 혹은 윤리성을 갖춘
리버서라면 리버싱을 하긴 해도 그에 대한 내용을 공개적인 자리에서 언급할 때 매우 고민을
하게 됩니다.

일단 요즈음 소프트웨어들은 대부분 리버스 엔지니어링 방지 문구를 약관에 집어넣고 있고
분명히 함부로 바이너리를 까보았다간 법적인 마찰까지 갈 수도 있습니다. 거기까지
이어지지 않더라도 최소한 그 사람에게 피해를 주거나 이리저리 귀찮게 불려다닐 수 있습니다.
만약 좀 심한 짓을 했고 그 사람이 어디 해커 출신이라면 그 그룹 멤버는 같은 출신이라는
이유만으로 영화처럼 줄줄이 엮여가기도 하죠.

그게 또 한편으로는 이해가 되는 것이 법적인 문제를 떠나서 같은 개발자 입장에서
내가 고생해서 졸라게 코딩을 해놨는데 그걸 어떤 한 개같은넘이 리버스 엔지니어링으로 완죤
ㅄ 을 만들어 놨다... 싶으면 사실 그건 그 개발자의 자존심에 중대한 타격을 주게 됩니다.
저시키는대체모야 머 이런것부터 시작해서 별의별말이 다 나올수 있습니다. 동종업계로써
사실 지켜야 할 윤리 덕목이 뭔지도 생각할 수 있는 부분이라고 봅니다.

따라서 만만한게 프리웨어고 혹은 상업성과 상관없는 프로그램들 혹은 기껏해야 해킹대회
프로그램만이 리버스 엔지니어링의 공개적인 석상에 오르게 됩니다(아 악성코드도 있네요).
물론 이런 것들을 통해서도많은 것을 배울 수 있긴 하지만, 배움의 열망과 갈망에 시달리는
이들에겐 사막 한가운데 오아시스의 그림자 정도밖에 되지 못합니다. 고수 리버서를 꿈꾸는
이들에겐 더욱 더 많은 자료와 더욱 더 체계적인 알맹이들을 원하고 그 흔적을 찾으려 인터넷을
항해합니다. 하지만 공개적인 자리에서 그런게 많지는 않죠.

몇년 전 리버스 엔지니어링에 대한 한글 자료는 그렇게 많은 자료가 있진 않았습니다. 하지만
지금은 어느 정도 쓸만한 자료들이 여기저기서 태동을 하고 있습니다. 리버스 엔지니어링에 대한
인식이 확산되고 있다는 사회적 현상으로 보입니다.

하지만 그에 걸맞지 않게 리버스 엔지니어링에 대한 부정적 인식은 더욱더 강해지고 있는 것
같습니다. 머 할말은 없는게 문화의 한 부분이 활성화되어 향유하는 것 까진 좋은데, 그것이
초딩들이나 기타 악의적 목적이 있는 이들에게 비윤리적으로 이용된다면,, 네거티브 캠페인이
자연스레 자리잡는것도 무리는 없다는 생각이 듭니다...

그래서 이제 생각해 볼 때가 된 것 같습니다. 과연 리버스 엔지니어링은 합법인가 불법인가
그리고 이것을 학문으로 규명해야 할 것인가? (물론 대학교에서 소프트웨어공학 시간에 리버싱에
대해 잠깐 나오긴 합니다만... 그건 간장종지 찍어먹는 수준에 불과하므로 일단 패스 ;; )

제 입장은 사실 두개입니다... 해킹/보안을 탐구하는 연구가의 입장과 밥벌어먹고 사는 사람인
보안 개발자나 보안 컨설턴트의 입장에서 말할 수 있겠네요..  일단 연구가의 입장에서는 당연히
합법입니다. 리버스 엔지니어링이 있어야 소프트웨어의 취약점을 규명할 수 있고, 또 이것은
제가 마소2월호 원고에 비슷한 내용을 언급하기도 했지만 코딩하는 사람의 심리적인 측면이나
습관 등도 관찰할 수 있기 때문에 심리학적인 부분까지도 깨우칠 수 있습니다. 따라서
기술적으로나 형이상학적으로나 학문으로 지정해줄 가치는 충분하다고 생각합니다.

다음으로 보안 개발자나 컨설턴트의 입장에선 반대입니다 -_- 왜냐하면 리버스 엔지니어링을
통해 보호를 해야 할 소프트웨어의 너무도 많은 부분이 까발려지고 있으며 그에 따라 수많은
해킹이 등장하고 있기 때문에 그를 일일히 다 처리하기는 너무 힘들기 때문입니다. 사실 기술을
기술로 이길 수는 없습니다. 특히 이쪽 분야는 더욱 그렇습니다. 막는 기술이 나오면 깨는 기술도
반드시 등장합니다. 따라서 제도적인 측면이 뒷받침을 해 주어야 (법적인 면) 막는 사람이 어느
정도 숨돌려가며 살 수 있습니다. 따라서 반대입니다 ;;

ㅎㅎ 두가지 입장을 모두 얘기해보았는데요 진짜 제 마음은 어느 것일까요.... :$
잠시 동문서답을 하자면 원래 단발에 살짝 끝내려고 했던 F-Secure Reversing 대회 원고를
분량이 너무 많다는 이유로 컷트당해 2회 기획으로 분리하고, 마소2월호 원고를 마친 후
다음 기획을 고민하면서 생각이 든 내용을 지금까지 한번 씨부려 봤습니다.

마이크로소프트 잡지에 보여주고 싶은 것이 몇개 있습니다(아... 잘난척 처럼 들릴 거 같네요
사실은 소재 모잘라 죽겠습니다). 하지만 리버스 엔지니어링이란 분야를 다루려니 걸리는
것이 너무 많네요. 이 프로그램으로 해보려니 그쪽 회사에서 전화 올 거 같고, 저걸로 해보려니
우리 회사에서 날 죽일라고 할 것 같고... 뭐 고민 중입니다. 어느 정도 수위를 어떻게 맞추어야
할 지... 윤리/도덕의 절대적 가치 판단의 자질이 매우 떨어지는 저로서는 망설임만을 갖게 합니다.

머 어쨌든 쓸데없는 소리는 이것으로 정리하고 :p

제 홈피에 마이크로소프트 기고 내용을 처음 광고 해보겠습니다 ㅎㅎ 이번주에 나올 2월호 기사는
지난번에 제 홈피에도 공개하지 않았던... 디버깅 도중 수학문제가 나와 날 황당하게 만들었던
F-Secure Reverse Engineering 대회 Level 3을 다룹니다.

다음번엔 별로 할게 없어서 악성코드나 할까 합니다. major function table hooking 쪽을
기획하고 있습니다. IRP Hook 이라고나 할까요 ㅋㅋ 잼있는 악성코드가 있었거든요
드라이버 쪽이 되겠네요 드라이버 쪽 아는것도 개뿔도 없으면서 글 쓰려니 쪼팔리는군요 -.-

window31. 2008년 1월

 

IDA 5.2 + HexRay를 어둠의 경로에서 구해서 한번 써봤습니다.
완전 장난아니군요 -_-

IAT Hook을 하는 소스를 HexRay로 돌려봤습니다.

bool ReplaceIATEntry(LPCSTR pszRepDllName, FARPROC pfnCurFunc, FARPROC pfnNewFunc, HINSTANCE hModInst) { LPBYTE pImageBase = (LPBYTE)hModInst; if(!pImageBase) return false; PIMAGE_DOS_HEADER pIDH = (PIMAGE_DOS_HEADER)pImageBase; if(pIDH->e_magic != IMAGE_DOS_SIGNATURE) return false; PIMAGE_NT_HEADERS pINH = (PIMAGE_NT_HEADERS)(pImageBase + pIDH->e_lfanew); if(pINH->Signature != IMAGE_NT_SIGNATURE) return false; PIMAGE_DATA_DIRECTORY pIDD = &pINH-> OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT]; PIMAGE_IMPORT_DESCRIPTOR pIID = (PIMAGE_IMPORT_DESCRIPTOR)(pImageBase + pIDD->VirtualAddress); for(; pIID->OriginalFirstThunk; pIID++) { LPSTR pszModName = (LPSTR)(pImageBase + pIID->Name); if(!strcmpi(pszModName, pszRepDllName)) break; } if(!pIID->Name) return false; DWORD dwDummy = 0; PIMAGE_THUNK_DATA pThunk = (PIMAGE_THUNK_DATA)(pImageBase + pIID->FirstThunk); for(; pThunk->u1.Function; pThunk++) { FARPROC* ppfn = (FARPROC*)&pThunk->u1.Function; if(*ppfn == pfnCurFunc) { VirtualProtect(ppfn, 4, PAGE_READWRITE, &dwDummy); *ppfn = pfnNewFunc; return true; } } return false; }



놀랄 노자죠 ㅎㅎ
이정도면 머 거의 소스나 다름없죠 -.-
그간 왤케 고생해서 디스어셈블링을 공부한거지요 ㅎㅎ

일단 이 소스에서 간단히 파악할 수 있는 프세이드 코드로 변환될때의 특징은
1) 초반 코드로 사용되는 파라메타 검증 if문은 goto로 해석한다는것
    (하지만 머 위의 코드를 goto로 구현해도 실제로 컴파일러는 비슷하게 빌드해주니 별 상관없음)

2) 구조체에 대한 타입캐스팅은 이루어지지 않는다는거
    (머 되는 넘도 있겠죠? 하지만 일단 PE 쪽 구조체는 안 나오네요 ㅎㅎ)

3) 일부 멤버 변수는 걍 상수로 나와버립니다. 포인터로 바로 계산을 해버리는듯

4) 그냥 16진수로 표시해주는게 어떨까 하는 생각이 드는데... 23117 을 보고 한참 생각했다는 -_-
   (아시다시피 pIDH->e_magic 은 PE의 표식을 알려주는 MZ Header 값이죠)


어쨌든 헥스레이 정말 물건이네요
이걸로 상당한 시간절약을 할 수 있을 것 같습니다.
헥스레이 개발자.......정말 천재입니다.....감탄 !

요즘 메신저 안 쓰시는 분들은 거의 없을겁니다.
그와 관련하여 자주 듣는 질문 중 하나가, 왜 메신저들이 남의 프로세스에 DLL을
집어넣느냐는 것입니다.

실제로 네이트온 같은 경우도 NateOnHook40u.dll이란 넘을 모든 프로세스에 집어넣죠.

예전에 신영진님과 이거에 대해 간단한 토론?을 한 적이 있는데요,
뭐 일단 그때 영진씨한테 들은 내용을 바탕으로 결론부터 말씀드리면 메신저가 이같이
dll을 넣는 이유는 "자리비움"기능을 구현하기 위해서라고 합니다.
그때 추가로 이루어졌던 토론이 꼭 메시지훅을 해서 자리비움을 구현할수밖에 없느냐...란 얘긴데
그건 결론이 나오진 않았었구요 :p

어쨌든 그렇게 얘기하고 머 멀 넣든 말든 별 문제는 없으니까 이후로도 걍 신경을 껏지만
얼마전에 저희 팀 메일로 메신저 부류가 왜 dll을 넣는지 궁금하다는 문의가 있어서
간만에 옛기억을 떠올려보며 한번 뜯어봤습니다.

간단한 화면캡쳐를 통해 그 원리를 말씀 드려 보겠습니다.

메신저 dll을 IDA로 간단히 본 화면입니다.
2008년도부터 리버스 엔지니어링에 대한 법적인 조항이 생긴다는 얘기가 있어서
무슨 프로그램인지에 대한 언급은 생략하겠습니다 :p

일단 아래 화면은 dll을 넣기 위해 message hook을 하는 코드입니다.
Hook id는 2번과 7번이 들어가는데 이는 각각 키보드 훅, 마우스 훅 입니다.
키보드 입력과 마우스 움직임을 감지하기 위한 것입니다.

#define WH_KEYBOARD         2
#define WH_MOUSE            7

후킹 프로시져인 fn과 sub_10001110은 동일한 기능을 하고 있으므로 하나만 보겠습니다.
마우스 훅에 대한 프로시져인 sub_10001110를 볼까요,

보시면 머 잡다한 짓을 하다가 sub_1000830E 를 부르는데요 쟤가 바로 시간을 계산하는
부분입니다. 안으로 들어가보면 GetLocalTime과 GetSystemTime등으로 난리부르스를 떨고
적절한 상수를 eax에 뱉어내줍니다. 그 값이 time_t 타입의 현재 시간을 나타내는 값입니다.
어쨌든 머 현재 시간을 계산하는 부분이라고 생각하시면 되겠네요

아 참고로 쓸데없는 부연지식을 첨가해보자면, 정확히는 저 부분은 개발자가 구현한 시간 루틴이 아니고
우리가 많이 쓰는 time()함수입니다. 즉, time_t time( time_t *timer ); 이거 입니다.
실제로 time()함수는 리버싱을 해보신분은 아시겠지만 저 함수가 실제로 있는것이 아니고
컴파일러가 GetLocalTime과 GetSystemTime 등을 조합해서 만들어주는 함수입니다.
따라서 빌드 후에 확인해보면 dll로 점프하지 않고 exe내부의 call문으로 생성되죠.

궁금하신 분들은 MSDN의 time() 예제코드를 빌드해보시고 직접 리버싱 해보세요 :p
참고로 IDA는 똘똘이스머프이기 때문에 그 call문을 time()이라고 완벽히 해석해주지만
OllyDBG는 바보이기 때문에 걍 흔해빠진 call문중의 하나로 보여줍니다 ㅋ

어쨌든 훅을 걸고 시간을 계산했습니다. 그리고 time_t 형태의 리턴값을 받았구요
위 이미지를 보시면 걔를 전역변수 어딘가에 넣어줍니다. 이곳은 어디일까요

네~ 정답은 쉐어드 섹션이 되겠습니다. 다른 프로세스에서(정확히는 메신저의 exe인
메인 모듈에서) 타 영역의 프로세스에도 접근하기 위하여 이같은 섹션을 만들어 두고
거기에 현재 시간 값을 가져와 비교하는 것으로 확인됩니다.

그럼 정리해 보겠습니다.

1) 메시지 훅을 걸어 모든 프로세스에 DLL 주입
2) 사용자가 마우스를 움직여서 훅이 걸리면 현재의 시간 shared section에 기록.
3) exe에서 shared section을 읽어와서 사용자가 마지막으로 마우스를 움직였을때의 시간과
   현재 시간을 비교
4) 그 시간이 3분 등 자리비움 설정 시간을 넘어서면 현재 상태를 "자리 비움"으로 변경  
5) 다른 어떤 프로세스가 포그라운드로 오게 되어도 DLL이 들어가 있으므로 역시
   마우스 움직임 캐취 가능

자 대충 이정도 알고리즘이 되겠네요 :p

여기서 수정 또는 덧붙힐 내용이 있습니다.

먼저 exe에서는 키보드 훅과 마우스 훅 외에 WH_CBT 훅까지 걸고 있습니다.
WH_CBT 훅은 윈도우가 생성/소멸/활성화 될때의 훅 체인을 걸 수 있습니다.
따라서 새 프로그램이 실행되어도 dll 을 주입할 수 있는 이유는 이 훅 때문이겠죠.

하지만 이로써 알 수 있는 부분은, 초반에 "모든 프로세스에 DLL을 주입.."이라고 했는데
CBT Hook에 의한 것이므로 정확히는 "윈도우를 가진 모든 프로세스"가 되겠죠 :)
따라서 윈도우가 없는 프로세스는 dll이 들어가지 않을거구요 :p

대충 이정도로 정리를 해보았습니다.

그런데 지금 글을 쓰면서 확인해보니 MSN 8.1은 더이상 남의 프로세스에 dll을 집어넣지 않네요?
예전에는 분명히 넣었던 것을 확인했는데 현재 dll 리스트를 보니 확실히 아무것도 없습니다.
MSN 8.1은 영진씨와 고민했던 "메시지훅을 하지 않고 자리비움 기능을 구현" 과제를 해결했나 보네요 :p

나중에 시간이 날 때 msn도 한번 살펴보도록 하겠습니다(혹시 이미 알고계신 분 있으시면 알려주세요)


2007년 12월.