Для создания l2infob.dat из этого необходимо только
UINT id;
UNICODE name;
UNICODE add_name;
ASCF description;
Разобрал actionname-ru.dat, потратил 15 минут. Ничего сложного нет.
----------------------------
Пока это только простой парсер, помогите написать или посоветуйте как это все хранить в памяти и потом уже записывать в txt, проблема в том, что заранее не известно количество элементов масива и постоянно меняется и при простой записи в txt все сдвинуто в кучу.
Последний раз редактировалось Be3geBJIa3, 28.10.2011 в 18:12.
Ой чувствую щас за некропостинг получу по ушам, но всёже... В конце всех фалов закриптованных 413 алгоритмом присутствуют дополнительные 20 байт... Линейка 20 нулей прекрасно кушает, НО всёже интересно откуда l2encdec берет эти байты? Заметил что при изменении 413 на 414 меняются только 4 байта в конце. Крипт/декрипт свой сделал, но вот непойму что это в конце. Какая-то контрольная сумма? Кто знает как ее просчитать?
P.S: в оригинальных файлах ладвы эти байты в конце не пустые, собственно это и смущает...
P.P.S: а еще кому знакома цифра 143114 - подскажите как бороться, у меня уже моск вывернулся в непонятном направлении :\
Последний раз редактировалось user713, 07.08.2016 в 08:14.
если скажешь откуда эту цифру взял, может кто-то и подскажет
После сжатия большого количества данных ZLIB'ом именно это количество байт (уже сжатых) сходится с данными упакованными темже l2encdec, все что выше - полностью разное. И вдобавок zlib не хочет распаковывать информацию которую сам же и упаковал, которая больше этого числа Я конечно понимаю что это скорей всего мой косяк, но перепробовав десятки разных версий zlib'a и встретив эту цифру абсолютно везде, я всетаки сделал выводы что ошибка "типична" для данного продукта.
P.S: жму стандартным compress, в то время как l2encdec напрямую использует методы inflateInit, inflate и inflateEnd
Последний раз редактировалось user713, 15.08.2016 в 10:19.
После сжатия большого количества данных ZLIB'ом именно это количество байт (уже сжатых) сходится с данными упакованными темже l2encdec, все что выше - полностью разное. И вдобавок zlib не хочет распаковывать информацию которую сам же и упаковал, которая больше этого числа Я конечно понимаю что это скорей всего мой косяк, но перепробовав десятки разных версий zlib'a и встретив эту цифру абсолютно везде, я всетаки сделал выводы что ошибка "типична" для данного продукта.
P.S: жму стандартным compress, в то время как l2encdec напрямую использует методы inflateInit, inflate и inflateEnd
Уверен, что это твой косяк, когда работал с ZLib'ом вообще не помню каких либо сложностей, все сжималось и разжималось, для любых файлов ла2.
Ой чувствую щас за некропостинг получу по ушам, но всёже... В конце всех фалов закриптованных 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 и размер ключа и блоков).
Так что единственное темное пятно - ключи, а вот их нигде нет
Кстати, твой вариант не всегда будет работать, потому что в последнем блоке, который неполный, данные могут быть смещены (не знаю почему и зачем). Из-за этого пришлось добавить костыль:
Добавлено через 3 минуты
Честно говоря, копался в этом больше из-за любопытства, а не по необходимости. Началось с разбора нового 'itemname-*.dat' (l2disasm уже не помогает, поэтому пришлось писать свою программу), а потом захотелось разобраться и с l2encdec.
Похоже догадался: идет выравнивание до кратности в 4ре байта.
Последний раз редактировалось Stenly76, 14.11.2016 в 11:25.
Причина: Добавлено сообщение
это CRC32 взятый начиная с самого начала включая заголовок (Lineage2Ver) и по результат от Енкрипта (до выравнивания нулями)
Спасибо, то что нужно
Цитата:
Сообщение от Stenly76
Похоже догадался: идет выравнивание до кратности в 4ре байта.
Именно так, тоже просчитал это, немного поэкспериментировав, и убрал все костыли из кода)
Цитата:
Сообщение от user713
P.P.S: а еще кому знакома цифра 143114 - подскажите как бороться, у меня уже моск вывернулся в непонятном направлении :\
Цитата:
Сообщение от ScythLab
Уверен, что это твой косяк, когда работал с ZLib'ом вообще не помню каких либо сложностей, все сжималось и разжималось, для любых файлов ла2.
Как показали эксперименты - косяк не мой) Взял оригинальные файлы Ла2 - и все разжалось, сжалось байт в байт) А если брать файлы уже обработанные через l2encdec - тут начинаются расхождения (l2encdec жмёт чуть сильней и заголовок и хвост потока отличаются от оригинального zlib) Клиент ладвы кушает оба варианта без проблем. Моя тулза понимает файлы l2encdec, l2encdec понимает файлы от моей тулзы, но при взаимной обработки блоки могут отличаться (чаще это первый и последний блоки). Но главное что всё работает