PEEK&POKE

[faldo]

Ok... so now that new dll became much more interesting

...but unfortunatly, it won't seem to work... the A3 script won't write to the process at all. Seems to be that $DataSize that don't work.

If you can't get 8 byte writes dll to work, it would be cool if you could implement the SeDebugPrivilege API into the 4 byte write dll

Thanx for the great work once again =o)

Edited July 9, 2005 by faldo

[Encryption]

I haven't posted here in a while, but if it hasn't already been done, or if anyone's interested, I can' write a function for DLL Injection using the CreateRemoteThread and LoadLibrary Technique which is used for most mainstream game hacks. I did this with quite a few games and it works quite well. There is very little to no protection against it, and as of currently, there is only one main stream game with protection against it which is Guild Wars. Just give the go ahead and I will write it up write it up right quick and you can add it to the game.dll.

As for finding the memory addressed for programs, you use a debugger like OlyDbg or a decompiler like IDA...if this already hasn't been answered.

[buzz44]

Not sure if this is a stupid question but would AutoIt be at all possible to send/recieve packets from program/game?

I usually use WPE Alpha.

Edited July 20, 2005 by Burrup

[Encryption]

Not sure if this is a stupid question but would AutoIt be at all possible to send/recieve packets from program/game?

I usually use WPE Alpha.

<{POST_SNAPBACK}>

Not unless AutoIt can make DLL's.

[faldo]

I can' write a function for DLL Injection using the CreateRemoteThread and LoadLibrary Technique which is used for most  mainstream game hacks. I did this with quite a few games and it works quite well.  There is very little to no protection against it, and as of currently, there is only one main stream game with protection against it which is Guild Wars. Just give the go ahead and I will write it up write it up right quick and you can add it to the game.dll. 

That would be awsome mate... i know alot of us would be very greatfull =o)

[Encryption]

So, one of the developers can add this to the dll...

The only header files needed for the code is windows.h

THese are the global variables which you need greatly.

HINSTANCE   hInst;
char   szLibPath [_MAX_PATH];
HWND hWnd;
DWORD PID;
DWORD TID;
HMODULE hModule;
HANDLE hThread;
void* pLibRemote = 0;
DWORD hLibModule= 0;
HMODULE hKernel32 = ::GetModuleHandle("Kernel32");
HANDLE hProcess = OpenProcess(PROCESS_CREATE_THREAD | PROCESS_QUERY_INFORMATION | PROCESS_VM_OPERATION | PROCESS_VM_WRITE | PROCESS_VM_READ, FALSE, PID);

This is the DLLInjectionPrepare function which you need to call before you start injection.

//=====DLLInectionPrepare Function========
//==This function gets all the=============
//==information we need when the=========
//==dll injection begins.================
//==============================
BOOL StartInfo()
{
   if(!GetModuleFileName(hInst, szLibPath, _MAX_PATH))
      return 0;
   strcpy(strstr(szLibPath,".exe"), ".dll");
   return 1;
}
//===============================

This is the LoadDLL function. The only parameter needed is the Window you want to load the dll into.

//===============================
BOOL LoadDLL(HWND window)
{
   hWnd = ::FindWindow(NULL, window);
   TID = ::GetWindowThreadProcessId (hWnd, &PID);
   pLibRemote = ::VirtualAllocEx(hProcess, NULL, sizeof(szLibPath), MEM_COMMIT, PAGE_READWRITE);//Allocate Memory in the Remote Process
   if(pLibRemote == NULL)//Check if it worked
      return 0;
   ::WriteProcessMemory(hProcess, pLibRemote, (void*)szLibPath,sizeof(szLibPath),NULL);//Write the path to the alloted memory
   hThread = ::CreateRemoteThread(hProcess, NULL, 0, (LPTHREAD_START_ROUTINE) ::GetProcAddress(hKernel32,"LoadLibraryA"), pLibRemote, 0, NULL);//Load the dll into the remote process
   if(hThread == NULL)
   {
      ::VirtualFreeEx(hProcess, pLibRemote, sizeof(szLibPath), MEM_RELEASE);//Free the memory we allocated earlier
      if(hLibModule == NULL)
         return 0;
      UnloadDLL();
      return 0;
   }

   ::WaitForSingleObject(hThread, INFINITE);
   ::GetExitCodeThread(hThread, &hLibModule);   // Get handle of loaded module
   ::CloseHandle(hThread);
   ::VirtualFreeEx( hProcess, pLibRemote, sizeof(szLibPath), MEM_RELEASE );//Free the memory we allocated earlier
   return 1;
}

This is the unload dll function and the only parameter is the window name you want to unload the dll from.

//=====UnloadDLL Function========
//==This function unloads the====
//==the DLL from the remote =====
//==========process.=============
//===============================
BOOL UnloadDLL(HWND window)
{
   hWnd = ::FindWindow(NULL, window);
   TID = ::GetWindowThreadProcessId (hWnd, &PID);
   hThread = ::CreateRemoteThread(hProcess, NULL, 0, (LPTHREAD_START_ROUTINE) ::GetProcAddress(hKernel32,"FreeLibrary"), (void*)hLibModule, 0, NULL );
   if(hThread == NULL)   // failed to unload
      return 0;
   ::WaitForSingleObject(hThread, INFINITE);
   ::GetExitCodeThread(hThread, &hLibModule);
   ::CloseHandle(hThread);
   return 1;
}
//===============================

To use you would first call the StartInfo function, then the unload dll function just to be safe...then the load dll function...then the unload function when you are all finished. If there are any errors let me know, but there definately should not be.

One last thing, in order for the dll to load properly, it must be in the same folder as the executable, and also the same name, so if you had an exe file name "hack.exe" then the dll would have to be in the same folder and named "hack.dll". I might word around this later, but as of now its not needed since you plan to use it for autoit game hacking.

Edited July 20, 2005 by Encryption

[buzz44]

You can code these in AutoIt fairly easily.

[Encryption]

You can code these in AutoIt fairly easily.

<{POST_SNAPBACK}>

Heh? You can code the dll injection in autoit? Since when can you allocate memory in another process? Did I miss a big update over the time I was gone?

[buzz44]

Check this thread to get started.

http://www.autoitscript.com/forum/index.php?showtopic=13256

[Encryption]

Well if it can be done, more power to AutoIt.

[layer]

It can be done... I think. w0uter made some fancy UDF's that require the latest BETA. Check out his signiture.

BTW,

Haven't seen you in a while Encryption!!

[w0uter]

i suppose it can be done.

but didnt larry had problems using VirtualAllocEx ?

[JSThePatriot]

Just because something can be done in AutoIt doesnt mean that would be the best way to do it, now if it was just as fast as writing it in C++ then sure use AutoIt, but I would bet C++ will inevitably be faster, and you will want some speed.

JS

[w0uter]

C++ will always be better as autoit. d'oh. but an external dll is so ugly.

[JSThePatriot]

C++ will always be better as autoit. d'oh. but an external dll is so ugly.

<{POST_SNAPBACK}>

Most definitely will it always be better. I wasnt implying otherwise, but I also like to support AutoIt so long as it is practical . Everything you can do in AutoIt can definitely be done 'better' in C++, but the thing is the time spent learning vs outputting code. AutoIt is here for a reason

JS

[petrojelly]

Ok i just tested the 8byte dll i posted before, and it doesnt work.

It's beyond my knowledge how to use a 8byte (QUAD sized) variable. So here is the 4 byte version of the dll, with debug privilege included.

Func MemWrite($ProcessName, $Address, $DataToWrite, $DataSize) ;$DataSize is 1 to 4

Local $PID, $Result

$PID = ProcessExists($ProcessName)

$Result = DllCall("Mem.dll", "long", "WriteMemLoc", "long", $PID, "long", $Address, "long", $DataToWrite, "long", $DataSize)

Return $Result[0]

EndFunc

Func MemRead($ProcessName, $Address, $BytesToRead) ;$BytesToRead is 1 to 4

Local $PID, $Result

$PID = ProcessExists($ProcessName)

$Result = DllCall("mem.dll", "long", "ReadMemLoc", "long", $PID, "long", $Address, "long", $BytesToRead)

Return $Result[0]

EndFunc

Ok... so now that new dll became much more interesting

...but unfortunatly, it won't seem to work... the A3 script won't write to the process at all. Seems to be that $DataSize that don't work.

If you can't get 8 byte writes dll to work, it would be cool if you could implement the SeDebugPrivilege API into the 4 byte write dll

Thanx for the great work once again =o)

<{POST_SNAPBACK}>

Mem.dll

Edited July 23, 2005 by petrojelly

[faldo]

Thanx petrojelly, since you didn't reply at the time, i acctually went ahead and solved the problem myself.

Ok, for the newcomers to this thread, the problem was that with a 4 byte poke (write) to the memory, the process might crash since it reads the memorys ASM operations, and they can be anything from 1 to 8 bytes.

Now, if an ASM operation was longer than 4 bytes, you'd have to pray to god your A3 script wrote the pokes fast enough so that it wouldn't disrupt the memory cycles, leaving half a ASM operation while the process ran it... Well, sometimes it worked, sometimes it didn't. That's why i wanted the 8 byte version, since there arn't any ASM operations longer than 8 bytes =o)

Since the 8 byte version of this exelent dll didn't work. I solved the problem by making a simple loop, or a jump right before the ASM operation(s) i wanted to alter, depending on how the code looks like.

In most cases jumping (JMP) over the function in the process, while editing the ASm inside it and then restoring the JMP to the original values, works fine. This won't disrupt the data flow nor crash the process.

However in some cases, the process NEEDS that particular function all the time in order to stay alive. So i solved that by looping the code right before the ASM you need to edit. This method will pause the process for some millisecond, but i havn't seen any process crash when i resumed it. The loop is also done with a JMP, looping the previous function in the process (since it's read chronologicly).

Well, i'm sure all of this don't make sence at all, if it don't, i'm willing to clarify it on request. Hopefully, it might help some other fellow geeks out there

For anyone who's interested, i released a new version of my "Syndrome" hack for World of Warcraft entirely done with A3.

http://www.mpcforum.com/showthread.php?t=99798

[faldo]

I've thought of a new function that will help game training alot... This might be done in A3 or you might need a DLL to achieve it, that's why i'm asking the pros.

Since games often get patched, one has to update the trainer aswell. Well, i know this can be solved, i even know in theory how it can be done.

If you scan the .text part (static code) of a process which is a few thousand addresses, one can map the area you need to use/change, identify the op-codes and compare them to a previous version of the game. Then make the script update itself to the new version.

Ok, if all that didn't make any sence, in brief, what would be great it a bytescanner.

A DLL or a script that could identify a byte or set of bytes that you specify.

I believe this could be done with the current mem.dll but may use too much CPU since you'd have to minimize every search to 4 bytes at a time.

Greatfull for feedback/thoughts.

Edited August 7, 2005 by faldo