끝이 보인다!끝이 보인다!끝이 보인다!끝이 보인다!(수정)아... 아직이네 쓰읍

이제 .fd에서 depex문제를 검사하는 실행기와 .efi에서 obb smm callout문제를 검사하는 실행기 간의 대통합을 달성해야한다.

그러기 위해서는 순서 지정이 굉장히! 중요하기 때문에 이부분을 신경써야하고, json파일 특히, obb와 smm callout 간의 결과는 하나의 파일에 생성될 수 있게 해야하고, 배열로 두 결과가 잘 들어가게 해야한다.

 

일단 단순하게 그전의 함수들을 병합하고 난 후, 순서들도 지정해줬다. 

대략적인 구조는

main() // 프로그램 진입점, 메뉴 루프 실행
 ├─ load_config() // py_test.json 로드 및 누락 키 보정
 ├─ save_config() // lastUpdated 갱신 후 설정 저장
 └─ [메뉴 루프]
  ├─ show_menu() // 콘솔 메뉴 출력
  ├─ [1] run_option_1() // 전체 파이프라인 실행
  │     ├─ fd_unpack() // UEFIExtract로 .fd 언팩
  │     ├─ depex_analyze() // Ghidra + DepexHunter 실행
  │     │     └─ create_depex_vulnerability_summary() // Depex 취약점 결과 필터링
  │     ├─ efi_unpack() // 7-Zip 언팩 후 EFI 수집
  │     └─ oob_smm_analyze() // OOB/SMM 분석 및 병합
  │           ├─ resolve_smm_script_name() // SMM 스크립트 이름 결정/호환
  │           │     └─ extract_public_class_name() // Java public class 이름 추출
  │           ├─ [EFI 반복] analyzeHeadless 실행 // 파일별 Ghidra 헤드리스 분석
  │           ├─ [EFI 반복] consolidate_driver_reports() // 드라이버 단위 결과 통합
  │           │     ├─ load_json_records_from_file() // 리포트 JSON 로드/정규화
  │           │     │     └─ parse_concatenated_json_objects() // 붙은 JSON 객체 복구 파싱
  │           │     ├─ normalize_script_name() // 스크립트명 표준화
  │           │     └─ normalize_binary_name() // 바이너리명(.efi) 정규화
  │           └─ build_oob_smm_final_outputs() // 최종 merged/vulnerabilities 생성
  │                 ├─ load_json_records_from_file() // 파일별 레코드 재로딩
  │                 └─ report_has_vulnerability() // 드라이버 취약 여부 판정
  ├─ [2] run_option_2() // fd 언팩 + Depex 실행
  │     ├─ fd_unpack() // UEFIExtract로 .fd 언팩
  │     └─ depex_analyze() // Ghidra + DepexHunter 실행
  │           └─ create_depex_vulnerability_summary() // Depex 취약점 결과 필터링
  ├─ [3] run_option_3() // efi 언팩 + OOB/SMM 실행
  │     ├─ efi_unpack() // 7-Zip 언팩 후 EFI 수집
  │     └─ oob_smm_analyze() // OOB/SMM 분석 및 병합
  ├─ [4] run_option_4() // fd/efi 언팩만 실행
  │     ├─ fd_unpack() // UEFIExtract로 .fd 언팩
  │     └─ efi_unpack() // 7-Zip 언팩 후 EFI 수집
  ├─ [a] run_option_a() // Depex만 실행
  │     └─ depex_analyze() // Ghidra + DepexHunter 실행
  │           └─ create_depex_vulnerability_summary() // Depex 취약점 결과 필터링
  └─ [s] run_option_s() // OOB/SMM만 실행
    └─ oob_smm_analyze() // OOB/SMM 분석 및 병합

 

total_launcher.py

0.02MB

 

 

 

---

 

그 이후에 이상하게 실행시간이 길어지는 문제가 있어서 그걸 해결해야한다(depexhunter쪽에서는 아무 문제 無)

디컴파일과 엔트리포인트 잡는 과정 등의 시간과 스크립트의 실행시간을 더해도 아무리 길어야 10초 이하인데, 그 시간보다 명확하게 오래걸리고 체감상 점점 늘어지는 기분이 들었다.

 

전체 실행시간

진짜 전체 실행시간이 길어지는 게 맞았다(3개의 .efi파일에 대해서 기존에는 1분 내에 끝났었음)

일단 뭐가 문제인지 파악해야되니까 

 

분석을 안하면 9.82초가 걸리는데, 이는 필연적으로 발생하는 시간이라고 판단하였다(프로젝트 생성 및 여는 시간이라서)

로그에서는 8초라 했던 시간(스크립트를 실행하지 않는 시간)은 실제로 22.13초가 나왔다. 이 시간도 디컴파일 등의 과정을 기존 로그가 제대로 측정하지 못한 것일 뿐, 필연적으로 발생하는 것이라고 볼 수 있다.

 

따라서 시간을 최대한 줄이려면 지금처럼 analyzeHeadless를 각 파일들에 대해서 호출하는 방식을 포기하고, 한번의 analyzeHeadless호출에 여러 .efi를 처리하도록 만들어야한다.

구현상의 편의를 위해서 각 파일들에 대해서 호출하는 방식을 사용했는데, 그게 결과를 늘어지게 만드는 원인이었다.

 

1. Ghidra analyzeHeadless를 배치 프로젝트로 실행
2. -import + -recursive로 EFI 폴더 전체를 한 번에 가져옴
3. 각 EFI에 대해 postScript를 순서대로 수행
- OobHunter.java
- SmmCalloutHunter.java
4. 결과를 mid/output으로 병합

 

이런 식의 순서로 진행되게 개선

 

그래도 성능 개선했다! 드디어 마참내!

구조 자체는 크게 변하지는 않았다. 리팩토링에 가까운 무엇인가를 한 것 같다.

total_launcher_v1.0.1.py

0.02MB

 

 

---

그리고 릴리즈 노트라는 걸 작성해 보려고 한다. 

내가 변경내역을 다 기억할리가 없어

Release_Note.md

0.00MB

 

---

- config파일을 활용해서 스크립트의 추가를 용이하게 만들어보자(파이썬 자료구조로 가능할 것 같다고는 하심)

- 다른 도구들에 비해서 가지는 장점(표 형식으로)

- 최종 결과 시간에서 조금 더 디테일하게(.efi 당 걸리는 시간)