Хацкер

EvgeniyZ, Вполне, главное найти место (адрес) который бы не использовался или же использовался, но вместе с твоим кодом не конфликтовал Здесь надо быть осторожным... Смотри опять же оригинальную символьную информацию по коду... после сигнатур для основного кода прошивки, далее идет разметка адресов оперативки... обрати внимание на "расстояние" между адресами... т.о. ты определишь где и сколько памяти выделено на конкретную переменную... есть глобальные переменные (от 1 до 4-х байт), а есть и буфера отведенные для ресурсоемких задач. На медне ковырял патч на увеличение размера мелодий ММF, мои догадки строятся на том, что там ссылки на стандартный буфер ОП поменяли на другой - большой, т.о. при наличии установленного на телефоне этого патча, можно использовать оперативку от стандартого буфера под мелодии. ... и еще, немного в догонку про адреса оперативки. Не забывай, что явного указания на адрес может и не быть вовсе. Оптимизатор кода постоянно хитрит, если адрес может быть получен арифметическими операциями от уже задействованного ранее, который сидит в регистре, то он выберет именно этот способ, т.к. он занимает меньше места. Т.е. к примеру 1.Грузится в регистр R0 адрес переменной - командой LDR 2.Далее грузится значение оперативки по искомому адресу, но уже в регистр R1 3.Т.к. в R0 уже сидит адрес, то можно загрузить еще переменную, адрес которой недалеко.... для этого используется та же команда LDR, только со смещением... Вот в такуой конструкции автопоиск адресов использования BinEdit'a уже бессилен имей ввиду Если смещения используемого самой командой LDR не хватает, может использоваться арифметика, напр. с адресом в регистре можно сделать любые махинции - как с обычным числом. и уж только тогда, когда оптимизатор кода не сможет получить переменную - идет явное указание ее в коде - такая конструкция займет 8 байт (4 - адрес и по 2 на две LDR).

Удержание затвора камеры надо искать ссылку на сигнатуру mcc_camera_take_n_send_from_idle. Я посмотрел вроде сама она лежит по адр. 00960DC8, а адресок соответственно 00071EA0 Но не уверен... проверь

dr-dimick, можно! тоже хочу... кто бы сделал р.s. если кто не вкурсе - быстрое включение т9 - удержание правой софт. кл.

Когда я начинал ... я тоже был обескуражен тем - что прошивка закончилась и как искать не понятно. Это область оперативки, соответственно в прошивке ее не будет. Но логично предположить что к этой глобальной переменной идет обращение из кода самой прошивки - так?! Значит надо найти в прошивке где идет обращение к ней. Т.е. зная адрес этой гл. переменной (gv_InCharge) надо поискать где она еще используется помимо патча... т.е. найти функцию в которой она используется - а потом... правильно! найти такую же функцию и у себя - и уже в своем коде ты увидишь новый свой адрес для той же переменной! А что делать, к примеру если адрес оперативки в исходной прошивке не соответствует какой-либо переменной (сигнатуре) - тогда рискну предположить что автор патча искал место в оперативке для своего патча... значит надо от чего-то отталкнутся - от переменной которая идет перед нашим адресом - берем и в калькуляторе - вычитаем от нашей переменной и ближайшей - получаем на сколько байт она убежала от нее - как правило круглое число потом ищем также где в коде используется переменная которая предшествует нашей и к полученному адресу прибавляем наше смещение... все элементарно Ватсон!

Официально выслал всем подписчикам новую версию KeyBacklightOff v2.0.2!!! Что реализовано: 1. Добавлено новое меню в котором можно вкл./выкл. подсветку клавиатуры. 2. Появилась возможность вкл./выкл. подсветку горячими клавишами (по умолч. - удержание "1" ) 3. Подсветка не привязывается ко времени 15 сек. продолжительность - отдельно - клавиатура отдельно 4. Переключение в отличае от предыдущей версии происходит мгновенно ------------ Что пока не удалось решить: 1. При выключении телефона выбранный режим подсветки для клавиатуры по умолчанию сбрасывается на выключено 2. Некорректно отображаются всплывающие подсказки напротив позиции "клавиатура"

Таблица иконок (iconstable) <iconstable title="Большие (при вызове)" type="bigicons" item="Иконка" ofs="0x8A78D8" reclen="24" count="78" ofsleft="4" ofstop="6" ofswidth="8" ofsheight="10" ofssize="14" bpp="8=0A,16=06" ofsbpp="17" ofsptr="20" lang="3;1-37=386,402;38-41=387,459;42-44=387,464;45-49=387,469;50-58=388,450;59-67=389,393;68-78=390,439"> 008A78D8: FFFF0000 0030 0041 001E 001E 0000 0384 03 0A 0000 0079D523 ofs="0x8A78D8" – адрес начала таблицы; reclen="24" – число байт в строке; count="78" – число строк (общее кол-во картинок); ofsleft="4" – по адресу ofs+ofsleft берется 2 байта - левый край картинки (0030); ofstop="6" – по адресу ofs+ofstop берется 2 байта – верхний край картинки (0041); ofswidth="8" – по адресу ofs+ofswidth берется 2 байта – ширина картинки (001E); ofsheight="10" – по адресу ofs+ofsheight берется 2 байта – высота картинки (001E); ofssize="14" – по адресу ofs+ofssize берется 2 байта – размер картинки (0384) байт (вычисляется как: ширина*высоту*цветность (цветность: 8 бит = 1, 16 бит=2, а вот 2 бита - наверно = 0,25)); ofsbpp="17" – по адресу ofs+ofsbpp берется 1 байт указывающий на цветность картинки; bpp="8=0A,16=06" – цветность 0A – 8 бит; 06 – 16 бит; ofsptr="20" – по адресу ofs+ofsptr берется 4 байта – адрес самой картинки в прошивке; lang="3;1-37=386,402 – подписи картинок, сопоставляется с языковыми ресурсами: 3 – возможно указание на язык (0 - немецкий, 1 - английский, 2 – французский, 3 - русский…) но не уверен, 1-37=386,402 – группа картинок в таблице начиная с №1 и по №37 сопоставляется с группой иконок «Лица» - о чем указывает индекс 386, далее индекс языковых ресурсов 402 – непосредственное название для картинки №1 («Афро»), далее индексы берутся автоматически по порядку: 403 для №2 и т.д. А вот в Agere идет такой тэг: <pictable title="Картинки" ofs="0x7B5340" count="949" reclen="8" ofswidth="0" ofsheight="2" ofsptr="4" bpp="09"> img index="0" title="" img index="1" title="" mg index="2" title="" </pictable> Все вроде тоже самое - такую конструкцию можно "натравить" и на наши прошивки, но вот с цветностью... х.з. не понимает она bpp="16" что ли, у меня черные квадраты повылазили... вручную ставлю 16 бит - работает

Петрович, не только Agere, в них видимо одна таблица на все картинки. А у нас этих таблиц море.... и бывает пустые, т.е. нисколько строк подряд ссылаются на одну и туже облать. А есть еще таблица таблиц!

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

AlexeyK, но в х140 русские же слова добавляются, выходит там есть база под русский язык? получается нас обделили

A-Droo, ага и ФотоЖоп и Ворд с Екселем Патч действительно стоящий! Respect stepan_v

Ustin, тебе итак крупно повезло! А ты еще перебираешь Довольствуйся тем что есть ведь эти прошивки на 99,9% одинаковые. Можешь попробовать перегнать символы на свою - вся инфа в хелпах

Не знаю как у обладателей Х100/Х600, а на Е630 (Е800/Е820) есть функция добавления новых слов в словарь Т9. Но корректно работает она почему-то только с английским языком. Русские же слова не заносятся. Алексей, ты не разбирался в принципе сохранения слов в Т9 и какое может быть этому объяснение?

правильно понимаешь, команда та же LDR, обрати внимание на адрес EED91770 - там непосредственно адрес 10C3151D. Так вот команда LDR - просто грузит в регистр его значение.... но со смещением кратным 4-м байтам, поймать можно перебором004F - обращение к тек.адрес + 4 байта 014F - обращение к тек.адрес + 8 байт 024F - обращение к тек.адрес + 12 байт и т.д. меняя первый байт пока не поймаешь я думаю очевидно, что и свой адрес 0x101119E68, ты должен размещать кратно 4 байтам. Попробуй в BinEdite в редакторе патче поэксперементировать, правя адрес в коде и глядя на мнемонику команды... BinEdit подскажет! Есть еще вариант, по идее удобнее... использовать встроенный компилятор BinEdit, он код сам рисует... но это совсем отдельная история ты опечатался? адрес и емкость регистров 4 байта! Ustin, как я делаю. я гружу прошивку с символьной информацией, для g1 - она неполная, а вот WK - для х100 - там SYM оригинальный, и ищу аналогичный код сначала там, разбираюсь чего он собственно выполняет и по аналогии делаю для своей прошивки (е630) если на твой тел. нет никакой символьной инфы... подбирай прошивки максимально схожие, можно попробовать перегнать символы на свою... а там уже сопоставляй. Принцип - ищешь аналогичную функцию которую затрагивает патч (если есть символы - по названию) и аналогично воспроизводишь. вот кстати есть для твоего тела оригинальный сум http://firmware.javer.sgh.ru/?frm=X460XEEB1&t=4

Garem!, парниша, ты реально халявщик по жизни! респектов гигантских ему хватает с головой, поверь мне... и от бренчания медалей сыт не будешь! Портирование таких мощьных патчей как ЧС и ED - сравнимо с их написанием с нуля! Зачем ему делать на телефон которого у него даже нет??? Вопрос ...а ты реально чем-нить помог??? ИМХО не надо здесь высказывать свое негодование. Есть личка... что в личку слабо? Есть тема обсуждения платных патчей... есть хотелка для е-серии... в конце концов... вот зайди туда и крикни: "хочу ЧС на халяву!!!"

1. Грузишь в регистр адрес переменной, сам адрес указываешь тоже в коде, чуть ниже, просто на него ссылаешься командой LDR 1137444C: 3549 LDR R0, =0x18A992CD и 11374524: 18A992CD DCD 0x18A992CD Данные для команды по адресу 1137444C 2. Грузишь в регистр значение оперативки по адресу в R0. Можно взять 1 байт по адресу 18A992CD - команда - LDRB R0, [R1], можно 2 байта (полуслово) LDRH R0, [R1], а можно и 4 байта в регистр запихать - LDR R0, [R1]. Значения регистров: в первом случае у нас получается R0 = 0x18A992CD R1 = 0x000000FF ' где FF - текущее значение оперативки во втором R0 = 0x18A992CD R1 = 0x0000AAFF ' где AAFF - взяли 2 байта: 1-й (AA) по адресу 18A992CD, а второй (FF) по следующему 18A992CE ну и со словом, то же R0 = 0x18A992CD R1 = 0xAABBCCFF ' где AABBCCFF - взяли 4 байта: 1-й (AA) по адресу 18A992CD, а второй (BB) по следующему 18A992CE и т.д.

igo, Garem!, привязать к подсветке и сделать новогоднюю елку не проблема... вечная проблема занимающая 95% времени написания любого патча и не всегда заканчивающаяся успехом - это поиск нужного кода. В данном случае необходимо найти переменную и/или функцию которая бы отвечала за мигалку MFF - полюбому это как-то отслеживается... ведь вибрация и мерцание диода - отнюдь не аппаратная реализация, как утверждают некоторые. У меня тоже раньше был С100 я перепрошивал его модифицированной прошивкой от С110 и про этот патч я знаю не по наслышке. Гораздо проще привязать к входящему звонку и сделать просто мигание... не под музыку, а скажем через 0,5 сек. CTAPbIY, прав весна пришла и желание бесконечно сидеть у компа улетает... (по роду деятельности очень много провожу за этим проклятым ящиком) да и мысли меня стали посещать нехорошие... а не продать ли мне свой е630? ******************* понимаю... весна - есть весна зы ждал два годва - ещё обожду... не к спеху не столько нужен результат - сколько процесс воплощения "хотелки" этой... редакт

В ближайшее время скину всем подписчикам х100 новую версию. Отдельное спасибо Старому.

Mako, эквиваленты определяются по использованию адресов оперативки в аналогичном коде, т.е. ищется та-же функция где используется та же переменная - соответственно ее адрес будет дугой. С записью все просто: 1. Аналогично грузится в регистр адрес оперативки. Как ты уже указал. 2. Коммандами STR, STRH, STRB записывается в указанный адрес значение другого регистра. STR- пишется т.н.слово (4 байта подряд), STRH - полуслово (2 байта), STRB - либо байт

Патч Charging Light Оff Ну вот и сбылась одна из моих давних хотелок! Честно говоря, меня жутко выводило из себя, что подсветка телефона не выключалась во время зарядки. Во-первых это дополнительный расход эл.энергии что отрицательно сказывается на времени процесса зарядки, во-вторых, когда телефон зарядился – свечение подсветки его разряжает АКБ. Ну а в-третьих, лицезреть ночью, как он светится не очень то и приятно. Вот подправил всего 4 байта, а результат превзошел все мои ожидания! Теперь во время зарядки включаются цифровые часы. А когда телефон заряжается выключенным включить подсветку можно коротким нажатием на клавишу вкл./выкл. Для портеров: в функции hen7_87LCDMainlightFullOff необходимо убрать проверку переменной s_env_DeviceStatus Charging_Light__ff.rar Charging_Light__ff.rar

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

vvyura, вот это веЩь!!! хоть кто-то популярно расказал, спасибо огромное будем копаться О результатах расскажу. Возник только вопрос. Сделай выкладку кода где проверяется выбраный пункт, т.е. наверно проверка глобальной переменной.

dr-dimick, уж поверь мне адрес вызова обработчика клавиш один... клавишь много, а обработчик один. Чтоюы завязать разные действия на разные кл. - нужно писать патч. У меня пока в этом потребности нет... игра свеч не стоит. Lee_Forever, у меня все прекрасно пашет. У тебя АТС городская сколько цифр?

dr-dimick, CTAPbIY, есть еще один адресок на удержание любой из цифр от 2 до 9... цифр много, а адресок один . На х100 и х600 уже известен,ну и на наше тело можно без труда отыскать.

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

Америку не открою, но все же выложу свои соображения по оптимизации кода. Если обращали внимание, размер оригинальной прошивки телефона е630 (файл .cla) составляет порядка 13,3 мб. Притом флешка под это дело-то на 16 метров! Конечно помимо прошивки еще 2 мб - EPROM, но остается еще порядка 700 кб – неиспользуемого кодом места. Так вот, монополия на эти 700 кб у нашей замечательной программы ResMan. Область «свободного» места задается в карте ресурсов (e630xe###.rxt) тэгами… Данная область используется при замене стандартных мелодий, шрифтов, языковых ресурсов, а вот картинки программой меняются поверх существующих. А теперь посмотрим, что же реально происходит. Итак, есть 2 варианта замены контент-начинки телефона: поверх исходных ресурсов, либо добавлением в конец прошивки нового ресурса и перебивкой табличных ссылок на данную область кода. Очевидно, что в первом варианте мы упираемся в размер исходного ресурса и не можем его увеличить, т.е. к примеру, ставя мелодию поверх существующей ее размер не должен превышать оригинала. Но в ResMan’e реализована другая логика – старая мелодия остается в коде прошивки, а новая добавляется в конец, перебиваются только ссылки (именно поэтому существует возможность вернуть все назад). Прошивка соответственно увеличивается в размерах на величину добавляемых ресурсов. С заменой графических ресурсов все наоборот – они замечательно встают поверх существующих один в один, т.к. размеры идентичны, про них речи вести не будем. Если после того, как вы залили прошивку, размер которой некоторым образом отличается от стандартной, вдруг опять решите поменять прошивку размер которой меньше, то «хвост разницы» естественно останется на флешке, на работе телефона это никак не отразится… останется неиспользуемый мусор. Мне представляется, что логичнее было бы предоставить выбор пользователю менять ли ресурсы поверх – с ограничением на исходный размер или добавлять в конец. К сожалению, в ResMan’е такая возможность отсутствует. Возникает вполне обоснованный вопрос, а все ли полностью используют эти 700 кб.? При разработке патчей я не вижу смысла теснится и приносить в жертву «неиспользуемые» ресурсы (иногда они даже очень используемые, ИМХО залазить на хохлянский язык не очень-то и хорошо), когда есть место в конце прошивки. Вот, к примеру, всеми известный автор патча «Черный список», Vadiks, принимая во внимание размеры последнего, уже не стал искать «неиспользуемые» ресурсы, а разместил код в конце бина, что вполне логично. Очевидно, что с ростом количества и размеров патчей, данная тенденция будет усиливаться и поиск «свободных» неиспользуемых участков прошивки будет занимать уйму времени и отобьет всякое желание что-либо делать. Я предлагаю оставить хотя бы часть свободного места для разработчиков. Теперь об ограничениях, на которые мы натолкнемся. Те 700 кб, о которых я говорил, придется делить с ResMan’ом. Т.е. к примеру, если кто-то уже у себя поменял мелодии, то разместить патчи поверх мелодий уже не получится. Кто будет двигаться? Разработчики или пользователи? Я считаю, что приоритет должен быть у патчей, а замена контент-ресурсов должна проходить по остаточному принципу. Отсюда вытекает еще вопрос, резервировать место для кода патчей можно в начале или в конце нашего блока в 700 кб. Если для патчей будет использоваться место в конце «коридора» то проблемы совместного использования сведутся к минимуму… но это вызывает определенные неудобства в размещении кода «от конца», т.е. определяя начальный адрес тела патча от последнего - по его длине (можно конечно и от фиксированного куска, скажем, начиная с 500 кб, но это опять же не оптимально, т.к. заранее резервируется 200 кб неизвестно под что). С точки же зрения пользователя этот вариант предпочтительнее в том плане, если 700 кб ранее были использованы не полностью, то наложения не произойдет. Второй вариант – размещая код в начале нашего блока, мы сразу натолкнемся на наложение. В любом случае указанных проблем не будет, если сначала уменьшить размер свободного блока в карте ресурсов, на размер патча, а потом уже менять контент-ресурсы в ResMan’e. Порядок установки патча будет выглядеть следующим образом (вариант размещения патчей в конце «свободного» блока): 1. В описании патча, автор указывает конечный адрес оставшегося свободного места, который пользователь правит в карте прошивки. 2. Собственно установка патча. Следующий патч, опять потребует места и соответственно, опять правим адрес в карте. Конечно, устанавливая несколько патчей необходимо просто указать последний. Оптимальным вариантом, конечно, было бы научить ResMan определять последний из адресов свободного места. А можно и вручную. Здесь уже возникает такое понятие как последовательность патчей, т.е. каждый патч идет следом друг дружкой, логично было бы присвоить каждому порядковый номер. И уже из группы патчей, которые устанавливает пользователь, он ориентируется на самый большой и берет соответствующее ему значение адреса. Вариант, если идет доработка патча, уже после, тоже возможен… конечный адрес опять меняется, а порядковый номер соответственно увеличивается. Можно пойти еще дальше и сделать темку на форуме-табличку «патч-номер-адрес». Вот такие вот соображения…