zypherion-technologies/hallwatchउपयोगकर्ता मोड डिटेक्टर जो अप्रत्यक्ष syscalls को पकड़ता है। यह Hell's Hall, Tartarus' Gate, RecycledGate, और VEH syscalls और कई अन्य को फँसाता है।
कॉपीराइट (C) 2026 Adam Zypherion <[email protected]> — GPL-3.0 के अंतर्गत लाइसेंस प्राप्त।
इनडायरेक्ट सिस्कॉल्स सरल हो जाते हैं जब आप एक देख लेते हैं। लोडर ntdll में चलता है, Nt* प्रोलॉग से SSN पढ़ता है, आगे दो बाइट्स में 0F 05 ढूंढता है, स्वयं r10/rax/rdx/r8/r9 सेट करता है, और सीधे उन दो बाइट्स पर jmp करता है। सिस्कॉल ntdll के अंदर से होता है। kernel32 एक्सपोर्ट पर आपका हुक कभी छुआ नहीं जाता। ntdll एक्सपोर्ट पर आपका हुक कभी छुआ नहीं जाता। SYSCALL के समय [RSP] लोडर के RWX पेज पर वापस इंगित करता है, लेकिन बाहर से कॉल में कुछ भी असामान्य नहीं दिखता।
HellHall proc
mov r10, rcx
mov eax, dwSSN
jmp qword ptr [qAddr]
ret
HellHall endp
वेरिएंट के नाम हैं। Tartarus' Gate और RecycledGate एक स्टब के syscall निर्देश का उपयोग करते हैं लेकिन किसी दूसरे के SSN का, इसलिए भले ही आप स्टब का नाम लॉग करें जो आपका हुक रिपोर्ट करता है, वह झूठ है। VEH syscall जानबूझकर एक एक्सेस उल्लंघन ट्रिगर करता है और अपने स्वयं के VEH का उपयोग करके संदर्भ को फिर से लिखता है ताकि RIP ntdll के syscall निर्देश पर पहले से तैयार रजिस्टरों के साथ उतरे। Hell's Gate ntdll का बिल्कुल उपयोग नहीं करता। लोडर अपने स्वयं के RWX पेज में 0F 05 लिखता है और वहाँ से चलता है।
कर्नेल मोड (KM) का उत्तर एक ड्राइवर है, मैं वास्तव में समय के साथ इस पर काम कर सकता हूँ और एक प्रोजेक्ट जारी कर सकता हूँ लेकिन जल्द ही ऐसा नहीं होगा :D
PAGE_GUARD काम करता हुआ दिखता है। syscall बाइट्स रखने वाले पेज को PAGE_GUARD से चिह्नित करें, VEH में STATUS_GUARD_PAGE_VIOLATION को पकड़ें, निरीक्षण करें, एक निजी ट्रैम्पोलिन पर रीडायरेक्ट करें, ट्रैप फ्लैग सेट करें, एकल-चरण बाहर निकलें, पेज को वापस सशस्त्र करें। प्रति Nt कॉल एक ट्रैप, चाहे लोडर वहाँ कैसे भी पहुंचे। यह Hell's Gate को छोड़कर सब कुछ के खिलाफ काम करता है।
समस्या यह है कि OS सहयोग नहीं करता। PAGE_GUARD एक शॉट है, इसका क्या मतलब है? हर बार जब यह फायर करता है तो बिट साफ हो जाता है और आपको इसे वापस रखना होता है। आपका हैंडलर syscalls करता है (गार्ड को वापस रखने के लिए NtProtect, फिर से शुरू करने के लिए NtContinue) और उन syscalls में स्टब होते हैं और वे स्टब उस पेज पर होते हैं जिसे आपने अभी गार्ड किया था। मैंने इसका अधिकांश भाग एक अलग पेज पर बने निजी syscall स्टब्स के साथ हल किया जो हमारे स्वामित्व में था (RWX आवंटित करें, mov r10,rcx; mov eax,SSN; syscall; ret लिखें, RX लॉक करें, ntdll को कभी न छुएं), लेकिन यह नाजुक था। हर विंडोज माइनर वर्जन ने टाइमिंग बदल दी। नमूने द्वारा स्पॉन किया गया प्रत्येक थ्रेड इंटीग्रिटी वर्कर के खिलाफ एक और दौड़ था जो गार्ड का पुनर्निर्माण कर रहा था। एक ही मशीन पर दस रनों में डेमो सफलता लगभग 30 से 50 प्रतिशत थी।
आखिरकार मैंने विंडोज को यह समझाने की कोशिश करना बंद कर दिया कि PAGE_GUARD को मेरी इच्छानुसार व्यवहार करना चाहिए, और इसके बजाय बाइट को ओवरराइट करने की कोशिश की।
https://github.com/user-attachments/assets/0cb670fd-e51b-413e-bf00-08f9297888ed
syscall निर्देश पर बाइट 0F 05 है। पहली बाइट अकेली (0F) दो-बाइट ओपकोड के एक परिवार का उपसर्ग है जिसमें SYSCALL, CPUID और RDTSC शामिल हैं। अपने आप में यह निष्पादन योग्य नहीं है; CPU को दूसरे बाइट की आवश्यकता है। यदि आप पहली बाइट को 0xCC (INT3) से बदल देते हैं, तो जोड़ी CC 05 बन जाती है, जिसे CPU INT3 के रूप में डिकोड करता है जिसके बाद एक भटका हुआ बाइट होता है जिस तक वह कभी नहीं पहुँचता। कोई भी कोड पथ जो उस पते पर उतरता है, EXCEPTION_BREAKPOINT उठाता है।
यह पूरी तंत्र है। हमारा VEH ब्रेकपॉइंट को पकड़ता है, देखता है कि पता किस स्टब का है (हम init समय पर ntdll के एक्सपोर्ट को गणना करके मानचित्र बनाते हैं), जो कोई भी आया उस पर तीन जाँच चलाता है, और Context->Rip को एक निजी ट्रैम्पोलिन पर सेट करता है जो वास्तविक syscall करता है और लौटता है। बाइट CC ही रहता है। अगला कॉलर उसी तरह से इसे हिट करता है, इसलिए पेज प्रोटेक्शन को आगे-पीछे फ्लिप करने की कोई आवश्यकता नहीं है।
स्पष्ट होने के लिए: हाँ, यह बाइट ओवरराइट द्वारा हुकिंग है। यह सिर्फ उस बाइट पर नहीं है जिसे लोग आमतौर पर "ntdll हुक" से समझते हैं। क्लासिक EDR हुक स्टब के पहले बाइट्स को JMP <my_func> से ओवरराइट करता है:
ntdll!NtAllocateVirtualMemory:
E9 ?? ?? ?? ?? jmp my_hook ; overwrites "mov r10, rcx"
...
0F 05 syscall
C3 ret
यह ठीक वही है जो इनडायरेक्ट syscalls के आसपास चलता है। लोडर स्वयं SSN पढ़ता है और सीधे 0F 05 पर कूदता है, प्रोलॉग (और आपका jmp) कभी नहीं चलता, हुक कभी फायर नहीं करता। हम जो करते हैं वह syscall बाइट को ही ओवरराइट करना है:
ntdll!NtAllocateVirtualMemory:
4C 8B D1 mov r10, rcx ; अछूता
B8 18 00 00 00 mov eax, 18h ; अछूता
CC 05 int3 / 05 ; था 0F 05, हमने 0F के ऊपर CC लिखा
C3 ret
अब इससे कोई फर्क नहीं पड़ता कि आप उस पते पर कैसे पहुँचे। प्रोलॉग के माध्यम से, एक इनडायरेक्ट जंप के माध्यम से जो प्रोलॉग को छोड़ता है, एक VEH-syscall संदर्भ पुनर्लेखन के माध्यम से जो RIP को वहाँ गिराता है, जो भी हो। यदि CPU उस बाइट को निष्पादित करता है, तो यह ट्रैप करता है। क्लासिक हुक के समान तकनीक परिवार, अलग स्थान, पूरी तरह से अलग कवरेज।
ट्रैम्पोलिन इस तरह दिखता है:
F3 0F 1E FA endbr64
49 89 CA mov r10, rcx
B8 <stub SSN> mov eax, ssn
0F 05 syscall
C3 ret
तीन जाँच PAGE_GUARD संस्करण से अपरिवर्तित हैं क्योंकि वे सही तीन जाँच थीं; उन्हें बस एक विश्वसनीय स्थान पर रहने की आवश्यकता थी।
वापसी पता। [RSP] वह है जहाँ syscall वापस आ गया होता। एक वास्तविक कॉल के लिए यह ntdll, kernel32, kernelbase, या संबंधित रनटाइम DLL में से किसी एक के अंदर है। Hell's Hall के लिए यह लोडर के जिस भी RWX पेज से चल रहा है, उसके अंदर है। हमारे पास init पर उन नामों के लिए GetModuleHandle कॉल करके और उनके PE हेडर से .text रेंज पढ़कर बनाए गए विश्वसनीय रिटर्न लक्ष्यों की एक छोटी सूची है।
SSN। स्टब का प्रोलॉग syscall बाइट तक पहुँचने से पहले ही चल चुका होता है, इसलिए eax में वह मान होता है जो इसमें लोड किया गया था। यदि लोडर ने Tartarus स्वैप किया, तो वह मान उस SSN से मेल नहीं खाएगा जिसे हमने गणना के समय इसी स्टब से पढ़ा था। हम बेमेल को लॉग करते हैं, और ट्रैम्पोलिन अपने स्वयं के syscall से पहले सही SSN लिखता है, इसलिए जो कर्नेल फ़ंक्शन चलता है वह बाइट का है न कि वह जो लोडर चाहता था। तकनीक को उसी चरण में लॉग और बेअसर किया जाता है।
स्टैक वॉक। RtlVirtualUnwind वर्तमान संदर्भ से, पाँच फ्रेम ऊपर। प्रत्येक फ्रेम का RIP एक ज्ञात मॉड्यूल के अंदर होना चाहिए और उसकी एक RUNTIME_FUNCTION प्रविष्टि होनी चाहिए। शेलकोड और ROP गैजेट इसमें विफल होते हैं, भले ही [RSP] स्वयं विश्वसनीय दिखता हो, जिसे एक लोडर नकली बना सकता है (यह मोटे तौर पर अनुमान लगा सकता है कि इसका कॉलर मेमोरी में कहाँ होगा और वहाँ एक विश्वसनीय वापसी पता गढ़ सकता है)।
यदि कोई जाँच विफल होती है, तो हम एक लॉक-फ्री रिंग में एक छोटा स्ट्रक्ट पुश करते हैं और ड्रेन थ्रेड अगली बार जागने पर इसे प्रिंट करता है।
[!! hallwatch !!] indirect syscall (अविश्वसनीय कॉलर, इस स्टब के लिए गलत ssn)
syscall : NtAllocateVirtualMemory
syscall rip : 0x00007FF827660372
return addr : 0x00007FF7EED719D6
rax (ssn) : 0x0000000F (stub encodes 0x00000018)
thread : 26388
Hell's Gate वह जगह है जहाँ INT3 मदद करना बंद कर देता है। हमने कभी लोडर के RWX पेज को पैच नहीं किया क्योंकि हमें कभी पता नहीं चला कि यह अस्तित्व में है।