메타모픽 엔진의 핵심, 코드 교환의 원리

메타모픽 엔진의 핵심, 코드 교환의 원리
by 신영진(YoungJin Shin), codewiz at gmail.com, @codemaru, http://www.jiniya.net

소개
코드 교환은 메타모픽(metamorphic) 엔진 제작의 핵심 방법 중의 하나다. 코드 교환이 무엇인지에 대해서 살펴보고 코드 교환을 구현하기 위해서 필요한 핵심 자료 구조와 어떤 논리를 통해서 구현할 수 있는지에 대해서 알아본다.

연재 가이드
운영체제: 윈도우 2000/XP
개발도구: Visual Studio 2005
기초지식: C/C++, Win32 API, Assembly
응용분야: 보안 프로그램

필자소개
신영진 pop@jiniya.net, http://www.jiniya.net
웰비아닷컴을 창업해 XIGNCODE3라는 게임보안 제품을 개발하고 있다. 시스템 프로그래밍에 관심이 많고 다수의 PC 보안 프로그램 개발에 참여했다. 월간 마이크로소프트웨어의 오랜 필자이면서 Microsoft MVP, 데브피아 Visual C++섹션 시삽으로 활동하고 있다. Steve Barakatt과 Grey’s Anatomy의 광팬이며, 한때는 WoW에 미쳤었다. 한마디로 평가하자면 괴짜다.

Introduction
변이(mutation)는 바이러스 제작자에게는 참 오래된 화두다. 바이러스 제작자들은 백신을 피하기 위해서 바이러스의 다양한 부분들이 변형되도록 연구했다. 이름을 바꾸었고, 내부에서 사용하는 문자열을 변경했다. 그리고 최근에는 백신의 감시를 피하기 위해서 바이러스 코드를 직접 변형하는 기법들을 사용한다. 변이는 바이러스의 출발점부터 지금까지 존재하는 가장 근본적이면서도 가장 강력한 기술이다. 이렇게 음지에서 연구된 ‘변이’라는 기법이 요즘은 난독화라는 이름으로 속속 바이러스가 아닌 일반 프로그램을 보호하는 용도로도 사용되고 있다. 이런 현상을 보면 정말 극과 극은 통한다는 말이 실감나기도 한다.

프로그램 변형 기법을 설명할 때 흔히 등장하는 용어로 메타모픽(metamorphic)과 폴리모픽(polymorphic)이 있다. 이 둘은 모두 morphic이란 어미에서 볼 수 있듯이 원본 프로그램을 변형시켜 새로운 ‘변이’를 만들어내는 방법을 의미한다. 용어 자체가 워낙 비슷하게 생긴 까닭에 용어의 비슷함만큼이나 그 차이가 불분명하게 여기저기 많이 사용되는 경향이 있다. 잠깐 둘의 차이점을 살펴보고 넘어가도록 하자.

이 두 변형 기법의 가장 근본적인 차이는 원본 회귀 가능성에 있다. 변형 함수를 M, 원본 바이너리를 S, 변형된 바이너리를 D라고 할 때, 이 사이에서는 D = M(S)라는 관계가 성립한다. 여기까지는 메타모픽과 폴리모픽 모두 동일하다. 둘의 차이는 생성된 D에 있다. 만약에 생성된 D로부터 원본 S로 돌아갈 수 있는 역함수 M^-1가 존재한다면 이 변형함수 M은 폴리모픽 함수라 하고, 역함수가 존재하지 않는 변형함수라면 메타모픽 함수라 부른다. 즉, 변형된 바이너리에서 원본을 추출하는 것이 가능하다면 폴리모픽, 불가능하다면 메타모픽이란 이야기다. 메타모픽이 폴리모픽보다는 좀 더 상위의 변형 기법임을 알 수 있다.

메타모픽 엔진을 제작하는 데에는 다양한 기법이 사용된다. 노이즈 삽입, 레지스터 교환, 코드 교환, 등가 코드 치환 등이 그 대표적인 방법들이다. 이 글에서는 이중에서도 코드 교환이란 기법이 무엇인지 알아보고, 그 기능을 구현하기 위해서 우리가 어떤 것들을 고려해야 하는지에 대해서 살펴본다. 이 글의 모든 내용은 “진화하는 코드”에서 논의했던 내용에 기반한 것이기 때문에 해당 내용을 먼저 살펴보는 것이 이 글의 전체 내용을 이해하는데 도움이 될 것 같다 (참고자료 [1]).

코드 교환
컴파일러는 우리가 작성한 소스 코드를 컴퓨터가 실행할 수 있는 기계어로 번역해준다. 이렇게 생성된 프로그램은 결국 CPU가 수행할 수 있는 명령어의 집합으로 이루어져 있다. 간단하게 CPU가 수행할 수 있는 명령어의 종류가 i0부터 i9까지 10개로 이루어져 있다고 가정해보자. 그러면 우리가 만든 프로그램은 i2, i5, i8, i0과 같이 순열의 형태로 표현할 수 있다. 이렇게 표현한 프로그램의 재미있는 특징은 i2, i8, i5, i0과 같이 명령어의 일부 순서를 바꾸어도 결과가 동일한 경우가 있다는 점이다. 이와 같이 결과가 동일하도록 코드 순서를 변경하는 것을 코드 교환이라 부른다.

코드 교환은 바이트 패턴 매칭을 통해서 특정 코드를 찾아내는 기법을 무력화 시키기는 데 탁월한 효과를 가지고 있다. 왜냐하면 코드 교환이 어셈블리어 단계에서 일어나기 때문에 아주 사소한 코드 교환이라고 하더라도 특정 지점의 바이트 순서를 완전히 다른 형태로 변형시키기 때문이다.

코드 교환의 실제 예로는 아래와 같이 두 개의 명령어로 이루어진 간단한 프로그램을 생각해 볼 수 있다. 이 프로그램이 하는 일이라곤 eax에 3을, ecx에 4를 넣는 것이 전부다.

mov eax, 3
mov ecx, 4

이 간단한 프로그램의 신기한 점은 아래 코드와 같이 그 순서를 뒤집어 실행하더라도 결과는 동일하다는 점에 있다.

mov ecx, 4
mov eax, 3

eax에 3을 넣고, ecx에 4를 넣는 일이나 순서를 바꿔서 ecx에 4를 넣고 eax에 3을 넣으나 최종 결과는 eax에는 3이, ecx에는 4가 들어간다는 점에서 100% 동일하다. 이 프로그램의 경우 명령어가 2개로 구성되어 있기 때문에 순서를 변경해서 만들어낼 수 있는 프로그램 또한 2가지 밖에는 없다. 하지만 대상 명령어가 많다면 가지 수는 기하급수적으로 늘어난다. <표 1>에는 순서 변경이 가능한 3개의 명령어로 이루어진 프로그램의 예가 나와있다. 3개의 명령어로 만들어낼 수 있는 가지 수는 3!, 6개가 된다. 우리가 작성하는 고급 언어로 만들어지는 프로그램의 경우 번역된 CPU 명령어 수는 엄청나게 많기 때문에 이러한 방식을 사용해서 만들어 낼 수 있는 동일한 프로그램의 가지 수는 거의 무한대에 가깝다고 할 수 있다.

표 1 코드 교환의 예

원본	변형1	변형2	변형3	변형4	변형5
mov eax, 3 mov ecx, 4 mov edx, 5	mov ecx, 4 mov eax, 3 mov edx, 5	mov edx, 5 mov ecx, 4 mov eax, 3	mov ecx, 4 mov edx, 5 mov eax, 3	mov edx, 5 mov eax, 3 mov ecx, 4	mov eax, 3 mov edx, 5 mov ecx, 4

하지만 이러한 단순한 사실로 너무 좋아하기에는 아직 좀 이르다. 왜냐하면 실제로는 이 문제가 그리 간단하진 않기 때문이다. push 3, push 4라는 두 개의 명령어로 구성된 프로그램을 생각해보자. 이 프로그램은 스택에 순차적으로 3과 4를 집어 넣는다. 이 프로그램의 순서를 바꾸면 push 4, push 3이 된다. 이 경우에는 스택에 4를 넣고 나서 3을 넣는 프로그램이기 때문에 원본 프로그램과는 결과가 180도 다른 프로그램이 돼 버린다. 코드 교환을 적용할 수 없는 것이다.

코드 교환이 어려운 근본 원인이 바로 여기에 있다. 교환을 할 수 있는 경우가 있고, 할 수 없는 경우가 있다는 점이다. 우리는 그것들을 직관적으로 보고 판단할 수 있지만 컴퓨터에게 그것을 어떠한 방식을 통해서 알려주어야 할지 명확하지 않기 때문에 더욱 어렵다. 그렇다면 이제 프로그램으로 어떻게 교환할 수 있는 코드와 교환할 수 없는 코드를 구분할 수 있는지에 대해서 알아보도록 하자.

의존성
코드 교환이 가능한지를 검사하기 위해서 우리가 제일먼저 살펴볼 개념은 의존성이다. 의존성이란 개념을 설명하기에 앞서 이해를 돕기 위해서 우리가 알고 있는 컴퓨터가 실제로 동작하는 원리를 먼저 살펴보도록 해야겠다. 현대 컴퓨터의 이론적 근간은 튜링 머신에서 찾을 수 있다. 튜링 머신은 종이에 적힌 명령어를 읽어 들이면서 그 명령어의 기능에 따라 내부 상태를 참조하고, 또 변경시켜가며 의미 있는 계산을 수행해 나가는 구조로 되어 있다. 현대 컴퓨터에선 이 내부 상태가 CPU 레지스터로, 종이가 메모리로 변경됐을 뿐 계산을 수행해 나가는 방식은 똑같다. 정리해보면 결국 명령어라는 것이 수행하는 일은 내부 상태를 참조하고, 또 내부 상태를 변경하는 일이 라는 점이다. 즉, 기본적으로 모든 명령어는 내부 상태에 대한 사이드 이펙트에 기반해서 동작한다고 볼 수 있다.

이런 관점에서 앞서 소개했던 push 프로그램을 다시 살펴보자. push 프로그램을 분석하기 위해서는 우선 정확하게 push라는 명령어가 어떤 기능을 수행하는지를 알아야 한다. 인텔 매뉴얼에서는 push 명령어의 기능을 다음과 같은 의사 코드로 표현하고 있다 (참고자료 [4]). 실제로는 이것보다 훨씬 어렵게 표시되어 있으나 여기서는 핵심만 간략하게 추려서 표현한 것이다.

ESP ← ESP – 4
[ESP] ← VALUE

이 내용을 살펴보면 push 명령어는 ESP라는 내부 상태를 참조한다. 또한 명령이 수행되는 과정에서 ESP와 변경된 ESP가 가리키는 곳의 내용을 변경한다.

분석한 push 명령어의 기능을 토대로 앞선 push 프로그램을 그림으로 도식화해 보면 <그림 1>과 같은 구조가 된다. 이 그림에서 중요한 포인트는 바로 첫 번째 명령어가 변경한 esp를 두 번째 명령어가 다시 참조를 하고 있다는 점이다. 이렇게 앞의 명령어가 발생시킨 사이드 이펙트가 다음 명령어에 영향을 주는 구조를 두고 우리는 이 두 명령어가 의존성 관계에 있다고 이야기 한다.

그림 1 push 프로그램 구조

반면에 앞서 교환이 가능했던 mov 프로그램의 구조는 <그림 2>에 나와 있는 것처럼 도식화할 수 있다. 여기에서는 첫 번째 mov 명령어가 수정한 eax 값이 두 번째 명령어의 실행에 어떠한 영향도 미치지 않기 때문에 이 사이에는 의존성이 없다. 그래서 이 두 명령어는 교환이 가능한 것이다.

그림 2 mov 프로그램 구조

정리해보자. A, B 두 명령어가 순서대로 존재할 때, A가 수정하는 상태와 B가 참조하는 상태의 교집합이 공집합이 아닌 경우를 두고 우리는 B는 A에 의존적이라고 표현한다. 더불어 이런 의존 관계에 있는 명령어는 코드 교환이 불가능하다.

상태 맵
x86 계열의 CPU는 32비트 모드에서 <그림 3>에 나와 있는 것과 같은 기본 실행 환경을 제공해 준다 (참고자료 [2]). 그림을 조금 살펴보면 이렇다. 기본적인 프로그램 실행에는 8개의 범용 레지스터(EAX, EBX, ECX, EDX, EDI, ESI, ESP, EBP), 6개의 세그먼트 레지스터(CS, DS, ES, FS, GS, SS), 상태 레지스터(EFLAGS), 명령어 포인터 레지스터가(EIP) 사용된다. 프로그램이 부동 소수점 연산을 하는 경우에는 FPU 레지스터들이 추가로 사용되며, MMX 명령어를 사용하는 경우에는 MMX 레지스터가, SSE 명령어를 사용하는 경우에는 XMM 레지스터들이 사용된다.

이제 CPU 내부에서 관리되고 있는 상태에 대해서 알아보았으니 그 다음으로 어디까지 지원할 것인지 그 범위를 결정해야 한다. <그림 3>을 다시 살펴보면 프로그램 실행 환경은 크게 기본 프로그램 실행 레지스터, 부동 소수 레지스터(FPU), MMX 레지스터, XMM 레지스터, 주소 공간의 다섯 가지 컴포넌트로 구성된 것을 볼 수 있다.

여기서 FPU, MMX, XMM 레지스터 쪽을 지원한다는 것은 각각 부동 소수 명령어, MMX 명령어, SSE 명령어 디코딩 기능을 추가해야 한다는 의미가 된다. 주소 공간에 대한 지원은 좀 더 복잡하다. 다음 프로그램을 살펴보자. 이 프로그램은 첫 번째 명령어가 esp 번지에 기록을 하고, 두 번째 명령어가 그 기록한 esp 번지를 읽고 있다. 즉, 두 명령어 사이에서는 동일한 메모리 번지 esp를 공유하기 때문에 의존성이 있다.

mov [esp], eax
mov ecx, [esp]

비슷한 구조로 되어 있는 다음 프로그램을 살펴보자. 이 프로그램은 앞선 프로그램과 달리 두 명령어 사이에 의존성이 없다. 왜냐하면 eax를 기록한 곳은 esp 번지 이고, ecx에 값을 기록하기 위해서 참조하는 메모리는 esp+4 번지이기 때문이다.

mov [esp], eax
mov ecx, [esp+4]

여기까지만 보면 주소 공간을 지원하는 것이 별로 어려운 문제가 아닌 것처럼 보인다. 이 문제가 복잡하다는 사실을 알려주는 예는 바로 다음 프로그램에 있다. 이 프로그램의 경우 첫 mov 명령어가 esp 번지에 기록하며, 두 번째 mov 명령어는 0xFFFF0000 번지를 참조하고 있다. 그렇다면 과연 이 프로그램은 두 명령어 사이에 의존성이 있는 것일까? 없는 것일까? 답은 그 때 그 때 다르다는 것이다. 왜냐하면 만약 이 프로그램이 실행될 때 esp의 값이 0xFFFF0000이었다면 의존성이 있는 것이고, 그렇지 않다면 없는 것이기 때문이다. 즉, 직접 실행되기 전까지는 이 프로그램의 의존성을 우리가 파악할 수 없다는 점이 주소 공간의 의존성을 추적하는 문제의 가장 큰 어려움이다. 이런 이유로 우리는 소개한 세 개의 프로그램의 경우 모두 첫 번째 명령어와 두 번째 명령어가 메모리를 수정하고 참조한다는 형태로 단순화 시켜서 모두 코드 교환이 불가능한 형태라고 간주하는 방법을 사용할 것이다.

mov [esp], eax
mov ecx, [0xFFFF0000]

주소 공간에 대한 추적을 지원하는 것 외에도 나머지 모든 컴포넌트를 지원하는 것이 항상 최선은 아니다. 왜냐하면 런타임 코드 교환을 생각한다면 성능 문제를 고려하지 않을 수 없기 때문이다. 또한 대부분의 프로그램의 경우 MMX나 SSE 명령어를 잘 사용하지 않는다는 것도 중요한 이유다. 이런 이유로 우리는 앞으로의 논의에서는 기본 프로그램 실행 레지스터외의 상태(FPU, MMX, XMM)에 대해서는 지원하지 않는 것을 기본으로 논의를 진행하도록 하겠다. 프로그램의 거의 대부분이 기본 명령어로 이루어지기 때문에 기본 프로그램 실행 레지스터만 추적하는 것으로도 상당히 많은 코드 교환이 가능하다는 점도 같이 기억해두자.

지원할 컴포넌트가 결정이 되었다면 이제는 명령어 사이의 의존성을 파악하는 방법이라는 원래 문제로 넘어가보자. 이 문제를 해결하기 위해서 우리는 상태 맵이란 것을 사용할 것이다. 상태 맵이란 우리가 추적할 개별 상태들을 하나의 비트로 표현한 정수를 말한다. <리스트 1>을 보면 우리가 추적하기로 한 상태에 대해서 상수를 정의해 둔 것을 볼 수 있다. <리스트 2>에는 명령어 하나 하나를 분석한 명령어 구조체가 나와 있다. 이 명령어 구조체에는 단일 명령어에 대한 모든 정보가 저장된다. 앞서 우리가 도식화한 그림에 있었던 참조 상태와(ref_state) 수정 상태도(mod_state) 여기에 저장된다.

리스트 1 상태 정의

const ULONG X86_STATE_EAX    = 0x00000001;
const ULONG X86_STATE_EBX    = 0x00000002;
const ULONG X86_STATE_ECX    = 0x00000004;
const ULONG X86_STATE_EDX    = 0x00000008;

const ULONG X86_STATE_EBP    = 0x00000010;
const ULONG X86_STATE_ESP    = 0x00000020;
const ULONG X86_STATE_ESI    = 0x00000040;
const ULONG X86_STATE_EDI    = 0x00000080;

const ULONG X86_STATE_EFLAGS = 0x00004000;
const ULONG X86_STATE_MEMORY = 0x20000000;

const ULONG X86_STATE_ALL    = 0xFFFFFFFF;

리스트 2 명령어 노드의 구조체

typedef struct _INSTRUCTION
{
    // ... 각종 정보들 ...

    ULONG ref_state; // 명령어가 참조하는 상태
    ULONG mod_state; // 명령어가 수정하는 상태
} INSTRUCTION, *PINSTRUCTION;

그림 3 32비트 모드 기본 실행 환경

상태 맵을 사용해서 실제로 의존성을 파악하는 코드는 <리스트 3>에 나와 있다. <리스트 3>의 코드는 앞선 push 프로그램의 코드 사이에 존재하는 의존성을 파악하는 것을 보여주고 있다. 각 명령어 구조체의 ref_state와 mod_state를 설정한 다음 AND(&) 연산을 수행하면 이 사이에 존재하는 의존성이 나타난다. dependency가 0이라면 의존성이 없는 것이고, dependency가 0이 아니라면 의존성이 존재하는 것이다.

앞서 언급한 것처럼 우리는 메모리 추적을 지원하지 않을 것이기 때문에 메모리를 참조 내지는 수정하는 명령어에 대해서는 X86_STATE_MEMORY 비트를 설정해서 의존성을 체크하면 된다. 더불어 우리가 알지 못하는 명령어 FPU, MMX, SSE를 만났을 때에는 X86_STATE_ALL을 사용하면 해당 명령어들에 대해서는 코드 교환이 발생하는 현상을 방지할 수 있다.

리스트 3 명령어 분석을 통한 의존성 파악

INSTRUCTION push3;
push3.ref_state = X86_STATE_ESP;
push3.mod_state = X86_STATE_ESP | X86_STATE_MEMORY;

INSTRUCTION push4;
push4.ref_state = X86_STATE_ESP;
push4.mod_state = X86_STATE_ESP | X86_STATE_MEMORY;

ULONG dependency = push3.mod_state & push4.ref_state;

그렇다면 개별 명령어가 참조하는 상태에 대해서는 어떻게 파악하는 것일까? 당연히 <리스트 3>에 나와 있는 것과 같은 수작업을 통해서 판단할 수는 없는 노릇이다. 이는 명령어를 디스어셈블링해서 해석하는 부분에서 자동적으로 파악하도록 만들어야 한다. x86 계열 CPU의 경우 여기에는 크게 두 가지 작업이 있다. 개별 명령어가 특수하게 참조하는 상태를 파악하는 일과, ModR/M 바이트를 분석해서 참조하는 레지스터 정보를 획득하는 일이 그것이다 (참고자료 [3], [4]).

독립성
의존적인 명령어와 구조와 그렇지 않은 명령어 구조에 대해서 살펴보았다. 그리고 그 의존성을 기계적으로 판단할 수 있는 도구도 마련했다. 그렇다면 의존적이지 않은 명령어의 순서를 교환함으로써 모든 일이 간단하게 끝날 수 있을까? 물론 그렇게 간단하지 않다. 아래와 같은 프로그램을 살펴보자.

mov eax, ecx
mov ecx, 4

첫 번째 mov 명령어는 ecx를 참조하고, eax에 값을 기록한다. 두 번째 mov 명령어는 참조하는 것이 없으며, ecx에 값을 기록한다. 이 두 명령어 사이에는 의존적인 관계가 없다. 그렇다면 이 명령어의 순서를 교환해 보자.

mov ecx, 4
mov eax, ecx

순서를 변경하고 나서 명령의 사이의 관계를 분석해보면 첫 번째 명령어가 ecx에 값을 수정하고, 두 번째 명령어는 그것을 참조한다는 것을 알 수 있다. 원본 프로그램에는 없던 의존성이 명령어의 순서를 교환하고 나니 생겼다. 이 두 프로그램은 원래 CPU의 ecx 상태 값이 4였다면 동일한 기능을 수행한다. 하지만 4가 아닌 다른 값에 대해서는 모두 다른 결과를 나타내기 때문에 이 둘은 같은 프로그램이라고 할 수 없다.

이를 통해 우리는 독립성이라는 새로운 개념을 도출해 낼 수 있다. A, B 라는 인접한 두 명령어가 존재할 때에, A가 B와 의존적이지 않으며, 동시에 B도 A에 의존적이지 않은 경우에 우리는 이 A와 B가 독립적인 관계에 있다고 표현한다. 또한 앞서 살펴본 것과 같이 이렇게 독립적인 관계에 있을 때만 두 명령어의 교환이 가능하다.

배타성
다음과 같은 프로그램의 경우 두 개의 인접한 명령어는 서로 다른 레지스터의 값을 변경하지만 eflags라는 플래그 레지스터의 값을 둘 다 기록하고 있는 것을 볼 수 있다. 두 명령어의 경우 서로 독립적이기 때문에 교환해도 무방한 것처럼 보이지만 교환하는 경우에는 최종적으로 eflags에 저장되는 값이 달라진다는 차이점이 있다.

sub ecx, 3 (읽기: 없음, 쓰기: ecx, eflags)
sub edx, 5 (읽기: 없음, 쓰기: edx, eflags)

위 프로그램이 아래 프로그램의 일부라고 생각하면 이 내용이 얼마나 큰 차이를 나타내는 지를 알 수 있다. 프로그램이 실행될 때에 ecx, edx에 모두 5가 저장되어 있었다고 한다면 두 명령어를 교환하기 전에는 $label 노드로 분기가 발생하지만, 두 명령어의 순서를 교환하고 나면 분기가 발생하지 않는다.

sub ecx, 3 (읽기: 없음, 쓰기: eax, eflags)
sub edx, 5 (읽기: 없음, 쓰기: eax, eflags)
je $label (읽기: eflags, 쓰기: 없음)

이렇게 두 명령어가 수정하는 상태의 교집합이 공집합인 경우를 두고 우리는 두 명령어가 상호 배타적이라 표현한다. 앞서 살펴본 것과 같이 두 명령어가 독립적이라 하더라도 상호 배타적이지 않은 경우에는 프로그램 실행 결과가 달라지게 되므로 두 명령어를 교환할 수 없다.

분기 코드의 복잡성
끝으로 우리가 주의해야 할 것은 분기 명령이 포함된 코드다. 분기 명령어는 프로그램 실행 순서에 절대적인 영향을 미치기 때문에 세심하게 살펴보아야 한다. <리스트 4>에는 조건 분기 명령어를 포함한 간단한 프로그램 코드가 나와 있다. 여기에는 a, b, c, d라는 네 개의 지점이 오른쪽에 표시되어 있다. 이 네 개의 지점은 분기 코드에서 나타나는 특징이 깃들어 있는 특별한 지점들이다. 각 지점을 기준으로 코드 교환이 실행 흐름에 미치는 영향에 대해서 살펴보자.

리스트 4 분기 코드를 포함한 프로그램

        cmp esi, edi
        mov eax, 1   … a
        je $label    … b
        mov eax, 2   … c
$label: mov ecx, 3   … d
        mov edx, 4   … e

우선 a지점을 살펴보자. a지점의 특징은 다음 명령어가 분기 명령어라는 점이다. a와 b를 교환하는 것은 지금까지 논의된 내용으로는 충분히 가능하다. a와 b는 독립적이며, 상호 배타적이기 때문이다. 하지만 a와 b를 교환하면 실행 흐름이 달라지는 문제가 발생한다. esi, edi가 같다면 a, b, d순으로 프로그램이 진행된다. 하지만 a와 b를 교환해 버리면 실행 흐름이 b, d가 돼버린다. 원본 프로그램과 달라지는 것이다.

다음으로 b지점을 살펴보자. b지점의 특징은 현재 명령어가 분기 명령어라는 점이다. 물론 b와 c 또한 교환 가능한 명령어다. esi와 edi가 동일할 때 교환하기 전 실행 흐름은 a, b, d가 된다. 하지만 b와 c를 교환했다면, a, c, b, d 순으로 실행된다. 흐름이 달라지는 것이다. 따라서 이 경우도 교환할 수 없다.

c지점은 다음 명령어가 역참조 노드라는 특징이 있는 부분이다. 역참조 노드는 다른 노드에서 분기가 되어서 도달하는 지점이 있는 노드를 말한다. 코드 상에서는 $label과 같은 것이 있는 지점을 의미한다고 생각하면 된다. c와 d를 교환하면 어떤 일이 발생할까? esi와 edi가 같을 때 a, b, d로 실행되던 것이 a, b, c로 실행되는 결과를 가져온다. 따라서 이 경우도 교환할 수 없다.

끝으로 d지점을 살펴보자. d지점은 현재 명령어가 역참조 노드인 경우다. 이 경우에 d와 e를 교환하면 esi와 edi가 동일했다면 a, b, d, e로 실행되던 것이 a, b, e, d로 실행된다. 반대로 esi와 edi가 같지 않았다면 a, b, c, d, e로 실행되던 것이 a, b, c, e, d로 실행된다. 두 경우 모두 원래 실행 흐름에 포함된 코드를 모두 포함하기 때문에 이 경우에는 교환을 하더라도 문제가 되지 않는다.

정리해보면 이렇다. 현재 노드나 다음 노드가 분기 노드인 경우(b, a) 내지는 다음 노드가 역참조 노드인 경우(c) 코드 교환을 수행하는 경우 실행 흐름이 달라지기 때문에 해당 명령어의 독립성, 배타성에 상관 없이 교환할 수 없다.

코드 교환의 법칙
코드 교환을 할 수 있는 경우와 없는 경우를 구분하기 위해서 다양한 내용을 논의했다. 모든 내용을 종합해서 정리해보면 우리는 다음 4가지 조건이 만족되면 현재 노드의 코드와 다음 노드의 코드를 교환해도 문제가 없다는 결론을 내릴 수 있다. <리스트 5>에는 이를 코드로 구현해 본 내용이 나와 있다.

• 현재 노드와 다음 노드가 분기 노드가 아니다.
• 다음 노드가 역참조 노드가 아니다.
• 현재 노드와 다음 노드가 독립적이다.
• 현재 노드와 다음 노드가 배타적이다.

리스트 5 코드 교환이 가능한지 검토하는 함수

BOOL CanExchangeNode(INSTRUCTION *c)
{
    INSTRUCTION *n = c->GetNext();

    // 현재나 다음이 분기 노드인가?
    if(c->IsBranch() || n->IsBranch())
        return FALSE;

    // 다음이 역참조 노드인가?
    if(n->IsXref())
        return FALSE;

    // 현재와 다음이 독립적인가?
    if((c->mod_state & n->ref_state)
        || (n->mod_state & c->ref_state))
        return FALSE;

    // 현재와 다음이 배타적인가?
    if(n->mod_state & c->mod_state)
        return FALSE;

    return TRUE;
}

지금까지 우리는 전체 프로그램의 일부가 교환 가능한지 불가능한지를 판단하는 방법에 대해서 알아보았다. 이를 통해서는 단지 두 명령어를 교환하는 작업만 가능할 뿐이다. 이를 전체 프로그램에 적용하기 위해서는 전체 명령어를 파싱해서 만들어둔 명령어 리스트를 순회하면서 해당 지점의 코드가 교환 가능한지를 체크하고 교환이 가능한 경우에는 랜덤하게 교환할지를 결정하면 된다. 이 구조를 다중 패스로 적용하면 명령어들의 교환이 중첩으로 적용되기 때문에 원본 프로그램에서는 전혀 유추할 수 없는 최종 프로그램을 생성해 낼 수 있다. 이런 과정을 보여주는 전체 의사 코드가 <리스트 6>에 나와 있다.

리스트 6 전체 프로그램 코드 교환 의사 코드

// N 패스 수행
for(int i=0; i<N; ++i)
{
    c = GetListHead();
    n = c->GetNext();
    while(c && n)
    {
        // 교환 가능한 경우 50% 확률로 교환
        if(CanExchangeNode(c) && (rand() % 2))
            ExchangeNode(c, n);

        c = c->GetNext();
        n = c->GetNext();
    }
}

참고자료
[1] 진화하는 코드 by 신영진, 마이크로소프트웨어 2008-01
[2] Intel® 64 and IA-32 Architectures Software Developer’s Manual VOLUME 1
[3] Intel® 64 and IA-32 Architectures Software Developer’s Manual VOLUME 2A
[4] Intel® 64 and IA-32 Architectures Software Developer’s Manual VOLUME 2B