AntiDBG

antidbg Windows के लिए एक x64 user-mode anti-debugging लाइब्रेरी है, जिसे सॉफ़्टवेयर को डीबगिंग से बचाने के लिए डिज़ाइन किया गया है।

लाइब्रेरी को अपनी anti-debugging सुरक्षा के आधार के रूप में मानें, न कि अपनी एकमात्र रक्षा के रूप में।

लाइब्रेरी है:

• उपयोग में बहुत आसान (केवल एक फ़ंक्शन कॉल आवश्यक)।
• उच्च प्रदर्शन और न्यूनतम संसाधन उपयोग के लिए डिज़ाइन की गई (1% CPU उपयोग; <2MB मेमोरी)।
• किसी भी बाहरी निर्भरता से मुक्त।
• पूर्णतः MIT-लाइसेंस प्राप्त।
• CFG-अनुरूप।

संरचना

खतरा मॉडल यह मानता है कि एक डीबगर इस सुरक्षा प्रणाली द्वारा संरक्षित सॉफ़्टवेयर को किसी भी विशेषाधिकार स्तर से इंटरसेप्ट कर सकता है, और विशेषाधिकार स्तर जितना ऊँचा होगा, पहचान उतनी ही कम प्रभावी होगी।

यह सॉफ़्टवेयर निम्नलिखित द्वारा तुच्छ CPL > 0 इंटरसेप्शन को बायपास करने के लिए सख्त किया गया है:

• inline assembly के साथ syscalling के माध्यम से किसी भी प्रकार के API हुक से बचना।
• वर्तमान प्रक्रिया के लिए virtual memory सुरक्षा और injection शमन नीतियों को लागू करना।
• RAX में syscall spoofing को रोकना, अवैध instrumentation callbacks का पता लगाकर और/या उन्हें अधिलेखित करके।
• on-disk vs in-memory तुलना करके निगरानी किए गए .text अनुभागों पर किसी भी प्रकार के inline patch का पता लगाना।
• exception handling delivery (VEH, SEH, LPTOP_LEVEL_EXCEPTION_FILTER) और software breakpoints का विश्लेषण करना।
• PAGE_GUARD redirection व्यवहार का परीक्षण करना।
• महत्वपूर्ण stubs को non-writable मेमोरी के रूप में सुरक्षित करना, बाद में उन्हें एक अलग थ्रेड पर hardware-accelerated hashing के साथ निगरानी करना।
• TLS callbacks के साथ प्रक्रिया entrypoint को डीबगर attachment से सुरक्षित करना, thread start address निरीक्षण करना।
• डीबगर entrypoints में जाल बनाना, जैसे DbgBreakPoint और DbgUiRemoteBreakin, ताकि प्रक्रिया क्रैश हो या वापस लौटे।
• सभी थ्रेड्स को डीबगर events और process freeze से छिपाना। सुनिश्चित करता है कि thread priority स्थिति प्रभावित न हो।
• सुरक्षा शुरू होते ही एक global vectored handler सेट करना।

यदि किसी जाँच को करने का एकमात्र तरीका non-syscallable exported function का उपयोग करना है, तो संबंधित फ़ंक्शन को मैन्युअल रूप से reverse-engineer किया जाता है और सुरक्षा थ्रेड के module address space में चलाने के लिए पुनर्निर्मित किया जाता है। सभी user-mode मेमोरी संरचनाओं को APIs का उपयोग करने के बजाय सीधे memory introspection के साथ चलाया जाता है।

सुरक्षा routines जानबूझकर कुछ execution paths को user-mode hooks के विरुद्ध असुरक्षित छोड़ देती हैं, जो memory honeypots के रूप में कार्य करते हैं। इनका उपयोग state तुलना और हमलावरों को भ्रमित करने के लिए किया जाता है।

सुरक्षा routines pseudo-randomly चलती हैं। entropy को शुद्ध hardware-based ASLR, stack व्यवहार और थोड़े से गणित के साथ तय किया जाता है; kernel को कॉल किए बिना, user-mode APIs का उपयोग किए बिना, या hypervisors द्वारा सशर्त या बिना शर्त exiting निर्देश जारी किए बिना।

जब सुरक्षा उल्लंघन का पता चलता है, तो सुरक्षा प्रणाली STATUS_SXS_EARLY_DEACTIVATION के साथ INT 29h को invoke करके वर्तमान प्रक्रिया को क्रैश कर देती है, सभी exception handlers को बायपास करते हुए। कुछ मामलों में, यह वर्तमान प्रक्रिया को समाप्त करने के लिए kernel को एक APC भी कतारबद्ध करती है।

पहचान

इस लाइब्रेरी के मुख्य entrypoint (abdg.c) में पाई जाती हैं, क्रम में समझाई गई हैं।

संक्षिप्त व्याख्याएँ; एक विशिष्ट पहचान यहाँ समझाए गए से अधिक अतिरिक्त/उप-जाँचें कर सकती है।

आप अन्य पहचान अवधारणाओं का अधिक स्रोत कोड antidebug\archived फ़ोल्डर में पा सकते हैं।

• 1. kernel32 के export function का उपयोग करके PEB के BeingDebugged फ़ील्ड को पढ़ता है।
• 2. यह देखने के लिए export IsRemoteDebuggerPresent को कॉल करता है कि लक्ष्य प्रक्रिया अपने स्वयं के संदर्भ के बाहर से डीबग की जा रही है या नहीं।
• 3. INT 2D software interrupt को निष्पादित करता है, यह जाँचते हुए कि क्या ऐसे निर्देश के बाद वाला बाइट छोड़ दिया जाता है और EXCEPTION_BREAKPOINT handler के माध्यम से रूट नहीं किया जाता है।
• 4. breakpoint interrupt INT 3D को निष्पादित करता है, फिर देखता है कि exception को इंटरसेप्ट किया जाता है या सामान्य रूप से पारित किया जाता है।
• 5. ICE/0xF1 को invoke करता है, EXCEPTION_SINGLE_STEP उठाता है और जाँचता है कि क्या डीबगर इस exception को RFlags रजिस्टरों में single step बिट सेट के साथ निर्देश निष्पादित करके उत्पन्न सामान्य exception मानेगा।

उपयोग

1. Guard mode: आपके प्रोग्राम में एक थ्रेड चलना शुरू हो जाएगा और लगातार attached डीबगरों की निगरानी करेगा। यदि किसी भी समय डीबगर का पता चलता है, तो प्रोग्राम प्रयास को लॉग करेगा (यदि debug mode में संकलित है) और किसी अन्य प्रोग्राम को क्रैश रोकने से रोकते हुए बलपूर्वक बाहर निकल जाएगा।

उदाहरण:

#include "adbg.h"

int main() {
    StartDebugProtection();

    return 0;
}

2. Single-run mode: एक फ़ंक्शन जिसे आप किसी भी समय कॉल कर सकते हैं यह पता लगाने के लिए कि आपकी प्रक्रिया से डीबगर attached हैं या नहीं।

उदाहरण:

#include "adbg.h"

int main() {
    if (isProgramBeingDebugged()) {
        printf("Debugger detected.\n");
    }
    else {
        printf("No debugger was detected.\n");
    }

    return 0;
}

बिल्ड

1. Binary mode

test runner executable बनाने के लिए, -DBUILD_EXAMPLE=ON सक्षम करें। यह example/main.c को संकलित करता है और इसे antidebug के विरुद्ध लिंक करता है, बिना core लाइब्रेरी को entry point से प्रदूषित किए।

Visual Studio (GUI)

1. Visual Studio में repository फ़ोल्डर खोलें (या जनरेट की गई .sln फ़ाइल खोलें)।
2. अपना वांछित configuration चुनें (x64-Release या x64-Debug)।
3. antidebug_runner को startup project के रूप में सेट करें और Build पर क्लिक करें (या चलाने के लिए F5 दबाएँ)।

CLI (MSVC / Ninja / Clang)

प्रोजेक्ट रूट से:

cmake -B build -S . -DBUILD_EXAMPLE=ON
cmake --build build --config Release

executable यहाँ स्थित होगा:

• MSVC multi-config: build/Release/antidebug_runner.exe
• Ninja single-config: build/antidebug_runner.exe

Debug Builds पर नोट: Debug mode (--config Debug) में संकलन core/debug.c के माध्यम से console/debugger diagnostic logs सक्षम करता है। Release mode logging को पूरी तरह हटा देता है।

2. Library mode (Static या Shared)

डिफ़ॉल्ट रूप से, CMake एक static library (antidebug.lib या libantidebug.a) उत्पन्न करता है। dynamic link library (DLL) बनाने के लिए, -DBUILD_SHARED_LIBS=ON पास करें।

विकल्प A: MSVC (cl.exe)

Visual Studio generator का उपयोग करके:

# Static Library (.lib)
cmake -B build -S . -A x64 -DBUILD_SHARED_LIBS=OFF
cmake --build build --config Release

# Dynamic Library (.dll + import .lib)
cmake -B build -S . -A x64 -DBUILD_SHARED_LIBS=ON
cmake --build build --config Release

विकल्प B: Clang-CL (MSVC Integration के साथ LLVM)

clang-cl के साथ Ninja का उपयोग करके:

# Ensure clang-cl is in your PATH or run from the VS x64 Native Tools Command Prompt
cmake -B build -S . -G Ninja -DCMAKE_C_COMPILER=clang-cl -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=OFF
cmake --build build

विकल्प C: Clang (MinGW / LLVM-MinGW)

अपना 64-bit LLVM-MinGW shell लॉन्च करें (x86_64-w64-mingw32-clang आपके PATH में) और Ninja का उपयोग करें:

# Static Library (.a)
cmake -B build -S . -G Ninja -DCMAKE_C_COMPILER=clang -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=OFF
cmake --build build

# Shared Library (.dll)
cmake -B build -S . -G Ninja -DCMAKE_C_COMPILER=clang -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=ON
cmake --build build

3. CMake के माध्यम से इंस्टॉलेशन

संकलित लाइब्रेरी और headers को एक स्थानीय prefix में इंस्टॉल करने के लिए:

cmake --install build --prefix "C:/local/antidebug"

यह उत्पन्न करता है:

C:/local/antidebug/
├── bin/
│   └── antidebug.dll           (if BUILD_SHARED_LIBS=ON)
├── lib/
│   └── antidebug.lib           (or libantidebug.a)
└── include/
    └── antidebug/
        ├── adbg.h
        └── ...

कानूनी और अस्वीकरण

इस प्रोजेक्ट के किसी भी दुर्भावनापूर्ण उपयोग के माध्यम से आपके द्वारा किए गए किसी भी नुकसान के लिए मैं ज़िम्मेदार या उत्तरदायी नहीं हूँ।

BUILD दस्तावेज़ का निर्माण AI के साथ किया गया था, किसी भी समस्या की रिपोर्ट करें।

License: MIT