Afro

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

Здесь можешь найти много инфы 

Пример использования функции SetThreadContext(Windows.h) для закрытия процесса.

Программа завершает процесс путём замены адреса в регистре EIP, адресом "ExitProcess" из библиотеки kernel32.dll 

#include <iostream>

#include <Windows.h>

#include <tlhelp32.h>

using namespace std;
int main() {
  DWORD PID = NULL;
  HANDLE hPESnap;
  HANDLE hTHSnap;
  THREADENTRY32 te32;
  PROCESSENTRY32 pe32;
  CONTEXT ctx;
  ctx.ContextFlags = CONTEXT_CONTROL;
  HMODULE kernel = GetModuleHandle("kernel32");
  te32.dwSize = sizeof(THREADENTRY32);
  pe32.dwSize = sizeof(PROCESSENTRY32);
  hPESnap = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
  if (!Process32First(hPESnap, & pe32)) return 2;
  do {
    if (stricmp(pe32.szExeFile, "uTorrent.exe") == 0) {
      PID = pe32.th32ProcessID;
      break;
    }
  } while (Process32Next(hPESnap, & pe32));
  hTHSnap = CreateToolhelp32Snapshot(TH32CS_SNAPTHREAD, 0);
  while (Thread32Next(hTHSnap, & te32)) {
    if (PID == te32.th32OwnerProcessID) {
      cout << "Opening thread handle Thread ID:" << te32.th32ThreadID;
      HANDLE hThread = OpenThread(THREAD_ALL_ACCESS, false, te32.th32ThreadID);
      cout << "Setting thread context\n\n";
      SuspendThread(hThread);
      GetThreadContext(hThread, & ctx);
      ctx.Eip = (DWORD) GetProcAddress(kernel, "ExitProcess");
      SetThreadContext(hThread, & ctx);
      ResumeThread(hThread);
      CloseHandle(hThread);
    }
  }
  CloseHandle(hTHSnap);
  CloseHandle(hPESnap);
  return 0;
}

Как я понимаю: в OptinalHeader задаются выравнивания секций относительно файла(fileAligment) и относительно секции(sectionAligment). То есть секции располагаются в адресах кратных этим выравниваниям.

На деле же получается вот что:

Сначала думал что размер всех секций одинаков, тот который указывается в выравниваниях, теперь понял, что это бред и что могут быть разными.
Я правильно понимаю, если секция заканчивается в адресе не кратном выравниванию, то память выделяется до тех пор пока не дойдёт до нужного адреса?
Если да, то зачем такие замуты, почему бы не начать секцию сразу за предыдущей?
И зачем нужно смещение относительно файла, разве не достаточно только от секции?

Сможешь обработать и сюда скинуть?

Делать мне нечего, могу помочь если возникнут вопросы по конкретным вещам.

Вот кстати урок от кодера про сканеры сигнатур (на плюсах)

P.S. всё уже давно сделано за тебя, знай себе копипасти

си шарп. Как перенести это на с++ ?

Так он там ничего сверхъествественного не использует, перенести в два счёта можно.

Разве что типы поменять и в цикле пробел поставить 

Ах вот ты про что.

А чем тебе не нравятся уроки кенга? 

Что значит внешний?

Если постоянно пишешь видео, то можно и на Action раскошелиться. В конце концов, 1500 - небольшие деньги за ее функционал.

Это для студента то небольшие? Ну ты загнул

Привет, форум!
Решил записать пару видео на днях и не знаю чем. До этого никогда подобными вопросами не задавался, поэтому решил спросить у вас. Чем вы записываете видео уроки?

В интернете много вариантов, интересно конкретно ваши предпочтения

На wasm.ru можешь почитать про формат PE файлов.

 

Basically manual mapping mirrors the functionality of LoadLibraryA in that it prepares a dll so that it can be successfully loaded into the process and have the right relative offsets etc, thus eliminating the need to call LoadLibraryA which is VERY easy for the remote process to hook and detect seeing as it's called within the remote process.

Я не силён в английском. Как я понял, этот мэппинг заменяет loadlibrarya и нужен из-за того, что второй легко определяется (чем-то).

Coder, можешь кинуть ссылку где можно почитать суть этого метода, если он имеет схожий функционал со стандартным loadlibrarya, то в чем его "фишка"?

Ну и на васме я что-то не смог соориентироваться

UPD. Всё нашёл. Если можешь от себя что-то добавить - буду рад)

TS, есть ли какая-нибудь годная русскоязычная инфа по этому мануал мапингу?
Дюже хочется поднабраться.

Я немного не понял твоего вопроса.

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

Тогда зачем писать трейнеры, которые по куче раз меняют значение в адресе с патронами и т.д., если можно просто найти адрес инструкции и изменить её всего один раз, мне кажется это проще, хотя наверное не со всеми играми.

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

90h это код инструкции nop

Во второй тоже самое, видимо для какой-то ещё ситуации с патронами. Я тоже всегда думал, что статический указатель всегда должен быть, да это и по логике ясно, но там такая куча смещений, что мама не горюй.

Наверное плохо искал.

Кстати я так и не вкурил чем же отличается

db 90 90

от

nop
nop

Значит так, речь идёт о battlefield 2.

Попытался найти статичный адрес патронов, не вышло, не знаю почему, но всё время после кучи оффсетов выходил на адрес без указателей.

После часа припадков злости что с этой игрой не так (а скорее с моей головой), решил глянуть как оно реализовано в интернете.

Нашёл таблицу, ну думаю, сейчас увижу всё, прозрею сразу, но ни тут то было, в таблице скрипт вот такого содержания:

"BF2.exe"+19E736:
db 90 90
"BF2.exe"1B9466:
db 90 90

И тут я немного выпал в осадок, ведь как я понял тут просто занопили инструкцию оригинальную по двум адресам, кстати оригинальная инструкция:

sub [eax],edx

Так вот вопрос, неужели возможно такое, что в игре нету статичного адреса с патронами (всмысле указателя), и получается бывает так, что у ф-ции статичный адрес? И как определить статичный он или нет? Или он всегда статичный?

И ещё один : чем отличается

db 90 90

от простого

nop
nop

?

Оу, похоже я с названием лажанул, исправте кто может

DllMain должна вернуть значение 1.

Если возвращается значение 0, то dll выгружается из программы.

И ты смотришь MFC, а не голый C++/

Да, разобрался, спасибо

Проблема в том, что не получается открыть поток в dll, приложение крашится.

Изначально все скатал под чистУю у кодера (в уроке):

#include <Windows.h>

DWORD WINAPI Thread();

bool APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved){
if (ul_reason_for_call == DLL_PROCESS_ATTACH){
  CreateThread(NULL, NULL, Thread, NULL, NULL, NULL);
}
}
DWORD WINAPI Thread(){
//Do something
return S_OK;
}

Потом полез в инет и нашёл фразу "За исключением периода инициализации", то есть как я понял в самом DllMain нельзя задерживаться и поток надо создавать отдельно поэтому написал вот так:

#include <Windows.h>
DWORD WINAPI Thread();
void CreateThrd(){
CreateThread(NULL, NULL, (LPTHREAD_START_ROUTINE)Thread, NULL, NULL, NULL);
return;
}

bool APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved){
if (ul_reason_for_call == DLL_PROCESS_ATTACH){
  CreateThrd();
}
}
DWORD WINAPI Thread(){
for (;;Sleep(1000)){
  MessageBox(NULL, "Msg from thread", MB_OK, NULL);
}
return S_OK;
}

Но и это тоже к сожалению не проканало, кстати меседжбокс не вылез.

Где то ещё было про какие-то обозначения или метки выхода из потока, но это я не вкурил.

Кто знает в чем трабла?

UPD. Странно, но проблема решилась куда более простым путём: тупо забыл указать возвращаемое значение в ф-ции DllMain.

Но теперь интересует обратный вопрос, почему когда на мсдне пишут что создавать потоки нельзя, тут такой беспредел творится? (MSDN)

Копия того, что я видел на C#.

P.S. я думал что он хочет сам свой парсер написать.

Именно так, свой)

хм, видно я ошибся.

На сишарпе - да, даже есть пример хороший, но я хочу на плюсах.

Но не приложу ума как

Всё это конечно просто замечательно, но хотелось бы кого-то примерчика, как я понял существует куча библиотек облегчающих эту задачу, но т.к. я ещё мягко говоря нубец, для меня сложно выбрать какую-то и написать

можно пример, пусть даже не для предложенного примера, а полегче, чтобы понять логику выполнения?

Доброго времени суток.

Имеется файл следующего содержания:

<clientzones>
<subzones>
  <subzone>
   <name>STR_AbProD2_SZ_B</name>
   <priority>16</priority>
   <string>STR_AbProD2_SZ_B</string>
   <breath_area>FALSE</breath_area>
   <power_area>FALSE</power_area>
   <ui_map>main</ui_map>
   <fatigue_korea>FALSE</fatigue_korea>
   <points_info>
	<type>polygon</type>
	<points>
	 <npc_info>
	  <movetype>false</movetype>
	  <nameid>798356</nameid>
	  <pos>
	  <x>417.244720</x>
	  <y>357.266296</y>
	  <z>231.750000</z>
	  </pos>
	 </npc_info>
	 <npc_info>
	  <movetype>false</movetype>
	  <nameid>798356</nameid>
	  <pos>
	  <x> 377.244720</x>
	  <y> 312.016296</y>
	  <z>221.000000</z>
	  </pos>
	 </npc_info>	  
	</points>
	<bottom>0.100000</bottom>
	<top>500.100000</top>
   </points_info>
  </subzone>
</subzones>
</clientzones>

Нужно из этого файла вытащить id, x/y/z координаты и записать следующим образом в новый файл

<spawns>
<spawn map="NEW-IDABPROD3" npcid="798356" pool="2" interval="105">
	<object x="417.244720" y="357.266296" z="231.750000" h="0" />
	<object x="377.244720" y="312.016296" z="221.000000" h="0" />
   </spawn>
</spawns>

*параметр pool - количество координат, а h, interval и map - статичны

Не откажусь от примера кода или ссылок на литературу, в которой можно про это почитать

P.S. твой метод нещадно грузит ЦП.

Поэтому более лояльно по отношению к ЦП будет - внедрение инъекции кода.

Спасибо за совет, но внедрять инъекцию кода я ещё не научился.

Не откажусь от ссылки где можно про это почитать или посмотреть)

А зачем закрывать хэндл?

И если их по отдельности делать, то это не будет долше или более ресурсоёмким?

#include <windows.h>
HWND hWnd = NULL;
HANDLE process = NULL;										 
DWORD pid = 0;
const float patchH(100.0), patchA(20.0);
float Health, Ammo;
int main()
{
hWnd =  FindWindow(NULL, "Crimsonland");
GetWindowThreadProcessId(hWnd,&pid);

while(hWnd)
{		  
	  if (process == NULL && pid != 0)
    {
	 process = OpenProcess(PROCESS_ALL_ACCESS, false, pid);
    }
	  ReadProcessMemory(process, (LPVOID)(0x0048E5C4), &Health, 4, NULL);
	  ReadProcessMemory(process, (LPVOID)(0x0048E860), &Ammo, 4, NULL);
	  if (Health<patchH)
    {
	 WriteProcessMemory(process, (LPVOID)(0x0048E5C4), &patchH, 4, NULL);
    }
	  if (Ammo<patchA)
    {
	 WriteProcessMemory(process, (LPVOID)(0x0048E860), &patchA, 4, NULL);
    }

  Sleep(50);
}
CloseHandle(process);
return 0;
}

Вот, постарался учесть все замечания

#include <windows.h>
HWND hWnd = NULL; // заголовок окна нужного процесса
HANDLE process = NULL;										
DWORD pid = 0;   // номер процесса в списке
const float patchH(100.0), patchA(20.0);
float Health, Ammo;
int main()   // создаём точку входа в процесс трейнера
{
while(1)
{
  hWnd =  FindWindow(NULL, "Crimsonland");
  GetWindowThreadProcessId(hWnd,&pid);
  if(hWnd){
	  if (process == NULL && pid != 0)
	  {
			   process = OpenProcess(PROCESS_ALL_ACCESS, false, pid);
	  }
	  ReadProcessMemory(process, (LPVOID)(0x0048E5C4), &Health, 4, NULL);
	  ReadProcessMemory(process, (LPVOID)(0x0048E860), &Ammo, 4, NULL);
	  if (Health<patchH || Ammo<patchA)
	  WriteProcessMemory(process, (LPVOID)(0x0048E5C4), &patchH, 4, NULL);
	  WriteProcessMemory(process, (LPVOID)(0x0048E860), &patchA, 4, NULL);

	 }
  Sleep(200);
}

}

Ого, спасибо за советы)

Не работало из за последнего пункта, значение float точкой, а искал int

Про сиаут - не обращай внимания, это я для теста сделал, какое значение возвращает, с брейкпоинтами не очень ещё дружу.