KR102319115B1 - 컨텍스트 스위칭에 영향받지 않는 하버드 아키텍처의 캐시 특성을 활용한 에뮬레이팅 환경 탐지 방법 및 그 시스템 - Google Patents

Abstract

에뮬레이팅 탐지 방법 및 시스템이 개시된다. 본 발명의 일실시예에 따른 에뮬레이팅 탐지 방법은 명령어 캐시(I-Cache)와 데이터 캐시(D-Cache)를 포함하는 하버드 아키텍처 프로세서에서 에뮬레이팅을 탐지할 수 있도록 하는 것으로, 명령어 캐시를 사용하는 제1 탐지모듈의 실행 이후 역시 명령어 캐시를 사용하는 제2 탐지모듈을 바로 실행시켜 컨텍스트 스위칭의 영향을 받지 않고 에뮬레이팅을 탐지할 수 있도록 한다.

Description

컨텍스트 스위칭에 영향받지 않는 하버드 아키텍처의 캐시 특성을 활용한 에뮬레이팅 환경 탐지 방법 및 그 시스템 {EMULATING ENVIRONMENT DETECTING METHOD UNAFFECTED BY CONTEXT SWITCHING USING CACHE CHARACTERISTIC OF HAVARD ARCHITECTURE AND SYSTEM USING THE SAME}

본 발명은 에뮬레이팅 탐지 방법에 관한 것으로, 특히 하버드 아키텍처 프로세서에서 동작하는 어플리케이션에서 컨텍스트 스위칭이 일어나는 경우에도 에뮬레이팅 환경을 탐지할 수 있도록 하는 에뮬레이팅 탐지 방법에 관한 것이다.

실제 디바이스와 동일한 환경을 에뮬레이팅하여 실제 디바이스에서 동작하는 어플리케이션을 실행시키는 것이 쉬워지면서, 에뮬레이팅 환경을 구축하고 어플리케이션의 주요 정보를 추출하거나, 어플리케이션에 대한 역공학(Reverse-Engineering)을 실행하고자 하는 시도가 늘어나고 있다.

이에 따라서, 어플리케이션이 실행될 때마다 실행되는 환경이 실제 디바이스인지 아니면 에뮬레이팅 환경인지 확인할 수 있도록 하는 기술이 개발되고 있는데, 한국등록특허 제10-1530533호, “에뮬레이터 실행 환경 탐지 시스템 및 방법 ”과 같은 종래기술에서는 실제 디바이스에 장착된 배터리, 마이크 및 다수의 센서와 같은 하드웨어 상태 정보를 확인하여 어플리케이션이 실행되는 것이 실제 디바이스인지 확인하도록 하고 있다.

그러나, 이와 같은 방법은 에뮬레이팅 환경을 해당 센서에 대한 정보를 제공할 수 있도록 구축하는 등 우회할 수 있는 방법이 다수 존재하여, 에뮬레이팅 환경을 정확히 탐지해 내기 어렵다는 문제가 있다.

한국등록특허 제10-1530533호

본 발명의 목적은 하버드 아키텍처 프로세서에서 실행환경이 실제 디바이스인지 에뮬레이터인지 탐지할 수 있도록 하는 것이다.

또한, 본 발명의 목적은 컨텍스트 스위치가 일어나는 경우에도 실행환경이 실제 디바이스인지 에뮬레이터인지 정확히 탐지할 수 있도록 하는 것이다.

또한, 본 발명의 목적은 별도의 스레드나 함수로 에뮬레이팅 탐지 코드가 분리되지 않고도 실행환경이 실제 디바이스인지 에뮬레이터인지 탐지할 수 있도록 하여 에뮬레이팅 탐지를 우회하기 어렵도록 하는 것이다.

또한, 본 발명의 목적은 에뮬레이팅이 어려운 어플리케이션 바이너리를 생성할 수 있도록 하는 것이다.

상기한 목적을 달성하기 위한 본 발명에 따른 에뮬레이팅 탐지 방법은 명령어 캐시(I-Cache)와 데이터 캐시(D-Cache)를 포함하는 하버드 아키텍처 프로세서에서 에뮬레이팅을 탐지하는 방법에 있어서, 상기 명령어 캐시를 이용하여 명령어를 실행하는 복수의 인스트럭션(Instruction)을 포함하는 제1 판별모듈을 실행하는 단계, 상기 제1 판별모듈의 실행이 종료된 후 레지스터의 값을 확인하여 실행환경이 실제 디바이스인지 에뮬레이터인지 확인하는 1차 확인 단계, 상기 확인 결과 상기 실행환경이 에뮬레이터인 것으로 확인되는 경우, 상기 명령어 캐시를 이용하여 명령어를 실행하는 복수의 인스트럭션을 포함하는 제2 판별모듈을 실행하는 단계 및 상기 제2 판별모듈의 실행이 종료된 후 레지스터의 값을 확인하여 실행환경이 실제 디바이스인지 에뮬레이터인지 확인하는 최종 확인 단계를 포함한다.

이 때, 상기 제2 판별모듈은 상기 하버드 아키텍처 프로세서의 특성에 따라 결정되는 소정의 기준치보다 적은 수의 인스트럭션으로 구성될 수 있다.

이 때, 상기 기준치는 하기의 수학식에 의하여 결정될 수 있다.

[수학식]

기준치 = 상기 하버드 아키텍처 프로세서의 코어성능 / 상기 하버드 아키텍처 프로세서의 명령어당 평균 클럭수 / 상기 하버드 아키텍처 프로세서의 최대 프로세스 개수 / 상기 하버드 아키텍처 프로세서의 초당 전체 프로세스 리사이클 횟수

또한, 상기 1차 확인 단계에서 상기 실행환경이 실제 디바이스로 확인되거나, 상기 최종 확인 단계가 종료되면, 상기 제1 판별모듈 또는 상기 제2 판별모듈에 의해서 수정된 상기 명령어 캐시를 상기 제1 판별모듈의 실행 전 상태로 복원하는 단계를 더 포함할 수 있다.

또한, 상기 제1 판별모듈은 특정 주소의 명령어를 캐싱하는 인스트럭션, 상기 캐싱된 주소의 명령어를 수정하는 인스트럭션 및 상기 캐싱된 주소의 명령어를 실행하는 인스트럭션을 포함할 수 있다.

또한, 본 발명에 따른 에뮬레이팅 탐지 방법은 명령어 캐시(I-Cache)와 데이터 캐시(D-Cache)를 포함하는 하버드 아키텍처 프로세서에서 동작하는 어플리케이션에서 에뮬레이팅을 탐지하는 방법에 있어서, 상기 어플리케이션의 기능을 수행하는 코드 또는 바이너리를 수신하는 단계, 상기 수신한 코드 또는 바이너리에 포함된 상기 어플리케이션의 기능을 수행하는 루틴 중 적어도 하나의 루틴 앞에 상기 어플리케이션의 실행 환경이 에뮬레이터인지 여부를 확인하는 에뮬레이팅 탐지 코드를 포함시키는 단계 및 상기 에뮬레이팅 탐지 코드를 포함한 상기 어플리케이션의 실행 바이너리를 생성하는 단계를 포함할 수 있다.

이 때, 상기 에뮬레이팅 탐지 코드는 상기 명령어 캐시를 이용하여 명령어를 실행하는 복수의 인스트럭션(Instruction)을 포함하는 제1 판별 코드, 상기 제1 판별모듈의 실행이 종료된 후 레지스터의 값을 확인하여 실행환경이 실제 디바이스인지 에뮬레이터인지 확인하는 1차 확인 코드, 상기 확인 결과 상기 실행환경이 에뮬레이터인 것으로 확인되는 경우, 상기 명령어 캐시를 이용하여 명령어를 실행하는 복수의 인스트럭션을 포함하는 제2 판별 코드 및 상기 제2 판별모듈의 실행이 종료된 후 레지스터의 값을 확인하여 실행환경이 실제 디바이스인지 에뮬레이터인지 확인하는 최종 확인 코드를 포함할 수 있다.

본 발명에 따르면 하버드 아키텍처 프로세서에서 실행환경이 실제 디바이스인지 에뮬레이터인지 탐지할 수 있도록 하는 방법이 제공된다.

또한, 본 발명에 따르면 컨텍스트 스위치가 일어나는 경우에도 실행환경이 실제 디바이스인지 에뮬레이터인지 정확히 탐지할 수 있도록 하는 방법이 제공된다.

또한, 본 발명에 따르면 별도의 스레드나 함수로 에뮬레이팅 탐지 코드가 분리되지 않고도 실행환경이 실제 디바이스인지 에뮬레이터인지 탐지할 수 있도록 하여 에뮬레이팅 탐지를 우회하기 어렵도록 하는 방법이 제공된다.

또한, 본 발명에 따르면 에뮬레이팅이 어려운 어플리케이션 바이너리를 생성할 수 있도록 하는 방법이 제공된다.

도 1은 본 발명의 일실시예에 따른 에뮬레이팅 탐지 방법의 기본 원리를 도시한 도면이다.
도 2는 본 발명의 일실시예에 따른 에뮬레이팅 탐지 방법을 나타낸 동작 흐름도이다.
도 3은 본 발명의 일실시예에 따른 에뮬레이팅 탐지 방법에서 판별모듈의 동작을 나타낸 동작 흐름도이다.
도 4는 본 발명의 다른 실시예에 다른 에뮬레이팅 탐지 방법을 나타낸 동작 흐름도이다.
도 5은 본 발명의 일실시예에 따른 에뮬레이팅 탐지 코드의 일례를 도시한 도면이다.
도 6는 본 발명의 일실시예에 따른 에뮬레이팅 탐지 방법에 따라 어플리케이션 바이너리를 생성하는 일례를 도시한 도면이다.
도 7는 본 발명의 일실시예에 따른 에뮬레이팅 탐지 시스템의 내부 구성을 도시한 구성도이다.

본 발명을 첨부된 도면을 참조하여 상세히 설명하면 다음과 같다. 여기서, 반복되는 설명, 본 발명의 요지를 불필요하게 흐릴 수 있는 공지 기능, 및 구성에 대한 상세한 설명은 생략한다. 본 발명의 실시형태는 당 업계에서 평균적인 지식을 가진 자에게 본 발명을 보다 완전하게 설명하기 위해서 제공되는 것이다. 따라서, 도면에서의 요소들의 형상 및 크기 등은 보다 명확한 설명을 위해 과장될 수 있다.

이하, 본 발명에 따른 바람직한 실시예를 첨부된 도면을 참조하여 상세하게 설명한다.

본 발명은 하버드 아키텍처를 따르는 프로세서에서 동작하는 어플리케이션에서, 실행환경이 실제 디바이스인지 에뮬레이팅 환경인지를 확인할 수 있도록 하는 방법에 관한 것이다. 본 발명에서 말하는 하버드 아키텍처 프로세서는 명령어(인스트럭션, Instruction)을 저장하는 캐시와 데이터를 저장하는 캐시가 구분되어 있는 프로세서를 의미하는 것으로 이와 같이 명령어를 저장하는 메모리와 데이터를 저장하는 메모리가 구분되어 있는 형태의 프로세서라면 어떤 형태도 가능하다.

하버드 아키텍처 프로세서에서 명령어를 저장하는 캐시를 명령어 캐시(Instruction-Cache, I-Cache), 데이터를 저장하는 캐시를 데이터 캐시(Data-Cache, D-Cache)라고 하며, 본 발명은 이와 같은 하버드 아키텍처 프로세서의 캐시 특성을 활용하여 에뮬레이팅 환경을 구분할 수 있도록 한 것이다.

도 1은 본 발명의 일실시예에 따른 에뮬레이팅 탐지 방법의 기본 원리를 도시한 도면이다.

상술한 바와 같이, 하버드 아키텍처 프로세서의 캐시는 명령어 캐시와 데이터 캐시로 분리되어 있다. 이런 특성으로 인하여 실제 프로세서의 분리된 두 캐시는 때에 따라 같은 주소임에도 불구하고 서로 다른 데이터를 캐싱할 때가 있다. 그런데, 어플리케이션에 대해 정보 추출 또는 역공학 등을 하기 위하여 에뮬레이팅 환경에서 어플리케이션을 동작시키는 경우에는 에뮬레이터에서 캐시 구조를 고려할 필요가 없으므로, 하버드 아키텍처 프로세서의 캐시 특성이 반영되지 않는다.

이러한 차이로 인하여, 하버드 아키텍처 프로세서를 사용하는 실제 디바이스에서의 실행 결과와 에뮬레이팅 환경에서의 실행 결과가 달라지는 경우가 발생된다. 이와 같은 코드를 실행하여 실행결과를 비교하게 되면 해당 코드가 실행되는 환경이 실제 디바이스인지 에뮬레이터인지 구분하는 것이 가능하다.

도면의 우측에 도시된 것처럼, 손쉽게 에뮬레이팅 환경을 구분할 수 있는 판별코드는 (1) 특정 주소의 명령어 캐싱, (2) 캐싱된 주소의 명령어 수정, (3) 캐싱된 주소의 명령어 실행의 세가지 단계로 구성될 수 있다.

도면의 우측 표를 보면, (1) 특정 주소의 명령어 캐싱의 단계는 0x108번지 명령어의 첫 번째 실행에 해당하는데, 실행을 통해 명령어 캐시에 명령어를 저장하게 된다. (2) 캐싱된 명령어 수정은 도면에서 0x10C번지 명령어로 표현되어 있는데, MOV R1, #0x3에 해당하는 4바이트 값을 쓰도록 한다. (3) 캐싱된 명령어 실행은 도면에서 0x114번지에서 JUMP되어 0x108번지를 두 번째로 실행하게 되는 것을 의미한다.

이와 같이 0x108번지의 명령어가 두 번째로 실행될 때, 실제 디바이스에서는 명령어 캐시에 캐싱된 명령어(SUB R1, #0x1)이 수행되는 반면, 에뮬레이터 환경에서는 덮어 씌워진 명령어(MOV R1, #0x3)가 수행되기 때문에, 이 코드가 수행된 이후에 R1의 값을 확인해 보면, 에뮬레이터 환경에서는 0x3을 값으로 가지게 되고, 실제 디바이스 환경에서는 0x0을 값으로 가지게 된다.

이와 같은 판별코드의 전체적인 실행 흐름을 보면, 코드실행시작 -> 0x100번지 -> 0x104번지 -> 0x108번지 -> 0x10c번지 -> 0x110번지 -> 0x114번지 -> 0x108번지 -> 0x10c번지 -> 0x110번지 -> 0x114번지 -> 코드실행 종료의 순서로 진행됨을 알 수 있다.

그런데, 멀티태스킹이 일어나지 않아 컨텍스트 스위칭이 일어나지 않는 경우에는 이와 같은 동작을 통해 실제 디바이스와 에뮬레이터를 쉽게 구분할 수 있는데, 실행 중간에 컨텍스트 스위칭이 일어나는 경우 결과를 신뢰할 수 없게 된다. 예를 들어, 위 판별코드의 실행 프로세스 중에서 0x110번지 -> 0x114번지 -> 0x108번지의 3가지 단계 사이에서 컨텍스트 스위칭이 일어나게 되면, R1에 저장되는 값이 달라질 수 있다.

컨텍스트 스위칭이 일어나는 경우에도 실제 디바이스에서 실행되었다면, R1이 0x0 값을 가지게 되므로, 실제 디바이스라는 판별결과는 신뢰할 수 있다. 그러나, 실제 디바이스에서 실행하였는데, 0x110번지 -> 0x114번지 -> 0x108번지의 3단계 사이에서 컨텍스트 스위칭이 일어나는 경우에는 R1의 값이 0x3이 되는 경우가 발생될 수 있다. 즉, 에뮬레이터로 판별결과가 나오게 되는데, 실행환경은 실제 디바이스인 경우가 존재하는 것이다.

따라서, 컨텍스트 스위칭이 일어났는지, 일어나지 않았는지 확인할 수 없는 경우라면, 도 1의 판별코드에서 실제 디바이스로 판별된 경우만을 신뢰하고, 에뮬레이터로 판별된 경우는 신뢰할 수 없게 된다.

이와 같은 컨텍스트 스위칭에 대한 제어와 캐시의 Invalidate, Flush, Prefetch 작업은 사용자 영역에서 수행할 수 없기 때문에, 판별코드가 실행되는 환경을 안전하게 제어하여 정확한 결과를 얻는 것은 현실적으로 불가능한 상황이다. 이와 같은 문제를 해결하기 위해서, 여러 차례 판별코드를 반복 수행한 후 그 통계값을 이용하여 실행환경을 테스트하는 경우도 있다. 하지만, 이와 같은 방법은 불필요하게 리소스를 많이 소모하고, 결과를 얻는데까지 시간이 오래 걸리는 문제점이 있다.

따라서, 본원 발명의 보다 바람직한 실시예에서는 이와 같은 판별코드를 단독으로 수행하지 않고, 컨텍스트 스위칭에 영향을 받지 않는 형태로 실행시키도록 하여, 판별의 정확성을 높일 수 있다.

프로세서에서 컨텍스트 스위칭이 발생된 직후에는 최소 N번의 명령어 실행 안에서 컨텍스트 스위칭이 다시 일어나지 않는다. 따라서, 컨텍스트 스위칭이 발생된 직후 N번의 명령어 안에서 판별코드가 동작할 수 있다면 컨텍스트 스위칭의 영향을 받지 않고 정확한 탐지가 가능하도록 할 수 있다.

이하에서는 이와 같은 원리에 의해 컨텍스트 스위칭에 영향을 받지 않고 실행환경을 판단할 수 있도록 하는 에뮬레이팅 탐지 방법을 설명한다.

도 2는 본 발명의 일실시예에 따른 에뮬레이팅 탐지 방법을 나타낸 동작 흐름도이다.

도면에 도시한 바와 같이, 본 발명의 에뮬레이팅 탐지 방법은 제1 판별모듈을 실행하는 단계(S201), 실행환경을 1차적으로 확인하는 1차 확인 단계(S202), 제2 판별모듈을 실행하는 단계(S203), 실행환경을 최종 확인하는 최종 확인 단계(S204) 및 명령어 캐시를 복원하는 복원 단계(S205)로 구성될 수 있다.

단계 S201에서는 명령어 캐시를 이용하여 명령어를 실행하는 복수의 인스트럭션(Instruction)을 포함하는 제1 판별모듈을 실행한다. 앞서 살펴본 바와 같이, 명령어 캐시를 이용하여 명령어를 실행하는 복수의 인스트럭션을 실행하게 되면, 그 실행결과로 도출되는 레지스터 값을 이용하여 실행환경이 실제 디바이스인지 에뮬레이터인지 확인할 수 있게 된다.

단계 S201에서 실행되는 제1 판별모듈은 복수의 인스트럭션을 포함하는데, 이 복수의 인스트럭션은 도 3에 도시된 바와 같이 (1) 특정 주소의 명령어를 캐싱하는 인스트럭션(S301), (2) 상기 캐싱된 주소의 명령어를 수정하는 인스트럭션(S302), (3) 상기 캐싱된 주소의 명령어를 실행하는 인스트럭션(S303)을 포함하여 구성될 수 있다. 즉, 명령어 캐시에 명령어를 캐싱한 뒤 캐싱된 명령어를 수정하고 이를 다시 실행시킴으로써, 실제 디바이스에서의 결과와 에뮬레이터에서의 결과가 다르게 도출될 수 있도록 한다.

단계 S201의 결과만으로도 대부분의 경우 실행환경이 실제 디바이스인지 아니면 에뮬레이터인지 구별할 수가 있다. 그러나, 제1 판별모듈의 실행 중간에 프로세서에서 컨텍스트 스위칭이 일어나는 경우에는 앞서 살펴본 바와 같이 실제 디바이스로 판별되는 경우는 정확하지만, 에뮬레이터로 판별되는 경우는 실제 디바이스인 경우와 에뮬레이터인 경우가 모두 포함될 수 있다.

따라서, 본 발명에서는 단계 S201에서 실행되는 판별코드의 결과만으로 실행환경을 판단하지 않고, 보다 정확한 판단 결과를 얻을 수 있도록 아래와 같은 단계를 수행한다.

단계 S202에서는 상기 제1 판별모듈의 실행이 종료된 후 레지스터의 값을 확인하여 실행환경이 실제 디바이스인지 에뮬레이터인지 확인한다. 단계 S201에서 실행한 제1 판별모듈은 앞서 살펴본 바와 같이, 실제 디바이스인 경우와 에뮬레이터인 경우에 각각 레지스터에 다른 결과를 기록하도록 하는 모듈이다. 따라서, 제1 판별모듈의 실행 종료 후 레지스터의 값을 확인하면, 실행환경이 실제 디바이스인지 에뮬레이터인지 구분할 수 있다.

앞서 도 1에서 설명한 것과 같은 판별모듈을 제1 판별모듈로 사용하는 경우, 단계 S202에서는 레지스터 R1이 값이 0x0인지, 0x3인지 확인함으로써, 실행환경이 실제 디바이스인지, 에뮬레이터인지 구분할 수 있다. 이 밖에도 다양한 판별모듈이 존재할 수 있으며, 그 구체적인 방법에 의해 본 발명이 제한되지는 않는다.

단계 S202에서 확인한 결과 실행환경이 실제 디바이스로 확인되는 경우, 앞서 살펴본 바와 같이, 실제 디바이스임이 명확하기 때문에, 이 경우에는 추가적으로 판단할 필요 없이 단계 S205로 이동하여 에뮬레이팅 탐지를 마무리한다. 그러나, 실행환경이 에뮬레이터로 확인되는 경우에는 제1 판별모듈이 실행되는 중간에 컨텍스트 스위칭이 일어났는지 여부에 따라서, 결과가 달라질 수 있기 때문에, 단계 S203으로 진행하여 추가 확인을 하게 된다.

단계 S203에서는 상기 확인 결과 상기 실행환경이 에뮬레이터인 것으로 확인되는 경우, 상기 명령어 캐시를 이용하여 명령어를 실행하는 복수의 인스트럭션을 포함하는 제2 판별모듈을 실행한다.

단계 S203에서 실행하는 제2 판별모듈은 상술한 제1 판별모듈과 마찬가지로 복수의 인스트럭션을 포함하는데, 이 복수의 인스트럭션은 도 3에 도시된 바와 같이 (1) 특정 주소에 명령어를 캐싱하는 인스트럭션(S301), (2) 상기 캐싱된 주소의 명령어를 수정하는 인스트럭션(S302), (3) 상기 캐싱된 주소의 명령어를 실행하는 인스트럭션(S303)을 포함하여 구성될 수 있다.

따라서, 단계 S203에서 실행되는 제2 판별모듈은 제1 판별모듈과 동일한 형태로 구성될 수 있다. 그러나, 보다 정확한 판단이 가능하도록 하고 우회 가능성을 최소화하기 위하여 제1 판별모듈과 제2 판별모듈은 서로 다른 방식으로 구현되는 것이 보다 바람직하다.

단계 S203에서 실행되는 제2 판별모듈은 제1 판별모듈이 종료된 이후 바로 시작된다. 따라서, 제2 판별모듈을 구성하는 인스트럭션의 개수가 소정의 기준치보다 적게 구성되는 경우에는 제1 판별모듈의 수행 중에 컨텍스트 스위칭이 일어나서 제대로 판별이 되지 않은 경우에도 제2 판별모듈에서 컨텍스트 스위칭 없이 정확한 결과를 얻을 수 있다.

따라서, 단계 S203에서 실행되는 제2 판별모듈은 소정의 기준치보다 적은 수의 인스트럭션으로 구성되어야 한다. 상기 소정의 기준치는 하버드 아키텍처 프로세서의 특성에 따라 결정되는 것이 바람직하다.

보다 상세하게 살펴보면, 제2 판별모듈의 인스트럭션 수를 제한하는 기준치는 하기의 수학식에 의해 결정되는 것이 바람직하다.

[수학식]

기준치 = 상기 하버드 아키텍처 프로세서의 코어성능 / 상기 하버드 아키텍처 프로세서의 명령어당 평균 클럭수 / 상기 하버드 아키텍처 프로세서의 최대 프로세스 개수 / 상기 하버드 아키텍처 프로세서의 초당 전체 프로세스 리사이클 횟수

예를 들어, 프로세서의 코어성능이 1GHz이고, 명령어당 평균 클럭수가 5 CPI이며, 프로세서의 최대 프로세스 개수가 1,000개이고, 프로세서의 초당 전체 프로세스 리사이클 횟수가 10이라고 하면, 위 수학식에 대입해 보면 아래와 같은 결과를 얻을 수 있다.

1 GHz / 5 CPI / 1,000개 / 10회

= 1 * 1,000 * 1,000 * 1,000 / 5 / 1,000 / 10

= 20,000

즉, 20,000개보다 적은 수의 인스트럭션으로 제2 판별모듈을 구성할 경우, 컨텍스트 스위칭에 영향을 받지 않고 정확하게 실행환경을 확인하는 것이 가능하다.

이 때, 제2 판별모듈에 포함되어서는 안되는 명령어가 존재한다. 이 명령어들은 상기 기준치의 크기를 구할 때, 정확한 명령어의 실행 개수를 가늠하기 어렵기 때문이다. 이와 같이 포함되어서는 안되는 명령어는 (1) 함수 호출 명령어, (2) 시스템 호출 명령어, (3) 예외 발생 명령어, (4) 예외 처리 명령어, (5) 다른 실행 루틴을 동반하는 명령어가 있다.

단계 S204에서는 상기 제2 판별모듈의 실행이 종료된 후 레지스터의 값을 확인하여 실행환경이 실제 디바이스인지 에뮬레이터인지 확인하는 최종 확인한다. 단계 S202에서의 1차 확인과 동일한 형태로, 제2 판별모듈을 실행한 이후에 레지스터에 저장되는 값을 확인하는 것으로 실행환경이 실제 디바이스인지 에뮬레이터인지 확인할 수 있다.

단계 S204에서 수행되는 최종 확인은 단계 S202에서와는 달리 컨텍스트 스위칭의 영향을 받지 않으며, 이에 따라 실행환경이 실제 디바이스인지 에뮬레이터인지 정확하게 판별해 낼 수 있다. 따라서, 단계 S204에서 판단한 결과를 최종 판단 결과로 사용할 수 있다.

단계 S205에서는 상기 1차 확인 단계(S202)에서 상기 실행환경이 실제 디바이스로 확인되거나, 상기 최종 확인 단계(S204)가 종료되면, 상기 제1 판별모듈 또는 상기 제2 판별모듈에 의해서 수정된 주소의 명령어를 상기 제1 판별모듈의 실행 전 상태로 복원한다.

단계 S202의 1차 확인 단계에서 실제 디바이스로 확인된 경우에는 컨텍스트 스위칭의 여부와 관계없이 실제 디바이스에서 실행되었음을 확인할 수 있기 때문에, 추가로 판별을 수행하지 않게 되고, 에뮬레이터로 판별된 경우에는 추가로 제2 판별모듈을 수행한 이후에 최종확인을 진행한다. 이와 같이 최종적으로 확인이 완료되면 완료된 결과를 이용하여 정해진 마무리 작업을 수행해야 한다.

단계 S205에서 수행하는 마무리 작업은 기본적으로 실행환경을 판별하기 이전(단계 S201이 시작되기 이전)의 상태로 프로세서의 상태를 복원하는 것이다. 복원을 위해서는 레지스터나 메모리 등에 제1 판별모듈 실행 전에 저장되어 있던 데이터를 백업하고, 이를 판별 이후에 복원하도록 하는 것이 가장 기본적인 방법이다.

단계 S205에서 이와 같이 복원작업을 수행하게 되면, 어플리케이션의 여러 루틴들 사이사이에 본 발명의 에뮬레이팅 판별 방법을 수행하는 코드들이 삽입되더라도, 어플리케이션의 기능에 영향을 주지 않고, 어플리케이션이 안전한 상황에서만 실행될 수 있도록 제어하는 것이 가능하다. 만일 S205에서 수행하는 복원작업이 없다면, 이와 같은 판별이 진행된 이후에 프로세서의 상태가 달라지기 때문에, 판별코드는 기존 어플리케이션의 루틴과는 다른 별도의 스레드 혹은 별도의 함수에서 실행되어야 한다.

하지만, 단계 S205에서 이와 같이 판별코드를 실행하기 이전의 상태로 복구하는 것이 가능하기 때문에, 어플리케이션의 중간중간에 판별코드를 삽입하고, 이를 통해 안전하게 어플리케이션을 관리할 수 있다. 특히, 동일한 판별코드를 여러 곳에서 반복 사용하는 것도 가능하여, 어려운 작업 없이도 필요한 곳에서 실행환경을 확인할 수 있다.

단계 S205에서 수행하는 마무리 작업은 이 밖에도 실행환경의 판별 이유에 따라서 여러 가지가 있을 수 있다. 예를 들어, 판별 결과, 실행환경이 실제 디바이스가 아니라 에뮬레이터인 것으로 판별된다면, 어플리케이션이 역공학에 노출되거나 어플리케이션의 주요 정보들이 유출될 우려가 있기 때문에, 어플리케이션의 실행을 중단하거나 종료하도록 하는 것이 가능하다. 이를 통해 안전한 환경에서만 어플리케이션이 동작하도록 할 수 있다.

도 2에 도시된 에뮬레이팅 탐지 방법은 소스코드로 구현되어 동작할 수 있는데, 어플리케이션의 안전한 실행을 위하여, 어플리케이션의 소스코드 또는 바이너리 코드의 중간에 해당 소스코드의 내용을 삽입함으로써, 어플리케이션을 안전하게 관리할 수 있다. 소스코드를 삽입하는 것은 바이너리를 수정하거나, 어플리케이션이 소스코드를 컴파일 하는 과정에서 에뮬레이팅 탐지 소스코드를 삽입하여 컴파일하도록 하는 등 다양한 실시예가 가능하다.

도 4는 본 발명의 다른 실시예에 다른 에뮬레이팅 탐지 방법을 나타낸 동작 흐름도이다.

도면에 도시한 바와 같이 본 발명의 일실시예에 따른 에뮬레이팅 탐지 방법은 어플리케이션 코드 또는 바이너리를 수신하는 단계(S401), 에뮬레이팅 탐지 코드를 포함시키는 단계(S402) 및 어플리케이션 실행 바이너리를 생성하는 단계(S403)를 포함하여 구성될 수 있다.

단계 S401에서는 어플리케이션의 기능을 수행하는 코드 또는 바이너리를 수신한다. 본 발명에서는 일반적으로 작성된 어플리케이션을 에뮬레이팅 환경을 탐지하여 안전하게 실행될 수 있도록 하는 어플리케이션으로 변경함으로써, 에뮬레이팅 탐지가 가능하도록 한 것이다. 이 때, 어플리케이션은 일반적으로 PC, 모바일 등에서 사용되는 매우 다양한 형태의 어플리케이션을 포함할 수 있다. 그런데, 이와 같이 다양한 어플리케이션을 다양한 제작자가 만들 때에, 본 발명의 코드를 적용하여 만들도록 한다면, 많은 시간과 노력이 소요될 수 밖에 없다.

따라서, 단계 S401에서는 기존의 방식에 의해 개발이 완료된 어플리케이션의 소스코드 또는 바이너리를 수신하도록 한다. 단계 S401에서 수신하는 소스코드 또는 바이너리에는 본 발명에 따른 에뮬레이팅 탐지 기술이 적용되지 않은 것이므로, 일반 어플리케이션을 개발하는 개발자 입장에서는 이와 같은 에뮬레이팅 탐지 기능에 대해 고민할 필요 없이 기능만을 구현하도록 할 수 있어, 어플리케이션 개발 효율을 극대화할 수 있다.

단계 S402에서는 단계 S401에서 수신한 소스코드 또는 바이너리에 포함된 상기 어플리케이션의 기능을 수행하는 루틴 중 적어도 하나의 루틴 앞에 상기 어플리케이션의 실행환경이 에뮬레이터인지 여부를 확인하는 에뮬레이팅 탐지 코드를 포함시킨다.

어플리케이션은 각각 기능을 실행하는 복수의 루틴으로 구성되어 있는데, 본 발명의 에뮬레이팅 탐지 코드는 앞서 살펴본 바와 같이, 주변의 루틴에 영향을 주지 않고 에뮬레이팅 탐지가 가능하기 때문에, 어플리케이션의 여러 루틴들 중간중간에 삽입될 수 있다.

이 때, 어플리케이션의 모든 루틴의 앞에 에뮬레이팅 탐지 코드가 들어가면 불필요한 리소스를 소비하게 될 수 있으므로, 역공학을 방지하고 보안을 유지해야 하는 중요한 루틴을 선정하고, 선정된 루틴의 앞에서 에뮬레이팅 탐지 코드가 동작하도록 하며, 에뮬레이팅 환경인 경우에는 해당 루틴이 실행되지 않도록 하여, 보다 안전한 어플리케이션을 준비하는 것이 가능하다.

단계 S402에서 포함시키는 에뮬레이팅 탐지 코드는 아래와 같은 코드를 포함하여 구성될 수 있다. 에뮬레이팅 탐지 코드에는 도 2에서 설명한 에뮬레이팅 탐지 방법을 수행할 수 있는 다양한 기술이 적용될 수 있으며, 아래 설명하는 내용 이외에도 도 2에서 설명된 내용들이 단계 S402에서 포함시키는 에뮬레이팅 탐지 코드에 포함될 수 있다.

단계 S402에서 포함시키는 에뮬레이팅 탐지 코드는 명령어 캐시를 이용하여 명령어를 실행하는 복수의 인스트럭션(Instruction)을 포함하는 제1 판별코드를 포함한다. 이 때, 제1 판별코드는 복수의 인스트럭션을 포함하는데, 이 복수의 인스트럭션은 (1) 특정 주소에 명령어를 캐싱하는 인스트럭션, (2) 상기 캐싱된 주소의 명령어를 수정하는 인스트럭션, (3) 상기 캐싱된 주소의 명령어를 실행하는 인스트럭션을 포함하여 구성될 수 있다. 즉, 명령어 캐시에 명령어를 캐싱한 뒤 캐싱된 주소의 명령어를 수정하고 이를 다시 실행시킴으로써, 실제 디바이스에서의 결과와 에뮬레이터에서의 결과가 다르게 도출될 수 있도록 한다.

단계 S402에서 포함시키는 에뮬레이팅 탐지 코드는 또한 상기 제1 판별모듈의 실행이 종료된 후 레지스터의 값을 확인하여 실행환경이 실제 디바이스인지 에뮬레이터인지 확인하는 확인 코드를 포함한다. 상기 제1 판별코드는 앞서 살펴본 바와 같이, 실제 디바이스인 경우와 에뮬레이터인 경우에 각각 레지스터에 다른 결과를 기록하도록 하는 모듈이다. 따라서, 제1 판별모듈의 실행 종료 후 레지스터의 값을 확인하면, 실행환경이 실제 디바이스인지 에뮬레이터인지 구분할 수 있다.

상기 확인 코드에서 확인한 결과 실행환경이 실제 디바이스로 확인되는 경우, 앞서 살펴본 바와 같이, 실제 디바이스임이 명확하기 때문에, 이 경우에는 추가적으로 판단할 필요 없이 에뮬레이팅 탐지를 마무리한다. 그러나, 실행환경이 에뮬레이터로 확인되는 경우에는 제1 판별코드가 실행되는 중간에 컨텍스트 스위칭이 일어났는지 여부에 따라서, 결과가 달라질 수 있기 때문에, 다음 코드로 이동하여 추가 확인을 하게 된다.

단계 S402에서 포함시키는 에뮬레이팅 탐지 코드는 상기 확인 결과 상기 실행환경이 에뮬레이터인 것으로 확인되는 경우, 상기 명령어 캐시를 이용하여 명령어를 실행하는 복수의 인스트럭션을 포함하는 제2 판별코드를 포함한다.

상기 제2 판별코드는 상술한 제1 판별코드와 마찬가지로 복수의 인스트럭션을 포함하는데, 제1 판별모듈과 동일한 형태로 구성될 수 있다. 그러나, 보다 정확한 판단이 가능하도록 하고 우회 가능성을 최소화하기 위하여 제1 판별모듈과 제2 판별모듈은 서로 다른 방식으로 구현되는 것이 보다 바람직하다.

상기 제2 판별코드는 제1 판별코드가 종료된 이후 바로 시작된다. 따라서, 제2 판별코드를 구성하는 인스트럭션의 개수가 소정의 기준치보다 적게 구성되는 경우에는 제1 판별코드의 수행 중에 컨텍스트 스위칭이 일언서 제대로 판별이 되지 않은 경우에도 제2 판별코드에서 컨텍스트 스위칭 없이 정확한 결과를 얻을 수 있다.

따라서, 상기 제2 판별코드는 소정의 기준치보다 적은 수의 인스트럭션으로 구성되어야 한다. 상기 소정의 기준치는 하버드 아키텍처 프로세서의 특성에 따라 결정되는 것이 바람직하다.

보다 상세하게 살펴보면, 제2 판별코드의 인스트럭션 수를 제한하는 기준치는 하기의 수학식에 의해 결정되는 것이 바람직하다.

[수학식]

기준치 = 상기 하버드 아키텍처 프로세서의 코어성능 / 상기 하버드 아키텍처 프로세서의 명령어당 평균 클럭수 / 상기 하버드 아키텍처 프로세서의 최대 프로세스 개수 / 상기 하버드 아키텍처 프로세서의 초당 전체 프로세스 리사이클 횟수

단계 S402에서 포함시키는 에뮬레이팅 탐지 코드는 상기 제2 판별코드의 실행이 종료된 후 레지스터의 값을 확인하여 실행환경이 실제 디바이스인지 에뮬레이터인지 확인하는 최종 확인한다. 1차 확인 코드에서 1차 확인과 동일한 형태로, 제2 판별코드를 실행한 이후에 레지스터에 저장되는 값을 확인하는 것으로 실행환경이 실제 디바이스인지 에뮬레이터인지 확인할 수 있다.

최종 확인 코드에서 수행되는 최종 확인은 1차 확인 코드에서와는 달리 컨텍스트 스위칭의 영향을 받지 않으며, 이에 따라 실행환경이 실제 디바이스인지 에뮬레이터인지 정확하게 판별해 낼 수 있다.

단계 S402에서 포함시키는 에뮬레이팅 탐지 코드는 상기 1차 확인 코드에서 상기 실행환경이 실제 디바이스로 확인되거나, 상기 최종 확인 코드가 종료되면, 상기 제1 판별코드 또는 상기 제2 판별코드에 의해서 수정된 상기 명령어 캐시를 상기 제1 판별코드의 실행 전 상태로 복원하는 복원 코드를 포함한다.

상기 복원 코드에서 수행하는 마무리 작업은 기본적으로 실행환경을 판별하기 이전의 상태로 프로세서의 상태를 복원하는 것이다. 복원을 위해서는 레지스터나 메모리 등에 제1 판별코드 실행 전에 저장되어 있던 데이터를 백업하고, 이를 판별 이후에 복원하도록 하는 것이 가장 기본적인 방법이다.

단계 S403에서는 상기 에뮬레이팅 탐지 코드를 포함한 어플리케이션의 실행 바이너리를 생성한다. 여기서 실행 바이너리라고 하는 것은 디바이스에서 어플리케이션을 바로 실행할 수 있도록 하는 바이너리뿐 아니라, 실행할 수 있도록 설치하는 바이너리를 포함한다.

이처럼 단계 S403에서 에뮬레이팅 탐지 코드를 포함한 어플리케이션의 실행 바이너리를 생성함으로써, 어플리케이션 개발자가 별도의 에뮬레이팅 탐지를 위한 코드를 개발할 필요 없이 안전한 어플리케이션을 개발하고 공급하는 것이 가능하게 된다.

도 5은 본 발명의 일실시예에 따른 에뮬레이팅 탐지 코드의 일례를 도시한 도면이다.

도면의 에뮬레이팅 탐지 코드 중 0x100부터 0x114까지가 제1 탐지모듈 또는 제1 탐지코드에 해당하는 코드이며, 0x118부터 0x11C까지가 1차 확인 모듈 또는 1차 확인 코드에 해당하는 코드이고, 0x120부터 0x130까지가 제2 탐지모듈 또는 제2 탐지코드에 해당하는 코드이고, 0x134의 Finalizing code는 최종 확인과 복원을 실행하는 코드를 의미한다.

도면에서 Unsafety Zone으로 표시된 부분은 컨텍스트 스위칭의 영향을 받아 결과값을 신뢰하기 어려운 부분이며, Safety Zone은 제2 탐지모듈의 인스트럭션 개수가 크지 않다면 컨텍스트 스위칭의 영향을 받지 않기 때문에 안전하게 탐지 가능한 부분이다.

이는 하나의 실시예를 나타내는 것으로 디바이스의 특성, 어플리케이션의 특성 등을 고려하여 다양한 형태의 탐지코드를 구현하는 것이 가능하며, 본 발명은 그 구체적인 구현 방법에 의해 제한되지 않는다.

도 6는 본 발명의 일실시예에 따른 에뮬레이팅 탐지 방법에 따라 어플리케이션 바이너리를 생성하는 일례를 도시한 도면이다.

도면에 도시한 바와 같이, 본 발명의 에뮬레이팅 탐지 방법은 에뮬레이팅 탐지 기능이 포함되지 않은 일반 어플리케이션의 소스코드 또는 바이너리를 입력 데이터로 수신하고, 여기에 에뮬레이팅 탐지 코드를 포함시켜, 최종 바이너리를 생성하는 형태로 구현된다.

이 때, 어플리케이션의 소스코드에 에뮬레이팅 탐지 코드를 포함시키는 기능은 일반적인 어플리케이션의 컴파일러에 포함되어 구현되는 것이 가능한데, 어플리케이션은 기존 방식으로 개발하고 컴파일러만 본 발명이 적용된 컴파일러를 사용함으로써, 안전한 어플리케이션의 개발이 가능하도록 하여 효율적으로 본 발명을 적용할 수 있다.

또한, 어플리케이션 바이너리를 수신하여 에뮬레이팅 탐지 코드를 포함시키는 것은 바이너리 자체를 수정하여 새로운 바이너리를 생성하는 바이너리 수정 기법이 사용될 수 있는데, 이 경우에는 어플리케이션에 바이너리 수정이 어렵도록 하는 다른 보안장치가 마련되어 있는 경우 적용이 어려울 수도 있다. 구체적인 바이너리 수정 방법 등은 통상의 지식을 가진 자가 다양한 형태로 개발 가능하며 이 구체적인 방법에 의해 본 발명이 제한되지는 않는다.

도 7는 본 발명의 일실시예에 따른 에뮬레이팅 탐지 시스템(701)의 내부 구성을 도시한 구성도이다.

도면에 도시한 바와 같이, 본 발명의 에뮬레이팅 탐지 시스템(701)은 어플리케이션 수신부(710), 어플리케이션 수정부(720) 및 바이너리 생성부(730)를 포함하여 구성될 수 있다. 본 발명의 에뮬레이팅 탐지 시스템(701)의 주요 구성은 상술한 에뮬레이팅 탐지 방법에 설명된 내용을 모두 포함할 수 있으며, 아래에 구체적으로 서술하지 않았더라도, 위의 에뮬레이팅 탐지 방법에서 설명한 다양한 구성이 적용 가능하다.

어플리케이션 수신부(710)는 어플리케이션의 기능을 수행하는 코드 또는 바이너리를 수신한다. 본 발명에서는 일반적으로 작성된 어플리케이션을 에뮬레이팅 환경을 탐지하여 안전하게 실행될 수 있도록 하는 어플리케이션으로 변경함으로써, 에뮬레이팅 탐지가 가능하도록 한 것이다. 이 때, 어플리케이션은 일반적으로 PC, 모바일 등에서 사용되는 매우 다양한 형태의 어플리케이션을 포함할 수 있다. 그런데, 이와 같이 다양한 어플리케이션을 다양한 제작자가 만들 때에, 본 발명의 코드를 적용하여 만들도록 한다면, 많은 시간과 노력이 소요될 수 밖에 없다.

따라서, 어플리케이션 수신부(710)는 기존의 방식에 의해 개발이 완료된 어플리케이션의 소스코드 또는 바이너리를 수신하도록 한다. 단계 S401에서 수신하는 소스코드 또는 바이너리에는 본 발명에 따른 에뮬레이팅 탐지 기술이 적용되지 않은 것이므로, 일반 어플리케이션을 개발하는 개발자 입장에서는 이와 같은 에뮬레이팅 탐지 기능에 대해 고민할 필요 없이 기능만을 구현하도록 할 수 있어, 어플리케이션 개발 효율을 극대화할 수 있다.

어플리케이션 수정부(720)에서는 어플리케이션 수신부(710)에서 수신한 소스코드 또는 바이너리에 포함된 상기 어플리케이션의 기능을 수행하는 루틴 중 적어도 하나의 루틴 앞에 상기 어플리케이션의 실행환경이 에뮬레이터인지 여부를 확인하는 에뮬레이팅 탐지 코드를 포함시킨다.

어플리케이션은 각각 기능을 실행하는 복수의 루틴으로 구성되어 있는데, 본 발명의 에뮬레이팅 탐지 코드는 앞서 살펴본 바와 같이, 주변의 루틴에 영향을 주지 않고 에뮬레이팅 탐지가 가능하기 때문에, 어플리케이션의 여러 루틴들 중간중간에 삽입될 수 있다.

이 때, 어플리케이션의 모든 루틴의 앞에 에뮬레이팅 탐지 코드가 들어가면 불필요한 리소스를 소비하게 될 수 있으므로, 역공학을 방지하고 보안을 유지해야 하는 중요한 루틴을 선정하고, 선정된 루틴의 앞에서 에뮬레이팅 탐지 코드가 동작하도록 하며, 에뮬레이팅 환경인 경우에는 해당 루틴이 실행되지 않도록 하여, 보다 안전한 어플리케이션을 준비하는 것이 가능하다.

어플리케이션 수정부(720)에서 포함시키는 에뮬레이팅 탐지 코드는 아래와 같은 코드를 포함하여 구성될 수 있다. 에뮬레이팅 탐지 코드에는 도 2에서 설명한 에뮬레이팅 탐지 방법을 수행할 수 있는 다양한 기술이 적용될 수 있으며, 아래 설명하는 내용 이외에도 도 2에서 설명된 내용들이 어플리케이션 수정부(720)에서 포함시키는 에뮬레이팅 탐지 코드에 포함될 수 있다.

어플리케이션 수정부(720)에서 포함시키는 에뮬레이팅 탐지 코드는 명령어 캐시를 이용하여 명령어를 실행하는 복수의 인스트럭션(Instruction)을 포함하는 제1 판별코드를 포함한다. 이 때, 제1 판별코드는 복수의 인스트럭션을 포함하는데, 이 복수의 인스트럭션은 (1) 특정 주소에 명령어를 캐싱하는 인스트럭션, (2) 상기 캐싱된 주소의 명령어를 수정하는 인스트럭션, (3) 상기 캐싱된 주소의 명령어를 실행하는 인스트럭션을 포함하여 구성될 수 있다. 즉, 명령어 캐시에 명령어를 캐싱한 뒤 캐싱된 명령어를 수정하고 이를 다시 실행시킴으로써, 실제 디바이스에서의 결과와 에뮬레이터에서의 결과가 다르게 도출될 수 있도록 한다.

어플리케이션 수정부(720)에서 포함시키는 에뮬레이팅 탐지 코드는 또한 상기 제1 판별모듈의 실행이 종료된 후 레지스터의 값을 확인하여 실행환경이 실제 디바이스인지 에뮬레이터인지 확인하는 확인 코드를 포함한다. 상기 제1 판별코드는 앞서 살펴본 바와 같이, 실제 디바이스인 경우와 에뮬레이터인 경우에 각각 레지스터에 다른 결과를 기록하도록 하는 모듈이다. 따라서, 제1 판별모듈의 실행 종료 후 레지스터의 값을 확인하면, 실행환경이 실제 디바이스인지 에뮬레이터인지 구분할 수 있다.

상기 확인 코드에서 확인한 결과 실행환경이 실제 디바이스로 확인되는 경우, 앞서 살펴본 바와 같이, 실제 디바이스임이 명확하기 때문에, 이 경우에는 추가적으로 판단할 필요 없이 에뮬레이팅 탐지를 마무리한다. 그러나, 실행환경이 에뮬레이터로 확인되는 경우에는 제1 판별코드가 실행되는 중간에 컨텍스트 스위칭이 일어났는지 여부에 따라서, 결과가 달라질 수 있기 때문에, 다음 코드로 이동하여 추가 확인을 하게 된다.

어플리케이션 수정부(720)에서 포함시키는 에뮬레이팅 탐지 코드는 상기 확인 결과 상기 실행환경이 에뮬레이터인 것으로 확인되는 경우, 상기 명령어 캐시를 이용하여 명령어를 실행하는 복수의 인스트럭션을 포함하는 제2 판별코드를 포함한다.

상기 제2 판별코드는 상술한 제1 판별코드와 마찬가지로 복수의 인스트럭션을 포함하는데, 제1 판별모듈과 동일한 형태로 구성될 수 있다. 그러나, 보다 정확한 판단이 가능하도록 하고 우회 가능성을 최소화하기 위하여 제1 판별모듈과 제2 판별모듈은 서로 다른 방식으로 구현되는 것이 보다 바람직하다.

상기 제2 판별코드는 제1 판별코드가 종료된 이후 바로 시작된다. 따라서, 제2 판별코드를 구성하는 인스트럭션의 개수가 소정의 기준치보다 적게 구성되는 경우에는 제1 판별코드의 수행 중에 컨텍스트 스위칭이 일언서 제대로 판별이 되지 않은 경우에도 제2 판별코드에서 컨텍스트 스위칭 없이 정확한 결과를 얻을 수 있다.

따라서, 상기 제2 판별코드는 소정의 기준치보다 적은 수의 인스트럭션으로 구성되어야 한다. 상기 소정의 기준치는 하버드 아키텍처 프로세서의 특성에 따라 결정되는 것이 바람직하다.

보다 상세하게 살펴보면, 제2 판별코드의 인스트럭션 수를 제한하는 기준치는 하기의 수학식에 의해 결정되는 것이 바람직하다.

[수학식]

기준치 = 상기 하버드 아키텍처 프로세서의 코어성능 / 상기 하버드 아키텍처 프로세서의 명령어당 평균 클럭수 / 상기 하버드 아키텍처 프로세서의 최대 프로세스 개수 / 상기 하버드 아키텍처 프로세서의 초당 전체 프로세스 리사이클 횟수

어플리케이션 수정부(720)에서 포함시키는 에뮬레이팅 탐지 코드는 상기 제2 판별코드의 실행이 종료된 후 레지스터의 값을 확인하여 실행환경이 실제 디바이스인지 에뮬레이터인지 확인하는 최종 확인한다. 1차 확인 코드에서 1차 확인과 동일한 형태로, 제2 판별코드를 실행한 이후에 레지스터에 저장되는 값을 확인하는 것으로 실행환경이 실제 디바이스인지 에뮬레이터인지 확인할 수 있다.

최종 확인 코드에서 수행되는 최종 확인은 1차 확인 코드에서와는 달리 컨텍스트 스위칭의 영향을 받지 않으며, 이에 따라 실행환경이 실제 디바이스인지 에뮬레이터인지 정확하게 판별해 낼 수 있다.

어플리케이션 수정부(720)에서 포함시키는 에뮬레이팅 탐지 코드는 상기 1차 확인 코드에서 상기 실행환경이 실제 디바이스로 확인되거나, 상기 최종 확인 코드가 종료되면, 상기 제1 판별코드 또는 상기 제2 판별코드에 의해서 수정된 상기 명령어 캐시를 상기 제1 판별코드의 실행 전 상태로 복원하는 복원 코드를 포함한다.

상기 복원 코드에서 수행하는 마무리 작업은 기본적으로 실행환경을 판별하기 이전의 상태로 프로세서의 상태를 복원하는 것이다. 복원을 위해서는 레지스터나 메모리 등에 제1 판별코드 실행 전에 저장되어 있던 데이터를 백업하고, 이를 판별 이후에 복원하도록 하는 것이 가장 기본적인 방법이다.

바이너리 생성부(730)는 상기 에뮬레이팅 탐지 코드를 포함한 어플리케이션의 실행 바이너리를 생성한다. 여기서 실행 바이너리라고 하는 것은 디바이스에서 어플리케이션을 바로 실행할 수 있도록 하는 바이너리뿐 아니라, 실행할 수 있도록 설치하는 바이너리를 포함한다.

이처럼 바이너리 생성부(730)에서 에뮬레이팅 탐지 코드를 포함한 어플리케이션의 실행 바이너리를 생성함으로써, 어플리케이션 개발자가 별도의 에뮬레이팅 탐지를 위한 코드를 개발할 필요 없이 안전한 어플리케이션을 개발하고 공급하는 것이 가능하게 된다.

본 발명의 에뮬레이팅 탐지 방법은 프로그램 명령어의 형태로 구현되어 컴퓨터 판독 가능한 기록매체에 저장되어 사용될 수 있다.

컴퓨터 판독 가능한 기록 매체의 예에는, 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체, CDROM, DVD 와 같은 광기록 매체, 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical media), 및 ROM, RAM, 플래시 메모리 등과 같은 프로그램 명령어를 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다.

프로그램 명령어의 예에는, 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드도 포함된다. 상기 하드웨어 장치는 본 발명에 따른 처리를 수행하기 위해 하나 이상의 소프트웨어 모듈로서 작동하도록 구성될 수 있으며, 그 역도 마찬가지이다.

이상에서와 같이 본 발명에 따른 에뮬레이팅 탐지 방법 및 에뮬레이팅 탐지 시스템은 상기한 바와 같이 설명된 실시예들의 구성과 방법이 한정되게 적용될 수 있는 것이 아니라, 상기 실시예들은 다양한 변형이 이루어질 수 있도록 각 실시예들의 전부 또는 일부가 선택적으로 조합되어 구성될 수도 있다.

710: 어플리케이션 수신부
720: 어플리케이션 수정부
730: 바이너리 생성부

Claims (18)

1. 명령어 캐시(I-Cache)와 데이터 캐시(D-Cache)를 포함하는 하버드 아키텍처 프로세서에서 에뮬레이팅을 탐지하는 방법에 있어서,
   상기 명령어 캐시를 이용하여 명령어를 실행하는 복수의 인스트럭션(Instruction)을 포함하는 제1 판별모듈을 실행하는 단계;
   상기 제1 판별모듈의 실행이 종료된 후 레지스터의 값을 확인하여 실행환경이 실제 디바이스인지 에뮬레이터인지 확인하는 1차 확인 단계;
   상기 확인 결과 상기 실행환경이 에뮬레이터인 것으로 확인되는 경우, 상기 명령어 캐시를 이용하여 명령어를 실행하는 복수의 인스트럭션을 포함하는 제2 판별모듈을 실행하는 단계; 및
   상기 제2 판별모듈의 실행이 종료된 후 레지스터의 값을 확인하여 실행환경이 실제 디바이스인지 에뮬레이터인지 확인하는 최종 확인 단계
   를 포함하는 에뮬레이팅 탐지 방법.
2. 제1항에 있어서,
   상기 제2 판별모듈은 상기 하버드 아키텍처 프로세서의 특성에 따라 결정되는 소정의 기준치보다 적은 수의 인스트럭션으로 구성되는 것
   을 특징으로 하는 에뮬레이팅 탐지 방법.
3. 제2항에 있어서,
   상기 기준치는 하기의 수학식에 의하여 결정되는 것
   을 특징으로 하는 에뮬레이팅 탐지 방법.
   [수학식]
   기준치 = 상기 하버드 아키텍처 프로세서의 코어성능 / 상기 하버드 아키텍처 프로세서의 명령어당 평균 클럭수 / 상기 하버드 아키텍처 프로세서의 최대 프로세스 개수 / 상기 하버드 아키텍처 프로세서의 초당 전체 프로세스 리사이클 횟수
4. 제1항에 있어서,
   상기 1차 확인 단계에서 상기 실행환경이 실제 디바이스로 확인되거나, 상기 최종 확인 단계가 종료되면, 상기 제1 판별모듈 또는 상기 제2 판별모듈에 의해서 수정된 상기 명령어 캐시를 상기 제1 판별모듈의 실행 전 상태로 복원하는 단계
   를 더 포함하는 에뮬레이팅 탐지 방법.
5. 제1항에 있어서,
   상기 제1 판별모듈은
   특정 주소의 명령어를 캐싱하는 인스트럭션;
   상기 캐싱된 주소의 명령어를 수정하는 인스트럭션; 및
   상기 캐싱된 주소의 명령어를 실행하는 인스트럭션
   을 포함하는 에뮬레이팅 탐지 방법.
6. 명령어 캐시(I-Cache)와 데이터 캐시(D-Cache)를 포함하는 하버드 아키텍처 프로세서에서 동작하는 어플리케이션에서 에뮬레이팅을 탐지하는 방법에 있어서,
   상기 어플리케이션의 기능을 수행하는 코드 또는 바이너리를 수신하는 단계;
   상기 수신한 코드 또는 바이너리에 포함된 상기 어플리케이션의 기능을 수행하는 루틴 중 적어도 하나의 루틴 앞에 상기 어플리케이션의 실행 환경이 에뮬레이터인지 여부를 확인하는 에뮬레이팅 탐지 코드를 포함시키는 단계; 및
   상기 에뮬레이팅 탐지 코드를 포함한 상기 어플리케이션의 실행 바이너리를 생성하는 단계
   를 포함하는 에뮬레이팅 탐지 방법.
7. 제6항에 있어서,
   상기 에뮬레이팅 탐지 코드는
   상기 명령어 캐시를 이용하여 명령어를 실행하는 복수의 인스트럭션(Instruction)을 포함하는 제1 판별 코드;
   상기 제1 판별 코드의 실행이 종료된 후 레지스터의 값을 확인하여 실행환경이 실제 디바이스인지 에뮬레이터인지 확인하는 1차 확인 코드;
   상기 확인 결과 상기 실행환경이 에뮬레이터인 것으로 확인되는 경우, 상기 명령어 캐시를 이용하여 명령어를 실행하는 복수의 인스트럭션을 포함하는 제2 판별 코드; 및
   상기 제2 판별 코드의 실행이 종료된 후 레지스터의 값을 확인하여 실행환경이 실제 디바이스인지 에뮬레이터인지 확인하는 최종 확인 코드
   를 포함하는 것을 특징으로 하는 에뮬레이팅 탐지 방법.
8. 제7항에 있어서,
   상기 제2 판별코드는 상기 하버드 아키텍처 프로세서의 특성에 따라 결정되는 소정의 기준치보다 적은 수의 인스트럭션으로 구성되는 것
   을 특징으로 하는 에뮬레이팅 탐지 방법.
9. 제8항에 있어서,
   상기 기준치는 하기의 수학식에 의하여 결정되는 것
   을 특징으로 하는 에뮬레이팅 탐지 방법.
   [수학식]
   기준치 = 상기 하버드 아키텍처 프로세서의 코어성능 / 상기 하버드 아키텍처 프로세서의 명령어당 평균 클럭수 / 상기 하버드 아키텍처 프로세서의 최대 프로세스 개수 / 상기 하버드 아키텍처 프로세서의 초당 전체 프로세스 리사이클 횟수
10. 제7항에 있어서,
    상기 에뮬레이팅 탐지 코드는
    상기 1차 확인 코드에서 상기 실행환경이 실제 디바이스로 확인되거나, 상기 최종 확인 단계가 종료되면, 상기 제1 판별코드 또는 상기 제2 판별코드에 의해서 수정된 상기 명령어 캐시를 상기 제1 판별코드의 실행 전 상태로 복원하는 복원 코드
    를 더 포함하는 에뮬레이팅 탐지 방법.
11. 제7항에 있어서,
    상기 제1 판별 코드는
    특정 주소의 명령어를 캐싱하는 인스트럭션;
    상기 캐싱된 주소의 명령어를 수정하는 인스트럭션; 및
    상기 캐싱된 주소의 명령어를 실행하는 인스트럭션
    을 포함하는 에뮬레이팅 탐지 방법.
12. 제1항 내지 제11항 중 어느 한 항의 방법을 실행하는 프로그램을 기록한 기록매체.
13. 어플리케이션의 기능을 수행하는 코드 또는 바이너리를 수신하는 어플리케이션 수신부;
    상기 수신한 코드 또는 바이너리에 포함된 상기 어플리케이션의 기능을 수행하는 루틴 중 적어도 하나의 루틴 앞에 상기 어플리케이션의 실행 환경이 에뮬레이터인지 여부를 확인하는 에뮬레이팅 탐지 코드를 포함시키는 어플리케이션 수정부; 및
    상기 에뮬레이팅 탐지 코드를 포함한 상기 어플리케이션의 실행 바이너리를 생성하는 바이너리 생성부
    를 포함하는 에뮬레이팅 탐지 시스템.
14. 제13항에 있어서,
    상기 에뮬레이팅 탐지 코드는
    명령어 캐시를 이용하여 명령어를 실행하는 복수의 인스트럭션(Instruction)을 포함하는 제1 판별 코드;
    상기 제1 판별 코드의 실행이 종료된 후 레지스터의 값을 확인하여 실행환경이 실제 디바이스인지 에뮬레이터인지 확인하는 1차 확인 코드;
    상기 확인 결과 상기 실행환경이 에뮬레이터인 것으로 확인되는 경우, 상기 명령어 캐시를 이용하여 명령어를 실행하는 복수의 인스트럭션을 포함하는 제2 판별 코드; 및
    상기 제2 판별 코드의 실행이 종료된 후 레지스터의 값을 확인하여 실행환경이 실제 디바이스인지 에뮬레이터인지 확인하는 최종 확인 코드
    를 포함하는 것을 특징으로 하는 에뮬레이팅 탐지 시스템.
15. 제14항에 있어서,
    상기 제2 판별코드는 하버드 아키텍처 프로세서의 특성에 따라 결정되는 소정의 기준치보다 적은 수의 인스트럭션으로 구성되는 것
    을 특징으로 하는 에뮬레이팅 탐지 시스템.
16. 제15항에 있어서,
    상기 기준치는 하기의 수학식에 의하여 결정되는 것
    을 특징으로 하는 에뮬레이팅 탐지 시스템.
    [수학식]
    기준치 = 상기 하버드 아키텍처 프로세서의 코어성능 / 상기 하버드 아키텍처 프로세서의 명령어당 평균 클럭수 / 상기 하버드 아키텍처 프로세서의 최대 프로세스 개수 / 상기 하버드 아키텍처 프로세서의 초당 전체 프로세스 리사이클 횟수
17. 제14항에 있어서,
    상기 에뮬레이팅 탐지 코드는
    상기 1차 확인 코드에서 상기 실행환경이 실제 디바이스로 확인되거나, 상기 최종 확인 단계가 종료되면, 상기 제1 판별코드 또는 상기 제2 판별코드에 의해서 수정된 상기 명령어 캐시를 상기 제1 판별코드의 실행 전 상태로 복원하는 복원 코드
    를 더 포함하는 에뮬레이팅 탐지 시스템.
18. 제14항에 있어서,
    상기 제1 판별 코드는
    특정 주소의 명령어를 캐싱하는 인스트럭션;
    상기 캐싱된 주소의 명령어를 수정하는 인스트럭션; 및
    상기 캐싱된 주소의 명령어를 실행하는 인스트럭션
    을 포함하는 에뮬레이팅 탐지 시스템.

Images