Run DLL From memory

[Centauri Soldier]

I seem to recall someone (I think MicroByte) saying that a dll could be read as binary and stored in and run from memory. I've been searching the forums for about a half-hour with no luck finding the post (not that it has the "how" anyway). Does anyone know how this can be done?

[Imagine Programming]

I seem to recall someone (I think MicroByte) saying that a dll could be read as binary and stored in and run from memory. I've been searching the forums for about a half-hour with no luck finding the post (not that it has the "how" anyway). Does anyone know how this can be done?

I know it's possible, but I don't know if an AMS compatible is available, if you can't find it, I'll be happy to write you one :)

[RizlaUK]

to call a dll from memory you would need a dll or plugin to make it happen in the first place so i dont really see the point in doing it, plus the target dll would need to be compiled into the calling dll so i cant really see a generic solution

it is possible to do, just not with AMS, check out the PB-OSL package, it contains a lib that calls a dll from memory and contains examples

[Imagine Programming]

to call a dll from memory you would need a dll or plugin to make it happen in the first place so i dont really see the point in doing it, plus the target dll would need to be compiled into the calling dll so i cant really see a generic solution

it is possible to do, just not with AMS, check out the PB-OSL package, it contains a lib that calls a dll from memory and contains examples

Indeed, a nice function in the PBOSL lib ^^

[Centauri Soldier]

Well then, it seems like a plugin would be the way to go. A Plugin Extension Plugin that would allow the plugin maker to place his dll in the plugin as a string and then load it into memory with the PEP at start-up without writing the included dll to the hard disk. Could that be done?

[RizlaUK]

dunno, sounds like a lot of work, and although it sounds like something i would use, as my plugins are already dll based and this dll needs to be written to disk in order to use then its a waist of time for me to unpack a dll to call another dll from memory, if im unpacking a single dll i might as well unpack several dll's

if something like this was coded in C++ then id use it for sure

[Centauri Soldier]

Perhaps I misunderstood. I though IP was saying that a plugin built in PB could facilitate loading a dll into and calling it from memory. Would that plugin require a dll to be unpacked?

[Imagine Programming]

Perhaps I misunderstood. I though IP was saying that a plugin built in PB could facilitate loading a dll into and calling it from memory. Would that plugin require a dll to be unpacked?

No, that plugin could wrap the PBOSL function, but then again you would always need that plugin to load the dll's from memory. (eg from a Base64 string, decrypted and loaded in the plugin)

Eg: You write a luaplugin, which has a dll included, but you would have to need the plugin to load the plugin from a string, you wouldn't mind?

[Centauri Soldier]

No, I would not mind at all. Having one plugin that extended the functionality of many other plugins without the need to write anything to disk would be fantastic.

We could simply create a dependency check for each dependent plugin that would ensure the presence of the PB plugin.

[Imagine Programming]

No, I would not mind at all. Having one plugin that extended the functionality of many other plugins without the need to write anything to disk would be fantastic.

We could simply create a dependency check for each dependent plugin that would ensure the presence of the PB plugin.

Okay, I will see what I can do, I'll try to prepare something tonight or tomorrow. (Having a festival tonight hehe)

You'll probably won't even have to decrypt the string before the call, but it would improve the speed quite much if you'd pass a memorypointer to the string instead of the string itself...

How would you like to call the dll exactly, open, call, close library, or simply call function and close right after?

[Centauri Soldier]

I'm not sure what the difference is amongst all those choices but I think I would prefer speed above all else (or perhaps even having the option selectable by the programmer in case he wants to favor security for one application and speed for another).

Simply calling a function would probably be easiest but since I don't know much about this procedure I think I would like to leave it to your discretion.

Enjoy your festival tonight, don't drink too much heh heh...:D.

[RizlaUK]

OPEN, CALL, CLOSE :yes:yes:yes

its a must for a dll lib, bit tricky for noobs to get the hang of, but a must in my book

and yes, a pointer would be quicker, but the overhead has to come from somewhere, at some point in the call the string will need to be 'PokeS' and here you have 3 options

1. poke it in AMS with the memory plugin
2. poke it with a function in your plugin
3. send the string and poke it withn the function call

i dont see how there would be much of a speed difference, it would make the indivdual calls quicker but the overall process would still take the same time (within a few 100's MS)

get your stopwatch out i guess, only way to tell

[Imagine Programming]

OPEN, CALL, CLOSE :yes:yes:yes

its a must for a dll lib, bit tricky for noobs to get the hang of, but a must in my book

and yes, a pointer would be quicker, but the overhead has to come from somewhere, at some point in the call the string will need to be 'PokeS' and here you have 3 options

1. poke it in AMS with the memory plugin
2. poke it with a function in your plugin
3. send the string and poke it withn the function call

i dont see how there would be much of a speed difference, it would make the indivdual calls quicker but the overall process would still take the same time (within a few 100's MS)

get your stopwatch out i guess, only way to tell

Well yes poking it in AMS would be good, just don't declare the base64 as a string variable, but poke it right away is an argument. Then give the pointer as argument to the plugin I'm gonna write, I won't even have to peek it from there, because decrypting and loading can all be done using just the pointer ^^

This way, the string will only have to be parsed by AMS once, on the moment it gets poked into the Memory plugin's pointer.

[Imagine Programming]

Last question, when do you need this? I'm still busy with the L-OOP script, I almost finished that one ^^

That festival sucked by the way, I have 2 groups of friends, group 1 hates group 2 and vice versa... I was caught in the middle lol! And the heaters broke, so it was like -6C over there... waste of time and money.

[reteset]

Hi
i am following this thread
but i could not understand what do you want to do by technique

will this add a dll to another one and then call added dll's functions from host dll
if so, this is very interesting , there will be dependencies ..?

is there a step by step explanation

i am just curious :p

[Centauri Soldier]

Sorry about your festival, IP. That sucks. Maybe let 'em fight it out next time :eek:.

I don't need it right away. It just popped in my head and I thought it would be nice to be able to include DDLs as strings in plugins and call them from memory without having to write them to the hard disk. No hurry.

I hope you're not asking me that question, reteset. I have no idea how all this fancy-cool dll coding works. :D

[Imagine Programming]

Hi
i am following this thread
but i could not understand what do you want to do by technique

will this add a dll to another one and then call added dll's functions from host dll
if so, this is very interesting , there will be dependencies ..?

is there a step by step explanation

i am just curious :p

It's basicly being able to call procs in a dll, but without having to write the dll to a file. A memorybuffer containing the data of the dll is enough, so you can include it in a project using a res file, or in PB using the DataSection.

This way, you can load the library from that buffer, and not from a file, call the functions and close the library again.

I'm going to write this as a plugin for AMS users, where they for example pass me a pointer with a base64 encoded DLL, the plugin will copy the memory, decrypt the data and load the data as library.

I have been discussing stuff on the PB forums, where stuff got clear to me, how to inject a dll into a process and how to do that without needing the file. So basicly, this method is injecting the code/library into the callers thread using winapi's memory management to write the data into the process' memorybuffer.

This could sound quite numb to everyone, because I don't exactly know how to explain this, I've been using it for ages, but the backend of this method is rather new to me. Don't worry though, I'll just use the existing functions in the plugin hehe.


Sorry about your festival, IP. That sucks. Maybe let 'em fight it out next time :eek:.

I don't need it right away. It just popped in my head and I thought it would be nice to be able to include DDLs as strings in plugins and call them from memory without having to write them to the hard disk. No hurry.

I hope you're not asking me that question, reteset. I have no idea how all this fancy-cool dll coding works. :D

Ah ok, well I'll start coding tomorrow probably, it's not a huge job.

Lol yeah, I hope next time they finished the childish behaviour and have some fun... I'm getting sick
and tired of all those kids fighting over nothing... Ah well, next time will be more fun :p