Jump to content
Korean Random

NonNamed

User
  • Content Count

    6
  • Joined

  • Last visited

Community Reputation

0 Noob

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Приходите, расскажу. Если коротко - последовательный план на полное воспроизведение серверной составляющей танков и его реализация в коде.
  2. У нас исходы на Java, и последний протокол 1.1+ (по состоянию на конец сентября). Соглашусь. Лишний раз драконить ВГ не стоит, иначе они начнут вставлять палки в колёса таким разработкам. Запилив бОльшую часть функционала уже можно себе позволить бороться с той завесой защит от ботов/снифферов/эмуляторов которой могут обвешать клиент если эта сфера продвинется вперёд
  3. Нет, я не автор. Пока из продукта нет чего-то завершенного, разные неформатные пр начинают шатать его в разные стороны пытаясь решать свои местечковые проблемы, не заглядывая дальше своего носа. Чем отнимают очень много времени. Для тех кто хотел бы помочь личка открыта, выставлять наружу Proof of Concept без какой-либо готовой базы я считаю нецелесообразным.
  4. Опенсорснуть - может означать что набегут людишки и накоммитят много не качественного кода. Или нафоркают и раздербанят на свои эмуляторы. Могу приоткрыть доступ заинтересованным к своим репозиториям в гитхабе, при условии, что не будет открытых форков в паблик до тех пор, пока не соберется что-то более менее играбельное. Пишите в личку, постепенно буду разгребать почту.
  5. На самом деле на 1.1 работает и без отправки его с сервера, это больше похоже на тот счетчик, который раньше был вместо SEQUENCE_NUMBER в случае ненадежной доставки. Не понятно зачем они его разделили. В версиях до 0.8 он увеличивался бесконечно, причем если запустить одновременно несколько клиентов и снять с них трафик - можно понять что это действительно глобальный счетчик сетевой подсистемы. Мы также не обновляем сниффер, версии пожалуй с 0.8. Сперва сканируется память, находится сигнатура методов шифрования/дешифрования, и уже на найденные адреса памяти вешается отладчик, который снимает данные. В любом случае, я не говорю что mitm это плохо. Но он не всегда правильную картину покажет того, как клиент обработал данные (но точно такую, как он их принял к обработке). А switchBaseApp (switchInterface если быть точнее), вы можете отфильтровать, либо заменить unreliable заглушкой чтоб в sequence не было дырки. На самом деле не 255, а примерно 60 он укладывает в один байт. Дальше клиент нарезает messageId и во второй байт укладывает то, что за пределами маски 0xFFC0
  6. В 1.0 в протоколе добавился флаг 0x0010 (если оперировать BE порядком, 0x1000 для LE) и соотвествующий footer для него. Не видел, чтоб сервер его использовал, присланный клиентом можно просто откусить из сообщения. Выкусывать нужно перед обработкой footer'а HAS_SEQUENCE_NUMBER, т.е. на примере ненадежного пакета: если флаг синий, то откусываем красный: 0x4814 20000000 BC000000 BA000000 00000000 00 EFBEADDE 06 Вы у себя делали поддержку PIGGYBACKS и ACK's или в своем эмуляторе тоже полагаетесь на то, что пакеты не будут пропадать? После обновления протокола на 1.0 у нас отвалились только некоторые из RPC методов: вызов showGUI для Account стал оперировать большим количеством данных, хотя в скрипте их осталось столько же (сейчас уже не уверен). Пока захардкодили этот кусок, живём так. От версии к версии 1.0 -> 1.1 этот кусок не поменялся. В остальном значительных изменений протокола обновление не принесло. Если есть проблемы с обновлением сетевой составляющей - спрашивайте, мы тоже делаем эмулятор для танков и поели 💩 с нелогичностью протокола. Перехват трафика через MITM - интересное решение, спасибо. Мы в свое время написали и используем для этого сниффер, который ищет определенные точки в клиенте вытаскивая данные прямо из памяти.
×
×
  • Create New...