Detect if you're being debugged on OS X. Apple's AmIBeingDebugged() won't handle a debugger not using ptrace and is insufficient.

osx_being_debugged.c

#include <mach/task.h>
#include <mach/mach_init.h>
#include <stdbool.h>

static bool amIAnInferior(void)
{
	mach_msg_type_number_t count = 0;
	exception_mask_t masks[EXC_TYPES_COUNT];
	mach_port_t ports[EXC_TYPES_COUNT];
	exception_behavior_t behaviors[EXC_TYPES_COUNT];
	thread_state_flavor_t flavors[EXC_TYPES_COUNT];

	exception_mask_t mask = EXC_MASK_ALL & ~(EXC_MASK_RESOURCE | EXC_MASK_GUARD);
	kern_return_t result = task_get_exception_ports(mach_task_self(), mask, masks, &count, ports, behaviors, flavors);
	if (result == KERN_SUCCESS)
	{
		for (mach_msg_type_number_t portIndex = 0; portIndex < count; portIndex++)
		{
			if (MACH_PORT_VALID(ports[portIndex]))
			{
				return true;
			}
		}
	}
	return false;
}

I have to look at what's the cause of it, but this does not work as intended as it crashes a process that is not being debugged when called in a DYLD_INSERT'd dylib.

I know this is gist is incredibly old, but if you have any insights or encountered this yourself I'd be interested in your observations from the past.

Currently to determine this I'm just checking AmIBeingDebugged and searching the thread context for non zero dr- registrars -- saying there's a hardware breakpoint present.

I haven't tried this code in a long time. I assume it's crashing in task_get_exception_ports() or mach_task_self(). Maybe you're calling it too early in the process since you're being DYLD_INSERT'd but that's a guess.