Anti-Debugging: রিভার্স ইঞ্জিনিয়ারিং প্রতিরোধে ম্যালওয়্যারগুলোর অভিনব পদ্ধতি!

প্রতিটি malware author জানেন যে তাদের তৈরি code একদিন না একদিন security researcher-এর হাতে পড়বে। যখনই এটি ঘটে, তখন malware-এর capability, command and control infrastructure, এবং targeted victim-সংক্রান্ত তথ্য প্রকাশ পেতে পারে। এই বিশ্লেষণ প্রক্রিয়া যত বিলম্বিত করা যায়, malware তত বেশিদিন সক্রিয় থাকতে পারে এবং তার operator-রা তত বেশি লাভ অর্জন করতে পারে।

Anti-debugging শুধু malware-এ ব্যবহৃত হয় না—কপিরাইট সুরক্ষিত software, DRM সিস্টেম, এবং anti-cheat engine-গুলোও একই কৌশল ব্যবহার করে। তবে malware-এর প্রেক্ষাপটে এর তীব্রতা ও সৃজনশীলতা অনেক বেশি, কারণ এখানে detection মানে শুধু analysis বিলম্ব নয়, পুরো অপারেশনের ব্যর্থতা।

Windows operating system বেশ কিছু built-in API প্রদান করে যা একটি process debugger-এর অধীনে চলছে কিনা তা যাচাই করতে পারে। এদের মধ্যে সবচেয়ে সরল হলো IsDebuggerPresent। এই API কেবল current process-এর PEB (Process Environment Block)-এ থাকা BeingDebugged flag পড়ে। যদি একটি debugger যেমন x64dbg বা WinDbg attached থাকে, এই flag set হয়ে যায়।

আরেকটি জনপ্রিয় API হলো CheckRemoteDebuggerPresent, যা বাহ্যিকভাবে অন্য process debug করা হচ্ছে কিনা তা যাচাই করে। NtQueryInformationProcess একটি undocumented native API যা ProcessDebugPort, ProcessDebugFlags, এবং ProcessDebugObjectHandle সহ বিভিন্ন debug-related information দিতে পারে। যদি ProcessDebugPort non-zero হয়, তবে process একটি debugger-এর অধীনে চলছে।

NtSetInformationThread কে ThreadHideFromDebugger flag দিয়ে কল করে malware তার thread-কে debugger থেকে লুকিয়ে রাখতে পারে। এর ফলে debugger thread-এ breakpoint hit করতে পারে না এবং exception গুলো intercept করতে ব্যর্থ হয়।

Process Environment Block (PEB) হলো Windows-এর একটি গুরুত্বপূর্ণ data structure যা প্রতিটি process-এর জন্য maintained হয়। PEB-এর কিছু field debugger-এর উপস্থিতি প্রকাশ করে—যেমন উপরে উল্লিখিত BeingDebugged (offset 0x02), NtGlobalFlag (offset 0x68 64-bit-এ 0xBC)।

NtGlobalFlag সাধারণত zero থাকে, কিন্তু যখন process debugger-এর অধীনে launched হয়, এতে FLG_HEAP_ENABLE_TAIL_CHECK, FLG_HEAP_ENABLE_FREE_CHECK, এবং FLG_HEAP_VALIDATE_PARAMETERS flag set হয়, যার মান 0x70। malware সরাসরি এই memory location পড়ে detection করতে পারে।

একইভাবে heap structure-এ debugger-এর উপস্থিতিতে কিছু পরিবর্তন আসে। Heap-এর Flags field এবং ForceFlags field debug heap configuration প্রকাশ করে। HEAP_GROWABLE (0x2) ছাড়া অন্য কোনো flag set থাকলে এটি debug environment নির্দেশ করে।

Debugging প্রক্রিয়া স্বাভাবিকভাবেই code execution-কে ধীর করে দেয়। একটি কোড block যা সাধারণত milliseconds-এ সম্পন্ন হয়, debugger-এ step through করলে কয়েক মিনিট লেগে যেতে পারে। malware এই বৈশিষ্ট্য কাজে লাগায়—একটি known operation-এর শুরু এবং শেষে timestamp record করে এবং এর মধ্যবর্তী সময় পরিমাপ করে।

GetTickCount, QueryPerformanceCounter, এবং RDTSC (Read Time-Stamp Counter) instruction এই কাজে ব্যবহৃত হয়। RDTSC সবচেয়ে precise কারণ এটি CPU-এর internal counter পড়ে। যদি দুটি RDTSC কলের মধ্যে delta কিছু threshold অতিক্রম করে—সাধারণত 0xFFFF বা 100,000 cycles—malware ধরে নেয় যে debugger active রয়েছে।

আধুনিক malware এই কৌশলকে আরও sophisticated করে তুলেছে। তারা multiple timing check রাখে বিভিন্ন code path-এ, যাতে analyst একটি bypass করলেও অন্য জায়গায় detection trigger হয়। কখনো কখনো cloud-based timing reference ব্যবহার করা হয়, যেখানে NTP server থেকে time fetch করে local clock-এর সঙ্গে তুলনা করা হয়।

Debugger-গুলো process-এ ঘটা exception intercept করে, যা malware exploit করতে পারে। সবচেয়ে classic উদাহরণ হলো intentional INT 3 (breakpoint instruction, opcode 0xCC) execute করা। সাধারণ পরিবেশে এটি একটি EXCEPTION_BREAKPOINT exception তৈরি করে যা process-এর own exception handler ধরতে পারে। কিন্তু debugger-এ এই exception প্রথমে debugger ধরে এবং সাধারণত execution থামিয়ে দেয়।

malware তার নিজস্ব Structured Exception Handler (SEH) রেজিস্টার করে এবং intentionally exception throw করে। যদি handler কল হয়, debugger নেই; যদি না হয়, debugger present। SetUnhandledExceptionFilter এবং Vectored Exception Handler (VEH)-এর মাধ্যমেও একই কৌশল প্রয়োগ করা যায়।

আরেকটি কৌশল হলো INT 2D instruction ব্যবহার, যা শুধু kernel mode-এ valid, কিন্তু user mode-এ একটি unique exception তৈরি করে যা different debugger ভিন্নভাবে handle করে।

কিছু advanced malware তার own code-এর checksum বা hash গণনা করে এবং সেটি একটি known good value-এর সঙ্গে তুলনা করে। যদি debugger software breakpoint (0xCC byte) inject করে, code-এর bytes পরিবর্তিত হয় এবং checksum mismatch হয়। তখন malware execution বন্ধ করে দেয় অথবা ভুল code path follow করে।

Self-modifying code বা packed code-এও anti-debugging প্রয়োগ করা যায়। UPX-এর মতো commercial packer ছাড়াও custom packer ব্যবহার করে malware তার real code runtime-এ decrypt করে। যদি analyst শুরুতে breakpoint set করতে চান, তাদের প্রথমে unpacking routine বের করতে হয়, যা সময়সাপেক্ষ।

Hardware breakpoint (debug register DR0-DR3 ব্যবহার করে set করা) সাধারণত software breakpoint-এর তুলনায় harder to detect, কিন্তু malware GetThreadContext API দিয়ে এসব register পড়ে এবং non-zero value পেলে debugger উপস্থিতি নিশ্চিত করে।

Anti-debugging-এর সঙ্গে ঘনিষ্ঠভাবে সম্পর্কিত একটি ধারণা হলো anti-VM এবং anti-sandbox। আধুনিক malware analysis-এ analyst-রা VirtualBox, VMware, বা automated sandbox যেমন Cuckoo, ANY.RUN ব্যবহার করেন। malware এই environment detect করার জন্য বিভিন্ন artifact খোঁজে।

Registry-তে HKLM\HARDWARE\Description\System\SystemBiosVersion-এ "VBOX" বা "VMWARE" string, HKLM\SOFTWARE\VMware, Inc.-এর existence, MAC address-এর OUI prefix (00:0C:29 VMware-এর জন্য), এবং running process list-এ vmtoolsd.exe, VBoxTray.exe—সবই VM-এর indicator। CPUID instruction-এর hypervisor bit (leaf 1, ECX bit 31) আরেকটি common check।

Sandbox detection-এর জন্য malware username, computer name, recent file count, এবং mouse movement check করে। অনেক sandbox-এ default username "John Doe" বা "user" থাকে, recent files কম থাকে, এবং mouse activity সীমিত। উন্নত malware delayed execution ব্যবহার করে—কয়েক মিনিট বা ঘণ্টা পরে activate হয়, কারণ বেশিরভাগ sandbox short analysis window-এ চলে।

GootKit banking trojan anti-debugging-এর একটি classic উদাহরণ। এটি 200-এর বেশি anti-analysis check প্রয়োগ করে, যার মধ্যে রয়েছে timing check, VM detection, debugger API check, এবং specific analysis tool যেমন ProcessHacker, Wireshark, Sysinternals suite-এর উপস্থিতি যাচাই। এই বহুস্তরীয় সুরক্ষার কারণে GootKit-এর full analysis সম্পন্ন করতে security researcher-দের সপ্তাহ লেগে যায়।

Emotet malware family এর প্রতিটি version-এ নতুন anti-debugging trick যোগ করেছে। তাদের একটি জনপ্রিয় কৌশল হলো process tree analysis—যদি parent process explorer.exe না হয়, malware ধরে নেয় এটি sandbox-এ চলছে এবং dormant থাকে।

Stuxnet—ইরানের পারমাণবিক কেন্দ্রে আক্রমণকারী cyber weapon—তে সবচেয়ে sophisticated anti-debugging এবং code obfuscation ব্যবহৃত হয়েছিল। এর কারণে একে সম্পূর্ণরূপে analyze করতে multiple security firm-কে কয়েক মাস কাজ করতে হয়েছিল।

Analyst-রা anti-debugging বাধা অতিক্রম করার জন্য বিভিন্ন পদ্ধতি ব্যবহার করেন। সবচেয়ে সরল হলো API hooking—IsDebuggerPresent-এর মতো function-কে patch করে সবসময় FALSE রিটার্ন করানো। ScyllaHide এবং TitanHide-এর মতো plugin x64dbg-এর জন্য এই কাজ স্বয়ংক্রিয় করে দেয়। তারা PEB modification, API hooking এবং exception handling সমন্বিতভাবে পরিচালনা করে।

আরেকটি পদ্ধতি হলো static analysis-এ মনোযোগ দেওয়া। IDA Pro বা Ghidra-তে malware load করে dynamic execution ছাড়াই code path বিশ্লেষণ করা যায়। যদিও এটি packed code-এর জন্য কঠিন, anti-debugging সরাসরি trigger হয় না।

Emulation-based analysis যেমন Unicorn Engine বা QEMU ব্যবহার করেও bypass সম্ভব। এখানে CPU instruction simulate করা হয়, real OS environment নয়, ফলে অনেক API-based check কাজ করে না। তবে emulator-এর own artifact থাকে যা advanced malware detect করতে পারে।

সবচেয়ে কার্যকর কৌশল হলো hybrid analysis—static এবং dynamic-এর সমন্বয়। প্রথমে static analysis-এর মাধ্যমে anti-debugging logic identify করা হয়, তারপর targeted patching বা bypass dynamic analysis-এ প্রয়োগ করা হয়।