PjOrion - редактирование, компиляция, декомпиляция, обфускация модов (Версия: 1.3.5 Дата: 11.08.2019)

[GPCracker 2,088]

Может реально стоит нормальный дебаггер поискать или доработать.

Вот что реально стоит доработать, так это сохранение лога в файл при работе клиента через Орион...

Я так понимаю, логи подбираются через хук на sys.stdout... Неплохо бы их дальше пробрасывать... Чтобы логи как положено писались в файл.

Да и контроль потока как-то странно работает... Иногда приходится отправлять принт чтобы "зависшие в буфере" данные "прописались".

Через что кстати потоки между процессами пробрасываешь? MMap?

Жалко не прокатит. Протекторы присекают такие вещи.

Интересно как... Проверяют чек-сумму объекта?

[StranikS_Scan 4,210]

1. Вот что реально стоит доработать, так это сохранение лога в файл при работе клиента через Орион...

2. Я так понимаю, логи подбираются через хук на sys.stdout... Неплохо бы их дальше пробрасывать... Чтобы логи как положено писались в файл.

3. Да и контроль потока как-то странно работает... Иногда приходится отправлять принт чтобы "зависшие в буфере" данные "прописались".

4. Через что кстати потоки между процессами пробрасываешь? MMap?

5. Интересно как... Проверяют чек-сумму объекта?

 

1. Сделаем

2. Да, пробросим

3. Есть такой косячёк, просто так не выковыривается, пытался, надо танцевать

4. Да не, через файл. Самый обычный текстовый файл, точнее два файла:

5. И такое делают, а еще проверяют встроенный ли метод или же он пользовательский, а еще могут  переимпорт делать

from __builtin__ import XXX

и обломать хук. Сопособов не мало.

Edited January 12, 2015 by StranikS_Scan

[GPCracker 2,088]

Да не, через файл. Самый обычный текстовый файл, точнее два файла:

mutex`ы я так понимаю для синхронизации чтения / записи буферов, чтобы чтение не начиналось раньше времени и не затирались непрочитанные данные?

Ну что я и говорил) Memory-mapped file

Есть такой косячёк, просто так не выковыривается, пытался, надо танцевать

Я так понимаю, все проходит по такой схеме:

В stdout запихивается "поток для ловли". С некоторым интервалом делается READ(). Если данные не пустые, отправляются в буфер передачи (файл).

Далее орион с некоторым интервалом проверяет буфер-файл. Если данные там изменились он их парсит и кидает в "лог"?

 

З.Ы. Надо будет как-нить написать по-нормальному передачу данных между питон-процессами / потоками в общем виде (класс) через mmap. С флагами и mutex`ами)

Edited January 12, 2015 by GPCracker

[StranikS_Scan 4,210]

 

 

mutex`ы я так понимаю для синхронизации чтения / записи буферов, чтобы чтение не начиналось раньше времени и не затирались непрочитанные данные? Ну что я и говорил) Memory-mapped file

 

Да.

Ммм оказывается такой класс есть. Я не знал. У меня обмен Ориона с клиентом идёт не питон-питон, а делфи-питон. Я на стороне Ориона через делфи читаю/пишу данные в буфере. Просто не видел смысла делать делфи-питон-питон.

 

 

В stdout запихивается "поток для ловли". С некоторым интервалом делается READ(). Если данные не пустые, отправляются в буфер передачи (файл). Далее орион с некоторым интервалом проверяет буфер-файл. Если данные там изменились он их парсит и кидает в "лог"?

 

Ага, модуль на питоне, что клиенту скармливается можешь сам глянуть в wottransmission.zip:

 

transmitter.py

 

Вот хук:

class orion_debugoutput():
    def write(self, message):
        global message_buffer
        global client_mutex, client_buffer, orion_mutex
        if len(message)>0 or len(message_buffer)>0:
            if not wottransmission_sleep:
                if not wottransmission_output_buffering or (len(message_buffer)>=5000):
                    if not orion_mutex.check():
                        if client_mutex.lock():
                            try:
                                client_buffer.write(message_buffer+str(message), wottransmission_printingsymbolsmode)
                                message = message_buffer = ''
                            finally:
                                client_mutex.unlock()
            message_buffer = message_buffer+str(message)
    def flush(self):
        pass
    def close(self):
        pass

А вот главная функция:

def orion_transfer_check():
    global wottransmission_enable, wottransmission_printingsymbolsmode
    global wottransmission_sleep, sleep_buffer
    global client_mutex, orion_mutex, orion_buffer
    if not orion_mutex.check():
        if client_mutex.lock():
            try:
                if orion_buffer.check():
                    code = orion_buffer.read()
                    if len(code)>0:
                        if not wottransmission_sleep or ('wottransmission_sleep=False' in code.replace(' ', '')):
                            try:
                                exec (sleep_buffer+str(code)) in sys.modules[__name__].__dict__
                            except:
                                import traceback
                                print traceback.format_exc()
                                return False
                            finally:
                                sleep_buffer = ''
                        else:
                            sleep_buffer = sleep_buffer+str(code)
                    return True
            finally:
                client_mutex.unlock()                
    return False

[KACTET 317]

Эх программисты вам бы получить запрос и ждать его...

Все возможные моды уже к этой игре сделаны, еште меня ругайтесь но это так.

Посему в Орион нужно вводить патчер байт кода непосредственно в worldoftanks и самое главное редактор с перехватом пакетов из игры к серверу и обратно.

Читеры давно нашли закономерность в коде, что выстрелившие враги не попадают по танку....

Я понимаю что написал немыслимые предложения для культурного программиста, но программа должна перейти на новый жёсткий уровень к этой игрушке 

Edited January 14, 2015 by KACTET

[GPCracker 2,088]

Эх программисты вам бы получить запрос и ждать его... Все возможные моды уже к этой игре сделаны, еште меня ругайтесь но это так. Посему в Орион нужно вводить патчер байт кода непосредственно в worldoftanks и самое главное редактор с перехватом пакетов из игры к серверу и обратно. Читеры давно нашли закономерность в коде, что выстрелившие враги не попадают по танку.... Я понимаю что написал немыслимые предложения для культурного программиста, но программа должна перейти на новый жёсткий уровень к этой игрушке

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

Читеры давно нашли закономерность в коде, что выстрелившие враги не попадают по танку....

Интересно, как такое работает... Если все обсчитывается на сервере. Весь питон-код связан с сишным движковым через вызовы .base и .cell. И насколько я помню, там идет команда типа moveVehicle с аргументами-флагами. Я конечно не знаю, что творится в сишной части, но по крайней мере спидхак, качественный aimbot и т.п. "мощные" читы на питоне не напишешь. Если их вообще можно создать. Засвет считается на сервере, поэтому wallhack не сделать точно, стены простреливать тоже не получится, разве что разрушаемые, про которые грамотные игроки знают и не используют как укрытие.

Не стоит забывать тот факт, что онлайн-игры бывают двух типов времени: клиентского и серверного. В первом случае читерить намного проще, ибо можно специально создавать лаги, двигаться рывками и т.д. Например, в CoD используется для этих целей банально торрент-клиент. Если игра идет в серверном времени, то все лаги играют против игрока. И читерить можно разве что за счет каких-либо ошибок или недоработок разработчиков. Поэтому если разрабы BW и WG нормально написали протокол обмена, то "неграфический" чит написать не получится.

Ну конечно использование лагов оппонента в своих целях никто не отменял (может товарищ это подразумевает под такого рода "читерством"?). Может поэтому и не пишется пинг игроков в WoT. Хотя для сокомандников писать не мешало бы. Чтобы видеть, кого дисконектнуло, а у кого реальные лаги.

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

 

З.Ы. При дисконнекте инета танк становится неподвижным (локально), а сервер продолжает выполнять последнюю команду на движение, то есть при сильных лагах танк становится попросту неуправляемым.

[StranikS_Scan 4,210]

@GPCracker, чего-ты его слушаешь, там надо было читать между строк а не дословно, он метафорами пишет ))) 

 

Что касается серверной технологии ВГ, то сервер сам моделирует игровой мир у себя и рассылаем всем клиентам данные об игровой ситуации, а принимает он от клиентов только пакеты с клавишами и кнопками. Нажата кнопка W, отпущена кнопка W, нажата правая кнопка мыши, опущена правая кнопка мыши. Пакеты принимаются постоянно, после чего ставятся в очередь, обработка пакетов и перерасчет сцена на сервере происходит каждые 100 мс, т.е. 10 раз за секунду. Все что пришло на сервер в течении 100мс он учтет при перерасчете сцены. Получается система удаленного управления объектами на сервере. Твой танк это не танк в клиенте, нет. Твой танк это танк на сервере - он удаленный объект управления. А сервер принимает от тебя пакеты с клавишами и рассчитывает реакцию этого объекта на нажатие клавиш. Так что ни чего зачитерить или хукнуть тут нельзя, чтобы игрок ни делал на клиенте. Вот так работает технология реализованная ВГ. Штука хорошая, но у нее есть недостатки. Полностью отсутствует какое-либо распределение ресурсов и вычислений. Всё делает сервер сам - отсюда, малейший тупняк на сервере и игра валиться в кашу. Также недостатком является запаздывание игры на клиенте по отношению к себе самому. Если игрок нажал кнопку выстрела, то пройдет много времени прежде чем он увидит результат. Вот как это будет. Пусть пинг игрока 50мс. Тогда после нажатия кнопки выстрела пакет уйдет на сервер и придет туда спустя 25 мс, затем он обработается и эвент выстрела встанет в очередь. Спустя 0-100мс как пакет попадет на сервер наступит новый тик сервера. Затем когда тик настанет сервер обсчитает новую сцену - это сцена в которой будет выстрел. В зависимости от нагрузки сервера на это может уйти от 1 до 100 мс и даже больше если сервер тупит и не справляется. Пусть он нагружен не сильно и все просчитал за 20мс. После этого новая сцена рассылается клиентам и наш клиент получит её спустя 25мс и увидит свой выстрел. Ну и сколько прошло времени? Считаем  25 + 1...100 + 20 + 25 = 70-170мс. Среднее значение = 120 мс. Ого! А пинг то у нас всего 50мс, а игра идёт со средней задержкой в 120 мс! Вот вам и недостатки централизованных технологий ))))

 

И сразу уж допишу чтоб картина была полной... А что же клиент? Клиент тоже снабжен графическим движком и тонной питоновских скриптов, моделирующих игровой мир. Но увы хоть клиент и умеет самостоятельно моделировать игровой мир - он бедолага кукла, манекен. Сервер присылает скупо клиенту только управляющую инфу, которая синхронизирует игровой мир клиенте с игровым миром сервера. Как это происходит, каждый может увидеть если во время игры выдернет кабель интернете, а потом воткнет его обратно. После потери связи клиент же не зависает и не останавливается. Нет, танки продолжают двигаться, физика работает сцена обновляется. Но все это происходит по инерции физическим движком игры. И если кабель не воткнуть обратно, то дальше будет дисконнект. А если воткнуть, то мы тут же увидим как произойдет синхронизация, танки мгновенно поменяют направления движения и местоположения... т.е. наш манекен опять начал плясать под дудку сервера, образно выражаясь )))) Ну и самое главное. А почему так сделано? А вот как раз для того чтобы сгладить большую задержку в работе сервера. Благодаря такому сглаживанию игрок с пингом в 30 мс и игрок с пингом в 300 мс могут спокойно играть друг с другом и у обоих игра будет идти плавно без всяких выкрутасов. Ну пока лаги у провайдеров не появятся и не испортят всю эту идилию... )))

 

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

Edited January 14, 2015 by StranikS_Scan

[GPCracker 2,088]

GPCracker, чего-ты его слушаешь, там надо было читать между строк а не дословно, он метафорами пишет )))

С чего ты решил, что я его слушаю? Я и написал, что "стандартные" читы в танках неосуществимы.

 

обработка пакетов и перерасчет сцена на сервере происходит каждые 100 мс

Известная константа) Эти 100мс компенсируют разницу в пинге неслабо так...

 

а принимает он от клиентов только пакеты с клавишами и кнопками. Нажата кнопка W, отпущена кнопка W, нажата правая кнопка мыши, опущена правая кнопка мыши.

Не совсем. Сервер принимает команды от игрока и выполняет их. На движение там точно команды. self.base.vehicle_moveWith(flags) avatar.py. ЕМНИП флаги определяют процент мощности двигателя и направление. Можешь покопаться, если интересно. А вот выстрел: self.base.vehicle_shoot(). base и cell - сишные модули, об этом в доках BW написано)

 

Кстати, не факт, что сервер все команды перепроверяет... Этим занимается клиент. Можно попробовать в трене повыполнять различные core-вызовы.

Edited January 14, 2015 by GPCracker

[StranikS_Scan 4,210]

На движение там точно команды. self.base.vehicle_moveWith(flags) avatar.py. ЕМНИП флаги определяют процент мощности двигателя и направление.

 

Подозреваю что это для локального физ движка, а не для сервера. Хотя не исключаю, что клавиши движения трансформируют в такие вот величины.

 

 

Кстати, не факт, что сервер все команды перепроверяет...

А зачем их перепроверять? Команды то из категории - вперед назад выстрел и т.д. Чего там проверять? Сервер их просто принимает а затем реагирует на них в соот. с состоянием сцены на сервере и возможностями физических величин заложенных в физ модели на сервере. 

 

Или ты хочешь сказать что если хакнуть speedlimit на клиенте (есть там такое в разделе кода про ограничение максимальной скорости движения), то танк быстрее поедет? Сомневаюсь. Думаю это только клиентской модели касается.

 

Можно попробовать в трене повыполнять различные core-вызовы.

 

Это интересно. 

Edited January 14, 2015 by StranikS_Scan

[GPCracker 2,088]

Или ты хочешь сказать что если хакнуть speedlimit на клиенте (есть там такое в разделе кода про ограничение максимальной скорости движения), то танк быстрее поедет? Сомневаюсь. Думаю это только клиентской модели касается.

Это невозможно, я сразу это сказал

На движение там точно команды. self.base.vehicle_moveWith(flags) avatar.py. ЕМНИП флаги определяют процент мощности двигателя и направление.

А вот shoot можно попробовать повызывать и интервалом 5-6 секунд для какой-нить топовой небарабанной пт.

 

Подозреваю что это для локального физ движка, а не для сервера. Хотя не исключаю, что клавиши движения трансформируют в такие вот величины.

Это команды связи с сервером. См. доки BW.

Entity

Оно самое

 

Сервер также может "вызывать" методы на клиенте, некоторые, например, находятся в avatar.py.

Edited January 14, 2015 by GPCracker

[fecell 125]

Думаю это только клиентской модели касается.

Имхо параметр скорости используется для прогнозирования положения танка на клиенте. Т.е. если изменить этот параметр то танк будет передвигаться прыжками.

пример (цифры наугад):

на клиенте с локально измененной скоростью 70 км/ч танк проезжает в течении 120мс (среднее время из расчетов выше) определенное расстояние, но реальная скорость танка на сервере 54 км/ч. Т.о. через 120мс сервер даст верное положение танка, и на клиенте он перепрыгнет на верное место. в течении следующих 120 мс он опять будет лететь ракетой и через 120 мс снова перепрыгнет чуть назад. аналогично будет если менять скорость в меньшую сторону - будет двигаться как черепаха, но прыжками, по данным сервера, корректировать свое реальное положение. результат таких изменений должен быть плачевен - никогда ни в кого не попадешь если будешь двигаться, т.к. целиться будешь и текущего положения которое видишь у себя на экране, а на сервере реальное местонахождение будет иным и траектория выстрела будет рассчитана иначе - хрен пойми куда))

Edited January 15, 2015 by fecell

[KACTET 317]

Имхо параметр скорости используется для прогнозирования положения танка на клиенте. Т.е. если изменить этот параметр то танк будет передвигаться прыжками.

пример (цифры наугад):

на клиенте с локально измененной скоростью 70 км/ч танк проезжает в течении 120мс (среднее время из расчетов выше) определенное расстояние, но реальная скорость танка на сервере 54 км/ч. Т.о. через 120мс сервер даст верное положение танка, и на клиенте он перепрыгнет на верное место. в течении следующих 120 мс он опять будет лететь ракетой и через 120 мс снова перепрыгнет чуть назад. аналогично будет если менять скорость в меньшую сторону - будет двигаться как черепаха, но прыжками, по данным сервера, корректировать свое реальное положение. результат таких изменений должен быть плачевен - никогда ни в кого не попадешь если будешь двигаться, т.к. целиться будешь и текущего положения которое видишь у себя на экране, а на сервере реальное местонахождение будет иным и траектория выстрела будет рассчитана иначе - хрен пойми куда))

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

А вот shoot можно попробовать повызывать и интервалом 5-6 секунд для какой-нить топовой небарабанной пт.

Пробовали, тоже правкой пакетов. Танк стреляет без перезарядки но сервер отключает сразу клиент... ((

Edited January 15, 2015 by KACTET

[sae 2]

Версия вроде 1.2.2, а в проге пишет по старому:

 

>>> PjOrion: 1.2.1 01/11/2014 © StranikS_Scan for http://www.koreanrandom.com/forum/
>>> Python connected: 2.7.8 (default, Jun 30 2014, 16:03:49) [MSC v.1500 32 bit (Intel)]
>>> Orion syntax: @!abc -> print abc; @!!module -> import module

[StranikS_Scan 4,210]

Версия вроде 1.2.2, а в проге пишет по старому:

 

>>> PjOrion: 1.2.1 01/11/2014 © StranikS_Scan for http://www.koreanrandom.com/forum/

>>> Python connected: 2.7.8 (default, Jun 30 2014, 16:03:49) [MSC v.1500 32 bit (Intel)]

>>> Orion syntax: @!abc -> print abc; @!!module -> import module

 

Косяк, забыл отредактировать сообщение.

[GPCracker 2,088]

Пробовали, тоже правкой пакетов. Танк стреляет без перезарядки но сервер отключает сразу клиент... ((

Детектор читеров)

[lportii 14]

Всё верно, пакеты правят именно для светляков. (просто подменяют 00 00 00 три байта в пакетах, читеры они такие ещё что придумают) Действительно со светляка сложно попасть в результате по другим танкам, но и по такому светляку не попадают, даже засвеченному. (выстрелы арты и танков идут в другое место и конечно очень много криков в чате) Такой танк умеючи и со знанием как его вести светит всю команду соперников на ура.Пробовали, тоже правкой пакетов. Танк стреляет без перезарядки но сервер отключает сразу клиент... ((

Это вроде городских легенд )

Протокол танков не просто защищен. он пздц как защищен. И серверную часть лишним выстрелом в барабане не обмануть.

И в итоге выстрел - просто танк будет дергатся.без трассера и прочего.

Изменение скорости приведет к жутким фризам.

[KACTET 317]

Это вроде городских легенд )

Протокол танков не просто защищен. он пздц как защищен. И серверную часть лишним выстрелом в барабане не обмануть.

И в итоге выстрел - просто танк будет дергатся.без трассера и прочего.

Изменение скорости приведет к жутким фризам.

Ну сервер аимбота тоже был защищён, хотя его обошли просто вставкой robots.txt в отсылаемый код )

А вообще да хешь сумм пакетов ломается и сервер отключает клиент.

Но есть одно но, начальный блок пакета не проверяется и при замене одного определённого байта в пакете, который проходит не очень часто светляк вполне ездит и в него не попадают...

Я на этом доказывать перестаю т.к. уже давно заметил что в частности программисты по другому смотрят на программы чем читеры...

[GPCracker 2,088]

в частности программисты по другому смотрят на программы чем читеры...

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

[KACTET 317]

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

\

Edited January 20, 2015 by KACTET

[spoter 1,402]

Парень, тяжелая наркота до добра не доведет...