방망이

왜 업그레이드가 필요한가기존에 작성한 DepexHunter 스크립트는 UEFI 펌웨어 이미지를 UEFIExtract로 풀어놓은 덤프 폴더를 순회하면서, 각 DXE 드라이버의 DEPEX(Dependency Expression) 섹션을 파싱해 "이 드라이버가 요구하는 프로토콜이 이미지 안의 어떤 드라이버로도 제공되지 않는" 경우를 찾아내는 스크립트다. 이 스크립트는 GhidraScript를 상속하고 있음에도 정작 Ghidra의 핵심 기능인 디스어셈블/디컴파일/P-code 분석은 전혀 쓰지 않는다. 실제 동작은 info.txt와 body.bin을 텍스트·바이너리 레벨에서 직접 파싱하는 파일 시스템 순회에 가깝다. 프로토콜을 "누가 제공하는가"를 판단하는 로직도 마찬가지로 코드 분석이 아니라 이름 매칭에 의존..

- 오늘의 주제 및 키워드 > 데이터 흐름 기초 > [Reaching Def, Def-Use, Live Variable] 데이터 흐름 (Data Flow Analysis)P-code로 취약점을 분석할 때 핵심 포인트는 "외부에서 들어온 값이 위험한 함수까지 도달할 수 있는가?"에 대한 것.이 질문에 대한 답을 하기 위해서는 코드를 실행하지 않고도 값이 어디서 왔고, 어디로 흘러가는지 파악할 수 있어야 함. 1. Def-Use Chain변수의 정의(Def)와 사용(Use)을 연결한 체인Def - 변수에 값이 처음 할당되는 지점(의미 있는 값이 처음 들어오는 시점)Use - 그 값이 입력으로 읽히는 지점아래 코드를 예시로 들어보자.void func(int sock) { char buf[64]; ..

[P-code 공부 커리큘럼] Phase2에서 4, 5번에 대한 내용은 팀원들의 블로그를 참고한다.Phase2 - 4 (Varnode, PcodeOp) https://ludence8.github.io/%EC%A1%B8%EC%97%85%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8/2026-05-16-PCode-1.html Ghidra P-Code 알아보기 1P-Code (사실 P-Code는 다들 너무 잘 알고 있을 것이라 생각한다…) P-Code는 Ghidra가 사용하는 IR로, 다양한 프로그래밍 언어들을 통일하기 위한 목적인 컴파일러 레벨의 IR들과 달리 P-Code는 MIPS, x86, ARMludence8.github.ioPhase2 - 4 (SLEIGH, High Pcode vs..

01 어셈블리 기초핵심 레지스터 (x86-64)RAX 64-bit accumulator 함수 반환값, 산술 연산 RBP base pointer 스택 프레임 기준점 RSP stack pointer 현재 스택 탑 위치 RIP instruction pointer 다음 실행할 명령어 주소 RDI/RSI 1st / 2nd argument 함수 인자 (Linux x64) RDX/RCX 3rd / 4th argument 함수 인자 (Linux x64) 어셈블리 읽기 — 실제 예제아래는 int add(int a, int b) { return a + b; } 의 컴파일 결과입니다 0x1129 push rbp ; 호출자 RBP 저장 0x112a mov rbp, rsp ..

기존에 진행하던 프로젝트의 전반적인 개발은 일단락 되었고, 앞으로 진행할 방향에 대해 고민하는 시간과 함께 스크립트 발전에 대해 목마른 팀원분들과 함께 P-code를 공부해보고자 한다. P-code 공부는 AI를 활용하고자 한다.이번주는 P-code에 대해 개념 공부를 하기 보단 커리큘럼을 먼저 설계해보기로 하였다.이를 위해 내가 주로 쓰는 세 가지 정도의 AI 툴로 테스트 해보았고, 모두 동일한 프롬프트를 사용하였다.Claude Sonnet 4.6 (무료)Gemini Pro (유료)Chat GPT (무료)P-code에 대해 잘 모르는 사람 입장에서 위 세 가지 툴 모두 시키는거 많고 해야할 거 많고 체계적으로 짜준 것 같긴 하다만 Claude가 로드맵 형식으로 구체적이면서 시각적으로 한눈에 들어오게 만..

[검증 전 확인 및 로직 보강]검증을 하다보니 이런식으로 드라이버 별 구분이 아니라 프로토콜 별 구분으로 되어서 json 출력 로직을 수정하였다. 또한 드라이버 이름 기반으로 먼저 탐지하고 knownProtocolProvider() 함수에 있는 switch-case를 그 다음으로 보는 방법으로 했었는데, 그 두개의 순서를 바꾸어 자기 자신에 대한 프로토콜 제공자를 매칭하는 오탐을 수정하였다. Bug를 사용할지 Defect를 사용할지 고민했었는데, Defect로 결정하게 되어 이것도 수정하였다. (블로그 작성 이후에 수정함) [실행이 안 될 경우 BDS(Boot Device Selection) 페이즈로 넘어가지 못하는 드라이버]CpuDxe (1A1E4886-9517-440E-9FDE-3BE44CEE2136..