last fixes

_src/Anti-Debug/techniques/assembly.md

@@ -409,7 +409,7 @@ bool IsDebugged()
 <br />
 <h3><a class="a-dummy" name="popf_and_cpuid">9. POPF and CPUID</a></h3>
 
-This technique is similar to <a class="a-dummy" name="popf_and_trap_flag">7. POPF and Trap Flag</a>.
+This technique is similar to [7. POPF and Trap Flag](#popf_and_trap_flag).
 To detect the use of a VM in a sandbox, malware could check the behavior of the CPU after the trap flag is set. 
 The trap flag is a flag bit in the processor's flags register that is used for debugging purposes. 
 When the Trap Flag is set, the processor enters a single-step mode, which causes it to execute only one instruction at a time and then generate a debug exception. 
@@ -426,22 +426,22 @@ But the next instruction is <tt>cpuid</tt> which behaves differently in VM. When
 bool IsDebugged()
 {
 __try
-	{
-	__asm
-		{
-			pushfd
-			popfd
-			cpuid
-			C7 B2
-		}
-	return true;
-	}
+    {
+    __asm
+        {
+            pushfd
+            popfd
+            cpuid
+            C7 B2
+        }
+    return true;
+    }
 __except(GetExceptionCode() == EXCEPTION_SINGLE_STEP
 ? EXCEPTION_EXECUTE_HANDLER
 : EXCEPTION_CONTINUE_EXECUTION)
-	{
-		return false;
-	}
+    {
+        return false;
+    }
 }
 
 {% endhighlight %}

_src/Anti-Debug/techniques/misc.md

@@ -495,7 +495,7 @@ This technique involves modifying the Image File Execution Options (IFEO) regist
 When an executable file is launched, the operating system checks the corresponding IFEO registry key for any specified debugging options. If the key exists, the operating system launches the specified debugger instead of the executable file.
 Removing these entries further complicates analysis efforts by eliminating one potential avenue for researchers to attach debuggers to the malware process.
 
-<table style="width:62%">
+<table style="width:100%">
   <tr>
   	<td colspan="2">Check if the following process names are being removed (also check if the current process name is being removed)</td>
   </tr>

_src/Evasions/techniques/os-features.md

@@ -16,7 +16,6 @@ tags: os-features
 <br />
   [3. Detect Wine](#detect-wine)
 <br />
-
   [Countermeasures](#countermeasures)
 <br />
   [Credits](#credits)
@@ -217,7 +216,7 @@ Signature recommendations are not provided as it's pretty tricky to track such a
 The <tt>MulDiv</tt> [API](https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-muldiv) is being called with specific arguments (<tt>`MulDiv(1, 0x80000000, 0x80000000)`</tt>) which should logically return 1 - however, due to a bug with the ancient implementation on Windows, it returns 2.
 
 There are more known evasion methods to detect Wine like the good old check of searching for the existence of one of Wine’s exclusive APIs such as <tt>`kernel32.dll!wine_get_unix_file_name`</tt> or <tt>`ntdll.dll!wine_get_host_version`</tt>) as also mentioned in <a href="https://evasions.checkpoint.com/src/Evasions/techniques/processes.html#check-if-specific-functions-are-present-in-specific-libraries
-">Processes evasion techniques</a> </i>.
+">Processes evasion techniques</a>.
 
 <b>Code sample</b>
 <p></p>
@@ -237,7 +236,7 @@ int Check_MulDiv_1() {
         std::cout << "MulDiv evasion method not detected." << std::endl;
     }
 
-	return 0;
+    return 0;
 }
 
 int Check_MulDiv_2() {

_src/Evasions/techniques/registry.md

@@ -16,7 +16,6 @@ tags: registry
 <br />
   [3. Check if VBAWarnings enabled](#check-if-vbawarning-enabled)
 <br />
-
 [Countermeasures](#countermeasures)
 <br />
 [Credits](#credits)