I have been playing with the old GlobalAlloc() API and it has this interesting capacity of being marked as executable memory. This is a little demo that copies code stored in the data section into dynamic memory and executes it.
About the only irritation is that I had to include the name of the MessageBox API after ExitProcess to get it into the import table.
At least you don't have to mess around with VirtualProtect to write code and modify it if you like so its probably useful somewhere.
Regards,
hutch@movsd.com
About the only irritation is that I had to include the name of the MessageBox API after ExitProcess to get it into the import table.
At least you don't have to mess around with VirtualProtect to write code and modify it if you like so its probably useful somewhere.
Regards,
hutch@movsd.com
Nice work by Hutch.
I think the running code in reserved memory can be usefull for SMC applications.
(Maybe for EXE protection)
Regards,
Vortex
I think the running code in reserved memory can be usefull for SMC applications.
(Maybe for EXE protection)
Regards,
Vortex
Vortex,
This is basically the idea of being able to write and run dynamically generated code. This example is very simple so that it can be understood easily but the idea is to be able to produce and run variations in code from the same address and to be able to modify that code on the fly to suit different situations.
About the only problem I have found so far is if the dynamically generated code calls an API that is not used elsewhere in the code, the API is not added to the import table but that is easy enough to fix.
I can see the use of this type of capacity in areas as diverse as protection systems for software and repeatable memory objects that can be duplicated to handle a large number of instances.
Regards,
hutch@movsd.com
This is basically the idea of being able to write and run dynamically generated code. This example is very simple so that it can be understood easily but the idea is to be able to produce and run variations in code from the same address and to be able to modify that code on the fly to suit different situations.
About the only problem I have found so far is if the dynamically generated code calls an API that is not used elsewhere in the code, the API is not added to the import table but that is easy enough to fix.
I can see the use of this type of capacity in areas as diverse as protection systems for software and repeatable memory objects that can be duplicated to handle a large number of instances.
Regards,
hutch@movsd.com
AFAIK PAGE_EXECUTE isn't even implemented in Windows, so you might as well execute code in some memory marked as read-only.
Another way. The same code in a file loaded as a resource. Resource loaded to global memory and executed.
Regards
Regards
it's weak "protection" in my opinion..as one can dump all that moved code directly from memory, or just grab it from your file (you will have to store the code section somehow encrypted or not)
DZA,
Used IN rather than used AS is the appropriate distinction. By itself, it is no big deal to find in a debugger but that is hardly a protection system.
The theory is that any of them can be broken but some seem to take a lot longer than others. Also there is no formula for protection systems and the ones that work OK are as diverse as the people who write them.
Everybody has their pet theory on protection systems, me included but there is no point ever publishing them as they become ritual to break. Idiosyncracy is what they have going for them if they are done right and if they are eventually broken, it will probably be too late to be of any use to those who break them.
Regards,
hutch@movsd.com
Used IN rather than used AS is the appropriate distinction. By itself, it is no big deal to find in a debugger but that is hardly a protection system.
The theory is that any of them can be broken but some seem to take a lot longer than others. Also there is no formula for protection systems and the ones that work OK are as diverse as the people who write them.
Everybody has their pet theory on protection systems, me included but there is no point ever publishing them as they become ritual to break. Idiosyncracy is what they have going for them if they are done right and if they are eventually broken, it will probably be too late to be of any use to those who break them.
Regards,
hutch@movsd.com
Hi
My intention was not a protection project. I kept hold of Hutch's "playing with". I have playing further and excluded the name of the MessageBox API after ExitProcess.
Regards
My intention was not a protection project. I kept hold of Hutch's "playing with". I have playing further and excluded the name of the MessageBox API after ExitProcess.
Regards
minor,
I can get it to build but it always GP faults on my win95. I tried setting both the .rsrc and .text section as WRE but it still crashes.
This is the code I built it with,
It looks like an interesting idea, perhaps I did not translate the make file properly.
Regards,
hutch@movsd.com
I can get it to build but it always GP faults on my win95. I tried setting both the .rsrc and .text section as WRE but it still crashes.
This is the code I built it with,
@echo off
\masm32\bin\rc /v rsrc.rc
\masm32\bin\ml.exe /c /coff /Cp dynamic.asm
\masm32\bin\link.exe /SUBSYSTEM:WINDOWS /section:.rsrc,RWE dynamic.obj rsrc.obj
It looks like an interesting idea, perhaps I did not translate the make file properly.
Regards,
hutch@movsd.com
I use RadAsm as editor and create a project. I don't have to bother about how the project is built. But this options works.
regards
@echo off
if exist dynamic.obj del dynamic.obj
if exist dynamic.exe del dynamic.exe
if exist dynamic.res del dynamic.res
\masm32\bin\rc /v dynamic.rc
\masm32\bin\ml.exe /c /coff /Cp /nologo dynamic.asm
\masm32\bin\link.exe /SUBSYSTEM:WINDOWS /RELEASE /VERSION:4.0 /LIBPATH:\masm32\lib\ dynamic.obj dynamic.res
dir *.*
pause
regards
BTW. You can exclude the line "includelib \masm32\lib\user32.lib" in dynamic.asm
regards
regards
Nope,
Same result as before, it GP faults. Do me a favour and build the EXE file and post it with the source. Also I would be interested in which OS version you are running, this is tested on my internet machine running win95b and it may be different if you are running win2k or XP.
Regards,
hutch@movsd.com
Same result as before, it GP faults. Do me a favour and build the EXE file and post it with the source. Also I would be interested in which OS version you are running, this is tested on my internet machine running win95b and it may be different if you are running win2k or XP.
Regards,
hutch@movsd.com
I assumed that the kernel function addresses is static. However depending on version of the kernel32.dll the RVAs are different . I attach a new MBox.hex with a seach function. I still assume that the image base is 77 E8 00 00. I also attach the source code. I copied the hex code from offset 200 to the end and created the MBox.hex.
Regards
Regards
It's not windows that doesn't implement PAGE_EXECUTE - it's the x86 architecture.
Other architectures does support it, and windows will probably support it there.
If you only care about x86, you can use any (read/write) memory to execute code
from. And stop thinking of GlobalAlloc memory as "global" memory, there isn't
really any global memory on win32, only shared views of file mappings. If you want
to be 100% clean and stuff, you should use VirtualAlloc for dynamically building code -
but there isn't much point to this as you'll probably be building your code for x86,
and on x86 there's no PAGE_EXECUTE ^_^. For something JITty on multiple
platforms, with a code-generation backend for multiple processors, you might have
to use VirtualAlloc though.
Other architectures does support it, and windows will probably support it there.
If you only care about x86, you can use any (read/write) memory to execute code
from. And stop thinking of GlobalAlloc memory as "global" memory, there isn't
really any global memory on win32, only shared views of file mappings. If you want
to be 100% clean and stuff, you should use VirtualAlloc for dynamically building code -
but there isn't much point to this as you'll probably be building your code for x86,
and on x86 there's no PAGE_EXECUTE ^_^. For something JITty on multiple
platforms, with a code-generation backend for multiple processors, you might have
to use VirtualAlloc though.
This is my last contribution to this subject. The "InsCodeInDynamic.exe" inserts the code of "MBox" into the last section of Hutch's "Dynamic.exe" file. When executing the Dynamic.exe MBox messagebox first appears with the text
"MSBox Code is inserted into last section of Dynamic.exe PE Structure
and executed by changing the entry point of Dynamic.exe"
After pushing "OK-button" Dynaic.exe messagebox appears.
These examples are the fruits of studies of the PE structure and with help from mob's example in this thread.
Hutch. I hope my last version did work. BTW my OS is win2k. I read your thread Getting the relocation address of an EXE file as an image.. I am not sure what you mean but if it is what I think, to load an executable into memory or into another executable and start it from there instead from disk, that's what I am after.
Regards
"MSBox Code is inserted into last section of Dynamic.exe PE Structure
and executed by changing the entry point of Dynamic.exe"
After pushing "OK-button" Dynaic.exe messagebox appears.
These examples are the fruits of studies of the PE structure and with help from mob's example in this thread.
Hutch. I hope my last version did work. BTW my OS is win2k. I read your thread Getting the relocation address of an EXE file as an image.. I am not sure what you mean but if it is what I think, to load an executable into memory or into another executable and start it from there instead from disk, that's what I am after.
Regards