Brompton Diary

Using 'Applied Lib' function in IDA 5.2 (step by step)

낙서 — Wed, 23 Sep 2009 02:48:43 GMT

BuddyBuddy(이하 Buddy2) 메신저는 MFC42lu 라이브러리를 이용해 작성된 프로그램이다. 따라서 Buddy2를 손쉽게 리버싱 하기 위해서는 MFC42lu 라이브러리가 필요하다. 왜냐하면 바로 아래 그림 처럼 Import 함수들의 이름을 식별할수 없기 때문이다.

그렇다면 이 식별 불가능한 함수 이름을 어떻게 알아 볼수 있게 바꿀수 있는가? 해답은 바로 IDA 5.2 에 있다. IDA는 Signature를 통해 이미 잘 알려진 라이브러리를 자동 분석 해주는 기능을 가지고 있다 (List of applied library modules). 하지만 이 기능을 적용하기 위해서는 해당 라이브러리 파일이 반드시 필요하다. 위의 경우에는 MFC42lu.lib 파일이 필요 한 것이다.

MFC42lu.lib 파일을 획득 하였다고 가정한다. List of applied library modules 기능을 사용하기 위해서는 우선 이 라이브러리 파일을 통해 내장된 obj 파일을 추출해야 한다.

1. LIB 파일에서 OBJ 파일 추출하기

LIB 파일을 IDA를 통해 열면 다음과 같이 다수의 obj 파일로 구성되어 있음을 확인 할수 있다. 이 obj 확장자 파일들은 LIB 명령어를 통해 추출 가능하다.

LIB 명령어의 EXTRACT 옵션을 이용하면 되며 membername은 바로 위 IDA에서 본 Filename 컬럼의 내용들이 들어가면 된다.
다수의 obj 파일을 일일이 손으로 추출하기 어려우면 배치 프로그램을 이용하면 용이 할 것이다.

2. OBJ 파일에서 Pattern 파일 만들기

1의 과정으로 아래와 같이 OBJ 파일들을 추출 하였습니다.

이제 이 OBJ 파일들을 pcf.exe 파일을 통해 하나의 패턴 파일로 변환해야 합니다.

위 그림은 pcf 사용방법과 옵션에 대한 설명을 보여주고 있습니다.
이 과정 역시 다수의 OBJ 파일에 대해서 작업을 해야 하기 때문에 배치 프로그램을 이용하면 효율적입니다.

3. Pattern 파일로 Signature 파일 만들기

IDA 에서 인식하는 Signature 파일을 만드는 과정입니다.
사용되는 유틸리티는 sigmake 입니다.

위 그림은 sigmake를 어떻게 사용하는지에 대해서 보여주고 있습니다.

4. IDA에 적용하기

Re-building the MFC(4.2) with MSLU (부제: mfc42lu.lib 만들기)

낙서 — Tue, 22 Sep 2009 06:52:34 GMT

[재 료]
설치된 Visual Studio 6.0 파일들 (Visual C++ 포함된)

[과 정]

1. Back up
VC98\MFC\LIB 와 VC98\MFC\SRC 를 백업 합니다.
(나중에 원래대로 복구하기 위해서 필요하겠죠)

막 간
MFC42U.DLL (Unicode Release)
MFC42UD.DLL (Unicode Debug)
MFCN42UD.DLL (Unicode Debug - Network classes)
MFCO42UD.DLL (Unicode Debug - OLE classes)
MFCD42UD.DLL (Unicode Debug - Database classes)

유니코드 버젼의 MFC(excluded MSLU)는 위 5가지 DLL로 구성되어 있습니다.
릴리즈 모드를 위한 DLL은 한개인 반면 디버그 모드를 위한 DLL이 4개 인 이유는 디버깅 시 로딩 속도를 빠르게 하기 위해서라는군요.

2. Makefile 수정
VC98\MFC\SRC 에 위치한 아래 4가지 MAK 파일을 수정 해야 합니다.
(수정 이유는 리빌딩 될 DLL에 Unicows.lib가 포함되게 하기 위함입니다)
MFCDLL.MAK
MFCNET.MAK
MFCOLE.MAK
MFCDB.MAK

각 파일 안에

link @<<

이런 명령문이 존재 합니다. 이 명령문 뒤에 다음과 같은 라이브러리들을 삽입해야 합니다.

/nod:kernel32.lib /nod:advapi32.lib /nod:user32.lib /nod:gdi32.lib /nod:shell32.lib /nod:comdlg32.lib /nod:version.lib /nod:mpr.lib /nod:rasapi32.lib /nod:winmm.lib /nod:winspool.lib /nod:vfw32.lib /nod:secur32.lib /nod:oleacc.lib /nod:oledlg.lib /nod:sensapi.lib unicows.lib kernel32.lib advapi32.lib user32.lib gdi32.lib shell32.lib comdlg32.lib version.lib mpr.lib rasapi32.lib winmm.lib winspool.lib vfw32.lib oleacc.lib oledlg.lib

3. DLL 이름 결정 및 변경
Re-build를 통해 생성될 새로운 DLL의 이름을 결정 한 후 소스코드를 변경 해주는 과정입니다.
새로운 이름은 아래와 같이 설정 했습니다.

MFC42LU.DLL
MFC42LUD.DLL
MFCN42LUD.DLL
MFCO42LUD.DLL
MFCD42LUD.DLL

변경 해줘야 하는 소스코드는 다음과 같습니다.

DLLDB.CPP 소스코드 안에서 38,39 번째 줄과 46,47번째 줄의 내용을 아래와 같이 수정 합니다.
#define MFC42_DLL "MFC42LUD.DLL"
#define MFCO42_DLL "MFCO42LUD.DLL"
#define MFC42_DLL "MFC42LU.DLL"
#define MFCO42_DLL "MFCO42LU.DLL"

DLLNET.CPP 소스코드 안에서 37번째 줄과 43번째 줄의 내용을 아래와 같이 수정 합니다.
#define MFC42_DLL "MFC42LUD.DLL"
#define MFC42_DLL "MFC42LU.DLL"

DLLOLE.CPP 소스코드 안에서 38번째 줄과 44번째 줄의 내용을 아래와 같이 수정 합니다.
#define MFC42_DLL "MFC42LUD.DLL"
#define MFC42_DLL "MFC42LU.DLL"

DLLINIT.CPP 소스코드 안에서 371번째 줄과 373번째 줄의 내용을 아래와 같이 수정 합니다.
#define MSVCRT_DLL "MSLURTD.DLL"
#define MSVCRT_DLL "MSLURT.DLL"

추가적으로 DLLINIT.CPP 소스코드 안에서 아래 사항을 수정해 주셔야 합니다.
DLLINIT.CPP 소스코드 안에서 391번째 줄을 아래와 같이 수정 합니다.
#ifdef _UNICODE
를
#if 0
로 변경 하시면 됩니다.

4. DEF 파일이름 수정하기
VC98\MFC\SRC\INTEL 경로 안에 있는 아래 파일들의 이름을 다음과 같이 수정 합니다.

MFC42U.DEF --> MFC42LU.DEF
MFC42UD.DEF --> MFC42LUD.DEF
MFCN42UD.DEF --> MFCN42LUD.DEF
MFCO42UD.DEF --> MFCO42LUD.DEF
MFCD42UD.DEF --> MFCD42LUD.DEF

위에 언급 된 DEF 파일들을 열어 LIBRARY 항목 다음에 있는 문자를 DEF 파일 이름과 동일하게 수정해야 합니다.
예를 들어 MFC42LU.DEF 파일 안에 LIBRARY 항목은 다음과 같습니다.

LIBRARY MFC42u

이를 다음과 같이 수정해 주셔야 합니다.

LIBRARY MFC42lu

5. 배치파일 만들기
리빌딩 준비가 완료 되었습니다. 리빌딩을 위한 배치 파일을 만들어보도록 하죠.
MFC\SRC 경로 밑에 buildmfc.bat 파일을 생성 합니다. 그리고 아래와 같은 내용을 입력해 주세요.

nmake -f mfcdll.mak libname=MFC42L DEBUG=0 UNICODE=1 /a
nmake -f mfcdll.mak libname=MFC42L DEBUG=1 UNICODE=1 /a
nmake -f mfcdb.mak libname=MFCD42L DEBUG=1 UNICODE=1 /a
nmake -f mfcnet.mak libname=MFCN42L DEBUG=1 UNICODE=1 /a
nmake -f mfcole.mak libname=MFCO42L DEBUG=1 UNICODE=1 /a

6. 배치파일 실행 후
새롭게 생성된 DLL 파일은 VC98\MFC\SRC 에 저장됩니다.
새롭게 생성된 LIB 파일은 MFC\LIB 에 저장됩니다.

MFC\LIB 에서 mfc42lu.lib 파일을 만나실 수 있습니다.

7.Trouble Shooting
MS Visual Studio 6.0에는 unicows.lib 파일이 기본적으로 내장되어 있지 않습니다. 따라서 이 파일을 따로 확보하지 못하면 mfc42lu.lib & mfc42lu.dll 파일을 컴파일 하는 과정에서 링킹 오류가 발생합니다. unicows.lib 파일을 확보한 후 VC98\MFC\LIB 에 저장 하십시요. 그리고 배치 파일을 실행 하면 정상적으로 mfc42lu.lib 파일이 생성되는 것을 확인 할 수 있습니다.

[Reversing] Mi3 Messenger: Memo Data (KeyGen Algorithm) - Extension

낙서 — Wed, 02 Sep 2009 10:14:27 GMT

Target: Mi3 Messenger Version 5
Reversing Tool: OllyDbg 2.0

Motivation
Mi3 메신저는 저장된 쪽지 내역을 복호화 하는데 내부적으로 생성한 KEY를 사용한다. 이 KEY를 생성하는 함수의 위치는 Mi3 Messenger: Memo Data (KeyGen Algorithm) 게시물에서 확인 할 수 있다. 만약 이 KEY 생성 알고리즘을 분석 해봤다면 상위 함수로부터 입력 된 KEY 생성 인자(편의상 SEED라 부르겠다)가 존재함을 알 수 있을 것이다. 이 SEED는 얼핏 보면 메신저 ID와 간단한 HEX 값으로 구성된 단순한 0x40 바이트 크기의 데이터이지만(아래그림 참조), 메신저 ID를 빼고는 어떻게 변화될지 예측 할 수 없는 상태이기도 하다. (0x00 값들에 어떤 값이 삽입될지 0x30 값이 어떻게 변할지 우리는 알 수가 없다)

따라서 이 0x40 바이트의 데이터를 생성하는 함수를 찾아 보도록 하겠다.

Reversing Process
먼저 KEY 생성 알고리즘 함수를 보자.

첫 번째 CALL은 상위 함수로 부터 입력 받은 SEED를 로컬변수에 전달하는 기능을 담당하고 있다.

<0x526118 함수>
파란색으로 반전되어 있는 부분이 SEED를 4바이트씩 로컬변수에 복사하는 부분이 되겠다. 이 함수를 보면 SEED가 들어있는 버퍼의 주소 값이 EDX에 있다는 사실을 알 수 있다. 그리고 EDX는 상위 함수(시작주소:52616C)로 부터 전달 된 인자 값이다. 첫 번째 그림으로 돌아가서 EDX를 찾아보면, 해당 주소 값은 결국 (시작주소:52616C)의 상위 함수로 부터 전달 된 인자 값임을 확인 할 수 있다.

아래 그림은 (시작주소:52616C)의 상위 함수이다.

0x52691F에서 호출 하는 함수가 KEY 생성 알고리즘 함수(시작주소:52616C)이다. 그리고 바로 위에 ESI+18 값을 EDX에 삽입하는 명령문이 존재하고 있다. 역시나 [ESI+18]에는 예의 SEED가 존재하고 있었다. 게다가 ESI+18 주소 값의 데이터는 함수 (시작주소:526158)에 의해 완전히 완성되는 것을 확인 할 수 있었다.(SEED의 마지막 8바이트를 이 함수가 생성하고 있었다)

<0x526158 함수>

상위로부터 전달 된 2개의 주소 EAX와 EDX를 교환하고 있다. 그리고 (시작주소:403254) 함수를 호출 하고 있다.
아래 그림은 (시작주소:403254) 함수가 포함하고 있는 다수의 Switch 구절 중 하나이다.

EAX 주소에 존재하는 값을 EDX 주소에 복사하는 명령문들이다.
여기서 EAX가 가리키는 값은 SEED의 마지막 8바이트 데이터이고 EDX 주소는 SEED의 버퍼 주소이다(정확히는 SEED 버퍼의 Offset 0x38). 결과적으로 SEED의 마지막 8바이트는 이곳에서 생성된 것은 아닌 것이다.

(시작주소:403254) 함수의 EAX 주소 값은 (시작주소:526158) 함수의 EDX 주소 값을 전달 받은 것이다. 그리고 함수 (시작주소:5268D4)의 EBP 값으로 이어진다. 계속해서 이 EBP는 (시작주소:5268D4)의 상위 함수로 부터 전달 받은 EDX의 인자 값을 건내 받고 있다.

아래 그림은 (시작주소:5268D4) 함수의 상위 함수(시작주소:526958)이다.

EDX는 스택주소 ESP로부터 이어져 왔다는 것을 한 눈에 알 수 있다. ESP의 값은 (시작주소:5260D0) 함수에 의해 생성되어진다.

아래 그림은 (시작주소:5260D0) 함수 이다.

보시다시피 이 함수 역시 이미 만들어진 데이터를 복사해주는 역활만 하고 있다. EDX가 가리키는 버퍼에 우리가 원하는 8바이트 데이터가 존재하고 있으며, 이 EDX는 상위함수(시작주소:5268D4)에서 입력된 값이다.
(시작주소:5268D4) 함수를 살펴보면 EDX에 EBX+10의 주소를 로드하는 부분이 있는 것을 확인 할수 있다. 또한 이 EBX는 (시작주소:5268D4)의 상위 함수로 부터 전달 된 인자 값과 동일하다는 것도 알수 있다(EDX).

아래 그림은 0x5268D4의 상위 함수 0x526A6C이다

EDX 주소값은 현재 함수의 스택 주소를 이어받고 있다. 이 스택 주소의 값을 함수 호출 때마다 살펴보면 0x5268D4를 호출 할 때 아래와 같은 값이 생성되는 것을 확인 할 수 있다(실제 상위 16바이트는 0x5268A4에서 생성되고 하위16바이트는 0x5268D4에서 생성된다).

재미있게도 함수 0x5268D4는 우리가 이미 지나쳐온 함수이다.

0x5268D4 함수의 출력 값은 스택 주소가 가리키는 버퍼에 입력될 것을 우리는 알고있다. 그리고 그 스택주소는 EAX로 이어져 본 함수로 입력되었다. 본 함수 내에서는 EAX는 ESI로 이전되고 [ESI+10] 이라는 버퍼내 주소 지정을 통해 값을 ADD 하는 곳이 보인다.

[Reversing] CryptoAPI: CryptDeriveKey() Function

낙서 — Mon, 10 Aug 2009 09:29:15 GMT

Target: CryptoAPI Library (AdvApi32.dll, rsaenh.dll, dssenh.dll)
Tool: OllyDbg 2.0

Motivation
CryptoAPI는 Windows에서 제공하는 암호라이브러리 이다. 이 라이브러리는 사실 표준 암호라이브러리(예를들어 OpenSSL)와 구현상의 차이점을 가지고 있는데 특히 CryptDeriveKey() 함수가 표준과 다르다. RC4 Key 준비과정이나 AES 키 생성과정이 그렇다. 어디가 어떻게 다른지를 역공학을 통해 알아보자.

Reversing Process
CryptDeriveKey() 함수를 Reversing 하는데 가장 효과적인 방법은 이 함수를 사용하는 프로그램을 만든 후 그 프로그램을 역공학 하는 것이다. 만약 프로그램을 작성했다면 가능한 Debug 모드로 컴파일을 수행 한 후 실행 파일을 동적 분석 하도록 한다.
이 프로그램을 OllyDbg로 불러들인 후 사용되는 Intermodular Call을 확인하면 아래 그림과 같이 CryptDeriveKey() 함수를 발견 할 수 있다. 브레이크를 걸자.

이제 프로그램을 실행 시키면 CryptDeriveKey() 함수를 호출 하는 순간 멈출 것이다. 아래 그림 같이~

위 그림은 자신이 작성한 프로그램에 따라 다를 것이다. 어쨓든 이제 Step Into를 수행하면 CryptDeriveKey() 함수로 진입 하는 것이다. 아래 그림은 CryptDeriveKey() 함수 시작 부분이다.

여기서 포인트!
CryptDeriveKey()는 MS에서 각각의 인자 값들이 이러이러하고 리턴 값은 이것이다 라고 공개하고 있는 함수이다. 우리는 이런 함수를 Documented 함수라고 부르는데 사실 CryptDeriveKey() 함수는 껍데기 일 뿐이고 실제 각종 암호 알고리즘의 키를 생성하는 함수는 CPDeriveKey() 함수이다. 이 함수는 AdvApi32.dll이 아닌 rsaenh.dll, dssenh.dll에 존재한다. 그리고 이 CPDeriveKey() 함수는 CryptDeriveKey() 함수에서 포인터 함수로서 참조되어 사용되어진다. (대부분의 Windows API는 이런 방식으로 설계 되어 있다)
자 그렇다면 CryptDeriveKey()에서 CPDeriveKey()를 호출하는 곳은 어디일까?
1. 함수 호출 방법을 포인터 함수 참조 방식을 사용하는 곳
2. 호출 전 인자 수가 CryptDeriveKey()와 동일한 곳
일 것이다. 그리고 바로 그곳이 위 그림의 붉은 곳이다.
아래 그림은 CryptDeriveKey() 함수를 보여주고 있다.

Windows API들은 대부분 비슷한 모습으로 시작된다.
초반부에 로컬 변수들의 초기 값을 설정해주는 모습, 인자 값의 Validation 체크 하는 모습을 볼 수 있다.(참고로 오른쪽에 함수이름은 본인이 써 넣은 것으로 OllyDbg에서 기본적으로 지원해주는 않는다)

CPDeriveKey() 함수의 인자 값 중 키 길이를 나타내는 인자의 Validation을 체크 하는 과정이 보인다.

CPGetHashParam() 함수가 보일 것이다. 이 함수는 CryptGetHashParam()의 실제 구현 함수이다. 이 부분 때문에 CryptDeriveKey() 함수의 인자 값으로 CryptHashData()의 출력 값을 바로 사용 할 수 있는 것이다.

위 그림의 파란 부분과 위의 위 그림에 하단 부분을 보면 점프가 연속적으로 이어져 있다. 다양한 분기문이 이어진다는 뜻인데... CPDeriveKey() 함수의 인자 값 중 어떤 암호 알고리즘의 키를 생성 할 것인지에 대한 인자 값이 있다. 그리고 바로 이 값에 의해 분기문이 선택되어지고 있는 것이다. 파란색 아래 코드들은 원래 3중 DES를 위한 것인데 업데이트에 의해 AES도 이 부분의 코드를 사용한다.
내용은 대충 아래와 같다.
3중 DES는 입력된 SEED(키를 생성하기 위해 이용되는 값)를 가지고 64바이트 키 2개를 만들어야 한다!
CPCreateHash() 열고, 입력된 SEED를 0x36 값으로 각각 XOR, CPHashData() 수행
CPCreateHash() 열고, 입력된 SEED를 0x5C 값으로 각각 XOR, CPHashData() 수행
이렇게 생성된 해쉬 결과를 3중 DES 키로 사용한다는 시나리오다.
(암호학 공부하신 분들은 대충 감이 올것이다... 그렇다 HMAC이다)

잘 안보이시겠지만 위 내용은 MSDN에서 찾아 볼수 있는 내용이며 바로 위에 간략하게 써놓은 예기들을 서술하고 있다. 여담이지만 본인이 이 함수를 Reversing 하게 된 이유는 바로 위 항목에서 '3DES or AES' 라고 되어 있는 부분이 오직 3DES 라고만 되어 있었기 때문이다. 언제 업데이트를 했는지 아오T-T
각설하고 위에 내용은 3DES로는 완벽하지만 AES로는 미흡한 서술이다.
AES의 경우에는 키를 생성하기 위해 입력된 SEED가 20바이트이고 이 값이 각각 0x36(64바이트 만큼)과 0x5C(64바이트 만큼)로 XOR되서 새로운 64바이트 값이 2개 생성되는데...문제는 0x5C와 XOR해서 생성된 값은 전혀 사용되지 않는 다는 점이다.

자.... 코드를 좀 뛰어 넘었다 어짜피 해쉬 Final 부분 코드이다.
위 그림은 그렇게 해서 완성된 새로운 SEED를 본 함수의 출력 구조체에 복사하는 부분이다. 함수 이름은 마치 키를 생성 할 것 같지만 RC4나 AES 등의 키 생성 함수는 이곳에서 호출되지 않는다. CryptDeriveKey() 함수는 오직 SEED를 새롭게 생성 하거나 아니면 가만히 냅두는 역활 만 하고 실제로 CryptDecrypt() 함수에서 키를 생성한다.
자 함수의 마지막 부분이다.

MakeKeyRSABaseCompatible() 함수는 내부적으로 CPSetKeyParam() 함수를 재호출 하고 이 함수는 대부분의 암호 알고리즘들의(3DES&AES 빼고) SEED를 재구성하거나 출력 구조체로 그냥 복사해주는 역활을 하고 있다.
RC4의 SEED도 이 함수 내에서 재구성되는데 이부분이 궁굼하신 분은 직접 분석 해보길 바란다.

[Reversing] Mi3 Messenger: Storaged Password

낙서 — Tue, 04 Aug 2009 12:18:09 GMT

Target: Mi3 Messenger (Version 5)
Tool: OllyDbg 2.0

Motivation
Mi3 메신저는 사용자 편의성을 위해 '자동 로그인' 옵션을 제공한다. 자동 로그인이 가능하다는 뜻은 계정과 패스워드(혹은 그와 비슷한 역활을 하는 어떤 것)를 로컬 컴퓨터 어딘가에 저장하고 있다는 의미이다. 만약 정말로 패스워드를 저장하고 있다면 이는 보안상 큰 취약점을 가지고 있는 것이다. 이 패스워드를 직관적으로 보기 힘들게 암호화 하고 있어도 마찬가지이다.
Mi3 메신저는 이런 보안상 큰 취약점을 가지고 있다는 사실이 판명되었다. 역공학을 통해 패스워드를 획득하는 방법을 알아보자.

Reversing Process
Mi3 메신저는 '자동 로그인' 옵션을 사용 할 경우 계정과 패스워드를 파일에 기록하도록 프로그램되어 있다. 물론 패스워드를 그대로 저장하지는 않는다. 하지만 암호화 된 패스워드를 보면 그 과정은 그다지 복잡하지 않을 것이라 예상된다.

'자동 로그인' 옵션을 체크한 상태에서 사용자가 로그인을 시도하면 Mi3 메신저는 해당 파일에 위와 같은 값을 써넣을 것이다. 바로 이부분에 브레이크 포인트를 설정하고 분석을 시작한다.

아래는 로그인을 시도 한 후 세 번째로 브레이크 포인트에 잡히는 코드 부분이다.
(첫 번재와 2번째도 같은 위치에 브레이크 포인트가 걸렸지만 원하는 값이 없었다)

파란색 줄의 Buffer 부분에 우리가 원하는 암호화 된 패스워드 값이 들어 있음을 Memory Map을 통해 확인 할 수 있을 것이다. 그리고 이 값은 본 함수(시작주소:40B50C)를 호출 할 때 넘어온 인자 값 중 하나이다. 따라사 상위 함수를 살펴 보도록 한다.

별 것 없다 계속 해서 상위 함수로 올라가 보자.

역시 WriteFile의 Buffer 인자 값을 전달하는 함수 일 뿐이다. 계속 올라간다.

올라가자 올라가자

코드를 계속해서 분석 한다면 아직도 암호화 된 패스워드 값이 더 상위 함수에 만들어짐을 알 수 있을 것이다 계속 올라가자

후 아직도 더 올라가야 겠네...

여기서도 암호화 된 패스워드를 생성하진 않는다. 올라간다.

함수가 길어서 그림이 짤렸다(위). 이 함수의 시작 주소는 본인의 경우 7006F8 이였다. 지금까지 우리가 타고 올라온 함수의 근원은 빨간 부분의 CALL 0x004048C0이였다. 이 함수 위단에서는 암호화 된 패스워드를 발견 할 수 없었으므로 분명 이 함수에서 그리고 빨간 부분 위에서 암호화 된 패스워드가 생성될 것이다.
CALL 중심으로 값을 확인 해본 결과 파란 줄이 그어져 있는 CALL 0x0049BD68이 암호화된 패스워드를 생성하는 것을 확인 했다.

Reversing 과정은 여기까지... 암호화 된 패스워드를 어떻게 만들어내는 지는 함수 (시작주소:49BD68)을 분석하면 쉽게 알 수 있을 것이다.

[Reversing] Yahoo! Messenger: Conversation Data

낙서 — Wed, 29 Jul 2009 08:46:52 GMT

Target: Yahoo! Messenger (Version 8.1.0.239)
Tool: OllyDbg 2.0

Motivation
Yahoo! Messenger를 통해 대화한 내용은 로컬 컴퓨터에 파일(저장된 대화 내역)로 저장된다. 그리고 그 내용은 암호화 되어 있기 때문에 타인이 그 내용을 확인 할 수는 없다. 하지만 역공학을 통해 Yahoo! 메신저의 복호화 알고리즘 및 KEY 생성 알고리즘(혹은 KEY)을 밝혀낸다면 그 내용을 열람 할 수 있을 것이다.

Reversing Process
대화 내용이 저장된 파일을 읽어오는 순간에 프로그램을 멈추고 싶다. 따라서 Yahoo! 실행파일에서 ReadFile API가 사용되는 모든 구간을 브레이킹 포인트로 지정하자.

그리고 프로그램을 수행시키며 ReadFile 함수가 버퍼로 읽어오는 데이터를 살펴보자. 분명 저장된 대화내용과 동일한 HEX 값을 불러들이는 순간이 있을 것이다. 아래 그림이 바로 그 순간이다.

여기부터 프로그램의 흐름을 하나씩 따라가다보면 파일로부터 읽어들인 데이터를 처리 하는 부분을 찾을 수 있게 된다.
아래그림 부분이다.

Arg3에 자신의 로그인 계정이 들어가고 Arg2에는 복호화 시킬 데이터의 크기 그리고 Arg1에는 복호화 시킬 데이터가 담긴 버퍼를 넘겨주고 있다. 즉, 함수 4D4BE5는 복호화 알고리즘이 담긴 함수 이거나 그 함수까지 가는 경로 일 것이라는 추측이 가능하다.
아래는 함수 4D4BE5의 모습이다.

이 함수 중간에 루프가 하나 존재하고 그 루프 안에 XOR 연산자가 하나 보인다. 바로 이부분이 복호화를 수행하는 Statement이다.

Yahoo! Messneger는 자신의 로그인 계정을 KEY로 사용하며, 암호화 된 데이터와 단순히 XOR을 통해 복호화를 수행한다는 사실을 확인 할 수 있었다.

[Reversing] Mi3 Messenger: Memo Data (KeyGen Algorithm)

낙서 — Tue, 28 Jul 2009 16:47:57 GMT

Target: Mi3 Messenger Version 5
Reversing Tool: OllyDbg 2.0

Motivation

Mi3 메신저는 쪽지(Memo)를 보내거나 받을 때마다 그 내용을 로컬 컴퓨터에 저장하도록 되어있다. 물론 쪽지내용은 평문이 아닌 암호문으로 저장되어 있기 때문에 단순히 파일을 열람하는 방법으로는 데이터 획득이 어렵다. 하지만 암호문을 생성하는 알고리즘과 KEY를 획득할 수 있다면 메신저에 로그인하지 않고도 데이터 해독이 가능해진다.

Reversing Process
Mi3 메신저의 저장된 쪽지내용(암호문)을 복호화 하기 위해서는 암호화할 때 사용된 KEY가 필수적으로 필요하다. MissleeMessenger.exe를 리버싱하여 KEY를 생성하는 알고리즘을 분석한다.

분석을 시작해야 할 지점은 디버깅 중 KEY를 발견 한 순간 부터이다. 이 KEY는 복호화 과정에서 반드시 쓰이므로 복호화 알고리즘 함수 안에서 KEY를 발견 할 수 있을 것이다. 아래 그림은 복호화 알고리즘을 포함하고 있는 함수(시작주소:704044)이고 [EBX+10] 값이 KEY 임을 확인 할 수 있다.

EBX+10은 다음과 같은 주소를 가리키고 있다(0x018BF748).

생성된 KEY가 고정적으로 이 메모리 주소에 저장될지 아닐지는 메모리 할당 방법에 따라 다르겠지만 일단 고정적일 것이라는 낙관적(?) 인 생각을 가지고 하드웨어 브레이크 포인트를 잡아보자.(아니면 다른 수를 쓰면 된다)
그리고 새롭게 Mi3 메신저를 실행 시킨 후 브레이크가 걸릴때 마다 0x018BF748 메모리 번지를 자세히 들여다 보자. 어느 순간 아래 그림과 같은 HEX 값을 갖는 순간을 포착 할 수 있을 것이다.

0x39와 0x36 값이 쓰여지는 순간이다.
브레이킹 된 순간의 코드 부분은 아래와 같았다.

이제 이 코드를 근간으로 KeyGen 함수를 찾아 갈 수 있게 되었다.
함수를 거슬러 올라가 보자.

KEY 값을 메모리에 쓰는 함수의 최상위 부모 함수가 바로 위의 그림이다(파란색 부분이 루프이다).
그리고 KEY 값은 EBX에서 가져오는 것을 알 수 있다. EBX는 현재 함수의 첫 번째 로컬변수(EBP-4)의 값을 계승하고 있고 이 로컬변수는 함수의 인자 값(EAX)으로부터 포인터를 이어 받고 있다.
즉, 위 함수를 호출 하는 상위 함수를 들여다 볼 필요가 있게되었다.

호출 직전 상위 함수(위) 살펴보면 LEA EAX, [LOCAL.10] 부분이 KEY 값이 담긴 메모리주소를 셋팅 하는 부분임을 바로 알 수 있다. 또한 이 주소는 바로 해당 Statement의 바로 위 함수 526A44 와 매우 관련 있을 것 같은 느낌이 들어보인다(직감이다).

먼저 LEA EAX, [LOCAL.10] 의 값을 확인하자. 그 값은 운 좋게도 Stack 주소 0x0012F974를 셋팅 하고 있다. 운이 좋다는 것은 Stack 주소 라는 점이다. Stack 주소는 프로그램을 반복 실행 시켜도 위치가 변동되지 않기 때문이다. 즉 프로그램을 실행 시키면서 0x0012F974의 값이 변동되는 것을 확인하면 어디서 KEY 값이 복사가 되는지 쉽게 찾을 수 있다.

결론부터 예기하자면, KEY 값은 함수 (시작주소:526A44) 안에서 해당 Stack 주소에 복사 되고 있었다. 이 함수를 타고 내려가다 보면 이미 생성된 KEY 값을 단순히 복사하는 코드를 만나거나 혹은 KEY 생성 함수에 다다를 수 있을 것이다.

526A44 함수는 다음과 같다

2개의 내부 함수 중에 두번째 함수가 KEY 값을 복사(or생성) 한다는 사실을 Stack 주소를 통해 확인했다.

(시작주소:526A6C) 함수는 다음과 같다

3개의 내부 함수 중에 세번째 함수가 KEY 값을 복사(or생성) 한다는 사실을 Stack 주소를 통해 확인했다.

(시작주소:526958) 함수는 다음과 같다

KEY 생성 함수의 시작 부분임을 직감적으로 알 수 있는가? 평소에는 보기 힘든 산술연산자들이 반복되는 형태, 그리고 여기까지 타고 들어오면서 반복적으로 보였던 자신의 ID 등, 이 함수가 KEY 생성 함수일 가능성이 높음을 시사해주고 있다.

(시작주소:5268D4) 함수는 아래와 같고 이 함수 안에 존재하는 (시작주소: 52616C) 함수가 KEY 생성 함수이다.

나머지는 어셈블리를 따라가며 KEY 생성 알고리즘을 획득하는 과정만 남는다.

[Reversing] Mi3 Messenger: Memo Data (Decrypting Algorithm)

낙서 — Tue, 28 Jul 2009 13:47:41 GMT

Target: Mi3 Messenger Version 5
Reversing Tool: OllyDbg 2.0

Motivation
Mi3 메신저는 쪽지(Memo)를 보내거나 받을 때마다 그 내용을 로컬 컴퓨터에 저장하도록 되어있다. 물론 쪽지내용은 평문이 아닌 암호문으로 저장되어 있기 때문에 단순히 파일을 열람하는 방법으로는 데이터 획득이 어렵다. 하지만 암호문을 생성하는 알고리즘과 KEY를 획득할 수 있다면 메신저에 로그인하지 않고도 데이터 해독이 가능해진다.

Reversing Process
Mi3 메신저의 저장된 쪽지내용(암호문)을 복호화 하는 알고리즘에 대해서 분석한다.
Mi3 메신저는 사용자가 쪽지내역을 열람하는 메뉴를 선택하면 다음과 같은 과정을 거친다.

쪽지내역이 저장된 파일을 읽어온다.
암호화 된 데이터를 복호화 한다.
복호화 된 쪽지내용을 사용자에게 보여준다.

1번 과정에서 브레이크를 걸기 위해서 ReadFile API를 사용하는 모든 구간에 브레이크를 설정한다.(ReadFile 함수 시작점에 브레이크를 거는 방법도 유효)

메시지함을 열람하면 아래와 같은 브레이크 포인트 지점에서 프로그램이 일시정지 된다. 이 지점이 쪽지 내용이 저장된 파일을 읽어들이는 부분이다.

소스코드를 차례차례 실행 시키며 데이터의 변화를 지켜보자

최종적으로 바로 아래의 함수까지 거슬러 올라가보자.

이 함수(시작주소:702BAC)가 바로 쪽지 내용 복호화 과정을 담고있는 함수이다. 즉, 파일을 열어 안에 있는 내용을 읽어들이고 그 데이터를 복호화 하는 과정을 담고 있다는 뜻이다.

아래의 루프 구간은 데이터를 읽은 후 Parsing하는 과정을 반복하고 있다.
(우리는 CALL MissleeM.403C68 이 저장된 쪽지 내용을 읽어들이는 함수임을 이미 알고 있다)

그렇다면 파일로부터 읽어온 쪽지 내용은 어디에서 복호화 하고 있을까? 그것은 바로 아래 함수(시작주소:704044)에서 수행된다.
(이 함수를 호출하면 데이터가 복호화 되는 것을 확인 할 수 있기 때문이다.)

이 함수(시작주소:704044)는 아래와 같은 구조를 가지고 있다.

함수 (시작주소:703ED4)는 복호화 알고리즘을 담고 있다.
이 함수의 인자는 KEY와 Encrypted Data 등이다.(Encrypted Data = 저장된 쪽지 내용)

위 그림은 (시작주소:703ED4) 함수에서 실질적으로 데이터가 복호화가 되는 코드 부분을 보여주고 있다.
XOR DL, CL
와
XOR DL, [ECX+EDI]
가 그것이다.
첫번째 명령어는 KEY 값과 Encrypted Data를 XOR하는 연산이며,
두번째 명령어는 첫번재 명령어의 결과와 [ECX+EDI] 값의 XOR 연산이다.
여기서 ECX는 프로그래머가 하드코딩 해놓은 256바이트 크기의 배열 주소이다.
아래 그림은 256바이트 크기의 고정 배열 값을 보여주고 있다.

그리고 EDI 값은 Encrypted Data의 첫번재 바이트 값이다. 따라서 [ECX+EDI]는 256바이트 배열에서 EDI 번째 1바이트 값을 의미한다. EDI는 복호화가 1바이트 씩 진행 될 때마다 그 크기는 1씩 증가한다는 사실도 잊지말자. TABLE의 데이터를 전체적으로 이용하기 위해서이다.(0xFF 까지 증가하면 다시 0x00부터 1씩 증가한다)

여기까지 리버싱을 수행했다면 Mi3 메신저의 저장된 쪽지내용(암호문)에 대한 복호화 알고리즘은 모두 파악한 것이다. 하지만 복호화 과정에서 사용되는 KEY 값은 어떻게 생성되는지 아직 알 수 없다.
KEY 생성 알고리즘은 다음에 알아보도록 한다.

오페라 카르멘

낙서 — Sun, 01 Jul 2007 12:03:45 GMT

오페라 카르멘을 보았습니다.
저희 누님께서 공연관계 일을 하시는 고로 종종 공짜로 이런 구경을 할 수 있답니다.
점때는 King and I 라는 태국을 배경으로 영국 가정교사와 왕의 뮤지컬을 보았었지요.

이번에는 저로써도 처음 접하는 오페라... 현대적 의상으로 구성된 개정판 카르멘 이긴 했지만
역시 음악이 참 좋더군요.(딱 하나만 ㅎㅎ) 4막에서 그 음을 가장 화려하게 들을 수 있는 카르멘
대표곡 투우사의 노래! 솔직히 이 노래가 나올때 빼고는 졸렸답니다 ㅋ...

위에 보시는 장면은 절규하는 호세와 그에게 죽임 당한 카르멘입니다.
(카르멘은 남자 한번 사귀면 6개월을 버티기 힘들어하는 여걸이십니다)

공연 중에 사진을 찍는 것은 에티켓이 아니죠 ㅎㅎ 이건 누님 통해서 얻은 사진으로 제가 본 공연과는
약간 다르 답니다. 예를 들면 저 다리에 앉아 손을 흔들고 있는 아이들이 한국 아이들 이였다는 점
이랄까요?

다음에는 차입콥스키의 걸작 오페라 스페이드의 여왕을 한다는데 꼭 또 봤으면 합니다~

Pearls Before Breakfast (아침식사 전의 진주들)

낙서 — Mon, 09 Apr 2007 07:35:29 GMT

세계적 바이올리니스트 개런티 1분에 1달러도 안되다니?

오늘 우연히 네이버에 들렸다가 메인화면에서 조슈아 벨 사진이 있는 기사를 보았다. 팬은 아니지만 얼굴이 후끈 달아오를 정도로 그의 연주를 들은 경험이 있는 나로선 흥미가 동하지 않을 수 없었다 게다가 기사 제목도 제목이고...

네이버 기사 링크

기사를 다 보고나서 웃음이 나왔다. 이유인 즉 내가 조슈아 벨의 연주를 들은 곳이 다름 아닌 보스턴 심포니 오케스트라 였기 때문이다. 매주 목요일, 보스턴 심포니가 러쉬 티켓을 파는 날이다. 전 세계적으로 유명한 오케스트라의 음을 놓칠수가 없었고, 또한 돈도 없었기 때문에 예정에 없는 일박을 더하고 말았다.
(이에 관련된 재밌는 에피소드가 있는데 이건 보스턴 편에 포스팅 하겠다^^)

그리고 그 의 음을 만날 수가 있었다. 아름답고 화사하고 정렬적이고 역동적이고...
분명 한 악기에서 음을 내고 있는데 눈을 감고 들으면 여러 사람이 동시에 연주를 하는 듯한 음의 솔로...

나 뿐만이 아니라 음악을 들으러 온 모든 사람들이 열열히 박수를 치는 모습이 아직도 기억에 남는다. 그와의 협연이 끝나고 그 유명하다는 보스턴 심포니는 The planet 으로 마무리를 하지만 오히려 관중들은 실망 했다는 모습이 역력했다.

나는 그날 연주를 뒤로 하고 일단 뉴욕의 친척 집으로 돌아왔다 그리고 여독을 좀 녹인 후 DC로 다시 여행을 떠났다. 1월 10일 수요일 호주 친구들과 합류 여기저기 관광을 하는 중 지하철 역에서 문득 보게된 광고...조슈아 벨 리사이틀... 나는 속으로 아 이 사람 투어 중이구나 보스턴 다음에는 DC군 하고 생각했다. 그리고 시간만 된다면 다시 그의 음악을 듣고 싶었지만 이미 비행기 표가 확정된 시점에서 예정을 변경 할 수는 없었다. 그렇게 이틀 가량을 DC에서 더 머문 후 오스틴으로 돌아 왔다.

만약 지하철에서 그의 음악을 들었다면 나는 그의 연주임을 알아 차릴 수 있었을까? 평소라면 분명 못하겠지만 그의 음색을 들은지 몇일 안되었기 때문에 가능성이 있었을지도 모른다. DC에서는 뉴욕만큼 거리의 뮤지션이 많지도 않고 나는 바쁜 사람도 아니니 그 뮤지션을 눈여겨 볼지도 모르기 때문이다.

기사에 대해서 예기해보자. 위의 기사는 살짝 말을 돌려서 생각하면 유명한 음악가들의 공연을 보러가는 사람들은 그저 허영을 부리고 있는 것이다 라고 생각하게 만든다. 물론 전부를 예기하는 건 아니다. 허나, 이런 실험을 근거로 한 기사는 평소에도 클래식 문화에 부정적인 생각을 가진 사람들에게 좋은 비평소제가 되버린다.(기사 밑에 달린 댓글을 보면 알 수 있다)

하지만 청중(지하철의 승객들)이 눈을 돌리지 않았다는 건 역시 음악이 그들의 발길을 멈출 만큼 감미롭지 않았다는데 한 표 던진다. 아무리 그들이 바쁘다고 해도 말이다. 이유는 음악을 듣는 환경에 있지 않을까 생각한다. 지하 지하철역 게다가 사람 북적이고 시끄러운 러쉬아워 시간 때... 이런데서 연주를 아무리 잘 한들 그게 귀에 들어나 오겠는가? 그냥 어디서 음악이 들려오는 구나 하고 말뿐이다. 적어도 음악이 제대로 들려야 좋구나 아름답구나 하고 생각을 할 것이 아닌가? 결론은 기사에서 말하는 의문을 풀기에는 실험이 너무 엉터리 같다는 것이 나의 의견이다. 적어도 음악이 제대로 들리는 환경하에서 음악을 들려주며 실험을 해야 한다고 생각한다.

나는 딱 한번의 그의 음악을 접한 후 아직 까지도 그의 음악을 들으수만 있으면 비싼 돈 주고라도 공연장에 가고 싶다는 생각을 가지고 있다. 나는 음악에 대해서도 잘 모르고 그림에 대해서도 잘 모른다. 하지만 예술은 그런것에 구애 받지 않는다. 지식이 필요 없는게 예술이라고 생각한다. 레오나르도의 그림을 봤을 때 오싹했었다. 마치 흑마술을 사용해 사람의 영혼을 그림에 안착시킨 듯한 느낌을 받았다. 하지만 그럴리가 있겠는가? 그저 레오나르도가 그렇게 표현 한 것 뿐이다. 그리고 그 걸 느끼는데는 그저 필요한 건 두 눈 뿐이다. 조슈아 벨과 보스턴 심포니의 콘체르토를 듣고나서 나는 술을 마셨을때 와 같이 얼굴이 달아오른 상태였었다. 지금 그때의 음률이 생각나지도 않는데다 뭘 연주했는지도 모른다.(카탈로그 잃어버렸다) 즉, 내가 모르는 콘체르토 였었다... 별로 아는 것도 없지만... 하지만 감동을 느끼는데 필요했던건 그저 두 귀와 약간의 돈 그리고 시간 이였다.

p.s 그때 들었던 협주곡은 Bruch violin concerto No.1 이였네요.

(DC 지하철에서 본 조슈아 벨 광고 팻말)