Broken Code (window31)

머 대단한 알림거리는 못 되지만 오늘이 생일날이었습니다.
(아 12시가 지났으니 어제 ; )
생일케익에 초를 3개 꽂아놓고 불을 붙혀보니 참 기분 묘하네요....

이번 생일은 걍 조용하고 우울하게 지나가려 했지만
점심때부터 타 팀분이 불러내서 생일이라고 밥도 사주고,
업무시간 중간에 팀원들이 챙겨줘서 조촐한 파뤼도 하고 (남자끼리지만 ;; )
저녁에도 지인들이 자릴 만들어줘서 잘 먹고 잘 놀다 왔습니다.
(돈은 좀 썻다만 ;; 아아 내 이번달 카드값도 100을 넘어갈 것인가 ㅠㅠ)

생일이라는 것이 참 웃긴 것 같습니다.
나라는 인간이 세상에 릴리즈를 했다는 굉장히 기쁜 날이면서도
릴리즈 이후 업그레이드도 없고 안정화도 되지 않아 챙겨주는 사람 없는 경우는
참 우울한 날입니다.

생일이 다가올 때마다 많은 사람들이 이런 생각을 할 것 같습니다
"과연 이번 내 생일은 잘 지낼 수 있을까... 많은 사람이 축하를 해 줄까... 그렇지 않으면 어떡하지"

기쁨 아니면 슬픔이라니,
항상 상반된 이해관계와 흑백논리가 성립하는 명제 같네요.

글쎄.. 아무 생각 없이 "중도"에서 생일을 보내시는 분도 계시겠지만
저의 경우에는 항상 좌 아니면 우 였던 것 같습니다...
올해는 제 인생에 버그가 많아 우울한 생일을 예상했지만
다행히 좋은 생일을 맞이했던 거 같고요.
현재로서는 그점만은 다행이고 고맙게 생각하고 있습니다.

2008년 3월 5일은 경칩 입니다.
제 생일은 항상 경칩을 전후로 있어왔기 때문에 선명하게 기억하고 있습니다.

경칩은 잘 아시다시피 개구리가 겨울잠을 끝내고 밖으로 튀어나온 날이죠.
그리고 하루이틀 정도의 수치적 오류를 감안해서 저도 그맘때가 엄마 뱃속에서 튀어나온 날입니다.
그래서 한때 우울한 생일일때마다 개구리와 제 모습을 오버랩 시키면서
희망과 새시작이라는 유치한 단어로 머리 구석구석을 꾸역꾸역 채워댔죠.
그래서 전 그런말을 좀 싫어했습니다 "무심코 던진돌에 개구리는 뒤져"
희망을 갖고 땅속에서 기어나온 개구리에게 돌을 던지지 맙시다 ;

작년에도 1,2월은 참 좋지 않은 일이 많았는데,
올해에도 1,2월은 버그투성이 인생을 보내오면서 참 많이 힘들었습니다.

하지만 작년에는 3월부터 많은 부분이 개선되었고
2008년 3월에도 그렇게 되어 갔으면 싶네요~
제 생일을 기점으로 그렇게 변해갔으면 하는 바램입니다.

인생을 흑자로 맞이할 수 있는 프로파일링을 진행해야겠죠 :)
오늘 튀어나올 많은 개구리들을 생각하며 인생 여기저기에 인스트럭션 코드를 삽입하고 있습니다.
앞으로 더욱 좋은 일만 가득하고, 여기 오시는 분들도 더 멋진 삶이 될 수 있도록 기원 할께요 :)
생일 축하해 주신 분들께 감사 드립니다 ^^


2008년 3월





ps 오늘 생일에 선물 안사오고 비싼거 시킨 넘들 다 주거써....

드라이버를 분석할 때, 1394디버깅을 할 떄는 머 별로 상관이 없겠지만, 디버깅을 하는 그 순간
말고도 별도로 파일 자체가 필요할 때가  있다. 파일을 디스어셈블링 하던가 hex compare등을
하던가 머 상황은 다양한데, 일반적인 경우는 머 babo.sys 형태로 파일이 current 폴더 혹은 driver
폴더에 있을텐데 뭐가 문제냐 하겠지만, 요즘은 드라이버를 올린 후에 지워버리는 것이 또 하나의
추세라 (물론 FILEMON 등은 예전부터 그렇게 하긴 했지만) 그렇게 하는 넘들에게 드라이버
파일을 뽑아내기가 쉽지 않을 때가 있다.

어쨌든 그래도 적어도 드라이버가 올라가는 타이밍을 알고 있다면 나름 획득하는 꽁수가 있다.
하지만 이미 올라가 있는 경우 혹은 언제 올라가는지 알 수 없을 경우 (특히 루트킷 같은 넘들이나
커널모드에서 돌아가는 악성 코드 같은 넘들) 파일을 획득하기가 까다로운 편이다.

하지만 이 때는 커널번지를 그대로 메모리 덤프를 떠 버리는 방법을 쓰면 나름 도움이 된다.
그 방법은? windbg의 .writemem 명령어를 이용한다

먼저 .hh를 통해 헬프 파일을 보자

 

간단하다 .writemem 파일이름 address l 요까지

그럼 한번 직접 덤프를 떠 보자. FileMon의 경우는 드라이버를 올린 뒤 파일을 지워버리니
좋은 마루타가 될 수 있다. 파일몬을 띄워놓고 드라이버 리스트를 출력해 보았다. 메모리상에
드라이버는 올라가 있지만, 실제로 파일은 없기 때문에 리스트 컨트롤에는 0byte로 출력된다.
(TaskInfo에서는 드라이버 이름은 커널번지를 스캔해서 얻지만, 그 파일에 대한 size나 version
등의 세부정보는 파일을 통해서 얻기 때문)

따라서 FILEM.SYS는 이 파일을 로드한 driver 폴더에 가 보아도 파일이 없음은 물론이다. 이넘을
덤프를 떠 보자.


여기가 FILEM.sys가 로드된 커널번지다.

사이즈를 알 수 없으니 무식한 방법을 쓸 수 밖에 없다 :( NEXT를 열심히 눌러서 할당되지 않은
영역까지 가 본다. 거기까지가 FILEM.sys의 영역일 것이다(별로 마음에 들지 않는 방법이다
좀 더 고급스런 방법 없을까요 ㅠㅠ)

요까지다. 그럼 사이즈를 계산해보면,

사이즈는 0x9fff 다. 그러면 그만큼을 덤프를 떠 보자!
c:\에 FILEM_dump.sys 라는 파일로 덤프를 떠 보겠다. windbg의 커멘드창에 다음과 같이
입력하자.

.writemem c:\\FILEM_dump.sys a945c000 l 9FFF

자 이제 C드라이브 루트에 파일이 생겼다. 헤더를 확인해볼까?


흐흐 PE영역이 분석이 잘 된다.

이제 이 파일을 IDA에 넣던, 기존 파일이 있으면 기존 파일과 hex compare를 하던 마음대로
활용하면 된다 :p

단, FILEM.sys의 경우는 ksecdd.sys 를 또 참조하고 있고, 또 이 파일은 메모리 영역을 그대로
덤프 뜬 것이라 ntoskrnl에서 export하고 있는 각종 상대번지와 어드레스 등이 일치하지 않는다.
그래서 함수 콜 부분이 제대로 분석되지 않을 것이다(극복하는 방법은 한번 연구해보세요^^;;)

커널 드라이버도 ImportREC같은 툴이 있다면 좋을 것 같은데 :p

물론 FileMon의 경우는 더 쉬운 드라이버 획득 방법이 있지만 지금은 writemem을 설명하기 위해서
예로 든 것이니 괜한 태클은 걸지 않으길 바란다 (전 주로 악성 코드 분석에 이 방법을 이용합니다)


2007년 5월