[CODE]Ingame Functions( POST YOUR FINDINGS HERE )

[chelmatt]

how do i include move to position and warp on my clua with the your codes on the first page? tnx.

[ntKid]

Originally Posted by chelmatt

how do i include move to position and warp on my clua with the your codes on the first page? tnx.

You will have to get the CLua source, get the game.bin from the katar update ( offset reference ), add and register the functions to the lua table, compile the source and set the Macro.lua to your needs. If you are not used to work with MSVC you can wait for the new CLua compilation, i am waiting for the next official game update to entirely patch CLua so i can try to update the old and newer codes.

Thx for your feedback, cheers.

[chelmatt]

tnx for the response. seems like a lot of work for the likes of me. i guess i'll wait for the patched clua. ^_^

[AlainProvist]

Originally Posted by ntKid

Very nice Alain but i still think you are making your life very hard by not being in the process context, if you are using C/C++ why not perform a DLL injection?

Originally Posted by ntKid

check if eax is valid to read before reading it, you may be trying to read something that it is still not created or being deleted, "IsBadReadPtr" eax before assuming it is a valid pointer. imagine if the eax = 0 and you do mov eax, [ eax ] it will try to read a invalid memory region.
If you are concerned about multithread you can detour the functions that you are going to call and add a critical section

INT ( WINAPI *pDetoured )( );
INT WINAPI myDetoured( )
{
INT dwRes = NULL;
EnterCriticalSection( &cs );
dwRes = pDetoured( );
LeaveCriticalSection( &cs );
return dwRes;
}

cheers.

Yeah I've switched from asm code to C code to make a ThreadSafeReadAddress function reading adresses safely. In another hand what I got in the crash I described was not a null address but an invalid address (either fucked addr or simply not commited addr) :'(. Can't do anything for this I suppose...

I'll try the EnterCriticalSection( &cs ); solution with detouring calls too. Seems a bit safer than calling game function like I did until now (additionnaly to my random crashes I got some crazy rendering bugs too like sort of thermic vision oO).

I tried today to detour dinput8's GetDeviceState() to be able to fake key presses and I'm completely shoked to see that the keyboard buffer returned
by each frame call from the game is always set to 0... How the hell do they treat their inputs ?!

HRESULT __stdcall hkGetDeviceState(LPDIRECTINPUTDEVICE lpDevice, DWORD cbData, LPVOID lpvData) 
{ 
	static BYTE buffer[256]; 
	HRESULT temp = DI_OK;

	temp = pGetDeviceState(lpDevice, cbData, lpvData); // original code

	if(cbData != 256)
		return temp;
	
	{  
		for (DWORD i = 0; i < 256; ++i)  
		{  
			if(((BYTE*)lpvData)[i]!=buffer[i])
				add_log("Key 0x%X %s", i, (((BYTE*)lpvData)[i]&0x80) ? "pressed" : "released");
		}  
	}

	memcpy(buffer, lpvData, cbData);
	return temp; 
}

I tried this code on another game using dinput8 and it works perfectly...

[ntKid]

Originally Posted by AlainProvist

I tried today to detour dinput8's GetDeviceState() to be able to fake key presses and I'm completely shoked to see that the keyboard buffer returned
by each frame call from the game is always set to 0... How the hell do they treat their inputs ?!

HRESULT __stdcall hkGetDeviceState(LPDIRECTINPUTDEVICE lpDevice, DWORD cbData, LPVOID lpvData) 
{ 
	static BYTE buffer[256]; 
	HRESULT temp = DI_OK;

	temp = pGetDeviceState(lpDevice, cbData, lpvData); // original code

	if(cbData != 256)
		return temp;
	
	{  
		for (DWORD i = 0; i < 256; ++i)  
		{  
			if(((BYTE*)lpvData)[i]!=buffer[i])
				add_log("Key 0x%X %s", i, (((BYTE*)lpvData)[i]&0x80) ? "pressed" : "released");
		}  
	}

	memcpy(buffer, lpvData, cbData);
	return temp; 
}

I tried this code on another game using dinput8 and it works perfectly...

They are using GetDeviceData to handle the keyboard not GetDeviceState. I think the send skill is responsible for your glitch, maybe we have to find the raw call for it inside the SendSkill function ( i mean the actual skill function does more things than what we want it to do, we need to find the right raw call inside it ).

[AlainProvist]

Ok... Let's hook the GetDeviceData too ^^. About the glitch, yes. That's why I try to make the calls thread safe before trying any other raw game call. I traced the whole function above the one sending the skill in order to understand what drives the send.
I reached this part of the code :

/* if the jump occurs you skip the send of the skill
0088B10B  mov         edx,eax 
0088B10D  and         edx,7 
0088B110  mov         cl,dl 
0088B112  shr         bl,cl 
0088B114  test        bl,1 
0088B117  je          0088B1E7
*/

But I have no clue about what this test is really...








edit : Argh this stupid double post automerge again...


Failed to hook GetDeviceData()... Can't understand what happens here. Before I hook anything the normal call of GetDeviceData() is always performed with specific device through a specific callstack. But at the exact moment I hook the function, an unexpected call to my newly hooked function is performed through this crazy callstack with an unexpected unkown device and the game, (not my hooked function currently doing nothing else than recalling the original function), simply crash because it doesn't handle this case (unknown device return).

The unexpected callstack just right before calling GetDeviceData()

>	game.bin!005f32af() 	
 	[Les frames ci-dessous sont peut-être incorrects et/ou manquants, aucun symbole chargé pour game.bin]	
 	user32.dll!_UserCallWinProcCheckWow@32()  + 0x10e octets	
 	0018fc40()	
 	ntdll.dll!_KiUserCallbackDispatcher@12()  + 0x2e octets	
 	game.bin!0078da6c() 	
 	game.bin!005ef361() 	
 	game.bin!004ffab5() 	
 	game.bin!00502634() 	
 	game.bin!0065b5cc() 	
 	game.bin!0050539a() 	
 	ntdll.dll!_NtQueryInformationProcess@20()  + 0x12 octets	
 	ntdll.dll!_RtlEncodePointer@4()  + 0x17 octets	
 	game.bin!00550047()

And the code supposed to work...

// DInputHook.cpp*: définit le point d'entrée pour l'application console.
//

#define _CRT_SECURE_NO_WARNINGS 
#define DIRECTINPUT_VERSION 0x0800 
#include <Windows.h> 
#include <cstdio> 
#include <time.h> 
#include <dinput.h> 


DWORD WINAPI HookThread();
DWORD WINAPI UnhookThread();
void add_log(char* format, ...); 
void *SetDetour(BYTE *source, const BYTE *destination, unsigned int length);
void UnSetDetour(BYTE *source, const BYTE *destination, unsigned int length, BYTE *tunnel);
HRESULT __stdcall hkGetDeviceState(LPDIRECTINPUTDEVICE lpDevice, DWORD cbData, LPVOID lpvData); 
typedef HRESULT(__stdcall* GetDeviceState_t)(LPDIRECTINPUTDEVICE, DWORD, LPVOID); 
HRESULT hkGetDeviceData(LPDIRECTINPUTDEVICE lpDevice, DWORD cbObjectData, LPDIDEVICEOBJECTDATA rgdod, LPDWORD pdwInOut, DWORD dwFlags);
typedef HRESULT(__stdcall* GetDeviceData_t)(LPDIRECTINPUTDEVICE, DWORD, LPDIDEVICEOBJECTDATA, LPDWORD, DWORD); 

GetDeviceState_t pGetDeviceState; 
GetDeviceData_t pGetDeviceData; 

HMODULE hModDInput8 = NULL; 
FARPROC dwGetDeviceState = NULL; 
FARPROC dwGetDeviceData = NULL; 
FARPROC dwDirectInput8Create = NULL; 
HANDLE tmpHandle = NULL; 
bool Freeze = false; 
bool ShouldExitThread = false;

BOOL WINAPI DllMain(HINSTANCE hinstDll,DWORD Reason,LPVOID Reserved) 
{ 
	switch(Reason) 
	{ 
	case DLL_PROCESS_ATTACH: 
		add_log("==========LOG START=========="); 
		add_log("DLL Attached"); 
		add_log("Creating Thread..."); 
		tmpHandle = CreateThread(0, 0, (LPTHREAD_START_ROUTINE)&HookThread, 0, 0, 0); 
		if (!tmpHandle) 
		{ 
			add_log("ThreadCreation Failed!"); 
		} 
		break; 
	case DLL_PROCESS_DETACH:
		ShouldExitThread = true;
		Sleep(1000); 
		UnhookThread();
		add_log("DLL Detached"); 
		add_log("==========LOG END==========\n\n\n"); 
		break; 
	} 
	return 1; 
} 

DWORD WINAPI HookThread(void) 
{ 
	add_log("Thread Created"); 
	while (!hModDInput8) 
	{ 
		add_log("Searching dinput8.dll..."); 
		hModDInput8 = GetModuleHandle(L"dinput8.dll"); 
		Sleep(100); 
	} 
	add_log("Found dinput8.dll: %x !", hModDInput8); 
	while (!dwDirectInput8Create) 
	{
		add_log("Searching GetDeviceState..."); 
		dwDirectInput8Create = GetProcAddress(hModDInput8, "DirectInput8Create"); 
		Sleep(100); 
	} 
	add_log("Found DirectInput8Create: %x !", dwDirectInput8Create); 

	dwGetDeviceState = (FARPROC) ((DWORD)dwDirectInput8Create - 0x62B1);// C34CC8E - C3469DD
	add_log("GetDeviceState is here (DirectInput8Create - 0x62B1): %x", dwGetDeviceState); 
	add_log("Hooking GetDeviceState..."); 
	pGetDeviceState = (GetDeviceState_t) SetDetour((PBYTE) dwGetDeviceState, (PBYTE) hkGetDeviceState, 5); 
	add_log("Hooked GetDeviceState - Detour : %x - New: %x !", pGetDeviceState, hkGetDeviceState); 

	dwGetDeviceData = (FARPROC) ((DWORD)dwDirectInput8Create - 0x60E7);// C34CC8E - C346BA7
	add_log("GetDeviceData is here (DirectInput8Create - 0x60E7): %x", dwGetDeviceData); 
	add_log("Hooking GetDeviceData..."); 
	pGetDeviceData = (GetDeviceData_t) SetDetour((PBYTE) dwGetDeviceData, (PBYTE) hkGetDeviceData, 5); 
	add_log("Hooked GetDeviceData - Detour : %x - New: %x !", pGetDeviceData, hkGetDeviceData); 


	while (!ShouldExitThread) 
	{ 
		if( GetAsyncKeyState( VK_F12 ) &1 )
		{ 
			Freeze = !Freeze; 
			Sleep(500); 
		} 
		Sleep(10); 
	} 
	return 0; 
}

DWORD WINAPI UnhookThread(void) 
{
	UnSetDetour((BYTE *)dwGetDeviceState, (BYTE *)hkGetDeviceState, 5, (BYTE *)pGetDeviceState);
	add_log("Unhooked GetDeviceState - Detour : %x - New: %x !", hkGetDeviceState, pGetDeviceState); 
	pGetDeviceState = NULL;

	UnSetDetour((BYTE *)dwGetDeviceData, (BYTE *)hkGetDeviceData, 5, (BYTE *)pGetDeviceData);
	add_log("Unhooked GetDeviceData - Detour : %x - New: %x !", hkGetDeviceData, pGetDeviceData); 
	pGetDeviceData = NULL;

	return S_OK; // exit current thread
}

void add_log(char* format, ...) 
{ 
	HANDLE filehandle; 
	DWORD dwReadBytes; 
	char buffer[2048]; 
	char writebuffer[2048]; 
	va_list args; 
	va_start(args, format); 
	vsprintf (buffer, format, args); 
	filehandle = CreateFile(L"Log.txt", GENERIC_WRITE, 0, 0, OPEN_ALWAYS, 0, 0); 
	SetFilePointer(filehandle, 0, 0, FILE_END); 
	char date[18]; 
	_strdate(date); 
	date[8] = ' '; 
	_strtime(date+9); 
	sprintf_s(writebuffer, 2048, "Log Added (%s): %s\r\n", date, buffer); 
	WriteFile(filehandle, writebuffer, strlen(writebuffer), &dwReadBytes, 0); 
	CloseHandle(filehandle); 
} 

void *SetDetour(BYTE *source, const BYTE *destination, unsigned int length)
{
	unsigned int const jmpLength(5);
	unsigned int const nopOpcode(0x90);
	unsigned int const jmpOpcode(0xE9);

	if (length < jmpLength) 
		length = jmpLength; // Make sure the patch's length is long enough to hold a 32bit JMP.
	unsigned int tunnelLength = length + jmpLength;
	BYTE *tunnel  = new BYTE[tunnelLength]; // Create a body for the "tunnel" function.
	FillMemory(tunnel, tunnelLength, 0);
	DWORD oldProtection(NULL); // Old page protection.
	VirtualProtect(source, length, PAGE_EXECUTE_READWRITE, &oldProtection);
	memcpy(tunnel, source, length);
	FillMemory(source, length, nopOpcode);// erase source opcode
	source[0] = jmpOpcode;
	tunnel[length] = jmpOpcode;
	*(DWORD*)(source + 1) = (DWORD)(destination - source) - jmpLength; // JMP Offset 1
	*(DWORD*)(tunnel + 1 + length) = (DWORD)(source - tunnel) - jmpLength; // JMP Offset 2
	VirtualProtect(source, length, oldProtection, &oldProtection);
	return tunnel;
}

void UnSetDetour(BYTE *source, const BYTE *destination, unsigned int length, BYTE *tunnel)
{
	unsigned int const jmpLength(5);
	unsigned int const nopOpcode(0x90);
	unsigned int const jmpOpcode(0xE9);

	if (length < jmpLength) 
		length = jmpLength; // Make sure the patch's length is long enough to hold a 32bit JMP.
	unsigned int tunnelLength = length + jmpLength;
	DWORD oldProtection(NULL); // Old page protection.
	VirtualProtect(source, length, PAGE_EXECUTE_READWRITE, &oldProtection);
	memcpy(source, tunnel, length);// copy back the original opcode
	VirtualProtect(source, length, oldProtection, &oldProtection);
	delete[] tunnel;
}
	
HRESULT __stdcall hkGetDeviceState(LPDIRECTINPUTDEVICE lpDevice, DWORD cbData, LPVOID lpvData) 
{ 
	static BYTE buffer[256]; 
	HRESULT temp = DI_OK;

	temp = pGetDeviceState(lpDevice, cbData, lpvData); // original code

	if(cbData != 256)
		return temp;
	
	{  
		for (DWORD i = 0; i < 256; ++i)  
		{  
			if(((BYTE*)lpvData)[i]!=buffer[i])
				add_log("Key 0x%X %s", i, (((BYTE*)lpvData)[i]&0x80) ? "pressed" : "released");
		}  
	}

	memcpy(buffer, lpvData, cbData);
	return temp; 
}

HRESULT hkGetDeviceData(LPDIRECTINPUTDEVICE lpDevice, DWORD cbObjectData, LPDIDEVICEOBJECTDATA rgdod, LPDWORD pdwInOut, DWORD dwFlags)
{
	HRESULT temp = DI_OK;

	temp = pGetDeviceData(lpDevice, cbObjectData, rgdod, pdwInOut, dwFlags); // original code

// 	if (temp == DI_OK)
// 	{
// 		for(DWORD i = 0; i < *pdwInOut; ++i)
// 		{
// 			if (rgdod[i].dwData & 0x80) // only key-down events are reported
// 			{
// 				add_log("Key 0x%X %s", rgdod[i].dwOfs, (rgdod[i].dwData & 0x80) ? "pressed" : "released");
// 			}
// 		}
// 	}

	return temp; 
}

Honestly these hook failures start to make me really sick... I just simply don't understand wtf happens. I feel like loosing my few free time for... nothing exept headaches -_-.

[pureleech]

ntKid can u help me make it work to private server pleaese?

[ntKid]

Originally Posted by AlainProvist

HRESULT __stdcall hkGetDeviceState(LPDIRECTINPUTDEVICE lpDevice, DWORD cbData, LPVOID lpvData)
{
static BYTE buffer[256];
HRESULT temp = DI_OK;

temp = pGetDeviceState(lpDevice, cbData, lpvData); // original code

if(cbData != 256)
return temp;

{
for (DWORD i = 0; i < 256; ++i)
{
if(((BYTE*)lpvData)[i]!=buffer[i])
add_log("Key 0x%X %s", i, (((BYTE*)lpvData)[i]&0x80) ? "pressed" : "released");
}
}

memcpy(buffer, lpvData, cbData);
return temp;
}

HRESULT hkGetDeviceData(LPDIRECTINPUTDEVICE lpDevice, DWORD cbObjectData, LPDIDEVICEOBJECTDATA rgdod, LPDWORD pdwInOut, DWORD dwFlags)
{
HRESULT temp = DI_OK;

temp = pGetDeviceData(lpDevice, cbObjectData, rgdod, pdwInOut, dwFlags); // original code

// if (temp == DI_OK)
// {
// for(DWORD i = 0; i < *pdwInOut; ++i)
// {
// if (rgdod[i].dwData & 0x80) // only key-down events are reported
// {
// add_log("Key 0x%X %s", rgdod[i].dwOfs, (rgdod[i].dwData & 0x80) ? "pressed" : "released");
// }
// }
// }

return temp;
}
[/code]
Honestly these hook failures start to make me really sick... I just simply don't understand wtf happens. I feel like loosing my few free time for... nothing exept headaches -_-.

DInput8 module memory page is cloned at device spawn part of the code is executed on the clone image and other part of it is for memcmp( kind of a anti cheat check ).

I think you should focus your energy into fixing the SendSkill function because even if you make the DInput8 Hook work you wont be able to multiclient bot.

Originally Posted by pureleech

ntKid can u help me make it work to private server pleaese?

In theory CLua or the codes should work on the private server, since the client is the same.. You can try and ask Thr!ce to make the AFKLoader log into the private server instead of the official one.

Cheers.

[Omdi]

Does someone has the current address of the sendSkill function?
I would like to search for the internal 'sendPacket' function in Aura Kingdom

[ntKid]

Originally Posted by Omdihar

Does someone has the current address of the sendSkill function?
I would like to search for the internal 'sendPacket' function in Aura Kingdom

Should be this one, 0x006F1C60 ( matching the function on first post ).

Good luck, i really hope you pull that off.

[AlainProvist]

Actually I just got the render glitch with read only functions + the setNearestTarget call. So I assume that the setNearestTarget can also lead to crash exactly as the sendSkill does. I'll try to detour it and add critical section.

@Omdihar, I only have the french client ones, but you can easily find the offset by using the code search in CE and looking for this unique opcode :

push eax
push eax
mov eax, [ esi + 0x00000008 ]
shr eax, 0x0C
and eax, 0x0000FFFF
push eax
mov ecx, edi

edit : lol too late...



edit 2014/03/04 :

OK small update to say that I pushed myself very hard last night trying to approach the problem differently. Instead of trying to lock the functions supposed to be called in our thread to avoid memory collapsing, and thus risk to create deadlocks, I tried to inject somewhere in the main loop of the main thread a function of mine using a detour.

The idea is to make the main thread call this function driven by a static DWORD activating parts of the game's code and controled from our thread.

In pseudo code it can be sumed up by :

#define CMD_1 0x1 // for example SetNearestTarget
#define CMD_2 0x2 // for example SendSkill
#define CMD_3 0x4 // and so on...
DWORD commands = 0;
void myHook()
{
   if(commands&CMD_1)
      SetNearestTarget();
   if(commands&CMD_2)
      SendSkill();

   commands = 0;// treated for this frame
}

The tunnel is supposed to contain :

pusha
call myHook
popa
[instructions removed by the set of the detour]
ret/jmp origin// ret if the detour set a call or jmp origin if it is a jmp

I'm nearly done with this ; just a simple problem of address call after I changed all my jmp instructions to call ones because I was destroying the stack when jumping to a c declared function with a jump (yeah let's destroy the stack joyfully xD).
I'll finish this tonight when coming back home, and tell you if this worked (hope it will, cause I'm in a shortage of ideas after this one...)

[romromrom]

guys im noob in this. what shud i put in the macro.lua so that my bard will heal itself when it reach 50% hp.

[pandu12345]

Originally Posted by romromrom

guys im noob in this. what shud i put in the macro.lua so that my bard will heal itself when it reach 50% hp.

Hmm, you can try this:

macro ISaidIamAnOOb{
heal myBard
because ICantUseAutoPotion
}

Really works, btw OP, amazing work

[icestar]

Originally Posted by pandu12345

Hmm, you can try this:

macro ISaidIamAnOOb{
heal myBard
because ICantUseAutoPotion
}

Really works, btw OP, amazing work

You are evil...

[TheStupidDog]

Movement speed pointer :

"game.bin"+00B37994
      <Offsets>
       14
        C
       10
       340
       4E4

(above was copied from the XML file that CE generates.)

And some info on the float stored for some movement speeds (these will change slightly after reloading client so they're not 100% accurate) :

100%     =    8.599999428

105%     =    9.029999733

145%     =    12.46999931

150%     =    12.89999962

160%     =    13.75999928

165%     =    14.18999958

From a little testing it seems that you can set your speed to about 30-50% higher than what it should be with no major side effects.
This should be useful for getting to mobs very fast (minimizing time travelling between things) and also lets you get clear of red carpet faster meaning more time smacking bosses As with the previous pointer I posed (for the coord system) I've tried to refine the pointer to the best of my (bad) ability, several reboots and client starts etc. Once again I hope this is useful