resID.l=1 ;-> number of resource
hResInfo=FindResource_(#NULL,resID,#RT_RCDATA)
If(hResInfo)
hData=LoadResource_(#NULL,hResInfo)
If(hData)
lpData=LockResource_(hData)
If(lpData)
AllocateMemory(1,8000,0) ;-> your needed size
lg=UnpackMemory(lpData,UseMemory(1))
;...
;...
EndIf
EndIf
EndIf
;======================================
;To compile (by Microsoft's RC) the RES file, I use this source:
1 RCDATA
BEGIN
#include "secondApp.exe"
End
I saw some weird things done in VB which I could not understand.
The idea to allow a program to run after lodinng into memopry was to first load a fake program and run it. This fake could be just nulls and also has to be the exact size of the exe which it is desired to run. This fake program is then overwritten by the desired program from memory, and it is claimed the new program will run.
I have seen a post here which alters a running program and could do this.
Maybe it gives a few ideas but seems too simple to be true.
Hi!
I know, i know, a bit old, but i was just reading posts from PB forums and saw this.
Well it got my attention. Can anyone tell me if this is possible(load an exe in memory and run it)? I don't know, but i've heard of GetProcAddress, can i use it run and exe loaded in memory?
Just curiosity, if somebody knows i would like to hear some explanation by some kind.
Thanks
> The idea to allow a program to run after lodinng into memopry was to first
> load a fake program and run it. This fake could be just nulls and also has
> to be the exact size of the exe which it is desired to run. This fake program
> is then overwritten by the desired program from memory, and it is claimed
> the new program will run
Sounds like a hoax to me. How can you run something made up of nulls?
Also, even if possible, this is still not running it from memory because you'd
have to save it to disk first to run it, otherwise you'd just run the null app
from memory in the first place, so why not just run the exe that way instead?
I compile using 5.31 (x86) on Win 7 Ultimate (64-bit).
"PureBasic won't be object oriented, period" - Fred.
Oh...
I've read the recent post about /Resource parameter to the compiler and saw memory advantages instead of includebinary. So just thought this could happen the same way.
Thanks for answering
that is POC of how to load exe to directly to memory from another exe where its inside... |:
but im more interested about how to "inject" complete exe or just portions of its code into another process... |: there was example how to inject dll to another process but thats not what im looking for...
I've seen this request many times both here and in VB/C forums, and I've
yet to see a workable solution. Personally, I don't believe it can be done.
(There's a lot of "try this, do that" but NEVER an example source that one
can test for themself and get an immediate result).
I compile using 5.31 (x86) on Win 7 Ultimate (64-bit).
"PureBasic won't be object oriented, period" - Fred.
Hi!
I think in same way PB is right, but correct me if i am wrong. But isn't this the way that packers like UPX and others act?. They embedd the application we want in a stub/loader that decompresses the data(our exe, dll) in memory and run it?
The only way to run an exe inside of memory is to create a PE header emulator. You then have to manipulate the PE header to make it think its comming from the HDD but really its a reference to a memory location... not easy stuff
> isn't this the way that packers like UPX and others act?. They embedd the
> application we want in a stub/loader that decompresses the data(our exe,
> dll) in memory and run it?
Interesting theory, so I tested it -- and no, UPX decompresses the exe to the
Windows Temp folder before running it. I used FileMon to watch for what files
were created in Temp when I launched my app that was compressed with
UPX, and it showed a file with the same byte-size as my uncompressed app
being created there. I then decompressed the app and launched it again,
and nothing was seen in Temp this time. So, it doesn't run it from memory.
I compile using 5.31 (x86) on Win 7 Ultimate (64-bit).
"PureBasic won't be object oriented, period" - Fred.