Acoustica Premium Edition

1. 

   Оффлайн

   Teodorrrro

   Звание: Бывалый

   Команда сайта

   Сообщений: 154

   Создано тем: 25

   Рейтинг: 4

   Репа: (12|12|0)

   Баллы: 51

   Страна: не указана!

   Был: 2024-02-25 16:14

   Лайков: 3

   Nexus, потрясающе! Кстати, той же операции скорее всего ждут и остальные...
   
   
   

    Показать / Скрыть текст

   

   Сообщение отредактировал 31 июля 2018 - 12:53
   4 октября 2013 - 13:41 / #11
2. 

   Оффлайн

   Автор темы

   Nexus

   Забанен

   Сообщений: 611

   Создано тем: 20

   Репа: 0

   Баллы: 0

   Был: 2022-07-03 23:07

   Лайков: 7

   teodorrrro, дошла очередь и до твоего перевода Целый файл выставлять не буду, так как там нужно поменять всего лишь один байт(!).
   Открой в WinHex DeClick.dll, по смещению 275CD поменяй 72 на EB. Все.
   Теперь все нужные тебе строки, которые находятся в формате ANSI, переводи в формате UTF-8. Но это касается только строк в ANSI! Строки в Unicode переводи тоже в Юникоде.
   Переведешь и обкатаешь файл - если глюков и багов обнаружено не будет, то дам такие же HEX значения и для других "проблемных" файлов.
   4 октября 2013 - 14:41 / #12
3. 

   Оффлайн

   78Sergey

   Звание: Эксперт

   Мастер

   Сообщений: 508

   Создано тем: 52

   Рейтинг: 6

   Репа: (269|269|0)

   Баллы: 1681

   Страна: не указана!

   Был: 2024-05-09 09:15

   Лайков: 260

   Цитата: Nexus

   Открой в WinHex DeClick.dll, по смещению 275CD поменяй 72 на EB.

   
   
   
   Браво!!!
   
   Немного прокомментирую твое решение. Насколько я понял, данная подпрограмма выполняет преобразование кодировки ANSI в UTF-8 по упрощенному алгоритму. Обрати внимание на предыдущую команду - cmp eax, 80. Шестнадцатеричное число 80h десятичном формате - это 128, т.е. в данном случае основная половина таблицы символов. Символы кириллицы находятся во второй, расширенной половине таблицы.
   
   Итак, команда cmp eax, 80 сравнивает код символа с числом 80. Если код меньше 80 (основная таблица символов), то флаг CF будет установлен в1 и далее будет выполнена команда условного перехода JB на указанный адрес. Если код больше 80 (расширенная таблица символов), то флаг CF устанавливается в 0, а команда условного перехода игнорируется. Таким образом с символами второй половины таблицы выполняются какие-то дополнительные преобразования.
   
   Ты предлагаешь заменить команду условного перехода JB (72h) на безусловный JMP (EBh). Т.е. однозначно и всегда, при обработке строк, определенный участок кода будет пропускаться. Возможно он и не так важен, но мы не знаем, как это отразится на работе самой программы. Я думаю, что более корректным решением будет исправление максимального значения символьных кодов, 128 на 256 (80h на 100h). Т.е. будет обрабатываться вся таблица ASCII. Так, по идее, побочных ошибок быть не должно.
   
   Что нужно сделать? В НЕХ-редакторе по адресу 000275CD байт 72 оставляем без изменений, а корректируем значение 80.
   Число 256 в шестнадцатеричном формате будет 100. Запишем его по байтам - 01 00. Изменим порядок байт на обратный - 00 01. Вот так его и записываем с адреса 000275C9. В моем варианте нужно изменить два байта teodorrrro, если есть есть желание, попробуй сделать так.
   
   Nexus, если не трудно, то хотя бы тезисно расскажи алгоритм работы с отладчиком по нахождению таких мест в исследуемом файле. Это не срочно, как будет время и желание!
   5 октября 2013 - 08:41 / #13
4. 

   Оффлайн

   Teodorrrro

   Звание: Бывалый

   Команда сайта

   Сообщений: 154

   Создано тем: 25

   Рейтинг: 4

   Репа: (12|12|0)

   Баллы: 51

   Страна: не указана!

   Был: 2024-02-25 16:14

   Лайков: 3

   Класс!
   С горем пополам нашел и изменил значение 80, главное - не забывать про UTF-8. Спасибо всем!
   
   Отчет:
   
   
   

    Показать / Скрыть текст

   
   
   
   
   

   Сообщение отредактировал 31 июля 2018 - 12:58
   5 октября 2013 - 09:48 / #14
5. 

   Оффлайн

   Leserg

   Звание: Ветеран

   Команда сайта

   Сообщений: 933

   Создано тем: 79

   Рейтинг: 8

   Репа: (131|131|0)

   Баллы: 1616

   Был: 2024-05-09 15:29

   Лайков: 146

   Цитата: teodorrrro

   С горем пополам нашел и изменил значение 80, главное - не забывать про UTF-8.

   
   
   
   Ты бы мог быстро найти это место, задав в НЕХ-редакторе поиск следующей последовательности байт:53573D800000007265BF01000000 . Она в файлах является уникальной. Если планируешь переводить следующие версии программы, то выполни поиск этой последовательности байт в новой версии программы. Если она повторяется и изменение байт положительно влияет на корректное отображение кириллицы, то можешь сделать патч, например с помощью утилиты diablo2oo2"s Universal Patcher [dUP]. Так ты себе немного облегчишь работу.
   
   Еще рекомендация. Для каждой программы, которую ты переводишь, делай себе пометки проблемных мест и способы их решения. Я, например, записываю в текстовый документ, как нашел, где находится, характерные признаки локации (какие функции или текстовые строки рядом), делаю скриншоты областей НЕХ-кода и участков дизассемблированного листинга в отладчике, какие инструменты применял. Поверь, пройдет пару недель и ты все это забудешь. Придется начинать все заново.
   
   Спасибо Nexus! Еще один мамонт повержен.

   Кто ищет, тот всегда найдет!
   

   5 октября 2013 - 12:48 / #15
6. 

   Оффлайн

   Автор темы

   Nexus

   Забанен

   Сообщений: 611

   Создано тем: 20

   Репа: 0

   Баллы: 0

   Был: 2022-07-03 23:07

   Лайков: 7

   Цитата: Leserg

   Я думаю, что более корректным решением будет исправление максимального значения символьных кодов, 128 на 256 (80h на 100h).

   
   
   
   Эффект один и тот же - запретить выполнение кода за этими значениями, т.е. не пускать туда текстовые строки для обработки. Почему? Потому что дальнейший код за этим оператором предназначен для конвертирования с Юникода в UTF-8 и он НЕРАБОЧИЙ! По сути вся вот эта функция - полная лажа. И вроде код полезный и нужный, если бы не одно "но"... Все дело в операторе MOVZX EAX,BYTE PTR DS:[ECX] и последующим INC ECX. Для конвертирования двухбайтовой кодировки (Юникод, UTF-8, ..) в UTF-8 нужна загрузка в регистр процессора сразу двух байт, а не одного как в этом операторе. Чуть ниже, сразу за этой подпрограммой, находится такая же, аналогичная функция обработки строк в UTF-8, но уже корректно написана. Ну а текущая функция годится только для перемещения байт текстовой строки с одного места памяти в другое. И не более. Все равно на выходе необходимо получить строку в виде UTF-8, как требует программа, значит пускай входная строка и будет написана в UTF-8.
   
   

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

   
   
   Алгоритм? Ну... Нахожу ссылку на проблемную текстовую строку, потом по этой ссылке иду на то место, где хранится это строка, ставлю на ней бряк Memory... и запускаю прогу. В тех местах кода, где строка считывается, отладчик и останавливается. Вот эти места я и анализирую. Бывает в том месте просто подсчитывается длина исходной строки (это место я пропускаю), а бывает считывается первый байт строки в какой-нибудь регистр и, после некоторых манипуляций с этим байтом, пересылается в другое место памяти, обычно это оператор MOV BYTE *** или MOV WORD ***. Смотрю куда оно пересылает и ставлю там тоже бряк. Вот так и скачу по брякам, пока не найду то место, где портится строка.
   А что у тебя за отладчик? И вроде Олька, но как-то не особо похоже...
   5 октября 2013 - 14:48 / #16