code toolbox

보안 제품의 기능 확장·웹 보안과 결합 지속

컴퓨터를 사용하는 사람들은 누구나 한 번쯤은 바이러스에 걸려서 고생을 하거나 애드웨어 때문에 원하지 않는 광고 창을 닫느라 땀을 흘린 경험을 가지고 있다. 또 스파이웨어는 사용자가 알아차리지 못하게 정보를 빼돌린다. 이러한 악성코드는 나름대로 각각 ‘성격’을 가지고 있다. 이 ‘성격’은 탄생 초기에는 어설펐지만 수많은 운영체제와 사용자 환경을 겪으면서 ‘진화’해 가고 있는 것이다.

단, 스파이웨어는 사용자가 알아차리지 못하게 정보를 빼돌리고 있었으니 눈에 띄는 직접적인 피해나 번거로움은 없었을지도 모르지만, 쇼핑 사이트나 이동통신 사이트의 사용자 정보 유출 뉴스를 듣고 나면 며칠 후부터 메일과 SMS를 통하여 증가하는 스팸과 광고에 짜증내 본 기억도 떠오를 것이다. 

사용자를 불편하게 하고 정보를 빼내려는 이러한 악성코드가 사라진다면 얼마나 좋을까? 하지만 마치 사회에서 도둑이나 강도가 없길 바라지만 사라지지 않듯이, 운영체제를 만드는 마이크로소프트가 ‘신뢰할 수 있는 컴퓨팅’을 내세우며 보안을 강화해 나가더라도 악성코드는 줄어들지 않고 더욱 교묘하고 은밀하게 정보를 빼내가려고 하고 있다. 도둑이나 강도가 없는 세상은 사람들이 모두가 천사가 되는 영화나 소설 속에서나 가능할 것 같다. 

영화나 소설과 같은 이야기가 나왔으니 이어서 비유를 해보자면 베트맨에 나오는 악역인 조커의 캐릭터처럼 악성코드도 ‘성격’을 가지고 있다. 그리고 이 ‘성격’은 탄생 초기에는 어설펐지만 수많은 운영체제와 사용자 환경을 겪으면서 ‘진화’해 가고 있다. 사실, 운영체제가 점점 더 거대해지고 많은 기능을 제공하면서 악성코드가 가질 수 있는 ‘성격’은 점점 더 다양해지고 있는 현실이다. 

그렇다면 최근에 등장하는(또는 등장한 걸 모를 수도 있는) 악성코드들은 어떤 ‘성격’을 가지고 있을까? 악성코드의 미래를 이야기하기 전에 이들의 성장과정인 필모그라피(filmography)를 먼저 아는 것이 도움이 될 것이다.

악성코드, 점점 자신을 숨기다

초기의 악성코드들은 순진한 ‘성격’을 가지고 있었다. 바이러스에 감염되면 벽에 낙서를 하듯이 “아무개 여기 다녀가다”라는 식으로 표시를 하거나 프로그램 내부에 특정한 문자열을 심어서 자신의 사인으로 남기기도 했다. 그냥 어디엔가 자신의 이름이 나온다는 것이 재미있는 그런 호기심 많은 사춘기와 같은 시기였을 테니까. 

그렇게 얌전했던 성격은 1990년대 후반에 들어서면서부터 심각하게 삐뚤어지기 시작했는데, 컴퓨터 운영 체제가 도스(DOS)를 사용하던 것에서 윈도우(Windows) 형태로 바뀌면서부터 더 악동 같은 짓을 하게 되었다. 왜냐하면 윈도우 환경은 집에서 혼자 장난감을 가지고 놀다가 동네 놀이터에 나가서 놀게 되는 것처럼 더 넓고, 더 다양하고, 더 많은(사실 이것이 중요하다! 공격할 수 있는 대상이 무지막지하게 늘어났으니!) 환경을 제공해 주었다. 그뿐만 아니라 인터넷의 대중화는 이러한 놀이터를 연결해서 놀이 동산에 입장한 것처럼 사람들을 쉽게 연결할 수 있게 되었고 악성코드를 만들어서 시험해볼 수 있는 좋은 놀이터를 제공하게 되었기 때문이다. 

그럼 악성코드는 왜 놀이터를 헤집고 다니게 되었을까? 아이러니컬하게도 악성코드를 만들기 쉬워진 것은 GUI(Graphic User Interface)를 제공하는 운영 체제와 Visual C 등으로 편리해진 프로그래밍 덕분이다. 왜냐하면 악성코드도 사용자가 의도하지 않은, 하지만 그 프로그램을 만든 누군가가 원하는 무엇인가를 수행하는 하나의 소프트웨어이기 때문이다. 

악성코드들이 순진함에서 점점 삐뚤어진 성격을 가지게 되면서 좀 더 강렬하고 자극적이고 치명적인 모습으로 진화해가기 시작했다. 왜냐하면 보안 회사들의 방어 능력도 점점 좋아지고 빨라졌고 운영 체제를 만들던 마이크로소프트도 자사 운영 체제의 취약점을 보완하기 위해서 많은 노력과 투자를 하기 시작했기 때문이다.

쉽게 이야기하면 초기에 지은 집들은 방범이 허술해서 도둑이 쉽게 들어올 수 있었지만, 경비원을 두고 주인이 직접 문을 점검하고 다니니 악성코드들은 문을 열고 들어오기 위해서 더 힘들게 고생을 해야 했다. 마치 영화 ‘미션 임파서블’에서 컴퓨터에 접근하기 위해서 줄을 타고 내려와서 대롱대롱 힘들게 매달려 있어야 했던 것처럼 말이다.

악성코드, 당신의 안방을 노리다

위에서 간단하게 살펴본 것처럼 악성코드들은 점점 지능적으로 변해갔다. 들키지 않고 오래 남아 있어야 하고 사용자 몰래 무엇인가를 해야 하기 때문이다. 더 강화된 방범 시스템을 피하기 위해서 더욱 높은 수준의 변장과 다양한 침투 도구들이 필요하게 되었다. 사용자들도 한 두 번쯤은 악성코드에 당하게 되면서 인식이 높아졌기 때문에 악성코드를 쉽게 만들어서 마구 뿌릴 수 있던 그런 시절은 지나가버렸다. 

무척 힘들게 집에 침입한 도둑이 그냥 벽에 낙서만 하고 돌아설까? 그냥 가기엔 도둑 입장에서 무언가 허전하고 아쉽고 바보 같은 느낌이 든다. 그렇다. 힘들게 집에 들어갔으니 돈이 될만한 무엇인가를 좀 들고 나가야겠다. 사실 악성코드를 만들 수 있는 정도의 수준이면 사용자의 컴퓨터에서 무엇인가를 집어 나가는 것은 어려운 일도 아니다.(만들어진 것을 이용하는 사용자와 그것을 만들어주는 개발자의 차이란 참으로 크지 않던가?) 

그래서 처음에는 그 집에 있는 돈이 될만한 정보들을 들고 나가기 시작했다. 대표적으로 사용자의 개인 정보를 노리기 시작했고 사용자에게 광고를 보여주고 돈을 벌어보기도 했다. 그 다음에는 사용자의 금융 정보, 그리고 나중에는 사용자의 데이터 파일까지 내보내기 시작했다.(이쯤 되면 악성코드의 성격이 참 많이 빗나가고 있다.)

악성코드, 크게 한 방을 노리다

보안 소프트웨어의 방어 노력과 사용자의 높아진 경각심으로 인하여 악성코드들은 새로운 방법을 모색하기 시작했는데 그것은 바로 눈에 띄지 않게 더 숨어버리는 것이었다. 처음부터 들어가서 노골적으로 무엇인가를 가져가려고 하니 잘 들키게 되어서, 이젠 몰래 들어간 후에, 훗날을 기약하는 원격 조정 폭탄(?)을 조심스럽게 심어놓는 것이다. 

악성코드가 사용자의 PC를 조금씩 조금씩 장악해 나가면서 자신만의 꿈을 키워 나갔는데 그것은 바로 사용자 PC에 심어놓은 원격 조정 폭탄들을 동원하여서 한 탕 크게 하는 것이다. 말하자면 은행강도 정도로 크게 한탕하고 도망가는 것이라고 할까? 힘들게 한 탕을 하려니 개인 사용자 수준의 정보로는 부족하고 기업이나 기관의 큰 데이터베이스를 노리거나, 공격에 대한 예고를 통해 돈을 요구하는 형태로 발전하게 되었다. 지금도 특정 사이트를 공격하는 D-day가 되면, 많은 개인 사용자 PC들이 사용자도 모르게 좀비가 되어서 공격에 동원되는지 알 수 없을 정도이다. 

여기까지 오게 되면 순진하게 시작되었던 악성코드의 성격은 수많은 좀비를 앞세운 무장강도 수준으로 삐뚤어진 성격이 되어버린 것이라고 할 수 있겠다. 지금은 악성코드들이 사용자의 PC를 원격으로 조정하기 위하여 영화 ‘마이너리티 리포트’에 나오는 작은 스파이 로봇들을 뿌리는 것처럼 작지만 알아차리기 힘든 에이전트들을 몰래 몰래 뿌리고 있는 중이다. 언제, 어느 사이트를 공격할지는 알지 못하는 채로.

악성코드의 유비쿼터스 시대; 언제 어디서나, 보이지 않게

그렇다면 앞으로 시간이 좀 더 흐르고 나면 이러한 악성코드들을 싹 없애버릴 수 있을까? 안타깝게도 대답은 ‘아니다’이다. 오히려 악성코드들이 활약할 수 있는 분야는 더 다양해지고 있다. 사람들이 PC뿐만이 아니라 노트북을 사용하고(사실 노트북은 PC랑 운영 체제 기반과 환경이 거의 같다), 핸드폰, MP3P, PDA, PMP, PDP, 내비게이션 등 무수히 많은 디지털 기기를 사용하고 있다. 

사용자들은 앞으로 더 많은 개인화한 디지털 기기들을 이용하게 될 텐데, 이들은 모두 운영 체제를 가지고 있고 또 그 취약점을 가지고 있다. 하드웨어 제품을 만드는 회사와 종류는 다를지 몰라도 운영 체제는 마이크로소프트가 거의 독과점을 하고 있는 상황에서 악성코드들에게는 더 다양한 놀이터를 제공하는 것일지도 모른다. 

사실, 개인화한 기기뿐만 아니라 홈 네트워크가 더 많이 보급되고 가정의 가전 제품들도 급속히 네트워크화한다면 냉장고가 악성코드에 감염되어서 문을 열어 주지 않거나, 반찬을 녹여 버리거나, 냉각기를 세워서 냉장고 앞을 흥건하게 적셔놓을지도 모르는 일이다. 디지털 도어 락이 입력을 거부하거나 디지털 텔레비전이 마음대로 온라인 주문을 하지 않을 거라고 제조업체가 보장할 수 있을까?

악성코드와 보안 제품의 가상화

GUI 환경을 통해 사용자들에게 편리한 환경을 제공했듯이(물론 악성코드에게도 편리한 환경), 최근에는 가상화 환경을 통해 시스템을 절약하고 한정된 자원으로 더 많은 일들을 할 수 있도록 해주는 노력들이 이어지고 있다. 가상화를 통해 구현되는 환경은 사용자 입장에서는 큰 차이를 느끼지 못할 수도 있지만, 시스템의 활용성을 더 높이고 돈을 더 많이 들이지 않아도 된다는 점에서 매우 매력적인 환경이 될 것이다. 

그런데 사용자에게 편리한 환경은 악성코드에게도 편리한 환경이 될 수 있다는 점에서 편리함과 보안성은 동전의 양면과 같은 성격을 가지고 있다. 악성코드가 가상화 환경에서 존재한다면 쉽게 폐기할 수 있을 것이라고 생각할 수도 있지만 가상화 환경에 숨어들어가서 더 찾기 힘들고 치료하기 어려워질 수도 있다. 가상화가 점점 실용적으로 이용될수록 우리가 이제까지 경험하지 못한 새로운 악성코드의 패턴이 등장할 것이라 예상할 수 있다. 

그렇다면 사이버 세상의 미래는 헐리우드식 영화들이 보여주는 것처럼 암울하고 비관적이기만 한 것일까? 아니면 아시아권의 영화들이 보여주는 것처럼 인간적이고 자연적인 모습을 기대할 수 있는 것일까? 

이에 대한 한 가지 답으로 안티바이러스 및 통합보안 제품의 가상화 기술을 제시할 수 있다. 가상화는 이미 1960년대에 시작된, 생각보다 오래 묵은 기술이다. 오래된 만큼 기술적으로 성숙되어 있고 가상화 개념이 적용된 분야 또한 광범위하다. 보안 업계에서도 이미 오래 전부터 화두였다. 가상화 기술을 도입한 서버, 네트워크 등 여러 가지 솔루션의 등장으로 그 취약점 또한 점점 늘고 있다. 가상화 기술을 확보하지 않고서는 이를 위한 보안 제품도 만들 수 없으며 악성코드는 이 점을 노릴 것이다. 이에 대비하기 위해 안철수연구소를 비롯한 보안 업체는 어느 때보다 기술 확보에 노력하고 있다. 

안티바이러스 분야에서 현재 가장 많이 적용된 가상화 기술은 에뮬레이티드 머신(Emulated Machine) 또는 샌드박스 머신(Sandbox Machine)을 이용한 악성코드 분석 기법이다. 이것들은 각각 나름의 가상화 방법을 가지고 구현되어 있다. 또한 이를 통한 자동 분석 시스템 또한 각광을 받고 있다. 엄청나게 폭주하고 있는 악성코드 샘플을 효과적으로 처리하고 늘어만 가는 악성코드를 효과적으로 처리하기 위해 가상화 기술에서 방법을 찾고 있다. 

현재 안철수연구소는 악성코드 샘플 처리 자동화 시스템에 Light-weight Virtualized Environment 기술을 적용하고 있다. 이 기술은 엔진의 진단율을 높이는 데도 적용하고 있다. 또한 제너릭 디텍션(Generic Detection), 휴리스틱 디텍션(Heuristic Detection), 프로액티브 프리벤션(Proactive Prevention) 등의 기법을 테스트하고 있다. 이런 기술로 악성코드에 더 효과적으로 대응할 수 있으며 더 많은 악성코드를 차단할 수 있다.

통합보안 제품, 더 가볍고 더 빨라지다

한편, 백신 및 통합보안 제품의 변화 추세를 보자면 급변하는 인터넷 환경과 고객의 요구에 대응하며 포인트 솔루션에서 토털 솔루션으로, 다시 웹 2.0 기술을 접목한 서비스 형태로 지속적인 진화를 하고 있다. 단순 안티바이러스 툴을 넘어 사용자의 PC 사용을 더욱 안전하고 편하게 하는 방향으로 변화를 거듭하고 있는 것이다. 특히 최근 통합보안 제품의 변화를 주도하는 방향은 크게 ‘경량화와 가속화’, ‘케어 영역의 확대’로 나누어볼 수 있다. 

인터넷의 급속한 성장과, PC와 PC가 네트워킹된 상황에서 악성코드의 유포 채널이 미디어를 통한 수동적인 방법에서 사이트를 통한 능동적인 방향으로 바뀌어 가고 있다. 그에 따라 악성코드가 기하급수적으로 늘어나고 있다. 이에 대한 대응으로 통합보안 제품이 진단하는 악성코드 DB도 1년에 2배 정도씩 늘어나고 있다.  

최근 PC를 사용하는 주된 목적은 인터넷 쇼핑이나 뱅킹, 동영상, 게임 등 금융과 엔터테인먼트로 집중되고 있다. 이에 따라 운영체제나 타 프로그램 때문에 PC 작동이 끊기거나 지연되는 일이 없기를 바라는 요구가 증가하고 있다.
 

이와 같이 PC 사용의 목적 및 패턴이 변화함에 따라 통합보안 제품에 대한 요구가 기능 중심에서 PC 사용에 미치는 영향을 최소화하는 경량화로 이동하고 있다. 악성코드가 증가함에 따라 통합보안 제품 엔진의 크기가 커지므로 경량화에 대한 요구가 지속적으로 확대될 것으로 보인다. 보안 업체는 엔진 파일 크기의 증가를 최소화하고 행위 기반, 가상화 등의 기술을 접목하는 한편, 파일/프로세스 검사 시 파일 I/O(Input/Output), CPU 사용량을 최소화하기 위한 다양한 방법을 찾고 있다. 

지난해 안철수연구소가 출시한 ‘V3 365 클리닉 2.0’의 경우가 최근 통합보안 제품 업계의 경량화 트렌드를 가장 먼저 반영, 시장에 선보인 예로 들 수 있다. 공통 요소의 모듈화, 최적화를 통해 CPU, 메모리 등 주요 리소스의 사용을 최소화했다. 이로써 용량은 1/10로 줄어들고, 실행과 검사 속도가 이전 버전과 비교해 2-3배 빨라졌다. 특히 메모리 점유율을 개선하여 실시간 감시 중에도 속도 저하를 전혀 느낄 수 없는 수준으로 개선하였다. 

시만텍의 노턴 2009의 경우도 시스템 리소스에 대한 부하를 줄이는 데 초점을 맞춰 통합보안 제품 가동에 따른 PC 속도 저하 문제를 줄이는 데 중점을 두었다고 강조하고 있다. 실질적으로 300MB가 넘는 용량이 100MB로 크게 줄어들었으며 검사 속도 또한 확연히 줄어들었다고 시만텍 측은 설명하고 있다. 

이러한 통합보안 제품의 ‘Lighter and Faster’의 추구는 실시간 감시만 켜두면 버벅거리는 PC 때문에, 그리고 두세 시간의 시스템 검사 시간 때문에 답답해하던 사용자들에게 ‘보안이냐 편리함이냐’란 딜레마를 훌훌 털어버리게 할 수 있는 반가운 성과라고 할 수 있다.

단순 백신을 넘어 토털 PC 케어로

사람들은 컴퓨터를 사용하면서 늘 궁금하고 답답하다. ‘늘 내 PC는 느린 것 같아’, ‘왜 나만 하면 인터넷이 이렇게 느려지지?’ PC에서 발생하는 문제의 원인은 매우 다양하다. 그 해결 방법 또한 원인만큼 복잡하고 다양하다. 하지만 그 원인을 알고 해결할 수 있는 파워유저보다 일반 초보 유저가 절대적으로 많아지고 있다. 단순히 백신 고유의 기능인 악성코드 치료만으로는 ‘편리하고 안전한 PC의 사용’에 어려움을 겪는 사용자가 대부분이라는 것이다. 

이에 보안 업체의 고민이 있고 여기서 통합보안, 토털 케어로의 미래를 엿볼 수 있다. 물론 현재도 레지스트리, 디스크 등 리소스에 대한 최적화, 드라이버 업데이트 등으로 기능 확장을 해 나가고 있으나 아직은 운영체제에서 제공해 주는 기능의 확장에 머물러 있다. 

향후 보안 업계는 이와 같은 기능 확장과 웹 보안과의 결합이 지속적으로 이루어질 것으로 보인다. 백신이 초기 의료 체계를 모델링해서 나왔듯이 지속적인 모니터링과 관리를 받을 수 있는 서비스 형태로 진화할 것으로 전망된다. 또한 PC에 문제가 있을 때 사용자가 조치하는 수동적인 방법에서 자체적으로 판단하고 능동적으로 대응하는 형태의 ‘능동형 서비스’로 발전해 나갈 것으로 보인다.

도전과 응전은 계속된다

자동차를 타는 사람들이 처음에는 사고에 대응하지 못했지만 점차 안전벨트를 메고, 에어백을 달고, 후진 센서를 달고 하는 식으로 안전에 대한 노력을 해 온 것처럼, 우리가 생각할 수 있는 미래는 지금보다 더 편리한 환경을 제공할 것이다. 

마찬가지로 악성코드가 사라지지 않을 것이 자명하지만, 또 분명한 것은 악성코드들을 막기 위한 인간의 노력은 더 많은 발전을 이룰 것이고, 보안을 전문적으로 연구하는 좋은 기업들의 노력이 빛을 발할 것이라는 점이다. 

악성코드가 들어오는 방법, 악성코드가 숨어 있는 것을 찾는 방법, 악성코드가 최종적으로 노리는 목표를 찾아내고 위험을 제거하기 위한 기술 등 실질적인 방어를 위한 연구를 쉬지 않고 고민하고 찾아내고 있는 전문가들이 있기 때문이다. 그리고 인류의 역사는 끊임없는 공격과 방어에 대한 연구에서 발전하여 왔고 그러한 노력을 통하여 더 살기 좋은 세상을 만들어 왔기 때문이다. 

2. 파일기반의 탐지 기법(File Base Detection Tech)

현재까지 알려진 안티 바이러스(Anti-Virus) 소프트웨어 대부분이 파일 기반(File Base)의 진단법을 사용하고 있다. 이는 대부분의 악성 코드가 특정 운영체제에서 실행되기 위해서는 해당 운영체제에서 실행이 가능한 특정한 파일 형태로 되어 있다는 점에서 기인한 것이다. 그러므로 악성 코드가 윈도우 시스템(Windows System)에서 실행되기 위해서는 윈도우 시스템에서 실행 가능한 파일 포맷인 PE(Portable Executable) 형식을 가지고 있어야 된다는 것이다.


[그림 3] PE(Portable Executable) 형식의 악성 코드 파일

이러한 PE(Portable Executable) 형식의 악성 코드를 진단하기 위해서는 안티 바이러스(Anti-Virus) 소프트웨어 역시 이러한 파일 형식을 인식하고 악성 코드로 판단을 내릴 수 있는 특정 형식의 시그니처(Signature)를 가지고 있어야 된다. 이러한 진단법이 대부분의 안티 바이러스(Anti-Virus) 소프트웨어가 사용하는 시그니처 기반(Signature Base) 또는 스트링(String – 여기서 말하는 스트링이란 일반적인 문자열이 아닌 파일의 헥사코드(Hex Code)를 의미하는 것이다.) 검사 방식이라고 이야기하는 진단법이다. 이러한 시그니처 기반(Signature Base)의 진단법은 악성 코드로 분류된 파일의 특정 부분 또는 고유한 부분을 검사의 대상으로 삼으므로 오탐(False Positive)과 미탐(False Negative)을 최소화하는 정확한 진단이 가능하다는 것과 파일 검사 시에 파일들의 특징적인 부분들만 비교 함으로 빠른 스캐닝(Scanning)을 장점으로 들 수 있다.

그러나 이러한 시그니처 기반(Signature Base) 진단법은 악성 코드의 파일 자체가 몇 백 바이트(Byte)만 바뀌어도 진단이 되지 않는 미탐(False Negative)이 발생함으로 파일이 조금만 변경된 새로운 변형에 대해서는 대응을 할 수가 없게 된다. 그리고 기존에 알려진 악성 코드에 대해서만 대응을 할 수 있으므로 새로운 형태의 알려지지 않은 악성 코드에 대해서는 대응을 할 수 없다는 단점을 가지고 있다.

1) 휴리스틱 탐지 기법 (Heuristic Detection Tech)

이러한 시그니처 기반(Signature Base)의 진단법이 가지고 있는 한계를 극복하고자 개발한 탐지 기법 중 하나가 휴리스틱 탐지(Heuristic Detection) 기법이다. 휴리스틱 탐지(Heuristic Detection) 기법은 일반적인 악성 코드가 가지고 있는 특정 폴더에 파일 쓰기와 특정 레지스트리 부분에 키 생성과 같은 명령어(Instruction)들을 스캐닝 엔진(Scanning Engine)에서 시그니처(Signature)화하여 파일을 검사할 때 이를 사용한다. 그래서 검사 대상 파일이 휴리스틱 시그니처(Heuristic Signature - 이 것을 부스터(Booster)라고도 한다.)와 비교를 통하여 일반적으로 알려진 악성 코드와 얼마나 높은 유사도를 가지고 있는지를 판단하여 알려지지 않은 새로운 악성 코드를 탐지하는 기법이다.
이러한 휴리스틱 탐지(Heuristic Detection) 기법은 검사 대상이 되는 파일에 대해서 휴리스틱(Heuristic) 검사 시에 스캐닝 엔진(Scanning Engine)이 어떠한 형태를 취하는가 에 따라서 아래와 같이 크게 2가지 형태로 나누어서 볼 수 있다.

- 동적 휴리스틱 탐지 기법 (Dynamic Heuristic Detection Tech)
동적 휴리스틱 탐지(Dynamic Heuristic Detection) 기법은 검사 대상이 되는 파일을 가상화된 영역 또는 운영체제와 분리된 특정 공간에서 파일 실행(File Execution)을 통해 수집한 다양한 정보들을 휴리스틱 시그니처(Heuristic Signature)와 비교를 통하여 검사를 수행하는 기법이다. 즉 검사 대상이 되는 파일이 어떠한 형식으로든 실행이 되어야 하며 이러한 점으로 인해 런 타임 휴리스틱 탐지 (Run-Time Heuristic Detection) 기법이라고도 불리고 있다. 이러한 동적 휴리스틱 탐지(Dynamic Heuristic Detection) 기법은 이 후에 다룰 에뮬레이터(Emulator)과 샌드박스(Sandbox)에서 조금 더 자세하게 알아 보도록 하자.

- 정적 휴리스틱 탐지 기법 (Static Heuristic Detection Tech)
정적 휴리스틱 탐지(Static Heuristic Detection) 기법은 동적 휴리스틱 탐지(Dynamic Heuristic Detection) 기법과는 반대로 파일에 대해서 어떠한 형식의 파일 실행(File Execution) 없이 파일 자체를 그대로 스캐닝 엔진(Scanning Engine)에서 읽어 들여 휴리스틱 시그니처(Heuristic Signature)와 비교를 수행하는 탐지 기법이다.


[그림 4] 정적 휴리스틱(Static Heuristic)과 동적 휴리스틱(Dynamic Heuristic)

이 외에도 네거티브 휴리스틱(Negative Heuristic – 이 것을 스토퍼(Stopper)라고도 한다.)탐지 기법도 있다. 이는 이제까지 기술한 휴리스틱 탐지(Heuristic Detection) 기법과는 반대로 악성 코드에서 전형 사용하지 않은 윈도우 팝업 창 생성과 같은 명령어(Instruction)들이 존재 할 경우에는 악성 코드로 판단하지 않는 기법이다. 즉, 휴리스틱 시그니처(Heuristic Signature)와 동일한 명령어들이 존재하지 않는 부정의 경우에만 악성 코드로 판단한다.
이러한 형태들의 휴리스틱 탐지(Heuristic Detection) 기법은 기존에 알려진 악성 코드도 탐지가 가능하며 알려지지 않은 새로운 악성 코드 역시 탐지가 가능하다는 점에서 매력적인 탐지기법이라고 할 수 있다. 그러나 이 탐지 기법은 정상 파일을 악성 코드라고 판단하게 되는 오탐(False Positive)의 발생이 가장 큰 단점으로 작용한다. 특히나 파일을 삭제하고 치료하는 안티 바이러스(Anti-Virus) 소프트웨어의 특성상 오탐(False Positive)율이 높게 된다면 컴퓨터 시스템 자체에 큰 문제를 유발할 수 있게 됨으로 이는 치명적인 문제점이라고 볼 수 있다.

2) 제너릭 탐지 기법 (Generic Detection Tech)

앞서 설명한 휴리스틱 탐지(Heuristic Detection) 기법 외에도 알려지지 않은 악성 코드를 탐지하기 위한 기법 중에는 제너릭 탐지(Generic Detection) 기법이라는 것이 있다. 이 탐지 기법은 유사한 형태의 악성 코드 집합을 탐지하기 위해 해당 집합을 이루는 악성 코드 파일들의 공통된 코드 영역(Code Section)을 진단하도록 한다. 그러므로 소스 코드(Source Code)상에서 사용자 코드(User Code)의 변화가 없거나 약간의 수정만 가하여 컴파일(Compile)만 새롭게 하여 생성한 새로운 악성 코드 변형들에 대해 탐지가 가능함으로 유사한 형태의 악성 코드 변형들이 지속적으로 제작되더라도 시그니처(Signature) 업데이트 없이 탐지가 가능하다는 장점이 있다.

이러한 제너릭 탐지(Generic Detection) 기법에서는 일반적으로 파일에 대한 OPcode(Operation Code) 명령어 비교 방식이 많이 사용되고 있다. 이 OPcode(Operation Code) 명령어 비교 방식에는 크게 와일드카드 비교(Wildcard Matching – Don’t Care 비교라고도 한다)와 미스매칭(Mismatching) 방식으로 나누어진다. 먼저 와일드카드 비교(Wildcard Matching)는 유사한 형태의 악성 코드 변형들의 특정 코드 영역(Code Section)에서 사용되는 OPcode(Operation Code) 명령들이 조금씩만 다르고 동일할 경우 해당 다른 OPcode(Operation Code) 명령어 부분에 와일드카드를 적용하여 다른 OPcode(Operation Code) 명령어가 사용되어도 이를 무시하겠다는 것이다.


[그림 5] 메모장(Notepad.exe) 프로그램의 OPcode(Operation Code) 명령어들

[그림 5]를 예로 들어 메모장 프로그램을 원본 악성 코드라고 가정을 한다면 이 원본 악성 코드의 일부 OPcode(Operation Code) 명령어들은 [그림 5]의 붉은색 박스 영역의 순서대로 진행된다. 이렇게 PUSH, PUSH, PUSH, PUSH 순서로 진행되는 OPcode(Operation Code) 명령어들이 다른 악성 코드 변형들에서는 PUSH, PUSH, PUSH, MOV가 사용된다면 마지막 MOV 부분을 와일드카드(Wildcard)로 적용하여 마지막 4번째 OPcode(Operation Code) 명령은 어떠한 것이 사용되더라도 이에 구애 받지 않겠다는 것이다. 이렇게 적용하게 되면 원본 악성 코드와 변형 악성 코드의 전체 OPcode(Operation Code) 명령어 진행 순서는 유사한데 일부가 조금 틀리더라도 모두 진단하게 되는 효과를 구현할 수가 있다. 그러나 미스매칭(Mismatching) 방식은 와일드카드 비교(Wildcard Matching)와는 반대로 MMX(Multi Media eXtension) 명령어 또는 FPU(Floating Point Unit) 명령어와 같이 악성 코드에서 잘 사용되지 않는 명령어들이 [그림 5]의 해당 붉은색 박스영역과 같이 특정 부분에 사용 될 경우, 해당 파일을 악성 코드 변형으로 판단하지 않겠다는 것이다. 이런 미스매칭(Mismatching) 방식은 앞서 설명한 네거티브 휴리스틱(Negative Heuristic) 탐지 기법과 기본적인 개념은 동일하다고 볼 수 있다.

그러나 이러한 제너릭 탐지(Generic Detection) 기법은 악성 코드의 공통된 코드 영역을 진단함으로 새로운 악성 코드 변형들이 제작되더라도 탐지가 가능하다는 장점이 있지만 새로운 악성 코드 변형들이 완전히 새로운 OPcode(Operation Code) 명령어 순서로 진행된다던가 아니면 안티 디버깅(Anti-Debugging)과 암호화(Encryption) 등과 같이 실행 파일 보호 기법을 통해 OPcode(Operation Code) 명령어의 진행 순서를 뒤섞어 놓게 된다면 스캐닝 엔진(Scanning Engine)에서는 이를 탐지하지 못하게 되는 문제가 발생할 수가 있다.

이상으로 파일을 기반으로 알려지지 않은 악성 코드 탐지 기법들에 대해서 알아 보았다. 다음으로는 파일 실행을 통해서 탐지하는 동적 휴리스틱 탐지(Dynamic Heuristic Detection) 기법 설명 시에 잠시 언급한 에뮬레이터(Emulator)와 샌드박스(Sandbox)에 대해서 알아보도록 하자.[Ahn]

[저자] 안철수연구소 ASEC 장영준 주임연구원 

3. 에뮬레이터(Emulator)과 샌드박스(Sandbox)

앞 장에서 설명한 새로운 악성 코드 탐지기법들은 모두 실행 파일(Executable File) 자체를 대상으로 한 탐지 기법들이다. 그러나 이번 장에서 설명하는 에뮬레이터(Emulator)와 샌드박스(Sandbox)는 모두 실행 파일(Executable File) 자체에 관한 탐지 기법이 아니라 해당 실행 파일(Executable File)의 실행을 통해 수집한 정보들을 이용하여 새로운 악성 코드를 탐지하는 기법들이다. 그러므로 앞서 이야기한 바와 같이 실행 파일(Executable File)의 실행을 통하여 새로운 악성 코드를 탐지하는 동적 휴리스틱 탐지(Dynamic Heuristic Detection) 기법과도 상당히 밀접한 연관 관계를 가지고 있는 것이다.

1) 에뮬레이터(Emulator)

사전적인 의미에서 에뮬레이터(Emulator)는 대리 실행기 라는 의미를 가지고 있다. 대리 실행기 라는 의미에서와 같이 에뮬레이터(Emulator)는 실제 컴퓨터 시스템 상에서 실행 파일(Executable File)을 직접적으로 실행하는 것이 아니라 실제 컴퓨터 시스템에 가상(Virtual)의 환경이나 가상의 하드웨어(Hardware) 이미지를 생성하여 해당 가상 하드웨어(Hardware)를 통하여 간접적으로 실행하는 것을 의미한다. 이러한 의미로 인해 일부에서는 에뮬레이터(Emulator)를 이용한 탐지 기법을 코드 에뮬레이션(Code Emulation) 또는 CPU 에뮬레이션(CPU Emulation) 이라고도 이야기 한다.

이 탐지 기법은 실제 컴퓨터 상에서 스캐닝 엔진(Scanning Engine)이 검사를 수행하지만 컴퓨터 시스템 내부에 가상의 CPU와 메모리 등의 가상의 환경을 제공하여 실행 파일(Executable File)을 실행하고 정보를 수집함으로 실제 컴퓨터 시스템에서는 악성 코드로 인한 어떠한 감염 피해도 발생하지 않는다. 이러한 점으로 인해 알려지지 않은 악성 코드를 탐지하기 위한 부분에서는 상당히 강력한 방법이라고 할 수 있다.
이러한 가상의 환경을 이용하는 에뮬레이터(Emulator)가 컴퓨터 시스템에서 구현되기 위해서는 크게 다음과 같은 4가지가 포함 되어야 한다.

- 가상 CPU 환경
실행 파일을 실제 CPU를 이용한 연산과 동일하게 처리하기 위해 일반적인 모든 명령어들뿐만이 아니라 MMX(Multi Media eXtension) 명령어와 FPU(Floating Point Unit) 명령어까지도 모두 처리 할 수가 있어야 한다.

- 가상 메모리 환경
32비트(Bit) 주소 체계에서는 최고 4 기가바이트(GB)까지 확장이 가능하지만 가상의 메모리 환경에서는 이렇게 많은 메모리는 필요하지 않다. 다만, 실행 파일(Executable File)이 실행되었을 때 변경하는 메모리 주소들에 대해 모두 기록하고 이를 추적할 수 있어야 하며 논리적인 메모리 주소와 물리적인 메모리 주소들을 모두 제공할 수 있어야 한다.

- 가상 저장 장치 환경
물리적인 저장 장치와 동일하게 실행 파일(Executable File) 실행 시 발생하는 저장 장치에 대한 파일 읽기 및 쓰기처럼 저장 장치에 대한 I/O(Input/Output)가 발생할 때 에뮬레이터(Emulator)에서는 실제 하드웨어와 동일한 환경을 제공 할 수 있어야 한다.

- 에뮬레이션 제어기(Emulation Controller)
에뮬레이션 제어기(Emulation Controller)는 에뮬레이터(Emulator)에서 가장 핵심이 되는 부분이다. 실행 파일(Executable File)이 가상 환경에서 실행 시 악성 코드로 판단 할 수 있을 정도의 충분한 정보를 수집하고 이를 제어하는 것이 바로 에뮬레이션 제어기(Emulation Controller)이기 대문이다. 그래서 에뮬레이션 제어기(Emulation Controller)에서는 실행 중인 악성 코드를 어느 시점에서 실행을 중단할 것인가와 얼마 정도의 시간을 실행에 소비할 것인가를 판단하고 제어할 수 있어야 한다. 일반적으로는 인텔 X86 CPU에서 에뮬레이션(Emulation)을 수행 하기 위해서는 최소 1,000개에서 최대 30,000개의 CPU 명령어 수행과 함께 45초 정도의 시간 소요를 기본으로 설정 한다.

이렇게 가상의 환경에서 실행 파일(Executable File)을 실행하고 수집된 실행 결과들을 통해서 악성 코드로 판단하는 에뮬레이터(Emulator)는 실제 시스템에 전혀 감염의 피해를 입히지 않고 알려지지 않은 악성 코드를 탐지할 수 있다는 점에서는 상당히 강력한 방법이라고 이야기 하였다. 하지만 에뮬레이터(Emulator)는 스캐닝 엔진(Scanning Engine)이 실행 파일(Executable File)을 검사 할 때마다 모두 가상의 환경에서 실행을 하고 분석을 해야 된다는 점에서는 컴퓨터 시스템에 대한 자원 소모가 커지게 되는 부담을 안고 있다. 이 문제로 인해 전반적인 스캐닝 엔진(Scanning Engine)의 검사 속도 저하로 이어지는 점이 가장 큰 단점이라고 할 수 있다.

2) 샌드박스(Sandbox)
에뮬레이터(Emulator)와 샌드박스(Sandbox)는 실행 파일(Executable File)의 실행을 통하여 수집된 정보를 통하여 악성이라고 판단하는 점에서는 유사한 형태라고 할 수 있다. 그러나 에뮬레이터(Emulator)와 샌드박스(Sandbox)의 가장 큰 차이점은 어떠한 형태로 실행 파일(Executable File)을 실행하고 어떠한 방식으로 악성 코드로 판단할 수 있는 정보들을 수집하는가에 가장 큰 차이점을 가지고 있다.
일반적으로 샌드박스(Sandbox)는 어플리케이션 에뮬레이터(Application Emulator)라고도 알려져 있는데 이러한 명칭에서 알 수 있듯이 샌드박스(Sandbox)는 에뮬레이터(Emulator)와는 달리 가상의 공간을 생성하는 것이 아니라 실제 컴퓨터 시스템상에서 바로 실행 파일(Executable File)을 실행하고는 정보를 수집한다는 점에서 가장 큰 차이점을 가지고 있다.


[그림 6] CWSandbox의 기본 구조

일반적인 어플리케이션 에뮬레이터(Application Emulator)로 널리 알려져 있는 CWSandbox는 [그림 6]과 같은 기본적인 구조로 되어 있다. CWSandbox의 경우 실행 파일(Executable File)이 실행되면 해당 파일의 스레드(Thread)로 모니터링 모듈인 CWMonitor.dll 파일을 인젝션(Injection) 시킨다. 인젝션(Injection) 이 후 해당 실행 파일(Executable File)이 실행되는 되는 모든 절차를 추적하여 해당 정보를 모두 CWSnadbox로 전달하게 된다.


[그림 7] CWSnadbox에서 윈도우 API 호출의 후킹(Hooking)

그리고 실행 파일(Executable File)이 실행되는 과정에서 발생하는 윈도우 API(Windows API) 호출 모두를 API 후킹(API Hooking) 기법을 이용하여 가로챈 후 CWSandbox로 전달 된 다. 전달 된 윈도우 API(Windows API) 호출은 CWSandbox를 통해 윈도우 커널 레벨(Windows Kernel Level)로 전달하는 정상적인 절차를 수행하게 되고 호출되는 윈도우 API(Windows API) 역시 호출한 해당 실행 파일(Executable File)로 바로 전달하는 것이 아니라 CWSandbox를 거쳐서 전달하게 되는 것이다. 이러한 과정을 표현한 것이 바로 [그림 7]과 같다.

그런데 여기에서 바로 어플리케이션 에뮬레이터(Application Emulator)인 샌드박스(Sandbox)의 가장 큰 특징이 나타난다. 호출 되는 윈도우 API(Windows API)가 CWSandbox를 통해 실행 파일(Executable File)로 전달 된 후 다시 그 리턴 값이 윈도우 운영체제로 바로 전달 되는 것이 아니라 CWSandbox를 통해 전혀 다른 리턴 값을 윈도우 운영체제로 전달하게 된다는 것이다. 이러한 다른 리턴 값을 전달하게 됨으로 실행 파일(Executable File)이 악성 코드여서 감염으로 인해 발생하는 악의적인 기능들이 모두 CWSandbox에 의해 걸러지게 됨으로 실질적인 컴퓨터 시스템에는 감염으로 인한 피해가 발생하지 않게 된다. 그리고 수집된 윈도우 API(Windows API) 호출과 리턴된 값과 같은 정보들을 통하여 CWSandbox는 해당 실행 파일(Executable File)이 알려지지 않은 악성 코드인지 판단을 하게 된다.
그러나 에뮬레이터(Emulator)와 같이 가상의 공간이 아닌 실제 컴퓨터 시스템의 환경에서 실행 파일(Executable File)을 실행하는 샌드박스(Sandbox) 역시 윈도우 응용 프로그램이다. 그러므로 샌드박스(Sandbox)가 특정 악성 코드를 정상적으로 제어하지 못하게 될 경우에는 그 감염으로 인한 피해가 고스란히 실제 시스템으로 전달되게 됨으로 예측하지 못하는 문제가 발생할 가능성이 크다.

이제까지는 실행 파일(Executable File)의 실행을 통해서 알려지지 않은 악성 코드를 탐지 할 수 있는 에뮬레이터(Emulator)와 샌드박스(Sandbox)에 대해서 알아 보았다. 하지만 다음 장에서는 일반적인 윈도우 실행 파일 포맷이 아닌 전자 메일로 형태는 급속한 확산을 시도하는 알려지지 않은 매스 메일러 웜(Mass Mailer Worm)을 탐지 할 수 있는 기법에 대해서 알아 보도록 하자.[Ahn] 

1. packetstorm.linuxsecurity.com
2. synnergy.net
3. unsecure.altervista.org
4. www.blacksheepnetworks.com
5. www.circlemud.org
6. www.dsinet.org
7. www.metasploit.com
8. www.nostarch.com
9. www.packetstormsecurity.org
10. www.rosiello.org
11. www.safemode.org
12. www.security-corporation.com
13. www.thc.org

D-DOS란 "Distribute Denial of Service attack"의 약자로 우리말로는'서비스 분산 거부 공격' 이라고한다.
단적으로 특정 기법을 통해 대량의 네트워크 접속을 유발해 해당 네트워크, 서버등의 시스템을 마비시키는 악의적인 네트워크에 대한 공격이다.
결과적으로 네트워크 마비 등으로 인해 정상 이용 고객들의 접속 자체도 이루어지지 않는 상태가 되는것으로
다음의 기법들이 대표적으로 많이 사용되고 있다.

1. SYN Flood
특정 TCP 포트로  허용치 보다 초과된 수의 연결 요청(SYN) 전송
대부분 Source IP가 Spoofing 되어 있음

2. UDP Flood
허용치 보다 초과된 수의 UDP 패킷

3. ICMP Flood
허용치 보다 초과된 수의 ICMP 패킷

4. Fragment Flood
허용치 보다 초과된 수의 fragmented IP  패킷

5. Connection Flood
Connection 수가 정상의 경우보다 매우 높은 경우

6. Source Flood
단일 Source 가 허용치보다 많은 수의 IP 패킷을 전송하는 경우

7. Zombie 공격 
너무 많은 합법 IP Source로부터 합법적인 TCP 패킷을 전송하는 경우

8. Slammer 공격 
허용치 보다 초과된 수의 패킷이 UDP 포트 1434로 전송

9. DNS 공격 
허용치 보다 초과된 수의 패킷이 UDP 포트 53으로 전송

10. My Doom 공격 
Zombie로부터 허용치보다 높은 수의 HTTP 패킷 전송

11. Smurf 공격
대상 서버의 소스 주소를 위조하여 다수의 Echo(Ping) 메시지를 IP Broadcast트 주소로 전송. 
해당 Broadcast주소로 트래픽을 전달하는 라우팅 장치가 Layer 2 Broadcast 기능에 대해 IP Broadcast를 
수행하기 때문에 대부분의 네트워크 호스트는 각각 ICMP Echo 요청을 받아들여 Echo 응답을 수행하게 되므로 응답 중인 호스트 수에 비례하여 트래픽이 증가

12. Fraggle 공격  
Fraggle은 UDP (7)Echo  메시지를 사용한다는 점을 제외하곤 smurf와 유사함. 
멀티액세스 Broadcast 네트워크에서는 수백 대의 시스템이 각 패킷에 응답할 수 있음.
Echo(7) 및 Chargen(UDP 19)를 이용하여 Loop 형성 가능 

특히 최근에는 악성코드 혹은 바이러스를 통한 Bot 감염에 의한 좀비PC들(BotNet)이 D-dos 공격에 많이 이용되는 7번 이후의 공격이 증가하고 있으며 IDC내로 최근에 유입되는 트래픽이 수G를 넘는 경우도 흔하다.

현재 국내외의 많은 네트워크 장비업체, 솔루션 업체에서 D-Dos 방어 장비, 솔루션이 출시되고 있으나 워낙 다양한 공격에 대처하기에는 기반 기술자체의 한계로 인해 효용성이 떨어지고 있다.

기존의 대부분 IDS, IPS,  백신등의 기본 아키텍처가 Signature 를 기반으로 패킷 비교를 통한 차단방식을 사용하고 있으나 근본적으로  D-Dos 공격 자체가 TCP, UDP 프로토콜 자체의 취약성 혹은 매커니즘을 이용한 대량 패킷을 전송해서 시스템 혹은 네트워크에 과부하를 일으키는 방식을 사용함에 따라 Signature가 없거나 수집이 되었다 해도 해당 패턴이 장비에 업데이트가 되는데 수시간 혹은 수십일이 소요되는 현실을 감안할때 일명 "Zero Day 공격"에는 근본적으로 대처할 수가 없는것이 현실이다.

단, 현재 해외에서 각광받는 RBIPS(Rate-Based Intrusion Prevention System) 장비가 큰 효과를 얻고 있다고 하는데 해당 장비에 대해서 조만간 소개해 보겠다.

ICMP(Internet Contol Message Protocol)는 IETF RFC792에 정의된 프로토콜로써 호스트간 혹은 호스트와 라우터간의 에러 상태 혹은 상태 변화를 알려주고 요청에 응답을 하는 기능을 담당하는 네트워크 제어프로토콜이다. 활성화된 서비스나 포트가 필요하지 않는 유일한 프로토콜이다. 이러한 ICMP의 특징을 악용한 ICMP Flooding은 대량의 ICMP패킷을 공격자가 직접 victim에게 전송하는 방법으로 그 변종의 예러 Smurf, Welchia worm 등이 있다. Smuf는 공격자가 source IP address를 victim의 IP address로 설정한 후, broadcast address로 ICMP ehco request패킷을 전송하면 그 하위 모든 시스템들이 ICMP echo reply 패킷을 victim으로 전송하게 되어 대량의 패킷들이 집중하여 네트워크 부하를 높이게 된다. 최근 발견된 Welchia worm은 감연 시스템에 대하여 IP address의 B클래스를 고정시키고 C클래스부터 증가시키며 ICMP 패킷을 전송하여 다른 감염 대상을 찾고 감염 시스템의 성능을 저하시키는 형태이다.

트래픽 모니터로 '패킷 개수' 체크
네트워크 장비라고 함은 스위치, 파이어월, 라우터 등을 말하며, 대다수의 네트워크 장비에는 자체적으로 포트별 트래픽 또는 세션별 트래픽을 관찰할 수 있는 기능이 있다. 물론 포트별 트래픽이나 전체 트래픽을 관찰할 수 있는 NMS(Network Management System)를 활용할 수도 있다. 네트워크 장비를 이용하는 것은 웜 트래픽의 패턴을 찾는다기보다는 트래픽의 양을 관찰하는 것이다. 트래픽이 많고 적음으로 웜인지 아닌지를 판단하는 것은 조금 위험스러운 생각이라고 할 수도 있겠지만, 웜 트래픽의 특징을 생각해보면 간단하게 웜에 감염된 PC 또는 IP 어드레스를 찾을 수 있다. 
여기에서 전체 송수신되는 데이터 양(Bytes)을 기준으로 판단하기 보다 패킷 개수로 판단해야 한다. 데이터 양을 기준으로 판단하면 많은 데이터를 업, 다운로드하는 경우와 혼동될 수 있기 때문이다. 예를 들어 SYN 공격이라고 하면 대략 100Mbps 네트워크에서 초당 1000개 이상의 SYN 패킷이 한 IP 어드레스를 통해 전송된다. 하지만 SYN 패킷은 크기가 65bytes이기 때문에 1초에 전송하는 데이터 양은 65Kbytes이다. 또한 대역폭 사용양도 700Kbps 미만으로 1%도 되지 않는다. 
물론 많은 NMS 도구를 사용해 전체 트래픽 발생량을 수시로 관찰해야 한다. 많은 고객 사이트를 방문하면서 의아해했던 점이 대부분 패킷 개수보다는 대역폭에 영향을 주는 데이터 양에 더 신경을 쓴다는 것이었다. 장비에 과부하를 발생시키는 것은 물론 총 송수신되는 데이터 양일 수도 있지만, 더더욱 영향을 주는 것이 패킷의 개수이다. 이제 다음과 같은 경우를 생각하면서 트래픽을 관찰해 보자.

·특정 IP 어드레스 또는 포트를 살펴보니 송신되는 패킷은 상당히 많은데 수신되는 패킷은 없다
·데이터 양(bytes)에 비해 송수신되는 패킷의 개수가 너무 많다
·한 IP 어드레스가 지나치게 많은 세션을 형성한다

사용자가 아무리 손이 빠르고 애플리케이션이 특수하게 설계돼 있다고 하더라도 1초에 100여 개 이상의 세션을 한 IP 어드레스가 형성하기란 쉽지 않다. 모두가 비정상적인 트래픽으로 생각할 수 있다. 
실제 패킷을 저장할 수 없는 NMS 도구나 장비의 콘솔 화면을 사용하는 것은 간단하고 추가 비용이 들지 않는다는 장점이 있지만, 몇 가지 어려움이 있다. 첫째, 사용자가 수시로 장비에 접속해 트래픽 상태를 관찰해야 하기 때문에 오히려 해당 장비에 부하를 가중할 수 있다. 둘째 과도한 트래픽에 의해 시스템이 과부하 상태인 경우에는 트래픽을 관찰하기 위해 접속하기 조차 힘들 수 있다. 
셋째 IP 어드레스별 트래픽과 세션 정보를 관찰할 수 있지만, 의심되는 트래픽이 실제 웜으로 인해 발생하는 트래픽인지 분석하기 어렵다. 즉, 증거가 될만한 실제 패킷을 저장할 수 없다. 이것은 패킷 저장 기능이 있는 NMS나 IDS(Intrusion Detection System)를 사용해 해결할 수도 있다. 넷째 의심되는 IP 어드레스에 대한 차단은 사용자 몫이다. 주의할 점은 트래픽뿐만 아니라 해당 장비의 CPU, 메모리 상태도 항상 점검해야 한다는 것이다.

UDP(User Datagram Protocol)를 이용한 패킷전달은 비연결형 서비스로서 포트대 포트로 전송한다. 대표적인 응용 서비스로 TFTP, SNMP, 실시간 인터넷 방송들이 이에 해당한다. UDP Flooding은 UDP의 비연결성 및 비신뢰성 때문에 공격이 용이한 방법이다. UDP는 source address와 source port를 spoofing 하기 쉽다. 이러한 약점들을 이용해 과다한 트래픽을 victim에 전송함으로써 spoof가 되는 victim간 네트워크를 마비시킨다. <그림>에 나타낸 바와 같이 공격자가 victim A에게 source IP address를 victim B의 IP address로 spoofing하여 대량의 UDP 패킷을 전송하면 victim A와 victim B는 계쏙해서 서로 패킷을 주고받게 되어 두 시스템 사이의 네트워크에 과부하가 초래된다. 이 공격은 주로 echo와 chargen 서비스를 이용한다.

ICMP Protocol

신뢰성을 제공해주지 못하는 IP Protocol 통신 환경에서 발생할 수 있는 문제에 대한 Feedback을 제공하기 위해 설계되었다. 따라서, 프로토콜 컨트롤을 위해 다양한 형태의 메시지를 포함하고 있다. 그 중 잘못된 서비스 Port로 UDP 패킷이 전달 되었을 때 발생되는 ICMP Destination Port Uncreachable 메시지는 UDP Flooding 공격과 밀접한 관련이 있다.

보통 UDP storm attack 이라 불리는데, UDP 서비스 중에 echo/chargen을 이용하여, 시스템을 다운시키는 공격이다. 이것들을 이용하여 공격을 받는 경우가 많고, 또한 실제로 echo/chargen service는 별로 이용되는 일이 없기 때문에 시스템에서 제거하는 편이 좋다. 제거하는 방법은 /etc/services 와 /etc/inetd.conf 파일에서 echo, chargen을 제거한 후에 inetd 수퍼서버를 다시 띄우는 것이다.

• 3.1 ICMP flood
• 3.2 Teardrop attacks
• 3.3 Peer-to-peer attacks
• 3.4 Permanent denial-of-service attacks
• 3.5 Application level floods
• 3.6 Nuke
• 3.7 Distributed attack
  
• 3.8 Reflected attack
• 3.9 Degradation-of-service attacks
  
• 3.10 Unintentional denial of service
• 3.11 Denial-of-Service Level II
• 3.12 Blind Denial of Service

typedef struct _CHILD_RESULT
{
 DWORD dwDepth;
 LPVOID  lpLeftContext;
 LPVOID  lpRightContext;
}CHILD_RESULT, *PCHILD_RESULT;

typedef struct _CHECK_RESULT
{
 DWORD    dwFlags;
 DWORD    dwCheckResult;
 CHILD_RESULT  stChildResult;
 TCHAR    szResult[SZ_MAXSIZE];
 LPVOID    lpContext;
}CHECK_RESULT, *PCHECK_RESULT;

1) 구조체 형태 파악하기

0:000> dt _CHECK_RESULT
WinDbg_dt_test!_CHECK_RESULT
   +0x000 dwFlags          : Uint4B
   +0x004 dwCheckResult    : Uint4B
   +0x008 stChildResult    : _CHILD_RESULT
   +0x014 szResult         : [1024] Wchar
   +0x814 lpContext        : Ptr32 Void

2)구조체에 설정된 값 확인하기

0:000> dt _CHECK_RESULT 0x27f6f8
WinDbg_dt_test!_CHECK_RESULT
   +0x000 dwFlags          : 1
   +0x004 dwCheckResult    : 4
   +0x008 stChildResult    : _CHILD_RESULT
   +0x014 szResult         : [1024]  "Check_WinDBG_dt_Command function call"
   +0x814 lpContext        : (null)

2-1)구조체 값 확인하기 (심볼이 설정되었을때)

0:000> dt stChkResult
Local var @ 0x27f6f8 Type _CHECK_RESULT
   +0x000 dwFlags          : 1
   +0x004 dwCheckResult    : 4
   +0x008 stChildResult    : _CHILD_RESULT
   +0x014 szResult         : [1024]  "Check_WinDBG_dt_Command function call"
   +0x814 lpContext        : (null)

3) 구조체 특정 필드 확인하기 
0:000> dt _CHECK_RESULT dwCheckResult
WinDbg_dt_test!_CHECK_RESULT
   +0x004 dwCheckResult : Uint4B

3-1)구조체 특정 필드 값 확인하기 
0:000> dt _CHECK_RESULT dwCheckResult 0x27f6f8
WinDbg_dt_test!_CHECK_RESULT
   +0x004 dwCheckResult : 4
0:000> dt _CHECK_RESULT stChildResult 0x27f6f8
WinDbg_dt_test!_CHECK_RESULT
   +0x008 stChildResult : _CHILD_RESULT

4) 구조체 내에 있는 구조체 값 확인하기

0:000> dt _CHILD_RESULT 0x27f6f8+0x008
WinDbg_dt_test!_CHILD_RESULT
   +0x000 dwDepth          : 0
   +0x004 lpLeftContext    : (null)
   +0x008 lpRightContext   : (null)

5) 구조체에 있는 모든 값 나열(펼처서)해서 보기
0:000> dt -r _CHECK_RESULT 0x27f6f8
WinDbg_dt_test!_CHECK_RESULT
   +0x000 dwFlags          : 1
   +0x004 dwCheckResult    : 4
   +0x008 stChildResult    : _CHILD_RESULT
      +0x000 dwDepth          : 0
      +0x004 lpLeftContext    : (null)
      +0x008 lpRightContext   : (null)
   +0x014 szResult         : [1024]  "Check_WinDBG_dt_Command function call"
   +0x814 lpContext        : (null) 

1) 커널의 모든 구조체 나열 : dt nt!_* (dt는 data type의 약자이고, nt는 윈도우 nt를 말하는게 아닐런지...ㅎㅎㅎ)

2) 커널의 특정 구조체 나열(인터럽트 관련) : dt nt!_*interrupt*

3) 특정 구조체의 구조 보기 : dt nt!_ktrap_frame

4) 특정 구조체 내의 하부 구조체까지 보는 명령 : dt nt!_ktrap_frame -r

5) 커널 내의 모든 스택 정보 보기 : !stacks 0

6) 시스템에 로드된 디바이스 드라이버 나열 : lm t n(lm은 list module의 약자 인듯...)

7) 전체 IDT(Interrupt Dispatch Table) 나열 : !idt -a

8) 빈번히(?) 호출된 interrupt 나열 : !idt => 어떤 빈도로 나열되는지 모르겠음.

9) 인터럽트 컨트롤러 나열 : !pic, !apic(작동 안함???)

10) io pic(programmable interrupt controller) 나열 : !ioapic

--------------------------------------- crash 분석 ---------------------------------------------------------

11) !analyze -v : 분석 결과 보기

12) kb : crash 당시의 커널 call stack 보기

13) !process -1 0 : crash 당시의 수행 중이던 프로세스

     !process -1 7 : crash 당시의 수행 중이던 프로세스의 상세 정보 출력(7이 상세 정보 출력 옵션임)

     - !process 0 0 : crash 당시의 가상메모리에 load 되어 있던 모든 프로세스(마지막이 0 flag 이므로, 간략히 출력 옵션임)

     - !process [process 시작주소] : 프로세스 관련 상세 정보 출력,

                                                   위의 커맨드로 시작주소를 알 수 있음.

     - 출력 정보 설명 :

        PROCESS : 프로세스의 정보가 들어있는 EPROCESS Block의 주소

        Cid : 프로세스 ID

        Peb : Process Environment Block 의 주소

        ParentCid : 부모 프로세스 ID

        Image : 프로세스 이름

14) !vm : crash 당시의 가상 메모리 사용 내역 요약 및 프로세스 리스트

15) !poolused : crash 당시의 커널 paged&nonpaged pool list

     - !poolused 2 : nonpaged pool 할당량 별로 정렬 후 출력

     - !poolused 4 : paged pool 할당량 별로 정렬 후 출력

16) !thread [thread 시작주소] : !process [process시작주소]를 하면 프로세스에 포함된 thread의 정보가

                                           나와서 확인 가능함.

     - 출력 정보 설명 : teb(thread environment block 시작 주소)

17) !locks : crash 당시 resource lock 정보

18) !handle : crash 당시에 open된 handle 정보 나열

     !handle [프로세스주소] : 해당 프로세스가 소유한 핸들을 출력함

     !handle [프로세스주소] f

19) !stack [프로세스주소] : 프로세스 관련 Stack 정보를 보여줌

--------------------------------------- hang 분석 ------------------------------------------------------

1) !analyze -hang -v : hang 분석을 해줌

--------------------------------------- !analyze -v 해석 ------------------------------------------------------

덤프에 따라, 일부 값은 안 나올수도 있음.

-v(verbose)  옵션은 상세 결과를 출력하게 함

1) FAULTING_IP : fault가 발생했을 때의 명령의 포인터 값

2) BUGCHECK_STR : 발생한 BUGCHECK을 설명하는 문장임.

                               BUGCHECK은 주로 커널 모드 fault와 연관이 있음.

3) DEFAULT_BUCKET_ID : 현재의 fault가 어떤 범주의 fault에 속하는지를 알려줌

4) LAST_CONTROL_TRANSFER : 스택에서 이뤄진 마지막 두 함수 호출을 보여준다.

                                               이들 주소에 ln 명령을 사용하면, 마지막 함수를 확인 가능함.

                                               (ln [주소] : 주소가 나타내는 심볼을 표시함)

5) STACK_TEXT : 스레드의 전체 스택 트레이스를 보여준다.

6) STACK_COMMAND : fault를 유발한 스레드의 stack trace를 구하기 위해 실행된 명령을 보여준다.

                                  ; 는 구분자임.

6) FOLLOWUP_IP : fault를 유발했을 가능성이 가장 큰 명령을 보여줌

7) SYMBOL_NAME : fault가 발생한 심볼의 이름을 보여줌

                              nt!ExDeferredFreePool+540 으로 나오는 것은 심볼이름이 아님. 주소를 나타냄

                              Private Symbol 이 없기 때문에 해당 주소의 구체적인 함수명 같은 심볼을 안 보여줌

                              (MS만 볼 수 있음)

8) FOLLOWUP_NAME : 이 fault를 누가 사후 점검해야 하는지를 나타냄

                                  보통 MachineOwner가 많음

9) IMAGE_NAME : fault가 발생한 이미지의 이름을 나타냄

10) MODULE_NAME : fault를 보이는 모듈의 이름을 나타냄

                              (lmvm [모듈명] 으로 조회 가능)

11) BUCKET_ID : fault가 속하는 문제의 범주를 보여줌

11) FOLLOW_UP : 이 fault에 가장 알맞은 소유자를 보여준다. 소유자를 찾을수 없다면 디폴트인 MachineOwner가 됨.

아래 3가지 옵션을 이용하면 보다 많은 정보를 쉽게 확인 할 수 있습니다.

-V : 레지스터 또는 버추얼 메모리 주소 값을 보여 줍니다.

-t : 각 로컬 변수의 data type을 보여 줍니다.

-i : local, global, parameter, function, or unknown 등의 정보를 보여 줍니다.

적용예

1: kd> dv -V -t -i

prv param  b60b6b20 @ebp+0x08 void * P = 0x86558908

prv param  b60b6b24 @ebp+0x0c unsigned long TagToFree = 0

prv local  b60b6b24 @ebp+0x0c struct _EPROCESS * ProcessBilled = 0x00000000

prv local  b60b6b0c @ebp-0x0c unsigned long Tag = 0xb60b6b8d

prv local  b60b6b14 @ebp-0x04 _POOL_TYPE EntryPoolType = PagedPool (1)

prv local  b60b6b08 @ebp-0x10 unsigned long BigPages = 0x805bc066

prv local  b60b6b00 @ebp-0x18 _POOL_TYPE PoolType = NonPagedPool (0)

prv local  b60b6af0 @ebp-0x28 struct _KLOCK_QUEUE_HANDLE LockHandle = struct _KLOCK_QUEUE_HANDLE

prv local  b60b6b20 @ebp+0x08 unsigned long Combined = 0x86558908

로컬 변수인지 또는 파라미터 인지 보여주고 주소값이 나와서 값을 확인해 볼수 있다.

최근에 알게된 Tip을 하나 소개 합니다.

1)특정 콜스택 프레임으로 이동

1: kd> .frame 12

12 013bf554 65e931e8 ipnathlp!NatpDeletePortBlock+0x48

2) 로컬 변수와 파라미터 값 확인

1: kd> dv -V -t

013bf55c @ebp+0x08 struct _NAT_PORT_RESERVATION * PortReservation = 0x0013d1f0

013bf560 @ebp+0x0c struct _NAT_PORT_BLOCK * PortBlock = 0x02f75988

013bf544 @ebp-0x10 struct _IO_STATUS_BLOCK IoStatus = struct _IO_STATUS_BLOCK

013bf54c @ebp-0x08 struct tcp_blockports_request Request = struct tcp_blockports_request

//dt 명령어로 값을 확인했다.

1: kd> dt _NAT_PORT_RESERVATION 0x0013d1f0

ipnathlp!_NAT_PORT_RESERVATION

   +0x000 TcpipHandle      : 0x00000da8

   +0x004 BlockSize        : 0x20

   +0x006 PortBlockSize    : 0x18

   +0x008 PortBlockList    : _LIST_ENTRY [ 0x2f75988 - 0x12b7f8 ]

//dt 명령어로 값을 확인했다.

1: kd> dt _NAT_PORT_BLOCK 0x02f75988

ipnathlp!_NAT_PORT_BLOCK

   +0x000 Link             : _LIST_ENTRY [ 0x12c050 - 0x13d1f8 ]

   +0x008 StartHandle      : 0x1389

   +0x00c Bitmap           : _RTL_BITMAP

   +0x014 BitmapBuffer     : [0] 0

3) ?? 명령으로 특정 로컬 변수값 확인

1: kd> ?? Request  -> (?? 명령어로 확인할수 있는줄 몰랐다, 꼭 dt만 사용해야 하는줄 알았다.)

struct tcp_blockports_request

   +0x000 ReservePorts     : 0

   +0x004 NumberofPorts    : 0x1389

   +0x004 StartHandle      : 0x1389 a 0n5001

kd> .symfix e:\symbols

kd> .reload
Connected to Windows XP 2600 x86 compatible target, ptr64 FALSE
Loading Kernel Symbols
........................
Loading User Symbols

lm 을 사용하여 심볼이 로드된 상태를 봅니다.

kd> lm
start    end        module name
804d9000 806ede00   nt         (pdb symbols)          e:\symbols\ntoskrnl.pdb\8592B6763F344B562\ntoskrnl.pdb
806ee000 80701d80   hal        (deferred)            
f9871000 f988b580   Mup        (deferred)   
f996f000 f998e780   fltMgr     (deferred)
...

nt 는 심볼이 로드된 것이 보이는데 나머지는 deferred 라고 나옵니다.
이것은 WinDbg 의 lazy symbol loading (deferred symbol loading) 이라는 특징 때문에 그렇습니다.

WinDbg 는 심볼을 로드할 때 꼭 필요한 심볼만 올려놓고 나머지는 deferred 로 해놓고 심볼을 올리지 않습니다. deferred 로 된 녀석들은 나중에 해당 모듈이 WinDbg 상에서 실제 사용되는 순간이 발생해야만 로드가 됩니다. 필요한 것만 그때 그때 올려주는 나름대로 효율적인 방법입니다. ^^

WinDbg Help 에 보면 .reload 는 다양한 옵션을 가지고 있는데요.
제가 유용하게 사용하는 것만 몇가지 설명합니다.

.reload /i mydrv.sys (심볼이 맞지않아도 강제로 심볼 로드하기)

예를 들어 어제 빌드한 드라이버가 BSOD 를 발생시켜서 덤프가 만들어 졌는데 심볼은 보관하지 않아서 덤프분석을 할 수 없는 문제를 만났다고 가정합시다. 다행히도 어제 소스 코드를 그대로 보관하고 있었다고 하면 그것을 그대로 빌드하여 pdb 파일을 생성할 수 있습니다. 문제는 이 pdb 파일을 로드하려고 해도 WinDbg가 TimeStamp 등을 체크하여 symbol mismatch 에러를 내면서 심볼로드를 하지 않는다는 겁니다. 이런 경우에 심볼이 맞는지 확인하지 말고 강제로 올려달라는 /i 옵션을 사용하면 심볼이 올라갑니다.

.reload /f (심볼 모두 올리기)

보통 lazy symbol loading 상태로 그냥 사용하시면 되지만 혹시 모든 모듈의 심볼을 모두 올려 놓아야 할 경우가 있다면 /f 옵션을 사용해서 모든 모듈의 심볼을 올릴 수 있습니다.

.reload /u (심볼 모두 내리기)

반대로 모든 심볼을 모두 내려야 할 경우가 있다면 /u 옵션을 사용해서 모든 모듈의 심볼을 내릴 수 있습니다.

.reload /u mydrv.sys (특정모듈 심볼 내리기)

mydrv.pdb 를 로드하여 사용하고 있는데 새로 빌드한 mydrv.pdb 를 심볼패스에 복사하면 mydrv.pdb 가 사용중이라서 복사가 실패합니다. 이런 경우 /u mydrv.sys 옵션을 줘서 특정 모듈의 심볼만 내릴 수 있습니다.

.reload mydrv.sys (특정모듈 심볼 로드하기)

위와 같이 내려진 특정 모듈의 심볼만 다시 올리려면 mydrv.sys 처럼 모듈 이름을 줘서 로드합니다.

로드된 모듈 리스트 보기
 lm 명령을 이용하면 된다.

lm k : Kernel Mode 모듈 표시
lm u : User Mode 모듈 표시
lm m : 패턴을 검사하여 해당하는 것만 보여줌 <lm m my*>

lkd> lm
start    end        module name
00c80000 00c90000   NateOnHook40u   (export symbols)       C:\Program Files\NATEON\BIN\NateOnHook40u.dll
00cb0000 00cb9000   MgHookDll C (export symbols)       C:\Program Files\LG Software\On Screen Display\MgHookDll.dll
01000000 0106a000   windbg     (pdb symbols)          D:\Symbol\WebSymbol\windbg.pdb\D6EF677AA54441279479F0307F05A8941\windbg.pdb
016a0000 01784000   ext        (export symbols)       C:\Program Files\Debugging Tools for Windows\winext\ext.dll
01790000 017c1000   kext       (pdb symbols)          D:\Symbol\WebSymbol\kext.pdb\6B643FC4E9F94FF4ABA4CEF1FD6F89D61\kext.pdb

모듈의 심볼(Symbol) 검사
 x 모듈!패턴 을 입력하면 된다.

lkd> x nt!Ke*
804f8c02 nt!KeQuerySystemTime = <no type information>
804f8c9e nt!KeEnableInterrupts = <no type information>
80500e38 nt!KeSwitchKernelStack = <no type information>
804fad32 nt!KeReadStateProcess = <no type information>
804f9188 nt!KeReleaseInterruptSpinLock = <no type information>

데이터 타입(Date Type) 표시
 dt 데이터 타입 을 입력하면 된다.

lkd> dt _EPROCESS
   +0x000 Pcb              : _KPROCESS
   +0x06c ProcessLock      : _EX_PUSH_LOCK
   +0x070 CreateTime       : _LARGE_INTEGER
   +0x078 ExitTime         : _LARGE_INTEGER
   +0x080 RundownProtect   : _EX_RUNDOWN_REF
   +0x084 UniqueProcessId  : Ptr32 Void
   +0x088 ActiveProcessLinks : _LIST_ENTRY
   +0x090 QuotaUsage       : [3] Uint4B
   +0x09c QuotaPeak        : [3] Uint4B
   +0x0a8 CommitCharge     : Uint4B

메모리 덤프(Memory Dump)
 d* 명령들을 이용하면 된다.

db : Byte 형식 + Ascii 로 표시
dd : 데이터를 4Byte 형식으로 표시

lkd> db 8053db18
8053db18  8b ff 55 8b ec 8b 45 08-8b 4d 0c 8b 55 14 89 48  ..U...E..M..U..H
8053db28  0c 8b 4d 10 89 48 10 03-ca 89 48 14 8b 4d 18 83  ..M..H....H..M..
8053db38  c1 fe 89 48 18 8b 4d 1c-89 48 20 66 8b 4d 20 66  ...H..M..H f.M f

디스어셈블리(Disassembly)
 u 주소 를 이용하면 된다. 특정 함수를 디스어셈블리 하고 싶으면 uf 주소 를 하면 된다.

u 주소 : 주소에서 일부분만 디스어셈블리
u 주소1 주소2 : 주소1에서 주소 2까지 디스어셈블리

lkd> u 8053db18 or uf nt!NtOpenProcess
nt!KeInitializeProfile:
8053db18 8bff             mov     edi,edi
8053db1a 55               push    ebp
8053db1b 8bec             mov     ebp,esp
8053db1d 8b4508           mov     eax,[ebp+0x8]
8053db20 8b4d0c           mov     ecx,[ebp+0xc]

메모리 영역 속성 보기(VA Dump)
 !vadump 명령을 사용하면 된다. 만약 특정 메모리의 속성을 보고 싶다면 !vprot 주소 명령을 사용하면 된다.

0:000> !vadump
BaseAddress:       00000000
RegionSize:        00010000
State:             00010000  MEM_FREE
Protect:           00000001  PAGE_NOACCESS

BaseAddress:       00010000
RegionSize:        00001000
State:             00001000  MEM_COMMIT
Protect:           00000004  PAGE_READWRITE
Type:              00020000  MEM_PRIVATE

0:000> !vprot 30c191c
BaseAddress: 030c1000
AllocationBase: 030c0000
AllocationProtect: 00000080 PAGE_EXECUTE_WRITECOPY
RegionSize: 00011000
State: 00001000 MEM_COMMIT
Protect: 00000010 PAGE_EXECUTE
Type: 01000000 MEM_IMAGE

프로세스 관련
 모든 프로세스를 보기위해서는 !process 0 0 를 입력하면 된다. 디버거를 특정 프로세스에 붙이고 싶으면 .process /i [pid] 를 입력하면 된다.

lkd> !process 0 0
**** NT ACTIVE PROCESS DUMP ****
PROCESS 8a3a3490  SessionId: none  Cid: 0004    Peb: 00000000  ParentCid: 0000
    DirBase: 00780000  ObjectTable: e1001c70  HandleCount: 521.
    Image: System

PROCESS 8a184158  SessionId: none  Cid: 03f0    Peb: 7ffdd000  ParentCid: 0004
    DirBase: 17a40020  ObjectTable: e163dd70  HandleCount:  20.
    Image: smss.exe

PROCESS 89df4da0  SessionId: 0  Cid: 0440    Peb: 7ffd5000  ParentCid: 03f0
    DirBase: 17a40040  ObjectTable: e1c6cb18  HandleCount: 626.
    Image: csrss.exe

구조체 내용 보기

!strct _KMUTANT ff93a330

이렇게 명령을 주면 자료구조랑 값들이 같이 출력이 된다.

WinDBG 디버깅 과정 파일로 저장하기

Windbg를 이용해서 디버깅을 하다보면,

디버깅과정을 저장할 필요가 생깁니다.
또는 아래와 같은 상황이 있을수 있을겁니다.

- 다른분의 도움을 통해 디버깅한 내용을 참고하고 싶은경우
- 수십시간동안 켜놓은 결과를 저장해야하는경우. -> 화면 버퍼를 넘어가면 그동안의  내용이 사라지죠~
- .cls 를 습관적으로 사용하는경우.    -> 제경우입니다. T.T

이때 유용한 명령어가 바로.

.logxxx 계열 명령어입니다.

.logopen logfile
    >> 디버깅 과정을 저장할 로그파일 명을 지정합니다.
          ex) .logopen “c:\dbglog\logs.txt”

.logfile
    >> 현재 기록중인 디버깅 로그파일의 상태를 표시합니다.

.logclose
    >> 기록중이던 로그를 종료(완료)합니다.



유용하게 쓰세요~
(단, .logopen 이전의 내용은 저장되지 않습니다.` ^^)
참고하세요)
.logopen 정보 역시 Windbg WorkSpace 에 함께 저장됩니다.~ ^^

출처 : 다년간의 프로그래밍 경험 및 구글 search 결과

1.심볼(pdb), 소스 파일 설정하기

(WinDbg에서 심볼은 필요할 때 로드한다. 즉 지연해서 로드한다.)

ld [심볼이름] -> 강제로 심볼 로드하는 명령어

lm -> 현재 로드 되어있는 모듈 보여준다. 지연 되어 있으면 (deffered)라고 나온다.

.reload-> 심볼다시로드

2.| (process status)

3.~ (thread status)

4.변수 확인하기

.frame 1

dv(display variable)

5.dt –r (typecast) (address)

(dt -r int 0x0012f5bc)

6.wt-> 모든 함수를 계층적으로 보여주는 명령어

7.브레이크 포인트

bp -> 주소를 이용해서 설정

bu -> 심볼이름을 이용해서 설정

(bu 060630_WinDbgTest!CWinDbgTestDlg::OnBnClickedButton1)

bl -> 브레이크 포인트 리스트

be (breakpoint enable), bd(breakpoint disable)

bc (breakpoint clear)

ba -> 메모리 액세스 브레이크 포인트

8.!critsec (임계섹션 주소), !locks(잠겨진 모든 임계섹션 주소 확인), !handle(프로세스내의 핸들 정보 표시)

1)!vm 명령을 사용해서 현재 컴퓨터의 메모리 사용량을 살펴 보았습니다.

kd> !vm

*** Virtual Memory Usage ***
Physical Memory:   655234   ( 2620936 Kb)
Page File: \??\C:\pagefile.sys
   Current:   2095104Kb Free Space:   1999612Kb
   Minimum:   2095104Kb Maximum:      4190208Kb
Available Pages:   130442   (  521768 Kb)
ResAvail Pages:    577917   ( 2311668 Kb)
Modified Pages:       749   (    2996 Kb)
NonPagedPool Usage: 65522   (  262088 Kb)
NonPagedPool Max:   69378   (  277512 Kb)
********** Excessive NonPaged Pool Usage *****
PagedPool 0 Usage:   4025   (   16100 Kb)
PagedPool 1 Usage:    416   (    1664 Kb)
PagedPool 2 Usage:    414   (    1656 Kb)
PagedPool 3 Usage:    416   (    1664 Kb)
PagedPool 4 Usage:    411   (    1644 Kb)
PagedPool Usage:     5682   (   22728 Kb)
PagedPool Maximum:  86016   (  344064 Kb)
Shared Commit:        978   (    3912 Kb)

현재 !vm 명령을 통해서 NonPagedPool 메모리를 거의 다 사용한 것을 알 수 있습니다. 아마 특정 디바이스 드라이버 모듈에서 메모리를 많이 사용하는 것 같습니다.

2) !poolused 명령어를 사용해서 각각 메모리 할당 내용을 살펴 봅니다.

0: kd> !poolused
   Sorting by  Tag

  Pool Used:
            NonPaged            Paged
 Tag    Allocs     Used    Allocs     Used
 1394        1      520         0        0UNKNOWN pooltag '1394', please update pooltag.txt
 1MEM        1     3368         0        0UNKNOWN pooltag '1MEM', please update pooltag.txt
 2MEM        1     3944         0        0UNKNOWN pooltag '2MEM', please update pooltag.txt
 3MEM        3      248         0        0UNKNOWN pooltag '3MEM', please update pooltag.txt
 8042        4     3944         0        0PS/2 kb and mouse , Binary: i8042prt.sys
 AGP         1      344         2      384UNKNOWN pooltag 'AGP ', please update pooltag.txt
 AcdN        2     1072         0        0TDI AcdObjectInfoG 
 AcpA        3      192         1      504ACPI Pooltags , Binary: acpi.sys
 AcpB        0        0         4      576ACPI Pooltags , Binary: acpi.sys
 AcpD       40    13280         0        0ACPI Pooltags , Binary: acpi.sys
 AcpF        6      240         0        0ACPI Pooltags , Binary: acpi.sys
 AcpM        0        0         1      128ACPI Pooltags , Binary: acpi.sys
 AcpO        4      208         0        0ACPI Pooltags , Binary: acpi.sys

...

 WmiG       30     6960         0        0Allocation of WMIGUID 
 WmiR       63     4032         0        0Wmi Registration info blocks 
 Wmip      146     3504       182    18600Wmi General purpose allocation 
 Wmit        1     4096         7    49480Wmi Trace 
 Wrpa        2      720         0        0WAN_ADAPTER_TAG 
 Wrpc        1       72         0        0WAN_CONN_TAG 
 Wrpi        1      120         0        0WAN_INTERFACE_TAG 
 Wrps        2      128         0        0WAN_STRING_TAG 
 aEoP        1      672         0        0UNKNOWN pooltag 'aEoP', please update pooltag.txt
 fEoP        1       16         0        0UNKNOWN pooltag 'fEoP', please update pooltag.txt
 hSVD        0        0         1       40Shared Heap Tag , Binary: mrxdav.sys
 hibr        0        0         1    24576UNKNOWN pooltag 'hibr', please update pooltag.txt
 iEoP        1       24         0        0UNKNOWN pooltag 'iEoP', please update pooltag.txt
 idle        2      208         0        0Power Manager idle handler 
 jEoP        1       24         0        0UNKNOWN pooltag 'jEoP', please update pooltag.txt
 mEoP        1       88         0        0UNKNOWN pooltag 'mEoP', please update pooltag.txt
 ohci        1      136         0        01394 OHCI host controller driver 
 rx..       3     1248         0        0UNKNOWN pooltag '  rx', please update pooltag.txt
 sidg        2       48         0        0GDI spooler events 
 thdd        0        0         1    20480DirectDraw/3D handle manager table 
 SeSd      18    77056         2       96UNKNOWN pooltag 'SeSd', please update pooltag.txt
 vPrt        0        0        18    68160UNKNOWN pooltag 'vPrt', please update pooltag.txt
 TOTAL     3570214 209120008     38769 13066104

usbp 태그를 사용하는 모듈이 Nonpaged를 많이 사용하고 있습니다. 

3)!poolfind를 이용해서 특정 태그 메모리 사용내역을 확인해 봅니다.

kd> !poolfind SeSd 0

Scanning large pool allocation table for Tag: SeSd (827d1000 : 827e9000)

Searching NonPaged pool (823b1000 : 82800000) for Tag: SeSd

826fa130 size:   c0 previous size:   40  (Allocated) SeSd
82712000 size:   c0 previous size:    0  (Allocated) SeSd
82715940 size:   a0 previous size:   60  (Allocated) SeSd
8271da30 size:   c0 previous size:   10  (Allocated) SeSd
82721c00 size:   10 previous size:   30  (Free)      SeSd
8272b3f0 size:   60 previous size:   30  (Allocated) SeSd
8272d770 size:   60 previous size:   40  (Allocated) SeSd
8272d7d0 size:   a0 previous size:   60  (Allocated) SeSd
8272d960 size:   a0 previous size:   70  (Allocated) SeSd
82736f30 size:   a0 previous size:   10  (Allocated) SeSd
82763840 size:   a0 previous size:   10  (Allocated) SeSd
8278b730 size:  100 previous size:  290  (Allocated) SeSd
8278b830 size:   10 previous size:  100  (Free)      SeSd
82790130 size:   a0 previous size:   20  (Allocated) SeSd
82799180 size:   a0 previous size:   10  (Allocated) SeSd
827c00e0 size:   a0 previous size:   30  (Allocated) SeSd
827c8320 size:   a0 previous size:   60  (Allocated) SeSd
827ca180 size:   a0 previous size:   50  (Allocated) SeSd
827ec140 size:   a0 previous size:   10  (Allocated) SeSd

Searching NonPaged pool (fe7c3000 : ffbe0000) for Tag: SeSd

위 결과를 보니 메모리 할당(Allocated)된 만큼 해제(free)를 하지 않고 있는것 같습니다. 메모리 릭(memory leak)이 발생한것 같습니다.

4) Tag 이름으로 문제를 발생하고 있는 드라이버 찾기

WinDbg에서 태그로 이름으로 드라이버를 찾는 명령어를 제공하지 않는것으로 알고 있습니다.

그래서 저는 www.dumpanaysis.org 사이트에 나와있는 방법으로 찾습니다. 

직접 C:\windows\system32\drivers 드라이버 폴더에 찾는다. (cmd.exe)

C:\windows\system32\drivers>findstr /S /m /l hSeSd *.sys

출처 : 다년간의 프로그램밍 경험 및 http://www.dumpanalysis.org

안녕하세요 신경준입니다. 어제는 날씨가 여름처럼 덥던데 오늘은 비가올려고 하는지 좀 서늘하네요. 일교차가 심한데 감기 걸리지 않게 조심하세요

 WinDbg에서 제가 생각할때 가장 많이 사용하는 명령어를 간단하게 정리했습니다.

[Debugger Setup : 심볼 설정]

 .sympath : 심볼 경로를 설정하는 명령어입니다.

 .sympath SRV*f:\localsymbols*http://msdl.microsoft.com/download/symbols

 .srcpath : source 경로를 설정하는 명령어 입니다. 

 .srcpath+ \\buildmachine\workspace\project\srt

 .lsrcpath : local 컴퓨터에 있는 source 경로를 설정하는 명령어 입니다.

 .lsrcpath+ c:\workspace\project\src 

 .lines : 디버깅 할때 소스 라인 정보를 보여주거나 보여주지 않게 설정한다.

 .lines -d (disable show source information)

 .lines -e (enable show source information)

 lm : 로드되어있는 모듈 정보를 알아본다.

s이름으로 시작하는 모듈의 정보를 알아낸다.

kd> lm m s*
start    end        module name
f9f73000 f9f7fd80   sysaudio     (deferred)                
fa04b000 fa09b400   srv          (deferred)                
faab7000 faac8500   sr           (deferred)                
facac000 facbae00   serial       (deferred)                
fb008000 fb00ba80   serenum      e:\mysymbols\SereEnum.pdb\.......
fb24f000 fb250000   swenum       (deferred)                

Unloaded modules:
f9f53000 f9f61000   swmidi.sys
fb0ae000 fb0b0000   splitter.sys
fb040000 fb043000   Sfloppy.SYS

!sym noisy 시끄러운 심볼을 로드한다.(이상한 심볼을 로드한다.)

!sym noisy Activates noisy symbol loading. 소란스러운 심볼을 로드하고 적용한다.

!sym quiet Deactivates noisy symbol loading. 소란스러운 심볼을 언로드하고 적용 해제한다.

.enable_unicode 1 : 디버깅 과정중에 unicode 스트링을 보여 줄수 있도록한다.

dt 명령어는 물론 Locals window and the Watch window. 에 있는 유니코드도 주소값 또는 hex 값이 아닌 스트링이 보여진다.

x 심볼을 조사해 본다.(Examine Symbols)

아래 명령어 예제는 prymes모듈에서 __n으로 시작하는 함수를 모두 보여주고 해당 심볼의 데이타 타입도 보여주라는 명령어이다.
0:001> x /t prymes!__n*
00427d84 char * myModule!__nullstring = 0x00425de8 "(null)"
0042a3c0 int myModule!_nstream = 512
Type information missing error for _nh_malloc
004021c1 struct MyStruct myModule!MyStructInstance = struct MyStruct
00427d14 <NoType> myModule!_NLG_Destination = <no type information>

Create a Visual C++ Wizard for Visual Studio 2005

• http://www.codeguru.com/cpp/v-s/devstudio_macros/customappwizards/article.php/c12775__1/

  Visual Studio C++ Project Templete 만들기 

• Creating the Project

  To create a new wizard project, go to File > New > Project and select Visual C++, and then from the list of available templates customwiz. Let's call this project "DummyWin32Wizard", because after all, that's exactly what it is. You will be asked to select the settings for this project. First, put "DummyWin32Wizard" in the "Wizard Friendly Name" edit, check the "User Interface" checkbox, and set the number of pages of the wizard to 1, because that's all what we'll need.
  

  When the project is created, it will have several created files that you can see in the following picture. The most important ones are described here:
  

   

짜증나는 워닝과 에러 중에,헤더파일 순서에 따라 발생하는 워닝/에러가 있습니다.특히 링크타임에 나는 에러는 네이밍 모양새가 재밌게 생겨먹지 않은 스타일로 생기는 데다가 링커가 별로 힌트를 주지 않아서 짜증이 나기도 합니다.예를 들면 아래와 같은 겁니다.

위 예는 MFC프로젝트에서 모든 파일에서 MFC헤더를 다른 헤더 보다 먼저 선언해야 하는데(대부분 stdafx.h를 가장 상위에 선언합니다.),비 MFC프로젝트에서 사용하던 파일을 Import하고 컴파일 하는 순간 발생했습니다.

이런 에러의 경우 대처법은 의외로 간단 합니다.일단 똑똑고 기억력 좋으신 분들은 자기가 했던 행위들의 콜스택을 하나하나 거슬러 올라가시면서 대처 하는법이 있고,이게 가장 비용대비 시간단축 효가가 가장 좋습니다.

순간 욱해서 콜스택 거슬러 올라가기 힘드신 (저 같은;;)분들은 아래처럼 대처 하시면 됩니다.먼저 링커 옵션에 아래 옵션을 추가 합니다.

그리고 다시 빌드 하면 링킹타임에 library를 스캔하는 리스트가 아래와 같이 output창에 나오게 됩니다.

윗 예에서 uafxcwd.lib를 링크 할 때,링크에러가 났고,에러를 유발한 유력한 용의자는 uuid.lib입니다.왜냐면,계속 다른 애들은 디폴트 경로에서 링크되는데 uuid.lib만 sdk에서 링크 되었고, MFC에서 new를 재정의 하기 때문에,이전에 new가 정의되어 있는 파일이 링크되면 안됩니다.여기서 “stdafx.h”파일을 추가 하는 것을 잊었구나 하는 생각이 듭니다.

/verbose옵션을 써보지 않으신 분들은 한번 넣고 컴파일을 해보시면 쓰잘떼기 없는 정보까지 주르륵 나와서 놀라실 껍니다.여러가지 링킹 타임에 하는 작업 정보를 자세히 알려주는 것을 알 수 있습니다.윗예의 :lib처럼 뒷부분에 세부 옵션을 붙여 보기 좋게 정보를 추출하는 작업이 익숙해 지면 일반적인 컴파일시 정보를 잘 제공해주지 않는 링킹 타임시 발생하는 에러에 정보를 얻어 디버깅 작업 시간을 단축 시킬 수 있습니다.

1. http://www.assembla.com/
이곳은 가입해보니 무료 사용자는 소스를 오픈해야만 하더군요.
바로 다른 곳을 알아보았습니다.

2. http://unfuddle.com/
소스를 오픈하지 않아도 된다길래
잽싸게 가입하고 소스 올리고,
친구를 프로젝트 팀원으로 등록하려고 보니..
무료 이용자는 팀원을 2명까지만 등록할 수 있네요...

3. http://ffhosting.net/
여기는 국내 사이트입니다.
무료 계정을 신청한 사람이 svn을 신청하면
세팅해 주고 사용할 수 있게 해준다고 합니다.
그런데 다른 사이트들은 프로젝트 관리 페이지를 제공하는데
(인원, 비용, task, bug tracking 등)
이곳은 그냥 서버만 제공하는것 같네요.

4. http://www.xp-dev.com/
그래서 다시 검색하다가 이곳을 알아냈습니다.
여러명 함께 사용할수 있고 기본 용량 500MB에
앞서 말했듯이 프로젝트 관리 페이지와 토론방, 게시판 등을 사용할 수 있네요.
프로젝트는 공개/비공개를 선택할 수 있고...

SVN 으로 소스 관리하시려는 분들은 참고하세요~