0

This question already has an answer here:

I am trying to detect whether my executable is running in a debugger. Here is a solution using ptrace. My problem is that even if my executable is stripped (strip a.out) I am able to find with gdb the following code snippet:

0x00000000004007e9: mov    $0x0,%ecx
0x00000000004007ee: mov    $0x1,%edx
0x00000000004007f3: mov    $0x0,%esi
0x00000000004007f8: mov    $0x0,%edi
0x00000000004007fd: mov    $0x0,%eax
0x0000000000400802: callq  0x4006d0 <ptrace@plt>
0x0000000000400807: cmp    $0xffffffffffffffff,%rax

I simply run (gdb)info files, and disassembled the memory location belonging to .text. Is there a way to get rid from <ptrace@plt>, or is there a better way to detect the debugger beside the methods based on software breakpoints or execution time measuring?

marked as duplicate by jvoisin, peter ferrie, Dominik Antal, w s, ixje Nov 18 '15 at 5:54

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

1

You have 2 simple options:

  • You can link your executable statically and then strip (add -static to compiler/linker command line).
  • You can invoke ptrace system call using inline assembly
  • If you will invoke ptrace as system call with inline assembly you can obfuscate calculation of syscall parameters (index of system call is passed via registers, and you can calculate this number instead of using correct number directly for example).

EDIT:

The number of other, more complicated options, is endless. For example you can call this ptrace by function pointer, which is calculated dynamically. There are a lot of ways to obfuscate a function pointer value.

Please note that using obfuscation of any kind is "security through obscurity" and not too much effective without other, more effective measures such as encryption.

Good luck.

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