Taint Analysis 연구분석보고서
By. bdr@a3sc.co.kr
(A.K.A Dear.Tom)
kerz@a3sc.co.kr
(A.K.A k3rz)
I. Introduction
1. Motivation
Application이 입력 받는 외부 데이터(인자)는 어느 정도까지 “영향”을 줄 수 있는가? 라는 의문은 Information(Data) Flow, Taint Analysis 분야를 발전할 수 있게 한 동기부여가 되었습니다. 즉 외부 데이터로부터 영향을 받는 부분을 찾기 위한 방법의 발전이라고 할 수 있습니다.
“영향”을 줄 수 있는 것들에는 MP3, PDF, 네트워크 패킷 등과 같이 어플리케이션의 외부 데이터를 말할 수도 있으며, 시스템 커널에 영향을 주는 정보(Understanding Data)를 의미할 수도 있습니다.
2. 용어 정의
가. Information Flow
디버거로 어플리케이션의 내부를 보면, 실행되는 동안 Information은 복사되고, 수정되고 있습니다. 즉 Information 은 항상 움직이는 것이라고 정의할 수 있습니다.
Taint analysis는 Information Flow 분석의 한 형태라고 볼 수 있습니다.
상세한 정보는 “Certification of Programs for Secure Information Flow”[2]를 참고하시기 바랍니다.
나. Flow
연산이 사용되는 객체의 X와 이로부터 파생된 객체의 Y가 있을 때, “X에서 Y로 흐른다(flow)”라고 말합니다.
다음은 Flow 개념을 설명한 도식화 화면입니다.
[그림 1] Flow 도식도
다. Taint Analysis
Taint Analysis는 외부 입력 영향으로부터 흐름을 파악 하는 것을 말합니다. 즉 다음과 같이 정의 할 수 있습니다.
● 모든 외부 입력을 비 신뢰성(untrustworthy) 값으로 간주하며, 이들의 데이터 흐름을 추적하는 기법
Taint Analysis는 일반적으로 프로그램의 분석을 위해 사용되는 경우가 많은데, 예를 들어 메모리 퍼포먼스, footprint, 보안 TEST 목적 등이 있으며, TaintBochs와 같은 시스템 에뮬레이터를 이용하면 운영체제 동작 감시도 가능합니다.
보안적 관점으로 봤을 경우 Taint Analysis로부터 취약한 메모리 영역의 추적이 가능하므로, 0-day 취약점, 악성코드 분석 등에 응용이 가능합니다.
라. Taint 객체
“객체의 출처 값을 신뢰 할 수 없다면(untrustworthy), 그 객체 역시 Taint 되었다.” 라고 말합니다.
다음은 Taint 객체 개념을 설명한 도식화 화면입니다.
[그림 2] Tainted 객체
마. Taint propagation
“만약 taint 된 객체 X와 연산으로 파생된 객체인 Y가 있을 때, 객체 Y는 taint 되었으며, 객체 X로부터 객체 Y로 taint 되었다”라고 말합니다.
Taint는 t로 표시합니다. (“Taint operator t”)
위의 정의 내용은 X → t(Y) 로 표시할 수 있으며, 다음과 같은 성질을 가졌습니다.
X → t(Y) and Y → t(Z), then X → t(Z)
다음은 Taint propagation 개념을 설명한 도식화 화면입니다.
(도식에서 나타내듯 2가지 이상의 Tainted source 들은 융합될 수 있습니다.)
[그림 3] Tainted propagation 도식도
II. Taint 여부 판별 방법
대부분의 Taint Analysis tool 은 C, C++, Java 프로그래밍 언어를 위해 사용 사용되며, 프로그램의 소스 코드가 없어도 분석됩니다. 또한 각각의 High-level 의 언어로 파싱 할 필요가 없습니다.
본문에서는 x86 아키텍처를 기준으로 설명을 주로 하겠습니다.
Taint Analysis 모듈은 x86아키텍처에서 사용하기 위해서 최소한 다음과 같은 조건을 갖춰야 합니다.
● 각각의 명령 연산의 모든 피연산자는 식별 가능하여야 합니다.
● 피연사자의 유형(source/destination)은 식별 가능하여야 합니다.
● 각각의 tainted 객체는 추적이 가능하여야 합니다.
● 각각의 명령의 의미가 명확해야 합니다.
예를 들어 전형적인 명령으로 “mov eax, 040h”을 보자면 2가지 확실한 피연산자는 eax 그리고 040h 값을 나타냅니다. Destination 피연산자는 eax, source 피연산자는 eax(register), 040h 값을 나타냅니다. (다른 명령들 중에는 함축적인 피연산자를 가지기도 합니다.) 여기에서 만약 source 피연산자인 040h 값이 taint source 피연산자라고 하면 eax 또한 Taint 피연산자 값이 되고, 이와 파생된 값들도 taint 된 값이 됩니다. 위의 내용은 단순한 명령을 예로 생각했지만, 수많은 연산, 명령을 통해서 실제로는 더 복잡할 것 입니다.
Taint Analysis tool은 x86 명령을 중간언어(IL: Intermediate Languages)로 바꿔준 후 해석하는 형태를 띄는데, 이유는 구문 분석(parse)하기 쉽고, 피연산자를 식별할 수 있기 때문입니다.
Taint 추적 매커니즘은 bit 혹은 byte 단위로 이루어질 수 있습니다.
1. Taint objects on x86
X86 아키텍처 안에서는 2가지 객체가 Taint 될 수 있는데, 다음과 같습니다.
● Memory locations
● Processor registers
가. Memory objects
● 메모리 영역의 초기 주소 값을 저장
● 메모리 영역의 크기(size)를 저장
나. Register objects
● 레지스터 식별자(이름)를 저장
● bit-level 추적 기법에서는 개별 bit를 저장
다음은 Taint object에 대한 도식화 화면입니다.
2. Instruction analysis
ISA(Instruction Set Architecture)는 다음과 같이 몇 가지 카테고리로 분류할 수 있습니다.
● 할당 지시자(Assignment instruction): mov, xchg 등
● 2진 지시자(Boolean instruction): AND, OR, XOR 등
● 산술 지시자(Arithmetical instruction): add, sub, mul, div 등
● 문자열 지시자(String instruction): scas, lods, cmps 등
● 분기 지시자(Branch instruction): call, jmp, jnz 등
가. 할당 지시자(Assignment instruction)
mov eax, dword ptr [4C001000h]
메모리 4C001000h 영역에 있는 값이 tainted 데이터라면, 이 값을 할당 받은 eax 또한 tainted 데이터가 됩니다.
다음은 Taint 할당 지시자 MOV개념 도식화 화면입니다.
나. 2진 지시자(Boolean instruction)
2진 연산(AND, OR, XOR 등) 결과의 tainted 여부는 입력된 tainted 데이터가 결과값에 어떤 영향을 주었는지를 보고 판단합니다. 단, 2개의 입력 값 모두가 taint된 경우는 제외합니다.
(1) AND 진리표(truth table)
A
B
A AND B
0
0
0
0
1
0
1
0
0
1
1
1
A가 taint된 값이라고 가정했을 때,
- B가 0일 경우 그 결과는 무조건 “taint 되지 않았다.(untainted)”라고 판단
- B가 1일 경우 그 결과는 무조건 “taint 되었다.(tainted)”라고 판단
왜냐하면, AND연산의 특성(2개의 입력 값 모두가 1일 경우에만 참) 상 B가 1일 경우에만 A의 값에 영향을 받기 때문입니다.
다음은 Taint 2진 지시자 AND 개념 도식화 화면입니다.
[그림 6] Taint 2진지시자 AND 도식화
(2) OR 진리표(truth table)
A
B
A OR B
0
0
0
0
1
1
1
0
1
1
1
1
A가 taint된 값이라고 가정했을 때,
- B가 1일 경우 그 결과는 무조건 “taint 되지 않았다.(untainted)”라고 판단
- B가 0일 경우 그 결과는 무조건 “taint 되었다.(tainted)”라고 판단
왜냐하면, OR 연산의 특성(1이 하나라도 있을 경우 무조건 참) 상 B가 0일 경우에만 A의 값에 영향을 받기 때문입니다.
(3) XOR 진리표(truth table)
| A | B | A XOR B |
| 0 | 0 | 0 |
| 0 | 1 | 1 |
| 1 | 0 | 1 |
| 1 | 1 | 0 |
A가 taint된 값이라고 가정했을 때,
- B의 값에 상관없이 모든 결과는 “taint 되었다.(tainted)”라고 판단
왜냐하면, XOR 연산의 특성(둘 중 하나만 1일 경우에만 참) 상 B가 어떤 값이든 A의 값에 영향을 받기 때문입니다. 단, A xor A의 연산처럼 A값이 어떤 값이든 그 결과가 무조건 0이 되는 경우는 “taint되지 않았다.(untainted)”라고 판단합니다.
다음은 Taint XOR 개념 도식화 화면입니다.
[그림 7] Taint XOR 개념 도식화
(4) 항진 명제(tautology)와 모순 명제(contradiction)
- 항진 명제는 입력 값과 상관없이 항상 결과가 참인 경우
- 모순 명제는 입력 값과 상관없이 항상 결과가 거짓인 경우
- 그러므로, taint 된 입력 값이 들어왔다 하더라도 무조건 “taint되지 않았다(untainted)”라고 판단
(5) 상수(constant)를 이용한 연산
- 무조건 “taint 되지 않았다(untainted)”라고 판단
다. 산술 지시자(Arithmetical instruction)
sub, add, mul 등의 산술 지시자는 내부적으로 2진 연산을 이용합니다. 예를 들어, ADD 연산은 AND 및 XOR의 연산으로 이루어져 있습니다. 그러므로 “하나의 피연산자가 taint 되어 있을 경우에는 그 결과 또한 taint 되었다.”라고 판단합니다. 그리고 이 결과에 영향 받는 EFLAGS(ZF, OF, DF, CF 등) 레지스터 또한 “taint 되었다”라고 판단합니다.
라. 문자열 지시자(String instruction)
tainted 문자열은 어떤 문자열 지시자가 적용되더라도 생성된 객체는 “taint 되었다.(tainted)”라고 판단합니다.
● taint된 문자열에 대한 크기(size) 값 또한 taint 되었다고 판단
● taint된 문자를 검색한 값과, 그 결과로flag(found/not found)를 설정하는 경우에도 taint 되었다고 판단
마. Taint 된 객체의 수명(Lifetime)
다음은 taint된 객체가 생성/유지 되는 경우와 제거되는 경우를 설명한 내용입니다.
(1) 생성/유지
- 신뢰하지 못할(untrusted) 객체로부터 할당 받은 경우
- tainted 객체로부터 할당 받은 경우
(2) 삭제
- untainted 객체로부터 할당 받은 경우
- tainted 객체로부터 할당을 받았지만, 그 결과가 상수인 경우
III. 응용
1. Exploit 검출
Taint Analysis를 통해 Exploit 검출 할 수 있는데, 사용자 데이터의 추적이 가능하다면, 신뢰할 수 없는(nontrusted) 데이터가 privileged location에서 사용되었는지 검출이 가능합니다. 이를 통해 위험한 부분을 찾을 수 있으므로 패치하여 위험성을 낮출 수 있을 것 입니다.
Privileged location에 대해 설명하자면, 조금 작은 그림으로 생각하면 특정 OS상에서 특권 레벨(privileged level), 사용자 레벨(unprivileged level)로 구분하여 생각할 수 있는데, 신뢰할 수 없는(nontrusted) 데이터가 어떤 위치에서 사용되고 있는지 검출한다는 의미로 보시면 됩니다.
Taint Analysis - Exploit detection 으로 SQL Injection, XSS, BoF(Buffer overflows) 검출이 가능하며, 심지어 Unkown Attack 검출도 가능합니다.
2. 데이터 수명(lifetime) 분석
Taint Analysis를 통해 데이터 수명을 분석하면 가상 머신 메모리 안에 저장된 민감한 정보(비밀번호, 신용카드 정보) 데이터 수명을 추적 할 수 있습니다. 그리고 대부분의 Application 의 경우 민감한 정보 데이터의 수명을 최소화하기 위해 어떠한 조치도 하지 않습니다.
상세한 내용은 “Understanding data lifetime via whole system Simulation”[3]를 참고하시길 바랍니다
IV. 활용방안
1. DBI(Dynamic Binary Instrumentation)
가. 용어 정의
(1) Instrumentation
실행정보를 수집하기 위해 프로그램에 임의의 코드를 삽입하는 기술을 의미합니다.
(2) Dynamic Binary Instrumentation
실행중인 어떤 프로그램(프로세스)에 특수한 목적(모니터링, 통계 등)으로 사용될 임의의 코드를 삽입하는 방법입니다.
나. DBI의 유용성
● Recompile 및 Relink가 필요 없어 작업 효율성을 높일 수 있다.
● 실행중에 특정 코드를 발견할 수 있다.
● 동적으로 생성된 코드를 처리할 수 있다.
● 기존에 실행중인 프로세스를 불러와(attatch) 분석 할 수 있다.
다. 주요 목적
(1) 컴퓨터 구조 연구
● Trace Generation
● Branch Predictor and Cache Modeling
● Fault Tolerance Studies
● Emulating Speculation
● Emulating New Instructions
(2) 프로그램 분석
● Code Coverage
● Call-graph generation
● Memory-leak detection
● Instruction profiling
(3) 스레드 분석
● Thread profiling
● Race detection
라. DBI Tools
다음은 DBI 관련 Tool들을 간략하게 정리한 내용입니다.
Tool 이름
실행환경
특징
WIN
LINUX
MAC
- 다양한 플랫폼 지원
Pin
O
O
O
- Intermediate Language(Vex) 기반
DynamicRIO
O
O
O
-
TEMU
O
O
-
- Virtual Machine(QEMU) 기반
- 시스템 전체를 분석 가능
2. PIN
PIN은 대표적인 DBI 도구로써, 다양한 플랫폼(Linux, Windows, MacOS)에서 사용가능합니다. C 혹은 C++로 작성된 임의의 코드를 실행코드의 한 부분으로 삽입시킬 수 있으며, 이미 실행중이던 프로세스를 attach 시키는 일도 가능합니다. 특히, 방대한 API를 제공하여 사용자가 원하는 툴을 직접 제작하기 쉽도록 도와주며, 기본적으로 제공되는 툴 또한 많이 있습니다.
PIN은 일종의 “Just In Time”(JIT) 컴파일러입니다. 하지만, 해당 컴파일러에 입력되는 값은 바이트코드가 아닌 일반적인 실행파일입니다. 하나의 명령어가 실행될 때마다 그 흐름을 가로채어PIN 내부적으로 새로 생성(컴파일)한 코드를 실행하며, 이때 사용자가 원하는 코드를 삽입(Instrumentation) 할 수 있습니다.
가. 사용법
기본적인 PIN의 사용법은 다음과 같습니다.
$ pin [pin-option]... –t pintool [tool-options]... -- application
● pin ← Instrumentation Engine
● pintool ← Instrumentation Tool
● application ← Target Program(or process)
나. Tools
PIN에서 제공하는 기본적인 Tool에는 다음과 같습니다.
Tool Name: 기능
inscount0: Simple Instruction Count
itrace: Instruction Address Trace
pinatrace: Memory Reference Trace
imageload: Detecting the Loading and Unloading of Images
proccount: Procedure Instruction Count
malloctrace: Finding the Value of Function Arguments
malloc_mt: Instrumenting Threaded Application
buffer-lin: Using the Fast Buffering APIs
follow_child_tool: Instrumenting Child Process
(1) pinatrace
대상 프로그램에서 메모리에 접근(Read or Write)하는 내역을 기록하여 출력해줍니다.
다음은 cmd.exe를 대상으로 pinatrace 툴을 실행한 화면입니다.
[그림 9] pinatrace 실행화면
D:\_PIN_>pin.bat -t .\source\tools\SimpleExamples\obj-ia32\pinatrace.dll -- cmd
\d dir
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
D:\_PIN_>
다음은 cmd.exe 에서 메모리에 접근 한 결과를 보여주는 화면입니다.
[그림 10] pinatrace 결과화면
위의 화면에서 결과값은 다음을 의미합니다.
(2) Imageload
프로그램에서 불러들이는 이미지 정보를 기록하여 출력합니다.
다음은 cmd.exe를 대상으로 imageload 툴을 실행한 화면입니다. D:\_PIN_>dir
[그림 11] imageload 실행화면
D:\_PIN_>pin.bat -t .\source\tools\ManualExamples\obj-ia32\imageload.dll -- cmd
\d dir
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
다음은 cmd.exe 에서 불러들이는 이미지 정보를 보여주는 화면입니다.
[그림 12] imageload 결과화면
(3) proccount
프로그램에서 실행되는 프로시저를 기록하여 출력합니다.
다음은 cmd.exe를 대상으로 proccount 툴을 실행한 화면입니다.
| D:\_PIN_>pin.bat -t .\source\tools\ManualExamples\obj-ia32\proccount.dll -- cmd \d dir Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. D:\_PIN_>dir |
다음은 cmd.exe 에서 실행되는 프로시저 정보를 보여주는 화면입니다.
[그림 14] proccount 결과화면
(4) malloctrace
함수로 전달되거나, 함수에서 반환되는 인자 값을 찾아 출력해 줍니다.
다음은 cmd.exe를 대상으로 malloctrace 툴을 실행한 화면입니다.
| D:\_PIN_>pin.bat -t .\source\tools\SimpleExamples\obj-ia32\malloctrace.dll -- cm d \d dir Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. D:\_PIN_> |
[그림 15] malloctrace 실행화면
다음은 malloc(), free()를 위한 인자 값 및 malloc()으로부터 반환되는 값을 보여주는 화면입니다.
[그림 16] malloctrace 결과화면
(5) Debugging
Linux의 GDB나 Windows의 Visual Studio를 이용하여 Pin에서 실행되고 있는 프로그램을 Attach 시켜 디버깅을 할 수 있습니다.
다음은 [터미널1]에서 pintool(inscount0.so)을 gdb로 넘겨준 화면입니다.
다음은 [터미널2]에서 –pause_tool 옵션을 이용하여 pid를 확인하는 화면입니다.
다음은 [터미널1]에서 PIN에서 실행되고 있는 프로세스를 Attach 시키는 화면입니다.
이후로는 일반적인 상황과 마찬가지로 디버깅을 하시면 됩니다.
다. Routines
pintools의 코드에는 2가지 중요한 루틴이 포함되어 있습니다.
다음은 중요 루틴을 설명하기 위한 예제코드로써, 프로그램에서 사용되는 Instruction의 갯수를 파악하는 모듈입니다. void Instruction(INS ins, void *v) //instrumentation routine
inscount0.cpp
(...)
void docount() { icount++; } //analysis routine
{
INS_InsertCall(ins, IPOINT_BEFORE, (AFUNPTR)docount, IARG_END);
}
(...)
(1) Instrumentation routines
Instrumentation 코드를 “어디에 삽입” 할 것인지를 정의하는 루틴입니다. 위의 예제 코드에서는 프로그램에서 사용되는 instruction의 갯수를 파악하기 위해 instruction이 실행되기 바로 전에 counting 함수를 위치시킵니다.
(2) Analysis routines
instumentation 코드가 활성화 될 때, “무엇을 할 것인지”를 정의하는 루틴입니다. 위의 예제를 이어서 생각해 보면, 프로그램에서 Instruction이 실행될 때 마다 해당 루틴이 호출되어 카운팅 변수의 값을 늘리게 됩니다.
3. Valgrind
Valgrind는 실행 파일의 디버깅과 프로파일링을 위한 Open-source 입니다. 주로 Memory-leak, Thead profiling, Race detection 에 사용되며, --tool 옵션으로 tool 사용이 가능합니다.
가. 사용법
기본적인 Valgrind의 사용법은 다음과 같습니다.
$ valgrind –-tool=<name> Prog-and-args
● valgrind ← Instrumentation Engine
● <name> ← Instrumentation Tool
● Prog-and-args ← Target Program(or process)
나. Tools
valgrind에서 제공하는 기본적인 Tool에는 다음과 같습니다.
Tool Name 기능
Memcheck memory error detector
Cachegrind cache and branch-prediction profiler
Callgrind call-graph generating cache profiler
Helgrind thread error detector
DRD thread error detector (similar helgrind)
Massif Heap profiler
DHAT different kind of heap profiler
Ptrcheck experimental heap, stack and global array overrun detector
BBV experimental SimPoint basic block vector generator
(1) Cachegrind
프로그램의 캐시 프로파일링을 합니다.
다음은 cachegrind를 사용한 결과 화면입니다.
[그림 20] Cachegrind 결과화면
(2) memcheck
Valgrind 사용시 일반적으로 사용되는 tool이며, 다음과 같은 경우를 알려줍니다.
• 초기화되지 않은 메모리 사용
• free된 메모리에 Read/Write를 시도한 경우
• malloc된 메모리 블록 외에 Read/Write 를 시도하는 경우
• stack의 부적절한 지역에 Read/Write 가 시도되는 경우
• 메모리 노출(leak) - malloc되고 free되지 않은 메모리
• 초기화되지 않거나 주소를 알 수 없는 메모리가 시스템 호출로 넘겨지는 경우
• memcpy()와 관련된 함수에서 SRC, DST의 포인터가 겹치는 경우
• 몇 가지의 POSIX pthreads API의 잘못된 사용
다음은 memcheck를 사용한 결과 화면입니다.
[그림 21] memcheck 결과화면
(3) helgrind
helgrind는 멀티 쓰레드 프로그램에서 데이터의 경쟁 상태를 알려줍니다.
다음은 helgrind를 사용한 결과 화면입니다.
[그림 22] helgrind 결과화면
(4) callgrind && (kcachegrind || callgrind_annotate)
callgrind 프로파일링을 위해 사용되며, 출력 파일(filename.out.pid)을 생성합니다. 호출의 호출 관계를 보여줍니다.
생성된 출력 파일은 kcachegrind, callgrind_annotate 를 통해 보기 편하게 변환이 가능합니다.
다음은 출력된 파일을 확인한 화면입니다.
[그림 23] callgrind 출력파일 확인
다음은 callgrind를 사용한 결과 화면입니다.
[그림 24] callgrind 결과
[kcachegrind]
다음은 kcachegrind를 실행한 화면입니다.
[그림 25] kcachegrind 실행 화면
다음은 kcachegrind를 실행한 결과 화면입니다.
[그림 26] kcachegrind 결과화면(1)
다음은 kcachegrind를 실행한 결과 화면입니다.
[그림 27] kcachegrind 결과화면(2)
[callgrind_annotate]
다음은 callgrind_annotate를 실행한 화면입니다.
[그림 28] callgrind_annotate 실행화면
다음은 callgrind_annotate를 통해 생성된 파일을 확인한 화면입니다.
[그림 29] callgrind_annotate 출력파일 확인
(5) tainter
Cambridge 의 컴퓨터 연구소(Computer Laboratory)에서 만든 valgrind taint analysis tool 이며, Opensource 입니다.
URL) http://www.cl.cam.ac.uk/~wmk26/tainter/
다음은 tainter를 실행한 화면입니다.
[그림 30] tainter 실행화면
다음은 tainter를 사용한 결과 화면입니다.
[그림 31] tainter 결과 화면
V. 결론
Taint Analysis는 보안적인 입장에서 보면 외부 입력에 대한 데이터의 흐름을 분석하여 취약한 부분을 추적하는 기법입니다. 다양한 방식으로 Taint Analysis는 적용될 수 있습니다. 예를 들어 디버거를 이용하여 디버깅된 모든 코드를 한 줄씩 확인하는 방법으로 취약점을 찾을 수 있습니다. 하지만 파일의 크기가 커지게 되면 이 방법으로 찾기에는 한계가 있을 수 있습니다. 그럴 때, Taint analysis 단계를 걸치면 취약할 수 있는 메모리 위치 등을 조금 더 수월하게 찾을 수 있습니다. 특히, 공격자의 입장에서 보면 공격 대상(Target)의 취약한 부분(예를 들어, BOF나 SQL Injection이 발생하는 부분)을 찾아 공격할 수 있을 것 입니다.
Taint analysis는 보안 컨설턴트 입장에서는 취약점을 찾기 위한 준비단계라고 볼 수 있으며, 응용방법에 따라서 만족스런 결과 창출이 가능합니다.
VI. 참고문헌
[1] Barbosa. Edgar. COSEINC Solid Security. Taint Analysis. In H2HC 2009
[2] D. E. Denning and P. J. Denning. Certification of programs for secure information flow. Communications of the ACM, 1977
[3] J. Chow, B. Pfaff, T. Garfinkel, K. Christopher, and M. Rosenblum. Understanding data lifetime via whole system simulation. In USENIX Security, 2004
[4] BSDaemon. Dynamic Program Analysis and Software Exploitation. In Phrack issue#67-10, August 14 2010
[5] Valgrind Project. http://www.valgrind.org
[6] Pintool. http://www.pintool.org/
[7] Wei Ming Khoo. Tainter. http://www.cl.cam.ac.uk/~wmk26/tainter/
[8] Bitblaze Project. http://bitblaze.cs.berkeley.edu/temu.html
