Manually browse sma...
 
Notifications
Clear all

Manually browse smarts phones! Extractions miss app contents

10 Posts
8 Users
0 Likes
527 Views
(@yunus)
Posts: 178
Estimable Member
Topic starter
 

Hi all,

We have a case, where we were handed a mobile phone and we were asked to extract all messages (Sms, whatsapp, etc in the phone) and we had been told that the suspect had been using a messaging application called xxxx.

And after we got extractions from both UFED and XRY, we saw that none of the messages of the application (we were told about) were included in the report, which was disappointing enough once again.

As we were not able to see the messsages in the report produced by so-called FORENSIC SOFTWARE, we had to manually browse the phone to see whether or not there are those messages in the phone and we saw that the messages were all there in plain text, no password, no encryption.

IF THE GUYS WHO BROUGHT THE PHONE HAD NOT TOLD US THE SUSPECT HAD THOSE MESSAGES, WE WOULD PROBABLY NOT MANUALLY BROWSE THE PHONE AFTER THE EXTRACTION.

And If we had sent the report - of the forensic software- which is based only on the extraction THE REPORT WOULD BE MISSING THOSE EXISTING IMPORTANT CONTENTS, AND THE PROSECUTOR WOULD PROBABLY NOT UNDERSTAND HOW WE MIGHT MISS SUCH IMPORTANT CONTENTS WITH SUCH A LABORATORY EQUIPPED WITH FANCY SOFTWARE WORTH OF THOUSANDS OF DOLLARS.

This drives us really crazy. The contents that can easily be seen by JUST manually browsing of the phone, can not be extracted at all -without even a slightest warning - by the forensic software -UFED nor XRY- and those software give the FALSE impression THAT examiners get all the existing contents in phones, so examiners do not have to manually browse the phone".

So, I am convinced once-more that WE, AS EXAMINERS, NEVER FULLY TRUST EXTRACTIONS of so-called FORENSIC SOFTWARE, or never assume FORENSIC REPORTS PRODUCED BY THE SOFTWARE IS COMPLETE. No FORENSIC REPORT is complete with such hollow results produced by the so-called forensic software that steal people's trust.

One more thing, we now are updating our mobile phone examination procedures to manually browse the phones after extractions of the software, and make sure whether there is any content left unextracted. So, please check yours so you should not be deceived with missing, wrong reports of so called forensic software.

 
Posted : 21/04/2016 11:38 pm
aeiforensics
(@aeiforensics)
Posts: 27
Eminent Member
 

Most commercial tools will extract the SQL db and then will run a parser for what they are made aware to look for. A simple app version change could have changed the schema, added/removed columns, etc…so Yes, it's always crucial to gain a more complete picture via manual processes. Not because you don't trust your vetted and tested tool, but because we as Forensic Examiners should know what our tool is/is not doing behind the scenes.

Paul Sanderson's SQL tool is a great option for this manual process and IEF's Phone module does a decent job of enumerating DBs that it doesn't recognize the schema for to at least give you a "head's up" that you may want to dig deeper.

One other thing, in my experience, I have found that exporting out the DBs from a cell phone extraction is a better alternative to viewing the DB internal to PA or XRY. Neither (currently) have as fully featured SQL browsing tools as what you can use 3rd party.

 
Posted : 21/04/2016 11:58 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

And I wonder how anyone will ever be able to validate such tools (or the procedures commonly used) against more stringent norms such as ISO 17025 or similar.

I believe you are on the prosecutor side, so you (actually the tools you used) probably missed some accusatory evidence (which might even have been "excessive" or "more than needed" to actually bring the suspect to Court) but what if the evidence was actually exculpatory in nature (and the only exculpatory evidence available)?

How far could an automated or semi-automated report generated "facts" (due to missing findings) deviate from "what actually happened"?

How would you stand in Court if a defense investigation found those exculpating artifacts you could have totally missed weren't you informed of the presence of the specific app?

How would the reputation of your laboratory be affected by such hypothetical case?

jaclaz

 
Posted : 22/04/2016 12:56 am
PaulSanderson
(@paulsanderson)
Posts: 651
Honorable Member
 

Paul Sanderson's SQL tool is a great option for this manual process

Thanks aeiforensics.

Yunus, I feel your pain but in defence of the tools you mention it is difficult (or rather impossible) for them to support every possible app and if there is an app that they dont support how can they warn you if they dont know (for instance) that a particular unsupported app is a messaging app.

There are three areas where these sorts of tools fall down (to be clear I am not knocking them as they are very good at what they do and they have a place in investigations)

* unsupported applications, there is just too much out there
* supported applications where the schema changes - this really drops them into the previous unsupported class
* Supported applications where there is too much data to produce a simple canned report

Skype is a great example of a complex database where the schema changes regularly and there is just too much data to automatically create a report that works every time. The contacts table for example has 105 columns (last time I counted there were 97) and while most of the information is not relevant in most cases, on occasion it is. e.g. I was aware that the buddy blob field can contain an embedded jpg (a copy of the avatar image) but I noticed recently that this can sometimes be a previous avatar image. Without examining the database "properly" this would be missed.

This is one of the reasons I wrote my Forensic Browser for SQLite, to browse and create reports on databases that are not supported by the main stream, one tool does all, forensic applications and to investigate a database fully.

More information on the Browser can be found at the link below, along with a form to request a fully functional demo,

http//sandersonforensics.com/forum/content.php?198-Forensic-Browser-for-SQLite

 
Posted : 22/04/2016 2:18 am
(@trewmte)
Posts: 1877
Noble Member
 

Every examiner will understand and feel your frustration, but it goes with the territory. Reaching out to explain your frustration is a good thing because we may have ideas you may find useful.

Paul Sanderson is quite correct in his reference to ISO/IEC 17025, it is a standard that could not of itself accredit the tools used for data acquisition.

Sometimes we do need to use extra tools during examination because some primary tools are not finite enough to reach into certain areas or translate data that is stored. (U)SIM is a good example in that some of the readers on the market do not acquire from 'CUST' files simply because their EF (elementary file) is not reported in e.g. GSM11.11/TS51011/3GPP31.102 or because the software hadn't been written to understand how the file was formatted e.g. .bmp.

The selection and choice of tools is still today a subjective process. In fairness to UFED and XRY (and Oxygen et al.) are you equally able to define all the times you have had successes using these tools. I am sure their use far outweighs not using them. Also, Forensic Browser for SQLite is a tool, I would have thought, you would want to have in your lab toolkit.

Tools designed for automatic data acquisition used on a target DUT does not remove the responsibility of the examiner to check the target DUT. Manual browsing is THE human intervention tool regularly used for checking and comparing the results of data acquired using software tools. In this regard examiners still require a Camera and Video in their toolkits.

Hope this helps.

 
Posted : 22/04/2016 11:29 am
(@sam305754)
Posts: 44
Eminent Member
 

In Physical Analyzer you can see in "installed app" section the one that are decoded or not. You still have the ability to extract the related database or parse your entire dump in another tool. But has mentionned above there are too many apps (and release of new versions) on the market to rely only on excellent tools such UFED or XRY.

Regards

 
Posted : 22/04/2016 12:44 pm
(@yunus)
Posts: 178
Estimable Member
Topic starter
 

Thank you everyone (jaclaz, trwmte, paulsanderson, aeiforensics, sam305754) for valuable ideas.

I totaly agree there are two many apps out there and it does not seem possible for forensic software to cover all of them.

However would it not be better - in terms of quality assurance, accurate reporting, prevent miscarriages of justice - that forensic software on which all EXAMINERS rely solely should put a general warning on their REPORTING something like "PLEASE REMEMBER TO MANUALLY BROWSE THE PHONE FOR ANY POSSIBLE CONTENT WHIC MAY ARISE FROM UNCOMMON APPLICATIONS AND MAY HAVE BEEN LEFT IN THE PHONE UNEXTRACTED TO MAKE SURE YOU PROVIDED AS ACCURATE REPORTING AS POSSIBLE".

 
Posted : 22/04/2016 2:07 pm
(@mobileforensicswales)
Posts: 274
Reputable Member
 

Its important to remember that not all apps will allow backup of local data or cache and the 'blame' as such should not be placed on the forensic tools. This is a far wider problem where I worry some examiners have little appreciation of the mechanisms behind a device backup.

I have no problem with any of the above comments and can highly recommend all tools mentioned in situations where you HAVE extraced the database ) Sometimes the only way we will get these databases is through JTAG, chipoff or modifying the device in someway to remove limitations which protect this data under normal circumstances.

 
Posted : 22/04/2016 3:27 pm
UnallocatedClusters
(@unallocatedclusters)
Posts: 577
Honorable Member
 

This is a very health discussion and I appreciate Yunus' reminder to always ask the phone owner or attorney, if possible, what specific communication(s) and application(s) are of interest. This information is not always available but often times is and the forensic professional forgets to ask for specific examples of "interesting" evidence other parties identified.

I am hoping for some education here, but my understanding is that basically smartphones are file cabinets; some file cabinet drawers are locked and inaccessible to consumers when one buys a smartphone from the store. In these locked and inaccessible to consumer drawers are system files, passwords, credit card information, and other sensitive information Apple and Google do not want consumers (or 3rd party applications) to have access to.

I believe it is possible to change all the locks on one's file cabinet through a process called jail-breaking or rooting, but this makes one's phone inherently insecure and provides a copy of one's file cabinet master key to the jail-breaking/rooting software provider. It would be similar to having a locksmith come change the locks to one's home, but the locksmith is keeping a copy of one's house key and can come and go when they please, and sell information they find out about me from my home activities to 3rd parties.

So my basic understanding of the FBI/Apple issue was that Apple did (does) have a single master key to all iPhones, but did not want to provide a copy of this single master key because if the master key fell into the wrong hands, then it is possible that Apple would lose ownership and control of all of the non-jailbroken iPhones in the world; this could result in massive loss of revenue and jobs to Apple. So basically, when one weighs the immense risk to Apple versus extracting an unknown amount of evidence from one phone, I can see why Apple refused to risk its entire company.

So back to yunus' point my understanding is that Apple iMessages store content in an unlocked file cabinet drawer (currently), which is why forensic tools can recover deleted iMessages without the need for jail-breaking.

QUESTIONS TO THE EXPERTS

Is it possible for 3rd party communication applications to store their SQL databases in one of Apple's locked cabinet drawers and thus to recover deleted evidence, one would need to jail-break the phone first? This is my current understanding of why forensic tools are sometimes unable to extract deleted content the content is stored in a locked file cabinet drawer.

Previous explanations also make sense about the complexity and shifting nature of SQLite database files, which supports the idea one should use multiple tools to validate results (and to yunus' point confirm with the live phone itself).

Could an explanation of why one sees content on a live phone, but not in a forensic report be due to the underlying evidence (SQLite files, etc.) being stored in a locked cabinet drawer? Thanks -

 
Posted : 23/04/2016 4:36 am
aeiforensics
(@aeiforensics)
Posts: 27
Eminent Member
 

I don't want this to turn into an Apple vs FBI thread, so PM me if you want to discuss further, but re your statement, "…my basic understanding of the FBI/Apple issue was that Apple did (does) have a single master key to all iPhones…" - refer to here for more accurate information please and give specific attention to the facts on page 4, lines 7 and 8.

 
Posted : 23/04/2016 5:47 pm
Share: