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 host को पिन करता है)।

क्विकस्टार्ट

प्रत्येक कमांड एक JSON ऑब्जेक्ट प्रिंट करता है — आर्ग्युमेंट त्रुटियाँ भी शामिल: {"ok":true,"data":…,"meta":…} या {"ok":false,"error":…}। इसे पढ़ने के लिए --pretty जोड़ें; विफलता पर एग्ज़िट कोड गैर-शून्य होता है।

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 पर इंगित करें — 25 टूल्स जो समान {ok,data,meta} एनवेलप लौटाते हैं, stdio पर JSON-RPC।

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

यह क्या करता है

• डीकंपाइल — एक ऑप्टिमाइज़िंग SSA डीकंपाइलर (Memory-SSA, phi-web वेरिएबल कोलेसिंग, पूर्ण SSA विनाश, सटीक ब्रांच शर्तें) जिसका ऑप्टिमाइज़र अपने द्वारा किए गए प्रत्येक रीराइट की रिपोर्ट करता है (--explain: कौन सा सब-पास क्या बदला, किस पते पर), न कि ब्लैक-बॉक्स उत्तर।
• लाइव मेमोरी स्कैन करें — स्नैपशॉट-समर्थित नैरोइंग, फ़्रीज़, कोड-केव हुक्स के साथ वैल्यू/पॉइंटर/AOB स्कैनिंग। पूरा स्कैन → नैरो → फ़्रीज़ → पैच लूप।
• देखें और समझाएँ — सॉफ़्टवेयर / हार्डवेयर / कंडीशनल ब्रेकपॉइंट और एक वास्तविक क्रॉस-प्रोसेस अनवाउंड कॉल स्टैक; वह कच्ची सामग्री जिस पर provenance बना है।
• नाम पुनर्प्राप्त करें — दोनों ABIs पर 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-only हैं और ऐसा कहने से इनकार करते हैं। गलत वाला scan dissect था, जिसने एक फ़ील्ड की चौड़ाई उसके एलाइनमेंट से पहले चुनी और इसलिए एक स्ट्रक्चर को उसकी पहली गलती से चार बाइट फेज़ से बाहर पढ़ा: अपने ही स्रोत से ज्ञात लेआउट के विरुद्ध छह में से एक फ़ील्ड सही, बाद में छह में से पाँच।
• Windows 11 — 23 में से 21 जाँच मापी गईं, 0 गलत, टारगेट स्वयं ओरेकल के रूप में। ui focus कंसोल टारगेट पर सही ढंग से कोई विंडो नहीं ढूँढता; stack backtrace Linux-only है — एकमात्र जगह जहाँ Linux एडाप्टर आगे है।

डिकोडर, एक स्वतंत्र डिसअसेम्बलर के विरुद्ध — वह नींव जिस पर बाकी सब खड़ा है, और अब तक केवल उसके ऊपर बने पास द्वारा जाँचा गया था, जो सभी एक ही स्ट्रीम पढ़ते हैं:

• x86: निर्देश सीमाएँ objdump के साथ तुलना की गईं। तीन उद्देश्य-निर्मित आकार सटीक, एक साझा लाइब्रेरी के 20 000 निर्देश और एक 32-बिट सिस्टम DLL के 20 000, शून्य असहमति और शून्य सीमाएँ जो किसी भी पक्ष के पास अकेले थीं। 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%) वास्तविक निर्देशों के साथ जिन्हें यह अस्वीकार करता है (मुख्यतः LSE एटॉमिक्स)। 48 में से तीन को हाथ से डिकोड किया गया और वे वास्तव में UNALLOCATED हैं। वह अंतराल एक बाउंड द्वारा रखा गया है जो विफल हो जाता है अगर यह बढ़े, और यहाँ बताया गया है न कि छोड़ा गया: एक आरक्षित शब्द जिसे निर्देश के रूप में पढ़ा जाए, डेटा को एक विश्वसनीय प्रोग्राम में बदल देता है।

फ़ंक्शन विस्तार, इमेज की अपनी अनवाइंड टेबल और लिंकर की एक्सपोर्ट सूची के विरुद्ध:

• objdump --dwarf=frames से प्रत्येक FDE का start..end पुनर्प्राप्त विस्तार के बराबर — इस मशीन पर 3 787 की तुलना (10 + libc के 3 777), start और end, सटीक; अलग से दो बड़ी लाइब्रेरीज़ पर 15 467 और 14 355 मापे गए।
• फ़ंक्शन सूची द्वारा 0 एक्सपोर्टेड एंट्री पॉइंट छूटे: ओरेकल आकार पर 10 में से 10 और libc की स्कैन की गई विंडो के अंदर 2 323 में से 2 323।

क्रॉस-रेफ़रेंस और कॉल ग्राफ़, एक ऐसे स्रोत की डिसअसेम्बली के विरुद्ध जो यह टूल नहीं है:

• एक सिस्टम C लाइब्रेरी के छह सबसे व्यस्त टारगेट्स में 4 733 संदर्भ — कोई नहीं छूटा और कोई आविष्कृत नहीं, दोनों दिशाओं में। call, tail-call jmp और RIP-relative डेटा संदर्भ प्रत्येक kind द्वारा लेबल किए गए हैं, और प्रत्येक की तुलना objdump जो दिखाता है उससे की गई।
• 100 फ़ंक्शन्स में 304 कॉल साइट — कोई नहीं छूटा और कोई आविष्कृत नहीं, प्रत्येक फ़ंक्शन का विस्तार सिंबल सीमा के बजाय अनवाइंड टेबल से लिया गया, और एक tail call (एक कंडीशनल सहित) को उसके कॉल के रूप में गिना गया जो वह है।
• 100 फ़ंक्शन्स में 464 ब्रांच टारगेट, उनमें से प्रत्येक एक बेसिक ब्लॉक की शुरुआत। स्प्लिटर द्वारा छूटा एक टारगेट दो ब्लॉक्स को जुड़ा छोड़ देता है, इसलिए प्रोग्राम में मौजूद एक एज ग्राफ़ में मौजूद नहीं होता — और इसके ऊपर कुछ भी इसे नोटिस नहीं कर सकता।