Просмотр полной версии : Датамайнинг клиента игры
Страницы :
[
1]
2
3
4
5
6
7
8
9
10
nORb Dragon
30.04.2019, 09:25
Ссылки на полезные ресурсы:
Публичный архив изменений по датамайну на «E7 Vault» (https://www.e7vau.lt/datamine-history.html)
Ссылки на полезные посты:
потрошилки пакетов/архивов:data.pack (скрипты на python) - https://forums.goha.ru/showthread.php?p=159273387#post159273387 (версия 2.7 от 2021.12.02)
*.bank (скрипты на python, только под Windows) - https://forums.goha.ru/showthread.php?p=159275908#post159275908
описание потрошения звуковых файлов (.bank) - https://forums.goha.ru/showthread.php?p=158649085#post158649085
конверсия формата файлов:db-файл в csv-формат (скрипты на python) - https://forums.goha.ru/showthread.php?p=159274578#post159274578
(ВНИМАНИЕ! поддерживается пока только старый формат, использовавшийся до патча от 2021.06.10)
scsp-файл в json-формат (скрипты на python) - https://forums.goha.ru/showthread.php?p=159272975#post159272975
(ВНИМАНИЕ! поддерживается пока только старый формат, использовавшийся до патча от 2021.06.10)
Если у кого есть мысли, идеи, предложения или даже конкретные "программные продукты" для датамайна Epic Seven - пишем, не стесняемся. :smok) Открытый код - приветствуется! :|)
В случае, если есть что обсудить со мной, но лень регистрироваться на гохе, меня можно найти и на reddit: /u/nORbDragon
някавайня
30.04.2019, 09:44
https://www.reddit.com/r/EpicSeven/comments/a9lh4s/datamining_spoilersrawish_assorted_dump/
ну ты можешь поюзать реддит например в подобных темах и именно в этой обязательно есть челик который кричит как ты это делаешь научи меня и его учат в комментах:dunno:
nORb Dragon
30.04.2019, 10:09
Реддит - это свалка, где только изрядно покопавшись можно найти что-то ценное. :trololo: Нет времени глубоко и уныло копаться, поэтому и спрашиваю.
Пойду чекну линк. :think)
Добавлено через 8 минут
Глянул линк. Бесполезная инфа, которую я уже знал. :'(
Основное, что меня интересует:
- как нормально перекачать весь клиент игры с эмуля на комп, на примере Nox/Memu/LDPlayer (для дальнейших махинаций над декодингом на компе);
- чёткое указание, в каком файле и на какой позиции находится ключ для расшифровки других файлов;
- в чём в итоге запаковано всё (zip, java, ещё какой треш), чем именно распаковывать после дешифровки.
някавайня
30.04.2019, 10:27
Реддит - это свалка, где только изрядно покопавшись можно найти что-то ценное. :trololo: Нет времени глубоко и уныло копаться, поэтому и спрашиваю.
Пойду чекну линк. :think)
Добавлено через 8 минут
Глянул линк. Бесполезная инфа, которую я уже знал. :'(
Основное, что меня интересует:
- как нормально перекачать весь клиент игры с эмуля на комп, на примере Nox/Memu/LDPlayer (для дальнейших махинаций над декодингом на компе);
- чёткое указание, в каком файле и на какой позиции находится ключ для расшифровки других файлов;
- в чём в итоге запаковано всё (zip, java, ещё какой треш), чем именно распаковывать после дешифровки.
в ноксе есть какая то встроенная прога туда заходишь там собственно кучина папок(аля как в андройде) именно туда я закачивал анцензор пак по дестини чайлд возможно оттуда можно перекачать .
nORb Dragon
08.02.2020, 02:06
Апну темку. :trololo: ЭТО НЕ НЕКРОПОСТ! :|) Ну, почти. :trololo:
https://www.reddit.com/r/EpicSeven/comments/derpuy/guide_how_to_datamine_e7_assets/
Про дата майнинг и распаковку ресурсов.
В общем, поковырялся я немножко сегодня, раскуривая написанное по ссылке.
Предупреждать о том, что в EULA что-то там мелькает и намекает про "нельзя датамайнить", упоминать не буду. :spy: Подозреваю, что это скорее угроза для тех, кто попробует использовать результаты "майнинга" в своей "коммерческой деятельности" (клип-арты и т.д.) или начнёт модифицировать клиент.
Про "технические моменты" рассказывать пока не буду. Предложенное там: азы XOR, указание ключа и способ найти что-то интересное в файле data.pack.
Это всё: базовая информация, которой мне так реально нехватало год назад.
На основе этой инфы, я смогу для себя накидать:
динамический поиск нового ключа для XOR, если креативы решат его внезапно поменять для data.pack, но саму структуру файла менять не будут;
выгрузку ВСЕХ вложенных в data.pack файлов (не только png);
автоматизировать весь этот процесс до "нажатия одной кнопки".
Я не знаю, почему там в темке на reddit пугают народ огромными объёмами. На первый взгляд, png-файлы там непожаты. Насчёт остальных файлов - хз. Углублённо реализовывать это дело буду в свободное от работы время на работе. :trololo:
Из самого главного, что уже нащупал, и о чём нет инфы в той темке. Но я благодарен написанному там, ибо без той инфы о используемом ключе XOR и насколько сильно запрятаны там файлы (те же PNG), я бы не добрался до этого момента. Мб кому пригодится, поэтому оставлю здесь.
Начиная с определённого момента, содержимое data.pack файла превращается в склад разнообразных файлов. Они идут последовательно друг за дружкой, разделителем между ними является последовательность из четырёх байтов B3 02 00 00 (первый байт меняется по ходу пьесы? не разобрался до конца).
Начинается всё (ориентируюсь по data.pack от 6 февраля 2020 года) с позиции по адресу - 1407C. И дальше идут файлы, файлы, файлы.
Далее по тексту буду использовать фразу "поток записанного файла" под значением: вся информация по одному из множества файлов, которые были присобачены внутрь data.pack, записанная последовательно (инфа о файле + содержимое файла).
Описание потока записанного файла (что я понял, поковырявшись в data-pack):
4 байта - общий размер ВСЕГО блока, который посвящён данному файлу (маркеры окончания записанного потока включительно);
1 байт - служебный маркер с хз какой задачей, обычно значение равно 02;
1 байт - хранит длину строки с названием файла (в байтах);
4 байта - хранит размер содержимого файла (в байтах);
1 байт - служебный маркер с хз какой задачей, обычно значение равно 00;
4 байта - служебный маркер с хз какой задачей, часто содержит всякую ересь, но может быть равен и 00 00 00 00;
имя файла, где найти размер строки для его вырезания - упомянуто несколькими пунктами выше;
содержимое файла, где найти размер файла для его вырезания - упомянуто несколькими пунктами выше;
4 байта - служебный маркер окончания записанного потока файла, обычно имеет вид B3 02 00 00 (первый байт меняется по ходу пьесы? в конце data.pack используется BA).
Разберём на примере для закрепления.
Допустим, у нас по адресу 14AE2 есть описание потока записанного файла title/bg/1st_anniversary_bg.png
Рассматриваем под микроскопом с позиции 14AE2.
64-DB-07-00 02 1F 32-DB-07-00 00 00-00-00-00 74-69-74-6C-65-2F-62-67-2F-31-73-74-5F-61-6E-6E-69-76-65-72-73-61-72-79-5F-62-67-2E-70-6E-67-89
^ ^ ^ ^ ^ ^ ^- имя файла (title/bg/1st_anniversary_bg.png)
| | | | | ^- 4 байта - служебный маркер с хз какой задачей, часто содержит всякую ересь
| | | | ^- 1 байт - служебный маркер с хз какой задачей, обычно значение равно 00
| | | ^- 4 байта - размер содержимого файла, равняется в данном случае: 514 866 байт
| | ^- 1 байт - длина строки с названием файла, в данном случае: 31 байт
| ^- 1 байт - служебный маркер с хз какой задачей, обычно значение равно 02
|
^- общий размер ВСЕГО блока описания файла, в данном случае равен 514 916 байт, что соответствует:
= 514 866 байт (размер содержимого файла)
+ 31 байт (длина строки с названием файла)
+ 15 байт (служебные символы заголовка)
+ 4 байта (служебные символы маркера окончания записанного потока файла)
Ради интереса, смещаемся с позиции 14AE2 на позицию 92646 (+514 916 байт). И мы видим перед этим местом 4 байта со служебным маркером окончания файла (B3 02 00 00).
С самой же позиции 92646 начинается описание следующего записанного файла - title/bg/20_valentine_bg.png.
Сразу предупреждаю: это пока непроверенные мною наброски, сделанные в пятницу вечером на основе прочитанного и анализа "по-диагонали" файла data.pack. :trololo: Мне не нравится BA 02 00 00. :think) Надо будет присмотреться, что с ним не так.
nORb Dragon
08.02.2020, 12:52
Поглядел на свежую голову.
В общем, маркер окончания записанного потока файла может быть как B3-02-00-00, так и 00-00-00-00. В чём разница? Без понятия.
Смущавшие меня байты вида BA-02-00-00 - это последние четыре байта содержимого файлов, а не маркер окончания.
Так как этот маркер окончания записанного потока можно не анализировать, а тупо скипать бесполезные 4 байта, то думаю просто закрывать глаза на их содержимое. :think)
Ещё раз упоминаю, что это всё мой теорикрафт. Ковыряться в этом, писать программку по "распилу" data.pack на файлики буду на следующей неделе. Дома на ПК у меня ничего не стоит из нужного. :|)
автоматизировать весь этот процесс до "нажатия одной кнопки".
Помню раньше юзали скрипт на bms (https://zenhax.com/viewtopic.php?t=8908), но в новой версии игры не пашет. Вдруг поможет в разработке.
nORb Dragon
09.02.2020, 16:00
На своём линух-сервачке от нечего делать написал щаз потрошилку data.pack. :smok) Достал оттуда ВСЕ файлы (29.536). Другое дело, что возможно куча из них ещё дополнительно зашифрованы. :think)
https://forums.goha.ru/attachment.php?attachmentid=158715&d=1581253168
Распотрошил где-то за полторы минуты.
nORb Dragon
09.02.2020, 17:29
В общем, много клипарта и т.д. Аккуратно распихано по папкам и подпапкам. Но то, что меня интересует, кажется содержится в неизвестного мне формата файлах. :think)
Может кто в теме, чем открываются .atlas, .scsp, .sct файлы? :think) Кажется, что именно там спрятано нужное мне.
Архив для экспериментов - 158716
Ну и так, что в глаза бросилось.
Артефакт, которого я не видел в игре:
https://forums.goha.ru/attachment.php?attachmentid=158717&d=1581258375
Значок сета, которого нет в игре (и я хз как его понимать, ибо вамп и НР сеты есть):
https://forums.goha.ru/attachment.php?attachmentid=158718&d=1581258375
Сценка, которую я не видел вроде. :think)
https://forums.goha.ru/attachment.php?attachmentid=158719&d=1581258375
Карта рейд-лабиринта.
https://forums.goha.ru/attachment.php?attachmentid=158720&d=1581258375
Ну и Басар ждёт ваших кристаллов. :trololo:
https://forums.goha.ru/attachment.php?attachmentid=158721&d=1581258386
nORb Dragon
09.02.2020, 20:38
В общем, если кто хочет поиграться с датамайном. Или поделиться на реддите, вдруг кому там будет интересно. :think) Ну или побыть К.О., если там уже и до такой степени раскурил народ, но мы этих тем не видели. :|)
Вот что я набросал сегодня: 158722
Это - скрипт под python3. Предполагаемое место выполнения: linux. Под виндой не факт, что "взлетит", надо скорее всего допиливать "напильником". Но мне лень. :trololo:
Для работы необходимо наличие на линухе питона третьей версии и уже подготовленного ранее файлика data.pack . Под "подготовленностью" подразумеваю, что его уже прогнали через XOR. Инструкция со скриптом на питоне находится на реддите в темке по ссылке (см. Step 1, Step 2) - https://www.reddit.com/r/EpicSeven/comments/derpuy/guide_how_to_datamine_e7_assets/
Выполнять мой скрипт через команду:
python3 epic7ripper.py
Результаты выполнения будут сохранены:
- лог со списком "выпотрошенного" в файл epic7ripper.log
- сами "выпотрошенные" файлы будут вкинуты в папку от сегодняшнего числа (допустим: 20200209).
Не буду удивлён, если часть файлов (допустим те же .db) дополнительно зашифрованы и/или запакованы. Поэтому и решил поделиться скриптом, чтоб ускорить процесс "раскуривания". Да и может кто там сообразит, как открыть файлы с расширением .atlas, .scsp, .sct
Если вкинете на реддите этот скрипт, рекомендую моё имя не упоминать там всуе. Не хочу быть забаненным в игре за минутную шалость. :trololo:
Переводить на великий и могучий английский я комменты в скрипте конечно же не буду. :|) Пущай страдают!
Может кто в теме, чем открываются .atlas, .scsp, .sct файлы?
Где-то была база по игре со всеми анимациями персонажей, там полюбому знают как открыть. Вот только ссылку на сайт не могу найти :think)
Добавлено через 16 минут
Нашел.
https://e7herder.com/tools/model-viewer
Там слева вводишь имя персонажа и получает анимации.
С автором можно связаться через гитхаб (https://github.com/zklm/e7herder-issues/issues) или реддит (https://www.reddit.com/r/EpicSeven/comments/dord37/e7herder_model_viewer_and_small_db_site/).
nORb Dragon
11.02.2020, 16:09
Немножко допилил напильником скрипт. Вписал в него дешифровщик (xor) data.pack. Теперь достаточно будет снять с эмуля файл data.pack, закинуть его в папку со скриптом и запустить скрипт без всяких лишних манипуляций.
Конечно, процесс дешифровки довольно долгий, если чего.
Дешифрованный data.pack закинет в созданную папку от сегодняшнего числа вместе с результатом потрошения.
Новая версия скрипта: 158730
nORb Dragon
12.02.2020, 10:04
Файлики .pigz упакованы в gzip, если кого волновал этот вопрос.
nORb Dragon
12.02.2020, 12:39
Наброски того, что из себя представляют .pack файлы у Epic7. Скорее для себя, чтоб не забыть.
первые 5 байт файла - сигнатура, значение равно: PLPcK
1 байт с версией (?), обычно значение равно: 01
<-- первый блок файла -->
4 байта, в которых хранится адрес начала второго блока файла
(... непонятный набор байтов первого блока)
<-- второй блок файла, адрес его начала упомянут выше -->
4 байта, хранят общий размер ВСЕГО второго блока файла
(... непонятный набор байтов второго блока)
<-- третий блок файла, адрес его начала вычисляется на основе стартовой позиции второго блока + размер второго блока -->
(список файлов)
Хотелось бы понять, что спрятано/описано в первом и втором блоках. :think)
Описание формата списка файлов я уже упоминал ранее, найти можно по ссылке - https://forums.goha.ru/showthread.php?p=158315163#post158315163
Осталось теперь понять, где спрятаны ключи для дешифрования .db файлов. И как расковырять файлы спрайтов .sct. :think)
Есть мысль, что они дополнительно ещё и запакованы, но не могу на глаз определить использованный алгоритм. :think)
Вообще, нагуглил, что .atlas и .scsp - это результат работы с программой 2d анимации Spine - http://esotericsoftware.com/spine-texture-packer
Но не могу разобраться с sct-файликами. И да, это не Scitex CT, судя по результам моих экспериментов. Или он как-то странно упакован. :think)
Теперь касаемо
С автором можно связаться через гитхаб или реддит.
Я думаю, что если бы он хотел поделиться инфой о датамайне, он бы ею давно поделился. :trololo:
Все его посты: это предложение оценить результат его работы по датамайну (тот же сайт) и/или сообщить ему об ошибках.
В общем, даже пытаться не буду с ним выходить на связь. :|) Меня нет ни на реддите, ни на гитхабе.
nORb Dragon
12.02.2020, 15:30
Разобрался со вторым блоком файла. Там действительно идёт тупое перечисление адресов позиций, где в файле находится старт очередного блока описания вложенного файла.
Второй блок имеет вид:
1 байт - служебный маркер, вроде всегда равен 01
<- список ссылок, имеющих вид: ->
1 байт - служебный маркер, всегда равен 00
4 байта, в которых хранится адрес начала описания вложенного файла
Кстати, в 4 байтах с адресом может значиться 00-00-00-00. Фича мб. :think) Их надо скипать.
Осталось раскурить, за что отвечает первый блок. :think)
nORb Dragon
14.02.2020, 12:05
Возвращаясь к блоку с файлами, их описанию.
^- 4 байта - служебный маркер с хз какой задачей, часто содержит всякую ересь
Перебрал дохрена вариантов, что это. Не похоже на CRC, не похоже на ключ дешифровки...
Ради интереса попробовал посмотреть, что если заюзать это значение в качестве позиции в файле, и... таки да, это ссылки на другие файлы. Вопрос: зачем? :think) Ответа на этот вопрос у меня нет.
Вскрываются ли .scsp и .sct файлы программкой Spine - не в курсе. Ибо программка платная, триал версия не даёт возможности заюзать нужный мне функционал. Хотя... надо будет проверить, наверняка существует "торрент-эдишен"? А то платить за ПО, которое мне не поможет... я уже давно перешёл в категорию "я не настолько богат".
Чем вскрыть файлики .db я тоже так и не разобрался.
В общем, мои силы на "соло мозговой штурм" закончились. Кажется, пора отрихтовать немножко скрипт потрошилки, мб "перевести" комменты на анл, и закинуть этот скрипт + волнующие меня файлы под "анонимом" на реддит. С предложением раскурить вместе, как эти файлы можно вскрыть.
Следующий этап: соберу наверн отдельный скрипт для сравнения результатов датамайнов от разных дат для поиска новых/изменённых файлов. :think) Чтоб ручками не сравнивать.
nORb Dragon
14.02.2020, 14:24
Предположительно, окончательный вариант скрипта потрошилки на python3 с "ру-комментами внутри". :think)
Исполнять на линухе. На винде скорее всего не взлетит.
Скрипт для скачивания: 158751
Исполнять через команду:
python3 epic7ripper_v1_2.py
Предварительно, конечно, закидываем в ту же папку файл data.pack, который ещё не был прогнан через XOR.
Скрипт сам дешифрует файл, после чего начнёт его потрошить. Результат будет сохранён в папку с названием вида YYYYMMDD. В эту же папку будет сохранён дешифрованный вариант data.pack.
Лог работы будет сохранён в файл epic7ripper.log.
Выглядеть лог будет как-то так:
Готовимся к дешифрованию, копируем содержимое файла data.pack в оперативную память...
Приступаем к дешифровке data.pack , результат будет сохранён в 20200214/data.decrypted-20200214.pack
- дешифрование завершено
Запуск задачи по потрошению...
Результат потрошения будет сохранён в папку по адресу: ***/20200214
Позиция начала блока с файлами: 0x1402b | 81963
* упоминаемая ссылка на другой файл - адрес на описание другого файла, смысл его упоминания непонятен
Начало |*Ссылка на | Имя вложенного файла | Размер файла
описания|другой файл| | (в байтах)
========|===========|============================= ===========================================|====== =================
0001402b| 00000000 | @patch.attributes | 45
0001407c| 0abb9fef | title/title_manager.db | 2621
00014ae2| 00000000 | title/bg/1st_anniversary_bg.png | 514866
00092646| 291eba2f | title/bg/20_valentine_bg.png | 652719
00131c24| 4f1fb869 | #partion.title.sector_rev | 4
00131c54| 25f031f1 | title/bg/19_xmas_bg.png | 594517
001c2ed3| 0cf22b10 | bin/game.bin | 4848262
00662978| 04ac2d3b | #partion.bin.ver | 4
0066299f| 4b7e5f70 | text/text_en.db | 7961449
00dfa52a| 00000000 | #partion.text_en.sector_rev | 4
00dfa55c| 24f36a29 | text/en/event_02.en.srt | 276
00dfa69a| 00000000 | text/en/mov1_1_10.en.srt | 68
00dfa709| 20d80151 | text/en/mov1_2_0.en.srt | 1138
00dfaba5| 00000000 | #partion.text_en.ver | 4
00dfabd0| 349dd8bf | title/bg/19_halloween_bg.png | 623759
00e9308e| 1f50dc3b | title/logo/epic7_event_logo_zht.png | 404556
00ef5d10| 5aad0026 | title/logo/epic7_event_logo.png | 359704
00f4da5a| 01156dfa | title/bg/19_summer_bg.png | 491477
00fc5a5b| 00000000 | #partion.title.ver | 4
00fc5a84| 00000000 | #partion.media_pre.ver | 4
00fc5ab1| 00000000 | #partion.media_pre_ko.ver | 4
00fc5ae1| 08d34f56 | #partion.media_voc_ko.ver | 4
00fc5b11| 00000000 | banner/ja/sp_season4_upgrade.png | 68316
(...)
74594405| 00000000 | zodiac2/wnd_maiden.csb | 6864
74595efe| 00000000 | effect/eff_explosion_fire_ground.scsp | 2157
745967a3| 00000000 | #partion.res.ver | 4
745967ca| 00000000 | @ver.minimal | 4
745967ed| 00000000 | @ver.media | 4
7459680e| 00000000 | @ver.res | 4
7459682d| 00000000 | @ver.text | 4
7459684d| 00000000 | @ver | 4
Всего выгружено файлов: 29537
nORb Dragon
14.02.2020, 16:20
Оп. Кажется в куче комментов на реддите я таки нашёл нужную мне инфу на расшифровку db-файлов. Щаз ковыряюсь, подбираю xor-ключ методом научного тыка... Надеюсь, что он подойдёт ко всем db-файлам. :cw:
nORb Dragon
14.02.2020, 20:10
Как йа задолбался... Но я таки сделалЪ. Смог собрать ключ к одному из db-файлов на основе... млять, вот этого - https://pastebin.com/DY0db2D2 Четыре часа угробил! :mad:
Кому интересно, оригинальный зашифрованный файл и уже дешифрованный мною на основе "подсказки" можно забрать по ссылке, в архиве: 158752
И да, я этот подобранный ключик прогнал по поиску в data.pack. Нашёл его упоминание в файлике text/text_en.db :think) Видно там спрятаны ключи к остальным db-файлам. Надо будет поковыряться, попотрошить его. Не, показалосЪ.
Касаемо же формата данных в дешифрованном db-файлике: пока не ковырялся. Но по ходу ковыряния над ключом обратил внимание на наличие маркеров колонок. Думаю, там табличные данные. В анализ формата не углублялся ещё.
надо будет проверить, наверняка существует "торрент-эдишен"?
Я не нашел. Странно, что никто не взломал. :dunno:
На винде скорее всего не взлетит.Надо всего лишь установить питон и пойдет :think)
nORb Dragon
16.02.2020, 00:57
Я просто хз, не заглючит ли питон под виндой при юзании в пути обратного слеша. :|)
nORb Dragon
17.02.2020, 12:26
Разобрался со структурой db-файлов. Универсальный конвертер их в текстовые файлы с табулятором-разделителем собрал. Но проблема с тем, что надо к каждому такому db-файлу индивидуально подбирать xor-ключ - осталась.
Если кому любопытно, содержание файла character_player.db, приведённое к табличке экселя: 158769
Так как db-файлов много, а подбирать подходящий ключ к каждому из них я не буду. Лень. :cw:
Если кто считает, что в каком-то из db-файлов находится ОЧЕНЬ важная и полезная инфа - тыкните в него пальцем. Мб поковыряюсь над ним, подберу к нему xor-ключ. :think)
PS: забыл приложить сам текстовый файл с табуляторами - 158770
nORb Dragon
17.02.2020, 15:36
Накидал мозгодробительное описание формата .db для тех, кто постарше и любит ковыряться во всякой хрени. :trololo:
Файл .db состоит из:
- 5 байт сигнатуры: PLPcK
- 1 байт с версией (?), обычное значение: 01
- 4 байта, хранят адрес начала второго блока данных, обычно значение равняется 26-00-00-00
- <-- первый блок данных неизвестного назначения -->
(набор байтов первого блока)
- <-- второй блок данных: перечисление адресов описание строк таблицы в .db файле -->
- 4 байта, хранят общий размер ВСЕГО второго блока файла
- 1 байт - служебный маркер, вроде всегда равен 01
- <-- перечисление адресов описания вложенных файлов -->
- 1 байт - служебный маркер, всегда равен 00
- 4 байта, в которых хранится адрес начала описания строки таблицы, возможно пустое значение вида 00-00-00-00
- <-- третий блок данных: базовая информация о параметрах таблицы -->
- <-- строка данных, хранящая количество колонок таблицы [1*] -->
- <-- строка данных, хранящая количество строк таблицы [1*] -->
- <-- четвёртый блок данных: перечисление заголовков колонок таблицы [2*] -->
- <-- пятый блок данных: перечисление строк таблицы [3*] (количество строк таблицы получаем из третьего блока) -->
- <-- шестой блок данных: мусор -->
- скорее всего всегда равен этой строке:
00-00-50-4C-50-63-4B-01-26-00-00-00-00-00-00-00-00-00-00-24-06-00-00-2C-06-00-00-00-26-00-00-00-00-00-00-00-00-00-00-00
[1*]
Описание формата строки данных, хранящей количество колонок/строк таблицы:
- 4 байта - общий размер ВСЕГО блока, который посвящён данной строке
- 1 байт - служебный маркер с хз какой задачей, всегда равен 02
- 1 байт - хранит длину строки со служебным идентификатором (в байтах)
- 4 байта - хранит размер содержимого строки таблицы (в байтах), значение равняется 04-00-00-00
- 1 байт - служебный маркер с хз какой задачей, всегда равен 00
- 4 байта - хранит адрес начала описания ДРУГОЙ строки, задача его упоминания непонятна, возможно пустое значение вида 00-00-00-00
- служебный идентификатор, где найти размер строки для его вырезания - упомянуто несколькими пунктами выше:
(*) \t - символ табуляции, h09
- если идентификатор равен \tcols - значит строка посвящена количеству колонок в таблице
- если идентификатор равен \trows - значит строка посвящена количеству строк в таблице
- 4 байта - количество колонок/строк таблицы (в зависимости от значения предыдущего параметра)
[2*]
Описание формата строки данных, хранящей описание колонки таблицы:
- 4 байта - общий размер ВСЕГО блока, который посвящён данной строке
- 1 байт - служебный маркер с хз какой задачей, всегда равен 02
- 1 байт - хранит длину строки со служебным идентификатором (в байтах)
- 4 байта - хранит размер наименования колонки таблицы (в байтах)
- 1 байт - служебный маркер с хз какой задачей, всегда равен 00
- 4 байта - хранит адрес начала описания ДРУГОЙ строки, задача его упоминания непонятна, возможно пустое значение вида 00-00-00-00
- служебный идентификатор, где найти размер строки для его вырезания - упомянуто несколькими пунктами выше
- наименование колонки таблицы, где найти размер для его вырезания - упомянуто несколькими пунктами выше
[3*]
Описание формата одной (! ВНИМАНИЕ, это не очепятка, здесь каждая строка состоит из двух блоков) строки таблицы:
- <- блок со служебным идентификатором строки (смысл наличия этого мусора? неизвестен, я этот блок игнорирую) ->
- 4 байта - общий размер ВСЕГО блока, который посвящён идентификатору
- 1 байт - служебный маркер с хз какой задачей, всегда равен 02
- 1 байт - хранит длину строки со служебным идентификатором (в байтах)
- 4 байта - хранит размер содержимого служебного идентификатора (в байтах)
- 1 байт - служебный маркер с хз какой задачей, всегда равен 00
- 4 байта - хранит адрес начала описания ДРУГОЙ строки, задача его упоминания непонятна, возможно пустое значение вида 00-00-00-00
- служебный идентификатор, где найти размер строки для его вырезания - упомянуто несколькими пунктами выше <- бесполезный параметр, имхо
- ещё один служебный идентификатор, где найти размер для его вырезания - упомянуто несколькими пунктами выше <- бесполезный параметр, имхо
- <- блок РЕАЛЬНОГО содержимого колонок данной строки таблицы ->
- 4 байта - общий размер ВСЕГО блока, который посвящён данной строке
- 1 байт - служебный маркер с хз какой задачей, всегда равен 02
- 1 байт - хранит длину строки со служебным идентификатором (в байтах)
- 4 байта - хранит размер содержимого строки таблицы (в байтах)
- 1 байт - служебный маркер с хз какой задачей, всегда равен 00
- 4 байта - хранит адрес начала описания ДРУГОЙ строки, задача его упоминания непонятна, возможно пустое значение вида 00-00-00-00
- служебный идентификатор, где найти размер строки для его вырезания - упомянуто несколькими пунктами выше <- бесполезный параметр, имхо
- содержимое строки таблицы, где найти размер для его вырезания - упомянуто несколькими пунктами выше
<-- содержимое строки таблицы: перечисление значений колонок для данной строки, в качестве разделителя между колонками используется маркер в виде байта со значением вида 00 -->
Пример описания одной из строк таблицы (два идущих подряд блока на строку таблицы):
17-00-00-00 02 03 05-00-00-00 00 AF-1E-01-00 09-09-30 63-31-30-30-31
^ ^ ^ ^ ^ ^ ^ ^- содержимое служебного идентификатора ( c1001 )
| | | | | | ^- служебный идентификатор ( \x09-\x09-0 )
| | | | | ^- 4 байта - адрес начала описания ДРУГОЙ строки, задача его упоминания непонятна, возможно пустое значение вида 00-00-00-00
| | | | ^- 1 байт - служебный маркер с хз какой задачей, всегда равен 00
| | | ^- 4 байта - размер содержимого служебного идентификатора, равняется в данном случае: 5 байт
| | ^- 1 байт - длина строки со служебным идентификатором, в данном случае: 3 байта
| ^- 1 байт - служебный маркер с хз какой задачей, всегда равен 02
|
^- общий размер ВСЕГО блока со служебным идентификатором строки таблицы, в данном случае равен 23 байт, что соответствует:
= 5 байт (второй служебный идентификатор)
+ 3 байт (длина строки с первым служебным идентификатором)
+ 15 байт (служебные символы заголовка)
FB-01-00-00 02 05 E7-01-00-00 00 00-00-00-00 63-31-30-30-31 63-31-30-30-31-00-79-00-63-68-72-6E-5F-63-31-30-30-31-00-31-39-31...
^ ^ ^ ^ ^ ^ ^ ^- содержимое колонок данной строки таблицы с разделителями \x00 ( c1001 y chrn_c1001 191003;200102;SKILL_ONLY )
| | | | | | ^- служебный идентификатор ( c1001 )
| | | | | ^- 4 байта - адрес начала описания ДРУГОЙ строки, задача его упоминания непонятна, возможно пустое значение вида 00-00-00-00
| | | | ^- 1 байт - служебный маркер с хз какой задачей, всегда равен 00
| | | ^- 4 байта - размер содержимого строки таблицы, равняется в данном случае: 487 байт
| | ^- 1 байт - длина строки со служебным идентификатором, в данном случае: 5 байт
| ^- 1 байт - служебный маркер с хз какой задачей, всегда равен 02
|
^- общий размер ВСЕГО блока РЕАЛЬНОГО содержимого колонок данной строки таблицы, в данном случае равен 507 байт, что соответствует:
= 487 байт (размер содержимого строки таблицы)
+ 5 байт (длина строки со служебным идентификатором)
+ 15 байт (служебные символы заголовка)
nORb Dragon
18.02.2020, 11:52
Оставлю здесь скрипт по преобразованию уже дешифрованного db-файла в текстовый файлик с разделителями-табуляторами.
Результирующий текстовый файлик можно при желании открыть в Excel. Только при импорте данных необходимо будет проставить всем колонкам принудительное отображение всех данных в виде "текста". Иначе оно поломает часть данных, переведёт их в дату (типа "3 янв") и прочий треш.
Скрипт: 158779
К архиву приложен файлик character_player.test-20200214.db для извращений и экспериментов.
Юзать через python3 epic7_db2txt.py <имя db-файла> <имя файла для результата>
Допустим:
python3 epic7_db2txt.py character_player.test-20200214.db character_player.txt
Есть мысли как автоматизировать поиск ключа под db-файлы, но... это пока мысли. Если удастся реализовать, то соберу скрипт, который будет сразу и декодить файл и преобразовывать его содержимое к текстовому варианту с табуляторами. :think)
nORb Dragon
18.02.2020, 12:55
Оп. Кажется, я случайно нашёл где спрятан ключ дешифровки для db-файлов...
nORb Dragon
20.02.2020, 02:35
Всё. Раскурил, как подобрать ключ под каждый db-файл индивидуально. В следующую "версию" потрошилки впишу, чтоб сразу дешифровала их. И делала дополнительно "альтернативный" текстовый файлик с табуляторами-разделителями колонок.
Из нерешённого вопроса остались файлики со спрайтами: sct/atlas/scsp
Волнует, конечно, больше всего вопрос, что же за формат это такой, sct... :think)
nORb Dragon
20.02.2020, 13:23
Лол. Они там с сегодняшнего патча подробили data.pack на data.pack и data.pack~1
Надо будет поковыряться, разобраться в чём там фишка. Тупо разрезан по 1гб или более замудрёно всё. :think)
nORb Dragon
20.02.2020, 15:31
И наступил тот день, когда я только собрал алгоритм универсальной подборки ключа на основе "мусора" в файлах. А разрабы взяли, и выкинули самый "ценный" для меня блок из файлов. :trololo:
https://forums.goha.ru/showthread.php?p=158321007#post158321007 <- второй блок выкинут. Кажется, теперь после первого блока идёт сразу третий. Чего там с db-файлами - я ещё не разбирался.
Файл data.pack~1 похож на тупое отпиливание от data.pack. Во всяком случае, вариант с ключом от data.pack под него не подходит.
nORb Dragon
20.02.2020, 20:44
Не... второй блок как был мусором, так и остался. Теперь там другой мусор. Не список адресов, на основе которых я лепил ключ к дешифровке файла. Но указание, где находится третий блок, я не нашёл.
Однако, обнаружил, что начало третьего блока в data.pack так и осталось на позиции x01402B. Удивительно. :think) Ковыряюсь, принудительно указал своей потрошилке на эту позицию вместо вычислений.
Указал. Выгрузило несколько файлов и споткнулось. :think) Реально формат перелопатили. Или ключ немножко поменяли... Завтра буду на работе раскуривать, если время будет. :spy:
nORb Dragon
21.02.2020, 14:37
Просто "приклейка" data.pack~1 к data.pack с наложением на него ключа от data.pack не прокатила.
Другой ключ? :think)
Касаемо файликов .db
Глянул на один, вроде формат не поменялся. :cw: Хоть что-то раскуривать заново не придётся.
Раскури как открыть звуковые архивы .bank :think)
nORb Dragon
21.02.2020, 15:41
Раскури как открыть звуковые архивы .bank
В очередь! :|)
Я теперь даже их выпотрошить не могу из нового формата.
Добавлено через 54 минуты
Просто "приклейка" data.pack~1 к data.pack с наложением на него ключа от data.pack не прокатила.
Другой ключ?
Затупил. Надо было сначала склеить, после чего прогонять ключом. Я же отдельно прогнал через ключ data.pack~1, а ключ-то под data.pack нестандартного размера.
В общем, если сначала склеить файл, то нормально дешифруется data.pack.
Теперь надо разобраться с изменениями в структуре хранения данных в нём. :cw:
nORb Dragon
21.02.2020, 19:37
Всё. Потрошилку допилил до нового формата data.pack. Сволочи. Я столько мусора, закинутого СПЕЦИАЛЬНО в пак и засунутого куда попало МЕЖДУ реальными упакованными в этот пак файлами никогда ещё не видел! :mad:
Пришлось воспользоваться доп полем в начале описания файла, где эпизодически идёт линк на другой файл из пака, плюс делать анализ "описания файла", что за данные я именно выгрузил с адреса Х. Сравнивать загруженные "типа" размер всего блока с размером файла, сходятся ли они. И проверяю наличие "правильных значений" в "служебных" маркерах (x02 и x00).
347 "трапов" в data.pack насчитала моя потрошилка! :mad:
nORb Dragon
21.02.2020, 21:56
В общем, очередной вариант скрипта потрошилки на python3 с "ру-комментами внутри". :think)
Исполнять на линухе. На винде возможно взлетит, но это неточно.
Скрипт для скачивания: 158796
Исполнять через команду:
python3 epic7ripper_v2_0.py
Остальные файлы в архиве - обязательные к наличию. Не надо их "выкидывать".
Предварительно, конечно, закидываем в ту же папку файлы data.pack + data.pack~1, которые ещё не были прогнаны через XOR.
Скрипт сам дешифрует файл, после чего начнёт его потрошить. Результат будет сохранён в папку с названием вида YYYYMMDD. В эту же папку будет сохранён дешифрованный вариант data.pack (data_.pack). Сами потом удалите, если он вам будет ненужен.
Лог работы будет сохранён в файл epic7ripper.log, закинут в папку с результатом потрошения.
Выглядеть лог будет как-то так:
Запуск задачи по потрошению /***/20200221/data_.pack.decoded
Результат потрошения будет сохранён в папку по адресу: /***/20200221/
Позиция начала блока с файлами: 0x1402b | 81963
* упоминаемая ссылка на другой файл - адрес на описание другого файла, смысл его упоминания непонятен
** возможно упоминание пропусков непонятных блоков - это скорее всего мусор, цель нахождения в data.pack - неизвестна
Начало |*Ссылка на | Имя вложенного файла | Размер файла | Дешифрован
описания|другой файл| | (в байтах) | (.db)
========|===========|============================= ===========================================|====== ========|===========
0001402b| 00000000 | @patch.attributes | 45 | -
0001407c| 0abb9fef | title/title_manager.db | 2621 | False
00014ae2| 00000000 | title/bg/1st_anniversary_bg.png | 514866 | -
0abb9fef| 00000000 | wnd/bg_change_popup.csb | 4276 | -
00092646| 291eba2f | title/bg/20_valentine_bg.png | 652719 | -
0abbb0cd| 279d9eae | wnd/episode_card.csb | 9132 | -
00131c24| 4f1fb869 | #partion.title.sector_rev | 4 | -
291eba2f| 4b256404 | stagept/m_dreamer_boss_l_skill_02.stg | 2125 | -
0abbd4a0| 00000000 | face/m0625_fu.png | 158113 | -
279d9eae| 4b981d77 | portrait/c5071.sct | 1343382 | -
00131c54| 25f031f1 | title/bg/19_xmas_bg.png | 594517 | -
4f1fb869| 56d583f2 | effect/chain_nature.atlas | 1375 | -
291ec2b4| 6774e147 | stagept/m_dreamer_boss_l_skill_01.stg | 2545 | -
4b256404| 00000000 | effect/ui_soul_burn_use.atlas | 513 | -
0abe3e65| 1553977c | bg/starstreet_2.scsp | 893 | -
27b21e69| 00000000 | camera/spirit_machine_cm_sk3.scsp | 343 | -
4b981d77| 00000000 | effect/grade_legend_in.atlas | 305 | -
001c2ed3| 4b7e5f70 | text/text_en.db | 8071922 | > .txt
25f031f1| 00000000 | particle/bubble_04.sct | 18812 | -
4f1fbdf4| 00000000 | effect/chain_light_acha.sct | 209922 | -
56d583f2| 00000000 | item_arti/art0017_l.jpg | 10126 | -
291eccdd| 31322a21 | stagept/m_dreamer_boss_i_skill_03.stg | 4366 | -
6774e147| 00000000 | skill/pa_c2050_2.png | 5140 | -
4b256635| 00000000 | effect/ui_soul_burn_use.sct | 73614 | -
0abe4209| 1f8e0dcc | face/m0624_su.png | 19231 | -
1553977c| 72b49f65 | banner/ss_v1053a_bi_kr.png | 21303 | -
27b21ff4| 4c3461ef | cut/sk_c1011_s01_3.webp | 761656 | -
4b981ed7| 00000000 | effect/grade_legend_back.sct | 25210 | -
009759e7| //----// | //-------------------- Пропускаем странный блок --------------------// | //--------// |
4b7e5f70| 00000000 | effect/healer_skill_03_hit.sct | 65892 | -
25f07b96| 00000000 | wnd/clan_support_confirm.csb | 11152 | -
(...)
0cb829c8| 36701ea9 | effect/ui_livepvp_soulburn_pati1.particle | 21010 | -
0cb87c16| 29de8f23 | effect/ui_livepvp_vs_eff.atlas | 399 | -
0cb87dd6| 00000000 | effect/ui_livepvp_vs_eff.cfx | 1491 | -
0cb883d8| 173bd0d6 | effect/ui_livepvp_vs_eff.scsp | 791 | -
0cb8871f| 2ddbbf6d | effect/ui_livepvp_vs_eff.sct | 52998 | -
0cb95654| 00000000 | effect/ui_livepvp_vs_eff_pati1.particle | 29323 | -
0cb9c919| 00000000 | effect/ui_livepvp_vs_eff_pati2.particle | 4364 | -
Всего выгружено файлов: 28298
Дальше.
Если моя потрошилка смогла (по её мнению) подобрать ключ к файлу .db, то она автоматически декодирует и этот файл, после чего пытается сразу собрать txt-файл для дальнейшей загрузки в MS Excel (txt-файлы с табуляторами-разделителями). Эти файлы находятся там же, где и первоначальные db-файлы с бонусом в расширении вида .txt
В логе я помечаю, какие db-файлы потрошилка смогла предположительно корректно конвертнуть в последнем столбце. Но... Сами понимаем, что я все эти файлы не проверял и не пересматривал. Потрошилка могла и затупить. И файл мог оказаться другого формата. :trololo:
В общем, развлекайтесь.
nORb Dragon
21.02.2020, 22:48
Ну, типа "спойлеры". Скорее всего уже выкладывали на реддитах. :trololo: Но я тоже выложу, как "доказательство", что потрошилка работает. :smok)
158797 158798 158799 158800 158801 158802 158803 158804 158805
nORb Dragon
22.02.2020, 01:06
М. Таки в выкинутом "мусоре" что-то было... В общем, это пока не окончательная версия потрошилки. :think) Надо придумать, как расковырять "мусор" и достать оттуда нужное.
nORb Dragon
22.02.2020, 02:43
Не придумал ничего лучше, кроме как тупо при "вбегании в мусорный бак" впрыгивать в него и перебирать побайтно в поисках заголовка начала описания нового вложенного файла. :cw: И знаете... Сработало. :trololo:
Конечно процесс замедлился. Но теперь потрошит весь data.pack.
Обновлённый набор скриптов потрошилки: 158806
А что, ТМ Крозед - это таки другой персонаж?
data.pack + data.pack~1
А где ты нашел data.pack~1? У меня только один data.pack на 2,5 гигов :think)
https://i.imgur.com/Wz9n949.png
мой файл (https://drive.google.com/open?id=13oUgIl4Z3HVh239UG7YBEFGyI5WjWFAD) :'(
nORb Dragon
22.02.2020, 16:37
А где ты нашел data.pack~1? У меня только один data.pack на 2,5 гигов
У меня после последнего патча выглядит так:
158808
Единственное, что возможно повлияло на это: я недавно зачищал в ноль кэш игры, когда она не захотела патчеваться. :think) И она заново выкачивала всё. Но для меня формат data.pack изменился кажется именно в последнем обновлении. До этого был единый файл.
Касаемо ошибки - будем смотреть. :think) Интересно, это проблема mmap или локальная для компа. Посмотрим...
nORb Dragon
22.02.2020, 16:44
Аблин. Гугль подтвердил мои подозрения.
Как я и подозревал, mmap помещает весь файл в ОЗУ. Питон - не основной мой язык программирования, множества тонкостей не знаю. :|) Надо будет перепилить работу с огромными файлами. :think)
nORb Dragon
22.02.2020, 17:47
В общем, заливаю твой data.pack себе на сервак линухи. Ещё где-то час заливаться будет. :think) Корректировки в скрипт внёс, чтоб обрабатывал этот огромный файл через буфер ~256мб. Но выкладывать сюда без проверки его на работоспособность не хочу.
nORb Dragon
22.02.2020, 22:13
@Kapes (https://forums.goha.ru/member.php?u=788012)
Ну и толстый у тебя data.pack. И ещё прикол: там дохрена дублей файлов. С разным размером. :think) Мусорка во всей красе. Поди угадай, где "правильные файлы". В итоге моя потрошилка их перезаписывала.
Новая версия скрипта: 158809
Запускать через:
python3 epic7ripper_v2_1.py
Вроде должно у тебя заработать теперь. :think) Но сразу предупреждаю: декодить твои 2.7гб и потрошить будет долго. Много "мусорных" блоков. Надо будет ещё найти время, глянуть в них, действительно ли там остался мусор. Или мне надо подрихтовать анализатор "мусора".
Ну и толстый у тебя data.pack. И ещё прикол: там дохрена дублей файлов. С разным размером. Мусорка во всей красе.Чё корейцы дали, тем и пользуюсь :tonq2)
https://i.imgur.com/z5HmGVx.png
Не пошло :'(
Я переустановил игру, теперь data.pack (https://drive.google.com/file/d/14-MZO3r2DXASVULw5_SFQLfiArklJ3u_/view?usp=sharing) весит 2 гига. Второго файла нет. Ошибка осталась.
nORb Dragon
23.02.2020, 03:15
Ну, теперь затыкается не на mmap, а на BytesIO. :trololo:
Значит он тоже пытается сожрать весь файл в оперативку. :think) Надо переделать и две функции, где на BytesIO сидит у меня. :spy:
nORb Dragon
23.02.2020, 04:36
@Kapes (https://forums.goha.ru/member.php?u=788012)
Попробуй этот вариант: 158811
Вроде избавился от BytesIO. И должен теперь кусками data.pack кушать его, не пытаясь проглотить 2гб. :trololo:
Попробуй этот вариант: epic7ripper_v2_1a.zipОн теперь вообще не стартует, даже ошибок не выдаёт. :dunno:
Пробовал запустить два скрипта.
https://i.imgur.com/WcIfJw1.png
nORb Dragon
23.02.2020, 13:34
Пробовал запустить два скрипта.
Запускать через:
python3 epic7ripper_v2_1.py
:trololo:
Остальные скрипты (с префиксом _ ) - модули, в них нет ничего "запускательного". Там хранятся функции. Стартует весь механизм epic7ripper_v2_1.py
Ахтыж. Забыл приложить его в архив. :|) Ну, он не поменялся с прошлого раза. Ладно, попытка номер два: 158817
nORb Dragon
23.02.2020, 14:05
Хмм. Утром ставил на проверку, но не дождался результата, спать ушёл. Сбойнуло на потрошении твоего старого data.pack :think)
Снова ковыряться. :cw: Где-то видно накосячил с буферами.
Добавлено через 12 минут
Ясн. Таки накосячил с буфером в функции по аккуратной прогонке data.pack через ключ. В общем, жди следующей версии. :trololo: