Run exe from memory (x64)

Вот тут об этом вроде бы хорошо написано (англ)
http://msdn.microsoft.com/en-u... 00794.aspx

разбираться с этим https://sites.google.com/site/... 4bytestest
или переписать приложение под dll (при вызове dllmain она сама загрузиться в память).

он же на delphi, насколько я понял, перевести его в с++ не получится.

Проблема в том, что при загрузке dll из памяти необходимо загрузить их в уже имеющийся процесс, а в случае с exe - процесс необходимо создать.

Есть необходимость запускать exe из памяти, а не с диска.
Может кто сталкивался с данным проектом?

что есть такого в delphi чего нет в c++? Перевести можно спокойно. Другое дело переводить с delphi на, например, c# или java.


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

Сталкивался. Но то было давно, в эпоху Win2K/WinXP.
На современных Виндах запуск exe - очень сложный и многоэтапный
процесс, полноценно сэмулировать его вряд ли получится.
Проще скинуть exe на диск, а затем оттуда уже запускать.

Нет, совсем не проще, как было описано ранее, цель проекта - реализовать криптование приложения.

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

Кстати, запуск процесса из памяти все равно не спасет от снятия дампа,
так что криптование как защита - идея не самая лучшая.

It's actually quite easy. Similar technique has been described in a paper I read like 3 years ago.

Windows allow you to call the CreateProcess function with CREATE_SUSPENDED flag, that tells the API to keep the process suspended until the ResumeThread function is called.

This gives us time to grab the suspended thread's context using GetThreadContext function, then the EBX register will hold a pointer to the PBE(Process Enviroment Block) structure, which we need to determine the base address.

From the layout of the PBE structure we can see that the ImageBaseAddress is stored at the 8th byte, therefore [EBX+8] will give us actual base address of the process being suspended.

Now we need the in-memory EXE and do appropiate alignment if the alignment of memory and in-memory EXE differs.

If the base address of suspended process and in-memory exe matches, plus if the imageSize of the in-memory exe is lesser or equal to the suspended process' we can simply use WriteProcessMemory to write in-memory exe into the memory space of the suspended process.

But if the aforementioned conditions weren't met, we need a little more magic. First, we need to unmap the original image using ZwUnmapViewOfSection, and then allocate enough memory using VirtualAllocEx within the memory space of the suspended process. Now we need to write the in-memory exe into the memory space of the suspended process using the WriteProcessMemory function.

Next, patch the BaseAddress of the in-memory exe into the PEB->ImageBaseAddress of the suspended process.

EAX register of the thread context holds EntryPoint address, which we need to rewrite with the EntryPoint address of the in-memory exe. Now we need to save the altered thread context using the SetThreadContext function.

Voila! We're ready to call the ResumeThread function on the suspended process to execute it!

This is a major hack, and you should really avoid doing it. If you want to start a new process then the only guaranteed way to make it work without issue is to launch an executable that resides in the filesystem. Anything else is a hack and you can't rely on it working in the future.

Нет, инжектировать dll в другой проект нельзя, так как это должно быть именно приложение, сейчас объясню поподробнее. Мне необходимо реализовать криптование exe, для этого, я беру исходной приложение и оборачиваю его специальным образом и на выходе получаю новое приложение. Это приложение запускается с диска, декриптует исходное приложения, которое зашито внутри нового приложения, делая при этом необходимые проверки и запускает исходное приложение из памяти. При этом исходное приложение может быть любым, но это должно быть именно приложение.

Нет это не вариант. Большая часть приложения реализована, не хватает только этого проекта. Что касается VmProtect, то это не подходит из-за нашего типа защиты. Мы используем HASP и проверки при декриптование связанные с ним необходимы

Кстати, запуск процесса из памяти все равно не спасет от снятия дампа,
так что криптование как защита - идея не самая лучшая.

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

Т.е. по сути ты пытаешься прицепить защиту к стороннему приложению? Если приложение свое, то непонятно, зачем такая система наворочена.