Re: FAQ по штатной MMCS (Все вопросы в одной теме)
Цитата:
Сообщение от samets
Ps названия ключей условно взяты из сообщения №428 Холода, когда он выяснил их проверку в файле HMIManаger.exe
Молодец, samets, глазастый! . Имя с точностью до 3х пробелов после .
Правда Холод в 428 сообщении немного в другом контексте это упоминал, не суть. В этом ракурсе предложение smart007 становится более реальным, чем паять ключи.
Господа Реверсеры! Прикладываю HMIManager.exe из R03. Ковыряйте, если есть время, ищите обращения к ключу. Потом соберем LOADING и проверим.
В свое время для отладки (не для производственного тестирования) на платах были спец. контакты или колодки (jtag вроде именовали), как правило не распаянные в производтсвенной модели, может и тут что-то подобное имеется...
Интересно на чем отлаживают код разработчики, имхо не на живой голове, а на железке типа "ренесанса" или софтовом эмуляторе, но у меня в свое время не удалось виртуалку под sh4 запустить нормально =( Но кто-то вроде писал (сейчас не уверен что именно про mmcs, возможно про другую kiwi-систему, что пакет собран для работы с несколькими различными платформами одновременно, может наш тоже?
Но вообще странная штука, что за столько лет так и не утекла из недр восточных разработчиков ни одна версия kiwi редактора... но как-то даже натыкался на резюме одного из разработчиков, кто приводил в пример что разрабатывал эту систему.
Интересно на чем отлаживают код разработчики, имхо не на живой голове, а на железке типа "ренесанса" или софтовом эмуляторе
ПО MMCS писалось на языке высокого уровня, причем объектно ориентированном (как верный признак, в теле программ щедро накидано операторов "delete" и "new", используемых в ООП для создания и уничтожения экземпляров классов).
У этого факта есть 2 стороны:
1) плюс: много полезной информации компилятор оставляет в теле исполняемого модуля. Там есть потрясающие строки вида " А вот сейчас мы запретим показ DVD в движении". Причем строки хранятся недалеко от кода, как это и положено при компиляции объектов Именно поэтому относительно легко удается грохнуть этот запрет с DVD, особенно не парясь с трассировкой кода.
2) минус: крайне затруднено восстановление программной логики, поскольку очень много вызовов процедур не по прямым адресам, а косвенно через относительные смещения к неивестным из мертвого листинга адресам (которые видимо являются ссылками на объекты исходного текста ООП). И мертвый код анализировать становится трудно. Это плата за удобство концепции ООП для разработчика.
На интелсовместимых платформах, я даже спустя 15 лет перерыва могу по ассемблерному коду легко вернуть все в С. Легко понять вызовы процедур и какие параметры при этом передаются. На SH-4 у меня таких навыков нет, поэтому это все время. Если кто обладает знаниями по стандартной структуре ассемблерного кода SH-4, в который компилируются высокоуровневые вызовы процедур и функций хоть на CPP хоть на C#, буду признателен за краткую информацию.
Что касается отладки: свой небольшой отладчик в MMCS загружен, можно пытаться его слегка переписать, чтобы он выводил на экран устройства или в файл нужную информацию. Но что бы его переписать и отладить нужно большое количество циклов: модификация кода --> модификация loading.kwi --> запись на HDD --> запуск на устройстве ---> анализ результата --> модификация кода --> ... и далее по циклу.
Все прозаично но муторно и долго. А альтернативой является интуитивное и несистематическое тыканье в разные места кода на удачу и проверка что получилось. Тоже вариант, но менее предсказуемый.
Re: FAQ по штатной MMCS (Все вопросы в одной теме)
Если кто-то и взломал эту программу, то она работает по открытому формату kiwi версии 1.22. Но чую, что в mmcs уже используется модифицированный или более новый формат. Что бы получить доступ к документации более новой, нужно стать членом kiwi-консорциума, что стоит не копейки и явно не каждой компании просто так дадут возможность в него войти (
Вот и дилема, стоит ли тратить время на расколупливание формата и конвертацию актуальных карт, или ждать/разрабатывать другое более модернизированное устройство...
Re: FAQ по штатной MMCS (Все вопросы в одной теме)
2 heavy
Большой практической пользы от otakиной проги loadingview нет, она позволяет экспортировать или корректно заменять исполняемые файлы и ресурсы из loading.kwi. Но как я понял, здесь есть участники, которые научились это делать вручную. Но это умение не поможет конвертировать скажем навителовские карты в формат MMCS.
Меня просто взял интерес взломать этот loadingviewer.
У меня подозрение большое, что автор выложил на сайте урезанный функционал, даже с лицензией.
Тут было бы интересно написать небольшой файлменеджер, зашить его в лоадинг, чтобы после загрузки управлять с его помощью содержимым диска без разлочивания: менять файлы, добавлять и т.п.
MMCS работает на процессоре sh4 hitachi. Компилятор для win ce в целом не фатальная проблема.
---------- Добавлено в 15:36 ---------- Предыдущее сообщение было написано в 14:54 ----------
Update:
Писать для MMCS можно на windows ce sdk + visual studio
---------- Добавлено в 15:45 ---------- Предыдущее сообщение было написано в 14:54 ----------
Re: FAQ по штатной MMCS (Все вопросы в одной теме)
Цитата:
Сообщение от Bedolaga
У меня пока не получилось. Поясню: экспорт + замена продекларирована самим автором. Я повторил его слова. Прога без лицензии это не делает. Я решил поверхностно ее поковырять пару дней, научился подсовывать, правда в ручном режиме правильный лицензионный файл. Она стала показывать, что стала лицензированной. А опции замены и экспорта все равно не открылись.
У меня задачи проще:
1. починить рамку на камере заднего вида. не понятно, чего оно там считывает с CAN как тип авто и почему потом не может найти нужных файлов. хочется попатчить так, чтобы всегда определялось как XL.
2. подкинуть в image файлов с заставками от peugeot, потому как потом их на диске менять каждый раз - замучаешься. к тому же, в последней версии boot image тоже меняется в процессе прошивки и своя картинка приезжает, только если клемму скидывать.
Re: FAQ по штатной MMCS (Все вопросы в одной теме)
Цитата:
Сообщение от Bedolaga
...Писать для MMCS можно на windows ce sdk + visual studio
Ещё где нибудь добыть SDK под MMCS ибо от стандартной WinCE 4.2 там мало что осталось. Например использовать стандартные обращения к Win API не получится, куски функций скомпилированы внутри .exe файлов, часть функций вызывается из kernel достаточно нестандартно, через memset и иже с ними.
Всё это в принципе ерунда, вот дизассемблировать модули можно только в виртуальной памяти, а как и всё это разворачивается в реальном режиме - узнать сильно затруднительно. Нужен дамп RAM запущеной системы...
Если это не останавливает, я только за!
Re: FAQ по штатной MMCS (Все вопросы в одной теме)
2 Alex01 да я пока что просто философствую :-)
2 WhiteTiger для очень простого файлменеджера нужно немного драйверов. Если мы про драйвера периферических устройств.
Точнее всего два: видео и тачскрина, чтобы вводить информацию и отображать информацию на экране. Поскольку MMCS все-таки иногда что-то на дисплее показывает и принимает команды, то скорее всего эти драйвера (или их фрагменты) в той или иной форме на MMCS присутствуют и полагаю на достаточно высоком уровне и обособленно. Поскольку MMCS умеет читать/писать/удалять файлы с диска, CD и USB, то могу предположить что какое-никакое высокоуровневое API управления файлами тоже в MMCS присутствует. И вот теперь следующий вопрос к Ёжик Пых:
Ёжик Пых,я понял, что Вы уже довольно глубоко продвинулись в анализе софта MMCS, если позволите несколько вопросов:
1) Дизасемблировали на IDA или есть что-то более специальное? Если ли у Вас физические устройства на базе SH4 типа Hitachi HPW-600ET ePlate, для баловства? Если ли эмуляторы SH4? Судя по Вашим словам, Вы анализировали только dead code?
В принципе по моему опыту (когда-то активно поламывал программы лет 15 назад) dead code analysis дает около 90 процентов успеха при надлежащем усердии. Я ведь не думаю, что в MMCS применены динамические распаковщики, противодействие декомпиляции и т.п. Все должно быть видно.
2) Я понял из Ваших слов, что много стандартных системных WinCE API вшито в исполняемый модуль навигации прямым кодом и вызвать их из другого приложения (нашего гипотетического файлменеджера) на уровне внешего API будет невозможно? Т.е. остается реконструировать эти API и написать свои библиотеки или также вписывать прямо в код приложения по аналогии со штатным исполняемым модулем? Верно?
3) У меня на теоретическом уровне довольно оптимистический взгляд на возможность MMCS jailbreak потому как все его проги открыты, операционная система все же WinCE как не крути, т.е. возможен детальный dead code analysis, как минимум. Возможность работать с файлами, тачскрином и видео на высоком уровне в MMCS скорее всего есть, нужно только аккуратно это все вычленить. Т.е. не нужно будет писать драйвера с нуля.
Т.е. это все вопрос времени и интереса. Я думаю, для начала классический проект "Hello world!" с кнопкой "ОК" внизу для MMCS представляет большой академический и практический интерес.
---------- Добавлено в 03:43 ---------- Предыдущее сообщение было написано в 02:23 ----------
Upadate:
2 Ёжык Пых не сочтите за дерзость, но если у Вас есть уже копия диска со всеми системными и исполняемыми файлами (карты мне не нужны) не могли бы Вы ими поделиться? Мне это нужно для того что бы оценить масштаб бедствия и самому понять что там доступно, а что нет. Не хотелось бы все это самому вручную из loading.kwi выдирать, а также вынимать свой диск без большой нужды.
спасибо,
---------- Добавлено в 04:15 ---------- Предыдущее сообщение было написано в 02:23 ----------
Ого, только что прочитал архив этой ветки и нашел крайне интересную информацию от cvy7:
т.о. исполняемые модули в MMCS имеют нетрадиционную для Win CE структуру. Прям ЛГБТ получается, а не MMCS :-)
Это значит, что средствами Visual Studio просто так exe-шники под MMCS не получить. ОК, но и это не фатально.
План такой:
1) из dead listingа четко вычленить основной сервис по обращению к дискам и экрану с тачскрином.
3) на основе полученных фрагментов собрать свою библиотеку этих функций.
4) скомпилировать код для своей программы, хоть и посредством Visual Studio +SDK for SH4.
2) взять любой родной работающий exe-шник и в его тело аккуратно пропатчить свой код, по возможности ничего в хидерах и точках входа не меняя.
Вообще у проблемы жестко вшитого кода API в тело программы есть две стороны: плохая, очевидная и понятная - не возможно другим этим сервисом пользоваться, но есть и хорошая: легче патчить сущестующие программы.
Re: FAQ по штатной MMCS (Все вопросы в одной теме)
А внутри точно SH-4 или может только код под режим SH-4 скомпилирован? Поражаюсь япошкам, втюхивать проц прошлого века от сеги дримкаста... кто-то все еще надеется запустить на этом igo или навител? :D
jvc вроде тоже на этом чипе нафигацию в своих устройствах делает и тоже под windows ce, но у них такая же беда с картами - обновлений карто "по два года ждать да еще и протухшими".