[AlaSToR]

Потому что это редиректы. Сейчас проблем для созданий патчей практически нету. А вот раньше приходилось очень сильно извращаться. Команды bl/blx (да и вообще команды в асме) - имеют ограничения. Так например, команда mov может записывать число от нуля до 255 (0..$FF). Команды переходов b/bne/beq и т.д. имеют тоже свое ограничение - длина перехода. А также и bl/blx не может вызывать функцию, которая находится на длине, превышающей ограничение. Чтобы этого избежать, создаются редиректы. Т.е. вызывая в коде функцию, которая находится на расстоянии, превышающем ограничение - BinEdit создает редирект. Т.е. вызывается уже не my_function (что вызывали вы в коде), а ее редирект, т.е. получается так сказать вызов совсем другой функции, скажем - j_my_function, которая уже описывается в основном после патче, или если указана директива .orgbl - то в месте, где указана эта директива. Конструкция редиректа такова: Вот такая вот нехитрая конструкция и позволяет вызывать функции, находящиеся на любом расстоянии. А также перед редиректами - у тебя находяся данные для загрузки командой ldr, а т.е. gv_backlight. От этого никуда не деться. Если от редиректов можно избавиться, то от данных - нет. А насчет первого блока вопросов - я ничерта не понял, что где и как. И не я один

Урок №6 - Данные. Вот выкроил еще немножко времени на следующий урок. Начну я данный урок с портирования патча. Особенность данного патча в том, что здесь нужно лишь найти опять - только эквиваленты. Но теперь у нас придется заменить не только стартовый адрес, но еще и значение в поле to. А в конечном варианте, патч выходит с абслютно тремя разными между прошивками значения полей, но одинаковые по смыслу. А портировать мы будем патчик все с того же D900XEFK2 на G600XEGL1. В прицнипе различий толком нет, на какой телефон портировать - смысл в принципе один и тот же. Итак, начнем. Вспоминаем урок №5, где мы учились открывать одновременно две прошивочки. Следовательно, открываем BinEdit, в нем открываем прошивку D900XEFK2, затем открываем связанную прошивку - G600XEGL1, отключаем синхронизацию. Ну, вообщем, Вы должны помнить это. Для начала - начнем с простого. На сегодня наш патчик - это Исправить Bluetooth по горячей клавише. Довольно простой патчик, на самом деле, не правда ли? В данном уроке, мы начнем уже с Вами пытаться отличать уже на глаз - данные от мсс-скриптов? Что, не понятно? И не удивительно =) Итак, рассказывать суть данного патча. В телефоне есть таблица адресов функций (не стоит этого бояться, сейчас все подробно объясню). Вспомните - настройку меню пользователя, допустим. В ней есть строго определенные функции. А также - есть настройка функций клавиш на джойстик (влево, вправо, вниз) (замечу - на очень старых телефонах этого может и не быть, но даже на D600 это уже было) - и тут тоже есть те же самые функции. Так вот, установили мы допустим функцию на клавишу ВНИЗ любую из списка. Как при этом срабатывает телефон? У каждой функции есть свой адрес. Адрес - это 4 байта. И что - чтобы запомнить, какая функция у нас стоит на той или иной клавише - в EEPROMe тратить целых 4 байта? Посчитаем. Чтобы запомнить 3 функции, т.е. по функции на 3 кнопки - нам понадобится 12 байт (4 байта [1 функция] * 3 кнопки). А есть альтернативный способ решения - мы сохраним номер функции в EEPROM для каждой кнопки. Вместимость одного байта (0xFF) = 255. Т.е. если у нас функций меньше 255, мы можем взять номер функции, сохранить его в EEPROM, тем самым заняв всего лишь 3 байта в EEPROMe (1 байт [номер функции] * 1 кнопку). Так телефон и поступает. А потом, когда мы нажимаем на кнопку, телефон производит следующие действия: 1) Получаем номер функции ; 2) Умножаем его 4 (сейчас поймете зачем) (назовем получившееся число - числом Z) ; 3) В прошивке записана таблица функций, поэтому берем указатель на начало таблицы ; 4) Сдвигаем указатель на число Z ; 5) И по получившемуся адресу - забираем функцию. Непонятно? Объясняю наглядно. Вот наша таблица (обычный массив), выглядит примерно следующим образом: { 1:Главное меню ; 2:Меню Bluetooth ; 3:MP3-плеер ; и т.д. } Я описал три ячейки адресов, размер каждой ячейки получается сколько? Раз это адрес, значит 4 байта. Проанализируем работу телефона. В настройках мы выбрали функцию под номером 1, т.е. "Главное меню". В телефоне отсчет происходит с какого числа? С нуля. Поэтому на самом деле, эта функция имеет номер не 1, а 0. Итак, пошагово. 1) Получили мы номер функции. Это 0. 2) Умножаем его на 4, т.е. на размер ячейки. Получается, что Z = 0. 3) Получаем указатель на таблицу, сдвигаем указатель на число Z, и получаем адрес, записанный в нашу ячейку. Т.е. Указатель никуда не сдвинулся, он остался на месте (т.е. что будет с числом, если к нему прибавить 0? Оно и останется таким же). 4) Ну и забрали функцию с нулевой ячейки, а т.е. - Главное меню. А если мы выберем функцию - Меню Bluetooth? То что будет записано в EEPROM? Функция Bluetooth для нас имеет номер 2, но на самом деле - телефон запишет в EEPROM - 1. 1) Получими номер функциию. Это 1. 2) Умножили на 4 -> Z = 4. 3) Получиил указатель на таблицу, сдвинули его на 4 байта, а т.е. на 1 ячейку, следовательно указатель стоит на том адресе, где написана функция Меню Bluetooth, получаем ее и переходим в нее. Прикольно, не правда ли? А самое главное, мы сэкономили целых 9 байт в EEPROMe! Надеюсь, Вы поняли, как выглядит этот процесс, вернемся к нашему патчу. Мы ставим функцию Bluetooth на кнопку, а при ее нажатии - открывается что? Меню Мои устройства. Что нам нужно делать в данном случае? Нам нужно найти эту таблицу. Но для начала - мы откроем наш патч, и я покажу очень частую ошибку начинающих патчмейкеров. Открыли наш патч, смотрим: <nord offset="0x0199FE80" from="4C252D11" to="3C486A10" /> Мы берем данные 4C252D11, вставляем в D900XEFK2 - поиск нам выдает аж целых 6 адресов! Ну значит дело хорошо, вставляем эти данные в G600XEGL1 - и.. Ой.. а почему ничего не находит? Поясню. Взгляните внимательно - на те данные, что лежали в прошивке, и на те - что мы изменили? Ничего они Вам не напоминают? Вспоминаем, база у D900 - 0x1. Смотрим - патч изменяет 4 байта. Берем данные из поля - from: 4C252D11. Еще раз приглядываемся: 4C 25 2D 11. А если здесь записано просто число в формате LittleEndian (т.е. перевернутое)? Давайте проверим эту теорию. Переворачиваем, 4C 25 2D 11 -> 11 2D 25 4C, т.е. получился адрес 112D254C. Входит он в пределы прошивки D900? Входит, т.е. прошивка начинается с базового адреса, 0x1 -> 0x10000000, заканчивается приблизительно на ~11A00000. Кто-то доходит до него, кто-то нет, но не суть. Входит число 112D254C в диапозон от 10000000 до 11A00000? Входит. Поэтому вставляем данный адрес, и переходим по нему.. Если Вы никуда не лазили, то Вы должны находится на вкладке HEX. Будучи более опытными, вы заметите приблизительно одинаковые строки. На самом деле, здесь записаны самые обычные мсс-скрипты, и поэтому для более приятного их интерпретирования, переходим на вкладку МСС в левой части BinEdit. Опа, что тут у нас? Таск, потом подготовка окна, потом опять таск.. Вообщем, это адрес менюшки Мои устройства. Теперь, нам нужно найти такой же адрес на G600. Первым делом, есть заветная кнопочка - Найти аналогичный код в BinEdit. Замечательная кнопочка, но так как это все-таки программа, а не человеческий мозг - поэтому ей до него - далеко. Но все же попробуем ее нажать. А находится она тут: Действия -> Связанный Bin -> Найти аналогичный код. Что нам программка отвечает? Не удается найти аналогичный код. Ну это и к лучшему, так как все нужно делать - руками, а не халявить, следовательно поэтому - поехали копать прошивку Задача наша на данный момент - такова: нужно найти адрес менюшки Мои устройства в G600. С чего надо начать? Как я уже говорил, практически любое действие начинается - с открытия главного меню. Открываем его в D900 и в G600 (напоминаю, адрес главного меню D900: 11350BB0, G600: 207AA114). Итак, открыли. Далее - вспоминаем, как добраться до главного меню Bluetooth. D900XEFK2: Меню - Приложения - Bluetooth (Меню - 3 - 4). G600XEGL1: Меню - Приложения - Bluetooth (Меню - * - 4). ;Здездочка - это 11 пункт, Решетка - 12). Итак, открываем в D900: 11350BB0 -> 1177E3D8 -> 106A483C G600: 207AA114 -> 214FB7C4 -> 202D70C8. Открыли. Заметили, что и тут структура очень похожа между прошивками? Сначала идет "Пункт 1 будет выбран по умолчанию", а затем переход. Переходим на второй скрипт, а затем по адресу, куда он ведет (D900: 10ECBFD4, G600: 20771DAC). Уже сейчас замечу, нам понадобится адрес главного меню Bluetooth, это те, что указаны выше (а не те, на которые мы перешли по переходам). Т.е. адрес главного меню Bluetooth в D900: 106A483C, в G600: 202D70C8. А теперь, вернемся ненадолго к открытому патчу на D900. Глядим в поле to - ничего нам не напоминают эти данные? Проводим ту же операцию, что и с полем from. Получаем: 3C486A10 -> 3C 48 6A 10 -> 10 6A 48 3C -> 106A483C. Входит в диапозон адресов? Входит. А теперь смотрим - ничего ли нам не напоминает этот адрес? Ого, дык это ж адрес главного меню Bluetooth! Правильно. Уже мы знаем, что писать в поле to для G600. Осталось лишь найти стартовый адрес для изменения. А он находится довольно просто. Найдем сначала его на D900. Что нам нужно? Нужно найти таблицу, в котором будет лежать функция - "Мои устройства" как данные. Как пользоваться поиском в BinEdit. На данный момент нас будут интересовать только две кнопки в поиске (надеюсь все знают, где поиск в BinEdit? В правой части программы, первая вкладка - Поиск). Первая кнопка - буква А с лупой, вторая кнопка - буква D с биноклем. Все видят? Ну и хорошо. А если не видим - присматриваемся лучше. В таблице функций - адреса лежат просто как данные. Точнее адреса везде лежат как данные, но в таблице - кроме них - больше ничего нет. Поэтому выполняем следующие действия. Кнопка поиска, которая A с лупой - она, в прицнипе, предназначена для ассемблера. Кнопка поиска данных, которая D с биноклем - нам и потребуется в данный момент. Берем адрес менюшки Мои устройства (возьмем мы его уже не из патча, а из головы. А как это, спросите Вы? Отвечаю. На данный момент у нас в D900 открыт адрес - 10ECBFD4, и мы видим, по какому пункту меню в какой адрес телефон переходит. Мои устройства - какой по счету это пункт меню? Второй для нас. Если у Вас человеческий файл binedit.ini, то описание скрипта mcc_menu_select (По пункту меню XX переход в адрес YYYYYYYY) будет человеческого вида, т.е. будут описываться пункты, начиная с 1. Тогда нас интересует строка - "По пункту меню 2 переход в адрес YYYYYYYY". Если же, у вас начинаются описание переходов по пунктам, начиная с 0 - то интересует строка - "По пункту 1 переход в адрес YYYYYYYY". Но в любом случае, адрес второго пункта в этом меню - это 112D254C. Вот он нам и понадобится. Вставляем этот адрес в поиск по данным (т.е. нажали кнопку D с биноклем), нам выдало 6 адресов: Какой же нам именно нужен для изменения? Рассказываю секрет - 5 из 6 адресов - это мсс-скрипты. И только 1 из 6 - это таблица. Как нам ее найти? Давайте поглядим глазами. Берем первый адрес - 106A52D4. Похоже на мсс-скрипт? Нет? Да что вы Нам нужно всего лишь выровнять код МСС, для этого нажнем кнопку . И опа - мы попали на какие-то условия. МСС-скрипты? МСС-скрипты. Берем следующий адрес - 10ECC02C и проделываем те же самые действия. Похоже на МСС-скрипты? Похоже. Итак, мы прошуршали так все шесть адресов. Интересно, заметите ли Вы тот самый, который не содержит в себе МСС-скрипты? А теперь маленький секрет. Нажмем черненький треугольничек между нашими двумя нужными кнопками поиска и выберем там пункт "МСС команды с использованием адреса". Сколько адресов нашел? 5? А почему не 6? Да потому что, один из шести - и не является мсс-скриптами. Путем анализирования и поиска шестого лишнего, мы сравнивая два списка поиска, обнаруживаем, что адрес 1199FE80 и не является мсс-скриптом. А как раз таки, и хранит в себе таблицу функций. Открываем наш патч, преобразуем наш адрес для изменения к нормальному виду и смотрим - правильно ли мы нашли? Правильно! Теперь нам ничего не стоит, как проделать все тоже самое, только на примере прошивки G600XEGL1, тем самым портанув этот нетрудный патчик. Полностью объяснив структуру патча, я уже не буду зацикливаться на моментах, и просто вкратце портирую данный патч вместе с Вами на G600XEGL1. Итак, у нас есть адрес главного меню Bluetooth в G600 - это 202D70C8. Берем адрес менюшки `Мои устройства` - это вспоминаем - переход по пункту меню 2 по адресу 21010660. Вставляем в поиск как данные, получаем шесть адресов, отсеиваем их, получаем, что адрес ячейки в таблице опять под номером #6, т.е. 0x21AE5F24. Все, мы все нашли, осталось лишь открыть компилятор, да компильнуть наш патчик. Итак, открываем компилятор, создаем наш проект, пишем следующее: .start 0x21AE5F24 А дальше? Что нам требуется? Заменить 4 байта, т.е. положить нормальный адрес в адрес в формате LittleEndian. Как это делается? Вспоминаем урок №3. Для этого существует операнда .word, которая записывает адрес в человеческом виде - в формат LittleEndian, как раз заменяя ровно 4 байта, что нам и требуется. На какой адрес будем заменять? На адрес главного меню Bluetooth, поэтому в компиляторе пишет следующее: .start 0x21AE5F24 .word 0x202D70C8 Все, патч готов Компилируем, и радуемся новоиспеченому патчу. Пару нюансов. На некоторых телефонах, в данном патче мы можем обнаружить следующее (буду брать на примере D900, т.к. в данный момент не нашел патча этого, где сделано следующим образом). Допустим, что в G600 адрес меню Bluetooth - 212D70C8, тогда при компиляции мы получаем следующее: <nord offset="0x01AE5FD4" from="60060121" to="C8702D21" type="CODE" /> Все видят, что последний байт (21) - одинаков и в поле from, и в поле to? Некоторые патчмейкеры после компиляции правят SMP на наличие одинаковых байт, т.е. получается следующее из патча: <nord offset="0x01AE5FD4" from="600601" to="C8702D" type="CODE" /> Уже сразу и не скажешь, что тут адрес, верно? В таких случаях обычно делается вот что - открывается адрес для изменения, то бишь - 0x21AE5FD4, там мы можем заметить следующее: 60060121B80F0E2180FD452168DD3120 Вот еще подсказка, как легко замечать данные. 1) Разбиваем строку по 4 байта: 60060121 B80F0E21 80FD4521 68DD3120 Затем обращаем внимание на каждый четвертый байт: 60060121 B80F0E21 80FD4521 68DD3120 Замечаем, что он или 20, или 21. Следовательно, нужно насторажиться (хотя я уже сразу же проверяю, что за данные тут лежат. Проверить просто - копируем это число, превращаем в человеческий формат, а далее уже по обстоятельствам). Тут, в основном, может быть: 1) Это указатель на строку, следовательно нужно смотреть на вкладке HEX в самой правой колонке - там BE интерпретирует байты как текст. Текст может быть как вменяемым, например: ..`.0.Poland..............b.1.Germany..........., т.е. мы видим, что идет перечень стран.. А можем быть и неособо вменяемым незнакомому человеку с кодировкой UTF8: ???°?·?°??.?’N‹?·????.?zN‚???µ?? (в основном через каждый символ-два повторяется буква Р (здесь возможно и в основном знак вопроса идет, т.к. в блокноте ANSI кодировка была указана при сохранении, поэтому данные символы из другой кодировки он не понимает ). 2) Это указатель на мсс-скрипты. Как, например, в рассмотренном выше патче. Т.е. чтобы посмотреть, что там - копируем адрес, превращаем в человеческий вид - и переходим на вкладку МСС в левой часте BinEdit'a. 3) Указатель на функцию. Опять же, копируем адрес, превращаем в человеческий вид, затем переходим на вкладку Код, и уже смотрим, что там за функция. Будучи более опытными в этом деле, также зная асм - уже сможете отличать код от подобия кода (т.е. от не кода, но BinEdit будет пытаться интерпретировать его как код). 4) Ну может быть еще указатель на указатель. Т.е. копируем число, превращаем в человеческий формат, а там мы попадаем на еще какую-нибудь таблицу, в котором опять же лежат - указатели. Ну это основные случаи я рассмотрел, скажу сразу - далеко не все. Еще также быть - указатель на RAW графику, может быть указатель на IFEG-графику.. многое чего. Какие еще могут быть нюансы. Скажу еще вот что. Мы рассмотрели понятие "таблица", кажкая ячейка - 4 байта. Но не стоит думать, что в любой таблице ячейки все по 4 байта. Есть таблицы, в которых идут данные по байту, а также по два. У Вас может появиться вопрос - а где по 3 байта? Отвечу. Наш мобильный ARM-процессор умеет работать с числами, типа: 1) byte (один байт) ; 2) half-word (два байта) ; 3) word (четыре байта). [Спасибо FRAER за исправление] ;названия привел из типов переменных =) По три байта - он работать не умеет. Есть еще исключения - динамичноячеечные таблицы (т.е. таблицы, в которых размер ячейки может варьироваться). Но это немного другой разговор, так как из них данные берутся вручную, нежели из статичноячеечных (т.е. размер каждой ячейки исключительно одинаков). Для чего это делается (хотя возможно еще рано о них говорить, но все же - потом если что, вернемся). В таблицах, где каждая ячейка имеет одинаковый размер - легко работать. Там можно получать данные просто по номеру, как в рассмотренном выше примере. Или же пройдясь циклом по всем ячейкам таблицы, хоть и тут же опять будут номера. Также могу сказать - о таблице иконок в прошивке. Таблицы имеют размер ячеек одинаковый - 24 байта. Если Вы хорошо вчитываетесь, то можете задать сейчас вопрос - что за бред, если размер ячейки может быть 1, 2 или 4 байта? Тут я поясню. Размер ячеек может быть каким угодно, но данные в них - могут быть уже по 1, 2 или 4 байтам. В таких больших ячейках, работа идет через указатель. Т.е. здесь получается - номер * 24, получаем указатель на нужную ячейку. А уже данные с нее - собираем по крупицам, т.е. по одному, двум или четырем байтам. Ну думаю, хватит грузить по этой теме, кому надо будет - еще вновь перечитает, когда станет более опытным в сфере патчей, повторение - мать учения Ну на сегодня мой урок подходит к концу, единственное, что еще хотелось бы сказать. Мы научились заменять данные, это понятно. Мы заменили в таблице указатель на менюшку "Мои устройства" (это переход по пункту 2) на адрес главного меню Bluetooth. Но ведь мы также можем сделать и переход не в главное меню Bluetooth, а в менюшку активации Bluetooth. Просто для закрепления урока. P.S. Переход по пункту меню 1 Ну все, на сегодня все - собирался рассказывать совсем не про этот патч, а про немного сложней. Но пока пусть будет так, главное - Вы познакомились с таким понятием, как данные, и что если мы видем данные - то не стоит искать тупо такой же в другой прошивке, я имею ввиду то, что не стоит брать адрес с одной прошивки и его же вставлять другую для поиска. Надеюсь, урок не покажется Вам трудным, и Вы его переварите. В очень ближайшее время, будет рассмотрен более трудный патч, уже с использованием ассемблера. Enjoy.

Мда.. обновил оперу на компе - та же борода случилсоь Переустановил оперу - ничего не изменилось.. Хотя изменилось, да не то - теперь пару смайликов (слева от ответы) стали не четкими,а немного размытыми

Название: SwingGlobal Func Версия: 1 Прошивка: G600XEGL1 Автор(ы): [AlaSToR] Портировал(и) на G600: - Тестировал(и): - Спасибо: - Описание: Патч добавляет возможность назначение глобальной функции на нажатие качельки в большинстве мест телефона. Для управления патчем зайдите в Меню-#-1-5 (Меню-Настройки-Телефон-Клавиша громкости) и увидите два новых спинбокса "Клавиша громкости" (а бывший спинбокс `Клавиша громкости` переименован в `При звонке`), на который можете выбрать одну из функций на нажатие качельки: - Сдвиг пунктов меню (то, что в стандарте) ; - Регулировка громкости клавиатуры ; - Регулировка громкости плеера/FM-радио ; - Регулировка яркости дисплея ; - Выключено (т.е. при нажатии качельки не будет ничего происходить), а также второй спинбокс "Если плеер/FM-радио выключено", который будет доступен в случае, если в первом спинбоксе будет выбрана функция, связанная с MP3-плеером или FM-радио, а также добавлен один чекбокс, который дает возможность все равно оставить функцию сдвига пунктов меню, если в данной менюшке более 50 элементов (пунктов меню). Данный чекбокс имеет высший приоритет, после глобальной функции `Выключено`. Т.е. если глобально отключили функцию качельки (т.е. в первом спинбоксе выбрали `Выключено`), то сдвиг в длинных менюшках не будет работать. Во всех остальных случаях - будет. Например, если глобально у нас стоит регулировка громкости плеера/FM, а если плеер/FM выключен, и побочная функция, в данном случае, у нас - это отключить качельку, то сдвиг в длинных менюшках все равно будет работать (естесственно, если данный чекбокс будет включен). ВНИМАНИЕ! Для работы патча необходима установка -=Мастер-патча=-! SwingGlobal_Func.rar

А Вы попробуйте сначала применить патч, а уже затем изменять опции. Как бы патчи с опциями только в таком порядке и ставятся, а уж никак не наоборот.

Название: Google Red Key FiX Версия: 1 Прошивка: G600XEGL1 Автор(ы): [AlaSToR] Портировал(и) на G600: - Тестировал(и): - Спасибо: - Описание: Патч исправляет баг прошивки с красной кнопкой при выходе из менюшки `Поиск в Google`. Теперь, при нажатии на красную трубку в данной менюшке, мы будем выходить не в главное меню телефона, а на рабочий стол, как положено. Google_Red_Key_FiX.rar

Урок №5 - Исследование кода МСС-скрипта. Ну чтож.. прошло немало времени с тех пор, как я писал последний урок.. Попробуем возобновить работу. Даже и не знаю, что рассматривать конкретно.. Но думаю - будем уже пытаться портировать патчики.. Для примера возьмем патч `Экономный режим в яркости дисплея`, в котором мы уже будем смотреть, а что же творится в этих самых мсс-скриптах? Итак, открываем данный патч, как обычно - на D900XEFK2, будем пытаться его портировать на G600XEGL1, тем самым научимся исследовать две прошивки одновременно, а заодно и думать об мсс. Начнем. Первым делом - открываем в BinEdit - D900XEFK2. Затем в главном меню выбираем: Действия - Связанный bin - Открыть новый редактор, в котором мы выберем вторую прошивку для исследования. Это будет - G600XEGL1. В итоге, у нас открыто два BinEdit'a с нужными прошивками. Следующий шаг, что нам нужно сделать - это выключить синхронизацию между прошивками. Я это делаю, т.к. при исследовании кода на одной прошивке сбивается адрес на второй, поэтому делается все это - ручками, и только ими. Для этого проводим следующее действие в обоих окнах BinEdit (есстно не одновременно, а по очереди): Действия - Связанный bin - Синхронизация. Щелкаем, тем самым сняв галочку. Возвращаемся к нашему патчу - открываем его в любом текстовом редакторе. Расскажу секрет - чтобы портировать данный патч, нужно просто изменить стартовые адреса и все. Возвращаемся к патчу. Смотрим первую строчку патча: <nord offset="0x0124C6C6" from="01" to="00" /> Вспоминаем первый наш урок.. Какой натуральный адрес изменяется? 1121C6C6, т.к. база в D900 - 0x1. А в G600 как бы этот адрес выглядел? Вспоминаем.. Т.к. база 0x2, значит адрес будет - 2121C6C6. Первым шагом нам надо - открыть главное меню телефона (есстно на мсс-уровне). Я начинаю чаще всего - с этого. Вспоминаем урок №3 - там я показывал, как найти адрес главного меню телефона. Напомню - в D900 это 11350BB0, а в G600 - 207AA114. Дальше - нам нужно поочередно выполнять действия между двумя прошивками, т.е. шаг за шагом, одинаково. Вспоминаем, как добраться до яркости дисплея в D900? Меню-Настройки-Дисплей-Яркость (Меню-9-3-5). А в G600 это - Меню-Настройки-Подсветка-Яркость-Настройка яркости (Меню-12-2-2-2). В принципе, в данном случае поочередность действий нам не требуется, так что открываем яркость дисплея в D900. Итак это - 11350BB0->102AFCEC, 102AFCEC->102B0DBC, 102B0DBC->113BAFAC. МСС-скрипты яркости дисплея на D900 открыты (ее адрес 0x113BAFAC).. Далее - открываем ее же нa G600: 207AA114->21096C14, 21096C14->21098E50, 21098E50->2030F4C4, 2030F4C4->2197F20C, 2197F20C->21097CD4. Теперь и на G600 яркость дисплея открыта, ее адрес - 0x21097CD4. Хочу заострить внимание на переходе G600: 21096C14->21098E50. Вы видите, что начиная с адреса 21096C24 идет серый блок? (у кого нет серого блока, проверяем следующее: последняя ли версия BinEdit, и присутствует ли файл mask.col в папке с программой). Это означает, что с данного адреса начинается новый блок мсс, не имеющий никакого отношения к скриптам, идущим до 21096C24. Поэтому блок, состоящий всего лишь из одного скрипта (на адресе 21096C14) является завершенным. Итак, мы получили мсс-адреса описания яркости дисплея на мсс-уровне (D900: 113BAFAC, G600: 21097CD4). Начинаем исследовать, что же происходит у нас при входе в данный пункт? Сначала идет подготовка окна, затем происходит переход на другой адрес (в D900 это переход на 107990FC). Выполняем поочередные действия - сначала в D900 переходим по адресу 0x107990FC, затем в G600 переходим по адресу 207BC48C). Итак, что мы видим дальше? Здесь выполняется какой-то таск. В D900 это: mcc_task 0xA 0x36, в G600 это: mcc_task 0xA 0x37. Так что же все-таки происходит в данном таске? Открываем BinEdit [D900XEFK2] (т.е. тот BinEdit, в котором у нас открыта прошивка D900XEFK2), теперь нас интересует - вкладка "МСС" в правой части программы. Открываем ее. Нас интересует скрипт - MCC_TASK, с номер 0xA и кейсом 0x36 (вспоминаем прошлые уроки, где я рассказывал про номера и кейсы). Идем по порядку. Для начала - забыли про кейсы, нас пока интересует скрипт MCC_TASK с номером 0xA. Ищем в правой часте программы на вкладке МСС - MCC_TASK 0A (надеюсь понятно, почему именно данную надпись? Если бы у нас шел номер таска не 0xA, а допустим 0x13, тогда что бы мы искали на вкладке МСС? MCC_TASK 13 и т.д.). Нашли - это запись: 1121AB24|170A|MCC_TASK 0A. Отлично. Дважды щелкаем по записи (т.е. по адресу), открылась в левой части вкладка "Код" - в данной вкладке BinEdit уже в основном предназначен для распознавания ассемблера (хотя также в ряде случаев здесь интерпретируются и мсс-скрипты, и данные). Что мы видем? В столбик идут всякие разные команды, в которых мы ничего не понимаем Немного объясню - это THUMB-код ассемблера (Если Вы читали другие статьи про режимы нашего процессора, то помним, что THUMB-команды это 2 байта, и только лишь bl/blx вызовы имеют размер - 4 байта). Сейчас разбирать каждую команду не имеет смысла, так как 90% тех читателей, кто хочет именно обучиться - ничего не поймут. Да и в прицнипе - и я не смотрю на данный код, т.к. он нужен только в редких случаев, когда не имеем возможности нормально подобраться к нужному кейсу, или нужный кейс не соответствует тем данным, что мы предполагаем получить. Это вряд ли Вы поймете, поэтому пропускаем мимо ушей, в нужный момент вернемся к этому. Итак, продолжаем. Мы открыли содержание MCC_TASK 0A, теперь нас интересует - какой кейс у нас был? А кейс у нас был (вспоминаем) - 0x36. Что же делать дальше с этим кейсом? Да все просто, пролистываем код вниз, пока не наткнемся на записи вида: 1124AC18: F205 DCD 0x05F2;B loc_1124B7F4;При 0x0000;Переход на адрес 0x1124B7F4 1124AC1A: E905 DCD 0x05E9;B loc_1124B7E2;При 0x0001;Переход на адрес 0x1124B7E2 1124AC1C: AC07 DCD 0x07AC;B loc_1124BB68;При 0x0002;Переход на адрес 0x1124BB68 1124AC1E: AF07 DCD 0x07AF;B loc_1124BB6E;При 0x0003;Переход на адрес 0x1124BB6E 1124AC20: EC08 DCD 0x08EC;B loc_1124BDE8;При 0x0004;Переход на адрес 0x1124BDE8 1124AC22: 2F0C DCD 0x0C2F;B loc_1124C46E;При 0x0005;Переход на адрес 0x1124C46E 1124AC24: 490C DCD 0x0C49;B loc_1124C4A2;При 0x0006;Переход на адрес 0x1124C4A2 1124AC26: 1B32 DCD 0x321B;B loc_11251046;При 0x0007;Переход на адрес 0x11251046 1124AC28: 860A DCD 0x0A86;B loc_1124C11C;При 0x0008;Переход на адрес 0x1124C11C 1124AC2A: 8E0A DCD 0x0A8E;B loc_1124C12C;При 0x0009;Переход на адрес 0x1124C12C Вот это и есть описания кейсов. Каждая запись означает, на какой адрес ведет какой кейс. У нас кейс 0x36, значит пролистываем ниже, то того, пока не увидим запись вида ";При 0x0036 ;Переход на адрес ..". Итак, эта запись находится на адресе 1124AC84: 1124AC84: 900C DCD 0x0C90 ;B loc_1124C530 ;При 0x0036 ;Переход на адрес 0x1124C530 Отсюда мы узнаем, что по кейсу 0x36 выполняется код по адресу 0x1124C530. На данный момент кейсы таска 0xA в прошивке G600XEGL1 интепретируются BinEdit'ом неправильно, точнее - вообще не интерпретируются. Поэтому здесь придется немного схалявить.. Но - хотя бы попробуйте открыть MCC_TASK 0A в G600. Если у Вас это получится, то попробуйте сравнить с моим адресом. MCC_TASK 0A находится на адресе: 20B3FF24. Ну вот в прицнипе, Вы уже знаете, как примерно открывать содержимое мсс-скрипта. Возможно у Вас встанет вопросы - ну с таском все понятно, все довольно ясно. А что, если нам выпадает другой скрипт? Еще проще Смотрим на скрипт, допустим это: 207BC49C 66 00 0000 0000 0000 00000000 0000 0000 Начало вызова пользовательских событий Вспоминаем про идентификатор скрипта (см. Урок №3), смотрим - ид данного скрипта - 66. Открываем в правой части BinEdit вкладку MCC, и ищем там в графе "КОД - 66. Для упрощения, можно нажать на саму вкладочку "Код" для упорядочивания записей по возрастанию/убывания данного кода. Вообщем, поискав - мы найдем запись: 2016CC00|66|MCC_USER_EVENT_START Надеюсь, это понятно. Вернемся, к нашим баранам. Так что же в итоге выполняется в этом 0x36 кейсе? Открываем адрес 1124C530 (надеюсь, еще не забыли, откуда он взялся), и смотрим его код (пока каждая команда нас не интересует, буду вкратце рассказывать поблочно). Выделю первый блок: LDR R0, =0x00000A19 BL lk_get_text LDR R1, =gv_ImageTitleIconStart MOV R5, #0x0 LDRH R2, [R1, #0] MOV R1, #0x0 MOV R3, R5 BL _Reg_Draw_Title В данном блоке прорисовывается заголовок менюшки (верхняя надпись, и полоска, где рисуются часы, значки (индикаторы). Следующий блок: MOV R0, #0x8 BL _lk_get_sofk MOV R4, R0 MOV R0, #0x46 BL _lk_get_sofk MOV R2, #0x0 MOV R1, #0x0 STR R2, [SP, #0x8] MOV R2, R4 MOV R3, R5 STR R1, [SP] STR R1, [SP, #0x4] BL _Reg_Draw_Softkey В данном блоке прорисовываются софт-клавиши. Далее идет код некоторых проверок, затем блок рисования картинки: MOV R2, #0x20 MOV R1, #0x0 STR R2, [SP, #0x8] MOV R2, #0x1 MOV R3, R7 MOV R0, #0x0 STR R1, [SP] STR R1, [SP, #0x4] LDR R6, =LcdPattern BL _lk_DisplayImage Затем еще раз и т.д. Но нам что конкретно там - уже не важно, т.к. здесь от меня требовалось лишь показать, как узнать, что происходит в самом скрипте. Вернемся к портированию патча. Что от нас требуется? Убрать для начала ограничение. Если подумать, ведь при нажатии на кнопку влево (уменьшение яркости) - должна быть проверка, типа - если подсветка на уровне 1, то прекратить выполнение действия, и оставить значение подсветки - 1. Поглядим это, вернувшись на мсс-описание яркости дисплея. Приглядимся: 1079911C 69 06 0700 0000 0000 2C102B10 0000 0000 При нажатии "вправо" переход на 0x102B102C 1079912C 69 06 1000 0000 0000 2C102B10 0000 0000 При нажатии "боковая вверх" переход на 0x102B102C 1079913C 69 06 0600 0000 0000 CC917910 0000 0000 При нажатии "влево" переход на 0x107991CC 1079914C 69 06 1300 0000 0000 CC917910 0000 0000 При нажатии "боковая вниз" переход на 0x107991CC 1079915C 69 06 0E00 0000 0000 CCAF3B11 0000 0000 При нажатии "левая софт" переход на 0x113BAFCC 1079916C 69 06 0D00 0000 0000 CCAF3B11 0000 0000 При нажатии "i/ok" переход на 0x113BAFCC 1079917C 69 06 0900 0000 0000 98D08111 0000 0000 При нажатии "вкл/выкл (красная)" переход на 0x1181D098 1079918C 69 06 0F00 0000 0000 D0E0F810 0000 0000 При нажатии "правая софт" переход на 0x10F8E0D0 Вот наши обработчики нажатий клавиш. Интересует нас - выполнение функции по нажатию на кнопку `влево`. Значит переходим по адресу 107991CC. Поглядев скрипты по этому адресу можно понять, что все действие разворачивается в одном таске (mcc_task 0xA 0x34), а затем телефон возвращается в описание яркости дисплея. На G600 - выполняется другой таск (mcc_task 0xA 0x35), но прицнип тот же. Открываем сначала на D900 - MCC_TASK 0A (1124AB24), затем кейс 0x34 (1124C6BC), затем в G600 - MCC_TASK 0A (20B3FF24), ну а тут я подскажу пока - адрес перехода по кейсу 0x35 - 20B4229A. Итак, на данный момент должно быть у вас открыто: [D900XEFK2] - адрес 1124C6BC, [G600XEGL1] - адрес 20B4229A. Открываем наш патч на D900, смотрим - первый адрес для изменения это 1124C6C6. Глядим данный адрес на D900: 1124C6C6: 0128 CMP R0, #0x1 Видим, что данная строчка в патче - это изменение именно проверки в таске по кнопке влево. Также видим аналогичный код в G600: 20B422A4: 0129 CMP R1, #0x1 Вот уже хорошо, первый адрес для изменения в прошивке G600 - мы нашли. Открываем компилятор в G600 и пишем такое: .start 0x20B422A4 .byte 0 Таким образом мы добьемся в патче следующего: <nord offset="0xB422A4" from="01" to="00" /> Т.е. того, что нам нужно. Операнда .byte записывает 1 байт по нужному адресу. Хотя возможно указывание и нескольких байт, только нужно их писать через запятую. Т.е. операнда записывает побайтно нужные данные. Идем дальше, с первой строкой мы разобрались. Теперь вторая строчка изменения прошивки: <nord offset="0x0124C6F4" from="013804" to="C04605" /> Мы видим, что даже не пролистывая прошиву - мы видим в D900 уже этот адрес для изменения. Глянем в G600 - видим примерно тоже. Но так как не показываются нам кейсы в G600, для достоверности покажу один из способов узнавания - а точно ли мы нашли эквивалент? Для этого нам потребуется sym-файл прошивки, для D900 у меня он есть, объясняю. Видим блок: LDR R1, =0x10B73920 ADD R1, #0x34 MOV R0, #0x1B BL _tra1_3trace Это блок вызова трассировки, такие ф-ии понапиханы везде в прошивку, по ним и можно ориентироваться. Скажу сразу - функций трассировки в телефоне достаточно разных, поэтому не обязательно ориентироваться только на эту. Объясню, что такое трассировка в телефоне - это запись в специальный трассировочный буфер определенной строки для отладки прошивки. В строках бывают разные параметры, но нам не важно. Главное - сама строка. Отлаживают ее сами корейцы, поэтому это не для нас. Но - мы возьмем это как козырь Смотрим в D900, какая строка передается в данную функцию. Строка передается в регистр R1, т.е. нас интересует код: LDR R1, =0x10B73920 ADD R1, #0x34 Команда ldr - загружает адрес на данный в конкретный регистр. В данном случае, в регистр R1 помещается значение 0x10B73920. Команда add является аналогом арифметической операции сложение, т.е. попросту - плюс. В данном случае, здесь "написано", что к адресу, помещенному в регистр R1, прибавить значение 0x34. Посчитаем вручную, чтоже это все получается? Открываем стандартный виндовский калькулятор, выбираем режим "Инженерный", затем выбираем радиокнопку - hex, и вводим: 10B73920, затем плюс и 34. Получилось число 10B73954. А теперь проще. Приглядимся на комментарий к данной команде (add). Это справа зеленая надпись, отделенная точкой с запятой: ;R1 = R1 + 52 "4" = 0x10B73954 (280443220) Поясню откуда всякие непонятные цифры: a) 52. Число "52" взялось оттуда, что число 0x34 (а это шестнадцатеричная система счисления) переведено в десятичную, отсюда и 52. б) "4". Здесь замечу - не цифра 4, а символ. А написано 4, потому что байт 0x34 это номер символа "4" в ANSI-кодировке (я это кстати рассматривал уже в уроке №1). в) 280443220. Аналог к пункту "а". Просто итоговое полученное число (0x10B73954) из шестнадцатеричной системы счисления преобразовали в десятичную. Ну в прицнипе хватит разжовывать, надеюсь все это - Вы уже поняли. [D900XEFK2]: Открываем на вкладке HEX адрес 10B73954, и видим там такую строку: TASK_SET_GET_CONTRAST_LEVEL В G600 немного проще - там сразу же передается адрес на строку в функцию трассировки (это просто исключение в данном месте), т.е. без всяких арифметических действий. А передается туда адрес - 2197B478. Открываем его на вкладке HEX, смотрим текст: TASK_SET_GET_CONTRAST_LEVEL Совпадает с D900? Совпадает, значит мы можем быть уверены, что эквивалент найден правильно. (Но - бывают и случаи, что даже при совпадении строки трассировки - эквиваленты не совпадают, т.к. одна и та же строка может передаваться в разных местах телефона!) Возвращаемся обратно на вкладку код, к нашему именно коду (у кого непонятно что там появилось - это сейчас пытается BinEdit интерпретировать текст как код. Поэтому - нажмите стрелку влево, рядом с полем ввода адреса). Смотрим на второй адрес патча - 1124C6F4, ищем аналог в G600 - это 20B422D0. Открываем уже открытый компилятор и пишем следующее: .start 0x20B422D0 nop .byte 5 Команда nop - ничего не делает, таким образом мы затерли команду по адресу 20B422D0, т.е. теперь команда sub r0,1 не выполнится. А на следующем адресе запишется байт 5. Ну вот и теперь разобрались со вторым адресом патча. Смотрим следующий - 1124C74A. Прокрутив дальше код [D900XEFK2] - мы вновь увидим адрес для изменения, и прокрутив код [G600XEGL1] - увидим его аналог - 20B422E2. Следовательно, что мы добавляем в компилятор? .start 0x20B422E2 nop .byte 5 Ну и остался последний адрес [D900XEFK2] - 1124C770, также прокрутив код, найдем и ему аналог [G600XEGL1] - 20B42308. Теперь добавляем четвертый адрес в компилятор, и компилируем наш патч. Ура, мы его портировали! Можем свериться с уже готовым патчем в G600. У вас может возникнуть вопрос - а почему различия такие? В нашем скомпилированном патче со второй строки идет измененные данные - C04605, а в G600 - C0460528. Все просто. Сравните последний байт (два символа) в поле from и в поле to - есть разница между ними? Что там 28, что там - тоже 28. Просто в компилятор было записано там не .byte 5, а cmp r0,5. Вот и все. Подведя итог рассматривания данного патча, я хочу сказать вот что. Так как в G600 не интерпретируются кейсы в MCC_TASK 0A, я Вам советую попробовать портировать данный патч на любую другую старенькую модель телефона. Желательно, конечно, на ту, где данный патч уже есть, чтоб было с чем сравнивать правильность портирования. Заканчивая наш сегодняшний урок, хочу рассказать еще кое-что. Кто-то мог догадаться, почему я пару строками выше написал cmp r0,5, а кто-то и не мог. В завершении, я расскажу, как восстанавливать исходник из smp-файла. Скажу сразу же - это занятие для маньяков, лучше возьмите исходник. Но раз выхода нет, то пробуем. В прицнипе, это не так трудно. Но даже для не очень больших патчей - это доставляет неудобства. Вообщем, делаем следующее: 1) Открываем редактор патчей (Инструменты - Редактор патчей) ; 2) Открываем в нем нужный патч (на примере - открываем рассматриваемый выше патч на G600XEGL1) ; 3) Если редактор патч для дела - запускается в первый раз, то мы толком ничего не увидим. Поэтому приводим окно к нужному виду (пример на скрине. Тянем за черные полоски и наслаждаемся). 4) Возьмем любой из адресов, размер изменения которых 4 байта. Допустим первый в списке, это 00B422D0. Снизу появляется 3 вкладки - Свойства/HEX Код/Код. Нас интересует последняя вкладка - Код. Открыв ее, мы увидим следующее: 20B422D0 C046 NOP ;Пустая команда. Аналог MOV R8,R8 20B422D2 0528 CMP R0, #0x5 ;Сравнить R0 и 5 Также в прицнипе есть и патчи, в которых по одному адресу изменения будут записаны как мсс-скрипты, так и thumb-код. В этом случае уже проще применять патч к прошивке, переходить по изменяемому адресу и уже переписать код оттуда. Ну вообщем все, надеюсь Вы меня не забыли, и продолжаете колупаться в патчах, и уже ушли намного дальше, чем мои уроки. Всем спасибо, до свидания

Иконка добавляется также, как и создается пункт меню. Различия - в типе, передаваемом в lk_AddMenu, ну и уже не строку нужно передавать в lk_AddMenu, а ID иконки. Статей нет, но есть патчи, откуда можно пример взять.

Самой последней версии? Потому что, первая версия также у меня работала до пары до времени. Сначала все работало, а потом по неведомым причинам - перестало.

Снег, прошу прощения, ошибка вышла. Адрес указывать нужно 30489160, все остальное - без изменений

У вас не Фото, а зеленая трубка, если мне не изменяет память. Это раз. А во вторых - LCD Dump не работает в яве без доп. патча. Вот в камере вроде бы как должно сниматься. Чтобы в камере был отдельный буфер - я не слышал. С vScreenMem как раз и снимается в патче "ScreenShot". Чтобы через BinEdit снять скриншот в яве, нужно следующее. 1) Установить патч CGSN; 2) Скачать последнюю версию BinEdit; 3) Открываем терминал (Инструменты - Подключение к телефону); 4) Выбираем COM-порт (вроде бы как баг не исправлен, поэтому телефон должен висеть на порте ниже десятого), подключаемся к телефону - внизу должна отобразиться модель телефона и информация о CGSN-патче; 5) Открываем вкладку в терминале - Дамп. Адрес - 303650A0, длина - 12E80, в третьем поле так и оставляем 100, нажимаем сохранить, указываем имя дампа. Потом меняем ему расширение на .raw, открываем через Samsung RAW Viewer, если отображается коряво - снизу указываем длину - 176, ширину - 220, bpp - 16. Если отображается уже нормально, сохраняем скриншот в любом нужном для нас формате. Ну вот в прицнипе и все.

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

Миш, пробуй. Использовать думаю нужно ScreenShot studio v2.1,прописав в карту: <phone model="SAMSUNG SGH-E200B" path="/Images/Downloaded images" mode="PIMS" gen="D500" width="176" height="220" bpp="16" endian="Little" ack="0" /> ScreenShot_E200B.rar

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

Меня интересует, а каким ж образом Вы портировали данный патч? Через автопортирование в BinEdit? Во-первых, для нового файлового менеджера вашего телефона - нужно половину оригинального патча переписать. Да я бы сказал, что даже процентов 90 здесь будет по другому. И проблема при включении не из-за файловой системы, а из-за того, что в начале прошивки (адрес 0x2000004C) записано неизвестно что, глянул первую попавшуюся врезку - там идет переадресация телефона на адрес 0FC3217D. Ну и что мы хотим получить от данного патча? Ручками все надо портировать, плюс переписать почти весь патч, чтобы добиться нужного эффекта.

Видел, пробовал делать это на G600, вручную задавал коордитаны в Reg_Draw_User_Image - 0 эффекта. Хотя скорей всего все равно я закосячил..

Название: Фонарик Версия: 0.5 Прошивка: G600XEGL1 Автор(ы): Freeman, vvyura Портировал(и) на G600: - Тестировал(и): - Спасибо: vvyura Описание: Теперь у вас есть фонарик, который работает самостоятельно, отдельно от камеры. Адрес функции фонарика: 0x210A6700 Или же устанавливаем фонарик на клавиши через патч: KC [Keys Configurator]. Известные баги: - При складывании слайдера с установленной функцией `Завершение операции` - фонарик не выключается. Поэтому и версия 0.5. Маленькое примечание по поводу интерфейса. Если есть файл `flashlighter_bg.raw` в папке user - то будет при запуска фонаря рисоваться данный фон. Если же нет - выведется текст `Фонарик` на фоне меню. Огромнейшее спасибо vvyura за данный патч! P.S. Никто из патчмейкеров ответственности за повреждение вспышки - не несет. P.S.S. Кому нужно - в первом посте появились API-файл к G600XEGL1, а также SYM-файл. FlashLighter_0.5.rar

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

Это будет отдельный патч. А посредством тем будет и заменяться главное меню.

А кто будет делать?

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

Даже не знаю, к кому ориентирован вопрос.. На днях обновил оперу с 10.52 до 10.60, и только наш форум отображается косячно. Не помню точно, перед обновлением нормально ли показывался он на 10.52,или нет.. Вроде как уже нет.. Проверил на IE - все нормально. Вы, случаем, никаких работ не проводили с оформлением? Скрин прилагаю. Советы по перезагрузке компа не предлагать. Если в отображаемых ветках еще ширина более-менее нормальная, то чем ниже - там вообще узко.

К сожалению, BinEdit не идеален. И некоторые косяки есть.. Но мы здесь и собрались, чтобы его улучшать. Ну вот это и есть один из известных недочетов - при наложении кода на код он не всегда ругается. Такие танцы не нужны. Проще сразу писать: .word 0x2153CDFB. Директива .word сама автоматически переворачивает адрес, т.е. преобразует в Little Endian. Дык 0xFBCD5421 уже в Little Endian, куда еще дальше преобразовываться само в себя? Получается, что нет, т.к. ри компилировании .byte 0xBFCD5421 - у нас вообещ выходит просто байт 0x21 и все. Вообще, чтобы меншье вопросов возникало, можно все это самому исследовать. Открываем отдельный компилятор, выставляем в настройках - компилирование в результат, и пишем нужный код для исследования: .start 0 .byte 0xBFCD5421 Компилируем,и видим, что на выходе у нас просто 1 байт 0x21: 00000000: 21

Такие выводы откуда? Потому что BinEdit не ругается? Или самостоятельно вручную проверяли? Я уже написал, что если написать код То никаких ошибок BinEdit не выдаст, хоть и будет наложение. А если уже написать То ошибка будет. И нельзя ли просто использовать метки? Это ж намного удобней, или в данном патче конкретно изменяется место в прошивке? А там,если нужно где-то ссылаться на строку - то просто указываем ее название, например string_1.

Да, я поэтому в конечной цитате его и зачеркнул. В этом вся и ошибка. Сейчас поменял местами, т.е. сначала 64 идет,потом 94 - и у меня тоже теперь ошибка такая же выводится.