Sign in to follow this  
Followers 0
x42x4b

FileInstall to memory (without creating file)

13 posts in this topic

Hello All,

This is my first post. I was searching for a while, but I didn't find answer for my question.

And the question is:

Is there any possibilty to drop something from .exe script without creating a file?

I need to protect my process from evil people who wants to crack my prog.

some art ;-)

+-----------------+

| initial program |

+-----------------+

|

/ \

| ? | - check env and search for debbugers, procdumps. ?: clear? If NO - Exit.

\ /

|

| Yes, clear.

|

L +--------------------------+

| extract main program |

+-------------------------+

|

+-------+

| run it |

+-------+

|

+------+

| exit |

+------+

There is not details, beacuse I'd like to make it clear.

As you can see, the main program executes as initial prog. There is no new PID, main program is "invisible" - no new process.

Anyone has a solution?

I'm too weak to solve it by myself. Please, help, hilfe, hajuto, SOS :-).

Regards!


1. RTFM | /dev/LOL2. RTFS | /dev/OMG3. FGI | /dev/WTF4. /dev/BBQ :)

Share this post


Link to post
Share on other sites



well, i have something like this:

$jupi = _TempFile()
FileInstall("jupi.lol", $jupi)

FileSetAttrib($jupi, "+RASHO")
Run($jupi, "", @SW_HIDE, $STDIN_CHILD + $STDOUT_CHILD + $STDERR_CHILD)
FileDelete($jupi)

Copying jupi.lol is unavailable, because is gone :P .

In process explorer is shown path, but you can't find, copy, edit file... It's marked "delete as soon it is possible" :-) .

I found topic about source for FileInstall. Maybe, I'll find there answer.

PS: talking to myself, but maybe this code will be helpful for someone.

Regards.


1. RTFM | /dev/LOL2. RTFS | /dev/OMG3. FGI | /dev/WTF4. /dev/BBQ :)

Share this post


Link to post
Share on other sites

There may be a certain offset in an AutoIt binary where data can be inserted with FileRead and FileWrite. Have the autoit binary read itself and write itself. Then you can just fileread from that offset. Tricky... but possible... I have done it. Takes a bit of experimentation. Start looking for an offset at the end of the binary and work backwards...

Lar.

Thanks. Did you mean "inserting" file between offsets in AutoIt binary, which is executed as same process as AutoIt binary?

\x42\x4b


1. RTFM | /dev/LOL2. RTFS | /dev/OMG3. FGI | /dev/WTF4. /dev/BBQ :)

Share this post


Link to post
Share on other sites

Will this useful program also be invisible to anti-badware programs?

Share this post


Link to post
Share on other sites

well, i never tried it, but you could install the exe on @TempDir, open it, and delete it after opening

its just an idea


Never judge my awesome brazilian-english language :D:D<-- lol ;P

Share this post


Link to post
Share on other sites

Will this useful program also be invisible to anti-badware programs?

don't know, didn't try :-)

well, i never tried it, but you could install the exe on @TempDir, open it, and delete it after opening

won't work, after execute it, file is locked by system.


1. RTFM | /dev/LOL2. RTFS | /dev/OMG3. FGI | /dev/WTF4. /dev/BBQ :)

Share this post


Link to post
Share on other sites

won't work, after execute it, file is locked by system.

If it's a script file, you could FileInstall(Au3.au3)... /AutoIt3ExecuteScript... ProcessWait... FileDelete(Au3.au3) (this does work).

But I'd be intrested personally to see Larry's idea made into a working option... that sounds like alot of my own personal headaches could be solved.


[center]Common sense plays a role in the basics of understanding AutoIt... If you're lacking in that, do us all a favor, and step away from the computer.[/center]

Share this post


Link to post
Share on other sites

There may be a certain offset in an AutoIt binary where data can be inserted with FileRead and FileWrite. Have the autoit binary read itself and write itself. Then you can just fileread from that offset. Tricky... but possible... I have done it. Takes a bit of experimentation. Start looking for an offset at the end of the binary and work backwards...

Lar.

Well, I found this place :-)... it took me 10min :-), but now, I wonder how to use it...

something like Run($array) where $array contains file. Or maybe just little ASM to exec included file :-).

No less, no more... thanks Larry for idea :-). It was so simple... as usually simple solutions are the best :-).

Regards.


1. RTFM | /dev/LOL2. RTFS | /dev/OMG3. FGI | /dev/WTF4. /dev/BBQ :)

Share this post


Link to post
Share on other sites

#9 ·  Posted (edited)

Share this post


Link to post
Share on other sites

It will if you rename it first. Then delete the renamed file.

Edit, maybe not.. I'm sure I did this somehow

On WinXP it's impossible :-)...

You can rename it and put it into other directory... but delete it?! no...

I tried many times...


1. RTFM | /dev/LOL2. RTFS | /dev/OMG3. FGI | /dev/WTF4. /dev/BBQ :)

Share this post


Link to post
Share on other sites

#11 ·  Posted (edited)

Well, I found this place :-)... it took me 10min :-), but now, I wonder how to use it...

something like Run($array) where $array contains file. Or maybe just little ASM to exec included file :-).

No less, no more... thanks Larry for idea :-). It was so simple... as usually simple solutions are the best :-).

Regards.

If I understand you correctly, you have an executable file loaded into the same address space of an AutoIt script and want to transfer control to that executable. If that's the case, it's not that simple. I've executed a simple program in place in memory through some trickery (not with AutoIt) and the results are not pleasant. Simply having an executable loaded into memory is not the same as loading an executable into memory for execution. There are a number of steps performed when loading and preparing an executable to be run. For example, my sample application just displayed a message box with a simple string. When I would execute the application directly in memory, the wrong string was displayed. I assume this is because the application was not loaded at the base address it expected and no loader performed automatic rebasing. Second, and more importantly, while it's true that you can transfer control to the entry point of the executable loaded, once a call to exit() is made or the program runs off the end of WinMain() or main(), the entire application ends - "parent" and all.

If you want to safely - and properly - run an executable file, it has to be invoked through Windows so that it gets its own address space. That means it has to be on disk. Either that, or you have to write your own loader so that you adjust the addresses to work within another processes address space. You'll also have to hijack the exit() function and all variants to make sure the process isn't closed when the "child" closes.

It's a very complicated thing to do.

Edit: Corrected typo(s).

Edited by Valik

Share this post


Link to post
Share on other sites

What exactly are you trying to achieve?

Share this post


Link to post
Share on other sites

What exactly are you trying to achieve?

well, i thought... maybe there is a magic thing which will unable dumping process...

In procdump tool u will see only memory for "loader" (that thing which starts main program).

If i didn't make myself clear, forgive me... Sometimes i just have a problem with output on my thoughts :-) like a (bin * str) / true = wtf is that? :-), but i really know what i want (thx god :-) )


1. RTFM | /dev/LOL2. RTFS | /dev/OMG3. FGI | /dev/WTF4. /dev/BBQ :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0