Simple DLL Loader for RO Clients, last updated 2014/01/05

[Ai4rei 321]

Simple DLL Loader for RO Clients

About
If you expect some super simple application, let me disappoint you, there is none; everything is already part of the RO client. Consider this post as a proof-of-concept. There are also certain catches that you should be aware of, before you start jumping for joy.

All you need to do, is to give your library a .asi, .m3d or .flt extension instead of .dll and it will miraculously get loaded by the client when it starts up and is unloaded once it shuts down.

While you can load pretty much any dynamic library this way, there is a major catch: when your DLL gets loaded, most of the initialization is already complete and the window is already visible, DirectX is not initialized at that point. So while this might be ideal for a client plug-in, that messes with the window or the client runtime, it's probably less usable for hot-patching of the initialization code. Another catch is, that the client will load fine when your DLL is deleted.

Summary: While the process of loading a DLL with the extensions .asi, .m3d and .flt is simple, the point at which it gets loaded might be unsuitable for certain uses. Since it's not intrusive, it might be of use for client plug-ins.

Demo: The linked demo consists of a pre-build DLL with source, that displays a message when loaded and unloaded for convenience of testing this PoC.

Edit:
Another issue noticed by Cataclysm: If "Sound Mode" in RO setup is set to "No Sound", DLLs will not be loaded.

Download
demo

QA

• How does this work?
  Your DLL is loaded as a driver for the Miles Sound System (mss32.dll), but since it does not register with it, it does not interfere with it in any way.

 

License

This work is licensed under a Creative Commons Attribution 3.0 Unported License.

Edited April 12, 2020 by Ai4rei

[KeiKun 8]

Hmmm...

I guess playing with client will be easier for me~

 

This image represents that Potte was here

[Rytech 392]

This is very interesting. I knew something like this was possible because of a .dll loading patch a past client dev made which I used for capturing outgoing packets. Is this stuff related to how the mouse freedon plugin works (dinput.dll)?

[Ai4rei 321]

No, those tools usually override a system DLL (dinput.dll) or replace a RO DLL (mostly cps.dll, which is a trimmed down zlib1.dll). Either method uses a DLL that is hard-bound (import section) to the client and executes before the client code.

 

This method loads DLLs as found, as many as you want, though it executes later than hard-bound DLLs.

Edited December 28, 2013 by Ai4rei

[安赫尔 9]

Sir Ai4rei!

 

Have some guide?

 

It is difficult to understand ...

 

I have always admired your work.

[Neo-Mind 264]

All you need to do, is to give your library a .asi, .m3d or .flt extension instead of .dll and it will miraculously get loaded by the client when it starts up and is unloaded once it shuts down.

 

When your DLL gets loaded, most of the initialization is already complete and the window is already visible, DirectX is not initialized at that point. So while this might be ideal for a client plug-in, that messes with the window or the client runtime, it's probably less usable for hot-patching of the initialization code.

[fppb08 0]

cool