기드라를 사용하기전에 이런 근본적인 의문이 들었다.
어째서 정적분석에 어셈도 아니고 소스코드도 아닌 p-코드(중간언어)인가?

참고한 글

p코드
기드라의 중간 언어. 기계어 인스트럭션을 더 일반적이고 확실한 방법으로 예시.

위와 같이 인스트럭션이 어떤 짓을 하는지 명확하게 표기. → 인스트럭션을 보다 명확하게, 아키텍처에 독립적.

보통 하나의 인스트럭션(기계어)가 여러게의 pcode 인스트럭션으로 쪼개지는 형태 (더 복잡해 진다) 그래서 오히려 중간언어가 어셈블리 기계어보다 더 명확하고 추상화가 덜 되어있는. (기존의 지식과 달랐다!)

sleigh
sleigh라는 언어를 사용.

추후 계획과 방향성

1. SMM, SMI, SMRAM의 키워드와 관련된 취약점만을 대상으로 찾는다.
   • 그동안 조사결과 대부분의 이슈가 SMM모드와 SMRAM과 관련되어서 튀어나옴
   • 얻을 수 있는게 많은 만큼 다양한 접근(오염시키기, 이중포인터, SMRAM 외부 실행.) -> 추후 다른 곳의 취약점으로 확장하기 유리.
   • ‘메모리’와 연관됨
     =>SMM 키워드가 포함된 취약점만 다룰 것이다. 이는 너무 추상적이므로 추후 좀더 세부적인 취약점을 선택해 나갈 예정

2. 정적 분석 방법에 대한 조사
   정적 분석을 위한 툴을 만들기 위해선, 결과적으로 취약점 분석을 위한 코드가 작성되어야할 것.
   코드의 효율적 구현을 위해서 우리가 활용할 수 있는 대표적인 정적분석 방법을 이해하고, 이를 구현하는 코드의 패턴을 익힐 것이다.
   조사할 키워드로는 patter matching, taint analysis, CFG, symbolic excution.

3. 취약점에 대한 접근
   취약점 조사및 선정 → UEFI 관련 CVE를 기준으로 조사해서 정적 분석이 가능한 것을 타깃.
   샘플 확보 → 실제 해당 취약점 존재 바이너리를 찾거나 만들 수 있는가? (현재 것에 존재하는 취약점인가?)
   정적분석 방법 찾아서 정상코드와 취약코드 구별
   오탐 필터링 방법 찾기.

4. 당장 하고 싶은 것은
   대표적인 정적 분석 방법에 대한 조사
   관심있는 곳에서 가장 만만한 취약점을 선택
   취약점의 표지, 취약점의 문제를 유발하는 입력, 어떤 사고를 초래할지 고려 이를 해결하는 알고리즘을 나이브하게 작성 (수도코드, 파이썬…)

smm 관련하여 언급되지 않은 추가 취약점 예시들을

TOCTOU(time-of-check to time-of-use)

검사 시점과 사용시점 사이에 발생할 수 있는 취약점.
실제 SMM관련 보고 사례1
실제 SMM관련 보고 사례2

참고한 블로그1
참고한 블로그2

DMA attack
Direct memory access는 말단의 디바이스가 따로 허가 없이 OS레벨까지는 직접 메모리 접근, 빠르게 일을 처리할수 있게 해줌. ex) 네트워크 어답터가 OS를 거치지 않고 바로 메모리로 가져온 정보를 보내서 빠르게 일처리
하지만 이는 pcileech같은 도구를 이용해서 직접 메모리를 수정하는 악용(DMA attack)이 가능케함.-> 이론상 코드 실행 도중 CPU 몰래 RAM에 접근, OS레벨정도의 메모리 부분은 수정가능. 이를 막기위해 IOMMU 같은 기술 개발이 이루어지고 있으나 미미하다고함.

combuffer의 TOCTOU 예시

commbuffer도 일반 모드 <-> SMM 간의 데이터 교환을 위해서 SMRAM 외부에 존재.
commbuffer의 필드 18번을 가져와서 smm_field_18의 변수(SMRAM 내부 변수)에 저장.
-> 해당 변수가 SMM 밖에 있는 지 체크, 조건통과
-> CopyMem smm_field_18이 아닌 Commbuffer의 필드를 직접 사용

만약에 조건 통과 이후, DMA 어택을 이용하여 commbuffer의 해당부분이 SMRAM을 가리키도록 수정한다면?
-> SMRAM 오염.