FileLoad without FileInstall on disk

[martin]

look this article about embedding files as resources in a delphi code

Thanks for the link but I don't see anything there to tell you how to load an exe resource into memory and run it from there.

[Zedna]

Hello Zedna,

thanks for your reply. But I have a different idea in mind.

What I want is to have a single source AU3 file containing ALL needed resources.

I.e. used icons were previously encoded (base64) to ascii strings. That constant resource-strings are stored as AU3 source (may also be included). The strings can be compiled. At runtime, when the icon-resource is needed, the string is decoded into memory (icon image). And the remaining thing is to initialise the Gui-Control with that memory instead of icon-file.

If this would work then a compiled AU3 program contains all needed data.

With my techniquie of adding icons to resources you can add every type of resources you want, for example TXT or binary data of resource type RCDATA instead of resource type ICON. But You must then use some API functions for loading such general type of resource data at runtime. In Delphi it's done by ResourceStream:

var List: TStringList;

    ResStream := TResourceStream.Create(HInstance,'NAME_01',RT_RCDATA);
    List.LoadFromStream(ResStream);
    ResStream.Free;

RC file:

NAME_01 RCDATA FILE.TXT

[Zedna]

look this article about embedding files as resources in a delphi code

Thanks for that link. Very good article about resources and using them!

[Richard Robertson]

You cannot execute an executable file from memory. Windows won't do it. Even delphi must write an executable somewhere before Windows can start a process from it. If the program is interpreted, that is a different matter. They can be interpreted by the first executable from memory, but then, they aren't really programs but still just code.

[DarthVega]

You cannot execute an executable file from memory. Windows won't do it. Even delphi must write an executable somewhere before Windows can start a process from it. If the program is interpreted, that is a different matter. They can be interpreted by the first executable from memory, but then, they aren't really programs but still just code.

Haven't you ever heard of "memory resident" ?

[/dev/null]

Haven't you ever heard of "memory resident" ?

do you know what that means?

Thanks

Kurt

[DarthVega]

do you know what that means?

Thanks

Kurt

Actually, I don't. I'm so stupid that I can't see the blatantly obvious definition within the phrase itself....

Thanks for the quick drive by attempt, dev null....

[herewasplato]

@DarthVega,

"memory resident" has nothing to do with executing "an executable file from memory".

It is a label/marking/designation for programs that should stay in RAM and not be sent to the swap file. It has nothing to do with defining how (or from where) the program started.

Edited January 6, 2007 by herewasplato

[herewasplato]

If I understand correctly...

If I understand correctly... The OP wants one AutoIt script that has another EXE in it. Then, without using AutoIt's FileInstall, the OP wants the one AutoIt script to write the EXE directly to RAM (never touching the hard drive).

Mr Icekirby has mentioned that Windows will not allow an EXE to start from RAM.

[DarthVega]

@DarthVega,

"memory resident" has nothing to do with executing "an executable file from memory".

It is a label/marking/designation for programs that should stay in RAM and not be sent to the swap file. It has nothing to do with defining how (or from where) the program started.

There are these things called worms... ok? They don't need to be run from the hard drive AT ALL. They can be run from a host program (that is on the harddrive) but the worm itself never even has to venture onto the harddisk. So yes, you can have code that is memory resident. I'm not saying that will work in mary's situation... she wants a memory resident program that starts from within another program. This would be rather complicated and IMO, unnecessary. I was merely correcting this guy:

You cannot execute an executable file from memory. Windows won't do it.

Look up the Slammer worm, Mr. Kirby. Code can be executed from memory. Just because it doesn't have an ICON on some nifty little DESKTOP GUI doesn't mean it's not a program!

[Valik]

By your foolish definition, DLLs are programs, then. In fact, basically any function that does something is a program. Maybe it doesn't even need to do anything to qualify as a program. You're making a very broad generalization of what a "program" is. Executing arbitrary code, written directly to memory or not, is not the same thing as executing a program directly from memory. It approaches impossible to launch a program in it's own address space from memory alone. It's possible, not practical - or trivial, to launch an executable in the current address space. Tricks like buffer overflows or just plain writing instructions directly to memory are irrelevant to this conversation, however. The OP wants to launch a program directly from memory in it's own address space. Being asinine and pointing out things by assuming vague definitions of terminology is just pointless.

Now, let's point out - again - your incorrect use of "memory resident". That term does not mean "resides only in memory". It means "always in memory". The kernel of your operating system is a good candidate for something that is "memory resident". That means it's never swapped out to disk to free RAM. It does not mean the kernel only exists in memory as your definition would demand.

The lesson I think you need to learn from this is two-fold. First, when you use terminology, use it right. Don't attach improper definitions or use the most vague interpretation you can to try to prove a point you can't make. Second, don't play with the big boys until you know what the hell you are talking about. You might be able to get away with the half-baked jargon on some idiot-hole forum where nobody knows any better - we know better. Not all of us are idiots and we don't get lost so easily with your improper fancy-speak.

[The Kandie Man]

...I just don't think that executing an executable from memory is possible. It just has to be run from the disk, AFAIK, unless Valik or someone else wants to come in here and tell me that it can be done.

You cannot execute an executable file from memory. Windows won't do it. Even delphi must write an executable somewhere before Windows can start a process from it. If the program is interpreted, that is a different matter. They can be interpreted by the first executable from memory, but then, they aren't really programs but still just code.

... It approaches impossible to launch a program in it's own address space from memory alone. It's possible, not practical - or trivial, to launch an executable in the current address space...

There, this thread is now complete. Valik says it really can't be done(not practically), therefore, it can't be done.

Each program is responsible for its own memory allocation and the Operating System assists the program in doing this. You can't have another program allocate memory for an executable and then run it in memory. In addition, when a program is started it usually has to load a bunch of system libraries since it relies on the OS to run correctly. When the program starts up it does this and the OS assists. I have never seen a program on a Windows OS ever run from memory and therefore it really just isn't practical. In addition the OS would probably not know what to do when something like this is attempted and I would guess it would probably not have a fun response.

True, resources like .bmp, .jpg, .wav, .mp3, and other media/resource/data files can be loaded into memory and used, but these are not executable files. Executable files are files that carry machine instructions and can only be read by the machine. These other files don't contain machine instructions, only data that can be read and interpreted by the programs themselves.

Feel free to correct me if anything i said was wrong, but it would appear at this time that running executables directly from memory isn't feasible. It doesn't matter what language you use, it is a limitation in the way the OS and hardware currently work.

Sorry,

The Kandie Man

[herewasplato]

There are these things called worms... ok? They don't need to be run from the hard drive AT ALL...

My understanding of the term "memory resident" comes from many years of reading various publications. This webopedia "lay" definition: http://www.webopedia.com/TERM/M/memory_resident.html is what I was getting at when I was saying that you were miss using the term. I'm not qualified to speak on the feasibility/practicality of running a installation EXE only from RAM. However, your reference to the Slammer worm did lead me to a MS doc that used to term "memory resident" much like you have: http://www.microsoft.com/technet/security/...ts/slammer.mspx I think that MS has used a really poor choice of words here since these two words - when used in that order - have been reserved to refer to a label assigned to a program. A label that prevents the program from being sent to the swap file.

I'm not conceding that you (or MS) used the term properly, I'm just apologizing for being so dogmatic before.

[bearcav]

Seeing stuff that is going on in the software world it seems reasonably possible to extract and use a data file and then recombine with the changes.

Since AutoIT exe's are built like they are it seems like it is all the more possible, and further encryption schemes could be used to protect vital information.

Start -enter password

use password to decrypt resource

if successful continue

load values and run main program

Save -> encrypts a copy of the data and replaces the old encrypted file

Shutdown checks for anything else that needs to be saved and

exit

If userland is secure and password is secure then data is pretty decently secure.

Just a thought as it helps to have a destination in mind when your start your trip...

[MyDream]

As you know there is FileInstall ( "source", "dest" [, flag] ) function to include a file in autoit compiled script. but is there a way to load this file directly without copying it on disk ?

some think like FileLoad("source")

thinks a lot for any help

Interesting, sorry if I have to bring this thread back up.

One way of doing it if possible is by making a ramdisk and running your exe file from the ramdisk.

Ramdisk is consider as physical memory right?

[Richard Robertson]

Don't even bother. I don't know why you are digging this up, but it's been established that it just wasn't a good idea.

[anzacfalcon]

Ok, what mary is looking for is the holy grail of malware coders. A little piece of code called RunPE. Research it if you like. There is only one person that has ported this module from VB6 (Visual Basic 6) to AutoIt. I dont think giving he's name would be a good idea right now but what you want can be used for both reasons of good and bad. Only "Him" and a few close friends including me have this au3 file. So yes, running a executable from memory is completely possible and has been done.

Edited January 5, 2010 by anzacfalcon

[GEOSoft]

Note: Ive just realized that this thread has 2,424 Views. There is a reason behind that.

Sure there is, you just brought up a thread with a last post that's a year and a half old. Lots of people read a thread in that time period and it didn't need locking before and probably doesn't now.

[anzacfalcon]

Sure there is, you just brought up a thread with a last post that's a year and a half old. Lots of people read a thread in that time period and it didn't need locking before and probably doesn't now.

Oh sorry about that

[Zedna]

There is a solution for executing EXE directly from memory but it's not simple.

Look at "Run binary (executing from memory)" example from trancexx

#713513

EDIT: Just to be complete, there is also solution for calling DLL functions from memrory

Embed DLLs in script and call functions from memory - Pure AutoIt script (Now worked under Vista) from Ward

http://www.autoitscript.com/forum/index....0708&hl=memory&fromsearch=1&#entry560708

Edited January 6, 2010 by Zedna