바쁘실텐데 이렇게 도와주셔서 감사합니다.
먼저, 저희 프로젝트에 대해서 다시한번 차근 차근 설명해 드릴게요.

프로젝트 인원은 총 7명이고,
기간은 지난 10월 23일 부터 오는 1월 23일 까지입니다.
현재 발표일까지는 10일이 남아있습니다.

주제는 "소프트웨어 보안 솔루션"으로서 다음과 같은 그림을 갖습니다.

                              2. ( 개발사 )
                             +-----------+
                             | 인증 서버 |
                             +-----------+
1. ( 개발사 )                    |               3. ( 웹 )
   +-----------------+         |         +-----------------+
   | 1차 암호화 도구 |        |         | 2차 암호화 모듈 |
   +-----------------+         |         +-----------------+
            |                        ㅣ                   |
            |      4. ( 사용자 ) |                    |
            |       +--------------------+         |
            |       |  인증, 복호화 모듈 |         |
            +--> |----------------------|         |
                    | 암호화 실행 이미지| <----+
                    +--------------------+

[ 보안 시나리오 ]

1. 개발사에서 "1차 암호화 도구"를 사용하여 개발이 완료된 소프트웨어의
   실행파일을 암호화 합니다. 암호화 과정은 다음과 같습니다.
  
   a. 지정된 실행파일을 PE Header를 제외하고 암호화 합니다.
   b. 암호화 된 실행파일의 앞쪽에 "인증, 복호화 모듈"을 병합합니다.
      즉, 파일 하나가 2개의 실행 이미지를 포함하여 위쪽 그림의 4번과
      같은 형태를 띄게 됩니다.
  
   암호화 된 실행파일을 포함하여 개발사는 기존과 동일한 방식으로 소프
   트웨어를 패키지화하여 배포합니다.

2. 소프트웨어를 구입한 사용자는 설치과정을 거친 후, 실행을 시도 합니다.
   그림의 2번과 같은 형태를 가지는 실행파일을 실행하게 되면 시스템은
   아래쪽의 암호화 된 이미지를 실행하지 못하고, 위쪽의 "인증, 복호화
   모듈"(이하 "인증모듈")을 실행하게 됩니다. 그 이유는 아래 그림의 PE
   이미지 구조에 있습니다.

                  +-------------------------------------+
                  |  인증, 복호화 모듈의 PE Header |
                  |--------------------------------------|
                  |                      ...                       |
                  |=====================|
                  | 암호화 실행 이미지의 PE Header |
                  |---------------------------------------|
                  |                      ...                       |
                  +-------------------------------------+

   실행 파일을 소위 더블클릭하게 되면 시스템의 실행파일로더(Loader32)가
   파일을 매핑하게 되고 파일의 가장 앞쪽에 위치한 4K 바이트의 PE Header
   를 읽게 됩니다. PE Header에는 자신의 실행 파일 이미지에 대한 모든 정
   보가 기록되어 있고, 그 정보에는 파일상의 위치와 크기가 포함되므로 위
   와 같은 상황에서는 인증모듈만이 실행되는 것입니다.

   실행된 인증모듈은 인증 과정을 거치는데 문제가 있을 경우, 개발사의 웹
   사이트에 접속하게 됩니다. 접속된 웹사이트에서 사용자는 개발사가 제공
   하는인증 과정을 거치게 됩니다.

3. 웹사이트는 ".NET SmartClient" 기반의 "2차 모듈"을 실행합니다.
   실행된 2차모듈은 Serial을 가지고 1차 암호화 된 실행파일을
   한번 더 암호화 합니다.

4. 성공적인 인증 과정 이후, 사용자가 소프트웨어를 실행하게 되면 자동적으
   인증모듈이 실행되게 되고, 실행된 인증모듈은 우선 2차 암호화를 해제 합
   니다. 복호화 후에 얻은 Serial값 1차 암호화 된
   실행 이미지를 가지고 다음의 작업을 순서적으로 합니다.  
  
   a. 사용자 컴퓨터의 MAC Address를 알아내고, Serial을 이용해 DB의
      MAC Address값과 비교합니다. 값이 다를 경우, 실행을 중단 합니다.
   b. 위의 증 작업에 이상이 없으면 실행 이미지의  1차 암호화를 해제하고
      완전히 복호화 된 실행 이미지를 프로세스화하여 실행합니다.

[ 문제점 ]
프로젝트 진행의 가장 큰 문제점은 바로 위 글의 마지막 과정인 4의 b에 있습
니다. 바로, 실행된 인증 모듈과 같은 파일 내에 위치한 암호화 된 실행 이미
지를 보안에 아무런 문제없이 프로세스화 하는 것인데요. 다음의 그림으로 설
명이 가능합니다.

                                                        VAS (가상화 영역)
                   실행파일                          +-------------+ 2G
            +--------------------+                |                  |
            |  인증, 복호화 모듈 |   MMF       |                 |
            | -------------------- | ----------> | -------------|
            | 암호화 실행 이미지|                 | 실행 이미지 |
            +--------------------+ ----------> | ------------- |
                                                          |                   |
                                                          +------  -------+ 0

파일의 앞쪽에 위치한 인증모듈이 실행되어 뒤쪽의 암호화 된 실행 이미지를
가상화 영역에 매핑(MMF:Memory Mapped File) 하는 방법은 기본적으로 제공
되는 WIN32 API로서는 불가능한 일입니다. 실행파일을 프로세스화 해주는 함
수인 "CreateProcess()"는 인자로 파일의 경로를 받기 때문에 이와 같은 경우
에 앞쪽의 암호화 모듈이 다시 실행될 뿐입니다.

이 문제를 해결하기 위해 저희가 할 수 있는 것은 다음과 같습니다.

1. CreateProcess()의 내부 작동을 파악하고, 개입할 수 있는 부분을 찾아서
   수정을 가해 로더가 파일의 뒤쪽에 위치한 실행 이미지를 프로세스화 하게
   만듭니다.

2. NativeApihooking 사용(ReActOS)

3. CreateProcess()와 동일한 기능을 하지만 파일 경로가 아닌 실행 이미지의
   시작 주소로 동작하는 함수를 만듭니다.

위의 방안 중 3번은 저희가 할수 없는 영역으로 이미 간주하였고, 1,2번의 경우
는 다음의 시나리오를 생각하고 있으나 불확실한 요소가 많습니다.

1. 병합된 파일의 경로를 받아 CreateProcess()가 호출됩니다.
2. CreateProcess() 내부에서 실행파일을 매핑하기 위해 함수를 호출합니다.
3. 호출된 함수는 결국 File I/O를 위해 Device Driver에 IRP(I/O Request Pa
   cket)을 보내게 되고, 전송된 IRP를 중간에서 가로채기 위해 File Filter
   Driver를 작성하게 껴 넣게 됩니다.
4. File Filter Driver로 들어온 IRP의 내용을 분석하고 수정하여 매핑된 파
   일의 위치와 크기를 앞쪽의 인증 모듈에서 뒤쪽의 실행 이미지로 수정합니
   다.
5. 수정된 주소와 크기로 파일매핑이 이루어 지고, 자연스럽게 인증 모듈이 아
   닌 실행 이미지가 실행되게 됩니다.

[ 정리 ]
여기 까지가 저희 프로젝트가 가진 문제이며, 저희가 가진 지식이 너무나 협
소해서 File Filter Driver에 관한 시나리오가 현실적으로 구현 가능한 것인
지에 대한 확신 없이, 3명의 인원이 Device Driver를 공부하고 나머지 4명이
그 외의 것을 공부하고 있습니다. CreateProcess 의 FileMapping내부라도 자세히
알고 싶습니다.