An evidence-based Android cache forensics model
Download 0.49 Mb.
|
- Navigate this page:
- 1.10.2Application caches
- 1.10.2.1Generic Caches
- 1.10.2.2Webview Cache
- 1.10.2.3SQLite DB Cache
- 1.10.2.4Image Cache
- 1.10.2.5Serialized Java Objects
- 1.10.2.6DiskLruCache
- 1.10.2.7Custom Format
1.10FindingsThere are several interesting findings that were identified during the cache analysis. 1.10.1System cachesSystem cache in Android is Dalvik VM Cache. For the purpose of faster run time execution, byte-code alignment, verification and optimization are done well ahead and stored as optimized DEX in dalvik cache. This optimization happens when the application is first run after the installation. The dalvik-cache is found in a system folder which can be found at /data/data/dalvik-cache . 1.10.2Application cachesMost apps use private caches in some way or the other. While some Android developers specifically handle cache in their apps, most developers may not even know that their app will cache internally because they use certain APIs. A pattern of similarity is noticed across apps and the usage of standard cache APIs creating stand set of cache files. However, most of these cache file formats are undocumented. In this research, some attempts had been made to document these undocumented cache formats. 1.10.2.1Generic CachesMost of the analysed apps have these files. It is usually found inside the Android private cache location and accompanied by two other folders namely debug and testdata. It generally creates around 12 files or more.
Below is the structure of cache_r.0 file
Table 2 - Structure of cache_r.0 Below is the structure of cache_bd.0 file
Table 3 - Structure of cache_bd.0 1.10.2.2Webview CacheWhen an app uses WebView component to load web pages, the pages and other resources related to that page are cached in the private cache location of each app. WebView in Android 4.4 and above by default uses Chromium WebView while less than version 4.4 uses Android WebView . This means, the WebView caches on Android versions less than 4.4 will be different than the WebView Caches on version 4.4 and above. In this experiment, Android version 4.1.2_r2 is considered because Android 4.4 is relatively new and only a few models exist. WebView caches are found inside a directory called webviewCacheChromium under the private cache location. E.g., /data/data/ /cache/webviewCacheChromium The cache consists of many files but only three different file formats. There is only one index file, a few data_ 
Figure 7 - List of files for WebView Cache The WebView caches are stored on disk as a collection of block-files with an index file and a collection of several external files. The Android source header file disk_format.h located inside the project chromium under net/disk_cache contains several important information regarding cache structures and working mechanisms. When cache data is larger than the block size specified in (net/addr.h), then the cache is stored on a separate file called f_xxxxxx where x is a hexadecimal number. Smaller data are stored in series of blocks on a block file. The index file which is just ‘index’ without any extensions, is a hash table that maps the cache entry to the cache address value.
Table 4 - WebView cache index file Block-file is the last element of the cache which stores blocks of data of a given size. It can store data from one to four consecutive blocks and can grow up to 64K blocks. It has a fixed size header used to track free of blocks on the file. The first file contains the number of the second file, and the second file contains the number of a third file, created when the second file reaches its limit. Any given block can be located directly by its address from these linked-chain of files, which contains the file number and starting block inside the file. Every time a new cache is initialized, it is done so with four block files (data_0, data_1, data_2 and data_3) with each file dedicated to store blocks of a given size. The number at the end of the file name is the block file number which is in decimal. There are two special types of blocks namely, an entry and a rankings node. While entry node contains information related to the same cache entry, a rankings node has volatile information that changes frequently for a given entry. All cache entries also have a dirty identifier.
Table 5 - Structure of block file
Table 6 - Structure of a Cache Entry The other files f_xxx are raw data files like Html, JavaScript etc., either compressed or uncompressed files. 1.10.2.3SQLite DB CacheSQLite is a powerful, compact, embedded relational database management system . Several Apps that take advantage of SQLite database which is on public domain, used by default by most modern browsers and has default developer support from Android, instead of just files. These files can be viewed by any SQLite database browser. Android Cache Viewer, the primary contribution of this thesis provides default support for SQLite database caches. 1.10.2.4Image CacheStandard Android gallery uses a format different from other caches. It creates of three files where one file is the index and the other two are data files. One data file is active while the other is inactive. New entries are appended into the active region until it exceeds the size limit. If it exceeds the limit, the active file and the inactive file are interchanged, and the new active file is simply truncated and the index for that file is also cleared. The index file is a hash table .
Table 7 - Index file of Android Gallery
Table 8 - Data file of Android Gallery The structure is found in the below source location.
1.10.2.5Serialized Java ObjectsSome Android apps caches data in the form of serialized Java objects and one good example is YouTube. Because serialized objects in various apps can represent various structures, let us analyse YouTube as an example. YouTube caches images as serialized objects. Skipping 0x95 bytes from each of the .cache file located in the private cache directory, will yield a JPEG image from the video watched. Offset 76-7D provides the timestamp in milliseconds of the Unix epoch time. 
Figure 8 - JPEG and Timestamp in YouTube Cache In the above example, 0x000001442571F983 corresponds to Wed, 12 Feb 2014 09:33:50 GMT.
libcore.io.DiskLruCache 1 100
2 CLEAN 3400330d1dfc7f3f7f4b8d4d803dfcf6 832 21054 DIRTY 335c4c6028171cfddfbaae1a9c313c52 CLEAN 335c4c6028171cfddfbaae1a9c313c52 3934 2342 REMOVE 335c4c6028171cfddfbaae1a9c313c52 DIRTY 1ab96a171faeeee38496d8b330771a7a CLEAN 1ab96a171faeeee38496d8b330771a7a 1600 234 READ 335c4c6028171cfddfbaae1a9c313c52 READ 3400330d1dfc7f3f7f4b8d4d803dfcf6
Table 9 - Structure of Journal File Cache entries with DIRTY status is actively being created or updated. Also, all successful DIRTY operation must be followed by a CLEAN or REMOVE status. DIRTY lines with no CLEAN or REMOVE means, temporary files must be removed. Cache entries can only be read from CLEAN track entries. READ status tracks the LRU cache access. REMOVE status indicates the removal of cache entry . A temporary file named "journal.tmp" will be used during compacting journal file. This is helpful to data carve the journal.tmp for forensic purposes. Many apps like LinkedIn use DiskLruCache as it is a standard API. The structure is found in the below source location.
1.10.2.7Custom FormatSeveral Apps also use custom and third party cache libraries which could have different formats apart from what were discussed. Directory: wki -> images images -> Research Proposal Augmented Reality Visualization of Outdoor Environmental Corrosion Download 0.49 Mb. Share with your friends:
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||