하나는 남이 가르쳐 주는 것을 배우는 것. 이 것은 태어나서 24년간 - 길면 더 길어질 수 있겠지만 - 눈 앞에 있는 공부의 대부분이다. 물론 그 중에서도 두 번째 종류의 공부를 찾아내서 하는 경우도 많지만, 이 경우는 이게 힘들다는걸 모르고-_- 하는 것이기에 공부라고 생각 안하는 경우도 있고, 그닥 무게있게 생각하지 않는 경우도 많다.
남이 가르쳐 주는 것을 배우는 것은, 물론 그 자체도 상당히 어려운 일이지만, 비교적 쉬운 편이다. 음식에 비유하자면 이런거다 - 누군가 먼저 입에 넣고 오물오물 씹어서, 부드럽게 만들어논 음식. 이미 1차적으로 소화된 것이기 때문에 질기지도 않고 소화가 안돼 고생하는 일도 없다. 물론 가르쳐주는 사람이 노력한다는 전제 하에서다. 여하튼 이런 공부는 사람이 머릿속에서 미리 체계화시킨 것을 그대로 전수받는 것이기 때문에 배우기도 쉽고, 이해하기도 쉽고, 무엇보다 애프터서비스가 된다.
근데 이 두번째 공부, 스스로 배우는 것은 여러가지로 다르다. 차원이 다르단걸 요새 느끼고 있다. 책과 material, 소스코드를 보면서 열심히 공부를 해보고 있는데, 무지하게 질기다. 게다가 달콤하지도, 자극적이지도 않고 무덤덤하니 쓰다. 씹어도 씹어도 질겨서 입 안에 문 채로 보채고 있다. 더 열심히 씹으면 삼킬 수 있을 것 같은데, 안씹던 질긴걸 씹다보니 턱이 다 아프다. 약간씩, 그 안에 있는 진국이 나오면서 나름의 맛이 느껴지기 시작하긴 했지만 본격적으로 느끼기엔 한참 멀었다.
뱉어내면 내 인생 꼬이는거고(ㅋㅋ) 계속 물고 있으면 분명히 충치가 생길거다. 그래서 난 씹어야만 하는데, 그 질긴 촉감이 머릿속에 남아서 씹는게 싫다. 에휴우
내가 다니는 학교 POSTECH은 기숙사 학교기 때문에, 배달 음식을 시켜먹는 일이 잦다.
근데 요즘 돈도 없었고 먹을 일도 잘 없어 배달음식을 자주 안시켜먹었더니, 뭐가 맛있고 뭐가 괜찮은지 모르는 상황에 이르렀다.
그래서 랜덤으로 배달메뉴를 고르는 프로그램을 만들어야겠다는 결론에 도달했다.
루비로 짰는데, CGI로 짤려고 했더니 매번 호출때마다 파싱해 오는게 너무 느려서 standalone web server로 만들었다.
웹서버 코드는 웹서핑 해서 나온 코드를 대충 때려박아 넣었다.
핵심인 배달업체 페이지 분석에서 학교 홈페이지가 공개되면 여러모로 곤란해질듯 하여 그 부분은 X로 마스킹 했으니, 그냥 켜면 절대 돌아가지 않는다.
이전에 만들었던걸 좀 더 개량했다. 광고를 받아다 보여주는 것으로 보이는 함수 (00577F40)의 시작을 RETN으로 덮어쓰고, 리소스를 편집해 상단부 뉴스티커가 아예 애초부터 안보이게 고쳤다. 덤으로 채팅창의 광고도 제거했다.
과정 보기
일단, 광고 창의 class를 spy++ 등으로 보면 #30770으로 다이얼로그인 것을 확인할 수 있다. 다이얼로그를 생성하는 API함수는 CreateDialogParam이나 CreateDialogIndirectParam, DialogBoxParam 등이 있는데, DialogBox... 는 Modal 다이얼로그를 생성하지만 광고창은 실제로 떠 있는 동안 다른 창을 선택할 수 있는 Non-modal이다. 따라서 USER32.DLL 모듈에서 CreateDialogParam, CreateDialogIndirectParam을 찾아 브레이크를 걸어준다. 물론, 이 두 함수 모두 스트링을 다루기 때문에 A/W가 붙은 변종들이 있다. XP 이상에서는 A류는 W를 부르는 래퍼일 뿐이므로 W에만 걸어도 무방하다.
그 다음 적당히 실행시켜보면서, 몇 번째 호출때 광고창이 생성되는지 본다. 횟수를 확인한 후에는 광고 창을 만드는 CreateDialogIndirectParam(해 보면 CreateDialogParam은 호출되지 않음을 알 수 있다)을 실행하기 전에, 이 함수를 호출한 Caller들을 Calling Stack을 확인해서 하나씩 브레이크를 걸어본다.
함수의 calling convention에 따라서 stdcall인지 cdecl인지에 맞게 함수 호출를 무시하고 지나가보면, 적당한 위치에서 죽지 않고 무사히 실행되는 부분을 확인할 수 있다. 현재 네이트온(버전 4.0.10.4 (1481))에서는 그 위치가 00671d08이다.
잘 보면, CALL 뒤에 스택을 정리하는 부분이 보인다. 따라서 저 함수는 cdecl이고, 함수의 리턴 방법은 RETN 명령으로 바로 리턴하는 것이다.
RETN은 기계어로 C3이므로, 함수 호출을 따라 가서 00577F40을 C3으로, 명령이 2byte였으니까 다음을 90으로 넣어주면 함수가 완전히 무시된다. 그러고 실행시켜보면 켜자마자 뜨는 광고가 사라진다! 만세ㅋ
그 외의 광고 제거는 리소스 해커 등의 툴을 이용해서 132번과 163번 다이얼로그의 전광판, 광고티커에 주어진 스타일 중 WS_VISIBLE 을 빼면 된다.
압축을 푼 다음, nateoff.bat 을 실행시키면 패치가 진행된다. 이전에 네이트온을 종료시켜주는건 센스.
넷북을 쓰다 보면, 무선 연결이 불안정할 때가 많아 수시로 끊어진다. 그 자체는 문제가 아닌데, 그러다 보면 메신저들이 신나게 재접을 해대는 상황이 벌어지기 마련이다. 이 때 문제가 되는 것이, 네이트온의 경우 쓸데없는 광고가 뜬다는 것이다.
이 쓸데 없는 광고는 얼마나 쓸 데가 없냐면, 광고가 떠도 앞에 안 나오고 뒤에 숨어 있다가 네이트온 쪽지가 와서 보려고 쪽지창을 클릭할 때 광속의 속도로 전면으로 튀어나와서는 대신 클릭당한다. 그러면 Internet Explorer가-심지어 기본 브라우저를 딴 것으로 바꾸어두어도!-뜨면서 그게 완전히 뜨기까지 네이트온은 먹통이 되고, 그게 뜬 뒤에도 한동안 버벅거리는 것은 상당한 짜증을 동반시킨다.
그래서 나는 광고를 없애버리기로 다짐했다. 하는 김에 네이트온 접속 후의 스킨을 수정해서 광고를 떼보았다. 요놈도 상당히 자리를 차지해 넷북으로썬 상당히 귀찮다.
이것도 저것도 모르겠다, 하는 사람은 첨부된 파일을 받아다 적당히 풀면 되겠다. xml파일은 C:\Program Files\NATEON\Skins\DefSkin 에, exe파일은 C:\Program Files\NATEON\BIN에 넣으면 된다.
수정한 부분은 xml 파일에서는 아랫쪽에 주석처리된 부분 밑의 tr 태그를 죄다 지웠다. 그러고 나니까 별로 안예뻐서 miniview 들어가 있는 행과 그 아래 행은 살려뒀더니 원래부터 광고가 없었던 것 마냥 이뻐졌다ㅋ
exe파일에서는 '아마도' 광고 관련 처리하는 루틴을 전부 NOP으로 때워넣었는데, 위치가 0271d08부터 약 32byte 정도 된다. add esp, 24h 까지 덮으면 된다.
요즘은 인터넷 홍수 시대라고 해도 과언이 아닐 정도로 엄청난 양의 정보들이 인터넷을 통해 유통되고 있다. 최초의 인터넷(정확히는 www:World Wide Web)은 단순히 발행된 정보를 독자에게 전해주는 단방향 커뮤니케이션이었지만, CGI라고 하는 요술방망이가 등장한 이후 사용자가 서버에게 단순히 요청만 하는 것이 아니라 정보를 제공해주고 그 제공된 정보를 서버가 다시 처리해 돌려주는 신비한 일도 발생하기 시작했다.
지금이야 php다, RoR이다, django다 하는 더 이상한 놈들에게 자리를 빼앗기거나 대체, 또는 그것들을 위한 단순한 backend 수준으로 그 위상이 격하된 CGI이지만 처음 나왔을 때는 상당하고도 신선한 충격이었고, 덕분에 Perl이라는 언어는 원래 계획됐던 보고, 시스템 관리용 언어에서 벗어나서 굉장히 넓은 지평을 갖게 되었다. 한 때 우리나라에서 유행했던 소위 “설치형 웹게임”이란 놈들은 거의 다 이 Perl로 짜여지기도 했다.
Perl은 시스템 관리용으로도 쓰였기 때문에 웬만한 머신에는 다 설치되어 있었고, 따라서 CGI를 쓰는 데는 큰 문제가 없었지만 가끔씩 Perl이 설치되지 않았거나 Perl을 사용할 수 없는 웹서버가 있었고, 또 Perl이란 언어 자체가 내부적으론 컴파일링을 하지만 원시 코드(source code)를 그대로 입력받는 언어였기에 필연적으로(하지만 지금은 전혀 상관없는) 속도가 느려지기 마련이어서, 가끔 바이너리로 된 CGI가 배포되기도 했었다.
하지만 이제 와서는 사실, Perl이 안 깔린 머신도 없고 웬만한 기능은 다 Perl, python, ruby 등의 언어로 바인딩이 제공되고 있으며 저런 것을 쓰더라도 속도 문제에 있어서 전혀 신경을 쓰지 않아도 될 정도의 시대인지라, C로 CGI를 만들겠다는 것은 정말 뻘짓이 아닐 수 없다. 그럼에도 불구하고 C로 CGI를 만들어야 하는 이유가 있다.
C는 모든 언어의 기본이다. 이 말은 C가 정말 기초적이기 때문에 이 것을 배워야 다른 언어로 CGI를 짤 수 있다는 되도안한 소리가 아니다. 무슨 뜻이냐면, 특히나 Linux의 경우, 대부분의 라이브러리들이 1차적으로 C 언어로 된 인터페이스를 갖는다. 거기에 추가적으로 필요하다면 각 언어용 바인딩이 제공되어 설치하여 쓰게 되어 있다. 따라서, Perl이나 python, ruby용 바인딩이 설치되어 있지 않은 어떤 라이브러리를 사용하고 싶다면, 그 바인딩을 구해서 사용할 수 없는 경우엔 C로 짜는 것이 대안이 될 수 있다는 것이다. 이 '사용할 수 없는 경우'라는 것은 상당히 많은 경우를 포함하는데, C와의 호환이 필요한 라이브러리의 경우 C로 컴파일해야 하는 경우가 자주 발생한다. 이 때 가끔씩, 뭔가 알 수 없는 이유로 컴파일이 안되는 경우가 발생하기도 하고, 컴파일을 무사히 마치더라도 적절한 위치에 넣을 수 있는 권한이 없어 실패할 수도 있다. 기본적으로 각 언어별로 제공되는 확장기능 관리 기능을 통해 설치하려고 해도 보통은 권한이 없어서 그것도 여의치 않다. 하지만, 어쨌든 간에 그 라이브러리가 머신에 깔려만 있다면, 헤더파일만 있으면 C에서는 가져다 쓰는 데 큰 문제가 없다.
... 두 번째 이상의 이유를 찾아보려 했지만 도저히 모르겠다. 나도 C로 두 개의 CGI를 '이시대에' 만들었지만, 왜 했는지 지금 생각해보면 참 바보같다. 물론, 이 선택을 하지 않으면 관리자 권한이 없는 웹서버에 내가 원하는 기능을 갖는 CGI 만들기는 불가능했을 것이기 때문에-그리고 그 웹서버를 버릴 수도 없는 상황이라- 어쩔 수 없었지만.
서론은 여기까지 하고, 먼저 단순한 예제를 보자. 아마 다른 언어로 CGI를 만들어 봤으면 다음 예제가 뭐하는 것인지, 더해서 얼마나 무의미한 것인지 알 수 있으리라고 생각한다.
별 것 없다. 컴파일해서 대충 first.cgi 정도로 이름을 바꿔 적당한 곳에 넣어주자. 아, 이야기하는 것을 깜빡했는데, 적어도 이 글은 'C 언어로 된 간단한 소스파일을 이해할 수 있고 CGI 사용을 위한 웹서버 설정을 할 수 있는 사람', 또는 'C 언어로 된 간단한 소스파일을 이해할 수 있고 CGI 사용이 가능하도록 설정된 웹서버를 가진 사람'을 대상으로 하고 있다. 따라서 독자 여러분께서는 first.cgi로 접속하는 법을 알고 있을 것이다.
접속해 보면 웹브라우저에 달랑 ”안녕, 세상아!” 라는 글이(당연히 따옴표는 없다) 찍힌 것을 볼 수 있을 것이다. 이 단순한 소스 코드가 의미하는 바는 다음과 같다.
puts("Content-type: text/plain\n");
실제로는 puts가 문자열을 출력할 때 맨 뒤에 개행문자를 하나 더 붙이므로 개행이 두 번 일어나게 되어 빈 줄 하나가 생긴다. 이 명령이 수행하는 것은 '이 CGI가 출력할 내용물의 타입은 text/plain입니다'하고 클라이언트에게 알리는 것이다. html을 출력할때는 text/html, xml을 출력할 때는 application/xml, png파일일 때는 image/png가 된다. MIME을 찾아봐라.
puts("안녕, 세상아!");
위에서 출력한 헤더의 내용이 나온다. 단순한 텍스트로 안녕, 세상아! 가 출력된다.
기본적으로, CGI가 표준 출력(stdout)으로 출력하는 내용이 클라이언트로 전송되게 된다. 그런데 클라이언트에서 접속했을 때 500에러가 나온다면, 첫째로 헤더 출력하는걸 깜빡했거나 잘못된 헤더를 출력하는 경우이고, Perl이나 다른 언어로 만들었을 경우와 다르게 Segmentation Fault가 난 경우에도 500 에러가 난다. 절대 Segmentation fault 이전까지 출력한 내용이 나오지 않으므로(Apache2의 경우) 알아둘 필요가 있다.
다른 언어로 CGI를 만들어 봤다면 알겠지만, CGI는 서버와 클라이언트의 정보를 환경변수와 표준 입력으로 얻는다. C로 짜는 경우도 큰 차이가 없다. 환경변수 정보를 확인하고 싶다면 다음 CGI를 만들어서 테스트해보면 좋을 것이다.
#include <stdio.h>
int main(int argc, char ** argv, char ** env)
{
int ch;
puts("Content-type: text/plain\n");
while(*env) puts(*(env++));
puts("This is stdin:");
while((ch = fgetc(stdin)) -1) fputc(ch, stdout);
return 0;
}
요정도면 무리 없이 GET/POST 양쪽 모두 사용할 수 있을 것이다. 참고로, %xx 형식으로 escape된 것은 직접 unescape 해 주어야 한다.
그런데, multipart/form-data로 encoding 된 데이터가 넘어올 때는 상당히 곤란하다. 뭔가 많이 복잡해진다는 것을 저 cgi를 통해 확인할 수 있을 것이다. 하지만 파일 업로드를 포기할 수는 없는 노릇. 이럴 때를 위해 누군가가 강력한 라이브러리를 만들어뒀다.
cgilib이라는 라이브러리인데, cgilib 홈 페이지에서 자세한 정보를 접할 수 있다. ...고는 하지만, 뭔가 문서가 부족하다. 하지만 cgilib 자체가 워낙 가볍고 작은 라이브러리인지라, 일반적으로 설치하면 cgi.h 파일이 /usr/include에서 발견되는데 이 파일을 열어서 내용을 보면 금방 이해할 수 있다. cgiInit()로 넘겨진 parameter들을 준비시켜서 cgiGetValue(), cgiGetFile()로 받아오면 된다.
Povis.rb
NateOff.zip
NateOnMain.exe
readme.txt