Добрый день.

Господа программеры, прошу помочь кому не сложно с небольшой проблемкой:

Если обяснять просто, то ситуация такова:
Пишу собственный загрузчик. Выделяю память с помошью malloc, вписываю туда бинарный код из исполняемого файла, а потом ссылаюсь на эту память с помошью указателя на функцию и вызываю. Происходит Segmentation Fault, в ассме четко видно, что не позволяет запустить функцию, хотя в памяти видно, что бинарный код ф-ии верный и все правильно. 100%, что malloc не дает прав на EXECUTE.

Как выделить память чтобы были права на EXECUTE?

Заранее благодарю!

начнем с самого начала...
  во-первых, я глубоко сомневаюсь, что ты пишешь загрузчик  , загрузчики пишут либо на асме либо на С с НУЛЯ.
  во-вторых, шелл-код - это плохо   , и если ты хочешь использовать его при загруженном ядре, то скорее всего тебе придется обламаться: ядро не допускает передачу управления в сегмент данных, чтобы обойти это ограничение тебе надо ОЧЕНЬ постараться и как минимум хорошо разбираться в устройстве ядра (в том, что ты в нем разбираешься я очень сомневаюсь, т.к. иначе ты не создал бы этот пост).
  в-третьих, если даже ты и начнешь выполнять код на уровне ядра(а для этого надо написать модуль, и загрузить его в ядро(конечно же root'ом)), то здесь поджитает следующая проблема: стандартная библиотека С в ядре не работает и ее использование в ядре НЕВОЗМОЖНО, так что придется тебе , в основном оперировать ф-цией do_mmap() (я молчу про то что ты должен на зубок знать ассемблер)

  в общем, ты слишком уж замахнулся =))) так что если хочешь все-таки написать эту программу, то следующая лит-ра тебе не будет лишней: Д.Бовет, М. Чезати "Ядро Linux", Р. Лав "Разработка ядра Linux" + С.А. Раго, Стивенс "Unix. Профессиональное программирование"

1. показывай код
2. защита от выполнения может быть только на аппаратном уровне
какой процессор используется?

бред
для процессоров без поддержки NX-бита проблемы нет
если NX-бит поддерживается и используется проблема может быть, но она решается через __ioremap() несколькими строчками
да, кроме того, с чего вы взяли, что jeka23 работает с ядром?
загрузчик вполне может работать на пользовательском уровне и отображать некий код на линейное адресное пространство текущего процесса с разрешением всех релокаций
(такое может быть, например, если используется специфичный формат входных файлов, о котором не знает LD, для реализации какой-нибудь виртуальной машины)

А можно просто посмотреть исходники /lib/ld-x.y.z.so

пусть покажет исходный код, без него мне будет крайне тяжело продолжать обсуждения в топике.
MAKCim, вы должны знать что именно ф-ция do_mmap() из файла <mm.h>, выделяет новый "участок" линейных адресов(первый желаемый адрес может попробовать указать программист) который по-умолчанию помечается как готовый на ЗАПИСЬ. ЧТЕНИЕ И, самое главное, ИСПОЛНЕНИЕ. думаю, самое то будет разместить шелл-код именно там =), чем сидеть и извращаться с инлайн-ассемблером ;).

P.S. я не говорю что jeka23 работает именно с ядром, просто осуществить все задуманное легче всего через интерфейсы ядра.

это, конечно, хорошо
я с этим и не спорю
но вопрос то был в этом



все зависит от того, что надо получить в итоге

что-то я не очень понимаю о чем вы говорите. но давайте, попробуем разобраться =):
 1) Вот типичный шелл:

с тем, что ядро такие штуки не допускает я, конечно, загнул, т.к. являюсь ярым противником таких садистических увлечений =), но согласитесь, запуск шелла из собственного стека(!!!) это уже чересчур...
не проще ли нормално "попросить" ядро выделить адреса для кода???
 2) Я все же жду от автора топика исходный код... =)

RasenHerz, 
я не понимаю, к чему ваш последний пост 
причем здесь стек...

"Чукча не читатель - чукча писатель"  

<...> именно ф-ция do_mmap() из файла <mm.h>, выделяет новый "участок" линейных адресов(первый желаемый адрес может попробовать указать программист) который по-умолчанию помечается как готовый на ЗАПИСЬ. ЧТЕНИЕ И, самое главное, ИСПОЛНЕНИЕ. думаю, самое то будет разместить шелл-код именно там =), чем сидеть и извращаться с инлайн-ассемблером ;).

с тем, что ядро такие штуки не допускает я, конечно, загнул,<...>

Вот типичный шелл:


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

теперь все всем понятно? могу для особо одаренных объяснить более подробно....

товарищ jeka23 использует malloc() (-> mmap()/brk() -> |kernel| -> do_mmap()) 
т. е heap

не понятно   

RasenHerz, 

!  MAKCim

Модератор: В следующий раз будет бан!

за что предупреждение??? по-моему я никого не оскорбил...

И сново здравствуйте.

Уведомление на почту не работает почему-то, поэтому я и не предпологал, что мне люди отозвались, за что огромное Вам спасибо.

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

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

Обясню ситуацию чуть подробней:
Есть движок на пользовательском уровне, который переписывается отдельно под разные платформы. К этому движку идут бинарники, не прилинкованы ни к одной функции винды, но собранные под виндой с целью использования их под разными платформами. Я был конечно не прав, что использовал malloc, RasenHerz прав. Заменил на mmap с флагом PROM_EXEC и теперь ситуация немного другая:
У данных бинарников задан base image address - 0x33310000, а base image address у такого же "движка" под винду - 0x33300000 и расчет идет на то, что и под линуксом base image address будет задан 0x33300000 у "движка", а у меня получается такая ситуация, что "движок" под линуксом грузится на произвольный адрес (например 0x85af34ec23) и когда с помошью mmap выделяется память и первый параметр передается желаемый адрес выделяемой памяти(0x33310000), то память выделяется, но сразу же помечается как "out of bounds" и дальнейшая работа загрузчика не может продолжатся так как на первом же memcpy все валится с SIGBUS.

Я так понимаю, что вся фишка в том, что мне нужно base image address у линуксового "движка" поставить в 0x33310000, но никак не могу найти как это сделать с g++ компилятором..... Может кто-нить подсказать как это делается?

Еще раз извиняюсь, что не имею права давать код!