Earlier in the year Digital Forensic Analyst Marco Neumann wrote a series of great blog posts analysing artifacts created by Skype apps (both Windows Store and Desktop versions):

Some of the filenames he discussed looked the same as Google Chrome artifacts so we did some digging and discovered that the Skype desktop app is now built using the Electron framework, which in turn uses the Chromium rendering engine and therefore creates some of the same artifacts as Google Chrome.

We analysed version 8.53 of the Skype desktop app and found Skype data stored in the following location on a Windows machine:

C:\Users\<username>\AppData\Roaming\Microsoft\Skype for Desktop

The folders and filenames are instantly recognisable as Chromium artifacts:



As we could see cache artifacts here we tried loading them into Browser History Examiner (BHE) to see if anything of interest could be recovered. To do this we used the Load history manually option within BHE and specified the following path for the Chrome cache files location:

C:\Users\<username>\AppData\Roaming\Microsoft\Skype for Desktop\Cache

Over a 1000 cached images were extracted from the Skype profile we used, which appeared to be a mixture of the following:
  • Images sent/received during Skype conversations
  • Preview thumbnails associated with links sent/received during Skype conversations
  • Images that are used by the Skype application itself

Images exchanged during conversations are often of the most interest and these appear to have URLs with a subdomain such as api.asm.skype.com. Therefore, a simple keyword search for “api.asm.skype.com” filtered the cached images down to just those that were exchanged during conversations.



The Cached Files tab in BHE showed over 26,000 other records that had been recovered. Most of these cache records were requests to Skype APIs with JSON responses.

Some of the records clearly represent links that have been shared within conversations.



These URLs all start with https://urlp.asm.skype.com/v1//url/info followed by a “url” query string parameter that contains the shared link in URL encoded format. For example when a user shares the following link:
https://www.foxtonforensics.com/blog/post/analysing-firefox-session-restore-data-mozlz4-jsonlz4

Then a HTTP request is made to a Skype API with the following URL:
https://urlp.asm.skype.com/v1//url/info?url=https%3A%2F%2Fwww.foxtonforensics.com%2Fblog%2Fpost%2Fanalysing-firefox-session-restore-data-mozlz4-jsonlz4

Query string parameters can be easily decoded in BHE by right-clicking on a record and going to Inspect URL. The details window then shows the decoded values:



We can also inspect the JSON data that has been cached for the API request, by right-clicking the record and going to Inspect JSON. Again we can see the URL that has been shared along with other metadata.



Browsing through the other cache records we can see requests to Skype APIs about call rates / prices which include a telephone number.





There are also requests regarding missed calls:



The URL doesn’t provide any interesting information but we can see the phone number of the missed call by inspecting the JSON response.



As you can see lots of useful data can be obtained from an Electron/Chromium based desktop application such as Skype by using Browser History Examiner.

We also discovered that the Skype desktop app caches some conversation messages using the Indexed Database API within Chromium. This data is stored within the “IndexedDB” folder e.g.

C:\Users\<username>\AppData\Roaming\Microsoft\Skype for Desktop\IndexedDB

Chromium uses LevelDB as the underlying datastore for the Indexed Database API. Some conversation messages can be seen in plain text within the LevelDB database files. However, in order to extract this data we will need to parse the LevelDB database. We plan to continue our research in this area and hope to have more updates on this in the future.