OUT-CLUB.RU - Исследование механизма работы ПО MMCS

OUT-CLUB.RU (https://out-club.ru/board/index.php)

- - Исследование механизма работы ПО MMCS (https://out-club.ru/board/showthread.php?t=37735)

Re: Исследование механизма работы ПО MMCS

Здравствуйте, господа. Извиняюсь, что вторгаюсь в вашу неспешную беседу.
я тут в соседней ветке вопрос задавал, но там, видимо мимо как-то прошло... да и, судя по всему, тут он более уместен.

Сильно подозреваю, что единственное препятствие для проигрывания видео с USB порта в системе исключительно програмное. Как бы это дело обойти?

з.ы. у меня система r-03

Re: Исследование механизма работы ПО MMCS

Цитата:

Сообщение от Gun78 (Сообщение 1067086)

Понятно. А контрольных сумм там никаких нет? Т.е. можно WinHex'ом подправить что надо прямо в файле loading.kwi и все?

Есть ,но не всегда они критичны для системы.WinHex'ом не проблема подправить,проблема найти где и что.:)

---------- Добавлено в 17:01 ---------- Предыдущее сообщение было написано в 16:51 ----------

Попробовали воткнуть модуль нави.ехе с русской проши на американку, не вышло система постоянно перегружается, хотя при прямой заливке русского лодинга в американскую голову модуль нави прекрасно работает.
Вот переделанный лодинг http://4pda.ru/forum/dl/post/1109746/LOADING_NEW.rar
извлечённые прошивки http://4pda.ru/forum/dl/post/1109638/Mitsubishi.rar
Может кто посмотрит сам лодинг переделанный, подсказывают что контрольные суммы могут не соответствовать.При сравнении Нех-редактором исходного лодинга американки и переделанного,чётко виден сектор разницы, может спецы могут чего посоветовать?
Американский лодинг исходник http://files.mail.ru/SNDUTA

Re: Исследование механизма работы ПО MMCS

Есть интерес попробовать заменить текстовые константы одного из языков на другой (т.е. поменять содержимое таблиц типа - /ScreenData/AV/GS_AV_STRING.tbl). С форматом таблицы еще разобраться можно - но что делать с loading.kwi в котором эта таблица лежит и из которого будет периодически распаковываться? Есть ли у кого опыт по засовыванию в лоадинг файла другого размера нежели оригинал - т.е. не побайтная корретировка, а именно перезапись по сути всего лоадига...

Re: Исследование механизма работы ПО MMCS

А вот внутренности блока БТ никто поизучать не желает?
https://www.out-club.ru/board/showpo...&postcount=179

Код:

22/08/2011  12:35 PM    <DIR>          .

22/08/2011  12:35 PM    <DIR>          ..

21/04/2011  05:55 PM    <DIR>          backup

21/04/2011  05:55 PM    <DIR>          executables

21/04/2011  05:55 PM               379 main_instructions.ini

21/04/2011  05:55 PM               296 versions.ini.gz

21/04/2011  05:55 PM    <DIR>          whole_nand

21/04/2011  05:55 PM    <DIR>          whole_nor

Re: Исследование механизма работы ПО MMCS

Цитата:

Сообщение от Gun78 (Сообщение 1067086)

А контрольных сумм там никаких нет?

Элементарно проверяется.
В любом exe, не относящемся к ОС (т.е. во второстепенной прикладной программе) правится один байт (конечно, лучше знать какой, но в целом это не важно, если файл не относится к драйверам и программам, стартующим автоматом).
Если заливка правленной прошивки проходит успешно, значит никаких чексумов не проверяется и делать можно очень много чего.
Естественно, после загрузки эту программу запускать не рекомендуется, если вы правили байт в секции кода, если же в секции данных (например, символ в строке), то можно запустить и посмотреть результат. Правка секции кода предпочтительна, т.к. это исключит сразу все сомнения относительно контрольных сумм, т.к. именно эти секции подлежат защите в первую очередь.
Только нужно помнить, что некоторые регионы модулей изначально сжаты, поэтому если поправить тупо, можно не достичь нужного результата, посему (если не умеете читать прошивки без инструментов) делаем так:
- разбираем прошивку, например, Remaker'ом;
- находим секцию кода модуля JitDbgr.EXE, после работы Remaker'a это файл S000 в соотвествующем директории;
- выбираем запоминающуюся последовательность из 15-20 байтов;
- открываем прошивку (лоадинг) в хексредакторе, находим последовательность байтов, которую запомнили;
- убеждаемся, что такая последовательность в прошивке только одна (т.о. мы точно знаем, что правим в нужном месте), иначе придется выбрать другую уникальную последовательность.
правим один байт;
- льем прошивку в дивай и смотри результат заливки.
По крайней мере, вы наконец узнаете есть ли в буте проверка контральных сумм :)
Ясно, что делать это может только человек, представляющий, что делает, иначе вся отвественность и риски на вас, с меня взятки гладки: у меня нет такого дивая, чтоб восполнить вашу потерю, если она случится (кто понимает, - знает, что ничего плохого случиться не может, если делать как я написал).

Re: Исследование механизма работы ПО MMCS

Я готов пробовать на своём девайсе ,но адекватно править не смогу.
Какой один байт править в последовательности? И сколько раз ,пока тыком не подберём КС?
Пробывал вьювером открывать прошивку выбирать файл и подставлять некоторую последовательность из него в поиск НЕХ-а, но совпадений не находит

Re: Исследование механизма работы ПО MMCS

Цитата:

Сообщение от PUSHIK (Сообщение 1089990)

но совпадений не находит

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

Re: Исследование механизма работы ПО MMCS

Вот, например, кусок loading.kwi, который вы выкладывали на 4pda. Это фрагмент именно секции кода файла JitDbgr.exe. Я специально выбрал место, где лежат простые строки в уникоде.
Можете пропатчить их, как вам нравится (достаточно и одну букву, патч в этих строках абсолютно безопасен.) и попытайтесь залить прошивку в дивайс. Если не примет, значит проверки есть, если примет, значит руки для дальнейшего ковыряния развязаны, что в этом случае делать дальше я писал пару дней назад в личке Ежику Пыху.
Здесь лишь замечу, что для инъекции можно воспользоваться тем обстоятельством, что донорский navi.exe по размеру меньше того, что лежит в этой прошивке.

Успехов.

ЗЫ: И где тут кнопка "Изменить"?

Re: Исследование механизма работы ПО MMCS

Поменял. Идет update и черный экран.

Re: Исследование механизма работы ПО MMCS

Цитата:

Сообщение от PUSHIK (Сообщение 1090993)

и черный экран.

Моя вина.
Я почему-то понадеялся, что вы, прочитав информацию на 4pda, уже знаете о существовании стандартных контрольных сумм записей формата B000FF и смените ее самостоятельно. Речь идет о двенадцати байтах заголовка каждой записи (три поля по 4 байта каждое), которые представляют собой следующую информацию:

Код:

Record Address      4     Physical starting address of data record. 

Record length        4     Length of record data, in bytes.

Record checksum   4     Signed 32-bit sum of record data bytes.

Соответственно, изменив даже один байт вы должны пересчитать Record checksum для этого региона и изменить ее.
Физически в прошивке этот заголовок лежит непосредственно перед самим регионом, который описывает.
Я сейчас на работе и под руками нет вашей прошивки. Вечером, если надо, покажу где это и как это.
Для работы по-прежнему достаточно Remaker'а и WinHex'a.

Re: Исследование механизма работы ПО MMCS

Если несложно. Знаю что есть КС ,но где и методику расчета не знаю.Можно на примере,это заменить то на то .. А я попробую что выдит.

Re: Исследование механизма работы ПО MMCS

Цитата:

Сообщение от PUSHIK (Сообщение 1091465)

Можно на примере,это заменить то на то ..

Это можно. Имея немного времени для чтения, вы бы могли сделать это проще, используя лишь карту прошивки, полученную из Remaker'a, но по-скольку нужных знаний у вас пока нет, пойдем окружным путем, как говорят в армии, по разделениям.
Работать будем с той извлеченной из контейнера прошивкой, которая прилеплена в аттаче (она, как вы помните лежит в контейнере LOADING.kwi по смещению 0х0006F000) и самим LOADING.kwi.
Для работы нам понадобятся Remaker for WinCE5 и WinHex, если не знаете, где взять последний могу выложить.

И так:

Открываем прошивку (NK.bin) в Remaker'e (в меню левой панели File -> Open ROM) и, когда она загрузится, выполняем в меню правой панели View -> Map Project NB0. Эти действия приведут к тому, что в директории, где лежит Remaker, появится папка NB0, в которой будет находиться разобранная на составляющие части прошивка, ее карта - MAP.txt и много других полезных файлов (Рис. 1).
Запускаем WinHex и открываем в нем наш контейнер LOADING.kwi, затем находим в папке Remaker'a файл S000 в директории \NB0\OUT\MODULES\JitDbgr.EXE\ и тоже открываем его в WinHex'е - это и есть секция (регион, если говорить в терминах прошивок) кода файла JitDbgr.exe в том виде, в каком она лежит в прошивке (Рис. 2).
В WinHex'e переходим на закладку S000 и выделяем мышкой первые шестнадцать байт (можно и не 16, важно просто что бы они были уникальными) и копируем их в буфер обмена: Edit -> Copy Block -> Hex Values.

Re: Исследование механизма работы ПО MMCS

Продолжим:

Рис. 3 относится к п.3 предыдущего поста.

Переходим на закладку LOADING.KWI и находим начало нужного региона, выполнив Search -> Find Hex Values... В поле ввода открывшегося диалога вставляем из буфера обмена сохраненную последовательность из 16 байтов и нажимаем кнопку OK (Рис. 4).
После выполнения этих действий курсор должен установиться на начало нужного региона нужного файла (смещение 0х00E20A8F). Однако, если выполнить повторный поиск (нажав клавишу F3), мы убедимся, что найдена еще одна такая же последовательность, и еще одна, и еще. Вывод: к сожалению, последовательность оказалась не уникальной. Такую проверку нужно проводить всегда, чтобы быть уверенным, что найден именно тот фрагмент, который нужен.
Возвращаемся на закладку S000 и выбираем другую последовательность байтов для поиска, например, следующие 16 байт и копируем их в буфер обмена. Снова идем на закладку LOADING.KWI и повторяем попытку поиска, как описано выше (Рис 5). Нажатием F3 убеждаемся, что такой последовательности в контейнере больше нет и это именно то, что надо.
И так, нужная последовательность найдена по смещению 0x00E96613, но ведь это вторые 16 байт из файла S000, значит сам регион начинается по смещению 0x00E96613 - 0х00000010 = 0х00E96603. Рассмотрим заголовок региона, те 12 байт, что предшествуют собственно региону и обведены на Рис.5 красной линией. Первые четыре байта это смещение региона 0х8E82C000 они нас в данном случае не интересуют. Вторые - длина региона 0x0003EFFC. Третьи - его контрольная сумма 0x0188EB68. Обратите внимание, что чтение выполняется справа налево.

Re: Исследование механизма работы ПО MMCS

Продолжим.

Выполним еще одну маленькую проверку. Поставим курсор на начало региона по смещению 0x00E96603 и выделим весь блок прошивки, которую этот регион попал. Для этого выполним Edit -> Define Block... В первое поле введем смещение начала блока 0x00E96603, а справа из выпадающего списка выберем Beginning of block. Во второе поле введем смещение конца блока, для чего к смещению начала добавим длину блока, полученную из заголовка блока: 0x00E96603 + 0x0003EFFC = 0x00ED55FF. Вводим это значение во второе поле, а справа, естетственно, выбираем End of block и нажимем OK (Рис. 6). Теперь расчитаем контрольную сумму этого блока: Tools -> Compute Hash... и в откывшемся диалоге выберем Checksum (32 bit) и получим результат 0188EB68, сверив его с третьим полем заголовка, убеждаемся, что она записана именно здесь.
Теперь начинаем патчить прямо в WinHex'е. Недалеко от начала региона видим строку "Count Overflow." Заменим ее на "Count money....". Саму замену производим в правой панели WinHex'а, только обратите внимание, что это уникод, т.е. на каждую букву, пробел или точку приходится 2 байта, второй из которых нулевой. Выглядеть это будет так, как на Рис. 7. После чего выполняем File -> Save или Save As..., чтобы сохранить наши изменения.
Понятно, что после изменения содержания блока изменилась и его контрольная сумма и соответствующее поле заголовка нужно пропатчить новым значением. Если вы случайно сняли или изменили выделение блока, повторите операции его выделения и расчета контрольной суммы блока, как описано выше (п. 1 этого поста). Полученное значение внесите в третье поле заголовка блока, только не забудте перевернуть его справа налево. Если сумма, например, получилась 01020304, то записать нужно 04 03 02 01. Снова выполните сохранение файла, как описано в предыдущем пункте (п. 2) и пробуйте его заливать.

Прилепить вычлененный из контейнера LOADING.KWI файл прошивки NK.bin для упражнений в Remaker'e в аттач не удалось, поэтому качаем здесь - http://ifolder.ru/25370044.
Готового "это заменить на то" не даю, это не интересно. Экспериментируйте.

Re: Исследование механизма работы ПО MMCS

Пошёл переваривать ,не знаю вернусьли.

Re: Исследование механизма работы ПО MMCS

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

Re: Исследование механизма работы ПО MMCS

Цитата:

Сообщение от PUSHIK (Сообщение 1093391)

Женя, ты невнимательно читал предыдущие мои и cvy7 посты. Там больше половины драйверов и шрифты внутри .ехе упакованы. Я на выходных буду пробовать озвученное Mi81 предложение, тогда всё станет ясно.

Re: Исследование механизма работы ПО MMCS

Цитата:

Сообщение от Ёжик Пых (Сообщение 1093413)

Читал я внимательно ,но половину неосмыслил.:blush:

Re: Исследование механизма работы ПО MMCS

Цитата:

Сообщение от Mi81 (Сообщение 1091793)

Выполним еще одну маленькую проверку. Поставим курсор на начало региона по смещению 0x00E96603 и выделим весь блок прошивки, которую этот регион попал. Для этого выполним Edit -> Define Block... В первое поле введем смещение начала блока 0x00E96603, а справа из выпадающего списка выберем Beginning of block. Во второе поле введем смещение конца блока, для чего к смещению начала добавим длину блока, полученную из заголовка блока: 0x00E96603 + 0x0003EFFC = 0x00ED55FF. Вводим это значение во второе поле, а справа, естетственно, выбираем End of block и нажимем OK (Рис. 6). Теперь расчитаем контрольную сумму этого блока: Tools -> Compute Hash... и в откывшемся диалоге выберем Checksum (32 bit) и получим результат 0188EB68, сверив его с третьим полем заголовка, убеждаемся, что она записана именно здесь.

Mi81, Спасибо за столь подробный ликбез, теперь отчет.

Дополнительных КС в Navi.exe похоже нет. В S001 Navi.exe исправил C.u.r.r.e.n.t на O.l.d.r.e.n.t, пересчитал СS32, залил на HDD, всё прекрасно запустилось, разницы в работе не заметил.

Решил пойти дальше и претворить Вашу идею по переносу в жизнь, но наталкнулся на несоответствия. Основа, LOADING.KWI N-04, выложенная Пушик'ом http://files.mail.ru/SNDUTA. Все смещения даю от полного LOADING.KWI не разделенного на части.
После римейкера получаю 4 региона S000-S003 и просто начинаю проверять в прошивке.
S000 | 7E2A6B-D1E286 - заголовок соответствует, CS32 совпала ;
S001 | D1EA83-E20616 - заголовок соответствует, CS32 совпала ;
S002 | EFA16F-EFC71D - заголовок отсутствует или не верный, длина 25AF, CS32 - 0011CE6F
S003 | EFC72B-E1638B - в заголовке неверно указана длинна (00019С64/ реальная 00019С61), CS32 по длине 00019С61 - верная.

Насколько я понял Вашу идею, я перекидываю из R03 регионы в N04, смещение оставляю на месте, исправляю длину и CS32, оставшееся место забиваю нулями. В этом раскладе не ясно, что делать с S002.
Особенностью S002 и S003 является то, что они идут друг за другом и видимо данные о CS и длине расположены немного по другому.

Прошу Ваших комментариев/правок/дополнений.

Re: Исследование механизма работы ПО MMCS

Ну вообще-то, эксперимент, который я описал выше касался лишь установления факта наличия/присутствия контрольных сумм, потому что на практике не каждый регион пакуется отдельно. На самом деле один блок прошивки может включать неколько регионов. Именно этот случай, видимо, вы имеете с S0002. Т.е. заголовок есть, но он где-то выше. Если знакомы с программированием, то написать утилиту, которая вычислит смещения всех заголовков блоков и принадлежащих им блоков данных дело 15-20 минут. Думаю, справитесь ? Если нет, воспользуетесь готовой - viewbin.exe из комплекта Platform Builder'а. Должны получить это:

список боков

D:\>viewbin -r nk_04.bin
ViewBin... nk_04.bin
Image Start = 0x8DA00000, length = 0x010E9960
Record [ 0] : Start = 0x8DA00000, Length = 0x00000010, Chksum = 0x000002E1
Record [ 1] : Start = 0x8DA00040, Length = 0x00000008, Chksum = 0x0000035B
Record [ 2] : Start = 0x8DA01000, Length = 0x00033F8C, Chksum = 0x011956E8
Record [ 3] : Start = 0x8DA35000, Length = 0x00001FFC, Chksum = 0x000AA7BA
Record [ 4] : Start = 0x8DA37000, Length = 0x000496D8, Chksum = 0x01A41F8F
Record [ 5] : Start = 0x8DA806D8, Length = 0x00001910, Chksum = 0x0006B023
Record [ 6] : Start = 0x8DA82000, Length = 0x00018FA8, Chksum = 0x00885154
Record [ 7] : Start = 0x8DA9B000, Length = 0x00013F40, Chksum = 0x006707E5
Record [ 8] : Start = 0x8DAAF000, Length = 0x00013E98, Chksum = 0x00728952
Record [ 9] : Start = 0x8DAC3000, Length = 0x00016FE8, Chksum = 0x006BAF3E
Record [ 10] : Start = 0x8DADA000, Length = 0x0001AF9C, Chksum = 0x00960AEA
Record [ 11] : Start = 0x8DAF5000, Length = 0x0001BFBC, Chksum = 0x009477BB
Record [ 12] : Start = 0x8DB11000, Length = 0x00014FF0, Chksum = 0x0079D043
Record [ 13] : Start = 0x8DB26000, Length = 0x00002D6C, Chksum = 0x0010060B
Record [ 14] : Start = 0x8DB29000, Length = 0x00009E58, Chksum = 0x00376A3D
Record [ 15] : Start = 0x8DB33000, Length = 0x0003F000, Chksum = 0x01627928
Record [ 16] : Start = 0x8DB72000, Length = 0x0003DE2C, Chksum = 0x016580B6
Record [ 17] : Start = 0x8DBB0000, Length = 0x0000C994, Chksum = 0x0048D131
Record [ 18] : Start = 0x8DBBD000, Length = 0x00000994, Chksum = 0x00047B78
Record [ 19] : Start = 0x8DBBE000, Length = 0x0002DFF0, Chksum = 0x010CD2FB
Record [ 20] : Start = 0x8DBEC000, Length = 0x00001CE0, Chksum = 0x000850F4
Record [ 21] : Start = 0x8DBEE000, Length = 0x0000FB3C, Chksum = 0x0043FDD6
Record [ 22] : Start = 0x8DBFE000, Length = 0x0002DD78, Chksum = 0x00FEE97B
Record [ 23] : Start = 0x8DC2C000, Length = 0x00028FFC, Chksum = 0x00E467D0
Record [ 24] : Start = 0x8DC55000, Length = 0x00025FF8, Chksum = 0x00DF4E45
Record [ 25] : Start = 0x8DC7B000, Length = 0x00028D80, Chksum = 0x00D234AC
Record [ 26] : Start = 0x8DCA4000, Length = 0x00057548, Chksum = 0x01FA43C1
Record [ 27] : Start = 0x8DCFB548, Length = 0x00019A9C, Chksum = 0x007AEC34
Record [ 28] : Start = 0x8DD15000, Length = 0x00043104, Chksum = 0x017B0913
Record [ 29] : Start = 0x8DD58104, Length = 0x00000898, Chksum = 0x0003E4F9
Record [ 30] : Start = 0x8DD59000, Length = 0x0003AF0C, Chksum = 0x013650EA
Record [ 31] : Start = 0x8DD94000, Length = 0x00025F88, Chksum = 0x00CD0208
Record [ 32] : Start = 0x8DDBA000, Length = 0x00004FEC, Chksum = 0x001AC818
Record [ 33] : Start = 0x8DDBF000, Length = 0x00023A0C, Chksum = 0x00C40481
Record [ 34] : Start = 0x8DDE3000, Length = 0x00004F5C, Chksum = 0x001A685C
Record [ 35] : Start = 0x8DDE8000, Length = 0x0001BD4C, Chksum = 0x00A6F0E9
Record [ 36] : Start = 0x8DE04000, Length = 0x00030D80, Chksum = 0x0105BDF1
Record [ 37] : Start = 0x8DE35000, Length = 0x00000FFC, Chksum = 0x0006CB20
Record [ 38] : Start = 0x8DE36000, Length = 0x0005BF44, Chksum = 0x0200A4EB
Record [ 39] : Start = 0x8DE91F44, Length = 0x0001A0BC, Chksum = 0x00755EDA
Record [ 40] : Start = 0x8DEAC000, Length = 0x00037FC8, Chksum = 0x012DBBAA
Record [ 41] : Start = 0x8DEE4000, Length = 0x00018FFC, Chksum = 0x0072FE38
Record [ 42] : Start = 0x8DEFD000, Length = 0x0016D518, Chksum = 0x07C1A4B3
Record [ 43] : Start = 0x8E06A518, Length = 0x00000AE8, Chksum = 0x000489F4
Record [ 44] : Start = 0x8E06B000, Length = 0x0005599C, Chksum = 0x018A87FE
Record [ 45] : Start = 0x8E0C099C, Length = 0x0003D660, Chksum = 0x014059EC
Record [ 46] : Start = 0x8E0FE000, Length = 0x00047C10, Chksum = 0x017FB32D
Record [ 47] : Start = 0x8E145C10, Length = 0x000323C8, Chksum = 0x00FD1265
Record [ 48] : Start = 0x8E178000, Length = 0x0053B81C, Chksum = 0x1D5A00E5
Record [ 49] : Start = 0x8E6B381C, Length = 0x000007E4, Chksum = 0x0003B4AA
Record [ 50] : Start = 0x8E6B4000, Length = 0x00101B94, Chksum = 0x039BDBA5
Record [ 51] : Start = 0x8E7B5B94, Length = 0x0001544C, Chksum = 0x00679C03
Record [ 52] : Start = 0x8E7CB000, Length = 0x00032000, Chksum = 0x00EC9E33
Record [ 53] : Start = 0x8E7FD000, Length = 0x00018E34, Chksum = 0x00798556
Record [ 54] : Start = 0x8E816000, Length = 0x00009FD4, Chksum = 0x0032ECD3
Record [ 55] : Start = 0x8E820000, Length = 0x00000EF4, Chksum = 0x0007237D
Record [ 56] : Start = 0x8E821000, Length = 0x00005F54, Chksum = 0x001D7BB7
Record [ 57] : Start = 0x8E827000, Length = 0x00004EF0, Chksum = 0x00170D1C
Record [ 58] : Start = 0x8E82C000, Length = 0x0003EFFC, Chksum = 0x0188EB68
Record [ 59] : Start = 0x8E86B000, Length = 0x00027114, Chksum = 0x0125236A
Record [ 60] : Start = 0x8E892114, Length = 0x00019C64, Chksum = 0x00C5AF2F
Record [ 61] : Start = 0x8E8ABD78, Length = 0x0003F9C4, Chksum = 0x016B97F0
Record [ 62] : Start = 0x8E8EB73C, Length = 0x0003E6D8, Chksum = 0x01E9F0BE
Record [ 63] : Start = 0x8E929E14, Length = 0x00031BAC, Chksum = 0x01895AAB
Record [ 64] : Start = 0x8E95B9C0, Length = 0x000708D4, Chksum = 0x037310AA
Record [ 65] : Start = 0x8E9CC294, Length = 0x0003DFBC, Chksum = 0x01EA0548
Record [ 66] : Start = 0x8EA0A250, Length = 0x0003D258, Chksum = 0x01E37A36
Record [ 67] : Start = 0x8EA474A8, Length = 0x000391E0, Chksum = 0x017FEEB2
Record [ 68] : Start = 0x8EA80688, Length = 0x0006750C, Chksum = 0x031B1242
Record [ 69] : Start = 0x8EAE7B94, Length = 0x00000054, Chksum = 0x00000D9C
Record [ 70] : Start = 0x8EAE7BE8, Length = 0x00001D78, Chksum = 0x000A8F82
Record [ 71] : Start = 0x00000000, Length = 0x8DA00004, Chksum = 0x00000000
Start address = 0x8DA00004
Checking record #69 for potential TOC (ROMOFFSET = 0x00000000)
Found pTOC = 0x8eae7b94
ROMOFFSET = 0x00000000
Done.

[свернуть]

толлько учтите, что это физические адреса самой прошивки, следовательно 0x8DA00000 это 0x00000000 в самой прошивке.

Относительно S0003. То ли в WinCE 4.2, но скорее всего - в прошиках SH4 наблюдается некоторое перекрытие модулей (до 4-х байт), возможно дело в этом. Сегодня от нечего делать поставил Platform Builder 4.2 и попробовал сгенерить несколько прошивок под SH4, во всех наблюдал такие перекрытия. Вохможно это просто связано с округлением до разрядности процессора, т.е. до 4-х байт. Полагаю, это ни на что не влияет.
И еще вам нужно разобраться со структурами e32 и о32, которые тоже нужно будет маленько поправить после того, как регионы станут на свои места. Ничего сложного там нет, визуально их можно увидеть в imageinfo.txt для каждого модуля, там же где лежат его S000x. Найти эти структуры в прошивке поможет ее карта, которую так же выдает Remaker.

---------- Добавлено в 22:54 ---------- Предыдущее сообщение было написано в 22:17 ----------

Что касается S002, то он лежит в 59-м блоке на самом его дне.

---------- Добавлено в 23:07 ---------- Предыдущее сообщение было написано в 22:17 ----------

Что бы найти начало 59-го блока в файле формата bin можно воспользоваться информацией о ней, полученной от viewbin. Для этого достаточно найти сам заголовок блока, только, учитывая то, что байты в DWORD читаются ноборот, искать нужно последовательность 00B0868E147102006A232501

---------- Добавлено в 23:10 ---------- Предыдущее сообщение было написано в 22:17 ----------

где 00B0868E - первернутый адрес загрузки;
14710200 - длина;
6A232501 - чексумма.
В вашем bin этот заголовок находится по смещению 0x00E665FF

---------- Добавлено в 23:25 ---------- Предыдущее сообщение было написано в 22:17 ----------

Цитата:

Сообщение от Ёжик Пых (Сообщение 1093931)

смещения даю от полного LOADING.KWI не разделенного на части

Вообще, удобнее работать с вырезанной прошивкой.
Чтобы быстро ее вырезать, воспользуйтесь следующим приемом:
1. Откройте KWI в LoadingView и перейдите на часть, соотвествующую образу OS. В вашем случае часть 00000111 это загрузчик, за ней следует OS, далее - образ нандфлеш. Если вы не умеете находить начало прошивки, то вы можете увидеть его дамп в провой панели. Перепишите первые 16 байт.
2. Перейдите на часть следующую за образом OS (в данном случае - образ флеши. Перепишите бйты.
3. Откройте KWI в WinHex'е. Найдите (Search -> Find Hex Values...) начало прошивки (B000FF...) и начало следующей части, выделите блок между ними и сохраните в отдельный файл. Это и есть ваш nk.bin.

Re: Исследование механизма работы ПО MMCS

Цитата:

Сообщение от Mi81 (Сообщение 1094118)

Вообще, удобнее работать с вырезанной прошивкой.
Чтобы быстро ее вырезать, воспользуйтесь следующим приемом...

ОК, буду пытать дальше. По поводу разделения на части есть более простой способ.
LOADING.KWI состоит из 3х частей: загрузчик, OS и ScreenData. Стартовые адреса и длины частей описаны в заголовке с одной "хитростью". Чтобы получить искомые Start address и Length нужно умножить на 2. Пример для OS N04:

Код:

0x210 : 000000000000000000037800008727FE

Длина: 008727FE * 2 = 10E4FFC
Старт: 00037800 * 2 = 6F000

Re: Исследование механизма работы ПО MMCS

+ За "хитрость"

Re: Исследование механизма работы ПО MMCS

Тут на Угона нет статейка появилась

Скрытый текст

Статьи » Спутниковые системы
Поделиться…

Штатная навигация как противоугонный трекер

05.09.2011, автор: Макар Алтынов

Навигационные системы, интегрированные в штатную электронику автомобиля, давно стали принадлежностью топовых комплектаций автомобилей класса выше среднего. Можно ли использовать навигатор, установленный автопроизводителем, в противоугонных целях? Оказывается, можно.
Скажу сразу, эта идея до промышленной реализации не дошла и реализуется пока в качестве эксперимента. Основная техническая проблема – в обилии схемных решений, в отсутствии унификации между аппаратурой разных производителей. Пока набираются опыт и статистика, потом возможно будет предложить и потребительские решения (с рядом ограничений, о которых позже). Делается это в Москве, инженерами одной фирмы, занимающейся раскодировкой и русификацией штатных навигационных блоков и адаптацией карт и ПО для России.

https://out-club.ru/board/attachment...ygnpmskxza.jpg https://out-club.ru/board/attachment...hrampfvedy.jpg

Итак, суть в следующем. Штатный навигатор большинства автомобилей начинает работать сразу после включения зажигания. Сам аппарат может быть и выключен, но питание на модуль GPS-приёмника всё равно поступает, дабы сократить время «холодного старта» при включении навигации. Даже более того: приёмник продолжает работать некоторое время и после выключения зажигания, у некоторых производителей этот период достигает нескольких часов и без труда перепрограммируется и на боле длительный срок, до нескольких дней или даже недель. Благо, энергопотребление GPS-чипсетов SiRFStar, MTK и SiRFAtlas минимально, меньше тока саморазряда АКБ. Соответственно, автомобиль почти всегда «знает» где он находится, если только ему «видны» навигационные спутники.
Есть и ещё одно преимущество у встроенных навигаторов по отношению к тем же PND или отдельным радиомаякам – наличие МЭМС-гироскопа, который позволяет по анализу отклонений построить траекторию движения автомобиля даже без участия спутников, в определённых, конечно, пределах. Но в этих пределах точность будет даже выше, чем у GPS, гироскоп способен уловить отклонения в несколько миллиметров. Это значит, что автомобиль с такой системой навигации знает свои точные координаты даже находясь на большой подземной стоянке, в экранированном боксе, да вообще везде. И, заметьте, всё это при формально выключенном питании.
Такое свойство штатных навигаторов грех не использовать. Самое простое, что тут можно сделать - «снять» каким-то образом информацию о координатах и попытаться передать её владельцу. То есть, встроить в навигатор GSM-модуль. На случай отключения штатной АКБ нужно предусмотреть ещё и аварийное питание, небольшой аккумулятор или батарейку, благо, энергии много не нужно.
Оказалось, что даже такая модернизация сопряжена с множеством технологических трудностей, от отсутствия места в блоке навигации до сложности расшифровки протоколов межмодульного взаимодействия. Но, пройдя этот этап, разработчики пришли к выводу, что такая работа не стоит примитивности результата: по сути, мы получаем дубликат радиомаяка. Да, с лучшим определением координат и с меньшим риском обнаружения (в штатную «магнитолу» никто не полезет искать закладки), но столь же уязвимый перед экранированием GSM-сети.

https://out-club.ru/board/attachment...whyybfbfdb.jpg https://out-club.ru/board/attachment...eg6yeamyph.jpg

А вот с противодействием глушению такой треккер справляется не в пример лучше. Дело в том, что угонщики работают с дорогими машинами по более-менее устоявшемуся алгоритму: «быстрый» угон с «глушилкой» GPS, помещение машины в закрытый бокс и спокойный поиск противоугонных закладок. В экранированном помещении глушилку выключают, там она не нужна. Тем боле, если машина прошла ревизию и в ней не обнаружилось сторонних GPS-маяков. Кстати, можете быть уверены: все места установки СОС-систем и автономных маяков угонщикам прекрасно известны и подобная ревизия сложности не представляет. Штатный же треккер «держит» свои координаты крепко, их нужно только передать. А пользовательское устройство уже само наложит их на карту или экстраполирует в навигационную программу.
Тут нужно упомянуть ещё один элемент отработанной схемы угона: GSM-глушилку выключают позже, чем GPS, убедившись в отсутствии связи с абонентской станцией. Для этого используются специальные радиочастотные GSM-детекторы, недешёвые, но эффективные. Либо когда на примере собственных телефонов угонщики убеждаются: в данном боксе сотовая связь не работает.
Что же делать? Предлагается совершенно фантастическая идея: через bluetooth-модуль автомобиля «взломать» чужой сотовый телефон! Поместить туда микропрограмму, которая незаметно для владельца телефона будет отправлять координаты автомобиля его законному владельцу, по заданному списку номеров. Технологически особой проблемы в этом нет, bluetooth-протокол «ломается» достаточно легко, вирусы для мобильных платформ тоже не первый день существуют. А здесь речь идёт именно о вирусной программе, точнее, троянской, которая не причиняет вреда, но использует чужой смартфон в собственных целях. Происходит это так: штатный bluetooth-модуль автомобиля модернизируется таким образом, чтобы он автоматически включался «по событию», независимо от включённости зажигания и даже вообще наличия питания в энергосистеме автомобиля. «Событием» может быть определённый промежуток времени после выключения зажигание, пропадание питания (что означает переключение на аварийную батарейку), отсутствие приёма GPS сигналов. При определённых финансовых вложениях устройство можно оснастить и детектором факта глушения GPS/GSM, но это дорого и пока не проходит по габаритам.

https://out-club.ru/board/attachment...xeaceyfkq3.jpg https://out-club.ru/board/attachment...smmjkn2fjp.jpg

Итак, навигатор идентифицировал по совокупности признаков факт угона и/или глушения. Активируется bluetooth-модуль, перепрограммированный на единственную задачу – заразить «трояном» первый сотовый телефон, попавший в ареал действия bluetooth (это примерно 100 метров). Это может быть телефон любого прохожего и вообще любое устройство с «голубым зубом», оснащённое способностью передавать информацию по GSM. Сейчас много портативных навигаторов с такими функциями, других автомобилей с продвинутыми мультимедийными системами, появляются планшетные компьютеры. Учитывая нынешнюю многоплатформенность мобильных гаджетов, целесообразно сосредоточиться на основных платформах – Android и Windows Mobile, возможно, iPhone. Но в описываемой разработке речь пока идёт только о Windows Mobile версии не выше 6.5.
Столь непростая схема нужна для того, чтобы иметь возможность коннекта там, где не работают иные средства связи. Ведь человек с «заражённым» телефоном рано или поздно выйдет на простор функционирования GSM-сети! Тогда-то «троян» и перешлёт координаты на мобильное устройство владельца автомобиля, по стандартному протоколу, а оно, в свою очередь, активирует программу поиска.
Тут мы вступаем на скользкий путь противозаконности подобных действий. И дело даже не в том, что в качестве базовой программы поиска применён «ломаный» и модифицированный «Навител» (хотя и за это по голове не погладят), а в том, что распространение вредоносных программ для ЭВМ – это статья уголовного кодекса (273, если кто не знает), до трёх лет (правда, прецедентов такого наказания пока нет). Не знаю уж, насколько смартфон может быть отнесён к ЭВМ или «иным машинным носителям», но путь этот явно не самый законный. И это главная причина, по которой не называется имя автора разработки. Она же надёжно страхует такие устройства от массового распространения и открытой, легальной продажи.
Но будем реалистами. Вероятность серьёзного наказания за обладание подобной противоугонкой даже не мала – она ничтожна. «Троян» получает ответ от телефона владельца, после чего засыпает и обнаружить его практически невозможно. То есть, никому никакого вреда он не приносит и хороший адвокат легко докажет безосновательность отнесения этой программы к категории вредоносных. Ущерб, понесённый владельцем заражённого смартфона достигает хорошо если трёх рублей, за использованный трафик, за такую сумму судиться захотят не многие. В случае с «Навителом» всё ещё проще – он взят просто потому, что попался под руку. Не исключено, что фирма ЦНТ будет заинтересована в выпуске официальной версии своей программы со встроенной функцией поиска, тогда разработчик готов передать ей список необходимых изменений. Да кроме «Навитела» ещё много программ навигации существует, в том числе и бесплатных. Можно взять какую-нибудь «нарисуйку» с картами OpenStreetMap…Короче, это не проблема.
Заметим, несанкционированный коннект по bluetooth хоть и возможен, но является взломом. А вот коннект по WiFi возможен совершенно легально, тем более, что всё больше телефонов оснащаются «вай-фаем». И не только на приём, но и на раздачу. А дальность действия WiFi даже побольше будет, чем у bluetooth. Поэтому разрабатывается сразу двухмодульная схема. По WiFi, кстати, можно вести машину в городе, с его обилием хот-спотов, и это позиционирование мало будет уступать GPS. Эта функция незаменима при угоне методом погрузки в КУНГ, когда экранируется GPS. Например, в сети БиЛайн-ВайФай, покрывающей Москву, можно найти «закладку» точнее, чем с LBS.
Теперь принципиальный вопрос: зачем городить огород и заниматься встраиванием такого устройства в штатную навигацию, не проще ли сделать отдельную автономную противоугонку? Некоторые аргументы в пользу такого решения были приведены выше, но они не исключают и создание отдельного устройства. Правда, с ним сложнее всё в том же юридическом плане: модернизация готового аппарата – это одно, а выпуск целенаправленного распространителя «троянов» - немного другое.
Понятно, что уязвимостей у описанного решения хватает. В конце концов, многих сигнал приведёт на радиорынок, где продаются ворованные штатные «магнитолы» - в том случае, если автомобиль угоняли на запчасти. Но в активе всегда останется малая распространённость, отсутствие рекламы и подробной информации о принципах работы. Значит, угонщики не будут считать это угрозой своему бизнесу и разрабатывать меры противодействия.

http://www.ugona.net/article155.html

[свернуть]

Интересно имеет эта идея право на воплощение у нас?

Re: Исследование механизма работы ПО MMCS

Цитата:

Сообщение от Gomerchik (Сообщение 1104460)

Тут на Угона нет статейка появилась
http://www.ugona.net/article155.html
Интересно имеет эта идея право на воплощение у нас?

Бредоватая идея.
Уж лучше с таким расчётом вживить ЖСМ модуль срабатывающий периодично или по событию, в саму магнитоллу. Если авто идёт на перепродажу ,то оно всё-равно войдёт в зону ЖСМ,причём отследить его можно будит не только по координатам ,но и по базовым станциям.
Если же авто идёт на разбор, то угонщикам достаточно снять акку-р и в обоих случаях ничего не поможет.Нужно делать ещё отдельно спящее питание для мафона либо ЖСМ модуля, а батарея большой ёмкости в него не влезит, так что запас времени автономной работы будит невысок и если авто в боксе разбирается ,то даже неделя это ничто.

Re: Исследование механизма работы ПО MMCS

может кто поковыряет японческую прошивку и найдёт этот самый кусок, который работает с CAMERA ECU (пытался англоязыровать тут https://out-club.ru/board/showthread...13813&page=240 ) и прикрутит его в америкосовскую N-04?

возможно ли это в теории?

нас с такими машинами уже много и я думаю можно и коммерчески будет проработать этот вопрос если все получится :)

Re: Исследование механизма работы ПО MMCS

Цитата:

Сообщение от sanxx (Сообщение 1105814)

В теории возможно всё, но на практике, нужно иметь уйму времени для написания утилит по сборке/разборке ПО MMCS. Учитывая её немассовость, коммерческие проекты отметаются. Нужно либо усилие группы энтузиастов, либо огромное количество времени. Я ковыряю эту тему в свободное время, которого практически нет, а Японские головы не ставлю целью совсем, как неактуальные в Москве и Европе....

Re: Исследование механизма работы ПО MMCS

Цитата:

Сообщение от Ёжик Пых (Сообщение 1112066)

да время - золото
:(

Re: Исследование механизма работы ПО MMCS

Наткнулся на такую фигню, может с её помощью можно наш монитор ПАЛ сигнал научить понимать?тогда русскую прошивку можно былоб напрямую заливать

CS4954/55

NTSC/PAL Digital Video Encoders

к сожалению, изображение утрачено
The CS4954 and CS4955 provide full conversion from digital video formats YCbCr or YUV into NTSC and PAL Composite, Y/C (S-Video) and RGB or YUV analog video. Input formats can be 27 MHz, 8-bit YUV, 8-bit YCbCr or ITU R.BT656 with support for EAV/SAV codes. Video output can be formatted to be compatible with NTSC-M, NTSC-J, PAL-B, D, G, H, I, M, N and combination N systems. Closed caption is supported in NTSC. Teletext is supported for NTSC and PAL.

Re: Исследование механизма работы ПО MMCS

не уверен правильно ли выбрал тему...

пробовал ли кто-нибудь поставить вместо MMCS linux? вот этот или что-нибудь отсюда?

на сайте igo говорится, что есть версия под наш процессор (Renesas SH)... где бы взять?

Re: Исследование механизма работы ПО MMCS

Приветствую все кото видит ! есть вопрос
В общем есть mmcs , как его поставить если стоит обычный без монитора Outlander XL 2010 ! ну или подскажите хоть где посмотреть что то про это как сделать USB и какую gps антену ставить

Re: Исследование механизма работы ПО MMCS

Цитата:

Сообщение от LA_ (Сообщение 1171098)

А смысл? И есть спецификации железяки?

Re: Исследование механизма работы ПО MMCS

Смысл поставить iGo? Или linux? Если второе, то, например, чтоб иметь возможность на жесткий диск записать свои треки. Думаю, что под линукс можно найти более хорошие навигационные программы, чем стандартная.

Кое-какие спецификации есть в шапке этой темы.

Re: Исследование механизма работы ПО MMCS

Народ,
помогайте. В настоящее время веду переговоры с iGo по поводу адаптации их навигации к нашей магнитоле. Они, вроде бы, заинтересованы в данном направлении. Прислали мне лист технических спецификаций, который необходимо заполнить и вернуть им. А они уж, на основе предоставленной информации, сообщат, возможна ли установка их навигации на MMSC. Лист в приложении, сам я его заполнить не могу, со знанием языка проблем нет, а вот со знанием начинки проблемы.
Давайте навалимся и заполним как требуется?

Re: Исследование механизма работы ПО MMCS

Цитата:

Сообщение от povt12 (Сообщение 1275948)

Народ,
помогайте. В настоящее время веду переговоры с iGo по поводу адаптации их навигации к нашей магнитоле.

МОЛОДЕЦ!!!
Поддерживаю коллегу! Надо просить ГУРУ по разделу MMCS нашего форума, чтобы навалились гурьбой. Я уже постил здесь и здесь примерно такой же вопрос, но через российскую разлочку зверька.

Re: Исследование механизма работы ПО MMCS

Вроде QNX под наш процессор есть. Может им заказать написание полноценной ОС для нашего устройства? Но тож все характеристики надо как-то узнать.
Процессор Renesas SH, жесткий диск Toshiba MK4036GAC. Кто-нибудь фотографии платы делал?

Re: Исследование механизма работы ПО MMCS

Подскажите Plzz! Можно ли на последней прошивке МАР 2011 включить AUX в движении? DVD в движении работает! А вот AUX нет!

Re: Исследование механизма работы ПО MMCS

Цитата:

Сообщение от max2321 (Сообщение 1281882)

А разве в других прошивках он есть? Никогда не было! Я себе сделал через спец-адаптер.

Re: Исследование механизма работы ПО MMCS

Наверно это нужно спрашивать тут)))

Доброго времени суток!
Знающие люди подскажите, не знающие не советуйте.
Решил я подключить два активных сабвуфера к нашей штатной магнитоле, нашол буферы которые можно подключать на аккустические выходы, НО при полной громкости в голове срабатывает защита и звук пропадает, пока не заглушишь машину и не включешь снова он не появляется. Я понял что выходы нашей головы даже спец буферы не выдерживаю(((

ВОПРОС!

Может кто разбирал или паял уже, к каким 4-ем КОНДЕНЦАТОРАМ в нутри магнитолы нужно припоять провода чтобы оргонизовать нормальные линейные выходы? Или как подключить саб, но чтобы бошка не вырубалась?(идея есть через трансформатор 220 на 12 в, 12 в к акустическому каналу любому, а обмотку 220 к сабу)

Re: Исследование механизма работы ПО MMCS

Дорогие мои друзья
У меня есть Outlander 2006 модельного MMCS с телевизором и Navi.japanise version.
Есть у меня жесткач на 100 гигов с таким же подключением.Можно ли найти образ и закатать его
что бы русифицировалось и навигация наша работала? Или это большая проблема?
Может кто уже воплотил это в реальность? Или нет возможности? Подскажите!

Re: Исследование механизма работы ПО MMCS

Я так понял кроме страдальцев с конденцаторами эту ветку никто не посещает? :(