이번 준비를 하면서 부족함을 느꼈던 부분들을 정리해 보려고한다.

best 기드라 api는 어떻게 찾지?

이번 졸업프로젝트에서의 흔한 흐름은 아래와같다.

Q. 지금 내가 구현하는 형태가 비효율적이거나, 이미 기드라에서 구현한게 아닐까?
A. (LLM)’기드라 자체 헬프 스크립트를 참고하세요!’
-> 방대한 양에 포기하고 그냥 짜던대로 짠다!

그러다보니, 결과물이 ‘스마트한 연구 결과’보단 이해한 LLM코드 갈무리에 가까움.

하지만 이 방대한 스크립트 앞에서, 내가 모르는걸 뭐라 표현해야할지도 모른다
그야말로 “인덱스 없는 도서관에 던져진 상황”

원인

• 문서 읽는 참을성 부족
• from 모르는 것 - to 최적의 방법(api). 이 사이를 어떻게 연결시키지?

개선

1. 내가 구현하고자 하는것의 ‘학술적인 용어’를 먼저 파악하기.
2. 이를 구현한 API를 묻고, 기존 코드, 기드라 javadoc 활용해 검증.
3. 자주하는 분석질문과, 해당하는 API 1대1 매칭시켜두기
4. 여기서 알아낸 API와 학술적 용어를 섞어 코드를 짜달라하기 + 필요 이상으로 추상화를 낮게 구현하지 않았는지 검증

여기나온 학술적 용어는 그럼 어떻게 찾을까?
이 분야가 꽤 작아서, 단순히 구글에 자연어 검색으로는 찾기 힘들었다.
이 역시 잘 정돈해서 LLM에 질문 -> 위키나 재 질문을 통해 검증
과거 방식까지 동원하면 관련도서 목차, 용어정리 읽기, 교수님께 질문도 있다고한다.

애초에 내가 지금 직면한 문제에대한 유사한 접근 방식을 활용하는것도 도움되니 관련 취약점 보고서를 많이 읽으라고한다.

이전에 ‘제대로 구현한게 맞았나?’ 싶었던 내용들을 이전 정리에서 찾아, 직접 최적으로 만들어보는 것을 다음주에 할 것 같다.

또 추가로 이미 아이다 생태계가 잘되어있으니, 아이다에서의 구현을 참고하여서, 비슷한것이 있는지 살피는 것도 좋을 것 같다는 개인적 생각이든다.

아래는 이와 별개로 클로드가 추천한 한번 읽으면 좋을 것들

내장 스크립트중 추천할것도 줬다.

• ShowConstantUse.java — def-use 추적의 정석
• WindowsResourceReference.java — 메모리에서 패턴 찾기
• FixupNoReturnFunctions.java — 함수 분석 조작
• ghidra_scripts/ 안에서 Decompiler*.java 들 — HighFunction 사용법

UEFI 도메인코드로 efiseek같은거 코드도 읽어보라는데 솔직히 언제 참고할지 모르겠다.

또 질문할때도 필요한 API를 명시하라고 한다 -> 근데 그 API를 모른다니까

또 javadoc에서 ghidra.program.model.listing (Function, Instruction, Program) ghidra.program.model.pcode (HighFunction, PcodeOp, Varnode) ghidra.program.model.symbol (Reference, Symbol) ghidra.app.decompiler (DecompInterface) ghidra.program.model.address (Address, AddressSet) ghidra.util.task (TaskMonitor) 가 분석의 95퍼센트라고한다.

추천하는 책

• The Ghidra Book (Chris Eagle) — 챕터 14, 15 (스크립팅, 분석)가 핵심
• Ghidra 소스의 DecompilerAPI 패키지 Javadoc — 짧고 알맹이 있음

low p-code, 정말 필요할까

이번 스크립트를 작성하며 리스팅의 low p-code는 거의 사용한 적이 없었다.
정적분석을 위한 것도 high p-code 수준의 API로 모두 처리가 가능하였다.
그래서 지금 계획은 high p-code 수준의 일부 명세, 이를 이용한 기드라 정적분석의 구현등을 조사할듯하다.
추가적인 의견 받습니다..

추가로 교수님이 p-코드 관련 깊게 조사해보라 하신것의 의미가 궁금하니다.

• 관련된 공부를 뭉뚱그려서 표현한것?
• 진짜 p코드의 세부내용과 명세에 관하여?

UEFI 특화 분석 패턴도 짧게 조사 필요.

예를들어 이런 케이스가 생긴다.

내가 사용할 라이브러리를 포함해서 EDK2를 빌드했다.
그러나 리버스 엔지니어링 후, 함수 찾기가 힘들다.
그 이유는

• 사용 라이브러리 많으면, 내부에 함수가 찾기힘들정도로 증가.
• undefined 처리되었으면, 따로 함수 구조체를 찾아야함.

이런경우처럼을 대비해서 UEFI 특화의 분석 패턴을 짧게 조사할 필요성도 있다.

내 머릿속의 지우개

여러가지 프로젝트 관련 합의를 해놓고 잊어버리고, 관성적으로 처리하는 경우가 있었음.

• 처음엔 EDK2 정해진 버전을 쓰기로 했으나, 잊어버리고 그냥 최신버전 사용 (후에 다행히 커밋된지 오래된 모듈이어서 살았다.)
• p코드 기반 분석인데, 편하다보니 너무 역컴파일된 코드에 의존했고, 코드를 잘못 이해한 경우가 생겼었다.

이에 대한 것도 클로드가 꽤나 많은 얘기를 해줬다. 이것도 다음주에 발표에 포함해볼까 한다.