KR101095815B1 - 소프트웨어 보안 장치 및 그 방법 - Google Patents

Abstract

소프트웨어 보안 장치 및 그 방법이 개시된다. 실행파일에서, 운영체제가 읽고 수행할 수 있는 명령어들의 집합을 정의하는 명령어 셋 영역은 완전히 암호화된 상태로 보안이 이루어진다. 프로세스 생성 과정을 통해 보안된 실행파일의 프로세스가 가상 메모리 영역으로 매핑되며, 실행파일이 암호화된 상태인 경우, 실행파일은 암호화된 상태 그대로 유지하면서 프로세스와 매핑된 가상 메모리 영역의 블록들이 복호화된다. 이후 복호화된 가상 메모리 영역의 블록들이 물리적 메모리로 로드됨에 따라 프로세스가 실행된다. 이러한 구성에 따르면, 소프트웨어 불법복제를 예방하고, 소프트웨어를 대상으로 한 바이러스, 악성코드로부터의 피해를 최소화하여 시스템의 안정성을 향상시킬 수 있다.

실행파일, 소프트웨어, 보안, 코드 섹션

Description

소프트웨어 보안 장치 및 그 방법{APPARATUS AND METHOD FOR SOFTWARE SECURITY}

본 발명은 소프트웨어 보안 장치 및 그 방법에 관한 것으로, 더욱 상세하게는 실행파일을 대상으로 한 소프트웨어 보안 장치 및 그 방법에 관한 것이다.

오늘날 컴퓨터 기술의 발전으로 여러 분야에 걸쳐서 셀 수 없이 많은 종류의 소프트웨어들이 사용되고 있다. 하나의 소프트웨어를 제작하기 위해서는, 많은 인력과 시간, 비용이 투자되어야 하고, 제작을 위한 기반 기술을 습득하고 연구하는 것에도 그 이상의 노력이 필요하다. 그러나, 어렵게 제작된 이러한 소프트웨어들은 소위 크랙(Crack)이라고 불리는 방법을 통해 무단 유통되는 경우가 많다.

그렇다면, 어떻게 이렇게 쉽게 크랙을 만들 수 있을까? 소프트웨어 개발 기업은 왜 그것을 막지 못할까? 여기에는 이유가 있으며, 그 이유를 이해하기 위해서는 먼저 소프트웨어의 구조를 알아야 한다.

소프트웨어는 하나 또는 여러 개의 실행파일로 이루어져 있으며, 각각의 실행파일은 곧 시스템이 인식할 수 있는 많은 수의 명령어들이 쓰여진 한 장의 긴 종 이로 비유할 수 있다.

도 1은 종래 기술에 따른 실행파일을 설명하기 위한 참조도이다.

실행파일에 쓰여진 모든 명령어들은 0과 1의 반복인 이진수로 이루어져 있으며, (a)와 같이 각각의 명령어들은 서로 다른 이진수 값과, 그에 따른 의미를 갖는다. 0과 1의 조합인 이러한 명령어들의 집합을 명령어 셋(Instruction Set)이라고 하며, 이는 대상이 되는 시스템의 프로세서, 즉 CPU(Central Processing Unit)에 따라서 조금씩 다를 수 있다. 프로세서 제작자는 자신들의 프로세서가 이해할 수 있는 명령어 셋을 시중에 공개하여 컴파일러 제작자로 하여금 자신들의 프로세서용 컴파일러를 설계할 수 있도록 한다.

소프트웨어 개발자들은 명령어 셋을 직접 파일에 작성하여 프로그래밍 하지 않는다. 만약 명령어 셋으로 직접 프로그램을 작성한다면 간단한 프로그램을 만드는 데에도 매우 많은 시간이 걸릴 정도로 비효율적이기 때문에, 개발자들은 C, C++, Java 등의 영문을 기반으로 한 고급언어를 사용하며, 특수한 번역기를 통해서 고급언어를 명령어 셋으로 변환한다. 이 번역기가 바로 컴파일러인 것이다. (b)는 컴파일러의 동작을 예시한 것이다.

이와 같은 과정으로 인해, 컴파일러 제작자는 컴파일러를 설계하기 위해 대상이 되는 프로세서의 모든 명령어 셋을 알아야만 하므로 어떠한 프로세서든지 프로세서 설계자는 명령어 셋을 세상에 공개해야 하고, 이렇게 공개된 명령어 셋은 소프트웨어 보안에 있어서 큰 문제를 안겨준다.

대부분의 소프트웨어 개발자들은 고급언어만을 사용하지만, 고급언어를 명령 어 셋으로 바꾸는 컴파일러 제작자가 있듯이, 명령어 셋을 읽고 작성할 수 있는 개발자들은 분명히 존재한다. 이러한 고급 개발자들은 큰 노력을 들여서 제작된 소프트웨어의 실행파일들을 열어서 읽고 이해할 수 있으며, 수정도 가할 수 있는 것이다. 더욱이, 오늘날에는 (c)와 같이 명령어 셋으로 이루어진 실행파일을 역으로 번역하여 고급언어로 출력해주는 프로그램까지 빈번하게 쓰이고 있으므로, 실행파일의 내용을 파악하는 것은 이제 소수 고급 개발자들만의 특별한 능력이 아니다.

소프트웨어의 제작과 실행의 근본적인 문제는 일반적으로 생각할 수 있는 것보다 더 많은 불이익을 가져다 준다. 개발자 또는 개발기업이 장시간에 걸쳐 쌓은 기술과 노하우는 결국 소프트웨어 실행파일의 코드로 표현이 되고, 이러한 코드들은 보호되지 않은 명령어 셋이므로 소중한 기술이 매우 쉽게 유출될 수 있다.

또한, 유료 소프트웨어를 구입하지 않고 공짜로 사용하기 위해서, 일부 개발자들은 소프트웨어 실행파일의 명령어 셋을 분석한 후, 그 중 사용자의 라이센스를 확인하는 코드를 수정하여 수정된 실행파일을 만들어 내거나, 또는 실행파일 내의 라이센스 번호를 확인하는 코드를 분석한 후, 그것을 기반으로 독립적인 라이센스 번호 생성 프로그램을 만들어 내고 이를 인터넷을 통해 유포하는 방법을 취한다. 이러한 개발자들을 크래커(Cracker), 그 행동을 크래킹(Cracking)이라고 하며, 이는 바로 소프트웨어 불법 복제의 직접적인 원인이 된다. (d)는 크래킹의 한 예이다.

소프트웨어 실행파일의 명령어 셋을 그대로 공개하는 현재의 방식은 운영체제의 안정성을 떨어뜨리는 바이러스, 악성코드가 등장하게 된 주원인이라고 할 수 있다. 하나의 운영체제는 많은 종류의 소프트웨어들의 집합체이며, 이 중 운영체제의 구동에 중추적인 역할을 하는 소프트웨어들 역시 명령어 셋의 모음인 실행파일들로 이루어져 있다. 보호되지 않는 명령어 셋의 취약점에 의해 운영체제를 구성하는 코드를 분석하는 것이 가능했고, 그 때문에 바이러스, 악성코드 등의 시스템에 직접적으로 유해한 프로그램이 만들어 질 수 있었던 것이다.

본 발명이 해결하고자 하는 기술적 과제는, 소프트웨어 불법복제로 인한 제작자의 불이익을 예방하고, 소프트웨어를 대상으로 한 바이러스, 악성코드로부터의 피해를 최소화하여 시스템의 안정성을 향상시키며, 나아가 사용자의 올바른 소프트웨어 사용을 유도할 수 있는 소프트웨어 보안 장치 및 그 방법을 제공하는 것이다.

본 발명이 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제로 제한되지 않으며, 언급되지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.

본 발명에 따른 소프트웨어 보안 장치는 실행파일의 프로세스를 가상 메모리 영역으로 매핑하는 프로세스 생성부; 상기 실행파일이 암호화된 상태인 경우, 상기 실행파일을 암호화된 상태 그대로 유지하면서 상기 프로세스와 매핑된 가상 메모리 영역의 블록들을 복호화하는 복호화 수행부; 상기 복호화된 가상 메모리 영역의 블록들을 물리적 메모리에 올려 상기 프로세스를 실행하는 프로세스 실행부를 포함한다.

본 발명에 따른 컴퓨터 판독가능 매체는 실행파일의 특성을 기술하여 운영체제가 상기 실행파일을 실행할 때 상기 기술된 특성을 이용할 수 있도록 하는 헤더 영역; 및 상기 운영체제가 읽고 수행할 수 있는 명령어들의 집합을 정의하되, 상기 명령어들의 집합을 암호화된 상태로 저장하는 명령어 셋 영역을 포함하는 실행파일을 저장한다.

본 발명에 따른 소프트웨어 보안 방법은 실행파일의 프로세스를 가상 메모리 영역으로 매핑하는 프로세스 생성 단계; 상기 실행파일이 암호화된 상태인 경우, 상기 실행파일을 암호화된 상태 그대로 유지하면서 상기 프로세스와 매핑된 가상 메모리 영역의 블록들을 복호화하는 복호화 수행 단계; 및 상기 복호화된 가상 메모리 영역의 블록들을 물리적 메모리에 올려 상기 프로세스를 실행하는 프로세스 실행 단계를 포함한다.

본 발명의 소프트웨어 보안 장치 및 그 방법에 따르면, 소프트웨어 불법복제로 인한 제작자의 불이익을 예방하고, 소프트웨어를 대상으로 한 바이러스, 악성코드로부터의 피해를 최소화하여 시스템의 안정성을 향상시키며, 나아가 사용자의 올바른 소프트웨어 사용을 유도할 수 있다.

이하에서는, 본 발명의 바람직한 실시예에 따른 소프트웨어 보안 장치 및 그 방법에 대하여 도 2 내지 도 7을 참조하여 상세히 설명한다.

도 2는 본 발명의 일 실시예에 따른 실행파일의 구성을 설명하기 위한 참조 도이다.

소프트웨어 보안 측면에서, 주로 문제가 되는 대상은 실행파일이다. 본 발명은 윈도우즈(Windows)를 비롯한 유닉스(Unix), 리눅스(Linux), 솔라리스(Solaris) 등의 모든 운영체제를 기반으로 한 실행파일에 적용 가능하다. 이하에서는, 편의상 PE(Portable Executable) 파일을 기준으로 일 실시예를 설명한다.

PE 파일은 윈도우즈를 기반으로 한 실행파일로서, 어플리케이션 프로그램을 구성하는 EXE, DLL, OBJ 파일과 디바이스 드라이버 파일인 SYS, DRV 등, 윈도우즈의 실행파일 로더(Loader)가 실행할 수 있는 코드를 가지는 모든 파일들을 포함한다.

PE 파일의 포맷을 보면 크게 앞쪽의 4KB(Kilobytes)에 해당하는 헤더(Header)와 나머지 부분인 여러 개의 섹션(Section)들로 나누어 질 수 있다. 헤더는 PE 파일의 종류에 상관없이 언제나 4KB의 크기를 가지며, 실행된 프로그램을 의미하는 프로세스의 정보(Process Info.)와 뒤쪽의 여러 섹션들의 정보(Section Info.)를 가지고 있어서, 시스템이 파일을 실행할 때 헤더를 이용하게 된다. 컴퓨터 파일에서 헤더는 파일의 본 내용에 앞서 맨 앞에 붙어 있어서, 내용의 길이라든가 파일의 다른 특성들을 기술하고 있는 필드이다.

헤더 뒤쪽에는 시스템이 읽고 수행할 수 있는 명령어들의 집합인 코드 섹션(Code Section)과, 프로그램 실행 시에 사용될 전역 데이터(Global Data), 정적 데이터(Static Data), 문자열(String)로 이루어진 데이터 섹션(Data Section), 아이콘(Icon), 이미지(Image), 버전(Version) 정보 등을 가지는 리소스 섹 션(Resource Section)이 순서대로 자리잡고 있다. 이러한 구조는 여타 다른 운영체제의 실행파일 구조와 크게 다르지 않다.

본 발명의 일 실시예에 따른 실행파일은 자신의 특성을 기술하여 시스템의 운영체제가 실행파일을 실행할 때 기술된 특성을 이용할 수 있도록 하는 헤더 영역과, 운영체제가 읽고 수행할 수 있는 명령어들의 집합을 정의하되, 명령어들의 집합을 암호화된 상태로 저장하는 명령어 셋 영역을 포함한다. 실행파일이 PE 파일인 일 실시예에서, 명령어 셋 영역은 코드 섹션이다.

즉, 본 발명의 일 실시예는 소프트웨어 보안의 취약점인 영역, 즉 명령어 셋을 가지고 있는 실행파일 내 코드 섹션의 내용을 공개하지 않는다. 여기서 코드 섹션의 내용을 공개하지 않는다는 것은 곧 코드 섹션을 완전히 암호화하는 것을 의미하며, 암호화는 DES(Data Encryption Standard), AES(Advanced Encryption Standard), SEED 등의 암호화 알고리즘을 통해 이루어질 수 있다.

코드 섹션의 내용을 숨기는 방법은 특정한 파일 암호화 알고리즘으로 국한되지 않는다. 예컨대, 암호화 되기 전과 후의 데이터 크기가 변화하지 않고, 64비트(Bits)의 키(Key)를 갖는 DES 알고리즘을 선택하여 코드 섹션을 암호화할 수 있다. PE 파일의 코드 섹션이 DES 알고리즘에 의해 암호화되면, 코드 섹션 내부의 명령어 셋을 읽을 수 없기 때문에 위에서 언급한 모든 보안 상의 문제점으로부터 안전해지게 된다. 취약점이었던 소프트웨어 실행파일의 명령어 셋이 암호화를 풀기 전까지는 그 내용을 알 수 없는 블랙박스(Black Box)가 되는 것이다.

도 3은 본 발명의 일 실시예에 따른 소프트웨어 보안 동작을 설명하기 위한 참조도이다. 도 3에서는, 실행파일이 PE 파일이고, 실행파일 로더가 소프트웨어 보안 장치로서 해당 동작을 수행하는 경우를 가정한다.

실행파일을 도 2와 같이 암호화하는 경우, 암호화된 명령어 셋이 보안상 안전한 반면, 프로세서가 그 의미를 받아들여 실행할 수 없는 치명적인 문제점을 가지게 된다. 따라서, 본 발명의 일 실시예는 암호화된 코드 섹션을 운영체제 상에서 안전한 방법으로 실행할 수 있도록 구성된다. 이러한 구성을 설명하기 위해서, 운영체제가 프로그램을 실행하는 과정을 먼저 설명한다.

대부분의 운영체제는 두 가지 이상의 프로그램을 동시에 실행시키기 위해서 멀티태스킹(Multitasking) 기술을 사용한다. 멀티태스킹의 사용으로 많은 수의 프로그램을 동시에 사용할 수 있게 되면서 주기억장치의 용량이 부족해지게 되었고, 이를 위해 가상 메모리(Virtual Memory)라는 개념이 등장하게 된다. 가상 메모리는 주기억장치의 용량보다 실행해야 할 프로그램의 양이 더 많아질 때, 당장 사용하지 않는 프로그램의 데이터 또는 코드를 보조기억장치로 옮겼다가 필요할 때 다시 주기억장치로 옮겨서 사용하는 방법을 말한다.

운영체제는 실행되고 있는 각각의 프로그램으로 하여금 크기가 큰 가상 메모리 영역을 마치 물리적 메모리(Physical Memory), 즉 주기억장치처럼 여기게 만들기 때문에, 소프트웨어 개발자는 물리적 메모리의 효율적 사용에 대한 문제에 대하여 생각할 필요가 없다.

32비트 운영체제는 4GB(Gigabytes), 64비트 운영체제는 1TB(Terabytes)의 가 상 메모리 영역을 제공하며, 프로그램의 코드를 실행하기 전, 프로세스를 생성할 때, 실행파일 전체를 가상 메모리의 일정한 영역으로 매핑(Mapping)한다. 매핑된 코드는 일정한 크기의 블록(Block)으로 나누어져 관리되며, 각각의 블록은 필요할 때마다 물리적 메모리에 독립적으로 로드(Load)되므로, 물리적 메모리 상에서 프로그램의 코드는 연속적이지 않다.

운영체제의 실행파일 로더가 하는 일은 크게 프로세스의 생성과 실행으로 나눌 수 있다. 프로세스에 가상 메모리 영역을 할당하고 가상 메모리에 실행파일을 매핑하는 등의 프로세스 생성 과정이 모두 끝나면, 실행파일 로더는 (a)와 같이 매핑된 코드 섹션의 가장 첫머리에 해당하는 블록부터 물리적 메모리에 올려 실행하게 된다. 본 발명의 일 실시예에 따라 암호화된 실행파일의 경우, 프로세스 생성 단계에서는 문제를 일으키지 않는다. 하지만, 프로세스 실행 단계에서는 매핑된 실행파일의 암호화된 코드 섹션의 일부가 실행되려고 할 때, (b)와 같이 프로세서가 암호화된 명령어 셋을 이해할 수 없으므로 오류를 일으키게 된다.

결국, 프로그램을 실행하기 위해서는 코드 섹션의 암호화를 풀어야만 하는데, 만약 실행을 위해 암호화를 푼다면 그것은 다시 처음으로 돌아가는 것을 의미한다. 프로그램의 실행 직전에 암호화를 풀고 실행이 끝난 후 다시 암호화한다고 하더라도, 프로그램이 실행되는 동안에는 실행파일의 암호화가 풀려 있어야만 하므로, 프로그램이 실행 중일 때 파일들을 복사해 놓으면 그만이다.

따라서, 본 발명의 일 실시예는 실행파일 상의 암호화를 계속 유지하면서 프로그램을 실행하게 된다. 이것은 운영체제 파일 매핑의 특성을 이용한 것이다. 일 반적인 파일의 경우에 매핑 후에 메모리 상의 내용을 변경하면 대상 파일에도 변경이 가해지게 된다. 그러나, 실행파일의 경우에는 가상 메모리 영역의 이미지를 변경하더라도 대상이 되는 원래 파일에는 변경이 가해지지 않는다.

이러한 특성은 실행파일을 보호하기 위한 운영체제 정책의 일부이다. 즉, 실행파일을 보호하기 위하여, 프로그램 내부에서 잘못된 코드에 의해 가상 메모리 상의 실행파일 이미지를 수정하더라도 이를 실제 파일에 반영하지 않는 것이다. 결국, 가상 메모리 상의 암호화된 코드 섹션을 암호화 하기 전으로 돌려놓는다고 하더라도 실행파일 상의 코드 섹션은 그대로 암호화된 상태로 유지된다.

실행파일 로더는 프로세스의 생성을 모두 끝마치고 프로세스의 실행 과정이 시작되기 직전에, 가상 메모리 상에 매핑된 코드 섹션의 암호화를 풀어주는 것으로 프로그램을 시작할 수 있다. (c)는 이러한 과정을 예시한 것이다. 암호화를 풀 때에는 파일을 읽고 쓰는 작업을 하지 않으므로, 사용자의 체감 시간은 고려의 대상이 아니게 된다. 코드 섹션의 암호화를 풀기 위해 필요한 키 데이터를 사용자에게 배포하고 입력 받는 과정에서는 라이센스 번호를 사용하거나 USB(Universal Serial Bus) 메모리, 네트워크를 이용한 방법 등 여러 가지 방법이 있을 수 있으며, 본 발명은 키 데이터의 배포와 사용자의 입력 방법을 특정한 한 가지로 국한하지 않는다.

도 4는 본 발명의 일 실시예에 따른 소프트웨어 보안 장치의 구성도이다.

도 4를 참조하면, 본 발명의 일 실시예에 따른 소프트웨어 보안 장치는 프로 세스 생성부(110), 복호화 수행부(120), 프로세스 실행부(130)를 포함하며, 암호화 수행부(100)를 추가로 포함할 수 있다.

암호화 수행부(100)는 실행파일을 암호화하기 위해 DES, AES, SEED 등의 암호화 알고리즘을 통해 명령어 셋 영역(예컨대, PE 파일의 코드 섹션)을 암호화한다.

프로세스 생성부(110)는 프로그램의 코드를 실행하기 전, 프로세스에 가상 메모리 영역을 할당하고 실행파일을 가상 메모리의 일정한 영역으로 매핑하는 등의 과정을 통해 프로세스를 생성한다.

복호화 수행부(120)는 실행파일이 암호화된 상태인 경우, 원래의 실행파일을 암호화된 상태 그대로 유지하면서 프로세스와 매핑된 가상 메모리 영역의 블록들을 복호화한다. 복호화 수행부(120)는 매핑 영역 보호부(121), 인증부(122), 복호화부(123)를 포함할 수 있다.

매핑 영역 보호부(121)는 실행파일이 보안된 프로그램인지 여부를 확인하고, 확인 결과 실행파일이 보안된 프로그램인 경우(예컨대, PE 파일의 코드 섹션이 암호화된 경우) 프로세스와 매핑된 가상 메모리 영역의 외부 접근을 차단한다. 인증부(122)는 실행파일이 최초 실행인지 여부를 판단하고, 판단 결과 실행파일이 최초 실행인 경우 인증 과정을 수행하여 인증이 통과되면 프로그램 관리데이터를 생성한다. 복호화부(123)는 실행파일이 실행된 적이 있어 해당 실행파일에 대한 프로그램 관리데이터가 이미 생성된 경우, 프로세스와 매핑된 가상 메모리 영역의 블록들(예컨대, 매핑된 암호화 코드 섹션의 블록들)을 복호화한다.

프로세스 생성 과정 및 복호화 과정이 모두 끝난 후, 프로세스 실행부(130)는 복호화된 가상 메모리 영역의 블록들(예컨대, 코드 섹션 블록들)을 물리적 메모리에 올려 해당 프로세스를 실행한다.

도 5는 본 발명의 일 실시예에 따른 소프트웨어 보안 방법의 흐름도이다. 도 5를 참조하여 실행파일 로더가 소프트웨어 보안 장치로서 동작하는 경우의 동작을 예시적으로 설명하면 다음과 같다.

실행파일 로더는 복수의 프로그램과 그 프로그램을 수행하는 많은 수의 프로세스들을 효율적으로 관리해야 한다. 또한, 본 발명의 일 실시예에 기반한 실행파일 로더는 추가적으로 라이센스 인증 과정과 실행파일 이미지 복호화 과정, 그리고 그에 따른 추가적인 데이터의 관리를 함께 해주어야만 한다. 여기서는 이해의 편의를 위해 실행파일 로더가 하나의 프로그램을 실행하는 과정에 대해서만 설명하기로 한다.

먼저, 실행파일은 명령어 셋 영역을 암호화하는 과정을 통해 암호화된 상태로 저장될 수 있다(S100).

S110은 실행파일의 프로세스를 가상 메모리 영역으로 매핑하는 프로세스 생성 단계이다. 사용자가 프로그램을 실행하게 되면 실행파일 로더에 프로그램 실행 요청이 들어오게 된다(S111). 실행파일 로더는 입력 받은 프로그램 실행 요청에 상응하여 프로세스에 가상 메모리 영역을 할당하고, 가상 메모리에 실행파일을 매핑하는 등 복호화 및 프로세스 실행 이전까지의 여러 과정을 모두 수행한 후(S112), 실행 요청된 프로그램이 보안된 프로그램인지, 아닌지 여부를 판단한다(S121).

S120은 실행파일이 암호화된 상태인 경우, 실행파일을 암호화된 상태 그대로 유지하면서 프로세스와 매핑된 가상 메모리 영역의 블록들을 복호화하는 복호화 수행 단계이다.

프로세스 생성 과정 이후, 실행파일 로더는 해당 실행파일이 보안된 프로그램인지 여부를 확인하고(S121), 확인 결과 실행파일이 보안된 프로그램인 경우 프로세스와 매핑된 가상 메모리 영역의 외부 접근을 차단한다(S122). 그리고, 실행파일이 최초 실행인지 여부를 판단하며(S123), 판단 결과 실행파일이 최초 실행인 경우, 인증 과정을 수행하여 인증이 통과되면 프로그램 관리데이터를 생성한다(S124). 실행파일이 실행된 적이 있어 프로그램 관리데이터가 이미 생성된 경우에는, 프로세스와 매핑된 가상 메모리 영역의 블록들에 대한 복호화가 이루어진다(S127).

실행 요청된 프로그램이 보안된 프로그램이 아닌 경우 실행파일 로더는 단순히 프로세스를 시작하고, 추가적인 관리를 하지 않는다(S128). 그러나, 보안된 프로그램이라면 먼저 외부로부터의 가상 메모리 접근을 차단시키고(S122), 대상 프로그램을 실행하는 다른 프로세스가 있는지 확인한다(S123). 이것은 프로그램의 최초 실행 시에만 인증과정을 하기 위한 방법으로서, 실행할 때마다 매번 인증과정을 거치지 않아 인증절차로 인해 야기 될 수 있는 사용자의 불편함을 최소화한다.

만약, 프로그램이 최초로 실행된 거라면 정해진 인증 과정을 수행하고(S124), 인증이 통과되면(S125) 실행파일 이미지의 복호화 전에 프로그램 관리데이터를 생성하게 된다(S126). 그러나, 이미 다른 프로세스들이 존재한다면 그것은 곧 이미 인증을 받았다는 뜻이므로, 인증 과정을 생략하고 가상 메모리 영역에서 실행파일 이미지의 암호화를 푼다(S127). 여기서, 프로그램 관리데이터는 실행파일 로더가 보안된 프로그램의 관리를 위해 커널 메모리(Kernel Memory) 상에 할당하는 작은 추가적 데이터 블록으로서, 프로그램을 실행하는 프로세스의 개수, 프로세스의 인증데이터 등을 가지고 있다.

S130은 복호화된 가상 메모리 영역의 블록들을 물리적 메모리에 올려 해당 프로세스를 실행한 후 사용자 요청에 따라 종료하는 프로세스 실행/종료 단계이다.

S120의 복호화 과정을 마치면, 실행파일 로더는 모든 준비를 끝마친 프로세스를 시작하게 되고, 사용자는 실행된 프로그램을 육안으로 확인할 수 있게 된다(S131). 사용자가 사용을 마치고 보안된 프로그램을 종료하면 실행파일 로더는 보안된 프로그램의 프로세스에 한하여 종료 요청을 받고(S132), 해당 프로세스가 실행파일의 마지막 프로세스인지 여부를 확인하게 된다(S133). 이때, 종료 요청을 받은 프로세스 이외에 해당 프로그램을 실행하는 다른 프로세스가 존재한다면 단순히 프로세스의 종료 작업을 수행한다(S135). 프로세스가 실행파일의 마지막 프로세스가 아니거나 프로그램 관리데이터가 이미 제거된 경우에도, 프로세스는 종료된다(S135). 이때, 종료 요청된 프로세스가 프로그램의 마지막 프로세스라면 더 이상 프로그램 관리데이터를 사용할 필요가 없으므로, 실행파일 로더가 프로그램 관리데이터를 커널 메모리에서 제거한 후(S134) 프로세스를 종료하게 된다(S135).

도 6은 본 발명의 다른 실시예에 따른 소프트웨어 보안 방법을 설명하기 위한 참조도이고, 도 7은 본 발명의 다른 실시예에 따른 소프트웨어 보안 방법의 흐름도이다.

본 발명의 실시예는 운영체제 실행파일 로더의 설계에 직접 적용하는 방법과, 운영체제의 내용을 변경하지 않고 실행파일 로더의 프로세스 생성, 실행 과정에 개입하는 특수한 모듈(Module)을 소프트웨어의 실행파일에 삽입하는 두 가지 방법으로 구현될 수 있다. 두 가지 방법 중 후자의 방법을 윈도우즈 NT 시스템에 적용하는 경우를 가정해 보자. 윈도우즈 NT의 실행파일 로더의 동작에 접근하기 위해서는 여러 가지 방법이 있을 수 있지만, 본 발명의 일 실시예에서는, 네이티브 API 후킹(Native Application Programming Interface Hooking) 기술을 사용한다.

API는 윈도우즈에서 개발자가 이를 이용하여 프로그램을 작성할 수 있도록 제공하는 함수들(Functions)의 집합체를 말하며, 크게 사용자 레벨(User Level)에서 사용할 수 있는 Win32 API와, 커널 레벨(Kernel Level)에서 사용할 수 있는 네이티브 API로 나누어진다. 이 중 실질적으로 프로세스의 생성 과정을 진행하는 함수가 구현된 시스템 파일의 내부에는 자신이 가지고 있는 모든 함수들에 대한 이름과 주소정보를 포함한 서비스 테이블(Service Table)이 존재한다.

이 서비스 테이블에 기록된 함수의 주소를 다른 함수의 주소로 변경하게 되면, 시스템은 테이블의 기록을 참조한 후, 변경된 주소의 함수를 원래의 함수 대신 호출하게 된다. 즉, 서비스 테이블에 기록된 프로세스 생성 함수의 주소를 새롭게 구현한 함수의 주소로 변경함으로써 실행파일 로더의 동작에 직접적으로 개입할 수 있는 것이다.

새롭게 구현한 프로세스 생성 함수 내에서는 먼저 변경되기 전의 프로세스 생성 함수를 호출함으로써 시스템으로 하여금 프로세스의 생성 과정을 마치게 하고, 시스템에 의해 가상 메모리 영역에 매핑된 실행파일의 코드 섹션을 암호화 해제한다. 이후, 외부의 다른 프로세스가 대상 프로세스의 가상 메모리에 접근하는 것을 방지하기 위하여, 프로세스 참조 객체(Process Reference Object)에 접근하여 프로세스 속성으로부터 가상 메모리 영역의 읽기, 쓰기 권한을 제거한다. 이 방법은 대부분의 안티바이러스(Anti-Virus) 프로그램이 프로세스를 보호하기 위해 사용하는 방법이다. 마지막으로, 변경했던 서비스 테이블의 주소 정보를 원래대로 복원해 놓는다.

구현이 끝난 모듈은 도 6의 (a)와 같이 암호화가 끝난 대상 소프트웨어의 실행파일 가장 앞쪽에 삽입하는 방식으로 이후에 사용자에 의해 실행될 수 있다. 실행파일 로더는 앞에서 설명한 PE 파일의 가장 앞쪽에 위치한 4KB 크기의 헤더에서 정보를 얻어서 프로세스를 생성한다. 그러므로, 실행파일의 앞쪽에 삽입한 모듈을 대신해서 실행하게 되며, 실행된 모듈은 자신의 뒤쪽에 위치한 대상 실행파일의 이미지를 사용하여 위와 같은 방법으로 프로세스 생성 작업에 개입하여 안전하게 프로그램을 실행할 수 있게 된다.

모듈의 동작을 도 7을 참조하여 순차적으로 설명하면 다음과 같다. 먼저, 사용자가 사용하고자 하는 프로그램을 실행할 때 모듈이 대신 실행된다는 것은 위에서 설명한 바와 같다(S210, S220). 실행된 모듈은 실행파일 로더의 동작에 개입하게 될 디바이스 드라이버를 내부에 포함하고 있으며, 이 디바이스 드라이버가 시스템에 설치되어 있는지 확인한 후(S230) 이미 설치되어 있다면 자신의 하단에 위치한 대상 실행파일을 독립적인 외부 파일로 기록하여 이미 재정의되어 동작하고 있는 실행파일 로더에 프로그램의 실행을 요청한다(S290).

만약 디바이스 드라이버가 설치되어 있지 않다면, 내부에 가지고 있는 디바이스 드라이버의 이미지를 외부 파일로 기록한 후(S240) 이를 시스템에 등록, 실행하여(S250) 커널 모드로 진입시킨다(S260). 커널 모드에서는 네이티브 API 서비스 테이블에 대한 접근권한이 주어지기 때문에 이를 수정할 수 있다(S270, S280).

그러므로, 모듈은 도 6의 (b)에 예시된 것처럼, 서비스 테이블에 기 등록되어 있는 프로세스 생성 함수(ZwCreateProcessE)의 주소를 재정의된 새로운 프로세스 생성 함수(NewCreateProcessE)의 주소로 변경할 수 있게 된다. 이러한 과정 후에는 실행파일 로더의 프로세스 생성 과정에 새로이 등록한 프로세스 생성 함수가 직접 개입하게 되므로, 운영체제의 커널 코드를 변경하는 작업을 하지 않고 실행파일 로더의 동작에 변화를 줄 수 있는 것이다. 모듈에 의해서 실행파일 로더에 프로그램의 실행 요청이 전달(S300)된 이후에는 도 5에서 언급한 S110 내지 S130 과정이 실행된다.
이와 같이, 본 발명은 소프트웨어 실행 방식에 관한 문제를 해결하는 새로운 개념의 프레임워크(Framework)로서, 운영체제를 기반으로 한 모든 소프트웨어를 구성하는 실행파일의 구조와 소프트웨어의 기본적인 제작, 실행 과정이 가지고 있는 본질적인 문제를 구조적으로 보완한다. 본 발명은 운영체제의 종류와 암호화 알고리즘의 선택, 키 데이터의 배포, 발명의 적용 방식에 따라서 여러 가지 형태로 응용될 수 있다.

삭제

이상 첨부된 도면을 참조하여 본 발명의 실시예를 설명하였지만, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자는 본 발명이 그 기술적 사상이나 필수적인 특징을 변경하지 않고서 다른 구체적인 형태로 실시될 수 있다는 것을 이해할 수 있을 것이다.

따라서, 이상에서 기술한 실시예들은 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 발명의 범주를 완전하게 알려주기 위해 제공되는 것이므로, 모든 면에서 예시적인 것이며 한정적이 아닌 것으로 이해해야만 하며, 본 발명은 청구항의 범주에 의해 정의될 뿐이다.

도 1은 종래 기술에 따른 실행파일을 설명하기 위한 참조도이다.

도 2는 본 발명의 일 실시예에 따른 실행파일의 구성을 설명하기 위한 참조도이다.

도 3은 본 발명의 일 실시예에 따른 소프트웨어 보안 동작을 설명하기 위한 참조도이다.

도 4는 본 발명의 일 실시예에 따른 소프트웨어 보안 장치의 구성도이다.

도 5는 본 발명의 일 실시예에 따른 소프트웨어 보안 방법의 흐름도이다.

도 6은 본 발명의 다른 실시예에 따른 소프트웨어 보안 방법을 설명하기 위한 참조도이다.

도 7은 본 발명의 다른 실시예에 따른 소프트웨어 보안 방법의 흐름도이다.

Claims (8)

1. 실행파일의 프로세스를 가상 메모리 영역으로 매핑하는 프로세스 생성부; 상기 실행파일이 암호화된 상태인 경우, 상기 실행파일을 암호화된 상태 그대로 유지하면서 상기 프로세스와 매핑된 가상 메모리 영역의 블록들을 복호화하되, 상기 프로세스와 매핑된 가상 메모리 영역의 외부 접근을 차단한 상태에서 복호화를 수행하는 복호화 수행부; 및 상기 복호화된 가상 메모리 영역의 블록들을 물리적 메모리에 올려 상기 프로세스를 실행하는 프로세스 실행부를 포함하되,

   상기 복호화 수행부는,

   상기 실행파일이 보안된 프로그램인지 여부를 확인하고, 확인 결과 상기 실행파일이 보안된 프로그램인 경우 상기 프로세스와 매핑된 가상 메모리 영역의 외부 접근을 차단하는 매핑 영역 보호부;

   상기 실행파일이 최초 실행인지 여부를 판단하고, 판단 결과 상기 실행파일이 최초 실행인 경우 인증 과정을 수행하여 인증이 통과되면 프로그램 관리데이터를 생성하는 인증부; 및

   상기 실행파일이 실행된 적이 있어 상기 프로그램 관리데이터가 이미 생성된 경우, 상기 프로세스와 매핑된 가상 메모리 영역의 블록들을 복호화하는 복호화부를 포함하는 소프트웨어 보안 장치.
2. 제1항에 있어서,

   상기 실행파일의 명령어 셋 영역을 암호화하는 암호화 수행부를 더 포함하는 소프트웨어 보안 장치.
3. 삭제
4. 삭제
5. 실행파일의 프로세스를 가상 메모리 영역으로 매핑하는 프로세스 생성 단계; 상기 실행파일이 암호화된 상태인 경우 상기 실행파일을 암호화된 상태 그대로 유지하면서 상기 프로세스와 매핑된 가상 메모리 영역의 블록들을 복호화하되, 상기 프로세스와 매핑된 가상 메모리 영역의 외부 접근을 차단한 상태에서 복호화를 수행하는 복호화 수행 단계; 및 상기 복호화된 가상 메모리 영역의 블록들을 물리적 메모리에 올려 상기 프로세스를 실행하는 프로세스 실행 단계를 포함하되,

   상기 복호화 수행 단계는,

   상기 실행파일이 보안된 프로그램인지 여부를 확인하는 단계;

   상기 실행파일이 보안된 프로그램인 경우 상기 프로세스와 매핑된 가상 메모리 영역의 외부 접근을 차단하는 단계;

   상기 실행파일이 최초 실행인지 여부를 판단하는 단계;

   상기 실행파일이 최초 실행인 경우, 인증 과정을 수행하여 인증이 통과되면 프로그램 관리데이터를 생성하는 단계; 및

   상기 실행파일이 실행된 적이 있어 상기 프로그램 관리데이터가 이미 생성된 경우, 상기 프로세스와 매핑된 가상 메모리 영역의 블록들을 복호화하는 단계를 포함하는 소프트웨어 보안 방법.
6. 제5항에 있어서,

   상기 실행파일의 명령어 셋 영역을 암호화하는 암호화 단계를 더 포함하는 소프트웨어 보안 방법.
7. 삭제
8. 제5항에 있어서, 상기 프로세스 실행 단계는,

   상기 프로세스를 시작하는 단계;

   상기 프로세스에 대한 프로세스 종료 요청을 입력 받는 단계;

   상기 프로세스가 상기 실행파일의 마지막 프로세스인 경우, 상기 실행파일에 대한 프로그램 관리데이터를 제거하는 단계; 및

   상기 프로세스가 상기 실행파일의 마지막 프로세스가 아니거나 상기 프로그램 관리데이터가 이미 제거된 경우, 상기 프로세스를 종료하는 단계를 포함하는 소프트웨어 보안 방법.

Images