2

Can someone explain why GetTickCount is called 3 times in a row when only one result is used?

This isn't the whole function of assembly just the part which has GetTickCount many times. I don't think it's human error in programming who would do that? Is it some sort of optimization trick or some compiler screw up?

The output below is from OllyDbg

00412EB0  /$ 81EC F4010000  SUB ESP,1F4
00412EB6  |. 53             PUSH EBX
00412EB7  |. 55             PUSH EBP
00412EB8  |. 56             PUSH ESI
00412EB9  |. 8B35 14B24D00  MOV ESI,DWORD PTR DS:[<&KERNEL32.GetTick>;  kernel32.GetTickCount
00412EBF  |. 57             PUSH EDI
00412EC0  |. FFD6           CALL ESI                                 ; [GetTickCount
00412EC2  |. FFD6           CALL ESI                                 ; [GetTickCount
00412EC4  |. FFD6           CALL ESI                                 ; [GetTickCount
00412EC6  |. 8BC8           MOV ECX,EAX
00412EC8  |. B8 CDCCCCCC    MOV EAX,CCCCCCCD
00412ECD  |. F7E1           MUL ECX
00412ECF  |. C1EA 03        SHR EDX,3
00412ED2  |. 895424 14      MOV DWORD PTR SS:[ESP+14],EDX
00412ED6  |. FFD6           CALL ESI                                 ; [GetTickCount
00412ED8  |. FFD6           CALL ESI                                 ; [GetTickCount
00412EDA  |. FFD6           CALL ESI                                 ; [GetTickCount
00412EDC  |. 8BD0           MOV EDX,EAX
00412EDE  |. B8 CDCCCCCC    MOV EAX,CCCCCCCD
00412EE3  |. F7E2           MUL EDX
00412EE5  |. C1EA 03        SHR EDX,3
00412EE8  |. 895424 1C      MOV DWORD PTR SS:[ESP+1C],EDX
00412EEC  |. FFD6           CALL ESI                                 ; [GetTickCount
00412EEE  |. 8B0D A87C4300  MOV ECX,DWORD PTR DS:[437CA8]
00412EF4  |. 33C0           XOR EAX,EAX
00412EF6  |. 3BC8           CMP ECX,EAX
00412EF8  |. 894424 18      MOV DWORD PTR SS:[ESP+18],EAX
00412EFC  |. A3 20594D00    MOV DWORD PTR DS:[4D5920],EAX

Hex-Ray's decompiled result

  DWORD GetTickCountDivideddBy10; // [sp+14h] [bp-1F0h]@1
  unsigned int v41; // [sp+18h] [bp-1ECh]@1
  DWORD GetTickCountDividedBy10; // [sp+1Ch] [bp-1E8h]@1

  GetTickCount();
  GetTickCount();
  GetTickCountDivideddBy10 = GetTickCount() / 0xA;
  GetTickCount();
  GetTickCount();
  GetTickCountDividedBy10 = GetTickCount() / 0xA;
  GetTickCount();
  v41 = 0;
  dword_4D5920 = 0;

Executable file: http://www.mediafire.com/download/qnqb00q4yk4kq6v/

user3435580
  • 566
  • 1
  • 4
  • 15
  • Are you in debug mode? Because [0xCCCCCCCD](http://stackoverflow.com/questions/370195/when-and-why-will-an-os-initialise-memory-to-0xcd-0xdd-etc-on-malloc-free-new) is one of the special values often used in debugging. And did you compile the program with optimizations on? – phuclv Apr 20 '14 at 02:16
  • 1
    @LưuVĩnhPhúc: That is not a memory clearing pattern. That is actually a constant used in [division via reciprocal multiplication](http://homepage.cs.uiowa.edu/~jones/bcd/divide.html). The result of `MUL dw 0xCCCCCCCD` together with `SHR upper32, 3` is effectively a division by 10. – rwong Apr 20 '14 at 05:01
  • I haven't compiled this program it's very old 1998 program trying to reverse it.. this is just some strange stuff I found even IDA-PRO Hex-Rays didn't understand it well. I posted the Hex-Rays result too, Here is the exe file, http://www.mediafire.com/download/qnqb00q4yk4kq6v/ – user3435580 Apr 20 '14 at 09:11

0 Answers0