[ERROR]Calling SendAttackPacket()

[martinx1]

Hi, i'm building a small hack but now, i'm having some problems on calling the SendAttackPacket() function.
This is my code for now:

void SendAttack(DWORD BinAddr) {
	DWORD *Target = (DWORD*)(BinAddr + 0x0019EC38);
	DWORD *TargetAdress = (DWORD*)(*Target + 0x73C);
	printf("TargetAdress: %d\n", *TargetAdress);
	DWORD FuncAddr = BinAddr + 0x1BF420;
	printf("FuncAddr: %d\n", FuncAddr);
	DWORD ClassPointer = BinAddr + 0x4846A4;
	_asm {
		MOV ECX, [ClassPointer]
		PUSH [Target]
		PUSH 0
		CALL FuncAddr
	}
}

I know it is a mess, I will optimize it as soon as i get this to work.

This is the error that is being showed:



And this is the memory region of the function:




This is my first time coding anything in _asm, but i have been reading a lot about it.

Hope somone can help.

[_asm]

create a function pointer rather than using inline assembler.

void SendAttackPacket(const uint32_t vid, const uint8_t mode)
{
    typedef bool(__thiscall* tSendAttackPacket)(int, const uint32_t, const uint8_t);
    const auto fSendAttackPacket = reinterpret_cast<tSendAttackPacket>(0xffffffff); /* SendAttackPacket Function Call */
    
    if (fSendAttackPacket)
        fSendAttackPacket(*reinterpret_cast<uintptr_t*>(0xffffffff), vid, mode); /* CNetworkStream Class Pointer Instance */
}

I suggest you to create a function pointer for the "Send" function since this allows you to simply pass packet structure rather than always finding the function call for the specific function.

btw, are you sure this is the correct disassembly output of "SendAttackPacket"? I don't see any instruction loading the reference of the packet structure into a register (LEA).

[martinx1]

Originally Posted by _asm

create a function pointer rather than using inline assembler.

void SendAttackPacket(const uint32_t vid, const uint8_t mode)
{
    typedef bool(__thiscall* tSendAttackPacket)(int, const uint32_t, const uint8_t);
    const auto fSendAttackPacket = reinterpret_cast<tSendAttackPacket>(0xffffffff); /* SendAttackPacket Function Call */
    
    if (fSendAttackPacket)
        fSendAttackPacket(*reinterpret_cast<uintptr_t*>(0xffffffff), vid, mode); /* CNetworkStream Class Pointer Instance */
}

I suggest you to create a function pointer for the "Send" function since this allows you to simply pass packet structure rather than always finding the function call for the specific function.

btw, are you sure this is the correct disassembly output of "SendAttackPacket"? I don't see any instruction loading the reference of the packet structure into a register (LEA).

Thanks for the answer, I will take a look in some definitions in your code, since some of them are unknown to me, and test it tomorrow.
I think this is the right "SendAttackPacket" function. But it could be wrong, but i tried brakepoints on the functions and the game always stoped when i attack some moob, and the top of the stack before the function call had the right VID. But i didn't post the full disassamble. Here is the rest if you want to check out:

[_asm]

It would actually be really helpful if you could show the full Disassembly including the offsets. I don't really know what's so super secret in your Disassembly except maybe your modulename which was exposed anyway in your last screenshot...

This function is indeed the SendAttackPacket function since it includes the Trace function if an error occurs and the Send function with it's appropriate parameters (0x02 as the packet header, 0x0A as the packet length). eax is a reference from ebp - 0x14 (lea eax, [ebp - 0x14]) - loads the effective address of the packet structure.
eax is then pushed onto the stack (eax is a void* used as a buffer which now includes all the data of the loaded struct).
The size is then pushed as its first parameter (0x0A). Finally, the Send function (BaseAddress + 0x1C0BB0) is called. After that, the return value of Send is tested against itself (test al, al) and the flag is set. al is the lower 8 bit register of eax.
If it's not equal, the trace function will be called and the function returns (xor al, al declares a local variable and makes sure the variable is zero; indicating the return value).

Assuming the packet was sent successfully to the server, it will set the return flag to 1, making sure the function has returned true and the SequenceByte will be appended to the packet by calling SendSequence (baseaddress + 0x3179E9)(CNetworkStream::SendSequence).
All the used registers are now popped off the stack (ebp) and the function returns the value that was previously set (1).

There are some compiler optimizations here and there but that shouldn't matter at all since the functions stays the same.
The easiest way to call this function is to either use the Send function with its packet structure and length or simply finding references to this function. Assuming SendAttackPacket is called from a different class, the class pointer of CNetworkStream should be easy to find.
All that's left to do now is writing yourself a function pointer with the function call address and class instance pointer.

PS: I forgot to mention that it's totally possible for the client to have ASLR enabled which can be annoying for debugging unless you already have some FindPattern algorithm or other workaround.

with kind regards,
_asm

[martinx1]

Originally Posted by _asm

It would actually be really helpful if you could show the full Disassembly including the offsets. I don't really know what's so super secret in your Disassembly except maybe your modulename which was exposed anyway in your last screenshot...

This function is indeed the SendAttackPacket function since it includes the Trace function if an error occurs and the Send function with it's appropriate parameters (0x02 as the packet header, 0x0A as the packet length). eax is a reference from ebp - 0x14 (lea eax, [ebp - 0x14]) - loads the effective address of the packet structure.
eax is then pushed onto the stack (eax is a void* used as a buffer which now includes all the data of the loaded struct).
The size is then pushed as its first parameter (0x0A). Finally, the Send function (BaseAddress + 0x1C0BB0) is called. After that, the return value of Send is tested against itself (test al, al) and the flag is set. al is the lower 8 bit register of eax.
If it's not equal, the trace function will be called and the function returns (xor al, al declares a local variable and makes sure the variable is zero; indicating the return value).

Assuming the packet was sent successfully to the server, it will set the return flag to 1, making sure the function has returned true and the SequenceByte will be appended to the packet by calling SendSequence (baseaddress + 0x3179E9)(CNetworkStream::SendSequence).
All the used registers are now popped off the stack (ebp) and the function returns the value that was previously set (1).

There are some compiler optimizations here and there but that shouldn't matter at all since the functions stays the same.
The easiest way to call this function is to either use the Send function with its packet structure and length or simply finding references to this function. Assuming SendAttackPacket is called from a different class, the class pointer of CNetworkStream should be easy to find.
All that's left to do now is writing yourself a function pointer with the function call address and class instance pointer.

PS: I forgot to mention that it's totally possible for the client to have ASLR enabled which can be annoying for debugging unless you already have some FindPattern algorithm or other workaround.

with kind regards,
_asm

Good detailed answer, I think i follow what you said. To find the SendAttackPacket() function i just search for the string "Send Battle Attack Packet error" go back to where that function is called, and the adress is a static one (Correct me if i'm wrong) in the 1st screenshot is (ModuleName + 0x1BF420), when i have time i will try to make a FindPattern algorithm.

I'm to busy this days, so i will try to implement and learn about what you mentioned before in my free times. Thanks for all your help, is good to have someone smart and available to explain these things.

And please dont close this thread for now, I might have some more questions later

[martinx1]

Sorry fo disturbing again, but after a while of testing and changing things I still didn't manage to put this working, it allways instant closes the client or crashes.

But 1st i have a question:
Use of ClassPointer Why the use of the ClassPointer in the function call?

Originally Posted by _asm

 
fSendAttackPacket(*reinterpret_cast<uintptr_t*>(0xffffffff), vid, mode); /* CNetworkStream Class Pointer Instance */

I thought the ClassPointer was stored in ECX (At least was what i read in somewhere).

Despite this question I started throwing the values in the code you show before. After a couple of tries and some reading on MSDN here is the code that i thought was the one that made more sense:

void SendAttackPacket(const uint8_t mode, const uint32_t vid)
{
	typedef bool(__thiscall* tSendAttackPacket)(int, const uint8_t, const uint32_t);
	const auto fSendAttackPacket = reinterpret_cast<tSendAttackPacket>(BinAdress + 0x1BF420); /* SendAttackPacket Function Call */

	if (fSendAttackPacket)
		fSendAttackPacket(*reinterpret_cast<uintptr_t*>((DWORD*)(0x0019EC38 + 0x08)), mode, vid); /* CNetworkStream Class Pointer Instance */
}

I changed the position of "mode" and "vid" since in the stack i saw that the VID was stored before the MODE, and in MSDN says that __thiscall pushes on to the stack from right to left.

For the ClassPointer i set a breakpoint and i grab the EBP register, and I saw that it was always the same, so i just copy the instruction "PUSH [EBP+0x08]" and replaced the EBP with its value 0x0019EC38.

Here is the disassambler with a breakpoint at the start of the function:


I tried to atach visual studio debugger but whenever i injected the DLL, the game crashed and the debugger just pointed to DLL_PROCESS_DETACH bypassing the ThreadCreation.

But without the debugger atached the thread was created and run quite well until reach the SendAttackPacket() function, that instantly closes the game without any error.

Altought, I know that the server isn't protected against this type of injection, since i can create a wallhack and it runs fine without errors. Most likely there is something that i dont understand on this.

[_asm]

I'm happy to hear your question!

Well first, the Class-Pointer needs to be casted to a uintptr_t hence the cast in the function call because the prototype states the following:

typedef bool(__thiscall* tSendAttackPacket)(int, const uint8_t, const uint32_t);

the int is ecx, also known as the Class-Pointer ecx. The __thiscall calling convention always has the classpointer (this) ecx as its first parameter (ebp + 0x04) and the other parameters follow like this ebp + 0x08 (1st parameter), ebp + 0x0C (2nd parameter).
According to your disassembly the Class-Pointer in this case clearly is Cymera.exe + 0x4846A4 as it gets stored inside ecx - making it clear that this is a __thiscall convention. More about __thiscall convention here

Your code will obviously crash since you can't use ebp + 8 as the Class-Pointer as explained above.
(EBP + 8 actually indicates the first parameter of the function; where ebp + 0xC is the second parameter.)

As for your concern whether ecx is the Class-Pointer, you're absolutely correct!
You have to use it in the function pointer like this:

void SendAttackPacket(const uint8_t mode, const uint32_t vid)
{
    typedef bool(__thiscall* tSendAttackPacket)(int, const uint8_t, const uint32_t);
    const auto fSendAttackPacket = reinterpret_cast<tSendAttackPacket>(Cymera.exe + 0x1BF420);
    
    if (fSendAttackPacket)
        fSendAttackPacket(*reinterpret_cast<uintptr_t*>(Cymera.exe + 0x4846A4), vid, mode);
}

And of you're correct, the mode is actually the first parameter and the vid the second since it's reversed on the stack.

Btw, you can show the absolute addresses in cheatengine. I think you can disable the module address in the view settings in cheat engine, allowing you to see the actual class-pointer.
I also recommend you using the "NetStream::Send" function rather than calling the function directly. Of course you'd have to hook the MainThread of the Client (you can use either OnUpdate or OnRender) and then execute your code from there since Metin2 is NOT threadsafe .

For comparison with the original code:

bool CPythonNetworkStream::SendAttackPacket(UINT uMotAttack, DWORD dwVIDVictim)
{
    if (!__CanActMainInstance())
        return true;

#ifdef ATTACK_TIME_LOG
    static DWORD prevTime = timeGetTime();
    DWORD curTime = timeGetTime();
    TraceError("TIME: %.4f(%.4f) ATTACK_PACKET: %d TARGET: %d", curTime/1000.0f, (curTime-prevTime)/1000.0f, uMotAttack, dwVIDVictim);
    prevTime = curTime;
#endif

    TPacketCGAttack kPacketAtk;

    kPacketAtk.header = HEADER_CG_ATTACK;
    kPacketAtk.bType = uMotAttack;
    kPacketAtk.dwVictimVID = dwVIDVictim;

    if (!SendSpecial(sizeof(kPacketAtk), &kPacketAtk))
    {
        Tracen("Send Battle Attack Packet Error");
        return false;
    }

    return SendSequence();
}

with kind regards,
_asm

[Lindeth]

Find out what [ebp+0xC] is and push it after vid. This should solve your problem if everything else is okay.

[martinx1]

Originally Posted by _asm

I'm happy to hear your question!

Well first, the Class-Pointer needs to be casted to a uintptr_t hence the cast in the function call because the prototype states the following:

typedef bool(__thiscall* tSendAttackPacket)(int, const uint8_t, const uint32_t);

the int is ecx, also known as the Class-Pointer ecx. The __thiscall calling convention always has the classpointer (this) ecx as its first parameter (ebp + 0x04) and the other parameters follow like this ebp + 0x08 (1st parameter), ebp + 0x0C (2nd parameter).
According to your disassembly the Class-Pointer in this case clearly is Cymera.exe + 0x4846A4 as it gets stored inside ecx - making it clear that this is a __thiscall convention. More about __thiscall convention here

Your code will obviously crash since you can't use ebp + 8 as the Class-Pointer as explained above.
(EBP + 8 actually indicates the first parameter of the function; where ebp + 0xC is the second parameter.)

As for your concern whether ecx is the Class-Pointer, you're absolutely correct!
You have to use it in the function pointer like this:

void SendAttackPacket(const uint8_t mode, const uint32_t vid)
{
    typedef bool(__thiscall* tSendAttackPacket)(int, const uint8_t, const uint32_t);
    const auto fSendAttackPacket = reinterpret_cast<tSendAttackPacket>(Cymera.exe + 0x1BF420);
    
    if (fSendAttackPacket)
        fSendAttackPacket(*reinterpret_cast<uintptr_t*>(Cymera.exe + 0x4846A4), vid, mode);
}

And of you're correct, the mode is actually the first parameter and the vid the second since it's reversed on the stack.

For comparison with the original code:

bool CPythonNetworkStream::SendAttackPacket(UINT uMotAttack, DWORD dwVIDVictim)
{
    if (!__CanActMainInstance())
        return true;

#ifdef ATTACK_TIME_LOG
    static DWORD prevTime = timeGetTime();
    DWORD curTime = timeGetTime();
    TraceError("TIME: %.4f(%.4f) ATTACK_PACKET: %d TARGET: %d", curTime/1000.0f, (curTime-prevTime)/1000.0f, uMotAttack, dwVIDVictim);
    prevTime = curTime;
#endif

    TPacketCGAttack kPacketAtk;

    kPacketAtk.header = HEADER_CG_ATTACK;
    kPacketAtk.bType = uMotAttack;
    kPacketAtk.dwVictimVID = dwVIDVictim;

    if (!SendSpecial(sizeof(kPacketAtk), &kPacketAtk))
    {
        Tracen("Send Battle Attack Packet Error");
        return false;
    }

    return SendSequence();
}

with kind regards,
_asm

I understand now, but the code is still showing the same error

I search for that, but i could't fix it, some says that this error only happens in some systems. Tomorrow i will create a virtual machine to test.

Originally Posted by _asm

Btw, you can show the absolute addresses in cheatengine. I think you can disable the module address in the view settings in cheat engine, allowing you to see the actual class-pointer

Yes i found it, but since i already show the module name, now i don't need it xD, but is good to know Thanks anyway.

Originally Posted by _asm

I also recommend you using the "NetStream::Send" function rather than calling the function directly. Of course you'd have to hook the MainThread of the Client (you can use either OnUpdate or OnRender) and then execute your code from there since Metin2 is NOT threadsafe .

I manage to find the function "NetStream::Send". But why can't I just call the function like this one? Does that mean that I can't call some code at the same time?
I think that this to damn hardcore to me xD, i mean, e can't even make this running clean.

May I add you on skype? Just to clarify some things.

Originally Posted by Lindeth

Find out what [ebp+0xC] is and push it after vid. This should solve your problem if everything else is okay.

[ebp+0xC] is 0 as you can see on this Screenshoot:
Thats why I wrote ("PUSH 0").
Thanks anyway

[Lindeth]

Originally Posted by martinx1

void SendAttack(DWORD BinAddr) {
	DWORD *Target = (DWORD*)(BinAddr + 0x0019EC38);
	DWORD *TargetAdress = (DWORD*)(*Target + 0x73C);
	printf("TargetAdress: %d\n", *TargetAdress);
	DWORD FuncAddr = BinAddr + 0x1BF420;
	printf("FuncAddr: %d\n", FuncAddr);
	DWORD ClassPointer = BinAddr + 0x4846A4;
	_asm {
		MOV ECX, [ClassPointer]
		PUSH [Target]
		PUSH 0
		CALL FuncAddr
	}
}

I see you push two things; mode and vid. But in disassembler there are three things being pushed. Find out what other is and push it like i said before. It doesn't matter if it's 0 or whatever.

Set the breakpoint on CALL x so you can easily see the pushed things on stack and right click to stack change to ebp* to be sure in your case.

[_asm]

Originally Posted by martinx1

May I add you on skype? Just to clarify some things.

Unfortunately (fortunately?) I've stopped using Skype for a long time now for various reason. I also don't like the idea of solving problems privately without letting the publicity be aware of the solution/problem.

[martinx1]

Originally Posted by Lindeth

I see you push two things; mode and vid. But in disassembler there are three things being pushed. Find out what other is and push it like i said before. It doesn't matter if it's 0 or whatever.

Set the breakpoint on CALL x so you can easily see the pushed things on stack and right click to stack change to ebp* to be sure in your case.

You were right!!! Finally its working!!!
I was so focused on the leaked source that i didn't even realize that this function (on this server) had 3 arguments instead of 2, [EBP+08] points to a value that change between this values(0x01000E00, 0x01000F00, 0x01001000 0x01001100) depending on the HIT type.

Here it is the final code if anyone needs

void SendAttackPacket(const uint32_t attack, const uint8_t mode, const uint32_t vid)
{
	typedef bool(__thiscall* tSendAttackPacket)(int, const uint32_t, const uint8_t, const uint32_t);
	const auto fSendAttackPacket = reinterpret_cast<tSendAttackPacket>(BinAdress + 0x1BF420); /* SendAttackPacket Function Call */

	if (fSendAttackPacket)
		fSendAttackPacket(*reinterpret_cast<uintptr_t*>(BinAdress + 0x4846A4), attack, mode, vid); /* CNetworkStream Class Pointer Instance */
}

Originally Posted by _asm

Unfortunately (fortunately?) I've stopped using Skype for a long time now for various reason. I also don't like the idea of solving problems privately without letting the publicity be aware of the solution/problem.

No problem, thanks anyway.

By the way, I was thinking in spam this function to a moob in order to create a DMG hack. But when i try it with less the 200ms diference, only the first hit can damage it. Is this from server side protection? or can i bypass it with the "CNetworkStream::Send" function?

[Lindeth]

Originally Posted by martinx1

By the way, I was thinking in spam this function to a moob in order to create a DMG hack. But when i try it with less the 200ms diference, only the first hit can damage it. Is this from server side protection? or can i bypass it with the "CNetworkStream::Send" function?

As far as i know it's limitted serverside. Try it with ninja.

And increase the sleep time for other characters. Find the ideal sleep time for them.

[martinx1]

Originally Posted by Lindeth

As far as i know it's limitted serverside. Try it with ninja.

And increase the sleep time for other characters. Find the ideal sleep time for them.

Ninja use other values for the Hit type, but is faster. I will try to use the Send() function anyway. I have nothing to lose, and I can improve my skills as coder.
Since the problem is resolved, the thread can be closed.

[aok96boom]

Originally Posted by martinx1

You were right!!! Finally its working!!!
I was so focused on the leaked source that i didn't even realize that this function (on this server) had 3 arguments instead of 2, [EBP+08] points to a value that change between this values(0x01000E00, 0x01000F00, 0x01001000 0x01001100) depending on the HIT type.

Here it is the final code if anyone needs

void SendAttackPacket(const uint32_t attack, const uint8_t mode, const uint32_t vid)
{
	typedef bool(__thiscall* tSendAttackPacket)(int, const uint32_t, const uint8_t, const uint32_t);
	const auto fSendAttackPacket = reinterpret_cast<tSendAttackPacket>(BinAdress + 0x1BF420); /* SendAttackPacket Function Call */

	if (fSendAttackPacket)
		fSendAttackPacket(*reinterpret_cast<uintptr_t*>(BinAdress + 0x4846A4), attack, mode, vid); /* CNetworkStream Class Pointer Instance */
}

No problem, thanks anyway.

By the way, I was thinking in spam this function to a moob in order to create a DMG hack. But when i try it with less the 200ms diference, only the first hit can damage it. Is this from server side protection? or can i bypass it with the "CNetworkStream::Send" function?

Kinda late but anyway,
i found CNetworkStream::Send function and here's the call to this function so i thought something like this to call it

PHP Code:

void call() {
    DWORD funcAddr = 0x0056DDB0;
    const char * data;
    int size;
    __asm {
        PUSH data
        PUSH size
        MOV ECX,DWORD PTR SS:[EBP-18]
        CALL funcAddr
    }
} 


i know it wont work so im waiting ur opinions on how should i continue.
Thanks