Fluke/en
From GZProject Wiki
Contents |
Fluke
When a task involved in the executable process, account for a large part of the code rewrite and reinventing the wheel. The project standardizes the connection to any local application to make it more simple. And this generation can be used in any project for any task, as the code is portable and separated into an independent module.
What is the objective is most often when we talk about connecting to the application? Naturally there may be many options, but the key management and control application. That is the challenge would most likely be confined to the interception of the call functions and transfer them either on the side of the main application or processing directly within applications, which made the connection. In this article I will describe the process, ways and options to connect to the application. Interception functions described in the following article IOFluke.
Types of Connection
We need to choose the method of connection in the target process. Any control of the application limited to the creation executable code and transfer its work process. This will determine the form in which we want to pass on the code. This can be a simple function written in C++ or in Assembler. And gently transferred from one area of memory to another, the complexity of the implementation of such an algorithm does not arise, but we are looking for a universal mechanism that will be embedded in any process, and is more convenient.
Transferring functions
Here is the original function written in assembler code for a lend between located in the body between the notes function body. After calling GetBody (), the process results in a binary array assembly code:
xor eax,eax;
nop;
nop;
nop;
retn;
Example functions :
std::vector<unsigned char> GetBody()
{
unsigned char* start;
unsigned char* end;
__asm
{
call process;
// function body start
xor eax,eax;
nop;
nop;
nop;
retn;
// function body end
process:
mov [end],offset process;
pop eax;
mov [start],eax;
};
return std::vector<unsigned char>(start,end);
}
Let the reader not to be scared simply example, it achieves exactly describes the mechanism by which could be realized any exploit. The type xor eax, eax may be replaced by the code processing and system libraries kernel32.dll addresses, as well as addresses of all library functions. Then, we get a dynamic, fully functional program, which is irrelevant to how addresses memory be neglected. This will register using SEH.
Let us return to our duties, receiving an array of dynamic code memory, we must consider options for the release of the code on the other side.
Transfer of executable code
Transfer binary array possible with the direct writing contents array executable process. This can be done in several versions:
- Using WINAPI WriteProcessMemory.
- Through programming driver.
Since the scheme the drivers are very focused on operating system version, I do not think it is promising. The second method, by using WriteProcessMemory requires us to care for the spaces of binary data in the executable process.
In other words, we need to answer the question of what memory, we want to put the data. This primarily depends on the purpose of our introduction. If our goal is specific executable code conversion process, we need to define the space in the executable process and write. Of course, tentatively, halting the flow inside the target process. Another option, if we did not have the memory to be executed our code - is only the one run. And this would have to use the main entrance point, or stop, which makes us the operating system.
These points can be :
- The program entry point.
- The call any library functions
- The windows processing queue messages
I think the list could go on.
There is a limit to which we can expect, the size of the binary code that we are trying to put in the trust process. Unfortunately, there could be a situation in which the code is allowable for embedding. For example, the body of the message contains only a single command to the core code within the process. And after the change process, we can not guarantee that our binary code starts running from their starting positions. Or our code replaced data necessary for the correct functioning of the application. To solve this problem requires a integrated library in the executable process. This task was successfully fulfilled the Fluke project.
Connecting the library
The binary code for the library is very popular method of writing control module. This solves a lot of issues. First, we do not have to use assembler, secondly, we do not spend forces in the dynamic addressing, and thirdly use debugging information to our library. Thus, we shied away from the limitations associated with the executable code. Let's take a look at the connection of any library in any executable process.
Synchronizing with the main application
An important point is the connection, downloading a few libraries, as well as the enforcement functions. Our project allows you to connect directly to a number of executable processes. And that means that we need to ensure appropriate synchronization between different libraries within a master application. All the synchronization and connectivity hidden inside the library, the developer receives a convenient interface within which lie further information on the ID connected process.
Let us look at the issue closer, and then we will understand why it was necessary to use the facilities synchronization in the application. Suppose we need to create a master application several child processes, each working independently. To do this, we run the process and give the command to connect the library to the new process created. It will be recalled that none of the available methods of connecting no guarantee that the library immediately loaded. Therefore, we do not know at what point we can start the next process, and connect the second library. That certainly is available through the Windows IPC mechanisms, but I think module Fluke obliged to guarantee and signaling an erroneous situations. That is not possible if for any reason connect the library, the developer will hear it through an exception and will be able to make adequate provision for removal, which would not lead to a breach of logic within the application wizard.
Writing library
Creating a new library, an arbitrary process in which virtually made no restrictions. For example, create a project in any environment, and connect to the static library, affordable way to us. Source, which are available at svndir:trunk/library/fluke. The code libraries need to create a global object inherited from class Fluke::CFlukeSlave. In the constructor of this class do challenge method Fluke::CFlukeSlave::Create ();. Here is an example:
class MyApp:public Fluke::CFlukeSlave
{
public:
MyApp()
{
Create();
}
};
MyApp g_app;
Tentatively to be involved in the project file svnfile:trunk/library/fluke/flukeslave.h. What do the same available in a repository with the project. At this stage, the library completed.
Master application
The next step is to develop master application. It is tasked with the basic logic of choice and support the subordinate application. And in the same way connected to it. All of these actions have already programmed and only need to choose the appropriate functions to the interface library. This means that the application developer master application determines how how will embed in the executable process, and then a feature flukemaster of relevant parameters. This procedure is for the normal functioning of the ligaments wizard applications and target the process.
List all the functions supported by the library to connect to the process described here : svnfile:trunk/library/fluke/flukemaster.h.
Getting source
To build the library must have :
