Декодирование и дизассемблирование файлов Рус. Оф. Сер-ра.

[S@nderS]

Доброго времени суток, форумчане.

Интересует следующий вопрос: Находил кто декодер для файлов русского оффа?

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

Если кто достиг успехов в патчинге русского клиента, сообщите пожалуйста.

[J-Fobos]

L2Dat_EncDec
Официальный сайт _http://www.l2j-jp.info

Там все на понятном языке рописано Так что сразу заходим в эту ветку форума
_http://www.l2j-jp.info/forum/viewforum.php?f=18

Ну и если уж очень лениво даже по инглышу читать вот ссылка на закачку
_http://trac.l2j-jp.info/L2Dat_EncDec/wiki

[S@nderS]

Сообщение от J-Fobos

L2Dat_EncDec
Официальный сайт _http://www.l2j-jp.info

Там все на понятном языке рописано Так что сразу заходим в эту ветку форума
_http://www.l2j-jp.info/forum/viewforum.php?f=18

Ну и если уж очень лениво даже по инглышу читать вот ссылка на закачку
_http://trac.l2j-jp.info/L2Dat_EncDec/wiki

О, спасибо. Очень конечно хорошо, что он декодирует, но вот как теперь закодировать, да так чтобы работало? Проблема в том, что есть 2 типа энкодинга обычные и энкодинг оригинальных файлов. Оригинальный используется для оффа. Вот каким образом закодировать в оригинальный, вот настоящая проблема. У меня такое чувство, что это могут сделать только разработчики

[J-Fobos]

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

[Клерик]

Евро от Русского, не отличается, так? Или все же есть разные способы кодировки, раскодировки?

[J-Fobos]

Напишу очень розвернутый ответ

Процесс открытия dat/ini файлов разбивается на 2 части: криптование и кодирование.

Сначала файл криптуется, потом кодируется. Сначала рассмотрим кодирование так как более понятно простому человеку. Запись/чтение данных в dat файл производится блоками с помощью системных процедур BlockWrite и BlockRead. Процедура имеет следующий вид:
BlockWrite(<имя файла>,<переменная для записи>,<размер переменой для записи>);
BlockRead(<имя файла>,<переменная для записи>,<размер переменой для записи>);
На первый взгляд все нормально, но возникает проблема: чтобы прочесть переменную из файла надо предварительно знать ее длинну. Для этого dat файл делают в виде таблицы в шапке которой записывают длину переменной для чтения/записи.

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

В линейке для отображения кирилици используют кодировку UTF-8, а на корейском офе для их иероглифов используют UTF-32 которые, как видно из названия используют разное количество байт для хранения одного символа.
Соответственно параметры в процедурах BlockWrite и BlockRead которые отвечают за размер текстовых переменных будут разные. Хотя сам способ открытия таких файлов остается неизменным как для ру офа так и для остальных, но меняются входящие параметры. Еще во времена С3 для удобства открытия подобных файлов в программу asm-disasm включили возможность задавать величины этих переменных. Для этого ввели *.ddf файлы в которых записывается структура dat файла и позже по этой структуре файл читается. Сами ddf файлы под разные криники можно без проблем найти в инете, но если надо могу выложить их и тут (у меня имеются все начиная с С3).

С ini файлами ситуация чуть другая, там не используется BlockWrite/BlockRead, в них используется система просто текстового файла и никаких заморочек в отличии от dat файлов нету. Поэтому эти файлы открываются для всех кодировок одинаково.

С криптованием ситуация чуть сложнее. Сам алгоритм довольно сложный и громоздкой так что расписывать его нестоит. В этом алгоритме по определенной формуле шифрируется каждый байт файла с использованием ключа (ключ в 95% случаев используют 413). А при розшифровании используется уже другая формула, но с тем же ключом. Формулу по которой файл розшифровывается уже давно вытащили из клиента и прекрасно используют в программе l2encdec (все программы для правки файлов линейки являются лиш графическими оболочками для нее). А вот формулу по которой файл шифруется никто не узнал (в клиент она не вшита). Ее попытались создать с помощью формулы розшифровки, но к сожалению получилось лиш похожая формула, поэтому и не получается закодировать новые файлы также как и оригинальные. Для тех кто знает математику это можно сравнить с взятием интеграла, а потом производной.
Подробнее о криптографии можно прочесть в википедии
http://ru.wikipedia.org/wiki/%D0%9A%...84%D0%B8%D1%8F

Фун блин, вот это я настрочил

[S@nderS]

Ну то что написано выше, это почти всем кто работал с клиентом. Кому бы в НКСофт дать бутылку водки за оригинальный алгоритм шифрования

[mcrss]

L2Dat_EncDec работает не со всеми файлами клиента руоффа. skillname-ru.dat например расшифровывает, а itemname-ru.dat - нет.
Для вскрытия itemname-ru.dat я пользовался связкой l2encdec_2.10.1 и l2asm-disasm_1.4.0. Все отлично расшифровывается.

[dragindrog]

Может кто подскажет чем открывать файл utx для новых хроник GO все перепробовал и не каких результатов

Добавлено через 18 часов 4 минуты
Млях срочно нужен декриптор UTX для GO