[2022/03/02][짤막한 이야기 - 파일과 프로세스(=이미지)]

[2022/03/02][짤막한 이야기 - 파일과 프로세스(=이미지)]
앞선 포스트에서 프로그램의 주소 체계는 파일 상태일 때와 프로세스 상태(=이미지 상태)일 때 다르다고 서술하였다.
모든 프로그램은 헤더(Header)와 바디(Body, 섹션 바디라고도 함)로 구성되어 있는데, 바디는 그 역할에 따라서 특정한 이름의 섹션으로 구성되어 있다.
예를 들면 실제 실행코드를 가지고 있는 Code 섹션(Windows에서는 보통 .text 영역), 변수값이나 문자열 등을 가지고 있는 Data 섹션(Windows에서는 보통 .data 영역), 사용할 함수의 정보를 가지고 있는 Import 섹션(Windows에서는 보통 .idata 영역) 등이 있다.
즉, 프로그램의 각 역할들은 섹션의 바디에서 결정되는 것이다.
그런데 섹션은 반드시 특정한 숫자의 배수로만 구성(이를 Alignment라고 함)된다.
만약 이 Alignment가 200인데 Data 섹션의 크기가 150인 경우 남은 50만큼은 0으로 채워지게 되며, 이를 제로 패딩(Zero Padding)이라고 한다.
그리고 Windows에서는 파일 상태에서의 Alignment 값과 프로세스 상태에서의 Alignment 값이 서로 다르다.
일반적으로 프로세스 상태의 Alignment 값이 파일 상태의 Alignment 값보다 더 크기 때문에 같은 양의 코드, 데이터, 함수 정보를 가지고 있는 섹션 바디라도 뒤에 붙은 제로 패딩의 양이 크게 달라지게 된다.
따라서 파일 상태에서 특정한 문자열이나 특정한 코드가 A라는 주소에 있더라도 프로세스 상태에서도 동일한 위치(주소 A)에 존재하리라는 보장은 없는 것이다.
파일과 프로세스에서의 Alignment가 동일하게 설정된다면, 그림과 같은 구조적 차이는 없어지게 되겠지만, 이는 속도의 저하를 가져올 수 있다.
왜냐하면 파일 Alignment가 정해지는 것은 하드디스크에서 해당 파일을 가장 빠르게 읽어들일 수 있는 단위로 설정되고,
프로세스 Alignment가 정해지는 것은 메모리에서 해당 이미지를 가장 빠르게 읽어들일 수 있는 단위로 설정되기 때문이다.
위와 같은 현상은 Windows 실행파일 뿐 아니라 Linux, MacOS 등 모든 구조에서 공통적으로 발생하는 현상이다.
이는 분석가 뿐 아니라 개발자에게도 필수적인 이론으로 알려져 있다.
[관련된 짤막한 이야기 - 섹션[2021/10/01]]
[관련된 짤막한 이야기 - 주소 체계[2022/02/28]]
[관련된 문서 - 핀툴 프로그래밍 기본서[제3부. 핀툴로 UPX 언패킹하기]]
#이야기 #루니프 #핀 #핀툴 #패킹 #언패킹 #IAT #주소체계 #파일 #메모리 #정렬(Alignment) #분석가 #개발자