Level 34

이번 레벨에서는 패킹 된 바이너리를 언패킹 하지 않고, 패킹 된 상태에서

분석하는 법에 대하여 다룰 것이다.

대부분의 경우, 리버싱을 할 때 처음에는 바이너리가 패킹 되어 있는지

확인하는 것이다. 또한 바이너리를 리버싱 하기 위해서는 꼭 언패킹을 할

필요는 없다. 따라서 이번에는 언패킹을 하지 않을려고 한다. 이런 작업은

대상 바이너리가 패킹되어 있는데 어떤 이유로 인해 덤프를 뜨지 못 할

경우 유용하게 사용될 수 있다. 패킹된 모든 바이너리는 실행되고 나면

언젠가는 메모리에 언패킹 된 상태로 저장되어 있을 것이기 때문에 올리

디버거에서 실행시킨 뒤 언패킹 된 상태가 메모리에 저장된 시점부터

분석을 시작할 것이다.

* "PEiD", "Detect It Easy" 등과 같은 패커 탐지 툴에서는 위 사진처럼 지금 분석

하려는 바이너리가 "ASProtect 1.23 - 2.56" 패커가 사용되었다고 나온다. 다만

해당 패커의 프로텍터 옵션을 모두 사용되지 않은 듯 하다. 이번 레벨의

목표는 언패킹이 아니기 때문에 해당 패커가 어떤 옵션으로 사용되었는지

확인하는 작업은 필요 없다. ( OEP를 찾는 작업은 꽤 간단한데, 그냥

"401000" 주소에 HW BP를 설치하고 실행하면 된다. )

* 일반적으로 "ASProtect" 패커가 적용된 바이너리에서 OEP를 찾으려면, 디버거

옵션에서 커널을 제외한 "Exceptiosn"을 모두 체크 해제한 다음에 바이너리가

완벽하게 실행 될 때 까지 "Shit+F9"를 계속 누른다. x 번째에서 실행되었다면

재시작 한 뒤 "Shift+F9"를 (x-1)번 만큼 누른 뒤 코드 섹션에 BP를 설치하고

한번 더 "shift+F9"를 누르면 OEP로 이동된다.

바이너리 실행 시 위와 같은 nag 창이 나타난다. 리버싱을 쉽게 하기 위해 많은

정보를 제공하는 것이 바로 위 사진의 nag 창 자체이다. 프로그램의 등록 상태를

시작할 때 판단하는 것을 알 수 있는데, 만약 이 nag 창을 생성하는 코드를

찾으면 생성 이전에 분명히 조건문이 있을 것이다. ( 등록 vs 등록 안됨 )

* 이 바이너리의 EP 값은 OEP와 도일하다. 이번 레벨에서는 이전에 설명했던

OEP의 개념을 무시할려고 한다. 다만 코드를 분석하고, 문자열/레퍼런스 검색

등을 위해서는 코드 내에서 "시작점"을 찾아야 한다. 사실 코드 내의 어떠한

부분이던 첫 번째 스크린이나 nag 창이 생성되기 전에 위치한다. 이번 분석에

서는 시작점을 방금 전에 보았던 nag 창을 잡을 것이다. 다만 리버싱을 연습

하기 위해 "backtracing" 방법을 이용하여 OEP 부터 찾고자 한다.

* nag 생성 코드를 패커 코드에서 찾으면 안된다는 것을 기억하길 바란다. 이번

바이너리는 nag 창을 메인 프로그램에서 생성했지만, 만약 nag 창이 생성되지

않는 바이너리의 경우에는 그냥 처음 나타나는 윈도우(대부분 메인 프로그램)을

찾으면 된다.

nag 창이 생성된 상태에서 F12 / Alt+K 를 눌러 디버거를 일시 중지 시킨 뒤

위 콜 스택 창에서 보여지는 함수를 이용하여 nag 코드를 찾을 것이고 해당 코드

이전의 코드를 찾아 리버싱을 위한 시작점으로 잡을 것이다. 쉽게 설명하자면

그냥 가짜 "OEP"를 생성하는 것이라고 생각하면 된다.

콜 스택에서 “005DDC5F” 주소로 이동한 다음 해당 코드 루틴의 함수 프롤로그쪽

으로 이동하여 HW BP를 설치한다. 이후 프로그램을 재시작(F12)한 뒤 실행(F9)

하며 방금 설치한 HW BP 주소에서 멈추게 된다.

콜 스택이 아무런 정보도 제공하지 않는 것에 비하여 시스템 스택은 약간의 정보를

제공한다. 일단 시스템 스택 정보를 이용하여 새로운 HW BP를 설치하기 전에,

이전에 설치했던 BP부터 삭제해야 한다. ( HW BP는 최대 4개까지 설치할 수

있기 때문에 필요 없는 BP는 가능한 제거하는 것이 좋다. )

시스템 스택에서 보여지는 리턴 주소(00402A01, 호출된 함수 다음의 주소)로 이동

한다.

리턴된 주소 이전에 “004029FB | CALL [EDX+D8]”에서 호출되는 함수가 nag 창을

생성하였다. 그런데 바로 위쪽에 “JNZ” 조건문의 조건에 따라 해당 함수가 실행

될수도, 안될 수도 있다. 일단 해당 주소를 기억해둔 뒤 먼저 OEP를 찾고 난 뒤에

분석을 할 것이다.

이동된 코드 루틴의 함수 프롤로그(시작) 부분으로 이동한다. 이전과 동일한 방법

(HW BP, 시스템/콜 스택 이용)을 이용하여 OEP를 찾을 것이다.

이전과 동일하게 함수 프롤로그에 HW BP를 설치하고, “재시작 / 실행”을 하면 BP

주소에서 멈춘다. 그리고 시스템 스택창에서 보여지는 리턴 주소로 이동한다.

이번에도 이전과 동일하게 이동된 리턴 주소의 함수 프롤로그 부분으로 이동하여

HW BP를 설치한 뒤 “재실행 / 실행”하면 해당 주소에서 멈춘다. 이번에는 콜

스택 창을 통하여 리턴 주소를 알아낼 수 있다.

리턴되는 주소 “0040133C | CALL 005E11E4” 위쪽을 보면 “JE” 조건문이 2개 있는

것을 볼 수 있는데, 조건문 이전에 호출된 “00658036” 함수의 리턴값에 따라

분기가 되어 nag 창을 생성했던 “005E11E4” 함수의 호출 여부가 결정되고 있다.

어찌되었든 이번에도 마찬가지로 리턴된 주소의 함수 프롤로그 주소로 이동하여

“HW BP 설치 / 재시작 / 실행” 한 뒤 시스템 스택창에서 보여지는 리턴 주소로

이동한다.

이번에도 마찬가지로 “리턴 주소의 함수 프롤로그 주소로 이동 / HW BP 설치 /

재시작 / 실행” 과정을 거친다.

그런데 이번에는 시스템 스택 창에서 리턴되는 주소가 존재하지 않는 것을 볼 수

있다.

시스템 스택 창에서 스크롤을 조금 내려 메인 프로그램의 코드 섹션으로 리턴

되는 마지막 부분을 찾으면 위 사진과 같다. 해당 주소에서 리턴 되는 주소값을

메모리맵 창에서 봐야 한다.

"00814404" 주소는 메모리 맵 창의 주소/섹션 정보로 미루어 보아 “ASProtector

패커” 코드가 위치한 주소이다. 점점 OEP 쪽으로 다가가고 있는 것을 알 수 있다.

바로 이전에 설치한 HW BP 주소는 "0063F5A4" 였는데, 시스템 스택 창을 보면

리턴하고 있지 않고 있었다. 해당 주소가 OEP 주소일 가능성도 있다. 그러나 다른

방법으로도 OEP로 추정되는 "0063F5A4" 주소로 접근할 수도 있다.

OEP로 추정되는 “0063F5A4” 주소에 “Ctrl+R”을 누르면 해당 주소와 연관된 주소/

명령어를 보여주는데, “JMP” 분기문이 사용되는 것을 볼 수 있다.

패커가 적용되어 있기 때문에 올리 디버거에 “Ctrl + A (코드 재분석)”을 적용

시키면 위 사진에서 보여지는 것처럼 분기됨을 의미하는 빨간 화살표와 함께

“00401054” 주소에서 분기되는 것을 볼 수 있다.

분기시키는 “00401054” 주소로 이동한 뒤 스크롤을 위로 올리면 바이너리의

OEP를 찾을 수 있다. (이전에 말한것처럼 “00401000” 주소이다.)

지금까지 보여준 것은 OEP를 찾는 또 다른 방법이였다. 일반적으로 OEP를 찾는

"ESP Trick" 방법 등과 비교해보면 꽤 시간을 잡아 먹는 방법이긴 하지만 연습

하는 입장에서는 이런 것 또한 알아두는 것이 좋다.

어쨌든 이전에 설명한것처럼 이번에는 언패킹을 하지 않을 것이기 때문에, 방금

찾은 OEP는 그냥 잊어버리기 바란다. (그냥 OEP 찾는 방법을 보여주기 위함

이였다.) 따라서 이전의 HW BP 주소로 이동한 다음, 해당 주소를 가짜 OEP로

생각하여 분석을 시작할 것이다. ('-' 키를 눌러 이전 주소로 이동한다)

이전의 HW BP 주소로 이동한다. 대부분의 경우 리버싱을 위하여 OEP를 찾을 때

까지 현재 주소를 기준으로 이전에 호출된 함수를 백트레이싱 할 필요가 없다.

다시 한번 말하지만 현재 주소의 HW BP를 그냥 가짜 OEP로 생각해야 한다.

이 후 리버싱은 지금까지 한 것과 크게 다르지 않다.

프로그램을 실행하면 nag 창이 나타났을 때 “OK” 버튼을 누르면 메인 프로그램이

실행된다. 메인 프로그램이 실행되면 타이틀바 부분에 “Remind! Evaluation

Version” 문자열이 보여 진다.

“Help – About Remind!” 메뉴를 누르면 우측 사진처럼 “Evaluation version”

문자열이 보여 진다.

이전에 기억하라고 해두었던 주소(4029BE)로 이동한다. 해당 주소에서 nag 창을

생성하기 때문에 호출되는 “[EDX+D8]” 함수에서 하는 것이 “프로그램 등록 상태

체크” 라고 추정할 수 있다. 그리고 위쪽에 보여지는 “JNZ” 조건 상태에 따라

해당 함수가 실행 될 수도, 안 될 수도 있다.

그리고 해당 조건문 위쪽에서 “CALL 006436F0” 함수에서 호출하고, 이후에 CMP

명령어로 ‘0’과, “[ECX+6D0]” 포인터 값을 비교하고 있다. 만약 해당 포인터 값에

EAX 레지스터 값이 참조되면 “006436F0” 함수를 분석해서 리턴 값을 분석해야

한다.

해당 주소까지 진행해보면 포인터 값이 ‘0’이기 때문에, 이 값을 ‘0’과 비교해서

“JNZ” 조건문을 이용하기 때문에 분기가 일어나지 않아 nag 코드가 실행 된다.

해당 포인터 값을 임시적으로 ‘1’로 변경하여 분기가 일어나게 하여 nag 코드를

우회하여 정상적인 “등록” 상태로 프로그램이 실행되는지 테스트를 한다.

값을 변경하고 실행하면 프로그램 타이틀바 부분의 문자열과, “About” 메뉴에서

정상적으로 등록되었다고 나오게 된다. 임시적인 해결 방법을 찾았으니, 이제

패치하는 방법을 찾아야 한다.

프로그램을 재시작 하여 이전에 패치 했던 주소로 이동하여, 해당 주소와 연관된

명령어들을 봐야 한다.

연관되는 명령어들을 보니 “[ECX+6D0]” 포인터 값과 ‘0’ 값을 비교하는 명령어는

4개, “MOV” 명령어로 포인터 값을 세팅하는 명령어는 1개임을 볼 수 있다. 분석을

위해 모든 명령 주소에 BP를 설치한 뒤 실행(F9) 시킨다.

이전 사진에서 보았던 모든 주소에 BP가 설치되었기 때문에 프로그램을 실행하면

처음에 포인터 값을 세팅하는 주소로 이동된다. 해당 주소의 명령어를 “0 => 1”로

패치하여 포인터 값을 ‘1’로 세팅시킨다. 이렇게 하면 전에 보았던 조건문에서

분기가 일어나서 nag 생성 코드를 실행하지 않을 것이다.

패치하고 실행(F9)하면 처음으로 해당 포인터 값과 '0'을 비교하는 곳에서 멈춘다.

그런데 패치를 했음에도 불구하고 포인터 값이 '1'이 아닌 '0'으로 되어있다. 이런

일이 발생하는 이유는 해당 포인터 값을 체크하여 (더블 체크) '0'으로 만들어

버리는 명령어가 있기 때문이다.

비교되는 포인터 값을 덤프 창에서 이동하여 해당 주소에 “MEM BP”를 설치한다.

“MEM BP”설치 후 한번 더 실행(F9)하면 “00425077” 주소에서 멈추는데, 이번에는

“[EBX+6D0]” 포인터 값을 ‘0’으로 세팅하고 있다. 즉, “[ECX+6D0], ”[EBX+6D0]“

2개의 레지스터를 이용하여 더블 체크를 하고 있는 것이다. 마찬가지로 이전과

동일하게 패치를 한다.

패치 후 한번 더 실행하면 비교되는 포인터 값이 ‘01’로 세팅되어 비교되는 것을

볼 수 있다.

이 상태에서 쭉쭉 실행(F9) 시키면 메인 프로그램이 실행된다. 이전에 임시적으로

패치했던 때와 동일하게 프로그램 타이틀 바 부분의 문자열이 사라진다.

메인 프로그램이 실행 된 뒤 “About Remind!” 메뉴를 클릭하면 다시 한번 이전에

설치했던 BP 주소에서 멈춘다. 프로그램이 정상적으로 등록되었는지 이중으로

체크하고 있는 것이다. 물론 이전에 패치를 했기 때문에 포인터 값이 ‘01’로 세팅

되어 있다.

모든 부분이 정상적으로 작동된다. 따라서 이전에 보았던 2개의 MOV 명령어를

사용하는 곳을 '0' -> '1'로 바꿀 필요가 있다.

1. "VA : 4023CF / 00 => 01"

2. "VA : 425077 / 00 => 01“

프로그램에서 무결성 체크를 하고 있기 때문에 패쳐를 사용하는 것은 무리가

있다. 따라서 이번에는 로더를 작성할 것이다.

* 패쳐는 프로그램의 명령어 자체를 수정하기 때문에 패킹 된 바이너리의 코드를

수정해 버리면 무결성 체크에서 걸리게 된다. 물론 언패킹을 해서 덤프를 뜬 뒤,

원본 바이너리에서 수정을 하면 통과할 수도 있다.

* 패쳐가 프로그램이 처음 실행 될 때부터 영향을 주는 것에 비하여 로더는 특정

조건을 만족시킬 때만 실행되게 만들 수 있기 때문에 무결성 체크로부터 좀 더

자유롭다.

위 사진처럼 “dUP”를 이용하여 로더 생성 프로젝트의 초기 값을 세팅한다. 세팅

하면 본격적으로 어떤 로더를 만들 것인지 정해야 한다.

오프셋 로더 역시 잘 동작하겠지만 이번에는 "Search & Replace (이하 S&R) 로더를

만들것이다.

* S&R 로더의 장점은, 이 로더는 특정 바이너리(이진) 문자열을 검색한다는 것이다.

따라서 이런 종류의 로더는 소프트웨어가 업데이트 되서 약간의 변화가 생겨도

대부분 동작할 것이다. ( 다른 주소에 위치한 동일한 바이트를 패치할 수 있기

때문이다 ). 오프셋 로더의 장점은 만들기 쉽고, 사용하기 쉽다는 점이다.

S&R 로더를 위해 위와 같은 설정을 한다. 위와 같이 원본/치환 패턴을 입력하면

“4023CF” 주소가 패치되는 것이다.

“425077” 주소 패치를 위해 위와 같이 또 다른 원본/치환 패턴을 입력한다.

* 올리 디버거에서 위 사진에서 입력한 "Search Pattern" 바이트가 다른 곳에

있나 없나 체크했지만 다른곳에는 없었다. 좋은 S&R 로더를 만드는 것은

소프트웨어의 다음 버전에서도 존재할만한 유니크한 바이트를 대상으로 바이트

패치를 이용하는 것이다.

* 이전 사진의 아래쪽에 위치한 "MemCheck" 기능을 이용하지 않으면 로더를

동작하지 않는다. (패커의 무결성 체크 때문에 동작이 실패한다). 따라서 로더는

패킹 된 바이너리가 언패킹이 끝나고 무결성 체크(CRC 체크)가 끝날 때까지

대기한 뒤에 실행되어야 한다.

* ASProtector 패커는 쉽게 우회할 수 있는 CRC 체크를 무결성 체크로 이용한다.

참고로 CRC 체크는 "VA : 00D9A337" 주소에서 수행된다. 해당 순간에 올바른

CRC 값은 "[ESP+14]" 주소에 위치하고, CRC 체크의 결과는 EAX 레지스터에

저장된다. 따라서 "00D91714" 함수 내부로 이동하여 첫 번째, 두 번째 라인을

"MOV EAX,DOWRD PTR [ESP+14]", "RETN" 으로 패치해 버리면 항상 무결성

체크를 우회할 수 있다.

* CRC 체크 주소를 찾는 것이 힘들다면, "diablo2002"가 만든 툴을 이용할 수

있다. (해당 툴은 ASProtector 패커가 적용된 바이너리에서 무결성 체크를 우회

하기 위해 패치해야 하는 주소와 바이트를 알려준다)

* 그러나 좀 더 범용적으로 사용되는 로더(ASProtector 무결성 체크를 우회하지

않는 로더)를 만들고자 한다. 위에서 말햇듯이 무결성 체크가 끝난 뒤에 로더를

실행시키면 되는데, 이는 로더가 특정 "DWORD" 값을 액세스 할 때 까지 기다

리는 설정을 주어 해결할 수 있다.

분석 대상 바이너리의 OEP 주소(00400000) 조금 아래쪽에 보면 [659D5B] 포인터에

EAX 값을 복사하고 있다.

바이너리가 언패킹이 되기 전에는 [659D5B] 포인터 값은 “00000000”로 세팅된다.

그러나 바이너리가 언패킹이 완료되면 포인터 값이 “00400000”로 변하게 된다.

즉, 로더에서 위 주소의 값이 "00400000" 일 때까지 멈춘 뒤 실행하라고 세팅

하면, 언패킹이 끝나고 CRC 체크가 종료 된 뒤에 로더가 실행 될 것이다.

패킹 된 바이너리를 패치하기 위해 “Patch compressed PE File” 옵션을 체크하고,

“Enable MemCheck” 옵션을 체크하여 위 사진과 같이 세팅한다.

세팅 후 로더를 생성하고 실행하면 바이너리가 무결성 체크를 우회하고 정상적

으로 등록된 상태로 실행 된다.