dataextractor udma new

ACE Laboratory Data Extractor UDMA ®

ACE Laboratory Ltd, Russia, Unauthorized copy or distribution of these documents is prohibited

www.acelaboratory.com 1

Table of contents

1 General information....................................................................................................................................................5 1.1 Purpose. ................................................................................................................................................................5 1.2 Hardware and software requirements. ..................................................................................................................5

2 Product distribution kit. ..............................................................................................................................................6 3 Getting started. ...........................................................................................................................................................7

3.1 First program launch. ............................................................................................................................................7 4 Description of program functionality. ........................................................................................................................9

4.1 General principles of control and data output. ......................................................................................................9 4.2 Basic notions and definitions. ...............................................................................................................................9 4.3 Task Manager window..........................................................................................................................................9

4.3.1 Items of the Task main menu. ....................................................................................................................10 4.3.1.1 New task................................................................................................................................................10 4.3.1.2 Open task...............................................................................................................................................10 4.3.1.3 List of recent tasks. ...............................................................................................................................10

4.3.2 Items of the Options main menu.................................................................................................................10 4.3.2.1 Working folder. .....................................................................................................................................10 4.3.2.2 "Read only" devices. .............................................................................................................................11

4.3.3 Quick access toolbar...................................................................................................................................11 4.4 Creation of a data recovery task..........................................................................................................................12

4.4.1 Folder selection for task data storage. ........................................................................................................12 4.4.2 Source device selection. .............................................................................................................................13 4.4.3 Task initialization. ......................................................................................................................................14 4.4.4 Additional settings......................................................................................................................................14

4.4.4.1 Make data copy. ....................................................................................................................................15 4.4.4.2 Create virtual translator.........................................................................................................................15 4.4.4.3 Use active PC-3000 utility. ...................................................................................................................15

4.4.5 Destination device selection. ......................................................................................................................15 4.4.6 Task comments. ..........................................................................................................................................16

4.5 Opening an existing task.....................................................................................................................................17 4.6 Primary window of the data recovery task..........................................................................................................17

4.6.1 Main menu of the primary task window.....................................................................................................18 4.6.1.1 The "Options" menu..............................................................................................................................18 4.6.1.2 Task options. .........................................................................................................................................18 4.6.1.3 Task options for cases, when the source drive is connected to a port of the PC-3000 UDMA board. 18 4.6.1.4 The "Copying" tab.................................................................................................................................18 4.6.1.5 The "Command to read" tab..................................................................................................................19 4.6.1.6 The "HDD power supply" tab. ..............................................................................................................20 4.6.1.7 The "Error handling" tab. ......................................................................................................................20 4.6.1.8 The "Loss of readiness" tab...................................................................................................................21 4.6.1.9 The "Heads map" tab.............................................................................................................................22 4.6.1.10 Reference. .............................................................................................................................................24 4.6.1.11 Settings for data recovery from a device connected to standard port....................................................24 4.6.1.12 Settings for data export from image files. .............................................................................................25 4.6.1.13 Task info. ..............................................................................................................................................26 4.6.1.14 GREP expressions.................................................................................................................................26 4.6.1.15 Regular expression concept...................................................................................................................26 4.6.1.16 Regular expression syntax.....................................................................................................................26 4.6.1.17 Using the reference. ..............................................................................................................................27 4.6.1.18 Raw recovery reference book................................................................................................................28 4.6.1.19 The "Service" menu. .............................................................................................................................29 4.6.1.20 HDD control..........................................................................................................................................29 4.6.1.21 Standby command. ................................................................................................................................29

Data Extractor UDMA ® ACE Laboratory

Unauthorized copy or distribution of these documents is prohibited. ACE Laboratory Ltd, Russia, 2 www.acelaboratory.com

4.6.1.22 "Recalibration" command......................................................................................................................30 4.6.1.23 Software reset. .......................................................................................................................................30 4.6.1.24 Hardware reset.......................................................................................................................................30 4.6.1.25 Complex initialization. ..........................................................................................................................30 4.6.1.26 Disable read look-ahead. .......................................................................................................................30 4.6.1.27 Disable "AutoRelocation" while reading (HDD RAM). .......................................................................30 4.6.1.28 Turn off/on drive’s power (F12). ..........................................................................................................30 4.6.1.29 Calculators.............................................................................................................................................30 4.6.1.30 FAT – Root sector. ................................................................................................................................30 4.6.1.31 FAT – partition size...............................................................................................................................31 4.6.1.32 Explorer. ................................................................................................................................................31 4.6.1.33 GREP search..........................................................................................................................................31 4.6.1.34 Verification............................................................................................................................................31 4.6.1.35 Raw recovery.........................................................................................................................................31 4.6.1.36 Copy region. ..........................................................................................................................................31

4.6.2 Quick access toolbar. ..................................................................................................................................32 4.6.3 Informational panel....................................................................................................................................32 4.6.4 Log panel. ...................................................................................................................................................32

4.6.4.1 The "Log" tab. .......................................................................................................................................32 4.6.4.2 The "Map" tab. ......................................................................................................................................33 4.6.4.3 Map navigation......................................................................................................................................33 4.6.4.4 Legend. ..................................................................................................................................................33 4.6.4.5 The "HEX" tab. .....................................................................................................................................34

4.7 Basic modes. .......................................................................................................................................................34 4.7.1 Data area copy creation. .............................................................................................................................34 4.7.2 Data copy export mode. ..............................................................................................................................35 4.7.3 Explorer mode. ...........................................................................................................................................36

4.7.3.1 Appearance, controls and navigation. ...................................................................................................36 4.7.3.2 Explorer objects.....................................................................................................................................37 4.7.3.3 Master Boot Record (MBR). .................................................................................................................38 4.7.3.4 Partition Entry. ......................................................................................................................................41 4.7.3.5 Partition boot sector (boot)....................................................................................................................42 4.7.3.6 Common methods available for all types of partitions. .........................................................................42 4.7.3.7 Additional methods for FAT partitions. ................................................................................................43 4.7.3.8 Additional methods for NTFS partitions. ..............................................................................................45 4.7.3.9 Additional methods for Ext2(3) partitions. ...........................................................................................47 4.7.3.10 Additional methods for UFS1(2) partitions...........................................................................................48 4.7.3.11 Additional methods for HFS+ partitions. ..............................................................................................49 4.7.3.12 Directories and files...............................................................................................................................50 4.7.3.13 Mode peculiarities during data recovery. ..............................................................................................55

4.7.4 Virtual translator creation. ..........................................................................................................................58 4.7.4.1 Shifts table.............................................................................................................................................60 4.7.4.2 Using an object map during translator rebuilding. ................................................................................61 4.7.4.3 Methods for automatic searching and addition of shifts for FAT partitions. ........................................66 4.7.4.4 Seek shift points for FAT copies. ..........................................................................................................66 4.7.4.5 Searching for shift points in FAT subdirectories. .................................................................................66 4.7.4.6 Seek shift points for files.......................................................................................................................67 4.7.4.7 Virtual translator creation for an NTFS partition. .................................................................................68 4.7.4.8 List of non-resident files........................................................................................................................69 4.7.4.9 Limitations of the method. ....................................................................................................................70

4.7.5 The "Mount task as a drive" mode..............................................................................................................71 4.8 Auxiliary modes. .................................................................................................................................................72

4.8.1 The "Object map" mode. ............................................................................................................................72 4.8.2 Verification. ................................................................................................................................................77 4.8.3 GREP search...............................................................................................................................................78 4.8.4 Shift search. ................................................................................................................................................80 4.8.5 Raw recovery. .............................................................................................................................................81 4.8.6 Partition analysis (for FAT file system)......................................................................................................84

4.8.6.1 Peculiarities of mode use.......................................................................................................................88 4.8.7 MFT scanning.............................................................................................................................................88




4.8.8 Automatic restoration of NTFS partitions. .................................................................................................89 4.8.9 Copying a region of sectors........................................................................................................................92 4.8.10 View and edit sector. ..................................................................................................................................93

4.8.10.1 "Data" menu item. .................................................................................................................................93 4.8.10.2 "Editing" menu item..............................................................................................................................93 4.8.10.3 "View as…" menu item.........................................................................................................................94 4.8.10.4 "Options" menu item. ............................................................................................................................98 4.8.10.5 Quick access toolbar. ............................................................................................................................98 4.8.10.6 Viewing and editing panel, its tabs. ......................................................................................................98 4.8.10.7 Status and additional information panel..............................................................................................100

4.8.11 MFT record editor. ...................................................................................................................................101 4.8.11.1 Purpose................................................................................................................................................101 4.8.11.2 Appearance and controls. ....................................................................................................................101 4.8.11.3 Toolbar. ...............................................................................................................................................101 4.8.11.4 HEX editor panel ................................................................................................................................102 4.8.11.5 Methods available in the HEX editor panel ........................................................................................103 4.8.11.6 Tree panel............................................................................................................................................104 4.8.11.7 Methods available in the tree panel.....................................................................................................105 4.8.11.8 Restoration example. MFT record with multiple random corruptions................................................106

4.8.12 MacOS Metadata Editor. ..........................................................................................................................112 4.8.12.1 Purpose................................................................................................................................................112 4.8.12.2 Appearance and controls. ....................................................................................................................112 4.8.12.3 Toolbar ................................................................................................................................................112 4.8.12.4 HEX editor panel. ...............................................................................................................................113 4.8.12.5 Methods available in the HEX editor panel. .......................................................................................113 4.8.12.6 Tree panel............................................................................................................................................113 4.8.12.7 Methods available in the tree panel.....................................................................................................114

5 Data recovery. ........................................................................................................................................................115 5.1 Causes of physical drive malfunctions..............................................................................................................115

5.1.1 Bad sectors. ..............................................................................................................................................115 5.1.1.1 Malfunctions pertaining to damaged servo labels on a drive. .............................................................115 5.1.1.2 Malfunction of the magnetic head assembly (MHA). .........................................................................116 5.1.1.3 Corruption of drive service data and resulting inoperability...............................................................116 5.1.1.4 Other causes resulting in inaccessibility of user data on a drive.........................................................116

5.1.2 Causes of logical data corruption. ............................................................................................................116 5.1.2.1 Failures in file system operation. ........................................................................................................116 5.1.2.2 Incorrect user actions - erasure, formatting, etc. .................................................................................117 5.1.2.3 Consequences of virus activity............................................................................................................118

5.2 Preliminary diagnostics of the drive under examination...................................................................................118 5.2.1 Drive electronic board malfunction..........................................................................................................118 5.2.2 Drive spindle motor malfunction..............................................................................................................119 5.2.3 Drive MHA malfunction. .........................................................................................................................119 5.2.4 Service data erasure..................................................................................................................................120

5.3 Data recovery using Data Extractor UDMA.....................................................................................................121 5.3.1 General methods and settings in case of physical damage. ......................................................................122

5.3.1.1 A drive with defective sectors but without knocking sounds during work. ........................................122 5.3.1.2 A drive failing while reading defective sectors...................................................................................122 5.3.1.3 A drive that has problems reading servo labels and produces knocking sounds. ...............................123 5.3.1.4 Imitating readiness loss. ......................................................................................................................123 5.3.1.5 A drive with magnetic head assembly problems.................................................................................124

5.3.2 Using Explorer for work with a malfunctioning drive. ............................................................................124 5.3.2.1 Restoration of MBR and boot sectors. ................................................................................................125 5.3.2.2 Valid MBR, corrupted boot sector of a partition. ...............................................................................125 5.3.2.3 MBR corrupted, boot sectors are valid................................................................................................125 5.3.2.4 MBR is corrupted and boot sector of the first partition is missing. ....................................................126 5.3.2.5 Recovery of partition metadata. ..........................................................................................................126 5.3.2.6 Recovery of FAT partition metadata...................................................................................................126 5.3.2.7 Recovery of NTFS partition metadata.................................................................................................126 5.3.2.8 Recovery of Ext2(3) partition metadata. .............................................................................................127 5.3.2.9 Recovery of UFS1(2) partition metadata. ...........................................................................................127



5.3.2.10 Using the map of occupied sectors. .....................................................................................................127 5.3.2.11 Selective data saving in Explorer using the directory and object maps...............................................128 5.3.2.12 Using the heads map to recover data from WD drives .......................................................................128

5.3.3 Data recovery in case of translator corruption..........................................................................................129 5.3.3.1 Meaning of negative shifts and data "collapse"...................................................................................130 5.3.3.2 Translator regeneration for FAT partitions. ........................................................................................130 5.3.3.3 Translator regeneration for NTFS partitions. ......................................................................................133

5.3.4 Data recovery in case of logical damage. .................................................................................................134 5.3.4.1 Using the map of unused sectors. ........................................................................................................135

6 Reference. .............................................................................................................................................................. 136 6.1 Master Boot Record and partition table. ...........................................................................................................136 6.2 Logical drive with FAT file system. .................................................................................................................139

6.2.1 Logical drive with FAT12/16 file system.................................................................................................139 6.2.2 Logical drive with FAT32 file system. .....................................................................................................144

6.3 Logical drive with NTFS file system. ...............................................................................................................149 6.3.1 Boot sector. ...............................................................................................................................................149 6.3.2 Master file table (MFT). ...........................................................................................................................151 6.3.3 File Records. .............................................................................................................................................152 6.3.4 Update Sequence. .....................................................................................................................................153 6.3.5 Attributes. .................................................................................................................................................154

6.3.5.1 Standard information attribute ($STANDARD_INFORMATION, 10h) ...........................................158 6.3.5.2 List of attributes ($ATTRIBUTE_LIST, 20h). ...................................................................................158 6.3.5.3 File name attribute ($FILE_NAME, 30h). ..........................................................................................159

6.3.6 Data Runs. ................................................................................................................................................160 6.3.7 Metafiles. ..................................................................................................................................................161

6.4 Logical drive with Ext2,3file system. ...............................................................................................................162 6.4.1 Superblock. ...............................................................................................................................................162 6.4.2 Table of group descriptors. .......................................................................................................................164 6.4.3 Blocks. ......................................................................................................................................................165 6.4.4 Index nodes...............................................................................................................................................165 6.4.5 Extended attributes. ..................................................................................................................................167 6.4.6 Directory record........................................................................................................................................168 6.4.7 Symbolic link............................................................................................................................................168

6.5 Logical drive with UFS1,2 file system..............................................................................................................169 6.5.1 Superblock. ...............................................................................................................................................169 6.5.2 Cylinder summary information.................................................................................................................171 6.5.3 Group descriptor. ......................................................................................................................................171 6.5.4 Bit maps of blocks and fragments.............................................................................................................172 6.5.5 Index nodes...............................................................................................................................................173 6.5.6 UFS2 extended attributes..........................................................................................................................174 6.5.7 Directory records. .....................................................................................................................................174




1 General information. Attention! The program can only function in tandem with a PC-3000 UDMA tester board (with an appropriate

power supply adapter).

The software is adjusted specifically for operation with an individual PC-3000 UDMA tester board. Each board has its own ID number matching the number of your license.

The program will operate incorrectly if used with another board!

1.1 Purpose. Data Extractor UDMA software and hardware suite is a professional data recovery instrument. The suite

allows data recovery from IDE drives connected to the ATA0 and ATA1 ports of a PC-3000 UDMA tester board and from any other data storage device connected to standard ports provided that such device can be identified by the operating system.

SATA drives can be connected to the ports of the PC-3000 UDMA tester board using a corresponding adapter.

You can work with drives using LBA48 addressing connected via the IDE ports of the PC-3000 UDMA board.

Configuration jumpers of the drives connected to PC-3000 UDMA ports must be set to “Master Only” mode.

Fields of suite application: − data recovery from physically malfunctioning HDD − data recovery in cases of damaged logical structures − combination of the above two cases.

Under physically malfunctioning devices we mean here IDE or SATA drives with damaged disk surfaces or head assembly and corrupted service information resulting in unstable reading and multiple errors, troubles with the system coordinating logical block addressing (LBA) with actual HDD geometry (translator).

In many cases the system allows successful recovery of data from physically malfunctioning HDD even when their magnetic head assembly or disk surfaces are damaged.

In case of translator problems the program allows creation of a map of resulting data shifts subsequently using the map to access and copy the required data from a damaged drive.

Under logical structure damage we mean here such damage to logical structures, which prevents access to user data by means of the operating system. The damage may be caused by failures or malfunctions of a drive or operating system, incorrect user actions or virus activity.

Our suite allows creation of a complete or partial copy of the data from a malfunctioning drive saving it directly to another HDD or to image files. You can create copies in the background using the tools for logical structure rebuilding included into the package. During the procedure user data will be read from the malfunctioning drive and copied selectively. Such approach helps decrease considerably the volume of data read from the failing drive making respectively lower the load on the device and the time required for data recovery.

1.2 Hardware and software requirements. Proper functioning of the program requires a personal computer (PC) with a Celeron 1.6 GHz CPU or faster, at

least 512 MB RAM, an available PCI slot, CD-ROM for software setup and a video display adapter supporting the resolution of 1024х768, and a 17” display. Operating system: Windows 2000 or Windows XP.

Recommended configuration: Core2Duo 2.6-3.0 GHz CPU, 2048 MB RAM, display resolution 1280x1024, and a 19” display.



2 Product distribution kit. Data Extractor UDMA variant.

1. Installation CD containing the distribution package of Data Extractor UDMA software

1 item

2. User Manual 1 item

3. License Agreement 1 item




3 Getting started. 3.1 First program launch.

Select the PC-3000 UDMA program icon on your desktop or run PC-3000 UDMA from the Start\Programs\PC-3000 program group using the keyboard or mouse to launch the program.

One obligatory condition is the presence of the PC-3000 UDMA tester board with a number matching the number of your License Agreement.

If the suite installation has been successful and your system complies with all the requirements above, the main program window will be displayed:

Figure 1. The main program window

Data Extractor UDMA software functions in tight connection with the core of “PC-3000 for Windows” being integrated into its visual interface.

PC-3000 for Windows is an MDI application. All windows of the program and of Data Extractor UDMA are child forms of the main PC-3000 program window.

In order to start working with Data Extractor UDMA, you should either click the Data Extractor ( ) toolbar button or open the main menu in the Utility selection→Data Extractor window of PC-3000 interface.

As soon as you do that, the program will display a window containing the active form of Data Extractor UDMA Task Manager:



Figure 2. Data Extractor UDMA Task Manager window




4 Description of program functionality. 4.1 General principles of control and data output.

The program is an МDI application.

The main window includes the master form integrated with the main menu of the currently selected child form, a panel of status and error registers, and power indicator of the drive connected to an IDE port of the PC-3000 UDMA tester board.

All mode windows (except for dialog boxes) include: − The main menu, which in child forms integrates itself into the master menu of the main form or appears in

the upper part in modal forms. − A toolbar of quick access buttons below the main menu. All actions triggered by the fast access buttons can

also be invoked from the main menu. − The workspace, where the program displays most of the information about tasks and processes. − In individual cases (e.g., in sector editor mode) windows also include a panel for output of additional

(status) information located in the lower part of the window.

Forms used for modification of settings regulating program activity are actually represented by standard dialog boxes.

All control functions are performed using selection of respective items in the main or right-click menu, by pressing the corresponding quick access buttons or through keyboard shortcuts.

You can navigate through the interface using the TAB, Shift+TAB keys or with the mouse.

4.2 Basic notions and definitions. The list of notions and definitions used throughout this manual:

No Name Comment 1 Task A set of data (settings, results, etc.), generated while working with a specific drive and

stored to a separate directory matching the task name. 2 Image A copy of data recovered from a damaged drive and saved either to a normal drive or to

image files in task subdirectory. 3 Export The process of sector-by-sector copying of data from image files to a normal drive

connected to the PC-3000 UDMA tester board. 4 LBA Logical address of a data block (sector). 5 Scan map Graphical presentation of copy creation results. 6 Explorer Visual mode for presentation of logical structure of data on a connected HDD or its

image. 7 Translator The system correlating the logical disk space (LBA) with the actual physical HDD

geometry including the system for accounting of defective areas.

4.3 Task Manager window. This is the main form of Data Extractor UDMA. You may use its controls (main menu and quick access

buttons) to set up the main program parameters, create a new task or open a previously created one.

The form is also referred to as Task Manager because Data Extractor UDMA is actually a multitasking program which allows simultaneous operation of several data recovery tasks.

E. g., you can run a task for sector-by-sector copying of data from a damaged drive (in that case, preferably from ATA0 to ATA1) performing at the same time purely logical data recovery from a technically operational drive connected to one of standard ports in your computer.

You can manage the form using the main menu or quick access buttons.



4.3.1 Items of the Task main menu.

4.3.1.1 New task.

Selection of the New task (Ctrl+Ins) menu item or clicking the quick access button ( ) corresponding to it initiates the mode for creation of a new data recovery task described in detail further.

4.3.1.2 Open task.

Selection of the Open task (Ctrl+Enter) menu item or clicking the quick access button ( ) corresponding to it opens the dialog box, where you can select the directory of a previously created task (please see the figure below).

Figure 3. Dialog window for selection of a previously created task

As soon as you select the directory containing files with task settings and results, the program will open the main form of the specified task and its record will appear in the list of previously created tasks (if it was not there for some reasons).

4.3.1.3 List of recent tasks.

Contents of the list are based on the information about created and opened data recovery tasks.

The list becomes available upon selection of the Task item in the main menu; it serves for quick opening of the tasks created earlier. List elements are sorted according to the time, when task data were accessed. The most recent tasks will be at the top of the list.

Figure 4. List of recent tasks

List items will be removed from the list upon deletion of a directory corresponding to a specific task.

4.3.2 Items of the Options main menu.

4.3.2.1 Working folder.

Working folder setup allows selection of the main folder on any standard partition of your drive to be used by default for subsequent creation of task subdirectories.




The dialog window for working folder selection is shown in the figure below:

Figure 5. The dialog of working folder selection for a task

4.3.2.2 "Read only" devices.

This menu item is intended to prevent recording of sector-by-sector copy from the drive being tested to your main system hard drive. To ensure that, you will have to check in the list (please see the figure below) those drives, which may not be used for creation of sector-by-sector data copies.

For copying of image files, results, etc. the program can use any standard connected devices without limitations.

Figure 6. Selection of “Read only” devices

4.3.3 Quick access toolbar. The appearance of Task Manager toolbar is shown in the figure below.

Figure 7. Quick access toolbar of the Task Manager form

The buttons perform functions identical to the commands of the main form menu.



4.4 Creation of a data recovery task. Data recovery process may be obstructed with problems of all sorts. They may include various physical device

malfunctions and purely logical data integrity issues. A combination of both cases is also possible, etc.

The previous version, our Data Extractor ISA software used task subdivision into groups according to the specifics of each individual case. Three task groups were identified.

The first group represents cases, when a drive is damaged, but reports on readiness and has no data shifts (the translator is functional). It includes multiple BAD sectors, possible malfunctions of magnetic head assembly or data read channel. Hard drives with a replaced MHA or disks also fall into that group. In general, it covers all situations when users experience problems while reading data.

The second group consists of cases when the system that coordinates logical block addresses (LBA) with actual physical HDD geometry (including the system of defective areas accounting) becomes damaged for whatever reason. Here belong cases of direct translator corruption (Quantum drives) as well as situations, when data are read from a drive made ready during a “HOT SWAP” procedure so that a drive uses for its operation a translator from another functional device. In other words, those are cases when shifts in data placement are encountered (please note that in the first case only data shifts forward are possible while in the second case shifts backwards may also occur).

The third group includes all cases of damaged logical data structures. They may result from erroneous user actions, software or power supply failures or from interference of various virus programs. We mean here just regular data storage, not RAID arrays.

However, real data recovery practice has demonstrated that the described approach may be not quite applicable in cases, when a single device combines problems belonging to different groups.

Thus, there are cases when a drive has a corrupted translator and also a lot of sectors that cause errors at an attempt to read them.

Therefore in Data Extractor UDMA, similarly to Data Extractor PCI software released earlier we used another approach, namely generation of a list of required features for a task.

E.g.: a drive has BAD sectors and translator problems. It means that we need to create data copy taking into account translator shifts.

Following from the above, the task creation process is implemented as a task creation wizard that guides users and assists them.

The selection of wizard pages is not invariable; it depends on your actions.

4.4.1 Folder selection for task data storage. The figure below demonstrates page appearance.

Figure 8. Task folder selection window

The default name for each new task is “NewTask”; the software creates it as a subdirectory in the working folder specified in program settings.

If you wish to change task location you can either modify the full path in the editing line or click the Browse button and specify the required folder.




Figure 9. Task folder selection dialog box

The dialog box allows you to select or rename an existing folder or create a new one.

4.4.2 Source device selection. The window is used to specify the device that will be the main one for the current task. Dialog appearance is

shown in the figure below.

Figure 10. Source device selection dialog

Device list includes all data storage devices connected to standard ports and identified by the operating system (Floppy, IDE, SATA, SCSI) except for CD-ROM. Besides, the list contains a few special devices: PC3000 ATA0 and ATA1, External file and File Image.

A few words about those devices.

PC3000 ATA0 and ATA1 represent the main independent and equivalent IDE ports of the PC-3000 UDMA board. We recommend connecting all IDE drives with physical malfunctions exactly to those ports because the software allows maximum control over the situation, when the said ports are used for operation. We mean here operation using the PC-3000 UDMA board driver, which, unlike standard device drivers, is designed to work with malfunctioning drives so that HDD failures do not result in operating system crashes. When PC-3000 ATA0 or ATA1 port is used, there is an opportunity to disable and enable power supply for a drive when necessary or to force a hardware reset.

If one of the main PC3000 IDE ports (ATA0 or ATA1) is selected for operation and during task creation a drive connected to that port fails to reach readiness or starts knocking, you can interrupt that process.

Figure 11. Drive readiness waiting dialog during task creation

File Image is a virtual device employed to export a sector-by-sector data copy previously created in another task to a new functional drive or to continue working with that task. The task must be created in Data Extractor UDMA. We shall discuss the peculiarities of copy creation and use in the format of image files further.



External file is another virtual device used to open in Data Extractor UDMA a data copy created as a single image file earlier in DE or third-party software tools. The operator can use than DE features for logical data recovery and translator restoration and mount that image (i.e. connect the current task to the list of standard Windows disk drive devices).

4.4.3 Task initialization. The window appears only if you select one of the PC-3000 UDMA board ports (ATA0 or ATA1) is used as the

main source device.

The figure below demonstrates window appearance:

Figure 12. Task initialization

Selection of initialization options is determined by model peculiarities or specific physical malfunctions of a drive. Thus, if you enter a task after the selected drive has been made “ready” using the HOT-SWAP method (replacement of the PCB with power on), or using a LOADER in the PC3000 utility, or after it has been switched to factory mode in a specialized utility, then in no event should you perform hardware or software reset.

If HDD ID cannot be read, if it returns incorrect information or becomes inaccessible during work, then selection of the option to read HDD ID is not recommended.

The Initialization option may be necessary sometimes with older drives (e. g., WD), which would not read data without it. It is not recommended for new drives.

The Readiness waiting period field is necessary because some drives (models) generally take a lot of time to report on readiness while with others long delay before readiness report may be caused by a malfunction. The initialization scenario allows users to manage the situation with maximum flexibility in each individual case.

4.4.4 Additional settings. The page containing additional task settings is shown in the figure below:

Figure 13. Additional settings

During task creation you can specify additional actions that you are planning to perform within the task depending upon the situation.




4.4.4.1 Make data copy.

The option should be selected in cases, when a damaged drive has reading problems irrespectively of their cause.

During copy creation the program generates a map of reading results, which allows users to evaluate the status of the whole damaged drive or data area being scanned. The map is actively employed in all modes that perform data recovery from a drive being tested.

E. g., if a sector has been copied successfully (no matter whether the attempt to read it has number 1 or n) then an attempt to read it again will not cause access to the damaged drive; the data will be read from the copy. Thus, apart from saving copied data, the option minimizes the number of attempts to access a malfunctioning drive.

That feature is especially useful with drives almost ready to cease functioning being an advantage over programs performing purely logical restoration; deep analysis performed by the latter rebuilds a virtual file system but by the end of that process a drive may go completely out of order so that reading of necessary data may become impossible.

When the option for data copy making is enabled, further editing always means work with the data copy. This is essential because it is usually not recommended to record anything to a drive with physically damaged parts. One more distinctive feature of that mode is manifested in the fact that the program copies not only successfully retrieved data, but also data read with various errors. The software performs statistical processing of reading results adding to a copy the most reliable data (provided that the number of attempts to read data exceeds 2).

In particular, when data reading is unstable and causes checksum (UNC) errors, the data may still contain a lot of useful information. It may be especially helpful while scanning service areas (BR, FAT, etc.). E. g., a portion of information in a sector read with errors may still be normal, then the software could use it during subsequent logical structure restoration.

4.4.4.2 Create virtual translator.

The option should be enabled when a damaged drive has translation problems or a part of its data for some reason is shifted relatively to the necessary position (e. g., because of an unfinished disk manager operation).

4.4.4.3 Use active PC-3000 utility.

PC-3000 suite includes a number of specialized programs designed for work with hard drives of individual manufacturers and drive families. These programs offer a number of features, which can be used together with Data Extractor, for example, to build a map of HDD heads or recover data. Such features include data reading, ability to send to HDD a command disabling Autorelocation and generation of a heads map. The first two features can only be used in case, when a corresponding utility is running (and provided that it supports the requested mode). When a map of drive heads needs to be built, the user will have to launch the appropriate utility manually.

4.4.5 Destination device selection. If you have enabled the Make data copy option on the previous page, then on the next page you will be offered

to select the target device to be used for copying (please see the figure below).

Figure 14. Selection of a destination device for copying

You may select any device from the list for that purpose.



The list includes all standard data storage devices except for Floppy, CD-ROM and those marked as "read only".

Besides, the list also contains two special devices: PC3000 ATA1 (or ATA0) and File Image.

PC3000 ATA1 (or ATA0) is a currently unused IDE port of the PC-3000 UDMA board. If you are making a full copy of a drive connected to PC3000 ATA0, or its partition (and port ATA1 is not used at the moment in another task), then port ATA1 will appear in the list and we recommend connection of the target drive to that port. That method minimizes CPU load on your computer (because most operations over data are performed by the PC-3000 UDMA board) reaching in most cases the maximum final copying speed possible.

Furthermore, the safety of copy creation is ensured because OS does not see the copy being created and cannot interfere with the process of its creation. Consequently, if a task for copy creation is generated for port ATA1, then the device list will contain port ATA0 (respectively if it is not used at the moment in another task). Completely normal status of the destination device is a prerequisite for the operation. Besides, it should be equal to or exceed the source device capacity.

If the destination drive for the copy fails to report on readiness for some reason (or starts knocking) during task creation, you can interrupt the process using the appropriate dialog:

Figure 15. Drive readiness expectation dialog during task creation

File Image should be selected, when data is copied to image files. The data thus copied is added to the task directory as binary files in imgXXX.bin format (where XXX stands for the initial sector number). File size can be selected from a drop-down list. Disk space available on the partition containing the task directory must be equal to or exceed the expected source data volume.

Creation of a copy as image files is used when you have to copy from a drive in question a relatively small portion of data and the condition of its logical structure allows that. It can also be handy when you need to modify the logical structure metadata to gain access to the data without recording anything to the drive being tested (recording to a drive under test is generally not recommended and sometimes it is altogether prohibited because such an operation might render the HDD totally inoperative).

In cases, when you need to copy a lot of data or a whole drive (partition) we recommend selection of a real physical device from the list.

Modify MBR. If a full drive copy is being created on a HDD connected to standard ports, there is certain risk that the OS installed on your computer may detect a new correct MBR sector and attempt to mount the corresponding partitions or, worse, to modify its data. To prevent that, you can slightly modify the MBR sector so that the OS does not recognize the zero drive sector as MBR (in this case, MBR sector signature represented by word AA55h is changed to BB55h), and then, after a full copy is created, restore the signature in the zero sector manually.

4.4.6 Task comments. The page allows users to save any comments (on drive, situation, client, etc.) in task parameters.

Figure 16. Task comments




4.5 Opening an existing task. There are two methods, which can be used in order to open a task created earlier:

1) Task selection from the list of existing tasks, which appears upon clicking the Task item in the main menu of the Task Manager window (please see the figure below).

Figure 17. List of tasks created earlier

2) Use the fast access button ( ) to the left of the Open task button to choose a task from the list of tasks opened earlier.

Figure 18. List of tasks created earlier

3) Click the Open task button and select explicitly the task folder.

If the selected task uses a drive connected to the main IDE port of the PC-3000 UDMA board then the program will display at task start a dialog window where you can modify its initialization parameters (please see the figure below). That is necessary because the situation may change during work with a damaged drive (e. g., a drive may stop reading its ID information), and the changes will demand respective script modifications.

Figure 19. Dialog window for modification of task initialization parameters

4.6 Primary window of the data recovery task. The appearance of the primary task window depends upon the settings entered during task creation; it may

vary considerably. The elements of the window can be subdivided into the following groups: − main menu − quick access toolbar − information panel − a panel with tabs for program log, map of copying results and sector view − explorer panel. Availability of panels, their components and displayed information depend upon task settings and a specific

mode.



4.6.1 Main menu of the primary task window. The selection of main menu elements is constant, but their availability may depend on the type of task and the

currently running process.

4.6.1.1 The "Options" menu.

The list of items in that menu is invariable; just the availability of the Task options item may change. In some cases the item is inactive.

4.6.1.2 Task options.

Selection of this menu item (if it is accessible) brings up a window, where you can edit alterable task parameters. Some parameters are specified at task creation and cannot be changed while it is being performed.

Window appearance may vary considerably depending upon task settings selected during its creation.

4.6.1.3 Task options for cases, when the source drive is connected to a port of the PC-3000 UDMA board.

Task settings window is most packed with options in that case. That is determined by considerably greater opportunities for drive control compared to devices connected to standard ports.

4.6.1.4 The "Copying" tab.

The tab is intended for specification of parameters to be used while copying a range of sectors on a tested drive. It appears only if the Make data copy option has been enabled during task creation. The settings pertain to sector-by-sector data range copying with simultaneous map creation; the mode is described in detail further.

Note. During work in some additional modes (e.g., Explorer, GREP search, etc.) copy creation is performed in the background. Copy creation parameters supported in those modes do not include just the options to jump skipping sectors and use several read attempts.

Tab appearance is shown in the figure below:

Figure 20. Copy creation parameters

You can edit the values within the tab to specify the range of sectors for copying (Initial LBA and Final LBA), direction of reading while copying, block size (in sectors) during the reading procedure, and to determine program behaviour for processing of map data for the copy (Skip sectors at loss of readiness, Skip sectors on reading errors, and Work with copy only).

The Direction parameter may be important in two cases:

1) The first case occurs when a disk has a scratch that causes MHA malfunction at the very first contact. E. g., if the scratch is in the beginning of a disk (precise location unknown), the largest data portion is in the end. In such case there is sense in reading the range beginning from the end backwards.

2) The second case includes some drive types which read data better without caching when physically damaged. As a matter of fact, reading backwards makes a drive reset its cache; in certain situations that method allows recovery of a greater data part.




The Block size for reading parameter should be modified in some individual cases only, when the number of sectors producing errors is very large and they occur very frequently. Decreasing that value sometimes improves the overall copying speed (the result follows from the reading algorithm employed in the program rather than the drive).

The Skip sectors at loss of readiness parameter is used to prevent the program from excessive unnecessary reading of sectors, which in the best case make the drive stop responding to commands or, at the worst result in drive knocking with its heads against the stop, damaging its mechanics.

The Skip sectors on reading errors parameter allows users to finish reading of data from sectors skipped earlier without losing time trying again to read sectors, which have been copied with errors. That feature is valuable for time saving purposes decreasing also the load on a malfunctioning drive.

The Clear not reading sectors parameter makes the program add unreadable sectors to the copy as sectors filled with zeroes. The option makes sense if you are creating a sector-by-sector copy on another drive (in that case there is no risk that unread sectors in the resulting copy can contain garbage).

The Single sector access parameter is used when you need to restrict the number of attempts to read a sector to one. The option can be used, for example, during initial evaluation of drive condition when there is no need to spend a lot of time for complete recovery of all data using repeated attempts (by default, three reading attempts are used).

Note! When used, the parameter is not equivalent to setting the Reading retries option on the Error handling tab to 1. Thus, if Single sector access is enabled, and a sector has been read with an error or could not be read because of an error, there will be no other attempts to access the sector. However, if you set on the Error handling tab Reading retries to 1, new access to unread sector is possible unless the options to Skip sectors at loss of readiness and Skip sectors on reading errors are enabled. The Single sector access parameter has priority over the Reading retries parameter.

The Work with copy parameter allows disabling of all attempts to access data on a malfunctioning drive. Then the software will only work with the data already available in copy.

The option to Modify MBR has been discussed earlier.

4.6.1.5 The "Command to read" tab.

This tab is intended to select the command to be used by default for reading data from a HDD.

In many cases selection of an alternative command may prove helpful, because each command may turn out to be optimal for data recovery from different drives under various conditions.

Figure 21. Applicable reading command selection

The commands to Read, use UDMA66 and Read, use UDMA33 are intended for data retrieval in corresponding UDMA modes (the modes are considerably faster than PIO modes described further). Availability of those commands is determined by the HDD ID read earlier, i.e. if it has been read and a certain reading mode is marked as unsupported in it, then the corresponding command will become unavailable. If HDD ID cannot be read for some reason, both commands are available and the user has to decide if he is ready to deal with the consequences of their use.

Both the Use hardware retries and Do not use hardware retries commands may produce optimal results under different conditions so their choice is determined by a specific drive model. They either enable or disable data reading (returning an error).



The Read, ignore CRC command forces data reading without integrity control. The approach is not really good, but it sometimes allows considerable time economy while finalizing reading of data from defective sectors during recurring passes.

The Read from active PC-3000 Utility option allows reading via specialized utilities included into the suite in cases, when they are active and support the required mode. At present the said mode is supported in the utility for WD drives. Please refer to the documentation for the specialized utilities for details.

4.6.1.6 The "HDD power supply" tab.

In individual cases described further the software automatically turns power supply off/on while working with a HDD.

The Task parameters saving with power-off if the utility remains idle for… parameter switches off power supply of the corresponding drive and closes the current task after the specified interval (minutes).

Figure 22. The "HDD power supply" tab

4.6.1.7 The "Error handling" tab.

This is one of the most important tabs. Some of its parameters are taken into account during all operations for data reading from a damaged drive.

Figure 23. The "Error handling" tab

The Reading retries parameter determines the number of attempts to read a sector copied with errors of any type. Please keep in mind that whenever the parameter is greater than 3 the program performs additional statistical analysis and preserves the most reliable data. There is also a probability that one of multiple reading attempts will be successful. Currently the software uses the parameter during data copy creation and in the sector-by-sector range copying mode only (provided that the Single sector access option on the Copying tab is disabled). The parameter is ignored during “background” copy creation, the program makes just 1 reading attempt.




The Jump size parameter applies to the sector-by-sector range copying process regulating program behaviour if a sector reading error (but not a loss of readiness) occurs. If the specified size is greater than 1, the program skips while reading the number of sectors defined by the parameter, jumping forward (or back in case of reading backwards) and returns copying data up to the first sector causing errors making thus precise the borders of the area containing defective sectors. The sectors between the two extreme ones are skipped and marked as such. The use of jumps allows time economy and lower load on a drive with large corrupted areas.

The Script of actions at read errors (except for UNC) scenario is usually empty. It is used only in those rare cases, when a drive being tested stops after an error normal operation and begins reporting endless errors for all sectors in sequence (do not confuse the case with the static translator problem!).

In such cases you can set up the scenario and make the drive functional again automatically. The scenario is identical to the list of actions in case of readiness loss (described in detail further). The sequence is used in all task modes whenever an error occurs during sector reading.

4.6.1.8 The "Loss of readiness" tab.

Parameters of this tab (please see the figure below) are used by all task modes during data reading from a damaged drive being thus of essential importance in cases, when a drive stops responding to commands (does not react). They are especially significant, when a drive produces knocking sounds.

Figure 24. The "Loss of readiness" tab

The Jump size parameter defines the number of sectors that the pointer will skip forward as soon as the program moves further if the HDD does not respond within a specified time-out. The mode is used for jumping over the most damaged disk areas (e. g., when one of HDD heads is damaged). The parameter is employed only in case of successive copying of a sector range. The pointer will be shifted by the defined number of sectors. If the new sector is read without errors the program will attempt to pinpoint the damaged area from the other end, reading the disk in the reverse direction until it encounters the first sector causing readiness loss. Sectors between those two errors will be skipped.

The Timeouts panel contains a number of parameters that define the interval during which the program will wait after readiness is lost in various reading modes (PIO and UDMA) and after execution of scripts (software reset, hardware reset and power off/on). Readiness waiting parameters are specified in milliseconds.

The Script of actions at loss of readiness panel determines the order and the set of program actions to be performed by the program in case, when a drive does not report ready within a specified period. The panel allows the following operations:

1) Software reset. 2) Hardware reset. 3) Turn off/on drive’s power. 4) Initialization. 5) Recalibration. 6) Disable read look-ahead. 7) Disable "AutoRelocation" while reading (HDD RAM).



The sequence of actions is invariable, it is determined by the order of options (from the top down); users can modify the selection of actions to be performed depending upon a specific situation.

E. g., if a drive starts knocking during loss of readiness, enabling the Turn off/on drive’s power option is mandatory.

The presence of that item is essential in situations, when data scan on a large drive is performed and the user does not monitor the operation progress constantly. In certain cases a drive may lose readiness, start knocking and go on damaging its own mechanics. If you do not stop that, further data recovery may become impossible.

Note! The Turn off/on drive's power option will be applied (if selected) upon readiness loss by a drive only in case, when both the Software reset and Hardware reset options are either not selected or have both failed.

However, you can modify the scenario at your own discretion as the situation may require. The script will be performed in cycle for the number of times specified in the Attempts field.

The Disable read look-ahead option allows switching a drive to the mode when read-ahead access is not used. It can be important in cases of selective data recovery from a malfunctioning drive. If a drive head is damaged, you can build the map of heads and disable reading for the damaged head, then read-ahead functionality of the drive should be disabled as well to avoid using the head accidentally while reading.

The Disable "AutoRelocation" while reading (HDD RAM) option allows switching a drive to the mode with disabled hardware reallocation of defective sectors.

Since two latter parameters are preserved in drive RAM, then if HDD power supply is switched off/on (in cases of drive readiness loss and performance of a corresponding scenario), the appropriate modes will be enabled automatically again.

4.6.1.9 The "Heads map" tab.

The tab appears in situations, when a copy is being created. Generally it also controls the corresponding mode. Its parameters have the following purpose: for many (though by no means all) drive models the command for LBA→CHS conversion is known. Its use allows building a map of drive heads and its application for further operations (through identification of the number and purpose of heads as well as LBA↔Head relation).

The procedure may be essential in cases, when a single head (or several) is out of order but you need to read the data from sectors under the remaining functional heads before MHA replacement (if that is altogether possible). In such cases you will have to build a map of heads, uncheck malfunctioning heads, disable read caching and only then proceed to actual data reading.

Tab appearance is shown in the figure below.

Figure 25. The "Heads map" tab.

A map has to be generated before it can be used. You can create a map for a whole drive or for a range thereof to be copied.

Upon clicking the Create map button you will see an offer to select the type of the drive for which the procedure will be performed.




Figure 26. Drive type selection.

At present the list of drives that allow map creation can be extended by running a loaded active PC-3000 utility for the corresponding HDD model (consequently, you will have to select the РС-3000 Utility menu item). E.g., you can use the features of specialized utilities to build head maps for new MAXTOR and WD drives.

For some old drive models you can build the map creating the corresponding drive family in the HDD type list. Thus the software supports map creation for all FUJITSU drives, practically all IBM drives, old MAXTOR drives, old WD drives, all Quantum drives (including models manufactured by MAXTOR). If the feature is not supported for the current drive or the drive is damaged and does not execute required commands then the program will display an error message during map creation.

When the drive type is selected, you should specify the boundaries of the sector range for which the map will be created.

Figure 27. Specification of the sector range.

We recommend spending some time and creating a map for a whole drive.

Figure 28. Creation of a heads map.

When the map is ready, you can define whether its data should be employed further. If the map will be used, you can also specify, which drive heads will be used for reading.

Figure 29. Selection of heads for reading.



4.6.1.10 Reference.

Users can employ the Reference mode to save and reuse settings required most frequently (you can invoke the mode using the button in the lower left corner of the Parameters window).

The reference window for typical configurations is shown below. Initially the reference is empty. If necessary, the user can create required configurations personally. Thus, you can create configuration for preliminary (initial) reading pass to estimate the situation in general and disable reading retries and jumps for time economy in it as well as additional passes for recovery of the data, which could not be retrieved during the first stage.

Figure 30. Typical configurations reference window.

In order to create a new configuration, you will have to specify the required settings in the Parameters window first and then invoke the Reference mode to create a corresponding record and save the new configuration by pressing the Refresh button.

You can load the required configuration from the list of available records by clicking the Select button (Ctrl+Enter).

Figure 31. The window for creation/editing of records in typical configurations' reference.

4.6.1.11 Settings for data recovery from a device connected to standard port.

The settings in that case are considerably simpler. You can only specify the initial and final LBA of the area to be copied and the number of reading attempts and jump size in case if an error occurs. Furthermore, options to Clear not reading sectors, use Single sector access and Work with copy only are also available. Detailed descriptions of those settings can be found in the sections above.




Figure 32. Settings for copying from a device connected to standard port (the Copying tab).

Figure 33. Settings for copying from a device connected to standard port (the Error handling tab).

4.6.1.12 Settings for data export from image files.

When you are exporting data from image files, only sector range has to be specified. Additionally, you can enable the option to write zeroes instead of the sectors that the program has failed to read:

Figure 34. Settings for data export from image files.



4.6.1.13 Task info.

Window appearance is shown in the figure below:

Figure 35. Viewing and editing task information.

The mode is intended for quick review of information about a task (source device, destination device) and comments to it. You can change and save comment text.

4.6.1.14 GREP expressions.

The reference includes a list of regular expressions used by the search engine of the program.

The software package includes a basic list of GREP expressions (over 160 records). You can supplement it with your own custom records whenever necessary.

4.6.1.15 Regular expression concept.

A regular expression is a method used to represent templates for text search and verify text compliance with the specified template. For instance, special meta characters help tell the program to look for a substring in the beginning of an input string or a certain number of substring iterations.

The functional model implemented in Data Extractor UDMA software is rather simplified. However, its features are quite sufficient for successful practical application.

A regular expression can be created manually, in binary editor or using the Add Grep plug-in (please refer to section View and edit sector).

4.6.1.16 Regular expression syntax.

Regular expressions consist of characters and operators. The operators are listed in the table below.

? Any character . Any character * Any number of any characters "xxx" A string of characters \000 A character (when it begins with 0 – in octal notation) \999 A character (when it begins with 1..9 – in decimal notation) \xHH A character with HH hex code \n Line feed \r Carriage return \t Tabulation \f Form feed return [xxxx] Any character from the specified group (which can be specified as an "A-Z" range). [-xxxx] Any character different from the specified group %x Special sets of characters:




W – any number of spaces w – a single space N – any number of "0123456789" characters n – a single "0123456789" character A – any number of characters from the "a-z" or "A-Z" range a – a single character from the "a-z" or "A-Z" range X – any number of characters from the "0-9" or "a-z" or "A-Z" range x – a single character from the "0-9" or "a-z" or "A-Z" range

^ From the string beginning @nnn Starting with nnn position from the beginning @-nnn Starting with nnn position from the end (xxx) Subexpression (min:max) Number of iterations for the following operator | Logical “OR” for two subexpressions

Any character matches itself if it does not belong to special wildcards. A sequence of characters matches the same sequence in an input string, so that "bluh" template will match the "bluh'' substring in an input string.

If you need the program to view meta characters or Escape sequences as plain characters, they should be preceded by the "\" character, e.g., the "^" meta character usually matches line beginning but when represented as "\^" it will match the "^" character, "\\" matches "\", etc..

Examples:

Expression Returns Foobar 'foobar' \^FooBarPtr '^FooBarPtr' ^GIF8[79]a GIF87a or GIF89a in the beginning of a line @510\x55\xAA Bytes $55 $AA at position @510 (@3"MS") * (@510\x55\xAA) Combination of “MS” string in the position 3 and bytes $55 $AA in the position

510 ^\xF8{12}(\xFF) A $F8 byte in the string beginning with 12 following $FF foo\x20bar 'foo bar' (please note the middle space) foob[aeiou]r 'foobar', 'foober', etc. but not 'foobbr', 'foobcr', etc.

4.6.1.17 Using the reference.

The appearance of reference on GREP expressions is shown in the Figure 30.

Figure 36. GREP reference

You can work with the reference either using the right-click menu in the list or by clicking buttons on the quick access toolbar in the upper part of the window, or by entering shortcut key combinations displayed in right-click menu (recommended).



You can sort the data in the ascending and in the descending order in each of the columns and quickly highlight the record beginning with a specified character (to do so, you should just enter the character from the keyboard, the command is case sensitive).

The Select command will become available, when the reference is used for selection of data search criteria.

Selection of the Add or Edit menu options brings up a window for editing the record properties (please see the figure below).

Figure 37. Editor window for properties of a regular expression record

While adding new records it is advisable to assign carefully their categories and names, although the search routine uses the GREP field contents only. Please keep in mind that creation and use of complicated expressions may slow down the search procedure considerably. The program searches faster for simple expressions beginning with position indicator ('^' or '@').

4.6.1.18 Raw recovery reference book.

The reference book is used during the raw recovery procedure, which will be described further.

The appearance of the raw recovery reference is shown in the figure below.

Figure 38. Raw recovery reference

Work with the reference is very similar to operations with GREP reference described above.

The only significant difference is in the selection of fields conveniently displayed in the editing dialog window:

Figure 39. Editing a record from the raw recovery reference book




While searching based on the raw recovery reference, the program only uses the regular expressions selected in the Seek column. To extend the list of the expressions used during search, you will have to select the corresponding expression from the reference or create such expression and enable the Seek checkbox.

When raw recovery is selected, the program offers to choose the method for calculation of the found data size. There are two possible variants. The first method uses for size calculation just the regular expressions enabled in the Seek column of the reference. The second method uses all regular expressions from the reference (but only during data size calculation). Specific size calculation method depends upon the data being sought. Thus, for ZIP archives the first method is preferable (if found archive size turns out to be greater than its actual size, some programs for data recovery from damaged archives (e.g., ZipFix) will allow data extraction from it. If a found archive is smaller than its real size, the chances of even partial data extraction from it will be very low.

In addition, the following fields will also be important for searching and processing of results: Ext (extension), GREP (main criterion), GREPEXT (refining criterion) and Ord (analysis order).

The GREPEXT field is used for more precise identification of discovered file headers in cases when several file types have identical headers but differences can be found further, in file bodies.

The Ord field is of special importance; its presence is determined by the possibility of cases, when one of GREPs being analyzed is a simplified subset of another regular expression. To receive valid results, you will have to search for the most complex expression and only then search for a simpler one.

Editing the reference is possible, it is a rather complex and serious task. However, when a data recovery task is created, the program makes a copy of the raw recovery reference, which it uses then in the current task. Consequently, reference can be restored, when necessary. On the other hand, if you wish to preserve the entered changes, then you should edit the main DE reference instead of the current task reference.

Figure 40. Raw recovery reference and its copy in the current task

DE uses the main raw recovery reference book to initiate raw recovery from the main menu. Current task reference is used if raw recovery has been started from the quick access toolbar or any available Explorer method.

4.6.1.19 The "Service" menu.

4.6.1.20 HDD control.

This item is added into the menu for experienced users; it allows performance of certain actions over HDD connected to ATA0 and ATA1 ports of the PC-3000 UDMA tester board.

4.6.1.21 Standby command.

In individual cases, in particular, when you need to perform some actions on a connected drive, such as HOT SWAP procedure (replacement of electronic board without a prior drive power-off) you can send a standby command to a drive (the HDD will stop spindle rotation until it receives a new command).

In this case, the main raw recovery reference will be used.

When you initiate raw recovery from Explorer, the current task reference will be used (a copy of the main reference made during task creation).



4.6.1.22 "Recalibration" command.

This command can be used to make a drive resume its operation after a previous Standby command.

4.6.1.23 Software reset.

This command sends to a drive a reset command.

4.6.1.24 Hardware reset.

The procedure is initiated by the PC-3000 UDMA board using the RESET line of the IDE interface.

4.6.1.25 Complex initialization.

Selection of this item initiates consecutive performance of the following actions: − hardware reset − software reset − initialization − recalibration.

4.6.1.26 Disable read look-ahead.

This item sends to drive a command to disable read-ahead functionality.

4.6.1.27 Disable "AutoRelocation" while reading (HDD RAM).

This item sends to drive a command to disable automatic hardware reallocation of defective sectors.

4.6.1.28 Turn off/on drive’s power (F12).

This command switches off/on power supply for the drive used in the current task.

4.6.1.29 Calculators.

Having selected this menu item, you gain access to a collection of specialized calculators, which may be helpful while working with data. The need for such modes is determined by one of the main requirements to any data recovery tool, i.e. time economy.

4.6.1.30 FAT – Root sector.

The calculator allows fast calculation and detection of root directory location as soon as you discover a signature of any FAT indicating its beginning. It may be important in cases, when partition beginning is not known exactly on a large disk.

In that case you should search the supposed area (but not the whole disk!) for any FAT directory (searching for two directories is advisable to determine cluster size). Using the respective window for sector data review (as a FAT directory) with this calculator built-in or by invoking the latter from the main menu, you can quickly identify approximate clustering beginning.

Then you can search within that (approximately identified) area for EPR, Boot, and FAT copies using their information to advance further.

There is one important remark: for FAT 16 the calculations may be approximate with accuracy up to 1 cluster.




The calculator appearance is shown in the figure below:

Figure 41. Calculator for identification of Root position in FAT partitions

4.6.1.31 FAT – partition size.

The calculator (shown in the figure below) allows estimation of partition size, when you find the beginning and the end of any (one or both) FAT copy by its signature.

Figure 42. Calculator for estimation of FAT partition size

The calculation helps determine the expected position of the next partition in cases, when other sources of information (MBR, EPR, Boot) are not yet found or are unavailable.

The tool saves a lot of time while restoring large partitions and (or) in case of areas seriously damaged physically.

One good example is the picture of consequences caused by Win95.cih virus infection. In such case the location of the second partition (if the size of the first one is unknown) can be discovered by finding the remaining Root and the start of the second FAT copy of the first damaged partition and using then the calculator.

Please keep in mind, however, that the program calculates the size of data area (excluding the size of FAT copies and reserved sectors).

4.6.1.32 Explorer.

The Explorer mode is described in detail in the Basic modes section.

4.6.1.33 GREP search.

The GREP search mode is described in detail in the Auxiliary modes section.

4.6.1.34 Verification.

The Verification mode is described in detail in the Auxiliary modes section.

4.6.1.35 Raw recovery.

The Raw recovery mode is described in detail in the Auxiliary modes section.

4.6.1.36 Copy region.

The Copy region mode is described in detail in the Auxiliary modes section.



4.6.2 Quick access toolbar. The toolbar is located in the upper part of the window. The buttons on that panel and their availability may

vary considerably depending upon the current mode and task settings.

Thus, Power and Verification buttons are active only when you are working with a drive connected to the ATA0 or ATA1 port of the PC-3000 UDMA board.

Button actions are identical to those items of the current task window menu, which are needed most frequently. You can identify button purpose by its icon and tool tip.

4.6.3 Informational panel. Panel appearance is shown in the figure below:

Figure 43. Informational panel of a task

The Source device panel displays information about the current connected source device (model, serial number, firmware version, drive capacity and the total number of accessible sectors (LBA)).

The Mode panel informs about the current operational mode.

The Operation panel displays additional information during task execution (e.g., the current operation, its status, maybe the current LBA, etc.).

The panel is present in practically all the modes, except for the Explorer mode, where its presence would decrease considerably the workspace being thus unwanted.

4.6.4 Log panel. The panel is called so just conventionally. In fact, it is a notepad with a selection of tabs, which depends on the

current task and mode and may change.

The panel is present in practically all the modes though with different tabs and settings.

4.6.4.1 The "Log" tab.

The Log tab is always visible. The log is common for all program modes.

Apart from the log proper containing output messages, the tab includes a slider progress indicator for the current process (lower tab part) and controls for data output to the log (slider regulating the level of details for debugging data output and a control toolbar).

The tab appearance is shown in the figure below:

Figure 44. The "Log" tab

The detail control slider for output of debugging information allows regulation of the intensity of the text data stream output to the log. If the slider is in the topmost position, the program outputs complete information about the process (including even the sector being read). If it is in the lowest position, the program reports only significant errors. The higher the slider is the greater is the stream of output information.

Log size is determined by PC-3000 UDMA software settings. When its specified size is exceeded, a part of the log gets deleted automatically.

The Clear log button clears the current log completely.




The Save log to file button allows users to save the current log to a file.

The Pause trigger button stops automatic log scrolling to the end without interruption of actual data output to the log. That allows convenient log reviewing during intensive data output to it. The key may be either depressed or released.

The Save log to file automatically trigger button allows users to switch on data saving to a file simultaneously with information output into log. Thus the file will contain a full task log without parts lost during log clearing procedure.

4.6.4.2 The "Map" tab.

The tab contains a sector-by-sector map reflecting the results of data copy creation. The tab is displayed only in case, when you are making a sector-by-sector copy or exporting data. Tab appearance is shown in the figure below:

Figure 45. The "Map" tab

The list of actions available in each specific case will be different (e. g., if you are exporting data, then in sector editing mode there will be no opportunity to read its data from a damaged drive, etc.).

The main purpose of the mode is in reliable estimation of qualitative results received while scanning so that users can decide how the scanning parameters should be modified.

E. g., after the first scanning pass you may choose to run scanning again for an area, which was read with numerous errors – this time with stricter or just different parameters (the number of reading attempts, use of hardware retries, etc.).

In addition to the main feature (quality estimate), you can perform some other useful procedures available via the right-click menu of the map (invoked by right-clicking with the mouse over the map).

Here is a short list of those opportunities:

− An opportunity to review and edit the data of a selected sector (using right-click menu or double-clicking). − An opportunity to generate a report on the results of copying a specific data range. All actions pertaining to editing, copying, and export are performed over a data image (image files or data on

another device selected as destination).

4.6.4.3 Map navigation.

You can navigate the scanning map using your mouse and keyboard.

To browse the map from keyboard, use the mouse or "TAB" key to move to the vertical slider. Then use the "Up" and "Down" arrow keys, "Page Up", "Page Down", "Home" and "End" to move around the map.

You cannot move the focus to the map itself, but left-clicking it will bring the focus to its slider – that is another method, which allows further use of the keyboard.

Reviewing the map with the mouse is even simpler – all you have to do is to click or pull the slider.

If you click a selected sector (square box) on the map once and hover with the mouse pointer over it, you will see a hint with its number and head number, if the heads map has already been built for that sector.

To move to a specific sector using the map, you can enter its number in the LBA map field and click the Go to button.

4.6.4.4 Legend.

Click the Legend button to see the current legend (colours used to display various items on the map), that will bring up a window containing necessary information:



Figure 46. Reviewing the legend

4.6.4.5 The "HEX" tab.

The tab is used to display the initial sector of any selected object. It appears in cases, when we can speak about data objects, current object, its position and initial sector.

Currently it applies to the Explorer and Object map modes.

The HEX tab may look slightly differently depending upon task settings.

In case of translator rebuilding it contains additional fields and buttons. Please see the description of translator regeneration for details.

You can use the right-click menu within the tab to change the number of bytes per line or column, font and encoding.

Figure 47. The "HEX" tab

4.7 Basic modes.

4.7.1 Data area copy creation. The window of this mode will be the primary one if during task creation you have selected the Make data copy

option. The mode is used during sector-by-sector copying of a data range (from LBA to LBA) from the drive being tested.

The Make data copy option applies to all modes of a task thus created and whenever reading of certain sectors is required the program checks first whether the data have been read earlier (map). If there have been no prior attempts to read the data, the program will attempt to read them with subsequent copying to destination and map correction provided that the Work with copy only task option is disabled), otherwise the data will be read from an earlier copy.

In this mode the software creates a sector-by-sector copy of the data area from the malfunctioning drive. The copy may be created in the form of image files in task subdirectory or immediately on another drive connected to the second port of the PC-3000 UDMA board or on a drive connected to standard system port. Copy location is defined during task creation.

In the data copy creation mode the window includes the main menu, quick access toolbar, informational panel that displays task and process information and a panel containing the Log and Map tabs. The window appearance in this mode is shown in the figure below.




Figure 48. Data area copy creation

The panel of quick access buttons in that mode consists of 5 groups (please see the figure below).

Figure 49. Quick access toolbar in the copy creation mode

− Power control (ATA0 and ATA1). − Task settings and information (Parameters, Information, Statistics). − Additional modes (Explorer, GREP search, Verification, Mount task as a drive). − Process management for copy creation (Start / Abort). − Exit the task. To start copying, you will have to specify the parameters (Task parameters button) and click the Begin button.

To start copying, you will have to specify the parameters (Task parameters button) and click the Begin button.

The action of the Abort button may not be instant; sometimes it terminates the process only after a while. That peculiarity is determined by the fact that during work with a damaged drive finalizing a single operation may take some time.

Process status is displayed in the informational panel. Additional information on the current progress is appended to program log. During task execution you may switch to map tab and check the results of copying data taking into account the legend (the figure above demonstrates the program window in copy creation mode with an active Map tab).

Please see the section Main menu of the primary task window → The “Options” menu for a description of mode settings window, its peculiarities and purposes of available parameters.

The functions of all panels in that mode and their controls are described above in the Primary window of the data recovery task section.

You cannot switch to other modes while the copying mode is being used. You can only review task information, copying statistics and edit the parameters.

4.7.2 Data copy export mode. The mode is intended for exporting as image files a copy of data created in another task.



To enter the mode, you should create a task for work with the File image device. During task creation the program will offer to select the directory containing image files and a file containing parameters of the task, which has created them.

The mode interface is simple and requires no special comments. You should open the editing window for task parameters via the menu or quick access button, specify the borders of the sector range that will be exported, click the Begin button and wait until the procedure is finished.

4.7.3 Explorer mode. The main purpose of that mode is to display visually the logical structure of data on an inspected HDD,

assistance to users in its interpretation and modification, if necessary.

The mode has derived its name from the similarity of its appearance to Windows Explorer (with a tree in the left pane, item list in the right pane, icons and a right-click menu).

The composition and structure of displayed information are determined mainly by the requirement of the most precise reflection of data arrangement on a drive (type, location, relation, etc.). Employed methods also follow from the needs of data recovery tasks (viewing of object's initial sector, retrieval of an associated list of object sectors, etc.).

Depending upon task settings the Explorer can be the main or an auxiliary mode. However, the mode is always available, and you can use it as the main one even in cases, when it is originally auxiliary. E. g., when a disk contains a lot of defective sectors and the Make data copy option is enabled; the mode can be used for quick selective copying of data without creation of a full drive copy.

Note! When the program reads data from drive surface in the Explorer mode, it ignores some settings defined in the Task params window, namely the number of reading retries and jump size. You should also keep in mind that sectors read earlier with an error will not be read again. Consequently, to read the most valuable data from a HDD (Boot, FAT copies, MFT), you should switch to the Object map mode where the limitations of the Explorer mode do not apply.

4.7.3.1 Appearance, controls and navigation.

Window appearance in the Explorer mode is shown in the figure below:

Figure 50. Window appearance in the Explorer mode

The tree with a list of objects making up the logical drive structure is displayed in the left frame; the list of child objects for the currently selected tree object is shown in the frame to the right. You can navigate both lists and

Toolbar

Objects' tree of HDD logical structure

Table of child objects (sorted in the ascending order by the "Name" column)

Status line

Panel with tabs: Log, Map, HEX (binary editor). The HEX tab is selected allowing the user to control the validity of data in the initial sector of a selected object.

The directory contains files and folders marked for copying

File marked for copying

Group of files selected for copying; however, they are unmarked (differences between copying methods are discussed further)




switch between them using the mouse or keyboard. All currently available actions over the selected element in any list can be invoked from the right-click menu (some actions are also associated with shortcut keys).

The table of child objects is sorted by default in the ascending order ("Δ") by the Name column. Users can change the order (ascending "Δ" or descending "∇") and sorting column by clicking the header of the required column with the mouse. Besides the sorting methods, users can adjust column width. Default settings modified by the user are saved in the current task parameters. The table of child objects displays them using icons associated in your OS with

their respective data types, all other files belonging to unrecognized types are assigned the icon.

Quick access toolbar is located above the lists. It consists of several groups (please see the figure below):

− Power management − Task parameters and information about it (Params, Info) − Auxiliary modes (GREP search, Verification, Mount task as a drive) − Current process management (Skip and Abort process) − Exit the task.

Figure 51. Toolbar in the Explorer mode

The Abort button is used to stop any process that the Explorer may be performing (unfolding a directory, copying, etc.). Appearance of this button (while there is no Begin button) and special attention to it follow from the fact that work with malfunctioning drives or drives with corrupted logical structure may cause a totally unforeseen situation (infinite looping, copying of a file of an erroneously large size, reading of a large corrupted area), which may need to be terminated.

Below the lists there is an informational panel, which displays additional information on the selected tree element (the number of child objects and their total size (for directories only)).

The lower window pane contains a panel with log, copy creation map and sector viewing tabs. The presence of these tabs depends upon task settings.

During data recovery process you may encounter totally unexpected problems resulting from physical damage or logical data corruption, which in their turn may cause problems during logical analysis performed using the Explorer.

Such nature of possible problems determines two main requirements: − An opportunity to receive maximum information about the progress of the currently running process, when

necessary (up to the number of an individual sector being read). − An opportunity to terminate any process at any moment.

To comply with the above requirements, the program in the Explorer mode contains three main elements: a window for output of work log and service information, the Abort button and a slider regulating the level of details for data pertaining to currently running processes.

The window for output of work log and service information requires no comments.

As we have already mentioned, the Abort button is used to terminate the process running at the moment. Please note that Explorer operation actively employs multithreaded model of Windows operation, so pressing the button will terminate the current active process (e. g., directory unfolding, file copying, FAT reading, etc.). Because of some peculiarities in work with a malfunctioning drive, some processes (sector reading, no matter whether it has been successful or not) must be finished in a certain manner, otherwise you will have to power off the drive, power it up again, etc. Therefore sometimes pressing Abort does not immediately produce visible results (a respective message in the informational window, termination of work with a drive, etc.). Click Abort several times.

The debugging info slider of the Log tab allows regulation of the volume of output data about the process progress. The upper slider position means complete information, the lowest disables data output, intermediary settings provide more or less complete reports respectively.

If you have enabled the Create virtual translator option during task creation, you will see a Table of shifts to the right of the object list; the table will be described in detail in the Virtual translator creation section.

4.7.3.2 Explorer objects.

Objects displayed in the Explorer list panels represent the elements of logical data structure of a hard drive. Their purpose is described in the table below.



Icon Name Description MBR The main boot record, MBR (Master Boot Record, sector 0) Primary/Secondary

Partition Primary/secondary Partition Entry (16-byte structure)

Extended Partition Extended Partition Entry (16-byte structure) Boot Boot sector of a partition Root Root directory of a partition Folder File system directory Lost&Found An artificial directory, which will be used for placement of orphan directories

and files discovered while using logical recovery methods (i.e. those, for which the program cannot find a parent directory)

File Files of a partition. + – file with the "compressed" attribute + – file with the "sparse" attribute + – deleted file or folder.

Each type of objects displayed within Explorer panels is associated with its own icons, relevant text information and a selection of actions available from the object right-click menu. The list of actions is determined by object type and the type of file system that the object belongs to. The right-click menu can also be invoked by the "Alt+Down" shortcut key combination.

The Scan and View the first sector methods are common for almost all of the above-listed objects.

Scan means reading again (or, perhaps, for the first time) of the information pertaining to the selected object and updating the list of child objects. Of course, the information will be different for each object type (zero sector for a drive (MBR), a list of corresponding sectors defined by the file system for a directory, etc.). This method is not defined for objects belonging to the File type since all information about files is stored in their respective Folder object.

View the first sector command loads the first sector of a selected object into the binary editor for viewing (and editing, when necessary). In some cases, the method may be unavailable although it is defined for all Explorer objects. That is possible in several cases:

− Object created artificially. − Insufficient information about an object (in case of NTFS partitions a situation may arise when

information about a file has been retrieved from a directory while the MFT record corresponding to that object is missing or corrupted, then the Explorer displays a file with zero size).

Besides, there is another fact, which requires explanations. In case of NTFS a question arises regarding the location to be understood as the initial sector – the first sector of the corresponding MFT record or the first sector of a data stream. This problem is solved based on the location of an object's data stream. For resident data (placed within MFT) the first sector is meant to be (and display) the first sector of the MFT record (although frequently the data stream is found in the second sector of a record). For non-resident data it will be the first sector of a data stream located outside the MFT.

4.7.3.3 Master Boot Record (MBR).

For the MBR record, in addition to the methods listed above, the following tools are available: − Map (for the MBR object the whole HDD surface is understood as the map; the list of chains displays

accessible drive partitions). − Properties (a window of partitions table will be displayed, data in the table are editable, please see the

figure below).

Figure 52. Window of drive descriptors (MBR) opened after Properties selection




− Raw recovery (raw recovery process starts for the whole drive using an interval equal to 1 since information about cluster size is located in boot sector of each partition and at that stage it is yet unknown; please see details in the Raw recovery section).

− Search NTFS structures (automatic mode for restoration of NTFS partitions, please refer for details to the Automatic restoration of NTFS partitions section).

− Quick disk analysis (automatic mode for creation of a virtual partitions table in cases when MBR is not available).

− Image to file (the mode creates in user-defined file a copy of data based on partition table for possible further analysis using third-party software products);

− MFT Record Viewer (MFT record editor mode for visual presentation of logical MFT record structure in NTFS partitions, please refer for details to section MFT record editor ).

− MacOS Records Viewer (a specialized editor for MacOS data structures, please refer for details to section MacOS Metadata Editor). It allows reviewing (and, if necessary, editing in HEX editor panel) the following data structures: HFS Master Directory Block; HFS+ Volume Header; HFS+ Catalog Node Descriptor; HFS+ Extents Node Descriptor; AppleDrive FirstLBA; Apple Partition; EFI GPT Header; EFI GPT Entries. Visually the mode is a form consisting of two main parts: the left part of the screen contains the HEX editor panel, the right part displays the tree of the selected MacOS data structure. Data in the tree-like structure panel can be viewed only while the data in HEX editor panel can be modified, if necessary.

− Аpple Partition Map.

Map. An MBR or EPR map can be used, for example, for quick access to the boot sector of a corresponding partition or a copy of boot sector, if it exists. In FAT32 partitions, a copy of boot sector is usually located 6 sectors away from the main one, in NTFS partitions it is placed in the end of a partition. When necessary, found copies can be used for restoration of the main boot sector of a partition (via clipboard or a file) or for creation of a virtual partition.

Quick disk analysis. This automatic search method is intended for creation of a virtual table of partitions if the MBR of the drive being examined is damaged or unavailable for some reason.

Virtual table of partitions is built using the found boot sectors of FAT and NTFS partitions and their copies. First the program seeks boot sectors in small areas at the beginning and end of disk space. If it finds boot sectors, it adds to the virtual table of partitions the information about the boundaries of the partitions, which the sectors describe. Further search is recursive since information about partition borders found during the initial stage allows searching for boot sectors at the borders of the partitions found earlier, and so on.

The method has certain limitations. Since the program looks for boot sectors only in small areas at the beginning and the end of disk space (during the first stage), we can imagine a situation, in which the method can product negative results. Suppose that a drive has two partitions, the first one is NTFS with a corrupted boot sector and the second is FAT. In that case search in a small area in the beginning of disk space will not produce any results because the boot sector of the NTFS partition is corrupted. Search in the end of disk space will also return no results because in FAT partitions the boot sector and its copy are recorded in the partition beginning (consequently, for the second partition the sectors will be located somewhere in the middle of disk space if the partitions have approximately similar size). Thus, the first search stage will reveal no boot sectors (or copies thereof), which can be used to continue searching. In that case the whole partition should be scanned for boot sectors but evidently that method cannot be quick.

The mode is a simplified (and therefore quick) and completely automatic method for solving the problem of the most common and simple cases of logical corruption. If the method does not produce positive results, you can use more sophisticated methods of logical restoration (for FAT and NTFS partitions), which will be described further. However, these methods need (and in most cases require) a complete copy of all data for complicated and long analysis.

Add virtual partition. A virtual partition is an artificial partition in the Explorer mode produced by creation of a partition boot sector in a task database (without actual data recording to the drive being examined). As a result of generation of that artificial boot sector, a new partition of a type specified during creation will appear in the Explorer; its properties will be characterized by the parameters defined in that boot sector. A manually created virtual partition allows you to use all tools applicable to normal partitions, unlike virtual partitions created as a result of some automatic data recovery modes (e.g., Logical recovery). You can save the virtual boot sector to disk, if necessary.

While creating a virtual partition users have to specify the type of the partition being created, its initial and final LBA and cluster size (please see the figure below). Then the user will see a dialog window necessary for correction of the remaining parameters of that boot sector.



Figure 53. Dialog for definition of virtual partition parameters

Figure 54. Dialog for editing the boot sector of a virtual partition

There is another method for addition of virtual partitions, which may be more convenient in certain circumstances. It is available from the boot sector viewing window (Service → Add virtual partition …). The viewing window in its turn can be opened from the binary editor window (View as ..).

Figure 55. Adding a virtual partition from the boot sector viewing window

As an example, let us suppose that we are dealing with a drive with corrupted MBR sector. We can run GREP search for boot sectors in a small area at the beginning of the drive space (FAT, NTFS). Suppose, that a boot sector of an NTFS partition was found by its signature. Open the sector in binary editor and choose View as .. → Boot NTFS, if the sector data are valid, we can add the sector as a virtual partition (critical properties of a boot sector are validated automatically and highlighted in yellow if they exceed normal range). The program checks whether the sector is a copy or if it is the original. The check includes calculation of the partition's position (whether it is inside the drive data range), control of the position of the other boot sector copy, MFT and MFT Mirror for NTFS partitions and FAT for FAT partitions. If the checks do not provide an unambiguous answer telling whether the sector is a copy or the original, then both variants remain available in the context menu (Boot sector and Boot sector copy), otherwise just one possible and correct variant will be left in the list.

Аpple Partition Map. Information about drive structure (partition table) can be stored in locations other than MBR. In MacOS file system the table of partitions immediately follows the zero sector, and each slot of the table occupies a single sector. The zero sector contains information about sector size and the total number of sectors. The initial sector describes the table itself, further slots define unused areas and drive partitions.

This method uses the table of partitions to build a map of drive structure (including the table itself, unused space and loaders).




Figure 56. Apple Partition Map mode

Note! Drive structure can be described using one more method, in a GUID table of partitions (the standard has been introduced by Intel). Data Extractor supports three methods of drive structure organization: MBR (Microsoft), Apple Partition (MacOS) and GUID Partition (Intel).

GPT (GUID Partition Table) uses LBA addressing. Executable binary code is located in LBA 0 (MBR sector), GPT header – in LBA 1 with the table of partitions immediately following it. In 64-bit Windows OS 32 sectors are reserved for GPT, therefore sector 34 is the first used sector on disk.

Figure 57. Drive structure using GUID Partition table

GPT header and table of partitions are duplicated (their copies are placed in the end of disk space).

The header of the partitions table defines disk blocks, which users can access. It also determines the number of partition entries following the header and their size. In 64-bit Windows Server 2003 128 partition entries are reserved, each of them is 128 bytes.

The header contains GUID – it is a data structure containing its own size and position (always LBA 1), size and position of header and partitions table copies (always last disk sectors). It also contains a checksum for itself and the table of partitions.

Partition entries contain the type of GUID partition (first 16 bytes), unique partition GUID (next 16 bytes), initial and final 64-bit LBA of a partition, partition name and its attributes.

4.7.3.4 Partition Entry.

The following tools are available for objects of the partition type:



− Map. − Raw recovery (raw recovery process starts for the whole partition using an interval equal to 1 since

information about cluster size is located in boot sector of each partition and at that stage it is yet unknown; please see details in the Raw recovery section).

− Search NTFS structures (automatic mode for restoration of NTFS partitions, please refer for details to the Automatic restoration of NTFS partitions section).

4.7.3.5 Partition boot sector (boot).

Modes supported for objects corresponding to the boot sectors of partitions are rather different. These objects support methods available for all types of partitions.

4.7.3.6 Common methods available for all types of partitions.

− Properties − Partition map − Raw recovery (raw recovery process starts for a partition with the interval equal to cluster size, please see

details in the Raw recovery section).

Properties. This method allows reviewing (editing) the structure of a partition boot sector. The figure below demonstrates a sample corresponding window for a boot sector of a FAT32 partition.

Note! Values in light fields of the form are essential for correct data recovery from the selected partition. The program validates the correctness of data input into these fields during entry. If the entered data are invalid, parameter title will be highlighted in yellow.

Figure 58. Viewing a boot sector of a FAT32 partition using the "Properties" tool

Partition map. This mode can be used for the following purposes: − To verify and correct the locations of metadata important for recovery of data within a partition during

translator regeneration (copies of boot sector, FAT, MFT beginning, etc.). − To verify the location and integrity of basic metadata of a partition in case of logical corruption (quick

access to boot sector copies, FATs). − When working with a malfunctioning drive, you can select the chains most important for access to data

(e.g., FATs, boot sectors) and read them to a copy using the strictest parameters (higher number of reading attempts), and estimate the quality of reading results.

Please refer to the Object map section for details regarding the use of this mode. Window appearance in the Object map mode is shown below.

Values in decimal notation Parameter Parameter size Values in hexadecimal notation




Figure 59. Partition map" for a FAT32 partition

Additionally, the menu includes items relevant for individual partition types only.

4.7.3.7 Additional methods for FAT partitions.

− Used sectors map. For FAT partitions the program builds a map of used space based on the active FAT copy. When working with a malfunctioning drive (with lots of bad sectors), the map allows you to decrease the necessary time and load on the HDD.

E.g., in cases, when you manage to build a map of used sectors and FATs address the data being recovered (i.e. the partition has not been reformatted), then, to decrease the overall procedure duration and load on the drive, you can use the built map only to create a data copy and skip reading bad sectors in non-addressed area of the partitions.

− Unused sectors map. For FAT partitions the program builds a map of free space (for FAT partitions it uses the active FAT copy to that effect).

If the data being recovered are located in a non-addressed area (a partition has been created over an older partition and the sought data were in that older partition), then it makes sense to look for user data in the raw recovery or GREP search modes using the map of unused space.

Note! Correct generation of Used and unused sectors maps while reading copies of FAT does not allow using the command to read ignoring CRC (if sector integrity control is skipped, then a sector is considered to be filled completely; therefore, the Used sectors map will occupy the whole data area of a partition while the Unused sectors map will be empty).

Note! If the bitmap used to build the map of used/unused space contains sectors read with any error, such sectors are assumed to belong to both maps. Consequently, in such case the total size of used and unused space will be greater than the partition size (because the same sectors from it appear in the used and unused space maps). The not applies for all file systems supported by DE.

− Map of sector chains. It allows retrieval of a full object map beginning with its initial sector using the active FAT copy.

Figure 60. Dialog for initial sector entry while building a map of sector chains



The mode can be used to copy files the relevant information of which in the parent directory slot has been lost. In that case, if you employ GREP search to find file beginning. If the active FAT copy contains information about location of that object beginning with the found sector, then you can build a map of sector chains and save the object to a drive connected to one of the standard ports. Then you have to rename it accordingly (GREP search determines possible object extension) and the result will be a file with a size rounded up to the cluster size. Certain file types may fail to open in that situation; so the initial file size will have to be corrected manually.

− Show deleted objects – this option defines whether the program will show deleted files and folders in the Explorer window that displays the selected FAT partition.

Please keep in mind, that this Explorer option in general is not a complete replica of the Partition analysis mode with the Seek deleted objects option enabled as in this case the program will only find deleted objects in subdirectories of a FAT partition revealed on the basis of a recursively built tree. When Partition analysis is used with the Seek deleted objects option enabled, you may also find deleted objects in lost directories (i.e. directories, which are not referenced from within other folders).

Besides, the fact that a deleted object is displayed in Explorer does not guarantee its successful copying.

Figure 61. Explorer window containing deleted objects

− Folders validity control. As we have noted above, the tree of objects in Explorer is built recursively, i.e. it uses the root directory containing descriptors of subdirectories and files; the subdirectories in turn may also contain their own files and subdirectories, and so on. Let us assume that an object in root (or any other) directory contains a descriptor of a child subdirectory. If this option is enabled, the program will examine the specified cluster checking if it contains the subdirectory specified in the corresponding descriptor of its parent directory. If there is none, such object will not appear in the tree of objects. If the integrity control is not used for subdirectories, the tree of objects will display all subdirectories without checking whether they actually exist.

This method must not be used in case of translator restoration because during the initial stage of virtual translator creation the required directory may appear in a location other than required because of shifts.

− Files descriptions validity control. If you select this option, the program will validate file names, size and initial sector (except for the date). Consequently, if the data are invalid (e.g., the initial sector is outside the partition boundaries), the corresponding object will not be displayed in Explorer.

− Use Boot copy (provides for an opportunity to work with a FAT32 partition using the data from a boot sector copy).

− FAT copies… → 1 copy (2 copy, Ignore FAT) (allows you to select the number of FAT copy that will be used for further work or ignore FAT altogether).

− FAT copies… → Connect file as a FAT copy.

You can use the Partition map mode to save a FAT copy to file. This menu item allows connection of a copy thus saved (perhaps, corrected manually or using other software tools) for correct addressing of a partition. A corresponding record will appear in the right-click menu of a partition after file connection (please see the figure below).




Figure 62. Connecting a file as a FAT copy

Please keep in mind that this setting will not be preserved when exiting a task and also in case of scanning the parent objects; a respective warning appears when you select this command (for a boot sector object, such objects are Task, MBR and MBR slot).

Figure 63. Connecting a file as a FAT copy

− FAT copies… → Map (allows reviewing the map of the selected FAT copy).

− FAT copies… → Comparison and correction of FAT copies taking into account defective sectors. This method is available in copy creation mode only. When it is used, the program reads both FAT copies replacing in each copy bad sectors with sectors from the other copy if they have been retrieved in it without errors.

− Show deleted objects (determines whether deleted directories and files will be displayed).

− Partition analysis (allows automatic parsing of a FAT partition in case of serious logical corruption, please see the Partition analysis section for details).

4.7.3.8 Additional methods for NTFS partitions.

− Active Boot. Any NTFS partition contains two boot sectors – the primary one located in the beginning of partition space and its copy at the end of partition. If the primary boot sector and its copy match or if one of the sectors is invalid (it cannot be read or it contains garbage), you can select the boot sector for further work and, consequently the Active Boot menu item will be grayed out. If the primary boot sector and its copy differ but both contain valid data, you can choose which sector will be used (Base and BackUp respectively).

− Select MFT descriptor. Similarly to the duplication of boot sectors, NTFS also duplicates 4 initial MFT records. DE performs an identical check for them and either decides with certainty, which records should be used further (then the menu item will become grayed out), or allows you to make the choice if both copies are correct but differ from each other (Base and Mirror respectively).

− Used sectors map. For NTFS partitions the program builds a map of used space based on $Bitmap data. When working with a malfunctioning drive (with lots of bad sectors), the map allows you to decrease the necessary time and load on the HDD.

E.g., in cases, when you manage to build a map of used sectors and MFT addresses the data being recovered (i.e. the partition has not been reformatted), then, to decrease the overall procedure duration and load on the drive, you can use the built map only to create a data copy and skip reading bad sectors in non-addressed area of the partitions.



− Unused sectors map. For NTFS partitions the program builds a map of free space based on $Bitmap data.

If the data being recovered are located in a non-addressed area (a partition has been created over an older partition and the sought data were in that older partition), then it makes sense to look for user data in the raw recovery or GREP search map using the map of unused space.

Note! Correct generation of Used and unused sectors maps while reading copies of $Bitmap does not allow using the command to read ignoring CRC (if sector integrity control is skipped, then a sector is considered to be filled completely; therefore, the Used sectors map will occupy the whole data area of a partition while the Unused sectors map will be empty).

Note! If the bitmap used to build the map of used/unused space contains sectors read with any error, such sectors are assumed to belong to both maps. Consequently, in such case the total size of used and unused space will be greater than the partition size (because the same sectors from it appear in the used and unused space maps). The not applies for all file systems supported by DE.

− MFT map. MFT is the most essential part of metadata for NTFS partitions.

In case of drives with logical corruption, building of an MFT map means that we have all metadata for data recovery (if it is the necessary MFT, i.e. the partition has not been reformatted). This mode helps evaluate the size of MFT and the number of records therein. E.g., if you are restoring a partition containing lots of data (several thousands of files), and the built map is small (e.g., taking 500 sectors corresponding to approximately 250 addressed files), then most probably the partition has been reformatted and available MFT cannot be used for recovery of required data since it belongs to the new partition.

When working with malfunctioning drives (with present bad sectors), building of an MFT map means that we have only the information about locations of all necessary metadata, which then have to be recovered with all necessary scrutiny (using retries and various reading commands). The number of bad sectors can be used to evaluate the degree of metadata corruption. The more successful MFT reading is, the higher will be the probability of receiving access to necessary data. A successfully retrieved MFT provides information about data properties and appropriate locations. However, there is no guarantee that information about the placement of a required object will be sufficient to copy it After MFT reading, you are advised to run Scan MFT. As a result, the program will build in the Explorer a virtual file system tree described by that MFT.

Theoretically, MFT map can be used to set shift points for MFT chains when restoring the translator manually (the automatic method available from the right-click menu of the MBR slot object is more expedient; however, situations are possible when it cannot be applied, please see the Virtual translator creation for an NTFS partition, Mode limitations section for details).

− MFT_Record properties. An MFT record can be selected by its number of by LBA number. Brief summary on the selected MFT record will be output to log, complete item description will be displayed in specialized editor (MFT record editor, please see corresponding section for details).

− Partition analysis (automatic mode for restoration of NTFS partitions, please see Automatic restoration of NTFS partitions for details).

− Scan unused space (automatic mode for restoration of deleted NTFS partitions, please see Automatic restoration of NTFS partitions for details).

− Scan MFT (the program scans MFT records and uses them to build a virtual file system of the selected partition, please see the Scan MFT section for details).

− Clear the table of results. When working in Explorer with an NTFS partition, the programs stores in task database certain metadata conventionally referred to as the table of results. If the table of results has been filled using incorrect source data, this method allows you to clear the table and, having altered the source data, fill it again.

E.g., when working on a partition with a malfunctioning translator, invalid data may appear in the table of results (MFT parts are shifted relatively to their supposed normal position, as a result, the program cannot calculate correctly the numbers of records in the table). Consequently, as soon as all MFT shifts are discovered (shifts for all of its parts) we should be able to receive access to data in Explorer. To do so, you have to clear the table of results removing unreliable data (added during an earlier stage of Explorer operation, when not all shifts were found) and scan MFT (the program will add to the results table reliable data taking into account the detected shifts).

− List of non-resident files. For NTFS partitions the program can build a table of all non-resident files with all objects ordered by their initial LBA in the ascending order. The table can be used first of all to search for shift points during translator restoration (please see section 4.7.4.8 for details). For original drive partitions and virtual partitions created manually the table of objects will be built simultaneously with unfolding of the partition tree. For virtual partitions produced using automatic recovery methods the list of non-resident files will be filled completely because those methods imply scanning of MFT or search for all records.




4.7.3.9 Additional methods for Ext2(3) partitions.

− Only files and folders. There are many file types existing in UNIX. Files that users create are called regular files, folders are referred to as directories. In addition, there are many «files» for which the system allocates no actual blocks (a block is a counterpart of cluster). Those files are names used for access to hardware devices or communication channels.

This method allows regulation of the number of file types displayed in Explorer for Ext partitions. Therefore, the program will display just regular files and folders or all file types existing in Ext partitions. A similar mode is available for UFS partitions.

− Used / unused sectors map (from Bitmap). In Ext file content is stored in blocks represented by chains of adjacent sectors. A certain number of blocks are combined into block groups. Group descriptor contains a bitmap for the group blocks. The bitmaps for group blocks can be used to build the maps of used (or unused) blocks for all the groups in a partition.

− Properties. Basic information about the structure of an Ext partition is stored in the superblock data structure located in the file system beginning. The superblock contains such essential properties as block size, the number of blocks in group, the number of index nodes in group and file system, etc.

The method allows reviewing and, if necessary, editing the main superblock properties in the following window:

Figure 64. Ext2(3) viewing and editing window

− Sector of the group descriptors table. The table of group descriptors is a list of data structures called group descriptors; the list is stored in file system block immediately following the superblock. The table contains a record for each group of blocks in file system, and each record contains information about initial addresses of Bitmaps for blocks and index nodes and tables of inodes.

The method allows reviewing the main standard fields of the group descriptors table in the following window:



Figure 65. Window for reviewing of Ext2(3) group descriptors table

4.7.3.10 Additional methods for UFS1(2) partitions.

− Only files and folders. There are many file types existing in UNIX. Files that users create are called regular files, folders are referred to as directories. In addition, there are many «files» for which the system allocates no actual blocks (a block is a counterpart of cluster). Those files are names used for access to hardware devices or communication channels.

This method allows regulation of the number of file types displayed in Explorer for UFS partitions. Therefore, the program will display just regular files and folders or all file types existing in UFS partitions.

− Map of inodes table. In UFS metadata of each file and directory are stored in a data structure called index node (inode). The structure is added to an index table and has fixed size. UFS partition is subdivided into sections referred to as block groups; therefore, each group contains its own table of inodes. This method allows building a general map of inodes table, which will consist of group tables.

− Metadata map. Each group of blocks contains the following metadata: superblock copy, group descriptor and inodes table. Consequently, the general map of partition metadata will contain all chains of metadata sectors from each group.

− Used / unused inodes map. The descriptor of each group contains a bitmap for the inodes table. Those bitmaps are used to build the maps of used (or unused) inodes for all groups in a partition. Since a single sector contains several inodes, it will appear in the used inodes map if at least one of the index nodes is used. Consequently, the map of unused inodes will only contain sectors with completely unused index nodes.

Note! During analysis of UFS partitions the most essential data is in superblock (or its copy), group descriptors (in fact they are all identical, and that makes their search and use considerably easier) and the inodes table (actually it is a counterpart of MFT in NTFS partitions). Therefore, the maps described above have been implemented to recover partition metadata (with highest precision) in case of serious corruption and then proceed to attempts to selectively read user data.

− Used / unused blocks map. In UFS file content is stored in blocks represented by chains of adjacent sectors. A certain number of blocks are combined into block groups. Group descriptor contains a bitmap for the group blocks. The bitmaps for group blocks can be used to build the maps of used (or unused) blocks for all the groups in a partition.

− Used / unused fragments map. In UFS file content is stored in blocks, which can be subdivided into fragments. A fragment is used for storage of final file bytes (instead of allocating a complete block). Group descriptor contains a bitmap for the group fragments. The bitmaps for group fragments can be used to build the maps of used (or unused) fragments for all the groups in a partition.

− Superblock. UFS superblock is located in the beginning of file system space; it contains basic information about FS size and configuration. By default, superblock data are used for analysis of UFS partitions.

− Superblock copy. Each group of cylinders contains a copy of the superblock. Theoretically, the mode allows switching to any available copy of the superblock. Please keep in mind, however, that unlike FAT and NTFS,




UFS does not use fixed positions of superblock copies; instead they are defined in the superblock itself. Therefore, if the superblock is not found (or contains garbage), then locations of superblock copies is unknown and the mode is not available. If the superblock is found and contains valid data, then switching to its copy makes no evident sense.

− Superblock properties. As we have mentioned above, in UFS superblock is located at the beginning of file system space and it contains such partition information as fragment size, the number of fragments in a block, the size of blocks group and locations of various data structures in each group. This method allows viewing and, if necessary, editing of essential superblock properties in the following window:

Figure 66. UFS1(2) superblock viewing and editing window

− Superblock copy properties. This method allows viewing and, if necessary, editing of the required superblock copy.

− Group descriptor properties. In UFS group descriptor occupies a complete block. It consists of a set of standard fields and an open area intended for storage of various tables. Standard fields contain service information and describe the structure of the final block part. This method allows viewing and, if necessary, editing of the main standard fields in a group descriptor using the following window:

Figure 67. UFS1(2) group descriptor viewing and editing window

Note! The methods described above will only be available if a valid superblock is present.

4.7.3.11 Additional methods for HFS+ partitions.

− Active VolumeHeader. Any HFS+ partition has two Volume Headers – the main one located at the beginning of a partition and its copy (Alternate Volume Header), located in the partition end (more specifically, at offset 1024 bytes from the partition start and end respectively). In cases when the main Volume Header and its copy match, or if one of those sectors is invalid (it cannot be read or it contains garbage), you can confidently select the Volume Header for further operations and therefore the Active VolumeHeader menu item will become grayed out. If the main Volume Header and its copy differ, but both are valid, then you can choose one of them (Base and BackUp respectively).



− Allocation File map. This method allows building an Allocation File map for HFS+. Allocation File is one of five HFS+ special files, which determines, which of allocation blocks are used and which are free (HFS+ distributes sectors into groups referred to as allocation blocks).

− Extents File map. The method allows building an Extents Overflow File map for HFS+. Extents Overflow File is one of five HFS+ special files intended for storage of additional extents of user files and special files (8 initial extents are stored in the Catalog File of a partition).

− Catalog File map. The method allows building a Catalog File map for HFS+. Catalog File is one of five HFS+ special files, which describes the directories and file structure of a partition.

− Attributes File map. The method allows building an Attributes File map for HFS+. Attributes File is one of five HFS+ special files, which contains additional information for files and directories.

− MacOS Records Viewer. MacOS Records Viewer is a specialized editor for HFS+ data structures. It allows reviewing and, if necessary, editing of the following data structures:

a) HFS Master Directory Block

b) HFS+ Volume Header

c) HFS+ Catalog Node Descriptor

d) HFS+ Extents Node Descriptor

e) AppleDrive FirstLBA

f) Apple Partition

g) EFI GPT Header

h) EFI GPT Entries.

− MacOS Records Viewer → Allocation File. This method allows viewing and, if necessary, editing in MacOS Records Viewer the data of the Allocation File structure.

− MacOS Records Viewer → Extents File. This method allows viewing and, if necessary, editing in MacOS Records Viewer the data of the Extents Overflow File structure.

− MacOS Records Viewer → Catalog File. This method allows viewing and, if necessary, editing in MacOS Records Viewer the data of the Catalog File structure.

− MacOS Records Viewer → Attributes File. This method allows viewing and, if necessary, editing in MacOS Records Viewer the data of the Attributes File structure.

− MacOS Records Viewer → Volume Header. This method allows viewing and, if necessary, editing in MacOS Records Viewer the data of the Volume Header structures (Base and BackUp).

− Used / unused sectors map (from Bitmap). Information is stored in HFS+ exclusively in blocks (allocation blocks), represented by chains of adjacent sectors. This method allows building maps of used (or unused) blocks based on the data from Active VolumeHeader and Allocation File.

4.7.3.12 Directories and files.

The following tools are available for objects of the directory type: − Scan − View the first sector − Map − Save …(F2) − Save marked … (Ctrl+F2) − Find files (Ctrl+F) − Map of folder − Map of marked folders and files − Report on marked folders and files − MFT_Record properties (for NTFS partitions only, brief summary on the selected MFT record will be

output to log, complete item description can be displayed in specialized MFT record editor, please see correspoding section for details).




Save – command allows saving the selected objects (files and/or directories with their contents) to a user-defined folder. The method works with files and folders selected in the objects list tree or in the table of child objects (but multiple selections are possible only in the table of child objects, not in the list tree). Objects can be selected similarly to the manner used in standard Windows Explorer except for selection from the current object to the first and/or the last one (accomplished by pressing Ctrl+Shift+Home or Ctrl+Shift+End respectively). The use of that method with any directory results in copying of all contents within that directory.

For example, the figure below contains a table of child objects with three selected EXE files. Although the table contains three other marked files and a directory, they will not affect the results of the Save command.

Figure 68. Multiple selection in a table of child objects

Save marked – this command allows you to save files and folders marked in Explorer (located on lower hierarchy levels relatively to the object, for which you invoke the command) to a spare drive connected to one of the standard ports.

For example, the picture below demonstrates an objects' list tree with the "Windows" folder selected in it. The selected directory contains marked files and subdirectories (some of them are visible as shown by the icon to the left of the folder). If you select Save… the program will attempt to copy the whole "Windows" directory. If you select Save marked, the program will copy to a drive connected to one of the standard ports only marked objects located within the selected folder (the marked "NC" folder will not be copied because it is on the same hierarchy level with the "Windows" folder).

Figure 69. Saving marked objects to a spare drive connected to a standard port

This method can be used to mark the data that have to be copied, navigate to the root object and save all marked objects into the task folder.

The program supports an opportunity to interrupt copying of files that cause reading errors when working with a malfunctioning drive using the Save… and Save marked methods. If the Interrupt saving for damaged source files option is enabled, the program will offer to choose the actions to perform in cases when an error occurs while reading a file. The scenario (Parameters window) must define the file types to which the option will apply. Besides, it must contain the action to take when copying is interrupted – to save to spare drive the whole file including the part read with errors or discard the file. Since certain file types cannot be opened in case of incomplete copying, the user can define personally the copying method depending upon the situation (type of copied data and drive condition).



Figure 70. Directory selection dialog for saving user data

Figure 71. Scenario for actions in case if the option to Interrupt saving for damaged source files is enabled

Note! When the Save… and Save marked methods are used in the data copy creation mode, the program reads from the last cluster of each object the necessary sectors only (as determined by the object's size). This approach helps decrease the load on a malfunctioning drive and copying duration in cases, when bad sectors are outside the required data area to be read.

Consequently, if you switch to the Map mode for a saved object, some sectors in the end of the last cluster may be marked as unread.

Figure 72. Map of a saved object

Find files – this method can be used to search for files and folders matching user-defined conditions. The result of each search will be an Explorer instance containing found files/folders (preserving at that data hierarchy, i.e. the found files will be located in their parent directories). Therefore, you can run search recursively, for example, find first the directories matching the necessary condition and then start searching files within these results.

Please keep in mind that the program performs search for the whole parent directory on an objects tree.




The figure below demonstrates the results of search for all objects with the "exe" extension in the root directory.

Figure 73. Results of "*.exe" search within the "root" directory

To run a search, users have to define the search criteria.

Figure 74. Specification of file search criteria

Users can search by name, date and size. Searching by name uses different approaches to file and folder search. Searching by date and size is identical to standard methods and so require no explanations. When searching by name, the user can define both criteria at the same time, then the resulting list will contain files matching one of the conditions in the Including group and not matching any of the conditions in the Excluding group. The syntax of filters is identical to the syntax of search modes in Windows OS.

You can use the Deleted dropdown list to specify the following options for search: seek all, seek undeleted only and seek deleted only.

Map – this command allows reviewing of the placement map for a selected object (directory or file). For a directory the utility will display a list of chains it occupies (scanning of child objects will not be performed).

A map cannot be built for artificial folders and resident objects (NTFS).



Figure 75. The "Map" mode

Map of folder – performance of this command results in creation of a general map of all objects within a directory (without metadata in case of NTFS partitions). This mode is not available for the root Explorer objects since in fact a map for the root directory will be a map of occupied sectors.

Figure 76. The "Map of folder" mode

Please refer to the Object map section for details regarding work with map.

Map of marked folders and files – the mode builds a map of selected folders and files taking into account the hierarchy of the object for which the method has been invoked. E.g., if two directories are selected on the root level – Downloads and MyDocuments, and the method has been invoked from the context menu of the root directory, then both directories will be added to the map. If the method has been invoked from the context menu of one of the selected folders, then that respective folder will appear in the map. If the mode is initiated from the context menu of any other directory or file, then no objects will be added to the map.

The resulting map can be used for selective copying of the sectors pertaining to the necessary directories and files.

− Report on marked folders and files – the mode outputs to the standard text editor (Notepad) a list of marked objects, which contain unread, modified sectors or sectors read with an error.




Figure 77. Report on marked folders and files

The context menu for files does not contain the Map of folder method; instead, there is Open (F4) method available.

4.7.3.13 Mode peculiarities during data recovery.

1) Using the Explorer mode while working with a malfunctioning drive and creating a data copy.

Efficient use of the mode in case of a malfunctioning drive is determined mostly by a single assumption (and fact) – a damaged drive usually still contains enough accessible information to do without copying of all drive data but rather extract the necessary part selectively and relatively quickly.

Explorer application in that case has the following main peculiarities:

a) The Explorer manipulates copied data. You should keep in mind that data viewing and editing are performed for the data copy created earlier or being created in the process of Explorer mode use.

This peculiarity allows (in many cases) access to necessary user data on a damaged drive after just minor corrections to a data copy and rescanning of the respective object. Nothing is recorded to the damaged drive during the process, and the results of modifications become visible instantly.

Here is a typical example of such Explorer use: the boot sector of a FAT partition has been read with errors. The information about the number of FAT copies and cluster size is corrupted. An attempt to unfold the root directory fails. Therefore, we should use the sector editor (+ View as Boot FATXX.) to enter correct values into the corresponding fields and check the result immediately rescanning the corresponding object. Searching for FAT copies and other necessary data should be performed using GREP search. Eventually after a few minutes of work we receive an opportunity to unfold the logical structure of the partition further.

b) When the mode needs data retrieved previously, it does not access the damaged drive taking the data from the copy.

This peculiarity has two useful aspects. First, the data copied once will not be lost because it will be preserved in the copy. Thus, it prevents situations sometimes occurring during work with Lost & Found and similar software when a program reads a damaged drive several times, analyzes it, but when the data structure and placement finally become clear it cannot be accessed for recovery any longer, because the drive becomes totally inoperative beyond repair.

In the second place, such strategy of work with data minimizes attempts to access a damaged drive. It is essential in cases of drives almost ready to stop functioning because it considerably increases the chances that the HDD will remain functional until you actually have the discovered necessary data copied.

c) As a rule, the total volume of data necessary to restore the logical structure of partitions is relatively small compared to the total data volume of a drive.

The peculiarity also has two helpful application aspects. The main one is in considerable economy of time it takes to extract required data because data copying is selective. The idea should be clear taking into account significant capacities of modern drives and the ratio between really important data and garbage typical for most users and software. If a drive is seriously damaged the time thus saved may be enormous (IBM drives take approximately 8 seconds to read a single defective sector).

And, once again, the approach minimizes access to a malfunctioning HDD.

d) Since some data, which may become necessary during any procedure (e. g., directory scan), can be in corrupted area there may be two problems: long time required to perform a procedure and the reliability of results thus obtained.

e) Currently the software supports logical analysis for FAT, NTFS, HFS+, UFS1(2) and EXT2(3) partitions only (for FAT, NTFS and partially for HFS+ partitions automatic restoration methods are implemented; for other types of partitions such methods will be added later).



Examples of mode use. The simplest variant occurs when the structure of a required partition is opened in Explorer and you only have to copy the necessary data. If a reading error occurs while copying an object, you can switch into the Map mode for that object, specify stricter reading parameters for it and complete its reading into copy. Alternatively, you can mark the required data, navigate to the root directory, build a map of marked folders and files and read the data setting stricter reading parameters, if necessary.

A more complicated situation may occur when partition structure is completely or partially invisible in Explorer. Partition's hierarchy may be inaccessible completely, for example, when the boot sector is corrupted. Then you can try using GREP search to discover a boot sector copy. If the copy cannot be found, create a virtual partition and use it to experiment with the partition structure. Perhaps, access to some of the required data cannot be gained because of corrupted partition metadata (FAT copies or MFT, for FAT or NTFS partitions respectively). On FAT partitions you can experiment with different FAT copies trying to read them more thoroughly (using the Partition map → Scan selected chains mode); if there are BAD sectors, you may try to correct the copies (Comparison and correction of FAT copies taking into account defective sectors). The Comparison and correction… mode is available in the copy creation mode only. When it is used, the program reads both FAT copies replacing in each copy bad sectors with sectors from the other copy if they have been retrieved in it without errors.

For NTFS partitions it is recommended to retrieve the MFT (in the MFT map → Scan). If MFT contains a lot of defective sectors, you are advised to read it with stricter parameters and then launch MFT table scanning.

If logical corruption caused by physical damage is very extensive and the Explorer fails to provide access to the necessary data, for FAT partitions you can try using Partition analysis. The volume of data read to a copy and the resulting load on a malfunctioning drive will be considerably smaller than during creation of a complete copy depending upon the settings of the analysis procedure.

In the Partition analysis mode (for NTFS partitions) recovery manipulations will require all sectors of the specified range. Therefore, you are advised to make a complete copy of drive data or the sector range being analyzed (e.g., a partition) on another drive and initiate the mode for a copy of the required data.

2) Using the Explorer mode for virtual translator creation.

Explorer (or rather a modification thereof) is the main mode for translator restoration. Please see the description of translator restoration methods for details on Explorer use.

3) Using the Explorer for restoration of logical data structure on a functional HDD.

The Explorer is used for restoration of logical data structure because it allows data correction on an examined drive and you can immediately check the results using Explorer modes.

Unfortunately, it is difficult to describe all possible cases, so we shall give two examples:

Example 1. Let us assume, that we are working with a drive containing two partitions. The first FAT32 partition has to be restored; its boot sector and boot copy are corrupted (MBR slots are intact). There are two possible variants: edit boot sector directly on the HDD or create a virtual partition with the required parameters (type, cluster size, etc.). If you are confident and the drive has no recording problems, you can use the first variant. However, creation of a virtual partition is simpler and safer. In this situation you will have to edit manually the boot sector of the created virtual partition.

Note! If the boot sector copy were not corrupted, you could choose one of two possible ways. First, you could find the boot sector copy using GREP search, open the sector in binary editor in View as..→ Boot FAT32 mode and select the Service → Add virtual partition command to create the required virtual partition. Alternatively, you can initiate Quick disk analysis using the MBR context menu (then the volume of read and analyzed data will be slightly larger and the analysis results will contain all the found partitions).

We shall assume the second method is selected and create a virtual partition. In the Adding virtual partition window you will have to specify the partition type (usually it is known, in this case it is FAT32), its initial and final LBA and cluster size. The initial and final LBA should be taken from MBR slot. Cluster size should be left unchanged for now (the default value is 8), it will have to be corrected later.

After entry of all parameters in the Adding virtual partition window, press the Ok button and proceed to editing the boot sector of the partition. You will have to fill in correctly only the values essential for data recovery; these values are shown using light background. Here is the order in which the data should be filled in:




− BytesPerSector – the number of bytes per sector, usually 512 (200h).

− SectorsPerCluster – the number of sectors in a cluster, the default value is 8. You can calculate the value for this field as follows. Start GREP search selecting FAT folder as search criterion. You can interrupt the process as soon as it reveals several folders. Then use the found folders to estimate the approximate position of the root directory and the number of sectors per cluster. To do so, you will have to switch into View mode of the first found folder and use the binary editor to invoke the View as… → FAT folder mode. Use the FAT folder window that appears next to calculate in the FAT - Root sector panel a number of RootSectors values for different values of SectorsPerCluster (e.g., 4, 8, 16, 32). Repeat calculations for several found directories. As a result, the approximate position of the root directory will be indicated by the matching (or very slightly different) RootSectors values with fixed SectorsPerCluster value. You should enter the corresponding SectorsPerCluster value into the boot sector of your virtual partition.

Figure 78. The "FAT folder" window: calculation of root folder location and cluster size

− ReservedSectors – the number of sectors occupied by the loader and reserved, the default value for FAT32 is 32. In order to verify the correctness of that parameter, you should switch into the Partition map of boot-sector mode and use the table of chains, navigation panel and HEX panel (binary editor) to check the location of the first FAT copy (FAT starts with a media descriptor, F8h means a hard drive). Sometimes a situation may occur, when the first FAT copy is destroyed, but the second one remains. Then you can continue work with a partition by increasing the ReservedSectors value so that it addresses the second copy and by changing the number of FAT copies to 1. Exact location of FAT copies can be revealed using the GREP search mode by selecting FAT (Copy) as the search criterion.

− BigTotalSectors – the number of sectors. This parameter is calculated as the difference between the final and initial LBA.

− BigSectorsPerFAT – the number of sectors per single FAT. This parameter can be calculated as follows. During calculation of the SectorsPerCluster parameter we have computed the approximate location of the root directory, now it is time to pinpoint it more precisely. To do so, you will have to jump to the found sector in the binary editor and check whether it is a root directory. The check should be performed as follows. First, the sector must contain directory elements (View as… → FAT folder); second, the directory must contain no links to parent directory; third, usually moving one sector to the left will result in a sector containing zeroes (it is FAT end, which is usually empty). Having thus determined the precise position of the root directory, deduct from it the initial LBA and the number of reserved sectors occupied by FAT. If there is just one FAT copy, it will be the sought value, if there are two FAT copies (most typical situation), the number thus obtained should be divided by two.

Figure 79. Binary data editor containing the first sector of a root directory in a FAT32 partition



Figure 80. Binary data editor containing the first sector of an arbitrary directory in a FAT32 partition

As a result of correct filling of information for the boot sector of your virtual partition, you will receive access to the required data of the first FAT32 partition. If necessary, the boot sector thus created can be saved to the drive in order to work then with the latter directly (this does not apply to cases, when no recording to drive should/can be performed).

Example 2. The drive being restored contains two partitions (no matter, whether FAT or NTFS), but MBR is corrupted. In that case you will have to restore MBR slots (specify the partition types and their relative locations on the drive). MBR sector can be restored manually by specifying the partition type and its relative location on a drive using the boot sectors found during GREP search. In addition, you can use the automatic Quick disk analysis mode.

Figure 81. Drive descriptors window (MBR) opened by the "Properties" command

Quick disk analysis mode can be invoked from the context menu of the MBR sector. It will create virtual MBR slots using all found boot sectors as the basis. If you choose this automatic mode, you will not restore the MBR sector in the exact understanding of the term, although access to the data within partitions will be obtained using the virtual MBR slots.

Let us examine the procedure of manual restoration of MBR slots. Switch to the GREP search mode, specify boot sectors of FAT or NTFS partitions as search criteria and start search. As a result, the program will return several boot sectors (i.e. the sought sectors, their probable copies and erroneously identified sectors); you will have to select the right ones from the list. You can validate correctness of a boot sector within the binary editor in the View as…→ Boot XXX mode. Having thus selected two required boot sectors, position the pointer over the MBR sector in Explorer and use the right-click menu to invoke its Properties. Use the window, which appears next, to edit the type of partitions and their relative coordinates in accordance with the found boot sectors.

4.7.4 Virtual translator creation. The mode is intended for data recovery in cases, when HDD translator is corrupted.

Actual translator corruption is manifested in the fact that data are present on a drive, they are accessible and not damaged, but parts thereof are shifted and the shift grows larger from the beginning (LBA) to disk end.

Modified Explorer mode is the main visual mode for virtual translator creation (please see the figure below). The Explorer mode is used to identify the shifts and check the results of map corrections because it immediately displays all changes following from the entered modification. One example is the case, when adding the next shift opens the whole child directory on-screen.

The basic concept used for data recovery is consistent creation of a map for occurring shifts in dialog mode. Here the software applies knowledge of logical data organization in a drive and in specific partitions (FAT and NTFS).

On FAT and NTFS partitions, the program supports methods for automatic shifts search.

Relative sizes of partitions (i.e. the initial sector and total number of sectors)

Partition type (see the Reference section)

Link to itself and parent directory




Note! The Folders validity control method should not be used while restoring FAT partitions since during the initial stage of virtual translator creation a required directory may appear in a location other than necessary because of shifts.

Users should realize how the resulting shifts map will be used. In this case Data Extractor employs the shifts map (table) to calculate the true LBA value virtually rebuilding the corrupted drive translator.

Figure 82. Modified visual Explorer mode during translator restoration

The list of tools employed for drive translator rebuilding:

1) Shifts table and its right-click menu (in the right part of the screen).

2) Modified HEX tab with controls necessary to modify, add and search for the shift of the currently displayed sector.

3) The Object map mode that allows you to identify the actual locations of the beginning and end of sector chains (i.e. if you are combining a segmented file from its parts, you can obtain a list of sector chains for that file and coordinate it with a shifts map). Please see details in the Using an object map during translator rebuilding section.

4) Search shift points mode. This method is invoked by a button on the HEX panel of the log, which appears if you have enabled the Create virtual translator option. It allows using GREP search to find sectors around the specified one displayed in the HEX tab, matching the required criteria (e. g., directories or files of specific type) and add a shift point. The mode is described in detail in the Auxiliary modes section.

5) GREP search mode. This mode can be used similarly to the Search shift points mode; however, after its restart you will have to clear the table of results as new shift points could have been added but not included into the results table obtained during previous search.

6) Verification mode. This method can be used when you are working with the source, not its data copy. Information collected during verification may prove useful as revealed defective sectors and sectors causing slow-down are very likely to correspond to shift points. E.g., if you see that a shift occurring within a certain range of sectors

Shifts table present in most auxiliary Explorer modes (e.g., Object map). Shifts characterized by different reliability are shown in various colours.

Right-click menu of the shifts table.

Shift point addition

Button switching into the shifts search mode

Shift entry field

For the current object Explorer highlights in the shifts table the line used to calculate the shift of the initial sector (object beginning)



matches the number of sectors that have failed verification, then probably the sectors detected during verification correspond to the sought shift points.

7) Methods for automatic translator rebuilding accessible from the right-click menu of the boot sector in FAT partitions and MBR (EPR) of NTFS partitions.

4.7.4.1 Shifts table.

The program creates a table of shifts and uses it while running in the Explorer mode (while opening nodes, copying, object map generation, etc.) when you are trying to create a virtual translator.

The table has a right-click menu, which consists of the following items: − Add shift point (Ctrl+Ins) − Delete (Ctrl+Del) − Refresh − Compress Table − Legend − Calc LBA − Clear (applies to a range of sectors similarly to the Compress Table method) − Save to file (program outputs shifts table to a text file).

Add shift point. Unlike the identically named button in the binary editor tab ( ), this method is intended for manual entry of a shift point.

Figure 83. Adding a shift point using the right-click menu of the shifts table

Objects tree in Explorer is not updated automatically when a shift point is added or deleted manually (i.e. using the right-click menu of the shifts table) or the shifts table is cleared.

Compress Table. When the Explorer needs to read a specific sector and the shifts table contains some records, the program finds the nearest record with a smaller or equal LBA and uses that shift while reading. Thus, at an attempt to read, for example, LBA = 1000 (provided that the shifts table contains a nearest record of shift in position 999 by +5 sectors) the program will actually read sector 1005.

If more than 2 records follow in the table successively without gaps (with increasing LBA) with an identical shift, you can leave just the first and the last records; that will not influence the result of Explorer operations.

Please keep in mind, however, that the larger is the number of records in the table, the smaller will be the influence of a record added in error (with an invalid shift), so compression of shifts table is recommended only in cases, when searching and addition of shifts are finished.

The Compress Table (and Clear) method works with a range of sectors specified in a dialog displayed after its selection (please see the figure below). There is just one table of shifts for a whole drive, so you may frequently have to compress (or clear) a part of the table pertaining to a specific range of sectors leaving the rest. E.g., if a shifts table has been built for the first partition of a drive and you need to compress the table in the process of work, use the dialog to specify the second partition to leave unchanged the table part pertaining to the first partition.

Figure 84. Dialog for compression range entry




Legend. When points are added to the shifts table, the notion of their reliability is also introduced.

Reliable shifts are those obtained using automatic methods for objects that contain an indication of their location or those whose position is known from other reliable sources (e.g., positions of boot sectors are known from MBR slots, folders of FAT partition contain an explicitly indicated cluster number). When a shift point is being added the program looks for the closest points in the table (with smaller and larger LBA respectively). The following variants are possible:

1) Such points have not been found or found points have a different shift, so the reliability degree of the point being added will remain unchanged.

2) A reliable point is being added while one of the found points has the same shift being less reliable; then its reliability degree will be changed to reliable.

3) A low reliability point is being added while one of the found points has the same shift being reliable; consequently, the reliability degree of the point being added will be changed to reliable.

4) A low reliability point is being added and one of the found points has no reliability degree but it has the same shift; then the reliabilities of both points will be summed up (so the reliability degree of both points will change).

Figure 85. Window containing information about reliability of a shift point

Calc LBA. The principle used in Explorer for shift point calculation for a specific sector based on the shifts table is described above for the Compress Table method. Sometimes users have to see (calculate) the shift of some intermediate sector. This method is used to do without looking through the whole shifts table searching for the nearest point with a smaller or equal LBA. You only have to enter the required sector number in the LBA field and click Ok to receive the search results.

Figure 86. LBA entry window

Figure 87. Calculation result window

4.7.4.2 Using an object map during translator rebuilding.

During translator rebuilding, maps of various Explorer objects can be rather helpful while searching for shift points. These objects (and, consequently, maps) include: MBR (EPR), partition (boot sector), MFT (for NTFS partitions), files and folders.

Partition map (EPR map). MBR zero sector is usually located in its standard position. Therefore, when MBR slots are not defective you can switch to the Map mode to see in the table of chains the chains of drive partitions. Double-clicking the first partition with the mouse opens in the binary editor tab the initial partition sector (boot sector). If the sector displayed in HEX window is not a boot sector of the partition, use the shift control buttons to find it and add the corresponding shift point (the shift point must be added even if the boot sector is in place). Proceed in the same manner to set the shift points for the boot sectors of other partitions (if they exist). If a boot sector cannot be discovered

quickly (using the HEX tab and shift control buttons), then you should use the shifts search mode ( ).



Figure 88. MBR map

With NTFS partitions you can use an MBR map to detect and set a shift point for a boot sector copy as it must be located in the end of a partition (scroll to the end of a partition or, if it is not the last partition, then scroll to the next partition and move one sector to the left).

As soon as the shift points for boot sectors of partitions are set, use the Explorer to move to the first sector and launch the Partition map mode. A map of an NTFS partition can be used to identify the initial shift points for MFT, MFT mirror and boot sector copy.

Starting points for the first and the second partitions are added into the shifts table (0 and 1000 respectively).




Figure 89. NTFS partition map

Similarly to the MBR map, if you cannot find the beginning of some object, you can use the Search shift points mode. E.g., the figure below demonstrates a window in the Search shift points mode used to determine the MFT Mirror position.

Figure 90. Shift point search mode

With FAT partitions, you can use a partition map to identify the initial shift points for FAT copies, boot sector copy and the root directory.

When moving along a sector chain, the shift value used to calculate the position of the first chain sector is marked in the shifts table

NTFS MFT Record is selected as a search criterion.

Four MFT records have been found (the sought MFT Mirror);now we use the right-click menu of the results table to add the corresponding shift point.



Figure 91. FAT partition map

In some cases you can slightly change the described procedure: use the MBR map to identify the shift size for the boot sector of the first partition, then switch to the Partition map and set the shift points for the most important metadata of the partition (or initiate automatic searching for shifts). Then return to MBR map and continue making the table of shifts for the second partition and so on. It will make sense in cases when partitions are sufficiently large and detection of shift points for a previous partition allows you to estimate the approximate shift size that has to be used to find the boot sector of the next partition.

Theoretically, an MFT map (for NTFS partitions) can be used to identify the shift points for the beginning of MFT chains. However, manual searching for shift points within these chains is a rather tedious task and it is far easier to use automatic search for shifts with NTFS partitions.

Object map can be used to detect the points where sector chains of an object are shifted. E.g., a file cannot open after its copying to a spare drive. You can invoke the Map mode for that object to try to check and correct the beginning chain parts, if necessary. That may be possible for certain file types (zip, doc, dbf, etc.), which use recognizable data structures. Thus, having reviewed the data structure of the first chain, you should proceed to the second one. If the structure is similar, then the chain beginning has been identified correctly. You can move one sector to the right and to the left to verify the assumption. E.g., the figure below demonstrates a table of chains for a Microsoft Word document.




Figure 92. Map of object chains

Moving one sector to the right (please see the figure below) shows that the structure of data has not changed.

Figure 93. Binary editor tab after chain shift to the right by 1 sector

Moving one sector to the left (please see the figure below) shows that the structure of data has changed. It means that the shift point has been identified correctly for the chain (of course, this is an ideal case when a sector is filled with zeroes but usually data structures are visually distinguishable). You can check the beginning of other chains in the same manner.

Figure 94. Binary editor tab after chain shift to the left by 1 sector

If you need to correct shift points for data that have no typical structure, you can try picking successively possible shifts within a range determined by neighbouring points in the table of shifts (when you navigate the list of files, the pointer in the shifts table moves to the record whose shift is being used).

When moving along a sector chain, the shift value used to calculate the position of the first chain sector is marked in the shifts table.



4.7.4.3 Methods for automatic searching and addition of shifts for FAT partitions.

These methods can be invoked from the right-click menu of the boot sector object within a FAT partition. They should be launched in the numbering order and as the situation may require.

4.7.4.4 Seek shift points for FAT copies.

The method should be used only in case, when shifts are present in the area of both FAT tables. You can judge about that using the partition map to check the starting positions of the first and the second FAT copies and the root directory (clustering beginning). If at least one copy does not contain shifts inside, it would be reasonable to start using it without looking for shifts in the other one. Please keep in mind, that you should identify the proper location of the root directory, too.

E.g., if you have used the partition map and shifts search mode to identify the points of shifts for FAT copies and root directory, then the following variants are possible:

− The size of shifts for FAT copies and root directory are the same; it is the best variant and you can proceed looking for the points of shifts for subdirectories.

− The first FAT copy has shift А1, the second FAT copy and root directory have shift А2, it means that FAT2 contains no internal shifts unlike FAT1. In that case you do not have to search for shifts within the first FAT copy, it will be sufficient to switch to the second FAT copy using the right-click menu of the boot sector object (FAT copies… → 2 copy).

− The first and the second FAT copies have shift А1 while the root directory has shift А2. It means that FAT1 contains no internal shifts. Therefore, you will have to switch to the first FAT copy using the right-click menu of the boot sector object (FAT copies… → 1 copy).

− FAT1, FAT2 and root directory have different shifts, i.e. both FAT copies have internal shifts and you will have to use the Seek shift points for FAT copies method.

Application of the mode results in discovery of shift points within the area of FAT tables and their addition to the table. After mode completion the user will have to verify the root directory location.

The root directory location can be verified as follows. First, the sector must contain directory elements (View the first sector → View as… → FAT folder). Second, the directory must contain no links to a parent directory. Third, moving one sector to the left usually displays a sector containing zeroes (it is the end of FAT, which in most cases is empty).

Figure 95. Binary editor window containing the first sector of the root directory of a FAT32 partition

Figure 96. Binary editor window containing the first sector of an arbitrary directory on a FAT32 partition

4.7.4.5 Searching for shift points in FAT subdirectories.

The mode is based on a very useful property of FAT directory – it contains the information about its position (cluster number), which allows users to identify its shift relatively to the expected position.

The mode can only be used provided that the root directory (taking into account the shifts added earlier) is in place; the program displays a reminder window informing about that.

Figure 97. Informational window

Link to itself and a parent directory




Search parameters are determined by a specific situation (please see the figure below).

Figure 98. Parameter entry window for shift search in FAT directory

The Search direction panel offers the following search variants:

− Search Forward (the program will search forward only, i.e. using shift increment from zero to the value specified by the Search depth parameter).

− Search mainly forward (the program will search forward; if it fails to find a shift, then it will search backwards).

− Search forward and back (the program will search in jumps, i.e. absolute shift value will grow from zero to the value defined by the Search depth parameter, but the program will check two points (with positive and negative shift)).

− Search in whole partition. The above variants of directory search work recursively, i.e. they unfold the root directory and proceed deeper. If one of the directories in a chain of folders is corrupted, the program will be unable to find shifts for child folders. If a root directory is corrupted, search based on these methods will return no results altogether. Search within a whole partition means sector-by-sector scanning of the whole data area; therefore, it takes considerably more time but it also allows you to reveal shifts for all directories of a partition (when this search method is employed, it should also be used for file search). As soon as the Search in whole partition procedure is finished for directories and files on a drive with a corrupted root directory, you have to use the Partition analysis mode.

Search direction is determined by the type of shifts (erased translator means searching forward, “HOT-SWAP”- mostly forward or forward and backward depending upon the "donor" drive).

Please note one more peculiarity typical of shift search for directories. Searching returns the best results when user folders are more or less evenly distributed within a partition's data area. As a result, you will obtain reliable shift points for the whole data area. If for some reason all folders of а partition are concentrated in one location, further analysis (shift search for files) may not return necessary results, so that you may have to look for shift points working with individual files in the Explorer mode.

Search depth is determined by the size of shifts. Increasing the depth does not cause errors while searching for folder shifts, it can only increase the search duration. If the search process has not revealed any directory, the program will log an error message. You can try increasing the search depth or Search in whole partition at once.

The search results in addition of new records to the shifts table.

The method can be used several times successively because a previous pass may correct the conditions for the following one so that the latter reveals new points. In the end of the procedure the program logs the information about the number of added shifts.

If no records have been added after the last search, then the procedure should be stopped.

4.7.4.6 Seek shift points for files.

We recommend using the method only after shift search within directories because file headers are searched by signatures and contain no information about their position.

Hence follows the requirement to specify not too large search depth. Otherwise, if several files of the same type are located closely to each other, there may be errors during attempts to identify their true position and addition of invalid records to the shifts table.

The method can also be used several times successively.



4.7.4.7 Virtual translator creation for an NTFS partition.

This method of automatic shift search and addition for NTFS partitions is available from the right-click menu of the MBR slot object. When this mode is initiated, the program displays its Select range window, where the initial and final LBA are specified (substituted automatically from MBR slot) and maximum shift sizes. Maximum shift is used while searching for partition metadata and it has to be sufficiently large (boot sector copy is located in the end of a partition and if the latter is rather large, the shift in its end can be large, too). Maximum file shift defines the maximum search depth for files and, indirectly, the number of passes; in most cases you can use the default value.

Figure 99. Parameter entry window for shift search on an NTFS partition

During the procedure, the program performs the following actions: − Searches for boot sector and identifies its shift. − Searches for boot sector copy and identifies its shift. − Searches for partition metadata (MFT and MFT Mirror), then builds MFT map and identifies shift points

for table records. − Uses the revealed metadata to search in several stages for file shifts (changing the search parameters and

using smaller depth of possible shifts).

As a result, a virtual partition will appear in the Explorer reflecting the data structure retrieved using the shifts table (shift points for some files may have to be corrected manually). If the procedure has been completed, you are advised to copy data using the virtual partition as source.

Figure 100. Explorer window with an added virtual partition produced as a result of

translator rebuilding

Virtual partition resulting from translator rebuilding for an NTFS partition.




If after procedure completion the required data remain inaccessible but shifts for MFT have been identified correctly (you can check that using the MFT map for the original partition), you should clear the table of results for the original partition, run MFT scanning, then seek and compensate shifts of files and non-resident directories in the resulting virtual partition.

Figure 101. Explorer window with an added virtual partition produced as a result of MFT scanning

For a virtual partition produced as a result of the Create virtual translator for NTFS partition mode the

following methods are available from the Explorer right-click menu: − Scan − View the first sector − Delete virtual Boot − MFT_Record properties − List of non-resident files.

4.7.4.8 List of non-resident files.

As the mode's title implies, it builds a table of all non-resident files of an NTFS partition.

You can pick the necessary files from the general list using the Find button (the search criterion does not recognize the "*" character, i.e. to select all files with the "doc" extension, you should enter ".doc" as the search criterion).

The mode is used to check and correct manually the found shift points for non-resident objects.

The easiest checks are those of objects with typical data structure. E.g., the figure below demonstrates a window containing files with the jpg extension selected from a general list (these files have a typical header, which can be easily identified). Navigating such a sorted list, it is easy to find discrepancies in data structure and correct the shift (if the list is not sorted, visual checks are considerably more difficult because data structures may change drastically when moving between different data types). You can estimate the range within which a shift may be changed using the shifts table, namely, points neighbouring relatively to the current one (when navigating a file list, the pointer in the shifts table will be positioned over the record whose shift is being used). E.g., in the figure below the program uses shift 2305 for the file selected in the list; if the header were not correct, you could try changing the shift size within the 2302-2320 range (neighbouring points in the shifts table).

If you need to correct shift points for data that have no typical structure, you have to try in sequence shift sizes within the range defined by the neighbouring points in the shift table (the most favourable situation is when the shift of neighbouring points is ±1).



Figure 102. List of non-resident files

The Find shifts method accessible from the right-click menu of the list of non-resident files is intended as a tool necessary to repeat search for file shift points within a specified range of sectors. A situation may arise, when the automatic search mode takes an incorrect decision regarding some shift point thus causing invalid calculations for all subsequent points. If you correct shift value for that point manually, then you can employ the method to recalculate shift values for other points.

Figure 103. Parameter entry window for shift search for non-resident files

4.7.4.9 Limitations of the method.

1) If MBR (EPR) slot of the partition being restored has been created artificially (manually), then correct operation of the automatic shift search method requires that the slot must contain correctly specified values of the initial and final LBA (the final LBA value frequently can be specified approximately or equal to the final LBA of a drive). Therefore, if you are unsure whether these values are correct, you should find the boot sector of the respective partition and take the values from it.

2) The examined automatic method for restoration of translator for an NTFS partition may fail in cases, when a partition being restored contains portions of metadata of earlier NTFS partitions (MFT and INDEX tables).

Such situation can be indicated by "duplicate" objects (files and folders) that appear in the Explorer after automatic virtual translator creation. These may be system files, such as $MFT, or folders, for example, Program Files or Windows. In that case the method for automatic virtual translator creation cannot be used, and you should proceed in a different manner:




− Use the МBR slot map to place properly (i.e. identify the shift value and enter it into the shifts table) the boot sector of the partition.

− Use the map of the NTFS partition to place properly the first 4 records of MFT and MFT Mirror and the boot sector copy located in the end of the partition.

− Open the MFT map and place properly its chains. You may have to look for shifts inside the chains. When working with the source drive, you can use the verification mode.

− Clear the results table and scan MFT. − Manually deal with folders, files and their chains. When working with the source drive, you can use the

verification mode.

4.7.5 The "Mount task as a drive" mode.. This mode allows connecting the current task (we mean drives connected to АТА0 and АТА1 ports of the PC-

3000 board and operations with an image file) to the list of standard Windows disk drive devices; all settings of the selected task will apply in that case. E.g., when working with a malfunctioning drive in the copy creation mode the standard procedure will be used, i.e. if the OS needs to read certain sectors, the program will check the sectors accessed earlier taking them from a copy if they have already been read or reading them from the surface with all appropriate error processing (all task settings except for jumps are active).

This mode can be utilized for the following purposes: − To restore information using other software. It may prove necessary in case if the file system being restored

is not supported by Data Extractor. In another situation third-party software solutions may be used as a tool of the customer choice and PC-3000 can act then as means of problem prevention.

− Standard use of a normal drive. Here we mean, first of all, a number of basic actions such as formatting and data writing/reading (if that is possible) without the need to reconnect a drive to one of the standard ports of the user's computer.

− Better understanding of the processes used in different software to work with HDD. E.g., if you connect a drive in the copy creation mode and allow recording to it, then you can switch to the Map mode to monitor the data read by a specific software tool (it may be standard Windows Explorer) and the data that it writes (modifies).

When mounting a task, the user is offered to select the connection mode: Read only, Simulate writing or Permit writing. If the user selects the Permit writing mode, the program displays a window for confirmation of this option (please see the figure below).

Figure 104. Parameter specification dialog for a task being mounted

Figure 105. Dialog for confirmation of allowed writing for a task being mounted

The process of task mounting may take several minutes.

Read only. As the mode's title implies, the task mounted in the OS is used to read only, no recording to a task is performed. This mode is employed, when you do not want the OS to write to a drive or when a drive has recording problems. When working with drives demonstrating data reading problems, you should use the Make data copy mode. Then the program will take care of all problems occurring in operation of a malfunctioning drive, i.e. it will power it off when necessary, apply certain runtime scenarios, and read data using different commands. In case of insignificant logical corruption sometimes it is sufficient to create a task in the copy creation mode, mount it as a standard disk device and the OS will allow access to the required data. When logical corruption is considerable, you can use third-party data recovery software if it has any advantages over Data Extractor (the latter in that case will take care of the problems arising from work with a malfunctioning HDD).

When you are rebuilding a translator, you can identify the shift points, connect a task and use standard means to read the necessary data. Please keep in mind that you will have to remount the task when you add shift points because OS caches read sectors, and so it will be unable to notice the changes, which you have made.



Unlike removable media for which read only mode exists, such mode is not provided for hard disk drives. Therefore, it is implemented as follows: an OS attempt to write any data results in a reply generated by Data Extractor and corresponding to write error. Such approach sometimes may cause a system Delayed write error when a drive is connected in Windows XP (its partitions will be inaccessible in the Explorer mode to the OS).

Figure 106. Drive access error in the "read only" mode in Windows XP

Simulate writing. This mode has been designed for elimination of errors that occur during connection of a disk drive in the reading mode in Windows XP. Data Extractor simulates writing for the OS but no actual recording occurs. There is a slight probability that the OS may attempt to verify the written data and consequently fail to find it. Therefore, in cases, when for some reason you need to allow recording of system data without losing the original information, use the Make data copy mode and Permit writing with a drive. Then the system (or other third-party software products) will overwrite the data in copy and the original data can be read again, if necessary.

Permit writing. Users should realize that data loss can occur when writing to a drive is allowed. This mode is dangerous in case, when a drive has writing problems.

This mode is only safe in case when a task is created in copy mode, then recording will be performed to a copy instead of the original drive (i.e. there still will be an opportunity to read again the modified data from the source).

If writing is allowed, but no data copy is created, then recording will be performed directly to the drive (this approach is only recommended with functional drives). In that case work with a drive will be completely identical to a situation when a drive is connected to a standard port (available operations include formatting, reading and writing).

4.8 Auxiliary modes.

4.8.1 The "Object map" mode. When speaking about object map you should keep in mind that each object of a drive's logical structure is

located on disk and has a certain placement map, i.e. a sequence of sectors.

The mode is intended for visual operations with the map. It simplifies understanding of actual object placement on disk, its fragmentation and the results of copying whenever making a data copy from a damaged drive (sectors, which could not be read, sectors copied with errors, etc.).




Window appearance in the Object map mode is shown in the figure below.

Figure 107. Window appearance in the object map mode

The upper window part contains informational lines reflecting the current status and toolbar buttons, which allow map navigation. The purposes of toolbar buttons are described below.

Figure 108. Program toolbar in the Object map mode

− Load map from file / Save map to file (please keep in mind that these methods work with a whole object, i.e. if you switch into the map mode for a partition, then the whole partition will be loaded/saved).

− Control over the positioning process (First, Previous, Next, Last).

− Go to sector window for the number of the sector that the program will jump to and Edit.

− Make copy of object data.

− GREP search

− Raw recovery

− Fill with pattern

− Clear Map

− Calc map statistics

− Create submap

− Task params

Toolbar

Status bar

Graphical object map panel

Table listing object chains (chain number, initial and final LBA, length and description)

Right-click menu of the selected chains (objects)

Shifts table (virtual translator creation mode)



− Exit the task.

Make copy of object data. The method is only available in data copy creation mode; it makes a complete copy of the object loaded into map (taking into account the sorting order in the table of chains).

Fill with pattern. The method is designed to fill the sectors of a built map having certain characteristics with data defined in a pattern.

The method can be helpful first of all in cases, when you suppose that after copy creation the user data will be parsed or analyzed outside DE in some other software product. In DE, whenever a method need to analyze a sector read with any error, the program generates it as a sector filled with zeroes. On the other hand, if you analyze the resulting image in another program that has no information of the reading results map, then the sectors read with errors should preferably be filled with zeroes. Alternatively, they can be marked in a certain manner, for example, with not read indication in the sector beginning (or in any other way) and that is accomplished in binary editor by pressing the Pattern button in the filling parameters. Having thus marked unread or defective sectors and saved, for instance, the data of a certain directory, you can use then standard text search in Windows Explorer to select files containing invalid data.

The Change map option makes sense for operations in DE only. E.g., you can fill unread sectors with zeroes and mark them as modified using the option to Change map. As a result, in case of subsequent attempts to access those sectors, the program will take them from copy instead of artificial generation.

Figure 109. Pattern parameters

Clear Map. The method clears the built map (i.e. it changes the specified properties of the sectors to Sector was not read).

E.g., if you have a map of an object and it contains modified sectors (a copy is created at that), you can clear the sign indicating that the sectors have been modified and read them again.

Figure 110. Properties for map clearing




Calc map statistics. This method calculates statistics for all the sectors of a built map according to the legend.

Figure 111. Statistics for object map

E.g., you can build an MFT and calculate its statistics to estimate how damaged it is.

Create submap. The current map can be used as the basis for submap, which will contain just the sectors with specified properties. E.g., if you have a map of a directory with partially read data, you can use the method to build a submap containing unread sectors only with information about their association with individual files.

Raw recovery and GREP search. These modes are available for all objects loaded to map. They allow working both with contiguous objects (e.g., partition) and with sector chains (map of unused space). During raw recovery using the map the program corrects the sizes of found objects according to the scanned area. Please see the Raw recovery and GREP search sections for details.

Speaking about navigation we should mention two aspects: an object has relative and absolute (actual position on disk) coordinates. Though relative coordinates are continuous and linear (e. g., from sector 0 to 999 with total length of 1000 sectors), absolute (LBA) coordinates directly depend upon disk fragmentation and may have any values. Whenever navigation is mentioned, relative navigation is meant.

The middle window part displays the object map. Hovering with the mouse over a sector square brings up a hint with its relative and absolute coordinates. To distinguish between individual sector chains, crossed symbols placed contiguously or with interleave are used.

Figure 112. Displayed chains and read sectors

The current sector status is shown on the map using color. The legend can be reviewed by clicking the Legend button on the Map tab. When you do not create a data copy, all sectors on the map will be displayed as read. However, the program might not have read them (it is assumed that if the data copy is not created, then the drive being tested has no reading problems and any sector can be read when necessary).

Below the map you can see the table listing chains. By default, the table is sorted by the chain number (as shown by the "Δ" sign in its header and the color of the respective column), but the user can change the column used for sorting and the order (ascending "Δ" or descending"∇") by clicking the corresponding table header with the mouse.

The sorting method, apart from the convenience of data viewing, affects the order of scanning (and saving).

All values in the table (except for the N column) are editable (after clicking the necessary value with the mouse).

Note! If you are changing the chain values in the table, the program does not validate the entered data (i.e. the chains may intersect).

0 1 (5) 2 3 (27) 4 Sector chains, chain length in sectors is indicated in brackets.

Successfully read sectors Sector read with an error



Figure 113. Table of chains

While viewing a map of object with chains having some meaningful value, the About field shows a respective record (e.g., Boot, FAT1, FAT2, Data, etc.). When working with chains without meaningful values (e.g., file chains), then you can edit the About field to create arbitrary order and then scan or save the chains in the defined order.

The right-click menu of the chains table allows you to add or remove chains thus enabling you to create and use a manually created object map (Add chain and Delete selected chains commands). This feature can be used when you "assemble" a file manually (looking for the chain start and, perhaps, the end in the search system).

You can work individually with each chain (you can move to chain beginning by double-clicking it, save it to disk as a file or load from file). These operations are available from the right-click menu of the list. In addition to individual manipulations with chains, you can select sets of chains and work with them (several chains can be selected by clicking them with the mouse with the Ctrl button depressed).

You can clear the selected sector chains (i.e. fill them with zeroes) and the map (i.e. in case of copy creation the program will set for the selected chains an attribute telling that they have not been read).

If you select a right-click menu command, which may result in data loss, the program displays a warning message. E.g., the figure below demonstrates a message that appears at an attempt to clear the selected chains.

Figure 114. Message at an attempt to clear the selected chains

The right part of the table listing chains contains "hot buttons" for work with the list. These buttons allow the following operations:

− Clear map. The command will clear entirely the list of chains, their locations will disappear, too. − Save map to file. The method saves to file information about the list of chains for the built map. You can

use the method, for example, when you are building a map of a large object and it takes quite a lot of time. Then you can build the map once, save it to file and then instead of rebuilding it each time load it from the file which is considerably faster.

− Load map from file. − Add chain. The method allows you to create manually any map by adding the required sector chains

(possibly, taking into account the required order of their reading).

Figure 115. "Hot buttons" for operations with the list

Object map is very convenient for selective copying of essential data. First of all, this applies to the partition boot sector Explorer object as its structure is unfolded in the map mode. E.g., for FAT partitions you can use the mode

Table sorted by the "N" column in the ascending order

This field is in the editing mode

Table sorted by the "About" column in the ascending order. In this case, the field is filled in manually.




to scan FAT copies, for NTFS partitions – MFT (its first 4 records). With FAT partitions, a FAT copy saved to a file can be connected for work with a selected partition (please see the Explorer mode description for details).

The lower window part contains a panel with log and sector view tabs. If the sector view tab is active it displays the contents of the sector selected in the map.

If you are creating a virtual translator, the partition map used together with the HEX tab allows you to put in place data chains important for further data recovery (MFT beginning, etc.).

4.8.2 Verification. The mode allows users to verify a range of sectors and find those, which cause an error or considerable

slowdown during verification.

Verification may be helpful during data recovery from a HDD with a corrupted translator (provided that you are working with the original drive, not a copy) as the errors and slowdown locations found during verification are very likely to correspond to the sought shift points. In addition, the mode allows you to estimate quickly the surface condition of the HDD being tested to make a decision regarding the manner of further manipulations.

To perform verification, you should enter the Verification mode and initiate the process using the Execute button. Use the Parameters window that appears next to specify the values for the sector range to be verified, verification method (verification only or + reading and writing), reading and writing parameters (if the Verification, Read, Write mode is selected) and click the OK button.

If Verification, Read, Write has been selected, then, in addition to surface verification, the program will perform for defective sectors reading (with the selected read command and the number of attempts equal to or less than the specified) and writing of read data. The reading process is as follows: the program reads a defective sector; if reading is successful then the process will be terminated, if it fails, then another reading attempt will be made (but not more than the specified number of attempts). The program writes to drive either data read from it (which might be not quite reliable when the command to read ignoring CRC is used) or zeroes if all read attempts fail. Drives of certain manufacturers, for example, IBM perform hardware substitution (remap) of defective sectors when a drive attempts to write to these sectors. When the number of revealed defects on a HDD is small and the drive supports remap, this feature allows you in some cases to get rid of found defective sectors and continue working with a drive connected to a standard port, which is considerably easier.

Figure 116. The "Parameters" window of the "Verification" mode

The progress indicator of the procedure will be displayed in the Operation panel. Verification results will be added to the Results table in the middle part of the window workspace. Window appearance in that mode is shown in the figure below.



Figure 117. Window appearance in the "Verification" mode

Resulting information may prove helpful because sectors found using the method with high probability correspond to shift points.

E. g., if you see that a shift occurring in a certain sector range corresponds to the number of sectors that have failed verification in the range then those sectors match the shift points with a very high probability degree.

Unfortunately complete correlation is impossible because not all the criteria used by manufacturers while making up a list of defective sectors accounted for in the translator are publicly disclosed and most likely they are stricter than plain verification.

From the viewpoint of reliability the sectors producing errors during verification are certainly more reliable. A slowdown during verification may only be a hint.

Verification results are stored with task data and can be used at any moment.

4.8.3 GREP search This is the main search mode in the program. It allows multiple searching for sectors containing data that

comply with the conditions of regular expressions selected as search criteria (from a corresponding reference).

Mode toolbar

Current LBA

Process status

Table of results (LBA and the category of each verification error)

Right-click menu of the selected sector with a verification error

Progress indicator (empty here as the process is completed)




Window appearance in that mode is shown in the figure below.

Figure 118. Window appearance in the "GREP search" mode

Window toolbar in that mode is simple and consists of five buttons only: Execute, Pause, Abort, Sector editor и Exit.

To perform a search procedure, you should specify the search range (not always), search step (if you are looking for data aligned with clusters the step should be equal to cluster, that will speed up the process), select search criteria from the reference book and define their use in the future search. Search range is skipped in cases, when it is started for some Explorer map (in that case it will be determined by the current map object). The search step size should (ideally) match the cluster size, so if it is known, it should be specified to decrease the number of search errors and overall procedure duration. If you do not know the cluster size, the only remaining variant is the step equal to1.

To select the criteria, use the Add item from the right-click menu of criteria list. That will bring up a window with a list of regular expressions, where you can quickly define the list of criteria using its Select (Alt+Enter) command.

Mode toolbar

Current LBA

Parameters (initial and final LBA and the range) Table of search criteria

Right-click menu of a found object from the table of results

Table of search results (first sector and title)



Figure 119. Window of the "Grep expressions" reference

You can indicate whether the selected criterion should be used or not used in the forthcoming search from the right-click menu or by double-clicking its respective record. Of course, you can always search using all selected criteria but for time saving purposes it would be more expedient to leave active just the necessary ones. The greater is the number of active criteria and the more complicated they are the slower the search process will be (especially for complicated criteria containing no direct pointers to the position of required data).

You can use the right-click menu of the results list to enable list grouping according to record types (criteria). You can also proceed to sector viewing (editing).

4.8.4 Shift search. The operation can be started by the button on HEX tab of the log visible if you have enabled the Create virtual

translator option.

The HEX tab displays the first supposed sector of the object selected in Explorer (EPR, boot sector, file or directory).

You should run this procedure if the shift is too large (more than 20 sectors) and you cannot identify it clicking the shift search buttons (within the same tab).

The mode is based on search for regular expressions and its appearance resembles very much common GREP search, but searching for suitable data starts from the supposed sector in the user-defined direction and is performed with a specified depth (please see the figure below).




Figure 120. Shift search mode

When the search is over, you can select the most suitable sector out of all detected ones (looking, for example, for minimum shift or shift direction, for a directory – contents) and use the right-click menu of the results list to add the record to the shifts table.

4.8.5 Raw recovery. The Raw recovery mode occupies the last place in the group of data recovery tools provided in the suite in

terms of use frequency. The main purpose of this method is restoration of files with recognized headers, when there is no information about their location based on the assumption of their continuity.

In other words, if the program has detected two file headers belonging to a known type, then we may suppose (if we have no precise location data – FAT, MFT record, etc.), that the file has a type determined by the first header and the size calculated as the difference between the LBA of the first and the second header.

The assumption is not always correct since an identification error is possible, files may be fragmented, etc. Besides, in that case we lose the information about its name, creation date, position (directory).

However, when there is no other way, it is better to restore something than nothing at all. Please note that restoration results depend seriously on a specific situation: whether the header reference contains necessary records, how fragmented is the drive, how large are the required files. In various cases the percentage of successfully recovered files may vary from 0% to 70%.

The method should be applied in cases, when logical structure damage is really vast or when you deal with a file system for which you have no logical recovery tools.

Program window in that mode resembles the GREP search mode very much (please see the figure below).



Figure 121. Raw recovery mode

There are two basic differences: − Search criteria are not selected, their list is determined by the Raw recovery reference book (the criteria at

that can be modified, please see details further). − Searching produces a list of supposed files, which can be copied. Each file at that is named by the number

of its initial sector; file extension is determined by the criterion of type. If the program copies all files of a certain type (from the right-click menu of criteria list) it creates a subdirectory named after that extension.

Figure 122. Results of the "Raw recovery" mode

Raw recovery reference book. This reference contains all regular expressions, which can be used to identify user's files. It is accessible from the Options → Raw recovery reference book menu (please see the figure below).

Mode toolbar

Current LBA

Progress indicator

Parameters (initial and final LBA and the range)

Table of found standard headers (extension, type, number of files, GREP, ID)

Table of found files (initial LBA, type, size, ID). The size and ID columns are filled in after the procedure is completed.




Figure 123. Raw recovery reference

During raw recovery procedure the program uses for search of the supposed file beginning just the regular expressions marked in the Seek column. To extend the list of expressions used in search you will have to mark an existing expression from the reference or create the necessary expression and mark it by selecting in the Seek field.

When raw recovery is selected, the program offers to choose the method for calculation of the found data size. There are two possible variants. The first method uses for size calculation just the regular expressions enabled in the Seek column of the reference. The second method uses all regular expressions from the reference (but only during data size calculation). Specific size calculation method depends upon the data being sought. Thus, for ZIP archives the first method is preferable (if found archive size turns out to be greater than its actual size, some programs for data recovery from damaged archives (e.g., ZipFix) will allow data extraction from it. If a found archive is smaller than its real size, the chances of even partial data extraction from it will be very low.

Each line in the reference defines a search criterion for a specific file type determined by the GREP field. During raw recovery the program searches for those criteria. Data from the GREPEXT field are used to identify more precisely file type if several identical GREP exist for different file types. If GREP for several file types is identical and no GREPEXT for them exist, then the extension is selected using the Order field (by the lowest order).

Additional criteria defined by the GREPEXT field do not appear in the reference book. You can view the field containing additional criteria by entering the list item editing mode. E.g., the figure below demonstrates two windows for editing a list item with identical GREP but different GREPEXT.

Figure 124. Editing window for an item in the raw recovery list

Editing the reference is possible, it is a rather complex and serious task. However, when a data recovery task is created, the program makes a copy of the raw recovery reference, which it uses then in the current task. Consequently, reference can be restored, when necessary. On the other hand, if you wish to preserve the entered changes, then you should edit the main DE reference book instead of the current task reference.



Figure 125. Recovery reference and its copy in the current task

DE uses the main raw recovery reference book to initiate raw recovery from the main menu. Current task reference is used if raw recovery has been started from the quick access toolbar or any available Explorer method.

One more important peculiarity is that incorrect identification of file beginning in that mode may lead to data loss.

This can be illustrated by an example – if the program has discovered a lot of file headers of a certain type with a simple and indistinctive header signature, but your customer tells (or you are convinced), that there should be no files of that type on the inspected drive. It means that the results are invalid and they may cause incorrect size calculation for other important files, so they have to be deleted (the program will recalculate all sizes at that automatically).

Correct setting of the beginning of scanned area and scanning step help users minimize the number of errors and save a lot of time. Please note, that scanning should be started from a known clustering beginning; you should use step equal to cluster size. If you have no such information, then any reliable file header discovered after a search with step 1 will do as the first parameter. As the second parameter you can use the minimum default cluster size (e. g., 8 for FAT).

Actions that may be performed over items in the Categories and Files lists can be invoked using the respective right-click menus.

The mode can be launched from the Service → Raw recovery menu item or from corresponding object menu items in Explorer, but there is a difference: for Explorer objects of "partition table slot" type the program sets the search range (partition), while for “Boot” there is also a step setting (cluster size).

4.8.6 Partition analysis (for FAT file system). The procedure can be started from the right-click menu of a boot sector in FAT partition within Explorer.

It is intended to search for directories within a FAT partition, which are lost or for some reason inaccessible in the Explorer mode. Correct application of this method requires a valid boot sector of a partition (clustering beginning, cluster size) or a virtual boot sector.

In case of malfunctioning devices (with sectors causing reading errors) the mode can be used in combination with the Make data copy option.

The mode is completely automatic; however, user participation is required when scanning parameters and goals are defined.

In this case, the main raw recovery reference will be used.

When you initiate raw recovery from Explorer, the current task reference will be used (a copy of the main reference made during task creation).




Figure 126. Definition of partition scan parameters

Depending upon the selected analysis options, the volume of the data to be read will change. However, it will always be less than the total volume of a partition. E.g., if you have enabled the option to use just one FAT copy, then the program will read that copy only, sectors of the directories and initial sectors of the files addressed in the selected FAT copy.

FAT copies. The users are offered to choose one of FAT copies, use both copies or ignore them altogether. If one or both FAT copies have been selected for analysis, the program will generate two tables in the task database: a table of objects and a table of objects' chains. The first table contains objects addressed in FAT (i.e. folders and files) while the second one contains chains of sectors belonging to the corresponding objects (i.e. all information about the placement of each individual object). If you analyze one of FAT copies, the program reads that copy and uses it to fill in these tables. If you are using both copies for analysis, the program reads them and fills the tables with data found in both tables (i.e. it will add to the table objects that are identically addressed in both copies and objects that are addressed in a different manner in these copies).

Ignoring FAT copies during data recovery process implies that the analysis will be performed for the whole partition (it is used in cases when FAT copies contain garbage).

Data analysis in unaddressed areas. This parameter, together with the opportunity to use/ignore FAT copies, determines the data area to be analyzed. There are several combinations possible.

1) The application analyzes the data area addressed in FAT (here it is assumed that one or both FAT copies have been selected for analysis).

2) The application analyzes the whole partition area taking into account FAT copies.

3) The application analyzes the entire data area (The Data analysis in unaddressed areas option will be

enabled automatically if you select the Ignore FAT option) ignoring FAT copies.

Raw recovery. This option determines whether the program will use raw recovery during data analysis. Raw

recovery can be used both during analysis of data addressed in FAT for preliminary identification of data types and in its regular understanding, i.e. for recovery of contiguous data using the GREP reference.

Seek deleted objects. This parameter determines the need to search for deleted files when scanning using one or both FAT copies.

Location check for files. When this option is used, the program checks for intersection of a deleted files and objects addressed in FAT (information about the beginning of a deleted file will be taken from a directory slot and its



location is based on the assumption of its contiguity). If such intersection occurs (and control is on), then the size of the deleted file will be decreased in accordance with the location of the object whose position has been identified more reliably.

As we have already mentioned, the program generates two tables during analysis, i.e. a table of objects and a table of their chains. These tables include the property of object reliability. E.g., if the program analyzes both FAT copies then objects addressed in both copies will be most reliable while objects that are addressed in copies differently will have lower reliability. Speaking about file attributes (first of all, its extension), the information received as a result of raw recovery has low reliability, information obtained from a directory slot is more reliable. Thus, if there is information about file type based on the data from its parent directory, it will be more reliable compared to an extension assigned as a result of GREP search. However, if no parent directory has been found for a file, then an extension found as a result of raw recovery will be, although less reliable, but still the only available information. The reliability of directories addressed in FAT and "lost" ones (e.g., when you can see from a directory slot addressed in FAT certain information about a file while a slot of a "lost" directory provides information telling that it is a different file having other attributes; consequently the information from the directory addressed in FAT is more reliable and the data from the "lost" directory must be ignored).

Note! The described principle of decision taking applies to all objects of a partition being restored except for files with the ".chk" extension. These files are produced by the "Check Disk" program during its checks and repair of disk structure; they are usually located in directories of the "Folder.XXX" type (no other known software tools create files with such extensions). Reliability for files with this extension has been decreased deliberately (i.e. if the program finds during analysis information from any other directory that describes the same object, then it will be considered to be more reliable).

As an example, the figure below demonstrates an Explorer window with the "Folder.000" directory. The directory contains 139 objects (see the status line); if you initiate Partition analysis then most files from that folder will be relocated to other parent directories (maybe even deleted ones) with corresponding new attributes.

Figure 127. Using the "Partition analysis" mode

The choice of analysis parameters in a specific situation depends upon the original data, some advice can be found in the Peculiarities of mode use section further.

After definition of parameters the program starts the procedure, which seems to resemble the Logical scan and Scan MFT modes (a window containing log, map and the Stop and Exit buttons).




Figure 128. "Partition analysis" mode

When the information about parent directory for a folder is lost, then the program creates in the virtual partition model an artificial Lost&Found folder and adds to it the object in question and those objects, for which it acts as parent.

If information about a certain FAT object exists, i.e. one of FAT copies or both contain a related set of chains that refers to none of the found folders, then you can assume that the set of chains is a file (or a part thereof). Such objects are added to an artificial Lost FAT objects folder; if the program performs raw recovery during the procedure, such objects will be assigned extensions using the GREP reference. At creation the directories will be assigned names of the FolderXXX type (XXX is the number of the initial sector), and files will receive names of the FileXXX type.

The Partition analysis mode can be used several times with different options. All results will be saved to the objects tree in Explorer. They can be compared and you can use a specific item depending upon the situation. Thus, you can first start analysis using one FAT copy, then use the other copy, if necessary, then use them both, then ignore FAT, and so on depending upon the time that analysis can take and the returned results.

The analysis procedure must complete normally, i.e. if you interrupt it during some intermediate stage then even if it has successfully revealed all data, the program may misinterpret them and build the file system tree incorrectly.

After completion of processing (and the procedure), when the program finds enough data for interpretation into a variant of virtual file system, the corresponding objects will appear in the Explorer mode.

Figure 129. Explorer window with the results of partition analysis

Virtual FAT partition created as a result of analysis (the original partition returned errors during reading of FAT copies and the root directory has been deleted as demonstrated by the names of folders in the root directory of the virtual partition)

Current FAT partition created by Explorer tools (the figure shows that the root directory is empty)

Artificial "$Lost FAT objects" directory



4.8.6.1 Peculiarities of mode use.

Depending upon the source data, you should select different parameters when starting the procedure to recover information. The main difference is between two initial tasks:

− Restoration of data addressed in FAT. − Restoration of data unaddressed in FAT.

1) Restoration of data addressed in FAT. It means that one or two correct FAT copies are preserved within the partition being restored; they may be partially corrupted but still they describe the partition in question (i.e. the copies address the data being recovered). A situation is possible, when both copies are intact and the program restores deleted files or files and folders for which parent directories are lost (and so the objects are not visible in Explorer). This case does not apply to a situation when a partition has been reformatted because in that case, although FAT copies exist, they address completely different data (data of the new partition).

In most cases the choice of the Analyze all FAT copies can be viewed as the most universal one. Then the program reads both FAT copies and builds two tables: a table of objects and their chains as intersection of those copies (i.e. it includes objects addressed similarly in both tables and objects addressed differently). The mode for work with a specific FAT copy can be used when one of the copies is heavily corrupted or destroyed completely (e.g., by a virus). Since analysis mode can be started several times with different parameters, you can start it first using one FAT copy, then the other one, then both of them and compare the returned results.

It is recommended to enable the Raw recovery option as in that case the program will perform preliminary identification of data type while building a table of object chains. If the program fails to discover a parent directory for data, they will be placed into the artificial Lost FAT objects directory with the extension obtained during raw recovery. If no raw recovery has been performed, the data type for such objects will not be defined.

During recovery of deleted data you will have to use the Seek deleted objects and Location check for files options.

2) Restoration of data unaddressed in FAT. In most cases, the situation occurs after reformatting of a partition (maybe, several ones). As a result of formatting, new FAT copies appear addressing the data of a new created partition. The data being recovered at that will be located in areas unaddressed by the new FAT copies. Despite the fact that FAT copies address unnecessary data, you can use them in combination with the Data analysis in unaddressed areas option based on the assumption that the data to be restored cannot intersect with the new data. Ignoring FAT copies makes sense only when they are filled with garbage.

Using the raw recovery is mandatory because when FAT information is missing, it is the only method capable of restoring the location map for contiguous user data based on GREP reference and the map of unused space. The type of data obtained as a result of raw recovery can be made more precise using the information from "lost" directories that remained from the partition being recovered (other file attributes can be identified more precisely as well, first of all, file name).

4.8.7 MFT scanning. For better understanding of the description below a few comments are necessary for the data structure

organization in NTFS partitions.

Data organization within NTFS partitions is considerably more complicated, than in FAT; we shall not go into details here (detailed descriptions of file systems can be found in the appendices hereto). Users should be aware of several guidelines:

1) Data recovery is simpler with NTFS than with FAT.

2) Any NTFS partition includes a certain basic table of directory and file placement (MFT - Master File Table). The table contains full information about everything stored on disk, including itself (two copies – the main one and Mirror).

3) An individual MFT record completely describes a specific file system object or even preserves the data of that object in some cases (resident object storage).

4) If you do not see anything after opening an NTFS partition or directory in Explorer it means only that you did not manage to read anything from the first 15 MFT service records (most likely the root directory) or index record of the selected directory. Most probably, a large part (if not all) of the undiscovered data can be recovered using the Scan MFT command.

5) If a specific MFT record is corrupted, data associated with it cannot be restored.




The Scan MFT method allows you to scan the whole MFT and use it to build a virtual file system tree.

Figure 130. Virtual partition produced as a result of MFT scan

MFT scanning is based on the information obtained from the current MFT descriptor (base or mirror). MFT descriptor is actually represented by 4 initial records of the corresponding table. Any NTFS partition has two descriptors – the base one and its copy. If the base descriptor and the copy match, scanning is performed using the main descriptor. If a descriptor is invalid (the program cannot read it or it contains garbage), DE switches to the correct descriptor and uses it for scanning. If both descriptors are valid but differ from each other, you can choose the descriptor for further operations and, consequently, MFT scanning (the selection is performed using the Select MFT descriptor command in the right-click menu of the partition boot sector).

Once the procedure completes, it builds a virtual file system for the selected partition. Files and directories for which no parent folder has been found, will be placed into the Lost&Found artificial directory.

4.8.8 Automatic restoration of NTFS partitions. Automatic restoration of NTFS partitions uses the following modes:

1) Search NTFS structures (the mode available from the right-click menu of the “drive” and MBR slot objects in Explorer).

2) Partition analysis (the mode available from the right-click menu of the boot sector of an NTFS partition).

3) Scan unused space (the mode available from the right-click menu of the boot sector of an NTFS partition).

There is a single method for restoration of NTFS partitions though it has three modes that differ in terms of initial data used for analysis.

The method is intended for complete scanning of an area on inspected device to check it for presence of NTFS data structures, analysis of revealed structures and subsequent creation of virtual NTFS partitions for access to user data.

We recommend using that mode only in cases of very serious damage to logical structures on completely functional devices (drives with logical problems or copies of physically damaged drives). In case of malfunctioning devices (defective sectors that cannot be read) you can use the mode in combination with the Make data copy option. However, creation of a full drive (partition) copy and further restoration work with it could yield better results.

Under serious corruption of logical structures we mean here damage preventing data extraction using other, simpler methods provided by the program (including, first of all, the Scan MFT mode, and excluding Raw recovery – the last method in the sequence of applicable technologies).

One considerable drawback of this method is the need for complete reading of the scanned data area and long sophisticated analysis of gathered results. For a completely operational drive the metadata search may take several hours (up to 24 hours depending upon drive capacity, its speed, the volume of required and found data).

Its significant benefit is in high efficiency in case of damaged logical structures (even when one or several new file systems have been created on top of a previous one).

The modes are completely automatic. User input is required only during the initial stage. That follows first of all from the very purpose of that method, which is in assistance in case of serious logical damage, which users cannot completely understand, characterize and respectively take specific actions for its restoration, or just searching for customer data using other tools provided by the program.

Virtual NTFS partition produced as a result of MFT scanning (the program shows in brackets the descriptor used for scanning, in this case, the base one).



It has been mentioned that there is just one restoration method, but several variants of its application exist using various original data. Let us explain that aspect in detail.

The Search NTFS structures mode can be started from the right-click menu of the "drive" object in Explorer. The figure below demonstrates the dialog for specification of original data.

Figure 131. Initial parameters specification dialog for the Search NTFS structures mode

The program will select the entire drive as the area for scanning and it will analyze all possible values of the cluster size. That is the most labour-intensive restoration variant.

This mode is recommended in two cases:

1) MBR sector and boot sectors of partitions are not accessible (they are bad or contain garbage).

The situation does not apply to cases, when partition boot sectors or their copies exist and contain valid information. In such case the MBR sector is very likely to be restored in Quick disk analysis mode or manually.

2) You are restoring an NTFS partition deleted during reformatting procedure with modification of partitions or their parameters.

The Search NTFS structures mode can also be invoked from the right-click menu of the MBR slot object in Explorer. In that case the program will select the current partition as scanning area, but it will also analyze all possible cluster size values.

The mode can be used in the following cases:

1) Boot sector of the partition being restored and its copy are not accessible (they are bad or contain garbage).

2) You are restoring an NTFS partition deleted during reformatting of the current partition (and partition size has not been modified).

Partition analysis can be invoked from the right-click menu of the boot sector of an NTFS partition. If the boot sector and its copy are both inaccessible, the mode will be completely identical to the previous one.

Figure 132. Initial parameters specification dialog for the Partition analysis mode

Current partition is specified in the parameters as the area for scanning. The program substitutes cluster size from the boot sector (or its copy) decreasing considerably time required for analysis and the probability of wrong identification of partition structure. Information about the size of structures is copied from the boot sector (or its copy) if the PreDef PBR switch is enabled.




The mode can be used in case of serious logical damage to a partition with a valid boot sector (or its copy) left, which has not been reformatted (in that case the next mode is used).

Operators can choose in the mode settings the option to scan by unused space of the partition, then the program will only analyze unused partition space (in that case deleted data of the current partition can be found). If you need to search for data possibly remaining from the earlier partition, you should either Scan unused space or configure the current method: set the flag by unused space of the partition and mark all possible values for Sectors per Cluster (because earlier partition could use a completely different cluster size).

The Scan unused space mode can be invoked from the right-click menu of the boot sector in an NTFS partition provided that boot (or its copy) and Bitmap is valid (otherwise the mode will not be available).

Figure 133. Initial parameters specification dialog for the Scan unused space mode

As the mode title implies, the program will analyze unused space based on Bitmap searching for the data left from earlier NTFS partitions. Thus, the initial situation is as follows: there was an NTFS partition, then it was reformatted without size modification, some data was written to it, then it turned out that the earlier partition contained important data. Since the current partition cannot provide information about cluster size for earlier partitions, all possible variants of the Sectors per Cluster value must be selected.

After parameter setting the mode starts working. Window appearance in that mode resembles the Partition analysis for FAT partitions and Scan MFT modes (window containing program log and the Stop and Exit buttons). During a logical scan the Operation informational panel reflects the current activity.

The actions performed in that mode can be subdivided into two essential parts – data search and data processing.

First the program searches the selected range of sectors. If you have launched the command earlier searching areas included into the specified range, those areas will be skipped during the process. This should not surprise you (during search the program displays in the Operation informational panel the number of the current sector, for example, LBA = 5 167).

As soon as the searching procedure is over, the program processes discovered data. If you have aborted the search, the software will display a prompt offering to decide whether it should process retrieved information.

Figure 134. Message window displayed after an aborted search procedure

Such behaviour is determined by the fact that the final result of processing may depend considerably upon the whole totality of found data (sometimes a single unread sector may result in making totally different and sometimes incorrect conclusions regarding data arrangement), so you will have to make the choice individually.

Because of that problem the program deletes the results of each previous processing prior to a new data processing in order to allow creation of a new data model based on the whole totality of all discovered records.

After processing (and mode) completion the respective objects will appear in the Explorer mode provided that the program has found enough data for the interpretation into a variant of virtual file system.



Figure 135. Explorer window with the logical scan results

4.8.9 Copying a region of sectors. This is an auxiliary mode. It can be invoked from the Service menu of task window if you have enabled the

Make data copy option. The command is intended for copying a data range from the task source device to an area of target device specified for copying. The size of copied areas must be equal, though the starting positions may differ.

The mode allows, for instance, copying of a data area from a specified partition to a position on another drive different from the initial location (initial LBA). If necessary, you can employ the mode to collect on a single drive sector-by-sector copies of data from several other devices.

One limitation of the mode is that it does not create or take into account a copying map, using task settings only partially. It means that you should keep in mind the following:

− If you have created a copy with a map and then apply that mode the copy may become corrupted. − If you have copied a specified range and then simply enter the Explorer mode or launch searching (any

procedure pertaining to reading), the data of the copied region may be modified.

Figure 136. Informational message before region to region copying

Figure 137. Parameters for region copying to another region

The figure displays the dialog box, where you can define the parameters for region copying. The window appearance in that mode practically does not differ from, for example, the Scan MFT mode.

Virtual NTFS partition produced as a result of logical scan (the original partition has been formatted and replaced with small volume of new data)

Current NTFS partition

The program adds to the "Lost&Found" folder those files and folders for which no parent directories have been discovered




4.8.10 View and edit sector. The mode is intended for viewing and editing the data of a specific recovered sector; it is available in the

following cases:

− During work with a copying map or object map. To switch to the mode, you should double-click the square box of the corresponding sector or run the Edit item from the context menu of the map or use the View the first sector item from the context menu in the object chain list.

− During work in GREP search and Raw recovery modes it appears as the View sector item in the right-click menu of the resulting element list.

− In the Explorer mode it is the View the first sector item of the object right-click menu. As soon as you invoke the mode, the program will display an editing window:

Figure 138. Window appearance in sector viewing and editing mode

The upper part of the window contains the main menu and quick access toolbar.

The central window part displays the data viewing and editing area. It is subdivided into two sections. The left section shows data in hexadecimal notation, the right part shows respective characters.

The lower window part contains the panel, which displays the current status and additional information.

4.8.10.1 "Data" menu item.

The Data menu item allows the following operations: − Load (Ctrl+R) or read data; − Save (F2) data to corresponding sector − Save to file − Load from file.

The Load method allows users to read again data from the current sector.

The Record method allows saving of edited or loaded from a file data to a sector.

The Save to file method is intended to save data from a read sector to a file.

The Load from file method allows loading of data from file to editor.

4.8.10.2 "Editing" menu item.

This item contains a group of methods employed for sector data search and editing: − Find − Find next



− Fill in − Edit integers and bits − Select all.

The Find method allows search for required data position by mask within the loaded sector.

Figure 139. The search window

The Find next method allows searching for the next instance of required structure matching the same mask.

The Fill in method allows filling the specified sequence of bytes with required fill byte. The user can simply copy the fill byte into the file data (the "=" operator) or replace the original data with a result of bitwise operation between every byte of the original data and the filling byte (the "AND", "OR", and "XOR" operators).

Figure 140. Filling parameters window

Binary editor allows changing fragments of the document being edited as single-byte, double-byte or four-byte integers. To start editing, you should select in the editor a data fragment 1, 2 or 4 bytes long and select in the Edit menu the Edit integers and bits (Ctrl+B) item. This command will display an editing window. You can edit values in decimal, hexadecimal or binary notations.

Figure 141. Editing integers and bits

The Select all method is intended to select the whole data area without additional use of the mouse or keyboard. That may come handy because many methods in this mode operate with a selected area (including operations with the clipboard.

4.8.10.3 "View as…" menu item.

This item unites a group of methods employed for interpretation and viewing the data of a previously read sector as a specific structure:

− Partition table − Boot FAT16 (boot sector of a FAT16 or FAT12 partition) − Boot FAT32 (boot sector of a FAT32 partition) − Boot NTFS (boot sector of an NTFS partition) − FAT folder (directory of a FAT partition)




− Ext2(3) superblock (boot counterpart on LINUX EXT2 or EXT3 partitions) − Ext2(3) GroupDescriptors (sector containing the table of group descriptors within a LINUX EXT2 or

EXT3 partition) − HFS+ Volume Header.

All variants of presentation (except for FAT folder) allow editing of data in the structure fields and therefore they can be used during data recovery. These methods can be invoked both from the binary editor and from the Properties of the right-click menus of the respective objects in the Explorer mode.

The appearance of some presentation variants is shown in the figures below:

Figure 142. Viewing drive descriptors as a Partition table

Figure 143. Viewing the boot sector data as Boot FAT16



Figure 144. Viewing the boot sector data as Boot FAT32

Figure 145. Viewing the boot sector data as Boot NTFS

Figure 146. Viewing a sector with directory elements as a FAT folder




Figure 147. Viewing Ext2(3) superblock

Figure 148. Viewing the table of Ext2(3) group descriptors

Figure 149. Viewing HFS+ Volume Header



4.8.10.4 "Options" menu item.

This menu item allows users to change the form of data presentation on the panel: − Set the number of bytes per line − Set the number of bytes per column − Change the font and its size − Change the text encoding − Change colours.

Figure 150. Binary editor settings window

4.8.10.5 Quick access toolbar.

The upper part of the window contains a navigational panel and information lines reflecting the current status. Purposes of the toolbar buttons are described below.

Figure 151. Binary editor toolbar

− Load/Save data

− Editing (Copy, Cut, Paste)

− Control over positioning (First, Previous, Next, Last)

− Go to sector and the window for entry of the number of the sector to move to.

− Exit the task.

4.8.10.6 Viewing and editing panel, its tabs.

This is the main panel used while viewing and editing loaded data.

The left panel section displays data in hexadecimal notation, the right shows data as text.

Methods applicable to the panel are accessible via the right-click menu:

− Load from file − Save to file − Copy (Ctrl+C) − Cut (Ctrl+X) − Paste (Ctrl+V) − Delete (Alt+Del) − Copy as text − Edit integers and bits




− Fill in − Find (Ctrl+F) − Find next (Ctrl+N) − Set bookmark − Go to bookmark − Plugins.

Some of those methods can also be invoked using the main menu and quick access buttons while the rest can be started from the context menu only (e. g., work with bookmarks and data copying as text).

To mark an object, you can use the Set bookmark submenu in the editor's right-click menu or the Shift+Ctrl+N hot keys (where N stands for the marker number; there may be 10 markers in general). Selection of a submenu item sets a marker, which will appear in the editor to the left of line offset and the selected menu item receives a checkmark. Reselection of the Set bookmark submenu item removes the marker and unchecks the menu item.

To go to a set bookmark, you should select the Go to bookmark item from the editor right-click menu or use the Ctrl+N hot keys (where N stands for the marker number). Submenu items corresponding to set bookmarks appear checked.

Figure 152. Binary editor window with set bookmarks

In order to copy data as text, you should select the fragment of the data being edited and choose the Copy as text command from the right-click menu. Since the program copies not the data proper but their screen presentation, then it displays a window of data presentation parameters.

Figure 153. Window for copying data as text

As Text /As Binary data. If the Text mode is selected, then the data being edited are viewed as text, so they will be added to clipboard without conversion. You should not use that copying method if the data include non-printable characters. If the Binary data mode is selected, then the program will add to clipboard a text report that looks identically to the view in the binary editor. Other entered parameters affect its generation; they are accessible in the Binary data mode only.

Number of bytes in a line – the number of bytes in every presentation line.

Number of bytes in a column – the number of bytes in every presentation column.



Address field width – the parameter defines the size of the address (offset) field. The program uses zeroes to supplement values to the specified width.

Address prefix – the parameter defines the text displayed to the left of an address value (e.g., "0x" or "$").

Show text – an attribute informing about the presence/absence of text presentation for binary data.

Text margin – the number of characters separating the areas where text and binary data are displayed.

Margin space symbol – the character separating text and binary data.

Replace unprintable symbols with – the symbol that will be used to replace non-printable characters in the text data area.

Plugins. This section of the context menu is supposed to include plug-ins for the binary editor. Currently it contains the Add Grep method, which allows adding a required search criterion from the binary editor into the regular expressions reference. To do that, highlight the necessary data substring (which will act as the search criterion) in the binary editor and invoke from the context menu Plugins → Add Grep. The program will display a dialog for regular expression editing where you can specify the name for the criterion (default – New Grep), its category and slightly modify the search criterion, if necessary.

Figure 154. Search criterion editing window

4.8.10.7 Status and additional information panel

The status line reflects the current editing status. The panel consists of four parts: 1) Offset from the start and selection length (dec). 2) The sign informing about the presence of unsaved changes (modified data in the viewing and editing

window are highlighted with the background colour). 3) Information about data value at the current cursor position (Byte, Word, DoubleWord); 4) Information about the status of read sector (in accordance with the legend in the copy creation mode).

Figure 155. Binary editor status line

1 2 3 4




4.8.11 MFT record editor.

4.8.11.1 Purpose.

The main purpose of MFT record editor is visual presentation of MFT logical structure, assistance to the operator in its understanding and modification, if necessary.

4.8.11.2 Appearance and controls.

The figure below demonstrates window appearance in MFT record editor mode.

Figure 156. MFT record editor

Left part of the screen contains HEX editor panel, right part – tree-like record structure.

You can navigate both panels and between them using keyboard or the mouse. While navigating any of the panels, the program will highlight the corresponding record in the other panel.

Editor toolbar and controls are located above the panels.

4.8.11.3 Toolbar.

The figure below demonstrates the editor toolbar.

Figure 157. MFT record editor toolbar

It includes several groups of controls:

1) Exit the editor

2) Record integrity control: restoration and preparation for writing.

When an MFT record is loaded to HEX editor buffer, the program checks record integrity and restores it (see section 6.3.4). The result of that operation appears in the status bar of the tree structure; it can take the following values:

− FixUp OK – record fixed successfully.



− FixUp OK (1st) – the first sector of the record restored successfully while the Real size of the FILE Record is equal to 512 bytes or less and thus it allows you to ignore the error during restoration of the second MFT sector.

− FixUp Error – record restoration failed; further record editing will require modification of the Update Sequence Number & Array fields.

3) Save changes.

This command allows you to save the results of record editing to task drive. Prior to MFT saving, the record must be restored and it must have no problems with preparation for recording, i.e. record condition should be FixUp OK. Then the program performs preparation for recording, saves MFT to task drive leaving the record not restored.

4) Navigation: Mode, (Forward, Back, Go to) or (Search Forward, Abort, Search back, Go to), LBA/VSN/REC input field, the option to enable the search mode and the condition for search stop.

The program supports from one to three navigation modes depending upon the location where MFT record editor is started.

Drive navigation is available always regardless of the MFT record editor start location and the task status.

Navigation of Corrupted MFT records is available in case, if you have performed Scan MFT and/or Partition analysis of the task drive, and/or Search NTFS structures on the task drive. In this mode navigation is performed within the list of MFT records found earlier and marked as corrupted. The number of the current loaded record and the total number of corrupted MFT records appears in the third line of the status bar in HEX editor.

Navigation of MFT map is only available if you start MFT record editor on an NTFS partition of the task drive and a “live” MFT map is accessible. Navigation is performed between virtual sectors of the MFT map, the number of the current virtual sector and the total number of virtual sectors in MFT map is displayed in the third line of the status bar in HEX editor.

The Forward and Back fast access buttons allow navigation is sequential order between records/sectors. Go to button offers an opportunity to jump directly to the selected sector/record after entering its number in the input field.

While navigating the Drive or MFT map with the search mode enabled (the option to enable the search mode and the condition for search stop), the Search forward and Search back buttons allow searching in the selected direction for the marker of the «FILE» MFT record located in the initial four bytes of the table. Condition for search stop determines the number of matching symbols in marker. E.g., with the condition for search stop equal to 3, MFT record editor will stop on the record that has any of the following combinations in the initial four bytes: xILE, FxLE, FIxE, FILx, where x stands for any character. To force search termination, you can use the Abort button, the program sops also when border values (0 or MAX) of the sector number are reached.

5) The Partition, initial partition sector (Start LBA), and Cluster Size.

MFT record editing is performed to save in the end user data. Saving of user data stored in non-resident attributes requires information about the initial sector and cluster size of the supposed or real NTFS partition. That is where this toolbar section is used. The map of the non-residence attribute is built based on the Start LBA and Cluster Size values. Users can define field values using one of two supported methods:

− Select NTFS partition from the dropdown list. Start LBA and Cluster Size values will be substituted from the parameters of the selected partition, manual input into Start LBA and Cluster Size values will be blocked.

− Choose in the dropdown list Partition is not selected and enter the Start LBA and Cluster Size values manually.

Partition selection affects the availability of the Parse record, link to partition method in the HEX editor panel. If Partition is set to Partition is not selected, the method will not be available.

Value in the Cluster Size field affects the availability of the Map and Save attribute to file methods in the tree panel. When Cluster Size is set to zero, those methods are not available.

4.8.11.4 HEX editor panel

HEX editor is quite standard; it supports two buffer notations – hexadecimal and symbolic.

If a record field is an offset, then HEX editor highlights (red font on black background) also the position determined by the field value.

Both notations allow record editing. HEX editor has no limitations for record editing. Below the HEX editor panel you can find the status bar consisting of three sections. The first section displays loaded sectors relatively to the zero drive sector – absolute LBA. The second section displays loaded sectors relatively to the zero sector of the selected




drive partition or to the Start LBA field. The third section displays Record number / Total records in the mode for navigation between Corrupted MFT records or VirtualSectorNumber / MaxVSN in MFT map navigation mode.

Figure 158. HEX editor status bar during navigation within Drive

Figure 159. HEX editor status bar during navigation within MFT map

Figure 160. HEX editor status bar during navigation between Corrupted MFT records

4.8.11.5 Methods available in the HEX editor panel

1) Save to file and Load from file methods are available all the time. They allow saving MFT to file or loading it from file respectively.

2) View as Attribute and View as MFT Record method. Depending upon the cursor position (offset) the View as Attribute (offset greater than 0) or View as MFT Record (offset equal to 0) method can be available in HEX editor.

Tree panel switches correspondingly to display the attribute (MFT part) or the whole MFT.



Figure 161 View as Attribute and View as MFT Record methods

3) Parse record, link to partition method. It is used to link to a selected NTFS partition an MFT that is not

tied to any NTFS partition; it usually used to complete the record repair procedure.

This method is available if an NTFS partition is selected on the toolbar. In case of successful method application the file described by MFT record will be placed in the Lost&Found directory of the NTFS partition.

4) Fix AT80 in deleted Extend method. It is intended for restoration of attribute $80 in a deleted EXTEND MFT record. It allows complete (of the main record was extended with one additional) or partial restoration of the user data map.

The method is available if the following conditions are observed: empty list of attributes and File reference to the FILE record is other than zero.

The method is based on a peculiarity in removal of such records and does not provide 100% guarantees of restoration.

4.8.11.6 Tree panel

The panel is intended for logical parsing, visualization of MFT structure and its editing. Each field in the tree structure is described in the following format:




FIELD – field name

OFF – absolute field offset in record

LEN – field size in bytes

VALUE – value

T – value notation (S – string, I – integer, H – hex, U – Unicode string, D – date / time, ‘ ’ – none)

Editing of records in the tree panel is restricted to the S, I, H types. Pressing ENTER switches the tree structure within the panel into editing mode.

If a field represents a structure, the VALUE column is used sometimes to display additional information, for example, for an Attribute type $30 it duplicates the File name field of resident data.

All errors in logical MFT parsing are highlighted with red font.

Above the tree panel you can see a status bar consisting of two sections. The first one displays the status of the record integrity control. The second section is intended for display of a brief error description for the selected MFT record field. Since the number of possible damage variations is quite large, descriptions and restoration guidelines are available for some errors only. Their number and details will increase with further development of the MFT record editor.

Figure 162. Status bar of the tree panel

4.8.11.7 Methods available in the tree panel

1) Integer notation.

The method is only available for integer fields in record structure. You can use it to change field notation from integer to hexadecimal and back.

Figure 163. Integer notation

2) Map.

The method is available for the DATA RUNS field provided that: partition beginning (zero sector of the partition) is specified, partition cluster size is defined and the field has no chain generation errors.

The method opens standard Data Extractor window for map viewing.



Figure 164. Map

3) Attribute saving to file.

The method is available for any resident or non-resident record attribute if it has no logical record parsing errors, the partition beginning (zero sector of the partition) and the partition cluster size is specified.

While saving an attribute, the program automatically generates file name in the following format LBA(XXXXXXX)_$XXXXXXXX, e.g.: LBA(149790)_$00000050 filename means that an attribute of record $00000050 located at LBA = 149790 has been saved.

If an attribute is named, then its name will be added to the file name: LBA(149790)_$00000050_<attribute_name>.

If an unnamed $80 attribute is being saved and MFT record contains a correct $30 attribute, then the file name will be substituted from attribute $30.

4.8.11.8 Restoration example. MFT record with multiple random corruptions




Restore the record by restoring in order its fields because a corrupted field often affects other fields that follow it.

Edit <HEADER>. The record has partially passed the integrity check as the FixUp OK (1st) record status shows.

The Update Sequence → Array → 1 → Marker value has to be corrected. Valid value should be taken from Update Sequence → Number = $00A7.

First we press the UnFix button to make the record ready for writing. Correct Update Sequence → Array → 1 → Marker and check the integrity using the FixUp button.

Record status changes to FixUp OK and <HEADER> has no more errors.

Now we proceed to the next error (invalid attribute type), it is the first attribute in the attributes list.

First, the attribute type should be included in the $AttrDef list:

Type OS Name 0x10 $STANDARD_INFORMATION 0x20 $ATTRIBUTE_LIST 0x30 $FILE_NAME 0x40 NT $VOLUME_VERSION 0x40 2K $OBJECT_ID 0x50 $SECURITY_DESCRIPTOR 0x60 $VOLUME_NAME 0x70 $VOLUME_INFORMATION 0x80 $DATA 0x90 $INDEX_ROOT



0xA0 $INDEX_ALLOCATION 0xB0 $BITMAP 0xC0 NT $SYMBOLIC_LINK 0xC0 2K $REPARSE_POINT 0xD0 $EA_INFORMATION 0xE0 $EA 0xF0 NT $PROPERTY_SET 0x100 2K $LOGGED_UTILITY_STREAM

Second, if <HEADER> → File reference to the base FILE record is equal to zero (it is the base MFT record), then the type of the first attribute in list must certainly be $00000010.

Of course, in case of double error both in <HEADER> → File reference to the base FILE record and in Attribute → <STANDART ATTRIBUTE HEADER> → Attribute Type, the situation is more complicated.

Edit Attribute Type and make sure there are no errors.

Then we proceed to Attribute[$00000030] → <DATA RESIDENT> → Filename namespace. In that field two

initial bits are used. Set bit 0 means that file name is a long name; set bit 1 means that file name is short. Length of the file name Attribute[$00000030] → <DATA RESIDENT> → Filename length in characters = 11, extension length - OLB – three characters. Therefore we conclude that Attribute[$00000030] → <DATA RESIDENT> → Filename namespace can take any – 1, 2, 3 – value.

Now we edit Filename namespace and make sure that there are no errors.




We proceed to the field Attribute[$00000030] → <DATA RESIDENT> → File Name. The field contains

characters in various encodings (different code tables). Edit the field in HEX editor. Please note, that file name does not affect the validity of user data in MFT record, the main requirement implies that file name must be correct from the viewpoint of your operating system.

Then - Attribute[$00000080]. It is a non-resident attribute that has <DATA RUNS>.

As a hint, each Run in the VALUE column is commented in three fields:

1) NNNNN [SSSSS - LLLLL],

where NNNNN stand for the number of clusters in chain (stored in each chain;

2) SSSSS – Starting VCN chains (calculated on the basis of Last VCN of the preceding chain),

3) LLLLL – Last VCN chains = SSSSS + NNNNN – 1.

Consequently, Last VCN of the last chain is Last VCN of the attribute data from the viewpoint of <DATA RUNS>.

Validity of a non-resident attribute can be verified by the relation between two fields: <STANDART ATTRIBUTE HEADER> and <DATA RUNS>.



Those fields in <STANDART ATTRIBUTE HEADER> are: Starting VCN and Last VCN, in <DATA RUNS> - LastVCN of the last chain.

In a correct attribute the values of LastVCN <STANDART ATTRIBUTE HEADER> and <DATA RUNS> match.

Let us try to identify the cause of mismatch.

<STANDART ATTRIBUTE HEADER> → Last VCN – the value is obviously wrong. First, it is negative;

second, the divergence with <DATA RUNS> → Last VCN is too large. That allows an assumption that high bytes of the 8-byte field are corrupted. Therefore we edit the field after switching it into hexadecimal notation using the appropriate method.

Having fixed the fifth and the eighth bytes to $0, make sure they are correct – the Last VCN values in

<STANDART ATTRIBUTE HEADER> and <DATA RUNS> match. It means also that the fields containing the number of clusters per each chain <DATA RUNS> → Run → Clusters length contain valid data – it is unlikely that errors in two or more chains would compensate each other so that the resulting sum of clusters remains invariable.

<STANDART ATTRIBUTE HEADER> → Starting VCN must be equal to 0 – if the record is base. Edit the field.




According to the definition, <DATA RUNS> chains must complete with data end marker – a byte with the 0

value.

Edit the <END OF DATA RUNS> field changing the value to 0.

Save the result of our operations to task drive using the corresponding toolbar button.

Additionally, you can calculate the cluster size dividing Allocated size of the attribute by LastVCN+1. In our case, it will be 459776 / 898 = 512, Cluster Size = 1 sector. Cluster size in sectors must be 2^N - [1,2,4,8,16,32,64,128].

Now we can open the map of <DATA RUNS> for attribute $80 to control user data. If the <DATA RUNS> → Run → Clusters offset field in the first <DATA RUNS> chain has not been damaged, we are very likely to see the actual data of that MFT record.

Now we can save the user data of the MFT record by writing the attribute to file.



4.8.12 MacOS Metadata Editor.

4.8.12.1 Purpose.

The main purpose of MacOS Metadata Editor is visual presentation of logical record structure, assistance to the operator in its understanding and modification, if necessary.

4.8.12.2 Appearance and controls.

The figure below demonstrates window appearance in MacOS Metadata Editor.

Figure 165. MacOS Metadata Editor

Left part of the screen contains HEX editor panel, right part – tree-like record structure. You can navigate both panels and between them using keyboard or the mouse. While navigating any of the

panels, the program will highlight the corresponding record in the other panel. Editor toolbar and controls are located above the panels.

4.8.12.3 Toolbar

Figure 166. Toolbar appearance

It includes several groups of controls:

1) Exit the editor

2) Save changes (allows you to save the results of record editing to task drive).

3) Navigation: Mode, step input field (in sectors), Forward, Back, Go to buttons, LBA/VSN input field.

The program supports from one or two navigation modes depending upon the location where MacOS Metadata Editor is started.

Drive navigation is available always regardless of the MacOS Metadata Editor start location and the task status.




Navigation of XXX File map is only available if you start MacOS Metadata Editor on an HFS+ partition of task drive by invoking the MacOS Records Viewer → XXX File method, where XXX stand for Extends or Catalog File. Navigation is performed between virtual sectors of the corresponding map.

The Forward and Back fast access buttons allow navigation is sequential order between records/sectors with the step defined in the Step input field. Go to button offers an opportunity to jump directly to the selected sector after entering its number in the input field.

4.8.12.4 HEX editor panel.

HEX editor is quite standard; it supports two buffer notations – hexadecimal and symbolic. If a record field is an offset, then HEX editor highlights (red font on black background) also the position determined by the field value. Both notations allow record editing. HEX editor has no limitations for record editing.

Below the HEX editor panel you can find the status bar consisting of two sections. The first section displays loaded sectors relatively to the zero drive sector – absolute LBA. The second section displays VirtualSectorNumber / MaxVSN in the mode for XXX map navigation.

Figure 167. HEX editor status bar during navigation within [Drive]

Figure 168. HEX editor status bar during navigation within [XXX File map]

4.8.12.5 Methods available in the HEX editor panel.

Save to file and Load from file methods are available all the time. They allow saving a record to file or loading it from file respectively.

4.8.12.6 Tree panel.

The panel is intended for logical parsing, visualization of MacOS metadata record structure and its editing.

Above the tree panel you can see the panel of metadata properties containing the Record type and Record size dropdown lists.

Figure 169. Status bar of the metadata tree panel

Record type allows you to change the algorithm for parsing and display of the data in HEX editor buffer within the tree panel. Currently the program supports parsing of the following MacOS metadata:

− HFS Master Directory Block − HFS+ Volume Header − HFS+ Catalog Node Descriptor − HFS+ Extents Node Descriptor − Apple Drive First LBA − Apple Partition − EFI GPT Header − EFI GPT Entries.

Record size (in sectors) allows you to modify the number of sectors loaded to the HEX editor buffer.

Each field in the tree structure is described in the following format:

FIELD – field name

OFF – absolute field offset in record

LEN – field size in bytes

VALUE – value

T – value notation (S – string, I – integer, H – hex, U – Unicode string, D – date / time, ‘ ’ – none).

Editing of records in the tree panel is restricted to the S, I, H types. Pressing ENTER switches the tree structure within the panel into editing mode.



If a field represents a structure, the VALUE column is used sometimes to display additional information, for example, for an Rec#[x] it duplicates the Node name.

All errors in logical record parsing are highlighted with red font.

Above the tree panel you can see a status bar consisting of two sections. The first section is unused yet. The second section is intended for display of a brief error description for the selected field in a MacOS metadata record.

Since the number of possible damage variations is quite large, descriptions and restoration guidelines are available for some errors only. Their number and details will increase with further development of the MacOS Metadata Editor.

Figure 170. Status bar of the tree panel

4.8.12.7 Methods available in the tree panel.

Integer notation. The method is only available for integer fields in record structure.

You can use it to change field notation from integer to hexadecimal and back.

Figure 171. Integer notation




5 Data recovery. This chapter is devoted to the description of situations causing corruption of user data (further referred to as

the data) and possible methods of its recovery. All methods are detailed as applies to the PC-3000 suite and Data Extractor UDMA software.

We assume here that our readers are already familiar with the basics of IDE drive architecture. Otherwise we recommend having a look at some fundamental principles described at: http://www.acelab.ru/products/pc/traning.html.

There are several causes making user data inaccessible. Inaccessibility we understand here as any circumstance making it impossible to read data from a drive no matter whether it is physically damaged (BAD sectors, malfunction of magnetic heads, etc.), or data corruption occurred on a totally functional HDD (file system failure, consequence of virus infection, incorrect operator actions: erasure of essential information, formatting, etc.).

We shall refer to data recovery from a damaged drive as physical recovery and as logical recovery whenever the data have to be recovered from a functional drive.

Very frequently logical recovery has to be performed following a physical recovery.

5.1 Causes of physical drive malfunctions.

5.1.1 Bad sectors. They appear as a result of damage to the magnetic layer on disks (scratches, chipped particles, cracks, etc.).

BAD sectors may appear because of magnetic heads falling on disk surface (e. g., scratches and chipping occur when a working drive survives a hit or other impact) or may result from normal ageing of magnetic surfaces (long storage, especially under variable temperature conditions, may result in scratches of the magnetic layer).

Scanning such drive with test software, such as the universal utility of PC-3000 suite reveals UNC, AMNF, and IDNF errors.

When Scandisk software is used for drive testing, such errors do not get identified; instead, the program marks the sectors as BAD.

The probability of data recovery when BAD sectors appear depends heavily upon their number and location on drive surfaces.

It may be quite possible, that the required data remain unaffected by emerging BAD sectors. In that case data can be copied using standard tools of the operating system and we do not examine the case because of its obvious simplicity.

The situation is much worse, when BAD sectors appear in the system area used by the OS (root directory, file allocation tables, etc.). In such case the data cannot be recovered without special equipment.

Sometimes BAD sectors occur within the user files. Then data copying with, for example, OS tools is also impossible because of constant I/O errors, which eventually force the system to stop the copying procedure.

5.1.1.1 Malfunctions pertaining to damaged servo labels on a drive.

Usually the malfunction happens because of a large number of BAD sectors (the greater is the number of surface defects, the higher is the probability of defect occurrence in the area occupied by servo labels).

Servo fields are essential drive components used to sustain stable rotational speed of magnetic disks and precise positioning (movement) over the drive surfaces for access to sectors.

An attempt to read a track with corrupted servo labels causes an exceptional situation when further drive behaviour becomes hard to predict. HDD actions mostly depend upon programming used by the developers of firmware used in each specific drive model.

In the most elementary case a drive would report an IDNF error and move on to read the next servo label.

However, if several servo fields in a row are corrupted a drive is usually unable to establish stable rotational speed and perform fine head adjustments for the track.

As we have mentioned above, various drive models behave differently in that situation.



E. g., some drives try moving to the next cylinder but having stabilized the rotational speed there they again encounter corrupted labels on the way back, etc. The process is accompanied with a whirring sound and readiness loss by the drive.

Some HDDs cannot read servo labels in motion (to accomplish a stop) and hit the actuator limiter; such drive produces at that knocking sounds.

Reading of the areas containing corrupted servo fields is usually impossible. First of all, a drive cannot position the heads over sectors with corrupted servo labels and, in the second place, drives usually hang on such defective areas. Third, positioning failures frequently cause head knocking against the internal limiting stop.

The knocking is the worst thing while trying to recover data from a drive with corrupted servo fields. As a matter of fact, the moment the actuator strikes the limiter the magnetic heads bounce back with an additional vertical vibrational motion hitting disk surface. The whole process is followed by increasing damage to magnetic surfaces.

Therefore it is essential to avoid actuator knocking against the limiter while trying to read information from a drive with corrupted servo labels.

5.1.1.2 Malfunction of the magnetic head assembly (MHA).

This malfunction type includes failures of the reading element of magnetic (or magnetoresistive) head or failure of a channel on the preamplifier commutator chip.

In that case it is impossible to read data from the corresponding surface. Moreover, drive service data is also inaccessible if it is located on the same side. Switching to the surface will immediately result in looped actuator knocking against the limiter because servo data for the surface are not available.

Partial data recovery from such drive is possible provided that it can be made to report on readiness (i.e. when the head used for drive initialization is functional). Usually it is head 0. However, as soon as the drive attempts to use the failing head, it will immediately start knocking being unable to position the head properly. The read data volume in that case is in inverse proportion to the number of malfunctioning magnetic heads.

5.1.1.3 Corruption of drive service data and resulting inoperability.

There are several reasons that cause corruption of service data, for instance, BAD sectors occurring within the service area, firmware errors causing sometimes erasure of certain sectors in firmware zone, overflow of S.M.A.R.T. logs, corruption of drive translator, etc.

A drive with a damaged service zone cannot initialize itself (an attempt to read drive description causes an ABRT error). Consequently, it will not be recognized by BIOS and will remain invisible to the system. Data cannot be copied from such a drive using standard OS tools.

5.1.1.4 Other causes resulting in inaccessibility of user data on a drive

Such causes include, for example, electronic board malfunction or cases, when a drive falls down with a resulting shift of the magnetic disks stack. Drives damaged during natural disasters (floods, fire, etc.) also belong to this group.

5.1.2 Causes of logical data corruption.

5.1.2.1 Failures in file system operation.

Data losses may result from failures of the operating system, namely of its file subsystem. Errors in the file system operation, in their turn, may be caused by various reasons: power supply failures, software errors, incorrect user actions (power-off or reset during software operation), etc.

File system is based upon numerous important tables and structures.

Existing partitions and their types are defined in the partition table. Organization of each specific partition depends on its type.

The following data are essential for FAT file system: − Boot sector containing information about partition size, cluster size (the number of sectors occupied by the

smallest data block), the number and size of FAT copies, root directory location.

− File allocation table (FAT) containing the information about file position within a partition.




− The directory containing information about file attributes (name, size, date of creation, last access and modification, etc.) and its initial cluster.

Corruption of any of the above-listed structures renders access to the corresponding file either impossible or very complicated. Thus, if the directory slot pertaining to the file gets corrupted, then the information about its initial cluster is lost so that the information about file attributes is gone forever. However, information about the initial cluster can be obtained using other means, for example, you can find file beginning by its signature. If the FAT portion describing a file gets corrupted, file recovery becomes impossible if it is fragmented. A corrupted boot sector (can be rebuilt) complicates access to FAT and directories.

The following data are essential for NTFS file system: − Boot sector containing information about partition size, cluster size, file record size, directory record size,

initial cluster of the Master File Table (MFT) and initial cluster of the copy containing the first 4 MFT records.

− MFT containing complete information about the attributes of files and directories and their locations.

One critical condition for gaining access to a directory or file is the availability and integrity of the corresponding directory or file records in MFT. Boot sector corruption may complicate access to the table. If MFT is inaccessible or corrupted, there is no opportunity to access files. The only remaining method for partial data recovery is searching for file headers using their signatures, i.e. raw recovery.

The following data are essential for Ext2(3) file system used in Linux: − Super Block – a boot sector counterpart containing information about partition size, cluster size, the

number of data block groups, the number of inodes per group.

− Table of group descriptors containing the information about data structure in a specific group.

− Table of inodes of a specific group.

− File directories.

Inode records contain information about the attributes and location of files and directories. The table of group descriptors together with the tables of inodes are of primary importance. Super Block corruption complicates access to the table of group descriptors. If a table of group descriptors gets corrupted, the information about positions of inodes tables will be lost. Corruption of inode tables makes it impossible to obtain information about file attributes and their locations.

Damage to any of the structures and tables listed above can cause troubles accessing data or their irreversible loss.

UFS1(2) file system is similar to Ext2(3) (to be precise, UFS was used as the basis for Ext2(3)). Therefore, UFS1(2) uses identical data structures, such as superblock and tables of inodes. There are also differences. For example, in UFS1(2) a block (cluster counterpart) is subdivided into smaller parts called fragments where final portions of user data can be stored. UFS1(2) uses just one instance of the table of group descriptors, which contains statistic data only. Information about a specific group referred to as group of cylinders is stored in group descriptor located at the beginning of each group. Group descriptor also contains bit maps of blocks, fragments and index nodes.

However, in almost every case of file system errors the chances to restore information are quite high. In fact, many structures have copies while others can be reconstructed. Even in case of complete corruption of file system structure you can use raw recovery and attempt to extract required data. The only exception includes cases, when the data are physically erased.

5.1.2.2 Incorrect user actions - erasure, formatting, etc.

File deletion may be performed out of negligence or intentionally or even involuntarily. In the latter case files get deleted because some software functions incorrectly or because of virus activity.

File system in most cases does not immediately erase file contents from disk while deleting it. So, if an operator has accidentally deleted some files but immediately realized the mistake the probability of their restoration is quite high (though different for each file system).

Files can be restored even after some time, at least partially.

When a high-level format command is executed, most data remains in the original location, the system does not physically delete them, but in various file systems service tables may be reset and that may cause partial data loss.



5.1.2.3 Consequences of virus activity.

Those consequences may be very different; they depend upon harmful actions programmed in a specific virus..

Viruses may consume resources without releasing them (disk space, memory, GDI, etc.) causing, in turn, operating system failures and probably file system errors.

More malicious viruses may physically corrupt hard drive data: modify file contents, delete, format drives, damage file system service information, etc. (e, g., CIH virus deletes every eighth sector on all hard drives).

5.2 Preliminary diagnostics of the drive under examination. Prior to the beginning of restoration work you should perform diagnostics of the drive containing the data to

be restored with maximum precision. You should identify, whether the drive is physically damaged, and if it so determine damage degree.

The procedure can be performed using any diagnostic software, but we recommend using the PC-3000 suite for Windows. The following situations are possible as diagnostics results:

− Drive electronic board malfunction.

− Drive spindle motor malfunction.

− Drive MHA malfunction.

− Service data damage.

− BAD sectors on drive surfaces.

− Drive may be physically functional.

The restoration methods will be different in each case, let us discuss them in detail.

5.2.1 Drive electronic board malfunction. Such a problem usually does not cause loss of user data though there may be exceptions.

The main difficulty in that situation is the necessity to find the same board (from another drive of the same family and in some cases with the same capacity). Moreover, sometimes you will have to select a board containing a compatible or identical firmware version in microprocessor ROM.

Generally, the following guidelines should be followed:

Replacement boards should be sought in an identical drive family. If you have no information about its identification codes, you can compare the layout of printed circuit boards and installed chips. Sometimes you can use a drive's serial number. In most cases it will be of little effect, because there are lots of drives, but sometimes a situation is possible, when a company purchases several computers in a batch. Then it is probable that they would contain drives from the same shipment with close serial numbers. Then you can use such a drive as a donor device.

At power-up during trial installation of replacement board listen for knocking or screeching sounds, turn off the power instantly if you hear anything like that and carefully check everything again.

If a drive spins up the spindle motor and produces no mentioned unwanted sounds, then you can try connecting it to testing software and scan it checking whether the data on it are accessible for reading.

If you are using the universal PC-3000 utility for testing, then pay attention to reading of drive description from the device and verify its surfaces.

Frequently the sealed head-and-disk assembly case also suffers because of board malfunctions. This is illustrated by a well-known issue of Quantum drives. Malfunctioning chip that controls the spindle motor and actuator makes a drive start knocking producing BAD sectors right in the initial area of disk space containing the table of partitions, boot sector and other service data.

Electric parameters of boards are characterized by certain scattering even on identical models. So installation of another board to a head-and-disk assembly may result is a considerably deteriorated data reading. BAD sectors may appear on a drive, which used to work flawlessly.

Therefore, if after board replacement data reading causes errors you could try looking for the most compatible board among the available ones.




5.2.2 Drive spindle motor malfunction. Spindle motor malfunctions may be related to its mechanical seizure or to a break or burnout of drive winding,

or, more frequently, its short failure.

In case of motor seizure (which usually happens with hydrodynamic bearings) you can dismantle it and eliminate the problems preventing normal rotation – chipped parts and notches. We have described the method applicable for bearing repair in Seagate Barracuda IV HDDs at our technical support site for registered users of PC-3000 at: http://www.acelab.ru/pcTechSupport/DOSvers/TechDoc/Barracuda4.html

In case, when the spindle motor coils get damaged, its controlling chip on the electronic board usually burns out, too. If you install a functional board on a HDA with such malfunction, there is great probability that the controlling chip will burn out again. Modern drives employ the star-shaped scheme for connection of coils (see the figure below).

A

BC

0

Figure 172. The scheme of motor coils connection

We do not discuss here the cases, when drive coils break or burn out, because they are too complicated.

Short connection of a coil in many cases allows starting the motor and data recovery. To do so, you should first measure the impedance of normal coils and the impedance of the short coil. Then connect in a daisy chain to the short coil phase a 5-10 W resistor with impedance equal to the difference between the value for normal coils and the short one.

It is advisable to place a cooling fan at the spindle motor control circuit, because the chip will be working overloaded.

Perhaps, you might have to start the spindle motor in two steps. First perform the initial power-on - the drive will very slowly gain speed. If the controlling chip turns the spindle motor off after timeout then you should power-off the drive and after a second switch it on again.

5.2.3 Drive MHA malfunction. MHA malfunctions include both failures of the magnetic (or magnetoresistive) heads and failure of a

preamplifier commutator chip located on drive actuator.

MHA fault manifests itself in the form of constant knocking sounds produced by the actuator hitting against drive limiter. If the sounds appear right after drive power-up (provided that the electronic board is sound) they mean that magnetic head 0 and (or) 1 are failing or that the corresponding channels of the preamplifier commutator chip are malfunctioning. They are used for drive initialization and reading of firmware data in most HDDs.

The only solution is MHA replacement with another one taken from the same model. We do not discuss the case here, because it is a very specific and complicated operation.

If a drive reports on readiness normally, though it may produce some knocking sounds, it means that system heads and channels (those used for drive initialization) are functional and therefore you can partially read data from such drive using Data Extractor UDMA software.

E. g., if a drive has 6 heads and one of them cannot read, then the size of recovered data will be equal to 5/6 of the total size of drive data; if the drive has 4 heads, then it will be 3/4 respectively, etc. A part or even all of the information required by your customers may turn out to be in that recovered portion.

An attempt to restore drive contents completely would require a MHA replacement with a functional one taken from the same model. The procedure is extremely complicated and demands from the operator certain skills and experience as well as availability of special tools and devices. It is really advisable to perform all work opening the head-and-disk assembly within a class 100 clean room (100 dust particles per 1 sq. m.). Such zone can be organized in a specialized room or on a properly equipped table.

As we have mentioned, the work is complicated and even an experienced specialist during MHA replacement may encounter situations causing scratches on magnetic surfaces.



Therefore prior to MHA replacement work you are advised to use Data Extractor UDMA software to read from the drive maximum available information.

After successful MHA replacement the new MHA performs positioning slightly differently from the original one due to gaps in the seats and factory tolerances. That results in servo system failures and multiple BAD sectors even if the surfaces had no defects before.

That is why even after MHA replacement we recommend reading data from Data Extractor UDMA software. Its reading algorithms are specifically engineered for work in such poor conditions.

Some specialists do not replace the whole MHA in case of preamplifier chip malfunction. Instead, they remove the original MHA and solder a new chip. In that case after installing the original MHA back they reach better matching with earlier records so the drive operation is more stable. However, soldering a chip on a flexible lavsan MHA cable is a quite unique task that requires smoke-free flux and great experience.

5.2.4 Service data erasure. Such malfunction usually causes all drives to behave identically:

To any logical command they respond with an ABRT error in the respective register. Of course, nothing can be copied from a drive in such condition. The situation is complicated by the fact the in many models the translation program is located within the service data area.

The program acts as a link between logical LBA and physical PCHS spaces, it is responsible for hiding of physical defects and bypassing them during work with logical parameters.

Defect lists of an individual drive model are used as a source for creation of its translator. Many drives have a special factory mode command employed to create a translator. Otherwise it is generated automatically after the sol-called internal formatting, when a drive formats itself without any external control. The formatting at that is performed in strict compliance with the existing lists of defects, all defective sectors are skipped (remain unformatted).

After successful completion of internal formatting a drive recalculates its translator and records it to its service area; then it is ready to work using logical parameters, e. g. in LBA.

If you try to record service data with the same version from an identical drive to the one with corrupted service data1, the latter will start working, it will read drive description and execute many logical commands, but an attempt to read user data will be successful only until the first encountered defect. Then the drive will constantly produce IDNF errors.

Such behaviour is caused by a mismatch between the translator and actual drive format, while reading the number of a required sector will not correspond to the actually read sector. Of course, you can try to read data ignoring error (e. g., Data Extractor UDMA software can do that), but anyway the difference between the translator and actual drive condition will result in skipping or a shift of copied data relatively to the actual records. Eventually the OS will fail to interpret such data properly.

Please note, the greater is the number of defects in the original drive and in the borrowed translator, the more striking will be the difference between the read data and actual information. However, you may employ the method in a hopeless situation. Then it is recommended that the recorded new translator should contain as few defect records as possible (an empty one would be the best).

But overwriting of the original service data (no matter how corrupted it is) should really be the last resort.

A little more delicate approach from the viewpoint of data recovery would be to use the so-called HOT-SWAP method instead of overwriting the service data.

It consists in swapping the electronic board from a functional drive to another one with damaged service data without turning the power off.

The procedure is as follows. Find a totally identical2 drive (let us call it a donor HDD), remove its electronic board. Then install for testing purposes the electronic board from the malfunctioning drive to the normal drive and check its functionality3. This is necessary to ensure that the electronic board from the malfunctioning drive is normal and to check its compatibility with donor HDA and its firmware version.

After compatibility testing of boards and HDA you can proceed to the actual HOT SWAP process. 1 You can record service data using, e. g. PC-3000 software and hardware suite. 2 A drive with the same capacity from the same family. 3 The task can be accomplished using, for example, the PC-3000 suite.




Connect the donor to Data Extractor UDMA and create a task for reading data of the type you need. After successful task creation use the “Service” menu to send a “Standby” command to the drive. Make sure that the spindle motor has stopped and swap the electronic board from the donor HDA to the HDA containing corrupted service data; do not disconnect IDE and power cables.

Attention! Please exercise extreme caution because the board is live during the swapping procedure!

After successful hot swap use the “Service” menu to send a “Recalibration” command to the drive and ensure that it has started the spindle motor, reached readiness properly and the “ERR” indicator is off.

Then you can try to read the data.

Please keep in mind that after drive power-off and for some models even after hardware reset command you will have to repeat the HOT SWAP procedure described above.

To avoid that when possible, you should modify the scenario of program behaviour at loss of readiness – remove the power-off tracking option and hardware reset, if necessary.

As the last note please remember that service data get corrupted for no reason extremely rarely. Usually its corruption results from BAD blocks appearing in service area and, as a rule, in data area, too. In such a situation the time required for recovery and respectively its cost may increase significantly – you may wish to notify your customers about that.

Therefore you should consider the possibility of such situation while making an agreement with customers regarding the time and cost of data recovery.

5.3 Data recovery using Data Extractor UDMA. As we have already mentioned, the problems encountered during data recovery are very diverse. However, we

can subdivide them into three groups of cases.

The first group represents cases, when a drive is damaged, but reports on readiness and has no data shifts (the translator is functional). It includes multiple BAD sectors, possible malfunctions of magnetic head assembly or data read channel. Hard drives with a replaced MHA or disks also fall into that group. In general, it covers all situations when users experience problems with data reading (including loss of readiness and knocking sounds).

The second group consists of cases when the system that coordinates logical block addresses (LBA) with actual physical HDD geometry (including the system of defective areas accounting) becomes damaged for whatever reason. Here belong cases of direct translator corruption (Quantum drives) as well as situations, when data are read from a drive made ready during a “HOT SWAP” procedure so that it uses for its operation a translator borrowed from another functional drive. In other words, those are cases when shifts in data placement are encountered (please note that in the first case only data shifts forward are possible while in the second case shifts backwards may also occur).

The third group includes all cases of damaged logical data structures. They may result from erroneous user actions, software or power supply failures or from interference of various virus programs. We mean here just regular data storage, not RAID arrays.

These three groups of data recovery situations define three existing types of tasks (currently) accomplished during application of our suite:

− Creation of a data copy from a malfunctioning drive

− Data recovery in case of a corrupted translator

− Data recovery in case of damaged logical structures.

Of course, the classification is fairly general and completely unpredictable case combinations are possible (and rather frequent).

Thus, in case of physical failures very often serious (or minor) logical corruptions follow.

Sometimes it happens that operation of partition management program causes a situation identical to translator corruption. There were some cases when interrupted operation of Partition Magic resulted in a shift of some data.

Depending upon the situation you should set the options during task creation in such a manner as to make the data recovery work as easy as possible.

The guidelines are as follows:



− If a drive is functional there is no need to enable the Make data copy option. It would be reasonable to connect it to the standard motherboard port to achieve maximum throughput rate.

− If a drive is malfunctioning, the Make data copy option must be enabled. Decide whether you will create a full copy or a background copy in the Explorer mode depending upon the degree of physical and logical damage and upon the volume of data, which have to be extracted.

− If a drive has translator problems, the option to Create virtual translator should be enabled.

5.3.1 General methods and settings in case of physical damage. This section describes general methods and task settings necessary to create a copy of required user data from

a malfunctioning drive.

You are advised to work with malfunctioning HDD using the PC-3000 UDMA board ports only (ATA0 and ATA1).

If a drive is malfunctioning, the option to Make data copy must be enabled while creating a task for data recovery from it.

Figure 173. Selection of the Make data copy option in recovery task settings

If you are recording a copy to drive connected to one of standard system ports, you may encounter certain problems pertaining to the OS actions affecting the resulting data copy. E.g., you can successfully transfer MBR and boot sector from a malfunctioning drive to the target one (connected to standard port) but then the OS can detect that partition and attempt to mount it possibly changing some data (in that case you should use the Modify MBR method, please refer to section 4.4.5 for details).

5.3.1.1 A drive with defective sectors but without knocking sounds during work.

It makes sense to copy data in two or more passes:

1) A quick pass without stops to retry reading of sectors that cause errors with a minimum number of reading attempts. The Skip sectors on reading errors option is possible; it can be combined with a jump setting to be used if errors are encountered. The pass is intended for copying of the main easily accessible data part for fear that a drive may cease functioning. Variation of reading commands is possible.

2) A refining pass with a greater number of attempts to read defective sectors (depending upon drive condition), the Skip sectors on reading errors option is disabled, the size of on-error jump is equal to one sector. Please note that considerably increased number of reading attempts makes sense only for a drive, which demonstrates unstable reading. It is useless when a drive reads unreliable information from defective sectors. Sometimes you can enable the Read, ignore CRC option for time economy.

All subsequent passes make sense for specific areas only (metadata, files, folders).

5.3.1.2 A drive failing while reading defective sectors.

The recommendations provided for such drives are identical to the previous case (i.e. reading in two or more passes).




One exception – you could use a script to define program actions while reading a defective sector. The script structure depends on drive behaviour. Basically a software reset or hardware reset should suffice. Sometimes a power-off is required.

Please note that a drive will only be powered-off in the software and hardware resets fail. A situation is possible, when a drive reaches readiness after a software/hardware reset but then starts reading all sectors with an error. In that case, you should leave in the script just the power-off and use no software or hardware reset.

5.3.1.3 A drive that has problems reading servo labels and produces knocking sounds.

The recommendations for the first case apply here, too. But the script of program actions by all means should include the Power switch off option, which must be used at readiness loss.

5.3.1.4 Imitating readiness loss.

Sometimes attempts to read defective sectors consume a lot of time (the program tries to read a block first and if the attempt fails, proceeds to sector-by-sector reading). That may be unacceptable if the number of such sectors is too high. Besides, the necessary data frequently do not match the damaged areas.

Of course, you could specify jump size to use upon a reading error and jump over the damaged sectors, but the time wasted for a single attempt to read a defective sectors may still be too long. In that case you can try imitating the loss of readiness by the drive setting the timeout in such a way that normal sectors get read without problems but a slightest slowdown triggers loss of readiness and a jump respectively. The timeout can be set to approximately 0,2-1 second depending upon drive behaviour. It is advisable to remove from the scenario used at readiness loss all unnecessary records, especially power-offs. A software reset is usually sufficient.



Figure 174. The settings for imitation of readiness loss

When the data accessed without problems are copied, you should disable the Skip sectors at loss of readiness option in the task parameters and restore the initial timeout value.

Then act according to the circumstances or use the Explorer to extract data or try the second pass to read the defective areas more thoroughly.

5.3.1.5 A drive with magnetic head assembly problems.

The problem manifests itself as follows: long zones of successful reading regularly alternate with zones, which either cannot be read at all or produce errors while reading .

For a HDD with such problem you should build a heads map, if possible, selecting the reading heads. Then use the Explorer mode and try to access the required data (you should disable read-ahead HDD mode to avoid accidental attempt to use a damaged head). If you cannot access the data (some of it belongs to the area read by malfunctioning heads), first copy the information from the functional heads and only then try reading from the remaining ones (perhaps even after MHA replacement).

If you cannot build a map of heads (the algorithm does not work) use jumps on HDD readiness loss (perhaps, you will not even have to imitate it, but you can minimize the waiting time) or jumps on reading error to bypass the zones corresponding to inoperative heads. Select the jump size so that you can cross the zone corresponding to a malfunctioning head in 1- 2 jumps.

As soon as the copy is created, you may proceed with logical structure recovery but you will be working with a copy instead of a damaged drive.

5.3.2 Using Explorer for work with a malfunctioning drive. During work with a malfunctioning drive (lots of BAD sectors, malfunctioning MHA …) in many situations a

full copy is not required to recover the necessary user data. Quite often selective reading of the required data is sufficient. To do that, you should use the Explorer mode and auxiliary modes, such as GREP search, Object map, View and edit sector, etc. Below we describe specific situations and methods that allow you to decrease considerably the load on a malfunctioning drive and the time required for data recovery.

MBR, boot sectors of partitions, FAT and MFT (for FAT and NTFS partitions respectively) contain the most essential metadata necessary for recovery of user data.

E.g., if MBR is damaged physically, it makes sense to rebuild it (filling in the information about partitions) and quickly obtain access to data. The same is true for boot sectors of partitions (see the section 4.7.3 Explorer mode, Mode peculiarities subsection, examples 1 and 2).

With FAT partitions you can use Partition analysis (for FAT file system) to find automatically data that is lost or inaccessible for whatever reason. Correct application of that method requires a valid partition boot sector (clustering beginning, cluster size) or a virtual boot sector. Please refer for details on that mode in section 4.8.6 Partition analysis and its Mode peculiarities subsection.




When dealing with NTFS partitions with a problem both in the initial 4 MFT records and in MFT Mirror, it makes sense to use a partition map to assemble one valid copy of the 4 initial records from two partial ones.

Scan MFT if that is possible. It is the fastest method (if the data do not appear in Explorer immediately) to build a virtual file system and gain access to the required data. MFT occupies approximately 10% of partition space and so to recover, for example, 1 Gb of data you will not have to copy everything, which may be a difficult or even impossible task in case of serious physical problems (for details please refer to section 4.8.7 MFT scanning).

In general, serious logic parsing is recommended after copy creation on a functional drive.

For NTFS partitions the program supports a completely automatic mode (see section 4.8.8) intended for parsing of analysis of complex damage (it is available from the right-click menu of the drive, MBR slot, boot sector objects in the Explorer mode). One considerable drawback of the method is in the necessity of complete reading of the scanned data area and long complicated analysis. On the other hand, its advantage is in high efficiency (including the situation when a drive was reformatted and a lot of data was overwritten after that).

With FAT, NTFS and HFS+ partitions that have no main boot sector but have its copy, the program will use that copy automatically for data access. Thus, if DE allows access to the required data using a copy of the boot sector and you need to copy the data to a functional drive, copy the data. If you decide to restore the HDD functionality (assuming there are no other problems or you are going to address them too), then you should copy the boot sector in binary editor and overwrite the master sector; then the OS will be able to see the corresponding partition (an example of such case for an NTFS partition can be found in subsection 5.3.2.2).

5.3.2.1 Restoration of MBR and boot sectors.

On FAT partitions with corrupted MBR sector, boot sectors of partitions and their copies, but FAT tables are valid and partition data are not damaged seriously, you can reconstruct the MBR sector and boot sectors manually. Such case is described in detail in section 4.7.3 Explorer mode, subsection Mode peculiarities subsection, examples 1 and 2.

With sufficient experience, you can also reconstruct boot sector of an NTFS partition. However, in most cases one of boot sector copies remains available and further we shall discuss a few such cases and appropriate solutions.

5.3.2.2 Valid MBR, corrupted boot sector of a partition.

1) In Explorer mode go to the MBR slot object of the corresponding partition and then use its right-click menu to switch to the Map mode.

2) Go to the last sector in a partition chain.

3) Double-click the square on map to open the binary editor and copy sector content to clipboard (it is a copy of the boot sector of NTFS partition).

4) Return to map and go to the first sector of the partition chain (it is the corrupted boot sector).

5) Open it in binary editor and overwrite its content.

6) Return to the Explorer mode and rescan MBR slot.

5.3.2.3 MBR corrupted, boot sectors are valid.

For such cases Explorer features automatic Quick disk analysis mode intended for creation of a virtual table of partitions based on found boot sectors in cases, when MBR is inaccessible (please refer to section 4.7.3.3 for details). If the mode is unable to build a virtual table of partitions and for general information we provide below two examples of manual procedure for restoration of MBR slots. It may also be helpful if only MBR sector is damaged on a drive and so its restoration will produce a completely functional drive will all data and OS.

The next example illustrates a situation when MBR slots are corrupted on a drive that had several NTFS partitions.

1) In Explorer mode go to the MBR object and use its right-click menu to invoke its Properties. Use the window that opens to edit slot 0: in "Partition type" column enter 07 (NTFS partition), in the "Initial sector" column specify 63 (in 99% cases when the assumption is incorrect you can try searching for the boot sector manually because it is easily recognizable or in the GREP search mode), in the "Sectors" column you can enter any number though properly it should be read from the boot sector (load the boot sector into binary editor and choose "View as…→ NTFS partition Boot", "TotalSectors" field).

2) Save the changes.



3) Rescan the tree and receive access to the data of the first partition.

4) Use the "Partition map" mode for the boot sector of the first partition.

5) Go to the last map sector (copy of the NTFS partition boot sector).

6) Double-click the square on map to open the binary editor and go to the next sector. It will be either boot sector of the next partition or EPR (which you can easily identify by its content).

7) Copy to clipboard the sector number and still in binary editor go to 0 sector (MBR).

8) In "View as…→ Partition Table" mode write to the partition type column of slot 1 either 07 (if a boot sector was found) or 0F (for EPR), substitute in the "Initial sector" column the found sector number, etc. thus repeating the described procedure to fill MBR slots depending upon individual drive organization.

5.3.2.4 MBR is corrupted and boot sector of the first partition is missing.

1) Look for the copy of the boot sector of the second partition in drive end minus 20000 sectors.

2) Then open it in binary editor and choose "View as…→ NTFS partition Boot" to obtain the partition size from the "TotalSectors" field.

3) Use calculator to find the number of the first partition sector (sector number of the found copy – "TotalSectors").

4) Substitute the resulting value into one of MBR slots (type - 07, size – "TotalSectors").

5) Rescan the tree to receive access to the data of the second partition.

6) Use "View the first sector" command for the found boot sector and go to the previous sector. Most likely, you will find a copy of the boot sector of the previous partition. If it is so, use the clipboard to transfer its content to the partition beginning (in 99% cases it is sector 63) and repeat the procedure described above for another MBR slot. If you do not find the boot sector copy, then the second partition was most likely to be in EPR and the boot sector copy is 63 sectors further.

If you are not sure, if you are just practicing or if you do not wish to write to user drive or cannot write to a malfunctioning drive, work in the task with the data copy creation option enabled (it allows as much experimenting as necessary), or modify the virtual boot sector.

5.3.2.5 Recovery of partition metadata.

Suppose that MBR sector and boot sectors of partitions have been copied from a malfunctioning drive or reconstructed correctly.

5.3.2.6 Recovery of FAT partition metadata.

While working with a malfunctioning drive, for FAT partitions it is necessary to read FAT copies first of all. The best way to do that is the partition map mode for the boot sector object.

Use the partition map to check locations of FAT copies. If they are in place, select them in the table of chains and run the "Scan selected chains" command (if the copies are not in place, then the translator is corrupted or boot sector was read with errors). While scanning FAT copies using the map, estimate the amount of damage (i.e. the number of unread sectors) and define stricter reading parameters, if necessary (increase the number of attempts or use various reading commands).

If you succeed in reading one of the copies without errors, you should switch to it in the right-click menu of the boot sector object using the "FAT copies…" command. If defective sectors are present in both FAT copies, you can choose "FAT copies… → Comparison and correction of FAT copies taking into account defective sectors". The method is available in copy creation mode only. As a result, it replaces in each copy the defective sectors with ones read from the other copy provided they have been read without errors.

5.3.2.7 Recovery of NTFS partition metadata.

While working with a malfunctioning drive, for NTFS partitions it is necessary to read MFT first of all. The best way to do that is the partition map mode for the boot sector object.

Use the partition map to check locations of MFT, MFT Mirror and boot sector copy located at partition end. Then it is recommended to read MFT (or rather its 4 initial records describing the table or their copies). To do that, highlight it in the list of chains and select "Scan selected chains". Then switch to the "MFT map" mode and read the




remaining table part. While scanning using the map, estimate the amount of damage and define stricter reading parameters, if necessary (increase the number of attempts or use various reading commands).

The resulting number of defective sectors provides reliable information for an estimate of metadata corruption. The more successful MFT reading has been, the higher is the probability that you will receive access to the necessary dat. Successfully read MFT provides information about data attributes and their locations. However, information about the placement of a necessary object does not guarantee its successful copying in future. After MFT reading you are advised to run "Scan MFT". As a result, the program will build in Explorer a virtual file system tree described by the selected MFT.

5.3.2.8 Recovery of Ext2(3) partition metadata.

While working with a malfunctioning drive, for Ext2(3) partitions it is necessary to read the superblock (counterpart of the boot sector), table of group descriptors and the table of index nodes. If the superblock is missing, you can replace it with a copy. Superblock copy is usually present in every group of blocks; it can be found by the 0xEF53 signature in bytes 56-57 (unless the «sparse superblock» option is enabled). In addition, every group of blocks includes copies of the group descriptors table (the table of group descriptors contains descriptors for all groups). Once you have obtained the superblock and the table of group descriptors, you should read as thoroughly as possible the table of index nodes containing subtables for each group.

5.3.2.9 Recovery of UFS1(2) partition metadata.

While working with a malfunctioning drive, for UFS1(2) partitions it is necessary to read the superblock (counterpart of the boot sector), group descriptors and the table of index nodes. If the superblock is missing, you can replace it with a copy. Superblock copy is usually present in every group of blocks; it can be found by the 0x011954 signature in bytes 1368-1371 for UFS1 and the 0x19540119 signature in bytes 1372-1375 for UFS2. In addition, every group of blocks includes a group descriptor containing the structure description for that group (all group descriptors are identical, so to restore access to data even one of them will be sufficient). Group descriptor can be found by the 0x090255 signature in bytes 4-7 of the appropriate sector. Once you have obtained the superblock and the group descriptor, you should read as thoroughly as possible the table of index nodes containing subtables for each group (using the partition maps or metadata).

5.3.2.10 Using the map of occupied sectors.

When you are recovering data from a partition that has not been reformatted (i.e. partition metadata address the required information), you can save considerable time compared with creation of full copy if you copy just the part of the partition occupied with data. Then you do not have to waste time reading empty space, which may contain quite a lot of defective sectors. You can build the map of occupied space using the "Used sectors map" command available for the boot sector object in Explorer.

For FAT and NTFS partitions the map of occupied partition space will be built using the active copy of FAT or $Bitmap respectively.

Figure 175. Building the map of occupied sectors

Having built the map of occupied sectors, you should read all chains of the built map by pressing the Run button, or select all chains and use the right-click menu of the chains table to choose the "Scan selected chains" command.



Figure 176. "Used sectors map" mode

As a result, the program will attempt to save to the copy the part of the partition actually containing user data. Since the program uses in the map mode all task settings (including retries), scanning can be performed in two or more passes (a quick pass with imitation of readiness loss and refining passes with a large number of reading attempts and various reading commands).

Having recovered thus the partition data you can switch off the malfunctioning drive and continue work with the created copy.

Maps of occupied/unused space can be built for FAT, NTFS, HFS+, Ext2(3), and UFS1(2) partitions. In case of UFS1(2) partitions the map can be built for blocks and fragments (a block consists of fragments, consequently the map of occupied /unused space for fragments is more precise but its creation requires more time).

5.3.2.11 Selective data saving in Explorer using the directory and object maps.

If during data recovery you know exactly where the necessary information is located, you can use the Explorer mode to attempt unfolding of the directory tree to the necessary folder.

If you cannot unfold the directory tree to the required folder, you should try reading the partition metatada

Having obtained access to the required directory, you can try to copy the necessary files. If you are working with a malfunctioning drive, the Save and Save marked methods support interruption of copying for files with reading errors (because some file types cannot be opened if they are copied incompletely). If the map of drive heads has been build and some of them were marked as disabled, then if a sector turns out to be associated with such head during file saving it will be interpreted as an error.

If some data could not be copied in Explorer, you should switch to the "Map of folder" mode, select the corresponding data chains and finish reading them with more thorough parameters (increased number of read attempts and various reading commands). Upon creation of a folder map, all data of that directory will be placed in the copy being created. Apart from the folder map, you can recover data using the map mode for a specific file.

5.3.2.12 Using the heads map to recover data from WD drives .

During work with malfunctioning WD drives you may encounter a situation when regular reading methods cause a drive to start knocking. The problem can be solved as follows. You will have to build the heads map for such drive and use specialized utility to disable read-ahead caching and automatic relocation of defects. Then you can




retrieve all data from WD drives using sequential reading for magnetic heads (i.e. you should select in the "Parameters" window the first head and read, then the second, and so on), then the drive does not begin endless knocking.

Figure 177. Selecting the heads for reading in sequence

5.3.3 Data recovery in case of translator corruption. First of all, users should understand that the mode is not intended for translator regeneration but rather for

gaining a temporary opportunity to retrieve data from a drive where the system of coordination between logical disk space (LBA) and physical HDD geometry somehow became defective.

It may be a case, when the service modules of translator proper got corrupted. However, a similar situation may occur, when data have to be copied from a drive using the HOT SWAP method (e. g., data from a security locked drive).

While in the first case up to 100% of data may be recovered, in the second situation losses are likely because you will have to use a borrowed translator, so some data may become inaccessible or lost.

Basically, there are two approaches to the task: you can identify the shift points and restore the native drive translator or having identified the shift points you can use software simulation of translator activity.

The first approach is not universal because it requires deep knowledge about a specific drive model. Besides, sometimes it is impossible to create a new translator without data loss.

The second approach is universal, so it has been selected for our application.

However, the approach also has a considerable drawback for it requires certain knowledge of the organization of file systems being restored. Therefore, when speaking about translator creation using Data Extractor UDMA, we mean FAT, NTFS, HFS+, Ext2(3) and UFS1(2) partitions.

Currently the suite includes a manual interactive implementation for data recovery and automatic recovery for FAT and NTFS partitions (please refer for details to sections 4.7.4.3 Methods for automatic searching and addition of shifts for FAT partitions and 4.7.4.7 Virtual translator creation for an NTFS partition).

A few more recommendations before we describe the mode and data recovery methods:

− If you are planning to recover data from a drive using HOT SWAP, the best way is to copy the data first to another functional drive and only then proceed with the recovery.

− It is advisable to disable automatic relocation of defects in drives, which support the feature. Otherwise you will be looking for ghosts, after reading a defective sector the drive will hide it (or a whole track) and the situation will change drastically.

− If you cannot comply with the requirement, copy all data to a functional drive. Automatic defect relocation will occur, but the resulting situation will be stable. Of course, data losses are possible in that case.

− Recording of an empty translator is the best method, when it is possible and not likely to cause data corruption.

These recommendations are based on the understanding that in Data Extractor UDMA the task of translator recreation is purely logical. While it is being performed it is preferable to have access to all drive data (to avoid losses of information), data structure and their position should not change.

To follow the recommendations connected with the specifics of an individual drive (disabling automatic defects relocation, etc.), use the PC-3000 suite or similar tools.



There is one separate case, to which the suggested method does not apply. It includes situations, when translators in Western Digital or Fujitsu drives become damaged. Then you will have to use the PC-3000 suite to restore the translator right in the drive, because those HDDs do not allow logical recovery while the translator is corrupted.

The only difference in mode appearance from Explorer is in the table of detected shifts displayed in the left part of the workspace (see the figure below). For detailed mode description please refer to section 4.7.4 Virtual translator creation.

Figure 178. Modified visual Explorer mode during translator regeneration

5.3.3.1 Meaning of negative shifts and data "collapse".

In cases when you need to read from drive data using the HOT SWAP method, losses of data ("collapsing") are possible because a borrowed translator is used and so negative shifts can appear.

Lets us explain that using an example. Suppose that we are dealing with an original drive containing a FAT32 partition; therefore the boot sector of the first partition has LBA 63, its copy – 69. HOT SWAP method was used to access the drive. Assuming that in the defect list of the borrowed translator sector 63 is marked as defective. Consequently, "collapsing" has occurred and access to sector 63 of the original drive cannot be obtained, while sector 69 becomes 68, i.e. in the table of shifts for the boot sector copy the shift equal to – 1 should be entered.

5.3.3.2 Translator regeneration for FAT partitions.

A drive has two FAT partitions, but Explorer has not discovered even its MBR.

Users should remember two things. In the first place, all data remain on disk and if the shifts map is prepared correctly, all data will be accessible within the Explorer. Second, the final shift grows from drive beginning to the end. To avoid searching for a shift taking hundreds of sectors, you should create the map sequentially, each time making sure that the points appended to the map added the right corrections (use the scanning method for the corresponding objects in Explorer).

In other words, the procedure is as follows: − Find on the disk a structure with position (view initial sector) does not match the required.

− Identify the number of sectors by which the required structure is shifted.

− Add the point to the map of shifts.




− Make sure that the situation has been resolved.

For map creation the following data can be used: structures typical for a file system and files with a clear signature in the beginning.

Thus, you can identify the shift size using your knowledge about: − MBR − boot sectors − FAT copies (in case of NTFS partitions, MFT and MFT Mirror) − directories − Files: WORD, EXCEL, ZIP, RAR, EXE, DLL, etc.

The list can be considerably extended with proper user qualification and experience.

In future it is important to understand that if you have found two points shifted by the same number of sectors then the data within the range delimited by those points can be considered reliable and used, because you know the shift necessary to access them. If the shift between two points has changed (apart from a specific BAD sector, which has caused the shift), then you should proceed with caution trying to work with the data located within such two points.

Thus, the more shifted points you find and add into the map, the less will be the number of data areas with an unidentified shift.

Let us get back to our example.

The absence of objects corresponding to MBR slots in the Explorer means only that MBR position does not match the required (0 sector) assuming that the translator is native and no “collapsing” has occurred; so use the shift control buttons (forward/backward) and sector viewing window (HEX tab), to discover its new position (2 last bytes are $55 $AA).

Let's assume that it is sector 2. It means that the sector 0 is actually shifted by 2 sectors forward, so now it is time to switch to the map of shifts and add the first point for LBA = 0 with shift 2 (the “Add shift point” button in the upper right corner of the HEX panel).

Figure 179. Adding a shift point

Then launch the “Scan” method for the drive object. The Explorer will display objects corresponding to MBR slots.

Then it's time to pay attention to the list of objects in the right Explorer frame, you see that the first partition should start with sector 63 and the second presumably with sector 4 000 000.

Figure 180. Explorer window containing two partitions

Now we should try to unfold the first partition within the Explorer.

If the attempt fails, we should seek the first boot sector (manually or in the shift point search mode). For the boot sector search you can use the map mode of the "MBR" object. After switching into the map mode, you will see in the chains table the chains of drive partitions. Double-click the first partition to switch to it, then the program displays the first partition sector (boot sector). If the sector displayed in HEX window is not a boot sector of the partition, use shift control buttons to find it and add the appropriate shift point (the shift point should be added even if the boot sector is in place). For details on the map mode use see the section "Using an object map during translator rebuilding". If you find, for example, that the boot sector of the first partition is shifted by another two sectors, add that new point to the table of shifts.

Please note that if the map contains points with LBA smaller than the one being inspected, their shifts are already taken into account. It means that in the current example the boot sector of the first partition is actually shifted by 4, not by 2 sectors.



That is very convenient because during successive map checking from the beginning to drive (partition) end we shall not encounter very large shifts because each new map point enters correction for all sectors with the same or greater LBA.

If the point has been added correctly then rescanning the object in the first MBR slot will make the boot sector of respective partition (FAT in our case) appear as a tree object.

Then you should check FAT copies. To do so, you can open the partition map accessible from the right-click menu of the "boot sector" object in Explorer. In that mode you can place properly the starting locations of FAT copies and the root directory. Unfortunately, FAT root directory has no remarkable signature, but data represented as text can be easily recognized, even more so because typically it is preceded by the last sector of the second FAT copy (usually filled with $00).

Then you should make sure whether the area containing FAT copies is identified correctly (and whether it contains shifts). If at least one copy is reliable, you can make it active and skip the other one. If both copies raise doubts you should launch automatic searching for shift points within FAT copies. After the procedure completion you should check the root directory location.

If you are working with a source drive with zero translator, the feature for seeking BAD sectors (using verification) implemented in the suite may come handy. Perhaps, discovered BAD sectors are the sought shift points. E. g., if a sector range where the 1st (2nd) FAT copy is located demonstrates a shift by 2 sectors and verification of that range reveals exactly 2 defects, then most likely this is your target. The problem is in the fact that the situation is not always so obvious. E. g., you may observe a shift by 4 sectors while verification may reveal two defects only. That can be explained by unavoidable differences in BAD sector definitions used at the manufacturing factory and in our verification process. In that case you have to look for the shifted sector manually. An alternative variant would be in the comparison of two copies based on the assumption that they should be identical (unfortunately that is not always and not completely so). As a rule, that is not required because the automatic shift search in FAT copies is quite efficient and reliable.

Note! Folders validity control method should not be used in restoration of FAT partitions because during initial stage of virtual translator generation the required directory can appear outside the required location because of shifts.

After you have obtained the shift points for FAT copies in automatic mode or you have switched to one of the copies, which has no internal shifts, you can use automatic methods to search shifts for directories and then for files (for details please refer to "Methods for automatic searching and addition of shifts for FAT partitions").

Seek shift points for FAT subdirectories method is based on a very useful property of FAT directory, which contains information about its location (cluster number) that allows you to identify its shift relatively to the expected position. You can only use that mode provided that the root directory is in place considering the shifts added earlier. You can use the method several times in sequence.

Seek shift points for files method is recommended after shift search for directories only. That is so because the search for file beginning is signature-based and files contain no information about their locations. Hence the next requirement – to avoid specifying too large search depth, otherwise if several files of the same type are located closely, errors in identification of their real positions are possible resulting in addition of wrong records to the table of shifts. The method can also be used several times in sequence.

In manual mode, you have to identify the shifts map step by step using Explorer features and knowledge of signatures (directories and files).

In general, the procedure is as follows:

1) Open the root directory (further - the required subdirectory) on the tree.

2) Arrange the list of child objects in the ascending order of their initial sector number (previous shift affects the sectors following it). By default that is exactly the ordering used in the list for the translator regeneration task.

3) Navigate the items of that directory in the list of child objects and if you find a suitable object (recognizable beginning signature or evident and clear data structure (text file)) use the HEX tab to check whether its beginning is in place.

4) If a shift is detected, identify its size navigating the sectors or using the shift search mode, and add it then to the shifts map.

After shift addition the changes to the table are immediately taken into account for the current object.




You should add all identifiable points: those, which arrived in place after a shift and those, which turn out to be in place taking into account the preceding shifts. Such step improves the quality of data recovery since it increases reliable sector intervals. The more points there are, the better.

If after copying you discover that there are still problems with some individual files, it means that either a shift has occurred within a range of sectors occupied by a file (or its part) or file parts (remember about fragmentation) fall into an area with a shift, which has not been identified. In that case you should use the map for an individual object to see how it is placed on disk and compare the data with the shifts map. Then make a correct decision (where the shift is and how large it is), correct the map and copy the file again taking into account recent changes.

You will have to do the work for precise identification because frequently the type of file being recovered is so unusual that you have no tools at hand to check its integrity. We recommend keeping the map of shifts as long as you continue working with that drive.

The methods for recovery of the following partitions are identical to the description above.

5.3.3.3 Translator regeneration for NTFS partitions.

For NTFS partitions the suite offers the automatic mode Create virtual translator for NTFS partition searching for shifts. The mode is available from the right-click menu of the "MBR slot" Explorer object.

During the procedure the program performs the following operations: − Seeks for the boot sector and identifies its shift − Seeks the boot sector copy and identifies its shift − Seeks partition metadata (MFT and MFT Mirror), then builds MFT map and identifies shift points for the

table records − Uses the found metadata to search in several stages for file shifts (with varied search parameters and

narrowed depth of possible shifts).

As a result, the Explorer displays a virtual partition with data arrangement obtained using the shifts table (you may have to edit the shift points for some files in manual mode). For manual checks and correction of the found shift points of non-resident files the List of non-resident files is used.

Please refer for details to section 4.7.4.7 Virtual translator creation for an NTFS partition and its subsection Limitations of the method.

In case of manual translator restoration for NTFS partition, the procedure is as follows:

1) Use the MBR or EPR map to place properly the boot sector of the required partition.

2) Rescan the "drive" object.

3) Use the partition map to place properly 4 initial MFT records, their copy (MIRROR) and boot sector copy located at the partition end.

4) Rescan the file system object.

5) Use the MFT map to place properly МFT chains (keep in mind that with cluster size equal to 1 sector a chain may start with a signature other than “FILE”!).

6) Clear the table of results.

7) Rescan MFT.

8) Seek and add shift points for files (resident files have a “FILE” signature while non-resident are as usual) and folders (resident directories have a “FILE” signature while non-resident are “INDEX”).

9) Clear the table of results again.

10) Rescan MFT again.

11) Copy the data.

The approach is identical for LINUX partitions: first the superblock should be put into place, then the groups and then precise adjustment for files and directories follows.

All the descriptions of the suggested data recovery methods in case of a corrupted (or borrowed) translator lead to an important conclusion: success does not depend upon your tools only, but also on your experience, professional skills and intuition.



If you are just beginning such work, you can check the data structure for a relevant partition type on an functional drive. Thus you will receive the experience of quick visual identification of recognizable data structure signatures.

5.3.4 Data recovery in case of logical damage. This task suggests using the Explorer and other auxiliary modes (search, viewing and editing of data in a

specific sector), that allow to retrieve, view and, when necessary modify the information about the data structure on connected HDDs.

Data should be modified especially careful, when you do not have a copy since you are recording to the only data source.

However the drawback sometimes may be advantageous – you can fix small corruption rather quickly (MBR, boot sector) and then use the Explorer to check the integrity of the data structure thus produced, connect the drive to a standard port and copy the required data from it using standard tools. Some restoration examples for MBR and boot sectors can be found in the "Restoration of MBR and boot sectors" section of this manual.

If you are really concerned about the safety of the source data or you are not quite sure and wish to check your assumptions, you can use Explorer features on a data copy provided that you have enabled copy creation. In that case you can interactively edit the copy being created, achieve structure restoration and having received necessary results proceed to copying via the Explorer the data required by your customer leaving to the latter drive formatting and OS reinstall procedure. You do not have to copy the whole drive contents (in the Explorer mode the program reads the required data only).

For the boot sector Explorer object there is another opportunity for experimenting leaving safe the original data, i.e. creation of a virtual boot sector. A virtual partition is an artificial partition in the Explorer mode produced as a result of boot sector creation in task database (without data recording to the drive being examined). After creation of such artificial boot sector a new partition of the type selected during creation appears in Explorer and has the parameters defined by that boot sector. Unlike virtual partitions created by automatic data recovery modes (e.g. Partition analysis), for a manually created virtual partition the program supports all methods available for regular partitions. If necessary, you can save a virtual boot sector to disk. For details on the use of virtual partitions please refer to the description of the Explorer mode and example 1.

There is another opportunity for creation of a virtual boot sector provided in HEX editor or rather its View as…/ Boot … mode. In that mode the program supports the Service → Add virtual partition method, which allows fast access to the required data if you find the boot sector of a partition or its copy (in manual mode or using GREP search). While adding a virtual partition using that method, the program checks whether the boot sector is the first or the second copy based on the partition metadata and suggests an appropriate variant. If partition metadata cannot be found using the information from boot sector, the operator will be offered to choose manually which boot sector copy he is dealing with. Besides the View as… / Boot … mode can be employed to estimate easily whether the found sector is actually a boot sector, because the program checks essential fields during the procedure highlighting invalid data with yellow background. As an example, the figures below demonstrate the boot sector windows during addition of a virtual partition and an invalid boot sector.




Figure 181. Adding a virtual partition

Figure 182. Invalid boot sector

Peculiar methods of logical structure recovery in the Explorer mode are provided for each file system; the methods can be invoked by commands from the respective context menus of Explorer objects.

Descriptions of those methods and examples of their application in some specific cases of corruption in the logical data structures can be found in the sections containing reviews of each individual mode.

5.3.4.1 Using the map of unused sectors.

In case of purely logical corruption you can use the "Unused sectors map" mode combined with the copy creation mode to improve parsing quality in certain cases. E.g., if a partition that a user needs has been reformatted and metadata of that partition is intact, you can build the map of free space. Analysis of used space in such cases makes little sense because it belongs to new partition and the data being recovered can only remain in unused partition area.

Thus, you have to build the map of unused sectors, select all chains and invoke the "Scan selected chains" method from the context menu of the chains table. If you have already made a full copy of the partition being restored, you can enter the "Used sectors map" map, select all chains and clear them.

As a result, having obtained the map of unused partition sectors, you can disable the drive being restored and continue work with the created copy.

For all file systems supported in DE you can run the Raw recovery and GREP search modes with the unused space map. For NTFS partitions you can use the automatic Scan unused space mode (for details see section 4.8.8).



6 Reference. 6.1 Master Boot Record and partition table.

Information about drive structure (partition table) is stored in the Master Boot Record (MBR). MBR is located at cylinder 0, head 0, sector 1 (in LBA addressing mode it is the zero sector). Sector beginning contains the master boot program, it is followed by a partition table containing four partition descriptors. Every descriptor defines partition boundaries in two notations: CHS and LBA. In addition to partition boundaries, a descriptor also defines partition attributes, i.e. the system code and the flag of active partition. The flag of active partition tells master boot record, which partition it should use to boot. The active partition flag can be set for one partition only on a drive (or for none). System code determines partition type; an operating system can use as its file system only partitions of the type that it recognizes.

The MBR structure is as follows: − bytes 000h – 1BDh – boot code for the boot sector of an active partition − bytes 1BEh-1CDh, 1CEh-1DDh, 1DEh-1EDh, 1EEh-1FDh – partition descriptors (Partition Entry), 16-

byte structures (see Table 1) − bytes 1FE = 55h, 1FF = AAh –MBR signature (word AA55h).

Table1. Partition entry structure

Offset Length, bytes Purpose 00h 1 Boot Flag – active partition flag: 80h – active, 00h – none 01h 1 Begin Head – first head number 02h 2 Begin SelCyl – the number of the initial sector and cylinder 04h 1 System Code – system code (see Table 3) 05h 1 Ending Head – last head number 06h 2 Ending SelCyl – the number of the last sector and cylinder 08h 4 Starting Sector (Relative Sector) – the number of the initial partition sector 0Ch 4 Num Sectors – number of sectors in a partition

A partition table can be filled both from the beginning and from the end. If the number of partitions is less than four, then free entries contain zeroes. Free descriptors, just like used ones can be located in any part of the table.

Sector and cylinder numbers are stored in two bytes (Begin SelCyl and Ending SelCyl). Bits 0-7 of cylinder number are stored in the second byte while bits 8-9 are stored in higher bits of the first byte. Sector value is stored in bits 0-5 of the first byte.

Table 2. Binary map Begin SelCyl (Ending SelCyl)

Byte 2 Byte 1 F E D C B А 9 8 7 6 5 4 3 2 1 0

Cylinder number Sector number 7 6 5 4 3 2 1 0 9 8 5 4 3 2 1 0

When a drive functions in LBA (logical block addressing) number, CHS (cylinder-head-sector) values for the beginning and final placement positions are ignored. Disk space is displayed using absolute sector numbers and not CHS (cylinder-head-sector) terms. Thus, the relative sector value and partition length are used to identify partition size on a drive. CHS values are impossible on drive larger than 8.4 GB altogether.

Partition structure depends upon its type. Some system codes are listed in the Table 3.




Table 3. HDD partition codes and types

Code Partition; OS in which each type was introduced; file system; volume 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0E 0F 11 14 16 40 52 63 64 65 75 80 81 82 83 85 93 94 A5 B7 B8 C7 DB E1 E3 F2 FF

Unknown (unformatted) partition DOS FAT12; MS-DOS 2.0; up to 15 Mb XENIX root XENIX usr DOS FAT16; MS-DOS 3.0; up to 32 Mb (DOS) Extended; MS-DOS 3.3; up to 2 Gb DOS FAT16 (Big DOS); MS-DOS 4.0; up to 2 Gb OS/2 HPFS or Windows NT NTFS AIX AIX bootable OS/2 Boot Manager Win95 FAT32; Windows 95 OSR2; 512 Mb – 2 Tb Win95 FAT32 (LBA); Windows 95 OSR2; 512 Mb – 2 Tb Win95 FAT16 (LBA); Windows 95 OSR2; 32 Mb – 2 Gb (Win95) Extended (LBA); Windows 95 OSR2 Hidden DOS FAT12 Hidden DOS FAT16 Hidden DOS FAT16 Venix 80286 Microport GNU HURD Novell Netware 2 Novell Netware 3 PC/IX Old MINIX Linux/MINIX Linux Swap Linux Linux extended Amoeba Amoeba BBT BSD/386 BSDI fs BSDI swap Syrinx CP/M DOS access DOS R/O DOS secondary BBT

Partitions with the (01, 04, 06, 0B, 0C, 0E) codes are primary partitions of DOS/Windows. There may be several primary partitions (although old versions of the FDISK utility in MS DOS and Windows 9x allowed creation of just one primary partition). A primary partition contains a single logical drive. The first sector of that logical drive (boot sector) contains the loader and a descriptor of file system type and drive structure.

The figure below demonstrates an example of MBR in binary editor for a drive with two primary partitions the first of which is active. Entries of the third and fourth partitions are zeroed.



Figure 183. MBR example

Please find explanation of the active partition entry below.

Figure 184. An example of an active partition entry

Note (the use of Data Extractor). For convenient reviewing and editing the partition table, Data Extractor offers the form shown in the figure below.

Figure 185. Viewing drive descriptors in the "Partition table" mode

The window can be invoked from the right-click menu of the MBR object in the Explorer mode (the Properties menu item) or in the binary editor using the View as…→ Partition table mode. All table values are editable, the current parameter being edited is shown against light background. Values in the partition table are displayed in decimal notation except for the System and Boot columns containing hexadecimal values.

System code (0Сh – Win95 FAT32)

Active partition flag (80h) First head number (Side =1)

Starting sector and cylinder numbers (Cylinder = 0, Sector = 1)

Final sector and cylinder numbers (Cylinder = 1023, Sector = 63)

Last head number (Side =254)

Number of an initial partition sector (Relative Sector = 0)

Number of sector in a partition (Num Sectors = 18 506 817)

Parameter being edited

MBR signature

Bytes 000h – 1BDh – code starting the boot sector of the active partition

Bytes 1BEh-1CDh – descriptor of the first active partition Bytes 1CEh-1DDh – descriptor of the second partition




Extended partition (code 05 or 0F) serves for organization of an arbitrary number of logical drives. The first sector of an extended partition is identical to MBR (but the loader is missing), it contains an Extended Partition Record (EPR) of the same structure, which has, however, certain peculiarities. The first entry defines a secondary partition assigned for the next logical drive. It contains partition file system code, coordinates of partition beginning and its end (in CHS and LBA). If the logical disk does not occupy the whole extended partition, the second descriptor also has code 05 or 0F pointing at the location of the sector containing the next extended partition record. Other entries are not used (their codes are zero). If a partition contains no free space, the second entry is not used. The same rules apply to the next extended partition record. The chain ends with an extended partition table where the second record contains a zero partition code. The second descriptor in extended tables can only point to the position of the next extended table. A part of extended partition space can remain unassigned. The chain of extended partition records must be contiguous, it cannot branch (only two descriptors are used and the second one can only point at the next table) and it cannot loop (the second descriptor may not point at the same table or the one preceding it in the chain).

Judging by their location on a physical drive, extended partitions are inserted into each other; they are all located in the area described in MBR as EPR. MBR can describe one EPR only.

If extended partition records have code 0Fh, then linear addresses of all records in these tables will be specified relatively to the physical drive beginning .

Figure 186. Extended partitions displayed in the Explorer mode

Four descriptors in MBR are followed by the AA55h (double-byte) signature that marks the sector as a system one. This value is present in every sector of the partition structure (including boot sectors) and its absence may mean a probably damaged partition structure.

Loading the active partition for MBR means discovery of the position of the first (boot) sector of that partition, loading the sector into memory and transmission of control to its beginning. Further actions will be performed by the active partition loader. Prior to loading the active partition MBR checks whether the found partition is the only active one; if it is not, then it stops with the Invalid partition table message. If no active partition has been found, MBR stops with the Missing operating system message. During sector loading from MBR the latter invokes the function for single sector reading and if a drive fails to read that sector without errors, master boot procedure stops with the Error loading operating system message.

6.2 Logical drive with FAT file system.

6.2.1 Logical drive with FAT12/16 file system. FAT (File Allocation Table) file system was designed by Bill Gates and Marc McDonald in 1977. Originally it

was used in the 86-DOS operating system. To allow portability of programs from the CP/M operating system into 86-DOS, it supported earlier adopted limitations for file names. Later 86-DOS was purchased by Microsoft and became the basis for MS-DOS 1.0 released in August 1981. FAT was intended for work with floppy disks smaller than 1 Mb and at first it did not support hard drives. At present FAT supports files and partitions up to 2 Gb.

The structure of a FAT12/16 partition is shown in the table below.

Table 4. The structure of a FAT12/16 partition

System area Data area

Boot sector FAT FAT (copy) root Cluster 2 Cluster 3 … Cluster N

Note! (the use of Data Extractor). The structure of any partition can be reviewed in the Partition map mode available from the right-click menu of the selected partition in the Explorer mode. The mode can be used to:

− Check and correct the position of partition metadata important for data recovery during virtual translator creation (boot sector copies, FAT copies, MFT beginning, etc.).

Extended partitions



− Check the location and integrity of the main partition metadata in case of logical corruption (fast access to boot sector copies and FAT tables).

− When working with a malfunctioning drive, you can select the chains that are most important (e.g., FATs, boot sectors) and read them into a copy using strictest parameters (higher number of read attempts), and estimate the reading quality.

Window appearance in the Partition map mode is shown below.

Figure 187. The “Partition map” mode for a FAT16 partition

Sector 0 also referred to as the boot sector contains a table of drive parameters and the initial operating system loader. First 3 bytes of sector 0 contain a JMP command to jump to the loader start: byte 0E9h with 1 short offset byte followed by a NOP command (code 90h), or byte 0EBh and two long offset bytes. Long offset is used when the loader is located in reserved sectors. Loader is a small program loading the operating system or just its kernel; it can also be a tool for selection of the OS to boot (boot manager). Unlike the master boot record, this loader is connected with its OS and it is written to disk during formatting by that OS.

Then an 8-bit field follows, which is used during format to store the OS version identifier. It is a text string that has the MSWIN4.1 value for Windows OS.

After that there is the BPB (BIOS parameter block), which describes physical disk characteristics and allows calculation of a correct physical address on drive using the specified logical sector number. The table is followed by additional data.

Sector 0 can be followed by additional reserved (for loader) sectors. The total number of reserved sectors, including 0 is specified in BPB.

After the reserved sectors (or right after the sector 0) there is a file allocation table (FAT), and then additional FAT copies may follow. Usually 2 copies are used. The number of copies is specified in BPB.

In the end of the system area there is a root directory, which has fixed size. The root directory size in directory records is also indicated in the BPB table.




Table 5. Boot sector structure

Offset Length Purpose 0h 3h

0Bh 0Dh 0Eh 10h 11h 13h

15h 16h 18h 1Ah 1Ch 20h 24h

25h 26h 27h 2Bh 36h 3Eh

1FEh

3 8 2 1 2 1 2 2 1 2 2 2 4 4 1 1 1 4

11 8

448 2

JMP command to the loader code start OS title, for example, "MSDOS6.0" BytesPerSector – the number of bytes per sector, usually 512 (200h) SectorsPerCluster – the number of sectors per cluster ReservedSectors – the number of sectors occupied by the loader and reserved NumberOfFATs – the number of FAT copies RootEntries – maximum number of 32-byte elements in the root directory TotalSectors – total number of sectors within a volume. 0000 means that the drive is larger than 32

Mb, the number is defined by a BigTotSects dword (offset: 20h) MediaDescriptor – media descriptor (identically to the first FAT byte) SectorsPerFAT – the number of sectors in a single FAT SectorsPerTrack – the number of sectors per track Heads – the number of heads HiddenSectors – the number of hidden sectors BigTotalSectors – the number of sectors (for partitions > 32 Mb) PhysicalDiskNumber – logical device number, the number is assigned during the format process

(80h – the first hard drive) CurrentHead - reserved Signature – extended loader signature (29h) VolumeSerialNumber – volume serial number (set during format) VolumeLabel – volume label (a string) SystemID – character file system identifier (e.g., "FAT16") Loader code area BootSignature – the 55AAh signature (end of the boot sector).

Note! English parameters in this table correspond to the labels used in the program window while viewing a boot sector in binary editor in the FAT16 Boot sector mode.

Note! (the use of Data Extractor). For convenient viewing and editing of a boot sector of a FAT12 or FAT16 partition, Data Extractor offers the window shown in the figure below.

Values in light fields of the window are essential for correct data recovery from the selected partition. The program validates the correctness of data input into these fields during entry. If the entered data are invalid, parameter title will be highlighted in yellow.

Figure 188. Viewing a boot sector in the "FAT16 Boot sector" mode

You can open the window from the right-click menu of the boot sector mode in the Explorer mode (using the Properties menu item) or the View as…→ FAT16 Boot sector mode of the binary editor..

FAT file system cannot control each individual sector; therefore, it unites adjacent data areas into clusters. Thus, it decreases the total number of storage units that the file system has to track. Each cluster has its number; cluster size (number of sectors) is divisible by 2, the number is selected depending upon disk and FAT size (see Table 6). A file takes on drive a group of clusters expressed by an integer number. As a result, some disk space is wasted. If a file

Values in decimal notation

Parameter size Values in hexadecimal notation

Parameter (see the table)



takes more than one cluster, then all clusters occupied by the file will be arranged into a cluster chain. The number of files on disk cannot exceed the number of clusters (FAT elements).

Table 6. FAT cluster size.

Partition size, Mb FAT16 Cluster size, Kb

(number of sectors)

FAT size, Kb FAT32 Default cluster size, Kb

(number of sectors)

FAT size, Kb

0 – 15 16 – 27

128 – 255 256 – 511

512 – 1 023 1 024 – 2 145 2 146 – 8 191 8 192 – 16 383

16 384 – 32 767 32 768 and larger

4 (8), FAT12 2 (4) 4 (8)

8 (16) 16 (32) 32 (64)

- - - -

0,5 – 6 16 – 28

64 – 128 64 – 128 64 – 128 64 – 128

- - - -

- - - -

4 (8) 4 (8) 4 (8) 8 (16)

16 (32) 32 (64)

- - - -

512 – 1 023 1 024 – 2 145 2 146 – 8 191 4 096 – 8 191 4 096 – 8 191

4 096 and more FAT has received its name from the similarly named file allocation table. The file allocation table is used to

store information about the clusters of a logical drive. Each cluster corresponds to an individual record in FAT – FAT element, which shows whether the cluster is free, occupied by data or marked as bad (defective). If a cluster is occupied by a file, the corresponding record in the file allocation table will include the address of the cluster containing the next file portion or code telling that the cluster is the last one in a chain. That is why FAT is called a file system with linked lists. The original FAT version designed for DOS 1.00 used a 12-bit file allocation table (i.e. one FAT element had the size of 1,5 bytes) and supported partitions up to 16 Mb (in DOS you can create no more than two FAT partitions). For support of hard drives larger than 32 Mb, FAT capacity has been increased to 16 bit (one FAT record is 2 bytes), and the cluster size – to 64 sectors (32 Kb). Since any cluster can be assigned a unique 16-bit number, FAT supports 216, or 65536 clusters per single volume maximum.

System files must be placed in a specific location to allow the boot record to find them as it is too small to store the algorithm of their search on disk. Fixed position of system files in the beginning of the data area imposes a strict limitation on the size of the root directory and file allocation table. Therefore, the total number of files and subdirectories in the root directory of a FAT drive is limited to 512.

Let us examine the organization of a file allocation table using FAT16 as an example (FAT record size is 2 bytes). FAT element contains a number (code), which for FAT16 may take one of the following values:

− 0000h – free cluster − 0002h-FFEFh – number of the next element in a chain − FFF7h – defective − FFF8h-FFFFh – the last one in a chain.

The figure below illustrates the beginning of FAT for a hard drive. FAT elements with numbers 0 and 1 are not used as FAT starts with the media descriptor byte followed by three filling bytes (FFh). Media descriptor determines its type: F8h – hard drive, F0h – 1,44 Mb floppy, F9-FFh – floppy disks of various formats. FAT12 uses just three lowest quadruples (000-FFFh) of the above codes, and the filling pattern consists of two bytes.

F8 FF FF FF 03 00 04 00 05 00 FF FF FF FF 08 00 0A 00 F7 FF 0C 00 00 00 FF FF

Figure 189. Organization of cluster chains

Information about every file is located in the directory record that the file is included into. Directory record contains file size (in bytes), file name, link to the first chain cluster (cluster number) and some additional information (attributes). To read a file completely, it is necessary to find its record in the directory and read the first cluster referenced by that record – it will be the file beginning. Then you should read the FAT element corresponding to it and check whether it is the last one. If it is not the last one, it will show the number of the next cluster of the chain, which also has to be read "in addition" to the clusters read earlier. When the last cluster of the chain is reached, excessive data have to be screened if a file ends outside the cluster border. The screening is performed using file length specified in its directory record.

0000h 0001h 0002h 0003h 0004h 0005h 0006h 0007h 0008h 0009h 000Ah 000Bh 000Ch

Media descriptor

3 filling pattern bytes

File 1 (4 clusters)

File 2 (1 cluster)

File 3 (4 clusters)

Free cluster Defective cluster

FAT element number




Besides free, occupied and bad clusters, drives may contain lost clusters. These are individual clusters or chains that are marked as occupied but belong to no files (i.e. they are not referenced in any of the directory records).

FAT uses the following filename conventions: − A filename must start with a letter or a digit and it may contain any ASCII characters except for space and

the "/\[]:;|=,^*? characters. − Filename cannot exceed 8 characters, then a dot and an optional extension up to 3 characters follow. − Filenames are not case-sensitive, case is not preserved.

The system of directories or folders in general looks as follows. The last FAT copy on drive is immediately followed by a fixed area allocated to the root directory, which may contain a limited number of directory entries. Each directory entry is 32 bytes long and uses a fixed structure (see Table 7). It indicates filename, number of the first cluster, creation date and some file attributes and service properties. A directory may contain entries describing child directories.

Table 7. FAT entry record structure.

Offset, bytes Length, bytes Purpose 00h 08h 0Bh

0Ch-15h 16h

18h

1Ah 1Ch

8 3 1

10 2 2 2 4

File name supplemented with spaces (20h) from the right to 8 characters File type (extension) supplemented with spaces to 3 characters File attributes: Bit 0 – Read Only (R/O) Bit 1 – Hidden (H) Bit 2 – System (Sys) Bit 3 – Volume Label Bit 4 – Directory Entry Bit 5 – Archive (A) Reserved Time of the last change (creation): Bits 0-4 – pairs of seconds (0-29) Bits 5-10 – minutes (0-59) Bits 11-15 – hours (0-23) Date of the last change (creation): Bits 0-4 – day (0-31) Bits 5-10 – month (0-59) Bits 0-3 – year, counted since 1980 (0-119) First cluster number File size in bytes (maximum size is 4 Gb)

The first character in a filename (offset 0) may have special meaning: − 00h – never used directory entry − 05h – first character in the name has code E5h − 2Eh – directory alias (dot) − E5h – deleted entry.

A child directory for FAT looks as a regular file described by the corresponding record of its parent directory. In the link to a directory (marked using a special attribute) the length field is not used (it contains zero), and directory end is identified by the end of the cluster chain. A child directory contains a collection of the same directory entries. The first entry of a child directory is a link to itself under the "." alias (it is used as the source of the first cluster of that directory). Then follows a record with a link to the parent directory using the ".." alias, it allows finding the beginning of the parent directory (zero cluster number indicates a root directory). While the root directory can have only a fixed number of entries, the limitation does not apply to child directories and the number of entries is only limited by the free space on a drive.

Figure 190. Example of a child directory

In Windows 95 support for "long" names of files and directories has been introduced. These names allow characters in different cases, dots within a file name, spaces and some other special characters. The directory includes for every file (or directory entry) several 32-byte adjacent blocks (directory records). The first few entries (see Table 8)

Child directory record – link to itself Child directory record – link to parent directory

Attribute of a link to parent directory

Directory alias



is used for recording of a "long" case-sensitive filename, the number of blocks depends upon name length. These elements have a specific value of the 0Fh attribute byte (volume label, system, hidden and read-only) preventing older OS from noticing these records during search. They are followed by an element with regular structure containing short filename in the 8.3 format. This directory entry contains the number of the first cluster, creation date and file (directory) attributes. A long name cannot exist without a short one. Blocks with parts of a long filename are numbered in the order of character sequence. Block number 01h is located right before the block containing a short filename; if it is insufficient, it will be preceded by a block with the 02h number, etc. The number of the last block is recorded with an increase by 40h (if long filename fits in one block only, its number will be 41h).

Table 8. Structure of directory entry containing a long name.

Offset, bytes Length, bytes Purpose 00h 01h 0Bh 0Ch 0Dh 0Eh 1Ah 1Ch

1 5x2=10

1 1 1

6x2=12 2

2x2=4

Order number Name (double-byte Unicode characters) Attributes (0Fh) Type (00h) Control code (calculated on the basis of the short name) Name (continued) 0000h Name (continued)

Below you can see an example of directory entry containing a long name (System Volume Information), the directory occupies three adjacent 32-byte blocks (length in bytes is specified in brackets).

Figure 191. Example of a directory with a long name

6.2.2 Logical drive with FAT32 file system. FAT32 is a descendant file system of FAT (first FAT was 12-bit and allowed operations with floppy disks and

logical drives up to 16 Mb; in MS-DOS version 3.0 FAT has become 16-bit to support larger drives and for drives up to 2 047 Gb a 32-bit FAT version is used). FAT32 supports smaller cluster sizes and thus allows more efficient use of the disk space compared to FAT. The file system is used in DOS-based operating systems - Windows 95 OSR2, Windows 98 and Windows Me..

The structure of a FAT32 partition is shown in the table:

Table 9. FAT32 partition structure

System area Data area Loader (3 sectors) Loader copy

BPB

, BF_

BPB

, lo

ader

(b

egin

ning

)

FSIn

fo

load

er

(con

tinue

d)

…

BPB

, BF_

BPB

, lo

ader

(b

egin

ning

)

FSIn

fo

load

er

(con

tinue

d)

… FAT

FAT

(cop

y)

Clu

ster

2

Clu

ster

3

…

Clu

ster

N

FAT32 uses an extended loader. It occupies now three physical sectors instead of one and there is a backup copy placed several sectors away after the first boot record (the number of the boot sector's backup copy is specified in BF_BPB, it is usually equal to 6). The zero boot sector contains a block of BIOS parameters, Big FAT BIOS Parameter Block (BF_BPB) and the loader code beginning. Sector 1 contains a FSInfo structure, intended for FAT management. The third sector contains continuation of the boot code. The block of BIOS parameters takes more space in FАТ32; therefore, the standard BPB block has been supplemented by a block entitled BF_BPB. It contains the same structures

Order number Name (5х2=10) Attributes

Type Control code

Name, continued (6х2=12)0000h Name, continued (2х2=4)

File name (8) Time Attributes Reserved (10) Date

First cluster number

File size in bytes (4) Type (3)




as the standard BPB but also includes some additional fields necessary for FAT32. Modifications added to BPB for FAT32 support are described in the table below.

Unlike FAT16, the root directory has no fixed location and size. Instead, it is a special file just like all other directories. In practice, the root directory usually starts with the first cluster of the file area (cluster 2).




− When working with a malfunctioning drive, you can select the chains that are most important (e.g., FATs, boot sectors) and read them into a copy using strictest parameters (higher number of read attempts), and estimate the reading quality

Please refer to the Partition map section for details on using the mode. Window appearance in the Partition map mode is shown in the figure below.

Figure 192. “Partition map” mode for a FAT32 partition



Note! (the use of Data Extractor). You can view the structure of the sector containing the directory elements of a FAT partition if you load it into the binary editor and select View as…→ FAT folder mode. The viewing window will contain the following information for every folder element: offset, cluster number, type, name, extension, size, long name.

Figure 193. Viewing a sector with folder elements in the "FAT folder" mode

The viewing window includes a panel (FAT - Root sector) for approximate calculation of the root directory position. The calculation takes into account the following values obtained from the sector containing FAT directory elements:

− Sector – initial sector of the current directory − Cluster – initial cluster of the current directory − RootCluster – initial cluster of the root directory (0 or 1,5 for FAT12/16, 2 for FAT32) − SectorPerCluster – the number of sectors per one cluster − RootSector – calculated number of the root directory sector.

You can also use the panel to identify the cluster size: the procedure will require two sectors containing the elements of different directories. Then you can substitute different SectorPerCluster value into the calculation to find RootSector values that match or differ just a little; the corresponding SectorPerCluster value will be the sought cluster size for the partition.

FAT32 uses 32-bit cluster identifiers reserving at that 4 bits so that efficient cluster identifier size is 28 bits. Since the maximum size of FAT32 clusters is 32 Kb, theoretically FAT32 can operate volumes of 8 Terabytes. Windows 2000 limits the size of new FAT32 volumes to 32 Gb although it supports larger existing FАТ32 volumes (created in other operating systems).

First two cells of a FAT in the FAT32 system are used as follows: − Cell 0 contains a media descriptor byte supplemented with binary 1s on the left. − Cell 1 contains the code of the attribute of a file cluster chain end (usually 0FFFFFFFh).

Bit 27 of cell 1 is an attribute that describes completion of work with a drive: 1 – work completed in a standard manner, 0 - no. Bit 26 of the cell 1 is an identical attribute describing normal completion of an input/output operation.




Table 10. Boot sector structure of a FAT32 partition

Offset Length, bytes Purpose 0h 3h

0Bh 0Dh 0Eh

10h 11h 13h

15h 16h 18h 1Ah 1Ch 20h

24h 28h 2Ah 2Bh 2Ch

30h 32h

34h 40h

41h 42h 43h

47h 52h

5Ah 1FEh

3 8

2 1 2

1 2 2

1 2 2 2 4 4

4 2 1 1 4

2 2

12 1

1 1 4

11 8

420 2

JMP command to the loader code start OS title, for example, "MSDOS6.0"

BPB BytesPerSector – the number of bytes per sector, usually 512 (200h) SectorsPerCluster – the number of sectors per cluster ReservedSectors – the number of sectors occupied by the loader and reserved NumberOfFATs – the number of FAT copies RootEntries – maximum number of 32-byte elements in the root directory TotalSectors – total number of sectors within a volume. 0000 means that the drive is larger

than 32 Mb, the number is defined by a BigTotSects dword (offset: 20h) MediaDescriptor – media descriptor (identically to the first FAT byte) SectorsPerFAT – the number of sectors in a single FAT (reserved) SectorsPerTrack – the number of sectors per track Heads – the number of heads HiddenSectors – the number of hidden sectors BigTotalSectors – the number of sectors (for partitions > 32 Mb)

BF_BPB BigSectorsPerFAT – the number of sectors per one FAT (for partitions > 32 Mb) ExtFlags – active FAT number FS_VersionMajor – version number FS_VersionMinor – revision number RootDirStrtClus – the number of the first cluster occupied by the root directory on a FАТ32

drive FSInfoSec – the number of the sector containing the FSInfo structure BkUpBootSec – the number of a backup copy of the boot sector (relatively to the main one,

which is usually 0, so this parameter is usually 6) Reserved PhysicalDiskNumber – logical device number, the number is assigned during the format

process (80h – the first hard drive) Reserved Signature – extended loader signature (29h) VolumeSerialNumber – volume serial number (set during format) VolumeLabel – volume label (a string) SystemID – character file system identifier (e.g., "FAT32") Loader code area BootSignature - the 55AAh signature (end of the boot sector)

Note! English parameters in this table correspond to the labels used in the program window while viewing a boot sector in binary editor in the FAT32 Boot sector mode.



Note! (the use of Data Extractor). For convenient viewing and editing of a boot sector of a FAT32 partition, Data Extractor offers the window shown in the figure below.


Figure 194. Viewing a boot sector in the "FAT32 Boot sector" mode

You can open the window from the right-click menu of the boot sector mode in the Explorer mode (using the Properties menu item) or the View as…→ FAT32 Boot sector mode of the binary editor.

The FSInfo structure is intended to speed up performance of various operations with FAT. It contains the number of free sectors and the number of the first free sector. The structure format is described in the table below:

Table 11. FSInfo sector structure

Offset Length, bytes Purpose 000h 004h 1E4h 1E8h 1ECh 1F0h 1FCh

4 480 4 4 4 12 4

41615252h structure sign Reserved 61417272h structure sign Current number of free clusters Number of the first free cluster Reserved AA550000h structure sign

Note! If the current number of free clusters is equal to FFFFFFFFh, it means that the value is unknown and it has to be calculated. If the same value is in the field of the first free cluster number, it means that the search for a free cluster should start with cluster 2. A different value of the first free cluster number points to a cluster that should be used to start searching for free clusters, not to the first free one.







6.3 Logical drive with NTFS file system.

6.3.1 Boot sector. The first sector of a logical drive is referred to as boot sector. It contains bootstrap code and information about

drive geometry. Boot sector structure is determined by the architecture-related peculiarities of a specific file system.

Table 12. Boot sector structure of a logical NTFS drive (short version)

Offset Size, bytes Description 00h 3 Jump instruction 03h 8 OEM ID – identifier 0Bh 25 BPB 24h 48 Extended BPB 54h 426 Bootstrap Code

01FEh 2 Boot sector signature (55AAh)




− When working with a malfunctioning drive, you can select the chains that are most important (e.g., FATs, boot sectors) and read them into a copy using strictest parameters (higher number of read attempts), and estimate the reading quality. Window appearance in the Partition map mode is shown in the figure below.

Figure 195. “Partition map” mode for an NTFS partition

At the boot sector start there is a machine command of 3 bytes to proceed to bootstrap code. Bytes 3-11 (counted from zero) are used to store the vendor's ID that defines the type and version of the file system being used (e.g., "MSDOS5.0" for FAT16, "MSWIN4.0"/"MSWIN4.1" for FAT32 and "NTFS" for NTFS).



The identifier is followed by a BIOS Parameter Block (BPB) of 25 bytes, used to store information about the drive geometry (the number of cylinders, heads, sectors, sector size, the number of sectors per cluster, etc.).

NTFS distributes drive space in clusters using 64 bits to number them. Thus it can use 264 clusters up to 64 Kb each. Similarly to FAT, cluster size can be changed but it does not have to be proportional to the drive size. Default cluster sizes selected during partition formatting are listed in the table below.

Table 13. Default cluster sizes

Drive size Cluster size, Kb (sectors) Less than 512 Mb 512 bytes (1)

512-1023 Mb 1 (2) 1-2 Gb 2 (4) 2-4 Gb 4 (8) 4-8 Gb 8 (16) 8-16 Gb 16 (32)

16-32 Gb 32 (64) more than 32 Gb 64 (128)

The BIOS Parameter Block is followed by its extension - extended BPB used to store the number of the first MFT cluster, its size in clusters, the number of the MFT mirror cluster and some other information. Unlike FAT16/32, MFT can be located in any place on a drive.

After the extended BPB there follows Bootstrap Code, which searches a drive for the OS loader (in Windows NT it is ntldr), loads it into memory and passes control to it. If Bootstrap Code is missing, OS startup is impossible. However, if such drive is connected as a secondary one, the partition should be perfectly accessible.

Boot sector ends with a 55AAh signature.

Table 14. Boot sector structure of an NTFS drive

Offset Size, bytes Description 00h 3 Jump – a jump command 03h 8 System_id - OEM ID

0Bh 2 BPB

BytesPerSector - the number of bytes per sector (always 512 for hard drives) 0Dh 1 SectorsPerCluster - the number of sectors per cluster 0Eh 2 ReservedSectors – the number of reserved sectors 10h 3 NotUsed1 – unused in NTFS (must be 0) 13h 2 NotUsed2 - unused in NTFS (must be 0) 15h 1 MediaDescriptor - media descriptor (F8h for hard drives) 16h 2 NotUsed3 - unused in NTFS (must be 0) 18h 2 SectorsPerTrack – the number of sectors per track 1Ah 2 NumberOfHeads - the number of heads 1Ch 4 HiddenSectors - the number of hidden sectors 20h 4 NotUsed4 - unused in NTFS (must be 0)

24h 4 Extended BPB

NotUsed5 - unused in NTFS (must be 0) 28h 8 TotalSectors – total number of sectors 30h 8 MFT_Cluster – logical number of the cluster where MFT starts 38h 8 MFT_Mirr_Cluster - logical number of the cluster where MFT mirror starts 40h 4 ClustPerFileRecord – the number of clusters per file record (see note) 44h 4 ClustPerIndexBlock – the number of clusters per index block 48h 8 lbVolumeSerialNumber – volume serial number 50h 4 Checksum (0 means instruction to skip its calculation). 54h 426 Bootstrap Code

01FEh 2 Signature – boot sector signature (55AAh)

Note! English parameters in this table correspond to the labels used in the program window while viewing a boot sector in binary editor in the NTFS Boot sector mode.

Note! The ClustPerFileRecord parameter value can be calculated as follows. Some documents mention that parameter value equal to F6h means that the file record size is ¼ of the cluster size (without explanation of calculation method for other values). We suggest the following formula for that parameter:

leRecord)ClustPerFi128(2, +=bytesN ,

where N stands for the size of file record in bytes.




ClustPerIndexBlock – is a single-byte number in true form (e.g., binary number 1111 0110 means minus 118 in decimal code, consequently the size of a file record is equal to 210 = 1024 bytes). Parameter values are always negative and the 0 … 31 range is illegal.

Note! (the use of Data Extractor). For convenient viewing and editing of a boot sector of an NTFS partition, Data Extractor offers the window shown in the figure below.


Figure 196. Viewing a boot sector in the "NTFS Boot sector" mode

You can open the window from the right-click menu of the boot sector mode in the Explorer mode (using the Properties menu item) or the View as…→ NTFS Boot sector mode of the binary editor.

6.3.2 Master file table (MFT). Every element in the NTFS file system is a file, even its service data. The most important NTFS file is referred

to as the Master (or main) File Table (MFT). It is located in MFT area acting as a centralized directory for all files of a drive, including itself. The MFT zone is created during formatting of a logical drive; by default, it occupies 12,5 % of volume capacity (depending upon the NtfsMftZoneReservation parameter value it can take 25 %, 37 % or 50 %).

This area is the location of the $MFT file, which initially takes approximately 64 sectors and grows from the MFT zone start to its end as new user files/subdirectories are created. The approximate size of the MFT file can be evaluated as a product of table record element (usually 1 Kb) and the total number of partition files/subdirectories including the ones deleted recently.

To prevent fragmentation of the $MFT file, the MFT zone remains reserved until all free space on the volume is used up, then the unused "tail" of the MFT zone will be divided in two leaving space for user files. The process can be repeated several times until the reserved space is reclaimed completely.

When necessary, $MFT file can be relocated to any disk part, then it will be outside the volume beginning. The initial address of the $MFT file is stored in boot sector at offset 30h bytes from its beginning.






Figure 197. NTFS drive volume structure

$MFT file is a collection of entries of the FILE Record type. Each such record describes a corresponding file or subdirectory. In most cases, a single file/subdirectory is described completely by one FILE Record, although theoretically it may require several records.

6.3.3 File Records. A file record consists of a header and one or several attributes of arbitrary length terminated by an end

marker (a 32-bit FF FF FF FFh value). Although the number and length of attributes vary between different file records, the size of the file record structure itself is fixed and in most cases it is equal to 1 Kb (the value is stored in the $Вoot file). The first byte of a file record always matches sector beginning.

Header, Attribute 1, Attribute 2, … , Attribute N, End marker.

Figure 198. File record structure

If actual length of attributes is less than the file record size, its end will simply remain unused. If attributes do not fit within the space allocated for them, an extra File Record referencing the initial record will be created.

Table 15. File record structure

Offset Size, bytes OS Description

00h 4 any File record signature (magic number) "FILE" 04h 2 any Offset of the update sequence number, conventional (S) 06h 2 any Size (in words) of the Update Sequence Number & Array 08h 8 any $LogFile Sequence Number (LSN) 10h 2 any Sequence number 12h 2 any Hard links counter 14h 2 any Offset of the first attribute

16h 2

any Flags: 00h – unused file record 01h – file record is used; it describes a file 02h – file record is used; it describes a directory 04h – no information 08h – no information

18h 4 any Real size of a file record 1Ch 4 any Allocated size of a file record 20h 8 any File reference to a base File Record (0, if the record is base). 28h 2 any Next attribute ID 2Ah 2 XP For alignment 2Ch 4 XP Index number of this MFT record

2 any Update sequence number 2S-2 any Update sequence array

File record signature. The first bytes in a header take the 46 49 4C 45h ("FILE") value indicating that you are dealing with an MFT entry of the File Record type.

0x0000 46 49 4C 45 30 00 03 00 B0 EF 97 10 00 00 00 00 FILE0...°ï—..... 0x0010 09 00 01 00 38 00 01 00 78 01 00 00 00 04 00 00 ....8...x.......

Figure 199. File record signature

Offset of update sequence number. After the signature there is a 16-bit bit number reflecting the offset of the update sequence number (please see the Update Sequence section).

$MFTMirror

User data and metafiles User data and metafiles

$MFT file

MFT zone

File record signature

Offset of update sequence number = 0030h




0x0000 46 49 4C 45 30 00 03 00 F4 59 00 02 00 00 00 00 FILE0...ôY...... 0x0010 01 00 02 00 38 00 01 00 E8 01 00 00 00 04 00 00 ....8...è....... 0x0020 00 00 00 00 00 00 00 00 05 00 00 00 28 00 00 00 ............(... 0x0030 05 00 00 00 00 00 00 00 10 00 00 00 60 00 00 00 ............`...

Figure 200. Offset of update sequence number

Header size (which varies between different operating systems) is not specified explicitly. Instead, the header contains a 16-bit number located at offset 14h bytes from the sector beginning, which contains the first attribute offset in bytes relatively to the file record beginning. Offsets of the next attributes (if any) are identified by adding the sizes of all previous attributes (the size of each attribute is specified in its header) to the first attribute offset (please see the Attributes section for details). The end of the last attribute contains a 32-bit end marker – FF FF FF FFh.

0x0000 46 49 4C 45 30 00 03 00 B0 EF 97 10 00 00 00 00 FILE0...°ï—..... 0x0010 09 00 01 00 38 00 01 00 78 01 00 00 00 04 00 00 ....8...x.......

...

0x0030 6A 02 00 00 00 00 00 00 10 00 00 00 60 00 00 00 j...........`... ...

0x01D0 00 00 04 00 00 00 00 00 31 40 22 25 01 00 86 E1 ........1@"%..†á 0x01E0 FF FF FF FF 82 79 47 11 00 00 00 00 00 00 00 00 ÿÿÿÿ‚yG.........

Figure 201. First element pointer, end marker

File record length is stored in two 32-bit fields. The real size field at offset 18h bytes from the sector start contains the total size of the header, all its attributes and the end marker rounded by the 8-bit border. The allocated size field at offset 1Сh bytes from the sector start contains the number of bytes allocated to file record rounded to the sector size.

For the 16-bit flags field located at offset 16h byte from the sector start the following three values are defined: 00h – the file record is not used or the file/directory associated with it is removed, 01h – file record is used and describes a file, 02h – file record is used and describes a directory. It is obvious that the value of that field is produced as a result of addition of the attributes defined for it, i.e. the file record describing a directory has the value equal to 01h + 02h = 03h. Undocumented attributes 04h and 08h, probably, may contain information about the file system version (NT, 2K); they are used with such system files as $Secure, $Quota, $ObjID, $Reparse, and $UsnJrnl.

0x0000 46 49 4C 45 30 00 03 00 B0 EF 97 10 00 00 00 00 FILE0...°ï—..... 0x0010 09 00 01 00 38 00 01 00 78 01 00 00 00 04 00 00 ....8...x.......

Figure 202. Flag, real size and allocated size fields

The 64-bit field at offset 20h bytes from the sector start contains the index number of the base file record. The field is always equal to zero for the first file record; for all extra records it will be equal to the number of the base file record. Extra file records can be located in any MFT parts; they do not have to be close to the base record. In order to provide for fast search of extra file records, an $ATTRIBUTE_LIST is maintained. The list of attributes is a special attribute added to the first file record and containing the index numbers of extra records. Attribute list format is described in the Types of attributes table.

0x0010 09 00 01 00 38 00 01 00 78 01 00 00 00 04 00 00 ....8...x....... 0x0020 00 00 00 00 00 00 00 00 05 00 00 00 1B 00 00 00 ................

Figure 203. Index numbers of the base and current file records

6.3.4 Update Sequence. File records need a mechanism for integrity control of their contents. In NTFS update sequence is employed

for that purpose.

Allocated size = 400h (1024) Real size = 178h (376)

Flag = 01h (file record describes a file)

Base file record index (this is the base record)

File record index = 1Bh (27)

First attribute offset = 38h

End marker

First attribute beginning



16-bit update sequence number is recorded to the end of each sector forming a file record; these sectors are duplicated in the file record header. During each reading operation the last two bytes in a sector are compared with the corresponding header field and if NTFS driver finds a discrepancy then such file record is considered invalid.

The main purpose of the update sequence is protection against "recording breaks". If the power supply disappears during the process of sector recording to disk, it may happen that a half of a file record will be recorded successfully and the other half will retain its old contents (a file record usually consists of two sectors). During each sector rewriting the sequence number grows by 1, so if a break in recording occurs, the value of the sequence number in the file record header will not match the number in the sector end.

Data replaced by the update sequence numbers are stored in a special update sequence array located in file record header right after the sequence number.

To validate the integrity of a file record, it is necessary to read from the header the pointer to a sequence number (it is stored at offset 04h bytes from the header beginning) and compare the 16-bit value at that address with the last word of each of the sectors forming the file record. Their mismatch means that the corresponding data structure is damaged and it should be used very carefully.

0x0000 46 49 4C 45 30 00 03 00 25 49 74 2A 00 00 00 00 FILE0...%It*.... 0x0010 01 00 01 00 38 00 03 00 D8 01 00 00 00 04 00 00 ....8...Ø....... 0x0020 00 00 00 00 00 00 00 00 06 00 00 00 1E 00 00 00 ................ 0x0030 0E 14 72 00 00 00 00 00 10 00 00 00 60 00 00 00 ..r.........`...

...

0x01F0 08 03 73 00 6F 00 66 00 74 00 77 00 61 00 0E 14 ..s.o.f.t.w.a...

...

0x0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0E 14 ................

Figure 204. Verification of file record integrity

After successful integrity check of a file record, it is necessary to restore its original form (assuming modification of a sector copy in memory). For that purpose there is a 16-bit field at offset 06h from the sector beginning. It contains the total size of the update sequence number together with the update sequence array (SizeOf(update sequence number) + SizeOf(update sequence array)), expressed in words (two bytes). The size of an update sequence number is always equal to one word; therefore, the value of the 16-bit field at offset 06h minus one defines the number of sectors in a file record. The first word in an update array corresponds to the last word in the first sector of a file record. The second one corresponds to the last word in the second sector, etc.

0x0030 0E 14 72 00 00 00 00 00 10 00 00 00 60 00 00 00 ..r.........`... ...

0x01F0 08 03 73 00 6F 00 66 00 74 00 77 00 61 00 72 00 ..s.o.f.t.w.a... ...

0x0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

Figure 205. Restoration of a file record copy in memory

6.3.5 Attributes. Any attribute consists of a header and a body. Attribute header and the body of a resident attribute are stored

in file record within MFT (please see the File Records section). The body of a non-resident attribute is stored outside MFT in one or several clusters indicated in a special list in the header of that attribute (please see the Data Runs section). If the 8-bit field at offset 08h bytes from the beginning of an attribute header is equal to 0, then the attribute is considered to be resident; if it is 1 – then it is non-resident. No other values are allowed.

Pointer to the sequence number = 30h The number of sectors in file record = 03h – 1 = 2 sectors

File record beginning

Update sequence number (validation value)

End of the first file record sector

End of the second file record sector

Update sequence number (validated value)

End of the first file record sector

End of the second file record sector

Update sequence arrayUpdate sequence number




Four initial bytes of an attribute header determine its type. An attribute's type, in its turn, defines the presentation format for the attribute's body.

Table 16. Types of attributes

Value OS Conventional designation Description 010h any $STANDARD_INFORMATION Standard file information (time, access rights) 020h any $ATTRIBUTE_LIST List of attributes 030h any $FILE_NAME Filename 040h NT $VOLUME_VERSION Volume version 040h 2K $OBJECT_ID Unique GUID and other ID 050h any $SECURITY_DESCRIPTOR Security descriptors and Access Control Lists (ACL) 060h any $VOLUME_NAME Volume name 070h any $VOLUME_INFORMATION Information about the volume 080h any $DATA Main file data 090h any $INDEX_ROOT Index root 0A0h any $INDEX_ALLOCATION Index sub-nodes 0B0h any $BITMAP Free space map 0C0h NT $SYMBOLIC_LINK Symbolic link 0C0h 2K $REPARSE_POINT For third-party vendors 0D0h any $EA_INFORMATION Extended attributes for HPFS 0E0h any $EA Extended attributes for HPFS 0F0h NT $PROPERTY_SET Obsolete, not used at present 100h 2K $LOGGED_UTILITY_STREAM Used by the encrypted file system (EFS)

The next four bytes contain attribute length expressed in bytes. The length of a non-resident attribute is equal to a sum of its body and header; and the length of a resident attribute equals the length of its header. Thus, if we add an attribute's length to its offset, we can receive a pointer to the next attribute (or end marker if the current attribute is the last one in a chain).



0x0000 46 49 4C 45 30 00 03 00 F4 59 00 02 00 00 00 00 FILE0...ôY...... 0x0010 01 00 02 00 38 00 01 00 E8 01 00 00 00 04 00 00 ....8...è....... 0x0020 00 00 00 00 00 00 00 00 05 00 00 00 28 00 00 00 ............(...

0x0030 05 00 00 00 00 00 00 00 10 00 00 00 60 00 00 00 ............`...

0x0040 00 00 00 00 00 00 00 00 48 00 00 00 18 00 00 00 ........H....... 0x0050 54 CF 02 E1 4E DD C5 01 00 27 A3 1C 7E 75 C4 01 TÏ.áNÝÅ..'£.~uÄ. 0x0060 16 E8 3F E2 4E DD C5 01 16 E8 3F E2 4E DD C5 01 .è?âNÝÅ..è?âNÝÅ. 0x0070 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ............... 0x0080 00 00 00 00 09 01 00 00 00 00 00 00 00 00 00 00 ................

0x0090 00 00 00 00 00 00 00 00 30 00 00 00 78 00 00 00 ........0...x...

0x00A0 00 00 00 00 00 00 03 00 5A 00 00 00 18 00 01 00 ........Z....... 0x00B0 27 00 00 00 00 00 01 00 54 CF 02 E1 4E DD C5 01 '.......TÏ.áNÝÅ. 0x00C0 54 CF 02 E1 4E DD C5 01 54 CF 02 E1 4E DD C5 01 TÏ.áNÝÅ.TÏ.áNÝÅ. 0x00D0 54 CF 02 E1 4E DD C5 01 00 00 00 00 00 00 00 00 TÏ.áNÝÅ......... 0x00E0 00 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00 ........ ....... 0x00F0 0C 02 44 00 49 00 52 00 45 00 43 00 54 00 7E 00 ..D.I.R.E.C.T.~. 0x0100 31 00 2E 00 45 00 58 00 45 00 65 00 64 00 69 00 1...E.X.E.e.d.i.

0x0110 30 00 00 00 88 00 00 00 00 00 00 00 00 00 02 00 0...ˆ...........

0x0120 6C 00 00 00 18 00 01 00 27 00 00 00 00 00 01 00 l.......'....... 0x0130 54 CF 02 E1 4E DD C5 01 54 CF 02 E1 4E DD C5 01 TÏ.áNÝÅ.TÏ.áNÝÅ. 0x0140 54 CF 02 E1 4E DD C5 01 54 CF 02 E1 4E DD C5 01 TÏ.áNÝÅ.TÏ.áNÝÅ. 0x0150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x0160 20 00 00 00 00 00 00 00 15 01 64 00 69 00 72 00 .........d.i.r. 0x0170 65 00 63 00 74 00 78 00 5F 00 39 00 63 00 5F 00 e.c.t.x._.9.c._. 0x0180 72 00 65 00 64 00 69 00 73 00 74 00 2E 00 65 00 r.e.d.i.s.t...e.

0x0190 78 00 65 00 00 00 00 00 80 00 00 00 48 00 00 00 x.e.....€...H...

0x01A0 01 00 00 00 00 00 04 00 00 00 00 00 00 00 00 00 ................ 0x01B0 78 21 00 00 00 00 00 00 40 00 00 00 00 00 00 00 x!......@....... 0x01C0 00 90 17 02 00 00 00 00 C0 8C 17 02 00 00 00 00 .�......ÀŒ...... 0x01D0 C0 8C 17 02 00 00 00 00 22 79 21 26 0C 00 01 00 ÀŒ......"y!&....

0x01E0 FF FF FF FF 82 79 47 11 00 00 00 00 00 00 00 00 ÿÿÿÿ‚yG......... 0x01F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 05 00 ................

Figure 206. Identification of attribute location in a file record

The body length of resident attributes expressed in bytes is stored in a 32-bit field located at offset 10h bytes after the start of an attribute header. The 16-bit filed following it is used to store the offset of the resident body counted from the beginning of an attribute header.

In non-resident attributes lots of fields are used for storage of the length of their bodies. Real size of attribute expressed in bytes is stored in the 64-bit field located at offset 30h bytes from the beginning of an attribute header. After it follows a 64-bit field that preserves initialized data size of the stream expressed in bytes and, judging by all signs, always equal to the real size of attribute body. Another 64-bit field located at offset 28h bytes from the start of an attribute header is used to store the allocated size of attribute expressed in bytes and equal to the real attribute size rounded (up) to cluster size.

Two 64-bit fields located at offsets 10h and 18h bytes from the start of an attribute header define the first (starting VCN) and the last (last VCN) virtual cluster number belonging to the body of that non-resident attribute. Virtual clusters are logical cluster numbers independent from their physical location on disk. In most cases, the number

Attribute type ($STANDARD_INFORMATION, offset – 38h)

Attribute length = 60h, the next attribute is located at offset 38h + 60h = 98h

Attribute type ($FILE_NAME, offset – 98h)


Attribute type ($FILE_NAME, offset – 110h)


Attribute type ($DATA, offset – 198h)

Attribute length = 198h, the next attribute is located at offset 198h + 40h = 1E0h

32-bit end marker (i.e. file record contains 4 attributes)




of the first cluster of a non-resident attribute body is equal to zero and the last one – to the number of clusters occupied by the attribute body minus one. The 16-bit field at offset 20h from the start of an attribute header contains a pointer to the Data Runs array within that header, which describes the logical order of placement on disk for a non-resident attribute body (please see the Data Runs section for details).

Every attribute has its own identifier (attribute ID) unique for that file record and preserved in a 16-bit field located at offset 0Eh from the start of an attribute header.

If an attribute has an attribute Name property, then the 16-bit field at offset 0Ah bytes from the attribute header will contain a pointer to it. For nameless attributes it is zero (most attributes have no names). Attribute name is stored in an attribute header in UNICODE format; its length is defined by a 8-bit field located at offset 09h bytes from an attribute start.

If an attribute body is compressed, encrypted or sparse, the 16-bit flag field at offset 0Ch bytes from the start of an attribute header will not be equal to zero.

Table 17. Resident attribute structure

Offset Size, bytes Value Description 00h 4 Attribute type (e.g., 10h, 60h, B0h) 04h 4 Attribute length including the header 08h 1 00h Non-resident flag 09h 1 N Attribute's name length (0 if the attribute is nameless) 0Ah 2 18h Name offset (0 if the attribute is nameless)

0Ch 2

0001h 4000h 8000h

Flags: - compressed attribute - encrypted attribute - sparse attribute

0Eh 2 Attribute ID 10h 4 L Length of attribute body without header 14h 2 2N+18h Attribute's body offset 16h 1 Index flag 17h 1 00h For alignment 18h 2N UNICODE Attribute name (if any)

2N+18h L Attribute body

Table 18. Non-resident attribute structure

Offset Size, bytes Value Description 00h 4 Attribute type (e.g., 0x20, 0x80) 04h 4 Attribute length including the header 08h 1 01h Non-resident flag 09h 1 N Attribute's name length (0 if the attribute is nameless) 0Ah 2 40h Name offset (0 if the attribute is nameless)

0Ch 2

0001h 4000h 8000h

Flags: - compressed attribute - encrypted attribute - sparse attribute

0Eh 2 Attribute ID 10h 8 Starting VCN 18h 8 Last VCN 20h 2 2N+40h Offset of data runs list 22h 2 Compression unit size rounded up to 4 bytes 24h 4 00h For alignment 28h 8 Allocated size rounded up to cluster size 30h 8 Real size 38h 8 Initialized data size of the stream 40h 2N UNICODE Attribute name (if any)

2N+40h .. List of data runs



6.3.5.1 Standard information attribute ($STANDARD_INFORMATION, 10h)

The standard information attribute describes the time of creation/modification/last access to a file, access rights and some other auxiliary information (e.g., quotes).

Table 19. Structure of the standard information attribute (10h)

Offset Size, bytes OS Description ~ ~ any Standard attribute header 00h 8 any С – time of file creation (creation) 08h 8 any А – time of file modification (altered) 10h 8 any М – time of file record modification (MFT changed) 18h 8 any R – time of last file reading (read) 20h 4 any MS-DOS file permissions 24h 4 any Highest dword in version number (maximum number of versions) 28h 4 any Lowest dword in version number (version number) 2Ch 4 any Class ID 30h 4 2K Owner ID 34h 4 2K Security ID 38h 8 2K Quota charged 40h 8 2K Update sequence number (USN)

The following values are defined for MS-DOS file permissions: − 0001h - read-only − 0002h - hidden − 0004h - system − 0020h - archive − 0040h - device − 0080h - normal − 0100h - temporary − 0200h – sparse file − 0400h - reparse point − 0800h - compressed − 1000h - offline − 2000h - not content-indexed − 4000h - encrypted.

6.3.5.2 List of attributes ($ATTRIBUTE_LIST, 20h).

The list of attributes is used when all file attributes do not fit into the base file record and so the file system has to place them in extra records. Index numbers of these extra file records are stored in the $ATTRIBUTE_LIST attribute in the base file records.

Attributes may not fit into a single file record in the following cases: − File contains many alternate names or hard links. − File is heavily fragmented. − File contains a very complicated security ID. − File has many data streams (i.e. attributes of the $DATA type).

Table 20. Structure of the $ATTRIBUTE_LIST attribute (20h)

Offset Size, bytes Description ~ ~ Standard attribute header 00h 4 Attribute type (please see the Types of attributes table) 04h 2 Record length 06h 1 Name length or zero (if none), conventional designation – N 07h 1 Offset to name or zero if none 08h 8 Starting VCN or zero if the attribute is resident 10h 8 Reference to base/extra file record 18h 2 Attribute ID 1Ah 2N Name in UNICODE format (if N > 0)




6.3.5.3 File name attribute ($FILE_NAME, 30h).

The $FILE_NAME attribute contains file name in corresponding namespace (maximum filename length is 255 characters in UNICODE format). A file may have several such attributes (e.g., a Win32 name and an MS-DOS name). The attribute is also used to store hard links, if any.

Table 21. Structure of the $FILE_NAME attribute (30h)

Offset Size, bytes Description

~ ~ Standard attribute header 00h 8 File reference to parent directory 08h 8 С – time of file creation (creation) 10h 8 А – time of file modification (altered) 18h 8 М – time of file record modification (MFT changed) 20h 8 R – time of last file reading (read) 28h 8 File's allocated size 30h 8 File's real size 38h 4 Permissions flag (see the description of the standard information attribute) 3Ch 4 Used in HPFS 40h 1 Name length in characters– L 41h 1 Filename namespace 42h 2L Filename in UNICODE format without the final zero

0x0090 00 00 00 00 00 00 00 00 30 00 00 00 78 00 00 00 ........0...x... 0x00A0 00 00 00 00 00 00 03 00 5A 00 00 00 18 00 01 00 ........Z....... 0x00B0 27 00 00 00 00 00 01 00 54 CF 02 E1 4E DD C5 01 '.......TÏ.áNÝÅ. 0x00C0 54 CF 02 E1 4E DD C5 01 54 CF 02 E1 4E DD C5 01 TÏ.áNÝÅ.TÏ.áNÝÅ. 0x00D0 54 CF 02 E1 4E DD C5 01 00 00 00 00 00 00 00 00 TÏ.áNÝÅ......... 0x00E0 00 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00 ........ ....... 0x00F0 0C 02 44 00 49 00 52 00 45 00 43 00 54 00 7E 00 ..D.I.R.E.C.T.~. 0x0100 31 00 2E 00 45 00 58 00 45 00 65 00 64 00 69 00 1...E.X.E.e.d.i.

0x0110 30 00 00 00 88 00 00 00 00 00 00 00 00 00 02 00 0...ˆ...........

0x0120 6C 00 00 00 18 00 01 00 27 00 00 00 00 00 01 00 l.......'.......

0x0130 54 CF 02 E1 4E DD C5 01 54 CF 02 E1 4E DD C5 01 TÏ.áNÝÅ.TÏ.áNÝÅ. 0x0140 54 CF 02 E1 4E DD C5 01 54 CF 02 E1 4E DD C5 01 TÏ.áNÝÅ.TÏ.áNÝÅ.

0x0150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

0x0160 20 00 00 00 00 00 00 00 15 01 64 00 69 00 72 00 .........d.i.r. 0x0170 65 00 63 00 74 00 78 00 5F 00 39 00 63 00 5F 00 e.c.t.x._.9.c._. 0x0180 72 00 65 00 64 00 69 00 73 00 74 00 2E 00 65 00 r.e.d.i.s.t...e. 0x0190 78 00 65 00 00 00 00 00 80 00 00 00 48 00 00 00 x.e.....€...H...

Figure 207. Example of the $FILE_NAME attribute

Attribute type ($FILE_NAME) Attribute length

Resident flag (offset 08h, the attribute is resident, i.e. its body is stored in this file record)

Flag (offset 0Ch, the attribute is not compressed or encrypted)

Attribute body length (offset 10h) = 6Сh (108 bytes) Attribute body offset (offset 14h) = 18h

Reference to parent directory (offset 18h)

CAMR (creation, modification and read time)

Allocated and real size (offsets 40h and 48h, zero values mean that file size should be taken from the $DATA attribute)

Name in UNICODE format (42 bytes) = "directx_9c_redist.exe", i.e. name in Win32 format; therefore, the first (undescribed) name attribute contains MS-DOS name: "DIRECT~1.EXE"

Filename length = 15h (21), name in UNICODE format will take 21*2 = 42 bytes

Attribute contains MS-DOS name - "DIRECT~1.EXE"



6.3.6 Data Runs. Bodies of non-resident attributes are stored on disk in one or several cluster chains referred to as runs. A run is

a sequence of adjacent sectors characterized by the number of its initial cluster and length. A set of runs is referred to as run-list.

For space saving purposes, the run length and the initial cluster number are stored in fields of variable size. Thus, if run size fits into a byte (i.e. its value does not exceed 255), then it is stored in a byte. Consequently, if a run size requires a long word for its presentation, then it is stored in a long word.

The size fields are stored in 32-bit fields referred to as nibbles. Hexadecimal system allows easy conversion of bytes into nibbles and vice versa. Lowest nibble corresponds to the lowest hexadecimal bit in a byte, the highest nibble corresponds to the highest one. E.g., 69h consists of two nibbles – the lowest one is 9h, the highest – 6h.

A list of data runs is an array of structures; each of them describes the characteristics of its own run, and in the list end there is a 16-bit end marker equal to 00h. The first byte of the structure consists of two nibbles: the lowest one defines the field length for the initial run cluster (conventionally designated as F), the highest nibble determines the number of clusters in that run (L). Run length field follows next. Depending upon the L value, it can take from 1 to 8 bytes (longer fields are not allowed). The first byte of the initial file cluster field is located at offset 1 + L bytes from the structure beginning (which corresponds to 2+2*L nibbles).

Table 22. Data run structure

Offset, nibbles Size, nibbles Description 0 1 Length field size (L) 1 1 Initial cluster field size (S) 2 2*L The number of clusters in a run

2+2*L 2*S Number of the initial cluster of a run

0x0190 78 00 65 00 00 00 00 00 80 00 00 00 48 00 00 00 x.e.....€...H...

0x01A0 01 00 00 00 00 00 04 00 00 00 00 00 00 00 00 00 ................

0x01B0 78 21 00 00 00 00 00 00 40 00 00 00 00 00 00 00 x!......@.......

0x01C0 00 90 17 02 00 00 00 00 C0 8C 17 02 00 00 00 00 .�......ÀŒ......

0x01D0 C0 8C 17 02 00 00 00 00 22 79 21 26 0C 00 01 00 ÀŒ......"y!&....

0x01E0 FF FF FF FF 82 79 47 11 00 00 00 00 00 00 00 00 ÿÿÿÿ‚yG.........

Figure 208. Example of a $DATA attribute

Let us examine a run-list corresponding to a normal unfragmented file shown in the figure above: "22 79 21 26 0С 00".

The first byte is 22h. Lowest nibble (x2h) describes the size of a run length field, the highest one (2xh) – the initial cluster field size. The next few bytes represent the run length field, which in this case takes two bytes – 79h 21h. Two other bytes (26h 0Сh) define the number of the initial run cluster. The zero byte at the end (00h) indicates that its is the last run in the file. As a result, our file consists of a single run, which starts with cluster 0С26h (reverse byte order) and ends with cluster 0С26h + 2179h = 2D9Fh.

If the file were fragmented, the run-list could look, for example, as follows: "31 38 73 25 34 32 14 01 E5 11 02 31 42 AA 00 03 00". The first run (run 1) starts with cluster 342573h and continues until cluster 342573h + 38h = 3425ABh. The second run (run 2) starts with cluster 0211E5h and continues until cluster 0211E5h + 114h = 212F9h. The third run (run 3) starts with cluster 0300AAh and continues to cluster 0300AAh + 42h = 300ECh. The zero byte at the end (00h) indicates that it is the last run in the file. Thus, the file consists of three data runs placed on disk as follows: 342573h – 3425ABh; 0211E5h – 212F9h; 0300AAh – 300ECh.

Attribute type ($DATA, offset – 198h)

Resident flag (offset 08h, non-resident attribute) Attribute name length (offset 09h, attribute is not nameless)

Flag (offset 0Ch, attribute is not compressed or encrypted )

Initial virtual cluster number (offset 10h)

Run-list offset (offset 20h) = 40h

Final virtual cluster number (offset 18h)

Real attribute body length (offset 30h) = 2178СС0h (35 097 792 bytes)




Beginning with version 3.0, NTFS supports sparse attributes, i.e. those which do not write to disk clusters that contain zeroes only (if an attribute is sparse, then its flag will be 8000h). The field of the initial cluster number of such run may be equal to zero meaning that no cluster has been assigned to that run. The length field contains the number of clusters filled with zeroes. They should not be read from disk. You should create them manually in memory.

6.3.7 Metafiles. The first 12 records in MFT are always occupied by service metafiles: $MFT (the $MFT proper), $MFTMirr

($MFT mirror), $LogFile (transaction log), $Volume (information about volume), $AttrDef (defined attributes), '.' (root directory), $Bitmap (free space map), $Boot (system loader), $BadClus (list of bad clusters), etc. Every metafile is responsible for some aspect of system functioning. The table below lists the currently used metafiles and their purposes.

Four first records are so important that they are duplicated in a special $MFTMirr file located approximately in the middle of a drive (precise location is stored in boot sector at offset 38h bytes from its beginning). Contrary to its name, $MFTMirr is not a mirror of the whole $MFT file, it is just a copy of its first four elements.

Records from 12 to 15 are marked as used, but in fact they are empty. Records 16-23 are not used, they are marked as unused.

Beginning with record 24, the user files and directories are located. Four metafiles, which appeared in W2K ( $ObjId, $Quota, $Reparse and $UsnJrnl) can be located in any record with the number equal to 24 or greater (file record numbers are counted from zero).

Table 23. NTFS service files (metafiles)

Record No. in MFT File name OS Description

0 $MFT any Master File Table (MFT) 1 $MFTMirr any Backup copy of the first four MFT elements 2 $LogFile any Transactional logging file 3 $Volume any Serial number, creation time, dirty flag (unreset cache flag) for the volume 4 $AttrDef any Attribute definition 5 . (dot) any Root directory of the volume 6 $Bitmap any Free/occupied space map 7 $Boot any Volume boot record 8 $BadClus any The list of bad clusters within a volume 9 $Quota NT Quota information 9 $Secure 2K Used security descriptors

10 $UpCase any Table of uppercase characters for name translation 11 $Extend 2K Directories: $ObjId, $Quota, $Reparse, $UsnJrnl

12-15 unused any Marked as used but empty in fact 16-23 unused any Marked as unused ≥ 24 ObjId 2K Unique identifiers for every file ≥ 24 $Quota 2K Quota information ≥ 24 $Reparse 2K Information of the reparse point type ≥ 24 $UsnJrnl 2K Journal of encryption ≥ 24 File any Regular files ≥ 24 Directory any Regular directories



6.4 Logical drive with Ext2,3file system. Ext2 and Ext3 file systems are based on UFS (Unix File System). Ext3 is a server version of Ext2 with

implemented support for file system journaling; it is compatible with the base Ext2 architecture.

The file system starts with an optional reserved area. The remaining file system part is subdivided into sections referred to as groups of blocks. All groups except for the last once contain the same number of blocks used for storage of metadata, directories and file content.

Basic information about file system structure is stored in the superblock data located in FS beginning. The content of files is stored in blocks represented by groups of adjacent sectors. Metadata of each file and directory are stored in a data structure referred to as index node (inode); the structure has fixed size being included into an index table. A single index table exists for each group of blocks. File names are stored in the directory record structure within the blocks allocated to the parent directory. Directory records are data structures containing file name and a pointer to the file index record.

6.4.1 Superblock. Superblock is located in the FS beginning. It contains base information about partition size and configuration

being a counterpart of boot sector in FAT and NTFS.

Superblock starts with offset of 2 sectors from the FS beginning. Its size is equal to 1024 bytes (2 sector), although most of them are unused. Superblock contains just the configuration parameters, it contains no boot code. Backup copies of the superblock are usually stored in the first block of each group of blocks.

Superblock also contains such basic parameters as block size, total number of blocks, the number of blocks per group and the number of blocks reserved before the first blocks group.

First group of blocks is located after the reserved area.

Figure 209. Ext2,3 file system structure

Backup copies of the superblock and the table of group descriptors may be not stored in each group of blocks if the sparse superblock flag is enabled.

Superblock fields are listed in the following table.

Group 0 Group 1 … Group N-2 Group N-1

Blocks in group

Reserved area and first data block

Total number of groups




Table 24. Ext2,3 superblock data structure

Range Description Essential 0 – 3 Number of inodes in FS Yes 4 – 7 Number of blocks in FS Yes

8 – 11 Number of blocks reserved to prevent FS overflow No 12 – 15 Number of free blocks No 16 – 19 Number of free inodes No 20 – 23 Block where the zero group of blocks starts Yes 24 – 27 Block size (in the format of bits number for shift of the 1024 value to the left) Yes 28 – 31 Fragment size (in the format of bits number for shift of the 1024 value to the left) Yes 32 – 35 Number of blocks in each group Yes 36 – 39 Number of fragments in each group Yes 40 – 43 Number of inodes in each group Yes 44 – 47 Last mounting time No 48 – 51 Last writing time No 52 – 53 Current number of mount sessions No 54 – 55 Maximum number of mount sessions No 56 – 57 Signature (F53h) No 58 – 59 FS status:

1h – checked FS 2h – FS has errors 4h – frozen inodes are found. No

60 – 61 Error handling method: 1h – continue 2h – remount FS as read-only 3h – panic. No

62 – 63 Additional version No 64 – 67 Time of the last integrity check No 68 – 71 Interval between forced integrity checks No 72 – 75 OS used to create the FS:

0h – Linux; 1h – GNU Hurd; 2h – Masix; 3h – FreeBSD; 4h – Lites. No

76 – 79 Main version: 0h – original version; 1h – “dynamic” version. Yes

80 – 81 UID allowed to use the reserved blocks No 82 – 83 GID allowed to use the reserved blocks No 84 – 87 First unreserved inode in FS No 88 – 89 Inode structure size Yes 90 – 91 Group of blocks including this superblock (for backup copies) No 92 – 95 Flags of compatible features:

0001h – preliminary allocation of blocks for directories is used to decrease fragmentation;

0002h – index nodes of AFS servers exist 0004h – FS contains a journal (Ext3) 0008h – inodes have extended attributes 0010h – modification of FS sizes is allowed for large partitions 0020h – directories use hashed indexes No

96 – 99 Flags of incompatible features: 0001h – compression (unsupported) 0002h – directory records contain the file type field. Yes

100 – 103 Flags of compatible read-only features: 0001h – sparse superblocks and tables of group descriptors 0002h – FS contains a large file 0002h – directories use В-trees (not implemented). No

104 – 119 FS identifier No 120 – 135 Volume name No 136 – 199 Last mount path No 200 – 203 Bit map for algorithm use No

204 Number of blocks allocated for files in advance No 205 Number of blocks allocated for directories in advance No

206 – 207 Unused No



208 – 223 Journal identifier No 224 – 227 Journal inode No 228 – 231 Journal device No 232 – 235 Beginning of the froze inodes list No

236 – 1023 Unused No

6.4.2 Table of group descriptors. The file system consist of groups of blocks. Each group has an associated data structure describing its

arrangement – group descriptor. Group descriptors are stored in a group descriptors table recorded in the group following the superblock. Backup copy of the table exists in each group of blocks (unless the «sparse superblock» feature is enabled in the system). Apart from file content, groups of blocks contain administrative data – backup copies of the superblock and group descriptors table, tables of index nodes and blocks. Group descriptor describes the location of those data. Basic structure of a blocks group is illustrated below:

Superblock backup copy Table of group descriptors

Bit map of blocks Bit map of inodes Table of inodes

Files content

Bit map of blocks describes the allocation status of group blocks. The initial address of the block containing the map is defined in group descriptor. Map size in bytes is equal to the number of blocks in group divided by 8. Since during FS creation Linux sets the number of blocks per group equal to the number of bits in block, the map size is equal to one block.

Bit map of inodes describes the allocation status of inodes in group while its initial address is defined in group descriptor. Map size in bytes is calculated by dividing the number of inodes in a group by 8. The initial address of the block containing the table of inodes is written in the group descriptor, its size can be calculated by multiplying the number of inodes in group by the size of each node (128 bytes).




Table 25. Data structure of records in group descriptors table

Range Description Essential 0 – 3 Initial address of the blocks bit map Yes 4 – 7 Initial address of the inodes bit map Yes

8 – 11 Initial address of the inodes table Yes 12 – 13 Number of free blocks in group No 14 – 15 Number of free inodes in group No 16 – 17 Number of directories in group No 18 – 31 Unused No

6.4.3 Blocks. In Ext2,3 the unit of data storage is a block, i.e. a group of adjacent sectors. Blocks in Ext2,3 can be viewed as

counterparts of clusters in FAT and NTFS.

Block size in Ext2,3 is 1024, 2048 or 4096 bytes; its value is specified in the superblock. Each block is assigned an address. Address numbering starts with 0, and block 0 is located in the first file system sector. Each block is included into a certain group of blocks except for the case when the superblock defines a reserved area in file system beginning. Then the reserved blocks do not belong to a group, and group 0 starts immediately after the reserved blocks.

The status of block allocation is identified by the bit map of blocks located as specified in group descriptor. For storage of the bit map a full block is assigned; each bit in the block represents a certain block of the group.

In Ext2,3 some of the allocated blocks can belong to no specific files. The system has multiple dedicated blocks with administrative FS data, which are not associated with files. As an example we can mention the superblocks, tables of group descriptors, bit maps of blocks and inodes and tables of inodes.

6.4.4 Index nodes. In Ext2,3 main metadata of files and directories are stored in the data structures of inodes. Additional metadata

can be stored in extended attributes.

All inodes in Ext2,3 have the same size specified in superblock (base size is 128 bytes, in «dynamic» FS versions the size can be dynamic). Each file and directory is allocated a single inode; addressing of inodes starts from 1. Inodes of every group are stored in table located as defined in group descriptor.

Inodes 1 – 10 are usually reserved and so they must be allocated. Among the reserved inodes just the node 2 has a special purpose being used for representation of the root directory. Inode 1 is used to store information about damaged blocks. For the journal the system usually employs inode 8, but its number can be redefined in superblock. The first user file is usually created in inode 11; that node is often allocated for the lost+found directory. The directory is used by software checking file system integrity; any index node allocated for use but not associated with any file name will be placed in that directory under a new name.

The number of fields in every inode is a static value. Additional information is stored in extended attributes and auxiliary indicators. The allocation status of an inode is determined by the map of inodes located as specified in the group descriptor.

Fields of the base inodes are listed in the table below.

Table 26. Data structure of an index node

Range Description Essential 0 – 1 File access mode (type and permissions, see tables 26.1, 26.2, and 26.3) Yes 2 – 3 Low 16 bits of the user identifier No 4 – 7 Low 32 bits of the size in bytes Yes

8 – 11 Access time No 12 – 15 Editing time No 16 – 19 Modification time No 20 – 23 Removal time No 24 – 25 Low 16 bits of the group identifier No 26 – 27 Links counter No 28 – 31 Number of sectors No 32 – 35 Flags (see Table 26.4) No 36 – 39 Unused No 40 – 87 12 direct pointers to blocks Yes 88 – 91 Indirect pointer of the first level Yes 92 – 95 Indirect pointer of the second level Yes



96 – 99 Indirect pointer of the third level Yes 100 – 103 Generation number (NFS) No 104 – 107 Extended attributes block (files ACL) No 108 – 111 High 32 bits of size / directories ACL Yes / No 112 – 115 Block address for fragments No

116 Fragment index in block No 117 Fragment size No

118 – 119 Unused No 120 – 121 High 16 bits of the user identifier No 122 – 123 High 16 bits of the group identifier No 124 – 127 Unused No

16-bit mode field consists of three parts. 9 lower bits contain the flags of permissions; each bit corresponds to one permission. During definition of permissions the «user / group / others» format is used. User and group identifiers are specified in inode, the remaining belong to the «others» category. Each category can be allowed to read, write or execute. Flags of permissions are summarized in the table below.

Table 26.1. Flags of permissions in bits 0-8 of the mode field

Permission flag Description 001h Others – execution allowed 002h Others – writing allowed 004h Others – reading allowed 008h Group – execution allowed 010h Group – writing allowed 020h Group – reading allowed 040h User – execution allowed 080h User – writing allowed 100h User – reading allowed

The next three bits are intended for executable files and directories. Whenever at least one of them is set, the behavior of the executable file at the start changes or files in directories receive special properties. Those flags are listed in the table below.

Table 26.2. Flags in bits 9-11 of the mode field

Permission flag Description 200h Stability bit 400h Set Group ID (SGID) 800h Set User ID (SUID)

Bits 12 – 15 determine the type of the file associated with the inode. The type is defined by a separate value, not a combination of flags. Supported values are listed in the table below.




Table 26.3. Type flags for bits 12-15 of the mode field

Flag Description 1000h FIFO 2000h Symbolic device 4000h Directory 6000h Block device 8000h Regular file А000h Symbolic link С000h Unix socket

Table 26.4. Flags in the inode flags field

Flag Description 00000001h Secure removal (unused) 00000002h Saving a data copy at removal (unused) 00000004h File compression (unused) 00000008h Synchronous updates – new data are recorded to drive immediately 00000010h Locked file – content modification is impossible 00000020h Only data appending is allowed 00000040h File is not added to the dump command results 00000080h A-time is not updated 00001000h Directory with hash indexing 00002000h Ext3 maintains a file system journal.

6.4.5 Extended attributes. A file or directory can have extended attributes represented as «name-value» pairs. If a file or directory has

extended attributes, its inode will contain the address where those attributes are stored.

The block of extended attributes consists of three sections. 32 initial bytes form the header, then the section containing a list of name records follows. The third section starts from the block end and goes backwards to the beginning. It contains the attribute values (their order can differ from the order of the name records).

The extended attributes header starts with the zero byte of the block; its length is 32 bytes. Header fields are listed in the table below.

Table 27. Data structure of the extended attributes header

Range Description Essential 0 – 3 Signature (EA020000h) No 4 – 7 Links counter No

8 – 11 Number of blocks Yes 12 – 15 Hash code No 16 – 31 Reserved No

The links counter indicates how many files with the same extended attributes use together that block of extended attributes. Hash codes calculated by the attribute values are used by the OS to check if two files have the same attributes.

After the header name records follow. The structure of each record is described in the table below.

Table 28. Data structure of the name record in the extended attributes block

Range Description Essential 0 Name length Yes 1 Attribute type (see table 28.1) Yes

2 – 3 Value offset Yes 4 – 7 Block containing attribute value Yes

8 – 11 Value size Yes 12 – 15 Value hash code No

16 + Name in ASCII encoding Yes Offset is specified in bytes within the defined block. Current Linux versions can store the set of extended

attributes in a single block only , the block field is not used in the record. The size field contains the number of bytes in the value. Name length determines the record length; the next record begins with the nearest 4-byte border. Record type field can contain one of six values listed in the table below.



Table 28.1. Type field values in the name records of extended attributes

Value Description 1 User environment attribute 2 POSIX ACL 3 POSIX ACL by default (for directories only) 4 Trusted environment attribute 5 LUSTRE (unused) 6 Security environment attribute

If an attribute belongs to user, trusted or security environment, the block end contains a plain value corresponding to that name. If the type field contains one of POSIX ACL types, the value has its own set of data structures.

6.4.6 Directory record. Directory records are used for storage of file and directory names. They are located in blocks allocated for

directories and containing the addresses of inodes representing files and directories.

There are two formats of the directory structure format but both versions have the same size. The version being used is determined by the incompatible feature flag in superblock. The original format is not used in modern systems by default, its fields are listed in the table below.

Table 29. Data structure of the original directory record version

Range Description Essential 0 – 3 Inode value Yes 4 – 5 Record length Yes 6 – 7 Name length Yes 8 + Name in ASCII encoding Yes

It is the minimal data structure and all its fields are mandatory. For each name the directory contains a single structure referring to the inode with metadata. Name does not end in a null character, therefore the record should contain the length field. Linux aligns those data structure along the borders of 4 bytes.

The second version of directory record uses the name length field more efficiently. Maximum number of characters in file name is 255, therefore a single byte is sufficient for its storage. The second byte is used then to store the file type (which is also stored in inode). Fields of the second version of directory record are listed in the table below.

Table 30. Data structure of the second directory record version

Range Description Essential 0 – 3 Inode value Yes 4 – 5 Record length Yes

6 Name length Yes 7 File type (see Table 30.1) No

8 + Name in ASCII encoding Yes

The type value is not mandatory. Its allowed values are listed in the table below.

Table 30.1. Allowed values of the type field in a directory record

Values Description 0 Unknown type 1 Regular file 2 Directory 3 Symbolic device 4 Block device 5 FIFO 6 UNIX socket 7 Symbolic link

6.4.7 Symbolic link. Symbolic links are special files associated with another directory or file. File «content» is the link target, so

definition of symbolic links does not require creation of new data structures. If the path to target file or directory is shorter than 60 characters, it is stored in 60 bytes of inode used for storage of 12 direct and 3 indirect pointers to




blocks. If path length exceeds 60 bytes, a separate block is allocated for its storage. File size corresponds to the length of the path to target object.

6.5 Logical drive with UFS1,2 file system. The UFS system stems from the Berkeley FFS (Fast File System). Backup copies of important data structures

are stored in several locations within the file system. A UFS partition consists of sections referred to as cylinder groups. In UFS1 the size of each group was defined on the basis of drive geometry (in UFS2 all groups usually have the same size and during formatting of new drives in UFS1 the system can create one group altogether if the partition size is small). Cylinder groups are counterparts of blocks in Ext2,3.

UFS beginning contains the superblock holding the information about file system structure. The content of each file is stored in a block represented by a group of adjacent sectors. Blocks can be subdivided into fragments. Fragments are used for storage of final file bytes (instead of allocating a full block). Metadata of files and directories are stored in data structures referred to as index nodes. File names are stored in directory records within the blocks allocated for a directory. A directory record is a plain data structure containing file name and a pointer to index node.

Each cylinder group has its own table of index nodes, bit maps with information about the allocation status of blocks, fragments and index nodes, and a superblock copy.

6.5.1 Superblock. UFS superblock contains the main file system parameters – fragment size, the number of fragments in each

block, the size of each cylinder group and location of various data structures in each group. UFS superblock has similar purpose compared with the superblock in Ext2,3, but information about the structure and optional data are different.

UFS1 and UFS2 use different data structures in superblocks. Superblocks differ in a vital aspect: UFS2 has enabled 64-bit versions of the size and date fields added in the end of the data structures. Empty 32-bit fields are ignored and not used for data storage.

UFS1 superblock is usually located in sector 16; 2048 bytes are allocated for its storage but many of the stored data are optional or just contain zeroes (from the data recovery viewpoint, important data are located in the first and the third superblock sectors; the first one contains all information about configuration of the corresponding partition while the third has magic that allows you to find and identify the superblock).

The next table summarizes the list of the main and meaningful fields in UFS1 superblock used in FreeBSD, NetBSD, and OpenBSD (the Designation column contains names of superblock fields used in DE to display its properties).



Table 31. UFS1 superblock data structure (partial)

Range Description Designation 0 – 7 Unused -

8 – 11 Shift of backup superblock in cylinder groups relatively to the "base" (in fragments) s_shift_res_sb 12 – 15 Descriptor shift in cylinder groups relatively to the "base" s_shift_descr 16 – 19 Shift of the index nodes table in cylinder groups relatively to the "base" s_shift_itable 20 – 23 Unused - 24 – 27 Additional shift (delta) for randomization in cylinder groups s_delta 28 – 31 Mask for shift calculation (cycle) in cylinder groups s_cycle 32 – 36 Unused - 36 – 39 Number of fragments in file system s_fragm_per_fs 40 – 43 Unused - 44 – 47 Number of cylinder groups in file system s_group_per_fs 48 – 51 Block size in bytes s_bytes_per_block 52 – 55 Fragment size in bytes s_bytes_per_fragm

56 – 183 Unused - 184 – 187 Number of index nodes in cylinder group s_inodes_per_group 188 – 191 Number of fragments in cylinder group s_fragm_per_group 192 – 207 Unused -

208 Superblock modification flag s_flag_modif_sp 209 Flag indicating that file system is clear at the mounting moment s_flag_clear 210 Flag indicating system mounting in "read-only" mode (1, if the system is available for

reading only) s_flag_readonly 211 – 1319 Unused - 1320 – 1323 Maximum length of an internal symbolic link s_max_length_ref 1324 – 1327 Format of index nodes:

2 – 4.4BSD; 0x0FFFFFFF – 4.2BSD. s_inode_format

1328 – 1371 Unused - 1372 - 1375 Signature (011954h) s_magic

Superblock beginning contains the offsets that determine location of data structures within each cylinder group. It also holds the delta and cycle parameters used to calculate the base address of each cylinder group in UFS1.

In UFS1 offsets are supplemented with a base shift that depends upon the cylinder group. Base shift of each group is calculated using two parameters – cycle (с) and delta (d). Base shift grows by d for each group and it gets reset after c groups.

UFS2 superblock contains the same basic information as in UFS1 version, but it does not contain some unused fields and some 32-bit fields are replaced with 64-bit versions. UFS2 superblock is usually located in sector 128.

The next table summarizes the list of the main and meaningful fields in UFS2 superblock (the Designation column contains names of superblock fields used in DE to display its properties).





Range Description Designation 0 – 7 Unused -

8 – 11 Shift of backup superblock in cylinder groups relatively to the "base" (in fragments) s_shift_res_sb 12 – 15 Descriptor shift in cylinder groups relatively to the "base" s_shift_descr 16 – 19 Shift of the index nodes table in cylinder groups relatively to the "base" s_shift_itable 20 – 43 Unused - 44 – 47 Number of cylinder groups in file system s_group_per_fs 48 – 51 Block size in bytes s_bytes_per_block 52 – 55 Fragment size in bytes s_bytes_per_fragm

56 – 183 Unused - 184 – 187 Number of index nodes in cylinder group s_inodes_per_group 188 – 191 Number of fragments in cylinder group s_fragm_per_group 192 – 207 Unused -

208 Superblock modification flag s_flag_modif_sp 209 Flag indicating that file system is clear at the mounting moment s_flag_clear 210 Flag indicating system mounting in "read-only" mode (1, if the system is available for

reading only) s_flag_readonly 211 – 1079 Unused - 1080 – 1087 Number of fragments in file system s_fragm_per_fs 1088 – 1319 Unused - 1320 – 1323 Maximum length of an internal symbolic link s_max_length_ref 1324 – 1327 Format of index nodes s_inode_format 1372 - 1375 Signature (19540119h) s_magic

Some fields are placed differently, the superblock signature is also changed.

6.5.2 Cylinder summary information. UFS1 and UFS2 contain data structures referred to as cylinder summary information. Those structures are

identical in both UFS versions; they contain statistical information about each cylinder group. The structures form a table, each record in the table corresponds to a single group. Summary address and size is defined in superblock.


Range Description Essential 0 – 3 Number of directories No 4 – 7 Number of free blocks (full set of fragments) No

8 – 11 Number of free index nodes No 12 – 15 Number of free fragments (incomplete blocks) No

Cylinder summary information in UFS1,2 is not a counterpart of the group descriptors table used in Ext2,3 and its practically inapplicable for data recovery tasks.

6.5.3 Group descriptor. File system consists of cylinder groups. All groups (possibly, except for the last one) have the same size. Each

group contains a descriptor of itself. Apart from descriptor, each group includes a table of index nodes and superblock backup copy.

A full block is allocated for storage of group descriptor. The descriptor consists of a number of standard fields and the area intended for storage of various bit maps. Standard fields contain information about cylinder group configuration and describe the structure of the final block portion. Most of the fields are optional and they are only used to improve file system efficiency. The final portion of the group descriptor block contains bit maps of index nodes, group blocks and fragments.

In UFS locations of group descriptor, table of index nodes and superblock backup copy are defined separately for each file system; offsets are specified in the superblock. In UFS1 the situation is additionally complicated by the base shift depending upon the cylinder group and supplementing the offsets.

Base shift of each group is calculated using two parameters – cycle (с) and delta (d). It grows by d for each group and it gets reset after c groups.

Data structures of group descriptors in UFS1 and UFS2 are different. Group descriptor offset is defined in the superblock. To calculate the location of a UFS1 group descriptor you need the base shift value in addition to the offset (i.e. group descriptor location is calculated as offset + base shift for the corresponding group).



Group descriptor fields in UFS1 file system are listed in the table below.

Table 34. UFS1 descriptor data structure (partial)

Range Description Designation 0 – 3 Unused - 4 – 7 Signature (0х090255) g_magic

8 – 11 Last recording time - 12 – 15 Group number g_group_number 16 – 17 Number of cylinders in group - 18 – 19 Number of index nodes in group g_inodes_per_group 20 – 23 Number of fragments in group g_fragm_per_group 24 – 27 Number of directories g_folders_per_group 28 – 31 Number of free blocks g_free_blocks_count 32 – 35 Number of free index nodes g_free_inodes_count 36 – 39 Number of free fragments g_free_fragm_count 40 – 43 Last allocated block g_last_ins_block 44 – 47 Last allocated fragment g_last_ins_fragm 48 – 51 Last allocated index node g_last_ins_inode 52 – 91 Unused - 92 – 95 Shift of the bit map of index nodes in bytes g_shift_inodes_bitmap 96 – 99 Shift of the bit map of fragments in bytes g_shift_fragm_bitmap

100 – 107 Unused - 108 – 111 Shift of the bit map of blocks in bytes g_shift_blocks_bitmap 112 – 115 Number of blocks in group g_blocks_per_group 116 – 167 Unused -

168+ Bit maps -

UFS2 group descriptor contains the same base information as its counterpart in UFS1, but some of its fields take up more space. Descriptor location relatively to the cylinder group beginning is stored in superblock, but unlike UFS1 descriptors, additional randomization is not used.

The table below contains a list of UFS2 group descriptor fields.

Table 35. UFS2 descriptor data structure (partial)

Range Description Designation 0 – 3 Unused - 4 – 7 Signature (0х090255) g_magic

8 – 11 Unused - 12 – 15 Group number g_group_number 16 – 19 Unused - 20 – 23 Number of fragments in group g_fragm_per_group 24 – 27 Number of directories g_folders_per_group 28 – 31 Number of free blocks g_free_blocks_count 32 – 35 Number of free index nodes g_free_inodes_count 36 – 39 Number of free fragments g_free_fragm_count 40 – 43 Last allocated block g_last_ins_block 44 – 47 Last allocated fragment g_last_ins_fragm 48 – 51 Last allocated index node g_last_ins_inode 52 – 91 Unused - 92 – 95 Shift of the bit map of index nodes in bytes g_shift_inodes_bitmap 96 – 99 Shift of the bit map of fragments in bytes g_shift_fragm_bitmap

100 – 107 Unused - 108 – 111 Shift of the bit map of blocks in bytes g_shift_blocks_bitmap 112 – 115 Number of blocks in group g_blocks_per_group 116 – 119 Number of index nodes in group g_inodes_per_group 119 – 167 Unused -

168+ Bit maps -

In both descriptor versions the required information is limited to the offsets of bit maps for index nodes and fragments. Bit maps are located after byte 168 but within the block allocated for the group descriptor.

6.5.4 Bit maps of blocks and fragments. In UFS the content of files and directories is stored in fragments and blocks. A fragment is a group of adjacent

sectors, a block is a group of adjacent fragments. Each fragment has an assigned address, address numbering starts with




0. Blocks are addressed by their first fragment. The first (zero, to be more precise) block and fragment are located in the first file system sector. Minimum block size in UFS is 4096 bytes, maximum number of fragments in a block is 8. The figure below demonstrates an example of the relation between blocks and fragments. Block 56 containing fragments 56 – 63 is allocated completely to a file, and fragments 67 - 68 from the block 64 are allocated for its final portion. The remaining fragments of block 64 can be assigned for other files.

Figure 210. Example of the relation between blocks and fragments

If a file can fill a complete block, it will be assigned a full block. While recording the last data portion, file system allocates the fragments necessary for data storage. If a file grows in size so that it can fill an entire block, data will be relocated.

The status of allocation for blocks and fragments is identified by bit maps. Information about each UFS block is stored in two bit maps: bit map of fragments and bit map of blocks. Those bit maps contain information in format inverse to the one typically used in practice: their bits are set to 1 for free objects and reset to 0 for allocated ones.

File system maintains for each cylinder group a bit map of fragments stored in the group descriptor block. Offset of the bit map in bytes is specified in descriptor while the map size is determined by the number of fragments in group.

Bit map of blocks duplicates the information stored in the bit map of fragments, but each its bit signifies an entire block.

6.5.5 Index nodes. Index nodes contain metadata that describe files and directories. UFS1 and UFS2 use different data structures

as UFS2 fields have larger size. Index nodes are distributed among cylinder groups. The number of index nodes per single group is defined in the superblock. Each group of cylinders has its own table of index nodes and its offset is also specified in the superblock. In UFS1 the initial shift value for the table of index nodes can change depending upon the cylinder group (if randomization is used), in UFS2 index tables are always placed with the same offset relatively to the group beginning.

The size of index nodes in UFS1 is 128 bytes, their fields are enumerated in the following table.

Table 36. UFS1 index node data structure

Range Description Essential 0 – 1 File access mode (type and permissions, see Tables 26.1, 26.2 and 26.3) Yes 2 – 3 Links counter Yes 4 – 7 Unused No

8 – 15 Size Yes 16 – 19 Access time No 20 – 23 Access time (nanoseconds) No 24 – 27 Modification time No 28 – 31 Modification time (nanoseconds) No 32 – 35 Editing time No 36 – 39 Editing time (nanoseconds) No 40 – 87 12 direct pointers to blocks Yes 88 – 91 Indirect pointer of the first level Yes 92 – 95 Indirect pointer of the second level Yes 96 – 99 Indirect pointer of the third level Yes

100 – 103 Status flags No 104 – 107 Number of blocks No 108 – 111 Generation number (NFS) No 112 – 115 User identifier No 116 – 119 Group identifier No 120 – 127 Unused No

The mode field contains the same values as in Ext2(3). Links counter performs the same functions and grows with creation of each file name referring to the index node.

Information about allocation status of an index node is stored in the bit map of index nodes. The file system maintains a bit map of index nodes for each cylinder group keeping it in the group descriptor block.

56

Block 56

57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72

Block 64

55



UFS2 index nodes are twice as large as their counterparts in UFS1 (256 bytes instead of 128), a part of their 32-bit fields is replaced in them with 64-bit ones. Index nodes are also stored in the table of index nodes; the table’s offset is defined in the superblock and remains constant. Fields of the UFS2 index nodes are listed in the following table.

Table 37. UFS2 index node data structure

Range Description Essential 0 – 1 File access mode (type and permissions, see Tables 26.1, 26.2 and 26.3) Yes 2 – 3 Links counter Yes 4 – 7 User identifier No

8 – 11 Group identifier No 12 – 15 Size of the index nodes block No 16 – 23 Size Yes 24 – 31 Number of bytes held No 32 – 39 Access time No 40 – 47 Modification time No 48 – 55 Editing time No 56 – 63 Creation time No 64 – 67 Access time (nanoseconds) No 68 – 71 Modification time (nanoseconds) No 72 – 75 Editing time (nanoseconds) No 76 – 79 Creation time (nanoseconds) No 80 – 83 Generation number (NFS) No 84 – 87 Kernel flags No 88 – 91 Status flags No 92 – 95 Size of extended attributes No

96 – 111 2 direct pointers to the blocks of extended attributes No 112 – 207 12 direct pointers to blocks Yes 208 – 215 Indirect pointer of the first level Yes 216 – 223 Indirect pointer of the second level Yes 224 – 231 Indirect pointer of the third level Yes 232 – 255 Unused No

The most noticeable difference between UFS1 and UFS2 versions is in 64-bit blocks and time stamps introduced in the latter. Addresses in indirect addressing blocks also take 64 bits.

6.5.6 UFS2 extended attributes. UFS2 files and directories can also have extended attributes («name-value») defined by the user or system.

Extended attributes are stored in regular data blocks with addresses specified in appropriate index nodes. Each block contains a list of data structures having variable length; their fields are listed in the table below.

Table 38. Data structure of the extended attribute record in UFS2

Range Description Essential 0 – 3 Record length Yes

4 Name space: 1 – user 2 – system. No

5 Content supplement Yes 6 Name length Yes

7 – (7 + name length) Name Yes (after name with alignment along the 8 bytes border)

Value Yes

The system supplements the name to make the value begin from the border of 8 bytes. The value is also supplemented to align the next record along the 8-bytes border. The name alignment size is calculated by the name length while the size of value alignment is defined in byte 5.

6.5.7 Directory records. Directory records are intended for storage of directory and file names. They are stored in blocks allocated to

directories. Each record contains file name and the address of an index node containing metadata. The fields of directory records in UFS1(2) are listed in the table below.




Table 39. Data structure of a directory record in UFS1(2)

Range Description Essential 0 – 3 Index node Yes 4 – 5 Directory record length Yes

6 Name length Yes 7 File type No

8 + Name in ASCII encoding Yes

Allowed values of the file type are listed in the table below.

Table 40. Allowed values of the type field in the directory record

Values Description 0 Unknown type 1 FIFO 2 Symbolic device 4 Directory 6 Block device 8 Regular file

10 Symbolic link 12 Socket 14 Duplicate

The duplicate type is used in case if the file system has been mounted in concatenation mode which may result in two files with the same names appearing. For one of the files the system sets the duplicate flag and the operating system does not display it upon user request.

The directory record length field is used to search for the next allocated record, the name length field – for identification of name end and actual record length.

dataextractor udma new

Documents

data recovery task

task main menu

new task

open task

task manager window

data output

options main menu

general information