I had Cellebrite analyze an iPhone 5 that was not passcode protected. The timeline reports a short series of SMS messages (about 10) that date back to November of 2005, before immediately going to a 2013 date range. What could cause this anomaly?
Do you work in a optus/telstra/allphones store? I know some people that do. Perhaps I can ask them to do what you have and get back to you with the results (I haven't actually used a cellebrite, just provided very minor support in updating them)
Do you work in a optus/telstra/allphones store? I know some people that do. Perhaps I can ask them to do what you have and get back to you with the results (I haven't actually used a cellebrite, just provided very minor support in updating them)
No, I actually work in Southwest USA. Thanks for the offer, but I need my answers before I have to go back up on the witness stand tomorrow.
If it makes any difference, nearly all of the SMS messages (including the ones with the odd dates) were deleted.
Well as iPhone 5 was launched in September 2012; as a hunch I would hazard a guess that these messages perhaps where not generated on the iPhone 5 back in 2005, which tends to open up a guessing game as to suggested possibilities.
pnares below are some guesses (but not made to cast doubt on your work)
We don't know if the messages are sent or received?
We don't know if the dates are from the phone's clock or network clock?
We don't know if the user had accidentally/deliberately backdated the phone's clock?
Maybe the deleted data has been misread or something lost in translation?
Maybe the deleted data compromises in its composition more than one text message?
As we don't know the originator of the data what if the iPhone 5 was secondhand and you are seeing previously deleted data from another user?
etc
etc
One procedure you may wish run through by yourself (or you may have already done it) is define how text messages usually appear in iPhone 5 e.g how they are stored (random or threaded) and also the allocation of date and time stamps?
Consider also how text messages are deleted and the deletion of the logical entry such that a user no longer sees the message that was stored as opposed to how the physical data can still remain e.g. which part of the file header gets deleted?
What if the data recovery system you are using, through no fault of its own, is presenting the data factually but maybe a nibble in the date/time stamp value has been corrupted so as to present a false positive?
As you mentioned these are deleted entries.
It is possible that the date portion of the message was overwritten and the result you got are false positive.
When dealing with deleted entries that were recovered, you always have to validate and look how it is stored in hex whenever it is possible ( UFED PA gives you that option )
There are different possibilities to why this is happening. One is the changes in the entry formats that Apple is doing in different iOS versions and when recovering from unallocated area, it can produce such false positive results.
Ron
Of course the possibility of a false positive also opens up (as I did not mention it in my first post) the invitation to verify and validate the same data but with other tools to see what results the other tools produce.
Varying entry formats in iOS, if this were suggested at trial, there might perhaps be an expectation or an anticipation that you might expect to be asked at court did the other tools produce the same results?
What type of retrieval was done? I recently retrieved data from an iPhone 5 bot as a logical and a file system acquisition. The logical had no SMS, the file had 426 deleted SMS.
Eric