Slobcat1337, post: 139026, member: 42812 wrote:
I didnt realise that was against the rules, apologies.
No worries; now you know
In case you guys wondered why you can't attach a regular Windows debugger (not CE) to
InstanceServerG.exe, then the answer is the
DebugPort field in EPROCESS kernel structure is already set.
How did I get to that conclusion?
1) I tried x32dbg.exe (the x86 version of x64dbg debugger) and attempted to attach to InstanceServerG.exe. When doing that, I got this in the Log:
Code: Select all
"C:x64dbgx32x32dbg.exe"
Database file: C:x64dbgx32dbInstanceServerG.exe.dd32
Attach to process failed! GetLastError() = ERROR_IS_SUBSTED: An attempt was made to use a JOIN or SUBST command on a drive that has already been substituted.
Saving database to C:x64dbgx32dbInstanceServerG.exe.dd32 16ms
Debugging stopped!
2) I then attached x32dbg.exe with another instance of x32dbg.exe. The error message is generated when exiting a function called
AttachDebugger found in TitanEngine.dll (yes, Titan Engine is used to do a lot of the heavy lifting in x64dbg). More precisely,
NtDebugActiveProcess API returns error
0xC0000048.
3) Upon investigation I stumbled across this article:
[Link]. Give it a read, there's a lot of stuff that's interesting in there. What spiked my interest is something I've considered, but said to myself "nah, it can't be". I remember my old RE days back in 2008 when I was fiddling with
Armadillo. This protection came with something called a Debug-Blocker
The program executable spawned a main process (father), which in turn spawned a second process (child), whereas the 'father' would debug the 'child'. The result, aside from other features of the protection, would be the process you want to attach can't be attached:
4) The method to circumvent this, from the above: open the process with CE, set a breakpoint on
WaitForDebugEvent and when it's hit execute
DebugActiveProcessStop( InstanceServerG_pid ).
OR
5) Reset the
DebugPort pointer to 0 in EPROCESS kernel structure. For that you will need to let CE use dbk:
Code: Select all
dbk_initialize()
dbk_useKernelmodeOpenProcess()
dbk_useKernelmodeProcessMemoryAccess()
local pid = dbk_getPEProcess( getOpenedProcessID() )
repeat until( pid ~= 0x0 )
if pid ~= 0x0 then
writeQword( pid + 0x420, 0 )
end
What the above does: for the current CE session the script will initialize the kernel-mode debugger, make it so kernel OpenProcess and Read/Write Process Memory are used, get the EPROCESS address and NULL the DebugPort pointer found at 0x420 offset. Note that 0x420 may be different depending on your OS. I'm running
Windows 10 x64 Version 1909 (18363.900).
If you're on a different OS and want to use the above, then in order for you to figure out the DebugPort offset, you would need to use some random .exe. Run it. Open CE. Run the first 3 lines in the script above in Lua Engine (Memory Viewer > Ctrl+L), then right-click the process name in main CE GUI. You will see a pop-up where you're interested in the
PEProcess line (e.g.: PEProcess:FFFFB804E7FCC080). Go to that address in Memory Viewer, bottom hex window. Enlarge the window a bit so you can monitor the hex dump. And press Ctrl+Enter so you can see the display referenced by offsets rather than addresses. Then attach x32dbg.exe to your program and keep an eye on CE's dump. You will see a pointer filled-in in the 0x400 offset area. When you detach this will be set to 0. That's how you get your
offset (where in the EPROCESS structure is the DebugPort).
What can you now do after having run this: you can debug the game with any debugger out there (I'm not a fan of the CE debugger myself, hence why I wanted to use a tool I'm comfortable with when debugging).
Peace out,
Sun
