Итак имеется прошивка донор с нужным рабочим видео драйвером и имеется прошивка реципиент, в который этот драйвер нужно вставить, взамен имеющегося. Здесь небольшая оговорка, прошивки эти от одного прибора, но разной серии. Из этого следует, что размеры драйверов различаются не значительно и нам не потребуется передвигать другие 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

Содержание файла imageinfo.txt

Размещение реципиента в слотах:
Слот 0
01e95000 - 01ea4000 L0000f000 initialized data of region_1 s3c24x0_disp.dll
Слот 1
02e70000 - 02ea0000 L00030000 Virtual base address of s3c24x0_disp.dll

Содержание файла imageinfo.txt

Исходя из полученной информации рассчитываем необходимые "сдвиги" регионов.
Для слота 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 донора и внесите в него изменения отражающие реалокацию:

Смотрим значение сжатого размера, с помощью виндовского калькулятора переводим это десятичное значение в шестнадцатеричное 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.

Теперь у Вас будут два файла 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"

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 для асма и с:

Отдельное "спасибо" за проделанный труд и подготовленный материал "Mi81"

История изменений:

Один нюанс нужно учитывать. Авторелок не релочит пока автоматом модули имеющие два региона в нулевом слоте. У меня это например модуль shdocvw.dll. Такой модуль нужно временно переместить из папки MODULES и после авторелока , релокнуть в ручном режиме на соответствующей вкладке.

Небольшой комментарий по работе конвертера nb0->bin. На сегодня, он корректно конвертирует файлы, которые соответствуют стандартному файлу nb0. Если в файле отсутствует указатель на ROMHDR, расположенный по оффсету 0х48 Надеюсь добавлю возможность корректной работы и с такими файлами. если конечно придумаю правильный алгоритм поиска ROMHDR.

Внимание! Данная программа выкладывается на условиях ее не коммерческого использования.

Release_XipPort_beta_008_001.rar

Release_XipPort_beta_009_001.rar

XIPPort.rar

Большая благодарность за разрешение на размешение информации и проделанный труд "holod"

Программа для распаковки дампа, получаемого с помощью Atlas3_NR для прошивок типа Сhain. Создаёт NB0 и BIN файлы, фиксит TINYNK.bin, создаёт Chain.bin и chain.lst .Полученная таким образом прошивка готова для заливки в коробку.

P.S. Добавил автоопределение типа ТОС.

Sorcery.exe

Почти тоже самое, но чуть быстрее работает.

Sor1.exe

Большая благодарность за информацию "Kir7"

В первую строчку вводи значение 512 (размер блока данных), во вторую 16 (размер spare данных). При условии, что дамп снят с обычного флэша на 64 мега. На выходе получишь Pages.bin и Spares.bin. Которые уже можно обработать утилитой - sorcery.

Большая благодарность за информацию "Holod"

Описание:
Программа предназначена для редактирования реестра Windows CE, находящегося в прошивках.

Внимание!!! Все существующие на данный момент программы-аналоги (CeRegEditor и т. д.) используют RGUCompr от Microsoft. И в результате получаем полностью неработоспособный реестр!

История изменений:

mregedit_v055

mregedit_v054

mregedit_v04

Большая благодарность за информацию "AnDim"

Описание:
Программа для работы с образами операционных систем WinCE. Восстанавливает таблицу реалокации модулей при извлечении.

В данных версиях реализованы пока основные функции. Работа с форматом NB0, BOOOFF, удаление, добавление файлов и модулей,извлечение файлов и модулей, восстановление таблицы реалокации при извлечении модулей. Добавление можно производить как из донора, так и простым сбросом файла над первой панелью. При сбросе на файлами, будет добавлен как файл, при сбросе над модулями, будет добавлен как модуль. Дамп nb0 и BOOOFF файлов, так же возможен простым сбросом над панелями.

История изменений Remaker_WinCE5.

История изменений Remaker_WinCE6

Внимание!!! Данная программа выкладывается на условиях ее не коммерческого использования.

Прикрепленные файлы версий программ: скачать одним архивом тут
Remaker_WinCE5_9.5.rar
Remaker_WinCE5_9.6.rar
Remaker_WinCE5_9.7.rar
Remaker_WinCE6_09.rar
Remaker_for_WinCE5.rar

Большая благодарность за информацию "Holod"

Описание:
Quick BIN Viewer предназначен для просмотра, анализа и сравнения прошивок типа bin и их реестров. Функция сравнения работает только для моноксиповых прошивок! Просмотра - для любых стандартных Windows CE 5.0/6.0 и Windows Mobile прошивок.
Умеет выполнять экспорт реестров hv и fdf прямо из прошивки в текстовый формат REGEDIT4 ANSI.

Описание версий.

Внимание!!! Данная программа выкладывается на условиях ее не коммерческого использования.

QuickBinViewer_Setup_v1.054

Для работы требуется Microsoft .NET Framework 3.5 SP1, если у вас он не установлен, то можно взять здесь, сервиспак -здесь.

Большая благодарность за информацию "Mi81"