리버스 엔지니어링 바이블, 오탈자나 기타 문의
리버스 엔지니어링 바이블, 오탈자나 기타 문의에 대해서는 아래 공지를 참조하시면 됩니다. 앞으로는 오른쪽 상단 공지에 띄워놓겠습니다.
http://window31.com/notice/410
리버스 엔지니어링 바이블, 오탈자나 기타 문의에 대해서는 아래 공지를 참조하시면 됩니다. 앞으로는 오른쪽 상단 공지에 띄워놓겠습니다.
http://window31.com/notice/410
1. 공격대상은 거의다 패킹된 바이너리이며 보안 코드 작성시 그 상태에서는 IAT 를
쉽게 구할 수 없다. 따라서 검사하지 않을 것이다.
2. 하지만 해킹툴을 만드는 입장에선 까짓거 노가다로 찾아서 하드코딩 해버리면 된다.
(대부분이 이런 넘들임. 클라이언트가 패치하여 번지가 바뀌면 후킹하지 못함)
3. 보안 솔루션이 IAT 를 구하더라도 패커가 내부적으로 리다이렉트 시키는건지
해킹툴이 훅을 하는건지 패커의 내부구조를 상당수 파악하기 전까진 분간하기 힘들다.
4. 훅을 해도 system dll 들의 메모리 CRC가 변경되지 않는다.
서적 출간 소식입니다.
국내에서도 리버싱을 full 로 다룬 첫 서적이 나올 것 같네요 ^^
http://simples.co.kr/ 에서 esniper 님께서 리버싱관련 서적을 다음달 초에 내신다고 합니다.
아래는 목차고요. 목차에 대해 어느 보안 포럼에서는 이렇다 저렇다 논란 이 있긴 하지만
아직 알맹이도 보지 못한 상황에서 내용에 대해 왈가불가 하는 것 보다 리버싱 전문 서적의
첫 출간이라는 것에 더 큰 의의를 두어야 하지 않을까 싶네요.
(목차를 보며 그나마 할 수 있는 얘기는 코드 한줄한줄에 대한 Tracing 보다는
리버싱이라는 것을 다룰 때 포괄적으로 알아야 할 지식과 개념, 용어, Tool 등을
정리해놓았다는 생각이 정도? )
리버싱에 관심 있으신 분들 한권씩 지르세요 ^^;
리버싱 잘하시는분들도 지르세요ㅎㅎ 인식이 많이 높아지긴 했지만 리버싱은 아직도 희귀학문에
속하는 지라 "C++ 일주일이면 쵸큼 잘하게 된다" 이딴 책보다는 아무래도 매출이 적을테니
훌륭한 책을 널리 알리는데 다들 공헌해야 한다고 봅니다 :)
---------------------------------
1장 리버스엔지니어링에 대하여
1 리버스엔지니어링이란 무엇인가?
2 크래커에 의한 피해사례, 개발자들이 주의할 부분
3 리버스엔지니어링의 전망과 취업
4 리버스엔지니어링 관련 법률
5 라이센스 정책에 대한 정리
2장 리버스엔지니어링을 위한 기초지식
1. 올리디버거(OllyDBG) 설정 및 사용법
2. Jump구문제어 문제풀이
3. CPU레지스터와 어셈블리언어, 진수변환
3-1. 진수변환
3-2. CPU 레지스터
3-3. 어셈블리 언어
3-4. 상황별 어셈블리 명령어
4. WinApi 분석을 통한 문제풀이
5. 메뉴얼 Unpack과 Back To User모드
6. 키젠(KeygenMe)문제풀이를 통한 스택과 콜링컨벤션의 이해
7. KeyFile체크문제풀이와 바이너리 수정
8. NAG제거 문제를 통한 PE구조의 이해
3장 리버스엔지니어링 관련 툴
1. 툴을 사용하는 것에 대하여
2. 시스템 모니터링 툴(System-Monitoring Tools)
2-1. Filemon
2-2. Regmon
2-3. TcpView
2-4. Procexp
3. 디스어셈블러(Disassemblers)
3-1. IDA 설치 (Install)
3-2. 메뉴구성과 IDA 사용방법
3-3. 디버깅 (Debugging)
3-4. IDA에서 For문 분석하기
3-5. IDA에서 if문 분석하기
3-6. 크로스레퍼런스 기능과 지뢰찾기 분석
4. 디컴파일러(Decompilers)
4-1. 플래쉬 디컴파일러(sothink SWF Decompiler)
4-2. 닷넷 프로그램 디컴파일러(Reflector)
4-3. 델파이 디컴파일러(DeDe)
4-4. 자바 디컴파일러(JAD)
5. 메모리패치(Memory Patch)
5-1. 티서치(TSearch)
5-2. 치트엔진 (Cheat Engine)
6. 바이너리분석(Binary Analysis)
6-1. PEiD
6-2. 리소스해커
6-3. Strings
6-4. Dependency Walker와 DumpBin
7. 언패커(Unpacker)
7-1. Universal Extractor
7-2. VMUnpacker
8. 리빌더 (Rebuilder) - ImpRec
9. 헥스에디터(Hex-editors) - XVI32와 QuickBe
10. 루트킷탐지(Rootkit Detection)
10-1. GMER
10-2. IceSword
11. 네트워크 모니터링 툴(Network-Monitoring Tool) - Wireshark
12. 가상머신 (Virtual Machine)
12-1. Vmware
12-2. VirtualBox
4장 악성코드 분석
1. 악성코드란?
1-1. 파일 바이러스
1-2. 웜
1-3. 트로이 목마
1-4. 백도어
1-5. 스파이웨어
2. 악성코드 감염경로
2-1. 메신저에서의 파일 전송
2-2. 이메일에서 파일 다운
2-3. 의심스러운 사이트에서의 Activex 설치
2-4. P2P 사이트에서의 파일 다운
2-5. 인터넷에서 감염된 파일 다운
4.3 악성코드 분석 (IRC Bot)
5장 안티디버깅(Anti Debugging)
01. 안티디버깅이란?
02. 안티디버깅의 종류
03. IsDebuggerPresent
04. Microsoft Visual Studio 2005 에서 컴파일 및 실행
05. Microsoft Visual Studio 6.0 에서 컴파일 및 실행
06. IsDebuggerPresent 우회방법
07. IsDebugged
08. IsDebugged 우회방법
09. NtGlobalFlags
10. NtGlobalFlags 우회방법
11. CheckRemoteDebuggerPresent
12. CheckRemoteDebuggerPresent 우회방법
13. FindWindow
14. FindWindow 우회방법
-----------------------------
개인적인 생각이지만, 사실 리버싱 글을 쓰기가 어려운 이유는
target 을 잡기가 힘들기 때문이라고 생각합니다.
無 에서부터 시작하는 일반 프로그래밍과는 달리, 리버싱은 분석을 당할 대상이 반드시 필요하고.
그래서 대상을 선정하기 어렵고, 리버싱 하기 위해 ㅄ될 플그램을 직접 몇개 맹글어야 하고
하지만 리버싱하는거보다 코딩하는게 더 귀찮을 때가 있고
그리고 웬지 사람들 눈에는 UI도 제대로 없는 추리한 애플리케이션보다는
누구나 아는 익숙한 프로그램을 리버싱해주길 원하고
뭐 그런 ㅈ같은 현실 때문에 글 쓰는것, 그리고 크리티컬한 분석내용과 코멘트를 작성하는 것
이매우 힘든 것 같습니다.
이 서적을 쓰신 작가분도 그러한 고민을 하지 않았을까 하고 생각되네요.
리버싱이 P2P 프로그램 속도패치나 상용 S/W 시리얼 크랙 에만 이용되지 않고
좀더 전문적인 학문이 되려면 이같은 작가의 고민이나 현실적인 문제가 좀더 극복되어야 할 것
같습니다.
핵 드라이버에서 종종 발견되는 코드
정말 이거 싫다
대책이 있을랑가 ㅋ
무슨 코드인지 알만한 분들은 다 아실겁니다 :p
머 이 드라이버 만든 사람도 제 블로그 보고 있을지 모르겟지만 ;;
저는 컴터를 쓰다가 하루에도 여러번씩 내 컴터에 깔린 커널 드라이버 리스트를 확인합니다.
드라이버를 은밀하게 깔아서 할 수 있는 짓이 워낙 많다 보니.. 저 또한 피해자의 예외대상은
아니라고 생각되어 걍 머 버릇처럼 확인하고 있습니다.
그런데 오늘 출근해서 보니 vzthni.sys 라는 묘한 드라이버가 올라와 있더군요 -_-
파일 날짜를 보니 어제 퇴근 시간 직전 시간입니다.
어떤 개쉑이 내 PC에 기 들어와서 이상한거 깔아놓은건가 하는 압뷁에 순간 혼미해지더군요
저희가 짱개들로부터 해킹 공격을 하도 많이 받다 보니 그런 생각이 더했습니다.
그리고 제 PC는 워낙 음흉한 자료가 많다보니 ㅎㅎㅎ 더 심장이 조여오더군요 -_-
일단 바이러스 토탈에 먼저 넣어 봤습니다.
== File Header ==
Machine : 0x14C (Intel 386)
NumberOfSections : 0x5
TimeDateStamp : 0x46919405 (Mon Jul 09 10:48:53 2007)
리버스 엔지니어링은 어디까지 지켜보아야 할까...
window31.
해킹/보안 분야에서 어떠한 주제를 화두에 올린다는 것은 정말 신선한 것이 될 수도 있지만
한편으로는 정말 위험한 행동이 될 수도 있습니다. 그 이유는 당연히 보안이라는
분야가 반드시 해킹이라는 전제가 선행되기에 따라오는 테마이며, 해킹이라는 전제가 등장하게
된다면 반드시 관련 프로그램의 취약점이나 유린할 수 있는 소재들이 꼬리에 붙기 때문이죠.
그리고 또 이것은 매우 위험한 행동과 직결되는 수도 있습니다 (법적인 문제까지)
그래서 해킹이나 특히 리버스 엔지니어링에 대한 어떠한 언급을 하기가 매우 조심스러워 집니다.
리버스 엔지니어링 쪽에 대해 한가지 주제가 나오게 된다면 당연히 리버싱 당할 Target 이
나올 것이고 이는 대부분 상용 소프트웨어거나 현재 End User에게 서비스 되고 있는 프로그램들이
대부분일 가능성이 높습니다. 이쯤 되었을 때 어느 정도 보안 쪽 경력이 있고 혹은 윤리성을 갖춘
리버서라면 리버싱을 하긴 해도 그에 대한 내용을 공개적인 자리에서 언급할 때 매우 고민을
하게 됩니다.
일단 요즈음 소프트웨어들은 대부분 리버스 엔지니어링 방지 문구를 약관에 집어넣고 있고
분명히 함부로 바이너리를 까보았다간 법적인 마찰까지 갈 수도 있습니다. 거기까지
이어지지 않더라도 최소한 그 사람에게 피해를 주거나 이리저리 귀찮게 불려다닐 수 있습니다.
만약 좀 심한 짓을 했고 그 사람이 어디 해커 출신이라면 그 그룹 멤버는 같은 출신이라는
이유만으로 영화처럼 줄줄이 엮여가기도 하죠.
그게 또 한편으로는 이해가 되는 것이 법적인 문제를 떠나서 같은 개발자 입장에서
내가 고생해서 졸라게 코딩을 해놨는데 그걸 어떤 한 개같은넘이 리버스 엔지니어링으로 완죤
ㅄ 을 만들어 놨다... 싶으면 사실 그건 그 개발자의 자존심에 중대한 타격을 주게 됩니다.
저시키는대체모야 머 이런것부터 시작해서 별의별말이 다 나올수 있습니다. 동종업계로써
사실 지켜야 할 윤리 덕목이 뭔지도 생각할 수 있는 부분이라고 봅니다.
따라서 만만한게 프리웨어고 혹은 상업성과 상관없는 프로그램들 혹은 기껏해야 해킹대회
프로그램만이 리버스 엔지니어링의 공개적인 석상에 오르게 됩니다(아 악성코드도 있네요).
물론 이런 것들을 통해서도많은 것을 배울 수 있긴 하지만, 배움의 열망과 갈망에 시달리는
이들에겐 사막 한가운데 오아시스의 그림자 정도밖에 되지 못합니다. 고수 리버서를 꿈꾸는
이들에겐 더욱 더 많은 자료와 더욱 더 체계적인 알맹이들을 원하고 그 흔적을 찾으려 인터넷을
항해합니다. 하지만 공개적인 자리에서 그런게 많지는 않죠.
하지만 그에 걸맞지 않게 리버스 엔지니어링에 대한 부정적 인식은 더욱더 강해지고 있는 것
같습니다. 머 할말은 없는게 문화의 한 부분이 활성화되어 향유하는 것 까진 좋은데, 그것이
초딩들이나 기타 악의적 목적이 있는 이들에게 비윤리적으로 이용된다면,, 네거티브 캠페인이
자연스레 자리잡는것도 무리는 없다는 생각이 듭니다...
그래서 이제 생각해 볼 때가 된 것 같습니다. 과연 리버스 엔지니어링은 합법인가 불법인가
그리고 이것을 학문으로 규명해야 할 것인가? (물론 대학교에서 소프트웨어공학 시간에 리버싱에
대해 잠깐 나오긴 합니다만... 그건 간장종지 찍어먹는 수준에 불과하므로 일단 패스 ;; )
제 입장은 사실 두개입니다... 해킹/보안을 탐구하는 연구가의 입장과 밥벌어먹고 사는 사람인
보안 개발자나 보안 컨설턴트의 입장에서 말할 수 있겠네요.. 일단 연구가의 입장에서는 당연히
합법입니다. 리버스 엔지니어링이 있어야 소프트웨어의 취약점을 규명할 수 있고, 또 이것은
제가 마소2월호 원고에 비슷한 내용을 언급하기도 했지만 코딩하는 사람의 심리적인 측면이나
습관 등도 관찰할 수 있기 때문에 심리학적인 부분까지도 깨우칠 수 있습니다. 따라서
기술적으로나 형이상학적으로나 학문으로 지정해줄 가치는 충분하다고 생각합니다.
다음으로 보안 개발자나 컨설턴트의 입장에선 반대입니다 -_- 왜냐하면 리버스 엔지니어링을
통해 보호를 해야 할 소프트웨어의 너무도 많은 부분이 까발려지고 있으며 그에 따라 수많은
해킹이 등장하고 있기 때문에 그를 일일히 다 처리하기는 너무 힘들기 때문입니다. 사실 기술을
기술로 이길 수는 없습니다. 특히 이쪽 분야는 더욱 그렇습니다. 막는 기술이 나오면 깨는 기술도
반드시 등장합니다. 따라서 제도적인 측면이 뒷받침을 해 주어야 (법적인 면) 막는 사람이 어느
정도 숨돌려가며 살 수 있습니다. 따라서 반대입니다 ;;
ㅎㅎ 두가지 입장을 모두 얘기해보았는데요 진짜 제 마음은 어느 것일까요.... :$
잠시 동문서답을 하자면 원래 단발에 살짝 끝내려고 했던 F-Secure Reversing 대회 원고를
분량이 너무 많다는 이유로 컷트당해 2회 기획으로 분리하고, 마소2월호 원고를 마친 후
다음 기획을 고민하면서 생각이 든 내용을 지금까지 한번 씨부려 봤습니다.
마이크로소프트 잡지에 보여주고 싶은 것이 몇개 있습니다(아... 잘난척 처럼 들릴 거 같네요
사실은 소재 모잘라 죽겠습니다). 하지만 리버스 엔지니어링이란 분야를 다루려니 걸리는
것이 너무 많네요. 이 프로그램으로 해보려니 그쪽 회사에서 전화 올 거 같고, 저걸로 해보려니
우리 회사에서 날 죽일라고 할 것 같고... 뭐 고민 중입니다. 어느 정도 수위를 어떻게 맞추어야
할 지... 윤리/도덕의 절대적 가치 판단의 자질이 매우 떨어지는 저로서는 망설임만을 갖게 합니다.
머 어쨌든 쓸데없는 소리는 이것으로 정리하고 :p
제 홈피에 마이크로소프트 기고 내용을 처음 광고 해보겠습니다 ㅎㅎ 이번주에 나올 2월호 기사는
지난번에 제 홈피에도 공개하지 않았던... 디버깅 도중 수학문제가 나와 날 황당하게 만들었던
F-Secure Reverse Engineering 대회 Level 3을 다룹니다.
다음번엔 별로 할게 없어서 악성코드나 할까 합니다. major function table hooking 쪽을
기획하고 있습니다. IRP Hook 이라고나 할까요 ㅋㅋ 잼있는 악성코드가 있었거든요
드라이버 쪽이 되겠네요 드라이버 쪽 아는것도 개뿔도 없으면서 글 쓰려니 쪼팔리는군요 -.-
window31. 2008년 1월