블로그는 귀차니즘

  한 몇일 중고장터를 잠복해 있었더니 무지 좋은게 하나 뜨더군요. 그래서 냉큼 질렀습니다. 에구 그런데 이거 다시 할 짓이 못되는군요. 사람 진이 다 빠질 정도로 신경이 쓰이고 스트레스도 장난이 아닙니다. 아마 다시 할 일이 있을까 하군요.
  색은 블랙입니다. 뭐 대충 열 세장 정도에 주워왔는데, 메모리 정품 4기가에 기스도 별로 잘 없고 엄청 괜찮은거 같군요. 그런데 이미 4기가 중 3.5기가 정도가 게임으로 가득 차 버렸습니다. CPS2PSP 를 넣어서 게임을 좀 돌려보고 바로 개발 세팅에 들어가 봐야겠군요 ^^.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

  해킹이라는 것은 아주 많이 들어보셨을 겁니다. 최근 들어서 사회가 정보화 사회로 탈바꿈 되었고, 이미 대한민국은 컴퓨터 혹은 네트워크없이는 말을 못할 정도로 크게 발전이 되었죠. 그로 인해, 해킹이라는 것 또한 이슈로 떠올랐을 겁니다. 최근 들어서 옥션 개인 정보 유출등의 사건과도 연관을 지을 수도 있는 부분입니다.
  이 해킹혹은 크래킹에 있어서 주요한 원인은 어떤 것일까요? 가장 크게 말해서 프로그램 제작상 소스코딩의 오류라고 표현을 할 수 있다고 합니다. 왜 그런가 하면 아래의 코드를 한 번 보도록 할 까요?

Test.cpp (Language : cpp)

1. #include <iostream>
2.  
3. void Process()
4. {
5.     char InputData[100];
6.     gets( InputData );
7. }
8.  
9. int main( int argc, char **argv )
10. {
11.     Process();
12. }

  이 같은 경우 어떠한 문제를 불러일으킬 수 있을까요?? 흔히 C++, C 코드가 기계어로 바뀌는 과정을 대충적이나마 알고 계신 분들은 원인을 대충 아실 겁니다. 함수를 호출하기 위해서는 스택에 return 될 코드를 push 한 뒤, Call 명령 혹은 Jmp 명령으로 호출하게 되죠, 그런데 지역 변수라는 것 또한 해당 컨텍스트의 스택에 존재하게 된다는 게 이 코드의 문제점 원인 입니다.


  이와 비슷한 형태를 띄고 있기 때문에 만약 데이터를 읽는데 있어 return 될 주소의 코드가 다른 정보로 뒤 덮어씌워진다면 어떠한 문제점이 생길까요? Process 함수를 호출한 뒤, main 함수로 다시 돌아가지 않고, 어떠한 특정 함수로 호출이 될 수 있다는 점이 문제입니다.
  이 게 만약 Linux, Unix 쪽의 텔넷 터미널 쪽으로 접속되었을 때 수행이 되는 코드라고 생각을 해 봅시다. 그럼 악의적인 목적을 가진 사용자가 Telnet Control 소켓으로 일반적인 키보드로는 입력할 수 없는 데이터를 전송하여 return 코드를 덮어씌워버릴 수 있지 않을까요? 만약 그렇게 된다면 특정 커널 코드로 return 주소를 수정할 수 있고, 그로 인해 사용자의 권한이 관리자의 권한으로 지정되게 될 지도 모르겠죠.
  그런데 이러한 코드가 저런 부분만 해당 되느냐 하면 그것은 또 아닙니다.

strcpy.cpp (Language : cpp)

1. #include <iostream>
2. #include <string>
3.  
4. int main( int argc, char **argv )
5. {
6.     char InputData[100];
7.     std::string Input;
8.    
9.     std::cin >> Input;
10.     strcpy( InputData, Input.c_str() );
11.  
12.     return 0;
13. }

  위와 같은 코드일 경우 문제점이 생길 것 같다는 생각이 들지 않나요? 바로 strcpy라는 함수에 바운더리를 계산하는 부분이 없어서 그렇습니다. 입력된 문자열이 길다면 그냥 데이터를 뒤집어 씌운다는 점으로 인하여 잠재적인 보안의 위협적 요소를 가지게 된다는 점이 중요합니다. strcpy 함수의 내부 구현은 아마도 '\0', NULL 문자가 나올 때 까지 해당 Dest 문자열에서 Src 문자열 까지 복사를 하도록 구현이 되어있을 겁니다. 그리하여 문제점이 생길 수 있는 것이구요.
  그래서 strcpy 대신에 strncpy를 사용하도록 권고가 되었고, 이 것 또한 모자라서 VS.net 2005 이상 부터는 strcpy_s 를 사용하도록 기존 문자열 함수들은 디프리케이트 된 것으로 알 고 있습니다. 사용하지 말라고 비권고까지 시켜버렸는데 굳이 사용할 이유는 없겠죠?
  책을 더 읽어서 유용한 정보가 있으면 더 올려보도록 하겠습니다. 이러한 보안요소는 지켜가며 코딩을 해야 겠다는 생각이 줄줄 드는군요^^;

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

  한 횽님 덕분에 뽐뿌질을 2차로 받아 드디어 PSP를 지르겠다고 생각을 하고 물량을 찾아보는 중인데 좋은 게 잘 없군요. 신형을 그냥 살까 고민이 조금 됩니다. 프로그램은 괜찮게 약간이라도 쓸모 있는 게 생각이 났는데, 기기가 있어야 제대로 시작을 해보지 않을까 합니다. 이럴 땐 서울에 있는 게 엄청 부러워 지는군요. 다만 환경은 저질스럽겠지만 말입니다.
  총알은 탄창이 연발로 준비되어 있는데 과녁이 안보이는군요. 천지 이래선 쏴봐야 맞지도 않겠습니다. 어서 적이 나타났으면 하네요. 내일은 가상 캠퍼스 신청 해놓은게 있어 시험도 쳐야 하는데, 에구 ㅠ_ㅠ 시간은 없고 해야할 건 많고, 엄청 빠듯하네요.
  당분간 물건 구하는데 총력을 기울여 보겠습니다. 너무 직거래쪽만 구해서 그럴까요. 택배 거래도 한 번 생각해봐야 하지 않을까 라는 생각이 들기도 하는군요. 프로그램은 FTP 서버 프로그램도 개발해보고, 파일 공유 프로그램도 만들어 보고, 기타 재미있는 프로그램을 만들어 보고 싶군요.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

  컴퓨터로 프로그램을 만들어보신 분이라면 컴파일러 혹은 인터프리터라는 단어를 한 번쯤은 들어보셨으리라 생각합니다. 그만큼 필수적인 단어이자 프로그램 이죠. 이 프로그램들이 없으면 실행이라는 것 자체가 불가능하니까요. 그럼 이 부분은 어떻게 인식을 하게 될까요?
  아시는대로 컴퓨터는 자동적으로 알아서 프로그램을 생성하는 것이 아니라 코딩을 통한 작동명령을 제시해주어야 합니다. 그렇지 않으면 제대로 동작하지도 않을뿐더러 어떠한 역할을 수행하지도 못하겠지요. 그럼 어떻게 문법적 구문을 인식할까요? 그건 바로 오토마타를 통한 LALR(N), LR(N) 등의 문자열 파싱 방법등으로 처리하곤 합니다. 물론 학교에서만 배운 지식이기에 현재 자주 사용하는 gcc, C++ Builder, VS.net C++ 등의 컴파일러는 더 최신의 기술을 사용할지도 모릅니다. 하지만 기본은 아마도 비슷하겠죠?
  그 문법적 문자열을 인식하는것은 일일히 코딩을 통하여 인식을 할 수도 있겠지만 그 것은 시간적으로도 키보드의 플라스틱으로도 낭비가 아닐 수 없습니다. 왜냐하면 yacc, lex 등의 좋은 툴이 많이 나와있기 때문이죠. 그 것과 더불어 boost에는 spirit 이라는 라이브러리가 존재합니다. 아마도 규모면에서는 약간 적은 프로그램에서 사용될 것 같습니다. 그럼 대충 어떻게 사용하는지 알아볼까요??

CalcExpr.h (Language : cpp)

1. #pragma once
2.  
3. #include <boost/spirit/core.hpp>
4. #include <string>
5.  
6. using namespace boost::spirit;
7.  
8. typedef rule< scanner< wchar_t const * > > Rule;
9.  
10. class CCalcExpr
11. {
12. public:
13.     CCalcExpr(void);
14.     ~CCalcExpr(void);
15.  
16.     static bool TryParse( std::wstring &Str, size_t &ErrIndex );
17. };

CalcExpr.cpp (Language : cpp)

1.  
2. #include "stdafx.h"
3. #include "CalcExpr.h"
4.  
5. CCalcExpr::CCalcExpr(void)
6. {
7. }
8.  
9. CCalcExpr::~CCalcExpr(void)
10. {
11. }
12.  
13. bool CCalcExpr::TryParse( std::wstring &Str, size_t &ErrIndex )
14. {
15.     Rule Expr;
16.     Rule PowOp      = *space_p >> L'^' >> *space_p;
17.     Rule MulOp      = *space_p >> ( ch_p< wchar_t >( L'*' ) | ch_p< wchar_t >( L'/' ) ) >> *space_p;
18.     Rule AddOp      = *space_p >> ( ch_p< wchar_t >( L'+' ) | ch_p< wchar_t >( L'-' ) ) >> *space_p;
19.    
20.     Rule Symbol   = +( range_p( L'A', L'Z' ) | range_p( L'a', L'z' ) );
21.     Rule Function      = ( Symbol >> L'{' >> ( Symbol | real_p ) >> L'}' );
22.     Rule Value      = real_p | ( L'[' >> Function >> L']' );
23.     Rule Element        = ( L'(' >> Expr >> L')' ) | Value;
24.     Rule MinusElement   = ( L'-' >> Element ) | Element;
25.     Rule Factor   = ( MinusElement >> PowOp >> Factor ) | MinusElement;
26.     Rule Term         = ( Factor >> MulOp >> Term ) | Factor;
27.     Expr                = ( Term >> AddOp >> Expr ) | Term | end_p;
28.  
29.     parse_info< wchar_t const * > Parse_Info = parse< wchar_t >( Str.c_str(), Expr );
30.  
31.     if( !Parse_Info.full )  {
32.        
33.         ErrIndex = Parse_Info.length;
34.         return false;
35.     }
36.  
37.     return true;
38. }

  사용은 boost가 흔히 그렇듯이 boost에 속하는 hpp 파일을 include 시켜주어야 합니다. 목적 헤더파일은 core.hpp 파일입니다. 이 boost::spirit이 지원하는 부분은 문법을 분석하고 문법이 실행되는 것 까지 지원되나, 제가 거기까지는 사용을 못해봤으므로 일단 입력 문자열이 맞는지 검사하는 부분으로 진행하겠습니다.
  일단 문자열이 파싱이 되느냐 되지 않느냐를 판단하기 위해서는 Rule 이라는 것이 필요합니다. 이 것이 무엇이냐 하면 오토마타때 배우는 EBNF( Extended Backus Naur Form )와 동일하게 생각하시면 됩니다. 즉 하나의 룰이 하나의 Non-Terminal을 표현한다고 보시면 됩니다. 위 코드는 제가 IPangYa 라이브러리에서 계산수식을 인식하여 정확한 것인지 파악하기 위하여 작성하였던 코드입니다. 나름 고생도 했죠.
  룰을 만들기 위해서는 Rule 형태의 변수를 선언을 하게 되고 = 연산자 우측엔 >> 로 이루어진 룰의 조합이 존재하면 됩니다. 예를 들면 ch_p< wchar_t >( L'+' ) >> L'(' 이렇게 된다면 +( 이라는 문자열을 인식하는 룰이됩니다. C++ 에 존재하는 라이브러리 답게 *, | 연산자들을 오버로딩 하여 룰을 C++ 문법으로 간단히 표현할 수 있도록 제작이 되어있습니다. 그러므로 Expr에서 (abcc)*, (abcc)+ 와 같은 문자열 형식을 인식할 수 있습니다.
  물론 ParseTree가 제작되기 위하여 *, /, +, - 등의 연산자 오버로딩을 정해주기 위하여 룰의 위치, 순서들을 먼저 조절 해주어야 합니다. 그게 약간의 사용법에 있어서 어려움이 될 수도 있습니다. 종이의 룰은 그냥 적으면 되지만 OOP라고는 하지만 내부 함수는 절차지향이니 그 순서를 생각한다면 반대로 생각해야할 부분도 있기 때문이죠. 만약 이러한 작업들을 통하여 Rule이 생성되었다면 boost의 parse 함수를 이용하여 최상위 룰과, 입력 문자열을 같이 넣어준다면 작업을 수행하고, parse_info의 변수에 에러 위치, 혹은 성공 여부를 채워주게 됩니다. 무척 간편하죠?^^
  필요한데 간단간단하게 제작을하여 사용하려면 이러한 것들을 사용하는 것은 어떻까요?

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

  네이버 같은 곳에 개인정보 유출에 대한 기사가 뜬다면 달리는 댓글에는 필수적으로 욕이 달리는 것을 쉽게 볼 수 있습니다. 최근 옥션으로 인하여 무척이나 개인정보유출에 대한 관심이 극도로 높아져 있는 시기이기 때문이죠.
  그런데 혹시 LGT 유출 사건은 들어보셨나 모르겠습니다. 올해 3월 중순쯤 에 일어났던 일이라고 하는군요. 그런데 이걸 어떻게 알게되었냐면 디시인사이드(http://www.dcinside.com )에 존재하는 프로그래밍 갤러리에서 였습니다. 이게 진실적으로 언론에 대한 불신감을 조금 가져다 주는 것에는 충분하게 보이더군요.
  왜 그러냐구요?? 물론 제가 당사자가 아니기 때문에 엄청 자세한 사실 까지는 잘 모르는 상황입니다만 지금 LGT 쪽에서 소송을 걸고 현재 불구속 입건까지 처해있는 상황에서 객관적으로 봤을 때, 약간은 핀트가 어긋나있지 않은가 하는 점, 피의자로 몰아붙이는 듯한 느낌을 받는 점입니다.
  일단 첫 째 가장 큰 책임은 LGT 에서 제공을 했다고 할 수 있습니다. 왜냐하면 웹에서 기본 인자 전달 방식인 Get, Post 방식 중 Get으로 드러난 정보를 손 쉽게 가공하여 접근을 할 수 있기 때문입니다. 실제로 해당 http://fguy.tistory.com의 주인장 되시는 분은 URL중 번호를 가르키는 인자를 다른 번호로 바꿈으로써 접근을 하는 링크역할 페이지만을 만들었습니다. 그게 사실적으로 숨겨져 있는 정보도 아니고, 번호에 대한 CRC 검사를 하는 부분도 없었습니다. 그래서 그냥 전화번호만 바꿈으로써 해결이 된것이죠. 여기서 알 수 있는 것은 보안에 대하여 아무런 지각이 없는 상태에서 개발을 하여 그렇게 되지 않았을까 하는 점입니다.
  실제, 원래 모샵이라는 사이트에서 사용을 하기 위해서 대학산학쪽으로 개발을 의뢰하고 진행이 되었다고 하는군요. 그 개발과정이라는 것이 어떻게 된 것인지까지는 잘 모르겠습니다. 하지만 비밀번호조차 Sql Injection으로 인한 해킹문제점이 여러차례 알려진 것도 사실이고, 어느정도 IT강국이라고 언론에서 떠들어 대는 나라에서 그런 부분에 미흡했다면 그래도 어느정도 막으려는 의지를 보였다고 할 수 있을 것인데, 이 경우는 전혀 아닌것 같군요. 눈으로 보기에도 확연히 허술하니까요.
  게다가 모샵에서 서비스한 기간이 상당히 오래되었다고 합니다. 실제적으로 데이터를 어느누가 얼마나 빼갔는지는 현재 알 수 없는 상황이라는거죠. 그런데 한 꺼번에 마침 잘 걸렸다는 듯이 책임을 몰아붙이고 진행을 하는 듯 합니다.
  물론 저 분이 책임이 없느냐 하면 그 것도 아니라고 생각합니다. 연결을 해주는 페이지를 만들어서 공개를 하고, 그로인해 다른 사람이 접근을 아주 쉽게 할 수 있다는 것이 저 분의 가장 큰 문제점입니다. 그게 아니고 과정이라던가, 비밀글로 만들어졌다면 최소한 이러한 문제점과, 소송으로 진행되는 것 만은 막을 수 있었겠지요. 그렇지 않을까요?
  그러므로 제가 볼 때는 지금 LGT쪽에서 주장하는 개인정보유출이라는 사건은 약간 어감을 달리해야 하지 않을까 하네요. 왜냐하면 개인정보 유출을 위하여 데이터를 저장한 것이 아니라, 그냥 통로만을 열었을 뿐이니까요. 데이터를 다른 용도의 사용목적으로 따로 사용하기 위하여 저장한다는 것이야 이 사람에게 충분히 악의가 있었고, 처분의 당위성이 생기겠지만, 이 건 좀 아닌것 같지 않나요? 한 번쯤 생각을 해보시는게 어떨까 합니다.

  저도 나름 컴퓨터로 밥을 벌어먹은지 1년 3개월 째가 되어가고 있기에, 약간은 개인 개발자에게 팔이 굽을수도 있고, 안타까운 점도 없지 않아 있습니다. 이 사태가 하나하나 진행되어가고 있는 것이 기사에 보일때 마다 아쉬운 감을 느낄 수 밖에 없군요.
  우리나라가 언론에서 IT강국이라고 떠들지만 실지 현재는 그렇게 여겨지는 것 같지 않습니다. 인터넷에서 만나는 많은 개발자 분들 중에서 적지않은 수가 IT강국이 아닌 IT소비강국이라고 정정해야 한다고 하시더군요. 아마 이러한 것들도 있기 때문이 아닐까 합니다. 뿐만 아니라 자체적인 기술력이 없는 것도 하나의 문제점이 될 수 있겠군요.
  앞으로 우리나라가 진정으로 IT강국이 되려면 이러한 사소한 문제점과 허술한 보안의식이 먼저 고쳐져야 진정 IT강국으로 발돋움을 할 수 있지 않을까요? 이번 LGT 사건을 보면서 착찹함을 금할 길이 없어 글을 올려봅니다. 그래도 전 이런것 때문에 나름 "완벽한 보안을 위한 C and C++ 코딩" 이런 책도 사보고 있는데 말이죠. 어찌 되었든 개인적으로는 잘 해결이 되었으면 합니다. 중간중간 삼천포로 빠지더라도 양해하고 봐주시길^^;

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.