VEH = Vectored Exception Handling

VEH Hooking is very powerful and stealthy. Let's break it down super clearly:

๐Ÿ“š What is VEH Hooking?

VEH = Vectored Exception Handling.

In Windows, a VEH is a custom function you can register that catches exceptions (errors) when your program crashes, before normal Structured Exception Handling (SEH) kicks in.

๐Ÿ‘‰ Hackers and malware use VEH to catch and modify execution flow without touching the original code on disk!

๐Ÿง  Simple logic:

  • Instead of overwriting functions (like inline hooking), you register a handler.

  • Then you force a controlled exception (like a memory access violation).

  • When the exception happens, Windows calls your VEH.

  • Your VEH modifies context (the CPU registers) and redirects execution to your shellcode or payload.

✨ No patching code, no visible jumps — it's extremely stealthy.

๐Ÿ› ️ How to Set Up a VEH Hook:

  1. Call AddVectoredExceptionHandler(1, MyHandlerFunction);

    • (1) = call this handler first if multiple handlers are registered.

    • MyHandlerFunction = your custom code to run when exceptions happen.

  2. Make something crash intentionally:

    • Access forbidden memory (mov eax, [0x00000000]).

    • Or trigger a STATUS_GUARD_PAGE_VIOLATION.

  3. When exception happens, Windows calls your VEH handler.

  4. Inside the VEH, you can:

    • Fix the crash.

    • Change EIP/RIP (Instruction Pointer) to jump to your shellcode.

    • Resume execution.

๐Ÿ“œ Simple Code Example (C++)

LONG WINAPI MyVEH(EXCEPTION_POINTERS* ExceptionInfo) {      // If it's the kind of exception we want      if (ExceptionInfo->ExceptionRecord->ExceptionCode == EXCEPTION_ACCESS_VIOLATION) {          // Redirect execution          ExceptionInfo->ContextRecord->Rip = (DWORD64)MyShellcode;  // x64          return EXCEPTION_CONTINUE_EXECUTION;      }      return EXCEPTION_CONTINUE_SEARCH;  }    void SetupVEH() {      AddVectoredExceptionHandler(1, MyVEH);  }

๐Ÿ”Ž Now whenever an access violation happens ➔ your shellcode runs.

๐ŸŽฏ Why is VEH Hooking Dangerous (and interesting)?

Feature Why it matters
๐Ÿ›ก️ No code modification Nothing obvious in disassembly. No JMP inserted.
๐Ÿ‘ป Hard to detect Code looks clean, AV/EDR tools have trouble seeing the hook.
๐ŸŽฏ Full control You can hijack execution at any point you can trigger an exception.
๐Ÿ”ฅ Powerful for exploit dev Especially in ROP chains, privilege escalations, shellcode loaders.

๐Ÿงจ Bonus: Even Smarter VEH Tricks

  • Page Guard VEH: Mark memory with PAGE_GUARD, and handle page accesses one by one.

  • VEH Shellcode: Some advanced malware installs a VEH and then erases itself from memory.

๐Ÿ‘€ Memory view when VEH is active:

  • No changes to function bytes.

  • Exception handling table has extra entries.

  • New handlers visible via:

    • WinDbg command: !veh

    • x64dbg Plugin: "VEH Breakpoints" tab.

๐Ÿ”ฅ Summary:

Term Meaning
VEH A special way to handle exceptions before SEH.
VEH Hooking Using exceptions + VEH to redirect code execution stealthily.

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