PLease could someone advise me whether its possible to conduct analysis on captured data from macbook using encase in a windows environment,
i have managed to image the macbook but want to know if i can do a keyword searches across all the captured data
can deleted folders be rocovered as in windows
can compund files (zip etc) be mounted and searched
any help would be appreciated as iam not familair with macintosh computers at all
All my research leads me to believe that deleted catalog entry on a Mac is deleted. On a PC it is marked as deleted but the entry on the Mac is cleared. The files still exist as raw data, but the directory / catalog entry does not.
Can others confirm this point?
As far as I can tell, the Catalog B-tree is reorganized after files or directories are deleted, overwriting the entries for the deleted items. There seems to be a temporary intermediate state where the entry is rendered invalid but is still present in the B-tree, but this seems to only be the case on live systems. It may be possible to find the data for deleted Catalog entries after the end of a list in a B-tree node or in unused nodes
As far as I can tell, the Catalog B-tree is reorganized after files or directories are deleted, overwriting the entries for the deleted items. There seems to be a temporary intermediate state where the entry is rendered invalid but is still present in the B-tree, but this seems to only be the case on live systems. It may be possible to find the data for deleted Catalog entries after the end of a list in a B-tree node or in unused nodes
This is correct. The catalogues are rearranged to maintain the 'flatest' tree structure possible to speed up parsing while locating the file's on-disk address. This will generally mean that the deleted file names are overwritten in the catalogue leaf nodes. Sometimes the old entry will be in there but this is fairly rare. Encase will sometimes show a deleted file name from the catalogue but the address will be pointing to an active file so be careful about names and examine the contents at the offsets. You should pay particular attention to the inode information (Encase puts this in the file identifier column) for the files as this is information that is unique to each object and provides a better way of id'ing the file than the name as the inode number is persistent and will only be used once for each volume ( does not repeat for a different file or roll over, this value is incremented in a 4 byte field in the Master Directory Block when files/objects are written). In the old days you could usually get the names from the data fork but this doesn't necessarily work in HFS+.
Well, the B-tree depth doesn't change much, but each node is a linear list of multiple entries, so when an item is deleted from the middle of the list, the later entries are moved forward. (You also have B-tree node rebalancing if they get too long/short.)
While rare, note that Catalog Node IDs (inode numbers) *can* be reused if the current CNID hits 2^32. (In this case, a bit in the volume header is flipped indicating that this has occurred. This is very uncommon, particularly since some low-level software doesn't handle this case properly!)
While rare, note that Catalog Node IDs (inode numbers) *can* be reused if the current CNID hits 2^32. (In this case, a bit in the volume header is flipped indicating that this has occurred. This is very uncommon, particularly since some low-level software doesn't handle this case properly!)
Yes it is *very* rare. In 16 years I have never seen it roll-over, nor have contacts of mine at Blackbag or in the RCMP.
You are talking about 4294967296 objects.
Yes, it only really matters if you're writing software that will operate on an HFS+ partition, in which case you should check for the flag (for the very rare case that this occurs). As an investigator, you're not realistically going to see it happen. Fortunately, checking the flag manually can assure you that CNIDs have not been reused.