0

I am reading Eldad Eilam's book titled Reversing. In Chapter 11: Breaking Protections, there is a crackme called Defender, which creates a dedicated thread, which repeats the following steps:

1. Invokes `rdtsc` and saves the time-stamp counter (`t1`)
2. Relinquishes the CPU
3. Invokes `rdtsc` again, from the result (`t2`) subtracts the previous value: `dt=t2-t1`
4. If `dt` is greater than some hardcoded value, terminates; otherwise goes to 1.

The goal is to detect if the process is stopped in a debugger. Is the idea behind this method the fact that after hitting a breakpoint all threads will be stopped? Because as far as I know this can be prevented in gdb by issuing set pagination off and set non-stop on. Or is there something I am missing?

1

When a debugger is present, and used to single-step or to perform any time of run-time instrumentation, there is a measurable delay between the executions of the individual instructions, when compared to native execution.

This can be either bypassed "by hand" (rdtsc is not one of the typical instruction that you'll find in regular programs), or automatically if you control the cpu to make him lie about its current number of ticks, like in QEMU.

-1

the idea behind rdtsc instr is to detect if the process is single stepped not stopped in the debugger.

  • Is'nt single stepping actually stopping at every instruction? – robert Nov 20 '15 at 11:16
  • yes, but in this case its to detect single step only in the code block from first rdtsc to second rdtsc. If you stop in the debugger CPU cycles count will be much higher cause of the time (break/pause) you spend in the debugger – krusty Nov 20 '15 at 11:32
  • your comment should form part of your answer, since it includes the details about why it works – peter ferrie Nov 20 '15 at 15:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.