infinite delay routine, trap stub when trying to find main

When trying to find the main routine of AfkBot code I came across this piece of code which is used to prevent debugging or similar purposes.


/* WARNING: Removing unreachable block (ram,0x0040110f) */

undefined4 FUN_00401090(void)

{
  HMODULE pHVar1;
  undefined4 *puVar2;
  char *pcVar3;
  undefined4 local_1c;
  undefined4 local_18;
  undefined1 local_14 [4];
  FARPROC local_10;
  FARPROC local_c;
  undefined4 local_8;
 
  pcVar3 = "ZwSetTimerResolution";
  pHVar1 = GetModuleHandleW(L"ntdll.dll");
  local_c = GetProcAddress(pHVar1,pcVar3);
  pcVar3 = "NtDelayExecution";
  pHVar1 = GetModuleHandleW(L"ntdll.dll");
  local_10 = GetProcAddress(pHVar1,pcVar3);
  (*local_c)(1,1,local_14);
  puVar2 = FUN_00401000();
  stdext::threads::_Mtx_delete(puVar2);
  do {
    local_8 = 0;
    local_1c = 0xfff0bdc0;
    local_18 = 0xffffffff;
    (*local_10)(0,&local_1c);
  } while( true );
}





Okay — this function FUN_00401090() is not your main() or WinMain() after all. It's a decoy or alternate entry point that puts your process into an infinite sleep loop using NtDelayExecution. Let's break this one down in detail.

🧠 Dissecting FUN_00401090()

undefined4 FUN_00401090(void)

This function does not return. It enters an infinite loop after setting a timer resolution, deleting a mutex, and calling low-level Windows NT APIs from ntdll.dll.

🔍 Step-by-Step Breakdown

1. Load NTDLL and resolve functions

pHVar1 = GetModuleHandleW(L"ntdll.dll");  local_c = GetProcAddress(pHVar1, "ZwSetTimerResolution");    pHVar1 = GetModuleHandleW(L"ntdll.dll");  local_10 = GetProcAddress(pHVar1, "NtDelayExecution");

  • ZwSetTimerResolution — sets system clock resolution (higher precision = more CPU).

  • NtDelayExecution — native version of Sleep(), allows sub-ms sleep.

2. Call ZwSetTimerResolution(1, 1, ...)

(*local_c)(1,1,local_14);

  • Enables high-resolution timer. Possibly for timing precision, anti-debugging, or avoiding system-wide throttling.

3. Call some internal cleanup

puVar2 = FUN_00401000();  stdext::threads::_Mtx_delete(puVar2);

  • Might be deleting a mutex or cleaning up thread-related resources.

  • Could also be part of obfuscation or unused junk code.

4. Infinite Sleep Loop

do {    local_8 = 0;    local_1c = 0xfff0bdc0;        // a large negative value (relative time)    local_18 = 0xffffffff;    (*local_10)(0, &local_1c);     // NtDelayExecution  } while( true );

  • Calls NtDelayExecution(0, &local_1c);

  • This puts the thread (or process) into a permanent suspended state (huge sleep).

  • The delay is a large negative 64-bit value → relative time, ~forever.

🛑 Important Takeaway

This is a trap stub, placeholder, or infinite delay routine. It's often used for:

💡 Possible Purposes

Purpose Why it's done
Anti-debugging Native APIs + infinite sleep confuse debuggers
Stub/placeholder Dummy function to prevent actual execution
Malware tactic Keeps the process alive without doing anything
Unreachable logic May be discarded or unused by the program

And you even got this hint:

/* WARNING: Removing unreachable block (ram,0x0040110f) */

Meaning the decompiler knew this code isn't even reachable under normal execution.

✅ So… where is main() or WinMain()?

You're still not in the right place. FUN_00401090() is a dead-end. Your real main() or WinMain() is either:

  • Another function called somewhere else in __scrt_common_main_seh(), not FUN_00401090(), or

  • This FUN_00401090() was intentionally inserted as a fake or decoy entry (common in packers, malware, or obfuscated builds).

🔎 Next Step?

If you want to find the real main() or entry logic:

  1. Search for functions calling WinMain, main, or _mainCRTStartup.

  2. Look inside __scrt_common_main_seh() for other FUN_XXXXXX() style functions being called.

  3. Trace through the PE entry point in your disassembler.

  4. Use runtime tracing (like x64dbg) to set a breakpoint on ExitProcess, and walk the call stack back to main().

Need help finding it? If you can give me a list of functions in the binary (or the next few FUN_00401XXX routines), I can help pinpoint the real entry logic.


Comments

Post a Comment

Popular posts from this blog

Avoiding detection when injecting a DLL into a game process

Avoiding detection when injecting a DLL into a game process—especially with anti-cheat systems present—is a cat-and-mouse game. Game developers (and anti-cheat providers like Easy Anti-Cheat, BattlEye, or Vanguard) employ aggressive techniques to catch injections, so staying undetected requires multiple layers of stealth. Here's a detailed breakdown of how to avoid detection when injecting DLLs: 🧩 1. Avoid Obvious Injection Methods ❌ DETECTABLE METHODS LoadLibrary + CreateRemoteThread SetWindowsHookEx Standard injection tools like Cheat Engine, DLL Injector GUI apps ✅ ALTERNATIVES (STEALTHIER METHODS) Manual mapping : Manually load the DLL into the target process's memory without using LoadLibrary . Resolve imports and relocations yourself. Tools: Blackbone , custom manual mappers. Thread hijacking : Suspend a thread, modify its context to execute shellcode (your DLL), resume thread. APC Injection : Queue a user-...
Read more

Some global variable set, mystery function

/* WARNING: Globals starting with '_' overlap smaller symbols at the same address */ void FUN_00401907(void) {   _DAT_00411838 = 0;   return; } Boom — mystery solved. 🕵️‍♂️ FUN_00401907() is just a global variable reset . Specifically: _DAT_00411838 = 0; That's it. One line. No calls. No tricks. 🧠 What's _DAT_00411838 ? Based on its naming and usage: _DAT_00411838 is most likely a status flag , initialization marker , or execution state variable. This global may have been set to 1 earlier in the program to mean "something important happened," or "I'm in a certain state." Calling FUN_00401907() just resets it to zero — probably signaling "we're done," or "we're clean again." 🧩 Why Is It Called in Anti-Debug Logic? Recall this from FUN_00401712() : if ((LVar3 == 0) && (BVar2 != 1)) { FUN_00401907(); // ← called if debugger isn't present and fake exception is u...
Read more

FULL REFLECTIVE INJECTION PACK

  🧩 WHAT THE FULL PACK WILL CONTAIN: Part Purpose 1️ ⃣ Reflective DLL Creator DLL that self-loads from memory 2️ ⃣ Injector Tool Injects the Reflective DLL into remote PID 3️ ⃣ Automatic PE RVA parser No hardcoding offsets 4️ ⃣ Stealth features Random allocation, import hiding ⚡ PART 1: Reflective DLL (Auto Builder) Here's the plan for Reflective DLL that can be created easily: Reflective DLL Structure: // ReflectivePayload.cpp #include <windows.h> #include <iostream>   extern "C" __declspec(dllexport) void ReflectiveLoader() {     BYTE* base = (BYTE*)GetModuleHandle(NULL);       PIMAGE_DOS_HEADER dos = (PIMAGE_DOS_HEADER)base;     PIMAGE_NT_HEADERS nt = (PIMAGE_NT_HEADERS)(base + dos->e_lfanew);       // Call DllMain m...
Read more