шрифт в TGA расшифровка/разбор?

ufimez · 18 сентября, 2014

Здравствуйте, прошу подсказать как получить нормально читаемый текст в файле tga

Платформа PS3

Игра Dungeon Defenders

Возникли сложности со шрифтом, мне сказали:

"шрифтов около 10 штук и они едрёные,наложены друг на друга" рябь на картинке

https://cloud.mail.ru/public/f4095838dc6e%2...Large_PageA.tga

что с этим файлом можно сделать и куда копать чтобы получить нормально распозноваемый текст

Изменено 26 сентября, 2014 пользователем ufimez

AwsomeEpicCool · 19 сентября, 2014

в загаловке указан 24битный режм - т.к. шрифты обычно ч\б, значит значения одного пиксела повторяются трижды, что мы и видим (негинтропия для 24бит имеет весьма высокое значение).

далее в заголовке видим тип кодирования 10, это значит, цветовая схема RGB, а сжатие RLE.

Суть методов данного подхода состоит в замене цепочек или серий повторяющихся байтов или их последовательностей на один кодирующий байт и счетчик числа их повторений.
Например:

44 44 44 11 11 11 11 11 01 33 FF 22 22 - исходная последовательность

03 44 04 11 00 03 01 03 FF 02 22 - сжатая последовательность

Первый байт указывает сколько раз нужно повторить следующий байт

Если первый байт равен 00, то затем идет счетчик, показывающий сколько за ним следует неповторяющихся данных.

возможны и друге реализации RLE.

и дейчтвительно, если поглядеть на содержимое в hex (начиная с 13h - 19 символ\байт), то треммы (группы из трех) байт чередуются однобайтовами значениями длинны, а значит сомнений в том, что это именно RLE быть не может, но при декодировании всего этого бреда получается вот такая каша. глядя на эту кашу можно предположть, что данные зашифрованны (не редкий слчай в наше время, особенно для консолей) и учитывая крайнюю избыточность данных в купе с контестом (например, учитывая, что это простая картинка с алфовитом, размера 512на512), видна куча подскзок для расшифроки...

Расшифровка должна осуществлятся с ключем размера кратным 8 бит (судя по всем признакам это и есть 8), т.к. структура файла не повреждена шифрованием (наболее примитивм методом шифрования может быть побайтовый XOR, как в японских играх, а в наиболее сложным - добавляется еще перестановка бит т.к. другие методы будут увиличивать энтропию, что в файле не наблюдается). В результате декодирования (заголовок не зашифрован) должна получится RLE последовательность в которой - сумма произведений повторений суммы пикселей цвета фона (повторяемой) подстроки должна быть велика (в общем фон шрифта) из всех имеющихся (из заголовка имеем, что размер текстуры 512х512=) 262 144 пикселов, по другому - наиболее часто встречатся в конечном изображении, иначе - изображение должно получится с высокой энтропией (в случае подсчета энтропии можно стремится к ее мексимизации исходя из условий задачи, даже на сжатом наборе данных, чтобы не перебирать все варианты, хотя можно подобрать и более сложные\эффективные фильтры). После расшифровки и декодирования RLE количество 24х-битных пикселов должно соответствовать размеру текстуры.

Иначе (в случае безрезультативности достаточно быстрого перебора 8!*2^8=10 321 920 варантов, в простейшем случае 2^8=256 варианов) текстура либо не содержиит шрифта, либо является лишь его частью в избыточной форме кодирования избыточной текстуры шрифта.

Изменено 19 сентября, 2014 пользователем AwsomeEpicCool

AwsomeEpicCool · 20 сентября, 2014

UPD

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

На первом этапе не обязательно брутфорсить все байты изображения (оно и так будет различимо), а можно лишь перебирать ключ для кодирующих байт RLE последовательности.

при перестоновках начать проверу было бы логично с циклических сдвигов (на от 0 до 7 бит в любую одну сторону, всего 8*2^8=2 048 вариантов и останется 5 040 =7! остальных комбинаций этих вариантов из 7 возможных перестановок соответственно)

Изменено 20 сентября, 2014 пользователем AwsomeEpicCool

AwsomeEpicCool · 20 сентября, 2014

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

Thief1987 · 20 сентября, 2014

Мда.

Либо umodel неправильно достал текстуру, либо обычный свизлинг, раз уж речь идет о пс3.

AwsomeEpicCool · 20 сентября, 2014

Thief1987, спокойно, это предусмотрино еще в первом посте, ведь свизлинг и есть перестаовка wikipedia:Swizzling_(computer_graphics)

а как проверить, что там нет искомого я еще там же расписал :)

Кстати, здесь челвек описывает похожий баг с umodel и частично решает его

Изменено 20 сентября, 2014 пользователем AwsomeEpicCool

ufimez · 26 сентября, 2014

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

через winhex открыл файл

00000A00000000000000000000020002180000424242813F3F3F813C3C3C81393939013636363C3C3C813939398136363681323232012F2F2F35353581323232052F2F2F2E2E2E2A2A2A2B2B2B2828282F2F2F812C2C2C812929290325252526262622222235353581323232812F2F2F812C2C2C092929292E2E2E2C2C2C2B2B2B2828282929292626262525252323232929298126262681232323031F1F1F2020201C1C1C23232381202020811C1C1C82000000032727272222222424241F1F1F83000000022121211C1C1C1E1E1E94000000001B1B1B9E000000082727272525252323232020202222221F1F1F1D1D1D0000001D1D1D86000000001C1C1CFF

и запутался в конец, а где в заголовке указано? -