Has anyone run across a newer Apple laptop with the Apple Silicon M1 chip and successfully imaged it? I have the password, I've tried using Digital Collector (MacQusition), ADF, and booting the device to Target-Disk mode which seems to no longer be a capability of these newer laptops.Â
Hi,
Target Disk Mode is no more on the Apple Silicon M1 Mac’s.
Apple have taken the approach of what they call Share Disk:
https://support.apple.com/en-gb/guide/mac-help/mchlb37e8ca7/11.0/mac/11.0
Which uses SMB via a cable connection to another Mac.
Good Morning,
I am hoping this post will "reactivate" this page. I have an Apple Macbook Pro with an M1 chip running macOS Big Sur v11.2.3. I have digital collector that I know doesn't support a physical acquisition.
Â
I am wondering if anyone has a work around, or instructions on obtaining a logical image? When I choose to image the APFS file system, I get a long warning that prompt me to type in "accept risk". Is this option okay to use?
Â
All insight is helpful, thank you!!
Steve
Has anyone run across a newer Apple laptop with the Apple Silicon M1 chip and successfully imaged it? I have the password, I've tried using Digital Collector (MacQusition), ADF, and booting the device to Target-Disk mode which seems to no longer be a capability of these newer laptops.Â
Here is how Sumuri with their RECON ITR approach the problem:
https://sumuri.com/how-to-image-an-apple-silicon-mac-with-recon-itr-live/
Â
@mokosiy Thanks! I am actually working with them as their solution isn't working as of yet.
I struggled through a MacBook Air M1 (Big Sur) last week. Started with a live targeted collection to grab the user dir. It was screamin' fast for quite a while (was writing 4GB segments in 1 min vs 30 min on a 2018 MacBook Pro I was collecting at the same time), then slowed to a crawl and at the rate it was going, would have taken over 200hrs to finish the last 6 GB. I couldn't wait that long so after a couple hours to see if it changed, tried to just image the whole thing via booting to Digital Collector/MacQ and found out that was a no go. The info I found in trying to sort that out pointed to M1 Macs only being able to boot to a full licensed Mac OS vs the modified OS on Digital Collector. I then tried the SMB (new version of Target Disk Mode), connected to a 2015 MacBook Pro running Mojave. With the User passcode I was able to unlock the M1 Air's disk and see it in Finder. I could see the user dir that I needed to collect, but it was greyed out and I could not access it. Neither Finder nor Digital Collector could access it. I ended up reverting to live imaging with Digital Collector but searched for the documents needed and just imaged those logically instead of the whole user dir. I'm not sure if having my machine running Big Sur would have helped. I've just started messing with Big Sur via dual boot on my Macs (not M1) and seen the "Incompatible Disk" messages, but haven't had time to look into that. Perhaps the imaging Mac needs to be an M1 Mac as well to access the user dir via SMB. I did not have time to test anything else, but I am anxious to hear what the solution is when someone comes across it.
@opie328 So, I am still working on this project. Huge headache. I received a trial of RECON ITR from Sumari. It was able to get a logical sparse image, but in order to do so, you must boot the suspect mac and connect it to the internet (to use demo). This may not be ideal for most depending on the evidence. The sparse image completed successfully, but isn't recognized as an image type by AXIOM, FTK, or EnCase. Forgive my ignorance, but if I can't open an image with any of my tools, it is quite useless. I went back to RECON and attempted a DMG-RW image, but failed. I resorted to the last option which was a logical file capture. This was successful in creating a 260GB export of the file structure. I am now creating an L01 of that export to maintain it.
Â
I will follow up to let y'all know if AXIOM processes it correctly.
Â
Anyone have insight on the sparse image review?
@steveyo412 Speak to Cellebrite, they will email you the instructions for the logical capture. ive been struggling with it all day, but its not overly complicated. You'll need user credentials. Â
Hope I got a solution for this problem with the help of collector. Though we cannot take full physical imaging of the hard disk (bcoz of apfs, file vault etc ) but logical image of the data volume could be carried out which found out to be revealing much info. Will host the whole documented procedure soon.
Hello guys, I've been also interested if there is currently any valid alternative to full forensically sound image of a MacBook M1 (dead acquisition)?Â
Are there any updates and good news on the topic?
Below is what I've currently have researched and experimented so far, which I will be updating on my website if I come up with any new ideas ( https://bakerst221b.com/docs/dfir/investigation/collection/mac/#research).
Here is the state on 4th July 2022.
Share Disk is very different from Target Disk and is relatively useless for forensic purposes (from what I've seen by now). Share Disk, unlike its preceder, operates over SMB protocol and is not mounted like a normal drive. In fact,
diskutil list
(or its GUI version Disk Utility), [Disk Arbitrator]( https://github.com/aburgh/Disk-Arbitrator) (custom tool) or even
ls /dev/ | grep disk
won't show it. It seems that its mounting is not really governed by diskarbitrationd (framework for mounting and managing drives). Even though in GUI it looks like it's mounted, different APIs seem to be in place.
I've tried creating a file `/etc/fstab` and using custom settings for mounting my test USB drive:
LABEL="TestDrive" none apfs ro,noauto
This USB device was not automatically mounted, and when I mounted it manually, it was in read-only mode (`ro` option). I did the same for the Macintosh HD, which is the label for my drive on target MacBook.
LABEL="Macintosh HD" /suspect apfs ro,noauto
Just in case I acquired the volume's UUID viaÂ
diskutil info /Volumes/Macintosh\'s\ HD | grep -i uuid
from both the recovery mode and when booted normally (which were different).
This is basically a network share and you have pretty much the same rights as the user of that PC. I don't know yet if there is any way to control the restrictions here, but at the moment the most forensically sound way would be to use a physical write blocker. This [tool]( https://sumuri.com/how-to-image-an-apple-silicon-mac-with-recon-itr-live/) from SUMURI is for Live acquisition only. So, are there any currently forensically sound methodologies for performing dead acquisition? Getting raw disk image (that would also get slack and unallocated space as well)? Thanks!