I've seen this done on Windows using CreateProcess, although I believe it wasn't specifically for anti-debugging purposes but instead a process that wanted to reinitialise itself from the beginning.
A far more effective actual anti-debugging technique is to have the parent become the debugger of the child, preventing any other debugger from attaching to it.
But then you can attach to the parent and cause it to stop debugging the child so you can. I think you want a process to be its own debugger; idk if ptrace(2) allows that. Then there's things like DTrace and eBPF -- I don't think you can prevent them from the target.
this is how ptrace works in essence, so if you look in the man pages for that ptrace there's an example. you just ptrace_attach from the parent to the child pid. it couldn't be more straighforward usage of ptrace. https://man7.org/linux/man-pages/man2/ptrace.2.html
long ptrace(enum __ptrace_request op, pid_t pid,
void addr, void data);
The patch code looks like a rather convoluted way of patching out the function code. Can we not just replace conditional branch with a regular one and nop out the rest? Or at least set w8 to 1 manually? I know next to nothing about ARM assembly, so I'm most likely missing something.
```
(lldb) run
Process 14345 launched: '/anti-debug/swift/build/anti_debug' (arm64)
start pid = 14345
exit parent process for child pid = 14348
continue as child process pid = 14348
Process 14345 exited with status = 0 (0x00000000)
```
The main reason for using dlsym instead of calling fork directly is to make it harder for an ‘attacker’ to detect or set breakpoints on the fork function, thus obfuscating the anti-debugging mechanism. You have to more checks before being able to understand why you cannot attach the debuger.
You may still think that mode could be still able to catch a new child process but apparently people have tried and the answer is no
I've seen this done on Windows using CreateProcess, although I believe it wasn't specifically for anti-debugging purposes but instead a process that wanted to reinitialise itself from the beginning.
A far more effective actual anti-debugging technique is to have the parent become the debugger of the child, preventing any other debugger from attaching to it.
But then you can attach to the parent and cause it to stop debugging the child so you can. I think you want a process to be its own debugger; idk if ptrace(2) allows that. Then there's things like DTrace and eBPF -- I don't think you can prevent them from the target.
> A far more effective actual anti-debugging technique is to have the parent become the debugger of the child,
Do you have example of that? I am really curious, thanks for sharing tho :)
this is how ptrace works in essence, so if you look in the man pages for that ptrace there's an example. you just ptrace_attach from the parent to the child pid. it couldn't be more straighforward usage of ptrace. https://man7.org/linux/man-pages/man2/ptrace.2.html
long ptrace(enum __ptrace_request op, pid_t pid, void addr, void data);
. to debug oneself you can try https://gist.github.com/x64-elf-sh42/83393e319ad8280b8704fbe...
it prints -1 due to some fail, but it cannot attach GDB to it :P
edit 9001: it notes the bash is attached to it which spawned the exe, not sure if that's correct or just buggy btw
The patch code looks like a rather convoluted way of patching out the function code. Can we not just replace conditional branch with a regular one and nop out the rest? Or at least set w8 to 1 manually? I know next to nothing about ARM assembly, so I'm most likely missing something.
Does follow-fork-mode in lldb not also defeat this?
I tried with LLDB using `settings set target.process.follow-fork-mode child` but for some reasons I feel like it still exit from the parent process.
I also tried with a long living process: https://github.com/tony-go/antidebug-examples/tree/main/swif...
And I got this:
``` (lldb) run Process 14345 launched: '/anti-debug/swift/build/anti_debug' (arm64) start pid = 14345 exit parent process for child pid = 14348 continue as child process pid = 14348 Process 14345 exited with status = 0 (0x00000000) ```
The UI did not even appeared as it should.
Maybe I miss something in my LLDB config...
Also it could come from a messy thing in the code.
The main reason for using dlsym instead of calling fork directly is to make it harder for an ‘attacker’ to detect or set breakpoints on the fork function, thus obfuscating the anti-debugging mechanism. You have to more checks before being able to understand why you cannot attach the debuger.
You may still think that mode could be still able to catch a new child process but apparently people have tried and the answer is no
Yes.
The more you hate, the more you love.