www.reversecore.com

책 원고 작성 완료!

reversecore — Mon, 05 Dec 2011 01:44:12 +0900

안녕하세요. ReverseCore 입니다.

책 원고 작성을 완료하였습니다.

모든 컨텐츠 작성을 마치고 자체 퇴고(8회)를 완료하였습니다.

이제 출판사에 넘겨줄 수 있겠네요. ^^~

<퇴고 작업을 도와준 아이패드>

분량

8섹션, 61챕터, A4 기준 1000 페이지 입니다.
885 개의 이미지와 65 개의 소스파일이 담겨있습니다.
책 이름도 결정 하였습니다. (나중에 공개할 께요~ ^^)

내용

기존 블로그의 내용 60% + 새로운 컨텐츠 40% 로 구성하였습니다.

블로그에 있는 내용들은 Windows XP + Visual C++ 6.0/2008 환경에서 작업했었습니다. 이를 최신 Windows 7 32bit + Visual C++ 2010 환경으로 재작업을 하였구요. 컨텐츠들의 순서 조정에 많은 고민을 하였습니다.

새로 추가된 내용들은 아래와 같습니다.

64 bit Computing / Debugging
고급 리버싱 (TLS, TEB, PEB, SEH, IA-32 Instruction 해석)
Anti-Debugging (Static, Dynamic, Advanced)
디버깅 실습 (Service, Self-Creation, PEImageSwitching, DebugBlocker)

일정

2010년 5월 1일 책을 쓰기로 마음 먹고 2011년 12월 3일 원고를 마감하였네요. 원고 작업만 19 개월 소요되었군요. (블로그 시작한날인 2009년 2월부터 따져보면 벌써 약 33 개월이 지났네요.)

아직까지는 제 인생 최대의 프로젝트라고 말할 수 있겠습니다. ^^

2011년 6월말쯤 8장 마지막 챕터를 끝내고 책에 뭐 빼먹은게 없나 살펴보니, 문득 제가 애초에 기획했던 모든 컨텐츠 작성을 끝냈다는 사실을 깨달았습니다.

약간 멍~ 했죠. 조금 재충전을 하고 퇴고 작업에 들어갔습니다. 노트북으로 들고 다니며 보는데 한계가 있어서 문서를 출력해서 보다가 분량이 너무 많아서 힘들었습니다. 그래서 아이패드에 문서를 전부 입력하고 PDF Viewer 앱과 터치펜으로 퇴고 작업을 했습니다. (퍼포먼스가 확 향상되더군요.) 약 5 개월간의 기나긴 퇴고 작업 끝에 드디어 원고를 탈고 할 수 있었습니다.

마침 아내가 아기와 외출한 시간(12월 3일 토요일 오후 6시)에 제가 계획한 8 단계 퇴고작업의 마지막 작업을 끝마칠 수 있었네요.

소감

일단 기분이 몹시 좋습니다. 몸과 마음이 날아갈듯 하네요. ^^
마치 오랜 여행을 마치고 집에 돌아온 느낌이 드네요. 기쁜 마음에 이렇게 블로그에 글을 올려 봅니다.

# 작업 속도

책을 쓸 때는 생각보다 작업 속도가 너무 느려서 도대체 언제쯤 책이 완성될 수 있을까 싶었습니다. 하루에 그림 하나 또는 캡쳐 두개 정도 밖에 못 할 때도 많았거든요. 하지만 그런 날들이 하루 이틀 쌓이니까 어느 순간부터는 "내가 언제 이렇게 많은 일을 했지?" 라는 생각이 들면서 목표 지점이 희미하게나마 보이기 시작했습니다.

# 재작업

책을 쓰면서 가장 힘들었던 순간은 이미 한번 쓴 글을 두번 세번 다시 쓸 때 였습니다. 독자분들께 최신의 리버싱 경험을 드리기 위해 개발도구를 Visual C++ 2010 으로 바꾸고 작업환경을 Windows 7 으로 바꾸었습니다. 그러다보니 기존 문서를 그에 맞게 다시 캡쳐하고 변경된 주소를 찾아 고치는 작업들이 많았습니다. 지금와서 뒤돌아보니 그런 작업들이 가장 기억에 많이 남습니다.

# 슬럼프

10 여회의 크고 작은 슬럼프를 경험하였습니다. 수많은 재작업과 검증, 생각대로 나오지 않는 글쓰기, 예상보다 훨씬 오래 걸리는 시간, 개인적인 외부 요인 등으로 인해서 글을 쓰지도 못하고 글쓰기 자체가 싫어지는 상황이 몇 번 닥쳤었죠. 스트레스가 쌓인 겁니다.

제가 새벽에 일어나 글을 쓰는 책상이 있는데요, 어느 순간에는 그쪽을 쳐다보기도 싫어지더군요. 그리고 저녁에는 퇴근 후 글을 쓰러 찾아가는 도서관이 있습니다. 한때는 그쪽으로 발길이 도저히 떨어지지 않는 날도 많았습니다.

다행인것은 그때마다 제 자신이 슬럼프 상황인걸 인식하고 극복하려고 노력했다는 것입니다.

# 응원

가끔 블로그에 방문해서 댓글에 답변도 달아드리고 제 책을 응원하는 글을 보면서 힘을 얻곤 했습니다. 그리고 부모님, 아내, 친구들, 회사 동료들까지 많은 분들께서 관심을 가져주시고 격려를 해주셨습니다.

이 자리를 빌어서 모든 분들께 감사 드립니다.

그리고 제가 좋아하는 독서도 많이 하고 사람들과 많이 어울려 다니면서 다시 용기를 얻어서 작업을 이어나갈 수 있었습니다. 그러다 결국 여기까지 올 수 있었구요.

"포기하기 전까지 실패란 없다. 시행착오가 있을 뿐이다. 시행착오를 거듭하다보면 언젠가 결국 성공하게 된다."

위 명언을 계속 새기면서 포기하지 않고 꾸준히 작업했더니 결국 원고가 완성되었습니다.

# 앞으로...

출판사와의 일정이 잡히면 블로그에 다시 공지해 드리겠습니다.

원고 작업을 한번 성공하니 자신감이 충만해 지는게 느껴집니다. 이번에 많은 경험과 시행착오를 겪어보니 두 번째 책도 금방 쓸 수 있을 것 같은 기분입니다. (2 탄을 기획 중인데요. 구체적으로 정리되면 알려드릴께요~)

다시 한번 모든 분들께 감사 드립니다. ^^~

ReverseCore

InjDll64.exe 버전업! - 64bit 지원

reversecore — Fri, 29 Oct 2010 23:06:00 +0900

기존 InjDll.exe 유틸리티를 업그레이드(Ver. 1.1.1) 하였습니다.

1. 64bit 지원

2. <dll path> 의 상대 경로 지원

☞ InjDll.exe - DLL Injection/Ejection 전용 도구

Windows 7 64bit OS 가 보급됨에 따라 리버싱 분야에도 점차 64bit 지원 여부가 중요한 이슈가 되고 있습니다. 저 또한 최근에 64bit 관련 내용을 공부하면서 흥미로운 내용을 많이 접하였습니다. (이번에 작업 중인 리버싱 책에 64bit 리버싱 챕터를 추가시켰습니다.)

각 플랫폼(32/64bit) 별로 Dll Injection 을 하실 때 다음의 내용을 주의해 주시기 바랍니다.

- Target 프로세스가 32bit 인 경우 : Injector & Dll => 모두 32bit (PE32 포멧)

- Target 프로세스가 64bit 인 경우 : Injector & Dll => 모두 64bit (PE32+ 포멧)

* 64bit OS 에서는 32/64bit 프로세스가 모두 실행 가능하므로, Target 프로세스의 PE 포멧을 확인 하신 후 적절한 Injector(InjDll32/InjDll64) 와 DLL 을 사용하시면 됩니다.

* PE32+ 포멧의 파일을 생성하시려면 Visual C++ 2010 Express & Windows SDK 를 설치하시면 됩니다.

ReverseCore

도대체 리버싱을 어떻게 공부해야 하나요?

reversecore — Wed, 13 Oct 2010 00:57:57 +0900

"리버싱 공부를 어떻게 시작해야 할지 모르겠어요. 도와주세요." 라는 질문을 종종 받곤 합니다. 제가 블로그 활동을 하는 이유는 우리나라의 리버싱 기술 수준을 향상시키고, 리버싱 기술을 널리 전파하는데 작은 힘을 보태는 것입니다. 특히 리버싱에 처음 입문하시는 분들께 길잡이 역할을 할 수 있다면 더이상 바랄게 없습니다.

과연 어떻게 하면 리버싱을 잘 할 수 있을지 제 생각을 얘기해 드리겠습니다.

1. 모든 공부에는 "목표"가 있어야 합니다.

"리버싱 전문가가 되기 위해", "취직을 위해", "흥미를 위해", "해커가 되기 위해" 등의 자신만의 목표가 필요합니다. 이러한 목표가 없으면 힘든 공부를 지속하기 어렵습니다. (도중 포기할 확률이 높아진다는 뜻입니다.) 목표는 여러분들에게 방향을 제시합니다. 그 목표를 향해 한발 한발 전진하시기 바랍니다.

2. "긍정적인 마인드"를 가지세요.

잘못된 편견을 가지신 분들이 많이 계십니다.

- "저는 C 언어도 모르는데요... 리버싱을 할 수 있을까요?" --->>> 물론이죠.

- "저는 어셈블리를 해본적이 없는데요... 리버싱을 못 하겠지요?" --->>> 천만에요. 잘 하실 수 있습니다.

- "저는 윈도우즈 구조를 전혀 모르는데요... 그래도 리버싱을 할 수 있을까요?" --->>> 무지 잘하게 되실 겁니다.

바로 위와 같이 "저는 XXX 를 모르는데요" 라던지 "저는 YYY 를 해본적이 없는데요" 라는 말은 리버싱을 공부할 때 전혀 의미없는 말입니다. 이런 말은 지레 겁을 먹게 만들고, 도전 의식을 꺾어버립니다. 시도조차 못해보고 포기하게 만드는 부정적인 말입니다. 오히려 "XXX 를 모르기 때문에 배우고 싶다" 라고 긍정적인 생각을 해보시기 바랍니다.

배워야 할 가짓수를 따지자면 수십 가지가 넘을 것입니다. 리버싱 초보자가 그걸 처음부터 다 배워야 할까요? 너무 힘들겠지요. 지겨워질 겁니다.

그냥 새로운 내용이 튀어 나올때마다 다 해결하고 넘어가려고 하지 마시고 일단 맘에 묻어두시고 계속 진행하시는 것이 중요합니다. 반복 학습 하는 과정에서 한가지씩 차츰 차츰 배워나가시면 됩니다.

예를 들어 "XOR EAX, EAX" 의 의미는 디버깅을 몇 번 해보시면 저절로 체감하게 되는 내용입니다. 처음 볼때나 낯설고 흥미롭지요. 하지만 100번 봤다고 생각해 보세요. 그냥 당연하게 받아들이게 됩니다. 오히려 같은 의미의 "MOV EAX, 0" 명령어가 이상하게 보일겁니다. XOR EAX, EAX 를 왜 안썼을까 하고 말이죠.

3. "재미"를 느끼셔야 합니다.

초보일수록 더더욱 리버싱 과정에서의 재미를 찾으셔야 합니다. 어렵고 지겨운데 어떻게 계속 해나갈 수 있겠습니까? 리버싱이 재밌고, 하나씩 모르는 걸 배워나가고, 내가 맘먹은대로 프로그램을 패치시키는 이런 과정에서 재미를 찾으셔야 하지요.

사람은 재미있는 일이라면 남들이 아무리 말려도 스스로 하게 되어있답니다.

4. "검색"을 생활화 하셔야 합니다.

"검색하면 9할은 나온다" <- 제가 어디서 읽은 후 맘속에 담아둔 명언 입니다. 특히 리버싱 기술은 수많은 검색을 통한 지식 습득이 필수적입니다. 역사가 짧고 관련 전문가도 적고 관련 서적도 거의 없다시피 하니까요. 일단 믿고 검색해 보시기 바랍니다. 반드시 원하시는 내용을 찾을 수 있으실 겁니다.

5. 제일 중요한건 "실천"입니다.

"Just Do It" 아시죠~

뭔가를 이루고는 싶은데... 맘을 먹으셨으면... 행동을 하셔야죠... 그것도 지금 당장 하는겁니다...

제 블로그에 있는 HelloWorld 부터 무작정 따라해보는 겁니다. 당연히 처음에는 하나도 아는게 없지요. 모든게 낯설게 느껴집니다. (특히 어셈블리 명령어는 거의 외계 언어로 보이죠.)

첫 목표는 디버거를 이용해서 main() 함수를 찾아가는 겁니다. 디버거에 일단 익숙해 지기 위해서 메뉴도 하나씩 건드려 보고요. tracing(StepIn[F7], StepOut[F8] 명령어를 이용) 을 마구 해보는 겁니다. 차츰 감이 오다가 결국 main() 을 찾게 됩니다. C 소스 코드와 Disasembly 코드의 차이도 확인해 보시구요. 시작은 성공하신 겁니다! 출발이 좋군요. ^^

그다음 간단한 crackme, patchme, unpackme 등을 찾아서 해보시구요.

흔히 볼 수 있는 메모장, 계산기등을 패치해봅니다. (아주 간단히 말이죠. 가령 기능을 막아본다던지 하는 그런 정도로요.) 그 후 차츰차츰 대상을 넓혀 가시는 겁니다.

6. "느긋한 마음"을 가지세요.

리버싱 초보자가 가장 걸리기 쉬운 병이 바로 "조급증" 입니다. 빨리 성과를 내고는 싶은데 공부가 만만치는 않고 실력은 제자리에서 맴돌고 있습니다. 자신이 얼마나 모르는 것인지, 제대로 가긴 하는 건지 너무 답답합니다. 어셈블리, 윈도우즈 내부구조, PE 파일 포멧, API 후킹 등 뭐 하나 쉬운게 없습니다. 어셈블리 한가지만 봐도 어디까지 공부를 해야 하는지 알 수 가 없지요. 이럴때 마음이 급해지고 목표를 잃어 버리게 됩니다.

제가 해드리는 얘기를 잘 읽어 보시기 바랍니다.

世界最强 大韓民國

위 한자들을 읽어 보세요. "세계최강 대한민국" 입니다. 대부분 정확히 읽으셨을 겁니다. 그렇다면 안보고 정확히 쓸 수도 있으신가요? 아마 안보고 쓰는건 쉽지 않으실 겁니다. ^^ 위 8 글자 중에서 한 두 글자를 모르더라도 주변 글자들을 통해서 전체를 읽어 낼 수 있습니다.

저를 비롯한 많은 리버서들이 어셈블리 명령어를 100% 자유자재로 구사하지는 못합니다. 몇명은 그래도 어셈블리 프로그래밍이 가능하지만 많은 사람들은 그렇지 못합니다. 마치 위의 한자를 읽을 수만 있고 쓸 수는 없는 것과 비슷한 상황입니다. 그래도 리버싱만 잘해요~ ^^ 명령어를 모르면 찾아 보면 되니까요. 그 정도만 알아도 프로그램의 동작 흐름을 알아낼 수 있습니다. 아마 이런식으로 몇 년이 더 흐르면 지금보다 훨씬 잘하게 되겠지요.

중요한 것은 저와 제가 아는 모든 리버서들도 초보 시절에는 (여러분들과 같이) 다 고만고만한 조건이었다는 것입니다. 꾸준히 하다보니 자연스럽게 어느 정도의 실력이 쌓인 것이지요. 절대로 조급해 하지 않았습니다.

여러분들도 지금 당장 시작해보세요~ 분명히 성과가 나타날 것입니다.

제가 어떻게 장담하냐구요? 저는 사실 구체적인 성공 사례를 알기 때문입니다. 블로그를 운영하면서 많은 분들께 과분한 감사의 메일을 받았습니다. 그 사연들을 읽어보면 감동에 이어 전율이 흐를 때도 있습니다.

- 대학 졸업작품이 단과대 전체 최우수 작품으로 선정되었습니다. (상까지 받으셨다는...)

- 개발 프로젝트에 후킹 기술을 적용해서 쉽게 해결할 수 있었습니다. (유명 회사 개발팀 소속이십니다.)

- XX소프트웨어 멤버십에 합격했습니다. (XX 취직이 보장된다는 그런 곳이라죠.)

- 리버싱 프로젝트("문서 암호화")를 성공시켰습니다. (아마 대학교 동아리 였던걸로 기억합니다.)

- 기타...

이분들께서는 대부분 리버싱 초보셨습니다. 본인들의 불타는 열정으로 엄청난 성취를 이루어 내신 거지요. 따라서 제가 여러분도 할 수 있다고 장담할 수 있는 것이고요.

공부하시다가 모르시는 내용이 있으세요? 질문하세요~ 저도 다른 분들의 생각을 들어보고 같이 고민하는 것을 좋아합니다.

자, 지금 당장 시작하세요~ ^^

ReverseCore

리버싱 현업에서 사용되는 디버거(Debugger)들

reversecore — Wed, 29 Sep 2010 00:05:00 +0900

리버서들이 가장 많이 사용하는 도구인 디버거(Debugger)에 대해 이야기 해보도록 하겠습니다.

리버싱 현업에서 사용되는 Debugger 들을 간략히 정리해 보겠습니다.

1. OllyDbg

☞ http://www.ollydbg.de/

OllyDbg 는 사용이 편리하고 가볍고 빠른 무료 Debugger 입니다. 도저히 무료라고 보기 힘든 다양한 기능과 많은 Plugin 을 통한 확장성으로 인하여 수 많은 리버서들의 열광적인 지지를 얻고 있습니다.

OllyDbg 는 리버싱 초보부터 전문가까지 폭넓게 사용되는 가장 인기 있는 디버거입니다.

<그림 1 - OllyDbg>

OllyDbg 의 장점으로는 가볍고 빠르며 상당히 다양한 기능과 많은 옵션을 제공한다는 것입니다. 또한 PlugIn 기능을 통한 확장성을 제공합니다. 가장 사용자가 많고 OllyDbg 를 이용한 리버싱 강좌가 많이 있기 때문에 초보자도 쉽게 배울 수 있습니다. 그리고 무료로 제공된다는 점도 큰 장점입니다.

단점으로는 개인이 혼자서 개발한 거라 업데이트와 후속 제품의 개발 주기가 늦다는 것입니다. 다행히 최근에 OllyDbg 2.0 Final 버전이 릴리즈 되었습니다. 비록 겉모습은 이전 버전과 동일하지만 내부 코드는 완전히 새롭게 프로그래밍 하여 속도와 정확성 등이 크게 향상되었다고 하네요.

2. IDA Pro

☞ http://www.hex-rays.com/idapro/

Hex-rays 사의 IDA Pro 는 현재 최고의 Disassembler & Debugger 라고 말할 수 있습니다. 과거에는 Disassembler 성격이 강했으나, 수많은 업데이트를 통해 Debugger 기능 또한 막강해 졌습니다.

수 많은 다양한 기능들을 설명하는 전문 서적이 따로 존재할 정도로 엄청난 기능을 자랑합니다. 또한 Decompiler Plugin 등을 추가로 장착하면 리버싱이 말할 수 없이 편리해 집니다. 그만큼 가격도 비싸지요.

많은 리버싱 전문가들이 IDA Pro 를 주력으로 삼으면서 리버싱 전문 툴로써의 입지를 탄탄히 굳히고 있습니다.

장점으로는 다 써보지도 못할 정도로 다양한 기능과 충실한 업데이트를 들 수 있습니다. 다만 가격이 비싸고 사용법이 비교적 복잡하며 초기 로딩 시간이 좀 걸린다는 것을 단점으로 들 수 있겠습니다.

<그림 2 – IDA Pro>

3. WinDbg

http://www.microsoft.com/whdc/devtools/debugging/default.mspx

WinDbg 는 DOS 시절 16 bit 디버거인 debug.exe 의 Windows 버전입니다.

<그림 3 – Debug.exe>

콘솔 화면에서 키보드만으로 디버깅을 하는 debug.exe 의 사용자 인터페이스를 그대로 가져왔습니다. 저는 이런 스타일의 프로그램을 매우 좋아하지만 반대로 거부감을 갖는 분들도 상당수 계십니다.

유저 모드 디버깅(User Mode Debugging) 분야에서는 사용자 편리성이 뛰어난 OllyDbg 나 IDA Pro 가 꽉 잡고 있습니다. 따라서 WinDbg 는 주로 커널 모드 디버깅(Kernel Mode Debugging)에 주로 사용됩니다. 전설적인 커널 디버거인 SoftICE 의 후속 제품 개발이 중단된 이후 커널 디버깅 분야에서 사실상 독보적인 존재가 되어 버렸습니다. (경쟁 제품이 없는 상태입니다.)

역사가 오래 된 만큼 기능도 다양하고 사용 방법에 대한 전문 서적이 여러 권 나와 있습니다.

<그림 4 - WinDbg>

장점은 커널 디버깅이 가능하다는 것과 Microsoft 에서 직접 만든 디버거라는 점입니다. 시스템 파일에 대한 심볼(Symbol)을 직접 다운 받을 수 있어서 시스템 내부 구조체(Undocumented 포함) 및 API 에 대한 정보를 얻을 수 있습니다. 또한 Windows OS 의 덤프 파일을 읽어 들여 분석할 수 있기 때문에 시스템 크래쉬(Crash)가 발생했을 때 원인을 분석해 낼 수 있습니다.

단점으로는 다른 디버거들에 비해 좀 떨어지는 사용자 환경과 편의성을 꼽을 수 있겠습니다. (예를 들어 코드에 직접 주석을 입력할 수 없고, Disassembly 코드에서 호출되는 API 이름도 잘 표시되지 않는 등의 불편함이 있습니다.)

그래도 커널 드라이버 개발과 유지보수에 필수적으로 사용되는 디버거 입니다. 리버싱에서는 커널 드라이버 파일 분석에 주로 사용됩니다. 최근에는 대부분 WinDbg 와 VirtualPC(또는 VMWare) 조합으로 커널 디버깅을 수행합니다. 향후 여러분들의 리버싱 실력이 쌓인 후 커널 드라이버(예: Rootkit) 등을 분석할 때 자주 사용될 것입니다.

+---+

지금까지 리버싱 현업에서 사용되는 대표적인 디버거들에 대해서 간략히 살펴보았습니다.

제 경우에는 유저 모드 디버깅에 OllyDbg 1.10 를 사용하고, 커널 모드 디버깅에는 WinDbg 를 사용합니다.

ReverseCore

책소개

reversecore — Mon, 06 Sep 2010 01:00:00 +0900

책소개

제가 요즘 회사일, 집안일 외에 대부분의 시간에 리버싱 서적을 열심히 쓰고 있습니다. 책 홍보를 위해 간략히 소개해 드리자면 타겟 독자층은 "리버싱 입문을 원하는 초보자"와 "리버싱 레퍼런스가 필요한 중급자" 입니다. 컨셉은 "내부 동작 원리를 아주 쉽고 뜨겁게 이야기" 하는 것입니다. 분량은 (제발) 1,000 페이지가 넘지 않도록 노력 중입니다. 책 내용은 블로그 내용을 좀 다듬어서 60% 정도를 채우고, 새로운 주제를 써서 나머지 40% 정도를 채울 예정입니다. 그리고 실습 예제를 많이 넣으려고 합니다.

일정

집필 일정은 늦가을까지로 예정했었습니다. 그런데 쓰면 쓸수록 제 자신이 점점 진지해지면서 입문자에게 필요하다고 생각되는 범위와 분량이 대폭 늘어나고 있습니다. 일정과 분량을 조절할 필요가 있네요. 욕심을 자제하려고 노력도 해봤지만, 진정한 "리버싱 입문서"를 독자에게 제공해야 한다는 사명감(?) 같은 게 생겨서 이젠 굳이 자제하려고 노력하지 않습니다. ^^

조언

제 블로그를 방문하시는 분들 중에서 혹시 제가 책에서 다루면 좋겠다고 생각되는 주제(또는 조언, 건의, 아무거나)가 있으시다면 댓글로 알려주시기 바랍니다. 작업에 큰 도움이 될 것입니다.

블로그

블로그에 글을 많이 올리지 못해서 자주 방문하시는 분들께 죄송하다는 말씀을 드립니다. 집필이 끝나면 제 블로그에는 실전 리버싱 실습 위주로 포스팅을 할 예정입니다. 그리고 책에 미처 쓰지 못한 내용들을 올리게 될 것입니다.

제 블로그는 매일 방문하고 있습니다. 댓글의 질문들에 답변도 올리고, 이메일로 문의하신 내용도 꼭 챙겨읽고 답변 드리고 있습니다. 리버싱 하시다가 궁금한 점 있으시면 부담 갖지 마시고 질문해 주세요. 저는 같이 생각해 보는 것을 좋아합니다. 답변 달면서 제가 더 많이 배우니까요.

그리고 바쁘더라도 종종 글을 올려야겠어요. 예전에는 블로그 포스팅 하는게 저의 즐거움 이었는데 말이죠. 요즘엔 글을 쓰기만 하고 올리지는 않으니 즐거움이 하나 줄었어요.

방문해 주시는 모든 분들께 감사 드립니다.

댓글, 이메일 보내주시는 분들에게도 감사드려요. 여러분께서는 모두 가까운 미래에 '열혈 리버서' 가 되실 것입니다.

감사합니다.

* 제가 좋아하는 멘트를 하나 남길께요~ 제 트위터에도 쓴 내용입니다. (트위터를 혼잣말 하는 공간으로 활용하기 때문에 Follow, RT 이런거 없어요. ^^)

"똑같은 시기에 비슷한 생각을 하는 사람은 많지만 실천에 옮기는 사람은 드물다. 나는 생각을 행동에 옮겼을 뿐이다. 기회는 도전하고 실천하는 자가 받는 선물 같은 것이다." - 강덕수, STX 그룹 회장 (창업주)

리버서의 연륜을 말해주는 Opcode Manual

reversecore — Tue, 31 Aug 2010 01:00:00 +0900

지난주부터 "IA-32 Instruction" 챕터를 작업하는 중인데요, IA-32 Instruction 이란 쉽게 말해 아래 그림에서 빨간 박스로 표시된 부분을 말하는 것입니다.

디버거에 탑재된 Disassembler 가 저 Instruction 을 해석해서 우리가 익히 보는 (오른쪽의) Disassembly 코드를 만들어 내지요.

"IA-32 Instruction" 챕터를 작업하면서 제 노하우를 공개하였습니다. 그건 바로 Intel IA-32 Manual 에서 Instruction 을 해독하기 위해 필요한 Opcode Map(Opcode Table) 부분만 프린터로 출력한 것입니다. 저한테는 Opcode 매뉴얼인 셈이지요. (아래 그림 참고)

작업 중인 책 내용의 일부를 소개합니다. (참고 섹션 내용입니다.)

* 참고

위 출력물이 너덜너덜 해질 때쯤 여러분은 IA-32 Instruction 해석의 고수가 되어 있으실 겁니다. 저 또한 5년 동안 손 때묻은 저만의 출력물을 한 부 가지고 있습니다. 후배나 동료가 Instruction 해석에 관해서 물어오면 자랑스럽게 꺼내서 가르쳐 줍니다. 많이 참고하다 보면 어떤 내용이 대충 어느 페이지에 있다는 감이 생겨서 한번에 그곳을 펼칠 수 있습니다. (생활의 달인?)

제가 가장 존경하는 선배님도 이러한 출력물을 가지고 계셨습니다. 그 당시에도 매우 낡아 보였지요. 어찌 보면 이것이 리버서의 연륜(?)을 나타내는 하나의 척도로 볼 수 도 있겠습니다. 여러분께서도 꼭 자신만의 출력물을 한 부 만들어서 활용해 보시기 바랍니다.

이처럼 오랫동안 저랑 같이 작업한 제 손 때묻은 매뉴얼 이라서 어느덧 애정이 생겨 버렸습니다. (기술자들은 모두 그런 게 한두 개씩은 있잖아요? 자신과 오랫동안 함께 하면서 분신이 되어버린 도구 같은…)

최근 1~2년은 주로 각종 자동화 시스템의 개발/유지보수 업무를 하면서 Opcode 매뉴얼을 거의 꺼내 보지 못했었는데, 이번에 "IA-32 Instruction" 챕터를 쓰면서 다시 꺼내어 보니 감개가 무량하더군요. (그동안 소홀해서 미안해~ 이번 챕터는 다 니 덕이야~ 고마워~)

더불어 제게 처음 IA-32 Instruction 을 가르쳐 주시고(사실 개발, 분석을 다 가르쳐 주셨죠) 제가 가장 존경하는 선배님(형님)이 생각납니다. 지금은 외국에 계셔서 만나 뵙기는 힘듭니다만 오늘은 그분이 더 보고 싶네요. ^^~

어셈블리 언어를 이용한 Code Injection (5)

reversecore — Sun, 04 Jul 2010 19:18:55 +0900

이전 강좌에서 이어지는 내용입니다.

☞ 어셈블리 언어를 이용한 Code Injection (4)

# MessageBoxA() 파라미터 입력 1 – MB_OK

002D002C 6A 00 PUSH 0

PUSH 0 은 스택에 0 을 입력하는 명령입니다. 이 0 의 의미는 아래에서 호출될 MessageBoxA() API 의 네 번째 파라미터(uType)로 사용됩니다.

참고로 MessageBoxA() API 는 아래와 같이 4 개의 파라미터를 받습니다.

int WINAPI MessageBox(

__in_opt HWND hWnd,

__in_opt LPCTSTR lpText,

__in_opt LPCTSTR lpCaption,

__in UINT uType

);

* 출처 : http://msdn.microsoft.com/en-us/library/ms645505(VS.85).aspx

* 참고

uType 값이 0 이면 MB_OK 를 의미하며, 단순히 OK(“확인”) 버튼 한 개만 보여주게 됩니다.

# MessageBoxA() 파라미터 입력 2 – "ReverseCore"

002D002E E8 0C000000 CALL 002D003F

002D0033 52 PUSH EDX

002D0034 65:76 65 JBE SHORT 002D009C

002D0037 72 73 JB SHORT 002D00AC

002D0039 65:43 INC EBX

002D003B 6F OUTS DX,DWORD PTR ES:[EDI]

002D003C 72 65 JB SHORT 002D00A3

002D003E 00E8 ADD AL,CH

이번에는 CALL 명령으로 코드 사이에 포함된 문자열 데이터 주소를 스택에 입력하는 기법을 소개하겠습니다. 이 역시 Assembly 프로그래밍 언어에서만 가능한 기법입니다.

위 2D0033 ~ 2D003E 주소 영역은 분명히 프로그램 코드 영역이지만 그 내용은 사실 "ReverseCore" 문자열 데이터 입니다. (붉은색 표시 부분) 즉, "ReverseCore" 문자열의 시작주소는 2D0033 입니다. 그리고 이 문자열은 MessageBoxA() API 의 세 번째 파라미터 (lpCaption)로 사용됩니다.

함수 파라미터로 사용되려면 문자열 주소를 스택에 넣어줘야 하는데 과연 어떤 방식으로 입력할까요?

2D002E 주소의 CALL 002D003F 명령을 디버깅으로 쫓아 들어가 보겠습니다. (StepIn [F7]) 그리고 아래 그림과 같이 스택 주소를 봐주시기 바랍니다.

<Fig. 13>

스택에 "ReverseCore" 문자열 시작 주소인 2D0033 이 입력되었습니다!!! MessageBoxA() 의 세 번째 파라미터가 입력된 셈이죠.

이 트릭은 CALL 명령어의 "동작원리"를 응용한 것입니다.

CALL 002D003F 명령을 수행하면 함수(2D003F) 가 종료된 후 돌아올 리턴 주소(2D0033)를 스택에 입력(PUSH)한 후 해당 함수 주소(2D003F)로 이동(JMP)합니다. 즉, CALL 명령어는 PUSH, JMP 명령어를 합쳐 놓은 것입니다.

사실 2D003F 는 함수 형태가 아닙니다. RETN 명령어로 되돌아가는 형태가 아니란 얘기지요. 여기서의 CALL 002D003F 명령어는 바로 뒤에 이어지는 "ReverseCore" 문자열 주소를 스택에 입력하고 그 다음 코드 명령어로 가기 위해서 사용되고 있는 것입니다.

이해 되시나요? ^^ 재미있는 CALL 명령어 사용법입니다.

# MessageBoxA() 파라미터 입력 3 – "www.reversecore.com"

002D003F E8 14000000 CALL 002D0058

002D0044 77 77 JA SHORT 002D00BD

002D0046 77 2E JA SHORT 002D0076

002D0048 72 65 JB SHORT 002D00AF

002D004A 76 65 JBE SHORT 002D00B1

002D004C 72 73 JB SHORT 002D00C1

002D004E 65:636F 72 ARPL WORD PTR GS:[EDI+72],BP

002D0052 65: PREFIX GS:

002D0053 2E:636F 6D ARPL WORD PTR CS:[EDI+6D],BP

002D0057 006A 00 ADD BYTE PTR DS:[EDX],CH

역시 위 "ReverseCore" 문자열과 마찬가지로 MessageBoxA() API 의 두 번째 파라미터 lpText 문자열("www.reversecore.com")을 입력하는 명령입니다.

위 코드에서 빨간색으로 표시된 부분은 코드 명령어가 아니라 문자열 데이터("www.reversecore.com") 입니다.

2D003F 주소의 CALL 002D0058 명령어는 (앞에서 설명 드린 바와 같이) 바로 뒤에 이어지는 문자열("www.reversecore.com") 데이터의 주소(2D0044)를 스택에 입력하고 그 다음 명령어 주소(2D0058)로 갑니다. (아래 그림 참고)

<Fig. 14>

# MessageBoxA() 파라미터 입력 4 – NULL

002D0058 6A 00 PUSH 0

MessageBoxA() API 의 첫 번째 파라미터인 hWnd 값을 입력합니다. 일반적으로는 메시지 박스가 소속된 윈도우 핸들을 입력하지만, 여기서는 NULL 을 입력하여 무소속(?) 메시지 박스가 출력되도록 만들겠습니다.

# MessageBoxA(NULL, "www.reversecore.com", "ReverseCore", MB_OK) 호출

002D005A FFD0 CALL EAX

드디어 MessageBoxA() API 를 호출하는 CALL 명령어 입니다. 현재 EAX 레지스터에는 위에서 호출한 GetProcAddress() 에 의해서 리턴된 MessageBoxA() API 의 시작 주소(7793EA71)가 저장되어 있습니다. (<Fig. 12> 참고)

2D005A 주소의 CALL EAX 명령어까지 디버깅한 후 레지스터와 스택을 살펴보면 아래 그림과 같습니다.

<Fig. 15>

이 CALL EAX 명령어를 실행하면 메시지 박스가 나타날 것입니다.

<Fig. 16>

# ThreadProc() 리턴값 세팅

002D005C 33C0 XOR EAX,EAX

notepad.exe 프로세스에 인젝션된 코드(ThreadProc() 스레드 함수) 가 종료될 준비를 합니다. 스레드 함수의 리턴값을 0 으로 세팅하기 위해서 XOR EAX, EAX 명령어가 사용됩니다. 함수의 리턴값은 EAX 레지스터를 사용한다는 것을 기억 하시죠?

* 참고

XOR EAX, EAX 명령어는 EAX 레지스터를 0 으로 초기화하는 가장 쉽고 빠른 명령어 입니다. 디버깅하면서 많이 접하게 될 것입니다.

# Stack Frame 해제 및 함수 리턴

002D005E 8BE5 MOV ESP,EBP

002D0060 5D POP EBP

002D0061 C3 RETN

ThreadProc() 함수 시작할 때 생성한 Stack Frame 을 해제 합니다. 그리고 RETN 명령으로 함수가 종료됩니다.

이 ThreadProc() 함수에서 Stack Frame 은 매우 중요합니다. 앞에서 설명 드린 "PUSH 를 이용한 스택에 문자열 넣는 기법" 에서 스택에 입력된 문자열을 일일이 POP 명령으로 힘들게 없앨 필요 없이 Stack Frame 해제 명령어 한방으로 가볍게 초기화 시킬 수 있습니다.

* 참고

Stack Frame 관련 내용은 아래 링크를 참고하세요~

☞ Stack Frame

+--+

Assembly 언어를 이용한 Code Injection 에 관한 설명을 마치도록 하겠습니다. C 언어 보다 더 자유로운 Assembly 언어를 사용하여 다양하고 창의적인 코드를 생성해 보시기 바랍니다. Assembly 초보자도 OllyDbg 의 "Assemble" 명령어를 이용하면 좀 더 쉽게 이용하실 수 있습니다.

위 실습을 다 끝내신 분께서는 한번 제 블로그 이미지에 있는 바이트 코드를 입력해서 실행해 보시기 바랍니다. ^^ 어떤 코드가 나타날까요? (OllyDbg 의 편집 기능과 New Origin Here 기능을 사용하면 되겠지요~)

ReverseCore

위 글이 도움이 되셨다면 추천(VIEW ON) 부탁 드려요~

어셈블리 언어를 이용한 Code Injection (4)

reversecore — Sun, 04 Jul 2010 18:46:05 +0900

다른 프로세스에 인젝션된 코드를 디버깅하면서 동작 원리를 알아보도록 하겠습니다.

이전 강좌의 내용은 아래 링크를 참조하시기 바랍니다.

☞ 어셈블리 언어를 이용한 Code Injection (1)

☞ 어셈블리 언어를 이용한 Code Injection (2)

☞ 어셈블리 언어를 이용한 Code Injection (3)

notepad.exe 디버깅

CodeInjection2.exe

notepad.exe 프로세스에 어셈블리 언어로 제작한 코드를 인젝션 시키고 디버깅을 해보도록 하겠습니다.

Code Injection 기법의 디버깅 방법은 아래 링크를 참고하시기 바랍니다.

☞ Code Injection 기법 (3)

위의 글에서 소개된 방법에 따라 notepad.exe 에 인젝션된 코드를 OllyDbg 로 보면 아래 그림과 같습니다.

<Fig. 1>

* 참고

위 코드의 시작 주소(2D0000)는 사용자 환경에 따라서 틀려집니다.

위 코드를 자세히 디버깅 해보겠습니다.

# Stack Frame 생성

002D0000 55 PUSH EBP ; # ThreadProc()

002D0001 8BEC MOV EBP,ESP

전형적인 스택 프레임 생성 명령어 입니다. 이 명령어가 낯 설은 분들께서는 이 기회에 "55 8BEC" 하고 외워두시는 것도 좋습니다.

스택 프레임을 생성하는 이유는 이후에 나오는 명령어들이 스택에 문자열들을 집어넣는 기법을 사용하기 때문에 위 ThreadProc() 함수가 종료될 때 스택을 깨끗이 정리하기 위해서입니다.

# THREAD_PARAM 구조체 포인터

002D0003 8B75 08 MOV ESI,DWORD PTR SS:[EBP+8]

스택 프레임이 생성된 이후에 [EBP+8] 이 의미하는 것은 함수로 넘어온 첫 번째 파라미터 입니다. 이 경우에는 THREAD_PARAM 구조체 포인터가 될 것입니다.

아래에 THREAD_PARAM 구조체를 표시하였습니다. 구조체의 멤버는 2개의 함수 포인터인데 각각 “LoadLibraryA” 와 “GetProcAddress()” 의 포인터가 저장됩니다. (누가 이 포인터를 구해서 저장시켜 줬을까요? 네, 지난 강좌에서 소개한 CodeInjection2.exe 프로그램에서 구해서 notepad.exe 에 인젝션 시킨 후 스레드 실행할 때 파라미터로 넣어주었죠.)

typedef struct _THREAD_PARAM

{

FARPROC pFunc[2]; // LoadLibraryA(), GetProcAddress()

} THREAD_PARAM, *PTHREAD_PARAM;

위 2D0003 주소의 MOV ESI, DWORD PTR SS:[EBP+8] 명령어를 실행한 이후에 ESI 레지스터에 저장된 주소를 따라가서 확인해 보겠습니다.

<Fig. 2>

ESI 에 280000 주소가 저장되었으며 이 주소는 CodeInjection2.exe 에서 THREAD_PARAM 구조체를 위해 notepad.exe 프로세스 메모리 공간에 할당한 메모리 버퍼의 주소입니다.

* 참고

THREAD_PARAM 구조체 주소(2D0000)는 사용자 환경에 따라서 틀려집니다.

<Fig. 2> 의 메모리 윈도우를 보면 280000 주소에 두 개의 4 byte 값들이 저장된 걸 확인할 수 있습니다. 저 값들이 "LoadLibraryA" 와 "GetProcAddress" API 함수의 시작 주소일 것입니다. 좀 더 직관적으로 확인하기 위해서 OllyDbg 메모리 윈도우의 보기 옵션을 변경해 보겠습니다.

메모리 윈도우에 커서를 위치시킨 후 마우스 우측 메뉴의 "Long – Address" 항목을 선택해 주시기 바랍니다.

<Fig. 3>

위 메뉴 항목을 선택하면 OllyDbg 의 메모리 윈도우는 아래 그림과 같이 표시 형식이 변경됩니다.

<Fig. 4>

주소가 훨씬 더 직관적으로 표시되지요? 또한 친절하게 Comment 에 각 주소에 해당되는 API 이름을 표시해 주고 있습니다.

# "user32.dll" 문자열

002D0006 68 6C6C0000 PUSH 6C6C ; “\0\0ll”

002D000B 68 33322E64 PUSH 642E3233 ; “d.23”

002D0010 68 75736572 PUSH 72657375 ; “resu”

위 코드는 스택(Stack)에 문자열을 저장하는 기법입니다. 스택에 직접 접근할 수 있는 Assembly 프로그래밍 언어에서만 가능한 독특한 기법이지요.

2D0006 주소의 PUSH 6C6C 명령어는 스택에 00006C6C 값을 저장하라는 뜻입니다. 6C 는 ASCII 로 'l' 이지요. 즉, 이 명령은 "\0\0ll" 문자열을 스택에 집어 넣는 것입니다.

그 밑의 2D000B 와 2D0010 주소의 PUSH 명령어도 각각 "d.23" 문자열과 "resu" 문자열을 입력하는 명령어 입니다.

x86 CPU 의 Little Endian 표기법과 스택의 거꾸로 자라는 특성 때문에 문자열을 뒤집어서 입력하는 것을 주의 깊게 보시기 바랍니다. 이것은 디버깅할 때 잘 알고 계셔야 하는 내용입니다.

2D0010 주소까지 디버깅 한 후 스택을 보면 아래 그림과 같습니다.

<Fig. 5>

이와 같은 PUSH 명령어를 이용하여 원하는 문자열을 스택에 입력할 수 있습니다. 또한 Code Injection 할 때 문자열 데이터를 따로 인젝션 하지 않고 코드에 포함시켜서 코드만 인젝션 시킬 수 있습니다.

* 참고

- 문자열 데이타를 코드에 포함시키는 방법은 한가지가 더 있으며, 뒤에서 따로 소개합니다.

- 32 bit OS 에서 PUSH 명령어는 한번에 최대 4 byte 크기의 데이터만 스택에 저장이 가능합니다.

# "user32.dll" 문자열 파라미터 입력

002D0015 54 PUSH ESP

LoadLibraryA() API 는 파라미터로 로딩시킬 DLL 파일 이름 문자열 주소를 받습니다.

HMODULE WINAPI LoadLibrary(

__in LPCTSTR lpFileName

);

* 출처 : http://msdn.microsoft.com/en-us/library/ms684175(VS.85).aspx

위 <Fig. 5> 를 보시면 현재 ESP 의 값은 219FCD4 이며 이것은 "user32.dll" 문자열의 시작 주소입니다. 따라서 2D0015 주소의 PUSH ESP 명령어는 "user32.dll" 문자열 주소(219FCD4)를 스택에 입력하는 명령입니다. (아래 그림 참고)

<Fig. 6>

# LoadLibraryA("user32.dll") 호출

002D0016 FF16 CALL DWORD PTR DS:[ESI] ; kernel32.LoadLibraryA

ESI 레지스터는 <Fig. 4> 에서 보다시피 280000 값을 가지며 이 주소에는 LoadLibraryA() API 의 시작 주소(772C2864)가 저장되어 있습니다. 아래 그림을 봐주시기 바랍니다.

<Fig. 7>

어셈블리 언어의 메모리 참조 문법이 생소하신 분들께서는 이번 기회에 확실히 익혀 두시기 바랍니다. 아래와 같은 간단한 전개식을 사용하면 쉽게 이해하실 수 있습니다. ([ ] 는 C 언어의 포인터 참조와 같은 개념입니다.)

[ESI] = [280000] = 772C2864 (address of kernel32.LoadLibraryA)

2D0016 주소의 CALL DWORD PTR DS:[ESI] 명령어를 실행하면 LoadLibraryA() API 가 호출되면서 파라미터로 입력된 "user32.dll" 이 로딩됩니다. notepad.exe 프로세스는 실행될 때 이미 user32.dll 를 로딩하였으므로 그 로딩 주소만 리턴합니다.

<Fig. 8>

함수의 리턴값은 EAX 에 저장되므로 위 <Fig. 8> 을 보시면 EAX = 778E0000 이 저장되었습니다.

OllyDbg 메뉴의 "View – Executable modules [ALT + E]" 항목을 선택하시면 아래 그림과 같이 프로세스 메모리에 로딩된 DLL 을 확인 할 수 있습니다.

<Fig. 9>

위 그림에서 user32.dll 의 로딩 주소가 778E0000 임을 확인 할 수 있습니다.

# "MessageBoxA" 문자열

002D0018 68 6F784100 PUSH 41786F ; “\0Axo”

002D001D 68 61676542 PUSH 42656761 ; “Bega”

002D0022 68 4D657373 PUSH 7373654D ; “sseM”

역시 PUSH 명령어를 이용해서 문자열 "MessageBoxA" 를 스택에 입력하는 명령어 입니다. (위의 "user32.dll" 문자열 입력과 동일합니다.)

2D0022 주소의 PUSH 명령까지 디버깅을 하고 나면 아래 그림과 같이 스택에 "MessageBoxA" 문자열이 저장됩니다.

<Fig. 10>

# GetProcAddress(hMod, "MessageBoxA") 호출

002D0027 54 PUSH ESP ; - “MessageBoxA”

002D0028 50 PUSH EAX ; - hMod (778E0000)

002D0029 FF56 04 CALL DWORD PTR DS:[ESI+4] ; kernel32.GetProcAddress

현재 ESP 의 값은 0219FCC8 입니다. (<Fig. 10> 참고) 따라서 2D0027 주소의 PUSH ESP 명령어는 "MessageBoxA" 문자열 주소(0219FCC8) 를 스택에 입력하는 명령입니다. (이 문자열 주소는 2D0029 주소에서 호출되는 GetProcAddress() API 의 2nd 파라미터로 사용됩니다.)

그리고 현재 EAX 의 값은 778E0000 입니다. 이는 user32.dll 모듈의 로딩 주소이지요. (<Fig. 8> 참고) 따라서 2D0029 주소의 PUSH EAX 명령어는 user32.dll 의 시작 주소(hMod)를 스택에 입력하는 명령입니다. (이 문자열 주소는 2D0029 주소에서 호출되는 GetProcAddress() API 의 1st 파라미터로 사용됩니다.)

여기까지 디버깅을 진행한 후 스택의 모습은 아래 그림과 같습니다.

<Fig. 11>

ESI 레지스터의 값은 280000 입니다. 따라서 [ESI+4] 의 전개식은 다음과 같습니다. (<Fig. 4>, <Fig. 7> 참고)

[ESI+4] = [280004] = 772C1837 (address of kernel32.GetProcAddress)

따라서 2D0029 주소의 CALL DWORD PTR DS:[ESI+4] 명령어는 GetProcAddress(778E0000, "MessageBoxA") API 를 호출하는 것입니다. 이 CALL 명령어를 실행하면 user32.MessageBoxA() API 시작 주소가 EAX 레지스터에 저장됩니다. (사용자 환경에 따라서 이 주소는 틀려집니다. 제 경우에는 EAX = 7793EA71 입니다.)

<Fig. 12>

(분량이 많아 다음 강좌에 이어서 하겠습니다.)

어셈블리 언어를 이용한 Code Injection (3)

reversecore — Wed, 30 Jun 2010 20:02:54 +0900

어셈블리(Assembly) 언어로 생성한 코드를 가지고 Injector 를 만들어 보도록 하겠습니다.

이전 강좌의 내용은 아래 링크를 참조하시기 바랍니다.

☞ 어셈블리 언어를 이용한 Code Injection (1)

☞ 어셈블리 언어를 이용한 Code Injection (2)

ThreadProc() 함수의 Binary 코드 얻기

asmtest_patch.exe

지난 강좌에서 생성한 asmtest_patch.exe 파일을 OllyDbg 로 열어 보겠습니다. 우리가 프로그래밍한 ThreadProc() 의 주소는 401000 입니다. 메모리 윈도우에서 401000 주소로 갑니다.

<Fig. 1>

ThreadProc() 함수는 401000 ~ 401061 의 주소 영역입니다. 위 그림과 같이 이 영역을 선택하신 후 마우스 우측 메뉴의 "Copy - To file" 항목을 선택하시기 바랍니다. (아래 그림 참고)

<Fig. 2>

이렇게 저장한 파일을 텍스트 에디터로 열어보겠습니다. (GVIM 또는 AcroEdit 추천합니다.)

<Fig. 3>

위 텍스트 파일의 내용은 Hex 값으로 표현된 ThreadProc() 함수로써, IA-32 OpCode (Operation Code) 명령어 입니다. 이 내용은 곧 상대방 프로세스에 인젝션 시킬 코드가 되는 것입니다.

위 텍스트 파일을 아래와 같이 편집합니다. 불필요한 부분을 제거하고 모든 바이트마다 "0x" 표시를 붙여주고 ',' 로 연결합니다. 텍스트 에디터의 편집 기능(열 선택, 문자열 변경)을 적절히 사용하시면 편리합니다.

<Fig. 4>

위 그림에서 편집된 텍스트 내용을 보면 마치 C 언어의 BYTE 배열처럼 보이지 않습니까? 이게 바로 인젝션 시킬 코드 버퍼입니다. (아래 설명되는 CodeInjection2.cpp 파일에서 사용됩니다.)

편집된 텍스트 파일을 첨부합니다.

RVA.txt

CodeInjection2.cpp

CodeInjection2.cpp

Injector 프로그램의 소스 코드입니다. 위에서 텍스트 에디터로 만든 코드 버퍼는 아래 소스에서 g_InjectionCode 배열에 사용되었습니다.

* 참고!

아래 소스코드는 MS Visual C++ 2008 Express Edition 에서 개발되었으며, Windows 7 32bit 환경에서 테스트 되었습니다. 또한 설명의 편의를 위하여 리턴 값 체크와 에러 처리 코드는 생략되었습니다. 원본 소스 코드는 위에 첨부된 CodeInjection2.cpp 파일을 참고하시기 바랍니다.

typedef struct _THREAD_PARAM

{

FARPROC pFunc[2]; // LoadLibraryA(), GetProcAddress()

} THREAD_PARAM, *PTHREAD_PARAM;

// ThreadProc()

BYTE g_InjectionCode[] =

{

0x55, 0x8B, 0xEC, 0x8B, 0x75, 0x08, 0x68, 0x6C, 0x6C, 0x00,

0x00, 0x68, 0x33, 0x32, 0x2E, 0x64, 0x68, 0x75, 0x73, 0x65,

0x72, 0x54, 0xFF, 0x16, 0x68, 0x6F, 0x78, 0x41, 0x00, 0x68,

0x61, 0x67, 0x65, 0x42, 0x68, 0x4D, 0x65, 0x73, 0x73, 0x54,

0x50, 0xFF, 0x56, 0x04, 0x6A, 0x00, 0xE8, 0x0C, 0x00, 0x00,

0x00, 0x52, 0x65, 0x76, 0x65, 0x72, 0x73, 0x65, 0x43, 0x6F,

0x72, 0x65, 0x00, 0xE8, 0x14, 0x00, 0x00, 0x00, 0x77, 0x77,

0x77, 0x2E, 0x72, 0x65, 0x76, 0x65, 0x72, 0x73, 0x65, 0x63,

0x6F, 0x72, 0x65, 0x2E, 0x63, 0x6F, 0x6D, 0x00, 0x6A, 0x00,

0xFF, 0xD0, 0x33, 0xC0, 0x8B, 0xE5, 0x5D, 0xC3

};

// ThreadProc()

004010ED 55 PUSH EBP

004010EE 8BEC MOV EBP,ESP

004010F0 8B75 08 MOV ESI,DWORD PTR SS:[EBP+8]

004010F3 68 6C6C0000 PUSH 6C6C

004010F8 68 33322E64 PUSH 642E3233

004010FD 68 75736572 PUSH 72657375

00401102 54 PUSH ESP

00401103 FF16 CALL DWORD PTR DS:[ESI]

00401105 68 6F784100 PUSH 41786F

0040110A 68 61676542 PUSH 42656761

0040110F 68 4D657373 PUSH 7373654D

00401114 54 PUSH ESP

00401115 50 PUSH EAX

00401116 FF56 04 CALL DWORD PTR DS:[ESI+4]

00401119 6A 00 PUSH 0

0040111B E8 0C000000 CALL 0040112C

00401120 <ASCII>

0040112C E8 14000000 CALL 00401145

00401131 <ASCII>

00401145 6A 00 PUSH 0

00401147 FFD0 CALL EAX

00401149 33C0 XOR EAX,EAX

0040114B 8BE5 MOV ESP,EBP

0040114D 5D POP EBP

0040114E C3 RETN

BOOL InjectCode(DWORD dwPID)

{

HMODULE hMod = NULL;

THREAD_PARAM param = {0,};

HANDLE hProcess = NULL;

HANDLE hThread = NULL;

LPVOID pRemoteBuf[2] = {0,};

hMod = GetModuleHandleA("kernel32.dll");

// set THREAD_PARAM

param.pFunc[0] = GetProcAddress(hMod, "LoadLibraryA");

param.pFunc[1] = GetProcAddress(hMod, "GetProcAddress");

// Open Process

hProcess = OpenProcess(PROCESS_ALL_ACCESS,

FALSE,

dwPID);

// Allocation for THREAD_PARAM

pRemoteBuf[0] = VirtualAllocEx(hProcess,

NULL,

sizeof(THREAD_PARAM),

MEM_COMMIT,

PAGE_READWRITE);

WriteProcessMemory(hProcess,

pRemoteBuf[0],

(LPVOID)&param,

sizeof(THREAD_PARAM),

NULL);

// Allocation for g_InjectionCode

pRemoteBuf[1] = VirtualAllocEx(hProcess,

NULL,

sizeof(g_InjectionCode),

MEM_COMMIT,

PAGE_EXECUTE_READWRITE);

WriteProcessMemory(hProcess,

pRemoteBuf[1],

(LPVOID)&g_InjectionCode,

sizeof(g_InjectionCode),

NULL);

hThread = CreateRemoteThread(hProcess,

NULL,

(LPTHREAD_START_ROUTINE)pRemoteBuf[1],

pRemoteBuf[0],

NULL);

WaitForSingleObject(hThread, INFINITE);

CloseHandle(hThread);

CloseHandle(hProcess);

return TRUE;

}

<코드 1>

위의 코드와 지난번 CodeInjection.cpp 의 코드와의 가장 큰 차이점은 인젝션 시키는 코드 내에 필요한 문자열 데이터를 같이 포함시킨 것입니다.

따라서 _THREAD_PARAM 구조체에서 문자열 멤버가 사라졌습니다. 그리고 기존 C로 된 ThreadProc() 함수 대신 <Fig. 4> 의 OpCode 버퍼(g_InjectionCode)가 사용됩니다. (이 OpCode 버퍼를 생성하기 위해 OllyDbg 의 “Assembly” 명령을 사용했던 것을 기억하시죠?)

조금 더 정교하게 프로그래밍을 했다면 _THREAD_PARAM 구조체조차 필요 없도록 만들 수도 있습니다. 세부적인 구현 방법은 어디까지나 구현하는 사람의 마음입니다.

중요한 것은 어셈블리 프로그래밍을 통해서 생성된 OpCode 버퍼를 Injector 소스코드에 사용하여 상대방 프로세스에 인젝션 시킨다는 것입니다.

예전에 설명 드린 CodeInjection.cpp 소스 코드와 비교해서 보시면 차이점을 더 명확히 이해할 수 있을 것입니다. (위 <코드 1> 의 세부 설명은 생략합니다. Code Injection 의 구현 방법에 대해서는 밑의 링크된 설명을 참고하시기 바랍니다.)

☞ 참고 : Code Injection 기법 (2)

다음 강좌에서 실제로 상대방 프로세스에 인젝션 시킨 후 디버깅을 하면서 저 어셈블리 코드가 어떤 의미를 가지고 있는지 알아보도록 하겠습니다.

☞ 어셈블리 언어를 이용한 Code Injection (4)

ReverseCore

위 글이 도움이 되셨다면 추천(VIEW ON) 부탁 드려요~

어셈블리 언어를 이용한 Code Injection (2)

reversecore — Mon, 28 Jun 2010 23:00:45 +0900

지난 강좌에 이어지는 내용입니다.

☞ 어셈블리 언어를 이용한 Code Injection (1)

ThreadProc()

Assembly 언어로 ThreadProc() 함수를 만들겠습니다. 지난 강좌에서 C 로 만든 ThreadProc() 과의 차이점은 Code 사이에 필요한 Data(문자열)를 포함 시키는 것입니다.

각자 아래 그림과 같이 입력해 주시기 바랍니다. 각 Assembly 명령어에 대한 설명은 뒤쪽에서 하겠습니다. (“Fill with NOP’s” 옵션은 uncheck 해주시고, 오타가 나면 그 주소에 가서 다시 입력하시면 됩니다.)

<Fig. 5>

40102E 주소의 CALL 0040103F 명령어까지 잘 입력하셨나요? 그 다음에는 문자열을 입력합니다. Assemble 윈도우를 닫아주세요. OllyDbg의 코드 윈도우에서 401033 주소에 커서를 위치시킨 후 아래 그림과 같이 "Edit" 명령(단축키 : [Ctrl+E])을 내려줍니다.

<Fig. 6>

위 그림의 Edit 윈도우에서 "ASCII" 항목에 "ReverseCore" 를 입력합니다. 문자열은 반드시 NULL 로 끝나야 하므로 "HEX" 항목에서 00 값을 추가해 줍니다. ("Keep size" 옵션은 uncheck 로 해주세요.)

이와 같이 입력한 후 OllyDbg 에서 코드를 보면 아래 그림과 같습니다.

<Fig. 7>

위 그림에서 푸른색으로 반전된 영역이 바로 "ReverseCore" 문자열 영역입니다. 매우 이상한 명령어로 표시된 것을 볼 수 있습니다. 이렇게 표시되는 이유는 OllyDbg 의 Disassembler 가 문자열을 IA-32 명령어로 잘 못 해석한 것입니다. 이것은 어디까지나 Code 위치에 문자열을 입력한 저의 잘못(?)이지 OllyDbg 의 Disassembler 의 문제는 아닙니다.

* 참고

디버깅을 할 때 이와 같은 상황을 종종 부딪히게 됩니다. 또한 이를 이용한 Anti-Debugging 기법도 있습니다. 향후 Anti-Debugging 에 대해서 설명할 때 소개해 드리겠습니다.

위 <Fig. 7> 화면처럼 문자열을 선택한 상태에서 "Analysis" 명령(단축키 : Ctrl+A)을 내려보겠습니다.

* 참고

OllyDbg 의 “Analysis” 명령은 코드를 다시 해석하라는 명령입니다. 주로 Unpack 된 코드를 재 해석할 때 많이 사용하게 됩니다.

<Fig. 8>

위 그림은 Analysis 명령이 수행된 이후에 코드의 모습입니다. 401033 주소의 "ReverseCore" 문자열은 잘 보입니다만, 401000 주소 이후의 명령어들은 잘 못 해석이 되었습니다. (OllyDbg 2.0 에서도 코드와 데이터를 100% 정확히 구별해서 보여주지는 못합니다. 사실 이게 문자열인지 명령어인지 판단하기 어렵습니다.)

위 <Fig. 8> 은 코드를 보기 어려우므로 마우스 우측 메뉴의 "Analysis – Remove analysis from module" 명령을 사용하여 코드를 원래대로 되돌립니다.

<Fig. 9>

위 Remove analysis 명령을 사용하면 다시 위의 <Fig. 7> 과 같은 형태의 코드로 보이게 됩니다.

이제 401033 주소의 "ReverseCore" 문자열 뒤의 40103F 주소부터 다시 입력할 차례입니다. (<Fig. 7>, <Fig. 8> 의 40102E 주소의 CALL 40103F 명령어 참고)

<Fig. 10>

그리고 401044 주소에 문자열("www.reversecore.com")을 입력합니다. (마지막에 NULL 입력을 잊지 마시구요.)

<Fig. 11>

401058 주소부터 아래와 같이 명령어를 입력합니다.

<Fig. 12>

이것으로써 ThreadProc() 코드 입력이 모두 완료되었습니다. 아래 그림에 전체 코드가 나타나 있으니 각자 오타를 점검해보시기 바랍니다.

<Fig. 13>

* 참고

401033, 401044 주소의 내용은 명령어가 아니고 문자열입니다. OllyDbg 에서 문자열을 명령어로 인식하여 이상하게 표시하고 있습니다.

Save File

위에서 생성한 코드를 잘 저장합니다. OllyDbg 의 코드 윈도우에서 마우스 우측 버튼 메뉴 중 "Copy to executable \ All modifications" 를 선택합니다. (아래 그림 참고)

<Fig. 14>

아래 그림과 같이 확인 메시지 창이 뜹니다. "Copy all" 을 선택해 주세요.

<Fig. 15>

마지막으로 변경 내용을 보여주는 창이 나타납니다. 마우스 우측 메뉴의 "Save file" 항목을 선택합니다. (아래 그림 참고)

<Fig. 16>

이후에 나타나는 파일 저장 다이알로그에서 적당한 파일 이름(asmtest_patch.exe)을 적어준 후 저장합니다.

asmtest_patch.exe

다음 강좌에서 asmtest_patch.exe 의 어셈블리 코드를 이용해서 Injector 를 만들어 보도록 하겠습니다.

* 참고 : 새롭게 소개된 OllyDbg 명령어

Assemble [Space]

Analysis [Ctrl+A]

New origin here [Ctrl+Gray *]

ReverseCore

위 글이 도움이 되셨다면 추천(VIEW ON) 부탁 드려요~

어셈블리 언어를 이용한 Code Injection (1)

reversecore — Sun, 27 Jun 2010 17:23:55 +0900

어셈블리(Assembly) 프로그래밍 언어를 이용하여 Code Injection 기법에 사용되는 코드를 생성해 보도록 하겠습니다.

Code Injection 관련 내용은 아래 강좌를 참고하시기 바랍니다.

☞ Code Injection 기법 (1)

☞ Code Injection 기법 (2)

☞ Code Injection 기법 (3)

Goal

이번 강좌에서는 OllyDbg 의 Assemble 기능을 이용하여 Assembly 언어로 인젝션 시킬 코드(ThreadProc() 함수)를 만들어 보도록 하겠습니다. Assembly 언어는 C 언어보다 훨씬 더 자유로운 (정형화 되지 않은) 코드를 생성할 수 있습니다. (예: 스택(Stack), 레지스터(Register) 를 직접 access 가능) 그리고 CodeInjection.cpp 소스코드를 수정하여 Assembly 언어로 제작된 ThreadProc() 함수를 notepad.exe 프로세스에 인젝션 시켜보도록 하겠습니다.

이전 강좌에서 설명 드린 (C 언어로 생성된) ThreadProc() 과 어떤 차이점이 있는지 잘 살펴보시기 바랍니다.

Assembly 프로그래밍

C/C++ 언어의 대표적인 개발 툴은 MicroSoft Visual C++ 와 Borland C++ Builder 입니다.

Assembly 언어에도 MASM(MicroSoft Macro Assembler), TASM(Borland Turbo Assembler), FASM(Flat Assembler) 등의 개발 툴(Assembler)이 있습니다.

참고로 저는 C/C++ 언어는 MS Visual C++ 로 개발하고 Assembly 언어는 MASM 으로 개발합니다. 특히 MASM 은 다양한 Macro 함수와 라이브러리를 지원하기 때문에 거의 C 언어와 비슷한 수준으로 편리하게 프로그래밍을 할 수 있습니다.

Assembly 프로그래밍을 정식으로 하시려면 MASM 을 설치하고 프로그래밍 하시면 됩니다. 또는 Visual C++ 와 같은 C 언어 개발 툴에서 인라인 어셈블리(Inline Assembly)를 사용할 수 도 있습니다. 이런 방식은 개발자에게 잘 어울리는 방식입니다.

우리는 모두 리버서(Reverser)이기 때문에 이번 강좌에서는 리버서에게 좀 더 잘 어울리는 방법을 소개하겠습니다. 바로 OllyDbg 에서 지원하는 "Assemble" 기능을 이용해서 프로그래밍을 하는 것입니다.

* 참고

OllyDbg 의 "Assemble" 기능은 간단한 Assembly 프로그래밍을 지원하는데, 이는 리버싱에 매우 유용하게 사용됩니다. (디버깅하면서 코드를 이리저리 수정할 일이 많기 때문이지요.)

OllyDbg 의 "Assemble" 명령

OllyDbg 의 “Assemble” 명령어를 이용하여 Assembly 프로그래밍을 해보겠습니다.

asmtest.exe

위에 첨부된 asmtest.exe 실행 파일을 OllyDbg 로 열어보겠습니다. (asmtest.exe 는 Assembly 프로그래밍 테스트 용도로 제작된 -아무런 기능이 없는- 실행 파일입니다.)

<Fig. 1>

위 그림과 같이 코드 섹션의 맨 윗부분(401000)을 봐주시기 바랍니다. OllyDbg 의 새로운 명령어를 소개해 드리겠습니다. 바로 EIP 를 원하는 주소로 바꿔버리는 기능입니다.

OllyDbg 의 코드 윈도우에서 401000 주소에 커서를 위치시킨 후 마우스 우측 메뉴의 "New origin here [Ctrl+Gray*]" 항목을 선택해 주세요.

<Fig. 2>

아래 그림과 같이 EIP는 401000 주소로 변하게 됩니다.

<Fig. 3>

위 EIP 변경 기능은 디버깅에 유용하게 사용될 수 있으므로 잘 기억해 두시기 바랍니다.

* 참고!

"New origin here" 기능은 단순히 EIP 만 바꿔버리는 것이기 때문에 직접 디버깅을 해서 그 주소로 가는 것과는 틀립니다. 레지스터와 스택의 내용은 전혀 바뀌지 않기 때문입니다.

이제 401000 주소에서 "Assemble" 명령(단축키 : [Space])을 내리면 아래 그림과 같은 Assemble 입력 창이 나타납니다.

<Fig. 4>

이제부터 OllyDbg 에서 간단한 Assembly 프로그래밍을 할 수 있게 되었습니다.

* 참고

위 <Fig. 4> 에서 "Fill with NOP’s" 항목은 uncheck 해주시기 바랍니다. OllyDbg 의 Assemble 명령은 해당 주소에 사용자 코드를 입력하는 것입니다. 만약 이 항목이 check 되어 있으면 기존의 코드 보다 짧은 길이의 코드를 입력했을 때 남은 길이만큼 NOP (No Operation) 명령어를 채워 넣어서 전체적인 Code Alignment 를 맞춰주게 됩니다. 이번 강좌에서는 설명의 편의를 위해서 uncheck 상태로 진행하도록 하겠습니다.

(내용이 많아 다음 강좌에 이어서 하겠습니다.)

☞ 어셈블리 언어를 이용한 Code Injection (2)

Code Injection 기법 (3)

reversecore — Thu, 24 Jun 2010 10:43:46 +0900

Code Injection 기법에 의해서 인젝션된 코드를 디버깅 하는 방법에 대해서 알아보도록 하겠습니다.

이전 강좌의 내용은 아래 링크를 참조하시기 바랍니다.

☞ Code Injection 기법 (1)

☞ Code Injection 기법 (2)

Code Injection 디버깅 실습

CodeInjection.exe

1. notepad.exe 디버깅

OllyDbg 를 이용하여 notepad.exe 파일의 디버깅을 시작합니다. 아래 그림과 같이 실행[F9] 버튼을 선택해서 notepad.exe 를 "Running" 상태로 만들어주세요.

<Fig. 1>

2. OllyDbg 옵션 변경

Code Injection 은 상대방 프로세스에 새로운 스레드를 생성하는 기법이므로 아래와 같이 OllyDbg 의 옵션을 변경하면 인젝션된 스레드 코드 시작부터 디버깅이 가능합니다.

<Fig. 2>

이제부터 notepad.exe 프로세스에서 스레드가 생성된다면 해당 스레드 함수 시작코드에서 멈추게 됩니다.

3. CodeInjection.exe 실행

Process Explorer 를 이용하여 notepad.exe 프로세스의 PID 를 구합니다.

<Fig. 3>

PID 값을 실행 파라미터로 하여 CodeInjection.exe 를 실행합니다.

<Fig. 4>

4. 스레드 시작 코드

CodeInjection.exe 프로세스가 실행되어 코드 인젝션이 성공하면 아래 그림과 같이 인젝션된 스레드 코드 시작 위치에서 디버깅이 멈추게 됩니다.

<Fig. 5>

주의 하실점은 디버깅이 멈춘 것이지 EIP 가 이곳으로 세팅된 것이 아닙니다.

위 그림의 150000 주소에 BP 를 설치한 후 실행[F9] 시켜 주세요. 실행 제어가 정확히 BP 설치 주소(150000)에 멈추게 되고 이제부터 펀안하게 디버깅을 진행하시면 됩니다.

* 참고!

실행 환경에 따라서 위 주소는 다르게 표시될 수 있습니다.

OllyDbg 의 편리한 기능을 이용하여 인젝션된 코드를 디버깅 하는 방법에 대해서 살펴보았습니다.

다음 강좌에는 C 언어가 아닌 Assembly 언어를 이용해서 인젝션 코드를 만들어 보도록 하겠습니다. 많이 기대해 주세요~

☞ 어셈블리 언어를 이용한 Code Injection (1)

ReverseCore

위 글이 도움이 되셨다면 추천(VIEW ON) 부탁 드려요~

Code Injection 기법 (2)

reversecore — Wed, 23 Jun 2010 00:15:20 +0900

Code Injection 실습 예제인 CodeInjection.exe 의 소스 코드(CodeInjection.cpp)를 살펴보도록 하겠습니다.

이전 강좌의 내용은 아래 링크를 참조하시기 바랍니다.

☞ Code Injection 기법 (1)

CodeInjection.cpp

CodeInjection.zip

* 참고!

CodeInjection.cpp 는 Visual C++ 2008 Express Edition 으로 개발되었으며 Windows 7 32bit 환경에서 테스트 되었습니다. 또한 Visual C++ 의 코드 최적화 기능을 사용하지 않고 빌드 하였습니다. (/Od)

아래 소개되는 코드들은 설명의 편의를 위하여 에러 처리 부분을 생략하였습니다. 완전한 코드는 첨부된 CodeInjection.cpp 파일을 참고하시기 바랍니다.

main()

먼저 main() 함수를 살펴 보겠습니다.

int main(int argc, char *argv[])

{

DWORD dwPID = 0;

if( argc != 2 )

{

printf("\n USAGE : %s <pid>\n", argv[0]);

return 1;

}

// code injection

dwPID = (DWORD)atol(argv[1]);

InjectCode(dwPID);

return 0;

}

<코드 1 – main() 함수>

main() 함수의 역할은 InjectCode() 함수를 호출하는 것입니다. 이때 함수 파라미터로 상대방 프로세스의 PID 값을 넘겨줍니다.

ThreadProc()

이제 상대방 프로세스에 인젝션 시킬 코드(스레드 함수)를 살펴보겠습니다.

// Thread Parameter

typedef struct _THREAD_PARAM

{

FARPROC pFunc[2]; // LoadLibraryA(), GetProcAddress()

char szBuf[4][128]; // "user32.dll", "MessageBoxA",

// "www.reversecore.com", "ReverseCore"

} THREAD_PARAM, *PTHREAD_PARAM;

// LoadLibraryA()

typedef HMODULE (WINAPI *PFLOADLIBRARYA)

(

LPCSTR lpLibFileName

);

// GetProcAddress()

typedef FARPROC (WINAPI *PFGETPROCADDRESS)

(

HMODULE hModule,

LPCSTR lpProcName

);

// MessageBoxA()

typedef int (WINAPI *PFMESSAGEBOXA)

(

HWND hWnd,

LPCSTR lpText,

LPCSTR lpCaption,

UINT uType

);

// Thread Procedure

DWORD WINAPI ThreadProc(LPVOID lParam)

{

PTHREAD_PARAM pParam = (PTHREAD_PARAM)lParam;

HMODULE hMod = NULL;

FARPROC pFunc = NULL;

// LoadLibrary(“user32.dll”)

// pParam->pFunc[0] = kernel32!LoadLibraryA()

// pParam->szBuf[0] = “user32.dll”

hMod = ((PFLOADLIBRARYA)pParam->pFunc[0])(pParam->szBuf[0]);

// GetProcAddress(“MessageBoxA”)

// pParam->pFunc[1] = kernel32!GetProcAddress()

// pParam->szBuf[1] = “MessageBoxA”

pFunc = (FARPROC)((PFGETPROCADDRESS)pParam->pFunc[1])(hMod, pParam->szBuf[1]);

// MessageBoxA(NULL, “www.reversecore.com”, “ReverseCore”, MB_OK)

// pParam->pFunc[1] = kernel32!GetProcAddress()

// pParam->szBuf[1] = “MessageBoxA”

((PFMESSAGEBOXA)pFunc)(NULL, pParam->szBuf[2], pParam->szBuf[3], MB_OK);

return 0;

}

<코드 2 – ThreadProc() 함수>

위 코드에서 실제로 인젝션 되는 부분은 ThreadProc() 함수입니다. 그 위의 typedef 문은 C 언어 문법을 위한 것이므로 인젝션 시킬 필요가 없습니다.

ThreadProc() 의 코드는 함수 포인터를 많이 사용해서 얼핏 복잡하게 보이지만 사실 내용은 아래와 같이 간단합니다.

hMod = LoadLibraryA(“user32.dll”);

pFunc = GetProcAddress(hMod, “MessageBoxA”);

pFunc(“www.reversecore.com”, “ReverseCore”);

<코드 2> 의 주석을 참조하시면 ThreadProc() 의 코드는 쉽게 이해가 가실 것입니다.

중요한 것은 ThreadProc() 코드의 개념입니다.

Code Injection 기법의 핵심은 독립 실행 코드를 인젝션 시키는 것입니다.

그러기 위해서 코드와 (코드에서 참조하는) 데이터를 같이 인젝션 시키는 것입니다. 그리고 인젝션 시키는 코드에서 역시 인젝션 시킨 데이터를 정확히 참조할 수 있도록 해야 합니다.

위 ThreadProc() 함수를 보시면 직접 API 를 호출 하지 않습니다. 또한 문자열도 직접 정의해서 사용하지 않습니다. 전부 스레드 파라미터로 넘어온 THREAD_PARAM 구조체에서 가져다 사용하고 있습니다.

만약 일반적인 프로그램이라면 ThreadProc() 의 코드는 아래와 같이 간단히 작성할 수 있습니다.

DWORD WINAPI ThreadProc(LPVOID lParam)

{

MessageBoxA(NULL, "www.reversecore.com", "ReverseCore", MB_OK);

return 0;

}

<코드 3 – 일반적인 프로그램에서의 ThreadProc()>

위 <코드 3>을 빌드하여 생성된 파일을 디버거로 보면 아래 그림과 같습니다.

<Fig. 1>

위 그림의 코드(10001000 ~ 10001018 영역)를 다른 프로세스에 그대로 인젝션 시킨다면 정상적으로 실행되지 않습니다. 그 이유는 코드에서 사용되는 10009290, 1000929C, 100080F0 주소의 내용이 상대방 프로세스에는 없기 때문입니다.

따라서 저 주소에 해당하는 문자열과 API 주소를 같이 인젝션 시켜야 합니다. 또한 <Fig. 1>의 코드 역시 그 인젝션된 데이터의 주소를 정확히 참조하도록 프로그래밍 되어야 합니다.

이와 같은 조건을 만족시키기 위해서 <코드 2> 의 ThreadProc() 함수는 THREAD_PARAM 구조체를 이용해서 2 개의 API 주소와 4 개의 문자열 데이터를 받아들입니다. 2 개의 API 는 바로 “LoadLibraryA()” 와 “GetProcAddress()” 입니다. 이 2 개의 API 만 있으면 모든 라이브러리의 함수를 호출 할 수 있습니다.

* 참고 사항

1. 위 실습 예제의 경우에 LoadLibraryA() 와 GetProcAddress() 의 주소 말고 MessageBoxA() 의 주소를 직접 전달하여 사용해도 됩니다. 하지만 정석은 LoadLibraryA() 와 GetProcAddress() 만을 전달한 후 이를 이용해서 필요한 DLL 을 로딩시켜 원하는 함수 주소를 직접 구하는 것입니다. 이 방식의 장점은 해당 라이브러리를 프로세스에 정확히 로딩시킨다는 것입니다. 가령 notepad.exe 프로세스에 윈도우 소켓 API 인 ws2_32!connect() 의 주소를 넘겨주면 에러가 발생할 것입니다. (notepad.exe 에 기본적으로 ws2_32.dll 이 로딩되지 않았으니까요.)

2. 대부분의 유저 모드 프로세스는 kernel32.dll 을 로딩하므로 LoadLibraryA(), GetProcAddress() 의 주소를 직접 넘기는 것은 크게 무리가 없습니다. 단, kernel32.dll 을 로딩하지 않는 시스템 프로세스(예: smss.exe)도 있으니 사전에 꼭 확인하시기 바랍니다.

3. Kernel32.dll 같은 시스템 라이브러리는 OS 가 부팅되어 있는 상태에서는 모든 프로세스에서 동일한 주소에 로딩되어 있습니다. OS 버전이 틀리거나 재부팅(Vista, 7 의 경우)을 하거나 하면 같은 모듈이라도 로딩 주소는 틀려집니다.

위 <코드 2> 의 내용을 디버거로 살펴보면 아래 그림과 같습니다.

<Fig. 2>

위의 <Fig. 2> 의 코드를 보시면 모든 중요한 데이터는 스레드 파라미터인 pParam 으로 받아서 사용하는 것을 알 수 있습니다. 즉, <Fig. 2> 의 ThreadProc() 함수는 독립 실행 코드라고 말 할 수 있습니다. 위의 <Fig. 2> 와 앞에서 소개한 <Fig. 1> 를 비교해 보시면 그 차이점을 확인하실 수 있습니다.

* 참고!

Visual C++ 2008 Express Edition 에서 프로젝트의 [Release/Debug] 모드와 [최적화] 옵션에 따라서 CodeInjection.cpp 파일은 <Fig. 2> 와는 다른 형태로 빌드 될 수 있습니다. 위 실습 예제는 Release 모드에서 최적화 옵션 사용 안함(/Od)으로 빌드 하였습니다.

InjectCode()

아래는 Code Injection 기법의 핵심인 InjectCode() 함수입니다.

BOOL InjectCode(DWORD dwPID)

{

HMODULE hMod = NULL;

THREAD_PARAM param = {0,};

HANDLE hProcess = NULL;

HANDLE hThread = NULL;

LPVOID pRemoteBuf[2] = {0,};

DWORD dwSize = 0;

hMod = GetModuleHandleA("kernel32.dll");

// set THREAD_PARAM

param.pFunc[0] = GetProcAddress(hMod, "LoadLibraryA");

param.pFunc[1] = GetProcAddress(hMod, "GetProcAddress");

strcpy_s(param.szBuf[0], "user32.dll");

strcpy_s(param.szBuf[1], "MessageBoxA");

strcpy_s(param.szBuf[2], "www.reversecore.com");

strcpy_s(param.szBuf[3], "ReverseCore");

// Open Process

hProcess = OpenProcess(PROCESS_ALL_ACCESS, // dwDesiredAccess

FALSE, // bInheritHandle

dwPID); // dwProcessId

// Allocation for THREAD_PARAM

dwSize = sizeof(THREAD_PARAM);

pRemoteBuf[0] = VirtualAllocEx(hProcess, // hProcess

NULL, // lpAddress

dwSize, // dwSize

MEM_COMMIT, // flAllocationType

PAGE_READWRITE); // flProtect

WriteProcessMemory(hProcess, // hProcess

pRemoteBuf[0], // lpBaseAddress

(LPVOID)&param, // lpBuffer

dwSize, // nSize

NULL); // [out] lpNumberOfBytesWritten

// Allocation for ThreadProc()

dwSize = (DWORD)InjectCode - (DWORD)ThreadProc;

pRemoteBuf[1] = VirtualAllocEx(hProcess, // hProcess

NULL, // lpAddress

dwSize, // dwSize

MEM_COMMIT, // flAllocationType

PAGE_EXECUTE_READWRITE); // flProtect

WriteProcessMemory(hProcess, // hProcess

pRemoteBuf[1], // lpBaseAddress

(LPVOID)ThreadProc, // lpBuffer

dwSize, // nSize

NULL); // [out] lpNumberOfBytesWritten

hThread = CreateRemoteThread(hProcess, // hProcess

NULL, // lpThreadAttributes

0, // dwStackSize

(LPTHREAD_START_ROUTINE)pRemoteBuf[1],

pRemoteBuf[0], // lpParameter

0, // dwCreationFlags

NULL); // lpThreadId

WaitForSingleObject(hThread, INFINITE);

CloseHandle(hThread);

CloseHandle(hProcess);

return TRUE;

}

<코드 4 - InjectCode() 함수>

위 코드는 DLL Injection 코드와 매우 유사합니다.

InjectCode() 함수의 앞 부분은 THREAD_PARAM 구조체 변수를 세팅하고 있습니다. 이 값들은 상대방 프로세스에 인젝션 되어 ThreadProc() 스레드 함수에 파라미터로 전달될 것입니다.

* 참고!

Windows 7 에서 모든 프로세스에 로딩된 kernel32.dll 의 주소가 동일하므로 CodeInjection.exe 프로세스에서 구한 API(“LoadLibraryA”, “GetProcAddress”) 주소와 notepad.exe 프로세스에서 구한 API(“LoadLibraryA”, “GetProcAddress”) 주소가 서로 동일하다는 것을 기억하시기 바랍니다.

그리고 API 함수 호출이 이어지는데요, 핵심 API 함수들의 호출 흐름만 살펴보면 아래와 같습니다.

OpenProcess()

// data : THREAD_PARAM

VirtualAllocEx()

WriteProcessMemory()

// code : ThreadProc()

VirtualAllocEx()

WriteProcessMemory()

CreateRemoteThread()

위 코드의 핵심은 상대방 프로세스에 data 와 code 를 각각 메모리 할당하고 인젝션 시켜 준다는 것입니다.

마지막으로 CreateRemoteThread() API 를 이용해서 원격 스레드를 실행시킵니다.

+---+

이로써 Code Injection 기법을 이용한 실습 예제 소스코드에 대한 설명을 마치도록 하겠습니다.

설명의 편의성을 위하여 매우 기초적인 실습 예제를 소개하였습니다. Code Injection 의 개념을 이해하시는데 어려움이 없을 거라 생각됩니다. 위 개념을 이해하셨다면 다양한 아이디어로 자신만의 Code Injection 기법을 연습해 보시기 바랍니다

* 참고!

제가 Code Injection 기법을 구현할 때 인젝션 시킬 코드 부분은 어셈블리 언어로 프로그래밍 합니다. 복잡한 것은 MASM 을 사용하고, 간단한 것은 OllyDbg 의 “Assemble” 명령을 사용합니다. (단축키 [Space]) 이렇게 만들어진 Hex 코드 버퍼를 위 InjectCode() 함수 내에서 상대방 프로세스에 인젝션 시켜줍니다. 이러한 방법은 좀 더 직관적인 인젝션 코드를 만드는데 도움이 됩니다. Code Injection 마지막 강좌에서 간단히 실습해보도록 하겠습니다.

다음 강좌에서는 Code Injection 기법을 디버깅 하는 방법에 대해서 알아보도록 하겠습니다.

☞ Code Injection 기법 (3)

ReverseCore

위 글이 도움이 되셨다면 추천(VIEW ON) 부탁 드려요~

Code Injection 기법 (1)

reversecore — Tue, 22 Jun 2010 00:25:44 +0900

Code Injection 기법에 대해 설명하고 실습 예제를 분석하겠습니다. DLL Injection 기법과 어떻게 다른지 비교 분석해보겠습니다.

* 본문 내용을 편하게 읽기 위해서는 아래의 배경지식이 필요합니다.

☞ DLL Injection – 다른 프로세스에 침투하기 (1)

☞ DLL Injection in Windows 7 (1)

Code Injection

Code Injection 이란 상대방 프로세스에 독립 실행 코드를 삽입한 후 실행 시키는 기법입니다. 일반적으로 CreateRemoteThread() API 를 이용하여 원격 스레드 형태로 실행 시키므로 Thread Injection 이라고도 얘기합니다.

아래 그림은 Code Injection 의 개념을 보여주고 있습니다.

<Fig. 1>

인젝션 대상이 되는 target.exe 프로세스에 코드와 데이터를 삽입합니다. 이때 코드의 형식은 스레드 프로시져(Thread Procedure) 형식으로 해주고, 코드에서 사용되는 데이터는 스레드의 파라미터로 전달해 주면 됩니다. 즉, 코드와 데이터를 각각 인젝션 시켜주는 것입니다.

이와 같이 개념은 간단한데, 구현에 있어서 주의해야 할 내용이 있습니다. Code Injection 구현의 주의 사항에 대해서 DLL Injection 과 비교하여 설명 드리겠습니다.

☞ 참고 : DLL Injection – 다른 프로세스에 침투하기 (1)

DLL Injection vs Code Injection

아래와 같이 간단한 코드가 있습니다. 코드의 내용은 윈도우 메시지 박스를 출력하는 것입니다.

DWORD WINAPI ThreadProc(LPVOID lParam)

{

MessageBoxA(NULL, "www.reversecore.com", "ReverseCore", MB_OK);

return 0;

}

DLL Injection 기법이라면 위 코드를 DLL 파일 형태로 만든 후 다른 프로세스에 인젝션 시키면 됩니다.

OllyDbg 를 실행시켜 위 ThreadProc() 코드 영역을 살펴보겠습니다.

<Fig. 2>

위 그림의 코드에서 사용되는 주소를 주목하시기 바랍니다.

먼저 10001002 주소의 PUSH 10009290 명령어와 그 밑의 PUSH 1000929C 명령어에 사용된 10009290, 1000929C 주소를 보겠습니다. 이 명령어들은 MessageBoxA() API 에 사용될 문자열(“ReverseCore”, “www.reversecore.com”) 주소를 스택에 저장시킵니다.

<Fig. 3>

위 그림을 보시면 이 문자열들의 주소(10009290, 1000929C)는 DLL의 데이터 섹션 영역에 위치합니다.

이번에는 <Fig. 2> 에서 1000100E 주소의 CALL DWORD PTR DS:[100080F0] 명령어에 사용된 100080F0 주소를 보겠습니다. 참고로 이 CALL 명령어는 바로 user32!MessageBoxA() API 호출 명령입니다.

<Fig. 4>

위 그림에서 100080F0 주소는 바로 DLL 의 IAT(Import Address Table) 영역임을 알 수 있습니다. (그 위로 다른 API 들의 주소를 확인 할 수 있습니다.)

이와 같이 DLL 의 코드에서 사용되는 모든 데이터는 DLL 의 데이터 영역에 위치합니다.

따라서 DLL Injection 기법으로 DLL 을 통째로 상대방 프로세스 메모리에 삽입시키면 코드와 데이터가 같이 메모리에 존재하기 때문에 코드는 정상적으로 실행될 수 있습니다.

Code Injection 은 필요한 코드(<Fig. 2>)를 인젝션 시키는 것입니다. 하지만 코드에서 사용되는 데이터(<Fig. 3>, <Fig. 4>) 도 같이 인젝션 시켜줘야 정상적으로 코드의 실행이 가능해집니다. (또한 인젝션된 데이터의 주소를 코드에서 잘 알아볼 수 있도록 프로그래밍 해야 합니다.)

이러한 이유 때문에 DLL Injection 기법 보다 고려할 사항이 좀 더 많습니다.

아래의 실습 예제 코드를 보시면 더 확실히 파악하실 수 있습니다.

코드 인젝션을 사용하는 이유

코드 인젝션은 DLL 인젝션과 비교하여 기능은 비슷하면서 고려해야 할 사항은 더 많기 때문에 사용하기 불편하게 느껴질 수 있습니다. 과연 코드 인젝션의 장점은 무엇일까요?

1) 메모리를 적게 차지한다.

아주 작은 크기의 코드와 데이터를 인젝션 할 때는 DLL 로 만들어서 인젝션 시킬 필요가 없습니다. 간단히 코드 인젝션으로 구현하면 DLL 인젝션과 같은 기능을 제공하면서 메모리를 훨씬 적게 차지합니다.

2) 흔적을 찾기 어렵다.

DLL 인젝션은 해당 프로세스 메모리에 흔적을 남기기 때문에 간단히 인젝션 여부를 알 수 있습니다. 하지만 Code 인젝션은 쉽게 흔적을 남기지 않습니다. (물론 이 역시 알아낼 수 있는 방법이 있습니다.) 이 특징 때문에 악성코드에서도 코드 인젝션을 많이 사용합니다.

3) 기타

별도의 DLL 파일 없이 Code Injector 프로그램만 있으면 됩니다. 또한 처음에는 생소하지만 일단 익숙해 지게 되면 아주 쉽고 편리하게 구현이 가능합니다.

간단히 정리하면 DLL Injection 은 규모가 크고 복잡한 일을 수행할 때 사용하고, Code Injection 은 규모가 작고 간단한 일을 수행할 때 사용합니다.

실습 예제(CodeInjection.exe)

CodeInjection.exe

실습 예제는 notepad.exe 프로세스에 간단한 코드를 인젝션 시켜서 메시지 박스를 출력하는 내용입니다.

* 참고!

CodeInjection.exe 는 Visual C++ 2008 Express Edition 으로 개발되었으며 Windows 7 32bit 환경에서 테스트 되었습니다.

#1. notepad.exe 실행

notepad.exe 를 실행 시킨 후 Process Explorer 를 이용하여 notepad.exe 프로세스의 PID 를 확인합니다.

<Fig. 5>

제 테스트 환경에서 notepad.exe 의 PID 는 1896 입니다.

#2. CodeInjection.exe 실행

첨부된 CodeInjection.exe 파일을 실행시킵니다. 이때 실행 파라미터로 앞에서 구한 notepad.exe 의 PID 값을 입력합니다.

<Fig. 6>

#3. 메시지 박스 확인

<Fig. 7>

메시지 박스가 notepad.exe 윈도우의 밑에 깔려 있으므로 확인 하실 때 주의하시기 바랍니다.

다음 강좌에서 실습 예제의 소스 코드를 보면서 어떻게 구현되었는지 자세히 확인해 보도록 하겠습니다.

☞ Code Injection 기법 (2)

ReverseCore

위 글이 도움이 되셨다면 추천(VIEW ON) 부탁 드려요~

Advanced Global API Hooking – IE 접속 제어 (4)

reversecore — Mon, 17 May 2010 01:29:58 +0900

Global API Hooking 예제 코드를 분석하면서 해당 기술에 대한 이해를 돕습니다.

본 내용을 읽기 전에 이전 포스트를 참고하세요. 같이 이어지는 내용입니다.

☞ Advanced Global API Hooking – IE 접속 제어 (1)

☞ Advanced Global API Hooking – IE 접속 제어 (2)

☞ Advanced Global API Hooking – IE 접속 제어 (3)

* 참고!

모든 소스 코드는 MS Visual C++ 2008 Express Edition 으로 개발 되었으며, Windows 7 32bit & IE 8 에서 테스트 되었습니다.

전체 소스 코드는 아래 첨부된 파일을 참고하시기 바랍니다.

redirect.cpp

주요 함수에 대해 설명 드리겠습니다. 설명의 편의를 위해서 에러 처리 관련 코드는 제거하였습니다. 에러 처리 코드가 포함된 원본 함수의 전체 코드는 첨부된 파일에서 확인하시기 바랍니다.

DllMain()

먼저 DllMain() 함수를 살펴보겠습니다.

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)

{

char szCurProc[MAX_PATH] = {0,};

char *p = NULL;

switch( fdwReason )

{

case DLL_PROCESS_ATTACH :

GetModuleFileName(NULL, szCurProc, MAX_PATH);

p = strrchr(szCurProc, '\\');

if( (p != NULL) && !_stricmp(p+1, "iexplore.exe") )

{

// wininet!InternetConnectW() API 를 후킹 하기 전에

// 미리 wininet.dll 을 로딩 시킴

LoadLibrary("wininet.dll");

}

// hook

hook_by_code("ntdll.dll", "ZwResumeThread",

(PROC)NewZwResumeThread, g_pZWRT);

hook_by_code("wininet.dll", "InternetConnectW",

(PROC)NewInternetConnectW, g_pICW);

break;

case DLL_PROCESS_DETACH :

// unhook

unhook_by_code("ntdll.dll", "ZwResumeThread",

g_pZWRT);

unhook_by_code("wininet.dll", "InternetConnectW",

g_pICW);

break;

}

return TRUE;

}

DllMain() 함수의 핵심 기능은 ntdll!ZwResumeThread() 와 wininet!InternetConnectW() API 의 hook/unhook 입니다.

한가지 특이한 코드는 실행 프로세스 이름이 iexplorer.exe 인 경우 wininet.dll 을 로딩 시키는 코드입니다. iexplore.exe 프로세스가 정상적으로 실행되면 기본적으로 wininet.dll 을 로딩하고 있는데 왜 굳이 추가적으로 로딩을 시키는 걸까요? 그 이유는 Global API Hooking 때문입니다.

ntdll!ZwResumeThread() 를 이용한 API 후킹은 해당 프로세스의 메인 스레드가 시작되기 전에 제

어를 가로채기 때문에 우리가 후킹하려는 wininet.dll 모듈이 아직 로딩되어 있지 않는 상황이 발생할 수 있습니다. 이를 방지 하기 위해서 iexplore.exe 프로세스인 경우 wininet!InternetConnectW() API 를 후킹하기 전에 무조건 wininet.dll 을 로딩시키는 것입니다.

NewInternetConnectW()

wininet!InternetConnectW() 의 후킹 함수인 NewInternetConnectW() 함수에 대한 설명입니다. 이 함수는 IE 의 접속 주소를 모니터링 하면서 특정 사이트에 접속을 시도할 때 원하는 사이트로 접속을 돌리는 역할을 수행합니다.

HINTERNET WINAPI NewInternetConnectW

(

HINTERNET hInternet,

LPCWSTR lpszServerName,

INTERNET_PORT nServerPort,

LPCTSTR lpszUsername,

LPCTSTR lpszPassword,

DWORD dwService,

DWORD dwFlags,

DWORD_PTR dwContext

)

{

HINTERNET hInt = NULL;

FARPROC pFunc = NULL;

HMODULE hMod = NULL;

// unhook

unhook_by_code("wininet.dll", "InternetConnectW", g_pICW);

// call original API

hMod = GetModuleHandle("wininet.dll");

pFunc = GetProcAddress(hMod, "InternetConnectW");

if( !_wcsicmp(lpszServerName, L"www.naver.com") ||

!_wcsicmp(lpszServerName, L"www.daum.net") ||

!_wcsicmp(lpszServerName, L"www.nate.com") ||

!_wcsicmp(lpszServerName, L"www.yahoo.com") )

{

hInt = ((PFINTERNETCONNECTW)pFunc)(hInternet,

L"www.reversecore.com",

nServerPort,

lpszUsername,

lpszPassword,

dwService,

dwFlags,

dwContext);

}

else

{

hInt = ((PFINTERNETCONNECTW)pFunc)(hInternet,

lpszServerName,

nServerPort,

lpszUsername,

lpszPassword,

dwService,

dwFlags,

dwContext);

}

// hook

!hook_by_code("wininet.dll", "InternetConnectW",

(PROC)NewInternetConnectW, g_pICW;

return hInt;

}

위 함수의 코드는 매우 단순합니다. 함수의 2 번째 파라미터인 lpszServerName 문자열이 바로 접속 주소입니다. 이 접속주소를 모니터링 하여 우리나라 4 대 포탈 사이트(Naver, Daum, Nate, Yahoo)인 경우, 제 블로그(ReverseCore)로 연결을 바꿔버립니다.

hook_by_code() / unhook_by_code() 에 대한 설명은 아래 포스트를 참고하시기 바랍니다.

☞ API Hooking – ‘스텔스’ 프로세스 (3)

NewZwResumeThread()

ntdll!ZwResumeThread() 의 후킹 함수인 NewZwResumeThread() 함수입니다.

NTSTATUS WINAPI NewZwResumeThread(HANDLE ThreadHandle, PULONG SuspendCount)

{

NTSTATUS status, statusThread;

FARPROC pFunc = NULL, pFuncThread = NULL;

DWORD dwPID = 0;

static DWORD dwPrevPID = 0;

THREAD_BASIC_INFORMATION tbi;

HMODULE hMod = NULL;

char szModPath[MAX_PATH] = {0,};

// call ntdll!ZwQueryInformationThread()

hMod = GetModuleHandle("ntdll.dll");

pFuncThread = GetProcAddress(hMod, "ZwQueryInformationThread");

statusThread = ((PFZWQUERYINFORMATIONTHREAD)pFuncThread)

(ThreadHandle, 0, &tbi, sizeof(tbi), NULL);

// Dll Injection to the new child process

dwPID = (DWORD)tbi.ClientId.UniqueProcess;

if ( (dwPID != GetCurrentProcessId()) && (dwPID != dwPrevPID) )

{

dwPrevPID = dwPID;

// change privilege

SetPrivilege(SE_DEBUG_NAME, TRUE);

// get injection dll path

GetModuleFileName(GetModuleHandle(STR_MODULE_NAME),

szModPath,

MAX_PATH);

// call InjectDll()

InjectDll(dwPID, szModPath);

}

// unhook

unhook_by_code("ntdll.dll", "ZwResumeThread", g_pZWRT);

// call ntdll!ZwResumeThread()

pFunc = GetProcAddress(hMod, "ZwResumeThread");

status = ((PFZWRESUMETHREAD)pFunc)(ThreadHandle, SuspendCount);

// hook

hook_by_code("ntdll.dll", "ZwResumeThread",

(PROC)NewZwResumeThread, g_pZWRT);

return status;

}

NewResumeThread() 함수의 첫 번째 파라미터는 resume 시킬 스레드의 ThreadHandle 입니다. 지난번 설명에서 이 스레드는 바로 자식 프로세스의 메인 스레드라고 설명 드렸습니다.

☞ 참고 : Advanced Global API Hooking – IE 접속 제어 (3)

따라서 NewResumeThread() 함수 초반부의 ZwQueryInformationThread() API 를 호출하는 이유는 바로 ThreadHandle 이 가리키는 스레드(자식 프로세스의 스레드) 가 소속된 자식 프로세스의 PID 를 얻기 위함입니다.

이렇게 ThreadHandle 파라미터를 이용하여 (지금 막 생성된) 자식 프로세스의 PID 를 얻어 내었습니다. 이 PID 를 이용하여 redirect.dll (후킹 DLL) 을 인젝션 시켜 줍니다. 해당 자식 프로세스는 메인 스레드가 실행되기도 전에 이미 redirect.dll 이 인젝션 되면서 자동으로 API 후킹이 걸리게 됩니다.

마지막으로 ntdll!ZwResumeThread() API 를 정상적으로 호출하여 자식 프로세스의 메인 스레드를 resume 시킵니다. 이제 자식 프로세스는 API 가 후킹된 채로 정상 실행됩니다.

High-Level API Hooking vs Low-Level API Hooking

위의 ntdll!ZwResumeThread() API 후킹 방법은 단순히 kernel32!CreateProcess() API 를 후킹하는 것보다 더 강력하고 편리한 방법입니다. 왜냐하면 CreateProcess() 는 내부적으로 CreateProcessInternal() 을 호출합니다. 만약 프로그램에서 CreateProcessInternal() 을 직접 호출한다면 정상적인 후킹이 되지 않습니다. (차라리 CreateProcessInternal() 을 후킹하는 것이 더 좋은 방법입니다. – 좋은 방법을 가르쳐 주신 iwillhackyou 님께 감사드립니다.)

이런 식으로 Low-Level API (ntdll.dll 에서 제공되는 API) 를 후킹할수록 더 강력합니다. 하지만 대부분의 Low-Level API 들은 undocumented 되어 있으며, OS 버전에 따라 변경될 가능성이 존재합니다. 반면에 High-Level API (kernel32.dll 레벨 - documented) 들은 변경될 가능성이 없고 잘 문서화 되어 있기 때문에 안정적인 후킹이 가능합니다. 대신에 후킹 성능이 좀 떨어집니다.

따라서 High-Level API 후킹과 Low-Level API 후킹은 서로 일장 일단이 있기 때문에 상황에 맞게 적절히 선택하여 구현하시는 것이 현명한 방법입니다.

+---+

다음 강좌는 Code Injection 을 통한 API 후킹에 대한 내용입니다. 지금까지는 DLL 을 인젝션 시켜서 API 후킹을 진행하였지만, 짤막한 코드를 삽입시켜 동일한 기능을 구현하는 것입니다. DLL Injection 방법과 많은 차이점이 있으며, 이 또한 흥미로운 주제가 될 것입니다.

ReverseCore

위 글이 도움이 되셨다면 추천(VIEW ON) 부탁 드려요~

Advanced Global API Hooking – IE 접속 제어 (3)

reversecore — Fri, 07 May 2010 00:26:16 +0900

Global API Hooking 예제를 실습하겠습니다.

본 내용을 읽기 전에 이전 포스트를 참고하세요. 같이 이어지는 내용입니다.

☞ Advanced Global API Hooking – IE 접속 제어 (1)

☞ Advanced Global API Hooking – IE 접속 제어 (2)

* 참고!

모든 소스 코드는 MS Visual C++ 2008 Express Edition 으로 개발 되었으며, Windows 7 32bit & IE 8 에서 테스트 되었습니다.

실습 예제 – IE 접속 제어

redirect.dll

InjDll.exe

# 실습 내용

IE 프로세스의 특정 API 를 후킹 하여 국내 4 대 포탈 사이트(Naver, Daum, Nate, Yahoo)에 접속 시도할 때 www.reversecore.com 주소로 연결 시켜버립니다. 또한 IE 의 탭이 새로 생성되면서 동시에 프로세스가 추가되는 경우를 대비해서 Global API Hooking 기법을 사용하였습니다.

API 후킹은 redirect.dll 을 인젝션 시켜서 구현합니다. redirect.dll 은 아래 2 개의 API 를 후킹합니다.

wininet!InternetConnectW() - IE 프로세스의 접속 주소를 제어하기 위해 후킹

ntdll!ZwResumeThread() – Global API Hooking 구현을 위해 후킹

* Global API Hooking 에 대한 자세한 설명은 아래 글을 참고하세요.

☞ Advanced Global API Hooking – IE 접속 제어 (2)

#1. IE 실행

실습을 위해서 먼저 IE 를 실행시켜 주시기 바랍니다. 그리고 Process Explorer 를 이용하여 현재 실행중인 IE 프로세스의 구조를 살펴 보겠습니다.

<Fig. 1>

위 그림을 보시면 IE 프로세스는 부모-자식 관계로 실행되는 것을 알 수 있습니다. 부모 프로세스만 ntdll!ZwResumeThread() API 를 후킹해도 이후부터 생성되는 모든 IE 프로세스들은 자동으로 후킹됩니다.

#2. DLL Injection

redirect.dll 파일을 IE 프로세스(iexplore.exe) 에 인젝션 시킵니다.

<Fig. 2>

Process Explorer 를 이용해서 IE 프로세스에 redirect.dll 파일이 정상적으로 인젝션 되었는지 확인합니다.

<Fig. 3 >

#3. 새로운 탭 생성

IE 에서 새로운 탭을 생성합니다.

<Fig. 4>

Process Explorer 를 이용해서 새로 생긴 탭과 연결된 프로세스(PID:3136)에 redirect.dll 이 제대로 인젝션 되었는지 확인합니다.

<Fig. 5>

ntdll!ZwResumeThread() API 후킹을 통한 Global API Hooking 이 성공하였습니다.

#4. 포탈 사이트 접속

IE 의 아무 탭에서 국내 4 대 포탈 사이트에 접속을 시도해 보세요.

www.naver.com

www.daum.net

www.nate.com

www.yahoo.com

<Fig. 6>

위 그림에서처럼 주소는 naver 지만 실제로는 ReverseCore 사이트가 연결되었습니다.

#5. DLL Ejection

IE 프로세스에서 redirect.dll 을 내려보겠습니다.

<Fig. 7>

Process Explorer 를 이용하여 redirect.dll 가 정상적으로 ejection 되었는지 확인합니다.

<Fig. 8>

이제 다시 naver 에 접속해보면 이제는 정상적으로 접속하는 것을 확인하실 수 있습니다.

<Fig. 9>

#6. 추가 실습

위에 소개된 InjDll.exe 와 redirect.dll 파일을 이용해서 각자 좀 더 실습을 많이 해보시기 바랍니다. Global API Hooking 기법에 대한 개념을 확실히 이해하실 수 있으실 것입니다.

- 전체 프로세스 후킹

- explorer.exe 만 후킹 (이후 IE 실행)

+---+

실습 내용이 길어진 관계로 redirect.dll 파일의 소스 코드 설명은 다음 강좌에 하겠습니다. (조금 빨리 올리겠습니다.)

☞ Advanced Global API Hooking – IE 접속 제어 (4)

ReverseCore

위 글이 도움이 되셨다면 추천(VIEW ON) 부탁 드려요~

Advanced Global API Hooking – IE 접속 제어 (2)

reversecore — Sun, 25 Apr 2010 23:40:59 +0900

Global API Hooking 에 대한 기본 개념을 정리합니다. 또한 ntdll!ZwResumeThread() API 의 후킹을 통한 Global API Hooking 기법의 원리를 살펴봅니다.

본 내용을 읽기 전에 이전 포스트를 참고하세요. 같이 이어지는 내용입니다.

☞ Advanced Global API Hooking – IE 접속 제어 (1)

* 참고!

모든 소스 코드는 MS Visual C++ 2008 Express Edition 으로 개발 되었으며, Windows 7 32bit & IE 8 에서 테스트 되었습니다.

Global API Hooking

Global API Hooking 에 대해서 다시 한번 간단히 정리하고 넘어가겠습니다.

지금까지의 강좌를 통해서 우리는 특정 프로세스에 대해 원하는 API 의 후킹을 간단하게 구현할 수 있게 되었습니다.

* 참고

☞ API Hooking – 계산기, 한글을 배우다 (1)

☞ API Hooking – ‘스텔스’ 프로세스 (1)

#1. 일반적인 API Hooking

일반적인 API 후킹의 문제는 후킹을 원하는 프로세스가 생성될 때마다 매번 API 후킹을 해줘야 한다는 것입니다. 아래 그림은 DLL Injection 기법을 이용한 일반적인 API Hooking 을 표현한 것입니다.

<Fig. 1>

위 그림에서 후킹 대상 프로세스는 Test.exe(PID:2492) 입니다. InjDll.exe 프로그램을 이용해서 Hook.dll 을 Test.exe 프로세스에 인젝션 시켜서 원하는 API 를 후킹 하였습니다. (1)

그런데 이후에 또 다른 Test.exe(PID:3796) 프로세스가 생성되었다면 이 프로세스에도 역시 Hook.dll 을 인젝션 시켜줘야 (PID:3796 프로세스에 대한) 정상적인 API 후킹이 이루어 질 것입니다. (2)

즉, 후킹 대상 프로세스가 새로 생성 될 때마다 계속해서 수동으로 API 후킹을 시켜야 합니다.

#2. Global API Hooking

이번에는 Global API Hooking 을 살펴보도록 하겠습니다.

<Fig. 2>

InjDll.exe 는 Windows 운영체제의 기본 쉘(Shell) 인 Explorer.exe 프로세스에 gHook.dll 을 인젝션 시킵니다. (후킹하고자 하는 Test.exe 가 아닌, Test.exe 를 실행시켜주는 프로세스인 Explorer.exe 를 후킹한다는 것이 핵심입니다.)

gHook.dll 은 <Fig. 1> 의 Hook.dll 의 기능에다가 자식 프로세스 생성에 관련된 API 를 후킹하여 자식 프로세스를 생성할 때마다 자신(gHook.dll)을 인젝션 시키는 기능을 가지고 있습니다. (위 <Fig. 2> 참조)

따라서 Windows 쉘인 Explorer.exe 프로세스에 gHook.dll 을 한번 인젝션 시켜놓으면 그 이후 Explorer.exe 에서 생성되는 모든 자식 프로세스들에게 자동으로 gHook.dll 이 인젝션 됩니다.

이것이 자동 API Hooking 의 기본 개념이며, 이를 시스템에 실행중인 모든 프로세스를 대상으로 확장한 것이 바로 Global API Hooking 입니다.

* 참고!

Explorer.exe 외에 다른 프로세스들도 자식 프로세스를 생성할 수 있습니다. 따라서 원칙적으로 Global API Hooking 을 완벽히 구현하려면 현재 실행중인 모든 프로세스들을 후킹 해야 합니다.

하지만 시스템 안정성과 불필요한 오버헤드를 막기 위해 작업 내용에 따라서 특정 프로세스만 후킹 하는 경우도 있습니다. (제가 실습 예제로 준비한 IE 후킹이 대표적인 경우입니다.)

이상으로 Global API Hooking 개념에 대해서 정리해 보았습니다.

이제부터 어떤 API 를 후킹해야 Global API Hooking 을 쉽게 구현할 수 있는지 알아보도록 하겠습니다.

ntdll!ZeResumeThread() API

자식 프로세스를 생성하는 API 에 대해서 생각해 보도록 하겠습니다.

프로세스를 생성하는 API 는 단연 kernel32!CreateProcess() API 가 대표적입니다.

* 참고 – kernel32!CreateProcess() API 를 이용한 Global API Hooking 방법

☞ API Hooking – ‘스텔스’ 프로세스 (4)

CreateProcess() API 의 디버깅을 위하여 다음과 같이 간단한 프로그램을 만들어 보겠습니다.

// cptest.cpp

#include "windows.h"

#include "tchar.h"

void main()

{

STARTUPINFO si = {0,};

PROCESS_INFORMATION pi = {0,};

TCHAR szCmd[MAX_PATH] = {0,};

si.cb = sizeof(STARTUPINFO);

_tcscpy(szCmd, L"notepad.exe");

if( !CreateProcess(NULL, // lpApplicationName

szCmd, // lpCommandLine

NULL, // lpProcessAttributes

NULL, // lpThreadAttributes

FALSE, // bInheritHandles

NORMAL_PRIORITY_CLASS, // dwCreationFlags

NULL, // lpEnvironment

NULL, // lpCurrentDirectory

&si, // lpStartupInfo

&pi) ) // lpProcessInformation

return;

if( pi.hProcess != NULL )

CloseHandle(pi.hProcess);

}

위 코드로 빌드 시킨 프로그램입니다.

cptest.exe

cptest.exe 를 디버깅 해보면 프로세스 생성과 관련된 API 들의 호출 흐름을 알 수 있습니다.

아래 그림은 cptest.exe 의 kernel32!CreateProcessW() 호출 코드입니다.

* 참고 : CreateProcessW 는 CreateProcess 의 Wide Character (유니코드)버전입니다.

<Fig. 3>

kernel32!CreateProcessW() 내부로 따라 들어가면 아래 그림과 같이 kernel32!CreateProcessInternalW() 호출 코드를 볼 수 있습니다.

<Fig. 4>

위 그림에서 아래쪽의 스택 메모리를 보시면 <Fig. 3> 의 스택(함수 파라미터)이 거의 동일하게 넘어온걸 알 수 있습니다.

kernel32!CreateProcessInternalW() 내부로 들어가 보겠습니다.

<Fig. 5>

kernel32!CreateProcessInternalW() 는 상당히 큰 함수입니다. 아래로 쭉 스크롤을 내리면 아래 그림과 같이 ntdll!ZwCreateProcess() 를 호출하는 코드가 나타납니다.

<Fig. 6>

위 그림에서 아래쪽의 스택을 보시면 <Fig. 4> 에서의 스택과는 많이 다른 형태인 것을 알 수 있습니다. 2번째 파라미터(Arg2)는 어떤 구조체 인데 왼쪽의 Hex dump 창을 보시면 구조체 멤버 중에 12F950 주소의 12FD38(“notepad”) 문자열 주소를 확인 하실 수 있습니다. (<Fig. 3> 스택 참조)

Ntdll!ZwCreateUserProcess() 가 호출되면 자식 프로세스가 SUSPEND 모드로 실행됩니다.

<Fig. 7>

notepad.exe 프로세스는 생성되었지만 아직 EP 코드가 실행되지 않은 상태입니다.

<Fig. 6> 코드에서 계속 아래로 진행하면 ntdll!ZwResumeThread() API 호출 코드가 나타납니다.

<Fig. 8>

ntdll!ZwResumeThread() 는 함수 이름 그대로 스레드를 RESUME 시켜줍니다. 이 스레드가 바로 자식 프로세스(notepad.exe) 의 메인 스레드입니다. 따라서 이 API 가 호출되면 비로소 자식 프로세스의 EP 코드가 실행됩니다.

<Fig. 9>

지금까지의 API 호출 흐름을 정리하면 아래와 같습니다.

kernel32!CreateProcessW

kernel32!CreateProcessInternalW

ntdll!ZwCreateUserProcess // 프로세스 생성됨 (메인 스레드는 suspend 상태)

ntdll!ZwResumeThread // 메인 스레드 resume 시킴 (프로세스 실행됨)

자식 프로세스 생성에 있어서 가장 마지막에 호출되는 API 가 바로 ntdll!ZwResumeThread() 입니다. 따라서 우리는 이 API 를 후킹함으로써 자식 프로세스의 EP 코드가 실행되기 직전에 제어를 가로챈 후 원하는 API 를 후킹시킬 수 있습니다.

ntdll!ZwResumeThread() 는 undocumented API 이며, 함수 정의는 아래와 같습니다.

NTSTATUS NtResumeThread(

IN HANDLE ThreadHandle,

OUT PULONG SuspendCount OPTIONAL

);

* 출처

http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/NT%20Objects/Thread/NtResumeThread.html

* 참고

User Mode 에서 ntdll!ZwResumeThread() API 와 ntdll!NtResumeThread() API 는 동일합니다.

위에서 소개한 4 개의 API (CreateProcessW, CreateProcessInternalW, ZwCreateUserProcess, ZwResumeThread) 중에서 어떤걸 후킹해도 Global API Hooking 이 가능합니다.

다만 상위에 위치한 CreateProcessW() 함수를 후킹하면 특정 경우(CreateProcessInternalW 를 직접 호출하는 경우)에 후킹이 되지 않을 수 있습니다. 따라서 CreateProcessInternalW() 이하를 후킹하는 것이 더 좋은 방법입니다. (각자 장단점이 있을 수 있으므로 모두 연습해 두시는 것이 좋을 것 같습니다.)

다음 시간에는 Global 후킹 실습을 한 후 실제 코드를 살펴보도록 하겠습니다.

☞ Advanced Global API Hooking – IE 접속 제어 (3)

ReverseCore

위 글이 도움이 되셨다면 추천(VIEW ON) 부탁 드려요~

Advanced Global API Hooking – IE 접속 제어 (1)

reversecore — Mon, 29 Mar 2010 20:38:13 +0900

좀 더 고급스러운 Global API Hooking 방법에 대해서 알아보겠습니다.

실습 예제로는 IE(Internet Explorer) 를 후킹하여 특정 사이트로 향하는 접속을 우회시켜 제 블로그로 접속하도록 만들겠습니다.

본 내용은 지난 번에 설명한 Global API Hooking 강좌에 추가되는 내용입니다.

Global API Hooking 의 개념에 대해서는 아래 강좌를 참고하여 주시기 바랍니다.

☞ 참고 : API Hooking – Stealth 프로세스 (2)

☞ 참고 : API Hooking – Stealth 프로세스 (4)

* 참고!

모든 소스 코드는 MS Visual C++ 2008 Express Edition 으로 개발 되었으며, Windows 7 x86 & IE 8 에서 테스트 되었습니다.

실습 예제

실습 목표는 IE 프로세스의 API 를 후킹하여 특정 사이트로 향하는 접속을 다른 사이트로 우회시키는 것입니다. 주소 창에 직접 입력을 하던, 링크를 클릭하던 제가 막아놓은 사이트에는 접속하지 못하도록 만드는 것입니다. (유해 사이트 차단 기능을 생각 하시면 이해하시기 쉬울 것입니다.)

* 참고!

유해 사이트 차단 기능 자체로 보면 사실 방화벽 차원에서 지원해주는 것이 훨씬 효과적입니다. 어디까지나 실습을 위한 예제이므로 실제 제품에 위 기능을 염두에 두신다면 이점을 고려하시기 바랍니다.

wininet!InternetConnect()

API Hooking 에서 가장 핵심적인 사항은 바로 후킹 대상 API 를 선정하는 것입니다.

이 부분은 사실 개개인의 노하우가 필요한 부분입니다. 개발 경험 혹은 API 후킹 경험이 많을수록 유리합니다. (요즘은 구글링으로 대부분 해결이 가능하지요.)

작업 전에 간단히 예상을 해보자면 소켓 라이브러리(ws2_32.dll) 혹은 MS 에서 제공하는 인터넷 관련 라이브러리(wininet.dll, winhttp.dll) 들을 후킹 하면 될 것 같습니다. (후자 쪽이 훨씬 수월한 작업이 되겠지요.)

IE 를 실행 시켜서 간단히 분석해 보도록 하겠습니다.

먼저 Process Explorer 를 이용하여 로딩된 DLL 들을 살펴보도록 하겠습니다.

<Fig. 1>

다행히 IE 에서는 ws2_32.dll 뿐만 아니라 Wininet.dll 도 같이 로딩하고 있습니다.

Wininet.dll 에서 제공하는 API 중에 InternetConnect() 라는 API 가 있습니다. 함수 이름 그대로 어떤 웹사이트에 접속하려고 할 때 사용하는 API 입니다.

HINTERNET InternetConnect(

__in HINTERNET hInternet,

__in LPCTSTR lpszServerName, // 접속 URL

__in INTERNET_PORT nServerPort,

__in LPCTSTR lpszUsername,

__in LPCTSTR lpszPassword,

__in DWORD dwService,

__in DWORD dwFlags,

__in DWORD_PTR dwContext

);

* 출처 : http://msdn.microsoft.com/en-us/library/aa384363(VS.85).aspx

OllyDbg 를 IE 프로세스(PID : 3484 = D9Ch)에 attach 시킨 후 wininet!InternetConnectW() API 에 BP 를 설치하겠습니다. (InternetConnectW() API 는 InternetConnect() 의 Wide Character 버전입니다.)

<Fig. 2>

이 상태에서 IE 주소 창에 접속하려는 사이트의 주소를 입력해 보겠습니다.

<Fig. 3>

위에서 설치한 BP 에 걸렸습니다. 이 때 프로세스의 스택 메모리를 살펴보겠습니다.

<Fig. 4>

스택의 정보를 보면 접속 주소(lpszServerName)는 www.google.com 이라는 것을 알 수 있습니다.

시험 삼아 이 주소를 한번 조작해 볼까요?

<Fig. 5>

위 그림과 같이 "www.google.com" 문자열을 "www.reversecore.com" 문자열로 변경합니다.

* 주의!

위 주소들은 모두 UNICODE 문자열이므로 마지막에 2 byte NULL (0000) 로 끝나야 합니다. (HEX 창에서 문자열 끝에 00 00 을 입력하시면 됩니다.)

위와 같이 접속 주소를 수정한 후 디버거를 실행 시킵니다. 아마 wininet!InternetConnectW() 에 설치된 BP 에서 계속 멈출 것입니다. 이는 보통 하나의 웹사이트가 여러 개의 링크 주소로 이루어져 있기 때문입니다. BP 를 제거 후 계속 실행 해 주세요. (스택 조작은 최초 InternetConnectW() 호출에서 한번만 하시면 됩니다.)

결과적으로 IE 는 아래 그림과 같이 (원래 의도했던) www.google.com 이 아닌 (변경된) www.reversecore.com 주소로 접속하게 됩니다.

<Fig. 6>

따라서 wininet!InternetConnectW() 를 후킹 한 후 lpszServerName 파라미터를 조작하면 IE 접속을 제어할 수 있게 됩니다.

원리는 매우 간단하지요. 다행히 IE 에서 wininet.dll 를 사용하기 때문에 쉽게 API 후킹할 수 있었습니다. 여기까지는 일반적인 API Hooking 방법과 동일합니다.

하지만 실제 구현에 있어서 한가지 중요한 고려사항이 있습니다.

바로 IE 8 의 독특한 프로세스 구조 때문에 Global API Hooking 기법을 써야 한다는 것입니다.

IE 프로세스 구조

IE 를 새롭게 실행 한 후 탭(tab) 을 여러 개 띄워서 각각 다른 사이트에 접속해 보겠습니다.

<Fig. 7>

Process Explorer 를 이용하여 IE 프로세스 구조를 살펴보겠습니다.

<Fig. 8>

위 <Fig. 7> 과 <Fig. 8> 을 보시면 IE 에 7 개의 탭이 띄워져 있고, IE 프로세스(iexplore.exe)는 총 5 개 실행되고 있습니다. 그리고 iexplore.exe 프로세스(PID:3784)는 나머지 iexplore.exe 프로세스들과 부모-자식 관계를 형성하고 있습니다.

IE 프로세스 구조를 봤을 때 IE 어플리케이션은 부모에 해당되는 메인 프로세스(PID:3784)가 각 탭들에 해당되는 자식 프로세스들을 관리하는 구조라고 볼 수 있습니다.

IE 7 부터 탭 개념을 도입하면서 위와 같은 프로세스 구조로 변경되었는데요, 이 방식의 장점은 탭 별로 독립적인 프로세스로 동작하기 때문에 하나의 탭 에서 오류가 발생하더라도 나머지 탭들과 부모 프로세스(IE 본체)에게는 영향을 끼치지 않는다는 것입니다. (최신 웹 브라우저들에서 사용되는 방법입니다.)

이와 같이 IE 프로그램은 각 탭에 해당하는 자식 iexplore.exe 프로세스가 실제 접속을 담당하므로 탭 프로세스가 생성되는 순간에 (해당 프로세스의) API 를 자동으로 후킹할 수 있어야 합니다. 즉, Global API Hooking 방법으로 구현되어야 한다는 뜻입니다. 그렇지 않다면 새로운 탭으로 접속하는 경우에는 후킹이 되지 않을 것이기 때문이지요.

지난 번에 Global API Hooking 을 구현하기 위하여 kernel32!CreateProcess() API 를 후킹하는 방법에 대해서 소개하였습니다. 하지만 CreateProcess() API 를 후킹하는 방법에는 약간의 제한 사항이 있다는 것도 같이 설명 드렸습니다.

☞ 참고 : API Hooking – Stealth 프로세스 (4)

이번 포스트의 목적은 CreateProcess() API 의 후킹을 통한 Global API Hooking 방법의 불편함을 없애고 좀 더 안정적이고 편리한 방법으로 Global API Hooking 을 구현하는데 있습니다.

그 방법이란 바로 ntdll!ZwResumeThread() API 를 후킹하여 프로세스가 생성된 후 메인 스레드가 resume 될 때 원하는 API 를 후킹하는 방법입니다.

글이 길어진 관계로 다음 시간에 ntdll!ZwResumeThread() API 의 후킹을 통한 Global API Hooking 방법에 대해 자세히 설명하도록 하겠습니다.

☞ Advanced Global API Hooking – IE 접속 제어 (2)

ReverseCore

위 글이 도움이 되셨다면 추천(VIEW ON) 부탁 드려요~

InjDll.exe – DLL Injection/Ejection 전용 도구

reversecore — Mon, 15 Mar 2010 00:23:57 +0900

제가 개발한 InjDll.exe 프로그램을 소개합니다.

이 프로그램을 이용해서 원하는 DLL 을 대상 프로세스에 Injection/Ejection 시킬 수 있습니다.

DLL Injection 에 관련된 설명을 아래 링크를 참조하세요.

☞ DLL Injection – 다른 프로세스에 침투하기 (1)

☞ DLL Injection in Windows 7

InjDll.exe (Ver 1.0.0)

제 블로그 study 에서 자주 소개되는 프로그램입니다.

소스를 조금 다듬고 기능을 추가시켜서 정식 버전(1.0.0)으로 배포합니다.

InjDll.exe

이 프로그램은 공개용이며, 자유롭게 사용하실 수 있습니다.

* 주의!

기본적으로 Windows 2000 이상만 지원합니다. (Windows 7, XP 에서 테스트 되었습니다.)

Windows 9X 계열에서는 사용하실 수 없습니다.

사용방법은 아래와 같습니다.

InjDll.exe <procname|pid|*> <-i|-e> <dll path>

<procname|pid|*>
procname Process name (ex: explorer.exe, notepad.exe, etc)
pid Process ID

<-i|-e>
-i Injection Mode

-e Ejection Mode

<dll path> DLL File Path (relative or full)

사용 예

dummy.dll

- PID 2840 프로세스에게 dummy.dll 파일을 Injection 시킬 때

- IE 프로세스에게 dummy.dll 파일을 Injection 시킬 때

- 모든 프로세스에게 dummy.dll 파일을 Injection 시킬 때

Ejection 은 –i 대신 –e 를 사용하면 됩니다.

InjDll.exe (Ver 1.1.1)

InjDll.exe 가 버전업 되었습니다. (2010.10.29)

추가/변경 사항

1. 64bit 지원

InjDll64.exe 를 이용하여 64bit 프로세스에 64bit DLL 파일을 인젝션 시킬 수 있습니다.

* 64bit 프로세스에 DLL Injection 을 하기 위해서는 Injector(InjDll64.exe) & DLL 파일이 모두 64bit(PE32+) 이어야 합니다.

2. <dll path> 의 "상대 경로" 지원

아래와 같이 Dll 파일 위치를 상대 경로로 입력할 수 있습니다.

InjDll32.exe notepad.exe -i dummy32.dll
InjDll32.exe calc.exe -i ..\hook.dll
...

주의사항

1) 원격 스레드를 실행시켜 LoadLibrary() 를 호출하는 방식이므로 대상 프로세스에 kernel32.dll 이 로딩되어 있지 않다면 Injection/Ejection 작업은 실패합니다.

2) 접근 권한이 제한된 (보호받는) 프로세스나 Anti-Injection 기법이 적용된 프로세스 들에게도 역시 Injection/Ejection 작업은 실패합니다.

3) 원칙적으로 Injection 을 N 번 시켰을 때 Ejection 도 같은 횟수로 호출해 줘야 해당 DLL 이 제대로 unloading 됩니다.

Bugs

사용하시다가 버그가 발견된다면 댓글로 알려주시면 감사하겠습니다.

ReverseCore

위 글이 도움이 되셨다면 추천(VIEW ON) 부탁 드려요~