क्या AI एजेंट आपके ऐप को रिवर्स-इंजीनियर कर सकते हैं?
REA — Reverse Engineer Anything — एक ओपन-सोर्स MCP सर्वर और कमांड-लाइन टूल है जो किसी कोडिंग एजेंट को पेशेवर रिवर्स-इंजीनियरिंग सॉफ़्टवेयर चलाने देता है: एजेंट को किसी जारी किए गए ऐप या बाइनरी की ओर इंगित करें और यह असली डीकंपाइलरों के साथ कोड का निरीक्षण करता है, किसी फ़ीचर के काम करने के तरीके को स्पेसिफ़िकेशन के रूप में लिखता है, उस फ़ीचर का पुनर्निर्माण करता है, और पुनर्निर्माण की तुलना मूल से करता है। यह अक्टूबर 2026 में GitHub के सबसे तेज़ी से बढ़ते प्रोजेक्टों में से एक बन गया, और यह एक पुराने तथ्य के अर्थशास्त्र को बदल देता है: उपयोगकर्ता की मशीन पर चलने वाली कोई भी चीज़ उस उपयोगकर्ता द्वारा पढ़ी जा सकती है। यह लेख समझाता है कि REA वास्तव में क्या है, यह जिन टूलों के स्टैक को चलाता है, वह वर्कफ़्लो जो इसके आउटपुट को भरोसेमंद बनाता है, और सॉफ़्टवेयर जारी करने वाले डेवलपर को इसके बारे में क्या करना चाहिए।
REA क्या है
REA (रेपो morluto/rea है, MIT-लाइसेंस प्राप्त, npm से rea-agents के रूप में इंस्टॉल किया गया) कोई डीकंपाइलर नहीं है। यह स्वयं कुछ भी डीकंपाइल नहीं करता। यह एक ऑर्केस्ट्रेशन परत है जो Model Context Protocol बोलती है — वही इंटरफ़ेस जिसके साथ इस साइट का एजेंट-तैयारी कार्य वेबसाइट की ओर से निपटता है — और रिवर्स-इंजीनियरिंग ऑपरेशनों को ऐसे टूलों के रूप में उजागर करती है जिन्हें Claude Code, Codex या Cursor जैसा कोडिंग एजेंट कॉल कर सकता है: इस बाइनरी को डिसअसेंबल करो, इस फ़ंक्शन को डीकंपाइल करो, स्ट्रिंग्स की सूची बनाओ, क्रॉस-रेफ़रेंस का अनुसरण करो, साक्ष्य दिखाओ। भारी काम इसके नीचे के इंजन करते हैं, जिन्हें एजेंट उसी तरह चलाता है जैसे कोई मानव विश्लेषक चलाता, सिवाय इसके कि वह संपूर्ण होने का खर्च उठा सकता है।
श्रम का यही विभाजन मुद्दा है। किसी डीकंपाइलर का आउटपुट विशाल और अधिकांशतः उबाऊ होता है; रिवर्स इंजीनियरिंग में दुर्लभ कौशल कभी टूल चलाना नहीं था, बल्कि यह तय करना था कि आगे क्या देखा जाए और यह जानना था कि उत्तर कब सिद्ध हो गया है। REA इंजनों को वर्कफ़्लो निर्देशों के साथ जोड़ता है — एक निर्धारित क्रम में जाँच करो, हर दावे के लिए साक्ष्य दर्ज करो, बताओ कि क्या हल नहीं हो सका — ताकि एजेंट का आउटपुट स्यूडोकोड का ढेर न होकर रसीदों के साथ निष्कर्षों का एक समूह हो। नेटिव बाइनरियों के लिए यह Ghidra, IDA Pro या Hopper को चलाता है; Android पैकेजों के लिए यह JADX को चलाता है; लाइव व्यवहार के लिए यह HAR और mitmproxy कैप्चर पढ़ सकता है। एक इंटरफ़ेस, कई इंजन, और एजेंट सहनशक्ति प्रदान करता है।
स्टैक एक ही मानचित्र में
विश्लेषण का केंद्र। Ghidra NSA का मुफ़्त, Apache-2.0-लाइसेंस प्राप्त डीकंपाइलर है और अधिकांश लोगों के लिए डिफ़ॉल्ट इंजन है; IDA Pro वह व्यावसायिक दिग्गज है जिसे कई पेशेवर अब भी पसंद करते हैं। नया क्या है, वह इन दोनों टूलों में से कोई नहीं बल्कि उनके पुल हैं: GhidraMCP और ida-pro-mcp चल रहे Ghidra या IDA सत्र को MCP के माध्यम से किसी एजेंट के सामने उजागर करते हैं, ताकि एजेंट स्क्रीनशॉट पढ़ने के बजाय सीधे डिसअसेंबली डेटाबेस से प्रश्न पूछ सके। REA उनसे एक स्तर ऊपर बैठता है, इंजन चुनता है और काम का क्रम तय करता है।
मोबाइल और ऐप्स। jadx Android APKs को वापस पठनीय Java में डीकंपाइल करता है; Apktool किसी APK के संसाधनों और smali को खोलता है और उसे पुनः बना सकता है; Frida चल रहे ऐप में इंस्ट्रुमेंटेशन करता है, फ़ंक्शनों के निष्पादित होते समय उन्हें हुक करता है — वह गतिशील आधा हिस्सा जिसे स्थैतिक डीकंपाइलेशन नहीं देख सकता; और ILSpy .NET असेंबलियों के लिए वही करता है जो jadx APKs के लिए करता है। (किसी APK के कोड के बजाय उसकी घोषणाओं पर बिना इंस्टॉल किए पहली नज़र डालने के लिए, इस साइट का APK Analyzer आपके ब्राउज़र में मैनिफ़ेस्ट, अनुमतियाँ और हस्ताक्षर प्रमाणपत्र पढ़ता है।)
बाइनरी और निम्न-स्तर। radare2 और उसका अधिक अनुकूल फ़ोर्क rizin स्क्रिप्ट-योग्य, टर्मिनल-प्रथम रिवर्स-इंजीनियरिंग फ़्रेमवर्क हैं; x64dbg वह Windows डीबगर है जिसकी ओर अधिकांश विश्लेषक रुख करते हैं; ImHex फ़ाइल स्वरूपों का वर्णन करने के लिए पैटर्न भाषा वाला एक हेक्स एडिटर है; और angr एक प्रतीकात्मक-निष्पादन इंजन है जो किसी फ़ंक्शन के एक बार चलने के बजाय उसके माध्यम के हर पथ के बारे में तर्क कर सकता है। ये उन प्रश्नों के लिए टूल हैं जिनका उत्तर डीकंपाइलर ख़राब देते हैं: पैक किए गए बाइनरी, अजीब फ़ाइल स्वरूप, “क्या यह इनपुट उस शाखा तक पहुँच भी सकता है”।
नेटवर्क और रनटाइम। mitmproxy किसी ऐप और उसके सर्वरों के बीच बैठता है और बातचीत को रिकॉर्ड करता है — कई ऐप्स के लिए API ट्रैफ़िक कोड से अधिक समझाता है, और यह वह कैप्चर स्वरूप है जिसे REA मूल रूप से पढ़ता है। dnSpy .NET अनुप्रयोगों को लाइव डीबग और संपादित करता है, और raddebugger Windows के लिए Epic का आधुनिक ग्राफ़िकल डीबगर है। इन सबके चारों ओर मानचित्र हैं: दो चुनी हुई सूचियाँ, awesome-ai-reverse-engineering (एजेंट युग के 122 रेपो, हर एक को पढ़ा और स्कोर किया गया) और REA के लेखक की अपनी awesome-reverse-engineering, नीचे स्रोतों में जुड़ी हुई हैं।
क्लीन-रूम लूप: स्पेसिफ़िकेशन, पुनर्निर्माण, सत्यापन
REA जिस वर्कफ़्लो को प्रोत्साहित करता है वह AI से पुराना है: यह क्लीन-रूम इंजीनियरिंग है, वह अनुशासन जो कभी BIOS को कॉपी किए बिना उसे क्लोन करने के लिए उपयोग किया गया था। एजेंट लक्ष्य की जाँच करता है और SPEC.md लिखता है — सॉफ़्टवेयर क्या करता है, इसका एक स्पेसिफ़िकेशन, सरल भाषा में, हर व्यवहार के साक्ष्य के साथ संलग्न। उसके बाद ही पुनर्निर्माण शुरू होता है, डीकंपाइल किए गए कोड से नहीं बल्कि स्पेसिफ़िकेशन से, और पुनर्निर्माण का मूल्यांकन स्वीकृति मानदंडों के आधार पर किया जाता है: वही इनपुट, वही आउटपुट, वही किनारे के मामले। जहाँ न्यायाधीश नहीं कहता है, वहाँ लूप अंदाज़े की ओर नहीं बल्कि साक्ष्य की ओर लौटता है — और फिर से जाँच करता है।
इसीलिए दिलचस्प कलाकृति स्पेसिफ़िकेशन है, स्यूडोकोड नहीं। साक्ष्य के साथ कोई स्पेसिफ़िकेशन दूसरे एजेंट, टेस्ट सूट या मानव द्वारा जाँचा जा सकता है; कोई कच्चा डीकंपाइलेशन इनमें से कुछ भी नहीं है। यह कानूनी रूप से महत्वपूर्ण कदम भी है: व्यवहार संबंधी स्पेसिफ़िकेशन से पुनर्निर्माण किसी कार्यान्वयन की नकल करने से अलग कार्य है, इसीलिए यह लूप भावनाओं के बजाय साक्ष्य और मानदंडों पर ज़ोर देता है। एजेंट टूलिंग का मूल्यांकन करने वाले किसी भी व्यक्ति को — रिवर्स इंजीनियरिंग के लिए या किसी और चीज़ के लिए — यह पैटर्न चुरा लेना चाहिए: वितरण-योग्य वस्तु एक सत्यापित दावा है, आत्मविश्वास भरा उत्तर नहीं।
यदि आप सॉफ़्टवेयर जारी करते हैं तो इसका अर्थ
इनमें से कुछ भी क्लाइंट-साइड कोड को गुप्त नहीं बनाता; यह कभी था ही नहीं। यह उसे पढ़ना सस्ता बनाता है। Ghidra के साथ कुशल विश्लेषक हमेशा आपके ऐप से API एंडपॉइंट, फ़ीचर फ़्लैग और लाइसेंसिंग तर्क निकाल सकता था — REA-श्रेणी के टूलिंग का अर्थ है कि एजेंट सब्सक्रिप्शन वाला कोई जूनियर एक दोपहर में पहला पास कर सकता है। व्यावहारिक परिणाम पुराने ही हैं, अब छोटी समय-सीमाओं के साथ: जारी किए गए बाइनरी में एम्बेड किया गया कोई रहस्य — एक API कुंजी, एक निजी एंडपॉइंट, एकमात्र सच्चा छूट नियम — प्रभावी रूप से प्रकाशित हो चुका है; ऑबफ़स्केशन पढ़ने की लागत बढ़ाता है लेकिन यह एक देरी है, बाधा नहीं; और वह सब कुछ जिसकी गोपनीयता पर आपका व्यवसाय निर्भर करता है, उसे ऐप में नहीं बल्कि प्रमाणीकरण के पीछे, आपके सर्वर पर रहना चाहिए।
बचाव भी उतने ही अग्लैमरस हैं और वे काम करते हैं: रहस्यों और मूल्य-निर्धारण/लाइसेंसिंग निर्णयों को सर्वर-साइड रखें, स्थायी कुंजियों के बजाय अल्पकालिक, सीमित-दायरे वाले टोकन जारी करें, जहाँ जोखिम उचित ठहराता हो वहाँ प्लेटफ़ॉर्म सत्यापन (Play Integrity, App Attest) का उपयोग करें, और दुरुपयोग नियंत्रण डिज़ाइन करते समय मान लें कि आपके क्लाइंट का व्यवहार पूरी तरह से अवलोकन योग्य है। यह इस साइट के एजेंट-तैयारी पाठ का दर्पण प्रतिबिंब है: वहाँ, मुद्दा यह था कि एजेंट आपकी वेबसाइट की मशीन-उन्मुख सतह को पढ़ते हैं चाहे आपने उसे डिज़ाइन किया हो या नहीं; यहाँ, एजेंट आपके ऐप की बाइनरी को उसी तरह पढ़ते हैं। दोनों ही मामलों में, जीतने वाली चाल यह है कि जानबूझकर तय किया जाए कि मशीन-उन्मुख सतह क्या कहती है।
वैध उपयोग — और सीमाएँ
रिवर्स इंजीनियरिंग के सम्मानजनक, स्थापित उपयोग हैं, और REA का अपना दस्तावेज़ीकरण उसी सूची का नाम देता है: अपने स्वयं के सॉफ़्टवेयर का विश्लेषण (उस प्रति सहित जिसका स्रोत आप खो चुके हैं), सुरक्षा अनुसंधान और भेद्यता विश्लेषण, मैलवेयर और घटना जाँच, अंतरसंचालनीयता — अपने उत्पाद को दूसरे के साथ काम करने योग्य बनाना —, CTF प्रतियोगिताएँ, और शिक्षा। कई न्यायक्षेत्रों में इनमें से कुछ उन लाइसेंस खंडों के विरुद्ध भी संरक्षित हैं जो उन्हें प्रतिबंधित करने का दावा करते हैं, विशेष रूप से अंतरसंचालनीयता और सद्भावपूर्ण सुरक्षा अनुसंधान, यद्यपि विवरण भिन्न होते हैं और यह लेख कानूनी सलाह नहीं है।
सीमाएँ भी उतनी ही स्पष्ट हैं। टूलिंग पर MIT लाइसेंस लक्ष्य पर लाइसेंस नहीं है: यह किसी प्रतियोगी के उत्पाद को उसकी बाइनरी से क्लोन करने, DRM या लाइसेंस प्रवर्तन को पराजित करने, या आप जो निकालते हैं उसे वितरित करने का अधिकार नहीं देता। पिछले खंड का क्लीन-रूम लूप ठीक इसी लिए मौजूद है कि पुनर्निर्माण को उस रेखा के सही ओर रखा जाए — व्यवहार और साक्ष्य, नकल किया गया कार्यान्वयन नहीं। इस साइट के स्वयं के विश्लेषण टूल लघु रूप में वही रेखा अपनाते हैं: स्थैतिक, स्थानीय, केवल-पठनीय, कोई निष्पादन नहीं, कोई परिहार नहीं — एक पहली नज़र, भारी और कानूनी रूप से संवेदनशील काम उन टूलों और लोगों पर छोड़ दिया गया है जो इसकी ज़िम्मेदारी ले सकते हैं।
इसे स्वयं आज़माएँ
REA को Node.js 22 या बाद के संस्करण की आवश्यकता है; एक ही कमांड — npx rea-agents setup — इसके MCP सर्वर को उन कोडिंग एजेंटों के साथ पंजीकृत करता है जिन्हें यह पाता है और मेल खाते वर्कफ़्लो निर्देश इंस्टॉल करता है, और REA का अपना doctor कमांड हर इंजन की जाँच करता है (नेटिव बाइनरियों के लिए Ghidra जैसा नेटिव इंजन इंस्टॉल होना चाहिए; JADX APKs को कवर करता है)। इसे ऐसे सॉफ़्टवेयर की ओर इंगित करें जिसका आप स्वामित्व रखते हैं या ऐसे नमूने की ओर जिसका निरीक्षण करने की आपको अनुमति है — आपके द्वारा लिखा गया एक छोटा उपयोगिता प्रोग्राम उत्तम पहला लक्ष्य है — और इससे पूछें कि कोई फ़ीचर कैसे काम करता है। कोई भी स्यूडोकोड पढ़ने से पहले इसके द्वारा निर्मित स्पेसिफ़िकेशन पढ़ें: साक्ष्य के लिंक ही वह जगह हैं जहाँ सच्चाई है।
यदि आप पहले कदम का शून्य-इंस्टॉल संस्करण चाहते हैं, तो यही वह है जिसके लिए इस साइट का Binary File Inspector है: किसी PE, ELF या Mach-O फ़ाइल को पृष्ठ पर छोड़ें और अपने ब्राउज़र में उसके हेडर, सेक्शन, इंपोर्ट और स्ट्रिंग्स पढ़ें — कोई अपलोड नहीं, कोई निष्पादन नहीं, कोई टूलचेन नहीं। यह कुछ भी डीकंपाइल नहीं करेगा, और यह ऐसा कहता भी है; यह पाँच मिनट का ट्राइएज है जो आपको बताता है कि क्या पूर्ण REA उपचार स्थापित करना उचित है, और किस इंजन के लिए।
स्रोत और आगे पढ़ना
- REA — morluto/rea (GitHub)
- Ghidra — NationalSecurityAgency/ghidra (GitHub)
- GhidraMCP — LaurieWired/GhidraMCP (GitHub)
- ida-pro-mcp — mrexodia/ida-pro-mcp (GitHub)
- jadx — skylot/jadx (GitHub)
- Apktool — iBotPeaches/Apktool (GitHub)
- Frida — frida/frida (GitHub)
- mitmproxy — mitmproxy/mitmproxy (GitHub)
- awesome-ai-reverse-engineering — zhuyansen (GitHub)
- awesome-reverse-engineering — morluto (GitHub)