This EnScript decodes binary and XML plist files that are extensively used by Apple computer software and hardware to store configuration data.
Binary plists support data in the form of ANSI & Unicode strings, integer numbers, UIDs, Boolean (true/false) values, floating point numbers, binary data and dates/times.
XML plists support data in the form of Unicode strings (encoded as UTF-8), integer numbers, Boolean (true/false) values, floating point numbers, binary data and dates/times.
The user has the option of choosing how the script should iterate through the case; he/she can also choose which files are actually processed based on a combination of signature, extension and name. The recommended options are marked with an asterisk (*).
Note that the script must be executed from the Evidence>Entries tab in order for it to correctly identify the data to be processed.
The examiner can choose to create a single data bookmark containing the data from all of the source files; alternatively he/she can choose to create a data bookmark per file.
With regards to binary plist values, the content and format of such data is in the hands of the developer who created the plist file. That notwithstanding, such data will often contain text strings (encoded as ANSI or Unicode) that contain important evidential data; it may also contain embedded file content that requires external processing (such as the SQLite database files used on the iPhone and iPod Touch).
Notwithstanding that embedded binary plist streams will be parsed automatically and in a recursive manner, the EnScript offers two options for viewing other types of binary data.
By default, if binary data is less than or equal to 512 bytes, it will be bookmarked as string data. In order to accomplish this, one or more continuous non-printable characters will be replaced by a single '·' character. This is sufficient to remove excessive amounts of unintelligible binary data while still allowing Unicode strings to be recognised as such. The examiner should however be aware that two readable strings separated by a single '·' character could be many bytes apart.
A second option is to have the script write the interpreted plist files into a logical evidence file. The data in the file is structured in a very similar way to the data bookmark already mentioned above. The only difference is that each plist name/value pair is represented as a file. For all but binary plist name/value pairs the data is stored in the file as a Unicode string. Binary plist data is written as is; this facilitates signature and hash analysis; it also enables the examiner to extract binary data streams for processing with 3rd party applications.
The script will recognize plists that are NSKeyedArchive files automatically and resolve their internal links, which are implemented through the use of UID values.
The structure of NSKeyedArchive files that are plists can take some getting used-to particularly as both have their own type of dictionary. A dictionary is a list containing one or more child objects each having a name.
In a plist file, an NSKeyedArchive dictionary will consist of three plist folders: NSKeys, NSObjects and $class. The $class folder will contain an entry called $classname, which will have a value of NSDictionary or NSMutableDictionary.
The values in the NSKeys and NSObjects folders are linked such that the name of the object at position n in the NSObjects folder will be at position n in the NSKeys folder.
NSKeyedArchive files also support two types of array: NSArray and NSMutable array. Items in an array are identified by their index, which means that an NSKeyedArchive array will only consist of two folders: NSObjects and $class. The NSKeys folder is not needed.
Timestamps are displayed as UTC/GMT. This assumes that the underlying value is also stored as UTC/GMT rather than local time.
YOU MAY ALSO LIKE