Ezbeat의 도서관

PICA air 사용하기

Ezbeat — Fri, 27 Apr 2012 01:39:37 +0900

컴퓨터 사양이 좋아진 이후론 vmware로 과장 쫌 보태 windows os를 50개쯤 킬 수 있을 것 같군요. =_=;;

PICA air라는 PC방 관리 프로그램을 설치해서 환경을 구축해봤습니다.

서버, 클라 둘다 말이죠. 2개의 os를 사용해.

아래는 동영상입니다.

( 화면이 작으니.. 제대로 보실려면 브라우져 크기 조절 )

영상에 많은 설명을 넣어놨지만.. ^^

해보고 싶으신 분들은 고고씽! 필드 테스트 때 긴장될 것 같네요.

'RestRoom > Routine' 카테고리의 다른 글

PICA air 사용하기 (0)	2012/04/27
Phoenix HD 개인기록! (2)	2012/02/26
몸도 마음도 정화하리..? (2)	2012/01/19
2011 KUCIS 최우수동아리 & 기술문서 부분 최우수상 (0)	2011/12/21
해피캠퍼스는 멍청해!! (2)	2011/12/08
ATmega128 LCD password 실험 (0)	2011/11/17

ELF 파일의 PLT, GOT

Ezbeat — Thu, 26 Apr 2012 23:35:11 +0900

음.. 윈도우 PE파일에서는 프로그램이 실행되면 Import table과 Export table을 사용해 프로그램에서 사용할 라이브러리 주소를 가져오지요. dll 같은 경우는 로드될때 base address가 바뀔수도 있기 때문에 PE Loader가 프로그램이 실행되면 특정 메모리에 함수들의 주소를 다 쓰지요.

그러면 대표적인 리눅스 실행 파일인 ELF 파일은 라이브러리 함수 주소를 어떤식으로 가져와 사용할까요?

테스트를 진행할 소스코드입니다. 단순한 덧셈 프로그램이지요.

-static 옵션을 사용하지 않고 컴파일 후 진행하도록 하겠습니다.

컴파일이 끝났으면 readelf -S 를 사용해 섹션 헤더를 봐보겠습니다.

주목해야할 섹션은 .plt 섹션과 .got.plt 섹션

.plt 섹션은 Procedure Linkable Table 의 약자로서 말그대로 함수들 링크가 가능한 테이블로 프로그램이 호출하는 모든 함수가 나열되어 있습니다.

.got.plt는 Global Offset Table로서 전역 offset을 가지는 테이블 이랍니다.

한번 쭉 프로그램을 실행하면서 따라가보죠.

main함수 첫 부분을 보면 printf 함수를 호출하고 있습니다.

그러면 해당 주소를 가보죠

printf 실제 링크 주소로 오는 것이 아닌 plt 라는 영역으로 들어오게 됩니다.

어딘가 점프를 또 하네요. 따라가보겠습니다.

이번엔 got 영역으로 들어오는군요. 원래는 저 부분에 printf의 실질적인 라이브러리 주소가 있어야합니다.

하지만 지금은 첫번째로 printf가 호출되는 상황이므로 아직 printf의 라이브러리 주소를 구해놓지 않은 상황입니다.

잘 보시면 0x08048346 주소는 plt 영역의 <printf@plt+6> 주소가 같은 것을 확인할 수 있습니다.

즉, 현재는 jmp *0x804a000을 수행하면 <printf@plt+6> 위치로 오게 됨을 알 수 있습니다.

그리고 나서 jmp 0x8048330을 수행하는데 저 부분은 dl_runtime_resolve 함수를 수행하는 부분인데요.

실제 printf의 라이브러리 주소를 got에 저장하고 printf의 실제 주소로 점프를 한다고 합니다.

윈도우 PE파일과 다르게 호출되는 함수 주소를 한번에 다 올리는 것이 아닌 프로그램 실행 시 호출될 때마다 라이브러리 주소를 got에 넣는다고 하네요. 그 다음번 printf를 호출할 땐 이미 앞서 got에 printf의 라이브러리 주소를 가져왔으므로 dl_runtime_resolve 함수를 수행하지 않고 바로 printf 를 호출할 수 있습니다.

한번 main 함수의 printf 다음 주소에 bp를 걸고 수행 후 got를 확인해 보겠습니다.

아까와는 값이 다르게 있다는 것을 알 수 있겠네요.

결론은 FSB 기법을 활용해 got overwrite를 해서 쉘을 따는 방법도 널리널리 알려졌습니다.

아 그리고 -static 옵션을 사용해 컴파일을 하면 위 과정 따윈 다 ~~ 없습니다. 모든 함수들이 프로그램 내부로 들어오기 때문이죠. 대신 용량은~? 엄청 커지겠네요. 위 실행 파일을 대상으로 비교를 해보니 용량은 90배 가량 차이가 났습니다.

배보다 배꼽이 더큰 상황이 -0-;; 아무튼 리눅스도 잘해야합니다..... 윈도우도 잘 못하는 것이 별의별 걱정을 다하네요.

'My Study > Programming&Theory' 카테고리의 다른 글

ELF 파일의 PLT, GOT (2)	2012/04/26
Calling Convention Process for AMD 64 Bit (4)	2012/04/02
Windows rand() 랜덤 비율 (0)	2012/02/14
ARM 명령어 공부 (2)	2012/01/27
BlockInput Function (3)	2012/01/20
My BSOD (2)	2012/01/08

간단한 정수 오버플로우

Ezbeat — Sun, 22 Apr 2012 02:11:17 +0900

잡담..

흐흐+_+ 오늘은 아버지께서 양복을 사주셨습니다. 제 생애 처음으로 입어보는 양복이네요..

양복하면 어른들 양복 밖에 생각이 안나서 입기 꺼려하고있었는데 오늘 양복점을 가서 입어보니 20대들이 입을 수 있는 핏도살고 간지도 나는 깔끔한 정장들도 나오더군요. 제 마인드가 오늘 또 하나 바뀌었습니다 ㅋㅋ

첫 양복이라 무난한 검은색으로.. 장례식장이던..결혼식장이던..발표할때던.. 어디서나 입을 수 있는..ㅋ

하!지!만.. 아직 구두가 없어서 입을수가 없습니다 ㅠ_ㅠ.. 이로서 사회인에 한걸음 다가간 느낌이 조금 드네요 -_-; 싫습니다!!

====================================================================================

자기전에 책보다가.. 간략히 나오길래 저도 확인차 그냥 정리만 하고 자렵니다.

Exploit과는 거의 담을 쌓고 지낸지라.. 오랜만이군요. 이런 글도..

이런 간략한 코드가 있습니다. 너무 인위적이네요.

문자열을 하나 입력받고 해당 문자열과 문자열의 길이를 넘기구요.

문자열의 길이가 of함수에 할당된 buf 크기보다 작으면 복사를 하고 크면 복사를 하지 않고

끝나게 됩니다.

일반적인 bof 개념으로보자면 저 루틴에선 취약점이 없어 보이겠네요.

하지만 정수 오버플로우 발생으로 취약점이 일어나는 부분이 있습니다.

바로 of함수에서 문자열의 길이를 비교하는 if문..에서 발생합니다.

현재 templen과 maxlen 변수의 자료형은 char입니다.

그렇기 때문에 128인 값이 들어오면 -1로 취급을 하게 되겠지요.

즉, of함수 인자로 문자열 길이를 넘길 때 128글자 이상을 넘기면 해당 값은 음수로 인식이되 if안으로 들어오게되면서

bof를 일으킬 수 있습니다.

assembly 로 봐보겠습니다.

저 부분을 보시면 cmp로 비교한 다음 JGE라는 점프문이 나오네요.

JG, JL은 부호있는 값이 비교할 때 사용되는 점프문..입니다. 그 반대는 JA, JB 이겠지요.

고로 [ebp+8] 값이 0x80이 넘어서면.. JGE 는 작동되지 않고.. 문자열 복사가 이루어집니다.

이렇게 말이죠..

해결방안은?! 모르면 간첩!!

잘래요 ㅠ ㅠ

'My Study > Exploit' 카테고리의 다른 글

간단한 정수 오버플로우 (2)	2012/04/22
Windows ShellCode 만들기 ( DEP란.. ) (3)	2010/10/30
geteuid()를 사용한 쉘코드 만들기 (0)	2010/05/21
버퍼 오버플로우 취약점에 대한 대처 방안들 (0)	2010/04/29
Hackerschool level19 쉘코드 줄이기, 환경변수 사용하지 않기 (0)	2010/04/26
RTL로 푼 해커스쿨 level11 (2)	2010/04/07

백신 Avast의 Anti-attach 우회하기

Ezbeat — Thu, 19 Apr 2012 20:26:48 +0900

Avast 백신에서 실행파일을 검사할 때 어떠한 방식으로 알아보려고 리버싱을 시도하려는데

이와 같은 창이 뜨게됩니다. 해당 프로세스를 어테치를 할 수가 없습니다.

그래서 시작한 아바스트 어테치하기... 얼른 끝나면 좋으려만;ㅋ

사실 해보면서 글 작성하고 있는 겁니다.

왜냐하면.. 이렇게 글을 쓰기 시작해놔야 글 완성을 위해서라도 끝까지 하게되기 때문이죠.

저의 게으름성을 채찍질하기 위함?

Avast 는 아래와 같이 기본적으로 2개의 프로세스로 작동하고 있습니다.

두 프로세스다 어테치가 안되는 건 당연..

일단 ollydbg에서 attach를 실패하는 것으로보아 AvastUI.exe의 pid를 가지고

OpenProcess 할 때 함수가 실패하고 있는 것으로 생각했습니다.

그리고 그렇게 생각했던 이유 중 가장 큰 원인이..

NtOpenProcess가 SSDT 후킹 되어 있다는 점이었습니다. 바로 아바스트 시스템 파일에 의해 말이죠.

하..지..만.. =_= 그건 저의 명백한 착각..

아무리 커널 디버깅을 해서 봐보아도 일반 계산기를 attach할 때와 avastui.exe를 attach 할 때와의 차이점이 없는 것입니다.

NtOpenProcess 성공적으로 호출되구요. 아무튼 아니라는 겁니다.

근데 당연한 거지만 저도 이 짓을 하면서 처음 알았는데 올리디버거에서 Attach를 눌렀을 때 뜨는 바로 이창..

이 창에서 나오는 프로세스들은 OpenProcess가 성공해야만 나오는 것이었습니다.

고로 AvastUI.exe가 저기 나온걸로 보아 OpenProcess는 무조건 성공 -0-;; 아.. 허무허무..

그러면 다른 함수로 눈을 돌려야겠죠. 어테치가 안된다고 에러메시지창이 떴을 때 루틴을 봐보니

DebugActiveProcess 함수가 실패하고 있었던 것입니다. AvastUI.exe를 attach하려고 했을 때 말이죠.

Ollydbg에서.. 보이는 루틴

IDA에서 보이는 루틴

똑같은 주소에 있는 루틴인데 왜 올디에선 저렇게 보이는지.. -_-;;;;

하지만 hex 값을 보아하니 올디가 기계어를 잘못읽고 변환한건 아닙니다.

push 하고 retn하는걸로 보아 0x10002321로 점프를 하고 있군요.

"antiattachkill" 문자열이 있고 막 뭐가 있네요. 그리고 아래 있는 JMP에서 다시 원래 루틴으로 돌아가게 됩니다.

음.. 올디가 런타임 시 내부적으로 .text영역에 있는 코드를 바꿔버리는 걸까요?

IDA에서는 바로 나오는걸로보아 그런듯 싶습니다. 귀찮으니 여긴 분석 X

아무튼 현미경에 DebugActiveProcess 함수를 대보고 봐봐야겠습니다.

DebugActiveProcess 함수 안...

DebugActiveProcess 는 타겟 프로세스의 PID를 가지고 호출을 하게 됩니다.

빨간색으로 네모친 부분이 타겟 PID를 가지고 ZwOpenProcess를 사용해 핸들을 구하는 부분입니다.

핸들은 성공적으로 잘 얻습니다.

그리고 그 아래 DbgUiDebugActiveProcess 함수가 있네요. 해당 함수는 얻은 핸들을 인자로 호출을 하게 됩니다.

내부적으로 ZwDebugActiveProcess를 호출하네요. 해당 함수는 첫번째 인자 핸들 두번째인자 디버그오브젝트?

라는 값을 가지고 KiFastSystemCall을 호출합니다. 유저는 여기서 끝이군요.

ZwDebugActiveProcess 함수의 리턴 값이 일반적인 경우 0x00000000 인데

AvastUI.exe를 어테치하면 리턴 값이 0xC0000022 입니다. 접근 거부...

그러면 역시 나 또 커널에서 무언가 조작이 되어 있다는건데...

ZwDebugActiveProcess 함수가 SSDT 후킹되어 있지도 않고 커널 수정된 부분을 봐도 inline훅이 되어 있지도 않습니다.

음.. .그러면 커널 디버깅을 통해 루틴을 따라 가보죠.

NtDebugActiveProcess 첫 부분입니다. 심오하게 들어가야 알 줄 알았지만 다행이 함수 초입부부터 뭔가 이상했습니다.

0x80664545 에서 ObReferenceObjectByHandle 이라는 함수를 사용하고 있습니다. 이는 OpenProcess로 부터 얻은 프로세스의 핸들을 가지고 해당 ThreadObject를 구해주는 함수입니다. 하지만 저 함수의 리턴 값이 0xC0000022 였습니다.

물론 AvastUI.exe를 어테치 했을 경우이고 그냥 계산기를 어테치 했을 경우엔 0x00000000이 리턴 됬습니다.

그러면 ObReferenceObjectByHandle 함수 내부를 봐봐야 뭘 알 것 같군요.

하던 도중 cpu가 쿼드라 일반적인 트레이싱이 힘들더군요. 자꾸 bp걸고 그냥 실행하면 context가 다른 걸로 넘어가 있어서..ㅠ

잡소리 그만하고 아무튼 gogo

내부를 보니.. 처음 부분에 ExMapHandleToPointerEx 함수가 호출되고 있습니다.

제가 알기론 HANDLE_TABLE 이라는 구조체를 리턴 값으로 넘겨주는 함수입니다.

일단 해당 함수를 호출한 이후 리턴 값을 봐보겠습니다. ( 현재 AvastUI.exe 를 어테치한 상황입니다. )

저 빨간색 네모친 부분이 중요합니다. 근데 자료를 찾아보니 QuotaProcess 의 자료형은 PEPROCESS로 프로세스 객체 포인터를 가지고 있어야하는데 저 값이 이상하군요. 아무튼 저 값이 사용되는 부분을 봐보겠습니다.

빨간색 네모친 부분위에서 해당 값을 가져다가 지지고 볶고 한 다음 test로 어떠한 값(이 모듈 인자) 과 test 연산을 하는데

QuotaProcess가 0x410이면 점프를 한다는 것입니다.

점프를 하고 나면 이 부분으로 오는데 저기서 익숙한 값이 0xC0000022 값을 ebx 레지스터에 넣고 있습니다. 저기가 실행되면 안되겠죠.

그러면 Avast 관련 프로세스가 아닌 일반 프로세스를 대상으로 위와 같은 짓을 다시 해보겠습니다. 어떠한 차이점이 있는지를 알면 우회하기가 더욱 편할 것 같군요.

이번엔 notepad.exe 프로세스를 어테치 했을 때의 상황입니다. 위와 다르게 0x410이 아닌 0xc3a가 저 부분에 존재하더군요.

실제로 notepad.exe 말고도 calc.exe 등등 Anti-attach가 적용되지 않은 여러 프로세스를 다 어테치 해봤을 때 저 부분이 0xc3a 였습니다. 이때 0xc3a를 0x410으로 바꿔서 실행하니

반가운 창이 뜨네요.

그러면 메모리 패치를 시도해볼 수 있는 기회가 생겼군요.

AvastUI.exe를 어테치 한 상황에서 ExMapHandleToPointerEx 함수까지 호출 된 후! 리턴 값인 HANDLE_TABLE의 QuotaProcess 멤버변수를 0x410이라는 값에서 0xc3a로 바꿔서 실행을 해보겠습니다.

올레~~~~ Attach 성공입니다.

음.. 그러면 저 0x410이라는 값은 도데체 언제 셋팅이 되는 것일까요?

ExMapHandleToPointerEx 함수의 리턴 값은

"BaseHandleTableAddress + (Target Handle / 4 * 8)" 이라는 공식하에 나오는 건데...( 내부적으로 이렇게 얻어옴 )

NtDebugActiveProcess 함수를 들어오기 전부터 이미 핸들은 셋팅되어 있는 것이고..

고로 NtDebugActiveProcess 들어오기 전부터 핸들 테이블에는 0x410이라는 값이 셋팅되어 있는 것입니다.

그러면 핸들을 얻어오는 NtOpenProcess!!! 이놈을 다시 조저봐야하는 건가요?? 처음으로 다시 돌아가야하는 기분이네요.

근데 NtOpenProcess는 아바스트 시스템 파일에 의해 SSDT 후킹이 되어 있는 상황이라.. 말이 되는군요.

시험기간이고 시간이 없어서 여기까지만 하겠습니다. 분명 예상대로라면 핸들을 얻어와서 핸들 테이블에 처음엔 0xc3a를 넣겠지만 나중에 0x410을 또 어딘가에 넣겠지요.

nt!ExCreateHandle:

80571d96 8bff mov edi,edi

80571d98 55 push ebp

80571d99 8bec mov ebp,esp

80571d9b 51 push ecx

80571d9c 8365fc00 and dword ptr [ebp-4],0

80571da0 53 push ebx

80571da1 56 push esi

80571da2 8b7508 mov esi,dword ptr [ebp+8]

80571da5 8d45fc lea eax,[ebp-4]

80571da8 50 push eax

80571da9 56 push esi

80571daa e81cffffff call nt!ExpAllocateHandleTableEntry (80571ccb)

80571daf 8bd8 mov ebx,eax

80571db1 85db test ebx,ebx

80571db3 7444 je nt!ExCreateHandle+0xbd (80571df9)

80571db5 57 push edi

80571db6 64a124010000 mov eax,dword ptr fs:[00000124h]

80571dbc 8bf8 mov edi,eax

80571dbe ff8fd4000000 dec dword ptr [edi+0D4h]

80571dc4 8b450c mov eax,dword ptr [ebp+0Ch]

80571dc7 8b08 mov ecx,dword ptr [eax]

80571dc9 890b mov dword ptr [ebx],ecx

80571dcb 8b4004 mov eax,dword ptr [eax+4]

80571dce 894304 mov dword ptr [ebx+4],eax ; BaseHandleTableAddress + (Handle/4*8) + 4 위치에 0xc3a 넣음

알아낸건 일단 이 부분입니다. 저기서 0xc3a를 넣는건 확인했습니다. ExCreateHandle 함수!

'My Study > Reversing' 카테고리의 다른 글

백신 Avast의 Anti-attach 우회하기 (8)	2012/04/19
NtSetInformationThread 를 이용한 Anti-Debugging (0)	2012/04/17
Themida 2.1.2.0 Virtual Machine (7)	2012/02/01
ARM CPU 공부시작.. ㅠ_ㅠ (6)	2012/01/25
Code Virtualized (7)	2011/06/27
ZwSetSystemInformation (2)	2011/01/11

NtSetInformationThread 를 이용한 Anti-Debugging

Ezbeat — Tue, 17 Apr 2012 13:21:17 +0900

밥 먹으면서 뭘 보다가 그냥 잼난거 같아서 정리해봅니다.

햇반 질려요 .. ㅠ_ㅠ ..

이번엔 NtSetInformationThread 함수를 사용한 안티디버깅 방법인데요.

함수 정의는 아래와 같이 생겼습니다.

NTSTATUS ZwSetInformationThread(
  __in  HANDLE ThreadHandle,
  __in  THREADINFOCLASS ThreadInformationClass,
  __in  PVOID ThreadInformation,
  __in  ULONG ThreadInformationLength
);

MSDN의 설명을 보니 스레드의 우선순위를 지정한다고 나와있습니다. 스레드 우선순위와 안티디버깅?

MSDN을 더 뒤져봐도 스레드 우선순위 관련 설명밖에 안나와있군요. 그러면 전 문서에 나온 설명을 적겠습니다.

Windows 2000은 오직 anti-debugging 목적으로 함수를 확장했다는데요.

바로 ThreadInformationClass 에 ThreadHideFromDebugger(0x11) 멤버입니다.

ntdll의 NtSetInformationThread함수를 사용해 각각의 스레드 마다 지정될 수 있습니다.

바로 코드를 봐보겠습니다.

50줄도 안되는 짧막한 코드네요.

보시면 39번째 라인에서 NtSetInfortmationThread 함수를 호출하고 있습니다. 인자를 보면 현재 쓰레드를 대상으로 말이죠.

실행결과 화면입니다.

NtSetInformationThread 함수의 리턴 값이 0x00000000로 제대로 호출은 되고 있군요.

이제 프로그램을 Debugger에 Attach를 시켜보겠습니다... 이 부분은 동영상으로 봐보죠 그게 더 보기 쉽겠네요.

(화면이 잘 안보실태니 브라우져 크기를 조절하셔서 보세요~)

동영상에서 보이시는 바와 같이 작동하게 됩니다.

그러면 문서에 있는 설명을 조금 더 읽어보죠.

이 함수가 호출되게 되면 해당 thread는 계속 실행되지만 debugger 같은 경우는 더이상 thread에 관련된 어떠한 이벤트를 받지 못한다고 되어 있습니다. 즉, BP를 걸었으면 debugger에 breakpoints 가 걸렸다는 이벤트가 전달이 되야되는데 전달이 되지 못하므로 CC를 만난 타겟 프로그램은 그냥 예외가 나버려 죽게되는 것입니다.

Olly Advanced 플러그인에 있는 ZwSetInformationThread 우회 설정을 해놓으면 될까 싶어서 해보았는데 타겟 프로그램을 바로 디버거에 붙혀서 실행하면 플러그인에 의하여0xFFFFFFFE 를 뱉으며 우회가 되지만 실행 중인 프로그램을 Attach를 할 경우는 이미

ZwSetInformationThread 함수가 호출된 상황이기 때문에 이 경우는 어떻게 우회를...

근데 이 방법을 몰랐을 경우에는 Software BP를 탐지하는 안티 디버깅이라고 착각을 할수도 있겠네요.

============================ 커널 분석 과정 ======================== 굳이 볼 필요는 없습니다.

그러면 NtSetInformationThread는 user 상에선 어떻게 작동하는지 확인하지 못합니다.

소화할겸 오랜만에 커널 디버깅이나 해봐야겠습니다.

일단 cpu제어를 제 프로세스의 스레드 context로 옮겨놓고 멈춰놓고 커널 내부적으로 NtSetInformationThread 에 BP를 걸어 멈추고 디버깅을 시작해보았습니다. 맞게 표현한건지 모르겠군요.

NtSetInformationThread 시작 루틴

8057afa7 68d0000000 push 0D0h 8057afac 68a05c4f80 push offset nt!ObWatchHandles+0x32c (804f5ca0) 8057afb1 e8bd9ef6ff call nt!_SEH_prolog (804e4e73) 8057afb6 64a124010000 mov eax,dword ptr fs:[00000124h] 8057afbc 8945dc mov dword ptr [ebp-24h],eax 8057afbf 8a8040010000 mov al,byte ptr [eax+140h] 8057afc5 8845e4 mov byte ptr [ebp-1Ch],al 8057afc8 84c0 test al,al 8057afca 0f847f8b0600 je nt!NtSetInformationThread+0x9d (805e3b4f) 8057afd0 8365fc00 and dword ptr [ebp-4],0 8057afd4 8b450c mov eax,dword ptr [ebp+0Ch] ; 두번째 인자였던 0x11 가져옴 8057afd7 48 dec eax 8057afd8 48 dec eax 8057afd9 740f je nt!NtSetInformationThread+0x3b (8057afea) 8057afdb 48 dec eax 8057afdc 48 dec eax 8057afdd 740b je nt!NtSetInformationThread+0x3b (8057afea) 8057afdf 83e803 sub eax,3 8057afe2 0f84c2a40800 je nt!NtSetInformationThread+0x74 (806054aa) 8057afe8 48 dec eax 8057afe9 48 dec eax 8057afea 6a04 push 4 8057afec 5b pop ebx 8057afed 895dd8 mov dword ptr [ebp-28h],ebx 8057aff0 8b7d14 mov edi,dword ptr [ebp+14h] 8057aff3 8b7510 mov esi,dword ptr [ebp+10h] 8057aff6 85ff test edi,edi 8057aff8 7423 je nt!NtSetInformationThread+0x6c (8057b01d) ; 점프 8057b01d 83caff or edx,0FFFFFFFFh 8057b020 8955fc mov dword ptr [ebp-4],edx 8057b023 6a0a push 0Ah 8057b025 58 pop eax 8057b026 8b4d0c mov ecx,dword ptr [ebp+0Ch] ; 0x11 다시 가져옴 8057b029 3bc8 cmp ecx,eax 8057b02b 0f8fb82c0300 jg nt!NtSetInformationThread+0x5c4 (805adce9) ; 0x0A보다 크므로 점프 805adce9 8bc1 mov eax,ecx 805adceb 6a0d push 0Dh 805adced 59 pop ecx 805adcee 2bc1 sub eax,ecx 805adcf0 0f85337a0500 jne nt!NtSetInformationThread+0x5d1 (80605729) ; 0x0D와 다르므로 점프 80605729 48 dec eax 8060572a 0f8455010000 je nt!NtSetInformationThread+0x719 (80605885) 80605730 48 dec eax 80605731 0f84e6000000 je nt!NtSetInformationThread+0x6bb (8060581d) 80605737 48 dec eax 80605738 48 dec eax 80605739 0f84a3000000 je nt!NtSetInformationThread+0x680 (806057e2) ; 여기서 eax가 0 되면서 점프 806057e2 85ff test edi,edi 806057e4 0f854bfeffff jne nt!NtSetInformationThread+0x3f2 (80605635) 806057ea 57 push edi 806057eb 8d45ac lea eax,[ebp-54h] 806057ee 50 push eax 806057ef ff75e4 push dword ptr [ebp-1Ch] 806057f2 ff355cb75680 push dword ptr [nt!PsThreadType (8056b75c)] 806057f8 6a20 push 20h 806057fa ff7508 push dword ptr [ebp+8] 806057fd e8578df6ff call nt!ObReferenceObjectByHandle (8056e559) ; 프로그램의 ETHREAD 구조체 주소 얻음 80605802 8bf0 mov esi,eax 80605804 85f6 test esi,esi 80605806 0f8c7f59f7ff jl nt!NtSetInformationThread+0x3a7 (8057b18b) 8060580c 8b4dac mov ecx,dword ptr [ebp-54h] ; 얻은 ETHREAD 구조체 주소 8060580f 8d8148020000 lea eax,[ecx+248h] ; ETHREAD.각종 비트 단위 정보 80605815 f00918 lock or dword ptr [eax],ebx ; edx = 00000100b, ETHREAD.HideFromDebugger 값 1로 셋팅 80605818 e96959f7ff jmp nt!NtSetInformationThread+0x3a2 (8057b186) 8057b186 e87587f6ff call nt!ObfDereferenceObject (804e3900) 8057b18b 8bc6 mov eax,esi 8057b18d eba0 jmp nt!NtSetInformationThread+0x879 (8057b12f) 8057b12f e87a9df6ff call nt!_SEH_epilog (804e4eae) 8057b134 c21000 ret 10h

코드는 방대하지만 그냥 추적하면서 필요한 부분만 추출해봤습니다. 그 중에서도 중요시 봐볼 부분은 아랫 쪽인데 아랫 쪽에서 보면 ETHREAD 구조체 주소를 얻어와 HideFromDebugger 멤버 값을 1로 셋팅하는 부분이 있습니다.

빨간색으로 된 부분만 보시면 됩니다.

이로서 NtSetInforamtionThread 루틴은 끝입니다. -_-;; 고로 최종 작동 코드는 아래와 같은 한줄...

ETHREAD.HideFromDebugger = 0x01;

이때 간단히 저 부분을 0x00으로 다시 패치하면 anti-debugging 우회! .. 뭐 이렇게 하는건 의미가 없네요.

그러면 저 메모리 값(HideFromDebugger)을 어디서 참고해서 쓰고 있는지 봐보겠습니다.

b1d20934 8051a017 nt!DbgkForwardException+0x38 b1d20cf4 804e03f3 nt!KiDispatchException+0x1f4 b1d20d5c 804e0b4c nt!CommonDispatchException+0x4d b1d20d5c 00401068 nt!KiTrap03+0xae WARNING: Frame IP not in any known module. Following frames may be wrong. 0012ffc0 7c817067 0x401068 80582109 f6804802000004 test byte ptr [eax+248h],4

80582110 0f8560b40900 jne nt!DbgkForwardException+0x3a (8061d576) [br=1]

윗 부분은 해당 멤버변수를 참고하는 위치에서 멈췄을 때의 콜스택이고

아래 부분은 해당 멤버변수를 참고하는 코드입니다.

( 현재 스레드 부분에 BP를 건 후 멈춘 루틴입니다. 단순 Attach를 했을 땐 여기를 오지 않습니다. )

일단 4와 비교한 후 점프를 할지 말지 결정되는 걸로봐서 저 부분 루틴을 따라가면 차이점이 있겠군요.

HideFromDebugger 셋 되어 있으면 점프하고 클리어 되어 있으면 점프를 하지 않습니다.

조금만 더 분석해보니...

점프를 하지 않으면 DbgkpSendApiMessage 함수를 수행하는 반면 점프를 하면 DbgkpSendApiMessage 함수를 실행 못하는 차이점이 있는것 같군요.

이로서 이 방법을 만났을 경우 우회할 수 있는 방법으로는 user 상에서 NtSetInformationThread 함수 호출 시 두번째 인자 값을 그냥 0으로 줘버리는 방법이 있겠군요.

아함.. C언어 수업가야되요.. ㅠ_ㅠ .. 그냥 급하게 정리를 마칩니다. 잉여잉여 -0-;;

'My Study > Reversing' 카테고리의 다른 글

백신 Avast의 Anti-attach 우회하기 (8)	2012/04/19
NtSetInformationThread 를 이용한 Anti-Debugging (0)	2012/04/17
Themida 2.1.2.0 Virtual Machine (7)	2012/02/01
ARM CPU 공부시작.. ㅠ_ㅠ (6)	2012/01/25
Code Virtualized (7)	2011/06/27
ZwSetSystemInformation (2)	2011/01/11

Melon Crack은 나쁜 것

Ezbeat — Mon, 16 Apr 2012 01:07:23 +0900

( 의미 없는 동영상 이지만 보실 분은 Ctrl + 마우스 휠 로 크기 조절해서 보세요. )

마지막으로 유종의 미를 거두며.. 이제 멜론 크랙 안합니다.

아직도 보안해야할 점이 많지만 이번 업데이트에서는 지금껏 업데이트한 것 중에 괜찮게 한 것 같습니다.

사용자의 id를 얻고 그거에 대한 유저 넘버를 얻고 등등 여러개 값을가지고.. 조합해 인코딩 시켜

384Byte의 값을 만들어서 서버에 넘기고 서버에서는 또다시 인코딩 된 1452Byte 의 큰 데이터를 넘겨서 어찌고 저찌고 처리..

이번엔 로그인 할때부터 노래가 재생될때까지의 모든 루틴을 분석한 것 같군요. -_-;;

추가적으로.. 유료결제한 사용자 id만 알면 그 사람꺼 쓸수있는듯..흠..

데일리시큐에 멜론 크랙 관련 기사가 났는데 경각심을 가지고 강력한 보안 메커니즘을 적용했으면 좋겠다.

왜냐하면 이젠 멜론 크랙에 시간 투자 할일 없으니깐..

멜론 유료결제 완료~ ^-^ ipad에서 노래들어야지 ㅠㅠ

'My Study > etc' 카테고리의 다른 글

Melon Crack은 나쁜 것 (5)	2012/04/16
TIOBE 프로그래밍 인기 순위 (2)	2012/02/02
ipad 사용자 권한 (0)	2012/01/27
바로가기 (2)	2011/07/31
PC로 카톡 쓰기~ (8)	2011/05/30
UHA 확장자 (0)	2011/05/27

Calling Convention Process for AMD 64 Bit

Ezbeat — Mon, 02 Apr 2012 18:09:16 +0900

머리가 멍청해 봐도봐도 까먹는 까마귀 같은 저... -_-;;

그냥 가장 흔한 인자 전달과 리턴 값 처리만 찾아서 정리했습니다.

http://www.osronline.com/ddkx/kmarch/64bitamd_7qqv.htm

매개변수 전달

파라미터 타입

Floating Point	처음부터 4개의 파라미터 - XMM0 ~ XMM3. 그 이후로 스택 사용!
Integer	처음부터 4개의 파라미터 - RCX, RDX, R8, R9. 그 이후로 스택 사용!
Aggregates(8,16,32, or 64 bits) and __m64	처음부터 4개의 파라미터 - RCX, RDX, R8, R9. 그 이후로 스택 사용!
Aggregates(other)	포인터. 처음부터 4개의 파라미터 - RCX, RDX, R8, R9. 그 이후로 스택 사용!
__m128	포인터. 처음부터 4개의 파라미터 - RCX, RDX, R8, R9. 그 이후로 스택 사용!

예제) 1 - 모두 정수

func1(int a, int b, int c, int d, int e);

a => RCX, b => RDX, c => R8, d => R9, e => 스택에 push..

예제) 2 - 모두 실수

func2(float a, double b, float c, double d, float e);

a => XMM0, b => XMM1, c => XMM2, d => XMM3, e => 스택에 push..

예제) 3 - ints와 floats 섞음..

func3(int a, double b, int c, float d);

a => RCX, b => XMM1, c => R8, d => XMM3

예제) 4 - __m64, __m128, 그리고 aggregates

func4(__m64 a, _m128 b, struct c, float d);

a => RCX, b => RDX, c => R8, d => XMM3

리턴 값

64 bits(__m64 타입 포함) 값이 들어갈 수 있는 대부분의 리턴 값은 RAX 레지스터를 통해 반환되어 진다. 하지만 __m128, __m128i, __m128d, floats, double 같은 타입은 XMM0 레지스터를 통해 리턴되어 진다. 만약 리턴 값이 64 bits안에 속하지 않는다면 호출자는 첫번째 인자를 사용해 리턴 값을 받은 포인터를 할당해 넘겨줘야한다.

'My Study > Programming&Theory' 카테고리의 다른 글

ELF 파일의 PLT, GOT (2)	2012/04/26
Calling Convention Process for AMD 64 Bit (4)	2012/04/02
Windows rand() 랜덤 비율 (0)	2012/02/14
ARM 명령어 공부 (2)	2012/01/27
BlockInput Function (3)	2012/01/20
My BSOD (2)	2012/01/08

notepad++ 멀티로더

Ezbeat — Thu, 29 Mar 2012 10:36:55 +0900

메모장 대신에 참 유용하게 사용할 수 있는 notepad++

타 메모장 프로그램과 마찬가지로 탭 기능을 지원하며 하나의 프로그램에서 여러개의 파일을 볼 수가 있습니다.

하지만 일반 메모장과 같이 2~3개 정도 켜놓고 보고싶은 경우도 있는데요.. 멀티로더가 안되게끔 만들어져 있어서.. 그게 아쉽네요. 옵션으로라도 제공을 하면 좋으려만.. 그래서 그냥 조금 수정시켜 만들어놨습니다. 필요하신분은 쓰세요.

안에서 단순히 뮤텍스를 사용한 멀티로더 방지를 하고 있어서 1Byte만.. 수정시키면 됩니다.-0-;; 1분짜리..

( 올디키기 귀찮으신분은 그냥 제꺼 써주세요 ㅋㅋ )

아무튼 필요하신분은 쓰세요.

notepad .exe

다운받으면.. notepad__.exe로 되는거 같은데.. notepad++.exe로 파일명 바꾸고

notepad++.exe가 있는 위치에 덮어씌우면 끝.

일단 버전은 위 그림에 나와있는 버전에서만 수정했습니다. 다른 버전은 안될가능성도 있겠지요. 위치가 바뀌었으면. -_-;

'My Study > Program' 카테고리의 다른 글

notepad++ 멀티로더 (0)	2012/03/29
Windows8-ConsumerPreview-32bit-English (0)	2012/03/03
GOMENCODER(곰인코더) Crack - 2012/02/28 (4)	2012/03/01
Windows Message Logging Tool (0)	2012/02/13
.text section disasm (0)	2011/07/26
ASCII Generator (2)	2011/04/19

Windows8-ConsumerPreview-32bit-English

Ezbeat — Sat, 03 Mar 2012 18:53:14 +0900

주말 저녁에 심심해서 설치해봤습니다 ..ㅎ
설치는 그냥 하면 되구요. ㅋ 켰을 때 화면을 찍어보았습니다.

swf라 10MB밖에 안올라가서 자르고 잘랐네요. 그냥 이렇게 생겨먹었슴다.

구제척으로 뭐가 달라졌는지는 천천히 봐봐야겠네요.
에고 옆에 Instant Demo가 뜨네요 ㅋㅋ 정품 가지고 싶어요 ㅠㅠ!

'My Study > Program' 카테고리의 다른 글

notepad++ 멀티로더 (0)	2012/03/29
Windows8-ConsumerPreview-32bit-English (0)	2012/03/03
GOMENCODER(곰인코더) Crack - 2012/02/28 (4)	2012/03/01
Windows Message Logging Tool (0)	2012/02/13
.text section disasm (0)	2011/07/26
ASCII Generator (2)	2011/04/19

GOMENCODER(곰인코더) Crack - 2012/02/28

Ezbeat — Thu, 01 Mar 2012 14:07:44 +0900

심심해서 한번 해보았습니다.
아르마딜로 패킹이 되어 있긴 하지만 강력한 프로텍터가 아니기 때문에
굳이 언패킹을 하지 않아도 손쉽게 분석이 가능했습니다.

요새는 여러 인코더가 나와서 곰인코더를 많이 쓰실지는 모르겠네요.
전 잘 쓰진 않지만요.. 인코딩할 일이 없어서;;

디버거 형식의 자동 패치툴을 만들어보았습니다.
(배포는 하지 않습니다.)

아에 분석을 하기 힘들게 중요 루틴 부분만이라도 코드 가상화 기법을 적용시켜놓으면..어떨까 싶네요.
자동화 툴도 있기 때문이죠 :-)

크랙을 못하게하려면..?
리버싱을 원천적으로 막는 방법을 찾는다.
현재 방법으로 가장 손쉽게 리버싱을 막으려면 패커를 바꾸는 방법을 택해야한다.
좀더 강력한 프로텍터로 패킹을 하는 것을 추천합니다.

루틴 수정.
중요루틴제어를 여러 군대로 분산시켜 분석을 어렵게??..뭐 결국 이것도 시간 문제지만요..

서버 사용.
로그인할 때만 사용자 인증을 위해서만 서버를 사용하고 있는데 ..
서버를 잘 활용해 크랙 방지.. 특정 루틴 인코딩 시켜놓고 서버에서 받아온 값을 가지고 디코딩 수행
서버에선 id와 권한을 가지고 암호화한 값을 전달??.. 뭐 이런식이면..

모르겠네요 -_-..

요즘 코드 가상화 기법을 제대로 공부를 해봐야하기 때문에 덕분에 리버싱을 많이해보게 생겼습니다..ㅠ

'My Study > Program' 카테고리의 다른 글

notepad++ 멀티로더 (0)	2012/03/29
Windows8-ConsumerPreview-32bit-English (0)	2012/03/03
GOMENCODER(곰인코더) Crack - 2012/02/28 (4)	2012/03/01
Windows Message Logging Tool (0)	2012/02/13
.text section disasm (0)	2011/07/26
ASCII Generator (2)	2011/04/19

Windows rand() 랜덤 비율

Ezbeat — Tue, 14 Feb 2012 13:47:56 +0900

걍 심심해서 테스트 해봤습니다. Windows에서 Visual Studio를 설치하고 srand와 rand함수를 사용해 랜덤 값을 뽑아내면 얼마나 랜덤할 수 있는지...;;

srand() 함수

rand() 함수

Visual Studio 2010/2008 기준으로 이와 같이 정의가 되어 있습니다.
( 그 하위 버전은 확인 못함.. )

최소 값은 0x0000, 최대 값은 0x7fff 가 되겠군요.

아래는 테스트 코드입니다. srand의 인자로 얼마나 랜덤 적이고 동적인 값을 넣어야 하는게 관건인듯 싶은데..
걍 전 rdtsc를 사용해 넣어봤습니다. ( time()이나 GetTickCount() 함수들 보단 동적이므로.. ㅎㅎ )

한번 실행마다 10억 번의 rand를 뽑아내 그 빈도를 조사해보았습니다.
가장 많이 나온 숫자의 횟수와 가장 적게 나온 숫자의 횟수를 조사해 %로 알아보았습니다.

여러번의 실행을 해보았습니다.

Max: 31308/1000000000 0.003131%

Min: 29715/1000000000 0.002971%

Max: 31267/1000000000 0.003127%

Min: 29783/1000000000 0.002978%

Max: 31222/1000000000 0.003122%

Min: 29809/1000000000 0.002981%

Max: 31343/1000000000 0.003134%

Min: 29782/1000000000 0.002978%

Max: 31234/1000000000 0.003123%

Min: 29743/1000000000 0.002974%

Max: 31258/1000000000 0.003126%

Min: 29701/1000000000 0.002970%

Max: 31209/1000000000 0.003121%

Min: 29777/1000000000 0.002978%

정확히 100%를 32767로 나누면 0.00305185% 쯤 나오는데
기준 %를 기점으로 대략 ±0.0001% 밖에 벗어나질 않는군요.

결론 : 골고루 랜덤한 값이 나옵니다 -_-;; 이상 뻘짓.............. 흑흑..

'My Study > Programming&Theory' 카테고리의 다른 글

ELF 파일의 PLT, GOT (2)	2012/04/26
Calling Convention Process for AMD 64 Bit (4)	2012/04/02
Windows rand() 랜덤 비율 (0)	2012/02/14
ARM 명령어 공부 (2)	2012/01/27
BlockInput Function (3)	2012/01/20
My BSOD (2)	2012/01/08

Windows Message Logging Tool

Ezbeat — Mon, 13 Feb 2012 16:21:57 +0900

Windows 메시지 로깅을 해보자. 간간히 어떠한 작업을 할 때 메시지 로깅이 필요할 때가 있는데 그 때 사용하는 툴 입니다.

이상한 잡다구리한 툴이 아닌 VS를 설치하면 같이 설치되는 툴로서..

Microsoft Spy++

이라는 툴입니다. 파일명은 spyxx.exe군요.

Microsoft에서 제공을 해주는 툴이므로 껄쩍지근함 없이 바로 사용할 수 있었습니다.
타겟 테스트 프로그램은.. PC_CTL.exe로 하겠습니다.

사실 2012년 2월 어느날.. 서울을 갔다가 잘곳이 없어서 찜방에서 자게 되었습니다.
마침 찜질방 컴퓨터가 있길래.. 켰습니다. 사용하려 했더니 돈을 넣으라더군요.

전 소프트웨어발전을 위해 착실히 돈을 내고 쓰는 유저이기 때문에 개발자와 찜질방 주인을 위해 돈을 투입했습니다.
그래서.. 관련 exe를 가져왔습니다. 그게 PC_CTL.exe입니다.
부모프로세스로 MSServices.exe라는 프로그램도 있었습니다. :-)

피시방에서 살짝쿵 분석을해서 ... 유용?!하게 사용하긴 했지만 일단 여기선 메시지 로깅이 목적이므로.. ㅎㅎㅎ

먼저 툴을 소개하겠습니다.

먼저 메시지 로깅 툴을 켜보면 이와 같이 나옵니다. 현재 활성화된 모든 윈도우들에 대한 핸들이 나오는군요.

그 외에도 Spy메뉴에서 Processes를 누르면..

이와 같이 나오고.... PC_CTL 프로세스도 보이는군요.

+버튼을 눌러 자세히 보면..

또한 원하는 Process, Thread, Windows에 대고 우클릭 후 Message를 누르면 해당 Windows에서 발생하는 모든 메시지를 로깅할 수 있으며..

이와 같이 Message Options을 주어서 원하는 메시지만 로깅할 수 있습니다.

그리고 로깅 후 보고 메시지를 자세히 보고 싶으면 우클릭 후 Properties.. 를 눌러주면..

wParam과 lParam에 대한 자세한 정보도 볼 수 있습니다.

뭐 메시지 관련 API함수들을 Hook해서 체크할수도 있지만 툴이 있으므로 이렇게 편하게 확인하면 됩니다.

그리고 PC_CTL 프로그램은 분석결과

Windows 작업 관리자

레지스트리 편집기

컴퓨터 관리

서비스

시스템 구성 유틸리티

위 5개의 프로그램이 켜질경우 자동으로 해당 프로그램들을 꺼버리는데요.
그냥 전 각 프로세스의 핸들을 얻어서 TerminateProcess함수로 종료시키는줄 알았습니다만..
BP를 걸고 running 해봐도 멈추지 않는걸로 보아 그건 아니더군요.

그래서 한번 봐보았습니다.
메시지 로깅을 원하는 윈도우를 설정하고 작업관리자를 켜보았습니다. 당연히 작업관리자는 죽겠지요.

그랬더니 이와 같이 로그가 남았습니다.

그러면 이벤트로 작업관리자를 죽이는것 같네요.

작업 관리자의 이벤트를 로깅해봤습니다.

위에 WM_TIMER는 1초에 한번씩 발생하는걸로 봐서 프로세스목록을 1초에 한번씩 얻어오고 있나봅니다.
빨간색 네모친것보면 WM_CLOSE이벤트가 발생했군요.
PC_CTL 프로세스가 SendMessage 혹은 PostMessage를 사용해 WM_CLOSE 이벤트로 작업관리자를 죽였나봅니다.

정답!

아무튼 이외에도 기능이 많으니 한번만 써보셔도 괜찮은 툴이라는 것을 알 수 있을 것 입니다. 더 괜찮은 메시지 로깅 툴이 있다면 추천 바랍니다 ^^;

'My Study > Program' 카테고리의 다른 글

Windows8-ConsumerPreview-32bit-English (0)	2012/03/03
GOMENCODER(곰인코더) Crack - 2012/02/28 (4)	2012/03/01
Windows Message Logging Tool (0)	2012/02/13
.text section disasm (0)	2011/07/26
ASCII Generator (2)	2011/04/19
Ezbeat Keygen Template (3)	2010/12/09

TIOBE 프로그래밍 인기 순위

Ezbeat — Thu, 02 Feb 2012 10:10:28 +0900

사이트
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

많은 분들이 포스팅을 해주셨지만 제 블로그 역시 포스팅..할래요. .ㅎㅎ

현재 2012년 1월 자료까지 나왔습니다.
사이트에도 나와있듯이

The TIOBE Programming Community index is an indicator of the popularity of programming languages.
프로그래밍 언어의 인기 지표랍니다.
1년 전 순위와 비교해 상승/하락 정도도 보여주네요.

역시 제가 좋아하는 C언어.. C++도 잘 활용할줄 알아야하는데.. 큰일입니다.
아무튼 이렇게 많은 언어들이 있다는 것도 첨 알았네요. 별별 언어가 다있네요 =_=;;

'My Study > etc' 카테고리의 다른 글

Melon Crack은 나쁜 것 (5)	2012/04/16
TIOBE 프로그래밍 인기 순위 (2)	2012/02/02
ipad 사용자 권한 (0)	2012/01/27
바로가기 (2)	2011/07/31
PC로 카톡 쓰기~ (8)	2011/05/30
UHA 확장자 (0)	2011/05/27

Themida 2.1.2.0 Virtual Machine

Ezbeat — Wed, 01 Feb 2012 17:31:53 +0900

리버싱을 하는데 있어서 가장 우리를 난감하게 만드는 놈은 바로 안리 리버싱이 걸려있는 바이너리 입니다.
이러한 안티리버싱 기술을 자동적으로 바이너리에 덮어씌워주는 놈은 바로 프로텍터들입니다. 대표적인 프로텍터로는
VMProtect 나 Themida 같은 프로그램들이 있습니다.

두 프로텍터는 역시 명성에 걸맞게 강력한 안티리버싱 기술들이 구현이 되어 있는데 그 중 하나는 Virtual Machine 기술입니다. 쫌 더 직관적으로 말하면 코드 가상화 기술입니다. 사실 아직 제대로 분석을 해보진 못하였지만 차차 분석을 해봐야되므로 간략히 그에 대한 코드를 분석해보았습니다. 전 일단 Themida 2.1.2.0 버전에 있는 Virtual Machine 기능을 살펴보았습니다.

더미다의 Virtual Machine 옵션입니다.

코드 가상화라 함은 원래의 명령어를 가상화를 시키고 가상화된 코드를 본체에 있는 하드웨어적인 CPU가 처리하는 것이 아닌 개발자가 만든 소프트웨어적인 핸들러가 처리를 하게 되는 것입니다. 그 때의 핸들러를 보통 가상화된 명령어를 처리하는 CPU라고 하는데 위 그림에서 Processor Specifications 에서 지정하는 것이 바로 그 소프트웨어적인 CPU를 어떻게 만들 것인지에 대한 옵션입니다. 일단 전 위와 같이 옵션을 지정하였고 위 옵션은 디폴트 옵션보단 조금 더 강력한 옵션입니다.

옆의 Entry Point Virtualization 옵션은 엔트리포인트로부터 몇 개의 명령어를 가상화 시킬 것인가를 지정하는 옵션입니다.
위와 같이 지정하면 2Byte가 아닌! 2개의 명령어가 가상화 되는 것입니다.

그 외로는
API 함수에 대한 가상화 레벨을 지정할수도 있고 Multi Branch Techology는 그냥 분석을 더욱 어렵게 하기 위해 분기문을 마구 꼬아놓는 그러한 옵션 같습니다.

아무튼 위와 같은 옵션으로 패킹을 진행하겠습니다. 먼저 원본 파일의 Entry Point를 봐보겠습니다.

익숙한 Entry Point 죠?? 아무튼 이번엔 패킹된 파일의 Entry Point를 봐보도록 하겠습니다.

옵션대로 위 2개의 명령어가 사라져있고 그 자리엔 쓰레기 값이 채워져 있습니다. 사실상 저 부분은 가상화가 되서 더이상 제어가 저 위치로 오지도 않을 뿐더러 실행도 하지 않습니다. 그렇기 때문에 그냥 저 부분엔 아무 값이나 채워놔도 무방합니다. 그 코드는 그러면 어디서 실행이 되냐구요?? 그건 가상화된 명령어를 실행해줄 소프트웨어적인 CPU가 수행해 주겠지요.

또한 가상화된 명령어는 메모리 어딘가에 마구마구 인코딩되서 짱박혀 있겠지요.

제가 간략히 분석해본 더미다 가상화 기술입니다.

먼저 Entry Point에서 두개의 명령어는 이미 가상화가 되어서 Virtualized Code 상에 존재할 것이고 해당 위치에는 쓰레기 코드가 있습니다. 그리고 Virtualized Code 부분에는 Code Section에 있는 가상화된 명령어만 있는게 아닌 Themida의 원래 기능인 코드, 리소스 등 이런 부분들 인코딩, 압축 되어 있는 것을 디코딩, 압축 해제 시키는 코드도 있는데 그 부분 또한 전부 가상화가 되어서 Virtualized Code 부분에 있는 것 같네요.

그리고 빨간색 화살표는 진행 방향인데요. Themida는 EntryPoint에 있는 CALL 명령어 부분만 가상화 했지 CALL 내부는 가상화 하지 않았습니다. 그렇기 때문에 가상화된 코드를 Virtual CPU가 돌리는 동안 Code Section부분으로 넘어와 Normal Code를 실행 후 다시 가상화된 코드를 실행시키는 것입니다. 이 때 CPU 제어 이동이 있겠지요.

가상화된 코드는 Virtual CPU가 실행시키고 Normal Code는 하드웨어적인 제 컴퓨터론 Intel CPU가 처리를 하게됩니다.

간단하게 실제 코드 상으로 한번 봐볼까요??

더미다 패킹 된 프로그램의 EntryPoint입니다. 이제부터 쭉쭉 인코딩된 코드를 디코딩 시킵니다...

계속 실행하다보면 무한반복하는 부분이 생기는데 아마 명령어를 fetch해서 해석하는 부분이겠지요.

저 부분에서 Virtual CPU의 Instruction Handler를 호출합니다.. EAX를 Index로 사용하네요.
( EDI : 0x0044A5E8, EAX : 0x00000057 )
EDI를 봐보겠습니다.

빨간색 네모친 부분이 Virtual CPU에서 사용하는 레지스터 입니다.
또한 그 아래 노란색 네모친 부분이 Instruction Handlers 입니다.
EAX가 Index가 되서 저 Handler 들 중 하나로 점프를 하게 되는 것입니다.
개수는 676개입니다.

하지만 Themida Virtual Machine 옵션을 낮게 주고도 해보았는데 차이점이 있었습니다.
위 가상화 기술 그림은 옵션을 약하게 줬을 경우이고 높게 주었을 경우에는 아래와 같이 됩니다.

두 번째로 실행되는 Virtual CPU에서 실질적인 Code 섹션에 있는 가상화된 코드를 실행해줍니다.

뭐 더욱 분석이 복잡해 졌네요.

아직 각각의 Instruction Handler 들이 어떤 식으로 작동하는지는 분석을 안해봐서 모르겠네요. 하지만 분명히 하나의 Intel 명령어를 처리하기 위해서 여러개의 Virtualized Code가 수행되는 것은 분명합니다.

JMP xxxxxxxx
와 같은 명령어 하나만 처리를 하더라도

이 부분이 무려 116번이나 호출된 것을 보면 알 수 있겠지요.
아마 코드를 가상화 시키면서 까지 거기에 쓰레기 코드 또한 많이 넣어놨을 것입니다.

또한! Instruction Handler들 내부에도 전부 쓰레기 코드왕창에 난독화도 무지되어있습니다.
또한! 더미다 패킹을 하게되면 생성되는 난독화 방법이나 쓰레기 코드들도 달라지며 opcode 순서도 바뀌게 되며 레지스터 순서도 바뀌고 아무튼 싹다 바뀌더군요. 하나를 제대로 분석했다 하더라도 다른 파일 분석이 힘든.. ㅠ_ㅠ

이번 글에서는 Themida 가상화 기술 관련해서 살짝만 맛 보았습니다.
왠지 제가 원하는 방법으로 구현이 되어 있는것 같아서 마음에 드네요.

나중엔 더욱 깊이 분석해보고 다른 패커에 쓰인 가상화 기술도 분석해봐야겠습니다.

=========== 2월 7일 추가 분석 ============
VM CPU로 제어가 넘어오는 부분이 있네요

일단 이 부분이 VM Entry로 들어오는 루틴입니다. 빨간색으로 표시된걸로 봐서 앞 코드에 의해 디코딩이 되었나봅니다.
그리고 저 루틴을 들어오기 전에

이러한 부분도 있는데 잘 보시면 0x0041E7D2로 VM Entry로 점프하는 루틴이 많은것을 볼 수 있습니다.
그리고 각 JMP하기전에 어떠한 값을 push를 하는데 push 하는 값의 용도는 확실히는 모르겠습니다.
예상으론 외부로 나갔다가 들어오면서 다시 가상화된 코드 부분을 돌리는데 해당 부분을 뜻하는 것 같습니다.

각 push에 bp를 걸고 trace를 해본 결과 5번 정도 LoadLibrary를 호출하고 GetLocalTime 함수도 호출을 하더군요.
아래서 다섯번째 JMP 문이 code영역에 nop처리 된 부분에 원래의 api함수로 채워넣고 안티 디버깅 기술이 걸렸다면 여기서 걸릴 뿐더러 안걸릴 경우 code 영역으로 들어가 정상적인 코드 실행까지 하게 됩니다. 저 JMP문으로 들어갔을 때의 동작방식을 알아봐야겠군요. :-)

그리고....
VM Entry를 들어왔을 때

이 부분 저 부분에서 ESI가 가리키는 메모리 영역에서 1Byte씩 al로 가져옵니다. 또한..

이 부분하고 1:1로 한번씩 번갈아가면서 실행... 핸들러 수행이 끝나면 LODS 명령어로 점프를 하게 됩니다.
JMP문은 그 가상화된 명령어를 수행하기 위한 핸들러를 호출하는 부분이구요.

그러면 저기서 LODS했을 때의 AL(1)과 JMP문의 EAX(2)가 같냐? 그건 아닙니다. 뭐 같은 필요는 없겠죠. 꼬아놨다면요.
하지만...!! 값이 다르더라도 1:1 매치가 되면 좋지만 1:1 매치가 아닙니다. 다대다 관계 더군요. 즉..!

(1)이 2c,f9,f6이 나왔을 때
(2)는 62 만 계속 나올 때도 있습니다.

그 반대의 경우도 마찬가지구요.

(2)가 62일 경우 (1) 값을 계속 뽑아 50개를 뽑아봤는데.. 규칙이 없습니다.

그래서 트레이스해본 결과 수행되는 루틴이 다를줄 알았는데 (1)에서 (2)로 가는데 까지의 루틴은 항상 같습니다.
중간에 메모리에 있는 값을 가져와 연산을 수행하는 부분에서 달라지겠군요. 이 부분도 자세히 분석을 해봐야겠군요.

조금 더 자세히 분석해본 결과
(1) 의 값은 도데체 어디에 영향을 미치는지는 잘 모르겠습니다.
(1) 값은 핸들러 Index를 만드는 과정에 영향을 끼치지는 않더군요.

그러면 핸들러 인덱스를 누가 만드느냐??
위위 그림에서 PUSH EBX를 하고 있는데 저 EBX의 BL 값에 의해 인덱스가 만들어집니다.
그러면 BL값 또한 무작위인데 핸들러 인덱스가 같은 경우도 있지 않냐?? .. 라고 의문을..?

바로
BL + Handler Index
의 계산으로 인해 만들어집니다...만;;
이게 전부는 아닌 것 같군요. 특정 핸들러가 수행되면 EBX값이 BL부분만 바뀌는게 아닌 EBX 전체 값이 바뀌어버리게됩니다.
더 이상은 너무 시간이 걸려 ....

아래는 분석 결과..
a = push ebx할 때의 bl 값
b = jmp할 때 handler index
c = jmp루틴 왔을 때 바뀐 bl값

전부다는 아니지만
c == a + b
가 성립하고 있는 것을 알 수 있습니다.

BL(a) AL(b) BL(c)

--------------------------

8E A9 37

37 B5 EC

EF 62 51

51 55 A6

A6 39 DF

C8 B5 7D

83 62 E5

E5 3D 22

22 B5 D7

DD 62 3F

3F 60 9F

9F 8A 29

2C 62 8E

8E A9 37

37 B5 EC

EC 62 4E

4E 60 AE

AE 62 10

10 55 65

65 A9 0E

0E 39 47

'My Study > Reversing' 카테고리의 다른 글

백신 Avast의 Anti-attach 우회하기 (8)	2012/04/19
NtSetInformationThread 를 이용한 Anti-Debugging (0)	2012/04/17
Themida 2.1.2.0 Virtual Machine (7)	2012/02/01
ARM CPU 공부시작.. ㅠ_ㅠ (6)	2012/01/25
Code Virtualized (7)	2011/06/27
ZwSetSystemInformation (2)	2011/01/11

ipad 사용자 권한

Ezbeat — Fri, 27 Jan 2012 18:08:13 +0900

ios5에서 어플 디버깅을 하지못해 애 먹고 있던 도중 그냥 재미난걸 보았습니다.

현재 제 ipad 에 있는 passwd 파일입니다.

중요한건 root 계정과 mobile 계정입니다.
이번엔 현재 실행 중인 프로세스를 봐보겠습니다.

제가 ipad에서 오목 어플을 켜봤는데 해당 오목 어플은 mobile이라는 계정의 권한으로 실행이 되게 됩니다.
뭐 당연히 어플들이 root 권한으로 실행되면 안되겠죠.

그러면 저 어플을 root 권한으로 실행시키면?? 당연히 mobile 권한으로는 해당 어플을 끌 수가 없을 것입니다.
Operation not permitted 라는 오류가 납니다.

일단 root 권한으로 저 GomokuOnline 프로그램을 켜보겠습니다.

켰습니다. 하지만 ipad 화면이나 아래 bar에는 오목 어플이 없습니다.

이렇게 말이죠. 하지만 분명히 root 권한으로 실행은 시켰으니 메모리에 올라와 있긴 할 겁니다.
아직 mobile 계정에서 처리를 못한 것이지요. 여기서 ipad로 해당 어플을 켜줍니다.

그러면 mobile에서는 새로 어플리케이션을 실행하는 것이 아닌 이미 GomokuOnline 프로그램은 프로세스 목록이 있으니
어플리케이션을 그냥 ipad 화면에 보여주기만 할 것입니다. 이제 ipad 화면에 보이는 오목 프로그램은 root 권한으로
실행되고 있습니다.

ipad 에서 끌 수 있을까요?? 절대 못끕니다. 왜냐하면 mobile 계정은 root 가 실행시킨 프로그램을 끌 수 없기 때문이죠.

뭐 당연한거겠죠.
이럴 때가 아니라 ios5에서 gdb를 써야하는데 애를 먹네요. ㅠ

아.. 끌 때는 그냥 root 계정으로 프로세스 kill 해줌 됩니다. =_=;;

'My Study > etc' 카테고리의 다른 글

Melon Crack은 나쁜 것 (5)	2012/04/16
TIOBE 프로그래밍 인기 순위 (2)	2012/02/02
ipad 사용자 권한 (0)	2012/01/27
바로가기 (2)	2011/07/31
PC로 카톡 쓰기~ (8)	2011/05/30
UHA 확장자 (0)	2011/05/27

ARM 명령어 공부

Ezbeat — Fri, 27 Jan 2012 00:31:37 +0900

ipad2에는 A5라는 CPU가 탑제되어 있습니다

ARM 회사에서 만들었기 때문에 리버싱을 하려면 당연히 ARM CPU에 대해서 적당한 지식이 있어야합니다.
여기선 조금씩 알아보고 더욱 자세한 내용은 ARM CPU 문서들을 참고해주세요~

ARM CPU는 내부적으로 32Bit의 데이터 버스와 32Bit의 어드레드 버스를 제공합니다.
또한 잘 알려져 있듯이 ARM은 대표적인 RISC 코어입니다.

RISC 설명
http://terms.co.kr/RISC.htm

즉, ARM의 명령어는 그 종류가 적으면서도, 다양하게 적용시킬 수 있는 특징이 있습니다.
하나씩 알아보면서 느껴보도록 하죠.

ARM 구조
1. 레지스터
ARM은 31개의 32Bit 범용 레지스터가 있습니다. 또한 동작모드에 따라는 6개의 Status 레지스터도 있습니다.

2. ALU
32Bit 연산이 가능한 ALU가 제공됩니다. ARM의 ALU 장점으로는 보통 다른 CPU에서는 shift 명령이 따로 있었는데, ARM에서는 따로 존재하는 것이 아닌 대부분의 명령에서 옵션으로 적용시킬 수 있습니다. ( Barrel Shifter )

3. Booth's 곱셈기
곱셈 기능을 제공하는 32Bit Booth's 곱셈기가 있습니다. 곱셈기는 32Bit 연산을 지원하며, 32Bit의 두 입력을 받아서 곱하여, 결과가 32Bit를 넘더라도 넘는 부분은 버리고 32Bit만을 남깁니다.

ARM의 레지스터
위에서 모두 32Bit인 31개의 범용 레지스터와 6개의 상태레지스터가 있다고 했습니다.
하지만 ARM 어셈블러에서 사용하는 범용 레지스터 키워드는 r0~r15까지 16개밖에 되지 않습니다. 즉, 다시 말해서 사용자가 한번에 사용할 수 있는 레지스터는 16개입니다. 그 중에 몇개는 프로그램 카운터(PC) 스택 포인터(SP) 등의 용도로 사용됩니다. 그러면 그 나머지는?? 나머지 레지스터는 CPU 동작모드와 관련되어 r0~r15로 리-맵핑되어 사용됩니다.

1. Special Purpose General Register
위에서 사용자가 프로그램 할 때 레지스터 지정을 위해 사용할 수 있는 키워드는 r0~r15 입니다. 그 중에 특별한 목적을 위해 사용되는 레지스터를 알아보겠습니다.

- Program Counter ( r15 )
r15는 다른 CPU에서와 마찬가지로 PC 와 같은 역할을 합니다. 다만 차이점이 있다면 r15를 일반 다른 레지스터처럼 오퍼랜드로 사용할 수 있다는 점이고 ARM 어셈블러에서는 pc라는 키워드와 r15를 동일하게 취급합니다.
* Intel CPU 어셈블러에서는 오퍼렌트로 PC와 같은 역할을 하는 EIP 레지스터를 오퍼렌드로 사용할 수 없습니다.

- Stack Pointer ( r13 )
ARM 에서는 Stack을 위한 명령어가 따로 없습니다. 즉, Push나 Pop 등의 명령어가 제공되지 않습니다. 그러나 sp라는 키워드를 사용하여 r13을 쓸 수 있는데, 묵시적으로 r13을 스택포인터로 사용할 수 있도록 정해 놓은 듯 합니다. 그리고, Push, Pop 같은 명령어가 없으므로, ARM에서는 같은 기능을 일반 데이터 전송 명령을 통해 해결합니다. ARM 의 데이터 전송명령은 Auto Increment 기능이 있어서 하나의 인스트럭션으로 Push나 Pop과 동일한 기능을 수행 할 수 있습니다.
( 라고 제가 읽는 문서에서는 설명을 하였지만.. 실제로 현재 최신 ARM CPU는 지원을 합니다.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204ik/Babefbce.html
위 링크를 따라 가보시면.. ;; )

- Link Register ( r14 )
r14는 링크 레지스터라고 부릅니다. 이 레지스터는 Intel CPU에서 보지 못했던 기능의 레지스터인데요. Intel CPU등의 CPU에서는 서브루틴을 호출할 경우 CALL을 사용하면 다음에 수행될 PC를 스택에 넣고, 호출될 번지를 PC에 넣는 동작을 하게됩니다. 하지만 ARM에서는 CALL과 RET와 같은 명령이 없습니다. 대신 Branch With Link라는 명령(BL)이 있는데, 해당 명령을 수행하면, CALL과 비슷하게 다음에 수행될 pc(r15) 값을 스택이 아니라 lr(r14)에 넣고 분기 번지를 pc(r15)에 넣어 분기합니다. 즉, 스택을 사용하지 않는 것이지요. 복귀할 때는 RET 대신 mov pc,lr 이라는 데이터 전송명령으로 복귀합니다.

이러한 방식은 나름대로 장단점이 있습니다.
단점
어떤 서브루틴이 콜 되었을 때, 서브루틴에서 복귀번지가 r14에 들어있는 상태가 됩니다. 문제는 해당 서브루틴에서 다시 한번 다른 서브루틴을 콜 한다면, 원래 r14에 보관되어 있던 복귀 번지 값이 덮어씌워지는 결과가 생깁니다. 이런 경우엔, 수동으로 sp(r13)를 이용하여 스택에 r14 값을 보관해 두어야 합니다. 즉, 분기(BL) 하기전에 r14를 스택에 보관해 두고, 리턴해서 복구하는 과정을 거치는 셈

그러면 왜 굳이 이러한 방법을 쓸까요?? 여러번 분기(BL)하는 경우가 아닌 한번만 분기(BL) 하는 경우라면, 스택을 사용하지 않고 레지스터를 사용함으로써, 그 속도에서 이익을 얻게 되는 것!

또한 분석가 입장에서 보면 CALL, RET 명령어가 없어서 가독성 면에서 떨어질 것 같습니다. 이건 저도 아직 경험해 보지 않은 것이지만 이렇게 이론적으로 공부하더라도 그럴 것 같네요.

2. ARM Status Register
위에서 Status 레지스터는 32Bit 짜리 레지스터 6개가 있다고 했습니다. 그러나 6개 모두를 한꺼번에 사용하지는 못하고, 또 그럴 필요도 없습니다. 일단 하나의 32Bit Status 레지스터만 생각하면 됩니다.

Status 레지스터는 PSR이라고 부릅니다. 그리고 일반적으로 CPSR이라고 하여 Current Program Status Register라고 부릅니다. PSR은 크게 Flag Bits부분과 Control Bits 부분으로 나뉩니다.

- Flag Bits
어떤 인스트럭션의 결과 등을 나타내는 부분으로 4Bit가 있습니다. 다른 CPU의 Flag Register와 비슷한데 각각 N, Z, C ,V의 4가지 입니다.

1) Negative/Less Than Flag
N으로 표기되는 이 플래그는 연산의 결과가 마이너스인 경우에 세트됩니다.
2) Zero Flag
Z로 표기되는 이 플래그는 연산의 결과가 0이 되었을 경우에 세트됩니다.
3) Carry/Borrow/Extend Flag
C로 표기되는 이 플래그는 자리올림이나 내림이 발생한 경우, 그리고 Shift 연산 등에서 사용됩니다.
4) Overflow Flag
V로 표기되는 이 플래그는 연산의 결과가 오버플로우 되었을 경우 사용됩니다.

이상의 Flag Bit들은 다른 칩의 상태 레지스터와 다르지 않습니다.

- Control Bits
컨트롤 비트들은 인터럽트를 제어하는 비트와 계속해서 언급되기만하고 실체를 드러내지 않고 있는 Exception과 관련된 CPU 동작모드를 설정하거나 확인할 수 있는 기능을 가진 Bit가 있습니다.

1) IRQ/FIQ Disable Bit
ARM 인터럽트 중에서 IRQ와 FIQ를 금지시킬 수 있는 클래그입니다. 인터럽트의 종류는 이밖에도 몇 가지가 더 있는데, 그 중에서 IRQ, FIQ는 PSR를 통해 금지시키거나 가능하도록 설정할 수 있습니다.
2) Mode Bits
M0에서 M4까지의 모드 비트는 CPU의 6개의 동작 상태를 나타냅니다. 즉, 간단히 말하면 ARM은 6개의 동작 모드를 가지는데, 이를테면 User모드와 인터럽트 모드 등입니다.

이제 상태 레지스터를 그림으로 봐보겠습니다.

지금까지 레지스터를 알아보았는데 Exception 관련된 부분은 필요할 때 추후 올리겠습니다.

이번엔 Instruction Set을 알아보도록 하죠.

ARM 명령어 특징
ARM은 32Bit 코어입니다. 특징적인 것은 모든 명령어가 32Bit 하나의 Word로 구성된다는 것입니다. Intel CPU 경우엔 명령어에 따라 대략 1Byte~7Byte까지 있습니다. 하지만 ARM은 모든 명령어를 한 Word로 처리합니다. 일단은 명령어의 개수가 몇 안되고, 주소는 상태주소 방식을 사용하며, 심지어 Immediate 상수 값도 32Bit 값을 그대로 넣을 수 없습니다.
만약 r0에 32Bit 상수를 넣고 싶다면, 몇몇 예외를 제외하고는 메모리에 미리 넣어두고 해당 메모리를 상태 주소로 참조해서 얻어와야 한다는 뜻입니다.

역시 장단점이 있습니다.
장점
모든 명령어를 같은 사이즈로 처리함에 따라 파이프라인 구현이 용이하다는 점이 있습니다. 그리고 명령어 해석기를 설계할 경우 예외 처리부분이 없으므로, 쉽고 고속으로 처리할 수 있겠지요.

단점
코딩 시에 몇몇 제한이 따른다는 점 입니다. 상대 주소 지정 방식은, 이 때 사용하는 Offset이 24+2=26Bit 이므로, 상대주소라고는 하지만 거의 불편이 없고, 다만 Immediate 오퍼랜드를 지정할 경우에 좀 번거롭다는 점이 있습니다. 그러나 8Bit 해상도를 가지는 오퍼랜드라면 한 Word 내에서 처리가능 합니다.

ARM 명령어의 다른 특징으로는 모든 명령어를 조건적으로 실행시킬 수 있다는 것입니다. 예를 들어, Intel CPU에서는 jz, jc와 같은 점프 명령어를 사용합니다. 그 의미는 jz 같은 경우 zf가 설정되어 있으면 점프를 해라, 혹은 jc같은 경우는 cf가 설정되어 있으면 점프를 해라. 라는 의미입니다. 무조건 점프시에는 jmp를 쓰지요.

ARM의 경우엔 그런 플래그의 사용이 점프 명령에 국한되지 않고, 예외 없이 모든 명령어에 사용할 수 있습니다.

위의 경우를 보시면 jmp에 해당하는 B명령 뿐만 아니라 MOV 와 같은 데이터 전송명령에도 플래그 옵션을 사용했음을 볼 수 있습니다.

삼항 연산자로 예를 들어보겠습니다.
a = (b==c) ? d:e;
의미는 b와 c가 같으면 d를 a에 넣고 다르면 e를 a에 넣는 것입니다.

일단 Intel CPU에서는??

이와 같이 됩니다. ARM CPU를 봐보도록 하겠습니다.
제 ipad2 에서 gcc로 컴파일 할 경우 최적화 문제 때문에 원하는 표현이 잘 안나오는 것 같지만
ARM CPU의 명령어를 사용하면

CMPS r2,r3
MOVEQ r1,r4
MOVNE r1,r5

이렇게 짧게 표현 가능합니다. 중요한 것은 Intel CPU에서는 점프문은 꼭 필요한 반면 ARM CPU에서는 점프문이 꼭 필요하진 않습니다.

다시 한번 강조하지만 ARM에서는 이와 같은 조건 옵션을 모든 명령어에 사용 가능합니다. 실제로 모든 OP 코드의 상위 4Bit는 이런 조건 옵션을 나타내는데 사용되는 비트입니다. 각 조건에 사용되는 접미사 목록입니다.

총 15개로 15 = 1111b 딱 4Bit 맞군요. 다 외울 필요는 없고 여기에서는 그냥 이런 것들이 있구나 하는 정도면 알면 됩니다.
필요할 때 보면되기 때문이죠. 명령어를 볼 땐 명령어에서 다 문자로 표시줍니다.

다음 특징은 대부분의 명령어에 S라는 접미사를 사용하여 플래그 레지스터에 영향을 줄지 여부를 결정할 수 있다는 것입니다. 특히 연산명령을 수행할 때 'S' 를 붙히면 해당 결과에 따라서 플래그 값들이 변하게 되고, 붙히지 않으면 영향을 미치지 않도록 할 수 있습니다. Intel CPU에서는 연산의 결과에 따라 항상 플래그 값이 영향을 받는거와는 다르군요. 사실 이러한 점 때문에 Intel CPU에서는 특정 연산을 수행시 Push , Pop을 사용해 레지스터를 스택에 저장해 두고 연산이 끝난 후 다시 빼오는 방법을 사용하는데.. 귀찮습니다.

● Branch and Branch with link (B, BL)

Cond 부분은 위에 있는 조건 옵션입니다. 101은 B 명령 코드입니다.
L 부분은 1일 경우 BL이 되는 것이고 0이면 B 명령입니다. B는 JMP라고 생각하시면되고, BL은 CALL로 생각하시면 됩니다.
다만 BL의 경우엔 PC값을 스택에 넣는 것이 아니라 r14(lr)에 넣는다는 것에 차이가 있습니다. 나머지 하위 24Bit가 Offset으로 사용되는데 ARM은 모든 명령어들이 Word 단위 이므로 총 +/- 32MB 영역을 커버합니다.

● Data Processing Instruction
데이터 프로세싱 명령은 ARM의 50% 정도에 해당하는 명령입니다. 실제 개수는 16개이고, 연산명령, 비교명령, 비트 연산 명령, 데이터 전송 명령 등이 포함됩니다.

1) <Cond>
해당 명령의 조건 실행 플래그입니다. 데이터 프로세싱 명령어에도 당연히 포함됩니다.
해당 플래그를 통해 명령을 현재 플래그 레지스터(CPSR)의 상태에 따라 실행 여부를 결정하는데 사용되는 플래그입니다.

2) <I>
Operland 2로 지정되어 있는 부분이 Immediate Operand 인지 아닌지 여부를 나타내는 비트. Immediate Operand라 함은, 예를 들어 Intel CPU에서 MOV AX, 01234h 라고 했을 경우 1234h를 가리키는 말입니다.

3) <OpCode>
데이터 프로세싱 명령 중 어떤 명령인지를 나타내는 필드. 해당 필드와 명령어는 다음과 같습니다.

4) <S>
S 비트가 1인 경우는 데이터 프로세싱 명령의 결과가 CPSR에 영향을 미칩니다. 즉, 0인 경우에는 CPSR은 변하지 않습니다.

5) <Rn>
ARM 데이터 프로세싱 명령은 그 결과와 첫 번째 오퍼랜드는 항상 레지스터로 지정해야 합니다. Rn은 첫 번째 오퍼랜드를 가리키는 것으로 위에서 Op1으로 표기한 것에 해당합니다. ARM에서 한번에 볼 수 있는 범용 레지스터는 sp, lr, pc 등을 포함해서 r0~r15까지입니다. 즉, 4Bit를 통해 레지스터를 나타내게 됩니다. 해당 필드는 명령에 따라 사용되지 않기도 합니다. MOV나 MVN등이 이에 해당합니다.

6) <Rd>
오퍼레이션의 결과가 저장될 레지스터를 의미합니다. 역시 레지스터를 가리키므로 4Bit를 사용하고 모든 명령에서 디폴트로 사용되는 필드. ARM의 데이터 프로세싱 명령의 결과는 항상 레지스터로 들어갑니다.

7) <Operand 2>
Immediate Operand 혹은 레지스터 Operand 입니다. <I> 필드가 0일 경우 레지스터 입니다. 이에 관해선 많은 설명이 있지만 일단 여기까지만... 필요하면 추후..;

이제 조금 더 명령어의 세부 비트 개념이 아닌 관점을 명령어를 읽는 것에 초점을 맞춰보겠습니다.

1. MOV{cond}{S} Rd, Op2
Assembler에서 가장 기본적으로 사용되는 데이터 전송명령입니다. ARM에서의 MOV는 다른 칩의 MOV와 비슷하지만 그 Target이 되는 부분이 항상 레지스터라는 점 입니다.
즉, Intel CPU같은 경우 아래 두 명령어 처리가 가능하지만
MOV EAX,[EBX]
MOV EAX,EBX

ARM같은 경우는 첫 번째는 처리할 수 없는 명령어 입니다. 즉, 레지스터나 Immediate 값 같은 것들을 레지스터에 넣는 명령입니다. 참고로.. Target 레지스터가 PC인 경우 S옵션을 사용하면, Exception 모드에서 보통 상태로 빠져 나오는 역할을 하게 됩니다. 예시 코드를 보겠습니다.

MOV r0,r1
단순히 r1에 있는 내용을 r0에 넣는 것입니다.

MOV r0,#0
r0에 상수 0을 넣는 명령입니다. ARM에서는 상수에 #을 붙혀서 사용합니다. 또 진법 표현은 C에서의 방법을 사용합니다. 즉, MOV r0,#0x30 이런 식으로 사용할 수도 있습니다. 혹은 &을 붙여서 16진수를 나타낼 수도 있습니다.

MOV r0, #0xfc000003
r0에 상수 값 0xfc000003을 넣는 명령입니다. 해당 값은 8Bit 값 0xFF를 32Bit로 확장하고 오른쪽으로 두 번 Rotate 시킨 값입니다. 그래서 에러가 나지 않습니다.

MOV r0, r1, LSL #1
r1을 왼쪽으로 1bit Shift한 값을 r0에 넣는 것입니다. LSL( Logical Shift Left )

MOV r0, r1, LSR r2
r1을 r2 만큼 오른쪽으로 Shift 한 값을 r0에 넣는 명령입니다. LSR ( Logical Shift Right )

MOV r0, r0, ASR #24
r0을 오른쪽으로 24bit 만큼 Shift 한 값을 r0에 넣는다. ASR ( Arithmetic Shift Right )
LSR와 차이점은 최 상위 비트가 1인 경우 새로 계속 해당 비트 값을 유지시킨다는 것입니다.
LSR 같은 경우는 새로 들어오는 최상위 비트는 항상 0입니다.

MOVS r0, r1, LSR #1 ; C(flag) = r1[0]
MOVCC r0, #10 ; if C == 0 then r0 = 10
MOVCS r0, #11 ; if C == 1 then r0 = 11
r1을 오른쪽으로 1bit Shift 한 값을 r0에 넣는다. 이 때 연산의 결과가 플래그에 영향을 미치도록 하기 위해 S를 붙힌 것이다.
만약 Carry Flag가 셋팅 됬을 때와 안됬을 때의 차이로 r0에 넣는 값이 달라진다.

MOVS r0, r4 ; if r4 == 0 then r0 = 0
MOVNE r0, #1 ; else r0 = 1
r0에 처음에 무조건 r4 값이 들어가고 MOVNE에서 r4 값이 0이면 0과 1은 다르므로 false로 MOVNE문은 실행되지 않습니다.

2. MVN{cond}{s} Rd, Op2
이 명령어는 Rd = NOT Operand2 의 의미를 가진 명령입니다. 기존 어셈블러에서는 볼 수 없던 명령이죠. 기능은 MOV 처럼 값을 넣긴 넣는데 NOT을 해서 넣는 명령입니다.

MVN r0, #0 ; r0 = -1
0을 NOT 하면 FF..FFF 이므로 -1 이 되게 됩니다.
또한 MOV r0, #0xFFFFFFFF 이렇게 하면 에러가 발생합니다. ARM의 모든 명령이 32bit 한 word이고 Immediate 어포랜드처리를 8bit 값을 Rotate 시키는 방식으로 사용하기 때문인데, MVN을 사용함으로써 해당 값을 넣을 수 있습니다.

3. ADD{cond}{S} Rd, Rn, Op2
ADC{cond}{S} Rd, Rn, Op2
더하기 명령입니다. Intel CPU와 차이점은 오퍼랜드를 3개 지정한다는 것입니다. Rd 는 결과가 저장될 레지스터로, Data Processing 명령 모두는 그 결과가 Rd로 들어가야만 합니다. 나머지 두개가 서로 더해질 오퍼랜드 입니다. 두개의 오퍼랜드 중 하나는 또 항상 레지스터여야만 합니다. Op2는 Shifted Register 혹은 Immediate Value 중 하나입니다.

ADD r0, r0, #1 ; r0 = r0 + 1
r0에 1을 더한 후 그 값을 r0 넣는 것입니다.

ADD r0, r1, r2 ; r0 = r1 + r2
생략..

ADDS r0, r1, r1, LSL #2 ; r0 = r1 * 5
알아서 유추... 모든 수의 <<1 은.. x2..

ADD r0, r0, r1 ; r0 = r0 + r1
MOV pc, lr ; return
r0 과 r1을 더해 r0에 넣고 리턴 하고 있습니다. 리턴 값은 r0 레지스터에 들어가게 됩니다.

4. SUB{cond}{S} Rd, Rn, Op2
SBC{cond}{S} Rd, Rn, Op2 ; Carry Flag와 관련되어 있는 명령
RSB{cond}{S} Rd, Rn, Op2
RSC{cond}{S} Rd, Rn, Op2   ; Carry Flag와 관련되어 있는 명령

위 네 명령은 빼기 명령입니다. R로 시작하는 명령은 Rn과 Op2를 바꿔서 명령하는 명령입니다. 즉,
SUB Rd, Rn, Op2 => Rd = Rn - Op2
RSB Rd, Rn, Op2 => Rd = Op2 - Rn

SBC Rd, Rn, Op2 => Rd = Rn - Op2 + Carry - 1

5. AND{cond}{S} Rd, Rn, Op2
EOR{cond}{S} Rd, Rn, Op2
ORR{cond}{S} Rd, Rn, Op2

이번엔 Bit 연산에 관련된 명령어들입니다.
AND => AND
EOR => XOR
ORR => OR

B 명령을 제외하고는 왠만한 명령어는 모두 3글자라서 ORR로 했나봅니다.

AND r0, r0, #0xFF
r0과 0xFF를 and 연산 후 그 결과를 r0에 넣습니다. r0의 8bit만 남기는 명령입니다.

ANDCSS r0, r1, ASR r3
만약 캐리플래그가 설정되어 있다면 r0 = r0 AND ( r1 >> r3 ) 을 수행합니다. 계산 결과는 플래그에 영향을 미칩니다.

EORS r0, r0, r0
r0 = r0 XOR r0 을 수행하는 명령인데 r0을 0으로 만들고 NF는 0, ZF는 1로 만듭니다.

MOV r0, #0xFF
ORR r0, r0, #0xFF00
최종적으로 r0을 0xFFFF를 만드는 과정입니다.

6. BIC{cond}{S} Rd, Rn, Op2
Rd = Rn AND (NOT Op2) 로 설명이 되어 있는 명링입니다.

BIC r0, r1, #3
r0 = r1 AND 0xFFFFFFFC 의미입니다.

7. CMP{cond} Rn, Op2
CMN{cond} Rn, Op2

비교 명령입니다. MOV, MVN처럼 인수가 2개이지만 Rd가 없습니다.
CMP는 우리가 알던 CMP명령입니다. Rn에서 Op2를 빼 보는 명령이죠. 해당 명령은 레지스터에는 영향을 미치지 않고 플래그에만 영향을 미치는데 이 명령어들은 S 옵션이 없어도 디폴트로 S 옵션을 준 효과가 나타납니다. S 옵션마저 꺼지면.. -_-
Nop 같은 명령어가 되는건가요?? ㅎ

CMN은 CMP와 반대로 두 오퍼랜드를 더해보는 명령입니다.

CMP r2, #23
MOVEQ r2, #45
만약 r2가 23이면 45를 넣어라..

CMP r0, #0
CMPEQ r1, #0
CMPEQ r2, #0
CMPEQ r3, #0
MOVEQ r4, #12
r0부터 r3까지 모두 0이라면 r4에 12를 넣는 명령

CMN r1, r2
MOVEQ r0, #0
MVNNE r0, #1
r0 = (r1 + r2) == 0 ? 0, -1 이라는 의미.. 영어 해석 같네요.. -_-;

8. TEQ{cond} Rn, Op2
TST{cond} Rn, Op2

CMP와 거의 비슷한 구조를 갖는 명령입니다. 기능도 거의 유사..
CMP가 빼기, CMN가 더하기라면
TEQ는 XOR, TST는 AND 연산을 통해 같은 일을 합니다.
하지만 특징이라면 Logical 연산이 일어날 경우 플래그 중에서 VF(Overflow)는 영향을 받지 않습니다.

CMP r0, #31 ; r0 <= 31
TEQ r0, #127 ; r0 == 127
MOVLS r0,#'.' ; if either then r0 ='.'

TST r1, #3
MOVEQ r0, #1
MOVNE r0, #0
r0 = (r1 & 3) == 0 ? 1 : 0 이러한 의미 같습니다.

● PSR Transfer
PSR이란 Program Status Register 로서 플래그 비트와 Control 비트들로 구성된 레지스터 입니다. 해당 레지스터의 값을 일반 레지스터로 옮기거나 반대의 일을 하는 명령이 PSR Transfer 명령입니다.

PSR은 32Bit 레지스터입니다. CPSR, SPSR 5개를 합쳐서 총 6개가 있습니다. 여기서 SPSR은 Exception 모드에 따라 여분으로 존재하는 PSR을 말합니다. 실행 모드에 따라서 User가 접근할 수 있는 PSR은 한개, 혹은 2개로 제한됩니다. 예를 들어 User모드에서는 CPSR에만 접근 할 수 있고, IRQ모드에서는 CPSR과 SPSR_irp 에 접근할 수 있습니다.

아래 명령어는 그닦 쓸일이 없고 CPU 동작 모드를 임의로 설정하거나, 현재 동작모드를 확인하기 위해서 사용되는 경우가 있습니다.

1. MRS{cond} Rd,<psr> : Transfer PSR contents to a register
MSR{cond} <psr>, Rm : Transfer register contents to PSR
MSR{cond} <psrf>, Rm : Transfer register contents to PSR flag bits only

MRS명령과 MSR 명령의 의미가 애매할 수도 있습니다. M을 Move로, R을 레지스터로, S를 PSF로 파악하면 MRS의 경우엔 Move Reg PSR 정도로 생각할 수 있습니다. 즉, 레지스터에 PSR 값을 넣는 명령

예제 생략.. = _ =

● 곱하기 명령(MUL, MLA)
ARM에서는 곱하기 명령이 크게 두 종류가 있습니다. 하나는 그냥 곱하는 것이고, 다른 하나는 곱해서 더하는 것입니다.

1. MUL{cond}{S} Rd, Rm, Rs
이 명령에서는 레지스터만을 사용해야 합니다.

MUL r1, r2, r3 ; r1 = r2 * r3
참고로 곱하기의 결과가 32Bit를 넘는다면, 하위 32Bit만 결과 레지스터에 남습니다.

2. MLA{cond}{S} Rd, Rm, Rs, Rn
이번엔 레지스터가 4개 입니다.

Rd = Rm * Rs + Rn 의 의미 입니다.

● Single Data Transfer( LDR, STR )
해당 명령은 레지스터와 외부 메모리와의 데이터 전송을 담당하는 명령입니다. 무척 사용 빈도가 높은 명령. Intel CPU에서는 MOV 하나로 레지스터간의 데이터 전송과, 외부메모리와의 데이터 전송의 두 가지 목적으로 사용하지만 ARM에서는 구분이 되어 있습니다.

즉, MOV 명령은 레지스터간의 전송명령, 데이터 처리명령으로 분류되고
LDR, STR은 데이터 전송명령으로 분류됩니다.

LDR은 Load라는 의미로 외부 메모리로부터 레지스터로 데이터를 읽어오는 명령이고,
STR은 Storage라는 의미로 레지스터로부터 외부 메모리로 데이터를 저장하라는 명령입니다.

1. LDR{cond}{B} Rd, address{!} ; Rd = Contents of address
LDR{cond}{B} Rd, =expression ; Rd = expression
STR{cond}{B} Rd, address{!} ; contents of address = Rd

LDR과 STR은 Single Data 전송 명령입니다. 비슷한 명령으로 LDM, STM은 여러 개의 레지스터 내용을 전송할 수 있는 명령입니다. 이 밖에 SWP라는 스왑 명령이 있는데, 해당 5개의 명령만이 외부 메모리와 레지스터간의 전송을 가능하게 하는 명령입니다.

LDR과 STR의 경우 전송 단위를 바이트, 혹은 워드(32bit)단위로 수행 할 수 있습니다.
바이트 단위 전송의 경우 해당 레지스터의 어떤 부분이 사용될지의 여부는 해당 프로세서의 Endian에 달려 있습니다.
또, 워드 전송 명령을 사용할 경우, 메모리 주소는 Word align이 되어야 합니다.

Endian 설명
http://ko.wikipedia.org/wiki/%EC%97%94%EB%94%94%EC%96%B8

아래 그림은 LDR과 STR에서 사용하는 전송 모드를 나타낸 것입니다.

1) Pre-Indexed Addressing Mode
이 모드에서는 Rn을 베이스 주소로 사용합니다. 여기에 더해서 Offset을 지정하거나, 혹은 지정하지 않을 수 있습니다. Offset을 사용할 경우에는 해당 Offset을 베이스 주소에서 더하도록 하거나 뺄 수 있는데, 위의 그림에서 +,- 기호가 그것을 나타냅니다.

LDR r0, [r1]
r1을 베이스로 사용하고 Offset은 지정하지 않은 형태입니다. r0에 r1을 번지로 하는 워드를 읽어드립니다.

LDR r0, [r1, #132]
Offset으로 132를 지정한 형태입니다.

STR r0, [r1, r2]
베이스는 r1, Offset은 r2를 사용한 형태입니다. 즉,
*(r1 + r2) = r0
사람 해깔리게 우 => 좌가 아닌 이 명령어는 좌 => 우 네요..;

LDR r0, [r1, r2, LSL #2]
베이스 r1, Offset은 r2 << 2 의 형태

이번에는 Write-Back 기능입니다. LDR 명령의 경우 옵션으로 Write-Back을 지정할 수 있는데, 지정할 경우 원래 베이스에 Offset을 더한 값을 다시 베이스 레지스터로 넣는 기능을 합니다.

STR r2, [r0, #-4]!
r2 = *(r0 - 4)
r0 = r0 - 4
이와 같은 의미가 됩니다. Offset을 적용 시켜서 먼저 명령어를 수행 한 후 베이스 주소와 Offset을 더해주는 것이죠.
아무튼 여기서 Pre-Index Mode이기 때문에 실제 주소를 구할 때 Offset을 먼저 빼준 것입니다.

2) Post-Indexed Addressing Mode
Post 인덱스 모드의 경우에는 Pre 인덱스 모드에 비해 Effective Address는 항상 Rn, 즉, 베이스 주소를 나타내는 레지스터의 값입니다. 그리고 한가지 알아두어야할 것은 Post 인덱스 모드의 경우엔 따로 !를 사용하지 않더라도 이폴트로 Write-Back 모드가 사용됩니다. Post인데 Write-Back이 안된다면, Offset을 사용할 이유가 없군요.

LDR r0, [r1], r2
대괄호의 사용이 Pre 인덱스의 경우와 다릅니다.
r0 에다 r1을 주소로 하여 값을 읽어오고 다시 r1에는 r2를 더해주는 일을 합니다.

3) Relative Addressing Mode
해당 Addressing 모드는 어셈블러가 적절히 지원하여 변환해 주는 모드라고 생각하면 됩니다.

LDR r5, ThreeCubed
ThreeCubed DCD 27

위와 같은 경우 실제로는
LDR r5, [PC, #constant]
형태의 코드로 번역해 줍니다. 즉, PC를 베이스로 삼아서 코드를 만드는 것이지요. 만약 해당 Symbol이 지정하는 범위가 너무 커서 상수로 지정할 수 없다면 어셈블을 할 때 에러를 내게 됩니다.

LDR r0, =0x12345678
이 경우 어셈블러가 해당 상수 값을 특정 공간에 모아서 삽입 해 주고(이 공간을 Literal Pool 이라 하는군요.) 역시 마찬가지로 PC를 베이스로 해서 명령코드를 만듭니다.

● Block Data Transfer 명령(LDM, STM)
해당 명령은 LDR, STR과 마찬가지로 실제 메모리에 레지스터의 내용을 전달하거나, 전달받을 수 있는 명령입니다.
LDR 명령이 메모리 번지의 내용을 지정된 레지스터로 가져오는 명령이라면 LDM은 가져오긴 하는데, 여러 개의 레지스터의 내용을 한 큐에 가져오는 명령입니다. 가장 많이 사용되는 경우는 스택 연산인 것 같습니다. ARM에는 Push, Pop 명령이 없습니다. 대신 LDR이나 STR을 쓸 수도 있겠고 ,또 LDM, STM을 쓸 수도 있죠.

push eax
push ebx
push ecx
push edx
와 같은 Intel CPU 명령이 있다면

ARM Single 데이터 전송 명령으론..
STR r0,[sp],#-4
STR r1,[sp],#-4
STR r2,[sp],#-4
STR r3,[sp],#-4

ARM Multiple 전송 명령으론..
STMEA sp!,{r0,r1,r2,r3}

{ Reg_List }
중괄호 사이에 전송 대상이 되는 레지스터를 넣어주면 됩니다.
ARM 에서 한 시점에 사용할 수 있는 레지스터의 개수는 r0~r15까지 총 16개입니다.

또한 LDM 명령의 니모닉상에 16bit의 공간이 있어서 각 비트가 레지스터 r0~r15와 1:1대응이 된다는 사실입니다.
따라서 { Reg_List }에는 어떠한 레지스터의 조합도 올 수 있습니다.

{r3,r2,r1} 과 {r1,r2,r3}를 했을 경우 메모리에 저장되는 순서는 같습니다. 위 이유 때문..

위 Multiple 전송 명령에서 STMEA라고 적었는데 EA가 동작모드를 지정하는 부분입니다. 이와 같은 키워드가 8가지가 있고, 동작모드는 4가지가 있습니다.

여기서 동작모드는 여러 개의 레지스터 값을 메모리로(로부터) 전송할 경우 해당 메모리 번지를 증가시키면서 저장할지, 혹은 감소시키면서 저장할지를 지정하는 것과, 증/감을 하는데, 저장하기 전에 증/감을 할지, 아니면 저장하고나서 증/감을 할지를 지정하는 것을 의미합니다.

STMFD/LDMFD : Full Desending Stack ; ARM 컴파일러가 사용하는 스택
STMFA/LDMFA : Full Ascending Stack
STMED/LDMED : Empty Descending Stack
STMEA/LDMEA : Empty Ascending Stack

깔끔하게 그림 한장으로 보시겠습니다.

● Single Data Swap

1. SWP{cond}{B} Rd, Rm, [Rn]
레지스터를 3개 지정하도록!. 실제 동작은 Rd = [Rn], [Rn] = Rm이 한번에 일어나는 명령
B는 Operation이 아니라 Byte Operation을 의미합니다.

SWP r0, r1, [r2] ; r0 = [r2], [r2] = r1
SWPB r2, r3, [r4] ; r2 = [r4], [r4] = r3 Bit 0~7까지만 영향을 미침

● Software Interrupt

1. SWI{cond} <expression>
SWI는 소프트웨어 인터럽트 명령입니다. SWI 명령이 걸리면 동작모드가 변화합니다. Supervisor 상태로 진입을 하게 됩니다. 이러한 특성 때문에 pSOS의 경우는 System Call의 진입방법으로 사용합니다.

pSOS 설명
http://en.wikipedia.org/wiki/PSOS

===========================================================================================
으아........... 대략 5시간의 시간을 걸쳐 겨우겨우 하나의 문서를 읽으면서 정리해보았군요.

이제 대충 ARM CPU에 대해 알았고 명령어들을 알아보았으니 실제로 프로그래밍을 해본다음 간단한 명령어들을 해석해보고 그만쓰겠습니다......... 제발!! 저장하기좀 누르고 싶네요 -_-ㅋㅋㅋ

간단히 두 수를 입력받아 합을 구해주는 프로그램 입니다.
main 함수 부분을 봐보겠습니다.

왼쪽은 실제 환경에서의 gdb로 봐본 결과이고 오른쪽은 Windows에서 IDA로 디스어셈블링을 해본 결과입니다.
차이점을 아시겠나요?? :-)

왼쪽에선 push, pop 명령어가 쓰인 반면 오른쪽에선 STMFD, LDMFD 명령어들이 쓰였습니다.
뭐 IDA에서는 최신 ARM 명령어를 지원안하나 보군요. 실제로는 push 명령어를 쓰고 어셈블러에서는 STMFD으로 바뀐다고..하는?!

위 스샷에서
GDB 버전은 6.3.50.20050815-cvs
IDA 버전은 6.1.1100421
이었습니다.

일일이 트레이스 해가며 디버깅을 해보려 했으나.. 왜 gdb에서 breakpoint가 안먹히죠..?
그냥 r 누르니까 bp를 다 무시해버리고 그냥 실행되네요.. 할 수 없이 그냥 코드만 보고 분석해봤습니다.

STMFD SP!, {R7, LR}
스택에 LR 레지스터 값 저장. main 함수 내부적으로 또 다른 함수 호출하므로
LR 레지스터에 값이 덮어 씌워지므로 그것을 막기 위함
저장되면
H |....|LR|R7| L
이런식으로 저장 된다.

ADD R7, SP, #0
스택 포인터를 R7 레지스터에 더하고 있다.;;

SUB SP, SP, #0x14
스택에 공간을 할당하고 있다. 스택은 높은 주소에서 낮은 주소로 자라기 때문에 ..

STR R0, [SP, #0x1c+var_18] => [SP, #4]
STR R1, [SP, #0x1c+var_1c] => [SP]
R0, R1 레지스터에 있는 값을 스택포인터에서 +4, +0 위치에 각각 저장한다.

LDR R3, =(aInputNumber - 0x2278)

ADD R3, PC, R3 ; "Input number : "

R3에 "Input number : " 문자열 주소를 가져온다.

MOV R0, R3 ; char *

BL _printf

문자열 주소를 첫 번째 인자로해서 printf를 호출

ADD R2, SP, #0x1C+var_10

ADD R12, SP, #0x1C+var_14
sp에서 +12, +8 위치에 떨어진 곳의 주소를 각각 R2, R12에 넣는다.
인자 값을 받기 위해 주소를 가져오겠지요.

LDR R3, =(aDD - 0x2290)

ADD R3, PC, R3 ; "%d %d"

"%d %d" 문자열 있는 주소를 R3로 가져옴

MOV R0, R3 ; char *

MOV R1, R2

MOV R2, R12

BL _scanf

각 인자 값 넣어주소 scanf 호출.. 뭐 이런식입니다.

이런 부분은 쉬운 부분이므로
아래는 각자 알아서...

그만 쓸래요! 으악!

'My Study > Programming&Theory' 카테고리의 다른 글

Calling Convention Process for AMD 64 Bit (4)	2012/04/02
Windows rand() 랜덤 비율 (0)	2012/02/14
ARM 명령어 공부 (2)	2012/01/27
BlockInput Function (3)	2012/01/20
My BSOD (2)	2012/01/08
SwapContext를 이용한 프로세스 찾기 (7)	2012/01/04

ARM CPU 공부시작.. ㅠ_ㅠ

Ezbeat — Wed, 25 Jan 2012 15:21:23 +0900

ipad2를 산지 어언 반년이상 지난 지금.. 방금까지 탈옥을 해본적이 없다. 사실 탈옥을 해보려고 했지만 패드를 산 이후 멋모르고 ios5로 업데이트를 시켜버리고.. 그냥 쓰고 있었다. 언젠간 탈옥 툴이 나오겠지..라는 마음을 가지고;;

뭐 카페를 뒤져보니 나왔더군요 ㅋ 설 담날이라 휴유증에 빠질찰나 마침 재미있겠다 싶어서 바로 탈옥을 했죠. 사실 탈옥해서 가장 써보고 싶은 것은 gdb로 app를 리버싱해보는 것이었습니다. cydia에 재미있는 툴들도 많지만 뭐 일단 제 우선순위에선 gdb에 밀려났습니다.

탈옥 후 openSSH를 설치하고 Xshell로 접속해보았습니다.

굿 입니다. 뭔가 설레이는 군요.

일단 디버깅에 필요한 툴들을 다운 받아줍니다. 간단히 apt-get을 사용해 설치하면 됩니다.

리눅스 커널 정보를 봐볼까요..

!!!!!!!!!! ARM이래요 ARM.... 흑흑.......

사실 지금까지 Intel CPU 리버싱 밖에 공부해 보지 않았기 때문에 기대반 두려움 반이었습니다.
그래도 포기는 하지 않습니다. 재미있으니까요 :-)

오늘은 디버깅 창 까지만 봐보겠습니다. 공부공부..;

이렇게 켜주시고.. 이제 ps 명령어로 프로세스 확인~

현재 GomokuOnline 이라는 프로세스인데 있는 폴더를 보면 Applications 폴더아래 막 이상한 시리얼 넘버같은 폴더로 들어오게 됩니다. 이와 같이 모든 어플리케이션은 저렇게 폴더가 따로 생겨서 설치가 됩니다. IFile 설치해서 보셔도 됩니다.

아무튼 gdb 로 attach~

성공적이군요. 레지를 봐보면~ ?!

역시 ARM...흑흑 ㅋㅋ

그리고 gcc를 설치해 천천히 ARM CPU공부를 해봐야겠네요.
gcc는 그냥 cydia에서 GNU C Compiler 설치하면 됩니다. ios5 기준..

이렇게.. - -잘 되네요.

gcc 버전
gcc version 4.2.1 (Based on Apple Inc. build 5555)

main 함수

일단 리버싱을 시작해봅시당..

'My Study > Reversing' 카테고리의 다른 글

NtSetInformationThread 를 이용한 Anti-Debugging (0)	2012/04/17
Themida 2.1.2.0 Virtual Machine (7)	2012/02/01
ARM CPU 공부시작.. ㅠ_ㅠ (6)	2012/01/25
Code Virtualized (7)	2011/06/27
ZwSetSystemInformation (2)	2011/01/11
User Callback Address (0)	2011/01/10

BlockInput Function

Ezbeat — Fri, 20 Jan 2012 16:57:23 +0900

BlockInput이라는 함수가 있다.
msdn의 친절한 설명을 봐보면..

Blocks keyboard and mouse input events from reaching applications.
그냥 키보드와 마우스의 입력 이벤트를 막는다고 되어 있다.

하지만 유일하는 먹히는 키 조합.. Ctrl + Alt + Del 키를 누르면 풀린다.
음.. 그래도 저 키조합도 막을 수 있는 방법을 구글에 찾아보면 소스코드도 포함된 글이 많다~

해당 함수는 인자로 BOOL 값을 하나 받는데.. 1이면 block하는 것이고 0이면 unblock하는 것이다.
Anti Reversing 기법으로 사용되는 함수이기도 하는데 밥 먹고 소화겸 어떻게 작동하는지 분석을 해보았다.

아 참고로.. 위 테스트 환경은 Windows XP SP3 이다.

user에서 BlockInput 함수를 호출하면 커널에서는 NtUserBlockInput 함수를 호출하게 된다.
딱 봐도 중요한 함수는 _BlockInput 함수 같다. 앞뒤로 있는 EnterCrit, LeaveCrit 함수는 저 부분을 감싸고 있는 걸로봐선 임계영역을 위한 함수들 같다. 함수 명만봐도..ㅋ

일단 _BlockInput 함수를 봐보자.

그렇게 길지도 않다.

일단 빨간색 네모 친 부분을 잘 보면 된다.

파란색 네모 친 부분에서는 gptiBlockInput 변수가 0인지 체크를 한다. 즉 현재 블록 상태인지 아닌지를 체크한다.
0이 라면 블록 상태가 아니라는 뜻이므로 보라색 명령어가 실행이되면서 esi에 있는 값이 들어간다.
그 값은 (0xe1df1008) 값이다. 하지만 저 값이 항상 일정하지는 않는 듯 싶다. 여러번 해보니 값이 바뀌는 것 같다.

아무튼 무슨 값이 gptiBlockInput 변수로 들어간다는 것이다.

하지만 gptiBlockInput 값이 0이 아니라면 분홍색 네모 친 부분이 실행된다. 먼저 esi와 비교를 하는데 같으면 그 아래 있는 분홍색 명령어를 실행함으로써 gptiBlockInput 변수 값을 0으로 만든다. 다를 경우에는 그냥 종료를 하게된다. 무슨 뜻이냐면 이미 블록이 풀려버렸다는 뜻이다. 왜..? Ctrl + Alt + Del 키를 눌러서 미리 풀어버린 경우에 저렇게 된다.

일단 gptiBlockInput 변수에 들어가는 값에 따라 블록이 되고 안되고가 결정이 된다.
그러면 그냥 커널에서 저 값을 강제로 바꿔보면??..

-_-;;;;;;;;; 바꾸려고 봤더니 변수가 사라졌다... 또한 NtUserBlockInput 함수도 메모리에 존재하지 않는다.

이유는 윈도우에는 nt함수를 위한 user 함수를 위한 각각의 ServiceTable이 있는데
nt함수들은 KiServiceTable에 있고 user함수들은 W32pServiceTable에 있다.

아래는 각 모듈 정보

kd> !address kiServiceTable

804d9000 - 001f9000

Usage KernelSpaceUsageImage

ImageName ntkrnlpa.exe

kd> !address W32pServiceTable

bf800000 - 001c3000

Usage KernelSpaceUsageImage

ImageName \SystemRoot\System32\win32k.sys

또한 분석을 해보면 KiServiceTable은 항상 메모리에 올라와 있지만 W32pServiceTable는 W32pServiceTable 내부 함수가 호출될 경우에만 메모리에 올라온다.

이와 같이..;;

그래서 W32pServiceTable 가 메모리에 올라왔을 경우 gptiBlockInput 변수에 접근할 수 있는데 그 때 값을 바꿔주니
BlockInput 함수를 호출하지 않아도 똑같은 동작은 내 맘대로 제어할 수 있었다.

그러면 커널에서는 저 값을 어디서 사용하는 것일까? 당연히 키보드와 마우스의 이벤트를 막는 역할을 할 것이다.
한번 하드웨어 브포를 걸어놓고 살펴보자.

WinDbg에서
ba r4 gptiBlockInput
이와 같이 하면 해당 변수에 4Byte read 시 BP가 걸리게 된다.

어디서 멈췄을까요?
win32k!ProcessMouseInput 함수에서 멈췄습니다. 처음 부분을 봐보죠.

gptiBlockInput 변수가 0인지 비교를 하고 0이 아니라면 0xbf886745 로 점프를 하게 됩니다.

가보면 그냥 함수 에필로그 부분인 것을 알 수 있습니다.

즉, 처음에 블록 상태를 나타내는 변수를 검사 후 0이 아닌 값이 있으면 그냥 이벤트 수행 루틴을 건너 뛰어버리는 것 입니다.
참 변수를 직관적으로 잘 사용하고 있군요.

키보드 같은 경우도 봐보겠습니다.

xxxKeyEvent 함수에서 해당 변수에 접근을 하고 있고 저 부분에서 0인지 아닌지 검사를 하게 됩니다.
0이라면 test 명령어이기 때문에 and 연산 후 값이 0이므로 점프하지 않습니다. 0 이 아닌 경우 점프를 하게 되겠죠.
점프 했을 경우엔... 뭐 위와 비슷하게 처리루틴이 아닌 다른 루틴으로 가겠지요..;

결론.................. BlockInput 함수.. 이렇게 작동합니다. .ㅎㅎ 허무..;

'My Study > Programming&Theory' 카테고리의 다른 글

Windows rand() 랜덤 비율 (0)	2012/02/14
ARM 명령어 공부 (2)	2012/01/27
BlockInput Function (3)	2012/01/20
My BSOD (2)	2012/01/08
SwapContext를 이용한 프로세스 찾기 (7)	2012/01/04
Remote Library Injection (4)	2011/12/29

Codegate 2011 B500 writeup

Ezbeat — Wed, 18 Jan 2012 22:56:58 +0900

대회가 끝난 .. 오래된 이 시점.. 가상화 프로젝트를 진행도중 예전에 가상화 관련해서 리버싱 문제가 하나 있었던거 같은데 그 당시 대회때는 건들어보지도 못했고; 나중에 시간 있을 때 한번 풀어봐야지 하고 문제만 가지고 있었는데 이제서야 풀어보게 되네요~ b100,200,300,400 다 풀었는데 시간상..ㅠㅠ 보지도 못한..;

문제를 풀어보면서 느낀건데 이거 만든 사람이 참 대단하게 느껴지더군요. 뭐 일단은 문제를 풀어보도록 하죠.
( 혹시 혼자서 먼저 풀어보실 분은 풀어보셔요. )
문제 파일

7CAC6AF2303FC01ACD2CEB350DAC0518

Q : Find a key.

일단 문제를 실행해보겠습니다.

출제가의 오타가 보이는 군요. 아무튼 키 파일을 체크를 하는데 해당 파일이 없다고 뜹니다.
뭐 리버싱을 해서 원하는 키 파일이 뭔지 알아내야겠지요. 일단 리버싱을 들어가기 전에

문제의 정보를 봐보았습니다.

해당 바이너리의 ImageBase와 EntryPoint를 살펴보니 시작하는 섹션이 .text 섹션이 아닌 .VM 섹션이라는 것을 알 수 있습니다. 0x409000 부터 .VM 섹션이기 때문이죠. 제가 공부하고 구현해보았던 코드 가상화 기법과는 또 다른 것 같습니다.

아무튼 부푼 기대를 가지고 한번 리버싱을 해보죠.

올디로 처음 열어보았을 때 화면입니다.

뭔가 시작부터 복잡하다고 느껴집니다. 전 미친척 하고 일일이 분석을 해보았지요.. =_=;; ㅎㅎ 사실 여러 가상화 기법들을 봐보아야 했기 때문에 겸사겸사 분석해본 것입니다.

여기에 모든 분석한 위치를 담기엔 뭐해서 대충 설명을 적겠습니다.

일단 두 번의 가상 메모리를 할당합니다.
VirtualAlloc(NULL,0x1000,0x1000,PAGE_EXECUTE_READWRITE);
첫번째 VirtualAlloc된 메모리 : V100
두번째 VirtualAlloc된 메모리 : V200
으로 일단 가정..
그림이 있어서 말해보면 위 그림에서
call dword ptr ds:[eax]
이 위치에서 한번 VirtualAlloc을 합니다.

아무튼 위 과정이 끝나고 쭉쭉 트레이스 하다보면

위와 같은 루틴으로 점프해서 들어오게 되는데 이 루틴이 핵심적인 부분 중 하나입니다.
이 루틴은 분석할만한 가치가 100% +_+ ㅋㅋ ㅠ_ㅠ @==^^ 설명이나 얼른..

이 루틴에서는 스택 재구성은 물론 별의별 짓을 합니다.
트레이스 하다보면
0x0040B1D4 에 있는 값과 0x0040B1D4 + 1 위치에 있는 값을 가져와 xor를 시킵니다.
그리고 0x0040B1D4 + 1 위치에 있는 값에서 xor된 크기 Byte만큼 데이터를 가져옵니다.
가져와서 또 지지고 볶고.. 쿵짝쿵짝

그리고 나면 V100+0xFD4 위치에 특정 명령어가 생성이 됩니다.
위 루틴의 끝 부분을 보시겠습니다.

이번 실행때 V100이 0x250000 였나보군요. 아무튼 push하고 retn하므로 저 주소로 뛰겠죠. 가보겠습니다.

push ebx를 하고 난 후 0x40ABBD로 점프를 하게 됩니다.

저 push ebx가 뭘까.... 메모리에 이미 있는 값을 지지고 볶고 한 후 생성된 값인데..

아무튼 계속 트레이스 해본 결과 위 과정이 반복 된다는 것을 확인할 수 있었습니다.

그래서~ 0x0040ABBC 위치에 BP를 잡고 0x00250FD4 위치의 명령어를 계속 확인하면서 적어본 결과입니다.

00250FD4 6A 00 PUSH 0

00250FD4 60 PUSHAD

00250FD4 9C PUSHFD

00250FD4 58 POP EAX

00250FD4 50 PUSH EAX

00250FD4 68 03954000 PUSH 409503

00250FD4 58 POP EAX ; 7CAC6AF2.00409503

00250FD4 8B05 F0914000 MOV EAX,DWORD PTR DS:[4091F0]

00250FD4 8D05 F80F3600 LEA EAX,DWORD PTR DS:[360FF8]

00250FD4 8925 F80F3600 MOV DWORD PTR DS:[360FF8],ESP

00250FD4 8300 04 ADD DWORD PTR DS:[EAX],4

00250FD4 58 POP EAX

00250FD4 8BF2 MOV ESI,EDX ; 7CAC6AF2.00409987

00250FD4 46 INC ESI ; 7CAC6AF2.00409987

00250FD4 8A02 MOV AL,BYTE PTR DS:[EDX]

00250FD4 3242 01 XOR AL,BYTE PTR DS:[EDX+1]

00250FD4 0FB6C0 MOVZX EAX,AL

00250FD4 50 PUSH EAX

00250FD4 56 PUSH ESI ; 7CAC6AF2.00409988

00250FD4 57 PUSH EDI

00250F7C 60 PUSHAD

00250F7C 8B0D CC0F3600 MOV ECX,DWORD PTR DS:[360FCC]

00250F7C 8B35 C80F3600 MOV ESI,DWORD PTR DS:[360FC8] ; 7CAC6AF2.00409988

00250F7C 8B3D C40F3600 MOV EDI,DWORD PTR DS:[360FC4]

00250F7C F3:A4 REP MOVS BYTE PTR ES:[EDI],BYTE PTR DS:[ESI]

00250F7C 61 POPAD

00250FD4 51 PUSH ECX

00250FD4 50 PUSH EAX

00250FD4 57 PUSH EDI

00250FD4 51 PUSH ECX

00250FD4 68 4B934000 PUSH 40934B

00250FD4 59 POP ECX ; 7CAC6AF2.0040934B

00250FD4 8B0D F4914000 MOV ECX,DWORD PTR DS:[4091F4]

00250FD4 66:390F CMP WORD PTR DS:[EDI],CX

00250FD4 59 POP ECX

00250FD4 51 PUSH ECX

00250FD4 C60438 68 MOV BYTE PTR DS:[EAX+EDI],68

00250FD4 68 66934000 PUSH 409366

00250FD4 59 POP ECX ; 7CAC6AF2.00409366

00250FD4 81C1 47000000 ADD ECX,47

00250FD4 890D DA0F3600 MOV DWORD PTR DS:[360FDA],ECX ; 7CAC6AF2.004093AD

00250FD4 C64438 05 C3 MOV BYTE PTR DS:[EAX+EDI+5],0C3

00250FD4 59 POP ECX ; 7CAC6AF2.004093AD

00250FD4 8BF2 MOV ESI,EDX ; 7CAC6AF2.0040998D

00250FD4 46 INC ESI ; 7CAC6AF2.0040998D

00250FD4 8A02 MOV AL,BYTE PTR DS:[EDX]

00250FD4 3242 01 XOR AL,BYTE PTR DS:[EDX+1]

00250FD4 0FB6C0 MOVZX EAX,AL

00250FD4 50 PUSH EAX

00250FD4 56 PUSH ESI ; 7CAC6AF2.0040998E

00250FD4 57 PUSH EDI

00250F7C 60 PUSHAD

00250F7C 8B0D CC0F3600 MOV ECX,DWORD PTR DS:[360FCC]

00250F7C 8B35 C80F3600 MOV ESI,DWORD PTR DS:[360FC8] ; 7CAC6AF2.0040998E

00250F7C 8B3D C40F3600 MOV EDI,DWORD PTR DS:[360FC4]

00250F7C F3:A4 REP MOVS BYTE PTR ES:[EDI],BYTE PTR DS:[ESI]

00250F7C 61 POPAD

00250FD4 51 PUSH ECX

계속 반복............

이러한 값이 생성이 되면서 실행을 하게 됩니다.!!
일단 여기서 이 가상화에 대한 결론을 내보면 원본 실행 루틴을 문제 만든이의 방법으로 인코딩을 시켜서 메모리에 저장해두고 실행 시 한줄 한줄 디코딩 하면서 실행하는 과정입니다.

너무 값이 많아 살펴보니 비슷비슷한 루틴이 계속 반복되고 있는 것을 알 수 있었습니다. 그리고 반복되는 루틴을 보니..!!
원본 실행 루틴을 디코딩 시켜서 메모리(V200 +0xFD4)에 저장하는 코드와 동일(너무 비슷?) 함을 알 수 있었습니다. 코드를 전부 분석해보니 눈에 보이더군요. 무튼 디코딩 되서 실행되는 루틴 또한 무언가 값을 디코딩해서 메모리에 저장합니다. 이거 이중 가상화 같군요. 가상화라 해야하나.. 아무튼 그러면 분명히 그 코드를 실행시키는

이와 비슷한 루틴이 분명히 존재할 것입니다.

PUSH V200+0xFD4
RETN
이 루틴이 어딘가 존재한다는 말이죠. 없으면.. 사실상 문제 삭제해버릴 생각이었습니다. ㅎㅎㅎㅎ
있으니 이렇게 풀이를 작성하고 있겠죠?

이 위치 입니다. V200이 0x260000 였나보군요.
RETN 위치로 가보겠습니다.

뭐 여기서도 역시나 한줄 실행하고 0x4093AD 위치로 가는 것을 알 수 있습니다.
이제 0x00260FD4 위치에 있는 값을 또 한줄한줄 잡아볼까요?

아!!~ 그 전에 .text 영역을 잠깐 봐보겠습니다.
보통 가상화를 시키면 가상화된 코드는 원본 코드보다 크기가 훨씬 크기 때문에 새로운 섹션을 만들어서 거기에 넣어두게 됩니다. 이 문제에서는 .VM 섹션에 있는 거구요. 그러면 원본 코드가 있는 .text 섹션엔?? 뭐 쓰레기 값으로 꽉꽉 넣어놨겠죠. 필요 없는 코드이기 때문에요.

하지만 문제 만든이가 모든 코드를 가상화 시키지 않고 부분부분만 가상화를 시켜놨습니다. 그래서

이와 같이 듬성듬성 있는 코드 이지만.. (nop 된 부분은 전부 가상화된 코드일 것.. ㅠㅠ)
전부다 BP를 걸어놨습니다.

다시 가상화 코드 부분으로 돌아와 0x00260FD4 위치에 있는 값을 잡아보겠습니다.

00260FD4 8D0D 40FB1200 LEA ECX,DWORD PTR DS:[12FB40]

이거 한줄 실행하고 .text섹션으로 들어오네요.

잘 보니 인자로 "rb", "codegate.key" 가 들어가는 걸로 봐서 codegate.key 파일명을 가지고 read/binary ? 로 여는 것을 알 수 있었습니다. 그래서 문제 파일과 동일한 폴더에 그냥 codegate.key 라는 파일을 하나 만들고 그안에 아무내용이나 막 채워넣었습니다. 그 다음 RETN을 하면 다시 .VM섹션으로 돌아오게 됩니다.

계속 0x00260FD4 위치에 있는 값을 잡아보겠습니다.

이렇게 잡고나면 running 상태로 빠지게 되며

이 창에서 멈추게 됩니다. 아무키나 누르면 계속 진행되겠지요. 다시 진행하겠습니다.

이 가상화된 루틴을 실행 후

.text섹션인 이 부분으로 오게됩니다. 이 부분이 codegate.key 파일이 존재하면 JE문에서 점프하지 않고 없으면 점프하게 됩니다. 즉, 없다면 EAX 값이 0으로. 있다면 0x0B6863BD와 같은 값으로...

다시 0x00260FD4로..

이 부분 실행 후 다시 .text 섹션..;;

이 부분 실행 후 다시 .VM 섹션.. 뭐 무한반복?? [ECX+4] 에는 0x0B6863BD 값이..

위에서 얻어온 값을 가지고 이렇게 비교를 하는 군요. 파일이 없으면 cmp문을 수행 후 I can't find the file 이라는 문장이 출력됩니다. 위 두 문장을 수행 후 다시 .text 섹션으로 오는데 이 부분이 중요합니다.

CALL 문을 호출하는데 들어가는 인자는
Func(0x12FB48,0x200,0x1..) 이렇게 들어갑니다.
실제로 수행을 해보면 0x12FB48 메모리 주소에 0x200 바이트 만큼 codegate.key에서 가져오게 됩니다.
아마 저 함수는 fread 함수 같군요 ㅋㅋ 키 길이는 0x200 Byte인것 같습니다. 계속 계속 gogo

한 문장 수행 후 다시 .text.. 지치네요..

EAX에 0x0B70139B라는 값 넣고 있습니다.

뭐 또 검증 하겠죠. 아무튼 이제 중요한 부분으로 바로 넘어가겠습니다.
계속 0x00260FD4 에 있는 문을 실행하면

이와 같은 루틴을 실행하게 되는데 주석에 달아놨듯이 [ECX+8]은 codegate.key에서 읽어온 0x200 Byte의 첫번째 데이터 값입니다. 그리고 그 값이 0x64와 xor 한 후 0x90과 비교를 하는데.. 당연히 다르겠죠. 그래서 아래와 같이 틀렸다는 문장을 실행하게 됩니다.

이제 cmp al,0x90 위치에 올 때마다 al 값을 옆 값과 맞는 값으로 바꿔주면서 진행해보겠습니다.
혹은 그냥 cmp 실행 후 zero flag를 바꿔줘도 됩니다. ㅋ

이런식으로 진행되게 됩니다. 1Byte씩 가져와 특정 값과 xor 한후 특정 값과 비교를 하죠..
이걸 일일이... 해야 하는거겠죠??.. ㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠ

잠시 글 쓰는걸 중단하고 노가다 작업좀 하겠습니다.

------------ 잠 시 후 ------------
워...... fread로 0x200 Byte나 읽었길래 정말 512번의 저 거지같은 노가다를 해야되는줄 알았습니다.
다행이.. 0x64..즉 100Byte만 저짓거리 한 후 ...!

위와 같은 루틴을 시행하더군요.

codegate.key의 값을 읽어온 메모리 값을 다른 메모리로 100byte만큼 옮깁니다.
그리고 나서 pop ecx를 마지막으로 .VM섹션에서 한 후.. .text 섹션으로 넘어오게 됩니다.
이 때 단순히 zf만 1로 바꿔주면서 넘어오신 분들은 여기까지 하고 실제 key file 값을 구해주셔야합니다.
xor되는 값과 cmp되는 값을 xor 시켜주면서 복원.. 100Byte를 말이죠.

이 루틴인데 무언가 printf 할 느낌이 팍팍드는 이 좋은 기분은 뭘까요?? ^^
JL점프문에 의해 루프를 돈 다음 나온 화면을 보겠습니다.

올바르게 찾은 것 같군요. 아..... 바로 답을 주진 않고 또 뭔가 이상한 값을 주네요.. :-(

하! 지! 만! ㅋㅋ 저도 이렇게 비슷한 유형의 문제를 낸적이 있습니다. 추측해봤지만 맞더군요.
일단 각각의 숫자를 2진수로 바꿉니다. 그리고 1에 색을 넣어서 한번 봐보겠습니다.

보이십니까?? QR 코드입니다. 하지만 QR코드가 180도 돌아가 있는 것 같군요.
QR코드를 읽을 수 있게끔 변환을 하겠습니다. ( 엑셀 사용.. -.- ) 위 결과를 단 20초면 아래와 같이 변환 가능!

위 값을 나의 패드로 찰칵 찍으면?!

답 : I_am_in_C0d3gat3_2011!!

뿌듯하네요. ㅋㅋ 이거 푸는데.. 가장 많이 시간이 걸린 곳은.. 바로 키파일 100Byte 저거 찾는 부분입니다. ..ㅠ_ㅠ 아흑..

PS. -_-;;;; 이거 조금 찾아보니까.. x86 Virtualizer 툴로 두번 가상화 시킨 것 뿐이네요..;;; 덕분에 x86 가상화 툴 싹다 분석해봤네요. 오픈소스 툴이므로 찾아보면 소스코드도 있습니다. 전 아바스트 백신 쓰는데 백신에서 잡네요.

그 전까지 이 문제 만든이가 직접 가상화 코드를 구현한줄 알았습니다.;;;

'My Study > Crack Me' 카테고리의 다른 글

Codegate 2011 B500 writeup (2)	2012/01/18
Defcon 2010 예선 바이너리 3번 (0)	2010/06/02
Defcon 2010 예선 바이너리 2번 (0)	2010/06/02
Defcon 2010 예선 바이너리 1번 (8)	2010/05/23
HellBound Application Cracking 15 (0)	2010/04/29
HellBound Application Cracking 2 (2)	2010/04/28

My BSOD

Ezbeat — Sun, 08 Jan 2012 11:31:08 +0900

BSOD..Blue Screen of Death.. 아주 짜증나는 화면이죠.

이 거지 같은 화면을 좀 바꿔볼까요??

실제로 드라이버 개발하는 입장에서도 "Inbv" 함수를 사용하면 간단히 BSOD 같은 화면을 구성할 수 있습니다.
심심하신 분들은 한번 만들어보세요 ^^ 간단히 Inbv 함수 몇개 import 시키고 그냥 사용하시면 끝납니다.-.-;

전 조금 더 나아가 장난쳐보기 위해 실제 윈도우에서 사용하고 있는 블루스크린의 색을 바꿔보겠습니다.

먼저 KeBugCheck 함수 내부에서 블루스크린을 구성하기 위해 호출되는 Inbv 함수가 무엇인지 보겠습니다.
Windows XP 기준으로 봐보았습니다.

InbvSolidColorFill() 함수가 배경 색이고
InbvSetTextColor() 함수가 글자색입니다.

저 두 부분을 후킹해서 살포시 인자 값만 바꿔주면.... 끝끝끝.. ㅎㅎ

그래서 나온 제 BSOD입니다. 가 아니라 RSOD 입니다. (Red Screen of Death)

눈 아프네요.. @_@;;

'My Study > Programming&Theory' 카테고리의 다른 글

ARM 명령어 공부 (2)	2012/01/27
BlockInput Function (3)	2012/01/20
My BSOD (2)	2012/01/08
SwapContext를 이용한 프로세스 찾기 (7)	2012/01/04
Remote Library Injection (4)	2011/12/29
OpenProcess를 막는 방법은?? (11)	2011/12/20

SwapContext를 이용한 프로세스 찾기

Ezbeat — Wed, 04 Jan 2012 16:01:11 +0900

지금껏 시스템 프로그래밍을 많이 해왔지만 프로세스를 찾는 프로그래밍은.. 안해본것 같군요.
기껏해봐야
CreateToolhelp32Snapshot()
Process32First()
Process32Next()
세 함수를 사용한 유저모드에서 프로세스 찾는...;;

커널에서도 찾는 방법이 여러가지가 있을 껀데
ZwQuerySystemInformation함수를 사용하는 방법..
또한 System 프로세스의 EPROCESS 구조체 주소를 구해 링크드 리스트로 연결된 EPROCESS를 쭉 따라가면서 찾는 방법..

등등 여러가지가 있었습니다. 하지만 API함수를 사용하는 방법은 간단히 후킹해 내 프로세스 정보를 없애버리면 되는것이고
EPROCESS 구조체를 쭉 따라가면서 탐지하는 방법은 내 프로세스의 링크를 끊어버리면 탐지가 어렵게 되는.. ;;

그래서 루트킷 책을 보니깐 nt!SwapContext 함수를 후킹해 탐지하는 방법이 있더군요.
해당 함수는 현재 실행 중인 스레드의 컨텍스트가 바로 다음에 실행될 스레드의 컨텍스트로 스왑될 때 호출되는 함수입니다. 고로.... IRQL은..?! PASSIVE_LEVEL이 아닌 DISPATCH_LEVEL에서 이루어지겠죠. 무튼무튼

해당 함수에 들어오게되면
EDI 레지스터는 다음에 실행될 스레드(ETHREAD)를 가리키며 ESI는 현재 실행 중이며 곧 스왑될 스레드(ETHREAD)를 가리킵니다. 실제로 그런지 봐볼까요?
아 ~ 그리고 이 모든 테스트는 Windows XP SP3에서 테스트 됬습니다. 그렇다고 Windows 7이라고 뭐 다를건 없습니다. -_-;

kd> ln nt!SwapContext

(805438e0) nt!SwapContext | (80543a38) nt!KeInterlockedSwapPte

Exact matches:

nt!SwapContext = <no type information>

kd> bp 805438e0

kd> g

Breakpoint 0 hit

nt!SwapContext:

805438e0 0ac9 or cl,cl

현재 SwapContext 함수 처음 부분에 멈춰있는 상태입니다. EDI 레지스터를 확인하고 ETHREAD 구조체에 맵핑 시켜보죠.

kd> r

eax=00001000 ebx=ffdff000 ecx=00000001 edx=80555880 esi=825b2b30 edi=825b6020

eip=805438e0 esp=f8afdce0 ebp=f8afdcf4 iopl=0 nv up ei pl nz na pe nc

cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000206

nt!SwapContext:

805438e0 0ac9 or cl,cl

kd> dt _ETHREAD 825b6020

ntdll!_ETHREAD

+0x000 Tcb : _KTHREAD

+0x1c0 CreateTime : _LARGE_INTEGER 0xe6654fd`d4418200

+0x1c0 NestedFaultCount : 0y00

+0x1c0 ApcNeeded : 0y0

+0x1c8 ExitTime : _LARGE_INTEGER 0x825b61e8`825b61e8

+0x1c8 LpcReplyChain : _LIST_ENTRY [ 0x825b61e8 - 0x825b61e8 ]

+0x1c8 KeyedWaitChain : _LIST_ENTRY [ 0x825b61e8 - 0x825b61e8 ]

+0x1d0 ExitStatus : 0n0

+0x1d0 OfsChain : (null)

+0x1d4 PostBlockList : _LIST_ENTRY [ 0x825b61f4 - 0x825b61f4 ]

+0x1dc TerminationPort : (null)

+0x1dc ReaperLink : (null)

+0x1dc KeyedWaitValue : (null)

+0x1e0 ActiveTimerListLock : 0

+0x1e4 ActiveTimerListHead : _LIST_ENTRY [ 0x825b6204 - 0x825b6204 ]

+0x1ec Cid : _CLIENT_ID

+0x1f4 LpcReplySemaphore : _KSEMAPHORE

+0x1f4 KeyedWaitSemaphore : _KSEMAPHORE

+0x208 LpcReplyMessage : (null)

+0x208 LpcWaitingOnPort : (null)

+0x20c ImpersonationInfo : 0xe163d390 _PS_IMPERSONATION_INFORMATION

+0x210 IrpList : _LIST_ENTRY [ 0x824541e8 - 0x824541e8 ]

+0x218 TopLevelIrp : 0

+0x21c DeviceToVerify : (null)

+0x220 ThreadsProcess : 0x825b9830 _EPROCESS

+0x224 StartAddress : 0x80536b02 Void

+0x228 Win32StartAddress : (null)

+0x228 LpcReceivedMessageId : 0

+0x22c ThreadListEntry : _LIST_ENTRY [ 0x825b6fd4 - 0x825b75f4 ]

+0x234 RundownProtect : _EX_RUNDOWN_REF

+0x238 ThreadLock : _EX_PUSH_LOCK

+0x23c LpcReplyMessageId : 0

+0x240 ReadClusterSize : 7

+0x244 GrantedAccess : 0x1f03ff

+0x248 CrossThreadFlags : 0x10

+0x248 Terminated : 0y0

+0x248 DeadThread : 0y0

+0x248 HideFromDebugger : 0y0

+0x248 ActiveImpersonationInfo : 0y0

+0x248 SystemThread : 0y1

+0x248 HardErrorsAreDisabled : 0y0

+0x248 BreakOnTermination : 0y0

+0x248 SkipCreationMsg : 0y0

+0x248 SkipTerminationMsg : 0y0

+0x24c SameThreadPassiveFlags : 3

+0x24c ActiveExWorker : 0y1

+0x24c ExWorkerCanWaitUser : 0y1

+0x24c MemoryMaker : 0y0

+0x250 SameThreadApcFlags : 0

+0x250 LpcReceivedMsgIdValid : 0y0

+0x250 LpcExitThreadCalled : 0y0

+0x250 AddressSpaceOwner : 0y0

+0x254 ForwardClusterOnly : 0 ''

+0x255 DisablePageFaultClustering : 0 ''

저기서
+0x220 ThreadsProcess : 0x825b9830 _EPROCESS
이 부분이 바로 해당 스레드를 가지고 있는 프로세스의 EPROCESS 구조체 주소 정보가 있는 곳입니다.
해당 EPROCESS를 따라가보죠.

kd> dt _EPROCESS 0x825b9830

ntdll!_EPROCESS

+0x000 Pcb : _KPROCESS

+0x06c ProcessLock : _EX_PUSH_LOCK

+0x070 CreateTime : _LARGE_INTEGER 0x0

+0x078 ExitTime : _LARGE_INTEGER 0x0

+0x080 RundownProtect : _EX_RUNDOWN_REF

+0x084 UniqueProcessId : 0x00000004 Void

+0x088 ActiveProcessLinks : _LIST_ENTRY [ 0x821a3310 - 0x8055c158 ]

+0x090 QuotaUsage : [3] 0

+0x09c QuotaPeak : [3] 0

+0x0a8 CommitCharge : 7

+0x0ac PeakVirtualSize : 0x293000

+0x0b0 VirtualSize : 0x1cf000

+0x0b4 SessionProcessLinks : _LIST_ENTRY [ 0x0 - 0x0 ]

+0x0bc DebugPort : (null)

+0x0c0 ExceptionPort : (null)

+0x0c4 ObjectTable : 0xe1000cc0 _HANDLE_TABLE

+0x0c8 Token : _EX_FAST_REF

+0x0cc WorkingSetLock : _FAST_MUTEX

+0x0ec WorkingSetPage : 0

+0x0f0 AddressCreationLock : _FAST_MUTEX

+0x110 HyperSpaceLock : 0

+0x114 ForkInProgress : (null)

+0x118 HardwareTrigger : 0

+0x11c VadRoot : 0x825b5200 Void

+0x120 VadHint : 0x825b5200 Void

+0x124 CloneRoot : (null)

+0x128 NumberOfPrivatePages : 3

+0x12c NumberOfLockedPages : 0

+0x130 Win32Process : (null)

+0x134 Job : (null)

+0x138 SectionObject : (null)

+0x13c SectionBaseAddress : (null)

+0x140 QuotaBlock : 0x8055c200 _EPROCESS_QUOTA_BLOCK

+0x144 WorkingSetWatch : (null)

+0x148 Win32WindowStation : (null)

+0x14c InheritedFromUniqueProcessId : (null)

+0x150 LdtInformation : (null)

+0x154 VadFreeHint : (null)

+0x158 VdmObjects : (null)

+0x15c DeviceMap : 0xe1004440 Void

+0x160 PhysicalVadList : _LIST_ENTRY [ 0x825b9990 - 0x825b9990 ]

+0x168 PageDirectoryPte : _HARDWARE_PTE_X86

+0x168 Filler : 0

+0x170 Session : (null)

+0x174 ImageFileName : [16] "System"

+0x184 JobLinks : _LIST_ENTRY [ 0x0 - 0x0 ]

+0x18c LockedPagesList : (null)

+0x190 ThreadListHead : _LIST_ENTRY [ 0x825b97e4 - 0x8246fbb4 ]

+0x198 SecurityPort : 0xe19c27b0 Void

+0x19c PaeTop : (null)

+0x1a0 ActiveThreads : 0x39

+0x1a4 GrantedAccess : 0x1f0fff

+0x1a8 DefaultHardErrorProcessing : 1

+0x1ac LastThreadExitStatus : 0n0

+0x1b0 Peb : (null)

+0x1b4 PrefetchTrace : _EX_FAST_REF

+0x1b8 ReadOperationCount : _LARGE_INTEGER 0x65

+0x1c0 WriteOperationCount : _LARGE_INTEGER 0x1c7

+0x1c8 OtherOperationCount : _LARGE_INTEGER 0x12e5

+0x1d0 ReadTransferCount : _LARGE_INTEGER 0x9a53c

+0x1d8 WriteTransferCount : _LARGE_INTEGER 0x2c1cd6

+0x1e0 OtherTransferCount : _LARGE_INTEGER 0x76c46

+0x1e8 CommitChargeLimit : 0

+0x1ec CommitChargePeak : 0x1cd

+0x1f0 AweInfo : (null)

+0x1f4 SeAuditProcessCreationInfo : _SE_AUDIT_PROCESS_CREATION_INFO

+0x1f8 Vm : _MMSUPPORT

+0x238 LastFaultCount : 0

+0x23c ModifiedPageCount : 0xcc3

+0x240 NumberOfVads : 4

+0x244 JobStatus : 0

+0x248 Flags : 0x40000

+0x248 CreateReported : 0y0

+0x248 NoDebugInherit : 0y0

+0x248 ProcessExiting : 0y0

+0x248 ProcessDelete : 0y0

+0x248 Wow64SplitPages : 0y0

+0x248 VmDeleted : 0y0

+0x248 OutswapEnabled : 0y0

+0x248 Outswapped : 0y0

+0x248 ForkFailed : 0y0

+0x248 HasPhysicalVad : 0y0

+0x248 AddressSpaceInitialized : 0y00

+0x248 SetTimerResolution : 0y0

+0x248 BreakOnTermination : 0y0

+0x248 SessionCreationUnderway : 0y0

+0x248 WriteWatch : 0y0

+0x248 ProcessInSession : 0y0

+0x248 OverrideAddressSpace : 0y0

+0x248 HasAddressSpace : 0y1

+0x248 LaunchPrefetched : 0y0

+0x248 InjectInpageErrors : 0y0

+0x248 VmTopDown : 0y0

+0x248 Unused3 : 0y0

+0x248 Unused4 : 0y0

+0x248 VdmAllowed : 0y0

+0x248 Unused : 0y00000 (0)

+0x248 Unused1 : 0y0

+0x248 Unused2 : 0y0

+0x24c ExitStatus : 0n259

+0x250 NextPageColor : 0x5bf6

+0x252 SubSystemMinorVersion : 0 ''

+0x253 SubSystemMajorVersion : 0 ''

+0x252 SubSystemVersion : 0

+0x254 PriorityClass : 0x2 ''

+0x255 WorkingSetAcquiredUnsafe : 0 ''

+0x258 Cookie : 0

이부분
+0x174 ImageFileName : [16] "System"
이 부분에 바로 해당 프로세스의 이름이 담겨 있는 곳입니다.
이 부분만 후킹해서 슬쩍슬쩍 빼오면 되는 것이지요. EDI, ESI 두 레지스터에서 전부 말이죠.

방법은 간단합니다.

1. nt!SwapContext 함수를 인라인 후킹을 한다. 처음 5Byte를 MyRoutine() 함수로 Jmp하게끔
2. MyRoutine() 함수에서는 EDI, ESI 레지스터에서 ETHREAD -> EPROCESS -> ImageFileName 주소를 구한다.
3. nt!SwapContext 함수로 다시 점프한다.

끝입니다. 구현하면서 중요시 해야될 부분은 보통 API 함수 후킹할 때는
후킹 -> My 함수 호출되면 -> 인자값 조작 -> 언후킹 -> 오리지널 함수 호출 -> 후킹 -> 리턴 값 조작....
이런식으로 진행이 되는데 이 함수는 그렇게 하면 안됩니다.

일단 문서화된 함수가 아니고.. 찾아보니까 함수의 원형을 도저히 모르겠더군요. 또한 이건 함수라고 하기도 뭐한게 [ebp+8].. 이런식으로 인자 값을 가져와서 하는게 아닌 단순 EDI, ESI 에 있는 값을 모니터링 하기 때문이죠. 일반적인 API함수가 아닌..
또한 안다 하더라도 위와같은 방식을 사용하면 스레드가 스왑될 때마다 언후킹, 후킹을 하게 되는데 이러면 상당히 오버헤드가 발생하게 됩니다. Windows 같은 경우 하나의 스레드가 사용할 수 있는 퀀텀을 다 사용하면서 스왑된다 하더라도 스왑되는 주기가 매우 짧기 때문이죠. 고로 이런 방식으로 진행됩니다.

후킹 -> (naked)My 함수 호출 -> EDI, ESI로부터 프로세스 이름 얻음(함수로 처리) -> nt!SwapContext 함수로 점프

이런식입니다. 즉 언후킹은 해당 후킹 드라이버가 언로드 될 때만 해주는 것입니다.
그리고 언후킹을 하지 않기 때문에 저 같은 경우는 아래와 같이 구현했습니다;;

Windows XP SP3 SwapContext 처음 부분

805438e0 0ac9 or cl,cl

805438e2 26c6462d02 mov byte ptr es:[esi+2Dh],2

805438e7 9c pushfd

My 함수 끝 부분
or cl,cl

mov byte ptr [esi+0x2D],2

jmp swapContext_Trampoline ; SwapContext_Address + 7

이런식으로 5Byte가 jmp문으로 바뀐것에 대해 내부적으로 수행해주고 SwapContext 주소에서 +7 자리로 점프를 해서 실행하는 것입니다. 이러면 언후킹할 필요가 없더군요. 오버헤드 막기 성공.. ;;

아무튼 구현하니 잘 작동은 합니다.

사실 이렇게 끝내면 안되고 당연히 프로세스 이름을 담을 테이블을 만들고 중복 처리도 해주고
프로세스가 종료되면 해당 프로세스를 테이블에서 빼주고도 하고 유저와 통신을 하면서
사용자에게 보여주기도 해야하는 과정이 남았지만 이건 나중에 실질적으로 필요할 때가 생기면 구현을 해봐야겠습니다.

아래는 그냥 DbgPrint를 사용해 프로세스 이름을 출력하는 과정만 보여주었습니다.
또한 DKOM방법으로 숨긴 프로세스 또한 찾아지는지 보겠습니다.

이제 이렇게 SwapContext를 후킹해 프로세스를 찾아내는 방법 우회해 프로세스를 숨길 수 있는 방법은 무엇이 있을까요?
무조건 프로그램을 사용하게 되면 해당 프로세스 내부에 있는 스레드는 걸리게 될 것이고.. 걸리면 탐지가 되는거고..
안걸리게 해야될탠데.. 안걸리려면 프로세스가 작동을 안해야한다는.. 작동 안할꺼면 필요도 없는 거고..;
우회할 수 있는 방법엔 무엇이 있을까요?? 좋은 방법 아시는 분은 댓글로 저에게 조언 부탁드려요! 막상 바로 떠오르진 않군요.

'My Study > Programming&Theory' 카테고리의 다른 글

BlockInput Function (3)	2012/01/20
My BSOD (2)	2012/01/08
SwapContext를 이용한 프로세스 찾기 (7)	2012/01/04
Remote Library Injection (4)	2011/12/29
OpenProcess를 막는 방법은?? (11)	2011/12/20
Immunity Debugger Hard Hooking (2)	2011/12/08

Remote Library Injection

Ezbeat — Thu, 29 Dec 2011 13:57:44 +0900

예전에부터 해왔던건데 ㅠㅠ Native 함수 후킹 시 함수호출 규약 Calling Convention 을 무시한결과.. 엄청난 삽질을 동반한 시간적 낭비가 있어서 이제 올려보네요.. 아 ㅠㅠ API 후킹 시 함수호출 규약 잘 지킵시다..헝헝..

한가지 궁금한 점은.. NtOpenFile일 경우 커널이나 유저나 함수호출 규약은 __stdcall로 같은데
왜 후킹할 때 user에선 __stdcall을 붙혀줘야되고 kernel에선 안붙혀줘도 되는건지..;

다시 본론으로 돌아와서 Remote Library Injection은 나름 괜찮은 기술입니다.
디스크에 읽고 쓰여짐을 탐지하는 모니터링 툴들을 우회할 수 있기 때문이죠.

간략한 그림을 보시겠습니다.

보통 몇몇 악성코드가 작동하는 방식입니다. 먼저 Dropper는 백신에 걸리지 않기 때문에 안전하게 메모리에 올라올 수 있고 그 다음에 악성 dll을 소켓 통신을 통해 받던 Dropper내부적으로 인코딩되어 있던 것을 디코딩하던 한 다음 Disk상에 드랍 시킵니다. 그 다음에 LoadLibrary를 통해 악성 dll을 로드시키는 것이지요.

하지만 이 방법은 백신에 걸리기 쉽습니다. 만약 백신이 Disk에 생성되는 모든 파일들에 대해서 모니터링을 하고 있다면?
아마 Virus.dll이 잡힐 확율은 상당히 높을 것입니다. 그러면 다른 방법으로 Virus.dll을 로드 시킬 방법을 생각해봐야겠군요.

아래 그림을 봐보아요~

상당히 그림을 발로 그렸지만.. 보면 Dropper.exe 내부적으로 소켓통신으로 받았던 원래 가지고 있던 아무튼 해당 Virus.dll을 Disk에 드랍하지 않고 자체적으로 메모리상에서 바로 로드해 버리는 것입니다.
이렇게 구현될 경우 당연히 Disk에 생성되는 모든 파일에 대해서 감시하고 있는 백신은 당연히 농락시킬 수 있는 것입니다.

제가 ezbeat.dll로 로드가 되면 단순히 메시지 박스만 띄우는 dll을 하나 만들어 보았습니다. 이제 이 dll을 로드해보겠습니다.

간단히 LoadLibrary를 사용해 "c:\ezbeat.dll" 을 로드하는 방법입니다. 누구나 dll을 로드할 때 이러한 방법을 많이 사용하죠.
당연히 "c:\ezbeat.dll" 는 Disk상 해당 경로에 존재합니다.

로드가 된 후 올디로 상태를 확인해보았습니다.

파란색으로 네모친 부분을 보면 잘 로드가 되었고 Entry 또한 잘 나와 있군요.

이번엔 Remote Library Injection을 사용해서 로드하는 방법입니다.

EmulateFileToMemory() 함수와 InitHook() 가 추가가 되었군요.
그리고 LoadLibrary 할 때 넘어가는 인자가 "K:\ezbeat.dll" 입니다. 하지만 제 컴퓨터에는 K 드라이버는 없습니다.
즉.. "K:\ezbeat.dll" 은 하드에 존재하지 않는 그냥 가짜 이름입니다. 해당 파일의 내용은 LoadLibrary 호출자 프로세스가 가지고 있습니다. 그러면 실패할까요? 실행해보죠.

잘 되는군요. 이것도 올디로 봐보겠습니다.

로드도 잘 되었고 dll 내부적으로 있는 메시지박스도 잘 실행되었지만.. Entry가 없습니다...
바로 이게 Remote Library Injection 입니다.

방법은?

1. 로드시키려는 dll 파일 내용을 메모리 상에 지니게 있도록 한다. ( 소켓으로 받던.. 애당초 인코딩해서 가지고 있던.. )
2. dll 내용을 메모리 상에 올라왔을 때와 똑같이 에뮬레이팅 해준다.
3. LoadLibrary 내부적으로 호출되는
NtQueryAttributesFile, NtOpenFile, NtCreateSection, NtMapViewOfSection 을 후킹
4. LoadLibrary가 호출되 각 후킹된 Nt 함수들 내부적으로 들어오면
파라미터와 리턴 값을 적절히 조작해 성공하게 만든다.

끝입니다.
아래는 영상..

일부러 백신에 잡히게 dll을 만들어보고 해당 dll을 가지고 테스트 해봐야겠네요.
아무튼 다른 실시간 모니터링 부분은 몰라도 디스크 모니터링 하는 부분은 우회가 가능한 방법입니다.

'My Study > Programming&Theory' 카테고리의 다른 글

My BSOD (2)	2012/01/08
SwapContext를 이용한 프로세스 찾기 (7)	2012/01/04
Remote Library Injection (4)	2011/12/29
OpenProcess를 막는 방법은?? (11)	2011/12/20
Immunity Debugger Hard Hooking (2)	2011/12/08
ScreenSaver 만들어보기 (3)	2011/11/30

OpenProcess를 막는 방법은??

Ezbeat — Tue, 20 Dec 2011 03:34:45 +0900

모든 기말고사 시험이 끝나고.. 데이터베이스 발표만을 앞둔 상황에서.. 새벽에 심심하던 찰나 문뜩 생각이 나서 장난같지 않은 장난을 한번 쳐봤습니다. 될까 싶었는데 그냥 되더군요.

OpenProcess는 PID를 가지고 대상 프로세스의 커널오브젝트를 가리키는 핸들을 얻어오는 함수입니다.
dll injection을 하건 해당 프로세스의 메모리 패치를 하던간에.. 무조건 호출되어야하는 함수입니다.
뭐.. FindWindow를 사용할수도 있지만 윈도우 이름보단 프로세스 이름으로 pid를 얻는게 더 효율적이죠...

저놈의 함수를 막을려면 어떻게 할까요.. 유저단에서 생각을 해보면 전역 후킹을 통해 모든 프로세스에 dll을 inection 시키고 모든 프로세스의 kernel32.dll에 있는 OpenProcess를 후킹해서 막아야할까요?.. 물론 되겠죠.

이번엔 커널단에서 생각해보겠습니다. 그냥 간단히 KiServiceTable 있는 ZwOpenProcess 함수를 후킹할까요?(SSDT..)
이 방법은 커널 프로그래밍을 해야되는 것 이지만 후킹 탐지가 쉽게 되므로 효율성이 얼마나 있을지 모르겠군요.

그 외에도 SYSENTER를 후킹해서 하는 방법..( ZwOpenProcess 시스템 번호로 식별해.. )

많은 방법이 있지만 이번에 해볼 방법은 쫌.. 살짝 장난스럽긴 하지만 PID를 계속적으로 바꿔버리는 것입니다.
프로세스를 계속 살렸다 죽였다 살렸다 죽였다.. 하는 방법은 아니구요;;
살아있는 프로세스의 PID를 계속 바꾸는 것 입니다.

바로 저 PID 말이죠.
프로세스의 PID가 저장되어 있는 장소는 두 군데로 알고 있습니다. 첫번째는

TEB 구조체의 ClientId 멤버변수에 있습니다. 이건 유저에 저장되어 있는 값이구요.
GetCurrentProcessId()함수를 사용해서 얻오는 PID가 바로 저기서 얻어오는 것 입니다.

두번째는

커널에 있는 EPROCESS 구조체 내부에 있는 UniqueProcessId 멤버변수에 있습니다.

그러면 프로세스 이름으로 검색해 PID를 얻어오는 방법인
CreateToolhelp32Snapshot()
Process32First()
Process32Next()
세 함수를 사용한다면 어떠한 PID를 가져올까요??

바로 EPROCESS 구조체 내부에 있는 UniqueProcessId 값을 가져오게 됩니다.

하지만 저 값이 계속적으로 바뀌어버리면??
제대로 된 PID 값을 알지못해 OpenProcess가 실패하게 될 것입니다.
사실 한번만 바꿔도 되는데... 계속 바뀌어지면 뭔가 있어보이잔아요?...흠..

아무튼 그런 방법을 사용해 PID를 변경시키는 프로그램을 만들어보았습니다.
그리고 다른 프로세스에서는 해당 프로세스의 핸들을 얻기위해 OpenProcess를 계속 시도하였습니다.

아래는 동영상.. ( 마우스 휠로 브라우져를 확대에 보세요.. )

이것도 조금만 생각해보시면 파훼법이 있겠죠??
혹시 좋은 방법들이 있다면 댓글로 조언을 해주세요 ^^

'My Study > Programming&Theory' 카테고리의 다른 글

SwapContext를 이용한 프로세스 찾기 (7)	2012/01/04
Remote Library Injection (4)	2011/12/29
OpenProcess를 막는 방법은?? (11)	2011/12/20
Immunity Debugger Hard Hooking (2)	2011/12/08
ScreenSaver 만들어보기 (3)	2011/11/30
API vs MFC (1)	2011/11/30

해피캠퍼스는 멍청해!!

Ezbeat — Thu, 08 Dec 2011 20:27:43 +0900

제가 인터넷 서핑 중 해피캠퍼스에 자료를 올려서 용돈벌이를 하고 있다는 학생의 글을 보고
"오 ~ 나도 한번??"

이라는 생각을 가지고 뭘 한번 올려볼까.. 하고 하드를 뒤져보았다.
일단 테스트로 올려볼 것이기 때문에 예전에 간단히 짜본 음악 플레이어 소스코드를 올려보았다.

해당 코드는 당연히 유니코드 기반 코드였고 내부적으로 한글을 써야했기 때문에
_wsetlocale(LC_ALL,_T("korean"));
이 함수 또한 사용해 주었다..

해당 함수는 wprintf, fputws와 같은 함수들을 통해서 유니코드 기반으로 한글을 출력하고 싶을 때 사용하는 함수;;
무튼..

고로 당연히 컴파일도

이렇게 유니코드 문자 집합 사용으로 해주어야한다. 이건 뭐 VS 디폴트 옵션이다.

컴파일 결과.. 당연히 error - 0, warning - 0..

다음날.. 해피캠퍼스에서 메일이 왔다... 두근! 등록이 됬구나!..?!

??????????????? 허얼?
저 오류는... 문자 집합을 멀티바이트 문자 집합 사용을 했을 때.. 나는 오류.. 당연히 자료형이 맞지 않아 날수밖에 없는 오류!

해피캠퍼스에서는 코드를 돌릴 때 그냥 기계가 돌리는 것일까요? 사람이 Ctrl + C, V를 사용해 컴파일러에서 돌리는 것일까요?? ... 이런건 알바생 쓰겠죠??..

너무 한거 아닌가요?ㅠㅠ

'RestRoom > Routine' 카테고리의 다른 글

몸도 마음도 정화하리..? (2)	2012/01/19
2011 KUCIS 최우수동아리 & 기술문서 부분 최우수상 (0)	2011/12/21
해피캠퍼스는 멍청해!! (2)	2011/12/08
ATmega128 LCD password 실험 (0)	2011/11/17
2011년 5월 21일(토) KUCIS 호남권역 정보보호 세미나 (4)	2011/05/19
2011년 5월 14일(토) 서울여자대학교 제 12회 U3 정기 워크샵 (2)	2011/05/19

Immunity Debugger Hard Hooking

Ezbeat — Thu, 08 Dec 2011 19:31:40 +0900

일반적으로 hard 후킹하면 다들 생각하고 있는 것이 있죠. 맞습니다.

만약 kernel32.dll의 WinExec 함수를 하드후킹한다면 해당 함수 내부의 코드 5Byte를 jmp코드로 바꾸죠.
그리고 응용 프로그램에서 해당 함수가 호출되면 제가 만든 루틴으로 jmp문을 타고 들어오게 됩니다.
이 때부터 전 파라미터를 조작해버릴수도 있고 리턴 값을 조작해버릴 수도 있습니다.

예전엔 이 과정을 C로 테스팅해보고 실제로 사용도 해봤습니다.
만약 explorer.exe의 LoadLibrary 함수의 파라미터를 모니터링 할 때 순서입니다.

1. LoadLibrary를 하드후킹하는 코드를 작성하고 dll로 만든다.
2. dll injection을 사용해 해당 dll을 explorer.exe 프로세스에 injection한다.
3. 후킹이 성공되고 explorer에서 LoadLibrary가 호출 됬을 때
dll 내부 Hook루틴에서는 파라미터들 값을 낚아챈다.
4. 낚아챈 값을 파일로 저장하거나 파이프 통신을 사용해 내 프로세스에서 그 결과를 출력한다.

이런식으로 작동하게 되죠.

하지만 이번엔 Immunity Debugger에서 python 스크립트를 사용해 디버깅 중 하드후킹을 수행해 특정 함수의 인자를 모니터링 해보는 것입니다.

독백

Immunity Debugger에서는 immlib라는 아주 좋은 라이브러리를 제공해주는데 해당 라이브러리를 사용하면 짧은 코드로 후킹 작업을 할 수 있습니다. 일단 구현은 "파이썬 해킹 프로그래밍" 책을 보면서 구현해 보았고 후킹되는 함수는 달리해보았습니다.

Immunity Debugger를 보면 아래 command 창이 있습니다. 해당 창에서 windbg 명령어도 사용이 가능하며
위 그림과 같이 ! 를 붙히면 \PyCommands 폴더에 있는 python 스크립트를 실행할 수 있습니다. ( py 빼고 입력 )

이제 ezbeat.py 코드를 보기전에
후킹 당할 프로그램 코드와 ( C언어 ..-_-; 방금 위에서 말해놓고!! ) 후킹 결과화면을 보겠습니다.
후킹은 WinExec 함수를 후킹하였고 모니터링 할 값은 파라미터 2개와 리턴 값입니다.

단순히 계산기와 메모장 하나씩 각각 다른 속성으로 띄워주는 프로그램입니다.

실행 순서
1. 위 프로그램 Immunity Debugger에 붙힘
2. ezbeat.py 실행
3. 프로그램 실행
4. ezbeat.py 실행
5. log창 확인

해당 프로그램을 Immunity Debugger에 붙히고 ezbeat.py를 돌린 후 실행시켜보겠습니다.

성공적으로 후킹이 되었습니다.

log창을 확인 결과입니다.

훅이 2번 걸렸고 각각의 인자들은 저렇습니다.
그런데 첫번째 호출됬을 때 두번째 인자로 SW_NORMAL(0x01) 을 주었는데 왜 0x00으로 나왔냐..라고 궁금해하실 분들도 계실탠데.. 저도 왜 저런가 궁금해서 WinExec 함수 내부를 봐봤더니

저 부분에서 두번째 인자가 1일경우 점프를 하게 되고 "EBP+0xC" 자리에 ESI(0x00) 값으로 채워지는 것을 확인했습니다.
그냥 그런가보다 하고 넘어가주세요...;;

이제 ezbeat.py 코드를 보겠습니다.

# -*- coding: utf-8 -*-

from immlib import *
from libhook import *

# 후킹하기 위해 해당 함수의 ret 명령의 주소를 찾아준다.
def getRet(imm, allocaddr, max_opcodes = 500):
    addr = allocaddr

for a in range(0, max_opcodes):        
        # addr에 있는 값을 디스 어셈, 그 다음에  opCode 클래스에서 get 함수를 사용해 얻는 값은 다음 명령어 값
        op = imm.disasmForward( addr , 1 )  
        
        # 그 다음 명령어가 "RETN" 인지 체크
        if op.getDisasm().find("RETN") != -1:
            op = imm.disasmBackward( addr, 3)
            return op.getAddress()  # 맞으면 그 주소 리턴
            
        addr = op.getAddress()
        
    return 0x00

def main(args):
    imm = Debugger()
    Name = "ezbeat"
    
    # knowledge DB에서 Name 객체를 얻는다.
    fast = imm.getKnowledge(Name)
    
    # 얻기를 성공하면.. = 이미 후킹이 되어 있다면
    if fast:
        # 후킹 함수가 호출돼 로깅 함수들이 호출되면 로깅 함수는 FastLogHook 객체가 만든 메모리 영역에 로깅한 정보를 저장한다.
        # 저장된 로깅 정보를 보려면 getAlloLog() 래퍼 함수를 이용.
        # getAlloLog() 함수는 메모리의 내용을 파싱해 다음과 같은 형태의 파이썬 리스트를 반환
        # [(hook_address, (arg1,arg2,argN)), ... ]
        # list[0][0] => 후킹 된 주소
        # list[0][1][0] => arg1
        hook_list = fast.getAllLog()
        
        # 후킹된 함수의 주소를 얻어옴
        FuncRetAddr = imm.getKnowledge("HookFuncNames")     
        count = 0
        
        for a in hook_list:
            imm.log("WinExec(0x%08x,0x%08x) - ret : 0x%08x" % 
                    (hook_list[count][1][0],
                     hook_list[count][1][1],
                     hook_list[count][1][2]),
                    hook_list[count][0])
            
            count += 1

return "[*] Hook hit Num : %d" % len(hook_list)
        
        
    # 실질적인 후킹 설정 작업을 진행하기 전에 디버거를 일시 정지 시킨다.
    imm.pause()
    FuncAddr = imm.getAddress("kernel32.WinExec")
    
    # 모듈 정보를 얻음
    module = imm.getModule("kernel32.dll")
    
    # 모듈이 분석되지 않았으면 분석함
    if not module.isAnalysed():
        imm.analyseCode(module.getCodebase())
    
    FuncRetAddr = getRet(imm,FuncAddr)
    #imm.log("RET address : 0x%08x" % FuncRetAddr)
    
    # knowledge DB에 후킹할 주소를 넣는다.
    imm.addKnowledge("HookFuncNames", FuncRetAddr)
    
    # 이제 실질적인 후킹 설정 작업을 수행한다. stdcall 함수 cdecl은 STDCALL 뺌
    fast = STDCALLFastLogHook(imm)
    
    imm.log("Logging on WinExec 0x%08x" % FuncRetAddr)
    fast.logFunction(FuncRetAddr)   # 원래의 명령을 점프 코드로 덮음
    
    """
    fast.logRegister(register)      # 후킹 함수가 호출됐을 때 특정 레지스터의 값을 살펴볼 수 있음
    fast.logDirectMemory(address)   # 후킹 함수가 호출됐을 때 특정 메모리 주소의 데이터를 살펴볼 때 사용
    fast.logBaseDisplacement(register,offset)   # 스택의 파라미터 값을 참조하거나 레지스터로부터 특정 오프셋만큼 떨어진 곳의 데이터를 살펴볼 때 사용
    """
    
    # ret직전의 부근에서 후킹하기 때문에 EAX에는 리턴 값이 들어가 있고
    # 함수 프롤로그는 했지만 JMP문에 의해 LEAVE가 사라져서 에필로그는 실행 안된 상태
    fast.logBaseDisplacement("EBP",8)       # 첫번째 인자
    fast.logBaseDisplacement("EBP",0xC)     # 두번째 인자
    fast.logRegister("EAX")                 # 리턴 값
    
    # 후킹 설정
    fast.Hook()
    
    # 이후에 후킹 결과를 얻기 위해 후킹 객체를 저장한다.
    imm.addKnowledge(Name, fast, force_add = 1)   
    
    return "[*] Success Hooked"

주석은 최대한 자세히 달아보았습니다.
immlib 나 각 라이브러리에 있는 자세한 함수 설명은
http://debugger.immunityinc.com/Documentation/

이쪽으로 가시면 더욱 자세히 볼 수 있습니다.

이제 후킹 된 실제 어셈 코드를 봐보도록 하겠습니다.
WinExec 후킹 전 코드 일부분입니다.

후킹 후 코드 일부분입니다.

잘 비교해 보시면 어떤 부분이 달라졌는지 알 수 있습니다.
원본 코드는 어디로..?;; 일단 JMP문을 따라 들어가보겠습니다.

열심히 분석해서 주석을 달아놨습니다.
즉, 위 코드를 전체적인 그림으로 봐보면

여기서 얻을 인자 같은 것은 python코드를 짜는 사람 마음이기 때문에 후킹 코드와 원하는 값 저장할 크기는 유동적입니다.
그리고 python 코드를 보시면 getAllLog() 함수를 사용해 메모리로부터 값을 가져온다고 했는데 바로
0x00000080위치에서 가져오는 것 입니다. 실제로 저 위치에 있는 리턴 값을 0x64로 바꿔보고 실행해보겠습니다.

그리고 제가 알던 후킹방법하고 다른 점은 JMP로 덮힌 코드를 후킹 코드 내부에서 실행한다는 것입니다.
음... 나머지는.. 다들 알아서 해보시면 알 수 있을 것입니다. 글을 쓰다 잠시.. 정신놓고 어딜 갔다와서 갑자기 이상하네요.ㅠㅠ

Immunity 디버거에서 파이썬을 실행시킬 땐 PyCommand를 사용하는데
PyCommand를 만들 때 기본적인 템플릿이 존재합니다.

첫번째는 파라미터를 받아들이는 main()함수를 정의
두번째는 문자열을 리턴해야 한다는 것

위 코드를 잘보면 main함수의 인자로 받을 수 있게끔 args를 써주었고 리턴도 하고 있는 것을 볼 수 있다.
이것을 잘 응용하면 더욱 편하게 디버깅을 할수 있을 것 같네요..

'My Study > Programming&Theory' 카테고리의 다른 글

Remote Library Injection (4)	2011/12/29
OpenProcess를 막는 방법은?? (11)	2011/12/20
Immunity Debugger Hard Hooking (2)	2011/12/08
ScreenSaver 만들어보기 (3)	2011/11/30
API vs MFC (1)	2011/11/30
Prefix list in executive component (0)	2011/09/02

ScreenSaver 만들어보기

Ezbeat — Wed, 30 Nov 2011 18:21:57 +0900

플젝에 치여 이리저리 정신못차리고 있는 와중에 예전부터 한번쯤 만들어보고 싶었던 스크린 세이버 만드는 것을 잠자는 시간을 쪼개 익혀봤습니다. 공부했다고 하는것보단 이건 그냥 방법을 익혔다고 표현하는게 올바를 것 같습니다. ^^;;

API책을 보며 공부했습니다.

스크린 세이버는 컴퓨터를 해보신 분들이라면 누구나 한번쯤은 보신 화면일 것입니다.

익숙하신 화면이죠?? ;;ㅋ

이러한 스크린 세이버는 원래 두가지 용도로 사용이 되었습니다.

1. 오랫동안 화면이 정지되어 있을 경우 같은 위치에 정적인 그림이 계속 표시되므로써 모니터의 특정 부분만 빨리 손상되는 것을 방지하는 것. 이 기능은 스크린 세이버의 원래적인 용도에 부합되는 기능입니다.

2. 보안상 중요한 정보가 누출되는 것을 방지한다. 작업중 잠시 자리를 비울 경우 작업하던 내용을 누군가가 보거나 또는 파일 등의 정보를 훔쳐갈 수도 있는데 스크린 세이버는 화면을 잠금으로써 정보 누출을 방지하는 것..

하지만 요새는 모니터 성능도 좋아져서 1번 같은 경우의 용도로는 거의 사용이 안됩니다.
그리고 새로운 3번의 기능이 추가되었죠.

3. 일부러 모니터를 끄지 않고 자리를 비움으로써 사람들이 자기의 스크린 세이버를 보고 감탄해 하는 기능

제 주위만 해도 이러하신 분들이 수두룩 하시죠. 소녀시대 스크린 세이버부터...ㅎㅎ
하지만 저는 직접 코딩을 해 나만의 스크린 세이버를 만들어 보고 싶었습니다. 일단 이 글에선 간략한 샘플 코드만 만들어보죠.

스크린 세이버는 OS가 부팅될 때 함께 실행이 된다. 그리고 항상 사용자의 키보드와 마우스를 감시하며 제어판에서 지정한 시간동안 입력이 없을 경우 미리 지정되어 있는 스크린 세이버 애플릿을 실행합니다.

용어 정리
스크린 세이버 : 운영체제의 일부이며 항상 실행상태에서 사용자의 입력을 감시하는 프로그램
스크린 세이버 애플릿 : 스크린 세이버에 의해 호출되는 실행 파일(.scr)

이러한 스크린 세이버 애플릿이 실행이 안되는 경우가 있습니다.
1. 스크린 세이버 애플릿이 지정이 안되었을 경우
2. 윈도우 기반이 아닌 응용 프로그램이 실행 중일 때
3. 컴퓨터 교육 프로그램(CBT)이 실행중일 때
4. 한 프로그램이라도 스크린 세이버의 실행을 거부할 때

스크린 세이버 애플릿은 스크린 세이버에 의해 실행되며 사용자의 입력이 있으면 즉시 종료된다.

이제 간단한 샘플 코드를 작성해 볼 것인데 다행이도 Windows에서는 참 좋은 라이브러리를 지원해주고 있다.
바로 "ScrnSave.lib" 이다.

애플릿 개발자들이 애플릿이 언제 호출될지 설정 대화상자는 언제 어떻게 보여줄지, 제목 문자열은 어디에 넣어둘지 등을 다 생각해서 개발을 한다면 어려움에 호소할 것이다. 그래서 이러한 문제는 없애기 위해 스크린 세이버 라이브러리를 제공하며 대부분의 약속이 이미 프로그래밍되어 있으므로 애플릿은 스크린 세이버 라이브러리와 연결하고 자신의 고유한 화면 처리만 하면 된다.

샘플 코드를 봐보자.

#include <Windows.h>
#include <tchar.h>
#include <ScrnSave.h>

#ifdef UNICODE
#pragma comment(lib, "ScrnSavW.lib")
#else
#pragma comment(lib, "ScrnSave.lib")
#endif

#pragma comment(lib,"ComCtl32.lib")

/* 
	스크린 세이버의 메시지를 처리하는 메시지 프로시저
	원형도 WndProc과 동일하며 프로그래밍 방법도 동일
	스크린 세이버 라이브러리는 애플릿에 적절한 전체화면의 검정색 배경에 항상 위 옵션으로 메인 윈도우를 만들며
	메인 윈도우의 메시지 프로시저로 이 함수를 지정한다. 
	이 함수에서 처리하지 않는 메시지는 DefScreenSaverProc함수로 전달하여 스크린 세이버 라이브러리가 처리
*/
LRESULT WINAPI ScreenSaverProc(HWND hWnd, UINT iMessage, WPARAM wParam, LPARAM lParam)
{
	HDC hdc;
	PAINTSTRUCT ps;
	TCHAR *Mes = _T("http://ezbeat.tistory.com");

switch(iMessage){
	case WM_CREATE:
		return 0;

case WM_PAINT:
		hdc = BeginPaint(hWnd,&ps);
		SetBkMode(hdc,TRANSPARENT);
		SetTextColor(hdc,RGB(255,255,255));
		TextOut(hdc,500,500,Mes,_tcslen(Mes));

MoveToEx(hdc,500,500,NULL);
		Ellipse(hdc,200,200,300,300);
		EndPaint(hWnd,&ps);
		return 0;
	}
	return DefScreenSaverProc(hWnd,iMessage,wParam,lParam);
}

/*
	설정 대화상자의 메시지 처리 함수. 일반적인 대화상자 메시지 프로시저와 동일
	사용자로부터 설정 상태를 입력받아 약속된 장소(보통 레지스트리)에 저장하는 역할
*/
BOOL WINAPI ScreenSaverConfigureDialog(HWND hDlg, UINT iMessage, WPARAM wParam, LPARAM lParam)
{
	return TRUE;
}

/*
	커스텀 컨트롤을 등록할 때 사용. 보통 TRUE를 리턴하면 된다.*
*/
BOOL WINAPI RegisterDialogClasses(HANDLE hInst)
{
	return TRUE;
}

위 사용된 3개의 함수는 필수적으로 있어야 한다. 각 함수에 대한 설명은 주석으로 간략히 달아놨다.

그리고 위에 참조할 라이브러리를 지정해주어야하는데
유니코드 기반으로 프로그래밍 하려면 "ScrnSavW.lib" 라이브러리를 사용해주면 된다.
이 부분에서 잘 안되서 애먹었다.;;

http://blog.naver.com/PostView.nhn?blogId=sainthkh&logNo=140062316898&categoryNo=59&viewDate=¤tPage=1&listtype=0
위 블로그에 잘 설명이 되어 있었다 ^^; 감사합니다~

또한 스크린 세이버 애플릿 파일은 확장자가 .exe가 아닌 .scr 입니다.
그렇기 때문에 아래와 같이 셋팅을 해주고 컴파일을 해주어야합니다.
하지 않으면 실행할때마다 확장자를 바꾸고 실행하는 번거로움을 겪에 될 것 입니다.

이제 실행된 결과 화면을 봐보자.

잘 만들어져 졌군요. 저 상태에서 키가 눌린다거나 마우스 입력이 들어오면 바로 스크린 세이버창은 꺼지게 됩니다.
이제 이것을 응용해 저만의 스크린 세이버 애플릿을 만들어보겠습니다.

멋지게 만들고 싶었지만 그럴 시간은 없어서 초간단으로 만들었습니다.

Ezbeat.scr

끝... -_-.. 심심하신분은 실행해보세요오.. scr 이라고해서 바이러스 절대 아닙니다! ㅋㄷㅋㄷ

'My Study > Programming&Theory' 카테고리의 다른 글

OpenProcess를 막는 방법은?? (11)	2011/12/20
Immunity Debugger Hard Hooking (2)	2011/12/08
ScreenSaver 만들어보기 (3)	2011/11/30
API vs MFC (1)	2011/11/30
Prefix list in executive component (0)	2011/09/02
API Listbox에서 가로 스크롤 넣기 (1)	2011/08/10

API vs MFC

Ezbeat — Wed, 30 Nov 2011 01:07:15 +0900

많은 사람들은 항상 이야기를 한다. "MFC가 좋아요? API가 좋아요? 라고..

그리고 많은 사람들은 MFC도 짜증나고 API도 짜증난다고 말한다.

모든 사람들은 다음과 같이 말한다.

API는 너무 어렵다.

MFC는 너무 복잡하다.

API는 너무 코드 양이 많다.

MFC는 부풀어 있다.

API는 마법사가 없다.

MFC는 나쁘게 설계되어 있다.

API는 객체지향하지 않다.

MFC는 내 개를 걷어찼다.?!

API는 나의 여자친구를 빼앗아갔다.?!

어디서 본 글이고 공감되서 써봤습니다.
마지막 두 문장은 애매모하네요.
API가 나의 여자친구를 빼앗아 갔다는 것은
그만큼 코드짜는데 시간이 걸리기 때문에 여자친구를 만나지 못해 헤어졌다는 말 같은데...
MFC가 내 개를 걷어찼다는 것이 무슨 말인지..ㅠ
원본 문장은 이렇습니다. - "MFC kicked my dog"

혹시 무슨 뜻인지 아시는 분은 댓글로좀 알려주세요 ㅠ_ㅠ..

'My Study > Programming&Theory' 카테고리의 다른 글

Immunity Debugger Hard Hooking (2)	2011/12/08
ScreenSaver 만들어보기 (3)	2011/11/30
API vs MFC (1)	2011/11/30
Prefix list in executive component (0)	2011/09/02
API Listbox에서 가로 스크롤 넣기 (1)	2011/08/10
커널 데이터 버퍼 (0)	2011/07/26

ATmega128 LCD password 실험

Ezbeat — Thu, 17 Nov 2011 22:57:49 +0900

요샌.. 학과공부에 너무 치여 이도저도 못하고 있는 저 입니다..ㅠㅠ
하드웨어도 배우는데 지금까지 ATmega128을 가지고 간단한 실습들을 하였고
다음시간부터 micro mouse를 가지고 길 찾기 프로젝트를 해야합니다..ㅠㅠ

별의별걸 다 실험했지만 ATmega128로 실험한 마지막 실습은 영상으로 남겼습니다..ㅠㅠ
그냥 올립니다..ㅠㅠ

USART0을 사용했고.. 시그널 처리를 해 만든 것입니다.

ATmega128.. 이로서 실습이 끝났지만..ㅠㅠ 학교에 반납해야한다는거..;;
나중에 micro mouse도 제대로 작동하게 만들면 영상 올리겠습니다~

하드웨어도 은근히 잼는거 같아요.. 아직 이론적 지식이 부족한거 같지만요 ;;ㅋ

'RestRoom > Routine' 카테고리의 다른 글

2011 KUCIS 최우수동아리 & 기술문서 부분 최우수상 (0)	2011/12/21
해피캠퍼스는 멍청해!! (2)	2011/12/08
ATmega128 LCD password 실험 (0)	2011/11/17
2011년 5월 21일(토) KUCIS 호남권역 정보보호 세미나 (4)	2011/05/19
2011년 5월 14일(토) 서울여자대학교 제 12회 U3 정기 워크샵 (2)	2011/05/19
SBS 고릴라 라디오 (0)	2011/01/25

Prefix list in executive component

Ezbeat — Fri, 02 Sep 2011 17:58:12 +0900

윈도우 시스템 루틴의 명명 규칙을 이해한다면 이들 익스포트된 함수의 이름을 좀 더 쉽게 해독할 수 있다.

일반적인 형태
<Prefix><Operation><Object>

Prefix : 루틴을 익스포트하는 내부 컴포넌트
Operation : 객체나 리소스에 행해지는 동작
Object : 동작 대상

'My Study > Programming&Theory' 카테고리의 다른 글

ScreenSaver 만들어보기 (3)	2011/11/30
API vs MFC (1)	2011/11/30
Prefix list in executive component (0)	2011/09/02
API Listbox에서 가로 스크롤 넣기 (1)	2011/08/10
커널 데이터 버퍼 (0)	2011/07/26
Data Read/Write in Cache (0)	2011/07/12

API Listbox에서 가로 스크롤 넣기

Ezbeat — Wed, 10 Aug 2011 12:04:47 +0900

현재 프로젝트를 하고 있던 도중 리스트박스를 만들어서 파일 경로를 얻어오는 부분을 구현하고 있었습니다.
뭐 다른 부분은 문제가 되질 않지만 파일 경로가 길어질 경우 리스트박스 가로 길이를 넘어서게 되서 뒷 부분이 짤려서 안보이게 되더군요.

보시면 저렇게 짤려있습니다;;

전 평소대로 생각했습니다. 그냥 리스트박스 속성창 뒤져보면 있겠지.. 찾아보았더니 있더군요?!

디폴트 False로 되어 있어서 저 값을 True로 바꾸고 다시 실행시켜보았더니!
가로 스크롤은 안생기더군요.......... 그래서 인터넷에 찾아보니 친절히 코드가 있어서 그걸 가져다 사용해 보았습니다.
( 뭔가 오류가 쫌 있어서 살짝 바꾸기만 했습니다. )

출처 : http://stpetrus27.wordpress.com/2009/03/15/win32-control-listbox-%E3%80%90horizontal-scroll%E3%80%91/

코드는 그렇게 복잡하진 않습니다.
현재 리스트박스에 있는 문자열들의 가로 길이를 얻어와서
가장 긴 값을 가지고 LB_SETHORIZONTALEXTENT 메시지를 넘기는 것입니다.

그러면 리스트 박스에 가로 스크롤이 가능한 너비를 Pixel 단위로 지정 되게 되면서 가로 스크롤이 생기게 됩니다.
( 마지막에 뒷부분이 조금 잘리길래 +20 정도를 더 해주었습니다. )

리스트 박스에 LB_ADDSTRING 메시지로 값을 추가했을 때 바로 그 아래 문장에 해당 함수를 호출시켜주면 됩니다.
당연히 리스트박스 속성창에서 Horizontal Scroll 값은 True로 해주어야 합니다.
False로 했을 경우 위 함수를 적용시켜도 스크롤 바는 생기지 않습니다.

만족스럽습니다. 이런거에서 시간을 낭비하고 있다니..ㅠ_ㅠ .. 짜증나는군요.

'My Study > Programming&Theory' 카테고리의 다른 글

API vs MFC (1)	2011/11/30
Prefix list in executive component (0)	2011/09/02
API Listbox에서 가로 스크롤 넣기 (1)	2011/08/10
커널 데이터 버퍼 (0)	2011/07/26
Data Read/Write in Cache (0)	2011/07/12
Windows Cache (2)	2011/05/31