Fix images

0xcpu · Nov 6, 2019 · 48fec4c · 48fec4c
1 parent 2d04c7b
commit 48fec4c
Show file tree

Hide file tree

Showing 7 changed files with 5 additions and 5 deletions.
diff --git a/Phase1InitComplete/README.md b/Phase1InitComplete/README.md
@@ -12,7 +12,7 @@ void ExNotifyCallback(
 
 With the help of IDA we can see that this function is called with the following parameters:
 
-![ExNotifyCallback Phase1InitComple](https://cdn1.imggmi.com/uploads/2019/10/20/9fcc65231792b2f2104ef86c3e15ccab-full.png)
+![ExNotifyCallback Phase1InitComple](images/CallExNotifyCallback.png)
 
 The variable `ExCbPhase1InitComplete` holds the pointer to the `CALLBACK_OBJECT`. And the `Argument1` and `Argument2` are zero, this means that our callback won't receive any interesting arguments.
 
@@ -22,4 +22,4 @@ For this driver to work, it must be loaded at Boot time that means that the `Sta
 Having this in mind, the use case of this is quite small. But just for fun, we decided to add some code in the callback that allow us to retreive the address of the `LOADER_PARAMETER_BLOCK`. To do this, we basically obtain the address of the return address (Using the intrinsic [_AddressOfReturnAddress](https://docs.microsoft.com/en-us/cpp/intrinsics/addressofreturnaddress?view=vs-2019)) we checked using IDA and WinDbg how much we need to add to this value in order to obtain the pointer to the `LOADER_PARAMETER_BLOCK`. To make this short, the callback gets called from `ExNotifyWithProcessing` which substracts 0x30 to `rsp` (We add 0x8 for the retn addr from this function) this comes from `ExNotifyCallback` which substracts 0x28 (Again we add 0x8 for the retn addr) finally we found out the next value (At least on In Windows 10 ver 1903 (OS Build 19002.1002)) in the stack corresponds with the `LOADER_PARAMETER_BLOCK` (This is inside `Phase1InitializationIoReady`) so in the end would be:
 `0x30 + 0x8 + 0x28 + 0x8 = 0x68`. In the following image it can be seen how the code is adding 0x68 to `rax` and then we can use this value (pointer) to dispay the type `LOADER_PARAMETER_BLOCK`:
 
-![Obtaining LOADER_PARAMETER_BLOCK](https://cdn1.imggmi.com/uploads/2019/10/20/1797c0611078071add3ac86bea6f6567-full.png)
+![Obtaining LOADER_PARAMETER_BLOCK](images/LoaderParamBlock.png)
diff --git a/Phase1InitComplete/images/CallExNotifyCallback.png b/Phase1InitComplete/images/CallExNotifyCallback.png
diff --git a/Phase1InitComplete/images/LoaderParamBlock.png b/Phase1InitComplete/images/LoaderParamBlock.png
diff --git a/WdEbNotificationCallback/README.md b/WdEbNotificationCallback/README.md
@@ -4,7 +4,7 @@ The main function of this callback is to notify `WdFilter` when a `KnonwBadImage
 
 To trigger this callback the parameter [`BDCB_CALLBACK_TYPE`](https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/ntddk/ne-ntddk-_bdcb_callback_type) must be set to `BdCbStatusUpdate` (A status update provided by the system to a boot-start driver) and the structure [`_BDCB_IMAGE_INFORMATION`](https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/ntddk/ns-ntddk-_bdcb_image_information) must have the field Classification set to `BdCbClassificationKnownBadImage`.
 
-![WdBoot ExNotifyCallback](https://cdn1.imggmi.com/uploads/2019/11/5/32fb7fde2a79d44a3d24a98d88c92ab3-full.png)
+![WdBoot ExNotifyCallback](images/CallExNotifyCallback.png)
 
 In the previous image we can see the call that executes `WdBoot` to notify the callback routines. Argument1 is a pointer to MpEbGlobals.Magic and Argument2 is set to 0x28. The MpEbGlobals structure has the following definition
 
@@ -47,8 +47,8 @@ As we can see, this structure has some quite interesting fields that we will be
 
 - As we can see on MP_EP_GLOBALS, if we go back in the structure from the Magic field we can get the value of IoUnregisterBootDriverCallback. This function will be called when `WdBoot` is unloaded from memory. So there's a chance to change to change that pointer to our own function (Kinda hooking) so our function will be automatically called when `WdBoot`is unloaded from memory. Of course there's a big downside here, this callback is execute only when a `KnonwBadImage` is found, and of course if this happens the system will probably Bug Check. So not really a big deal here.
 
-![MpEbUnload](https://cdn1.imggmi.com/uploads/2019/11/5/e8d769eb462f5429f868550ee95d1fbc-full.png)
+![MpEbUnload](images/MpEbUnload.png)
 
 - This one needs further investigation on `WdFilter`, but it may be possible to access the DriversListEntry(Refer to the post to see the structure used in this field) and modify the Classification that was set by the ELAM driver. This could possibly lead to `WdFilter` believing this a `KnownGoodImage`, since `WdFilter` will use this information too. The downside here is that the routine registered by `WdFilter` execute before our registered routine, but this could probably be changed modifying the CALLBACK_OBJECT.CallbackFunctions LIST_ENTRY in order to make our routine first. (**This still needs investigation**)
 
-![WdFilter Saving DriverClassification](https://cdn1.imggmi.com/uploads/2019/11/5/794a318e4a1e40bded7f1e082f24ae0d-full.png)
+![WdFilter Saving DriverClassification](images/WdFilterCopyData.png)
diff --git a/WdEbNotificationCallback/images/CallExNotifyCallback.png b/WdEbNotificationCallback/images/CallExNotifyCallback.png
diff --git a/WdEbNotificationCallback/images/MpEbUnload.png b/WdEbNotificationCallback/images/MpEbUnload.png
diff --git a/WdEbNotificationCallback/images/WdFilterCopyData.png b/WdEbNotificationCallback/images/WdFilterCopyData.png