На этой странице, вы сможете найти полезную информацию по прошивкам PNA и программному обеспечению для этих целей, полезные советы и ответы пользователей. Часть добавленной информации будет размещена с других сайтов и только с разрешения на ее публикацию автором (ссылка и имя автора в нижней части сообщения). Информация будет постоянно добавляться и обновляться.
Описание процедуры переноса модуля из одной прошивки в другую с реалокацией адресов в слотах 0 и 1.
Итак имеется прошивка донор с нужным рабочим видео драйвером и имеется прошивка реципиент, в который этот драйвер нужно вставить, взамен имеющегося. Здесь небольшая оговорка, прошивки эти от одного прибора, но разной серии. Из этого следует, что размеры драйверов различаются не значительно и нам не потребуется передвигать другие dll.
Для начала разберем обе прошивки с помощью программы Xipport. Жмем кнопку dump xip.bin, ждем появления папки OUT. Затем делаем карты прошивок, жмем write maps. Смотрим карты, файл MAP.txt. Нас интересует информация о размещении в слотах нашего драйвера. Вот она.
Размещение донора в слотах: Слот 0 01e93000 - 01ea2000 L0000f000 initialized data of region_1 s3c24x0_disp.dll Слот 1 02e30000 - 02e60000 L00030000 Virtual base address of s3c24x0_disp.dll
Исходя из полученной информации рассчитываем необходимые "сдвиги" регионов. Для слота 0 регион донора нам нужно сдвинуть на 0х01e95000 минус 0х01e93000 равно 0х2000 если адрес размещения региона донора меньше адреса размещение региона реципиента, смещение будет положительным, если наоборот, смещение будет отрицательным. Для слота 1 виртуальный базовый адрес нам нужно сдвинуть на 0х02e70000 минус 0х02e30000 равно 0х40000 если виртуальный базовый адрес размещения донора меньше виртуального базового адреса размещение реципиента, смещение будет положительным, если наоборот, смещение будет отрицательным.
Необходимые величины смещений мы с Вами рассчитали. Теперь можно переходить непосредственно к самой процедуре. Как мы знаем, некоторые регионы модулей сжаты, поэтому перед тем как заняться перемещением модуля в виртуальном адресном пространстве, нам необходимо "разжать" сжатые регионы. Определить какие регионы сжаты мы можем по флагу o32[х].o32_flags:если второй байт равен xxxx20xx то регион сжат. Например в нашем случае это первый и второй регионы, имеющие флаги o32[1].o32_flags: C0002040 и o32[2].o32_flags: 40002040 (Эти данные мы берем из файла imageinfo.txt) Для "расжатия" используем программу BOOOFF. На первой вкладке (BIN NB0) выберите кнопку Decompress, в диалоге открытия файлов выберите необходимые файлы регионов. В нашем случае это будут файлы первого региона, в папке с именем модуля (s2c24x0_disp.dll) файл S001 и файл второго региона S002. После работы программы получим файлы S001.decompress и S002.decompress, а так же лог файлы S001.decоmpress.Log и S002.decompress.Log . Лог файлы на данном этапе нам не нужны, поэтому можете смело их удалить, что бы не путались под ногами.
Процедура реалокации на самом деле проста и не замысловата. Хотя ее описание может показаться сложным и запутанным. В двух словах объясню ее суть, что бы Вы понимали, что Вы делаете. Все ссылки внутри модулей прописаны в абсолютных адресах, т.е. если программе нужно обратиться к какой либо переменной, она считывает указатель на эту переменную. Указатель это адрес по которому эта переменная хранится. Сдвигая регион мы изменяем адреса хранящиеся в указателях. Т.е. если первый указатель хранил значение 0х01e93000, при перемещении нам нужно изменить этот адрес на 0х2000, и теперь этот указатель будет хранить другой адрес 0х01е95000. Т.е. будет указывать на адрес внутри региона расположенного в новом адресном пространстве слота. Открываем программу BOOOFF на вкладке MovModule и заполняем поля.
В поле "Адрес" пишем адрес региона донора в слоте 0. Берем этот адрес из карты донора (01e93000) В поле "Длина" пишем длину региона донора в слоте 0. Берем ее из карты донора (L0000f000) В поле "Смещение" пишем необходимое смещение адресов донора. Как рассчитать это значение описано с начале Слот 0 01e93000 - 01ea2000 L0000f000 initialized data of region_1 s3c24x0_disp.dll
Заполнив поля формы , нажимаем кнопку "Искать" и последовательно, в диалоге открытия файлов, выбираем необходимые файлы регионов донора. В нашем случае это файлы S000, S001.decompress,S002.decompress.
Реалокацию модуля в слоте 0 мы сделали, переходим к перемещению базового адреса. Процедура ни чем не отличается от реалокации региона в нулевом слоте. На вкладке MovModule и заполняем поля.
В поле "Адрес" пишем базовый адрес модуля донора в слоте 1. Берем этот адрес из карты донора (02E30000). В поле "Длина" пишем длину модуля донора в слоте 1. Берем ее из карты донора (L00030000). В поле "Смещение" пишем необходимое смещение базового адреса донора. Как рассчитать это значение описано с начале. Слот 1 02e30000 - 02e60000 L00030000 Virtual base address of s3c24x0_disp.dll
Заполнив поля формы , нажимаем кнопку "Искать" и последовательно, в диалоге открытия файлов, выбираем необходимые файлы регионов донора. В нашем случае это файлы S000, S001.decompress,S002.decompress.
Вот теперь мы с Вами закончили и процедуру изменения базового адреса в модуле донора. Теперь нам нужно сжать, разжатые нами регионы и внести изменения в файл imageinfo.txt.
Сжимаем регионы с помощью программы BOOOFF. На первой вкладке (BIN NB0) выберите кнопку Compress, в диалоге открытия файлов выберите необходимые файлы регионов. В нашем случае это будут файлы первого региона, в папке с именем модуля (s2c24x0_disp.dll) файл S001.decompress и файл второго региона S002.decompress После работы программы получим файлы S001.decompress.compress и S002.decompress.compress, а так же лог файлы S001.decоmpress.compress.Log и S002.decompress.compress.Log . Старые файлы регионов S001 и S002 переименуйте в S001_old и S002_old например. А файлы полученные после работы программы S001.decompress.compress и S002.decompress.compress, переименуйте в S001 и S002. Затем откройте файл imageinfo.txt донора и внесите в него изменения отражающие реалокацию:
o32[1].o32_vsize: 0000EFE0 o32[1].o32_rva: 0001F000 o32[1].o32_psize: 00002BD1заменить на полученный размер региона после сжатия, берем из файла S001.decompress.compress.Log и переводим в шестнадцатеричный вид. o32[1].o32_dataptr: P+00EC6788 o32[1].o32_realaddr: D=01E93000заменить на новый адрес региона в слоте 0т.е. на 01Е95000 o32[1].o32_flags: C0002040
o32[2].o32_vsize: 00000A28 o32[2].o32_rva: 0002E000 o32[2].o32_psize: 00000570заменить на полученный размер региона после сжатия, берем из файла S002.decompress.compress.Log и переводим в шестнадцатеричный вид. o32[2].o32_dataptr: P+001F77D0 o32[2].o32_realaddr: V+0002E000 o32[2].o32_flags: 40002040
как узнать новый размер регионов после сжатия? Для региона S001 открываем файл S001.decompress.compress.Log
Фаил - S001.decompress Нормальный размер - 45216 Сжатый размер - 11347
Смотрим значение сжатого размера, с помощью виндовского калькулятора переводим это десятичное значение в шестнадцатеричное 11347=0х2С53 Записываем его вместо старого значения o32[1].o32_psize: То же самое делаем для региона S002, открываем файл S002.decompress.compress.Log
Фаил - S002.decompress Нормальный размер - 2600 Сжатый размер - 1372
Смотрим значение сжатого размера, с помощью виндовского калькулятора переводим это десятичное значение в шестнадцатеричное 1372=0х55С Записываем его вместо старого значения o32[2].o32_psize:
После внесения всех необходимых изменений нужно сохранить файл imageinfo.txt. На этом процедура реалокации закончена. Копируем из папки MODULES донора в папку MODULES реципиента, папку с нашим модифицированным модулем. Так же из папки MODULES донора в папку MODULES реципиента копируем файл s3c24x0_disp.dll.txt. Этот файл описывает размещение регионов в прошивке и в принципе его можно не копировать, но для очистки совести скопируем и его.
После этого в программе Xipport, нажимаем кнопку realloc P, что бы наш новый модуль нормально разместился в прошивке. Затем жмем кнопку build xip_out.bin . Вот теперь точно все. Это и есть наша прошивка, с замененным и перемещенным модулем в формате nb0. Дальше, в зависимости от необходимого формата, можете преобразовать ее в bin(BOOOFF) или вставить с помощью хекс редактора в img прошивку.
Данное описание рассказывает о реалокации конкретного модуля, но этот алгоритм, может быть применен к любому модулю, лишь бы этот модуль подходил к типу процессора и coredll.dll содержала необходимые функции для работы перемещаемого модуля.
PS. При перемещении модулей и особенно при добавлении модулей, адреса в слоте 0 должны быть кратны 0х1000, а в слоте 1 кратны 0х10000.
Большая благодарность за разрешение на размешение информации и проделанный труд "holod"
Меняем имя файла или модуля, прямо в файле прошивки.
Зачастили вопросы, уже четыре за последнюю неделю, как поменять имя файла или модуля в прошивке. Человеку, мало мальски понимающего структуру NB0, этот вопрос кажется банальным. Но , от этого подобных вопросов не становится меньше. Разберём на конкретном примере. Имеем NK.bin из прошивки PN-365, задача переименовать aygshell.dll в aygshel2.dll. Конвертируем NK.bin в NK.nb0 буфом или хипом, кому как нравится. Строим карту. Ищем в MAP.txt строку 83011ff0 - 83011ffd L0000000d modname aygshell.dll . Тут написано что имя модуля лежит по виртуальному адресу 83011ff0. Что-бы найти его в самом файле NK.nb0 , нужно из 83011ff0вычесть physfirst. Его значение можно подсмотреть в файле ROMHDR.txt. В нашем случае physfirst: P=82200000. Итого 83011ff0-82200000=E11FF0. Открываем в хексе NK.nb0, идем на смещение E11FF0, видим имя aygshell.dll. Меняем его на aygshel2.dll, сохраняем полученный NK.nb0, конвертируем обратно в NK.bin. Всё, мы поменяли имя. Таким способом можно легко менять имена файлов и модулей, не пересобирая прошивку. Можно конечно разобрать, переименовать и собрать. Но мне кажется , в данном случае так проще.
Отдельное "спасибо" за проделанный труд и подготовленный материал "Kir7"
Берем архив из прикрепления, разархивируем в любое место. Запускаем. Выбираем в диалоговом окне наш дамп. Устанавливаем глубину цвета 16 bpp, затем выбираем размер окна(разрешение экрана прибора с которого снят дамп)
Затем клавишами PgDn , PgUp, просматриваем дапм, до появления части картинки.
Затем стрелками вверх-вниз, влево-вправо, выравниваем изображение в окне. Сохраняем в нужном формате, либо как bin, либо как bmp. Все.
Большая благодарность за разрешение на размешение информации и проделанный труд "holod"
Как из дампа, извлечь пригодный для прошивки файл.
Итак, в результате работы программы, мы получаем два файла: Pages.bin и Spares.bin. Первый файл содержит непосредственно дамп флэш памяти, второй содержит служебные байты.
Тут нужно немного описать строение флэш памяти: NAND память нашего прибора, состоит из последовательных блоков, которые в свою очередь разбиты на страницы. Каждый блок содержит 32 страницы, каждая по 512 Байт. Если все перемножим получим, что размер блока равен 16кБайт. Или в шестнадцатеричном виде 0х200*0х20=0х4000. В конце каждой страницы содержится 16 байт служебной информации, сообщающей системе, является ли этот блок хорошим или плохим (бэд) блоком. Так же в этих байтах хранятся коды коррекции ECC. Так вот файл Pages.binсодержит последовательность блоков, а файл Spares.binсодержит последовательность служебных байтов.
Итак для работы будем использовать любой HEX редактор. Откроем в нем полученный нами файл Pages.bin. Вначале файла, с адреса 0х0000 по адрес 0х0FFF, располагается первый загрузчик. В терминологии Самсунга - nBOOT, этот загрузчик, производит первичную инициализацию процессора, памяти и т.д. и загружает второй, основной загрузчк - EBOOT, который уже производит окончательную инициализацию всего железа, грузит в память образ системы и запускает ее. Далее с адреса 0х1000 располагается ТОС (Table Of Contents) Вот ТОС нашего прибора:
Из ТОС мы можем узнать: 1. Виртуальный адрес загрузки EBOOT в память равный 8C 05 D0 00 2. Физический адрес размещения EBOOT в NAND памяти равный 00 00 14 00 3. Длину EBOOT в байтах равную 00 05 00 00 4. Контрольную сумму рассчитанную как сумма всех байт равную CC A4 F1 5. Виртуальный адрес загрузки OS в память равный 8C 40 C0 00 6. Физический адрес размещения OS в NAND памяти равный 00 16 14 00 7. Длину OS в байтах равную 01 77 04 04 8. Контрольную сумму рассчитанную как сумма всех байт равную 91 88 A6 37
Здесь нужно отметить, что данные из памяти считываюся процессором в обратной последовательности, поэтому, например значение длины OS видим 04 04 77 01 , читаем 01 77 04 04.
Если наша NAND не имеет плохих(бэд) блоков, то процесс извлечения образа загрузчика и образа оси, предельно прост. Берем из ТОС начало, прыгаем туда, делаем отметку. Затем переходим в конец, равный сумме начала и длины и прыгаем туда. Выделяем область между началом и концом, копируем. Создаем в HEX редакторе новый файл, вставляем копию. Осталось сохранить этот файл, под именем EBOOT.nb0 для загрузчика или NK.nb0 для оси.
Если NAND имеет плохие(бэд) блоки, наша задача несколько усложняется. Нам необходимо вырезать из дампа, данные этих плохих блоков. Иначе наша прошивка не загрузится. Итак как же определить наличие плохих(бэд) блоков? Вот тут то нам и понадобится файл Spares.bin. Открываем его в HEX редакторе.
Это так называемые экстра данные, имеющие 16 байт длины, на каждую страницу блока. Эти данные идут после каждой страницы и несут в себе информацию о состоянии блока. Первые два байта, порядковый номер страницы, шестой байт индикатор бэд блока, байты с девятого по шестнадцатый коды коррекции ECC. Если блок помечен как плохой, шестой байт первой и второй страницы блока, отличается от значения FF. Так же, если блок плохой первая и вторая страница блока могут иметь нули. Вот как на примере, выделенное красным. Или как вариант, экстраданные всех 32 страниц блока, могут быть забиты нулями. Как на примере ниже.
Как же, используя эти данные, определить адреса бэд блоков, что бы вырезать их из дампа? Для начала на нужно определить, есть ли в нашем дампе, бэд блоки. В HEX редакторе задаем поиск, на последовательность в двадцать нулей ( 00 00 00 00 00 00 00 00 00 00 ). Смотрим результаты поиска и записываем адрес экстраданных первой страницы блока. Для первого примера это 0х05 8000. Для второго примера 0х0B 0000. Бэд блоков может быть и больше, чем два. Важно определить их все. Теперь когда мы нашли и записали адреса первых страниц всех бэд блоков, приступим к расчету адресов этих блоков, что бы вырезать их из дампа. Тут есть небольшой нюанс, вырезать бэд блоки нужно с конца, т.е. сначала найдем адрес последнего бэд блока и вырежем его, потом предпоследнего и т.д. И так найдем адрес последнего бэд блока из наших примеров. Адрес экстраданных первой страницы блока, как мы уже видели, равен 0хB 0000, отбрасываем последний 0 (ноль) получаем 0хB000. Это значение умножим на длину страницы, выше я писал что длина страницы равна 512 байт, в шестнадцатеричном значении 0х200. 0хB000*0x200=0x160 0000 это и есть адрес начала последнего бэд блока. Прыгаем туда и ставим метку. Как мы уже знаем, что длина блока равна 0х4000.Прибавляем к адресу начала блока, его длину, получаем адрес конца блока. 0х160 0000+0х4000=0х160 4000 Вырезаем область между этими адресами. Таким же способом находим адрес начала следующего бэд блока из первого нашего примера. 0х05 8000 откидываем последний ноль, умножаем на 0х200 получаем адрес начала бэд блока 0хB0 0000. Прыгаем туда и ставим метку. Прибавляем к адресу начала блока, его длину, получаем адрес конца блока 0хB0 0000+0х4000=0xB0 4000. Вырезаем область между этими адресами.
Так же для очистки дампа от бэд блоков, можно воспользоваться программой Cleaner.
Программка, которая удаляет из дампа, сделанного прогой xu-wf бэд блоки. Положите программу в папку с файлами Pages.bin и Spares.bin, запустите ее. На выходе получите файл Pages_clean.bin в котором будут вырезаны бэд блоки.
PS: В процессе изучения дампов, выяснилось, что Мессады используют другой способ пометки бэд блоков. Поэтому данная программа не подходит для очистки дампов, снятых с Мессад. Хотя с них снимать дампы и бесполезно. Прошить убитый аппарат с карточки пока никому не удалось. А для прошивки JTAGом, можно и ручками поработать.
Осталось по таблице ТОС, найти адрес начала области EBOOT или OS. Отметить его, затем прибавить длину области EBOOT или OS. Скопировать эти области в новый файл и сохранить их.
Теперь у Вас будут два файла EBOOT.nb0 и NK.nb0. Нужно проверить, все ли правильно мы сделали. Это можно осуществить с помощью программы dumprom.exe. Программу прикладываю во вложении. Кидаем программу и ДЛЛ в папку, туда же кидаем наш файл, например NK.nb0. В этой же папке необходимо создать еще одну папку с именем dump. Далее выполняем команду в командной строке: dumprom.exe -d dump -5 NK.nb0. Этим мы говорим, рапаковать файл NK.nbo в папку dump используя метод сжатия WinCE 5.0 Если программа отработает корректно, в папке дамп вы увидите все файлы входящие в вашу прошивку. В случае с EBOOT.nb0, вы увидите один файл nk.exe.
Возникает вопрос, можно ли прошиться этими файлами? Ответ пока не однозначен. В прошивках после блока данных идет последовательность нулей, порядка 5-6 мегабайт.Для чего он, я не знаю и как рассчитать необходимое количество нулей, что бы прошивка корректно загрузилась, я тоже пока не знаю. Как только появится информация она будет добавлена в этот пост.
PS:Более простой способ, проверки правильности извлеченной прошивки (заключается в проверке контрольной суммы). Запускаем программу sum.exe с аргументом в виде названия файла. Например sum.exe NK.nb0. Программа покажет контрольную сумму, которую можно сравнить с той, что записана в ТОС. Теперь мы вырезали из дампа данные бэд блоков. Сохраним результат работы на всякий случай.
Данная информация предоставлена для ознакомительных целей и ее использование вы берете на свой страх и риск. За последствия автор ответственности не несет.
Прикрепленные файлы: скачать одним архивом тут - dumprom.rar - K9F1208B0B.rar - sum.exe - Cleaner.rar
Большая благодарность за разрешение на размешение информации и проделанный труд "holod"
Практические выводы, на основе анализа прошивок для мультихип в формате bin.
1. Четырехбайтный счетчик количества партишенов непосредственно предшествует массиву XIPCHAIN_ENTRY[], количество элементов в котором определяется счетчиком. Я не встречал прошивок больше чем с тремя партишенами. 2. Счетчик и непосредственно следующие за ним элементы массива XIPCHAIN_ENTRY[] представлены в файле bin одной записью, которая следует сразу за последним байтом одной из партишен или после последней партишен. Если после записи идет первая запись следующей партишен (т.е. chain не последняя запись в прошивке), то адрес этой записи (physical address of record) выровнен на 0x00100000 - партишены начинаются именно с таких адресов. 3. Длина записи при значениях счетчика: • 1 - 0x0298 байт (dec 664); • 2 - 0x0528 байт (dec 1320); • 3 - 0x07B8 байт (dec 1976) и т.д.... Именно все записи такой длинны и нужно проверять на наличие информации chain. В общем случае длина этой записи рассчитывается по формуле (счетчик * sizeof(XIPCHAIN_ENTRY) + 4 байта самого счетчика + 4 завершающих нулевых байта). Размер структуры XIPCHAIN_ENTRY = 656 байтов. 4. Физический адрес записи с информацией chain кратен 0x00001000. 5. В каждом отдельном XIPCHAIN_ENTRY: • первые четыре байта (pvAddr) это всегда адрес в физическом пространстве прошивки; • третьи четыре байта (dwMaxLength) всегда кратны 0x00001000; • следующие два байта (usOrder) могут принимать значение только от 1 до счетчика включительно; • еще два байта (usFlags) могут принимать значения только 1 или 2; • начиная с 20 байта обязательно присутствует ANSI строка из легитимных (отображаемых и допустимых для имен переменных и файлов) английских символов, заканчивающаяся нулем не длинее 32 символов. Если запись удовлетворяет всем этим условиям то это информация сhain и теперь мы знаем количество партишенов, их имена, адреса и прочее. Думаю, что все приведенные проверки проводить даже излишне, хватит 1 и 3, можно для уверенности добавить еще 5.3 и 5.4. В монохипе этой информации может не быть вовсе, на то он и монохип. В мультихипе, состоящем из бин (кстати, во избежание путаницы с теми мультихипами, которые состоят из nb0, я бы называл их мультибинами), кроме того, в IMAGE_HEADER (первые пятнадцать байтов файла прошивки) последние четыре байта (Run-time image length) включают в себя суммарную длину образа (все партишены в формате nb0 плюс XIPCHAIN_ENTRY с учетом выравнивания (если chain лежит между партишенами) его длины до начала следующей партишен, кратного, как сказано выше 0х00100000). Образы самих партишенов не имеют 15-бвйтного заголовка B000FF..., он просто откушен. Мультихиповые прошивки, состящие из nb0, получаются в PB конвертацией из мультибиновых с помощью cvrtbin.exe. С этой же задачей справляются и наши инструменты: они хоть и не "видят" второго и последующих bin'ов, но ркуоводствуясь данными о суммарной длинне образа из заголока прошивки, развертывают его правильно. Вообще XIPCHAIN_ENTRY может искаться и другими способами - стандартно через Extensions или тупым поиском строки "chain information", в данном случае описан еще один вариант.
В заключение вытяжка из исходников PB для асма и с:
#else typedef struct _XIPCHAIN_ENTRY { LPVOID pvAddr; // address of the XIP DWORD dwLength; // the size of the XIP DWORD dwMaxLength; // the biggest it can grow to USHORT usOrder; // where to put into ROMChain_t USHORT usFlags; // flags/status of XIP DWORD dwVersion; // version info CHAR szName[XIP_NAMELEN]; // Name of XIP, typically the bin file's name, w/o .bin DWORD dwAlgoFlags; // algorithm to use for signature verification DWORD dwKeyLen; // length of key in byPublicKey BYTE byPublicKey[596]; // public key data } XIPCHAIN_ENTRY, *PXIPCHAIN_ENTRY;
typedef struct _XIPCHAIN_SUMMARY { LPVOID pvAddr; // address of the XIP DWORD dwMaxLength; // the biggest it can grow to USHORT usOrder; // where to put into ROMChain_t USHORT usFlags; // flags/status of XIP DWORD reserved; // for future use }XIPCHAIN_SUMMARY, *PXIPCHAIN_SUMMARY;
typedef struct _XIPCHAIN_INFO { DWORD cXIPs; // // may contain more than one entry, but we only need the address of first one // XIPCHAIN_ENTRY xipEntryStart; } XIPCHAIN_INFO, *PXIPCHAIN_INFO; #endif
Отдельное "спасибо" за проделанный труд и подготовленный материал "Mi81"
Бета версия нового XipPort for WinCE5 с релоком модулей.
История изменений:
версия beta 02 Добавлена функция релока модулей
версия beta 03 добавлена функция авто добавления файлов
версия beta 04 добавлена функция релока модулей полностью размещенных в слоте 0 добавлена функция релока модулей с двумя регионами размещенными с слоте 0 добавлена функция релока модулей не имеющих регионов в слоте 0 добавлена функция релока модулей с регионами в RAM (nk.exe) добавлена функция автоматической коррекции изменяемых значений в файле imageinfo.txt добавлена функция автоматической коррекции изменяемых значений в файле ROMHDR.txt добавлена функция возможности выбора автоматического изменения значения physlast.
версия beta 04_01 пофиксен баг со сжатием регионов.
версия beta 05 01 удалено выравнивание региона на 4, регион обрабатывается в фактическом размере. добавлена возможность разбиения файлов на регионы, для добавления их в виде модулей.(как exe, так и dll) с последующим релоком в слотах. регион dll имеющий атрибут открытого на запись - сжимается. мелкие правки интерфейса.
версия beta 05 02 добавлено удаление существующих папок MODULES и FILES при дампе прошивки. добавлено удаление существующего файла с совпадающим именем при сборке прошивки. добавлена вкладка Misc, для различных процедур, в настоящее время добавлена кнопка decompress, для декомпрессии различных сжатых файлов. Файлы сохраняются в папку DECOMPRESSFILES.
версия beta 05 03 пофиксен баг с перезаписью файлов добавлено программа сжатия файлов. Файлы сохраняются в папку COMPRESSFILES.
версия beta 05 04 Пофиксен баг с реалокацией модулей преобразованных из файлов.
версия beta 06 01 Добавлен Авто релок в слотах.
версия beta 07 01 Добавлена функция дампа из файла bin формата. Добавлен конвертер bin -> nb0
версия beta 07 02 Добавлен вызов функции realloc P после завершения авто релока в слотах.
версия beta 08 01 Добавлен правильный конвертер nb0->bin, с автоматическим определением стартового адреса. Добавлена возможность сохранения файла прошивки в формате bin.
версия beta 09 01 Добавлено полная поддержка мульти хип прошивок Добавлено авторелок модулей на вершины слотов Добавлено автопреобразование файла в модуль с авторелоком на вершину слота Добавлено удаление модуля Добавлено удаление файла Добавлено определение свободного пространства в слотах Исправлен баг преобразования Bin->nb0->Bin (ограниченный размер записи) Изменена процедура релока в RАМ , добавлено автоматическое изменение RAMFree, RAMStart, Physlast. Мелкие правки.
Один нюанс нужно учитывать. Авторелок не релочит пока автоматом модули имеющие два региона в нулевом слоте. У меня это например модуль shdocvw.dll. Такой модуль нужно временно переместить из папки MODULES и после авторелока , релокнуть в ручном режиме на соответствующей вкладке.
Небольшой комментарий по работе конвертера nb0->bin. На сегодня, он корректно конвертирует файлы, которые соответствуют стандартному файлу nb0. Если в файле отсутствует указатель на ROMHDR, расположенный по оффсету 0х48 Надеюсь добавлю возможность корректной работы и с такими файлами. если конечно придумаю правильный алгоритм поиска ROMHDR.
Внимание! Данная программа выкладывается на условиях ее не коммерческого использования.
Программа для распаковки дампа, получаемого с помощью Atlas3_NR для прошивок типа Сhain. Создаёт NB0 и BIN файлы, фиксит TINYNK.bin, создаёт Chain.bin и chain.lst .Полученная таким образом прошивка готова для заливки в коробку.
В первую строчку вводи значение 512 (размер блока данных), во вторую 16 (размер spare данных). При условии, что дамп снят с обычного флэша на 64 мега. На выходе получишь Pages.bin и Spares.bin. Которые уже можно обработать утилитой - sorcery.
Описание: Программа предназначена для редактирования реестра Windows CE, находящегося в прошивках.
Внимание!!! Все существующие на данный момент программы-аналоги (CeRegEditor и т. д.) используют RGUCompr от Microsoft. И в результате получаем полностью неработоспособный реестр!
История изменений:
0.5.5 добавлена поддержка .rgu файлов - корректные отображение и обработка ключей и значений "со знаком минус"
0.5.4 добавлена функция поиска. - 4 панели вывода результата (Results 1-4) - настраиваимая панель управления (Find) - combobox, расположенный на тулбаре, для быстрого поиска в текущем документе (файле) - поиск в указанной папке (на диске), быстрая сортировка результата, до 1000000 вхождений - + куча всякой мелочи
Release history: --------------------- V. 0.5.5 + Support .rgu files
Программа для работы с образами WinCE - Remaker for WinCE 5-6.
Описание: Программа для работы с образами операционных систем WinCE. Восстанавливает таблицу реалокации модулей при извлечении.
В данных версиях реализованы пока основные функции. Работа с форматом NB0, BOOOFF, удаление, добавление файлов и модулей,извлечение файлов и модулей, восстановление таблицы реалокации при извлечении модулей. Добавление можно производить как из донора, так и простым сбросом файла над первой панелью. При сбросе на файлами, будет добавлен как файл, при сбросе над модулями, будет добавлен как модуль. Дамп nb0 и BOOOFF файлов, так же возможен простым сбросом над панелями.
История изменений Remaker_WinCE5.
11.04.2010. - Remaker_5_a_2 Добавлено: Извлечение файлов и модулей. Таблица реалокации dll пока не восстанавливается, но vbase приводится к оригинальному значению, т.е. vbase = 0х10000000
14.04.2010. - Remaker_5_a_3 Добавлено: Восстановление таблицы реалокации модулей, при извлечении.
15.04.2010.- Remaker_5_a_3.1 Исправлено: Баг с извлечением ехе модулей
16.04.2010.- Remaker_5_a_3.2 Исправлено: Баг фикс
18.04.2010.- Remaker_5_a_3.3 Исправлено: Баг фикс
20.04.2010.- Remaker_5_a_4 Исправлено: Баг фикс Добавлено: Прямой дамп и сохранение bin файлов. Дамп возможен как через меню, так и сбросом файла с расширением .bin над панелями. Добавлено: Дополнение файла формата nb0 нулями до размера файла из которого делался дамп. Для этого нужно установить чек бокс в меню Settings->Restory Size .nb0
29.04.2010.- Remaker_5_a_7 - Удалил из за багов Изменено: Процедура извлечения модулей, восстановления таблицы реалокации
01.05.2010.- Remaker_5_8 Переход из альфы в полноценную бету.
05.05.2010.- Remaker_5_9 Добавлено: Извлечение файлов и модулей из донора, Добавление файлов и модулей из донора, Компрессия-Декомпрессия файлов, Настройка отмены сжатия файлов при добавлении. Ручной реалок в физических адресах. Исправлено: Мелкие баги.
05.05.2010.- Remaker_5_9.1 Добавлено: Поиск в открытой карте
05.05.2010.- Remaker_5_9.2 Исправлено: Оптимизирована процедура восстановления таблицы реалокации
05.05.2010.- Remaker_5_9.3 Исправлено:Баг фикс
05.05.2010.- Remaker_5_9.5 Изменено: Процедура восстановления таблицы реалокации
11.05.2010.- Remaker_5_9.6 Изменено: Процедура восстановления таблицы реалокации
14.05.2010.- Remaker_5_9.7 Изменено: Процедура восстановления таблицы реалокации
15.04.2010.- Remaker_6_a_3 Добавлено: Извлечение файлов и модулей. Восстановление таблицы реалокации модулей, при извлечении.
16.04.2010.- Remaker_6_a_3.1 Исправлено: Баг фикс
18.04.2010.- Remaker_6_a_3.2 Исправлено: Баг фикс
4.06.2010.- Remaker_6_09 Синхронизированы возможности с версией 9 для WinCE5
Внимание!!! Данная программа выкладывается на условиях ее не коммерческого использования.
Прикрепленные файлы версий программ: скачать одним архивом тут Remaker_WinCE5_9.5.rar Remaker_WinCE5_9.6.rar Remaker_WinCE5_9.7.rar Remaker_WinCE6_09.rar Remaker_for_WinCE5.rar
Quick BIN Viewer программа для просмотра, анализа и сравнения прошивок типа bin и их реестров.
Описание: Quick BIN Viewer предназначен для просмотра, анализа и сравнения прошивок типа bin и их реестров. Функция сравнения работает только для моноксиповых прошивок! Просмотра - для любых стандартных Windows CE 5.0/6.0 и Windows Mobile прошивок. Умеет выполнять экспорт реестров hv и fdf прямо из прошивки в текстовый формат REGEDIT4 ANSI.
Описание версий.
# 28.05.10 - Базовая бета-версия 1.00. # 06.07.10 - добавлена процедура инсталляции/деинсталляции, хотя будет работать и без нее, т.к. все нужное содержит в себе. Устранена зависимость от Platform Builder'а, теперь программа стала самостоятельной и может устанавливаться на любом компьютере (ранее работала только на компе с установленным PB). # 10.07.10 - Добавлена возможность корректного экспорта реестра (впервые после самого Microsoft PB 6.0) в текстовый формат REGEDIT4, что позволяет свободно редактировать его и собирать с помощью regcomp.exe. # Экспорт реестра возможен как целиком, так по отдельным root-веткам и ключам. Выполняется через правый клик на соответствующем элементе в TreeView (левая панель окна программы). После того, как вы получите реестр, он будет автоматически открыт в Блокноте (Notepad) для редактирования или просмотра. Не забудьте сохранить его по опции меню "Save As..." Обратите внимание, что для дальнейшей сборки regcomp'ом сохранять надо в формате ANSI # 12.07.10 - Добавлена возможность сборки реестра из текстового файла в формате REGEDIT4 ANSI. Локаль определяется по содержимому реестра. Реализовано через опцию меню Тools -> Сompile Registry... # 17.07.10 - Стало возможным экспортировать в текстовый формат т.н. "разностный" реестр, в ситуации, когда для сравнения загружены одновременно две прошивки. В этом случае параметры, отсутствующие в реестре второй прошивки, имеют префикс "-" (минус), а те, которых нет в первой - префикс "+". Выглядит это примерно так: [HKEY_LOCAL_MACHINE\Explorer\Desktop] "-{000214A0-0000-0000-C000-000000000046}"="My Device" "+{000214A0-0000-0000-C000-000000000046}"="Мое устройство" "-{000214A1-0000-0000-C000-000000000046}"="Recycle Bin" "+{000214A1-0000-0000-C000-000000000046}"="Корзина" Это, на мой взгляд, упрощает редактирование тестового реестра в формате REGEDIT4 ANSI, т.к. различающиеся ключи в нем находятся рядом и легко отыскиваются поиском по символам "- или "+. Не нужно сравнивать два текстовых файла. Regcomp тоже понимает эти префиксы. Теперь вы "на лету" можете менять образы сравниваемых прошивок, как первой, так и второй. Если вам нужно заменить первую или вторую прошивки не выходя из программы, просто откройте другую прошивку через Image->Open... или Compare... # 25.07.10 - Добавлена возможность просмотра и сохранения в текстовом файле информации о прошивке, партишенах (для мультибин прошивок) и о составе файлов/модулей. Выполняется по правому клику в TreeView на нужном элементе и опции Info... Мелкая правка имен файлов по умолчанию при сохранении листинга реестра. Теперь бутовая часть реестра по умолчанию сохраняется в "Boot Registry.txt", остальная - "Registry.txt", полный реестр (для хайвов) - "FullRegistry.txt", а для отдельных ключей - "Key_имяключа.txt". # 30.07.10 - Исправлена ошибка в определении LOCALE при компиляции реестра. Добавлена обработка ошибки, связанной с попыткой получения полного листинга реестра при загрузке во вьювер одной из партишен мультибиновой прошивки, как автономной, когда в ней присутствует не весь реестр. Добавлена опция меню View -> Compare Options, благодаря чему при сравнении содержимого прошивок, появилась возможность выбирать способ сравнения: по именам файлов/модулей, их дате или размеру. Теперь окно regcomp'а не закрывается автоматически, чтобы можно было видеть его ошибки. # 06.08.10 - предпринята попытка исправить описанный выше дефект библиотек Microsoft, связанный с утерей пустых ключей, для чего пришлось написать свой парсер. Пока только для реестров формата fdf. Теперь, надеюсь, стало возможным получить точный листинг реестра этого типа через Menu -> Tools -> Get Hive Listing. Листинги, полученные прежним способом (из TreeView), остаются на совести Microsoft и не рекомендуются для последующей компиляции. В новом листинге отключена сортировка ключей, на тот случай, если последовательность драйверов в реестре имеет какое-то значение для сохранения работоспособности драйверов в некоторых прошивках. Такое предположение ранее высказывалось мною, однако до сих пор оно не проверено и остается предположением. # 07.08.10 - Добавлена возможность получать точный листинг файлов реестра типа hive. Делается так же, как с реестрами типа fdf, через Menu -> Tools -> Get Hive Listing... Чтобы получить правильный заголовок для бутового реестра, он должен иметь имя boot.hv. После того, как получены листинги всех частей реестра (boot.hv, default.hv и user.hv) просто объедините их в один файл, отредактируйте и скормите regcomp'у через Menu -> Tools -> Compile Registry... Отказался от выдачи не сортированного листинга, теперь он сортирован по алфавиту, что облегчает его чтение и поиск нужных ключей. Как оказалось, regcomp все равно переставляет ключи известным одному ему способом, поэтому, даже при не сортированной разборке с последующей сборкой, побайтного совпадения в оригинальном и вновь собранном реестре нет. # 08.08.10 - Исправлен баг с забытой веткой CURRENT_USER, выброшены ключи, у которых нет параметров, но есть субключи: они и так будут автоматически созданы regcomp'ом, улучшено форматирование вывода параметров типа REG_BINARY при разборке реестра типа hive, чтобы не создавать бесконечно длинных строк.
Внимание!!! Данная программа выкладывается на условиях ее не коммерческого использования.
Не знал куда прицепить ссылку, здесь наверное будет правильно... очень удобный онлайн-конвертер (TRANSLATOR, BINARY), раньше я им пользовался для издевательства над аппаратом))) Хотя может пригодится и не только для модернизации прошивки, а может и просто для изменения реестра