Jump to content
  • Advertisement
Sign in to follow this  
irreversible

sending a function address space across a network

This topic is 4435 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm not sure the name covers it, but here's what I want to do: 1) the user loads a plugin on the host machine that does some rendering 2) the application can use clients across the network to help the plugin do the rendering without actually having the plugin on disk I don't want to send the dll to the client as a file, not even temporarily. Instead I want to send the neccessary code as already loaded into memory that can then be executed at the other end and never written to disk. First off, can this be done? Safely? Getting proc addresses from the dll won't suffice for this since the functions may call any number of user defined functions also loaded from the dll, any number of built-in functions from the host application and any number of functions from the WinAPI or the standard library. In addition, the plugin might be using third party libraries that come shipped with it (one way around would be to send the third party libraries temporarily as files - that's acceptable). I'm thinking that the only way to do this is to load the entire plugin into memory and send it to the client application, which can then load it into local memory space (a possibly sneaky "how?"). Furthermore, the client then needs to call the appropriate functions from within the plugin (a straighforward "how?"). The simplest solution would be for the client to load the dll from memory, I guess (equivalent to allocating the entire file into memory and then calling LoadLibrary() on it). Can that be done? Perhaps through simulating LoadLibrary()? (I suppose that's close to impossible without having access to some Windows internal code. Right?) Most importantly, will this remove the risk of the client "leeching" the plugin? If it won't, then how can I make sure that the client gets the neccessary code to run, but can't get the actual plugin written do disk? Or maybe there's a simple solution to a problem? For once... :P

Share this post


Link to post
Share on other sites
Advertisement
What's the problem with sending the file and dealing with temporaries? A lot of cool tools that I know of have used this approach very successfully.

Share this post


Link to post
Share on other sites
Quote:
Original post by daerid
What's the problem with sending the file and dealing with temporaries? A lot of cool tools that I know of have used this approach very successfully.


You can leech the file while it's on the hard drive, even if it's there for a second. Besides, I don't think having the dll on the hard drive for a second is possible - once it's loaded, it's also locked, meaning that it can't really be deleted.

I'm talking about security and protecting the owership of the plugin, not making the solution simple :).

Share this post


Link to post
Share on other sites
It's possible to load a DLL from memory, but it's not directly supported by the Win32 API and it's not easy.

See here

Share this post


Link to post
Share on other sites
Quote:
Original post by Nitage
It's possible to load a DLL from memory, but it's not directly supported by the Win32 API and it's not easy.

See here


Wow, thanks! That's exactly what I need. Odd that I didn't find that when I was looking around on Google.

By the way - there is another, a somewhat less painful solution that requires a file to be stored on the hard disk, but doesn't allow the plugin to be leeched: create a dud copy of the dll that has the code section replaced with zeros. Load it and replace the code section in memory. I can't be sure that would work, but it sounds reasonably possible. This would boil down to:

1) call LoadLibrary()
2) receive the code section over the network
3) replace it in memory (using the base address of the dll)
4) lock the memory again
5) get proc addresses
6) do whatever you what to do
7) clean up

But the 100% from memory solution is far more tidier and more suitable for my application.


The only problem that now arises, though is client security - essentially what I'd be doing is running unsolicited code on the client's computer. There is, however, very little guarantee that the plugin isn't malignant (for instance it a simple case might wipe out a hard drive or install a virus), not allowing the client to run a virus scan on it in advance. Even though I don't think that's really bound to be a problem, it's still a rather obvious security hole...

Is there any way I can curb the dll from having direct disk access?

edit: the answer to the last question seems to be running the dll in a separate thread and calling SetSecurityInfo() to change its privileges. There seems to be no way to change access rights for modules...

[Edited by - irreversible on June 27, 2006 6:13:59 AM]

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!