Now this is a good start, but as previously mentioned, BlockBlock seeks to provide the user more information about the responsible process such that the user may make an educated decision. While this mechanism captures all file I/O (as opposed to only events of interest), it does provide the process id (pid) of the process that generated the file I/O event. That is to say, sure you get notifications from the API such as, "hey, a new launch daemon (plist) was created" - but there is no direct or trivial way to then get the pid and/or path of the process that created the new daemon.Īs such BlockBlock utilizes the /dev/fsevents device directly, as suggested by Amit Singh in his seminal "OS X Internals" book. In order to provide an informative alert, the alert popup contains the pid, path, and ancestry of the process responsible for at attempted persistence:Īlthough an application could use the FSEvents API to be alerted of specific file and directory changes, this API does not provide information about the process that generated the event.
Although most of BlockBlock's code and logic works great on El Capitan, one component is completely broken.thanks to Apple's changes to their latest OS.īlockBlock monitors file I/O events in order to detect "persistence attempts." When it detects such an event, it alerts the user. First up? - updating BlockBlock for El Capitan compatibility. Having recently returned from presenting at VirusBulletin and EkoParty, I finally have some free time to catchup on my todo list. Findings will be included in part II of this blog posting :) While I wait for a kext signing certificate from Apple I'll going to check this out, as KAuth interface appears more stable than the prototype of the MAC policy function.
Update: Several people have reached out to me (mahalo!) to mention that the KAuth API can also be used to monitor process creation from a kext.
0 kommentar(er)
