anti-reverse

7 minute read

Anti-Disassembly From Practical Malware Analysis

⦁ Understanding Anti-Disassembly.

​ first thing we need to know what is anti-disassembly. anti-disassembly: is a Technique that makes disassembly difficult for a malware analyst the malware writer use this Techniques.

⦁ Defeating Disassembly Algorithms.

there are two type to disassembly

  1. Linear Disassembly: this type is iterates over a block of code, disassembling one instruction at a time linearly, without regard for flow-control instructions, this basic strategy.

  2. Flow-Oriented Disassembly: A more advanced strategy this method used by most commercial disassemblers this type determines and examines the instructions and builds a list of locations like “JZ” this instruction like “if statement” by this strategy the disassemblers can disassemble false first and put the location for true in the list to disassemble in the future

⦁ Anti-Disassembly Techniques.

  1. Jump Instructions with the Same:

​ Target this technique is a combination of “JZ” with “JNZ” In fact this is an unconditional ”JMP“ but the disassembler doesn’t recognize it

​

​ When you see this order , this is your first indication that anti-disassembly, you can see the opcode like this

​

​

​ You need to understand the opcode in first 4 byte you can see “JZ” and “JNZ” instructions and then “CALL“ instruction the problem in “CALL” instruction .you can patch it by “NOP” = “0x90” or convert it from code to data like this

​

​

  1. A Jump Instruction with a Constant Condition : this technique is a commen one they use conditional jump every time will be true

    ​

    ​ In this example the “XOR” instruction put zero in eax and every time the condition will be ture The problem is happening when the disassembler disassembles the false first and by this it will conflict with the “0xE9” instruction and disassemble it to “JMP” to location Depends on the next 4 byte you can solve this problem by converting “0xE9” to data not code like this .

    ​

  2. Impossible Disassembly : this term does not mean written but the difference is in the previous sections we could to know the technique by read instructions now in this technique uses byte that we can’t ignored this mean we can’t only replace this byte with “0x90” = “NOP” . in this example you can see “0xFF” is a part of both instructions

​

​ You can notice that the “EAX ” inc then dec to solve this problem you can convert all byte to data you can see this sequence of byte doesn’t make error in disassembly but makes wrong result so we call this Impossible Disassembly

Note

so you see we use “NOP” in a lot of bytes, so we can use plugin written in python with IDA PRO to entire the first byte and the last byte and it will full it by “NOP” instruction .

Anti-Debugging From Practical Malware Analysis

Some Terms :

  1. Anti-debugging: is a popular anti-analysis technique used to detect debuggers also to make the operation of analysis difficult

  2. PEB(process environment block): we will use this term in that section so the PEB is a data structure that contain information about each running process , It contains all user-mode parameters associated with a process like that

    ​

    PEB can be referenced by the location fs:[30h]

Anti-debugging Techniques:

  1. Windows Debugger Detection.

    • Using the Windows API

      in this technique malware writer uses Windows API to detect debuggers I’ll explain some of this API :

      1. IsDebuggerPresent: this API searches for IsDebugged in (PEB) and zero if you are not running in the context of a debugger

      2. CheckRemoteDebuggerPresent: like IsDebuggerPresent but the new feature is it can check or detect debugger for another process it take a handle to a process that we need to know if it debugged

      3. NtQueryInformationProcess: This is a native API function , it can return information about a given process. it take two parameter first is a handle to a process and second is what information we need .For example, using the value ProcessDebugPort (value 0x7) for this parameter will tell you if the process in question is currently being debugged. If the process is not being debugged, a zero will be returned; otherwise, a port number will be returned

    • Manually Checking Structures

      they use this technique and it is most common . in this technique we use flags to detect debuggers i’ll explain some

      1. Checking the BeingDebugged Flag:

        flag location : PEB+18h

      to make anti-anti you have two solution

      • Force the jump to be taken (or not) by manually modifying the zero flag immediately before the jump instruction is executed. This is the easiest approach.
      • Manually change the BeingDebugged flag to zero.

      1. Checking the ProcessHeap Flag:

        flag location : PEB+18h

      • The best way to overcome this technique is to change the ProcessHeap flag manually or to use a hide-debug plug-in for your debugger
    • Checking for System Residue

      When analyzing malware, we typically use debugging tools, which leave residue on the system.

      malware take advantage for this and search for Residue and detect the debuggers , such as by searching registry keys for references to debuggers

      HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug

      this reg is changed if any error happend so if it is changed to something like OllyDbg malware determine that is debugger is runing

  2. Identifying Debugger Behavior.

    in this section malware use some normal Behavior to detect debugger

    like breakpoint

    • INT Scanning

      in this technique the malware take advantage from way that debugger uses it to put a breakpoint normaly whaen debugger want to make breakpoint it will add instruction INT 3 (which is the software interrupt) and when debugger found this it will stop the opcode for INT is (0xCC)

      the malware will search for this to detect the debuggers

      • This technique can be overcome by using hardware breakpoints instead of software breakpoints.
    • Performing Code Checksums

      every malware has checksums which is (CRC) or a MD5 checksum malware will check for the checksum for opcodes in the malware.

      • This technique can be overcome by using hardware breakpoints
    • Timing Checks

      the idea of this technique is to calculate time before excution instruction and after excute it and if the diffirence is large the malware will assumpation that malware is running we will explain some ways to do this

      1. Using the rdtsc Instruction

        rdtsc is used to returns the count of the number of ticks since the last system reboot

      in this example it calculate the diffirence between after and before and then check if the result is greater than 0xFFF

      if false nodebugger else debuggerdetected

      • This technique can be overcome by patch the “jb”

  3. Interfering with Debugger Functionality.

    in this section malware use some normal Functionality to detect debugger which is like where is the first breakpoint

    • Using TLS Callbacks

      Most debuggers start at the program’s entry point as defined by the PE header. A TLS callback can be used to execute code before the entry point and therefore execute secretly in a debugger

      this technique simply will uses to make the patch is difficult because the malware will excute some code before the first breakpoint but we can change the first breakpoint to tls code

      you can check for tls section by uses PEview

      you can have it pause before the TLS callback by selecting OptionsDebugging OptionsEvents and setting System breakpoint as the place for the first pause