God knows that hosting an assembly is bound to trust management... No autonomy.
A hosted program calls an unmanaged Assembly through the PInvoke or COM interface. however, it seems that the hosted Assembly can only call the unmanaged Assembly through COM, at least in the current NET document. although the NET class library is very powerful, you do not need to operate the platform API to complete an excellent program or assembly, but sometimes we still need it, especially when we want to operate other program behaviors.
Including implementing APi Hook.
Penetrate the firewall.
Even implementing a non-process. Of course, these are very easy to implement in WIN32 programming. dotNet needs to carry a NET package of dozens of MB, which is really difficult... And its practical significance... I'm afraid it will be significant to use prescriptions when Vista is widely used in. After all, Net development, especially some form databases, is very easy. I also like dotNet very much.
When you look at the title carefully, you will find that I am talking about C # code, not dotNet code. Why? Because C # has a special feature in that it is a pure object-oriented language. the global method is not provided at all. second. C # I personally or most people like it and have some representativeness. The most common thing is that I really cannot stand the C ++/Clr development method... I really want to vomit. Of course, Vb.net is not the focus of this Article. After all, I personally do not like the syntax of Nothing. In fact, null looks more professional.
All right.
In WIN32, even processes are relatively independent. Of course, COM is not mentioned here, so we can say that injection is not to inject to other processes.
Think about some ways to let other processes load our assembly:
1. COM, a good way. Microsoft's support for COM on NET is still relatively good.
2. Use the C ++ Exports DLL function, which sounds good.
Here I will use the second method. The first method is not used. Why? Considering that WIN32 calls to COM, I am not very familiar with it. Secondly, I feel that the registration is not environmentally friendly, and it is not conducive to debugging.
Of course, the second method is not very fond... After all, the C ++/Clr code must be used. However, it is not too complicated to have a C ++ Foundation.
The basic idea of implementation is to use C ++/Clr or other languages or even WIN32 to establish an injection machine program, then, the injection machine is used to inject another compiled C ++/Clr DLL to the target process and initiate the call. The DLL is responsible for calling the CShape DLL. in fact, the key lies in the C ++/Clr DLL in the middle. in fact, the entire process is very easy to understand.
I used the remote thread Insertion Method to inject DLL (this code is too much discussion I skipped), by the way, why do I have to use a transit DLL. the reason is this: in Visual C ++ 2005, there is a line in MSDN, which probably means that if the hosted Code contains the local code in mixed programming, then EntryPoint must be a local function. in this way, the managed code cannot be called during initialization, and my form interface has been completed. In order to save money, I will not re-write the local code, even if MFC draws a form, it is easy to make the brain bigger... I hope it will be helpful to future generations.
Our C ++/Clr fills in an output table.
LIBRARY ClrDllInjectHelper
EXPORTS
LoadCShapeDll
Like this,
Then, it is called in the injected local code.
Void WINAPI RemoteMain (void * Data)
{
_ Try
{
LPVOID pProc;
PProc =: GetProcAddress (LoadLibraryW (DllPath), "LoadCShapeDll ");
If (pProc = NULL)
{
: MessageBoxA (NULL, "cannot load dynamic Connection Library, please check file integrity; \ r \ n Injection Process exited", "error", MB_ICONERROR );
: ExitProcess (NULL );
}
_ Asm
{
Lea eax, CShapeDllPath
Push eax
Call [pProc]
}
}
_ Handler T (EXCEPTION_EXECUTE_HANDLER)
{
: MessageBoxA (NULL, "SEH exception Handlered !!! ", NULL, MB_ICONERROR );
}
// Load yourself to load managed code
} Probably the code is like this. We load a DLL normally. In this way, this DLL can call the hosted assembly.
Call in the public DLL output function
Void _ stdcall LoadCShapeDll (WCHAR * CShapeDllPath)
{
String ^ str;
Try
{
Assembly ^ assembly;
Str =: System: Runtime: InteropServices: Marshal: PtrToStringAuto (System: IntPtr (CShapeDllPath ));
Assembly =: Assembly: LoadFile (str );
Type ^ type = assembly-> GetType ("CShapeDll. AppMain ");
System: Reflection: MethodInfo ^ mi = type-> GetMethod ("Main ");
Mi-> Invoke (nullptr, nullptr );
}
Catch (Exception ^ e)
{
System: Windows: Forms: MessageBox: Show (e-> Message + "\ r \ n DllPath:" + str, "Error Occured When in injection Code ");
: ExitProcess (NULL );
}
// System: Windows: Forms: MessageBox: Show ("DEBUG ");
}
In this way, the C # assembly can be loaded.
C # Assembly we only need to create a new class library and initialize a static class
The code is like this.
Using System;
Using System. Collections. Generic;
Using System. Text;
Using System. Windows. Forms;
Namespace CShapeDll
{
Public static class AppMain
{
Public static void Main ()
{
MessageBox. Show ("Loaded ");
Application. EnableVisualStyles ();
Application. SetCompatibleTextRenderingDefault (false );
Application. Run (new FormMain ());
}
}
Public class Class1
{
}
}
That's all. Theoretically, it's very simple. This way our task is finished.
Now let's discuss why a DLL can be output using C ++/Clr.
We use OllyDbg to load the DLL with a global output table.
We will be surprised to find a standard output table.
This means that we can load hosted/unmanaged code in this way. Of course, I think this is one of the reasons why C ++ is powerful.
We double-click this function before the DLL Initialization is complete.
Will find
100010D0 C> $-FF25 24800010 jmp dword ptr ds: [10008024]
100010D6 CC int3
100010D7 CC int3
It will jump to the data segment. At this time, the data in the code segment is an invalid pointer. After the DLL Initialization is complete.
This data will be filled and then transferred to the Jitter.
79013370 58 pop eax
79013371 55 push ebp
79013372 8BEC mov ebp, esp
79013374 51 push ecx
79013375 52 push edx
79013376 50 push eax
79013377 E8 87920000 call mscoree.7901C603
7901337C 5A pop edx
7901337D 59 pop ecx
7901337E 5D pop ebp
7901337F 50 push eax
79013380 C3 retn
. Therefore. once we load this dynamic link library in the standard LoadLibraryA/W mode. with GetProcAddress, you can call the managed code in the common WIN32 format. this is undoubtedly very convenient. in particular, it is not managed to call the managed code.
The article does not have any technical content. You just need to be an official player.
Source: [wood cracking] injects hosted assembly into other programs, which is very strong.
Http://www.bmpj.net/forum-viewthread-tid-254-fromuid-1.html
