3

I know hooking is usually used as a technique when one would rather use external (or injected) code to manipulate an executable, vs breakpoints which are usually set by a debugging framework in an attached executable.

Why would one prefer hooking function calls rather than setting a breakpoint?

The only examples I can think of are:

  • if somehow the control port used for debugging is sabotaged and you just need quick info (e.g. malware: the program is debugging itself as an anti-RE trick)
  • tool preference/preferring a program/tool/automated tool that collects information rather than the tedious task of debugging an application

Can anyone think of reasons other than these?

4
  • 1
    Hooking and breakpoints are used for very different usage, I am afraid you cannot really compare them. It is a bit like trying to compare a fish and a bike. To be more precise, breakpoint is used to stop a program in order to analyze the memory at this point. And, hooking won't stop the program but run a given function at start and at exit of a given program block.
    – perror
    Sep 18, 2015 at 19:14
  • Thanks for the reminder! Ive only read about hooking & never used it. Ive read zines, CTF & crackmes writeups that use hooks due to time checks or something implemented in the target. However, in all the situations encountered I never thought "cant use a debugger in this situation! Lets go hooking!" The only time I have is anti-malware or AV, which led to this question. When would you need to utilize hook rather than debug (outside of the aforementioned reasons) outside of AV/malware usage? I know its preferred when REing packers because it would be faster than dbg or writing a dbg script.
    – grepNstepN
    Sep 18, 2015 at 19:39
  • 2
    1) Hooks exists in the same address space as that of the target. So you have full access to all memory. In case of breakpoints, the debugger and debugee exists in different address space. In order to read memory, special API needs to be used, like ReadProcessMemory on Windows. 2) Hooks properly implemented, are usually difficult to detect. Debuggers are noisy.
    – 0xec
    Sep 19, 2015 at 5:17
  • thanks ya'll. I'd like to mark @ExtremeCoders comment as an answer but it won't let me, so I'll add it in an answer.
    – grepNstepN
    Sep 23, 2015 at 18:07

2 Answers 2

1

Both hooks and debuggers are easy enough to detect if you're looking for them. Using API in order to read the debugee's memory by the debugger is no real disadvantage, in my opinion.

I find debugging to be more documented, resilient and OS supported than any manual hooking. Although Microsoft for example provides the Detours hooking library, this is still not a functionality supported by the OS and Microsoft highlights that usage of hooking is discouraged.

The major reason I often see hooking being used instead of debugging is for the following reasons:

  1. Monitoring the entire system is required instead of specific processes.
  2. There's no need to trace the full flow of execution, but instead only record specific events (such as network communication, for example).

Although hooking could potentially be used for debugging, these two techniques are usually used for completely different things.

0

@ExtremeCoders comment was a sufficient answer:

1) Hooks exists in the same address space as that of the target. So you have full access to all memory. In case of breakpoints, the debugger and debugee exists in different address space. In order to read memory, special API needs to be used, like ReadProcessMemory on Windows.

2) Hooks properly implemented, are usually difficult to detect. Debuggers are noisy.

Forgot to look at my question in that regard.

1
  • 1
    Maybe add this comment w/ quotes as part of the accepted answer? Jun 10, 2018 at 7:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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