반응형

3rd CodeEngn ReverseEngineering Seminar

  날짜
 2009년 7월 4일 토요일 오후 13:00 ~ 18:30


  장소
 서울여자대학교 인문사회관 3층 인사랑당(316호)

  등록비용
 학생 : 1만5천원 / 직장인 : 3만원

  주최 / 주관
 심플스 커뮤니티(이강석, 박영호, 박병익)

  발표주제
 최상명, 김태형 : (파일바이러스 치료로직 개발자 입장에서 본) 파일 바이러스 분석
 고흥환 : 윈도우 커널 악성코드에 대한 분석 및 방법
 박찬암 : DEFCON CTF 2009 Binary Leetness 100-500 Solutions
 안기찬 : Reversing Undocumented File Formats using a Hex Editor and your Brain

등록 : http://codeengn.com/2009/

개인적으로 리버스엔지니어링에 많은 관심이 있다. 참석하고 싶지만 일정이 어떻게 될지 몰라서.
아 흔치 않은 기회인데.. 거금 3만원을 들여서라도 참석하고픈 맘도 있지만..  일정상 보류..

반응형
나의 두번째 희생양이 된것은 에스큐엘디비엑스 입니다.

제가 사용하는 디비툴중에 편리함으로 치면 쵝오! 라고 생각하는 툴이고 상용입니다.

상용툴이고 또 제가 애용하는 툴이기에 제품명에 색칠 좀 했습니다.ㅎㅎ;(장난치나 라고 돌던지지 말아주시길^^;)

이 툴 또한 패킹이 되어 있지 않더군요.. 해당 툴 버전은 밑에 스샷에 보시다시피 Professional Edition 이구요.

라이센스 만료라 하여 별 신경쓰지 않았지만 한번 까 보았습니다.

그다지 어렵지 않게 리버싱이 되었고 해결되더군요. 상용 제품으로서 좀더 신경을 쓰는 편이 좋을것 같습니다.







리버싱에 흥미를 느끼고 틈틈히 공부해 나가면서 많은 것을 배우는것 같습니다.

그리고 리버싱에 관한 법률에 대해 다시 한번 잘 읽어봐야겠다는 생각이 들기 시작했습니다.

상용프로그램에 대한 리버싱 힌트나 파일은 절대 공개하지 않을 것입니다.
  1. acranes 2010.02.28 23:11

    정말 대단하시네요
    제가 꼭 필요한데 주시면 않되나요?
    acranes@naver.com 입닏다.
    감사합니다.

반응형


Unable to write to memory of debugged process (7FFDA002..7FFDA002).

Ollydbg 실행시에 위와 같은 에러가 뜨는 경우가 있다. 적잖이 짜증이 난다.

이는 Ollydbg 플러그인 설정이 잘못 되어 있기 때문이다.

Ollydbg 탭에 보면 Plugins > OllyHelper > Options..

Auto Clear the debug bit.  에 체크가 되어있다면 체크를 풀어주면 된다.

  1. 좋네요 2010.12.30 03:11

    뭐가 계속 충돌인지 궁굼했었는데 이거였군요

  2. 1902D 2011.02.02 23:03

    고맙슴다

  3. 굳굳 2016.10.15 13:24

    아직 블로그 운영하시는진 모르겠지만
    unable to " read "to memory of debugged process 오류는 어떻게 해결하나요??

반응형

윤근용 happyme9@nhncorp.com | 필자는 시스템 프로그래머로 시스템에 대한 다양한 분야에 관심이 많다. 특히 보안 문제에 대한 관심이 높아 다년간 보안 업무에 종사하고 있다. 바이러스 보안 업체를 거쳐 현재는 NHN에서 주로 보안 관련 프로젝트를 수행하고 있다.


루트킷은 자신을 감추기 위해서 다양한 기술을 이용한다. 가장 대표적인 것이 후킹을 이용하는 방법이다. 주로 SSDT 후킹과 같은 커널 레벨에서의 후킹이 많이 사용되는데 이를 위해서는 루트킷이 커널 드라이버 형태로 작성돼야 한다. 루트킷은 스스로를 더욱 교묘하고 은밀하게 숨기기 위해 커널 패치와 같은 로우 레벨의 조작을 수행하는 경우가 많으며, 심지어는 BIOS와 같은 펌웨어를 이용하기도 한다. 가상화 기술을 이용하는 루트킷 기술은 이제 더 이상 새로운 것이 아니며, 이미 새로운 위협으로 예상되어 왔다. 하지만 현재 대부분의 보안 제품으로는 탐지하기 힘들다면 것이 문제라고 할 수 있다. 즉 가상화 기술을 이용해서 자신의 VM(Virtual Machine) 안에서 독자적으로 루트킷이 실행된다면 현재의 보안제품으로는 탐지가 불가능하다. 따라서 악성 코드가 가상화 기술을 이용하는 경우에는 문제가 더욱 심각하다.

가상화의 위협

루트킷 탐지가 어려운 이유 중 하나는, 루트킷 탐지 소프트웨어와 동일한 레벨의 권한을 가지고 수행된다는 것이다. 대부분의 루트킷 탐지 소프트웨어는 커널 레벨에서 동작하지만 루트킷 또한 커널 레벨에서 동작하는 커널 드라이버 형태로 많이 작성된다. 따라서 서로 동일한 능력을 가지고 대치되기 때문에 탐지 및 무력화가 쉽지 않은 것이 현실이다. 따라서 어느 한쪽이 더 높은 권한을 가진다면 승패는 한쪽으로 기울 것이다. 커널 레벨보다 한 층 더 높은 권한을 부여 받을 수 있는 방법이 바로 가상화다. 가상화로 커널 레벨보다 높은 권한을 갖는 루트킷은 커널 레벨에서 동작하는 루트킷 탐지 소프트웨어를 무력화 시킬 수 있다(<그림 1> 참조). 이와 반대로 루트킷 탐지 소프트웨어가 커널 레벨보다 더 높은 권한을 갖는다면 커널 레벨에서 동작하는 루트킷은 부처님 손바닥 안의 손오공 신세가 돼 버릴 것이다(<그림 2> 참조).

가상화

가상화(Virtualization)라는 용어는 다양한 분야에서 사용된다. 컴퓨터 시스템에서의 가상화는 시스템의 유효한 리소스(하드웨어, 운영체제, 데이터 등)를 보다 효율적으로 사용하기 위해서 연구되어 왔다. 그 중 하나가 운영체제 가상화인데, 이는 하드웨어 리소스가 부족했던 6~70년대 VMM(Virtual Machine Monitor)이라는 개념으로 출발했다. VMM은 하드웨어와 운영체제 사이에 위치해서 하드웨어에 대한 리소스(CPU, Memory, Physical Disk)를 가상화한다. VMM이 운영체제에게 제공하는 인터페이스는 하드웨어가 운영체제에게 제공하는 인터페이스와 동일하기 때문에 운영체제 입장에서는 VMM의 존재 여부에 영향을 받지 않고(존재 자체를 모르고) 동작할 수 있으며, VMM에 의해서 동시에 여러 운영체제가 동작할 수 있다.

하이퍼바이저

하이퍼바이저(Hypervisor)란 하나의 시스템에서 동시에 여러 개의 운영체제를 사용할 수 있게 해주는 가상화 플랫폼을 말한다. 가장 대표적이고 쉬운 예로 VM웨어를 들 수 있다. 하이퍼바이저는 다음과 같이 크게 두 가지 형태로 구분된다. 물론 아래의 두 형태가 복합된 형태 또한 가능하다. Type 1에서는 VMM (Virtual Machine Monitor)이 Host 운영체제 안에서 동작한다.

Type 2에서는 VMM(Virtual Machine Monitor)이 하드웨어와 게스트 운영체제(Guest OS) 사이에 존재한다.

다음은 Type 1형태로 구현된 VM웨어의 내부 구성요소이다.

- VMApp : 유저 레벨 애플리케이션(Host OS의 App로써 동작)
- VMDriver : 호스트 시스템을 위한 디바이스 드라이버(Host OS의 커널에서 동작, 호스트 운영체제와 게스트 운영체제 간의 실행 context switching을 담당한다.)
- VMM : VMDriver가 로드되면서 생성되는 virtual machine monitor

소프트웨어 가상화

IA-32에서 운영체제는 Ring 0, 애플리케이션은 Ring 3 권한으로 동작한다. 하지만 가상화 환경에서는, 하드웨어와 직접 연결되어 가상화를 수행하는 VMM이 Ring 0 권한으로 실행돼야 한다. 이때, 운영체제도 동일하게 Ring 0 권한으로 실행되면 운영체제가 VMM 코드를 제어할 수 있을 뿐만 아니라 VMM에 의한 가상화 자체가 불가능해 진다. 따라서 운영체제는 VMM보다 낮은 권한을 부여한다. 이러한 작업을 Ring Deprivileging이라고 하는데, Ring Deprivileging은 다음과 같은 두 가지 형태로 수행된다.

♦ VMM : Ring 0
   Guest OS : Ring 1
    App : Ring 3

♦ VMM : Ring 0
   Guest OS : Ring 3
   App : Ring 3

이렇게 운영체제의 실행 권한이 하향 조정됨으로써 야기되는 문제점 때문에 VMM의 역할 비중이 커졌다. 즉 운영체제가 하드웨어에 접근하는 작업이나 특정한 시스템 콜과 같이 Ring 0 권한이 요구되는 작업을 모두 모니터링해서 그에 맞는 작업을 수행해야 한다. 동시에 여러 개의 운영체제가 동작 중이라면 이들에 대한 Context Switching을 VMM이 담당해야 한다. 실행권한 변경에 따른 문제점을 극복하기 위해서 Paravirtualization, Binary Translation 등의 방법들이 이용됐다.
하지만 Paravirtualization은 운영체제의 커널을 수정해서 특정한 VMM에서 가상화가 가능하도록 하는 것인데, 이는 리눅스와 같은 오픈소스 운영체제에서나 가능한 일이며 일반적으로 적용할 수 있는 방법이 아니다. 또한 Binary Translation은 상대적인 성능상의 부하가 문제가 된다. 이런 소프트웨어 가상화에 의한 문제점을 해결해 주는 것이 CPU 레벨의 가상화라고 할 수 있다. 즉 가상화를 구현하기 위해서 사용된 Paravirtualization, Binary Translation과 같은 작업을 CPU 레벨에서 지원하는 것이다.

하드웨어 가상화

인텔, AMD의 CPU 레벨에서 제공하는 하이퍼바이저를 하드웨어 가상화라고 할 수 있다. 인텔이나 AMD에서 CPU 레벨의 가상화를 지원하기 전까지는 대부분 소프트웨어 가상화에 의존해왔다. 하지만, IA-32 자체가 가상화에 맞지 않는 구조를 가지기 때문에, (애초에 하나의 운영체제만 동작하도록 설계됨) 소프트웨어 가상화 구현의 어려움  뿐만 아니라 그에 따른 부가적인 문제점을 갖게 된다.

인텔

- VT(Virtual Technology, 코드명: Vanderpool) 간단히 IVT라고 한다.
- IA-32 기반 CPU에서의 IVT를 VT-x라고 하며 IA-64(itanium)기반 CPU에서의 IVT를 VT-i라고 한다.
- 제공 CPU: 일부 펜티엄 4, Xeon, 코어듀오, 코어 2 듀오 프로세서(IVT기능을 지원하는 정확한 인텔 CPU 목록은 http://process orfinder.intel.com에서 조회 할 수 있다.)

AMD

- AMD-V(AMD Virtualization, 코드명: Pacifica)
- 제공 CPU: (64비트 x86 아키텍처) AMD 애슬론 64, 애슬론 64×2, 튜리온 64?2, 옵테론, 페놈

VT-x

이제 인텔 CPU에서 제공하는 VT-x에 대해서 간단히 살펴보자. VT-x에서는 VMX(Virtual Machine Extension)라는 실행 모드를 지원함으로써 가상화를 가능케 한다. VMX는 두 가지 모드로 나뉘는데, VMX root operation(fully privileged Ring 0) 모드와 VMX non-root operation(less privileged Ring 0) 모드이다. 여기서 VMM은 VMX root operation 모드로 동작하고 VM은 VMX non-root operation 모드로 동작한다. VMX root operation 모드는 몇 가지를 제외하고는 일반적인 CPU 동작 모드와 거의 동일하다. VM non-root operation 모드에서의 CPU 작업은 가상화를 지원하기 위해서 제약되거나 변경된다. 더 정확히 말하면 root operation 모드로 동작하는 VMM은 Ring 0 보다 권한이 높고, non-root operation 모드로 동작하는 게스트 운영체제는 Ring 0, App는 Ring 3 권한으로 동작한다. VMX의 동작 모드 변경은 다음 두 가지 경우가 있다.

♦  VM entry: VMM이 VMX non-root operation 모드로 VMX not-root operation 모드로 동작하는 VM의 코드(운영체제, 애플리케이션)가 실행된다.
♦  VM exit: VMM이 VMX root operation 모드로 VMX root operation 모드로 동작하는 VMM으로 CPU 제어권이 반환된다.

VMS operation의 시작과 종료는 VMXON, VMXOFF 명령에 의해서 수행된다. 특정한 명령이나 이벤트(예외 발생, I/O 디바이스 접근, 특정 레지스터 접근 등)가 발생하면 VM exit에 의해서 VMX root operation 모드가 된다. VMCS(Virtual Machine Control Structure)의해서 VMX의 모드 변경과 VMX non-root operation이 관리된다(AMD-V의 경우는 VMCB (Virtual Machine Control Block)).

<그림 5>에서 보는 바와 같이 루트킷 디텍터 등의 보안 프로그램은 어디까지나 루트킷 VM에 의해서 로드되고 컨트롤 되는 하나의 게스트 운영체제 상의 커널 모듈이거나 일반적인 애플리케이션일 뿐이다. 따라서 이런 구조에서의 루트킷 탐지는 거의 불가능하다(100 퍼센트 불가능한 것은 아님).

가상화 기술을 이용하는 루트킷

이제 앞에서 언급한 가상화 기술을 이용하는 루트킷에 대해서 알아보자.

SubVirt

SubVirt는 마이크로소프트와 미시간 대에서 가상화 기술을 이용한 루트킷이 가능한지 여부를 증명하기 위해서 만든 것이며, 기존의 가상화 소프트웨어(VM웨어, 버추얼-PC)를 이용한 것이므로 진정한 의미의 가상화를 이용한 루트킷이라고 보기 힘들다. SubVirt는 호스트 운영체제로 리눅스를 이용하며 시스템의 Boot Sequence를 수정해서 원래의 운영체제를 로드한다.

Vitriol

Dino Dai Zovi에 의해서 개발된 VM 루트킷으로써 MaxOS X 운영체제에서 동작하며 인텔 VT-x(인텔 코어듀오/솔로)기술을 이용했다(2006년 10월 마이크로소프트의 BlueHat 컨퍼런스에서 발표되었다).

BluePill

Vista x64(AMD 64)에서 AMD-V를 이용한 VM 루트킷. BIOS 수정이나 SubVirt처럼 Boot Sequence를 변경시키는 작업을 수행하지 않으므로 재부팅 없이 언제든지 설치가 가능하며 어떤 입출력에 대해서도 가상화를 않기 때문에 성능상의 부하가 거의 없다.

현재 그리고 미래

루트킷과 악성코드를 구분하는 게 모호하긴 하지만 엄밀히 말하면 같지는 않다. 루트킷과 악성코드의 결합, 정확히 말하면 악성 코드가 루트킷 기술을 사용하면(이미 이런 악성코드가 많은 것이 현실이다.) 더욱 강력한 공격력과 전파력을 보유한다. 그러면 탐지나 방어, 치료(제거)와 같은 후속 조치가 더 어려워질 것이다. 사실, MPack과 같은 공격 툴킷이 거래되고 있는 블랙마켓이 존재하는 것이 현실이다. 심지어 악의적인 행위 자체도 거래가 된다. 이를 통한 잠재적인 피해 규모는 산정하기 힘들 정도다. 예전에는 악성 코드를 여러 형태로 분류했지만 이미 오래 전부터 대부분의 악성코드가 복합적인 성격을 띄기 시작했다. 서로간의 사용 기술을 복합적으로 사용하고 있을 뿐만 아니라 목적 자체도 복합적인 것들이 많아졌다.

CPU에서 제공하는 가상화 기능을 이용하는 것은 단지 루트킷의 은닉 기술 중 하나일 뿐이다. 가상화 이외에도 하드디스크의 사용하지 않는 섹터를 이용해서 은닉하는 기술, ATAPI 스펙을 이용한 은닉과 같이 탐지가 불가능한 경우가 상당히 많다. 가장 무서운 것은 알려지지 않은 루트킷, 좀더 정확히 말하면 알려지지 않은 기술을 사용한 루트킷은 존재여부 조차도 모르고 있다. 더 큰 문제는 기존의 보안 프로그램이 교묘한 방법을 사용하지 않고 전통적인 기술을 사용하는 루트킷도 만족스럽게 탐지하지 못한다는 점이다. 탐지해도 안전하게 제거하는 기술은 아직 미흡한 실정이다. 루트킷 탐지를 위한 기술 영역뿐만 아니라 루트킷을 안전하고 완벽하게 제거하는 기술 영역도 지속적인 연구가 필요하다. 현재까지 안정적으로 루트킷을 탐지할 수 있는 증명된 기술은 없다. 루트킷이 사용하는 기술과 보안 소프트웨어가 사용하는 기술이 크게 다르지 않기 때문에 누가 먼저 새로운 기술을 이용하느냐에 따라서 그 승패가 좌우된다. 마이크로소프트에서 얼마 전에 코모쿠(komoku)라고 하는 안티 루트킷 솔루션 업체를 인수했다는 소식은 시사하는 바가 크다고 할 수 있다.

반응형

신영진 pop@jiniya.net, http://www.jiniya.net|웰비아닷컴에서 보안 프로그래머로 일하고 있다. 시스템 프로그래밍에 관심이 많으며 다수의 PC 보안 프로그램 개발에 참여했다. 현재 데브피아 Visual C++ 섹션 시삽과 Microsoft Visual C++ MVP로 활동하고 있다. C와 C++, 프로그래밍에 관한 이야기를 좋아한다.


SDT 후킹

SDT(Service Descriptor Table) 후킹은 시스템 서비스 테이블의 값을 조작하는 API 후킹의 한 방법이다. 유저모드 API 후킹의 경우 프로세스간 컨텍스트가 다르기 때문에 시스템 전역 후킹을 하기 위해서는 일일이 모든 프로세스에 관련 코드를 주입(injection) 시켜야 한다는 불편한 점이 있었다. 이러한 문제를 해결한 한 가지 방법이 SDT 후킹이다. SDT 후킹은 커널모드에서 한 번만 후킹을 하면 모든 프로세스에 적용되기 때문에 별도로 컨텍스트 관리를 할 필요가 없기 때문이다.

SDT 후킹의 방법을 이해하기 위해서는 우선 윈도우의 API 호출이 어떻게 커널로 전달되는지를 알아야 한다. 간단하게 windbg를 통해서 TerminateProcess 호출이 커널로 전달되는 과정을 살펴보도록 하자. 응용 프로그램에서 호출한 Terminate Process는 ntdll.dll의 NtTerminateProcess로 이어진다. <리스트 1>에 windbg를 통해서 디스어셈블한 NtTerminateProcess 함수가 나와있다. eax에 0x101를 넣고, 0x7ffe03000에 저장된 번지를 호출하는 것을 알 수 있다.

<리스트 2>에 나와있는 것처럼 0x7ffe0300는 edx에 현재 스택 포인터를 저장하고 sysenter 명령어를 호출하는 코드임을 알 수 있다. sysenter 명령어는 유저모드에서 커널모드로 진입하기 위한 명령어로 MSRs에서 실행할 커널 함수 주소를 가져와서 그 번지로 이동시키는 역할을 한다. rdmsr 명령어를 통해서 sysenter 명령어가 수행됐을 때 실행되는 함수를 찾아보면 KiFastCall Entry라는 것을 알 수 있다. KiFastCallEntry는 eax에 저장된 서비스 번호에 해당하는 함수를 호출하는 역할을 한다.

여기까지 과정을 요약하면 TerminateProcess 호출은 ntdll. dll의NtTerminateProcess로 이어지고, NtTerminate Process는 eax에 TerminateProcess API의 서비스 함수 번호인 0x101을 넣고 커널모드에서 KiFastCallEntry를 호출한다. KiFast CallEntry는 SDT를 참조해서 eax에 저장된 서비스 번호에 해당하는 함수를 호출한다. 이제 실제로 SDT에 대해서 살펴보도록 하자. SDT는 총 네 개의 서비스 테이블로 구성된다. 각 테이블은 <리스트 3>에 나와있는 SDE 구조체로 이루어져 있다. SDE 테이블의 각 필드별 설명은 <표 1>에 나와 있다. SDT의 첫 번째 테이블은 윈도우의 네이티브(native) API 함수를 저장하고 있는 ntoskrnl 테이블이다. 두 번째 테이블은 GUI 함수들을 저장하고 있는 win32k 테이블이다. 세 번째, 네 번째 테이블은 추후 사용하기 위해서 예약된 테이블이다.

윈도우 커널에는 기본적으로 두 종류의 SDT가 포함되어 있다. KeServiceDescriptorTable은 일반적인 스레드에 사용되는 테이블로 ntoskrnl 테이블만 사용하고, 나머지 테이블은 모두 사용하지 않는다. KeServiceDescriptorTableShadow는 GUI 스레드에 사용되는 테이블로 ntoskrnl과 win32k 테이블을 사용한다. <그림 1>은 이러한 구조를 도식화한 것이다.

windbg를 통해서 실제 커널의 SDT를 살펴보도록 하자. <리스트 4>에 커널의 SDT 구조체를 덤프한 내용이 나와있다. 살펴보면 ntoskrnl 테이블의 base 주소는 0x84e46a8, counter는 0, limit은 0x11c, arg 필드 값은 0x80514eb8인 것을 알 수 있다. 함수 테이블을 덤프한 것을 보면 첫 번째 함수의 시작 주소는 0x80581302인 것을 알 수 있고, 인자 크기는 0x18 바이트란 것을 알 수 있다. 한 가지 주의해서 볼 사실은 GUI 함수 테이블과 GUI 인자 테이블은 커널 내부가 아닌 win32k.sys 내부에 존재한다는 것이다. <리스트 4>에서도 이 두 테이블의 주소만 확연히 틀린 것을 확인할 수 있다.

이제 SDT에서 TerminateProcess API의 서비스 함수를 찾아보자. <리스트 1>을 보면 eax에 0x101을 집어넣고 있으므로 TerminateProcess API의 서비스 함수 번호는 0x101이란 것을 알 수 있다. 함수 테이블은 4바이트 기준이고, 인자 테이블은 한 바이트 기준이란 점을 생각해서 해당 내용을 덤프 해보면 <리스트 5>와 같다. TerminateProcess의 서비스 함수 주소는 0x80586740이고, 인자는 0x08 바이트 크기인 것을 알 수 있다. 해당 주소를 디스어셈블하면 커널 내부의 NtTerminateProcess 함수가 출력된다.

이제 끝으로 SDT 후킹을 하는 방법을 생각해보자. SDT 후킹이라 함수 테이블의 번지를 바꾸는 작업을 하는 것을 말한다. <리스트 5>에서 0x101번에 해당하는 서비스 함수 주소는 0x80586740이다. 이 값을 우리가 만든 임의의 함수 주소로 변경한다면, 응용 프로그램에서 TerminateProcess를 호출할 때 원본 서비스 함수가 아닌 우리가 새롭게 작성한 함수가 호출된다.

SDT 복구

루트킷은 API 호출 결과를 조작하기 위해서, 보안 프로그램은 시스템 상황을 모니터링하기 위해서 SDT 후킹을 광범위하게 사용한다. 이런 경쟁 조건에서는 먼저 실행되어서 SDT를 후킹한 쪽에 우선권이 주어진다. 예를 들어 루트킷이 NtQuerySystem Information 함수를 후킹한 상태를 생각해보자. 이후 실행되는 보안 프로그램에서 호출하는 NtQuerySystemInformation의 결과값은 루트킷에 의해서 조작된 값이기 때문에 신뢰할 수 없게 된다. 따라서 보안 프로그램은 자신이 동작하는 환경이 안전한지를 점검하는 것이 최우선 과제라 할 수 있다.

이러한 문제를 해결하기 위해서 나온 것이 SDT 복구 기술이다(http://www.security.org.sg/code/sdtrestore.html). 이 기술의 원리는 간단하다. 현재 시스템의 SDT와 파일로 존재하는 커널의 SDT를 비교해서 같은지 다른지를 비교하는 것이다. SDT 후킹을 하더라도 변경되는 것은 현재 메모리의 내용일 뿐 파일의 내용은 원본 그대로 이기 때문이다. 이 방법의 전체적인 실행 순서는 다음과 같다.

♦ 현재 로드된 커널의 이미지 이름과 로드 주소를 알아낸다.
♦ 로드된 커널의 KeServiceDescriptorTable의 base 주소를 알아낸다.
♦ 동일한 이름의 커널을 LoadLibraryEx를 통해서 메모리에 로드시킨다.
♦ 로드된 이미지에서 base와 동일한 오프셋에 있는 테이블 내용을 비교한다.

<리스트 6>은 이를 간단한 의사 코드로 만들어본 것이다. 핵심적인 부분은 함수 테이블 주소의 오프셋을 사용해서 Load LibraryEx로 로드한 커널에서 해당 부분을 찾아내는 것이다. 현재 로드된 커널의 이미지 이름과 베이스 주소는 NtQuery SystemInformation 함수를 사용해서 구할 수 있다.

SDT 재배치

참 아이러니 한 사실은 보안 제품에서 루트킷을 잡기 위해서 개발된 SDT 복구 기술이 역으로 루트킷에서 사용한다는 것이다. 보안 제품도 시스템 모니터링을 하기 위해서 SDT 후킹을 사용하는데 루트킷이 보안 제품을 무력화하기 위해서 SDT 복구를 사용하는 것이다. 이러한 루트킷에 대항하기 위해서 만들어진 기술이 SDT를 재배치하는 방법이다. 이 방법은 앞서 살펴본 SDT 복구가 로드된 커널의 KeServiceDescriptorTable[0].base에서 찾는다는 사실을 이용한다. base 필드의 값이 커널 이미지 외부에 있다면 로드한 커널 파일에서는 그 부분을 찾을 수 없다. 메모리를 할당한 다음 해당 영역으로 함수 테이블을 복사하는 것이 핵심이다. 그리고 커널의 base 필드 값을 할당된 메모리로 연결해주면 된다. 이렇게 변경된 경우의 테이블 구조가 <그림 2>에 나와 있다.

SDT를 찾는 또 다른 방법

SDT 재배치 방법이 나오고 얼마지 않아 루트킷 진영에서는 오리지널 커널 이미지 파일로부터 SDT의 주소를 알아내는 새로운 방법이 나왔다(http://www.rootkit.com/newsread.php? newsid=176). 이 방법은 커널의 초기화 코드에서 base 주소를 찾아내는 방법을 사용한다. KeServiceDescriptorTable은 커널의 KiInitSystem이란 함수에서 <리스트 7>과 갈은 형태로 초기화된다. base 주소에는 KiServiceTable이란 고정적인 값이 할당되기 때문에 이 부분을 통해서 base 주소의 기본 값을 찾아낼 수 있다.

이 방법의 전체적인 실행 순서는 다음과 같다. 글만 보고는 의미를 이해하기가 쉽지 않기 때문에 <그림 3>에 나와 있는 명령어 구조와 재배치 오프셋의 관계를 보면서 의미를 파악하도록 하자. <리스트 8>에는 재배치 정보에서 SDT 주소를 찾아내는 과정에 대한 의사코드가 나와있다.

♦ 현재 로드된 커널의 이미지 이름을 알아낸다.
♦ 동일한 이름의 커널을 LoadLibraryEx를 통해서 메모리에 로드한다.
♦ GetProcAddress를 통해서 KeServiceDescriptorTable 주소를 구한다.
♦ 모든 재배치 정보를 조사해서 재배치하는 곳의 참조 주소가 KeSer viceDescriptorTable인 것을 찾는다.
♦ 찾아낸 부분의 명령어 코드 형태가 mov [mem32], imm32 형태 인지를 조사한다.
♦ 5단계까지 일치했다면 재배치 주소+4에 있는 값이 KeService DescriptorTable[0].base의 초기 값이 된다.

전용 SDT

SDT를 둘러싼 이러한 싸움이 한창일 때 SDT 후킹에 대한 원론적인 의문을 품은 사람들이 있었다. 그 의문은 다름 아닌 SDT 후킹이 과연 시스템 전역 후킹인가에 대한 것이었다. 그들은 좀 더 세밀하게 커널을 분석했고, SDT 후킹이 시스템 전역이 아니라는 결론에 도달하기에 이르렀다(http://zap.pe.kr/index. php?page=pages/researches/winternals_kr.php). <리스트 9>에 나와있는 것처럼 커널 스레드 구조체에는 ServiceTable이란 필드가 있다. 이 필드의 역할은 해당 스레드의 서비스 테이블을 가리키는 역할을 한다. 앞서 살펴본 것과 같이 일반적인 경우에 모든 스레드는 <그림 4>에 나타난 것처럼 KeService Descri ptorTable이나 KeServiceDescriptorTableShadow 중에 하나의 서비스 테이블을 가리키기 때문에 SDT 후킹이 시스템 전역인 것처럼 보였던 것이다.

전용 SDT란 <그림 5>에 나타난 것처럼 특정 스레드의 Service Table을 수정해서 전혀 새로운 서비스 테이블과 연결시키는 방법이다. 앞서 살펴보았던 방법을 통해서 커널 파일에서 원본 SDT를 추출한 다음 그 정보를 기반으로 새로운 서비스 테이블을 만들면 SDT 후킹이 이루어진 상태라 하더라도 해당 스레드는 SDT 후킹으로부터 자유로울 수 있다.

인라인 후킹 vs 트램펄린

SDT를 새롭게 만들어서 스레드에 연결시키는 방법이 나오면서 더 이상 SDT 후킹은 의미가 없어졌다. 보안 개발자들은 좀 더 하위레벨의 코드를 직접 후킹하는 방법을 선택했다. 인라인(inline) 후킹으로 불리는 이 방법은 커널 함수 도입부를 후킹된 함수로 점프하는 코드로 패칭하는 것을 말한다. <리스트 10>과 같은 NtTerminateProcess 함수 본문을 <리스트 11>과 같이 바꾸는 것이다.

후킹에 관심이 있는 개발자라면 대부분 알고 있듯이 이러한 인라인 후킹은 트램펄린 함수를 사용해서 손쉽게 무력화 시킬 수 있다. 트램펄린 함수란 원본 함수와 도입부를 동일하게 구현하고 점프 코드 다음으로 바로 이동시키는 것을 말한다. <리스트 12>에는 이러한 트램펄린 함수의 한 예가 나와있다.

보안 개발자들의 다음 선택은 단순하게 트램펄린 함수에 무력화 되지 않도록 여러 함수를 동시에 인라인 후킹하는 방법이었다. 다중 인라인 후킹으로 불리는 이 방법은 후킹을 하고자 하는 함수에서 사용하는 다른 함수도 같이 인라인 후킹을 하는 것이다. NtTerminateProcess 함수는 내부적으로 PspTerminate ThreadByPointer, ObfDereferenceObject, ObClearProcess HandleTable와 같은 함수를 사용한다. 이들 함수를 동시에 후킹하면 앞서 살펴본 TL_NtTerminateProcess를 호출하더라도 TerminateProcess 함수 본문에서 호출하는 다름 함수에서 걸리기 때문에 단순 트램펄린 함수로는 우회하기가 쉽지 않다. <그림 6>은 해커가 이러한 상황을 공격하기 위해서 각각에 대한 트램펄린 함수를 만들어둔 화면을 보여주고 있다. <그림 6>에 나와 있듯이 이렇게 각각의 트램펄린을 만든다고 하더라도 CALL로 연결된 2번 선 때문에 인라인 후킹을 무력화 할 수 없다.

물론 그렇다고 이러한 다중 인라인 후킹을 무력화할 수 있는 방법이 전혀 없는 것은 아니다. 트램펄린 대신 함수를 통째로 복사해서 사용한다면 다중 인라인 후킹도 무력화할 수 있다. <그림 7>은 이런 방식으로 함수를 통째로 복사해서 다중 인라인 후킹을 무력화하는 방법이 나와있다. NtTerminateProcess를 원본 운영체제 코드를 복사해서 그대로 만들되 CALL 하는 부분만 Psp TerminateThreadByPointer가 아닌 TrampolinePsp Termina teThreadByPointer를 호출하도록 만드는 것이다. 인라인 후킹된 함수가 많다면 굉장히 번거로운 작업이 되겠지만 결국은 시간과 노력만 투자한다면 어떤 종류의 인라인 후킹이든 우회할 수는 있다.

물론 복잡하게 트램펄린을 만들지 않고 JMP 부분만 원본 코드로 덮어 쓴다면 쉽게 후킹을 우회할 수 있다. 하지만 이렇게 값을 덮어 쓰는 방법은 SDT 후킹과 마찬가지로 경쟁 조건을 유발 시킨다. 서로 JMP와 원본 코드를 끊임없이 덮어쓴다면 그 결과는 예측할 수 없다. 또한 일부 보안 프로그램에서는 자신의 후킹 코드가 손상되는 경우에는 시스템을 중단시키기도 하기 때문에 값을 덮어쓰는 방법은 신중하게 결정해야 한다.

후킹을 넘어서

점프 코드 지뢰밭을 일일이 제거하면서 나가는 것도 재미는 있지만 속도는 더디게 마련이다. 지뢰를 굳이 제거하지 않고 그 위를 날아간다면 그 또한 좋은 방법일 것이다. 앞서 우리가 원본 SDT를 커널 파일에서 찾은 것처럼 커널 파일에 있는 원본 코드를 사용한다면 지뢰밭을 뚫지 않고 날아가는 것도 가능하다.

<그림 8>에는 이러한 아이디어가 나와있다. 커널 파일 자체도 PE 포맷이라는 점과 재배치 섹션이 존재한다는 점을 생각한다면 커널을 로딩하는 것이 불가능한 일은 아니라는 것을 알 수 있다. 커널 모드 코드에서 메모리를 할당하고 그곳에 커널을 올린다음 재배치를 수행하면 <그림 8>의 왼쪽과 같은 구조가 된다. 커널 코드가 두 벌이라는 것과 함께 각각의 커널은 자신의 자료 구조를 가질 것이다. 하지만 이렇게 되서는 곤란하다. 왜냐하면 자료 구조는 전부 기존 커널의 것을 이용해야 하기 때문이다. 약간의 트릭을 써서 커널을 할당된 메모리에 올린 다음 재배치를 기존 커널의 주소에 로딩된 것처럼 수행한다면 <그림 8> 오른쪽 그림과 같은 구조가 된다. 커널의 코드는 두 벌이 되지만 참조하는 자료 구조는 하나가 된다. 이 상황에서 새로 로딩한 커널의 NtTer minateProcess를 호출한다면 트램펄린 함수를 하나도 만들지 않고 모든 인라인 후킹을 우회할 수 있다.

반응형

강병탁 window31@empal.com, www.window31.com|바이너리 취약점 분석 업무를 하고 있다. 안티 크래킹/안티 디버깅 엔진 개발을 다년간 해왔으며 시스템 프로그래밍과 리버스 엔지니어링에 관심이 많다. 악성 코드나 해킹툴이 내부에 담고 있는 천재적인 알고리즘에 감탄하며 오늘도 IDA를 돌린다.


루트킷은 반드시 커널 레벨에서만 가동돼야 한다는 고정관념이 있다. 유저 레벨에서 아무리 숨겨 보았자 커널에서 쉽게 발견할 수 있다는 점에서 기능상의 한계를 많이 지적하는 편이다. 하지만 루트킷을 단순히 ‘최고의 은닉’ 기술에만 국한시켜서는 안 된다. 은닉이라는 기본 테마가 ‘무엇으로부터의 은닉’ 이라는 구체적 명제에 목매이지 않는다면, 유저 레벨 루트킷도 훌륭한 투명인간이 될 수 있다. 예를 들어 유저 레벨의 루트킷은 IceSword 같은 대부분의 루트킷 디텍터에 쉽게 발견되는 편이다. 하지만 그 같은 커널 드라이버를 이용하는 루트킷 디텍터를 사용할 수 없는 경우, 그리고 루트킷을 사용할 목적지가 드라이버와 무관한 장소일 경우라면 유저 레벨 루트킷도 충분한 가치를 발산할 수 있다. 더욱이 루트킷 하면 드라이버라고 생각하는데, 유저 레벨 루트킷은 드라이버를 설치하지 않고 숨겼다는 점에서 어떤 면에서는 더욱 훌륭하다고 볼 수 있다.

그리고 유저 레벨 루트킷은 “절대로 발견할 수 없도록 숨긴다”라는 목적보다는 그 기술이나 구현론 자체에 더욱 중점을 둬야 한다고 본다. 유저 레벨 루트킷을 구현하려면 API Hooking이나 각종 시스템 지식들이 다양하게 요구된다. “절대 발견할 수 없도록 숨긴다”에 너무 치중하지만 않는다면, 유저 레벨 루트킷을 연구하면서 얻을 수 있는 시스템 개발적 지식은 아주 많으리라 생각된다. 또한 유저 레벨의 루트킷은 굳이 루트킷 구현이 아닌 다른 여러 곳에서도 이용될 수 있는 알고리즘도 있기 때문에 얻을 수 있는 것은 더욱 많다고 생각된다. 따라서 루트킷을 커널에서만 구현해야 한다는 관념에 너무 얽매일 필요는 없으며, 유저 레벨에서 구현할 수 있는 루트킷은 어떤 것이 있고, 구조는 어떠한지 살펴볼 필요가 있다.
 
API Hooking

유저 레벨 루트킷으로써의 가장 기본임과 동시에 모든 부분이 되기도 하는 기법이 바로 API Hooking이다. Ring3에서는 시스템에 전역적인 영향을 끼치는 커널 구조체를 컨트롤 할 수 없으므로 은닉을 위해서는 기본적으로 후킹 기법을 필수적으로 사용한다. 그리고 타겟이 되는 API는 사용자가 공격자의 코드나 바이너리를 발견하지 못하도록 모듈을 찾는 관련 함수가 직접적인 대상이 된다. 예를 들면 파일을 찾을 때 FindNext File() 이나 프로세스를 찾을 때의 Process32Next() 같은 API가 대표적인 경우이다. 따라서 유저 레벨 루트킷은 이와 같은 API를 후킹하는 작업을 필수적으로 진행하므로 먼저 API Hooking에 대해서 살펴볼 필요가 있다. API Hooking에는 기본적으로 두 가지 기법으로 나누어진다. 첫째는 IAT Hook, 둘째는 Inline Hook(Overwrite Hook)이다. 여기서 사실 IAT Hook은 루트킷을 구현하는데 있어서 실전에서는 그다지 많이 쓰이지 않는 편이다. 왜냐하면 요즘 필드에 릴리즈되는 바이너리들은 암호화를 위해 대부분 프로텍팅·패킹이 돼서 배포되고 있는데, 프로텍터나 패커들은 API Call의 정보를 숨기거나 다른 보안상의 이유로 IAT를 망가뜨리거나 여러 갈래 꼬아놓은 자체 IAT를 사용하고 있다. 그래서 이 경우는 IAT가 잘 구해지지 않기 때문에 해당 테이블을 후킹 할 수 없고, 당연히 내가 원하는 은닉 기술을 활성화 할 수 없다. 따라서 IAT와는 무관하게 궁극적으로 DLL의 엔트리 포인트로 이동하는 부분을 노린, Inline Hook 방법을 많이 사용한다.

API Hooking을 위한 사전 준비 지식

유저 레벨에서 API Hooking을 위해서는 반드시 해당 프로세스에 DLL을 주입해야 한다(물론 DLL없이 빈 번지를 할당하여 코드를 삽입하고 리모트 스레드를 돌리는 방법도 있지만, 그 방법 역시 지금부터 설명할 세 가지 방법 중, 3번에 해당하는 것이기 때문에 별도 설명은 생략한다). DLL을 주입하는 방법에는 세 가지 방법이 있다. 첫째는 메시지 후킹, 둘째는 AppInit_DLLs 이용, 셋째는 CreateRemoteThread 이다. 이중 첫째는 윈도우가 없는 프로세스는 DLL을 집어넣을 수 없고, 둘째의 AppInit_ DLLs은 다른 프로그램이 사용하는 경우도 있으니 루트킷 구현이 목적인 API Hooking 방법으로는 적절한 방법이 아니다. 따라서 모든 프로세스의 DLL을 집어넣기 위한 방법으로는 셋째인 CreateRemoteThread가 가장 적합하다. 이 기법은 대부분 OpenProcess -> VirtualAllocEx -> WriteProcess Memory -> CreateRemoteThread 의 패턴을 사용한다. API Hooking에 이용되는 가장 표준적인 방법이기도 하다.

다음은 어느 API를 후킹해야 루트킷이 되는지 기능별로 살펴볼 필요가 있다. 목적은 자신을 발견할 수 없게 하는 법이 우선이다. 따라서 모듈이나 프로그램을 발견하기 위해서는 파일을 찾거나 메모리를 뒤지는 방법을 생각할 수 있는데 루트킷은 그것을 저지해야 하는 기능이 반드시 포함돼야 한다. 즉 모듈을 찾을 때에는 프로세스 검색, 파일 검색 더불어 서비스 리스트 검색까지 세 가지 방법이 있으며 루트킷은 이 세 가지 검색 방법을 모두 무력화 시켜야 한다.

프로세스 숨김

프로세스 리스트에서 공격자가 만든 바이너리가 보이지 않아야 하는 것이 첫 번째 과제이다. 프로세스를 나열하는 방법은 대표적으로 툴헬프32와 PSAPI가 있다. 따라서 루트킷은 유저 레벨에서 프로세스 리스트를 링크에서 제외시키기 위하여, Pro cess32Next()와 OpenProcess()를 후킹해야 한다. Open Process()만 후킹하면, 프로세스의 핸들만 얻을 수 없다 뿐이지, 툴헬프로는 PID와 프로세스 이름까지는 구해지기 때문에 유저 레벨에선 반드시 Process32Next()까지 처리해야 한다. 자신의 핸들이나 PID를 구해 놓고, OpenProcess()나 Process32Next() 후킹 함수에서 자신을 찾으려 할 때, 자신의 정보를 숨기는 방법이다. 만약 DLL을 가진 경우는 Module32Next()도 같은 방법으로 처리해 준다.

서비스 숨김

바이러스나 백도어를 찾을 때 서비스에 등록됐는지 살펴보는 경우가 많다. 그 때 루트킷이 서비스에 등록이 되어 있는 모습이 쉽게 발견되면 안 되므로, 서비스 리스트를 뽑을 때 그 목록에서 제거할 필요가 있다. 서비스 리스트는 EnumServices StatusEx 이라는 API를 사용한다. 루트킷은 이 API를 후킹하여 자신의 링크를 끊는다.

파일 숨김

탐색기나 내 컴퓨터 등에서 파일 리스트가 보이지 않아야 한다. 원리는 프로세스 리스트 때와 비슷하며 타겟이 되는 API는 FindNextFile 이다. 유저 레벨 루트킷은 이 API도 놓치면 안 된다. 이렇게 유저 레벨 루트킷을 구현하기 위한 세 가지 처리 부분을 살펴보았다. 프로세스, 서비스, 파일 리스트에서 자신을 숨긴다면, 별다른 루트킷 디텍터의 도움을 받지 않는 이상 해당 모듈을 찾기는 결코 쉽지 않다. 커널 드라이버를 설치할 필요도 없고, EXE와 DLL만으로 루트킷을 구현할 수 있다. 이것이 유저 레벨의 루트킷이다.

유저 레벨에서 루트킷 검출 방법

그렇다면 이번엔 유저 레벨에서 루트킷을 찾는 방법에 대해 알아보자. 물론 유저 레벨에서의 검출 방법은 커널 레벨에 비해 그 활용성이 지극히 제한적이고, 기법도 다양하지 않은 편이다. 그러나 방법이 전혀 쓸모없는 것도 아니다. 또한 이런 방법이 반드시 루트킷을 찾을 때만 사용되는 기술은 아니라는 점에서 다른 여러 시스템 프로그래밍에 활용할 수 있는 부분도 있다. 그렇다면 유저 레벨에서의 검출 방법에는 어떤 것이 있는지 살펴보자.

csrss.exe 의 스레드 리스트 이용

윈도우 시스템 프로세스 중 하나인 csrss.exe를 활용하면 유저 레벨에서도 루트킷을 감지할 수 있다. csrss.exe는 Client Server Run-time SubSystem의 약자로 윈도우 시스템을 가동시키는 핵심 프로세스이다. 이 프로세스는 윈도우에서 실행되는 모든 프로세스의 오브젝트를 관장하고 있다. 따라서 csrss.exe의 스레드 리스트를 구하면 루트킷 프로세스까지 검출이 가능하다.

후킹 원복화

후킹 되어 있는 API를 직접 원복화 시켜 버리는 방법이다. 물론 툴로 제공되는 경우도 있고 직접 VirtualProtect()와 Write ProcessMemory()를 이용하여 구현할 수도 있다. 지금은 디버거를 직접 붙여서 강제로 원복화를 시켜 보도록 하겠다. <화면 4>를 보자. 현재 FindNextFile이 h.dll 로 후킹 된 상태이다.

이 상태에서 이 코드를 원복화 시켜버리자. FindNextFile의 엔트리 코드는 mov edi, edi 로 시작하며 그 이후의 코드까지 포함하여 후킹 된 5바이트를 OpCode로 표현하면 0x8B, 0xFF, 0x55, 0x8B, 0xEC이다. 이 코드로 엔트리를 덮어써 버리자. <화면 5>가 그 내용이다.

그 후킹된 코드는 사라지고 오리지날 상태의 엔트리 포인트가 된다(<화면 6> 참조). 이제 FindNextFile의 후킹은 제거했다. 따라서 무결 상태의 FindNextFile을 사용할 수 있을 것이며 루트킷의 DLL을 거치치 않게 되므로 파일 검색이 가능하다. 이런 식으로 API Hooking을 원복화 시켜서 무력화 할 수 있다.

PID 연속 대입 방법

아무리 루트킷이 프로세스를 숨겨도 PID는 당연히 있기 마련이다. 그리고 PID는 0xC번부터 0xFFFF번까지 존재한다(4번 PID는 시스템이 사용한다). 따라서 PID를 4씩 늘려가며 연속해서 프로세스의 핸들을 오픈해 본다면, 현재 프로세스 리스트엔 없지만 PID가 있는 경우가 나타날 수 있다. 이 경우는 100% 루트킷의 프로세스이다. PID Brute Force 라는 기법이며, 단점은 루트킷이 프로세스의 핸들조차 얻지 못하도록 처리해 놓았을 때는 이 방법으로 검출이 불가능하다는 점이다.

유저 레벨 루트킷은 커널 하층부에 또 하나의 시스템이 더 들어올 수 있다는 약점이 있으므로 한계가 있고, 또 모든 프로세스를 통제해야 한다는 점에서 커널 루트킷보다 오히려 더 까다로울 수도 있다. 하지만 유저 레벨 루트킷은 반드시 루트킷 구현의 목적이 아닌 시스템 프로그래밍의 진수를 보여주는 여러 가지 기법을 사용한다. DLL Injection과 API Hooking, 그리고 각종 오브젝트의 활용적인 부분까지 유저 레벨 쪽의 Windows Internals에 대한 지식을 많이 함축하고 있다. 따라서 유저 레벨의 루트킷은 그 기능의 강력함의 여부를 떠나 기술 그 자체, 구현 알고리즘 자체에 우선순위를 두어 평가하는 것도 좋지 않을까 생각한다.

참고자료

1. Rootkit - http://www.rootkit.com

2. Anti-Rootkit - http://antirootkit.com/

3. Rootkits : Subverting the Windows Kernel - by Greg Hoglund, Jamie Butler

반응형

권용휘 rodream@gmail.com|필자는 악성코드 제거 프로그램인 ‘울타리’를 제작/배포하고 있다. 그 이외에도 여러 프리웨어를 http://rodream.net을 통해 배포하고 있다. 가끔씩 코드프로젝트나 루트킷에 글을 기고한다. 악성코드로부터 시스템을 지키기 위해 오늘도 컴퓨터를 켠다.

루트킷은 이미 오래전부터 존재했다. 유명세를 탄 무렵에는 이미 기술이 대부분 공개된 상황이었다. 기술 자체는 새롭거나 특별할 것이 없지만, 언제부터인가 ‘보안의 핵심’ 으로 대두됐다. 과연 왜 갑자기 유명세를 탔을까? 루트킷이 유명해진 이유는 앞에서 언급했듯이 큰 기업의 스캔들로 인해서 루트킷에 관심이 없던 해커와 크래커 그리고 프로그래머에게 존재가 알려졌기 때문이다. 정체가 알려지자 많은 크래커가 루트킷을 사용했다. 악의적인 일을 좀 더 효과적으로 그리고 완전히 성취하기 위해 루트킷의 소스코드나 프로그램을 활용하기 시작했다. 결국 기존의 바이러스가 좀 더 고급적인 보안 기법을 써서 시스템을 파괴했고 백신 업체들은 이를 방어하기 위해 루트킷에 대한 대응책을 마련할 수밖에 없었다.

루트킷의 정확한 의미

이제 루트킷이 정확히 무엇을 의미하는지 알아보자. 말 그대로 루트킷은 루트(Root) 권한을 쉽게 얻게 해주는 킷(Kit)이다. 루트킷을 사용하면, 보안 허점을 이용해 원하는 일을 처리하도록 도와준다. 파일이나 레지스트리를 숨기는 것이 루트킷이 하는 대표적인 일이다. 이는 악성 프로그램이나 바이러스를 시스템에서 제거하려는 시도를 무력화시키기 위한 것이다.

이와 같이 루트킷이 실제로 하는 일은 자신을 은폐하거나 삭제할 수 없도록 하는 게 대부분이다. 일반적으로 자신을 은폐하기 위해서 루트킷은 운영체제나 시스템을 변화시킨다. 우리가 쓰는 운영체제는 크게 두 개의 계층(유저 모드와 커널 모드)으로 이루어져 있다. 커널 모드에는 실제로 운영체제의 핵심적인 작업을 수행하는 코드가 동작하며, 유저 모드는 커널 모드의 코드를 사용하기 위해 API를 사용한다. 예를 들면, 파일을 지우기 위해 프로그램에서 DeleteFile API를 사용하면, 유저 모드에서는 파일을 직접 지우는 기능이 없으므로 커널 모드의 파일 지우는 코드가 동작하도록 요청한다.

또한, 백신 프로그램 등이 바이러스가 동작중인지를 찾아내기 위한 방법으로 어떤 프로그램이 실행중인지 알아내는 방법도 이와 동일한 과정을 거친다. 즉 유저 모드에서는 실제로 작업을 하는 게 아니라, 단지 커널 모드로의 이관을 도와준다. 루트킷을 써서 은폐하는 프로그램은 바로 이렇게 커널 모드로 이관하는 길목에서 자신을 은폐하기 위한 일을 한다. 은폐하는 일 자체가 점점 고도화되고 복잡하기 때문에 루트킷을 이러한 기술의 일련으로 오해할 수 도 있다. 하지만, 루트킷이라고 부르는 것은 기술 자체보다는 기술을 사용해 기존 시스템의 정책(Policy)에 역행할 수 있는 것을 의미한다.

앞에서 언급하였던 유저 모드에서 커널 모드로 이관되는 과정을 변형 시키는 것을 가리켜 후킹(Hooking)이라고 한다. 하지만, 후킹을 사용했다고 해서 모두 루트킷이라고 명명하면 안 된다. 생각해보면 이는 매우 당연한 것인데, 현재 많이 사용하는 DRM 프로그램이 포함한 실시간 암·복호화도 후킹을 사용해 구현되는 경우가 대부분이지만, 아무도 이를 루트킷이라고 말하지는 않는다. 최근 소니 USB에서 새로운 루트킷이 검출됐다는 보도가 나왔다.

기사에서는 루트킷을 판별하는 데 기술적인 측면보다 파일과 프로그램을 은닉하는 것이 악용될 수 있다는 점에 집중하고 있다. 그렇다면, 모두에게 인정받은 프로그램이 정상적인 목적으로 이러한 기능을 사용하는 경우에는 어떻게 될까? 답은 이런 경우에도 루트킷이라는 칭호를 달 수 밖에 없다는 것이다.

필자가 직접 확인했던 모 언론사의 툴바 프로그램은 다른 프로그램이나 사용자에 의해 임의로 지워지지 않도록 프로그램을 숨기고 삭제하지 못하도록 해 놨다. 분명 루트킷이라고 판별할 수 있다. 이는 프로그램을 사용해 다른 프로그램도 함께 숨겨지거나 삭제할 수 없도록 할 수 있기 때문이다. 설명을 덧붙이면, 이 프로그램이 만약 C:\Program Files\??Toolbar 라는 폴더 아래에 있는 모든 파일을 숨기고 아래에 있는 프로그램을 사용자로부터 은닉시킨다면 악성코드를 만드는 사람의 입장에서는 자신의 프로그램의 실행 파일을 자동으로 C:\Program Files\??Toolbar 폴더 아래에 자동으로 복사하도록 설정할 수 있다. 이렇게 된 경우에, 사용자가 ??Toolbar를 설치하면 자기 자신을 보호하기 위한 프로그램이 악성코드를 숨겨주는 부가 효과(Side Effect)가 발생한다. 이러한 부가 효과는 시스템에 매우 치명적이며 악영향을 미친다. 지워지지 않는 악성코드가 악성코드 제작자의 의지가 아닌 상태에서 만들어진 것이다. 만약 ??Toolbar가 매우 유명하고 대부분의 사람들이 사용한다면 모든 악성코드 제작자들은 이 폴더로 자신의 프로그램이 설치되도록 유도하게 될 것이고, 결국 ??Toolbar는 악성코드를 보호하는 프로그램이 되어 악성코드의 숙주가 된다.

루트킷의 종류

루트킷은 범용적으로 쓰이기 때문에 종류도 다양하다. 여기서 언급하는 루트킷의 종류는 필자가 개인적으로 나눈 것으로 절대적인 것이 아니라는 것을 먼저 밝힌다. 우선 루트킷의 전체를 볼 수 있도록, 어떤 루트킷이 있는지 알아보자. 루트킷이 동작하는 환경에 따라서 나누면, 운영체제 별로 루트킷이 존재한다. 윈도우에서 동작하는 루트킷만 살펴보면, 유저 모드 루트킷과 커널 모드 루트킷 그리고 그에 속하지 않는 루트킷(윈도우가 구동되기 전에 동작하는 루트킷)이 있다. 유저 모드와 커널 모드가 따로 있는 것은, 유저 모드에서 할 수 없는 일을 커널 모드에서 할 수 있는 경우가 많기 때문이다.

우리가 가장 많이 사용하는 CPU 인 인텔 호환 CPU는 명령어를 실행할 수 있는 권한을 가지고 있는데, ring0 부터 시작해서 ring1, ring2, ring3 까지, 4개의 ring 권한을 가진다. 윈도우의 경우 유저 모드에서는 ring 권한 중 가장 낮은 ring3 권한을 가지므로 CPU에 시스템 큰 영향을 줄만한 명령어를 실행할 수 없다. 하지만, 커널 모드에서는 ring0를 사용하므로 이를 위해 커널 모드 루트킷이 필요한 것이다. 또한, 생소하게 생각될 수도 있지만, 커널 모드도 유저 모드도 아닌, 루트킷이 있다. 이는 운영체제가 로드되기 전, 하드 디스크의 MBR(Master Boot Record)을 참조하게 되는데, MBR을 수정해 자신이 먼저 실행되도록 시스템을 수정하는 루트킷이다. 또한, 하드디스크가 아닌 비디오카드에 기생하는 루트킷도 존재한다.

이와 같이 다른 하드웨어에 존재하는 저장장치에 기생할 경우에 얻는 이점은 일반적으로 바이러스에 감염됐다고 판단해 하드디스크를 포맷하거나 운영체제를 재설치하는 경우가 많은데, 이러한 루트킷은 포맷과 재설치에도 불구하고 살아남는다는 특징이 있다.

루트킷은 누가 만드는가?

대체 루트킷은 누가 만드는 것일까? 실질적으로 많은 루트킷이 공개되고 배포되는 루트킷 닷컴(http://rootkit.com)에 가면 루트킷을 공개하는 사람들이 자신의 신원을 밝히고 자신의 결과물(RootKit)을 공개한다.

루트킷 자체는 ‘악성’이라기보다는 시스템 보안의 허점을 공개하는 하나의 도구이기 때문에, 그 자체가 나쁜 일은 아니기 때문이다. 물론 이를 악용하면 큰 문제를 일으킬 수 있겠지만, 아직까지 국제적인 제재는 없는 상황이다. 중국의 경우 실제로 크래킹 방법을 잡지에 기고하고 판매하는 경우도 있다. 국내 사정은 아직 먼 이야기지만. 몇 년 전 『해킹, 파괴의 광학』이라는 책이 매우 성황리에 팔렸던 적이 있다. 국내에서는 아직 이 책에 공개된 수준까지만 허용된다. 그렇다면 루트킷을 만들어서 공개하는 이들은 누구일까? 대부분 보안 프로그래머이다. 이 얘기가 다소 혼란스러울 수도 있을 것 같다. 어떻게 시스템을 파괴하기 위한 도구를 보안 프로그래머가 만들 수 있을까 하는 의문에 봉착한다. 이는 방패를 만들기 위해서는 창에 대해 잘 알아야 하고, 창을 잘 아는 사람만이 효과적인 방패를 만들 수 있는 이치와 같다. 하지만, 여기서 필자가 한 가지 명확하고 싶은 것은 루트킷을 만드는 사람과 악성코드를 만드는 사람을 확실하게 구분해야 한다는 것이다. 대부분의 악성코드 제작자는 시스템 자체에 대한 이해도가 높지 않다. 그들은 단지 루트킷을 사용하는 것뿐이다. 이러한 사람들을 스크립트 키디(Script-x Kiddie)라고 부른다. 이들은 시스템에 대한 탐구 의지보다는 과시욕이나 시스템을 파괴하려는 생각만 앞선 사람들이다.

루트킷 기술들

루트킷에서 나오는 기술은 무척 다양하다. 기술의 수준도 높은 반면에, 누구나 알만한 내용도 존재한다. 하지만 “아... 이렇게 역으로 생각할 수 도 있구나”라는 식의 역발상적인 기술이 많다. 필자 개인적으로는 한가한 시간에 여러 프로그래머나 해커의 사이트를 돌아다니면서 그들이 최근에 해온 일들을 훑어보는 습관이 있다. 루트킷에 대한 내용을 읽다 보면, 좀 더 창의적이고 기발한 생각을 떠올리도록 도와주는 경우가 있다.

가장 잘 알려진 기술인 후킹도 기술 자체는 이미 오래전에 알려졌지만(리눅스 등의 운영체제에서는 이렇게 후킹을 하는 것이 운영체제의 일부가 되있기도 하다), 루트킷을 잡아내고 복구(Restore)하는 기술이 발전함에 따라서 좀 더 지능적으로 진화해 왔다. 예를 들면, 백신 프로그램이 루트킷을 탐지해내려면 루트킷 프로그램의 연속된 특정 어셈블리 코드를 찾는 경우가 많다. 특히 <리스트 1>의 코드는 커널 모드에서 Write Protection 기능을 제거하기 위해 CR0 비트를 조작하는 코드이다. 하지만, 루트킷에 많이 쓰이면서부터, 백신 프로그램은 이 코드를 기준으로 루트킷을 탐지한다.

이러한 문제를 해결하기 위해, 안티-루트킷(Anti-RootKit) 프로그램이 특정 실행 코드(op code: 기계어)가 연속적으로 나오는 경우에만 검출해낼 수 있다는 허점을 노려, INC EAX, DEC EAX와 같이 의미 없는 코드로 코드의 흐름을 섞어 놓는 간단한 방법으로 백신의 검출망을 피해간 것이 바로 <리스트 2>의 코드이다. 이러한 의미 없는 코드는 매우 많다. <리스트 2>와 같이 어떤 일을 한 후에 다시 그 일을 되돌리는 명령을 사용하는 것도 있으며 JUMP 명령어를 사용해 이리저리 코드의 흐름을 어지럽히는 방법도 있다. 또한, 어셈블리에서는 아무것도 하지 않는 명령어로 NOP라는 명령어가 있는데, 이를 사용하는 경우도 있다. 이러한 것을 ‘Code Randomization 기법’이라고 하는데, 최근 루트킷에서 흔히 발견하는 간단한 트릭이다. 하지만, 최근에는 실행 코드 자체만 고민하던 해커들이 실행 코드보다는 코드가 사용하는 데이터에 집중하면서 DKOM (Direct Kernel Object Manipulation)이라는 기법이 새롭게 생겨났다. 이 기법은 실행 코드가 사용하는 데이터(프로세스 목록을 저장하기 위한 링크드 리스트 등)를 변경하여 자신을 감추는 방법 등으로 활용되고 있다. DKOM을 사용해 프로세스를 숨기는 방법을 간단히 설명하면 다음과 같다. 먼저, 윈도우에서는 Process 목록을 링크드 리스트를 사용하여 관리하게 되는데, 이 링크드 리스트의 각 항목들을 가지고 연결 고리를 조작하는 방법이다.

<그림 2>와 <그림 3>을 보면 <그림 2>에 있던 세 개의 프로세스가 연결된 상태에서 <그림 3>처럼 하나의 연결을 끊게 되면, 두 개의 프로세스만이 존재하는 것처럼 보인다. 이것이 바로 DKOM 기법을 사용하여 Process 목록을 숨기는 원리이다. DKOM은 매우 혁신적인 아이디어라고 할 수 있다. 왜냐하면, 이전의 루트킷이 실행 코드를 바꾸는데 전념했고, 그렇기 때문에 루트킷을 탐지해내는 방법으로 실행 코드를 확인하는 방법을 많이 사용했다. 루트킷이 아무리 똑똑해도, 언젠가는 메모리 어딘가에 자신을 실행해 달라는 흔적(보통 jmp 명령어나 자신의 코드가 있는 메모리 주소가 된다)을 남긴다. 하지만, DKOM 기법을 사용하면, 데이터 조작 여부를 판단하기가 매우 애매해진다.  이렇게 숨긴 Process를 알아채기 위한 방법은 Process 목록에서 자신을 지워버려도 언젠가 악성코드가 실행되려면 윈도우가 실행 코드 스케쥴을 하는 기반인 스레드(Thread) 목록에서는 지우지 않는 다는 것에 착안하여 검출해내는 방식을 사용한다.

필자는 2007년 10월, RootKit.com에 네이티브 애플리케이션이 루트킷으로 사용될 수 있다는 내용을 기고한 적이 있다. 비스타에서 기존 윈도우와 가장 많이 바뀐 내용이 UAC에 관련된 내용이며, 이것이 네이티브 애플리케이션을 통해 무력화 될 수 있다는 내용이었다. 최근에는 이런 식으로, 새롭게 생긴 정책의 논리적인 구멍(Hole)을 공격하는 경우가 늘고 있다. UAC에 관련된 유사한 예로, 윈도우 비스타의 정식 버전이 출시되기 전인 RC 버전에서는 윈도우의 Swap 기능을 역이용해, Swap out 된 가상 메모리의 내용을 조작하여 다시 그 코드가 Swap In 되어 실행 될 때 시스템의 권한을 가로채는 기발한 방법이 나오기도 했다. 물론 이 문제는 정식 버전이 나오기 전에 이미 수정됐다.

루트킷이 시사하는 것

루트킷이 시사하는 것은 이미 대부분의 사람들이 시스템의 허점을 이용할 준비가 돼 있다는 것이며, 이는 곧 우리가 불안한 디지털 세상을 살고 있다는 말이기도 하다. 더 이상, 크래킹은 많은 지식을 가진 고급 크래커들만의 몫이 아니다. 하지만, 대부분의 사람들이 운영체제가 잘못 설계됐기 때문이라고 오해한다. 물론 운영체제 자체의 문제도 있겠지만 새롭게 보안을 강화시킨 비스타에도 여전히 루트킷은 존재하며, 많은 사람들이 안전하다고 생각하는 유닉스와 리눅스조차도 수많은 루트킷이 존재한다.

필자는 이제 기술적인 문제에서 떠나야 한다고 생각한다. 보안 위협이 사회현상으로 부각되면서 여러 가지 법안이 제정됐지만, 충분한 생각과 고려 없이 제정된 법들은 루트킷의 악용을 규제하기 보다는 안티-루트킷 프로그램에 ‘인증’을 받으면 루트킷 기능을 이용할 수 있다는 새로운 ‘권력’ 을 생산해내기에 이르렀다. 세계적으로 많은 안티-루트킷(백신) 업체들이 있지만, 이들의 방식에도 문제가 많다.

특히, 루트킷을 진단하는 방법으로 실제 코드를 분석하는 방식을 사용하는데, 이에 대한 기준도 업체마다 달라 ‘오진’이 빈번하게 발생한다. ‘오진’의 대부분은 기술적이지 못한 사용자들에게 마치 바이러스인 것처럼 겁을 줘서 ‘오진’ 당한 업체에게는 명예 실추와 영업 손실을 끼친다. 이러한 구조로 인해 백신 소프트웨어를 만드는 업체들이 마치 프로그램 인증서를 발급하는 것과 같은 양상이 됐다. 지금은 오래된 이야기 이지만, ActiveX로 인한 악성코드 및 바이러스가 기승을 부리면서부터, ActiveX에는 인증서라는 것이 필수요소로 작용하게 되었다. 하지만, 인증서를 악성코드 제작자들이 자유롭게 취득하지 못하도록 가격이 책정돼 버렸다. 이로 인해 ActiveX를 사용해 웹 페이지에서 프로그램을 서비스하려면 인증서를 꼭 구입해야 한다. 인증서 가격은 가장 저렴한 방법으로 구매해도 1년에 25만원에 육박하는 적지 않은 가격이다. 이것은 과연 누구를 위한 것인가? 인증서를 구매한다고 해서 악성코드나 바이러스가 박멸되는 것일까? 전혀 그렇지 않다. 오히려 지금에 와서는 합법적으로 인증서를 구매해서 악성코드를 만드는 것이 당연시 되어 버렸다. 이러한 방식은 마치 벼룩을 잡기위해 초가삼간을 다 태우는 격이며, 앞으로 생길 새로운 보안 위협에 대해서는 이러한 새로운 권력을 창출해 내지는 말아야 한다고 생각한다.

반응형

Reverser's Page

woodmann.com
+Fravia 의 홈페이지 중 일부인 포럼공간이다. 전세계적으로 가장 유명한 곳이다. 포스팅 또한 상당히 전문적인 지식이 담겨있다. 제가 생각하기에 리버싱에 관련된 그리고 시스템의 깊은 곳을 이해하는데 최고의 사이트가 아닌가 합니다.
 
AntiCrack.de
+Fravia 의 포럼에 필적하는 곳이다. 주옥과 같은 자료들이 존재하니 꼭 들어가보시길 권해드린다. 포럼, protools, codebreak magazine, protools, reverse academy, crackme, daemon's hompage, APJ(assembly programming journal) 로 구성되어 있다.
oPEN rEVERSE fORUMS
이름 그대로 리버싱의 열린 공간이며 상당한 고수분들이 계신다.
BiW Reversing
상당히 유명한 Detten과 같은 리버서들이 있는 곳이다. 양질의 문서를 제공한다.
Reverse Engineering Team
그 유명한 CrackZ 와 같은 리버서들이 있는 곳이다.
 
UNPACKING GODS
이 홈피의 상위주소를 가보시면 Absolute Lock 의 홈피로 이어진다. vladmir, yates, NtSC, SAC 와 같은 시스템에 관한 고수들의 홈피이다.
W A S M . R U
러시아 사이트로 디버깅에 필요한 자료에 대한 업데이트가 뛰어나며, 양질의 문서를 제공한다.
www.exetools.com
너무도 유명한 자료실이다. 각종 툴 및 프로그램, 전자도서를 구할 수 있다. 크랙 튜토리얼도 있으나 크랙 자체에만 치중한 경향이 있어 그다지 좋은 자료라고는 생각하지 않는다.
http--crackz.reteam.org-
CrackZ 의 홈피이다. dongle와 FlexLM 과 같은 전문적인 프로텍터에 관한 독보적인 사이트이다.
SVKP's page
SVKP 상용 프로텍터의 홈페이지다. 해당 프로텍터를 광고하려는 건 절대 아니고, 좋은 글들이 있으니 anti-debug 에 관심 있으신 분들은 읽어보시기 바란다. 또한 개발자가 쓴 "cracking proof of your software" 라는 책도 굉장히 좋으니 구하셔서 읽어보시길.
__ULTRASCHALL__HOME__OF__THE__STARS__
DAEMON 의 홈페이지로 IA-32 Interrupt Mechanism을 이용한 여러 anti-debug 소스를 제공한다.
ka0s.net
PDA, celluar phone, Xbox 와 같은 모바일 콘솔에 대한 리버싱을 다루는 곳이다.
RW5jcnlwdGlvbiAmIEtleUdlbg==  
키젠으로 유명하신 x3chun 님의 홈피이며 직접 코딩한 여러 유명 암호 알고리즘에 관한 소스를 제공하고 있다.
 
Vivaman's page
비바맨님의 홈페이지다. 홈피를 방문해보면 전지현을 향한 그분의 마음을 알 수 있다 ㅋㅋ
Le4rN TO Cr4cK
크랙미를 미러링해주며 QnA 게시판을 제공하고 있다. 초기에 비해 수준이 낮아지고 있다. junk advice를 올리는 사람들 때문에 짜증나기도 하지만, 하루에 한번 꼭 들리는 곳이기도 한 곳이다.

      k3nny's web v2.0 - welcome!
      크랙도 세월에 따라 필요한 툴들이 달라지는 법인데, 케니는 무엇이 필요한 것인지 잘 아는 듯 하다. 정말 알짜 툴들만 모아놓았다.

http--kickme.to-mxbnet
실전 크랙을 보여주는 곳이다. 크랙을 막 시작하셨다면 이곳을 추천해드린다. 하지만 이분은 대략 간단명료하게 글을 쓰는 스탈이라서 스스로 도전해보실 분만 가보시길.
 
http--66.98.132.48-yates-
시스템에 대한 정보 및 IDT 와 관련된 정보의 디버깅 방법을 알려준다. 또한 Xbox와 같은 콘솔의 IDA용 sig를 공개하고 있다. 대단한 넘이다.
Stone's WebNote
유명 리버서의 홈피.
DataRescue
자타가 공인하는 최고의 디스어셈블러 IDA 의 홈페이지다.
The IDA Palace
유용한 IDA 플러그인 및 IDC 스크립트가 있다.
mammon_
윈도우즈와 리눅스 양쪽의 시스템을 두루 정통한 mammon의 홈페이지다.
Quine's IDA Page
바이너리 분석의 대가인 Quine의 홈페이지다.
      MackT
      impReconstructor로 유명한 UCF 팀의 MackT의 홈페이지
      The home of RTA
      그 유명한 squidge가 만든 RTA. 쓰는 사람 거의 못봤는데, 이거 굉장한 툴임엔 틀림없다.
 
 

Programmer's & Specific Topic

Assembly Language Journal --> 저의 착각이 있었습니다. APJ는 anticrack.de에서 새로운 둥지를 틀었으며 이슈가 발행되었습니다.
현재 더 이상의 이슈는 발행되지 않고 있으나 어셈에 관한 정수를 맛볼 수 있는 곳이다.
Hello, Coder !
ElicZ의 홈페이지로 그의 환상적인 소스를 제공한다. 아마 ElicZ만큼 깊은 곳을 아는 사람도 드물 것이다.
http--y0da.cjb.net-
y0da는 PE editor로 유명한 리버서이다. ElicZ 만큼은 아니지만 그또한 대단한 프로그래머다.
IceExt
Stenri 홈피로 소프트 아이스 플러그인, IceExt를 개발하고 있다.
Iczelion's Win32 Assembly Homepage
두말할 나위없는 어셈블리의 바이블과 같은 곳이다. MASM을 유지보수하는 공동개발자이기도 하다.
windows disassembler
Sang Cho 님의 홈페이지다. 한국분이시지만 사이트는 영어이다. +Fravia의 홈페이지에도 당당히 소개되고, 디스어셈블러를 개발하는 사람들에게 표준화된 소스와 instruction set을 제공해주신다. 정말 멋진 곳이다.
Jeremy Gordon's page
GoDebug 로 유명한 제레미 고든의 웹페이지. SEH 에 관한 글 및 정말 멋진 곳이다. 어셈을 배우기를 원하시는 분은 이곳을 꼭 가보시길.
 
Linkers and Loaders
COFF 타입의 링커와 로더에 대한 문서를 공개하고 있다.
데브피아 - IT 포탈 사이트
리버서에게 오픈 리버스 포럼이 있다면 프로그래머에겐 데브피아가 있다. 프로그래머들의 열린 공간이다. 어셈은 다루지 않는다 --;
환영합니다. 어셈블리 개발자 그룹 어셈러브(AsmLove)입니다
어셈블리어를 다루는 곳이다. 자료가 많기는 하지만 활성화 되었다고 보기는 어렵고, 주인장님과 유명한 minz님이 꾸려나가고 계시다.
한글 PHP Manual (2000-08-01)
제목 그대로.
Endi Co. Ltd.
디바이스 드라이버 관련 강좌를 제공하며 특히 VxD에 대한 강좌가 있다.
8051
8051 기판 조립에서부터 제어까지 관련자료를 제공하고 있다. 나처럼 컴공이나 전자공학과와 전혀 상관없는 사람이 8051을 처음 접할 때 유용한 사이트.
하제 소프트 - 윈도우즈 디바이스 드라이버 개발업체
보호모드와 같은 운영체제에 대한 전문적인 정보를 제공한다.
1년 후에도 내용이 살아있는 잡지
마소 잡지이다. 잡지를 사지 않더라도 웹에서 유용한 글을 읽을 수 있다.
29A Labs
국제적인 바이러스 잡지이다. 얼마전엔 모바일 바이러스를 만들어내기도 했다. 바이러스 잡지이긴 하나 소개되는 기술들은 상당히 실용적이다. 정말 보물과도 같은 소스코드들을 제공한다.
Welcome! (VX heavens)
바이러스 잡지의 대부. 그외의 유명 바이러스 매거진에 대한 아카이브를 제공.
 
Internals.com - The best online resource for system programmers
api monitor의 정석과 같은 API32를 개발하신 분의 홈피이다. 양질의 글과 유용한 툴을 제공한다.
Software Design - Windows Software by Gregory Braun
유용한 툴을 만들어 제공하고 있다.
dongle
동글 HASP에 대한 자료가 있다.
_♡신의키스♡_
HTML에 관한 독보적인 존재!
성미시리얼 방문을 환영합니다
정말 멋진 곳이다. 이곳에서는 전자회로, rs485 통신 및 pic 16 시리즈에 대한 자료를 제공하고 있다.
John the Ripper password cracker
유닉스 시스템의 해쉬에 대한 무차별대입공격 프로그램으로 유명한 곳. 모르는 분 없으시리라.
Obfuscated-HTML De-obfuscation Tools
웹소스의 암호화 복호화를 제공해준다. 상당히 유용하다.
Apache-Kr.org
아파치 웹서버에 대한 문서를 제공해준다.
데이터베이스를 사랑하는 사람들의 모임 데이터베이스 사랑넷
데이터베이스에 대한 방대한 문서를 제공. 머부터 봐야할 지 엄두가 안나는 곳.
 
+ 여리의 작업실 - www.zap.pe.kr +
이곳을 꼭 가보시길 권해드린다. 드라이버 프로그램을 하시는 분이신데 정말 대단하다는 생각밖에 들지 않는다. 굉장하다. 솔직히 부럽다 크~
 
Ntsc´s Homepage
링크한 문서인지 직접 작성한 문서인지 모르겠으나 암튼 괜찮은 곳이다. ANTI-BP, Xbox에 대한 자료를 제공한다.
illmob.org
여러 가지 자료를 제공.
암호의 세계
암호학에 대해 재미있게 소개하고 있는 곳이다.
 
MSDN Home Page
두말 할 나위없는 마이크로소프트웨어의 MSDN 홈페이지다.
Interrupt Mechanism and Application of Intel IA32 Architecture
anti-debug를 알고 싶은 사람이라면 이것을 꼭 이해해야 한다.
디버깅의 모든것, DebugLab.com
리버서가 아닌 프로그래머에게 필요한 디버깅에 대해 논하는 홈페이지다.
블록암호 알고리즘
굉장한 곳이다. 거의 모든 암호 알고리즘에 대한 소스와 설명, 소금줄과 같은 링크를 제공해준다.
CryptoClub
국내 암호관련 보안 동아리이다. 역시 대단한 곳이다.
Intel Pentium Instruction Set Reference (Basic Architecture Overview)
인텔 CPU의 명령어 셋을 온라인 상에서 제공하는 곳. 좋긴한데 뎁따 느리다. 누군가 미러링 좀 해줬으면.
Schneier.com
BlowFish 알고리즘을 개발하신 분의 홈피이다.
 
     동우의 HomePage - Welcome
     이동우님의 홈페이지. 주옥과 같은 자료의 링크를 제공해주심. 근자엔 리버싱과 관련된 문서를 공개하심. 웹페이지를 깔끔하게 만드는 방법을      아시는 분이다.
       
     sysinternalsl
     매우 유명하신 Mark Russinovich님과 어떤 분이 공동경영하시는 홈피이다. File Monitor 이외에도 시스템 관련한 보물과도 같은 자료들을 무료      로 공개해주는 곳이다. 얼마간의 소스와 양질의 문서또한 제공하고 있다.
     http://math88.com.ne.kr/crypto.htm
     정상조 님의 홈. 암호학에 관련해서 실제 DES가 어떻게 돌아가는지 단계별로 보여준다.
 
Networker's page
 
.[packet storm].
각종 버그리스트와 유용한 툴, exploit을 제공한다. 부연설명 없어도 워낙 유명한 곳이라서. 너무 실전에 치우쳐 있어 그다지 좋아하지 않는다. 그래도 어쩔 수 없이 들리게 되는 곳 --;
HACKER4U
승!님이 운영하시는 해킹 포탈 사이트이다. 역시 고수분들이 계신다. 버뜨. 자료는 별로없다.
KHDP.ORG Home Page
보안과 관련된 문서를 제공하는 곳이다. 양질의 문서가 많다.
KLDP.org
리눅스 관련 문서의 한글화 프로젝트를 하는 곳이다.
Hack This Site
웹해킹 워게임 사이트이다.
Korea Hacke.net
웹해킹 워게임 사이트. 웹해킹을 처음 해보신다면 이곳을 추천.
Nikto
웹상의 취약점 스캐너인 닉토를 win32용으로 포팅하신 분의 홈피이다.
 
Beist's page
웹해킹으로 유명하신 승진님의 홈피. 승진님은 자신의 노하우를 공개하는데 아낌이 없는 분이다.
 
wowhackers
양질의 문서를 제공.
seaofglass
유리바다님의 홈피이다. 지금은 바쁘신 듯. 이분은 여러분야게 관심이 많아 분류가 어렵다 ^^;
정보보호기술훈련장에 오신것을 환영합니다.
분석을 다루고 있다.
해커스랩 프리해킹존에 오신걸 환영합니다.
국내최초 워게임을 제공한 것으로 유명하다.
 
CULT OF THE DEAD COW
유명한 CDC의 홈피.
core-sdi
core-sdi 팀의 홈피이다. 총 4개의 멤버 페이지로 나뉘어지니 들어가보자. 그 중 하나는 잘 알려진 badcoded의 홈피이다.
phrack
프랙은 이슈화가 되었거나 그럴 만한 가치가 있는 기술들이 올라오는 곳이다. 예전에 우리나라 분도 '설마'라는 유틸로 글을 올렸던 기억이 난다. 프랙에 대한 설명은 굳이 드리지 않아도 잘 아실 것 같아 줄임.
 

 

Research 

ISI Web of Knowledge [v2.0]
저널 검색 사이트이다. 연구를 하는 사람이라면 당연히 들르게 되는 곳.
Sigma-Aldrich Home Page
전세계에서 가장 큰 시약판매회사이다. 에누리 해주는 법이 없다. 나쁜넘들.
THIC
내가 가장 가고 싶은 회사인 Lucent 그룹의 홈페이지다.
KOSEN 21
한국계 연구자들의 모임 사이트이다. 경험의 부족으로부터 나오는 궁금증이나 구하기 힘든 논문을 얻고 싶을 때 이용한다. 한국계 과학자들 중 현재 활발히 활동 중이신 30~40 분들이 많이 오시는 까닭에 전문적인 답변을 구할 수 있는 곳이다.

 

 

Oasis

###안녕하세요 김유식의 디시인사이드입니다!!!###
모르는 분 없으시길.
jonyTaro
잔잔한 카툰을 제공해주신다.
Red Hot Chili Peppers
그루브라는 단어를 연상케 하고 이해하게끔 만드는 그룹의 팬페이지.
인터넷의 시작 - 벅스
벅스없는 세상은 상상도 할 수 없다~~~
카툰 다간다
당신 이곳을 모르는가!
행복한 유머, 웃긴대학에 오셨습니다..
웃대. '웃자'가 무슨 뜻인지 아신다면 당신은 웃대인.
 
나비효과 - The Butterfly Effect
그룹사운드 '나비효과'의 홈피다. 첫사랑이란 노래는 정말 쵝오다.
 
CNN.com
전세계 최대의 뉴스기업.
강도영의 만화이야기
강풀순정만화로 유명하신 강도영 작가님 홈페이지. ㅋㅋ 라는 단어밖에 안나온다 ㅋㅋ
team5p
최고의 플래쉬 팀. 연예인지옥을 모르신다면 꼭 보시길.
레이싱걸들 사진
      이 여인네들은 어디서 왔단 말인가 쩝.
 

 

Search Engine

Google
최고의 검색엔진.
네이버
궁금한게 있을 땐 언제나 네이버에게.
네이트
최고의 메신저를 만들어 낸 곳. 난 라이코스 이메일을 사랑한다.
AltaVista  
Babel Fish
다양한 언어번역을 무료제공.
 
      Google
      해커전용 구글.
 

e-BOOK

Electronic books downloads
Food for Thought
computerbooks.web.com
FreeTechBooks - free online C-C++ programming books for beginners
Hacker Smiling Newbie Information Resource
Index of -files
BOOKS
The Hackers Playground

[출처] Reverser's Page |작성자 몽구스

반응형

사용자 삽입 이미지

PE라고 하는 윈도우 하에 실행되는 모든 실행파일의 헤더(프로그램이 실행될때 전체 프로그램 구조의 미니맵과 같은 역할을 하는 것을 PE라고 한다.) 를 읽어들여서 분석하고, 손상된 PE가 발견되었을경우 Rebuild해주는 막강한 기능을 가지고 있다.

반응형
 
사용자 삽입 이미지

UPX Shell 은 UPX 의 EXE 파일 버전입니다.

UPX Shell 은 EXE 나 DLL 과 같은 파일의 용량을 최대 90%까지 압축하며, 압축 해제도 가능합니다.

압축시 용량은 팍~ 줄어들고 실행 타임이 약 0.1초 늦어진다는 점을 감안하면 엄청난 압축 능력인거죠~

ㅎㅎ 이제 제 Portable 프로그램들이 완벽을 향해 달립니다~

+ Recent posts