&사용 케이스와 함수간 오염에 너무 큰 시간을 쏟았다.
디버깅 시간부족으로 인해서 함수간 오염전파를 포기하고, 최대한 패턴매칭으로 비슷한 일을 할수 있게 수정했다.
발표에서의 피드백을 통해 방향성을 추가로 결정 지으려고한다.

추가 개선된 로직(더 쉽게)

함수간 분석을 사용하는 부분이 대부분 하다보니 자잘한 오류가 발생했다. 그래서 대부분을 패턴매칭으로 단순화 + 함수 내에서만 추적으로 바꾸었다.

1. [step 1]. 4*x*y 형태의 연산 모두 찾기.(패턴매칭) 이전과 동일하나 기드라에서 AST및 임시 스크립트로 high p-code형태로 출력해보며 좀더 그 범위를 확실히 했다.

2. [step 2]. allocatepool,page의 역할로 추정되는 함수 찾기(패턴매칭, 함수 내 분석)
   edk2의 래퍼함수들의 사용패턴을 이용해 인수가 1개인 함수에 들어가는가로 단순화.

3. [step 3]. 변수들의 범위 검사를 하는가?(패턴매칭, 함수 내 분석)
   step 2가 뚱뚱해져서 따로 뺐다.

4. [step 4]. 오버플로우 유발 연산으로부터 해당 함수의 인수까지 도달가능하면 (함수 내 분석)
   중간에 &로 흐름이 끊겨도, 스택변수일경우 추적 가능하다

할 수 있는 것

드라이버내 모든 위험한 연산 캡처.
연산아래 allocatepool/page 요청 여부(함수 인자 갯수등으로 단순 추정)
함수내 분석에서 스택 주소로 접근해도 처리가능(제한은 추후 작성)

할 수 없는 것

함수간 분석
-> 실제 sink 도달여부 (allocatepool 역할 추정함수 패턴 매칭)
-> 실제 source 도달여부(모든 파라미터는 오염된 것으로 가정 , 인수까지만 추적)
범위 검사 한계(실제 해당 변수가 아닌 같은 값의 상수를 썼거나)

하면서 어려움을 겪었던 부분들.

• 함수간 전파를 통한 값 초기화는 어떻게 -> 함수에 의한 초기화일지도? 를 감지하는 pcodeop(indirect)로 관련된 함수호출 모두 보기
• 기드라가 추정해준 배열, 타입, 구조체의 타입 어떻게 믿고 쓰지? -> rbp근처면 변수로 취급, 멀면 구조체로 취급.
• 비교연산같이 변화가 없는 연산은 getDef로 나오지 않아요

다음주 할것

• 화요일까지 자동화를 위한 json 변환 코드 추가 + 스크립트와 테스트용 드라이버 전달.(테스트 방향성 생각해보기), 확실한 명세 전달
• 이후 할일은 아마 검증 , 자동화 쪽과 논의후 결정
• 해당 코드 내에서의 개인적인 개선은 없을 것(검증 쪽 요청 시에만 수정)

개선할 것

• 시간에 쫒겨도 일단 머리속에 떠오른는 로직을 만들기전에 이게 타당한지 고민해봤다면 좋았을텐데
• 사용중에 지금 더 쓸수 있는 API가 뭔지 고민해봤더라면 (막상 구현하니 API로 더 쉽게할수 있는 경우가 많았음)
• 드라이버를 수정해서 좀더 코드를 단순화 하면 되는데 &까지 쫒으려다가 오히려
• ai외에도 참고할 코드가 있었다면