Academia.eduAcademia.edu

Figure 3 – uploaded by Farkhund Iqbal

See full PDFdownloadDownload figure
Fig. 4. Structure of the-real-index file The real-index file (Fig. 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 number of entries in the hash table, cache size and control = wey ee The hash table contains a list of entries and each entry is 24 bytes in size. The cache entry has three parts, as shown in Table 1. The very last 8 bytes of the file are reserved for saving the last modified time of the index file. While Disk Cache structure makes use of block files to store data, Simple Cache resource content and HTTP responses are stored in a single cache entry file. This format significantly simplifies a reading and writing process of cached data which also reduces the complexity of analysis and recovery algorithms. A cache entry name is created by combining a reverse entry hash address from the index file with an underscore and a stream number which can be either 0, 1 or s. The structure of the most commonly used format (stream 0) starts from file header followed by URL, resource content, EOF (End of File), server HTTP response, SHA256 of the URL (optional part) and EOF.

Figure 4 Structure of the-real-index file The real-index file (Fig. 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 number of entries in the hash table, cache size and control = wey ee The hash table contains a list of entries and each entry is 24 bytes in size. The cache entry has three parts, as shown in Table 1. The very last 8 bytes of the file are reserved for saving the last modified time of the index file. While Disk Cache structure makes use of block files to store data, Simple Cache resource content and HTTP responses are stored in a single cache entry file. This format significantly simplifies a reading and writing process of cached data which also reduces the complexity of analysis and recovery algorithms. A cache entry name is created by combining a reverse entry hash address from the index file with an underscore and a stream number which can be either 0, 1 or s. The structure of the most commonly used format (stream 0) starts from file header followed by URL, resource content, EOF (End of File), server HTTP response, SHA256 of the URL (optional part) and EOF.

Related Figures (11)

Fig. 1. Discord local directory structure with activity log location
Fig. 1. Discord local directory structure with activity log location
Fig. 2. Ranking block (data_0) structure The file data_O 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. Each block is 36 bytes in size (Fig. 2). The rankings file contains more forensically valuable data in comparison to the index file (which only stores a list of entry addresses). The use of data_O can significantly simplify the process of data recovery, while the eviction information provides vital information on when the file was created and accessed for the last time.
Fig. 2. Ranking block (data_0) structure The file data_O 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. Each block is 36 bytes in size (Fig. 2). The rankings file contains more forensically valuable data in comparison to the index file (which only stores a list of entry addresses). The use of data_O can significantly simplify the process of data recovery, while the eviction information provides vital information on when the file was created and accessed for the last time.
Fig. 3. Simple Cache directory structure
Fig. 3. Simple Cache directory structure
Fig. 7. DiscFor main functionalities overview The main characteristic of application-specific forensics is that it deals with large numbers of various file types and their structures. In order to read often dispersed data from proprietary formats new tools are required. Therefore, the goal of DiscFor is to automate the process of evidence collection and presentation from local Discord directories. While there are solutions available for Discord data recovery, most of them do not acquire complete data. The reason for DiscFor creation was to tackle this issue a nd develop a robust software solution capable of extracting all information stored on Discord local files that might be of and presenting them to the application user. forensic value n this section we present an overview of the architecture used (Fig. 7). The preservation of data is the first phase of the d investigation. One of DiscFor’s options a creation of a logical copy of the source material igital forensic ows for the . This ensures that data is not being altered by Discord during further examination, and provides a backup of the original data for further use. Prior to backup creation the user has the option to either search a file system for the Discord directory or provide an exact path to the target folder.
Fig. 7. DiscFor main functionalities overview The main characteristic of application-specific forensics is that it deals with large numbers of various file types and their structures. In order to read often dispersed data from proprietary formats new tools are required. Therefore, the goal of DiscFor is to automate the process of evidence collection and presentation from local Discord directories. While there are solutions available for Discord data recovery, most of them do not acquire complete data. The reason for DiscFor creation was to tackle this issue a nd develop a robust software solution capable of extracting all information stored on Discord local files that might be of and presenting them to the application user. forensic value n this section we present an overview of the architecture used (Fig. 7). The preservation of data is the first phase of the d investigation. One of DiscFor’s options a creation of a logical copy of the source material igital forensic ows for the . This ensures that data is not being altered by Discord during further examination, and provides a backup of the original data for further use. Prior to backup creation the user has the option to either search a file system for the Discord directory or provide an exact path to the target folder.
TABLE 2. DISCFOR RECOVERY RESULTS The extraction capabilities of our tool were tested manually to ensure that the correct data and files were recovered. DiscFor recovers 29 different types of information for every file extracted and saves them in a CSV report. Chat logs and attachments are the most valuable types of evidence that can be found in the Discord local directory. The former stores entire conversations including text, graphical content URLs, and timestamps which are vital in 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. 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. In comparison, ChromeCacheView does not recognise valid entries as it attempts to recover empty files. FireKitty does not recover any data, while Discrecorder is able to extract some files, albeit with significant changes made to the source code. Py_chromium_cache_simple only extracts data from Simple Cache structure, and “JSON to HTML and XLS” parses data from chat logs but does not include all information that can be found in the log file. Whilst all of the tools provide different capabilities in terms of Discord data recovery, none of them can perform full, accurate extractions combined with chat log reconstruction and _ presentation. As ChromeCacheView is the most accurate of all the solutions offered, its performance was specifically selected and compared to DiscFor.
TABLE 2. DISCFOR RECOVERY RESULTS The extraction capabilities of our tool were tested manually to ensure that the correct data and files were recovered. DiscFor recovers 29 different types of information for every file extracted and saves them in a CSV report. Chat logs and attachments are the most valuable types of evidence that can be found in the Discord local directory. The former stores entire conversations including text, graphical content URLs, and timestamps which are vital in 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. 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. In comparison, ChromeCacheView does not recognise valid entries as it attempts to recover empty files. FireKitty does not recover any data, while Discrecorder is able to extract some files, albeit with significant changes made to the source code. Py_chromium_cache_simple only extracts data from Simple Cache structure, and “JSON to HTML and XLS” parses data from chat logs but does not include all information that can be found in the log file. Whilst all of the tools provide different capabilities in terms of Discord data recovery, none of them can perform full, accurate extractions combined with chat log reconstruction and _ presentation. As ChromeCacheView is the most accurate of all the solutions offered, its performance was specifically selected and compared to DiscFor.
Fig. 8. Functionality graph of Disk Cache recovery script Ihe next stage is an extraction of data that has been identified as potential evidence. We have designed three different modules in order to address all three possible sources: Disk Cache, Simple Cache and activity log. Fig. 8 shows the functionality of the module (maincache.py) responsible for the recovery of the data from Disk Cache used on Windows and macOS operating systems. The dispersion of data across multiple locations requires a lengthy process of recovery. As its name suggests, Simple Cache is less complex than Disk Cache, thus the process of evidence acquisition is easier as most of the data is stored in a single location. Recovery of data from the activity log is performed by employing a simple pattern recognition algorithm which pulls all necessary information. The last component of our tool is responsible for presentation of findings. Information on all recovered files is saved to a CSV file, the contents of which includes the file name, server HTTP response and eviction information as well as the addresses of all parts in cache files. Because Discord compresses each file uploaded by its users, an MD5 hash value is calculated for each recovered item and stored in the report. We have developed a separate module which reconstructs chat messages from chat logs and corresponding multimedia files extracted from the cache. Recreated messages are saved in HTML format and can be displayed in a web browser.
Fig. 8. Functionality graph of Disk Cache recovery script Ihe next stage is an extraction of data that has been identified as potential evidence. We have designed three different modules in order to address all three possible sources: Disk Cache, Simple Cache and activity log. Fig. 8 shows the functionality of the module (maincache.py) responsible for the recovery of the data from Disk Cache used on Windows and macOS operating systems. The dispersion of data across multiple locations requires a lengthy process of recovery. As its name suggests, Simple Cache is less complex than Disk Cache, thus the process of evidence acquisition is easier as most of the data is stored in a single location. Recovery of data from the activity log is performed by employing a simple pattern recognition algorithm which pulls all necessary information. The last component of our tool is responsible for presentation of findings. Information on all recovered files is saved to a CSV file, the contents of which includes the file name, server HTTP response and eviction information as well as the addresses of all parts in cache files. Because Discord compresses each file uploaded by its users, an MD5 hash value is calculated for each recovered item and stored in the report. We have developed a separate module which reconstructs chat messages from chat logs and corresponding multimedia files extracted from the cache. Recreated messages are saved in HTML format and can be displayed in a web browser.
TABLE 3. DISCORD APP CONTENTS The server HTTP response is recovered in the form of a byte string, and the most important parts are cleaned; an example of this is shown in Table 4, while a fully reconstructed message is presented in Fig. 9.
TABLE 3. DISCORD APP CONTENTS The server HTTP response is recovered in the form of a byte string, and the most important parts are cleaned; an example of this is shown in Table 4, while a fully reconstructed message is presented in Fig. 9.
TABLE 4. TYPES OF CARVED AND CLEANED SERVER RESPONSE DATA
TABLE 4. TYPES OF CARVED AND CLEANED SERVER RESPONSE DATA
TABLE 5. DISCFOR AND CHROMECACHEVIEW RECOVERY RESULTS COMPARISON
TABLE 5. DISCFOR AND CHROMECACHEVIEW RECOVERY RESULTS COMPARISON
Fig. 9. Example of reconstructed message
Fig. 9. Example of reconstructed message
Moreover, Fig. 10 shows that the DiscFor process of data recovery takes less time than its ChromeCacheView counterpart even though it recovers more information and also reconstructs the messages. The results are based on the tests performed on all 18 datasets shown in Table 2. The testing only considered the recovery of the data and creation of the report files as ChromeCacheView does not provide a backup feature. In spite of this result, it is important to mention that the performance of DiscFor recovery may be variable, depending on the hardware and software used. Fig. 10. DiscFor and ChromeCacheView performance comparison
Moreover, Fig. 10 shows that the DiscFor process of data recovery takes less time than its ChromeCacheView counterpart even though it recovers more information and also reconstructs the messages. The results are based on the tests performed on all 18 datasets shown in Table 2. The testing only considered the recovery of the data and creation of the report files as ChromeCacheView does not provide a backup feature. In spite of this result, it is important to mention that the performance of DiscFor recovery may be variable, depending on the hardware and software used. Fig. 10. DiscFor and ChromeCacheView performance comparison
Related topics:
Computer Science
580 California St., Suite 400
San Francisco, CA, 94104
© 2025 Academia. All rights reserved