[리버싱 핵심원리] 1부 3장 정리

본 게시글의 내용은 리버싱 핵심원리를 보며 복습 겸 정리를 위해 작성하였습니다.

책 내용과 일부 다를 수 있고, 이해를 돕기 위한 저만의 예시도 일부 포함되어 있습니다.

본 게시글에서 사용되는 소스코드와 파일은 리버싱 핵심원리에서 제공하는 파일을 사용하며, 사용하는 도구는 다를 수 있습니다.

바이트 오더링

바이트 오더링(Byte Ordering)은 영어 단어 그대로 바이트가 저장되는 순서를 의미하며, 리틀 엔디언과 빅 엔디언 방식으로 구분됩니다.

리틀 엔디언

리틀 엔디언(Little Endian)은 가장 낮은 바이트가 가장 낮은 메모리 주소에 저장되는 방식입니다. 즉, 작은 주소에서 시작해 끝으로 갈 수록 값이 큰 바이트가 저장되는 방식입니다.

int32_t num = 0x12345678;

int32_t는 4Bytes의 크기를 갖고 0x12345678이 리틀 엔디언 방식으로 저장될 경우 아래와 같습니다.

값	0x78	0x56	0x34	0x12
주소	0x01	0x02	0x03	0x04

데이터를 역순으로 저장한다고 생각하시면 됩니다.

빅 엔디언

빅 엔디언(Big Endian)은 가장 큰 바이트가 가장 낮은 메모리 주소에 저장되는 방식입니다. 즉, 큰 주소에서 시작해 끝으로 갈 수록 값이 작은 바이트가 저장되는 방식입니다.

int32_t num = 0x12345678;

int32_t는 4Bytes의 크기를 갖고 0x12345678이 빅 엔디언 방식으로 저장될 경우 아래와 같습니다.

값	0x12	0x34	0x56	0x78
주소	0x01	0x02	0x03	0x04

데이터를 사람이 읽는 그 순서대로 저장한다고 생각하시면 됩니다. 무엇보다 사람이 읽기 쉽죠.

리틀 엔디언과 빅 에디언의 장점과 단점

리틀 엔디언

연산 효율 및 데이터 캐스팅

리틀 엔디언 방식은 하드웨어 연산에서 조금 유리한 포지션을 갖고 있습니다. 예를 들어, 덧셈 연산을 수행한다고 가정해봅시다. 덧셈 연산은 자리 올림(Carry)이 발생할 가능성이 있기 때문에 가장 낮은 바이트부터 계산을 해야 효율적입니다. 빅 엔디언 방식의 경우 가장 큰 바이트부터 저장되기 때문에 낮은 바이트를 읽으려면 그 뒤로 이동해야 하는 추가 작업이 발생합니다.

 

데이터 확장에서 리틀 엔디언 방식은 큰 장점을 갖고 있습니다. 예를 들어, 8비트(1바이트) 데이터를 16비트나 32비트로 변환한다고 해봅시다. 8비트 데이터 0x12가 리틀 엔디언으로 저장되면 아래와 같습니다.

주소	값
0x01	0x12

만약 위 데이터를 32비트로 확장한다면 낮은 바이트를 그대로 유지하고 그 뒤에 상위 바이트 데이터를 추가하면 됩니다.

주소	값
0x01	0x12
0x02	0x00
0x03	0x00
0x04	0x00

사용하는 하드웨어에 따라 차이는 있겠지만 대부분의 경우 낮은 바이트부터 처리하기 때문에 연산 면에서 조금 유리하다는 장점을 갖고 있습니다.

디버깅 난이도 상승

리틀 엔디언 방식은 빅 엔디언 방식에 비해 사람이 읽기 힘들다는 단점을 갖고 있습니다. 다소 직관적이지 않기 때문에 디버깅을 수행할 때 어려움을 느끼게 됩니다.

호환성

리틀 엔디언 시스템에서 빅 엔디언 시스템과 통신을 수행할 때 별도의 변환 과정이 필요합니다. 대부분 변환할 수 있는 기능을 지원하기 때문에 큰 문제는 없는 편입니다.

빅 엔디언

사람이 읽기 쉬움

가장 높은 바이트가 가장 낮은 주소에 저장되기 때문에 사람이 읽기 쉬운 방식으로 저장됩니다. 0x12345678을 저장한다면 그대로 0x12 0x34 0x56 0x78로 저장되기 때문에 디버깅 시 데이터를 읽기 쉽다는 장점이 있습니다.

네트워크

네트워크 프로토콜을 통한 통신 시 빅 엔디언 방식을 사용하기 때문에 별도의 변환 과정이 필요 없습니다. 표준화 작업을 수행하기 편리하기 때문에 네트워크 통신 및 일부 서버 시스템에선 빅 엔디언 방식을 채택하고 있습니다.

연산 비효율

연산 수행 시 가장 낮은 바이트부터 처리하면 별도의 정렬 과정을 거쳐야하기 때문에 추가 연산이 필요해집니다.

ASCII 문자열은 한 문자 당 1Bytes로 표현되기 때문에 바이트 오더링과는 무관합니다. UTF-8 문자열은 가변 길이를 갖고 한 문자 당 1~4Bytes를 갖습니다. 특정 바이트 패턴을 갖기 때문에 이 역시 바이트 오더링과는 무관합니다. (예, 한글 '가'는 EA B0 80 패턴을 갖는 데 이 패턴을 지키지 않으면 '가' 문자가 안 나타난다.)

UTF-16과 UTF-32는 고정 길이를 갖고 바이트 오더링의 영향을 받습니다. 그래서 UTF-16 LE, UTF-16 BE로 구분되고 데이터를 올바르게 해석하려면 이 정보가 필요합니다. BOM(Byte Order Mark)라고 하는데 이것이 없으면 LE인지 BE인지 구분하기 힘듭니다.