Broken Code (window31)

팀장의 가치 2부입니다.
댓글이 거의 올라오지 않을 것으로 예상했습니다만, 예상과는 다르게 2개의 댓글이
올라왔습니다. 하지만 모두 비공개군요 ㅎㅎㅎ 약간 민감한 내용이다보니 댓글을
함부로 남겼다가는 엄한 뉘앙스를 풍길 수 있으므로 역시 아예 안 쓰거나 비공개로
남기신 거 같습니다. 좋습니다. 더욱 많은 비공개 코멘트를 부탁 드릴께여 :p


4) 책임은 팀장이 지는거다. 팀원들에게 뒤집어 씌우지 마라.

어느 회사나 업무를 하다가 장애나 사고, 문제가 발생하게 되죠. 머 사람이 일을 하다보면
로봇이 아닌지라 실수나 문제가 있게 됩니다. 문제는 사회에서의 일이라 누군가는 그에 대한
책임을 져야 하는데, 여기서 쓰레기같은 팀장은 그 책임을 팀원에게 뒤집어 씌운다는 것입니다.

물론 그 문제의 업무를 팀원이 한 경우도 있습니다. 하지만 제 생각에 장애가 큰 건이고
팀장이 총괄적인 위치에 있다면 포괄적으로 책임은 팀장이 져야 하는게 아닐까 하는
생각이 듭니다. 전직장에서 여러 서비스업체에 대형사고가 난 적이 있습니다. 고객사에
다량으로 장애보고서를 제출하고 난리도 아니었죠. 그때 책임자 칸에 누군가의 이름을
써야 하는데, 그게 누구 한사람의 잘못이 아니라서 서로 자기이름을 쓰기 꺼려하더라고요

머 거기까지는 이해가 됩니다. 그런데 각 팀의 팀장들까지도 그런 졸렬한 모습을 보이는
모습에서 사실 전 약간 환멸감을 느꼈습니다. 서로 자기 이름 빼려고 하는 모습이 참 웃기지도
않더라고요, 그래서 전 그랬습니다. 쓸 사람 없으면 다 내이름 쓰라고. 그까짓거 거기 자기이름
석자 기록하는게 뭐가 무섭냐고 그냥 너무 황당하고 어이없어서 그런거지만 지금 생각해보면
미친짓이었죠 ㅋㅋㅋ 그거 참 무서운 겁니다 ㅎ

농담이고 좀 다른 각도의 예를 들어보자면, 팀원이 사고를 쳤을때 평소엔 그 팀원이 무슨일을
하고 있는지 어떤 애로사항이 있었는지 막상 그 일을 할땐 전혀 신경도 안써주고 있었으면서
"이번건은 니 책임으로 한다" 라고 말하는 경우도 있습니다. 눈물 나죠 ㅎㅎ (절대 제 얘기
아닙니다 ㅋㅋㅋㅋㅋ) 뭐 이런 예들 말고도 많습니다. 팀장들이 팀원에게 뒤집어 씌우는
일화들은 참으로 다양하죠. 윗 분들에게도 그렇게 보고하죠 "그친구가 좀 잔실수가 많아서요
하지만 이번에 제가 잘 타일렀으니 다시 같은 실수는 안할겁니다" 위선자....

팀장이라는 위치는 업무 지시 외에도 팀원들의 방패막이 되어주는 위치이기도 합니다.
물론 그것이 팀원의 모든 ㅄ짓을 다 커버해주라는 의미는 아닙니다. 다만 팀원이 어떠한
업무를 처리할 때 특히 과감함과 용기가 필요한 부분에 있어서는 "그래 울 팀장님이 계시니까"
하는 팀장을 믿고 일어설만한 포스를 보여줘야 한다는 겁니다. 그래야 업무의 질과 생산성도
더욱 더 높아지고 효율적인 연구를 할 수 있습니다. 그게 아니라면 책임 쓰기 무서워서
항상 중간만 가는 일만 하게 되겠죠. "니들이 일을 정말 열심히 하고 똑바로 했는데도 사고가
발생했다, 그러면 그건 내가 책임진다" 라고 말해주는 그런 팀장님 정말 멋집니다.


5) 좀 사줘라

이번엔 약간 가벼운 주제입니다. 짠돌이 팀장... 정말 만쵸. 사실 팀장쯤 되면 좀 애들 맛있는
것도 한번씩 사주고 쏘고 그래야 되는 면이 필요합니다. "이거 쏜다고 해서 나에게 무슨
보답이 돌아오는가?" 라고 생각하시는 팀장님들? 걍 평생 주글때까지 남 밑에만 있으십쇼.
평생 팀원으로만 계신다면 대가 없이 쏘지 않아도 됩니다.

생각외로 짠돌이 팀장님 졸라 많습니다. 머 비싼것도 아닌데 애들한테 몇천원씩 걷는 모습을
보면 참 경악스럽기도 한답니다. 회식이라고 억지로 오게 했으면서 그걸 돈을 걷어서 지불하는
초특급 울트라 킹왕짱 팀장님도 계신답니다. 참 어이가 없죠? 팀장쯤 되면 팀원들에게 한번씩
사주는게 그것도 기본 자질입니다. 머 연봉 차이가 얼마나 나는지는 모르겠지만 일단 팀원들보단
많이 받지 않습니까. 근데 머 연봉이고 자시고를 떠나서 자기 팀의 사람들인데 밤늦게까지
일하거나 무언가 대견한 내용을 처리했을때 훌륭하고 자랑스럽지 않을까요. 아이스크림 하나를
사주더라도 그건 정말 멋진 모습입니다. 저는 다행히 아직 짠돌이 팀장님은 만나본 적은 없습니다.
그러나 돈 걷어서 회식한다는 얘길 들으면 참 추하다고 느껴지네요. 회사에서 돈이 안나오더라도
적어도 회식비 정도는 자기가 충당해야 하는거 아닐까요. 아니면 회식을 하지 말던가요.

6) 애들이 상태가 삘릴리하면 눈치 좀 채줘라

IT회사만 그런지는 모르겠지만 대부분의 팀들이 늦게까지 일을 하죠. 그러다보면 사실 아무리
재밌고 성취감 있는 일이더라도 어느 순간에는 개지치게 됩니다. 그리고 그것이 업무 때문에
지칠수도 있지만, 팀원들 사이의 사람 관계 때문에 힘들어 할 수도 있죠. 혹은 회사와 상관없이
집안일이나, 돈 문제나 연애 문제 머 그런것으로 심신이 엉망이 되는 경우도 있습니다.

팀장이면 자기 팀원의 대충의 상태 정도는 알아둬야 한다고 생각합니다. 업무적으로 문제가
있다면 더더욱이 애가 갑자기 왜그러나 생각을 해볼 필요가 있고요, 업무 외 내용으로
고민상태에 빠져 있더라도 그것이 업무에 영향을 끼치는 것은 당연하므로 상황을 대략이라도
알려고 노력해야 합니다. "알려고 노력해야 합니다" 이것이 중요한 것 같습니다. 힘든 상태에
빠져있는 팀원은 스스로 먼저 말하지 않습니다.

그러나 이 섹션에서 제가 아는 최악의 팀장은 이렇습니다. "아니, 본인이 말을 안하면 어떻게
아나요?" 저라면 그 말을 뒤집어서 그 팀장에게 이렇게 말해주겠습니다. "아니 그럼, 본인이
지금 힘들다고 해서 팀장님 ㅅㅂ 저 요즘 졸라 힘드니까 일 시키지 마세요" 라고 할까요?
정말로 유별나고 오버액션이 심한 사람 아니고서는 자기 힘들다고 징징대지 않습니다. 물론
그런 사람도 있긴 하죠. 하지만 그런 모습을 보이면 팀장 입장에선 어케 생각할까요? "저시키는
항상 자기가 젤 힘든줄 아네" 라고 좋지 않은 모습으로 볼겁니다. 결국 서로에게 더 피곤한
결과만 안겨줄 뿐입니다. 따라서 팀원들이 자기 힘들다고 먼저 얘기해야 내가 알 수 있다 라고
생각하는 팀장님 정말 천만의 말씀 만만의 콩떡입니다. 머 팀장과 팀원의 신뢰관계가 아주
높다라면 그럴 순 있습니다. 하지만 그런 경우가 대다수라면 이렇게까지 얘기하지도 안쵸

가장 바람직한 프로세스는 팀장이 "알려고 노력해야 합니다"  라는 것입니다. 그러기 위해서는
팀원들과 많은 대화를 해야 하죠. 그리고 팀원들의 많은 면을 받아들이는 자세가 필요합니다.
걍 대화를 듣는 척만 하거나 말한 후에 뒤에서 응징을 가하거나 머 그런다면 오히려 역효과겠죠 -_-
팀장 스스로 팀원들의 상태를 파악하는 모습이 필요합니다. 팀원 입장에선 자기를 신경써주는
모습에 고마운 느낌을 가지게 됩니다. 그리고 나중에 가선 팀장님이 원하는 모습을 보여주겠죠.
머 예를들면 "팀장님, 제가 저번주에 여친이랑 헤어졌는데 그거 때문에 정신상태가 엉망이고
일이 졸 안잡혀요, 제가 업무 처리가 좀 더디더라도 조금만 이해해주세요 금방 일어설께요"
이해 못해주시는 팀장님 없을겁니다.


아직도 몇가지 내용이 더 남았는데 쓰다보니 오늘도 졸 길어졌군요
내일이나 모레 한편 더 쓰도록 하겠습니다. ㅎㅎ



window31. 2008년 5월

이 블로그를 방문하시는 분들 중에는 본인이 팀장인 경우도 있을 것이고, 아니면 팀장 밑에서
일하고 있는 팀원인 분도 계실거라 생각합니다. 오늘은 팀장의 자질? 역할? 등에 대해 이야기
해보려 합니다.좋은 팀장과 나쁜 팀장에 대한 서술, 그리고 팀장으로써의 갖춰야 할 덕목? 등에
대한 소재들을 제 이야기와 주변에서 들어본 많은 예제들을 섞어 가감없이 털어내 보겠습니다.

일단 저는 지금까지 여러 팀장 밑에서 일을 해보았지만, 그래도 다행히 - 남들이 표현하기에 -
쓰레기 같은 팀장은 만나본 적은 없는 것 같네요. 물론 그렇다고 해서 이 사람이 지금까지
만나본 적 없는 지구상에 존재하는 최고의 팀장이다 ! 라고 할 정도의 분들이라는건 아니고요 ㅎ
머 어느 사람이나 완벽한 이는 없기에 당신은 나의 최고의 팀장이다 라고 사실 칭찬해 드릴 수는
없지만 :p 그래도 각 팀장님들 밑에서 일하면서 어느 정도는 이만한 사람이 없다 라고 느낀 적은
많았습니다. 하지만 그에 비해 제 주변엔 쓰레기같은 팀장 밑에서 일하는 친구, 선후배들이 참
많군요 lol.  나이가 들은건지 사회생활 흔적이 늘어나서 그런건지 요즘 들어 더더욱이 팀장들의
뒷따마가 참 많이 들려 옵니다 :p 그럼 한번 썰을 풀어놓아볼까요.

1) 팀장이 지키지 못하는 룰은 팀원에게 강요하지 말것

일단 제 얘기를 해보자면, 저는 전직장에서 지각을 좀 많이 한 편이었으나(워낙 늦게까지 일해서
라고 변명 하겠습니다 ;; ) 단 한번도 팀장님에게 지각에 대한 코멘트나 압박을 받은 적이
없었습니다. 왜냐하면 팀장님도 지각을 자주 하시거든요 ㅎㅎ 그래서 본인이 지키지 못하는 룰은
팀원들에게도 강요하지 않았던 것 같습니다. 그 부분은 참 고맙게 생각하는데, 사실 이건 어떻게
보면 팀장 입장에서는 당연한 행동입니다.

그러나 상당수의 팀장들이 그렇지 않죠. 본인도 종종 지각을 하면서 지각을 하는 팀원들에게
쓰레기같은 욕을 퍼붓거나 압뷁의 눈초리를 넘기는 팀장들이 있습니다. 뭐 지각이라는 명제에
국한된 이야기가 아닙니다. 업무를 할 때 팀장 본인도 일을 한두개씩 빼먹는 덤벙댐을 보여주면서,
팀원들이 멀 하나 빼먹는 모습을 발견하면 이때다 싶은건지 바로 지적을 가하는 어이없는
팀장들도 있습니다. 이런건 정말 팀장으로서 자제해야 할 행동입니다. 팀원들에게 잘못을
지적하기에 앞서서 본인의 행동은 어떠했나를 먼저 생각해야 합니다. 만약 어떤 팀원이 보기에
팀장이 맨날 저지르는 실수를 자기가 한번 했는데 지적을 받았을때, 대부분의 팀원은 이렇게
생각할겁니다. "ㅄ아 너나 잘해라" 이런게 쌓이면 신뢰관계는 무너집니다. 그리고 팀원들은
그 팀장을 더이상 팀장으로 생각하지 않게 되기까지 하죠. 따라서 본인이 팀장이라는 지위에
있을 때 어떠한 지적사항을 내리기 전에 자신의 모습을 한번 더 돌아보는 자세가 필요합니다.

2) 모르면 나서지 마라. 닥치고 팀원 말을 좀 들어봐라

이번에도 제 이야기로 시작해보겠습니다 ^^;; 현 팀장님 얘긴데요, 저와 팀장님은 주력분야가
조금 달라서 팀장님이 잘 아시는 것을 제가 하나도 모를때가 있고, 제가 아는것에 팀장님께서
조금 모르는 부분이 있습니다. 저희 팀장님은 그런 부분을 인정하고 제 분야라고 생각하시는
쪽에는 제 의견을 기울이시는 편입니다. 항상 고맙게 생각합니다 (아아 연이어 본의 아니게
저의 전,현 팀장님에 대한 아부성 멘트를 날렸군요. 설명의 전개상 어쩔 수 없습니다 :p )

그러나 사실 이런 팀장들은 많지 않습니다. 본인이 팀장이라는 입지 때문에, 잘 몰라도 일단
아는척을 하려 하는 것이 보통입니다. 그리고 본인의 생각과 부합하지 않는 의견을 팀원이
냈을 때, 본인이 그 팀원보다 더 지식이 적음에도 불구하고 고집을 부리거나 결국에는
공권력으로 밀어붙혀 의견을 묵살시켜버리죠. 보통 이렇게까지 되면 그 팀원은 일단
팀장에게 더이상 솔직한 발언을 내뱉지 않게 됩니다. 그러면 당연히 좋은 아이디어나
효율성 높은 의견은 어둠 속에서 사라지게 되고, 업무 질은 떨어지게 됩니다. 팀장과
팀원간의 불화가 커지는 것도 물론이고요.

팀장이라는 지위는 리더의 위치이긴 하지만, 신(god)의 자리가 아닙니다. 따라서 팀장도
모르는 것이 있을 수 있으며, 팀장보다 더 나은 의견을 팀원이 제시할 수도 있습니다. 하지만
상당수의 팀장들이 자존심 상해하는 이유 때문에 그리고 체면? 때문에 일단 본인이 더
아는 척을 하려 합니다. 정말 위험한 행동이죠. 근데 사실 되게 웃기는게, 이런 팀장은 진짜
확인해보면 실력이 매우 별볼일 없는 사람이 많습니다. 입사가 빨라서 밀려 올라가서 팀장이
됐다거나 연줄로 팀장이 됐다거나 뭐 족보를 파보면 그런 경우가 많죠. 또 이런 팀장들은
알고보면 자기보다 잘난 팀원들이 생길까봐 불안에 떨고 있는 족속들인 경우도 많습니다.
사실 어떻게 보면 불쌍한 것도 같습니다.


3) 팀원은 팀장의 장기말이 아니다.

사실 팀장의 주 역할은 업무 보다는 관리가 먼저이긴 하지만, 돈과 인력이 넘쳐나서 항상
여유에 젖어있는 대기업이 아닌 이상 (대기업 중에서도 여유 많은 부서) 관리에 주력하는
팀장은 많지 않죠. 형편상 팀장도 함께 업무를 하는 것이 보통입니다. 그러나 어이없는 현실은
상당수의 팀장들이 일은 많고 사람 모자라서 주글라고 하는 열악한 팀임에도 불구하고 본인은
일은 거의 하지 않고 팀원에게 시키기만 하는 경우가 있습니다. 물론 팀장은 팀원에게 업무를
시키기 위한 자리이기도 합니다. 하지만 그것은 업무를 "지시" 하라는 것이지, 업무를 "떠넘기라는"
의미가 아닙니다. 이 경우는 대부분 지가 하다만 일을 다른 팀원에게 떠맡기거나
성과는 별로 없고 시간만 졸라 많이 드는 작업을 팀원들에게 넘기는 경우가 대부분입니다.

아주 최악의 팀장으로 꼽을 수 있습니다. 더욱 쓰레기같은 모습은 윗 사람에게 잘 보일만한
업무나 웬지 이런건 내가 해야 있어보인다 싶은건 또 반드시 자기가 한다는 겁니다. 조금 더
개쓰레기같은 면으로 업글 시켜보자면 팀원이 해온 일을 자기가 한 것처럼 둔갑시키기까지 합니다.
그런 팀장 밑에서 일하는 팀원은 항상 팀장의 뒤치닥거리나 잡일만 하게 되고, 업무 스킬은
제자리 걸음만을 반복하게 됩니다. 물론 성과도 팀장이 다 가져가므로 윗사람에게 인정 받는건
여전히 팀장입니다. "이 사람 밑에서는 배울게 없다" 라고 생각하게 되죠.


아~ 하고싶은 말이 아직도 한참 남았는데 써놓고 보니 생각보다 지면을 꽤 차지했네요 ;
슬슬 졸리기도 하고 다음 내용은 2부에 계속 써보겠습니다 :p


window31. 2008년 5월.

 

야후에서 중국 지진을 애도하기 위해서 메인화면 디자인을 흑백으로 했네요.

중국 지진 때문에 모든 온라인 게임도 5월 21일까지 3일간 서비스 중단이랍니다.
정부에서 지정한 애도의 날? 뭐 그런걸로 되어서 다같이 서버를 닫기로 했다나봐요.
http://tianyichina.tiancity.com/homepage/article/2008/05/19/4307.html
여러 곳에 영향을 미치네요..

중국에 지인 계시는 분들, 아무 일 없으시길.

XP 서비스팩 3가 릴리즈되었습니다. 드뎌 나왔네요 어떤 것이 바뀌었을 지...
관련 업무 하시는 분들은 틀에 얽매인 써머리를 보는 것보단 수많은 리부팅과 블루를 띄워보며
직접 겪으시는게 아무래도 낫겠죠 :p

옛날에 보안 개발 업무 할때는 이런거 하나 튀어나오면 완전 비상이었는데
지금은 그나마 압박이 좀 덜하긴 하지만 그래도 여전히 불안불안 하네요 :p

링크는 아래
http://support.microsoft.com/kb/936929

정신을 차려 보니 어느덧 5월이네요.

4월은 정말 숨돌릴 틈 없이 빨리 지나갔던 것 같습니다. 일단 블로그는 거의 신경을
못썼네요 ^^; 마소 원고도 하필 2개나 잡혀버려서 그것도 은근히 압박이 있었고요
업무적으로 골때리는 일도 많았고 새로 준비해야 할 것도 있구
머 어쨌든 새로운 일들이 굉장히 많았으며 주변의 많은 것들이 바뀌었고
슬픈 기억의 희석과 기쁜 기억의 태동 새로이 만들어갈 추억들 등
달력을 보는 것도 잊을 만큼 빠르게 시간이 흘러갔던 것 같네요.

영화 빽 투더 퓨처를 보면 그런 부분이 나오죠. 1,2,3편을 통틀어 1955년의 시점이
계속적으로 모든 부분과 연관을 맺게 되고 브라운 박사는 자꾸만 관계성을 맺어가는
1955년이 시간 흐름의 법칙 혹은 우주학적으로 무언가 중요한 의미를 갖는 시점이라고
표현을 합니다. 머 물론 영화에서 내용 전개상 갖다붙힌 얘기에 불과하겠지만 어쨌든
저는 그 부분에 큰 인상을 받았고 저도 제 인생에 있어서 어떠한 "시점"의 존재를 중요시
하게 됐습니다. 그런 의미에서 2008년 4월은 제가 지금까지 지내온 삶과 앞으로 살아갈
날을 앞뒤 미루어 보았을 때 굉장히 큰 의미를 갖는 시점이 될 것 같습니다. 머 구체적으로
엿이다 뻑이다 머다 구구절절 읊어대기에는 거시기한 일들이 많지만 어쨌든 그렇네요 ^^;

일상이 변화하면서 제가 변하는 모습을 느끼게 되었고 지난 시간들에 대한 반성을 많이
했습니다. 과거의 미안했던 행동들 후회스런 일들 그리고 진작 해오지 못했던 것들 여러모로
삶에 있어서 흠집이나 흉터가 되었던 희로애락이 사람의 가슴을 그렇게 아프게 할 수 있다는
그리고 나의 무책임한 발언이나 행동이 여러 사람에게 악영향을 끼쳤다는 것이 참 많은
부분에서 부끄럽게 하네요 ^^; 후회는 하지만 이제와서 돌이킬 수 없는 부분. 반성하고 있습니다.
그리고 다시는 같은 잘못을 저지르지 말아야겠죠. 머 이제라도 깨닫고 반성 했으니 다행이죠
그렇게 생각해보니 오히려 본인이 대견해지기도 하네요 :p

아무래도 주변 생활이 본인의 심리상태나 관념 등에 대한 기준을 지배하게 되는 것 같습니다.
그런 의미에서 개발자 분들 그리고 보안 컨설턴트 하시는 분들, 기술서적 이제 그만 보시고
수필이나 소설도 좀 보세요 :p 저도 생각해보면 옛날에는 이빠이 느끼한 글도 좀 보았고
예쁜 책도 어느 정도는 읽어대며 감성을 평균 수치 근처까지는 유지했던 것 같은데 그넘의
코드에만 빠져있다 보니 인간이 딱딱해지고 계산적이 되고 융통성이라는 것을 모르게 되고
삶의 끈적끈적한 부분을 인정하지 않고 살게 되었던 것 같네요.

저도 이래뵈도 예쁜 편지지에 밤새 꼬깃꼬깃 적은 악필의 문체로 연애편지도 많이 써보았고
좋아했던 여자에게 주려고 별도 천개씩 접어본 이력을 가지고 있습니다(자랑입니다! ;;; )
하지만 어느샌가 몇년전부터 그런것을 잊고 살게된 것 같네요. 굳이 그런것을 챙피하다? 혹은
뭐냐 쪼팔리게! 라고 굳이 생각할 필요는 없는 것 같다는 생각이 요즘은 자꾸 듭니다. 본인이 정말
하고싶지 않은 것과 남들 눈을 의식하는것은 전혀 다르니까요. 딱딱하게 굳어 있는 것이 반드시
멋있어 보이는 것도 아닌 것 같고요 :) 감정을 속이는 것, 억지스럽게 감성과 사랑을 억눌러
보았자 되돌아오는 것은 이퀼리브리엄에서의 주인공의 총알 세례 뿐이라는 생각이 자꾸 드는
요즘입니다 :p


2008년 5월.

 

 

 

[실전강의실|Reverse Engineering의 정석]
C++ 클래스와 디스어셈블링

월간 마이크로소프트웨어 2008년 5월호

지난회는 C 코드가 어셈블리 코드로 변환되었을 때를 살펴보았다. 이번회는 C++ 문법과 클래스는 디스어셈블링을 할 때 어떤 식으로 해석할 수 있는지 알아본다. call, 조건문은 점프 구문 등으로 어느 정도 직관적인 예측을 할 수 있었던 C 문법에 비하여 C++는 멤버 함수, private 함수, 생성자, 소멸자, 상속 등 분석이 어려운 다양한 개념이 많은 편이다. 리버스 엔지니어링을 할 때 이러한 내용들은 어떻게 확인할 수 있는지 확인해 보자.

------------------------------------------------------

강병탁 window31@empal.com, http://www.window31.com | 바이너리 취약점 분석 업무를 하고 있다. 안티 크래킹/안티 디버깅 엔진 개발을 다년간 해왔으며 시스템 프로그래밍과 리버스 엔지니어링에 관심이 많다. 악성 코드나 해킹툴이 내부에 담고 있는 천재적인 알고리즘에 감탄하며 오늘도 IDA를 돌린다.

------------------------------------------------------

------------------------------------------------------

연재 순서

1회 | 2008. 4 | C 문법과 디스어셈블링
2회 | 2008. 5 | C++ 클래스와 디스어셈블링
3회 | 2008. 6 | DLL, MFC 실전 모듈 리버싱
4회 | 2008. 7 | 4GL 고급 언어 역분석
5회 | 2008. 8 | 안티 디버깅과 리버스 엔지니어링

------------------------------------------------------

연재 가이드

운영체제| 윈도우 2K/XP/2003
사용도구| Visual Studio, IDA, WinDBG
기초지식| C, ASM, Win32 API
응용분야| 리버스 엔지니어링/시스템 프로그래밍/해킹/보안

------------------------------------------------------

C++ 분석의 난해함

객체 지향 프로그래밍은 바이너리 코드로 바뀌었을 때 어떻게 접근해야 할까? 사실 C 코드의 경우는 함수, 조건문, 반복문 이라는 일정한 규칙이 있고, 이것은 어셈블리에서 CALL문, Jmp문 등으로 쉽게 대입이 된다. 하지만 C++로 넘어오게 되면 클래스가 등장하고, 멤버 변수와 멤버 함수가 필요하게 되며, 캡슐화나 상속 등의 개념까지도 요구된다. 이러한 것들이 개발자 입장에서는 좀더 쉽고 간편한 코딩을 위해 이러한 기반이 마련된 것이지만, 리버스 엔지니어링 할 때의 입장은 전혀 다르다. 현재 보고 있는 함수가 그냥 함수인지 특정 클래스의 멤버 함수인지, 그리고 이 변수는 전역 변수인지 생성자는 어떤 식으로 구성되어 있는지 등 파악하기 어려운 부분이 많기 때문이다. 즉 구조적 뼈대가 C++과 어셈은 1:1로 매칭되지 않으므로 직관적인 파악이 쉽지 않은 편이라는 것이다.

클래스 뼈대