Mobileactivationd
Ben Hollinbeck
I was looking at my activity monitor when I noticed a process called mobileactivationd. It appears to be running under the root user so I'm assuming it has significant privileges. A quick search yielded results about jailbreaking and bypassing security measures on phones. I literally factory reset my Mac yesterday, haven't installed anything even remotely suspicious, and have never done anything with jail breaking. All I'm looking for is some information on this process (there doesn't appear to be any readily available) and whether or not it's part of macOS. Any thoughts would be greatly appreciated!
You can manually do this by going in through the registry and looking at the mounted devices, or the Setup.api.dev.log file. In Inspector, we show this under the Device Connections in Actionable Intel.
Keep in mind that it needs to be adjusted to local time. You can then add up all the Distance Travelled entries for the day which will give you the answer. Rather than manually adding them all, you could also just export the entries as an excel and do a simple =sum command to calculate it all for you.
Sharing of pictures can occur in various ways. Since we know the image we are looking for, and we know it was shared, starting off in the Chats, and searching for the image, we can see that it came from Marsha. There are two source files listed, and one was your answer.
This one could be easy if you let the tools help you. First, you need to find the numbers for Marsha that were used. You can then filter the call logs based on those numbers for that date. Next, go to location data to see if there are any corresponding location points at that time. That would bring you to the answer.
Now, what if there was a way to collectively look at all the relative data in a simple view? How about the timeline? It holds quite a bit of data. You can pick your time frame, then the artifacts you are looking for, and there is your answer.
Once you got to the database you could find the answer. If you looked up Telegram prior to diving into the database, you knew the name of the app is ph.telegra.Telegraph. kTCCServiceLiverpool is used for location and Ubiquity is used for iCloud.
What we were looking for here was the cpl_enabled_marker file. This file notes when iCloud Photos was turned on. The file is located at /private/var/mobile/Media/PhotoData/cpl_enabled_marker. You did need to tweak the time to reflect the requested time format.
This one is not an easy one. The way we got to this was by going through crash logs. There is no easy way to do it. If you look at /private/var/wireless/Library/Logs/CrashReporter/Baseband/log-2021-05-07-stats.plist you can see there was an entry where a crash log was created and it lists the iOS on the device at the time.
There were much easier ways to get to this answer, you could have looked at /pirvate/var/mobile/Library/mobileactivationd/ log files, as well as the lockdown logs. Health data often stores iOS versions as well.
This question was meant to be a curveball. This one should have led you to passes23.sqlite file. It was empty, hence no cards were saved to the wallet. Ian Whiffin wrote a great blog post about payments using Apple Pay.
Beth starts to crank up the heat here. Sure, you could have mapped the locations of the device where it was, and cross-referenced the update on the previous question when we talked about the iOS version. This is often an overlooked source of location data in Health.
If you look at the healthdb_secure.sqlite (remember you need an encrypted backup or a Full File System to get this file), there is a table data_provenances that lists each version of the device and related time zone.
Research never ends in DFIR. Scott Koenig did a great write-up about this specific topic. It should have led you to /private/var/mobile/Library/UserConfigurationProfiles/PublicInfo/PublicEffectiveUserSettings.plist.
If you got the answer to the previous question, you read the blog and should have known that you were looking for an answer in the same file. You were looking for the value for maxGracePeriod which was 0.
For this one, we applied a few filters. First, we went to System, System Logs and then filtered on 2021-07-20, which does not reveal the correct time in the question. We must convert to UTC to get the correct answer.
The researchers said they discovered they could build a hostile Wi-Fi network that would force Apple devices to download time and date updates from their own (evil) NTP time server: And to set their internal clocks to one infernal date and time in particular: January 1, 1970.
Harrigan and Kelley say exploiting this bug on an Apple iPhone device is slightly trickier because iPhones get their network time updates via GSM, the communications standard the devices use to receive and transmit cell phone signals. But they said it may be possible to poison the date and time on iPhones using updates fed to the devices via GSM.
This is not quite correct. There are ways to recover from doing something as stupid as this. A DFU restore will usually fix it, and, if not, running the battery all the way down or disconnecting it for a few seconds will allow recovery. Apple Stores have been disconnecting the battery for phones brought in with this problem for over a month (and not charging for the service). And the 9.3.1 update was 2 weeks ago.
With the NTP version of this attack, it does not restore as the previous versions might have. Ourselves and Apple engineers left devices unplugged for days. It did not allow DFU mode. It did not permit a restore. The devices continued to sit on worktables are increase in temperature. We used multiple laptops, multiple devices and multiple images. Our collective assessment was that the device keeps running and will not permit any sort of hard shutdown.
To be fair, that could be read as incrementing backwards from January 1st, 1970 and not incrementing backwards from the current date to 1970 and beyond. If you notice they talk about how it reached 1968 and 1965, which could mean the increment started at 1970.
5. The network is only considered familiar if it passes this challenge. If it does not prove knowledge of the private key, or the public key is unknown to the phone, the network is considered unfamiliar on that occasion.
However, setting to the January 1, 1970 date is special. That date is the Unix Epoch because dates are represented internally with a signed integer (originally 32-bit). That value is all zero bits. Apparently NTP then failed to notice it was already at the low bound of the data type, and still tried to decrement. Then, perhaps (since a negative number turns on the high bit of the data type to represent the sign), NTP was doing an Unsigned comparison with a signed number (bad but common mistake for programs written in C/C++). This would cause it to think it had not yet reached the target date, and keep decrementing below January 1, 1970.
I suspect it was the infinite loop triggered by this bug that caused the hard freeze, rather than the certificates being invalidated. But the certificates being invalidated did mean that critical system software was unable to run (and that makes it practically impossible to recover from the hard freeze).
I guess this is, for the millionth time, where we demand that Apple will finally add the basic function of letting us manage the list of known network SSIDs to iOS. I mean seriously, how is it that my phone due to backups and restores still connects to networks that have the same SSID as the hotel wifi from a vacation in 2010??!
WiFi devices connect by WiFi MAC address not only by Wi-Fi network name. If MAC address is different, iPhone notifies and asks user to join new network. Therefore, you have to spoof exact Wi-Fi spot mac address, not just a common Wi-Fi name to connect seamlessly.
The flaw, which appears to have been caused by a bad compare between an unsigned 32-bit time and a 64-bit time, as it only affects 64-bit devices running iOS 8.0 or later, which would limit it to the iPad Air and later and the iPad mini 2and later. iOS devices with a valid SIM card would appear to be immune to the NTP hack as iOS prioritizes time sync from NITZ (for GSM) and CDMA2000 services.
The iOS 9.3.1 update only had changes to swcd, SharedWebCredentials.framework, symptomsd (all for the links bug), and mobileactivationd (for the iCloud activation bug present on iOS devices released in 2013 or earlier). It had no other changes.
The video this article links to was originally filmed on February 24th, as you can see by the date in the one console. This is before the release of iOS 9.3, so the iPad appears to be running running iOS 9.2.1, not iOS 9.3.
While NTP itself is known to be insecure, desktops and laptops will filter out bogus servers if they follow the recommendations in the NTP RFCs. Such as using more than one time server and/or also using dates embedded in response packets. The other common method is to ignore dates that occur before a certain event.
This will be an update to Local Photo Library (LPL) Photos.sqlite decoding as the result of a DFIR Discord community member question. As the blog title hints, the research being updated is related to what the data might look like within LPL Photos.sqlite when an iPhone, and possibly other Apple devices, are used to transfer data to another iPhone, or Apple device, during a new device set-up.
The artifacts discussed within this blog, like many other digital forensic artifacts, are only pieces to a larger puzzle. Data discovered during a digital forensic examination and analysis should be used in conjunction with other investigative leads to build the puzzle. Any data uncovered during this process can aid investigators in identifying additional devices related to the investigation and ask deeper investigative questions.
During this research, I was able to replicate what was observed in the case data within test devices data after one test. Due to what was required to set up the test devices, I was only able to test this twice with the same devices. I would like to remind everyone if this data is critical for your investigation, please take the time to mimic these steps and conduct additional testing.
ff7609af8f