Выполним еще одну маленькую проверку. Поставим курсор на начало региона по смещению 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.
Готового "это заменить на то" не даю, это не интересно. Экспериментируйте.
Последний раз редактировалось Mi81; 25.08.2011 в 00:23.
Выполним еще одну маленькую проверку. Поставим курсор на начало региона по смещению 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 и длине расположены немного по другому.
Может проще драйвера с американки сунуть в русский лодинг,тогда решится не только вопрос с нави, но и с русскоязычиванием всей системы.
Женя, ты невнимательно читал предыдущие мои и cvy7 посты. Там больше половины драйверов и шрифты внутри .ехе упакованы. Я на выходных буду пробовать озвученное Mi81 предложение, тогда всё станет ясно.
Женя, ты невнимательно читал предыдущие мои и cvy7 посты. Там больше половины драйверов и шрифты внутри .ехе упакованы. Я на выходных буду пробовать озвученное Mi81 предложение, тогда всё станет ясно.
Ну вообще-то, эксперимент, который я описал выше касался лишь установления факта наличия/присутствия контрольных сумм, потому что на практике не каждый регион пакуется отдельно. На самом деле один блок прошивки может включать неколько регионов. Именно этот случай, видимо, вы имеете с S0002. Т.е. заголовок есть, но он где-то выше. Если знакомы с программированием, то написать утилиту, которая вычислит смещения всех заголовков блоков и принадлежащих им блоков данных дело 15-20 минут. Думаю, справитесь ? Если нет, воспользуетесь готовой - viewbin.exe из комплекта Platform Builder'а. Должны получить это:
толлько учтите, что это физические адреса самой прошивки, следовательно 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 ----------
Цитата:
Сообщение от Ёжик Пых
смещения даю от полного LOADING.KWI не разделенного на части
Вообще, удобнее работать с вырезанной прошивкой.
Чтобы быстро ее вырезать, воспользуйтесь следующим приемом:
1. Откройте KWI в LoadingView и перейдите на часть, соотвествующую образу OS. В вашем случае часть 00000111 это загрузчик, за ней следует OS, далее - образ нандфлеш. Если вы не умеете находить начало прошивки, то вы можете увидеть его дамп в провой панели. Перепишите первые 16 байт.
2. Перейдите на часть следующую за образом OS (в данном случае - образ флеши. Перепишите бйты.
3. Откройте KWI в WinHex'е. Найдите (Search -> Find Hex Values...) начало прошивки (B000FF...) и начало следующей части, выделите блок между ними и сохраните в отдельный файл. Это и есть ваш nk.bin.
Вообще, удобнее работать с вырезанной прошивкой.
Чтобы быстро ее вырезать, воспользуйтесь следующим приемом...
ОК, буду пытать дальше. По поводу разделения на части есть более простой способ.
LOADING.KWI состоит из 3х частей: загрузчик, OS и ScreenData. Стартовые адреса и длины частей описаны в заголовке с одной "хитростью". Чтобы получить искомые Start address и Length нужно умножить на 2. Пример для OS N04:
Навигационные системы, интегрированные в штатную электронику автомобиля, давно стали принадлежностью топовых комплектаций автомобилей класса выше среднего. Можно ли использовать навигатор, установленный автопроизводителем, в противоугонных целях? Оказывается, можно.
Скажу сразу, эта идея до промышленной реализации не дошла и реализуется пока в качестве эксперимента. Основная техническая проблема – в обилии схемных решений, в отсутствии унификации между аппаратурой разных производителей. Пока набираются опыт и статистика, потом возможно будет предложить и потребительские решения (с рядом ограничений, о которых позже). Делается это в Москве, инженерами одной фирмы, занимающейся раскодировкой и русификацией штатных навигационных блоков и адаптацией карт и ПО для России.
Итак, суть в следующем. Штатный навигатор большинства автомобилей начинает работать сразу после включения зажигания. Сам аппарат может быть и выключен, но питание на модуль GPS-приёмника всё равно поступает, дабы сократить время «холодного старта» при включении навигации. Даже более того: приёмник продолжает работать некоторое время и после выключения зажигания, у некоторых производителей этот период достигает нескольких часов и без труда перепрограммируется и на боле длительный срок, до нескольких дней или даже недель. Благо, энергопотребление GPS-чипсетов SiRFStar, MTK и SiRFAtlas минимально, меньше тока саморазряда АКБ. Соответственно, автомобиль почти всегда «знает» где он находится, если только ему «видны» навигационные спутники.
Есть и ещё одно преимущество у встроенных навигаторов по отношению к тем же PND или отдельным радиомаякам – наличие МЭМС-гироскопа, который позволяет по анализу отклонений построить траекторию движения автомобиля даже без участия спутников, в определённых, конечно, пределах. Но в этих пределах точность будет даже выше, чем у GPS, гироскоп способен уловить отклонения в несколько миллиметров. Это значит, что автомобиль с такой системой навигации знает свои точные координаты даже находясь на большой подземной стоянке, в экранированном боксе, да вообще везде. И, заметьте, всё это при формально выключенном питании.
Такое свойство штатных навигаторов грех не использовать. Самое простое, что тут можно сделать - «снять» каким-то образом информацию о координатах и попытаться передать её владельцу. То есть, встроить в навигатор GSM-модуль. На случай отключения штатной АКБ нужно предусмотреть ещё и аварийное питание, небольшой аккумулятор или батарейку, благо, энергии много не нужно.
Оказалось, что даже такая модернизация сопряжена с множеством технологических трудностей, от отсутствия места в блоке навигации до сложности расшифровки протоколов межмодульного взаимодействия. Но, пройдя этот этап, разработчики пришли к выводу, что такая работа не стоит примитивности результата: по сути, мы получаем дубликат радиомаяка. Да, с лучшим определением координат и с меньшим риском обнаружения (в штатную «магнитолу» никто не полезет искать закладки), но столь же уязвимый перед экранированием GSM-сети.
А вот с противодействием глушению такой треккер справляется не в пример лучше. Дело в том, что угонщики работают с дорогими машинами по более-менее устоявшемуся алгоритму: «быстрый» угон с «глушилкой» GPS, помещение машины в закрытый бокс и спокойный поиск противоугонных закладок. В экранированном помещении глушилку выключают, там она не нужна. Тем боле, если машина прошла ревизию и в ней не обнаружилось сторонних GPS-маяков. Кстати, можете быть уверены: все места установки СОС-систем и автономных маяков угонщикам прекрасно известны и подобная ревизия сложности не представляет. Штатный же треккер «держит» свои координаты крепко, их нужно только передать. А пользовательское устройство уже само наложит их на карту или экстраполирует в навигационную программу.
Тут нужно упомянуть ещё один элемент отработанной схемы угона: GSM-глушилку выключают позже, чем GPS, убедившись в отсутствии связи с абонентской станцией. Для этого используются специальные радиочастотные GSM-детекторы, недешёвые, но эффективные. Либо когда на примере собственных телефонов угонщики убеждаются: в данном боксе сотовая связь не работает.
Что же делать? Предлагается совершенно фантастическая идея: через bluetooth-модуль автомобиля «взломать» чужой сотовый телефон! Поместить туда микропрограмму, которая незаметно для владельца телефона будет отправлять координаты автомобиля его законному владельцу, по заданному списку номеров. Технологически особой проблемы в этом нет, bluetooth-протокол «ломается» достаточно легко, вирусы для мобильных платформ тоже не первый день существуют. А здесь речь идёт именно о вирусной программе, точнее, троянской, которая не причиняет вреда, но использует чужой смартфон в собственных целях. Происходит это так: штатный bluetooth-модуль автомобиля модернизируется таким образом, чтобы он автоматически включался «по событию», независимо от включённости зажигания и даже вообще наличия питания в энергосистеме автомобиля. «Событием» может быть определённый промежуток времени после выключения зажигание, пропадание питания (что означает переключение на аварийную батарейку), отсутствие приёма GPS сигналов. При определённых финансовых вложениях устройство можно оснастить и детектором факта глушения GPS/GSM, но это дорого и пока не проходит по габаритам.
Итак, навигатор идентифицировал по совокупности признаков факт угона и/или глушения. Активируется bluetooth-модуль, перепрограммированный на единственную задачу – заразить «трояном» первый сотовый телефон, попавший в ареал действия bluetooth (это примерно 100 метров). Это может быть телефон любого прохожего и вообще любое устройство с «голубым зубом», оснащённое способностью передавать информацию по GSM. Сейчас много портативных навигаторов с такими функциями, других автомобилей с продвинутыми мультимедийными системами, появляются планшетные компьютеры. Учитывая нынешнюю многоплатформенность мобильных гаджетов, целесообразно сосредоточиться на основных платформах – Android и Windows Mobile, возможно, iPhone. Но в описываемой разработке речь пока идёт только о Windows Mobile версии не выше 6.5.
Столь непростая схема нужна для того, чтобы иметь возможность коннекта там, где не работают иные средства связи. Ведь человек с «заражённым» телефоном рано или поздно выйдет на простор функционирования GSM-сети! Тогда-то «троян» и перешлёт координаты на мобильное устройство владельца автомобиля, по стандартному протоколу, а оно, в свою очередь, активирует программу поиска.
Тут мы вступаем на скользкий путь противозаконности подобных действий. И дело даже не в том, что в качестве базовой программы поиска применён «ломаный» и модифицированный «Навител» (хотя и за это по голове не погладят), а в том, что распространение вредоносных программ для ЭВМ – это статья уголовного кодекса (273, если кто не знает), до трёх лет (правда, прецедентов такого наказания пока нет). Не знаю уж, насколько смартфон может быть отнесён к ЭВМ или «иным машинным носителям», но путь этот явно не самый законный. И это главная причина, по которой не называется имя автора разработки. Она же надёжно страхует такие устройства от массового распространения и открытой, легальной продажи.
Но будем реалистами. Вероятность серьёзного наказания за обладание подобной противоугонкой даже не мала – она ничтожна. «Троян» получает ответ от телефона владельца, после чего засыпает и обнаружить его практически невозможно. То есть, никому никакого вреда он не приносит и хороший адвокат легко докажет безосновательность отнесения этой программы к категории вредоносных. Ущерб, понесённый владельцем заражённого смартфона достигает хорошо если трёх рублей, за использованный трафик, за такую сумму судиться захотят не многие. В случае с «Навителом» всё ещё проще – он взят просто потому, что попался под руку. Не исключено, что фирма ЦНТ будет заинтересована в выпуске официальной версии своей программы со встроенной функцией поиска, тогда разработчик готов передать ей список необходимых изменений. Да кроме «Навитела» ещё много программ навигации существует, в том числе и бесплатных. Можно взять какую-нибудь «нарисуйку» с картами OpenStreetMap…Короче, это не проблема.
Заметим, несанкционированный коннект по bluetooth хоть и возможен, но является взломом. А вот коннект по WiFi возможен совершенно легально, тем более, что всё больше телефонов оснащаются «вай-фаем». И не только на приём, но и на раздачу. А дальность действия WiFi даже побольше будет, чем у bluetooth. Поэтому разрабатывается сразу двухмодульная схема. По WiFi, кстати, можно вести машину в городе, с его обилием хот-спотов, и это позиционирование мало будет уступать GPS. Эта функция незаменима при угоне методом погрузки в КУНГ, когда экранируется GPS. Например, в сети БиЛайн-ВайФай, покрывающей Москву, можно найти «закладку» точнее, чем с LBS.
Теперь принципиальный вопрос: зачем городить огород и заниматься встраиванием такого устройства в штатную навигацию, не проще ли сделать отдельную автономную противоугонку? Некоторые аргументы в пользу такого решения были приведены выше, но они не исключают и создание отдельного устройства. Правда, с ним сложнее всё в том же юридическом плане: модернизация готового аппарата – это одно, а выпуск целенаправленного распространителя «троянов» - немного другое.
Понятно, что уязвимостей у описанного решения хватает. В конце концов, многих сигнал приведёт на радиорынок, где продаются ворованные штатные «магнитолы» - в том случае, если автомобиль угоняли на запчасти. Но в активе всегда останется малая распространённость, отсутствие рекламы и подробной информации о принципах работы. Значит, угонщики не будут считать это угрозой своему бизнесу и разрабатывать меры противодействия.
Бредоватая идея.
Уж лучше с таким расчётом вживить ЖСМ модуль срабатывающий периодично или по событию, в саму магнитоллу. Если авто идёт на перепродажу ,то оно всё-равно войдёт в зону ЖСМ,причём отследить его можно будит не только по координатам ,но и по базовым станциям.
Если же авто идёт на разбор, то угонщикам достаточно снять акку-р и в обоих случаях ничего не поможет.Нужно делать ещё отдельно спящее питание для мафона либо ЖСМ модуля, а батарея большой ёмкости в него не влезит, так что запас времени автономной работы будит невысок и если авто в боксе разбирается ,то даже неделя это ничто.
может кто поковыряет японческую прошивку и найдёт этот самый кусок, который работает с CAMERA ECU (пытался англоязыровать тут https://out-club.ru/board/showthread...13813&page=240 ) и прикрутит его в америкосовскую N-04?
возможно ли это в теории?
нас с такими машинами уже много и я думаю можно и коммерчески будет проработать этот вопрос если все получится
может кто поковыряет японческую прошивку и найдёт этот самый кусок, который работает с CAMERA ECU (пытался англоязыровать тут https://out-club.ru/board/showthread...13813&page=240 ) и прикрутит его в америкосовскую N-04?
возможно ли это в теории?
В теории возможно всё, но на практике, нужно иметь уйму времени для написания утилит по сборке/разборке ПО MMCS. Учитывая её немассовость, коммерческие проекты отметаются. Нужно либо усилие группы энтузиастов, либо огромное количество времени. Я ковыряю эту тему в свободное время, которого практически нет, а Японские головы не ставлю целью совсем, как неактуальные в Москве и Европе....
В теории возможно всё, но на практике, нужно иметь уйму времени для написания утилит по сборке/разборке ПО 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.