VM? Virtual..?? Vulnerability Analyst Diary 안녕하세요, 저는 이번 발표에서 BoB에서 프로젝트로 진행했던 내용에 대한 일지를 발표하게 된 임재혁이라고 합니다.

Contents VM ? Qemu Analysis Project Diary. About VM Project. Tips on VM Analysis. Other member’s opinion. 제가 발표를 하게 된 내용의 컨텐츠는 다음과 같습니다. 우선 VM이 무엇인지 간략하게 알아보도록 하고, 저희가 프로젝트를 진행했던 Qemu를 분석하는 프로젝트 다이어리에 대해서 이야기해 볼 것입니다. 또한 VM 프로젝트에서 어떤 부분이 어려웠고, 어떤 실패를 겪었는지 그러한 내용들에 대해 다룰 생각이며, VM 분석에 있어서 만약 VM 분석 프로젝트를 하게 된다면 어떠한 팁이 있는지, 저희 경험을 통해 쌓여진 내용들에 대해 이야기해보는 자리를 갖도록 하겠습니다. 또한, 저희 프로젝트 멤버에서 다른 분의 프로젝트 의견, 어떤 어려움이 있었는지, 팁 등에 대해서 이야기 해 볼 것입니다.

0. Topic 당시 저희가 프로젝트의 주제를 이러한 주제로 잡은데는 다양한 몇 가지 이유가 있었습니다. 우선 저희 프로젝트의 배경은 VENOM취약점이 이슈화 되는 상황과 클라우드 시스템이 대중화 된 상황이 결합되어 결정하게 된 프로젝트 주제였습니다. 맨 처음 프로젝트의 목표를 잡았을 때는, 자잘한 Crash에서부터 DoS 취약점, Remote Code Execution 취약점 등 다양한 버그를 분석하는 것을 첫 목표로 잡게 되었습니다.

1. VM ? Virtual Machine Software for Cross-platform Compatibility Vmware, QEMU, VirtualBox, Parallels.. 취약점을 분석하는 내용으로 들어가기 전에, 저희는 가상화, VM에 대한 다양한 경험을 필요로 했습니다. 우선 VM이 무엇일까요? VM이란 Virtual Machine의 줄임말로, 크로스 플랫폼을 위한 소프트웨어라고 볼 수 있습니다. 대표적으로 Vmware, VirtualBox, Parallels 등이 있는데, 우리들은 이 VM 기능을 지원해주는 소프트웨어를 통해 일반적으로 다양한 멀티 플랫폼을 구동을 하는 편이기도 하지요.

1. VM ? Full-Virtualization Para-Virtualization 음, 이 슬라이드는 그냥 부가적으로 추가한 내용이긴 한데, 저희가 프로젝트를 진행하면서 첫 몇 달간은 가상화에 대한 선수지식을 쌓기 위해서 가상화 기능을 직접 구현해보거나, 가상화에 관련된 해외 원문 등을 해석하면서 읽어보기도 하고 다양한 경험을 하게 되었습니다. 이 발표는 프로젝트 다이어리에 대한 소개지만, 대략적으로 가상화가 어떠한 내용이구나~ 정도로만 알고 넘어갈 수 있도록 추가한 슬라이드입니다. 가상화의 종류에는 Full-Virtualization과 Para-Virtualization이 대표적인데, 전자의 경우에는 말 그대로 전체 하드웨어를 가상화한다는 개념으로, Guest OS들과 하드웨어 사이에 VMM이 들어가 모든 명령을 중재하는 형태로 이루어지게 됩니다. 반가상화는 전가상화에서 발생하던, 몇 가지 문제점에 의해 제시된 개념인데, 전가상화에서는 모든 명령을 하이퍼바이저가 핸들링하지는 않는 형태이며, 딱 필요한 부분만 처리하게 됩니다. 또한 성능 상의 이점을 위해 HyperCall이라는 개념이 도입되었는데 이 반가상화의 경우에는 Guest OS가 컨트롤 도메인을 통해 하이퍼바이저와 통신하는 것이 아닌, 직접 HyperCall을 호출하여 통신하는 형태가 되겠습니다. 전가상화나 반가상화나 전부 CPU 레벨에서 가상화 칩을 제공해주기 때문에 이 칩을 통해 하드웨어와 OS사이에 하이퍼바이저를 띄워서 사용할 수 있게 됩니다. 대표적으론 인텔의 VT-x 등이 있는데.. 자세한 내용은 나중에 직접 가상화를 공부하시게 되면, 일명 공룡책이라고 하는 책을 참고하시면 도움 될 듯 싶습니다.

2. Analyse Diary Project Topic : QEMU Vulnerability Analysis Presented by PL (cd80) qemu-system-x86_64, qemu-system-i386 … VCPU, CVE Analysis, QEMU user manual … QEMU Internals .. 저희 프로젝트의 주제는 앞서 말씀드렸다시피 QEMU의 취약점, 버그들을 분석하는 것의 프로젝트의 토픽이었습니다. 프로젝트의 PL은 성우가 맡아주게 되었고, 당시에 저는 성우에게 프로젝트 추천을 받고 팀 이 프로젝트에 참여하게 되었습니다. 그 전에는 치현이형과 제가 병원 시설기반 취약점을 분석하자고 이야기를 하던 상황이었는데, 아무래도 병원이라던가 그런 곳의 시스템은 컨택하는 것부터가 쉬운 일이 아니기 때문에 프로젝트를 제대로 시작하지도 못하고 무산될 가능성이 있었는데, 오픈소스의 취약점을 분석하자는 이야기는 저에게 끌리는 이야기로 다가왔고, 팀원들을 설득해서 시작하게 되었습니다. Qemu에는 많은 종류가 있는데, x86_64 시스템, i386 시스템에서부터 mips, mipsel, arm 등 다양한 qemu가 존재합니다. 그 중에서도 저희는 i386과 x86_64를 중심으로 분석하게 되었습니다. 하지만, 중심으로 분석한다! 정도지 다른 것들을 분석하지 않는다는 말은 아니었고, 만약 버그를 발견한다면 다른 버전도 빌드해서 분석하겠다는 생각 정도는 하고 있었습니다. 저희는 프로젝트를 진행하기 위한 선수과정으로 VCPU를 직접 만들어보거나, CVE 들을 다양하게 분석해봄으로써 버그가 발생하는 다양한 변수들을 접해볼 수 있었고, Qemu 매뉴얼 등을 보게 되었습니다.

2. Analyse Diary CVE – Vulnerabilities in many cases 저희가 CVE 분석을 하게 되었던 이유는 다양한데, 우선 프로젝트를 선정했던 이유 또한 CVE에도 존재했습니다. CVE를 보면 알 수 있지만, 다음 그래프에서도 이전에는 취약점이 발견되지 않다가, 갑자기 2014년이 되어서야 많이 발견되는 것을 확인할 수 있습니다. 대부분 이번 iptime이라던가, 취약점이 대량으로 발생되서 더 이상 발견할만한 이렇다한 취약점이 없는 경우는 꽤 긴 시간동안 취약점이 여러가지 발견되다가 갑자기 천천히 줄어드는 동향을 보이게 됩니다. 반면에 Qemu 취약점은 이전에는 잘 발견되지 않다가, 갑자기 2014년에 히트를 치게 되고 그 이후에는 그다지 발견되지 않은 상태입니다. 그렇기 때문에, 잠재적인 취약점이 대량으로 존재할 것이라고 판단하였고 접근하게 되었습니다.

2. Analyse Diary CVE 분석이라는 과정을 통해 저희는 다양한 상황의 버그를 접할 수 있었고, DoS, Remote Code Execution 등이 대략적으로 어느 벡터에서 발생할 수 있는지, 그러한 내용들에 대해 배울 수 있었습니다. 팀원들은 각자 배분받은 CVE를 분석을 하였고, Source Code Diffing 등 다양한 방법을 시도하게 되었습니다. 이는 이후에도 이전 버전과 어느 코드들이 달라졌는지 알아보기 위해서 Diffing 기능이 활용되기도 하였습니다. 비록 CVE 분석 자체를 통해 실질적으로 무언가 얻은 것은 아니지만, 공격벡터에 대한 감을 잡는데 도움을 주었던 내용이었습니다.

2. Analyse Diary Virtualization ( Emulator ) 그리고 저희는 가상화를 직접 구현해보게 되었는데, 이는 아마 SSA에서 성우의 스터디를 참여해본 학생이면 한번쯤은 해보았을 내용인데, 그 이전에 저희는 프로젝트 선수과정 중에 가상화를 구현하는 것을 이를 통해 하게 되었습니다. 구현했던 내용을 간략하게 이야기해보자면, C를 이용하여 개발을 하게 되었고 Opcode를 비트 단위로 세밀하게 설계를 하게 되었습니다. 어떤 플래그가 세워져있다면 어떤 형태의 데이터타입인지, 이러한 내용들을 하나하나 직접 작성하게 되었고 xor이나 add, sub 등 다양한 연산들을 직접 구현을 하게 되었습니다.

2. Analyse Diary 한 가지, 또 개발했던 것은 NIC Fuzzer로, 네트워크에 데이터를 보냄으로써 NIC 디바이스에서 크래시를 찾아주도록 Fuzzer를 작성한 부분이 있었는데, 이 부분은 프로젝트 팀원이었던 고려대학교의 장하진 형이 개발을 하셨습니다. 하지만 이 Fuzzer는 그다지 큰 역할을 수행하지 못했고, 나중에 그저 참고 자료로만 남게 되었습니다. 언젠가는 좀더 정교한 형태의 NIC Fuzzer를 따로 설계하고 작성해볼 생각입니다.

2. Analyse Diary http://clang-analyzer.llvm.org/scan-build.html 프로젝트 초창기에 사용했던 도구로는 llvm의 scan-build라는 도구가 있었습니다. 이는 자동화 도구? 라고 보기는 조금 애매한 부분이 있기는 한데, scan-build는 프로젝트를 빌드할 때, 중간에 어떤 잠재적인 버그가 존재할 수 있는지 진단하여 리포팅해주는 형태의 자동화 분석 프로그램이었습니다. 이 프로그램을 사용해서 얻을 수 있었던 버그로는 divide by zero, use-after-free 등 다양한 버그가 존재했지만, 여기서의 Use-After-Free는 실제로 RIP를 변조할 수 있는 형태의 버그가 아니었고, 그저 코드 상으로만 같은 메모리가 재사용되기 때문에 탐지되었던 Use-After-Free 버그였습니다. 처음에는 Qemu 소스코드 자체가 너무 방대하고 분석하는 과정에서 어려움을 겪었기 때문에 자동화를 수행하는 도구를 알아보는 것은 어떨까? 라는 의견에서 시작되었던 부분이지만, 그렇게 좋은 결과를 얻지는 못하였고, 어떤 버그가 잠재적으로 내포되어있고 발생 가능한지, 정도만 파악할 수 있는 과정이 되어버렸습니다.

2. Analyse Diary Main : NIC Device, USB Device .. 저희가 프로젝트를 진행하면서 주로 분석했던 부분이 있는데 주로 디바이스를 위주로 분석을 하였습니다. NIC, USB 등 디바이스를 중심으로 분석을 하게 되었는데, NIC의 경우에는 이전에도 ne2000_receive, e1000_receive 등 다양한 NIC 디바이스의 Receive 함수에서 Overflow 취약점이 발생하였다는 것을 CVE 분석과정에서 알 수 있었고, 그에 따라 NIC는 저희들의 분석 대상 중 하나가 되었습니다. 하지만 이미 이전에 NIC의 경우에는 많은 버그가 발견된 상태이기 때문에, 많은 해커들이 NIC를 중심으로 취약점 분석을 시도했고 존재하던 취약점들 중 많은 요소들이 이미 패치된 상태였습니다. 또한 저희가 프로젝트를 진행하던 도중에 새로운 취약점이 발견되어 패치되어 버리는 안타까운 상황이 발생하기도 했습니다. 저희는 NIC만 분석해서는 버그를 찾기 어려울 것이라고 판단했고 다른 디바이스도 분석을 하자는 의견을 내게 되었습니다. 그 대상은 USB로 결정되었는데, 그 이유는 기능이 지원되기 시작한지 얼마 되지 않은 디바이스임과 동시에 User control을 내포하고 있는 디바이스이기 때문에 Buffer Overflow 등 다양한 버그가 존재할 수 있다는 가정을 하고 분석 대상 디바이스에 추가를 하게 되었습니다.

2. Analyse Diary Project result ? -> Vmware Crash 1 -> Qemu Crash 2 : From USB Device 그래서 프로젝트 결과물은 Vmware에서 크래시를 1개 발견했고, QEMU에서는 DoS 크래시를 2개 발견하였습니다. 둘 다 USB 디바이스에서 발견할 수 있었고, 직접 모듈을 시스템에 로드시켜보았는데, 연결이 끊기는 것을 확인할 수 있었습니다. 버그는 UHCI에서 발견할 수 있었고, 크래시를 발견했던 것은 송치현(yum3)형이 발견을 하셨고 원인을 제가 분석하고 그 내용을 기반으로 버그 트리거 코드가 작성되었습니다.

3. About VM Project About Failure.. -> LLVM Scan-build, Source Code Auditing -> Network Fuzzing Fuzzing -> IO Port Fuzzing -> NIC Device Fuzzing 이제, 프로젝트에 대한 설명은 이정도까지만 하도록 하고, VM 프로젝트에 대한 제 의견을 이야기해보겠습니다. 먼저.. 다양한 실패, 시행착오를 통해서 이런 방법은 시도하지 않는 것이 좋다, 이런 것은 시도 해보는 것이 좋다. 이런 지식들이 확립되엇고, 음.. 좋은 예시를 몇 가지 들자면 scan-build는 좋지 않으며 Source Code Auditing은 좋습니다. 그 이유를 설명하자면, scan-build는 그저 빌드하는 과정에서 잠재적으로 버그가 발생할 수 있을만한 코드를 진단하는 도구입니다. 그렇기 때문에 실제로 취약점이 발생할 수 있는 다양한 트릭, 버그 등은 탐지하기 어렵다는 단점이 존재합니다. 만약 scan-build가 모든 다양한 상황에서의 버그를 발견할 수 있다면, 뭐.. 이미 익스플로잇 자동화나 취약점 분석 자동화가 대중화되지 않았을까요? 그만큼 완벽하게 정교한 자동화 분석 도구라고 보기에는 어려우며 scan-build가 탐지하지 못하는 버그가 사람이 눈으로 찾을 수도 있다는 뜻이지요. 그렇기에 Source Code Auditing이 사실상 scan-build에 의존하는 것 보다는 낫습니다. Source Code Auditing은 음.. 삽질이라고 볼 수 있겠네요. Qemu의 소스코드는 일반 소프트웨어나 그런 수준의 소스코드가 아닌 만이라는 단위가 나오는 방대한 프로젝트입니다. 그 거대한 프로젝트에서 취약점이 어느 코드에서 발생할 수 있는지, 유저 컨트롤은 어느 부분에서 이루어질 수 있는지, 이를 분석하는 것은 매우 어려운 일입니다. 어려울 수 밖에 없지요. 그렇기 때문에 저희들이 CVE 분석이나 VCPU 개발이나 다양한 과정을 경험해본 것입니다. 그 방대한 양의 소스코드에서도 중심적으로 어느 부분을 분석해야 하는지, 그리고 어느 부분이 User Accessible한지, 이를 구분하기 위해서는 선수지식이 필요했으니까 말이죠. 저희는 프로젝트 중간 중간 Fuzzing 작업도 함께 병행했습니다. Fuzzing을 통해서 무작위적으로 NIC나 IOport에 데이터를 쓰게 만들었고, Fuzzing 또한 버그 탐색에 큰 역할을 발휘했습니다. 소스코드 오디팅도 좋은 방법이긴 하지만, 버그가 발생할 수 있는 부분임에도 분석자가 못보고 지나칠 가능성이 있기 때문에, 어떠한 입력값에 의해서 버그가 발생할 수도 있을 것이다. 라는 가정하에 Fuzzer를 작성하여 소스코드 오디팅을 하는 동시에 따로 돌려놓는 형태로 퍼징작업도 시도하게 되었습니다.

3. About VM Project But it’s so difficult. For Example) 1. hw, cpu.. Many directories, files.. 그럼 프로젝트의 어려움에 대해서 좀 알아보도록 합시다. 음.. 아까도 언급한 내용이긴 하지만 소스코드가 매우 방대합니다. 직접 qemu 버전을 하나 다운받아서 확인해보면 많은 디렉토리에 엄청나게 많은 파일들로 이루어져 있는 것을 볼 수 있습니다. 이를 전부 눈으로 분석한다..? 어렵죠. 시간만 오래 갖는다면 전부 분석하는 것도 가능하기야 하겠는데, 체력적인 문제도 있고 어렵겠습니다.

3. About VM Project 2. Each files.. WTF.. 또한 중요한 점이 있습니다. 각각의 파일들을 하나씩 열어보면 알겠지만, 각각의 파일마다 방대한 양의 소스코드를 가지고 있습니다. 그렇게 많은 디렉토리, 파일들이 존재하는데 그 각각의 파일마저도 이렇게 방대한 양의 소스코드가 있다.. 어떻게 분석하실건가요? 이럴 경우에는 프로젝트를 설명하면서 말했던 취약점을 분석할 중심내용을 선정하는 것이 현명한 방법입니다. 무작정 모든 코드를 분석하겠다고 달려들면 체력만 빼게 됩니다. 또한 취약점을 분석하겠답시고 모든 코드를 분석하게 되면 그 과정에 시간 또한 매우 많이 걸리기 때문에 그 기간동안 새로운 취약점이 발견되어 버전이 업데이트되어 버리는 참사가 발생할 수도 있겠습니다.. 그렇기 때문에 필요한 부분만 선정하여 분석하는 것이 매우 중요한 일이 아닐 수 없겠습니다.

3. About VM Project 3. Require a lot of knowledge.. -> VM knowledge(Hypervisor …) -> Syshack Technique(ROP, Memory Leak ..) -> Device Knowledge … (NIC, USB …) …. VM 프로젝트를 진행하기 위해서는 또한 매우 많은 지식이 요구됩니다. 예를 들어서 하이퍼바이저 같은 개념에서부터, VM의 구조 같은 지식들이 필요하며, 기본적으로 취약점을 분석하기 위해서는 시스템 해킹의 테크닉도 필요합니다. 예를 들자면 ROP나 메모리 릭 같은 개념들 말이죠. 요즘 대부분의 소프트웨어, 시스템에는 다양한 메모리 미티게이션이 적용되어 있기 때문에 메모리릭이나 ROP 같은 테크닉은 필수 요소로 작용하는 편입니다. 디바이스에 대한 지식도 매우 중요한 자리를 차지하고 있는데요, CVE를 보면 알겠지만 다양한 버그들이 주로 디바이스에서 발생하는 것을 확인할 수 있습니다. NIC나 UHCI 등등.. 다양한 디바이스에 대한 지식들이 요구되며, 이러한 내용들은 한글로 문서화된 문서들이 그다지 존재하지 않습니다. 물론 저희가 프로젝트를 진행하면서 번역하거나, 작성했던 문서들을 나중에 올리긴 할 생각이지만 저희가 프로젝트를 진행할 때는 documentation들이 그다지 존재하지 않아서 어려움을 겪었습니다. 또한 UHCI 구조체에 대한 내용과 그에 관련된 모듈 프로그래밍, 함수 등은 한글 documentation은 기대도 할 수 없었고, 리눅스 매뉴얼에서나 소스코드를 겨우 일부 구할 수 있는 정도였습니다.

3. About VM Project If you will start VM analyse Project .. 만약 앞으로 선발될 BoB 5기 생들이라던가.. 주변인이 VM 취약점 분석 프로젝트를 시작한다면? 음.. 제 의견은 왠만해선 다른 프로젝트를 진행하라고 하고 싶긴합니다만 VM 취약점 분석 프로젝트를 꼭 하고 싶다면, 제 의견은 무작정 코드 분석에만 달려들지 말라는 것입니다. 일반적으로 버그만 찾으면 익스플로잇이 가능한 그러한 상용 소프트웨어 취약점, 이런 경우에는 그저 분석으로만 접근해도 괜찮겠습니다만 QEMU나 VirtualBox 같은 가상화 소프트웨어의 취약점을 분석하기 위해서는 많은 선수지식이 매우 큰 중요성을 가지고 있습니다. 예를 들어서, 우연히 크래시를 발견했다. 하지만 그 크래시가 발생하는 디바이스에서 어떤 원인때문에 발생하는지, 그 디바이스의 구조체가 어떤 형태로 이루어져있는지, 이 Element가 어떤 역할을 수행하는지. 이런 내용들에서 막힐 가능성이 적지않기 때문에 이러한 지식들에 대한 학습도 필요하겠습니다. 또한, 음.. 가상화에 대한 취약점을 분석을 하는데 가상화가 어떤 형태로 이루어지는지, 기초적인 내용으로 넘어가서 하이퍼바이저가 무엇인지도 모른다면 가상화 취약점을 분석하고 익스플로잇하는데 무리가 있겠죠? 예를 또 들자면 VM Escape를 하기 위해서는 어째서 디바이스와 같은 코드를 분석해서 그 부분에서 익스플로잇을 해야하는지.. 이런 내용들에 대해서 이해하기 위해서는 가상화에 대한 개념이 필요합니다. 또한 도구를 활용하는 것도 중요합니다. 퍼징이라던가.. Scan-build도 사실 소스코드 오디팅이 더 효율적이긴 합니다만 저희가 활용을 잘 하지 못했던 것이라고 생각하며 이와 같은 도구들도 활용하는 편이 더 좋다고 생각합니다. 퍼징 작업에 대해서도 강조하고 싶습니다만 저희가 발견한 DoS의 경우에는 퍼징 기술이 중간과정에서 사용되었기 때문에 디바이스, IOPort 등을 대상으로 한 퍼징은 일부분 필요한 부분도 있다고 생각합니다. 무작정 아무 부분에나 퍼징을 하는 것이 아닌, NIC에 대한 이해, USB 디바이스에 대한 이해 등 기초 지식에 기반하여 필요한 부분만 퍼징을 수행해주는 센스도 필요하다고 생각합니다.

4. Tips on VM Analysis Focus on Device Module : Many accessible user controls. Foresee many cases vulnerabilities -> Like Use-After-Free, DoS Vulnerability.. VM 분석에 있어서 몇 가지 팁을 주자면, 디바이스 코드에 초점을 맞춰서 분석하세요. 저희 경험상 많은 유저 컨트롤이 가능한 영역은 디바이스 영역입니다. 예를 들어서 네트워크 디바이스를 구현한 receive 함수 코드에 데이터를 보낼 경우에는 NIC에서 Buffer Overflow가 일어난다거나, 이러한 상황이 생길 가능성이 존재하니까 말이죠. Guest OS내에서 Buffer Overflow를 일으킨다고 하더라도, 그게 만약 마더 프로세스가 아닌 Guest OS내에서만 한정적으로 Memory Corruption이 일어나는 거라면 소용이 없습니다. 그렇기 때문에 마더OS에서 RIP를 컨트롤할 수 있는 취약점 즉, VM Escape를 찾기 위해서는 마더OS를 건드릴 수 있는 버그를 찾아야하기 때문에 디바이스 코드를 위주로 살펴보는 것이 가장 좋습니다. 또 추가적으로 USB의 경우에도 디바이스 코드가 추가된지 그렇게 오래되지 않았습니다. 새로 추가된 코드의 경우에는 취약하게 작성될 가능성이 없지않아 있기 때문에 이미 취약점이 많이 공개되고 여러 차례 패치가 이루어진 디바이스보다는 새로 추가된 기능을 분석하는 것이 가장 효율적이겠지요. 두 번째 팁은, 절대로 취약점을 한정적으로 바라봐서는 안됩니다. 대부분 취약점이라고 한다면, Buffer Overflow, Format String Bug, Command Execution 등을 생각하시는 분들이 많습니다만, Assertion Failure같은 비정상적인 익셉션의 경우에도 DoS와 같은 유형으로 분류할 수 있습니다. 그렇기 때문에 취약점을 기존의 소프트웨어에서 발견하던 일반적인 오버플로, 익스큐션같은 취약점에만 한정적으로 코드를 바라봐서는 안된다는 점입니다. Overflow, Execution 같은 취약점은 대부분 눈에 쉽게 띄며 발견되는 것이 어렵지 않은 편이기 때문에, 개발자들은 소프트웨어를 개발하면서 그런 취약점이 발생될 가능성들을 최대한 패치하는 과정을 거치며 프로그래밍을 수행합니다. 좋은 예시로 NIC의 경우에는 디바이스에서 오버플로우 취약점이 많이 발생되었습니다. Pcnet, vmxnet, imx 등 다양한 NIC 디바이스 코드들은 이전에 많은 취약점이 발생되었기 때문에 새로이 추가되거나 패치가 될 때, 개발자들은 더욱 신중히 코드를 작성합니다. 그래서 점점 늦게 추가된 디바이스 코드일 경우에는 더 secure하게 작성된 것을 확인할 수 있습니다.

5. yum3’s opinion yum3’s opinion Few documentation Too many source code Importance of Hardware Manual Fuzzer Yum3는 저희 프로젝트 팀이셨던 치현이형의 닉네임입니다만, 치현이형의 의견도 한 번 물어보았습니다. 그 형은 간략하게 2개의 팁과 2개의 프로젝트의 어려움에 대해서 이야기하셨는데, 먼저 문서화된 자료가 그다지 없다는 부분을 어려움으로 드셨습니다. 저도 이건 앞서 거론한 내용이지만, 문서가.. 정말 없습니다.. 그렇기 때문에 CVE를 읽어보고 바이너리 디핑을 통해 어떤 식으로 취약점이 발생하는지 알아봄으로 VM 취약점에 대한 감각을 익혀야하며, QEMU의 디바이스 구조체에 대해서 설명하고 문서화, 또 어떤식으로 컨트롤해야하는지 알려주는 문서가 거의 존재하지 않기 때문에, 직접 리눅스 매뉴얼이나 디바이스 구조를 학습함으로써 접근해야하는 어려움이 뒤따릅니다. 또한 소스코드가 매우 많다는 점을 어려움으로 선정하셨는데, 소스코드가 대략적으로 몇 백만줄의 단위를 넘나들기 때문에 모든 디바이스 코드, CPU 코드, VNC 코드 등.. 다양한 모든 코드들을 분석하는 것은 무리라고 볼 수 있습니다. 몇 번이나 강조하는 내용이지만 그렇기 때문에 분석할 중심 코드를 선정하고 분석하는 것이 가장 좋습니다. 저희 팀이 했던 것처럼 Device를 중심으로 분석한다던가 말이죠.

Thank you!! 감사합니다.