NeatVideo это мощный и гибкий шумоподавитель для различных видеоматериалов.
Позволяет:
[li] строить профили под данное конкретное устройство, чтобы максимально эффективно удалять шум;
[li] настраивать уровни реакции подавления шума на различных частотах;
[li] раздельно настраивать уровни подавления шума в Y, Cr, Cb каналах (или RGB, на выбор).
[li] применять фильтр детализации совместно с профилем шума.

Что имеем:
1) Жестко-закодированные строки;
2) Разную кодировку строк (ANSI, UTF-8).

Инструменты:
1) Radialix совместно с дизассемблером IDA для перевода ЖЗС;
2) НЕХ-редактор (WinHEX) для исправления файла и модификации кода.

Для перевода используется вылеченный от жадности файл плагина NeatVideo.vdf.
 

После создания локализованного файла плагина в Radialix`e, необходимо в НЕХ-редакторе сделать небольшое исправление, иначе плагин не работает. В оригинальном файле в самом конце стоит байт С3:

А после перевода в Radialix`e этого байтика нет.

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

Врагу не сдается наш гордый "Варяг" (плагин)!
Продолжаем воевать с плагином. После недавней эпопеи на параллельной ветке форума, где товарищем Nexus было найдено решение по отображению кириллицы в меню плагина:

Цитата: NexusЧто нужно сделать? Для нормального отображения букв в МЕНЮ нужно файл открыть в HEX редакторе и по смещению 0FCBCF вместо 00 вбить 01. Это команда ассемблера PUSH 01 (6A 01). Для нормального отображения слова %n frame(s) (Конфигурация фильтра - вначале) нужно по смещению FCC07 заменить 0 на 1. Ну то же самое и такая же самая команда. Может где-то еще какая гадость выскочит, незнаю, не тестировал - если что, то пишите. Слегка запарился с делами, поэтому пока не до переводов.

данная проблема не ушла совсем. В некоторых строках и сообщениях плагина кириллица так и не отображается. Причем, в одном случае все нормально (кодировка windows-1251), а в другом кракозябры.
Вот, например, надпись "радиус" (radius):
А вот сообщение
Английский вариант сообщения выше
Другое переведенное сообщение отображается нормально (кодировка windows-1251)
Nexus, снова требуется твоя помощь. Какие теперь байты искать надо? Если бы ты рассказал принцип, то может быть я и сам бы справился. А так не совсем понятно, что искать надо.

Я глянул ассемблерный код по указанным тобой смещениям, где команду PUSH 0 меняем на PUSH 1, но пока у меня никаких мыслей по этому поводу.
 

Скопировал сообщение в эту ветку

Цитата: NexusПривет! Sorry за долгое отсутствие - понедельник же... Что до плагина и описания его взлома - ох... Я и сам толком не разобрался в механизме подмены кодировки (или что там это было). Механизм такой - прога считывает, к примеру, &File, потом вызывает подпрограмму, где идет туева хуча математически-логических операций (в которых я так и не разобрался), где нет ни одно API функции и не за что зацепиться, пока все не доходит до API функции KERNEL32 HeapAlloc, которая размещает в памяти уже переведенное в Юникод слово. Причем эта подпрограмма общая и для переводимых, и для непереводимых (крякозябнутых) слов. Но вот между местом, где берется непереводимое слово и подпрогой МатЛог операций есть маааленькая промежуточная подрограммулечка, байт на сорок, где и находится эта PUSH 0. Видимо это какой-то флаг, который устанавливает "использовать или не использовать символы кодовой страницы по умолчанию". Между нормально переводимыми словами такой подпроги нет. Там просто считывается слово (то есть на стек ложится адрес слова), название окна, куда это слово лепить, потом 4 байта какого-то мусора (для каждого слова разное) и, наконец, нужные нам 4 байта. Это флаги, для нормального перевода там будет 00000001, а для кряков 00000000.
Короче, я проследил все это дело в трассировке и нашел где обнуляется стек. Это все нужно показывать на скринах, на словах это трудно подять, да и не все поймут. Вон, даже на cracklab не смогли хотябы чем помочь, в ступор загнал своим вопросом. И похоже это или невнимательность программеров, или такой компилятор. В моих же проблемных проектах немного по другому, но принцип тот же, поэтому думаю что плагин - единичный случай.

Только я через Ольку... Видишь чуть ниже переход на подпрограмму CALL 101083B0? То подпрограмма размещения слов в памяти. Так вот, смотришь откуда приходят вызовы на  101083B0, их та вроде штук 20, и все идут с вот таких маленьких подпрограмм, где находится PUSH 0 (несколько идут без них).
 

Ого IDA выдала 333 обращения к этой подпрограмме. Попробую посмотреть...
 

Мда.. Может адресация у нас разная? Ща посмотрю...
О Боже! Да там переходов туча! Давай так, Моска не сразу строилась, я завтра еще гляну и отпишусь.Добавлено (05.02.2013, 16:30:40)
---------------------------------------------
Пока дело в тупике... Даже не знаю что и искать. Пока известно одно - все непереводящиися предложения обрабатываются одной подпрограммой. Буду ковыряться там.
 

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

Трехстрочное сообщение, как и слово ", radius:", и как предложение на начальном зеленом фоне "This is a craced NeadVideo" обрабатывается подпрогой, которая не допускает русские символы. Находится она по адресу 100EB900. И тоже туда куча переходов дет.
 

Цитата: Nexusобрабатывается подпрогой, которая не допускает русские символы.

Вот зараза какая! Тогда других вариантов нет как оставить на английском. Nexus, большое спасибо за помощь.
 

Подожди еще... Там еще байда со шрифтами - MS Shell Dll 2, что то сильно подозрительно кое-что напоминает. Еще поковыряюсь и отпишусь...Добавлено (07.02.2013, 16:48:52)
---------------------------------------------
Leserg, можешь назвать какие строки переводятся именно в 1251 кодировке, а не в UTF-8? Там видимо нужно дописывать кусок своего кода. Почти у цели, но еще поковыряюсь...
 

Цитата: NexusLeserg, можешь назвать какие строки переводятся именно в 1251 кодировке, а не в UTF-8?

Что ты имеешь в виду? Пока в проекте переведено 457 строк. Из них 65 в кодировке windows-1251, остальные - UTF-8. Те строки, что в кодировке windows-1251, часть отображается корректно, часть нет (кракозябры). В основном это строки, которые формируют сообщения различного характера (некоторые я указывал выше). Многие из этих сообщений я не могу получить при работе с плагином, поэтому не могу точно знать, какая там должна быть кодировка и верно ли отображается перевод.



Вот еще раз пример сообщения (корректный вид сообщения нарисован в графическом редакторе):


 

Цитата: Quote77Из них 65 в кодировке windows-1251, остальные - UTF-8

Судя по коду, прога делит сообщения на UNICODE и UTF-8. Причем, UTF-8 она переводит все равно в Юникод. Она даже не задействует ни одной кодовой таблицы! Даже кодовую талицу по умолчанию не использует. Как ты можешь переводить в 1251 и отображается нормально?! Это просто невозможно! Или Радиаликс пишет на экране одно, а все переганяет в другое, я ведь шаблонником не пользуюсь, поэтому и не знаю... В любом случае я уже близко у цели, PUSH 0 - это просто флаг разветвления подпрограмм. Стоит 0 - сообщение уходит на обработку подпрограммы, которая игнорирует UTF-8 символы. Например, File по-русски Файл в UTF-8 HEX пишется как D0A4D0B0D0B9D0BB, подпрога же тупо вставляет в памяти между ними нули - D000A400D000B000D000B900D000BB и получается белиберда. Стоит PUSH 1 - уходит сообщение на подпрограмму трансформации UTF-8 в UNICODE. Сейчас и занимаюсь переносом этого куска кода куда нужно.
 

Цитата: NexusКак ты можешь переводить в 1251 и отображается нормально?!

Но так и есть! Radialix работает верно (как показывает так и делает). Вот смотри в НЕХ-редакторе, часть секции с переведенными строками, которые добавил Radialix. Согласно выбранным установкам кодировок для строк, они так и записаны.


 

Ха! Значит я ошибся! Просто этот кусок кода не увидел. Я то думал что нужно строки переводить с UTF-8 в Юникод. А тут, оказывается, еще берется кодстраница по умолчанию. Ну так это совсем другое дело! Вбивай некорректные строки не в UTF-8, а в 1251 кодировке. А в самом файле нужны вот такие очередные изменения :
По смещению 00 0E AD 46 поменять E8 B5 52 FF FF на E8 05 74 FF FF
Это CALL 100E0C00 меняется на CALL 100E2D50.
CALL 100E0C00 просто встраивает между символами нули, например, A1 A2 A3 - будет A1 00 A2 00 A3 00. Ну а в Юникоде такое содержание знаете как будет отображаться...
CALL 100E2D50 уже использует API функцию MultiByteToWideChar, где перед ним устанавливается флаг "Использовать кодовую страницу по умолчанию CP_ACP". Вот она и нужна была.
Нужно еще плагин тестить, может где бока вылезут.