Ezbeat의 도서관

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% 밖에 벗어나질 않는군요.

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

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 이벤트로 작업관리자를 죽였나봅니다.

정답!

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

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++도 잘 활용할줄 알아야하는데.. 큰일입니다.
아무튼 이렇게 많은 언어들이 있다는 것도 첨 알았네요. 별별 언어가 다있네요 =_=;;

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

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 해줌 됩니다. =_=;;

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 호출.. 뭐 이런식입니다.

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

그만 쓸래요! 으악!

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 함수

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

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 함수.. 이렇게 작동합니다. .ㅎㅎ 허무..;

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 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)

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

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

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을 가지고 테스트 해봐야겠네요.
아무튼 다른 실시간 모니터링 부분은 몰라도 디스크 모니터링 하는 부분은 우회가 가능한 방법입니다.

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를 계속 시도하였습니다.

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

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

해피캠퍼스는 멍청해!!

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

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

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

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

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

고로 당연히 컴파일도

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

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

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

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

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

너무 한거 아닌가요?ㅠㅠ

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를 써주었고 리턴도 하고 있는 것을 볼 수 있다.
이것을 잘 응용하면 더욱 편하게 디버깅을 할수 있을 것 같네요..

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 이라고해서 바이러스 절대 아닙니다! ㅋㄷㅋㄷ

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"

혹시 무슨 뜻인지 아시는 분은 댓글로좀 알려주세요 ㅠ_ㅠ..

ATmega128 LCD password 실험

Ezbeat — Thu, 17 Nov 2011 22:57:49 +0900

요샌.. 학과공부에 너무 치여 이도저도 못하고 있는 저 입니다..ㅠㅠ
하드웨어도 배우는데 지금까지 ATmega128을 가지고 간단한 실습들을 하였고
다음시간부터 micro mouse를 가지고 길 찾기 프로젝트를 해야합니다..ㅠㅠ

별의별걸 다 실험했지만 ATmega128로 실험한 마지막 실습은 영상으로 남겼습니다..ㅠㅠ
그냥 올립니다..ㅠㅠ

USART0을 사용했고.. 시그널 처리를 해 만든 것입니다.

ATmega128.. 이로서 실습이 끝났지만..ㅠㅠ 학교에 반납해야한다는거..;;
나중에 micro mouse도 제대로 작동하게 만들면 영상 올리겠습니다~

하드웨어도 은근히 잼는거 같아요.. 아직 이론적 지식이 부족한거 같지만요 ;;ㅋ

Prefix list in executive component

Ezbeat — Fri, 02 Sep 2011 17:58:12 +0900

윈도우 시스템 루틴의 명명 규칙을 이해한다면 이들 익스포트된 함수의 이름을 좀 더 쉽게 해독할 수 있다.

일반적인 형태
<Prefix><Operation><Object>

Prefix : 루틴을 익스포트하는 내부 컴포넌트
Operation : 객체나 리소스에 행해지는 동작
Object : 동작 대상

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로 했을 경우 위 함수를 적용시켜도 스크롤 바는 생기지 않습니다.

만족스럽습니다. 이런거에서 시간을 낭비하고 있다니..ㅠ_ㅠ .. 짜증나는군요.

바로가기

Ezbeat — Sun, 31 Jul 2011 22:50:44 +0900

오늘 학교를 가기엔 너무 덥고.. 집에 있기엔 짜증이 나서 광천터미널에 영풍문고를 가보기로 마음 먹음.
가서 베스트 셀러를 읽을 생각이었지만 내 의지와 상관없이 몸이 IT서적 있는데로 직행.. 어쩔수없는 본능.

뭐 하나만 보기로 하고 윈도우 포렌식 책을 들었는데 목차에 윈도우 바로가기에 대한 내용이 있어서 읽어봤는데 재미있더군요.냥 머리속에만 남기기 뭐해서 정리합니다.

================================================
바로가기(shortcut)이라고 불리는 링크 파일은 윈도우에만 있는 독특한 기능이다.
여기서 궁금하실수도 있는데 리눅스에서도 심볼릭링크라고해서 바로가기와 같은 기능을 하는 놈이 있다.
그러면 이 두개는 뭐가 다르냐는 것이다.

정확히 말하면 윈도우에 심볼릭 링크가 본격적으로 지원되기 시작한 것은 Vista 이후부터다.
고로 윈도우에는 바로 가기와 심볼릭 링크가 동시에 존재하므로 이 둘은 같다고 할 수 없다.

먼저 바로가기와 심볼릭 링크의 가장 큰 차이점이다.

심볼릭 링크 : 파일 시스템 수준에서 구현
1. 파일 시스템이 보기에는 심볼릭 링크라는 별도의 파일이 아닌 그것이 바리키고 있는 대상 파일로 보임.
즉, 중간에 있는 심볼릭 링크는 애플리케이션에는 완전히 투명
2. 대상에 대한 절대 경로 혹은 상태 경로에 대한 정보만 가지고 있다.

바로 가기 : 애플리케이션 수준에서 구현
1. 그 자체가 완벽한 하나의 파일.
즉, 바로 가기는 파일이 가지고 있어야만 하는 모든 메타데이터와 MFT 엔트리를 가지고 있다.
파일 시스템이 보기에도 완전히 독립적인 별개의 파일로 보이고,
바로 가기를 사용하기 위해서는 애플리케이션 혹은 OS 수준에서 별도의 기능이 필요
2. 대상에 대한 절대 경로만 가지고 있다.

바로 가기의 정식 명칭은 'Shell Link'로, 'Shell Link Binary File Format' 으로 만들어진 파일임을 의미
이 Shell Link Binary File Format의 기능과 구조는 MS 문서에 자세히 나와있다.
( 쉽게 찾으실 수 있겠지만 나와 같이 게으르신 분을 위해 파일을 그냥 올립니다. )

ms-shllink-pdf.pdf

바로 가기라서 간단할꺼 같지만 문서 양을 보면 52p에 달한다..

제가 읽은 책이 윈도우 포렌식이라서 바로 가기에 반드시 필요한 부분과 포렌식 관점에서 중요한 부분만 설명하겠습니다.

바로 가기 생성
● 윈도우 설치 시
가장 대표적인 예는 윈도우를 처음 설치할 때 바탕 화면에 생기는 '내 컴퓨터' 같은 기본 바로 가기들이다.
이 외에도 작업 표시줄에 있는 아이콘이나 '내 음악' 폴더에 있는 'sample music'과 같은 파일들도 모두 바로 가기로 만들어 진다.

제가 쓰는 작업 표시줄 일부인데 이렇게 각각 아이콘들이 전부 바로 가기들입니다.

위 그림은 Windows 7에서의 모양이고 아래는 Windows XP에서의 모양입니다.

● 윈도우 설치 후
윈도우는 사용자의 편의를 위해 최근에 열었던 문서들의 목록을 자동으로 저장한다. 그 목록은 단순한 문자열이 아니라 모두 바로 가기들이다.

● 애플리케이션 설치 시
대부분 애플리케이션은 설치 과정에서 사용자에게 바탕 화면이나 작업 표시줄, 그리고 시작 모튜에 새로 설치한 애플리케이션의 바로 가기 항목을 만들지를 물어본다. 만들겠다고하면 설치 과정에서 자동으로 바로 가기를 만들어준다.

● 사용자가 생성
너무 당연한 이야기이다. 바로 가기 안 만들어본 분이 계시려나..

파일에 대고 우클릭을 하면 위와 같이 나오며 바로 가기 만들기를 누르면 끝이다.. 흠..

이제 바로 가기의 구조를 알아보자

바로 가기의 구조
바로 가기가 가지고 있는 정보 종류는 바로 가기 파일의 속성 정보 창에서 바로 가기 탭을 보면 대충은 알 수 있다.
난 notepad.exe를 대상으로 해보았다.

원본 파일의 종류, 전체 경로, 실행 옵션 등 기본적인 정보들만 있는거 같지만 이것은 바로 가기가 가지고 있는 전체 정보의 극히 일부분에 지나지 않는다.

제대로 파고 들어가기 전에 일반적으로 해킹대회 때나 리버싱 할 때 사용하는 Hex Editor로 열어보았다.
( 파일의 모든 내용을 볼 수 있으므로.. )
보고 싶은 분만 보시길.. 이 파일에 대한 설명은 하지 않겠다. 딱 봐도 뭔가 이상한 정보들이 많이 있다는것 정도는 알수 있다.

Hex Editor로 열어본 바로 가기

바로 가기는 다음과 같이 크게 다섯 부분으로 나눌 수 있다. 각 부분들은 저마다 고유한 내부 구조를 가지고 있다.

SHELL_LINK_HEADER: 식별 정보, 타임 스탬프, 그리고 선택 가능한 구조의 존재 유무를 표시하는 플래그를 저장
LINKTARGET_IDLIST : 원본에 대한 정보를 담고 있다.
이 구조는 Shell Link Binary File Format에서 선택 사항이지만
바로 가기에서는 필수적인 항목
LINKINFO : 원본의 위치를 찾을 때 필요한 정보를 담고 있다. 이 역시 선택 항목
STRING_DATA : 사용자 인터페이스나 경로 식별 정보를 가지고 있다.
EXTRA_DATA : 기타 정보를 가지고 있다.

이제 하나하나 세세하게 알아보자.

SHELL_LINK_HEADER

실제 Hex Editor에 있는 값과 비교해 가면서 적어본 것이다.

중요한 것만 몇가지 집고 넘어가겠다.
CLSID는 고정적인 값으로 바로 가기를 찾는데 중요한 역할을 할 수 있다.

SHELL_LINK_HEADER의 LinkFlag

LINKTARGET_IDLIST
바로 가기에서 LINKTARGET_IDLIST는 필수적인 항목이다. LINKTARGET_IDLIST는 2Byte에 걸쳐 IDList의 크기가 나오고 그 뒤에 가변 길이의 IDList가 나온다. IDList의 크기가 가변적이기 때문에 당연히 LINKTARGET_IDLIST의 크기도 가변적이다.
IDList는 다시 두 부분으로 나뉘는데, 첫 번째 부분은 2Byte의 고정 길이를 갖는 ItemIDSize이며, 그 뒤로는 가변 길이의 Data가 붙게 된다. IDList의 데이터는 일정한 구조가 없다. IDList의 끝에는 IDList의 끝을 알리는 2Byte크기의 예약 영역이 나오는데, 이것은 모두 0으로 채워져 있으며 TerminalID라고 부른다.

010 Editor 툴로 보면 쉽게 그 구조를 파악할 수 있다.

IDListSize가 223이라고 나왔는데 223 = 0xDF이다.
그 아래로 IDList 구조체 배열이 0,1,2,3 쭉 있다.

LINKINFO
LinkInfo도 바로 가기에 필수적인 요소이며, 원본 파일이 정해진 위치에 없는 경우 그것을 찾기 위한 필수 정보들을 가지고 있다. 그 필수 정보에는 원본이 저장되어 있던 볼륨의 정보 혹은 맵드 드라이브 문자, 원본까지의 UNC 경로 등이 포함된다.

LinkInfo Flag는 특이하게도 전체 32비트 중에서 좌측 2비트만을 사용하는데 그 의미는 아래와 같다.

VolumeID필드는 바로 가기가 생성될 당시에 원본이 있던 볼륨의 데이터를 가지고 있다.
이 정보는 원본이 제 위치에 없는 경우 원본을 찾는데 이용된다. 컴퓨터 포렌식 관점에서 이 정보는 매우 중요.
바로 가기의 링크가 끊어졌다면 우리는 이 볼륨 정보를 보고 사라진 볼륨에 대한 힌트를 얻을 수 있다.

VolumeID 구조 ( 010 Editor로 그냥 봄.. )

STRING_DATA
이 구조체는 사용자 인터페이스와 경로 식별자를 알려주는 일련의 문자열들로 구성.
각 문자열은 앞에 2Byte 길이의 문자열 크기가 먼저 나오고, 그 다음에 그에 해당하는 길이만큼의 문자열이 뒤따른다.
이 구조체에 올 수 있는 문자열의 종류는 LinkFlags에 따라 결정되며 가능한 문자열은 다음과 같다.

NAME_STRING : 바로 가기에 대한 설명을 가지고 있다.
RELATIVE_PATH : 바로 가기를 기준으로 원본까지의 상대 주소를 가지고 있다.
WORKING_DIR : 바로 가기를 활성화시켰을 때 사용할 수 있는 working directory의 주소를 가지고 있다.
COMMAND_LINE_ARGUMENTS : 애플리케이션을 실행할 때 사용한 명령 옵션을 가지고 있다.
ICON_LOCATION : 바로 가기를 사용자에게 보여줄 때 사용할 아이콘의 위치 정보를 가지고 있다.

제가 테스트한 notepad.exe의 바로가기에는 다음과 같은 정보가 있다.

RELATIVE_PATH ,WORKING_DIR 두 정보가 있었다.

EXTRA_DATA
이 구조체는 말 그대로 원본에 대한 추가 정보를 가지고 있다.
5가지 중요 정보 중에서 가장 방대한 크기를 차지하고 있었다.

추가될 수 있는 정보의 종류가 많지만 필요한 부분만 정리해보겠다.

지금까지 바로 가기에 대해서 분석해 보았는데 이 간단한 놈이 이렇게 복잡한 내용을 담고 있다는 것은 처음 알았다.

커널 데이터 버퍼

Ezbeat — Tue, 26 Jul 2011 12:05:08 +0900

정리차원에서 간략히 올립니다.

I/O를 요청한 스레드나 프로세스의 데이터 버퍼에 대한 정보는 IRP 구조체에 저장되어 있다.
드라이버에 I/O 요청과 관련된 스레드나 프로세스의 데이터 버퍼를 설명하기 위한 세 가지 서로 다른 방법을 제공

Direct I/O : MDL(Memory Descriptor List)이라 불리는 구조체를 사용하여 I/O를 요청한
스레드의 물리 주소 공간에 위치한 데이터 영역을 가리키는 방식

Buffered I/O : 버퍼에 저장된 데이터가 I/O를 요청한 스레드의 주소 공간에서 시스템 주소 공간에
있는 임시 영역으로 복사되고, 드라이버는 복사된 데이터의 버퍼 포인터를 사용하는 방식

Neither I/O : 드라이버는 버퍼에 해당하는 I/O를 요청한 스레드의 가상 주소를 제공하는 방식

드라이버는 I/O 관리자가 어떤 물리 장치에 전달되는 모든 IRP_MJ_READ/IRP_MJ_WRITE 요청이 어떤 방식으로 데이터를 주소받는지 알수 있도록 한 가지 방식을 선택해야 한다.

디바이스 오브젝트가 생성됐을 때 필요한 정보를 초기화하는 과정에서 디바이스 오브젝트에 있는 Flags 필드에 있는 특정 정보를 설정함으로써 가능

DeviceObject->Flags |= DO_BUFFERED_IO; // Buffered I/O
DeviceObject->Flags |= DO_DIRECT_IO; // Direct I/O

아무 설정도 하지 않으면 디폴트로 Neither I/O 방식

이번엔 디바이스 I/O 컨트롤 코드에서 사용하는 버퍼 방식에 대해 알아보겠다.

위 그림은 IOCTL 코드인데 IOCTL코드를 만드는 매크로가 winioctl.h에 정의되어 있다.

#define CTL_CODE( DeviceType, Function, Method, Access ) ( \

((DeviceType) << 16) | ((Access) << 14) | ((Function) << 2) | (Method) \

)

저기서 Method 라고 된 부분이 처리하고자 하는 I/O 요청을 위해 제공된 데이터 버퍼를 설명하기 위해 사용된다.

다시 말해 Method 인자는 DeviceIoControl() 함수 호출 시 제공되는 두 개의 데이터 버퍼(입력버퍼, 출력 버퍼)에
대한 정보를 드라이버에 알린다.

I/O 컨트롤 코드에서 제공하는 데이터 버퍼를 설명하기 위한 서로 다른 세가지 방식에 대해서 알아보자.

METHOD_BUFFERED : DeviceIoControl() 함수에서 제공하는 입력 버퍼와 출력 버퍼를 Buffered I/O 방식으로 처리

METHOD_IN_DIRECT & METHOD_OUT_DIRECT : DeviceIoControl() 함수에서 제공되는 입력 버퍼를 Buffered I/O 방식으로 처리하고 출력 버퍼를 Direct I/O 방식으로 처리

여기서 IN과 OUT의 유일한 차이점
I/O 관리자가 처리하는 출력 버퍼에 대한 액세스 권한 조사.
METHOD_IN_DIRECT - I/O 관리자는 I/O를 요청한 스레드가 출력 버퍼에 대한 읽기 권한을 가지고 있는지 조사한다.
이 경우 출력 버퍼는 드라이버에 대한 입력 값으로 사용한다.
METHOD_OUT_DIRECT - I/O 관리자는 I/O를 요청한 스레드가 출력 버퍼에 대한 쓰기 권한을 가지고 있는지 조사한다.

METHOD_NEITHER : DeviceIoControl() 함수에서 제공되는 입력 버퍼와 출력 버퍼를 Neither I/O 방식으로 처리

IOCTL 코드에서 사용되는 버퍼링 방법에 대해 간단히 요약한 표

.text section disasm

Ezbeat — Tue, 26 Jul 2011 00:07:15 +0900

예전에 1010으로된 Opcode를 손으로 직접 ModR/M Byte표와 SIB Byte를 표를 봐가며 어셈코드로 바꿔본적이 있다. 하지만 이걸 자동화 툴로 만든다는건 엄청난 시간적 노력이 필요하다. 마침 문서를 읽다가 이러한 모듈이 이미 제공되고 있다는 것을 알고 그것을 토대로 간단한 프로그램을 만들어보았다.

쓸모는 없지만 나중에 기회가 되면 OllyDbg처럼 멋지게 만들어보고 싶다.

disasm을 하는데 있어서 사용한 코드는 PVDasm 이라는 툴에서 사용하는 엔진 코드를 가져왔다.
해당 코드는 인터넷에서 찾아보면 쉽게 구할 수 있을 것이다.

내가 만든 툴은 이렇다.
argv[1]에 타겟 프로그램을 올리고 실행
해당 파일에서 .text섹션에 있는 코드만 전부 디스어셈블링 해준다.

consol창에서 보여주는건 한계가 있어서 파일로 저장도 하게끔 해놓았다.

왼쪽 그림은 올리디버거에서 켜본것이고 오른쪽은 내가 만든 툴이 읽어서 변환한 내용이다.

심심하신 분들은 테스트해보세요.;;

.text_disasm.exe

Data Read/Write in Cache

Ezbeat — Tue, 12 Jul 2011 10:40:23 +0900

프로젝트 때문에 파일 시스템 필터 드라이버를 만들어봐야되는데 파일 시스템 필터 드라이버 같은 경우는 캐시 개념이 빠질수가 없습니다. 그래서 책 공부하다가 중요한 내용이 나와 정리 차원에서 올려봅니다.
====================================================================================================
데이터의 처리와 관련된 부분은 데이터 읽기와 쓰기 과정에서 거의 처리된다. 그리고 나머지 부분은 캐시 관리자가 제공하는 함수들의 사용법만 이해하면 된다.

데이터 읽기 동작

<출처 : 드라이버 개발자를 위한 윈도우 파일 시스템 - 데이터 읽기 동작>

항상 애플리케이션에서 전달되는 모든 동작은 I/O 관리자를 거쳐 파일 시스템 드라이버에 전달된다.
이제 각 번호를 설명하겠다.

1. 애플리케이션이 ReadFile() Win32 API 함수를 사용하여 데이터 읽기 동작을 요청하고, 제어는 커널에 있는 I/O 관리자에 전달된다.

2. I/O 관리자는 애플리케이션에서 전달된 데이터 읽기 동작에 대한 IRP를 생성한 뒤 이를 직접 적절한 파일 시스템 드라이버에 전달한다.

애플리케이션과 데이터를 주고받기 위해 사용되는 메모리 관리 기법에는 세 가지 방식이 있다. 첫째는 사용자가 유저 모드에서 할당된 메모리의 내용을 커널 모드의 시스템 가상 주소 공간으로 복사하는 Buffered 방식이다. 둘째는 입출력 관리자가 사용자 버퍼를 가리키는 MDL(Memory Descriptor List)을 할당하고 MDL과 관련된 페이지를 보호하는 방식을 택함으로써 데이터의 복사 과정 없이 직접 유저 모드에서 할당된 메모리와 데이터를 주고받는 DMA 방식이다. 마지막은 유저 모드에서 할당된 가상 주소를 I/O 관리자가 수정하지 않은 상태로 파일 시스템 드라이버에 전달하는 Neither 방식이다. 일반적으로 대부분의 파일 시스템 드라이버와 통신을 하기 위해 사용되는 방식은 MDL이며, 가끔 Neither 방식을 사용하는 경우도 있다. 단, Neither 방식을 선택한 경우에는 항상 스레드 컨텍스트가 유저 모드 컨텍스트와 일치해야 한다.

3. 파일 시스템 드라이버가 데이터 읽기 요청을 받고 Buffered 액세스를 위해 오픈된 파일에 직접 데이터 읽기 동작을 지시한다. 이 경우 데이터 읽기 동작을 실행하고자 하는 파일이 캐싱되지 않았다면 (FileObject->PrivateCachedMap == NULL) 파일 시스템 드라이버가 캐시 관리자를 호출하여 파일에 대한 캐싱을 초기화하고, 캐시 관리자는 VMM(Virtual Memory Manager)에 캐시된 파일을 위해 파일 매핑(섹션 오브젝트)을 생성하도록 지시한다.

4. 파일 시스템 드라이버는 캐시 관리자에서 제공하는 CcCopyRead() 함수를 사용하여 데이터 읽기 요청을 캐시 관리자에게 전달한다. 캐시 관리자는 이 요청을 받은 후 사용자 버퍼에 데이터를 전달하기 위해 필요한 모든 단계를 담당한다. 이후 데이터를 캐싱하기 위한 단계는 전적으로 캐시 관리자가 담당한다.

5. 캐시 관리자는 파일의 데이터 구조를 검사하고, 사용자가 요청한 데이터 영역의 값에 대한 매핑된 뷰가 있는지 결정한다. 이때 매핑된 뷰가 없으면 캐시 관리자는 매핑된 뷰를 생성한다.

6. 캐시 관리자는 매핑된 뷰에서 사용자 버퍼로 메모리 복사를 수행한다.

7. 파일의 매핑된 뷰가 실제 요구된 데이터를 포함하는 물리 페이지와 연결되어 있지 않으면 페이지 오류가 발생하고, 페이지 오류를 해결하기 위한 필요한 동작을 수행하도록 가상 메모리 관리자에 제어를 넘긴다.

8. VMM은 물리 페이지를 할당하고 I/O 관리자를 통해 파일 시스템 드라이버에 물리 디스크에서 데이터를 읽기 위한 I/O(Non-cached Paging I/O Read) 요청을 전달한다.

9. Non-cached 데이터 읽기 요청을 받은 파일 시스템 드라이버는 하드 디스크와 같은 보조 저장 장치에 있는 데이터를 얻기 위한 I/O 요청을 생성한다. 그리고 새로 생성된 I/O 요청을 디스크 드라이버나 SCSI 드라이버와 같은 실제 보조 저장 장치를 관리하는 하위 레벨 드라이버에 전달한다.

10. 계층 구조상 파일 시스템 드라이버 아래에 위치하는 디스크 드라이버와 같은 하위 레벨 드라이버가 보조 저장 장치에서 데이터를 얻고 I/O 요청을 종료한다.

11. 파일 시스템 드라이버는 가상 메모리 관리자가 요구한 페이징 I/O 요청을 종료하고, 제어를 가상 메모리 관리자에 전달한다.

12. 페이지 오류를 발생시켰던 명령을 다시 실행한다.

13. 캐시 관리자는 파일의 매핑된 뷰에서 사용자 버퍼로 데이터 복사를 완료한다.

14. 캐시 관리자는 캐시된 데이터를 사용자 버퍼로 복사한 후, 제어를 파일 시스템 드라이버에 전달한다. 이때 데이터는 아직 캐시 관리자가 사용하기 위한 가상 주소 공간에 캐시된 상태로 남아 있다.

15. 파일 시스템 드라이버는 I/O 관리자가 처음에 전달한 IRP에 대한 처리를 종료한다.

16. I/O 관리자가 데이터 읽기 요청을 완료한다.

데이터 저장 동작

<출처 : 드라이버 개발자를 위한 윈도우 파일 시스템 - 데이터 쓰기 동작>

데이터 저장 동작은 위에서 설명한 데이터 읽기 동작과 유사하다.

1. 애플리케이션이 WriteFile() Win32 API 함수를 호출하여 데이터 저장을 요청하고, 제어는 커널에 있는 I/O 관리자로 이동한다.

2. I/O 관리자가 IRP를 생성하여 적절한 파일 시스템 드라이버에 직접 데이터 저장 요청 명령을 전달한다. 이때 사용되는 버퍼의 관리 방식은 데이터 읽기 동작과 동일하다.

3. 파일 시스템 드라이버는 Buffered 액세스를 위해 오픈된 파일에 직접 데이터 저장을 지시한다. 이때 데이터 저장을 실행하는 파일이 캐싱되지 않았다면 파일 시스템 드라이버가 캐시 관리자를 호출함으로써 파일을 캐싱할 것을 지시한다. VMM는 캐시된 파일에 대한 파일 매핑(섹션 오브젝트)을 생성한다.

4. 파일 시스템 드라이버는 캐시 관리자가 제공하는 CcCopyWrite() 함수를 사용하여 데이터 저장 요청을 캐시 관리자에 전달한다.

5. 캐시 관리자는 데이터 구조를 검사하고, 사용자가 수정한 데이터 영역을 포함하는 파일에 대한 매핑된 뷰가 어디에 있는지 결정한다. 만약 매핑된 뷰가 없으면 캐시 관리자가 파일에 대해 매핑된 뷰를 새로 생성한다.

6. 캐시 관리자가 메모리 복사를 구현한다. 이때 메모리 복사는 사용자 버퍼에서 파일의 매핑된 뷰와 연관된 가상 주소 공간으로 이루어진다.

7. 가상 주소 영역이 물리 페이지와 연결되어 있지 않다면 페이지 오류가 발생하는데 이를 해결하기 위해 VMM로 제어가 이동한다.

8. VMM는 요청된 데이터를 저장하기 위하여 사용될 물리 페이지를 할당한다. 사용자가 전체 페이지를 덮어 씌울 경우에는 캐시 관리자나 가상 메모리 관리자가 데이터를 수정하기 전에 디스크와 분리되어 이미 물리 페이지에 있는 데이터는 읽지 않는다. 그러나 일부 페이지가 수정되었다면 페이지의 수정이 허락되기 전에 VMM는 페이지 오류를 처리하기 위해 데이터 읽기 위한 페이징 I/O(Paging I/O Read) 요청을 발생시킨다. 페이지 오류를 처리한 후 페이지 오류를 발생시켰던 명령이 다시 실행된다.

9. 캐시 관리자가 사용자 버퍼에서 파일의 매핑된 뷰와 연관된 가상 주소 영역으로 데이터의 복사를 완료한다.

10. 캐시 관리자가 제어를 파일 시스템 드라이버로 전달한다. 이때 사용자 데이터는 시스템 메모리에 있으며, 아직 보조 저장 장치에 전달하지 않은 상태이다. 실질적인 보조 저장 장치로의 저장은 캐시 관리자가 나중에 처리한다.

11. 캐시 관리자가 데이터 저장 요청을 종료한다.

12. 파일 시스템 드라이버는 I/O 관리자가 처음에 전달한 IRP를 종료하고, IRP의 종료 메시지를 I/O 관리자에 전달한다.

13. I/O 관리자가 사용자 데이터 저장 요청을 완료한다.

Code Virtualized

Ezbeat — Mon, 27 Jun 2011 20:53:36 +0900

U3에서 발표 후 기술문서로 만든다는 것을 이제서야 만드네요.

안티리버싱 기법 중 코드 가상화 기법에 대한 기술문서 입니다.
아래는 목차입니다.

Code Virtualized.pdf

PKCS 용도

Ezbeat — Tue, 07 Jun 2011 20:14:25 +0900

먼저 공개키 암호의 용도를 알아보기 전에 표기 방법에 대해서 설명하겠다.

A의 공개키로 메시지 M을 암호화 : C = {M}A
A의 개인키로 암호문 C를 복호화 : M = [C]A
서명은 복호화와 같은 연산이다. 그래서 A의 메시지 M 서명(서명된 메시지) : S = [M]A

암호화와 복호화는 역 역산이므로 아래와 같이 표현이 된다.

[{M}A]A = {[M]A}A = M

공개키 암호 용도
대칭키 암호가 할 수 있는 일은 모두 공개키 암호로 수행할 수 있다. 단점이라면 처리속도가 느리다는 것이다.
하지만 공개키 암호는 대칭키 암호화 비교해 두 가지 중요한 장점을 제공한다.

1. 공개키 암호는 미리 공유 키를 설정할 필요가 없다는 점
2. 전자서명은 무결성뿐만 아니라 부인봉쇄(Non-Repudiation)를 제공하는 것

쫌 있다가 위 두가지 장점에 대해서 알아보도록 하자.

현실 세계에서의 보안성
실제로 우리가 사용하고 있는 암호체계는 어떻게하는게 좋을까??

대칭키 암호의 장점과 공개키 암호의 장점을 섞은 합성 암호체계를 구성하는 것이다.
즉, 공개키 암호처럼 키를 공유하지 않으면서 대칭키 암호의 효율성을 취하는 것이다.

공개키 암호는 대칭키를 설정하기 위해 사용하고
대칭키는 데이터를 암호화하는데 사용하는 것이다.

위 그림에서 간단하게 설명하고 있다.
먼저 대칭키에 사용될 키 K를 B에게 전해주어야 되는데 이 때 B의 공개키를 가지고 K를 암호화 시켜서 B에게 보낸다.
그리고 B는 B의 개인키를 사용해 복호화하면 A,B 두 사람은 키를 안전하게 공유하는 것이다.
이제 공유된 키 값을 가지고 대칭키 암호체계를 사용해 메시지를 주고 받으면 되는 것이다.

물론 위 그림은 취약한 부분이 있다. 실제로 A가 B에게 보내는 키 값은 B의 공개키로 암호화되는 것이기 때문에 누구나 연산이 가능하고, B는 그 값을 보낸 사람을 확인할 수가 없다. 이 때 안전하게 공유할 수 있는 방법은 다음에 설명하겠다.

서명과 부인봉쇄
공개키 암호는 대칭키 암호와 마찬가지로 무결성을 사용할 수 있다. 대칭키에서는 MAC이 무결성을 제공한다.
하지만 공개키 서명은 무결성을 제공하면서 대칭키 암호가 제공할 수 없었던 부인봉쇄도 더불어 제공한다.

먼저 대칭키가 제공하는 무결성을 살펴볼 예를 들어보자.

1. A가 주식 100장을 사기 위해 자신이 선호하는 증권 중개인 B에게 주문서를 제출
2. 자신의 주문에 대한 무결성을 확신하기 위해 A는 공유 대칭키 K를 사용해 MAC을 계산
3. A가 주문한 이후 B에게 대금을 지급하기 전에 그 주식이 80%나 가치가 떨어짐
4. A는 주문서를 제출하지 않았다고 주장 ( 거래를 부인 )
5. B도 키 K를 가지고 있기 때문에 A가 제출한 주문서 위조 가능 ( A가 주문서 제출한 사실을 증명할 수 없다 )

위 예제는 대칭키 암호 체계를 사용한 경우이다.
하지만 MAC 계산 대신 전자서명을 사용하면 이러한 문제는 자연히 사라진다.
A만이 자신의 개인키를 알고 있기 때문에 B는 그 받은 문서를 위조할 수 없다. 그러므로 전자서명은 무결성과 부인봉쇄 기능 모두를 제공할 수 있다.

비밀성과 부인봉쇄
A가 메시지 M을 B에게 보낸다고 하자.
이 때 A는 비밀성과 부인봉쇄 두가지를 모두 하기 위해서
먼저 메시지 M을 B의 공개키로 암호화(비밀성)하고 자신의 개인키로 서명(부인봉쇄)을 했다고 하자.

그러면 두 가지 전부 해결할 수 있는 방법으로 보인다.
이 때 A는
{[M]A}B ==> 메시지 M을 A의 개인키로 서명 후 B의 공개키로 암호화 ( 선서명 후암호화 )
[{M}B]A ==> 메시지 M을 B의 공개키로 암호화 후 A의 개인키로 서명 ( 선암호화 후서명 )

두가지 방법을 생각해 볼 수 있는데 어떠한 방법이 더 좋을까?? ( 순서가 바뀌면 영향이 있을까? )

예를 들어보자.
A가 B랑 사귀고 있다. 이 때 A는 B에게 메시지를 보낸다.
"나는 당신을 사랑해요~"
보내기 전 A는 {[M]A}B 선서명 후암호화 한 후 B에게 보낸다.
하지만 B는 장난끼가 발동해 B의 개인키를 사용해 해당 메시지에서 [M]A를 얻어낸다. ( 복호화 )
그리고 해당 메시지를 {[M]A}c(C의 공개키로 암호화)로 바꾼 후 C에게 보낸다.
그러면 C는 A를 보낸 메시지를 받고 A가 자기를 좋아하는지 알고 서로 당황하게 만들 수가 있다.

그 사실을 안 A는 이제 암호화를 먼저 한 후 서명을 하기로 한다. ( [{M}B]A )
하지만 이 방법 또한 안전하지 않다.
짧게 설명하면 A의 공개키또한 전부 공개되어 있으므로 A가 서명한 내용을 제거할 수 있고
자신의 개인키로 서명을 해버리면 해당 메시지는 자기것이 되어버리기 때문이다.

즉, 공개키 암호에서는 누구나 메시지를 암호화할 수 있고 누구나 서명을 검증 할 수 있다.

ECC 디피-헬먼

Ezbeat — Fri, 03 Jun 2011 15:46:18 +0900

ECC 디피-헬먼은 DH의 ECC 버전이다.

공개된 정보는 곡선과 곡선 상의 한 점으로 구성된다.

y^2 = x^3 + 11x + b (mod 167)

다음 점 (x,y)를 선정하고 b를 이 점이 곡선 상에 위치하도록 결정

(x,y) = 2,7 -> b = 19

최종적으로 공개된 정보
y^2 = x^3 + 11x + 19 (mod 167), 점 (2,7)

A와 B는 각각 자신들의 비밀 승수를 선정한다.
A의 비밀 승수 a = 15
B의 비밀 승수 b = 22

그러면 A는 다음과 같이 계산할 수 있다.
a(2,7) = 15(2,7) = (102,88)

15(2,7)은 (2,7) + (2,7) + ... + (2,7) 총 15회는 더하는 것과 같다.
타원곡선 암호에서 두 점을 더하는 방법은 전 글에서 해보았다.
http://ezbeat.tistory.com/335

하지만 (102,88)을 보면 타원곡선 내 없는 점 같이 보인다.
y^2 = 1062349 mod 167 = 62 mod 167
하지만 62에서 167을 계속 더해가면 88의 제곱인 7744 값이 나오게 된다.
즉, 62 mod 167 = 7744 mod 167 ( 7744 = 88^2 )

위에서 본 15회의 덧셈을 손으로 한다는 것은 시간상 문제도 있으므로 프로그램을 짜서 돌리는게 훨씬 현명하다.
ECC에서 두 점 합을 구하는 프로그램을 만들어 보았다. 단순히 두 점의 합을 구하는 것이기 때문에
15회의 덧셈을 위해선 입력을 몇 번 더 해주어야한다. 코드이다.

코드보기

#include <stdio.h> #include <stdlib.h> #include <string.h> #include <math.h> #include <Windows.h> enum { GREY = 0x7, WHITE = 0xF, GREEN = 0xA, CYAN = 0xB, RED = 0xc, YELLOW = 0xE }; typedef struct point{ int x; int y; }point; int mod(int num,int p, int flag); int GetM(point p1, point p2,int a,int p); void Set_Color_Console(WORD color); int main(void) { int a,b; point p1,p2,p3; int m; int p; int y_2; int y_2_mod; int count = 0; printf("타원곡선 생성 (E : y^2 = x^3 + ax + b) \n"); printf("a : "); scanf("%d",&a); printf("b : "); scanf("%d",&b); printf("\n"); printf("mod p : "); scanf("%d",&p); printf("\n"); while(1) { memset(&p1,0,sizeof(point)); memset(&p2,0,sizeof(point)); memset(&p3,0,sizeof(point)); Set_Color_Console(WHITE); printf("★더할 두 점을 입력하세요 \n"); Set_Color_Console(GREY); printf("p1 : "); scanf("%d %d",&(p1.x),&(p1.y)); printf("p2 : "); scanf("%d %d",&(p2.x),&(p2.y)); if(p2.x - p1.x < 0) { Set_Color_Console(RED); printf("두 점을 바꿔서 다시 입력해주세요. ( x2-x1 < 0 ) \n"); Set_Color_Console(GREY); fflush(stdin); continue; } printf("\n"); Set_Color_Console(GREEN); printf("타원곡선 : E : y^2 = x^3 + %dx + %d (mod %d) \n",a,b,p); Set_Color_Console(GREY); printf("p1 : (%d,%d) \np2 : (%d,%d) \n",p1.x,p1.y,p2.x,p2.y); m = GetM(p1,p2,a,p); printf("m : %d \n\n",m); p3.x = m * m - p1.x - p2.x; p3.x = mod(p3.x,p,0); p3.y = m * (p1.x - p3.x) - p1.y; p3.y = mod(p3.y,p,0); printf("P1 + P2 = P3 : "); Set_Color_Console(CYAN); printf("(%d,%d) \n\n",p3.x,p3.y); Set_Color_Console(GREY); y_2 = (p3.x * p3.x * p3.x) + (a * p3.x) + b; printf("y^2 = %d \n",y_2); y_2_mod = mod(y_2,p,0); printf("y^2 mod %d = %d mod %d \n\n",p,y_2_mod,p); } //타원곡선 위의 점 중에 정수가 되는 p3.y값 찾음 ( 보류 ) /* while(1) { temp = sqrt((double)y_2_mod); if((temp - (int)temp) != 0) { y_2_mod += p; } else { p3.y = (int)temp; break; } } printf("타원곡선 위의 정수인 점 \n"); printf("P3 : (%d,%d) \n",p3.x,p3.y); */ return 0; } //(음수)^-1 처리는 안되어 있음 int mod(int num,int p, int flag) { //+,- mod 연산 if(flag == 0) { int count = 0; //- mod if(num < 0) { num *= -1; while(1) { if(((num + count++) % p) == 0) { num = --count; count = 1; break; } } } //+ mod else num %= p; return num; } //revers_mod 연산 ^-1 되어 있는 것 else if(flag == 1) { int count = 1; //^-1 mod do { if((num*count % p) == 1) { num = count; break; } } while (count++); return num; } return -1; } int GetM(point p1, point p2,int a,int p) { int count = 0; if(p1.x == p2.x && p1.y == p2.y) { //입력 시 tmp2는 음수가 안되도록 int tmp1 = 3 * (p1.x * p1.x) + a; int tmp2 = 2 * p1.y; tmp1 = mod(tmp1,p,0); tmp2 = mod(tmp2,p,1); return ((tmp1 * tmp2) % p); } else { //입력 시 tmp2는 음수가 안되도록. 즉, 두번째 x값이 첫번째 x값 보다 크게끔 입력 int tmp1 = p2.y - p1.y; int tmp2 = p2.x - p1.x; tmp1 = mod(tmp1,p,0); tmp2 = mod(tmp2,p,1); return ((tmp1 * tmp2) % p); } return -1; } void Set_Color_Console(WORD color) { HANDLE hConsole = GetStdHandle(STD_OUTPUT_HANDLE); SetConsoleTextAttribute(hConsole,color); }

A는 이 결과를 B에게 보낸다.
B도 다음과 같이 계산하고 그 결과를 A에게 보낸다.
b(2,7) = 22(2,7) = (9,43)

A는 다음과 같이 자신의 비밀 승수 a를 B에게서 받은 값에 곱한다.
a(9,43) = 15(9,43) = (131,140)

B도 유사한 방식으로 다음과 같이 계산한다.
b(102,88) = 22(102,88) = (131,140)

이렇게 하여 A와 B는 대칭키로 사용하기에 적절한 비밀정보를 공유하게 된다.
이것이 가능한 것은 AB(2,7) = BA(2,7) 이기 때문이다. ( 간략한 그림 )

이러한 DH ECC도 중간자 공격에 취약하기는 마찬가지이다.

타원곡선 암호

Ezbeat — Fri, 03 Jun 2011 14:00:30 +0900

"타원곡선"은 특정한 암호체계가 아니다.
타원곡선들은 공개키 암호체계에서 요구되는 복잡한 수학 연산을 수행하는 또 다른 방법을 단순히 제공하는 것이다.

타원곡선 암호(ECC)
장점 : 타원곡신인 경우가 아닌 경우와 비교해 같은 수준의 보안성을 위해 필요한 비트 수가 적다는 것
단점 : 타원곡선이 복잡해 타원곡선의 수학에는 비용이 다소 더 든다는 점

그러나 전체적으로 볼 때 타원 곡선은 계산적 장점을 제공.
그래서 ECC는 휴대용 장비 같은 자원이 제한되는 환경에서 특별히 선호된다.

타원곡선 E는 아래 함수 그래프의 형태이다.
E : y^2 = x^3 + ax + b

∞로 표현되는 무한대의 특수한 점도 함께 포함한다.

위 그림은 타원곡선 상에서 두 점의 함을 찾는데 사용되는 방법도 설명하고 있다.
두 점 P1, P2 더하기 위해 두 점을 지나는 선을 그린다. 일반적으로 그 선은 곡선상에서 서로 다른 점과 만난다.

만약 그렇게 만나면 이 다른 점은 x축에 반사되어 그 합을 P3으로 얻는다.

P3 = P1 + P2

타원곡선에서 필요한 유일한 수학은 바로 덧셈이다.
암호를 위해 점들의 이산 집합이 요구된다.

이것은 다음과 같이 원래의 타원곡선 공식에 "mod p"를 더하면 수행될 수 있다.

y^2 = x^3 + ax + b (mod p)

예를 들어 아래의 타원곡선을 생각해 보자.

y^2 = x^3 + 2x + 3 (mod 5) --- ①

이 곡선 상의 모든 점 (x,y)에 대해 가능한 x값과 이와 일치하는 y값을 계산해 나열해 보자.

x = 0 ==> y^2 = 3 ==> 해가 없음 mod 5
x = 1 ==> y^2 = 6 = 1 ==> y = 1,4 mod 5
x = 2 ==> y^2 = 15 = 0 ==> y = 0 mod 5
x = 3 ==> y^2 = 36 = 1 ==> y = 1,4 mod 5
x = 4 ==> y^2 = 75 = 0 ==> y = 0 mod 5

① 식의 타원곡선 상의 점들은 다음과 같다.
(1,1), (1,4), (2,0), (3,1), (3,4), (4,0), ∞

이제 두 점을 합하는 알고리즘을 살펴보자

주어진 조건 : 곡선 E: y^2 = x^3 + ax + b (mod p)
E 상에서 P1 = (x1,y1), P2 = (x2,y2)
구하고자 하는 해: P3 = (x3,y3) = P1 + P2

알고리즘
x3 = m^2 - x1 - x2 (mod p)
y3 = m(x1 - x3) - y1 (mod p)

m 값
만약 P1과 P2가 같지 않다면 (if P1 ≠ P2)
(y2 - y1) * (x2 - x1)^-1 mod p
만약 P1과 P2가 같다면 (if P1 = P2)
(3x1^2+a) * (2y1)^-1 mod p

특수한 경우 1 : if m = ∞ 이면 P3 = ∞
특수한 경우 2 : 모든 점 P는 ∞ + P = P

예제 문제 ( 위 에서 사용한 E 곡선 그대로 사용 mod 5 )

P3 = (1,4) + (3,1)

m = (1 - 4) * (3 - 1)^-1 mod 5 = -3 * 2^-1 mod 5 = -3 mod 5 * 2^-1 mod 5 = (2 * 3) mod 5 = 6 mod 5 = 1 mod 5
m = 1

x3 = 1^2 - 1 - 3 = -3 mod 5 = 2 mod 5
y3 = 1 * (1 - 2) - 4 = -5 mod 5 = 0 mod 5

P3 = (2,0)
P3 점도 y^2 = x^3 + 2x + 3 (mod 5)이 곡선 위의 한 점이라는 것을 확인할 수 있다.
0 = 8 + 4 + 3 = 15 mod 5 = 0 mod 5

이제 타원곡선 상에서 덧셈을 할 수 있으므로 다음 글에선 ECC 디피-헬먼(디피-헬먼 타원곡선 암호 버전)에 대해 알아보겠다.

디피-헬먼 키교환 알고리즘

Ezbeat — Fri, 03 Jun 2011 11:16:37 +0900

디피-헬먼(DH) 키교환 알고리즘은 GCHQ의 윌리엄슨에 의해 발명되었다. 그러다가 곧 독립적으로, 이름에서 짐작할 수 있듯이 화이트필즈 디피와 마틴 헬먼에 의해 재발명되었다.

DH는 암호화나 서명을 위해 사용되는것이 아니라 사용자가 비밀 공유를 설정하는 데 사용된다.
대칭키 암호의 근본적인 문제 중 하나가 키 설정의 문제이기 때문에 그 의미는 크다.

대칭키 암호에서 송수신자간 대칭된 키를 공유해야 되는데 이 때 키교환 시 사용한다는 말이다.

DH의 보안성은 이산 로그 문제의 계산 난이도에 의존한다.
이산 로그 문제는 비록 NP-complete 문제로 알려져 있지는 않지만 인수분해 문제처럼 풀기가 매우 어렵다.

DH 의 수학적 표현은 상대적으로 단순하다.
p를 소수라하고 q는 생성자라 하자.
여기서 어떤 x ∈ {1,2, ... ,p-1}에 대해 x = g^n mod p 를 만족하는 지수 n을 찾을 수 있다.

p의 값과 생성자 q는 공개되어 있다.
이제 키 교환을 위해 A는 자신의 비밀 지수 a를 생성하고, B는 그의 비밀 지수 b를 생성한다.
A는 (g^a mod p)를 B에게 보내고 B는 (g^b mod p)를 A에게 보낸다. 이어서 A는 다음을 계산한다.

(g^b)^a mod p = g^ab mod p

B도 유사한 방법으로 다음을 계산한다.

(g^a)^b mod p = g^ab mod p

그러면 (g^ab mod p) 가 공유한 비밀이 되어 통상적인 대칭키로 사용될 수 있다.

이 때 공격자 C는 중간에 (g^b)^a mod p, (g^a)^b mod p 를 볼 수 있기 때문에 (g^ab mod p) 를 거의 알 수 있는 것처럼 보이지만 C는
g^a * g^b = g^(a+b) ≠ g^ab mod p
위가 성립하기 때문에 쉽게 알 수가 없다.

C는 어려운 이산 로드 문제를 풀기 위해 필요한 a나 b를 찾아야한다.

이러한 DH 알고리즘은 중간자 공격에 민감하다.
이것은 C가 직접 A와 B 중간에 서서 오가는 메시지를 가로채는 능동적인 공격이다.

C가 앞서 말한 위치에 있으면 A와 B 간의 DH교환은 부서질 수 있다.

이렇게 되면 A나 B둘 중 누구도 잘못된 것을 알지 못하고 있는 사이에 C는 A와 B간에 오가는 모든 메시지를 읽고 변경할 수 있게 된다.

이러한 중간자 공격을 어떻게 막을 수 있을까??

1. 공유하는 대칭키로 DH교환을 암호화
2. 공개키로 DH교환을 암호화
3. 개인키로 DH값을 서명