Friday, June 4, 2010

Forensic Practical Exercise #4

I have previously posted a couple different practical exercises here for people to work through and practice. You can see the previous ones here: Practical #1, Practical #2, Practical #3.

This exercise is going to be a little more theoretic because I cannot share the data that I have and I have no ability to make additional data for sharing.

So here is the scenario (BTW, it's a real scenario). Local police detectives have responded to the scene of a homicide. During their investigation they have discovered that there is a CCTV system that may have caught the entire event on video. Being conscious of preserving the data, they called the security company responsible for installing the CCTV system, who promptly responded and shut down the CCTV system. The technician pulled the hard drive out and gave it to the detectives, who has now given it to you with one simple request: "find the evidence". They want you to extract the videos so they can review them to see if it is useful in helping solve the case. Sounds simple eh?

Being the energetic examiner that you are, you quickly image the hard drive and begin an initial analysis. Once imaged, you load the image into EnCase and see a single 100GB FAT32 volume containing hundreds of files in the root directory of the volume. There are no subdirectories (other than some file system generated directories that contain no data). Information about the volume looks like this:

The files in the root directory look like this:

The video data from each day is recorded and stored in one or multiple files depending on the amount of data recorded. Each file has the extension of "XBA". The file header looks like this:

You then export several files out to your local working drive and attempt to view them using a freely available video viewer. Each attempt to view fails and the viewer reports the file is corrupted. A quick look at the exported files show they are each 32,768 bytes in length, even though EnCase reports a different size for each file you exported.

Ideas?..........Let the questions begin... please use the comment function below so everyone can benefit from questions and answers already given.


Anonymous Friday, 04 June, 2010  

Determine the manufacture of the surveillance system and request they send you or direct you to where you can download their proprietary viewer and attempt to view the copies of the files.

Anonymous Friday, 04 June, 2010  

Reprimand the Detective, tell him to go back and get the original DVR. Clone the original HDD, put clone into DVR, located evidence.

Anonymous Friday, 04 June, 2010  

like the first comment ... manufacturer of system, contact them. We once had one to lend us one of their full system so we could extract data.

Jon Stewart Friday, 04 June, 2010  

The FAT is fubar. We know that the directory entry seems more or less valid, containing timestamps, file size, and starting cluster, and we know that the cluster size is 32KB, and we know that this is a weird embedded system and embedded systems programmers are dirty, dirty people, and not apt to obey the normal rules of civility (like respecting filesystems).

My guess is this: it's a DVR device, and there's only going to be one file open for writing at any given time. When the system opens a new file and gets back the starting cluster, it simply starts writing direct to disk; when it closes the file, it writes the size back to the directory entry, and bypasses the FAT cluster chain altogether. It knows that the files won't be fragmented.

I haven't looked through exhaustively, but I think my hunch is borne out by looking at the starting extents in the picture. If you sort by starting extent, I'll bet you a can of Coke that you'll see the filenames are also sorted by time.

To verify, I'd go to the starting extent of one of these files in disk view. I'd scroll down the logical size of the file. And then I'd look at the last four bytes--they'll likely match \x00\x00\x01[\xB0-\xBF] (most likely \x00\x00\x01\xb9, which Foremost and other references I've found on the web list as the file footer). I'd copy that chunk out, and try to watch it.

If this pans out, it wouldn't be tough to script out extraction of all the files.


Anonymous Friday, 04 June, 2010  

Surveillance cameras normally use proprietary software that is not readable by normal means. Getting with the manufacturer, as suggested earlier, should have been the first step.

Anonymous Friday, 04 June, 2010  

I too have seen hard drive married to CCTV systems.

Lance Mueller Friday, 04 June, 2010  

Wow, a lot of differing opinions were posted. Like many real-life scenarios, we don't always get everything we want, like the original DVR system make, model, etc...My hope was that you tried to come up with a theory or ideas with what you had (what I presented).

That being said, Jon's theory is exactly correct! The manufacturer of this DVR system has decided to basically ignore all the rules of a common file system like FAT32. The DVR device creates a file with a sequential name and then streams the data to disk contiguously. When the file is completed, the logical size is written and then a new file is created at the very next cluster. As a result, none of the files are ever fragmented. They are laid out on the disk sequentially one cluster after another.

What gives this away? A couple of things. First, there are no FATs. Well, there is the reserved area for FATs, but they are empty, there is no cluster chaining going on at all. The second tip is EnCase does not show the files as deleted, but every file shows the size of 32,768 bytes, which is one complete cluster (64 sectors per cluster as show in the volume information).

If you look at the first item in EnCase's table pane, it is #512. The logical size is listed as 38,948,636 (logical size being bigger than physical size is very odd on a FAT32 filesystem) 38,948,636 / 32,768 = 1188. This file contiguously occupies 1188 clusters. Immediate after the 1188th cluster a new file begins.

The manufacturer has basically decided to utilize the standard FAT directory entry with the starting cluster number, but then thats all. There is no FAT table to indicate cluster chains because the manufacturer ignores the fragmentation capability of the file system and just writes the entire file contiguous. Knowing this, when a file needs to be read, the DVR system just looks up the file name in the root directory entry, then goes to the starting cluster and then reads the entire size of the logical file size even though it may cross several cluster boundaries.

So now, how do we get this data into a form the requesting detective can view? Again Jon is exactly right, an EnScript is the only way to export this data back into a form that can be viewed. Without an EnScript, the only way you could do this is to view the volume in EnCase and then sweep from the starting cluster number recorded in the DIR entry for the total number of bytes indicated in the file's logical size, then export. This will work, but if you have several hundred files to do, this is going to be *very* tedious.

So there you have it. This is just a simple example of the rules that we have come to know and follow, being broken and the file system being used in a non-traditional way.

Excellent work by Jon!

BTW, I had no idea Jon see this post and offer up his answer to this practical exercise. Jon and I used to work together and he has been my mentor for many years. As I have stated in my EnScript tutorials, I am not a programmer by trade, but Jon is. Jon has taught me basically everything I know about EnScript programming and has helped me tremendously over the past 5 years.

If you like programming stuff, Jon has his own blog at

Thanks Jon! I am honored you stopped by.

Douglas Brush Friday, 04 June, 2010  

Just had this exact case a few weeks ago. an by the way, nothing makes your heart jump after you image a drive for 6hrs on-site in adverse party's office an open it to see no partitions, file table, and just "stuff" in unallocated clusters.

Now - to make matters worse, the other side had damaged/lost the original CCTV box so all we had was a hard drive. The video forensic expert i work with is very good and we were able to obtain the DVR software. Luckily (in the sense of general compatibility) it was Windows based and originally ran native in XP Pro 32.

Forensic copy of original via Solo-III - 2 copies made. DD segments at 4GB.

Mount in FTK Imager to view data. Noted that there was not a "standard" logical partition and just data in unallocated clusters. However, there was a pattern of the files in unallocated space of size and some sort of naming convention. No recognizable file signatures and no file extensions. So something wrote on the drive.

Load a fresh Windows XP 32 VM. Used the Microsoft Windows Virtual PC on this.

Installed Mount Image Pro in the VM.

Connected the working copy of drive with the image to the computer and brought it into the VM.

Mounted the image.

Loaded the DVR software that was used on the original box. It scanned the attached drives and found the mounted evidence drive.

Now we were able to play back the video.

Why this was so important was the video had originally been processed poorly from the other side so there where video artifacts and blur in their production copy. Now with our method we were able to see the video clearly and the video forensic analyst was able to use his tools, on a read only copy, in a native environment and produce a clean DVD.

I created a VM of

Lance Mueller Friday, 04 June, 2010  

For those of you interested, here is the EnScript I wrote to correctly export the files. It is nothing fancy, 26 lines of code and it just takes the selected files and exports them to the default case export folder.

It is not compiled so you can see the entire code:

class MainClass {
void Main(CaseClass c) {
if (c){
String export = c.ExportFolder() + "\\Files Exported based on sequential clusters and file size\\";
if (LocalMachine.CreateFolder(export)){
forall(EntryClass entry in c.EntryRoot()){
if (entry.IsSelected()){
DeviceClass dev = entry.GetDevice();
EntryFileClass file();
LocalFileClass local();
if (local.Open(export + entry.Name(), FileClass::WRITE)){
local.WriteBuffer(file, entry.LogicalSize());
SystemClass::Message(16,"Error", "Could not create output file, check your case default export folder path and try again");
SystemClass::Message(16,"Error", "Could not create output folder, check your case default export folder path and try again");

Download Here

Joseph Shaw Friday, 04 June, 2010  

Lance, thank you for posting the EnScript code, even though I was too late to answer the practical question.

Greg Kelley Saturday, 05 June, 2010  

If you checked the box for "initialized size" when doing a copy/unerase, did that fix things? Just curious.

Unknown Monday, 07 June, 2010  
This comment has been removed by the author.
Lance Mueller Monday, 07 June, 2010  


Thanks for the comment, but the question of converting the XBA file was never really in question. You can't convert it if the file is incomplete or corrupted, which is the point/focus of the practical.

Unknown Monday, 07 June, 2010  

Yah, read it again - assumed that it was being seen as corrupted because it was a proprietary format and needed the converter / password. If the request was to 'get the evidence' I still would have gone that route first. Enjoyed reading the problem and solution - please keep them coming.

Unknown Monday, 07 June, 2010  

Sorry "...Yah, *I* read it again..."

Dan O'Day Wednesday, 16 June, 2010  

The XBA file format is proprietary to Timespace Technology:

You could ask the owner of the system to provide the player or request it from the manufacturer. We run into this issue a lot.

Rob Tuesday, 13 July, 2010  

I Love the response of the folks who do this or have delt with Security Video at this level before.. Fist call.. PROPRIETARY video ..arrgg! Then to Google or the Company's 1-800 number to request a viewer etc.. LOL.. I have one out on the bench now from an Arson.. Grr.. Luckily the video quality is so poor it doesn't matter..

But then this really wasn't what the problem was about.. eh?

Robyn Friday, 16 July, 2010  

I am new into the field and have found this site very helpful!

Can anyone give any advise on what certifications you have that you have found most valueable?

Computer Forensics Training Thursday, 09 September, 2010  

This is very informative blog that i found. But i like reading the problem and solution on this post. I will follow up this blog and please continue this awesome work..

HSCW Editor Sunday, 31 October, 2010  

If it's not too late to weigh in: I looked up the file extension/type, which is used by many DVRs, but led to a specific system. A few further searches turned up the system specs, manual, and product detail from Timespace Technology. .xba files can be read by "PCLINK200 REVIEWING/ARCHIVING SOFTWARE
Availability Supplied in Interface Kits; software freely available to law enforcement agencies". Either the forensic investigator/examiner in the example, or the detective could then have contacted:
Electronic Services Agency (ESA)
845 E 5TH St
Marysville, Ohio 43040
Phone: 1-937-644-2170
There is a software link on their webpage, and ESA, as I understand it, will provide a username/password to allow law enforcement to download the application for free, so examiners can review the evidence contained in the proprietary .xba files. The program otherwise retails for about $3600.

I admit I haven't contacted the company yet - but all that info turned up in about 10 minutes of searching. Man, I really love Google, you know?

I'd be interested to know if anyone has ever gotten in touch with ESA about the reviewing software.

There is another possible solution, though it would involve going back to the beginning: The specs and manual indicate that the security camera system can export the video to a CD - and during the process one can chose the option is chosen to writes both the .xba files AND pcplayer.exe to the CD. pcplayer.exe is a cut-down video reviewing app that allows viewing of the .xba files, but not conversion to another format.

The specs also indicate the recording format is MPEG4, even though the files are saved in the proprietary format, and that conversion of the .xba files to .avi can be done "with the password". So the PCLink Software not only plays back/reviews the files, but must do so by reassembling the original MPEG format from the .xba files. The archiving capability mentioned in the description may be what writes the .xba files PLUS the pcplayer to CD, and maybe also what accomplishes the conversion to AVI format. Of course, I don't know if it's possible to convert and leave the state of the drive unchanged: the program may write some sort of scratch files to the disk

Last: the ONE thing I keep asking myself after finding out all that information is: Why the hell didn't the technician, who presumably is competent to support the system, tell the police some of this in the first place? Since the security company supplied the hardware, they must own the software also, because it's not possible to purchase either without the other.

Obviously the real solution to this puzzle has been missed by everyone: The murderer is either the technician who pulled the hard drive, or the owner/manager of the security company (someone in authority who could make certain technicians are kept ignorant of anything except how to fix the hardware). He/she knows the police will figure out how to view the video eventually, but the delay will provide enough time to empty bank accounts, procure a fake passport, and flee to a country with which the US has no extradition treaty. :-)


Post a Comment

Computer Forensics, Malware Analysis & Digital Investigations

Random Articles