Наставьте на путь истинный

BritishColonist · 02.04.2012, 21:24

dwa83, я запиливаю продажу пакетами примерно так (из DLL) :

Код:

void Packet(DWORD length, char* packet) // отправка пакета
{
	DWORD PacketFunc = 0x6737B0;
	BYTE* Packet = new BYTE [length];
	memcpy(Packet,packet,length);
	__asm	{
		mov ecx, dword ptr [BA]
		mov ecx, dword ptr [ecx+0x20]
		push length
		push Packet
		call PacketFunc
	}
	delete [] Packet;
}

Этот код использую для продажи всех миражей из инвентаря:

Код:

char PacketSell[30] = "\x25\x00\x02\x00\x00\x00\x10\x00\x00\x00\x01\x00\x00\x00\x34\x47\x00\x00\x11\x00\x00\x00\xD0\x07\x00\x00";
for(SlotId=0; SlotId<SlotCount-1; SlotId++)	{
	ItemStart = *(DWORD*)(InventoryStart+SlotId*4);
	if(ItemStart)	{ // указатель не равен NULL - предмет есть в ячейке
		if (*(DWORD*)(ItemStart+0x08) == 18228)	{ // ид совпал с нужным
			PacketSell[18] = SlotId; // 18-й байт пакета - номер ячейки, из которой хотим продавать
			memcpy((void*)(PacketSell+22),(void*)(ItemStart+0x10),4); // 4 байта, начиная с 22-го, содержат количество предметов, которые хотим продать
			Packet(26,PacketSell); // отсылаем пакет
		}
	}
}

А этот код загружает структуру игрока и некоторые нужные оффсеты:

Код:

void CHostPlayer::LoadStruct()
{
	while (!*(BYTE*)OnlineFlag)	{
		Sleep(100);
	}

	__asm	{
		mov eax, dword ptr [BA]
		mov eax, dword ptr [eax+0x1C]
		mov eax, dword ptr [eax+0x34]
		mov PlayerStruct, eax
		mov eax, dword ptr [eax+0xCAC]
		mov ecx, dword ptr [eax+0x10]
		mov SlotCount, ecx
		mov eax, dword ptr [eax+0x0C]
		mov InventoryStart, eax
	}
}

Вас скорее заинтересуют не конкретные ID предметов, а их типы (например, если предмет - ДК, его можно продавать). Смещений и самих типов я не знаю, но они должны быть где-то тут есть в соседних темах.

dwa83 · 02.04.2012, 21:50

Спасибо, попробую пакетами. Надо бы разобраться, судя по всему пакетами сейчас больше функций делают.

Добавлено через 2 часа 16 минут
Что-то я делаю не так, не могу понять что. Я функцию посылки пакета инжектом загоняю в клиент, Как параметр передаю указатель на структуру пакета, которая включает длину и сами байты:

Код:

struct PACKET
{
  int len;
  BYTE Bytes[30];
};

Функция посылки пакета, которая инжектится в процесс такая:

Код:

// îòïðàâêà ïàêåòà
void __stdcall SendPacket_THREAD(PACKET* pack)
{

	DWORD Function = F_SEND_PACKET;
        DWORD len = pack->len;
	BYTE Packet[30];
	for (int i=0; i<pack->len; i++)
        Packet[i]=pack->Bytes[i];


	__asm
        {
          mov ecx, dword ptr [BA]
          mov ecx, dword ptr [ecx+0x20]
          push len
          push DWORD(Packet)
          call Function
	}

}

Далее функция которая инжектит её выглядит так:

Код:

void INJECTOR::Sell(BYTE nomcell, DWORD kol)
{
  PACKET pack;
  char PacketSell[30] = "\x25\x00\x02\x00\x00\x00\x10\x00\x00\x00\x01\x00\x00\x00\x34\x47\x00\x00\x11\x00\x00\x00\xD0\x07\x00\x00";
  memcpy(pack.Bytes,&PacketSell,30);
  pack.Bytes[18] = nomcell; // 18-é áàéò ïàêåòà - íîìåð ÿ÷åéêè, èç êîòîðîé õîòèì ïðîäàâàòü
  memcpy(pack.Bytes+22,&kol,4); // 4 áàéòà, íà÷èíàÿ ñ 22-ãî, ñîäåðæàò êîëè÷åñòâî ïðåäìåòîâ, êîòîðûå õîòèì ïðîäàòü

  pack.len=26;

  InjectAndExecute(&SendPacket_THREAD, &pack);
}

Сначала процесс подвисал из за того что в функции посылки пакета(которая инжектится в адресное пространство клиента) я пытался создать динамический массив как в примере. Поменял на статический. Компилятор стал ругаться на то что я в ASM коде пытаюсь поместить PUSH Packet. В обычных условиях Имя массива без скобок является указателем на первый элемент массива(т.е. указателем на массив). Но компилятор не хочет почемуто иметь в этом месте указатель типа BYTE*.
Я написал так: push DWORD(Packet). Тоесть мы взяли указатель на BYTE(по сути число, представляющее адрес) и сказали компилятору, что это DWORD число. Компилятор скушал выражение, но при посылке пакета ничего не происходит вообще. Где я напортачил?

Добавлено через 18 часов 36 минут
Всё, разобрался) Утро вечера мудренее, как говорится) Сделал так:

Код:

// îòïðàâêà ïàêåòà
void __stdcall SendPacket_THREAD(PACKET* pack)
{

	DWORD Function = F_SEND_PACKET;
        DWORD len = pack->len;
	BYTE Packet[30];
	for (int i=0; i<pack->len; i++)
        Packet[i]=pack->Bytes[i];
        BYTE* Pointer=Packet;

	__asm
        {
          mov ecx, dword ptr [BA]
          mov ecx, dword ptr [ecx+0x20]
          push len
          push Pointer
          call Function
	}

}

Добавлено через 19 часов 7 минут
BritishColonist, Пакет продажи, мне кажется, не правильный или уже изменён.
Пробовал пакеты медитации и атаки петом, работают.

Код:

void INJECTOR::Meditation()
{
  PACKET pack;
  pack.len=2;
  char Packet[2] = "\x2E\x00";
  memcpy(pack.Bytes,Packet,pack.len);
  InjectAndExecute(&SendPacket_THREAD, &pack);
}

void INJECTOR::PetAttack(DWORD wid)
{
  PACKET pack;
  pack.len=11;
  char Packet[30] = "\x67\x00\x00\x00\x00\x80\x01\x00\x00\x00\x00";
  memcpy(pack.Bytes,Packet,pack.len);
  memcpy(pack.Bytes+2,&wid,4); // 4 áàéòà, íà÷èíàÿ ñ 2 - WID ìîíñòðà
  InjectAndExecute(&SendPacket_THREAD, &pack);
}

а вот пакет продажи ни в какую не хочет. Пробовал с открытым диалогом у нпс и с открытым окном покупки/ремонта. Может ещё надо WID или ИД NPSа указывать в пакете?

Извиняюсь за невнимательность, в пакет же ещё ID предмета нужно записать, а там уже записан ID перьев феникса)

Добавлено через 22 часа 38 минут
Ура, первый самостоятельно написаный бот уже готов, пока я это пишу - фармит, тестируется)

Надо сказать большое спасибо форумчанам за полезные темы, так как научить человека, который не имеет никакого понятия о ботостроение, делать ботов - это прям достижение и гордость

Тем более за такой срок (Не знаю для кого как, а для меня полторы недельки - это быстро

).

Спасибо этим людям(могу только + рядом с аватаркой тыкнуть):

BritishColonist За отличный гайд Внедрение и модификация кода
И вообще отдельное спасибо за наставления и обьяснения по вопросам.
Dinmaite За темы Код для инжекта в память
Поиск базового адреса
Поиск инжектов

sumikot Очень полезная ТЕМА с оффсетами, страничка практически не закрывалась у меня)

N00bSa1b0t За прогу PW PacketListener

Вроде никого не забыл) Щас буду доробатывать бота до ума)

dwa83 · 05.04.2012, 23:33

Охх, всё, голова уже дымит. Может кто подскажет почему происходят периодические подвисания клиента? Происходит это так: сначала клиент перестаёт отвечать на инжекты, но все данные успешно считываются. Затем, даже если бот уже выключен, клиент реагирует на внутриигровое управление, но спустя время перестаёт отвечать(стандартное виндовое сообщение) либо светофором наградит. Замечено, что происходит это в циклах примерно таких:

Код:

void PROCESS::HillPet(float prc)
{
  while ((petHPproc(0)<prc)&&(myHP()!=0))  // допустим пет номер 0
  {
    msg="Хилю пета";
    if (skillCoolDown(11)==0)  //проверка в откате ли скилл
    proc.Skill(skillID(11)); // Инжектится юзанье скилла) 
    Application->ProcessMessages();  // даём приложению обработать события если хилл затянется
  }
}

У кого-нибудь были такие проблемы?

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

а теперь ещё и люди-невидимки появились

Добавлено через 6 часов 49 минут
BritishColonist, Вы помоему единственный в этой теме отвечаете. Не затруднит исходник глянуть? Или даже потестить. В принципе работает, хоть и не совсем алгоритм тот что задуман, но минут 5 максимум - и всё, не реагирует на инжекты(. Может я чего не правильно делаю?

whoami · 06.04.2012, 11:26

Не глядя на код определить практически не возможно =)
скорее всего, что-то важное затираешь, либо у тебя race condition

dwa83 · 06.04.2012, 14:24

whoami, если не лень посмотреть я ссылку на архив с проектом отправлю в ЛС

Добавлено через 6 минут
Попортить память клиента помоему только этим можно, так как больше нигде в память нет записи:

Код:

BYTE INJECTOR::InjectAndExecute(void *Func, void* Params)
{
  HANDLE hProcThread;
  void* pFunction;
  void* pParams;

  pFunction = VirtualAllocEx(hProcess,NULL,4096,MEM_COMMIT,PAGE_READWRITE);
  pParams = VirtualAllocEx(hProcess,NULL,256,MEM_COMMIT,PAGE_READWRITE);
  WriteProcessMemory(hProcess,pFunction,Func,4096,NULL);
  WriteProcessMemory(hProcess,pParams,Params,256,NULL);

  hProcThread = CreateRemoteThread(hProcess,NULL,NULL,(LPTHREAD_START_ROUTINE)pFunction,pParams,NULL,NULL);
  if(hProcThread==INVALID_HANDLE_VALUE) // не удалось создать поток
  {
    VirtualFreeEx(hProcess,pFunction,4096,MEM_RELEASE);
    VirtualFreeEx(hProcess,pParams,256,MEM_RELEASE);
    return 0;
  }

  WaitForSingleObject(hProcThread,INFINITE); // ожидаем завершения работы потока
  CloseHandle(hProcThread); // освобождаем память
  VirtualFreeEx(hProcess,pFunction,4096,MEM_RELEASE); // стираем из процесса нашу функцию
  VirtualFreeEx(hProcess,pParams,256,MEM_RELEASE); // и параметры
  return 1;	// успешная инъекция и выполнение кода
}

whoami · 06.04.2012, 14:30

ok. Но только если посмотреть, погонять сейчас нет возможности.

BritishColonist · 06.04.2012, 14:39

dwa83, давайте посмотрим.
Но я уверен на 90%, что даже долго изучая код, я вряд ли смогу определить проблему. Это не так-то просто.
А сейчас я рекомендую проверить, от чего конкретно случается эта штука. Найдите код, который, возможно, грузит процесс игры, уберите его и протестируйте так. Рано или поздно проблемный код будет вычислен.
Инжектор вроде правильно написан, но длительных тестов я с ним никогда не проводил.

edit:
Если зависания и баги появляются лишь спустя длительное время, попробуйте увеличить задержку между обновлением информации о мобах.

dwa83 · 06.04.2012, 15:12

Отправил ссылку. Вообще вполне возможно что я в инжектах прочу данные стека, так как не использую pushad и popad. Сейчас везде поставил. Ещё раз бота послал, сейчас гляну виснет ли всё ещё. Насчёт задёржки в цикле, попробую если при этом тесте всё равно виснуть продолжит. Вообще раньше я делал так. Одним скопом делал снимки структур мобов, нпс, ресов и тд. а затем работал с ними не считывая пока новые данные не понядобятся. Но так было слишком накладно, потому сейчас я все получения отдельных параметров сделал отдельной функцией, чтобы при желании узнать ХП, не приходилось читать всю структуру.

А что конкретно грузит игру я понял. Это либо инжект хила пета, либо инжект выделения моба, другие скорее всего тоже весят, но я проверял конкретно только эти. Ставил их в цыкл и запускал бота. Я вот только не могу понять почему подвешивает(причём так не сразу). Если из за "порчи стека" - щас тестируется с исправлениями, пока что бегает, не висит.

Добавлено через 6 минут
И почему-то при отдельных действиях, как то "ожидание пока перс начнёт кастовать" проц взлетает до 100%.. Кроме Sleep() можно как то с проца нагрузку снимать? Не охота жертвовать скоростью реакции..

Кстати, на счёт самого бота, к запущеному клиенту он сейчас подключается кнопкой "подключиться к игре", и только потом старт нажимать нужно. А выключается пока что снятием процесса из среды BC ))

Добавлено через 40 минут
Push и Pop не причём. Перестаёт реагировать.. Причём, в игре все действия можно делать в ручную. Например, пишет "выделяю моба" но инжект не идёт. Только если вручную выделить переходит к следующему действию. Ито далее все действия проходят только вручную. То-есть бот пишетт что выполняет действие и ждёт пока закончит его делать, но это действие не проходит, поэтому он ждёт до бесконечности и посылает не действующие инжекты. Щас попробую паузы наставить в те места, где виснет..

whoami · 06.04.2012, 15:53

Сразу по оптимизации замечание: на каждый вызов делать VirtualAllocEx/Free, да ещё отдельно для опкода и параметров - не самая лучшая идея. Лучше память аллоцировать один раз, сразу под всё. Потом, большинство операций (скиллы, таргет, призыв петов) делаются с помощью пакетов, лучше по максимуму работать через них. Тут и под новую версию клиента проще будет переделывать, и меньше кода отлаживать. Один раз написал код отправки пакета - дальше пользуешься без инжектов. Ещё какой момент... лучше будет, если вы будете заранее знать размер опкода и параметров. WriteProcessMemory для 4-килобайтовых блоков выполняются сильно медленнее, чем для 511-байтовых, например. А 511 байт - это довольно дофига.

SendPacket_THREAD отгда уж лучше так, без ненужного копирования:

Код:

  DWORD Function = F_SEND_PACKET;
  DWORD len = pack->len;
  BYTE* Pointer = pack->Bytes;

dwa83 · 06.04.2012, 16:13

whoami, почитал я что значит race condition. У меня всё в один поток, я с многопоточностью на вы(не разбирался за ненадобностью). Отсюда у меня вопрос. Всё идёт в основном потоке и не продолжается пока не выполнено требуемое действие. При зацикливании по какой либо причине(ну например сканирование чего-нибудь пока не найдём) шло замораживание окна бота(так как события не обрабатывались). Я это решил путём вставки принудительной обработки событий( Aplication->ProcessMessages() ) в длительном цикле. Отсюда проблема если мы в этом цыкле "схватим" мышкой окно и держим его у нас цикл останавливается на обработке событий(перетаскивания окна). То-есть получается обратная ситуация, раньше алгоритм бота не давал выполняться событиям, теперь же события не дают продоолжиться циклам бота(в том случае если мы копаемся в окне бота в то время, когда он работает). Как этого избежать?

Добавлено через 7 минут

Цитата:

Сообщение от whoami


	SendPacket_THREAD отгда уж лучше так, без ненужного копирования:

Жмм, точно, но это мелочи, я оптимизацией хотел заняться, когда всё в идеале работать будет. А копирование массива данных пакета я сделал, так как у меня в этой функции почему-то не хочет динамически с памятью работать(вылет клиента). Что-то я не подумал, что можно сразу указатель взять, ведь параметры то уже лежат в адресном пространстве клиента. Возьму на заметку. Кстати именно вопрос о размере инжектируемой функции меня интересовал. 511 байт хватит на самую большую функцию в моём коде? Самая большая по моему инжект перемещения

Добавлено через 11 минут
Что-то типа этого?

Код:

  pFunction = VirtualAllocEx(hProcess,NULL,512,MEM_COMMIT,PAGE_READWRITE);
  pParams = pFunction+256; // например пополам
  WriteProcessMemory(hProcess,pFunction,Func,256,NULL);
  WriteProcessMemory(hProcess,pParams,Params,256,NULL);

  hProcThread ...
  WaitFor...

  CloseHandle(hProcThread); // освобождаем память
  VirtualFreeEx(hProcess,pFunction,512,MEM_RELEASE); // стираем

Добавлено через 18 минут
Ещё хотел добавить, после проставления задержек бот вроде ведёт себя адекватно. Пока вышеописанные доработки вставлять не буду, останавливать придётся, пусть пока пофармит, может ещё чего всплывёт

Вывод: клиенту не очень нравится, когда его насилуют чрезвычайно частым считыванием данных, значит всё-таки задержками решать надо. Самое интересное, что Sleep(10) оказалось вполне достаточно.

whoami · 06.04.2012, 16:41

Ну вот, например, в старой версии PWFramework (библиотека на C#) неправильно ожидалось завершения инжектированного потока - получались натуральные рейсы =) Кроме того, эта функция может вызываться параллельно самим клиентом, и хрен знает как она на это среагирует =)

По поводу гуя и асинхронности. Самое простое - не делать длительных инжектов. А они там - все не длительные. И вызывать их из обработчика WM_TIMER. То есть, раз в 200 мс (например) опрашиваете интересующие вас параметры, принимаете решение, выполняете действия и перевзводите таймер.

Насчёт опкода и параметров. Обычно параметры занимают довольно мало места (у вас там иногда это вообще DWORD - 4 байта). Размер опкода вам известен. Поэтому, сразу в процессе бота формируете блок нужного размера (размер опкода+размер параметров), сразу в него пишете одним вызовом WriteProcessMemory и то и другое. Просто эта функции - Read/WriteProcessMemory крайне медленные, чем реже её дёргаешь - тем лучше. И почему-то запись блоков в 512 происходит намного медленнее, чем 511 =) Раза так в 4 примерно. Проверял на XP SP3, почему так - не знаю.

dwa83 · 06.04.2012, 16:57

Насчёт таймера подзадумаю, наверное проще так будет. Хотя я об этом уже думал, но мне показалось, что всё получится слишком запутанным. А так если подумать немного получше, то можно поставить таймер с вызовом 200мс, внутри будет проверяться какая-нибудь переменная, которая имеет значение в зависимости от того какое действие выполнить. И по этому критерию выполнять либо каст, либо бег либо что-то ещё. Наверное что-то типа того:
если переменная Action = пуляем скилл
{
выполнить пуляние скилла
проверить пульнули или нет
если пульнули Action = бежим к следующему
}

если переменная Action = бежим к следующему
{
проверить добежали или нет
если добежали Action = пуляем скилл
}
если переменная Action = бот стой
{
выключаем таймер
}

Итого имеем конечный автомат. Помоему будет неплохо.

BritishColonist · 06.04.2012, 17:17

Кстати ;D
Чтобы избавиться от половины всех проблем, связанных с разработкой, можно писать DLL, а не EXE.
А потом DLL внедрять через мой загрузчик или своим "стартером" (в котором, например, можно и конфиг сделать).

Но тут появится другая проблема - управление ботом. Самое простое - ini-файлик, который будет проверяться из DLL.

От каких проблем избавляет техника DLL:
1) инжекты не нужно внедрять (минус половина кода);
2) в инжектах может содержаться любой код (а не только асм и не только локальные переменные);
3) прямая работа с памятью через указатели (никаких Read/WriteProcessMemory);
4) нет необходимости в поиске процесса игры (разве что проверить версию игры можно).
Минусы DLL-Injection:
1) сложно организовать нормальное управление работой бота (можно применять сообщение WM_COPYDATA или "file mapping" для обмена данными между EXE и DLL);
2) сложно лицезреть результаты, если речь идёт о конкретных числах, данных (можно прикрутить функции добавления на экран текста или запись в файл);

Таким образом DLL даёт максимальную "степень внедрения". Полный доступ к процессу без вызова WinAPI-функций, максимальное быстродействие. Настоятельно рекомендую попробовать - авось понравится.

whoami · 06.04.2012, 17:53

Я для своего PWFramework сделал функцию самоинжектирования в клиент =) правда, так до ума не довёл.
Смысл такой, что пишешь программу, которая работает с процессом клиента через VirtualAlloc/FreeEx, Read/WriteProcessMemory и CreateRemoteThreadEx. Потом делается совсем небольшая доработка: после выбора клиента процесс "вселяется" в элементклиент, т.е. туда внедряется маленькая dll-загрузчик, которая поднимает CLR, в ней создаёт AppDomain, в котором запускает тот же экзешник. Только сам экзешник может выяснить, запущен он был сам по себе, или в адресном пространстве элемента. И во втором случае он может использовать отдельный экземпляр ProcessMemory, который работает с памятью напрямую (с помощью Marshal).
Не знаю, нормально объяснил, или нет. Но в реальных своих утилитах я это не использовал.

Минус подхода "вся логика в dll" в том, что отлаживаться сложнее и любая серьёзная ошибка валит элементклиент. В случае внешнего приложения, его можно спокойно трассировать, ставить бряки и клиент оно рушит далеко не всегда.

dwa83 · 06.04.2012, 17:55

Я думаю пока что для меня сложновато это будет) Хотя если в DLL добавить API функции работы с окнами то получится так, что один процесс(по сути поток самой игры и поток DLL) имеет 2 окна, одно - окно клиента, второе - окно бота. Это ведь возможно? Если так, то можно сделать "внедряльщик" DLL, в которой есть создание своего окна и взамиодействие с ним, а затем этот "внедряльщик" просто проверяет, всё ли прошло нормально и завершает работу. Я так понимаю внедрённая DLL не является зависимой от exe, который её внедрял? Если так то можно и визуализацию результатов и управление ботом сюда прикрутить?

Наставьте на путь истинный

Общение разработчиков