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.

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


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

[Dron_Gus]

Это уже сродни вирусописательству. Там тоже решаются задавчи, как "приклеиться" к чужому коду.

[max sagaydachny]

Это уже сродни вирусописательству. Там тоже решаются задавчи, как "приклеиться" к чужому коду.

давайте назовем это по другому - модификация системы для выполнения дополнительных действий... :-)

[max sagaydachny]

defunct
я думаю, что родной дата аборт хандлер там висит просто "на всякий случай".
я думаю, что его подмена не повлияет на работу операционной системы.
зачем менять обработчики IRQ и FIQ?

устройства, на которые нацелен проект: Canon камеры, на которых работает vxWorks

перезаписывать Flash, даже если бы это было возможно, не хочется по многим причинам (если что-то пойдет не так, я нехотел бы пытаться объяснять в сервисном центре , почему в моем аппарате не правильный образ Flash).

перезаписывать Flash, даже если бы это было возможно, не хочется по многим причинам (если что-то пойдет не так, я нехотел бы пытаться объяснять в сервисном центре , почему в моем аппарате не правильный образ Flash).

некоторые модели камер не позволяют запускать внешние исполняемые файлы, поэтому в принципе для этих моделей было бы неплохо изменить Flash, чтобы он позволял запускать файлы с карточки памяти.
тогда уже можно не заботиться о том, что что-то поломалось - просто удали файл с карточки....

[max sagaydachny]

abort handler - это обработчик ситуации, когда совсем все плохо. такого не может быть в работающих цифровых фото камерах, поэтому я считаю, что этот обработчик там - "на всякий случай", поэтому подмена его на наш обработчик достаточно безопасна.

мы его собираемся менять, чтобы иметь возможность получить управление обратно.

А как вы себе представляете процесс передачи управления из ОС вашему процессу?
используя data abort handler
я примерно знаю, с какими адресами оперирует операционная система.
на основе этого я могу написать свой data abort handler

еще раз напомню, что я не знаю достаточно хорошо архитектуру.
я могу быть кучу раз неправ.
поэтому и появился этот топик.

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

[defunct]

abort handler - это обработчик ситуации, когда совсем все плохо. такого не может быть в работающих цифровых фото камерах, поэтому я считаю, что этот обработчик там - "на всякий случай", поэтому подмена его на наш обработчик достаточно безопасна.

Все верно, но некоторые операционки используют DABT для определения объема подключенной памяти при стартапе. Если вы его тупо подмените - ОС может неверно определить объем памяти и девайс будет неверно работать.

мы его собираемся менять, чтобы иметь возможность получить управление обратно.

Data Abort происходит когда система находится в действительно плохом состоянии - в результате порчи какого-то указателя. Такая ситуация для отлаженного девайса - артефактная, т.о. управление назад вы получите ровно с такой же вероятностью, с какой девайс может сбойнуть.

используя data abort handler я примерно знаю, с какими адресами оперирует операционная система. на основе этого я могу написать свой data abort handler

Ну предположим написали, и что он вам даст? Ведь DABT это считайте краш системы.