DLL Injection problem with 2.6.1.49177 PTR build

[R3peat]

ok did some research



the functions where objMgr pointers are used for example are packed/crypted inside the static binary

so static analysis of binary is nutz now. but a dump with scylla also doesnt work without proper fixes, it just doesnt load into IDA

[R3peat]

mhh i can easily load an x86 dump into ida just having those issues with x64 dump ._.

[R3peat]

here some infos what was added into WoW

i think what we see in d3 now are the same techs

The Free Lunch Is Over - Obfuscation is Coming

[d2k2]

it seems they intruduced a function to get the adress of the ObjectManager. Before it was just a static address

00007FF63B19F9EB | 0F 85 CF 06 00 00            | jne diablo iii64_dump.7FF63B1A00C0               |
00007FF63B19F9F1 | E8 9A F2 00 00               | call <diablo iii64_dump.GetObjectManager>        |
00007FF63B19F9F6 | 48 8B 98 08 0B 00 00         | mov rbx,qword ptr ds:[rax+B08]                   |
00007FF63B19F9FD | E8 8E F2 00 00               | call <diablo iii64_dump.GetObjectManager>        | GetObjectManager
00007FF63B19FA02 | 48 8B B0 08 0B 00 00         | mov rsi,qword ptr ds:[rax+B08]                   |
00007FF63B19FA09 | 48 83 3E 00                  | cmp qword ptr ds:[rsi],0                         |
00007FF63B19FA0D | 0F 84 AD 06 00 00            | je diablo iii64_dump.7FF63B1A00C0                |
00007FF63B19FA13 | E8 78 F2 00 00               | call <diablo iii64_dump.GetObjectManager>        |
00007FF63B19FA18 | 48 83 B8 10 0B 00 00 00      | cmp qword ptr ds:[rax+B10],0                     |
00007FF63B19FA20 | 74 26                        | je diablo iii64_dump.7FF63B19FA48                |
00007FF63B19FA22 | 83 C9 FF                     | or ecx,FFFFFFFF                                  |

i am not able to debug it. so my question is:
do you think the ObjectManager address is even changing in a running instance, so that we have to call the function everytime to get the actuall adress?

[R3peat]

saw that aswell and it has some fancy code in it

void __usercall sub_1403BEDC0(__int64 a1@<rax>, __int64 a2@<rdx>, unsigned int a3@<ebp>, __int64 _RDI@<rdi>, __int64 a5@<rsi>)
{
char v6; // t0
unsigned __int8 v7; // of
__int64 v8; // rax
unsigned int v10; // et0
bool v11; // zf
unsigned int v12; // et1
unsigned int v13; // eax
bool v14; // cf
unsigned int v15; // et2
int v16; // esp
unsigned __int32 v17; // eax
_BYTE *v18; // [rsp-8h] [rbp-8h]
_BYTE *retaddr; // [rsp+0h] [rbp+0h]

_RCX = retaddr;
BYTE1(a2) -= *(_BYTE *)(a1 + 2 * a5 - 615260694);
JUMPOUT(BYTE1(a2), 0, &loc_1403BED7A);
v6 = *(_BYTE *)(_RDI + 1574983790);
LOWORD(a3) = -30357;
v7 = __OFSUB__((_BYTE)a2, -110);
LOBYTE(a2) = a2 + 110;
JUMPOUT(((a2 & 0x80u) != 0i64) ^ v7 | ((_BYTE)a2 == 0), &loc_1403BED86);
v10 = a1;
v8 = (unsigned int)a5;
for ( _RSI = v10; ; _RSI = (unsigned __int64)v18 )
{
v11 = (v16 & *(_DWORD *)(v8 + _RSI - 34)) == 0;
if ( v11 )
break;
v12 = v8;
v13 = a2;
a2 = v12;
_RDI = (unsigned int)(13 * _RDI);
__asm { outsd }
LOBYTE(v13) = MEMORY[0xA721E20633A3267A];
v14 = *(_BYTE *)(v12 + 0x54i64) < (unsigned __int8)v12;
*(_BYTE *)(v12 + 0x54i64) -= v12;
if ( !v14 )
{
*_RCX += BYTE1(v13) + v14;
__asm { rcr dword ptr [rdi+19h], cl }
MEMORY[0x31049EF932A7562E] = v13;
*(_RCX - 1666009353) += BYTE1(a2);
v11 = *(_DWORD *)(a2 + 1394316612) == -587438789;
__halt();
JUMPOUT(*(_QWORD *)&byte_1403BEE1F);
}
v18 = _RCX;
*(_DWORD *)(_RCX - 109) += _RDI;
v15 = v13;
v8 = a3;
a3 = v15;
_RCX = (_BYTE *)(*(_DWORD *)(_RSI - 287090625) ^ (unsigned int)_RCX);
LOBYTE(v8) = __inbyte(0x8Du);
}
v17 = __indword(a2);
JUMPOUT(*(_QWORD *)byte_1403BEE69);
}

[R3peat]

it seems they intruduced a function to get the adress of the ObjectManager. Before it was just a static address

00007FF63B19F9EB | 0F 85 CF 06 00 00            | jne diablo iii64_dump.7FF63B1A00C0               |
00007FF63B19F9F1 | E8 9A F2 00 00               | call <diablo iii64_dump.GetObjectManager>        |
00007FF63B19F9F6 | 48 8B 98 08 0B 00 00         | mov rbx,qword ptr ds:[rax+B08]                   |
00007FF63B19F9FD | E8 8E F2 00 00               | call <diablo iii64_dump.GetObjectManager>        | GetObjectManager
00007FF63B19FA02 | 48 8B B0 08 0B 00 00         | mov rsi,qword ptr ds:[rax+B08]                   |
00007FF63B19FA09 | 48 83 3E 00                  | cmp qword ptr ds:[rsi],0                         |
00007FF63B19FA0D | 0F 84 AD 06 00 00            | je diablo iii64_dump.7FF63B1A00C0                |
00007FF63B19FA13 | E8 78 F2 00 00               | call <diablo iii64_dump.GetObjectManager>        |
00007FF63B19FA18 | 48 83 B8 10 0B 00 00 00      | cmp qword ptr ds:[rax+B10],0                     |
00007FF63B19FA20 | 74 26                        | je diablo iii64_dump.7FF63B19FA48                |
00007FF63B19FA22 | 83 C9 FF                     | or ecx,FFFFFFFF                                  |

i am not able to debug it. so my question is:
do you think the ObjectManager address is even changing in a running instance, so that we have to call the function everytime to get the actuall adress?

if it "encrypts" the pointer it prbly does it at runtime so it will yield different results all the time

[enigma32]

if it "encrypts" the pointer it prbly does it at runtime so it will yield different results all the time

When dumping all modules, I could see that one of them had import on this: EncodePointer function (Windows) . Not sure if used or not, but it would make sense if they encrypt the static pointers. It would mean that memory reading won't work by itself (would read "garbage") and that injection is required, or hi-jacking the encrypt/decrypt functions.

[SeaDragon]

function GetObjectManager--<Diablo III.exe+367130>
{
...
mov [ebp-04],04162E2C
Diablo III.exe+367139 - lea eax,[ebp-04]
Diablo III.exe+36713C - mov [ebp-04],04162E2C key1
Diablo III.exe+367143 - push eax
Diablo III.exe+367144 - lea eax,[ebp-08]
Diablo III.exe+367147 - mov [ebp-08],91483E0C key2
Diablo III.exe+36714E - push eax
Diablo III.exe+36714F - mov eax,"Diablo III.exe"+A8CFC //The base pointer seems to have called this function
Diablo III.exe+367154 - call eax //Function call,Whether or not to change[ebp-04]，[ebp-08]
...

//The code seems to be deciphering

}

[R3peat]

When dumping all modules, I could see that one of them had import on this: EncodePointer function (Windows) . Not sure if used or not, but it would make sense if they encrypt the static pointers. It would mean that memory reading won't work by itself (would read "garbage") and that injection is required, or hi-jacking the encrypt/decrypt functions.

cant even inject cause theres some protection aswell or its due to the encryption of certaint memory regions

[bastiflew]

deleted ---

[xblade2k7]

This seems the end of an era :gusta:

[R3peat]

nah its not. it just adds some delay

[krxstal]

well, i'm hardstuck at objmgr. everything else seems fine just from looking over it in dbg and reclass.

i have an idea where its called but i have no clue how to read the & of it

[bastiflew]

deleted ---

[bastiflew]

deleted ---