자유로운설탕

  이번 시간에는 리버싱(리버스 엔지니어링: Reverse Engineering)과 포렌식(Forensic)에 대해서 이야기 해보려 한다. 시작하기 전에 먼저 양해를 구하고 싶은 부분은 이 두 분야에 대한 실무를 해본적이 없기 때문에 그다지 자신이 없다. 다만 어떻게 이 두 분야를 바라봐야 할까에 대해서 간단한 예제들를 중심으로 이야기를 풀어보려 한다.

[목차]

1. 보안을 바라보는 방법

2. 보안에서의 코드 읽기

3. 인젝션(Injection) 살펴보기 #1, #2

4. 암복호화

5. 클라이언트 코드

6. 업로드, 다운로드

7. 스크립트 문제

8. API

9. 하드닝(Hardening)
10. 보안 설계 문제
11. 스캐너 vs 수동 테스트

12. 자동화 잡

13. 리버싱과 포렌식

14. 모니터링 문제

15. 악성코드

16. 보안과 데이터

 

 

1. 들어가면서

  위의 두 개의 큰 주제를 하나의 파트로 묶은 이유는, 결과적으로 생각했을 때 두 분야의 연결점이 무척 많다고 생각하기 때문이다. 둘 중 한 쪽 분야에 대한 탄탄한 지식은 다른 분야를 접근 할때 허들을 많이 낮출테고, 일을 함에 있어서도 공통이 되는 지식 분야가 분리하기 힘들 정도로 많이 겹친다고 본다. 비유하자면 포렌식이 생태계과 생물들이 살아갔던 흔적에 주로 관심이 있다면, 리버싱은 생태계 안에서 살아가는 생물들의 행동 관찰에 관심이 있는 분야라고 본다. 생물을 이해하려면 생물들이 살아가는 환경을 이해해야 하고, 환경의 변화를 추적하려면 환경안에서 살아가는 존재들의 상호작용을 이해해야 할 것이다.

 

  사실 그것은 보안 전체에 대해서도 마찬가지인 부분 같다. 편의상 여러 분야로 나누어서 보안 지식을 분류하긴 하지만, 크게 보면 모든 분야가 유기적으로 얽혀 있다고 볼 수 있기 때문에, 어디나 분위기는 비슷비슷 하다고 본다. 반대로 여러 분야의 지식이 어느 정도 골고루 쌓여있지 않다면 뭔가 구멍이 뚫려 있듯이 어설픈 상태에 놓였다는 느낌이 들게 된다. 개인적으로 이 두 부분은 스스로 그렇게 느끼고 있는 구멍나 있는 부분들이기도 하다^^ 

 

 

 

 

2. 리버싱 예제 만들어 보기

  어딘가에서 만들어 놓은 샘플을 하나 가져와도 좋겠지만, 좀 더 간단하지만 통제가 되고 이해가 되는 예제를 예로 들기 위해서, 직접 C++ 로 프로그램을 하나 만들어서 비주얼 스튜디오의 정적 환경(뭐 디버깅 중이라서 동적이라고 볼 수도 있겠다)과 디버거 상에서 동적으로 실행되는 2개의 환경에서 코드를 비교해 볼까 한다. 윈도우즈 환경이기 때문에 요즘은 무료로 제공되고 있는 비주얼 스튜디오 커뮤니티(Visual Studio Community) 버전을 설치해 보도록 한다.

 

 

  구글에 "visual studio community" 라고 적으면 아래의 다운로드 링크를 찾을 수 있다.

 

[visual studio community - microsoft 홈페이지]

https://visualstudio.microsoft.com/ko/vs/community/

 

 

  다운로드 하여 실행하면 설치 화면이 나오는데, 설치를 진행하면서 Workload 탭 에서 "desktop development with c++" 기능을 체크해서 설치한다(이미 설치한 상태라서 스크린 샷은 못찍었는데 아래의 블로그를 참조하면 비슷한 듯 싶다). 뭐 다른 언어도 이것저것 공부할때 필요할 듯 하다면 설치해도 좋다.

 

[비주얼 스튜디오 2017 커뮤니티에서 c/c++ 프로그래밍 하기 - 모두의 코드님 블로그]

https://modoocode.com/220

 

 

 

2.1 리버싱 예제 만들기

  이후 프로그램을 실행을 시키고, "새 프로젝트 만들기" 를 선택한다. 위쪽 검색 메뉴에서 "c++" 를 입력하면, 아래와 같이 c++ 로 콘솔 앱을 만드는 항목이 보이게 된다. 해당 항목을 선택하고, "다음" 버튼을 누른다.

 

 

  프로젝트 이름을 "ReversingSample" 로 위치를 매번 파이썬 파일을 만들던 "c:\Python\Code" 로, 솔루션 이름을 "ReversionSample" 로 한 후, "만들기" 버튼을 누른다(나중에 디버거 툴로 선택할 exe 파일을 잘 찾을 수 있다면 기본값으로 설정 하거나 임의로 생성해도 된다)

 

 

  아래와 같이 정말 간단한 샘플 코드가 만들어져 나오는데, 간단히 기본 커맨드 화면에 "hello world" 를 뿌려주는 코드다(파이썬 코드의 print("hello world\n") 문이 하나 있다고 보면 된다)

 

코드 부분만을 분리해 보면 아래와 같다.

 

 

 

  위의 코드 자체에서 바로 살펴봐도 되지만, 그러기에는 뜯어 볼 게 너무 없는 코드이므로, 해당 내용을 모두 지우고 아래와 같이 for 문을 돌면서 Hello World 문구를 4번 입력하는 코드로 대체해 보자. 마지막에는 출력후 커맨드 창이 바로 종료되지 않도록 getchar() 함수를 넣어 사용자가 글자를 하나 입력해야 종료되도록 만들었다.

 

 

 

2.2 정적인 코드 보기

  정적인 분석을 하기 위해서 이제 화면에서 c++ 코드에 해당 하는 어셈블리 코드를 봐보자. 원래는 cl.exe 라는 명령어를 사용해서 컴파일을 해서 보는 방법을 많이 쓰는 거 같은데, 구글을 찾다보니 IDE UI 에서 편하게 볼 수 있는 기능이 있어서 해당 방식으로 보려 한다.

 

  아래의 그림과 같이 for 문 코드의 왼쪽 공간의 영역에서 마우스 왼쪽 버튼을 클릭해 빨간 브레이크 포인트를 찍는다. 이후 위쪽 Debug 드롭박스 옆의 환경을 64비트 어셈블리 코드를 보기위해서 "x86 -> x64" 로 바꾼다. 이후 그 옆의 "로컬 Windows 디버거" 버튼을 눌러서 디버깅 모드로 들어간다.

 

 

  그러면 컴파일 및 빌드가 진행 된 후, 아무것도 표시되지 않는(브레이크 포인트 땜에 아직 for 문이 돌아기지 못했으므로... 피들러에서 브레이크 포인트를 건 것과 비슷하다) CMD 창이 하나 뜨면서, 비주얼 스튜디오 창의 브레이크 포인트를 찍은 for 문 코드에서 멈춰 있게 된다.

 

  이 후, 해당 for 문 코드 위에서 마우스 오른쪽 버튼을 누르면, "디스어셈블리로 이동" 이라는 메뉴가 보이게 된다. 해당 메뉴를 클릭하면, 탭이 하나더 열리면서 현재 코드에 해당하는 어셈블리 코드가 보이게 된다(마치 브라우저에서 요소검사를 했다고 생각해도 될듯 싶다).

 

 

  그럼 위와 같은 처음 보게 된다면, 조금은 암호와 같이 느껴질수 있는 코드가 보여지게 된다. 화면을 보면 코드를 비교해 편하도록 기존 c++ 코드를 흰색 글자로 보여주고, 그에 해당하는 어셈블리 코드를 회색 코드로 보여주고 있다. 어셈블리 코드 쪽을 문법을 보면 크게 3가지의 섹션으로 나누어 지는데, 첫번째 섹션이 메모리 주소(00007FF... 같은거), 두번째 섹션이 명령어(mov, jmp 같은거), 세번째 섹션이 인자(eax)라고 보면 된다.

 

  컴파일을 하게 되면 0과 1로만 이루어진 기계어로 된 코드가 만들어 지는데 해당 코드가 CPU 쪽으로 전달되게 되어 정해진 명령어들을 수행하면서 컴퓨터가 동작하게 된다. CPU 를 0과 1로 이루어진 코드를 이용해 움직이게 하는 부분이 상상이 안간다면 파이썬 글에서도 추천했던 아래와 같은 책을 한 권 읽어보길 권한다.

• CODE 코드 : 하드웨어와 소프트웨어에 숨어 있는 언어

 

  그런 0과 1로 된 코드를 보면서 동작을 상상하는 것은, 사람들에게는 낯설기도 하고 코드도 너무 복잡해 져서 하기 힘든 일이기 때문에, 조금 더 CPU 와 상호 작용하는 부분을 동작에 따라 분류해서 사람이 읽기 쉽도록 정리한 언어가 어셈블리어이다. 지금은 일반적으로는 고대어 처럼 취급되긴 하지만, 처음 컴퓨터가 개발됬을 때에는 기계어가 지금의 c 언어 정도이고, 어셈블리어가 자바나, Python, NET 같은 사람에게 가독성과 프로그래밍을 쉽게 하도록 만들어주는 언어 였을 것 같다. 프로그래머들은 아마도 기계어를 안봐도 되는, 어셈블리 언어가 있는게 무척 고마웠을 것이고 말이다. 그런 어셈블리 언어를 다시 한번 감싼게 c, c++ 같은 언어이고, 그 것을 한번 더 추상화 한게, Java 나 Python 같은 언어일 것이다.

 

  현재는 프로그래밍 분야에서는 컴파일러의 동작을 배우거나, 임베디드 프로그래밍을 하지 않는 이상 어셈블리어를 배울일은 거의 없을 것이다(위키를 보다보니 요즘은 사물인터넷 때문에 작은 하드웨어에 최적화된 프로그래밍을 하기위해서 어셈블리어가 다시 사용이 늘고 있다고는 한다). 파이썬의 numpy 같은 특정 모듈이 성능을 위해 c 언어로 개발됬듯이, 종종 c 프로그램의 성능과 효율성을 높이기 위해서 특정 모듈을 직접 어셈블리어로 개발하는 경우도 있다곤 하지만, 꽤 드문 일일 것같다. 그래서 특정한 분야에 일하지 않고는 해당 언어를 사용하거나 볼 수 있는 기회가 드물다는게 어셈블리어를 배우는데 동기부여가 힘든 부분 중 하나인것 같다. 예를 들면 어떤 사람들에게는 평소에 전혀 안 쓰는 예전의 라틴어 같은 언어를 배우는 거와 비슷한 일이 되버릴 수 있다.

 

 

  또한 어셈블리어와 기계어는 1:1 의 매칭이 될테지만, 상위 수준의 언어와는 1 대 多, 또는 多 대 1의 관계가 될 수도 있다. 예를 들면 고 수준 언어로 갈수록 객체 지향 같은 구조적인 프로그램밍이나 코딩의 편의를 위해서 생긴 여러가지 추상적인 요소가 있을 수 있겠지만, 컴파일이 되어 실제 실행을 하는 기계어 코드 입장에서는 그런 사람을 위한 머리 꼬리들은 모두 띄어내고 실행에 필요한 요소들만 코드화 하게 할 것이다. 그렇게 됨으로서 한번 컴파일 된 언어는 다시 돌아갔을때, 원래 언어의 모양 그대로 복원하기 힘들게 되는 일이 생겨버리게 된다(아주 예쁘게 데코한 케잌을 일하면서 한 손으로 효율적으로 먹기위해 꽁꽁 뭉쳐버렸다고 생각해 보자. 원래 모양에 대한 정보가 없기 때문에 완전한 복원은 힘들다--;).

 

  또 자바나 Python 같은 언어를 사용해 보면 c 같은 언어에 비해서 사용자 코드만 만들면, 나머지 모든 것은 자동으로 연결해 움직이게 해주는 경향이 있다. 그러다 보니 실제 코딩을 한 코드가 빌드 될때, 기계어로 바뀐 후, 여러 미리 만들어진 외부 코드를 링크 하여 사용하기 때문에, 실제 기계어 입장에서 실행되는 코드는 처음 코드보다 몇 배는 부풀려져 있다. 보통 디버거를 돌릴때, 우리가 찾으려는 코드에 닿기 전에, 앞에 OS에서 움직이기 위해서 필요한 여러 코드(또는 디버깅을 방해하기 위한 방어코드)의 숲을 빠져나오는 여러가지 요령을 배우게 된다. 

 

  IDE 의 Hex-Rays 라는 플러그인을 사용하면 어셈블리어가 좀더 가독성이 높은 c++ 로 보여진다고는 하지만, 밑의 블로그에서 볼수 있듯이, 사람이 만든 변수명 등의 추상적인 정보가 다 기계어 쪽에 남아있진 않기 때문에 복원이라기 보단 어셈블리어가 문법만 c++ 로 보이도록 재구성 했다고 보는게 맞을 듯 싶다. 그리고 어째거나 c++ 도 엄청 잘해야 해당 코드를 잘 볼수 있을 테고 말이다.

 

[Reversing C++ programs with IDA pro and Hex-rays - ARIS's Blog]

https://blog.0xbadc0de.be/archives/67

 

  자바같이 여러 환경에서 자바 가상환경만 설치하면 그 위에서 호환되어 돌아가는 언어는, 컴파일을 하면 기계어가 아닌 가상환경에서 해석되는 공통 코드로 만들어지기 때문에 원래의 자바 언어로 디컴파일이 좀더 쉬운 편이다. 하지만 뭐 항상 그렇지만 코드는 점점 복잡해 지고 있고, 해당 언어를 아주 잘하지 않는 이상 남이 만든 코드를 보고 주어진 시간내에 이해하는 건 쉬운일은 아닌 것 같다.

 

[컴파일러 - 나무위키]

https://namu.wiki/w/%EC%BB%B4%ED%8C%8C%EC%9D%BC%EB%9F%AC

 

 

 

  사족이 길었지만 다음 이야기를 진행하기 전에 프로그램의 리버싱에서 왜 어셈블리어를 사용해야 하는지를 이해하고 넘어갔음 해서 그랬다. 그럼 비주얼 스튜디오에서 만든 코드를 보면서 이미 알고 있는 c++ 코드에 기반해서 어셈블리 코드의 동작방식을 해석해 보자.

 

  실제 편집창을 보면 저 잘라낸 코드 말고도 전체 코드는 엄청 길지만 앞뒤의 코드는 앞서 말한 "윈도우즈 환경에서, 커맨드 창을 통해서 해당 코드가 실행하기 위한 행사코드(행사 코드는 개발자인 임백준씨의 표현인데 이 경우 적절한 표현같다)" 라고 생각하면 될것 같다.

 

  다음 부터 나오는 모르는 어셈블리 키워드 들은 구글에서 "어셈블리 eax" 등으로 찾아 퍼즐을 맞춰보면 된다. 코드를 보면 rbp, eax, rcx같은 애들이 나타나는데, 이들은 모두 레지스터를 나타낸다. 레지스터는 CPU 입장에서 보면 프로그램의 변수와 같다. 이 변수들에 메모리에 있는 주소 번지, 숫자들과 잘 조합해서 명령을 실행한다.

 

  rbp, rcx 같은 경우는 64비트에서만 해당 표현을 볼수 있는 레지스트로 만약 앞에서 x86 으로 드랍박스를 선택했다면 나오지 않을 레지스트 이름이다(x86에서는 ebp, ecx등으로 e 로 시작되게 지칭한다). 앞으로 코드를 보면 알겠지만 64비트에서는 rcx 도 32비트에서의 동급인 레지스트인  ecx 표현으로도 같이 사용한다(코드 흐름상 추측하면 64비트에서는 rcx 사용 공간을 반만 사용하면 ecx 같다). 각 변수들은 미리 잘 쓰는 용도를 정해 놓은 편인데, 그건 어셈블리 코드를 많이 보면서 패턴상에서 감으로 익혀야 될 문제 같다.

 

   2번째 라인을 보면 "mov  dword ptr [rbp+4],0" 이 있다. 대충 살펴보면 rbp 라는 메모리 스택의 주소를 관리하는 레지스트가 가르키는 스택 위치에 0을 넣는다. 위에서 보면 c++ 코드의 "for (int count = 0; count < 4; count++)" 의 count=0 에 해당하는 주소 같아 보인다. 이후 3번째 줄의 "jmp   main+3Bh (07FF799ED185Bh)" 의 점프(jump=jmp) 명령을 통해 해당 주소인 7번째 줄(07FF799ED185B 주소)의 "cmp   dword ptr [rbp+4],4" 로 간다. 보면 아까 넣어놨던 0을 4와 비교(compare=cmp) 하는 라인이다.

 

  그 다음 8번째 줄을 보면 "jge main+4Fh (07FF799ED186Fh)" 로 앞 줄에서 비교한 결과가 크거나 같으면 루프를 벗어나 다음 코드(07FF799ED186F 주소 - c++ 코드로 보면 getchar())로 점프하는(jump if great or equal = jge) 코드가 있다. 지금은 0과 4를 비교했기 때문에 당연히 만족이 안 될 것이므로 점프 하지 않고 9번 줄로 넘어 갈것이다.

 

  9 번째 줄로 가면, 문자열 "Hello World\n" 가 담긴 주소를 rcx 레지스터로 담는다(Load Effective Address = lea). 이후 10번째 줄에서 "call  printf (07FF799ED11D1h)" 를 통해 윈도우즈의 printf api 를 호출해서 화면에 "Hello World" 를 뿌린다. 이후 11번째 줄에서 다시 루프의 시작에서 실행이 안됬던 4번째 줄로 점프한다(jmp  main+33h (07FF799ED1853h)

 

  4번째 줄을 보면, 아까 스택에 넣었던 0값을 eax 레지스터로 옮긴 후(mov  eax,dword ptr [rbp+4]), 5번째 줄 "(inc  eax)" 에서 1을 증가(increment = inc) 시키고, 6번째 줄에서 다시 1이 더해진 eax 값을 아까는 0이 들어있던 스택 주소로 보내 값을 0->1로 업데이트 한다(mov  dword ptr [rbp+4],eax)

 

  이후 7번째 줄로 가면 다시 위에서 설명했던 비교 명령을 통해서 1과 4를 비교하게 된다. 이렇게 계속 반복되다보면 스택의 0 값은 0, 1, 2, 3, 4, ... 가 되고, 0~3까지는 계속 Hello World 를 4번 표시하다가 4가 담기면서 4보다 크거나 같다는(jge) 조건을 만족하게 되서, 비로서 루프를 빠져나가서 14번 줄의 "call  qword ptr [__imp_getchar (07FF799EE02F0h)]" 을 통해 getchar() API 를 호출하게 된다. 이후 16번 줄의 "xor  eax,eax" 을 통해(자기자신을 xor 하면 0이 되니까 뭐 대충 c++ 의 "retrun 0" 의 느낌이 난다) retrun 0 을 통해 메인 프로그램 함수를 종료하게 된다. 이렇게 저렇게 꼬인 점프 루프 부분만을 빼면 아래와 같은 그림으로 정리함 어떨까 싶다.

 

  이렇게 어셈블리 코드를 보게 되면 기존 고수준 언어랑 많이 다르다는 느낌이 든다. 절대 쓰지 말라고 권고하는 점프도 마음것 사용 하고, 무언가 빠른 실행 속도만을 위해 최적화된 코드의 느낌이다.

 

 

 

  그럼 마지막으로 한가지만 더 생각해 보자. 아래와 같이 다른 코드를 그대로 유지하면서, for 문의 2번째 "<" 만 "<=" 로 바꾸면 어떻게 될까?

 

 

  유추해 보자면, 어셈블리어에는 jg (jump if greater than)라는 명령어가 있으므로, 기존 코드는 그대로 유지되면서 jge 가 jg 로만 바뀌면 한번 더 루프를 돌게 됨으로서 같아지지 않을까 싶다. 실제 코드를 수정하고 디버그 모드에서 어셈블리 코드를 보면 아래와 같이, jge 가 jg 로만 바뀐 어셈블리 코드가 나온다. 상황에 따라 두꺼운 책을 지루하게 보는 것보다는 이렇게 c 코드와 비교해 가면서 스스로 원본 코드의 난이도를 조정하면서 어셈블리 공부를 하는 것도 나쁘진 않을 것 같다.

 

 

 

2.3 동적으로 보기

  이번에는 여러 리버싱 책에서 하는 것처럼, 디버기를 이용해서 같은 코드(다만 앞에 본것은 디버깅 빌드 버전이고, 이번엔 릴리즈 버전으로 만들어 본다. 디버깅에 필요한 사족이 다 제거된 버전이라고 보면 될 듯 하다)를 봐보자.

 

  우선 디버깅을 할 exe 파일을 만들어 내보자. 위쪽의 네모난 정지 버튼이나 "Shift+F5" 를 눌러 디버깅을 중지한다. 이후 아까 Debug 상태의 드롭박스를 "Release" 로 바꾸고, "빌드>솔루션 빌드" 명령어를 통해 빌드를 한다.

 

1>코드를 생성했습니다.
1>ReversingSample.vcxproj -> C:\Python\Code\ReversingSample\x64\Release\ReversingSample.exe

 

 

 

  이제 디버거 프로그램을 다운받도록 해보자. 구글을 찾아보니 요즘은 64비트 환경에서는

x64dbg 라는 프로그램을 많이 쓰는 것 같다. 아래의 페이지에서 zip 파일을 다운로드 받아서 적당한 폴더에 압축 해제 한다.

 

[x64dbg]

https://x64dbg.com/#start

 

 

  이후 release\x64 폴더내에 있는 x64dbg.exe 파일을 실행 시킨다. 디버거 창이 뜨면 "파일 > 열기" 명령어를 통해서 아까 만들어 놓은 C:\Python\code\ReversingSample\x64\Release 폴더에 있는, "ReversingSample.exe" 을 선택한다. 아래와 같이 디버깅이 시작되는 화면이 열린다.

 

 

  디버거는 프로그램이 시작되면서 cpu 에서 실행되는 명령어 들에 대해서 어셈블리 레벨에서 가로채서 보여주는 프로그램이다. 그러다 보니 특정 명령어를 찾아 건너 뛰거나, 프로그램에서 사용하는 여러 값을 변경하거나 하는 일을 자유롭게(잘 이해만 한다면) 할수 있다. 앞에서 얘기한 웹에서의 피들러로 조작했던 클라이언트 코드와 비슷하지만, 보다시피 어셈블리와 그 어셈블리와 상호작용하는 시스템 자체의 동작을 이해해야 그것이 가능하기 때문에 자유롭게 구사하기 위해서는 브라우저로 실행 공간을 추상화 시킨 웹보다는, 배우서 익숙해야 할 부분이 더 많이 필요하다고 생각한다. 다만 그 더 많이 필요한 부분은 보안 기술 자체의 난이도 라기 보다는 앞 시간들에서 얘기했던 대상을 이해하기 위한 난이도인것 같다. 어셈블리나 해당 어셈블리가 돌아가는 환경들을 이해하는 부분은 보안의 측면이라기 보다는 기본적인 IT 기술의 이해쪽에 좀 더 가깝다고 본다. 다시 한번 강조하지만 보안 쪽은 대상의 기술적 측면을 이해하지 못한다면 할수 있는 것이 아주 적어진다.

 

 

  아까의 비주얼 스튜디오 환경에서는 원하는 코드에 대응하는 어셈블리 코드를 바로 볼수 있었지만(브라우저에서 요소 검사를 통해 해당 코드 위치로 이동한 것과 비슷하다고 볼 수 있다), 실행 파일에서는 우리가 작성한 코드가 실행되기 전에, 윈도우 환경에서 프로그램이 실행되기 위한 여러가지 행사코드들이 먼저 실행 될 것이기 때문에 한줄 한줄을 실행하게 되면 한참을 따라 가야한다. F8(건너서 단계 진행) 같은 키를 눌러 나름 큰 발자국으로 한 단계씩 이동하다가 원하는 코드를 만날 수도 있겠지만, 그러다 보면 원하는 지점을 놓쳐 몇번 시행 착오도 겪을수 있으므로 디버거에는 특정한 문자열이나 명령어, 패턴 등의 어셈블리 코드 요소를 기준으로 원하는 위치를 찾을 수 있게 검색 기능이 제공되어 있다. 해당 코드 화면에서 마우스 오른쪽 버튼을 누르고 "다음을 찾기 > 모든 모듈 > 문자열 참조" 를 선택하면 아래와 같은 프로그램이 가지고 있는 문자열들을 리스팅 하는 화면이 나온다.

 

  오른쪽 문자열 팬에 보면 우리가 뿌려주는 "hello, world\n" 문자열이 보인다. 해당 항목을 더블 클릭 해보자. 자 그럼 아까 비주얼 스튜디오에서 봤던 코드와 비슷하지만 조금은 모양이 다른 코드가 보이게 된다.

 

 

  그럼 한번 코드를 살펴보자. 비주얼 스튜디오와 비슷한 모양이 되도록 16진수 코드가 나오는 중간 부분은 편집해 제거했다.

 

  뭔가 첨에는 조금 달라 보였지만, 루프 코드를 보면 3번째 라인에서 ebx 레지스터에 5 값을 넣는다(mov ebx,5). 그리고 4, 5번 라인의 앞에서 이미 봐서 익숙한 패턴의 코드를 통해서 "hello world" 를 출력해 준다. 그리고 7번 라인을 보면 rbx(ebx 와 동일한 레지스트의 64비트 이름)에 1씩 빼준다(sub rbx,1). 이후 jne(jump not equal) 가 호출 되어 rbx 가 0인지 체크하여 0일 때까지 다시 5번째 라인인 7FF62C5F1080 주소로 점프하며 프린트를 반복한다.

 

  결국 실제 릴리즈 되어 실행되는 코드는 아까 디버깅에서 봤던 어셈블리와 모양은 다르지만 하는 일은 같은 등가의 코드라는 것을 알 수 있다.

 

 

 

 

3. 리버싱에 대해 생각해 보기

  앞의 예제를 통해서 짧게 격투기 선수의 초보 줄넘기 같은 짧은 리버싱 과정을 살펴 봤다. 그럼 다시 근본적인 문제로 돌아가서 왜 우리가 저렇게 귀찮은 과정을 거치면서 리버싱을 해야할까? 가장 큰 이유는 프로그램 소스가 없기 때문이다. 소스가 있는 프로그램을 굳이 리버싱을 하는 것는 KTX 열차 표가 있는데 뛰어서 서울에서 부산까지 가려하는 행동하고 비슷할 것이다.

 

  보통 리버싱 작업의 유용성을 예로 드는 데 사용하는 악성 코드는 소스를 모르는 채로 시스템을 공격하는 대상이고, 해당 실행 코드의 동작을 예측하고 방지하기 위해서는 내부 동작을 알아야 하기 때문에 궁극적으로는 리버싱 밖에는 방법이 없다(물론 여러가지 정적인이거나 해시 값을 체크하는 등의 히스토리에 기반한 방법도 있겠지만 그 쪽은 운이 좋은 편이라고 봐도 될듯 하다). 물론 악성 코드 분석과 같이 일정한 가상환경에 넣어놓고 동작을 관찰하는 보조적인 방법도 충분히 의미는 있을 것이다.

 

 

  리버싱 책을 보면 보면 보통 간단하게 어셈블리 코드의 동작 원리에 대해 설명한 후, 코드에서 원하는 위치를 찾아 로직을 이해하거나, 값이나 기능을 원하는 대로 패치하는 부분을 설명하고, 이후 PE파일의 구조, DLL 인젝션이나, API 후킹, 리버싱을 방해하는 방어수단에 대처하는 방법들을 설명하곤 한다.  그런데 사실 그러한 측면에서의 리버싱은 합법과 불법을 넘나들기도 한다. 같은 기술을 이용하여 타사의 프로그램의 동작 원리를 이해하여, 카피하고자 하는 용도로도 마찬가지로 사용될 수 있기 때문이다. 또한 긍정적인 측면으로는 많은 백신이나, 보안 툴들이 시스템 사용자의 허가(설치와 동의)를 기반으로 시스템을 보호하는데도 사용되며, 반대로 악성코드들은 그런 기술을 이용하여 사용자가 인지 못하는 사이에 동의를 얻어(택배문자를 클릭해 가짜 택배 프로그램을 설치한다던가) 자신을 숨기거나 사용자가 모르는 사이에 사용자의 자료나 행동을 기반으로 나쁜 행동을 벌이곤 한다.

 

  나아가 파이썬 시간에도 얘기했지만, 프로그램은 혼자서 움직이지 못하는 존재이다. 사용자가 직접 만든 코드 로직은 정말 적은 핵심 부분에 불과하고, 나머지는 타인이 만들어 놓은 모듈을 사용하고 있고, 해당 모듈도 해당 모듈의 언어에서 제공하는 라이브러리나, OS에서 제공하는 API(이것도 마찬가지로 코드라고 볼수 있다)를 사용해 해당 행동을 하게된다. 이 먹이사슬과도 같은 관점에서 보게 되면 여러분이 어셈블리를 잘 이해하고 미지의 프로그램을 잘 이해하려 한다면 해당 프로그램을 구성하는 언어 및 OS 의 API, OS의 동작 원리에 대해 잘 이해해야 한다는 결론이 나오게 된다. "Windows Internal" 같은 OS 동작을 설명하는 책부터, 시스템 프로그래밍 책 들과 같은 부분이 그런 시도의 출발점이 아닐까 생각한다. 좀 더 낮은 레벨에서 시스템을 안전하게 하려고 하면 할 수록, 이러한 평소에는 상위 언어에 감싸여 신경쓰지 못했던 부분들에 익숙해 져야 하는게 어쩔수 없는 면 같다.

 

  추가로 많은 악성 코드의 같은 경우는 외부와의 통신을 통해서 주요 로직 모듈을 다운 받거나 데이터를 받거나 전달하는 일도 많기 때문에, "통신" 이라는 개념에서 웹이나 다른 소켓 프로토콜과도 연관이 되어 버리게 되는 부분 같다. 그러다 보면 데이터 은닉(data hiding) 이라는 정상적인 것으로 위장해 하는 행동을 숨기려고 하는 쪽과도 주제가 만나게 된다.

 

 

 

 

4. 다른 측면의 리버싱

  위에는 코드에 기반한 얘기만 했지만, 블랙박스 테스트를 잘하면 화이트박스 기법과는 다른 측면에서 적절하게 주요 코드의 동작을 예측할 수 있고, 자바스크립트를 잘 분석하면 서버 사이드의 로직을 어느 정도 예측할 수 있듯이, 외부에서 관찰을 하여 분석하는 리버싱 영역도 있을것 같다.

 

  종종 만나는 부분이 게임 커뮤니티 같은데에서 사용자가 여러 실험을 통해서, 데미지 규칙을 유추 한다는지, 하는 부분이다. 사실 이런 부분은 서버 사이드 로직이기 때문에, 클라이언트를 아무리 분석해 봤자, 코드가 없을 테니 알 수가 없다.

["랩이 깡패다" 분석 실험 - 인벤]

http://www.inven.co.kr/board/lineagem/5056/4500

 

  뭔가 잘 짜여진 시나리오로 이런 반복적인 테스트를 하는 부분은 충분히 다른 측면의 리버싱이기도 하고, 클라이언트의 기반의 리버싱의 한계를 넘을 수 있게 하는 부분이기도 하다. 마치 별의 움직임을 관찰해서 행성들의 움직임의 규칙에 대한 가설을 세우는 일과 비슷하다고 보면 너무 거창한가는 싶지만 말이다.

 

 

 

 

5. 포렌식 예제 만들어보기

  뭐 예제라고 그러긴 좀 민망하긴 하지만, 포렌식의 측면을 살짝 엿볼수 있는 2개의 예제를 파이썬 코드로 만들어 살펴 보려고 한다.

 

 

5.1 특정 파일에 대한 생성, 수정, 접근 시간 보기

   첫번째는 파일의 생성일과 수정일 히스토리를 살펴보려고 한다. 우선 메모장을 열어서 "test" 라고 적고 c:\python\code 폴더에 test.txt 라고 저장한다(create). 이후 다시 해당 파일을 열어 "modify" 라고 다음 줄에 적고 다시 저장을 한다(modify). 이후 다시 해당 파일을 열어서 본다(access). 우리는 파일을 수정해서 저장하면 해당 파일만 남는 다고 생각하지만, NTFS 시스템은 해당 파일에 대해 생성, 수정, 접근에 대한 기록을 저장해 놓는다.

 

 

 

  "test.txt" 파일에 대한 해당 속성을 보기 위해 아래와 같은 파이썬 코드를 생성해 보자.

 

  내용을 보면 os모듈을 이용해서, 각 속성을 얻어와서 화면에 뿌린다. c:\python\code 폴더에 "UTF-8" 포맷으로 "show_timestamp.py" 라고 저장한다(잘 모르겠으면 파이썬 2교시를 참조). 이후 해당 파일을 실행 한다.

 

C:\Python\code>python show_timestamp.py
생성 시간: 2019-09-01 13:23:50
수정 시간: 2019-09-01 13:24:00
접근 시간: 2019-09-01 13:24:00

 

  근데 내용을 보면 이상하게 맨 마지막으로 파일을 열어본 시간이 안 찍히고 있다. 구글을 찾아보면 윈도우즈 7부터 성능을 위해서 파일이나, 디렉토리가 접근되었을때는 해당 정보를 업데이트 안한다고 한다. 이를 수정하기 위해서는 NtfsDisableLastAccessUpdate 레지스트리 키를 0으로 하면 된다고 한다. 뭐 해보고 싶으면 해봐도 좋을듯 싶다.

 

[Enable last access time - Open Tech Guide 사이트]

https://www.opentechguides.com/how-to/article/windows-10/129/enable-last-access-time.html

 

 

 

5.2 엑셀의 최근 항목을 레지스트리에서 찾아보기

   두 번째는 엑셀의 최근 접근 문서를 찾아보자. 엑셀을 열어보게 되면, 아래와 같이 최근 열었던 문서가 표시된다(오피스 16버전 기준).

 

 

  구글을 찾아보면, "HKEY_CURRENT_USER\Software\Microsoft\\Office\16.0\Excel\\File MRU" 경로에 있다고 나온다. 여러 전문적인 포렌식 툴도 있겠지만, 실행 창에서 "regedit" 를 입력하여 레지스트리 편집기를 열어 해당 경로로 이동해 보면, 아래와 같이 엑셀 창에서 봤던 최근 문서들이 키/값 으로 저장되어 있다.

 

  그대로 끝내긴 좀 그래서, 파이썬으로 해당 레지스트리 키를 가져와서, 최근 문서 값 만을 뿌려주는 코드를 하나 작성했다.

 

  역시 c:\python\code 폴더에 "UTF-8" 포맷으로 "show_excel_recently.py" 라고 저장 후 실행해 보자. 아래와 같이 원하는 결과가 나온다.

 

C:\Python\code>python show_excel_recently.py
Item 1: [F00000000][T01D415FA193618D0][O00000000]*C:\Python\code\07교시\result.xlsx
Item 2: [F00000000][T01D37D59BFAC7C70][O00000000]*C:\Backup\code\result2.xlsx
Item 3: [F00000000][T01D37D59BBFEB6B0][O00000000]*C:\Backup\code\result.xlsx

 

 

 

 

6. 포렌식에 대해 생각해 보기

  예제를 보았으니, 앞의 리버싱 얘기에 연결해서 전혀 다른 분야 같이 보이는 포렌식(forensic)에 대해 생각을 해보자

 

  포렌식의 가장 기본이 되는 형태는 삭제된 파일을 복구하는 undelete 작업일 것이다. 속도의 문제 때문에 컴퓨터에서 파일을 삭제할때(휴지통에 남기지 않더라도), 시스템에 등록된 파일에 대한 정보 위주로 삭제하고, 실제 파일 내용이 저장된 디스크의 자기 공간 부분은 그대로 남겨두게 된다. 

 

  왜 전체 내용을 다 지우지 않냐고 생각할 수도 있겠지만, 파일이라는 것은 디스크 내에 0과 1로 저장된 정보의 형태고, 그것을 완전하게 지우기 위해서는 랜덤한 형태로 (여러번) 덮어 씌워야 한다. 그렇다는 것은 몇 기가 정도의 파일을 완전히 삭제하려면 적어도 해당 파일을 디스크 사이에서 복제하는 시간만큼 동일하게 소요되게 된다는 것이다.

 

  매번 파일을 지울때마다(이건 사용자의 파일도 있을 수 있고, 시스템이 사용하는 파일일 수도 있다) 그렇게 번거로운 작업이 일어난다면 지금의 컴퓨터는 휠씬 더 많이 느려질 것이다(큰 파일 복사를 할때나 큰 용량의 파일을 여러개 다운로드 받을때 컴퓨터가 느려지는 현상을 생각함 될듯 하다). 그래서 파일을 지운 후 딱히 컴퓨터를 더 사용되지 않아 해당 파일이 저장되 있던 디스크 영역이 덮어써 지지만 않는다면, 원래의 파일로 복구가 가능할 가능성이 높게 된다. 물론 삭제를 해도 기존에 저장되었던 잔여 자기장에 기반하여 복구가 가능하다고는 하지만, 현실적으로는 가용 가능한 정보가 얼마나 복구될까는 싶다. 

 

[소거 프로그램 - 나무위키]

https://namu.wiki/w/%EC%86%8C%EA%B1%B0%20%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%A8

 

  앞의 어셈블리(또는 c++같은 낮은 수준의 프로그래밍 언어) 코드를 보면 알수 있지만, 컴퓨터는 의외로 생각보다 단순한 동작의 반복으로 우리가 보는 이 운영체체와 프로그램의 동작들을 구현한다. 단순하게 본다면 레지스트, 메모리, 디스크에 데이터를 썼다 지우거나 하는게 전부라고 봐도 될지 모른다. 그러한 과정에서 파일 삭제의 경우와 같이 무언가 완전히 덮어지지 않고 디스크 내에 남거나, 운영체제나 어플리케이션 들이 모니터링이나, 디버깅, 사후 추적의 목적으로 사용자 몰래 남기거나, 사용자가 부주의 해서 또는 필요해서 남긴 부분들이 존재하게 될 것이다. 또한 특수한 경우를 빼고는 메모리 상에는 대부분의 보호장치가 풀어지고 실행가능한 코드만 남게 되기 때문에 접근이 가능하다면 의미 있는 정보를 추출하는 것이 가능하다. 이런 부분들에 대해서 살펴보고, 복구하고, 시간의 측면에 따라 재구성 하여 사용자의 행동을 이해하고 증명하는 작업이 포렌식이란 영역이 아닐까 싶다.

 

  조금 공식적으로 얘기하자면, 그러한 데이터들을 이쪽에서는 아티팩트(artifact) 라고 부르는 것 같은데 그 아티팩트들이 존재할 수 있는 장소는 메모리 상의 여러 요소(실행되는 프로세스, 문서들), 평문으로 저장된 패스워드, 채팅 등 사용자간에 전달되는 데이터, 네트워크 커넥션 로그, MBR , 레지스트리, 로그 및 컨피그 파일, 프로그램 파일, 임시 파일, 데이터 파일, 삭제 후 유지되는 데이터 공간 등이 있을 것이다.

 

  앞에서 보안은 데이터의 흐름을 따라가는 일이라고 생각한다고 말했었는데, 모든 보안의 분야가 그렇겠지만 포렌식 분야야 말로 데이터에 포커스를 두고 흔적을 따라가는 일이라고 본다. 이상적으로는 데이터가 담긴 메모리, 디스크에 모든 필요한 정보가 담겨있다고 볼수 있지만, 해당 데이터들이 구체적인 사용 주체들과 연결되지 않는다면 0과 1로 만들어진 숫자에서서 쉽게 의미를 찾을 순 없을 것이다. 그렇게 하기 위해 OS 에 따른 디스크 및 메모리의 사용 방식, 프로그램이 동작하는 방식, 사용자가 생각하거나 움직이는 방식(사용자가 생성하는 데이터를 이해하거나, 사용자가 컴퓨터를 사용하는 용도나 스타일에 따라서도 접근이 달라질 수 있다고 본다)까지도 이해할 필요가 있다고 생각한다.

 

  나아가 명시적이진 않은 어플리케이션의 데이터를 추적하고 찾기 위해서는(역시 앞의 리버싱과 마찬가지로 소스를 모르니까) 앞 단에서 다르게 느껴졌던 리버싱 영역의 스킬들이 필요하게 될 가능성이 높아진다. 여기서에 두 개의 영역이 결국 만나게 된다고 생각하는데, 프로그램이나 운영체제의 행동을 쫓던 리버싱은 대상이 만들어내거나 접근하는 데이터에 관심을 가지게 되고, 데이터를 쫓아가던 포렌식은 데이터를 만들어 내는 프로그램이나 운영체제의 행동에 관심을 가지게 되어버린다. 결국 두 개의 분야의 지식이 만나 상호 작용하며 균형을 이루어야만 각 분야가 완전하게 될수 있는 것 같다.

 

 

 

 

5. 마무리 하면서 

  처음부터 많이 돌아오긴 했지만 리버싱과 포렌식은 서로 거리가 있는 분야가 아니며 서로의 영역의 지식이 필요한 연결되어 있는 분야라는 얘기를 하고 싶었다. 더 나아가면 보안의 다른 분야에서도 이러한 낮은 레벨의 지식이 필요한 분야가 전체적인 보안의 균형과 응용을 만들어 주는데 꼭 필요하다는 생각을 한다.

 

  그리고 현실적으로는 포렌식 같은 증명을 하는 작업은 객관적이고 표준적인 방법이 필요하므로(법적으로 증명해야 되는 경우도 점점 더 늘어나고 있을테니), 개인의 특별한 지식 보다는 공인된 기관에서 보안적으로 인증된 툴을 사용하여 증적을 만들어야 하는 경우도 많을 것 같다(회사가 인증이나 감사를 받을 때의 기준을 생각하면 이해가 될 것이다).

 

  다만 해당 툴의 결과를 올바르게 해석하거나 툴의 한계를 극복하는 부분은 앞의 스캐너 부분에서 얘기한 스캐너와 수동 테스트의 관계와 마찬가지라고 본다. 또 다른 측면에서는 취미나, 새로운 방법론을 연구하거나, 자동화 때처럼 공식적인 툴들이 지원하지 않는 마이너한 영역에 대해서 연구하는 측면도 있을 것 같다. 이렇게 보면 보안은 결국 컴퓨터라는 세상을 이해하는 일인 것 같기도 하다.