Difference between pages "3+1 data recovery" and "Windows SuperFetch Format"

From ForensicsWiki
(Difference between pages)
Jump to: navigation, search
(Created page with '== Overview == 3+1 Data Recovery: to know the broad sense data recovery better There is more data you can recover from your client's drives. Let [http://www.salvationdata.com S…')
 
 
Line 1: Line 1:
== Overview ==
+
{{expand}}
  
3+1 Data Recovery: to know the broad sense data recovery better
+
SuperFetch, is a memory management scheme that enhances the least-recently accessed approach with historical information and proactive memory management. [http://technet.microsoft.com/en-us/magazine/2007.03.vistakernel.aspx]
  
There is more data you can recover from your client's drives. Let [http://www.salvationdata.com SalvationDATA]Data Recovery Systems show you what is a broad sense data recovery approach.
+
<b>Note that the following format specification are incomplete.</b>
  
SalvationDATA Data Recovery Solutions pioneered the Broad Sense Data Recovery Approach – A professional approach contains three plus one (3+1) aspects (listed below). SalvationDATA has now developed manufacturer-level tools, in-depth trainings & materials and tech-support services to deal with the challenges of all 3+1 aspects. You could click on each stage listed below to know more about them
+
== SuperFetch DB files ==
[[File:http://www.salvationdata.com/images/3+1-data-recovery.jpg]]
+
The <tt>Ag*.db</tt> files are of the SuperFetch file format. E.g.
 +
<pre>
 +
AgAppLaunch.db
 +
AgCx_SC*.db
 +
AgGlFaultHistory.db
 +
AgGlFgAppHistory.db
 +
AgGlGlobalHistory.db
 +
AgGlUAD_%SID%.db
 +
AgGlUAD_P_%SID%.db
 +
AgRobust.db
 +
</pre>
  
== The Pretext of 3+1 Data Recovery ==
+
The SuperFetch DB files can be stored in uncompressed or compressed form, where different version of Windows use different compressed forms:
 +
* Compressed SuperFetch DB - MEMO file format; Windows Vista
 +
* Compressed SuperFetch DB - MEM0 file format; Windows  7
 +
* Compressed SuperFetch DB - MAM file format; Windows 8
  
At SalvationDATA, from the existed approach contains 3 stages only, we felt that the data recovery industry was in need of a more comprehensive approach to the broad sense data recovery need that handles all aspects: microcode, hardware component, bad sector/ instable head and file system. Many companies were claiming to do "full" data recovery, but were in fact only doing the data-level recovery probably by downloading software, while in the meantime 40%-50% potential data on the lower level is left behind, or worse, gone forever. The SalvationDATA 3+1 Data Recovery approach addresses hardware-level and software-level issues like microcode, hardware component, bad sector/ instable head and file system so that to make sure the maximum amount of data is retrieved.
+
=== Compressed SuperFetch DB - MEMO file format ===
 +
The MEM file consists of:
 +
* file header
 +
* compressed blocks
  
== An approach developed and spread from the wrong side ==
+
This format uses the LZNT1 compression method
  
By understanding thoroughly the SalvationDATA 3+1 Data Recovery flow, when we look back to the days without this concept, we will find that the data recovery stages included in the flow were developed and known from the wrong end.
+
==== File header ====
 +
The file header is 84 bytes of size and consists of:
 +
{| class="wikitable"
 +
|-
 +
! Offset
 +
! Size
 +
! Value
 +
! Description
 +
|-
 +
| 0
 +
| 4
 +
| "MEMO" (0x4d, 0x45, 0x4d, 0x4f)
 +
| Signature
 +
|-
 +
| 4
 +
| 4
 +
|
 +
| Uncompressed (total) data size
 +
|-
 +
|}
  
Stage 3, of all the stages,, data retrieval, is the most widely spread and long-running; all data recovery companies, even end users, by downloading software, can handle mission of this stage easily. But according to SalvationDATA experts only 30%- 40% percent of all data recovery cases are simply stage 3 cases. The left percentage requires an ability to handle with the stage 2 and stage 1&+1 issues.
+
==== Compressed blocks ====
 +
The compressed block size is the chunk data size, which is part of the LZNT1 compressed data, + 2 bytes for the size of the chunk header itself.
  
Stage 2, disk data extraction, is also widely known and adopted as “disk imaging” by data recovery services nowadays. But to SalvationDATA, according our experience with lots of potential clients, they perform this important stage using ghosting tools designed for and work on good HDDs only, not the patient HDDs that are unstable or inaccessible because of media defects and instable head, which are common challenges of Stage 2 in practice. Even more, with those traditional imaging tools, the time involved and the ordinary user-level repeated-read access to the media bring a risk of damaging the disk and head, making data lost irretrievable.
+
The uncompressed block size is 4096 (0x1000) or the remaining uncompressed data size for the last block.
  
Stage 1, drive diagnosis & restoration, is the primary stage in a broad sense data recovery flow but in fact deals with the deepest level in 3+1 broad sense data recovery flow. Unfortunately this Stage 1 is missing from most of the data recovery services or even noticed but was being done in a zigzag procedure or simply incorrectly due to lack of proper tools, meaning that they are putting away customers and profits. Our data has shown that up to 40% of data recovery cases have Stage 1 issues; and that IS NOT what going to happen that we can skip Stage 1 and perform Stage 2 and 3 and still to get certain percentage of data. You CAN NOT get anything in case you are not capable for the primary stage.
+
=== Compressed SuperFetch DB - MEM0 file format ===
 +
The MEM file consists of:
 +
* file header
 +
* compressed blocks
  
Stage +1, hardware component exchanging, is an extra but very important stage follows the Stage 1 diagnosis. This special stage handles with hardware component issues which can't be repaired but the only solution is to have the components exchanged using donor parts. Strictly speaking, Stage +1 is part of Stage 1: Drive Restoration; but we specially separate it from Stage 1 since it is kind of different level issue composing the comprehensive data recovery flow.
+
This format uses the LZXPRESS Huffman compression method
  
The 3+1 Broad Sense Data Recovery flow starts with the deepest level issues where the shoe pinches: Drive In-depth diagnosis and Restoration (include microcode level restoration as well as hardware component exchanging), and then the much more direct disk data extraction, and finally goes to the stage 3 which appears to be the most fruitful but in fact is the most common and the easiest one handles with the thinnest level issues.
+
==== File header ====
 +
The file header is 84 bytes of size and consists of:
 +
{| class="wikitable"
 +
|-
 +
! Offset
 +
! Size
 +
! Value
 +
! Description
 +
|-
 +
| 0
 +
| 4
 +
| "MEM0" (0x4d, 0x45, 0x4d, 0x30)
 +
| Signature
 +
|-
 +
| 4
 +
| 4
 +
|
 +
| Uncompressed (total) data size
 +
|-
 +
|}
 +
 
 +
==== Compressed blocks ====
 +
The file header is followed by compressed blocks:
 +
{| class="wikitable"
 +
|-
 +
! Offset
 +
! Size
 +
! Value
 +
! Description
 +
|-
 +
| 0
 +
| 4
 +
|
 +
| Compressed data size
 +
|-
 +
| 4
 +
| ...
 +
|
 +
| Compressed data
 +
|-
 +
|}
 +
 
 +
The uncompressed block size is 65536 (0x10000) or the remaining uncompressed data size for the last block.
 +
 
 +
=== Compressed SuperFetch DB - MAM file format ===
 +
The MAM file consists of:
 +
* file header
 +
* compressed blocks
 +
 
 +
This format uses the <b>TODO</b> compression method
 +
 
 +
==== File header ====
 +
<b>TODO</b>
 +
 
 +
{| class="wikitable"
 +
|-
 +
! Offset
 +
! Size
 +
! Value
 +
! Description
 +
|-
 +
| 0
 +
| 4
 +
| "MAM\x84" (0x4d, 0x41, 0x4d, 0x84)
 +
| Signature
 +
|-
 +
|}
 +
 
 +
==== Compressed blocks ====
 +
<b>TODO</b>
 +
 
 +
=== Uncompressed SuperFetch DB format ===
 +
<b>TODO</b>
 +
 
 +
==== File header ====
 +
<b>TODO</b>
 +
 
 +
{| class="wikitable"
 +
|-
 +
! Offset
 +
! Size
 +
! Value
 +
! Description
 +
|-
 +
| 0
 +
| 4
 +
| 0x0000000e
 +
| Unknown (Database type or signature?)
 +
|-
 +
| 4
 +
| 4
 +
|
 +
| Uncompressed (total) data size
 +
|-
 +
|}
 +
== TRX files ==
 +
The <tt>Ag*.db.trx</tt> files are of the TRX file format. E.g.
 +
<pre>
 +
AgCx_SC*.db.trx
 +
</pre>
 +
 
 +
<b>Note that the following format specification is incomplete.</b>
 +
 
 +
=== File header ===
 +
The file header is variable of size and consists of:
 +
{| class="wikitable"
 +
|-
 +
! Offset
 +
! Size
 +
! Value
 +
! Description
 +
|-
 +
| 0
 +
| 4
 +
| 1
 +
| Unknown (Version?)
 +
|-
 +
| 4
 +
| 4
 +
|
 +
| Unknown
 +
|-
 +
| 8
 +
| 4
 +
|
 +
| File size
 +
|-
 +
| 12
 +
| 4
 +
|
 +
| Maximum number of records (of the record offsets array)
 +
|-
 +
| 16
 +
| 4
 +
|
 +
| Number of records
 +
|-
 +
| 20
 +
| ...
 +
|
 +
| Record offsets array, where the record offset is a 32-bit integer. Unused record offset are set to 0.
 +
|-
 +
|}
 +
 
 +
=== Record ===
 +
<b>TODO describe</b>
 +
 
 +
== See Also ==
 +
* [[SuperFetch]]
 +
 
 +
== External Links ==
 +
* [http://technet.microsoft.com/en-us/magazine/2007.03.vistakernel.aspx Inside the Windows Vista Kernel: Part 2], by [[Mark Russinovich]], March 2007
 +
* [http://blog.rewolf.pl/blog/?p=214 Windows SuperFetch file format – partial specification], by ReWolf, October 5, 2011
 +
 
 +
[[Category:File Formats]]

Revision as of 00:41, 23 April 2014

Information icon.png

Please help to improve this article by expanding it.
Further information might be found on the discussion page.

SuperFetch, is a memory management scheme that enhances the least-recently accessed approach with historical information and proactive memory management. [1]

Note that the following format specification are incomplete.

SuperFetch DB files

The Ag*.db files are of the SuperFetch file format. E.g.

AgAppLaunch.db
AgCx_SC*.db
AgGlFaultHistory.db
AgGlFgAppHistory.db
AgGlGlobalHistory.db
AgGlUAD_%SID%.db
AgGlUAD_P_%SID%.db
AgRobust.db

The SuperFetch DB files can be stored in uncompressed or compressed form, where different version of Windows use different compressed forms:

  • Compressed SuperFetch DB - MEMO file format; Windows Vista
  • Compressed SuperFetch DB - MEM0 file format; Windows 7
  • Compressed SuperFetch DB - MAM file format; Windows 8

Compressed SuperFetch DB - MEMO file format

The MEM file consists of:

  • file header
  • compressed blocks

This format uses the LZNT1 compression method

File header

The file header is 84 bytes of size and consists of:

Offset Size Value Description
0 4 "MEMO" (0x4d, 0x45, 0x4d, 0x4f) Signature
4 4 Uncompressed (total) data size

Compressed blocks

The compressed block size is the chunk data size, which is part of the LZNT1 compressed data, + 2 bytes for the size of the chunk header itself.

The uncompressed block size is 4096 (0x1000) or the remaining uncompressed data size for the last block.

Compressed SuperFetch DB - MEM0 file format

The MEM file consists of:

  • file header
  • compressed blocks

This format uses the LZXPRESS Huffman compression method

File header

The file header is 84 bytes of size and consists of:

Offset Size Value Description
0 4 "MEM0" (0x4d, 0x45, 0x4d, 0x30) Signature
4 4 Uncompressed (total) data size

Compressed blocks

The file header is followed by compressed blocks:

Offset Size Value Description
0 4 Compressed data size
4 ... Compressed data

The uncompressed block size is 65536 (0x10000) or the remaining uncompressed data size for the last block.

Compressed SuperFetch DB - MAM file format

The MAM file consists of:

  • file header
  • compressed blocks

This format uses the TODO compression method

File header

TODO

Offset Size Value Description
0 4 "MAM\x84" (0x4d, 0x41, 0x4d, 0x84) Signature

Compressed blocks

TODO

Uncompressed SuperFetch DB format

TODO

File header

TODO

Offset Size Value Description
0 4 0x0000000e Unknown (Database type or signature?)
4 4 Uncompressed (total) data size

TRX files

The Ag*.db.trx files are of the TRX file format. E.g.

AgCx_SC*.db.trx

Note that the following format specification is incomplete.

File header

The file header is variable of size and consists of:

Offset Size Value Description
0 4 1 Unknown (Version?)
4 4 Unknown
8 4 File size
12 4 Maximum number of records (of the record offsets array)
16 4 Number of records
20 ... Record offsets array, where the record offset is a 32-bit integer. Unused record offset are set to 0.

Record

TODO describe

See Also

External Links