SanseoLab

0. 개요

  이 문서에서는 리눅스 안티바이러스에 대한 내용을 정리하기로 하겠다. 사실 그나마 흔한 윈도우 기반 안티바이러스에 대해서도 제대로 알지 못하지만 공부하며 찾아본다는 의미로 이 문서를 만들고자 한다. 리눅스도 윈도우와 마찬가지로 안티바이러스와 관련된 대부분의 자료들이 사용자 모드에서 실행되는 on-demand 형태의 시그니처 기반 스캐닝 위주로 존재한다. 여기서는 실제 상용 리눅스 안티바이러스 제품에서 사용될만한 기술들을 최대한 찾아보며 정리하고자 한다.

  먼저 파일 스캐닝과 관련된 내용을 정리하겠다. 앞에서 언급하였듯이 on-demand 형태의 사용자 모드 시그니처 기반 스캐닝은 윈도우와 비슷하기도 하고 이미 자료가 많이 있기 때문에 언급하지 않기로 하고 바로 실시간 파일 스캐닝 기법을 다루기로 한다. 다행히도 리눅스에서는 최근 fanotify라는 메커니즘이 제공되어 파일 실행 및 종료, 수정 등의 이벤트에 대한 알림 및 승인, 거부도 간단한 방식으로 가능해졌다. 윈도우의 경우에는 파일 시스템 미니필터 드라이버가 제공되서 필터 관리자를 통한 메커니즘이 제공된다.

  이후에는 프로세스 생성 감시 메커니즘을 다룬다. 윈도우의 경우에는 PsSetCreateProcessNotifyRoutineEx() 등의 함수들이 제공되어 프로세스나 스레드 생성 시에 콜백 루틴을 등록해줄 수 있으며 생성되는 프로세스의 정보 획득 및 생성의 승인 또는 거부를 선택할 수 있다. 관련 내용을 리눅스에서 찾아보았는데 아직 윈도우에서 제공되는 형태와 같은 메커니즘이 제공되어 있지 않다. 그래서 관련 사항들을 최대한 찾아본 결과 리눅스 보안 모듈 (LSM : Linux Security Module)을 이용한 방식이 가장 적합한 것으로 보인다. 다른 몇몇 방법들이 있긴 하지만 프로세스 생성 이전에 통지받고 동시에 생성을 거부할 수도 있는 방법은 이 방법밖에는 없어보인다.

  마지막으로 자가 보호 방식에 대해서 설명하고자 했지만 적절한 방식을 찾지 못하고 위에서 언급한 LSM을 이용한 방식을 소개한다. 구체적으로 grsecurity의 소스 코드를 분석하여 자가 보호를 제공하는 방식을 공부한다. 이 외에도 실제 안티바이러스 소프트웨어에서 사용되는 방식은 더 많이 존재하고 리눅스 자체적으로 제공하는 것이 한계가 있기 때문에 대부분 직접 구현되어 있을 것이다. 더 자세한 설명 그리고 추가적인 사항을 공부하면서 꾸준히 이 문서를 업데이트할 것이다.

1. 실시간 파일 스캐닝

  파일 스캐닝 기법에는 on-demand 스캐닝과 on-access 스캐닝이 존재한다. on-demand 스캐닝은 사용자가 검사 버튼을 누르거나 주기적으로 검사 스케줄을 정했을 때 수행되는 스캐닝이다. 일반적으로 인터넷에 퍼져 있는 안티바이러스 소스 코드들을 보면 대부분 시그니처 기반에 이러한 on-demand 스캐닝 방식이다. 이 방식은 전체 또는 지정된 범위에 존재하는 파일들을 모두 검사하는 방식으로서 특별한 지식이 필요하거나 난이도가 높거나 하지는 않으며 관련 자료들도 이미 충분히 존재한다. 물론 대부분 윈도우 플랫폼에서의 자료겠지만 리눅스 플랫폼에서도 충분히 존재한다고 생각한다.

  여기서는 on-access 스캐닝을 다룰 것이다. 이 방식은 실시간 검사라고도 불리는데 파일이 여러 이벤트를 통해 생성되었을 때 실시간으로 검사하는 것이다. 예를들어서 취약점을 이용해 악성코드 바이너리를 다운로드시킨다거나 드로퍼가 악성코드를 드롭시켜서 악성코드 바이너리가 생성되었을 때 이 파일을 검사한다. 당연히 이러한 방식을 사용하기 위해서는 파일 생성 이벤트가 발생하였을 때 알려주는 메커니즘이 필요할 것이다. 이 항목에서는 리눅스에서의 관련 메커니즘과 함께 on-access 스캐닝 기법을 다루기로 한다.

  먼저 그나마 조금 더 대중적인 윈도우의 메커니즘을 먼저 예시로서 설명한 후에 리눅스로 나아가기로 하겠다. 윈도우도 앞에서 설명한 on-demand 스캐닝 및 on-access 스캐닝 기법이 나뉜다는 것은 당연한 이야기일 것이다. 윈도우의 경우에는 on-access 스캐닝을 위하여 즉 안티바이러스 소프트웨어를 위하여 제공되는 메커니즘이 존재한다. 먼저 윈도우에서는 과거 루트킷처럼 (파일 생성 등과 관련된) 관련 함수들을 후킹하는 드라이버를 만들어 on-access 스캐닝을 수행하였다. 하지만 최근에는 커널의 구성 요소인 필터 관리자에 의해 관리되는 파일 시스템 미니 필터 드라이버를 개발하여 이러한 기능을 제공할 수 있다. 파일 시스템 미니 필터 드라이버에서는 여러 제공되는 함수들을 통해 파일 생성 등의 이벤트를 통지받고 또한 특정한 행위를 수행할 수 있다. 물론 안티바이러스의 경우에는 이 특정한 행위란 생성되는 파일에 대한 검사일 것이다.

  리눅스의 경우에는 비슷한 메커니즘이 존재한다. 과거 dnotify부터 inotify를 거쳐 현재는 fanotify가 존재한다. 여기서는 dnotify는 제외하고 inotify부터 설명해보도록 하겠다.

1.1 inotify

  inotify는 리눅스 커널에서 제공되는 기능으로서 디렉토리 및 파일을 감시할 수 있다. 참고로 디렉토리를 감시할 경우에는 디렉토리 자체 및 내부의 파일이 변경되는 이벤트에 대한 정보도 받을 수 있다. 이 메커니즘은 리눅스 커널에서 CONFIG_INOTIFY와 CONFIG_INOTIFY_USER를 설정해야 사용할 수 있는 커널 컴포넌트이다. 참고로 특정 디렉토리를 감시 대상에 추가한 경우에 내부에 존재하는 디렉토리까지 감시 대상에 추가되지는 않는다. 즉 recursive하지 않기 때문에 디렉토리 내부에 새로운 디렉토리가 생성되거나 삭제되는 경우를 위한 추가적인 메커니즘이 필요하다.

  다음으로는 inotify를 사용하는 방식 및 구성에 대해서 알아보겠다. 아주 간단한 예제를 통해 설명해 보자면 가장 먼저 inotify_init()을 호출하는데 이 함수는 inotify 인스턴스를 생성하는 역할을 하며 우리는 이 함수에서 반환된 file 디스크립터를 통해 생성된 inotify 인스턴스에 접근한다. 이후 감시할 대상의 경로 및 감시할 이벤트를 인자로 넣고 inotify_add_watch()를 통해 watch list에 추가한다(반대로 삭제하는 함수는 inotify_rm_watch()이다). 이 함수는 유니크한 watch 디스크립터를 반환하는데 이것은 뒤에서 사용될 것이다. 어쨌든 이후 반복문을 사용하여 주기적으로 read()를 통해 file 디스크립터를 읽는다. read()로 inotify_event 구조체를 읽을 수 있고 여기에는 여러 정보들이 들어있다.

  앞에서 inotify_add_watch()의 인자로 감시할 이벤트를 넣는다고 언급하였다. 파일과 관련된 이벤트는 여러 종류가 있지만 많이 사용되는 이벤트들은 다음과 같다. 파일이 read() 등의 함수를 통해 접근된 경우에는 IN_ACCESS 이벤트가, 감시 대상 디렉토리 내에 파일이나 디렉토리가 생성된 경우에는 IN_CREATE, 삭제된 경우에는 IN_DELETE, 감시 대상 파일 또는 디렉토리 자체가 삭제된 경우에는 IN_DELETE_SELF 이벤트가 발생하며 파일이 수정된 경우에는 IN_MODIFY, 파일이 오픈된 경우에는 IN_OPEN 이벤트가 발생한다. IN_ATTRIB 이벤트는 파일의 권한, 소유자, UID, GID 등의 정보가 수정되었을 때 IN_MOVE_SELF는 대상의 이름이 변경되었을 때 (즉 이동하였을 때) 발생한다. 마지막으로 IN_MOVED_FROM과 IN_MOVED_TO 이벤트는 감시 대상 디렉토리 내부의 파일이나 디렉토리 이름이 변경(이동)되었을 때 발생하는데 원본 파일에서는 IN_MOVED_FROM이 발생할 것이고 변경된 이름의(이동 후의) 파일에서는 IN_MOVED_TO가 발생할 것이다.

  위에서는 inotify_add_watch()를 통해 감시할 이벤트를 넣어주었는데 이후 read()를 통해 얻은, 즉 특정 이벤트가 발생한 경우에 얻는 이벤트도 동일하다. read()를 통해 얻는 데이터는 inotify_event라는 구조체인데 이 구조체에는 앞에서 설명했듯이 발생한 이벤트 및 이벤트가 발생한 watch 디스크립터 등의 값이 존재한다. watch 디스크립터를 굳이 알려주는 이유는 동일한 file 디스크립터를 통해 여러 대상을 감시할 때 필요하기 때문이다.

1.2 fanotify

  앞에서는 간략하게 inotify를 살펴보았다. 이것을 통해 우리는 파일에 관련 이벤트가 발생한 경우 이를 통지해 주는 메커니즘을 사용할 수 있다는 것을 알게되었다. inotify는 많은 이벤트들에 대한 모니터링이 가능하지만 단점도 존재하는 것이 recursive한 모니터링이 불가능했고 또한 이벤트가 발생하였다는 통지 이외에는 제공하는 기능이 없었다. inotify와 비교하여 장단점이 존재하는 fanotify를 살펴보겠다.

  fanotify도 inotify와 비슷한 부분이 많다. 이 메커니즘도 리눅스 커널에서 CONFIG_FANOTIFY를 설정해야 사용할 수 있는 구성 요소이다. 또한 뒤에서 나오겠지만 권한과 관련된 처리가 필요할 때가 있는데 이것은 CONFIG_FANOTIFY_ACCESS_PERMISSIONS를 설정해야 한다.

  이번에는 fanotify를 사용하는 방식을 알아보겠다. 이것도 비슷하게 fanotify_init()을 통해 fanotify group을 초기화하고 이 함수는 이 인스턴스와 연관된 file 디스크립터를 반환한다. 이 file 디스크립터는 inotify에서 inotify_add_watch(), inotify_rm_watch()와 비슷한 역할을 하는 fanotify_mark()에서 사용된다. 이 함수는 이것 외에도 flags, mask, 경로명 등의 인자를 받는데, 경로명은 당연히 감시 대상의 경로명을 의미할 것이고 flags는 FAN_MARK_ADD, FAN_MARK_REMOVE, FAN_MARK_FLUSH가 있다. FAN_MARK_ADD는 감시 대상에 대해 감시할 이벤트들을 추가한다는 것이고 FAN_MARK_REMOVE는 삭제, FAN_MARK_FLUSH는 전체 삭제를 의미한다. 이 3가지 중 적어도 하나는 필수이며 OR ( | )를 통해 다른 flag들이 추가될 수 있다. FAN_MARK_IGNORED_MASK는 mask에 설정된 이벤트들을 감시가 아닌 무시할 때 사용된다. 또한 FAN_MARK_MOUNT는 경로명에 지정된 마운트 포인트를 설정한다. 즉 마운트 포인트인 경로명 내의 서브디렉토리들까지 감시에 추가해주는 recursive한 모니터링 메커니즘을 제공한다.

  마지막으로 mask는 inotify와 마찬가지로 앞에서 언급한 감시할 이벤트들이다. FAN_ACCESS는 접근 즉 read된 경우에 발생하며 FAN_MODIFY는 수정 즉 write된 경우에 발생한다. FAN_OPEN 및 FAN_CLOSE는 각각 파일 또는 디렉토리가 open, close되었을 때 발생한다. FAN_OPEN_PERM과 FAN_ACCESS_PERM 이벤트는 파일 및 디렉토리를 각각 open 또는 read할 경우에 권한이 요구될 때 발생한다. 정확히 말하자면 파일이 열리기 전에는 FAN_OPEN_PERM, 닫힌 후에는 FAN_CLOSE_WRITE 이벤트가 발생한다.

  이제 모니터링이 제공되고 감시 대상 파일이나 디렉토리에서 이벤트가 발생할 것이다. 이것도 inotify처럼 read()를 통해 읽는데 정확히는 fanotify_event_metadata 구조체가 생성된다. 이 구조체에는 발생한 이벤트들 외에도 open file descriptor, 이벤트를 발생시킨 프로세스의 pid 등 여러 정보가 존재한다. 

  발생하는 이벤트는 두 종료가 있는데 Notification 이벤트와 Permission 이벤트가 그것이다. Notification 이벤트들은 inotify의 경우처럼 정보를 제공해 주며 Permission 이벤트들은 파일 접근에 관한 권한을 결정해 줘야 한다. 이 이벤트들은 앞에서 설명한 mask와 거의 같다고 보면 된다. 특이사항으로는 Permission 이벤트들 즉 FAN_ACCESS_PERM, FAN_OPEN_PERM 이벤트는 반드시 write()를 통해 응답을 보내야 한다는 것이다. fanotify_response() 구조체를 생성하여 fanotify file 디스크립터에 write()를 통해 응답을 보낸다. 응답은 이 구조체의 response 멤버에 FAN_ALLOW 또는 FAN_DENY 값을 설정하는 것이다.

1.3 정리

  여기서는 inotify와 fanotify를 비교하면서 정리하겠다. 둘을 살펴보면서 확인한 공통점들이 많기 때문에 기본적인 정보는 생략하고 차이 위주로 설명하겠다. 먼저 recursive한 모니터링을 제공한다는 점과 이벤트 통보 이외에도 접근 통제 즉, 접근의 허용 여부를 결정할 수 있다는 점에서 fanotify의 장점이 크다는 것을 알 수 있다. 이 접근 통제는 특히 안티바이러스에서 유용하게 사용될 수 있는 기능이다. 또한 fanotify_event_metadata 구조체를 보면 이벤트를 발생시킨 프로세스의 PID 및 open file descriptor가 제공된다. open fd를 통해 감시 대상 파일의 내용에도 접근할 수 있다.

  하지만 fanotify에서는 제공하지 않는 inotify만의 장점도 존재하는데 fanotify에서는 inotify보다 제한된 이벤트들을 감시할 수 있다. 즉 inotify에서는 지원됬었던 create, delete, move(rename) 이벤트에 대한 감시는 지원되지 않는다. 

2. 프로세스 생성 감시

  앞에서도 설명하였듯이 리눅스에서는 프로세스 생성 및 종료 등 프로세스의 상태와 관련된 모니터링 메커니즘이 존재하지 않는다. inotify를 통해 /proc을 모니터링하는 것은 불가능하고 proc connector 방식도 fork나 exec 같은 프로세스 이벤트를 알려주기만 할 뿐이지 이벤트 실행 이전에 통지함과 동시에 생성을 거부할 수 있는 메커니즘은 아니다. 그래서 결국 리눅스 보안 모듈을 이용한 방식을 선택하고 설명하고자 한다. 하지만 이 방식이 안티바이러스에서 실제로 사용될 수 있는지 즉 오버헤드를 감당할 수 있는지에 대해서는 모르겠다. 물론 다른 여러 방식으로 사용되고 있기 때문에 확실한 자료 없이 정리하기로 한다.

2.1 LSM

  리눅스 보안 모듈(LSM)이라고 하면 일반적인 모듈이라고 생각할 수 있는데 사실 설명이 필요한 부분이다. 과거 리눅스라는 운영체제에서 보안을 구현할 수 있는 방식으로서 선택 사항은 두 가지가 있었다. 하나는 커널 수정 방식이며 다른 하나는 LKM(Loadable Kernel Module) 즉 탑재 가능한 커널 모듈 방식이었다. 보안을 커널에 집적 구현하는 것과 모듈에 구현하는 것은 각각의 장단점이 명확했다. 리눅스 보안 모듈이라고 하면 LKM 형태로 구현된 보안 모듈이라고 생각하기 쉽지만 사실은 조금 다른 개념이다. 

  정확히 설명하자면 LSM은 여러 종류의 보안 정책 모듈들을 위하여 일반화된 framework를 제공하는 방식이다. 즉 리눅스 커널에서는 framework만을 제공하는 방식으로서 커널에 인터페이스를 만들고 이 인터페이스를 통해 써드 파티 보안 모듈들의 접근 제어 메커니즘과 커널을 연결시킨다. 많이 들어봤겠지만 SELinux, AppArmor, Smack, TOMOYO Linux 등이 공식적으로 리눅스 커널에 받아들여진 보안 모듈들이다.

  조금 더 자세히 보자면 리눅스 커널의 소스 코드 중에서 security.c가 LSM을 구현한 것이라고 보면 된다. 우리는 LSM에서 구현된 인터페이스를 통해 보안 정책 모듈을 만들 수 있다. 실질적으로 LSM은 커널이 내부 객체에 접근을 시도하기 직전에 Hook을 걸어 보안 모듈로 우회시킨다. SELinux나 AppArmor 등의 보안 모듈들은 원하는 부분에 콜백을 등록하여 보안 정책을 구현한다.

2.2 LSM을 이용한 프로세스 생성 모니터링

  앞에서는 개념만 설명하였기에 예를들어 설명해보겠다. 다음 링크 [ https://github.com/skx/linux-security-modules ]의 개발자는 LSM을 이용한 간단한 보안 모듈을 만들었다. 이 중에서 whitelist라는 예제를 보면 실행 파일 중에서 특정한 속성을 가진 바이너리만 실행 가능하게 만들려고 한다. 이 경우 여러 설정들은 생략하고 security_add_hooks() 함수로 bprm_check_security에 hook을 설치한다. 참고로 리눅스 커널 버전 4.1부터 security_add_hooks()라는 함수가 사용되고 있으며 그 이전에는 register_security()를 이용한 방식을 사용하였다. 또한 bprm_check_security라는 hook은 자세히 살펴보면 (CONFIG_SECURITY 커널 컴파일 옵션을 사용해 LSM을 활성화시킨 경우에) exec()이 최종적으로 호출하는 함수인 security_bprm_check()에서 사용되는 hook이다. 즉 exec() 호출 시에 호출되는 hook에 security_add_hooks()로 콜백 함수를 등록하는 것이다. 이 콜백 함수는 당연히 바이너리의 속성을 살피고 실행 여부를 판단하는 루틴으로 이뤄어져 있다.

  예를 조금 더 들어서 fork()의 경우에는 걸 수 있는 함수가 security_task_create()이며 task_create에 hook을 걸어서 사용할 수 있다. 이 외에도 include/linux/lsm_hooks.h를 확인하면 여러 hook들을 찾을 수 있다. 여기서 찾은 hook을 통해 security/security.c에서 이 hook을 사용하는 함수를 찾는다. 이후 이 함수가 어디에서 사용되는지를 추론하여 여러가지 지원되는 hook들을 정리할 수 있다. 앞에서는 프로세스와 관련된 것만 예를 들었지만 파일 시스템, 네트워크 등 여러 종류의 hook을 위한 인터페이스가 제공된다.

3. 자가 보호

  안티바이러스 프로그램은 특성 상 자기 자신을 보호할 필요가 있다. 안티바이러스에 대한 공격으로는 프로세스 종료(리눅스에서는 kill) 외데도 메모리 변조(리눅스에서는 ptrace 등을 이용한) 같은 공격이 있을 수 있다. 윈도우에서는 ObRegisterCallbacks()를 제공하여 프로세스 및 스레드 객체에 대한 특정한 사전 / 사후 동작에 관한 통지를 받는 콜백 함수를 등록할 수 있다. 이를 통해 유저 모드에서 프로세스나 스레드에 접근하려고 하는 경우 이 콜백이 먼저 호출되어 이러한 접근을 차단할 수 있다.

  리눅스의 경우 이러한 함수가 제공되는지 찾아보았지만 역시 존재하지 않았다. 사실 방어 이전에 리눅스에서는 어떤 공격이 존재하는지에 대한 지식도 부족한 상태였기 때문에 자질구레한 방어 기법들을 일일이 정리할 능력이 되지 못한다. 그러던 차에 앞에서 정리했던 LSM을 이용한 방식을 알게되었다. LSM을 정리하면서 가장 유명한 보안 모듈로 SELinux를 이야기했는데 여기서는 grsecurity라는 보안 모듈(공식 커널에 포함되어 있다)을 설명하고자 한다. 사실 SELinux를 보면서 복잡하기도 하고 보안 정책과 관련된 내용이겠구나 하는 생각에 그다지 관심을 가지지 않았는데 grsecurity를 보면서 지금까지 다루어왔던 익숙한 보안 기법들을 제공해준다는 사실에 놀랐다. 여기서는 프로세스 보호에 관련된 내용만 정리하겠지만 grsecurity는 이 외에도 PaX(윈도우의 DEP 같은), ASLR 같은 수많은 보안 기능들을 제공한다.

  직접 어떤 방식으로 구동하는지에 대한 설명은 당연히 위에서 설명한 hook을 이용한 방식일 것이므로 생략하고 어떤 공격이 있을 수 있는지 위주로 정리하겠다. 물론 당연히 grsecurity에서도 제공되는 방어 기능들이다. 가장 먼저 안티바이러스를 종료시키는 공격이 있을텐데 grsecurity에서는 LSM을 이용하여 특정 프로세스에 대한 kill을 못하게 설정할 수 있다. 종료 외에도 리눅스의 경우 ptrace를 이용하여 프로세스를 가로챌 수 있는데 특정 프로세스에 관해 이것을 막아주는 기능도 존재하며 사용자 모드의 프로세스가 실행 중일 때 메모리를 할당하여 코드를 생성하는 기능 및 패치하는 공격에 대한 방어도 존재한다. 다음 링크들은 grsecurity에서 제공되는 보안 기능들을 정리한 사이트들이다. [ https://grsecurity.net/compare.php ] [ https://en.wikipedia.org/wiki/Grsecurity ]

4. 정리

  현대 상용 안티바이러스 제품들이 어떤 형식으로 구현되는지에 대한 지식이 많이 부족한 상태에서 이렇게 나름대로 정리했다는 문서를 만들어서 올리는 것이 검색하는 사람들에게 민폐가 될 수 있겠다는 걱정이 있지만 그래도 대충이라도 훑어보면서 검색할만한 키워드 하나 쯤은 제공할 수 있지 않을까 하는 마음에 정리한 문서를 공개한다. 

  사실 그나마 자료가 있는 윈도우 안티바이러스에 대해서도 찾기 힘들었지만 리눅스 플랫폼의 안티바이러스는 정말 자료를 찾기 힘들어 보인다. 물론 ClamAV라는 오픈 소스 안티바이러스가 존재하지만 여기서는 fanotify를 이용한 on-demand 파일 스캐닝과 관련된 자료밖에 없어서 나머지 내용들은 나름대로 추리해 가면서 찾아보았다.

  실제로 판매되는 적절한 기능을 갖춘 리눅스 플랫폼의 안티바이러스에 대한 정보가 많이 존재했으면 하는 바람이며 이것은 윈도우도 마찬가지이다. 물론 시장이 좁아서 더더욱 없을 것이지만 다른 프로그램들과 달리 안티바이러스 제품들은 특히나 제대로 된 정보를 찾기 힘든 편이다. 어쨌든 배움이 있을 때마다 추가하도록 하겠다.

0. 개요

.... 0.1 Windbg (Cdb)

.... 0.2 Gdb

1. Control

.... 1.1 Session

........ 1.1.1 Restart

........ 1.1.2 Quit

.... 1.2 Basic

........ 1.2.1 Trace / Step

........ 1.2.2 Go

.... 1.3 ETC

........ 1.3.1 Symbols

2. Facility

.... 2.1 BreakPoint

........ 2.1.1 BP 기본 명령어

........ 2.1.2 BP 활용

.... 2.2 Memory Assemble / Edit

.... 2.3 Memory Fill / Copy / Compare

.... 2.4 Search

........ 2.4.1 Search memory

........ 2.4.2 Search for disassembly pattern

.... 2.5 Checkpoint

.... 2.6 Reverse Debugging

.... 2.7 Inferior

.... 2.8 Thread

.... 2.9 Signal

.... 2.10 Catch

.... 2.11 Event

.... 2.12 ETC

........ 2.12.1 Help

........ 2.12.2 Clear

........ 2.12.3 Loop

........ 2.12.4 Log

........ 2.12.5 ASLR

........ 2.12.6 Stop-on-solib-events

........ 2.12.7 Alias

........ 2.12.8 Define

........ 2.12.9 Etc

3. Data

.... 3.1 Unassemble

.... 3.2 Register

.... 3.3 Memory

........ 3.3.1 Display Memory

........ 3.3.2 Display words and symbols

........ 3.3.3 Display Referenced Memory

........ 3.3.4 Display Type

........ 3.3.5 Display Debugger Object Model Expression

.... 3.4 Call Stack

.... 3.5 ETC

........ 3.5.1 의사 레지스터

........ 3.5.2 Etc

0. 개요

  Windbg(또는 cdb 및 kd)나 Gdb를 다루는 대부분의 자료들은 커널 모드 디버깅이나 소스 코드 및 디버깅 정보 파일을 통해 디버깅을 하는 내용을 담고 있다. Gdb의 경우는 리눅스 플랫폼 자체가 오픈 소스가 많은 면이 있기 때문인 것으로 보이는데 물론 유저 모드 디버깅과 관련된 자료들 및 PEDA나 GEF 또는 evan's debugger 같은 Gdb의 불편한 인터페이스를 보완해주는 툴들도 존재한다. Windbg의 경우에는 Ollydbg의 영향이 매우 크다고 여겨지며 Ollydbg가 아직 지원하지 않는 64비트 리버싱의 경우에도 x64dbg 같은 디버거들의 개발로 인해 Windbg가 유저 모드 리버싱에서는 거의 사용되지 않는 것으로 보인다.

  Cdb는 CLI 형태의 유저 모드 디버거이며 Kd는 CLI 형태의 커널 디버거이다. Windbg는 Cdb 및 Kd를 통합함과 동시에 간단한 GUI 형태를 제공한다. Gdb는 유저 모드와 커널 모드를 모두 제공하면서 CLI 형태를 갖는다. 이 두 디버거의 공통점으로 윈도우 및 리눅스의 업그레이드와 함께 발전되며 많은 기능을 지원하는 장점이 있는 반면 두 디버거 모두 사용하기 매우 불편하다는 단점도 갖는다. 그렇기 때문에 특히 윈도우의 경우 x86 유저 모드 디버거 중에서 매우 사용자 친화적인 Ollydbg가 대표적으로 많이 쓰이고 있다.

  이 문서에서는 유저 모드 디버깅 즉 유저 모드 악성코드 분석을 위한 리버싱 용도로 Windbg(어떻게 보면 단지 Cdb)와 Gdb의 명령어를 정리하기로 한다. 유저 모드 디버거에서 이 디버거들보다 훨씬 사용자 친화적인 디버거 및 확장이 존재함에도 불구하고 굳이 이 문서를 만드는 이유는 관련 자료들이 많지 않아보이기 때문이다. 마지막으로 본문에서 프롬프트가 >로 시작하는 라인은 Windbg의 명령어를 의미하며 (gdb)로 시작하는 라인은 Gdb의 명령어를 의미한다. 그리고 명령어 옆에 괄호가 있는 경우에는 명령어의 약자를 의미한다.

0.1 Windbg (Cdb)

  Windbg에서 일반적으로 사용되는 명령은 "일반 명령"으로서 디버거 자체에 내장된 명령이다. 이 외에도 "메타 명령"이라고 "."으로 시작하는 명령 및 "!"로 시작하는 "확장 명령"도 존재한다. 

  참고 사항으로서 심볼 설정이 있는데 조금 자세히 설명해 보겠다. Ollydbg에서는 이 설정을 굳이 자세히 하지는 않았지만 이 디버거도 자체적으로 심볼 형태를 제공해 주기 때문에 API 함수의 이름이나 파라미터 이름 등의 정보를 보여줌으로써 우리가 쉽게 리버싱을 하도록 도와주었다. Windbg의 경우 심볼 설정을 해주지 않으면 앞에서 설명한 디버깅을 도와주는 정보를 하나도 얻을 수 없다. 이러한 디버깅 정보는 pdb 형태로 제공된다.

  pdb 파일 즉 심볼 파일은 우리가 직접 프로그램을 개발할 경우에도 디폴트로 만들어지는데 이 pdb 파일이 존재한다면 우리는 디버깅 시에 어셈블리 명령어에 상응하는 소스 코드를 보면서 디버깅을 할 수 있을 정도로 많은 정보가 들어있다. 물론 이것은 우리가 직접 개발하였고 심볼 파일을 생성한 후에 디버거로 읽어들인 경우에 해당하며 악성코드의 경우에는 심볼 파일과 같이 배포될 일이 없기 때문에 이런 기대를 할 수 없다.

  여기서 우리가 심볼 설정을 통해서 얻는 pdb 파일은 ntdll.dll이나 kernel32.dll 같은 시스템 DLL 파일들에 대한 정보이다. pdb 파일도 public 및 private 심볼로 나뉘는데 private 심볼의 경우 위에서 말한 소스 코드 등의 정보까지 많은 내용의 정보가 들어있으며 용량도 상당히 크다. 하지만 MS가 소스 코드를 공개할 일이 없을 것이며 이에 따라 제공되는 심볼 파일은 public 심볼인데 이것은 상당히 제한된 내용만 들어있다. 물론 없는것 보다는 훨씬 낫기 때문에 이렇게 심볼 설정을 하는 것이다. 여기서 얻을 수 있는 정보는 소스 코드는 아니더라도 API 함수의 이름은 얻을 수 있다.

  심볼 관련 설정은 두 가지로 나뉘는데 하나는 MS가 제공하는 모든 심볼 파일(public)들을 다운로드 받아서 특정 디렉토리에 두고 그 디렉토리의 경로를 설정하는 것이 있다. 다른 하나는 MS에서 제공하는 심볼 다운로드 링크 및 내 컴퓨터에 다운로드할 경로를 적어서 디버깅 시에 필요한 심볼 파일만(분석 도중 kernel32.dll로 진입했을 때 이 심볼 파일을 다운로드 받는 형태로) 다운로드 받을 수도 있다. 

[ SRV*c:\symbols*http://msdl.microsoft.com/download/symbols ]

  Windbg의 File -> Symbol File Path에 위와 같은 값을 입력하면 MS가 제공하는 심볼 서버에서 필요할 때마다 해당 심볼 파일을 c:\symbols 디렉토리에 다운로드 받아서 저장해 준다. 물론 미리 심볼 파일들 전체를 다운로드 받은 경우에는 디렉토리 경로만 적어주어도 된다. cdb를 사용하거나 커맨드 명령어를 통해 심볼 관련 설정을 하는 방식은 아래에서 명령어를 소개할 때 설명하도록 하겠다.

  실행 중인 프로세스를 어태치(Attach)하기 위해서는 cdb 실행 시 인자로 -p와 pid를 주면 된다.

0.2 Gdb

  Gdb로 디버깅하는 경우 특정 주소(일반적으로 EP)에 BP를 걸고 run 명령어를 사용할 수도 있지만 보통은 start 명령어를 이용한다.

(gdb) start

  이 명령어는 main()에 temporary breakpoint를 걸고 실행을 시작한다. 일반적으로 디버깅을 시작할 때 가장 먼저 사용하는 명령어로서 이 명령어를 통해 EP로 이동하여 디버깅을 시작할 수 있다.

  또 다른 참고 사항으로 디버기를 인자와 함께 실행시키는 경우에는 다음과 같이 사용한다. aaa는 실행 파일 이름이고 arg1과 arg2는 인자들로서 --args 옵션과 함께 사용한다.

$ gdb --args aaa arg1 arg2

  실행 중인 프로세스를 어태치(Attach)하기 위해서는 attach 명령어에 인자로 pid를 주면 된다.

(gdb) attach [pid]

1. Control

1.1 Session

1.1.1 Restart

> .restart

(gdb) run

  디버깅을 재시작한다.

1.1.2 Quit

> q

(gdb) quit    /    q

  디버깅을 종료한다.

1.2 Basic

1.2.1 Trace / Step

> t

(gdb) stepi    /    si

  Trace. Ollydbg의 Step Into와 같다.

> p

(gdb) nexti    /    ni

  Step. Ollydbg의 Step Over와 같다.

> wt [WatchOptions] [= StartAddress] [EndAddress]

> wt 0040107f

  Trace and watch data. EndAddress까지 실행하면서 여러가지 통계 정보를 보여준다. Start Address를 지정하지 않을 경우 현재 EIP를 기준으로 한다. 보여주는 통계 정보들로는 어떤 함수들이 호출되었는지와 그 횟수, 몇 개의 명령어들이 실행되었는지 그리고 몇 개의 시스템 호출이 실행되었는지 등이 있다.

> ta 0x<addr>    /    pa 0x<addr>

> ta 00401020

> pa 00401020

  Trace / Step to address. Ollydbg에서 F4 키와 같다고 할 수 있다. 즉 해당 주소까지 진행한다. ta의 경우에는 trace 방식을, pa의 경우에는 step 방식을 통해 진행한다.

> tc    /    pc

  Trace / Step to next call. 다음 call 명령어가 올 때까지 진행한다.

> tt    /    pt

  Trace / Step to next return. 다음 ret 명령어가 올 때까지 진행한다.

> tct    /    pct

  Trace / Step to next call or return. 다음 call 또는 ret 명령어가 올 때까지 진행한다.

> th    /    ph

  Trace / Step to next branching instruction. 다음 분기 명령어가 올 때까지 진행한다. 분기 명령어로는 call이나 ret 뿐만 아니라 jump 명령어도 포함된다.

1.2.2 Go

> g

  Go. 디버기 애플리케이션을 실행시키는 명령어로서 올리디버거의 F9와 같다. 일반적으로 BP를 걸어놓고 실행해야하며 그렇지 않는 경우에는 끝까지 실행되서 종료되어 버린다.

(gdb) continue    /    c

  Go. Windbg의 g 명령어와 같이 다음 BP를 만날때 까지 계속 진행한다.

> gc

  Go from conditional breakpoint. Conditional BreakPoint와 관련해서 사용되는 명령어이다. 이것은 뒤에 "2.1.2 BP 활용" 절에서 자세히 설명한다.

> gu

  Go up. 현재 함수가 반환할 때 까지 실행. 즉 현재 함수가 끝나는 ret까지 실행해서 caller로 복귀한다. 실수로 step over할 함수 내부로 step into한 경우에 이 명령을 사용해 간단하게 복귀할 수 있다.

(gdb) finish

(gdb) return

  현재 스택 프레임을 종료한다. 즉 현재 스택 프레임(함수)이 return할 때까지 실행하여 caller로 복귀한다. Windbg의 gu 명령어와 같다.

> gh

  Go with Exception Handled. 이것은 프로그램의 예외 핸들러를 호출하지 않고 직접 수동으로 예외 상황을 고칠 때 사용한다. 즉 예외가 발생되는 명령어를 실행해서 first chance 예외가 발생한 경우에 해당 명령어를 고치고 난 후에 다시 재개할 때 사용한다. first chance 예외 발생 시 고치지 않고 gh 명령어를 사용하면 계속 다시 first chance 예외가 발생한다.

> gn

  Go with Exception not Handled. 예외 발생 시 디버거가 받은 제어를 프로그램의 예외 핸들러가 처리하도록 프로그램에게 넘긴다. Ollydbg에서 Shift+F7 같이 다시 프로그램에게 넘겨주는 것이다.

  예를들어 보자면 발생할 예외의 핸들러에 미리 bp를 걸고 g 하면 first chance 예외가 발생하게 된다. 이 때 다시 g 하면 핸들러에 도착해서 bp에 걸린다. 하지만 애초에 gn을 하면 first chance 예외에 걸리지 않고 바로 핸들러까지 가서 이곳에서 bp에 걸린다.

* First Chance Exception / Second Chance Exception

  디버거의 구조 상 프로그램에서 발생한 이벤트를 받게 된다. 만약 예외가 발생한다면 당연히 디버거가 예외를 받게 된다. 이 때 first chance 예외가 발생한다. First chance 예외 발생 이후 프로그램에 예외 핸들러가 존재한다면 예외를 프로그램에게 넘길 수 있고(gn) 그렇지 않다면 디버거로 예외가 발생한 부분을 직접 수정해서 예외가 발생하지 않게 만든 이후 다시 실행을 재개(gh)할 수 있다. 어쨌든 프로그램에서 적절한 핸들러가 없어서 예외를 제대로 처리하지 못하면 다시 예외가 발생하게 되고 디버거는 이러한 unhandled 예외를 다시 잡게 되는데 이것을 second chance 예외라고 한다. 만약 디버거가 존재하지 않는다면 프로그램은 crash할 것이다.

* 예외 분석

  예를들어서 분석 시에 SEH를 이용한 안티 디버깅을 만났다고 가정해보자. 이 경우에 보통 SEH 핸들러의 주소에 BP를 걸고 실행할 것이다. 이 때 예외를 일으키는 명령어를 만나면 first chance 예외가 발생한다. 그리고 다시 g나 gn 명령어를 실행하면 BP에 도착할 것이다. 물론 gh 명령어를 사용한다면 계속 first chance 예외가 발생할 것이다.

1.3 Etc

1.3.1 Symbols

> .symfix c:\symbols

  심볼이 존재하는 디렉터리 경로를 지정한다.

> .reload

  경로 지정 후 심볼을 다시 로드한다.

2. Facility

2.1 BreakPoint

2.1.1 BP 기본 명령어

> bp 00407725

  Breakpoint. 0x00407725 주소에 BreakPoint를 건다.

> bp $exentry

  EP에 브레이크포인트를 설정할 때 사용한다. Windbg의 경우 디폴트 옵션에서는 처음 바이너리를 불러오면 ntdll.dll의 LdrInitializeThunk()에 BP가 걸리기 때문에 이 명령어를 통해 EP에 BP를 걸고 실행함으로써 간단하게 EP로 바로 이동할 수 있다. 

  참고로 Ollydbg의 경우에는 옵션에서 EP에 BP를 걸게 해주는 옵션이 있고 이것이 디폴트 옵션이라서 바이너리를 불러오면 자동으로 EIP가 EP에 위치하고 있기 때문에 처음 Windbg를 사용할 때 익숙치 않아서 당황할 수 있다. 

  Windbg로 바이너리를 불러오자 마자 이 명령어를 사용하면 아마 에러가 뜰 것이다. 그렇기 때문에 이 명령어는 한 번 실행 후 프롬프트가 돌아올 때 까지 약간 기다린 후에 한번 더 입력한다. 그리고 g 명령어를 사용하면 EP에 위치하는 것을 볼 수 있다.

(gdb) break *0x407725    /    b *0x407725

  Set breakpoint.

(gdb) tbreak

  Temporary breakpoint. 한 번 사용되면 자동으로 삭제되는 BP이다.

(gdb) hbreak

  Hardware breakpoint. Windbg는 하드웨어 BP라는 이름을 갖는 기능은 없다. 대신 ba를 이용하는데 뒤에서 ba 항목을 정리한다.

(gdb) thbreak

  Temporary hardware breakpoint.

> bl

(gdb) info break

  Breakpoint list. BP들의 목록을 볼 수 있다. 뒤의 명령어를 보면 알겠지만 목록에 나온 BP의 번호를 가지고 삭제하거나 활성화/비활성화를 할 수 있다.

> bc 0

(gdb) delete 0    /    d 0 

  Breakpoint clear. 0번 bp를 삭제한다.

> be 1

(gdb) enable 1

  Breakpoint enable. 1번 bp를 활성화한다.

> bd 2

(gdb) disable 2

  Breakpoint disable. 2번 bp를 비활성화한다.

> ba r4 00407725

  Break on access. 메모리 BP로서 해당 BP가 걸린 주소를 읽거나 쓰거나 실행할 경우에 발동한다. windbg의 경우 이것을 통해 하드웨어 BP와 같은 기능을 제공한다. 옵션에서 r은 read를 의미하며 w는 write, e는 execute이다. 뒤의 숫자는 BP가 걸리는 메모리의 크기로서 dword 즉 4바이트의 메모리에 BP를 걸려면 4를 입력한다. 참고로 e(execute) 옵션에서는 반드시 1바이트여야 한다. 그리고 메모리의 boundary를 맞추어야 하는데 예를들면 0x00407740의 주소에는 4바이트를 지정할 수 있지만 0x00407742의 경우에는 2바이트만 지정할 수 있다. 다시 0x00407744는 4바이트를 지정할 수 있고 0x00407746은 2바이트를 지정할 수 있다. 물론 1바이트는 아무 곳이나 지정할 수 있다.

(gdb) watch *0x00407725

(gdb) rwatch *0x00407725

(gdb) awatch *0x00407725

(gdb) info watch

  Watchpoint. Gdb에서는 메모리 BP를 watchpoint라는 개념을 통해 사용한다. 그래서 목록 확인도 info breakpoint 대신 info watch를 사용한다. 그냥 watch의 경우에는 write, rwatch는 read 그리고 awatch는 read/write를 의미한다. 

2.1.2 BP 활용

- windbg

  Conditional breakpoint. 예를들어 0x00401020에서 ecx 레지스터의 값이 2인 경우에 BP가 걸리게 하는 방식은 다음과 같다. 참고로 조건부 BP 명령어에는 j 명령어도 있지만 여기에서는 .if ~ .else만 고려하기로 한다.

> bp 00401020 ".if (@ecx == 0x2) {} .else {gc}"

  여기서 g 대신 gc를 사용하는데 이것은 만약 조건이 맞지 않는 경우에 g를 사용한다면 끝까지 실행되어 버리기 때문이다. 이것은 p 같은 명령어로 한 줄씩 트레이싱 하고 있는 경우에도 해당된다. 대신 gc를 사용한다면 조건이 맞지 않아도 다음 줄에서 브레이크가 걸린다. 즉 gc는 이러한 조건부 BP에서만 사용된다. 만약 bp가 걸린 경우에도 특정 명령어를 수행하고 싶다면 아래와 같이 사용할 수도 있다.

> bp 00401020 ".if (@ecx == 0x2) {lm ; u} .else {gc}"

  이 경우에는 조건 bp가 걸리면 lm 명령어와 u 명령어가 자동으로 실행된다. 물론 else 구문에도 명령어를 실행시킬 수 있다.

- gdb

  Conditional breakpoint. 예를들어 0x08043214에서 eax 레지스터의 값이 0인 경우에 BP가 걸리게 하는 방식은 다음과 같다.

(gdb) break *0x08043214 if $eax == 0

또는 다음과 같이 사용할 수도 있다.

(gdb) break *0x08043214

(gdb) info b

2 breakpoint ...

(gdb) condition 2 $eax == 0

  commands 명령어는 BP가 걸릴 때 실행시킬 명령어를 지정해준다.

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

(gdb) break *0x40081d

Breakpoint 2 at 0x40081d

(gdb) commands 2

Type commands for breakpoint(s) 2, one per line.

End with a line saying just "end".

>pwd

>end

(gdb) c

Continuing.

Breakpoint 2, 0x000000000040081d in main (0

Working directory /root/hw

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

  위와 같이 BP 2번 명령어를 인자로 넣고 commands 명령어를 실행하면 실행시킬 명령어를 받을 수 있다. 여기서는 pwd 명령어를 넣었다. 이후 실행시킬 명령어를 다 썼으면 end를 입력하여 끝낸다. 이제 continue 명령어를 입력하면 실행되다가 BP에 걸리고 동시에 pwd 명령어가 실행된 결과를 볼 수 있다.

2.2 Memory Assemble / Edit

> a 00407725

  Assemble. 명령어 실행 즉 Enter 후에 새로운 명령어의 입력을 받아들이는데 이 때 push 18 같은 방식으로 입력하면 해당 주소가 자동으로 수정된다. 이후에는 다음 주소에서 또 어셈블을 시도하는데 공백으로 입력 즉 Enter를 다시 한 번 입력하면 자동으로 종료된다.

> e 004077aa 6a 6d

> ea 00417000 "hello world"

  Edit. Assemble과 달리 명령어가 아닌 메모리를 수정한다. 디스어셈블리를 수정할 경우에도 edit 명령어를 사용할 수 있겠지만 assemble 명령어가 훨씬 편할 것이고 일반적인 메모리를 수정할 경우에는 edit 명령어를 사용한다. e만 사용할 경우에는 eb와 같아서 byte 즉 1바이트의 바이너리 값을 수정할 수 있고 뒤에 붙는 값에 따라 여러가지 방식으로 수정할 수 있다. 뒤에 붙는 w는 word, d는 dword, q는 qword, f는 부동 소수점(single precision - 4bytes)이며 D도 부동 소수점(single precision - 8bytes)이다. 이 외에도 위와 같이 a를 이용해 아스키 문자열을, za를 통해 NULL 종료 아스키 문자열, u는 유니코드 문자열, zu는 NULL 종료 유니코드 문자열 값으로 수정할 수 있다.

  참고 사항으로 e나 eb의 경우에 입력으로 11 22 33 44를 받는다고 하자. 그렇다면 해당 주소를 기준으로 "11 22 33 44" 이대로 각각의 바이트가 수정된다. ew의 인자로 "11 22 33 44"를 받는 경우는 좀 다르다. 이 때는 해당 주소부터 시작해서 "11 00 22 00 33 00 44 00" 이런식으로 변경된다. 즉 word는 2바이트이므로 1바이트만 입력받으므로 나머지는 "00"으로 채우는 것이다. word 형태로 바꾸고 싶다면 "1122 3344" 형태로 입력해야 한다. 그러면 원하는대로 1122 3344 형태로 수정된다. 마찬가지로 ed를 저런 식으로 입력한다면 "11 00 00 00 22 00 00 00 ..." 형태로 입력되며 "11223344" 형태로 입력해야 "11 22 33 44"와 같이 수정된다.

(gdb) set (*0x400820) = 0x6c

(gdb) set {char}0x001d3bb4 = 0x33

(gdb) set {int}0x001d3bb5 = 0x33333333

  gdb에서는 마땅한 명령어가 없는것으로 보인다. 즉 위와 같은 불편한 방식으로 사용할 수 밖에 없다.

2.3 Memory Fill / Copy / Compare

> f 00403000 l20 41 42 43

  Fill memory. 0x00403000부터 20바이트를 "0x41, 0x42, 0x43"의 연속으로 채운다.

> m <Start Range> <End Range> <Addr>

  Move memory. 

> m 00403000 00403003 00403010

  0x00403000부터 0x00403003의 메모리 값을 0x00403010에 옮긴다. 즉 복사 및 삽입이라고 할 수 있다. 참고로 처음 두 인자로부터 범위를 구할 수 있으므로 굳이 복사할 위치 즉 목적지 메모리의 끝 주소를 받을 필요는 없다.

> c <Start Range> <End Range> <Addr>

  Compare memory.

> c 00403000 00403001 00403010

  0x00403000부터 0x00403001의 메모리와 0x00403010부터 0x00403011의 메모리를 비교한다. 마찬가지로 처음 두 인자로부터 범위를 구할 수 있으므로 굳이 비교 대상 메모리의 끝 주소를 받을 필요는 없다.

2.4 Search

2.4.1 Search memory.

- windbg

s -[d|w|b|a] [ Range ] [ Pattern ]

> s [시작주소] [끝주소] [값]

> s 0019ffe0 0019fffc 'H' 'e'

  주소 사이에서 문자 H와 e가 들어간 것을 찾는다.

> s esp l200 77 d3

  esp 주소를 시작으로 200의 범위만큼 "77 d3" 값이 들어간 메모리를 찾는다.

> s -w esp l200 77d3

  또는 위와 같이 77d3이 word이므로 -w 옵션을 사용할 수 있다.

> s -d 00400000 00403000 00000000

  00000000인 값을 찾으므로 dword인 -d 옵션을 사용한다.

> s -a 0019fae0 l200 "hi"

  -a는 아스키를 말하며 l은 길이를 말하므로 0019fce0 까지이다. "hi" 문자열을 찾는다.

> s -sa 00417000 00418000

  아스키 스트링들을 찾아준다.

- gdb

(gdb) find [/sn] start_addr, +len, val1 [, val2, …]

(gdb) find [/sn] start_addr, end_addr, val1 [, val2, …]

  /b 옵션은 byte, /h는 harfwords(2 bytes), /w는 words(4 bytes), /g는 giant words(8 bytes)를 의미한다. 두 번째 인자는 시작 주소이며 세 번쨰 인자는 끝 주소 또는 길이를 의미한다. 마지막 인자가 찾을 메모리이다.

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

(gdb) find /b 0x400814, 0x40083a, 0xe5

0x400814 <main>

1 patterns found

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

  위와 같이 사용하면 주소 0x400814부터 0x40083a까지 0xe5 값을 찾는다.

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

(gdb) find /w 0x400814, +1000, 0xe5894855

0x400814 <main>

0x40083b <_Z41__static_initialization_and_destruction_0ii>

0x40087b <_GLOBAL__I_main>

0x400930 <__do_global_ctors_aux>

4 patterns found.

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

2.4.2 Search for disassembly pattern

> # [Pattern] [Address [ L Size ]] 

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

00401011 cmp ecx, dword ptr [edx+0ch]

00401307 add edx, eax

00401344 mov eax, dword ptr fs:[00000018h]

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

> # cmp*ecx 00401000 l30

> # cmp 00401000

> # ecx 00401000

> # 00401011 00401000 l30

> # ecx*word

> # ecx*dword*ptr

  위의 명령어들은 모두 다음 디스어셈블리를 찾기 위한 것이다. 참고로 4번째 예제는 주소도 검색 결과에 포함된다는 것을 보여준다.

00401011 cmp ecx, dword ptr [edx+0ch]

> # edx*eax 00401300

00401307 add edx, eax

> # dword*ptr*fs

00401344 mov eax, dword ptr fs:[00000018h]

2.5 Checkpoint

  Gdb는 체크포인트라는 기능을 제공한다. 이것은 현재 상태를 스냅샷으로 저장한 이후에 진행하다가 이전에 저장한 스냅샷으로 복귀할 수 있는 기능을 제공함으로써 디버깅을 편리하게 해준다. 실질적으로는 fork()를 통해 똑같은 프로세스를 만드는 것이다.

(gdb) checkpoint

  디버기의 현재 상태를 스냅샷으로 저장한다. 

(gdb) info checkpoint

  체크포인트 정보를 보여준다. 이후에는 여기서 보이는 체크포인트 번호를 사용한다.

(gdb) restart [ 체크포인트 번호 ]

  다른 체크포인트로 변경할 수 있다. 즉 이전에 저장한 체크포인트로 복귀할 수 있다.

(gdb) delete checkpoint [ 체크포인트 번호 ]

  체크포인트를 지운다.

2.6 Reverse Debugging

  Gdb는 역디버깅을 제공한다. 즉 디버깅 과정 중 저장을 시작한 후부터 다시 역으로 되돌아갈 수 있다는 것이다.

(gdb) target record

  역디버깅을 시작한다. 즉 상태 및 명령어 로그 저장은 여기서부터 시작한다.

(gdb) info record

  record 상태를 볼 수 있다. 저장된 명령어들이 몇 개인지 같은 정보를 볼 수 있다.

(gdb) ni

  ni나 si 등의 명령어를 사용하며 디버깅을 진행할 것이다.

(gdb) rc

  c 즉 continue 명령어의 반대이다. 반대 방향으로 c 명령어를 진행한다.

(gdb) rsi

  si 명령어의 반대이다.

(gdb) rni

  ni 명령어의 반대이다.

(gdb) record stop

  record를 중단한다. stop한 경우에는 지금까지 저장했던 로그가 모두 삭제된다. 즉 그냥 없었던 일이 되는 것이다.

(gdb) record save

  현재 record를 로그 파일로 저장한다.

(gdb) record restore [ 로그 파일 이름 ]

  로그 파일에서 복구한다. 참고로 복구하면 record의 begin 즉 record를 시작한 곳에서 시작한다.

(gdb) record goto end

  record의 마지막으로 간다. 여기서 마지막은 record로 저장된 마지막을 의미한다.

(gdb) record goto [ n ]

  record의 번호 n으로 간다.

(gdb) record goto begin

  record의 시작으로 간다.

(gdb) record delete 

  현재 위치 이후부터 end까지를 삭제한다. 현재 위치를 record의 end로 만든다.

(gdb) show exec-direction

  rsi, rni, rc 같은 명령어가 있어서 큰 의미는 없어 보이지만 실행 방향을 설정하는 모드도 존재한다. reverse와 forward가 있다. 

(gdb) set exec-direction reverse

  reverse로 설정한 경우에는 ni, si, c 같은 명령어가 rni, rsi, rc 처럼 반대로 진행된다. 참고로 "target record"를 통해 역디버깅을 시작한 후에 이 모드를 설정할 수 있다. 그냥 rni 같은 명령어를 사용하면 되므로 큰 의미는 없어보이는 모드이다.

(gdb) set exec-direction forward

  모드를 foward로 설정한다.

(gdb) set pagination off

  출력 결과가 화면을 넘어가는 경우 전체를 보여주지 않고 다음과 같이 부분만 출력한다. pagination 옵션을 off하면 화면을 넘어가는 긴 출력 결과도 전체를 보여준다.

---Type <return> to continue, or q <return> to quit---

2.7 Inferior

  리눅스에서는 fork()를 통해 자식 프로세스를 생성할 수 있다. Gdb의 경우 디버깅 도중 fork()로 인해 자식 프로세스가 생성된 경우 부모 프로세스 뿐만 아니라 자식 프로세스도 디버깅할 수 있는 기능을 제공한다.

  먼저 이것과는 상관 없지만 배경 지식을 위해 다음 모드를 살펴보겠다. 다음은 fork() 이후 각각 parent 또는 child 프로세스를 디버깅하겠다는 설정이다. 즉 부모 프로세스를 디버깅하는 도중 자식 프로세스가 생성된 경우에 둘 중 하나를 선택하여 그것을 디버깅하겠다는 것이다. 참고로 fork() 외에도 exec()도 마찬가지이다. same은 그대로 디버깅을 계속하고 new는 exec()을 통해 생성된 프로세스를 디버깅하겠다는 의미이다.

(gdb) set follow-fork-mode parent

(gdb) set follow-fork-mode child

(gdb) show follow-fork-mode

(gdb) set follow-exec-mode same

(gdb) set follow-exec-mode new

(gdb) show follow-exec-mode

  detach-on-fork 모드를 off시키면 fork() 시에 부모 또는 자식 프로세스를 선택하고 나머지를 detach 시키는 것을 막는다. 이에 따라 inferior는 부모 프로세스 와에도 자식 프로세스도 포함된다.

(gdb) show detach-on-fork

(gdb) set detach-on-fork off

  이제 inferior의 개념을 알게 되었으니 어떤 방식으로 inferior를 디버깅할지 살펴보겠다.

(gdb) info inferiors

  위의 명령어를 통해 inferior들의 목록을 구할 수 있다. 이 결과로 나온 번호를 통해 다음 명령어를 실행한다.

(gdb) inferior [ inferior 번호 ]

  이 명령은 디버깅 대상을 다른 inferior로 옮기는 역할을 한다. 만약 자식 프로세스의 번호를 사용하는 경우 부모 프로세스를 그대로 둔 상태에서 이제 자식 프로세스를 디버깅할 수 있는 것이다. 그리고 다시 부모 프로세스의 번호를 입력하여 부모 프로세스로 돌아갈 수도 있다.

(gdb) detach inferior [ inferior 번호 ]

  쓸모가 없는 경우에는 inferior를 detach 시킬 수 있다.

(gdb) kill inferior [ inferior 번호 ]

  또는 위의 명령을 사용해 inferior를 종료시킬 수 있다.

2.8 Thread

(gdb) info threads

  모든 스레드 리스트 및 번호를 보여준다.

(gdb) thread [ thread 번호 ]

  현재 스레드에서 다른 스레드로 변경한다.

(gdb) thread apply [ thread 번호 | all ] [ command ]

  기본적으로 명령어를 사용하면 현재 스레드에만 적용되겠지만 인자로 받은 thread 번호를 통해 명시된 스레드에도 동일한 command를 적용할 수 있다. 인자가 all인 경우 모든 스레드가 입력된 명령어를 수행한다.

(gdb) thread apply all bt

  위와 같은 명령어를 사용하면 모든 스레드의 콜스택을 보여준다(bt 명령어).

2.9 Signal

  리눅스에만 존재하는 signal과 관련된 명령어들이다.

(gdb) info signals

(gdb) info handle

  모든 종류의 시그널 목록과 이 시그널 발생 시 GDB각 각각의 항목에 따라 어떠한 행위를 할지에 대한 설정을 보여준다. 이것은 다음 명령어를 통해 각각에 맞는 키워드를 넣어서 설정할 수 있다.

(gdb) handle [ signal 이름 ] [ keyword ]

  키워드는 세 종류가 있다. 시그널 발생 시 프로그램을 중지시킬지에 따라 nostop, stop이 존재하며, 시그널 발생 시 메시지를 표시할지 여부에 따라 print, noprint가 존재하고 마지막으로 받은 시그널을 프로그램으로 다시 넘겨줄지 여부에 따라 pass(noignore), nopass(ignore)가 존재한다. 즉 예를 들면 다음과 같이 사용한다.

(gdb) handle SIG117 nostop

  signal 명령어는 프로그램에 인자로 받은 시그널을 넘김과 동시에 continue한다. 실제로 사용되는 예시를 들어보겠다. 만약 특정한 시그널이 발생하였고 거기에 대해 stop이 설정되어 있다면 프로그램은 정지한다. 이 때 다시 프로그램을 진행시키면 프로그램은 이 시그널을 받은 상태로 진행되기 때문에 만약 그 시그널이 프로그램을 종료시키는 중대한 에러였다면 프로그램은 종료된다. 이런 경우에 받은 시그널을 없애고 진행(continue)하고 싶은 경우에 다음 명령어를 사용한다.

(gdb) signal 0

  마지막으로 catch 명령어를 통해 signal에 대한 캐치포인트를 지정할 수도 있다. 이것은 Catchpoint 항목에서 설명한다.

(gdb) catch signal [ 시그널 번호 ]

2.10 Catch

  Gdb는 Catchpoint를 제공한다. 캐치포인트는 이벤트들에 대한 BP와 비슷한 개념이다. 즉 특정한 이벤트가 발생했을 때 BP를 걸어주는 것이다. 이벤트들로는 throw, catch, exception, exec, fork, vfork, syscall 등이 있다. 예를들어 간단하게 "catch syscall"을 사용함으로써 모든 시스템 호출에 catchpoint를 걸 수 있으며 fork()나 exec()도 마찬가지이다. 이 외에도 여러 C++ 예외에도 유용하게 사용할 수 있다.

(gdb) catch [ event ]

  여러가지 이벤트들에 대한 catchpoint를 설정한다. 

(gdb) info break

  catchpoint도 breakpoint와 같이 이 명령어를 통해 확인할 수 있다.

(gdb) tcatch [ event ]

  catch와 같지만 temporary로서 한 번만 처리된다.

2.11 Events and Exceptions for Windows

  sx* 명령어들은 디버기에서 예외 또는 이벤트가 발생할 때 디버거가 취할 행동을 제어한다. 즉 Break Status와 Handling Status를 설정한다.

> sx

  이 명령어는 현재 프로세스의 예외 목록 및 비-예외 이벤트들의 목록을 보여줌과 동시에 각 예외 및 이벤트에 대한 디버거의 디폴트 행위를 보여준다.

  먼저 Break Status부터 보겠다. sxe(이제부터 괄호 안은 cdb에서 사용되는 명령어로 하겠다) 명령어는 Break Status를 Break 즉 Enabled를 의미한다. 이것은 예외가 발생할 때 즉시 디버거로 넘겨주는 것을 의미하며 first-chance exception이라고도 불린다. sxd(-xd) 명령어는 Second chance break로 설정한다. 즉 Disabled를 의미한다. 이것은 first-chance exception 발생 시 메시지만 표시하고 break하지 않으며 에러 핸들러가 이 예외를 처리하지 못해 다시 예외가 발생했을 때 실행을 멈추고 다시 디버거로 넘겨주는 것이다. sxn(-xn) 명령어는 Output으로 설정한다. 즉 Notify를 의미한다. 이것은 예외 발생 시 메시지만 표시하는 것이다. sxi(-xi) 명령어는 ignore로 설정한다. 이것은 예외 발생 시 디버기 프로그램 자체에서 처리하지 디버거로 넘겨주지 않는다는 것을 의미한다.

  이제 Handling Status를 살펴보겠다. sxe -h 명령어는 Handling Status를 Handled로 설정한다. 이것은 실행을 재개할 시에 이벤트가 처리되었다고 여기게 해준다. sxd(또는 sxn, sxi) -h 명령어는 Not Handled로 설정한다. 이것은 실행이 재개되었을 때 이벤트가 처리되지 않았다고 여기게 해준다. 참고로 Single-step exception 같이 디버기와 디버거간의 통신에 사용되는 예외들은 Handled로 설정되어 있으며 디버거가 알아서 처리해 주지만 다른 예외들은 모두 Not Handled로 설정되어 있으며 일반적으로 그래야 한다. 특별한 경우가 아닌 경우에 일반적인 예외들을 Handled로 설정한다면 모든 first-chance 예외 및 second-chance 예외 발생 시에 모든 예외 처리 루틴들을 건너뛰기 때문이다.

  이렇게 sx* 명령어를 통해 Break Status를, sx* -h 명령어를 통해 Handling Status를 설정할 수 있다. 참고로 특별한 몇몇 이벤트 코드들은 -h 옵션을 사용하지 않고 sx* 명령어를 통해 Break Status 대신 Handling Status를 설정한다. 예를들면 아래에 나오는 hc의 경우에는 sx* hc 처럼 -h 옵션이 없어도 Handling Status를 설정한다는 것을 의미한다.다음은 일반적인 이벤트들이다.

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

asrt : Assertion failure.

av : Access violation.

dm : Data misaligned.

dz : Integer division by zero.

c000008e : Floating point division by zero.

eh : C++ EH exception.

gp : Guard page violation.

ii : Illegal instruction.

iov : Integer overflow.

ip : In-page I/O error

isc : Invalid system call.

lsq  Invalid lock sequence.

sbo : Stack buffer overflow.

sov : Stack overflow.

wkd : Wake debugger.

aph : Application hang.

3c : Child application termination.

ch, hc : Invalid handle. 참고로 ch는 Break Status, hc는 Handling Status를 설정할 때 사용된다.

Number : Any numbered exception.

dbce : Special debugger command exception.

vcpp : Special Visual C++ exception.

wos : WOW64 single-step exception.

wob : WOW64 breakpoint exception.

sse, ssec : Single-step exception. sse는 Break Status, ssec는 Handling Status를 설정할 때 사용된다.

bpe, bpec : Breakpoint exception. bpe는 Break Status, bpec는 Handling Status를 설정할 때 사용된다.

cce, cc : CTRL+C or CTRL+BREAK. cce는 Break Status, cc는 Handling Status를 설정할 때 사용된다.

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

  다음 이벤트들은 예외가 아니므로 Handling Status는 상관이 없기 때문에 Break Status만 설정할 수 있다.

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

ser : System error.

cpr : Process creation.

epr : Process exit.

ct : Thread creation.

et : Thread exit.

ld : Load module.

ud : Unload module.

out : Target application output.

ibp : Initial breakpoint.

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

  예들들어 보겠다. 다음은 ld 이벤트와 관련된 예제이다. ld 이벤트 코드는 예외가 아니므로 Break Status만 설정할 수 있다.

ld [ module, driver 이름 ] : 모듈(.dll)이나 드라이버(.sys)가 로드되었을 때의 이벤트 설정.

ud [ module, driver 이름 ] : 모듈(.dll)이나 드라이버(.sys)가 언로드되었을 때의 이벤트 설정.

  올리디버거의 옵션에는 모듈 로드 시에 자동으로 BP를 걸어주는 옵션이 있다. 즉 악성코드가 LoadLibraryA() API를 사용해 특정한 모듈을 로드할 시에 BP를 거는데 사용될 수 있는 편리한 기능이다. 이 기능을 Windbg에서 구현해보도록 하겠다. 

  Windbg에서는 ld라는 이벤트 코드가 있는데 이것은 모듈이 로드되었을 때 발생하는 이벤트이다. 이 이벤트를 sxe 명령어를 사용해 Break Status를 Break로 걸어준다. 이를 통해 특정 모듈이 로드된 경우에 BP를 자동으로 걸어주는 원리이다. 

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

> sxe ld user32.dll kernel32.dll

ld - Load module - break

(only break for user32.dll kernel32.dll)

> g

ModLoad: 749c0000 74afc000   C:\WINDOWS\SysWOW64\User32.dll

eax=00000000 ebx=00000000 ecx=000028b4 edx=0041a6e3 esi=00000000 edi=002d0000

eip=77731fec esp=0019d12c ebp=0019d180 iopl=0         nv up ei pl nz na po nc

cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202

ntdll!NtMapViewOfSection+0xc:

77731fec c22800          ret     28h

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

  위에서는 두 dll을 사용했는데 이 명령어는 user32.dll과 kernel32.dll을 차례대로 입력하면 통하지 않기 때문이다. 즉 마지막에 입력된 명령어로 수정된다. 그래서 여러개를 입력하고 싶은 경우에는 한 번에 위처럼 여러개를 같이 써야 한다. 만약 모든 모듈을 설정하고 싶다면 " sxe ld *.dll "과 같이 사용할 수도 있다. 비슷한 원리로 ud 이벤트 코드를 사용해 모듈이 언로드되었을 때 BP가 걸리게 할 수 있다. 참고로 Gdb에서도 이와 동일한 기능을 제공하는데 이것은 2.12.6 Stop-on-solib-events 절에서 설명하겠다.

  이번에는 sx 명령어를 입력하여 디폴트로 설정된 것들을 살펴보겠다. 보니까 ibp 이벤트 코드 즉 Initial breakpoint가 break로 설정되어 있다. 이 설정을 보면서 우리가 Windbg로 새로운 실행 파일을 로드한 경우에 자동으로 초기 BP가 걸려서 거기에서 멈춰있던 것을 생각할 수 있다.

  또한 위의 리스트에서 dbce부터 cce의 항목까지 보면 모두 디폴트로 Break Status는 break, Handling Status는 Handled인 것을 볼 수 있다. 이것은 당연하게도 디버거와 디버기가 통신하는데 사용되는 예외이기 때문이다. 단적인 예로 sse는 Single-step exception을 의미한다.

2.12 ETC

2.12.1 Help

> ?

  모든 명령어들과 연산자들의 목록을 보여준다. 그것 외에는 없다.

> .help

> .help /D wake

  meta-command help. 메타 명령어들에 대한 설명을 보여준다. 디폴트로 사용할 시 사용 가능한 모든 메타 명령어들의 목록을 보여준다. 두 번째 줄은 .wake 메타 명령어에 대한 간단한 설명을 볼 수 있다. 물론 각 알파벳을 클릭하여 해당 알파벳으로 시작하는 모든 메타 명령어들에 대한 간단한 설명을 볼 수 있다. .hh를 통해 자세한 설명을 보는 것을 추천한다.

> !help

  확장 명령어들의 목록을 보여준다.

> .hh

> .hh !gle

  Open html help file. HTML help 문서 파일을 열어준다. 인자로 명령어를 넣는다면 해당 명령어에 관한 설명을 찾아주며 일반 명령어든 메타 명령어든 확장 명령어든 문서에 있는 명령어는 모두 찾아준다. 참고로 왼쪽에서 검색 후 체크된 항목을 더블클릭해야 볼 수 있다.

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

(gdb) help

List of classes of commands:

aliases -- Aliases of other commands

breakpoints -- Making program stop at certain points

data -- Examining data

files -- Specifying and examining files

internals -- Maintenance commands

obscure -- Obscure features

running -- Running the program

stack -- Examining the stack

status -- Status inquiries

support -- Support facilities

tracepoints -- Tracing of program execution without stopping the program

user-defined -- User-defined commands

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

  인자 없이 사용하면 명령어들의 클래스를 보여준다. 즉 모든 명령어들을 보여주는 것이 아니라 각 명령어들이 속한 분류인 클래스를 보여준다.

(gdb) help data

  여기서는 data 클래스를 선택하였는데 이 data 클래스에 속한 모든 명령어들을 간단한 설명과 함께 보여준다. data 클래스의 명령어 중 dump 명령어를 보려면 아래와 같이 입력한다.

(gdb) help dump

  위와 같이 인자로 명령어를 넣으면 명령어에 대한 조금 더 자세한 설명을 볼 수 있다. 

(gdb) apropos breakpoint

  인자로 받은 문자열과 관련된 명령어들을 보여준다. 즉 위와 같은 경우에는 breakpoint 관련 명령어들의 목록이 결과로 나온다.

2.12.2 Clear

> .cls

  화면을 clear해 준다.

(gdb) shell clear

  gdb의 명령어도 아니고 특정한 환경(xterm)에 통하는 명령이지만 화면을 clear해 준다. 직접적으로 제공되는 gdb 명령어는 없다.

2.12.3 Loop

> z(expression)

  Execute while. 일종의 반복문으로서 괄호 안이 참일때 까지 반복한다. 다음과 같이 사용하는데 이렇게 사용하면 ecx가 0이될 때 까지 p 명령어를 실행한다.

> p; z(ecx != 0)

2.12.4 Log

- Windbg

  Windbg에서는 로그 파일을 만들어서 텍스트 형태로 기록할 수 있다. 즉 로그 파일을 오픈한 이후부터 닫을 때 까지 입력한 명령어 및 결과가 해당 텍스트 파일에 모두 기록된다. 

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

> .logopen /t C:\Users\monto\Desktop\log.txt

Opened log file 'C:\Users\monto\Desktop\log_252c_2017-06-15_10-58-50-192.txt'

// Open log file

> ...

> .logfile

Log 'C:\Users\monto\Desktop\log_252c_2017-06-15_10-58-50-192.txt' open

// Display log file status

> .logclose

Closing open log file C:\Users\monto\Desktop\log_252c_2017-06-15_10-58-50-192.txt

// Close log file

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

- Gdb

(gdb) set logging on

  로깅을 시작한다. 디폴트로 gdb.txt 파일에 저장된다.

(gdb) set logging off

  로깅을 중지한다.

(gdb) show logging

  현재 로깅 설정을 보여준다. 설정들은 뒤에서 나열하겠지만 어떤 이름의 파일에 저장할지, 로그를 append 즉 이어쓸지 아니면 overwrite할지, 마지막으로 출력을 터미널에도 보여주고 로그 파일에도 저장할지 아니면 로그 파일에만 저장할지이다.

(gdb) set logging file [ 파일 이름 ]

  로그 파일의 이름을 새로 지정할 수 있다. 디폴트는 gdb.txt 파일이다.

(gdb) set logging overwrite [ on|off ]

  로그를 overwrite할지 여부를 결정한다. 디폴트는 append이다.

(gdb) set logging redirect [ on|off ]

  로그의 출력을 로그 파일에만 보낼지 지정한다. 디폴트는 로그 파일 및 터미널 모두로 보내는 것이다.

2.12.5 ASLR

  디버기 실행 시에 커널에서 제공되는 ASLR 기능을 활성화할지 여부를 결정한다.

(gdb) show disable-randomization

  disable-randomization의 on/off 설정을 보여준다.

(gdb) set disable-randomization on 

  디버기 프로세스의 ASLR을 비활성화시킨다.

(gdb) set disable-randomization off

  디버기 프로세스의 ASLR을 활성화시킨다.

2.12.6 Stop-on-solib-events

(gdb) show stop-on-solib-events

  위에서 설명하였듯이 Gdb에서도 공유 라이브러리가 로드 또는 언로드 될 시에 BP를 걸어주는 기능을 제공한다. 위의 명령어는 현재 그 기능이 켜져있는지 여부를 보여준다. 

(gdb) set stop-on-solib-events 0

  Stop-on-solib-events 기능을 끈다.

(gdb) set stop-on-solib-events 1

  Stop-on-solib-events 기능을 켠다.

2.12.7 Alias

> as 또는 aS

  Set Alias. 아래의 예에서는 !teb 명령어의 alias로 !t를 만들었다. 이후에는 !teb 외에 !t 명령어만 사용해도 디버거는 !teb와 동일하게 받아들인다.

> as !t !teb

> !t

(gdb) alias -a di = disas

(gdb) di

  gdb에서는 alias 명령어가 존재한다.

2.12.8 Define

(gdb) define adder

> print $arg0 + $arg1 + $arg2

> end

(gdb) adder 1 2 3

$1 = 6

  gdb에서는 사용자 정의 명령어를 정의하기 위해 define 명령어를 사용한다. define 명령어 이후 새로운 명령어의 이름을 적으면 명령어의 내용을 받을 수 있다. 이후 마지막으로 end를 입력하면 종료된다.

2.12.9 Etc

> .printf

  c언어의 printf 문과 같다고 생각하면 된다. 유용하게 사용할 수 있다.

> poi()

  포인터 참조 명령어로서 c언어에서 *와 같다. 즉 인자로 주소를 받는다고 여기고 그 주소의 값을 반환한다.

> .printf "%y \n", poi(00413014)

KERNEL32!GetVersionExAStub (747456d0)

  00413014는 IAT 영역에 위치한 주소로서 GetVersionExAStub()의 주소가 들어가 있다. 조금 더 자세히 말하면 현재 PE가 로드되어 있으므로 IAT에는 각 임포트하는 API들의 주소가 들어가 있다. 코드 영역에서 api를 호출할 경우 이 IAT의 주소를 사용해 call dword ptr [ 00413014 ] 같은 방식으로 호출한다. 이 00413014가 어떤 함수인지를 보기 위해서 poi()를 이용해 해당 주소에 들어있는 값을 알 수 있다. 즉 747456d0이 .printf로 넘어온다.

  .printf의 포맷스트링을 보면 %y이다. 이것은 인자로 디버거 심볼의 주소를 받아서 해당 심볼의 이름을 보여준다. 즉 현재 kernel32.dll의 심볼이 있고 이 중에서 747456d0의 주소를 넘겨 받았으므로 이 주소에 해당하는 심볼인 KERNEL32!GetVersionExAStub 문자열을 출력해 준다. 물론 뒤에 실제로 받은 값이 747456d0도 보여주며 만약 심볼이 없다면 이 값만 보여준다. 이렇게 poi()와 %y를 통해 간단하게 IAT 주소를 가지고 api 이름까지 알아낼 수 있다.

> .echo [ string ]

  일반적인 echo와 같다고 생각하면 된다.

> .echo windbg echo

windbg echo

3. Data

3.1 Unassemble

> u

  Unassemble을 보여준다.

> u 00401000 0040107A

  위에서 지정한 주소만큼 Unassemble을 보여준다.

> u eip l30

  Unassemble을 30라인 만큼 보여준다.

> u ntdll!LdrUnloadDLL

  심볼이 존재한다면 해당 api 함수의 주소를 구하는데 u 명령어를 사용할 수 있다. 예를들면 Ollydbg에서 "Ctrl + G" 명령어를 통해 찾는 것과 같은 방식이다.

> ub

  u가 특정 주소 이후를 보여준다면 ub는 반대로 이전을 보여준다.

> ub eip l20

(gdb) disas

(gdb) disas $eip

  gdb의 경우 ub 같은 명령어가 없다.

(gdb) show disassembly-flavor

  디스어셈블리 스타일이 AT&T인지 아니면 Intel인지를 보여준다.

(gdb) set disassembly-flavor [ intel ]

  디스어셈블리 스타일을 Intel로 설정한다.

3.2 Register

> r

  기본 레지스터들의 값을 보여준다.

> r $proc

  현재 프로세스의 PEB 주소. 위와 같은 "의사 레지스터"는 항목 "3.5.1 의사 레지스터"에서 설명한다.

> r @eip=0x00401000

> r $ip=0x00401000

  두 명령어는 모두 EIP 값을 바꾸는 명령이다. 이것도 "의사 레지스터" 항목을 참고하자.

(gdb) info reg    /    i r

  Gdb의 경우 위와 같이 사용한다.

(gdb) set $eip = 0x00401000

(gdb) set $rip = 0x00401000

  두 명령어는 레지스터 즉 eip 또는 rip의 값을 변경하는 명령이다.

  GDB와 Windbg 모두 EFLAGS 레지스터 관련한 정보는 다음 링크를 확인한다. [ http://sanseolab.tistory.com/44 ]

3.3 Memory

3.3.1 Display Memory

- windbg

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

> d* <addr>

- *

a : ascii chars

u : unicode chars

b : byte + ascii (디폴트 d와 같다)

w : word

W : word + ascii

d : dword

c : dword + ascii

q : qword

f : floating point (single precision - 4b)

D : floating point (double precision - 8b)

b : binary + byte

d : binary + dword

s : string struct

S : unicode string

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

> dc 00401700

  Ollydbg의 디폴트 메모리 창처럼 메모리를 dword 형태로 아스키 값과 함께 출력한다. dW 명령어를 사용해도 띄어쓰기 즉 보여주는 단위의의 차이만 있지 실질적인 차이는 없다.

- gdb

(gdb) x/[Length][Format] [Address expression]

  x/ 바로 뒤에오는 숫자는 길이를 나타낸다. 아래의 예를 보면 알겠지만 10개 단위를 보여준다. 즉 여기서는 word 10개 단위를 보여준다. 두 번째는 출력 포맷을 의미한다. i는 인스트럭션(disas 명령어처럼), x는 익숙한 16진수 값, c는 char, s는 문자열이다. 세 번째는 출력 포맷의 크기이다. 즉 b(byte), h(halfword, 2bytes), w(word, 4bytes), g(giant word, 8bytes)가 있다. 다음 예제는 x86 아키텍처의 예이며 Ollydbg처럼 메모리를 4바이트 단위로 16진수 포맷을 통해 보여준다. 하지만 Ollydbg나 Windbg처럼 아스키 또는 유니코드 문자열을 보여주지는 못하고 메모리 값만 보여준다.

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

(gdb) x/10xw 0x400814

0x400814 <main>:        0xe5894855  0x400988be  0x0d20bf00  0xc1e80060

0x400824 <main+16>:    0xbefffffe    0x00400708  0xe8c78948  0xfffffec4

0x400834 <main+32>:    0x000000b8  0x55c3c900

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

(gdb) x/30i 0x08048320

  위와 같이 사용하면 disas 명령과 같이 인스트럭션들을 보여준다.

(gdb) x/16wx $sp

(gdb) x/16gx $sp

  첫 번째 예제는 x86 아키텍처에서 스택 창을 보여주며 두 번째 예제는 x64 아키텍처에서 보여준다. 마찬가지로 Ollydbg나 Windbg와는 다르게 값만 보여주고 심볼 또는 문자열 같은 정보는 보여주지 않는다.

3.3.2 Display words and symbols

- windbg

> d*s <addr>

  dds는 dword, dqs는 qword, dps는 아키텍처 표준 단위로 보여주며 특정 단위와 연관된 심볼도 함께 보여준다. 즉 해당 메모리 주소에 들어있는 값 및 이 값과 연관된 심볼을 보여준다. 예를들어 들어있는 값이 특정 함수의 주소인 경우에는 관련 함수의 이름 같은 심볼을 보여준다.

> dds esp

> dqs rsp

  x86 아키텍처에서 위와 같이 사용하면 esp를 dword 단위로 보여줌과 동시에 각 dword 주소 별로 값을 보여주며 만약 그 값과 연관된 심볼이 존재하는 경우 심볼도 보여주어서 Ollydbg의 스택 메모리 창처럼 보여줄 수 있다. x64의 경우에는 dqs 명령어를 사용한다.

3.3.3 Display Referenced Memory

> d** <addr>

  인자로 받은 해당 주소 영역에서 포인터를 보여주고 해당 포인터로 참조되는 메모리를 보여준다. 예를들어 현재 eax에 0x00685ce8가 들어있다고 하자. 이 때 "ddp eax" 명령을 실행한다면 결과는 다음과 같다.

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

00685ce8    006853f8    554c4c41

00685cec    00685be8    44505041

...

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

  즉 0x00685ce8을 포인터가 위치한 주소로 여기고 여기에 들어있는 값인 0x006853f8을 포인터로 생각한다. 마지막 3번째는 해당 포인터에서 참조되는 메모리이다. 이 명령어를 이렇게만 사용한다면 큰 의미가 없을테지만 다음과 같은 기능을 제공한다. "dds eax"를 실행해보면 다음과 같다.

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

00685ce8  006853f8 "ALLUSERSPROFILE=C:\ProgramData"

00685cec  00685be8 "APPDATA=C:\Users\monto\AppData\Roaming"

...

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

  즉 세번째 문자를 a로 넣는다면 참조되는 메모리를 아스키 문자열로 보여준다. 참고로 Ollydbg의 경우에 스택 메모리 창을 보면 함수 이름 및 파라미터 이름 같은 심볼 외에도 문자열로 여겨지는 경우에는 문자열도 보여준다. 그렇기 때문에 스택에 "dda esp" 명령도 유용하게 사용할 수 있다. 다음은 두번째 및 세번째 문자열로 들어갈 수 있는 값들이다.

dd* : 해당 값을 32비트 포인터로 생각한다. 즉 x86 아키텍처에서는 dd*를 사용한다.

dq* : 해당 값을 64비트 포인터로 생각한다. 즉 x64 아키텍처에서는 dq*를 사용한다.

dp* : 해당 아키텍처에 맞는 표준 사이즈를 자동으로 설정한다.

d*a : 참조되는 메모리를 아스키 문자열로 보여준다.

d*u : 참조되는 메모리를 유니코드 문자열로 보여준다.

d*p : 참조되는 메모리를 보여준다.

3.3.4 Display Type

  지역 변수, 전역 변수 또는 데이터 타입에 대한 정보를 보여준다.

> dt [-DisplayOpts] [-SearchOpts] [module!]Name [[-SearchOpts] Field] [Address] [-l List] > dt [-DisplayOpts] Address [-l List] > dt -h

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

> dt _PEB 0x0026a000

> dt ntdll!_PEB

   +0x000 InheritedAddressSpace : 0 ''

   +0x001 ReadImageFileExecOptions : 0 ''

   +0x002 BeingDebugged    : 0x1 ''

   +0x003 BitField         : 0 ''

   +0x003 ImageUsesLargePages : 0y0

   +0x003 IsProtectedProcess : 0y0

   +0x003 IsImageDynamicallyRelocated : 0y0

   +0x003 SkipPatchingUser32Forwarders : 0y0

   +0x003 IsPackagedProcess : 0y0

   +0x003 IsAppContainer   : 0y0

   +0x003 IsProtectedProcessLight : 0y0

   +0x003 IsLongPathAwareProcess : 0y0

   +0x004 Mutant           : 0xffffffff Void

   +0x008 ImageBaseAddress : 0x00400000 Void

   +0x00c Ldr              : 0x77757be0 _PEB_LDR_DATA

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

3.3.5 Display Debugger Object Model Expresison

  NatVis 확장 모델을 이용하여 C++ Expression을 보여준다.

> dx

  자세한 r# 옵션은 recursion Level이다. 다음과 같이 사용하여 _PEB_LDR_DATA 구조체 0x77757be0에 대한 정보를 확인하였다.

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

> dx -r1 ((ntdll!_PEB_LDR_DATA *)0x77757be0)

    [+0x000] Length           : 0x30 [Type: unsigned long]

    [+0x004] Initialized      : 0x1 [Type: unsigned char]

    [+0x008] SsHandle         : 0x0 [Type: void *]

    [+0x00c] InLoadOrderModuleList [Type: _LIST_ENTRY]

    [+0x014] InMemoryOrderModuleList [Type: _LIST_ENTRY]

    [+0x01c] InInitializationOrderModuleList [Type: _LIST_ENTRY]

    [+0x024] EntryInProgress  : 0x0 [Type: void *]

    [+0x028] ShutdownInProgress : 0x0 [Type: unsigned char]

    [+0x02c] ShutdownThreadId : 0x0 [Type: void *]

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

3.4 Call Stack

  여기서는 스택 프레임 즉 콜스택과 관련된 정보를 볼 수 있는 명령어들을 다룬다. 

- Windbg

> k

  Display stack backtrace.

> kb

  인자도 같이 보기.

- Gdb

(gdb) backtrace

(gdb) bt

(gdb) info stack

(gdb) where

  위의 명령어 모두 전체 call stack을 보여준다. 

(gdb) bt [ n ]

  특정 순서의 프레임만 보여준다.

(gdb) bt full

  전체 콜 스택에 대하여 로컬 변수를 포함해서 보여준다. 물론 심볼이 있어야 하기 때문에 여기서는 의미가 없다.

  다음에 설명하는 명령어들은 각 스택 프레임에 대한 정보를 보여주는 명령어들이다. 참고로 info args나 info locals 같은 명령어들은 심볼이 있는 경우에 정보를 보여줄 수 있다.

(gdb) info frame

  현재 선택된 스택 프레임에 대한 정보를 보여준다.

(gdb) info args    /    info locals

  심볼이 있는 경우에 각각 현재 프레임의 인자와 로컬 변수를 보여준다. 심볼이 있어야 하기 때문에 여기서는 의미가 없다.

  다음에 설명하는 명령어들은 콜 스택에서 각각의 스택 프레임을 선택하는 명령들이다.

(gdb) frame [ frame 번호 ]

  프로그램의 진행과 관련 없이 현재 스택 프레임을 변경한다.

(gdb) select-frame [ frame 번호 ]

  frame 명령어와 같지만 별도로 내용을 출력하지 않는다.

(gdb) up / down

  up 명령어는 현 프레임이 호출한 스택 프레임을 선택하고 down 명령어는 현 프레임을 호출한 스택 프레임을 선택한다. 간단히 말해서 bt 명령어를 통해 볼 수 있는 콜스택에서 위 아래로 선택하는 명령들이다.

3.5 ETC

3.5.1 의사 레지스터

  Windbg는 특정한 값을 갖는 의사 레지스터들을 지원한다. 이것은 dollar ($) 기호를 앞에 붙임으로써 구별 가능하다. 참고로 특정한 레지스터를 의미하는 at (@) 기호와 호동될 수 있다. 앞에서 특정한 레지스터를 표현할 때 다음과 같이 사용하였다.

> bp 00401020 ".if (@ecx == 0x2) {} .else {gc}"

  즉 의사 레지스터는 $ 기호를, 구체적인 레지스터는 @ 기호를 붙인다. 다음은 의사 레지스터들의 예시이다.

- $ip : 현재 디버거 타겟 아키텍처의 명령 포인터 레지스터의 이름을 나타낸다. 즉 x86에서는 eip 레지스터이며 @eip와 같은 의미이고 x64에서는 rip 레지스터 즉 @rip와 같은 의미이다.

- $ra : 현재 함수의 복귀 주소.

- $retreg : 주요한 값을 가지는 레지스터를 나타낸다. 즉 x86에서는 eax 레지스터(@eax), x64에서는 rax 레지스터(@rax)와 같은 의미이다.

- $csp : 현재 스택의 포인터. x86에서는 esp 레지스터(@esp), x64에서는 rsp 레지스터(@rsp)를 의미한다.

- $proc : 현재 프로세스. 유저 모드에서 PEB의 주소나 커널 모드에서 현재 프로세스의 EPOCESS 구조체의 주소.

- $thread : 현재 스레드. 유저 모드에서 TEB의 주소나 커널 모드에서 현재 스레드의 ETHREAD 구조체의 주소

- $tpid : PID

- $tid : TID

- $t0 ~ $t9 : 사용자 정의 의사 레지스터.

> ? <expression>

> ? $ip

> ? @eip

  ? <expression> 명령어는 해당 표현식의 결과를 보여준다. 바로 아래에 나온 예제를 보면 x86 환경에서는 두 명령어 모두 같은 값 즉 eip 레지스터의 값을 의미하며 ? 명령어의 결과도 동일하다.

3.5.2 Etc

3.5.2.1 Module

> lm

  List loaded modules. 참고로 윈도우의 심볼 서버를 설정한 경우를 가정하고 처음 이 명령어를 사용하면 ntdll만 심볼이 보이고 나머지는 deferred로 된다. 이것은 지금까지 분석한 모듈이 ntdll 밖에 없고 그래서 심볼 서버로 ntdll만 심볼을 다운로드 받았기 때문이다. 추후에 kernel32.dll 같은 곳에 들어가게 되면 우니도우의 심볼 서버에서 그것을 다운받기 때문에 심볼이 있는 환경에서 분석을 할 수 있게 된다. 물론 여기서는 악성코드 분석을 가정하기 때문에 실행 파일에 대한 심볼은 없을 수 밖에 없다. 

(gdb) info share

  로드된 공유 라이브러리들을 보여준다.

> !lmi ntdll.dll

  모듈 상세 정보

> !dlls

  로드된 모든 DLL 출력

> !dh -f [imgbase]

  해당 이미지의 헤더를 분석해서 보여준다. (-f는 파일 헤더, -s는 섹션 헤더, -a는 모든 헤더 정보)

3.5.2.2 Memory Map

> !address

  Memory Map을 보여준다.

> !vadump

  !address가 이것의 결과를 포함한 훨씬 많은 정보를 보여준다.

> !vprot 0013ff34

  인자로 받은 특정 메모리 주소의 속성을 보여준다.

(gdb) info program

(gdb) shell cat /proc/24084/maps

  뒤에서 나오지만 "info program" 명령어를 통해 PID를 얻는다. 이렇게 얻은 PID가 24084라고 하자. 그리고 shell 명령어도 뒤에 나오지만 셸 명령어를 실행시켜주는 역할을 한다. 위와 같이 사용하면 프로그램의 Memory map 정보를 얻을 수 있다.

3.5.2.3 etc

> !peb

  PEB 관련 정보

> !teb

  TEB 관련 정보

> !handle

  핸들 값 출력.

> !heap

  힙 관련 정보를 보여준다.

> !exchain

  SEH들을 보여준다

> !gle

  API의 마지막 에러 코드. 즉 GetLastError().

> .tlist

  현재 실행 중인 모든 프로세스들의 목록 및 PID를 보여준다.

> ~.

  현재 스레드 정보.

> ~*

  프로세스의 모든 스레드

> .imgscan

  Find image headers. 로드된 모듈들의 이미지 헤더 주소를 찾아준다.

> !tls [Slot]

  명시한 TLS slot을 보여준다.

> .shell

  셸 명령어를 사용할 수 있다. 인자 -x는 해당 프로세스 실행 이후 디버거에서 detach하는 옵션이다.

(gdb) pwd

  현재 작업중인 디렉토리를 보여준다.

(gdb) shell

  셸 명령어를 사용할 수 있다.

(gdb) show commands [ 번호 ]

  명령어 사용 히스토리를 보여준다.

(gdb) show env

  환경변수를 보여준다.

(gdb) show args

  인자를 보여준다.

(gdb) info proc [ keyword ]

  현재 프로세스의 /proc 프로세스 정보를 보여주며 디폴트로는 PID 등 같단한 정보만 보여준다. 키워드로는 mappings(매핑된 메모리 영역 목록), stat(프로세스 정보), status(프로세스 정보), all(/proc을 통해 얻을 수 있는 모든 정보)이 있다.

(gdb) info program

  프로그램의 실행 상태. PID, 현재 BP 정보, 현재 정지한 위치의 주소. 아주 간단한 정보만 보여준다.

(gdb) info files

  로드된 이미지들 즉 바이너리 및 모듈들의 섹션 별 주소 정보.

(gdb) info functions

  로드된 이미지들 즉 바이너리 및 모듈들의 함수들 목록 및 주소 정보.