소스코드 분석에 왕도는 있다?
글쓴이: 김태호_ / 작성시간: 수, 2000/12/27 - 11:44오전
프로그래밍을 하다 보면 처음부터 끝까지 아무것도 없는 상태에서 뭔가 만들어내기 보다는 이미 존재하고 있는 남의 코드를 가져다가 고쳐내는 경우가 더 많지요?
이럴때 특히 중요한 것은 남의 코드를 빨리 이해하고 그 구조를 머릿속에 넣는 것일텐데 그게 소스코드가 커지면 쉬운 일이 아니더라구요.
과연 소스코드 분석시 어떻게 하는 것이 좋을까요?
대형 프로그램의 소스를 분석할 때는 어떤 정해진 방법이라도 있는 것인지....
언어별로 조금씩 다르겠지만....가장 많이 쓰는 C언어만 가지고 이야기를 좀 해보고 싶군요.
댓글
후후 제가 아직 허접이라 그런지...전 프로그램 시작점 부터 봅니다.
후후 제가 아직 허접이라 그런지...
전 프로그램 시작점 부터 봅니다.
그리고 하나씩 호출되는 넘들을 ctag로 따라가죠...
그럼 결국은 하나의 모듈 끝까지 가게됩니다.
어떻게 보면 코드 자체가 하나의 트리라고 생각되죠.
근데 소스 전체를 분석하는 경우가 많은가요?
전 주로 필요한 부분만을 분석하고 적용하다 보니...
그럼 허접이었습니다.
저도 프로그램 분석을 위해 님께서 올리신 자료가 필요합니다.저의 멜로
저도 프로그램 분석을 위해 님께서 올리신 자료가 필요합니다.
저의 멜로 보내주시면 감사하겠습니다...
괜찮은 소스 분석 툴로는 크게 두 가지가 있는 것 같습니다. 우선 SU
괜찮은 소스 분석 툴로는 크게 두 가지가 있는 것 같습니다. 우선 SUN의 cscope과 LXR이라 불리는 툴이죠.
cscope는 대단히 고가의 소프트웨어였지만 SCO에서 공개용 cscope을 만들었습니다. 이 툴은 lex와 yacc을 이용하여 만들어졌는데 검색 속도가 꽤 좋습니다.
lxr은 대량의 소스를 하이퍼텍스트로 만들어 주는 툴인데, lxr.linux.no같은 사이트를 보면 그 유용성을 알 수 있죠. cscope이나 lxr은 쉽게 구할 수 있지만 정 구하기 어려운 분들은 메일 주십시오.
cscope이나 lxr가 필요하면 멜달라고 했는데 정말 주시는건가요...
cscope이나 lxr가 필요하면 멜달라고 했는데 정말 주시는건가요...?
그렇담 고맙구요...
쩝... ls 소스만 해도... -.- 4990 line 이더군요.뭐
쩝... ls 소스만 해도... -.- 4990 line 이더군요.
뭐... 디파인한거하고 주석빼면... 훨씬 줄겠지만...
뭐 대부분이... 옵션 처리부분... -.-
실제로... 파일만 보여줄려고 하면... -.- 몇줄
안되는데... -.- APUE 보면... 아주간단한... ls가
크크크... 하여튼 고운 하루되시길...
ln 이나 mv 같은건... 몇백라인 밖에 안되더군요.
크크크... 고운 하루...
소스 분석에 앞서 개인적인 소스에 관한 이야길 해보게습니다.해가가고
소스 분석에 앞서 개인적인 소스에 관한 이야길 해보게습니다.
해가가고 프로젝트를 하나씩 더 수행할때마다..
소스는 머랄까 좀더 조직화 되어 간다고 할수 있을까요?
결국은 이런 논리 입니다. 큰 프로그램 잘된 프로그램일수록
소스만 보고 분석하기가 쉽습니다.
왜냐면 크면 클수록 그 구조는 명확하고 framework 은
정교해야 하기 때문입니다.
보통은 크게 file 과 function 단위로 분석을 하는데
특정 function에 집착하진 않습니다. 일단 숲을 보는거죠
그렇게 숲을 먼저 보고 core 를 찾으면 코어를 위주로 봅니다.
그리고 수만줄이라고 해도 이미 분석한 framework이 몸에
익으면 그 코드를만든 철학자(?)의 눈으로 , 그사람의
view point로 코드를 훝죠.. 그렇치 않고 그 많은 코드를
어떻게 보겠습니까.
그렇게 하고 고치게 되면 그 framework 에 맞춰 수정을
해야합니다.물론 소스가 무척 클때 이야기입니다.
그리고 device code 가 아니면 혹은 특정 알고리즘을
구현한 코드가 아니면 그 알수없는 function 내부를
깊게 들여다 보지 않습니다. 왜냐구요?
일반 어플리케이션에서 쓸수 있는 알고리즘은 분석가도
대부분 충분히 구현할수 있는 부분이잖습니까?
많이 애를 먹었던게 device driver류의 코드 였는데
앞에서 어떤분이 말씀을 하셨던것처럼 하드웨어와
동작구조를 ,그 특정 bit의 의미까지 완벽하게
알아야 쓸수 있거든요
머 대부분은 그런 코드보다는 특정 application에분석이
대부분이라고 보는데 특정 기술이 삽입되지 않은
application은 대부분 중심 철학만 알면 , 숲을 보게되면
그냥 뚫을수 있습니다.
많약에 전체적으로 구조가 파악되지 않는다면 그 코드는
개념없이짠 코드이거나,
짱가가 짠 코드이거나 ,
아니면 분석하는 사람의 자질이 너무 떨어지는 경우겠죠
syscall조차도 제대로 모르고 유닉스 기반 application
을 분석한다는거는 너무 힘든일 아니겠습니까?
정말 좋으신 말씀이었습니다..벅찬 감동을 받았습니다..나무
정말 좋으신 말씀이었습니다..
벅찬 감동을 받았습니다..
나무를 보지말고,, 숲을 봐라..!
제게.. 큰. 격려가 되는 한 마디 였습니다..
새해복많이 받으십시요..
그럼이만.
소스코드의 분석은 말은 쉽지만 실제로는 엄청난 일입니다.코드의 크
소스코드의 분석은 말은 쉽지만 실제로는 엄청난 일입니다.
코드의 크기나 복잡도에 따라 틀려지겠지만, 엄청난 양의 용량을 필요로 하는 일이기 때문입니다.
자기가 만든 것도 아니고 남이 만든 소스 코드 내에서 사용된 자료구조나 함수의 역할 등등을 머리속에 넣고 있지 않으면 무지하게 힘들어지기 때문입니다. 영단어가 약한 사람이 영어 소설을 읽는 것 같다고나 할까요.
그러한 것들을 극복하기 위한 방법 중 하나로 아래에서 많은 분들이 지적하신 것처럼 \"관련 지식/정보의 습득\" 이라는 방법이 있습니다. 대단히 중요한 내용이지요.
여기에 하나 더 덧붙이고 싶다면 \"직관의 획득\" 을 말씀드리고 싶네요.
많은 사람들이 직관을 통밥이라고 이야기하면서 그 능력을 비하시키지만, 어떤 큰 일을 하기 위해서는 가장 중요한 요소라고 생각합니다.
그렇다면 직관은 어떻게 획득할까요. 저는 \"경험이 직관을 만든다.\" 라는 생각을 합니다. 많은 사람들이 \"경험을 통해 획득한 획일적인 사고방식이 직관을 방해할 수 있다.\" 라고 이야기하지만, 제 생각은 약간 틀립니다.
일반적인 \"척 보면 아는\", \"척 보면 간파하는\" 직관을 가지기 위해서는 *다양한* 경험이 가장 필수적인 것이라고 생각합니다.
제가 SI 쪽에 있어서 그런지 이쪽의 일들은 굉장히 획일적입니다. 대부분이 RAD 를 가지고 개발하며, RDB 를 사용하여 자료 처리를 수행하지요. 그러다 보니 경험이 많아지면 나름대로 SI 에 대한 직관들은 가지지만, 약간이라도 다른 요소가 섞이게 되면 직관이 아집으로 바뀌는 경우를 종종 봐 왔습니다.
이런 방식보다는 다양한 소프트웨어의 소스 코드를 보시는 것이 좋을 것 같습니다. 시스템이면 시스템, 그래픽이면 그래픽, 에디터면 에디터, 등등등... 요.
처음에는 작은 코드부터 분석하시는 게 좋을 것 같습니다. 유닉스 시스템의 ls, ps, vmstat, sysctl 등을 분석하시는 게 좋겠네요. 프로그래밍의 스타일, 테크닉, 그리고 좀 더 깊게 들어가면 시스템의 원리들도 어느 정도 보일 것 같습니다.
그 후 직관이 어느정도 생기면 - 통밥이 어느정도 생기면 ^^ - 중간 크기의 프로그램 또는 커널 쪽으로 분석을 하시는 것도 좋겠지요.
그럼... 새해 복들 많이 받으세여
저 자신도.. 솔직히 소스분석에 그리 경험이라던가 자신이 있는 것은 아닙
저 자신도.. 솔직히 소스분석에 그리 경험이라던가 자신이 있는 것은 아닙니다. 몇년전엔가 머드에 관심을 가지고 서클머드나 네트핵의 소스를 열심히 들여다본 것이 전부일뿐.. 하지만 나름대로 그동안 열심히 해왔고 만약 무언가 다시 소스분석할 일이 생긴다면 이렇게 해보겠다.. 라고 생각하는건 있답니다.
1. 조급해하지 말것..
소스분석이 쉬운 일이 아니라고 봅니다. 덩치가 커다랄수록 하루이틀 밤새서 가능한 일이 아닌이상 느긋한 마음을 가져야 할겁니다. 제 생각엔 어떤 소스를 완벽하게 분석하려면 그 소스를 직접 짜는 것보다 더 뛰어난 실력이 있어야 가능하며 시간은 그 소스를 직접 짜는 것보다 조금쯤 덜 걸린다.. 라고 생각합니다. 즉 소스분석이란게 쉽지 않은만큼, 분석할만한 가치가 있는 소스만 분석해라.. 라고 말하고 싶군요. 지저분하게 짰거나 구조적으로 불명확한 소스같은건 웬만하면 안들여다보는게 정신건강에 좋지 않을까..
2. 덩치가 크다고 주눅들지 말 것..
옛날 베이직 소스도 아니지 않습니까? 수만줄짜리 소스가 구조화되어있지 않을 리가 없습니다. 중요한 것은 그러한 구조를 파악하는 것이지 소스 한줄한줄이 어떤 의미인지를 파악하는 것은 그 다음의 일입니다.
3. 스타일을 파악할 것
똑같은 C언어라고 해도 짜는 사람마다 스타일이 틀립니다. 변수나 함수작명법, 소스파일을 에디팅하는 스타일, Indenting같은 기본적인 부분부터 typedef, 매크로, 유틸리티 함수, 에러처리, 헤더파일, 루프 스타일, if문에 조건거는 스타일, 함수 하나당 대충 어느정도의 일을 처리하는가.. 기타등등 그 사람의 스타일을 이해하면 소스를 한층 빨리 읽을 수 있게 됩니다. 그러니까 일단 소스를 접하게 되면 이런 부분들을 유심히 관찰하는 것도 필요하다고 봅니다.
4. 소스의 목적을 명확히 이해할 것
분석하려는 프로그램, 또는 소스가 정확하게 어떤 일을 하는지 우선 이해하고 있지 못하다면 그야말로 삽질입니다. 주석이라던가 파일명, 함수명, 호출위치등에서 최대한 정보를 얻어내어 우선 이 소스파일은 이런이런 일을 하는구나.. 하고 예상을 해야만 합니다.
5. 구조를 파악할 것
뭐 쉬운 얘긴 아닙니다만.. 일단 소스파일 수준에서 파악합니다. C파일이 30-40개쯤 되면 각각의 파일들이 어떤 역할을 하는 모듈인지 파악합니다. 유틸리티 모듈인지 아니면 UI모듈인지 아니면 데이터 모듈인지 또 서로 의존적인 것끼리 묶어서 그룹화도 합니다. 헤더파일도 마찬가지입니다. 잘 모르면 최대한 가능한 범위내에서 가정하고 들어갑니다.
그리고 나서 파일내부를 들여다봅니다..
6. 자료구조를 파악할 것
함수는 어차피 블랙박스라고 배우지 않았습니까? 한줄한줄 코드의 분석은 의미가 없고 함수단위로 \'이 함수는 이런 일을 한다\' 정도만 이해하고 있으면 됩니다. (물론 구조적이지 않은 소스라면 이런 말은 모두 무의미해집니다..)
그보다는 자료구조를 파악해야합니다. 물론 자세한 주석도 없는 상황에서 변수명과 데이타타입만 가지고 자료구조를 정확히 파악하기는 무리일 수도 있습니다만 코드를 들여다보기 전에 변수정의, 특히 C의 경우 전역변수 정의는 철저하게 들여다보고 들어가야만 합니다.
7. 배경지식을 갖출 것
말그대로입니다.. 만약 정렬이라던가 검색같은데 특정 알고리즘을 사용했다면 그 알고리즘을 모르는 상태에선 삽질이 될겁니다. 세마포를 썼다면 세마포를 우선 알고 있어야 합니다. FTP프로그램이라면 FTP프로토콜 및 작동원리에 대해 충분히 이해하고 있어야만 합니다. 그 소스를 작성하는데 필요한 충분한 배경지식이 없다면 분석은 더더욱 요원한 일입니다. 다시 말씀드리지만 어떤 소스를 분석하려면 그 소스를 작성하는 것보다도 더욱 뛰어난 실력이 있어야만 가능하다고 생각합니다. 만약 공부를 목적으로 소스를 분석한다면, 즉 자신이 짤 수 없는 소스를 분석하려고 든다면 짜는 것보다도 더 많은 시간이 필요할겁니다.
개인적으로.. 공부를 목적으로 분석을 한다.. 라는 것은 별로 바람직하지 않다고 봅니다. 예를 들면 GIF파일을 사용하는 방법을 공부하고 싶다고 해서 GIF.C를 어디서 구해다가 분석을 한다면.. 그건 좋지않습니다. GIF파일의 구조도 압축알고리즘도 정확히 이해못한 상황에서 소스코드만 들여다본다고 이해할 수 있을리가 없습니다. 정리된 문서나 책을 통해 공부를 하는 것이 훨씬 낫죠.
다만 큰 프로그램을 분석해보면 \"이렇게 짜는거구나\", \"이렇게 구조화시키는거구나\"하고 규모가 큰 프로그램을 작성하는 방법에 대해 느낄 수는 있다고 봅니다.
이런 좋은 글 100 point
이런 좋은 글 100 point 드리고 싶네요
프로그램 소스에 대한 사자성어...네트워크 프로그램 : 촌철살인(
프로그램 소스에 대한 사자성어...
네트워크 프로그램 : 촌철살인(寸鐵殺人)
데이타베이스 프로그램 : 고진감래(苦盡甘來)
시스템 프로그램 : 공전절후(空前絶後)
인공지능 프로그램 : 기상천외(奇想天外)
수치해석 프로그램 : 목불식정(目不識丁)
웹 프로그램 : 미인박명(美人薄命)
객체지향 프로그램 : 동분서주(東奔西走)
구조화 프로그램 : 거두절미(去頭截尾)
...他山之石으로 삼으시길
그것보다는 먼저 그 프로그램의 가장 큰 부분부터 코어로가는게 낫지않을
그것보다는 먼저 그 프로그램의 가장 큰 부분부터 코어로
가는게 낫지않을까 싶네요...
그리고 여러분은 모르시겠지만.. 컴 모니터 보면 자신도 모르게
스트레스 쌓입니다
:) 머리를 비우고 쭈욱 본다,.다시본다,.,.또본다,.,
:) 머리를 비우고 쭈욱 본다,.
다시본다,.,.
또본다,.,
욕하면서 본다,.,.
-_-분석끝내고 잔다,.,.
꿈속에서 알고리즘을 뜯어고친다,.내맘대로,.
일어나서 -_-코딩한다,.
하하하... 가장 현실에 와닿는것 같네요.
저만 그러는줄 알았습니다. :-)
가끔 심하게 헤매던 부분도 문득, 혹은 잠자리에서 불현듯 잡아내고는 하던데...
=====================================================================
s9712094@gmail.com
http://cliff3.tistory.com/
지구본을 보면 우리 사는 지군 둥근데,
부속품들은 왜 다 온통 네모난건지 몰라...
어쩌면 그건 네모의 꿈일지 몰라.
네모의 꿈-화이트3집 中에서
=================
Have a nice day! :-)
Google Talk : s9712094
iChat : s9712094
http://www.facebook.com/joonho78
http://twitter.com/JoonHoSon
=================
먼저 실행해본다 그리구 내가 알고 있는 모든 수단을 통해 계속 건드린다.
먼저 실행해본다 그리구 내가 알고 있는 모든 수단을 통해 계속 건드린다. 소스해부 말고 실행을....
그리구 작성한다. 만들고 나면길지만 어째든 돌아간다..쪼짜 가 분석하는 방법론 --;
저 같은 어떤 소소를 분석한다고 맘을 먹으면, 모조리 프린트 합니다.
저 같은 어떤 소소를 분석한다고 맘을 먹으면, 모조리 프린트 합니다.
그리고 무작정 끝까지 한번씩 훑어 봅니다. 그러면, 대충 어떤 함수들이 중요한지 알게 되더군요. 형광펜은 필수^^
그리고는, 그 중요 함수를 중심으로 흐름을 파악할려고 합니다. 즉 알고리즘을 파악하죠.
여기까지 하면, 소스 코드의 90% 를 파악됐다고 생각합니다.
그리고는, 그 알고리즘을 제가 알고 있는 랭귀지로 구현합니다.
(일일이 소스를 한줄 한줄 뜯어 볼필요는 없습니다.
제 경험상 대부분 core 부분은 얼마 안됩니다.)
프로그래머가 자기 실력을 늘리는데, 남의 소스를 뜯어보는것 만큼 좋은건 없다고 봅니다.
정말이지 모방은 창조의 어머니란게 이런데에 들어맞는게 아닐까요?
저 같은 경우는 지금 작은 보드위에 올라가는 프로그램 소스를 분석중인데요
저 같은 경우는 지금 작은 보드위에 올라가는 프로그램 소스를 분석중인데요...
밑에분 말씀대로 참 많이 필요하네요..
USB specification, 각 칩의 datasheet, 참고할 책들...
역시..
어렵다는 생각외엔...
하드웨어에 대해서 잘 알아야 한다는게...더 어려운거 같네요...
분석하려는 소스가 무엇을 하느냐를 알고 싶다면좀 쉽겠지요. 그리고 처
분석하려는 소스가 무엇을 하느냐를 알고 싶다면
좀 쉽겠지요. 그리고 처음에는 이것을 분석하는
것이 중요합니다. 그리고 각 무엇에 대해서 어떻게
를 하나씩 해 나가야 겠지요.
webalizer 소스를 분석하려고 삽질한적이 있는데안을 들여다보니
webalizer 소스를 분석하려고 삽질한적이 있는데
안을 들여다보니 C언어로 되어있긴한데 전혀 알아먹을수가
있어야죠.
책으로만 봤던 해쉬알고리즘도 봤는데 약간 이해가 되려다가
그냥 포기했습니다. 엉~
만드사람한테가서 이거 왜 이렇게했냐 저렇게 했냐를
묻지 않고서는 시간밖에 없을듯 합니다.
하하...사실 이 질문만으로는 애매한 이야기랍니다.분석하고자 하는
하하...
사실 이 질문만으로는 애매한 이야기랍니다.
분석하고자 하는 프로그램이 어떠한 종류의 일을 하느냐에 따라 틀리죠.
일례로 복잡한 알고리즘을 처리하는 프로그램들, 예를 들어 뉴럴 넷이라던가, HMM을 다이나믹 프로그래밍으로 구현한 코드들은 해당 코드를 보는 것만으로는 해결이 안됩니다.
알고리즘과 데이터 스트럭쳐를 먼저 이해하고서 코드 분석으로 들어가는 것이 정석이랍니다.
그리고 시스템 소프트웨어, 가령 임베디드 장비에 들어가는 펌웨어적 프로그램 같은 경우도 소스 코드만으로는 해결이 안되죠.
이런 시스템 소프트웨어는 해당 제어 MPU 칲에 대한 데이터 시트도 필요하고, 해당 장비를 이루고 있는 칩들에 대한 데이터 시트와 클럭 타이밍 차트도 필요학거든요.
(그래서 시스템 소프트웨어 작성은 순수 전산베이스만 공부하신 분들은 어렵답니다.)
네트웍쪽 프로그램 소스의 경우는 각종 규약(프로토콜), 표준에 대한 스펙문서(IEEE나 RFC 따위..)도 한쪽에 준비해야 되지요..
(세상에 쉬운 일 없죠?)
또, 다른 쪽으로 보자면 분석을 하고자 하는 프로그램 소스의 분량이 어느 정도냐에 따라 이야기가 매우(!) 틀려집니다.
솔직히 1-2 천라인 이하의 경우 사람에 따라 요령껏 분석할 수도 있지만 몇 만, 몇 십만 라인짜리 소스는 분석을 위한 툴들도 필요하고 \'방법론\'도 필요합니다.
흠.. 질문을 하신 의도는 알겠는데 이러한 문제의 경우는 글쎄요..??
저도 다른 분들의 의견을 더 들어봐야겠네요^^
제가 얘기하고 싶은 결론은 소스 분석을 한다해서 소스만 들어봐서 되는 경우는 드물다는 거랍니다.
(사설이 길었나요? 죄송..^^)
분석을 많이 해본것도 아니고 아주 큰 프로그램의 소스를 분석해 본 것도
분석을 많이 해본것도 아니고 아주 큰 프로그램의 소스를 분석해 본 것도 아니지만... ^^;
저같은 경우는 core 부분을 미리 찾습니다. 대체로 프로그램들이 인터페이스 구현에 상당히 많은 양의 코드를 들이는 걸로 알고 있거든요. 그래서 이런 부분을 넘어가고 실질적인 프로그램의 핵심 부위를 미리 찾아두면 분석이 편하겠죠.
당연히 이제서야 실질적인 분석이겠지만... 이상태로 함수의 역활이라던가 호출 흐름 등을 알아낸다면 더욱 쉬워지고, 나머지는 각각의 함수나 코드의 역활분석만 남았겠군요. -_-; 당연한 이야기를 적었군요..;;; 그냠 한번 적어봤습니다 ~ :)
코퍼스님이 소스분석 툴을 말씀하셨는데 구체적으로 어떤것이 있는지요?오
코퍼스님이 소스분석 툴을 말씀하셨는데 구체적으로 어떤것이 있는지요?
오픈소스계열에는 어떤것이 있는지 알려줄 수 있는지?
GD
저 같은 경우에는 unix에서 일반적인 도구들을 사용하고있습니다. 그
저 같은 경우에는 unix에서 일반적인 도구들을 사용하고
있습니다. 그럭저럭 쓸만하다고 느끼고 있는 편입니다.
주로 다루는 소스들이 대략 몇만~수십만 라인정도 되는
기완결된 프로젝트이고, 주로 C 또는 C++ 로 코딩되어
있습니다. 이중에서 일부분의 기능 또는 전체의
기능을 파악하여 기능 추가 또는 버그 수정 등의 작업
을 할때가 많습니다. linux 나 solaris 환경에서 작업은
하지만, 개발환경에서 직접돌릴 수 있는 프로젝트인
경우는 적습니다. 즉, embedded 시스템용 프로젝트도
꽤 있죠.
몇천 라인 정도면 프린트를 해보거나 그냥 쭈욱
훑어 가는 식으로 하는 것이 속 편하지만 시간이
며칠 없을때 꽤 많은 코드를 다 보기는, 게다가
일부기능만 보면 될 경우에 배보다 배꼽이 큰
경우가 많죠. 그래서 이것저것 해 보다가 결국은
전통적인 방법으로 돌아오게 되었습니다.
주로 쓰는 것이 vim 6.0beta (cscope 지원 컴파일)과
ctags 와 cscope 입니다. 다행인 것이 vim 이 이전
버젼부터 cscope 도 내부적으로 지원을 해주고,
cscope 의 recursive 기능의 버그가 최근에 잡혀서
더욱 편해졌습니다.
vi 와 ctag 은 초기부터 많이들 어울려서 쓰이는 툴
입니다. function 의 static call 을 훑어 내려가는
데 이만큼 편하고 쉬운 (아주 화려하지는 않지만)
방법도 없다 싶습니다. 게다가 vim 과 최신버젼의
exuberant ctags 를 이용하면 좀더 기능이 강화됩니다.
class 도 지원을 하고 multiple define 된 펑션들도
선택적으로 vi 내부에서 키 하나만 누르면 거의 딜레이
없이 0.5초에서 1초내에 (소스가 십만라인 이내라면)
점프가 가능합니다.
cscope 을 지원하도록 vim 을 컴파일 해야지만 이기능을
vim 내부에서 사용할 수 있습니다. (default 는 아마도
disable 되어 있을 겁니다.) cscope 은 그 자체로도
ctags 기능을 포함하는 다양한 기능을 하는 분석툴
이지만, vim 과 같이 사용하면 훨씬 다루기가 쉽습니다.
ctags 을 이용하여 해당 펑션의 definition 위치로
점프하는 기능 외에도, 해당 펑션을 호출하는 펑션을
찾아서 그 쪽으로 점프해주게도 합니다. 또한, 원하는
스트링을 grep 하고, 원하는 variable 을 찾고, 해당
헤더화일을 포함하는 화일을 찾는 등 다양한 기능을
vim 과 결합하여 사용할 수 있습니다.
저같은 경우 이 3개의 툴을 사용하지만, 결과적으로
vim 내부에서 몇개의 키로 ctags 과 cscope 을 사용
하도록 macro 시켜 놓기 때문에 강화된 vim 을
사용한다는 기분으로 통합된 분석환경을 사용하는 셈
입니다.
맨 처음 상위 디렉토리에서 ctags 와 cscope 을
recursive 하게 돌린 후 vim 에서 참조하도록
셋팅합니다. 그다음에, 하나의 펑션 또는 하나의 변수나
상수 등의 단서를 하나 얻습니다. 그것도 싫으면 대충
가장 상위가 될 것 같은 펑션이나 중요할 듯한 펑션이
있을 법한 화일을 하나 vim 으로 불러 들입니다.
(원래는 관련 문서라도 있으면 좋겠지만 있더라도
보기 싫을 때가 있고 없는 경우도 회사 사정상 때때로
있죠) 우선 vim 으로 불러들이면 그 다음부터는 맘대로
브라우징을 합니다. 아무 펑션이나 첨부터 끝까지는
그리 길지 않을테니 한번 훑어 보고 그 펑션에서
호출하는 펑션을 Control+] 로 들어갑니다. 또는
그 펑션을 호출하는 펑션을 찾고 싶을때 Control+\\
로 (이건 정의하기 나름이지만) 찾아서 올라갑니다.
펑션의 패러미터가 있을때 그 타입이 궁금하면 그 또한
Control+] 으로 정의된 곳을 들어가고, 항상 빠져나올
때에는 Control+T 를 사용합니다.
모든 프로젝트들이 structure 하게 구성되어 있지는
않죠. static function call 로만 구성되어 있다면
해피하겠지만, process spanwning 한다든지 function
pointer table 로 호출한다든지 IPC를 이용한다든지
하는 경우도 있습니다. 이런 경우는 cscope 의 기능을
이용합니다. g+Control+\\ (물론 이것도 정의하기
나름이지만) 을 치면 커서 아래 있는 keyword 가
assgin 된 곳 또는 패턴이 보이는 모든 곳이 선택되어
나타납니다. 어느 화일의 몇째 줄인지와 어느평션
안에 있는지 같은 위치 정보와 실제 사용된 라인이
한 줄 가량씩 해서 넘버링 되어 표시가 되면, 해당
넘버를 누르고 엔터를 치면 그곳으로 뛰어 갑니다.
이런식으로 하면 적어도 위에서 말한 다양한 방식의
펑션 호출들의 semantic call 까지도 개략적으로
파악이 가능합니다. 게다가 펑션 못지 않게 중요한
스트럭쳐나 클래스 같은 경우는 오히려 펑션 보다
구조가 static 하기 때문에 더 쉽게 알아 볼 수
있죠.
이런식으로 마구 마구 쉽게 브라우징 하다보면
대충 가닥이 보이기 시작합니다. 물론 관련 문서도
보면서 진행하면 더욱 좋지요. 이런식으로 일부분에서
전체구조로 퍼져나가면서 파악하는 방식, 또는 바텀에서
상위구조를 짐작해나가면서 파악하는 식의 작업은
조금 익숙해지기만 하면 일이라기 보다 마치 머드같은
text base RPG 를 하는 듯한 즐거움이 들기도 합니다.
물론, 즐기기만 할게 아니라 필요한 펑션/자료 구조들을
옆의 화면에 적어가면서 분석하고 생각을 해야 최종적인
분석 결과가 나오겠죠.
저 같은 경우에는 이런식으로 꽤 쓸만하게 작업을
해 왔는데, 주위의 다른 분들도 비슷하게 작업을
하더군요. 다른 방법도 많이 있겠지만, 요새 나오는
화려하고 최신의 기능을 가진 툴들 못지 않다고
생각이 듭니다. 가끔 class browser 같은 기능이 있
으면 더 좋겠다는 생각도 들기는 하지만, 이건 또 어차피 한번 시간 날때 다른 툴을 이용해서 돌려 버리면
그림 한장 나오니까 그걸로 충분할 듯 하다고 생각
이 드는 군요.
기타 기능으로는, vim 에서는 syntax highlighting 도
충실히 지원하고 아주 막강한 edit/modify/search
기능이 있습니다. 또, script 를 잘 사용하면 델파이
등 ms-win 용 개발환경에서 보이는 function parameter
preview 같은 기능도 사용할 수 있고, keyword completion 같은 기능도 막강하게 사용할 수 있습니다.
또 vim 에서만 본 것 같기도 한데, 때때로 중복되는
정의들이 있을때 어느 헤더를 include 할 때에 따라
또는 어느 소스를 makefile 에서 부를 경우에 때라
결과가 매우 달라지는 경우가 있습니다. 이럴때에는
makefile 에 있는 include path 를 vim 에 설정해
주면 [I 라는 키를 이용해서 커서가 있는 키워드가
어느 헤더화일에 정의되어 있는지가 path 및 include
된 헤더화일에 근거해서 쭈욱 보여줍니다. 이 기능이
ctags 이나 cscope 처럼 무작정 다 보여주는 기능과는
다르게 아주 쓸만 합니다.
다른 분들은 어떻게 생각하시는지 궁금하군요. 그냥
관심있는 분야의 스레드가 있길래 생각없이 긁적여
봤습니다.
vim을 써본지 2일째되는데, 이것을 이용해서 좀 많은 것을 공부하고 싶
vim을 써본지 2일째되는데, 이것을 이용해서 좀 많은 것을 공부하고 싶은데,
자료가 좀 부족하네요..
혹시 ctag 와 cscope에 대해 vim에서 사용할 때 실제
사용예를 좀 알 수 있나요....
.cshrc 에 path 설정하는 것이나, vim에 어떤 파일에 어떻게 설정을 해야
기능이 실해되는지에 대해서요....
답변 부탁드립니다......
자세한 설명 아주 재미있게 잘 읽었습니다... :-)
자세한 설명 아주 재미있게 잘 읽었습니다... :-)
http://sources.redhat.com/sourcenav에 가
http://sources.redhat.com/sourcenav
에 가보세요. 좋더군요.
리눅스, 윈도용도 있고.. 써보
니.. 이만하면 왠만한 소스는
다 분석하겠더군요.
근데 프로그램 사용법이 윈도용
이 아니라서 조금...
redhat사의 source navigator가 있습니다.물론 리
redhat사의 source navigator가 있습니다.
물론 리눅스용과 windows용이 무료로 사용가능합니다.
다음을 참고 하세요.
http://sources.redhat.com/sourcenav/
SN452.tar.gz을 다운 받았는데요...저 초보라... ;;
SN452.tar.gz을 다운 받았는데요...
저 초보라... ;;
압축 풀고 tar 풀고...
그 다음에 아무리 찾아봐도 실행파일이 없는걸요...
이것저것 막 눌러봐도 실행이 안되서.. ;;
제 컴터가 좀 깡통이거든요.
이 프로그램에서 실행파일의 위치가 어디에 있는지 알려주세요.
흐흑... 언제 초보탈출해서 리눅서라구 해보남.. ㅜ.
lxr 하고 cscope 좀 얻을 수 있을까요?
소스코드 분석해야 하는데.. 소프트웨어가 절실히 필요합니다.
source insight 쓰고 있긴 한데.. hyper text로 만들려구요.. lxr이 필요합니다.
cscope는 관심이 있구요..
초보자가 간절히 부탁드립니다.
감사합니다.
제 메일은 hwang.jinho@gmail.com 입니다.
음. lxr, cscope 모두
음. lxr, cscope 모두 인터넷에서 무료로 다운로드 받을 수 있습니다.
검색해 보시구 못 찾으시겠다면 답글달아주시면 검색해서 링크 추가하겠습니다.
그리고 소스코드를 hyper text로 만드는 경우에는 lxr이 아닌 doxygen을 사용하셔야 하지 않나요?
제가 알기로는 lxr은 서버(apache등의)를 돌리고
lxr에서 소스코드 디렉토리를 직접 접근하는 것으로 알고있습니다.
(혹시 제가 잘못알고 있다면 지적 바랍니다.)
doxygen은 소스코드에서 HTML문서를 자동으로 생성해줍니다.
따라서 소스코드 분석에도 유용하게 사용하실 수 있을 것 같습니다.
http://www.stack.nl/~dimitri/doxygen/
소스 분석을 위해서
소스 분석을 위해서 몇 가지 툴을 써 봤습니다. vi와 ctag 조합, source navigator, source insight를 써봤는데, 이것들 중에서는 source insight가 제일 좋더군요. 유료라는 단점이 있긴 하지만요.
Heejoon Lee
소스코드를 분석하기 위한 방법
RHG-Ruby Hacking Guide라는 책은 루비 소스코드를 설명하는 책입니다. 리눅스로 말하자면 Understanding Linux Kernel같은 책이지요.
책의 첫머리에 소스코드를 읽는 방법에 대한 개요가 나옵니다.
소스코드를 분석하기 위한 툴에 대한 설명보다도, 그 마음가짐이라던가 파악하는 과정이 꽤 마음에 듭니다.
언제나 삽질 - http://tisphie.net/typo/
프로그래밍 언어 개발 - http://langdev.net
딱 봐서 삘이 꽂히는
딱 봐서 삘이 꽂히는 코드들이 있습니다.
그럼 분석하고,
안그러면 집어치워버립니다.. 으흐흐
[농담] 아니 C언어가
[농담]
아니 C언어가 가장 많이 쓰는 언어라니요!
국립중앙과학관에 가면 지금 가장 많이 쓰는 언어는 포트란이라고 되어있는걸요.
Real programmers /* don't */ comment their code.
If it was hard to write, it should be /* hard to */ read.
익명사용자의 잔치
왜 죄다 익명으로 쓰셨을까요?
지금 소스코드 해석에 관한 방법론을 봤는데요
소스코드 해석에 관한 방법론도 있네요.
hira method. 지금 보는 소스에 바로 적용해 보고 싶군요.
소스 코드 분석 경험.
glibc의 rtld (런타임 링커 에디터) 소스 코드 부분만을 분석해 본적이 있는데요.
소스 코드 라인 단위로 말에요. 어느 정도 분석이 되니까... 자료 구조라든지 그런거 추출되고
코드 흐름이 파악되더라구요. 그리고 기존에 알려져 있던 glibc 공격과 관련된 부분들도 프랙 매거진
(phrack.org)에 있는 기법들을 어떻게 적용했는지 대충 알 수 있었구요. 많지는 않지만요.
보안에 대해서 많이 파악되는거 보다 프로그램에 대한 이해도만 넓혀지는 감이 없지 않아 아쉬웠지만요.
개인적인 경험 적어 봅니다.
http://kernelhacking1.blogspot.kr (제 블로그임.)
딱히 왕도라는 건 ...
뭐 ... 뻔한 이야기지만 익숙한 게 최고라고 하잖아요. 근데, 왕도는 없지만 확률적으로 좋은 방법은 있다고 생각합니다. (그게 왕도인가?? ......)
https://coderlife.tistory.com/137
- 제작 의도를 파악한다
- 이곳엔 이게 있고, 저곳엔 저게 있다는 걸 대충 파악한다
- 실행 환경을 갖춰본다 (100%가 아니어도 괜찮다)
- 일단 실행시킨다
- 막 써본다
- 버그가 나건 말건 일단 막 쓴다
- 그리고 코드를 본다
- 일단 본다
- 또 본다
- 담배 하나 핀다
- 봐선 안 되겠다 싶어 문서를 뒤진다
- 문서만 본다
- 문서만 보다가 졸기도 한다
- 문서와 코드를 매칭시킨다
- 잘 모르겠다며 도움을 청한다
-- 도움 청할 개발자가 없으면 다시 처음으로 돌아간다
-- 문서가 잘못되었으면 문서 만든 사람한테 따진다. 그래 봐야 바뀌는 건 없지만
- 한숨을 쉬며 퇴근한다
- 그리고 다시 반복한다
전 이게 왕도라고 생각해요.
댓글 달기