Academia.eduAcademia.edu

Figure 11 – uploaded by Farkhund Iqbal

See full PDFdownloadDownload figure
Fig. 13. DiscFor extraction messages During the testing phase, it was discovered that Disk Cache was flushing its older content when reaching between 3500-4000 files in a directory. This procedure effectively reduces the possible number of evidences that can be collected in the case when the application was extensively used, and users joined many active servers. For testing purposes, we created test scenarios by populating servers with a generic user account and random content exchange. Joining multiple servers allowed the creation of datasets, with varying content such as server data, timestamps, user accounts, message digests, etc. We have generated enough data to determine the importance of Discord forensics and the usefulness of our tool. Figure 13 shows an example message displayed by the application presenting detailed information about each recovery performed with DiscFor. Detailed information about each recovery performed with DiscFor gives the user a good look at how many files were recovered and how many were ignored. Table III summarizes the results of running DiscFor on all datasets created for the experiment. The total number of entries represents the amount of all entries in the cache structure. The valid entries column holds a number of entries that contain both server HTTP response and resource payload. Ignored entries values represent entries that were either empty or duplicate data. In addition to data recovery, DiscFor also reconstructs partial entries which mostly include audio and video files.

Figure 13 DiscFor extraction messages During the testing phase, it was discovered that Disk Cache was flushing its older content when reaching between 3500-4000 files in a directory. This procedure effectively reduces the possible number of evidences that can be collected in the case when the application was extensively used, and users joined many active servers. For testing purposes, we created test scenarios by populating servers with a generic user account and random content exchange. Joining multiple servers allowed the creation of datasets, with varying content such as server data, timestamps, user accounts, message digests, etc. We have generated enough data to determine the importance of Discord forensics and the usefulness of our tool. Figure 13 shows an example message displayed by the application presenting detailed information about each recovery performed with DiscFor. Detailed information about each recovery performed with DiscFor gives the user a good look at how many files were recovered and how many were ignored. Table III summarizes the results of running DiscFor on all datasets created for the experiment. The total number of entries represents the amount of all entries in the cache structure. The valid entries column holds a number of entries that contain both server HTTP response and resource payload. Ignored entries values represent entries that were either empty or duplicate data. In addition to data recovery, DiscFor also reconstructs partial entries which mostly include audio and video files.

Related Figures (15)

TABLE I. DISCORD INSTALLATION DIRECTORY
TABLE I. DISCORD INSTALLATION DIRECTORY
Disk Cache was developed as part of a Chromium project by Google and became a base for multiple web browsers such as Google Chrome, Opera and Brave. The structure is available under an open-source licence [15] and was wel described in [8]. There is a significant difference between the index file and data_O that may be of great value for forensic analysis and recovery of evidence. The file data_0 consists of two parts: a header and a rankings table. The header contains control information about the file and the table below. The rankings table is comprised of blocks that store the address of cache entries alongside its eviction information. The rankings file contains more forensically valuable data in comparison to the index file. The use of data_0 can significantly simplify the process of data recovery. The eviction information that can be found in the file may provide vital information on when the file was created and accessed for the last time. Figure 2 presents the structure of a data_0 file and its blocks of rankings data. Fig. 2. Ranking block (data_0) structure
Disk Cache was developed as part of a Chromium project by Google and became a base for multiple web browsers such as Google Chrome, Opera and Brave. The structure is available under an open-source licence [15] and was wel described in [8]. There is a significant difference between the index file and data_O that may be of great value for forensic analysis and recovery of evidence. The file data_0 consists of two parts: a header and a rankings table. The header contains control information about the file and the table below. The rankings table is comprised of blocks that store the address of cache entries alongside its eviction information. The rankings file contains more forensically valuable data in comparison to the index file. The use of data_0 can significantly simplify the process of data recovery. The eviction information that can be found in the file may provide vital information on when the file was created and accessed for the last time. Figure 2 presents the structure of a data_0 file and its blocks of rankings data. Fig. 2. Ranking block (data_0) structure
Fig. 1. Discord local directory structure with activity log location The cache structures are in the folders “GPUCache”, “Code Cache? and “Cache”. The “GPUCache” folder contains data used to increase the performance of the application but does not retain any information about the user. The second folder stores code used by the application though it does not hold any forensically valuable information. The last directory contains data about recently viewed messages, channels, servers etc. and is one of the applications digital artefact sources. The activity log can be found in “discord/Local Storage/leveldb” where it resides among other types of files.
Fig. 1. Discord local directory structure with activity log location The cache structures are in the folders “GPUCache”, “Code Cache? and “Cache”. The “GPUCache” folder contains data used to increase the performance of the application but does not retain any information about the user. The second folder stores code used by the application though it does not hold any forensically valuable information. The last directory contains data about recently viewed messages, channels, servers etc. and is one of the applications digital artefact sources. The activity log can be found in “discord/Local Storage/leveldb” where it resides among other types of files.
Fig. 3. Simple Cache directory structure Simple Cache is currently used by Discord as the main cache storage for Linux and Android distributions. The Simple Cache folder contains a fake index file, several cache entry files and folder index-dir which contains the-real-index. The-real-index file contains cache addresses for each cache entry. An overview of the Simple Cache folder in presented in Figure 3. The real-index file, as shown in Figure 4, consists of three parts: a header, entry hash table and an end of the file, called a footer. The header size is 40 bytes and contains information about the amount of entries in the hash table, cache size and control data. The hash table contains a list of entries and each entry is 24 bytes in size. The cache entry structure is comprised of three parts, as shown in Table II.
Fig. 3. Simple Cache directory structure Simple Cache is currently used by Discord as the main cache storage for Linux and Android distributions. The Simple Cache folder contains a fake index file, several cache entry files and folder index-dir which contains the-real-index. The-real-index file contains cache addresses for each cache entry. An overview of the Simple Cache folder in presented in Figure 3. The real-index file, as shown in Figure 4, consists of three parts: a header, entry hash table and an end of the file, called a footer. The header size is 40 bytes and contains information about the amount of entries in the hash table, cache size and control data. The hash table contains a list of entries and each entry is 24 bytes in size. The cache entry structure is comprised of three parts, as shown in Table II.
Fig. 4. The-real-index file structure
Fig. 4. The-real-index file structure
Fig. 5. Structure of the Simple Cache entry file
Fig. 5. Structure of the Simple Cache entry file
Fig. 7. Discord server HTTP response overview Figure 7 presents an overview of the server HTTP response. The headers of interest are highlighted yellow. While in this state data is legible it must be cleaned from unnecessary characters to improve its readability.
Fig. 7. Discord server HTTP response overview Figure 7 presents an overview of the server HTTP response. The headers of interest are highlighted yellow. While in this state data is legible it must be cleaned from unnecessary characters to improve its readability.
Fig. 9. DiscFor main functionalities overview client-side Discord directories. To achieve this, our tool consists of four main functionalities that address digital forensic process stages. In this section, we present an overview of the architecture used for DiscFor (Figure 9) and implementation details.
Fig. 9. DiscFor main functionalities overview client-side Discord directories. To achieve this, our tool consists of four main functionalities that address digital forensic process stages. In this section, we present an overview of the architecture used for DiscFor (Figure 9) and implementation details.
Fig. 11. Functionality graph of Simple Cache recovery script The Simple Cache as the name suggests is less complex than Disk Cache, thus the process of evidence acquisition is simpler as most of the data is stored in a single location. The diagram in Figure 8 shows simple overview of this process. The algorithm responsible for finding entries does not start from reading index file but instead loops through cache directory and reads every single entry found within. This allows to pull information and recover files which trail does not exist in the index file in a situation where the application did not manage to update a file before it was closed. With the cache entry file open, DiscFor proceeds to read data found inside. End of file sections are read first and information about corresponding entries is pulled.
Fig. 11. Functionality graph of Simple Cache recovery script The Simple Cache as the name suggests is less complex than Disk Cache, thus the process of evidence acquisition is simpler as most of the data is stored in a single location. The diagram in Figure 8 shows simple overview of this process. The algorithm responsible for finding entries does not start from reading index file but instead loops through cache directory and reads every single entry found within. This allows to pull information and recover files which trail does not exist in the index file in a situation where the application did not manage to update a file before it was closed. With the cache entry file open, DiscFor proceeds to read data found inside. End of file sections are read first and information about corresponding entries is pulled.
Fig. 10. Functionality graph of Disk Cache recovery script server HTTP response and stores all pulled data in a class instance separate for each entry.
Fig. 10. Functionality graph of Disk Cache recovery script server HTTP response and stores all pulled data in a class instance separate for each entry.
https://media.discordapp net/attachments/690238062298791986/690243 166137614589/planet mp4 format=jpeg&width=400&height=225 from chat logs and corresponding multimedia files as shown in Figure 9.
https://media.discordapp net/attachments/690238062298791986/690243 166137614589/planet mp4 format=jpeg&width=400&height=225 from chat logs and corresponding multimedia files as shown in Figure 9.
TABLE V. DATA TYPES FOUND IN HTTP RESPONSE DiscFor results were compared to ChromeCacheView which also allows recovering most of the data from Discord cache however it does not provide reporting features and some of the data is not being recovered as can be seen in Table 5. Apart from verification of completeness of the recovered data we have also tested the speed of recovery of both solutions.
TABLE V. DATA TYPES FOUND IN HTTP RESPONSE DiscFor results were compared to ChromeCacheView which also allows recovering most of the data from Discord cache however it does not provide reporting features and some of the data is not being recovered as can be seen in Table 5. Apart from verification of completeness of the recovered data we have also tested the speed of recovery of both solutions.
TABLE III. RECOVERY RESULTS
TABLE III. RECOVERY RESULTS
TABLE IV: DISCORD CONTENTS
TABLE IV: DISCORD CONTENTS
TABLE V. COMPARISON OF DICFOR AND CHROMECACHEVIEW RECOVERY RESULTS
TABLE V. COMPARISON OF DICFOR AND CHROMECACHEVIEW RECOVERY RESULTS
Related topics:
Computer ScienceDigital Evidence
580 California St., Suite 400
San Francisco, CA, 94104
© 2025 Academia. All rights reserved