search

Velocidex / c-aff4

An AFF4 C++ implementation.
http://docs.aff4.org
Apache License 2.0
187 stars 35 forks source link

osxpmem, Loading/Unloading kext #21

Closed hoyt-harness closed 6 years ago

hoyt-harness commented 6 years ago

I posted this to the working group, but may be better off here with more administrative issues over there. Also tl;dr material... sorry.

Here's a rundown of my testing of the latest AFF4/osxpmem binary for MacOS/APFS so far (also, this is for mem capture, not logical imaging):

Macbook Pro MacOS High Sierra 10.13.4 APFS (HFS+ on the MACTOOLS volume and ExFAT on the EVIDENCE volume)

I put the osxpmem.zip in an HFS+ formatted volume on an external HDD labeled MACTOOLS, along with the test directory scheme I used for the linpmem tests. This HDD also has a volume labeled EVIDENCE (ExFAT) and I put a /test_mac directory there to catch output. I also set the OS to not ignore ownership on the MACTOOLS volume. I first unzipped the archive:

$ unzip osxpmem.zip

...then checked ownership:

$ ls -Fla total 2929 drwxr-xr-x 9 hharness staff 306 Apr 20 09:01 ./ drwxr-xr-x 11 hharness staff 442 Apr 20 08:30 ../ -rw-r--r--@ 1 hharness staff 6148 Apr 20 09:01 .DS_Store drwxr-xr-- 6 hharness staff 204 Feb 9 00:03 osxpmem.app/ -rw-r--r--@ 1 hharness staff 1562910 Apr 19 17:11 osxpmem.zip -rw-r--r--@ 1 hharness staff 20 Apr 20 08:28 singlefile.txt drwxr-xr-x 6 hharness staff 204 Apr 15 17:34 testdir/

I changed ownership as follows:

$ sudo chown -R root:wheel osxpmem.app

I ran it using:

$ sudo ./osxpmem.app/osxpmem -o /Volumes/EVIDENCE/test_mac/macram.aff4

This gave the following results:

2018-04-20 09:17:18 E Can not open file /dev/pmem: No such file or directory /Volumes/MACTOOLS/MACTEST/./osxpmem.app/MacPmem.kext failed to load - (libkern/kext) system policy prevents loading; check the system/kernel logs for errors or try kextutil(8). 2018-04-20 09:17:19 E Unable to load driver at /Volumes/MACTOOLS/MACTEST/./osxpmem.app/MacPmem.kext 2018-04-20 09:17:19 E Imaging failed with error: -8

I went ahead and tried to load the kext manually and got this:

$ sudo kextutil osxpmem.app/MacPmem.kext

Kext rejected due to improper filesystem permissions: <OSKext 0x7fa0a9466e40 [0x7fff87d33af0]> { URL = "file:///Library/StagedExtensions/Volumes/MACTOOLS/MACTEST/osxpmem.app/MacPmem.kext/", ID = "com.google.MacPmem" } Diagnostics for osxpmem.app/MacPmem.kext: Authentication Failures: File owner/permissions are incorrect (must be root:wheel, nonwritable by group/other): /Library/StagedExtensions/Volumes/MACTOOLS/MACTEST/osxpmem.app/MacPmem.kext Contents _CodeSignature CodeResources MacOS MacPmem Info.plist

I did add the security exception for the kext signed by Adam Sindelar. See here: https://developer.apple.com/library/content/technotes/tn2459/_index.html

Checking ownership again:

$ ls -Fla total 2929 drwxr-xr-x 9 1000 1000 306 Apr 20 09:14 ./ drwxr-xr-x 12 1000 1000 476 Apr 20 10:00 ../ -rw-r--r--@ 1 hharness staff 6148 Apr 20 09:14 .DS_Store drwxr-xr-- 6 root wheel 204 Feb 9 03:03 osxpmem.app/ -rw-r--r--@ 1 1000 1000 1562910 Apr 19 17:11 osxpmem.zip -rw-r--r--@ 1 1000 1000 20 Apr 20 08:28 singlefile.txt drwxr-xr-x 6 1000 1000 204 Apr 15 17:34 testdir/

I escalated with sudo su, navigated through osxpmem.app, and confirmed the owner:group and nowrite for group/other was set properly. So, ownership shouldn't be the issue and neither should system policy prevention based on user approval. The message I received by attempting to run osxpmem allowing it to autoload the kext gave an illegal path of /Volumes/MACTOOLS/MACTEST/./osxpmem.app/MacPmem.kext (see above). I don't know where this path is coming from, but might be a clue if that's what it's actually trying to follow. It doesn't explain the error message when trying to load the kext manually with kextutil.

hoyt-harness commented 6 years ago

SOLVED: The issue mainly had to do with permissions. On the test machine, I wget'd the Version 1.0 release of osxpmem to an attached external drive formatted HFS+, unzipped it, and ran chown && chmod for root:wheel and 744 against the contents of osxpmem.app. In my previous post above, I had downloaded the zip'd release to my Linux workstation and added it to the external drive from there and this is where the problem lies, I think.

Anyway, it runs like it's supposed to now, except for the fd memory issue during logical imaging since osxpmem didn't get rebuilt for the Version 1.0 RC2 release.

hoyt-harness commented 6 years ago

Also, I should mention that I did still have to manually load and unload the kext (kextutil & kextunload), along with the manual permissions change. This is related to commit #14 .

hoyt-harness commented 6 years ago

I'm closing this for now as the primary issue has been addressed, along with the fd leak. It might be better to further test commit #14 via a separate issue.