Skype is a voice/video calling app, as well as a messaging app owned by Microsoft. It has over 100,000,000 installs on Google Play.
Package name: com.skype.raider
Files of interest:
- /cache/skype-4228/DbTemp
- /sdcard/Android/data/com.skype.raider/cache/
- /files/
- shared.xml
- <username>/thumbnails/
- <username>/main.db
- <username>/chatsync
The /cache/skype-4228/DbTemp directory contained multiple files with no extension. One of these files (temp-5cu4tRPdDuQ3ckPQG7wQRFgU on our device) was actually a SQLite database that contained the SSID and MAC of wireless access points it had been connected to.
The SD card path will contain any images or files received in a chat. If a file is downloaded, it will be in the Downloads folder in the root of the SD.
The shared.xml file listed the account's username, as well as the last IP address that connected to Skype:
The <username>/thumbnails directory contained the user's profile picture.
The main.db database, like it sounds, contains all of the app usage history. Here are some important tables:
|
Table |
Description |
|
Accounts |
Shows the accounts used on the device, and the associated email addresses. |
|
CallMembers |
Call logs from the app. The duration table is the duration of the call, and start_timestamp is the start time in Linux epoch format; neither of these columns is populated if the call is not answered. creation_timestamp is the actual beginning of the call; it is populated as soon as the call is initiated within the app, so even unanswered calls are shown in this column. The ip_address column shows the IP address of the user for connected calls. The type column indicates whether the call was outgoing or incoming (1 = incoming, 2 = outgoing). The guid column also shows the direction of the call, listing each participant from left to right, with the user on the left being the one who initiated the call. The call_db_id column can be correlated with the calls table to find further information about the call. |
|
Calls |
Very similar to CallMembers, but with less information. It is worth noting that the begin_timestamp column in this table is identical to creation_timestamp in CallMembers. There is an is_incoming column to show the direction of the call: 0 indicates outgoing, 1 indicates incoming. Finally, it should be noted that the duration of some calls did NOT match the CallMembers table. One of the durations was a second longer than the other table indicated. It appears that the CallMembers table calculates duration based on start_timestamp, while the Calls table calculates duration based on begin_timestamp. The difference in duration is likely caused by the amount of time it took the user to accept the call. |
|
ChatMembers |
Shows the users in each chat. The adder column lists the user that initiated the chat. |
|
Chats |
Lists each unique chat session. The timestamp column is the date/time the conversation began, in Linux epoch format. The dialog_partner column shows users in the chat, excluding the account on the device. The posters table shows every user that has made a comment in the chat, and includes the account on the device if it has posted. The participants column is similar to the dialog_partner column, but includes the user's account. Finally, the dbpath column contains the name of the chat backup file found in the <username>/chatsync directory. This will become important further in this analysis. |
|
Contacts |
This is actually a very misleading table. In our test, we added two users to our contact list; the contacts table has 233 entries! The is_permanent column indicates the status of the users listed in this table; if it is 1, the user is added as an actual contact within the application. The other 231 entries appear to be names that came up in results when we searched for contacts, but we never communicated with or added them. |
|
Conversations |
We have no idea what the difference between Conversations and Chats is. They contain much of the same information, and in fact appear to be referencing the same chat sessions. |
|
Messages |
Contains every individual message from chats/conversations. The convo_id column has a unique value for each conversation; any messages with the same convo_id value are from the same conversation. The author and from_dispname columns show who wrote each message. The timestamp column, once again, shows the date/time of the message in Linux epoch format. The type column indicates the type of message that was sent; here are the values from our testing:
The body_xml column has the content of the message. For plaintext messages and friend requests, the content is simply what the message said. File transfers show the size and name of the file. Video messages say that they are a video message, but provide no other information. Calls show the duration if it was connected, and no duration if they were missed/ignored. The identities column shows who sent each message, but may be blank if it was sent by the user account on the device. The reason column appears to be for calls, and shows either no_answer or busy to explain why a call was not connected. |
|
Participants |
Similar to ChatMembers, shows each user involved with a chat/conversation. |
|
SMSes |
Our testing did not include SMS messaging; however, each column in this table is self-explanatory. |
|
Transfers |
Shows information about files transferred. Includes the file name, size, and path on the device. The partner_dispname column identifies which user began the file transfer.
|
|
VideoMessages |
Shows the author and creation timestamp of video messages. Note that video messages are NOT stored on the device; accessing them will be covered in a separate section below. |
|
VoiceMails |
Our testing did not include voicemails; however, each column in this table appears self-explanatory. |