find-CBaseEntity_GetChangeAccessorPathInfo_1

Find CBaseEntity_GetChangeAccessorPathInfo_1

Locate CBaseEntity_GetChangeAccessorPathInfo_1 vfunc in CS2 server.dll or libserver.so using IDA Pro MCP tools.

Background

CBaseEntity overrides two separate CEntityInstance interface methods, GetChangeAccessorPathInfo_1 and GetChangeAccessorPathInfo_2, with byte-for-byte identical implementations (both simply forward to the same internal lazy-init helper at the same member offset). Because the source bodies are identical, the compiler may fold both vtable slots onto the exact same function address, or it may still emit two separate but structurally identical functions. CBaseEntity_GetChangeAccessorPathInfo_2 is already resolved (it inherits its vtable slot from CEntityInstance_GetChangeAccessorPathInfo_2); CBaseEntity_GetChangeAccessorPathInfo_1 occupies a different slot within +/-2 entries of it in the same CBaseEntity vtable.

Method

1. Load CBaseEntity_GetChangeAccessorPathInfo_2 from YAML

ALWAYS Use SKILL /get-func-from-yaml with func_name=CBaseEntity_GetChangeAccessorPathInfo_2.

If the skill returns an error, STOP and report to user.

Otherwise, extract:

• func_va (the reference implementation address)
• vfunc_index
• vfunc_offset
• vtable_name (should be CBaseEntity)

2. Load CBaseEntity VTable from YAML

ALWAYS Use SKILL /get-vtable-from-yaml with class_name=CBaseEntity.

If the skill returns an error, STOP and report to user.

Otherwise, extract:

• vtable_numvfunc
• vtable_entries

3. Enumerate Candidate Slots

Compute the scan window around the known slot:

• window_start = max(0, CBaseEntity_GetChangeAccessorPathInfo_2.vfunc_index - 2)
• window_end = min(vtable_numvfunc - 1, CBaseEntity_GetChangeAccessorPathInfo_2.vfunc_index + 2)

For every index i in [window_start, window_end] except CBaseEntity_GetChangeAccessorPathInfo_2.vfunc_index itself, read the candidate function address vtable_entries[i].

4. Check for Identical-Address Folding First

Compilers (MSVC /OPT:ICF, GCC/Clang identical code folding) commonly merge functions with byte-identical bodies into a single implementation, so multiple vtable slots end up pointing at the same address.

For each candidate index i:

• If vtable_entries[i] == CBaseEntity_GetChangeAccessorPathInfo_2.func_va, this slot is folded onto the same implementation and is an immediate match. Record i as target_vfunc_index and stop scanning further.

5. Otherwise, Decompile and Compare Candidates

If no candidate address matched directly, decompile the reference function and every remaining candidate:

mcp__ida-pro-mcp__decompile addr="<CBaseEntity_GetChangeAccessorPathInfo_2_func_va>"
mcp__ida-pro-mcp__decompile addr="<candidate_func_addr>"

Windows (server.dll)

The reference implementation is a one-line forwarder:

__int64 __fastcall CBaseEntity_GetChangeAccessorPathInfo_2(__int64 a1)
{
  return sub_180184630(a1 + 56);
}

A matching candidate must be structurally identical:

1. Takes a single (__int64 a1) argument (this only)
2. Directly tail-calls the exact same helper address as the reference (e.g. sub_180184630)
3. Passes the exact same constant offset argument (a1 + 56)
4. Returns the helper's result unchanged

Linux (libserver.so)

The reference implementation is a lazy-init pattern:

__int64 __fastcall CBaseEntity_GetChangeAccessorPathInfo_2(__int64 a1)
{
  __int64 result;
  ...
  result = *(_QWORD *)(a1 + 64);
  if ( !result )
  {
    result = operator new(384);
    ...
    *(_QWORD *)(a1 + 64) = result;
  }
  return result;
}

A matching candidate must:

1. Read/write the exact same member offset as the reference (a1 + 64)
2. Allocate the exact same size via operator new (384)
3. Initialize the same set of fixed fields at the same relative offsets (+56, +24, +40, +48, +96 .. +352, etc.)
4. Return the same lazily-initialized pointer

6. Confirm the Match

Among the scanned candidates (excluding the known _2 slot), exactly one should match either by identical address (Step 4) or by identical decompiled structure (Step 5). That candidate is CBaseEntity_GetChangeAccessorPathInfo_1.

If zero or more than one candidate match, STOP and report to user.

7. Write IDA Analysis Output as YAML

ALWAYS Use SKILL /write-vfunc-as-yaml to write the analysis results.

Required parameters:

• func_name: CBaseEntity_GetChangeAccessorPathInfo_1
• func_addr: <matched_func_addr>
• func_sig: None
• vfunc_sig: None

VTable parameters:

• vtable_name: CBaseEntity
• vfunc_offset: <target_vfunc_index * 8> in hex
• vfunc_index: <target_vfunc_index>

Function Characteristics

• Purpose: Lazily creates/returns the change-accessor path-info object for this entity; implementation is identical to CBaseEntity_GetChangeAccessorPathInfo_2, distinguished only by its vtable slot
• Binary: server.dll / libserver.so
• Parameters: (this) only
• Return value: Pointer to the lazily-allocated path accessor object stored at a fixed member offset

Discovery Strategy

1. Reuse the existing CBaseEntity_GetChangeAccessorPathInfo_2 YAML to obtain the reference address and known slot
2. Reuse the existing CBaseEntity_vtable YAML to scan the +/-2 neighboring slots
3. Prefer an identical-address (ICF-folded) match; fall back to structural decompile comparison
4. Generate a stable func_sig from the resolved candidate body

This is robust because:

• The two overrides are guaranteed byte-identical in source, so either the compiler folds them to one address or their decompiled structure will be indistinguishable except for the vtable slot
• Scanning a narrow +/-2 window avoids false positives from unrelated vtable entries
• The final YAML stores both the resolved function signature and the precise vtable metadata

Output YAML Format

The output YAML filename depends on the platform:

• server.dll -> CBaseEntity_GetChangeAccessorPathInfo_1.windows.yaml
• libserver.so -> CBaseEntity_GetChangeAccessorPathInfo_1.linux.yaml