Как перехватить tcp upd для игр
Перейти к содержимому

Как перехватить tcp upd для игр

  • автор:

Перехватчик пакетов для онлайн игр

new Bookmark Locked Falling

Admin
Administrator
*****

Перехватчик пакетов для онлайн игр Jan 9, 2017 20:19:58 GMT

Post by Admin on Jan 9, 2017 20:19:58 GMT

Я слышал можно в онлайн играх одну вещь в сумке приврать в другую связано это с подменой сетевых пакетов. А теперь о подводных камнях Ломать таким ламерским способом ты сможешь только говно-игры на подобие MU Online Так как например тот-же WOW использует 2х полосную систему шифрования. Моментальный выход из игры(без пакетов) перехватчик пакетов для онлайн игр. перехватчик пакетов для онлайн игр. Игра домовёнок кузя играть онлайн бесплатно — Новые онлайн игры, бесплатные MMORPG, лучшие браузерные игры, новые онлайн миры — dyakanbackrol.land.ru Смотреть онлайн мультсериал Про домовенка Кузю бесплатно в хорошем качестве.
Онлайн игри самоубийца
NetworkMiner — Сниффер, перехватчик и анализатор пакетов. Утилита пассивно анализирует дамп с трафиком, безошибочно определяет участников обмена сетевыми данными и распознает операционные системы, установленные на каждом хосте, по размеру окна, времени жизни пакета и уникальному набору флагов. Online игра mmorpg Для перехвата пакетов всех станций сегмента требуется перевести вашу сетевую карту в режим под названием promiscuous mode, чтобы она «бесстыдно» продолжала читать не предназначенные ей пакеты. Снифферы: перехват информации IP адрес http онлайн снифферы Как узнать чужой IP адрес город местоположение Скачать сниффер для Windows Как скрыть свой IP адрес компьютера?
Текстовая мморпг онлайн
Перехват пакетов. Добавить комментарий. 2 ответа [Последняя публикация]. Как на Delphi можно перехватить сетевые пакеты отправленные определенной программой по протоколам TCP и UDP? Нужно перехватить пакеты, отредактировать содержимое пакетов, перенаправить их на другой адрес и порт, и также при попытке программы получить с какого-то адреса UDP пакет нужно подменить его полученным с другого адреса. Перехватчик пакетов. Alex2ndr, Загорелся написать бота для онлайн игры, эти пакеты должны передаваться программе в онлайн режиме из ходя из их содержания производится движения мышки, нажиматься клавиши клавиутары etc. Лог не сохраняется в файле в онлайн режиме(только через save as), а хранится в оперативной памяти. Игры рпг и онлайн Поиск. Наш опрос. Какая онлайн игра лучше? Варфейс ваще чёткая игра. Программа для перехвата исходящих пакетов в игре R2 Online. Ей пока только можно просматривать перехваченный трафик. Но это уже пол дела. 1. SmartSniff — крошечная бесплатная утилита, предназначенная для перехвата и просмотра TCP/IP-пакетов, передаваемых через сетевые адаптеры между клиентскими и серверными машинами. Вы можете просматривать TCP/IP обмен в режиме ASCII (для текстовых прото

Отправить пакет на локальный порт windows

Всем привет. Появилась нетривиальная задача, которая состоит в том, чтобы организовать «домашнюю сеть» между устройствами из интернета через публичный сервер. Написана логика обмена данными, протокол TCP\UDP. Вопрос состоит в том, чтобы на определенный порт windows отправить уже полученные ранее пакеты, чтобы это выглядело как будто данные пришли из локальной сети. Грубо говоря организовать домашнюю локальную сеть между устройствами из публичного интернета путем эмуляции и отправки пакетов на локальный порт локальной машины.
В трех словах : есть клиент и сервер, клиент организует перехват пакетов с локального порта и отправку их на сервер, сервер ретранслирует пакет дальше другому клиенту, другой клиент получает пакет и отправляет его на локальный порт на той машине где он запущен. Таким образом организуется виртуальная локальная сеть между всеми машинами. Пишу на c#.
Принимаются любые мысли, любая информация связанная с этой темой.

  • Der FlugSimulator
  • Участник

#1
10:46, 3 июня 2020

ДобрыйБарин
> Появилась нетривиальная задача, которая состоит в том, чтобы организовать
> «домашнюю сеть» между устройствами из интернета

VPN не подходит?

  • ДобрыйБарин
  • Постоялец

#2
11:00, 3 июня 2020

rcsim
> VPN не подходит?

Не подойдет. Есть свой сервер через который нужно организовать передачу по своему протоколу грубо говоря. Сама передача данных клиент-сервер-клиент уже организована.
Я пытаюсь понять есть-ли инструменты на уровне WinAPI чтоб перехватить пакет и обратно принудительно передать пакет на локальный порт? Чтобы не только мое приложение увидело пакет который пришел, а любое приложение открытое в windows на данном порту. По принципу работы сниффера.
Приложение думает что оно отправило пакет на 127.0.0.1:8080 а на самом деле я его захватил и ретранслировал на сервер куда то в интернет. Потом получил этот пакет и перенаправил на 127.0.0.1:8080 уже на другой локальной машине из под системы.

  • Dmitry_Milk
  • Постоялец

#3
11:48, 3 июня 2020

ДобрыйБарин, ты понятия layer2 (канальный уровень) и layer3 (сетевой уровень) различаешь?

«Домашняя сеть» — это layer2, то есть от интерфейса (скорее всего виртуального) одной машины до интерфейса другой машины надо доставлять фреймы канального уровня, а не IP-пакеты сетевого уровня. С точки зрения машин, которые должны ощущать себя в одной локалке, речь должна идти про MAC-адреса, а не про IP-адреса и порты. То есть, внутрь IP-пакетов канала между клиентом и сервером надо запихивать ethernet-фреймы фейковой локалки, а не просто заниматься NAT-ом.

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

  • ДобрыйБарин
  • Постоялец

#4
12:08, 3 июня 2020

Dmitry_Milk
> ты понятия layer2 (канальный уровень) и layer3 (сетевой уровень) различаешь?
Конечно не различаю, иначе бы не задавал такие вопросы. Я не спец по сети, и другим занимаюсь.
Я знаю что такое делают через установку дополнительного адаптера сети, но многие приложения не умеют выставлять приоритеты адаптера, этим приходится заниматься руками из под системы, что влечет другие проблемы и массу неудобства. Задача состоит в том, чтобы не использовать никакие сторонние сетевые адаптеры кроме стандартного адаптера windows который установлен изначально по умолчанию и на него маршрутизировать все данные таким образом чтобы для конечного приложения оно выглядело как пакеты пришедшие из локалки с какого-то там порта.
Я примерно понял о чем вы написали, вопрос в реализации этого, как это можно сделать.
Dmitry_Milk
> С точки зрения машин, которые должны ощущать себя в одной локалке, речь должна
> идти про MAC-адреса, а не про IP-адреса и порты. То есть, внутрь IP-пакетов
> канала между клиентом и сервером надо запихивать ethernet-фреймы фейковой
> локалки, а не просто заниматься NAT-ом.
Тем не менее NAT-ом если я правильно понял все же нужно заниматься, но внутри ip пакетов вшивать ethernet-фреймы которые захватили, а потом обратно распаковывать у получателя.

ps.Все, я понял о чем речь. Еще бы пример, как это можно организовать средствами c#.
Как перехватить ethernet-фреймы от какого-либо приложения ну или адаптера и передать их обратно на тот же уровень. Есть какие-то готовые библиотеки для этого? Чтобы не писать велосипеды.
Короче мне нужен тупо MAC уровень, чтобы с него пакеты брать и на него же отдавать. Если я все правильно понял.

  • Dmitry_Milk
  • Постоялец

#5
12:37, 3 июня 2020

ДобрыйБарин
> Еще бы пример, как это можно организовать средствами c#

Скорее всего никак. Хоть NAT, хоть работа на канальном уровне — это вмешательство в сетевой стек. То есть нужно будет что-то устанавливать как дополнительный драйвер в систему (скажем, как какой-нибудь Wireshark требует ставить winpcap).

ДобрыйБарин
> Тем не менее NAT-ом если я правильно понял все же нужно заниматься, но внутри
> пакетов вшивать информацию о том, что пакет якобы с локальной сети пришел.

В стандартных решениях это делается путем инкапсуляции фреймов (содержащих в себе IP-пакеты локалки) внутрь IP-транспорта, а не подменой адресов в IP-пакетах.

  • Dmitry_Milk
  • Постоялец

#6
12:43, 3 июня 2020

Да, есть еще один путь. По типу SOCKS. То есть, подменой функций из winsock-библиотеки. Приложение думает, что оно открывает и работает с обычным IP-сокетом на IP-адресе сетевой карты, а фактически подменные функции делают нечто другое внутри IP-транспорта.

  • ДобрыйБарин
  • Постоялец

#7
12:45, 3 июня 2020

Dmitry_Milk
> Да, есть еще один путь. По типу SOCKS. То есть, подменой функций из
> winsock-библиотеки. Приложение думает, что оно открывает и работает с обычным
> IP-сокетом на IP-адресе сетевой карты, а фактически подменные функции делают
> нечто другое внутри IP-транспорта.
Да, вот это уже интересно. Как подменить функции winsock?

#8
14:17, 3 июня 2020

Появилась нетривиальная задача

В чем она нетривиальная?

Есть 100500 способов решения данного вопроса, простейший пример Тимвьювер.

— Есть внешний сервер
— Есть локальные компы, которые должны общаться между собой из под NAT

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

1) Запускается внешний сервер с известным вам портом, который доступен в интернете (делать защиту что бы другие не могли к нему подключиться или нет ваше дело)
2) Запускается сервер на локальном IP на каком то порту (при необходимости прописываются разрешения)
3) тут есть различия, если ваш софт или стандартный, например, Google chrome
3.1) Ваш софт:
— нет необходимости в пункте 2.
— подключаетесь напрямую к своему серверу в инете и передаете нужные данные
3.2) Снатдартный софт
— С помощью netsh делаете правила перенаправления портов на ваш запущенный локальный сервер
Например, порт 80 перенаправлять на 127.0.0.1:8080 (ваш локальный сервер)
— Сервер получает коннект, и полный доступ ко всем пакетам, вы тупо их читаете, передаете на внешный сервер в инете запущенный ранее, он их передает уже куда надо, читает полученный данные, передает на локальный сервер, так как коннект уже был установлен ранее, и локальный сервер их проксирует обратно в проогу, так как коннект был установлен тоже ранее.

1) 1.1.1.1:12345 — сервер в инете
2) 127.0.0.1:8080 локальный сервер
3) проброс порта 80 на 127.0.0.1:8080
получается

Google chrome > connect http://gamedev.ru:80 > 127.0.0.1:8080 > полный доступ к пакетам. читаем > send to 1.1.1.1:12345 > 1.1.1.1:12345 recv. pars, send, recv req > send to soket 127.0.0.1:8080 > send to Google chrome

P.S. Зачем вам обратная прокся?

C:\Users\tmp>netsh netsh>help Применимы следующие команды: Команды в этом контексте: .. - Переход на один контекстный уровень вверх. ? - Отображение списка команд. abort - Отмена изменений, сделанных в режиме работы вне сети. add - Добавление элемента конфигурации в список элементов. advfirewall - Изменения в контексте 'netsh advfirewall'. alias - Добавление псевдонима. bridge - Изменения в контексте 'netsh bridge'. bye - Выход из программы. commit - Применение изменений, сделанных в автономном режиме. delete - Удаление элемента конфигурации из списка элементов. dhcpclient - Изменения в контексте 'netsh dhcpclient'. dnsclient - Изменения в контексте 'netsh dnsclient'. dump - Отображение сценария конфигурации. exec - Запуск файла сценария. exit - Выход из программы. firewall - Изменения в контексте 'netsh firewall'. help - Отображение списка команд. http - Изменения в контексте 'netsh http'. interface - Изменения в контексте 'netsh interface'. ipsec - Изменения в контексте 'netsh ipsec'. lan - Изменения в контексте 'netsh lan'. mbn - Изменения в контексте 'netsh mbn'. namespace - Изменения в контексте 'netsh namespace'. nap - Изменения в контексте 'netsh nap'. netio - Изменения в контексте 'netsh netio'. offline - Переход в режим работы вне сети. online - Переход в оперативный режим. p2p - Изменения в контексте 'netsh p2p'. popd - Получение контекста из стека. pushd - Помещение текущего контекста в стек. quit - Выход из программы. ras - Изменения в контексте 'netsh ras'. rpc - Изменения в контексте 'netsh rpc'. set - Обновление параметров конфигурации. show - Отображение информации. trace - Изменения в контексте 'netsh trace'. unalias - Удаление псевдонима. wcn - Изменения в контексте 'netsh wcn'. wfp - Изменения в контексте 'netsh wfp'. winhttp - Изменения в контексте 'netsh winhttp'. winsock - Изменения в контексте 'netsh winsock'. wlan - Изменения в контексте 'netsh wlan'. Доступны следующие дочерние контексты: advfirewall bridge dhcpclient dnsclient firewall http interface ipsec lan mbn n amespace nap netio p2p ras rpc trace wcn wfp winhttp winsock wlan

уже на другой локальной машине из под системы

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

А вот написать сниффер, который будет ловить не только исходящие пакеты, но и входящие — вот это более или менее нетривиальная задача.

  • ДобрыйБарин
  • Постоялец

#9
15:22, 3 июня 2020

FourGen
> Зачем вам обратная прокся?
У меня есть свой собственный сервер, у которого серый ип. Я хочу на нем запустить свой клиент для ретрансляции пакетов из локальной сети через vps сервер на подключенные клиенты и хостить то, что мне нужно, чтобы к нему был доступ из внешнего интернета, а ретранслятором выступал бесплатный vps на node js. «Раз в пол года» нужно запускать локально какое-либо приложение чтобы его тестировать, и чтобы оно имело виртуальную связь по локальной сети.
Спасибо за ответ, кажется, netsh работает так как мне нужно.

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

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

#10
17:16, 3 июня 2020

netsh работает так как мне нужно

Обратите внимание там там для проброса портов с помощью netsh необходимо наличие установленного IPv6 обязательно во всех системах, и службу запустить нужно. Сейчас не перед глазами не скажу какую. Иначе порты будут открыты, но трафик не пойдет.

Лишь бы приложения думали что обмен пакетами происходит в локальной сети

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

Снифферы и не только. Выбираем инструмент для перехвата и анализа трафика

Ана­лиз тра­фика — важ­ней­ший этап тес­тирова­ния на про­ник­новение (или даже взло­ма). В переда­ваемых по сети пакетах мож­но обна­ружить мно­го инте­рес­ного, нап­ример пароли для дос­тупа к раз­ным ресур­сам и дру­гие цен­ные дан­ные. Для перех­вата и ана­лиза тра­фика исполь­зуют­ся сниф­феры, которых челове­чес­тво при­дума­ло великое мно­жес­тво. Сегод­ня мы погово­рим о самых популяр­ных сниф­ферах под вин­ду.

Теория

Что­бы перех­ватывать тра­фик, ана­лиза­торы могут исполь­зовать перенап­равле­ние пакетов или задей­ство­вать так называ­емый Promiscuous mode — «нераз­борчи­вый» режим работы сетево­го адап­тера, при котором отклю­чает­ся филь­тра­ция и адап­тер при­нима­ет все пакеты незави­симо от того, кому они адре­сова­ны. В обыч­ной ситу­ации Ethernet-интерфейс филь­тру­ет пакеты на каналь­ном уров­не. При такой филь­тра­ции сетевая кар­та при­нима­ет толь­ко широко­веща­тель­ные зап­росы и пакеты, MAC-адрес в заголов­ке которых сов­пада­ет с ее собс­твен­ным. В режиме Promiscuous все осталь­ные пакеты не отбра­сыва­ются, что и поз­воля­ет сниф­феру перех­ватывать дан­ные.

Те­оре­тичес­ки мож­но собирать вооб­ще все пакеты в сег­менте локаль­ной сети, где уста­нов­лен сниф­фер, одна­ко в этом слу­чае дан­ных для пос­леду­юще­го ана­лиза будет слиш­ком мно­го, да и фай­лы жур­налов быс­тро рас­пухнут до совер­шенно неп­рилич­ных раз­меров. А мож­но нас­тро­ить при­ложе­ние таким обра­зом, что­бы оно отлавли­вало тра­фик толь­ко опре­делен­ных про­токо­лов (HTTP, POP3, IMAP, FTP, Telnet) или ана­лизи­рова­ло лишь пер­вые 100 байт каж­дого пакета, где обыч­но и содер­жится самое инте­рес­ное: адрес целево­го хос­та, логины и пароли. Сов­ремен­ные сниф­феры могут слу­шать в том чис­ле и зашиф­рован­ный тра­фик.

Не­ред­ко ана­лиза­торы тра­фика при­меня­ются в «мир­ных» целях — для диаг­ности­ки сети, выяв­ления и устра­нения непола­док, обна­руже­ния вре­донос­ного ПО или что­бы выяс­нить, чем заняты поль­зовате­ли и какие сай­ты они посеща­ют. Но имен­но при иссле­дова­нии безопас­ности сетево­го перимет­ра или тес­тирова­нии на про­ник­новение сниф­фер — незаме­нимый инс­тру­мент для раз­ведки и сбо­ра дан­ных. Сущес­тву­ют сниф­феры для раз­личных опе­раци­онных сис­тем, кро­ме того, подоб­ное ПО мож­но уста­новить на роуте­ре и иссле­довать весь про­ходя­щий через него тра­фик. Сегод­ня мы погово­рим о наибо­лее рас­простра­нен­ных популяр­ных ана­лиза­торах тра­фика для плат­формы Microsoft Windows.

Wireshark

  • Про­изво­дитель: Wireshark Foundation
  • Сайт:https://www.wireshark.org
  • Ли­цен­зия: бес­плат­но

Об этой прог­рамме зна­ет, навер­ное, каж­дый, кто хотя бы раз стал­кивал­ся с задачей ана­лиза тра­фика. Популяр­ность Wireshark впол­не оправдан­на: во‑пер­вых, дан­ный про­дукт бес­пла­тен, во‑вто­рых, его воз­можнос­тей впол­не хва­тает для решения самых насущ­ных воп­росов, каса­ющих­ся перех­вата и ана­лиза переда­ваемых по сети дан­ных. Про­дукт поль­зует­ся зас­лужен­ной популяр­ностью у вирус­ных ана­лити­ков, реверс‑инже­неров, сис­темных адми­нис­тра­торов и, безус­ловно, пен­тесте­ров.

Что такое Wireshark, знает, наверное, каждый

Этот ана­лиза­тор име­ет рус­ско­языч­ный интерфейс, уме­ет работать с боль­шим количес­твом сетевых про­токо­лов (перечис­лять здесь их все лишено смыс­ла: пол­ный спи­сок мож­но най­ти на сай­те про­изво­дите­ля). В Wireshark мож­но разоб­рать каж­дый перех­вачен­ный пакет на час­ти, прос­мотреть его заголов­ки и содер­жимое. У при­ложе­ния очень удоб­ный механизм навига­ции по пакетам, вклю­чая раз­личные алго­рит­мы их поис­ка и филь­тра­ции, есть мощ­ный механизм сбо­ра ста­тис­тики. Сох­ранен­ные дан­ные мож­но экспор­тировать в раз­ные фор­маты, кро­ме того, сущес­тву­ет воз­можность авто­мати­зиро­вать работу Wireshark с помощью скрип­тов на Lua и под­клю­чать допол­нитель­ные (даже раз­работан­ные самос­тоятель­но) модули для раз­бора и ана­лиза тра­фика.

По­мимо Ethernet, сниф­фер уме­ет перех­ватывать тра­фик бес­про­вод­ных сетей (стан­дарты 802.11 и про­токол Bluetooth). Тул­за поз­воля­ет ана­лизи­ровать тра­фик IP-телефо­нии и вос­ста­нав­ливать TCP-потоки, под­держи­вает­ся ана­лиз тун­нелиро­ван­ного тра­фика. Wireshark отлично справ­ляет­ся с задачей декоди­рова­ния про­токо­лов, но, что­бы понять резуль­таты это­го декоди­рова­ния, надо, безус­ловно, хорошо раз­бирать­ся в их струк­туре.

К недос­таткам Wireshark мож­но отнести то, что вос­ста­нов­ленные потоки не рас­смат­рива­ются прог­раммой как еди­ный буфер памяти, из‑за чего зат­рудне­на их пос­леду­ющая обра­бот­ка. При ана­лизе тун­нелиро­ван­ного тра­фика исполь­зует­ся сра­зу нес­коль­ко модулей раз­бора, и каж­дый пос­леду­ющий в окне прог­раммы замеща­ет резуль­тат работы пре­дыду­щего — в ито­ге ана­лиз тра­фика в мно­гоуров­невых тун­нелях ста­новит­ся невоз­можен.

В целом Wireshark — не прос­то популяр­ный, но очень доб­ротный про­дукт, поз­воля­ющий отсле­дить содер­жимое гуля­ющих по сети пакетов, ско­рость их переда­чи, най­ти «проб­лемные мес­та» в сетевой инфраструк­туре. Но в отли­чие от ком­мерчес­ких при­ложе­ний здесь нет удоб­ных инс­тру­мен­тов визу­али­зации. Кро­ме того, с помощью Wireshark не так уж и прос­то, нап­ример, выловить из тра­фика логины и пароли, а это одна из типич­ных задач при тес­тирова­нии на про­ник­новение.

CommView

  • Про­изво­дитель: TamoSoft
  • Сайт:https://www.tamos.ru/products/commview/
  • Ли­цен­зия: плат­ный, покуп­ка лицен­зии или под­писка

Сре­ди сущес­тву­ющих ныне сниф­феров CommView — один из самых ста­рых и зас­лужен­ных ветера­нов, об этом про­дук­те «Хакер» пи­сал еще в 2001 году. Про­ект жив и по сей день, активно раз­вива­ется и обновля­ется: пос­ледняя на текущий момент вер­сия датиро­вана 2020 годом. Нес­мотря на то что про­дукт плат­ный, про­изво­дитель пред­лага­ет ска­чать три­ал, который поз­воля­ет пос­мотреть работу при­ложе­ния на прак­тике — проб­ная вер­сия сниф­фера перех­ватыва­ет тра­фик в течение пяти минут, пос­ле чего про­сит денег.

CommView — заслуженный «ветеран» в мире снифферов

Прог­рамма име­ет рус­ско­языч­ный интерфейс, что может стать опре­деля­ющим фак­тором при выборе сниф­фера для поль­зовате­лей, не вла­деющих англий­ским. Глав­ное пре­иму­щес­тво CommView — воз­можность гиб­ко нас­тро­ить пра­вила филь­тра­ции пакетов: мож­но выб­рать отдель­ные про­токо­лы, которые будет отсле­живать при­ложе­ние, сор­тировать пакеты по ряду приз­наков, нап­ример по раз­меру или заголов­ку. Ассорти­мент под­держи­ваемых про­токо­лов так­же весь­ма велик: сниф­фер уме­ет работать с самыми рас­простра­нен­ными прик­ладны­ми про­токо­лами, а так­же выпол­нять реконс­трук­цию TCP-сес­сии и UDP-потока. При этом CommView поз­воля­ет ана­лизи­ровать тра­фик вплоть до пакетов про­токо­лов самого низ­кого уров­ня — TCP, UDP, ICMP, а так­же прос­матри­вать «сырые» дан­ные. Прог­рамма показы­вает заголов­ки перех­вачен­ных пакетов, собира­ет под­робную ста­тис­тику IP-тра­фика. Сох­ранен­ные дан­ные мож­но экспор­тировать в 12 раз­личных фор­матов, начиная с .txt и .csv и закан­чивая фай­лами дру­гих ана­лиза­торов вро­де Wireshark.

По­мимо тра­фика на сетевой кар­те, CommView может монито­рить соеди­нения по VPN, а так­же тра­фика, про­ходя­щего через модемы — ана­лого­вые, мобиль­ные, ADSL, ISDN и дру­гие, для чего в сис­тему уста­нав­лива­ется спе­циаль­ный драй­вер. Есть воз­можность перех­вата VoIP-тра­фика и сес­сий SIP-телефо­нии. В сос­тав при­ложе­ния вхо­дит генера­тор пакетов, с помощью которо­го мож­но отпра­вить на задан­ный Ethernet-интерфейс пакет ука­зан­ной дли­ны, с про­изволь­ными заголов­ками и содер­жимым. Есть так­же доволь­но удоб­ный прос­мот­рщик лог‑фай­лов, поз­воля­ющий откры­вать фай­лы жур­налов в отдель­ном окне сниф­фера и выпол­нять поиск по их содер­жимому.

Тул­за, вне вся­ких сом­нений, край­не удоб­ная и полез­ная, если бы не «кусачие» цены на лицен­зию. Для про­фес­сиональ­ного пен­тесте­ра покуп­ка такого инс­тру­мен­та навер­няка будет оправдан­на, но ради того, что­бы разок «гля­нуть сеть», мож­но поис­кать аль­тер­натив­ные — более дешевые или бес­плат­ные решения.

Intercepter-NG

Это тоже очень ста­рый и убе­лен­ный седина­ми инс­тру­мент — впер­вые «Хакер» на­писал о нем еще в 2012 году. C тех пор раз­рабаты­ваемый нашими сооте­чес­твен­никами про­ект не толь­ко не исчез с прос­торов интерне­та, как мно­гие его кон­курен­ты, но даже активно раз­вивал­ся и совер­шенс­тво­вал­ся — пос­ледняя акту­аль­ная редак­ция сниф­фера датиро­вана 2020 годом. Сущес­тву­ет вер­сия прог­раммы для Android в виде .APK-фай­ла и даже кон­соль­ная вер­сия это­го инс­тру­мен­та для Unix.

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее

Вариант 2. Открой один материал

Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя! Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.

Как разобрать сетевой протокол мобильной MMORPG

За годы игры в одну мобильную ММОRPG у меня накопился некоторый опыт по ее реверс-инжинирингу, которым я хотел бы поделиться в цикле статей. Примерные темы:

  1. Разбор формата сообщений между сервером и клиентом.
  2. Написание прослушивающего приложения для просмотра трафика игры в удобном виде.
  3. Перехват трафика и его модификация при помощи не-HTTP прокси-сервера.
  4. Первые шаги к собственному («пиратскому») серверу.

Требуемые инструменты

Для возможности повторения шагов, описанных ниже, потребуются:

  • ПК (я делал на Windows 7/10, но MacOS тоже может подойти, если пункты ниже там доступны);
  • Wireshark для анализа пакетов;
  • 010Editor для парсинга пакетов по шаблону (не обязательно, но позволяет быстро и легко описывать формат сообщений);
  • само мобильное устройство с игрой.

Разбор формата сообщений между сервером и клиентом

Для начала, нам необходимо видеть трафик мобильного устройства. Сделать это достаточно просто (хотя я очень долго доходил до этого очевидного решения): на нашем ПК создаем точку доступа Wi-Fi, подключаемся к ней с мобильного устройства, выбираем в Wireshark нужный интерфейс — и весь мобильный трафик у нас перед глазами.

Зайдя в игру и подождав некоторое время, чтобы запросы, не связанные с самим игровым сервером, прекратились, можно наблюдать следующую картину:

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

tcp && tcp.payload && tcp.port == 44325 

Если встать в тихом месте, вдали от других игроков и NPC, и ничего не делать, можно увидеть постоянно повторяющиеся сообщения от сервера и клиента (размером 76 и 84 байт соответственно). В моем случае минимальное количество разнообразных пакетов посылалось на экране выбора персонажа.

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

Первым делом бросается в глаза идентичность пакетов. 8 дополнительных байт у ответа при переводе в десятичную систему очень похожи на метку времени в секундах: 5CD008F816 = 155713765610 (из первой пары). Сверяем часы — да, так и есть. Предыдущие 4 байта совпадают с последними 4 байтами в запросе. При переводе получаем: A4BB16 = 4217110 , что также очень похоже на время, но уже в милисекундах. Оно примерно совпадает со временем с момента запуска игры, и скорее всего так и есть.

Осталось рассмотреть первые 6 байт запроса и ответа. Легко заметить зависимость значения первых четырех байт сообщения (назовем этот параметр L ) от размера сообщения: ответ от сервера больше на 8 байт, значение L тоже увеличилось на 8, однако размер пакета больше на 6 байт значения L в обоих случаях. Также можно заметить что два байта после L сохраняют свое значение как в запросах от клиента, так и от сервера, а учитывая, что их значение отличается на один, можно с уверенностью сказать, что это код сообщения C (связанные коды сообщений скорее всего будут определены последовательно). Общая структура понятна достаточно, чтобы написать минимальный шаблон для 010Editor:

  • первые 4 байта — L — размер полезной нагрузки сообщения;
  • следующие 2 байта — C — код сообщения;
  • сама полезная нагрузка.
struct Event < uint payload_length ; ushort event_code ; byte payload[payload_length] ; >; 

Значит, формат сообщения пинга клиента: послать локальное время пинга; формат ответа сервера: послать то же время и время отправки ответа в секундах. Вроде не сложно, да?

Попробуем разобрать пример посложнее. Стоя в тихом месте и спрятав пакеты пинга, можно найти сообщения телепорта и создания предмета (craft). Начнем с первого. Владея данными игры я знал какое значение точки телепорта искать. Для тестов я использовал точки со значениями 0x2B , 0x67 , 0x6B и 0x1AF . Сравним со значениями в сообщениях: 0x2B , 0x67 , 0x6B и 0x3AF :

Непорядок. Видны две проблемы:

  1. значения не 4-х байтовые, а разного размера;
  2. не все значения совпадают с данными из файлов, причем в данном случае разница равна 128.
  • непонятное 0x08 перед ожидаемым значением;
  • 4-х байтовое значение, на 4 меньшее L (назовем его D . Это поле появляется далеко не во всех сообщениях, что немного странно, но там, где оно есть, зависимость L — 4 = D сохраняется. С одной стороны, для сообщений с простой структурой (как пинг) оно не требуется, но с другой — выглядит оно бесполезным).

Ожидаемые значения 14183 и 14285 тоже не соответствуют действительным 28391 и 28621, но разница тут уже намного больше 128. Проведя много тестов (в том числе и с другими типами сообщений) выяснилось, что чем больше ожидаемое число, тем больше разница между значением в пакете. Что было странно, так это то, что значения до 128 оставались сами собой. Поняли, в чем дело? Очевидная ситуация для тех, кто уже сталкивался с этим, а мне, по незнанию, пришлось два дня разбирать этот «шифр» (в конечном итоге во «взломе» помог анализ значений в бинарном виде). Описанное выше поведение называется Variable Length Quantity (значение переменной длины) — представление числа, в котором используется неопределенное количество байт, где восьмой бит байта (бит продолжения) определяет наличие следующего байта. Из описания очевидно, что чтение VLQ возможно только в порядке Little-Endian. По совпадению все значения в пакетах в таком порядке.

Теперь, когда мы знаем как получить исходное значение, можно написать шаблон для типа:

struct VLQ < local char size = 1; while(true) < byte obf_byte; if ((obf_byte & 0x80) == 0x80) < size++; >else < break; >> FSeek(FTell() - size); byte bytes[size]; local uint64 _ = FromVLQ(bytes, size); >; 

И функцию преобразования массива байтов в целочисленное значение:

uint64 FromVLQ(byte bytes[], char size) < local uint64 source = 0; local int i = 0; local byte x; for (i = 0; i < size; i++) < x = bytes[i]; source |= (x & 0x7F) * Pow(2, i * 7); // Бинарный сдвиг > return source; >; 

Но вернемся к созданию предмета. Опять появляется D и снова 0x08 перед меняющимся значением. Последние два байта сообщения 0x10 0x01 подозрительно похожи на количество предметов крафта, где 0x10 имеет роль, схожую с 0x08 , но по-прежнему непонятную. Зато теперь можно написать шаблон для этого события:

struct CraftEvent < uint data_length ; byte marker1; VLQ craft_id ; byte marker2; VLQ quantity ; >; 

Который будет выглядеть вот так:

И все равно это были простые примеры. Посложнее будет разобрать событие движения персонажа. Какую информацию мы ожидаем увидеть? Как минимум координаты персонажа, куда он смотрит, скорость движения и состояние (стоит, бежит, прыгает и т.д.). Так как строк в сообщении не видно, состояние, скорее всего, описывается через enum . Путем перебора вариантов, попутно сравнивая их с данными из файлов игры, а также через множество тестов, можно найти три XYZ вектора при помощи вот такого громоздкого шаблона:

struct MoveEvent < uint data_length ; byte marker; VLQ move_time ; FSkip(2); byte marker; float position_x ; byte marker; float position_y ; byte marker; float position_z ; FSkip(2); byte marker; float direction_x ; byte marker; float direction_y ; byte marker; float direction_z ; FSkip(2); byte marker; float speed_x ; byte marker; float speed_y ; byte marker; float speed_z ; byte marker; VLQ character_state ; >; 

Зеленая тройка оказалась координатами местоположения, желтые тройки, скорее всего, показывают куда смотрит персонаж и вектор его скорости, а последнее одиночное — состояние персонажа. Можно заметить постоянные байты (маркеры) между значениями координат ( 0x0D перед значением X , 0x015 перед Y и 0x1D перед Z ) и перед состоянием ( 0x30 ), которые подозрительно похожи по смыслу на 0x08 и 0x10 . Проанализировав много маркеров из других событий оказалось, что он определяет тип следующего за ним значения (первыми тремя битами) и семантическмй смысл, т.е. в примере выше если поменять местами вектора, сохранив при этом их маркеры ( 0x120F перед координатами и т.д.), игра (теоретически) должна нормально распарсить сообщение. С учетом этой информации, можно добавить пару новых типов:

struct Packed < VLQ marker ; // Маркер тоже оказался VLQ! local uint size = marker.size; // Некоторые сообщения не содержат значения смещения (в списках, например) и там приходится использовать вот такой вычисленный размер структуры switch (marker._ & 0x7) < case 1: double v; size += 8; break; // Из анализа других событий case 5: float v; size += 4; break; default: VLQ v; size += v.size; break; >>; struct PackedVector3 < Packed marker ; Packed x ; Packed y ; Packed z ; >; 

Теперь наш шаблон сообщения движения значительно сократился:

struct MoveEvent < uint data_length ; Packed move_time ; PackedVector3 position ; PackedVector3 direction ; PackedVector3 speed ; Packed state ; >; 

Еще один тип, который может нам понадобиться в следующей статье, это строки, которым предшествует Packed -значение их размера:

struct PackedString < Packed length; char str[length.v._]; >; 

Теперь, зная примерный формат сообщений, можно написать свое прослушивающее приложение для удобства фильтрации и анализа сообщений, но это уже тема для следующей статьи.

Upd: спасибо aml за подсказку, что описанная выше структура сообщений является Protocol Buffer, а также Tatikoma за ссылку на полезную соответствующую статью.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *