Play with one of the microservices: Use the CreateEvent function to prevent the microservices from starting

Today I read a book and bought a good book for a long time-Windows core programming. When we see the kernel object, section 3.3.4 describes the "Terminal Server namespace". The content is: if there is a global namespace available for the kernel object, it means it can be accessed by all client program sessions. Windows has such a Global namespace: "Global", put "Global" before the object name, you can make the named object into the Global namespace. -- What do you think?

For cross-origin process boundary to share kernel objects, the micropoints are nothing more than a few methods. At first I thought we were using methods that could inherit handles or name objects. Then I reversed the main program of the micro-point: MPStart.exe, and found that this is not the case. When I saw the following, I firmly believe that micropoints use the global namespace method mentioned above. Haha!
. Data: 00408060; char Name []
. Data: 00408060 Name db GlobalMPMon_6934D571-115B-4830-AC5C-02A0D08179C5, 0

Sub_401170 proc near
Push esi
Push edi
Xor edi, edi
Push offset Name; "Global \ MPMon_6934D571-115B-4830-AC5C-02 "...
Push edi; bInitialState
Push edi; bManualReset
Push edi; lpEventAttributes
Call ds: CreateEventA
Mov esi, eax
Call ds: GetLastError
Cmp eax, 0B7h
Jnz short loc_401196
Bytes --------------------------------------------------------------------------------------------

. Data: 004080A4; char aGlobalRebootev []
. Data: 004080A4 aGlobalRebootev db GlobalREBOOTEVENT_6934D571-115B-4830-AC5C-02A0D08179C5, 0

Loc_401875:
Push esi
Push edi
Xor edi, edi
Push offset aGlobalRebootev; "Global \ REBOOTEVENT_6934D571-115B-4830-A "...
Push 1; bInitialState
Lea edx, [esp + 20 h + EventAttributes]
Push edi; bManualReset
Push edx; lpEventAttributes
Call ds: CreateEventA
Mov esi, eax
Test esi, esi
Jz short loc_4018AB

When I saw the above, my bad-hearted eyes came out! Can we use the CreateEvent function to createGlobalMPMon_6934D571-115B-4830-AC5C-02A0D08179C5The identified kernel object. In this way, I guess it cannot start.

I wrote a small Demo and tested it. As expected, I turned off the micro-point first and ran my demo:

At this time, you can start the micro-point again. The micro-point cannot be started unless you exit my program or release the kernel object created above. Haha!

Of course, everyone will say that you are a bubble, and people will not quit, you have no chance! -- Not necessarily. If I write a program that keeps monitoring the micropoints, and if I find that the micropoints are not there, I will quickly create the kernel object above. What should I do with the micropoints, you need to know that the update will always be automatically upgraded at the micropoint, and sometimes the update will be restarted after the update is completed. It takes about three seconds to create a kernel object! Haha! By the way, I personally think that such smart Trojans will be the trend of the times in the future, and those brutal Trojans will be a bubble!

Now I will write it here and declare that this Demo is not malicious. It is just learning and testing!

I personally do not recommend using a global namespace. Instead, we recommend that you use a method that inherits the handle to share kernel objects between processes.

Download Demo and source code:

My space:Http://shineast.ys168.com/