Broken Code (window31)

필자 메모 - Dll Injection
강병탁 / window31 (window31@empal.com / www.window31.com)

월간 마이크로소프트웨어 2010년 4월호
("리버싱으로 분석하는 온라인 게임 해킹툴" 4회 - Wall Hack 中)

월핵을 제작하는 데에는 DLL Injection 이 사용된다. 하지만 Dll Injection 은 방법론의 하나일 뿐이지, 그것 자체가 월핵의 동작 구조라고는 할 수 없다. Dll Injection 이 몇 년 전에 비해서는 상당히 자료도 늘어나고 상세한 설명을 인터넷에서 쉽게 볼 수 있다는 점은 반길만한 일이다. 그러나 아쉬운 것은 이렇게 많은 데이터가 넘쳐나는데도, 아직도 상당히 많은 사람들이 DLL Injection 이라는 개념 자체를 잘못 이해하고 있는 것이 아닌가 하는 생각이 든다. 예를 들면 다음과 같은 대화가 이루어진다.

Q : 어떤 방식으로 월핵이 돌아가나요?
A : Dll Injection 을 사용합니다.

이 대화는 대략 다음과 같은 대화로 비유할 수 있지 않을까,

Q : 서울에서 부산까지 어떻게 가실 건가요?
A : 교통 수단을 이용할 겁니다.

Dll Injection 은 수단의 하나일 뿐이지. 그것 자체가 공격기술의 요지는 아니라는 것을 이해했으리라 본다. 특히나 이런 부류의 해킹툴 분석에 있어서는 더욱 그렇다. 보안회사에서 해킹툴 분석 내용으로 컨설팅을 할 때나, 게임회사 내부에서 분석 논의가 오갈 때에 저런 답변을 하는 사람으로 인해 회사나 팀의 이미지를 깎아먹는 일이 생기지 않기를 바란다.

필자 메모 - 네이티브 프로세스 예외
강병탁 / window31 (window31@empal.com / www.window31.com)

월간 마이크로소프트웨어 2009년 5월호
("Bypass AntiVirus" 3회 - 백신을 공격하는 악성코드 中)


네이티브 프로세스를 감염시키는 바이러스는 정말 조심에 조심을 거듭해 치료해야 한다. 네이티브 프로세스를 잘못 건드렸다가는 컴퓨터가 부팅조차 되지 않기 때문이다. 그런데도 아쉽게도 네이티브 프로세스 오진으로 사용자의 컴퓨터를 마비시키는 치명적인 사건이 발생했다는 소식이 아직도 들려온다. 악성코드가 네이티브 프로세스를 건드리는 이유에는 여러 가지가 있겠지만, 그 중 하나는 그 부분을 감염시키면 백신이 건드리기 힘들 것이라는 의도도 포함돼 있다는 것이다. 나를 치료하려다가 이 컴퓨터의 주인에게 오히려 더 큰 원성을 살 것이라는 약삭빠른 계산이다.

안티바이러스 엔진 개발자들은 smss.exe, csrss.exe, lsass.exe, svchost.exe 등 시스템에 반드시 사용되는 프로세스를 치료할 때 삭제할 대상으로 판정돼도 그것을 오진으로 간주, 네이티브 프로세스를 지우는 일만큼은 피할 수 있는 예외를 추가해야 한다. 백신 업데이트 후 컴퓨터 부팅이 되지 않는다는 유저들의 울부짖음은 백신 업체들에게 큰 모욕이자 치명타가 된다.

가상PC 감지
강병탁 / window31 (window31@empal.com / www.window31.com)

월간 마이크로소프트웨어 2009년 4월호
("Bypass AntiVirus" 2회 - 실시간 감시 취약점 中)


바이러스를 분석하기 위해 많은 보안 관계자들은 VMWare나 Virtual PC와 같은 가상 머신을 이용한다. 그런데 몇몇 멀웨어는 현재 자신이 실행된 환경이 가상 환경이라면 활동을 멈추고 즉시 자신을 파괴시킨다. 바이러스가 가상PC에서 로딩됐다는 것은 바이러스 분석가들이 악성코드 분석을 위해 실행했을 것이라고 판단하기 때문이다. 그리고 바이러스를 분석하는 입장에서도 바이너리를 리버스 엔지니어링 해 보기 전에 먼저 한 번 실행부터 시켜보는 것이 일반적이다. 때문에 이런 내부적인 상황을 모르고 가상PC에서 테스트하며 돌아가지 않는 바이러스가 발견된다면 분석을 중단하는 일도 발생한다. 이런 점을 노린 악성코드 제작자들의 의도는 상당히 지능적이라고 볼 수 있다. 따라서 안티바이러스 업무를 하는 사람은 가상PC가 아닌 전용 리얼 테스트 머신을 갖춰야 한다. 또한 악성코드가 가상PC를 어떻게 감지하는지에 대한 스캔 엔진도 별도로 장만하면 더욱 효율적이다. 예를 들어 <리스트 7>과 같은 코드가 있다. 이 코드는 현재 실행된 환경이 VMWare인지 감지한다.

<리스트 7> VMWare 감지 코드
bool IsVMWare() { bool rc = true; __try { __asm { push edx push ecx push ebx mov eax, 'VMXh' mov ebx, 0 mov ecx, 10 // any value but not MAGIC VALUE mov edx, 'VX' // port number in eax, dx // read port. on return EAX returns the VERSION cmp ebx, 'VMXh' // is it a reply from VMWare setz [rc] // set return value pop ebx pop ecx pop edx } } __except(EXCEPTION_EXECUTE_HANDLER) { rc = false; } return rc; }

인터넷의 해외 사이트를 잘 조사하다보면 많은 자료가 있으니 참고하면 좋을 것이다. 해커나 공격자도 우리와 같은 검색 능력을 가진 사람이라 결국 인터넷을 뒤져서 이와 같은 가상PC 감지 코드를 추가해 공격한다. 따라서 이런 유형의 코드를 검색하는 미니 스캔 툴을 개발, 가상PC에서 동작하지 않는 바이러스를 발견했을 때 그 파일에 대해 실행시켜 해당 바이러스가 가상 머신을 감지하는지 아닌지를 확인할 수 있다(패턴이 완전히 일치하지 않을 가능성이 있기에 100% 장담은 못하지만 확실히 도움은 된다). 더 나아가 해당 루틴을 찾아내면 그것을 걷어낸 후 가상PC에서 자유롭게 분석할 수도 있다. 또는 실시간 감시 기능을 무력화시키는 바이러스의 경우는 이런 행위를 할 가능성이 더욱 농후하다. 가상PC에서 바이러스 샘플을 실행한 후 돌아가지 않는 바이러스라고 쉽게 단언하지 않는 내공깊은 분석가가 더 많아졌으면 하는 바람이다.

기존 연재가 끝나기도 해서 얼굴에 철판 한번 쫙 깔고 새연재 광고를 하겠습니다 :p

백신 우회가 주제인 "Bypass AntiVirus" 를 제목으로 3월부터 4회분량으로 나갈 거 같습니다.
어떻게 보면 "나쁜짓"을 공식 소프트웨어 개발 잡지에 싣는 것이 이상해 보일 수도 있겠습니다만
뭐 초삐리들이 살펴보고 바로 써먹을 수 있는 구체적이며 따라하기도 쉬운 나쁜짓을 다룬다거나
특정 회사의 백신에 대해 언급하고 욕하고 뭐 그런 내용이 되진 않을 것 같습니다.
취약점을 살펴보고 대응방법을 고민해보자.. 내용의 수준은 떨어지더라도 뭐 마음만은 거창하게
그렇게 쓰고 있습니다 :p


실전강의실 | Bypass AntiVirus

연재 순서
1회 | 2009. 3 | 바이러스 감지 회피의 원리
2회 | 2009. 4 | 실시간 감시 기능 취약점
3회 | 2009. 5 | 백신을 공격하는 악성코드
4회 | 2009. 6 | 키보드 보안 솔루션 취약점

마소플러스
괜찮아요 - 월간 마소 2009년 3월호
강병탁 / window31@empal.com / www.window31.com

남녀가 사귈 때 서로에게 가장 듣고 싶어하는 말이 무엇일까? 이것에 대한 설문조사 결과를 한 포털에서 본 적이 있는데, 남자 쪽의 결과가 매우 흥미로운 답이 나왔다. 먼저 여자의 경우는 “사랑해” 라는 말이 1위를 차지했다. 자신이 사귀는 남자에게 사랑한다는 말을 가장 듣고 싶어하는 것은 자연스러운 일이고 어찌보면 당연한 설문 결과로도 보인다. 그러나 남자의 경우는 놀랍게도 여자에게 가장 듣고 싶은 말이 “사랑해”가 아닌 “괜찮아요” 였다.

남성의 심리적 결과 해석

여자친구에게 사랑한다는 말보다 괜찮다는 말을 더 듣고 싶어하는 이유는 무엇일까. 그만큼 여자친구에게 잘못을 많이 한다는 것일까, 아니면 남녀관계를 객관적으로 따지고 보았을 때 남자 쪽에서 실수하는 경우가 상대적으로 더 많기 때문인 것일까. 설문에 참가한 이들에게 직접 물어볼 수 없으니 진실을 확인할 순 없지만, 아무튼 “괜찮아요”라는 말을 듣고 싶어한다는 얘기는 본인이 무언가에 쫓기듯 불안한 상태에 있고 상대방에게는 자신에 대한 배려나 위안을 바란다는 해석으로도 생각할 수 있다.

프로젝트 진행시 발생하는 커뮤니케이션 오류

이와 같이 “괜찮아요”를 필요로 하게 되는 경우는 개발 프로젝트를 진행할 때도 유사하게 나타난다. 대형 프로젝트의 경우 여러 사람이 함께 작업하며 진행한다. 프로젝트에는 개발팀이 있으며 영업지원팀, QA팀, 문서작업팀 등여러 팀이 존재한다. 개발팀에서 코드를 작성하여 기능을 구현하면 QA팀에서는 프로그램에 문제가 없는지 다각도의 테스트 진행을 한다. 테스트가 완료되면 문서작업팀에서 프로그램의 매뉴얼 작성과 FAQ 가이드 등에 대한 문서 처리를 하며, 영업지원팀에서는 프로젝트의 진행상황에 대해 고객사와 커뮤니케이션을 담당한다.

이윽고 납기일이 되어 제품이 릴리즈 되고 라이브 서비스가 시작된다. 하지만 프로그램에 문제가 생겨 사용자들은 불편을 겪게 된다. 당장 고치기에도 힘든 수많은 버그가 발생한다. QA팀은 버그 있는 프로그램을 개발한 개발팀을 탓하며, 개발팀은 문제도 사전에 발견해주지 못한 QA팀을 탓하게 된다. 버그가 많은 것도 모자라 고객은 프로그램 사용에 불편함이 많다 혹은 제대로 된 가이드가 없다 불만을 제기하기도 한다. 고객과 커뮤니케이션 하는 영업팀은 매뉴얼을 제대로 만들지 못한 문서작업팀을 원망한다. 문서작업팀에선 고객이 원하는 바를 제대로 전달해 주지 않아서 매뉴얼의 결과가 이렇다는 식으로 영업팀을 책망한다.

효과적 프로젝트 진행을 위한 "괜찮아요"

상황이 이쯤 되면 각 팀에선 문제를 해결할 생각을 하기에 앞서 원인을 남 탓으로 돌리기에 바빠진다. 그리고 많은 일들을 타인에게 미룬다. 직접 나서서 했다가 문제만 일으켜서 책임 쓰기 싫다는 이유로 항상 적당히만 하려 한다. QA팀에선 애매한 모듈에 대해 서로 테스트를 하지 않으려 하고, 개발팀에서는 누구의 코드 때문에 버그가 생겼다며 논쟁한다. 영업팀에서는 고객에게 온 연락을 다른 사람에게 넘기기 일쑤다.

이런 상황에 가장 필요한 것은 빠른 속도의 문제 해결이 아니라, 서로에 대한 배려일 것이다. 그리고 이해심이다. 자신의 잘못을 누군가가 커버해준다면, 그리고 실수를 보완하기 위해 모두 함께 노력해 준다면, 모든 문제는 원활하게 풀리지 않을까 싶다. 아니 설사 풀리지 않는다 하더라도 더 이상 나빠지는 사태만은 방지할 수 있지 않을까. 그렇다면 이 같은 배려심과 이해심을 표출시킬 수 있는 방법을 생각해 보자. 그 방법은 단 한마디로 말로 시작할 수 있다. 그것이 바로 “괜찮아요” 라는 표현이다. 다른 사람이 만든 실수지만 그래도 어떤 관점에서 보면 누구 한사람의 잘못이라고 꼬집일 수 없는 현재의 프로젝트 상황. 이 프로젝트의 일원들에게 설문조사를 하여 서로에게 가장 듣고 싶은 말이 무엇인지 알아본다면 아마 괜찮다는 말 한마디가 가장 높은 표를 얻지 않을까.

비록 개발팀의 실수 코드로 인해 버그가 탄생했더라도 QA팀에서 괜찮다고 말해주는 이해심, 그리고 테스트 단계에서 충분히 발견할 수 있는 문제가 그대로 릴리즈되어 고객사에게 일일히 해명하러 다니는 영업지원팀도 그정도는 괜찮다고 말해줄 수 있는 배려. 이런것이 바로 누군가와 같이 공동으로 진행하는 프로젝트에서 가장 중요한 것의 하나가 아닐까 한다.

하지만 “괜찮아요”라는 말을 듣고 싶은 대상은 어쨌든 문제를 더 많이 일으킨 입장일 것이다. 그리고 목이 말라서 우물을 파고 싶어하는 더 아쉬운 쪽이다. 남녀 관계도 어찌보면 두 사람이 진행하는 하나의 인생 프로젝트라 할 수 있다. 따라서 남자 쪽에서 “괜찮아요”를 더 많이 듣고 싶은 사람은 먼저 나서서 사랑한다는 표현을 써보라고 권하고 싶다. 마찬가지로 프로젝트 진행중 “괜찮아요” 라는 말을 듣고 싶은 개발자들은 먼저 자신이 그 말을 건네며 이해심을 베풀어 보는 것은 어떨까 한다. 그런 한마디 한마디로 인해 프로젝트에 밝은 분위기가 피어날 수 있고, 마치 베토벤 바이러스에 감염된 음악인들 처럼 배려심 바이러스가 구성원 사이 내부로 전파되어 프로젝트 진행에 더 좋은 결과를 낳을 수도 있지 않을까.

강병탁 / window31 (window31@empal.com / www.window31.com)


월간 마이크로소프트웨어 2008년 12월호
("올리디버거 플러그인의 구조와 원리 3회 - 리버싱 보조 플러그인 中)


리버스 엔지니어링이란 참 묘한 부분이 있다. 수십 시간을 투자해도 결과물이 나오지 않아 스트레스를 받을 때가 있는 반면에 단 몇십분만에 분석이 완료되어 쾌감을 느낄 때가 있다는 양면성 때문이다. 그것은 바이너리가 크고 작고의 문제가 아니며 코드의 양 또한 이유가 되지 못한다. 바로 분석 지점의 정확하고도 탁월한 선택이 어떻느냐에 따라 달라지는 내용이다. 그리고 그것은 분석가를 지치고 괴롭게 하거나 또는 명쾌한 해결이라는 지름길로 안내해 줄 지를 결정하게 된다.

그래서 타겟의 목표 번지 선정이 필요한 것이고 브레이크 포인트라는 개념이 존재한다. 타인이 개발한 프로그램의 소스를 받아 살펴볼 때와 리버스 엔지니어링의 공통점이 바로 그것이다. 내가 아는 부분이나 불필요한 부분, 나의 소스분석의 목적과 관계가 없는 부분은 더듬어갈 필요가 없다. 그리고 그런 부분은 살펴보아봤자 시간낭비가 될 뿐이다. 개발자와 리버서는 늘 시간에 쫓기는 사람들이다. 자신이 원하는 기능과 필요로 하는 내용을 섭렵하기 위해서 정확한 목표 지점을 선정하는 작업은 정말 필수적인 것이다........