문제확인

UPX패킹이므로 언패킹을 해야한다. 본인이 사용하는 방법은 3가지이다.

1. OEP를 찾아서 그 부분부터 분석을 하는것

2. OEP를 찾아서 OllyDump를 통행 덤프를 뜬 후 LoadPE를 통하여 Rebuild를 한 후에 분석

3. UPX.exe를 통하여 언패킹을 한 후에 분석을 한다.

여기서 나는 3번의 방법을 통하여 분석을 실시하였다.      >>    $ upx -d 06.exe

풀이

아래의 JMP가 가르키는 곳이 OEP지점이다. 이 지점으로 점프를 하여 분석을 하면 된다.

아래와 같이 성공부분의 분기점이 나뉘어진 곳을 찾을 수가 있다. 이 부분에서 ASCII AD46DFS547 이라는 키 값을 찾을 수가 있다. 따라서 OEP+Key 이므로 00401360AD46DFS547이 이번 문제의 정답이다. 

문제확인

프로그램을 실행하면 다음과 같다. 이와 같이 아이디와 시리얼 값을 찾는 것이 문제이다.

디버깅에 앞서 PEID를 통하여 분석을 해보면 UPX로 패킹이 되어 있는 것을 확인 할 수가 있다.

풀이

방법은 두가지이다. POPAD 다음의 점프 부분이 본래의 코드 부분으로 점프를 한 후에 분석을 진행 할 수가 있다. 하지만 이는 지속적으로 분석하기에 번거로움이 있다.

따라서 우리는 upx를 통하여 unpacking을 진행 한 후에 프로그램을 분석 할 것이다.

분석을 하다보면 문자열을 검색하여 성공 구문을 찾은 후에 분석을 하면 되는데 총 두번의 문자열비교가 일어난다. 아이디와 시리얼 값이 각 각 따로 비교가 진행이 되며 진행 되는 방법은 다음과 같이 EAX에는 우리가 입력한 값과 EDX에는 비교에 사용될 원래의 값이 존재한다. 이를 통하여 우리는 시리얼 값을 찾을 수가 있다.

이에 따라 입력을 한후에 실행을 할 경우 성공 구문이 나타나는 것을 확인 할 수가 있다.

추가

OEP지점으로 이동하여 OllyDump를 통하여 직접 덤프를 뜰 수가 있다. 해당 플러그인을 통하여 OEP지점에서 DUMP를 클릭한 후에 rebuild를 해제 한 후에 완료를 클릭한 후에 LoadPE를 통하여 프로그램을 다시 재설정 해주면 upx패킹을 언패킹 할 수가 있다.

LordPE Deluxe.zip

OllyDump.dll

문제확인

<일반적인 방법으로 프로그램을 실행할 경우>

<디버깅을 통하여 프로그램을 실행할 경우>

풀이

프로그램을 천천히 분석하다 보면 디버깅이 걸리는 시점을 찾을 수가 있다. 바로 아래의 IsDebuggerPresent 지점이다. 이 부분에 의하여 디버깅이 걸리는 것이다.

따라서 안티디버깅을 피하기 위해서는 IsDebuggerPresent를 NOP로 채우는 것도 하나의 방법이다. NOP로 채움으로 인하여 디버깅일 정상적으로 실행 되는 것을 확인 할 수가 있다. 또는 MOV EAX,0을 통하여 무력화 할 수도 있다.

문제 확인

문제를 실행 할 경우 아래와 같이 동작하는 것을 확인 할 수가 있다.

풀이

123을 키 값으로 넣었을 경우 아래와 같이 비교 문자열이 존재하는 것을 확인 할 수가 있다.

따라서 문자열 비교 함수는 vbaStrCmp이며 키 값은 2G83G35Hs2 인 것을 확인 할 수가 있다.

문제확인

아래와 같이 패스워드를 확인하는 문제이다. 하지만 실행파일이 손상되어 실행이 되지 않는다. 실행을 하여보자.

실행을 할 경우 windows8.1에서는 아래와 같이 뜨는 것을 확인 할 수가 있다. 따라서 우리는 다른 방법으로 이 프로그램을 분석하여야 한다. 참고로 손상이 되었기에 디버깅도 가능 하지 않다. 따라서 우리는 HexEditor를 통하여 프로그램을 분석하여 보자.

풀이

아래와 같이 문자열이 기록되는 부분으로 추측 되는곳에 패스워드로 추측이 되는 문자열을 확인 할 수가 있다. 이처럼 우리는 패스워드를 쉽게 찾을 수가 있다.

문제확인

문제는 아래와 같이 GetDriveTypeA가 CD-ROM으로 인식 되기 위해서는 어떤 리턴값이 와야 하는지에 대한 문제를 구하는 방법이다.

아래와 같이 BP를 걸고 실행시 EAX에 3이 반환 되는 것을 확인 할 수가 있다. 이는 DRIVE_FIXED가 반환 되는 것으로 MSDN을 통하여 확인을 할 수가 있다. 또한 여기서 우리는 DRIVE_CDROM이 Return Value 5에 있는 것을 확인 할 수가 있으며, 이를 통하여 우리는 문제를 풀 수가 있었다.

풀이

하지만 여기서 CMP EAX,ESI를 통하여 분기점이 나뉘어지는데 여기서 문제가 이상한 것인지 EAX에 5를 넣어도 CMP EAX(3), ESI(4010003)이 비교가 되어서 결국 실패하는 부분으로 가게 된다. 따라서 우리는 성공 문자를 출력하기 위하여 다른 방법을 사용하여야 한다.

아래와 같이 JE를 JNE로 바꿈으로 인하여 우리는 성공 메세지를 확인 할 수가 있다.

PE파일이 메모리에 로딩되었을 떄 각 섹션에서 메모리의 주소와 파일 옵셋을 매핑하여보자.

위의 사진은 리버스코어 블로그에서 퍼온 것으로 메모리에서는 VA로 위치를 표한하며 파일에서는 Offset으로 위치를 표현하는데

그림과 같이 파일에서와 메모리에서의 위치가 차이가 나는 것을 확인할수가 있다. 그렇기에 메모리에서의 값을 확인한 후에 수정을 하고자 할때에는 직접 그 위치의 Offset 값을 구하여 찾아 가야한다. ( 물론 PEView 를 통해 편하게 할수도 있다.)

RAW = RVA - VirtualAddress + PointerToRawData

RAW = 파일에서의 주소

RVA = 메모리에서의 주소

VirtualAddress = 메모리에서의 섹션 시작 위치

PointerToRawData = 파일에서의 섹션 시작 위치

우선 RVA - VirtualAddress를 통하여 메모리에서의 해당 주소가 섹션 시작 위치로 부터 몇번쨰 순서에 있는지를 알기 위함이다. 이를 통하여 메모리에서의 몇번쨰 순서인지를 알게된후에 파일에서의 섹션 시작위치 값을 더해준다면 파일에서의 섹션시작위치 + 순서값 = 을 통하여 파일에서의 주소를  알수가 있다. 이를 통해 다른 블로그의 RVA to RAW를 본다면 훨씬 이해가 쉬울것이라 혼자 생각한다.

EAX : 산술 연산을 수행하기 위해 사용되거나 함수의 리턴 값을 전달하기 위해 사용된다.

EDX : 데이터 레지스터로 기본적으로 EAX 레지스터의 확장 개념으로 사용된다. 즉 곱하기나 나누기 같이 복잡한 연산을 위해 추가적으로 데이터를 저장할 때 사용된다. 또한 범용 목적의 저장소로도 사용이 된다.

ECX : 카운터 레지스터라 불리며, 반복적으로 수행되는 연산에 주로 사용된다. 반복 연산에서는 문자열을 저장하거나 카운트를 세는 작업이 수행 된다. 중요한점은 ECX는 값을 감소시키면서 카운트를 센다는 점이다.

           예: count = 0

           While count < 10:

           Print “Loop num : %d” % count

           Count+=1

에서 위 코드를 어셈으로 변환해보면 카운트 값을 나타내는 ECX의 값이 첫번째 반복 연산을 수수행할 때 10이고, 두번째에는 9로 감소한다는 것을 알수 있다.

ESI : EDI와 같이 데이터를 처리하는 반복문에서 효과적으로 데이터를 처리하기 위해 사용된다. ESI는 데이터 연산을 위한 Source Index를 나타내거나 입력 데이터 스트림의 위치를 나타낸다.

EDI : 데이터 연산의 Destination index(목적지)를 나타내거나 데이터 연산의 결과가 저장 되는 위치를 나타내는데 사용된다. ESI는 읽기위해 사용되고 EDI는 쓰기 위해 사용된다고 생각하면 된다.

ESP : Stack pointer로 EBP와 함께 함수 호출과 스택연산에 쓰인다. 힘수기 호출 될 때 먼저 함수에 전달되는 파라미터가 스택에 PUSH되고 그 다음에는 리턴 주소가 스택에 PUSH된다. ESP 레지스터는 스택의 가장 높은 주소를 가리킨다. 따라서 함수 호출시 ESP 레지스터는 리턴 주소를 가리킨다.

EBP : Base pointer, EBP 레지스터는 호출 스택의 가장 낮은 위치를 가리키는데 사용된다.

EBX : 특정한 목적이 없는 레지스터로 추가적인 저장소로 이 레지스터를 사용한다.

EIP : 현재 실행 중인 명령의 주소를 가리킨다. CPU가 바이너리 코드를 실행시킴에 따라 EIP 레지스터는 CPU가 현재 어느 코드를 실행중인지 나타내기 위해 계속적으로 코드의 주소를 갱신한다.