Overview
To recover data with Blade, you can either use the built-in recovery profiles stored in the global profiles database or create your own bespoke recovery profile. You do not have to possess programming knowledge to do this as with other tools. Blade was designed so that complicated data recovery profiles could be designed quickly for effective data recovery.
Blade has access to two separate recovery profile databases. The global database cannot be altered by the user and contains profiles created and distributed as part of the software. From time to time, we will update and add to these profiles as a result of research and development. It also allows us to create additional validation routines for specific profiles in the database. For example, the JPEG image recovery profile in the global database invokes a comprehensive validation routine to assist with accurate recovery. The personal recovery profile database can hold profiles created by the user, recovery profiles copied from the global database and imported recovery profiles from colleagues and other practitioners.
Elements of a Recovery Profile
As you can see from the figure below, there are a number of elements which make up a recovery profile. Blade has the ability to use more than just header/footer recovery and employs a powerful regular expression engine.
Figure 1
Wikipedia defines them as: “Regular expressions, also referred to as REGEX or REGEXP, provide a concise and flexible means for matching strings of text, such as particular characters, words, or patterns of characters.” Regular expressions allow you to create powerful recovery profiles which are capable of looking for patterns rather than specific bytes. Some of the patterns can be extremely complicated. Blade comes with its own Regular Expression testing utility so that signatures can be tested prior to use.
Creating a New Recovery Profile
With the personal recovery profile database open, click on the Add New button located on the main toolbar. This will create a new empty profile. We will go through each section individually so we can explain each field and create an example profile to recover Bitmap images. The first pane contains the summary information for this profile. It also contains information to allow this profile to store version information for profile version management.
Figure 2
Major.Minor.Build
File Header Section
This section stores the information which can usually be found at the start of a file.
Figure 3
The signature field holds the string regular expression which identifies that pattern of bytes at the start of a file (or segment of data). This is sometimes referred to as the “file signature” or “magic number”. For our Bitmap image, enter the following text:
BM....\x00\x00\x00\x00....\x28
Bitmaps have a file signature containing two upper case characters “BM”. The next four bytes hold a UInt32 which relates to a file length marker. This becomes important later as we create this profile. The dot character in the case relates to any possible value. This is why regular expressions are particularly powerful. For further information on creating regular expressions, see the external links at the end of this article.
The sector boundaries only check box allows you to select whether to ignore data which is not aligned to a sector boundary. This will depend entirely upon which type of data you are trying to recover. As we wish to recover all possible Bitmap images, we are going to leave this option un-ticked. By selecting this option, we may not recover images embedded within other file types.
The ignore case option will change the way the regular expression engine interprets our signature. In our Bitmap example, selecting this option will force the engine to look for data which starts with any combination of the upper and lower case characters “BM”. For example, it would identify “Bm”, “bM”, “BM” and “bm”. Leaving it un-ticked means the engine will only identify the upper case characters “BM” at the start of the signature.
File Landmark Section
The file landmark section allows you to improve the recovery capability even further. If you think of the file header and footers as bookends, the file landmark section refers to any data which can be found within the two boundaries. The landmark can be found at a specific offset, or at any position within the file. The landmark also uses regular expression patterns, and you can also select Unicode data.
By ticking the Use File Landmark option, you will unlock the fields in this section. The location drop down box allows you to select whether the landmark is floating or at a specific byte offset. If it is at a specific byte offset, this field accepts an integer value which is relative to the file header. For example, if you were aware of 2 static bytes (FF 0A) contained within your file at decimal offset 90, you would create the landmark as follows:
Figure 4
As another example, you may find the following Unicode string contained within a Microsoft Word document:
Figure 5
A Blade profile landmark for this would therefore look like this:
Figure 6
In our Bitmap example, we will leave this section blank and disabled.
File Footer Section
The file footer section contains information to allow the end of the file to be found. Not all file types contain footer data. For example, JPEG images contain 2 bytes to represent the footer FF D9.
Figure 7
By selecting the Use File Footer check box, the file footer fields will be activated. As with the other signature sections, you have the ability to use a regular expression pattern for this field. The Bytes to EOF field contains a signed integer value which relates to the location of end of the file in relation to the start of the footer. In our JPEG example above, as the footer contains two bytes FF D9, the Bytes to EOF file would be set to 2 - this indicates that the location of the start of this footer is 2 bytes prior to the end of the file.
The following footer example is for HTML data and contains a regular expression designed to stop if it encounters binary (non-textual) data or the normal end of an HTML document. This allows more accurate HTML recovery and can be used when attempting to recover text based files.
Figure 8
For our Bitmap example, leave the footer section un-ticked as there is no recognisable footer with this file format.
Data Length and Boundary Sections
This section controls the length and boundary of our recovered data. In our Bitmap example, we identified that at decimal offset 2 there was a UInt32 value which related to the length of the original file. If we select Use Length Marker, Blade will read a length marker at the offset provided.
Figure 9