[suggest new pipeline] add emulation_optimization

[0x653o]

✦ SCOUT 프로젝트의 현재 상태를 바탕으로, "동적 검증(Dynamic Validation) 성공률이 낮고 정적 분석 결과에 의존적이다"라는 핵심
페인 포인트를 해결하기 위해 5 Whys 기법을 사용하여 근본 원인을 분석하고 개선점을 제안하겠습니다.

---

[5 Whys 분석]
문제 정의: 정적 분석(Static Analysis) 결과는 많지만, 실제로 동작하는 PoC를 생성하는 'Confirmed' 단계의 성공률이 기대보다
낮음.

1. Why (1): 왜 동적 검증 단계에서 결과가 'Confirmed'로 승격되지 못하는가?

   • 답변: 펌웨어가 에뮬레이션 환경(FirmAE/QEMU)에서 정상적으로 부팅되지 않거나, 특정 네트워크 서비스가 올라오지 않기
     때문입니다.

2. Why (2): 왜 펌웨어가 정상적으로 부팅되지 않거나 서비스가 실행되지 않는가?

   • 답변: 에뮬레이션 환경이 펌웨어가 기대하는 하드웨어 주변기기(Peripheral, NVRAM, 특정 칩셋 등)를 완벽하게 모사하지
     못해 초기화 스크립트에서 중단되기 때문입니다.

3. Why (3): 왜 하드웨어 주변기기 모사가 완벽하지 않은가?

   • 답변: 각 제조사(ASUS, D-Link, Netgear 등)마다 고유한 하드웨어 종속적인 커널 모듈과 NVRAM 설정을 사용하는데, 현재는
     FirmAE라는 범용 도구 하나에만 의존하고 있기 때문입니다.

4. Why (4): 왜 제조사별 고유한 부팅 로직을 자동으로 처리하지 못하는가?

   • 답변: 파이프라인의 firmware_profile 단계에서 정적 분석 정보는 추출하지만, 이를 바탕으로 에뮬레이션 환경을 동적으로
     재구성(Mocking)하는 기능이 부족하기 때문입니다.

5. Why (5): 왜 에뮬레이션 환경을 동적으로 재구성하지 못하는가?

   • 근본 원인(Root Cause): "에뮬레이션 전단계(Pre-Emulation)에서 LLM이나 정적 프로파일링 결과를 이용해 NVRAM 값을
     예측하거나 가상 드라이버를 자동 생성하는 '하드웨어 추상화 레이어(HAL) 생성 단계'가 파이프라인에 없기 때문"입니다.

---

[개선 제안 (Enhancement Proposals)]

위의 근본 원인 분석을 바탕으로 SCOUT의 신뢰성을 한 단계 높일 수 있는 3가지 개선 제안입니다.

1. AI 기반 'NVRAM/Peripheral Mocking' 단계 추가

• 제안: emulation 단계 바로 앞에 emulation_optimization 단계를 추가합니다.
• 방법: inventory 단계에서 추출된 부팅 스크립트와 binwalk로 찾은 설정값들을 LLM(Claude/Codex)에게 전달하여, 부팅 실패를
  유도하는 특정 체크 로직을 우회할 수 있는 nvram.ini 파일이나 더미 라이브러리(LD_PRELOAD용)를 자동으로 생성하게 합니다.

2. 'Partial Emulation' (Chroot + QEMU User-mode) 강화

• 제안: 전체 부팅(Full System Emulation)이 실패하더라도 개별 바이너리만이라도 실행해 볼 수 있는 '부분 에뮬레이션'을
  표준화합니다.
• 방법: 현재 FirmAE가 실패하면 바로 중단되는 경우가 많은데, qemu-user-static을 활용해 타겟 바이너리만 별도의 네트워크
  네임스페이스에서 실행하여 입력값에 따른 Crash 여부만이라도 확인하는 단계를 강화해야 합니다.

3. Docker 레이어 최적화 및 'Pre-built Base' 구축

• 제안: 현재 우리가 수정한 Dockerfile은 빌드할 때마다 많은 도구를 새로 설치합니다. 이를 'Core(도구)'와
  'Environment(SCOUT)'로 더 명확히 분리해야 합니다.
• 방법: Ghidra, Binwalk v3, FirmAE가 이미 설치된 scout-base 이미지를 별도로 관리하고, 실제 SCOUT 코드는 이 베이스 이미지
  위에서 가볍게 동작하게 하여 CI/CD 및 분석가 배포 속도를 5배 이상 높여야 합니다. (빌드 최적화)

---

이 5 Whys 분석을 통해 볼 때, 단순히 도구(Binwalk v3 등)를 업그레이드하는 것을 넘어 "정적 분석 결과를 에뮬레이션 환경의
설정값으로 자동 변환해주는 지능형 브릿지"를 만드는 것이 SCOUT가 "Solid"해지는 다음 단계가 될 것입니다.

with gemini

[R00T-Kim]

Thanks for the thoughtful analysis! The 5 Whys breakdown accurately identifies the core problem.

Current State in SCOUT

Your suggestions align well with what we're already building:

Proposal 1 (NVRAM/Peripheral Mocking) — This is our highest-priority gap. We're currently integrating Pandawan/FirmSolo (USENIX Sec 2024) as a Tier 1.5 fallback, which uses KCRE (Kernel Config Recovery Engine) to build custom kernels for better re-hosting. An LLM-based NVRAM prediction layer on top of this would be a natural next step.

Proposal 2 (Partial Emulation) — Already implemented as Tier 2 in our pipeline (_try_tier2() in emulation.py). It uses qemu-user-static + chroot to run individual binaries when full-system emulation fails. We probe for listening sockets and network services.

Proposal 3 (Docker Layer Optimization) — Good engineering suggestion. We're currently working through this with the scout-emulation Dockerfile (see PR #1).

Where This Fits in Our Roadmap

We're planning the emulation improvements in phases:

1. Pandawan/FirmSolo integration (in progress) — better kernel-level re-hosting
2. LLM-guided boot script analysis — predict NVRAM values from init.d scripts
3. Vendor-specific HAL profiles — pre-built config templates per vendor/chipset

The emulation_optimization stage you describe would sit between firmware_profile and emulation in our 42-stage pipeline. We'll track this as a future enhancement.

Appreciate the contribution — this kind of analysis helps prioritize our work.