So Long Lockdown!
Ian Whiffin
Posted: 8th February 2020

So long Lockdownd.log. It was nice to have known you and the data you housed.

For anyone who isn't familiar, Lockdownd.log was covered in my first blog post "KnowledgeC (and Friends)" and shows how that file contains important information such as boot up dates/times, iOS Updates and Passcode Changes (not the passcode itself, just the fact it was changed).

It was a useful little log file, albeit a bit of a pain dealing with Process ID's to find the boot up item.

But still. It served a useful purpose and appears to be the file of choice for tools to determine power on times etc.

However, I have found that on iOS13 devices this file appears to no longer be in use for what we in the forensic community have been using it for. #SadTimes.

However, do not despair. For, in the ashes of Lockdownd.log I found containermanagerd.log to replace it and decided this deserved it's own little blog post.

containermanagerd.log.?

Stored at private/var/root/Library/Logs/MobileContainerManager are the containermanager log files. Their name is appended with a sequential number. ie.

containermanager.log.0
containermanager.log.1

etc. But log 0 is the most up to date record with it being renamed to 1 when it is full.

It stores very similar data to Lockdownd.log. For example:

Sun Apr 21 18:34:05 2019 [60] <notice> (0x10021ebc0) -[MCMMigrationStatus isBuildUpgrade]: Current build version (16E227 / (null)) equal to last version recorded (16E227 / (null)); skipping upgrade
Sun Apr 21 18:34:06 2019 [60] <notice> (0x10021ebc0) main: containermanagerd first boot cleanup complete

Sun Apr 21 19:25:22 2019 [60] <notice> (0x102506bc0) main: containermanagerd performing first boot initialization
Sun Apr 21 19:25:22 2019 [60] <notice> (0x102506bc0) -[MCMMigrationStatus isBuildUpgrade]: Current build version (16E227 / (null)) equal to last version recorded (16E227 / (null)); skipping upgrade

Sun Apr 21 19:25:23 2019 [60] <notice> (0x102506bc0) main: containermanagerd first boot cleanup complete
Wed Apr 24 19:47:07 2019 [60] <notice> (0x100dfebc0) main: containermanagerd performing first boot initialization

Wed Apr 24 19:47:07 2019 [60] <notice> (0x100dfebc0) -[MCMMigrationStatus isBuildUpgrade]: Current build version (16E227 / (null)) equal to last version recorded (16E227 / (null)); skipping upgrade

Wed Apr 24 19:47:08 2019 [60] <notice> (0x100dfebc0) main: containermanagerd first boot cleanup complete

Of most importance, note the lines:

Sun Apr 21 19:25:22 2019 [60] <notice> (0x102506bc0) main: containermanagerd performing first boot initialization

Sun Apr 15 18:48:03 2018 [65] <notice> (0x1b6dc0b40) -[MCMMigrationStatus isBuildUpgrade]: Did not find last build info; we must be upgrading from pre-9.3.1 or this is an erase install.

Sun Apr 21 19:25:22 2019 [60] <notice> (0x102506bc0) -[MCMMigrationStatus isBuildUpgrade]: Current build version (16E227 / (null)) equal to last version recorded (16E227 / (null)); skipping upgrade

Wed Feb 13 13:22:19 2019 [60] <notice> (0x104e0ab80) -[MCMMigrationStatus isBuildUpgrade]: Detected upgrade from 16C101 ((null)) to 16D57 ((null))

As you can see;

Line 1 refers to the Boot Process of the device.

Line 2 suggests either a wipe or upgrade from earlier iOS.

Line 3 suggests no update has occurred.

Line 4 has found a software update.

*Note that the times shown are local to the device. You may also see clearly erroneous timestamps from devices which have lost power/network connection and therefore do not know the correct time.

So we can find out almost everything from Lockdown now in containermanagerd.log. #GoodTimes.

The exception (so far) is Passcode Change that I have not yet located.

What interested me the most is that on the phones I have looked at, containermanager has been there all along. It's always recorded this data it has just been ignored. When I ran my phone in the well known Forensic tools, neither found any power log information newer than early December and sourced the Lockdown file.

As another test, I ran a phone in ArtEx (using Lockdown) and also ran it in the new version of ArtEx which uses containermanager.

I ran both with Start / End dates well outside of the limits of the device and I found that whereas Lockdown went back to 28th September 2018 and logged 23 Boot sequences, containermanager went back an additional 5 months to April 2018 and resulted in a total of 44 Boot sequences.

 

Wrapping Up

As mentioned in the write-up above, ArtEx now parses containermanager data where appropriate and this results in more power on records than before. I'm sure it's only a matter of time until other tools catch up ;)

Thank you for reading! Don't forget that ArtEx can be download FREE from the 'Software' section of my site.

Previous Article
"Apple Pay Transactions"
Next Article
"iOS Mail"
Search
Social