Zero's hobby blog.

언팩완료.  클리어

내 수리능력이 참으로 원망스러웠던 문제..

고길님의 문서를 보고 마지막의 EAX와 EBX를 구해서 제일 처음의 EAX와 EBX로 만들고 언팩했다.

원본 파일에 트랩이 있어서 삽질을 조금. ..

오리지날 파일이 왜 제공됐는가 의문이었는데 원본 메모리를 뜯어보니 문서와 똑같이 따라하면 실패하도록 트랩이 설치되어있었다. -_-

goodluck ....

가장 처음의 EAX와 EBX를 구하는 소스코드 

#include <stdio.h>


int main(void)
{
    unsigned int prev = 0x726ee12b, ofst = 0x20c1085a, check = 0;
    unsigned char bhChk=0;
    unsigned int reEbx = 0x????????; 

// 가장 마지막의 Ebx값을 reEbx에 넣어주면 된다. 이 값을 적고 프로그램을 돌리면 바로 답이 나오기에 이 값은 블라인드 처리..

    _asm{
        push ebx
            push eax
            push edx
            push ecx
            xor ecx,ecx
            xor edx,edx
            xor ebx,ebx
            xor eax,eax
    }


    for(unsigned char i=0; i<=0xFF; i++){
        _asm{
            mov eax,ofst
                mov cl, i
                rol eax, cl
                xor eax, prev
                mov check, eax
                mov ebx, check
                mov bhChk, bh
                mov eax, prev
                mov cl, al
                ror ebx, cl
                mov check, ebx
        }
        if(bhChk == i)
        {
            printf("BH : %x, EBX : %x\n", i, check);
        }

        if(i == 0xFF){
            break;
        }
    }

    _asm{
    }

    for(unsigned int i=5; i<=0x1000; i++){
        _asm{
                mov ebx, reEbx
                mov eax, prev
                sub ebx, eax
                mov cl, bh
                rol eax, cl
                xor eax, ebx
                mov cl, al
                ror ebx, cl
                mov reEbx, ebx
                mov prev, eax
        }
    }



    _asm{
            pop ebx
            pop eax
            pop edx
            pop ecx
    }

    printf("prev EAX...EBX %x, %x\n", prev,reEbx);

    return 0;
}

1차 시도 : 15/02/27

PEB에서 비롯되는 Ldr, Heap 안티 디버깅을 지나  OEP 도달. 

scanf 로 입력을 받고 난 뒤 ZwQueryInformationProcess API를 사용하는 안티 디버깅에 걸려서 실패 . 

오늘은 여기까지.

2차시도 : 15/02/28 

2차시도 4시간 30분만에 클리어. 

내용이 너무 방대해 자세한 내용은 나중에 쓸까 말까 고민중입니다. .

간략히 설명하자면

처음엔 1차시도에서 확인한 PEB 관련(Ldr, HeapFlag ) 안티디버깅이 3회 출몰합니다. 

그리고는 이제 Main만 분석하면 될것처럼 OEP가 등장하고 

scanf로 입력을 받다가 뜬금없이

ZwQueryInformationProcess native API로 2회 안티디버깅이 나옵니다. 

이제 정말 끝이겠지 하고 분석을 하던 도중 GetThreadContext로 디버그 레지스터에서 하드웨어 브레이크가 있는지 없는지 검사합니다.(분석하면서 하드웨어 브레이크를 사용할 일이 없었기에 무사히 넘어갔습니다.)

여기까지 지나면 드디어 내가 입력한 값들이 어떤 연산으로 분기되는지 나옵니다. 

그리고 대망의 비교루틴에서도 한 두번씩 페이크가 나옵니다 - -. 

1번째 문자에대한 페이크와 몇번째인지 기억은 안나는데 예, 예, 예 버튼 막 누르던 도중에 예 버튼자리에 아니오가 온 느낌이랄까요. 

그런느낌으로 엄한데로 점프 시켜버립니다 --. 

다행히 점프하기전의 스택으로 돌려놓고 origin 바꿔서 되돌아 오긴했습니다만.. 인내심을 시험받은 듯한 느낌이 드네요..

일단 여기까지

파일 디스크립트 문제, UPX 실행 압축과 매우 긴 쓰레기 코드로 리버싱을 방해한다.

중요 부분만 빠르게 체크하자

먼저 쓰레기 코드를 건너 뛰기 위해 printf 함수에 BP를 걸어 실행한다.

그러면 위와같은 파일관련 함수 호출이 연이어 등장하는 루틴을 발견할 수 있다.

401000 CALL 명령은 리버싱을 방해하는 쓰레기 코드이니 무시하자

내가 입력한 문자열을 순서대로 한개씩 돌려가면서 복호화 키로 사용하고 있다.

그리고 마지막 즈음에 파일 전체에 XOR EDX,0FF 명령으로 다시 한번 복호화를 진행한다.

암호화 루틴은 매우 간단하다.  내가 입력한 문자열을 순서대로 하나씩 뽑아서 암호화 하고, 다시 0xFF로 전체 파일을 암호화 한것이다.

그럼, 전체 파일을 0xFF로 한번 복호화 하고

일반적인 PE 실행파일에서 공통적으로 등장하는 부분을 0~0xFF 모든 경우로 다시 복호화해서 비교해보면 되겠다.

나는 도스 스텁 코드로 나오는 is program cannot 을 대상으로 복호화를 진행했고 복호화 키값을 얻어낼 수 있었다.

(간단한 프로그램을 짜서 is program cannot 스텁 부분의 문자열을 무차별 복호화 한 값하고 비교해보면 간단히 나온다.)

복호화 키값으로 원본 파일을 복호화 해보면 키값을 출력하는 프로그램이 나온다. 

복호화에 사용된 소스 :

#include "stdafx.h"
#include <string.h>

char sig[100];
char cksig[100];

int _tmain(int argc, _TCHAR* argv[])
{
    char chk;
    FILE* file = fopen("file", "r+b");


    strcpy(cksig, "is program cannot");

    rewind(file);
    fseek(file,0x50,SEEK_SET);

    for(int j=0; j<100; j++){
        sig[j] = fgetc(file);
        sig[j] ^= 0xFF;
        for(int i=0; i<=0xFF; i++){
            chk = sig[j] ^ i;

            if(chk == cksig[j]){
                printf("%c", i);
                break;
            }
        }
    }


    fclose(file);


    return 0;
}

크기가 매우 작은 간단한 게임이다.

처음 실행 하자마자 메모리 영역을 보면 알수 없는 문자들이 있는데

몬스터를 잡다보면 이 곳이 복호화 되는 것을 확인할 수 있다.

몬스터 한마리당 한글자를 복호화 하지만 총 글자수가 50개인 반면 몬스터는 48마리 밖에 없다.

해서 패스워드 버퍼에 메모리 브레이크 포인트를 건 뒤 몬스터를 잡아보면, 특정 메모리 공간에 있는 값으로 복호화 하는 루틴을 찾을 수 있다.

다시 복호화 값으로 사용되는 값중 하나를 골라 하드웨어 브레이크를 건 뒤 프로그램을 재 실행 해보자.

초기화 과정에서 해당 브레이크 포인트에 걸리는 것을 볼 수 있다. 그게 바로 위 사진의 루틴이다.

0x210 바이트 간격으로 데이터를 저장하는데, 이 값들이 몬스터들마다 하나씩 가지고 있는 복호화 키다.

반복문을 분석하면

키값이 0x4 만큼 계속 증가한다는 것을 확인할 수 있으며 이 규칙으로 나머지 값도 알아낼 수 있다.

매우 간단한 예제니 중요한 부분만 집고 넘어가자.

체크 버튼을 눌렀을 때 실행되는 루틴인데 메모리상에 그려진 비트맵과 리소스로 읽어들인 비트맵을 비교하는 루틴이다.

처음엔 이 루틴을 넘어가면 해결이 되는 건가 싶었으나, 루틴을 통과해도 프로그램에는 아무런 변화가 없다.

해서, 해답 키는 리소스 안에 그려져 있을 거라는 생각이 들었다.

처음엔 리소스내용을 프로그램에 띄어볼까 했는데 코드 인젝션까지 하는 건 너무 번거로운 작업이 될 것 같아 리소스 데이터만 추출하기로 했다.

먼저 헥스에디터로 bmp 파일 헤더와 이미지 헤더를 복사해 넣고 리소스 데이터를  뒷부분에 넣어준다. 

방금 그림판이 만들어낸 비트맵 헤더다.

42 4D - BM (비트맵 파일 헤더의 첫 시작 PE 포맷의 PE와 같은 의미다.)

36 B8 0B 00 (헤더까지 합친 파일의 총 크기, 비트맵을 복원할땐 사용되지 않는다.)

00 00 (예약)

00 00 (예약)

36 00 00 00 (실제 이미지 데이터의 시작 오프셋)

28 00 00 00 (이미지 헤더의 크기)

80 02 00 00 ->  Width 값

90 01 00 00 ->  Height 값

01 00 18 00 00 00 00 00 00 B8 0B 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

이 헤더를 그대로 쓰면 이미지를 불러올수 없으니 Width 와 Height 를 수정하자 

80 02 00 00 -> C8 00 00 00 (ImagePrc에서 사용하는 이미지 Width)

90 01 00 00 -> 96 00 00 00 (ImagePrc에서 사용하는 이미지 Height)

헤더 수정이 끝나면 리소스에서 긁어온 이미지 데이터를 헤더 뒤에 붙여넣자.

그럼 정상적으로 bmp 이미지를 불러올 수 있고

그곳엔 키 값이 적혀있다.

드디어 분석 완료 . 

내용이 너무 방대한 관계로 파일로 대체합니다. 

Position.udd

Position.bak

(Position.exe 파일을 바탕화면에 position 폴더를 만들고 그 안에 넣어서 분석하세요 !! udd파일에 파일경로가 저장되어있어서 다른 경로의 position 파일을 열면 새로운 udd파일을 리네임해서 생성해버립니다. 분석에 사용된 OS는 win XP SP3 입니다.)

position.c

(디스어셈 내용 소스로 만든 파일)

똑같은 알고리즘을 그대로 구현한 소스와 position을 분석하면서 comment 를 달아놓은 udd파일 첨부 .

(serial key 알고리즘 부분에 세세하게 coment 다 달아놨습니다. 소스와 함께 보셔야 이해가 되실거에요 .. 코딩도 날코딩이라 알아보기 힘드셔도 양해 바랍니다 ㅠ.ㅠ)

(실제 디스어셈에선 SEH예외처리도 사용되고 갖가지 예외와 문자열 사이즈를 확인하는 등 각종 연산들이 있지만 중요하지 않은 정보라 포함시키지 않았습니다. 사실 저도 문자열 사이즈가지고 무슨 연산을 하는지는 잘 모르겠네요. 그 부분들은 전부 comment 에 Unknown 이라고 표시해뒀습니다.) 

예제 값 

name : zero 

serial : 77777-77778 

올바르지 않은 serial 일경우 각종 비교문에 의해 알고리즘 루틴을 확인하기 힘드니 첫 분석이시라면 이 값을 쓰시길 권장합니다 

혹은 소스를 컴파일해서 name값으로 serial key 를 얻은후 그 값으로 디버깅 해보셔도 됩니다 ! 

이 프로그램의 알고리즘은 소스코드에 나온 그대로이구요 

순서대로

0-4 

>> 비트 연산 

& 1 연산

+5 혹은 ++ 연산이 전부입니다. 

name문자열을 2개씩 2개의 그룹으로 (zero 가 입력되면 ze, ro 를 나눔)  쪼개서 

데이터값들을 추출합니다. 

소스의 nameData1,2 ,3 ,4 버퍼들이

디스어셈을 통해 얻은 알고리즘 그대로 적용시켜 추출한 데이터값입니다. 

이 데이터들을 

0 - 2 

3 - 3 

1 - 4

2 - 0

4 - 1

nameData1,2 와 nameData3,4 를 name처럼 그룹으로 묶어 

위에 적은 index끼리 ADD연산을 합니다. 

그리고 이게 바로 serial key 값이죠. 

첨부한 소스를 컴파일하고 실행해보면 입력된 name 값에 따른 serial key 를 만들어서 출력해줍니다 

전 이제 이 데이터들로 문제가 제시한 

76876-77776 serial 값을 갖는 name을 찾아봐야겠습니다. -_-. 

추출된 5가지의 데이터는 결국 0아니면 1 (and 1 을 하므로) 

거기에 ++냐 +5 의 차이일뿐 즉 데이터는 전부 

1,2 혹은 5,6 이라는 거지요 . 

이 값들을 더해서 나올수 있는 조합은 기껏 해봐야 

6, 7 , 8 세가지 입니다. 

조금만  고민해보면 그 name값을 찾는 알고리즘을 작성할 수 있을것 같은데 

기어코 브루트 포싱을 쓰지 않고 해보려 합니다 - - ^ 

는.. 손실 알고리즘은 도저히 어떻게 못하겠군요 -_-; 그냥 브루트포싱을 써야겠습니다 !! 

그래도 나름대로 추출한 알고리즘을 기반으로 하는 브루트 포싱이니 알고리즘 기반이라는 것에서 위안을 삼아야 겠네요 

마지막 문자는 p라고 readMe에 있었으니 

나머지 3문자를 3중첩 for문으로 소문자 알파벳 3자리를 생성해서 쭉 돌려 만들어진 serial key 와 

문제의 serial key를 비교하면 문제 해 결 ! 

이 프로그램은 우리에게서 숫자를 입력받는다.

허나, 프로그램이 정상적으로 실행되지 않을것이다.

그러니 디버거로 분석을 해보자.

프로그램을 F9 로 실행하면 위 명령에서 익셉션이 발생해 프로그램이 정지한다.

mov ptr [eax] , 90 

eax 레지스터가 가리키는 값에 90을 대입해라. 

이 패치가 오류의 원인이다. 

먼저 오류의 원인인 해당 명령을 NOP 으로 패치해보자 .

이렇게 코드를 바꾸니 일단 실행은 정상적으로 잘 이루어 졌다. 

그리고 나서 나오는 핵심 코드 

NOP으로 넘겨서 돌아온곳은 다름아닌 JMP문이다. 

그것도 가장 중요한 correct 메시지를 출력하는 루틴을 건너뛰어버리는 JMP문! 

이 코드는 대체 왜 있는걸까 ? 

이 코드가 있는 한 어떠한 값을 입력해도 절대로 correct 메시지를 볼 수 없다. 

어거지로 이 JMP문을 NOP으로 채워보면  어떠한 값을 입력해도 correct메시지를 볼 수 있지만, 우리가 원하는 건 이런 메시지를 보는 것이 아니다. 

correct가 실행될 수 있는 입력값을 찾는 것이다. 

다시 여기로 돌아와 코드를 유심히 살펴보자.

eax 는 우리가 입력한 값에 특정 연산이 더해진 값이다. 즉 우리가 입력하는 값에 따라 그 수치가 바뀐다.

그리고, 그곳에 90이라는 데이터를 입력하려고 한다.

바로 이곳이 유요하지 않은 메모리를 가리킬 경우 메모리 참조 오류를 내면서 프로그램이 뻗어버리는 것인데 .

유효한 메모리공간으로 바꾸어 버리면 어떻게 될까?

예를 들어 코드영역내의 어느부분을 가리키도록 말이다.

90은 어셈 NOP명령의 OP코드이다.

즉, eax 가 특정 메모리를 가리키도록 만들면 이 명령에 의해 해당 메모리가 NOP명령어로 패치된다는 얘기다.

이정도면 거의 정답을 다 말한셈이다.

그래도 모르겠다면 프로그램을 몇 번이고 다시 분석해보길 권한다.

답 :

우리가 위에서 확인한 correct 를 건너 뛰어버리는 JMP문 그곳을 eax 가 가리키도록 해서 NOP으로 패치시키면 correct 메세지를 볼 수 있고

그 값이 바로 답이다.

여기까지 왔다면 계산기를 조금 두들겨 답이 무엇인지 알 수 있을것이다.

정말 파일명 그대로 쉬운 언팩 파일. 

분석이랄 것도 없고 그냥 OllyDBG 의 F8만 쭈우우욱 누르다가 OEP에 도달했다. 

딱봐도 언팩된 코드를 다시 푸는 XOR연산들이 연이어 나오는데 

이 루프들을 다 BP로 건너 뛰고 하다보면 금방 OEP에 도달한다. 

무엇보다 F8을 쭉 누르고 있으면 IAT를 복구하는 루틴도 볼 수 있으니 쉽게 이게 언팩 루프라는 걸 알아낼 수 있었다. 

이 부분의 알고리즘과 사용되는 버퍼를 자세히 살펴보면

입력받은 name으로 serial key를 생성하고 있다.

버퍼에 10, 20, 30 값을 입력하고

루프를 돌면서 name 버퍼의 하나하나에 순서대로 xor 연산을 수행한다.

5B 13 49 77 13 5E 7D 13

즉, 이러한 serial key 를 만드는 이름을 찾는건

해당 시리얼을 위 알고리즘처럼 순서대로 10 , 20 , 30

을 다시 XOR연산해서 원래의 값으로 되돌리면 된다.

원래 값으로 되돌리는 데에 사용된 소스 코드

#include <stdio.h>

int main(void)
{
   int i=0;
   int j = 0x10;
   int str_count=0;
   char passwd[100] = {0x5B,0x13, 0x49, 0x77, 0x13, 0x5E, 0x7D, 0x13};


   //scanf("%s", passwd);


   for(i=0; i<100; i++)
   {
      if(passwd[i]==0)
     break;

      str_count++;
   }


   for(i=0; i<str_count; i++)
   {
      if(j == 0x40)
     j = 0x10;
      passwd[i] ^= j;
      j += 0x10;

      printf("%c ", passwd[i]);
   }






   return 0;
}

한줄 한줄 StubCode를 트레이싱해서 넘어가면 

CALL 401000 명령으로 메인 함수를 호출한다.

내부로 들어가면 입력을 받을 수 있는 DialogBox가 뜨고 

이 때부터 이벤트 핸들러에 BP를 걸어서 디버깅을 진행하면 된다. 

처음에 Easy CrackMe를 실행했을 때 작동하는 API를 유추해서 

MessageBox 에 BP를 거는 것도 좋은 방법이다. 

ollydbg 의 name in module 

에서 messagebox를 찾아보면 코드에서 호출하는 MessageBoxA 함수가 보인다. 

엔터를 쳐보면 어느주소에서 호출하는지 나오는데 모두 BP를 걸면 되겠다. 

그리고 아무값이나 입력해보면 해당 이벤트 핸들러에서 정지! 

이제부터 이 이벤트핸들러를 분석하면 password를 찾아낼 수 있다. 

이벤트 핸들러를 보면 GetDlgItemTextA 를 이용해서 어느곳에선가 문자열을 읽어오고 있다.

GetDlgItemTextA가 호출되면 우리가 입력한 값으로 버퍼에 데이터가 채워진다. 

이 CrackMe는 이렇게 우리가 입력한 문자열과 내부 문자열을 비교하는 프로그램 같다.

GetDlgItemTextA API의 바로 밑을 보자 

CMP BYTE PTR SS:[ESP+5],61

명령어가 있다. ESP+5의 값과 61(a)를 비교하고 있는데 

ESP+5는 바로 우리가 입력한 버퍼의 2번째 데이터이다. Index(1) 

즉, 2번째 데이터가 a 인지 검사하고 있다. 만약 여기서 a가 아니라면 Zero Flag 가 0이되고 

그 밑에 오는 JNZ명령에 의해 비밀번호가 틀렸다는 MessageBoxA로 흐름이 넘어가 버린다. 

값을 다시 입력해서 2번째에 a가 오도록 아무값이나 입력하고 이 루틴을 넘어가보자. 

(메모리를 고쳐서 넘어가도 된다.) 

그 다음에 등장하는 5y  문자.

ECX에 우리가 입력한 3번째 값부터 나머지값을 넣고 

5y라는 문자열과 함께 CALL 401150 서브루틴 함수를 호출하고있다. 

이 함수 내부를 따라들어가면 우리가 입력한 버퍼의 3번째값부터 

5y 문자열을 1byte씩 비교한다. 

두번째,

3,4번째 문자를 5y로 변경하라. 

알아낸 정보 

?a5y??????

이제 거의 다왔다. 

R3versing이라는 문자열의 등장. 

언뜻보기엔 이녀석이 패스워드같다. 

하지만 아니다, 조금 더 파헤쳐보자 

가장 중요한 루틴이다. 

우선 EAX에 우리가 입력한 버퍼의 Index(4)의 값을 대입한다. 

즉 ?a5y를 입력했다면 이 부분엔 아직 데이터가 없다. 

?a5y???? 입력했다면 ????4개가 들어가있었을터. 

이 루틴은 반복문인데 1번 반복할때 우리가 입력한 버퍼와 

R3versing 문자열이 들어있는 ESI값을 

1BYTE씩 계속 비교한다. 

이 값 역시 완전히 일치해야한다. 

여기까지 진행하면 우리가 얻은 데이터는 이러하다 

?a5yR3versing 

거의 다왔다. 

이제 앞의 ?값이 무엇인지만 알아내면 된다. 

바로 이 부분! 

ESP+4 와 45를 비교하고있다. 

직접 스택을 확인하면 알겠지만 저건 우리가 입력한 버퍼의 시작주소이다. 

즉 첫번째 바이트의 주소이다. 

그 바이트부분이 45인지 검사하고 있다. 

45는 E

Clear.