D2BS

BotSys ramblings

Who is the target audience?
There is no audience, there is only targets. j/k
Devs, Reverse engineers, game hackers, process automation and extension to name a few.

What are the goals of our envisioned framework?
To provide generic plugin/component framework for extending/automating applications etc
Avoiding major code re-factoring.
Provide support for major platforms(Windows, OSX, Linux, BSD, at least).

What types of applications do we want to be able to make? things to do botting and game hacking are certainly a major focus but not a requirement

Q. What is the core?
A. Minimal

We really need a plugin based system. In my opinion the core itself should
only contain what it needs to load plugins(even the users UI of choice is
loaded via a plugin).

What is our definition of a plugin system?

What sort of modules layout do we want?

Dependency handling
What kinds of feature interfaces are we going to need? If we go too general with our definitions, dependency resolution is difficult at best, impossible at worst. If we go too specific with our definitions, we risk eliminating possible features. We need to find some sort of happy middle ground.

Interface related:
We surely want plugin and interface registration.
wrt the loader(controller) communicating with the injected framework:
<lord2800> we should provide a nice and clean api for the game controller to communicate with the proc
<eBoLA> yes via ipc named pipe etc

<lord2800> well, write it up as if we have a full plugin system and requireable features
<eBoLA> ive looked at a few other similar or we can roll our own
<lord2800> let's start from there
<lord2800> and see what we think as we talk it out

<eBoLA> for all intents d2bs.lib could be wrapped as a module
<eBoLA> not enforcing granularity

<eBoLA> okay lord2800 at this point our choice comes down to picking a lib or a design pattern to implement

<lord2800> we've got the core mostly outlined now
<lord2800> engines and games become plugins basically
<lord2800> and features too
<lord2800> hrm.
this is the realm we want to be in:

We need to discuss our stance on API/ABI compatability
http://chadaustin.me/cppinterface.html touches on some things we may want to consider

I) roll our own system ..

<eBoLA> id like to bypass the pitfalls and pains of rolling our own if there is something proven
<lord2800> I like the syntax used here a bit more: http://www.nuclex.org/articles/cxx/4-building-a-better-plugin-architecture
<eBoLA> we could easily go with a simple plugin factory
http://www.abstraction.net/ViewArticle.aspx?articleID=67
<eBoLA> the preceding is more of a framework to start with

II) choosing an existing framework

DynObj - http://dynobj.sourceforge.net/
This is a bit heavy for our uses but is worth looking at, it has some useful features

PDL - http://sourceforge.net/projects/pdl-cpp/
This is a portable dynamic class loader. Applies the KISS paradigm. I could see using or modeling after this but note that it has some limitations class instances are singletons and it doesn't do much to solve ABI compatibility concerns.

CPluff - http://www.c-pluff.org/reference/c-api/plugin.html

Yehia - http://ucxx.sourceforge.net/

Plump - http://plump.sourceforge.net/
May be worth looking at but older and unmaintained.

Pugg - http://pugg.sourceforge.net/
We can pretty much ignore this seems quite non-interesting.

PILS heartbeat - http://docs.google.com/viewer?url=http://linux-ha.org/_cache/TechnicalPapers__pils.pdf
Useful information at least, we'll at least have to give it a good look over
The interface registration feature is surely something we want

Base Features
We want to push as much as is reasonable into the domain of plugins. Some of the things we will want in the things we will want is a basic form of logging and debugging helpers, we'll see if we can find a happy median here. Some form of crash reporting should be integrated.

Crash reporting
google-breakpad and crashrpt are the likely candidates.

Reference plugins to implement

• Core utility plugin likely consisting of things such as injection, memory patching, pointer creation and management, hooking)
• Extended log handling
• Shared pointer extension possibly
• Unit testing
• Signature scanning/offset updating tool
• Scripting engine support (Spidermonkey, etc.) .Net could fall here (This will be an API to think about later)

Security

Do we really care in this case? I'm not sure we can even provide or enforce any security constraints given our language choice (C++). We'll have to think about this later.
After some thinking and reading, plugin signing came to mind. This would be a good idea for multiple reasons, but the exact implementation details would have to be worked out. I wouldn't be averse to implementing it as a crypto signature that gets generated and stored inside the code--though how we go about hashing it needs to be figured out. One idea would be to make all plugins have a separate file that defines their crypto sig, though I don't exactly like that idea because that means distributing plugins now becomes two-part instead of one-part.

Project renaming?
Possibly but we need to think about this some more, it kind of depends on how
generic we plan on making the project.(and we agree that we suck at coming up with names)

Licensing modal related:
To sum this up we pretty much don't want to use AGPL for the core as its on shaky legal grounds and can be problematic. Cthulhon provided us with much insight on this matter and we thank him. It all comes down to dual licensing. Making the interface headers LGPL compatible or like and the core GPL or like.

• (L)GPLv2 and AGPLv1 are not compatible.
• (L)GPLv3 and AGPLv3 are.
• Check the wording of any libs we may use to see if there has been changes from the vanilla license ex. removal of the 'or any later version' in GPLv2 which the Linux kernel has done(this may not be technically legal).
• A generic interface is vaccination against a viral license in most cases(which cases is it not?)
• A generic interface anyone can link closed code

<Cthulhon> I'd say make the interface headers licensed under at least the BSD, if not some license that requires only direct modification to be contributed back. LGPL, MPL, Apache, etc. Having a GPL core with an LGPL SDK of sorts would probably work well.

Distribution packaging

Memory management
Hoard sounds like a good candidate here.

ORGANIZEME <eBoLA> for say a cli game manager
<eBoLA> cli app that links to the plugin framework
<eBoLA> i want to inject the same base lib into whatever exe doesnt even have to be a game
<lord2800> and the base lib would load whatever plugins are necessary
<eBoLA> ya whatever requested module after its in the target proc
<eBoLA> so ie int main() { .. BotSys::Init(); BotSys::Load("foo.bin"); ... }
<eBoLA> first thing foo.bin does in target is BosSys::Init() ...
<eBoLA> mods can be as fat as people want not that would be a point in huge monolithic stuff
<lord2800> eBoLA: I was thinking more along the lines of plugins a la php
<lord2800> so the plugin provides a set of features via functions/objects
<eBoLA> what else is included in the base lib?
<eBoLA> where do we draw the line?
<lord2800> eBoLA: hmm. well, if we go as minimal as possible, then core becomes a series of plugin factories and some minimal apis
<eBoLA> ya im speaking wrt the api
<lord2800> that's about it
<lord2800> maybe some wrappers around confusing winapi code
<lord2800> and some way of getting the current directory
<lord2800> s'ok
<lord2800> eventually I plan to migrate that thread into the api doc
<eBoLA> i dont see a reason not to load a hooking/patching/ptr lib
<lord2800> we should just provide that in the core
<lord2800> practically everything will at least want access to that

<eBoLA> what about the ability to extend or flat out override the base impl?

<lord2800> the game hack would definitely use it
<lord2800> and something like a packet sniffer would definitely use it
<eBoLA> live r/e
<eBoLA> load a function tracer or such
<lord2800> yeah
<eBoLA> pattern searching ... ..

The road to implementation
<lord2800> we probably should implement the core first and then an engine
<lord2800> and then test it out with a simple command line program
<lord2800> we can use that for implementing most plugins too
<eBoLA> minesweeper for a hello world
<eBoLA> demo
<lord2800> and to test the core hooking api
<eBoLA> yup sounds good
<lord2800> I suppose the first plugin we should implement, beyond the engine, is a simple i/o lib
<lord2800> actually I just had a thought, eBoLA
<eBoLA> yea doorway to simpleini
<lord2800> how are we gonna tie the engine to the plugin?
<lord2800> actually I got an idea
<lord2800> we have 3 factories: Plugin, Engine, and Game (for lack of a better word)
<lord2800> and for a plugin or a game to register a function with an engine, we provide a well-known api
<lord2800> i.e. Engine::RegisterFunction and Engine::RegisterFunctionSet
<eBoLA> ya the dynobj does akin to that i beleive
<eBoLA> or im confusing it with one of the other projects atm
<lord2800> RegisterFunction would take a void* that points to the function to register and a char* for the name
<lord2800> and the engine does whatever it needs to do to register it
<lord2800> (i.e. JS_DefineFunction for spidermonkey)
<lord2800> actually we'd have to have some more parts to registerfunction
<lord2800> we'd also need a formatting string
<lord2800> to specify number/type of args
<eBoLA> we could use that in ptr making macros/asm
<eBoLA> encode function arity however
<lord2800> I like the idea of a formatting string for function arity
<lord2800> provides a way to both know arg length and type at the same time
<lord2800> something akin to sprintf

<eBoLA> and ya i suppose a factory for script engine is a good way to go
<eBoLA> but have the factory as a plugin
<eBoLA> LoadEngine(foo) when wanted
<lord2800> chicken and egg problem
<lord2800> my thought is tie the loader and the factory together
<eBoLA> do want to say provide callbacks and an integrated event system / message passing system etc
<eBoLA> pre/post callbacks/override ability

do we want to cache the interface list so we don't have to load every plugin on start? unsure about the specifics yet I just know it would be valuable for us to have so we do want to cache interfaces somehow, then? specifics obviously omitted as sort of a registry? ebola: sort of, but without the windowsy implementation/feel I think we'll end up rolling our own system for this also ebola, I had an idea for plugin security we could use manualmap and the plugin comes as a single file ya i was wanting to implement manualmap module for sure and we read the first N bytes, which is the crypto sig that we compare to the hash of the rest of the module but not as a requirement and is there any areas of programs i should reasearch into? more data encoding tools etc?