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

VORON · 24.12.2007, 00:02

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

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

stirena · 24.12.2007, 02:36

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

VORON · 24.12.2007, 14:53

Цитата:

Сообщение от stirena

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

написал скрипт для удобного мониторинга пакетов и ксоров.. он выводит на МЕМО на форму пакет перехваченый и ксор к нему.. так вот при отправке 10 подряд пакетов (2B) - на разрыв пати состоящий из 1-го байта в мемо записывается ЛОГ:

Код:

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

Код:

43 -220-247
43 -221-246
43 -210-249
43 -211-248
43 -208-251
43 -209-250
43 -214-253
43 -215-252
43 -212-255
43 -213-254
43 -202-225

вот собственно и всё..
код в скрипте который создаёт лог выглядит так:

Код:

 if FromClient then
 begin
 D:=ord(PCK[1]);
 x:= d XOR 43;
 frm.caption:=inttostr(d)+'-'+inttostr(x);
 memo.Lines.Add('43 -' + inttostr(D) + '-' + inttostr(x));
 end;

если теья интерисуют именно 10 первых пакетов при входе в игровой мир.. то они такие:

Код:

Ис   BD 9E 00 00 49 BA 54 87 B0 9E 00 00 49 BA 54 87 B0 9E 00

Вх   F8 02 01 

Вх   15 56 00 4F 73 1B 54 C8 00 4E 00 37 73 49 54 1E 46 00 00 00 73 83 6D 87 00 A5 01 00 73 49 54 87 00 00 00 00 73 4B 54 87 00 25 00 00 73 48 54 87 00 1D CF FE 8C 0C 4D 86 00 60 F2 FF 8C C6 96 72 28 5C 57 9C 33 91 F7 F7 3D 0A 97 8F 33 CA C8 29 00 27 D3 22 7B 49 54 87 00 3C 00 00 73 49 54 87 00 01 00 00 73 60 54 87 00 22 00 00 73 69 54 87 00 19 00 00 73 45 54 87 00 1A 00 00 73 49 54 87 00 00 00 00 73 49 54 87 00 00 00 00 73 49 54 87 00 00 00 00 73 49 54 87 00 00 00 00 73 49 54 87 00 00 00 00 73 49 54 87 00 00 00 00 73 49 54 87 00 00 00 00 73 49 54 87 00 00 00 00 73 49 54 87 00 00 00 00 73 49 54 87 00 00 00 00 73 49 54 87 00 00 00 00 73 49 54 87 00 00 00 00 73 49 54 87 00 00 00 00 73 49 54 87 00 00 00 00 73 49 54 87 00 00 00 00 73 49 54 87 00 00 00 00 73 3F 51 87 00 00 00 00 73 6C 54 87 00 00 00 00 73 49 54 87 00 00 00 00 73 49 54 87 00 

Ис   8D 85 00 

Вх   FE 1B 00 09 67 35 54 86 00 00 00 67 67 59 54 F2 00 64 00 69 67 5A 54 87 00 02 00 00 67 51 54 EE 00 6F 00 6E 67 35 54 84 00 00 00 67 67 5C 54 F5 00 61 00 6E 67 35 54 83 00 00 00 6F 67 47 54 E2 00 6E 00 00 67 30 54 87 00 61 00 64 67 50 54 E9 00 00 00 06 67 35 54 EE 00 6E 00 6E 67 54 54 E3 00 72 00 69 67 59 54 E2 00 00 00 07 67 35 54 E0 00 6F 00 64 67 54 54 F5 00 64 00 00 67 3D 54 87 00 72 00 75 67 5B 54 E2 00 00 00 09 67 35 54 F4 00 63 00 68 67 40 54 F3 00 74 00 00 67

Ис   55 86 00 00 41 A9 54 87 56 86 00 00 41 A9 54 87 56 4F BC F2 E6 CF 0E 8C CE B0 A5 BD C8 44 2B 63 81 ED 49 E2 DE 46 22 6C 98 25 FA F4 FE A5 30 24 E2 22 CE DC 87 A1 6A E9 BC C3 CA D3 BF 21 47 00 EE 80 2C 96 B1 32 4A 09 EA 40 9B 98 89 CA 42 48 86 A5 48 00 41 A9 54 87 56 86 00 00 41 A9 54 87 56 86 00 00 41 A9 54 87 56 

Вх  7F 00 00

Вх  64 6C 04 00 62 34 54 87 00 04 00 00 62 13 55 87 00 01 00 00 62 

Вх  E4 00 04 F6 AB 4D 54 84 00 00 00 02 AB 49 54 02 00 00 00 01 AB 49 54 0D 00 00 00 01 AB 49 54

при входе в игровой мир я нахожусь в отдаленном месте где нет не мобов не живых чаров.. поетому лишнего вроде не должно быть нечего... еще хачу заметить что галочка НЕ ДЕШЕФРИРОВАТЬ ТРАФИК- отключена и стоит галочка ОБХОД СМЕНЫ КСОР КЛЮЧА.. галочка НЕ ДЕШЕФРИРОВАТЬ ТРАФИК- помагает в том что во входящем трафике пакеты на половину верно расшифровываются.. первые 4 байта- корректно а следующие 4 байта- нет... и т.д. по пакету 4 верно а 4 нет...

stirena · 24.12.2007, 19:52

Какието неправильные пакеты.
должно бытьхотябы так

Код:

1. ProtocolVersion,
2. CryptInit
3. AuthLogin
4. CharList
5. CharacterSelected
6. RequestQuestList и RequestExManorList
7. ExSendManorList
8. QuestList
9. EnterWorld
10. UserInfo

VORON · 25.12.2007, 01:38

интересная вещь получается.. при отправке серверу пакета на разрыв пати "2B" сервер дает ответ что невозможно выйти из пати в дешиврованном виде "3B 00 00 00 00" на на моем сервере вместо етого приходит "3B 00 00 00 XX", хх- всегда разное и меняется по непонятным мне законам... если применяется ксоринг- то ксор чего угодно на 00 - должен дать само себя.. т.е. то что мы видим вместо хх в логе ето и есть 5-й байт ключа.. самый младший байт в изменяющейся части ключа 8-ми байтного.. но закон его изменения мне непонятен вапще.. вместо хх в 4-х принятых подряд пакетах- на разрыв пати (A6 25 AD 20) ну а первые 4 байта дешифрируются корректно (3B 00 00 00).. возможно ли что то еще кроме ксоринга? кто с чем сталкивался?

Добавлено спустя 1 час 10 минут 35 секунд:
продолжаю исследовать.. и обнаружил еще кое что интересное.. взял пакет ЮЗЕР ИНФО весьма длинный.. в начале там где моё имя указывается а потом характеристики.. как я уже сказал мой сервак шифрует ходящий трафик пакет не полностью а лиш половину.. весь пакет делится на орезки по 8 байт начиная с 1-го.. первые 4 байта в каждом отрезке- не закодированы и пакетхак их видит в расшифрованном виде как и должно быть.. а вот 4 следующие закодированы.. так вот в пакете ЮЗЕР ИНФО очень много нулей используется и есть места где по 12-16 нулей подряд идут.. я выбрал место там где в оригинале долны быть нули но в закодированом виде байты какието и предположил что ето и есть ключ для КСОИНГА.. так 0 отксореный на ключ= самому ключу.. и попробывал с помощью етого ключа расшифровать свое имя в етом жэ пакете.. просто отксорил побайтово закодированые байты в имени на байты из ключа.. И У МЕНЯ ПОЛУЧИЛОСЬ РАСШИФРОВАТЬ ИМЯ СВОЁ-).. т.е. теперь я знаю точно что применяется обычный КСОРИНГ для шифрации.. тока закон изменения ключа для меня остался загадкой..
но теперь чтоб немучится и не вычислять КСОР для каждого пакета который я мониторю я нашел хороший входящий паетик выдающий сообщение "ВЫ НЕМОЖЕТЕ ИСПОЛЬЗОВАТЬ ЕТО СИДЯ" который приходит каждый раз когда сидя на попе скил любой юзаеш в оригинале он выглядет так: "64 1F 00 00 00 00 00 00 00" .. но как вы уже сами догадываетесь пакетхак у меня его видит типа так "64 1F 00 00 XX XX XX XX 00" само собой ХХ ХХ ХХ ХХ - ето и есть ключ для ксоринга.. осталось выяснить по каким законом меняется от пакета к пакету етот ключ.. ето для меня покачто загадка.. наблюдения показывают что от пакета к пакету изменяются 1 байт- часто 2-й реже а 3 очень очень редко (через долгий промежуток времени) и 4 ваще почти никогда (ненаблюдал).. т.е. складывается впечатление что ето 4 разряда 4-х байтного числа которое от пакета к пакету немного изменяется.. но по какому закону?

Добавлено спустя 44 минуты 31 секунду:
может кто то захочет голову поломать.. приведу лог пакетхака для осмысления.. который получается если в тихом безлюдном месте без мобов сидя на попе 3 раза заюзать скил с ИД "63 00 00 00" при етом в фильтрах все галочки включены в логе никаких пакетов не пропущено..

отправляю запрос на использования скила:
A9 20 01 00 48 9A 55 87 86 43 расшифрованный вид:"2F 63 00 00 00 00 00 00 00 00"

получаю ШОУ МЕССАДЖ
64 1F 00 00 E5 10 54 87 00 расшифрованный вид:"64 1F 00 00 00 00 00 00 00"

получаю ЭКШН ФЕЙЛД
25 расшифрованный вид:"25"

отправляю запрос на использования скила:
BC 4D 01 00 13 C4 54 87 93 2E расшифрованный вид:"2F 63 00 00 00 00 00 00 00 00"

получаю ШОУ МЕССАДЖ
64 1F 00 00 E6 10 54 87 00 расшифрованный вид:"64 1F 00 00 00 00 00 00 00"

получаю ЭКШН ФЕЙЛД
25 расшифрованный вид:"25"

отправляю запрос на использования скила:
C5 20 01 00 2B F7 55 87 EA 43 расшифрованный вид:"2F 63 00 00 00 00 00 00 00 00"

получаю ШОУ МЕССАДЖ
64 1F 00 00 E1 10 54 87 00 расшифрованный вид:"64 1F 00 00 00 00 00 00 00"

получаю ЭКШН ФЕЙЛД
25 расшифрованный вид:"25"

Добавлено спустя 1 час 2 минуты 2 секунды:
тут во входящем трафике- сразу ключ выделен (4 байта вместо нулей).. а в исходящем ключ выделить не проблема тоже вот например:
отправляю запрос на использования скила:
C5 20 01 00 2B F7 55 87 EA 43 расшифрованный вид:"2F 63 00 00 00 00 00 00 00 00"

EA 43 - ето первые 2 байта ключа.. проверяем: EA xor C5 = 2F, 43 xor 20= 63 что соттветстыует тому что и нужно получить..
3 4 5 6 7 8 байты ключа ето 01 00 2B F7 55 87

dmitry501 · 25.12.2007, 07:35

Сервер то какой? :)

QaK · 25.12.2007, 11:44

Цитата:

Сообщение от VORON

отправляю запрос на использования скила:

Скилл рапид шот? 2Voron выложи побольше пакетов не 3 ттройки а штук 10-15, а то из 3х мало что сделаешь...
Плияяяя!ППЦ работать не могу =) интересно стало ... щас тупо сижу и думаю как же может ключь меняться ааааааааа :O:

VORON · 25.12.2007, 23:56

QAK да рапидшот.. ДИМКА сервер тока в пм (отпраавил) по понятным причинам тебе..

седня пока работал- думал.. стораясь думать головой-) надумал вот что.. новое значение ключа недолжно зависеть от своего предыдущего значения-((( или наоброт- "-)))" в доказательство приведу такой пример.. предположим ПАКЕТХАК отправит от имени сервера клиенту пакет какойто с использованием ключа, значение для которого он сам расчитает в зависимости от предыдущего значения ключа.. чтож- при етом клиент у себя в мозгах вычеслит новое значение ключа для будущего пакета от сервера.. но так как сервер про етот пакет (отправленный ПАКЕТХАКОМ клиенту) и знать не знал то сервер не станет расчитывать новый ключ.. и при следущей отправки любого пакета от сервера к клиенту- произойдет ошибка! так как сервак закодирует одним ключем а КЛИЕНТ будет распаковывать- другим ключем.. из етого вывод что для расчета нового значения ключа нам ненужно опираться на его прежнее значение... А НА ЧТО ЖЕ НАМ ТОГДА ОПИРАТЬСЯ??? ведь от чегото он всётаки меняется каждый раз...! помагите плиз!
из идей тока повнимательней всмотреться в заголовок пакета- который каждый раз разный и обрубается пакетхаком для удобства визуализации.. с учетом того что длинна пакет к примеру- "2b" (разрыв пати) - константа, предположив что ключ както от нее зависит- мы для одинакового пакета 2b должны получать одинаковый зашифрованный вид.. а вот например ЧЕКСАМ с учетом заголовка- будет всегда разный.. так как заголовок- меняется.. возможно там надо разгадку искать.. но либо в езменяющейся части заголовка какието подсказки есть.. вапще я кудато глубоко копать стал- но к этому приводят тока логические выводы опровергнуть которые- сам немагу..
щас запущу ПАКЕТХАК и отловлю ЛОГ новый из 15-20 пакетов и выложу... лог будет очень удобным надеюсь для осмысления..

Добавлено спустя 48 минут 2 секунды:
ТРИНДЕЦ НАРОД! админы чета грандиозное нахемичили! мои самые страшные прогнозы- сбылись..! КЛЮЧ ЗАВИСИТ ОТ СВОЕГО ПРЕДЫДУЩЕГО ЗНАЧЕНИЯ! И КАЖДЫЙ РАЗ МЕНЯЕТСЯ! и СЕРВЕР И КЛИЕНТ ДОЛЖНЫ ЕГО ИМЕТЬ и КАЖДЫЙ РАЗ ДЛЯ НОВОГО ПАКЕТА- ВЫСЧИТЫВАТЬ ЗАНОГО! я попытался внедриться ПАКЕТХАКОМ в трафик.. отправил клиенту безобидный пакет "25" - "ЕКШН ФЕЙЛД" в надежде подтвердить то что ето не приведет к ошибке.. так как я думал что ключ не зависит от своего предыдущего значения.. и получил что после етого пакета к клиенту- всё летит к чертям.. сообщения в чат через ЕРОГЛИФЫ начинают писаться.. и т.д. через пакетов 2-3-4-5 КЛИЕНТ вапще зависает и вылетает с критом.. из чего вывод: КЛЮЧ ЗАВИСИТ ОТ СВОЕГО ПРЕДЫДУЩЕГО ЗНАЧЕНИЯ!! всвязи с чем вопрос-- даже если я пойму логику его изменения то как я скриптом в трафик внедрюсь?? любой пакет от скрипта- рассинхронизирует клиент с сервером... ВО ЖЭСТЬ ТО! ето ведь придется фалшивый ключ ключ клиенту подсовывать а серверу фальшивый от клиента.. на несколько состояний назад.. т.е. если скрипт отправит хотябы 1 пакет камуто то он должен будет весь трафик последующий перекодировать с использованием ключаот предыдущего состоянния.. причем когда скрипт порядочно поработает откат состояния ключа достигнит ГРАНДИОЗНЫХ ЗНАЧЕНИЙ!..
а выход в чём??? че делать то ребята!

Добавлено спустя 2 часа 14 минут 29 секунд:
собственно ХКОР меня немного успакоил.. говорит что рассинхронизация ключа- ето в порядке вещей. и нужно просто перешифровывать все пакеты при прохождении через пакетхак (в нашем случаее ето будет скрипт) для того чтобы синхронизация ключа не нарушалась.. прийдется хранить 2 ключа для клиента (вход и выход) и 2 ключа для сервера (вход и выход) независимо друг для друга и перешифровывать все пакеты при прохождении через скрипт.. такчто продолжаем искать закон изменения ключа..
вот лог:
8E2C00001C5A5487A14F
FB41000011475487D422
A22C00007F3754878D4F
CF410000722A5487E022
B62C00001C5A5487994F
23400000114754870C23
4A2D00007F375487654E
37400000722A54871823
5E2D00001C5A5487714E
0B400000114754872423
722D00007F3754875D4E

такой лог получаю зажав сидя на попе долго кнопку ЮЗ СКИЛ.. за долю секунды от клиента к серверу улетают ети пакеты и межды ними нет ничего.. тока после них сервер начинает говорить что нельзя юзать скил... с задержкой..
как я уже сказал в оригинале етот пакет должен выглядеть так: "2F 63 00 00 00 00 00 00 00 00", выделить ключ отсюда не проблема.. мы видим что у ключа 3 4 байты не меняются (00 00), и 7 8 тоже не меняются (54 87), 2 байт меняется лениво както (4F,22,23,4E) повторов много.., 6-й байт закономерно циклом (5A,47,37,2A).. 5-й байт вместе с 6-м циклит.. но маловато 1 фиг данных закон изменения непонятен мне пока.. щас выйду из игры и зайду снова и получу новый лог аналогичный етому.. чтоб проверить цикличность..
ВОТ лог еще 1 с вкраплениями пакетов от сервера (ШОУ МЕСЕДЖ и ЕКШН ФЕЙЛД) как мы видим ети вкрапления не нарушают цикличности вапще никак.. а значит входящий и исходящий трафики не влияют на ключ друг друга..

379100003EE3548718F2
5EFC0000203F5487719F
25 (экшн фейлд) входящий
2B9100005D8E548704F2
B2FC0000435254879D9F
DF9100003EE35487F0F2
A6FC0000203F5487899F
F39100005D8E5487DCF2
9AFC000043525487B59F
E79100003EE35487C8F2
8EFC0000203F5487A19F
9B9100005D8E5487B4F2
E2FC000043525487CD9F
8F9100003EE35487A0F2
641F00006B67548700 (шоу месадж) входящий
D6FC0000203F5487F99F
A39100005D8E54878CF2
25 (экшн фейлд) входящий
CAFC000043525487E59F
579000003EE3548778F3
3EFD0000203F5487119E
4B9000005D8E548764F3
12FD0000435254873D9E
7F9000003EE3548750F3
06FD0000203F5487299E
139000005D8E54873CF3
7AFD000043525487559E
079000003EE3548728F3
641F00006A67548700 (шоу месадж) входящий
6EFD0000203F5487419E
3B9000005D8E548714F3
25 (экшн фейлд) входящий

QaK · 26.12.2007, 10:08

В общем мысли вслух: взял последовательность:

Цитата:

Сообщение от VORON

8E2C00001C5A5487A14F
FB41000011475487D422
A22C00007F3754878D4F
CF410000722A5487E022
B62C00001C5A5487994F
23400000114754870C23
4A2D00007F375487654E
37400000722A54871823
5E2D00001C5A5487714E
0B400000114754872423
722D00007F3754875D4E

выделил в ней предполагаемый ключ для ксора: разбил на пары байт (для наглядности):

Цитата:

A14F00001C5A5487 =========================== A14F 0000 1C5A 5487
D422000011475487 =========================== D422 0000 1147 5487
8D4F00007F375487 =========================== 8D4F 0000 7F37 5487
E0220000722A5487 =========================== E022 0000 722A 5487
994F00001C5A5487 =========================== 994F 0000 1C5A 5487
0C23000011475487 =========================== 0C23 0000 1147 5487
654E00007F375487 =========================== 654E 0000 7F37 5487
18230000722A5487 =========================== 1823 0000 722A 5487
714E00001C5A5487 =========================== 714E 0000 1C5A 5487
2423000011475487 =========================== 2423 0000 1147 5487
5D4E00007F375487 =========================== 5D4E 0000 7F37 5487

Дальше мысли потекли в таком направлении(/bred generator on):
"А что будет если предыдущий ключь отксорить на последующий"
получилось(жирным выделен результат ксора)

Цитата:

A1-4F 0000 1C-5A 5487
75-6D 0000 0D-1D 0000
D4-22 0000 11-47 5487
59-6D 0000 6E-70 0000
8D-4F 0000 7F-37 5487
6D-6D 0000 0D-1D 0000
E0-22 0000 72-2A 5487
79-6D 0000 6E-70 0000
99-4F 0000 1C-5A 5487
95-6C 0000 0D-1D 0000
0C-23 0000 11-47 5487
69-6D 0000 6E-70 0000
65-4E 0000 7F-37 5487
7D-6D 0000 0D-1D 0000
18-23 0000 72-2A 5487
69-6D 0000 6E-70 0000
71-4E 0000 1C-5A 5487
55-6D 0000 0D-1D 0000
24-23 0000 11-47 5487
79-6D 0000 6E-70 0000
5D-4E 0000 7F-37 5487

Наблюдения 5й и 6й байты повотряются циклично 6Е-70 и 0D-1D а 1й и 2й как-то непонятно(для меня) воть пока все.
А еще 2й байт ксора 6D - повторяется сколько-то раз, потом 6С, потом снова по 6D, 2й байт ключа увеличивается на 1, надо отловить от чего это зависит, в частности нужен кусок, где 2 раза меняется (+1) 2й байт.

такс продолжение: анализируя второй кусок кода с вкраплениями получил (без пакетов от сервака):

Цитата:

18-F2 0000 3EE3 5487
69-6D 0000 1E-DC 0000
71-9F 0000 203F 5487
75-6D 0000 7D-B1 0000
04--F2 0000 5D8E 5487
99-6D 0000 1E-DC 0000
9D9F 0000 4352 5487
6D-6D 0000 7D-B1 0000
F0-F2 0000 3EE3 5487
79-6D 0000 1E-DC 0000
89-9F 0000 203F 5487
55-6D 0000 7D-B1 0000
DC-F2 0000 5D8E 5487
69-6D 0000 1E-DC 0000
B5-9F 0000 4352 5487
7D-6D 0000 7D-B1 0000
C8-F2 0000 3EE3 5487
69-6D 0000 1E-DC 0000
A1-9F 0000 203F 5487
15-6D 0000 7D-B1 0000
B4-F2 0000 5D8E 5487
79-6D 0000 1E-DC 0000
CD9F 0000 4352 5487
6D-6D 0000 7D-B1 0000
A0-F2 0000 3EE3 5487
59-6D 0000 1E-DC 0000
F9-9F 0000 203F 5487
75-6D 0000 7D-B1 0000
8C-F2 0000 5D8E 5487
69-6D 0000 1E-DC 0000
E5-9F 0000 4352 5487
9D-6C 0000 7D-B1 0000
78-F3 0000 3EE3 5487
69-6D 0000 1E-DC 0000
11-9E 0000 203F 5487
75-6D 0000 7D-B1 0000
64-F3 0000 5D8E 5487
59-6D 0000 1E-DC 0000
3D-9E 0000 4352 5487
6D-6D 0000 7D-B1 0000
50-F3 0000 3EE3 5487
79-6D 0000 1E-DC 0000
29-9E 0000 203F 5487
15-6D 0000 7D-B1 0000
3C-F3 0000 5D8E 5487
69-6D 0000 1E-DC 0000
55-9E 0000 4352 5487
7D-6D 0000 7D-B1 0000
28-F3 0000 3EE3 5487
69-6D 0000 1E-DC 0000
41-9E 0000 203F 5487
55-6D 0000 7D-B1 0000
14-F3 0000 5D8E 5487

5й и 6й байты ксора о5 циклично повторяются, 2й байт ксора 6D - такой же как и в первом, один раз изменяется на 6С, первый байт ксора непонятно как меняется, хотя вроде какая-то закономерность есть .... ток хз какая ...
еще: если поксорить 5е байты от ксора из первого варианта и из второго - получается одно и то же значение (63), для 6го также (6D)
З.Ы. просьба по голове больно не бить :wink:

VORON · 28.12.2007, 02:51

QAK , давай думать мозгами... мне кажется что мы на верном пути.. то что циклит- заметили, то что ксор повторяется- тожэ.. давай думать дальше.. применять школьный курс математики... наврядли они ДИФЕНЦИАЛЬНЫЕ УРАВЕНИЯ ввели...
я и ты заметили что 2-й байт ключа отличается друг от друга на ксор равный "6D" а я ето подтвердил путем долгово мониторинга.. в разные дни.. даже после рестарта сервака- 2-й байт ключа- закономерно циклится на ксор "6D" об чем ето говорит???
я думаю что новый ключ получается из предыдущего путем ксора!. в случае со вторым байтом ключа- на одно и тожэ... поетому цикл такой.. именно на 6D ... 2-й байт от одного ключа отксорим на 6D и получим второй байт нового ключа... былобы всё хорошо но ето не всегда.. порой ето сбивается.. на 1 раз... на 1 пакет.. ксор нового ключа на предыдущий становится 6C порой.. на 1 пакет... и после етого всё снова: ксор- 6D (даже после рестарта сервака) 6D- это константа для ксора второго байта ключа.. очень редко на 1 раз она на 1С прыгает- но ето мы разберемся... далее.. раз так то- как мы можем получить цикличность такую? как написано в логе для второго байта исходящего пакета... 4F 22 4F 22 4F 22 как?? ето происходит если чтото ксорить на одно и тожже.... любое число ксорь на одно и тожэ и ответ будет циклом.. то одно то другое значение... из етого вывод что новый ключ- получается из предыдущего путем ксора предыдущего ключа на ЧТОТО! ето чтото- во втором байте- константа! т.е. для второго байта одно и тоже 6D...... на 6D 2-й байт ксорится вечно! но невсегда.. очень редко на 6С.. и то на 1 раз..
складывается такое впечатление что работает формула KEY2:=KEY1 xor F(d) , где D - длинна пакета... и при етом работают тока 2 байта... 1-й- всегда а второй- редко и то на 1 ксор отличается (вместо 3D становится 3C)... т.е. F(d)- на 3-й разряд 16- ричного числа- редко перелазит... F(d) работает в основном в пределах 1-го байта..
но раз при повторных однобайтовых пакетах ета F(d) залазит всётки на 2-й байт то вывод- она размером не ограничена.. и с каждым пакетом может быть она и растет даже... но странно .. 1 фиг если 2-й байт от ключей последовательных отксорить то выходит что почти всега 6D и на 1 раз 6С потом снова 6D т.е. функцие F(d) стремится чтоли както к 6D.. (бред неспорю...)....
вы спросите почему я взял формулу именно от D - (длинны пакета) зависящую.. да просто потому что при однобайтовом пакете (2B- исходящем) ключ друг от друга на 1 изменяется... то больше то меньше то по 4 больше то по 4 подряд меньше.. то 8 подряд больше то по 8 подряд меньше.. потом сменяется диапазон.. и снова конструкция повторяется на 1.. т.е. явно видно что при 1-но байтовом пакете ксор на 1 идет.. но с феничками.. вот обратите внимание если есть последовательная логика, то.. при смене диапазона четный ключ в следущий раз преобразуется на +1 а нечетный в минус на -1 ... смотрим логи в етом топе : 86 85 84 91 90 89 88 95 94 93 (ключ меняется при однобайтовом пакете) диапазон начался с 91 - нечетного значит следует ожидать 89 следушего.. что соответствует ксору на 1. ( длинну пакета..). а вот в другом логе видно что если последовательность алгоритма начинается с четного то следущий ключ будет больше на 1... сменить аллгоритм для первого байта ключа- очень просто.. достаточно среди кучи пакетов 2B - исходящих, отправить 1-н 10 байтов на ЮЗ СКИЛЛ... при етом меняется тенденция то на убывание ключ идет то на возрастание... при мониторинге однобайтового пакета (2B)....
а при етом всем при мониторенги 10-ти байтового пакета мы мониторим все 8 байтов ключа... и видим что 2-й байт в ключе друг от друга отличается на ксор 6D. .. и ето об многом говорит... думаем дальше..

бред конечно... нам нужны для решения задачи- МАТЕМАТИКИ!!!!!! а их ужэ и нету в природе все надеются на калькуляторы и т.д. а головой мыслить мало кто может! ПОЕТОму в етой теме тока модеры между собой общаются те- кто стремится.. а все остальные заглядывают сюда в надежде получить халяву на смену шифрации...
да еёе не будет даже когда мы вслух алгоритм озвучим.. рано или поздно... 1 фиг тот кто туг умом несможет весь етот математический бред под себя настроить..
но логику раскусите плиз!!!!! скажите какие логи нужны! я дам!
мне нужен закон по которому КЛЮЧ МЕНЯЕТСЯ!