Starting with iOS4 the call history database was moved to
“/private/var/wireless/Library/CallHistory/call_history.db”.
When performing a logical extraction the database is usually found in the “Files” section.
We suggest extracting the “call_history.db” file and then manually inspecting it with a SQL database browser, for instance SQLite Expert Personal (freeware), which can be found at
http//
If you are still having problems then please contact our support - support@msab.com
Micro Systemation.
JZ's tools allow the low-level (security means almost nothing) bit-for-bit imaging of the full device without making any changes to the device minus the memory that it is loaded into.
Just so there is no mistake JZ's tools, regardless of iOS version, only makes a image of the Data Slice (partition) NOT the full device. So you will not get the system slice. That said, however, 98% of what you want in an investigation is located in the Data Slice.
Drew
On a side note has anyone found the calls.db on an iOS 4 device?
When we perform a logical extraction (using .XRY 5.3) the database appears to be located at
private/var/wireless/library/callhistory/call_history.db
On the file system extractions we don’t get the ‘wireless’ folder so cannot seem to recover the call history database. Is this a known issue that anyone else has come across?
If by "file system extractions" you mean a device image of the data partition, then the directory "private/var/wireless/library/callhistory" can be found in "wireless/library/callhistory". You can verify this by using for instance
On a live system this file directory mapping is accomplished through (Unix) mountpoints.
Johan
When I say "file system extraction" I mean the use of JZ's iOS4 tools to recover the file system in a tar archive.
I have noticed that all the iOS4+ extractions we have performed on the Linux box are failing to fully recover the file system. It particular the scripts are not recovering the "private/var/wireless/" folder, which means we are not able to recover the call logs when using JZ's tools.
Has anyone else come across this?
I would like to follow up on the comments on page 2 of this thread regarding iXAM, as I do not wish users to be mis-informed.
There has been only one report to us of an iPhone stuck in a 'recovery loop', so it is known which customer is being referred to. The reported issues were discussed at the time with the end user and it was accepted there had been user error in connecting the device.
The iRecovery log we were sent said there was an issue with the boot section of the operating system.
iXAM does nothing that touches the operating system part of the phone.
Unfortunately, occasionally iPhone’s do just go wrong and that seems to have been the case here. Certainly we have not heard anything from the end user to the contrary.
It's worth noting iXAM has been independently tested and verified by both NIST and viaForensics in the USA.
Should there be any further questions we will be happy to assist you. Please use the email address on the iXAM-Forensics.com website.
Thanks