-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't crash if icloud account/phone can't be inferred #3
Comments
@wongjustin99, I'm using the local address book directory ( If you open Contacts.app, do you have an entry at the top for yourself? Does it have a phone number associated with it? |
I pushed updates for
I suspect it won't work because #4 isn't handled yet. But you can always pass in the missing information manually: The general problem is that the local iMessage sqlite database only contains the identifiers of participants, not your own number. Your iCloud account (for setting the sender of iMessages) is easy to figure out but not your phone number (for setting the sender of SMS). I might consider adding an option for users who don't care about sending the sender field. Regarding your 10+ numbers, that's another thing I'll have to figure out with some sqlite reverse engineering but I have a feeling it might not be possible to correctly guess which is the sender because I don't see a concept of a default phone number in iCloud contacts. |
I didn't need to manually pass that option in. Actually seems to be working now! Thanks so much for the help. Now that I have this set up, this might be a conversation for somewhere else besides this issue - but how are you using these plugins? Are they piped into something else for viewing/analysis? Or do you have any ideas you were planning to flesh out? |
The extractor uses the
LocalContacts
module to try and infer information about a user's icloud account and phone number (via local Address Book sqlite dbs). If these details can't be found and no options are passed in manually (viamy_phone_number
setting, etc), the extractor should raise an exception instead of crashing.This was encountered by @wongjustin99 in #chronicle-etl/33:
The text was updated successfully, but these errors were encountered: