리버스 엔지니어링 바이블, 오탈자나 기타 문의



리버스 엔지니어링 바이블, 오탈자나 기타 문의에 대해서는 아래 공지를 참조하시면 됩니다. 앞으로는 오른쪽 상단 공지에 띄워놓겠습니다.


http://window31.com/notice/410



저작자 표시
신고
Posted by window31


댓글을 달아주세요

  1. 2012.10.08 11:36 신고
    댓글 주소 수정/삭제 댓글
    사인해주세요~~~
  2. 뉴비
    2012.10.15 19:16 신고
    댓글 주소 수정/삭제 댓글
    저자님 요새 엄청 바쁘신가요??

    아니면 제 문의가 전달되지 않았는지... ㅠㅠ
    • 2012.10.15 20:37 신고
      댓글 주소 수정/삭제
      죄송합니다. 요즘 좀 정신이 없네요.. 얼른 답장 드리겠습니다 !
  3. 뉴비
    2012.10.15 23:57 신고
    댓글 주소 수정/삭제 댓글
    아 엄청 바쁘셔서 그러시군요.

    그럼 천천히 답장주세요.

    저는 혹시 안갔나해서요.

    좋은책 감사요~
  4. 2012.10.22 01:38 신고
    댓글 주소 수정/삭제 댓글
    티스토리에서 한 블로그를 운영하는 유저입니다.
    '리버스 엔지니어링 바이블' 책과 관련해서 출판사에 올려져 있는 코드들은 VC++ 6을 바탕으로 되어있는 코드인데, 이 코드들을 Visual Studio c++ 2010 버전에서 컴파일 하면 "...(nakid) PlusAsm(int a, int b).."부분에서 오류가 납니다. 따라서 (naked)다음 부분에 int를 추가해 주어야만 실행이 가능합니다. 이 수정한 코드를 제 블로그에 올려도 될련지요?..
    ( http://warrior119.tistory.com/ )
    • 2012.10.22 14:22 신고
      댓글 주소 수정/삭제
      그럼요~ 언제나 자유롭게 수정하셔도 됩니다. 오히려 감사드립니다 !
  5. jmlim_jungmee
    2012.11.07 15:17 신고
    댓글 주소 수정/삭제 댓글
    선배님 책 출판하셨네요~^^ 축하드려요~
    저도 책사서 사인받으러 가겠습니다.

OllyDBG Plugin - GODUP





좀 오래된 플러그인이긴 한데, 별로 아시는 분이 없는 것 같아서 한번 소개해봅니다.
GODUP 라는 플러그인인데, 기능은 좀 잡종이라 이것저것 다 설명하긴 좀 그렇고요
(resource hack 이나 PE Scanner 같은 기능은 제쳐둡시다)
map loader 라는 기능, 이걸 한번 도마 위에 올려 보겠습니다 :)

이 기능이 어떤 것이냐면 map 파일을 플러그인에서 지정해 줄 경우,
현재 분석중인 바이너리를 map 파일로 매칭시켜서 디스어셈블리 창에 뿌려주는 겁니다.
즉, map 파일이 있는 바이너리를 분석할때는 아주 좋죠~
(map 파일이 없는 바이너리야 뭐 아무 상관없는 플러그인이지만...  ;;; )

한번 볼까요~

예를 들어 리버싱 시에 이런 코드가 있습니다.
뭐하는 call 문인지 안에 헤집고들어가서 후벼보기까진 알 수 없죠 :(

사용자 삽입 이미지

그런데 GODUP 로 한번 map 파일을 연결해주면 아래와 같이 바뀝니다!
올리디버거 상의 디스어셈블리 코드를 map 파일에 나온 함수명대로 연결시켜준겁니다 오 좋아요 ~!

사용자 삽입 이미지

자~ 이제 첫번째 call 문은 InitNSS() 라는 함수고, 두번째 call 문은 OnButtonStart() 라는
것을 알 수 있네요! 이름으로 추정해보면 대충 함수의 역할은 알 수 있죠 ㅎ 첫번째 함수는
초기화 루틴에 쓰일 것이고 두번째 것은 머 button handler 라는 것 까지 파악이 가능합니다 :)
그리고 이 함수는 CNSS_GUIDlg 라는 class 의 member 함수라는 것 또한 확인이 되고요

이런 기능 덕에 용이해지는 상황

1) 내 코드 리버싱
저희 같은 리버싱 떨거지 부류들은, 디버깅할 때 비주얼 스튜디오의 디버깅 환경을
이용하지 않고 (디버그 빌드 조차 안합니다 only Release Build ㅎㅎ) 자기가 만든
바이너리임에도 불구하고 ollyDBG 나 windbg에 붙혀서 디버깅 하죠 ㅋ
이런 상황일때 GODUP 는 아주 큰 힘을 발휘합니다.
적어도 내가 만든 코드를 보며 어디가 어딘지 몰라서 방황하는 시간은 확실히 줄여 줍니다 ;


2) 코드 컨설팅, 취약점 분석
코드 컨설팅 혹은 취약점을 찾고 있을 때
그 많은 코드를 모두 리버스 엔지니어링으로 확인하기는 사실 힘든 부분이 없지 않아 있죠.
그래서 부분적으로라도 개발팀에 소스를 요청하는데, 개발 보안 정책상 소스를 밖으로 빼낼
수 없는 경우도 있고, 컨설턴트 ㅅㅂ야 니가 어느정도 하나 보자 등 괜히 안줄때도 있습니다. :)

음 그럴땐 어떻게 어떻게 일단 map 파일이라도 받아냅니다.
그리고 그걸 현재 바이너리랑 맵핑시켜서 돌리면 오우~ㅋ
작업능률이 10배는 향상되죠.
그리고 소스 없이 리버스 엔지니어링만으로 상대방의 코드를 깔 수 있는 기회가
좀더 빠른 시간안에 생기는거죠 :p
(아으... 혹시 이 블로그를 보는 우리회사 개발자들 이제 저한테 맵파일 안주는거 아니겟죠 ;;; )

그래서 암튼 저는 주로 map file - exe file 맵핑에 이 플러그인을 많이 씁니다.

요점은 이런식으로 map 파일을 연결시켜주는 플러그인이 있고
그것을 올리디버거에서 이렇게 훌륭히 사용할 수 있다는 것이 되겠습니다 :)
그냥 악성코드만 보시는 분들은 필요 없는 플러그인이 될수도 있겠지만요...;

window31. 2009년 3월


ps
음 그냥 문맥상 코드를 깐다... 라고 표현했는데,
사실 실제 업무를 할때, 컨설팅 받는 입장이 더 고마운 것이긴 하지만
오히려 공격하는 입장에서 더 굽신굽신 해야 한다고 생각합니다.
코드를 공격하면서 거만하거나 매너 없는 사람... 크랙질이나 다를 바 없다고 보이거든요
진정한 남자라면 굽신모드.

신고
Posted by window31


댓글을 달아주세요

  1. 2009.03.26 09:52 신고
    댓글 주소 수정/삭제 댓글
    이런걸 진작에 알려주질않고;;..-ㅂ-;;
    방금 GODUP 다운받았어요;;ㅋㅋㅋㅋ
    • 2009.03.26 10:47 신고
      댓글 주소 수정/삭제
      글고보니 첨부파일을 집어넣지 않았네...
      다시 첨부했음
  2. 2009.03.27 11:53 신고
    댓글 주소 수정/삭제 댓글
    진정한 남자라면 굽신모드...
    요즘들어 실감하는 말이네요.
    같은 회사 개발자들 상대로 "제발 한번만 컨설팅 받아주세요.
    굽신굽신 도와주세요... " 이러고 살아요.
    map파일있으면 windbg를 먼저 사용하게 되더라구요.^^
    GODUP도 앞으로 써봐야 겠네요.
    • 2009.03.30 09:29 신고
      댓글 주소 수정/삭제
      하하하
      "저는 제발 이렇게 좀 고쳐주세요"
      라고 하죠 : )
  3. 2009.03.27 16:27 신고
    댓글 주소 수정/삭제 댓글
    오래된 기억이라 애매한 질문인데요, map파일이 있다면 이미 pdb나 sym같은것도 있을건데(아니면 변환해서), 그러면 ollydbg에서 그냥 로딩 해주지 않나요? (저는 ida만 썼어서 질문이 좀 이상해도 이해해주세요ㅎㅎ)
    • 2009.03.30 09:30 신고
      댓글 주소 수정/삭제
      ollydbg 디폴트 버전에서 map 파일을 그냥 로딩해주진 않습니다 ^;
  4. seyool
    2009.03.27 17:31 신고
    댓글 주소 수정/삭제 댓글
    그동안 왜 이런생각을 못했을까요.. OTL
  5. 2009.04.15 19:00 신고
    댓글 주소 수정/삭제 댓글
    map 파일조차도 없는 프로그램 분석할 때에는, IDA에서 map 파일 생성해서 연결해주면 '그나마' 도움이 좀 될것 같습니다.
    • 2009.04.17 16:48 신고
      댓글 주소 수정/삭제
      '그나마'인가요 ㅎㅎㅎ 패킹된거(특히 Themida) 때문에 요즘 IDA 쓰는 비중이 줄어드는 중 ㅠㅠ
  6. 2009.09.21 06:56 신고
    댓글 주소 수정/삭제 댓글
    ㅋㅋㅋ 언제나 봐도 재밌는 글이네요

IAT Hook에 관한 고찰




그옛날 후킹이라는 주제를 처음 배울 때 인터넷이든 해외 사이트든 가장 먼저 설명하던
후킹의 종류는 IAT Hook 이었다고 생각합니다. IAT Hook을 먼저 안내하는 이유는 일단
PE를 공부하면서 Import Address Table 이라는 것에 대해 알아볼 때 부수적 효과로
덩달아 학습되기에 가장 적당한 주제이기도 하고, 또 후킹 구현이라는 데에 있어
inline hook 따위에 비하여 훨씬 쉽기도 하기 때문입니다.

그래서 보통 후킹에 대한 입문 하면 IAT Hook 부터 접하게 되는 것이 일반적이었다고
생각합니다. 따라서 저는 후킹이라는 주제를 하나의 큰 학문이라고 가정하고 그것을 수학에
비유한다면 IAT Hook 은 인수분해 쯤 되는 순서라고 봅니다. 또 그만큼 기초적이기도
하니까요.

하지만 쉬웠던 만큼 IAT Hook은 실전에선 그렇게 많이 써먹히지가 않았죠. 그 이유는
무엇일까요. 바로 IAT Hook 에는 "범용성" 이 없었습니다. 써먹을 타겟에 한계가 있던 것이죠.
IAT Hook 을 널리 전파하기에는 프로텍터와 패커라는 너무도 높은 관문이 있었습니다.
패킹한 바이너리의 IAT 를 찾는것은 패커의 종류마다 버전마다 너무도 많은 차이가 있고
또 그 각각의 IAT를 구하기도 쉽지 않습니다. 따라서 후킹하기에 앞서 모든 호환성이나
플랫폼을 감안하여야 하는 보안 솔루션 입장에선 IAT 는 건드리기 힘든 혹은 건드려서는
안되는 불모지 쯤으로 전락하게 됩니다.

그리고 역시 inline hooking 이 가장 범용적이면서 또 기능도 강력하기 때문에 사람들의
관심은 이쪽에 맞추어진 채로 지금까지 오게 됩니다. 그래서 inline hook 을 더 효율적으로
하는 여러가지 연구가 이루어집니다. 예를 들면 중간번지를 후킹한다거나 push address
retn, 트램벌린 코드 같은 시도가 그것들이죠. 처음 볼때마다 신기한 넘들이 등장하고
또 그것을 막거나 우회하기 위한 논의가 지속됩니다. IAT Hook은 버려져 있다고 생각하기
쉬운 이 시점에 overwrite hook은 계속 발전하고 있습니다.

하지만 최근에 실제 현업에서는 분위기는 또하나의 물결이 보이는 것 같습니다. 해커들에게
요즘의 대세는 IAT Hook 입니다. 보안업계 사람들이 버려둔채 이목이 집중이 되지 못하고
있는 영역인 것을 그들이 눈치라도 챈 듯, IAT 쪽을 최근 집중적으로 건드리고 있습니다.
특히 보안 모듈이나 보안 코드가 온전히 가동되고 있는 상황에 더욱 그렇습니다.

이들이 IAT 쪽을 공격하는 제가 나름대로 생각하는 이유를 적어보겠습니다.

1. 공격대상은 거의다 패킹된 바이너리이며 보안 코드 작성시 그 상태에서는 IAT 를
   쉽게 구할 수 없다. 따라서 검사하지 않을 것이다. 
2. 하지만 해킹툴을 만드는 입장에선 까짓거 노가다로 찾아서 하드코딩 해버리면 된다.
   (대부분이 이런 넘들임. 클라이언트가 패치하여 번지가 바뀌면 후킹하지 못함)
3. 보안 솔루션이 IAT 를 구하더라도 패커가 내부적으로 리다이렉트 시키는건지
   해킹툴이 훅을 하는건지 패커의 내부구조를 상당수 파악하기 전까진 분간하기 힘들다.
4. 훅을 해도 system dll 들의 메모리 CRC가 변경되지 않는다.


대략 이정도 같군요. 늘어놓고 보니 IAT Hook 이 공격하기에 꽤 매력적이라는 생각이
듭니다. 즉 이정도 이유만 되어도 IAT Hook 으로 공격할 당위성은 충분하다고 보입니다.

저는 르네상스 라는 단어를 좋아합니다. 르네상스는 문화의 부활 이라는 의미로 많이
사용되죠. 그래서 저는 IAT Hook 도 일종의 르네상스라고 보고 있습니다. 이전에
디버그랩에서 발표를 할 때에도 IAT Hook 의 르네상스라는 표현을 사용한 적이
있고 작년 마소에서 IRP Hook을 다룰 때에도 역시 마찬가지 비유를 들었던 기억이
있네요. 르네상스보다 사실 더 좋은 우리 선조들의 말씀도 있죠 "구관이 명관이다!"
예~ 역시 옛 것을 다시 살펴보는 것은 정말 중요한 것 같습니다.

마무리 짓자면 리버스 엔지니어링을 할 때 무언가 답은 나오지 않고 답답하다 싶으면
한번 IAT 쪽도 살펴보세요. 큰 힌트를 발견하게 될 수도 있습니다 :)

최근 들어 IAT 를 고도의 기술로 건드리며 우리를 당황하게 하는 중국애들을
보며 느낀 내용들입니다.


window31. 2009년 1월


신고
Posted by window31


댓글을 달아주세요

  1. 2009.01.12 09:01 신고
    댓글 주소 수정/삭제 댓글
    좋은 글 잘봤습니다. 역시 내공이 대단하셔요. 그나저나 중국해커들은 참 대단하다는 생각을 많이 합니다. 사람이 많아서 그런건지 정말 똑똑한건지.. 노가다를 좋아하는건지.. ^^;; 오늘도 화이팅하세요.
    • 2009.01.12 21:50 신고
      댓글 주소 수정/삭제
      일단은 사람이 많아서 라고 추측하고 있다는 ㅎㅎ
      뭐 잔대가리도 대단하죠 ^^
  2. rodream
    2009.01.12 10:13 신고
    댓글 주소 수정/삭제 댓글
    IAT Hooking 구조적으로 호환성이 안좋습니다.

    XP 32bit 에서만 실행된다고 하면 모르겠지만,

    Vista 에서 GetProcAddress 로 가져가서 저장하고 쓰는 경우와

    64bit 에 대한 지원 불가능으로 인해서 다소 압박입니다 =_=;;
    • 2009.01.12 21:50 신고
      댓글 주소 수정/삭제
      그렇죠 ㅎㅎ 그래서 구현/검사/원복화 는
      다들 꺼려하죠 ^^
  3. 2009.01.13 11:11 신고
    댓글 주소 수정/삭제 댓글
    ㅎㅎ 이게 지난번에 말씀하셨던 "IAT Hook의 르네상스"라는 것이었군요.
    이 바닥에서 일하려면 정말 잔머리가 잘 돌아야겠다는 생각을 해보게 되는군요.
    • 2009.01.13 18:52 신고
      댓글 주소 수정/삭제
      네 맞습니다.
      정파 기술 + 잔대가리가 필요하죠 : )
  4. 2009.03.21 22:27 신고
    댓글 주소 수정/삭제 댓글
    오랜만에 다시 보는 글입니다... :D

    제 블로그에서도 보셨겠지만... VirtualQueryEx() 를 이용해서 PE header가 차지하는 page size를 얻어낸뒤 그것을 더해버리면 대부분의 파일의 경우 IAT가 나와버려서... (물론 난점이라면 어떤게 후킹해야할 API인지 모른다는 것이 있겠지요...;;)
  5. Dual
    2010.07.16 21:28 신고
    댓글 주소 수정/삭제 댓글
    1년 이나 지난 글에 대한 리플이고 하지만, 생각해보면 그 외의 장점이 생각나서 적어봅니다,
    분명 아래 단을 후킹할수록(Lower, Wider) 한게 사실입니다.
    그게 장점이지만, 그만큼 훅 체인에 대한 경쟁도 치열하고, unhook될 가능성도 높죠, 또 Game Hack의 입장에서는 어떻게든 Native API의 꼭 호출해야만 하는 (Pesudo code 짜기가 좀 까다로운, system에 많이 dependent한)
    놈만 어떻게든 호출하면 되니까요, ObObjectByPointer와 KeAttachProcess(더 아래단의 stack이 더 많이 쓰이겠지만서도) 같은 놈들 말이죠,

    업계 리더 그 제품도 SSDT 에서 -> 인라인 훅으로 바뀌었더군요(커널단에서)

    SSDT Restore가 워낙 빈번하기 떄문이겠죠, 또한 원본 함수 주소를 구하는 것도 쉬우니까요,
    그다음 inline hook일떄도 후킹 대상 프로세스 또는 dll의 원본 파일을
    읽어서 , 제계산을 통한
    HookingStub(;;;)
    {
    execute rap code
    jmp originalfunc + rapcodesize
    }

    식으로 처리가 가능하죠, 이미 저도 몇년전에 써봤던 테크닉이고,
    그랬더니 그 후엔 훅이 중간으로 이동되더군요.

    이에 대한 Game Hack 의 대응은 바로 Code Relocation 이겠죠,
    이제 더 이상 그 함수를 쓸 필요도 없는, Pure한 코드는 제계산을 통해서
    얻을 수 있을테고, Relocation 해서 새로운 메모리 영역의 새로운 함수를
    쓴다면 더 이상 영향도 안받겠죠,
    이제 가장 중요한건, 보안 솔루션의 훅들 보다 가장 먼저 닿는 포인트가 어디인가 하는겁니다. 예전에는 가장 깊숙히 하는게 중요했다면, 더 로우레벨의 함수를 호출해서 우회했다면, 이젠 가장 상위에 함수를 후킹해서, 슈도코드를 짜서, 아랫단의 함수 호출 없이 처리 해버리는 , 점점 말하자면 가상화 방식으로 가는거죠, IAT 훅도 보안솔루션이 선점하면, 어짜피 요즘 Detour나
    Madchook 같은 라이브러리의 Disassemble 코드도 잘되있으니,
    API Call 부분을 찾아서, 고쳐주는, inline hook 이지만, 가장 상위의 inline hook 을 시도할겁니다 저라면, 그외엔 그냥 후킹도 하지 말고 자기가 만든 함수 DeviceIoControl 로 불러주면 될꺼 같습니다 ㅋㅋ 물론,
    IoControlCode도 보고 감지 하니, 가변적으로요 하하 ㅋㅋㅋ
    (xor 이 생각나네요)

    ㅠㅠ 그냥 이 글에 안적혀 있길래 썻지만, 이 블로그에 있는 글들에 충분히 담겨 있는 내용이라고 생각합니다 ㅋㅋ 클라이언트 단의 훅 체인, 후킹 방지 방법도 뭐 사실상 의미 없는 논쟁이고, 사실 상 불가능하죠 ㅋㅋㅋ 그럼에도 불구하고, 정보가 필요한 분들에게 혹시나마 도움이 될까 하고, 남겨봤습니다 ㅋㅋ (아마 없을듯)

    생각해보면 게임해킹은 다시하면 별로 재미없을거 같은게, 이제 더이상은 window31님이 안게시니까요 ㅠㅠㅋ
    츤츤ㅋㅋ!

계산기 커스터마이징




오랫만에 리버스 엔지니어링 관련 글을 쓰게 되는 것 같네요 ^^;

오늘의 주제는 1byte Patch 입니다.
저희팀에서 같이 일하는 haru 라는 분이 예전에 간단히 만든건데요.
간단하면서도 나름 재미있는 부분이라 한번 설명해 보겠습니다.

윈도우즈의 계산기 calc 많이들 사용하시죠.

특히 개발자나 리버서들은 16진수 사용이 필수이기 때문에 보기 - 공학용 으로 변경하셔서
많이 사용하시곤 합니다.

사용자 삽입 이미지


근데 공학용 으로 셋팅을 바꾸면 윈도우즈에서 그 설정값을 기억하고 있기 때문에
계속 저런 모양이 되지만

16진수인 Hex 를 선택해도 종료한 뒤 다시 실행하면 Dec 로 바뀌어져 버립니다.
그래서 실행할때 마다 Hex로 바꾸어야 하는....
졸~~ 짜증나죠  ㅅㅂ

그래서 계산기 Dialog 가 셋팅될때 라디오버튼을 아예 Hex가 디폴트가 되도록 바꾸는 방법이
있습니다. 그 방법은? 초기화 코드에서 처음에 UI 설정을 할 때 10진수로 라디오버튼을 셋팅하는
부분을 16진수로 바까버리는 방법입니다.

그 부분을 한번 뜯어가 볼까요.

아래 이미지를 보시면 UI 초기화 루틴인데요,  0x1001DCD 번지의 콜문을 보세요.

사용자 삽입 이미지



여기가 계산기 진법 셋팅하는 루틴입니다. 인자는 진수고요. 인자를 esi에 넣고,
esi를 2, 8, 10, 16과 각각 비교하는 코드가 보입니다. 그 숫자는 2진법, 8진법, 10진법, 16진법에
대한 숫자겠죠 :)



사용자 삽입 이미지


그러므로 0x1001DCB에 들어가는 push 0Ah 를 push 10h 로 변경시켜주면
매번 16진수로 셋팅이 되어서 실행이 되겠죠 0x0A 를 0x10 으로 바꿔주기만 하면 됩니다.
간단한 1 byte patching 이죠 :p

아주 쉬운 내용입니다. 이것으로 앞으로 매번 실행시마다 16진수가 디폴트인 채로 사용할 수
있겠죠. 다음에는 몇가지 코드를 주입해서 쵸큼 더 지능적으로 바꿔보도록 하겠습니다. :)


window31. 2008년 9월.

신고
Posted by window31


댓글을 달아주세요

  1. 2008.09.16 14:29 신고
    댓글 주소 수정/삭제 댓글
    오옷..계산기 사용하면서 불편하다 생각은 했지만
    패칭해볼 생각은 안해봤었네요ㅠㅠ

    좋은정보감사합니다.
    바로 계산기 패칭한 ㅎㅎ
    • 2008.09.18 02:11 신고
      댓글 주소 수정/삭제
      아랫 분이 한겁니다 ㅎ
      2부는 곧.
  2. 하루
    2008.09.17 08:43 신고
    댓글 주소 수정/삭제 댓글
    ㅊㅈ다!!
  3. 2008.09.17 11:18 신고
    댓글 주소 수정/삭제 댓글
    정작 나같은 사람은 계산기 파일을 어떻게 저런 코드로 열 수 있는지 조차 모른다는...ㅠㅠ(acroedit 같은걸로 여니 이상한 글자만 나와--ㅋ)
    • 2008.09.18 02:10 신고
      댓글 주소 수정/삭제
      머 형은 저런거 안 열어도 돈 마니 버시자나요 ㅎㅎ
  4. neo
    2008.09.19 11:07 신고
    댓글 주소 수정/삭제 댓글
    오~~
    별 생각 못하고 있었는데...

    저도 오늘 출근 하자 마자 해버렸다는...

    멋진 blog 잘 보고 있습니다.

    몰래몰래 눈팅하던.. 나그네 1인.ㅡㅡ
    • 2008.09.21 18:23 신고
      댓글 주소 수정/삭제
      별거 없는 블로그 방문해 주셔서 감사합니다 ^^;
      2부를 써야 하는데 귀차니즘의 압뷁 ;
  5. BlackMusic
    2008.10.12 08:22 신고
    댓글 주소 수정/삭제 댓글
    주인장님 잘봤습니다.^_^)^

    제 블로그에 출처를 남기고 가져가도 되나요..?
    • 2008.10.15 00:53 신고
      댓글 주소 수정/삭제
      네~ 출처만 있다면 어디든 퍼가셔도 괜찮습니다.
      별 대단한 글도 아닌데요 몰..ㅎ

[서적] 리버스엔지니어링 : 역분석 구조와 원리




서적 출간 소식입니다.
국내에서도 리버싱을 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 시리얼 크랙 에만 이용되지 않고
좀더 전문적인 학문이 되려면 이같은 작가의 고민이나 현실적인 문제가 좀더 극복되어야 할 것
같습니다.




신고
Posted by window31


댓글을 달아주세요

  1. 2008.08.25 18:26 신고
    댓글 주소 수정/삭제 댓글
    예전에 한번 툴 사용에 대해 적어놓은 국내 해킹 책을 본 것 같은데, 살짝 그런 느낌이 나는군요. ^^
    나중에 하나 사봐야겠습니다. ^^
    • 2008.08.27 23:49 신고
      댓글 주소 수정/삭제
      ㅎㅎ 까마귀님도 홈브류 책 하나 내주세요
  2. 2008.09.01 22:12 신고
    댓글 주소 수정/삭제 댓글
    헉... 쓰는건 둘째치고 저작권에 걸리지나 않을까 모르겠군요. ㅠㅠ
    ㅎㄷㄷㄷ
  3. 2008.10.14 15:02 신고
    댓글 주소 수정/삭제 댓글
    리버싱쪽으로 관심이 많았었는데...

    한번 사봐야 겠어요 ㅋ
    • 2008.10.15 00:58 신고
      댓글 주소 수정/삭제
      네. 간장게장 저도 참 좋아하는데 사먹어야겠어요.
  4. 자아
    2009.01.03 23:09 신고
    댓글 주소 수정/삭제 댓글
    이 게시글보고 책구입했습니다.
    전부터 관심이 있었는데 C언어도 모르는 저로서는 상당한 무리가...
    어쨋든 좋은책 소개해주셔서 감사합니다^^
  5. 2012.06.07 18:11 신고
    댓글 주소 수정/삭제 댓글
    원래 이 책에 얽히 비하인드 스토리가 있습니다. 원래 이 책을 제작한 작가들하고 제가 친분이 있었습니다. 같이 사이트 운영도 했구요.. 그래서 그 분들이 리버스 에니지어링 책을 지을려고 하는데 다른 파트는 다 자신들이 담당할테니 저는 기존에 제가 집필해서 인터넷으로 뿌린 문서인 Art of Hooking 부분을 넣자는 제의가 있었죠.. 저도 알았다고 문서를 순화시키겠다고 했는데.. 결국, 저는 이 책의 집필에 빠지기로 결정을 했드랬습니다. 그 이유가 바로 Window31 님이 지적하신 부분 때문이었습니다. 다른 부분 즉, 기술과는 상관없는 개념이나 기술이 발전해야할 미래의 모습과 현재 리버스 엔지니어링을 어떻게 접근해야 하는가에 대한 부분들을 제가 쓸수가 없었습니다. 제가 적고 싶은 부분들은 제가 Art of Hooking 문서에서도 적어놨듯이 리버싱을 단순히 크랙이나 루틴우회 정도로 보는 것이 아닌 학문적인 접근을 바랬거든요.. 예를들면 바이너리의 소스화 그리고 어셈블리를 C 소스 단위로 재구현을 하기 위한 분석관점을 중요하게 생각을 했습니다. 예를들면 어셈블리를 어떤과정을 통해서 C 로 역변환을 할 수 있는 지에 대한 최소한의 이론적인 부분이라도 넣고 싶었죠. 근데, 당시에는 HexRay 가 최초로 선보이기 시작(?)한 때였습니다. 다들 C 로 완벽한 역변환은 불가능하다고 말하던 시기에 HexRay 가 나왔던 것인데요.. 그 얘기는 그 당시에 제가 어셈블리를 C 로 역변환 시키는 이론에 대해서 완벽하게 공부하지 못한 상황이었단 얘기죠.. 그렇기 때문에 그 부분을 넣고 싶었고 욕심이 과한 나머지 결국 책 집필에서 빠지기로 했습니다. 제가 하고 싶었던 얘기(학문적인 관점에서 리버스 엔지니어링을 파야한다)를 주장하려면 그 역변환 과정에 대한 기술적인 설명을 할 수 있는 레벨이 되어야만 한다는 심적인 부담감이 컸습니다. 그래서 결국, 빠지기로 했던거죠.. Window31 님도 이미 알고 계시듯이 많은 초짜 리버서들이 크랙이나 패치를 만드는 것 따위를 위해서만 시작합니다. 그것이 그들의 수준에 가장 맞고 그것이 그들에게 시작할 동기 즉, 호기심을 주었으니까요.. 그러다가 결국에는 엄청나게 분석하기 어려운 놈을 만나게 될겁니다. 아마도 팩킹이 걸린 바이너리를 만나서 디버거를 연결해서 분석도 못하게 되는 상황이 오겠죠.. 그 상황이 만약 스스로를 열받게 자극하거나 혹은 실업무(과거에는 리버싱 분야에 실업무라는게 없었습니다. 대신, 뒷거래가 있었죠.. 크랙해주면 용돈 몇푼 받는 그런류..) 에 부딪혔는데 팩킹이 걸려있게되면 그걸 푸는데만 집중합니다. 그리고 언팩을 하게되면(대부분 직접하는 경우도 못봤습니다. 해외에서 언팩툴 찾아서 돌리는 수준.. 좀 집착하는 사람들은 메뉴얼(수동)언팩킹까지는 공부합디다.. 아니면 덤프뜨거나..) 거기서 더이상의 분석을 멈춥니다. 왜냐면, 그 수준에서 멈춰버리는 것이죠. 더 큰 과제를 앞으로 만날수 있음을 모르는 것이죠. 그리고 그 이상도 사실 바라지 않기 때문에 거의 디버거로 대충 call/jmp 흐름을 따라가는 감각적 리버싱에만 의존하게 됩니다. 그러다가 만약 포기하지 않고 계속해서 흥미를 갖게 된다면 나중에 반드시 데이타를 다루는 루틴까지 다 분석을 해야할 상황에 당도하게 됩니다.. 안해도 될지도 모르지만 스스로 해보고 싶어할 상황이 반드시 오게될겁니다. 그때가서 공부를 하게되겠죠.. 어떤영역이냐면.. 바로.. 동적분석(디버거를 사용하는 부류)을 버리고 바로 정적분석(어셈블리를 읽는 이론적인 리버싱에 가까운 영역.. 즉, 고수영역)으로 가게 되는 겁니다. 이 과정에 대해서 아무리 설명을 해도 사람들은 여전히 이렇게 말합니다. 난, 아무리 아무리 정을 붙일려고 해도 IDA 는 정이 안가.. 나는 여전히 올리디버거가 좋더라라는 사람들이 있습니다. 그런 사람들은 초보에서 중급자 정도의 딱지를 떼지 못한 사람들이죠.. 해외에서는 이미 정적분석에 대해서 엄청나게 연구가 된 상황인데.. 그래서 제가 예전에 운영하던 파워해커에서 가장 싫어하는 리버서가 언팩킹을 연구하는 해커였습니다. 사실, 연구같지도 않은 연구(어디서 뭘하고 어디서 뭘하고 어떻게 하면 풀린다. 내지는 어디 스크립트가 있다.. 내지는 스크립트 어떻게 짠다 정도..?)였습니다.. 팩킹이라는 것은 어차피 제작자의 의도는 풀릴것을 알지만 시간을 끌기위한 용도입니다.. 팩커를 푸는데 시간이 들면 그것은 제작자의 의도에 말려들어간 꼴인거죠.. 사실상 팩커를 푸는것이 중요하지 않다는 것이 아니라 그 이상에 관심을 가지라는 얘기를 해도 사람들이 받아들이질 않았습니다. 팩커를 푸는 것 이상에 루틴을 파악하는 이론을 만들고 그것을 검증해보고 더 나아가 데이타를 루틴에 연계시켜서 이해하는 방법을 깨우치고 최종적으로는 그 프로그램을 역으로 소스로 만들어내는 진정한 리버스 엔지니어링을 해야 한다는 말을 해도 사람들은 아무도 받아들이질 않았죠.. 그런말이 있더군요.. 사람들은 자신이 경험을 해서 직면하지 않는 순간까지 남들이 아무리 조언을 해줘도 받아들이지 않는다구요.. 필요에 의한 공부동기가 생기지 않으면 아예 받아들이지 않더라는 것이죠.. 오래전에 이런말을 했었습니다. 만약에 밥통에 들어있는 칩의 펌웨어에 담겨있는 코드를 리버싱해야 한다면 밥통에 올리디버거를 연결하겠느냐고 말한 적이 있었습니다. 디버거의 덧없음을 간접 표현한 말입죠.. 밥통에 들어간 칩은 인텔계열도 암계열도 아닌 그저 PIC 라는 전혀 쌩뚱맞은 회사의 칩일수도 있는데 디버거에만 의존하게되면 결국 이런 문제는 해결할 수 없는 반쪽짜리 리버서가 될 수 밖에 없는 것이지요.. 그래서 이론적으로 자신만의 분석기술을 공부하고 될 수 있다면 서로 공유해서 따분하거나 지루하지 않게 공부하자는 것이 제 생각이었드랬습니다. 외국 게시판에는 이런짓들 잘 하더군요.. 그래서 우리도 함 해보자 그랬었던 거였는데.. 잘 안되더군요.. 왜냐면.. 서로의 실력차가 너무 컸고.. 이해하는 이해도의 차이도 컸고.. 고급실력을 갖고 있는 분은 자신의 프라이드(자존심)이 너무 커서 같이 뭘 하려고 들지않았고요.. 의욕이 넘치고 같이 하자고 하는 사람들은 올리디버거에 정신팔려있으니.. 뭘 해볼수가 없었던 기억이 있습니다.. 동적분석을 가볍게 보는 것이 아니라 너무 그곳에 치우쳐 있으면 결국, 이론과 멀어지게 되고, 그렇게 되면 감각적인 인스트럭션 플로우(flow:흐름)만 따라가는 감각만 발전하게 되므로, 어셈블리 루틴만 보고도 이게 프로그램의 어떤 부분에서 어떤 처리를 하고 있는 것인지를 알지 못합니다. 제가 여태까지 본 대부분의 사람들. 심지어는 쫌 하네? 라고 생각한 사람들 까지도 올리디버거에서 루틴을 헛다리 짚는 사람들을 꽤나 봤습니다. 올리디버거에서 의심이 된다고 해서 주소를 불러주면 제가 IDA 로 그 주소를 넣고 보면 어처구니 없게도 정적 컴파일을 해서 생기게 되는 crt 코드를 보고 의심스럽다고 하고 있는등.. 쫌 한다고 생각한 사람들도 이런 어처구니 없는 분석을 하는 경우가 있었다는 겁니다.. 이런일이 생기는 이유가 바로, 정적분석 단계로 넘어가서 손에서 디버거를 놓고 분석시도를 하려고 피를 흘려본 적이 없기 때문에 생기는 거라고 말하고 싶은 겁니다. 저는 올리는 사용할려고 하면 할수 있어도 정이 안가는 수준까지 정적분석만 파왔었습니다. 과거에는 도스시절 sourcer 부터 wdasm32 나 IDA 3.8 버전부터 사용해서 softice 까지 모두 온리 디버거 식으로만 사용했죠. 올리가 처음 나왔을때도 올리로 감각적인 트레이싱만을 해서 거의 감각만으로 조작 못하는 것이 없었드랬습니다. 그럼 뭐합니까? 이론적으로 이게 왜 이렇게 되는지 설명해보라고 하면 한마디도 할 수 없는데.. 그저.. 그냥 여기서 점프가 요리로 가는데 요리로 바꾸니까 요렇게 됐다라는 말 말고 아무말도 할 수 없는 것이 바로 초보라는 것이죠.. 물론, 이 과정이 굉장히 중요합니다.. 반드시 필연적으로 거쳐야 하는 단계입니다.. 왠줄 아십니까? 이 과정이 없다면, 감각적으로 리버싱이 가능하다라는 사실을 깨우칠수가 없거든요.. 반복된 디버깅 훈련이 실제로 루틴자체에 대한 이해가 전혀 없이도 점프 흐름에 코드 0x90 만으로도 프로그램 조작이 되더라는 사실을 몸소 체험해야 합니다. 그래야 나중에 자신이 루틴을 완벽하게 이해하는 상황이 되었을때 자신이 발전했따는 사실을 알수 있는거거든요.. 그리고, 그 경험을 해야만 자신이 정적분석을 해야할 필요가 있다라는 사실을 느낄수가 있고요.. 동적분석이 자신의 한계다라는 것을 이해하려면 동적분석이 뭔질 알아야 한다는 거죠.. 그런 후에 정적분석을 동적분석때 공부하던 반복훈련처럼 하게 된 이후에 정적분석의 한계를 느끼게 되면 그때가서야 동적분석을 정적분석의 이론으로 완벽하게 이해하면서 접목시키게 될 수 있는거죠.. 그렇게 되어야만 합니다. 그래야 나중에 가면 원래의 소스코드로 복원하는 능력이 생기는 겁니다. 리버스 엔지니어링의 끝.. 원본 소스코드로의 완벽한 복원.. 이것이 리버스 엔지니어링의 종착점입니다.. 순수학문으로써 종착역은 원본소스의 복원이죠.. 만약, 원본소스가 있다면 취약점 분석(?) 할 필요도 사실 없는거거든요.. 물론, 아직까지도 100% 원복이 되지는 않는게 현실이기는 하지만, 어디까지나 개념적으로 본다면 리버서의 종착역은 원본소스로의 복원입니다. 정의를 내리라면 그것이 되는 것이죠. 현실에서는 다양한 목적에 사용되지만 순수한 목적을 본다면 원본소스로 복원을 뜻하는 기술이 리버스 엔지니어링입니다.
    여튼.. 이런 내용들을 다 실고 싶었지만.. 이런 내용을 알고는 있지만 이런 내용들을 초보들이 입문서로 보는 책에 과연 필요하느냐라는게 작가들과 제 생각이 달랐던 겁니다.. 그래서.. 결국, 저는 이 책의 제작과정에서 빠지게 되었습니다. 그리고 출판되었죠.. 요즘 들리는 얘기로는 이 책이 리버스 엔지니어링 분야의 입문서로 거의 자리잡았다고 들리더군요.. 제가 틀렸던거 같습니다.. 역시, 초보자들은 초보적인 내용만으로도 충분한것 같습니다.. 굳이 그들에게 모든 것을 알려줄 필요는 없었던 건가 봅니다.. 어쩌면 한번에 너무 많은 것을 알려주면 포기하고 안할지도 모르겠지요.. 누군가는 더 많은 내용을 갈구할지도 모르겠죠.. 그땐, 리버스 엔지니어링 고급편 책을 사보면 되겠죠.. 언젠가 고급편이 나오겠죠.. 여튼.. 그런 연유였습니다. 나중에 혼자 책을 낼 생각을 했었는데.. 역시나.. 욕심을 너무 많이 부리면 책을 낼수가 없더군요.. 이제는 낼 수 있는 단계가 되었을까? 개인적으로 생각을 해보는데 여전히 아닙니다.. 아직도 저는 모자라다고 생각합니다.. Window31 님하고 같이 집필한다면 또 모르겠네요.. 서로가 의도나 생각의 차이나 이런게 일치만 한다면 부족한 부분들을 채우면서 낼수도 있겠죠.. 근데, Window31 님 프라이드도 워낙 쎄신 분이라 한국의 고유특성상 이뤄지기는 아마 힘들듯.. ㅋㅋㅋ 저도 좀 이런 부분에 있어서는 양보보다 고집이 강한 성격이라.. 부딪히면 깨질듯.. 여튼.. 이책은 그저.. 초보들이 말 그대로 입문서 그냥 흥미위주로 생각해야할 책입니다.. 개념정립을 하는 책이 아닙니다.. 개념정립을 해주고 싶지만.. 그들이 필요하다면 직접 자신의 발로 찾아다닐거라고 생각합니다.. 이 책을 너무 높이 보시지 않기를 바랍니다.. 이책은 아파치 설치 웹서버 운영 같은 서적 정도의 수준으로 작성되도록 처음부터 컨셉이 잡혀진 책으로 알고 있습니다. 고도의 뭔가를 알려주겠다고 작성한 책은 아님...

Reverse Engineering 강의.



사용자 삽입 이미지
 

모 대학 컴퓨터시스템학과 학생들을 대상으로 리버싱 강의 요청이 와서
모교도 아니고 아무 상관없는 사람이지만 어쩌다가 강의를 하게 되었습니다.
저같은넘이 대학강단에 서보다니 학생들의 불운이 시작될거라고 제 친구가 그러는군요 ㅎㅎ
(음 날짜가 어제였는데, 3/15로 되어있네 타이핑 미스 ;; )

3시간이 넘는 강의였는데 그래도 조는 학생들 한명 없이 눈도 똘망똘망하게 뜨고 잘 경청해줘서
감사 드립니다. 질문도 많이 해 주셔서 고맙고요.

강의자료와 사용 툴, 바이너리는(공격코드 제외) 교수님을 통해 전달해드리도록 하겠습니다.


신고
Posted by window31


댓글을 달아주세요

  1. 2008.03.23 13:44 신고
    댓글 주소 수정/삭제 댓글
    오오 대학강의!!
    저도 좀 해주세요 ㅋ_ㅋ)/
  2. 리미
    2008.03.23 14:12 신고
    댓글 주소 수정/삭제 댓글
    조는 사람이 없었다니, 대단한 명강의였나봅니다.+_+
    • 2008.03.23 21:42 신고
      댓글 주소 수정/삭제
      교수님이 뒤에서 눈을 부라리고 앉아있었기 때문에 아닐까요 ㅋ
  3. 2008.03.23 19:52 신고
    댓글 주소 수정/삭제 댓글
    멋지다~~
    담학기부터 고정으로 하면 좋겠다~~
    • 2008.03.23 21:49 신고
      댓글 주소 수정/삭제
      제가 머 정식 강사도 아니고 -_- 걍 필요할 때 쓰는 조커같은 겁니다. :p
  4. 2008.03.23 20:11 신고
    댓글 주소 수정/삭제 댓글
    세시간 씩이나.. 목이 많이 아프셨겠네요.
    전 1시간 정도 세미나만 해도 목이 아파서 걸걸해 지던데..
    자료는 비공개 인가요?
    • 2008.03.23 21:46 신고
      댓글 주소 수정/삭제
      네 중간에 한 십여분 쉬었어요 : )
      에피소드 하나,, 누군가 준비해준 얼음주스 마시면서 했는데, 중간에 한번 평소의 버릇처럼
      아무생각 없이 얼음을 입에 넣고 씹으며 "우둑우둑 자 그럼 이 코드를 보시면요...아 죄송합니다" OTL
      자료는 회사 인사팀 끼고 컨펌 받은거라 제 맘대로 뿌려도 되는지 모르겠네요 ;;
      (머 사실 별 내용 없기도 합니다 ㅋ)
  5. 2008.03.24 02:00 신고
    댓글 주소 수정/삭제 댓글
    와우~ 멋지십니다. ^^)/~
    부럽네요~ >ㅁ<;)/~
  6. 2008.03.24 14:32 신고
    댓글 주소 수정/삭제 댓글
    멋쟁이 당신~~ 떠나라~ =0=;;;
  7. sungmirr
    2008.03.25 05:54 신고
    댓글 주소 수정/삭제 댓글
    그날 강의 정말 최고였습니다. 말씀도 잘하시고, 강의 내용이 워낙 흥미로워서 3시간 넘는시간이 어떻게 갔는지도 모를 정도로 빠르게 갔네요. 정말 괜찮은 영화 한편 본 듯이 여운이 계속 남아요.ㅎㅎ 좋은 선물 감사드리고. 그날 수고많으셨습니다. 질문 너무 많이 해서 죄송하고요..복받으세여~ㅋㅋ
    • 2008.03.26 02:24 신고
      댓글 주소 수정/삭제
      네 어떤 분인지 알 것 같네요 ^^ 질문 많이 해주시면 고맙죠 ㅎㅎ
      좋게 들어 줘서 감사합니다.
  8. 익명의R
    2008.03.25 15:12 신고
    댓글 주소 수정/삭제 댓글
    분명 미모 때문에 안 졸았을꺼야..(중얼중얼)
  9. 2008.03.25 16:58 신고
    댓글 주소 수정/삭제 댓글
    오우~ 강의~~ 쵝오!
  10. kaline
    2008.03.25 21:28 신고
    댓글 주소 수정/삭제 댓글
    저도 그날 강의 들었는데요. 무척 재미있었어요.
    오히려 시간이 너무 빨리가서 아쉬웠다는...
    • 2008.03.26 02:23 신고
      댓글 주소 수정/삭제
      감사합니다 ^^ 지겹지 않았다니 다행이네요 ^^
  11. 2008.03.25 23:10
    댓글 주소 수정/삭제 댓글
    비밀댓글입니다
  12. 2008.04.07 17:19 신고
    댓글 주소 수정/삭제 댓글
    >ㅁ< 저도 들어보고 싶네요~
    부럽다 ㅠㅠㅎ
    • 2008.04.08 21:12 신고
      댓글 주소 수정/삭제
      다 아는걸 왜 들으려고 하는지 ㅋ
  13. 2008.09.23 19:16
    댓글 주소 수정/삭제 댓글
    비밀댓글입니다
  14. 2008.11.13 17:46 신고
    댓글 주소 수정/삭제 댓글
    오오오오~~~~~ 저희 고등학교에도 강의를(압박)

내가 제일 싫어하는 코드



핵 드라이버에서 종종 발견되는 코드
정말 이거 싫다
대책이 있을랑가 ㅋ
무슨 코드인지 알만한 분들은 다 아실겁니다 :p
머 이 드라이버 만든 사람도 제 블로그 보고 있을지 모르겟지만 ;;



사용자 삽입 이미지

신고
Posted by window31


댓글을 달아주세요

  1. 하루
    2008.02.19 19:29 신고
    댓글 주소 수정/삭제 댓글
    보자 마자 뒷골 땡김 -_-
  2. 2008.02.20 21:36 신고
    댓글 주소 수정/삭제 댓글
    허헛... 예전에 자주 썼던 코드군요. ^^;;; 왠지 반가웠다는... ㅎㅎ
    • 2008.02.22 18:21 신고
      댓글 주소 수정/삭제
      이런, 나쁜짓을 해보셨군요 ㅋ
  3. Dual
    2008.02.21 08:49 신고
    댓글 주소 수정/삭제 댓글
    ㅋㅋ Inline hook bypass같군요.
  4. 2008.02.22 15:19 신고
    댓글 주소 수정/삭제 댓글
    재밌네요 ㅋㅋ
  5. Dylan
    2008.02.24 01:51 신고
    댓글 주소 수정/삭제 댓글
    UDM 뜯어보신건가 ㅋ
  6. codediv
    2008.02.24 17:31 신고
    댓글 주소 수정/삭제 댓글
    후훗
  7. 2008.02.25 23:44 신고
    댓글 주소 수정/삭제 댓글
    싫어하실만합니다. ㅎㅎ
    • 2008.02.26 01:29 신고
      댓글 주소 수정/삭제
      블로그 잘 봤습니다 ^^
      OBT 잘하세요 !!
  8. 2008.10.16 21:19 신고
    댓글 주소 수정/삭제 댓글
    제가 생각해본 방법중의 하나로는, internal함수인 KiAttachProcess(); 함수를 후킹해서 protected 프로세스에 접근하려고 하면, 몰래 다른 프로세스로 redirect하는 방식으로 보호를 하면 어떨지 궁금하네요...
    • 2008.10.18 18:00 신고
      댓글 주소 수정/삭제
      Ki 도 + 5 하면요? ^^;
    • 2008.10.18 19:57 신고
      댓글 주소 수정/삭제
      KiAttachProcess()는 바로 호출하면 시스템이 크래쉬되더군요...

      중간에 무슨 CRITICAL_SECTION 개체를 lock하던데...(?) lock 하는것도 undocumented함수라...

      조금 더 힘들겠지요 ㅋㅋ
    • 2008.10.19 05:14 신고
      댓글 주소 수정/삭제
      호출 방법에 문제가 있던 게 아닐까요?
      Ki 를 바로 호출하는 넘을 여러번 봤는데 ^^;
  9. 2008.10.16 21:20 신고
    댓글 주소 수정/삭제 댓글
    N모사의 보안 솔루션에서는 code 블럭 자체를 옮겨버리는 것 같던데...
    조금 무섭네요 ^^;
    • 2008.10.18 18:00 신고
      댓글 주소 수정/삭제
      무섭죠 ^^; n모사에서 어떻게 하는지는 모르겠네요
    • 2008.10.18 19:58 신고
      댓글 주소 수정/삭제
      retn(0xC3) 블럭 까지를 전부 코드를 다른 메모리에 옮겨버린 후, JMP를 후킹 함수로 지정해버리더군요. 우회하지 못하도록...
    • 2008.10.19 05:16 신고
      댓글 주소 수정/삭제
      네 그렇게 해도 위 스타일의 방법은 막을 수가 없는데요 ㅎㅎ
    • 2008.11.13 17:48 신고
      댓글 주소 수정/삭제
      JMP뒤의 코드는 전부 0xCC로 바꿔버리면 우회할 수 없을 것으로 생각됩니다...
    • 2008.11.13 21:46 신고
      댓글 주소 수정/삭제
      연구용으로는 그런 시도를 해볼 수도 있겠지만
      실전에서는 그런 구조로 개발을 할 수가 없어요
      여기를 나만 후킹하고 나만 사용한다면 이런처리가 가능하겠죠.
      연구가 입장에서 왜 그건 이렇게 안하나? 라고 생각하는 상당히 많은 것들을
      현업 개발자들이 몰라서 안하는게 아닙니다. 필드에서는 적용할 수 있는 기술이 있고
      결코 건드려서는 안되는 부분이 존재합니다.
      왜냐면 클라이언트는 너무도 다양하니까요.
      그리고 나랑 똑같은 생각을 가진 똑같은 기술을 만드려는 개발자도 넘쳐나고요.
      10만명의 유저중 10명의 해커를 막으려고 한 짓이
      정상적인 1만명의 실행을 방해할 수도 있습니다.
    • 2008.11.14 00:29 신고
      댓글 주소 수정/삭제
      결국, 제일 마지막 방법이 방법론적에서는 최강임에도 불구하고, 후방 호환성과 안정성을 고려하고 시장성과 효율성에 비추어볼 때, 그 방법을 사용할 수 없는 것이군요.

      말씀을 듣고나니 추가적으로 궁금한 것이 생겼는데요. 그렇다면 이미 GG나 HackShield같은 게임 보안 솔루션을 보면 하나같이 후킹을 하면 죄다 강제 재부팅과 같은 증상을 보이는데, 그런 경우엔 어차피 보안 솔루션 혼자 후킹해서 먹고 살겠다는 거니 마지막 방법을 써도 되는것이 아닌가요? (실제로 GG의 경우 함수의 끝 부분인 RET 명령어 까지의 Code Snippet을 다른 메모리에 옮긴 후, 실제 함수의 첫 부분에 JMP를 삽입시켜두고, 첫 부분을 제외한 RET명령어까지의 부분을 쓰레기 바이트로 채우는것 같더군요. - 이는 제가 위에서 언급한 방법에서 0xCC로 채우는 것을 쓰레기 바이트로 채우는 것이 다를 뿐, 본질적으로 같은 방법으로 보여집니다.)
    • 2008.11.14 01:18 신고
      댓글 주소 수정/삭제
      네. 그래서 처음 그 기술을 만들었을 때 수많은 프로그램들과 문제가 불거졌고
      핵을 쓰지도 않는데 문제가 계속된 애꿎은 유저들만 고생을 했습니다.
      그리고 그 부분은 지금도 논쟁이 되고 있는 것 중 하나고요
      GG가 다른 보안회사들에게 욕을 겁나게 들어먹고 있는 이유에도 포함이 됩니다.
      혼자 먹고 살겠다고 해놓은 그 기술을 아직도 사용하고 있는 이유는
      공개적인 자리에서 남의회사 사정을 밝힐수는 없고,
      (머 비공개적인 자리에서도 얘기할 생각은 없습니다)
      이 업계에서 직접 일을 해보시거나
      아니면 그 회사에 입사해보시면 알 수 있을것 같네요.
      HackShield는 혼자 먹고 살수는 없다고 판단하여 그 부분을 해제시켜놓은 것으로 알고 있습니다.
      그리고 JMP뒤의 코드를 0xCC로 바꿨는데 다시 해커가 바꿔버린다면 어떻게 하시겠어요?
      다시 또 0xCC로 바꾸실건가요? 또다시 해커가 바꾸면요?
      저는 사실 이런 논쟁은 별로 좋아하지 않습니다.
      끝이 없기 때문이죠.
      그리고 어떤 것도 최강의 기능은 없다고 생각합니다

의심 드라이버 발견




저는 컴터를 쓰다가 하루에도 여러번씩 내 컴터에 깔린 커널 드라이버 리스트를 확인합니다.
드라이버를 은밀하게 깔아서 할 수 있는 짓이 워낙 많다 보니.. 저 또한 피해자의 예외대상은
아니라고 생각되어 걍 머 버릇처럼 확인하고 있습니다.

그런데 오늘 출근해서 보니 vzthni.sys 라는 묘한 드라이버가 올라와 있더군요 -_-
파일 날짜를 보니 어제 퇴근 시간 직전 시간입니다.
어떤 개쉑이 내 PC에 기 들어와서 이상한거 깔아놓은건가 하는 압뷁에 순간 혼미해지더군요
저희가 짱개들로부터 해킹 공격을 하도 많이 받다 보니 그런 생각이 더했습니다.
그리고 제 PC는 워낙 음흉한 자료가 많다보니 ㅎㅎㅎ 더 심장이 조여오더군요 -_-

일단 바이러스 토탈에 먼저 넣어 봤습니다.

사용자 삽입 이미지

2개 백신에서 걍 오진인지 휴리스틱의 원인인지 암튼 의심스럽다 정도만을 내뱉는거 빼고는
아주 깔끔합니다 -_-

사실 깔끔해서 더 무섭더군요.
보통은 세상에 등장하지 않은 갓 태어난 싱싱한 바이러스에게 공격당하는 경우가 많거든요.
그 경우는 백신이 당연히 본적이 없는 바이러스이기 때문에 진단이 되지 않는것은 당연하고요 -_-

아무튼 드라이버를 얼른 뜯어 봤습니다.
크기도 상당히 크고, 의심스러운 짓을 너무나 많이 하더군요.

노티파이 루틴이 있어서 새 프로세스 생성도 감지하고 있고
그리고 SDT 도 건드리고 있는데, 테이블을 후킹하는게 아니고 오버라이트 훅을 하더군요
루트킷 디텍터에 걸리지 않으려고 아주 지대로 만들었군 하는 생각에 더 두려움에 떨었습니다....;
TCP접속도 체크하더군요.
난 완전 당한거야 무슨 파일들이 나갔을까 떨면서 IDA를 계속 보고 있는데
뭔가 이상합니다....

어디서 언젠가 본 드라이버 같아요.....

다시 한번 잘 뜯어보았습니다...
그리고 어제 퇴근시간 전에 실행했던 프로그램들을 생각해 보았습니다..

아악!!!! 하는 생각이 온몸에 휘감으면서
드라이버의 PE Header를 살펴보았습니다.
그리고 얼른 어떤 프로그램을 띄워서 그 프로그램의 드라이버를 로딩시킨 후
WinHex Kernel로 그 프로그램의 PE를 보았습니다...


오........이런....


File name : C:\Documents and Settings\window31\바탕 화면\vzthni.sys

== File Header ==
Machine              : 0x14C (Intel 386)
NumberOfSections     : 0x5
TimeDateStamp        : 0x46919405 (Mon Jul 09 10:48:53 2007)



사용자 삽입 이미지


두 드라이버의 타임스탬프를 비교해니 아주 명확하죠? (0x05 0x94 0x91 0x46)
vzthni.sys 의 범인은 IceSword의 드라이버였습니다 -_-

생각해보니 어제 퇴근시간 직전에 뭔가 확인해 볼 것이 있어서 IceSword를 실행했는데
이상하게 잘 실행되지 않고 좀비 상태로 멈췄길래 다시 한번 더 실행했던 기억이 나네요.
그때 오리지날 파일명인 IsDrv112.sys로 올라가지 않고 이상한 이름으로 드라이버가
로드되었던 것 같습니다.

IceSword가 실행될때 ㅄ이 되면 드라이버를 다른 이름으로 바꿔서 재 로드를 시도하는
코드가 있나 봅니다. 메인 exe는 아직 뜯어보지 않아서 더 구체적인 내용은 모르겠네요.

암튼 이상한 드라이버 때문에 십년 감수 했다는 -_-

아침부터 삽질 좀 했네요 ;;
머 덕분에 아이스스워드의 오리지날 드라이버 파일을 깔끔하게 획득 했습니다만 :p



걍 회의들어가기 전에 시간이 애매하게 남아서 끄적거려봤습니다.



(참고, IceSword의 드라이버는 로드시킨후 지워버리기 때문에 메모리에서 보아야 합니다
그래서 WinHex Kernel을 사용했습니다)


window31. 2008년 2월.

신고
Posted by window31


댓글을 달아주세요

  1. 2008.02.14 12:39 신고
    댓글 주소 수정/삭제 댓글
    오오오~~!! 유용한 WinHex Kernel? :D
  2. 2008.02.14 13:59 신고
    댓글 주소 수정/삭제 댓글
    우왕ㅋ굳ㅋ... 드라이버를 순식간에 분석하시는 ~_~)
    WinHex Kernel의 장점을 알 수 있는 포스팅이로군요
  3. 2008.02.14 18:06 신고
    댓글 주소 수정/삭제 댓글
    난 가끔 내가 만든 것 가지고 삽질한 경우도 있었는데...
    그정도는 애교로..ㅎㅎㅎ
    • 2008.02.15 18:18 신고
      댓글 주소 수정/삭제
      ㅎㅎ 자기가 깐 드라이버도 몰랐단 말야?
  4. 2008.02.15 09:05 신고
    댓글 주소 수정/삭제 댓글
    가짜 아이스워드도 있답니다.

    참고

    http://viruslab.tistory.com/100
    • 2008.02.15 18:19 신고
      댓글 주소 수정/삭제
      ㅎㅎㅎ 항상 좋은 정보 잘 보고 있어요

리버스 엔지니어링은 어디까지 지켜보아야 할까...




리버스 엔지니어링은 어디까지 지켜보아야 할까...
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월


 

신고
Posted by window31


댓글을 달아주세요

  1. 2008.01.29 00:15 신고
    댓글 주소 수정/삭제 댓글
    워.. 잘하시면서 =ㅅ=;; 너무 겸손하십니다 :)

    그나저나 상당히 공감이 가는 포스팅이네요...
    저도 개뿔도 없기때문에 머 공개할거리도 없지만 말이죠 ㅋ

    그나저나 IRP Hook이라... MBR Rootkit 인가요 'ㅅ'?

    뭐가 되었든 완전 기대하고 있을게요..

    그나저나 술한잔은 언제쯤.. ?
    • 2008.01.29 09:41 신고
      댓글 주소 수정/삭제
      네 MBR Rootkit 도 원리는 같습니다.
      다만 후킹하는 펑션 테이블이 좀 다르죠.
      사실 이게 왜 이제서야 잇슈가 되었나 싶기도 해요..
      IRP Hook 때문에 저희는 작년에 고생 좀 했거든요..
      (백신들이 아무도 못 캐취해내길래..)
      머 그래서 찌라시 툴을 하나 만들긴 했지만..
      (하하 술한잔은 조만간)
  2. 2008.01.29 04:23
    댓글 주소 수정/삭제 댓글
    비밀댓글입니다
    • 2008.01.29 09:42 신고
      댓글 주소 수정/삭제
      네 머 비밀댓글로 하실 것 까진 없는데 ^^
      답장 써드렸습니다.
  3. 2008.02.01 18:12 신고
    댓글 주소 수정/삭제 댓글
    마소 기고글 잘 읽었삼~
    리버싱을 해본지가 꽤 오래전 일이라 어렵게 느껴지네.

    구정 잘 보내삼~
    • 2008.02.01 23:37 신고
      댓글 주소 수정/삭제
      어려웠나? 내가 내용 표현을 잘 못한거구만 ㅠ ㅠ
      응 구정 잘 보내게
  4. 2008.02.03 02:01 신고
    댓글 주소 수정/삭제 댓글
    와우~ 마소 1월호에 실린 기사의 주인공이시군요. @0@)/~ 깜짝 놀랐습니다. 글을 아직 읽어보진 못했지만 좋은 내용인 것 같던데... 시간나면 꼭 읽어보겠습니다. 멋지십니다. ^^)/~
    • 2008.02.03 23:45 신고
      댓글 주소 수정/삭제
      ㅎㅎ 까마귀님 연재물이 더 멋져보이던데요
  5. 2012.02.13 04:15 신고
    댓글 주소 수정/삭제 댓글
    Great website. Nice posting comments system. I am sorry for the off-topic post, nonetheless I had been pretty pleased with Djokovic\'s play in the final of the Australia OPen this year. The guy is simply unequalled. He proved he was as powerful as iron. Simply imagine about he he can whip Nadal who had previously been so encouraged to succeed as well as was really so excited up while in the 5th set. I\'m commencing to consider that Djokovic is performing some religious work to bring some forces on his side which help him win such matches up against the greatest players in the entire world. Whatrrrs your opinion in relation to Rafa's game?

HexRay 정말 물건이네요...



IDA 5.2 + HexRay를 어둠의 경로에서 구해서 한번 써봤습니다.
완전 장난아니군요 -_-

IAT Hook을 하는 소스를 HexRay로 돌려봤습니다.




사용자 삽입 이미지

놀랄 노자죠 ㅎㅎ
이정도면 머 거의 소스나 다름없죠 -.-
그간 왤케 고생해서 디스어셈블링을 공부한거지요 ㅎㅎ

일단 이 소스에서 간단히 파악할 수 있는 프세이드 코드로 변환될때의 특징은
1) 초반 코드로 사용되는 파라메타 검증 if문은 goto로 해석한다는것
    (하지만 머 위의 코드를 goto로 구현해도 실제로 컴파일러는 비슷하게 빌드해주니 별 상관없음)

2) 구조체에 대한 타입캐스팅은 이루어지지 않는다는거
    (머 되는 넘도 있겠죠? 하지만 일단 PE 쪽 구조체는 안 나오네요 ㅎㅎ)

3) 일부 멤버 변수는 걍 상수로 나와버립니다. 포인터로 바로 계산을 해버리는듯

4) 그냥 16진수로 표시해주는게 어떨까 하는 생각이 드는데... 23117 을 보고 한참 생각했다는 -_-
   (아시다시피 pIDH->e_magic 은 PE의 표식을 알려주는 MZ Header 값이죠)


어쨌든 헥스레이 정말 물건이네요
이걸로 상당한 시간절약을 할 수 있을 것 같습니다.
헥스레이 개발자.......정말 천재입니다.....감탄 !

신고
Posted by window31


댓글을 달아주세요

  1. 2008.01.09 15:03 신고
    댓글 주소 수정/삭제 댓글
    흐음.. 저도 써봤습니다 :)
    일반 어플이나 코드는 잘 나오더군요.
    게다가 RECStudio 보다 안정적이지만 아주 유사한 코드가 나오더군요.
    일단 IDA 를 사용하는 주 목적인 전체 흐름 보기에는 참 좋은것 같은데
    이게 악성코드에다가 대응시키게도면... IDA가 못읽는애들이 많아서 ㅠ_ㅠ)
    • 2008.01.10 14:24 신고
      댓글 주소 수정/삭제
      RECStudio저도 그닥 맘에 안 들던데 ㅎㅎ
      근데 IDA가 왜 못 읽어요? 프로텍팅 되어 있어서?
  2. 2008.01.09 16:41 신고
    댓글 주소 수정/삭제 댓글
    최신 기대작! 동영상으로 봐서는 잘모르겠던데...ㅎ
    나도 어둠의 경로에서 기웃거려봐야 겠삼..
    • 2008.01.10 14:24 신고
      댓글 주소 수정/삭제
      근데 경우에 따라 네트워크 락 걸려있는 넘들이 있음.
      같은 망 안에서는 1PC밖에 못 쓰는...
  3. s
    2008.01.10 07:49 신고
    댓글 주소 수정/삭제 댓글
    아직도 자고 있겠군요.ㅋㅋ
    부러운 회사를 다니시네요^^
    • 2008.01.10 14:25 신고
      댓글 주소 수정/삭제
      우리회사가 정상이고 너희 S사가 너무 빠른거야-_-
  4. 2008.01.10 13:25 신고
    댓글 주소 수정/삭제 댓글
    -_+ 물건이죠... 그래도 디스어셈블이 더 로망이 있다랄까요?ㅎㅎ
    • 2008.01.10 14:25 신고
      댓글 주소 수정/삭제
      ㅎㅎ 그쵸 헥스레이는 뭔가 반칙 같다는 ;
      정정당당한 대결을 위해서는 순수 디스어셈블링으로 ㅋ~
  5. 앞선이
    2008.08.02 10:52 신고
    댓글 주소 수정/삭제 댓글
    이런 희한한 도구도 있는가,,
    IDA5.2 + HexRay 좀 올려주세요,,
    저도 한번 써보고 싶은데,, 어떻게 구입해야 할지..
    부탁드립니다.

BLOG main image
by window31

카테고리

분류 전체보기 (285)
Reverse Engineering (22)
C, C++ (20)
Kernel (8)
Guitar (19)
잡담 (79)
etc (8)
who am i (8)
보안 이야기 (89)
Tools (3)
월간 마이크로소프트웨어/그.. (28)

글 보관함