C'est la vie

이름

objdump -오브젝트 파일의 정보를 표시한다.

 

사용법

objdump

[-a|--archive-headers] [-b bfdname | --target=bfdname] [-C|--demangle] [--debugging] [-d|--disassemble] [-D|--disassemble-all] [--disassemble-zeroes] [-EB|-EL|--endian={big|little}] [-f|--file-headers] [-h|--section-headers | --headers] [-i|--info] [-j section | --section=section] [-l|--line-numbers] [-m machine | --architecture=machine] [--prefix-addresses] [-r|--reloc] [-R|--dynamic-reloc] [-s|--full-contents] [-S|--source] [--[no-]show-raw-insn] [--stabs] [-t|--syms] [-T|--dynamic-syms] [-x|--all-headers] [--start-address=address] [--stop-address=address] [--adjust-vma=offset] [--version] [--help] objfile...

 

설명

objdump 는 하나 이상의 오브젝트 파일에 대한 정보를 출력한다. 각 옵션들은 어떠한 정보들을 출력할지를 제어한다. 이 정보들은 주로 일반적인 프로그래머가 아닌 컴파일 툴을 개발하는 프로그래머들에게 유용한 것이다.

objfile... 은 조사할 오브젝트 파일들에 해당한다. 여기에 아카이브 파일을 지정한 경우에는 objdump 는 포함된 각각의 오브젝트 파일에 대한 정보를 출력한다.

 

옵션

동일한 역할을 수행하는 긴 형식과 짧은 형식의 옵션은 함께 표기하였다. -l (--line-numbers) 옵션을 제외하고 최소한 하나 이상의 옵션이 지정되어야 한다.

-a

--archive-headers

만약 objfile 중의 하나가 아카이브 파일인 경우, 아카이브 헤더 정보를
 ( `ls -l'과 비슷한 형태로) 출력한다. `ar tv' 명령을 통해 알 수 있는 정보를 제외하고, `objdump -a' 명령은 아카이브 멤버인 각각의 오브젝트 파일에 대한 형식을 보여준다.

--adjust-vma=offset

정보를 출력할 때, 먼저 모든 섹션 주소에 offset 을 더한다. 이것은 a.out 형식과 같이 섹션 주소를 표현하지 않는 형식에서 어떤 섹션을 특정 주소에 위치시키려는 경우와 같이, 섹션 주소가 심벌 테이블과 일치하지 않는 경우에 유용하게 사용될 수 있다.

-b bfdname

--target=bfdname

오브젝트 파일에 적용될 오브젝트 코드 형식을 bfdname으로 지정한다. 이 옵션은objdump 가 자동적으로 해당 형식을 인식할 수 있는 경우에는 필요치 않다. 예를 들어,

objdump -b oasys -m vax -h fu.o

명령은 Oasys 컴파일러를 통해 생성된 형식인 Vax 오브젝트 파일로 지정된 (`-m') `fu.o' 파일의 섹션 헤더에서 (`-h') 요약 정보를 출력한다. 적용할 수 있는 형식의 목록을 보려면 `-i' 옵션을 이용하도록 한다.

-C

--demangle

저수준의 심벌 이름을 사용자가 알아볼 수 있는 형태로 디코딩(demangle)한다. 시스템에서 부여한 앞부분의 언더스코어를 제거하는 일 이외에도, 이것은 C++ 함수의 이름을 읽을 수 있도록 변환해 준다.

--debugging

디버깅 정보를 출력한다. 이것은 파일 내에 저장된 디버깅 정보를 분석하여 C 언어와 비슷한 현태로 출력한다. 오직 몇가지 타입의 디버깅 정보 만이 구현되어 있다.

-d

--disassemble

objfile에서 기계어 부분에 해당하는 어셈블러 명령어를 출력한다. 이 옵션은 오직 명령어들을 저장하도록 되어있는 섹션들만을 디스어셈블링 한다.

-D

--disassemble-all

-d 옵션과 비슷하지만, 명령어가 저장되어 있는 섹션만이 아닌 모든 섹션의 내용을 디스어셈블한다.

--prefix-addresses

디스어셈블 시에, 각 라인의 완전한 주소값을 출력한다. 이것은 예전의 디스어셈블리 형식에 해당한다.

--disassemble-zeroes

일반적으로 디스어셈블된 출력은 제로 블럭(모든 데이터가 0인 블럭)을 건너뛴다. 이 옵션이 사용되면 이러한 제로 블럭들도 다른 데이터와 마찬가지로 디스어셈블한다.

-EB

-EL

--endian={big|little}

오브젝트 파일의 엔디안 형식을 지정한다. 이것은 오직 디스어셈블링 시에 적용된다. 이 옵션은 S-records와 같이 엔디안 정보를 갖고 있지 않는 형식의 파일을 디스어셈블할 때 유용하게 사용될 수 있다.

-f

--file-headers

objfile내의 각 파일들의 전체 헤더에서 요약 정보를 출력한다.

-h

--section-headers

--headers

오브젝트 파일의 섹션 헤더에서 요약 정보를 출력한다.

--help

objdump 에서 사용할 수 있는 옵션의 요약 정보를 출력하고 종료한다.

-i

--info

-b 혹은 -m옵션과 함께 사용할 수 있는 모든 아키텍처와 오브젝트 형식의 목록을 출력한다.

-j name

--section=name

name 섹션의 정보만을 출력한다.

-l

--line-numbers

(디버깅 정보를 사용하여) 오브젝트 코드를 출력할 때 해당 부분의 파일명과 라인 번호를 함께 출력한다. 이 옵션은 -d, -D, -r 옵션들과 함께 사용할 때에만 의미가 있다.

-m machine

--architecture=machine

오브젝트 파일을 디스어셈블할 때 사용할 아키텍처를 지정한다. 이 옵션은 S-records와 같이 아키텍처 정보를 포함하지 않은 오브젝트 파일을 디스어셈블할 때 유용하게 사용할 수 있다. 사용할 수 있는 아키텍처의 목록은 -i 옵션을 이용하여 알아볼 수 있다.

-r

--reloc

파일의 재배치 항목들을 출력한다. 이 옵션이 -d 옵션이나 -d 옵션과 함께 사용된 경우에는, 재배치 항목들은 디스어셈블 결과와 섞여서 출력된다.

-R

--dynamic-reloc

파일의 동적 재배치 항목들을 출력한다. 이 옵션은 오직 공유 라이브러리와 같은 동적 객체에 적용할 경우에만 의미를 가진다.

-s

--full-contents

요청한 섹션의 완전한 내용을 출력한다.

-S

--source

가능하다면 디스어셈블링된 결과와 함께 소스 코드를 출력한다. -d 옵션을 사용한 것과 비슷한 효과이다.

--show-raw-insn

디스어셈블할 때 명령어의 심벌과 함께 16진수 값을 출력한다. 이것은 --prefix-addresses 옵션이 사용되지 않은 경우의 기본값이다.

--no-show-raw-insn

디스어셈블할 때, 명령어의 16진수 값을 출력하지 않는다. 이것은 --prefix-addresses 옵션이 사용된 경우의 기본값이다.

--stabs

ELF 파일의 .stab, .stab.index, .stab.excl 섹션의 내용을 출력한다. 이것은 ELF 섹션 내에 .stab 디버깅 심벌 테이블 항목이 들어있는 (솔라리스 2.0과 같은) 시스템에서 유용하게 사용될 수 있다. 다른 대부분의 파일 형식들은 디버깅 심벌 테이블 항목들은 --syms output 옵션을 통해 볼 수 있는 링크 심볼들과 뒤섞여 있다.

--start-address=address

지정된 주소의 데이터에서부터 출력을 시작한다. 이 옵션은 -d, -r , -s 옵션의 출력에 영향을 미친다.

--stop-address=address

지정된 주소의 데이터에서 출력을 중지한다. 이 옵션은 -d, -r , -s 옵션의 출력에 영향을 미친다.

-t

--syms

심벌 테이블. 파일의 심벌 테이블 항목들을 출력한다. 이것은 `nm' 프로그램에서 제공하는 정보와 비슷한 형태로 출력된다.

-T

--dynamic-syms

다이나믹 심벌 테이블. 파일의 동적 심벌 테이블 항목들을 출력한다. 이 옵션은 공유 라이브러리와 같은 동적 객체에 대해서만 의미를 가진다. 이것은 `nm' 프로그램에서 -D (--dynamic) 옵션을 사용하였을 때 제공하는 정보와 비슷한 형태로 출력된다.

--version

objdump 의 버전을 출력하고 종료한다.

-x

--all-headers

심벌 테이블과 재배치 항목들을 포함한 가능한 모든 헤더 정보를 출력한다. `-x' 옵션을 사용하는 것은 `-a -f -h -r -t' 옵션을 모두 함께 준 것과 동일하다.

gcc는 예전에는 GNU C Compiler의 약자였으나 지금은 GNU Compiler Collection의 약자로 다양한(?) 언어의 컴파일러들의 집합체이다. gcc는 한마디로 GNU에서 개발된 ANSI C 표준을 따르는 C 언어 컴파일러라고 말할 수 있다. gcc는 ANSI C 표준에 따르기는 하지만 ANSI C 표준에는 없는 여러 가지 확장 기능이 있다. 또한 gcc는 통합개발환경(IDE)을 가지고 있지 않은 command line 컴파일러이다. 옛날 Turbo-C를 주로 사용해 보셨던 분들은 tcc.exe와 비슷하다고 생각하면 된다.

(*) -v 옵션
현재 사용되고 있는 gcc의 버전을 나타내는 옵션이다. 특정 소프트웨어 패키지를 컴파일하기 위해 어느 버전 이상의 gcc를 쓰도록 권장하는 경우가 있는데 시스템에 깔려있는 gcc의 버전을 파악하려고 할때 사용한다.

이제 직접 프로그램 하나를 컴파일하면서 설명하도록 하겠다. 아래는 hello.c의 소스이다.

#include〈stdio.h〉 int main() { 　　printf(“hello gccn”); 　　return 0; }

$ gcc -o hello hello.c
로 컴파일하면 실행파일 hello가 만들어진다.

(*) -o 파일이름 옵션
gcc의 수행 결과 파일의 이름을 지정하는 옵션이다. 위의 예제를 단순히
$ gcc hello.c
로 컴파일 하면 hello라고 하는 실행파일이 만들어 지는 것이 아니라 보통의 경우 a.out이라는 이름의 실행파일이 만들어진다.
-o hello 옵션을 줌으로써 결과물을 hello라는 이름의 파일로 만들어지게 하였다.

위의 컴파일 과정을 외부적으로 보기에는 단순히 hello.c파일이 실행파일 hello로 바뀌는 것만 보이지만 내부적으로는 다음과 같은 단계를 거쳐 컴파일이 수행된다.

　(1) C Preprocessing
　(2) C 언어 컴파일
　(3) Assemble
　(4) Linking

C Preprocessing은 C 언어 배울 때 배운 #include, #define, #ifdef 등 #으로 시작하는 여러 가지를 처리해 주는 과정이다. 그 다음 C 언어 컴파일은 C Preprocessing이 끝난 C 소스 코드를 assembly 소스코드로 변환하는 과정이다. Assemble은 그것을 다시 object 코드(기계어)로 변환하고 printf()함수가 포함되어 있는 라이브러리와 linking을 하여 실행파일이 되는 것이다.
위의 네 가지 과정을 모두 gcc라는 실행파일이 해 주는 것일까? 겉으로 보기에는 그렇게 보일지 모르지만 실제로는 gcc는 소위 말해 front-end라고 하여 껍데기에 지나지 않고 각각을 해 주는 다른 실행파일을 gcc가 부르면서 수행된다.
C Preprocessing을 전담하고 있는 실행파일은 cpp라고 하여 /usr/bin 디렉토리와 /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.95.12 디렉토리(당연히 gcc버전과 시스템에 따라 디렉토리 위치가 다르다. gcc -v로 확인하길 바란다.)에 존재한다. C 언어 컴파일은 cc1이라는 실행파일이 담당하는데 /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.95.12 디렉토리에 존재한다. Assemble과 linking은 각각 as와 ld라는 실행파일이 담당하고 /usr/bin 디렉토리에 존재하는 파일이다. (참고 : 시스템에 따라 /usr/bin이 아니라 /bin또는 /usr/local/bin 디렉토리에 존재할 수도 있다.)

gcc라는 실행파일이 하는 일을 정리해 보면 다음과 같다.
　(1) 사용자에게 옵션과 소스 파일명들의 입력을 받는다.
　(2) 소스 파일명의 확장자를 보고 어떤 단계를 처리해야 할지 결정한다.
　(3) 사용자의 옵션을 각각의 단계를 맡고 있는 실행파일의 옵션으로 변경한다.
　(4) 각각의 단계를 맡고 있는 실행파일을 호출(fork, exec)하여 단계를 수행하도록 한다.

=== C Preprocessing(cpp)
C preprocessing을 우리말로 하면 "C 언어 전처리"라고 할 수 있을 것이다. 모든 C 언어 문법책에서 정도의 차이는 있지만 C preprocessing에 대한 내용을 다루고 있다. C preprocessing에 대한 문법은 C 언어 문법의 한 부분으로 가장 기본이 되는 부분이다. C preprocessing에 관한 문법은 모두 '#'으로 시작된다. '#' 앞에는 어떠한 문자(공백 문자 포함)도 오면 안된다. 하지만 대부분의 compiler가 '#'앞에 공백 문자가 오는 경우에도 처리를 한다.

== C preprocessing이 하는 일
　(1) 입력 : C 언어 소스 코드
　(2) 출력 : 전처리가 완료된 C 언어 소스 코드
　(3) 하는 일
　　- 파일 포함(file inclusion - 헤더파일 및 기타파일)
　　- 매크로(macro) 치환
　　- 선택적 컴파일(conditional compile)
　　- 기타(#line, #error, #pragma)

cpp는 C 언어 소스코드를 입력 받아서 C preprocessing에 관련된 문법 사항을 적절히 처리하고 결과로 C 언어 소스코드를 출력하는 프로그램이다. 입력은 작성된 C 언어 소스 코드이고, 출력으로 나온 C 언어 소스 코드에는 C preprocessing 문법에 관련된 어떠한 것도 남아있지 않는다. 즉, #define, #include 등을 찾을 수 없다. 남아 있는 정보가 있다면 file 이름과 줄수(line number)에 관한 정보이다. 그 이유는 추후의 컴파일 과정에서 에러가 날 때 그 정보를 이용해서 error를 리포팅할 수 있도록 하기 위해서이다. 그렇다면 C preprocessing을 직접 해보자.
$ gcc -E -o hello.i hello.c
결과로 hello.i라는 파일이 생긴다. 그 파일을 에디터로 열어보면 hello.c의 첫번째 줄에 있는 #include 를 처리한 결과가 보일것이다.

(*) -E 옵션
-E 옵션은 gcc의 컴파일 과정 중에서 C preprocessing까지만 처리하고 나머지 단계는 처리하지 말라는 것을 지시하는 것이다. 평소에는 별로 쓸모가 있는 옵션이 아니지만 다음과 같은 경우에 유용하게(?) 사용할 수 있다.
　(1) C 언어 소스 코드가 복잡한 선택적 컴파일을 하고 있을 때, 그 선택적 컴파일이 어떻게 일어나고 있는지 알고 싶은 경우.
　(2) preprocessing의 문제가 C 언어 에러로 나타날 경우. 다음과 같은 소스코드를 고려해 보자.

#define max(x, y) ((x) 〉(y) ? (x) : (y) /* 마지막에 ")"가 없다!!! */ int myMax(int a, int b) { 　　return max(a, b); }

$ gcc -c cpperr.c
다음과 같은 에러가 난다.
cpperr.c: In function `myMax':
cpperr.c:4: parse error before `;'
cpperr.c파일의 4번째 줄에서 ';'가 나오기 전에 parse error가 났다. 하지만 실제 에러는 #define에 있었으므로 그것을 확인하려면 -E 옵션으로 preprocessing을 하여 살펴 보면 쉽게 알 수 있다.

(*) 참고 : parse error before x(어떤 문자) 에러는 소스코드를 parsing 할 때 발생한 에러를 말한다. parsing이란 syntax analysis(구문해석) 과정인데 쉽게 말하면 C 언어 소스코드를 읽어들여 문법적 구성요소들을 분석하는 과정이라고 할 수 있다. 보통 gcc에서 parse error라고 하면 괄호가 맞지 않았거나 아니면 ';'를 빼먹거나 했을 때 발생한다. 보통의 경우 before x라고하여 x라는 것이 나오기 전에 parse error가 발생하였음을 알려주기 때문에 그 x가 나오기 전에 있는 C 소스 코드를 잘 살펴보면 문제를 해결할 수 있다.

C preprocessing의 문법과 나머지 C 언어의 문법과는 거의 관계가 없다. 관계가 있는 부분이 있다면 정의된 macro가 C 언어의 문법 상의 char string literal에는 치환되지 않는다는 정도이다. (좀 더 쉽게 이야기 하면 큰 따옴표 안에서는 macro 치환이 되지 않는다.) 또한 c preprocessing은 architecture dependent하지 않다. 즉, i386용으로 컴파일된 cpp를 다른 architecture에서 사용해도 무방하다. 조금 문제가 있을 수 있는 부분이 있다면 gcc의 predefined macro(i386의 경우 i386용 자동으로 define된다.)가 다를 수 있다는 점 뿐이다. 따라서 cpp를 C 언어 소스코드가 아닌 다른 부분에서 사용하는 경우도 있다. 대표적으로 assembly 소스 코드에서도 사용한다. assembler가 사용하고 있는 macro 문법이 c preprocessing의 macro문법 보다는 배우기 쉽기 때문이다.

이제 preprocessing이 하는 일에 대해서 좀더 알아 보자.
== 파일 포함(file inclusion)
#include 〈stdio.h〉
#include "config.h"
위와 같이 많은 C 언어 소스코드에서 헤더 파일을 포함한다.〈〉와 ""의 차이는 기본적인 헤더파일과, 사용자 정의 헤더파일을 구분하는 정도이다. include한 헤더 파일은 default로 특정 디렉토리를 찾게 된다. Linux 시스템의 경우 /usr/include가 default 디렉토리이다. (실제로도 그곳에 stdio.h라는 파일이 있다.) 그 다음은 현재 디렉토리를 찾게 된다.(물론〈〉와 ""에 따라서 다르다.) 파일이 없으면 당연히 에러가 발생한다. gcc의 경우 다음과 같은 에러가 발생한다.
>>소스코드파일명:line number: 헤더파일명: No such file or directory
또는(LANG=ko일때)
>>소스코드파일명:line number: 헤더파일명: 그런 파일이나 디렉토리가 없음

그렇다면 include하고 싶은 파일이 default 디렉토리와 현재 디렉토리에 없으면 어떻게 할까? 그런 문제를 해결하기 위해서 다음과 같은 옵션이 존재한다.

(*) -Idir 옵션
여기서 dir은 디렉토리 이름이고 -I와 디렉토리 이름을 붙여 써야 한다. 그럼 include한 헤더 파일을 그 디렉토리에서도 찾아 주게 된다. 당연히 옵션을 여러 번 다른 디렉토리 이름으로 사용할 수도 있어서 헤더 파일을 찾을 디렉토리를 여러 개로 지정할 수 있다. 꼭 알아 두어야 할 옵션이다.

(*) -nostdinc
이 옵션은 default 디렉토리(standard include 디렉토리)를 찾지말라고 지시하는 옵션이다. 어플리케이션 프로그래머는 관심을 둘 필요가 없지만 kernel 프로그래머는 관심 있게 볼 수 있는 옵션이다.

== macro 치환
macro 치환에 대해서는 특별히 일어날 만한 에러는 없다. 가끔 문제가 되는 부분이 macro 정의가 한 줄을 넘어선 경우 역슬레쉬('')로 이어져야 하는데 그 소스 파일이 windows용 에디터로 편집 되었으면 parse error가 나는 경우가 있다. 그것은 개행문자(new line character)가 서로 달라서 그런 것인데...음 자세히 이야기하자면 끝이 없으므로 그냥 넘어가도록 해야한다. 또한 macro가 define된 상황에서 macro를 undef하지 않고 다시 define하면 다음과 같은 Warning이 난다.
'xxxx' redefined

macro 치환에서 대한 옵션 두개를 알아보도록 하자.

(*) -Dmacro 또는 -Dmacro=defn 옵션
gcc의 command line에서 macro를 define할 수 있도록 하는 옵션이다. 예를 들어 -D__KERNEL__이라는 옵션을 주면 컴파일 과정 중에 있는 C 언어 소스코드의 맨 처음에 #define __KERNEL__이라고 해준 것과 같이 동작한다. 또한 -DMAXLEN=255라고하면 C 언어 소스코드의 맨 처음에 #define MAXLEN 255 라고 한 것과 동일한 결과를 준다. 선택적 컴파일을 하는 경우에 많이 이용하는 옵션으로 꼭 알아야 할 옵션이다.

(*) -Umacro 옵션
이 옵션은 #undef하고 하는 일이 똑같은데 C 언어 소스코드와는 하등의 관계가 없다. -Dmacro옵션처럼 C 언어 소스코드의 맨처음에 #undef macro를 해주는 것은 아무런 의미가 없기 때문이다.(어짜피 #define은 그 이후에 나올 것이므로...) 이 옵션의 목적은 위의 -Dmacro옵션으로 define된 macro를 다시 undef하고자 할 때 쓰는 옵션이다. 평상시에는 별로 쓸 일이 없는 옵션이지만 그냥 -Dmacro와 같이 짝으로 알아 두길 바란다.

== 선택적 컴파일
#if 시리즈와 #else, #elif, #endif 등으로 선택적 컴파일을 수행할 수 있다. 위에서 설명한 -Dmacro 옵션과 같이 쓰는 경우가 많다. 특별히 설명할 옵션은 없고 #if와 #else, #endif의 짝이 잘 맞아야 한다. 그렇지 않으면 당연히 에러가 발생한다. 단순히 parse error라고 나오는 경우는 드물고, #else, #if 에 어쩌고 하는 에러가 난다. 많이 경우의 수가 있으므로 직접 에러가 발생되도록 코딩을 해보고 확인해 보는 것이 좋다.

== 기타(#line, #error, #pragma)
#line, #error, #pragma라는 것이 있는지도 모르는 사람들이 꽤 있것이다. 자세한 것은 C 언어 문법 책을 찾아보길 바란다. #line의 경우 C 언어 소스코드 직접 쓰이는 경우는 거의 없으니까 무시하고 #pragma는 compiler에 dependent하고 gcc에서 어떤 #pragma를 사용하는지도 알 수 없으므로 그냥 넘어가도록 한다. #error의 경우 C preprocessing 과정에서 강제로 에러를 만드는 지시어이다. 선택적 컴파일 과정에서 도저히 선택되어서는 안 되는 부분에 간혹 쓰인다. 당연히 #error를 만나면 에러가 생긴다. linux kernel 소스코드에서 include 디렉토리를 뒤져 보시면 사용하는 예를 만날 수 있다.

== predefined macro
사용자가 C 언어 소스코드에서 #define을 하지 않아도 이미 #define된 macro가 있다. ANSI C에서는 __LINE__, __FILE__, __TIME__, __DATE__, __STDC__ 다섯 가지는 이미 define되어 있는 macro로 강제적인 사항이다.(문법책 참조) gcc도 당연히 다섯 가지 macro를 predefine 한다. 뿐만 아니라 GCC의 버전에 대한 macro, architecture에 관한 사항 등을 -Dmacro 옵션 없이도 predefine 한다. -v 옵션을 실행하여 출력되는 specs파일을 열어보면 쉽게 알 수 있을 것이다.(specs파일이 어떻게 해석되는지는 나도 잘 모른다.)

== 꼭 알아두면 좋은 옵션 한가지
다음과 같이 shell 상에 입력해 보라.(hello.c는 계속되는 그 녀석이다.)
$ gcc -M hello.c
어떤 것이 출력되나? "hello.o: hello.c /usr/include/stdio.h 어쩌구저쩌구"가 출력될 것이다. 어디서 많이 본 듯한 형식 아닌가?

(*) -M 옵션
-M 옵션은 cpp에게 makefile로 만들 수 있는 rule을 만들어 달라고 하는 요청을 보내는 명령이다. file을 include하는 녀석은 cpp이므로 rule은 cpp가 만들 수 있다. 당연히 -Dmacro, -Umacro, -Idir 옵션 등을 같이 사용할 수 있고 그에 따라 결과가 달라질 수도 있다. makefile을 좀 쉽고 정확하게 만들 때 쓰는 옵션이므로 알아두면 좋다. 단점은 default 디렉토리에 있는 보통 사용자는 고칠 수도 없는 파일까지도 만들어 준다는 것이다.

=== C 언어 컴파일 과정
C 언어 컴파일 과정은 gcc라고 하는 frontend가 cc1이라는 다른 실행파일을 호출(fork & exec)하여 수행하게 된다. 사용자가 cc1이라는 실행파일을 직접 실행해야 할 하등의 이유도 없고 권장되지도 않는다. gcc의 입력으로 여러 개의 파일(C 소스 파일, object 파일 등)을 준다고 하더라도 컴파일 과정 중 앞 3단계, 즉 cpp, C 컴파일, assemble은 각각의 파일 단위로 수행된다. 서로 다른 파일의 영향을 받지 않고 진행된다. 특정 C소스 코드에서 #define된 macro가 다른 파일에는 당연히 반영되면 안된다. header 파일의 존재 의미를 거기서 찾을 수 있다.

이제 C 언어 컴파일 과정이 하는 일을 알아보도록 하자.

== C 언어 컴파일 과정이 하는 일
　(1) 입력 : C 언어 소스 코드(C preprocessing된)
　(2) 출력 : Assembly 소스 코드
　(3) 하는 일 : 컴파일(너무 간단한가?)

C preprocessing과 마찬가지로 너무 간단하다. 하지만 위의 “컴파일” 과정은 cc1 내부에서는 여러 단계로 나누어져 다음과 같은 순서로 일어난다. Parsing(syntax analysis)이라고 하여 C 언어 소스 코드를 파일로부터 읽어 들여 컴파일러(여기서는 cc1)가 이해하기 쉬운 구조로 바꾸게 된다. 그 다음에 그 구조를 컴파일러가 중간 형태 언어(Intermediate Language)라고 하는 다른 언어로 변환하고 그 중간 형태 언어에 여러가지 최적화를 수행하여 최종 assembly 소스 코드를 만들게 된다.

직접 수행해 보자. 다음과 같이 shell의 command line에 입력하라. 역시 지긋지긋한 hello.c를 이용하도록 한다.
$ gcc -S hello.c
결과로 출력된 hello.s를 에디터로 열어서 살펴보라 (혹시 위의 command로 hello.s가 만들어 지지 않는다면 gcc -S -o hello.s hello.c로 하라.). “.”으로 시작하는 assembler directive와 “:”로 끝나는 label명, 그리고 몇 개의 assembly mnemonic이 보이나? Assembly 소스를 읽을 줄 몰라도 그게 assembly 소스 코드구나 생각하면 된다.

(*) -S 옵션
-S 옵션은 gcc의 컴파일 과정 중에서 C 언어 컴파일 과정까지만 처리하고 나머지 단계는 처리하지 말라는 것을 지시하는 것이다. 평소에는 거의 사용하지 않는 옵션이지만 다음과 같은 경우에 유용하게 사용할 수 있다.
　(1) 어셈블리 코드가 어떻게 생겼는지 보고 싶은 호기심이 발동한 경우
　(2) C calling convention을 알아보거나 stack frame이 어떻게 관리되고 있는 지 보고 싶은 경우

보통의 경우는 아니지만 사용자가 직접 assembly 코딩을 하는 경우가 종종 있다. 아무래도 사람이 기계보다는 훨씬 똑똑하기 때문에 사람이 직접 assembly 코딩을 해서 최적화를 시도하여 소프트웨어의 수행 시간을 단축시키거나, 아니면 linux kernel이나 bootloader 등과 같이 꼭 assembly가 필요한 경우가 있다. 이때도 보통의 경우는 소프트웨어의 전 부분을 assembly 코딩하는 것이 아니라 특정 부분만 assembly 코딩을 하고 나머지는 C 언어나 다른 high-level 프로그래밍 언어를 써서 서로 연동을 하도록 한다. 그럼 C 언어에서 assembly 코딩된 함수를 호출할 때(반대의 경우도 마찬가지), 함수의 argument는 어떻게 전달되는 지, 함수의 return 값은 어떻게 돌려지는지 등을 알아볼 필요가 있다. 이렇게 argument와 return 값의 전달은 CPU architecture마다 다르고 그것을 일정한 약속(convention)에 따라서 처리해 주게 된다. 위의 hello.s를 i386용 gcc로 만들었다면 파일 중간에 xorl %eax,%eax라는 것이 보일 것이다. 자기 자신과 exclusive or를 수행하면 0(zero)이 되는데 이것이 바로 hello.c에서 return 0를 assembly 코드로 바꾼 것이다. 결국 i386 gcc에서는 %eax 레지스터에 return 값을 넣는다는 convention이 있는 것이다.(실제로는 gcc뿐 아니라 i386의 convention으로 convention을 따르는 모든 compiler가 %eax 레지스터를 이용하여 return값을 되돌린다.) argument의 경우도 test용 C 소스를 만들어서 살펴볼 수 있을 것이다. 물론 해당 CPU architecture의 assembly 소스코드를 어느 정도 읽을 수 있는 사람들에게만 해당하는 이야기 이다. stack frame도 비슷한 얘기 쯤으로 알아 두길 바란다.

== Parsing(Syntax Analysis)
위에서 cc1이 컴파일을 수행하는 과정 중에 맨 첫 과정으로 나온 Parsing에 대해서는 좀더 언급을 한다. Parsing과정은 그야말로 구문(Syntax)을 분석(Analysis)하는 과정이다. Parsing의 과정은 파일의 선두에서 뒤쪽으로 한번 읽어 가며 수행된다. Parsing 중에 컴파일러는 구문의 에러를 찾는 일과 뒤에 수행될 과정을 위해서 C 언어 소스 코드를 내부적으로 다루기 쉬운 형태(보통은 tree형식을 이용)로 가공하는 일을 수행한다. 이 중에 구문의 에러를 찾는 과정은 (1) 괄호 열고 닫기, 세미콜론(;) 기타 등등의 문법 사항을 체크하는 것 뿐만 아니라, (2) identifier(쉽게 말해 변수나 함수 이름 들)의 type을 체크해야 한다.
　(1) 괄호 열고 닫기, 세미콜론(;) 기타 등등의 문법 사항에 문제가 생겼을 때 발생할 수 있는 에러가 전에 이야기한 parse error이다. 보통 다음과 같이 발생한다.
>> 파일명과 line number: parse error before x
당연히 에러를 없애려면 ‘x’ 앞 부분에서 괄호, 세미콜론(;) 등을 눈 빠지게 보면서 에러를 찾아 없애야 한다.
　(2) type checking
구문 에러를 살필 때 type 체크를 왜 해야 할까? 다음과 같은 예를 보자.
var3 = var1 + var2;
앞 뒤에서 parse error가 없다면 위의 C 언어 expression!은 문법적인 문제가 없는가? 하지만 var1이 파일의 앞에서 다음과 같이 정의(definition)되었다면 어떻게 될까?
struct point { int x; int y; } var1;
당연히 ‘+’ 연산을 수행할 수 없다.(C 언어 문법상) 결국은 에러가 난다. 이렇게 identifier(여기서는 var1, var2, var3)들의 type을 체크하지 않고서는 구문의 에러를 모두 찾아낼 수 없다.
만약 var1과 var3가 파일의 앞에서 int var1, var3;로 정의되어 있고 var2가 파일의 앞에 어떠한 선언(declaration)도 없이 파일의 뒤에서 int var2;로 정의되어 있다면 에러가 발생할까? 정답은 “발생한다”이다. 위에서 언급했듯이 Parsing은 파일의 선두에서 뒤쪽으로 한번만(!!!) 읽으면서 진행하기 때문이다.(모든 C 컴파일러가 그렇게 동작할지는 의심스럽지만 ANSI C 표준에서는 그렇게 되어 있는 것으로 알고 있다. Assembler는 다르다.)
그렇다면 어떤 identifier를 사용하려면 반드시 파일 중에 사용하는 곳 전에 identifier의 선언(declaration) 또는 정의(definition)가 있어야 한다. 하지만 identifier가 함수 이름일 경우(즉 identifier뒤에 (…)가 올 경우)는 조금 다르다. C 컴파일러는 함수 이름 identifier의 경우는 int를 return한다고 가정하고 Error가 아닌 Warning만 출력한다.(Warning옵션에 따라 Warning조차 출력되지 않을 때도 있다.) 그럼 다음과 같은 소스 코드를 생각해 보자.
int var3, var2;
….
var3 = var1() + var2;
….
struct point var1(void) { … }
위와 같은 경우도 문제가 생긴다. 맨 처음 var1이라는 함수 이름 identifier를 만났을 때 var1 함수는 int를 return한다고 가정했는데 실제로는 struct point를 return하므로 에러 또는 경고를 발생한다.
결국 권장하는 것은 모든 identifier는 사용하기 전(파일 위치상)에 선언이나 정의를 해 주는 것이다. 다음과 같은 에러 메시지들을 짧막하게 설명해 본다.
　파일명 line number: ‘x’ undeclared …. 에러 --> ‘x’라는 이름의 identifier가 선언되어 있지 않았다.
　파일명 line number: warning: implicit declaration of function `x' … 경고 --> ‘x’라는 이름의 함수가 선언되어 있지 않아 int를 return한다고 가정했다는 경고(Warning) 메시지이다.

변수나 함수의 선언(declaration)과 정의(definition)에 대해서 알지 못한다면 C 언어 문법책을 찾아서 숙지하길 바란다. 그런 내용이 없다면 그 문법책을 휴지통에 버리길 바란다.

Parsing 과정에는 위의 identifier 에러 및 경고를 비롯한 수많은 종류의 에러와 경고 등이 출력될 수 있다. 에러는 당연히 잡아야 하고 경고도 무시하지 않고 찾아서 없애는 것이 좋은 코딩 습관이라고 할 수 있다. 경고 메시지에 대한 gcc 옵션을 살펴보도록 하자.

(*) -W로 시작하는 거의 모든 옵션
이 옵션들은 어떤 상황 속에서 경고 메시지를 내거나 내지 말라고 하는 옵션이다. -W로 시작하는 가장 강력한 옵션은 -Wall 옵션으로 모든 경고 메시지를 출력하도록 한다. 보통은 -Wall 옵션을 주고 컴파일 하는 것이 좋은 코딩 습관이다.

== Parsing 이후 과정
특별한 경우가 아닌 이상 Parsing을 정상적으로 error나 warning없이 통과한 C 소스 코드는 문법적으로 완벽하다고 봐야 한다. 물론 논리적인 버그는 있을 수 있지만 이후 linking이 되기 전까지의 과정에서 특별한 error나 warning이 나면 안된다. 그런 경우가 있다면 이제는 사용자의 잘못이 아니라 gcc의 문제로 추정해도 무방하다. Parsing이후에 assembly 소스 코드가 생성되는데, 당연히 이 과정에는 특별히 언급할 만한 error나 warning은 없다. 그냥 중요한 옵션 몇 가지만 집고 넘어가도록 하겠다.

(*) -O, -O2, -O3 등의 옵션
이 옵션은 컴파일러 최적화를 수행하라는 옵션이다. -O 뒤의 숫자가 올라갈수록 더욱 많은 종류의 최적화를 수행하게 된다. 최적화를 수행하면 당연히 코드 사이즈도 줄어 들고 속도도 빨라지게 된다. 대신 컴파일 수행 시간은 길어진다. 그리고 linux kernel을 위해 언급하고 싶은 것은 inline 함수들은 이 옵션을 주어야 제대로 inline 된다는 것이다.

(*) -g 옵션
이 옵션은 소스 레벨 debugger인 gdb를 사용하기 위해 debugging 정보(파일명, line number, 변수와 함수 이름들과 type 등)를 assembly code와 같이 생성하라는 옵션이다. 당연히 gdb를 이용하고 싶으면 주어야 한다. -g 옵션을 주지 않고 컴파일한 프로그램을 gdb로 디버깅하면 C 소스 레벨이 아닌 assembly 레벨 디버깅이 된다. 즉 C 소스 코드에 존재하는 변수 이름, line number 등이 없는 상황에서 디버깅을 해야 한다. 또한 -g 옵션을 -O 옵션과 같이 사용할 수도 있다. 단 그런 경우 최적화 결과, C 소스 코드에 존재하는 심볼(symbol; 쉽게 말해 함수와 변수 이름)중에 없어지는 것들이 발생한다.

(*) 여기서 잠깐
identifier와 symbol이 모두 “쉽게 말해 함수와 변수 이름”이라고 했는데 어떻게 차이가 날까? 엄밀히 말하면 차이가 조금 있다. symbol이 바로 “쉽게 말해 함수와 변수 이름”이며 각 symbol은 특정 type과 연계되어 있다. 하지만 identifier는 그냥 “이름” 또는 “인식어”일 뿐이다. 예를 들어 struct point { int x; int y; };라는 것이 있을 때 point는 symbol은 아니지만 identifier이다. 보통 identifier라는 말은 parsing에서만 쓰인다는 정도만 알아두면 된다.

(*) -p 옵션과 -pg 옵션
profiling을 아는가? 수행시간이 매우 중요한 프로그램(real time 프로그램이라고 해도 무방할 듯)을 작성할 때는 프로그램의 수행 시간을 함수 단위로 알아야 할 필요가 있는 경우가 많다. 프로그램의 수행 시간을 함수 단위나 더 작은 단위로 알아보는 과정을 profiling이라고 하는데, profiling은 프로그램 최적화에 있어서 중요한 기능을 담당한다. 대부분의 개발 툴이 지원하고 Visual C++에도 존재한다. 옛날 turbo C에는 있었나? 아무튼 gcc도 역시 profiling을 지원한다. -p 옵션 또는 -pg 옵션을 주면 프로그램의 수행 결과를 특정 파일에 저장하는 코드를 생성해 주게 된다. 그 특정 파일을 적당한 툴(prof또는 gprof 등)로 분석하면 profiling 결과를 알 수 있게 해 준다. 당연히 linux kernel 등에서는 사용할 수 없다.(이유는 특정 파일에 저장이 안되므로…) 초보자들은 이런 옵션도 존재하고 profiling을 할 수 있다는 정도만 알아 두면 좋을 듯 싶다. 나중에 필요하면 좀 더 공부해서 사용하면 된다.

(*) 기타 옵션(-m과 -f시리즈)
중요한 옵션들이기는 하지만 초보자가 알아둘 필요가 없는 옵션 중에 f또는 m으로 시작하는 옵션들이 있다. f로 시작되는 옵션은 여러 가지 최적화와 assembly 코드 생성에 영향을 주는 architecture independent한 옵션이다.(assembly 코드 생성이 architecture dependent 이므로 정확히 말하면 f로 시작되는 옵션이 architecture independent라고 할 수는 없다.) m으로 시작되는 옵션은 보통 architecture dependent 하며 주로 CPU의 종류를 결정하는 옵션으로 assembly 코드 생성에 영향을 주게 된다. 하지만 대부분은 초보자는 그런 것이 있다는 정도만 알아두면 되고 특별히 신경 쓸 필요는 없다고 생각된다. m으로 시작되는 옵션 중에 -msoft-float옵션이 있다.(물론 특정 architecture에만 존재하는 옵션이다.) -msoft-float 옵션은 CPU에 FPU(floating point unit)가 없고, kernel에서 floating-point emulation을 해 주지 않을 때 C 소스 코드 상에 있는 모든 floating-point 연산을 특정 함수 호출로 대신 처리하도록 assembly 코드를 생성하라고 지시하는 옵션이다. 이 옵션을 주고 라이브러리를 linking시키면 FPU가 없는 CPU에서도 floating 연산을 할 수 있다.(대신 엄청 느리다. 어찌보면 kernel floating-point emulation보다는 빠를 것 같은데 확실하지는 않다.)

=== Assemble 과정
Assemble 과정은 앞선 과정과 동일하게 gcc라는 frontend가 as라는 실행 파일을 호출하여 수행된다. 그런데 as는 cpp와 cc1과는 달리 gcc 패키지 안에 존재하는 것이 아니라 별도의 binutils라고 하는 패키지에 존재한다. binutils 패키지 안에는 as를 비롯해 linking을 수행하는 ld, library 파일을 만드는 ar, object 파일을 보거나 복사할 수 있는 objdump, objcopy 등 여러 가지 툴이 들어 있다.

이제 Assemble 과정이 하는 일을 알아보도록 하자.

== Assemble 과정이 하는 일
　(1) 입력 : Assembly 소스 코드
　(2) 출력 : relocatable object 코드
　(3) 하는 일 : assemble(너무 간단한가?)

입력은 당연히 C 언어 컴파일 과정을 거치면 나오는 Assembly 소스 코드이다. Assemble 과정을 거치면 소위 기계어(machine language)라는 결과가 relocatable object 형식으로 나온다. “relocatable”이라는 말이 어려우면 그냥 object 코드라고 해 두자. 이제 직접 수행해자. shell의 command line에 다음과 같이 입력하면 된다.
$ gcc -c hello.c
결과는 hello.o라고 하는 파일이 나온다. hello.o는 binary형식의 파일이니깐 editor로 열어봐야 정보를 얻기 힘들다. 당연히 위의 예는 assemble 과정만 수행한 것이 아니라 C preprocessing 과정, C 언어 컴파일 과정, Assemble 과정을 수행했다. Assemble 과정만 수행하고 싶으면 다음과 같이 입력하면 된다.
$ gcc -c hello.s
역시 hello.o가 생긴다. hello.s는 C 언어 컴파일 과정에서 -S 옵션으로 만들었던 그 파일이다. 별로 관심이 안 생기면 as를 직접 수행할 수도 있다. 다음과 같다.
$ as -o hello.o hello.s
역시 hello.o가 생긴다.

(*) -c 옵션
많이 쓰는 옵션이다. Assemble 과정까지의 과정만 수행하고 linking 과정을 수행하지 말라는 옵션이다. 여러 개의 C 소스 파일로 이루어진 프로그램을 컴파일 할 때 모든 소스 파일을 assemble 과정까지 수행하고 맨 마지막에 linking한다. 보통은 Makefile을 많이 이용하는데 그 때 많이 쓰이는 옵션이다.

Assemble 과정에서는 더 이상 기억해야 하는 옵션도 없고 이게 끝이다. C 언어 컴파일 과정에서 말한 바대로 C 언어 컴파일 과정이 끝난 C 소스 파일은 문법적으로 완전하다고 볼 수 있으므로 assemble 과정에서 Error나 Warning 나는 경우는 없다. 만약 Error나 Warning이 나는 경우가 있다면 gcc의 inline assemble을 이용했을 때, 그 inline assemble 소스 코드에 있는 문제 때문에 생길 수 있다. 안타깝지만 error나 warning 메시지가 나온 다면 C 소스 파일과 line number 정보는 없다. 잘 알아서 처리하는 수 밖에 다른 방법은 없는 것 같다. inline assemble 같은 것을 사용하지 않았는데도 error나 warning이 난다면 gcc의 버그라고 생각해도 무방하다.

== relocatable object 코드 파일 내용
어떤 정보가 object 파일 안에 들어있을까? 당연히 code와 data가 들어 있다. C 컴파일 과정에서 C 언어 함수 안에 있는 내용들이 assembly mnemonic 들로 바뀌었고 그것이 assemble되어 기계어(machine language)가 되었을 것이다. 그 부분이 code를 이룬다. C 언어 소스 코드에 있는 나머지는 전역 변수(external variable)와 정적 변수(static variable)들이 data를 이룰 것이다. 또한 문자열 상수를 비롯한 상수도 data에 들어 있다. 또한 프로그램 수행에 쓰이지는 않고 단순한 정보로서 들어 있는 data들도 있다. 예를 들어 -g 옵션을 주고 컴파일 하면 프로그램의 디버깅 정보(변수, 함수 이름, C 소스 파일이름, line number 등)가 data에 속한다고 볼 수 있다. 그런데 code와 data가 무질서하게 섞여 있는 것은 아니고 section이라고 불리우는 단위로 서로 구분되어 저장되어 있다. Code는 text section에 들어 있고, data는 성격에 따라 data section, bss section, rodata section 등에 나누어져 저장되어 있다.(text, data, bss, rodata 등의 section 이름은 그냥 관습적인 것이다.) 아무튼 section 이야기는 이 정도만 우선 알아두면 될 듯 싶다.

== Symbol 이야기
relocatable object code안에 code와 data가 들어 있다고 했는데, 아주 중요한 것을 빠뜨렸다. 이 이야기는 linking 과정을 이해하기 위해 꼭 필요한 부분이므로 반드시 읽어야 할 것이다. 우선 Symbol이 무엇인지 알 것이다. C 언어 컴파일 과정에서 identifier와 함께 설명했는데 잠시 다시 말씀하자면 Symbol은 함수와 변수 이름이다. 변수 중에 특히 관심두어야 할 것 들은 자동 변수(?,auto variable)들이 아닌 전역 변수(external variable)와 정적 변수(static variable)이다. 자동 변수는 함수의 stack frame에 존재하는 변수이기 때문에 현재 stack pointer(sp, 보통의 CPU의 register중에 하나)에 대한 offset으로 표현된다. 즉 현재 함수에서 자동 변수(auto variable)를 access(read/write)하고 싶으면 sp+상수의 어드레스를 access하면 된다. 하지만 전역 변수와 정적 변수는 그냥 32bit(32bit CPU기준) 어드레스를 읽어야 한다. stack pointer랑은 전혀 관계 없다. 아무튼 여기서 관심을 두는 Symbol은 함수, 전역 변수와 정적 변수의 이름이라고 할 수 있다.
이제 생각해 볼 것은 C 언어 소스 파일을 C preprocessing, C 언어 컴파일, assemble 과정을 거치면 완전한 기계어로 바꿀 수 있느냐 하는 점이다. 완전히 기계어로 바꿀 수 있을까? C 언어 소스 파일 하나로 이루어지는 프로그램이라면 완전히 기계어로 바꾸는 것이 가능하겠지만 일반적으로는 불가능 하다. 다음과 같은 예제를 살펴보자.

int func3(void); /* func3 선언 */ extern int mydata; /* mydata 선언 */ int func2(void) /* func2 정의 */ { …. } int func1(void) /* func1 정의 */ { int i; ….. func2(); ….. func3(); …. i= mydata+3; ….. } -- end of test1.c -- start of test2.c int mydata = 3; /* mydata 정의 */ int func3(void) /* func3 정의 */ { ….. }

위의 예제를 컴파일 한다고 생각해보자. test1.c에서 func1()의 내용을 기계어로 바꾸고 싶은데 func2()를 호출하는 시점에서는 별로 문제가 안된다. func2()는 같은 소스 코드 내에 존재하고 func2()를 호출하는 instruction과 func2()의 실제 위치(어드레스)의 차이를 계산해 낼 수 있으므로 상대 어드레스를 이용하는 함수 호출 instruction으로 완전히 기계어로 바꿀 수 있다. 그런데 문제는 func3()를 호출할 때는 func3()의 실제 위치(address)를 계산할 수 없다는 문제점이 있다. 당연히 동일한 파일에 존재하는 함수가 아니므로 그 함수가 존재하게 될 어드레스를 계산할 수 없다. 어드레스를 모르는데 함수 호출 instruction을 완전히 만들 수 있을까? 만들 수 없다. 당연히 전역 변수 mydata를 access하는 부분도 마찬가지로 mydata의 어드레스를 모르므로 완전히 instruction으로 바꿀 수 없다. 그럼 어떻게 해야 될까?
그때 assembler는 그냥 함수 어드레스 없는 함수 호출 instruction을 기계어로 바꾸어 놓는다. 그런 다음에 그 instruction에 “func3()를 호출한다”라는 표지를 붙여 놓는다. 그럼 그 후의 과정(linking)에서 func3()의 address를 계산했을 때 그 빈 공간을 채워 넣게 된다. mydata와 같은 전역 변수도 마찬가지로 동작한다. test1.c을 컴파일할 때는 “func3()”, “mydata” 라는 표지를 사용해야 한다. 그럼 test2.c를 컴파일 할 때는 무엇이 필요할까? 상식적으로 생각하면 “func3()”, “mydata”가 여기 있다라는 정보를 가지고 있어야한다.
정리하면 object 파일 안에는 그 object 파일에 들어있는 symbol들(test1.o에서는 func1과 func2, test2.o에서는 func3와 mydata)에 대한 정보가 들어있고, 그 object 파일이 reference하고 있는 symbol들(test1.o에서 func3와 mydata 사용)에 대한 정보가 들어 있다.

== Relocatable의 의미
위에서 object 코드라고 하지 않고 relocatable object 코드라고 지칭했는데 relocatable이 뜻하는 것을 잠시 집고 넘어 가자. Relocatable을 사전에서 찾아보면 “재배치가 가능한” 정도의 뜻이다. “재배치가 가능한” 이라는 의미는 상당히 모호하다. 좀 더 구체적으로 말하자면 위에서 설명된 symbol들의 절대 어드레스가 정해지지 않았다는 뜻이다. 즉 test1.c의 func1()이 절대 어드레스 0x80000000에 존재해야 한다라고 정해지지 않고 어떤 절대 어드레스에 존재해도 관계 없다는 뜻이다. 그런데 이 말과 헷갈리는 말이 한가지 더 있는데 그것은 position independent code이다. C 언어 컴파일 과정에서 설명한 옵션중에 -f 시리즈가 있었다. 그 중에 -fpic라는 position independent code를 만들라고 강제하는 옵션이 있다. position independent code도 역시 절대 어드레스상에 어느 위치에 있어도 무방한 code를 지칭한다. 하지만 두 가지는 분명 차이가 있는데, 그냥 넘어가기로 하자. 쉽게 relocatable은 절대 어드레스가 결정되지 않았다는 뜻, 그러나 position independent code와는 다른 말이다.

=== Linking 과정
Linking 과정은 ld라고 하는 실행파일이 담당하고 있다. Assemble을 담당하는 as와 마찬가지로 binutils 패키지의 일부분이다. 보통 어플리케이션을 컴파일하는 경우에는 gcc(실행파일)를 이용하여 ld를 호출하나, 특별한 경우에 있어서는 ld를 직접 수행하여 linking을 하는 경우가 종종 있다.

== Linking 과정이 하는 일
　(1) 입력 : 하나 이상의 relocatable object 코드 와 library
　(2) 출력 : 실행파일(executable) 또는 relocatable object 코드
　(3) 하는 일 : symbol reference resolving & location
Linking 과정은 하나 또는 그 이상의 object 파일과 그에 따른 library를 입력으로 받는다. 출력은 보통의 경우는 실행파일(executable file)이지만, 경우에 따라서 object 파일을 생성하게 할 수도 있다. 여러 개의 object 파일을 합쳐서 하나의 object 파일로 만드는 과정을 partial linking이라고 부르기도 한다. Linking 과정이 하는 일은 symbol reference resolving하고 location이라고 했는데, 저도 정확한 단어를 적은 것인지 의심스럽다. 정확한 용어를 사용한다면 좋겠지만 그렇지 못하더라도 내용을 정확히 이해하는 것이 중요하니깐 내용에 대해서 살펴보도록 하겠다.

== symbol reference resolving
어떤 C 소스 파일에서 다른 파일에 있는 함수와 전역 변수(symbol)에 대한 참조(reference)를 하고 있다면 assemble 과정에서 완전한 기계어로 바꿀 수 없다.(실제로는 같은 소스 파일에 있는 전역 변수를 참조하는 것도 보통의 경우, 완전한 기계어로 바꿀 수 없다.) 그 이유는 당연히 assemble 까지의 과정은 단일 파일에 대해서만 진행되고, 다른 파일에 있는 해당 함수와 전역 변수의 address가 상대적이든 절대적이든 결정될 수 없기 때문이다. 따라서 완전히 기계어로 바꿀 수 없는 부분은 그대로 “공란”으로 남겨두고 표시만 해 두게 된다.
Linking 과정에서 그 “공란”을 채워 넣게 된다. 그 과정을 보통 “resolve한다”라고 말한다. 어떻게 할까? 당연히 실행 파일을 이루는 모든 object 파일을 입력으로 받기 때문에 object 파일들을 차곡 차곡 쌓아 나가면(아래 location 참조) object 파일 안에 있는 모든 symbol(함수나 전역 변수 이름)의 address를 상대적이든 절대적이든 계산할 수 있다. 이제 각 symbol의 address가 계산되었으므로 표시가 남아 있는 “공란”에 해당하는 symbol의 address를 잘 넣어주면 된다.
linking 과정에서 나올 수 있는 에러는 대부분 여기에서 발생한다. 표시가 남아 있는 “공란”을 채울 수 없는 경우가 있다. 크게 두 가지로 나누어지는데, 우선 reference하고 있는 symbol을 찾을 수 없는 경우와 reference하고 있는 symbol의 정의가 여러 군데에 있는 경우이다.

>> object파일명: In function ‘func’:
>> object파일명: undefined reference to ‘symbolname’
위의 에러 메시지는 함수 func 안에서 사용되고 있는 symbolname이란 이름의 symbol이 어디에도 정의되지 않아서 “공란”을 채울 수 없다는 뜻이다. 당연히 symbolname을 잘못 입력하였던지 아니면 그 symbol이 속해있는 object 파일이나 library와 linking되지 않았기 때문이다.

>> object파일명1: multiple definition of ‘symbolname’
>> object파일명2: first defined here
위의 에러 메시지는 symbolname이란 이름의 symbol이 여러 번 정의되고 있다는 뜻이다. object파일1에서 정의가 있는데 이미 object파일2에서 정의된 symbol이므로 그 symbol을 reference하고 있는 곳에서 정확하게 “공란”을 채울 수 없다는 뜻이다. 당연히 두 symbol중에 하나는 없애거나 static으로 바꾸거나 해야 해결될 것이다.

== location(용어 정확하지 않을 수 있음)
이전 까지 object 코드를 모두 relocatable이라고 표현했다. 아직 절대 address가 결정되지 않았다는 의미로 사용된다.(position independent code와는 다른 의미) object 코드의 절대 address를 결정하는 과정이 “location”이다. Symbol reference resolving 과정에서 입력으로 받은 모든 object 파일들을 차곡 차곡 쌓아 나간다고 했다. 그런데 object 파일이 무슨 벽돌도 아닌데 차곡 차곡 쌓는 다는 것이 말이 되나? 여기서 쌓는 다는 말을 이해하기 위해서 다음과 같은 그림(?)을 살펴 보도록 하자.

많은 object code들
----------------- address(0xAAAAAAAA+0x5000)
test2.o(size 0x3000)
----------------- address(0xAAAAAAAA+0x2000)
test1.o(size 0x2000)
----------------- address(0xAAAAAAAA)

절대 address 0xAAAAAAAA에 test1.o의 내용을 가져다 놓는다. test1.o의 크기(파일 크기와는 의미가 조금 다르지만 그냥 무시하고 파일 크기라고 생각하기 바람)가 0x2000이므로 다음에 test2.o를 쌓을 수 있는 address는 0xAAAAAAAA+0x2000가 된다. 그곳에 다시 test2.o를 쌓고 또 test2.o의 크기를 보고 새로운 address 계산하고 또 object 코드 쌓고, 계속 반복이다. 이렇게 쌓을 때 초기 절대 address 0xAAAAAAAA가 무슨 값을 가지게 되면 모든 object 파일에 있는 symbol의 절대 address도 계산해 나갈 수 있을 것이다. 그걸로 symbol reference를 resolve하게 된다. 그 초기 절대 address 0xAAAAAAAA의 값을 정하는 것을 location이라고 한다. 그럼 왜 절대 address를 결정해야 할까? 꼭 그래야 할 필요는 없지만 CPU의 instruction이 대부분의 경우 절대 address를 필요로 하는 경우가 많기 때문이라고 할 수 있다.
(주의) object 를 쌓는 것은 위의 예처럼 단순하지는 않다. 실제로는 object 전체를 쌓지 않고 object안에 있는 section별로 쌓게 된다.

그럼 이제 직접 수행해 보자.
$ gcc -o hello hello.o
object 파일이 하나라서 너무 단순하다고 생각하는가? 물론 hello.o 하나만 command line에 나타나지만 실제로는 조금 많은 object 파일이 linking되고 있다. (아래에서 좀더 자세하게 설명한다.) 지겹지만 hello를 실행해 보라. 제대로 동작하는가? 제대로 동작한다면 그 사이 어떤 일이 벌어졌을까? 그 사이에 벌어진 일을 간단히 적어보면 다음과 같다. shell이 fork() 시스템콜을 호출하고 자식 process는 exec() 시스템콜을 통해 hello라는 파일 이름을 kernel에 넘긴다. kernel에서는 hello파일을 보고 linking할 때 location된 address(여기서는 absolute virtual address 이다.)상의 메모리로 hello 파일을 복사하고 PC(program counter)값을 바꾸면 수행되기 시작한다.
(주의) 실제로 위의 hello가 수행되는 과정은 많은 생략과 누락이 있다. 실제로는 hello 파일을 완전히 메모리로 복사하는 것도 아니고, dynamic linking & loading 등의 개념이 완전히 빠져 있지만 그냥 이해하기 쉽게 하기 위해서 간단하게 적어 본 것이다.

= library
hello.o를 linking하여 hello라고 하는 실행파일을 만드는데 command line에서는 아무것도 없지만 library가 같이 linking되고 있다. 그것은 지극히 당연하다. hello.c의 main함수에서 printf함수를 호출(linking이니깐 참조 혹은 reference라고 해야 좋겠다.)하고 있는데 printf함수 자체는 소스 중에 그 어디에도 없다.(물론 stdio.h에 printf함수의 선언은 있습니다만 정의는 어디에도 없다.) 잘 알다시피 printf함수는 C standard library 안에 있는 함수이다. C standard library가 같이 linking되었기 때문에 제대로 동작하는 hello 실행파일이 생긴 것이다.
library라는 것은 아주 간단한 것이다. relocatable object 파일들을 모아 놓은 파일이다. 소스로 제공할 수도 있으나, 그러면 매번 cpp, c 컴파일, assemble 과정을 거쳐야 하므로 컴파일 시간이 매우 증가하게 된다. 그래서 그냥 relocatable object 파일로 제공하는 것이 컴파일 시간 단축을 위해서 좋다. 그런데 필요한 relocatable object 파일이 너무 많으면 귀찮으니까 그것을 묶어서 저장해 놓은 녀석이 바로 library라고 할 수 있다.
Linux를 비롯한 unix 계열에서는 대부분의 library 파일의 이름이 lib로 시작된다. 확장자는 두 가지가 있는데, 하나는 .a이고 또 하나는 .so입니다.(뒤에 library 버전 번호가 붙는 경우가 많다.) .a로 끝나는 library를 보통 archive형식의 library라고 말하며 .so로 끝나는 library를 보통 shared object라고 부른다. /lib 디렉토리와 /usr/lib 디렉토리에 가면 많이 볼 수 있다.
archive library 안에 있는 symbol를 reference하게 되면 library중에 해당 부분(object 파일 단위)을 실행 파일 안에 포함시켜 linking을 수행한다. 즉, 해당 object 파일을 가지고 linking을 수행하는 것과 동일한 결과를 가진다. 보통 이런 linking을 static linking이라고 부른다.
그런데 시스템 전체에 현재 수행되고 있는 실행파일(실행파일이 수행되고 있는 하나의 단위를 process라고 한다.)들에서 printf함수를 사용하고 있는 녀석들이 매우 많으므로 그것이 모두 실행 파일에 포함되어 있다면 그것은 심각한 메모리 낭비를 가져온다는 문제점을 가지고 있다. 그래서 생각해 낸 것이 dynamic linking이라는 개념이다. 예를 들어 실행파일이 printf함수를 사용한다면 실행파일이 메모리로 loading될 때 printf가 포함되어 있는 library가 메모리 상에 있는 지 검사를 해 보고 있으면 reference resolving만 수행하고, 아니라면 새로 loading과 reference resolving을 하게 된다. 그렇게 되면 printf가 포함되어 있는 library는 메모리 상에 딱 하나만 loading되면 되고 메모리 낭비를 막을 수 있다. 그런 일을 할 수 있도록 도입된 것이 shared object 이다. MS Windows쪽의 프로그래밍을 하시는 사람이라면 DLL과 동일한 개념이라고 보면 된다.
그런 shared object를 이용하여 dynamic linking을 하면 실행파일의 크기가 줄어든다. 반면에 당연히 실행파일이 메모리에 loading될 때는 reference resolving을 위해서 CPU의 연산력을 사용한다. 하지만 MS Windows의 DLL과는 달리 shared object 파일과 static linking을 할 수도 있다.(반대로 archive library를 이용하여 dynamic linking을 수행할 수는 없다.)

(*) -static 옵션
dynamic linking을 지원하고 있는 시스템에서 dynamic linking을 수행하지 않고 static linking을 수행하라는 옵션이다. dynamic linking을 지원하고 있는 시스템에서는 dynamic linking이 default 이다.

직접 수행해 보자.
$ gcc -o hello_static -static hello.o
실행파일 hello, hello_static 을 수행하면 결과는 똑같다. 파일의 크기를 비교해 보면 차이가 난다는 것을 알 수 있을 것이다.

/lib, /usr/lib에는 엄청 많은 library 파일들이 존재한다. 그럼 linker가 찾아야 하는 symbol을 모든 library 파일에 대해서 검사를 하는 것일까? CPU하고 HDD가 워낙 빠르면 그래도 무방하겠지만, 그렇게 하지 않는다.(“사용자가 쉽게 할 수 있는 일을 컴퓨터에게 시키지 말라.”라는 컴퓨터 사용 원칙이다.) 우선 gcc는 기본적인 library만 같이 linking을 하게 되어 있다. 나머지 library는 사용자의 요구가 있을 때만 같이 linking을 시도하도록 되어 있다. 그럼 기본적인 library가 무엇인지 알아야 하고 gcc에게 사용자의 요구를 전달할 옵션을 있어야 할 것이다. 기본적인 library는 당연히 C standard library 이다. C standard library의 이름은 libc.a또는 libc.so 이다. 최근의 linux 머신은 /lib/libc.so.6 이라는 파일을 찾아 볼 수 있을 것이다 (symbolic link되어 있는 파일이다). 그리고 libgcc라고 하는 것이 있는데… 생략하고. 이제 옵션을 알아보자.

(*) -nostdlib 옵션
이름에서 의미하는 바대로 standard library를 사용하지 말고 linking을 수행하라는 뜻이다. 실제로는 standard library 뿐 아니라 startup file이란 녀석도 포함하지 않고 linking이 수행된다. startup file에 대해서는 좀 있다가 알아보도록 하겠다.

(*) -l라이브러리이름 옵션
특정 이름의 library를 포함하여 linking을 수행하라는 뜻이다. 예를 들어 -lmyarchive라고 하면 libmyarchive.a(또는 libmyarchive.so)라는 library파일과 같이 linking을 수행하는 것이다. library 파일 이름은 기본적으로 lib로 시작하니깐 그것을 빼고 지정하도록 되어 있다.

library에 대해서 또 하나의 옵션을 알아야 할 필요가 있다. 다름 아닌 “어느 디렉토리에서 library를 찾는가”이다. 모든 library가 /lib와 /usr/lib에 있으라는 보장이 없다. 그 디렉토리를 정하는 방법은 두 가지 인데 LD_LIBRARY_PATH라고 하는 이름의 환경 변수를 셋팅하는 방법이 있고 또 한 가지는 gcc의 옵션으로 넘겨 주는 방법이 있다.

(*) -Ldir 옵션
library 파일을 찾는 디렉토리에 “dir”이란 디렉토리를 추가하라는 옵션이다.(-Idir 옵션처럼 -L과 dir을 붙여서 적습니다.) 예를 들어 -L/usr/local/mylib 라고 하면 /usr/local/mylib라는 디렉토리에서 library 파일을 찾을 수 있게 된다.

== entry 이야기
application을 작성하고 compile, linking 과정이 지나면 실행 파일이 만들어진다. 그리고 그 실행 파일이 수행될 때는 메모리로 load되어 수행이 시작된다는 사실을 알고 있다. 여기서 한가지 의문이 생기는데, “과연 코드의 어떤 부분에서 수행이 시작되는가?”이다. 답이 너무 뻔한가? main함수부터 수행된다고 답할 것인가? 다소 충격적이겠지만 “땡”이다. main함수부터 수행되지 않고 그전에 수행되는 코드가 존재한다. 그 먼저 수행되는 코드에서 하는 일은 여러 가지가 있는데 그냥 건너 뛰도록 하겠다. 아무튼 그 코드에서 main함수를 호출해 주고 main함수가 return하면 exit 시스템호출을 불러 준다. 그래서 main이 맨 처음 수행되는 것처럼 보이고 main이 return하면 프로그램 수행이 종료되는 것이다. 그럼 그 코드는 어디 있을까? 시스템에 따라서 다르겠지만 일반적으로 /lib혹은 /usr/lib 디렉토리에 crt1.o라는 이름의 object 파일이 있는데 그 object 파일 안에 있는 _start라는 이름의 함수(?)가 맨 먼저 수행되는 녀석이다. 결국 보통 application의 entry는 _start함수가 된다.
그럼 crt1.o object 파일 역시 같이 linking 되어야 한다. gcc를 이용해 linking을 수행할 때 command line에 아무 이야기를 해주지 않아도 자동으로 crt1.o 파일이 함께 linking 된다. 실제로는 crt1.o 뿐 아니라 비슷한 crt*.o 파일들도 같이 linking 된다. 그렇게 같이 linking 되고 있는 object파일들을 startup file이라고 부르는 것 같다.(-nostdlib 옵션 설명할 때 잠시 나왔던 startup file이 바로 이 녀석들이다.) 그럼 ld는 _start파일이 entry인지 어떻게 알고, 다른 이름의 함수를 entry로 할 수는 없는것일까? 그것에 대한 해답은 아래 linking script부분에서 해결될 것이다.

== 실행 파일에 남아 있는 정보
linking의 결과 실행파일이 생겼는데, 보통 linux에서는 실행파일 형식이 ELF라는 포멧을 가진다.(linux 시스템에 따라 다를 수 있다.) ELF는 Executable and Linkable Format의 약자이다. 보통 linux 시스템에서의 relocatable object 파일의 형식도 ELF이다. 실제로 실행파일과 relocatable object 파일과는 조금 다른 형식을 가진다. 암튼 그건 상식으로 알아두고, 그럼 실행파일에 있는 정보는 무엇일까?
이제까지의 알아낸 정보들을 모두 종합하면 알 수 있다. 우선 실행 파일이라는 녀석이 결국은 relocatable object 를 여러 개 쌓아놓은 녀석이므로 원래 relocatable object 파일이 가지고 있던 code와 data 정보는 모두 남아있을 것이다. 그리고 entry를 나타내는 address가 있어야 수행을 할 수 있을 것이다. 또, dynamic linking을 했을 경우 관련된 shared object 정보도 남아있어야 한다.
실행 파일 속에 남아있는 data는 relocatable object에 있는 data처럼 프로그램 수행에 필요한 data가 있고 그냥 실행 파일을 설명하는 정보로서의 data가 있다. 예를 들어 -g 옵션을 주고 컴파일한 실행파일에서 디버깅 정보들은 실행과는 전혀 관계 없다. 따라서 그러한 정보들은 실행 파일 수행시에 메모리에 load될 필요도 없다.(load하면 메모리 낭비니깐) 실행 파일 속에 남아있는 code와 data는 relocatable object 처럼 특별한 단위로 저장되어 있다. ELF 표준에서는 segment라고 부르는데 보통의 경우는 object 파일처럼 section이라는 말이 쓰인다. reloctable object 파일과 마찬가지로 code는 text section에 저장되고 프로그램 수행 중에 필요한 data가 성격에 따라 나누어져 data, rodata, bss section이란 이름으로 저장되어 있다. 그 section단위로 메모리로 load될 필요가 있는지에 대한 flag정보가 있고 각 section이 load될 address(location과정에서 정해진다.)가 적혀 있어야 정확하게 loading을 할 수 있다.
기타로 symbol reference resolving이 끝났는데도 ELF형식의 실행파일은 보통의 경우 많은 symbol 정보를 그냥 가지고 있는 경우가 있다. symbol 정보 역시 수행에는 하등 관계가 없으므로 없애도 되는데, strip이라고 하는 binutils안에 있는 tool로 없앨 수 있다.

== linking script
흠 이제 좀 어려운 이야기를 할 차례이다. Location과정에서 어떤 절대 address를 기준으로 각 section들을 쌓는지, 그리고 entry는 어떤 symbol인지에 대한 정보를 linker에게 알려줄 필요가 있다. 보통 application의 경우는 시스템 마다 표준(?, 예를 들어 entry는 _start 다 하는 식)이 있는지라 별로 문제될 것은 없는데, bootloader나 kernel을 만들 때는 그런 정보를 사용자가 넘겨 주어야 할 필요가 있다. 그런 것들을 ld의 command line argument로 넘길 수도 있지만 보통의 경우는 linking script라고 하는 텍스트 형식의 파일 안에 저장하여 그 script를 참조하라고 알려준다. (아무래도 command line argument로 넘겨 줄 수 있는 정보가 한계가 있기 때문이라고 생각이 든다. location과 entry에 관한 내용 중에 ld의 command line argument로 줄 수 있는 옵션이 몇가지 있으나 한계가 있다.) ld의 옵션 -T으로 linking script 파일 이름을 넘겨 주게 된다.(gcc의 옵션 아님) linux kernel source를 가지고 있는 사람은 arch/*/*.lds 파일을 한번 열어 보길 바란다. 그게 linking script고, 초기 절대 address 하고 section 별로 어떻게 쌓으라는 지시어와 entry, 실행 파일의 형식 등을 적어 놓은 내용이 보일 것이다. 물론 한 줄 한 줄 해석이 된다면 이런 글을 읽을 필요가 없다. 그 script를 한 줄 한 줄 정확히 해석해 내려면 GNU ld manual 등을 읽어야 할 것이다.

== linux의 insmod
linux kernel을 구성하고 device driver 등은 linux kernel module(이하 module) 형식으로 run-time에 올릴 수 있다는 것을 알고 있을 것이다. module을 run-time에 kernel에 넣기 위해서 사용하는 명령어가 insmod이다.(modprobe도 가능) 이 module 이라는 것이 만들어 지는 과정을 잘 살펴 보면 gcc의 옵션중에 -c옵션으로 컴파일만 한다는 것을 알 수 있다. 확장자는 .o를 사용한다. relocatable object 파일이고, ELF형식이다. 그럼 이 module이 linux kernel과 어떻게 합쳐질까? 당연히 linking 과정을 거쳐야 된다. 일종의 run-time linking 이다. 당연히 module은 kernel내의 많은 함수와 전역 변수를 참조한다. 그렇지 않다면 그 module은 linux kernel의 동작과는 전혀 관계 없는 의미 없는 module이 될것이다. 그럼 참조되고 있는 symbol을 resolving하기 위해서는 symbol의 절대 address를 알아야한다 . 그 내용은 linux kernel 내부에 table로 존재한다. /proc/ksyms라고 하는 파일을 cat 해보면 절대 address와 symbol 이름을 살펴볼 수 있을 것이다. 살펴보면 알겠지만 생각보다 적은 양이다. 적은 이유는 그 table이 linux kernel source에 있는 전역 symbol의 전부를 포함한 것이 아니라 kernel source 내부나 module 내부에서 EXPORT_SYMBOL()과 같은 특별한 방법으로 선언된(?, 이 선언은 C 언어 문법의 declaration과는 다르다.) symbol들만 포함하기 때문이다. 다른 전역 symbol 들은 module 프로그래밍에 별 필요가 없다고 생각되어 지는 녀석들이기 때문에 빠진 것이다. 따라서 EXPORT_SYMBOL()등으로 선언된 symbol들만 사용하여 module을 작성해야 한다. 당연히 linking 과정을 거치기 때문에 앞서 설명한 linking에서 발생할 수 있는 에러들이 발생할 수 있다. 제일 많이 발생할 수 있는 것은 역시 undefined reference 에러이다. gcc의 에러와는 조금 다른 메시지가 나오겠지만 결국은 같은 내용이다.

== map 파일
linking 과정을 끝내면 당연히 모든 symbol에 대한 절대 address가 정해지게 된다. 그 정보를 알면 프로그램 디버깅에 도움이 될 수도 있으니 알면 좋을 것이다. ld의 옵션중에 '-Map 파일이름'이라는 옵션이 있는데 우리가 원하는 정보를 문서 파일 형식으로 만들어 준다. 그 파일을 보통 map 파일이라고 부른다. symbol과 address 정보 말고 section에 대한 정보도 있고 많은 정보가 들어 있다.
linux kernel을 컴파일을 하고 나면 나오는 결과 중에 System.map이라는 파일이 있는데 이 녀석이 바로 ld가 만들어 준 map 파일의 내용 중에 symbol과 symbol의 절대 address가 적혀 있는 파일이다. linux kernel panic으로 특정 address에서 kernel이 죽었다는 메시지가 console에 나오면 이 System.map 파일을 열어서 어떤 함수에서 죽었는지 알아볼 수도 있다.

== 옵션 넘기기
gcc의 이야기 맨 처음에 gcc는 단순히 frontend로 command line으로 받은 옵션을 각 단계를 담당하고 있는 tool로 적절한 처리를 하여 넘겨준다고 말했었다. 위에서 나온 ld의 옵션 -T와 -Map 과 같은 옵션은 gcc에는 대응하는 옵션이 존재하지 않는다. 이런 경우 직접 ld를 실행할 수도 있고 gcc에게 이런 옵션을 ld에게 넘겨 주라고 요청할 수 있다. 하지만 application을 컴파일할 때는 ld를 직접 실행하는 것은 조금 부담이 되므로, gcc에 옵션을 넘기라고 요청하는 방법이 조금 쉽다고 볼 수 있다. 그런 경우 사용되는 것이 -Wl 옵션인데 간단히 이용해 보도록 하자.
$ gcc -o hello -static -Wl,-Map,hello.map hello.c
그럼 hello.map이라는 매우 큰 문서 파일이 만들어진다. 한번 살펴 보도록 하자.(-static 옵션을 안 넣으면 살펴볼 내용이 별로 없을까봐 추가했다.)
실제로는 -Wl 옵션처럼 as에게도 옵션을 넘겨 줄 수 있는 -Wa와 같은 옵션이 있는데 쓰는 사람을 본 적이 없다.

http://www.michaelboman.org/books/sql-injection-cheat-sheet-oracle

http://www.michaelboman.org/books/sql-injection-cheat-sheet-mssql

http://www.michaelboman.org/books/sql-injection-cheat-sheet-mysql

http://www.michaelboman.org/books/sql-injection-cheat-sheet-postgresql

http://www.michaelboman.org/books/sql-injection-cheat-sheet-db2

http://www.michaelboman.org/books/sql-injection-cheat-sheet-ingres

http://hack3r.tistory.com/entry/Informix-SQL-Injection-Cheat-Sheet

http://hack3r.tistory.com/entry/DB2-SQL-Injection-Cheat-Sheet

http://hack3r.tistory.com/entry/Ingres-SQL-Injection-Cheat-Sheet

http://hack3r.tistory.com/entry/Postgres-SQL-Injection-Cheat-Sheet

http://hack3r.tistory.com/entry/MySQL-SQL-Injection-Cheat-Sheet

http://hack3r.tistory.com/entry/MSSQL-Injection-Cheat-Sheet

http://hack3r.tistory.com/entry/Oracle-SQL-Injection-Cheat-Sheet 
 

http://zerohz.tistory.com/61 
http://blog.naver.com/PostView.nhn?blogId=hypermin&logNo=70069184103


1.어셈블리어
Push  : sp 레지스터를 조작하는 명령어중의 하나이다.
       스택에 데이터를 저장하는데 쓰인다.
ex:) Push eax : 스택에 Eax의 값을 스택에 저장한다.
ex:) Push 20 :즉석값인 20을 스택에 저장한다.
ex:) Push 401F47 : 메모리 오프셋 401F47의 값을 스택에 저장한다.

Pop  : 이또한 sp 레지스터를 조작하는 명령어중 하나이다.
스택에서 데이터를 꺼내는데 쓰인다.
ex:) Pop eax :스택에 가장 상위에 있는 값을 꺼내애서 eax에 저장한다.
주의점 : Push 의 역순으로 값은 스택에서 Pop 된다.

Mov  : 메모리나 레지스터의 값을 옮길 때[로 만들 때]쓰인다.
ex:) Mov eax,ebx    :ebx 레지스터의 값을 eax로 옮긴다[로 만든다].
ex:) Mov eax,20     :즉석값인 20을 eax레지스터 에 옮긴다[로 만든다].
ex:) Mov eax,dword ptr[401F47]   :메모리 오프셋 401F47 의 값을 eax에 옮긴다[로 만든다]

Lea  : 오퍼렌드1의 값을 오퍼렌드2의 값으로 만들어준다.
ex:) Lea eax,ebx    : eax레지스터의 값을 ebx의 값으로 만든다.

Inc  : 레지스터의 값을 1증가 시킨다.
ex:) Inc eax  : Eax 레지스터의 값을 1증가 시킨다.
Dec  : 레지스터의 값을 1 감소 시킨다.
ex:) Dec eax : Eax 레지스터의 값을 1 감소 시킨다.

Add  : 레지스터나 메모리의 값을 덧셈할떄 쓰임.
ex:) Add eax,ebx   :Eax 레지스터의 값에 ebx 값을 더한다.
ex:) Add eax,50    :Eax 레지스터에 즉석값인 50을 더한다.
ex:) Add eax,dword ptr[401F47]  : Eax 레지스터에 메모리 오프셋 401F47의 값을 더한다.
Sub  : 레지스터나 메모리의 값을 뻇셈할떄 쓰임.
ex:) Sub eax,ebx   : Eax 레지스터에서 ebx 레지스터의 값을 뺸다.
ex:) Sub eax,50
Eax  : 레지스터에서 즉석값 50을 뺸다.
ex:) Sub eax,dword ptr[401F47]    :Eax 레지스터에서 메모리 오프셋 401F47의 값을 뺸다.
Nop  : 아무동작도 하지 않는다. : 90
Call : 프로시저를 호출할떄 쓰인다.
ex:) Call dword ptr[401F47]    : 메모리 오프셋 401F47을 콜한다.
Ret : 콜한 지점으로 돌아간다.
Cmp : 레지스터와 레지스터혹은 레지스터 값을 비교하기위하여 쓰인다.
ex:) Cmp eax,ebx    :Eax 레지스터와 Ebx 레지스터의 값을 비교한다.
ex:) Cmp eax,50     :Eax 레지스터와 즉석값 50을 비교한다.
ex:) Cmp eax,dword ptr[401F47]
:Eax 레지스터와 메모리 오프셋 401F47의 값을 비교한다.
Jmp : 특정한 메모리 오프셋으로 이동할떄 쓰인다.
ex:) Jmp dword ptr[401F47]   :메모리 오프셋 401F47 로 점프한다.
조건부 점프: Cmp나 Test 같은 명령어의 결과에 따라점프한다.
  Je  : Cmp나 Test 의 결과가 같다면 점프
  Jne : Cmp나 Text 의 결과가 같지 않다면 점프
  Jz  : 왼쪽 인자의 값이 0 이라면 점프
Jnz  : 왼쪽 인자의 값이 0 이 아니라면 점프
Jl   : 왼쪽 인자의 값이 오른쪽 인자의 값보다 작으면 점프(부호있는)
Jnl  : 왼쪽 인자의 값이 오른쪽 인자의 값보다 작지 않으면(크거나 같으면) 점프 (부호있는)
Jb   : 왼쪽 인자의 값이 오른쪽 인자의 값보다 작으면 점프(부호없는)
Jnb  : 왼쪽 인자의 값이 오른쪽 인자의 값보다 작지 않으면(크거나 같으면) 점프 (부호없는)
Jg   : 왼쪽 인자의 값이 오른쪽 인자의 값보다 크면 점프
Jng  : 왼쪽 인자의 값이 오른쪽 인자의 값보다 크지 않으면 (작거나 같으면) 점프
Jle   : 왼쪽 인자의 값이 오른쪽 인자의 값보다 작거나 같으면점프 (부호있는)
Jge  : 왼쪽 인자의 값이 오른쪽 인자의 값보다 크거나 같으면 점프
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
약 이정도의 명령어들이 가장 많이 나오는 것들임으로
최소한 위에 나온것들은 외워 두도록 하자.
3. 논리연산
이글에서는 5가지 논리연산에 대해서 쓸것이다.
논리연산자는 두 오퍼렌드의 값의 비트들을 대응시켜 명령에 따른 적절한 값을 구하여 첫번쨰 오퍼렌드의 값을 바꾸어 주는것이다.
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
AND 연산
대응되는 비트가 둘다 1이면 결과는 1이고 그외의 결과들은 모두 0 이 된다.
ex:) MOV EAX,8
AND EAX,10 :위를 계산하기 위해 우선 두 오퍼렌드의 값을 2진수로 바꾸어 주면 8은 1000 이 되고 10은 1010 이 되고 AND 연산은 둘다 1이여야 1이 됨으로 결과는 1000 이 됩니다.

OR 연산
대응되는 비트중 하나가 1 또는 둘다 1이면 결과는 1이고 그외는 모두 0이 된다.
ex:) MOV EAX,8
OR EAX,10
:위를 계산하기 위해 두 오퍼렌드의 값을 2진수로 바꾸어 주면 8은 1000이 되고 10은 1010이 되고 OR 연산은 한쪽 또는 양쪽둘다 1이면 1이고그외는 모두 0 임으로 결과는 1010이 된다.
XOR 연산
대응되는 비트 중에서 한비트가 1이고 다른 비트가 0이면 1이 되고 두개의 비트가 1이면 0 이 되고 두개다 0 이어도 0이 된다.
ex:) MOV EAX,8
XOR EAX,10
:위를 계산하기 위해 두 오퍼렌드의 값을 2진수로 바꾸어 주면 8은 1000이 되고 10은 1010이 되고 XOR 연산은 한쪽만 1이어야 1임으로 결과는 10이 된다.

NOT 연산
NOT 연산은 오퍼렌드의 값을 반대로 하여 준다.
ex:) MOV EAX,10
NOT EAX
:위를 계산하기 위해 오퍼렌드의 값을 2진수로 바꾸어 주면 10은 1010이 되고 NOT 연산은 1 과 0을 반대로 하여 줌으로 결과는 0101 이 된다.
*Test 연산은 오퍼렌드에 영향을 주지 않으며 플래그만 세트 시키어 준다.

 

 

 

 

2.레지스터
범용 레지스터
(1) Eax 레지스터
누산기인 Eax 레지스터는 입출력과 거의 모든 산술연산에 사용된다. 곱셋과 나눗셈, 변환 명령어등은 반드시 Eax 레지스터를 필요하게 된다.

Eax 레지스터는 32bit의 레지스터이고 16bit 의 레지스터로 ax가 있다.
(ax는 왼쪽의 ah와 오른쪽의 al로 이루어져 있다)
 (2) Ebx 레지스터
Ebx는 주소지정을 확대하기 위한 인덱스로서 사용될수 있는 유일한 범용 레지스터 이며, 다른 일반적인 계산 용도로도 쓰인다.
Ebx는 32bit 레지스터이고 16bit로 eb가 있다.
(eb는 왼쪽의 bh와 오른쪽의 bl로 이루어져 있다)
(3) Ecx 레지스터
Ecx는 루프의 반복 횟수나 좌우방향의 시프트 비트 수를 기억한다. 그외의 계산에도 사용된다.
Ecx는 32bit 레지스터이고 16bit로 cx가 있다.
(cx는 왼쪽의 ch와 오른쪽의 cl로 이루어져 있다.)
(4) Edx 레지스터
Edx는 몇몇 입출력 동작에서 사용 된다.
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
플래그 레지스터
(1) OF [Over Flow]
산술연산후 상위 비트의 오버플로를 나타냄
(2) DF [Direction]
스트링 데이터를 이동하거나 비교할떄 왼쪽 또는 오른쪽으로의 방향을 결정한다.
(4) SF [Sign]
산술결과의 부호를 나타낸다.[0=양수,1=음수]
(5) ZF [zero]
산술연산 또는 비교동작의 결과를 나타낸다.
[0=결과가 0이 아님,1=결과가 0임]

(6) CF [Carry]
산술연산후 상위 비트로부터의 캐리 그리고 시프트 또는 회전동작의 결과 마지막 비트
내용을 저장한다.

(7) TF [trap]
프로세서가 단일 스텝 모드(single-step mode)를 동작할수 있도록 해준다.

 

 

 

 

 

 

 

 

 

5. Assembly 명령어

 

MOV <Destination>, <Source> - Move. 값을 대입하려고 할때 사용한다. 사용 방법에는 <Destination>에는 레지스터, 메모리등이 올 수 있으며 <Source>에는 <Destination>와 같은 것 이외에 직접적인 값 등이 올 수 있다.
Example:
MOV EAX, 14h
MOV EAX, DWORD PTR SS:[EBP-14]
MOV DWORD PTR SS:[EBP-14], EDX

 

MOVS, MOVSB, MOVSW, MOVSD(Move String Byte or Word or DWord) - ESI가 가르키는 곳의 값들을 Byte(1byte), Word(2byte), DWord(4byte)크기만음 EDI가 가르키는 곳으로 이동시킨다.

MOVSX(Move with Sign-Extended) - Byte나 Word크기의 Operand를 Word나 DWord사이즈로 늘려준다. 부호는 유지된다.

 

MOVZX(Move with Zero-Extended) - Byte나 Word크기의 Operand를 Word나 DWord사이즈로 늘려준다. 연산 후 채워지지 않은 공간에는 0으로 매꾼다.

 

INT <Value> - Interrupt. 해당 Value에 따른 Interrupt를 발생시킨다. <Value>에 해당하는 것들이 너무 많으므로 다음에 더욱 자세하게 다루기로 하자.
Example:
INT 21h

 

ADD <Destination>, <Source> - Addition. 간단하다. <Destination>+<Source>한 값을 <Destination>에 저장한다. <Destination>에는 레지스터, 메모리등이 올 수 있으며 <Source>에는 <Destination>와 같은 것 이외에 직접적인 값 등이 올 수 있다.
Example:
MOV EAX, 5h
MOV EBX, 12h
ADD EAX, 5h  ; EAX에는 5h + 5h = Ah(10진수로 10)가 저장된다.
ADD EAX, EBX ; EAX에는 Ah + 12h = 1Ch(10진수로 28)가 저장된다.

 

SUB <Destination>, <Source> - Subtact. ADD명령어와 사용법은 동일하다. 단지 기능은 빼주는 역할이라는거!
Example:
MOV EAX, 4h
SUB EAX, 3h ; EAX에는 4h - 3h = 1h가 저장된다.

 

INC <Target> - Increments. 타겟의 값에서 1을 증가시킨다. <Target>에는 레지스터, 메모리등이 올 수 있으며, 직접적인 값은 불가능하다.
Example:
MOV EAX, 4h
INC EAX     ; EAX에는 4h에서 1증가된 값인 5h가 저장된다.

 

DEC <Target> - Decrements. 타겟의 값에서 1을 감소시킨다. <Target>에는 레지스터, 메모리등이 올 수 있으며, 직접적인 값은 불가능하다.
Example:
MOV EAX, 4h
DEC EAX     ; EAX에는 4h에서 1감수한 값인 3h가 저장된다.

 

JMP <Location> - Jump. 어떠한 장소로 점프한다. 쉽게 생각해서 GOTO문을 생각하면 될것이다. <Location>에는 점프할 곳의 코드주소를 담고있는 레지스터나 메모리등이 올 수 있다.
Example:
JMP 0041D983
JMP DWORD PTR SS:[EBP-14]

 

** Conditional JUMP **

 

JMP명령어와 같다. 단지 조건에 따라서 Jump할지 안할지가 결정되므로 Conditional Jump라고 하겠다. Conditional JUMP는 CMP명령어와 같이 사용된다.

 

CMP <Target1>, <Target2> - 두 타겟을 비교해서 Flag Register를 변경시킨다. <Target1>이 <Target2>보다 작으면 CF가 Set되고, 같으면 ZF가 Set되고 이런것 들이 있긴하지만, 다음에 왠만하면 Conditional Jump가 있기때문에 Jump문 의미로 이해하도록 하고 CMP로 인한 Flag 변화는 그냥 넘어가도록 하겠다.
Example:
CMP EAX, EBX

 

Unsigned
JA(JUMP if ABOVE)                                     CF=0 and ZF=0
JAE(JUMP if ABOVE or EQUAL)                    CF=0
JB(JUMP if BELOW)                                     CF=1
JBE(JUMP if BELOW or EQUAL)                    CF=1 and ZF=1
JNA(JUMP if NOT ABOVE)                            CF=1 or ZF=1
JNAE(JUMP if NOT ABOVE or EQUAL)           CF=1
JNB(JUMP if NOT BELOW)                            CF=0
JNBE(JUMP if NOW BELOW or EQUAL)          CF=0 and ZF=0
JE(JUMP if EQUAL)                                      ZF=1
JNE(JUMP if NOT EQUAL)                             ZF=0

Signed
JG(JUMP if GREATER)                                 ZF=0 and SF=OF
JGE(JUMP if GREATER or EQUAL)                SF=OF
JL(JUMP if LOWER)                                     SF!=OF
JLE(JUMP if LOWER or EQUAL)                    ZF=1 and SF!=OF
JNG(JUMP if NOT GREATER)                        ZF=1 or SF!=OF
JNGE(JUMP if NOT GREATER or EQUAL)       SF!=OF
JNL(JUMP if NOT LOWER)                            SF=OF
JNLE(JUMP if NOT LOWER or EQUAL)           ZF=0 and SF=OF
JE(JUMP if EQUAL)                                     ZF=1
JNE(JUMP if NOT EQUAL)                            ZF=0

Flag
JC(JUMP if CARRY flag set)                        CF=1
JNC(JUMP if NOT CARRY flag set)               CF=0
JO(JUMP if OVERFLOW flag set)                  OF=1
JNO(JUMP if NOT OVERFLOW flag set)         OF=0
JP(JUMP if PARITY flag set)                        PF=1
JNP(JUMP if NOT PARITY flag set)               PF=0
JPE(JUMP if PARITY is EVEN)                     PF=1
JPO(JUMP if PARITY is ODD)                      PF=0
JS(JUMP if SIGNAL flag set)                       SF=1
JNS(JUMP if NOT SIGNAL flag set)              SF=0
JCXZ(JUMP if CX is ZERO)                       CX=0

AND <Destination>, <Source> - Logical AND. 논리회로에 있어서의 AND연산을 수행한다. 그리고 AND연산을 시행할때, OF, CF는 초기화되고, ZF는 Set될 수 있다.
Example:
AND EAX, EBX

CALL <Location> - Call. 말그대로 함수를 부를때 사용한다. Jump와 같다고 느껴질지도 모르지만 Call문을 시행할 경우 스택에 Call문이 시행된것을 Push를 하며 Return이 가능하다.
Example:
CALL 0041D983
CALL DWORD PTR [EBX]

DIV <Target> - Division. EAX를 <Target>으로 나누는 연산이다. 결과로 몫은EAX에 나머지는 ECX에 들어간다.
Example:
MOV EAX, 64h
MOV ECX, 9h
DIV ECX       ; 64h(100) / 9h(9) = 몫 : 0Bh(11) , 나머지 1h이므로
                EAX = 0Bh, ECX = 1h가 저장된다.

 

IDIV <Target> - Integer Division. DIV와 똑같다. 하지만 다른점은 부호있는 정수를 다룬다는 점이다.

 

MUL <Target> - Multiplication. EAX와 <Target>을 곱하여 EAX에 저장한다.
Example:
MOV EAX, 2h
MUL 4h       ; EAX에는 2h * 4h = 8h가 저장된다.

 

IMUL <Value> - Integer Multiplication. EAX와 <Value>를 곱하여 EAX에 저장한다.
IMUL <Destination>, <Value> - <Destination>과 <Value>를 곱하여 <Destination>에 저장한다.
IMUL <Destination>, <Value>, <Value> - 2개의 <Value>를 곱한 후에 <Destination>에 저장한다.

 

LEA <Destination>, <Source> - Load Effective Address. <Source>의 실제 주소를 <Destination>에 저장한다. 하지만 이 용도보다는 빠른 계산을 위해 주로 사용된다. 예를들어 LEA EAX, DWORD PTR [2*EAX+ECX]를 하면, EAX에 2*EAX+ECX계산값이 들어가게 된다.

 

NOP - No Operation. 아무것도 하지 않는다.

 

OR <Destination>, <Source> - Logical OR. 논리회로에 있어서의 OR연산을 수행한다. 그리고 OR연산을 시행할때, OF, CF는 초기화되고, ZF는 Set될 수 있다.
Example:
OR EAX, EBX

 

POP <Destination> - POP. 스택에서 ESP가 가르키는 곳에서 주소값을 불러내어 <Destination>에 저장한다. 그리고 ESP는 다음값을 가르키게 된다.
Example:
POP EAX

 

PUSH <Source> - 스택에 <Source>를 집어넣는다. ESP는 최근에 PUSH한 값을 가르키게 된다.
Example:
PUSH EAX

 

RET - Return. 스택에서 주소를 POP해온 후 그 주소로 돌아간다. PUSH와 RET을 조합해서 JMP처럼 사용 할 수 있다.

 

TEST <Target1>, <Target2> - 이 연산은 대부분이 <Target1>과 <Target2>가 같게 설정된다. 예를들면 TEST EAX, EAX. 이 연산은 논리회로의 AND연산을 수행하지만 결과값을 저장하지 않는다. 단지 EAX=0일경우 ZF=1이 되고 EAX!=0일경우 ZF=0이 된다. 그리고 OF, CF는 0이된다.
Example:
TEST EAX, EAX

 

XOR <Destination>, <Source> - Logical Exclusive OR. 논리회로에 있어서 XOR연산을 수행한다. XOR연산을 시행할때, OF, CF는 초기화되고, ZF는 Set될 수 있다. 이 연산은 XOR EAX, EAX처럼 많이 사용되는데, 이렇게 할 경우 XOR=0이 된다. 이유는 직접 해보면 알것이다.
Example:
XOR EAX, EBX
XOR EAX, EAX     ; EAX=0이 됨.

 

LODS, LODSB, LODSW, LODSD(Load String Byte, Word, DWord) - ESI가 가르키는 곳에서 지정한 크기(Byte, Word, DWord) 만큼 읽어와 EAX에 복사한다. ESI는 복사한만큼 이동한다.

 

STOS, STOSB, STOSW, STOSD(Store String Byte, Word, DWord) - EAX에 들어이있는 데이터를 지정한 크기만큼 EDI가 가르키는 주소에 복사한다. EDI는 복사된 만큼 이동한다.

 

CLD(Clear Direction flag), STD(Set Direction flag) - Direction Flag를 Set하거나 Clear할때 사용한다.

 

CMC(Complement Carry flag), CLC(Clear Carry flag), STC(Set Carry flag) - Carry flag를 순서대로 반전, Clear, Set시킨다.

 

SHL <Destination>, <Value> - Shift Logical Left. <Destination>에 <Value>만큼 Shift연산을 왼쪽으로 수행한다. 만약 <Destination>보다 커질경우 CF=1이 된다.

 

SHR <Destination>, <Value> - Shift Logical Right. SHL과 기능은 동일하며 Shift연산이 오른쪽으로 진행된다.

 

ROL <Destination>, <Value> - Rotate Left. SHL과 기능은 동일하다. 단지 자리수가 늘어날경우 해당 비트가 오른쪽 끝으로 이동한다.

 

ROR <Destination>, <Value> - Rotate Reft. SHR과 기능은 동일하다. 단지 자리수가 없어질경우 해당 비트가 왼쪽 끝으로 이동한다.

 

1. 나눗셈 연산의 피젯수는(32bit의 나눗셈을 가정) 항상 edx:eax 이다.
2. cdq 는 나눗셈을 위해 피젯수의 사이즈를 확장하는 것이다.

나눗셈연산(div, idiv)은 eax와 edx에 의해서만 이루어집니다
- 피젯수(나눔을 당하는 수) 는 eax, edx에만 들어갈 수 있다는 얘기에요
16 / 5 연산을 한다고 가정해 봅시다.

16과 5 둘다 32bit data라고 가정하구요

그럼 일단 eax에 16을 넣습니다. 그 다음 ebx(다른레지스터나 메모리도 상관없음)에

5를 넣습니다. 그 다음 div 연산을 하면.........될것 같지만 안됩니다..

일반적으로 제수(여기서는 5)가 32bit이면 피젯수(여기서는 16) 는 64bit가 되어야

32bit 값을 가지는 몫을 얻을 수 있습니다.

그래서 피젯수의 bit를 확장 시켜주는것이 바로 cdq 연산입니다

32bit 크기의 eax의 값을 64bit의 값인 edx:eax로 만들어줍니다.

여기서 edx는 상위자리가되고 eax는 하위 자리가 되죠

자..그럼 cdq 연산까지 끝났으면 edx:eax에 16이 들어가있고 ebx에 5가 들어있겠네요

그럼 idiv연산을 해봅시다(div는 부호가없는 나눗셈 idiv 부호가 있는 나눗셈)

그럼 몫과 나머지가 나와야 하겠죠? 그 결과는 다시 eax와 edx로 들어가는데

eax에는 몫이, edx에는 나머지 부분이 들어갑니다~

 

LoadLibrary GetProcAddress (로드 라이브러리 겟프락어드레스) 후에 변하지 않는 레지스터는
EBX EBP ESI EDI 이다. EAX, ECX, EDX 가 변한다

Header Signature (Hex)	File Type	Description
xx xx xx xx AF 11	FLI	Graphics - Autodesk Animator
xx xx xx xx AF 12	FLC	Graphics - Autodesk 3D Studio
xx xx 2D 6C 68 35 2D            -   1   h   5  -	LZH	Archive - LHA Compressed Archive File
00	PIF   PIC  YTR	Windows - Program Information File  Graphics - IBM Storyboard Bitmap File  IRIS OCR Data File
00 00 00 02	MAC	Graphics - MAC Picture Format
00 00 00 nn 66 74 79 70                    f   t   y   p  33 67 70   3  g  p	3GG  3G2	3rd Generation Partnership Project 3GPP (nn=0x14)  3GPP2 (nn=0x20) Multimedia File
00 00 00 18 66 74 79 70                    f   t   y   p  33 67 70 35   3  g  p   5	MP4	MPEG-4 Video File
00 00 01 00	ICO	Graphics - Windows Icon Format
00 00 01 Bx	MPG	MPEG Video File
00 00 02 00	CUR  WB2	Graphics - Windows Cursor File  Spreadsheet  - QuattroPro
00 00 02 00 04 04	WKS	Spreadsheet - Lotus 1-2-3
00 00 02 00 05 04	WRK	Spreadsheet - Symphony
00 00 02 00 06 04	WK1  WR1	Spreadsheet - Lotus 1-2-3  Spreadsheet - Symphony
00 00 1A 00 00 10	WK3	Spreadsheet - Lotus 1-2-3
00 00 1A 00 02 10	WK4	Spreadsheet - Lotus 1-2-3
00 00 49 49 58 50 52           I   I   X  P  R	QXD	Quark Express Document (dependant endian)  Note: It appears that the byte following the 0x52  ("R") is the languate indicator; 0x33("3") seems to   indicate English and 0x61("a") reportedly indicates  Korean
00 00 49 49 58 50 52          M  M  X  P  R	QXD	Quark Express Document (dependant endian)  Note: It appears that the byte following the 0x52  ("R") is the languate indicator; 0x33("3") seems to   indicate English and 0x61("a") reportedly indicates  Korean
00 00 EF FF		Byte-order mark for 32-bit Unicode Transformation  Format
00 01 00 00 4D 53 49 53                   M  S   I  S  41 4D 20 44  61 74 61 74   A  M      D   a   t   a   b  61 62 61 73 65   a  s  e	MNY	Microsoft Money File
00 01 00 00 53 74 61 72                    S   t   a  n   64 61 72 64 20 4A 65 74   d  a   r   d     J   e   t   20 44 42        D  B	MDB	Database - Microsoft Access File
00 01 00 08	IMG	Graphics - GEM Image Format
00 01 01	FLT	Graphics - OpenFlight 3D File
00 01 42 41          B  A	ABA	Palm Address Book Archive File
00 01 42 44          B  D	DBA	Palm DataBook Archive File
00 06 15 61 00 00 00 02  00 00 04 D2 00 00 10 00	DB	Database - Netscape Navigator (v4)
01 11 AF	FLI	Graphics - FLIC Animation File
00 1E 84 90 00 00 00 00	SNM	Netscape Communicator (v4) Mail Folder
00 5C 41 B1 FF	ENC	Mujahideen Secrets 2 Encrypted File
00 6E 1E F0                    (offset : 512 bytes)	PPT	PowerPoint Presentation SubHeader
01 00 00 00	EMF  PIC	Extended(Enhanced) Windows Metafile Format  Printer Spool File (0x18-17 & 0xC4-36 : Win2K/NT,  0x5C0-1 : WinXP)  Spreadsheet Graph - Lotus 1-2-3
01 10	TR1	Novell LANalyzer Capture File
01 DA 01 01 00 03	RGB	Graphics - Silicon Graphics RGB Bitmap File
01 FF 02 04 03 02	DRW	Graphics - Micrografx Vector Graphics File
02 64 73 73       d   s  s	DSS	Graphics - Digital Speech Standard  (Olympus, Grundig & Phillips)
02	DBF	Database - dBASE II
03	DBF  DAT	Database - dBASE III  Database - dBASE IV  MapInfo Native Data Format
03 00 00 00	QPH	Quicken Price Histroy File
03 00 00 00 41 50 50 52                  A  P  P  R	ADX	Approach Index File
04	DB4	Database - dBASE IV Data File
07	DRW	A common signature may drawing programs
07 64 74 32 64 64 74 64       d   t   2  d  d   t   d	DTD	DesignTools 2D Design File
08	DB	Database - dBASE IV  Database - dBFast Configuration File
09 00 04 00 07 00 01 00	XLW	Spreadsheet - Excel BIFF2
09 02 06 00 00 00 01 00	XLW	Spreadsheet - Excel BIFF3
09 03 06 00 00 04 00 01	XLW	Spreadsheet - Excel BIFF4
0A nn 01 01	PCX	Graphics - ZSOFT Paintbrush  (nn = 0x02, 0x03, 0x05)
0C ED	MP	Graphics - Monochrome Picture TIFF Bitmap File
0D 44 4F 43       D  O  C	DOC	DeskMate Document File
0E 57 4B 53       W  K  S	WKS	DeskMate Worksheet
0F 00 E8 03                     (offset : 512 bytes)	PPT	PowerPoint Presentation SubHeader (MS Office)
11 00 00 00 53 43 43 41                  S  C  C  A	PF	Windows Prefetch File
1A 00 00	NTF	Database - Lotus Notes Template File
1A 00 00 04 00 00	NSF	Database - Lotus Notes File
1A 0x	ARC	Archive - LH Achive File, Old Version  (x = 0x02, 0x03, 0x04, 0x08, 0x09)
1A 0B	PAK	Archive - PAK Archive File
1A 35 01 00       5	ETH	GN Nettest WinPharoah Capture File
1A 52 54 53 20 43 4F 4D        R  T  S      C  O  M   50 52 45 53 53 45 44 20    P  R  E  S  S  E  D  49 4D 41 47 45 20 56 31    I   M  A  G  E     V   1  2E 30 1A   .   0	DAT	Graphics - Runtime Software Disk Image File
1D 7D	WS	WordStar Version 5.0/6.0 Document File
1F 8B 08	GZ	Archive - GZIP Archive File
1F 9D 90	TAR.Z	Archive - Tape Archive File
21 12   !	AIN	Archive - AIN Archive File
21 3C 61 72 63 68 3E 0A   !   <  a   r   c  h  >	LIB	Archive - Unix Archiver(ar) Files  Microsoft Program Library Common Object File  Format (COFF)
21 42 44 4E   !  B  D  N	PST	Microsoft Outlook File
23 20  #	MSI	Cerius2 File
23 20 4D 69 63 72 6F 73   #       M  i   c   r  o   s  6F 66 74 20 44 65 76 65    o  f    t      D   e   v  e   6C 6F 70 65 72 20 53 74    l   o   p   e  r      S  t  75 64 69 6F   u  d   i   o	DSP	Microsoft Developer Studio Project File
23 21 41 4D 52  #   !   A  M  R	AMR	Adaptive Multi-Rate ACELP Codec Format
24 46 4C 32 40 28 23 29   $   F  L   2  @  (  #   )   20 53 50 53 53 20 44 41       S  P  S  S      D  A  54 41 20 46 49 4C 45  T  A       F   I  L  E	SAV	SPSS Data File
25 21 50 53 2D 41 64 6F  %  !   P  S  -   A  d  o   62 65 2D    b  e  -	EPS	Adobe Encapsulated PostScript File
25 50 44 46   % P  D  F	PDF  FDF	Adobe Portable Document Format File   Forms Document File
28 54 68 69 73 20 66 69    (  T  h   i   s      f    i   6C 65 20 6D 75 73 74 20     l    e     m  u  s  t         62 65 20 63 6F 6E 76 65    b  e       c  o  n   v   e  72 74 65 64 20 77 69 74    r   t   e   d      w  i   t    68 20 42 69 6E 48 65 78    h  B   i   n   H  e  x  20	HQX	Archive - Macintosh BinHex 4 Archive
2A 2A 2A 20 20 49 6E 73    *   *   *           I   n   s   74 61 6C 6C 61 74 69 6F    t   a   l   l    a   t   i   o   6E 20 53 74 61 72 74 65    n     S   t   a   r   t   e  64 20  d	LOG	Symantec Wise Installer Log File
2D 6C 68    -   l    h                           (offset : 2 bytes)	LHA, LZH	Archive - Compressed Archive File
2E 52 45 43       R  E  C	IVR	RealPlayer Video File (v11 and later)
2E 72 61 FD 00       r   a	RA	RealMedia Streaming Media File
2E 52 4D 46   .   R  M  F	RM	Real Media File
2E 73 6E 64   .   s   n  d	AU	Sound - NeXt/Sun Audio Format
30   0	CAT	Microsoft Security Catalog File
30 00 00 00 4C 66 4C 65   0              L   f   L   e	EVT	Windows Event Viewer File
30 26 B2 75 8E 66 CF 11  A6 D9 00 AA 00 62 CE 6C	ASF, WMA,   WMV	Microsoft Windows Media Audio/Video File  (Advanced Streaming Format)
30 31 4F 52 44 4E 41 4E    0  1   O  R  D  N  A  N  43 45 20 53 55 52 56 45   C  E      S  U  R  V  E   59 20 20 20 20 20 20 20  Y	NTF	National Transfer Format Map File
31 BE 00 00 00 AB	DOC	Word processor - MS Word 4
3n BE 00 00 00 AB	WRI	Word processor - MS Write (n = 0x1, 0x2)
34 12	PIC	Graphics - PC Paint
37 7A BC AF 27 1C	7Z	Archive - 7-Zip Archive File
38 42 50 53   8  B  P  S	PSD	Graphics - Adobe Photoshop File
3A DE 68 B1	DCX	Graphics - CAS Fax Format
3C	ASX	Advanced Stream Redirector File
3C	XDR	BizTalk XML-Data Reduced Schema File
3C 21 64 6F 63 74 79 70  <    !   d  o  c   t   y   p	DCI	AOL HTML Mail File
3C 3F 78 6D 6C 20 76 65   <   ?   x  m   l        v  e   72 73 69 6F 6E 3D    r   s  i   o   n  =	MANIFEST	Windows Visual Stylesheet XML File
3C 3F 78 6D 6C 20 76 65   <   ?   x  m   l        v  e   72 73 69 6F 6E 3D 22 31    r   s  i   o   n  =   "   1   2E 30 22 3F 3E   .   0   "   ?   >	XUL	XML User Interface Language File
3C 3F 78 6D 6C 20 76 65    <   ?   x  m   l        v  e   72 73 69 6F 6E 3D 22 31    r   s  i   o   n  =   "   1  2E 30 22 3F 3E 0D 0A 3C    .   0   "   ?   >           <  4D 4D 43 5F 43 6F 6E 73   M  M  C  _  C   o  n   s   6F 6C 65 46 69 6C 65 20    o   l   e  F   i   l   e   43 6F 6E 73 6F 6C 65 56   C   o  n   s  o   l   e   V  65 72 73 69 6F 6E 3D 22   e  r   s  i   o   n   =   "	MSC	Microsoft Management Console Snap-in Control  File
3E 00 03 00 FE FF 09 00   06                                  (offset : 24 bytes)	WB3	Quatro Pro for Windows 7.0 Notebook File
3F 5F 03 00   ?  _	GID	Windows Help Index File
3F 5F 03 00   ?  _	HLP	Windows Help File
41 48  A  H	PAL, PIC	Graphics - Dr Halo Format
41 4C 5A 01  A  L   Z	ALZ	Archive - ESTsoft Alzip Archive File
40 40 40 20 00 00 40 40   @ @ @             @ @  40 40  @ @	ENL	EndNote Library File
41 43 53 44  A  C  S  D		Miscellaneous AOL Parameter and Information  File
41 4D 59 4F  A  M  Y  O	SYW	Graphics - Hardvard Graphics Symbol Graphic
41 4F 4C 20 46 65 65 64   A  O  L       F   e   e  d   62 61 67   b  a  g	BAG	AOL and AIM Buddy List File
41 4F 4C 44 42  A  O   L  D  B	ABY, IDX	Database - AOL Database File (ABY, MAIN.IDX)
41 4F 4C 49 44 58  A  O  L    I   D  X	IND	AOL Client Preferences/Settings File (MAIN.IND)
41 4F 4C 49 4E 44 45 58  A  O  L    I   N  D  E  X	ABI	AOL Address Book Index File
41 56 47 36 5F 49 6E 74   A  V  G   6  _   I   n   t   65 67 72 69 74 79 5F 44    e  g  r   i    t   y  _  D   61 74 61 62 61 73 65  a  t   a   b  a  s  e	DAT	AVG6 Integrity Database File
41 56 49 20 4C 49 53 54  A  V   I       L   I   S  T		Audio/Video Interleaved File
41 4F 4C 56 4D 31 30 30  A  O  L   V  M   1  0  0		AOL Personal File Cabinet (PFC) File
41 72 43 01  A   r   C	ARC	Archive - FreeArc Archive File
42 45 47 49 4E 3A 56 43   B  E  G   I   N  :   V  C   41 52 44 0D 0A  A  R  D	VCF	vCard File
42 4C 49 32 32 33 51  B   L   I   2   2  3  Q	BIN	Tomson Speedtouch Series WLAN Router   Firmware File
42 4D  B  M	BMP, DIB	Graphics - Windows Bitmap Format
42 4F 4F 4B 4D 4F 42 49  B  O  O  K  M  O  B   I	PRC	Palmpilot Resource File
42 5A 68  B  Z   h	BZ2, TAR,  TBZ2, TB2	Archive - bzip2 Archive File
43 42 46 49 4C 45  C  B  F   I   L  E	CBD	WordPerfect Dictionary File
43 44 30 30 31  C  D   0   0  1	ISO	ISO-9660 CD Disc Image
43 4F 4D 2B  C  O  M   +	CLB	COM+ Catalog File
43 52 45 47  C  R  E  G	DAT	Windows 9x Registry Files
43 52 55 53 48 20 76  C  R  U  S  H      v	CRU	Archive - Crush Archive File
43 54 4D 46  C  T  M  F	CMF	Sound - Creative Music Format
43 57 53  C  W  S	SWF	Shockwave Flash File (v5+)
43 61 74 61 6C 6F 67 20   C  a   t   a   l   o   g      33 2E 30 30 00   3   .   0   0	CTF	Wherelslt Catalog File
43 6C 69 65 6E 74 20 55   C   l    i   e   n   t      U   72 6C 43 61 63 68 65 20    r   l   C   a  c   h  e       4D 4D 46 20 56 65 72 20  M  M  F      V   e  r	DAT	IE History DAT File
43 72 65 61 74 69 76 65  C  r   e  a   t   i   v   e  20 56 6F 69 63 65 20 46      V  o   i   c   e      F  69 6C 65 1A   i   l    e	VOC	Sound - Creative Voice Format
44 42 46 48  D  B  F  H	DB	Palm Zire Photo Database
44 4D 53 21  D  M  S  !	DMS	Archive - Amiga DiskMasher Archive File
44 4F 53  D  O  S	ADF	Amiga Disk File
44 61 6E 4D  D  a   n  M	MSP	Graphics - Windows Paint
45 4E 54 52 59 56 43 44  E  N  T  R  Y  V  C  D  02 00 00 01 02 00 18 58                               X	VCD	Video VCD (GNU VCDImager) File
45 54 46 53 53 41 56 45  E  R  F  S  S  A  V  E  44 41 54 41 46 49 4C 45  D  A  T  A  F   I   L  E	DAT	Kroll EasyRecovery Saved Recovery State File
45 56 46  E  V  F	Enn  (nn = number)	EnCase Evidence File
45 59 45 53  E  Y  E  S	CE1, CE2	Graphics - ComputerEyes Format
46 4F 52 4D  F  O  R  M	LBM	Graphics - Interchange File Format
46 41 58 43 4F 56  F  A  X  C  O  V  45 52 2D 56 45 52  E  R   -  V  E  R	CPE	Microsoft Fax Cover Sheet
46 45 44 46  F  E  D  F	SBV	Unkown File Type
46 4C 56	SWF	Flash Video File
46 4F 52 4D 00	AIFF	Audio - Audio Interchange File
46 57 53  F  W  S	SWF	Shockwave Flash File
46 72 6F 6D 20 20 20   F  H  o  m                      or  46 72 6F 6D 20 3F 3F 3F   F  H  o  m      ?   ?   ?     or  46 72 6F 6D 3A 20   F  H  o  m   :	EML	A common File Extension for E-mail File
47 46 31 50 41 54 43 48  G  F   1  P  A  T  C  H	PAT	Advanced Gravis Ultrasound Patch File
47 49 46 38 37 61  G  I   F   8   7  a	GIF	Graphics - Graphics Interchange Format
47 49 46 38 39 61  G  I   F   8   9  a	GIF	Graphics - Graphics Interchange Format
47 50 41 54  G  P  A  T	PAT	GIMP (GNU Image Manipulation Program) Pattern  File
47 58 32  G  X  2	GX2	Graphics - Show Partner Graphics File
48 48 47 42 31  H  H  G  B  1	SH3	Harvard Graphics Presentation File
49 49 2A   I   I   *	TIF, TIFF	Graphics - Tagged Image File Format File  (Little Endian)
4D 4D 2A   M  M   *	TIF, TIFF	Graphics - Tag Image File Format  (Big Endian)
49 42 4B 1A   I  B  K	IBK	Sound - Soundblaster Instrument Bank
49 44 33   I   D  3	MP3	Sound - MPEG-1 Audio Layer 3 (MP3) Audio File
49 4D 44 43   I  M  D  C	IC1, IC2, IC3	Graphics - Atari Imagic Film Format
49 53 63 28   I   S  c  (	CAB	Archive - Install Shield (v5+) Archive File
49 54 53 46   I  T  S  F	CHM	Microsoft HTML Help Compiled File
49 6E 6E 6F 20 53 65 74    I   n   n   o      S  e  t   75 70 20 55 6E 69 6E 73    u   p     U  n   i   n  s     74 61 6C 6C 20 4C 6F 67    t   a   l   l        L   o   g  20 28 62 29       (  b   )	DAT	Inno Setup Uninstall Log File
4A 41 52 43 53 00   J  A  R  C  S	JAR	Archive - JARCS Archive File
4A 47 0n 0E 00 00 00	ART	AOL ART File (n = 0x3, 0x4)
4C 00 00 00   L	LNK	Microsoft Windows Shortcut File
4C 01   L	OBJ	Microsoft Common Object File Format (COFF)  Relocatable Object Code File
4C 4E 02 00   L  N	HLP	Windows Help File
4C 69 6E 53   L   i   n  S	MSP	Graphics - Windows 3.x Paint
4D 47 43  M  G  C	CRD	Database - Windows 3.x Card File
4D 49 4C 45 53  M   I  L   E  S	MLS	Mailestones v1.0 Project Management and  Scheduling Software (Also see "MV2C", "MV214")
4D 4C 53 57  M  L   S  W	MLS	Skype Localization Data File
4D 4D 00 2A  M  M      *	TIF, TIFF	Graphics -  Big Tagged Image File Format (TIFF)   (big endian)
4D 4D 00 2B  M  M      +	TIF, TIFF	Graphics -  Big Tagged Image File Format (TIFF)   File ( > 4GB)
4D 4D 4D 44 00 00  M  M  M  D	MMF	Yamaha Cynthetic Music Mobile Application   Format (SMAF)
4D 53 43 46  M  S  C  F	CAB  PPZ  SNP	Microsoft Cabinet File  Powerpoint Presentation Package  Microsoft Access Snapshot Viewer File
4D 53 46 54 02 00 01 00  M  S  F  T	TLB	OLE, SPSS, Visual C++ Type Library File
4D 53 5F 56 4F 49 43 45  M  S  _   V  O   I  C  E	CDR, DVF,  MSV	Sound - Sony Compressed Voice File  Sound - Sony Memory Stick Compressed Voice   File
4D 54 68 64  M  T   h  d	MID, MIDI	Sound - Standard Musical Instrument Digital   Interface (MIDI) Format
4D 56  M  V	DSN	CD Stomper Pro Label File
4D 56 32 31 34  M  V   2   1  4	MLS	Milestones v2.1b Project Management and  Scheduling Software (Also see "MILES", "MV2C")
4D 56 32 43  M  V   2  C	MLS	Milestones v2.1a Project Management and  Scheduling Software (Also see "MILES", "MV214")
4D 5A  M  Z	COM, DLL, DRV  EXE, PIF, QTS  QTX, SYS  ACM,  AX,   CPL,  FON,  OCX,  OLB,  SCR,  VBX,  VXD	Windows/DOS Executable File  MS Audio Compression Manage Driver  Library Cache File  Control Panel Application  Font File  ActiveX or OLE Custom Control  OLE Object Library  Screen Saver  Visual Basic Application  Windows Virtual Device Drivers
4D 5A 90 00 03 00 00 00  M  Z	API,  AX,  FLT	Acrobat Plug-in  DirectShow Filter  Adobe Audition Graphic Filter File
4D 5A 90 00 03 00 00 00  M  Z  04 00 00 00 FF FF	ZAP	ZoneAlam Data File
4D 69 63 72 6F 73 6F 66   M   i   c  r   o   s  o   f     74 20 56 69 73 75 61 6C    t       V  i   s  u   a  l    20 53 74 75 64 69 6F 20       S   t   u   d  i   o  53 6F 6C 75 74 69 6F 6E    S   o  l   u   t   i   o   n  20 46 69 6C 65      F   i   l   e	SLN	Visual Studio .NET Solution File
4D 69 63 72 6F 73 6F 66   M   i   c  r   o   s  o   f    74 20 57 69 6E 64 6F 77    t      W  i   n   d  o  w    73 20 4D 65 64 69 61 20    s      M  e  d   i  a  50 6C 61 79 65 72 20 2D   P   l   a   y  e  r       -   2D 20     -                                    (offset : 84 bytes)	WPL	Windows Media Player Playlist
4E 41 56 54 52 41 46 46   N  A  V  T   R  A  F  F    49 43   I  C	DAT	TomTom Traffice Data File
4E 45 53 4D 1A 01  N  E  S  M	NFS	Sound - NES Sound File
4E 49 54 46 30   N   I  T  F   0	NTF	National Imagery Transmission Format (NIFF) File
4E 61 6D 65 3A 20   N  a  m  e   :	COD	Agent NewsReader Character Map File
4F 50 4C 44 61 74 61 62    O  P  L  D  a   t   a   b   61 73 65 46 69 6C 65   a  s  e  F   i   l   e	DBF	Psion Series 3 Database File
4F 67 67 53 00 02 00 00    O  g  g  s  00 00 00 00 00 00	OGA, OGG,   OGV, OGX	Ogg Vorbis Codec Compressed Multimedia File
4F 7B   O  {	DW4	Visio/DisplayWrite 4 Test File
50 00 00 00 20 00 00 00  P	IDX	Quicken QuickFinder Information File
50 35 0A  P  5	PGM	Graphics - Portable Graymap Graphic
50 41 43 4B  P  A  C  K	PAK	Archive - Quake Archive File
50 45 53 54  P  E  S  T	DAT	PestPatrol Data/Scan Strings
50 49 43 54 00 08   P  I  C  T	IMG	Graphics -  ADEX ChromaGraph Graphics Card   Bitmap Graphics File
50 4B 03 04  P  K	ZIP,  DOCX, PPTX,  XLSX,  JAR,  SXC, SXD, SXI,  SXW  WMZ,  XPI,  XPT	Archive - Pkzip Archive File  Microsoft Office Open XML Format Document  Java Archive Package  OpenOffice Spreadsheet, Drawing, Presentation  Windows Media Compressed Skin File  Mozila Browser Archive  eXact Packager Models
50 4B 03 04 14 00 06 00  P  K	DOCX, PPTX,  XLSX	Microsoft Office Open XML Format Document
50 4B 03 04 14 00 08 00  P  K	JAR	Java Archive
50 4B 4C 49 54 45   P  K  L   I  T  E               (offset : 30 bytes)	ZIP	Archive - PKLITE ZIP Archive (see also PKZIP)
50 4B 53 70 58   P  K  S  F  X                   (offset : 526 bytes)	ZIP	Archive - PKSFX Self-Extracting Executable Compressed File (see also PKZIP)
50 4D 43 43  P  M  C  C	GRP	Windows Program Manager Group File
50 4E 43 49 55 4E 44 4F  P  N  C   I  U  N  D	DAT	Noton Disk Doctor Undo File
50 C3	CLP	Windows 3.x Clipboard
51 45 4C 20   Q  E  L  (offset : 92 bytes)	QEL	Quicken Data File
51 46 49 FB  Q  F  I	IMG	QEMU Qcow Disk Image
51 57 20 56 65 72 2E 20  Q  W      V   e  r	ABD, QSD	Quicken Data File
52 41 5A 41 54 44 42 31  R  A  Z  A  T  D  B  1	DAT	Shareaza (Windows P2P Client) Thumbnail
52 45 47 45 44 49 54   R  E  G  E  D  I  T	REG, SUD	Windows NT Registry and Registry Undo Files
52 45 56 4E 55 4D 3A 2C  R  E  V  N  U  M   :   ,	ADF	Antenna Data File
52 49  46  46  R   I   F   F	ANI  DAT  DS4	Windows Animated Cursof  Video CD MPEG or MPEG1 Movie File  Micrografx Designer v4 Graphic File
52 49 46 46 xx xx xx xx   R  I  F  F   41 56 49 20 4C 49 53 54  A  V   I       L   I  S  T	AVI	Resource Interchange File Format -  Windows Audio Video Interleave File
52 49 46 46 xx xx xx xx  R   I   F  F  43 44 44 41 66 6D 74 20  C  D  D  A   f   m  t	CDA	Resource Interchange File Format -  Compact Disc Digital Audio (CD-DA) File
52 49 46 46 xx xx xx xx  R   I   F  F  51 4C 43 4D 66 6D 74 20  Q  L  C  M  f  m  t	QCP	Resource Interchange File Format -  Qualcomm PureVoice
52 49 46 46 xx xx xx xx  R   I   F  F  52 4D 49 44 64 61 74 61  R  M   I  D   d  a   t   a	RMI	Resource Interchange File Format -  Windows Musical Instrument Digital Interface File
52 49 46 46 xx xx xx xx  R   I   F  F  57 41 56 45 66 6D 74 20  W  A  V  E  f  m  t	WAV	Resource Interchange File Format -  Audio for Windows File
52 54 53 53  R  T  S  S	CAP	Windows NT Netmon Capture File
52 61 72 21 1A 07 00  R  a  r  !	RAR	Archive - WinRAR Compressed Archive File
53 42 49 1A  S  B   I	SBI	Soundblaster Instrument Format
53 43 48 6C  S  C  H  l	AST	Audio - Need for Speed : Undergraound Audio File
53 43 4D 49  S  C  M  I	IMG	Img Software Set Bitmap File
53 48 4F 57  S  H  O  W	SHW	Harvard Graphics DOC v2/x Presentation File
53 49 45 54 52 4F 4F 49    S  I  E  T  R  O  N  I    43 53 20 58 52 44 20 53   C  S      X  R  D      S   43 41 4E  C  A  N	CPI	Sietronics CPI XRD Document File
53 49 54 21 00  S   I   T  !	SIT	Archive - Stufflt Compressed Archive File
53 4D 41 52 54 44 52 57  S  M  A  R  T  D  R  W	SDR	SmartDraw Drawing File
53 51 4C 4F 43 4F 4E 56  S  Q  L  O  C  O  N  V  48 44 00 00 31 2E 30 00  H  D           1   .   0	CNV	DB2 Conversion File
53 6D 62 6C  S  m  b  l	SYM	Harvard Graphics v2.x Graphics Symbol  Windows SDK Graphics Symbol
53 74 75 66 66 49 74 20  S   t   u   f   f   I   t  28 63 29 31 39 39 37 2D   (  c  )   1   9   9   7   -	SIT	Archive - Stufflt Compressed Archive File
54 43 53 4F 00 04 00 00 00 00  T  C  S  O                          (offset : 6 bytes)	SOL	Local Shared Object(LSO) File
54 68 69 73 20 69 73 20  T   h   i   s      i   s	INFO	UNIX GNU Info Reader File
55 43 45 58  U  C  E  X	UCE	Unicode Extensions
55 46 41 C6 D2 C1  U  F  A	UFA	Archive - UFA Compressed Archive File
55 46 4F 4F 72 62 69 74  U  F  O  O   r   b   i   t	DAT	UFO Capture v2 Map File
56 43 50 43 48 30  V  C  P  C  H  0	PCH	Visual C PreCompiled Header File
56 44 56 49  V  D  V   I	AVS	Intel Digital Video Interface
56 45 52 53 49 4F 4E 20  V  E  R  S   I   O  N	CTL	Visual Basic User-Defined Control File
57 4D 4D 50  W  M  M  P	DAT	Walkman MP3 Container File
57 53 32 30 30 30  W  S  2   0   0   0	WS2	WordStar for Windows v2 Document File
57 69 6E 5A 69 70  W  i  n  Z  i  p             (offset : 29, 152 bytes)	ZIP	Archive - WinZip Compressed Archive File
58 43 50 00  X  C  P	CAP	Cinco NetXRay, Network General Sniffer, and  Network Associates Sniffer Capture File
58 50 43 4F 4D 0A 54 79  X  P  C  O  M      T  y  70 65 4C 69 62   p  e  L  i  b	XPT	XPCOM Type Libraries for The XPIDL Compiler
58 54  X  T	BDR	MS Publisher Border
59 A6 6A 95	RAS	SUN Raster Format
5A 4F 4F 20  Z  O  O	ZOO	Archive - ZOO Compressed Archive File
5B 47 65 6E 65 72 61 6C    [  G   e   n   e   r   a   l  5D 0D 0A 44 69 73 70 6C    ]           D   i   s   p   l     61 79 20 4E 61 6D 65 3D   a   y     N  a  m   e  =    3C 44 69 73 70 6C 61 79    <  D   i   s  p   l   a   y   4E 61 6D 65   N  a  m  e	ECF	Microsoft Exchange 2007 Extended Configuration  File
5B 4D 53 56 43   [  M  S  V  C	VCW	Microsoft Visual C++ Workbench Information File
5B 50 68 6F 6E 65 5D   [  P   h   o   n   e  ]	DUN	Dial-Up Networking File
5B 56 45 52 5D 0D 0A 09   [  V  E  R  ]	SAM	AMU Pro Document
5B 76 65 72 0D 0A 09   [  v  e  r  ]	SAM	AMU Pro Document
5B 56 65 72 73 69 6F 6E   [  V  e   r   s   i   o  n  ]    (offset : 2 bytes)	CIF	Unknown File Type
5B 57 69 6E 64 6F 77 73  [  W   i   n   d   o  w   s  20 4C 61 74 69 6E 20      L   a   t   i   n	CPX	Microsoft Code Page Translation File
5B 66 6C 74 73 69 6D 2E  [   f    l   t   s   i   m  30 5D   0   ]	CFG	Flight Simulator Aircraft Configuration File
5F 43 41 53 45 5F   _  C  A  S  E  _	CAS, CBK	EnCase v3 Case File  EnCase v4, 5, 6 use OLE 2 Container File
60 EA	ARJ	Archive - ARJ Compressed Archive File
62 65 67 69 6E   b  e  g  i  n		UUencoded File
63 75 73 68 00 00 00 02    c  u  s  h  00 00 00	CSH	Photoshop Custom Shape
64 00 00 00   d	P10	Intel PROset/Wireless Profile
64 73 77 66 69 6C 65   d  s  w  f   i   l   e	DSW	Microsoft Visual Studio Workspace File
66 4C 61 43 00 00 00 22   f   L  a  C              "	FLAC	Free Lossless Audio Codec File
6C 33 33 6C   l   3   3   l	DBB	Skype User Data File
6D 6F 6F 76  m  o   o   v      or             (offset : 4 bytes)  66 72 65 65  f   r   e   e       or              (offset : 4 bytes)  6D 64 61 74  m  d   a   t      or              (offset : 4 bytes)  77 69 64 65  w  i   d   e      or               (offset : 4 bytes)	MOV	Apple QuickTime Movie File
72 65 67 66   r   e  g   f	DAT	Windows Registry Hive File
72 74 73 70 3A 2F 2F  r   t   s   p   :   /   /	RAM	RealMedia Metafile
73 6C 68 21  s   l   h   !    or  73 6C 68 2E  s   l   h   .	DAT	Allegro Generic Packfile Data File  (0x21 = Compressed,  0x2E = Uncompressed )
73 72 63 64 6F 63 69 64  s   r   c   d  o  c  i   d  3A   :	CAL	Graphics - CALS Raster Bitmap File
73 7A 65 7A  s   z   e   z	PDB	PowerBASIC Debugger Symbols File
74 42 4D 50 4B 6E 57 72  t   B  M  P  K  n   W  r       (offset : 60 bytes)	PRC	PathWay Map File (used GPS devices)
75 73 74 61 72  u   s   t   a   r                   (offset : 257 bytes)	TAR	Archive - Tape Archive File
76 32 30 30 33 2E 31 30  v   2   0   0   3   .  1  0  0D 0A 30 0D 0A            0	FLT	Qimage Filter
78   x	DMG	Mac OS X Disk Copy Disk Image File
7A 62 65 78  z   b   e   x	INFO	ZoomBowser Image Index File (ZbThumbnal.info)
7B 0D 0A 6F 20   {            o	LGC, LGD	Windows Application Log File
7B	DBF	Database - dBASE IV
7B 5C 72 74 66 31   {  \   r   t   f   1	RTF	Word processor - Rich Text Format
7E 42 4B 00   ~  B  K	PSP	Graphics - Corel Paint Shop Pro Image File
7F 45 4C 46      E  L  F		Linux/Unix - Executable and Linking Format
80	OBJ	Relocatable Object Code
80 00 00 20 03 12 04	ADX	Dreamcase Audio File
81 CD AB	WPF	Word processor - WordPerfect Test File
83	DBF	Database - dBASE III
83	DBF	Database - dBASE IV
83	DBF	Database -  FoxPro
8B	DBF	Database - FoxPro
89 50 4E 47 0D 0A 1A 0A       P  N  G	PNG	Graphics - Portable Network Graphics File
8A 01 09 00 00 00 E1 08  00 00 99 19	AW	MS Answer Wizard File
91 33 48 46	HAP	Archive - Hamarsoft HAP 3.x Compressed Archive
95 01	SKR	PGP Secret Key Ring
99 00	PKR	PGP Public Key Ring
99 01	PKR	PGP Public Key Ring
9B A5	DOC	Word processor - Winword 1.0
9C CB CB 8D 13 75 D2 11  91 58 00 C0 4F 79 56 A4	WAB	Outlook Address File
A0 46 1D F0                     (offset : 512 bytes)	PPT	PowerPoint Presentation SubHeader
A1 B2 C3 D4		tcpdump (libpcap) Capture File
A1 B2 CD 34		Extended tcpdump (libpcap) Capture File
A9 0D 00 00 00 00 00 00	DAT	Access Data FTK Evidence File
AC 9E BD 8F 00 00	QDF	Quicken Data File
B1 68 DE 3A	DCX	Graphics Multipage PCX Bitmap File
B5 A2 B0 B3 B3 B0 A2 B5	CAL	Windows 3.x Calendar
BA BE EB EA	ANI	NEOchrome Animation File
BE 00 00 00 AB 00 00 00  00 00 00 00 00	WRI	Microsoft Wirte File
C3 AB CD AB	ACS	Microsoft Agent Character File
C5 D0 D3 C6	EPS	Adobe Encapsulated PostScript File
C8 00 79 00	LBK	Jeppesen FiteLog File
CA FE BA BE	CLASS	Java Bytecode File
CD 20 AA AA 02 00 00 00		Norton Anti-Virus Quarantined Virus File
CF 11 E0 A1 B1 1A E1 00	DOC	Word processor - Perfect Office Document File
CF AD 12 FE	DBX	Microsoft Outlook Express E-mail File
D0 CF 11 E0 A1 B1 A1 E1	HWP  DOC, DOT, PPS  PPT, XLA, XLS  WIZ  AC_  ADP  APR  DB  MSC  MSI  MTW  OPT  PUB  SOU  SPO  VSD  WPS	HAANSOFT Compound Document File  Microsoft Office Compound Document File  CaseWare Working Papers Compressed Client File  Access Project File  Lotus/IBM Approach 97 File  MSWorks Database File  Microsoft Common Console Documet File  Microsoft Installer Package  Minitab Data File  Developer Studio File Workspace Options File  Microsoft Publisher File  Visual Studio Solution User Options File  SPSS Output File  Visio File  MSWorks Text Document File
D2 0A 00 00	FTR	GN Nettest WinPharoah Filter File
D4 2A	ARL, AUT	AOL History (ARL) and Typed URL (AUT) Files
D4 C3 B2 A1		WinDump (Winpcap) Capture File
D7 CD C6 9A	WMF	Graphics - Windows Metafile Format
DB A5	DOC	Word processor - Winword 2.0
DC DC	CPL	Corel Color Palette File
DC FE	EFX	eFax File Format
E3 10 00 01 00 00 00 00	INFO	Amiga Icon File
E3 82 85 96	PWL	Windows Password File
E8  or  E9  or  EB  or	COM, SYS	Windows Executable File
EB 3C 90 2A	IMG	GEM Raster File
EC A5 C1 00                   (offset : 512 bytes)	DOC	Word Document SubHeader
ED AB EE DB	RPM	RedHat Package Manager File
EF BB BF		Byte-order Mark for 8-bit Unicode Transformation  Format (UTF-8) File
F5	DBF	FoxPro Database
FD FF FF FF 04                 (offset : 512 bytes)	SUO	Visual Studio Solution User Options SubHeader
FD FF FF FF nn 00 00 00    (offset : 512 bytes)	PPT	PowerPoint Presentation SubHeader  (nn = 0x0E, 0x1C, 0x43)
FD FF FF FF nn 00   or      (offset : 512 bytes)  FD FF FF FF nn 02            (offset : 512 bytes)	XLS	Excel Spreadsheet SubHeader  (nn = 0x10, 0x1F, 0x22, 0x23, 0x28, 0x29)
FD FF FF FF 20 00 00 00    (offset : 512 bytes)	OPT  XLS	Developer Studio File Workspace Options   SubHeader  Excel Spreadsheet SubHeader
FD FF FF FF xx xx xx xx  xx xx xx xx 04 00 00 00    (offset : 512 bytes)	DB	Thumbs.db SubHeader
FE DB   or  FE DC	SEQ	Cyber Paint
FE FF		Byte-order mark for 16-bit Unicode Transformation  Format/2-octet Universal Character Set  (UTF-16/UCS-2)
FF	SYS	Windows Executable Format File
FF 00 02 00 04 04 05 54  02 00	WKS	Windows Spreadsheet Work File
EF 46 4F 4E 54       F  O  N  T	CPI	Windows International Code Page
FF 4B 45 59 42 20 20 20       K  E  Y  B	SYS	Keyboard Driver File
FF 57 50 43      W  P  C	WP, WPD, WPG  WP5	Word processor - WordPerfect Document and  Graphic File
FF D8 FF E0 xx xx 4A 46                               J  F  49 46   I   F	JPG	Graphics - JPEG/JFIF Format
FF D8 FF E1 xx xx 45 78                              E  x  69 66   i   f	JPG	Graphics - JPEG/Exif Format - Digital Camera  Exchangeable Image File Format (EXIF)
FF FF	GEM	GEM Metafile Format
FF D8 FF E8 xx xx 53 50                             S  P  49 46 46 00   I  F  F	JPG	Graphics - Still Picture Interchange File Format  (SPIFF)

http://www.iana.org/assignments/port-numbers

http://www.exploit-db.com/

http://www.whatismyip.org

http://sla.ckers.org/forum/