N0xis

실행 중인 프로세스의 하드웨어 워치포인트에서 값을 변경한 정확한 디컴파일된 명령문까지.

메모리 스캐너는 주소를 찾는다. 디컴파일러는 코드를 설명한다. N0xis가 이 둘을 연결한다.

$ n0x provenance trace --pid 9348 --addr 0x7ff68bef3010 --kind write

"function_va": "0x7ff68bef1580",          // containing function, auto-resolved
"decompiled_context": [
  "rax.2 = (*(uint32_t*)(0x7ff68bef3010) - 0x1);",
  "*(uint32_t*)(0x7ff68bef3010) = rax.2;"  // ← the statement that moved your value
]

이것은 소스의 hp -= 1;이며, 실행 중인 프로세스에서 복원된 것이다 — 감시된 주소가 해당 명령문에 나타난다. Windows 와 Linux에서 검증되었다.

"이것에 접근하는 것을 찾기" 스캔은 보통 원시 디스어셈블리 라인에서 멈추고, 디컴파일러는 보통 라이브 워치포인트 입력을 전혀 갖지 않는다. 이것은 그 두 반쪽을 연결한 것이다: 워치포인트 히트가 파일을 디컴파일하는 것과 동일한 SSA 파이프라인을 통해 해석된다.

설치

Linux와 Windows용 사전 빌드된 바이너리 — 최신 릴리스.

curl -LO https://github.com/Structio-labs/N0xis/releases/latest/download/n0xis-linux-x86_64
chmod +x n0xis-linux-x86_64 && ./n0xis-linux-x86_64 --version

또는 직접 빌드: cargo build --workspace --release (Windows와 Linux; MSVC Build Tools 불필요 — rust-toolchain.toml이 gnu 호스트를 고정한다).

빠른 시작

모든 명령은 하나의 JSON 객체를 출력한다 — 인자 오류도 포함: {"ok":true,"data":…,"meta":…} 또는 {"ok":false,"error":…}. 읽으려면 --pretty를 추가하라; 실패 시 종료 코드는 0이 아니다.

n0x doctor                                                    # environment check
n0x profile --file game.exe                                   # triage: sections, exports, engine hints
n0x function discover --file game.exe --pdata                 # exact .pdata discovery
n0x decomp pseudo --file game.exe --addr 0x140012a00 --style ssa --pretty
n0x provenance trace --pid 4821 --addr 0x1a2b3c40 --kind write --pretty

동일한 명령이 라이브 --pid, 정적 --file, 캡처된 --snapshot, 또는 SSH를 통한 원격 프로세스에서 실행된다. 이것은 평범한 Unix 배관이다 — n0x function discover --file game.exe --pdata | jq -r '.data.functions[].va'가 다음 명령에 입력을 공급한다. n0x guide는 113개 명령을 모두 나열하며, 바이너리에서 생성되므로 절대 어긋나지 않는다 — 그리고 이 숫자가 틀리면 테스트가 빌드를 실패시킨다.

에이전트에서: 아무 MCP 클라이언트든 n0xis-mcp를 가리켜라 — 동일한 {ok,data,meta} 봉투를 반환하는 25개 도구, stdio를 통한 JSON-RPC.

{ "mcpServers": { "n0xis": { "command": "/path/to/n0xis-mcp" } } }

무엇을 하는가

• 디컴파일 — 최적화 SSA 디컴파일러(Memory-SSA, phi-web 변수 병합, 완전한 SSA 파괴, 정확한 분기 조건)로, 옵티마이저가 수행한 모든 재작성을 보고한다 (--explain: 어느 서브 패스가 무엇을, 어느 주소에서 변경했는지), 블랙박스 답변이 아니다.
• 라이브 메모리 스캔 — 스냅샷 기반 좁히기, 고정, 코드 케이브 후크를 갖춘 값/포인터/AOB 스캐닝. 전체 스캔 → 좁히기 → 고정 → 패치 루프.
• 감시 & 설명 — 소프트웨어 / 하드웨어 / 조건부 브레이크포인트와 실제 크로스 프로세스 언와인드된 호출 스택; 프로버넌스가 기반으로 삼는 원재료.
• 이름 복원 — 두 ABI 모두에서 RTTI로부터 C++ 클래스 복원(MSVC .rdata 체인과 Itanium _ZTV 심볼), .NET NativeAOT RVA ↔ Namespace.Type.Method, LuaJIT, Bitsquid, IL2CPP — 그래서 스트립된 이미지가 sub_XXXX가 아닌 소스처럼 읽힌다.
• 영속화 & 비교 — .n0xt 테이블, 버전 관리되는 주석, 콘텐츠 주소 지정 캐싱, 함수/버전 비교.

Windows 와 Linux, PE 와 ELF, 하나의 파이프라인 — 정적 파일, 라이브 프로세스, 스냅샷 그리고 원격 타깃이 모두 동일한 패스와 동일한 버전 관리되는 JSON을 통해 흐른다.

코어에는 ML 비결정성이 결코 없다. 데스크톱 GUI는 별도 저장소에 있다: n0xis-gui.

상태

알파. 아래의 모든 주장은 도구 외부의 소스 — 커널, 이미지 자체의 테이블, 또는 타깃 프로세스 자체 — 에 대한 측정이다. 그러한 소스가 없는 곳에서는 그렇게 말한다, 왜냐하면 구현됨과 검증됨은 같은 주장이 아니기 때문이다.

라이브 메모리, 알려진 값을 심는 일회용 타깃에 대하여:

• Linux — 31개 명령 중 29개가 /proc/<pid>/mem에 대해 측정되었고, 하나는 틀렸다가 수정되었다. 나머지 둘은 Windows 전용이며 그렇게 말하며 거부한다. 틀렸던 하나는 scan dissect로, 필드의 폭을 정렬보다 먼저 선택해서 첫 실수부터 구조체를 4바이트 위상 어긋나게 읽었다: 자체 소스에서 알려진 레이아웃에 대해 6개 필드 중 하나만 맞았고, 수정 후 6개 중 5개가 맞았다.
• Windows 11 — 23개 검사 중 21개 측정, 0개 틀림, 타깃 자체를 오라클로 삼아. ui focus는 콘솔 타깃에서 창을 찾지 못하는 것이 맞다; stack backtrace는 Linux 전용 — Linux 어댑터가 앞서 있는 유일한 지점이다.

디코더, 독립적인 디스어셈블러에 대하여 — 다른 모든 것이 그 위에 서 있는 토대이며, 지금까지는 그 위에 세워진 패스들로만 검사되었는데, 그것들은 모두 같은 스트림을 읽는다:

• x86: 명령어 경계를 objdump와 비교. 목적에 맞게 만든 세 가지 형태는 정확했고, 공유 라이브러리 20 000개 명령어와 32비트 시스템 DLL 20 000개 명령어에서 불일치 0개, 그리고 어느 쪽도 단독으로 찾지 못한 경계도 0개. 334 MB 스트립된 브라우저 바이너리의 60 000개 명령어로 확장: 불일치 2개, 둘 다 .text에 내장된 ASCII 문자열 내부로, 참조 자체가 (bad)로 디코딩하는 곳 — 코드가 아니며, 어느 쪽 읽기도 옳지 않다.
• AArch64: 니모닉을 llvm-objdump와 비교(고정 폭 인코딩은 경계를 무의미하게 만든다). 아래 ARM64 항목을 보라.
• AArch64, 컴파일러 출력이 아닌 인코딩 공간: 600개의 결정적 워드를 llvm-mc --mattr=+all과 n0xis가 판정. 241개는 둘 다 명령어라고 부르고, 304개는 둘 다 거부 — 그리고 48개(8.0%)는 n0xis가 명령어로 읽는 예약된 인코딩이며, 7개(1.2%)는 n0xis가 거부하는 실제 명령어(대부분 LSE 원자 연산)이다. 48개 중 3개는 손으로 디코딩했고 진짜로 UNALLOCATED이다. 이 격차는 커지면 실패하는 바운드로 유지되며, 빠뜨리지 않고 여기에 명시한다: 예약된 워드를 명령어로 읽으면 데이터가 그럴듯한 프로그램으로 바뀐다.

함수 범위, 이미지 자체의 언와인드 테이블과 링커의 익스포트 목록에 대하여:

• objdump --dwarf=frames의 모든 FDE의 start..end가 복원된 범위와 동일 — 이 머신에서 3 787개 비교(10 + libc의 3 777), 시작과 끝, 정확; 별도로 두 개의 큰 라이브러리에서 15 467개와 14 355개로 측정됨.
• 함수 목록이 놓친 익스포트된 진입점 0개: 오라클 형태에서 10개 중 10개, 그리고 libc의 스캔된 윈도우 내부에서 2 323개 중 2 323개.

상호 참조와 호출 그래프, 이 도구가 아닌 소스의 디스어셈블리에 대하여:

• 시스템 C 라이브러리의 가장 바쁜 여섯 타깃에 걸쳐 4 733개 참조 — 놓친 것도, 지어낸 것도 없음, 양방향 모두. call, 테일콜 jmp 그리고 RIP 상대 데이터 참조는 각각 kind로 라벨링되며, 각각 objdump가 보여주는 것과 비교되었다.
• 100개 함수에 걸쳐 304개 호출 지점 — 놓친 것도, 지어낸 것도 없음, 각 함수의 범위는 심볼 경계가 아닌 언와인드 테이블에서 가져왔고, 테일 콜(조건부 포함)은 그것이 실제로 그러한 호출로 계산되었다.
• 100개 함수에 걸쳐 464개 분기 타깃, 그 모두가 기본 블록의 시작. 분할기가 놓친 타깃은 두 블록을 융합된 채로 남기므로, 프로그램에 존재하는 엣지가 그래프에는 존재하지 않게 된다 — 그리고 그 위의 어떤 것도 그것을 알아챌 수 없다.

복원된 구조체 필드, 구조체를 배치한 컴파일러에 대하여:

• gcc -g는 모든 멤버의 오프셋을 명시한다; 10개 함수에 걸쳐 15개 복원된 필드 오프셋, 모두 실제 멤버 — 지어낸 것 없음. 의도적으로 단방향이다: 옵티마이저는 필드 접근을 접고 제거하므로, 결코 나타나지 않는 멤버는 놓친 것이 아니라 컴파일러의 소행이다.

정적 분석, 이미지가 선언한 범위와 테이블에 대하여:

• x64 ELF와 PE: 함수 범위 정확, 92 001개 엣지에 걸쳐 CFG 불변식 위반 0개.
• ARM64 — 디코더와 CFG 검증됨, 디컴파일러는 아님. 2 381개 중 2 381개 함수 범위가 심볼 테이블과 정확히 동일, 46 757개 CFG 엣지에 걸쳐 위반 0개. 디코더는 이제 목적에 맞게 빌드된 컴파일러 출력(oracle/arm64.c를 -O2로)에 대해 LLVM 자체의 AArch64 디스어셈블러와 비교 검사된다: 147개 명령어, 147개 공유 주소, 디코딩 실패 0개, 그리고 28개 이름 차이 모두 문서화된 아키텍처 별칭(mov/orr, cmp/subs, b.hs/b.cs, …), 각각은 일괄적으로 용서되지 않고 테스트에 나열된다. AArch64 리프트/SSA는 아직 구축되지 않았으므로, decomp pseudo는 quality: 0.0을 보고하고 asm 노드로 폴백한다. 최적화 디컴파일러는 x64 전용이다.
• 32비트 PE: 422개 중 422개 익스포트된 진입점 발견, 34 149개 엣지에 걸쳐 위반 0개. 예외 테이블이 전혀 없는 32비트 이미지에서, 독립적인 파서가 그것으로부터 읽어낸 3 889개 .eh_frame FDE와 비교 검사: 놓친 것 0개, 모든 범위 정확, 알려진 함수 내부에 있는 항목 0개. 이 규칙은 x64 예외 테이블에 맞서 작성되었고, 그것이 전혀 없는 아키텍처에서도 성립한다.

복원된 시그니처, 질문을 던지기 전에 답이 알려진 여기서 컴파일된 타깃(oracle/)에 대하여:

• 두 x86-64 ABI 모두에서 12개 중 12개 — 매개변수 개수, 각 매개변수가 어느 레지스터 파일로 도착하는지, 그리고 반환 클래스, 혼합 정수/부동소수점 시그니처의 두 순서 모두 포함 (System V와 Win64는 두 인자 레지스터 파일을 서로 다른 규칙으로 센다).
• 32비트 cdecl은 나가는 길에 아리티를 명시하지 않고 레지스터로 아무것도 전달하지 않으므로, 매개변수 목록은 () — 불특정을 뜻하는 C — 로 읽히고, 없다는 주장이 될 (void)가 아니다. 이 리프트가 모델링하지 않는 x87 반환은 void가 아닌 /*unknown*/로 읽힌다. 두 격차 모두 그 이유와 함께 oracle/expect.json에 기록되며, 테스트는 하나가 조용히 닫히면 실패한다, 그래서 기록된 한계가 민간설화로 썩을 수 없다.

복원된 C++ 클래스, 이미지 자체의 타입 디스크립터 문자열에 대하여:

• 32비트 C++ 런타임에서 93개 vtable(이전에는 0개), 두 개의 64비트 런타임에서 97개와 152개, Itanium 경로를 통한 ELF에서 269개 — 그리고 복원된 모든 이름이 이미지 자체의 문자열에 존재, 따라서 어느 것도 지어내지 않았다. 두 MSVC 방언 모두 심어둔 회귀 픽스처 (oracle/rtti32.c, oracle/rtti64.S)를 갖는다, 왜냐하면 여기 어떤 컴파일러도 MSVC RTTI를 내보내지 않기 때문이다.

검증되지 않았고, 주장되지 않음: il2cpp import / symbols는 외부 덤퍼의 인덱스가 필요하다; il2cpp obj / classes는 라이브 관리 프로세스가 필요하다. 버전 관리되는 JSON 계약은 외부 사용자에 의해 실전 검증되지 않았다 — 형태가 바뀔 것으로 예상하라.

문서