abort handler. вопрос к гуру: как узнать адрес, куда пишутся данные? Опции

[max sagaydachny]

имеется устройство с процессором arm946es.
его родной firmware позволяет запускать бинарные файлы с SD карточки.
в результате запуска стартует не родная операционная система, а код из бинарного файла.

цель проекта: запустить процесс в уже работающей операционной системе.
для этого код из бинарного файла должен передать управление обратно на ROM, чтобы продолжилась загрузка операционной системы ( скорее всего с этим у нас проблем нет )

вопрос: как к нашему коду вернется управление после старта операционной системы?
ответ: используя Protection Unit мы пытаемся не позволить операционной системе установить ее родной abort handler
проблема в том, что минимальный размер страницы при использовании Protection Unit - 4kb
a нам нужно не позволить записать только 4(8?) байтов в vector table (data abort handler и prefetch abort handler )

тоесть наш обработчик должен иметь возможность узнать, что и куда в этом сегменте пытались записать.
если записываемый адрес не наш abort handler - нам нужно записать эти данные как и предполагал их записать "чужой" код.
получается, что нам нужен парсер инструкциЙ STR.
изобретать велосипед не хочется. скорее всего этот код давно существует.
мне не удалось этот код найти.
я смотрел проекты: qemu, skyeye, softgun, swarm
немного тяжело анализировать такие большие проекты, когда мне всего лишь нужен парсер для двух инструкций STR.

вопрос: где такой код искать, который позволяет узнать, по какому адресу предполагалась запись?
также возможно мы используем совершенно не правильный подход для решения нашей проблемы.


выслушаю и приму любые дикие идеи.

[scifi]

Такая штука реализована в Linux. Ссылка на код есть в этой теме:

http://electronix.ru/forum/index.php?showtopic=36258&hl=

[max sagaydachny]

scifi - спасибо за идею

defunct

подробнее:

1) штатных средст, позволяющих запустить исполняемый файл из операционной системы - нету
2) можно запустить исполняемый код ВМЕСТО операционной системы.
3) мы предположили, что единственный способ запуска нашего кода внутри операционной системы :
- попытаться запустить операционную систему из нашего кода.
- "что-то" зделать, чтобы операционная система наш код не стерла в оперативной памяти.
- получить "как-то" после запуска операционной системы управление назад на наш код. это позволит нам полноценно использовать все функции операционной системы.


наш еще нереализованный вариант решения данной проблемы:
поставить свой Data Abort Handler и запретить запись на первые 4кб (и на область памяти, в которой находится тело нашего обработчика), чтобы операционная система не смогла поставить свой хандлер.
поэтому на наш хандлер ложится ответственность записи той области памяти внутри наблюдаемого сегмента, которая не затрагивает наш код - эмуляция той инструкции.

поэтому возникла необходимость в дизассемблере той инструкции, которая собиралась выполнить запись.




поскольку у меня знания в области архитектуры ARM не большие , я надеялся услышать альтернативные варианты решения проблемы


PS: операционная система живет в ROM (Flash)

Сообщение отредактировал max sagaydachny - Oct 25 2007, 12:37

[defunct]

наш еще нереализованный вариант решения данной проблемы:
поставить свой Data Abort Handler и запретить запись на первые 4кб (и на область памяти, в которой находится тело нашего обработчика), чтобы операционная система не смогла поставить свой хандлер.
поэтому на наш хандлер ложится ответственность записи той области памяти внутри наблюдаемого сегмента, которая не затрагивает наш код - эмуляция той инструкции.

И что?! Вы думаете достаточно будет только один обработчик подменить?
А IRQ, а FIQ? Для того чтобы не терять контроль над системой вам придется эмулировать не только DABT, а все исключения.
Надеюсь вы понимаете, чем это может грозить системе?

поэтому возникла необходимость в дизассемблере той инструкции, которая собиралась выполнить запись.

Это даже не вопрос, просто берете таблицу команд (ARM instruction set) с arm.com, там все расписано.

поскольку у меня знания в области архитектуры ARM не большие , я надеялся услышать альтернативные варианты решения проблемы
PS: операционная система живет в ROM (Flash)

Альтернативный и на мой взгляд правильный вариант - подправить ОС так, как требуется для работы вашего проекта, либо взять такой ОС который удовлетворяет вашим требованиям сразу. Раз ОС на Flash, значит перезаписать можно.