안녕하세요 하카와티입니다.

블로그에 공지하지 않았지만 책을 집필하였고, 출간되었습니다. 책 제목은 CUCKOO SANDBOX 쿡쿠 샌드박스 구축과 확장 + 운영 팁입니다.

이 책을 구매하신 지인분들께서 오탈자를 찾게되면 공유해주시고 계시기에 발견과 함께 빠르게 이 페이지에서 공지하려 합니다.

재미있게 읽어주시고, 감사합니다.


제보자 - Phantomm님

152p 코드 4-48 몽고DB 데이터베이스 및 사용자 생성 (결과 부분)

몽고DB 계정, 패스워드, 권한 그리고 데이터베이스를 생성하는 명령에 따른 결과가 잘못 표기됨

>  db.createUser({user:"hakawati",pwd:"Mongodb123!@#",roles:[{role:"readWrite", db:"cuckoo"}]}) 

Successfully added user: {

        "user" : "mongodb""hakawati",

        "roles" : [

                {

                        "role" : "readWrite",

                        "db" : "mongodb_cuckoo"

                 }

        ]

 }

178p 악성코드 샘플 다운로드 경로 (폰트로 인해 마지막이 숫자 0으로 보이는 문제)

https://bit.ly/2ImqciO


'Notice > Sub Notice' 카테고리의 다른 글

쿡쿠 샌드박스 오탈자 공유  (2) 2018.11.16
  1. 2019.08.24 16:31

    비밀댓글입니다

  2. Favicon of https://www.hakawati.co.kr BlogIcon hakawati 2020.08.29 17:04 신고

    아뇨 쿡쿠 샌드박스의 경우 악성코드 디버깅과 VM 탐지 우회관련된 기능이 없습니다. 상용솔루션에서 있는건 봤습니다(Jeo Sandbox)

세미나나 컨퍼런스, 강의를 진행하다 보면 시연의 법칙을 만나게 된다. 시연의 법칙이란 시연을 영상으로 잘 녹화한 것이 아닌 즉석에서 시연을 펼칠때 꼭 말썽이 일어나는 상황을 의미한다. 이러한 시연의 법칙을 줄이기 위한 경험적 팁을 기술하려 한다.

1. 다양한 상황, 특히 시연을 보이기 위해 삽질했던 수 많은 상황들을 최대한 기록하고 기억하려 노력한다.

시연이 실패했을 때 유려하게 대처하는 모습이야 말로 전문가 냄새 풀풀 풍기게 해주는 멋짐 폭팔 요소. 문제는 시연을 준비하기 위해 삽질하는 시간이 대단히 많이 들 수 있다는 점이 단점이다. 경험적으로 구축 성공하면 운영체제를 삭제하고 처음부터 다시 설치하는 행위를 적게는 5번에서 많게는 10번은 진행(보고서 작성과 함께 진행)한다. 특이하게 매번 설치할 때 마다 새로운 에러를 만나는 신세계를 경험할 수 있다. 

2. 가상 머신에 구축한 운영체제는 하이퍼바이저에 설정한 NAT 네트워크로 네트워크 인터페이스를 사용한다.

세미나, 컨퍼런스, 강의의 환경에 어떤 아이피가 들어올지 상상도 안된다. 어떤 아이피가 들어오든 무적의 사설 네트워크로 퉁쳐버리자. 인터넷 안되는 문제는 가뿐히 해결할 수 있다. 다만 NAT 네트워크 대역이 발표하는 곳의 네트워크 대역과 겹쳐지는 순간 네트워크 셋팅은 모두 도루묵이 된다. 이 경우 팁은 핸드폰 핫스팟을 이용하자. 무제한 요금제는 덤. 요금제가 고민된다면 친구껄 이용하자.

3. 운영체제는 NAT 네트워크의 사설 아이피를 고정 아이피로 설정해 운영하자.

웹 서버를 구축했는데 운영체제 아이피가 DHCP 서버에 의해 바뀐다고? 이런.. DHCP 서버를 끄기엔 인생 시연만 하며 살껀 아니지 않는가. 그냥 사설 아이피를 고정아이피로 운영체제에 설정해버리자. 가상 머신에 구축하는 경우가 대다수니 다른 운영체제와 겹칠일 없어 별표 백만마흔다섯개. 좀 더 전문가 포스 풍기려면 도메인을 구매해 사설 아이피를 박아버리자. 그럼 아이피도 숨겨 실제 서버인것 처럼 간지 뿜뿜하는데 시연을 보는 사람이 스마트폰으로 웹서버에 접속하려는 진풍경도 덤으로 구경할 수 있다.

4. 시연 전 미리 시연을 해보자.

사실 대부분 이거 안해서 망하는 경우가 부지기수. 반복 학습이야 말로 최고의 고인물이 될 수 있는 지름길.

나중에 또 노하우가 생기면 여기에 추가 기술할 예정!

'Notice > Tips' 카테고리의 다른 글

시연의 법칙 줄이기  (1) 2018.07.31
기술 글쓰기 1 - Markdown과 친해지기  (2) 2016.07.24
  1. Favicon of http://moneycoach.kr BlogIcon 소액 결제 현금화 2018.10.16 11:47

    잘보고 가요^^

목차

1. 요약

2. 개요

3. 관리적 대응방안

3.1. 예방 관리

3.1.1. 소프트웨어 보안 업데이트

3.1.2. 레거시 시스템 제거

3.1.3. 백신 소프트웨어 운영

3.1.4. 랜섬웨어에 특화된 소프트웨어 사용

A. 앱체크(AppCheck)

B. NAR(Nuri Anti-Ransom)

3.1.5. 이메일 관리

3.1.6. 운영 관리

A. 원격 접속 프로그램의 기본 접속 계정과 비밀번호 변경

B. 지속적인 보안공지 확인과 권고 이행

3.2. 대비 관리

3.2.1. 백업 관리

A. 물리적 시스템을 이용한 백업

B. 클라우드 시스템을 이용한 백업

3.2.2. 복원 관리

3.2.3. 차단 및 대응

4. 결론

5. 추가 내용

A. 결제해도 파일을 복구해주지 않는다.

B. 복구 업체는 복구할 수 있다.

C. 감염되면 절대 복구할 수 없다.



    1. 요약

    • 소프트웨어 보안 업데이트 - 필수로 사용
    • 레거시 시스템 제거 - 비용 고려하여 최대한 제거, 그렇지 않다면 확실한 접근제어를 구현
    • 백신 소프트웨어 운영 - 인터넷 시큐리티 버전 추천, 유료 상품을 이용
    • 랜섬웨어에 특화된 소프트웨어 사용 - 앱체크 추천
    • 이메일 관리 - 외부 사설 이메일 사용 자제, 실행파일 첨부 자제 문화 형성
    • 운영 관리 - 원격 접속 프로그램의 기본 계정과 비밀번호 변경, 보안 전문업체나 한국인터넷진흥원의 권고 사항 지속적 이행
    • 백업 관리 - 물리 시스템 사용 시 백업 후 연결 끊기, 클라우드 사용 시 브라우저를 통해서만 이용, 자체 클라우드의 경우 동기화 프로그램을 제공하는 서비스를 이용하여 백업
    • 복원 관리 - 복원 시스템 운영하는 것을 추천하나 100% 신뢰하진 않음
    • 차단 및 대응 - 80, 443 포트 외 모든 포트를 차단 후 윈도우 업데이트

    2. 개요

    현재 가장 뜨거운 감자인 워너크라이(WannaCry) 랜섬웨어는 감염된 이후 대응방안은 애매하다. 이미 볼모로 잡힌 디지털 자산들을 해결할 수 있는 방안이 없기 때문이다. 하지만, 악성코드에 감염되기 전 유포는 충분히 대응 가능하다. 앞으로 꾸준히 이슈가 될 랜섬웨어의 핵심 대응방안을 기록해본다. 내용중 일부는 랜섬웨어뿐만 아니라 대다수의 악성코드를 대응하는 방안이 될 수 있다.

    3. 관리적 대응방안

    컴퓨터 시스템을 체계적으로 관리하는 것만으로도 충분히 대응할 수 있다. 관리적 대응방안에는 다음 두 가지 형태로 분류할 수 있다. 예방 관리는 말 그대로 랜섬웨어 감염으로부터 예방할 방안이며, 대비 관리는 랜섬웨어에 감염된 후에 대비할 방안이다.

    3.1. 예방 관리

    3.1.1. 소프트웨어 보안 업데이트

    주로 듣는 질문들을 정리해보면 다음과 같다.

    • 어떻게 랜선만 꼽혀있는데 악성코드에 감염되나요?
    • 웹 사이트 서핑만 했는데 악성코드에 감염될 수 있나요?
    • 문서를 열고 스크립트와 같은 추가 기능을 차단했는데도 악성코드에 감염될 수 있나요?

    위 질문의 대답은 "" 이다. 이러한 악성코드 감염이 가능한 이유는 소프트웨어 취약성(Vulnerability) 때문이다. 취약성을 정확한 개념은 아니지만 쉽게 설명하면 "공격자 마음대로 명령한다." 정도로 볼 수 있다. 이는 네트워크 기준으로 로컬인가, 근거리인가, 원거리인가는 중요하지 않다. 어느 기준이든 위험한 공격 방식이며, 당연한 이야기지만 셋 중에서 원거리 네트워크로 사용할 수 있는 취약성이 가장 위험하다.

    어? 너 취약하네? 너 내가 가리키고 있는 저 파일 다운로드하고 실행해!

    이번 이슈에 접목시켜보면 원거리 공격자가 SMB 버전1 프로토콜에 명령을 던졌을 때 취약하다면 랜섬웨어를 다운로드하고 실행하도록 명령할 수 있다. 물론 취약성이 존재하더라도 공격자가 시스템을 실제 운영하는 사용자만큼 명령을 전달할 수는 없다. 지속적이고 좀 더 용이하게 공격 명령을 구성하거나 이미 모든 명령을 포함한 형태로 한번에 명령하기 위해 악성코드를 감염시킨다. 따라서 취약성을 막는다면 악성코드 감염으로 부터 자유로울 수 있다.

    취약성을 막을 수 있는 가장 안전한 방법은 보안 업데이트를 통한 문제가 되는 소프트웨어의 패치를 진행하는 것이다. 이미 컴파일 된 파일을 패치하는 것은 매우 어렵다. 소스코드를 가지고 있는 회사에서 진행할 수 밖에 없기에 제조사의 보안 패치를 진행하는 것이 중요하다. 이번 워너크라이에 사용된 취약성은 마이크로소프트에서는 MS17-010, MITRE 기준으로 CVE-2017-0144로 명명되어 있다. 이 취약성은 2017년 3월 14일에 보안 패치를 진행했다. 정기적 보안패치나 자동 보안패치를 사용하며 다음 운영체제를 사용하는 사용자라면 이번 이슈에 영향을 받지 않았을 것이다.

    • 윈도우 XP Embedded (POSReady 2009 버전)
    • 윈도우 비스타
    • 윈도우 7
    • 윈도우 8.1
    • 윈도우 10 버전과 
    • 윈도우 서버 2008 & R2, 
    • 윈도우 서버 2012 & R2
    • 윈도우 서버 2016

    대규모 공격에 사용되는 취약성은 패치가 나와있는 취약성을 주로 사용한다. 간혹 패치되기 전에 취약성을 이용한 공격코드가 공개되었을 땐 네트워크 연결을 하지 않는 것이 답이 될 수 있지만, 이러한 상황은 아주 흔하지 않기에 보안 업데이트만 꾸준히해도 대부분의 공격을 막을 수 있다. 취약성을 사용하는 공격중에 웹을 이용한 대규모 공격은 드라이브-바이 다운로드(Drive-by Download) 공격이, 네트워크를 이용한 대규모 공격은 웜(Worm) 공격이 대표적인 케이스다.

    추가로 웹 사이트를 통한 감염의 대응방안에는 자바(Java), 어도비 플래시 플레이어(Adobe Flash Player) 등 마이크로소프트의 제품이 아닌 소프트웨어의 보안 업데이트도 필수로 진행한다.

    3.1.2. 레거시 시스템 제거

    레거시 시스템이란 정품을 사용하더라도 더 이상 서비스를 제공하지 않는 시스템을 의미한다. 예를 들어, 삼성의 마이마이 카세트 플레이어를 사용하고 있다해도 고장나면 삼성 서비스 센터에 카세트를 맡길 수 없다. 이미 오래된 제품이기 때문이다. 

    출처 - 위키트리

    운영체제 서비스가 종료된 버전은 앞으로도 취약성에 의해 문제가 발생할 것이고, 제품을 제작한 회사도 사건이 발생해야 보안 패치를 내놓을 것이다. 말 그대로 서비스가 종료되었기 때문이다. 다음 운영체제는 서비스가 종료된 운영체제로 워너크라이가 이슈가 되었던 13일 당일에 보안 패치할 수 있는 파일을 공개했다.

    • 윈도우 XP SP2
    • 윈도우 XP SP3
    • 윈도우 서버 2003
    • 윈도우 8

    결론적으로 서비스가 중단된 레거시 시스템을 사용하지 않는 것이 중요하다. 어쩔 수 없이 사용해야만 한다면, 확실한 접근제어가 필요하다. 레거시 시스템을 사용하는 아이피와 포트를 면밀히 조사하여 접근을 허용하고 그 외 아이피와 포트는 모두 차단한다.

    3.1.3. 백신 소프트웨어 운영

    백신 소프트웨어 운영을 무시해서는 안된다. 분명 백신은 악성코드 샘플이 수집되어야 분석한 정보를 바탕으로 차단할 수 있기 때문이다. 다르게 이야기하면 경험기반 차단으로 볼 수 있다. 랜섬웨어의 경우 감염된 이후 대응은 의미없을 수 있다. 하지만, 만약 백신 회사에서 미리 악성코드를 분석해 차단했다면 감염되지 않았을 것이다. 그 가능성에 기대해 운영한다.

    또 다른 백신 회사에서는 위에서 언급한 취약성 코드도 차단하기도 한다. 이미 네트워크단에서 차단하기에 감염이 발생하지 않는다. 이 경우 백신 회사에서 운영체제 깊은 부분까지 손봐야하기에 고도의 작업이 동반될 수 있다. 이 부분을 안정적으로 개발하지 않는다면 운영체제가 망가질 수 있기 때문이다. 이러한 제품군은 기존의 백신 제품들 보다 2배 정도 더 비싸다. 하지만 이러한 종류의 백신 가격은 평균적으로 1년 기준 5만원 안팍의 가격을 하기에 투자할만하다. 참고로 이런 형태의 제품군을 업체에서는 인터넷 시큐리티라고 부른다.

    세상에는 참 많은 백신이 있다. 국내 동향에 맞는 악성코드도 좋지만 다양한 차단 방법을 제시하는 해외 기업의 제품을 이용하는 것도 좋다. 사용자마다 언급하는 백신의 장단점이 다르기에 이 포스트에서는 특정 제품을 언급하지는 않는다. 2017 안티바이러스 TOP 10으로 선정한 다음 블로그를 참고해보는 것도 좋다. 아래 그림을 클릭하면 링크로 이동한다.

    3.1.4. 랜섬웨어에 특화된 소프트웨어 사용

    트로이목마나 스파이웨어 등 특정 악성코드에 특화된 솔루션이 존재한다. 랜섬웨어도 동일하게 특화된 솔루션이 있다. 여기서 소개하는 제품은 국내 제품이다. 안티 익스플로잇 제품이나 안티 랜섬웨어 제품은 개인적인 생각으로 국내 제품을 이용하는 것이 좋다. 오랜기간 서비스한 제품이 아닌 경우가 많기에 문제가 야기되면 제작자와 직-간접적으로 소통하여 문제를 해결하기 쉽기 때문이다.

    A. 앱체크(AppCheck)

    앱체크는 CheckMAL에서 만든 제품으로 일반 제품은 무료로 이용할 수 있고, 더 기능이 많은 Pro 버전은 1PC 1년 기준 22,000원이다. 다만 랜섬웨어에 특화되어 있기에 백신 제품과 함께 써야한다. 아래 링크를 클릭하면 홈페이지로 이동한다.

    B. NAR(Nuri Anti-Ransom)

    NAR은 누리랩에서 만든 제품으로 아직 공개되진 않았지만 랜섬웨어에 특화된 차단하는 솔루션이다. 감염행위는 일어나지만 이를 탐지와 동시에 악성 행위와 그 산출물에 관련있는 파일을 신속히 삭제하고 일부 암호화된 파일은 복구하는 구조를 가진다. 자세한 내용과 이번 워너크라이 차단 영상은 케이엘테크놀로지 사이트에서 확인할 수 있으며, 1 PC 1년 기준 가격과, 무료 및 유료 정책, 그리고 무료와 유료로 구분된다면 이 둘의 기능적 차이가 어떨지 기대된다.

    3.1.5. 이메일 관리

    이메일 보안 솔루션을 이용하는 것도 좋으며, 의심스러운 파일은 모두 무시하는 것이 중요하다. 모르는 사람에게 온 이메일은 미리보기 기능을 이용하는 것도 좋다. 첨부파일을 다운로드 받을 경우 확장자 검증을 확실히 해야한다. 확장자 검증은 다음 이미지의 "알려진 파일 형식의 파일 확장명 숨기기"가 기본으로 활성화되어 있기에 해제한 후 사용한다.

    대중적인 구글, 네이버, 다음으로 들어온 메일은 기본적으로 필터링하는 것이 좋다. 기본적으로 실행파일을 첨부하는 것을 자제하는 문화가 정착되는 것이 중요하다.

    3.1.6. 운영 관리

    A. 원격 접속 프로그램의 기본 접속 계정과 비밀번호 변경

    아직 발생하진 않았지만, 원격 접속 프로그램(텔넷, SSH)을 통해 로그인하여 랜섬웨어를 설치하는 웜 형태가 나타날 수 있다. 이러한 이슈는 이미 사물인터넷을 이용한 DDoS 공격으로 유명한 미라이(Mirai) 봇넷이 있다. 만약 공격자가 DDoS 공격을 위한 좀비 악성코드가 아닌 랜섬웨어를 설치하려 했다면 충분히 가능한 내용이다.

    로그인이 가능한 이유는 취약성은 아니다. 사용자가 제대로 설정하지 않은 기본 계정과 비밀번호로 접근하기 때문이다. 공장에서 혹은 제조사에서 제조한 새로운 서비스나 시스템을 구매하여 사용할 경우 필히 이를 변경한다.

    B. 지속적인 보안공지 확인과 권고 이행

    정보보안 전문업체나 국가 기관에서 지속적으로 사이버 위협을 조사하고 대응할 수 있는 방안을 권고한다. 이를 지속적으로 확인하고 이행하는 것이 안전한 시스템을 운영하는데 도움된다. 우리나라에서는 보호나라를 이용하는 것을 추천한다. 아래 그림을 클릭하면 보호나라 사이트로 이동한다.

    3.2. 대비 관리

    3.2.1. 백업 관리

    중요 파일 백업은 항상 들어오던 말이다. 문제는 대부분의 대응방안에서 정기적으로 백업하라고 하지만, 백업한 디바이스랑 연결은 어떻게 해야할지, 클라우드 백업은 어떻게 해야하는지 설명하지 않는다. 

    A. 물리적 시스템을 이용한 백업

    먼저 랜섬웨어는 연결되어 있는 모든 파일시스템을 읽고 암호화하기에 백업이 끝난 물리적 디바이스와 연결을 끊어야 한다. 아무리 백업을 잘해 놓았더라도 백업시스템 마저 랜섬웨어로 피해를 받는다면 복구할 방법은 희박하다. 공유 폴더도 안전하지 않으며, 매번 접근하기 위해 아이피나 도메인을 외우기도 힘들다. 적어도 계정 정보는 기억시켜두고, 패스워드를 입력하여 접근후 백업하고, 백업이 끝나면 연결 해제하는 것을 추천한다.

    B. 클라우드 시스템을 이용한 백업

    클라우드 시스템은 대중적으로 가장 많이 사용하는 원드라이브, N클라우드, 구글 클라우드를 조사했다. 



    먼저 마이크로소프트 원 드라이브에 대해 알아보자. 일부 사용자는 오피스 문서만 작성하여 원 드라이브에 저장하고, 문서를 작성할 때 마다 버전관리를 했기에 복구할 수 있다고 자신할 수 있지만, 문서 버전관리를 이용한 복구는 문서를 열람해서 진행하기에 열리지 않는 암호화된 문서에서는 사용할 수 없는 기능이다. 또 다른 기능으로 로컬에서 삭제했더라도, 클라우드의 휴지통에 가면 삭제된 데이터를 복구할 수 있다. 이러한 형태를 이용하면 복구 가능성은 높아진다. 암호화된 새로운 파일을 생성하고 암호화되지 않은 파일을 삭제하는 형태로 동작하는 랜섬웨어도 존재하기 때문이다. 확률로 계산해야 하기에 도박으로 선택할 필요는 없다. 원 드라이브를 사용하는 사용자 입장에서 가장 좋은 방법은 원 드라이브 소프트웨어를 설치하여 운영하지 않고, 귀찮더라도 브라우저를 통해서만 이용하는 것을 추천한다.

    네이버의 N드라이브는 어떨까.

    N드라이브에도 원 드라이버처럼 버전관리가 가능하다. 다행이도 오피스군에만 한정되어 있진 않지만, 내용을 읽을 수 있는 파일에 한해서만 제공한다. 예를 들어 설치 파일이나 압축 파일은 버전관리로 복구할 수 없다. 다시 말해서 랜섬웨어에 의해 암호화된 파일은 복구할 수 없다. 원 드라이브와 마찬가지로 랜섬웨어가 암호화된 파일을 생성하고 원본 파일을 삭제한다면 휴지통에서 복구할 수 있다. 결론은 위에 동일하기에 N드라이브도 소프트웨어를 설치하여 운영하지 않고, 귀찮더라도 브라우저를 통해서만 이용하는 것을 추천한다.

    구글 드라이브도 위에 동일하다. 동일하게 소프트웨어 형태로 설치하지 않고 브라우저를 통해 이용하는 것을 추천한다. NAS를 자체 클라우드로 분류한다면, 자체 클라우드를 구매할 때 동기화 프로그램을 제공하는 서비스 이용을 추천한다.

    3.2.2. 복원 관리

    시스템 복원을 대응방안으로 제시하는 경우도 있지만, 100% 신뢰할 수 없다. 시스템 복원은 윈도우 비스타 이후 볼륨 섀도우 카피(Volume Shadow Copy)를 사용하는데, 일부 랜섬웨어는 이 볼륨 섀도우 카피를 삭제하는 명령을 포함한다. 이런 랜섬웨어를 만났다면 롤백을 이용한 복구를 할 수 없다. 

    그렇다고해서 무조건 사용하지 않는다는 것은 아니다. 복원할 수 있는 상황도 있을 수 있으니 하나의 대응책으로 사용하는 것이 좋다.

    3.2.3. 차단 및 대응

    이번 워너크라이 랜섬웨어의 취약성 대응방안으로 SMB 프로토콜이 사용하는 UDP 포트 137, 138 TCP 포트 139, 445 포트를 차단하고 네트워크를 연결하도록 설명한다. 그리고 여러 업체의 대응방안에서 포트도 차단하고 SMB 서비스도 사용 중단하여 대응하도록 언급 하지만, 둘 중에 하나만 진행해도 무방하다. 취약한 서비스를 사용하지 않는다면 취약성을 이용한 공격을 사용할 수 없기 때문이다.

    만약 어떤 포트를 차단해야할지 모른겠다면, 80 포트와 443 포트를 기억하자. 이 두 포트는 HTTP와 HTTPS 프로토콜이 사용하는 포트로 윈도우 업데이트는 이 포트를 사용한다. 따라서 이 두 포트를 제외한 모든 포트를 차단하고, 윈도우 업데이트를 진행한 다음 차단을 해제하는 것도 하나의 방법이다.

    4. 마무리

    지금까지 이야기한 대응방안은 랜섬웨어에 포커싱 맞춰 이야기했지만, 다른 악성코드를 대응하는 것에도 도움이 되는 방안이다. 만약 잘못된 대응방안, 현실을 고려하지 않은 상황들, 놓친 대응 방안을 댓글로 남겨주시면 포스팅 내용에 추가하여 이 글을 자세히 읽은 분들에게 도움이 될 수 있도록 하겠다.

    혹시나 늦게라도 MS17-010 취약성을 점검하고 대응하고 싶다면, 다음 사이트를 이용하길 바란다.

    5. 추가 내용

    랜섬웨어에 대한 여러 소문들이 있다. 가장 많이 들은 이야기는 다음 두개이며, 댓글로 문의하시면 답변하겠다. 재미있는 질문은 지속적으로 수정하고 추가할 예정이다.

    A. 결제해도 파일을 복구해주지 않는다.

    일부 사실이다. 하지만 약 80~90% 비율로 해제해 주는 공격자가 더 많다. 그 이유는 시장경제 논리에 따르는데, 랜섬웨어에 감염된 피해자가 결제를 통해 해제를 하지 않는 문화가 자리잡으면 신뢰받지 못해 결제를 하지 않게된다. 자연스레 공격자는 수익이 줄어들 수 밖에 없에 기를 쓰고 복구해주려고 노력한다. 재미있는 사례중 하나로 복구에 실패하면 비용을 환급해주기도 한다. 하지만 왜 이런 이야기를 언론에서 이야기하는가 하면, 수익을 통해 더욱 강력한 악성코드나 공격에 재활용되어 악순환 구조가 만들어지기 때문이다.

    이번 워너크라이의 지불과 관련한 기사가 있으니 참고하기 바란다.

    B. 복구 업체는 복구할 수 있다.

    사실이 아니다. 이슈가 될 정도로 강력한 랜섬웨어의 경우 기술적으로 복구할 수 있는 방법이 안타깝지만 없다. 결국 랜섬웨어 복구 업체의 대부분은 자체적인 방법으로 복구하는 것이 아닌, 공격자에게 결제하여 복구하는 서비스로 위장한다. 물론 결제를 해야만하는 상황이고, 결제하는 방법이 어렵다면 대행 업체를 이용하는 것도 좋다. 그간 결제를 대행하면서 친절히 복구해주는 그룹과 먹튀하는 그룹을 기업 내부적으로 목록화해서 관리하고 있기 때문이다.

    복구업체에 관한 부정적인 기사가 있으니 참고하기 바란다.

    C. 감염되면 절대 복구할 수 없다.

    사실이 아니다. 랜섬웨어의 피해를 복구할 수 있는 방법은 여러가지 있다. 이 방법에는 백업이나 복원 그리고 지불을 통한 복구는 언급하진 않는다.

    • 랜섬웨어 분석을 통해 암호키를 추출 - 랜섬웨어 제작자의 실력 부족으로 나타나는 현상으로 파일 암호키를 파일로 작성하거나 메모리에 암호키가 기록된 경우 그리고 개발자가 고정된 암호키를 사용하는 경우 추출 가능하다.
    • 국제적 민관 합동으로 암호키를 수집한 경우 - 국제적 수사기관이 랜섬웨어 유포자를 검거하고, 유포자가 가지고 있는 키관리 서버를 얻게되면 보안전문업체에게 키를 제공하여 파일을 복구할 수 있는 도구를 제작하는 구조를 가진다. 이 경우 언제 체포될지 모르고, 체포되더라도 서버를 파괴시킬 수도 있기에 언제까지 기다리고 있을 수 만은 없다. 이와 관련하여 대표적인 사이트는 nomoreransom가 있다.


    'Information Security > Malware' 카테고리의 다른 글

    Is malware same mean Korean word 악성코드?  (0) 2018.12.14
    랜섬웨어 대응방안  (5) 2017.05.17
    [보고서] Mirai Botnet  (0) 2016.12.26
    도메인 쉐도잉 (Domain Shadowing)  (0) 2015.03.17
    Sweet Orange exploit kit  (0) 2014.09.02
    공다팩(Gondad EK) 분석 #04  (2) 2014.08.14
    1. Favicon of https://tasda.tistory.com BlogIcon Threat Collector 2017.05.18 06:13 신고

      kall 점검관련 https://securityonline.info/exploit-windows-machine-ms-17-10-easy-like-ms08_067/ 링크도 도움이 될듯합니다.

    2. Favicon of https://tasda.tistory.com BlogIcon Threat Collector 2017.05.18 07:04 신고

      덕분에 좋은 정보 많이 얻어갑니다. 감사합니다.

    3. Favicon of http://moneycoach.kr/ BlogIcon 소액결제 현금화 2017.12.07 03:35

      감사합니다 ~~~

    목차

    1. 개요

    2. 설치

    2.1. 기본 패키지 설치

    2.2. CVE-Search 다운로드

    2.3. 파이썬3 라이브러리 설치

    3. 운영

    1. 개요

    정보보안 인텔리전스에서 CVE는 어떤 위협이 존재하며 이러한 위협이 위험으로써의 가능성을 파악하기에 중요한 자원이다. CVE는 Common Vulnerabilities and Exposures의 약자로 취약점을 식별하고 관리하기 위한 고유 스키마를 의미한다. 여기서 설치하려는 CVE-SEARCH는 이미 HKWT-2016-0001에서 다룬적이 있지만, 일부 잘못된 내용과, 버전 업그레이드가 되었기에 이 문서에서 다시 정리한다.

    게스트 스펙 - CVE-Search Server

    • 운영체제: 우분투 16.04.02 서버 AMD64
    • CPU: 가상 CPU 4코어
    • 메모리: 1GBB
    • 아이피: 192.168.0.

    2. 설치

    2.1. 기본 패키지 설치

    CVE-Search는 기본으로 파이썬3를 사용한다. 따라서 라이브러리 설치할 때 파이썬3에 설치한다. 데이터베이스는 몽고DB를 사용하는데 설치할 버전은 2.X 버전이다. 우분투 기본 저장소에서 2.X 버전을 제공하니 단순하게 설치할 수 있다.

    sudo apt-get install vim git mongodb python3-pip redis-server

    2.2. CVE-Search 다운로드

    이제 git을 이용하여 CVE-Search 소스코드를 다운로드한다. Latest Release가 안정적이니 이 버전을 다운로드한다.

    git clone -b v2.1 https://github.com/cve-search/cve-search

    잘 다운로드 받았는지 확인하려면 git 명령으로 확인한다. commit에 있는 해시값의 앞 18247fd가 아래 그림의 내용과 동일하다는 것을 알 수 있다.

    cd ~/cve-search

    git show

    commit 18247fd56fca63ebbe29303a0b47e8626f47984c

    Merge: 1fe9fa2 46cca81

    Author: Alexandre Dulaunoy <a@foo.be>

    Date:   Mon Jun 13 16:58:31 2016 +0200


        Merge pull request #170 from adulau/master


        Many fixes

    2.3. 파이썬3 라이브러리 설치

    파이썬3 라이브러리는 cve-search 디렉터리의 requirements.txt를 이용하여 설치한다.

    sudo pip3 install -r ~/cve-search/requirements.txt

    설치하는 파이썬3 라이브러리는 다음과 같다.

    • PyMongo
    • Flask
    • Flask-PyMongo
    • Flask-Login
    • Tornado
    • Whoosh
    • Redis
    • Python-dateutil
    • passlib
    • feedformater
    • Whoosh
    • irc
    • sleekxmpp
    • Werkzeug
    • Jinja2
    • itsdangerous
    • click

    3. 운영

    이제 CVE-Search에서 사용될 정보를 가져와서 몽고DB에 저장하는 작업을 진행한다. 먼저 데이터베이스를 생성한다. -p 옵션을 사용하며, 이를 통해 뼈대가되는 CVE 코드를 2002년부터 최신까지 가져온다. 데이터베이스에 데이터를 업데이트하거나 제어하는 과정은 cve-search/sbin 디렉터리에 있는 파이썬 코드로 진행한다. 

    ~/cve-search/sbin/python3 db_mgmt.py -p

    Database population started

    Importing CVEs for year 2002

    Importing CVEs for year 2003

    Importing CVEs for year 2004

    Importing CVEs for year 2005

    Importing CVEs for year 2006

    Importing CVEs for year 2007

    Importing CVEs for year 2008

    Importing CVEs for year 2009

    Importing CVEs for year 2010

    Importing CVEs for year 2011

    Importing CVEs for year 2012

    Importing CVEs for year 2013

    Importing CVEs for year 2014

    Importing CVEs for year 2015

    Importing CVEs for year 2016

    Importing CVEs for year 2017

    다음으로 CPE 딕셔너리를 다운로드한다. CPE 딕셔너리는 Common Platform Enumeration 약자로 컴퓨터 시스템에 존재하는 응용 프로그램, 운영 체제, 하드웨어 장치 등의 클래스를 설명하고 식별하기 위해 표준화한 것이다. CPE는 2.2 버전과 2.3 버전을 제공하며 XML 스키마로 정보를 공식적으로 제공한다.

    ~/cve-search/sbin/python3 db_mgmt_cpe-dictionary.py

    마지막으로 다양한 사이트에서 CVE와 연관있는 정보를 가져온다.

    ~/cve-search/sbin/db_updater.py -c

    CVE와 연관있는 데이터는 다음과 같은 사이트에서 가져온다.

    • cves (Common Vulnerabilities and Exposure items) - source NVD NIST
    • cpe (Common Platform Enumeration items) - source NVD NIST
    • vendor (Official Vendor Statements on CVE Vulnerabilities) - source NVD NIST
    • cwe (Common Weakness Enumeration items) - source NVD NIST
    • capec (Common Attack Pattern Enumeration and Classification) - source NVD NIST
    • ranking (ranking rules per group) - local cve-search
    • d2sec (Exploitation reference from D2 Elliot Web Exploitation Framework) - source d2sec.com
    • MITRE Reference Key/Maps - source MITRE reference Key/Maps
    • ms - (Microsoft Bulletin (Security Vulnerabilities and Bulletin)) - source Microsoft
    • exploitdb (Offensive Security - Exploit Database) - source offensive security
    • info (metadata of each collection like last-modified) - local cve-search
    • via4 VIA4CVE cross-references.



    'Information Security > OpenSource' 카테고리의 다른 글

    CVE-SEARCH v.REV  (0) 2017.05.12
    How to install Cuckoo Sandbox 2.0.x  (31) 2017.05.08
    CVE-SEARCH  (1) 2016.06.29
    How to install Viper 1.3-dev  (0) 2016.04.04
    Mobile Security Framework  (0) 2016.03.02
    Cuckoo Sandbox 2.0 RC1 Release  (0) 2016.01.22

    목차

    1. 개요

    이 문서는 볼라티리티(Volatility)를 이용한 메모리 분석에서 악성코드를 찾기 위한 방법 중 하나로, 화이트리스트 기반으로 메모리 이미지를 구성하고 변경사항을 찾는 방법으로 메모리의 기준점(Baseline)을 구성하기 위한 내용이다. 아직 기준점 구성을 해보지 않았지만, SANS에서 잘 정리된 문서가 있어 이를 번역했다. 참고로 이 문서는 2014년에 작성되어 있기에 최신 볼라티리티 버전과 상이하여 실습에 문제가 발생할 우려가 있다.

    원문 - https://www.sans.org/reading-room/whitepapers/forensics/creating-baseline-process-activity-memory-forensics-35387

    2. 소개

    SANS의 고급 포렌식 분석과 침해사고 과정(Lee & Tilbury, 2013)은 침해 지표 확인을 위한 메모리 검사 프로세스를 정의한다. 불량 프로세스 식별, 프로세스 객체 분석, 네트워크 아티팩트 검토, 코드 삽입의 증거 찾기, 루트킷의 흔적 확인 그리고 의심스러운 프로세스와 드라이버를 덤프하는 총 6 단계로 구성된다. 

    분석가는 불량 프로세스를 식별과 함께 실행중인 프로세스, 부모 프로세스 그리고 시작 지점을 확인한다. 다음과 같은 질문을 생각하며 확인해보자.

    • 프로세스가 있어야만 하나요?
    • 부모 프로세스는 무엇이며 예상되는 동작은 무엇인가요?
    • 운영체제가 시작할 때 프로세스가 함께 시작하나요?

    프로세스 객체를 분석할 때 분석가는 실행 파일의 이름, 실행 파일의 경로, 프로세스 시작에 사용되는 커맨드라인 매개변수 그리고 이와 관련된 보안 식별자를 검사한다. 다음과 같은 질문을 생각하며 검사한다. 

    • 실행 파일이 예상했던 디렉터리에서 시작했나요?
    • 커맨드라인 매개변수는 예상할 수 있는 매개 변수인가요?
    • 프로세스가 실행되는 상황은 예상했는가요?
    • 이러한 실행은 시스템 권한으로 실행되었나요?
    • 아니면 사용자로 실행되었나?

    분석가는 메모리에 로드된 동적 링크 라이브러리(DLL)와 커널 모듈로 볼 수 있다.

    그런 다음 분석가는 estableshed로 연결된 네트워크와 이를 처리하는 프로세스를 검사한다. 

    • 비정상적인 네트워크 연결이 있나요?
    • 프로세스와 관련된 네트워크 연결이 시작되었나요?

    다음과 같은 의문을 가지고 위 세가지에서 공통적으로 이상한점을 찾는다.

    • 어떤 것이 비정상적이다는 것을 알 수 있을까?
    • 자문자답을 위해, 추측하는 것을 어떻게 알 수 있을까?

    문헌과 웹을 통한 검색은 출발지점만 제공받을 수 있다. 한 가지 해결책은 예상되는 것의 기준점을 수립하고, 이 기준점에 부합하는지 알아보는 것이다. 이러한 기준선을 사용하여 예상되는 프로세스를 필터링하여 예상하지 못한 부분에 집중할 수 있다.

    이 문서는 다음과 같은 책을 참고하여 기준점을 수립하는데서 시작한다.

    그런 다음 일련의 Windows 2008 R2 서버의 기준점을 테스트하여 유효성을 검사하고 수정한다.

    3. Windows Server 2008 R2 기준점 생성과 유효성 검사

    3.1. 데이터 수집 접근법

    3.1.1. 메모리 확보

    메모리 분석은 메모리 이미지를 확보하는 것에서 시작한다. 메모리를 확보하는데 사용할 수 있는 여러 도구가 있다. 여기서는 MoonSols의 win66dd.exe를 사용한다. 가장 좋은 방법은 수집 프로세스가 분석중인 시스템에 미치는 영향을 최소화하기 위해 외부 장치를 이용하여 메모리 이미지를 수집하는 것이다. 조사 대상 시스템의 디스크에 이미지를 생성하면 중요한 데이터를 덮어쓰거나 잃을 수 있다. 수집되는 메모리의 양을 감안할 때 기가 바이트 이상의 데이터에 해당할 수 있다. 이 문서의 분석은 디스크 내용이 아닌 메모리 이미지에만 관심이 있으므로 서버의 하드 드라이브에 있는 c:\tmp 디렉터리에서 win66dd.exe를 실행하여 메모리를 확보한다.

    3.1.2. 메모리 분석

    메모리 이미지를 분석하는데 사용할 수 있는 여러 도구가 있다. 이 문서에서는 파이썬으로 작성된 오픈소스 메모리 분석 프레임워크인 볼라티리티(Volatility Wiki, 2013)를 선택했다. 볼라티리티는 윈도우 XP 서비스팩 2 메모리 이미지(Volatility Wiki, 2013)를 분석하는 것을 제외하고, 명령을 실행 할 때 메모리 이미지 형식을 정의해야 한다. 분석에 사용된 형식인 Win2008R2SP1x64는 vol.py -f mem.img imageinfo 명령을 실행하여 정의한다. 여기서 mem.img는 분석하려는 이미지 파일의 이름이다. 모든 볼라티리 명령에 이미지 형식을 포함하는 대신 다음과 같이 VOLATILITY_PROFILE를 환경변수에 설정하여 사용할 수 있다.

    export VOLATILITY_PROFILE=Win2008R2SP1x64

    3.1.3. 서버 설치

    Windows Server 2008 R2는 Vmware Tools를 설치한 VMware Workstation 9.0에 설치했다. Windows의 모든 변형은 하나의 설치 ISO 이미지로부터 설치했다. systeminfo | find "OS" 명령을 사용하여 Windows Server 2008 R2 버전이 6.1.760 서비스팩 1 빌드 7601인 것을 알 수 있다. 운영체제 업데이트는 적용하지 않았다.

    3.2. 초기 기준점 구축

    메모리에서 프로세서의 기준점을 구성하기 위한 시작은 부팅할 때 운영체제가 로드하는 핵심 프로세스와 사용자가 로그인할 때 로그되는 프로세스에 대한 기본적인 이해가 필요하다. 이는 Windows Internals 6th Part 1, 2 (Russinovich, Solomon & Ionescu, 2012a, 2012b)에서 자세히 설명되어 있다. 중요한 윈도우 프로세스의 요약은 The Art of Memory Forensics (Ligh, Case, Levy, and Walters, 2014), Windows Processes or Die Trying (Olsen, 2014) literature 뿐만 아니라 SANS DFIR Digital Forensics and Incident Response Poster (Pilkington & Lee, 2014) 문서에서 찾을 수 있다.

    메모리에서 프로세스 목록에 나타나는 첫 번째 프로세스는 시스템이다. 시스템은 커널 프로세서를 위한 컨테이너다. (Ligh, Case, Levy 그리고 Walters, 2014) 정적 프로세스 ID가 4이고 부모 프로세스는 없다. 시스템이 세션 관리자(smss.exe)를 시작한다. (Olsen, 2014)

    smss.exe는 부팅 시퀀스의 첫 번째 사용자 모드 프로세스다. 세션 생성과 관련있다. 부팅 시 두 개의 세션이 생성된다. 세션 0은 시스템과 윈도우 서비스가 소유한 프로세스를 포함한다. 세션 2는 사용자가 소유한 프로세스를 포함(Ligh, Case, Levy 그리고 Walters, 2014)한다. smss.exe는 각 세션에 대해 클라이언트/서버 런타임 하위 시스템(csrss.exe)을 복사하는데서 시작한다. 윈도우 초기화 프로세스 (wininit.exe)를 시작하여 세션 0을 초기화하고 윈도우 로그온 프로세스(winlogon.exe)를 시작하여 사용자 세션을 초기화한다. 각 사용자 로그온에는 로그온할 때 만들어지는 고유한 세션 ID가 있다. 새 세션을 만들 때, smss.exe는 자체적으로 세션을 초기화하고 종료하는 자식 인스턴스를 만든다. 이러한 이유로, csrss.exe, wininit.exe 그리고 winlogon.exe의 부모 프로세스 아이디(PPID)는 메모리에 있는 프로세스(Pikington & Lee, 2014)의 프로세스 ID (PID)로 다시 매핑되지 않는다. 

    Wininit.exe는 세션 0에서 실행되는 사용자 모드 초기화 프로세스를 수행한다. 여기에는 로컬 보안 기관 (lsass.exe), 세션 관리자 서비스 로드(lsm.exe), 그리고 시스템 제어 관리자(service.exe)가 포함된다. lsass.exe는 로컬 보안 정책을 담당한다. lsm.exe는 새 세션을 시작할 때 smss.exe를 호출하여 터미널 서버 세션을 관리한다. (Olsen, 2014)

    윈도우는 대부분의 운영체제처럼 대화형 사용자와 관련없는 프로세스가 있다. 대신 사용자 로그온과 독립적으로 실행된다. 이들은 서비스라고 부르고, services.exe에 의해 실행된다. 윈도우는 각 서비스를 자체 프로세스로 실행하지 않는다. 대신 서비스를 공통적인 특성과 함께 서비스 그룹으로 그룹화한다. 이러한 서비스 그룹은 svchost.exe라는 일반 프로세스를 사용하여 시작된다. 여러 svchost.exe가 메모리에서 실행되는 것을 볼 수 있다. svchost.exe는 실행될 서비스 그룹을 지정하는 -k 매개 변수와 함께 시작된다. 표 1에 나열된 내용은 Windows Internals Part 1 (Russinovich, Solomon & Ionescu, 2012a)에 정의된 주요 시스템 그룹으로 초기 기준점을 채운다.

    윈도우 부팅 프로세스에 대한 설명에서 볼 수 있듯이 프로세스 메모리 분석을 위한 초기 기준점을 구축할 수 있다. 표 2는 메모리 덤프에서 찾을 수 있는 세션 0에 관한 프로세스를 요약한다.

    대화형 로그온 프로세스의 책임은 Winlogon.exe가 가진다. 이는 LoginUI.exe 프로세스 실행으로 사용자 로그온 상호 작용, 암호 변경 그리고 워크스테이션 잠금과 해제를 관리한다. (Russinovich, Solomon & Ionescu, 2012a).  사용자가 성공적으로 인증되면 레지스트리 값 HKLM\SOFTWARE\Microsoft\Windows NT\Current Version\Winlogon\shell에 정의된 쉘 프로세스가 시작된다. 기본 쉘 프로세스는 Explorer.exe다. 이는 Userinit 프로세스에 의해 시작되고, explorer.exe가 시작되면 끝난다. 따라서, 부모 프로세스 실행을 찾을 수 없다. 원격 데스크톱을 통해 로그인한 사용자의 경우, 콘솔이 아닌 사용자의 세션과 관련된 rdpclip.exe 프로세스가 메모리에서 발견된다.

    사용자 세션은 다음과 같은 세 가지 상태를 가진다.

    • 사용자가 로그인되어 있지 않다

    • 사용자가 콘솔로 로그인되어 있다

    • 사용자가 원격으로 로그인 되어 있다

    표 3은 이러한 각각의 상태에서 볼 수 있는 프로세스를 보여준다. 이는 사용자 로그온 프로세스를 위한 기초 기준점을 구성한다. 부모 프로세스의 종류가 등재되지 않기에 PPID는 메모리에서 프로세스로 다시 추적하지 않는다. 사용자 세션이 세션 1, 세션 2 등 될 수 있기 때문에 모든 세션을 사용자 세션으로 참조한다.

    프로세스뿐만 아니라 메모리 포렌식에 대한 기준점을 만들려면 동적 링크 라이브러리, 모듈 그리고 드라이버에 대해 생각해봐야 한다. 동적 링크 라이브러리(DLLs)가 가지는 코드와 자원은 여러 프로세스 사이에 공유된다. 모듈은 운영체제 커널에서 로드되는 코드다. 마지막으로 드라이버는 하드웨어 장치와 통신할 수 있게 컴퓨터에서 허용하는 코드다. (Ligh, Case, Levy, 그리고 Walters, 2014). 이러한 각각의 아티팩트는 많은 수의 객체로 구성되기에, 검색보다는 실제 시스템을 분석하여 기준점을 만드는 것을 추천한다.

    포렌식 분석가가 관심을 갖는 또 다른 속성은 프로세스에 의해 개방되어 연결되는 네트워크다. 이들은 netscan 플러그인을 사용하여 볼 수 있다. 기준점의 네트워크 연결 부분은 실제 시스템에서 데이터를 수집한 다음 분석하여 구성한다.

    3.3. 일반적인 윈도우 서버 2008 R2에 대한 기본점 테스트

    초기 메모리 기준점을 만들었으므로, 실제 시스템에서 수집한 메모리 이미지와 비교하여 유효성을 검사하고 개선할 수 있다. 첫 번째 Windows 2008 R2 서버는 작업 그룹의 일부인 일반 표준 설치를 사용하여 구축했다. Windows 미디어를 이용한 새로운 설치이기에 "깨끗"한 것으로 간주한다.

    3.3.1. 불량 프로세스 식별

    메모리 분석 방법론의 1 단계는 불량 프로세스 찾는 것으로 시작한다. 깨끗한 서버이기에 불량 프로세스가 없어야 하므로 초기 기준점에 포함되지 않은 프로세스를 찾는다.

    아래 출력은 볼라티리티의 pslist 플러그인을 사용하여 출력한 프로세스 목록이다. 페이지에 맞추기 위해 cut 명령을 사용하여 관련이 없는 출력은 제거했다. 부팅 프로세스를 로그온 프로세스와 분리하기 위해 이들 사이에 시간차를 두었다. 이는 아래에 표시된 시작 시간 열에서 볼 수 있다.

    $ vol.py -f win2008r2-01-a.img pslist | cut -c 20-76,84-104
    Volatility Foundation Volatility Framework 2.3.1
    Name                    PID   PPID   Thds     Hnds   Sess Start
    -------------------- ------ ------ ------ -------- ------ --------------------
    System                    4      0     76      460 ------ 2014-06-22 13:26:36
    smss.exe                232      4      2       29 ------ 2014-06-22 13:26:36
    csrss.exe               324    316      9      335      0 2014-06-22 13:26:42
    csrss.exe               376    368     10      189      1 2014-06-22 13:26:43
    wininit.exe             384    316      3       79      0 2014-06-22 13:26:43
    winlogon.exe            420    368      3       96      1 2014-06-22 13:26:43
    services.exe            480    384      8      189      0 2014-06-22 13:26:44
    lsass.exe               488    384      6      530      0 2014-06-22 13:26:45
    lsm.exe                 496    384     10      145      0 2014-06-22 13:26:45
    svchost.exe             588    480     11      345      0 2014-06-22 13:26:48
    svchost.exe             656    480      6      233      0 2014-06-22 13:26:49
    svchost.exe             744    480     13      288      0 2014-06-22 13:26:49
    svchost.exe             788    480     26      824      0 2014-06-22 13:26:49
    svchost.exe             836    480     10      508      0 2014-06-22 13:26:50
    svchost.exe             884    480      7      198      0 2014-06-22 13:26:51
    svchost.exe             928    480     16      429      0 2014-06-22 13:26:51
    svchost.exe             216    480     17      289      0 2014-06-22 13:26:53
    spoolsv.exe             904    480     13      313      0 2014-06-22 13:26:54
    svchost.exe            1040    480      3       46      0 2014-06-22 13:26:56
    vmtoolsd.exe           1096    480      9      253      0 2014-06-22 13:26:56
    TPAutoConnSvc.         1292    480     10      140      0 2014-06-22 13:26:59
    dllhost.exe            1456    480     13      194      0 2014-06-22 13:27:01
    msdtc.exe              1612    480     12      147      0 2014-06-22 13:27:03
    svchost.exe            1752    480      5       67      0 2014-06-22 13:29:01
    taskhost.exe           1276    480      5      118      1 2014-06-22 13:34:03
    TPAutoConnect.         1328   1292      5      126      1 2014-06-22 13:34:03
    conhost.exe            1556    376      1       30      1 2014-06-22 13:34:03
    dwm.exe                1116    884      3       65      1 2014-06-22 13:34:03
    explorer.exe            848    968     15      478      1 2014-06-22 13:34:03
    vmtoolsd.exe           2012    848      7      184      1 2014-06-22 13:34:06
    cmd.exe                 332    848      1       20      1 2014-06-22 13:39:31
    conhost.exe            1228    376      2       36      1 2014-06-22 13:39:31
    win64dd.exe             868    332      2       49      1 2014-06-22 13:52:33

    위에 굵게 표시된 줄은 기준점에 존재하지 않은 프로세스를 의미한한다. 이들은 더욱 면밀히 조사해야할 대상이다.

    서버는 Vmware Workstation에서 실행되므로, 일반적인 윈도우 설치의 일부가 아닌 VMware와 관련된 프로세스가 존재할 수 있다. 이와 관련해서 실제로 TPAutoConnSvc.exe, TPAutoConnect.exe 그리고 vmtoolsd.exe 세 프로세스를 볼 수 있다. VMware와의 관계에 관한 단서는 프로세스 정보를 자세히 검토할 때 제공받는다. 이 프로세스들은 각각 dlllist 플러그인을 통해 출려된 것 처럼 C:\Program Files\VMware\VMware Tools\  디렉터리에서 실행된다.

    $ vol.py -f win2008r2-01-a.img dlllist -p 1096 | grep -B 1 -i "command line"
    Volatility Foundation Volatility Framework 2.3.1
    vmtoolsd.exe pid: 1096
    Command line : "C:\Program Files\VMware\VMware Tools\vmtoolsd.exe"
    $ vol.py -f win2008r2-01-a.img dlllist -p 1292 | grep -B 1 -i "command line"
    Volatility Foundation Volatility Framework 2.3.1
    TPAutoConnSvc. pid: 1292
    Command line : "C:\Program Files\VMware\VMware Tools\TPAutoConnSvc.exe"
    $ vol.py -f win2008r2-01-a.img dlllist -p 1328 | grep -B 1 -i "command line"
    Volatility Foundation Volatility Framework 2.3.1
    TPAutoConnect. pid: 1328
    Command line : TPAutoConnect.exe -q -i vmware -a COM1 -F 30

    VMware Knowledge base (2014)는 가상 인쇄 모듈이 설치될 때 TPAutoConnect.exeTPautoConnSvc.exe가 시작되는 것으로 설명한다. 세션 0의 서비스 제어 관리자(SCM)가 TPAutoConnSvc.exe를 시작하는 것을 pslist 출력에서 확인할 수 있다. TPAutoConnect.exe는 세션 1을 초기화 할 때 TPAutoConnSvc.exe에 의해 시작된다. VMware 도구 서비스 (vmtoolsd.exe)는 게스트 윈도우 운영 체제 (VMware, 2011)에 설치된다. pslist 결과에서 세션 0과 세션 1 모두에서 실행중인 vmtoolsd.exe의 인스턴스가 있음을 알 수 있다. 따라서 이러한 프로세스는 기준점에 추가된다.

    일부 메모리 아티팩트는 사용자 로그온에 의해 도입된다. LogonUI.exe는 사용자가 로그인했기에 존재하지 않는다. 대신 taskhost.exe, conhost.exe 그리고 dwm.exe를 포함하여 로그인 성공과 관련된 여러 프로세스를 볼 수 있다. 이러한 프로세스는 초기 기준점의 일부가 되지 않는다. 표 4는 사용자가 로그온 할 때 시작되는 프로세스의 수정된 목록을 제공한다.

    또 다른 그룹의 아티팩트는 실제 메모리 획득과 관련있다. cmd.exewin64dd.exe (PID 868)가 메모리 이미지 수집을 위해 시작하기 위해 관리 모드(PID - 332)로 실행 되었다. cmd.exe가 실행되면 윈도우는 지원 프로세스인 콘솔 호스트(conhost.exe - PID 1228)도 실행된다. 이러한 마지막 그룹은 프로세스 기준점의 일부는 아니지만 메모리 이미지를 분석 할 때 고려해야할 사항이다.

    spoollvc.exe, dllhost.exe 그리고 msdtc.exe 프로세스가 초기 기준점의 일부가 아닌 services.exe에 의해 시작되었다. dllhost.exe는 COM(Component Object Model) 개체 (Startup Programs Database, 2014c) 관리와 연결된다. msdtc.exe는 분산 트랙잭션 코디네이터 (Startup Programs Database, 2014d)다. spoolsvc.exe는 스풀러 서비스이며 인쇄와 관련있다. (Startup Programs Database, 2014e)

    3.3.2. 프로세스 개체 분석

    메모리 분석 방법론의 2 단계는 프로세스 개체를 검사하는 것이다. 볼라티리티 플러그인으로 dlllist을 사용할 것이다. 매우 장황하기 때문에 명령을 통해 smss.exe라는 하나의 프로세스 (PID는 232)로 제한했다. 이 명령의 출력은 아래에서 볼 수 있듯이 프로세스를 시작하는데 사용된 명령과 프로세스와 관련된 DLL에 대한 정보를 제공한다.

    $ vol.py -f win2008r2-01-a.img -p 232 dlllist
    Volatility Foundation Volatility Framework 2.3.1
    ************************************************************************
    smss.exe pid:    232
    Command line : \SystemRoot\System32\smss.exe
    
    Base                         Size      LoadCount Path
    ------------------ -------------- -------------- ----
    0x0000000047a50000        0x20000         0xffff \SystemRoot\System32\smss.exe
    0x0000000077120000        0x1a9000        0xffff C:\Windows\SYSTEM32\ntdll.dll

    관심 가져야할 부분은 프로세스 이름, 프로세스 ID 그리고 프로세스를 시작하는데 사용된 커맨드라인이므로 dlllist 플러그인에서 grep을 사용하여 커맨드라인을 출력하여 축약된 결과물을 생성할 수 있다.

    $ vol.py -f win2008r2-01-a.img dlllist | grep -B 1 -i "command line"
    Volatility Foundation Volatility Framework 2.3.1
    smss.exe pid: 232
    Command line : \SystemRoot\System32\smss.exe
    --
    csrss.exe pid: 324
    Command line : %SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows
    SharedSection=1024,20480,768 Windows=On SubSystemType=Windows
    ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3
    ServerDll=winsrv:ConServerDllInitialization,2 ServerDll=sxssrv,4
    ProfileControl=Off MaxRequestThreads=16
    --
    csrss.exe pid: 376
    Command line : %SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows
    SharedSection=1024,20480,768 Windows=On SubSystemType=Windows
    ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3
    ServerDll=winsrv:ConServerDllInitialization,2 ServerDll=sxssrv,4
    ProfileControl=Off MaxRequestThreads=16
    --
    wininit.exe pid: 384
    Command line : wininit.exe
    --
    winlogon.exe pid: 420
    Command line : winlogon.exe
    --
    services.exe pid: 480
    Command line : C:\Windows\system32\services.exe
    --
    lsass.exe pid: 488
    Command line : C:\Windows\system32\lsass.exe
    --
    lsm.exe pid: 496
    Command line : C:\Windows\system32\lsm.exe
    --
    svchost.exe pid: 588
    Command line : C:\Windows\system32\svchost.exe -k DcomLaunch
    --
    svchost.exe pid: 656
    Command line : C:\Windows\system32\svchost.exe -k RPCSS
    --
    svchost.exe pid: 744
    Command line : C:\Windows\System32\svchost.exe -k LocalServiceNetworkRestricted
    --
    svchost.exe pid: 788
    Command line : C:\Windows\system32\svchost.exe -k netsvcs
    --
    svchost.exe pid: 836
    Command line : C:\Windows\system32\svchost.exe -k LocalService
    --
    svchost.exe pid: 884
    Command line : C:\Windows\System32\svchost.exe -k LocalSystemNetworkRestricted
    --
    svchost.exe pid: 928
    Command line : C:\Windows\system32\svchost.exe -k NetworkService
    --
    svchost.exe pid: 216
    Command line : C:\Windows\system32\svchost.exe -k LocalServiceNoNetwork
    --
    spoolsv.exe pid: 904
    Command line : C:\Windows\System32\spoolsv.exe
    --
    svchost.exe pid: 1040
    Command line : C:\Windows\system32\svchost.exe -k regsvc
    --
    vmtoolsd.exe pid: 1096
    Command line : "C:\Program Files\VMware\VMware Tools\vmtoolsd.exe"
    --
    TPAutoConnSvc. pid: 1292
    Command line : "C:\Program Files\VMware\VMware Tools\TPAutoConnSvc.exe"
    --
    dllhost.exe pid: 1456
    Command line : C:\Windows\system32\dllhost.exe /Processid:{02D4B3F1-FD88-11D1-
    960D-00805FC79235}
    --
    msdtc.exe pid: 1612
    Command line : C:\Windows\System32\msdtc.exe
    --
    svchost.exe pid: 1752
    Command line : C:\Windows\system32\svchost.exe -k
    LocalServiceAndNoImpersonation
    --
    taskhost.exe pid: 1276
    Command line : "taskhost.exe"
    --
    TPAutoConnect. pid: 1328
    Command line : TPAutoConnect.exe -q -i vmware -a COM1 -F 30
    --
    conhost.exe pid: 1556
    Command line : \??\C:\Windows\system32\conhost.exe
    --
    dwm.exe pid: 1116
    Command line : "C:\Windows\system32\Dwm.exe"
    --
    explorer.exe pid: 848
    Command line : C:\Windows\Explorer.EXE
    --
    vmtoolsd.exe pid: 2012
    Command line : "C:\Program Files\VMware\VMware Tools\vmtoolsd.exe" -n vmusr
    --
    cmd.exe pid: 332
    Command line : "C:\Windows\system32\cmd.exe"
    --
    conhost.exe pid: 1228
    Command line : \??\C:\Windows\system32\conhost.exe
    --
    win64dd.exe pid: 868
    Command line : win64dd /f win2008r2-01-a.img

    프로세스를 시작하고 services.exe에서 시작한 서비스 그룹을 식별하는데 사용되는 명령의 유효성을 검사하기 위해 dlllist 플러그인의 출력을 기준점과 비교한다. 이를 통해 DcomLaunch, PRCSS 그리고 regsvc의 세 가지 서비스 그룹을 신속하게 파악할 수 있다. 이들 모드 기준점에 존재하지 않아 추가될 필요가 있다.

    프로세스 분석 단계에는 프로세스가 예외 계정으로 실행중인지 확인하는 작업을 포함한다. 이 정보는 볼라이티리 플러그인 getsid를 통해 작업할 수 있다. 아래의 예는 PID가 488인 하나의 프로세스에 대한 출력을 보여준다.

    $ vol.py -f win2008r2-01-a.img -p 488 getsids
    Volatility Foundation Volatility Framework 2.3.1
    lsass.exe (488): S-1-5-18 (Local System)
    lsass.exe (488): S-1-5-32-544 (Administrators)
    lsass.exe (488): S-1-1-0 (Everyone)
    lsass.exe (488): S-1-5-11 (Authenticated Users)
    lsass.exe (488): S-1-16-16384 (System Mandatory Level)

    볼라티리티 출력은 아래와 같이 uniq 명령을 사용하여 축약할 수 있다. 다음은 각 프로세스와 그 프로세스를 실행시킨 계정의 목록이다. uniq 명령은 완벽하지 않다. 시스템에 몇 줄의 중복 선이 표시되지만 분석 프로세스는 여전히 단순하다.

    $ vol.py -f win2008r2-01-a.img getsids | uniq -w 18
    Volatility Foundation Volatility Framework 2.3.1
    System (4): S-1-5-18 (Local System)
    System (4): S-1-1-0 (Everyone)
    System (4): S-1-5-11 (Authenticated Users)
    System (4): S-1-16-16384 (System Mandatory Level)
    smss.exe (232): S-1-5-18 (Local System)
    csrss.exe (324): S-1-5-18 (Local System)
    csrss.exe (376): S-1-5-18 (Local System)
    wininit.exe (384): S-1-5-18 (Local System)
    winlogon.exe (420): S-1-5-18 (Local System)
    services.exe (480): S-1-5-18 (Local System)
    lsass.exe (488): S-1-5-18 (Local System)
    lsm.exe (496): S-1-5-18 (Local System)
    svchost.exe (588): S-1-5-18 (Local System)
    svchost.exe (656): S-1-5-20 (NT Authority)
    svchost.exe (744): S-1-5-19 (NT Authority)
    svchost.exe (788): S-1-5-18 (Local System)
    svchost.exe (836): S-1-5-19 (NT Authority)
    svchost.exe (884): S-1-5-18 (Local System)
    svchost.exe (928): S-1-5-20 (NT Authority)
    svchost.exe (216): S-1-5-19 (NT Authority)
    spoolsv.exe (904): S-1-5-18 (Local System)
    svchost.exe (1040): S-1-5-19 (NT Authority)
    vmtoolsd.exe (1096): S-1-5-18 (Local System)
    TPAutoConnSvc. (1292): S-1-5-18 (Local System)
    dllhost.exe (1456): S-1-5-18 (Local System)
    msdtc.exe (1612): S-1-5-20 (NT Authority)
    svchost.exe (1752): S-1-5-19 (NT Authority)
    taskhost.exe (1276): S-1-5-21-2236604341-3981238657-2714753860-1000
    TPAutoConnect. (1328): S-1-5-21-2236604341-3981238657-2714753860-1000
    conhost.exe (1556): S-1-5-21-2236604341-3981238657-2714753860-1000
    dwm.exe (1116): S-1-5-21-2236604341-3981238657-2714753860-1000
    explorer.exe (848): S-1-5-21-2236604341-3981238657-2714753860-1000
    vmtoolsd.exe (2012): S-1-5-21-2236604341-3981238657-2714753860-1000
    cmd.exe (332): S-1-5-21-2236604341-3981238657-2714753860-1000
    conhost.exe (1228): S-1-5-21-2236604341-3981238657-2714753860-1000
    win64dd.exe (868): S-1-5-21-2236604341-3981238657-2714753860-1000

    위 출력에서 한 가지 주의 사항은 두 개의 SID가 볼라티리티에 의해 NT Authority로 나열된다는 것이다. S-1-5-19는 로컬 서비스로 변환되고 S-1-5-20은 네트워크 서비스(Microsoft Knowledge Base, 2013a)로 변환된다. "-1000"으로 끝나는 긴 번호를 가진 SID는 사용자와 연결된다. 따라서 taskhost.exe, cmd.exe 그리고 win64dd.exe와 같은 프로세스는 사용자 컨텍스트에서 실행 중이다.

    예상대로 svchost를 사용하여 시작된 여러 서비스에는 서비스 그룹의 요구사항에 따라 다른 SID가 존재한다. 또한 로그온 한 사용자와 관련된 프로세는 사용자 SID와 연결된다.

    분석할 또 다른 메모리 아티팩트는 DLL이다. dlllist 플러그인으로 생성된 DLL의 전체 목록은 다소 길다. 앞에서 설명한 것 처럼 DLL 외에 다른 정보를 포함한다. DLL을 나열하는 각 행은 "0x"로 시작하고 dlllist 플러그인의 출력은 DLL만 나열하도록 생성하는 장점을 이용할 수 있다. 다음 명령은 DLL이 들어있는 행을 나열한 다음 계산한다. 전체적으로 1,411개의 DLL이 확인되었다.

    $ vol.py -f win2008r2-01-a.img dlllist | grep "^0x" | cut -c 20-37,57- | wc -l
    Volatility Foundation Volatility Framework 2.3.1
    1411

    DLL 목록을 검사하면, 여러 프로세스가 동일한 DLL을 사용하기에 중복되어 있다는 사실이 명확해진다. 목록을 정렬한 다음 고유한 행만 표시하고 대소문자를 무시함으로써 목록을 상당히 줄일 수 있다. 아래의 명령은 메모리 이미지에서 370개로 축소한 것을 보여준다.

    $ vol.py -f win2008r2-01-a.img dlllist | grep "^0x" | cut -c 20-37,57- | sort | uniq -i | wc -l
    Volatility Foundation Volatility Framework 2.3.1
    370

    기준점에서 370개 항목을 나열하는 표를 작성하는 대신 다른 메모리 이미지에서 실행된 동일한 명령의 출력과 비교할 수 있는 파일을 작성하여 기준점에 나열되지 않은 DLL을 찾는다. 파일은 속하지 않은 항목이 없는지 확인하기 위해 검토되어야 한다. 하나의 항목인 win64dd.exe는 메모리 수집 프로세스의 일부로 도입되었기에 제거해야 한다. DLL 기준점을 만드는데 사용되는 명령은 다음과 같다.

    $ vol.py -f win2008r2-01-a.img dlllist | grep "^0x" | cut -c 20-37,57- | sort | uniq -i > dll-baseline-01.lst
    Volatility Foundation Volatility Framework 2.3.

    유사하게, 볼라티리티는 모듈이라고 불리는 커널 모듈을 메모리에 나열할 수 있게 플러그인을 제공한다. 출력된 결과를 검토하면 메모리에 147개의 모듈이 있다. 비슷한 접근 방식을 사용하여 아래와 같이 모듈의 기준점을 작성한다.

    $ vol.py -f win2008r2-01-a.img modules | cut -c 20-40,60- | grep "0x" | sort | uniq -i | wc -l
    Volatility Foundation Volatility Framework 2.3.1
    147
    $ vol.py -f win2008r2-01-a.img modules | cut -c 20-40,60- | grep "0x" | sort | uniq -i > module-base-01.lst
    Volatility Foundation Volatility Framework 2.3.1
    $ cat module-base-01.lst | wc -l
    147

    파일은 속하지 않은 항목이 없는지 확인하기 위해 검토헤애 한다. Win64dd.sys는 메모리 수집 프로세스의 아티팩트이기에 제거되었다.

    3.3.3. 네트워크 아티팩트 검토

    Windows Vista와 Windows Server 2008부터 마이크로소프트는 IANA 권장 사항(Microsoft Knowledge Base, 2013c)에 따라 동적 포트 범위 할당을 1025부터 5000을 49152에서 65535로 변경했다. 볼라티리티의 netscan 플러그인은 열린 포트 목록과 해당 포트를 소유한 프로세스 목록을 제공한다. 각 svchost.exe 인스턴스를 소유하고 있는지 확인하기 위해 추가 분석을 수행한다. 예를 들어 다음을 고려한다.

    $ vol.py -f win2008r2-01-a.img netscan | cut -c 12-18,21-40,51-63,88-92,94-112 | uniq -w 20
    Volatility Foundation Volatility Framework 2.3.1
    Proto  Local Address        Foreign Addr  Pid      Owner
    TCPv4  0.0.0.0:49156        0.0.0.0:0     480      services.exe
    TCPv6  :::49156             :::0          480      services.exe
    TCPv4  0.0.0.0:445          0.0.0.0:0     4        System
    TCPv6  :::445               :::0          4        System
    TCPv4  0.0.0.0:47001        0.0.0.0:0     4        System
    TCPv6  :::47001             :::0          4        System
    TCPv4  0.0.0.0:49153        0.0.0.0:0     744      svchost.exe
    TCPv6  :::49153             :::0          744      svchost.exe
    TCPv4  0.0.0.0:49154        0.0.0.0:0     788      svchost.exe
    TCPv4  192.168.139.129:139  0.0.0.0:0     4        System
    TCPv4  0.0.0.0:135          0.0.0.0:0     656      svchost.exe
    TCPv6  :::135               :::0          656      svchost.exe
    TCPv4  0.0.0.0:49152        0.0.0.0:0     384      wininit.exe
    TCPv6  :::49152             :::0          384      wininit.exe
    TCPv4  0.0.0.0:49155        0.0.0.0:0     488      lsass.exe
    TCPv6  :::49155             :::0          488      lsass.exe
    TCPv4  0.0.0.0:49154        0.0.0.0:0     788      svchost.exe
    TCPv6  :::49154             :::0          788      svchost.exe
    UDPv4  0.0.0.0:5355         *:*           928      svchost.exe
    UDPv4  0.0.0.0:0            *:*           928      svchost.exe
    UDPv6  :::0                 *:*           928      svchost.exe
    UDPv4  0.0.0.0:123          *:*           836      svchost.exe
    UDPv6  :::123               *:*           836      svchost.exe
    UDPv4  0.0.0.0:123          *:*           836      svchost.exe
    UDPv4  0.0.0.0:0            *:*           836      svchost.exe
    UDPv6  :::0                 *:*           836      svchost.exe
    UDPv4  0.0.0.0:0            *:*           836      svchost.exe
    UDPv4  192.168.139.129:137  *:*           4        System
    UDPv4  0.0.0.0:5355         *:*           928      svchost.exe
    UDPv6  :::5355              *:*           928      svchost.exe

    표 5는 netscan 플러그인으로 식별되는 Windows Server 2008 R2가 여는 포트 목록이다. 이 목록은 초기 기준점을 설정하며 SMB(Server Message Block)와 NETBIOS를 비롯하여 보안상의 이유로 조직에서 사용하지 않도록 설정할 수 있는 일부 서비스를 포함한다.

    3.4. 연결된 윈도우 서버 2008 R2 부속 도메인에 대한 기준점 테스트

    다른 시스템에 대해 새롭게 수정한 기준점을 사용하여 프로세스를 반복적으로 검증하여 세부 사항을 조정한다. 기준점을 테스트하기 위해 두 번재 Windows Server 2008 R2는 도메인에 연결되어 있고 원격 로그온 사용을 통해 어떤 차이가 있는지 알 수 있는 예외와 함께 첫 번째 구성과 동일한 구성을 사용하여 만들었다. 이 이미지에서 두 명의 사용자는 원격으로 서버에 로그인하고 마이크로소프트 터미널 서버 연결(mstsc)을 사용하며 콘솔을 통해 하나를 사용한다. 메모리 이미지는 원격 사용자에 의해 생성했다.

    3.4.1. 불량 프로세스 식별

    우리의 분석은 불량 프로세스를 식별할 수 있도록 pslist 플러그인을 실행하여 프로세스 목록을 얻는 것에서 시작한다. 다음 사항을 고려한다.

    $ vol.py -f win2008r2-03-s1.img pslist | cut -c 20-53,70-76,84-114
    Volatility Foundation Volatility Framework 2.3.1
    Name                    PID   PPID   Sess Start
    -------------------- ------ ------ ------ ------------------------------
    System                    4      0 ------ 2014-07-28 01:26:59 UTC+0000
    smss.exe                224      4 ------ 2014-07-28 01:26:59 UTC+0000
    csrss.exe               316    308      0 2014-07-28 01:27:04 UTC+0000
    wininit.exe             368    308      0 2014-07-28 01:27:04 UTC+0000
    services.exe            472    368      0 2014-07-28 01:27:05 UTC+0000
    lsass.exe               480    368      0 2014-07-28 01:27:05 UTC+0000
    lsm.exe                 488    368      0 2014-07-28 01:27:05 UTC+0000
    svchost.exe             584    472      0 2014-07-28 01:27:10 UTC+0000
    svchost.exe             660    472      0 2014-07-28 01:27:11 UTC+0000
    svchost.exe             740    472      0 2014-07-28 01:27:11 UTC+0000
    svchost.exe             796    472      0 2014-07-28 01:27:11 UTC+0000
    svchost.exe             848    472      0 2014-07-28 01:27:12 UTC+0000
    svchost.exe             888    472      0 2014-07-28 01:27:12 UTC+0000
    svchost.exe             932    472      0 2014-07-28 01:27:13 UTC+0000
    svchost.exe             236    472      0 2014-07-28 01:27:14 UTC+0000
    spoolsv.exe             324    472      0 2014-07-28 01:27:15 UTC+0000
    svchost.exe            1092    472      0 2014-07-28 01:27:16 UTC+0000
    vmtoolsd.exe           1148    472      0 2014-07-28 01:27:16 UTC+0000
    svchost.exe            1412    472      0 2014-07-28 01:27:18 UTC+0000
    svchost.exe            1472    472      0 2014-07-28 01:27:18 UTC+0000
    TPAutoConnSvc.         1508    472      0 2014-07-28 01:27:19 UTC+0000
    dllhost.exe            1776    472      0 2014-07-28 01:27:22 UTC+0000
    msdtc.exe              1896    472      0 2014-07-28 01:27:23 UTC+0000
    svchost.exe            1204    472      0 2014-07-28 01:29:19 UTC+0000
    sppsvc.exe             1068    472      0 2014-08-02 20:10:58 UTC+0000
    TrustedInstall          252    472      0 2014-08-02 20:11:00 UTC+0000
    csrss.exe              3020   2956      1 2014-08-02 20:16:53 UTC+0000
    winlogon.exe           2896   2956      1 2014-08-02 20:16:53 UTC+0000
    taskhost.exe           1264    472      1 2014-08-02 20:17:25 UTC+0000
    dwm.exe                2328    888      1 2014-08-02 20:17:25 UTC+0000
    explorer.exe           1284   3068      1 2014-08-02 20:17:25 UTC+0000
    vmtoolsd.exe           1556   1284      1 2014-08-02 20:17:25 UTC+0000
    TPAutoConnect.         2712   1508      1 2014-08-02 20:17:25 UTC+0000
    conhost.exe            2856   3020      1 2014-08-02 20:17:25 UTC+0000
    csrss.exe              2232    376      2 2014-08-02 20:18:27 UTC+0000
    winlogon.exe           2124    376      2 2014-08-02 20:18:27 UTC+0000
    taskhost.exe           2116    472      2 2014-08-02 20:18:29 UTC+0000
    rdpclip.exe            2108   1412      2 2014-08-02 20:18:29 UTC+0000
    dwm.exe                2088    888      2 2014-08-02 20:18:29 UTC+0000
    explorer.exe           2708   1388      2 2014-08-02 20:18:29 UTC+0000
    vmtoolsd.exe           1124   2708      2 2014-08-02 20:18:29 UTC+0000
    TPAutoConnect.         2012   1508      2 2014-08-02 20:18:30 UTC+0000
    conhost.exe             672   2232      2 2014-08-02 20:18:30 UTC+0000
    cmd.exe                1268   2708      2 2014-08-02 20:18:40 UTC+0000
    conhost.exe            2904   2232      2 2014-08-02 20:18:40 UTC+0000
    win64dd.exe            2836   1268      2 2014-08-02 20:19:53 UTC+0000

    services.exe에 의해 시작된 두 개의 새 프로세스 sppsvc.exeTrustedInstall이 세션 0에 나타난다. sppsvc.exe는 마이크로소프트의 소프트웨어 보호 서비스며 윈도우와 마이크로소프트 응용 프로그램(Startup Programs Database, 2014a)을 위한 디지털 라이선스를 관리하는 것과 관련있다. TrustedInstaller.exe는 윈도우 모듈 설치 프로그램이며 윈도우 업데이트(Startup Programs Database, 2014b)와 관련있다. 이 프로세스는 시스템 부팅 직후에 만들어 졌으므로 추가 기준점에 표시되지 않았을 수 있다.

    두 개의 사용자 세션 1과 2를 검사할 때 기본 세션과 일관성 있음을 알 수 있다.

    3.4.2. 프로세스 개체 분석(Analyze Process Objects)

    다시 한번 dlllist 플러그인을 실행하여 프로세스 오브젝트 분석을 시작한다.

    $ vol.py -f win2008r2-03-s1.img dlllist | grep -B 1 -i "command line"
    Volatility Foundation Volatility Framework 2.3.1
    smss.exe pid: 224
    Command line : \SystemRoot\System32\smss.exe
    --
    csrss.exe pid: 316
    Command line : %SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows
    SharedSection=1024,20480,768 Windows=On SubSystemType=Windows
    ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3
    ServerDll=winsrv:ConServerDllInitialization,2 ServerDll=sxssrv,4
    ProfileControl=Off MaxRequestThreads=16
    --
    wininit.exe pid: 368
    Command line : wininit.exe
    --
    services.exe pid: 472
    Command line : C:\Windows\system32\services.exe
    --
    lsass.exe pid: 480
    Command line : C:\Windows\system32\lsass.exe
    --
    lsm.exe pid: 488
    Command line : C:\Windows\system32\lsm.exe
    --
    svchost.exe pid: 584
    Command line : C:\Windows\system32\svchost.exe -k DcomLaunch
    --
    svchost.exe pid: 660
    Command line : C:\Windows\system32\svchost.exe -k RPCSS
    --
    svchost.exe pid: 740
    Command line : C:\Windows\System32\svchost.exe -k LocalServiceNetworkRestricted
    --
    svchost.exe pid: 796
    Command line : C:\Windows\system32\svchost.exe -k netsvcs
    --
    svchost.exe pid: 848
    Command line : C:\Windows\system32\svchost.exe -k LocalService
    --
    svchost.exe pid: 888
    Command line : C:\Windows\System32\svchost.exe -k LocalSystemNetworkRestricted
    --
    svchost.exe pid: 932
    Command line : C:\Windows\system32\svchost.exe -k NetworkService
    --
    svchost.exe pid: 236
    Command line : C:\Windows\system32\svchost.exe -k LocalServiceNoNetwork
    --
    spoolsv.exe pid: 324
    Command line : C:\Windows\System32\spoolsv.exe
    --
    svchost.exe pid: 1092
    Command line : C:\Windows\system32\svchost.exe -k regsvc
    --
    vmtoolsd.exe pid: 1148
    Command line : "C:\Program Files\VMware\VMware Tools\vmtoolsd.exe"
    --
    svchost.exe pid: 1412
    Command line : C:\Windows\System32\svchost.exe -k termsvcs
    --
    svchost.exe pid: 1472
    Command line : C:\Windows\system32\svchost.exe -k
    NetworkServiceNetworkRestricted
    --
    TPAutoConnSvc. pid: 1508
    Command line : "C:\Program Files\VMware\VMware Tools\TPAutoConnSvc.exe"
    --
    dllhost.exe pid: 1776
    Command line : C:\Windows\system32\dllhost.exe /Processid:{02D4B3F1-FD88-11D1-
    960D-00805FC79235}
    --
    msdtc.exe pid: 1896
    Command line : C:\Windows\System32\msdtc.exe
    --
    svchost.exe pid: 1204
    Command line : C:\Windows\system32\svchost.exe -k
    LocalServiceAndNoImpersonation
    --
    sppsvc.exe pid: 1068
    Command line : C:\Windows\system32\sppsvc.exe
    --
    TrustedInstall pid: 252
    Command line : C:\Windows\servicing\TrustedInstaller.exe
    --
    csrss.exe pid: 3020
    Command line : %SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows
    SharedSection=1024,20480,768 Windows=On SubSystemType=Windows
    ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3
    ServerDll=winsrv:ConServerDllInitialization,2 ServerDll=sxssrv,4
    ProfileControl=Off MaxRequestThreads=16
    --
    winlogon.exe pid: 2896
    Command line : winlogon.exe
    --
    taskhost.exe pid: 1264
    Command line : "taskhost.exe"
    --
    dwm.exe pid: 2328
    Command line : "C:\Windows\system32\Dwm.exe"
    --
    explorer.exe pid: 1284
    Command line : C:\Windows\Explorer.EXE
    --
    vmtoolsd.exe pid: 1556
    Command line : "C:\Program Files\VMware\VMware Tools\vmtoolsd.exe" -n vmusr
    --
    TPAutoConnect. pid: 2712
    Command line : TPAutoConnect.exe -q -i vmware -a COM1 -F 30
    --
    conhost.exe pid: 2856
    Command line : \??\C:\Windows\system32\conhost.exe
    --
    csrss.exe pid: 2232
    Command line : %SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows
    SharedSection=1024,20480,768 Windows=On SubSystemType=Windows
    ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3
    ServerDll=winsrv:ConServerDllInitialization,2 ServerDll=sxssrv,4
    ProfileControl=Off MaxRequestThreads=16
    --
    winlogon.exe pid: 2124
    Command line : winlogon.exe
    --
    taskhost.exe pid: 2116
    Command line : "taskhost.exe"
    --
    rdpclip.exe pid: 2108
    Command line : rdpclip
    --
    dwm.exe pid: 2088
    Command line : "C:\Windows\system32\Dwm.exe"
    --
    explorer.exe pid: 2708
    Command line : C:\Windows\Explorer.EXE
    --
    vmtoolsd.exe pid: 1124
    Command line : "C:\Program Files\VMware\VMware Tools\vmtoolsd.exe" -n vmusr
    --
    TPAutoConnect. pid: 2012
    Command line : TPAutoConnect.exe -q -i vmware -a COM1 -F 30
    --
    conhost.exe pid: 672
    Command line : \??\C:\Windows\system32\conhost.exe
    --
    cmd.exe pid: 1268
    Command line : "C:\Windows\system32\cmd.exe"
    --
    conhost.exe pid: 2904
    Command line : \??\C:\Windows\system32\conhost.exe
    --
    win64dd.exe pid: 2836
    Command line : win64dd /f win2008r2-03-s1.img

    메모리 이미지에 두 개의 새로운 서비스, termsbcs와 서비스 그룹 NetworkServiceNetworkRestricted이 나타난다. 원격 데스크톱을 사용하도록 설정하면 이러한 문제가 발생할 수 있다. 다른 프로세스는 모두 기준점에 있고 실행 파일 경로는 정확하다.

    getsids 플러그인을 실행하면 프로세스가 실행중인 계정을 제공한다. termsvcs와 서비스 그룹 NetworkServiceNetworkRestricted은 네트워크 서비스에서 실행 중이다. 다른 모든 프로세스는 예상되는 계정에서 실행된다.

    $ vol.py -f win2008r2-03-s1.img getsids | uniq -w 18
    Volatility Foundation Volatility Framework 2.3.1
    System (4): S-1-5-18 (Local System)
    System (4): S-1-1-0 (Everyone)
    System (4): S-1-5-11 (Authenticated Users)
    System (4): S-1-16-16384 (System Mandatory Level)
    smss.exe (224): S-1-5-18 (Local System)
    csrss.exe (316): S-1-5-18 (Local System)
    wininit.exe (368): S-1-5-18 (Local System)
    services.exe (472): S-1-5-18 (Local System)
    lsass.exe (480): S-1-5-18 (Local System)
    lsm.exe (488): S-1-5-18 (Local System)
    svchost.exe (584): S-1-5-18 (Local System)
    svchost.exe (660): S-1-5-20 (NT Authority)
    svchost.exe (740): S-1-5-19 (NT Authority)
    svchost.exe (796): S-1-5-18 (Local System)
    svchost.exe (848): S-1-5-19 (NT Authority)
    svchost.exe (888): S-1-5-18 (Local System)
    svchost.exe (932): S-1-5-20 (NT Authority)
    svchost.exe (236): S-1-5-19 (NT Authority)
    spoolsv.exe (324): S-1-5-18 (Local System)
    svchost.exe (1092): S-1-5-19 (NT Authority)
    vmtoolsd.exe (1148): S-1-5-18 (Local System)
    svchost.exe (1412): S-1-5-20 (NT Authority)
    svchost.exe (1472): S-1-5-20 (NT Authority)
    TPAutoConnSvc. (1508): S-1-5-18 (Local System)
    dllhost.exe (1776): S-1-5-18 (Local System)
    msdtc.exe (1896): S-1-5-20 (NT Authority)
    svchost.exe (1204): S-1-5-19 (NT Authority)
    sppsvc.exe (1068): S-1-5-20 (NT Authority)
    TrustedInstall (252): S-1-5-18 (Local System)
    csrss.exe (3020): S-1-5-18 (Local System)
    winlogon.exe (2896): S-1-5-18 (Local System)
    taskhost.exe (1264): S-1-5-21-4249217695-1663262354-3778214704-1110
    dwm.exe (2328): S-1-5-21-4249217695-1663262354-3778214704-1110
    explorer.exe (1284): S-1-5-21-4249217695-1663262354-3778214704-1110
    vmtoolsd.exe (1556): S-1-5-21-4249217695-1663262354-3778214704-1110
    TPAutoConnect. (2712): S-1-5-21-4249217695-1663262354-3778214704-1110
    conhost.exe (2856): S-1-5-21-4249217695-1663262354-3778214704-1110
    csrss.exe (2232): S-1-5-18 (Local System)
    winlogon.exe (2124): S-1-5-18 (Local System)
    taskhost.exe (2116): S-1-5-21-4249217695-1663262354-3778214704-1109
    rdpclip.exe (2108): S-1-5-21-4249217695-1663262354-3778214704-1109
    dwm.exe (2088): S-1-5-21-4249217695-1663262354-3778214704-1109
    explorer.exe (2708): S-1-5-21-4249217695-1663262354-3778214704-1109
    vmtoolsd.exe (1124): S-1-5-21-4249217695-1663262354-3778214704-1109
    TPAutoConnect. (2012): S-1-5-21-4249217695-1663262354-3778214704-1109
    conhost.exe (672): S-1-5-21-4249217695-1663262354-3778214704-1109
    cmd.exe (1268): S-1-5-21-4249217695-1663262354-3778214704-1109
    conhost.exe (2904): S-1-5-21-4249217695-1663262354-3778214704-1109
    win64dd.exe (2836): S-1-5-21-4249217695-1663262354-3778214704-1109

    두 번째 이미지에서 DLL을 분석하기 위해 위에서 사용한 동일한 방법으로 1,990개의 인스턴스를 식별한다. 다시 말하자면, 이 숫자는 중복을 분류하고 제거하여 신경써야할 부분을 크게 줄일 수 있다.

    $ vol.py -f win2008r2-03-s1.img dlllist | grep "^0x" | cut -c 20-37,57- | wc -l
    Volatility Foundation Volatility Framework 2.3.1
    1990
    $ vol.py -f win2008r2-03-s1.img dlllist | grep "^0x" | cut -c 20-37,57- | sort | uniq -i | wc -l
    Volatility Foundation Volatility Framework 2.3.1
    397

    다음으로 DLL 기본 파일과 동일한 형식으로 397개의 DLL을 포함하는 파일을 생성한다. 다시 검사할 때 wc를 사용하여 라인 수를 계산했다.

    $ vol.py -f win2008r2-03-s1.img dlllist | grep "^0x" | cut -c 20-37,57- | sort | uniq -i > dll-03.lst
    Volatility Foundation Volatility Framework 2.3.1
    $ cat dll-03.lst | wc -l
    397

    DLL 목록에서 기준점에 적용하여 검토할 DLL의 수를 37개로 줄일 수 있다. 이는 1,990개를 검토하는 것 보다 효율적이다.

    $ cat dll-03.lst dll-baseline-01.lst dll-baseline-01.lst | sort | uniq -iu | wc -l
    37

    분석에서, uniq 명령의 여러 속성을 활용하여 비교했다. -i 매개 변수는 대소 문자를 무시하도록 사용했다. -u 매개 변수는 uniq에게 고유한 행만 출력하도록 사용했다. 고유성이 dll-03.lst 파일의 내용에 의한 것인지 확인하기 위해, 기준점 파일은 두번 추가하여 사용했다.

    37개의 DLL을 검토하는 과정은 합리적으로 보인다. win64dd.exe 하나의 항목만 메모리 수집 프로세스에 의해 소개되었으므로 제거한다. 깨끗한 이미지에서 나온 것이므로 두 목록을 병합하여 DLL에 대한 새로운 기준점을 생성할 수 있다.

    $ cat dll-03.lst dll-baseline-01.lst | sort | uniq -i | wc -l
    406
    $ cat dll-03.lst dll-baseline-01.lst | sort | uniq -i > dll-baseline-02.lst
    $ cat dll-baseline-02.lst | wc -l
    406

    도메인 첨부 메모리 이미지에서 모듈의 개수를 확인하는 과정에서 153개의 모듈이 발견되었다. DLL과 동일한 방법을 사용하여 기준점에 없는 모듈 7개로 좁힐 수 있다. 관리할 수 있는 모듈 수를 조사할 수 있다.

    $ vol.py -f win2008r2-03-s1.img modules | cut -c 20-40,60- | grep "0x" | sort | uniq -i | wc -l
    Volatility Foundation Volatility Framework 2.3.1
    153
    $ vol.py -f win2008r2-03-s1.img modules | cut -c 20-40,60- | grep "0x" | sort | uniq -i > module-03.lst
    Volatility Foundation Volatility Framework 2.3.1
    $ cat module-03.lst | wc -l
    153
    $ cat module-03.lst module-base-01.lst module-base-01.lst | sort | uniq -iu | wc -l
    7

    기준점에 없었던 모듈은 아래와 같다. Win64dd.sys는 메모리 수집 프로세스의 아티팩트며 아래에 표시된 것 처럼 기준점에 속하지 않는다. 그 외 모듈은 다음과 같다.

    $ cat module-03.lst module-base-01.lst module-base-01.lst | sort | uniq -iu
    RDPDD.dll 0x48000 \SystemRoot\System32\RDPDD.dll
    rdpdr.sys 0x2e000 \SystemRoot\System32\drivers\rdpdr.sys
    RDPWD.SYS 0x39000 \SystemRoot\System32\Drivers\RDPWD.SYS
    spsys.sys 0x71000 \SystemRoot\system32\drivers\spsys.sys
    tdtcp.sys 0xb000 \SystemRoot\system32\drivers\tdtcp.sys
    tssecsrv.sys 0xf000
    \SystemRoot\System32\DRIVERS\tssecsrv.sys win64dd.sys 0x11000 \??\C:\temp\windd\win64dd.sys

    3.4.3. 네트워크 아티팩트 검토

    네트워크 아티팩트 분석은 netscan 플러그인을 사용하여 진행한다.

    $ vol.py -f win2008r2-03-s1.img netscan | cut -c 12-18,21-40,50-63,86-112 | sort | uniq -w 20
    Volatility Foundation Volatility Framework 2.3.1
    Proto  Local Address         Foreign Addr       Pid       Owner
    TCPv4  0.0.0.0:135           0.0.0.0:0          660       svchost.exe
    TCPv4  0.0.0.0:3389          0.0.0.0:0          1412      svchost.exe
    TCPv4  0.0.0.0:445           0.0.0.0:0          4         System
    TCPv4  0.0.0.0:47001         0.0.0.0:0          4         System
    TCPv4  0.0.0.0:49152         0.0.0.0:0          368       wininit.exe
    TCPv4  0.0.0.0:49153         0.0.0.0:0          740       svchost.exe
    TCPv4  0.0.0.0:49154         0.0.0.0:0          796       svchost.exe
    TCPv4  0.0.0.0:49173         0.0.0.0:0          472       services.exe
    TCPv4  0.0.0.0:49174         0.0.0.0:0          1472      svchost.exe
    TCPv4  0.0.0.0:49178         0.0.0.0:0          480       lsass.exe
    TCPv4  -:0                   24.217.239.1       480       lsass.exe
    TCPv4  192.168.139.102:139   0.0.0.0:0          4         System
    TCPv6  -:0                   18d9:ef0d:80:ffff:0 CLOSED                  48
    TCPv6  :::135                :::0               660       svchost.exe
    TCPv6  :::3389               :::0               1412      svchost.exe
    TCPv6  :::445                :::0               4         System
    TCPv6  :::47001              :::0               4         System
    TCPv6  :::49152              :::0               368       wininit.exe
    TCPv6  :::49153              :::0               740       svchost.exe
    TCPv6  :::49154              :::0               796       svchost.exe
    TCPv6  :::49173              :::0               472       services.exe
    TCPv6  :::49174              :::0               1472      svchost.exe
    TCPv6  :::49178              :::0               480       lsass.exe
    UDPv4  0.0.0.0:0             *:*                1472      svchost.exe
    UDPv4  0.0.0.0:123           *:*                848       svchost.exe
    UDPv4  0.0.0.0:4500          *:*                796       svchost.exe
    UDPv4  0.0.0.0:500           *:*                796       svchost.exe
    UDPv4  0.0.0.0:5355          *:*                932       svchost.exe
    UDPv4  127.0.0.1:57762       *:*                480       lsass.exe
    UDPv4  127.0.0.1:65282       *:*                796       svchost.exe
    UDPv4  192.168.139.102:137   *:*                4         System
    UDPv6  :::0                  *:*                1472      svchost.exe
    UDPv6  :::123                *:*                848       svchost.exe
    UDPv6  :::4500               *:*                796       svchost.exe
    UDPv6  :::500                *:*                796       svchost.exe
    UDPv6  :::5355               *:*                932       svchost.exe

    netscan의 결과를 기준으로 기준점과 비교해 보면 세 가지로 구분할 수 있다. 

    • 포트는 일반 포트, 
    • 서버가 도메인에 연결되어 있지 않을 때 사용되는 포트 그리고 
    • 서버가 도메인에 연결될 때 사용되는 포트로 나눌 수 있다. 

    이러한 내용은 표 6에 요약되어 있다. 이 목록의 유효성을 검사하기 위해 IIS 서버, 도메인 컨트롤러 그리고 SQL 서버를 포함한 추가 구성을 사용하는 추가 작업이 필요하다.

    기준점에서 네트워크 포트를 사용할 때 주의할 점이 있다. 동적 포트 범위의 포트를 찾을 때 다른 프로세스가 이미 포트를 사용하고 있는 경우, 다른 서버 구성에 따라 동적 포트가 할당될 수 있다.

    4. 결론

    이 문서는 메모리 분석을 위한 기준점을 구축하는 방법을 설명했다. 이 방법은 시작일 뿐이다. 추가로 다른 Windows Server 2008 R2 구성을 사용하여 유효성을 검사하고 빌드하려면 더 많은 작업을 수행해야 한다. 유사한 방법을 사용하여 Windows 7, Windows 8 그리고 Windows Server 2012을 위한 기준점을 구축할 수 있다.

    기준점의 가치는 빌딩과 테스트하는 과정에서 입증되었다. 예상되는 프로세스를 문서화하여 기준점에 없지만 있어야 했던 프로세스를 신속하게 식별할 수 있었다. 예기치 않은 시스템을 식별하기 위해 손상된 시스템의 메모리 이미지에 기준점을 쉽게 사용할 수 있다. 이를 통해 찾은 프로세스와 DLL 목록으로 의심스러운 프로세스에 신속하게 집중할 수 있다. 기준점의 사용 가치는 검사할 DLL을 1,990개에서 37개로 줄이고 검사할 모듈을 153개에서 7개의 줄여 훨씬 더 효율적임을 증명한 것에 있다.

    일반적으로 기준점은 여러 소스의 메모리 이미지를 일반적으로 분석하는 것에 유용할 수 있다. 조직의 경우 표준 구성으로 맞춘 기준점을 사용하면 분석에 많은 시간을 절약할 수 있다. VMware Workstation에서 서버를 구현함으로써 생성된 아티팩트가 기준점에 영향을 주는 것을 확인했다. 이러한 확인을 확장하여 안티 바이러스 소프트웨어와 같은 조직의 표준 구성에 대해 다른 아티팩트를 생각해야 한다. 따라서 이러한 형태의 아티팩트를 기준점에 설정하면 분석에 상당한 시간을 절약할 수 있다.

    5. 참고 자료


    'Information Security > Incident Response' 카테고리의 다른 글

    Baseline Memory Analysis(번역)  (0) 2017.05.10

    목차

    1. 쿡쿠 샌드박스 구축

    1.1. 기본 패키지 및 C 라이브러리 설치

    1.2. 쿡쿠 코어 설치

    1.3. 샌드박스 구성

    1.3.1. 가상머신 다운로드 및 가져오기

    1.3.2. 파이썬 2.7 다운로드 및 설치

    1.3.3. pillow 라이브러리 설치

    1.3.4. 네트워크 구성 및 아이피 고정

    1.3.5. 방화벽/업데이트 비활성화

    1.3.6. Administrator 계정 활성화 및 로그인

    1.3.7. UAC 비활성화

    1.3.8. agent.py 실행과 가상머신 스냅샷 구성

    1.4. 웹 인터페이스 데이터베이스 구성

    1.5. 쿡쿠 설정

    2. 쿡쿠 샌드박스 기본 운영

    2.1. 쿡쿠 코어 실행

    2.2. 쿡쿠 웹 서버 실행

    3. 마무리

    4. 참고 사이트



    1. 쿡쿠 샌드박스 구축

    쿡쿠 샌드박스를 운영하는데 있어 최소한으로 설치하는 방법을 언급하려고 한다. 최소한이라는 것은 다양한 기능을 활용하지 않고, 윈도우 악성코드만 자동으로 분석하는 것에만 초점을 맞춘다는 의미다. 우선 쿡쿠 샌드박스를 테스트하기 위해 다음과 같은 환경에서 테스트했다. 호스트 운영체제에 가상머신 소프트웨어인 VMware을 설치하고, 가상머신으로 우분투 16.04 데스크톱과 서버를 설치한다. 그리고 가상머신 안에 다시 가상머신으로 윈도우 7으로 구성한다. 별도로 운영체제를 설치하는 과정은 설명하지 않는다.

    호스트 스펙

    • 운영체제: 윈도우 7 울티메이트 K SP1 64비트
    • 가상머신: VMware Workstation 12.5
    • CPU: i7-3630QM
    • 메모리: 16GB
    • 가상 아이피: 192.168.0.0/24

    게스트 1 스펙 - Cuckoo-Server

    • 운영체제: 우분투 16.04.2 데스크톱 64비트
    • CPU: 가상 CPU 8코어
    • 메모리: 4GB
    • 아이피: 192.168.0.200
    • 웹 포트: 8000

    게스트 2 스펙 - Cuckoo-DB-Server

    • 운영체제: 우분투 16.04.2 서버 64비트
    • CPU: 가상 CPU 4코어
    • 메모리: 1GB
    • 아이피: 192.168.0.251
    • DB 포트: 27018

    게스트 인 게스트 스펙 - Sandbox

    • 운영체제: 윈도우 7 엔터프라이즈 SP1 32비트
    • 가상머신: 버추얼박스(Virtualbox)
    • CPU: 가상 CPU 1코어
    • 메모리: 512MB
    • 아이피: 192.168.0.10

    본격적으로 쿡쿠 샌드박스를 설치하는데 이 구축은 크게 다섯 가지로 분류한다. 기본 패키지 & 라이브러리 설치 단계에서는 쿡쿠 샌드박스를 운영하기 위한 기본 도구와 라이브러리를 설치한다. 쿡쿠 코어 설치는 쿡쿠 샌드박스를 운영하는데 있어 필수적인 파이썬 라이브러리와 설정 파일을 구성한다. 샌드박스 구성은 쿡쿠 코어가 악성코드를 분석하기 위해 사용되는 안전한 환경인 샌드박스를 구성하는 것이다. 웹 인터페이스 데이터베이스 구성은 분석 결과를 표현하는 웹 인터페이스가 사용하는 데이터베이스를 구축한다. 마지막으로 쿡쿠 설정은 쿡쿠 엔진의 운영과 레포팅 기능 그리고 샌드박스 구성을 연동하기 위한 진행이다.

    1.1. 기본 패키지 및 C 라이브러리 설치

    쿡쿠 샌드박스에서 사용하는 다양한 파이썬 라이브러리를 설치하려면 다음 패키지와 라이브러리들을 설치해야 한다. 설치하는데 있어 중요한 부분은 sudo 명령과 함께 비밀번호를 입력하는 과정이 불편하여 root 권한을 부여하고 설치를 진행하는 경우가 많다. 이렇게 구성한 경우, 소유권 문제로 인해 쿡쿠 샌드박스가 원활하게 동작하지 않을 수 있다. 물론, 공격자가 시스템에 침투하게 되었을 때 root 권한을 얻을 수 있다는 문제도 발생한다. 리눅스가 제공하는 사용자 권한에 따른 운영방식을 이해하는 것과 쿡쿠 엔진의 운영과 기타 서비스의 운영에 따른 권한 문제가 발생하는 것을 해결하기 위해서는 root 권한으로 구축하는 것을 추천하지 않는다.

    먼저 쿡쿠 샌드박스를 구축하는데 필요한 패키지와 다양한 기능을 사용하기 위해 설치하는 파이썬 라이브러리가 요구하는 C 라이브러리를 설치한다.

    sudo apt-get install -y python-pip python-dev libssl-dev libjpeg-dev zlib1g-dev tcpdump apparmor-utils

    설치하는 패키지를 살펴보면 다음과 같다.

    • python-pip: 파이썬 라이브러리를 쉽게 설치하도록 도와주는 도구다.
    • python-dev: 파이썬 헤더(python.h)를 제공하여 고성능을 위한 파이썬 확장을 위해 설치, 다양한 파이썬 라이브러리들이 퍼포먼스적인 측면을 위해 처리 기능을 C 언어로 구성된다.
    • libssl-dev: cryptography 파이썬 라이브러리를 설치하기 위해 설치하는 패키지로, 다양한 암호 기능을 제공한다.
    • libjpeg-dev: pillow 파이썬 라이브러리를 설치하기 위해 설치하는 패키지로, jpeg 이미지 파일을 위해 사용되는 C 라이브러리다.
    • zlib1g-dev: pillow파이썬 라이브러리를 설치하기 위해 설치하는 패키지로, gzip과 PKZIP를 지원하기 위해 제작되었지만, PNG 이미지 파일을 위해 사용되는 C 라이브러리다.
    • tcpdump: 패킷을 캡처를 위한 프로그램이다.
    • apparmor-utils: 앱 아머(AppArmor)는 Application Armor의 약자로 프로그램의 네트워크 접근, 파일 읽기, 쓰기 그리고 실행 같은 능력을 제어하여 접근 통제할 수 있는 리눅스 커널 보안 모듈로 이를 제어하기 위한 유틸리티다.

    다음 쿡쿠 코어가 네트워크 패킷을 수집할 수 있게 다음과 같이 구성한다. aa-disable 명령으로 tcpdump를 보호하는 앱 아머를 비활성화하고, setcap 명령으로 일반 사용자가 root 권한 없이 tcpdump를 사용할 수 있게 설정한다.

    sudo aa-disable /usr/sbin/tcpdump
    sudo setcap cap_net_raw,cap_net_admin=eip /usr/sbin/tcpdump

    만약 setcap 명령을 사용할 수 없다면 libcap2-bin 패키지를 설치한다. 

    sudo apt-get install libcap2-bin

    이제 샌드박스로 사용할 가상머신인 버추얼박스(VirtualBox)를 설치한다. 버추얼박스는 현재 오라클(Oracle)에서 개발하고 관리하고 있으며, 무료로 사용할 수 있는 좋은 소프트웨어다. Cuckoo 2.0.0 공식 가이드에서 언급한 버추얼박스의 버전은 4.3, 5.0 그리고 5.1 버전이다. 다음과 같이 5.1 버전을 설치한다.

    echo deb http://download.virtualbox.org/virtualbox/debian xenial contrib | sudo tee -a /etc/apt/sources.list.d/virtualbox.list
    wget -q https://www.virtualbox.org/download/oracle_vbox_2016.asc -O- | sudo apt-key add -
    sudo apt-get update
    sudo apt-get install -y virtualbox-5.1

    1.2. 쿡쿠 코어 설치

    이제 쿡쿠 코어를 설치한다. 설치는 매우 편리하게 다음과 같으며, 최신 버전으로 설치한다.

    sudo pip install cuckoo

    만약 쿡쿠 코어 버전을 특정 버전으로 설치하고 싶다면 버전을 명시해서 사용한다. 버전을 기입하지 않으면 설치 가능한 버전 리스트를 볼 수 있다.

    sudo pip install cuckoo==
    The directory '/home/cuckoo/.cache/pip/http' or its parent directory is not owned by the current user and the cache has been disabled. Please check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.
    The directory '/home/cuckoo/.cache/pip' or its parent directory is not owned by the current user and caching wheels has been disabled. check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.
    Collecting cuckoo==
      Could not find a version that satisfies the requirement cuckoo== (from versions: 2.0.0a1, 2.0.0, 2.0.1a1, 2.0.1a2, 2.0.1a3, 2.0.1, 2.0.2a1, 2.0.2a2, 2.0.2a3, 2.0.2a4, 2.0.2, 2.0.3a2, 2.0.3a3)
    No matching distribution found for cuckoo==

    쿡쿠 샌드박스가 2.0.x 버전으로 배포되기 전 가장 큰 문제는 버전관리가 매우 어려웠다. 새로운 버전이 개발되면 기존의 버전을 폐기하고 새롭게 설치하는 문제가 있었다. 하지만 이제는 pip 명령으로 설치하기에 기존의 버전과 업그레이드 버전을 통합하기 쉬워졌다. 최신 버전의 쿡쿠로 설치하려면 -U 옵션을 추가해 사용한다.

    쿡쿠 버전은 정식 릴리즈인 2.0.x 버전이 있고, 개발자 릴리즈인 2.0.xax 버전이 있다. 예를 들어, 2.0.1 버전은 정식 릴리즈고, 2.0.2a3은 개발자 릴리즈다. -U 옵션을 사용하여 업그레이드하면 정식 릴리즈만 반영된다. 2.0.2a3 버전이 존재하더라도 2.0.1 버전으로 설치된다. 개발자 릴리즈로 구성하고 싶다면 명확한 버전을 명시하는 형태로 설치 가능하다.

    sudo pip install -U cuckoo

    설치 완료 후 터미널에서 cuckoo 명령을 입력하면, 다음과 같은 메시지를 볼 수 있다. cuckoo 명령을 입력해야 ~/.cuckoo 디렉터리가 생성된다. 이 디렉터리에서 쿡쿠 샌드박스 운영을 위한 다양한 설정을 할 수 있다.

    리눅스에서 홈 디렉터리는 /home/ 에 사용자 계정으로 생성된다. 우분투 데스크톱을 구축할 때 설정한 사용자 계정이 cuckoo이기에 /home/cuckoo/로 표현된다. 현재 로그인한 사용자도 cuckoo 이이기에 /home/cuckoo/디렉터리에서 대부분 활동한다. 홈 디렉터리를 표현하는 기호로 물결표(~, Tilde)를 사용한다. 따라서 각자의 홈 디렉터리로 표현하기 위해 ~/ 로 표현했다.

    쿡쿠 샌드박스의 설정을 할 수 있는 디렉터리의 위치는 설치한 사용자의 기준으로 ~/.cuckoo로 생성된다. 만약 adduser 명령으로 cuckoo2 사용자를 생성한 후 cuckoo 명령을 입력하면 /home/cuckoo2/.cuckoo 디렉터리가 생성되며 cuckoo2 사용자만을 위한 쿡쿠 설정과 코어를 운영할 수 있다. 이처럼 .cuckoo 디렉터리가 사용자마다 다르게 생성하고 구축할 수 있기에 이를 Cuckoo Working Directory로 부르며 줄여서 CWD라고 한다. 

    만약 CWD를 다른 경로로 지정하고 싶다면 다음과 같이 --cwd 다음에 원하는 경로를 입력한다.

    cuckoo --cwd ~/test
    cuckoo
    
       ______   __  __   ______   ___   ___   ______   ______
      /_____/\ /_/\/_/\ /_____/\ /___/\/__/\ /_____/\ /_____/\
      \:::__\/ \:\ \:\ \\:::__\/ \::.\ \\ \ \\:::_ \ \\:::_ \ \
       \:\ \  __\:\ \:\ \\:\ \  __\:: \/_) \ \\:\ \ \ \\:\ \ \ \
        \:\ \/_/\\:\ \:\ \\:\ \/_/\\:. __  ( ( \:\ \ \ \\:\ \ \ \
         \:\_\ \ \\:\_\:\ \\:\_\ \ \\: \ )  \ \ \:\_\ \ \\:\_\ \ \
          \_____\/ \_____\/ \_____\/ \__\/\__\/  \_____\/ \_____\/
    
     Cuckoo Sandbox 2.0.1
     www.cuckoosandbox.org
     Copyright (c) 2010-2017
    
    =======================================================================
        Welcome to Cuckoo Sandbox, this appears to be your first run!
        We will now set you up with our default configuration.
        You will be able to see and modify the Cuckoo configuration,
        Yara rules, Cuckoo Signatures, and much more to your likings
        by exploring the /home/cuckoo/.cuckoo directory.
    
        Among other configurable items of most interest is the
        new location for your Cuckoo configuration:
                  /home/cuckoo/.cuckoo/conf
    =======================================================================
    
    Cuckoo has finished setting up the default configuration.
    Please modify the default settings where required and
    start Cuckoo again (by running `cuckoo` or `cuckoo -d`).

    1.3. 샌드박스 구성

    샌드박스(Sandbox)는 악성코드를 안전하게 분석할 수 있는 환경을 제공한다. 이러한 샌드박스를 쿡쿠 코어가 직접 통제하여 자동화된 형태로 운영할 수 있다. 샌드박스로 사용될 수 있는 운영체제는 윈도우, 리눅스, OS X가 있으며 추가로 안드로이드도 가능하다. 가장 기본적인 동작을 확인하기 위해 윈도우 운영체제 이미지를 구성한다. 샌드박스 구성은 다음과 같이 진행한다.

    1.3.1. 가상머신 다운로드 및 가져오기

    윈도우 운영체제는 유료이기에 구매해야 하지만, 간단한 테스트를 위해서 마이크로소프트에서 공식적으로 90일 제한이 되어 있는 가상머신 이미지를 제공한다. 이 이미지를 다운로드 받는 사이트는 다음과 같다.

    https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/

    쿡쿠 샌드박스의 분석 기능은 완전히 인터넷 익스플로러 11 버전과 엣지(Edge) 브라우저의 분석을 제공하지 않기에 낮은 버전의 브라우저를 선택한다. 그리고 윈도우 7 32비트 운영체제를 선택한다. 구성하려는 가상머신은 1.1. 기본 패키지 및 C 라이브러리 설치에서 선택한 VirtualBox로 선택한다.

    우분투 데스크톱 버전에서 인터넷을 통해 다운로드 받을 때 저장되는 기본 위치는 ~/Download 디렉터리다. 다운로드한 파일은 zip으로 압축되어 있어 압축을 해제한다. 압축을 성공적으로 해제하면 IE8 - Win7.ova파일이 생성된다.

    unzip ~/Download/IE8.Win7.For.Windows.VirtualBox.zip

    이제 터미널에서 버추얼박스를 실행한다.

    virtualbox

    다음과 같이 창이 뜨는데, 최상단 바에서 File을 선택하고 Import Appliance... 를 클릭한다.

    그리고 우측 폴더 아이콘을 클릭하여 방금 압축을 해제한 .ova 파일을 선택한다. 이제 Next > 버튼을 클릭한다.

    이제 구체적인 시스템 구성 상태를 볼 수 있는데, 하단의 맥(MAC) 주소 초기화 버튼인 Reinitialize the MAC address of all network cards을 선택하고 Import를 클릭한다.

    이제 윈도우 7 가상머신을 실행하여 부팅한다. 이 가상머신은 이미 가상머신 확장 도구가 설치되어 있기에 편리하게 이용할 수 있다. 부팅이 완료되면 시작 > Command Prompt 아이콘에서 우클릭한 후 Run as administrator를 선택하여 관리자모드로 윈도우 프롬프트에 접근한다. 이제 다음 명령을 입력하면 90일 테스트 제품으로 활성화된다.

    slmgr /ato

    1.3.2. 파이썬 2.7 다운로드 및 설치

    악성코드를 분석하기 위해 쿡쿠 코어를 받으려면 샌드박스에 파이썬 2.7 버전을 설치해야 한다. 파이썬 2.7 버전을 다운로드하기 위해 윈도우의 인터넷 익스플로러 브라우저로 다음 사이트에 방문한다.

    https://www.python.org/

    상단의 다운로드를 클릭하면 다음과 같은 화면을 볼 수 있는데 Download Python 2.7.13을 클릭한다. 만약 파이썬 버전이 업데이트되었다면 마지막 숫자 13이 다른 숫자로 표기되어 있을 것이기에 당황하지 말자.

    다운로드 페이지로 이동하는데, 하단으로 스크롤하여 Windows x86 MSI installer를 선택한다.

    이러한 과정이 번거롭다면 다음 주소를 브라우저에 다음 주소를 입력하여 바로 다운로드를 진행할 수 있다.

    https://www.python.org/ftp/python/2.7.13/python-2.7.13.msi

    다운로드가 끝나면 파이썬을 설치한다.

    1.3.3. pillow 라이브러리 설치

    파이썬 2.7 설치가 끝났다면 pillow 라이브러리를 설치한다. 이 라이브러리를 샌드박스에 설치하는 이유는 악성코드 분석을 진행할 때 윈도우 운영체제의 화면의 스크린샷을 찍어 상태를 파악하기 위함이다. 예를 들어 랜섬웨어 악성코드를 분석한다면, 사용자에게 협박하는 메시지를 볼 수 있을 것이다. 설치 방법은 단순하다. 먼저 윈도우 프롬프트를 열고 c:\python27\scripts 디렉터리의 pip 명령으로 pillow 라이브러리를 설치한다.

    c:\Python27\Scripts\pip.exe install pillow

    1.3.4. 네트워크 구성 및 아이피 고정

    쿡쿠 코어가 샌드박스를 제어하는 것은 샌드박스에 설치된 에이전트를 통해 진행한다. 이 에이전트에 명령을 입력려면 쿡쿠 코어는 샌드박스의 아이피를 알아야한다. 하지만 아이피가 유동적으로 변경된다면 쿡쿠 코어는 샌드박스를 제어할 수 없게 된다. 따라서 샌드박스의 아이피를 직접 명시하여 고정한다. 또한 쿡쿠 엔진과 동일한 아이피 대역으로 설정하기 위해 브릿지 모드로 설정한다. 먼저 버추얼박스 상단의 Device에서 Network를 선택하고 Network Settings를 클릭한다.

    다음 Attached to: 에서 Bridged Adapter를 선택하고 Name을 우분투 네트워크 인터페이스인 ens33을 선택한다.

    이제 윈도우 운영체제에서 시작 > Control Panel > Network and Internet > Network and Sharing Center를 선택하고, 좌측의 Change adapter settings를 클릭한다. 윈도우 네트워크 인터페이스인 Local Area Connection 2가 나타나는데, 이 아이콘에서 마우스 우클릭을 한 후 Properties를 선택한다. 설정 창에서 Internet Protocol Version 4 (TCP/IPv4)를 선택하고 Properties를 클릭한다. 이제 다음 그림처럼 아이피와 DNS를 설정한다.

    아이피 설정은 사용자마다 다르며, 브릿지 모드로 설정하기에 가상머신의 아이피 대역인 192.168.0.0/24를 고려하여 설정한다. 필자는 샌드박스를 192.168.0.10로 설정했다. DNS의 경우 구글의 DNS인 8.8.8.8과 8.8.4.4를 사용하는데, 때론 국가적으로 이슈가 된 공격은 국내 DNS에서 싱크홀(ShinkHole)을 운영하여 공격자와 통신을 차단하기에 구글의 DNS를 사용한다.

    윈도우 커맨드로 들어가서 아이피가 잘 설정되어 있는지 ipconfig 명령으로 확인하고, 외부와 통신이 되는지 핑(ping) 테스트를 한다. 핑 테스트할 때 도메인을 이용해야 DNS까지 잘 동작하는지 확인할 수 있다.

    1.3.5. 방화벽/업데이트 비활성화

    쿡쿠 샌드박스는 허니팟에 기초한다. 악성코드가 잘 동작해야 효과적인 분석을 진행할 수 있기에 고의적으로 취약한 환경을 구성한다. 따라서 방화벽과 윈도우 업데이트를 비활성화한다. 시작 > Control Panel > System and Security를 선택한다. 여기서 Windows Firewall을 클릭하고 외측 항목에서 Turn Windows Firewall on or off를 클릭한다. 그리고 다음과 같이 두개의 Turn off Windows Firewall 항목을 선택한다.

    다시 시작 > Control Panel > System and Security를 선택한다. 그리고 Windows Update를 클릭한다. 좌측 항목에서 Change settings를 클릭한다. 다음 그림과 같이 Important updates에서 Never check for updates (not recommended) 를 선택하여 윈도우 업데이트를 비활성화 한다.

    1.3.6. Administrator 계정 활성화 및 로그인

    관리자 계정을 활성화하고 로그인하는 이유는 앞서 설명한대로 악성코드가 동작하는데 방해가 없어야 하기 때문이다. 마치 리눅스의 root 계정으로 시스템을 운영하는 것과 같은 의미로 해석할 수 있다. 시작 버튼에서 Command Prompt 아이콘을 찾아 마우스 우클릭하고, Run as administrator를 선택하여 관리자 권한으로 윈도우 프롬프트를 실행한다. 그리고 다음 명령을 입력하여 관리자 계정을 활성화한다.

    Net user administrator /active:yes

    로그 아웃하면 관리자 계정이 활성화 되어 있는 것을 볼 수 있다. 관리자 계정에 비밀번호가 설정되어 있지 않고, 설정할 필요도 없기에 바로 관리자로 로그인한다. 로그인하면 시스인터널즈(Sysinternals) 도구 중 하나인 BGInfo의 실행 허가 알림창이 뜬다. 이 도구는 위 이미지의 바탕화면처럼 시스템의 정보를 출력하는 도구이기에 실행을 허가하든 하지 않든 중요하지 않다.

    1.3.7. UAC 비활성화

    UAC는 User Account Control의 약자로 말 그대로 사용자 계정을 제어하는데 사용된다. 윈도우 비스타 운영체제에서 처음 도입된 보안 기술로 리눅스의 사용자 권한 체계와 유사하게 이해하면 된다. 보안 관점에서 이해를 해보면, 공격자가 악성코드를 실행시킬 때 일반 사용자 A에서 동작시키면, 일반 사용자 B가 로그인했을 때 이 악성코드는 동작하지 않는다. 그렇다면 모든 사용자가 악성코드를 실행시키려면 관리자 권한으로 시스템에 동작시키는 것이 필요하다. 이 관점에서 UAC 우회라는 기술을 공격자가 자주 사용한다.

    하지만 공격자가 악성코드를 감염시키기 전에 수행해야하는 공격이며, 악성코드를 분석하는 입장에서는 크게 필요가 없다. 문제는 자동화된 형태로 분석을 한다는 것은 사용자가 실행했다는 것을 증명할 수 없다. 더욱이 쿡쿠 코어는 일반 사용자로 접근해서 실행하는 것이 아닌 네트워크를 통해 받은 파일을 프로그램이 실행하기에 로그인한 계정 주체와 실행 주체가 달라 문제가 발생할 수 있다. 이러한 이유로 UAC를 비활성화 하는 작업이 필요하다. 시작에서 uac를 검색한다.

    그리고 다음과 같이 왼쪽 UAC 제어 바를 최하단으로 위치시켜 비활성화한다.

    1.3.8. agent.py 실행과 가상머신 스냅샷 구성

    쿡쿠 코어를 설치하면서 받아온 파일 중 샌드박스화 시키는 agent.py를 윈도우 7에 구성한다. 윈도우 7 가상머신 상단의 Devices를 선택하고, Shared Folders의 Shared Folders Settings... 를 클릭한다.

    다음 오른쪽의 폴더에 + 기호가 붙은 아이콘을 클릭하고 Folder Path: 를 선택한 다음 Other... 를 클릭한다. 그리고 다음과 같이 Directory: 에 ./cuckoo/agent를 입력한다. Choose 버튼이 비활성화 되더라도 엔터치면 연결이 이루어진다.

    다음으로 Auto-mount와 Make Permanent를 활성화하고 OK 버튼을 누른다. Auto-mount는 설정과 동시에 공유 폴더와 연결되도록 설정하는 옵션이고, Make Permanent는 다음 번 부팅 시 공유 폴더를 이용하도록 설정하는 옵션이다. 간혹 Auto-mount로 공유 폴더와 연결이 잘 안되는 경우가 발생하는데 이 때 재부팅하면 Make Permanent에 의해 공유 폴더와 연결되어 있는 것을 볼 수 있다.

    공유 폴더 설정이 끝났다면 시작버튼에서 마우스 우클릭을 한 후 Open Windows Explorer를 선택한다.

    좌측 Network 항목에 VBOXSVR 공유 폴더가 활성화 된 것을 볼 수 있다. 이 폴더에는 방금 설정한 디렉터리와 연결되어 있으며, 여기서 agent.py를 가져올 수 있다.

    agent.py를 바탕화면에 복사하고 실행한다.

    이제 스냅샷을 찍고 저장하는 과정을 진행한다. 이 과정은 우분투 터미널에서 명령으로 제어 가능하며 쿡쿠 코어가 가상머신을 제어하는 방식으로 봐도 무방하다. 우분투 터미널에서 다음과 같이 명령을 입력하여 현재상태를 저장하고 스냅샷을 구성한다. 가상머신의 이름은 IE8 - Win7이고, 스냅샷 이름은 Snapshot1로 설정했다. 스냅샷 이름은 사용자가 원하는 이름으로 설정해도 된다. 쿡쿠 코어가 제어할 땐 최근에 찍은 스냅샷을 기준으로 제어하기 때문이다.

    VBoxManage snapshot "IE8 - Win7" take "Snapshot1" --pause
    0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
    Snapshot taken. UUID: e2bc4426-6862-49fe-8ec2-4eb7dda4150c

    제대로 스냅샷 설정이 되었는지 확인하기 위해 가상머신을 종료하고, 리스토어를 진행한다.

    VBoxManage controlvm "IE8 - Win7" poweroff
    0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
    VBoxManage snapshot "IE8 - Win7" restorecurrent
    Restoring snapshot e2bc4426-6862-49fe-8ec2-4eb7dda4150c
    0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%

    그러면 버추얼박스에 표현되는 상태는 다음과 같으며 하나의 샌드박스 구성이 끝났다. 이제 버추얼박스를 종료하고 쿡쿠 설정을 진행한다.

    1.4. 웹 인터페이스 데이터베이스 구성

    쿡쿠 웹 인터페이스인 장고(Django)는 쿡쿠 코어 설치에서 설치했고, 이 웹 인터페이스가 사용하는 데이터베이스인 몽고DB(MongoDB)를 구축한다. 이 구성은 사용자가 편리하게 브라우저를 이용하여 분석을 요청하거나 분석된 결과를 볼 수 있게 도와준다. 추후에 스케줄링을 위한 데이터베이스와 검색을 위한 데이터베이스 구성 데이터베이스 서버에 구성할 예정이기에 쿡쿠 데이터베이스는 별도의 운영체제를 설치하여 네트워크로 연결한다.

    문서 지향 데이터베이스의 장점은 관계형 데이터베이스에서 사용하는 테이블과 같은 경직된 구조로 데이터를 저장하지 않다는 점이다. 좀 더 풀어서 설명하자면 테이블의 열을 추가하려면 테이블 자체의 정의를 변경해야 하지만, 문서 지향 데이터베이스는 스키마를 사용하지 않도록 설계되어 있기에 별도의 변경없이 속성만 추가하면 된다. 즉, 데이터를 관리하는데 있어 매우 효율적이며 빠르다.

    쿡쿠 데이터베이스 서버(192.168.0.251)에 몽고DB데이터베이스를 설치한다.

    sudo apt-get install mongodb
    그리고 외부에서 접근할 수 있게 몽고DB의 설정 파일에서 라인 11의 bind-ip 를 쿡쿠 데이터베이스 서버의 아이피로 수정한다.
    sudo vim /etc/mongodb.conf
    bind_ip = 192.168.0.251
    서비스를 재시작하여 설정을 적용한다.
    sudo systemctl restart mongodb
    기본 형태로 사용하는 것은 몽고DB 데이터베이스에 사용자 인증 없이 바로 사용하게 된다. 따라서 몽고DB 데이터베이스에 사용자 계정과 비밀번호를 구성하고 연결하도록 설정한다. 먼저 몽고DB 쉘에 접속한다.
    mongo 192.168.0.251
    MongoDB shell version: 2.6.10
    connecting to: 192.168.0.251/test
    Welcome to the MongoDB shell.
    For interactive help, type "help".
    For more comprehensive documentation, see
            http://docs.mongodb.org/
    Questions? Try the support group
            http://groups.google.com/group/mongodb-user
    다음 명령으로 계정과 비밀번호 그리고 권한을 설정한다.
    > use cuckoo
    switched to db cuckoo
    > db.createUser({user:"cuckoo",pwd:"Hakawati123!@#",roles:[{role:"readWrite",db:"cuckoo"}]})
    Successfully added user: {
            "user" : "cuckoo",
            "roles" : [
                    {
                            "role" : "readWrite",
                            "db" : "cuckoo"
                     }
            ]
    }

    1.5. 쿡쿠 설정

    쿡쿠 코어와 샌드박스 그리고 웹 인터페이스와 데이터베이스 구성이 모두 끝났다. 그렇다면 엔진의 운영 방식과 엔진이 샌드박스를 인식할 수 있도록 설정파일을 수정한다. 쿡쿠 설정파일의 대부분은 $CWD/conf 디렉터리에 위치한다.

    이 책을 집필하는 기준인 2.0.2버전에서는 총 15가지 설정파일이 존재한다. 모든 설정파일을 수정하지 않으며, 이 챕터에서는 기본으로 동작하기 위한 필수 설정만 수정한다. 이후 기능을 확장하는 과정마다 필요한 부분을 언급할 예정이다.

    • auxiliary.conf: 아래 다양한 설정 파일로 분류하기 애매한 부수적인 기능을 선택하고 설정하는 파일이다.
    • avd.conf: 안드로이드 분석으로 확장하는 과정에 가상머신의 요소로 선택하고 설정하는 파일이다.
    • cuckoo.conf: 쿡쿠 코어가 동작하는데 핵심적인 설정 파일이다.
    • esx.conf: 가상머신의 한 종류로 Tpye 1 하이퍼바이저 방식을 사용하고 있는 VMware의 ESX로 샌드박스를 구성할 때 선택하고 설정하는 파일이다.
    • kvm.conf: 가상머신의 한 종류로 Type 1 하이퍼바이저 방식을 사용하는 리눅스용 가상머신인 KVM으로 샌드박스를 구성할 때 선택하고 설정하는 파일이다.
    • memory.conf: Volatility 도구를 이용하여 메모리 포렌식을 진행할 때 필요한 기능을 선택하고 설정하는 파일이다.
    • physical.conf: Fog 프로젝트를 이용하여 샌드박스를 가상먼신이 아닌 리얼머신으로 구성할 때 선택하고 설정하는 파일이다.
    • processing.conf: 다양한 분석 기능을 선택하고 설정하는 파일이다.
    • qemu.conf: 가상머신의 한 종류로 Type 2 하이퍼바이저 방식을 사용하는 QEMU 로 샌드박스를 구성할 때 선택하고 설정하는 파일이다.
    • reporting.conf: 분석 결과를 반영하는 방식을 선택하고 설정하는 파일이다.
    • routing.conf: 다양한 네트워크 구성을 위해 사용하는 설정 파일이다.
    • virtualbox.conf: 가상머신의 한 종류로 Type 2 하이퍼바이저 방식을 사용하는 VIrtualBox로 샌드박스를 구성할 때 선택하고 설정하는 파일이다.
    • vmware.conf: 가상머신의 한 종류로 Type 2 하이퍼바이저 방식을 사용하는 VMware 로 샌드박스를 구성할 때 선택하고 설정하는 파일이다.
    • vsphere.conf: 가상머신의 한 종류로 VMware에서 제공하는 클라우드 컴퓨팅 가상화 플랫폼인 vSphere를 샌드박스로 선택하고 사용할 때 설정하는 파일이다.
    • xenserver.conf: 가상머신의 한 종류로 Type 1 하이퍼바이저 방식을 사용하는 리눅스용 가상머신인 xenserver으로 샌드박스를 구성할 때 선택하고 설정하는 파일이다.

    설정 파일의 기본 구성은 섹션과 옵션으로 구성되어 있다. 섹션은 각괄호([모듈 섹션])로 표현되며 옵션은 변수명처럼 구성된다. 기능을 단순히 켜고 끄는 것은 [yes/no]로 구성되어 있고, 그 외엔 구성에 필요한 값을 입력하도록 구성되어 있다.

    기본 설정에서 중요한 설정 파일은 cuckoo.conf, reporting.conf이며, 버추얼박스로 샌드박스를 구성했기에 virtualbox.conf도 중요한 설정 파일이다. 먼저 cuckoo.conf 설정을 살펴본다. 이 설정 파일에서 수정이 필요한 부분은 [resultserver] 섹션의 ip 옵션으로 샌드박스가 악성코드를 분석한 결과를 전달받는 쿡쿠 코어의 아이피로 수정하고 저장한다. 기본 포트는 2042인데, 필요에 따라 수정한다.

    vim ~/.cuckoo/conf/cuckoo.conf
    [resultserver]
    # The Result Server is used to receive in real time the behavioral logs
    # produced by the analyzer.
    # Specify the IP address of the host. The analysis machines should be able
    # to contact the host through such address, so make sure it's valid.
    # NOTE: if you set resultserver IP to 0.0.0.0 you have to set the option
    # `resultserver_ip` for all your virtual machines in machinery configuration.
    ip = 192.168.0.200
    
    # Specify a port number to bind the result server on.
    port = 2042

    reporting.conf에서 수정하는 부분은 1.4. 웹 인터페이스 데이터베이스 구성이 성공적으로 진행되어야 설정한 후 동작하는데 문제가 발생하지 않는다. [mongodb] 섹션에서 기능을 활성화하는 enabled 옵션 값을 yes로 변경하고, 쿡쿠 데이터베이스 서버 주소를 host 옵션에 입력한다. 그리고 몽고DB에 생성한 cuckoo 데이터베이스의 사용자 계정과 비밀번호를 username과 password 옵션에 입력한다.

    vim ~/.cuckoo/conf/reporting.conf
    [mongodb]
    enabled = yes
    host = 192.168.0.251
    port = 27017
    db = cuckoo
    store_memdump = yes
    paginate = 100
    # MongoDB authentication (optional).
    username = cuckoo
    password = Hakawati123!@#

    마지막으로 virtualbox.conf를 설정한다. 첫번째로 [virtualbox] 섹션의 mode 옵션을 gui로 변경한다. 이는 샌드박스가 화면에 보이도록 운영하여 제대로 동작하는지 확인하기 위한 목적이다. 기존의 headless를 사용하면 가상머신의 동작 과정이 화면에 보여지지 않고 분석하게 된다.

    두번째로 interface 옵션으로 샌드박스가 사용하는 네트워크 인터페이스 이름을 입력한다. 브릿지 모드로 설정했기에 우분투에서 ifconfig 명령으로 확인할 수 있는 네트워크 인터페이스 이름인 ens33으로 설정한다. 참고로 이 값은 사용자마다 상이할 수 있다.

    세번째로 machines옵션은 샌드박스의 구성을 설정하는 부분이다. 특히 machines에 설정한 cuckoo1은 그 아래에 있는 [cuckoo1] 섹션의 이름과 동일하게 구성되어야 쿡쿠 코어가 샌드박스의 정보를 읽을 수 있다. 이러한 방식으로 샌드박스를 여러개 구축할 수 있다.

    vim ~/.cuckoo/conf/virtualbox.conf
    [virtualbox]
    # Specify which VirtualBox mode you want to run your machines on.
    # Can be "gui" or "headless". Please refer to VirtualBox's official
    # documentation to understand the differences.
    mode = gui
    
    # Path to the local installation of the VBoxManage utility.
    path = /usr/bin/VBoxManage
    # If you are running Cuckoo on Mac OS X you have to change the path as follows:
    # path = /Applications/VirtualBox.app/Contents/MacOS/VBoxManage
    
    # Default network interface.
    interface = ens33
    
    # Specify a comma-separated list of available machines to be used. For each
    # specified ID you have to define a dedicated section containing the details
    # on the respective machine. (E.g. cuckoo1,cuckoo2,cuckoo3)
    machines = cuckoo1

    [virtualbox] 섹션의 machines 옵션에 설정된 cuckoo1의 구성사항이다. label 옵션은 샌드박스의 이름이기에 IE8 - Win7으로 설정한다. 이 샌드박스에 설정한 아이피를 ip 옵션에 설정한다.

    [cuckoo1]
    # Specify the label name of the current machine as specified in your
    # VirtualBox configuration.
    label = IE8 - Win7
    
    # Specify the operating system platform used by current machine
    # [windows/darwin/linux].
    platform = windows
    
    # Specify the IP address of the current virtual machine. Make sure that the
    # IP address is valid and that the host machine is able to reach it. If not,
    # the analysis will fail.
    ip = 192.168.0.10

    2. 쿡쿠 샌드박스 기본 운영

    쿡쿠 샌드박스 구축이 성공적이라면 쿡쿠 코어의 동작에 아무런 문제가 없을 것이다. 이제 쿡쿠 샌드박스를 운영하는 절차를 이해하고 동작시켜본다. 이 과정의 목차는 다음과 같다.

    2.1. 쿡쿠 코어 실행

    쿡쿠 코어를 다음과 같이 실행한다. 쿡쿠 샌드박스가 동작하는 과정에서 발생하는 문제를 출력할 수 있게 디버그 옵션인 -d를 함께 사용한다. cuckoo 명령은 환경변수로 등록되어 있어 어떤 위치에서 명령해도 잘 동작할 것이다. 코어가 잘 동작하면 다음과 같은 화면을 볼 수 있다.

    cuckoo -d
    
                _       _                   _             _              _            _
              /\ \     /\_\               /\ \           /\_\           /\ \         /\ \
             /  \ \   / / /         _    /  \ \         / / /  _       /  \ \       /  \ \
            / /\ \ \  \ \ \__      /\_\ / /\ \ \       / / /  /\_\    / /\ \ \     / /\ \ \
           / / /\ \ \  \ \___\    / / // / /\ \ \     / / /__/ / /   / / /\ \ \   / / /\ \ \
          / / /  \ \_\  \__  /   / / // / /  \ \_\   / /\_____/ /   / / /  \ \_\ / / /  \ \_\
         / / /    \/_/  / / /   / / // / /    \/_/  / /\_______/   / / /   / / // / /   / / /
        / / /          / / /   / / // / /          / / /\ \ \     / / /   / / // / /   / / /
       / / /________  / / /___/ / // / /________  / / /  \ \ \   / / /___/ / // / /___/ / /
      / / /_________\/ / /____\/ // / /_________\/ / /    \ \ \ / / /____\/ // / /____\/ /
      \/____________/\/_________/ \/____________/\/_/      \_\_\\/_________/ \/_________/
    
     Cuckoo Sandbox 2.0.2
     www.cuckoosandbox.org
     Copyright (c) 2010-2017
    
     Checking for updates...
     You're good to go!
    2017-04-17 15:46:25,624 [cuckoo.core.startup] DEBUG: Imported modules...
    2017-04-17 15:46:25,636 [cuckoo.core.startup] DEBUG: Imported "auxiliary" modules:
    2017-04-17 15:46:25,637 [cuckoo.core.startup] DEBUG: 	 |-- MITM
    2017-04-17 15:46:25,637 [cuckoo.core.startup] DEBUG: 	 |-- Reboot
    2017-04-17 15:46:25,637 [cuckoo.core.startup] DEBUG: 	 |-- Services
    2017-04-17 15:46:25,637 [cuckoo.core.startup] DEBUG: 	 `-- Sniffer
    2017-04-17 15:46:25,637 [cuckoo.core.startup] DEBUG: Imported "machinery" modules:
    2017-04-17 15:46:25,638 [cuckoo.core.startup] DEBUG: 	 |-- vSphere
    2017-04-17 15:46:25,638 [cuckoo.core.startup] DEBUG: 	 |-- KVM
    2017-04-17 15:46:25,638 [cuckoo.core.startup] DEBUG: 	 |-- ESX
    2017-04-17 15:46:25,638 [cuckoo.core.startup] DEBUG: 	 |-- XenServerMachinery
    2017-04-17 15:46:25,638 [cuckoo.core.startup] DEBUG: 	 |-- VirtualBox
    2017-04-17 15:46:25,638 [cuckoo.core.startup] DEBUG: 	 |-- Avd
    2017-04-17 15:46:25,639 [cuckoo.core.startup] DEBUG: 	 |-- QEMU
    2017-04-17 15:46:25,639 [cuckoo.core.startup] DEBUG: 	 |-- VMware
    2017-04-17 15:46:25,639 [cuckoo.core.startup] DEBUG: 	 `-- Physical
    2017-04-17 15:46:25,639 [cuckoo.core.startup] DEBUG: Imported "processing" modules:
    2017-04-17 15:46:25,639 [cuckoo.core.startup] DEBUG: 	 |-- AnalysisInfo
    2017-04-17 15:46:25,639 [cuckoo.core.startup] DEBUG: 	 |-- ApkInfo
    2017-04-17 15:46:25,640 [cuckoo.core.startup] DEBUG: 	 |-- Baseline
    2017-04-17 15:46:25,640 [cuckoo.core.startup] DEBUG: 	 |-- BehaviorAnalysis
    2017-04-17 15:46:25,640 [cuckoo.core.startup] DEBUG: 	 |-- Debug
    2017-04-17 15:46:25,640 [cuckoo.core.startup] DEBUG: 	 |-- Droidmon
    2017-04-17 15:46:25,640 [cuckoo.core.startup] DEBUG: 	 |-- Dropped
    2017-04-17 15:46:25,640 [cuckoo.core.startup] DEBUG: 	 |-- DroppedBuffer
    2017-04-17 15:46:25,641 [cuckoo.core.startup] DEBUG: 	 |-- GooglePlay
    2017-04-17 15:46:25,641 [cuckoo.core.startup] DEBUG: 	 |-- Irma
    2017-04-17 15:46:25,641 [cuckoo.core.startup] DEBUG: 	 |-- Memory
    2017-04-17 15:46:25,641 [cuckoo.core.startup] DEBUG: 	 |-- MetaInfo
    2017-04-17 15:46:25,641 [cuckoo.core.startup] DEBUG: 	 |-- MISP
    2017-04-17 15:46:25,641 [cuckoo.core.startup] DEBUG: 	 |-- NetworkAnalysis
    2017-04-17 15:46:25,641 [cuckoo.core.startup] DEBUG: 	 |-- ProcessMemory
    2017-04-17 15:46:25,642 [cuckoo.core.startup] DEBUG: 	 |-- Procmon
    2017-04-17 15:46:25,642 [cuckoo.core.startup] DEBUG: 	 |-- Screenshots
    2017-04-17 15:46:25,642 [cuckoo.core.startup] DEBUG: 	 |-- Snort
    2017-04-17 15:46:25,642 [cuckoo.core.startup] DEBUG: 	 |-- Static
    2017-04-17 15:46:25,642 [cuckoo.core.startup] DEBUG: 	 |-- Strings
    2017-04-17 15:46:25,642 [cuckoo.core.startup] DEBUG: 	 |-- Suricata
    2017-04-17 15:46:25,643 [cuckoo.core.startup] DEBUG: 	 |-- TargetInfo
    2017-04-17 15:46:25,643 [cuckoo.core.startup] DEBUG: 	 |-- TLSMasterSecrets
    2017-04-17 15:46:25,643 [cuckoo.core.startup] DEBUG: 	 `-- VirusTotal
    2017-04-17 15:46:25,643 [cuckoo.core.startup] DEBUG: Imported "signatures" modules:
    2017-04-17 15:46:25,643 [cuckoo.core.startup] DEBUG: 	 |-- CreatesExe
    2017-04-17 15:46:25,643 [cuckoo.core.startup] DEBUG: 	 `-- SystemMetrics
    2017-04-17 15:46:25,644 [cuckoo.core.startup] DEBUG: Imported "reporting" modules:
    2017-04-17 15:46:25,644 [cuckoo.core.startup] DEBUG: 	 |-- ElasticSearch
    2017-04-17 15:46:25,644 [cuckoo.core.startup] DEBUG: 	 |-- Feedback
    2017-04-17 15:46:25,644 [cuckoo.core.startup] DEBUG: 	 |-- JsonDump
    2017-04-17 15:46:25,644 [cuckoo.core.startup] DEBUG: 	 |-- Mattermost
    2017-04-17 15:46:25,644 [cuckoo.core.startup] DEBUG: 	 |-- MISP
    2017-04-17 15:46:25,645 [cuckoo.core.startup] DEBUG: 	 |-- Moloch
    2017-04-17 15:46:25,645 [cuckoo.core.startup] DEBUG: 	 |-- MongoDB
    2017-04-17 15:46:25,645 [cuckoo.core.startup] DEBUG: 	 |-- Notification
    2017-04-17 15:46:25,645 [cuckoo.core.startup] DEBUG: 	 `-- SingleFile
    2017-04-17 15:46:25,645 [cuckoo.core.startup] DEBUG: Checking for locked tasks..
    2017-04-17 15:46:25,663 [cuckoo.core.startup] DEBUG: Checking for pending service tasks..2017-04-17 15:46:25,645 [cuckoo.core.startup] DEBUG: Checking for locked tasks..
    2017-04-17 15:46:25,663 [cuckoo.core.startup] DEBUG: Checking for pending service tasks..
    2017-04-17 15:46:25,674 [cuckoo.core.startup] WARNING: Unable to import yara (please compile from sources)
    2017-04-17 15:46:25,675 [cuckoo.core.resultserver] DEBUG: ResultServer running on 192.168.0.200:2042.
    2017-04-17 15:46:25,676 [cuckoo.core.scheduler] INFO: Using "virtualbox" as machine manager
    2017-04-17 15:46:26,090 [cuckoo.machinery.virtualbox] DEBUG: Stopping vm IE8 - Win7
    2017-04-17 15:46:26,285 [cuckoo.machinery.virtualbox] DEBUG: Restoring virtual machine IE8 - Win7 to its current snapshot
    2017-04-17 15:46:26,404 [cuckoo.core.scheduler] INFO: Loaded 1 machine/s
    2017-04-17 15:46:26,422 [cuckoo.core.scheduler] INFO: Waiting for analysis tasks.

    샌드박스를 하나만 구성했기에 "Loaded 1 machine/s"가 출력된 것을 볼 수 있으며 어떠한 에러도 발생하지 않는다. 에러가 발생한다면 해당 에러를 잘 살펴보고 문제를 해결하는 것이 중요하다.

    2.2. 쿡쿠 웹 서버 실행

    이제 새로운 터미널을 열어 웹 서비스를 실행한다. 이 실행에 앞서 쿡쿠 코어 운영에 필요한 명령들을 살펴보자.

    cuckoo --help
    
    Usage: cuckoo [OPTIONS] COMMAND [ARGS]...
    
      Invokes the Cuckoo daemon or one of its subcommands.
    
      To be able to use different Cuckoo configurations on the same machine with
      the same Cuckoo installation, we use the so-called Cuckoo Working
      Directory (aka "CWD"). A default CWD is available, but may be overridden
      through the following options - listed in order of precedence.
    
      * Command-line option (--cwd)
      * Environment option ("CUCKOO_CWD")
      * Environment option ("CUCKOO")
      * Current directory (if the ".cwd" file exists)
      * Default value ("~/.cuckoo")
    
    Options:
      -d, --debug             Enable verbose logging
      -q, --quiet             Only log warnings and critical messages
      --nolog                 Don't log to file.
      -m, --maxcount INTEGER  Maximum number of analyses to process
      --user TEXT             Drop privileges to this user
      --cwd TEXT              Cuckoo Working Directory
      --help                  Show this message and exit.
    
    Commands:
      api          Operate the Cuckoo REST API.
      clean        Clean the CWD and associated databases.
      community    Fetch supplies from the Cuckoo Community.
      distributed  Distributed Cuckoo helper utilities.
      dnsserve     Custom DNS server.
      import       Imports an older Cuckoo setup into a new CWD.
      init         Initializes Cuckoo and its configuration.
      machine      Dynamically add/remove machines.
      migrate      Perform database migrations.
      process      Process raw task data into reports.
      rooter       Instantiates the Cuckoo Rooter.
      submit       Submit one or more files or URLs to Cuckoo.
      web          Operate the Cuckoo Web Interface.

    옵션으로는 디버그 옵션, 경고와 크리티컬 에러 메시지만 출력하는 옵션, 로그를 남기지 않는 옵션, 분석 개수를 조절하는 옵션, 사용자 권한을 제어하는 옵션 그리고 CWD를 지정하는 옵션으로 구성된다. 명령으로는 api, clean등 다양한데 이들은 각각의 기능을 사용할 때 언급할 예정이다.

    웹 서버를 실행하기 위한 명령으로는 web이 있다. 이 명령 뒤에 다시 --help 옵션을 사용하면 웹 서비스를 실행하기 위한 설정 방법을 볼 수 있다.

    cuckoo web --help
    
    Usage: cuckoo web [OPTIONS] [ARGS]...
    
      Operate the Cuckoo Web Interface.
    
      Use "--help" to get this help message and "help" to find Django's
      manage.py potential subcommands.
    
    Options:
      -H, --host TEXT     Host to bind the Web Interface server on
      -p, --port INTEGER  Port to bind the Web Interface server on
      --uwsgi             Dump uWSGI configuration
      --nginx             Dump nginx configuration
      --help              Show this message and exit.

    웹 서버는 -H 옵션 뒤에 호스트 아이피를, -p 옵션 뒤에 포트 번호를 입력하여 웹 서비스를 실행할 수 있다. 설명에 나와있듯이 --help 옵션이 아닌 help 옵션을 입력하면 장고 웹 인터페이스의 명령을 볼 수 있다. 어떤 옵션을 사용하든 기본으로 장고 웹 인터페이스를 사용한다.

    cuckoo web -H 192.168.0.200 -p 8000
    
    Performing system checks...
    
    System check identified no issues (0 silenced).
    April 17, 2017 - 15:55:06
    Django version 1.8.4, using settings 'cuckoo.web.web.settings'
    Starting development server at http://192.168.0.200:8000/
    Quit the server with CONTROL-C.
    [17/Apr/2017 15:55:30] "GET / HTTP/1.1" 200 21999

    브라우저로 웹 서버에 접근하면 쿡쿠 웹 서비스를 볼 수 있다.

    3. 마무리

    쿡쿠 샌드박스의 가장 기초적인 동작을 기술해보았다. 쿡쿠 샌드박스는 이것만 있지 않다. 패턴 제작부터 기타 대형 오픈소스 프로젝트와의 연동 등 여러가지 형태로 확장할 수 있다. 이 모든 것을 다루기엔 많은 시간이 필요할 듯 싶다. 기회가 된다면 차근차근 하나씩 정리하고 싶다.

    4. 참고 사이트


    'Information Security > OpenSource' 카테고리의 다른 글

    CVE-SEARCH v.REV  (0) 2017.05.12
    How to install Cuckoo Sandbox 2.0.x  (31) 2017.05.08
    CVE-SEARCH  (1) 2016.06.29
    How to install Viper 1.3-dev  (0) 2016.04.04
    Mobile Security Framework  (0) 2016.03.02
    Cuckoo Sandbox 2.0 RC1 Release  (0) 2016.01.22
    1. tgpapa 2017.07.24 23:14

      안녕하세요.
      얼마전 세미나에서 발표하시는것 보고 찾아들어왔습니다.
      쿡쿠 샌드박스 기본 환경 구축에 도움이 많이되었습니다. 감사합니다.
      혹시 DB서버 추가 구성(스케줄링용 RDB, 검색엔진(ElasticSearch)) 과 메모리 분석(Volatility) 관련내용은 포스팅 계획이 없으신가요?

    2. tgpapa 2017.07.30 12:20

      호스트와 샌드박스를 같은 네트워크 대역으로 하면
      샌드박스에서 구동되는 악성코드가 호스트로 전파되거나 그런 위험성은 없나요?

      • Favicon of https://www.hakawati.co.kr BlogIcon hakawati 2017.08.18 17:33 신고

        네 악성코드의 특성과 관련있는데, 보통 중첩 가상화로 구성하면 악성코드가 동작하는 운영체제와 호스트 운영체제가 다르기 때문에 영향이 더 적을것 같습니다. 또한 예전에 샌드박스에 요청한 악성코드로 쿡쿠 샌드박스를 우회해 호스트 운영체제 쉘을 획득하는(? 정확히 기억이 안나서) 취약성이 발견되었는데 곧바로 패치되었던 기억도 있습니다.

    3. 111 2018.04.17 16:18

      설치 체계적으로 잘 설명해두셔서 잘 하고있습니다..

      그런데 관리자 계정으로 로그인할때 비밀번호가 없다고 하셨는데 비밀번호를 입력하라고 하네요..

      어떻게 해결해야하는건지 혹시 아시나요?

      • Favicon of https://www.hakawati.co.kr BlogIcon hakawati 2018.06.25 09:48 신고

        아 최근에 MS에서 제공하는 개발자를 위한 가상머신의 구성이 바뀌었더라구요.

        //관리자 비밀번호 생성(아무거나인 * 후 패스워드 입력하지 않고 엔터)
        net user administrator *
        [엔터 두번]

        //자동으로 관리자로 접속되도록 일반 사용자 계정 모두 삭제
        net user IEUser /delete
        net user sshd /delete
        net user sshd_server /delete

    4. 2018.06.25 09:43

      비밀댓글입니다

      • Favicon of https://www.hakawati.co.kr BlogIcon hakawati 2018.06.25 09:49 신고

        가상머신의 네트워크 구성과 NAT 또는 브릿지에 따라 다르게 구성해해요. 네트워크 인터페이스인 ens33도 tech1님의 환경에 맞게 설정할 필요가 있습니다~

    5. tech1 2018.06.25 10:15

      답변 감사합니다.^^
      답변 내용은 "어댑터에 브릿지"(bridge adapter) 에서 ens33 이어도 제 네트워크 상황에 따라 다른거가 되도 된다는거 같은데요. 그럼. 혹시 포스팅한 부분중 ie8 - win7의 네트워크 주소를 고정아이피(192.168.0.10)로 수정하자나요.
      고정IP로 수정하면 ie8 - win7의 host인 우분투에서 따로 설정을 해줘야 하는거 아닌가요???
      고정ip하고 인터넷이 안되서요.. 설정이 필요한게 아닌가 생각했어요.

      • Favicon of https://www.hakawati.co.kr BlogIcon hakawati 2018.06.25 10:18 신고

        버추얼박스에서 어댑터 브릿지를 선택하시면 우분투의 아이피와 동일한 대역의 아이피로 고정하시면 됩니다. 우분투에 별다른 설정을 하지 않아도 통신이 잘돼요.

    6. tech1 2018.06.25 10:30

      아하 언뜻 이해가 간거 같은데요. 맞는지 잘 모르겠습니다.
      본문(포스팅된 글)에서 192 168 0 10으로 하신거는 host&guest 인 우분투의 ip 주소가 192 168 0 XX/24 이어서 같은 대역으로 설정하기 위해 192 168 0 XX(XX는 임의의 숫자이고, 10으로 설정하심)으로 했다고 보면 되나요?
      위의 말이 맞다면 제 컴퓨터에서 우분투의 ip 주소가 110 22 1 10이고 netmask가 255 255 255 0 일때 ie8-win7의 주소를 110 22 1 XX (XX는 제가 하고 싶은 거 암거나.. )로 하고 서브넷주소는 255 255 255 0 으로 하면 된다고 보면 될까요? (default gateway는 혹시 어떻게 정하시는지 아시는지요)

      • Favicon of https://www.hakawati.co.kr BlogIcon hakawati 2018.06.25 10:36 신고

        네 맞습니다. 다만, tech1님께서 말씀하신 아이피는 공인 아이피인 110.22.1.10를 사용하신거 같은데, 공인 아이피 할당 개수가 통신사의 상품에 따라 달라질 수 있어 할당하지 못할 수 있어요.
        이런 이유로 공인 아이피를 쓸 필요가 없어 저는 사설 아이피인 192.168.0.0 대역으로 사용하도록 VM웨어에서 설정을 했어요.
        사설 네트워크 설정 방법은 "VM웨어 > Edit > Virtual Network Editor > NAT > Subnet IP / Subnet mask 설정"으로 해결하실 수 있어요. 물론 우분투 운영체제 네트워크 인터페이스를 NAT로 설정하구요.

    7. tech1 2018.06.25 11:38

      답변 감사합니다. 네트워크 환경은 조사해보고 좀 생각해서 해야 겠네요..
      일단 다른 부분을 진행해 보았는데요. Administrator 계정 활성화를 했씁니다. Net user administrator /active:yes
      실행하고 The command completed successfully. 결과도 보았는데요. log off 하고 Administrator 에 로그인 하려고하는데 비번을 입력하고 합니다. 모든 과정을 본문하고 똑같이 했는데.. 왜그런지 혹시 짐작 가시는 바가 있으신가요??

      • Favicon of https://www.hakawati.co.kr BlogIcon hakawati 2018.06.25 11:42 신고

        //관리자 비밀번호 생성(아무거나인 * 후 패스워드 입력하지 않고 엔터)
        net user administrator *
        [엔터 두번]

        //자동으로 관리자로 접속되도록 일반 사용자 계정 모두 삭제
        net user IEUser /delete
        net user sshd /delete
        net user sshd_server /delete

    8. tech1 2018.06.25 13:34

      답변 정말 감사합니다..
      네트워크 설정에 있어서 제가 공인 IP를 사용하는데, VMware에서 사설 네트워크로 환경 설정하는 것을 알려주신거 같습니다. guest&host 우분투는 공인 IP를 사용하고, 이 우분투에 설치된 virtualbox의 위에 올라간 ie8-win7아 ip주소는 192 168 ~~ 와 같이 사설 ip 를 고정하여 사용하도록 설정하는 방법을 권해주신거 같은 맞는 건가요?? (저는 virtualbox 이긴합니다..)
      만약 그렇다면, 제가 다른 분이 쓴 글을 보니(http://ferretsecu.tistory.com/6 의 "8. 라우팅 설정";) guest&host에서 포트포워딩(ie8-win7은 호스트 전용 어댑터로 설정)을 해주는거 같은데 이부분을 사용해도 될까요??

      • Favicon of https://www.hakawati.co.kr BlogIcon hakawati 2018.06.25 14:03 신고

        네 라우팅 설정으로 진행하셔도 무방한데 그렇게 쓰시려면 host-only로 네트워크 쓰시면 됩니다. 우분투는 사설 안되시나요?

    9. 2018.06.25 14:19

      비밀댓글입니다

      • Favicon of https://www.hakawati.co.kr BlogIcon hakawati 2018.06.25 14:27 신고

        아 그렇게 구성하셨군요. 그렇게 구성하시면 네트워크가 안되요. 버추얼박스 안에 버추얼박스를 구성하면 안쪽의 버추얼박스의 네트워크 인터페이스가 안잡히더라구요. 가상화 안에 가상화를 중첩 가상화라하는데, 저도 이거 때문에 고생을 했었어요. 중첩 가상화 지원은 VM웨어가 가장 잘 지원해줘요. 버추얼박스는 안되구요.

    10. tech1 2018.06.25 14:47

      답변 감사합니다. hakawati님.
      hakawati님도 저와 비슷한 환경으로 하신거 같고, 차이점은 OS 버전과 vmware, 공유기 사용 환경인거 같은데 맞는지요?
      중첩가상화 환경에서 혹시 host only network으로 해도 virtualbox에서는 안되는건가요??

      • Favicon of https://www.hakawati.co.kr BlogIcon hakawati 2018.06.25 14:49 신고

        음 그부분은 안해봐서 모르겠어요. 제가 셋팅할 때 다양한 방법을 시도해봤는데, 버추얼박스 공식 이슈 보고에서 중첩가상화를 지원 안하기에 네트워크 인터페이스가 동작하지 않는다는 문구를 보고 더는 테스트 안했던 걸로 기억하고 있어요~

    11. tech1 2018.06.25 14:58

      아하 host only는 해봐야겠네요.
      그런데 지금 제 상황에서는 vmware로 바꾼다고 해도 ip 주소 설정에서 또 막힐거 같은데요. 아닐까요?
      아니면 vmware에서 ie8-win7을 네트워크 설정시 브릿지 어댑터로 하면 자동으로 인터넷까지 되게 고정IP 설정으로 되는건가요??

      • Favicon of https://www.hakawati.co.kr BlogIcon hakawati 2018.06.25 14:59 신고

        네 dhcp에 의해 자동으로 사설 아아피 할당받고 그 아이피 대역으로 고정 아이피 셋팅하면 잘 돌아갈꺼에요

    12. tech1 2018.06.25 17:02

      안녕하세여^^ hakawati님
      일단 routing 설정을 (http://ferretsecu.tistory.com/6 의 "8. 라우팅 설정";)을 보고 했씁니다.
      돌아가긴 하는거 같네요 ㅎㅎ..
      앞으로 어떤 문제가 나올지는 모르겠지만요.. 하다가 정 안되면 우분트를 host로 설치하고 하던지 vmware를 다운 받아야 겠네요.,
      댓글로 알려주셔서 정말 너무 감사드립니다.

      • Favicon of https://www.hakawati.co.kr BlogIcon hakawati 2018.06.25 17:02 신고

        어랏 잘되시나봐요! 제가 잘못알고 있었나 보네요. 저도 다시 한번 테스트 해봐야겠습니다~

    13. tech1 2018.06.25 17:12

      지뢰찾기.exe 넣고 돌아가서 리포트 보고서 나오는거 까지봐서요. 다른 부분이 잘 설치되었는지는 모르겠으나.. 현재는 며칠 삽질하다가 된거라 기쁩니다..
      포스팅 된글은 계속 보고 있습니다. ㅎㅎ

    14. Favicon of https://blog.naver.com/gusrn94o BlogIcon asu 2018.07.26 02:51

      ip 설정에서 막혔습니다. 우분투 ip 를 기준으로 맨뒤에 0~255 변경해서 하고 있는데 몇개 안했는데도, 시간이 많이 걸리네요... 만약에 0~255까지 다해봤는데도 안되면 그때는 어떻게 해결해야 될까요 ? ip 주소에 대한 지식이 별로 없어서 팁 하나 주시면 감사할게요 !!

      • Favicon of https://www.hakawati.co.kr BlogIcon hakawati 2018.07.27 13:23 신고

        일단 사설 아이피인지 공인 아이피인지 확인부터 할 필요가 있습니다~ ㅎ

    15. Jeong 2018.08.23 11:50

      윈도우 셋팅 중간에 agent.py 가 나오는데 이건 어디서 구할 수 있는건가요??
      파이썬 설치 다 되었고 find / agent.py 해봐도 아무것도 안나와요

    16. nick1 2018.09.11 14:23

      안녕하세요. 글 잘 봤습니다. 다만 제가 쿠쿠 샌드박스 동작 자체에 대한 이해가 좀 부족한 것 같아서요.
      가상 머신을 설치해야 하는 이유를 잘 모르겠습니다. 이 부분에 대해 설명해주실 수 있나요?

    17. cho6nt 2018.11.02 05:02

      안녕하세요 책 구독자입니다 라우팅 설정을 끝마쳤는데 윈도우에서 파이썬 홈페이지가 안들어가집니다, 구글이나 여타 msn이나 전부 들어가지는데 구글에서 검색하여 홈페이지를 들어가면 안들어가지네요 무슨 이유일까요?

    목차

    3. 기본 실행 환경(Basic Execution Environment)

    3.1. 작동 방식(Modes of Operation)

    3.1.1. Intel® 64 아키텍처(Intel® 64 Architecture)

    3.2. 기본 실행 환경의 개요(Overview of the Basic Execution Environment)

    3.2.1. 64비트 모드 실행 환경(64-Bit Mode Execution Environment)

    3.3. 메모리 조직(Memory Organization)

    3.3.1. IA-32 메모리 모델(IA-32 Memory Models)

    3.3.2. 페이징과 가상 메모리(Paging and Virtual Memory)

    3.3.3. 64비트 모드의 메모리 조직(Memory Organization in 64-Bit Mode)

    3.3.4. 동작 모드 vs 메모리 모델(Modes of Operation vs. Memory Model)

    3.3.5. 32비트 및 16비트 주소와 피연산자 크기(32-Bit and 16-Bit Address and Operand Sizes)

    3.3.6. 보호 모드에서 확장된 물리적 주소 배정(Extended Physical Addressing in Protected Mode)

    3.3.7. 64 비트 모드에서 주소 계산(Address Calculations in 64-Bit Mode)

    3.3.7.1. 표준 주소 배정(Canonical Addressing)

    3.4. 기본 프로그램 실행 레지스터(Basic Program Execution Registers)

    3.4.1. 범용 레지스터(General-Purpose Registers)

    3.4.1.1. 64비트 모드에서 범용 레지스터(General-Purpose Registers in 64-Bit Mode)

    3.4.2. 세그먼트 레지스터(Segment Registers)

    3.4.2.1. 64 비트 모드에서 세그먼트 레지스터(Segment Registers in 64-Bit Mode)

    3.4.3. EFLAGS 레지스터(EFLAGS Register)

    3.4.3.1. 상태 플래그(Status Flags)

    3.4.3.2. DF 플래스(DF Flag)

    3.4.3.3. 시스템 플래그와 IOPL 필드(System Flags and IOPL Field)

    3.4.3.4. 64 비트 모드에서 RFLAGS 레지스터(RFLAGS Register in 64-Bit Mode)

    3.5. 명령 포인터(Instruction Pointer)

    3.5.1. 64 비트 모드에서 명령 포인터(Instruction Pointer in 64-Bit Mode)

    3.6. 피연산자 크기와 주소 크기 속성(Operand-Size And Address-Size Attributes)

    3.6.1. 64비트 모드의 피연산자 크기와 주소 크기(Operand Size and Address Size in 64-Bit Mode)

    3.7. 피연산자 주소 배정(OPERAND ADDRESSING)

    3.7.1. 직접 피연산자(Immediate Operands)

    3.7.2. 레지스터 피연산자(Register Operands)

    3.7.2.1. 64-비트 모드에서 레지스터 피연산자(Register Operands in 64-Bit Mode)

    3.7.3. 메모리 피연산자(Memory Operands)

    3.7.3.1. 64 비트에서 메모리 피연산자(Memory Operands in 64-Bit Mode)

    3.7.4. 세그먼트 셀렉터 지정(Specifying a Segment Selector)

    3.7.4.1. 64-비트 모드에서 세그먼테이션(Segmentation in 64-Bit Mode)

    3.7.5. 오프셋 지정(Specifying an Offset)

    3.7.5.1. 64-비트 모드에서 오프셋 지정(Specifying an Offset in 64-Bit Mode)

    3.7.6. 어셈블러와 컴파일러 주소 배정 모드(Assembler and Compiler Addressing Modes)

    3.7.7. I/O 포트 주소 배정(I/O Port Addressing)


    3. 기본 실행 환경(Basic Execution Environment)

    이 장에서는 어셈블리 프로그래머가 볼 수 있는 Intel 64나 IA-32 프로세서의 기본 실행 환경을 설명한다. 프로세서가 명령어를 실행하는 방법과 데이터를 저장하고 조작하는 방법을 설명한다. 여기서 설명하는 실행 환경은 메모리 (주소 공간), 범용 데이터 레지스터, 세그먼트 레지스터, 플래그 레지스터 그리고 명령 포인터 레지스터다.

    3.1. 작동 방식(Modes of Operation)

    IA-32 아키텍처는 보호 모드, 실제 주소 모드 그리고 시스템 관리 모드라는 세 가지 기본 작동 모드를 지원한다. 운영 모드는 접근할 수 있는 명령어와 아키텍처 기능을 결정한다.

    • 보호 모드(Protected Mode) - 이 모드는 프로세서의 기본 상태(native state)다. 보호 모드의 기능에는 다중 작업 환경에서 "실제 주소 모드" 8086 소프트웨어를 직접 실행할 수 있는 기능이 있다. 이 기능은 Virtual-8086 모드로 불리는데, 실제 프로세서 모드는 아니다. Virtual-8086 모드는 모든 작업을 활성화 할 수 있는 보호 모드 속성이다.
    • 실제 주소 모드(Real-address Mode) - 이 모드는 확장 기능(보호되거나 시스템 관리 모드로 전환하는 기능)이 있는 Intel 8086 프로세서의 프로그래밍 환경을 구현한다. 프로세서는 전원을 켜거나 재부팅 후 실제 주소 모드에 위치한다.
    • 시스템 관리 모드(SMM, System Management Mode) -  이 모드는 전력관리나 시스템 보안과 같은 플랫폼의 특정 기능을 구현하기 위해 투명한 메커니즘을 운영체제나 executive에게 제공한다. 외부 SSM 인터럽트 핀 (SMI#)이 활성화되거나 고급 프로그래밍이 가능한 인터럽트 제어기(APIC, Advanced Programmable Interrupt Controller)에서 SMI를 수신하면 프로세서는 SMM으로 진입한다.
      SMM에서 프로세서는 현재 실행중인 프로그램이나 작업의 기본 문맥을 저장하는 동안 별도의 주소 공간으로 전환한다. 그래야 SMM 관련 코드를 투명하게 실행할 수 있다. SMM에서 복귀할 때, 프로세서는 시스템 관리 인터럽트 이전 상태로 돌아간다. SMM은 Intel386™SL과 Intel486™SL 프로세서와 함께 소개되었고, 펜티엄 프로세서 제품군의 표준 IA-32로 자리잡았다.

    3.1.1. Intel® 64 아키텍처(Intel® 64 Architecture)

    인텔 64 아키텍처는 IA-32e 모드를 추가한다. IA-32e 모드에는 두 가지 하위 모드가 있는데 이는 다음과 같다.

    • 호환 모드(Compatibility Mode) / IA-32e 모드의 하위 모드 - 호환 모드는 64비트 운영체제에서 오래된 16비트와 32비트 응용프로그램을 다시 컴파일하지 않고 실행할 수 있다. 단순하게, 호환성 하위 모드를 IA-32 아키텍처에서 호환 모드라고 부른다. 호환 모드의 실행 환경은 3.2절에서 설명한 것과 동일하다. 호환 모드는 64비트와 보호 모드에서 지원하는 모든 권한 레벨을 지원한다. Virtual-8086 모드에서 실행되거나 하드웨어 작업 관리를 사용하는 오래된 응용프로그램은 이 모드에서 작동하지 않는다.
      호환 모드는 코드 세그먼트 단위로 운영체제에서 사용할 수 있다. 이는 단일 64비트 OS가 64비트 모드에서 실행되는 64비트 응용프로그램을 지원하고, 오래된 32비트 응용프로그램(64비트 용으로 다시 컴파일하지 않고)을 지원할 수 있음을 의미한다.
      호환 모드는 32비트 보호 모드와 유사하다. 응용프로그램은 처음 4GB 선형 주소 공간에만 접근한다. 호환 모드는 16비트와 32비트 주소 그래고 피연산자 크기를 사용한다. 보호 모드처럼 이 모드에서 응용프로그램이 물리 메모리 확장(PAE, Physical Address Extensions)를 사용하여 4GB가 넘는 실제 메모리에 접근할 수 있다.
    • 64비트 모드 / IA-32e 모드의 하위 모드 - 이 모드는 64비트 운영체제가 64비트 선형 주소 공간에 접근하여 작성된 응용프로그램을 실행할 수 있게 한다. 단순하게, 64비트 하위 모드는 IA-32 아키텍처에서 64비트 모드라고 부른다.
      64비트 모드는 범용 레지스터와 SIMD 확장 레지스터의 수를 8에서 16으로 확장한다. 범용 레지스터는 64비트로 확장된다. 또한 모드는 레지스터 확장에 액세스하는 새로운 opcode 접두어 (REX)를 도입한다. 자세한 설명은 3.2.1 절을 참조한다.
      64비트 모드는 코드 세그먼트 단위로 운영체제에서 사용할 수 있다. 기본 주소 크기는 64비트고 기본 연산자 크기는 32비트다. 기본 피연산자 크기는 피연산자 크기만큼 덮어쓰는 접두어와 함께 REX opcode 접두어를사용하여 명령별로 재정의할 수 있다.
      REX 접두어를 허용하면 64비트 모드에서 작동할 때 64비트 피연산자를 지정할 수 있다. 이 메커니즘을 이용하여 64비트 레지스터와 64비트 주소를 사용할 수 있도록 기존의 많은 명령이 승격된다.

    3.2. 기본 실행 환경의 개요(Overview of the Basic Execution Environment)

    Intel 64 프로세서는 IA-32 프로세서의 기본 실행 환경을 지원하며, 64비트 프로그램(64비트 하위 모드)와 32비트 프로그램(호환 하위 모드) 실행할 수 있는 IA-32e 모드와 유사한 환경을 지원한다.

    IA-32 프로세서에서 실행되는 모든 프로그램이나 작업은 명령을 실행하고 코드, 데이터 그리고 상태 정보를 저장하기 위한 자원의 집합을 제공한다. 이러한 자원은 (그림 3-1에서 볼 수 있고 다음 단락에서 간략하게 설명 함) IA-32 프로세서의 기본 실행 환경을 구성한다.

    기본 실행 환경은 응용프로그램과 운영체제나 executive이 실행한 프로세서가 공동으로 사용한다.

    • 주소 공간(Address Space) - IA-32 프로세서에서 실행되는 모든 프로그램이나 작업은 최대 4GB (232 바이트) 선형 주소 공간과 최대 64GB (236 바이트) 물리 주소 공간을 주소로 쓸 수 있다. 4GB 보다 큰 주소 공간을 주소로 쓸 수 있는 자세한 정보는 3.3.6 절 "Extended Physical Addressing in Protected Mode"를 참조한다.
    • 기본 프로그램 실행 레지스터(Basic Program Execution Registers) - 8개의 범용 레지스터, 6개의 세그먼트 레지스터, EFLAGS 레지스터 그리고 EIP (명령 포인터) 레지스터는 범용적인 명령의 집합을 실행하는 기본 실행 환경을 구성한다. 이러한 명령은 바이트, 워드, 더블워드 정수에 대한 기본 산술 연산, 프로그램 흐름 제어를 처리, 비트와 바이트 문자열을 처리, 메모리 주소를 지정하는 수행한다. 이러한 레지스터에 대한 자세한 정보는 3.4 절 "Basic Program Execution Registers"를 참조한다.
    • x87 FPU 레지스터 - 8개의 x87 FPU 데이터 레지스터, x87 FPU 제어 레지스터, 상태 레지스터, x87 FPU 명령 포인터 레지스터, x87 FPU 피연산자 (데이터) 포인터 레지스터, x87 FPU 태그 레지스터 그리고 x87 FPU opcode 레지스터는 단정밀도(single-precision), 배정밀도(double-precision) 그리고 확장된 배정밀도(double extended-precision)를 통한 부동소수점 값, 워드 정수, 더블 워드 정수, 쿼드 워드 정수 그리고 BCD(Binary Coded Decimal) 값을 포함한 실행 환경을 제공한다.
    • MMX 레지스터 - 8 개의 MMX 레지스터는 64비트로 포장 된 바이트, 워드 그리고 더블 워드 정수에 대한 단일 명령, 다중 데이터(SIMD) 연산을 실행하도록 지원한다. 이 레지스터에 대한 자세한 내용은 9.2 절 "The MMX Technology Programming Environment"을 참조한다.
    • XMM 레지스터 - 8개의 XMM 데이터 레지스터와 MXCSR 레지스터는 128비트로 포장킹된 바이트, 워드, 더블 워드 그리고 쿼드 워드 정수와 128비트로 포장된 단정밀도와 배정밀도 부동소수점 값을 SIMD 연산으로 지원한다. 이 레지스터에 대한 자세한 내용은 10.2 절 "SSE Programming Environment"을 참조한다.
    • YMM 레지스터 - YMM 데이터 레지스터는 256비트로 포장된 단정밀도와 배정밀도 부동소수점 값과 256비트로 포장된 바이트, 워드, 더블워드 그리고 쿼드 워드 정수를 256비트 SIMD 연산으로 지원한다.
    • 바운드 레지스터(Bounds registers) - BND0-BND3 레지스터 각각은 메모리 버퍼에 대한 포인터를 지지하는 하위 및 상위 바운드(bounds) (각각 64비트)를 저장한다. 인텔 MPX 명령의 실행을 지원한다.
    • BNDCFGU와 BNDSTATUS - BNDCFGU는 경계(Bound) 검사시 사용자 모드 MPX 작업을 구성한다. BNDSTATUS는 MPX 작업으로 인한 #BR의 추가 정보를 제공한다.

    • 스택(Stack) - 프로 시저나 서브 루틴 호출 그리고 프로 시저나 서브 루틴 사이의 매개 변수 전달을 지원하기 위해 스택과 스택 권리 리소스는 실행 환경에 포함된다. 스택 (그림 3-1에 표시하지 않음)은 메모리에 위치한다. 스택 구조에 대한 자세한 정보는 6.2 절 "Stacks"를 참조한다.

    기본 실행 환경에서 제공되는 자원 외에도 IA-32 아키텍처는 시스템 레벨 아키텍처의 일부로 다음과 같은 자원을 제공한다. 이들은 운영체제와 시스템 개발 소프트웨어에 대한 광범위하게 지원한다. I/O 포트를 제외하고 시스템 자원은 Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volumes 3A & 3B에 자세히 설명되어 있다.

    • I/O 포트 - IA-32 아키텍처는 입력/출력 (I/O) 포트와 데이터 전송을 지원한다. 자세한 내용은 18 장 "Input/Output"을 참조한다.
    • 제어 레지스터(Control Registers) - 5 개의 제어 레지스터 (CR0부터 CR4)는 프로세서의 작동 모드와 현재 실행중인 작업의 특성을 결정한다. 자세한 내용은 Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A의 2장 "System Architecture Overview"를 참조한다.
    • 메모리 관리 레지스터(Memory Management Registers) - GDTR, IDTR, 작업 레지스터 그리고 LDTR은 보호 모드 메모리 관리에 사용되는 데이터 구조의 위치를 지정한다. 자세한 내용은 Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A의 2장 "System Architecture Overview"를 참조한다.
    • 디버그 레지스터(Debug Registers) - 디버그 레지스터 (DR0부터 DR7)는 프로세서의 디버깅 작업을 제어하고 모니터링을 허용한다. 자세한 내용은 Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3B를 참조한다.
    • 메모리 유형 범위 레지스터(MTRRs, Memory Type Range Registers) - MTRRs는 메모리 유형을 메모리 영역에 할당하기 위해 사용한다. 자세한 정보는 Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volumes 3A & 3B의 MTRRs 절을 참조한다.
    • 기계 고유 레지스터(MSRs, Machine Specific Registers) - 프로세서는 프로세서 성능을 제어하고 보고하는데 사용되는 다양한 기계 고유 레지스터를 제공한다. 가실상 모든 MSRs는 시스템 관련 기능을 처리하며 응용프로그램에서 접근할 수 없다. 이 규칙의 한 가지 예외는 타임 스탬프 카운터다. MSR은 Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3C의 35장 "Model-Specific Registers (MSRs)"에 설명되어 있다.
    • 기계 점검 레지스터(Machine Check Registers) - 기계 점검 레지스터는 하드웨어 (기계) 오류를 감지하고 보고하는데 사용되는 일련의 제어, 상태 그리고 오류 보고 MSR로 구성된다. 자세한 정보는 Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A의 15장 "Machine Check Architecture"를 참고한다.
    • 성능 모니터링 카운터(Performance Monitoring Counters) - 성능 모니터링 카운터를 사용하여 프로세서 성능 이벤트를 모니터링 할 수 있다. 자세한 정보는 Intel® 64 and IA-32 Architectures Software developer’s Manual, Volume 3B의 18장 "Performance Monitoring"을 참고한다.

    이 장의 나머지 부분에서는 메모리와 주소 공간의 구성, 기본 프로그램 실행 레지스터 그리고 주소 배정 모드를 설명을 한다. 그림 3-1에 표시된 다른 프로그램 실행 자원에 대한 설명은 이 볼륨의 다음 장을 참조한다.

    • x87 FPU 레지스터 - 8장, "Programming with the x87 FPU"를 참조
    • MMX 레지스터 - 9장, "Programming with Intel® MMX™ Technology"를 참조
    • XMM 레지스터 - 10장, "Programming with Intel® Streaming SIMD Extensions (Intel® SSE)" 11장, "Programming with Intel® Streaming SIMD Extensions 2 (Intel® SSE2)" 그리고 12장, "Programming with Intel® SSE3, SSSE3, Intel® SSE4 and Intel® AESNI"을 참조
    • YMM 레지스터 - 14장, "Programming with AVX, FMA and AVX2"을 참조
    • BND 레지스터, BNDCFGU, BNDSTATUS - 13장, "Managing State Using the XSAVE Feature Set" 그리고 17장, "Intel® MPX"을 참조
    • 스택 구현 및 프로 시저 호출 - 6장, "Procedure Calls, Interrupts, and Exceptions"를 참조

    3.2.1. 64비트 모드 실행 환경(64-Bit Mode Execution Environment)

    64비트 모드를 위한 실행 환경은 3.2 절에서 설명한 것과 유사하다. 다음 단락에서 적용되는 차이점을 설명한다.

    • 주소 공간(Address Space) - IA-32 프로세서에서 64비트 모드로 실행되는 작업이나 프로그램은 최대 264 바이트(3.3.7.1 절에 설명된 표준  주소 배정 요구 사항에 적용 받음)의 선형 주소 공간과 최대 246 바이트의 물리 주소 공간을 처리할 수 있다. 소프트웨어는 프로세서에 의해 지원받는 물리 주소 크기에 대해 CPUID를 쿼리할 수 있다.
    • 기본 프로그램 실행 레지스터(Basic Program Execution Registers) - 사용할 수 있는 범용 레지스터 (GPRs)는 16개다. GPRs는 64비트 폭이며 바이트, 워드, 더블 워드, 쿼드 워드 정수에 대한 연산을 지원한다. 바이트 레지스터에 접근하는 것은 가장 낮은 8비트로 균일하게 수행된다. 명령 포인터 레지스터는 64비트다. EFLAGS 레지스터는 64비트 폭으로 확장되면 RFLAGS 레지스터로 바꿔 부른다. RFLAGS의 상위 32비트는 예약된 영역이다. RFLAGS의 하위 32비트는 EFLAGS와 동일하다. 그림 3-2를 참조하자.
    • XMM 레지스터 - SIMD 연산을 위한 16개의 XMM 레지스터가 있다. 이러한 레지스터에 대한 자세한 내용은 10.2 절 "SSE Programming Environment"를 참조한다.
    • YMM 레지스터 - SIMD 연산을 위한 16개의 YMM 데이터 레지스터가 있다. 이러한 레지스터에 대한 자세한 내용은 14장 "Programming with AVX, FMA and AVX2"을 참조한다.
    • BND 레지스터, BNDCFGU, BNDSTATUS - 13장 "Managing State Using the XSAVE Feature Set" 와 17장 "Intel® MPX"을 참조한다.
    • 스택 - 스택 포인터 크기는 64비트다. 스택 크기는 SS 디스크립터(비 64비트 모드이기 때문에) 의 비트에 의해 제어되거나 포인터의 크기가 명령 접두사에 의해 무시되지 않는다.
    • 제어 레지스터(Control registers) - 제어 레지스터는 64비트로 확장된다. 새로운 제어 레지스터 (작업 우선 순위 레지스터: CR8 또는 TPR)가 추가되었다. 자세한 정보는 2장 "Intel® 64 and IA-32 Architectures"을 참고한다.
    • 디버그 레지스터(Debug registers) - 디버그 레지스터는 64비트로 확장된다. 자세한 내용은 Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A의 17장 "Debug, Branch Profile, TSC, and Quality of Service"을 참고한다.
    • 디스크립터 테이블 레지스터(Descriptor table registers) - 글로벌 디스크립터 테이블 레지스터 (GDTR, Global Descriptor Table Register)과 인터럽트 디스크립터 테이블 레지스터 (IDTR, Interrupt Descriptor Table Register)은 10자이르토 확장되어 완전한 64비트 기반 주소를 유지할 수 있다. 로컬 디스크립터 테이블 레지스터 (LDTR, Local Descriptor Table Register)와 작업 레지스터(TR, Task Register)도 확장되어 전체 64비트 기반 주소를 보유한다.

    3.3. 메모리 조직(Memory Organization)

    프로세서그 버스에서 주소를 지정하는 메모리를 물리 메모리라고 부른다. 물리 메모리는 일련의 8비트 바이트로 구성된다. 각 바이트에는 물리적 주소라는 고유 주소가 할당된다. 프로세서가 Intel 64 아키텍처가 지원하지 않는 경우 물리 주소 공간의 범위는 0에서 최대 236 - 1 (64GB)이다. Intel 64 아키텍처는 물리와 선형 주소 공간을 변경을 소개한다. 이는 3.3.3절, 3.3.4절 그리고 3.3.7절에서 설명되어 있다.

    실제로 IA-32나 Intel 64 프로세서와 함께 작동하도록 설계된 운영체제나 executive는 프로세서의 메모리 관리 기능을 사용하여 메모리에 접근한다. 이러한 기능은 메모리를 효율적이고 안정적으로 관리할 수 있는 세그먼테이션과 페이징 같은 기능을 제공한다. 메모리 관리에 대한 자세한 내용은 Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A의 3장 "Protected-Mode Memory Management"를 참조한다. 다음 단락에서는 메모리 관리를 사용할 때 메모리 주소를 지정하는 기본적인 방법을 설명한다.

    3.3.1. IA-32 메모리 모델(IA-32 Memory Models)

    프로세서의 메모리 관리 기능을 사용하면, 프로그램은 물리 메모리를 직접 처리하지 못한다. 대신 세 가지 메모리 모델 중 하나를 사용 하여 메모리에 접근하는데 이는 평면(Flat), 분할(Segmented) 그리고 실제 주소 모드(Real Address Mode)다.

    • 평면 메모리 모델(Flat Memory Model) - 메모리는 하나의 프로그램을 연속적인 주소 공간(그림 3-3)으로 표현한다. 이 공간을 선형 주소 공간(Linear Address Space)이라고 부른다. 코드, 데이터 그리고 스택은 모두 이 주소 공간에 포함된다. 선형 주소 공간은 바이트 크기만큼 주소 배정이 가능하며, 주소는 0에서 232 - 1(64비트 모드가 아닌 경우)까지 연속적으로 실행된다. 선형 주소 공간에서 모든 바이트를 위한 주소를 선형 주소라 부른다.
    • 분할된 메모리 모델(Segmented Memory Model) - 메모리는 프로그램에 세그먼트라고 불리는 독립적인 주소 공간의 그룹으로 나타낸다. 코드, 데이터 그리고 스택은 일반적으로 별도의 세그먼트에 포함된다. 세그먼트의 바이트 주소를 지정하기 위해 프로그램은 논리적 주소를 발행한다. 이 논리적 주소는 세그먼트 셀렉터와 오프셋 (논리적 주소는 종종 원거리 포인터라고 함)으로 구성된다. 세그먼트 셀렉터는 접근할 세그먼트를 식별하고 오프셋은 세그먼트의 주소 공간에서 바이트를 식별한다. IA-32 프로세서에서 실행되는 프로그램은 크기와 유형이 다른 최대 16,383개의 세그먼트를 처리할 수 있으며, 각 세그먼트는 232 바이트로 클 수 있다.
      내부적으로, 시스템에 정의된 모든 세그먼트는 프로세서의 선형 주소 공간에 매핑된다. 메모리 위치에 접근하기 위해서 프로세서는 각 논리 주소를 선형 주소로 변환한다. 이 변환은 응용프로그램에 있어 투명하다.
      분할된 메모리를 사용하는 주된 이유는 프로그램과 시스템의 신뢰성을 높이는데 있다. 예를 들어 프로그램의 스택을 별도의 세그먼트로 배치하면 스택이 코드나 데이터 공간으로 확장되거나 명령이나 데이터를 덮어쓰지 못하게 된다.
    • 실제 주소 모드 메모리 모델(Real-Address Mode Memory Model) - 이것은 Intel 8086 프로세서의 메모리 모델이다. Intel 8086 프로세서에서 실행되도록 작성된 기존의 응용프로그램과의 호환성을 지원한다. 실제 주소 모드는 분할된 메모리의 특정 구현을 사용하는데, 여기서 선형 주소 공간에 프로그램과 운영체제/executive는 각각 최대 64 KB 크기의 세그먼트의 배열로 구성된다.
      자세한 정보는 Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3B의 20장 "8086 Emulation"를 참조한다.

    3.3.2. 페이징과 가상 메모리(Paging and Virtual Memory)

    평면 또는 분할된 메모리 모델을 사용하면 선형 주소 공간은 직접 또는 페이징을 통해 프로세서의 물리적 주소 공간으로 매핑된다. 직접 매핑(페이징 비활성화)을 사용할 때, 각 선형 주소는 물리적 주소와 일대일로 대응한다. 선형 주소는 변환하지 않고 프로세서의 주소 행에 전달된다.

    IA-32 아키턱처의 페이징 메커니즘 (페이징 활성화)를 사용할 때 선형 주소 공간은 가상 메모리에 매핑되는 페이지로 구분된다. 가상 메모리의 페이지는 필요에 따라 물리 메모리에 매핑된다. 운영체제나 executive이 페이징을 사용할 때, 페이징 메커니즘은 응용프로그램에 투명하다. 모든 응용프로그램이 보는 모든 것은 선형 주소 공간이다.

    또한, IA-32 아키턱처의 페이징 메커니즘에는 다음을 지원하도록 확장된다.

    • 물리 주소 확장 (PAE, Physical Address Extensions)을 사용하여 4GB 보다 큰 물리 주소 공간을 처리한다.
    • 페이지 크기 확장(PSE, Page Size Extensions)을 사용하여 선형 주소를 4메가 바이트 페이지 물리 주소에 매핑한다.

    자세한 정보는 Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A의 3장 "Protected-Mode Memory Management"를 참조한다.

    3.3.3. 64비트 모드의 메모리 조직(Memory Organization in 64-Bit Mode)

    Intel 64 아키텍처는 64GB보다 큰 물리적 주소 공간을 지원한다. IA-32 프로세서의 실제 물리 주소 공간은 구현에 따라 다르다. 64비트 모드 아키텍처는 64비트 선형 주소 공간을 지원한다. 하지만 Intel 64 아키텍처를 지원하는 프로세서는 64비트보다 작게 구현할 수 있다. (3.3.7.1절 참조) 선형 주소 공간은 PAE 페이징 메커니즘을 통해 프로세서 물리 메모리 공간에 매핑된다.

    3.3.4. 동작 모드 vs 메모리 모델(Modes of Operation vs. Memory Model)

    IA-32나 Intel 64 프로세서 용 코드를 작성할 때, 프로그래머는 사용중인 코드와 메모리 모델을 작동시킬 때 프로세서가 작동 할 운영 모드를 알아야한다. 동작 모드와 메모리 모델간의 관계는 다음과 같다.

    • 보호 모드(Protected Mode) - 보호 모드에 있을 때, 프로세서는 이 절에서 설명하는 메모리 모델 중 하나를 사용할 수 있다. (실제 주소 배정 모드 메모리 모델은 일반적으로 프로세서가 virtual-8086 모드에 있을 때만 사용) 사용되는 메모리 모델은 운영 시스템이나 executive의 설계에 따라 다르다. 멀티 태스킹이 구현되면, 개별 작업은 다른 메모리 모델을 사용할 수 있다.
    • 시스템 관리 모드(System Management Mode) - SMM에서 프로세서는 시스템 관리 RAM (SMRAM)이라고 하는 별도의 주소 공간으로 전환한다. 이 주소 공간에서 바이트를 주소로 지정하는데 사용되는 메모리 모델은 실제 주소 모드 모델과 유사하다. 더 자세한 내용은 Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3C의 34장 "System Management Mode"을 참조한다.
    • 호환 모드(Compatibility Mode) - 호환성 모드에서 실행할 필요가 있는 소프트웨어는 32비트 보호 모드에서 실행되도록 지정된 메모리 모델과 동일한 메모리 모델을 준수한다. 세그먼트화의 효과는 32비트 보호 모드 의미와 동일하다.
    • 64비트 모드(64-bit Mode) - 세그먼트화는 일반적으로 (하지만 완전하지 않게) 비활성화 되고, 평면 64비트 선형 주소 공간에 생성한다. 구체적으로, 프로세서는 64비트 모드에서 CS, DS, ES 그리고 SS의 세그먼트 기준을 0으로 처리한다. (이로 인해 선형 주소가 유효한 주소와 같게 만든다) 64비트 모드에서 분할 및 실제 주소 모드를 사용할 수 없다.

    3.3.5. 32비트 및 16비트 주소와 피연산자 크기(32-Bit and 16-Bit Address and Operand Sizes)

    보호 모드에서 IA-32 프로세서는 32비트 또는 16비트 주소와 피연산자 크기로 구성 된다. 32비트 주소와 피연산자 크기에서 최대 선형 주소나 세그먼트 오프셋은 FFFFFFFFH (232 -1)을 가진다. 피연산자 크기는 일반적으로 8비트 이거나 32비트다. 16비트 주소와 피연산자 크기에서 최대 선형 주소나 세그먼트 오프셋은 FFFFH (216 - 1)을 가진다. 피연산자 크기는 일반적으로 8비트 이거나 16비트다.

    32비트 주소로 배정할 때, 논리 주소 (또는 원거리 포인터)는 16비트 세그먼트 셀렉터와 32비트 오프셋으로 구성된다. 16비트 주소 배정을 사용할 때, 주소는 16비트 세그먼트 셀렉터와 16비트 오프셋으로 구성된다.

    명령 접두사를 사용하면 프로그램 내에 기본 주소 및/또는 피연산자 크기를 임시로 대체하도록 허용한다.

    보호 모드에서 동작할 때, 현재 실행중인 코드 세그먼트를 위한 세그먼트 디스크립터가 기본 주소와 피연산자 크기를 정의한다. 세그먼트 디스크립터는 응용 프로그램 코드에서 일반적으로 볼 수 없는 데이터 구조다. 어셈블러 지시문을 사용하면 프로그램에서 기본 주소 배정과 피연산자 크기를 선택하도록 허용한다. 어셈블러와 다른 도구는 코드 세그먼트에 대한 세그먼트 디스크립터를 적절하게 설정한다.

    실제 주소 모드에서 동작할 때 기본 주소 배정과 피연산자 크기는 16비트다. 32비트 주소 배정을 사용하려면 실제 주소 모드에서 주소 크기만큼 대체하여 사용할 수 있다. 그러나 최대로 허용되는 32비트 선형 주소는 여전히 000FFFFFH (220 - 1)이다.

    3.3.6. 보호 모드에서 확장된 물리적 주소 배정(Extended Physical Addressing in Protected Mode)

    P6 제품군 프로세서부터 시작한 IA-32 아키텍처는 최대 64GB(236 바이트)의 물리 메모리 주소 배정을 지원한다. 프로그램이나 작업이 주소 공간에 직접적으로 배정할 수 없다. 대신, 가상 메모리 관리 메커니즘을 통해 64GB 물리적 주소 공간에 매핑되는 최대 4GB 개별 선형 주소 공간으로 처리한다. 이 메커니즘을 사용하면 운영 체제는 프로그램이 64GB 물리 주소 공간 안에 4GB 선형 주소 공간 전환이 가능하다.

    확장된 물리 주소 배정을 사용하려면 프로세서가 보호 모드에서 작동해야하며, 운영 체제는 가상 메모리 관리 시스템을 제공한다. 더 자세한 정보는 Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A의 3장 "36-Bit Physical Addressing Using the PAE Paging Mechanism"과 "Protected-Mode Memory Management"를 살펴본다.

    3.3.7. 64 비트 모드에서 주소 계산(Address Calculations in 64-Bit Mode)

    대부분의 경우, 64비트 모드는 코드, 데이터 그리고 스택을 위해 평면 데이터 주소를 사용한다. 64비트 모드(주소 크기만큼 대체하지 않는 경우), 유효하게 주소를 계산한 크기는 64비트다. 유효한 주소 계산은 64비트 기반 및 인덱스 레지스터를 사용하고, 변위를 64비트로 부호 확장한다.

    64비트 모드의 평면 주소 공간에서, 선형 주소는 기본 주소가 0이기 때문에 유효 주소와 같다. FS나 GS 세그먼트가 0 기반이 아닌 형태와 함께 사용되는 경우 규칙은 적용되지 않는다. 64비트 모드에서 유효 주소 구성 요소가 추가되고 전체 64비트 세그먼트 기반을 추가하기 전에 유효 주소가 절단(명령어 LEA를 참조)된다. 64비트 모드에서 주소 배당 모드에 관계없이 기본은 절대로 절단되지 않는다.

    명령 포인터는 64비트 코드 오프셋을 지원하기 위해 64비트로 확장된다. 64비트 명령 포인터는 RIP로 불린다. 표 3-1은 RIP, EIP 그리고 IP 사이의 관계를 보여준다.

    일반적으로, 64비트에서 변위적이고 즉각적인 것은 64비트로 확장되지 않는다. 유효 주소 계산 중에는 여전히 32비트와 부호 확장으로 제한된다. 하지만 64비트 모드에서는 MOV 명령의 변위적이고 즉각적인 64비트를 위한 형태를 제공하여 지원한다.

    모든 16비트와 32비트 주소 계산은 IA-32e 모드에서 제로 베이스로 확장되어 64비트 주소를 형성한다. 주소 계산은 현재 모드의 유효 주소 크기(64비트 모드나 호환 모드)로 잘려지며, 모든 주소 크기 접두사에 의해 덮어쓰인다. 그 결과 전체 64비트 주소 폭으로 제로 기반으로 확장된다. 이 때문에 호환 모드에서 16비트와 32비트 응용 프로그램 실행은 64비트 모드 유효 주소의 하위 4GB에서만 접근할 수 있다. 마찬가지로, 64비트 모드에서 생성된 32비트 주소는 64비트 모드 유효 주소의 하위 4GB에만 접근할 수 있다.

    3.3.7.1. 표준 주소 배정(Canonical Addressing)

    64 비트 모드에서 주소는 마이크로 아기텍처에 의해 63 비트 내지 최상위로 구현된 비트가 모두 1 또는 0으로 설정되면 정식 형식으로 간주한다.

    Intel 64 아키텍처는 64 비트 선형 주소를 정의한다. 구현은 더 작은 비트를 지원할 수 있다. Intel 64 아키텍처를 사용하는 IA-32 프로세서의 첫 번째 구현은 48 비트 선형 주소를 지원한다. 다시 말해서, 표준 주소는 64에서 48 비트를 0 또는 1로 설정해야 한다. (비트 47이 0인지 1인지에 따라 다름)

    구현은 64 비트의 선형 주소를 모두 사용할 수 없지만, 최상위 구현 비트를 통해 63 비트를 검사하여 주소가 표준 형식인지 확인한다. 선형 메모리 참조가 표준 형식이 아닌 경우, 구현시 예외를 생성한다. 대부분의 경우 일반 보호 예외(#GP)가 생성된다. 그러나 명시적이거나 묵시적 스택 참조의 경우, 스택 오류 (#SS)가 생성된다.

    묵시적인 스택 참조하는 명령은 기본적으로 SS 세그먼트 레지스터를 사용한다. 여기에는 PUSH/POP 관련 명령과 RSP/RBP를 사용하는 명령을 포함한다. 이 경우 표준 오류는 #SS다.

    명령어가 기본 레지스터 RSP/RBP를 사용하고 세그먼트 재지정 접두사를 사용하여 비-SS 세그먼트를 지정하는 경우 표준 오류로 (#SS 대신) #GP를 생성한다. 64 비트 모드에서 FS와 GS 세그먼트 재지정만 이 상황에서 적용된다. 다른 세그먼트 재지정 접두사 (CS, DS, ES 그리고 SS)는 무시된다. 이 또한 "비-스택" 레지스터 참조에 적용된 SS 세그먼트 재정의가 무시된다는 것을 의미한다. 이러한 시퀀스는 여전히 표준 오류 (#SS가 아닌) #GP를 생성한다.

    3.4. 기본 프로그램 실행 레지스터(Basic Program Execution Registers)

    아키텍처는 일반 시스템과 애플리케이션 프로그래밍에서 사용하기 위해 16개의 기본 프로그램 실행 레지스터를 제공한다. 이 레지스터는 다음과 같이 그룹화 할 수 있다.

    • 범용 레지스터(General-purpose registers) - 이 8개의 레지스터는 피연산자의 포인터를 저장하는데 사용한다.
    • 세그먼트 레지스터(Segment registers) - 이 레지스터는 최대 6개의 세그먼트 셀렉터를 보유한다.
    • EFLAGS (프로그램 상태 및 제어) - 레지스터 EFLAGS 레지스터는 실행된 프로그램의 상태를 보고하고 프로세서의 제한된 (응용 프로그램 레벨) 제어를 허용한다.
    • EIP (명령 포인터) - 레지스터 EIP 레지스터는 실행될 다음 명령에 대한 위치를 32비트 포인터의 크기만큼 가진다.

    3.4.1. 범용 레지스터(General-Purpose Registers)

    32 비트 범용 레지스터 EAX, EBX, ECX, EDX, ESI, EDI, EBP, 그리고 ESP는 다음 항목의 기능을 제공한다.

    • 논리 및 산술 연산자 용 피연산자
    • 주소 계산을 위한 피연산자
    • 메모리 포인터

    이러한 모든 레지스터는 피연산자, 결과(result) 그리고 포인터의 일반적인 저장에 사용할 수 있으며, ESP 레지스터를 참조할 때는 주의해야한다. ESP 레지스터는 스택 포인터를 가지고 있으며, 일반적으로 다른 목적으로 사용해서는 안된다.

    많은 명령이 특정 레지스터에 할당하여 피연산자를 보유한다. 예를 들어, 문자열 명령은 ECX, ESI 그리고 EDI 레지스터의 내용을 피연산자로 사용한다. 분할된 메모리 모델을 사용할 때 일부 명령은 어떤 레지스터의 포인터가 특정 세그먼트와 관련있다고 가정한다. 예를 들어, 일부 명렁은 EBX 레지스터의 포인터가 DS 세그먼트의 메모리 위치를 가리키는 것으로 가정한다.

    명령으로 범용 레지스터를 특수하게 사용하는 방법은 5장 "Instruction Set Summary"을 참고한다. 또한 Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volumes 2A, 2B & 2C의 3장, 4장, 5장을 참조한다. 다음은 특수 용도에 대한 요약이다.

    • EAX - 피연산자와 결과 데이터 누산기
    • EBX - DS 세그먼트의 데이터에 대한 포인터
    • ECX - 문자열 및 반복 연산을 위한 카운터
    • EDX - I/O 포인터
    • ESI - DS 레지스터가 가리키는 세그먼트의 데이터에 대한 포인터. 문자열 연산을 위한 소스 포인터
    • EDI - ES 레지스터가 가리키는 세그먼트의 데이터 (또는 대상)에 대한 포인터. 문자열 연산을 위한 대상 포인터
    • ESP - 스택 포인터 (SS 세그먼트에서)
    • EBP - 스택의 데이터에 대한 포인터 (SS 세그먼트에서)

    그림 3-5에서 보듯이 범용 레지스터의 하위 16 비트는 8086과 인텔 286 프로세서에 있는 레지스터 집합에 직접적으로 매핑되며 AX, BX, CX, DX, BP, SI, DI 그리고 SP 이름으로 참조될 수 있다. EAX, EBX, ECX 그리고 EDX 레지스터의 각각의 하위 2 바이트는 AH, BH, CH, DH (상위 바이트)와 AL, BL, CL, DL (하위 바이트) 이름으로 참조된다.

    3.4.1.1. 64비트 모드에서 범용 레지스터(General-Purpose Registers in 64-Bit Mode)

    64비트 모드에서, 16 개의 범용 레지스터가 있고, 기본 피연산자 크기는 32비트다. 그러나, 범용 레지스터는 32비트나 64비트 피연산자로 작업할 수 있다. 피연산자 크기가 32비트로 지정된 경우 EAX, EBX, ECX, EDX, EDI, ESI, EBP, ESP, R8D - R15D를 사용할 수 있다. 피연산자 크기가 64비트로 지정된 경우 RAX, RBX, RCX, RDX, RDI, RSI, RBP, RSP, R8-R15를 사용할 수 있다. R8D-R15D/R8-R15는 새로운 범용 레지스터를 나타낸다. 이 모든 레지스터는 바이트, 워드, d워드 그리고 q워드 수준에서 접근할 수 있다. REX 접두어는 피연산자 크기를 64비트로 생성하거나 레지스터 R8-R15를 참조하는데 사용된다.

    64비트 모드(R8-R15와 XMM8-XMM15)에서만 사용 가능한 레지스터는 64비트 모드에서 호환 모드로 전환 한 후 64비트 모드로 다시 전환되는 동안 보존된다. 그러나, R8-R15와 XMM8-XMM15의 값은 64비트 모드에서 옛날의 호환 모드나 실제 모드로 전환한 후에나 호환 모드를 통해 64비트 모드로 돌아가면 정의되지 않는다.

    64비트 모드에서 바이트 레지스터 접근하는 것을 제한한다. 명령은 예전의 상위 바이트(예, AH, BH, CH, DH)와 새 바이트 레지스터 중 하나를 동시에 참조할 수 없다. (예, RAX 레지스터의 하위 바이트) 하지만, 명령은 예전의 하위 바이트(예, AL, BL, CL 또는 DL)와 새로운 바이트 레지스터(예, R8 레지스터의 하위 바이트나 RBP)를 동시에 참조 할 수 있다. 아키텍처는 접두사 REX를 사용하는 명령에 대해 상위 바이트(AH, BH, CH, DH) 참조를 하위 바이트(BPL, SPL, DIL, SIL: RBP, RSP, RDI 그리고 RSI의 하위 8비트) 참조로 변경함으로써 제한적으로 적용한다.

    64비트 모드에서 피연산자 크기는 대상(destination) 범용 레지스터의 유효 비트수를 결정한다.

    • 64비트 피연산자는 대상 범용 레지스터에서 64비트 결과를 생성한다.
    • 32비트 피연산자는 대상 범용 레지스터에서 64비트 결과로 제로 기반으로 확장된 32비트 결과를 생성한다.
    • 8비트와 16비트 피연산자는 8비트와 16비트 결과를 생성한다. 대상 범용 레지스터의 48비트나 56비트 이상은 연산에 의해 수정되지 않는다. 8비트나 16비트 연산의 결과가 64비트 주소 계산을 위해 예정된 경우 명시적으로 레지스터를 전체 64비트로 부호 확장한다.

    64비트 범용 레지스터의 상위 32비트는 32비트 모드에서 정의되지 않았으므로 64비트 모드에서 32비트 모드로 전환 할때 범용 레지스터의 상위 32비트는 모존되지 않는다. (보호 모드 또는 호환 모드) 64비트에서 32비트 모드로 전환한 후에는 소프트웨어가 이 비트에 의존해서는 안된다.

    3.4.2. 세그먼트 레지스터(Segment Registers)

    세그먼트 레지스터 (CS, DS, SS, ES, FS 그리고 GS)는 16 비트 세그먼트 셀렉터를 보유한다. 세그먼트 셀렉터는 메모리의 세그먼트를 식별하는 특수 포인터다. 메모리의 특정 세그먼트에 접근하는 것은, 해당 세그먼트의 세그먼트 셀렉터가 세그먼트 레지스터에 있어야 한다.

    응용프로그램 코드를 작성할 때, 프로그래머는 일반적으로 어셈블러 지시문과 심볼을 사용하여 세그먼트 선택기를 만든다.어셈블러와 기타 도구는 이러한 지시문과 심볼과 관련된 실제 세그먼트 셀렉터 값을 만든다. 시스템 코드를 작성하는 경우, 프로그래머는 세그먼트 셀렉터를 직접 작성해야 할 수 있다. 자세한 정보는 Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A의 3장 "Protected-Mode Memory Management"를 참조한다.

    세그먼트 레지스터를 사용하는 방법은 운영체제나 executive가 사용하는 메모리 관리 모델 유형에 따라 다르다. 평면(비분할) 메모리 모델을 사용할 때, 세그먼트 레지스터는 중첩 세그먼트를 가리키는 세그먼트 셀렉터를 로드하며, 각 세그먼트는 선형 주소 공간의 주소 0에서 시작한다. (그림 3-6) 이러한 중첩 세그먼트는 프로그램의 선형 주소 공간을 구성한다. 일반적으로 두 개의 중첩 세그먼트는 정의된다. 하나는 코드고 다른 하나는 데이터와 스택이다. CS 세그먼트 레지스터 포인터는 코드 세그먼트를 가리키고, 모든 다른 세그먼트 레지스터 포인터는 데이터와 스택 세그먼트를 가리킨다.

    분할된 메모리 모델을 사용할 때, 각 세그먼트 레지스터는 일반적으로 다른 세그먼트 셀렉터로 로드되어 각 세그먼트 레지스터는 선형 주소 공간 안에 다른 세그먼트를 가리킨다. (그림 3-7을 참조) 따라서 프로그램은 언제든지 선형 주소 공간에서 최대 6 개의 세그먼트에 접근할 수 있다. 세그먼트 레지스터 중 하나를 가리키고 있지 않은 세그먼트에 접근하는 것은, 프로그램이 먼저 접근할 세그먼트의 세그먼트 셀렉터를 세그먼트 레지스터에 로드해야 한다.

    각 세그먼트 레지스터는 코드, 데이터 또는 스택의 세 가지 유형 중 하나와 연결된다. 예를 들어, CS 레지스터에는 실행되었거나 저장된 코드 세그먼트에 대한 세그먼트 셀렉터가 포함된다. EIP 레지스터에는 실행 될 다음 명령어의 코드 세그먼트 안에 오프셋이 포함된다. CS 레지스터는 응용프로그램에 의해 명시적으로 로드될 수 없다. 대신, 프로그램 제어(예, 프로시저 호출, 인터럽트 처리 또는 작업전환)를 변경하는 내부 프로세서 동작이나 명령에 의해 암시적으로 로드된다.

    DS, ES, FS 그리고 GS 레지스터는 네 개의 데이터 세그먼트를 가리킨다. 네 개의 데이터 세그먼트를 사용할 수 있으므로, 서로 다른 유형의 데이터 구조에 효율적이고 안전하게 접근할 수 있다. 예를 들어, 네 개의 개별 데이터 세그먼트가 생성될 수 있다. 하나는 현재 모듈의 데이터 구조, 다른 하나는 상위 모듈에서 보낸 데이터, 또 다른 하나는 동적으로 생성된 데이터 구조, 마지막 네번째는 다른 프로그램과 함께 공유된 데이터다. 추가 데이터 세그먼트에 접근하는 것은 응용프로그램이 필요에 따라 이러한 세그먼트에 대한 세그먼트 셀렉터를 DS, ES, FS 그리고 GS 레지스터에 로드해야 한다.

    SS 레지스터에는 현재 실행중인 프로그램, 작업이나 처리기에 대한 프로시저 스택이 저장되는 스택 세그먼트에 대한 세그먼트 셀렉터가 포함된다. 모든 스택 연산은 SS 레지스터를 사용하여 스택 세그먼트를 찾는다. CS 레지스터와 달리 SS 레지스터는 명시적으로 로드할 수 있으므로, 응용 프로그램이 여러 스택과 이들 사이를 전환하도록 설정할 수 있다.

    세그먼트 레지스터가 실제 주소 모드에서 사용되는 방법에 대한 내용은 3.3 절 "Memory Organization"을 참조한다.

    4 개의 세그먼트 레지스터 CS, DS, SS 그리고 ES는 Intel 8086과 Intel 286 프로세서에 있는 세그먼트 레지스터와 동일하며, FS와 GS 레지스터는 Intel 386™ 프로세서 제품군의 IA-32 아키텍처에 도입되었다.

    3.4.2.1. 64 비트 모드에서 세그먼트 레지스터(Segment Registers in 64-Bit Mode)

    64비트 모드에서 CS, DS, ES, SS는 연관된 세그먼트 디스크립트 기준의 값과 관계없이 각 세그먼트 기준이 0인것 처럼 처리된다. 이렇게 하면 코드, 데이터, 스택에 대한 평면 주소 공간이 만들어진다. FS와 GS는 예외다. 두 세그먼트 레지스터는 선형 주소 계산(로컬 데이터와 특정 운영 체제 데이터 구조의 주소 배정)에서 추가 기본 레지스터로 사용될 수 있다.

    분활화가 일반적으로 불가능 하더라도, 세그먼트 레지스터로 인해 프로세서가 세그먼트 접근을 돕도록 수행할 수 있다. 이러한 작업을 수행하는 동안 활성화된 프로세서는 로드된 값에 대한 기존(legacy) 검사를 지속적으로 대부분 수행한다. (검사가 64 비트 모드에서 적용되지 않은 경우에도) 64 비트 모드에서 로드된 세그먼트 레지스터가 호환 모드에서 실행되는 응용프로그램에서 사용될 수 있기에 이러한 검사가 필요하다

    64비트 모드에서 CD, DS, ES, SS, FS 그리고 GS의 검사 한계가 비활성화 된다.

    3.4.3. EFLAGS 레지스터(EFLAGS Register)

    32비트 EFLAGS 레지스터는 상태 플래그, 제어 플래그, 그리고 시스템의 그룹 플래그를 포함한다. 그림 3-8은 이 레지스터 안의 플래그를 정의한다. 프로세서 초기화 (RESET 핀 또는 INIT 핀을 주장함(asserting)으로써) 후 EFLAGS 레지스터의 상태는 00000002H다. 이 레지스터 비트는 1, 3, 5, 15 그리고 22 부터 31은 예약되어 있다. 소프트웨어는 이러한 비트의 상태를 사용하거나 종속해서는 안된다.

    EFLAGS 레지스터의 일부 플래그는 특수 목적 명령(다음 절에서 설명)을 사용하여 직접 수정할 수 있다. 전체 레지스터를 직접 검토하거나 수정할 수 있는 명령은 없다. LAHF, SAHF, PUSHF, PUSHFD, POPF 그리고 POPFD 명령은 절차(procedure) 스택이나 EAX 레지스터에서 플래그의 그룹을 옮기는데 사용할 수 있다. EFLAGS 레지스터의 내용이 절차(procedure) 스택이나 EAX 레지스터로 부터 전송 받은 후 플래그는 프로세서의 비트 조작 명령 (BT, BTS, BTR 그리고 BTC0를 사용하여 검사하고 수정할 수 있다.

    작업을 일시 중단 할 때 (프로세서의 멀티 태스킹 기능 사용), 프로세서는 일시 중단되는 작업에 대한 EFLAGS 레지스터의 상태를 작업 상태 세그먼트(TSS)에 자동으로 저장한다. 새로운 작업에 자체적으로 바인딩 할 때, 프로세서는 새로운 작업의 TSS로부터 데이터와 함께 EFLAGS 레지스터를 로드한다.

    인터럽트 또는 예외 처리기 프로시저에 대한 호출이 발생하면, 프로세서는 EFLAGS 레지스터의 상태를 프로시저 스택에 자동 저장한다. 인터럽트나 예외를 태스크 스위치와 함께 처리될 때, EFLAGS 레지스터의 상태는 일시 중단된 작업을 위해 TSS에 저장된다.

    IA-32 아키텍처가 발전함에 따라, 플래그가 EFLAGS 레지스터에 추가되었지만, 기존 플래그의 기능과 배치는 IA-32 프로세서 제품군에서 다음 버전으로 동일하게 유지되었다. 결과적으로, IA-32 프로세서의 한 패밀리에 대해 이러한 플래그에 접근하거나 수정하는 코드는 나중에 프로세서의 제품군에서 실행될 때 예상대로 동작한다.

    3.4.3.1. 상태 플래그(Status Flags)

    EFLAGS 레지스터의 상태 플래그 (비트 0, 2, 4, 6, 7 그리고 11)은 ADD, SUB, MUL 그리고 DIV 명령과 같은 산술 명령의 결과를 나타낸다. 상태 플래그 기능은 다음과 같다.

    CF (bit 0) / 캐리 플래그 (Carry Flag) - 산술 연산이 결과의 최상위 비트에서 carry나 borrow를 생성하는 경우 set되며 그렇지 않으면 clear 된다. 이 플래그는 부호 없는 정수 연산의 오버플로우 조건을 나타낸다. 또한 다중 정밀도 산술에도 사용된다.

    PF (bit 2) / 패리티 플래그(Parity Flag) - 결과의 최하위 바이트가 1 비트의 짝수를 포함하면 set되며 그렇지 않으면 clear된다.

    AF (bit 4) / 보조 캐리 플래그(Auxiliary Carry Flag) - 산술 연산이 결과의 비트 3에서 carry나 borrow를 생성하는 경우 set되며 그렇지 않으면 clear된다. 이 플래그는 이진화 십진법(BCD, Binary-Coded Decimal) 산술에 사용된다.

    ZF (bit 6) / 제로 플래그(Zero Flag) - 결과가 0인 경우 set되며 그렇지 않으면 clear된다.

    SF (bit 7) / 사인 플래그(Sign Flag) - 부호있는 정수의 부호 비트인 결과의 최상위 비트와 동일하게 set한다. (0은 양수이고 1은 음수다.)

    OF (bit 11) / 오버플로우 플래그(Overflow Flag) - 정수 결과가 대상 피연산자에 맞도록 양수가 너무 크거나 음수가 너무 작으면 (부호 비트 제외) set한고 그렇지 않으면 clear한다. 이 플래그는 부호 있는 정수 (2의 보수) 산술에 대한 오버플로우 조건을 나타낸다.

    이 상태 플래그 중에서 STC, CLC 그리고 CMC 명령을 사용하여 CF 플래그만 직접 수정할 수 있다. 또한 비트 명령 (BT, BTS, BTR 그리고 BTC)는 지정된 비트를 CF 플래그에 복사한다.

    상태 플래그는 단일 산술 연산이 부호 없는 정수, 부호 있는 정수 그리고 BCD 정수 세 가지 다른 데이터 유형에 대한 결과를 생성할 수 있다. 산술 연산의 결과가 부호 없는 정수로 처리되면, CF 플래그는 범위를 벗어난 조건(carry나 borrow)을 나타낸다. 부호 있는 정수 (2의 보수)로 취급 될 경우, F 플래그는 carry 또는 borrow를 나타낸다. 그리고 BCD 자리로 처리되면 AF 플래그는 carry 또는 borrow를 나타낸다. SF 플래그는 부호 있는 정수의 부호를 나타낸다. ZF 플래그는 부호가 있거나 부호가 없는 정수 0을 나타낸다.

    정수에 대해 다중 정밀도 산술 연산을 수행할 때, CF 플래그는 carry를 추가(ADC)와 borrow 제거(SBB) 명령과 함께 사용되어 하나의 계산에서 다음 계산으로 carry 또는 borrow를 전달한다.

    조건 명령 Jcc (jump on condition code cc), SETcc (byte set on condition cod ecc), LOOPcc 그리고 CMOVcc (conditional move)는 하나 이상의 상태 플래그를 조건 코드로 사용하여 분기(branch), 셋바이트(setbyte) 또는 엔드 루프 조건(end-loop conditions)를 테스트한다.

    3.4.3.2. DF 플래스(DF Flag)

    방향 플래그(Direction Flag) (DF, EFLAGS 레지스터의 비트 10에 위치)는 문자열 명령(MOVS, CMPS, SCAS, LODS 그리고 STOS)을 제어한다. DF 플래그를 set하면 문자열 명령이 자동으로 감소한다. (높은 주소에서 낮은 주소로 문자열을 처리하기 위해) DF 플래그를 clear하면 문자열 명령이 자동으로 증가한다. (낮은 주소에서 높은 주소로 문자열을 처리)

    STD와 CLD 명령은 각 DF 플래그를 set하고 clear한다.

    3.4.3.3. 시스템 플래그와 IOPL 필드(System Flags and IOPL Field)

    EFLAGS 레지스터의 시스템 플래그와 IOPL 필드는 운영체제나 executive operations을 제어한다. 응용 프로그램에 의해 수정되어서는 안된다. 시스템 플래그의 기능은 다음과 같다.

    TF (bit 8) / 트랩 플래그 - 디버깅을 위한 단일 단계 모드를 활성화하기 위해서 set되고 그렇지 않으면 clear한다.

    IF (bit 9) / 인터럽트 활성 플래그 - 마스킹 가능한 인터럽트 요청에 대한 프로세서의 응답을 제어한다. 마스킹이 가능한 인터럽트에 응답하려면 set하고, 그렇지 않으면 clear한다.

    IOPL (bits 12 and 13) / I/O 권한 레벨 필드 - 현재 실행중인 프로그램이나 작업의 I/O 권한 레벨을 나타낸다. 현재 실행중인 프로그램이나 작업의 현재 권한 레벨(CPL, Current Privilege Level)은 I/O 주소 공간에 접근하기 위해 I/O 권한 레벨보다 작거나 같아야한다. POPF와 IRET 명령은 CPL이 0일 때만 필드를 수정할 수 있다.

    NT (bit 14) / 중첩 작업 플래그 - 중단 및 호출된 작업의 연결을 제어한다. 현재 작업이 이전에 실행된 작업에 연결될 때 set된다. 연결되어 있지 않으면 clear된다.

    RF (bit 16) / 재시작 플래그 - 디버그 예외에 대한 프로세서의 응답을 제어한다.

    VM (bit 17) / Virtual-8086 모드 플래그 - virtual-8086 모드 활성화하면 set하고 virtual-8086 모드의 의미없이 보호 모드로 돌아가려면 clear한다.

    AC (bit 18) / 계열 점검 (또는 접근 제어) 플래그 - AM 비트가 CR0 레지스터에 set되면 플래그가 1인 경우에만 사용자 모드 데이터 접근의 계열 검사가 활성화된다.

    SMAP 비트가 CR4 레지스터에 설정된 경우 비트가 1이면 사용자 모드 페이지에 대한 명시적 감독 모드(supervisor-mode)의 데이터 접근이 허용된다. 자세한 내용은 Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A의 4.6절 "Access Rights"를 참고한다.

    VIF (bit 19) / 가상 인터럽트 플래그 - IF 플래그의 가상 이미지다. VIP 플래그와 함께 사용된다. (이 플래그와 VIP 플래그를 사용하려면 제어 레지스터 CR4의 VME 플래그를 설정하여 가상 모드 확장을 사용할 수 있다.)

    VIP (bit 20) / 가상 인터럽트 보류 플래그 - 인터럽트가 보류중임을 나타낼때 set하고 아닐땐 clear한다. (소프트웨어는 이 플래그를 set과 clear하고 프로세서는 읽을 수만 있다.) VIF 플래그와 함께 사용된다.

    ID (bit 21) / 식별 플래그 - 이 플래그를 설정하거나 지울 수 있는 프로그램의 기능은 CPUID 명령에 대한 지원을 나타낸다.

    이러한 플래그의 자세한 내용은 Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A의 3장 "Protected-Mode Memory Management"을 참조한다.

    3.4.3.4. 64 비트 모드에서 RFLAGS 레지스터(RFLAGS Register in 64-Bit Mode)

    64 비트 모드에서 EFLAGS는 64 비트로 확장되어 RFLAGS로 불린다. RFLAGS 레지스터의 상위 32 비트는 예약되어 있다. RFLAGS의 하위 32 비트는 EFLAGS와 동일하다.

    3.5. 명령 포인터(Instruction Pointer)

    명령 포인터(EIP) 레지스터는 실행될 다음 명령에 대한 현재 코드 세그먼트의 오프셋을 포함한다. JMP, Jcc, CALL, RET 그리고 IRET 명령을 실행할 때 하나의 명령 경계에서 다음 직선 코드로 진행되거나 여러 명령어로 앞뒤로 이동한다.

    EIP 레지스터는 소프트웨어로 직접 접근할 수 없다. 제어 전달 명령, 인터럽트 그리고 예외에 대해 묵시적으로 제어된다. EIP 레지스터를 읽는 유일한 방법은 CALL 명령을 실행한 다음 프로시저 스택에서 반환 명령 포인터의 값을 읽는 것이다. EIP 레지스터는 프로시저 스택의 반환 명령 포인터 값을 수정하고 반환 명령 (RET나 IRET)를 실행하여 간접적으로 로드할 수 있다. 자세한 정보는 6.2.5.2 절 "Returen Instruction Pointer"를 참조한다.

    모든 IA-32 프로세서는 명령을 프리페치(prefetch)한다. 명령 프리페치로 인해 명령을 로드하는 동안 버스로 부터 읽은 명령 주소가 EIP 레지스터의 값과 일치하지 않는다. 다른 프로세서 세대가 다른 프리페치 메커니즘을 사용하더라도 프로그램 흐름을 지시하는 EIP 레지스터의 기능은 IA-32 프로세서에서 실행되도록 작성된 모든 소프트웨어와 완벽하게 호환된다.

    3.5.1. 64 비트 모드에서 명령 포인터(Instruction Pointer in 64-Bit Mode)

    64 비트 모드에서 RIP 레지스터가 명령 포인터다. 이 레지스터는 실행된 다음 명령의 64 비트 오프셋을 유지한다. 64 비트 모드는 RIP 상대 주소 배정이라는 기술도 지원한다. 이 기술을 사용하면, 유표 주소는 다음 명령의 RIP에 변위를 추가하도록 결정된다.

    3.6. 피연산자 크기와 주소 크기 속성(Operand-Size And Address-Size Attributes)

    프로세서가 보호 모드에서 실행할 때 모든 코드 세그먼트는 주소 크기 속성과 피연산자 크기 속성이 있다. 이러한 속성은 코드 세그먼트를 위한 세그먼트 디스크립터의 D (기본 크기)플래그로 선택된다. (자세한 내용은 Intel® 64 and IA-32 Architectures  Software Developer’s Manual, Volume 3A의 3장 "Protected-Mode Memory Management"를 참조한다. D 플래그가 set되면 32 비트 피연산자 크기와 주소 크기 속성이 선택된다. 플래그가 clear할 때, 16 비트 크기 속성은 선택된다. 프로세서가 실제 주소 모드, virtual-8086 모드 또는 SMM에서 실행할 때, 기본 피연산자 크기와 주소 크기 속성은 항상 16 비트로 구성된다.

    피연산자 크기 속성은 피연산자의 크기를 선택한다.16 비트 피연산자 크기 속성으로 적용할 때, 피연산자는 일반적으로 8 비트나 16 비트일 수 있으며, 32 비트 피연산자 크기 속성으로 적용한 경우, 피연산자는 일반적으로 8 비트 또는 32 비트가 될 수 있다.

    주소 크기 속성은 메모리 주소 배정에 사용되는 주소의 크기 16비트나 32비트를 선택한다. 16 비트 주소 크기 속성으로 적용할 때, 세그먼트 오프셋과 변위는 16비트다. 이 제한 사항은 세그먼트의 크기를 64KB로 제한한다. 32 비트 주소 크기 속성으로 적용될 때 세그먼트 오프셋과 변위는 32 비트이므로 최대 4GB를 처리할 수 있다.

    기본 피연산자 크기 속성과 또는 주소 크기 속성은 명령에 피연산자 크기 속성과 주소 크기 속성 접두사를 추가하여 특정 명령을 무시할 수 있다. 자세한 내용은 Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 2A의 2장 "Instruction Format"을 참조한다. 이 접두어의 효과는 대상 명령에만 적용된다.

    표 3-4는 D 플래그와 피연산자 크기 그리고 주소 크기 접두어의 설정에 따라 유효한 피연산자 크기와 주소 크기(보호 모드나 호환 모드에서 실행한 경우)를 보여준다.

    3.6.1. 64비트 모드의 피연산자 크기와 주소 크기(Operand Size and Address Size in 64-Bit Mode)

    64 비트 모드에서 기본 주소 크기는 64 비트고 기본 피연산자 크기는 32 비트다. 접두사를 사용하여 기본값을 무시할 수 있다. 주소 크기와 피연산자 크기 접두사를 사용하면 명령별 32/64 비트 데이터와 32/64 비트 주소를 혼합할 수 있다. 표 3-4는 64 비트 모드에서 피연산자 크기를 무시하는데 사용할 수 있는 66H 명령 접두어와 REX.W 접두어 유효한 조합을 보여준다. 64 비트 모드에서 16 비트 주소는 지원하지 않는다.

    REX 접두어는 16개의 다른 값으로 구성하는 4비트 필드로 구성된다. REX 접두어에서 W 비트 필드는 REX.W로 부른다. REX.W 필드가 올바르게 set한 경우, 접두사는 64 비트의 피연산자 크기를 무시하도록 지정한다. 소프트웨어는 여전히 피연산자 크기 66H 접두어를 사용하여 16 비트 피연산자 크기로 껏다 켰다할 수 있다. 그러나 REX.W를 설정하면 피연산자 크기 접두사 (66H)보다 우선한다.

    SSE/SSE2/SSE3/SSSE3 SIMD 명령의 경우, 66H, F2H, F3H 접두사는 opcode 확장에 필수다. 이 경우 유효한 REX.W 접두어와 66H opcode 확장 접두사 사이에 상호작용은 존재하지 않는다.

    자세한 정보는 Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 2A의 2장 "Instruction Format"을 참조한다.

    3.7. 피연산자 주소 배정(OPERAND ADDRESSING)

    IA-32 기계 명령은 0개 이상의 피연산자에서 동작한다. 일부 피연산자는 명시적으로 지정되고, 다른 피연산자는 묵시적으로 지정된다. 근원지(Source) 피연산자에 대한 데이터는 다음 위치에 있다.

    • 명령 자체 (즉시 피연산자)
    • 레지스터
    • 메모리 위치
    • I/O 포트

    명령에 대한 목적지(Destination) 피연산자에 데이터를 반환할 때, 다음과 같이 반환될 수 있다.

    • 레지스터
    • 레모리 위치
    • I/O 포트

    3.7.1. 직접 피연산자(Immediate Operands)

    일부 명령은 명령 자체에서 인코딩된 데이터를 근원지(Source) 피연산자로 사용한다. 이러한 피연산자는 직접 피연산자(또는 단순히 즉각 연산(immediates))로 불린다. 예를 들어 다음 ADD 명령은 EAX 레지스터의 내용에 즉시 값 14를 추가한다.

    ADD EAX, 14

    모든 산술 명령 (DIV와 IDIV 명령은 제외)은 근원지(Source) 피연산자는 즉시 해당 값을 연산하도록 허용한다. 직접 피연산자에 허용되는 최대 값은 명령에 따다 다르지만 절대 부호 없는 더블 워드 정수(232)의 최대 값보다 클 수 없다.

    3.7.2. 레지스터 피연산자(Register Operands)

    근원지(Source)와 목적지(Destination) 피연산자는 실행중인 명령에 따라 다음 레지스터 중 하나가 될 수 있다.

    • 32-비트 범용 레지스터 (EAX, EBX, ECX, EDX, ESI, EDI, ESP, EBP)
    • 16-비트 범용 레지스터 (AX, BX, CX, DX, SI, DI, SP, BP)
    • 8-비트 범용 레지스터 (AH, BH, CH, DH, AL, BL, CL, DL)
    • 세그먼트 레지스터 (CS, DS, SS, ES, FS, GS)
    • EFLAGS 레지스터
    • x87 FPU 레지스터 (ST0부터 ST7, status word, control word, tag word, data operand pointer, and instruction pointer)
    • MMX 레지스터 (MM0부터 MM7)
    • XMM 레지스터 (XMM0부터 XMM7)와 the MXCSR 레지스터
    • 제어 레지스터 (CR0, CR2, CR3, CR4)와 시스템 테이블 포인터 레지스터(GDTR, LDTR, IDTR, 작업 레지스터)
    • 디버그 레지스터 (DR0, DR1, DR2, DR3, DR6, and DR7)
    • MSR 레지스터

    일부 명령은 한쌍의 32 비트 레지스터에 포함된 쿼드워드 피연산자를 사용한다. 레지스터 쌍은 이를 구분하기 위해 콜론으로 표시된다. 예를 들어, 레지스터 쌍 EDX:EAX에서 쿼드워드 피연산자의 EDX는 상위 명령 비트를 포함하고, EAX는 하위 명령 비트를 포함한다.

    EFLAGS 레지스터의 내용을 로드하고 저장하거나 레지스터의 개별 플래그를 set하거나 clear하는데 필요한 몇 가지 명령(PUSHFD와 POPFD 명령 같은)이 제공된다. 다른 명령(Jcc 명령과 같은)은 분기 또는 기타 의사 결정 작업을 위한 조건 코드로 EFLAGS 레지스터에서 상태 플래그의 상태를 사용한다.

    프로세서는 메모리 관리, 인터럽트와 예외 처리, 작업 관리, 프로세서 관리 그리고 디버깅 활동을 제어하는데 사용되는 시스템 레지스터의 집합을 포함한다. 이러한 시스템 레지스터의 일부는 시스텀 명령의 집합을 통해 응용프로그램, 운영 체제 또는 executive가 접근할 수 있다. 시스템 명령과 함께 시스템 레지스터에 접근할 때, 레지스터는 일반적으로 명령의 묵시적인 피연산자다.

    3.7.2.1. 64-비트 모드에서 레지스터 피연산자(Register Operands in 64-Bit Mode)

    64 비트 모드의 레지스터 피연산자는 다음 중 하나 일 수 있다.

    • 64-비트 범용 레지스터 (RAX, RBX, RCX, RDX, RSI, RDI, RSP, RBP, or R8-R15)
    • 32-비트 범용 레지스터 (EAX, EBX, ECX, EDX, ESI, EDI, ESP, EBP, or R8D-R15D)
    • 16-비트 범용 레지스터 (AX, BX, CX, DX, SI, DI, SP, BP, or R8W-R15W)
    • 8-비트 범용 레지스터: AL, BL, CL, DL, SIL, DIL, SPL, BPL, 그리고 R8L-R15L은 REX 접두어를 사용할 수 있다. AL, BL, CL, DL, AH, BH, CH, DH는 REX 접두어 없이 사용할 수 있다.
    • 세그먼트 레지스터 (CS, DS, SS, ES, FS, and GS)
    • RFLAGS 레지스터
    • x87 FPU 레지스터 (ST0부터 ST7까지, 상태 워드, 제어 워드, 태그 워드, 데이터 피연산자 포인터, 명령 포인터)
    • MMX 레지스터 (MM0 through MM7)
    • XMM 레지스터 (XMM0 through XMM15) and the MXCSR register
    • 제어 레지스터 (CR0, CR2, CR3, CR4, and CR8) and system table pointer registers (GDTR, LDTR, IDTR, and task register)
    • 디버그 레지스터 (DR0, DR1, DR2, DR3, DR6, and DR7)
    • MSR 레지스터
    • RDX:RAX 레지스터 128 비트 피연산자를 나타내는 쌍

    3.7.3. 메모리 피연산자(Memory Operands)

    메모리에서 근원지(Source)와 목적지(Destination) 피연산자는 세그먼트 셀렉터와 오프셋을 통해 참조된다. (그림 3-9) 세그먼트 셀렉터는 피연산자를 포함하는 세그먼트를 지정한다. 오프셋은 피연산자의 선형 또는 유효 주소를 지정한다. 오프셋은 32 비트 (표기법 m16:32로 표시)나 16 비트(표기법 m16:16으로 표시)가 될 수 있다.

    3.7.3.1. 64 비트에서 메모리 피연산자(Memory Operands in 64-Bit Mode)

    64-비트 모드에서 메모리 피연산자는 세그먼트 셀렉터와 오프셋에 의해 참조될 수 있다. 오프셋은 16 비트, 32 비트 또는 64 비트일 수 있다. (그림 3-10)

    3.7.4. 세그먼트 셀렉터 지정(Specifying a Segment Selector)

    세그먼트 셀렉터는 명시적이나 묵시적으로 지정할 수 있다. 세그먼트 셀렉터 지정의 일반적인 방법은 세그먼트 레지스터에 로드한 다음 프로세서가 수행중인 작업 유형에 따라 묵시적으로 레지스터를 선택하도록 허용한다. 프로세서는 표 3-5에서 주어진 규칙에 따라 세그먼트를 자동으로 선택한다.

    메모리로부터 데이터를 로드하거나 메모리에 데이터를 저장할 때 DS 세그먼트 기본값은 다른 세그먼트에 접근될 수 있도록 무시할 수 있다. 어셈블러 내에서 세그먼트 재정의는 일반적으로 콜론 ":" 연산자로 처리된다. 예를 들어, 다음 MOV 명령은 EAX 레지스터에서 ES 레지스터가 가리키는 세그먼트로 값을 이동한다. 세그먼트의 오프셋은 EBX 레지스터에 포함된다.

    MOV ES:[EBX], EAX;

    기계 레벨에서 세그먼트 재정의는 세그먼트-재정의 접두어로 지정되며, 이는 명령의 시작 부분에 배치된 바이트다. 다음 기본 세그먼트 집합은 재정의 할 수 없다.

    • 명령 페치(fetch)는 코드 세그먼트에서 만들어야 한다.
    • 문자열 명령의 목적지 문자열은 ES 레지스터가 가리키는 데이터 세그먼트에 저장해야 한다.
    • push와 pop 동작은 SS 세그먼트를 참조해야 한다.

    일부 명령은 세그먼트 셀렉터를 명시적으로 지정되도록 요구한다. 이러한 경우 16-비트 세그먼트 셀렉터는 메모리 위치나 16-비트 레지스터에 위치할 수 있다. 예를 들어, 다음 MOV 명령은 레지스터 BX에 있는 세그먼트 셀렉터를 세그먼트 레지스터 DS로 이동한다.

    MOV DS, BX

    세그먼트 셀렉터는 메모리에 48-비트 원거리 포인터의 일부로 명시적으로 지정될 수도 있다. 여기서 메모리의 첫번째 더블 워드는 오프셋을 포함하고 다음 워드는 세그먼트 셀렉터를 포함한다.

    3.7.4.1. 64-비트 모드에서 세그먼테이션(Segmentation in 64-Bit Mode)

    IA-32e 모드에서 세그먼테화의 영향은 프로세서가 호환 모드 또는 64-비트 모드에서 실행되는지 여부에 따라 다르다. 호환 모드에서, 세그먼트화 기능은 기존 IA-32 모드와 동일하게 동작하며, 위에서 설명한 16-비트나 32-비트 보호 모드 의미를 사용한다.

    64-비트 모드에서 세그먼트화는 일반적으로 (하지만 완벽하진 않음)비활성화되고, 평면 64-비트 선형 주소 공간을 생성한다. 프로세서는 CS, DS, ES, SS의 세그먼트 기준을 0으로 처리하여 실효 주소와 동일한 선형 주소를 만든다. 예외적으로 FS와 GS 세그먼트가 있으며, 세그먼트 레지스터 (세그먼트 기준을 유지)는  일부 선형 주소 계산에서 추가 기본 레지스터로 사용될 수 있다.

    3.7.5. 오프셋 지정(Specifying an Offset)

    메모리 주소의 오프셋 부분은 정적인 값 (변위라 부름)으로 직접 지정하거나 다음 구성 요소 중 하나 이상의 방법으로 주소를 계산하여 지정할 수 있다.

    • 변위(Displacement) - 8-비트, 16-비트 또는 32-비트 값
    • 베이스(Base) - 범용 레지스터의 값
    • 인덱스(Index) - 범용 레지스터의 값
    • 축척 계수(Scale factor) - 인젝스 값을 곱한 2, 4 또는 8의 값

    이러한 구성 요소를 추가하여 생성한 오프셋을 실효 주소(Effective Address)라고 한다. 이들 각 구성 요소는 긍정과 부정 (2s complement) 값을 가질 수 있으며, scaling factor는 예외다. 그림 3-11은 이러한 구성 요소를 결합하여 선택한 세그먼트에서 유효한 주소를 생상하는 가능한 모든 방법을 보여준다.

    base 또는 index 구성 요소로서의 범용 레지스터의 사용은 다음과 같은 방식으로 한정된다.

    • ESP 레지스터는 인젝스 레지스터로 사용할 수 없다.
    • ESP 또는 EBP 레지스타가 base로 사용될 때, SS 세그먼트는 기본 세그먼트이다. 다른 모든 경우에 DS 세그먼트는 기본 세그먼트다.

    base, index 그리고 displacement 구성 요소는 어떤 조합으로도 사용될 수 있으며, 이러한 구성 요소 중 무언가는 NULL이 될 수 있다. scale factor는 index가 사용되는 경우에만 사용될 수 있다. 가능한 각 조합은 프로그래머가 고급 언어와 어셈블리 언어에서 일반적으로 사용하는 데이터 구조에 유용하다.

    다음 주소 배정 모드는 주소 구성 요소의 일반적인 조합에 대한 사용을 시사한다.

    • Displacement - displacement만이 피연산자에 대한 직접적인(계산되지 않은) 오프셋을 나타낸다. displacement가 명령에서 인코딩되므로, 이 주소 형태를 절대 주소 또는 정적 주소로 부른다. 일반적으로 정적으로 할당된 스칼라 피연산자(scalar operand)에 접근하는데 사용된다.
    • Base - base 만으로 피연산자에 대한 간접 오프셋을 나타낸다. 기본 레지스터의 값이 변경될 수 있으므로 변수와 데이터 구조의 동적 저장에 사용할 수 있다.
    • Base + Displacement - base 레지스터와 displacement를 두 가지 목적으로 함께 사용할 수 있다.
      - 요소 크기가 2, 4 또는 8 바이트가 아닌 경우 배열의 index—displacement 구성 요소는 정적 오프셋을 배열의 시작 부분으로 인코딩한다. base 레지스터는 배열의 특정 요소에 대한 오프셋을 결정하기 위해 계산 결과를 유지한다.
      - 레코드의 필드에 접근하는 것: base 레지스터는 레코드 시작의 주소를 보유하고, displacement는 필드에 대한 정적 오프셋이다.
      특별히 이 조합이 중요한 경우는 프로시저 활성화 레코드의 매개 변수에 대한 접근이다. 프로시저 활성화 레코드는 프로시저가 입력 될 때 생성되는 스택 프레임이다. 여기서, EBP 레지스터는 스택 세그먼트를 자동으로 선택하기에 base 레지스터에 가장 적합한 옵션이다. 이는 이러한 공통 기능을 위한 간결한 인코딩이다.
    • (Index ∗ Scale) + Displacement -  이 주소 모드는 요소 크기가 2, 4 또는 8 바이트일 때 정적 배열에 효율적으로 index할 수 있는 방법을 제공한다. displacement는 배열의 시작 부분을 찾고, 인덱스 레지스터는 원하는 배열 요소의 첨자를 유지하고, 프로세서는 scaling factor를 적용하여 첨자(subscript)를 idnex로 자동 변환한다.
    • Base + Index + Displacement - 두 개의 레지스터를 함께 사하는 것은 2 차원 배열 (displacement가 배열의 시작 주소를 유지함)이나 레코드 배열의 여러 인스턴스 중 하나(displacement는 내부 필드의 오프셋)를 지원한다.
    • Base + (Index ∗ Scale) + Displacement - 모든 주소 배정 구성 요소를 함께 사용하면 배열의 요소가 2, 4 또는 8 바이트 크기일 때 2차원 배열을 효율적으로 인덱싱하도록 허용한다.

    3.7.5.1. 64-비트 모드에서 오프셋 지정(Specifying an Offset in 64-Bit Mode)

    64 비트 모드에서 메모리 주소의 오프셋 부분은 다음 구성 요소 중 하나 이상으로 직접적으로 정적 값이나 주소 계산을 통해 구성되어 지정 될 수 있다.

    • Displacement - 8-비트, 16-비트 또는 32-비트 값
    • Base - 64-bit 범용 레지스터의 값
    • Index - 64-bit 범용 레지스터의 값
    • Scale factor - 인젝스 값을 곱한 2, 4 또는 8의 값

    대부분의 경우 16개의 사용 가능한 범용 레지스터 중 하나에서 인덱스 값을 지정할 수 있다. 자세한 정보는 Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 2A의 2장 "Instruction Format"을 참고한다.

    다음과 같은 고유한 주소 구성 요소 조합도 사용할 수 있다.

    • RIP + Displacement - 64-비트 모드에서 RIP-상대 주소 배정은 부호있는 32 비트 displacement를 사용하여 32-비트 값을 부호 확장하고 RIP에서 64-비트 값을 더하여 다음 명령의 실효 주소를 계산한다.

    3.7.6. 어셈블러와 컴파일러 주소 배정 모드(Assembler and Compiler Addressing Modes)

    기계 코드 레벨에서 displacement, base 레지스터, 인덱스 레지스터, scale factor의 선택된 조합이 명령어로 인코딩된다. 모든 어셈블러는 프로그래머가 이러한 주소 배정 구성 요소의 허용 가능한 조합을 허용하여 피연산자를 처리할 수 있다. 고급 언어 컴파일러는 프로그래머가 정의한 언어 구성에 따라 이러한 구성 요소의 적절한 조합을 선택한다.

    3.7.7. I/O 포트 주소 배정(I/O Port Addressing)

    프로세서는 최대 65,536개의 8-비트 I/O 포트를 포함하는 I/O 주소 공간을 지원한다. 16-비트와 32-비트 포트는 I/O 주소 공간에 정의될 수 있다. I/O 포트는 즉시 피연산자나 DX 레지스터의 값으로 주소가 배정될 수 있다. I/O 포트 주소 배정에 대한 자세한 내용은 18장 "Input/Output"을 참조한다.


    요즘 정말 빅데이터와 기계학습이 핫한 키워드죠. 방대한 데이터 속에서 날카롭게 중요한 정보를 찾아내고 가공할 수 있는 빅데이터 기술과, 그 데이터를 기계가 학습하여 사람의 수준으로 인지할 수 있는 영역까지, 더 나아가 새로운 영역까지 나아가려고 하고 있죠.

    보안에서는 이러한 데이터들을 구하기가 힘듭니다. 공격당하거나 침해당한 기업의 주요 정보가 포함될 수 있기에 민감하기 때문입니다. 하지만 다음과 같은 사이트도 존재합니다. 보안을 위해 데이터셋을 공유하는 사이트로 이미지를 클릭하면 해당 사이트로 이동할 수 있습니다.



    1. 2017.01.20 07:10

      비밀댓글입니다

    + Recent posts