Авторизация / Register

[nORb Dragon]

Ссылки на полезные ресурсы:

Публичный архив изменений по датамайну на «E7 Vault»

Ссылки на полезные посты:

потрошилки пакетов/архивов:

data.pack (скрипты на python) - https://forums.goha.ru/showthread.ph...#post159273387 (версия 2.7 от 2021.12.02)

*.bank (скрипты на python, только под Windows) - https://forums.goha.ru/showthread.ph...#post159275908

описание потрошения звуковых файлов (.bank) - https://forums.goha.ru/showthread.ph...#post158649085

конверсия формата файлов:

db-файл в csv-формат (скрипты на python) - https://forums.goha.ru/showthread.ph...#post159274578

(ВНИМАНИЕ! поддерживается пока только старый формат, использовавшийся до патча от 2021.06.10)

scsp-файл в json-формат (скрипты на python) - https://forums.goha.ru/showthread.ph...#post159272975

(ВНИМАНИЕ! поддерживается пока только старый формат, использовавшийся до патча от 2021.06.10)

Если у кого есть мысли, идеи, предложения или даже конкретные "программные продукты" для датамайна Epic Seven - пишем, не стесняемся. Открытый код - приветствуется!

В случае, если есть что обсудить со мной, но лень регистрироваться на гохе, меня можно найти и на reddit: /u/nORbDragon

[някавайня]

https://www.reddit.com/r/EpicSeven/c...assorted_dump/

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

[nORb Dragon]

Реддит - это свалка, где только изрядно покопавшись можно найти что-то ценное. Нет времени глубоко и уныло копаться, поэтому и спрашиваю.

Пойду чекну линк.

Добавлено через 8 минут
Глянул линк. Бесполезная инфа, которую я уже знал.

Основное, что меня интересует:
- как нормально перекачать весь клиент игры с эмуля на комп, на примере Nox/Memu/LDPlayer (для дальнейших махинаций над декодингом на компе);
- чёткое указание, в каком файле и на какой позиции находится ключ для расшифровки других файлов;
- в чём в итоге запаковано всё (zip, java, ещё какой треш), чем именно распаковывать после дешифровки.

[някавайня]

Originally Posted by nORb Dragon:

Реддит - это свалка, где только изрядно покопавшись можно найти что-то ценное. Нет времени глубоко и уныло копаться, поэтому и спрашиваю.

Пойду чекну линк.

Добавлено через 8 минут
Глянул линк. Бесполезная инфа, которую я уже знал.

Основное, что меня интересует:
- как нормально перекачать весь клиент игры с эмуля на комп, на примере Nox/Memu/LDPlayer (для дальнейших махинаций над декодингом на компе);
- чёткое указание, в каком файле и на какой позиции находится ключ для расшифровки других файлов;
- в чём в итоге запаковано всё (zip, java, ещё какой треш), чем именно распаковывать после дешифровки.

в ноксе есть какая то встроенная прога туда заходишь там собственно кучина папок(аля как в андройде) именно туда я закачивал анцензор пак по дестини чайлд возможно оттуда можно перекачать .

[nORb Dragon]

Апну темку. ЭТО НЕ НЕКРОПОСТ! Ну, почти.

Originally Posted by Kapes:

https://www.reddit.com/r/EpicSeven/c...ine_e7_assets/
Про дата майнинг и распаковку ресурсов.

В общем, поковырялся я немножко сегодня, раскуривая написанное по ссылке.

Предупреждать о том, что в EULA что-то там мелькает и намекает про "нельзя датамайнить", упоминать не буду. Подозреваю, что это скорее угроза для тех, кто попробует использовать результаты "майнинга" в своей "коммерческой деятельности" (клип-арты и т.д.) или начнёт модифицировать клиент.

Про "технические моменты" рассказывать пока не буду. Предложенное там: азы XOR, указание ключа и способ найти что-то интересное в файле data.pack.

Это всё: базовая информация, которой мне так реально нехватало год назад.

На основе этой инфы, я смогу для себя накидать:

• динамический поиск нового ключа для XOR, если креативы решат его внезапно поменять для data.pack, но саму структуру файла менять не будут;
• выгрузку ВСЕХ вложенных в data.pack файлов (не только png);
• автоматизировать весь этот процесс до "нажатия одной кнопки".

Я не знаю, почему там в темке на reddit пугают народ огромными объёмами. На первый взгляд, png-файлы там непожаты. Насчёт остальных файлов - хз. Углублённо реализовывать это дело буду в свободное от работы время на работе.


Из самого главного, что уже нащупал, и о чём нет инфы в той темке. Но я благодарен написанному там, ибо без той инфы о используемом ключе 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.

PHP Code:

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. Мне не нравится BA 02 00 00. Надо будет присмотреться, что с ним не так.

[nORb Dragon]

Поглядел на свежую голову.

В общем, маркер окончания записанного потока файла может быть как B3-02-00-00, так и 00-00-00-00. В чём разница? Без понятия.

Смущавшие меня байты вида BA-02-00-00 - это последние четыре байта содержимого файлов, а не маркер окончания.

Так как этот маркер окончания записанного потока можно не анализировать, а тупо скипать бесполезные 4 байта, то думаю просто закрывать глаза на их содержимое.

Ещё раз упоминаю, что это всё мой теорикрафт. Ковыряться в этом, писать программку по "распилу" data.pack на файлики буду на следующей неделе. Дома на ПК у меня ничего не стоит из нужного.

[Kapes]

Originally Posted by nORb Dragon:

автоматизировать весь этот процесс до "нажатия одной кнопки".

Помню раньше юзали скрипт на bms, но в новой версии игры не пашет. Вдруг поможет в разработке.

[nORb Dragon]

На своём линух-сервачке от нечего делать написал щаз потрошилку data.pack. Достал оттуда ВСЕ файлы (29.536). Другое дело, что возможно куча из них ещё дополнительно зашифрованы.

Распотрошил где-то за полторы минуты.

[nORb Dragon]

В общем, много клипарта и т.д. Аккуратно распихано по папкам и подпапкам. Но то, что меня интересует, кажется содержится в неизвестного мне формата файлах.

Может кто в теме, чем открываются .atlas, .scsp, .sct файлы? Кажется, что именно там спрятано нужное мне.

Архив для экспериментов - portrait.zip



Ну и так, что в глаза бросилось.

Артефакт, которого я не видел в игре:



Значок сета, которого нет в игре (и я хз как его понимать, ибо вамп и НР сеты есть):



Сценка, которую я не видел вроде.



Карта рейд-лабиринта.



Ну и Басар ждёт ваших кристаллов.

[nORb Dragon]

В общем, если кто хочет поиграться с датамайном. Или поделиться на реддите, вдруг кому там будет интересно. Ну или побыть К.О., если там уже и до такой степени раскурил народ, но мы этих тем не видели.

Вот что я набросал сегодня: epic7ripper.zip

Это - скрипт под python3. Предполагаемое место выполнения: linux. Под виндой не факт, что "взлетит", надо скорее всего допиливать "напильником". Но мне лень.

Для работы необходимо наличие на линухе питона третьей версии и уже подготовленного ранее файлика data.pack . Под "подготовленностью" подразумеваю, что его уже прогнали через XOR. Инструкция со скриптом на питоне находится на реддите в темке по ссылке (см. Step 1, Step 2) - https://www.reddit.com/r/EpicSeven/c...ine_e7_assets/

Выполнять мой скрипт через команду:

Code:

python3 epic7ripper.py

Результаты выполнения будут сохранены:
- лог со списком "выпотрошенного" в файл epic7ripper.log
- сами "выпотрошенные" файлы будут вкинуты в папку от сегодняшнего числа (допустим: 20200209).

Не буду удивлён, если часть файлов (допустим те же .db) дополнительно зашифрованы и/или запакованы. Поэтому и решил поделиться скриптом, чтоб ускорить процесс "раскуривания". Да и может кто там сообразит, как открыть файлы с расширением .atlas, .scsp, .sct

Если вкинете на реддите этот скрипт, рекомендую моё имя не упоминать там всуе. Не хочу быть забаненным в игре за минутную шалость.

Переводить на великий и могучий английский я комменты в скрипте конечно же не буду. Пущай страдают!

[Kapes]

Originally Posted by nORb Dragon:

Может кто в теме, чем открываются .atlas, .scsp, .sct файлы?

Где-то была база по игре со всеми анимациями персонажей, там полюбому знают как открыть. Вот только ссылку на сайт не могу найти

Добавлено через 16 минут
Нашел.
https://e7herder.com/tools/model-viewer
Там слева вводишь имя персонажа и получает анимации.
С автором можно связаться через гитхаб или реддит.

[nORb Dragon]

Немножко допилил напильником скрипт. Вписал в него дешифровщик (xor) data.pack. Теперь достаточно будет снять с эмуля файл data.pack, закинуть его в папку со скриптом и запустить скрипт без всяких лишних манипуляций.

Конечно, процесс дешифровки довольно долгий, если чего.

Дешифрованный data.pack закинет в созданную папку от сегодняшнего числа вместе с результатом потрошения.

Новая версия скрипта: epic7ripper_v1_1.zip

[nORb Dragon]

Файлики .pigz упакованы в gzip, если кого волновал этот вопрос.

[nORb Dragon]

Наброски того, что из себя представляют .pack файлы у Epic7. Скорее для себя, чтоб не забыть.

PHP Code:

первые 5 байт файла - сигнатура, значение равно: PLPcK
1 байт с версией (?), обычно значение равно: 01

<-- первый блок файла -->
4 байта, в которых хранится адрес начала второго блока файла
(... непонятный набор байтов первого блока)

<-- второй блок файла, адрес его начала упомянут выше -->
4 байта, хранят общий размер ВСЕГО второго блока файла
(... непонятный набор байтов второго блока)

<-- третий блок файла, адрес его начала вычисляется на основе стартовой позиции второго блока + размер второго блока -->
(список файлов) 


Хотелось бы понять, что спрятано/описано в первом и втором блоках.

Описание формата списка файлов я уже упоминал ранее, найти можно по ссылке - https://forums.goha.ru/showthread.ph...#post158315163

Осталось теперь понять, где спрятаны ключи для дешифрования .db файлов. И как расковырять файлы спрайтов .sct.

Есть мысль, что они дополнительно ещё и запакованы, но не могу на глаз определить использованный алгоритм.

Вообще, нагуглил, что .atlas и .scsp - это результат работы с программой 2d анимации Spine - http://esotericsoftware.com/spine-texture-packer

Но не могу разобраться с sct-файликами. И да, это не Scitex CT, судя по результам моих экспериментов. Или он как-то странно упакован.



Теперь касаемо

Originally Posted by Kapes:

С автором можно связаться через гитхаб или реддит.

Я думаю, что если бы он хотел поделиться инфой о датамайне, он бы ею давно поделился.

Все его посты: это предложение оценить результат его работы по датамайну (тот же сайт) и/или сообщить ему об ошибках.

В общем, даже пытаться не буду с ним выходить на связь. Меня нет ни на реддите, ни на гитхабе.

[nORb Dragon]

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

Второй блок имеет вид:

PHP Code:

1 байт - служебный маркер, вроде всегда равен 01

<- список ссылок, имеющих вид: ->
1 байт - служебный маркер, всегда равен 00
4 байта, в которых хранится адрес начала описания вложенного файла 


Кстати, в 4 байтах с адресом может значиться 00-00-00-00. Фича мб. Их надо скипать.

Осталось раскурить, за что отвечает первый блок.

[nORb Dragon]

Возвращаясь к блоку с файлами, их описанию.

Originally Posted by nORb Dragon:

^- 4 байта - служебный маркер с хз какой задачей, часто содержит всякую ересь

Перебрал дохрена вариантов, что это. Не похоже на CRC, не похоже на ключ дешифровки...

Ради интереса попробовал посмотреть, что если заюзать это значение в качестве позиции в файле, и... таки да, это ссылки на другие файлы. Вопрос: зачем? Ответа на этот вопрос у меня нет.

Вскрываются ли .scsp и .sct файлы программкой Spine - не в курсе. Ибо программка платная, триал версия не даёт возможности заюзать нужный мне функционал. Хотя... надо будет проверить, наверняка существует "торрент-эдишен"? А то платить за ПО, которое мне не поможет... я уже давно перешёл в категорию "я не настолько богат".

Чем вскрыть файлики .db я тоже так и не разобрался.

В общем, мои силы на "соло мозговой штурм" закончились. Кажется, пора отрихтовать немножко скрипт потрошилки, мб "перевести" комменты на анл, и закинуть этот скрипт + волнующие меня файлы под "анонимом" на реддит. С предложением раскурить вместе, как эти файлы можно вскрыть.


Следующий этап: соберу наверн отдельный скрипт для сравнения результатов датамайнов от разных дат для поиска новых/изменённых файлов. Чтоб ручками не сравнивать.

[nORb Dragon]

Предположительно, окончательный вариант скрипта потрошилки на python3 с "ру-комментами внутри".

Исполнять на линухе. На винде скорее всего не взлетит.

Скрипт для скачивания: epic7ripper_v1_2.zip

Исполнять через команду:

PHP Code:

python3 epic7ripper_v1_2.py 


Предварительно, конечно, закидываем в ту же папку файл data.pack, который ещё не был прогнан через XOR.

Скрипт сам дешифрует файл, после чего начнёт его потрошить. Результат будет сохранён в папку с названием вида YYYYMMDD. В эту же папку будет сохранён дешифрованный вариант data.pack.

Лог работы будет сохранён в файл epic7ripper.log.

Выглядеть лог будет как-то так:

PHP Code:

Готовимся к дешифрованию, копируем содержимое файла 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]

Оп. Кажется в куче комментов на реддите я таки нашёл нужную мне инфу на расшифровку db-файлов. Щаз ковыряюсь, подбираю xor-ключ методом научного тыка... Надеюсь, что он подойдёт ко всем db-файлам.

[nORb Dragon]

Как йа задолбался... Но я таки сделалЪ. Смог собрать ключ к одному из db-файлов на основе... млять, вот этого - https://pastebin.com/DY0db2D2 Четыре часа угробил!

Кому интересно, оригинальный зашифрованный файл и уже дешифрованный мною на основе "подсказки" можно забрать по ссылке, в архиве: character_player.zip

И да, я этот подобранный ключик прогнал по поиску в data.pack. Нашёл его упоминание в файлике text/text_en.db Видно там спрятаны ключи к остальным db-файлам. Надо будет поковыряться, попотрошить его. Не, показалосЪ.

Касаемо же формата данных в дешифрованном db-файлике: пока не ковырялся. Но по ходу ковыряния над ключом обратил внимание на наличие маркеров колонок. Думаю, там табличные данные. В анализ формата не углублялся ещё.

[Kapes]

Originally Posted by nORb Dragon:

надо будет проверить, наверняка существует "торрент-эдишен"?

Я не нашел. Странно, что никто не взломал.

Originally Posted by nORb Dragon:

На винде скорее всего не взлетит.

Надо всего лишь установить питон и пойдет

[nORb Dragon]

Я просто хз, не заглючит ли питон под виндой при юзании в пути обратного слеша.

[nORb Dragon]

Разобрался со структурой db-файлов. Универсальный конвертер их в текстовые файлы с табулятором-разделителем собрал. Но проблема с тем, что надо к каждому такому db-файлу индивидуально подбирать xor-ключ - осталась.

Если кому любопытно, содержание файла character_player.db, приведённое к табличке экселя: character_player.zip

Так как db-файлов много, а подбирать подходящий ключ к каждому из них я не буду. Лень.

Если кто считает, что в каком-то из db-файлов находится ОЧЕНЬ важная и полезная инфа - тыкните в него пальцем. Мб поковыряюсь над ним, подберу к нему xor-ключ.

PS: забыл приложить сам текстовый файл с табуляторами - character_player.test-20200217.db.txt.zip

[nORb Dragon]

Накидал мозгодробительное описание формата .db для тех, кто постарше и любит ковыряться во всякой хрени.

PHP Code:

Файл .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]

Оставлю здесь скрипт по преобразованию уже дешифрованного db-файла в текстовый файлик с разделителями-табуляторами.

Результирующий текстовый файлик можно при желании открыть в Excel. Только при импорте данных необходимо будет проставить всем колонкам принудительное отображение всех данных в виде "текста". Иначе оно поломает часть данных, переведёт их в дату (типа "3 янв") и прочий треш.

Скрипт: epic7_db2txt.zip

К архиву приложен файлик character_player.test-20200214.db для извращений и экспериментов.

Юзать через python3 epic7_db2txt.py <имя db-файла> <имя файла для результата>

Допустим:

PHP Code:

python3 epic7_db2txt.py character_player.test-20200214.db character_player.txt 


Есть мысли как автоматизировать поиск ключа под db-файлы, но... это пока мысли. Если удастся реализовать, то соберу скрипт, который будет сразу и декодить файл и преобразовывать его содержимое к текстовому варианту с табуляторами.

[nORb Dragon]

Оп. Кажется, я случайно нашёл где спрятан ключ дешифровки для db-файлов...