Broken Code (window31)

GDC 다녀옵니다

window31 — Tue, 09 Mar 2010 11:07:49 +0900

미국 샌프란시스코에서 하는 GDC 에 3/9~3/15 까지 다녀올 예정입니다.
올해는 운이 좋아서 가게 되었네요.

GDC 는 아시다시피 세계에서 가장 큰 규모로 진행하는 게임 개발자 컨퍼런스입니다.
총 세션이 400개가 넘네요 ;;
저는 bot, cheat, programming 쪽 세션을 위주로 들을 것 같습니다.

발표 리스트입니다.
http://schedule.gdconf.com/

가시는 분들 그쪽에서 뵙겠습니다.

DirectX SDK 새 버전(2010년 2월자) 나왔습니다.

window31 — Sun, 21 Feb 2010 14:28:07 +0900

기본적으로 게임 프로그래밍을 업으로 하시는 분들이 DirectX 를 다루시겠지만,
보안 쪽에서 FPS 월핵 막으시려는 분들도 DirectX 열심히 공부하시길 바랍니다.
무언가 좋은 힌트가 발견될 수도 있겠죠 :)

용량은 약 500메가네요

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=2c7da5fb-ffbb-4af6-8c66-651cbd28ca15

데미다

window31 — Mon, 15 Feb 2010 17:37:09 +0900

제가 직접 찍은 짤방입니다 ㅎ

유형별로 살펴본 보안검수의 실체

window31 — Mon, 18 Jan 2010 22:00:31 +0900

보안검수의 종류를 말할 때, 화이트박스 분석, 그레이박스 분석, 블랙박스 분석 등, 작업 깊이에 따라 색깔로 분류한 정의를 들어보신 적 있으실겁니다. 물론 가장 짙은 색인 블랙박스는 아무래도 정보가 전혀 없는 어두운 공간 안에서 진행한다는 뜻으로 칭해진 의미일거고, 그레이박스에서 화이트박스까지, 색깔이 점점 옅어짐에 따라 박스의 내부를 좀더 자세히 들여다 볼 수 있다는 얘기로 이같은 분류법이 지어진 것 같습니다.

이런 정의를 인터넷에서 흔히 찾아서 나올 수 있는 단순히 용어의 수준에서 그치지 않고 좀더 실무나 실전에 가깝게 정의해서 분석을 실제로 진행하는 검수가의 시각에서 바라보며 제맘대로 한번 작성해 보도록 하겠습니다.

1. Black Box Analysis

데이터와 정보가 아무 것도 없는 채, 일반 유저와 마찬가지 상태에서 보안검수를 하는 것을 말합니다. 정보가 부족한 상태에서 분석을 하는 것이므로 기본적으로는 애플리케이션의 정상적인 가동 상태, 그리고 매우 쉽게 파악 가능한 패턴화 되어 있는 취약점 까지만 진단 가능한 경우가 대부분입니다.

블랙박스 상태에서는 아무래도 개발팀에서 처리한 내용에 대해 어떠한 단서도 얻지 못하는 경우가 많으므로 어떻게 보면 검수 영역에 한계가 있다는 것이 당연하다고 생각할 수 있지만 예외적으로 검수가의 능력에 따라 블랙박스 상태에서도 충분한 데이터를 얻어오는 경우도 있습니다. 하지만 그 경우에는 내부 코드를 해킹이나 리버싱으로 샅샅히 훑어야 하는 작업이 선행되므로 아무래도 시간이 엄청 많이 걸릴 수밖에 없습니다(오리지날 소스를 보거나 아니면 개발자에게 한번 물어보기라도 하면 될 일을 직접 분석하고 있으니 시간이 걸리는 것은 당연할 수밖에).

개인적으로 생각하기에 블랙박스 검수단계는 두가지 타입의 사람이 검수를 한다고 생각합니다.

1) 실력이 아주 뛰어남 (개발팀에게 묻지 않아도 스스로 데이터를 다 캐취해냄)
2) 실력이 아주 보잘 것 없음 (그냥 프로그램을 한번 실행해 보고, “어 별일없군 끝”).

이렇게 극과 극이 존재한다고 생각하며, 첫번째와 두번째 모두 해당되지 않는 “중간 실력”을 보유하고 있는 자는 본인의 한계를 알고 있기 때문에 아예 그레이박스 단계에서 분석을 시작하면 시작했지, 두가지 케이스에는 해당하는 작업은 잘 하지 않는다고 생각합니다. 사실 저라도 그렇습니다. 언제 저걸 일일히 다 하고 있어요 ;;; (물론 예외적으로 직접 다 해야할 때도 있지만 ;; ) 중간 실력자 타입은 무언가의 근거확립이나 브레이크 포인트를 설정한 이후에 검수를 하기 때문에 블랙박스 검수를 할 경우에는 알려진 유형적 취약점 정도만 기계적으로 대입해 보고 그 수준에서 작업을 마무리 하는 것 같습니다.

2. Gray Box Analysis

부분적인 소스 코드나 알고리즘 등 여러 가지 구조나 정보를 사전에 얻고 보안 검수를 진행하는 것을 말합니다. 아무래도 근거나 데이터가 있으므로 블랙박스 상태에서보다는 훨씬 효율적인 보안 검수가 가능하게 되겠죠.

또, 부분적으로 여러 장벽을 제거하거나 불필요한 단계를 거치지 않고 검수를 진행할 수 있습니다. 예를 들어 보안 모듈이나 기타 서드파티 툴이 여러 겹으로 보호하고 있을 때에 블랙박스 상태라면 그것을 검수가 자력으로 걷어낸 상태에서 검수를 하는 등 어쨌든 검수할 있는 형태로 분류시키는 작업을 누군가의 도움 없이 진행해야만 합니다, 하지만 개발팀의 협조가 가능한 그레이박스 단계라면 필요한 코드만 적시적소에 제거한 상태로 검수할 수도 있고, 소스 레벨 단계에서도 여러 가지를 시도해 볼 수도 있습니다. 아주 편리하죠.

다만 여러가지 개발 데이터를 받는 것이기 때문에 검수가의 개발 스펙이 떨어지면 걍 블랙박스 검수를 하느니 보다 못한 꼴이 될 수도 있습니다. 괜히 오바해서 그레이박스 검수를 하다가 개발자와 대화도 되지 않아서 개쪽을 먹기도 합니다. 따라서 개발팀과의 커뮤니케이션이 매우 중요한 단계가 됩니다.

또한 검수가의 경험 역시 중요시된다고 할 수 있습니다. 왜냐하면 개발팀에게 무언가를 받긴 받아야 하는데, 개발팀에서는 어떤 코드나 어떤 부분이 취약한 지 모르기 때문에 사실 검수가에게 뭘 물어봐야 할지 뭐를 주어야 할지도 모르는 경우가 있기 때문입니다. 따라서 검수가가 직접 필요한 데이터나 코드를 개발팀에 요청해야 하는데 당연히 적절한 위치나 코드, 변형된 모듈 등을 선정할 수 있는 실력이 필요하며, 개발팀과 협조하여 진행해 나가야 할 것을 능수능란하게 리드할 수 있어야 합니다.

해킹을 많이 당해본 개발자의 경우 경험 부족이나 능력이 떨어지는 검수가를 이 단계에서 한눈에 알아봅니다. 따라서 당연히 단지 툴 실행이나 얄팍한 테크닉에 의지하고 코드는 거의 볼 줄 모르는 사이비 보안검수가는 이 단계에서부터는 활동할 수 없습니다. 하지만 협력이 잘된다면, 아주 퀄리티 높은 보안 처리가 아웃풋으로 나올 수 있습니다.

3. White Box Analysis

이건 내일 마저 작성 해보겠습니다. 너무 길어져서 몰입력이 떨어질 것 같은 생각이 드네요 :)
제일 할말도 많은 화이트박스 검수 쪽이므로 제대로 다시 마음잡고 한편 작성해 보겠습니다 :p

window31.

병원에 입원중입니다.

window31 — Sun, 17 Jan 2010 15:27:42 +0900

금요일 새벽에 교통사고를 당했습니다.

차를 몰고 가고 있는데, 앞 차 두대가 길을 막고 분쟁중이길래
저도 잠깐 정차해서 그 뒤에 조용히 서있었습니다.
그런데 그걸 보지 못한 뒷차가 제 차를 엄청난 속도로 들이 박았습니다.
제 차의 뒤 트렁크 부분이랑 범퍼 부분은 모두 걸레가 됐고요
저도 충격을 좀 받았네요...

백미러 너머로 차가 돌진해오는 모습을 보며, 멈추겠지 멈추겠지 하며 그러고 있는데
차는 속도를 전혀 줄이지 않은 채 다가오고, 저는 "으어어억- 들이받는구나!" 하던
그 몇초간의 순간이 잊혀지질 않네요 (이런걸 트라우마라고 하나봐요) ...

뭐 어쨌든 입원해 있고, 물리치료 받는 중인데요, 뭐 이참에 좀 쉬지 하는 마음으로
생각해보니 좋은 기회로 삼아도 괜찮겠다 하는 생각도 드네요.

너무 심심해서 이것저것 둘러봤는데, 요즘엔 환자들에게 노트북을 대여해주는 업체도 있네요,
노트북 하루 24시간 9900원 뭐 이런게 있길래 한번 신청했습니다(인터넷은 WIBRO 제공)
전화한지 30분도 되기 전에 배달꾼이 노트북이랑 WIBRO 모뎀을 가져왔는데,

배달꾼 : "오늘 입원하셨다니, 특별히 좋은 노트북으로 가져왔습니다."

그런데 노트북을 살펴본순간 셀러론 2.4 에 메모리는 512MB -_-;
특별히 좋은 노트북인거는 맞네요 -_- 요즘 찾아보기 극히 힘든 노트북일테니 ;;;
다시 가져가라고 할 수도 없고 그사람들도 먹고 살아야 하니 그냥 쓰기로 했습니다.

아흠, 어쨌든 벌려진 업무들을 처리하지 못하고 이렇게 누워 있으려니 걱정이 많이 되네요.
거북이 노트북으로 뭘 하기도 힘들고...
그냥 한번씩 들어와서 바쁘다는 핑계로 너무 오랜기간동안 방치된 블로그에 글이나 간간히
써 보도록 하겠습니다.

커널에서 하는 것이 만능인가?

window31 — Mon, 28 Dec 2009 00:38:08 +0900

이달 초에 KOSR 세미나에 다녀왔습니다(생각해보니 한참 됐군요-_-). 발표자님께
오랫만에 인사도 하고 아는 사람들에게 간만에 얼굴도 비추고, 그런 부수적인 목적 외에
구경간 발표 자체도 꽤 깔끔하고 위트있게 진행된 터라 그럭저럭 재미있게 시간 보내고
왔습니다.

발표를 듣던 도중 키보드 보안 얘기가 나와서 중간에 많은 생각을 하게 되었습니다.
한때 키보드보안 개발회사에서 가장 괴로워 하던(귀찮아 하던... 분도 계셨구요) 쪽이
키보드 폴링을 이용한 키로깅에 대한 대응방안입니다. 여러 보안회사의 대책이
있었겠지만 사실 A 사의 대응방안이 예전부터 많이 흥미로웠습니다.

A 회사가 사용한 방법은 키보드 폴링 자체를 커널에서 원천적으로 제어할 수는
없다고 보고, 일단 키를 보내주되 다른 랜덤한 키와 섞고, 애플리케이션 단에서
그 랜덤한 키를 제외해주는 기법입니다(특허 문서에도 있으니 뭐 공개해도 괜찮겠죠).
사실 A 사의 대응방안에 대해 예전부터 여러가지 생각이 맴돌았지만, 커널 세미나를
하는 자리라는 점을 생각해 보면 기분이 더욱 묘했습니다.

왜냐하면 어쨌든 폴링에 대해서는 그냥 상식으로 생각하기에 커널 공격은 커널로
답을 찾을 것이다 라고 생각한 적이 있었거든요. 하지만 어쨌든 유저 레벨을 혼용한
방법으로 대응방법을 만든겁니다. 이 부분이 뭐가 문제냐고요, 이런 얘기가 있습니다.
"커널을 하는 사람들은 커널만이 최강인줄 안다. " 보안 쪽에서 일하거나 보안 쪽
공부를 하시는 분들 중에서는 이런 사람들 많이 보셨을 겁니다. 뭐 전혀 틀린 얘기는
아니지만 완전히 맞는 얘기도 아니라고 생각합니다.

보안쟁이들이 알고 있는 기존 상식 그리고, 비공식/공식적인 보안의 커리큘럼에는
항상 근원적으로는 커널에서 방어해야 하며, 그렇지 않고 유저에서만 버티고 서있는
것은 전혀 소용이 없다는 말을 합니다. 하지만 이 말은 완전히 정답이 아닙니다.
왜냐하면 굳이 커널로 내려가지 않더라도 유저 레벨에서 제어할 수 있는 내용이
생각보다 아주 많기 때문입니다. 조금 전 언급한 폴링 쪽도 그렇고요 생각 외로
native hooking 쪽도 그런 부분이 있습니다. 회사 업무라서 자세히 말은 못하겠고
(해외의 몇몇 rootkit detector 들은 ring3 mode 에서도 독특한 방식으로 rootkit 을
훌륭하게 잡아냅니다... 힌트는 여기까지....;; )

커널에서 대부분의 핵심 처리를 하는 두번째 문제점으로는, 커널에서 보호하는 양을
늘려가면 늘려갈 수록 그만큼 취약점이 증가하게 된다는 것입니다.

이 얘기는 무슨 의미냐 하면, 애플리케이션 레벨은 아무래도 영역이 방대하지만
커널 쪽은 상대적으로 코드 량도 적고, 현재 알려진 보호 영역이나 공격의 대상이
될만한 구간이 어느 정도 정해져 있기 때문입니다. 따라서 공격자가 커널 지식에
능하고, 보안 모듈 개발자가 기존 지식에 잘 길들여진 시스템 프로그래머라면,
커널에서 보호하고 있을 위치를 예상해 보는 것은 그렇게 어렵지 않습니다.

실제로 많은 사람들이 깨고 싶어하는 게임보안 솔루션이 가장 많은 공격을 당하면서
취약한 부분도 커널 부분이고, 유저 레벨에서 보호하는 부분은 오히려 훨씬 더
견고합니다 (물론 두 부분을 융합시키지 못한 미보완 상태의 구간도 많긴하지만요 ;; )

"커널만이 최고다" 라는 사람은 오히려 이제 막 커널을 시작한 쪼렙들에게 많이 봤습니다.
하지만 유저 레벨에서 충분한 보완이 된다면, 굳이 불안스러운 커널로 내려갈 필요가
있을까요? 또한 오버스러운 또는 초보스러운 커널 개발자의 경우 유저에서 해도 될
일을 일부러 커널로 내려가서 하는 경우도 있는데 그런 오버액션을 해야 될 필요도
있을까요?

보안 코드를 개발하는 우리는 "강력한" 프로그램을 만드는 것도 중요하지만
"안전한" 프로그램을 만드는 것 또한 잊어서는 안 될 내용이라고 생각합니다.
물론 커널로 만드는 것도 언젠가는 안전한 코드가 될 때가 올거고, 유저에서 하는 것
이상으로 안정한 상태로 돌아갈 수도 있습니다. 하지만 그런 날이 올때까지 피해를
보는 것은 개발자의 PC 일까요, 아니면 왜 블루가 나는지 알지도 못한채 계속
고객센터에 불이나도록 전화를 할 유저 PC 일까요? 또, 아무리 내가 안전하게
프로그래밍 하였다 하더라도 공공장소인 커널 공간에서 다른 모듈의 불안정한
후킹으로 인해 블루가 발생할 날이 반드시 오지 않는다고 보장할 수 있을까요.

물론 커널에서만 할 수 있는것은 당연히 커널에서 해야 한다고 생각합니다.
하지만 유저에서 해도 될 일을 굳이 커널에서 하고 있는 커널 만능주의 개발자들이
늘어나는 것을 막지 않는다면 아무리 드라이버 사이닝 제도가 버티고 서있다 하더라도
보안성이 점점 높아지는 각종 모듈 덕에 유저들 PC 에서 발생되는 블루스크린은
줄어들 것 같지 않을 거라는 생각이 듭니다.

window31.

ps. "커널에서만 할 수 있는것은 물론 당연히 커널에서 해야 한다"고 했습니다.
초딩들의 이상한 태클 댁글이나 이메일은 사절합니다 -_-;

GameHi 보안팀 인력 모집

window31 — Mon, 07 Dec 2009 13:17:40 +0900

서든어택, 데카론으로 유명한 GameHi 의 보안팀에서 인력을 모집 중에 있습니다.
게임 해킹에 관심 있으신 분들은 지원하시면 좋을 것 같습니다 :)
(스펙은 리버싱 + 게임보안 모듈 개발)

1. 모집내용

- 해당직무 : 게임클라이언트 모의해킹 / 보안 모듈 개발 / 보안 기술 지원
- 채용구분 : 신입/경력 (정규직)
- 채용인원 : 0명
- 근무지 : 게임하이(주) 보안팀 근무

2. 업무사항

- 게임 클라이언트 모의 해킹 및 취약점 분석
- 게임 보안 모듈 개발
- 게임 보안 프로그램 기술 지원

3. 지원자격

게임과 보안에 관심과 열정을 가지신 분

[우대사항]

- 보안 프로그래밍(WinAPI, MFC, C/C++, 어셈블리어) 가능하신 분
- 국내외 해킹 관련 대회 입상자
- 보안 관련 업체나 동종 업계 근무자

지원은 잡코리아를 통해서 하시면 됩니다 :)
http://www.jobkorea.co.kr/List_GI/GIB_Read.asp?GI_No=5780683

KOSR 드라이버 세미나

window31 — Wed, 25 Nov 2009 20:40:51 +0900

KOSR 에서 31차 정기세미나를 진행합니다.

이번에는 WDF 를 번역하신 최장욱님께서 진행하시네요.
(최근에는 Windows Internals 5th 도 번역하고 있군요 ;;; )

http://www.kosr.org/Contents/Lecture/SeminarContent.aspx?ser_no=33&page=1&mode=1&cls_cj=1&cls_cd=5&searchType=&searchKey=

아무래도 강사님께서 키보드 보안 드라이버 개발 경력이 깊기 때문에
그냥 키로거도 아닌 커널 키로거에 대한 이야기가 나올 것 같네요 :)

개인적인 생각이지만 애플리케이션 키로거는 그간 악성코드 분석자료나
기타 보안 세미나에서는 많이 등장했지만, 커널 키로거에 대한 분석내용을
세미나에서 볼 수 있는 모습은 극히 진귀한 광경이 아닐까 합니다 :)

물론 그 밖의 Windows 7 드라이버 개발이나, 기타 여러가지 TIP 등을 알 수 있겠네요-

이 분 최근에는 ㈜볼트마이크로(http://www.vaultmicro.com/) 라는
드라이버 개발 전문 회사를 차리셨습니다. 애도 있으면서 이런 도전적인 모습을 보여주다니 ㅎ!!
암튼 화이팅이고요, 간만에 잼잇는 세미나가 또 될 것 같습니다 :)

제13회 해킹방지워크샵 2009

window31 — Sun, 15 Nov 2009 23:06:46 +0900

13회 해킹방지워크샵, CONCERT 2009 때 발표를 하게 되었습니다.
주제는 "게임 개발사와 퍼블리셔를 위한 온라인 게임 보안 활성화 방법" 입니다.
아래 웹페이지에 나온 주제는 그냥 "온라인 게임보안 활성화 방법" 으로 표시되었네요.
제목이 확정되기 전에 페이지가 만들어졌는데,, 뭐 나중에 바꾸기도 뭣해서 그냥 뒀습니다.

http://concert.or.kr/suf2009/program/program.php

기존에 게임보안 세미나 하면 특정 제품 홍보나 아니면 호랑이가 담배먹던 시절의 기술에 대해서만
논하는 경우가 많았기에 그런 쪽과는 좀 다르게 내용을 꾸며보려고 했고요 (아무래도 게임보안
솔루션 개발사들은 기술 공개나 노하우, 경험 공개에 대해서 배타적인 회사도 있죠) 솔루션에
의지하는 것 보다는 게임 회사 입장에서 생각하는 게임보안에 대해서 하나씩 준비를 해봤습니다
(잘 아시겠지만, 여기서 말하는 게임보안은, 계정 해킹이나 침해사고 대응, 시스템 보안의 얘기가
아닙니다)

아래 부분은 목차입니다. 발표 자료는 아마 CONCERT 를 통해서 배포될 것 같습니다

1. 현재의 게임 해킹 대응 플랫폼의 문제점
2. 최근 게임 해킹툴 동향
3. 자체 로직보완
4. 자동사냥/매크로 대응
5. 오픈전 내부 보안검수
6. 게임 클라이언트 패킹 이슈
7. 게임보안 솔루션 선택시 생각해야 할 점
8. 해킹툴 차단 컨셉 변경
9. 법무팀과의 협업
A. 해킹툴 제작 사이트 모니터링
B. 마무리

등록비가 좀 비싸서, 회원사 아닌 분들에게는 와달라고 말씀을 드리지는 못하겠네요 ;;;
그럼 혹시 오시는 분들 콘서트 때 뵙겠습니다 (아는척 한번만 해주세요 :) )

window31.

Win32.Trojan.Pasta. 오진

window31 — Fri, 13 Nov 2009 20:49:16 +0900

어제오늘 Win32.Trojan.Pasta 오진 때문에 아주 홍역을 치뤘습니다.
우리 모듈과 구조가 비슷한 악성코드를 최근에 백신이 수집했고
그 패턴을 xx 같이 했나보군요 -_-;

모두 똑같은 파일입니다.

F-Secure 오진

Kaspersky 오진

AntiVir 오진

Kisv9Plus 오진

(Avast 는 화면캡쳐 생략)

오진 발생 리포트 시간을 보면, 시간차가 좀 있던데
해당 백신이 샘플을 언제 수집했고, 그 샘플을 언제 패턴업데이트 했느냐의 차이인 것 같습니다.
아무래도 Kaspersky 와 F-Secure 가 가장 빠르네요 (유저의 분포도 차이 일수도?)

Kaspersky 와 F-Secure 가 오진을 내고, 오진을 해결해주고 한 후에야
Avast, AntiVir, Kisv9Plus 등에서 그제서야 오진을 내기 시작하네요
샘플 수집 + 대응속도 의 뭐 종합 평가가 된 듯 싶습니다.

암튼 머 그건 그건데,,,, 백신들 진짜....-_- 스트레스를 부르네요.
게임보안 솔루션은 오진을 내면 고객들이 항의라도 하지, 백신은 오진내면 뭐 그냥 별 기색도 없이
"다음 패치때 풀어줄께" 또는 대답도 없는 시츄에이션을 보면, 어떻게 하라는 걸까요?

(오진을 해결해 달라고 연락을 했더니, 당신네는 우리 회사의 백신을 정식으로 구매한 고객이
아니기 때문에 오진 처리 요청을 우리 직원을 통해서 하지 말아달라는 얘기를 하는 회사도
있었습니다. 뭐 공개적인 자리라서 어느 백신사인지 얘기는 못 하겠네요 -_-)

window31.