talha-nazeef-ahmed/rpc-triageएक शून्य-प्रतीक स्थैतिक विश्लेषण इंजन जो AHP-आधारित जोखिम मॉडल का उपयोग करके विंडोज़ RPC आक्रमण सतह को निकालता है और गणितीय रूप से रैंक करता है।
Static बनाम dynamic, पहले यह पढ़ें। शुरू में dynamic और static विश्लेषण के बीच की रेखा को स्पष्ट करना उचित है: यह टूल अपनी रैंकिंग पूरी तरह से static analysis के माध्यम से करता है। यह बाइनरी से सीधे संकलित MIDL / NDR संरचनाओं को पढ़ता है और कभी भी कुछ निष्पादित नहीं करता है।
Windows RPC आक्रमण सतह के लिए स्टैटिक ट्राइएज। इसे PE बाइनरीज़ के फ़ोल्डर पर इंगित करें; यह उन सभी को ढूँढता है जो RPC सर्वर पंजीकृत करते हैं, संकलित MIDL संरचनाओं से सीधे प्रत्येक इंटरफ़ेस के NDR method signatures, transport bindings और registration flags को पुनर्प्राप्त करता है, और फिर प्रत्येक इंटरफ़ेस को reachability x danger द्वारा रैंक करता है, जिसमें हर स्कोर के साथ पूरी अंकगणितीय रसीद जुड़ी होती है ताकि आप गणित की जाँच हाथ से कर सकें।
मौजूदा RPC टूलिंग आसानी से किसी इंटरफ़ेस की method signatures और उसके registration flags को पुनर्प्राप्त कर सकती है। लेकिन उनमें से कोई भी दोनों को लेकर उस एक प्रश्न का उत्तर नहीं देता जो वास्तव में तय करता है कि आप अपना समय कहाँ बिताते हैं: यह देखते हुए कि मैं इस इंटरफ़ेस तक पहुँच सकता हूँ, और यह देखते हुए कि इसके तरीके इनपुट के रूप में क्या स्वीकार करते हैं, मुझे मशीन पर बाकी सब चीज़ों की तुलना में इसे कितनी तत्काल देखना चाहिए? यही अंतर इस टूल को भरता है।
फ़िल्टर करता है लक्ष्य फ़ोल्डर को ताकि Ghidra केवल उन बाइनरीज़ का ऑटो-विश्लेषण करे जो वास्तव में RPC सर्वर पंजीकृत करती हैं (वे rpcrt4.dll import करती हैं और RpcServerRegisterIf\* APIs में से एक को कॉल करती हैं)। System32 पर यह एक दोपहर और एक सप्ताह के बीच का अंतर है।
निकालता है, प्रति इंटरफ़ेस: UUID, RPC_SERVER_INTERFACE / MIDL_SERVER_INFO श्रृंखला, आधिकारिक DispatchTableCount, हर method का opnum + parameter directions + डिकोड किए गए NDR opcodes, registration flags (R9), security-callback ("bouncer") की उपस्थिति, security descriptor (best-effort), और endpoint / transport bindings।
रैंक करता है प्रत्येक स्वच्छ इंटरफ़ेस को दो स्वतंत्र अक्षों पर और उन्हें गुणा करके एक 0-100 समग्र स्कोर में बदलता है, जिसे Critical / High / Moderate / Low में वर्गीकृत किया जाता है।
स्वयं को स्पष्ट करता है: हर स्कोर के साथ एक रसीद स्ट्रिंग होती है जिसमें प्रत्येक घटक और वह अंकगणित सूचीबद्ध होता है जिसने अंतिम संख्या उत्पन्न की।
target dir --(pefile filter) --> only RPC-registering PEs
--(Ghidra headless auto-analysis) --> analyzed program DB
--(extract_rpc_interfaces.py script) --> interfaces + NDR + flags + endpoints
--(two-axis AHP ranking engine) --> ranked interfaces + receipts
--> single JSON report
शून्य-प्रतीक निर्भरता: इस इंजन का एक महत्वपूर्ण तकनीकी विभेदक यह है कि यह पूरी तरह से debug symbols के बिना काम करता है। dispatch tables को प्रोग्रामेटिक रूप से ट्रैवर्स करके और raw NDR (Network Data Representation) बाइटकोड्स और संकलित MIDL संरचनाओं को सीधे मेमोरी से पार्स करके, टूल Microsoft के .pdb फ़ाइलों या लाइव endpoint mapper क्वेरी की आवश्यकता को दरकिनार कर देता है। यह सुनिश्चित करता है कि इंजन stripped, production System32 बाइनरीज़ पर बिल्कुल वैसे ही out-of-the-box काम करता है जैसे वे वितरित की जाती हैं।
Ghidra 11.x (बंडल किए गए support/analyzeHeadless का उपयोग करता है)। PATH पर JDK 17+ की आवश्यकता है।
ड्राइवर पक्ष पर Python 3.8+, साथ में pefile।
निष्कर्षण स्क्रिप्ट Ghidra के बंडल किए गए Jython 2.7 के अंतर्गत चलती है - कोई तृतीय-पक्ष import नहीं, वहाँ स्थापित करने के लिए कुछ नहीं।
लक्ष्य: Windows x64 PE फ़ाइलें। विश्लेषण स्वयं OS-स्वतंत्र है (Ghidra क्रॉस-प्लेटफ़ॉर्म है), इसलिए आपको इसे Windows पर चलाने की आवश्यकता नहीं है।
git clone https://github.com/talha-nazeef-ahmed/RPC-Triage
cd RPC-Triage/
python -m pip install -r requirements.txt # just pefile
requirements.txt: pefile>=2023.2.7
सब कुछ orchestrator.py द्वारा संचालित होता है: यह आपके लिए फ़िल्टर करता है, import करता है, विश्लेषण करता है और निष्कर्षणकर्ता चलाता है।
python orchestrator.py \
-t \"C:\Windows\System32\" \
-g \"C:\ghidra_12.1.2_PUBLIC\" \
-s \".\extract_rpc_interfaces.py\" \
-o \".\out\report.json\" \
--stagedir \".\out\staged\" \
--projdir \".\out\ghidra_proj\" \
--projname RPC_Atlas
| फ़्लैग | अर्थ |
|---|---|
-t / --target | स्कैन करने के लिए बाइनरीज़ का फ़ोल्डर |
-g / --ghidra | Ghidra इंस्टॉल फ़ोल्डर (जिसमें support/analyzeHeadless होता है) |
-s / --script | extract_rpc_interfaces.py का पथ |
-o / --output | लिखने के लिए JSON रिपोर्ट का पथ |
--stagedir | फ़िल्टर की गई RPC बाइनरीज़ को कॉपी करने का फ़ोल्डर (रखा जाता है) |
--projdir | स्थायी Ghidra प्रोजेक्ट के लिए फ़ोल्डर |
--projname | Ghidra प्रोजेक्ट का नाम (जैसे RPC_Atlas) |
पहली बार चलाना बनाम फिर से चलाना (महत्वपूर्ण)। पहली बार चलाना धीमा हिस्सा करता है: यह फ़िल्टर करता है, मिलान करने वाली बाइनरीज़ import करता है, पूर्ण ऑटो-विश्लेषण चलाता है, फिर --projdir में एक .analysisComplete मार्कर छोड़ता है। उसी प्रोजेक्ट पर हर बाद का रन import/विश्लेषण (-process -noanalysis) को छोड़ देता है और केवल पहले से विश्लेषित प्रोग्रामों पर स्क्रिप्ट को फिर से चलाता है। इसलिए System32 का विश्लेषण एक बार की लागत है और आउटपुट पर पुनरावृत्ति सस्ती है। यदि विश्लेषण बाधित होता है तो मार्कर नहीं लिखा जाता और आंशिक प्रोजेक्ट (.rep / .gpr) को हटाकर नए सिरे से शुरू किया जाता है।
एक JSON फ़ाइल: बाइनरीज़ की एक सूची, प्रत्येक में एक Interfaces सरणी होती है। System32 पर एक पूर्ण रन इस रिपॉजिटरी में output/FullBatchRun.json पर शामिल है - यह कच्चा, बिना क्यूरेट किया हुआ आउटपुट है, ताकि आप देख सकें कि टूल बड़े पैमाने पर वास्तव में क्या उत्पन्न करता है। प्रति इंटरफ़ेस:
| फ़ील्ड | अर्थ |
|---|---|
CallSite | RpcServerRegisterIf\* कॉल का पता |
Tag / TagDesc | डेटा-गुणवत्ता बकेट (नीचे देखें) |
Rank | \"{Tier}/{Composite}\", जैसे Critical/91 |
RankDetail | पूर्ण स्कोरिंग रसीद (नीचे देखें) |
UUID | इंटरफ़ेस UUID |
InterfaceAddress / DispatchAddress | पुनर्प्राप्त संरचना पते |
FunctionsCount | आधिकारिक संग्रहीत method गणना; (FLAG: Walked X != Stored Y) ले सकता है |
Endpoints | transport / endpoint bindings |
Security | HasBouncer, SecurityDescriptor, SecureOnly, LocalCallOnly |
Methods | प्रति-opnum पैरामीटर सूची, डिकोड किए गए NDR opcodes के साथ |
टैग; डेटा-स्वच्छता द्वार:
Clean: स्वच्छ रूप से पुनर्प्राप्त; सामान्य रूप से रैंक किया गया।
Needs-Review: रैंक किया गया, लेकिन dispatch table ट्रैवर्सल संग्रहीत गणना से अधिक निकल गया (आमतौर पर एक trailing thunk block)। स्कोर वास्तविक है लेकिन [Provisional] के साथ आता है; उद्धृत करने से पहले method गणना सत्यापित करें।
Diagnostics / Diagnostics (2): यह पंक्ति एक निष्कर्षण कलाकृति है (UUID के रूप में गलत तरीके से पहचाना गया एक ASCII स्ट्रिंग और/या एक दूषित MIDL पॉइंटर)। स्कोर नहीं किया गया (Rank: N/A)। इन्हें जानबूझकर रखा गया है: ये टूल के स्वास्थ्य की रिपोर्ट करते हैं, आक्रमण सतह नहीं हैं।
यह FLAG: Walked X != Stored Y नोट। संग्रहीत DispatchTableCount आधिकारिक है और हर स्कोर इसी का उपयोग करता है। walked गणना एक स्वतंत्र निष्पादन-क्षमता क्रॉस-चेक है; जब दोनों असहमत होते हैं (आमतौर पर एक स्वच्छ 2x) तो इंटरफ़ेस को Needs-Review टैग किया जाता है ताकि आप उस पर नज़र डालें। यह कभी भी चुपचाप स्कोर नहीं बदलता।
यह वह हिस्सा है जो स्कोर को तर्क-योग्य बनाता है:
Moderate/35 | Gate:35 [ncacn_np:41, MultiEndpointBonus:15, HasBouncer:-46, BouncerIsNotCaching:25] | Surface:100 [HasBogusStruct:1x(opnums 5):[in]:61, HasCallerSizedBuffer:5x(opnums 0,6,11):[in]:49, InPtrs:6:18, Count:12:6 -> raw:134 [capped to 100] * 1.0 -> 100] | (35 * 100) / 100 = 35 [Provisional]
इसे बाएँ से दाएँ पढ़ें: