blackosx Posted August 17, 2015 Author Share Posted August 17, 2015 I've been wondering how I can get a reading from OS X 10.11 for the state of each SIP setting for inclusion in to DarwinDumper. For now I've created a script and combined it with a couple of resources, to test the following: - CSR_ALLOW_UNTRUSTED_KEXTS - CSR_ALLOW_UNRESTRICTED_FS - CSR_ALLOW_TASK_FOR_PID - CSR_ALLOW_UNRESTRICTED_DTRACE - CSR_ALLOW_UNRESTRICTED_NVRAM However, I have no idea how to test for these other two: - CSR_ALLOW_KERNEL_DEBUGGER - CSR_ALLOW_APPLE_INTERNAL Does anybody know if this is possible? Here's v0.3 of the script as it stands. checkSIP_v0.3.zip Current Output Output from my iMac with SIP enabled: ================================================== checkSIP v0.3 Note: Final SIP status is currently not accurate! ================================================== csrutil reports: System Integrity Protection status: enabled. Testing: ( 0 = Not Allowed / 1= Allowed) ================================================== Password: CSR_ALLOW_UNTRUSTED_KEXTS 0 CSR_ALLOW_UNRESTRICTED_FS 0 CSR_ALLOW_TASK_FOR_PID 0 CSR_ALLOW_KERNEL_DEBUGGER Unknown (presuming 0) CSR_ALLOW_APPLE_INTERNAL Unknown (presuming 0) CSR_ALLOW_UNRESTRICTED_DTRACE 0 CSR_ALLOW_UNRESTRICTED_NVRAM 1 ================================================== SIP status: 01000000 (0x64) Disabled ================================================== Output from my iMac with SIP disabled: ================================================== checkSIP v0.3 Note: Final SIP status is currently not accurate! ================================================== csrutil reports: System Integrity Protection status: disabled. Testing: ( 0 = Not Allowed / 1= Allowed) ================================================== Password: CSR_ALLOW_UNTRUSTED_KEXTS 1 CSR_ALLOW_UNRESTRICTED_FS 1 CSR_ALLOW_TASK_FOR_PID 1 CSR_ALLOW_KERNEL_DEBUGGER Unknown (presuming 0) CSR_ALLOW_APPLE_INTERNAL Unknown (presuming 0) CSR_ALLOW_UNRESTRICTED_DTRACE 1 CSR_ALLOW_UNRESTRICTED_NVRAM 1 ================================================== SIP status: 01100111 (0x103) Disabled ================================================== Resources Used For testing task_for_pid I've used a program I found on stack overflow by 0xced here #include <stdio.h> #include <stdlib.h> #include <mach/mach_traps.h> #include <mach/mach_init.h> #include <mach/mach_error.h> int main(int argc, char* argv[]) { task_t task; pid_t pid = argc >= 2 ? atoi(argv[1]) : 1; kern_return_t error = task_for_pid(current_task(), pid, &task); printf("%d -> %x [%d - %s]\n", pid, task, error, mach_error_string(error)); return error; } For testing kext loading I'm using Kabyl's old Disabler.kext which disabled AppleUpstreamUserClient. Notes For now, the CSR_ALLOW_UNRESTRICTED_NVRAM test always passes. But I have read from one of Pike's posts that this will not be fully enabled until the GM of El Capitan. So together with this and the two outstanding checks for Kernel Debugger and Apple Internal, the final status reported by the script is incorrect. 1 Link to comment Share on other sites More sharing options...
crusher Posted August 17, 2015 Share Posted August 17, 2015 After test your script I have this results: ================================================== checkSIP v0.3 Note: Final SIP status is currently not accurate! ================================================== csrutil reports: System Integrity Protection status: enabled. Testing: ( 0 = Not Allowed / 1= Allowed) ================================================== Password: CSR_ALLOW_UNTRUSTED_KEXTS 0 CSR_ALLOW_UNRESTRICTED_FS 0 CSR_ALLOW_TASK_FOR_PID 0 CSR_ALLOW_KERNEL_DEBUGGER Unknown (presuming 0) CSR_ALLOW_APPLE_INTERNAL Unknown (presuming 0) CSR_ALLOW_UNRESTRICTED_DTRACE 0 CSR_ALLOW_UNRESTRICTED_NVRAM 1 ================================================== SIP status: 01000000 (0x64) Disabled ================================================== Link to comment Share on other sites More sharing options...
blackosx Posted August 17, 2015 Author Share Posted August 17, 2015 Thanks for the quick test crushers! It works as expected, though as stated in the above post the script will never be accurate unless a way can be found to test the kernel debugger and apple internal states. Link to comment Share on other sites More sharing options...
Micky1979 Posted August 17, 2015 Share Posted August 17, 2015 for the kernel debug mode you should see at boot args in nvram like "debug=0x144". FileNVRAM.dilyb do a callback to the bootloader, so arguments get added and visible to bdmesg log also, I don't know for Clover. So I suppose you have two possible way. CSR_ALLOW_APPLE_INTERNAL allow/disallow valid flags, is like to set rootless=0/1 (if rootless=1 then CSR_ALLOW_APPLE_INTERNAL is set 0, then all other CSR_* are not allowed), so you can get that in bdmesg. rootless=0 argument detected = CSR_ALLOW_APPLE_INTERNAL 1 or rootless=1 argument detected = CSR_ALLOW_APPLE_INTERNAL 0 Link to comment Share on other sites More sharing options...
blackosx Posted August 17, 2015 Author Share Posted August 17, 2015 for the kernel debug mode you should see at boot args in nvram like "debug=0x144". What a coincidence.. I've just been playing with debug=0x14e Thing is, on my iMac, I see debug info at boot with -v regardless of whether or not SIP is enabled or disabled. My last five boots all show: Aug 17 17:31:42 localhost kernel[0]: IOKernelDebugger: registering debugger Aug 17 17:45:56 localhost kernel[0]: IOKernelDebugger: registering debugger Aug 17 17:58:41 localhost kernel[0]: IOKernelDebugger: registering debugger Aug 17 18:08:30 localhost kernel[0]: IOKernelDebugger: registering debugger Aug 17 18:12:21 localhost kernel[0]: IOKernelDebugger: registering debugger So I'm not sure whether the CSR_ALLOW_KERNEL_DEBUGGER is meant to stop this or not. 1 Link to comment Share on other sites More sharing options...
Fabio1971 Posted August 17, 2015 Share Posted August 17, 2015 After test i have this results : checkSIP v0.3 Note: Final SIP status is currently not accurate! ================================================== csrutil reports: System Integrity Protection status: disabled. Testing: ( 0 = Not Allowed / 1= Allowed) ================================================== Password: CSR_ALLOW_UNTRUSTED_KEXTS 1 CSR_ALLOW_UNRESTRICTED_FS 1 CSR_ALLOW_TASK_FOR_PID 1 CSR_ALLOW_KERNEL_DEBUGGER Unknown (presuming 0) CSR_ALLOW_APPLE_INTERNAL Unknown (presuming 0) CSR_ALLOW_UNRESTRICTED_DTRACE 1 CSR_ALLOW_UNRESTRICTED_NVRAM 1 ================================================== SIP status: 01100111 (0x103) Disabled ================================================== Fabio 1 Link to comment Share on other sites More sharing options...
blackosx Posted August 18, 2015 Author Share Posted August 18, 2015 Thanks for your input Micky1979. for the kernel debug mode you should see at boot args in nvram like "debug=0x144". But the presence of the debug boot arg does not indicate whether CSR_ALLOW_KERNEL_DEBUGGER is enabled or not. CSR_ALLOW_APPLE_INTERNAL allow/disallow valid flags, is like to set rootless=0/1 (if rootless=1 then CSR_ALLOW_APPLE_INTERNAL is set 0, then all other CSR_* are not allowed), so you can get that in bdmesg. Yes I see here that everything is allowed if CSR_ALLOW_APPLE_INTERNAL is set, but I fail to see how to identify if this is set from a running system. bdmesg is irrelevant on a real Mac as there is no boot log in ioreg. It would be great if apple printed the SIP state in the system.log with something like Aug 17 17:45:56 localhost kernel[0]: Security Integrity Protection State: 0x00 EDIT: or even just changed their current engaged message Aug 18 17:51:20 2015 com.apple.xpc.launchd[1] <Notice>: System Integrity Protection is engaged. to show when not fully engaged.. Aug 18 17:51:20 2015 com.apple.xpc.launchd[1] <Notice>: System Integrity Protection disengaged at 0x67. Link to comment Share on other sites More sharing options...
Micky1979 Posted August 18, 2015 Share Posted August 18, 2015 But the presence of the debug boot arg does not indicate whether CSR_ALLOW_KERNEL_DEBUGGER is enabled or not. Aug 17 17:31:42 localhost kernel[0]: IOKernelDebugger: registering debuggerAug 17 17:45:56 localhost kernel[0]: IOKernelDebugger: registering debugger Aug 17 17:58:41 localhost kernel[0]: IOKernelDebugger: registering debugger Aug 17 18:08:30 localhost kernel[0]: IOKernelDebugger: registering debugger Aug 17 18:12:21 localhost kernel[0]: IOKernelDebugger: registering debugger Anyway to enable it you need a Kernel flag, so real Mac have to use nvram bootarg. Yes incorrect parameter should not enable the debug mode but is an evidence (mmmmh no)? and IOKenelDebugger... it seems that something has been published in your ioreg... you have checked it?...not sure nyway I suppose that this goes in dmesg too.. EDIT take a look here: http://ho.ax/posts/2012/02/debugging-the-mac-os-x-kernel-with-vmware-and-gdb/ Link to comment Share on other sites More sharing options...
blackosx Posted August 18, 2015 Author Share Posted August 18, 2015 Hey Micky1979 - Thanks for the prompt reply. I haven't had time to boot back in to El Capitan yet but hopefully I can get time later today and check ioreg and dmesg. EDIT: To answer your questions. I used the com.apple.Boot.plist, rather than nvram for the debug boot arg as I have 4 OS X installs on my iMac and I prefer to keep that debug option just for a single OS and not all. Yes it looks like the network port was added to ioreg for remote debugger. And yes, the message appears in dmesg and asl Aug 18 17:29:38 localhost kernel[0] <Notice>: IOKernelDebugger: registering debuggerAs for your link, I have seen many articles on debugging and also Apple's own pages but I would never have the time to try. And even if I did I don't have the knowledge to do anything once I'd got there. Maybe in another life 1 Link to comment Share on other sites More sharing options...
blackosx Posted August 19, 2015 Author Share Posted August 19, 2015 2.9.9b9 -> 2.9.9b10 - Renamed Firmware Log to Boot Log.- Fix audio dump from command line.- Add notification of any dumps affected by current SIP settings for OS X 10.11 and up. (Not working for Enoch yet but I work on that next.)- Delete backup .txt files created with generating html report.- Updated nvram tool to latest version with more known nvram vars.- Improved command line feedback for dumps requiring SIP disabled.2.9.9 will remain beta until El Capitan is released as things may change yet. EDIT: Attachment removed as newer version is posted later in the thread Link to comment Share on other sites More sharing options...
crusher Posted August 19, 2015 Share Posted August 19, 2015 This test on DP 7!!!! 1 Link to comment Share on other sites More sharing options...
blackosx Posted August 20, 2015 Author Share Posted August 20, 2015 Thanks for testing crushers. So just to confirm that path dialog box was correct as the save no longer existed? Link to comment Share on other sites More sharing options...
blackosx Posted August 21, 2015 Author Share Posted August 21, 2015 2.9.9b10 -> 2.9.9b11 Quick update since Apple blocked DirectHW with DP7. EDIT: Attachment removed as newer version is posted later in the thread Link to comment Share on other sites More sharing options...
magnifico Posted August 22, 2015 Share Posted August 22, 2015 Hi Nik what is this? Lol sorry resolved Link to comment Share on other sites More sharing options...
blackosx Posted August 22, 2015 Author Share Posted August 22, 2015 DarwinDumper saves any user settings to ~/Library/Preferences/org.tom.DarwinDumper.plist. This includes the save path used. If when loading DarwinDumper that save path is no longer available then you will see that dialog. Link to comment Share on other sites More sharing options...
crusher Posted August 22, 2015 Share Posted August 22, 2015 This is my results on DP 7 and csr to 0x01 Link to comment Share on other sites More sharing options...
blackosx Posted August 24, 2015 Author Share Posted August 24, 2015 2.9.9b11 -> 2.9.9b12 - Add detection of SIP settings for latest Enoch using info from bootlog. - Revert a previous change for removing temporary files created when converting files for html. - Add removal of tmp files which I tried to remove with above (failed) fix. EDIT: Attachment removed as newer version is posted later in the thread Link to comment Share on other sites More sharing options...
crusher Posted August 24, 2015 Share Posted August 24, 2015 I test with csr 0x01 and 0x00. Link to comment Share on other sites More sharing options...
magnifico Posted August 24, 2015 Share Posted August 24, 2015 I test with csr 0x01 and 0x00. DarwinDumperReports.zip Nik Sorry for OT @Crushers i have asrock z97 and I74790K if i use smbios Imac 15.1 dont work ...why? Can you atteched in my PM your config.plist ?? Link to comment Share on other sites More sharing options...
crusher Posted August 24, 2015 Share Posted August 24, 2015 Nik Sorry for OT @Crushers i have asrock z97 and I74790K if i use smbios Imac 15.1 dont work ...why? Can you atteched in my PM your config.plist ?? This is not problem on your specs. Your problem is GPU. Link to comment Share on other sites More sharing options...
magnifico Posted August 25, 2015 Share Posted August 25, 2015 This is not problem on your specs. Your problem is GPU. Ok..Nik sorry for OT Crushers Can u explain me with PM ?? Link to comment Share on other sites More sharing options...
blackosx Posted August 26, 2015 Author Share Posted August 26, 2015 2.9.9b12 -> 2.9.9b13 - Address difference with ecscaped spaces for file paths in El Capitan DP7. - Update SIP info for El Capitan DP7. - Add SIP icon to any dumps in html report to show they have been affected by SIP settings. EDIT: Attachment removed as newer beta is posted below Link to comment Share on other sites More sharing options...
Slice Posted September 13, 2015 Share Posted September 13, 2015 2.9.9b12 -> 2.9.9b13 - Address difference with ecscaped spaces for file paths in El Capitan DP7. - Update SIP info for El Capitan DP7. - Add SIP icon to any dumps in html report to show they have been affected by SIP settings. DarwinDumper_v2.9.9b13.zip Tested in ElCapitan GM. All OK! But where is boot.log? Found! AudioCodecID is wrong ---------------------------------------- VoodooHDA Codec: ATI R6xx HDMI [1002:aa01] Controller: Advanced Micro Devices, Inc. [AMD/ATI] Whistler [Radeon HD 6730M/6770M/7690M XT] Really device is 0:100 0:000 PCI (00|01:00.01) : 1002 AA90 class=040300 Link to comment Share on other sites More sharing options...
blackosx Posted September 15, 2015 Author Share Posted September 15, 2015 Hi Slice I see you've since discussed this in the getcodecid thread. Are you happy with the output shown in DarwinDumper? Link to comment Share on other sites More sharing options...
bajito93 Posted September 15, 2015 Share Posted September 15, 2015 Great job, its very useful Link to comment Share on other sites More sharing options...
Recommended Posts