ЕХЕ в памяти!

← →
Tetros (2003-09-15 16:38) [0]

Господа, программисты!
Не поможете разобраться как можно запихнуть в память ЕХЕ файл
и там его запустить?
Был бы очень благодарен за любую инфу или исходники.
Заранее благодарен!

← →
Digitman (2003-09-15 16:53) [1]

http://delphimaster.net/view/7-1063605099/

← →
Tetros (2003-09-15 16:58) [2]

Что-то по этому адресу так никто ничем человеку не помог...
Есть еще идеи?

← →
Digitman (2003-09-15 17:03) [3]

> Tetros

ты хоть вник в суть того, что человеку ответили на его (100%-но схожий с твоим) вопрос ?

← →
Tetros (2003-09-15 17:09) [4]

Вроде ясно, надо РЕ-загрузчик свой писать, но в этом то и проблема... Я не проффесионал и не знаю толком формата РЕ файлов может поможете? Плиз :(

← →
Digitman (2003-09-15 17:18) [5]

> Вроде ясно, надо РЕ-загрузчик свой писать

полный контроль над загрузкой PE-модуля и стартом нового полноценного Win32-процесса имеют лишь "профессионалы" из MS ...

свой же собственный загрузчик (с вескими опять же ограничениями по последующему взаимодействию загруженного модуля и ОС) реально создать лишь для динамических библиотек ... но код DLL исполняется в контексте того же процесса, который грузит (тем или иным образом) и обращается затем к DLL, т.е. загрузка и использование DLL никак не связана с тем что тебя интересует - со стартом отдельного независимого процесса

разницу понимаешь ?

← →
Tetros (2003-09-15 17:22) [6]

Да, выходит что это невозможно?

← →
Digitman (2003-09-15 17:24) [7]

> Tetros

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

← →
Verg (2003-09-15 17:27) [8]

> Не поможете разобраться как можно запихнуть в память ЕХЕ
> файл
> и там его запустить?

А что, разве CreateProcess - это не "два в одном"?
И "запихнет" и запустит....

← →
Tetros (2003-09-15 17:28) [9]

Я хочу чтобы запуск моей проги нельзя было отследить по средству перехвата всего что запускается...

← →
Digitman (2003-09-15 17:30) [10]

> Tetros

перехватить можно все что угодно и когда угодно) ... не обольщайся на эту тему)

p.s.

никак заразу какую лепишь ? иначе зачем тебе скрытый механизм запуска процесса ?

← →
Tetros (2003-09-15 17:33) [11]

Нет не заразу, а в полне добрую тему, но дело не в этом. Возможно можно как-то все таки...

← →
Digitman (2003-09-15 17:36) [12]

> Нет не заразу, а в полне добрую тему, но дело не в этом.
>

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

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

← →
Verg (2003-09-15 17:37) [13]

> можно запихнуть в память ЕХЕ файл
> и там его запустить?

Это можно.

> запуск моей проги нельзя было отследить по средству перехвата
> всего что запускается...

Это нет.

← →
Tetros (2003-09-15 17:43) [14]

>> можно запихнуть в память ЕХЕ файл
>> и там его запустить?

> Это можно.

Как?

А задача вот в чем: в общем виде это легкая защита ЕХЕшника от взлома и т.п, сам ЕХЕшник находится в зашифрованом виде. Перед запуском мы загружаем его в память, там расшифровываем и выполныем. Использование диска, временных файлов и т.п нежелательно если к ним есть доступ для чтения/записи(по понятным причинам). Вроде все

← →
Digitman (2003-09-15 17:52) [15]

все ясно.
теперь поставь себя на место взломщика

он имеет твой ничем не защищенный EXE-файл (1), в теле которого "сидит" якобы зашифрованный (и тем самым якобы защищенный) другой EXE (2)

взломщик легко дизассемблирует файл (1), извлекает из него тело файла (2), изучает листинг, находит процедуры загрузки в память и дешифрования, трассировкой найденных алгоритмов восстанавливает оригинальное (незашифрованное) содержимое файла (2) - и все ! Вся твоя "защита", над которой ты парился, пардон, коту под хвост !

← →
Verg (2003-09-15 17:54) [16]

> > Это можно.
>
> Как?

Я уже говорил.

> Перед запуском мы загружаем его в память, там расшифровываем
> и выполныем.

Согласись - это "немного" контрастирует с первым сообщением в subj. :)

Кто это "мы", кстати? Я так понимаю, что это процесс, запуск которого тебе скрыть ужЕ не удасться.

← →
Tetros (2003-09-15 17:57) [17]

Согласен обсолютно!
Но мне просто ко всему прочему очень интересно разобраться в этом всем + можно применять в других областях...в общем нуна...

← →
Игорь Шевченко (2003-09-15 18:11) [18]

Если интересно - ищи исходные тексты Wine :) например, на www.winehq.com

← →
Tetros (2003-09-15 18:15) [19]

Спасибо посмотрю.

← →
AlexRya (2003-09-15 22:38) [20]

А wine тут с кокого оказалось?

← →
NightAngel (2003-09-15 22:55) [21]

> Digitman © (15.09.03 17:18) [5]
> полный контроль над загрузкой PE-модуля и стартом нового полноценного Win32-процесса имеют лишь "профессионалы" из MS

Чего же они такие умные и профессионалы оставили доступ к IDT в Win9х/ME. А ошибку, которая валила NT в консольном классе исправили только в последних SP к XP? ;)

> свой же собственный загрузчик (с вескими опять же ограничениями по последующему взаимодействию загруженного модуля и ОС) реально создать лишь для динамических библиотек ... но код DLL исполняется в контексте того же процесса, который грузит (тем или иным образом) и обращается затем к DLL, т.е. загрузка и использование DLL никак не связана с тем что тебя интересует - со стартом отдельного независимого процесса

Может быть я и ошибаюсь, но о старте процесса речи вроде-бы не было. Нужно запустить Exe"шник в контексте уже запущенного процесса. Ничего личного, просто интересно, почему Вы сделали вывод, что это невозможно осуществить? Или я что-то не так понял?

А по поводу вопроса, я тоже не представляю, где это возможно применить, кроме как в какой-нибудь гадости.

> Tetros ©

Если уж так необходимо, Вам проще просто дописать отдельную секцию (с декриптором) к Exe"шнику (а не мучиться с эмуляцией загрузчика), а секции с кодом, данными и импортом шифровать. Может сами ещё что-нибудь придумаете. Вариантов масса. Конечно неломаемой защиты Вы не напишете, но хоть что-то будет.

← →
Digitman (2003-09-16 08:24) [22]

> NightAngel

> Чего же они такие умные и профессионалы

ну ты ж заметил, наверно, что "профессионалы" у меня - в кавычках)

а то что к GDT/IDT "пустили" - ну, наверно, это чем-то обосновано было ... не берусь судить ... но дыра, соглашусь, изрядная)

> Может быть я и ошибаюсь, но о старте процесса речи вроде-бы
> не было

как раз вроде бы о старте отдельного процесса и шла речь, если я не ошибаюсь..
т.е., имея некий лин.адрес блока памяти со считанным из ресурса PE-образом в ВАП тек.процесса, выполнить на его основе полноценную загрузку (с последующим стартом) нового процесса на основе этого образа, не прибегая к документированным способам, обязательно требующим на входе PE-файл

← →
Tetros (2003-09-16 12:39) [23]

> NightAngel

> Если уж так необходимо, Вам проще просто дописать отдельную
> секцию (с декриптором) к Exe"шнику (а не мучиться с эмуляцией
> загрузчика), а секции с кодом, данными и импортом шифровать.
> Может сами ещё что-нибудь придумаете. Вариантов масса. Конечно
> неломаемой защиты Вы не напишете, но хоть что-то будет

Да я с полностью согласен так было бы проще, но я не знаю как это сделать. Нужна помощь.

← →
RedArc (2003-09-16 15:23) [24]

Совершенно не понятно, зачем такое нужно в защите от НСД и тем более в бяках. В бяках копаются не просто хакеры, а Хакеры. По поводу "разобраться". Посмотри на сайте серию статей о сокрытии процессов в памяти. По поводу запуска других процессов там же тоже написано много чего. Если хочется скрыть _только_ от любопытных глаз, то на сайте информации достаточно. Если хочется защититься от хотя бы начинающего хакера, то сам ты вряд ли чего сможешь сделать, чтобы даже начинающий хакер потратил больше 10 минут своего внимания на взлом.

В любом случае предлагаю тебе более элегантное решение. Склеиваешь два EXE-файла. Первый - (З)ащита, второй - защищаемая (П)рограмма. При старте З проверяет наличие собственной копии в памяти.
- Если таковой нет, то инсталлирует себя в систему как сервис, чтобы быть невидимой и загружаться всегда при старте Windows. После этого перезагружает Windows
- Если таковая есть, то просто "откусываем" П от себя, пишем во временный файл и оттуда обычным образом через CreateProcess стартуем. По окончании работы П временный файл убиваем.

При запуске З в качестве сервиса она оказывавется в памяти и просто висит ничего не делая. После запуска П периодически производит (О)бращение к процессу З в памяти. Если обращение к З неудачное или получен неправильный результат - завершаем работу процесса П.

При инсталляции З в качестве процесса можно получить (Д)анные о БИОС и какую-нибудь уникальную (И)нформацию о системе. Всё это можно впихнуть в секцию данных в самой З или разбросать по системным каталогам Windows в виде маленьких файликов. Эта информация поможет защитить З от несанкционированного копирования на другие компьютеры. При старте З в качестве сервиса просто проверяй соответствие сохранённых Д и И к актуальным Д и И. И если соответствия нет, то что-нибудь предпринимай, например, перезагружай Windows :)

В качестве О можно просто перенести часть процедур и (Ф)ункций, не обращающихся к глобальным переменным, из П в З. Тогда в качестве О можно просто каждый раз передавать в З имя процедуры или Ф, формальные параметры для этой процедуры или Ф и возвращать результат выполнения процедуры или Ф от З в П. В качестве идентификатора правильности выполнения процедуры или Ф можно дополнительно передавать определённое значение в какой-нибудь дополнительной переменной, а в П проверять это значение на истину. Для каждой процедуры или Ф это значение можно сделать уникальным или зависимым от какого-нибудь входного параметра.

Обмениваться данными между П и З можно через память или посредством Memory Mapped File.

В любом случае при большой необходимости любая защита будет сломана. Но даже фиговая защита лучше, чем её отсутствие. Главное здесь, это выбрать метод создания более стойкой защиты, требующий наименьшего вложения труда и знаний при разработке. Тогда затраты на модификацию такой защиты для каждой новой продаваемой версии П будут ничтожны по сравнению с затратами на взлом.

Если хочешь пообщаться на тему самопальных защит - пиши. Удачи!

← →
NightAngel (2003-09-16 20:39) [25]

> Digitman

> а то что к GDT/IDT "пустили" - ну, наверно, это чем-то обосновано было

По моему, ничем, кроме глупости, это не было обосновано, т.к. тот-же spider доступ к GDT/IDT закрывает (тут и нужно всего-лишь запретить доступ из Ring3 - один бит U/S - к страницам где расположены таблицы), без последствий для системы (естественно, ведь сама система в Ring0). А чем обосновать лёгкий доступ к каталогу и таблицам страниц? А в NT системах обработчик int 2Eh не меняя селекторы ES и DS копирует параметры в новый стек командой movsb (ds:[esi]->es:[edi]), без всяких проверок, хотя в самом ядре этих проверок куча? И таких примеров масса. А обосновано это, по моему тем, что нужно как можно больше ошибок "напихать" в очередную версию OS, чтобы она не дай бог последней не оказалась. Ну ладно, что-то занесло меня... :)

> т.е., имея некий лин.адрес блока памяти со считанным из ресурса PE-образом в ВАП тек.процесса, выполнить на его основе полноценную загрузку (с последующим стартом)

Ну хорошо. Делаем так (как это делает загрузчик): Выделяем память, для ВСЕГО модуля (который расположен в ресурсах запущенного Exe"шника) в ВАП текущего запущенного процесса, выравнивая Image Base на границу 64 Кб (10000h). Загрузчик в память грузит все заголовки, таблицу секций, секции в порядке перечисления в таблице, не грузится только оверлей (если он есть, обычно присутствует в последней секции, но теоретически может находиться и в другой), учтём это в дальнейшем. Извлекаем из ресурсов exe"шник (можно частями) и начинаем размещать его заголовки, таблицу секций, секции etc, с Image Base выделенной памяти. Т.к. Exe и Dll файлы на диске, не соответствуют своему образу в памяти, то поступаем так-же, как и загрузчик - размещая извлечённый exe"шник, выравниваем все заголовки и секции на размер страницы. Если загрузчику не удаётся загрузить модуль (неважно Exe или Dll) по указанному Image Base, то он использует секции .reloc или .fixup для того, чтобы перенастроить все VA адреса в программе. Естественно Image Base - Exe который мы хотим запустить не соответствует значению указанному в заголовке, значит, перенастраиваем все VA адреса. Далее, загружаем ВСЕ используемые библиотеки и настраиваем таблицу импортов. Затем проходим по списку функций TLSCallBack (если есть). Устанавливаем атрибуты страниц (заголовков и секций) в соответствие с их характеристиками в таблице секций. Инициализируем все регистры общего назначения и передаём управление программе по Entry point RVA. Проблемы возникнут, только если в запущенном Exe"шнике встретится ExitProcess(), GetModuleHandle(0) и т.п., но и это решить не сложно. Всех тонкостей и нюансов я раскрывать не буду (в частности, решение проблемы с оверлеем, Exe файлы могут вообще не содержать ни одной секции и всё равно они будут работать и т.д.). Теперь по поводу DLL - если библиотеку загрузить таким-же способом то от других DLL она будет отличаться только тем, что для неё не будет работать GetProcAddress(), FreeLibrary(), и некоторые другие вызовы, что в общем-то и несущественно. НО, модули загруженные и запущенные таким способом, ЗАРЕГИСТРИРОВАНЫ В СИСТЕМЕ НЕ БУДУТ (при желании можно и это реализовать, хотя платформа NT и удовлетворяет классу защиты C2 - в мечтах), чего, насколько я понял, автор вопроса и добивался. Вот тут я с Вами абсолютно согласен, что - "для вполне доброй темы наверняка найдутся и рекомендации по решению проблемы любыми иными способами". А на вопрос - "почему Вы сделали вывод, что это невозможно осуществить?" - Вы мне так и не ответили. :) Опять-же ничего личного, просто интересно с умным человеком пообщаться.

← →
OlegK (2003-09-17 07:43) [26]

2 Tetros
Вот эта статья Тебе может пригодиться:
http://www.programme.ru/archive/2001/3/032001_3.phtml

← →
Digitman (2003-09-17 10:45) [27]

> NightAngel

> почему Вы сделали вывод, что это невозможно осуществить

да почему ж нельзя ? именно так - можно) ... механизм, приведенный тобой, мне хорошо понятен ... НО ! опять же, все это реализуется в контексте тек.процесса... а говоря "невозможно" я имел ввиду именно старт отдельного процесса

ЕХЕ в памяти! Найти похожие ветки