>>450739

> Разве для вызова функции в памяти клиента достаточно записать только функцию, а параметры можно свои

В память нужно записать все, что требуется для работы функции. Давай разберем:
Стартовая функция потока (ThreadProc), которая у тебя RightClickF принимает один параметр, она использует конвенцию __stdcall, поэтому параметры (параметр) передаются через стек в обратном порядке:
(где-то внутри CreateRemoteThread):
push lpParameter // Заталкивает в стек параметр, который ты передал в CreateRemoteThread, т.е., твой DWORD.
call ThreadProc // Вызывает функцию, адрес которой ты передал как THREAD_START_ROUTINE, т.е., RightClickF.
В результате параметр DWORD guid в RightClickF читается из стека и становится равным тому, что ты передал в CreateRemoteThread. Он - просто число и никак не зависит от других данных в вызывающем и вызываемом процессах.

Но если рассмотреть другой пример, если бы у тебя была не RightClickF(DWORD guid), а, например, AnotherThreadFunc(const char message):
const char message = "hello";
CreateRemoteThread(... (LPTHREAD_START_ROUTINE) AnotherThreadFunc, (LPVOID) message, ...);
После вызова CreateRemoteThread все так же сделает:
...
push lpParameter // Заталкивает в стек параметр, т.е., адрес message.
call ThreadProc
После выполнения этого кода AnotherThreadFunc получает управление, в ее параметр message попадает адрес, который ты передал, но адрес-то этот в вызывающем процессе, а не в клиенте. В результате, при попытке использования параметра в лучшем случае прочитается мусор, а в худшем по этому адресу не окажется ничего, и клиент вывалится. Поэтому чтобы передать указатель, ты выделяешь память на стороне клиента, копируешь туда данные и передаешь указатель уже на эти данные.

Третий пример. Тебе нужно передать два параметра, но ты не можешь - у ThreadProc может быть только один параметр, и CreateRemoteThread принимает только один параметр. Поэтому ты подготавливаешь параметры (выделяешь память на стороне клиента для указателей, если нужно, и т.д.) и пихаешь полученные параметры в массив, который тоже копируешь на сторону клиента. И вот адрес этого массива ты передаешь в CreateRemoteThread. Твоя ThreadProc получит управление, ее первым и единственным параметром будет твой массив.

>>450740

> как записать эти параметры

hProcThread = CreateRemoteThread(hProcess, NULL, NULL, (LPTHREAD_START_ROUTINE)ta, guid, NULL, NULL); если guid не указатель, он один, и он не занимает больше 4 байт (в DWORD как раз 4).

Почитай что-нибудь по конвенциям вызова уже, гораздо понятней все станет.

> я не хочу использовать фасткалл

Ты не хочешь использовать указатель на функцию. А fastcall - всего лишь конвенция вызова (способ передачи параметров в функцию).

И вообще, нахуй так мучаться, погугли "инжект длл", реализуй в длл весь чит, потом научишься еще длл скрывать из списка модулей, и будет заебись.

Алсо, почему падает вызываемая функция - отдельный вопрос. Вангую, там класс, и в ecx не guid должен попадать. Но проверить не могу, в вов не играю.

>>450755
Hу вот смотри, что мы можем увидеть из скриншота кроме блядского AT&T синтаксиса.
1) (0x00711141) В edi записыается то, что ты передал первым параметром функции (ecx).
2) (0x00711143) По адресу edi+0x1a0 что-то читается.
3) Из этого заключаем, что первый параметр нихуя не DWORD, нихуя не guid, и вообще, учитывая, что он передается через ecx, это не __fastcall, а __thiscall, т.е., стандартный способ вызовов методов объекта, когда указатель на объект (this) кладется в ecx, а параметры в стек.
4) (0x00711149, 0x0071114b, 0x0071114e) Оказывается, из переданного в функцию объекта прочитался указатель на какой-то другой объект, у этого объекта мы вызываем какой-то виртуальный метод. Собственно, в этом месте все и падает, потому что передал ты нихуя не объект, и у него нихуя нет указателя на другой объект по смещению 0x1a0.
5) К ESP (указателю стека) функция не обращается (только корректирует стек после чего-то похожего на printf), а retn в конце не чистит стек, что позволяет заключить, что функция наша без аргументов.

Итого: по 0x00711141 лежит невиртуальный метод объекта (видимо, класса Player), который не принимает аргументов (кроме this). Где ты там guid нашел, я не знаю.

> как писать длл библиотеки

Так же как и обычные программы. Это уж точно проще, чем пистаь читы. В любом случае, google gcc make dll или google how to make dll with qt.

> о том, что параметр - гуид я узнал в одном треде

Это в принципе может быть объект класса GUID, хотя вряд ли.

> фасткалл - вызывает функцию по адресу

> но сама функция же нахоидтся в нашем процессе, вероятно ее тоже придется записать в процесс игры

Да, просто копируешь RightClickF в процесс игры, как и раньше и вызываешь. Поменяй только fastcall на, как мы выяснили, thiscall.

>>450769
Через eax, edx, esi, edi, ebx обычно ничего не передается, эти регистры используются для хранения промежуточных значений. esp/ebp - указатель стека и указатель на кадр стека, что это и зачем - гугли про стек, даже в wikibooks все разжевано,

> реестр

> путает регистр и реестр

> пишет чит

> Если я инъекутирую в вов асм функцию, которая забивает регистр так как мне надо

Если ты найдешь, по какому адресу (нихуя не фиксированному скорее всего) хранится адрес объекта player, положишь его в ecx и вызовешь 0x00711140, все будет ок.