This goes against modern understanding that say LDL or ApoB is an independent risk factor for cardiovascular disease. Also interestingly one of the authors, Dave Feldman, was a fellow SWE that left tech and started challenging this notion.
Sometimes there are too many errors to deal with. I find building on a machine that's on the exact macOS version that you are trying to build does the trick.
Apple allows 3rd party kernel extensions so naturally you would need to be able to debug the kernel. In my post, I link plenty of official Apple documentation that provide information on how to debug the kernel.
Yes, but that's not the whole OS. Where do your rights end to inspect the software and hardware you bought?
Also, I was careful to not say legal/illegal but allowed/disallowed. I am pretty sure that macOS disables some debugging calls, or at least it used to. What are the limits?
I can think of two different things that could match your description:
- An old call, ptrace(PT_DENY_ATTACH), which prevents the process that calls it from being debugged (with either ptrace or dtrace). iTunes calls this. It's always been rather easy to circumvent, either by attaching before the process has the chance to make the call, or by installing a kext that disables the functionality.
- System Integrity Protection broadly prohibits debugging of system processes, as well as kernel tracing via dtrace. But SIP can be disabled by the user, by design.
Kernel debugging in particular is explicitly supported by Apple in the form of Kernel Debug Kits, which consist of debug symbols for the open source parts of the kernel, as well as variant builds with more debugging stuff enabled at compile time. Peeking at the proprietary parts is presumably against the license agreement but not technically restricted in any way (hard to imagine what such a restriction would look like).
Because it has affected me in the past. I've had to debug stuff in the past in macOS, thinking it would be similar to BSD, and was thwarted by technical means to disable debuggers. I've found the experience quite distasteful and was trying to remember what the problems were that I faced.
Jonathan Levin's MOXiL 2nd Edition volume 3 is out and I recommend you get it. 1st edition is still very good and can hold you off until the other volumes are out.
Amit Singh has a Mac OS X Internals A Systems Approach that is good we well.
There are also various talks at security conferences that detail parts of macOS/iOS.
I haven't used vimperator for a long time, but in petadactyl you can use C-o and C-i to go back and forth, respectively. The key bind matches pretty well to what it is in Vim too.
Many people in infosec generally learn programming on their own and only code for their own need. They don't care about coding style, small optimizations, programming best practices, etc.
