Executing memory
Author
Hi,
I''m just writing an in-game decompression library. Some DLLs will be in a .zip-file and I''m wondering whether I need to decompress them on the harddisk first or if it is possible to extract them direct into memory and execute them.
I already did some searches but I didn''t find anything.
Thanks for your help.
BlackHC
I do know that I don''t know anything.
On Windows, if the exe is statically linked with those dlls, then they will need to be unpacked to disk before the exe can be executed. If the exe dynamically links with those dlls, then the OS needs to access those dlls on disk in order to load them into the address space of the process via LoadLibrary.
But, if you really want to dig into things just the same, perhaps you might find SoftWire helpful. Or perhaps FuBi.
But, if you really want to dig into things just the same, perhaps you might find SoftWire helpful. Or perhaps FuBi.
That''s doable, but entails writing your own PE loader (you''d have to do everything LoadLibrary does). Probably overkill.
You could instead pack them with UPX, at the cost of a 1.5 KB decompressor stub, and possibly lower compression ratios.
You could instead pack them with UPX, at the cost of a 1.5 KB decompressor stub, and possibly lower compression ratios.
Why all this talk about UPX? Why on earth would anyone want to use it (and similar programs) to make programs and libraries smaller??
Disk space is cheap, man. RAM is more expensive. Packed executables will use 15% or so more RAM thah the same executable unpacked.
Disk space is cheap, man. RAM is more expensive. Packed executables will use 15% or so more RAM thah the same executable unpacked.
i agree. disk space costs CONSIDERABLY less than memory. your user also will probably have more diskspace than RAM anyway... (that''s just an educated guess 
)
)
UPX and similar executable packers are good for download-and-run-once programs like installers and demos but shouldn''t be used for everything - and certainly not for DLLs with code that could otherwise be shared. While I have still to measure the memory overhead for real programs, I suspect it could be considerably larger than 15% in many cases.
Also, filesystem-level compression is an option for many users with concerns about on-disk executable size.
Also, filesystem-level compression is an option for many users with concerns about on-disk executable size.
> Why all this talk about UPX? Why on earth would anyone want to use it (and similar programs) to make programs and libraries smaller?? <
Quicker download.
> Disk space is cheap, man. RAM is more expensive. Packed executables will use 15% or so more RAM thah the same executable unpacked. <
True. However, increased mem usage on the order of 15 kb is laughable.
Agreed. I don''t know what these DLLs are for, nor how big they are.
> Also, filesystem-level compression is an option for many users with concerns about on-disk executable size. <
Yes. Again, though, I don''t think that''s a problem
Quicker download.
> Disk space is cheap, man. RAM is more expensive. Packed executables will use 15% or so more RAM thah the same executable unpacked. <
True. However, increased mem usage on the order of 15 kb is laughable.
quote:UPX and similar executable packers are good for download-and-run-once programs like installers and demos but shouldn''t be used for everything - and certainly not for DLLs with code that could otherwise be shared.
Agreed. I don''t know what these DLLs are for, nor how big they are.
> Also, filesystem-level compression is an option for many users with concerns about on-disk executable size. <
Yes. Again, though, I don''t think that''s a problem
I think the idea is to treat code and data in a similar way. While it's a nice idea, it's impossible to implement in a practical way with native win32 API. It would certainly be nice if LoadLibrary could take a pointer to a buffer filled with code, but we're not given that option .
If you look into .NET such a feat is not only possible, but can be used in practical ways in real world situations.
[edited by - CoffeeMug on March 26, 2003 1:37:56 AM]
.If you look into .NET such a feat is not only possible, but can be used in practical ways in real world situations.
[edited by - CoffeeMug on March 26, 2003 1:37:56 AM]
all you need to do to "execute memory" is to make instruction pointer point at the beginning of that memory block, after making sure that appropriate pages have execute access right. you can allocate a piece of memory from the heap and execute it; in fact, that''s how ATL implements HWND to CWindow mapping.
if you already have the code in memory, there''s no point in "loading" it anywhere, you can simply execute it from wherever it is (again, assuming you have the permissions).
quote:Original post by CoffeeMug
It would certainly be nice if LoadLibrary could take a pointer to a buffer filled with code, but we''re not given that option
if you already have the code in memory, there''s no point in "loading" it anywhere, you can simply execute it from wherever it is (again, assuming you have the permissions).
niyaw: it''s not that simple. You can load files with .com extention like that and execute them. I actually did that when I was experimenting with buffer overflows But loading a dll involves a bit more then that. For instance, modifying the the jumps in the code to account for the shift of the base address where the dll is loaded.
But loading a dll involves a bit more then that. For instance, modifying the the jumps in the code to account for the shift of the base address where the dll is loaded.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
