Преамбула: сразу оговорюсь, я - не программист, правда во времена существования DOS мог написать практически все, что угодно, не исключая и вирусы, но это было давно, хотя некоторые познания в области построения систем остались. Поэтому, если тут есть программеры, то поправьте меня, если я в чем-то не прав.
Итак, попытаюсь объяснить логику своего предыдущего поста по поводу невозможности программно без Platform Builder'a создать прошивку из дампа.Понятие ROM на WinCE 4.20 и 5.00 существенно отличается, не физически, конечно, а по методам использования. На 5.0 нет ROM в том понимании, как это было на 4.20: нету больше понятия XIP - здесь все файлы копируются в оперативную память перед выполнением (отсюда и понятие paging pool, которого не было на 4.20). Конечно, не считая бутлоадера "первой степени" (или IPL). Как правило его размер не более 1 кб и он нужен только для старта девайса, минимальной инициализации железа, необходимого для загрузки в RAM и передачи управления загрузчику "второй степени" (SPL).
SPL хранится в binary разделе DOC-чипа, IPL (который мы знаем как U2Bxxx.bld) - вообще в отдельной области (с адреса 0x0, которую лучше не трогать).Далее SPL уже полностью инициализирует железо, проверяет надо ли войти в режим бутлоадера, и определяет какую из версий системы требуется загрузить (update loader или нормальную OS). Update loader используется исключительно для установки обновлений ROM рекомендованным микрософтом способом (на уровне отдельных пакетов, а не всей прошивки).Далее SPL распаковывает в RAM, по заданному разработчиками адресу, выбранную версию ядра, и прыгает туда. На этом моменте, кстати, мы теряем первые 4 мегабайта оперативки. Это нельзя называть XIP (eXecute-In-Place, хотя формат идентичен), т.к. исполнение происходит не in-place, а путем предварительной загрузки кода в RAM. Ну а далее уже процесс загрузки идет как обычно. NK.exe грузит device.exe, filesys.exe и т.п., инициализируется первая партия драйверов, в частности драйвер DOC, и уже потом подгружается основной реестр и остальная часть системы. Так как на первой фазе используется другая копия реестра (boot.hv), и writeable копии реестра еще нету, то все хэндлы девайсов, проинициализированных на этой фазе остаются известны только ядру и в hklm\drivers\active не попадают.Здесь сходства заканчиваются...
Просто читать из памяти можно было на 4.20:
char *Rom = (char*) виртуальный адрес РОМ. Виртуальный адрес из физического - VirtualCopy().
Это можно сделать и на 5.0, НО!!!:
На пятой - все хранится на флеше который не отображается в память, и работа с ним идет как с обычным диском. (IMGFS). Т.е.:
WINAPI CreateFile (), DiskIOControl ().
Т.е. ROM хранится в IMGFS (FATFS, BINFS) партиции чипа, соответственно АПИ тут - работа с дисками. Так я сделал RomReader. (если кто возьмется улучшить или предложить что-то свое).Таблица разделов идентична по формату с MBR в жестких дисках (можно увидеть сигнатуру 0х55 0хAA в конце первого сектора, последующий после MBR сектор можно еще найти по строке ECEC). В MBR может находиться до 4 разделов. Первый - Os loader (формат практически идентичен РОМам 5.0, потому его понимает dumprom, а мы его знаем как OSxxx.IMG), там находится копия nk.exe, которая используется при обычной работе системы. Второй и третий IMGFS -перезаписываемые твики реестра и ShellAPP. Четвертый, необязательный - FAT партиция, которая может использоваться под persistent storage, хранение скажем radio ROM, или вообще не использоваться - это оставлено на совесть разработчика.
Первые 2 раздела могут быть не запакованы, в этом случае их очень удобно патчить на предмет отучения от сертификатов. Но могут быть и запакованы, и таких девайсов становится все больше.Понятно, что с МБР работать достаточно просто, а также несложно "сдампить" или русским языком - сделать копию любой партиции, а потом просто останется положить ее на карточку в виде файлов прошивки. Дело в том, что мы не задумываемся - где лежат куски образа, потому что APIшные функции сами выполняют за нас эту грязную работу. Мы просто читаем с диска так, как будто содержимое на нем лежит последовательно друг за другом.А что же на 4.20 ? На самом деле граница RAM-ROM сильно размыта...В РОМ не сожержится никаких образов, все модули и файлы разбиты на секции, секции расшвырены по всему RAM (напомню, что адресное пространство у WinCE до 4 Гиг)...Можно собрать эти ошметки в один файл (так делает, кстати ROMExtractor, кстати - почему в шапке советуют ей не пользоваться ?), можно даже попытаться таким образом найти все файлы и модули, но все уперается в релоки (адресную таблицу)....
И толку от того, что мы соберем такой образ из ROM ? Он не будет работать ни на одной уважающей себя операционной системе..Единственный выход - Platform Builder, который раз и навсегда собирает прошивку для конкретного типа устройств в формате BIN (существуют и другие форматы).Теперь отвечу:
ЦитатаПолный дамп вполне реально снять c рабочего прибора чисто программными методами - для своего JJ-320 я такую штуку написал (Atlas3_NR).
Я не утверждаю, что нельзя снять, я говорил: "залить", исключая JTAG, т.е именно программно и именно для 4.20, а у уважаемого xu-wf - 5.0...Надеюсь, мало-мальски без сумбура объяснил. PS.
Можно поступить так же, как и xu-wf в своей проге. Это будет 100 % рез-т, но узкоспециализированный. Зная потроха конкретного железа вплоть до внутренних адресов всех портов и регистров, а также все контролы, можно сдампить все в "белых перчатках". Но это - почти уже мини- PlatformUnBuilder И об универсальности здесь речи нет, о чем xu-wf сразу и сказал.--------------------
Итак, попытаюсь объяснить логику своего предыдущего поста по поводу невозможности программно без Platform Builder'a создать прошивку из дампа.Понятие ROM на WinCE 4.20 и 5.00 существенно отличается, не физически, конечно, а по методам использования. На 5.0 нет ROM в том понимании, как это было на 4.20: нету больше понятия XIP - здесь все файлы копируются в оперативную память перед выполнением (отсюда и понятие paging pool, которого не было на 4.20). Конечно, не считая бутлоадера "первой степени" (или IPL). Как правило его размер не более 1 кб и он нужен только для старта девайса, минимальной инициализации железа, необходимого для загрузки в RAM и передачи управления загрузчику "второй степени" (SPL).
SPL хранится в binary разделе DOC-чипа, IPL (который мы знаем как U2Bxxx.bld) - вообще в отдельной области (с адреса 0x0, которую лучше не трогать).Далее SPL уже полностью инициализирует железо, проверяет надо ли войти в режим бутлоадера, и определяет какую из версий системы требуется загрузить (update loader или нормальную OS). Update loader используется исключительно для установки обновлений ROM рекомендованным микрософтом способом (на уровне отдельных пакетов, а не всей прошивки).Далее SPL распаковывает в RAM, по заданному разработчиками адресу, выбранную версию ядра, и прыгает туда. На этом моменте, кстати, мы теряем первые 4 мегабайта оперативки. Это нельзя называть XIP (eXecute-In-Place, хотя формат идентичен), т.к. исполнение происходит не in-place, а путем предварительной загрузки кода в RAM. Ну а далее уже процесс загрузки идет как обычно. NK.exe грузит device.exe, filesys.exe и т.п., инициализируется первая партия драйверов, в частности драйвер DOC, и уже потом подгружается основной реестр и остальная часть системы. Так как на первой фазе используется другая копия реестра (boot.hv), и writeable копии реестра еще нету, то все хэндлы девайсов, проинициализированных на этой фазе остаются известны только ядру и в hklm\drivers\active не попадают.Здесь сходства заканчиваются...
Просто читать из памяти можно было на 4.20:
char *Rom = (char*) виртуальный адрес РОМ. Виртуальный адрес из физического - VirtualCopy().
Это можно сделать и на 5.0, НО!!!:
На пятой - все хранится на флеше который не отображается в память, и работа с ним идет как с обычным диском. (IMGFS). Т.е.:
WINAPI CreateFile (), DiskIOControl ().
Т.е. ROM хранится в IMGFS (FATFS, BINFS) партиции чипа, соответственно АПИ тут - работа с дисками. Так я сделал RomReader. (если кто возьмется улучшить или предложить что-то свое).Таблица разделов идентична по формату с MBR в жестких дисках (можно увидеть сигнатуру 0х55 0хAA в конце первого сектора, последующий после MBR сектор можно еще найти по строке ECEC). В MBR может находиться до 4 разделов. Первый - Os loader (формат практически идентичен РОМам 5.0, потому его понимает dumprom, а мы его знаем как OSxxx.IMG), там находится копия nk.exe, которая используется при обычной работе системы. Второй и третий IMGFS -перезаписываемые твики реестра и ShellAPP. Четвертый, необязательный - FAT партиция, которая может использоваться под persistent storage, хранение скажем radio ROM, или вообще не использоваться - это оставлено на совесть разработчика.
Первые 2 раздела могут быть не запакованы, в этом случае их очень удобно патчить на предмет отучения от сертификатов. Но могут быть и запакованы, и таких девайсов становится все больше.Понятно, что с МБР работать достаточно просто, а также несложно "сдампить" или русским языком - сделать копию любой партиции, а потом просто останется положить ее на карточку в виде файлов прошивки. Дело в том, что мы не задумываемся - где лежат куски образа, потому что APIшные функции сами выполняют за нас эту грязную работу. Мы просто читаем с диска так, как будто содержимое на нем лежит последовательно друг за другом.А что же на 4.20 ? На самом деле граница RAM-ROM сильно размыта...В РОМ не сожержится никаких образов, все модули и файлы разбиты на секции, секции расшвырены по всему RAM (напомню, что адресное пространство у WinCE до 4 Гиг)...Можно собрать эти ошметки в один файл (так делает, кстати ROMExtractor, кстати - почему в шапке советуют ей не пользоваться ?), можно даже попытаться таким образом найти все файлы и модули, но все уперается в релоки (адресную таблицу)....
И толку от того, что мы соберем такой образ из ROM ? Он не будет работать ни на одной уважающей себя операционной системе..Единственный выход - Platform Builder, который раз и навсегда собирает прошивку для конкретного типа устройств в формате BIN (существуют и другие форматы).Теперь отвечу:
ЦитатаПолный дамп вполне реально снять c рабочего прибора чисто программными методами - для своего JJ-320 я такую штуку написал (Atlas3_NR).
Я не утверждаю, что нельзя снять, я говорил: "залить", исключая JTAG, т.е именно программно и именно для 4.20, а у уважаемого xu-wf - 5.0...Надеюсь, мало-мальски без сумбура объяснил. PS.
Можно поступить так же, как и xu-wf в своей проге. Это будет 100 % рез-т, но узкоспециализированный. Зная потроха конкретного железа вплоть до внутренних адресов всех портов и регистров, а также все контролы, можно сдампить все в "белых перчатках". Но это - почти уже мини- PlatformUnBuilder И об универсальности здесь речи нет, о чем xu-wf сразу и сказал.--------------------
Установить IGo8, Навител, Гармин и Ситигид в свой любимый КПК