[리버싱] 과연 이게 될까? Ch.1

인라인 코드 패치를 실습 후 리버싱 핵심 원리 책을 정독 중, pe header 공부를 하는 챕터에서 Dos Stub를 유심히 살펴 보았다.

pe header의 스펙에 따르면, 각 섹션은 characteristics라는 엑세스 권한 비트를 가지고 있다. 그러나 pe header가 메모리에 올라갔을 때의 엑세스 권한은 알려져 있지 않은것 같은데, 디버거로 메모리 맵을 살펴보면 읽기 권한만이 부여되어 있는 것을 볼 수 있다.

pe header는 프로그램을 실행할 때 pe 로더가 메모리를 정해주고, 프로그램의 스펙이 어떻게 되어 있는지 나와있는 중요한 곳이기 때문에 보호받아야 한다.

아마도 pe 로더가 pe header가 메모리에 올라갈 때 읽기 엑세스만 주어진 것으로 보인다.

Dos Stub는 16비트 이하에서만 실행되는 코드라고 했다.
가변의 길이인 Dos Stub를 무시하고 pe 로더가 스펙으로 보게 되는 PE시그니처의 위치는 e_ifanew에 담겨있다.

만약에, Dos Stub을 쓰기 위한 공간을 코드나 읽기전용 데이터로라도 사용할 수 있을까?
문자열 패치를 할 때, data섹션을 사용하지 않고도, 패치를 시킬 수 있을까?
Dos Stub에 실행코드가 담겨있다면, 그것을 읽어 코드 섹션에 다시 쓴 다음 사용할 수 있을까?

한 번 시도해 보기로 했다.

이전의 인라인 코드 패치 실습에서부터 시작한다.
https://terria1020.blogspot.com/2020/01/code-cave-patch.html

코드 케이브가 담긴 프로그램으로부터, 실험을 해 본다.

프로그램의 Dos Stub는 이 만큼의 크기를 가지고 있다. 그리고 패치를 위한 문자열의 주소는 data섹션의 끝에 이렇게 담겨있다.

이 문자열을 data섹션에서 사용하지 않고, dos stub에서 사용 할 것이다.

그대로 복사해서, dos stub에 붙여넣어보자.

위에서 dos stub의 메모리, pe header가 담기는 메모리는 읽기 전용일 것이라고 했다.
저 공간은 프로그램을 실행했을 때 분명히 읽을 수 있는 것이 맞다.

저장을 한 후, x32dbg로 열어 보았다.

덤프 창을 보면 메모리에 잘 탑재되어 있는 것을 볼 수 있다.

간단히 프로그램을 실행 중 패치시켜 과연 읽어왔을 때 엑세스 오류가 뜨는 지 확인 해 보자.

문자열 인자를 넣는 곳을 빠르게 패치한 후, 실행시키면

디버거에서 별 문제 없이 실행이 되는 것을 볼 수 있다.

Dos Stub에 data를 넣고 읽었을 때 문제가 없이 사용되는 것을 볼 수가 있다.

그런데, dos stub는 16비트 이하에서 프로그램이 실행 시 실행되는 코드라고 하지 않았던가?
pe 로더는 16비트 가상환경에서 저 프로그램이 실행 시 16비트 pe 로더가, 16비트 시절 pe구조를 보고 dos stub 코드를 '실행'할 것이다.

그렇다면, 현 32비트 체제에서도 pe로더는 16비트 운영체제를 위한 dos stub를 pe header에 구조로서(호환성을 위해) 남겨두었다면, 디버거에서 본 메모리 맵 권한과 별개로 dos stub가 들어있는 일부 메모리 공간은 실행 권한도 부여되지 않았을까?

두 번째 실험으로 한번 해 보자.

처음에 메시지 박스를 띄우는 바이너리를 복사 해 두었다.

이 메시지 박스를 띄우는 바이너리는,
6A 00 68 00 20 40 00 68 12 20 40 00 6A 00 E8 4E 00 00 00 이다.
이 것을 dos stub에 직접 패치시켜보자.

dos stub의 공간에 붙여넣기 한 뒤,
디버거로 실행시킨다.

디버거에서 직접 0x00400040 (Dos Stub가 있는, 메모리에 올라간 주소)로 점프해 보면 일단 잘 수정되어 있다.

여기에 새 원점을 두고 실행을 시켜 봤을 때, 권한 오류가 난다면 실행 코드로서 사용을 하지 못할 것이고, 실행이 된다면 위의 dos stub의 크기만큼은 실행 권한이 주어진다는 예측을 맞출 수 있을 것이다.

생각보다 쉽게 실행이 된다!

Dos Stub가 위치하는 어떤 다른 위치에 다시 실행코드를 적고 실행해도,

아주 잘 된다!..

pe로더는 dos stub이 올라가는 메모리 공간은 호환성을 위해 실행 권한이 부여 된 것을 확인할 수 있었다.
더불어 code cave를 dos stub의 공간을 이용해서 사용해도 될 것 같기도 하다.
여러 응용이 가능할 것이다. 가령 e_ifanew의 위치를 바꿔 dos stub의 공간을 늘리고, 코드를 더 사용할 수 있게 해 둘 수도 있다.

-추가-
윈도우의 DEP 기법이 걸려있는 프로그램은 적용이 되지 않는것을 확인했다.
DEP 기법이 적용되어 있어도 코드를 실행시키는게 아닌 읽는 권한은 가능하므로 문자열 등의 읽기 데이터는 사용 가능한 것을 확인하였다.

DEP기법과 별개로 PAGE_GUARD가 걸려 있어도 사용이 불가능하다는 것을 확인하였다.

실행 권한이 주어지는 극히 일부의 메모리라고 해도 각종 윈도우 보안, 패커의 사용 여부 등에 의해 크게 의미가 없는 실행 권한일 것 같다.