데도이메도(Dedoimedo)를 지난 10여 년간 읽어온 독자라면 필자가 보안 소프트웨어를 크게 선호하지 않는다는 점을 잘 알고 있을 것입니다. 그럼에도 불구하고 필자는 시스템 전반에서 이들이 어떻게 작동하는지 확인하기 위해 보안 제품을 테스트하곤 합니다. 이런 작업 덕분에 소프트웨어를 서로 비교하고 평가할 수 있는데, 특히 윈도우 보안 프로그램의 황금 기준이자 가장 훌륭하고 실용적이며 허세 없는 EMET과 비교하는 것이 유용합니다.
어쨌든 몇 달 전, 필자는 Windows 7 머신에서 Malwarebytes Anti-Malware(이하 MBAM) 스캔을 실행했는데, 스캔 도중에 블루스크린 오류(BSOD)가 발생했습니다. 상당히 곤란한 상황이었죠. 시스템을 복구한 직후, 필자는 본격적인 조사에 착수했습니다. 지금부터 그 과정을 함께 살펴보겠습니다.
테스트 환경과 기본 전제
무슨 일이 있었는지 파악하기 전에 몇 가지 배경 정보를 짚고 넘어가겠습니다. 우선 BSOD에 관한 이야기인데요. 일반적으로 윈도우는 개인 사용 환경에서 매우 안정적입니다(서버 환경은 별개의 주제입니다). 윈도우 커널 자체의 버그 때문에 심각한 시스템 크래시를 겪을 이유는 사실상 없습니다.
필자는 약 15년 동안 열두 대 정도의 다양한 시스템에서 윈도우를 집중적으로 사용해왔는데, BSOD를 겪은 것은 겨우 몇 번뿐입니다. 그래픽 카드 과열 때문에 한 번, 버그 많은 그래픽 드라이버 때문에 한 번(이 문제는 예전에 길게 다룬 적이 있습니다), 그리고 USB 케이블로 스마트폰을 연결했을 때 한 번. 그게 전부입니다.
앞서 말씀드린 것처럼, 커널 크래시는 하드웨어 오류나 결함 있는 드라이버로 인해서만 발생해야 마땅하며, 이는 필자의 사용 이력과 정확히 일치합니다. 이는 리눅스 크래시 관련 저술을 통해 문서화한 필자의 광범위한 리눅스 경험과도 맥닿습니다. 요컨대 하드웨어 문제, 잘못된 시스템 콜, 혹은 순수한 커널 버그가 전부이며, 그중 마지막 것이 가장 가능성이 낮습니다.
그런데 이번에는 ataport.sys 드라이버 문제에 직면했습니다. 이것은 마이크로소프트가 제공하는 드라이버이므로 버그가 있어서는 안 되는 파일입니다. 그렇다면 하드웨어 문제일까요? 만약 그렇다면 어떤 종류의 문제일까요? 성급하게 판단하기 전에, 문제 해결은 느리게, 신중하게, 체계적으로 수행해야 한다는 점을 강조하고 싶습니다.
분석 1단계: 크래시 덤프 확인
자, 무슨 일이 있었는지 이해해 봅시다. 필자는 이미 상세한 BSOD 가이드를 통해 분석 방법을 소개한 바 있습니다. 해당 튜토리얼에서 소개한 도구 중 하나를 활용하면 크래시 덤프를 분석할 수 있습니다. 여기서는 Nirsoft의 BlueScreenView 프로그램을 선택했습니다. 분석 결과, 크래시의 원인은 다음과 같았습니다.
ataport.SYS+1ff3c
구체적인 에러 코드는 KERNEL_DATA_INPAGE_ERROR였습니다. 메모리 코어의 다른 인자들을 확인해 보니, 이는 커널 작업 중 발생한 하드웨어 오류를 가리키며, 결국 시스템 크래시로 이어진 것으로 보입니다. 여기까지는 비교적 단순합니다.
그런데 왜 하필 MBAM 스캔 도중에 크래시가 발생한 걸까요?
흥미로운 질문입니다. 이제 우리는 다음 두 가지 가능성을 구분해야 합니다.
- 문제가 MBAM에만 특정되는 경우
- 스캔 중 우연히 드러난 더 일반적인 시스템 문제인 경우
두 가설 중 어느 것이 맞는지 확인하려면 크래시 당시의 상황을 재현해야 합니다. 몇 가지 세부 사항을 덧붙이자면, 해당 머신은 Windows 7이 설치된 시스템으로, EMET 외에는 별도의 보안 소프트웨어가 없었고, TrueCrypt 컨테이너가 마운트된 상태였습니다. 이 점이 중요한 이유는 TrueCrypt 역시 스토리지 계층 드라이버를 사용하는 소프트웨어이므로 결과에 영향을 줄 수 있기 때문입니다.
두 번째 스캔을 실행해 보았지만, 이번에는 TrueCrypt 컨테이너가 마운트된 상태임에도 시스템 크래시가 발생하지 않았습니다. 다만 이벤트 로그에 Event ID 11이라는 오류가 기록되어 있었습니다.
The driver detected a controller error on \Device\Ide\IdePort1.
(드라이버가 \Device\Ide\IdePort1에서 컨트롤러 오류를 감지했습니다.)
필자는 이런 유형의 오류를 본 적이 없었고, MBAM 스캔과의 시점상 연관성도 흥미로웠습니다. 이제 추가 정보를 확보했으니, 조사의 다음 단계를 결정해야 했습니다.
컨트롤러 오류의 의미
이 특정 오류를 검색하면 같은 질문을 던지는 수많은 게시글을 찾을 수 있습니다. 결국 문제는 세 가지 주요 원인으로 귀결됩니다. 손상된 SATA 케이블, 고장난 디스크, 혹은 칩셋 컨트롤러 문제(사실상 새 메인보드가 필요하다는 의미). 꽤 불길하게 들립니다. 그런데 문제는 오직 MBAM 스캔 중에만 나타났습니다. 이 시점에서 우리는 일회성 사건인지, 아니면 시스템 전반의 문제인지 판별해야 했습니다.
분석 2단계: 시스템 상태 점검
필자는 하드웨어 검사를 포함해 여러 수준에서 머신의 상태를 점검하기로 했습니다. 단, 어느 검사도 100% 확실하지 않다는 점에 유의하세요. 특정 검사가 깨끗하게 통과되더라도 기술적으로는 다음 날 하드웨어가 죽을 수 있습니다. 따라서 이런 검사에 안도나 보장을 구할 수는 없습니다. 이 검사들이 말해주는 것은 최선의 경우 '현재로서는 더 넓은 문제를 시사하는 증상이 없다'는 사실뿐입니다.
- 디스크 SMART 검사 — 깨끗함
- WD Data Lifeguard Diagnostics 검사 — 깨끗함
- 위 문제 외에는 시스템이 완전히 안정적으로 작동함
- 사건 이후 일주일이 지난 시점까지 다른 어떤 문제도 전혀 발생하지 않음
뭔가 조치를 취하고 싶은 마음이 들었지만, 필자는 아무것도 건드리지 않고 컴퓨터를 일주일 내내 가동하기로 했습니다. 여기에는 대량의 IO를 유발하는 게임, 데이터 백업, 시스템 이미징, 윈도우 업데이트 등 부하가 큰 작업들도 포함되었습니다. 모든 잠재적 테스트에서 시스템은 몇 달, 몇 년 전과 동일하게 예측 가능한 방식으로 작동했습니다.
이 시점에서 필자는 하드웨어에 즉각적인 건강 문제가 없다고 판단했습니다(일시적 통계나 미신은 차치하더라도). 이로 인해 문제의 원인이 MBAM이라는 결론에 도달했고, 이는 '절대 윈도우 자체가 크래시되는 것이 아니라, 언제나 다른 무언가가 원인'이라는 필자의 경험과도 잘 부합합니다.
MBAM 추가 조사
이제 초점을 이 보안 소프트웨어로 옮깁니다. 온라인에서 검색해 보면 끝없는 게시글을 찾을 수 있으며, 반복적으로 등장하는 주요 주제는 다음과 같습니다. a) 악성코드 문제(당연한 얘기죠. 보안 소프트웨어 실행을 방해하고 이런 유형의 크래시를 일으키는 일부 트로이 목마 포함), b) MBAM 3는 크래시를 일으키지만 MBAM 2는 그렇지 않았다는 사용자들의 주장, c) TrueCrypt와의 비호환성이 BSOD로 이어질 수 있다는 의견.
필자는 이 가설들을 직접 검증해 보기로 했습니다. 먼저 c)에 대해 말씀드리면, 한때 문제가 됐을 수는 있지만 지금은 분명히 그렇지 않습니다. 필자의 경험상 항상 TrueCrypt 볼륨을 마운트해 왔으며, 이전에 크래시를 유발한 적은 한 번도 없었습니다.
a)에 관해서는 말도 안 되는 소리지만, 몇 가지 빠른 권고 사항을 따라 해보며 확인해 보았습니다. 물론 전부 근거가 없었습니다. 게다가 MBAM은 후속 스캔에서 BSOD 없이 완료했지만, 여전히 해당 컨트롤러 오류가 발생했는데, 이는 문제를 소프트웨어 쪽으로 좁혀주는 단서였습니다.
MBAM + Event ID 11의 연관성
이제야 진정으로 관련 정보를 검색할 수 있게 되었습니다. 공식 포럼에는 소수의 게시글만 존재했고, 그 내용은 필자의 사례와 매우 유사했습니다. 몇몇 사용자가 크래시를 겪었고, 그 원인이 MBAM과 Intel Rapid Storage Technology(RST) 드라이버 간의 충돌임을 밝혀낸 것이죠. 오호! 필자는 지원되는 최신 드라이버를 설치하고 재부팅했습니다. 그 과정에서 몇 가지 사실을 발견했습니다.
- 드라이브 문자가 엉망이 되어 올바르게 다시 할당해야 했습니다.
- 케이스의 디스크 LED가 SATA 링크 전원 관리를 활성화하지 않은 상태에서도 예전보다 덜 깜빡였습니다. 단순한 착시일 수도 있고, 실제로 디스크 폴링 활동이 줄어든 것일 수도 있습니다. 시스템 지표에는 큰 차이가 없었습니다.
- 새 드라이버 덕분에 아주 미세한 성능 향상이 있었습니다.
그리고 새롭게 MBAM 스캔을 실행했더니, 이번에는 아무 문제 없이 완료되었습니다. 이벤트 로그에도 오류가 전혀 기록되지 않았습니다. 결국 이는 타사 소프트웨어가 유발한 문제였으며, 마이크로소프트의 잘못도, 하드웨어 문제도 아니었던 셈입니다. 참고로 다른 MBAM 사용자들은 MBAM 버전 업그레이드 이후 문제가 사라졌다고 보고하기도 했습니다.
분명히 말씀드리면, 확인할 수 있는 범위 내에서 이 오류는 윈도우나 기반 플랫폼이 원인이 아닙니다. 다만 사용자가 이를 직접 판별하는 것은 사실상 불가능합니다. 예전 데스크톱에서는 SMART 데이터가 완벽하게 깨끗했던 디스크가 사전 경고 없이 사망했던 반면, 치명적 문제가 있다며 곧 죽을 것으로 예상됐던 또 다른 디스크는 오류 발생 이후에도 수개월간 멀쩡히 생존했으니까요. 통계는 통계가 당신에게 불리해질 때까지는 잘 들어맞습니다.
하지만 현실적으로, 바로 그 순간 그곳에서는 100% MBAM 문제였고 하드웨어와는 무관했습니다. 저수준 시스템 권한을 가진 보안 스캐너와 스토리지 드라이버 간의 충돌입니다. 그렇다면 왜 이런 일이 벌어진 걸까요?
과연, 왜?
MBAM 소스 코드에 접근할 수 없다면 확실히 알 수 없지만, 필자에게 하나의 이론이 있습니다. 악성코드는 때때로 각종 교묘한 방식으로 디스크에 자신을 숨기려 합니다. 그중 하나는 시스템이 가짜 I/O 드라이버를 사용하도록 강제하여 깨끗한 디스크로 보고하게 만드는 것입니다. 이는 악성코드 스캐너가 시스템 함수가 반환하는 값이 참값이라고 신뢰할 수 없다는 의미가 됩니다.
필자가 생각하기에 MBAM은 컨트롤러 명령은 물론 자체적인 seek, read, unlink 등의 시스템 콜과 함수를 포함한 자체 디스크 접근 함수를 구현하고 있는 것 같습니다. 어떤 이유로 이 명령 중 하나가 Intel RST와 충돌하여 I/O 오류를 유발했고, 시스템은 이를 컨트롤러 오류로 해석했습니다. 그래서 BSOD 혹은 시스템 이벤트가 발생한 것이죠. 이것은 어디까지나 필자의 이론이며 틀릴 수도 있지만, 나름 일리가 있습니다.
더 읽어볼 거리
시스템이 실패하지 않으리라고 장담할 수는 없기 때문에, 오히려 실패를 계획해야 합니다. 다시 말해 고통스러운 순간들을 받아들이고, 그런 순간이 닥쳤을 때 최소한의 손실로 빠르게 복구할 수 있도록 준비하는 것이죠. 예컨대 필자는 최소 2~3개의 새 하드 디스크를 포함한 예비 하드웨어를 항상 상비해 둡니다.
또한 성실히 데이터를 백업하고 시스템 이미지를 생성하므로, 하드웨어를 교체해야 하는 상황이 와도 빠르게 업무로 복귀할 수 있습니다. 실제로 몇 달 전, 다른 데스크톱에서 갑작스러운 디스크 고장을 직면했지만 문제없었습니다. 약 1시간 만에 데이터 손실이나 시스템 설정 변경 없이 다시 정상 작동 상태로 돌아왔습니다.
마지막으로, 문제 해결은 어떻게 체계적으로 수행해야 하는지에 대해 이야기했습니다. 이것이 바로 트러블슈팅의 본질입니다. 특히 하드웨어 및 소프트웨어 문제에서 그렇습니다. 올바르게 접근하면 실수할 가능성이 줄어들어 시간과 비용을 절약할 수 있습니다. 무작정 이것저것 바꿔보는 접근은 결코 좋은 생각이 아니며, 이 주제만으로도 필자는 한 권의 책을 쓸 정도입니다.
결론
이번 사건은 여러 요소가 얽힌 까다롭고 복잡한 문제였습니다. 한 시점에서는 여러 방면의 하드웨어 문제 가능성, TrueCrypt, 악성코드, 소프트웨어 버그가 모두 후보로 경쟁했습니다. 이를 해결하는 것은 결코 쉽지 않았습니다. 그럼에도 불구하고 느리고 신중한 작업을 통해 문제를 완전히 이해하고, 근본 원인을 분리해내며, 주장들을 검증하고, 잠재적 해결책을 테스트할 수 있었습니다. 그것도 극단적인 시스템 변경 없이 말입니다.
이것은 소중한 교훈이라고 생각합니다. 필자에게 일어난 일이지만, 여러분께서는 그 결과물을 가져가셨으면 합니다. 나쁜 일이 발생하면 인터넷은 쓰레기 같은 정보를 쏟아낼 것입니다. 하드웨어 문제든, 악성코드든, 마음에 드는 걸 고르세요. 모두가 여러분과 같은 문제를 겪었다고 주장하지만, 실제로는 조금씩 달라서 그대로 적용하기 어렵습니다. 이런 식으로는 미쳐버릴 수 있습니다. 남들이 한 시도를 따라 하고 싶은 유혹이 강하겠지만, 최선의 방법은 증상을 아주 신중하게 살피고 철저히 분석한 뒤, 가장 단순하고 침습성이 낮은 것부터 시작해 되돌릴 수 있고 완전히 정량화 가능한 수정을 적용하는 것입니다.
바로 이 방식으로 우리는 이 문제를 다루었습니다. 무슨 일이 있었는지 아는가? 재현할 수 있는가? 새로 얻은 정보가 말이 되는가? 가능한 원인들을 검증할 수 있는가? 일부를 배제할 수 있는가? 남은 원인들로 새로운 검색 라운드를 돌립니다. 새로운 주장, 새로운 가설, 새로운 검증. 명확하고 재현 가능한 결과. 해결. 지식. 그리고 즐거움. 이 글이 도움이 되기를 바랍니다. 윈도우를 탓하지 마시고, 여러분의 하드웨어에 대해 인터넷이 말하는 것에는 회의적인 태도를 유지하세요. 모든 것이 재앙처럼 들리지만, 반드시 그럴 필요는 없습니다. 즐거운 컴퓨팅 되세요.
감사합니다.