The '''Cellebrite 'Universal Forensic Extraction Device' (UFED)''' is a tool for mobile phone, smartphone, and PDA forensics. As of September 2010 the UFED was compatible with over 2,500 mobile phones (including GSM, TDMS, CDMA, iDEN). The standard package containing several dozen phone cables. The UFED had an intergrated SIM reader, with Wireless connection options also being integrated, such as IR and Bluetooth.

+

Please, do not delete text (ideas) here. Use something like this:

−

The UFED also supports native Apple iPOD Touch, and Apple iPHONE extraction on both 2G and 3G versions, as well as iOS4. This is clientless, and via a physical cable, and works on jailbroken and non-jailbroken devices.

+

<pre>

+

<s>bad idea</s>

+

:: good idea

+

</pre>

−

Subject data can be retrieved via logical extraction or via physical extraction (ie: hex dump). Moreover, all cable connectors from subject (source) side act as a write-blocker, being read only via the onboard hardware chipset. Extracted data includes basic handset data, the phonebook, SMS and MMS messages, SIM data, multimedia (e.g. images and videos stored on the phone), and time and date stamps.

** [[User:Joachim Metz|Joachim]] The validator should deal with the file structure the carving algorithm should not know anything about the file structure (as in revit07 design)

+

** Either extend Scalpel/Foremost syntaxes for extended features or use a tertiary syntax ([[User:Joachim Metz|Joachim]] I would prefer a derivative of the revit07 configuration syntax which already has encountered some problems of dealing with defining file structure in a configuration file)

** [[User:Joachim Metz|Joachim]] I'm no native speaker what do you mean with "ascription software"?

+

+

= Ideas =

+

* Use as much TSK if possible. Don't carry your own FS implementation the way photorec does.

+

** [[User:Joachim Metz|Joachim]] using TSK as much as possible would not allow to add your own file system support (i.e. mobile phones, memory structures, cap files)

+

I would propose wrapping TSK and using it as much as possible but allow to integrate own FS implementations.

+

* Extracting/carving data from [[Thumbs.db]]? I've used [[foremost]] for it with some success. [[Vinetto]] has some critical bugs :( [[User:.FUF|.FUF]] 19:18, 28 October 2008 (UTC)

+

* Carving data structures. For example, extract all TCP headers from image by defining TCP header structure and some fields (e.g. source port > 1024, dest port = 80). This will extract all data matching the pattern and write a file with other fields. Another example is carving INFO2 structures and URL activity records from index.dat [[User:.FUF|.FUF]] 20:51, 28 October 2008 (UTC)

+

** This has the opportunity to be extended to the concept of "point at blob FOO and interpret it as BAR"

+

+

.FUF added:

+

The main idea is to allow users to define structures, for example (in pascal-like form):

+

+

<pre>

+

Field1: Byte = 123;

+

SomeTextLength: DWORD;

+

SomeText: string[SomeTextLength];

+

Field4: Char = 'r';

+

...

+

</pre>

+

+

This will produce something like this:

+

<pre>

+

Field1 = 123

+

SomeTextLength = 5

+

SomeText = 'abcd1'

+

Field4 = 'r'

+

</pre>

+

+

(In text or raw forms.)

+

+

Opinions?

+

+

Opinion: Simple pattern identification like that may not suffice, I think Simson's original intent was not only to identify but to allow for validation routines (plugins, as the original wording was). As such, the format syntax would need to implement a large chunk of some programming language in order to be sufficiently flexible. [[User:RB|RB]]

+

+

=File System Awareness =

+

==Background: Why be File System Aware?==

+

Advantages of being FS aware:

+

* You can pick up sector allocation sizes ([[User:Joachim Metz|Joachim]] do you mean file system block sizes?)

:: As noted above, TSK should be utilized as much as possible, particularly the filesystem-aware portion. If we want to identify filesystems outside of its supported set, it would be more worth our time to work on implementing them there than in the carver itself. [[User:RB|RB]]

+

+

[[User:Joachim Metz|Joachim]] I would like to have the carver (recovery tool) also do recovery using file allocation data or remainders of file allocation data.

+

+

:::: I guess this tool operates like [[Selective file dumper]] and can recover files in both ways (or not?). Recovering files by using carving can recover files in situations where sleuthkit does nothing (e.g. file on NTFS was deleted using ntfs-3g, or filesystem was destroyed or just unknown). And we should build the list of filesystems supported by carver, not by TSK. [[User:.FUF|.FUF]] 07:08, 29 October 2008 (UTC)

+

+

:: This tool is still in the early planning stages (requirements discovery), hence few operational details (like precise modes of operation) have been fleshed out - those will and should come later. The justification for strictly using TSK for the filesystem-sensitive approach is simple: TSK has good filesystem APIs, and it would be foolish to create yet another standalone, incompatible implementation of filesystem(foo) when time would be better spent improving those in TSK, aiding other methods of analysis as well. This is the same reason individuals that have implemented several other carvers are participating: de-duplication of effort. [[User:RB|RB]]

+

+

[[User:Joachim Metz|Joachim]]

+

I would go as far to ask you all to look beyond the carver as a tool and look from the perspective of the carver as part of the forensic investigation process. In my eyes certain information needed/acquired by the carver could be also very useful investigative information i.e. what part of a hard disk contains empty sectors.

+

+

[[User:Joachim Metz|Joachim]]

+

I'm missing a part on the page about the carving challenges (scenarios)

Joachim The validator should deal with the file structure the carving algorithm should not know anything about the file structure (as in revit07 design)

Either extend Scalpel/Foremost syntaxes for extended features or use a tertiary syntax (Joachim I would prefer a derivative of the revit07 configuration syntax which already has encountered some problems of dealing with defining file structure in a configuration file)

Opinion: Simple pattern identification like that may not suffice, I think Simson's original intent was not only to identify but to allow for validation routines (plugins, as the original wording was). As such, the format syntax would need to implement a large chunk of some programming language in order to be sufficiently flexible. RB

File System Awareness

Background: Why be File System Aware?

Advantages of being FS aware:

You can pick up sector allocation sizes (Joachim do you mean file system block sizes?)

Some file systems may store things off sector boundaries. (ReiserFS with tail packing)

Increasingly file systems have compression (NTFS compression)

Carve just the sectors that are not in allocated files.

Tasks that would be required

Discussion

As noted above, TSK should be utilized as much as possible, particularly the filesystem-aware portion. If we want to identify filesystems outside of its supported set, it would be more worth our time to work on implementing them there than in the carver itself. RB

Joachim I would like to have the carver (recovery tool) also do recovery using file allocation data or remainders of file allocation data.

I guess this tool operates like Selective file dumper and can recover files in both ways (or not?). Recovering files by using carving can recover files in situations where sleuthkit does nothing (e.g. file on NTFS was deleted using ntfs-3g, or filesystem was destroyed or just unknown). And we should build the list of filesystems supported by carver, not by TSK. .FUF 07:08, 29 October 2008 (UTC)

This tool is still in the early planning stages (requirements discovery), hence few operational details (like precise modes of operation) have been fleshed out - those will and should come later. The justification for strictly using TSK for the filesystem-sensitive approach is simple: TSK has good filesystem APIs, and it would be foolish to create yet another standalone, incompatible implementation of filesystem(foo) when time would be better spent improving those in TSK, aiding other methods of analysis as well. This is the same reason individuals that have implemented several other carvers are participating: de-duplication of effort. RB

Joachim
I would go as far to ask you all to look beyond the carver as a tool and look from the perspective of the carver as part of the forensic investigation process. In my eyes certain information needed/acquired by the carver could be also very useful investigative information i.e. what part of a hard disk contains empty sectors.

Joachim
I'm missing a part on the page about the carving challenges (scenarios)