I'm always frustrated with state of facts, where you are in huge trouble if you need to incorporate data from one forensic tool into another one. It is ridiculous situation, but shows how unmature this market is. Lack of standardization, common formats, compatibility it is state of art :(
Anyhow to stop trolling about troubles what we can do ? Since there is no one like DOD in the networking crisis of 1970, before TCP/IP revolution, who can force all vendors to stop doing silly things and start to cooperate ? We can try to use features and existing tools to put kind of cooperation into action.
Since there is a strong invisible thin line among vendors doing mobile forensics and general forensics it is very hard to combine results this two class of tools.
There are some exceptions like NUIX but let us stay with older generation tools
Let imagine we have set of UFED logical extractions and set of PC images in EnCase we have to look as one job. Ufed things we can combine in UFED , same for PC images in EnCase but we can't process PC stuff in UFED so we have to move to EnCase and try some magic
Strategy is to move UFED data into logical evidence file and turn it somehow into data in EnCase, it will require a lot of scripting to do a full working importer. Idea is to use xml file created by UFED to populate records structure created by hand in EnCase and than later process new L01 file as part of bigger case.
Ill add later some examples and steps, maybe whole script too
Ufed logical extraction structure is well knwon, it is folder named by phone model and timestamp. In that folder there are subfolders and files with artifacts extracted. Key file is report.xml, a xml glue file which wraps all that together.
Search by email pattern and keyword also give some results but still not good enough
Same results we have if we try to work with ufed report file in xml format there we have control on data which are selected for report. Xml parssing is well supported, there are encsript examples hot to parse and bookmark xml, but not much documentation how and where to store parsed data if we like to create L01 file which contains data extracted by ufed. Code which works in close manner exists, Belkaosft integration modules, Magnetforensic tools integration and some others.
One thing which makes all this very unpleasant is fact that in 7.09.05 (and probably earlier versions too) index search by pattern does not work as it is intended (there is this topic raised support issue about PII information idnexing ) simply index pattern for phone numbersdoes not return phone numbers and simmilar does not return email addresses. There is almost nothing about this patterns in documentation only explanation with examples which I found was in that support topic.
This actually makes whole effort senseless because we don't know what also is not working and why.
My unfortunate conclusion is EnCase in current state can't be trusted as integration tool, if you like to analyze together data from mobiles or something similar.
Anyhow to stop trolling about troubles what we can do ? Since there is no one like DOD in the networking crisis of 1970, before TCP/IP revolution, who can force all vendors to stop doing silly things and start to cooperate ? We can try to use features and existing tools to put kind of cooperation into action.
Since there is a strong invisible thin line among vendors doing mobile forensics and general forensics it is very hard to combine results this two class of tools.
There are some exceptions like NUIX but let us stay with older generation tools
Let imagine we have set of UFED logical extractions and set of PC images in EnCase we have to look as one job. Ufed things we can combine in UFED , same for PC images in EnCase but we can't process PC stuff in UFED so we have to move to EnCase and try some magic
Strategy is to move UFED data into logical evidence file and turn it somehow into data in EnCase, it will require a lot of scripting to do a full working importer. Idea is to use xml file created by UFED to populate records structure created by hand in EnCase and than later process new L01 file as part of bigger case.
Ill add later some examples and steps, maybe whole script too
Ufed logical extraction structure is well knwon, it is folder named by phone model and timestamp. In that folder there are subfolders and files with artifacts extracted. Key file is report.xml, a xml glue file which wraps all that together.
File report.xml is glue to keep findings together in ufed folder.
In enscript we have various code examples for creating L01, for xmls parsing but what we don't have is a mechanism to map UFED data to EnCase phone extraction record structure. This is a guessing task, to be done by custom enscript.
EnCase view on the Ufed data stored in L01 file.
In EnCase in preview pane xml structure is easy visible, we can use Generic XML viewer plugin to see deeper into xml structure. It is easy to bookmark it or preview it.
Structure of the file is visible, very intuitive, but not directly related to structure how encase present phones.
If we use Report.htm instead of Report.xml, it actually requires less work but data is still not too usefull.
It is possible to do indexing on evidence so search is possible to find out relevant data about phone results. Unfortunately this also does not provide full access to imporatnt information.
Same situation we have with other artifacts, slightly better is with email addresses and phone numbers since there is a set of pasterns predefined in search.
Search by email pattern and keyword also give some results but still not good enough
Same results we have if we try to work with ufed report file in xml format there we have control on data which are selected for report. Xml parssing is well supported, there are encsript examples hot to parse and bookmark xml, but not much documentation how and where to store parsed data if we like to create L01 file which contains data extracted by ufed. Code which works in close manner exists, Belkaosft integration modules, Magnetforensic tools integration and some others.
One thing which makes all this very unpleasant is fact that in 7.09.05 (and probably earlier versions too) index search by pattern does not work as it is intended (there is this topic raised support issue about PII information idnexing ) simply index pattern for phone numbers
This actually makes whole effort senseless because we don't know what also is not working and why.
My unfortunate conclusion is EnCase in current state can't be trusted as integration tool, if you like to analyze together data from mobiles or something similar.
No comments:
Post a Comment