Call History about inflatabledonkey HOT 18 CLOSED

Well spotted sir. It looks like call_history.db was changed a while back. I've altered the filter to callhistorydb which should dump out the contents of that folder. I've just pushed a new build. Kindly let me know if the issue persists.

from inflatabledonkey.

Now if I set --item-type to CALL_HISTORY it would properly download folder with call history files.

But that was not a serious issue as I could set extension and domain and download whatever I want :) The real problem is that this file does not change after first snapshot. It is still from 2016-08-11 while latest snapshot is 2016-08-21. I've found that only for call history file for the moment, all other downloaded files seems to be up to date.

from inflatabledonkey.

Ok, have any files changed at all in the calldbhistory folder? Are there new files present? Are you able to confirm the latest recovered snapshot calldbhistory folder ties in with the calldbhistory folder on your device?

As far as I'm aware call history is based around SQlite which may create additional files that are merged periodically.

As a side note I can confirm my house mate's calldbhistory folder updates without any issues across the various snapshots.

from inflatabledonkey.

Look, here is two folders from different dates/snapshots:

From 20160811

-rw-r--r-- 1 xxxxxxxx staff 290816 11 aug 20:50 CallHistory.storedata
-rw-r--r-- 1 xxxxxxxx staff 36864 11 aug 20:50 CallHistoryTemp.storedata
-rw-r--r-- 1 xxxxxxxx staff 298 11 aug 20:50 com.apple.callhistory.databaseInfo.plist

From 20160821

-rw-r--r-- 1 xxxxxxxx staff 290816 11 aug 20:50 CallHistory.storedata
-rw-r--r-- 1 xxxxxxxx staff 298 21 aug 15:15 com.apple.callhistory.databaseInfo.plist

As you can see, CallHistory files identical but from 2 different snapshots (10 days difference). Content of this files also same. And as you can see - date also. As I mentioned above, for sms.db files - all is fine. This calls data files seems to be some kind of exception case.

I've downloaded whole folder with all call history files inside, i.e. using --item-type CALL_HISTORY.

from inflatabledonkey.

Interesting. What does the calldbhistory folder on your iOS device look like?

from inflatabledonkey.

I've some calls every day on my iOS device. The folder content as it is retrieved from iCloud by InflatableDonkey is exactly as I wrote in previous message with directory listings. Today I'd run backup device to icloud again and check if anything would change.

from inflatabledonkey.

Seems like new backup arrived. Here is a folder from 23 of August:

-rw-r--r-- 1 xxxxxx staff 290816 11 aug 20:50 CallHistory.storedata
-rw-r--r-- 1 xxxxxx staff 298 23 aug 14:57 com.apple.callhistory.databaseInfo.plist

As you could see - it is same again. You could also see that "com.apple.callhistory.databaseInfo.plist" file date is 23 aug (not 11 aug!)

from inflatabledonkey.

Also, my list of snapshots looks like this:

SNAPSHOT: 19 GB iPhone (xxx) (iOS 9.1) 2016-08-13T22:56:15.163Z
SNAPSHOT: 3647 MB iPhone (xxx) (iOS 9.1) 2016-08-21T18:42:19.475Z
SNAPSHOT: 142 MB iPhone (xxx) (iOS 9.1) 2016-08-23T19:26:22.887Z

First snapshot now set as "2016-08-13". Before today's backup it was from 11 of August.

from inflatabledonkey.

Ok. I still need to know what the calldbhistory folder looks like on your iOS device. Is it different from the retrieved folder and in what way is it different?

On the possibility of hidden files being present, I would also try

ls -al

on the retrieved folder and on your iOS device so we can make a comparison.

from inflatabledonkey.

Could you please suggest how can I check that on iOS device itself? Not sure if it is possible on non-jailbroken device.

from inflatabledonkey.

Downloaded folder:

ls -la
total 576
drwxr-xr-x 4 xxxxxx staff 136 23 aug 23:36 .
drwxr-xr-x 3 xxxxxx staff 102 23 aug 23:29 ..
-rw-r--r-- 1 xxxxxx staff 290816 11 aug 20:50 CallHistory.storedata
-rw-r--r-- 1 xxxxxx staff 298 23 aug 14:57 com.apple.callhistory.databaseInfo.plist

Seems like no hidden files there. Is it possible that your updated snapshot filtering mechanism could influence on that?

from inflatabledonkey.

Thank you. I don't think you can open a root terminal on an non-jail broken device, then again I could be wrong.

It is possible that we have an issue with the retrieval process and more specifically within our filtering mechanism. Without a side to side comparison of the files present on the device and the files that have been recovered we have a more difficult task in regards to diagnosing the issue. If I can spare the time over the weekend I'll take a look at the filtering code again.

The other possibility is that the files have been retrieved just fine and we are barking up the wrong tree.

I'll let you know if I glean any more information over the weekend.

from inflatabledonkey.

Hi guys, just want to give you some update from my side. I've found that the log of very latest calls could be found inside CallHistoryTransaction folder inside transaction.log file. It has very funny encoding. First 4 bytes - payload length, then you got bplist (binary plist). Inside bplist there are field with another bplist, which already contains list of last calls. I'm still not sure that this list could be decided as complete (I'm afraid that there are some lost calls between callhistory.db and transaction.log) - so, if @horrorho would find some timeframe to take a look at this issue - that would be great.

from inflatabledonkey.

Hi. I'm still not clear if this is a data retrieval issue or a data handling issue post-retrieval. Are you telling me that the files have been retrieved improperly or that the files have been retrieved properly but you're unsure as how to handle them? Two very different things.

Without further information or having the benefit of examining these files, the 'very funny encoding' sounds like a chunked plist type which is also used in things like photo streams. You may have a number of sequential plists present, each preceded by a payload length. Just double check you have them all and that the sum of the payload lengths match the file length.

I also cannot replicate the issue with my house mate's iOS 9 phone. There are no transaction.log files. Are you using iOS10?

from inflatabledonkey.

I don't want to say in my previous message that files have been retrieved improperly. I just said that I've found a place where latest calls could be found, and yes - I work with iOS 10 on that. When I said about 'funny encoding' that was just my amazement on the way how apple store that info - it is definitely properly downloaded as I could normally decode its binary format with mac os tool "plutil". Most of my worries about "callhistory.db" and "transaction.log" does not include ALL calls history data. I'm still working on investigation of this info to be 100% sure on that.

from inflatabledonkey.

Ok, it sounds like more a digital forensics issue and not a file retrieval issue. This is outside the remit of InflatableDonkey. If at some point I get an iOS10 backup and free time I'll take a look at it, but it's low on my priority list. You could try asking about it on apple.stackexchange.com.

from inflatabledonkey.

@horrorho , @ajlyakhov
Is it fixed?
For some icloud bkp I am getting callhistory db for first snapshot. But rest two are empty in wirelessDomain
But most of the icloud account, callhistory db is empty for all 3 snapshots.
Is it obvious?

Cheers

from inflatabledonkey.

@wiswashegrove The initial bug was fixed.

As we have multiple issues in one ticket and to avoid further confusion, I'm going to merge this ticket with #37.

from inflatabledonkey.