KR101440646B1

KR101440646B1 - 컴퓨터 구현가능 방법, 및 소프트웨어 보안 향상 방법

Info

Publication number: KR101440646B1
Application number: KR1020097005677A
Authority: KR
Inventors: 베르트랑 안커트; 마리우츠 에이치. 자쿠보우스키; 라마라트남 벤카테사르
Original assignee: 마이크로소프트 코포레이션
Priority date: 2006-10-27
Filing date: 2007-10-16
Publication date: 2014-09-22
Also published as: BRPI0716471A2; WO2008115279A3; RU2458394C2; US20140068580A1; IL197361A0; JP2010508583A; MX2009003342A; TW200832179A; ES2675371T3; CN101529436A; EP2076863A4; NO20091281L; US8584109B2; NO344529B1; KR20090082176A; US9459893B2; AU2007349213A1; CA2662558C; JP5302202B2; US20080127125A1

Abstract

컴퓨터-구현가능 방법은 프로그램의 다양한 사본을 생성하는 기능들을 포함하는 명령어 세트 아키텍처를 제공하는 단계, 이 명령어 세트 아키텍처를 사용하여 프로그램의 다양한 사본을 생성하는 단계, 및 프로그램의 다양한 사본 중 하나를 실행하는 가상 기계를 제공하는 단계를 포함한다. 다양한 예시적인 방법, 장치, 시스템, 기타 등등은 코드 및/또는 가상 기계를 다양화함으로써 소프트웨어 보안을 향상시키기 위해 가상화(virtualization)를 사용한다.

명령어 세트 아키텍처, 가상화, 변조 방지, 가상 기계

Description

컴퓨터 구현가능 방법, 및 소프트웨어 보안 향상 방법{VIRTUALIZATION FOR DIVERSIFIED TAMPER RESISTANCE}

소프트웨어 개발자들의 엄청난 노력에도 불구하고, 소프트웨어 보호 메카니즘은 여전히 주기적으로 무너진다. 게다가, 한 사본에 대한 성공적인 공격은 종종 다른 사본들에 대해 자동적으로 반복될 수 있다. 예를 들어, 소프트웨어 제공자가 소프트웨어의 평가판을 배포하는 경우, 한 사본으로부터 시간 제한을 제거하는 크랙이 모든 다른 배포된 사본에도 적용될 수 있다. 또한, 종래의 배포 모델은 수천명의 사용자들에게 빠르게 영향을 주는 연속 공격을 가능하게 해줄 수 있다.

다양화(diversification)는 소프트웨어 보안을 향상시키고 공격을 복잡하게 만드는 데 사용될 수 있는 개념이다. 그렇지만, 다른 규칙들이 적용될 수 있기 때문에, 소프트웨어 보안을 위해 개발된 다양화 기법들이 항상 소프트웨어 보호로 이전가능한 것은 아니다. 예를 들어, 보안을 위해 도입된 런타임 다양화의 대부분은 공격자가 프로그램 및 실행 환경에 물리적 액세스를 할 때 쉽게 무력화될 수 있다.

본 명세서에 기술된 바와 같이, 소프트웨어 보호를 위한 여러가지 다양화 기법은, 예를 들어, 모든 사용자에게 서로 다른 사본을 제공하고 맞춤화된 업데이트로 방어 수단을 새롭게 변경함으로써 공간적으로도 시간적으로도 새롭게 변경가능한 방어 수단을 제공한다.

다양한 예시적인 기법들은 코드 및/또는 가상 기계(VM)를 다양화함으로써 소프트웨어 보안을 향상시키기 위해 가상화를 사용한다. 예를 들어, 컴퓨터-구현가능 방법은 프로그램의 다양한 사본을 생성하는 기능을 포함하는 명령어 세트 아키텍처(instruction set architecture, ISA)를 제공하는 단계, 이 명령어 세트 아키텍처를 사용하여 프로그램의 다양한 사본을 생성하는 단계, 및 프로그램의 다양한 사본 중 하나를 실행하는 VM을 제공하는 단계를 포함한다. 다양한 다른 예시적인 기술들도 개시되어 있다.

도 1은 커스텀/수정된 명령어 세트 아키텍처(ISA) 및/또는 가상 기계(VM)로서 가상화 계층을 포함하는 시스템 및 전체적인 아키텍처를 나타낸 도면.

도 2는 커스텀 코드 및/또는 커스텀 VM을 생성하는 보안 모듈을 포함하는 예시적인 방법의 블록도.

도 3은 커스텀 VM을 생성하는 예시적인 방법의 블록도.

도 4는 커스텀 코드를 생성하는 코드 내의 함수들을 다양화하는 예시적인 방법의 블록도.

도 5는 도 4의 방법과 관련된 일례를 나타낸 도면.

도 6은 데이터 및/또는 데이터 구조를 다양화하는 예시적인 방법의 블록도.

도 7은 다양화 및 변조 방지를 위해 사용될 수 있는 다양한 프레임워크 특성들을 나타낸 도면.

도 8은 다양화 및 변조 방지를 위해 사용될 수 있는 특성들을 갖는 실행 모델을 나타낸 도면.

도 9는 다양화 및 변조 방지를 위해 명령어 의미(instruction semantics)에 적용될 수 있는 다양한 방법들의 블록도.

도 10은 다양화 및 변조 방지를 위해 명령어 인코딩에 적용될 수 있는 다양한 방법들의 블록도.

도 11은 다양화 및 변조 방지를 위해 페치 사이클(fetch cycle)에 적용될 수 있는 다양한 방법들의 블록도.

도 12는 다양화를 위해 프로그램 카운터(PC) 및/또는 프로그램 표현에 적용될 수 있는 다양한 방법의 블록도.

도 13은 다양화된 변조 방지를 위한, 스플레이 트리 내의 코드 단편의 일례를 나타낸 도면.

도 14는 다양화를 위해 가상 기계(VM)의 구현에 적용될 수 있는 다양한 방법들의 블록도.

도 15는 예시적인 컴퓨팅 장치의 블록도.

첨부 도면을 참조하여 비제한적이고 비전수적인 예들에 대해 기술한다.

개요

예시적인 기법들은 제어될 수 있는(예를 들어, 특정의 방식으로 동작될 수 있는) 가상 기계 또는 다른 기계 상에서 실행되는 코드에 대해 소프트웨어-기반 보안을 사용한다. 다양한 예들은 보안을 향상시키기 위해 협동적 방식으로 코드를 수정하고, 데이터를 수정하며 및/또는 가상 기계 동작을 수정한다. 예를 들어, 코드 인스턴스들을 다양화하기 위해 코드와 연관된 특징들이 식별되어 사용될 수 있다. 다양한 예들은 기존의 아키텍처 또는 수정된 아키텍처의 상부에서 에뮬레이트되는 커스텀 또는 수정된 명령어 세트 아키텍처(ISA)의 사용을 포함한다. 기존의 아키텍처가 가상화 계층(예를 들어, 가상 기계 또는 런타임 엔진 또는 간단히 "런타임")을 포함하는 경우, 예시적인 방법은 기존의 가상화 계층의 상부에 다른 가상화 계층을 추가할 수 있다. 다양한 기법들의 구현은 하부의 가상 기계의 상부에서 동작하는 커스텀 가상 기계를 사용하여 또는 수정된 가상 기계(예를 들어, 하부의 가상 기계를 수정한 것)를 사용하여 행해질 수 있다. 성능을 희생시켜 보안을 향상시키기 위해, 가상 기계들의 스택을 생성하는 데 이러한 프로세스가 반복될 수 있으며, 각각의 가상 기계는 그 바로 아래의 기계의 명령어 세트를 가상화한다.

다양화와 관련해서는, 공통의 성분들(예를 들어, DNA 구성 블록들)이 다양한 방식으로 조립됨으로써 종의 다양성을 향상시키는 유전적 다양성과 유사할 수 있다. 이에 따라, 악성 에이전트(예를 들어, 바이러스)가 유전적으로 다양한 종의 모든 구성원에 영향을 줄 가능성은 없다. 또한, 수백개의 유전자가 혼합 및 정합되는 단백질을 생성하는 몇몇 기생충에 대해 유사점이 존재한다. 이러한 단백질 다양성은 이러한 기생충이 면역 체계 탐지를 피하는 데 도움을 준다. 그렇지만, 종에서의 유전적 다양성이 종종 표현형적 다양성(phenotypic diversity)(즉, 표현 또는 발현의 다양성)과 연관되어 있지만, 본 명세서에 기술된 바와 같이, 코드 다 양화가 사용자의 경험을 변경시켜서는 안된다. 환언하면, 동일한 입력이 주어진 경우, 다양화된 모든 코드 인스턴스들이 실행되어 동일한 결과를 생성해야만 한다.

이하의 일반화된 식을 생각해보자.

유전자형(genotype) + 환경 = 표현형(phenotype)

코드/데이터 + 기계 = 결과

수학식 (2)에서, 다양한 코드 및/또는 데이터가 있는 경우, 기계는 결과가 거의 동일하도록 보장해주는 커스텀 기계나, 수정된 또는 제어된 기계일 수 있다. 하나의 가상 기계 또는 여러 가상 기계들이 사용되는 경우, 하부의 하드웨어 및/또는 운영 체제는 일반적으로 본 명세서에 기술된 예시적인 보안 방법들에 의해 영향을 받지 않지만, 유의할 점은 이러한 방법들이 계산 요구를 증가시킬 수 있다는 것이다.

본 명세서에 기술된 바와 같이, 코드 다양화는 공격을 복잡하게 만듦으로써 보안을 향상시킨다. 그에 부가하여, 한 코드 인스턴스에 대한 성공적인 공격의 반복이 "유전적으로" 상이한 코드 인스턴스에는 성공할 가능성이 없기 때문에, 코드 다양성은 연속 공격을 곤란하게 만들 수 있다. 게다가, 보안을 향상시키기 위해 데이터(또는 데이터 구조)가 다양화될 수 있다. 또한, 코드 및/또는 데이터 다양화를 사용하여 또는 이를 사용하지 않고 보안을 향상시키기 위해 커스텀 또는 수정된 가상 기계를 다양화하는 예시적인 기법들이 사용될 수 있다.

다양한 예들이 MSIL 바이너리로부터 개별화된 바이트코드를 생성하는 것에 주안점을 두고 있지만, 임의의 프로그래밍 언어, 중간 언어, 바이트 코드 또는 방식으로 표현된 프로그램에 대해 다양한 예시적인 기법들이 사용될 수 있다.

본 명세서에 기술된 바와 같이, 가상화 프로세스(예를 들어, 가상 기계 또는 가상 환경에서의 코드의 실행)는 (i) 프로그램의 많은 서로 다른 버전들을 만드는 것 및 (ii) 모든 프로그램 인스턴스를 공격에 견디도록 만드는 것을 용이하게 해준다. 다양한 예시적인 기법들은 가상화를 사용하여 이식가능한 검증가능 관리 CLR(managed CLR) 환경의 상부에서 커스텀 ISA(Instruction Set Architecture)를 에뮬레이트한다. 커스텀 ISA를 에뮬레이트하는 데 커스텀 런타임 또는 수정된 런타임이 사용될 수 있다, 즉 어떤 방식에서, 하부의 런타임이 커스텀 ISA를 통해 도입된 다양성을 관리할 수 있어야만 한다.

가상화는 다양화에서 사용될 수 있는 자유도를 제공한다. 예를 들어, ISA(예를 들어, 및/또는 마이크로아키텍처)는 통상적으로 (1) 명령어 의미, (2) 명령어 인코딩, (3) 연산 코드(opcode) 인코딩, (4) 코드 표현 및 프로그램 카운터, 그리고 (5) 가상 기계의 대응하는 내부 구현을 포함한다. 이들 자유도가 주어진 경우, 다양한 예시적인 방법들은 각종 보호 메카니즘들 중 임의의 것을 사용하여 프로그램의 많은 다양한 사본들을 생성할 수 있다.

ISA와 연관된 자유도는 변조-방지 프로그램의 설계 및 선택을 제공한다. 예를 들어, 변조 방지는 (1) (a) 가변적인 명령어 길이, (b) 제한된 명령어 세트, (c)물리적 중첩 및 (d) 의미적 중첩의 권장을 통해 지역적 수정(local modification)을 아주 어렵게 만드는 것, (2) 상기한 것들 모두 및 코드, 데이터 및 주소 간의 경계를 모호하게 하는 것에 의해 전역적 수정(global modification)을 아주 어렵게 만드는 것, (3) 명령어 의미를 가변적으로 만드는 것, 및 (4) 계속하여 코드를 재배치하는 것의 결과일 수 있다.

보다 구체적인 예로는, (i) 작은 명령어들의 조합을 통해 명령어를 작성함으로써 명령어 의미를 랜덤화하는 것, (ii) 증가된 의미 중첩을 가능하게 해주도록 명령어 의미를 선택하는 것, (iii) 종래의 선형 코드 표현으로부터 벗어나 코드를 자기-적응(스플레이) 이진 트리 등의 데이터 구조로 표현하는 것, (iv) 역어셈블링(disassembly)를 복잡하게 하고 지역적 수정을 더 어렵게 만들기 위해 연산 코드(opcode) 및 피연산자에 가변 길이를 할당하는 것, (v) 공격자에게 코드를 분석 및 수정하는 옵션을 더 적게 제공하도록 명령어 세트를 제한하는 것, 및 (vi) 비트 패턴, 연산 코드 및 피연산자 간의 매핑을 가변적으로 만드는 것이 있다. 이들 예 중 어떤 것들에 대해 이하에서 더 상세히 설명한다. 이 상세한 설명은 현재 생각되는 최상의 실시 형태를 포함한다.

여러가지 상세를 설명하기 전에, 상황 설명을 위해, 도 1은 가상화를 포함하는 일반 시스템(100) 및 아키텍처(105)를 나타낸 것이다. 아키텍처(105)는 또한 커스텀 및/또는 수정된 ISA 및/또는 가상 기계를 CLR(common language runtime, 공용 언어 런타임)이라고 하는 가상 기계와 관련하여 나타낸 것이다. 도 1의 CLR은, 예를 들어, 각종의 객체-지향 프로그래밍 언어(OOPL) 중 임의의 것으로부터 도출된 중간 언어 코드를 처리할 수 있는 CLR이다(따라서, 용어 "공용"을 사용함). 도 1 이 .NET™ 프레임워크(미국 워싱턴주 레드몬드 소재의 마이크로소프트사)와 관련하여 논의되고 있지만, 다른 아키텍처들에서 예시적인 기법들이 사용될 수 있다.

시스템(100)은 네트워크(103)를 통해 통신하고 있는 다양한 컴퓨팅 장치(101, 101', 102, 102')를 포함하고 있다. 장치(101, 101')는 클라이언트(예를 들어, PC, 워크스테이션, 경량급 장치, 스마트 장치, 기타)일 수 있는 반면, 장치(102, 102')는 서버이다. 아키텍처(105)는 장치(101), 서버(102') 및 네트워크(103)와 어떤 링크를 갖는 것으로 도시되어 있다.

.NET™ 프레임워크는 2개의 주요 컴포넌트, 즉 CLR(common language runtime) 및 .NET™ 프레임워크 클래스 라이브러리를 갖는다. 이들은 관리 애플리케이션(managed application)과 연관되어 있는 것으로 도시되어 있다. CLR은 .NET™ 프레임워크를 기반으로 하는 가상 기계(VM)이다. CLR은 실행 시에 코드를 관리하는 에이전트로서 기능하여, 메모리 관리, 쓰레드 관리, 및 리모팅(remoting) 등의 핵심 서비스를 제공하면서도, 보안 및 안정성을 증진시키는 엄격한 타입 안전성 및 기타 형태의 코드 정확성을 시행한다. 코드 관리의 개념은 CLR의 근본 원리이다. CLR을 목표로 하는 코드는 관리 코드(managed code)라고 하는 반면, 런타임을 목표로 하지 않는 코드는 비관리 코드(unmanaged code)(아키텍처의 우측 절반)라고 한다.

.NET™ 프레임워크에서, 프로그램들은 CLR에 의해 제공되는 관리 실행 환경 내에서 실행된다. CLR은 프로그램들 간의 런타임 상호작용성, 이식성, 보안, 개발 단순성, 언어간 통합을 크게 향상시키며, 풍부한 일련의 클래스 라이브러리에 대한 우수한 기초를 제공한다. .NET™ 프레임워크 CLR을 목표로 하는 각각의 언어는 소스 코드를 컴파일하고 메타데이터 및 MSIL(Microsoft

Intermediate Language) 코드를 생성한다. 다양한 예들이 MSIL을 언급하고 있지만, 다른 언어 코드에서 여러가지 예시적인 보안 기법들이 사용될 수 있다. 예를 들어, 대부분의 하위-레벨 어셈블러-스타일 언어(예를 들어, 임의의 중간 언어(IL) 코드)에서 여러가지 기법들이 사용될 수 있다. JAVA™ 프레임워크(미국 캘리포니아주 서니베일 소재의 선 마이크로시스템)의 바이트코드 등의 바이트코드에서 여러가지 기법들이 사용될 수 있다.

.NET™ 프레임워크에서, 프로그램 코드는 통상적으로 "메타데이터"(즉, 데이터에 관한 데이터)라고 하는 정보를 포함하고 있다. 메타데이터는, 각각의 함수의 실제 구현 이외에, 종종 그의 타입들 모두를 비롯한 프로그램에 대한 명세 전체를 포함한다. 이들 구현은 프로그램의 명령어에 대해 설명하는 기계-독립적인 코드인 MSIL로서 저장되어 있다. CLR은 이 "청사진"을 사용하여 런타임 시에 .NET™ 프로그램에 생명을 줌으로써, 코드를 어셈블리어로 직접 컴파일하는 것에 의존하는 종래의 방법으로 가능한 것보다 훨씬 나은 서비스를 제공할 수 있다.

.NET™ 프레임워크의 또하나의 주요 컴포넌트인 클래스 라이브러리는 종래의 명령줄 또는 그래픽 사용자 인터페이스(GUI) 애플리케이션부터 ASP.NET에 의해 제공되는 최신의 기술 혁신에 기초한 애플리케이션(Web Forms 및 XML Web services 등)에 이르는 애플리케이션을 개발하기 위한 포괄적인 객체-지향 재사용가능 타입들의 모음이다.

CLR이 아키텍처(105)의 관리 애플리케이션 쪽에 나타내어져 있지만, .NET™ 프레임워크는 비관리 컴포넌트(unmanaged component)에 의해 호스팅될 수 있으며, 이 비관리 컴포넌트는 CLR을 그의 프로세스에 로드하고 관리 코드의 실행을 개시함으로써 관리 측면 및 비관리 측면 둘다를 이용할 수 있는 소프트웨어 환경을 생성한다. .NET™ 프레임워크는 몇개의 런타임 호스트를 제공할 뿐만 아니라 제3자 런타임 호스트의 개발도 지원한다.

예를 들어, ASP.NET은 관리 코드에 대한 확장가능 서버측 환경을 제공하기 위해 런타임(RT)을 호스팅한다. ASP.NET은 ASP.NET 애플리케이션 및 XML 웹 서비스를 가능하게 해주기 위해 런타임에 직접 작용한다.

인터넷 익스플로러

브라우저 애플리케이션(마이크로소프트사)은 런타임(예를 들어, MIME 타입 확장자의 형태로 되어 있음)을 호스팅하는 비관리 애플리케이션의 일례이다. 런타임을 호스팅하는 인터넷 익스플로러

소프트웨어를 사용하면 사용자가 관리 컴포넌트 또는 Windows Forms 컨트롤을 HTML 문서에 임베딩할 수 있게 된다. 이와 같이 런타임을 호스팅하는 것은 관리 모바일 코드(managed mobile code)(Microsoft

ActiveX

컨트롤과 유사함)를 가능하게 해주지만, 약간 신뢰되는 실행(semi-trusted execution) 및 격리된 파일 저장 등의 관리 코드만이 제공할 수 있는 상당한 개선을 갖는다.

본 명세서에 기술된 바와 같이, 관리 코드는 런타임(예를 들어, 가상 기계, 런타임 엔진, 기타, 여기서 런타임은 하드웨어(HW)의 제어와 통상적으로 직접 연관 되어 있는 하부의 운영 체제(OS)와 인터페이스함)을 목표로 하는 어느 코드라도 될 수 있다. .NET™ 프레임워크에서, 관리 코드는 CLR을 목표로 하며 통상적으로 "그 자체에 대해 기술하는" 메타데이터라고 하는 추가의 정보를 포함한다. 관리 코드 및 비관리 코드 둘다가 CLR에서 실행될 수 있지만, 관리 코드는 CLR이, 예를 들어, 안전한 실행 및 상호 운용성을 보장해줄 수 있게 해주는 정보를 포함한다.

관리 코드에 부가하여, 관리 데이터(managed data)도 .NET™ 프레임워크의 아키텍처에 존재한다. 어떤 .NET™ 언어(예를 들어, C#, Visual Basic.NET, JScript.NET)는 기본적으로 관리 데이터를 사용하는 반면, 다른 언어들은(예를 들어, C++) 그렇지 않다. 관리 코드 및 비관리 코드에서와 같이, .NET™ 애플리케이션에서 관리 데이터 및 비관리 데이터 둘다를 사용하는 것이 가능하다(예를 들어, 가비지 컬렉션되지 않고 그 대신에 비관리 코드에 의해 관리되는 데이터).

프로그램 또는 코드는 통상적으로 이식가능한 실행가능 파일(portable executable file)(예를 들어, "PE")로서 배포된다. .NET™ PE에서, PE 래퍼 내의 첫번째 데이터 블록은 MSIL로서, 앞서 언급한 바와 같이, 대체로 저수준 어셈블러 언어 코드처럼 보인다. MSIL은 관례적으로 .NET™ 프레임워크에서 컴파일되고 실행되는 것이다. PE에서의 두번째 데이터 블록은 관례적으로 메타데이터로서 PE의 내용(예를 들어, 어떤 메서드를 제공하는지, 어떤 파라미터를 받는지, 무엇을 반환하는지)에 대해 기술하고 있다. 세번째 데이터 블록은 매니페스트(manifest)라고 하는 것으로서, 관례적으로 실행 파일이 실행되기 위해 어떤 다른 컴포넌트를 필요로 하는지를 기술하고 있다. 매니페스트는 또한 외부 컴포넌트의 공개키를 포함할 수 있으며, 그에 따라 CLR은 외부 컴포넌트가 적절히 식별되도록 해줄 수 있다(즉, 실행 파일에 의해 요구되는 컴포넌트).

실행 파일을 실행할 때, .NET™ CLR은 JIT(Just-In-Time) 컴파일을 사용할 수 있다. JIT 컴파일에 의해 모든 관리 코드는 그가 실행되고 있는 시스템(OS/HW)의 네이티브 기계어(native machine language)로 실행될 수 있게 된다. JIT에 따르면, 실행 파일 내의 각각의 메서드가 호출될 때, 그 메서드가 네이티브 코드로 컴파일되고, 구성에 따라, 동일한 메서드에 대한 차후의 호출이 반드시 동일한 컴파일을 거칠 필요가 없으며, 이는 오버헤드를 감소시킬 수 있다(즉, 오버헤드가 메서드 호출마다 한번씩만 발생함). CLR이 많은 표준의 런타임 서비스를 제공하지만, 관리 코드는 결코 인터프리트되지 않는다. 한편, 메모리 관리자는 단편화된 메모리의 가능성을 없애주고 메모리 참조 지역성(locality-of-reference)을 향상시켜 성능을 더욱 향상시킨다.

다시 아키텍처(105)를 참조하면, CLR과 클래스 라이브러리의 관계가 애플리케이션 및 전체 시스템(예를 들어, 시스템(100))과 관련하여 나타내어져 있으며, 관리 코드가 대규모 아키텍처 내에서 어떻게 동작하는지를 나타내고 있다.

CLR은 메모리, 쓰레드 실행, 코드 실행, 코드 안전성 검증, 컴파일, 및 기타 시스템 서비스를 관리한다. 이들 특징은 CLR 상에서 실행되는 관리 코드에 본질적인 것이다.

보안과 관련하여, 관리 컴포넌트는 그의 출처(인터넷, 전사적 네트워크, 또는 로컬 컴퓨터 등)를 포함하는 다수의 인자들에 따라 다양한 정도의 신뢰를 받을 수 있다. 이것은 관리 컴포넌트가 동일한 활성 애플리케이션에서 사용되고 있을지라도 파일-액세스 동작, 레지스트리-액세스 동작, 또는 기타 민감한 기능을 수행할 수 있거나 수행할 수 없을 수도 있다는 것을 의미한다.

CLR은 코드 액세스 보안을 시행할 수 있다. 예를 들어, 사용자는 웹 페이지에 임베딩된 실행 파일이 스크린 상에 애니메이션을 플레이할 수 있거나 노래를 부를 수 있지만 그의 개인 데이터, 파일 시스템 또는 네트워크에 액세스할 수 없다고 확신할 수 있다. 따라서, CLR의 보안 특징에 의해 적법한 인터넷-배포된 소프트웨어는 기능이 대단히 풍부할 수 있게 된다.

CLR은 또한 CTS(common type system)라고 하는 엄격한 타입 및 코드 검증 인프라를 구현함으로써 코드 안정성을 시행할 수 있다. CTS는 모든 관리 코드가 자기 설명적(self-describing)이도록 해준다. 관리 코드는 타입 충실성(type fidelity) 및 타입 안전성(type safety)을 엄격히 시행하면서 다른 관리 타입 및 인스턴스를 소비할 수 있다.

CLR의 관리 환경은 많은 통상의 소프트웨어 문제를 제거하는 것을 목표로 한다. 예를 들어, CLR은 객체 레이아웃(object layout)을 자동적으로 처리하고 객체에 대한 참조를 관리하여, 객체가 더 이상 사용되지 않는 경우 그 객체를 해방(release)시킬 수 있다. 이러한 자동 메모리 관리는 2가지 가장 흔한 애플리케이션 에러, 메모리 누수(memory leak) 및 유효하지 않은 메모리 참조를 해결한다. 관리 코드와 비관리 코드 간의 상호 운용성에 의해 개발자는 필요한 COM(component object model) 컴포넌트 및 dll(dynamic-link library)를 계속 사용할 수 있게 된 다.

.NET™ 프레임워크 CLR은 Microsoft

SQL Server™ 및 IIS(Internet Information Service) 등의 고성능의 서버측 애플리케이션에 의해 호스팅될 수 있다. 이 인프라는 런타임 호스팅을 지원하는 전사적 서버를 여전히 사용하면서 비지니스 로직을 작성하는 데 관리 코드를 사용할 수 있게 해준다.

관리 도메인 내의 서버측 애플리케이션은 런타임 호스트를 통해 구현된다. 비관리 애플리케이션은 CLR을 호스팅하며, 이 CLR은 커스텀 관리 코드가 서버의 거동을 제어할 수 있게 해준다. 이러한 모델은 호스트 서버의 성능 및 확장성을 획득하면서 CLR 및 클래스 라이브러리의 특징들을 제공한다.

앞서 언급한 바와 같이, 여러가지 예시적인 기법들은 이식가능하고 검증가능한 관리 CLR 환경의 상부에서 커스텀 또는 수정된 ISA를 에뮬레이트하기 위해 가상화를 사용한다. 이것은 아키텍처(105)에서 CLR과 관리 애플리케이션 공간의 경계의 상부에 있는 예시적인 커스텀/수정된 ISA 및/또는 VM(107)(점선 원호)으로 나타내어져 있다(여러가지 예들이 비관리 애플리케이션에 대해서도 기술하고 있음에 유의할 것). 이것은 커스텀/수정된 ISA가 CLR 및 하부 환경, 즉 "호스트" 환경(예를 들어, OS/HW)의 동작을 방해하지 않음을 의미한다. 커스텀 ISA가 커스텀 ISA의 여러가지 특징들을 구현하는 데 필요한 정도까지 CLR 또는 "VM"의 제어를 제공할 수 있는 반면, 여러가지 예들은 하부의 VM의 수정된 버전(즉, 수정된 CLR)일 수 있는 커스텀 VM에 의존한다. 따라서, 예시적인 아키텍처는 하나의 수정된 VM 또는 다수의 VM(예를 들어, 커스텀 VM이 목표 VM의 상부에 있음)을 포함할 수 있다. 얼마간 성능을 희생시켜 보안을 향상시키기 위해, 최하위 레벨 VM 이외의 모든 VM이 바로 아래의 VM의 명령어 세트를 가상화하는 방식으로 복수의 VM이 적층되어 있을 수 있다.

도 1에서, 화살표는 종래의 CLR이 그의 상부에 2가지 타입의 가상화(VM1, VM2)를 갖는 가상화 계층을 갖는 일례 및 종래의 CLR이 그의 상부에 2개의 적층된 가상화 계층(VM1, VM3)을 갖는 다른 일례를 가리킨다. 이러한 예들에서, 하부의 CLR은 부가적인 하나 이상의 가상화 계층이 보안을 더욱 향상시키는 보안 기능을 갖는 커스텀 또는 독점적 CLR일 수 있다. 예시적인 메서드는 다수의 적층된 VM을 포함하며, 각각의 VM은 그 바로 아래의 기계의 명령어 세트를 가상화한다. 최하위 레벨 VM이 통상적으로 하드웨어를 제어하는 운영 체제를 가상화하는 반면 기타 상위 레벨 VM이 다른 VM을 가상화한다는 것에 유의한다. 도 1에 나타낸 바와 같이, 다양한 구성이 가능하다(예를 들어, 2개의 VM이 하나의 VM 상부에 있음, 적층된 VM, 기타). 다중 "커스텀" VM 방식은 얼마간 성능을 희생시켜 더 많은 보안을 달성하기 위해 가상화를 이용하는 것으로 볼 수 있다.

다시 유전학 및 환경에서의 유사점을 참조하면, 유전학은 정적인 것으로 생각될 수 있는 반면, 환경은 동적인 것으로 생각될 수 있다. 이와 유사하게, 여러가지 다양성-기반의 변조 방지 방식은 정적 및/또는 동적일 수 있다. 일반적으로, 정적인 방식은 프로그램 코드의 사본을 다양화시키는 반면, 동적인 방식은 런타임 시에 VM 또는 VM 동작 또는 프로그램 동작을 다양화시킨다. 따라서, 본 명세서에 기술된 바와 같이, 여러가지 예시적인 기법들은 정적으로, 동적으로, 및/또는 정적으로도(예를 들어, 개별화된 프로그램 코드를 생성함) 동적으로도(예를 들어, 런타임 시에 프로그램 동작을 변화시킴) 동작하는 가상화를 포함한다.

예시적인 방법은 제1 가상화 계층을 포함하는 아키텍처를 제공하는 단계 및 제1 가상화 계층의 상부에 제2 가상화 계층을 제공하는 단계를 포함할 수 있으며, 제2 가상화 계층은 프로그램의 다양화된 사본을 수신하고 제1 가상화 계층을 사용하여 프로그램의 실행을 가능하게 해주도록 구성되어 있다. 이러한 방법은 본 명세서에 기술된 다양화 기법을 사용하여 소프트웨어 보안을 향상시킬 수 있다.

예시적인 방법은 프로그램 코드의 개별화된 사본을 생성하는 단계 및 프로그램 코드의 개별화된 사본을 실행하는 가상 기계를 제공하는 단계를 포함할 수 있고, 이 가상 기계는 런타임 시에 프로그램 동작을 변화시킬 수 있다. 이러한 방법은 본 명세서에 기술된 다양화 기법을 사용하여 소프트웨어 보안을 향상시킬 수 있다.

편의상, 커스텀 및 수정된 ISA는 본 명세서에서 커스텀 ISA라고 한다. 커스텀 ISA는 프로그램의 일련의 서로 다른 사본(즉, "버전")을 생성하는 데 사용될 수 있으며, 이들 사본은 이하의 특성들을 갖는다, 즉 (i) 일련의 사본 내의 각각의 사본은 변조에 대한 타당한 수준의 방어 수단을 가지고 있고, (ii) 한 사본에 대한 기존의 공격이 다른 사본에 대해 동작하도록 목표를 변경하는 것이 어렵다. 선택의 여지가 많은 결과, 대규모의 의미적으로 동등한 프로그램 공간이 생성될 수 있다. 어떤 방법은 더 많은 다양성을 가능하게 해주기 위해 이 공간 전체를 고려할 수 있거나, 다른 대안으로서, 어떤 방법은 다른 부분보다 더 변조-방지인 것으로 생각되거나 그러한 것으로 밝혀진 이 공간의 일부만을 고려할 수 있다.

변조-방지 특성들로는, (i) 프로그램의 정적 분석을 방지하는 것, (ii) 프로그램의 동적 분석을 방지하는 것, (iii) 지역적 수정을 방지하는 것, 및 (iv) 전역적 수정을 방지하는 것이 있다. 처음 2개의 특성은 난독화(obfuscation)의 문제와 밀접한 관계가 있는 반면, 나머지 2개의 특성은 보다 변조-방지 지향적이다. 그렇지만, 지능적인 변조는 적어도 어느 정도의 프로그램 이해를 필요로 하며, 이 프로그램 이해는 통상적으로 정적 바이너리를 관찰하는 것, 실행 중인 실행 파일을 관찰하는 것, 또는 이 2가지 기법의 조합 및/또는 반복에 의해 얻어진다.

여러가지 ISA(예를 들어, CISC, RISC 및 보다 최근의 Java™ 바이트코드 및 관리 MSIL)가 존재한다. 그렇지만, 뒤의 2개는 여러 이유로 더 쉽게 분석되는 경향이 있다. 첫째, 바이너리는 통상적으로 하드웨어 상에서 직접 실행되지 않지만, 실행 이전에 네이티브 코드로 에뮬레이트 또는 번역되어야 한다. 이것을 가능하게 해주기 위해, 코드와 데이터 간의 경계를 알 필요가 있으며, 상수 데이터와 재배치가능 주소(relocatable address) 간에 혼동이 없을 수 있다. 물론, 이것은 이식성의 이점이 있다. 이식성 이외에, 설계 원칙은 타입별 메모리 관리(typed memory management) 및 검증가능성(verifiability)에 대한 지원을 포함한다. 검증가능성을 보장하기 위해, 포인터 연산이 허용되지 않으며, 제어 흐름이 제한되고, 기타 등등이 행해진다. 타입별 메모리 관리를 가능하게 해주기 위해, 객체의 타입에 관하여 많은 정보가 실행 환경으로 전달될 필요가 있다.

이들 설계 원칙 모두는 실행 환경이 분석하기 쉽지만 똑같이 공격자도 분석 하기 쉬운 바이너리를 생성한다. 이것으로 인해 Java™ 및 관리 MSIL 바이너리 둘다에 대한 역컴파일러(decompiler)가 나타나게 되었다.

일반적으로, ISA의 설계 원칙이 소프트웨어 보호를 용이하게 해주는 설계 원칙과 점점 더 충돌하게 되는 경향이 있다.

본 명세서에 기술된 바와 같이, 이러한 경향에 대처하는 예시적인 기법은 부가적인 가상화 계층(또는 선택적으로 다수의 부가적인 가상화 계층)을 추가한다. 보다 구체적으로는, 이식가능하고 검증가능한 관리 런타임 환경의 상부에서 커스텀 ISA를 에뮬레이트하는 데 가상화가 사용될 수 있다. 이하의 구성을 생각해보자. (i) CLR의 상부에서 실행되는 환경에 대한 에뮬레이터(예를 들어, 커스텀 가상 기계)를 작성한다. (ii) 바이너리의 이진 표현을 받아서 이를 에뮬레이터에 데이터로서 추가한다. (iii) 주 프로시저가 원본 실행 파일의 진입점에서 에뮬레이션을 시작하게 한다. 이 구성이 주어진 경우, 그 결과는 이식가능하고 검증가능한 관리 바이너리이다. 게다가, 이는 네이티브 바이너리로서 보호되는데, 그 이유는 네이티브 바이너리의 공격자가 쉽게 네이티브 바이너리를 받아서 상기 구성을 따라할 수 있기 때문이다.

일반적으로, 바이너리의 경우, 경험 및 직관으로부터 볼 때, 보통의 IA32 바이너리(IA32 binary)는 보통의 관리 바이너리(managed binary)보다 이해하고 조작하기가 훨씬 더 복잡하다. 몇몇 기본적인 이유로는 (i) 가변적인 명령어 길이, (ii) 코드와 데이터 간의 구분이 분명하지 않음, 및 (iii) 상수 데이터와 재배치가능 주소 간의 구분이 분명하지 않음이 있다. 명령어(연산 코드 + 피연산자)가 가 변 길이(예를 들어, 1 - 17 바이트)를 가질 수 있고, 명령어가 바이트-정렬되기만 하면 되며, IA32에서 패딩 데이터 또는 정규 데이터와 혼합될 수 있기 때문에, 역어셈블러가 쉽게 동기를 벗어날 수 있다. 코드와 데이터 간에 명시적인 분리가 없기 때문에, 이들 둘다가 투명하게 읽기 및 쓰기될 수 있고 상호 교환가능하게 사용될 수 있다. 이것은 자기-수정 코드(self-modifying code)를 가능하게 해주는 것으로서, 분석하기 어렵고 공격자를 혼란시키는 것으로 유명한 특징이다.

코드의 이진 표현이 쉽게 판독될 수 있는 특성은 자기-검사 메카니즘을 가능하게 해주는 데 사용되는 반면, 제어 흐름에 대한 제한이 없는 것은 제어 흐름 평탄화(control flow flattening) 및 명령어 중첩(instruction overlapping) 등의 기법을 가능하게 해준다.

주소가 계산될 수 있고 주소가 정규 데이터와 쉽게 구별될 수 없다는 사실은 바이너리를 변조하는 것을 복잡하게 만든다. 예를 들어, 공격자는 지역적 수정만을 할 수 있는데, 그 이유는 공격자가 전체 바이너리를 재배치하는 데 충분한 정보를 가지고 있지 않기 때문이다. 이러한 관찰 내용은 분석하기 어려운 것으로 판명되는 예시적인 커스텀 ISA를 생성하는 데 사용될 수 있다. 이러한 ISA는 보안을 향상시킬 수 있다.

예시적인 기법들이 ISA 내의 자기-수정 코드 및/또는 제어 흐름 평탄화 및/또는 명령어 중첩을 포함할 수 있는 반면, 본 명세서에 기술된 구체적인 예들은 변조 방지의 향상을 위해 가변 길이의 명령어의 제공 및 프로그램의 일부분의 이진 표현의 사용을 포함하며, 이들은 어떤 자기-검사 메카니즘과 관련되어 있는 것으로 생각될 수 있다.

소프트웨어는 종종 비제어된 방식으로 공유하고 싶지 않은 것들을 알고 있다. 예를 들어, 시험판은 주어진 작업을 수행하는 기능을 포함하고 있을 수 있지만, 시간 제한은 너무 오랫동안 그 기능을 사용하지는 못하게 할 수 있다. 디지털 컨테이너에서, 소프트웨어는 종종 컨텐츠에의 제어된 액세스를 제공하는 데 사용된다. 모바일 에이전트(mobile agent)는 비밀로 유지될 필요가 있는 암호키를 포함하고 있을 수 있다.

공격을 복잡하게 만들기 위해, 예시적인 방법으로는, (i) 프로그램을 서로 다른 설치에 대해 서로 다르게 만드는 것, (ii) 프로그램을 맞춤 업데이트를 통해 시간의 경과에 따라 서로 다르게 만드는 것, 및 (iii) 프로그램을 런타임 랜덤화를 통해 매 실행마다 서로 다르게 만드는 것이 있다.

도 2는 가상 기계 상에서 이식가능한 실행가능 파일을 실행하는 프레임워크와 관련하여 구현되는 예시적인 보안 모듈(200)을 나타낸 것이다. 보안 모듈(200)은 프런트 엔드 프로세스 모듈(210) 및 백 엔드 프로세스 모듈(250)을 포함한다. 프런트 엔드 프로세스 모듈(210)은 VM을 목표로 하는 실행가능 바이너리 파일(110)을 판독하고 원래의 목표 VM 또는 커스텀 VM의 수정된 버전을 목표로 하는 커스텀 실행가능 바이너리 파일(150)을 생성한다. 어느 한 경우에, 프런트 엔드 프로세스 모듈(210)은 파일(110)을 사용하여 원래의 목표 VM에 관한 정보(VM 설명(215) 등)를 구할 수 있다. 백 엔드 프로세스 모듈(250)은 VM 설명(215)을 사용하여 커스텀 VM(170)에 대한 코드, dll, 기타 등등을 생성할 수 있다. 예를 들어, 종래의 VM은 공유 라이브러리 또는 dll(예를 들어, "네이티브" 라이브러리)로서 출하될 수 있고, 이러한 기법들은 커스텀 VM에 대해 사용될 수 있으며, VM이 VM의 상부에서 동작하는 경우, 커스텀 VM의 형태 및/또는 특성에서 하부의 VM의 명세가 고려될 수 있다는 것에 유의한다. 편의상, VM에 적용되는 용어 "커스텀"은 수정된 VM(예를 들어, 코드의 원래의 목표 VM의 수정된 버전)을 포함할 수 있다.

.NET™ 프레임워크를 목표로 하는 예에서, 프런트 엔드 프로세스 모듈(210)은 관리 MSIL 바이너리(110)를 읽고, 그의 ISA를 결정하기 위해 그 코드에 대해 몇번 실행되며, 그의 목표 VM의 XML 설명(215)을 생성한다. ISA가 결정되면, 모듈(210)은 원본 바이너리를 커스텀 바이트코드 언어(150)로 재작성할 수 있다.

도 3은 백 엔드 프로세스 모듈(250)이 XML 설명(215)을 읽고 커스텀 VM에 대한 관리 dll(172)을 생성하는 예시적인 메서드(300)를 나타낸 것이다. 백 엔드와 프런트 엔드의 분리는 얼마간 인위적인 것이지만, 더욱 모듈식인 설계를 가능하게 해주고 디버깅을 용이하게 해줄 수 있다. 예를 들어, 백 엔드 프로세스 모듈(250)은 dll을 직접 컴파일하지 않고 C# 코드(174)를 출력하도록 지시받을 수 있다(예를 들어, 172 참조). 이어서, 코드(174)가 별도로 검사 및 디버깅될 수 있다.

도 4는 원본 바이너리의 여러 부분들이 보유되는 예시적인 메서드(400)를 나타낸 것이다. 보다 구체적으로는, 원본 VM 실행가능 바이너리(110)는 함수(115(1)-(N))를 둘러싸고 있는 래퍼(wrapper)(111)를 포함하고, 프런트 엔드 프로세스 모듈(210)은 모든 함수(115(1)-(N))를 VM을 호출하여 필요한 인수를 전달하는 래퍼(113) 내에 재작성한다. 이러한 에에서, 모든 인수는 객체들의 어레이 형 태로 전달될 수 있다. "instance" 함수의 경우, 메서드(400)는 "this" 포인터도 포함하고 있다. 메서드(400)가 모든 함수에 대해 동작하여 각각을 하나의 구조로서 배치하기 때문에, 프런트 엔드 프로세스 모듈(210)은 또한 각각의 함수의 진입점의 식별 기호를 전달하는 것을 제공할 수 있다. 그에 부가하여, 프런트 엔드 프로세스 모듈(210)은, 적절한 경우, 반환된 객체가 원래의 함수의 반환 타입으로 변환(cast)되도록 하는 기능을 제공할 수 있다.

도 5는 메서드(400)의 특정의 구현예를 보다 상세히 나타낸 것이다. 이 예에서, 프런트 엔드 프로세스 모듈(210)은 VM을 호출하는 래퍼를 사용하여 함수를 스텁(stub)으로 변환하였다. 보다 구체적으로는, 함수 "foo"는 호출 "InvokeVM"으로 래핑된다.

앞서 언급한 바와 같이, 데이터 또는 데이터 구조는 다양화를 위한 수단을 제공할 수 있다. 도 6은 예시적인 프런트 엔드 프로세스 모듈(210)이 바이너리(110)를 원래의 데이터 구조 내의 데이터(117(1)-(N))와 함께 받아서 커스텀 바이너리(150)를 수정된 또는 커스텀 데이터 구조(156) 내의 데이터(117(1)-(N))와 함께 출력하는 예시적인 메서드(450)를 나타낸 것이다. 메서드(450)가 또한 함수들(115(1)-(N))의 래핑도 나타내고 있지만, 예시적인 메서드는 코드를 다양화함으로써, 데이터를 다양화함으로써, 및/또는 코드 및 데이터를 다양화함으로써 커스텀 바이너리를 생성할 수 있다. 어구 "데이터의 다양화"는 데이터의 다양화 및 데이터 구조에 기초한 다양화를 포함할 수 있다.

함수마다 원본 프로그램을 재작성하는 것을 포함하는 예시적인 메서드는, 데 이터 구조가 여전히 원본 프로그램에서와 같이 처리되기 때문에, 가비지 컬렉션과 같은 것들이 문제가 되지 않는다는 점에서 이점을 갖는다. 난독화, 다양화 및 데이터를 더 변조-방지되게 만드는 기법들이 적용되는 경우, 수정예들은 가비지 컬렉션과 같은 것들을 제공할 수 있다.

상기한 도 1 내지 도 6은 보안을 향상시키기 위해 가상화가 어떻게 사용될 수 있는지를 나타낸 것이다. 보다 구체적으로는, 프런트 엔드 프로세스 모듈은 커스텀 바이너리 코드를 생성하는 데 사용될 수 있고, 백 엔드 프로세스 모듈은 커스텀 바이너리 코드를 실행하는 커스텀 VM을 생성하는 데 사용될 수 있다. 이하에서 기술되는 도 7 내지 도 14는 ISA 및/또는 VM의 특정의 기능들이 다양화를 통해 보안을 향상시키는 데 어떻게 사용될 수 있는지를 나타낸 것이다.

관리 코드 및 본 명세서에 제공된 여러가지 예시적인 기법과 관련하여, 여러가지 예시적인 기법들이 .NET™으로부터 Java™ 영역으로 이전될 수 있기 때문에, CLR에 대한 관리 MSIL과 JRE(Java Runtime Environment)에 대한 Java™ 바이트코드 간의 선택은 얼마간 임의적이다. 게다가, Java™ 바이트코드를 난독화하는 기법이 관리 MSIL 바이너리에 적용될 수 있다. 이하의 설명은 주로 "부가된" 또는 커스텀 가상화 계층으로부터 비롯되는 예시적인 기법들에 주안점을 두고 있다. 예를 들어, 인터넷 배포를 통해 배포된 사본들의 자동화된 다양화는 계속 채택되고 있다. 따라서, 예시적인 기법들 중 임의의 것의 오버헤드 유발이 점점 더 경제적으로 실행가능하다.

여러가지 예시적인 기법들은 사람 상호작용이 더 이상 필요하지 않은 시점에서 자동적으로 보호를 도입할 수 있다. 다루기 힘들 정도로 많은 다양한 의미적으로 동등한 프로그램을 생성하는 것이 이론적으로 가능하다. 300개의 명령어를 갖는 프로그램을 생각하고 명령어마다 no-op를 전방 추가(prepend)할지를 선택한다. 이것은 2³⁰⁰개의 서로 다른 의미적으로 동등한 프로그램을 생성하며, 2³⁰⁰은 추정된 우주 내의 입자 수인 10⁸⁷보다 크다.

그렇지만, 한 인스턴스로부터 얻은 정보를 다른 인스턴스에 매핑하는 것을 곤란하게 할 정도로 얻어진 프로그램들이 다양해야만 하기 때문에 고유성이 꼭 충분한 것은 아니다. 게다가, 얻어진 프로그램들이 양호하게는 깨기 쉬운 것이어서는 안된다. 여러가지 예시적인 다양화 기법들의 공역이 모든 의미적으로 동등한 프로그램을 포함할 것으로 기대하는 것이 타당하지 않지만, 목표가 다양화기의 공역을 최대화하는 것으로 설정될 수 있는데, 그 이유는 공간이 클수록, 내부적으로 서로 다른 프로그램을 획득하기가 더 쉽기 때문이다.

예시적인 방법은 의미 자체에서보다는 기존의 의미 구현예에서부터 시작한다. 다수의 파라미터화가능 변환(parametrizable transformation)을 통해, 서로 다른 버전들이 획득된다. 이하의 여러가지 예들에서, 독립적으로 개별화될 수 있는 ISA의 다수의 컴포넌트들이 식별된다.

도 7은 바이너리 컴포넌트(505) 및 VM 구현 컴포넌트(560)로서 그룹화되는 예시적인 프레임워크 특성들(500)을 나타낸 것이다. 바이너리 컴포넌트(505)는 명령어 의미(510), 명령어 인코딩(520), 피연산자 인코딩(530), 페치 사이클(540), 그리고 프로그램 카운터(PC) 및 프로그램 표현(550)을 포함한다. 이들 컴포넌트는, 인터페이스들이 존중되는 한, 직교 방식으로 개별화될 수 있다. 커스텀 바이트코드 언어로 바이너리를 생성하는 데는, 즉 예시적인 커스텀 ISA를 구하는 데는 컴포넌트(505)로 충분하다. 그에 부가하여, 목표 VM 또는 커스텀 VM을 다양화하는 것으로 다양화가 행해질 수 있다(예를 들어, VM 구현 컴포넌트(560)를 참조할 것).

도 8은 실행 모델 및 인터페이스(800)를 나타낸 것이다. 이 모델(800)은 코드(802), 데이터 구조(804), 메서드 프레임워크(810), 및 커스텀 바이너리(150)를 포함하고 있다. 도 8에서, 화살표는 인터페이스 의존관계를 나타내고, 별표는 어떤 다양화가능한 부분들을 나타낸다. 이러한 모델을 사용하는 예시적인 방법은 모듈식 설계 및 독립적인 개발을 가능하게 해준다.

모델(800) 및 프레임워크(500)에 따르면, 다양화는 (i) 작은 명령어들의 조합을 통해 명령어를 작성함으로써 명령어 의미를 랜덤화하는 것, (ii) 증가된 의미 중첩을 가능하게 해주도록 명령어 의미를 선택하는 것, (iii) 종래의 선형 코드 표현으로부터 벗어나 코드를 자기-적응(스플레이) 이진 트리 등의 데이터 구조로 표현하는 것, (iv) 역어셈블링(disassembly)를 복잡하게 하고 지역적 수정을 더 어렵게 만들기 위해 연산 코드(opcode) 및 피연산자에 가변 길이를 할당하는 것, (v) 공격자에게 코드를 분석 및 수정하는 옵션을 더 적게 제공하도록 명령어 세트를 제한하는 것, 및 (vi) 비트 패턴, 연산 코드 및 피연산자 간의 매핑을 가변적으로 만드는 것을 포함할 수 있다.

도 8의 코드(802)는 페치-실행 사이클에 기초한 실행 엔진의 상위-레벨 개요 를 제공한다. VM의 주요 내부 데이터 구조는 메서드 프레임워크(810)로서 나타내어져 있다. 앞서 언급한 바와 같이, 화살표는 인터페이스 의존관계를 나타내고 있다. 예를 들어, DecodeOpcode는 다수의 비트를 페치할 수 있는 것으로 예상된다.

도 9는 도 5의 명령어 의미(510) 및 다양화를 위해 사용될 수 있는 어떤 특징들을 나타낸 것이다. 마이크로-연산(micro-operation)의 개념은 명령어 의미의 다양화를 가능하게 해줄 수 있다. 예를 들어, (예를 들어, 커스텀 ISA에 따라) 커스텀 바이트코드 언어로 된 명령어는 미리 정해진 일련의 마이크로-연산의 임의의 시퀀스일 수 있다. MSIL의 경우, 일련의 마이크로-연산은 현재 검증가능한 MSIL 명령어 및 (i) 적절한 실행을 위해 필요한 메타-정보를 전달하고 (ii) 의미를 변경하는 것 등의 부가 기능을 가능하게 해주는 다수의 부가 명령어를 포함한다(이하에서 더 상세히 설명함).

이것은 P6 마이크로-아키텍처에서의 마이크로-연산(μop)의 개념에 비유될 수 있다. 각각의 IA32 명령어는 일련의 op로 번역되고, 이들 op는 이어서 파이프라인에 의해 실행된다. 이것은 또한 수퍼-연산자(super-operator)에 비유될 수 있다. 수퍼-연산자는 고비용의 연산당 오버헤드를 피하고 실행 파일 크기를 감소시키기 위해 작은 연산의 조합으로부터 자동적으로 합성된 가상 기계 연산이다.

예시적인 방법은 마이크로-연산 각각을 에뮬레이트하는 스텁들을 제공하는 단계를 포함할 수 있으며, 이들 스텁(stub)은 커스텀 바이트코드 언어(예를 들어, 커스텀 ISA)로 된 표현이 더 풍부한 명령어들을 에뮬레이트하기 위해 연접될 수 있으며, 많은 에뮬레이션 함수(emulation function)가 리플렉션(reflection)에 크게 의존할 수 있다는 것에 유의한다.

이하의 MSIL 명령어들(덧셈, 인수 로드 및 상수 로드) 및 이들의 에뮬레이션 스텁(간단화되어 있음)을 사용하는 일례를 생각해보자.

명령어 선택 단계 동안에, 이하의 의미를 갖는 커스텀 바이트코드 명령어를 생성하고자 하는 것으로 가정하자.

CustomIns n i: n번째 인수를 로드하고, 상수 i를 로드하며, 이들 2개의 값을 더한다.

이 명령어는 이어서 큰 "switch" 문에서 "case" 문(예를 들어, 1)에 할당된다. case 문은 마이크로-연산의 서로 다른 에뮬레이션 스텁들의 연접이다.

변조 방지와 관련하여, 명령어의 의미를 알지 못하는 것은, 의미가 규정되어 있는 설명서를 갖는 것과는 대조적으로, 프로그램 이해를 복잡하게 만든다. 한 걸음 더 나아가기 위해, 커스텀 변조 방지 ISA는 어떤 설계 원칙(들)을 지키는 명령어 의미를 선택할 수 있다.

다시 도 9를 참조하면, 변조 방지를 향상시키기 위해 선택적으로 조건문 레지스터(predicate register)(513)와 관련하여, 조건부 실행(conditional execution)(512)이 사용될 수 있다. 조건부 실행은 또한 약간 다른 코드를 병합하는 것을 증진시킬 수 있다. 조건부 실행이 있는 경우, 명령어들은 조건문 레지스터에 의해 단정될 수 있다. 조건문 레지스터가 false로 설정되는 경우, 명령어는 no-op(무연산)로 해석되고, 그렇지 않은 경우, 명령어는 에뮬레이트된다. 이 방법을 사용하여, 레지스터는 약간 다른 코드를 실행할 수 있는 서로 다른 실행 경로를 따라 설정된다.

예시적인 방법은 원본 프로그램에서 2개의 서로 다른 컨텍스트로 코드 시퀀스(a, b, c 및 a, d, c)를 제공하는 단계 및 이어서 이 코드를 a, [p1]b, [p2]d, c에 "병합"하는 단계(여기서, 제1 컨텍스트로 코드를 실행하기 위해서는 p1이 "true"로 설정되고 p2는 "false"로 설정되고 제2 컨텍스트로 코드를 실행하기 위해서는 그 반대로 설정됨)를 포함할 수 있다. 하나 이상의 조건문 레지스터를 서로 다르게 설정한 결과, 서로 다른 코드가 실행될 수 있다(예를 들어, a, b, no-op, c 및 a, no-op, d, c).

변조 방지를 향상시키기 위해 제한된 명령어 세트(514)가 사용될 수 있다. 예를 들어, 커스텀 ISA는 no-op를 갖지 않고(515), 표현가능한 피연산자를 제한하며(516), 및/또는 적어도 어떤 조건 분기를 제거할 수 있다(517). 다른 방법은 커스텀 VM을 특정의 프로그램(들)에 맞춤화할 수 있으며, 따라서 예시적인 방법은 VM이 그 프로그램에 의해 요구되는 연산들만을 에뮬레이트할 수 있도록 해줄 수 있다.

또다시 no-op을 갖지 않는 커스텀 ISA(515)를 참조하면, 이 방법은 "원하지 않는" 기능(예를 들어, 라이센스 검사 또는 부상당한 게임 캐릭터의 건강을 저하시키는 것)을 no-op로 덮어쓰기함으로써 이러한 기능을 제거하는 통상의 공격 기법을 고려하고 있다. 많은 경우에, 커스텀 ISA에 no-op 명령어를 포함시킬 이유가 거의 없으며, 이러한 명령어를 갖지 않는 것은 원하지 않는 코드를 늘리려고 하는 공격자의 시도를 복잡하게 만든다.

표현가능한 피연산자를 제한하는 것(516)과 관련하여, 통계를 보면, 예를 들어, 어떤 600개 Java™ 프로그램(총 140만 라인)으로부터의 정수 리터럴 중에서, 80%는 0 내지 99이고, 95%는 0 내지 999이며, 92%는 2의 멱승 또는 2의 멱승 +/- 1이다. 따라서, 예시적인 커스텀 ISA는 표현가능한 피연산자의 수를 제한할 수 있 다, 다시 말하면 공격의 자유도를 제한할 수 있다.

다른 예시적인 방법은 적어도 어떤 조건 분기의 사용을 수정 또는 제한할 수 있다(517). 예를 들어, 보통, 각각의 조건에 대해 2가지 형태, 즉 "조건이 설정되어 있으면 분기하는 것과 조건이 설정되어 있지 않으면 분기하는 것"이 있다. 2개의 분기의 사용이 중복적이기 때문에, 커스텀 ISA는 한가지 형태만이 사용되고 그의 대응하는 형태가 ISA에 포함되지 않도록 코드를 재작성하는 것을 포함할 수 있다. 이 예시적인 기법은, 예를 들어, 라이센스 검사가 일련 번호의 유효성에 따라 조건부로 분기할 때 유용할 수 있으며, 이는 공격자가 분기 조건을 간단히 바꾸지 못하도록 한다.

도 10은 다양화를 위해 사용될 수 있는 명령어 인코딩의 여러가지 측면을 갖는 도 5의 명령어 인코딩 블록(520)을 나타낸 것이다. 보다 구체적으로는, 이들 측면은 가변적인 명령어 크기(522), 물리적 중첩을 위한 일진 인코딩(unary encoding)(524), 비지역적 의미(526), 및 디코딩 구조의 재배열(529)를 포함한다.

명령어 의미가 결정된 경우, 그 명령어에 대한 연산 코드 인코딩(opcode encoding)을 결정할 필요가 있다. 종래의 아키텍처에 대한 모든 연산 코드의 크기는 보통 일정하거나 단지 약간만 변한다. 예를 들어, MSIL 연산 코드는 통상적으로 1 바이트이고, 덜 빈번한 명령어에 대한 2 바이트 연산 코드를 가능하게 해주기 위해 이스케이프 값(Oxfe)을 갖는다. 제한된 가변성은 테이블 해석(table interpretation)을 통한 고속 탐색을 용이하게 해준다. 그렇지만, 보다 일반적으로, 어떤 프리픽스 코드(어떤 코드 워드도 임의의 다른 코드 워드의 프리픽스가 아 님)라도 명확한 해석을 가능하게 해준다.

가장 일반적인 형태에서, 의미에 대한 연산 코드를 디코딩하는 것은 이진-트리 순회를 통해 행해질 수 있다. 디코딩은 통상 루트 노드에서 시작하고, 0 비트가 읽혀질 때, 좌측 자식 노드로의 이동이 일어나고, 1 비트가 읽혀질 때, 우측 자식 노드로의 이동이 일어난다. 말단 노드에 도달될 때, 연산 코드가 성공적으로 디코딩된다(예를 들어, 명령어의 의미를 에뮬레이트하는 case 문에 대한 참조를 포함하는 말단 노드를 생각해보자).

커스텀 ISA가 임의적인 연산 코드 크기를 허용하는 경우, 부적법한 연산 코드가 없을 때, n개의 명령어에 대한 가능한 인코딩의 수는 이하의 식으로 주어진다.

수학식 3에서, 분수는 n개의 리프(leaf)를 갖는 평면 이진 트리의 수(카탈란 수(Catalan number))를 나타내는 반면, 계승은 리프에 연산 코드를 할당하는 것을 나타낸다. 가장 짧은 인코딩(즉, log2(n) 비트)에서 고정된 연산 코드 크기가 선택된 경우, 이는 부적법한 연산 코드를 야기할 수 있다. 이 경우에, 가능한 인코딩의 수는 이하의 표현(수학식 4)으로 주어진다.

커스텀 ISA가 최소의 고정된 연산 코드 크기 이외의 이유로 부적법한 연산 코드를 허용한 경우, 많은 더 많은 일들이 일어난다. 그렇지만, 이것은 이점을 제공함이 없이 커스텀 ISA로 작성된 바이너리의 크기를 증가시킬 수 있다.

.NET™ 프레임워크(예를 들어, MSIL)와 관련하여 본 명세서에 제시된 여러가지 예들에서, 이하의 모드들, 즉 (i) 테이블 탐색을 갖는 고정 길이 연산 코드, (ii) 약간 가변적인 명령어 크기를 가능하게 해주는 다중-레벨 테이블 인코딩(이스케이프 코드가 긴 연산 코드에 대해 사용됨), 및 (iii) 디코딩을 위한 이진-트리 순회를 갖는 임의적 길이의 연산 코드가 지원될 수 있다. 이러한 모드들은 적절한 경우 다른 프레임워크에 적용될 수 있다.

변조 방지와 관련하여, 다시 말하면, 비트 시퀀스에서 의미로의 매핑을 알지 못하는 것은, 예를 들어, 설명서 내의 이러한 정보를 갖는 것과 비교하여, 공격자를 위한 학습 곡선을 제공한다. 변조 방지 특성을 가능하게 해주는 방식으로 매핑을 선택하는 다수의 부가적인 방법들이 존재한다.

앞서 언급한 바와 같이, 도 10의 명령어 인코딩 블록(520)은 가변 명령어 크기 방식(522)을 포함한다. 예를 들어, 커스텀 ISA는 CISC 바이너리에서 허용되는 것보다 연산 코드의 길이에 훨씬 더 많은 변동을 가져올 수 있다. 가변 명령어 크 기는 또한 지역적 수정을 더욱 복잡하게 만드는 데 사용될 수 있다. 일반적으로, 큰 명령어는 작은 명령어를 간단히 대체할 수 없는데, 그 이유는 그 다음 명령어를 덮어쓰기하기 때문이다. 커스텀 ISA는 또한 작은 비제어-전달 명령어가 큰 명령어를 대체할 수 없게 할 수 있다. 예를 들어, 이것은 이러한 명령어가 길어져서 제어가 그 다음 명령어로 넘어가지 못하게 함으로써 달성될 수 있다.

각각의 명령어가 비트 범위에서(예를 들어, 약 64 비트와 약 127 비트 사이에서) 고유의 크기를 할당받을 수 있는 64개 명령어를 갖는 코드 또는 ISA를 생각해보자. 명백하게도, 큰 명령어는 작은 명령어의 공간에 들어가지 않는다. 게다가, 작은 명령어는 큰 명령어의 공간에 들어간다. 그렇지만, 제어가 그 다음 비트로 갈 때, 제어가 그 다음 명령어로 가도록 하기 위해 나머지 비트들에 no-op를 패딩하는 데 이용가능한 명령어가 없다. 따라서, 이 방식 하에서는, 공격자가 자신이 하고 싶은 것을 할 수 있는 다른 장소로 도망가지 못하게 하기 위해 제어-전달 명령어를 가장 길게 하는 것이 유용하다.

명령어 인코딩 블록(520)은 또한, 예를 들어, 물리적 중첩을 달성하는 일진 인코딩 방식(524)을 포함한다. 일진 인코딩 방식은 물리적 중첩을 증가시키거나 최대화함으로써 프로그램을 복잡하게 만들 수 있다. 예를 들어, 이러한 방식은 다른 명령어의 중간으로 들어가서 다른 명령어를 디코딩하기 시작할 수 있다. 이 방식은 양호한 인코딩을 선택함으로써 용이하게 될 수 있다. 예를 들어, 연산 코드(0, 01 , 001 , ..., O⁶³1 )를 인코딩하는 데 일진 인코딩이 사용될 수 있다. 이 예에서, 명령어의 시작에서 1 비트 후에 점프를 할 때 다른 명령어가 있을 가능성이 많다.

이상에서, 4개의 명령어가 일진 인코딩을 사용하여 연산 코드를 할당받았다. 이 예에서, 나눗셈 명령어(div)의 두번째 비트에서 디코딩이 시작하는 경우, 뺄셈 명령어(sub)가 나타난다. 마찬가지로, 나눗셈, 뺄셈 및 곱셈(mul) 명령어의 마지막 비트를 보면 덧셈 명령어가 나타난다.

명령어 인코딩과 관련한 커스텀 ISA에 대한 다른 방식은 비지역적 의미(526)를 사용한다. 배포된 사본마다 고유의 바이트코드 언어를 갖는 것은 공격자에 대한 중요한 장벽을 세운다.

일반적으로, ISA의 경우, 이하의 것들, (i) 비트 패턴에서 명령어로의 매핑, (ii) 명령어의 의미, (iii) 비트 패턴에서 피연산자로의 매핑, (iv) 데이터 구조의 표현, 기타에 대한 문서화가 없다. 그렇지만, 이러한 매핑 또는 표현은 종국에 정적 또는 동적 검사를 통해 공격자에 의해 학습될 수 있다. 공격자를 혼란케하기 위해, 커스텀 ISA는 비트 패턴이 서로 다른 실행 경로를 따라 서로 다른 의미를 갖도록 하기 위해 비지역적 의미(524)를 사용할 수 있다.

이진 프로그램은 단순히 "1"과 "0"의 시퀀스로서, 프로세서에 의해 의미가 부여된다. 비트 패턴과 해석 간의 의미는 통상적으로 ISA에 의해 고정되어 있다. 종래의 아키텍처에서, 어떤 명령어의 연산 코드가 주어진 비트 패턴으로 표현되는 경우, 이 패턴은 어디에 있든지간에 바이너리마다 일정하다. 커스텀 ISA는 특정의 비트 패턴을 가변적이게 만들 수 있으며, 공격자에 대한 중요한 장벽을 세우기 위해 모든 명령어 비트 패턴을 가변적이게 할 필요는 없음에 유의한다. 따라서, 비지역적 의미 블록(526)은, 예를 들어, 명령어에 대한 연산 코드의 가변적인 비트 패턴 블록(527) 방식을 포함한다.

커스텀 ISA에서, 비트 패턴은 단지 이전에 실행된 코드에 따라 의미를 할당받을 수 있다. 해석이 이전에 실행된 코드에 의존하게 하도록 하기 위해, (완전히 지정된) 입력에 따라, 커스텀 ISA는 서로 다른 실행 경로를 따라 프로그램 지점에 도달하는 것을 허용할 수 있다. 그렇지만, 이러한 커스텀 ISA는 여전히 주어진 프로그램 지점에서 비트의 해석에 대해 제어를 하고자 할 수도 있다. 이러한 가변성을 수용하기 위해, 커스텀 ISA는 어떤 다른 이벤트의 부작용으로서 해석 변화가 암시적이라기 보다는 명시적이도록 할 수 있다. 따라서, 비지역적 의미 블록(526)은, 예를 들어, 이전의 코드 실행에 기초하여 의미를 할당하는 비트 패턴 블록(528) 방식을 포함한다. 게다가, 비지역적 의미 블록(526)은, 예를 들어, 서로 다른 실행 경로를 따라 프로그램 지점에 도달하기 위해 커스텀 ISA에서 명시적인 해석 변화에 링크된다.

예시적인 방법은 디코딩 구조를 재배열함으로써 2개 이상의 실행 경로를 따라 프로그램에서 어떤 지점에 도달하는 것을 가능하게 해주기 위해 명령어 인코딩을 사용하여 프로그램의 다양한 사본을 생성하는 단계를 포함하며, 여기서 그 지점에서의 비트 패턴의 할당된 의미는 그 지점까지의 실행 경로에 의존한다. 예를 들어, 이러한 방법은 이전의 코드 실행에 기초한 의미(서로 다른 실행 경로에 대해 서로 다를 수 있음)를 할당할 수 있다.

커스텀 ISA는 특정의 해석 상태에서 실행 환경을 획득하는 것과 관련하여 복잡성을 제한하지 않으려고 할 수 있다. 환언하면, 이러한 방식은, 서로 다른 해석 상태에서 서로 다른 실행 경로로부터 프로그램 지점에 도달하는 것이 허용되어 있는 경우, 서로 다른 해석 상태가 무엇이든지 간에 하나의 목표 해석 상태로 이동하는 것이 비교적 쉬울 수 있도록 해줄 수 있다.

특정의 방식은 구조를 재배열하는 것(529)을 포함한다. 예를 들어, 해석을 변화시키는 것은 디코딩 트리를 재배열하는 것에 불과할 수 있다. 이전의 관찰 내용을 고려하여, 커스텀 ISA는 제한된 형태의 다양화만을 허용할 수 있다. 이를 위해, 커스텀 ISA는 서브트리(또는 다른 서브구조)가 돌아다닐 수 있는 선택된 레벨을 가질 수 있다. 이러한 선택은 몇개의 서로 다른 해석이 가능한지와 일련의 서로 다를 수 있는 해석 상태로부터 고정된 해석으로 가는 것이 얼마나 쉬운지 간의 트레이드오프이다.

일례에서, 트리 구조의 제3 레벨을 선택하는 것을 생각해보자. 가장 짧은 연산 코드가 3 비트라고 가정할 때, 이것은 8!개의 해석 상태를 가능하게 하지만, 기껏해야 8개의 마이크로-연산에서 어떤 해석 상태에도 도달가능하다. 이러한 방식은 일련의 MSIL 마이크로-연산에 적용될 수 있다. 예를 들어, 이하의 마이크로-연산을 생각해보자.

Swap(UInt3 position1, UInt3 position2): 위치 position1 및 position2에 있는 노드를 교환함

Set(UInt3 label, UInt3 position): label을 갖는 노드(어디에 있는지 상관없음)와 위치 position에 있는 노드를 교환함

테이블 해석의 경우에, 이것은 2-레벨 테이블 해석으로서 구현된다. 제1 레벨은 교환될 수 있는 다른 테이블들을 참조할 수 있다.

상기 예에서, 마이크로-연산은 대체로 MSIL 명령어에 대응하고, 피연산자 타입은 대체로 MSIL 피연산자 타입에 대응한다. 피연산자를 사용하는 마이크로-연산 에뮬레이션 스텁은 연산 코드 인코딩이 직교적으로 다양화될 수 있도록 해주기 위해 함수 호출을 사용한다. 게다가, 이러한 콜백은 자신을 호출한 커스텀 VM 명령어를 식별해주는 인수 "insNr"를 전달한다(예를 들어, 명령어 의미(510)의 예를 참조할 것). 이것은 피연산자를 서로 다른 커스텀 VM 명령어에 대해 서로 다르게 인코딩하는 것을 가능하게 해준다. 유의할 점은, 스텁들의 연접으로 인해, 연산 코드 다음에 임의의 수의 피연산자가 올 수 있다는 것이다. 따라서, 피연산자 인코딩(530)에 대한 방식은 이러한 기법들을 포함할 수 있다. 따라서, 연산 코드 인코딩을 다양화하는 유사한 방식들이 명령어 인코딩에 행해질 수 있다.

페치 사이클을 다양화하는 것은 "인위적인" 형태의 다양화로 생각될 수 있다. 도 11은 페치 사이클 블록(540)을 "필터"(542)를 사용하는 여러가지 방식을 포함하는 것으로 나타내고 있다. 기본적인 "비커스텀" 페치 사이클은 단순히, 현재의 프로그램 카운터(Program Counter, PC)에 따라, 커스텀 바이코드 바이너리로 부터 다수의 비트를 가져온다. 그렇지만, 하나 이상의 필터(542)의 사용은 변조 방지를 향상시키는 커스텀 페치 사이클을 가능하게 해준다. 이러한 필터 또는 필터들은 바이너리 내의 실제 비트를 VM에 의해 해석되는 비트로 변환시킬 수 있다.

페치 사이클 필터(542)는 하나 이상의 요청된 비트를 다른 정보와 결합함으로써 복잡성을 증가시킬 수 있다. 예를 들어, 실제의 요청된 비트가 프로그램의 다른 부분들과 결합될 수 있다(543). 이와 같이, 프로그램의 한 부분을 변경하는 것이 다른 부분에도 영향을 줄 수 있기 때문에, 프로그램이 더 상호의존적으로 된다. 기타 필터 방식들은 패턴 정합 기법을 복잡하게 만들기 위해 하나 이상의 비트를 랜덤값(예를 들어, 비밀키로부터 도출됨)과 결합하는 필터(544) 및 하나 이상의 비트를 프로그램 카운터(PC)와 결합하는 필터(545)를 포함한다.

대부분의 종래의 코드 표현은 선형 바이트 시퀀스로 되어 있다. 이러한 방식에서, 프로그램 카운터(PC)는 단순히 실행될 그 다음 바이트를 가리키며, 제어 이전은 통상적으로 실행을 계속할 바이트를 상대 오프셋 또는 절대 주소로서 지정한다. 이것은 기본적으로 코드를 바이트 어레이로서 표현하는 구조로 보이게 할 수 있다.

도 12는 어레이(553), 트리(554), 연결 리스트(555) 및 해쉬 테이블(556)을 포함한 여러가지 구조적 방식과 함께 프로그램 카운터 및 프로그램 표현 블록(550)을 나타낸 것이다. 커스텀 ISA는 코드를 스플레이 트리(도 13의 스플레이 트리(1320, 1330) 등)로서 표현할 수 있다. 코드가 스플레이 트리로서 표현될 수 있지만, 커스텀 ISA의 예시적인 방식은 다른 대안으로서 또는 그에 부가하여 보안을 향상시키기 위해 데이터를 스플레이 트리 또는 기타 선택된 구조로 표현할 수 있다. 일반적으로, 이러한 방식은 종래의 선형 표현(예를 들어, 도 13의 선형 방식(1310)을 참조할 것)보다 더 용이하게 다양화를 제공할 수 있다.

스플레이 트리는 다수의 이점을 갖는다, 즉 자체-조정적(self-balancing)이어서 코드의 자동 재배치를 가능하게 해준다. 게다가, 스플레이 트리는 임의적인 시퀀스에 대해 상각 비용(amortized cost)의 관점에서 거의 최적이다. 마지막으로, 최근에 액세스된 노드가 트리의 노드 근처에 있는 경향이 있으며, 이는 대부분의 실행 파일에 존재하는 공간 및 시간 지역성의 부분적인 이용을 가능하게 해준다.

자체-조정 속성으로 인해, 코드가 어떤 코드 단편으로 가는 실행 경로에 따라 메모리에서 많은 서로 다른 장소에 있을 수 있다. 제어 흐름 이전을 위해 코드 단편을 참조할 방법이 있는 한, 코드 단편이 이리저리로 이동될 수 있으며, 제어가 그 코드 단편으로 이전될 때 코드 단편이 검색될 수 있다. 예시적인 구조 방식은 스플레이 트리에서 노드의 키를 사용하며 이 경우 제어 이전은 제어가 이전되어야 하는 노드의 키를 지정한다. 이러한 예에서, 제어 흐름의 목표가 노드일 필요가 있다(즉, 노드 내에 포함된 코드의 중간으로 즉각 점프할 수 없다). 실제로, 이것은 실행이 각각의 기본 블록에 대해 새로운 노드를 기동시킨다는 것을 의미한다. fall-through 경로는 모든 제어 흐름을 명시적이도록 함으로써 처리될 수 있다. 이러한 예에서, 모든 제어 흐름 목표는 목표 코드(target code)를 포함하는 노드의 키로서 지정될 수 있다. 게다가, 노드에서의 코드의 크기는 일정할 수 있다. 게 다가, 노드가 너무 작아서 기본 블록 전체를 포함할 수 없는 경우, 그 노드는 다른 노드로 오버플로우되고 그곳에서 실행을 계속할 수 있다.

도 13은 계승 함수 "Fac"에 대해 주어진 선형 방식(1310)의 스플레이 트리(1320. 1330)를 사용하는 예시적인 방식을 나타낸 것이다. 예를 들어, 함수 "Fac"가 처음으로 호출될 때, 부분 (2)에 나타낸 바와 같이, 키 1을 갖는 노드가 참조되고 루트로 간다. 이 예에서 다른 주목할 만한 것은, 이 코드가 검증을 받지 않기 때문에, 호출이 더 이상 함수 시그너처(function signature)를 지정할 필요가 없다는 것이다.

이러한 기법이 생각없이 구현되는 경우, 포인터만 이리저리 이동되고, 실제 코드는 계속 힙 상의 동일한 곳에 있는다. 이것을 더욱 복잡하게 만들기 위해, 노드의 (기본 타입의) 실제 내용의 명시적인 교환이 일어날 수 있거나, 다른 대안으로서, 아마도 재암호화(re-encryption) 및/또는 다른 가비지 패딩(garbage padding)을 사용하여 코드 버퍼를 할당된 공간에 복사하는 것과 함께 새로운 코드 버퍼의 할당이 일어날 수 있다.

다시 도 7의 프레임워크 특성(500)을 참조하면, 예시적인 방식들이 VM 구현(560)에 적용될 수 있다. 어떤 방식들이 도 12에 도시되어 있다. 주어진 내부 구현에 대해, 평가 스택(evaluation stack)이 ISA에 기초하여 결정되지 않는다(예를 들어, 컴포넌트(505)를 생각해보자). 이러한 예에서, 마이크로-연산에 대한 에뮬레이션 스텁은 "pop" 및 "push" 등의 다수의 연산을 지원하는 인터페이스에 의존할 수 있다. 스택 데이터 구조(562)의 내부 구현을 위한 예시적인 방식은, 예를 들어, 어레이, 연결 리스트, 기타 등등을 통해 독립적인 다양성을 제공한다. 예시적인 방식은 선택적으로 이러한 인터페이스의 다수의 서로 다른 구현을 제공할 수 있다.

다른 방식의 목적은 VM 생성을 다양화하는 것(564)이다. 예를 들어, 상기 언급한 형태의 다양화를 위한 파라미터가 완전히 지정된 경우, 예시적인 백 엔드 프로세스는 커스텀 VM의 구현을 위해 관리 C# 표현(managed C# representation)을 어셈블하는 어떤 자동-생성된 코드와 함께 여러 장소로부터의 코드 조각(code snippet)을 결합할 수 있다. 다른 대안으로서, 예시적인 백 엔드 프로세스는 dll을 직접 출력할 수 있다.

다른 예시적인 방식은 dll을 다양화하는 것(566), 예를 들어, 소프트웨어 최적화, 소프트웨어 난독화, 소프트웨어 다양화(에 대한 비가상화-기반 방식), 기타 등등의 다양한 영역으로부터의 기존의 코드 변환의 랜덤화가능한 버전들을 사용하는 것을 포함한다.

본 명세서에 기술된 다양한 예시적인 기법들이 일반적으로 어떤 오버헤드를 야기하지만, 디지털 저작권 관리, 민감한 정보(예를 들어, 정부 정보, 독점 정보, 기타), 라이센스, 기타 등등이 관련되어 있는 경우, 다양화를 통해 보안 향상이 있다면, 이러한 오버헤드가 허용될 수 있다. 이러한 경우에, 다양화 기법이 통상적인 목표 영역에 적용될 수 있으며 어느 정도의 동시적 또는 "실시간" 실행을 요구하는 런타임 특징에는 적용될 수 없다. 예를 들어, 다양화가 디지털 저작권 관리와 연관된 코드에는 적용될 수 있고 실행 이전에 어떤 형태의 디지털 저작권 OK를 요구하는 관련 코드에는 적용될 수 없다.

가상화는 다양성 및 변조 방지 둘다에 가능한 광범위한 방법들로의 길을 열어준다. 실행 환경을 제어하는 것은 공격자의 작업을 복잡하게 만드는 중요한 수단을 제공한다. 여러가지 예들이 가상화의 개념에 기초한 소프트웨어 보호를 위한 특정의 프레임워크를 말하고 있지만, 다양성 및/또는 변조-방지 기능들이 대체로 독립적인 방식으로 도입될 수 있는 여러가지 방식들도 있다. 모듈식 개발 및/또는 배포가 사용될 수 있다.

도 15는 여러가지 예시적인 컴포넌트를 구현하고 예시적인 시스템을 형성하는 데 사용될 수 있는 예시적인 컴퓨팅 장치(1500)를 나타낸 것이다. 예를 들어, 도 1의 시스템의 서버 및 클라이언트는 장치(1500)의 다양한 기능들을 포함할 수 있다.

아주 기본적인 구성에서, 컴퓨팅 장치(1500)는 통상적으로 적어도 하나의 처리 장치(1502) 및 시스템 메모리(1504)를 포함한다. 컴퓨팅 장치의 정확한 구성 및 유형에 따라, 시스템 메모리(1504)는 휘발성(RAM 등), 비휘발성(ROM, 플래쉬 메모리, 기타 등등), 또는 이 둘의 어떤 조합일 수 있다. 시스템 메모리(1504)는 통상적으로 운영 체제(1505) 및 하나 이상의 프로그램 모듈(1506)을 포함하고, 프로그램 데이터(1507)를 포함할 수도 있다. 운영 체제(1505)는 컴포넌트(속성 및 이벤트를 포함함), 객체, 상속, 다형성, 리플렉션을 지원하고 객체-지향 컴포넌트-기반 애플리케이션 프로그래밍 인터페이스(API)(미국 워싱턴주 레드몬드 소재의 마이크로소프트사에 의해 제작된 .NET™ 프레임워크의 API 등)를 제공하는 컴포넌트-기반 프레임워크(1520)를 포함한다. 운영 체제(1505)는 또한 커스텀 ISA 및/또는 커스텀 VM을 갖는 예시적인 프레임워크(이에 한정되지 않음) 등의 예시적인 프레임워크(1600)를 포함한다. 게다가, 컴퓨팅 장치(1500)는 커스텀 ISA 및/또는 커스텀 VM을 생성하는 소프트웨어 모듈을 포함할 수 있다. 게다가, 컴퓨팅 장치(1500)는 커스텀 ISA 및/또는 커스텀 VM을 테스트하는 소프트웨어 모듈을 포함할 수 있다. 컴퓨팅 장치(1500)는 커스텀 코드 및/또는 적어도 부분적으로 커스텀 코드를 실행하는 커스텀 VM을 생성하는 소프트웨어 모듈을 포함할 수 있다. 컴퓨팅 장치(1500)는 점선(1508)으로 구분된 아주 기본적인 구성을 갖는다. 다시 말하면, 단말기는 더 적은 컴포넌트를 가질 수 있지만 이러한 기본적인 구성을 가질 수 있는 컴퓨팅 장치와 상호작용한다.

컴퓨팅 장치(1500)는 부가의 특징 또는 기능을 가질 수 있다. 예를 들어, 컴퓨팅 장치(1500)는 또한 부가의 데이터 저장 장치(이동식 및/또는 비이동식)(예를 들어, 자기 디스크, 광 디스크, 또는 테이프 등)를 포함할 수 있다. 이러한 부가의 저장 장치가 도 15에 이동식 저장 장치(1509) 및 비이동식 저장 장치(1510)로 나타내어져 있다. 컴퓨터 저장 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈, 또는 기타 데이터 등의 정보를 저장하는 임의의 방법 또는 기술로 구현되는 휘발성 및 비휘발성, 이동식 및 비이동식 매체를 포함할 수 있다. 시스템 메모리(1504), 이동식 저장 장치(1509) 및 비이동식 저장 장치(1510)는 모두가 컴퓨터 저장 매체의 예이다. 컴퓨터 저장 매체로는 RAM, ROM, EEPROM, 플래쉬 메모리 또는 기타 메모리 기술, CD-ROM, DVD(digital versatile disk) 또는 기타 광 저 장 장치, 자기 카세트, 자기 테이프, 자기 디스크 저장 장치 또는 기타 자기 저장 장치, 또는 원하는 정보를 저장하는 데 사용될 수 있고 컴퓨팅 장치(1500)에 의해 액세스될 수 있는 임의의 다른 매체가 있지만, 이에 한정되지 않는다. 임의의 이러한 컴퓨팅 저장 매체는 컴퓨팅 장치(1500)의 일부일 수 있다. 컴퓨팅 장치(1500)는 또한 키보드, 마우스, 펜, 음성 입력 장치, 터치 입력 장치, 기타 등등의 입력 장치(들)(1512)를 가질 수 있다. 디스플레이, 스피커, 프린터, 기타 등등의 출력 장치(들)(1514)도 포함될 수 있다. 이들 장치는 공지되어 있으며, 여기에서 상세히 설명할 필요가 없다.

컴퓨팅 장치(1500)는 또한 이 장치가 네트워크(예를 들어, 상기한 웹 또는 인터넷 네트워크(103)를 참조할 것) 등을 통해 다른 컴퓨팅 장치들(1518)과 통신할 수 있게 해주는 통신 접속(1516)을 포함할 수 있다. 통신 접속(1516)은 통신 매체의 일례이다. 통신 매체는 통상적으로 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈, 또는 기타 데이터에 의해 피변조 신호(반송파 또는 기타 전송 메카니즘 등)에 구현될 수 있으며 모든 정보 전달 매체를 포함한다. 용어 "피변조 데이터 신호"는 신호에 정보를 인코딩하는 방식으로 신호의 특성들 중 하나 이상이 설정 또는 변경된 신호를 의미한다. 제한이 아닌 예로서, 통신 매체는 유선 네트워크 또는 직접-배선 접속 등의 유선 매체, 및 음향, RF, 적외선 및 기타 무선 매체 등의 무선 매체를 포함한다. 용어 "컴퓨터 판독가능 매체"는 본 명세서에서 사용되는 바와 같이 저장 매체 및 통신 매체 둘다를 포함한다.

발명 대상이 구조적 특징 및/또는 방법적 동작과 관련하여 기술되어 있지만, 첨부된 청구항들에 정의된 발명 대상이 상기한 특정의 특징 또는 동작에 꼭 한정되는 것은 아니라는 것을 잘 알 것이다. 오히려, 상기한 특정의 특징 및 동작은 청구항을 구현하는 예시적인 형태로서 개시된 것이다.

Claims

컴퓨터 구현가능 방법으로서,

가상 기계를 규정하는(specifying) 프로그램의 다양한 사본을 생성하는 기능들을 포함하는 명령어 세트 아키텍처를 제공하는 단계 - 프로그램의 다양한 사본을 생성하는 상기 기능들은 조건문 레지스터(predicate registers)를 사용하여 조건부 실행(conditional execution)을 제공하는 명령어 의미(instruction semantics) 및 제한된 명령어 세트를 갖는 명령어 의미를 포함함 -;

상기 명령어 세트 아키텍처를 사용하여 프로그램의 다양한 사본을 생성하는 단계 - 상기 프로그램의 다양한 사본 각각은 상기 가상 기계의 연관된 수정된 버전을 목표로 생성됨 -; 및

상기 프로그램의 다양한 사본 중 하나의 실행을 위해 추가적인 가상 기계의 연관된 수정된 버전을 생성하는 단계

를 포함하는, 컴퓨터 구현가능 방법.
제1항에 있어서,

가상 기계의 연관된 수정된 버전을 생성하는 상기 단계는, 가상 기계 dll(dynamic-link library)을 생성하는 단계를 포함하는, 컴퓨터 구현가능 방법.
제1항에 있어서,

상기 제한된 명령어 세트는 "무연산(no operation)" 명령어(NOPS)를 포함하지 않는, 컴퓨터 구현가능 방법.
제1항에 있어서,

상기 제한된 명령어 세트는 피연산자의 제한된 표현을 가지는, 컴퓨터 구현가능 방법.
제1항에 있어서,

상기 제한된 명령어 세트는 적어도 어떤 조건 분기를 제한하는, 컴퓨터 구현가능 방법.
제1항에 있어서,

프로그램의 다양한 사본을 생성하는 상기 기능들은 가변적인 명령어 크기를 위한 명령어 인코딩을 포함하는, 컴퓨터 구현가능 방법.
제1항에 있어서,

프로그램의 다양한 사본을 생성하는 상기 기능들은 물리적 중첩을 도입하기 위해 일진 인코딩을 사용하여 연산 코드를 할당하는 명령어 인코딩을 포함하는, 컴퓨터 구현가능 방법.
제1항에 있어서,

프로그램의 다양한 사본을 생성하는 상기 기능들은 명령어에 대한 연산 코드의 가변적인 비트 패턴을 도입하는 명령어 인코딩을 포함하는, 컴퓨터 구현가능 방법.
제1항에 있어서,

프로그램의 다양한 사본을 생성하는 상기 기능들은 연산 코드의 이전의 실행에 기초하여 비트 패턴을 할당하는 명령어 인코딩을 포함하는, 컴퓨터 구현가능 방법.
제1항에 있어서,

프로그램의 다양한 사본을 생성하는 상기 기능들은 디코딩 구조를 재배열하여 둘 이상의 실행 경로를 따라 상기 프로그램 내의 한 지점에 도달할 수 있게 하는 명령어 인코딩을 포함하되, 상기 지점에서의 비트 패턴의 할당된 의미는 상기 지점까지의 실행 경로에 의존하는, 컴퓨터 구현가능 방법.
제1항에 있어서,

프로그램의 다양한 사본을 생성하는 상기 기능들은 하나 이상의 페치 사이클 필터를 포함하는, 컴퓨터 구현가능 방법.
제11항에 있어서,

상기 하나 이상의 페치 사이클 필터는 코드의 요청된 비트 또는 비트들에 정보를 부가하는 필터를 포함하는, 컴퓨터 구현가능 방법.
제12항에 있어서,

상기 정보는 랜덤값을 포함하는, 컴퓨터 구현가능 방법.
제12항에 있어서,

상기 정보는 프로그램 카운터 값(545) 또는 적어도 부분적으로 프로그램 카운터 값에 기초한 정보를 포함하는, 컴퓨터 구현가능 방법.
제1항에 있어서,

프로그램의 다양한 사본을 생성하는 상기 기능들은 상기 프로그램을 표현하는 스플레이 트리, 연결 리스트 및 해쉬 테이블로 이루어진 그룹(550)으로부터 선택된 적어도 하나의 구조를 포함하는, 컴퓨터 구현가능 방법.
제1항의 상기 명령어 세트 아키텍처를 이용하여 프로그램의 다양한 사본을 생성하기 위한 프로세서-실행가능한 명령어들이 저장된 컴퓨터 판독가능 매체.
컴퓨터 구현가능 방법으로서,

코드를 분석하여 상기 코드가 목표로 하는 가상 기계를 결정하는 단계;

수정된 가상 기계를 규정하기 위해 상기 가상 기계를 수정하는 단계;

상기 수정된 가상 기계에 적어도 부분적으로 기초하는 다양화된 가상 기계를 생성하는 단계;

상기 다양화된 가상 기계를 목표로 하고 상기 코드에 적어도 부분적으로 기초하는 다양화된 코드를 생성하는 단계 - 상기 다양화된 코드는 조건문 레지스터(predicate registers)를 사용하여 조건부 실행(conditional execution)을 제공하는 명령어 의미(instruction semantics) 및 제한된 명령어 세트를 갖는 명령어 의미를 포함함 -; 및

상기 다양화된 가상 기계를 사용하여 상기 다양화된 코드를 실행하는 단계

를 포함하는, 컴퓨터 구현가능 방법.
컴퓨터 구현가능 방법으로서,

하드웨어를 제어하는 제1 가상화 계층(virtualization layer)을 포함하는 아키텍처를 제공하는 단계;

가상 기계를 규정하는 프로그램을 수신하는 단계;

상기 가상 기계의 수정된 버전을 목표로 하도록 상기 프로그램을 수정하여 상기 프로그램의 다양화된 사본을 생성하는 단계 - 상기 가상 기계의 수정된 버전은 제2 가상화 계층을 제공하고, 상기 프로그램의 다양화된 사본은 조건문 레지스터(predicate registers)를 사용하여 조건부 실행(conditional execution)을 제공하는 명령어 의미(instruction semantics) 및 제한된 명령어 세트를 갖는 명령어 의미를 포함함 -; 및

상기 제1 가상화 계층의 상부에 상기 제2 가상화 계층을 제공하는 단계 - 상기 제2 가상화 계층은 상기 프로그램의 다양화된 사본을 처리하고 상기 제1 가상화 계층을 사용하여 상기 프로그램의 실행을 허용하도록 구성됨 -

를 포함하는, 컴퓨터 구현가능 방법.
소프트웨어 보안을 향상시키는 컴퓨터 구현 방법으로서,

하드웨어를 제어하는 운영 체제를 가상화하는 기본 가상 기계 가상화 계층을 제공하는 단계;

목표로 된 가상 기계를 규정하는 프로그램을 수신하는 단계;

상기 프로그램을 수정하여 상기 목표로 된 가상 기계의 수정된 버전을 목표로 하는 프로그램의 다양한 사본을 생성하는 단계 - 상기 프로그램의 다양한 사본은 조건문 레지스터(predicate registers)를 사용하여 조건부 실행(conditional execution)을 제공하는 명령어 의미(instruction semantics) 및 제한된 명령어 세트를 갖는 명령어 의미를 포함함 -; 및

상기 프로그램의 다양한 사본을 하나 이상의 추가적인 가상화 계층인 커스텀 가상 기계에 제공하는 단계 - 상기 하나 이상의 추가적인 가상화 계층 중 적어도 하나는 상기 기본 가상 기계의 명령어 세트를 가상화하고, 상기 목표로 된 가상 기계의 수정된 버전은 상기 커스텀 가상 기계에 기초하며,

가상화 계층은 상기 커스텀 가상 기계를 통해 상기 프로그램의 다양한 사본을 실행시킴 -

를 포함하는, 소프트웨어 보안 향상 컴퓨터 구현 방법.
소프트웨어 보안을 향상시키는 컴퓨터 구현 방법으로서,

프로그램 코드가 목표로 하는 가상 기계를 결정하기 위해 상기 프로그램 코드를 분석하는 단계;

상기 프로그램 코드의 맞춤화된 사본을 생성하기 위해 상기 가상 기계의 수정된 버전에 기초하여 상기 프로그램 코드를 수정하는 단계 - 상기 프로그램 코드의 맞춤화된 사본은 조건문 레지스터(predicate registers)를 사용하여 조건부 실행(conditional execution)을 제공하는 명령어 의미(instruction semantics) 및 제한된 명령어 세트를 갖는 명령어 의미를 포함함 -;

상기 프로그램 코드의 맞춤화된 사본의 실행을 위해 제2 커스텀 가상 기계를 제공하는 단계 - 커스텀 가상 기계의 내부 구현에 적어도 부분적으로 기초하여, 상기 가상 기계의 수정된 버전이 수정되고, 상기 제2 커스텀 가상 기계는 런타임 중 프로그램 동작을 변화시키도록 동작됨 -; 및

를 포함하는, 소프트웨어 보안 향상 컴퓨터 구현 방법.