Question Overwatch — External Entity List Linking & Component Decryption

[byte_corvus]

Struggling with entity linking in Overwatch? If you're dumping a raw list of 8k entries but your actual matched entity count is sitting at flat zero, you're likely hitting a wall with unique ID matching or component decryption.

Updating an old external base requires more than just swapping the Address_entity_base. You need to ensure your model component linking is actually hitting the right IDs. When your map fills up but the match fails, the culprit is usually the offset for the unique_id within the decrypted component or a mismatch in the entity map's ID collection logic.

Current Working Offsets
Use these signatures to verify your build:

namespace OW {
    namespace offset {
        uintptr_t Address_viewmatrix_base = 0x39C0600;
        uintptr_t Address_entity_base = 0x3A19628;
        uintptr_t gkey_ptr = 0x3B76970;
        uintptr_t byte_key = 0x3863B94;
        uintptr_t vis_var_byte = 0x3863660;
        uintptr_t outline_byte_key = 0x3863094;
        uintptr_t component_key_relative = 0x8;
    }
}

Component Decryption Routine
Overwatch uses a chain of rotations and XORs for its components. If your

DecryptComponent

is returning valid-looking pointers but matches still fail, verify the bitmask logic and the gkey pointer relative offsets.

Spoiler: Full Decryption Logic

inline uint64_t DecryptComponent(uintptr_t entity, uint8_t compId)
{
    uint64_t bitPosition = compId & 0x3F;
    uint64_t compBitMask = (1ull << bitPosition);
    uint64_t prefixBitsMask = compBitMask - 1;
    uint64_t groupIndex = compId >> 6;
    uint64_t compBitMap = SDK->RPM<uint64_t>(entity + 8 * groupIndex + 0x110);
    uint8_t indexByte = SDK->RPM<uint8_t>(entity + groupIndex + 0x130);
    if (!(compBitMap & compBitMask)) return 0;
    uint64_t indexCalc = indexByte + __popcnt64(compBitMap & prefixBitsMask);
    uint64_t compBase = SDK->RPM<uint64_t>(entity + 0x80);
    uint64_t component_index_value = SDK->RPM<uint64_t>(compBase + (indexCalc * 8));
    uint64_t enc = component_index_value;
    enc = ROR8(enc, 30);
    enc += 0x4F609B1743A3E058ULL;
    enc ^= 0xB9A5C29BAC360E7CULL;
    enc = ROR8(enc ^ 0x8340B7F80E6D5936ULL, 56);
    enc -= 0x0D3FF3C5F22A31B5ULL;
    enc ^= 0xEFC6613913D6CC73ULL;
    enc -= 0x737F74F54C836700ULL;
    uint8_t xor_byte = SDK->RPM<uint8_t>(SDK->dwGameBase + offset::byte_key);
    uint64_t xor_qword_ptr = SDK->RPM<uint64_t>(SDK->RPM<uint64_t>(SDK->dwGameBase + offset::gkey_ptr) + offset::component_key_relative);
    enc = xor_qword_ptr ^ (uint64_t)xor_byte ^ ((enc << 10) | (enc >> 54));
    enc -= 0x19897EFF1A06AF98ULL;
    uint64_t masked_upper = (compBitMask & compBitMap) >> bitPosition;
    return enc & (0 - (int64_t)masked_upper);
}

Entity Linking Failure Points

1. Checking the wrong ID offset: In the current build, model components (CompId 4 or 0x34) usually hold the unique_id at

   +0xD4

   .
2. Map population: The raw entity list often yields ~8k entries, but only a fraction are active actors. Ensure you're scanning

   0x130, 0x134, 0x138, 0x13C

   when building your ID-to-entity map.
3. Visibility Checks: If linking works but your ESP is blank, verify the

   CheckVisibility

   logic which resides at

   VisBase + 0x98

   with its own decryption chain.

While others are struggling with broken public visuals and flickering boxes, Infocheats users are digging into the component architecture to build stable, performance-oriented external solutions. Proper entity linking is the difference between a legit-looking ESP and a buggy mess that drops actors every two seconds.

Who's managed to get successful matches with the model component unique_id at 0xD4 recently?