리버싱 예제 :: gdb -01 file, x-executable, gdb binary file

이번 실습의 목적은 예제 파일이 어떤 프로그램인지를 알아내고, 

무엇을 입력해야지 "oh great!!" 라는 문장이 출력될 지 알아보는 것이다.

 

 

윈도우에서는 파일 확장자로 파일 정보를 파악할 수 있는데,

리눅스에서는 확장자가 존재하지 않아서 임의의 파일의 종류를 알기 위해서는 별개의 작업이 필요하다.

 

 

먼저, readelf 명령어로 헤더 등을 살펴보면 다음과 같다. 

 

 

 

 

file 명령어로 파일의 종류를 확인할 수 있다.

 

file filename : filename 의 정보를 출력

 

-i 옵션을 주면 MIME 미디어 타입 문자열로 표시된다. 

더 간단하고 핵심만.. 파일 종류를 바로 확인할 수 있다. 

 

 

예제 파일은 binary file 이고 x-executable 파일임을 알 수 있다.

 

binary file 이라 그냥 text editor 로는 이해할 수 없는 정보들이 나올 것이다.

hexdump 혹은 objdump 로 16진수 혹은 어셈블리어로 번역된 코드를 볼 수 있다.

 

 

추가로, c 코드, 어셈블리어, 그냥 비어있는 파일의 정보는 다음과 같이 출력된다.

 

 

 

 

x-executable 파일은 다음의 명령어로 실행시킬 수 있다.

 

(먼저 해당 파일의 퍼미션이 777이어야 한다.)

sudo chmod 777 filename : filename 의 퍼미션을 777로 변경

  (혹은 그냥 x 만 더해줘도 된다. chmod +x filename )

./filename : filename 실행

   ( -> 이게 안될 때 : sh filename 혹은 head -5 filename )

 

 

 

 

objdump : 화면에 object file 의 정보를 출력해주는 프로그램

 

-0x26(%ebp)

 

쟤를 맞춰야 하는 것임을 유추하였다.

 

 

 

(gdb) info 에서 여러 정보를 얻을 수 있다. 

하지만 나는 여기서는 유용한 정보를 얻지는 못했다..

 

 

 

 

 

다시 돌아와서,

disassemble funcName 혹은 disass funcName : funcName (함수) 의 어셈블리 코드 출력

 

 

break N 혹은 b N : N 번째 줄에 break point 

 

그런데 이 코드는 바이너리 코드라 그런지? break 1 만 해도 line 1 이 없다고 나온다. 왜인지는..

그렇다면 바이너리 코드를 gdb 에서 디버깅하는 방법을 ......

 

 

그래서 어셈블리 코드에서의 주소를 참조하여 break point 를 잡았다.

 

break *주소 : 주소 에 break point

 

 

중단점을 걸어두고 바이너리 코드를 보니 scanf 로 사용자에게 입력을 받고 나서, strcmp 를 하기 전 비교 대상을 push 하는 것을 발견하였다.

 

 

저 주소에 있는 값이 무엇인지를 알면 답을 구할 수 있다 !! << 0x80485ae

 

 

이제 어떻게 메모리 주소의 값을 조사할지를 보면, 

x adress : adress 의 정보 출력

( 혹은 x $register : register 가 가지고 있는 주소 정보 (?) )

 

 

 

여기서 필요에 따라 유용한 옵션들을 줄 수 있다.

 

x/format adress : adress 를 format 형식으로 출력

 

x	Hexadecimal format
o	Octal format
u	Unsigned decimal format
t	Binary format
d	Decimal format
s	string
i	CPU instruction
Nx	examine N words form stack

 

string 명령어로 저 주소 (0x80485ae) 에 있는 값을 살펴보기로 한다.

 

결과는..

 

 

yes!! 를 입력해야지 oh great!! 가 출력됨을 알아내었다 !!

 

 

다른 옵션들도 한 번 해보면 다음과 같다.

 

(0x79 는 y , 0x65 는 e)

 

 

또, eax 에 저장된, 내가 입력한 문자열을 한 번 보면 다음과 같다. 

 

 

 

breakpoint 로 멈춘 것이라

gdb 명령어로 step (다음으로 넘어감) 하고 continue 를 하니 역시나 "oh no... :(" 가 출력됨을 확인하였다.

 

 

 

breakpoint 아니어도 0x80485ae 에 저장된 값은 알 수 있지만, (메모리에 저장되어 있으니 ~)

eax 에 저장되었던 정보들은 확인할 수 없다는 것을 한 번 확인해 보았다.

 

만일 내가 알아야 하는 정보가 프로그램이 돌아가는 동안 바뀌고 없어지는 정보라면 break point 를 잘 잡아야 한다!

 

 

break point 를 삭제하려면 break point 번호를 입력하면 된다.

(어떤 라인의 break point 삭제 등 다른 방법도 많다.)

 

info b(reak) : break point 리스트 출력

d N : N 번째 break point 삭제

d : 모든 break point 삭제

 

 

break point 는 삭제되어도 넘버링은 지속된다.

 

 

1번 break point 가 삭제되었지만 다음의 break point 는 2번임을 알 수 있다.

 

 

 

 

이제 모든 break point 를 삭제하고, 찾은 답으로 프로그램을 돌려 보겠다.

 

 

성공!

 

 

 

참고)

(디버깅에서) i r  : 레지스터 정보들 출력

 

 

 

+)

정말 유용하게 참고한 https://hacksland.net/debugging-binaries-with-gdb/

좋은 정보들이 많다.!