ДЕШИФРУЕМ ТРАФИК

[VORON]

собственно ситуация стандартная куча ботов было на серваке.. и админы сменили шифрацию на серваке.. теперь пакетхак неможет корректно распознать пакеты..
в етой теме мы будем на моем многострадальном примере учиться как сломать защиту.. очень расчитываю на помощ людей которые сталкивались с подобной задачей..
для решения нам нужно знать то что для входящщего и исходящего трафика применяются разные алгоритмы шифрации (но невсегда) в базовой шифрации ети алгоритмы совпадают.. ДЛЛ исходники для которой дал ХКОР- сделана так что применяет 1 и тотжэ алгоритм для дешифрации трафика в обоих направлениях поетому ковыряние в ней ниче не даст нам нужно для каждого направления свой алгоритм применить...
я планирую ето сделать с помощью скриптов.. 1 скрипт помещу вверху списка - его задача будет ДЕШИФРИРОВАТЬ переменную PCK разными методами в зависимости от того пакет ИСХОДЯЩИЙ ИЛИ ВХОДЯЩИЙ.. а второй скрипт помещу в конце списка- и он будет зашифровывать ету переменную..
посредине списка скрипты будут работать с расшифрованными данными...

ну собственно я не надеюсь на очень быстрое решение задачи просто в етой теме будет обмен опытом.. те кто сталкивался с похожим..
начал я с того что ХКОРА замучал вопросами тупыми-) че да как -)) с чего начать.. ну начали с мониторинга... пакетов..
для шифрации обычно применяют КСОРИНГ на ключ.. КСОРИНГ хорош тем что он не изменяет длинну данных.. и данные зашифрованные с его помощью могут быть обратно распаковыны к начальному виду.. а вот ключ- админы любят менять.. причем в моем случае- очень извращенными способами.. при мониторинге исходящего трафика и отправке подряд 3-х одинаковых однобайтовых пакетов на разрыв пати (2B) я обнаружил что пакетхак перехватывает 88 8F 8E.. т.е. каждый раз новое...
но приетом часто по порядку.. ксоринг того что перехватил пакетхак на 2b дает нам последовательность a3 a4 a5 и т.д. т.е. последовательность каждый член которой отличается друг от друга на 1.. ХКОР посоветовал предположить что ключ инкрементируется (увеличивается) на длинну пакета каждый раз при отправке нового пакета... ну собствено проблема в том что я продолжил мониторить етот пакет на разрыв пати и обнаружил что порой ключ уменьшается-((( ето меня в тупичек поставил... раз 20-30 пакетов подряд ключ на 1 увеличивается а потом бац и срывается последовательность и ключ на 2 меньше становится...
если у ковото есть идеи- поделитесь...

[ASSA]

Посмотрите плиз кто знает
http://coderx.ru/showthread.php?t=267

[VORON]

предлагаю изменить способ общения.. набор цифр лога мало инфы в себе несет...
по возможности- нужен лог без дешифровки+ дешифровка к нему + жэлательно каждому пакету ключ указывать..
т.е. табличка из 3-х колонок.. в первом столбце- пакет отловленый во втром дешифровка к нему, в третьем- ключ для того чтобы из первого столбца получить второй..
из етих данных нужно думать как ключ меняется от пакета к покету..

[Polymorph]

Тогда вдогонку своему посту выше - архив:
http://slil.ru/25737435
В нём лог ПХ без дешираации и без обхода смены ксор ключа + xls документ с таблицей как предложил VORON

Заметка: Если отловить ПХ пакет на селф баф (вампирик например), и потом без изменений послать такой же - сервер его скушает и выполнит баф. Но если после клон-пакета попытатся в игре куда нибуть побежать: чар бежит в самые разные стороны. т.е. сервер продолжает дешифровать, думая что предидущий пакет (клон-пакет) был зашифрован правильно. И как следствие - если хотя бы 1 пакет будет зашифрован не верно, все остальные от клиента будут для сервера хоть и верными, но нести не правильную инфу. В итоге если ПХ клезет хоть одним пакетом, то всё общение клиент-сервер будет не верным, в итоге, клиент должен сдисконнектнутся. И вылетит ПХ. Омг, чёж делать то.

[ASSA]

Перед вводом новой защиты был апдейт, и длл-ки заменили.
Я вообще понимаю что дешифрование/шифрование идет в длл.
Но я не хотел бы заморачиваться и там копаться, хотя можно было бы если с кем то на пару хотябы. Я вообще хотел использовать дешифратор на делфи или на л2пх, так как известно что при входе на ГС я получаю криптини с ключем, потом этот ключ используется для шифрации входящего трафа и меняется на длинну пакета(вроде или типа чето в етом духе) и исходящего с таким же изменением. то есть у нас уже 2 ключа, но для разных трафов. Поэтому нада дергать ключ на стадии логина и включать скрипт, чтоб он иммитировал изменения ключа(и серв них не просек). Вот чтоб я сделал еслиб был супер програмером=)))

Поправьте если вы знаете больше=)

[nezabudkin]

Уважаемый xkor, прошу у тебя помощи!
Недавно, на моем самом любимом игровом серве сделали обновление до С6 и поставили шифрование трафика. Сервер, видимо, в основе своей остался PTS С4, но с самописными добавками. Причем за последние 2 недели, админы дважды меняли алгоритм шифрования!!! Сначало вообще пакетхак все нормально дешифровывал. После первого обновления защиты пакетхак стал частично дешифровывать входящий трафик, и полную чепуху писать в исходящем. Но что интересно, метод дешифрации трафика от клиента совпал с Вороновским, его скриптик, выложенный в этом топике помог дешифровывать трафик от клиента, причем даже менять ничего в скрипте не понадобилось!!! Но после второго обновления защиты все стало гораздо хуже. Пакетхак может работать только в срытом режиме!!!, иначе клиент вываливается с критом, все ботопроги других производителей вообще перестали работать, соответственно ботов на сервере я тоже не вижу, это конечно приятно). Так вот, за последний месяц я перерыл кучу инфы по шифрованию гейм-сервера линейки, вдоль и поперек перечитал этот топик. И понял, что у меня на серве ,в общем то, используется алгоритм xor-шифрования взятый от C4, и немного подправленный. Теперь Вороновский вариант дешифрации мне не подходит, а вот алгоритм залошенный в newxor.dll очень даже годится! Во всяком случае, я почти расшифровал трафик от сервера! Трафиком от клиента еще пока не занимался, но с виду там используется такой же метод шифрования что и от сервера.

Так вот, что хочу узнать то, я занялся правкой newxor.dll, с делфи я хорошо дружу. Но в чужом коде тяжело разбираться... xkor, не мог бы ты прокоментировать, в какой последовательности в этой библиотеке вызываются функции, какие параметры им передаются, описать схему хранения данных (какие переменные за что отвечают).

Если у меня получится дешифровать трафик, то я выложу в этом топике мой вариант исходников для newxor.dll, возможно это многим поможет...

[PanAm]

Byrger
В нормальном КриптИни по идее первые два байта 00 01, у тебя в первом случае так и есть, а во втором пакете 00 A5, или тут пакет уже зашифрован - а значит ты умолчал, что был еще 1 пакет перед ним, или хз )))

[Byrger]

Дело в том, что на сервере идёт доп шифрование, пакеты от клиента к серверу зашифрованы ХОРом, а от сервера ХОРом и поверх доп шифрование....Хмм... на шифровка начинается после Крупт инит...
Может ты не прав? иногда он даж на 00 BB начинается...

А так по теме: почему Пакет хак не смог расшифровать?

[alexsl]

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

var
  i,k,j: integer;
begin
  i:=size;
  for j:=0 to i div 8 do
  begin
      for k:=7 downto 0 do
      begin
            pck[k+(j*8)]:=pck[k+(j*8)] xor key[k];
// вот тут на серве дополнительное шифрование
      if j>=8 then
            pck[k+(j*8)]:=pck[k+(j*8)] xor key[k] xor key[k];
      end;
  end;
end.

но вот в отправке пакетов от клиента, немогу въехать как меняются первые 2 байта ключа.

юзал сидя скилл релакс в разные промежутки времени
обход смены хор ключа - вкл
не дешифровать трафик - выкл

46 44 07 00 E4 5F DC 5E 69 A6
B6 44 07 00 E4 5F DC 5E 99 A6
84 44 07 00 E4 5F DC 5E AB A6
B8 44 07 00 E4 5F DC 5E 97 A6 
D4 44 07 00 E4 5F DC 5E FB A6
C0 44 07 00 E4 5F DC 5E EF A6
C4 47 07 00 E4 5F DC 5E EB A5
D8 47 07 00 E4 5F DC 5E F7 A5
B4 47 07 00 E4 5F DC 5E 9B A5
80 47 07 00 E4 5F DC 5E AF A5
B6 47 07 00 E4 5F DC 5E 99 A5
46 48 07 00 E4 5F DC 5E 69 AA
98 49 07 00 E4 5F DC 5E B7 AB
37 4C 07 00 E4 5F DC 5E 18 AE
27 4C 07 00 E4 5F DC 5E 08 AE
57 4C 07 00 E4 5F DC 5E 78 AE 
37 4C 07 00 E4 5F DC 5E 18 AE

после прогонки через:

var
  k,j: integer;
begin
  key[0]:=pck[8];
  key[1]:=pck[9];
  key[2]:=pck[2];
  key[3]:=pck[3];
  key[4]:=pck[4];
  key[5]:=pck[5];
  key[6]:=pck[6];
  key[7]:=pck[7];

  for j:=0 to size div 8 do
  begin
      for k:=7 downto 0 do
      begin
            pck[k+(j*8)]:=pck[k+(j*8)] xor key[k];
// этот кусок наверно не нужен. еще не проверял. но и так работает
      if j>=8 then
            pck[k+(j*8)]:=pck[k+(j*8)] xor key[k] xor key[k];
      end;
  end;
end.

получаем:

2F E2 00 00 00 00 00 00 00 00 ; 69 A6 07 00 E4 5F DC 5E ; 10
2F E2 00 00 00 00 00 00 00 00 ; 99 A6 07 00 E4 5F DC 5E ; 10
2F E2 00 00 00 00 00 00 00 00 ; AB A6 07 00 E4 5F DC 5E ; 10
2F E2 00 00 00 00 00 00 00 00 ; 97 A6 07 00 E4 5F DC 5E ; 10
2F E2 00 00 00 00 00 00 00 00 ; FB A6 07 00 E4 5F DC 5E ; 10
2F E2 00 00 00 00 00 00 00 00 ; EF A6 07 00 E4 5F DC 5E ; 10
2F E2 00 00 00 00 00 00 00 00 ; EB A5 07 00 E4 5F DC 5E ; 10
2F E2 00 00 00 00 00 00 00 00 ; F7 A5 07 00 E4 5F DC 5E ; 10
2F E2 00 00 00 00 00 00 00 00 ; 9B A5 07 00 E4 5F DC 5E ; 10
2F E2 00 00 00 00 00 00 00 00 ; AF A5 07 00 E4 5F DC 5E ; 10
2F E2 00 00 00 00 00 00 00 00 ; 99 A5 07 00 E4 5F DC 5E ; 10
2F E2 00 00 00 00 00 00 00 00 ; 69 AA 07 00 E4 5F DC 5E ; 10
2F E2 00 00 00 00 00 00 00 00 ; B7 AB 07 00 E4 5F DC 5E ; 10
2F E2 00 00 00 00 00 00 00 00 ; 18 AE 07 00 E4 5F DC 5E ; 10
2F E2 00 00 00 00 00 00 00 00 ; 08 AE 07 00 E4 5F DC 5E ; 10
2F E2 00 00 00 00 00 00 00 00 ; 78 AE 07 00 E4 5F DC 5E ; 10
2F E2 00 00 00 00 00 00 00 00 ; 18 AE 07 00 E4 5F DC 5E ; 10

с 3 по 8 байты ключа вроде бы константы.

может какие нибудь идейки есть? в какую сторону копать?

ко времени может быть привязка? хотя как сервер может знать об времени отправления пакета, или в заголовке пакета есть время отправки?

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

Добавлено через 12 часов 57 минут
гыг, наступаю на одни и тежи грабли.
вот тежи пакеты (сидя юзаю релакс) в незашифрованном виде (сохранил из пх в текстовый файл. вроде как сохраняет не в шифрованном виде, убрав вкрапления)

039C54BE5329F5E03F030025
03460CC50974F5E03F030025
032EC146588FF5E03F030025
03F0C3CBBFBEF5E03F030025
035C8837A7E1F5E03F030025
03111547E4F6F5E03F030025
03057703060EF6E03F030025
0396FC62C92FF6E03F030025
03E510C02F6AF6E03F030025
03FD42672293F6E03F030025
033FD25769A0F6E03F030025
032A322625B4F6E03F030025
032696D0ACCEF6E03F030025
036BDF0456E7F6E03F030025
03308DD62A0FF7E03F030025
0346053ABB2CF7E03F030025
03B2C9A5A24FF7E03F030025
034A97AF6969F7E03F030025
03269FF6E488F7E03F030025
035F3BF0BAA5F7E03F030025
03101DB38AC2F7E03F030025
03D5CA845FEAF7E03F030025
0364A597B513F8E03F030025
0340ADDE3033F8E03F030025
03C1117C5C42F8E03F030025
032871577461F8E03F030025
03EE0F325476F8E03F030025
030F35D0B78FF8E03F030025
03BBCEE883B4F8E03F030025
03EE05528ACDF8E03F030025
034E1D839EF4F8E03F030025

вроде идеальные данные для расшифровки.
вот дальше возникает куча вопросов, допустим взял ключик который приходит от серва CryptInit F0 E8 B3 BF им декодирую потом с получившимся пакетом произвожу танцы с бубном? или сразу надо плясать?
т.е. с какого бока подступится?

[Grinch]

alexsl, зачем такая конспирация, что за сервер?