Good average time for prog execution

[Magnum]

Since there are so many processors, I would like to find some time that would indicate that it is being **bugged.
Of course I know it will also vary according to how fast you close the MessageBox.

Thanks.

; TimeCheck.asm Help from Qword,
; 
;
;

__UNICODE__=1 ; application is now TCHAR aware, so you will get the same result without __UNICODE__

.386
.model  flat,stdcall
option  casemap:none

include \masm32\include\windows.inc
include \masm32\include\user32.inc
include \masm32\include\kernel32.inc
include \masm32\include\advapi32.inc

include \masm32\macros\macros.asm

includelib  \masm32\lib\kernel32.lib
includelib  \masm32\lib\user32.lib
includelib  \masm32\lib\advapi32.lib

; a little helper macro ;-D

TCHR macro lbl,literals:VARARG
        IFDEF __UNICODE__
                UCSTR lbl,literals
        ELSE
                lbl db literals
        ENDIF
endm

.data
   
OutputBuffer     TCHAR   512 dup(0)
TCHR             How_long,"Time was %d milliseconds.",0
TCHR             Success,"That took %d milliseconds.",0
TCHR             AppName,'SiegeWorks 2012',0
TCHR             Waste, 'Wasting a little time.',0

mark        db  "Start of Storage"
Start_Count dd   0
End_Count   dd   0
started     BYTE "End of Storage",0

.data?

.code

start:

  jmp   GO
  WaterMark   db  "SiegeWorks 2012"
  %Date       db  " &@Date " ; Compile date
  %time       db  " &@Time"
  %version    db  " Masm Version &@Version"

GO:

invoke GetTickCount
mov Start_Count,eax

invoke wsprintf, ADDR OutputBuffer, ADDR Waste, EAX
invoke MessageBox,NULL,ADDR OutputBuffer, ADDR AppName,MB_ICONINFORMATION

; Do something here


invoke GetTickCount

mov     End_Count,eax

mov     eax,End_Count
sub     eax,Start_Count

.if eax > 900d ;  milliseconds

invoke wsprintf, ADDR OutputBuffer, ADDR How_long, EAX ; Time was..milliseconds.

invoke  MessageBox, 0, ADDR OutputBuffer, ADDR AppName, 0

.ELSE

invoke wsprintf, ADDR OutputBuffer, ADDR Success, EAX   ; That took...milliseconds.
invoke MessageBox,NULL,ADDR OutputBuffer , ADDR AppName,MB_ICONINFORMATION


  .ENDIF

; if ((li2-li) > 0x10) {
; MessageBox(NULL, L"Debugger Detected via
; QueryPerformanceCounter", L"Debugger Detected",
; MB_OK);
; } else {
; MessageBox(NULL, L"No Debugger Detected", L"No
; Debugger", MB_OK);
; }

invoke ExitProcess,0

end     start

[MichaelW]

Your time timing will vary with the processor and the clock speed. The variation due to the processor (IPC) will be relatively small, perhaps a range of 3:1 over the systems currently in use. But the variation due to the clock speed could be relatively large, perhaps 8:1, and much larger if the processor varies its clock speed during the test. You would do better timing in clock cycles because a clock cycle count will not vary (significantly) with the clock speed.

[Magnum]

Thanks Michael.

I am looking to check how long some code is taking while the program is running and branch off based on whether it is executing
within a defined amt. of time.

Andy

[Tedd]

As an anti-debugging measure, this is completely ineffective. The very code you're looking to 'protect' will obviously be the code that gets debugged - okay so far. As will the code around it - your timing code. So your amazing "are_we_being_debugged?" code will be stepped through and the jcc will be changed to jmp. Fixed.

Seriously, don't even waste your time on such tricks. If your software is worth hacking, it will be - all you can hope to do is make it a little difficult, but generally it's a waste of time. More likely, I'm afraid, no-one will care - so you will have completely wasted your time.

Spend your time making your software as amazing as possible. If it's so good that it's worth hacking, then it's also so good that people will pay for it. If you really believe you have something amazing, and that it needs protecting, then use a professional software protection solution.

[Magnum]

Tedd,

I propose that you are making an assumption based a tad bit of information.

"Redirecting"  can be useful to others in some situations.

Have a great day,

Andy