CLI 레퍼런스

gori 커맨드라인 레퍼런스입니다. 서브커맨드 없이 gori를 실행하면 TUI가 시작됩니다.

gori [command] [options]

전역 플래그: -v / -V / --version, -h / --help, 그리고 --config PATH(이번 실행에만 쓸 설정 파일, 아래 --config PATH 참고).

gori tui

인터셉트 프록시와 TUI를 시작합니다. 서브커맨드를 주지 않으면 이것이 기본값입니다.

gori
gori tui --listen 0.0.0.0 --port 8080

GORI_HOME은 플래그가 아니라 환경 변수입니다. TUI에서는 프로젝트 피커로 프로젝트를 고릅니다. 바인드 플래그는 이번 실행에 한해 전역 계층만 설정합니다. 설정을 참고하세요. 루트 CA 경로는 gori ca를 사용하세요.

gori run

비대화형 스위트입니다. 각 서브커맨드는 프로젝트 단위로 동작합니다. --project와 --db가 모두 없으면 GORI_PROJECT가 가리키는 프로젝트, project switch로 고정한 프로젝트, 가장 최근에 활성화한 프로젝트 순으로 씁니다. 어느 것을 골랐는지는 stderr에 한 번 알립니다(gori run: using project demo (from GORI_PROJECT)). 셋 중 마지막은 다른 프로젝트에 쓰기가 일어날 때마다 옮겨 가기 때문입니다. 존재하지 않는 프로젝트를 가리키는 GORI_PROJECT나 고정은 건너뛰지 않고 거부합니다. --project와 --db는 택일입니다. 둘 다 주면 --db가 조용히 이기는 게 아니라 사용법 오류로 거절합니다. 실제 사용 패턴은 스크립팅 가이드를 참고하세요.

gori run <subcommand> [verb] [options]

읽기 서브커맨드에 공통인 플래그: --project=NAME, --db=PATH, --format=FMT (보통 text 또는 json), 그리고 --format이 json을 제공하는 모든 명령에서 --format=json과 같은 --json. 모르는 옵션이나 서브커맨드를 주면 가장 가까운 실제 이름(did you mean --format?)과 --help 위치를 한 줄로 stderr에 출력합니다. 전역 플래그는 동사 뒤에 옵니다. gori run rewriter rm 1 --project=x는 되지만 gori run rewriter --project=x rm 1은 조용히 목록만 찍는 대신 사용법 오류로 거부됩니다.

읽기 서브커맨드는 스토어를 읽기 전용으로 열고 캡처 락을 잡지 않으므로, 라이브 TUI가 캡처 중인 프로젝트를 대상으로 실행해도 안전합니다. body: 질의는 검색 인덱스를 비우므로 쓰기입니다. gori 프로젝트가 아닌 --db 파일(다른 도구의 SQLite 데이터베이스나 빈 파일)은 파일에 손대기 전에 거부합니다. 데이터베이스를 만드는 명령(import --db, capture --db)은 빈 파일은 계속 초기화하지만, 다른 도구의 테이블이 든 파일은 거부합니다.

쓰기 서브커맨드는 그 프로젝트의 WAL 데이터베이스를 TUI, MCP와 공유합니다. Store 라이터를 통해 직렬화되므로 TUI가 열려 있어도 실행할 수 있지만, 캡처 커밋이 SQLite 라이터 슬롯을 잠시 차지할 수 있습니다. 짧게 끝나는 서브커맨드는 SQLite 열기/라이터 대기에 1초 예산을 둡니다. 그때까지 슬롯이 바쁘면 필요한 쓰기는 0이 아닌 코드로 종료하며, 다른 gori가 프로젝트를 잠그고 있다고 알리고 해결책(다시 시도하거나 읽기 전용 서브커맨드로 읽기)을 함께 보여 줍니다. 실행 내내 프로젝트를 열어 두는 서브커맨드(discover, fuzz, import, --macro를 준 mine, probe, retest run, oast listen/resume, intercept, sitemap js --scan)는 표준 5초 대기를 그대로 씁니다. repeater 전송도 네트워크 응답을 저장하지 못했다면 성공이라고 하지 않고 실패하므로, 스크립트가 완료된 쓰기와 확인이 필요한 응답을 구분할 수 있습니다.

출력 계약

STDOUT은 데이터를 나릅니다. 경고, 개수, 내보내기 확인 메시지는 STDERR로 가므로 파이프가 깨끗하게 유지됩니다. 읽는 쪽이 파이프를 먼저 닫아도(… | head) 조용히 0으로 끝납니다.

text 출력의 캡처 텍스트는 STDOUT이 터미널이든 아니든 제어 문자와 보이지 않는 문자를 이름으로 보여 줍니다(⟨ESC⟩, ⟨NBSP⟩, ⟨ZWSP⟩, ⟨RLO⟩). 그래서 요청에 든 이스케이프 시퀀스가 터미널을 조작하지 못하고, 숨은 문자도 눈에 보입니다. show와 repeater의 text 뷰는 CRLF를 포함해 줄바꿈을 그대로 유지합니다. --format json은 이런 문자를 있는 그대로 싣고 잘못된 UTF-8만 치환하며, --format raw는 정확한 바이트입니다.

모든 명령에서 --format json은 JSON 문서 하나이고, --format jsonl은 한 줄에 객체 하나입니다.

--fail-if-no-matches 없이 실행하면, 매칭이 없으면서 동시에 모든 전송이 실패한 fuzz는 1로 끝납니다. "결과 없음"과 "대상에 닿지도 못함"이 구분됩니다. 플래그를 주면 3이 우선합니다. 정지 조건이 충족된 실행은 두 규칙 모두에서 빠집니다. 시간 초과된 전송은 매칭되지 않은 오류 행으로 남으면서도 --stop-on 'time:>=5000'을 충족할 수 있고, 그것이 바로 실행이 찾던 결과이기 때문입니다.

생성 명령은 --format json을 받고, 새로 만든 행으로 답합니다. repeater create, issues create, notes create, views add, colormarker add, rewriter add, rewriter extract add, probe rules add, oast providers add, links add, project scope add, project host-override add는 쓰기가 커밋된 뒤 다시 읽어 온 객체 하나를 STDOUT에 출력하며, 그 모양은 같은 계열의 목록이 같은 행에 대해 출력하는 것과 정확히 같습니다. 그래서 스크립트는 문장에서 id를 긁어내는 대신 jq .id로 가져가면 됩니다. id는 그 계열의 다른 명령이 받는 값 그대로입니다. 대부분은 숫자이고, probe 규칙은 규칙 이름(custom_p_7), OAST 프로바이더는 프로바이더 키(p_3)입니다. 뷰는 이름으로 다루므로 id 대신 name과 key를 담습니다. notes create는 텍스트 줄이 가리키는 위치인 index를, links add는 created를 더합니다. created는 이미 링크돼 있던 쌍이면 false이고, 그때는 기존 링크의 id가 담깁니다. 텍스트 출력은 바뀌지 않습니다.

issue=$(gori run issues create --title "IDOR on /v1/users/{id}" --severity high --format json | jq .id)
gori run links add --owner=issue --id="$issue" --ref=flow --ref-id=42 --format json

run capture

gori run capture --port 8070 --format json --for 5m

run shell

OS 설정을 건드리지 않고, 도구들이 실행 중인 gori를 거치며 gori의 CA를 신뢰하는 터미널을 엽니다. 팔레트의 Open browser에 대응하는 터미널 기능입니다.

gori run shell                            # 대화형 $SHELL; `exit`로 나감
gori run shell -- curl https://target/    # 명령 하나를 실행하고 그 종료 코드로 끝남
eval "$(gori run shell --print)"          # 지금 쓰는 셸에 적용할 export 줄
gori run shell --print --shell fish | source

주소는 프로젝트를 캡처 중인 gori에서 가져오고(포트 폴백 뒤에도 실제 포트), CA는 그 gori가 서명에 쓰는 것을 씁니다. 프로젝트를 캡처하는 gori가 없으면 --proxy로 주소를 주지 않는 한 거부합니다. 캡처가 일시정지 상태면 경고하고 진행합니다.

설정되는 것: http_proxy, https_proxy, HTTP_PROXY, HTTPS_PROXY는 gori를 가리키고, 로컬 대상도 캡처되도록 NO_PROXY/no_proxy는 지웁니다. SSL_CERT_FILE, CURL_CA_BUNDLE, REQUESTS_CA_BUNDLE, GIT_SSL_CAINFO, AWS_CA_BUNDLE, PIP_CERT, CARGO_HTTP_CAINFO, DENO_CERT, NIX_SSL_CERT_FILE는 ~/.gori/shell/ 아래 번들을 가리킵니다. 이 변수들 대부분은 도구의 신뢰 저장소에 추가하는 게 아니라 교체하기 때문에, 번들에는 터미널이 원래 신뢰하던 저장소(직접 설정한 SSL_CERT_FILE, 없으면 시스템 루트)와 gori 루트가 함께 들어 있습니다. 특정 도구에만 설정해 둔 CA 변수(예: REQUESTS_CA_BUNDLE)는 공용 번들 대신 그 파일에 gori 루트를 더한 별도 파일을 받습니다. NODE_EXTRA_CA_CERTS는 gori 루트를 추가하고, NODE_USE_ENV_PROXY=1은 Node의 프록시 지원을 켜고, GODEBUG=x509sslcertoverrideplatform=1은 macOS의 Go가 SSL_CERT_FILE을 읽게 합니다. GORI_SHELL=1과 GORI_PROXY=HOST:PORT는 프롬프트에서 쓸 수 있는 표식입니다:

# ~/.zshrc 또는 ~/.bashrc
[ -n "$GORI_SHELL" ] && PS1="(gori) $PS1"

셸이 바꾸거나 지운 값은 GORI_SHELL_ORIG_<NAME>(예: GORI_SHELL_ORIG_HTTPS_PROXY)으로 기록됩니다. 셸 안에서 띄운 gori(gori run send, 두 번째 캡처)는 셸의 프록시 변수를 자기 업스트림으로 쓰지 않으므로, 그 트래픽이 두 번 캡처되지 않습니다. 대신 기록된 프록시와 NO_PROXY를 쓰고, 명시적으로 설정한 업스트림은 그대로 적용됩니다. gori 셸 안에서 다시 연 셸도 기록된 값에서 시작하므로 바깥 gori의 CA를 계속 신뢰하지 않습니다.

다루지 않는 것: 1.27보다 오래된 툴체인으로 빌드한 macOS의 Go 프로그램은 키체인으로 검증합니다. Go는 localhost와 루프백 주소를 절대 프록시하지 않습니다. Node는 NODE_USE_ENV_PROXY를 지원하는 릴리스(v22.21, v24.10에서 stable)에서만 프록시를 씁니다. Java는 JAVA_TOOL_OPTIONS로 truststore가 필요합니다. 자체 신뢰 저장소를 고정한 도구는 다루지 않습니다.

run browser

실행 중인 gori를 거치고 gori의 CA만 신뢰하는 브라우저를 엽니다. 팔레트의 Open browser를 스크립트에서 쓰는 형태입니다. ~/.gori/browser/<id>의 같은 프로필을 쓰고, 브라우저가 끝날 때까지 포그라운드에 머물며, Ctrl-C를 누르면 브라우저를 닫습니다.

gori run browser                                   # 처음 감지된 브라우저
gori run browser --browser brave
gori run browser --remote-debugging-port 9222      # 브라우저 자동화 MCP 서버용

프록시 주소는 run shell과 같은 방식으로 찾고, 프로젝트를 캡처 중인 gori가 없으면 같은 문구로 거부합니다.

--remote-debugging-port를 주면 브라우저가 알려 준 엔드포인트(http://127.0.0.1:N)를 출력합니다. 브라우저 자동화 MCP 서버를 여기에 연결하면 그 서버가 조작하는 페이지가 gori에 캡처됩니다.

npx @playwright/mcp@latest --cdp-endpoint http://127.0.0.1:9222
npx chrome-devtools-mcp@latest --browserUrl http://127.0.0.1:9222

그 프로필이 이미 실행 중인 브라우저에 열려 있으면 실행을 거부합니다. 실행 중인 브라우저는 이를 새 창 요청으로 받아들이고 포트를 열지 않기 때문입니다.

run android

adb로 Android 에뮬레이터나 루팅된 테스트 기기를 실행 중인 gori에 연결합니다. 팔레트의 Set up Android device를 스크립트에서 쓰는 형태입니다. gori는 loopback 바인드를 유지하고, adb reverse가 기기의 127.0.0.1:PORT를 gori로 이어 주며, 기기의 전역 HTTP 프록시가 그 주소로 설정됩니다.

gori run android devices                 # serial, 상태, 모델, api=N,emulator,root (adbd가 root일 때; 목록은 su를 묻지 않음)
gori run android setup --dry-run         # adb 명령만 출력하고 아무것도 바꾸지 않음
gori run android setup --system          # root로 CA를 시스템 저장소에 신뢰 등록
gori run android undo

setup은 run shell과 같은 방식으로 gori를 찾습니다. --user(기본값)는 CA를 /sdcard/Download/gori-ca.crt에 올리고 보안 설정을 엽니다. 거기서 CA 인증서로 설치하세요. API 24 이상을 대상으로 하는 앱은 network security config에서 허용해야만 사용자 CA를 신뢰합니다. --system은 기존 인증서와 gori의 루트(<subject_hash_old>.0)를 담은 tmpfs를 /system/etc/security/cacerts 위에 마운트합니다. root(root로 실행 중인 adbd, 또는 su)로 실행되고, --dry-run에서 모든 명령을 먼저 보여 주며, 기기를 재부팅하면 사라집니다. root가 없으면 --user로 낮추지 않고 거부하며, 시스템 CA를 Conscrypt APEX에서 읽는 Android 14+(API 34)는 지금은 거부합니다.

undo는 http_proxy를 :0으로 되돌리고, reverse 매핑을 지우고(포트는 기기의 프록시 값에서 읽거나 --device-port로 지정), 올린 파일을 삭제하며, root가 있으면 tmpfs를 언마운트합니다. 두 번 실행해도 안전합니다. 직접 설치한 사용자 CA는 설정에서 지울 때까지 남습니다.

다루지 않는 것: 인증서 피닝, 전역 프록시를 무시하는 트래픽.

run history / ls

gori run history -q 'status:5xx' --limit 100 --format json

서브커맨드: history show <id> (run show와 동일), history delete <id>… (id 하나 또는 여러 개를 한 트랜잭션으로. 모르는 id가 하나라도 있으면 호출 전체를 거부), history delete -q QL --yes, history clear --yes.

이 프로젝트의 History 컬럼은 기본으로 함께 그려지므로, 헤드리스 목록도 TUI의 History 탭과 같은 값을 보여 줍니다. 컬럼 없는 기본 목록으로 돌아가려면 --no-columns를 쓰세요. text에서는 행 끝에 label=value로 붙고(빈 값도 포함해서 전부입니다. "이 디스크립터는 여기서 아무것도 못 찾았다"도 봐야 할 답입니다), json에서는 columns 객체로 실립니다(컬럼이 없으면 키 자체가 없습니다). =는 첫 :보다 앞에 올 때만 라벨 구분자이므로 regex:token=(\w+)는 regex:token이라는 컬럼이 아니라 패턴 그대로입니다. 컬럼 하나당 출력되는 행마다 읽기 한 번이 추가되고, 본문을 읽는 세 종류는 본문을 최대 512 KiB까지 읽습니다.

json/jsonl의 각 행은 플로우의 절대 url과 요청 헤더를 담은 headers 객체를 함께 싣습니다 (같은 이름이 반복되면 배열이 됩니다). 본문은 넣지 않습니다. 그건 run show의 몫입니다.

그 객체의 민감한 헤더 값은 기본으로 [REDACTED]로 가려지며, 무엇이든 가려졌으면 행에 sensitive_headers_redacted: true가 붙습니다. 목록은 인벤토리이고, "내가 무엇을 캡처했나"를 확인하려고 한 번 실행한 명령이 살아 있는 세션 쿠키를 터미널 로그나 에이전트 대화 기록에 남겨서는 안 되기 때문입니다. 정확한 바이트가 필요하면 --include-sensitive를 쓰세요. 어느 쪽이든 헤더 이름과 와이어 순서, 반복 횟수는 그대로 남으므로 가려진 행도 그 요청이 무엇이었는지는 여전히 말해 줍니다. obs-fold 이어짐 줄은 별도 헤더로 나오지 않고 원래 필드에 합쳐진 뒤 함께 가려집니다.

같은 규칙이 민감한 헤더를 셀렉터로 지정한 header: 컬럼과 모든 cookie: 컬럼에도 적용됩니다. 이름을 지정한 쿠키의 값은 그 행이 이미 가리고 있는 Cookie 헤더의 일부이기 때문입니다. 반대로 포함되지 않는 것들은 이렇습니다. regex:, jsonpath:, position: 컬럼은 메시지의 어느 바이트에서든 자격 증명을 뽑아낼 수 있고 디스크립터만으로는 그런지 알 수 없어 원리적으로 다룰 수 없습니다. 쿼리 스트링에 담긴 자격 증명은 url과 target의 일부입니다. text 목록은 스크립트가 받아 가는 피드가 아니라 사람이 보는 화면이므로 그대로 둡니다. --format har 역시 교환용 문서로 다시 재생할 수 있어야 하므로 캡처된 메시지를 의도적으로 온전히 담습니다.

각 행에는 source도 실립니다. 이 플로우가 어디서 왔는지(proxy, repeater, fuzzer, discover, import …)이며, 출처를 기록하기 전에 캡처된 플로우는 null입니다. 값이 있을 때 source_surface(tui / cli / mcp)와 source_ref도 함께 나옵니다. text 형식은 평범한 캡처 트래픽이 아닌 행에 [repeater] 같은 칩을 찍습니다. src:로 필터링하며, MCP list_history와 get_flow도 같은 키를 냅니다.

history delete -q QL은 쿼리에 매칭되는 플로우를 전부 삭제하며 --yes가 필요합니다. --yes 없이 실행하면 몇 개가 지워질지 출력하고 거부합니다. QL이 모르는 필드를 쓴 쿼리(methd:)도 조용히 아무것도 지우지 않는 대신 거부합니다. id도 -q도 없으면 거부합니다. 프로젝트를 통째로 비우는 건 history clear --yes입니다.

--format har은 결과 집합 전체를 하나의 HAR 1.2 log로 STDOUT에 씁니다. 오래된 항목이 먼저 오므로, 쿼리 결과를 동료에게 넘기거나 Burp, Charles, 브라우저 네트워크 패널에 그대로 불러올 수 있습니다. HAR 내보내기를 참고하세요.

run show

gori run show <flow-id> --format raw

--format은 text, json, raw(정확한 바이트), har(항목 하나짜리 HAR log), 또는 요청을 코드로 직렬화하는 curl, python(requests), fetch(JavaScript), go(net/http), httpie, csrf(스스로 제출하는 HTML CSRF PoC)입니다. 각각 TUI의 Space → Y **Copy as…**에서 같은 이름의 항목이 복사하는 것과 바이트 단위로 동일한 텍스트를 냅니다. --request-only / --response-only로 출력을 제한하며, har에는 적용되지 않습니다. 요청을 코드로 내는 형식은 모두 요청 그 자체이므로 --response-only는 거부됩니다. 두 가지 주의사항은 STDOUT의 스니펫이 아니라 STDERR로 나갑니다. 캡처 한도에서 잘린 요청 본문은 짧은 채로 실리고, WebSocket 플로우는 업그레이드 핸드셰이크만 직렬화되며 프레임은 담기지 않습니다. 디코드된 SAML/JWT/GraphQL/파라미터, WebSocket 메시지, SSE 이벤트가 있으면 함께 포함됩니다.

--headers-only와 --max-body=BYTES는 text와 json 뷰를 간추립니다. --headers-only는 각 본문을 크기를 알려주는 한 줄로 바꾸고([body omitted by --headers-only: 149504 bytes]; JSON에서는 body 객체가 encoding과 size를 유지한 채 omitted: true를 얻습니다), --max-body는 디코드된 각 본문의 앞쪽 BYTES바이트를 찍은 뒤 [… truncated by --max-body: showing 2048 of 149504 bytes]를 붙입니다(JSON에서는 text/base64가 그 앞부분을 담고, size는 전체 크기, shown_size는 보여준 부분, truncated는 true입니다). 둘 중 하나만 있어도 본문에서 파생되는 섹션(디코드 뷰, gRPC 메시지, WebSocket 프레임, SSE 이벤트)은 빠집니다. 트랜스크립트는 그래도 개수와 함께 이름이 남습니다(=== SSE EVENTS (40) — not printed under --max-body ===, 또는 {"count": 40, "omitted": true}). 이 둘은 전체 메시지를 그대로 쓰는 다른 형식들과 함께 쓸 수 없고, 서로도 함께 쓸 수 없습니다.

--ws-match=QUERY는 트랜스크립트를 싣는 모든 형식에서 매칭되는 WebSocket 메시지만 찍습니다. ws:needle(대소문자 무시), ws~regex, 또는 접두어 없는 needle을 받고, ws: 쿼리 필드와 똑같이 매칭합니다. 소켓의 메시지 중 몇 개를 남겼는지는 STDERR 한 줄로 알려 줍니다.

--original은 Match & Replace 규칙이나 Intercept 편집이 바꾸기 전의 플로우, 곧 클라이언트의 요청과 원본 서버의 응답을 어느 --format으로든 찍습니다. 바뀌지 않은 쪽은 저장된 그대로 나옵니다. 아무것도 바뀌지 않은 플로우는 거부합니다.

안전한 증거 내보내기

--redact [PROFILE]는 캡처한 바이트 대신 플로우의 정제된 파생본을 씁니다. 리댁션 프로파일이 지목한 값이 키가 붙은 자리표시자 [REDACTED:3f1c9ab4]로 바뀝니다. 같은 값은 같은 태그를 받으므로, 읽는 사람은 둘 중 어느 것도 보지 않은 채로 "요청의 토큰이 응답의 토큰과 같다"는 사실만 확인할 수 있습니다. 태그는 값의 해시가 아니라 설치마다 한 번 만들어지는 비밀 키로 계산한 HMAC입니다. 네 자리 PIN이나 워드리스트에 있는 비밀번호의 잘린 해시는 몇 밀리초면 복원되고, 그러면 자리표시자 자체가 유출이 되기 때문입니다.

플로우를 렌더링 전에 한 번만 정제하므로 모든 --format에 적용됩니다. raw, text, json, har, 그리고 요청을 코드로 내는 여섯 형식 전부입니다. --no-redact는 이 프로젝트나 이 설치에서 리댁션이 기본이더라도 캡처한 바이트를 그대로 씁니다. --redact-preview는 무엇이 바뀔지(요청/응답, JSON 포인터 또는 폼 키, 발동한 규칙, 자리표시자)를 나열하고 문서는 출력하지 않습니다.

무엇을 덮고 무엇을 덮지 않는지:

• 본문만 다룹니다. 헤드, URL, 쿼리 스트링은 건드리지 않으며 STDERR의 문장이 매번 그 사실을 말합니다. Cookie 헤더나 ?token= 쿼리 스트링 속 크리덴셜은 소비자(HAR의 url, curl의 인자, 행의 target)가 함께 움직여야 하는 다른 축이고, 프로파일의 대상이 아닙니다.
• 저장된 바이트는 바뀌지 않습니다. History, Repeater, Comparer, get_response_body_chunk는 캡처 그대로를 계속 읽습니다. 정제는 나가는 길에서만 일어나므로, 내보내기 전후의 재전송은 바이트 단위로 동일합니다.
• JSON 본문은 다시 직렬화됩니다. 따라서 정제된 JSON은 원본이 아니라 gori의 공백과 키 순서를 갖습니다. 정확한 프레이밍 자체가 증거라면 --no-redact를 쓰세요.
• 헤드는 정제된 본문을 설명하도록 고쳐집니다. Content-Length가 다시 쓰이고, 읽기 위해 압축을 풀거나 청크를 해제해야 했던 본문은 Content-Encoding / Transfer-Encoding을 잃습니다(STDERR로 알립니다).
• gori가 읽을 수 없는 본문은 통째로 보류됩니다. 일부만 정제하지 않습니다. 유효한 UTF-8이 아닌 본문과 모든 multipart/*가 여기에 해당합니다(gori는 아직 파트를 분해하지 않으므로 업로드된 파일과 폼 필드를 구분할 수 없습니다). 자리표시자가 몇 바이트가 빠졌고 왜 그랬는지 말해 줍니다.
• 파싱되지 않는 본문은 보수적인 텍스트 패스로 물러납니다. 프로파일 자신의 패턴, 필드 이름을 "name": "value" / name=value 텍스트 규칙으로 다시 표현한 것(잘린 값도 허용), 그리고 어디에 나타나든 모호하지 않은 두 가지 내장 형태(JWS/JWE 컴팩트 직렬화와 PEM PRIVATE KEY 블록)입니다.

모든 주의사항과 개수는 STDERR로 나가고 STDOUT은 문서로 남습니다. 그래서 gori run show 42 --format har --redact > evidence.har는 여전히 순수한 HAR입니다.

HAR 내보내기

gori가 쓴 HAR은 다시 gori로 가져와도(gori run import --har) 같은 플로우가 되므로 왕복이 보장됩니다. 네 가지를 알아두세요.

• 본문은 와이어 바이트입니다. chunked만 풀고 압축은 풀지 않으며, 유효한 UTF-8이 아니면 base64로 인코딩합니다. Content-Encoding 헤더가 headers에 그대로 남아 본문과 헤드가 같은 메시지를 가리킵니다.
• 캡처 상한에 잘린 본문은 표시되며, 온전한 것처럼 나가지 않습니다. bodySize와 content.size는 실제 와이어 크기를 유지하고 텍스트에는 캡처된 앞부분만 담기며, content/postData의 comment가 그 사실을 적습니다. 명령은 해당 개수도 STDERR로 보고합니다.
• WebSocket 플로우는 메시지와 함께 내보내집니다. 실제 101 핸드셰이크에 캡처된 전송 기록이 Chrome DevTools의 _webSocketMessages 필드로 나란히 실리며, gori run import --har로 다시 복원됩니다. 방향, opcode(제어 프레임 포함), 바이트(유효한 UTF-8이 아니면 base64), 밀리초 단위 타임스탬프가 유지됩니다. 프레임별 형태(FIN/RSV/마스크 키)는 이 형식에 담을 필드가 없으므로 필요하면 --format json 또는 raw를 쓰세요.
• 응답이 캡처되지 않은 플로우는 건너뜁니다. 전송 기록이 비어 있는 소켓도 마찬가지입니다. 핸드셰이크만으로는 교환이 아니기 때문입니다. 개수와 이유는 STDERR로 나가고 STDOUT은 순수한 HAR 문서로 유지됩니다.

run compare

두 플로우의 줄 단위 diff이며, Comparer 탭과 동일한 결과를 냅니다.

gori run compare 41 42 --pane response --changes-only

diff 위에 양쪽의 status · size · time과 A→B 델타가 출력됩니다. 상태 코드가 뒤집혔는지, 크기가 얼마나 달라졌는지를 첫 줄을 읽기 전에 알 수 있습니다. --format=json에도 같은 값이 meta로 들어가고, 접힌 구간은 빈칸이 아니라 {"kind":"fold","hidden":N} 행이 됩니다.

--changes-only는 무엇이 바뀌었는지는 알려주지만 어디서 바뀌었는지는 지웁니다. 400줄 본문에서 한 줄만 다르면 위치 없는 두 줄만 남습니다. --context는 변경 지점을 제자리에 두고, 건너뛴 양을 함께 적습니다.

run diff

리테스트 리포트입니다. run compare가 메시지 두 개를 비교한다면, 이건 프로젝트 두 개를 엔드포인트 단위로 비교합니다. 실무의 절반을 차지하는 질문, 지난번 대비 뭐가 바뀌었나에 답합니다.

gori run diff --from q1-audit --to q3-retest --format md

아무것도 보내지 않습니다. 양쪽 모두 캡처된 트래픽만 비교합니다. 발견 항목이 아직 재현되는지 확인하려면 요청을 보내야 하고, 그건 Repeater로 직접 하는 선택으로 남습니다.

엔드포인트 동일성

서로 다른 두 점검이 같은 식별자를 캡처하는 일은 없습니다. 따라서 리터럴 경로로 키를 잡으면 모든 행이 removed 한 번 added 한 번으로 두 번 보고되고, 결국 아무 말도 하지 못합니다. 그래서 Sitemap이 그리는 폴딩 템플릿을 그대로 키로 씁니다: /users/{uuid}, /items/{n}, /search(쿼리 변형은 경로로 접힘). 폴딩은 양쪽의 합집합에 대해 한 번만 돌기 때문에, 한쪽에서만 폴딩 임계치를 넘긴 라우트도 반대쪽과 서로 매칭됩니다.

다섯 가지 판정

removed/gone 구분이 이 명령의 핵심입니다. 리테스트가 얕으면 방문한 엔드포인트도 적어지는데, 이 둘을 한 바구니에 넣으면 짧은 오후 작업이 대규모 수정처럼 보고됩니다. 모든 출력이 그 단서를 맨 앞에 두고, --verdict로 목록을 좁혀도 개수는 항상 다섯 판정 전부를 덮습니다.

changed 판정은 바이트 동일성이 아니라 허용 밴드로 내립니다. repeater minimize와 mine이 쓰는 바로 그 캘리브레이션입니다. 그래서 캡처 사이에 길이가 흔들리는 페이지는 unchanged로 읽힙니다. 상태 코드는 클래스로 비교합니다. 200이 201이 된 건 리테스트 발견이 아니지만 200이 403이 된 건 발견이고, 그건 별도의 auth 축으로 보고됩니다.

이슈 리테스트

리포트 끝에는 기준 프로젝트에서 아직 열려 있는 이슈들과, 그 이슈가 걸려 있던 엔드포인트가 어떻게 됐는지가 붙습니다: "여전히 같은 방식으로 응답함, 발견 항목이 아직 유효할 가능성이 높음", "이제 404/410으로 응답함", "새 캡처에서 요청된 적 없음, 닫기 전에 리테스트할 것". 요청은 보내지 않습니다. 수정 확인은 사용자의 판단입니다.

커버리지와 스코프

개수 위에 양쪽의 플로우 수, 엔드포인트 수, 호스트 수, 캡처 기간이 함께 출력됩니다. B의 커버리지가 A보다 얇으면 바로 보입니다. 두 프로젝트의 스코프 규칙이 다르면 그 사실도 적습니다. 그쪽 프록시가 애초에 기록하지 않아서 엔드포인트가 없는 것일 수 있으니까요.

run intercept

캡처 락을 쥔 TUI의 라이브 인터셉트 큐를 조작합니다. 인터셉트는 TUI 전용입니다. 헤드리스 gori run capture는 메시지를 붙잡지 않으며, list를 뺀 서브커맨드는 상태를 게시하는 캡처 인스턴스가 없으면 거부합니다(list는 STDERR로 알리거나 --format json에서 {"available": false, …}를 내고 0으로 끝납니다).

gori run intercept                              # 붙잡힌 항목 + 인터셉트 상태
gori run intercept get 3 --format json
gori run intercept forward 3
gori run intercept edit 3 --raw-file edited.txt
gori run intercept direction request
gori run intercept inject 42 --direction in --data '{"role":"admin"}'

list와 get은 --include-sensitive를 주지 않으면 민감한 헤더 값을 가립니다. 쓰기 서브커맨드는 프로젝트 데이터베이스를 거쳐 TUI의 ack를 폴링합니다.

run repeater

캡처한 플로우 하나를 재전송하거나, TUI와 공유되는 Repeater 워크벤치 세션을 관리합니다.

gori run repeater <flow-id> --target https://staging.example.com --http2 --diff

--headers-only와 --max-body는 출력되는 것만 바꿀 뿐, 무엇이 전송되거나 저장되는지는 절대 바꾸지 않습니다. 본문은 [body omitted by --headers-only: 149504 bytes]로 대체되거나, 잘린 뒤 [… truncated by --max-body: showing 2048 of 149504 bytes]가 뒤따르므로, 잘린 본문이 짧은 본문처럼 읽히는 일은 없습니다. 크기는 디코드된 본문의 크기(청크 해제, 압축 해제 후)이며, 자르지 않은 덤프가 찍는 것과 같은 값입니다. --format json에서는 body 객체가 size로 전체 디코드 크기를 유지합니다. --max-body는 text/base64에 그 앞부분을 담고 shown_size를 더하며 truncated: true를, --headers-only는 바이트를 빼고 omitted: true를 더합니다. 두 플래그는 함께 쓸 수 없습니다. --headers-only --diff는 두 헤드만 비교하고, --max-body는 --diff와 함께 쓸 수 없습니다. --diff의 비교 대상은 메시지 전체이기 때문입니다. 이 둘은 repeater send, repeater h2, send, show에서 같은 형태로 동작합니다.

repeater list: 저장된 Repeater 세션 목록 (--format text|json).

repeater create: Repeater 세션 생성:

gori run repeater create --target https://api.example.com --request-file req.txt --name "login probe"
gori run repeater create --flow 42 --name "clone of 42"
generate-request | gori run repeater create --target https://api.example.com --request-stdin
pbpaste | gori run repeater create --curl - --name "from devtools"

네 가지 요청 소스는 함께 쓸 수 없습니다. 두 개를 지정하면 플래그 순서로 하나를 고르는 대신 거부됩니다. 또한 빈 요청(빈 파일, --request-raw '', 아무것도 내보내지 않은 파이프)은 전송할 수 없는 세션을 만드는 대신 거부됩니다. --flow는 이 넷에 속하지 않습니다. 출처 역할도 하므로 넷 중 어느 하나와도 함께 쓸 수 있습니다. --curl은 curl 명령 하나를 읽고 (Repeater → Paste cURL 참고), 따로 주지 않으면 --target과 --http2도 그 명령에서 가져옵니다.

--request-stdin은 파이프나 리다이렉트(--request-stdin < req.http)를 읽으며, 터미널은 거부합니다. 터미널은 입력한 바이트를 그대로 되돌려 출력하므로, Cookie와 Authorization을 포함한 원시 요청 전체가 스크롤백에, 그리고 PTY로 캡처한 로그에 남습니다. 이는 이 플래그가 프로세스 목록과 셸 히스토리에서 막으려던 바로 그 노출입니다. 또한 ^D는 EOF가 아니라 대기 중인 줄을 내보내기만 하므로, 끝에 개행이 없는 요청은 ^D가 두 번 필요하고 한 번만 보내는 PTY 자동화는 무한히 대기합니다.

같은 규칙은 플래그로 지정한 모든 stdin 경로에 적용됩니다. issues --notes-stdin, 그리고 stdin을 -로 쓰는 네 가지(sequence --tokens -, authorize --identities=-, rewriter --response-file=-, 그리고 --…-file 계열 플래그의 -)가 그렇고, 터미널로 해석되는 경로(tty에서의 --request-file /dev/stdin 등)까지 포함됩니다. 워드리스트 경로도 포함됩니다. fuzz -w, mine --wordlist, discover --wordlist는 /dev/tty(그리고 tty 상태의 /dev/stdin)를 무한 대기 대신 wordlist is a terminal, not a file: …로 거부합니다.

반대로 플래그 없이 gori가 fallback으로 읽는 stdin 경로(fuzz, mine, sequence, decoder, jwt, cookie, notes)는 해당하지 않습니다. 거기서 터미널은 "소스를 주지 않았다"는 뜻이고, 각 명령이 자체 usage를 출력합니다. 다만 이 경로들도 이제 읽을 수 없는 stdin(cron/systemd가 fd 0을 닫은 경우)을 backtrace가 아니라 한 문장으로 보고합니다. 플래그로 지정한 경로는 이미 그렇게 해 왔습니다.

id=$(gori run repeater create -t https://api.example.com -f req.http --format json | jq .id)
gori run repeater send "$id"

repeater send <repeater-id>: 저장된 세션을 실행합니다. HTTP와 WebSocket 모두 해당됩니다.

gori run repeater send 3 --diff
gori run repeater send 5 --message '{"op":"subscribe"}' --idle-ms 5000

--path는 경로만 다른 엔드포인트들에 걸쳐 세션 하나의 요청을 스윕합니다. 경로마다 세션을 만들 필요가 없습니다.

for n in $(seq 1 38); do
  gori run repeater send 1 --path "/api/v1/items/$n" --headers-only
done

이 옵션은 이번 전송을 위해 저장된 요청의 사본을 고칩니다(-H와 -b도 마찬가지입니다). 세션은 자신의 요청과 마지막 응답을 그대로 유지합니다. 다른 대상의 응답을 그 옆에 저장하면 TUI 탭이 자신이 가지고 있지 않은 요청에 대한 응답을 보여주게 되고, 다음 --diff가 엉뚱한 엔드포인트와 비교하게 되기 때문입니다. 그래서 --format json에는 response_saved가 빠지고, path 필드에 전송된 대상이 담기며, text 상태 줄은 그 값으로 끝납니다(→ 200 in 218.4ms · /api/v1/items/42). --record-history는 실제로 나간 대로(새 경로 포함) 요청을 여전히 기록하며, --diff는 세션에 저장된 응답과 계속 비교합니다.

오리진에 닿은 전송은 그 뒤의 쓰기가 실패해도 0으로 종료하므로, 셸이 같은 요청을 다시 보내지 않습니다. 어느 쓰기가 실패했는지는 --format json이 알려 줍니다. response_saved(세션에 응답을 썼으면 나타나고, 프로젝트가 쓰기를 거부했거나 전송 중에 세션이 삭제됐으면 false와 함께 response_save_error가 붙습니다. 이때 다음 --diff는 이전 응답과 비교합니다)와, --record-history를 주었다면 history_saved가 나오며, 실패하면 history_error가 붙고 recorded_flow_id는 빠집니다. 텍스트 모드는 같은 문장을 STDERR에 찍습니다.

repeater ws <repeater-id>: 저장된 repeater로 지속 HTTP/1.1 WebSocket 세션을 엽니다(TUI의 Live session 및 MCP의 ws_session_open / ws_session_send / get_job / stop_job에 대응하는 gori run 표면). stdin에서 읽은 각 줄은 TEXT 메시지로 프레이밍해 보내고(--binary를 주면 헥스로 디코드한 BINARY 메시지), 보낸 프레임과 받은 프레임 모두 도착하는 즉시 stdout에 찍습니다. stdin EOF(--for가 없을 때), --for=DURATION, 또는 Ctrl-C가 오면 CLOSE 프레임을 보내고 깨끗하게 종료합니다. Windows에서는 파이프로 연결한 stdin 읽기가 블로킹되므로 서버 프레임은 다음 줄이 들어올 때 찍힙니다(콘솔 stdin은 괜찮습니다).

printf '{"op":"ping"}\n' | gori run repeater ws 5 --engine-io --for 30s
gori run repeater ws 5 --for 30s --format json

repeater move <repeater-id>: 워크벤치 스트립의 순서를 바꿉니다. --to N은 repeater list가 출력하는 1부터 시작하는 탭 번호이고, --up / --down은 한 칸씩 옮깁니다. 셋 중 하나만 주세요. --to와 방향을 함께 주면 임의로 해석하지 않고 거절하며, 1-<개수> 범위를 벗어난 --to도 잘라 맞추지 않고 거절합니다. 명령이 지목하지 않은 자리에 세션이 놓이는 일이 없도록 하기 위해서입니다. --format json은 from_index / to_index / moved를 보고합니다.

gori run repeater move 5 --to 1        # 첫 번째 탭으로
gori run repeater move 5 --down

repeater delete <repeater-id> [<repeater-id>…] --yes: 저장된 세션 하나 이상을 닫고 스트립의 번호를 다시 매깁니다. --yes는 필수이며, 첫 삭제 전에 모든 id를 검사합니다. 하나라도 모르는 id가 있으면 호출 전체를 거절하므로, 오타 하나로 워크벤치가 절반만 비는 일은 없습니다. 각 줄은 그 세션이 가지고 있던 탭 번호를 말합니다(무엇이든 밀려나기 전에 한 번만 읽습니다). --format json은 deleted(was_tui_index 포함), failed, remaining을 반환합니다. 지우지 못한 세션이 있으면 종료 코드가 0이 아닙니다.

repeater race <repeater-id> <repeater-id> [<repeater-id>…]: 저장된 세션 여러 개를 하나의 동기화된 레이스로 발사해, 서로 다른 N개의 요청이 좁은 한 순간에 서버에 닿게 합니다(서로 다른 엔드포인트에 걸친 TOCTOU). HTTP/1.1에서는 요청마다 연결을 따로 열고 모든 요청의 마지막 바이트를 함께 풀어 주며, HTTP/2에서는 한 연결을 공유하는 single-packet 공격으로 보냅니다. 모든 세션은 하나의 오리진으로 해소되고 같은 전송을 써야 하며, 아니면 레이스를 거부합니다. --http2 / --http1은 세션에 저장된 설정을 덮어쓰고, --max-requests=N은 N보다 큰 묶음을 나누지 않고 거부합니다. --verbatim, --slot=NAME, --reframe-grpc, --tls-preset=NAME, -k, --timeout, --allow-unscoped, --format text|json은 repeater send와 같습니다. 요청 하나의 복사본 여러 개로 레이스하려면 fuzz --race=N을 쓰세요.

gori run repeater race 3 4 --http2

repeater timing <idA> <idB>: 정확히 두 개의 저장된 세션을 차등 타이밍으로 분석합니다. 한 번 보내서는 보이지 않을 만큼 작은 차이를 위한 것입니다. 버리는 --warmup=N쌍(기본 3, 0이면 첫 쌍부터 측정)을 보낸 뒤 이 쌍을 --count=N번(1-500, 기본 30) 보냅니다. 각 쌍은 repeater race처럼 함께 풀어 주거나(HTTP/2 single-packet, HTTP/1.1 last-byte sync), --interleaved를 주면 순서를 번갈아 가며 하나씩 차례로 보냅니다. 판정은 지연 시간 한 번이 아니라 응답 순서에서 나옵니다. A가 B보다 늦게 도착한 쌍이 몇 개인지를 양측 부호 검정으로 봅니다. p < 0.01일 때만 a_slower나 b_slower이고, 그렇지 않으면 no_difference, 쓸 수 있는 쌍이 20개 미만이면 inconclusive입니다(어느 한쪽이라도 실패한 쌍은 버립니다). 변형마다 최솟값, 사분위수, 최댓값이 함께 찍힙니다. 두 세션은 하나의 오리진과 연결 모양을 공유해야 하며, HTTP/1.1과 HTTP/2가 섞인 쌍에는 --http1이나 --http2가 필요합니다. --verbatim, --slot=NAME, --reframe-grpc, --tls-preset=NAME, -k, --timeout, --allow-unscoped, --format text|json은 repeater send와 같고, JSON은 MCP timing_requests가 돌려주는 객체와 같습니다. 쓸 수 있는 쌍이 하나도 없으면 1로 끝납니다.

gori run repeater timing 3 4 --count 100

repeater minimize <repeater-id>: 응답이 그대로 재현되는 최소 형태까지 요청을 줄입니다. --apply는 결과를 세션에 다시 씁니다. --verbatim은 저장된 바이트를 그대로 보내며, 이때 본문 파라미터는 프레이밍을 정직하게 유지할 수 없어 후보에서 빠집니다. --slot=NAME은 그 세션 슬롯으로 보냅니다. -k/--insecure, --allow-unscoped, --format은 위와 같습니다.

repeater h2: 순서가 있는 HPACK 필드 목록으로 필드 단위 HTTP/2 요청을 보냅니다. 중복되거나 순서가 뒤바뀐 의사 헤더를 스크립트로 만들 수 있습니다.

gori run repeater h2 --target https://api.example.com --fields fields.json

--fields=FILE은 [[name, value], …] 배열이거나 {"fields": [[name, value], …], "body": "…"} 형태의 JSON 파일입니다(바이너리는 body_base64). 목록의 어떤 것도 정규화하지 않습니다. 앞의 콜론, 앞 공백이 붙은 값, 대문자 이름이 곧 페이로드입니다. --target은 접속할 오리진을 정하므로, :authority와 :scheme 필드는 의도적으로 그와 어긋나게 둘 수 있습니다. -k/--insecure-upstream, --timeout=SEC, --sse-events/--sse-time, --allow-unscoped, --tls-preset=NAME, --headers-only, --max-body, --format text|json은 repeater send와 같습니다.

run send

요청 하나를 보내고 응답을 출력합니다. 같은 코드로 만들어진 MCP send_request{url}의 헤드리스 형태입니다. 다른 모든 gori 전송과 마찬가지로 프로젝트의 업스트림 프록시, 호스트 오버라이드, 스코프, 샌드박스를 거쳐 나가며, --record-history나 --save-as-repeater를 주지 않으면 아무것도 남기지 않습니다.

gori run send https://api.example.com/v1/items/42 -H 'Accept: application/json' -b 'sid=abc'
gori run send --url https://api.example.com/v1/items -d '{"name":"x"}' -H 'Content-Type: application/json' --record-history
gori run send --url https://api.example.com --request-file req.http --headers-only

-X, -H, -d, -b는 curl에서와 같은 뜻입니다. -d는 본문이며(-X나 -H가 달리 정하지 않으면 요청을 폼 Content-Type의 POST로 만듭니다), -b는 쿠키입니다. #1383 전까지는 여기서 -b가 본문이었으므로, =가 없는 -b 값(예전의 -b '{"a":1}')은 거부하고 -d를 쓰라고 안내합니다.

종료 코드는 HTTP 판정이 아니라 교환 성공 여부를 알립니다. 404나 500도 0으로 끝나므로(JSON에서는 ok: true) status를 확인하세요. 1(ok: false)은 응답이 없었거나 gori가 응답을 프레이밍하거나 끝까지 읽지 못했다는 뜻입니다.

WebSocket 핸드셰이크인 요청은 평범한 요청으로 나가고 그 101이 응답이 되며, 명령은 이를 STDERR에 알립니다. 프레임을 주고받는 교환에는 세션이 필요합니다: repeater create 다음 repeater send를 쓰세요.

send, repeater <flow-id>, repeater send의 --format json은 원시 head 옆에 MCP send_request의 오류 계약을 싣습니다. 실패한 전송에는 error_kind(connect, timeout, protocol, no_response, truncated_request, budget, busy, other), error_code, retryable, delivered가 붙으므로, 스크립트는 error 문장을 매칭하지 않고도 거부된 연결과 타임아웃을 구분할 수 있습니다. 응답에는 reason, http_version, 파싱된 headers([{"name","value"}], 와이어 순서, UTF-8이 아닌 값에는 value_lossy/value_base64)가 붙습니다. match_replace_applied: true는 --apply-rules가 요청을 바꿨다는 뜻이고, bounded(events 또는 time)는 이벤트 스트림이 --sse-events / --sse-time 한도에서 멈췄다는 뜻입니다.

run fuzz

소스: --flow=ID, --repeater=ID, --request=FILE, 또는 stdin. 위치: §…§ 마커, --auto, --mark=TOKEN, 또는 스키마가 아는 gRPC 필드용 --field=SPEC.

영구 퍼즈 실행

gori run fuzz …는 일회성입니다. 같은 소스/옵션 앞에 save 동사를 붙이면 모든 결과를(완성된 렌더링 요청, 최종 와이어 요청, 응답 헤드, 응답 본문까지) 영구 저장합니다:

gori run fuzz save 42 --auto --preset sqli
gori run fuzz save --request request.txt --target https://api.example.com --project acme --payloads a,b

파일/stdin에서 저장할 때는 --project나 --db가 필요합니다. 프로젝트를 지정하지 않은 스윕을 가장 최근 프로젝트에 조용히 써넣지 않기 때문입니다. --record-history는 이와 별개로 남습니다. 저장된 결과 집합이 아니라 History 플로우를 제어합니다.

run mine

gori run mine <flow-id> --locations query,headers --wordlist params.txt

기본적으로 연결을 재사용합니다. 마이닝 한 번이 프로브마다가 아니라 워커마다 TCP(https라면 TLS) 핸드셰이크를 한 번씩만 치릅니다. 실행이 끝날 때 나오는 connections · N dialed · M reused 줄에서 대상이 이를 지켰는지 확인할 수 있습니다. 대상이 연결 단위로 동작한다면 --no-keep-alive로 끕니다.

run sequence

토큰의 무작위성을 평가합니다. 라이브: 요청을 리플레이하며 각 응답에서 토큰을 추출합니다. 수동: --tokens로 붙여넣은 목록을 분석합니다(네트워크 없음). 별칭 seq.

gori run sequence 42 --cookie SESSIONID --count 500
gori run sequence --tokens tokens.txt          # '-'는 stdin을 읽음

run authorize

선택한 플로우를 아이덴티티마다 재전송합니다. 아이덴티티는 관리자 세션, 저권한 사용자, 익명 클라이언트를 대신하는 헤더 오버레이이며, 각 응답을 기준선과 비교합니다. 기준선이 받은 것을 그대로 받는 아이덴티티가 있다면 접근 제어 우회일 가능성이 높습니다. Authorize 탭의 헤드리스 버전입니다.

gori run authorize 12 13
gori run authorize --query 'host:acme.test method:GET' --identities identities.json

--identities로 파일을 지정하지 않으면 아이덴티티는 프로젝트, 즉 TUI Authorize 탭의 목록에서 옵니다.

[{"name": "anonymous", "remove": ["Cookie", "Authorization"]},
 {"name": "low-priv",  "set": [{"name": "Cookie", "value": "session=…"}]}]

set은 헤더를 upsert하고 remove는 제거합니다. 어떤 항목도 "baseline": true를 갖지 않으면 캡처된 그대로의 요청이 기준선입니다. 기준선 외에 최소 한 개의 아이덴티티가 필요하며, 그렇지 않으면 비교할 것이 없습니다.

의미 있게 재전송할 수 없는 플로우는 아무것도 보내기 전에 이유와 함께 STDERR에 나열됩니다(no identity changes them, not a safe method to repeat, never completed, answered by gori, outside project scope, already queued). 선택한 플로우가 전부 건너뛰어지면 실행하지 않고 거부합니다. 모든 전송이 소켓을 열기 전에 거부되면 깨끗한 결과를 보고하는 대신 1로 종료하며 그 사실을 말합니다. 아무것도 보내지 않은 실행은 접근 제어가 동작한다는 증거가 아니기 때문입니다.

run cache-deception

선택한 각 플로우를 웹 캐시 디셉션으로 검사합니다: 캡처된(인증된) 아이덴티티로 재전송해 캐시를 채우고, 세션 없이 같은 url을 다시 요청한 뒤 고유한 캐시 무효화 쿼리 매개변수를 붙여 익명 제어 요청을 보냅니다. 제어 응답이 일치하고 캐시 히트 신호가 없을 때 공개 콘텐츠(served)로 봅니다. 제어 응답도 캐시 히트라면 쿼리가 무시됐을 수 있으므로 판정은 review이며, 익명 응답이 캐시 히트를 보이고 제어 응답은 다르면 디셉션 가능성(cached)이 있습니다. 플로우 하나당 최대 세 번 요청합니다. Authorize 엔진을 차용하며, 이를 유발하는 조작된 경로(;, .css, %00, dot-segment)는 Fuzzer의 cache-delimiters 페이로드 세트입니다.

gori run cache-deception 12
gori run cache-deception --flow 12 --flow 13 --format json

플로우마다 판정 하나를 보고합니다: cached(디셉션: 익명이 인증된 응답을 캐시에서 받았고 캐시 무효화 제어 응답은 다름), served(캐시 히트 증거가 없거나 캐시 히트가 없는 제어 응답과 일치), review(비슷하지만 동일하지 않거나 제어 결과가 불분명하거나, 일치한 제어 응답도 캐시 히트임), protected(익명이 다른 응답을 받음), blocked(gori가 전송 거부), errored. 각 시도의 cache는 해당 응답의 캐시 상태이며 최상위 cache는 익명 응답 상태입니다. --unsafe-methods 없이는 안전한 메서드(GET/HEAD/OPTIONS)만 검사합니다. 재전송할 수 없는 플로우는 STDERR로 알리고 다음 플로우로 넘어가며, 검사한 플로우가 하나도 없으면 1로 끝납니다.

run session

프로젝트의 세션 슬롯입니다. 이름 붙은 신원 각각이 헤더 오버레이 하나와, 그 값을 묶어 주는 extract 규칙들로 이루어집니다. TUI Authorize 탭의 identities 카드가 편집하고 MCP의 *_session_slot 도구가 관리하는 바로 그 목록입니다. Authorize 실행은 모든 슬롯으로 재생하고, 전송은 --slot이 지목한 하나로 나갑니다.

gori run session                                     # 목록 (값은 [REDACTED])
gori run session show admin --show-values
gori run session add --name admin --set 'Cookie: session=…' --rule SESSION
gori run session edit admin --clear-set --set 'Cookie: session=new'
gori run session baseline as-captured
gori run session rm admin
gori run session edit admin --refresh 12,14 --refresh-before jwt-exp
gori run session refresh admin

모든 동사가 --project=NAME / --db=PATH를 받습니다.

--set 값은 TUI 폼과 같은 헤더 파서를 지납니다. 이름은 RFC 7230 토큰이어야 하고 값에 CR이나 LF가 들어갈 수 없으며, 통과하지 못한 줄은 버려지지 않고 지목되어 거부됩니다.

from-flow는 캡처된 로그인에서 슬롯을 만듭니다. 로그인한 플로우를 지목하면 gori가 그 플로우의 응답을 읽어 오버레이를 채웁니다. 모든 Set-Cookie의 name=value를 Cookie: 헤더 하나로 접고(속성은 버리며, 응답이 삭제하는 쿠키는 건너뜁니다), 이어서 응답 자신의 Authorization을, 없으면 JSON 본문 최상위의 access_token / token / id_token 문자열을 Authorization: Bearer <value>로, 그것도 없으면 요청 자신의 Authorization을 씁니다.

gori run session from-flow 4211 --name admin
gori run repeater 900 --slot admin        # 플로우 900을 그 신원으로 재전송

오버레이는 리터럴입니다. 로그인이 돌려준 바이트 그대로 프로젝트에 저장됩니다. 스스로 재인증하지는 않으므로, 회전하는 토큰(수명 짧은 JWT, 요청마다 바뀌는 CSRF 값)은 extract 규칙 경로가 맞습니다: gori run rewriter extract에 --bind-from FLOW를 더하면 실행마다 값을 새로 발급받습니다. 슬롯에 갱신 단계를 붙이는 방법도 있고, 요청마다 바뀌는 값이라면 Fuzzer나 Miner의 요청 시점 매크로(--macro)를 쓰세요. 이름은 플로우를 읽기 전에 검사하므로, 중복된 이름은 "그 플로우는 로그인이 아니다"가 아니라 이름 충돌로 보고됩니다.

from-request는 캡처된 요청에서 지정한 헤더를 복사합니다. 인증 정보나 CSRF 값이 요청에 이미 있거나, 로그인 교환의 모든 헤더가 아닌 필요한 헤더만 의도적으로 스냅샷할 때 유용합니다. --copy-header를 헤더마다 반복하고, 하나 이상 지정해야 합니다. Content-Length, Transfer-Encoding, Host는 거부됩니다. 슬롯은 본문과 대상이 다른 메시지에 적용되므로, 이 헤더를 복사하면 이후 모든 전송의 프레이밍이나 라우팅이 어긋납니다. 저장되는 값은 리터럴 바이트이며, --show-values를 주지 않으면 표준 출력은 [REDACTED]로 가립니다. STDERR의 provenance는 복사한 헤더 이름만 출력하고 값은 출력하지 않습니다. 슬롯은 호스트 범위가 없습니다. --slot NAME을 명시한 모든 전송에 해당 슬롯의 헤더가 적용되므로, 슬롯은 의도한 신원 하나에만 사용하세요.

gori run session from-request 4211 --name admin \
  --copy-header Cookie --copy-header X-CSRF-Token
gori run repeater 900 --slot admin        # 해당 헤더 스냅샷으로 전송

이는 로그인 매크로가 아닌 리터럴 스냅샷입니다. 스스로 재인증하거나 회전하는 토큰을 갱신하지 않습니다. 수명이 짧은 JWT, 요청마다 바뀌는 CSRF 값처럼 다시 발급해야 하는 값은 gori run rewriter extract와 --bind-from FLOW를 사용해 실행마다 새로 추출하거나, 슬롯에 갱신 단계를 붙이세요. 요청마다 바뀌는 값이라면 Fuzzer나 Miner의 요청 시점 매크로(--macro)를 쓰세요.

갱신 단계는 슬롯을 다시 인증합니다. --refresh 12,14는 로그인하는 Repeater 세션(gori run repeater list)을 실행 순서대로 지정합니다. 보통 CSRF를 가져오는 요청, 그다음 $BIND.CSRF를 싣는 로그인 요청입니다. 각 단계의 응답은 슬롯 자신의 extract 규칙을 거치고, 그것이 슬롯을 다시 바인딩합니다. 단계는 그 슬롯의 $BIND.NAME 값을 해소하고 슬롯 헤더 오버레이는 싣지 않으므로, 로그인 요청이 교체하려는 만료된 자격 증명을 보내지 않습니다. 모든 단계는 source refresh(src:refresh)로 History에 기록되고, 갱신마다 이벤트 하나(list_events, source session)가 남습니다. 이벤트에는 바인딩 이름만 있고 값은 없습니다.

--refresh-before를 주면 슬롯으로 나가는 전송(모든 전송 명령의 --slot NAME, 그리고 Authorize 실행의 각 신원) 직전에 갱신이 스스로 실행됩니다.

정책이 있고 아직 아무것도 바인딩되지 않은 슬롯은 첫 전송 전에 갱신합니다. 401을 받은 뒤 요청을 재시도하지는 않습니다. 정책은 전송 전에만 동작하고 응답을 읽지 않으므로, 로그인이 Authorize 판정을 가리지 않습니다. 자동 갱신이 실패하면 전송은 가진 값으로 그대로 나가고, 30초 동안 다시 시도하지 않으며, 3번 연속 실패하면 수동 갱신이 성공할 때까지 자동 갱신이 꺼집니다. 동시에 들어온 전송은 진행 중인 갱신 하나를 기다립니다. 자동 갱신은 gori run이 여느 전송을 제한하듯 프로젝트 스코프로 제한되며 명령의 --allow-unscoped를 물려받지 않습니다. 로그인 호스트가 스코프 안에 있어야 합니다. 명령에 -k를 주면 그 전송처럼 갱신 단계도 업스트림 TLS 검증을 건너뜁니다.

슬롯이 단계로 쓰는 Repeater 세션을 삭제하면 그 단계는 제자리에 삭제됨으로 표시되어 남고, 갱신은 그 id를 다음에 차지한 세션을 실행하는 대신 그 단계를 거부합니다. --refresh나 --clear-refresh로 제거하세요.

바인딩 값은 메모리에, 프로세스마다 따로 있습니다. session refresh는 이 명령 자신의 테이블을 다시 바인딩하고 명령이 끝나면 사라지므로, 로그인 순서가 동작하는지 확인하는 용도입니다. --slot NAME 스윕은 자기 프로세스에서 갱신하고, TUI와 실행 중인 gori mcp는 각자의 테이블을 가집니다.

session activate는 없습니다. gori run 프로세스는 보내고 끝나므로 활성 포인터가 걸칠 시간이 없고, 저장해 두면 다음 실행에서 비어 있는 바인딩 테이블로 해소되어 $BIND.SESSION이 리터럴인 오버레이를 보내게 됩니다. 대신 전송할 때 신원을 지목하세요: send, repeater, repeater send, repeater race, repeater timing, repeater minimize, fuzz, mine, sequence, discover, retest run에서 --slot NAME. 실행은 첫 요청 전에 STDERR로 slot: sending as NAME을 찍습니다.

run probe

gori run probe --severity high --category cors
gori run probe -a

--severity는 info|low|medium|high|critical 중 하나입니다. --fail-on=LEVEL은 스캔이 보고하는 이슈(--severity/--category/--in-scope 적용 후)가 LEVEL 이상이면 3으로 종료하게 하므로, CI 잡의 게이트로 쓸 수 있습니다. --category는 headers|cookies|tech|infoleak|cors|client|active|custom입니다. -a/--active는 가벼운 액티브 검사도 포함합니다. -q/--query로 QL 필터를 겁니다. --lenient는 없는 필드 이름을 쓴 쿼리를 거절하지 않고 받아들입니다. --in-scope는 프로젝트 스코프 안의 호스트에 대한 이슈만 보고합니다. TUI의 s 렌즈로, --active/--allow-unscoped와 무관하게 옵트인이며 모든 플로우는 여전히 스캔됩니다.

--active와 함께: --unsafe는 안전하지 않은 메서드(POST/PUT/PATCH/DELETE)도 프로브하며, 이 재전송은 서버 데이터를 변경할 수 있습니다. --aggressive는 룰별 상한을 높이고 forbidden-bypass 헤더 집합을 넓힙니다(그리고 --unsafe를 함의합니다). 둘 다 --allow-unscoped를 함께 주지 않는 한 스코프 게이트를 따릅니다. -k/--insecure-upstream은 액티브 재전송의 업스트림 TLS 검증을 생략합니다. 인가된 대상에만 사용하세요.

probe만 쓰면 스캔하고 출력합니다. --persist를 주면 찾은 결과를 라이브 스캐너와 같은 방식으로 합쳐 저장된 발견 항목에도 기록하므로, TUI로 연 적 없는 프로젝트에도 판정 목록이 생깁니다. 기록이 실패하면 보고서를 출력한 뒤 그렇다고 알리고 1로 종료합니다. TUI Probe 탭 뒤에 저장되는 발견 항목은 별개의 표면입니다.

gori run probe issues --severity high            # 아래 동사들이 받는 id가 함께 나오는 트리아지 목록
gori run probe promote 12                        # 하나를 Issue로 확정
gori run probe dismiss --code missing_hsts       # 발견 코드나 --host로 일괄 무시
gori run probe delete --all --yes
gori run probe rules --kind active               # 스캔 룰 목록과 무장 여부
gori run probe rules enable <rule-id>            # id는 `probe rules`나 Probe 룰 레퍼런스에서
gori run probe mode passive                      # off | passive | active | aggressive

run discover

대상을 스파이더링하고 링크되지 않은 경로를 브루트포스합니다. --no-store가 아니면 결과는 Sitemap으로 반영됩니다. 대상이 청하지 않은 실제 트래픽을 보내므로 인가된 대상에만 실행하세요.

gori run discover --target https://target.example --max-depth 3 --extensions php,json,bak --format jsonl

기본적으로 origin별로 연결을 재사용합니다. 브루트포스 한 번이 프로브마다가 아니라 워커마다 TCP(https라면 TLS) 핸드셰이크를 한 번씩만 치릅니다. 실행이 끝날 때 나오는 connections · N dialed · M reused 줄에서 대상이 이를 지켰는지 확인할 수 있습니다. 대상이 연결 단위로 동작한다면 --no-keep-alive로 끕니다.

run wordlist

전역 wordlist 카탈로그: $GORI_HOME/wordlists(~/.gori/wordlists) 아래의 이름 붙은 목록이며 하나하나가 평범한 파일입니다. wordlist 경로를 받는 곳(fuzz -w, mine --wordlist, discover --wordlist, cookie --crack --wordlist)이면 어느 작업 디렉터리에서든 이름을 쓸 수 있습니다. /가 있는 값은 경로이므로 주어진 그대로 읽고, 이름만 있으면 현재 디렉터리를 먼저, 그다음 카탈로그를 찾습니다. 여기서는 프로젝트가 필요 없고 요청도 보내지 않습니다. 전체 모델은 가이드를 보세요.

gori run sitemap params --host api.example.com --format names | gori run wordlist save api-params.txt
gori run wordlist                       # 가진 목록: 이름과 크기
gori run mine 42 --wordlist api-params.txt
gori run wordlist show api-params.txt --head 5
gori run wordlist rename api-params.txt api-v2-params.txt
gori run wordlist delete api-v2-params.txt --yes

이름은 어느 문자든 글자와 숫자, _, ., +, -, 안쪽 공백(최대 200바이트, 글자·숫자·_로 시작해야 하고 .이나 공백으로 끝날 수 없음)이며 경로 구분자가 든 값은 거부합니다. 모든 verb가 -h를 받고, 거부된 변경 verb는 1로 종료하며 이유를 알려 줍니다.

명령줄에서 세션 바인딩 쓰기

세션 바인딩(로그인 응답에서 채워지는 $BIND.SESSION 같은 것. 세션 바인딩 참고)은 그것을 관측한 gori 프로세스의 메모리에만 존재합니다. settings.json에도, 프로젝트 데이터베이스에도 기록되지 않습니다. 복원된 토큰은 이미 낡은 것이고, 다시 추출하는 비용은 요청 한 번이기 때문입니다.

gori run은 호출마다 프로세스 하나이며, 스윕은 의도적으로 추출 소스가 아닙니다(공격 페이로드를 그대로 되비추는 응답이 세션을 그 값으로 바꿔버릴 수 있기 때문입니다). 그래서 선언된 바인딩을 참조하는 헤드리스 fuzz / mine / sequence / discover 템플릿은 그것을 채울 수단이 없어, 토큰이 리터럴 텍스트 그대로 나갑니다(거부되지 않습니다).

--bind-from FLOW-ID가 그 빠진 단계입니다. 캡처된 플로우 하나(로그인)를 의도적 전송 경로로 재생해 그 응답이 바인딩 테이블을 채우게 하고, 같은 프로세스 안에서 스윕을 이어 실행합니다.

gori run fuzz 42 --wordlist ids.txt --bind-from 17
# bind-from: flow #17 replayed → bound $BIND.SESS

하나의 stdio 세션에서 gori mcp 도구를 두 번 호출하는 경우도 원래부터 같은 방식으로 동작합니다.

run import

프로젝트의 History로 플로우를 일괄 임포트합니다. TUI의 Import 오버레이에 대응하는 CLI입니다(Proxy & History → 임포트 참고). 소스 플래그는 정확히 하나만 지정해야 하며, 모든 소스는 PATH가 -이면 stdin을 읽습니다(generator | gori run import --urls -). stdin은 파이프나 리다이렉트여야 합니다. 트래픽은 전혀 보내지 않습니다.

gori run import --postman api.postman_collection.json --db ./assessment.db --format json

임포트는 플로우를 기록하므로 discover와 같은 방식으로 대상을 정합니다. --db를 주면 생성하거나 다시 열고, 주지 않으면 기본 프로젝트를 몰래 만들지 않고 기존 프로젝트에 씁니다.

형식이 잘못된 항목은 파일 전체를 중단시키지 않고 건너뛰며, 결과에 양쪽 개수가 모두 담깁니다({"count": 12, "attempted": 12, "skipped": 3}). 프로젝트가 파싱한 플로우를 모두 커밋하지 못하면(저장소가 바쁘거나 쓸 수 없는 경우) count가 attempted보다 작아지고, text 줄에 커밋되지 않은 개수가 나오며, 명령은 1로 끝납니다. 임포트를 다시 실행하면 그 플로우를 재시도합니다. 응답까지 가져오는 것은 --har와 --burp뿐이고, 나머지는 요청 템플릿이라 보내기 전까지 History에서 Pending으로 보입니다.

run sitemap

gori run sitemap --in-scope --format paths

-q/--query=QL는 history와 같은 QL로 엔드포인트를 거릅니다(위치 인자로도 넘길 수 있습니다). Sitemap 전용 경로 메모 필드 tag:도 받습니다(적용 범위). -n/--limit=N은 스캔할 엔드포인트 수를 제한합니다(기본값 10000). --in-scope는 스코프 내 호스트로 한정하고, --hide-static은 이미지·폰트·오디오·비디오를 뺍니다(TUI 트리처럼 플로우 단위). --no-group은 id 접기를, --no-fold-query는 쿼리 문자열 접기를 끕니다(서로 다른 축입니다). --js-refs는 캡처한 JavaScript가 참조하지만 아무도 요청하지 않은 경로도 함께 그립니다(sitemap js 참고. JSON에서는 js_refs와 unrequested로 나오며, paths에는 나오지 않습니다). --format은 text(트리), json, paths 중에서 고릅니다. --lenient는 없는 필드 이름을 쓴 쿼리를 거절하지 않고 받아들입니다.

트리의 루트는 오리진(스킴, 호스트, 포트)마다 하나라서, http://127.0.0.1:19021, http://127.0.0.1:19022, https://127.0.0.1:8443은 루트 세 개가 됩니다. paths는 엔드포인트마다 기본 포트를 뺀 전체 URL을 출력합니다(GET https://127.0.0.1:8443/only-tls). json의 호스트 객체는 host에 포트 없는 호스트를 그대로 두고 scheme, port, origin(paths가 앞에 붙이는 값)을 더합니다. 태그는 호스트에 붙으므로 그 호스트의 모든 오리진 아래에 보입니다.

sitemap tag: 경로 하나에 자유 텍스트 메모를 고정합니다. TUI Sitemap에 보이는 그 메모입니다.

gori run sitemap tag --host api.example.com --path /v1/users --tag "IDOR candidate"
gori run sitemap tag --host api.example.com --path /v1/users --clear
gori run sitemap tag --list

sitemap params: TUI Params 서브탭과 같은 파라미터 목록입니다. 오리진(스킴, 호스트, 포트), 메서드, 경로, 위치, 이름마다 한 줄씩 나오며, 그 이름이 나온 플로우 수, 서로 다른 값 최대 --samples개(기본값 5), 그리고 4바이트 이상인 값이 디코딩된 응답 본문의 앞 256 KiB 안에 그대로 나타나면 reflected가 붙습니다(관찰일 뿐 취약점 판정은 아닙니다).

gori run sitemap params --host api.example.com
gori run sitemap params 'method:POST' --location json,form --format json
gori run mine 42 --wordlist <(gori run sitemap params --host api.example.com --format names)

-q/--query=QL(위치 인자로도 가능), --in-scope, --hide-static은 읽을 플로우를 좁힙니다. history처럼 플로우 단위로 적용됩니다. --host는 정확한 호스트, --origin=URL은 그 호스트의 오리진 하나(http://127.0.0.1:19021, --host와 함께 쓸 수 없음), --path=PREFIX는 경로 접두사, --location=LIST는 위치를 고릅니다(기본값 전체). 표준 브라우저 헤더는 --all-headers를 주지 않으면 빠집니다. --max-flows=N은 조건에 맞는 최신 플로우 N개를 읽고(기본값 2000), 더 오래된 플로우를 건너뛰었으면 stderr에 알립니다. 쿠키, 자격 증명 헤더, password나 token처럼 자격 증명 이름을 가진 필드의 값은 --include-sensitive를 주지 않으면 [REDACTED]로 출력됩니다. 가리는 기준은 이름과 JWT / 개인 키 형태뿐이라, 다른 이름의 비밀 값(presigned X-Amz-Signature, 임의의 sig= 등)이나 URL 경로 안의 자격 증명은 그대로 출력됩니다. 텍스트는 행을 오리진(https://api.example.com) 아래에 묶고, json 행에는 scheme, host, port가 들어갑니다. --format은 text, json, names 중에서 고릅니다. names는 한 줄에 이름 하나(JSON은 마지막 키 이름, --location에 지정하지 않으면 헤더 제외)로, Miner나 Fuzzer 워드리스트로 바로 쓸 수 있습니다.

sitemap js: 캡처된 JavaScript가 참조하는 엔드포인트입니다. TUI Sitemap이 js 행으로 그리는 것과 같습니다. 기본값은 같은 오리진에서 캡처된 요청이 닿지 않은 것만 오리진별로 보여주며(http://h:9090과 https://h는 서로 다른 묶음), 각 줄에 읽어 온 플로우와 줄 번호, 문자열, 표시(comment, templated, base: referer|guessed)가 붙습니다.

gori run sitemap js --scan
gori run sitemap js --host api.example.com --format json
gori run sitemap js --format urls | httpx -silent

--scan은 먼저 아직 스캔하지 않은 캡처된 JavaScript 응답과 HTML 페이지를 최신 것부터 --max-flows개(기본값 500) 읽고 참조를 저장합니다. 요청은 보내지 않습니다. -q/--query=QL(위치 인자로도 가능)은 읽을 플로우를 좁히고, --rescan은 이미 읽은 것도 다시 읽습니다. 목록은 --host(정확한 호스트), --path=PREFIX, --all(트래픽이 이미 닿은 참조도 포함), --all-hosts(gori가 캡처한 적 없고 스코프 include도 가리키지 않는 호스트도 포함. 기본값은 숨김), --no-comments, --in-scope로 좁힙니다. --format은 text, json, urls(한 줄에 URL 하나. 그대로 보낼 수 없는 템플릿 참조는 빠집니다) 중에서 고릅니다. 참조는 원본 플로우와 함께 지워집니다.

sitemap export: 캡처된 API를 OpenAPI 3.0.3 문서로 stdout에 출력합니다. TUI Sitemap에서 ⇧E로 쓰는 문서와 같습니다. 빠진 것과 그 이유는 stderr로 나옵니다.

gori run sitemap export --host api.example.com > api.json
gori run sitemap export --host api.example.com --format openapi-yaml > api.yaml
gori run sitemap export --origin http://127.0.0.1:19021 > one-service.json
gori run sitemap export --in-scope --examples > api.json

• 경로는 경로마다 템플릿으로 바꿉니다. 숫자, UUID, 긴 16진수, 날짜 세그먼트는 앞 세그먼트 이름을 딴 파라미터가 되어 /users/123/orders/9f1c2b7d0a4e가 /users/{userId}/orders/{orderId}가 됩니다. 트리 표시용 접기와 달리 한 번만 캡처된 id도 바꿉니다. 템플릿이 같은 엔드포인트는 하나의 operation으로 합치고, 쿼리 문자열만 다른 변형도 하나로 합칩니다.
• 파라미터(query, header, cookie)는 그 operation의 모든 샘플에 있을 때만 required입니다. 표준 브라우저 헤더는 빼고, 반복된 쿼리 키는 배열로 씁니다.
• 본문: 요청 본문과 상태 코드별 응답에 모든 샘플에서 추론한 스키마가 붙습니다. JSON 스키마는 타입을 합치고(integer와 number는 number로, 정말 다른 타입은 oneOf로), 객체 속성은 합집합으로 모으며, 모든 샘플에 있던 멤버만 required로 둡니다. 폼은 객체 스키마, 그 밖의 미디어 타입은 문자열이 됩니다.
• 보안: Authorization 헤더는 http bearer, basic, digest 스킴이 됩니다. 다른 자격 증명 헤더(X-Api-Key, X-Auth-Token 등)와 세션 쿠키는 apiKey 스킴이 됩니다. 값은 절대 쓰지 않습니다.
• 건너뜀: gori가 직접 보낸 요청(Repeater, Fuzzer, Miner, Discover 등. --include-gori를 주면 포함), WebSocket, gRPC, SSE, 응답이 완료되지 않은 플로우, 그리고 OpenAPI에 자리가 없는 메서드(CONNECT, WebDAV)는 건너뛰고 stderr에 개수를 적습니다. 첫 번째 규칙이 없으면 Discover 브루트포스가 추측한 경로가 모두 들어가고, 퍼징이 모든 타입을 느슨하게 만들어 버립니다.

-q/--query=QL(위치 인자로도 가능), --in-scope, --hide-static은 history처럼 플로우 단위로 읽을 대상을 좁힙니다. --host는 정확한 호스트, --path=PREFIX는 경로 접두사입니다. 여러 호스트에 걸친 플로우는 문서 하나에 모든 origin을 servers로 적고, 경로마다 응답한 origin을 따로 적습니다. API 하나당 문서 하나가 필요하면 --host를 쓰세요. --max-samples=N(기본값 20)은 operation마다 읽을 플로우 수, --max-flows=N(기본값 5000)은 전체 플로우 수, --max-endpoints=N(기본값 1000)은 남길 operation 수의 상한입니다. 상한 때문에 문서가 잘리면 stderr에 알려줍니다.

--examples를 주지 않으면 example 값은 없습니다. 예시 값은 샘플 하나에서 가져와 redaction 프로필(--redact=PROFILE, 기본값은 프로젝트 프로필, 없으면 전역 프로필, 없으면 default)을 거칩니다. 프로필의 필드 이름과 폼 키 이름은 쿼리 파라미터에도 적용됩니다. 자격 증명처럼 보이는 이름(X-Access-Token, apiKey, userPassword, sig)은 프로필과 상관없이 placeholder가 되고, 쿠키 값은 항상 placeholder입니다. 경로 id는 비밀을 뜻하지 않는 세그먼트 아래의 짧은 숫자나 날짜일 때만 예시를 붙이고, UUID·16진수·토큰 모양 세그먼트에는 붙이지 않습니다. 경로 속 자격 증명과 구별할 수 없기 때문입니다. 토큰 모양 경로 세그먼트(JWT, 긴 무작위 문자열)와 ;jsessionid= 같은 matrix 파라미터는 경로 키에 들어가지 않습니다. 출력은 결정적이어서 같은 플로우를 두 번 내보내면 바이트가 같습니다. 그래서 두 문서의 diff가 곧 API의 변화입니다.

run oast

아웃오브밴드 리스너입니다. listen은 기본적으로 즉석에서 쓰는 저장소 없는 리스너로, 페이로드를 등록하고 출력한 뒤 콜백을 스트리밍합니다. --save를 붙이면 프로젝트 세션이 됩니다. list / resume / release는 그렇게 저장된 세션(TUI의 RESUME LISTENER 피커가 보여주는 것과 같은 행)을 다룹니다.

gori run oast presets                          # 내장 공개 프로바이더 목록
gori run oast presets --check                  # …각 프리셋의 도달 가능성 프로브
gori run oast listen                           # interactsh, Ctrl-C까지 폴링
gori run oast listen --provider webhook.site --once --json
gori run oast listen --save                    # …프로젝트 세션으로 저장

presets는 공개 프로바이더를 나열하고, presets --check는 각각을 네트워크로 프로브해 실패한 단계(dns / connect / proxy / tls-verify / tls / timeout / exchange / dial)를 출력합니다. 커스텀 트러스트 스토어나 제한된 리졸버를 프로바이더 장애와 갈라 주는 정보입니다. 아무것도 응답하지 않았을 때만 비정상 종료 코드를 반환합니다.

gori run oast presets --check
gori run oast presets --check --format json

listen이 실패할 때도 같은 단계를 이름으로 밝힙니다. tls-verify의 해법은 다른 프로바이더가 아니라 이 머신의 트러스트 스토어입니다. SSL_CERT_FILE=/path/to/ca-bundle.crt(또는 SSL_CERT_DIR=/path/to/certs)로 실행해 사설 CA나 TLS 검사 프록시의 CA를 신뢰시키세요. gori 자신의 서비스 트래픽에서 이 번들은 가산적이라(시스템 스토어를 그대로 로드) 공개 프리셋도 계속 동작합니다. --ca-file 플래그는 없습니다.

listen 옵션:

--save는 즉석 리스너를 프로젝트 리스너로 바꾸고, 세 가지가 달라집니다. 모든 콜백이 프로젝트에 기록되고(그래서 TUI OAST 탭에 같은 히트가 보이고), 종료해도 등록이 유지되어 나중에 oast resume ID로 이어받을 수 있으며, 아웃오브밴드 프로브 룰(ssrf_oast, xxe_oast, cmd_injection_oast, rfi_oast)이 페이로드를 만들어낼 세션을 갖게 됩니다. 세션이 없으면 이 룰들은 아무것도 계획하지 않고, gori run probe --active가 그 사실을 알려줍니다. 세션 명령들과 마찬가지로 --project / --db를 받으며, 정리는 oast release ID입니다.

oast list / resume / release: 프로젝트에 저장된 리스닝 세션입니다(아래의 프로바이더는 어디서 듣는지를, 세션은 그 위의 살아 있는 등록 하나를 뜻합니다). 등록은 그것을 만든 프로세스보다 오래 남고, 그래서 어제 심어둔 페이로드를 오늘도 지켜볼 수 있습니다.

gori run oast list                                       # id, 프로바이더, 페이로드 호스트, 히트 수, 마지막 폴링
gori run oast list --format json
gori run oast resume 7                                   # 세션 #7 재개 후 콜백 스트리밍
gori run oast resume 7 --once --json                     # 한 번만 폴링하고 JSON 라인 출력 후 종료
gori run oast release 7                                  # 서버 측 등록 해제

resume과 release는 세션 id(7, 또는 list가 출력하는 #7)를 받습니다. resume은 서버 측 상태를 다시 살려 이미 심어둔 페이로드가 계속 resolve되게 한 뒤 폴링합니다. 받은 콜백은 모두 프로젝트에 기록되므로 TUI OAST 탭에서 같은 hit를 보게 되고, last_poll_at도 TUI 리스너처럼 갱신됩니다. Ctrl-C는 폴링만 멈추고 등록은 유지합니다. 정리는 release로 명시적으로 하며, 어느 쪽이든 저장된 콜백은 남습니다. 자동으로 재개되는 것은 없습니다.

oast providers: 위의 즉석 listen과 달리 프로젝트에 저장되는 프로바이더입니다. 동사: list(기본), add, update, enable, disable, delete(rm).

gori run oast providers                                  # 토큰은 [REDACTED]로 출력
gori run oast providers add --name lab --kind custom-http --host https://oast.lab.internal
gori run oast providers enable p_1

enable, disable, update, delete는 표시 이름이 아니라 프로바이더 id(p_1 또는 그냥 1)를 받습니다. add가 부여한 id를 출력하고, list에도 나옵니다. list는 settings.json의 전역 프로바이더도 g_<hex>로 보여 주며, 이것들은 여기서 읽기 전용입니다.

run jwt

JWT를 디코드, 검증, 재서명하거나 공격 페이로드를 생성합니다. 저장소 없는 계산이며, 토큰은 <token> 인자나 stdin에서 받습니다. 5개 세그먼트의 암호화 토큰(JWE)은 보호 헤더까지만 디코드합니다. gori는 alg/enc/kid를 읽을 뿐 클레임을 복호화하지 않습니다.

gori run jwt eyJhbGci...                        # 디코드(기본)
gori run jwt eyJhbGci... --encode --alg HS256 --secret s3cret
gori run jwt eyJhbGci... --encode --set role=admin --secret s3cret
gori run jwt eyJhbGci... --encode --alg ES256 --key ./private.pem
gori run jwt eyJhbGci... --verify --key ./public.pem
gori run jwt eyJhbGci... --attacks --key ./public.pem

run cookie

서명된 Flask / Rack / Django 세션 쿠키를 디코드, 검증, 브루트포스, 위조합니다. 저장소 없는 계산이며, 쿠키는 <cookie> 인자나 stdin에서 받습니다.

gori run cookie 'eyJ1c2VyIjoi...'                            # 기본은 decode, 형식은 자동 판별
gori run cookie 'eyJ1c2VyIjoi...' --crack --wordlist secrets.txt
gori run cookie --forge --type flask --secret s3cret --payload '{"user":"admin"}'

run decoder

값에 대해 Decoder 체인을 실행합니다. 단계는 |, >, ,로 구분합니다.

exec:COMMAND로 쓴 단계는 컨버터가 아니라 외부 프로세스 훅입니다. 현재 값이 COMMAND의 stdin으로 가고 그 stdout이 단계의 출력이 됩니다. 셸 없이 exec되므로 세 구분자는 인자 안에 넣을 수 없습니다.

gori run decoder 'base64-decode | jwt-decode' "$TOKEN"
echo -n secret | gori run decoder 'sha256 | base64'
gori run decoder 'base64-decode > exec:./parse-envelope --json' "$BLOB"
gori run decoder list                           # 모든 컨버터(이름, 분류, 방향)

run issues / notes

gori run issues --format markdown --export report.md
gori run issues --format sarif --export issues.sarif    # GitHub code scanning / CI 대시보드에 업로드
gori run notes --all

스크립트에서 create / update로 이슈를 작성합니다:

gori run issues create --title "Reflected XSS on /search" --cvss 8.8 --host app.example.com --flow 42
gori run issues update 7 --status confirmed --notes "Verified on staging" --severity critical
gori run issues delete 7 --yes

# 노트 본문은 인자 벡터 대신 파일이나 파이프에서 읽을 수 있습니다
gori run issues create --title "IDOR on /v1/users/{id}" --severity high --notes-file writeup.md
report-generator | gori run issues update 7 --status confirmed --notes-stdin

--notes, --notes-file, --notes-stdin은 함께 쓸 수 없고, 본문은 바이트 그대로 읽힙니다. 여러 줄 UTF-8도 CRLF도 보존됩니다(프로젝트 env var로 바인딩된 값은 다른 이슈 필드와 마찬가지로 $ENV.NAME으로 마스킹됩니다). 파일이나 파이프로 넘긴 긴 작성물은 프로세스 목록과 셸 히스토리에 남지 않습니다. create에서는 이슈와 한 트랜잭션에 기록되므로 스크립트가 create 후 update를 이어 붙일 필요가 없습니다. 노트를 비울 때는 update에 --notes ''를 쓰고, 아무 바이트도 주지 않은 파일이나 파이프는 거부됩니다. 리포트 생성기가 죽었다고 해서 기존 작성물이 조용히 지워지면 안 되기 때문입니다. --notes-stdin도 --request-stdin과 같은 이유로 파이프나 리다이렉트(--notes-stdin < notes.md)를 요구하고 터미널은 거부합니다.

--format sarif는 SARIF 2.1.0 로그를 씁니다. GitHub code scanning, DefectDojo, Azure DevOps가 그대로 읽는 형식입니다. 이슈 하나가 result 하나가 되며, severity는 SARIF level로 매핑되고(5단계 원본은 rank와 룰의 security-severity에 보존), false-positive/resolved 상태는 suppression으로 나가 정리한 이슈가 다시 열린 것으로 보이지 않습니다. 연결된 플로우는 실제 헤더와 (디코딩·64 KiB 상한) 본문을 담은 webRequest/webResponse로 함께 실립니다.

**이 로그에서 자격 증명 헤더 값은 기본적으로 [REDACTED]**이며, 무언가 가려졌으면 메시지에 gori/sensitiveHeadersRedacted: true가 붙습니다. SARIF 로그는 머신 밖으로 나가도록 만들어지는 문서라서 history --format json, evidence show와 같은 기본값을 따르고, --include-sensitive를 주면 값을 그대로 씁니다. 반복된 헤더는 그 필드가 허용하는 방식으로 합칩니다. 리스트 값은 , 로, Cookie 쌍은 ; 로 잇습니다. Set-Cookie는 합칠 수 없으므로 필드들을 줄바꿈으로 이어 쓰고, 메시지의 gori/setCookie 속성에도 필드마다 하나씩 나열합니다.

노트도 읽고 쓸 수 있습니다. 인자 없이 notes를 실행하면 목록을 보여주고(*가 활성 노트), notes <n>은 인덱스로 하나를 출력합니다:

gori run notes                                  # 목록
gori run notes 2                                # 2번 노트 출력
gori run notes create --text "SSRF candidate on /fetch"
echo "pasted from a scratchpad" | gori run notes create
gori run notes append 1 "confirmed on staging"
gori run notes update 1 --text "rewritten from scratch"
gori run notes delete 2 --yes

노트는 어디에도 다시 없는 글입니다. 캡처를 다시 하거나 실행을 반복해서 복원할 수 있는 대상이 아닙니다. 게다가 인덱스는 목록 위치라서, 앞의 노트가 하나 사라지면 notes delete 2가 가리키는 노트도 달라집니다. 그래서 delete는 -y/--yes 없이는 거부하고(대화형 확인 절차는 없습니다), 거부 메시지에 노트의 첫 줄(빈 노트라면 생략)을 인용해 번호를 잘못 짚었는지 삭제 전에 확인할 수 있게 합니다.

run notify

notify는 에이전트가 MCP reply_to_operator로 하는 일을 스크립트가 하는 방법입니다. summary는 알림 링과 Miss Ring 말풍선에 뜨는 한 줄이고, --detail(또는 --detail-file, -면 STDIN)은 링에서 ↵로 여는 긴 본문입니다:

gori run fuzz --flow 42 --auto --preset sqli > hits.txt && gori run notify "fuzz on flow 42 done" --level success --detail-file hits.txt
./nightly-scan.sh 2>&1 | tail -20 | gori run notify "nightly scan finished" --detail-file -

이 줄은 프로젝트 이벤트 피드에 script 소스로 기록되므로, 링에는 에이전트 답장에 붙는 ai 표시 없이 뜨고 Activity 패널에서 따로 걸러 볼 수 있습니다. TUI가 열려 있든 아니든 기록되고 notify는 어느 쪽이든 0으로 끝나며, 출력이 창이 있어 보여줬는지를 알려줍니다. 창이 없었다면 다음에 그 프로젝트를 여는 TUI가, 그동안 도착한 에이전트 답장과 함께 노트 하나로 요약해 보여줍니다.

run links

이슈나 노트가 가리키는 증거입니다. 캡처된 플로우, Repeater 세션, Fuzz / Miner 실행이 대상이 됩니다. Markdown 이슈 내보내기는 이미 이 포인터를 해석해 넣고, 여기서는 목록 조회와 편집을 합니다.

gori run links --owner=issue --id=7
gori run links add --owner=issue --id=7 --ref=flow --ref-id=42
gori run links delete --owner=note --id=2 --ref=repeater --ref-id=3

대상이 정리(prune)된 포인터는 사라지지 않고 (stale)로 표시되므로, "증거가 없음"과 "증거가 사라짐"을 구분할 수 있습니다. add는 멱등이며, 양쪽 대상이 모두 존재해야 합니다.

run evidence

Issue의 동결된 증거입니다. 캡처된 플로우나 Repeater 탭의 교환 하나를, 그것이 취약점을 확인해 준 순간에 그대로 복사한 변경 불가 사본입니다. links가 live 출처 포인터라면 이것은 보관된 바이트입니다. Repeater의 다음 전송이나 History 보존 정리는 사본에 닿지 못하므로, 응답이 취약점을 확인해 줄 때 한 번, 재테스트 뒤에 한 번 더 동결하세요. 스냅숏 하나를 여러 Issue에 연결할 수 있고, 마지막 Issue 연결을 끊어도 다시 연결하거나 명시적으로 삭제할 때까지 고아 상태로 남습니다.

gori run evidence freeze --issue=7 --ref=repeater --ref-id=3       # 사본 + live 링크
gori run evidence freeze --issue=7 --ref=flow --ref-id=42 --no-link
gori run evidence --issue=7                                        # 목록: 출처, 시각, 상태, 크기, SHA-256
gori run evidence                                                  # 프로젝트 전체 보관함(고아 포함)
gori run evidence show 12                                          # 사본 출력, 자격 증명은 가려짐
gori run evidence show 12 --include-sensitive --format=json
gori run evidence link 12 --issue=9                                # 다른 Issue에도 연결
gori run evidence unlink 12 --issue=7                              # 고아가 되어도 스냅숏 유지
gori run evidence delete 12 --yes

한 번도 보내지 않은 Repeater 탭은 요청만 동결하지 않고 거부하며, 응답이 아직 도착하지 않은 플로우도 거부합니다. Repeater 복사본은 탭에 저장된 요청(바인딩은 펼치지 않은 상태)과 저장소의 마지막 응답(성공한 전송의 것)을 짝지으므로, 취약점을 확인해 준 전송 직후에 동결하세요.

요청 드리프트. Repeater 탭은 요청 하나와 응답 하나를 들고 있고, 요청을 고쳐도 옆의 응답은 그대로입니다. 즉 전송 → 요청 수정 → 동결 순서로 하면 수정된 요청과 이전 교환의 응답이 한 사본에 묶입니다. gori는 각 전송이 실제로 나간 요청의 SHA-256을 기록해 이를 구분합니다. freeze는 그런 탭을 이름을 밝혀 거부하고 다시 보내라고 안내하며, --allow-drift를 주면 어긋난 쌍을 그대로 기록하고, TUI는 기록하기 전에 묻습니다. 이 버전보다 오래된 gori가 저장한 응답에는 기록된 다이제스트가 없으며, 그런 행은 드리프트가 아니라 "알 수 없음"으로 취급합니다. WebSocket 복사본은 핸드셰이크이며 프레임 기록은 복사되지 않습니다. 프로젝트의 동결 증거 총량은 256 MB로 제한되며, 넘으면 사본을 삭제할 때까지 freeze가 거부합니다. show는 본문을 디코딩해 텍스트 형식에서는 64 KB에서 자르고(저장된 사본은 온전합니다), JSON 형식은 get_flow와 같은 모양입니다.

run retest

Issue의 리테스트: 결함을 재현하는 Repeater 전송을 순서대로 나열하고, 각 단계에 역할과 기대 결과 하나를 붙인 것, 그리고 최근 실행 기록입니다. links는 무엇이 관련되어 있는지를, evidence는 결함을 증명한 바이트를 남기지만, 둘 다 실행할 수는 없습니다. "먼저 #4로 로그인하고, 그다음 #5가 403을 주어야 한다"는 서술을 CI가 실행할 수 있는 형태로 바꾸는 표면입니다.

gori run retest add --issue=7 --repeater=4 --role=setup                        # 먼저 로그인
gori run retest add --issue=7 --repeater=5 --role=baseline --assert=status:200
gori run retest add --issue=7 --repeater=6 --role=variant  --assert=status:403
gori run retest --issue=7                                                      # 각 단계가 무엇을 보낼지 포함한 계획
gori run retest move 9 --to=1                                                  # 순서 변경(id는 --format=json)
gori run retest update 9 --role=control --assert=body:same
gori run retest remove 9                                                       # 단계 하나 제거(`rm`도 됨)
gori run retest clear --issue=7 --yes                                          # 모든 단계 삭제
gori run retest run --issue=7                                                  # `pass`일 때만 종료 코드 0
gori run retest runs --issue=7                                                 # 보존된 실행 기록
gori run retest show 3                                                         # 한 실행의 결과 표
gori run retest forget 3                                                       # 기록에서 실행 하나를 지움

forget RUN은 실행 요약과 결과 행을 지웁니다. 그 실행을 만든 단계도, 각 전송이 기록한 History 플로우도 그대로 남습니다. 지우는 것은 보고이지 증거가 아닙니다. 기록은 최근 20개로 알아서 정리되므로, 이 명령은 애초에 기록에 남으면 안 되는 실행(잘못된 대상으로 보냈거나, 이후 수정된 스코프에서 돈 배치)을 위한 것입니다.

단언(단계당 하나):

JSON 경로는 sequence --jsonpath와 같은 문법입니다: 점 표기(data.items.0.id) 또는 괄호 표기($.data.items[0]["id"]). 와일드카드, 필터, .., 닫히지 않은 괄호처럼 gori가 읽을 수 없는 경로는 단계를 추가할 때 거부되므로, 경로를 한 번도 읽지 못해서 json-absent:가 통과하는 일은 없습니다. 읽을 수 있는 경로가 없는 필드를 가리키면 평범한 부재입니다.

각 단계는 실행 시점에 Repeater 탭이 들고 있는 요청을 그대로 보냅니다. 그래서 리테스트는 고쳐지는 요청을 따라가고, gori run evidence는 당시 모습 그대로를 얼립니다. 모든 전송은 프로젝트 스코프와 Sandbox 게이트를 통과하며 History에 src:retest로, 이슈와 단계 번호를 달고 기록됩니다. 그래서 탭이 한참 뒤에 바뀌어도 결과 행은 자기가 보고한 바로 그 응답을 열 수 있습니다. 탭에 저장된 응답은 덮어쓰지 않습니다.

setup 단계가 실패하면 측정 단계는 중단되지만(그 전제 위에서 이후가 측정되므로) cleanup은 실행됩니다. gori가 전송을 거부하면(스코프, Sandbox, exclude 규칙) 그 뒤는 모두 건너뛰며, cleanup도 --allow-cleanup 없이는 보내지 않습니다. 건너뛴 단계도 이유가 적힌 행을 남기므로 부분 실행이 통과처럼 읽히지 않습니다. body: 단언은 기준이 없을 때는 물론, 직전 baseline 단계가 자기 기대 결과를 못 맞췄을 때도 통과가 아니라 inconclusive입니다. 읽기를 확립하지 못한 기준은 아무것도 고정하지 못하므로, 그렇지 않으면 status:200 기준이 받은 403 오류 페이지와 변형을 비교해 둘 다 오류 페이지인데도 "본문이 그대로다"라고 보고하게 됩니다.

판정이 pass가 되려면 모든 단계가 실행되고 모든 단언이 결정되어야 합니다. blocked는 fail보다 우선합니다. gori가 끝내기를 거부한 실행은 대상이 아니라 스코프 설정에 대한 사실이기 때문입니다. run은 pass에서 0, 그 외에는 1로 종료합니다. Issue당 최근 20개 실행이 보존됩니다.

run rewriter

스크립트에서 Match & Replace 규칙을 관리합니다. Rewriter 탭이 편집하는 것과 같은 규칙이며, 실시간 프록시 트래픽에 적용됩니다:

gori run rewriter                                       # 적용 순서대로 규칙 목록
gori run rewriter add --op set_header --target request \
  --find X-Forwarded-For --value 127.0.0.1 --host '*.example.com'
gori run rewriter add --op replace --target response --part body \
  --match regex --find 'secret=(\w+)' --value 'secret=[redacted]'
gori run rewriter add --op remove_header --target response \
  --find Content-Security-Policy --scope global          # 모든 프로젝트에 적용
gori run rewriter preview --op replace --part body --find password --value hunter2
gori run rewriter add --op short_circuit --map-dir ./tampered \
  --strip-prefix /static/ --fallthrough                 # 없는 파일만 원본으로
gori run rewriter add --op short_circuit --find /api/pay --fault reset
gori run rewriter add --op short_circuit --from-flow 42  # 캡처된 응답을 스텁으로
gori run rewriter disable 3
gori run rewriter disable 2 --scope global               # 이 프로젝트에서만 끄기
gori run rewriter disable 2 --scope global --everywhere  # 기본값을 꺼서 모든 곳에서 끄기
gori run rewriter rm 3

preview는 같은 규칙 플래그를 받아, 규칙을 저장하지 않고 저장된 플로우 중 몇 개가 바뀌었을지 보고합니다. rm(delete), enable, disable은 목록의 규칙 id와 함께 --scope도 받습니다. 두 저장소가 규칙 번호를 각자 매기므로 id 하나가 서로 다른 두 규칙을 가리키기 때문입니다. 목록은 범위를 G/P 접두어로 출력하고(G*는 이 프로젝트가 해당 전역 규칙의 기본값을 오버라이드했다는 뜻), 프록시가 적용하는 순서 그대로 전역 규칙을 먼저 보여 줍니다. 전역 규칙과 프로젝트 규칙을 참고하세요.

본문 규칙은 HTTP/1.1과 HTTP/2 모두에서 필요에 따라 Content-Length를 다시 맞추고 청크를 해제합니다. 대화형 편집기는 Proxy & History를 참고하세요.

rewriter preset: 응답 수정 프리셋 설치. 평범한 Match & Replace 규칙을 써 주는 이름 붙은 출발점입니다. 동사: list, add <name>.

gori run rewriter preset list
gori run rewriter preset add unhide-hidden-fields
gori run rewriter preset add remove-csp --scope global --disabled

이름은 unhide-hidden-fields, enable-disabled-fields, remove-length-limits, strip-validation, remove-csp, remove-security-headers, disable-sri입니다. add는 --scope=project|global과 --disabled(무장하지 않고 설치해 먼저 검토)를 받습니다. 설치되는 규칙은 rewriter add와 같은 경로를 지나므로 이후에도 목록에 나오고 편집·삭제됩니다. 같은 프리셋을 두 번 설치하면 병합되지 않고 눈에 보이게 중복됩니다.

rewriter extract: 세션 바인딩을 선언하는 규칙입니다. $BIND.NAME을 어느 응답의 어디에서 읽을지 정합니다. 동사: list(기본), add, rm(delete), enable, disable.

gori run rewriter extract add --name SESS --kind cookie --selector session --host '*.example.com'
gori run rewriter extract add --name CSRF --kind regex --selector 'name="csrf" value="([^"]+)"'

rewriter bindings: 그 규칙들이 선언한 이름을 나열합니다(--format text|json). 값은 여기에 나오지 않으며, 나올 수도 없습니다. 바인딩 값은 실행 중인 gori의 메모리에만 있고 어디에도 기록되지 않으므로 다른 프로세스가 읽을 것이 없기 때문입니다. 살아 있는 값 테이블은 Rewriter 탭의 bindings 하위 탭에서 봅니다. 헤드리스 스윕에서는 --bind-from이 같은 프로세스 안에서 값을 채웁니다. 명령줄에서 세션 바인딩 쓰기를 참고하세요.

run grpc

gRPC .proto 렌즈를 명령줄에서: 이 프로젝트가 캡처된 gRPC를 어떤 스키마로 렌더하는지, 각 조각이 어디서 왔는지.

gori run grpc                                  # 무엇이 로드됐는지 (schema가 기본 동사)
gori run grpc schema --format json
gori run grpc reflect https://api.test:443     # ACTIVE: 대상에게 디스크립터를 요청
gori run grpc forget https://api.test:443      # 캐시된 대상 하나 버리기 (`rm`도 받습니다)
gori run grpc forget --all

schema와 forget은 프로젝트 DB 밖을 건드리지 않습니다. 보내는 쪽은 reflect 하나입니다. 대상의 grpc.reflection.v1 서비스에(없으면 v1alpha로, 실제 배포된 서버 대부분은 아직 이쪽입니다) 서비스 목록, 각 서비스를 선언한 파일, 그 파일들의 import 순으로 그래프가 닫힐 때까지 요청해 결과를 프로젝트에 캐시합니다. 다른 액티브 gori run 명령과 같은 스코프 게이트를 지나므로 범위를 벗어난 대상은 연결하기 전에 거부됩니다. 두 리플렉션 버전 모두 응답하지 않는 서버는 조용히 실패하지 않고 그렇다고 말하며, 무엇도 스스로 다시 받아오지 않습니다.

디스크립터 셋 파일(Project settings → Proto schema)은 forget으로 해제되지 않습니다. 프로젝트 설정에서 경로를 지우세요. 파일과 리플렉션 페치가 어떤 선언에 대해 어긋나면 그 수는 redefined로 보고되고 대상 자신의 말이 우선합니다.

run colormarker

Colormarker 규칙을 관리합니다. 캡처된 History의 어떤 행을 어떤 방식으로 칠할지 정하는 규칙이며, 표시 전용입니다. 트래픽을 전혀 수정하지 않으므로 Match & Replace 규칙과 달리 잘못 써도 목록이 오해를 부를 뿐, 메시지가 바뀌지는 않습니다.

gori run colormarker                                        # 우선순위 순으로 규칙 목록
gori run colormarker add --when 'status:>=500' --color red --style full --name 'prod 5xx'
gori run colormarker add --when 'host:cdn' --color blue --style strip --scope global
gori run colormarker update 2 --color orange                # 우선순위를 지키며 제자리 수정
gori run colormarker move 2 --up                            # 우선순위 올리기
gori run colormarker preview --when 'method:DELETE'
gori run colormarker preview --when 'resp.body:secret' --scope global
gori run colormarker disable 1 --scope global               # 이 프로젝트에서만 끄기
gori run colormarker disable 1 --scope global --everywhere  # 모든 프로젝트의 기본값을 끄기
gori run colormarker rm 3

update에서는 모든 필드가 선택이며 규칙의 현재 값이 기본입니다. --color만 주면 색만 바꾸고 --when만 주면 조건만 바꿉니다. 삭제 후 재생성 대신 이 명령을 쓰세요. 색상 규칙은 위치가 곧 의미이고(첫 번째로 매칭되는 활성 규칙이 행을 칠합니다) 다시 추가한 규칙은 자기 스코프 블록 맨 끝에 놓여, 전에 앞서던 규칙들보다 뒤로 밀립니다. enable / disable은 따로 두었습니다. 전역 규칙에서 그 둘은 라이브러리가 아니라 이 프로젝트에 대한 진술이기 때문입니다.

우선순위가 곧 규칙 집합의 의미입니다. Match & Replace 규칙은 합성되어 활성화된 모든 규칙이 순서대로 실행되지만, 색상 규칙은 해석됩니다. 첫 번째로 매칭되는 활성 규칙이 행을 칠하고 나머지는 조회조차 되지 않습니다. move가 rewriter에는 없고 여기에만 있는 이유입니다. 전역 규칙이 프로젝트 규칙보다 먼저 해석되므로, 상시 정책이 로컬 레이어보다 우선합니다.

--when은 History QL 조건입니다. 자기가 칠하는 목록 위의 필터 바와 문법도, 필드 집합도, 답도 같으며 ~정규식과 AND / OR / NOT, -부정, (그룹)을 모두 포함합니다. 캡처된 행이 스스로 답할 수 있는 항(host: path: url: method: scheme: status: proto:)은 쿼리 없이 메모리에서 매칭되고, 나머지(body: header: size: dur: stub: static: src: scope:)는 다시 그릴 때마다 규칙당 한 번의 배치 쿼리로 프로젝트 DB에 대해 해석됩니다. 그냥 두면 조용히 실패할 네 가지가 있어, gori는 거부하거나 경고합니다.

• body:는 여기서 텍스트 인덱스가 아니라 저장된 바이트를 스캔합니다. 그래서 필터 바의 body:가 건너뛰는 바이너리 바디까지 닿지만, 각 방향 앞 64 KiB까지만이고 바이트는 캡처된 그대로입니다. 그 경계를 넘어선 매치나 압축된 바디 안의 매치는 칠해지지 않습니다. (경고)
• host:는 DNS 레이블 글롭이 아니라 부분문자열입니다. host:alpha.test는 xalpha.test도 매칭합니다. (경고)
• 아직 응답이 없는 플로우에는 status가 없습니다. status: 규칙은 응답이 도착한 뒤에 그 행을 칠합니다. (경고)
• scope:는 s 표시 렌즈와 무관하게 프로젝트의 스코프 규칙을 따릅니다. 스코프 규칙이 하나도 없으면 아무것도 스코프 안에 있지 않으므로 scope:in과 scope:out 둘 다 아무것도 칠하지 않고, 반대로 부정형(-scope:in)은 모든 행을 칠합니다. (경고)

경고가 아니라 거부되는 것들: 모르는 필드(그냥 두면 hsot:가 자유 텍스트 검색이 되어 규칙이 영원히 발동하지 않습니다), 컴파일되지 않는 ~ 패턴, 그 필드가 받지 않는 값(size:>bogus처럼 쓰면 항이 버려져 규칙이 말한 것보다 더 많이 칠하게 됩니다), 그리고 모든 플로우에 매칭되는 조건(빈 값이나 입력 중인 host:).

preview는 조건이 최근 플로우 중 몇 개에 매칭되는지와, 실제로 몇 개를 칠하게 되는지를 함께 보고합니다. 앞선 활성 규칙이 이미 그 행을 차지했다면 두 숫자가 달라집니다. preview가 --scope도 받는 이유가 이것입니다. 전역 규칙은 모든 프로젝트 규칙보다 먼저 해석되므로, --scope=global 후보에게서 행을 뺏을 수 있는 프로젝트 규칙은 하나도 없습니다. update, rm(delete), enable, disable, move는 목록의 규칙 id와 --scope를 받습니다. 두 저장소가 서로 독립적으로 번호를 매기므로 id만으로는 서로 다른 두 규칙을 가리키기 때문입니다. 목록은 스코프를 G/P 접두사로 출력합니다(G*는 이 프로젝트가 해당 전역 규칙의 기본값을 오버라이드했다는 뜻).

탭은 기본적으로 바 위에 없습니다. 0으로 열거나, settings:tabs에서 Rewriter 옆에 슬롯을 줄 수 있습니다. 대화형 편집기는 프록시 & History를 참고하세요.

colormarker color

사용자 색상 팔레트입니다. 내장 6색 위에 얹어 모든 프로젝트의 색상 선택기에 함께 제공되는 이름 있는 색상입니다. 내장 색은 활성 테마를 거쳐 해석되므로 밝은 팔레트와 어두운 팔레트 양쪽에서 제대로 읽히지만, 사용자 색상은 절대 hex 값을 그대로 지니며 테마를 따라가지 않습니다. 팔레트가 주지 않는 색조를 얻는 대신 치르는 대가입니다. 색상은 settings.json(colormarker.colors)에 저장되므로 태생적으로 전역입니다.

gori run colormarker color list
gori run colormarker color add --name hotpink --hex '#ff69b4'
gori run colormarker color update hotpink --hex '#e0559b'   # 이름은 두고 색만 변경
gori run colormarker color update hotpink --name fuchsia    # 색은 두고 이름만 변경
gori run colormarker color rm fuchsia
gori run colormarker add --when 'method:DELETE' --color hotpink

이름이 곧 식별자입니다. 규칙의 --color에 저장되는 값이자 선택기에 보이는 값이므로 소문자로 정규화되고, 중복될 수 없으며, 내장 색 이름과 같을 수 없습니다. update는 두 옵션 중 하나만 줘도 됩니다.

색상을 지우거나 이름을 바꿔도 그 색을 쓰던 규칙은 의도적으로 고쳐 쓰지 않습니다. 규칙은 옛 이름을 그대로 들고 있다가 눈에 띄는 기본색으로 대체되어 그려지므로, 같은 이름으로 색을 다시 추가하면 원래대로 돌아옵니다. 이 명령에서 모든 프로젝트의 데이터베이스에 손을 뻗을 수는 없고, 절반만 적용된 연쇄 수정은 이름 하나가 붕 뜨는 것보다 나쁩니다. 색상 값만 바꾸는 경우는 다릅니다. 규칙은 색을 이름으로 참조하므로 어디서든 새 hex를 그대로 따라갑니다.

run views

History 뷰를 관리합니다. History 목록을 좁히는, 이름 붙은 QL 쿼리입니다. 뷰는 렌즈입니다. 다른 필터를 대체하지 않고 그 위에 AND로 얹히므로, gori run history --view History -q 'status:5xx'는 둘 다를 뜻합니다. 기본 뷰 일곱 개가 모든 프로젝트에 들어 있습니다: 출처 3종 All / History(src:proxy) / History + Repeater(기본값), 그리고 WebSocket·gRPC·SSE·Errors. 저장된 뷰는 컬러 룰과 똑같이 두 저장소에 나뉘어 삽니다.

gori run views                                              # 목록; TUI의 활성 뷰에 ● 표시
gori run views --scope global --format json
gori run views add 'acme errors' -q 'host:api.acme.test status:5xx'
gori run views add 'proxied' -q 'src:proxy' --scope global
gori run views set 'acme errors' -q 'status:>=500'          # 이름은 그대로, 쿼리만 교체
gori run views rename 'acme errors' --to 'acme 5xx'
gori run views scope 'acme 5xx' --to global                 # 두 저장소 사이로 옮기기
gori run views rm 'acme 5xx' --scope global

뷰는 이름으로 지목합니다. --view와 피커가 받는 것이 이름이고, id를 두면 한 가지를 두 가지로 부르는 셈이기 때문입니다. 이름은 스코프 안에서 유일하며 스코프끼리는 겹칠 수 있습니다. 그럴 때 --view는 project → global → 기본 제공 순으로 고릅니다. 프로젝트 환경변수와 호스트 오버라이드가 이미 쓰는 것과 같은 우선순위입니다. 모든 변경 명령이 --scope를 받는 이유는 colormarker rm과 같습니다. 두 저장소는 각각 따로 지목되며, 어느 쪽을 뜻했는지 추측하면 엉뚱한 뷰를 고치게 됩니다. 목록은 스코프를 G/P/· 접두사로 찍습니다.

쿼리는 실행할 때가 아니라 저장할 때 검사합니다. 없는 필드를 쓴 쿼리, 깨진 정규식, 그리고 모든 항이 버려질 쿼리는 거절합니다. 마지막 것이 중요합니다. 아무것도 좁히지 못하는 뷰인데도 v: 칩은 좁히고 있다고 주장하게 되기 때문입니다. 같은 검사가 세 표면 모두에서 돌아가므로, TUI가 거절한 뷰를 CLI가 받아 주는 일은 없습니다.

기본 제공 뷰는 편집도 삭제도 되지 않으며, 저장된 뷰가 기본 뷰의 이름을 가져갈 수도 없습니다. 가려 버리면 --view로 그 기본 뷰에 다시 닿을 수 없기 때문입니다.

지금 보고 있는 뷰를 지우면 그 프로젝트는 All로 돌아갑니다. 지운 글로벌 뷰를 가리키던 다른 프로젝트의 포인터는 무해하게 남습니다. id는 단조 증가 카운터에서 나오고 재사용되지 않으므로 다른 뷰가 그 자리를 물려받을 수 없습니다. 대화형 피커는 프록시 & History를 보세요.

run project

프로젝트 목록/생성/내보내기/가져오기/삭제, 또는 프로젝트 스코프 설정(스코프 규칙, env 변수, 호스트 오버라이드) 관리:

gori run project --format json
gori run project list
gori run project list --all
gori run project list --query=acme

list는 비어 있는 프로젝트(캡처된 플로우가 0개)를 숨깁니다. 워크트리나 체크아웃마다 프로젝트를 만들다 보면 수백 개가 쌓여, 정작 트래픽이 든 두세 개가 묻히기 때문입니다. 비어 있는지는 파일 크기가 아니라 행 수로 셉니다. 방금 만든 프로젝트도 3월에 남은 찌꺼기와 크기가 같습니다. 다음 두 개는 아무리 비어 있어도 항상 표시하고 표시자를 붙입니다. ◆는 --project 없이 실행한 gori run이 읽는 프로젝트, ◇는 TUI가 마지막으로 연 프로젝트입니다. --format json에서는 각각 current, tui_active 필드이고, flows 개수와 프로젝트 description(개수를 셀 때 같은 핸들로 함께 읽으므로 추가 open 비용이 없습니다)이 함께 나옵니다. 몇 개를 숨겼는지는 stderr로 나가므로 JSON 파이프는 깨끗한 배열로 남습니다.

--query는 그 나머지 절반입니다. 프로젝트를 가리키는 모든 철자에 대한 부분 문자열이라, 이름이 가물가물해도 찾을 수 있습니다. 정확한 이름·슬러그·짧은 id를 요구하는 --project보다 느슨합니다. 나열된 프로젝트의 데이터베이스를 전부 여는 플로우 집계 앞에 적용되므로, 수백 개를 가진 호스트에서는 빠른 경로이기도 합니다. --all과는 직교하며, 표시가 아니라 행 공급원을 좁히므로 제외한 것을 stderr로 밝힙니다. 매치가 0건이면 이 호스트에 실제로 몇 개가 있는지를 알려 주고, ◆ 프로젝트가 걸러졌다면 그 사실을 이름과 함께 말합니다. 빈 프로젝트 숨김 기본값과 달리 --query는 그 행을 고정해 두지 않기 때문입니다. --format json은 바인딩된 workspace도 함께 실으므로, 소비자도 쿼리와 같은 사실로 걸러낼 수 있습니다. 같은 좁히기를 MCP list_projects{query}가 같은 술어로 제공합니다.

project create

트래픽을 캡처하지 않고 프로젝트를 만듭니다. gori run capture --project=NAME도 필요할 때 만들어 주지만, 이 명령은 요청을 보내지 않으므로 프록시를 띄우기 전에 스코프와 env를 미리 구성할 수 있습니다.

gori run project create "API test"
gori run project create api-test --description="staging sweep"
gori run project create api-test --format json

이미 있는 이름은 오류가 아니라 그 프로젝트를 다시 여는 것으로 처리하며, --format json은 "created": false로 알려 줍니다. 다시 열 때 저장된 표시 이름은 마지막 create의 대소문자로 갱신되고, --description을 주면 기존 설명을 덮어씁니다. 새 이름이 이미 다른 프로젝트의 디렉터리 slug나 짧은 id라면 거부합니다. 그 이름으로는 --project가 새로 만든 프로젝트에 닿을 수 없기 때문입니다.

project switch

--project 없는 모든 gori run 명령이 읽을 프로젝트를 고정합니다. 고정하지 않으면 가장 최근에 활성화한 프로젝트를 읽는데, 이는 다른 프로젝트에 쓰기를 한 번만 해도 옮겨 갑니다.

gori run project switch api-test     # 고정 (이름, slug, 짧은 id)
gori run project switch              # 기본 프로젝트와 그것을 고른 근거 출력
gori run project switch --clear      # 가장 최근에 활성화한 프로젝트로 복귀
GORI_PROJECT=api-test gori run history   # 스크립트 하나를 위한 프로세스 단위 고정

GORI_PROJECT가 고정보다 우선하고, --project/--db는 둘 모두보다 우선합니다. 존재하지 않는 프로젝트를 가리키는 고정이나 GORI_PROJECT는 건너뛰지 않고 거부하며, 고정한 프로젝트를 삭제하면 고정도 풀립니다. project list는 현재 적용 중인 쪽에 ◆를 붙이고, switch의 --format json은 project, id, source(env, pinned, recent), pinned를 보고합니다. gori mcp와 TUI는 이를 읽지 않습니다. MCP는 자체 바인딩(GORI_MCP_PROJECT, 워크스페이스)을 쓰고, TUI는 사용자가 고른 프로젝트를 엽니다.

project export

프로젝트 데이터베이스를 WAL에 남아 있는 커밋된 쓰기까지 포함해 압축 아카이브로 내보냅니다. 원본 프로젝트는 열린 상태로 유지되며 변경되지 않습니다.

gori run project export "API test" -o engagement.gori
gori run project export api-test --output=before-clear.gori --force

쓰기 전에 flow·세션 슬롯·프로젝트 env 변수 개수와 프로젝트 업스트림 자격증명 설정 여부를 stderr에 출력합니다. 아카이브에는 저장된 전체 데이터베이스가 들어가며, 마스킹되지 않습니다. 파일 권한은 소유자만 읽고 쓸 수 있게 설정합니다. 기본적으로 기존 파일은 거부하고, 교체하려면 --force가 필요합니다. 원본 프로젝트 디렉터리 안에는 저장할 수 없습니다.

project import

아카이브를 검증하고 별도의 새 프로젝트로 등록합니다. 기존 프로젝트를 덮어쓰거나 다시 열지 않습니다.

gori run project import engagement.gori
gori run project import engagement.gori --name "API test copy"

프로젝트를 만들기 전에 아카이브의 flow·세션 슬롯·env 변수 개수와 프로젝트 업스트림 자격증명 설정 여부를 stderr에 출력합니다. 기존 표시 이름·디렉터리 slug·짧은 id와 충돌하면 거부하며, 거부 메시지가 해결책으로 --name을 알려 줍니다. 가져온 프로젝트에는 새 짧은 id가 발급되며 로컬 워크스페이스 바인딩과 잠금 파일은 포함되지 않습니다. 이전 DB 스키마는 프로젝트를 처음 열 때 마이그레이션하고, 현재 빌드가 지원하는 것보다 새로운 스키마는 거부합니다. 가져온 프로젝트는 목록에 추가되지만 자동으로 열리지는 않습니다.

사본은 데이터로만 들어오며, 이 머신의 설정이나 실행되는 것으로 들어오지 않습니다. 프로젝트 네트워크 설정(net.*), 호스트 오버라이드, Rewriter/Colormarker 전역 규칙 오버라이드, Probe 모드를 버리고, 모든 세션 슬롯의 자동 갱신을 끄며, pipe 규칙·파일 기반 short-circuit 규칙·exec 커스텀 probe 규칙을 비활성화합니다. 검토한 뒤 신뢰하는 것만 다시 켜세요.

project delete

프로젝트 디렉터리와 그 안에 캡처된 모든 것(플로우, 이슈, 노트, 스코프, 규칙)을 삭제합니다. 되돌릴 수 없으므로 두 단계로 동작합니다. --yes 없이 실행하면 대상만 출력하고 0이 아닌 코드로 종료합니다.

gori run project delete api-test              # 미리보기만, 아무것도 지우지 않음
gori run project delete api-test --format json
gori run project rm api-test --yes            # 실제로 삭제

미리보기는 플로우/이슈 개수, 디스크 사용량과 함께, 삭제가 지키는 잠금 둘 다를 보여 줍니다. 캡처가 살아 있는지(capture_lock_held), 그리고 다른 gori 인스턴스가 DB를 열어 두고 있는지(open_in_another_instance. MCP 서버는 캡처 잠금 없이도 쓰기를 하기 때문입니다). deletable은 이 둘을 합한 판정이고, 마지막 줄이 --yes가 실제로 통과할지를 말해 줍니다. 둘 중 하나라도 걸린 프로젝트는 삭제를 거부하므로 그 캡처를 중지하거나 그쪽에서 닫아야 합니다. capture_lock_held가 null이면 잠금 자체를 읽지 못한 것이고(쓰기 권한 없는 프로젝트 디렉터리), 이때도 삭제는 거부됩니다.

표시 이름은 유일하지 않습니다(같은 basename을 쓰는 두 워크스페이스는 이름을 공유합니다). 이름이 여러 프로젝트에 걸리면 다른 모든 --project와 마찬가지로 삭제를 거부하고 각각의 slug와 짧은 id를 보여 줍니다. 잘못 고르면 되돌릴 수 없기 때문입니다. slug와 짧은 id는 유일하므로 언제나 하나로 확정됩니다.

project scope

프로젝트의 include/exclude 스코프 규칙을 스크립트에서 관리합니다:

gori run project scope                                          # 규칙 목록 + 활성화 상태
gori run project scope --format json
gori run project scope add --kind=include --type=host --pattern=api.example.com
gori run project scope add --kind=exclude --type=regex --pattern='.*\.(css|js)$'
gori run project scope delete 3
gori run project scope enable
gori run project scope disable

목록은 규칙이 하는 또 다른 일을 두 번째 줄로 출력합니다. 규칙이 하나라도 있으면 활성 여부와 관계없이 Active-send gate: ON (N rules)가 찍히는데, 모든 액티브 전송(send, repeater, fuzz, mine, discover, MCP)이 --allow-unscoped 없이는 규칙상 스코프 밖인 대상을 거부하기 때문입니다. --format json에서는 active_send_gate로 실립니다. 규칙이 없으면 gori run 전송은 제한이 없고, MCP는 모든 전송을 거부합니다.

project sandbox

하드 컨테인먼트 샌드박스 게이트를 조회하거나 설정합니다. TUI Project settings 토글의 헤드리스 등가물입니다. 켜면 캡처 프록시가 스코프가 허용하는 요청만 전달하고 나머지는 모두 차단합니다. 표시 렌즈일 뿐인 project scope enable과는 다릅니다.

gori run project sandbox                 # 현재 상태 표시 (기본은 status)
gori run project sandbox status --format json
gori run project sandbox on              # 스코프 밖 트래픽 차단 시작
gori run project sandbox off             # 차단 중지

include 규칙이 없으면 샌드박스를 켤 때 규칙을 추가하기 전까지 모든 캡처 트래픽이 차단됩니다(gori run project scope add …). 이 명령은 경고 후 진행하므로 CI에서 컨테인먼트를 부트스트랩할 수 있습니다.

project env

아웃바운드 요청의 $ENV.KEY 치환에 쓰이는 프로젝트 env 변수를 관리합니다. 전역 변수는 settings.json / TUI Settings에 있고, 이 명령은 프로젝트 레이어만 다룹니다. 이름은 bare로 저장되며, 와이어에서 어떤 문법으로 적히는지는 전역 설정인 gori settings env-syntax가 결정합니다.

gori run project env                              # KEY=[REDACTED] 목록 (--show-values는 값 출력)
gori run project env --format json
gori run project env set TOKEN=secret
gori run project env set HOST api.example.com
gori run project env delete TOKEN

project host-override

프로젝트 호스트 오버라이드를 관리합니다. /etc/hosts처럼 호스트명에 대해 dial할 TCP 대상만 바꾸고, SNI·인증서 호스트·Host 헤더는 원래 이름을 유지합니다. 값에는 포트를 붙일 수 있어(IP, IP:PORT, [v6]:PORT) 호스트명을 다른 포트의 리스너로 돌릴 수 있고, IP만 주면 요청 자체의 포트를 그대로 씁니다. 충돌 시 프로젝트 항목이 전역 호스트네임 오버라이드보다 우선합니다. 별칭: host-overrides.

gori run project host-override                              # 목록
gori run project host-override --format json
gori run project host-override add --host=api.example.com --ip=10.0.0.1
gori run project host-override add 10.0.0.1 api.example.com   # /etc/hosts 순서
gori run project host-override add --host=api.example.com --ip=127.0.0.1:8443   # 포트까지 함께 옮기기
gori run project host-override update 1 --host=api.example.com --ip=10.0.0.9
gori run project host-override delete 1

project network

프로젝트 자체 네트워크 설정, 즉 TUI의 Project settings 카드가 쓰는 net.* 행을 읽고 고칩니다. 여기서 값을 설정하면 이 프로젝트에 한해 settings.json의 전역 network.*를 이깁니다. unset은 그 키를 다시 전역 값으로 되돌립니다. 각 키가 무엇을 하고 어디에 적용되는지는 프로젝트별 오버라이드를 참고하세요. 별칭: net.

gori run project network                                   # 모든 키: 여기서의 값과 출처
gori run project network --format json
gori run project network set upstream_proxy=http://proxy.corp.example:3128
gori run project network get upstream_proxy
printf %s "$PROXY_PASS" | gori run project network set upstream_auth alice --password-stdin
gori run project network set capture_max_mib 16
gori run project network unset capture_max_mib
gori run project network set outbound_max_rps=10          # 모든 실행, 모든 프로세스 합산

자격증명은 Project settings 카드에서와 마찬가지로 입력받은 업스트림에 고정됩니다. set upstream_auth는 상속된 전역 업스트림도 같은 쓰기 한 번으로 프로젝트에 고정하므로, 이후의 전역 편집이나 업스트림 규칙이 비밀번호를 다른 프록시로 데려가는 일이 없습니다. set upstream_proxy는 저장된 자격증명을 새 주소로 옮깁니다(그에 맞춰 Basic인지 SOCKS5인지 다시 판정합니다). 그리고 unset upstream_proxy는 unset upstream_auth를 먼저 하기 전까지 거부됩니다. 여러 행에 걸친 편집은 한 트랜잭션으로 처리하므로, 바쁜 프로젝트가 검증되지 않은 주소 옆에 비밀번호를 저장하는 일은 없습니다. 모든 편집은 자격증명 없이 프로젝트 이벤트 피드에 기록됩니다.

이미 프로젝트를 연 gori(TUI, capture, MCP 서버)는 프로젝트를 열 때 이 행들을 읽어 프로젝트를 다시 열기 전까지 유지합니다. 그런 경우 명령이 STDERR에 이를 알립니다.

run redact

안전한 증거 내보내기가 적용하는 리댁션 프로파일과 그 적용 범위를 관리합니다.

gori run redact profiles
gori run redact set pci --json-field card_number --json-field cvv --json-pointer /data/acct
gori run redact use pci
gori run redact default on

set은 네 종류의 규칙(각각 반복 가능)과 --description을 받습니다.

범위. 프로파일은 프로젝트 데이터베이스나 settings.json 중 한 곳에 살고, 어느 쪽에 있는지도 프로파일의 일부입니다. "password 필드는 절대 내보내지 않는다"는 사용자 자신의 정책이므로 전역이 맞고, "이 타깃은 그걸 pwd_hash라 부르고 계좌번호는 /data/acct에 있다"는 다음 점검로 따라가서는 안 되는 점검 데이터입니다. 해석은 구체적인 쪽 우선(프로젝트, 전역, 내장 순)이고 이름이 같으면 먼저 나온 것이 이깁니다. 그래서 프로젝트 프로파일이 전역을, 전역이 같은 이름의 내장을 가립니다.

**내장 default**는 크리덴셜, 토큰, 흔한 정부/금융 식별자를 필드 이름으로 덮고(password, client_secret, access_token, api_key, session_id, otp, pin, ssn, card_number, cvv, iban 등) 정규식은 하나도 싣지 않습니다. 기본 제공 패턴이 엉뚱한 것에 걸리면 경고 없이 망가진 보고서가 남지만, 기본 제공 이름이 엉뚱하게 걸리면 잃는 건 어차피 잃는 편이 나았을 값 하나이기 때문입니다. 예컨대 email에 대해서는 일부러 아무 말도 하지 않습니다. 주소 자체가 발견 내용인 종류의 취약점에서는 그런 기본값이 증거를 망칩니다. 원하는 것은 직접 만든 프로파일에, 눈에 보이는 곳에 넣으세요.

default on은 한 번만 하는 옵트인입니다. 이미 gori run show --format raw를 읽는 스크립트가 있는 설치에서 기본값을 뒤집으면 그 스크립트가 받는 내용이 조용히 달라지므로, gori는 꺼진 채로 출시합니다. 켠 뒤로는 호출마다 --no-redact가 캡처한 바이트로 돌아가는 명시적인 길입니다. 켜져 있으면 TUI의 Space → Y 복사 메뉴와 **MCP get_flow**도 정제합니다. 복사 제목은 COPY REQUEST AS · SANITIZED (3)로 보이고, get_flow는 프로파일 이름과 개수, 그리고 무엇을 보지 않았는지를 담은 body_redaction 객체를 돌려줍니다. MCP의 include_sensitive: true는 헤더 리댁션과 함께 본문 리댁션도 끕니다. 플래그 하나로 두 축을 함께 다룹니다.

자리표시자 태그는 [REDACTED:<16진수 8자리>]이며, 설치마다 한 번 만들어져 settings.json에 보관되는 비밀 키로 값을 HMAC한 결과입니다. 같은 값은 같은 태그를 공유해 보고서 안에서 상관관계를 유지할 수 있고, 태그에서 값을 복원할 수는 없으며, 이 설치 밖에서는 아무 의미가 없습니다. 공장 초기화는 salt를 남깁니다. 버리면 이미 쓴 모든 산출물의 자리표시자가 깨지기 때문입니다. gori settings export --sections redaction은 규칙과 함께 salt도 가져가므로, 규칙만 건네려면 gori run redact profiles --format json을 쓰세요.

gori mcp

MCP stdio 서버입니다. 도구 세부사항은 MCP 가이드를 참고하세요.

--install-*은 한 번에 여러 개 지정할 수 있습니다. 클라이언트마다 따로 설정하고 따로 보고하며, 하나가 실패해도 나머지는 그대로 진행됩니다. 커맨드라인의 다른 플래그(--db, --project, --no-project, --use-active-project, --read-only, --tools, --pin-project, --insecure-upstream, 전역 --config)는 모두 설치되는 커맨드에 기록되고, 경로는 절대 경로로 바뀝니다(--project는 이름 그대로 기록). 기존 설정 파일은 제자리에서 갱신됩니다. 다른 항목·테이블·주석은 유지되고, 권한도 보존되며, 교체는 원자적입니다.

gori ca

gori ca
gori ca --pem
gori ca --ca-dir=DIR
gori ca regenerate
gori ca regenerate --yes
gori ca import --cert root.crt.pem --key root.key.pem --yes

gori 루트 CA 인증서의 경로를 출력합니다(최초 사용 시 생성). 브라우저나 시스템 저장소에서 CA를 신뢰시킬 때, 또는 클라이언트에 --cacert를 지정할 때 사용하세요.

동사(verb)를 먼저 쓰고 플래그를 그 뒤에 씁니다. gori ca --ca-dir=DIR regenerate가 아니라 gori ca regenerate --ca-dir=DIR입니다. 반대 순서는 사용법 오류로 처리합니다. 그러지 않으면 동사가 버려진 채 CA 경로만 출력되어 작업이 수행된 것처럼 보이기 때문입니다. 세 가지 형태 모두 위치 인자를 받지 않습니다.

gori ca는 로드는 되지만 사용할 수 없는 루트 CA(인증서와 일치하지 않는 개인 키, 또는 gori가 서명에 사용할 수 없는 키)도 stderr로 보고합니다. 그렇지 않으면 이 증상은 클라이언트 쪽에서 "unknown CA"나 "bad signature" 핸드셰이크 실패로만 드러나기 때문입니다. 해결책은 regenerate와 import이며, 두 명령은 쌍 중 한 파일만 남은 경우를 포함해 어떤 상태의 CA 디렉터리에서도 동작합니다.

gori ca regenerate

디스크의 루트 CA를 새로 발급한 것으로 교체합니다. 파괴적: 이전 CA를 신뢰하던 모든 클라이언트는 새 인증서를 다시 신뢰해야 합니다. 이미 실행 중인 gori 프로세스는 재시작 전까지 이전 CA를 메모리에 유지합니다.

--yes 없이는 tty에서 프롬프트가 뜨며 regenerate를 입력하도록 요구합니다(TUI 확인과 같은 단어). 스크립트와 CI는 --yes를 전달해야 합니다. 성공하면 새 인증서 경로가 stdout으로 출력됩니다.

gori ca import

외부에서 생성한 루트 CA(인증서 + 일치하는 개인 키, 둘 다 PEM)를 gori 자체 CA 대신 채택합니다. 팀이나 여러 머신에서 하나의 CA를 공유하거나, 조직 CA를 재사용하기 위해서입니다. gori는 호스트별 리프 인증서를 즉석에서 서명하므로 두 파일이 모두 필요합니다. 클라이언트는 인증서만 신뢰합니다. regenerate처럼 파괴적이며, 디스크의 루트를 교체하고 기존 신뢰를 무효화합니다.

무엇이든 디스크에 기록하기 전에 쌍을 먼저 검증합니다: 키는 인증서와 일치해야 하고, 인증서는 CA여야 하며(basicConstraints CA:TRUE), gori가 그 키로 리프 인증서를 서명할 수 있어야 합니다. 마지막 검사 때문에 Ed25519 · Ed448 루트는 거부됩니다. gori는 리프를 SHA-256으로 서명하는데 이 키들은 이를 지원하지 않습니다. 따라서 EC P-256이나 RSA 루트를 사용하세요. 거부된 쌍은 현재 CA를 건드리지 않고 중단합니다. 만료되었거나 아직 유효하지 않은 인증서는 경고만 남기고 그대로 가져옵니다. tty에서 import를 입력하여 확인하거나 --yes를 전달하세요. 같은 동작을 TUI 팔레트(Import CA certificate)에서도 사용할 수 있습니다.

OpenSSL로 루트를 생성한 뒤 가져옵니다:

openssl ecparam -genkey -name prime256v1 -out root.key.pem
openssl req -x509 -new -key root.key.pem -days 3650 -subj "/CN=my ca" -out root.crt.pem
gori ca import --cert root.crt.pem --key root.key.pem --yes

클라이언트에서는 root.crt.pem만 신뢰하세요. 개인 키는 절대 배포하지 마세요.

gori settings

gori settings                      # settings.json 경로 출력
gori settings --edit               # $EDITOR로 열기
gori settings sections             # 최상위 섹션 목록
gori settings export [-o FILE]     # 공유 가능한 프로필 출력(기본 stdout)
gori settings import FILE          # 프로필의 섹션들을 적용
gori settings tls-fingerprint      # 목적지별로 gori가 보내는 JA3/JA4
gori settings env-syntax [VALUE]   # env 토큰 문법 읽기 / 설정
gori settings user-agents          # $GEN.USER_AGENT가 고르는 목록

gori settings env-syntax

env 토큰을 어떤 문법으로 적는지 정합니다. namespaced(환경 변수 $ENV.KEY, 세션 바인딩 $BIND.NAME, 요청마다 새 값을 만드는 생성기 $GEN.NAME) 또는 bare($KEY, $NAME, 생성기 표기 없음)입니다. 모든 프로젝트의 토큰을 어떻게 읽을지 결정하므로 전역 설정입니다. 인자 없이 실행하면 지금 적용된 값과 그 출처를 출력합니다.

gori settings env-syntax
# namespaced  (from /Users/me/.gori/settings.json)
#   $ENV.KEY / $BIND.NAME / $GEN.UUID

gori settings env-syntax bare
# env syntax: bare — $KEY / $NAME
# Each project is re-spelled the next time it opens: its stored tokens are rewritten from
# namespaced to bare, a backup is written beside the database, and the run that does it says
# so. Captured evidence is left exactly as it was. Switch back with `gori settings env-syntax namespaced`.

문법은 모두에게 namespaced입니다. 그래서 settings.json에 env.syntax가 없다는 것은 그 파일이 네임스페이스보다 먼저 쓰였다는 뜻입니다. 다음 시작에서 namespaced를 채택하고, 전역 재작성 규칙을 다시 적고(settings.json.pre-namespaced-<타임스탬프> 복사본을 남깁니다), 키를 파일에 씁니다. 각 프로젝트는 문법이 바뀐 뒤 처음 열릴 때 다시 적힙니다. TUI든, 아무 gori run …이든, gori mcp 서버든 마찬가지입니다. 데이터베이스 옆에 gori.db.pre-<grammar>-<타임스탬프> 백업(VACUUM INTO이므로 WAL까지 포함)을 쓰고, 토큰 몇 개가 옮겨졌는지 프로젝트마다 한 줄씩 stderr로 알려 줍니다. 다시 적는 대상: Repeater 초안(request, target, SNI, 이름)과 그 WebSocket 메시지, Fuzzer 템플릿, Miner·Sequencer 요청, 재작성 규칙의 치환 텍스트, 세션 슬롯 헤더 값, 그리고 이슈 제목·메모와 노트 본문에 마스킹된 토큰입니다. 그대로 두는 것: 출처가 캡처인 모든 행(flow_id가 있는 행이며, 캡처는 확장되지 않습니다), 대상 문법에 같은 바이트를 보내는 표기가 없는 행, 그리고 토큰이 아니라 테이블 키인 이름들(환경 변수, extract 규칙, 규칙 패턴, 페이로드 세트)입니다.

env.syntax = bare가 옵트아웃이며, 각 프로젝트는 다음에 열릴 때 되돌려 다시 적힙니다. 이때 그대로 두면 해석되기 시작할 리터럴 $NAME은 이스케이프됩니다. 환경 변수를 참고하세요. gori settings import는 프로필의 env.syntax가 이 설치와 다르면 stderr로 알려 줍니다. 임포트는 문법을 바꾸지 않습니다.

gori settings user-agents

$GEN.USER_AGENT가 고르는 목록입니다. 플래그 없이 실행하면 출처를 밝히는 # 줄 아래에 현재 쓰는 목록을 출력합니다. --set은 같은 형식을 그대로 읽으므로, 출력을 저장해 고친 뒤 다시 설정할 수 있습니다. --set은 파일의 줄로 내장 목록을 대체합니다. 한 줄에 User-Agent 하나이며, 빈 줄과 # 줄은 건너뜁니다. 헤더에 넣을 수 없는 줄이 하나라도 있으면 파일 전체를 거절하고 아무것도 바꾸지 않습니다. --reset은 내장 목록으로 되돌립니다.

gori settings user-agents > ua.txt       # 현재 쓰는 목록
gori settings user-agents --set ua.txt   # 내장 목록 대체
generator | gori settings user-agents --set -
gori settings user-agents --reset        # 내장 목록으로 되돌리기

settings.json에는 user_agents로 저장되며, TUI에서는 Preferences → Editor & Keys → User-Agents에서 편집합니다.

프로필

export와 import는 설정을 다른 머신으로 옮기거나, 팀과 공유하거나, 재현 가능한 실행을 위해 저장소에 커밋할 때 씁니다. 단위는 최상위 섹션이며 목록은 gori settings sections로 확인합니다.

gori settings export --sections network,scan_rules -o team-profile.json
gori settings import team-profile.json --dry-run     # 무엇이 적용될지 미리 보기
gori settings import team-profile.json --sections network

gori settings sections는 gori가 아는 모든 섹션을 나열하고, 이 설치본에 아직 값이 없는 것을 표시합니다:

…
statusline  (can carry commands)
…
network
…
editor  (can carry commands)
…
env  (holds secrets — excluded unless named; not set — at its default)
scan_rules  (can carry commands; not set — at its default)
…
decoder  (holds secrets — excluded unless named; can carry commands; not set — at its default)
rewriter  (can carry commands)
…

not set으로 표시된 섹션도 --sections에 쓸 수 있는 정상적인 이름입니다. export하면 담을 값이 없을 뿐이고(그 사실을 stderr로 알려줍니다), import하면 그 섹션이 처음으로 기록됩니다.

선택하지 않았거나 프로필에 없는 섹션은 그대로 남습니다. --sections가 고르는 것이 바로 이 경계입니다. 프로필이 실제로 담고 있는 섹션 안에서는:

• 리스트/테이블 섹션은 통째 교체됩니다: upstream_rules, outbound_tls, listeners, scan_rules, hostname_overrides, tabs 등. "upstream_rules": []를 담은 프로필은 테이블을 비웁니다. "규칙 없음"을 그렇게 표현합니다.
• 스칼라 오브젝트 섹션은 키 단위로 적용됩니다: network, editor, probe. 프로필이 생략한 키는 현재 값을 유지하므로, network.upstream_proxy만 지정한 팀 프로필이 언급한 적도 없는 bind_port까지 기본값으로 되돌리지 않습니다.

export는 공장 기본값 상태인 섹션을 아예 쓰지 않으므로, 프로필은 설정 전체의 스냅샷이 아니라 적용할 값들의 묶음입니다. 어떤 값이 기본값인 머신에서 export해도, 그 값이 기본값이 아닌 머신에서 되돌려지지 않습니다. import가 무엇을 건드릴지는 --dry-run으로 확인하세요. 목록에 넣는 쪽으로 넉넉하게 판단하므로, 거기 없는 섹션은 확실히 아무 변화도 없습니다.

import는 TUI와 동일한 저장 경로를 거치므로 원자적 쓰기가 유지되고, 동시에 실행 중인 gori가 건드리지 않은 섹션에 한 편집이나 삭제를 덮어쓰지 않습니다. 파일에 있는 알 수 없는 섹션은 보고하고 무시합니다. 실행 중인 설정에도, 파일에도 반영되지 않습니다.

gori가 settings.json을 읽지 못하는 상태(파싱 실패, 권한 문제, --config가 열 수 없는 대상을 가리키는 경우)라면 export와 import 모두 진행하지 않고 거부합니다. 그 시점의 gori는 모든 섹션이 공장 기본값이므로, import는 프로필이 언급하지 않은 섹션 전부를 기본값으로 디스크에 박고, export는 그 기본값을 원래 설정인 양 파일로 내보내기 때문입니다. 먼저 파일을 고치거나 지우세요. 파싱되지 않은 원본은 옆에 settings.json.corrupt로 보관됩니다. --dry-run은 예외입니다: 아무것도 쓰지 않으므로 그대로 실행되고, 비교 대상이 기본값이라는 사실을 stderr로 알려줍니다.

env, decoder, oast_providers는 export에서 기본 제외됩니다. env는 토큰 값을, decoder는 저장된 체인 라이브러리를(열려 있는 하위 탭은 여기가 아니라 프로젝트 저장소에 있습니다), oast_providers는 자체 호스팅 interactsh 토큰을 담기 때문입니다. 명시적으로 이름을 적는 것(--sections env)이 포함에 대한 동의입니다. upstream_rules는 공유해도 안전합니다. 사용자명과 환경변수 이름만 저장하고 비밀번호는 담지 않습니다.

이 설치의 기존 데이터를 읽는 방식을 정하는 값, 즉 토큰 문법(env.syntax), 토큰 접두사(env.prefix), 리댁션 솔트(redaction.salt)는 프로필에 담기지 않고 import로 바뀌지도 않습니다. import는 로컬 값을 유지하며, 프로필의 문법이나 접두사가 달랐으면 stderr로 알립니다. import한 전역 rewriter 규칙, colormarker 규칙, 저장된 뷰는 이 설치의 카운터로 새 번호를 받으므로, 지워진 로컬 규칙에 대한 프로젝트의 오버라이드가 import한 규칙에 붙지 않습니다.

-o가 실제 사용 중인 settings.json을 가리키면 거부됩니다. export는 스냅샷이 아니므로(기본값 상태인 섹션은 모두 빠지고, env, decoder, oast_providers는 이름을 지정하지 않는 한 빠집니다) 그것을 원본 파일에 되쓰면 해당 섹션이 갱신되는 게 아니라 삭제됩니다.

export가 실제로 그런 섹션을 담게 되면 -o FILE은 0600으로 생성되고, gori가 파일에 무엇이 들어 있는지 이름을 대며 알려줍니다. 자격증명을 export하는 데 동의한 것이 그것을 누구나 읽을 수 있게 두는 데 동의한 것은 아닙니다. 일반 export는 0644로 남고, env 변수가 하나도 없는 설치에서 env를 지정한 export도 일반 export입니다. 권한은 타이핑한 내용이 아니라 문서에 실제로 담긴 것을 따릅니다.

명령을 담은 프로필

다섯 섹션은 데이터가 아니라 명령을 담을 수 있습니다. 다른 설정과 똑같이 export됩니다. 팀이 같은 재서명 훅을 표준으로 쓰는 것이야말로 훅이 존재하는 이유니까요. 대신 양쪽 끝에서 파일에 무엇이 들었는지 말해줍니다.

앞의 셋은 프로세스 훅입니다. 다섯 중 가장 날카로운 건 statusline입니다. argv exec이 아니라 완전한 셸이고, 같은 섹션에 자기 enabled를 들고 있어 프로필 하나로 바로 무장되며, 트래픽 없이 타이머만으로 실행됩니다. editor는 프로필이 값을 지정했을 때만 보고합니다. 비어 있으면 gori는 받는 쪽의 $VISUAL/$EDITOR/vi로 넘어갑니다.

명령을 실행하지는 않지만 같은 방식으로 나열되고 막히는 모양이 둘 더 있으며, env와 file 행으로 표시됩니다. password_env가 있는 upstream_rules 항목(gori가 내 머신에서 그 변수를 읽어 프로필이 지정한 프록시로 보냅니다)과 body_file이 있는 rewriter short-circuit(매칭된 호스트의 페이지에 로컬 파일을, respond: dir이면 디렉터리를 제공합니다)입니다.

export는 개수를 stderr로 알리고, stdout의 프로필은 깨끗하게 둡니다:

note: 5 entries in this profile run a local command (2 rewriter pipe, 1 scan_rules exec, 1 statusline sh -c, 1 editor exec) — whoever imports it runs them with their own privileges

import는 argv까지 한 줄씩 나열하고, 확인을 받기 전까지 쓰지 않습니다. --dry-run도 같은 목록을 출력하며 어느 쪽이든 아무것도 쓰지 않습니다:

$ gori settings import team-profile.json
5 entries in this profile run a local command here, with your privileges:
  rewriter pipe     resign body    ./resign.sh --key $TOKEN
  rewriter pipe     (unnamed)      /usr/local/bin/hmac  [disabled]
  scan_rules exec   leak detector  ./detect.py
  statusline sh -c  command        gori-status --project
  editor exec       command        nvim
importing them is the same trust decision as running the author's script
gori settings import: refused — the 5 entries listed above run a local command with your privileges. Read them, then pass --allow-commands. Nothing was written.

명령을 읽고 나서 --allow-commands를 주세요. 대화형 프롬프트가 없으므로 스크립트에서 실행하는 import는 그대로 스크립트로 남습니다. 그 플래그 자체가 확인 절차입니다. 프로필이 담고는 있지만 꺼둔 항목은 [disabled]로 표시됩니다. 누군가 켜기 전까지는 아무것도 실행하지 않지만, 파일에는 여전히 들어 있습니다. --sections로 범위를 좁히면 이 판단도 함께 좁아집니다. network만 적용하는 import는 아무것도 무장시키지 않으므로 항목을 나열하지도, 플래그를 요구하지도 않습니다.

gori settings tls-fingerprint

gori가 실제로 보내는 ClientHello의 JA3/JA4 지문을 목적지별로 출력합니다. Cloudflare·Akamai·DataDome·PerimeterX 같은 안티봇이 챌린지를 띄울지 판단할 때 읽는 바로 그 offer입니다. outbound_tls의 지문 필드를 검증하는 수단입니다. OpenSSL은 협상 결과만 알려줄 뿐 무엇을 제안했는지는 알려주지 않으므로, 이 명령이 없으면 설정이 먹혔는지 확인할 방법이 없습니다.

gori settings tls-fingerprint                    # 모든 규칙 + 규칙 없음 기본값
gori settings tls-fingerprint shop.example.com   # 그 호스트가 실제로 받는 정책 하나
gori settings tls-fingerprint --json             # 원본 목록까지 담은 기계 판독용 출력

# …그리고 per-send 오버라이드가 대신 무엇을 보낼지. Repeater 탭의 ␣Pt나 `--tls-preset`
# 실행이 적용하는 것과 같은 좁히기를, settings.json을 건드리지 않고 미리 봅니다:
gori settings tls-fingerprint shop.example.com --preset curl

shop.example.com  (matched rule "shop.example.com")
  preset          chrome
  groups          X25519:P-256:P-384
  …
  tunnelled (gori offers h2) — ALPN h2, http/1.1
    JA3  c99e92e692ba483e2602b38b3c0a5645
         771,4865-4866-…,65281-0-11-10-35-5-16-22-13-43-45-51-21,29-23-24,0
    JA4  t13d1513h2_8daaf6152771_afafd945c4ab
         t13d1513h2_002f,0035,…_0005,000a,…_0403,0804,…

정책마다 두 개의 leg를 보여주며, 둘의 차이는 실재합니다. gori는 복호화하는 MITM 연결에서는 h2를 제안하고, 자신이 HTTP/1.1을 말하게 될 leg(포워드 프록시 dial, Repeater, WebSocket)에서는 제안에서 h2를 빼며, alpn을 설정하지 않았다면 ALPN 확장 자체를 보내지 않습니다. 그래서 두 leg의 ClientHello가 다릅니다. 각 다이제스트 아래 줄은 그 다이제스트가 해시한 목록입니다. 어떤 필드가 움직였는지는 거기서만 보이고, 브라우저와 비교할 가치가 있는 쪽도 이쪽입니다.

리포트가 읽는 컨텍스트는 실제 dial이 만드는 것과 같은 객체이므로, gori가 하지 않는 핸드셰이크를 설명할 수 없습니다. 이 OpenSSL이 거부하는 groups/sigalgs 문자열은 해당 규칙에 대해 stderr로 보고하고 나머지는 계속 출력합니다.

--preset NAME은 보고되는 모든 정책을 per-send 오버라이드와 똑같이 좁혀서 출력합니다(전송 단위 TLS 지문 참고). 이미 chrome 규칙이 걸린 호스트에 --tls-preset curl이 실제로 무엇을 실어 보낼지 확인할 때 씁니다. 클라이언트 인증서·프로토콜 범위·permissive는 목적지 것이 그대로 남고, ClientHello 모양만 교체됩니다. 모르는 이름은 빈 hello로 보고하지 않고 거부합니다.

전송 단위 TLS 지문

outbound_tls는 목적지 호스트로만 키가 잡힙니다. 상시 정책에는 맞지만, 지문 기능이 존재하는 이유인 질문, **이 엔드포인트가 chrome일 때와 curl일 때 다르게 답하나?**에는 맞지 않습니다. 그건 같은 호스트에 대한 A/B이고, 전송 사이에 전역 규칙을 고쳐서 하면 두 전송이 비교 불가능해질 뿐 아니라 그 호스트로 가는 다른 모든 탭과 백그라운드 캡처의 핸드셰이크까지 바뀝니다.

per-send 오버라이드는 목적지 테이블을 건드리지 않고 전송 하나 또는 실행 하나에 대해 프리셋을 지정하며, dial 시점에 해석됩니다:

gori run repeater 42 --tls-preset chrome           # 캡처한 플로우를 Chrome처럼 재전송
gori run repeater 42 --tls-preset curl             # …그리고 curl로 한 번 더, 비교 가능하게
gori run repeater send 7 --tls-preset firefox      # 저장된 세션을 이번 전송만 덮어쓰기
gori run repeater create --tls-preset chrome …     # 세션에 저장
gori run fuzz --flow 42 --auto --tls-preset chrome # 스윕 전체를 한 핸드셰이크로

TUI에서는 Repeater 탭의 ␣Pt(TARGET 밴드의 ␣Pt:… 칩)이고, 탭과 함께 영속화되므로 다시 연 탭은 이전에 보낸 지문 그대로 보냅니다. Fuzzer는 ^O 고급 카드의 TLS fingerprint 행입니다. MCP는 send_request{tls_preset}와 fuzz_start{tls_preset}이며, 결과 세트가 어느 핸드셰이크에서 나왔는지 말할 수 있도록 그대로 되돌려 줍니다.

오버라이드는 목적지 정책을 통째로 갈아치우는 게 아니라 좁힙니다:

오버라이드만 다른 두 전송은 서로 다른 SSL 컨텍스트로 연결하므로 실제로 핸드셰이크도 두 번입니다. https 전용입니다. 평문 구간은 ClientHello를 보내지 않고, gori는 보내지 않은 것을 보고하지 않습니다. 목적지 단위 프리셋과 마찬가지로 이것들은 근사치입니다(확장 순서와 GREASE 배치는 OpenSSL의 것). 가정하지 말고 gori settings tls-fingerprint HOST --preset NAME으로 확인하세요.

--config PATH

--config는 이번 실행에 쓸 설정 파일을 지정합니다. 서브커맨드 앞에 옵니다.

gori --config ./ci-profile.json run capture --for 5m
gori --config ~/profiles/corp.json          # 다른 설정으로 TUI 실행

우선순위는 --config → $GORI_CONFIG → $GORI_HOME/settings.json입니다.

이 플래그는 의도적으로 GORI_HOME과 직교합니다. 읽고 쓸 설정 파일만 바꾸고 CA, 프로젝트 DB, 테마, 워드리스트는 그대로 둡니다.

gori wizard

gori wizard

대화형 설정(전역 프록시 바인드 기본값, 테마, Miss Ring 마스코트, 그다음 에디터 키셋과 바꾸는 곳까지 알려 주는 요약)을 실행합니다. 최초 실행 시에도 자동으로 실행됩니다. 바인드 단계는 공유 settings.json 기본값을 기록하며, 선택한 포트에 이미 다른 프로세스가 열려 있으면 경고합니다(Enter를 한 번 더 누르면 그대로 유지). 프로젝트는 Project 탭에서 자체 주소를 고정할 수 있으며, --listen / --port는 이번 실행에 한해서만 오버라이드합니다. Esc를 두 번 누르면 마법사를 건너뛰고, 각 행은 클릭으로도 선택할 수 있습니다.

gori tutorial

gori tutorial

목업 UI에서 TUI를 대화형으로 둘러봅니다: 탭/패널 탐색(서브탭 줄 포함), space 메뉴(Space)와 두 번째 카드, 커맨드 팔레트 검색(Ctrl-P), READ/INS 편집 모드, 클라이언트를 어디로 향하게 하고 CA를 어떻게 신뢰시키는지, 캡처 스위치, 인터셉트(편집기 밖의 i), 도움말과 종료. 목업 메뉴와 투어가 언급하는 모든 키는 설치된 gori에서 읽어 옵니다. 각 레슨은 동작을 시연하고 직접 해 보도록 안내하며, 단계 표시줄의 ✓는 동작을 끝까지 해냈을 때만 켜집니다(◐는 들르기만 한 단계). 연습 단계에는 앞의 네 가지 동작에 걸친 선택적 확인 항목 여섯 개가 있습니다. 마지막 카드는 투어를 마친 뒤 이어질 프로젝트 선택 화면, --db 프로젝트(열기에 실패하면 선택 화면), 셸, 현재 세션에 맞는 다음 단계를 안내하고, 단독으로 실행한 gori tutorial을 마치면 다음에 실행할 명령을 출력합니다. gori wizard 끝에서 제공되고, 세션 안에서는 팔레트 명령 Guided tour(Ctrl-P)로 열 수 있습니다. 실제 프록시 세션 없이도 언제든 안전하게 다시 실행할 수 있습니다. 빠른 시작과 space 메뉴와 팔레트를 참고하세요.

gori update

gori update
gori update --exec   # Homebrew/Snap: 패키지 매니저 명령 실행

이 gori 바이너리가 어떻게 설치되었는지 감지하여 그에 맞게 업데이트합니다:

스토어 경로란 /nix/store/…뿐 아니라 옮겨진 스토어도 포함합니다. 루트 없이 설치하면 스토어가 ~/.local/share/nix/root 아래에 놓이고, NIX_STORE_DIR로 어디로든 옮길 수 있습니다. 기본 접두사를 벗어나면 스토어 해시의 형태로 판별하므로, 사용자가 우연히 nix/store라고 이름 붙인 디렉터리는 그대로 일반 바이너리 설치로 분류됩니다.

/usr/bin 또는 /bin 아래 경로는 패키지 소유권(pacman -Qo, dpkg-query -S, rpm -qf)으로 분류됩니다. 관리자가 파일을 소유하면 gori는 절대 덮어쓰지 않습니다. 프로브가 소유자를 찾지 못하면 바이너리 채널이 자체 업데이트합니다. 패키지 도구가 전혀 없으면 /etc/os-release(ID / ID_LIKE)로 Arch 계열 / Debian 계열 / RHEL 계열 안내를 폴백으로 고릅니다.

릴리스 자산 이름은 설치 가이드와 일치합니다(gori-v*-linux-* 순수 바이너리, gori-v*-osx-*.tar.gz 아카이브). macOS 아카이브 업데이트는 전용 레이아웃(예: curl 설치 프로그램의 PREFIX/opt/gori)을 요구하여 번들된 lib/가 /usr/local/lib 같은 공유 루트 아래에 절대 기록되지 않도록 합니다. 아직 릴리스 자산이 없으면 명령은 릴리스 페이지를 가리키는 명확한 오류로 종료합니다. 조용히 아무 동작도 하지 않는 것이 아닙니다.