Back Orifice XP

• Download source files - 472.79 KB

Introduction

Back Orifice XP (BOXP) is a network administration tool available for the Microsoft Win32 environment.

Built upon the success of Back Orifice and Back Orifice 2000, Back Orifice XP puts network administrators in control of the system, network, registry, passwords, file system, and processes. Except that BOXP is smaller, faster, free, and very, very extensible, because is based on plug-ins architecture that ensures new features can be added without releasing all new binaries.

I (Javier Aroche) say: "It is my idea to restructure the code of BO2K, called BOXP, fix many problems that affect it and add new features. At this moment BO2K works... but not completely, it is necessary to make deep changes to support a TRUE Plugin Interface, so that these work with the system and between them correctly, something that in BO2K it is not possible nowadays. And so arises the need to re-write the current sources to create a new interface that allows the plugins to use all the internal functions of the framework and functions from other plugins".

BO2K has many concept problems, bugs and limitations, but the major problem is the limited Plugin Linkage (PL). The BO2K 1.1 PL is just is an extension of the BO2K 1.0 PL, has added more members and done; but those additions don't resolve the concept problems... just give us a 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 it is running (well maybe if we update all function calls or redirect the function with other technique to our new function).
5. BO2K don't supports multi-languages. It needs to be recompiled to change the strings.
6. The flexibility really is limited, not all BO2K functions/objects could be updated, without touching the Memory Image.
7. Plugins don't have access to all functions.
8. BO2K does not 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 impossible via plugins.
10. Inter plugin communications is (almost?) impossible!!

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 a standard initialization and load of objects for the three applications. When the Framework is already initiated, it passes the control to the application so it begins and loads its own objects and begins its real execution.

As I already mentioned, the objective of the Framework is to provide a common base, facilitating to the plugins the access to the interface of the application. What each application does is extend the Framework adding more functions and objects to this. It must be noticed that the Framework for if alone could not be executed, the application needs to maintain the execution and the interaction with the user.

The Framework should contain utility functions, control of accesses, logs, global variables and functions. 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
• +/- Needs to be loaded when the FrameWork startup (need to store the API name in strings).
• - Must be handled with care, 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 starts up.
• - Must be handled with care, a NULL/Zero value crashes the execution.

Global Variables (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 care, 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 global objects easily, 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 in Thread info structure. Therefore we could stop threads in an 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 editing 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 operations fail, 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 Debugger Output.
• Output file configurable.

[Others]

• Basic Windows Viewer included.
• Basic Process Viewer included (for NT and 9x). + Basic C++ utility functions included. + DLL Image Loader included.
• LZH Compression included.
• Important functions generate error codes if it fails.

Server New Features

• Allow to pass custom data when registering a command. Later, when the command is called, it could access 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.
• Not based in MFC, doing the extensions are easy to implement.
• Manage multiple languages.
• Preferences dialog box.
• GUI changes: Use Toolbar, flat buttons
• Allow exporting the server configuration to file.
• Configuration stored in .ini file.

Client New Features

• Not based in MFC, doing the extensions easy to implement.
• Manage multiple languages.
• Preferences dialog box.
• Workspaces are checksummed. Avoid load corrupted data.
• Dialog, font, background colors are customizable.
• Flat buttons added.
• Client configuration stored in .ini file. Could run multiple clients with different configuration without issues.
• Better performance. Could receive a lot of server replies and process them all!.

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 characteristics, they are only those that are good for the boxp comparison.

The official Back Orifice XP web site is: http://boxp.sourceforge.net/. Check it out for further details, last versions and support.

Javier Aroche (j_aroche AT users DOT sourceforge DOT net)
BOXP Project Admin
http://boxp.sourceforge.net/

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here.