News for hackers. Stuff that matters.
Re:Implementing and Detecting Anti-Debugging with Fork() by cassepipe on Friday September 27, 2024 @08:01AM (#41669366)
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

Re:Implementing and Detecting Anti-Debugging with Fork() by a_t48 on Sunday September 29, 2024 @06:10AM (#41686273)
Ah, I never considered how follow forks mode might actually work/
Re:Implementing and Detecting Anti-Debugging with Fork() by tonygo on Friday October 04, 2024 @03:52AM (#41738894)
I tried, but I was not able to determine so far...
Re:Implementing and Detecting Anti-Debugging with Fork() by tonygo on Monday October 14, 2024 @04:43AM (#41835525)
I try to transform my C program into a long living one (just adding a sleep).

https://github.com/tony-go/antidebug-examples/pull/1

At first, it appears that the follow fork mode works nicely. But at some point it did not ... If I run it 10 times consequtively in LLDB. Sometimes it works, sometimes not ...

Re:Implementing and Detecting Anti-Debugging with Fork() by tonygo on Wednesday October 02, 2024 @03:55AM (#41718241)
> 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

Not sure I got this. IIUC there is a link between the fact that we used dlsym and the fact the child process is not catched by lldb in the follow fork mode?