Integrity Checking


uint FUN_00401863(void)

{
  HMODULE pHVar1;
  int *piVar2;
 
  pHVar1 = GetModuleHandleW((LPCWSTR)0x0);
  if ((((pHVar1 != (HMODULE)0x0) && ((short)pHVar1->unused == 0x5a4d)) &&
      (piVar2 = (int *)((int)&pHVar1->unused + pHVar1[0xf].unused), *piVar2 == 0x4550)) &&
     ((pHVar1 = (HMODULE)0x10b, (short)piVar2[6] == 0x10b && (0xe < (uint)piVar2[0x1d])))) {
    return CONCAT31(1,piVar2[0x3a] != 0);
  }
  return (uint)pHVar1 & 0xffffff00;
}



You're looking at another low-level helper function — FUN_00401863() — and this one's a stealthy check on the PE header of the current module (i.e. the executable itself). Let's unpack it.

🔍 What Does FUN_00401863() Do?

It appears to:

  • Access the current process module (your EXE) via GetModuleHandleW(NULL)

  • Verify it's a valid PE (Portable Executable) file

  • Check if a certain field in the PE Optional Header is non-zero

  • Return a uint indicating the result

🧠 Let's Break It Down

1. Get Handle to Current Module

pHVar1 = GetModuleHandleW(NULL);

  • Returns a handle to the base address of the current executable image.

  • Essentially: pHVar1 == (HMODULE) base address of EXE

2. Verify MZ Header

(short)pHVar1->unused == 0x5a4d

  • 0x5A4D = 'MZ' signature (DOS stub header at start of PE file)

3. Locate PE Header

piVar2 = (int *)((int)&pHVar1->unused + pHVar1[0xf].unused);  *piVar2 == 0x4550

  • Accesses the offset stored in the DOS header (e_lfanew)

  • Verifies the PE signature: 0x00004550 = 'PE\0\0'

4. Validate PE32 (Not PE32+)

(short)piVar2[6] == 0x10b

  • Optional header magic value:

    • 0x10B → PE32

    • 0x20B → PE32+

5. Check if Field Exists and Is Non-Zero

(0xe < (uint)piVar2[0x1d]) && piVar2[0x3a] != 0

This is checking:

  • If the Optional Header is large enough (SizeOfOptionalHeader > 0xe)

  • Then accessing and evaluating piVar2[0x3a] → unknown field in context

Note:

  • piVar2[0x3a] = field at offset 0xE8 from PE header (assuming piVar2 points to PE header)

This could be:

  • A custom field inserted by a packer, protector, or malware stub

  • Or maybe it's reading LoaderFlags, Win32VersionValue, or another optional header value

✅ Return Value

return CONCAT31(1, piVar2[0x3a] != 0);

  • If the field is non-zero, returns something like 0x00000001

  • Otherwise returns 0x00000000

If any checks fail, it falls through to:

return (uint)pHVar1 & 0xffffff00;

  • Returns a high-byte-only value (e.g., 0x100, 0x200), likely representing failure

💡 So What's the Purpose?

This function is:

  • Validating its own PE structure

  • Checking a custom or rare PE header field

  • Returning a status flag

🛠️ Use Cases

Possible Intent Description
✅ Legit integrity check Making sure the executable hasn't been tampered with
🧪 Packer stub Checking if it's been unpacked or altered
🧼 Clean start check Verifies certain state before cleanup/init
🔐 Malware evasion Some malware checks for field changes or injectors

🔎 Want to Dig Deeper?

If you can provide a memory dump, or tell me what value is in piVar2[0x3a], I can help you identify exactly what field this is and why it matters.

Also, if you're analyzing a suspicious binary or unpacking something, this kind of function is a classic anti-analysis trick.


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