정렬(alignment)과 패딩(padding)이 게임 파일 분석을 어렵게 만드는 이유

정렬과 패딩은 바이트를 관찰해 판별한다

헥스 에디터에서 반복되는 00이나 FF가 보인다고 곧바로 패딩이라고 결론낼 수는 없다. 00은 문자열 종료 표식, 길이 필드의 일부, 정렬을 맞추는 빈 공간일 수 있고, FF도 실제 데이터나 미사용 영역일 수 있다. 먼저 포인터가 가리키는 위치와 여러 레코드의 경계를 비교한다.

정렬(alignment)은 어떤 주소가 정해진 경계에 놓이도록 하는 규칙이다. 패딩(padding)은 다음 경계를 맞추려고 레코드 뒤에 실제로 들어간 여분의 바이트다. 모든 게임 파일이 문자열을 2바이트나 4바이트로 정렬하는 것은 아니다. 디스크 섹터 경계 정렬은 레코드 정렬과 별개의 규칙이다.

4바이트 정렬 예시

파일 오프셋 0x120에서 시작하는 레코드가 5바이트라고 가정한다. 레코드 끝 다음 주소(end-exclusive)는 0x125다. 다음 레코드가 4바이트 경계에서 시작해야 한다면, 끝 주소에 더할 패딩은 (-end_offset) % 4로 계산한다. 이 예에서는 3바이트를 더해 다음 레코드가 0x128에서 시작한다.

start = 0x120
record_length = 5
end_exclusive = start + record_length   # 0x125
padding = (-end_exclusive) % 4          # 3
next_start = end_exclusive + padding    # 0x128

이 계산은 위치를 예측할 뿐, 그 세 바이트가 반드시 00이라는 뜻은 아니다. 실제 패딩 값은 원본의 여러 레코드에서 확인한다. 문자열 길이에 종료 바이트를 포함하는지, 길이 필드가 헤더까지 세는지도 파일 포맷마다 다르다.

정렬 단위를 찾는 절차

1. 포인터 테이블이나 레코드 인덱스가 가리키는 시작 오프셋을 여러 개 기록한다.
2. 각 레코드의 끝 주소와 다음 시작 주소 사이 간격을 계산한다. 반복해서 같은 경계가 나오면 2·4·8 등의 정렬 가설과 맞춰 본다.
3. 문자열 길이가 다른 레코드도 비교한다. 길이가 달라도 다음 주소가 경계에 맞으면 정렬 가설이 강해지지만, 한 사례만으로 확정하지 않는다.
4. 포인터가 파일 시작 기준인지, 섹션 시작 기준인지, 블록 기준인지 확인한다. 기준 주소를 잘못 잡으면 나머지 포인터도 일정하게 어긋난다.
5. 복사본에서 한 레코드만 수정한 뒤 길이 필드, 포인터, 다음 레코드의 시작과 내용을 다시 읽는다.

데이터 길이 필드가 이미 레코드 끝을 지정한다면 별도 종료 바이트를 찾지 못할 수 있다. 반대로 종료 코드가 레코드 경계를 정해도 정렬 때문에 그 뒤에 여분 바이트가 올 수 있다. 경계 규칙을 구분해 추출기에 기록해야 번역문을 늘렸을 때 다음 항목을 덮어쓰지 않는다.

AI 분석 결과는 오프셋으로 검증한다

AI에게 반복되는 00을 패딩이라고 이름 붙이게 하기보다, 원본 오프셋·포인터 값·레코드 길이·다음 시작 주소를 함께 주고 가능한 가설별 계산을 비교하게 한다. 여러 레코드에서 계산 결과가 같은 경계를 예측하는지 확인한 뒤에만 추출·삽입 규칙으로 고정한다.