QIRA 디버거

Posted on Edited on In , Views:

아이폰 탈옥과 PlayStation 탈옥 등 천재해커라고 불렸고, 현재는 Comma.ai라는 회사를 만들어 1천달러로 기존의 자동차를 자율주행차를 바꿀 수 있는 OpenPilot이라는 시스템을 만들고 있는 George Hotz의 발표이다.

발표 페이스가 무진장 빠르고… 스타일 자체가 ‘난 천재다!’라고 얘기하는 느낌이다 ㅋㅋ.

발표에서는 본인이 주장하는 ‘Timeless debugger’인 QIRA를 소개한다.


gdb vs QIRA. Why QIRA?

  • gdb는 쒯이다.

    • 70년도에 만든 디버거를 왜 아직까지 쓰고있나?
    • 70년도에 만든 패러다임을 왜 지금까지 쓰고있나?

  • gdb는 backtrace (i.e. Call stack을 되짚어보는 기능) 기능을 지원한다.

    • 하지만 정확한 위치에서 breakpoint를 찍지 못해서 프로그램을 아마 10번은 돌려야 할 것이다.
      • 왜 우리는 정확한 위치에 breakpoint를 찍지 못하는가?
      • Crash report를 보면 대충 어디서 프로그램이 터졌는지 의심가는 부분은 있지만, 정확한 코드 라인을 알지 못하기 때문이다.
    • Breakpoint를 실수로 지나치면 돌아갈 방법이 없다.
      • 그러면 breakpoint를 좀 더 앞단의 코드로 옮기고 프로그램을 다시 시작해서 테스트 해야한다.
        • Crash report가 몇백-몇천개씩 몰려들고있으면 ‘breakpoint’를 찾는 작업만으로 시간을 다 갖다버린다.
      • 뭐… gdb에서 rewind 같은 기능을 만들고있긴 하지만, 우리가 원하는건 그게 아니다.

  • 우리가 원하는건 Timeless debugging이다.

    • .NET, Objective-C, Swift와 같이 다이나믹한 디버거들도 많지만, 우리가 원하는건 binary 프로그램 디버깅이다.
      • (Binary 프로그램 디버깅을 한다는건… 리버스 엔지니어링도 된다는게 아닐까…?)
    • IDA나 objdump도 binary 프로그램이 작동하는 방식을 이해하기 위한 좋은 선택이다.


QIRA의 근원

  • QIRA의 메인 아이디어는 Git과 같은 version control에서 왔다.
    • Git의 작동방식을 보면… 파일마다 버전 정보, 수정 내역, 수정한 사람의 정보 등등이 전부 기록되어있다.
    • 이 방식을 그대로 가져와서… 파일이 아니라 메모리와 레지스터에 적용하면 어떨까?
      • Instruction을 commit과 비슷한 개념으로 생각해서 말이다.
      • 예를 들어, MOVE(r0,1) 과 같은 instruction이 있었다면, r0라는 메모리에 1 값을 넣었다는 정보를 저장할 수 있겠다.
    • 위의 아이디어로 벌써 디버거의 구상은 끝났다.
      • Trace를 잘 할 수 있는 UI만 잘 만들면 된다.
      • gdb처럼 breakpoint 하나 놓쳤다고 프로그램을 다시 실행하게 만들지만 말자.


QIRA의 특징

  • 그렇게 만들어진 QIRA가 이것이다.
    • 좌상단에는 위에서 아래 순서로 Program trace가 나열되어있다.
      • 바로 밑에는 레지스터들이 있다.
    • 우측에는 IDA와 비슷한 방식으로 그래프 형태의 Program flow가 보인다.
    • 좌하단에는 메모리 주소마다 저장된 hex값을 보여준다.


  • QIRA의 장점은 아래와 같다.
    • EIP를 확실하게 알 수 있다 (i.e. 함수의 순서를 정확하게 알 수 있다).
    • 런타임에서 변수의 타입을 알 수 있다.
      • Static한 환경에서는 거의 절대로 변수의 타입을 알 수 없다 (메모리에서 변수의 시작점과 끝을 알 수 없기 때문)
      • QIRA는 Dynamic 트레이싱을 통해, 언제 얼만큼의 메모리가 접근하고 할당되는지 알기 때문에 변수의 타입을 추론할 수 있다.
    • QIRA는 프로그램 전체의 history를 저장한다.
      • gdb는 프로그램을 실행하면서만 trace를 읽을 수 있다.
      • QIRA는 trace의 로컬 복사본을 저장하기 때문에, 프로그램이 끝나도 trace 분석이 가능하다.
        • 즉, 다시 분석하려고 또 프로그램을 킬 필요가 없다.


  • 오버헤드가 너무 클 것 같다는 생각이 들 수 있다.
    • 하지만 요즘 컴퓨터는 짱짱 좋아서 모바일에서도 빠르게 코드가 돌아간다.
    • 데스크탑에서 QIRA를 돌린다? 절대로 리소스가 부족할리가 없다.

George Hotz가 이야기하길, 본인이 기업들의 프로그램 분석 대회에서 상금을 타갈 수 있던데에는 QIRA가 큰 공헌을 했다고 한다.
다른 사람들보다 10배는 더 빠르게 binary 프로그램을 분석할 수 있다는건 큰 능력이다.

카네기 멜론 대학에서는 비슷한 프로젝트로 현재 bap이라는 시스템을 만들고있다고 한다.