ilable at ScienceDirect

Digital Investigation 11 (2014) 179e186

Contents lists ava

Digital Investigation

journal homepage: www.elsevier .com/locate/d i in

Reverse engineering a CCTV system, a case study

Lee Tobin*, Ahmed Shosha, Pavel GladyshevDigitalFIRE Labs, CASL Institute, University College Dublin, Dublin, Ireland

a r t i c l e i n f o

Article history:Received 22 February 2014Received in revised form 21 July 2014Accepted 22 July 2014Available online 20 August 2014

Keywords:CCTVReverse engineeringProprietary file-systemsDisk image analysisInvestigationEavesdrop

* Corresponding author.E-mail address: lee.tobin@ucdconnect.ie (L. Tobi

http://dx.doi.org/10.1016/j.diin.2014.07.0021742-2876/© 2014 Elsevier Ltd. All rights reserved.

a b s t r a c t

Given a disk image of a CCTV system with a non-standard file system, how is the datainterpreted? Work has been done in the past detailing the reverse engineering of pro-prietary file systems and on the process of recovering data from CCTV systems. However, ifgiven a disk image without the CCTV system itself, or if under time constraints, the taskbecomes much more difficult. This paper explains a different approach to recovering thedata and how to make sense of data on a CCTV disk. The method does not requireextensive reverse engineering of the CCTV system, or even to have access to the CCTVsystem itself.

© 2014 Elsevier Ltd. All rights reserved.

Introduction

Techniques for reverse engineering proprietary filesystems are well documented (Ariffin et al., 2013; Pooleet al., 2008), it is usually feasible provided the data isintact and not encrypted. So why revisit this topic? Insome investigations, only the disk or disk image from theCCTV system is available. This limits the amount ofreverse engineering that can be done as the investigatordoes not have access to the CCTV hardware. Sometimesthe speed at which information can be extracted from aCCTV system is of the utmost importance; reverse engi-neering can be very time consuming. In these cases,speeding up the reverse engineering process withoutsacrificing the precision and depth of the analysis isdesirable. This paper approaches the problem in adifferent way; instead of trying to explain data structuresand data offsets from the raw data, the problem is tackledin a pragmatic way. To explain the approach, this paperwill use an example scenario. This scenario is based on an

n).

analysis performed in a real case, though heavilyredacted.

Related work

Wouter S. van Dongen performed a study of a SamsungCCTV system (Dongen, 2008) in order to obtain traces ofvideo recordings. This in-depth forensic examination of theCCTV system also analyses logs and related video data. Themethod employed differs from our approach as the Sam-sung system contained a common and recognisable file-system (ext3). This facilitated the use of data carvingtools to aid in the recovery of information in unallocatedspace. The approach undertaken in this paper is to under-stand the operation of the CCTV system in as little time aspossible while maintaining forensic rigour.

Poole et al. performed a detailed analysis (Poole et al.,2008) of a CCTV system. This analysis required extensivetesting and experimentation in order to reverse engineerthe device. This type of analysis, while very robust andcomplete, takes time and requires access to the CCTVhardware. It may be more appropriate to perform this typeof analysis if related CCTV software can not be found, arequirement for the approach detailed in this paper.

L. Tobin et al. / Digital Investigation 11 (2014) 179e186180

Problem

The example scenario is as follows:

� An investigator is given a 500 GB disk that was takenfrom a CCTV system, where the make and model is notspecified.

� The investigator is asked if video data exists on the diskrecorded before a certain date.

� The investigator has a limited amount of time in whichto provide a detailed answer and analysis.

Method

The approach taken in this paper requires a host systemon which to do the analysis, a way to monitor processes onthe host system and a way to view data on a disk (a low-level disk viewer).

Software and hardware used in the paper

� Tableau Forensic Bridge e Model T35e� Intel i7 based PC with 24 GB RAM.� Microsoft Windows 7 Professional SP1 v6.1.7601� XWays Forensics v15.8 SR-6� Process Monitor v3.05

The “Eavesdrop” approach

Fig. 1 shows the flowchart explaining the approachtaken in this paper. This method is explained from a Win-dows OS perspective, however it could just as easily beundertaken using any other operating system, in whichsuitable monitoring tools are available.

One of the most important steps in this approach is theidentification of the make and model of the CCTV system, ifthey are not known. This knowledge is required in order tofind proprietary software for the system.

Fig. 1. Flow chart for the

Initial step

Firstly, the disk was connected via a forensic bridge to avirtual machine running Windows 7. The make and modelof the CCTV was found after a quick examination of the firstfew bytes of the disk. Using a low level disk viewer (such asXWays Forensics), two easily recognisable strings“AVTECH” and “FSS16A” are found. This can be seen inFig. 2.

A quick Internet search uncovers a piece of softwarerelated to AVTECH called “Disktools”. Fig. 3 shows thissoftware recognises the disk image. The disk containsseveral events and after double-clicking on the “2013/03/1800:48:09” event a dialogue box selecting a channel from apossible 16 is shown. After a channel is selected, the chosenvideo for that date/time and channel is displayed. Now thatsome software is found that recognises the disk data, thereverse engineering process can begin. The basic idea is toperform a task in Disktools, such as playing a video, andwhile this task is being performed the disk I/O is monitored.This way, we get information as to how the data is struc-tured on disk without having to analyse the application'sexecutable directly.

Offsets to start of event list

Fig. 4 shows the output from Procmon after selectingthe first event and first channel.

Process Monitor (Russinovich and Cogswell, 2013)(Procmon) is an advanced monitoring tool for Windowsthat shows real-time file system, Registry and process/thread activity. We can use procmon to glean some detailsabout the disk layout.

Disktools is accessing the disk at byte offset 1EEDE00h(32431616d) in 200h (512d) byte chunks, which impliessector size. 1EEDE00h divided by 200h would be the sectoroffset F76Fh. Examining the first few bytes of the diskagain, the bytes 6FF7h can be seen at byte offset 29h.(6FF7h little endian on disk). Scanning through the disk

procmon method.

Fig. 2. The first 128 bytes of the disk image.

L. Tobin et al. / Digital Investigation 11 (2014) 179e186 181

image after this byte offset, there are several hundredsimilarly formatted rows (our dump is arranged in rows of16 bytes) then a distinct end of a section, containing allzeros. At byte offset 21h another number shown here is7EF7h. Looking at the byte offset 1EEFC00h (F77Eh* 200h)confirms the location of the distinct end of section, afterthis section there are only zeros for several sectors. Poole

Fig. 3. The GUI shown when

et al. in their analysis (Poole et al., 2008), performed on asimilar CCTV system, refer to this section of the drive asthe “Event List” section.

The first entry reported by Disktools is the event withthe timestamp “2013/03/18 00:48:09”. Fig. 5 shows thedisk at the byte offset 1EEDE00h. At 1EEDEC0h we seethese hexadecimal byte values:

“Disktools” is started.

L. Tobin et al. / Digital Investigation 11 (2014) 179e186182

� 0Dh ¼ 13d year� 03h ¼ 3d month� 12h ¼ 18d day� 00h ¼ 00d hours� 30h ¼ 48d minutes� 09h ¼ 9d seconds

This sequence of bytes directly correlates with the firstdate entry values shown in Disktools. While this analysisonly focuses on a single event, the rest of the events can beseen in the subsequent lines of this section of the disk

.Something to note here, during the analysis of the drive,before this first event there are older events on the drivebut these are not shown in Disktools. We will discuss thispoint in more detail later in the analysis.

Offsets to start of channel data

FromProcmon's logofDisktools, theapplicationnowseeksto 2DAAF3800h (from Fig. 4, second line 12258850816d).2DAAF3800h/200h (sector size) ¼ 16D579Ch.

From the first QWORD of this line, the hex value16D579Ch can be seen. This value correlates with the sectoroffset (see second line of Fig. 4) as 12258850816d/512d ¼ 23943068d or 16D579Ch.

Explaining the channel layout

Shown above is the first line, or groups of 2 QWORDs,at offset 02DAAF38F0h. The first byte is the only bytevalue that starts with a 1, representing the start of thechannel information. The second hex value in the firstbyte of each line represents the channel number. Thelocation of each channel's video data can be seen from

Fig. 4. Process Monitor output wh

the 3rd byte to the 6th byte and each of the subsequentchannels are offset from the last by the amount in the lastbyte of each line (in this case channel video is at sectoroffset 3A000024h and the next is offset by 0Eh from thisvalue 3A000032h).

Offsets to start of video data

Using the same logic, Procmon's output then shows aseek to byte offset 7400004800h (sector offset3A000024h). This value can be seen at offset F0h in Fig. 6.Repeating this analysis for all channels, the offset matchesthe sector shown in Fig. 6.

Putting it all together

Fig. 7 outlines the analysis. From the first sector, theoffset to the first event entry is shown F76Fh, this thenshows us the first date block 016D579Ch and in turn showsus all the channel data and the related video data sectoroffset 3A000024h.

To test this analysis, an applicationwas created that runsthrough all the events listed in the “event list” section ofthe disk. This application then generates a report of all theevents, all the video data, the related timestamps (inchronological order) and where each event is located onthe drive.

Testing

We created a Windows application called “Dis-kAccess”, written in C#. This application is shown in Fig. 8,at the moment DiskAccess is not currently available to thepublic.

en viewing the first entry.

Fig. 5. Sector showing entry data.

L. Tobin et al. / Digital Investigation 11 (2014) 179e186 183

The application is split into three panes, the leftmostpane shows the entry information, middle shows channelinformation and the rightmost pane shows video data. Asthe user selects a row from a pane, the row is parsed forbyte offsets and any panes to the right are refreshed withthe related data at the corresponding byte offsets.

DiskAccess runs through all the entries in the “eventlist” section of the disk, parsing the offsets using the in-formation acquired from the reverse engineering process. Areport is created, allowing us to validate the reverse engi-neering process by comparing the entries found with theentries from the proprietary software. The report shouldcontain the same amount of active entries that is reportedby the proprietary software, as the reverse engineeringprocess should mirror the behaviour of the proprietarysoftware.

Fig. 6. Sector showin

How DiskAccess works

To read the events found by the proprietary software,the application we created does the following:

1. Read sector F76Fh, this was found in Section 4.4.2. Read the entry in the event list, detailed in Section 4.4.3. Read channel data sector (16D579Ch in this first case),

detailed in Section 4.5.4. Find the channel with the leading “1” value indicating

the start of the channel data, see Section 4.6.5. Store the value indicating video data (location

3A00002h in this first case), detailed in Section 4.7.6. Goto step 5 and advance two QWORDs (the next row)

until the required amount of channels are found. Weknow there are 16 channels on this CCTV system.

g channel data.

Fig. 7. Overview of analysis.

L. Tobin et al. / Digital Investigation 11 (2014) 179e186184

7. Goto step 2, advance two QWORDs and repeat until nomore events are found. This algorithm will come to asection containing all zero values, this indicates the endof the event list section, see Section 4.4.

Building a tool such as this one enables us to recogniseand parse data structures on disk even if areas of the diskhave been partially overwritten or damaged. Also, thistype of application can provide a nice overview of howthe CCTV system writes data to the disk. In our case, datais written to the start of data sections and when the endof the section is reached the system seeks to the begin-ning of the section and overwrites the oldest data. Thisapplication gives a concise overview of the data on the500 GB disk.

Fig. 8. Application created

The DiskAccess application provides a report of the in-formation found on the disk. The report uncovered theexact same number of events as the DiskTools application,thus validating our reverse engineering process. Howeverwe are not merely rebuilding the same proprietary appli-cation functionality, we have far more information to workwith now after the reverse engineering process. The reportwill also show information regarding video data from olderevents if this video data is still available.

The table below is the informationprovided in the report.For the sake of brevity, only thefirst event is shown. The firstcolumn from table shows the timestamp information, thesecond column shows the channel number, then the sectoroffset to thedate entryand thefinal column shows the sectoroffset to the next date entry. All the values are hexadecimal.

to verify analysis.

Date Ch Sector offset Next date

0D0312003009 1 3A000024 3A0000320D0312003009 5 3A000032 3A00003F0D0312003009 9 3A00003F 3A00004C0D0312003009 D 3A00004C 3A0000580D0312003009 2 3A000058 3A00006C0D0312003009 6 3A00006C 3A00007B0D0312003009 A 3A00007B 3A0000890D0312003009 E 3A000089 3A0000950D0312003009 3 3A000095 3A0000A60D0312003009 7 3A0000A6 3A0000B30D0312003009 B 3A0000B3 3A0000C30D0312003009 F 3A0000C3 3A0000D00D0312003009 0 3A0000D0 3A0000E00D0312003009 4 3A0000E0 3A0000ED0D0312003009 8 3A0000ED 3A0000FB0D0312003009 C 3A0000FB 3A00010D

L. Tobin et al. / Digital Investigation 11 (2014) 179e186 185

Digging deeper

Once all the reported events are found, the applicationparses the events that are not displayed in Disktools andcompares the location of the related video data with thelocations of the reported video data. This information canuncover potential locations of older, unreported video data.A contrived and simplified example containing three re-ported events and one unreported event is shown in Fig. 9.Channel data is not shown, however channel data is ana-lysed by our application.

This figure shows two possible situations, the topshowing the video data for an event overwritten by newervideo data and below is an example showing the location ofvideo data of an unreported event that is potentiallyrecoverable. Based on the results of the reverse engineer-ing, DiskAccess allows an investigator to click on any of theevents found in the CCTV system and also events which arenot listed in the AVTECH proprietary software.

Fig. 9. Event recovery.

Extending the algorithm

We can extend the method explained in Section 5.1 toencompass older events in the event list. To do this we juststart the algorithmat thefirst event shownondisk, the eventsin our case started in sector 2, so therewere several thousandunreported events on disk. Running through the algorithmfrom this point we can cross-reference with the reportedevents. This way we can see if any video data remains.

The goal of this reverse engineering process was to findout if there was video data on the disk recorded before acertain date. With this in mind, we focused on the date andchannel information, not on the actual video data itself. Theinformation gathered by DiskAccess gives the investigatoran understanding of where the event data is written to ondisk, allowing the investigator to browse through the en-tries that the proprietary software does not show.

Conclusion and future work

A non-standard file system can be explained veryquickly using this practical “eavesdropping” approach.While this style of analysis is not novel, it is employed quiteregularly in the analysis of malware (Zeltser, 2010; Kendalland McMillan, 2007), it has yet to be used with unrecog-nised/proprietary file systems. Information about the filesystem can be extracted using this method and data can beinterpreted quickly and easily. The approach detailed in thispaper is not a file carving type approach. We are nottraversing the drive sector by sector or using any file systemto aid in the recovery, we are using the information gath-ered during the analysis to perform a deeper, more in-depth analysis of the data on the disk. This approach fo-cuses on the information gathered during the reverse en-gineering, in turn using this information to uncover andexplain more about the events and older event data on theCCTV disk.

For future development, it would be desirable to be ableto interpret the video data and allow for viewing of thisvideo data. The approach was outlined in a way to get themost information out of the system in the quickest amountof time while maintaining forensic rigour and precision. Inorder to fully understand the CCTV system, some moreanalysis would be required, for example how the systemknows where the offset to the first date entry is located. Inour reverse engineering we know this from first date entryshown in the proprietary software.

As explained earlier in the paper, this is not a file carvingapproach, and to be thorough, the investigator would haveto check that all areas of the CCTV drive have been exam-ined. This approach does uncover the areas of the disk thatthe proprietary software reads, and also uncovers the areasof the disk that are unreported. The report generated usingthe approach outlined in this paper provides a map ofwhere the video data resides, so the investigator can easilyunderstand where data is located on the disk.

It would be desirable to apply this approach to otherCCTV systems in order to further validate the findings. Evenso, we believe this approach could be used to understandand explain any non-standard file system, from practically

L. Tobin et al. / Digital Investigation 11 (2014) 179e186186

any system. This work is funded by Lero as part of the CSET2grant (10/CE/I1855).

References

Ariffin A, Slay J, Choo KK. Data recovery from proprietary formatted CCTVhard disks. In: Advances in Digital Forensics IX. Berlin Heidelberg:Springer; 2013. p. 213e23.

Dongen WSV. Case study: forensic analysis of a samsung digital videorecorder. J Digit Invest 2008;5:19e28.

Kendall K, McMillan C. Practical malware analysis. In: Black Hat Confer-ence, USA; 2007.

Poole NR, Zhou Q, Abatis P. Analysis of CCTV digital video recorder harddisk storage system. Digit Invest May 2008;5(1):85e92.

Russinovich M, Cogswell B. Microsoft, process monitor; 2013. Availablefrom, http://technet.microsoft.com/en-ie/sysinternals/bb896645.aspx.

Zeltser L. Reverse engineering malware. Retrieved June 13 (2001); 2010.