An evidence-based Android cache forensics model
Download 0.49 Mb.
|
- Navigate this page:
- 2.2.2 Undocumented Caches
- 2.2.3 Lack of Analysis Tools
- Conceptual Android Cache Forensic Process
- 1.8Extending Mckemmish’s Model
1.7Literature gapsWhile there are several methodologies, there is no specific process or technique to analyse Android app caches. This is probably due to the recent entry of Android apps which became popular. Hence, there is a need to have such a process to analyse Android caches. In addition to the lack of process and methodologies, the following factors also complicate forensic examination of Android app caches. 2.2.1 Cache DiversityThere is no universal cache format for Android Apps. App developers have the liberty to decide which cache format is appropriate for them. While Android itself provides support for caches, there are also other several third-party cache libraries. Some of the third-party cache libraries are as follows:
Also, a single Android app can make use of multiple cache libraries depending on its requirements and the components used in it. There are specific libraries for image caching, network caching etc. This diversity poses a huge challenge in properly identifying potential evidences in cache. 2.2.2 Undocumented CachesAndroid cache structures used by apps are often not documented properly. While clear API (Application Programming Interface) documentation exists for developers to use a cache in the application, the actual cache structures are generally not publicly documented for the purpose of forensics. This is certainly a huge barrier to overcome. The solution is not straight forward, but often involves analysing source code and reverse engineering. This again poses a challenge in properly identifying potential cache evidences. 2.2.3 Lack of Analysis ToolsModern mobiles are no longer just telephones but a smartphone, with powerful processing as a desktop computer or a laptop. With these swift changes, the way that these smart phones must be analysed also changes. While there are several forensic mobile data extracting tools available and many desktop application aid in analysing data, there are not many pre-existing tools to analyse specifically Android caches. Part of the reason is also because, Android is relatively new and there are millions of apps out there and each can have individual caching schemes. This poses a challenge in properly analysing potential cache evidences. 2.2.4 Rapid ChangesAndroid 1.0 was released on September 2008 . With the release of the latest version as of March 2014, Kit Kat 4.4, the API level was upgraded to 19 times, and the current API level is 19. Hence, roughly every 4 months, the API level increases, with new and more advanced features. So, the knowledge of a particular version regarding caches used by these new features, gets outdated every 4 months. This is a big challenge for forensic investigators to properly analyse potential cache evidences. Conceptual Android Cache Forensic ProcessMobile forensics is always a challenge for law enforcement . Android forensics in particular have a host of challenges that must be overcome . To overcome these issues and gaps, a new process focused on cache forensics is required. With more than 1.2 million Android Apps in Google Play Store, there is a wide range of apps and consequently diversity in the associated caches (which are often undocumented). To facilitate forensic examination, a transparent and robust classification is required. Classifying different caches makes it easier for law enforcement to take appropriate steps based on the cache branch. 
Figure 5 – Our proposed Android Cache Taxonomy Android caches are broadly divided into system caches and app caches. System caches contain the Delvik virtual machine caches. App caches are again divided into internal caches and external disk caches. External caches are those that are stored in SD cards which has no security attributes attached to them. Hence, any Android app can access these caches. Internal or private caches are protected and available only to that app and not available to any other app, unless the smartphone is rooted. Irrespective of whether the cache is internal or external, app caches can be broadly classified into component caches, Android API caches and custom or third party caches.
Most of the gaps we have noted are technical barriers. McKemmish’s model continues to be broadly applicable to Android cache forensics. However the technologies used in various elements varies greatly. For example, in preservation step, by default, most of the investigations take a snapshot/image of the disk and analyse later. However, that may have not been the case, two decades earlier. Hence, the preservation step is by default became a part of the process. However, the analysis part requires more effort with modern devices compared to the early days of mobile phones. In those days, mobiles had contacts and nothing else. Today, it is a computer in a pocket. This provides an imbalance in the four elements in Mckemmish model, strictly speaking from an effort and volume of that element as a result of technological advancement. 
Figure 6 - Conceptual Android Cache Forensic Process The process that is proposed here, which will be applied further in Android Cache Viewer is based on extending McKemmish Model specifically for Android Caches.
1.8.1.1ClassificationThis is equivalent to the identification step in McKemmish Model of forensic computing but not the same. Android caches are already identified as potential evidences and there is no requirement to any further identification. However, what is really required is a proper classification. This classification helps to identify the steps and procedures required to approach the investigation. As we saw in cache taxonomy, there are several different caches used for applications and each has a unique way to extract information. Hence, classification is absolutely required for proper extraction and analysis of Android caches. 1.8.1.2ExtractionPreservation step is required to make sure that the potential evidence is not tampered in anyway. With regards to mobile caches, the entire mobile memory/SD partition is usually taken as a disk image and analysed independently. From a cache perspective, the preservation step is mostly by extraction. Android partitions can be converted into an image file by using several Unix tools, Android Debugging Bridge (ADB) and dd from BusyBox. This partition can be mounted and analysed forensically. This way, the preservation step from McKemmish Model can be successfully undertaken during Extraction. 1.8.1.3Cache AnalysisThere are several tools to analyse mobile data. However, there are very few known tools for forensic investigation of cache data. There are several reasons identified:
Android Cache Viewer, which is the primary contribution of this thesis, is discussed in later sections, which helps to aid cache analysis for law enforcement and forensic investigators. Each cache is unique and must be analysed specifically. As we discussed earlier, without a proper classification, it is not easy for systematic analysis. 1.8.1.4Cache ReportsPresentation phase is the final element in McKemmish model which describes the need to provide presentable documents as the court requires. While it may include technical reports, it is not generally composed solely of a technical report. With regards to Android cache forensics, cache reports will often be included in the document which will be presented to the court. Android cache viewer will be able to provide cache reports. Directory: wki -> images images -> Research Proposal Augmented Reality Visualization of Outdoor Environmental Corrosion Download 0.49 Mb. Share with your friends:
|