[Disk] 우리는 이 바이너리가...

문제를 한번 보겠습니다.

문제에서 "바이너리" 가 동작을 했다고 한다. 그래서 파일의 유형을 한번 알아보기 위해 다음과 같은 명령어를 실행했다.

file binned

그러자 파일의 유형은 ELF로써, 유닉스 계열 운영체제의 실행, 오브젝트 파일, 공유 라이브러리 또는 코어 덤프를 할 수 있게 하는 바이너리 파일입니다. 쉽게 말해서 Windows에서 .exe확장자를 가진 것이 실행파일이듯 유닉스 계열 운영체제 에서 실행파일을 담당합니다.

 

실행파일이니 가상환경 스냅샷을 이용해서 저장을 하고 실행을 한번 해봤습니다.

./binned

실행을 했더니 다음과 같은 에러를 발생시켰습니다.

그래서 곰곰히 생각을 해보다가...문제를 다시 읽어봤습니다. 그러자 "바이너리가 동작을 한다" 라는 문구에 관심을 기울였고, 리눅스 디버깅 도구인 "strace"를 알아냈습니다.

 

strace란?

  애플리케이션들이 사용하는 system Call과 signal 등을 추적해서 성능 저하를 일으키는 부분이 있는지, 에러가 나는 부분이 있는지 확인하는 디버깅 툴입니다. (자세한건 생략 하겠습니다)

 

그래서 이 프로그램이 어떻게 동작하는지 알아보기 위해서 바로 실행을 했습니다.

strace ./binned

다양한 시스템 콜이 들어 있었고, 자세한 분석은 하지 않았지만 아까 우리가 실행을 했을 때, 봤던 문자열이 있는 것을 볼 수 있었습니다.

그래서 추측을 한 결과, 이 문자열 다음에 나오는 모든 시스템콜에 의미를 두고, 곰곰히 생각을 해봤습니다. 그러자 시스템 콜에는 자신이 가지는 고유 코드번호가 있었고 코드번호 리스트에 담긴 번호를 아스키로 변형을 시키면 되지 않을까? 라고 하나씩 분석을 하다가 { 중괄호가 생기는 시스템콜(setfsgid)을 찾게 되어서 계속 진행을 했습니다.

이 부분 말고 더 있습니다. (나머지는 생략하겠습니다)

그래서 fork()부터 코드번호를 붙혀보면, 57, 52, 52, 55, 123, ...... 69, 125까지 총 31개의 시스템 콜이 있습니다.

코드는 다음과 같습니다.

실행을 하게 되면 플래그 값을 구할 수 있었습니다.

 

시스템 콜 번호를 보기 위해선 요기 링크를 타고 들어가시면 됩니다.

https://elixir.bootlin.com/linux/v3.14/source/arch/x86/syscalls/syscall_64.tbl