MCommandParameterString

[PenguinGuy]

I can't figure out what the problem is. Currently, I am able to create a custom packet,
add parameters and send it to the server. However, if one of those parameters is a string, my client will crash. Very few times will my client actually send it without crashing

As an example, if I send the packet Channel.Request.Chat, my client goes "lol no" and dies.

MCommandParameterString:

typedef MCommandParameterString*( __thiscall* MCommandParameterStringType )( MCommandParameterString*, char* szValue );
MCommandParameterStringType MCommandParameterStringConstructor = reinterpret_cast<MCommandParameterStringType>( MCommandParameterStringAddress );

//
//

class MCommandParameterString : public MCommandParameter
{
public:
    char* m_szValue;

    MCommandParameterString( char* szValue );
};

//
//

MCommandParameterString::MCommandParameterString( char* szValue )
{
	MCommandParameterStringConstructor( this, szValue );
}

The part to send the packet:

MCommand* pCmd = MCommand::Create( 0x4C9 );

pCmd->AddParameter( new MCommandParameterMUID( &pCmd->m_pCommandDesc->m_uidSender ) );
pCmd->AddParameter( new MCommandParameterMUID( ( uidChannel ) );
pCmd->AddParameter( new MCommandParameterString( "Lol?" ) );

MCommand::Post( pCmd );

(I will post what the actual error shows in Gunz in a few;)

Edit-
I hooked MMatchServer::OnCommand, and the server does get the chat string.
Here's what the dump says;

Dump Summary
------------
Dump File: Gunz.dmp : C:\Users\admin\Desktop\Gunz\TG Developments\Client\Gunz.dmp
Last Write Time: 12/20/2010 6:35:38 PM
Process Name: thedueldll.exe : C:\Users\adminDesktop\Gunz\TG Developments\Client\thedueldll.exe
Process Architecture: x86
Exception Code: 0xC0000005
Exception Information: The thread tried to read from or write to a virtual address for which it does not have the appropriate access.
Heap Information: Not Present

[MentaL]

[dacharles]

I had the same Fucking problem, the problem is this:


When the command is sended the deconstructors for all the MCommandParameter classes are called and all are at vftable+0xC or something like that, this use the original mcommandparameter classes from gunz and all the mcommandparamter deconstructors(~String,~Int,~Vector,etc) are at vftable+0xC but when you try to recreate all the mcommandparameter classes, all of vftable are in the same place like the originals, except the String deconstructor, just that fucking function

Now I guess I fixed it hooking ClearParam (this is where all the deconstructors are called) and calling to OUR deconstructors will fix it.

CSIMPLEDETOUR_NOARGS( MCommand__ClearParam, MCommand ) 
{
	for( int i = 0; i != pInstance->m_pCommandParams.size(); i++ )
	{
		delete pInstance->m_pCommandParams[i];
	}
	pInstance->m_pCommandParams.clear();
}

sorry if my englich is weirdo.

[PenguinGuy]

Thank you for your suggestion, but I don't think it get's called like that.
I was wondering why I was experiencing the same crash, so I tested;

CDetour MCommandClearParamDet;
void MCommandClearParamHook( )
{
	MessageBoxA( NULL, "MCommand::ClearParam", "", MB_OK );

	MCommandClearParamDet.Org( );
}

It never gets called.
Edit- Lol, the only time it got called was when Gunz was closing.

[Linear88]

Yeah, I've been experiencing this problem too, annoys me.

Also, ClearParam gets called after posting any command, it gets called at the server select screen. (request server status info)

[PenguinGuy]

Yeah, I've been experiencing this problem too, annoys me.

Also, ClearParam gets called after posting any command, it gets called at the server select screen. (request server status info)

Odd, ClearParam was only called after I closed Gunz.

[jewness12]

virtual function table
nevermind

I don't get the same problem.

[PenguinGuy]

struct MCommandParameter
{
	void* operator new( size_t nSize )
	{
		return ( ( void*( __cdecl* )( int ) )0x00607EBE )( nSize );
	}

Herp derp

[dacharles]

Why you use that?