f2065

Посмотреть в меню при разговоре - можно ли там добратся до SMS. Если да - то позвонить с другого телефона при работе браузера, звонок имеет приоритет выше и временно приостановит работу браузера, а из него уже можно посмотреть смску. Ну или портировать патч для сворачивания Java, затем использовать MiniOpera которую можно будет в любой момент свернуть и посмотреть смс.

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

Это русская локализация.Slave - там напрямую без ptt указывается cla/clas файлы

Да, прошивку надо патчить. Без прошивочного кабеля можно и обойтись, хотя рисковано. Особенно если сейчас стоит древняя прошивка, а не B5722XXJK3. В шапке темы всё описано.

Нет. Ну вроде очень давно для какого-то Swift такой патч делали. Тут я не считаю что он нужен. Память явы и так расширяется до 16мб, плюс ява легко переустанавливается. Можно JAR-дистрибутивы игрушек хранить на флешке, а из памяти их удалять и ставить по мере надобности. Как это сделать давно описано в FAQ. MOBILedit! с SMSками работает лучше… Kies помнится длинные русские смс не видел… Ну и обратно из компа залить в телефон их врядли получится.

Для Master и CSC (Slave не трогать)… Их надо открыть в блокноте и в обе стороны заполненные строки скопировать вместо нулей. Файлы должны быть одинаковые в итоге… B7722XEKK1_OXEJH1_MD5fix.rar B7722iXEKK1_OXEKC2_MD5fix.rar

Прошивка не битая. Надо перекрёстно слить md5 файлы и имеющийся флешер её зальёт. Касается кстати все новых прошивок про которые тут кто-то сочинил что они сервисные… Исправлений не будет, там нечего исправлять - все контрольный суммы верные. Просто старому флешеру надо объединить мд5, он по частям неадекватно реагирует.

надо выполнить слияние md5, и имеющийся флешер заливает

Это умышленная опечатка, историческая традиция типа… C3200GXXKJ1 могут быть с разными локализациями… По правильному надо прошивку называть C3200GXXKJ1_OXEKJ1. Но ранее когда прошивки были одним файлом с уникальными локализациями - XE - это было Россия. А написать в шапке - C3200GXXKJ1 - так сейчас куча народу будет спрашивать а где взять русскую прошивку, а почему автоподсказка локализаций пишет что в этой XX-прошивке нет русского и т.д. Вообще надо конечно глобально обновлять БД хранимых прошивок (этому нововведению с отдельной локализацией уже года 2), но…

Не всё так просто… Половина реально рабочего кода вынесена в PAGE.partition_name="PAGED" partition_path="B7722XE.cla\ER_PAGE_FLASH_CB" partition_size=0x1400000 А оно распаковывается в размер 0x1EBD950… Ну и ещё напомню что B7722 на Swift не очень то похож - не понятно что там за патчи делать. А вот у C3520 например уже местом так не разбрасываются: в ptt размер MAIN-партиции 0xC00000, а распаковывается оно в 0x119ED1C. Но в принципе если глобально понять логику всей прошивки - то можно и незапакованное залить… Там же NAND всё равно огромная. Принести в жертву часть пользовательской памяти… Ну поля заголовка более-менее понятны, и все существующие поля - показаны в QMDC_Util.У незапакованных файлов: block size = 0, и packed data = unpacked data. А удаляет распаковщик не только заголовок но и сектора QMDU, которые очевидно важны но не понятно зачем в их обработке вызывается типа LDCLT p13,C14,[R0] и всё. У B7722 кстати они вообще встроены в QMDC-архив и видны только после распаковки. Причём их обработка влияет на флаги и дальнейшую распаковку (там в непонятных ситуациях выводится предупреждение checkpoint). А у меня нет реального B7722 чтобы запуская в нём понять правильно ли у меня воспроизведена эта логика… Выходной файл может иметь вкрапления посторонних данных (надо абсолютную адресацию в нём проверить на соответствие по смыслу, в начале и в конце CLA, но пока ещё не думал над этим). Прошивка C3520 распаковывается корректно полностью, проверено с реальной мобилой.

У новых Swift-3G (S5610 C3520 B7722 и т.п.) прошивки запакованы. Однако, оказалось что Samsung ничего нового не придумал, и там всё тот же уже известный алгоритм Quram с минимальными отличиями. У этих телефонов нет NOR+NAND памяти, а только медленная NAND. Прошивка в телефоне так и хранится запакованной, а при включении быстро разархивируется в ОЗУ и работает там (распаковку производит функция в .bootloader). Теперь вот (при помощи alex999_ и vvyura) есть утилита для распаковки таких запакованных прошивок. Про формат прошивки замечу что сектора QMDC - это те которые распаковываются, а вот QMDU - это сектора которые очевидно не сжаты и копируются как есть (хотя в распаковщие как-то используется DSP-сопроцессор для них) и пока про них более ничего не понятно. Некоторые сектора не сжаты - видимо те что плохо сжимались - и они передаются на выход целиком. Пока обратно запаковать распакованную прошивку нечем. А залить в мобилу незапакованную прошивку видимо нельзя - в частности потому что места не хватит. Однако, раз прошивка работает в ОЗУ - можно например модифицировать .bootloader чтобы он после распаковки прошивки накладывал на неё в ОЗУ необходимые патчи. Ну как на Qualcomm это реализовано… ER_FLASH_CB_MAIN - это обычно основной файл прошивки. ER_FLASH_CB_PAGE, ER_FLASH_CB_ROOT, ER_FLASH_NCB_DSP, ER_RAM_CB - пока не понятно. Ясно только что все эти файлы кроме PAGE - содержат прямой массив QMDC/Unknown/QMDU-секторов, а вот PAGE - имеет в начале таблицу расположения секторов и сектора в таблице перечислены не по порядку. Предположительно в PAGE вынесены редкоиспользуемые функции вшитые в прошивку - типа всяких инет-клиентов - они распаковываются по мере надобности. Версия от 2012.01.30 04:04 -QMDC_Util_201201300404.rar отличия от предыдущих: добавлена поддержка ZLib (теперь распаковываются файлы с partition_compression_algorithm 0 (ZLib) и 2 (QMDC), улучшен алгоритм поиска сжатых блоков, многочисленные мелкие оптимизации и багфиксы. Версия от 2012.03.22 22:04 -QMDC_Util_201203222204.rar отличия от предыдущих: добавлена распакова PAGE-файлов, для quram проверена работает точно, для zlib вероятно неправильная (у меня мобилы с zlib нет - сравнить RAM-дампы не могу). Версия от 2012.04.16 15:51 -QMDC_Util_201204161551.rar мелкие отличия от предыдущих: подписано поле +C в заголовке, чекбокс-переключалка регистра букв контрольной суммы.

Вероятно имя в разных полях… У одного заполнено "отображать как", а у другого собирается из "имя"+"фамилия".

Таблица словаря такая же, но алгоритм немного другой (компрессия явно хуже, но распаковывается существенно быстрее). Сигнатура у него QMDC (ещё есть QMDU - они заливается в DSP как есть). Вспоминаем D880… Slave - sysol… Так что Master и Slave могут быть разные. Так вот более новые Swift 3G (S5610, C3520) - которые имеют такую же запакованную структуру из MAIN и PAGE - классические Swift… Не понятно где наследники B7722… Подозреваю что есть, хотя явным образом не видел. Только косвенные факты… Флешер использует криптографические фукнции… Но все файлы прошивок однако не зашифрованы, QMDC-декомпрессор без всяких ключей это распаковывает. Вероятно как-то это связано с DSP - почти все файлы прошивок при распаковке передают ~1кб блок в DSP-сопроцессор как есть… А чего там DSP делает - незнаю как понять. Не, флешер передаёт в телефон как есть. Телефон при каждом включении распаковывает всё в ОЗУ. Хранится оно в телефоне в NAND, а NOR у них вообще нет (для Master). Причём доп.функции типа всяких клиентов вынесены в отдельную половину прошивки (PAGE) которая распаковывается по мере надобности.

Ну, некоторые оптимисты считают что это реально… Я только распаковщик написал пока… И всё-же B7722 - это не Swift. Вот например C3520 который имеет такую-же структуру прошивки и так же запакован - после распаковки на Swift похож. Есть многочисленная трассировка "mcc_", есть сама таблица MCC находимая по сигнатуре MCC_EDIT например, и показываемая в твоей версии BinEdit… MCC-скрипты знакомые… А вот с B7722 - всё совсем не так… И имена функций которые там попадаются совсем не знакомые, и вместо MCC какой-то другой скриптовый язык с командами типа PROCESS_WIFIMAIN PROCESS_EMAIL PROCESS_GIMAGING_TASK_14 PROCESS_GIMAGING_TASK_15 PROCESS_GIMAGING_TASK_16 - и их несколько тысяч… Я думаю что запаковывать прошивку назад - нецелесообразно. Всё равно у неё видимо подписи не совпадут. Надо модифицировать лоадер чтобы он накладывал патч в ОЗУ после распаковки.

А с чего ты взял что у него должно быть отображение адресов БС ? Вообще такое только патчами делается, а у него с патчами пока туго (хотя некоторые подвижки есть - прошивка распаковывается и в BinEdit открывается, но тестировать видимо некому). У Swift нетмонитор выводится кодом *#0206*DBG# - но тут похоже это не сработает…

Причём потом надо сменить дефолтную симку (меню доступно только для master) и отключить эти услуги для второй тоже если есть.

Билайн ?

Это вероятно не для уровня СЦ - в сервисмануалах этого нет… Это для самих программистов… По кодами ошибок можно найти место прошивки откуда ошибка была инициирована. Вот.

Реально, если предустанавливать jar и соответствующую БД напрямую в TFS. Встроенный софт не инсталлируется, он изначально прописан в TFS уже в установленном виде. Смотри как это сделано в .csc (тоже tfs). А иконка вшита в системное меню, её так просто не сменить (нужен конвертер qmg-графики).

прошивкой - не должно… надо менять плату или может что-то на ней перепаять… надо нести в СЦ.

41000001 - Облом с dfd0_0WriteWordFlash… NOR-флеш дохнет ? 3C0125B1 - hen1_42SlavePowerOnOffEvtHandler Вобщем это какие-то проблемы с железом Slave - не отзывается в положенное время, может коррозия платы или просто от возраста деградация электроники. Вероятно будет работать только с одной симкой (Master)

Ну поищи на samsung.ru - там есть русские контакы… Но я думаю что там без разницы что на русском что на английском - читать их не будут. А сами разработчики очевидно говорят на корейском… Да никогда они не реагировали на баги, те или иные баги есть во всех самсунгах… Имхо единственный вариант - личным визитом в официальный СЦ, чтобы описание бага было задокументировано в СЦ и ушло по внутренним каналам СЦ.

А чего пишет в логе ошибок - *#0206*377# ?

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

86090003 - вызывается в ani_timer_display (какая-то анимация и установка wallpaper), если в буфере NumOfAniFrame - ноль.Я думаю у тебя стоит сторонняя графика, в прошивке или в TFS. Или может какие-то патчи косвенно ломают графику… Там не адреса, там коды ошибок. Открыть прошивку в BinEdit и поискать места использования кода, в din3_0GeneralDefense. Если нет - то поискать соседние - в данном примере там адрес 86090004-1 а не 86090003 (такие особенности оптимизации thumb-кода). Проще смотреть в соседних прошивках на которые есть sym/elf, например D880JVHF1 - сразу имена понятны. 20127756: CE4A LDR R2, =NumOfAniFrame 20127758: 105C LDRB R0, [R2, R0] 2012775A: 0028 CMP R0, 0 2012775C: 05D1 BNE loc_2012776A 2012775E: CB49 LDR R1, =0x86090004 20127760: 0139 SUB R1, 1; 0x86090003 20127762: 0120 MOV R0, 1 20127764: 6EF7DCE8 BL _din3_0GeneralDefense