Собственно идея очень и очень стара.
Я её описывал ещё очень давно на форуме ОК вот здесь:
Suggestion: Client Based Packet Generation
Относительно недавно начал опять работать над проблемой, и немного продвинулся. ТЕ нашёл два класа отвечающие за формирование пакетов, а так-же по две функции в них которые отвечают почти за 95% всех пакетов в ОК.
Собственно ети класы отвечают за CharServer и MapServer.
TODO:
1) Найти параметры функций для генерации и отправки определённого пакета серверу. НЕ забывать о том что данные функции есть мемберами класа, потому им ещё нужно передавать указатель на this который тоже нужно найти.
2) Зделать костяк, желательно на C/C++ который сможет вызывать данные функции из дллки внутри тела клиента, передавая им определённые параметры.
ЗЫ: Проект осуществляется при поддержке администрации и програмеров ОК, потому в ближайшем будущем всем кто согласен помочь в осуществлении данного проекта будет открыт доступ к закрытой ветке на главном Сайте ОК (Testers Corner) где собственно и будет осуществлятся вся розработка. (Что-то похожее когда-то было с РОПП). Обезательное знание хоть какого-то англиского, желательно технического. (Хотя собственно почти все уважающие себя програмисты хорошо знают инглиш)
Господа программеры, прошу присоеденяйтесь. Вместе мы победим!
Генератор Сервертайпов, Пакетно независимый хКор 1
Модератор: 4epT
Не совсем еще разобрался. хКор - это другая реализация опенкора? Или как? Просветите, не хочется быть нубом 
Если так, то возможность изменять шифровку исходящих пакетов в самом коре весьма интересна... с учетом наличия отечественных серверов, которые эту шифровку проводят по-своему, не как стандартный клиент РО
Если так, то возможность изменять шифровку исходящих пакетов в самом коре весьма интересна... с учетом наличия отечественных серверов, которые эту шифровку проводят по-своему, не как стандартный клиент РО
Midnight
Ну в общем. хКор ето просто надстройка над ОК.
Оно работает очень и очень просто.
1) Инжектится дллка в процесс клиента РО
2) Ведётся перхват и перенаправление через себя нескольких функций которые отвечают за передачу данный от клиента к серверу и наоборот.
3) ОК ето всё слушает, и иногда вставляет свои пакеты, которые отправляются тем-же путём как и отправляет сам клиент РО.
Я-же предлагаю не отправлять пакеты напрямую так как делает чКор, а использовать генераторы клиента чтобы формировать и отправлять определённые пакеты посредством самого клиента. От чего даже самая крутая зощита не поможет
Ну в общем. хКор ето просто надстройка над ОК.
Оно работает очень и очень просто.
1) Инжектится дллка в процесс клиента РО
2) Ведётся перхват и перенаправление через себя нескольких функций которые отвечают за передачу данный от клиента к серверу и наоборот.
3) ОК ето всё слушает, и иногда вставляет свои пакеты, которые отправляются тем-же путём как и отправляет сам клиент РО.
Я-же предлагаю не отправлять пакеты напрямую так как делает чКор, а использовать генераторы клиента чтобы формировать и отправлять определённые пакеты посредством самого клиента. От чего даже самая крутая зощита не поможет
Хатабыч
Почему? Одно если ты будеш использовать ручками прописаные оффсеты функций и их данных. Другое если будеш использовать патерны указателей на класы и их функции, а так-же патерн для поиска соответвующего указателя на уже инициализированый клас. Тогда всё идёт как по малсу, даже парится особо не надо, только подставлять нужные параметры в функцию и всё.
Вот например как вызвать ItemUse:
GenPackets1(this, 0x001D, ...)
Где "this" ecx параметер функции указывающий на область памяти куда инициализирован клас, "..." параметры данной функции которые Я специально упустил ради того чтоб другие не воспользовались (пока).
Таким образом, данный режим остаётся полностью самодостаточным, и выдерживает апдейты любой сложности.
Почему? Одно если ты будеш использовать ручками прописаные оффсеты функций и их данных. Другое если будеш использовать патерны указателей на класы и их функции, а так-же патерн для поиска соответвующего указателя на уже инициализированый клас. Тогда всё идёт как по малсу, даже парится особо не надо, только подставлять нужные параметры в функцию и всё.
Вот например как вызвать ItemUse:
GenPackets1(this, 0x001D, ...)
Где "this" ecx параметер функции указывающий на область памяти куда инициализирован клас, "..." параметры данной функции которые Я специально упустил ради того чтоб другие не воспользовались (пока).
Таким образом, данный режим остаётся полностью самодостаточным, и выдерживает апдейты любой сложности.
Далеко не любой. Клиент постоянно апдейтят, может измениться все что угодно, в том числе количество и тип агрументов у методов классов, которые ты планируешь вызывать. И самое главное - ты планируешь их вызывать из контекста другого потока, причем, даже не задумываясь о синхронизации. Кто тебе сказал, что эти классы потоко-независимые? Скорее всего, у объектов, занимающихся формированием пакетов, есть некие внутренние буферы, в которых пакеты собираются перед отправкой. Представь, что с ними будет, если ты сделаешь вызов кода, модифицирующего их, одновременно с клиентом. Пусть вероятность этого низкая на однопроцессорной тачке, но это возможно, и это прямой путь к появлению трудноуловимых багов - типа дисконнектов раз в час по абсолютно непонятной причине. Для Гравити же будет достаточно минимума усилий, что бы обломать всю эту малину до состояния полной неработоспособности, если этот режим вдруг станет основным для OpenKore. А как ты планируешь получать данные с сервера? Это вообще получается очень сложно сделать. Да и не такое уж это универсальное решение. Владельцам серверов, имеющих защиты, будет достаточно пакануть экзешник клиента каким-нибудь хитрым пакером, и тогда все будет впустую.. Идея конечно интересная, но реализация имхо слишком сложная, и результат абсолютно не стоит потраченных сил и времени.kLabMouse писал(а): Таким образом, данный режим остаётся полностью самодостаточным, и выдерживает апдейты любой сложности.
Эм... я наверное нупко, но если мы будем использовать указатель на уже существующий обьект класса, то и использовать мы будем буферы и данные именно этого обьекта, нет?
А имхо задача не решается, а лишь переводится в другую плоскость. Теперь изменение пакетов уже не будет работать и придется менять сами функции(передаваемые параметры, скажем). А то, что это будет ооогрооомным геммороем для тех, кто пишет сам клиент(в основном это прогеры из гравити как я понимаю) - достаточно серьезно поменять уже реализованную функцию имхо очень неприятно.
А имхо задача не решается, а лишь переводится в другую плоскость. Теперь изменение пакетов уже не будет работать и придется менять сами функции(передаваемые параметры, скажем). А то, что это будет ооогрооомным геммороем для тех, кто пишет сам клиент(в основном это прогеры из гравити как я понимаю) - достаточно серьезно поменять уже реализованную функцию имхо очень неприятно.
Хатабыч
Вообщем. Ты не прав.
1) Параметры тех функций которые Я собираюсь юзать не менялись ещё со времён Альфы РО.
2) Мне полностью по барабану запакован ли екзешник или нет, мне и так с ним в памяти работать.
3) Потоковось возможно легко обеспечить, перенаправив вызов юзаной мною функции в тело инжектеной дллки, а там уже с ним розбиратся. ТЕ ждать пока выполнится задача инициализирована самой Дллкой.
В общем хорошо реализованая библа обеспечит очень хороший поддерживающий модуль Для ОК. И в общем не планируется использование данной фичи как основной, а лишь вспомагательной.
Вообщем. Ты не прав.
1) Параметры тех функций которые Я собираюсь юзать не менялись ещё со времён Альфы РО.
2) Мне полностью по барабану запакован ли екзешник или нет, мне и так с ним в памяти работать.
3) Потоковось возможно легко обеспечить, перенаправив вызов юзаной мною функции в тело инжектеной дллки, а там уже с ним розбиратся. ТЕ ждать пока выполнится задача инициализирована самой Дллкой.
В общем хорошо реализованая библа обеспечит очень хороший поддерживающий модуль Для ОК. И в общем не планируется использование данной фичи как основной, а лишь вспомагательной.
Но тогда ты будешь полностью завязан на внутреннюю логику клиента при отправке пакетов. Если пользователь будет спать, то все, что будет делать клиент - это играть с сервером в пинг-понг каждые 12 секунд. Захотел бот пнуть моба – ему придется ждать, пока клиент соизволит отправить на сервер очередной тик.kLabMouse писал(а):Хатабыч
3) Потоковось возможно легко обеспечить, перенаправив вызов юзаной мною функции в тело инжектеной дллки, а там уже с ним розбиратся. ТЕ ждать пока выполнится задача инициализирована самой Дллкой.
Хатабыч
Нед. Ты явно не понял. Мы то уже управляем. А если клиент что-то хочет, то смотрим занята ли функция своими делами? если да, то подождём пока освободится, если нет то продолжим выполнение запроса самого клиента.
ТЕ для клиента подставляем виктивную функцию путём модификации указателя на функцию внутри процеса самого клиента. Но нам же извесно где наша функция. Значит мы через себя, как через буффер пропускаем все запросы и ответы тоже. Таким образом контролируем весь процесс вызова функции как нами так и клиентом.
Выглядит приблизительно так:
1) Находим указатель на класс, находим указатель на инициализированый клас. Сохраняем указатель на нужную функцию для дальнейшего использования.
2) Модифицируем в инициализированом класе, а так-же в инициализирующих данных указатель на нашу функцию, подставляя указатель на нашу фиктивную буфферную функцию.
Теперь мы модем контролировать вызов нужной нам функции. Таким образом мы контролируем все операции самого пользователя. А так-же защищаемся от паралельного вызова функции. Чем обеспечиваем дружественность и багозащищённость.
Нед. Ты явно не понял. Мы то уже управляем. А если клиент что-то хочет, то смотрим занята ли функция своими делами? если да, то подождём пока освободится, если нет то продолжим выполнение запроса самого клиента.
ТЕ для клиента подставляем виктивную функцию путём модификации указателя на функцию внутри процеса самого клиента. Но нам же извесно где наша функция. Значит мы через себя, как через буффер пропускаем все запросы и ответы тоже. Таким образом контролируем весь процесс вызова функции как нами так и клиентом.
Выглядит приблизительно так:
1) Находим указатель на класс, находим указатель на инициализированый клас. Сохраняем указатель на нужную функцию для дальнейшего использования.
2) Модифицируем в инициализированом класе, а так-же в инициализирующих данных указатель на нашу функцию, подставляя указатель на нашу фиктивную буфферную функцию.
Теперь мы модем контролировать вызов нужной нам функции. Таким образом мы контролируем все операции самого пользователя. А так-же защищаемся от паралельного вызова функции. Чем обеспечиваем дружественность и багозащищённость.
Понять трудно, потому что объясняешь ты немного неверно. Указателей на класс не существует. Бывают указатели на объект данного класса, это видимо “инициализированные классы”. Бывает также указатель на таблицу виртуальных методов класса, это наверно “указатель на класс”. Именно ее скорее всего ты и собираешься править. Но ты забываешь о том, что:kLabMouse писал(а):Хатабыч
Нед. Ты явно не понял. Мы то уже управляем. А если клиент что-то хочет, то смотрим занята ли функция своими делами? если да, то подождём пока освободится, если нет то продолжим выполнение запроса самого клиента.
1) Заглушки тебе придется писать для всех методов этого класса.
2) Не все методы класса обычно делаются виртуальными, вызовы не виртуальных методов ты не отследишь, их нет в той таблице.
3) Доступ к данным объекта часто возможен и без вызовов каких-либо из его методов.
Гарантированно обеспечить потоко-независимость тут можно только имея на руках исходники клиента. Вообще, это достаточно кривое решение, вызывать методы созданных неизвестно кем и когда объектов, да еще и из другого потока. Хотя возможно что тебе повезет, и все будет работать, но вероятность этого далека от 100%.
Хатабыч
Бывает также указатель на таблицу виртуальных методов класса, это наверно “указатель на класс”
Именно оно, его нам достаточно ибо используемая нами функция не вызывается из нутри самого класа, и используется только внешними функциями. Что уже есть очень и очень хорошо.
1) Заглушку достаточно написать всего лищь для одной функции класа. Так-же возможно исправить немного начало самой юзаной нами функции дабы не парить мозг с таблицами. Пока сам не определился, тулза ещё далека от реализации, хотя тесты были и всё прошло очень даже гладко.
2) Опять-же вызовынужной нам функции только виртуальные, проверил 100 раз. Хотя можно попользовать Деторус для наших целей.
3) Данные обекта меняются только самим обектом. Опять-же проверял очень много раз.
Просто Визуал С++ 6.0 на котором скомпилен клиент очень интиресно поступает. Он выделяет целый большой кусок памяти где в начале находятся указатели на публичные функции, далее константа розделяющая публичные функции от публичных переменных, далее константа отделяющая публичные переменные от приватных.
Статики же сам класс который мы решили использовать сам по себе не использует. Есть у него конечно ссылки на глобальные переменные, но они опять-же не являются мемберами класа. Тем более что все параметры по которым строится каждый из пакетов берутся из параметров функции, и только из параметров функции.
Таким образом что есть:
1) Класс, указатель на область памяти куда инициализирован класс, где прописаны все его публичные методы и публичные с приватными переменными.
2) Все нужные глобальные переменные, указатели на них, указатели на структуры, указатели на указатели на структуры, ну всё в таком роде.
3) Местоположение (оффсет) нужной нам функции.
4) Подредактированая таблица публичных методов класа (найденая в пункте 1), для большей уверенности ещё и джамп на нашу функции прямо в начале юзаной нами функции (делает такую вещь Деторус).
Таким образом. У нас есть все данные даже для того чтоб не только вызывать нужную нам функцию, а даже чтоб создать абсолютно фиктивный класс, который сам клиент приймет как свой.
ЗЫ: Вот одного не понимаю. Зачем здесь розводить весь сыр-бор если можно в закрытой ветке ОК по дальше от глаз Гравити.
Бывает также указатель на таблицу виртуальных методов класса, это наверно “указатель на класс”
Именно оно, его нам достаточно ибо используемая нами функция не вызывается из нутри самого класа, и используется только внешними функциями. Что уже есть очень и очень хорошо.
1) Заглушку достаточно написать всего лищь для одной функции класа. Так-же возможно исправить немного начало самой юзаной нами функции дабы не парить мозг с таблицами. Пока сам не определился, тулза ещё далека от реализации, хотя тесты были и всё прошло очень даже гладко.
2) Опять-же вызовынужной нам функции только виртуальные, проверил 100 раз. Хотя можно попользовать Деторус для наших целей.
3) Данные обекта меняются только самим обектом. Опять-же проверял очень много раз.
Просто Визуал С++ 6.0 на котором скомпилен клиент очень интиресно поступает. Он выделяет целый большой кусок памяти где в начале находятся указатели на публичные функции, далее константа розделяющая публичные функции от публичных переменных, далее константа отделяющая публичные переменные от приватных.
Статики же сам класс который мы решили использовать сам по себе не использует. Есть у него конечно ссылки на глобальные переменные, но они опять-же не являются мемберами класа. Тем более что все параметры по которым строится каждый из пакетов берутся из параметров функции, и только из параметров функции.
Таким образом что есть:
1) Класс, указатель на область памяти куда инициализирован класс, где прописаны все его публичные методы и публичные с приватными переменными.
2) Все нужные глобальные переменные, указатели на них, указатели на структуры, указатели на указатели на структуры, ну всё в таком роде.
3) Местоположение (оффсет) нужной нам функции.
4) Подредактированая таблица публичных методов класа (найденая в пункте 1), для большей уверенности ещё и джамп на нашу функции прямо в начале юзаной нами функции (делает такую вещь Деторус).
Таким образом. У нас есть все данные даже для того чтоб не только вызывать нужную нам функцию, а даже чтоб создать абсолютно фиктивный класс, который сам клиент приймет как свой.
ЗЫ: Вот одного не понимаю. Зачем здесь розводить весь сыр-бор если можно в закрытой ветке ОК по дальше от глаз Гравити.