[Boxp-devs] [Task #103792] Build BOXP Engine
Status: Beta
Brought to you by:
j_aroche
From: SourceForge.net <no...@so...> - 2004-08-24 23:02:45
|
Task #103792 has been updated. Project: Back Orifice XP Subproject: FrameWork Summary: Build BOXP Engine Complete: 0% Status: Open Authority : j_aroche Assigned to: j_aroche Description: Back Orifice XP Description =========================== BO2K have many concept problems, bugs and limitiations, but the major problem is the limited Plugin Linkage (PL). The BO2K 1.1 PL just is an extension of the BO2K 1.0 PL, have added more members and done; but those additions don't resolve the concept problems... just give us an false hope. Therefore I have prepared a full redesign of the structure of bo2k and his Plugin Linkage. We need to recode because: 1. BO2K can't handle advanced techniques (like RemoteThread, Process Injection, Memory Image Compression/Encryption, "Hot plug" function updates,...). 2. The PL is too Limited. 3. Problems working with plugins that runs threads. 4. BO2K can't be updated when is running (well may be if we update all function calls or redirect the function with other techinque to our new function). 5. BO2K don't supports multi-languages. Need to be recompile to changes the strings. 6. The flexibility really is limited, not all BO2K functions/objects could be pdated, without touch the Memory Image. 7. Plugins don't have access to all functions. 8. BO2K don't knows if a plugin is running a thread. 9. The Client and the Config Tool are based in MFC, that does the GUI extensions almost imposible via plugins. 10. Inter plugin communications is (almost?) imposible!!. The FrameWork ============= This is the Primary Concept, the Code Base of the Server, Client and Config Tool. The Three applications will share the same FrameWork, giving an standard initialization and load of objects for the three applications. When the FrameWork is already initiate it passes the control to the application so it begins and loads its own objects and begin the real execution of it. As I already told the objective of the FrameWork is to provide a common base, facilitating to the plugins the access to the interface of the application. What does each application is extend the FrameWork adding more functions and objects to this. Must be noticed that the FrameWork for if alone it could not be executed, needs of the application to maintain the execution and the interaction with the user. The FrameWork should contain utility functions, control of accesses, logs, global variables and fucntions. The Application should contain user's interface, using the FrameWork for the common tasks (like handling plugins). The Plugin Linkage ================== The New Plugin linkage will be integrated for: [where '+'=good point and '-'=bad point] * API (pointers to API) + Can bypass/change them, just change the pointer address and done. + Common access way. + no API clearly present in the exe file. + Less plugin size, don't need the 'Import Table' in the PE header. + Faster plugin load, don't need to find the API addresses. +/- need to be loaded when the FrameWork startup (need to store the API name in strings). - Must be handled with careful, a NULL/Zero value crashes the execution. * Functions (pointers to functions) + Can bypass/change them, just change the pointer address and done. + Common access way. - need to add one for one when the FrameWork startup. - Must be handled with careful, a NULL/Zero value crashes the execution. * Global Varaibles (pointers and statics) * Strings and Binary data + Can bypass/change them, just change the pointer address and done. +/- Must be structured. - Must be handled with careful, a NULL/Zero value crashes the execution. * Application Context (functions, vars, strings, ...) + Common access way. + Plugins know we are running without complex test. - Must be handled with careful, a NULL/Zero value crashes the execution. With this structure the plugins can access to global objects easy, with problems. All data is shared. FrameWork Features ================== * [Strings] + Allow to replace them (for multilanguage support). + Allow to compress/encrypt them. * [Configuration] + Add, remove them. + Save/load configuration from .ini file. + Allow global access of all variables (so we could check the config of other plugin). + Allow change values storing the new values in a .ini file. * [Threads] + Keep a list of threads running in the FrameWork. + Start, Stop, Suspend, resume them. + When the shutdown starts, must stop all threads to avoid crash the FrameWork. + Custom data could be passed when the thread is created. + Control execution variable included un Thread info structure. Therefore we could stop threads in a easy way. + Find threads by ID String. * [Plugins] + Load/Unload them. + Allow to run one main thread at startup. + Share custom data, could be used to pass a pointer to a context structure. + Allow replace strings. (for multi-language support) + Keep a list of plugins to load at startup (only if .ini support is enabled) so when restarts loads the plugins added. + Change configuration, without edit the disk image (only if .ini support is enabled). + Any kind of file could be attached to the Server. + Allow self plugin remove. + Find Plugins by ID String. + Attachments are checksummed. * [Functions] + Handle a table of extra functions. + Add/remove extra functions. + Find functions by ID String. * [Encryption modules] + Add/remove engines. * [Input/Output modules] + Add/remove engines. * [Authentication modules] + Add/remove engines. + Better support of multi users architecture. + If Connect or Listen operation fails, returns error code. * [Logging] + Calls to important functions generates logs (AddPlugin, RemovePlugin, AddThread,...) + Plugins can generate logs. + Write log strings to a file or in Debuger Output. + Output file configuable. * [Others] + Basic Windows Viewer included. + Basic Process Viewer included (for NT and 9x). + Basic C++ utility functions included. + DLL Image Loader included. + LZH Compresion included. + Important functions generates error codes if fails. Server New Features =================== + Allow to pass custom data when register a command. Later, when the command is called it could access to the custom data. + Direct call of Server Commands, don't need to create a socket and connect to another socket in the server to execute them. + Manage multiple languages. + Better control of Listening Sockets and Connection Sockets. Uses mutex. + Custom Issue command reply function. + Command replies could be stored in a buffer, instead send them to the socket. + Configuration stored in .ini file; but could be disabled. Configuration Tool New Features =============================== + Must support plugins. + Register Plugins Commands. + No based in MFC, doing the extensions easy to implement. + Manage multiple languages. + Prefereces dialog box. + GUI changes: Use Toolbar, flat buttons + Allow export the server configuration to file. + Configuration stored in .ini file. Client New Features =================== + No based in MFC, doing the extensions easy to implement. + Manage multiple languages. + Prefereces dialog box. + Workspaces are checksummed. + Dialog, font, background colors are customizable. + Flat buttons added. + Client configuration stored in .ini file. Could run multiple client with different configuration withour issues. + Better perfomance. Could receive a lots of server replies and process them all!. Some planned new plugins ======================== Every program need to have options, so here is a list of plugins that should be work in boxp (and that maybe you couldn't see in bo2k!): * Remote Windows Manager Client. * Sound Stream. * Chat stream. * Remote DOS/Windows Secure Console(uses an authenticated socket). * Remote Databases manager (uses odbc, for more DBMS's compatibility). * Reverse connections, that is server connecting to client. * Users Authentication module (code name: Marsala, alredy begins to be development). * Multi language module. * Web client, handle your server with your web browser (alredy coded in bo2k). Out === This is only a sample of the current characteristics (or that are planned) of boxp, it doesn't seek to be a complete listing of characteristic, they are only those that are good for the boxp comparison. Javier Aroche (j_aroche AT users DOT sourceforge DOT net) BOXP Project Admin http://boxp.sourceforge.net ------------------------------------------------------- For more info, visit: http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=103792&group_id=115536&group_project_id=37920 |