Самостоятельное декодирование dat без l2encdec

Stenly76 · 14.11.2016, 11:25

Цитата:

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

Ой чувствую щас за некропостинг получу по ушам, но всёже... В конце всех фалов закриптованных 413 алгоритмом присутствуют дополнительные 20 байт... Линейка 20 нулей прекрасно кушает, НО всёже интересно откуда l2encdec берет эти байты? Заметил что при изменении 413 на 414 меняются только 4 байта в конце. Крипт/декрипт свой сделал, но вот непойму что это в конце. Какая-то контрольная сумма? Кто знает как ее просчитать?

P.S: в оригинальных файлах ладвы эти байты в конце не пустые, собственно это и смущает...

P.P.S: а еще кому знакома цифра 143114 - подскажите как бороться, у меня уже моск вывернулся в непонятном направлении :\

и от меня некропост

это CRC32 взятый начиная с самого начала включая заголовок (Lineage2Ver) и по результат от Енкрипта (до выравнивания нулями)

Добавлено через 9 минут

Цитата:

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

Зато теперь есть общедоступная реализация на php и delphi

В интернете подробной информации нет. Про RSA понятно по l2encdec (вывод процесса распаковки). Сжатие - логично, потому что размер файла меньше (плюс DStuff написал про использование zlib у себя в USAGE). То, что сначала сжимают, а потом шифруют через RSA - тоже понятно (иначе бы ничего не сжималось

Заголовок и CRC видно в hex-редакторе (размер остального кратен 128, что намекает на RSA и размер ключа и блоков).
Так что единственное темное пятно - ключи, а вот их нигде нет

Кстати, твой вариант не всегда будет работать, потому что в последнем блоке, который неполный, данные могут быть смещены (не знаю почему и зачем). Из-за этого пришлось добавить костыль:

PHP код:


			
    if ($size != 0x7c) 

    { 

      $p = strlen($s) - $size; 

      while ($p > 2 && $s[$p - 1] != "\0") --$p; 

      $s = substr($s, $p, $size); 

    } 

    else 

    { 

      $s = substr($s, -$size); 

    }

Добавлено через 3 минуты
Честно говоря, копался в этом больше из-за любопытства, а не по необходимости. Началось с разбора нового 'itemname-*.dat' (l2disasm уже не помогает, поэтому пришлось писать свою программу), а потом захотелось разобраться и с l2encdec.

Похоже догадался: идет выравнивание до кратности в 4ре байта.

user713 · 29.12.2016, 08:31

Цитата:

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

это CRC32 взятый начиная с самого начала включая заголовок (Lineage2Ver) и по результат от Енкрипта (до выравнивания нулями)

Спасибо, то что нужно

Цитата:

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

Похоже догадался: идет выравнивание до кратности в 4ре байта.

Именно так, тоже просчитал это, немного поэкспериментировав, и убрал все костыли из кода)

Цитата:

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

P.P.S: а еще кому знакома цифра 143114 - подскажите как бороться, у меня уже моск вывернулся в непонятном направлении :\

Цитата:

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

Уверен, что это твой косяк, когда работал с ZLib'ом вообще не помню каких либо сложностей, все сжималось и разжималось, для любых файлов ла2.

Как показали эксперименты - косяк не мой) Взял оригинальные файлы Ла2 - и все разжалось, сжалось байт в байт) А если брать файлы уже обработанные через l2encdec - тут начинаются расхождения (l2encdec жмёт чуть сильней и заголовок и хвост потока отличаются от оригинального zlib) Клиент ладвы кушает оба варианта без проблем. Моя тулза понимает файлы l2encdec, l2encdec понимает файлы от моей тулзы, но при взаимной обработки блоки могут отличаться (чаще это первый и последний блоки). Но главное что всё работает