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 screen 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
The first field is the description field. This is the string data which will be displayed in the list of recovery profiles. This string should be unique. If you do happen to accidently enter a description which has already been entered, Blade will append a counter to the end of the description to ensure it remains unique. In this field, enter the text “Example Bitmap”.
The File Extension field holds the extension used by Blade when it writes out any identified data. In this field enter the text “BMP”. There is no need to enter the dot character.
The category field is used to group similar types of recovery profiles. Blade automatically generates a number of common file types and also allows you to create your own group names. In this field, select “Graphic File Types”.
The author field contains a string which identifies the original author. When you add a new profile, this field automatically defaults to the name of the licensed user or agency which is stored in the USB licence dongle. This field can be altered at this point if you wish.
The date field is read only and will be automatically updated to reflect the last modified date/time for this recovery profile. The date is in ISO format.
The version stamp is also automatically generated. The version numbering format is:
MajorVersion.MinorVersion.BuildNumber
The build number is generated automatically and is read only. The numbers represent the year in 2 digit format and the day of the year. In the case above, the build number refers to the 154th day of 2010. When the profile is modified, this build number will be automatically updated.
The Minor Build number will also increase by one on subsequent modifications, although the Major/Minor numbers can be modified by the author at any time.
Version numbers are logged in the recovery audit log (along with a breakdown of the profile) so that specific recovery versions can be recreated at any time. In the case above, the recovery profile version is v1.0.10154.
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 recovery. 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
To create a landmark for this data, you would create a landmark as follows:
Figure 6
In our Bitmap example, we will leave this section blank 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
If the length marker had been of a different type, this can be selected in the Length Marker Size drop down box. You also have the option to select little or big endian values. For an explanation of little and big endian values, please see the link at the bottom of this article.
The Length Marker Relative Offset field indicates the relative location from the start of the file to the field containing the length marker.
If the data is corrupt and/or the length marker contains an unreasonable value, Blade will not recover data beyond the maximum length value set in the Data Boundary pane. In this case, the recovery log will indicate that data has been truncated and will only be recovered up to the maximum length value. If the data length marker is smaller than the Minimum Length value, Blade will log the fact that the data is shorter than the set value and the data will not be recovered.
If there is no Data Length marker, Blade will recover data based on the Data Boundary settings. The Minimum Length value prevents data which is smaller than this value from being recovered.
With the Maximum Length, Blade will recover data up to this value. If Use Next File Signature as EOF is selected, it will check where the next file is located on the disk (or image) and use this as the end of the file. In our Bitmap case, we have selected this value and set the maximum length to 25 MB.
When Use Next File Signature as EOF (End of File) is selected, Blade will only look for the EOF marker in the data from the start of the file to the start of the next file.
Helpful Links
Original Digital Detective Knowledge Base Article
Blade Forensic Data Recovery Web Site
Understanding Regular Expressions
Understanding Endiannes
