запуск проги из RAM
Пользователи, просматривающие топик: none
|
Зашли как: Guest
|
Имя  |
| Сообщение |
<< Старые топики Новые топики >> |
|
|
запуск проги из RAM - 2008-01-22 22:03:18.006666
|
|
|
RasenHerz
Сообщений: 303
Оценки: 0
Присоединился: 2007-11-27 21:17:15.833333
|
можно ли безопасным способом добавить программу в оперативку о и запустить ее оттуда??? пожалста, если кто знает каким раком все это можно осуществить (можно даже на асемблере(пишу на С)) напишите как!!! ну иль ссылку киньте на инфу!!!
|
|
|
|
|
RE: запуск проги из RAM - 2008-01-22 22:18:06.860000
|
|
|
redsh
Сообщений: 338
Оценки: 0
Присоединился: 2007-06-17 22:35:25.540000
|
мона только с уничтожением своего процесса (( (по крайней мере, без драйвера). вот инфа: http://www.wasm.ru/article.php?article=memfile
|
|
|
|
|
RE: запуск проги из RAM - 2008-01-22 22:27:43.680000
|
|
|
RasenHerz
Сообщений: 303
Оценки: 0
Присоединился: 2007-11-27 21:17:15.833333
|
quote:
мона только с уничтожением своего процесса (( (по крайней мере, без драйвера)
а генерирование шелл-кода не пойдет? нельзя ли разместить все данные сначала в куче и передать управление туда??? 8|
|
|
|
|
|
RE: запуск проги из RAM - 2008-01-22 23:36:11.410000
|
|
|
kreol
Сообщений: 823
Оценки: 0
Присоединился: 2007-03-08 03:13:06.876666
|
quote:
ORIGINAL: RasenHerz
можно ли безопасным способом добавить программу в оперативку о и запустить ее оттуда??? пожалста, если кто знает каким раком все это можно осуществить (можно даже на асемблере(пишу на С)) напишите как!!! ну иль ссылку киньте на инфу!!!
В смысле запустить из оперативки? А откуда в таком случае запускаются обычные программы? Или ты имеешь ввиду засунуть код программы в память как данные, а потом передать туда управление? Тогда скорее всего нет, процессор жёстко следит, чтобы сегмент данных был сегментом данных, а сегмент кода - сегментом кода.
|
|
|
|
|
RE: запуск проги из RAM - 2008-01-23 00:00:43.503333
|
|
|
crbunny
Сообщений: 223
Оценки: 0
Присоединился: 2006-06-22 21:20:01
|
kreol, процессор ни за чем не следит.
RasenHerz : во первых, объясни, пожалуйста немного подробнее, а именно, что ты там будешь запускать:
1. Есть ли сырцы прикрепляемой проги?
2. Она большая?
3. Точно нельзя жестким диском пользоваться?
4. Секции в файле прикрепляемой программы.
5. ОС, винда, надеюсь :D.
Идея состоит в следующем: сегмент кода прикрепляемой программы - в буффер, управление передать туда (есть метод в типсотриксах от Касперски). Отальные секции смержить. Может будет работать. Запустить- не проблема, а вот таблица импорта и ресурсы это будет тяжко.
Итого: если получтся, напиши мауал, с радостью прочитаю.
|
|
|
|
|
RE: запуск проги из RAM - 2008-01-23 00:31:29.276666
|
|
|
redsh
Сообщений: 338
Оценки: 0
Присоединился: 2007-06-17 22:35:25.540000
|
он хочет полноценный процесс
|
|
|
|
|
RE: запуск проги из RAM - 2008-01-23 01:18:32.983333
|
|
|
kreol
Сообщений: 823
Оценки: 0
Присоединился: 2007-03-08 03:13:06.876666
|
quote:
ORIGINAL: crbunny
kreol, процессор ни за чем не следит.
Разве что в реальном режиме работы.
В защищённом режиме работы процессор использует для управления памятью таблицы дескрипторов, в каждом дескрипторе есть поле DPL, которое характеризует права доступа для сегмента, адресуемого этим дескриптором, и три бита поля типа:
quote:
000 - сегмент данных, разрешено только считывание
001 - сегмент данных, разрешено считывание и запись
010 - сегмент стека, разрешено только считывание
011 - сегмент стека, разрешено считывание и запись
100 - сегмент кода, разрешено только выполнение
101 - сегмент кода, разрешено выполнение и считывание
110 - подчиненный сегмент кода, разрешено только выполнение
111 - подчиненный сегмент кода, разрешено выполнение и считывание
И за правильным использованием нужного сегмента следит именно процессор, равно как он следит за тем, чтобы программа не вышла за предел своего сегмента.
Точно не скажу, но скорее всего DPL и поле типа формируются в дескрипторе при загрузке сегмента в память, и если ты его загрузишь как сегмент данных, то и работать с ним ты сможешь только как с сегментом данных.
|
|
|
|
|
RE: запуск проги из RAM - 2008-01-23 01:36:16.966666
|
|
|
RasenHerz
Сообщений: 303
Оценки: 0
Присоединился: 2007-11-27 21:17:15.833333
|
избавимся от неясностей:
- я использую ОС linux
- программа должна будет ОБЯЗАТЕЛЬНО запускаться из оперативки( но можно и из стека)
- программа может быть ЛЮБОГО размера
- какие-либо секции, импорты ресурсов отсутствуют
а теперь немного о задумке:
Я создаю интерпритатор (своего рода высокоуровневый асемблер, знаю звучит дико, но все же мне это реально надо), и решив отказаться от парсирования исходного кода со ступенчатым выполнением(управление вернется интерпритатору только после исполнения всех инструкций, а не по схеме: анализ кода-интерпретирование нескольких инструкций-выполнение инструкций-инетрпретирование следующих инструкций), я счел что самым оптимальным и быстрым(но не легким =))) способом будет записывать обработанный байт-код в оперативку (на крайняк, можно разместить его прямо в стеке интерпритатора, конечно че заранее проверив на безопасность =))) и выполнять его оттуда.
|
|
|
|
|
RE: запуск проги из RAM - 2008-01-23 01:38:43.813333
|
|
|
RasenHerz
Сообщений: 303
Оценки: 0
Присоединился: 2007-11-27 21:17:15.833333
|
но как было отмечено ранее очень желательно выполнить код именно как процесс!
|
|
|
|
|
RE: запуск проги из RAM - 2008-02-09 20:47:37.196666
|
|
|
tеstеr
Сообщений: 377
Оценки: -46
Присоединился: 2008-02-08 17:56:40.563333
|
Я писал такую вещь, предмет у нас был Компиляторы и методы транляции.
Делал весь вывод в буфер (большой с запасом): unsigned char bufer[2000]
Туда писал результат ассемблирования и в конце ставил код команды RET (использовал код 0xC3 - ближний возврат, так как bufer будет в том же сегменте, что вызывающая процедура)
Для передачи управления на результат ассемблирования использовал
__asm
{
call bufer;
}
Писалось данное в VS поэтому работало, я слышал с ассемблерными вставками в Linux-компиляторах не всё так просто, то есть просто так передать управление на bufer не получится, его надо как то проедварительно описать, но ты, наверное, умеешь это делать.
Прога была у меня токой:
Откыть файл
Передать его дескриптор в MyAsm(FILE*f, unsigned char*bufer)
делаем
__asm
{
всё суём в стек (все регистры)
mov old_EAX, EAX
mov old_EBX, EBX
; заносим всё в перемеменные
}
//выводим результат на экран:
До выполнения программы состояние таково
EAX = …
EBX = …
__asm
{
call bufer;
}
//Программа выполнилась, выводим результат:
__asm
{
mov new_EAX, EAX
mov new_EBX, EBX
; заносим всё в перемеменные
выталкиваем всё из стека
}
//выводим результат на экран:
После выполнения программы состояние таково
EAX = …
EBX = …
|
|
|
|
|
RE: запуск проги из RAM - 2008-02-09 21:07:10.650000
|
|
|
_SaZ_
Сообщений: 4329
Оценки: 398
Присоединился: 2008-01-30 02:18:05.553333
|
На www.rsdn.ru есть пример, и вроде даже компонент на дэлфи, который полностью реализует указанную задачу, без разрушения процесса - родителя. Долго искать где именно. Недавно эта тема тут поднималась.
|
|
|
|
|
RE: запуск проги из RAM - 2008-02-09 21:15:21.500000
|
|
|
tеstеr
Сообщений: 377
Оценки: -46
Присоединился: 2008-02-08 17:56:40.563333
|
Я перепутал малость:
всё заносим в bufer
в конце bufer ставим 0xC3 (RET)
__asm
{
всё суём в стек (все регистры)
mov old_EAX, EAX
mov old_EBX, EBX
; заносим всё в перемеменные
call bufer;
mov new_EAX, EAX
mov new_EBX, EBX
; заносим всё в перемеменные
выталкиваем всё из стека
}
//выводим результат на экран:
До выполнения программы состояние таково
EAX = ... //old_EAX
EBX = ...
После выполнения программы состояние таково
EAX = ... //new_EAX
EBX = ...
|
|
|
|
|
RE: запуск проги из RAM - 2008-02-09 21:42:23.270000
|
|
|
tеstеr
Сообщений: 377
Оценки: -46
Присоединился: 2008-02-08 17:56:40.563333
|
Перед выполнением я тут сохраняю значение регистров, я то в своей лабе наоборот инициализировал их.
|
|
|
|
|
RE: запуск проги из RAM - 2008-02-11 22:41:08.200000
|
|
|
Яски Хианто
Сообщений: 13
Оценки: 0
Присоединился: 2007-11-24 17:53:43.173333
|
quote:
ORIGINAL: kreol
Разве что в реальном режиме работы.
В защищённом режиме работы процессор использует для управления памятью таблицы дескрипторов, в каждом дескрипторе есть поле DPL, которое характеризует права доступа для сегмента, адресуемого этим дескриптором, и три бита поля типа:
quote:
000 - сегмент данных, разрешено только считывание
001 - сегмент данных, разрешено считывание и запись
010 - сегмент стека, разрешено только считывание
011 - сегмент стека, разрешено считывание и запись
100 - сегмент кода, разрешено только выполнение
101 - сегмент кода, разрешено выполнение и считывание
110 - подчиненный сегмент кода, разрешено только выполнение
111 - подчиненный сегмент кода, разрешено выполнение и считывание
И за правильным использованием нужного сегмента следит именно процессор, равно как он следит за тем, чтобы программа не вышла за предел своего сегмента.
Но ничто не мешает изменить эти права при помощи VirtualProtect или установить их прямо при выдилении с помощью VirtualAlloc.
|
|
|
|
|
RE: запуск проги из RAM - 2008-02-12 18:20:55.756666
|
|
|
kolPeeX
Сообщений: 1456
Оценки: 0
Присоединился: 2007-01-25 14:57:57.683333
|
quote:
ORIGINAL: RasenHerz
но как было отмечено ранее очень желательно выполнить код именно как процесс!
думаю, можно записать результат во временный файл и запустить его
|
|
|
|
|
RE: запуск проги из RAM - 2008-02-13 21:07:59.096666
|
|
|
RasenHerz
Сообщений: 303
Оценки: 0
Присоединился: 2007-11-27 21:17:15.833333
|
quote:
думаю, можно записать результат во временный файл и запустить его
нет, не катит. мало того, что придется соблюдать формат исполняемых файлов Linux, так это еще и долго (в плане отклика), мне надо что бы ЛЮБАЯ написанная функция могла быть НЕМЕДЛЕННО вызвана как функция исполняемой среды (для отладки и т.д.).
в винде создать такое довольно просто(шелл-код), а вот в Linux - это совсем другая история… ошибки сегментации сыпятся просто градом! =(
|
|
|
|
|
RE: запуск проги из RAM - 2008-02-14 02:52:28.170000
|
|
|
Ясkи
Сообщений: 204
Оценки: 0
Присоединился: 2008-02-12 22:56:17.683333
|
Я не понял задачи, ты же вроде пишешь интерпретатор? в этом случае в буфер пишется байт-код, а затем последовательно выполняется.
Или все таки компилятор? в этом случае можешь писать тоже в память, но придется нехило потрудиться, притом что в линуксе должна присутствовать какая-нить библиотека - интерперетатор питона хотя бы.
|
|
|
|
|
RE: запуск проги из RAM - 2008-02-14 08:25:51.013333
|
|
|
RasenHerz
Сообщений: 303
Оценки: 0
Присоединился: 2007-11-27 21:17:15.833333
|
пишется интерпритатор. просто необходимо проверять на валидность вводимую информацию (а полагаться на неизменность кода я не могу - это серьезный урон безопасности), убедиться в наличии кода возврата управления интерпритатору и т.д. кроме того как одна из возможностей моего интерпритатора рассматривается фоновая интерпритация (как у MS VS, только там компиляция) для облегчения отладки.
|
|
|
|
|
RE: запуск проги из RAM - 2008-02-14 12:20:35.873333
|
|
|
kolPeeX
Сообщений: 1456
Оценки: 0
Присоединился: 2007-01-25 14:57:57.683333
|
определись, что тебе нужно…
то ты хочишь запускать программу как шелл-код, потом как процесс
далее, ты хочешь, чтоб код вернулся ТОЛЬКО после выполнения ВСЕХ инструкций (т.е. без отладки, хотя непонятно, как программа вернется в твой интерпретатор), при том, что тебе "это еще и долго (в плане отклика)", на какой ты расчитываешь отклик выполняя шелл-код в контексте своего интерпретатора?
также, какой может быть отклик, если ты собираешься получать управление после выполняния программы?
а потом "чтобы ЛЮБАЯ написанная функция могла быть НЕМЕДЛЕННО вызвана как функция исполняемой среды (для отладки и т.д.)", при этом тебе еще нужна безопасность
если ты действительно хочешь иметь возможность управлять программой, то лучше записать в файл результат и выполнить его (вот тебе и процесс)
контролировать можно с помошью ptrace()
|
|
|
|
|
RE: запуск проги из RAM - 2008-02-14 23:20:30.533333
|
|
|
Ясkи
Сообщений: 204
Оценки: 0
Присоединился: 2008-02-12 22:56:17.683333
|
Чет толи я не совсем понимаю что такое интерпретатор, толи ТС не понимает чего он хочет. Интерпретатор же выполняется в своем процессе, а код который он интерпретирует держит у себя в памяти. И я знаю два способа выполнения, первый это код транслировать в байт-код (как сделано в пхп) или выполнять не транслируя. Первый способ будет выполняться быстрее, но необходимо тратить время на трансляцию. Так вот.
Транслироваться код может в фоновом режиме, там же будет проверяться на правильность синтаксис языка и все что может быть проверенно на этом этапе, также производится некоторая оптимизация.
Я не понимаю что значит код должен возвращаться к интерпретатору, код же выполняется самим интерпретатором, как он может жить своей жизнью то, если это не компилируемый язык - он выполняет только то, что позволяет ему выполнять интерпретатор, работает в его рамках, и это является одним из плюсов интерпретатора, второй это кросс-платформенность.
|
|
|
|
|
|
