• Welcome to Valhalla Legends Archive.
 

[C#] Warden and Init()

Started by Ribose, December 21, 2008, 04:23 PM

Previous topic - Next topic

brew

So like, you totally just ignored my post.. which explains that those two apis it uses are part of the problem.....
<3 Zorm
Quote[01:08:05 AM] <@Zorm> haha, me get pussy? don't kid yourself quik
Scio te esse, sed quid sumne? :P

MyndFyre

Quote from: brew on January 07, 2009, 08:12 AM
So like, you totally just ignored my post.. which explains that those two apis it uses are part of the problem.....
Nevermind the fact that pretty much all your posts in the .net forum have historically been useless because you don't know about .net....

Quote from: Ribose on January 06, 2009, 09:09 PM
There is no stack trace for this exception, it's just sitting there pointing to no line of code, with no "View More Exception Detail" (or whatever it was...), and not caught by any try-catches I have.
That's because an MDA isn't an exception.  It's a .NET-provided breakpoint.  You should still be able to look at the call stack window in the debugger:

QuoteEvery generation of humans believed it had all the answers it needed, except for a few mysteries they assumed would be solved at any moment. And they all believed their ancestors were simplistic and deluded. What are the odds that you are the first generation of humans who will understand reality?

After 3 years, it's on the horizon.  The new JinxBot, and BN#, the managed Battle.net Client library.

Quote from: chyea on January 16, 2009, 05:05 PM
You've just located global warming.

brew

Quote from: MyndFyre[vL] on January 07, 2009, 10:15 AM
Quote from: brew on January 07, 2009, 08:12 AM
So like, you totally just ignored my post.. which explains that those two apis it uses are part of the problem.....
Nevermind the fact that pretty much all your posts in the .net forum have historically been useless because you don't know about .net....

It has more to do with logic than .NET actually:

Quote from: brew on January 06, 2009, 07:35 PM
...
   if (!strcmp(lpProcName, "AddVectoredExceptionHandler")) {
      return (FARPROC)nullsub;
   } else if (!strcmp(lpProcName, "RemoveVectoredExceptionHandler")) {
      return (FARPROC)nullsub2;
   }
...

Quote from: Ribose on January 06, 2009, 09:09 PM
and noticed "AddVectoredExceptionHandler" and "RemoveVectoredExceptionHandler". I noticed that those APIs are mentioned in the Reentrancy MDA page. Could this be a part of the problem?
<3 Zorm
Quote[01:08:05 AM] <@Zorm> haha, me get pussy? don't kid yourself quik
Scio te esse, sed quid sumne? :P

Ribose

Quote from: brew on January 07, 2009, 08:12 AM
So like, you totally just ignored my post.. which explains that those two apis it uses are part of the problem.....
uhh oh, sorry
Quote from: brew on January 06, 2009, 07:35 PM
Or you could do the sensible thing, like pass back a nullsub to the module if/when it requests it (for me it was screwing up debugging):


void __stdcall nullsub(int p1, int p2) {

}

void __stdcall nullsub2(int p1) {

}

FARPROC WINAPI MyGetProcAddress(HMODULE hModule, LPCSTR lpProcName) {
AddChatEx(vbYellow, "Module getting address to 0x%08x!%s() ...", hModule, lpProcName);
if (!strcmp(lpProcName, "AddVectoredExceptionHandler")) {
return (FARPROC)nullsub;
} else if (!strcmp(lpProcName, "RemoveVectoredExceptionHandler")) {
return (FARPROC)nullsub2;
}

return GetProcAddress(hModule, lpProcName);
}

Oh, I didn't look at it much, and didn't understand what you were getting at ("if/when it requests it" didn't tell me what you were getting at... you could have said that Add/RemoveVectoredExceptionHandler was the problem instead of just "it" :o).

Now reading it again, yeah, that does make sense... I already hijacked the GetProcAddress, so I guess I can hijack those two specific calls as well.

I just hijacked those two, but its getting to there and failing:
Quote
        GetProcAddress(2088763392, "AddVectoredExceptionHandler") = MY 3611266
        GetProcAddress(2088763392, "RemoveVectoredExceptionHandler") = MY 3611314
        TlsAlloc() = 31
        TlsSetValue(31, 0) = 1
        AddVectoredExceptionHandler(64944284, 0) = 0
        TlsFree(31) = 1
A first chance exception of type 'System.AccessViolationException' occurred
According to the page, AddVectoredExceptionHandler should return a valid pointer (as far as I can tell) to some handle...

@Myndfyre: when the MDA appears, the call stack window has been empty...

I just changed it so it gets its own ProcAddress again, and this time the MDA is pointing directly to the line:
pp_WardenFunctionList = new IntPtr(init((MyFuncList**) pp_MyFuncList));
and does have a call stack, which is exactly as I would expect (I also enabled "View External Code" in the call stack window, which may have done it):

[Managed to Native Transition]
green arrow Felbot.exe!Felbot.Protocol.WardenModule.InitializeModule() Line 696 + 0x3a bytes C#
Felbot.exe!Felbot.Protocol.WardenModule.RecieveWarden(byte[] encrypted = {byte[37]}) Line 180 + 0x8 bytes C#
Felbot.exe!Felbot.Protocol.BattleNetPacketThread.Recieve_SID_WARDEN(byte[] data = {byte[37]}) Line 1306 + 0x10 bytes C#
Felbot.exe!Felbot.Protocol.BattleNetPacketThread.ParsePacket(MBNCSUtil.DataReader dataReader = {MBNCSUtil.BncsReader}) Line 282 + 0x4e bytes C#
Felbot.exe!Felbot.Protocol.BattleNetPacketThread.Socket_Recieve(int length = 41) Line 3004 + 0x2d bytes C#
Felbot.exe!Felbot.Protocol.PacketThread..ctor.AnonymousMethod() Line 114 + 0x21 bytes C#
mscorlib.dll!System.Threading.ThreadHelper.ThreadStart_Context(object state) + 0x66 bytes
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) + 0x6f bytes
mscorlib.dll!System.Threading.ThreadHelper.ThreadStart() + 0x44 bytes
~Ribose