• IsDebuggerPresent
o Determined by checking PEB.BeingDebugged (offset 0x02) to be set.

• IsRemoteDebuggerPresent
o Calls CheckRemoteDebuggerPresent on current process and checks if the return has a debug
port.

• IsNtGlobalFlag
o Checks the PEB.NtGlobalFlag (offset 0x68) for the following flags described in
Table 1: NtGlobalFlags.

• IsSeDebugPrivsEnabled
o This sample doesn’t enable DebugPrivs so if they are it is a red flag. Another test that is better
for this kind of test, but not implemented is to check the parent process and see if that process
has DebugPrivs enabled.

• IsHardwareBreakpointPresent
o This checks if any of the hardware breakpoints are set by checking the CONTEXT record for the
running thread.

• IsTooSlow
o This check is a simple timing check that does a simple back to back call to GetTickCount and
compares the delta and looks for a threshold of anything over two seconds constitutes debugging

invoke GetTickCount
mov ebx,eax
invoke GetTickCount
sub eax,ebx ; what is the maximum possible value here? Is it always zero? One? Can it be infinity?    

Code:

invoke GetTickCount
mov ebx,eax
invoke GetTickCount
sub eax,ebx ; what is the maximum possible value here? Is it always zero? One? Can it be infinity?    

The answer is it can be any value even with no debugger running.

revolution you are viewing it from the perspective of an author of operating system, but malware actor / author views are more limited, I guess.

invoke GetTickCount
mov ebx,eax
invoke GetTickCount
sub eax,ebx ; what is the maximum possible value here? Is it always zero? One? Can it be infinity?     

format PE console
entry start

include 'win32a.inc'

section '.data' data readable writable

buf     rb      10
        db      0
fmt     db      '%d'
len     dd      ?
dummy   dd      ?

section '.code' code readable executable

start:
        call    [GetTickCount]
        mov     ebx, eax
        call    [GetTickCount]
        sub     eax, ebx
        push    eax
        push    fmt
        push    buf
        call    [wsprintf]
        add     esp, 12
        mov     dword [len], eax
        push    -11
        call    [GetStdHandle]
        push    0
        push    dummy
        push    dword [len]
        push    buf
        push    eax
        call    [WriteConsole]
        push    0
        call    [ExitProcess]

section '.idata' import readable writable

 library kernel32, 'KERNEL32.DLL',\
         user32, 'USER32.DLL'

 import kernel32,\
        GetStdHandle, 'GetStdHandle', \
        WriteConsole, 'WriteConsoleA', \
        GetTickCount, 'GetTickCount', \
        ExitProcess,'ExitProcess'

 import user32,\
        wsprintf, 'wsprintfA'    

Modern CPU is fast enough.

A modern CPU can execute billions of instructions per second. The exact number depends on the CPU's clock speed (measured in GHz, or gigahertz) and the number of cores. A CPU with a clock speed of, for example, 3 GHz can process 3 billion cycles (and thus, potentially 3 billion instructions) per second. However, the number of instructions executed per clock cycle can vary due to factors like the complexity of the instructions and the CPU's architecture.

invoke QueryPerformanceFrequency, addr [freq]
invoke QueryPerformanceCounter, addr [start]
mov ecx, 1700000000
@@:
  loop @b ; 1 instruction in a loop
invoke QueryPerformanceCounter, addr [ends]
mov rax, [ends]
sub rax, [start]
cqo
div [freq]    

format PE console
entry start

include 'win32a.inc'

section '.data' data readable writable

buf        rb      100
           db      0
fmt        db      '%d', 0
len        dd      ?
dummy      dd      ?
freq       dq      ?
start_tick dq      ?
ends_tick  dq      ?

section '.code' code readable executable

start:
        mov     ecx, 100000000 ; Heat loop

  @@:
        loop    @b

        push    freq
        call    [QueryPerformanceFrequency]
        push    start_tick
        call    [QueryPerformanceCounter]
        mov     ecx, 1700000000 ; your CPU frequency (cycles)
;       mov     ecx, dword [freq]

  @@:
        loop    @b
        push    ends_tick
        call    [QueryPerformanceCounter]
        mov     eax, dword [ends_tick + 0]
        mov     edx, dword [ends_tick + 4]
        sub     eax, dword [start_tick + 0]
        sbb     edx, dword [start_tick + 4]
        jnz     @f
;       mov     ecx, 1000 ; more precise (up to one thousandth)
;       mul     ecx
        div     dword [freq]

  @@:
        push    eax
        push    fmt
        push    buf
        call    [wsprintf]
        add     esp, 12
        mov     dword [len], eax
        push    -11
        call    [GetStdHandle]
        push    0
        push    dummy
        push    dword [len]
        push    buf
        push    eax
        call    [WriteConsole]
        push    0
        call    [ExitProcess]

section '.idata' import readable writable

 library kernel32,                 'KERNEL32.DLL',\
         user32,                   'USER32.DLL'

 import kernel32,\
        GetStdHandle,              'GetStdHandle', \
        WriteConsole,              'WriteConsoleA', \
        GetTickCount,              'GetTickCount', \
        ExitProcess,               'ExitProcess',\
        QueryPerformanceCounter,   'QueryPerformanceCounter',\
        QueryPerformanceFrequency, 'QueryPerformanceFrequency'

 import user32,\
        wsprintf,                  'wsprintfA'
    

However the system will try to resume your process as soon as possible so that it finishes the interrupted handler ...

The full code is based on your previous testing program via GetTickCount.

  @@:
        nop
        loop    @b       

"The system" is the OS. A multi-tasking OS gives no guarantee about timing. You can get any value, 0, 1, 123, 2^31-1, etc. "The system" does what it wants, a user program has no control over it, and no way to force it to behave in any specific way.

I got the value "4" printed. Does that mean "LOOP" command take 4 CPU cycles, or what does that mean?

I don't know how many instructions are there in GetTickCount Win32 API, but certainly not many, since it took less than 1 ms to execute. My CPU is 1.7GHz, so can process 1.7 billion instructions per second!

I don't know how many instructions are there in GetTickCount Win32 API, but certainly not many, since it took less than 1 ms to execute. My CPU is 1.7GHz, so can process 1.7 billion instructions per second!

earlier i posted a message and deleted it as i dont remember the link to the source (probably somewhere in msdn)

i mentioned that QPC has some overhead, and it is advised to calculate that overhead and subtract it from your final time.