보안서약서를 작성했기 때문에 프로젝트의 내용에 대해 상세히 언급할 수 없음을 알립니다.
🛠️ 인생 첫 프로젝트
이번 프로젝트는 내가 대학 4년을 다니며 경험한 첫 프로젝트였다. 처음 경험한 프로젝트인만큼, 여러 난관도 있었고 생각하지 못했던 방향으로 전개되는 것도 많았다.
처음 프로젝트에 대한 궁금증이 생겨 교수님께 연락드렸을 때, 프로젝트에 대한 교수님의 설명을 들었다.
이 프로젝트의 분야는 보안인 것에 반해 나는 변변찮은 경력도, 프로젝트 경험도 없던 응애 아가 학부생인 것으로도 모자라서 보안은 절대 내 인생에서 할 일이 없을 것이라고 생각해서 수업조차 들은적 없었다.
그런 나에게 교수님이 제안하신 '보안'을 주제로 한 프로젝트.
이건 기회다!
라는 생각이 드는 순간 앞뒤 가리지 않고 프로젝트에 참여하겠다고 했다.
사실 고등학교때와 대학에 처음 입학했을 때 까지만 해도 보안에 대해 관심이 있었고, 정보보안전문가가 꿈이었다.
하지만 분야가 너무 마이너한 감이 없잖아 있고, 진입장벽이 너무 높다고 생각해서 보안쪽에서 일을 하는 것은 어려울 것이라고 생각해 포기했었다.
하지만 이렇게 프로젝트로나마 보안을 접할 수 있다는 사실이 솔직히 좀 설렜다. 예전부터 궁금하던 게임을 플레이할 수 있게 된 느낌처럼 말이다.
보안에 대해 하나도 몰라도 괜찮다고 생각했다. 계속 공부해서 빈 부분을 채우면 되니까.
기회라고 생각한다면 그저 잡으면 될 뿐, 나머지는 전혀 고민이 되지 않았다.
그래서 이번 프로젝트를 진행하기 위해 나는 프로젝트가 정식으로 시작되기 전 1월부터 프로젝트를 위한 기반을 다지기 위한 보안 공부를 했다. 주로 실습 위주였다. 
🤯 삽질의 연속
이번 프로젝트는 말 그대로 삽질의 연속이었다.
원래 연구라는 것이, 완벽히 정해진 로드맵을 따라가기보다는 이것저것 해보다가 방향을 잡는 경우가 많다. 정해진 목표를 이룰 수 있을지 없을지 확실하지 않기 때문이다.
💻 OpenCSD Enable하기 (2월~3월)
프로젝트를 처음 시작할 때, 우리 연구실에서도 프로젝트를 함께 진행하는 기관에서 사용했던 보드인 DB845c를 동일하게 사용하길 원했지만 그 보드가 단종되어버리는 이를 대체하기 위해 바람에 필요한 기술이라고 생각했던 OpenCSD(실제로 필요하지 않은 기술이었음)가 동작하고 실제로 구매할 수 있는 모든 보드를 찾아내야했다.
이런 식으로 알아봐서 최종 결정된 보드는 DB410c였다.
DB410c를 구매한 이후 Coresight의 OpenCSD를 enable하기 위해 정말 많은 고생을 했다.
DB410c에 Linaro가 support하는 Debian을 설치하려고 계획했지만 이상하게 Debian SD card image가 다운받아지지 않아서 익숙한 Ubuntu를 설치하려고 했다.
하지만 결국..설치에 실패해서 이런 상황이 되어버렸다.
그래서 안되는 Ubuntu를 내버려두고 fastboot를 이용해 Debian을 설치하게 된다.
신기한건, 내가 Ubuntu를 설치하려고 시도한 방법은 SD card를 이용한 부팅 방법이라 보드 자체의 펌웨어를 건든 것은 아니라서 보드의 기존 OS로 부팅하는 것에는 문제가 없었다는 것이다.
어떻게 보면 당연한거겠지만 나한테는 새로운 배움이었다.
이후 fastboot를 이용해 Debian을 설치할 때 openCSD와 perf가 동작하도록 커널 설정 및 커널 컴파일, 커널 빌드, 이후 커널 설치를 하는 과정에서도 큰 어려움을 겪었다.
어떤 날은 오후 1시에 미팅하러 가서 밤 9시까지 계속 커널 빌드만 한 날도 있었다.
여담이지만 그 날은 집 갈때 서러워서 울었다.. 집 가는 데에 1시간 반이 걸려서 9시에 바로 출발해도 11시쯤 집에 도착하는데 집 가려고 막 건물을 나가려고 하니까 비가 오더라. 이것도 저것도 잘 안되는게 괜히 속상했던 것 같다. 지금 생각해보면 재미있는 해프닝이다.
🗃 수많은 문서 번역 (4월)
우리의 프로젝트 타겟은 ARM 프로세서 였다.
하지만 ARM 프로세서가 아무리 임베디드 시스템에 많이 쓰여도 실생활에서 우리가 쓰는 프로세서는 Intel이지 ARM이 아니다..
그래서 약 4월 경부터 프로젝트를 진행하기 위해 혹여나 ARM에 대한 선수지식이 필요할까 싶어 ARM64와 AArch64 어셈블리에 대한 매뉴얼을 일부분 번역했다.
또한 하드웨어 트레이스와 관련하여 ETM 매뉴얼의 패킷 부분도 번역하였다.
솔직히 번역한 모든 것들을 기억할 수 있다고 한다면 그건 거짓말이다.
중요한 것은 '어, 나 이거 어디서 본 것 같은데? 번역한 것 같은데?' 의 느낌이다.
이런 느낌이 들었을 때 바로 찾아서 볼 수 있도록 미리 번역을 해둔 것이다..
하지만 유감스럽게도 번역한 문서들은 그다지 쓰이지 않았다.
번역한 것의 20% 정도만 사용되었던 것 같다.
4월 한 달간 고생했던 것들이 지식의 확장에는 도움이 됐을지 모르겠지만, 프로젝트는 큰 의미가 없었던 것이다.
하지만 기술 문서를 읽어보는 것이 큰 도움이 됐고, 기술 문서의 목차의 중요성을 다시금 경험하는 기회가 되었다.
😥 네? 다시 판매한다구요? (6월)
프로젝트 도중 상당히 큰 문제가 발생했다.
프로젝트를 막 시작하던 1월 경 단종되었다고 했던 DB845c가 다시 판매되고 있다는 소식을 접한 것이다.
이런.... 이게 무슨 소리람? 완전 멘붕이었다.
그래서 급하게 같이 프로젝트를 진행하는 다른 학교에 구매를 요청했지만, 아무래도 우리 연구실에서 단독으로 진행하는 프로젝트가 아니기 때문에 우리가 직접 구매하는 것이 아니라 다른 학교에 대행을 맡겨야 해서 결재를 받아야 하는 등의 여러 절차로 인해 우리가 당장 써야하는 보드를 프로젝트가 끝나가는 연말쯤 받을 수 있게 되었다.
그래서 결국 프로젝트를 제안한 기관에서 DB845c 보드를 3개 빌려왔고, 이전에 진행했던 DB410c와 관련된 모든 작업들은 쓸모가 없어졌다.
아무리 연구는 삽질의 연속이라지만 이 때에는 좀 허무했던 것 같다.
그래, 모든 일은 내가 원하는 대로만 흘러가지 않는다. 결국 이게 인생이다. 정말 어떤 상황이든 겸허히 받아들이는 자세를 배웠다.
📝 Welcome to 기드라 World! (6월)
기관에서 대여받은 보드를 통해 실험 환경이 완전히 통일되었으므로 이제는 기드라(Ghidra) 툴을 이용해 Python script와 Java script를 사용하는 법을 알아냈다.
처음에는 인터넷의 유명한 보안 예제인 abex01crackme.exe를 기드라를 통해 분석해보았다.
이를 해석하기 위해서는 어셈블리에 대한 지식이 있어야했다.
위에서 번역해두었던 문서를 참고해도 되지만, 나는 대학교 2학년때 시스템 프로그래밍과 마이크로프로세서응용 과목을 통해 어셈블리에 대한 어느 정도의 지식이 있어서(그 당시 어셈블리가 굉장히 재밌었음) 그다지 어렵지 않게 해석할 수 있었다.
그리고 abex01crackme.exe에 적용할 수 있는 Python script를 실제로 적용해보고 제대로 작동하는지 확인해보았다.
동작은 역시나 아주아주 잘 됐다.
그런데 Python script는 Java에 비해 간단하게 작성할 수 있지만 여러 API에 대한 설명과 정보가 부족했기 때문에(검색해도 잘 안나옴) 여러 기드라 API에 대한 문서가 존재하는 Java를 사용해 스크립트를 작성하게 되었다.
이를 위해 기드라와 이클립스를 연동하는 법도 검색을 통해 알아냈다 (링크 참조).
그 이후부터는 Java로 만들어진 여러 스크립트를 분석해서 우리에게 필요한 기능을 알아내기 위한 조사가 시작되었다.
HelloWorldScript.java, IterateInsructionScript.java, IterateFunctionsScript.java 등을 실행하고 그 안에 쓰인 API가 어떻게 동작하는지 문서로 전부 정리하였다.
📰 프로젝트 중간보고 (7월)
7월은 프로젝트 중간보고 기간이어서 중간보고를 위한 발표자료와 보고서 만들기에 시간을 할애했다.
각자 자신이 맡은 부분의 발표자료와 보고서를 작성했다.
했던 일들이나 조사한 내용을 매번 문서작업 해 드라이브에 올려놨기 때문에 발표자료와 보고서를 만드는 것이 크게 어렵지는 않았다.
문서작업을 해놓으면 지금까지 프로젝트에서 자신이 무엇을 했는지를 까먹더라도 손쉽게 확인할 수 있다는 큰 장점이 있는 것 같다.
무엇인가 개발을 할 때에도 무엇을 만들었는지, 혹은 무엇이 변경되었는지 꼼꼼히 문서를 작성하는 것을 소홀히 하지 말자고 다짐했다.
🔎 안티 디버깅 기술 조사 및 프로젝트 핵심 기술 연구 (8월~9월)
8월부터는 본격적으로 프로젝트의 핵심인 ARM 프로세서에서 동작하는 안티 디버깅 기술에 대해 조사했다.
가장 큰 중심이 되었던건 Pangu였다 (링크 참조).
엄밀히 얘기해보자면 먼저 Linux x86 기반으로 동작하는 안티 디버깅 기술을 찾아서 이것을 ARM 프로세서용으로 보드에서 동작할 수 있게 cross-compile을 한다. 그리고 DB845c에서도 이 코드가 제대로 동작하는지 확인하는 작업이 계속됐다.
보드에서 안티 디버깅 코드가 제대로 동작하는지 확인해보기 위해 보드에서 무한루프를 돌고 있는 코드에 Ubuntu에서 원격으로 보드에 GDB를 attach하는 방법으로 실험하였다.
remote GDB를 보드에 attach 시키기 위해 정말 많은 실패 과정이 있었다.
gdb 대신 gdb-multeiarch를 쓰고, 디버깅 심볼을 찾지 못해 디버깅하지 못하는 여러 에러메세지를 겪다가 android ndk의 gdbserver를 보드에 직접 push해 사용하게 되었다.
Pangu에 상당히 많은 기술이 소개되어 있지만 이 중 동작하는 것은 극소수에 불과했다 (1개).
그리고 Pangu 이외에 수 많은 조사를 했지만 이 중 동작하는 것은 대략 3개 정도에 불과했다.
악성코드에서 안티 디버깅 기술을 사용하는 경우 악성코드 분석에 큰 장애물이 되므로 실제로 사용 가능한 안티 디버깅 기술이 별로 없다는 것은 좋은 일이지만... 프로젝트 입장에서는 조사에 큰 성과가 없었다.
더불어 프로젝트의 목적에 도달하기 위해 기드라를 공부하며 알아냈던 스크립트를 작성하는 법과 Java API를 통해 우리가 원하는 기술을 가진 스크립트를 작성했다.
상당 부분의 코딩을 내가 도맡아서 했다. 보안 상 코드를 올릴 수는 없지만...
그리고 같이 프로젝트를 진행하는 기관의 연구원님이 작성하신 코드의 동작을 분석해 우리가 작성한 코드와 비교해보기도 했다.
아무래도 연구원님은 경력도 있으시고, 이 주제에 대해 이전부터 연구를 해오셨던 분이기 때문에 코드의 퀄리티가 훨씬 높았고 지원되는 기술이 많았다.
연구원님의 코드에서 가장 인상깊었던 부분은 외부 라이브러리를 추적할 수 있었다는 점과 멀티 스레드를 지원했다는 점이다.
참고로 DB845c에서 가용한 코어의 개수는 총 8개인데, 우리 프로젝트에서는 하나의 코어를 사용하는 단일 스레드 코드를 작성했으며 실험 또한 단일 코어로 진행하였다.
📃 하드웨어 트레이스 추출 (10월)
이 때 부터는 보드에서 실제로 동작했던 안티 디버깅 기술에 대한 하드웨어 트레이스를 추출하였다.
프로젝트의 가장 핵심인 부분에 해당했다.
이것을 위해 지금까지 트레이스를 추출하려고 고생을 했고, 그 트레이스를 분석하기 위해 기드라 스크립트를 작성한 것이다.
하드웨어 트레이스를 추출한 정확한 이유와 기술의 원리는 설명할 수 없지만 우리가 의도했고 예상한 대로 추출된 트레이스의 결과를 확인할 수 있었다.
실험하는 도중 의문점이 들었던 것이 있다.
지금까지 remote GDB를 attach하기 위해 우리 연구실에서는 보드에서 코드가 무한루프를 돌게 했다.
하지만 보드에서 무한루프를 도는 코드는 제대로 GDB를 detect하긴 했지만 트레이스 상으로는 우리가 의도한 결과를 발견할 수 없었다.
그런데 코드를 무한루프를 돌지 않게 수정해서 타이머를 사용해 일정 시간 타이머를 설정하고(그 타이머의 시간 동안 GDB를 attach) 안티 디버깅 기술을 사용하는 경우 트레이스가 원하는 방향으로 추출되었다.
똑같은 기술을 사용하는데 코드가 무한루프를 도는 것과 그렇지 않은 것 사이에 어떤 차이가 있는지 알 수 없었다.
📰 프로젝트 최종보고 (11월)
11월 역시 프로젝트 최종보고 기간이기 때문에 지금까지 프로젝트로 진행해왔던 것들로 발표자료와 보고서를 만들었다.
7월에서와 동일하게, 우리 연구실에서 진행했던 모든 활동이 문서화되어 남아있기 때문에 이 작업이 크게 어렵지는 않았다 조금 번거로울 뿐.
😀 소감
내가 참여한 프로젝트는 아무래도 개발의 프로젝트보다는 연구에 초점이 맞춰져 있는 프로젝트라 개발의 경험을 할 수는 없었지만, 인생 첫 프로젝트를 통해 다른 사람들이 쉽게 접할 수 없는 특별한 경험을 했다는 것이 즐겁고 보람있었다.
내가 이 프로젝트를 기회로 생각했던 가장 큰 이유는, 아무나 할 수 없는 특별한 경험이라는 생각이 들었기 때문이었다.
기드라를 사용하는 것, 하드웨어 트레이스를 추출하는 것은 아무나 할 수 있는 경험이 아님이 확실하다. 비록 여러 삽질이 있었지만, 그래도 이 시간과 노력이 가치있다고 생각한다.
이번 프로젝트를 통해 새로운 분야를 경험할 수 있었고 무엇보다 문서화에 대한 중요성 또한 배웠다.
나에게는 1월부터 11월까지 진행된 거의 1년에 해당하는 11개월의 긴 프로젝트였다.
이 프로젝트는 나의 24살이자 대학생활의 마지막과 함께했다.
앞으로도 여러 도전을 해보고 싶다.
