0

I'm looking to develop a "secure" application and as a security mitigation, I'd like to be able to discover if a debugger (GDB, LLDB...) is in use on the currently running application; aborting if detected.

How can I detect monitoring of a statically-linked C application?

  • Walk the /proc tree
  • ...
Ben Crowhurst
  • 8,204
  • 6
  • 48
  • 78
  • 2
    FWIW, you're only going to stop the people who don't know what they're doing. When you give someone something to run on their computer, they **WILL** be able to figure out exactly what your code is doing. It's their kernel, their libraries, and their hardware. You can make it harder, but you can't stop it. – Andrew Henle Oct 07 '20 at 12:10
  • It is mathematically impossible for a piece of software to detect if it runs inside a perfect emulation, debugger or not. What you want is not possible. – 12431234123412341234123 Oct 07 '20 at 12:19
  • Making a program harder to debug does not increase security, the opposite is true. The harder to debug the less like for you to catch security vulnerabilities. I would recommend you to learn some more basics before you develop a security sensitive application. – 12431234123412341234123 Oct 07 '20 at 12:30
  • Security is about layers, it is very difficult to stop a determined individual but that in of itself is not an excuse not to have any restrictions. It very much is possible to determine if a process has been forked by a debugger and in that event to shut the application down... it is a layer of defence, a stopgap, not a cure. – Ben Crowhurst Oct 07 '20 at 21:58
  • @BenCrowhurst No, it is not possible to do that. A debugger can tell your software anything and the software can not detect if this is faked or not. It is not just difficult, it is impossible. Trying to restrict a owner to do something with your software is impossible. It seems you are trying to implement security by obscurity. Please stop what you are trying to do. You do not understand what you are doing. – 12431234123412341234123 Oct 08 '20 at 11:18
  • and yet... https://stackoverflow.com/questions/573115/what-is-your-favourite-anti-debugging-trick – Ben Crowhurst Oct 08 '20 at 20:01
  • and still... https://reverseengineering.stackexchange.com/questions/43/anti-debug-techniques-on-unix-platforms – Ben Crowhurst Oct 08 '20 at 20:32
  • @BenCrowhurst As you can read in the linked question "all the techniques I found on Internet were easily worked around as soon as the anti-debug technique has been understood." This is the case for every possible way to detect a debugger. Again, it is not possible. It is like trying to define the square root of 2 as a fraction. – 12431234123412341234123 Oct 12 '20 at 17:42
  • @12431234123412341234123 I appreciate your passionate response and I'm not looking for a full-proof aproach but additional layers to combat potentail misuse, please see my previous comment "Security is about layers, it is very difficult to stop a determined individual but that in of itself is not an excuse not to have any restrictions ..." – Ben Crowhurst Oct 12 '20 at 19:47

3 Answers3

0

Just a crazy idea - load BPF program (assuming your binary has a capability to do it) to intercept ptrace syscall from process parent, and check if pid of process being traced match your process' pid, then you can either fail the syscall, preventing the debug, and send and event to userspace to stop your process.

Although it won't work for attached process, so you'd need to intercept ptrace from all processes, I'm not sure BPF allows it, don't remember.

qrdl
  • 34,062
  • 14
  • 56
  • 86
0

Another crazy idea - tracer expects SIGTRAPs from tracee on each breakpoint/step, so you can catch this signal from your process, again using BPF, and do something about it. But again it is based on the assumption that tracer doesn't know about it.

qrdl
  • 34,062
  • 14
  • 56
  • 86
0

You can't. Software can not detect if it runs in a perfect emulation or in the real world. And a emulator can be stopped, the software can be analyzed, variables can be changed, basically everything can be done what can be done in a debugger.

Lets say you want to detect if the parent process is a debugger. So you make a system call to get the parent PID? The debugger can intercept the system call and return any PID which does not have to be the real PID. You want to intercept every SIGTRAP so the debugger can't use it anymore? Well the debugger can just stop in this case and send the SIGTRAP also to your process. You want to measure the time when you send SIGTRAP to know if the the process stops for a short time by the debugger for sending SIGTRAP so you know when there is a debugger? The debugger can replace your calls to get the time and return a fake time. Lets say you run on a Processor that has a instruction that returns the time, so no function call is needed to get the time. Now you can know that the time you are getting is real? No, the debugger can replace this instruction with a SIGTRAP instruction and return any time he wants or in case such a instruction does not exist, run the Software in a emulator that can be programmed in any way. Everything you can come up with to detect a debugger or emulator can be faked by the environment and you have 0 change to detect it.

The only way to stop debugging is by not giving the software to the customers but keep it in your hands. Make a cloud service and run the software on your server. In this case the customer can not debug your program since he does not run it and has no control over it. Except the customer can access the server or the data somehow, but that is a different story.

12431234123412341234123
  • 2,732
  • 15
  • 22