- Email: [email protected]
Case study: Forensic analysis of a Samsung digital video recorder
digital investigation 5 (2008) 19–28
available at www.sciencedirect.com
journal homepage: www.elsevier.com/locate/diin
Case study: Forensic analysis of a Samsung digital video recorder Wouter S. van Dongen Fox-IT Forensic IT Experts, Olof Palmestraat 6, 2616 LM Delft, The Netherlands
article info
abstract
Article history:
In May 2007, a case of potential child abuse was reported to the hospital where the
Received 22 October 2007
victim was under observation. The child had been in the hospital for several months
Received in revised form
and there was hope that a digital video recorder (DVR) may have recorded the
20 March 2008
maltreatment of a hospitalized child. Unfortunately the recordings could not be found
Accepted 1 April 2008
on the device by hospital security employees. The DVR was given to digital forensic examiners in an effort to recover footage. This article details how the system was
Keywords:
examined, describing the steps that were taken to obtain information and how the
Digital video recorder
information was interpreted. The methods described in this article can be applied to
DVR
other similar devices.
Digital video
ª 2008 Published by Elsevier Ltd.
MPEG-4 Hard disk recorder Video Carving Recovery Berkeley database BTree
1.
Background
In May 2007 it was presumed that in February 2007 a hospitalized child was possibly maltreated by its mother. The child was diagnosed with various forms of illness but the doctor could not find any definite cause. The doctors stated that the child might be suffering from Fabricated or Induced Illness, more commonly known as Munchausen Syndrome by Proxy (MSbP). In MSbP an individual falsifies or induces an illness in another person to achieve emotional satisfaction. This is a form of maltreatment (abuse and/or neglect) rather than a mental disorder. Children are the usual victims and the mother is the usual perpetrator (Dr. Feldman, 2007).
E-mail address: [email protected] 1742-2876/$ – see front matter ª 2008 Published by Elsevier Ltd. doi:10.1016/j.diin.2008.04.001
During the entire period of February the child was hospitalized. Two cameras in the child’s hospital room were connected to a digital video recorder (DVR) that had possibly recorded these events. By the end of February the hospital security decided to use the digital video recorder for other purposes in the hospital. Due to the slow progress of the child’s examination and the reporting of possible child abuse, the DVR had been used for almost a month for other purposes before any footage was viewed. Furthermore the hospital security was not entirely sure if any recordings had been made in the child’s room with the concerned device as no audit trail was maintained during this period. The alleged abuse took place between the 14th and 20th of February 2007. A quick examination by the hospital security
20
digital investigation 5 (2008) 19–28
revealed that no recordings on the DVR were available for the period when the child was possibly maltreated. Digital forensic examiners were asked to determine if recordings – or pieces of recordings – of the specified period resided on the DVR and to examine if footage could maliciously have been removed.
2.
Methodology
The digital forensics examiners in this case first performed a preliminary investigation to obtain an overall picture of the system’s properties, functionalities, settings and situation, and then used this information to develop a strategy for an effective technical investigation. The first step in the preliminary investigation was to identify the brand/type/model of the device. As part of this research process, digital forensics examiners collected as much information as possible concerning the device, components and similar devices. After this initial research, the device was opened, revealing two internal hard disks. Forensic images were created for each hard disks and the images were restored onto new hard disks and placed back into the device. In order to obtain an overall picture of the system’s functionalities and state, the system was booted. A separate hard disk was used for additional testing such as test recordings. To minimize the risk of mistakes while performing a preliminary inspection of the device, the digital forensics examiners regularly consulted the user manual for the DVR. After this live inspection, the evidence was examined using forensic software. The final step in the preliminary investigation was to use the information in order to construct methods for extracting lost footage from the device. During the technical investigation the examination and recovery methods constructed during the preliminary investigation were applied in the order most likely to recover lost footage. All results were documented and, where possible, the newly acquired knowledge was applied to other methods.
3.
Preliminary investigation
3.1.
System information and evidence preservation
The relevant DVR is a Samsung SHR-2040. The complete manual was downloaded from the manufacturer’s website (http:// www.samsung-security.com). This device is a multi-stream DVR that is capable of storing four video streams with audio on a hard disk. Video is compressed in MPEG-4 format and stored in a video file, and audio is compressed using ADPCM (Adaptive Differential Pulse Code Modulation) and, according to the manual, is stored in a separate audio file. The DVR is capable of transferring video and audio in real-time over a network so that monitoring is possible from a PC (Samsung, 2005). A label on the device indicated that it was manufactured in China by Tianjin Samsung Electronics in October 2006. After reviewing and documenting the DVR’s specifications, the system was opened for further investigation. Two 160 GB hard disks – specified as primary and secondary by the IDE
controller – were found. Both hard disks were imaged as a raw (dd) image and hashed using a LogiCube Talon kit (available from: http://www.logicubeforensics.com). After securing the original hard drives, the images were restored on two new 160 GB hard disks and placed back into the system. Two chips on the motherboard appeared to play a fundamental role in recording and playing footage. Both chips – a MultiStream IV AT2041 and a MultiQuad II AT4012E – were manufactured by a Korean company called PentaMicro.
3.2.
First boot
The system was booted for the first time with the duplicate hard drives in place and no cameras were attached. A separate hard disk was used for additional testing, such as test recordings. The main screen of the DVR software was divided into four sections, titled cam 01 up to cam 04. Camera 01 up to camera 03 displayed the status ‘V.loss’, while camera 04 displayed ‘V.off’. Compared to local time, the date and time shown was one hour behind. After pressing the search button, a calendar overview showed available footage from 2-25-2007 until 3-17-2007. The footage prior to March showed a woman and her baby but did not include the dates of interest on February 14th and 20th. This footage was recorded by two cameras in black and white without audio. Starting in March, the recordings showed a conference room in a different location. The conference room was recorded with three cameras in colour without audio. In the calendar view it was possible to select recordings per half hour. While playing the footage an icon with a ‘C’ is displayed. According to the manual this icon means that the footage is recorded in CIF (352 288 pixels) resolution. Besides CIF the DVR also supports Half D1 (720 288) formats. Under the menu button several settings and log files were found. Within the system section it was possible to view a system and an event log. The manual states that the system log shows records for the following actions:
System Start Login (admin) Logout (admin) Login(user) Logout(user) Setup Start (Local) Set Setup End (Local) Set Setup (remote): Viewer Playback Start Playback End Record Start CH[n] Record End CH[n] Power Failure Recovery Time Change Load Factory Default System upgrade Disk Full Backup Start Backup End Backup Stop Backup Fail
digital investigation 5 (2008) 19–28
ATA HDD Erase USB HDD Erase USB Memory Erase Overwrite Playback Sop Backup Stop(Overwrite)
Dozens of entries were stored in the system log starting on 12-27-2006 and ending on 6-26-2007. An overview of entries (only the most important entries are shown as the entire log file is too large) in the system log is provided here:
12-27-2006
12-29-2006
02-14-2007
02-16-2007 02-21-2007 03-01-2007
03-23-2007
05-10-2007
05-11-2007
05-15-2007
06-13-2007
First: 9:22:53, last: 9:25:51 System start [6 s] setup [50 s] several admin logins [within a 2 min period]. First: 12:45:43, last: 13:05:36 Login (admin), setup, playback start, playback end, setup, system shutdown, system start, setup, HDD Erase, Load factory, system shutdown, system start, setup start, setup end, system shutdown, system start, setup start, setup end, system shutdown. First: 13:58:25, last: 15:58:29 System start, setup start [5 min] setup end, login (admin) [1 hour] login admin [15 min] login (admin) [10 min] login (admin). First: 20:25:47, last: 20:27:27 Setup start, setup end. 8:29:49 Login (admin). First: 12:37:19, last: 14:12:57 System start, power failure recovery, setup start, setup end, several playback entries [few seconds between entries], setup start, setup end, system shutdown, system start, playback, login (admin), system start and power failure recovery [15 min] system start and power failure recovery. First: 15:48:27, last: 15:56:51 System start and power failure recovery, several playback entries [within 3 min period], system shutdown. First: 13:39:16, last: 14:03:07 System start [13 min] setup start [3 min] setup end, login (admin), login (admin). First: 06:06:59, last: 07-04-22 Login admin [52 min] several setups [within 2 min period]. First: 07:54:06, last: 10:17:27 System start, Backup start [6 min] Backup end, login (admin), system start and power failure recovery, login (admin). System start and power failure recovery, playback, setup [our own actions].
The event log records the events alarm, motion and video loss and contained only six entries: video loss for camera one, two, three and four on 12-29-2006 (a few seconds between entries) and video loss for camera one and two on 2-14-2006. Beside the system and event log files, the system section contained an option named ‘HDD mode’ which was set to
21
‘overwrite’. The manual states ‘Overwrite: Deletes the original data and saves new data when HDD is full during the recording’. The camera section showed that camera one, two and three were enabled without audio, and that the fourth camera was disabled. Within the record mode section the quality was set to ‘very high’, the rate was 5 IPS (images per second), and video size was set to CIF (352 288 pixels) format. The DVR in this case did not have an option to delete a specific recording, but had two ways to remove recordings. The first method was to perform an HDD erase, causing all footage and settings to be lost. The second method was to set the system clock back whereby all recordings after that date are removed. The DVR offers the functionality to create a backup of recordings in DVR or AVI format by using a start and end date. Entering a date not available on the system calendar proved futile to view unavailable footage from earlier in February.
3.3.
Image investigation
The raw (dd) images could not be loaded correctly in AccessData FTK 1.71 (available from: http://www.accessdata.com) because only raw data were displayed. The forensic images could be loaded in Encase 6.5 (http://www.guidancesoftware. com), but the program crashed frequently or showed file contents from a different file. AccessData FTK imager 2.5.1 (available from: http://www.accessdata.com) was able to process the forensic images and was used for further investigation. Both the primary and secondary hard disks were divided into three partitions of 1411, 196, 151,017 MB and formatted with the ext3 file system. The first partition on the primary hard drive contained the directories ‘‘etc’’ and ‘‘bin’’ that are standard on Linux. The ‘‘etc’’ directory contained an event and system log file and ‘‘dvr_config.txt’’ file. The ‘‘bin’’ directory contained the operating system such as executable files, kernel modules and log files. Beside these directories, the ‘‘root’’ directory contained 670 files with a ‘‘.db’’ and ‘‘.eve’’ extension. These files appeared to be used for the bookkeeping of the recordings on the hard disk. The filenames of these bookkeeping files were UNIX numeric timestamps. The first file was named ‘‘1172930400.eve/db’’ (March 3 at 14:00) and the last file was named ‘‘1174136400.eve/db’’ (March 17 at 13:00). The bookkeeping filenames matched the last modified timestamps of the files. Therefore, a good overview could be obtained by sorting the bookkeeping files by the last modified date. From this perspective, the first modification date was March 3 at 14:20 and the last was March 17 at 13:26 and, between these dates, a new set of ‘‘.db’’ and ‘‘.eve’’ files were created every hour. The .db files contained many UNIX timestamps in 32 bit hexadecimal, little endian format. Beside the bookkeeping files, an empty file named ‘‘overwrite’’ was found in the ‘‘root’’ directory. This ‘‘overwrite’’ file had the exact same modification time (March 3 at 14:20) as the first bookkeeping file. An additional 516 bookkeeping files were stored on the first partition of the secondary hard disk. In addition to the ‘‘.db’’ and ‘‘.eve’’ files, there was an ‘‘overwrite’’ file with the modification date of March 17 at 13:26. The first bookkeeping file was named ‘‘1172422800.eve/db’’ (February 25 at 17:00) and
22
digital investigation 5 (2008) 19–28
the last file was named ‘‘1174557600.eve/db’’ (March 22 at 10:00). When sorting the files by the modification date, two bookkeeping file periods were observed. The first period dated from the February 25 at 17:00 through March 3 at 14:20. The second period started on the March 17 at 13:26 and ended on March 22 at 11:09. On both hard disks data were found in the unallocated space of the first partition. Parts of the data in the unallocated space were very similar in structure to the stored ‘‘.db’’ files (Fig. 1). Besides an empty directory named ‘‘lostþfound’’ and an empty file named ‘‘PREALARM,’’ no files or directories with any useful information were found on the second partition of both hard drives. The third partition on both the hard drives contained a 146 GB file named ‘‘MPEG_STREAM.’’ A review of these files and some experiments in VLC media player did not reveal any information. No headers of any kind were found in the ‘‘MPEG_STREAM’’ files and several MPEG repair and detections tools were not able to decompress/detect/extract/decode anything from the ‘‘MPEG_STREAM’’ file (Fig. 2).
3.4.
Assumptions and steps to take
3.4.1.
Putting the information together
The modification date of the last bookkeeping file on the primary hard disk matched the modification date of the ‘overwrite’ file on the secondary hard disk. The modification date of the last bookkeeping file of the first period matched the one of the ‘overwrite’ files stored on the primary hard disk. Based on this information, and since the DVR was set to ‘overwrite’ mode it is most likely that the ‘overwrite’ files indicate when a video stream hopped from one disk to the other to start overwriting. The ‘overwrite’ file on the primary hard disk was written before the bookkeeping files. Therefore, it can be assumed that the stream on the primary hard disk is completely overwritten. By looking at the dates of the bookkeeping files digital forensics examiners determined that these were the ‘new’ recordings of the conference room. On March 17 at 13:26 the primary disk was full and also started overwriting on the secondary hard disk. Therefore, recordings from February 25 at 17:00 through March 3 at 14:20 had not been overwritten yet (Fig. 3). The system log file indicated that the system was first booted on December 27, 2006. Due to the amount and duration
of the log entries this was probably for some quick testing. Both the event and system log show that on December 29 probably more testing was done and then the system was restored back to its original state. The system was shutdown and was not booted until February 14, 2007. No digital traces were found between December 27 and February 14. Many log entries are found for February 14 and March 1, 2007. Therefore February 14 is probably the date when the system started recording. Since no interesting log files were found between February 14 and March 1, it can be presumed that two cameras recorded the child’s room until the first of March. On March 1, the system was set up to record the conference room and recorded through to March 23 with three cameras attached. Log entries of May are likely originated from the hospital security staff attempting to locate the footage of interest. According to the manual the system should log recording events, but these were not found in the log files. A quick test recording showed that these events were not being logged by the system. The one hour difference between the local time and the time displayed by the DVR was probably due to Daylight Savings Time. See Fig. 4 for a graphical display of the assembled events. At this point of the forensic examination no indications of any malicious activities had been found. The system log clearly records time changes and HDD erases and no such events were logged. Furthermore, the dates and times of log files and footage match. The system showed records since the first boot, just two months after the manufacture date. Therefore it is unlikely that the system was tampered with by a person with no forensic computing experience. A large portion of the old footage appears to have been overwritten. It is not clear how the system overwrites a previous recording and for that reason it was not known whether old recordings might reside on the system.
3.4.2.
Steps to take
Data structures that resemble the ‘‘.db’’ bookkeeping files were found in the unallocated space of the hard disks. Restoring the old bookkeeping files was the best chance to successfully view old footage. The timestamps within the recovered ‘‘.db’’ files would provide a good overview of the recording course on the hard disks. The second method was to create a new recording, copy the old video stream over the created video stream and try to play the old video stream with use
Fig. 1 – Screenshot of FTK imager. Example of bookkeeping files on the first partition of both hard disks.
digital investigation 5 (2008) 19–28
23
Fig. 2 – Screenshot of FTK imager; both raw (dd) images loaded in FTK imager showing the partition and directory structure.
of the new bookkeeping files. If these methods proved to be unsuccessful, more time consuming methods would be required. Reverse engineering ‘‘.db’’ files and manually creating ‘‘.db’’ files with perhaps the right pointers is one of these methods. Trying to play, de-multiplex and transcode the entire video stream was the final method. As most system activities are logged, recovering log files that may have been removed would be a good indication of whether recordings were removed.
4.
Technical investigation
4.1.
Recovering old bookkeeping files
4.1.1.
The recovery attempt
The ‘‘.db’’ bookkeeping files had a distinctive file header, but no footer. The bytes of the file header were also stored further in the file. Therefore the second header match must be set to be ignored when carving. All ‘‘.db’’ files found on the primary hard disk had a fixed file size of 166 kB. The ‘‘.db’’ files on the secondary hard disk had a fixed file size of 548 kB. It is not
Fig. 3 – The course of the recordings on the hard disks.
clear why the ‘‘.db’’ files on both hard disks differ in size. With this information, Foremost (http://foremost.sourceforge. net) was used to recover bookkeeping files on both disks. In order to give the recovered files the correct filename a Perl script was written. This Perl script located the first timestamp, a UNIX 32 bit hex value, stored within the recovered file and renamed the file to the equivalent UNIX numeric time. In addition, the corresponding event (.eve) file was generated. After restoring the original filenames of all recovered bookkeeping files the recording periods were made insightful. On the primary hard disk, two bookkeeping periods were recovered. The first period was from December 24 through 27, 2006. This period was not carved consequently for every hour. The second period started on March 20 at 19:00 and ended on March 22 at 9:00. The second period was carved very consequent, for every hour in this period a ‘‘.db’’ file was found. On the secondary hard disk, ‘‘.db’’ files from February 24 at 6:00 to February 25 at 18:00 were carved consequently. No bookkeeping files were found for February 14–20 when the events presumably took place. With the use of this information the old and current recording situation is shown in Fig. 5. The recovered bookkeeping files for February 24 and 25, 2007 were placed on the secondary duplicate hard disk and the DVR was booted. Once the system was booted the interface showed no option to play these dates. The DVR was powered off and the hard disk was mounted on a computer to see what had happened. The DVR appeared to have removed all the recovered files. This was probably due to the fact the system was set to ‘Overwrite’ mode and had removed the oldest recordings. Therefore all the bookkeeping files of March were removed and the recovered files were placed back. Once the DVR was booted the calendar overview showed that the recovered recordings were able to be viewed. Unfortunately the system showed a black screen and stopped responding
24
digital investigation 5 (2008) 19–28
Fig. 4 – Timeline.
when one of the recovered bookkeeping files was selected. Even when trying to play footage from February 25 at 17:30 proved unsuccessful, despite the fact that February 25 at 17:30 is only half an hour before the last available footage that has not been overwritten yet. Therefore, this recording moment has the highest potential of successfully being recovered. To be certain that the recovery with Foremost was performed properly, carved bookkeeping files of available recording periods were placed on the hard disk. All of these files did work, for this reason it is assumed that the carving method was performed properly.
4.1.2.
Result explanation
In order to give a logical explanation for the result of the recovery attempt, the DVR’s overwrite functionality was further examined. The DVR presumably allocates a part of the video stream to overwrite when the hard disk is full. Such allocation of space
Fig. 5 – Old and current recording situation.
could be performed in real-time or by the day, hour or perhaps by the minute. To find out how the DVR allocates space the system started recording with two cameras attached with HDD mode ‘Overwrite’ switched off. The DVR was set to raise an alarm and stop recording when the disk was full. With this setting it was possible to check if the system already allocated space or if this was done real-time. If allocation of space was real-time the system would immediately raise an alarm as no space was left to record on. The DVR stopped recording and raised an alarm after 1.5 min. At this point the system was completely full and first had to allocate space before it could start recording again. Therefore the system was set back to HDD mode ‘Overwrite’, started and manually stopped after 3 s of recording. The interface of the DVR showed that the footage from February 25 at 17:00 until 18:00 was not available anymore. Thus it was determined that space is allocated by the hour. In order to find out if it is possible to view footage that has been removed by the allocation process, the new bookkeeping files were removed and the old files restored. It proved possible to view a big part of the ‘removed’ footage. If this theory was correct it should have been possible to view some footage (maximum of an hour) before February 25 at 17:00. Therefore recovered bookkeeping files of 16:00 and 17:00 were placed on the DVR; then 17:00 was selected and rewinded back as far as possible. At 16:57:32 rewinding stopped and played 2.5 min of ‘removed’ footage.
4.2.
Recovering log files
4.2.1.
The recovery attempt
The system log file has the same structure as the ‘‘.db’’ bookkeeping files. For the recovery attempt a distinctive header and a fixed size of 10 kB was used by Foremost. One removed system log file was recovered and was copied over the system log file on the primary hard disk. The DVR was booted and the log file was successfully showed by the log viewer. The recovered log file solely contained entries of December 26, 2006 with a few quick admin logins.
digital investigation 5 (2008) 19–28
25
Fig. 6 – Example of the contents of an event file opened in a hex editor.
4.2.2.
Result explanation
The system was probably used for some quick testing and was restored back to its original state, removing all data. No log files containing possible malicious activities, such as time change and HDD formats, have been found on the system.
4.3.
Copying video streams
At this point in the forensic examination, the chances of recovering more video than 2.5 min are very slim. However, for the purpose of this paper and possible similar future investigations, more methods were tested. Since every DVR brand is different, one method may be preferred over the others.
4.3.1.
footage resulted in the same results as the first attempt. Fortunately the DVR was powered off quickly enough to avoid damaging the hard disk.
4.3.2.
Result explanation
The ‘‘.db’’ bookkeeping files contain many timestamps and presumably also pointers to locations in the ‘‘MPEG_STREAM’’ file. Timestamps could be checked within the ‘‘MPEG_ STREAM’’ if they correspond with the timestamp from the bookkeeping files. The ‘‘.db’’ bookkeeping files are further examined in the next paragraph.
4.4.
A closer look at the bookkeeping files
4.4.1.
The recovery attempt
The recovery attempt
An empty hard disk was placed in the DVR and was automatically formatted by the system. One camera without audio was set to start recording for 1 h. After this hour the hard disk was mounted on a computer and the created ‘‘MPEG_STREAM’’ file on the third partition was overwritten by the original ‘‘MPEG_ STREAM’’ file of the primary hard disk. The hard disk was placed back in the system and booted. While trying to play footage, a black screen was displayed and the DVR stopped responding. Although the DVR stopped responding, the hard drive LED indicated a lot of hard disk activity as if it was searching. After a few seconds of waiting, the hard disk started to make a ticking sound. This system was immediately powered off as this sound certainly was not correct. The hard disk turned out to be broken. The recovery attempt was repeated with the use of three cameras because it is known that all footage on the primary hard disk was recorded by three cameras. Trying to play
Two types of bookkeeping files were found, with ‘‘.db’’ and ‘‘.eve’’ extensions. The purpose of both bookkeeping files became clear based on examination of test recordings. When a recording starts, the ‘‘.eve’’ and ‘‘.db’’ files are generated. Both bookkeeping files have a numeric UNIX timestamp as filename, containing the recording date/time rounded down to the full hour. When a recording starts at 14:20 a timestamp is made for 14:00. The generated ‘‘.db’’ file is filled with data during the recording hour. The ‘‘.eve’’ file stays untouched after it is generated. The ‘‘.eve’’ – event – files do not hold much valuable information, except for their timestamp they are almost all the same. The event files are responsible for notifying the DVR if there is footage available for a specific hour. The timestamp found within the event files matches the timestamp of the corresponding filename (Fig. 6).
Fig. 7 – Sample structure of .db file viewed within a hex editor. The green frame is a 32 byte block. The repeated bytes are underlined. The timestamp is framed in blue. (For interpretation of the references to colour in this figure legend, the reader is referred to the web version of this article.)
26
digital investigation 5 (2008) 19–28
Fig. 8 – Example of a simple .db file dump.
The ‘‘.db’’ files were first examined in a hex editor. The ‘‘.db’’ files are divided in blocks of 1024 bytes. Each block has a header which is the same for every block in every file. Only the first block has a different header, but equals to all other first blocks from other ‘‘.db’’ files. Within a block a number of bytes are repeatedly found in the same pattern. Each block is subdivided into smaller blocks of 32 bytes, starting with the bytes ‘‘10 00 01.’’ The bytes ‘‘08 00 01’’ with a 32 byte block precede every timestamp. Three 32 byte blocks were found for every second (according to its timestamps). The examined ‘‘.db’’ file belongs to recordings made by three cameras. Therefore the ‘‘.db’’ file presumably contains
pointers for every second and every camera to the ‘‘MPEG_ STREAM’’ file. The byte directly after ‘‘10 00 01’’ is probably the camera. The beginning of a 1024 byte block with the header and the 32 byte blocks within is shown in Fig. 7. As the file extension indicates, the ‘‘.db’’ file is clearly some kind of database file. Perhaps all the contents could be readily dumped with a tool. First the database/file type had to be identified. For identification the ‘file’ function under Ubuntu Linux was used. The ‘‘.db’’ file was identified as a Berkeley database, BTree version 8. After searching the internet it turned out that a Berkeley DB tool suite is available for Linux. This tool suit contains a function called db_dump whereby it was possible to dump ‘‘.db’’ files. The function db_dump supports a simple and more detailed dump. Both dumps were used to obtain a better picture of functioning of a ‘‘.db’’ bookkeeping file. A sample of both dumps of the same part of a ‘‘.db’’ file is shown in Figs. 8 and 9. In order to understand the ‘‘.db’’ files they had to be stripped down as far as possible. Simply removing pages (the detailed ‘‘.db’’ dump showed that a 1024 byte block is called a page) resulted in a corrupt ‘‘.db’’ file that could not be recognized by the DVR. Therefore a more cautious method was required. The headers were made clear by over and over changing bytes and dumping the file. The results of these actions are shown in Figs. 10 and 11. In addition to identifying header bytes, the whole structure of the file was made clear in this way. The ‘‘.db’’ file starts with a header (see Fig. 10) followed by the first page which is identified as the ‘BTree internal’ section. This is actually the ‘top’ of the tree and divides the file down in branches and leaves. The
Fig. 9 – Example of a detailed .db file dump.
digital investigation 5 (2008) 19–28
27
Fig. 10 – Example of the file header of a .db file and the meaning of the bytes.
‘BTree internal’ section functions like an index in a book and points to branches in order to offer fast data access. A branch section starts with a header specified as ‘BTree leaf’ (see Fig. 11) containing the data leaves (32 byte data blocks). With this information it was possible to create a stripped down ‘‘.db’’ file. Starting with a Berkeley Db file header, followed by zero bytes until 1024 bytes (size of one page). Next, without a top level ‘BTree internal section’ – a branch (starting with BTree leaf header) section of 1024 bytes (1 page) containing only one leaf (32 bytes) is followed. The BTree internal section was left out because it had no use in such a small file. Correct page and entry information in the headers (see Figs. 10 and 11) was very important. Wrong page or entry information resulted in a corrupt file. As the .db file was stripped down, it was time to try to alter the leaf information (see Fig. 12). Altering the timestamp in the leaf by only one second caused the ‘‘.db’’ file to be invisible in the DVR interface. All other bytes, with the exception of the bytes ‘‘10 00 01’’ and ‘‘80 00 01,’’ could be changed without any noticeable result. Looking for pointers also turned out to be futile.
4.4.2.
Result explanation
Apart from being a timestamp, it is not clear what information is held in a leaf (32 byte block). Test recordings showed audio is not stored in a separate file as the manual states. Therefore some of these bytes could indicate whether a recording contains sound or not. Although seeking for offsets was unsuccessful, the most logical explanation is that these bytes do represent pointers. The bookkeeping files have to be present in order to view footage. No other artefacts regarding viewing
the video stream have been found. Perhaps a part of the information in the leaf is converted to a pointer with of some kind of function.
4.5.
Playing the entire video stream
4.5.1.
The recovery attempt
Preceding attempts to play the ‘‘MPEG_STREAM’’ file did not work, see Section 3.2. A new test recording with one camera without audio was made for testing purposes. Opening the created video file in a hex editor showed, contrary to the preliminary investigation, a structure. A file header followed by two different sections that could easily be separated from the rest of the data. These sections are probably headers. The only programs which were able to identify the ‘‘MPEG_STREAM’’ file were Transcode (available from: http:// www.transcoding.org, only version 1.02 worked) and Mencoder (available from: http://www.mplayerhq.hu). Both files identified the file as a digital video format. Despite all the efforts, no footage could be revealed with the use of these programs. Attempts to change the file header to headers of other similar video files were also fruitless. By using the DVR’s backup functionality the test footage was exported to DVR format. By viewing the exported file and the ‘‘MPEG_STREAM’’ in a hex editor showed remarkable resemblance in their structure. The two mentioned sections (headers) started and ended at exactly the same offsets. Besides this the exported file and the ‘‘MPEG_STREAM’’ file only differ 152 bytes in size. Another test recording with the use of three cameras showed the same result. The three exported recordings’ files together matched the file size of
Fig. 11 – Example of a page header (BTree leaf) within a .db file a the meaning of the bytes.
28
digital investigation 5 (2008) 19–28
Fig. 12 – Sample leaf.
the ‘‘MPEG_STREAM’’ file. The exported file was not created by a simple substitute code of the ‘‘MPEG_STREAM’’ file. Both video processing chips found within the DVR were manufactured by PentaMicro. A look at the website of PentaMicro (http://www.pentamicro.com) revealed that there is a Reference Design Kit (RDK) available. PentaMicro’s RDK implies a complete solution for the embedded DVR developer including the functionality to view an entire video stream. PentaMicro was contacted to ask if they were able to view a test recording of the DVR. PentaMicro’s support quickly replied notifying that they were not able to view the file because the stream ID did not match their own stream ID. Altering the stream ID to their own did not work either. PentaMicro assumed that Samsung created their own streaming method. PentaMicro stated that the ‘‘MPEG_STREAM’’ file probably holds the PES (Packetized Elementary Stream) format. Research into PES files showed that the header holds several timing references such as DTS (decoding timestamp) and ESCR (elementary stream clock reference). No useful information regarding viewing or converting PES files was found. Samsung was not willing to help in any way, and would not provide any information about the functioning of the DVR system. Samsung stated they cannot decode the video stream for any kind of reason.
4.5.2.
Result explanation
Samsung probably created a proprietary video stream that cannot be viewed without deeper knowledge of the functioning of the system.
reside in the proprietary ‘‘MPEG_STREAM’’ file, it is highly likely that no lost recordings reside on the DVR. The system was set to overwrite mode and had most likely overwritten all footage (except 2.5 min) before February 25, 2007. Furthermore, it is highly plausible that the system did not record anything on February 14 through 20, 2007. No bookkeeping files or even bits of bookkeeping file were found for this period. All other recovered bookkeeping files were entirely recovered without missing pieces. Therefore the DVR that was examined might not be the device that actually recorded the events, or perhaps no recordings were made at all. The lax documentation and tracking of DVR used in the hospital could have led to the misidentification of the relevant DVR system. No indications of malicious tampering attempts were found. It is highly unlikely that someone without an extensive knowledge of computers and a deeper knowledge of the functioning of the system, would be able to tamper with a DVR in such a way that no traces of these activities would remain on the system. Because no evidence was found against the defendant, she was acquitted of all charges. This case example demonstrates the importance of forensic preparedness within an organization. With proper documentation and tracking of the use of DVR’s, and with preservation procedures after each use, it would have been possible to determine whether relevant footage had been recorded.
references
5.
Conclusion
An in-depth forensic examination of the DVR in this case did not find any traces of recordings from the period of interest. Although it is not possible to be certain that no lost recordings
Feldman Marc. Munchausen by proxy. Available from:; 2007. Samsung. Real time DVR, SHR-2040/2041/2042 User’s manual. Available from: ; 2005.
available at www.sciencedirect.com
journal homepage: www.elsevier.com/locate/diin
Case study: Forensic analysis of a Samsung digital video recorder Wouter S. van Dongen Fox-IT Forensic IT Experts, Olof Palmestraat 6, 2616 LM Delft, The Netherlands
article info
abstract
Article history:
In May 2007, a case of potential child abuse was reported to the hospital where the
Received 22 October 2007
victim was under observation. The child had been in the hospital for several months
Received in revised form
and there was hope that a digital video recorder (DVR) may have recorded the
20 March 2008
maltreatment of a hospitalized child. Unfortunately the recordings could not be found
Accepted 1 April 2008
on the device by hospital security employees. The DVR was given to digital forensic examiners in an effort to recover footage. This article details how the system was
Keywords:
examined, describing the steps that were taken to obtain information and how the
Digital video recorder
information was interpreted. The methods described in this article can be applied to
DVR
other similar devices.
Digital video
ª 2008 Published by Elsevier Ltd.
MPEG-4 Hard disk recorder Video Carving Recovery Berkeley database BTree
1.
Background
In May 2007 it was presumed that in February 2007 a hospitalized child was possibly maltreated by its mother. The child was diagnosed with various forms of illness but the doctor could not find any definite cause. The doctors stated that the child might be suffering from Fabricated or Induced Illness, more commonly known as Munchausen Syndrome by Proxy (MSbP). In MSbP an individual falsifies or induces an illness in another person to achieve emotional satisfaction. This is a form of maltreatment (abuse and/or neglect) rather than a mental disorder. Children are the usual victims and the mother is the usual perpetrator (Dr. Feldman, 2007).
E-mail address: [email protected] 1742-2876/$ – see front matter ª 2008 Published by Elsevier Ltd. doi:10.1016/j.diin.2008.04.001
During the entire period of February the child was hospitalized. Two cameras in the child’s hospital room were connected to a digital video recorder (DVR) that had possibly recorded these events. By the end of February the hospital security decided to use the digital video recorder for other purposes in the hospital. Due to the slow progress of the child’s examination and the reporting of possible child abuse, the DVR had been used for almost a month for other purposes before any footage was viewed. Furthermore the hospital security was not entirely sure if any recordings had been made in the child’s room with the concerned device as no audit trail was maintained during this period. The alleged abuse took place between the 14th and 20th of February 2007. A quick examination by the hospital security
20
digital investigation 5 (2008) 19–28
revealed that no recordings on the DVR were available for the period when the child was possibly maltreated. Digital forensic examiners were asked to determine if recordings – or pieces of recordings – of the specified period resided on the DVR and to examine if footage could maliciously have been removed.
2.
Methodology
The digital forensics examiners in this case first performed a preliminary investigation to obtain an overall picture of the system’s properties, functionalities, settings and situation, and then used this information to develop a strategy for an effective technical investigation. The first step in the preliminary investigation was to identify the brand/type/model of the device. As part of this research process, digital forensics examiners collected as much information as possible concerning the device, components and similar devices. After this initial research, the device was opened, revealing two internal hard disks. Forensic images were created for each hard disks and the images were restored onto new hard disks and placed back into the device. In order to obtain an overall picture of the system’s functionalities and state, the system was booted. A separate hard disk was used for additional testing such as test recordings. To minimize the risk of mistakes while performing a preliminary inspection of the device, the digital forensics examiners regularly consulted the user manual for the DVR. After this live inspection, the evidence was examined using forensic software. The final step in the preliminary investigation was to use the information in order to construct methods for extracting lost footage from the device. During the technical investigation the examination and recovery methods constructed during the preliminary investigation were applied in the order most likely to recover lost footage. All results were documented and, where possible, the newly acquired knowledge was applied to other methods.
3.
Preliminary investigation
3.1.
System information and evidence preservation
The relevant DVR is a Samsung SHR-2040. The complete manual was downloaded from the manufacturer’s website (http:// www.samsung-security.com). This device is a multi-stream DVR that is capable of storing four video streams with audio on a hard disk. Video is compressed in MPEG-4 format and stored in a video file, and audio is compressed using ADPCM (Adaptive Differential Pulse Code Modulation) and, according to the manual, is stored in a separate audio file. The DVR is capable of transferring video and audio in real-time over a network so that monitoring is possible from a PC (Samsung, 2005). A label on the device indicated that it was manufactured in China by Tianjin Samsung Electronics in October 2006. After reviewing and documenting the DVR’s specifications, the system was opened for further investigation. Two 160 GB hard disks – specified as primary and secondary by the IDE
controller – were found. Both hard disks were imaged as a raw (dd) image and hashed using a LogiCube Talon kit (available from: http://www.logicubeforensics.com). After securing the original hard drives, the images were restored on two new 160 GB hard disks and placed back into the system. Two chips on the motherboard appeared to play a fundamental role in recording and playing footage. Both chips – a MultiStream IV AT2041 and a MultiQuad II AT4012E – were manufactured by a Korean company called PentaMicro.
3.2.
First boot
The system was booted for the first time with the duplicate hard drives in place and no cameras were attached. A separate hard disk was used for additional testing, such as test recordings. The main screen of the DVR software was divided into four sections, titled cam 01 up to cam 04. Camera 01 up to camera 03 displayed the status ‘V.loss’, while camera 04 displayed ‘V.off’. Compared to local time, the date and time shown was one hour behind. After pressing the search button, a calendar overview showed available footage from 2-25-2007 until 3-17-2007. The footage prior to March showed a woman and her baby but did not include the dates of interest on February 14th and 20th. This footage was recorded by two cameras in black and white without audio. Starting in March, the recordings showed a conference room in a different location. The conference room was recorded with three cameras in colour without audio. In the calendar view it was possible to select recordings per half hour. While playing the footage an icon with a ‘C’ is displayed. According to the manual this icon means that the footage is recorded in CIF (352 288 pixels) resolution. Besides CIF the DVR also supports Half D1 (720 288) formats. Under the menu button several settings and log files were found. Within the system section it was possible to view a system and an event log. The manual states that the system log shows records for the following actions:
System Start Login (admin) Logout (admin) Login(user) Logout(user) Setup Start (Local) Set Setup End (Local) Set Setup (remote): Viewer Playback Start Playback End Record Start CH[n] Record End CH[n] Power Failure Recovery Time Change Load Factory Default System upgrade Disk Full Backup Start Backup End Backup Stop Backup Fail
digital investigation 5 (2008) 19–28
ATA HDD Erase USB HDD Erase USB Memory Erase Overwrite Playback Sop Backup Stop(Overwrite)
Dozens of entries were stored in the system log starting on 12-27-2006 and ending on 6-26-2007. An overview of entries (only the most important entries are shown as the entire log file is too large) in the system log is provided here:
12-27-2006
12-29-2006
02-14-2007
02-16-2007 02-21-2007 03-01-2007
03-23-2007
05-10-2007
05-11-2007
05-15-2007
06-13-2007
First: 9:22:53, last: 9:25:51 System start [6 s] setup [50 s] several admin logins [within a 2 min period]. First: 12:45:43, last: 13:05:36 Login (admin), setup, playback start, playback end, setup, system shutdown, system start, setup, HDD Erase, Load factory, system shutdown, system start, setup start, setup end, system shutdown, system start, setup start, setup end, system shutdown. First: 13:58:25, last: 15:58:29 System start, setup start [5 min] setup end, login (admin) [1 hour] login admin [15 min] login (admin) [10 min] login (admin). First: 20:25:47, last: 20:27:27 Setup start, setup end. 8:29:49 Login (admin). First: 12:37:19, last: 14:12:57 System start, power failure recovery, setup start, setup end, several playback entries [few seconds between entries], setup start, setup end, system shutdown, system start, playback, login (admin), system start and power failure recovery [15 min] system start and power failure recovery. First: 15:48:27, last: 15:56:51 System start and power failure recovery, several playback entries [within 3 min period], system shutdown. First: 13:39:16, last: 14:03:07 System start [13 min] setup start [3 min] setup end, login (admin), login (admin). First: 06:06:59, last: 07-04-22 Login admin [52 min] several setups [within 2 min period]. First: 07:54:06, last: 10:17:27 System start, Backup start [6 min] Backup end, login (admin), system start and power failure recovery, login (admin). System start and power failure recovery, playback, setup [our own actions].
The event log records the events alarm, motion and video loss and contained only six entries: video loss for camera one, two, three and four on 12-29-2006 (a few seconds between entries) and video loss for camera one and two on 2-14-2006. Beside the system and event log files, the system section contained an option named ‘HDD mode’ which was set to
21
‘overwrite’. The manual states ‘Overwrite: Deletes the original data and saves new data when HDD is full during the recording’. The camera section showed that camera one, two and three were enabled without audio, and that the fourth camera was disabled. Within the record mode section the quality was set to ‘very high’, the rate was 5 IPS (images per second), and video size was set to CIF (352 288 pixels) format. The DVR in this case did not have an option to delete a specific recording, but had two ways to remove recordings. The first method was to perform an HDD erase, causing all footage and settings to be lost. The second method was to set the system clock back whereby all recordings after that date are removed. The DVR offers the functionality to create a backup of recordings in DVR or AVI format by using a start and end date. Entering a date not available on the system calendar proved futile to view unavailable footage from earlier in February.
3.3.
Image investigation
The raw (dd) images could not be loaded correctly in AccessData FTK 1.71 (available from: http://www.accessdata.com) because only raw data were displayed. The forensic images could be loaded in Encase 6.5 (http://www.guidancesoftware. com), but the program crashed frequently or showed file contents from a different file. AccessData FTK imager 2.5.1 (available from: http://www.accessdata.com) was able to process the forensic images and was used for further investigation. Both the primary and secondary hard disks were divided into three partitions of 1411, 196, 151,017 MB and formatted with the ext3 file system. The first partition on the primary hard drive contained the directories ‘‘etc’’ and ‘‘bin’’ that are standard on Linux. The ‘‘etc’’ directory contained an event and system log file and ‘‘dvr_config.txt’’ file. The ‘‘bin’’ directory contained the operating system such as executable files, kernel modules and log files. Beside these directories, the ‘‘root’’ directory contained 670 files with a ‘‘.db’’ and ‘‘.eve’’ extension. These files appeared to be used for the bookkeeping of the recordings on the hard disk. The filenames of these bookkeeping files were UNIX numeric timestamps. The first file was named ‘‘1172930400.eve/db’’ (March 3 at 14:00) and the last file was named ‘‘1174136400.eve/db’’ (March 17 at 13:00). The bookkeeping filenames matched the last modified timestamps of the files. Therefore, a good overview could be obtained by sorting the bookkeeping files by the last modified date. From this perspective, the first modification date was March 3 at 14:20 and the last was March 17 at 13:26 and, between these dates, a new set of ‘‘.db’’ and ‘‘.eve’’ files were created every hour. The .db files contained many UNIX timestamps in 32 bit hexadecimal, little endian format. Beside the bookkeeping files, an empty file named ‘‘overwrite’’ was found in the ‘‘root’’ directory. This ‘‘overwrite’’ file had the exact same modification time (March 3 at 14:20) as the first bookkeeping file. An additional 516 bookkeeping files were stored on the first partition of the secondary hard disk. In addition to the ‘‘.db’’ and ‘‘.eve’’ files, there was an ‘‘overwrite’’ file with the modification date of March 17 at 13:26. The first bookkeeping file was named ‘‘1172422800.eve/db’’ (February 25 at 17:00) and
22
digital investigation 5 (2008) 19–28
the last file was named ‘‘1174557600.eve/db’’ (March 22 at 10:00). When sorting the files by the modification date, two bookkeeping file periods were observed. The first period dated from the February 25 at 17:00 through March 3 at 14:20. The second period started on the March 17 at 13:26 and ended on March 22 at 11:09. On both hard disks data were found in the unallocated space of the first partition. Parts of the data in the unallocated space were very similar in structure to the stored ‘‘.db’’ files (Fig. 1). Besides an empty directory named ‘‘lostþfound’’ and an empty file named ‘‘PREALARM,’’ no files or directories with any useful information were found on the second partition of both hard drives. The third partition on both the hard drives contained a 146 GB file named ‘‘MPEG_STREAM.’’ A review of these files and some experiments in VLC media player did not reveal any information. No headers of any kind were found in the ‘‘MPEG_STREAM’’ files and several MPEG repair and detections tools were not able to decompress/detect/extract/decode anything from the ‘‘MPEG_STREAM’’ file (Fig. 2).
3.4.
Assumptions and steps to take
3.4.1.
Putting the information together
The modification date of the last bookkeeping file on the primary hard disk matched the modification date of the ‘overwrite’ file on the secondary hard disk. The modification date of the last bookkeeping file of the first period matched the one of the ‘overwrite’ files stored on the primary hard disk. Based on this information, and since the DVR was set to ‘overwrite’ mode it is most likely that the ‘overwrite’ files indicate when a video stream hopped from one disk to the other to start overwriting. The ‘overwrite’ file on the primary hard disk was written before the bookkeeping files. Therefore, it can be assumed that the stream on the primary hard disk is completely overwritten. By looking at the dates of the bookkeeping files digital forensics examiners determined that these were the ‘new’ recordings of the conference room. On March 17 at 13:26 the primary disk was full and also started overwriting on the secondary hard disk. Therefore, recordings from February 25 at 17:00 through March 3 at 14:20 had not been overwritten yet (Fig. 3). The system log file indicated that the system was first booted on December 27, 2006. Due to the amount and duration
of the log entries this was probably for some quick testing. Both the event and system log show that on December 29 probably more testing was done and then the system was restored back to its original state. The system was shutdown and was not booted until February 14, 2007. No digital traces were found between December 27 and February 14. Many log entries are found for February 14 and March 1, 2007. Therefore February 14 is probably the date when the system started recording. Since no interesting log files were found between February 14 and March 1, it can be presumed that two cameras recorded the child’s room until the first of March. On March 1, the system was set up to record the conference room and recorded through to March 23 with three cameras attached. Log entries of May are likely originated from the hospital security staff attempting to locate the footage of interest. According to the manual the system should log recording events, but these were not found in the log files. A quick test recording showed that these events were not being logged by the system. The one hour difference between the local time and the time displayed by the DVR was probably due to Daylight Savings Time. See Fig. 4 for a graphical display of the assembled events. At this point of the forensic examination no indications of any malicious activities had been found. The system log clearly records time changes and HDD erases and no such events were logged. Furthermore, the dates and times of log files and footage match. The system showed records since the first boot, just two months after the manufacture date. Therefore it is unlikely that the system was tampered with by a person with no forensic computing experience. A large portion of the old footage appears to have been overwritten. It is not clear how the system overwrites a previous recording and for that reason it was not known whether old recordings might reside on the system.
3.4.2.
Steps to take
Data structures that resemble the ‘‘.db’’ bookkeeping files were found in the unallocated space of the hard disks. Restoring the old bookkeeping files was the best chance to successfully view old footage. The timestamps within the recovered ‘‘.db’’ files would provide a good overview of the recording course on the hard disks. The second method was to create a new recording, copy the old video stream over the created video stream and try to play the old video stream with use
Fig. 1 – Screenshot of FTK imager. Example of bookkeeping files on the first partition of both hard disks.
digital investigation 5 (2008) 19–28
23
Fig. 2 – Screenshot of FTK imager; both raw (dd) images loaded in FTK imager showing the partition and directory structure.
of the new bookkeeping files. If these methods proved to be unsuccessful, more time consuming methods would be required. Reverse engineering ‘‘.db’’ files and manually creating ‘‘.db’’ files with perhaps the right pointers is one of these methods. Trying to play, de-multiplex and transcode the entire video stream was the final method. As most system activities are logged, recovering log files that may have been removed would be a good indication of whether recordings were removed.
4.
Technical investigation
4.1.
Recovering old bookkeeping files
4.1.1.
The recovery attempt
The ‘‘.db’’ bookkeeping files had a distinctive file header, but no footer. The bytes of the file header were also stored further in the file. Therefore the second header match must be set to be ignored when carving. All ‘‘.db’’ files found on the primary hard disk had a fixed file size of 166 kB. The ‘‘.db’’ files on the secondary hard disk had a fixed file size of 548 kB. It is not
Fig. 3 – The course of the recordings on the hard disks.
clear why the ‘‘.db’’ files on both hard disks differ in size. With this information, Foremost (http://foremost.sourceforge. net) was used to recover bookkeeping files on both disks. In order to give the recovered files the correct filename a Perl script was written. This Perl script located the first timestamp, a UNIX 32 bit hex value, stored within the recovered file and renamed the file to the equivalent UNIX numeric time. In addition, the corresponding event (.eve) file was generated. After restoring the original filenames of all recovered bookkeeping files the recording periods were made insightful. On the primary hard disk, two bookkeeping periods were recovered. The first period was from December 24 through 27, 2006. This period was not carved consequently for every hour. The second period started on March 20 at 19:00 and ended on March 22 at 9:00. The second period was carved very consequent, for every hour in this period a ‘‘.db’’ file was found. On the secondary hard disk, ‘‘.db’’ files from February 24 at 6:00 to February 25 at 18:00 were carved consequently. No bookkeeping files were found for February 14–20 when the events presumably took place. With the use of this information the old and current recording situation is shown in Fig. 5. The recovered bookkeeping files for February 24 and 25, 2007 were placed on the secondary duplicate hard disk and the DVR was booted. Once the system was booted the interface showed no option to play these dates. The DVR was powered off and the hard disk was mounted on a computer to see what had happened. The DVR appeared to have removed all the recovered files. This was probably due to the fact the system was set to ‘Overwrite’ mode and had removed the oldest recordings. Therefore all the bookkeeping files of March were removed and the recovered files were placed back. Once the DVR was booted the calendar overview showed that the recovered recordings were able to be viewed. Unfortunately the system showed a black screen and stopped responding
24
digital investigation 5 (2008) 19–28
Fig. 4 – Timeline.
when one of the recovered bookkeeping files was selected. Even when trying to play footage from February 25 at 17:30 proved unsuccessful, despite the fact that February 25 at 17:30 is only half an hour before the last available footage that has not been overwritten yet. Therefore, this recording moment has the highest potential of successfully being recovered. To be certain that the recovery with Foremost was performed properly, carved bookkeeping files of available recording periods were placed on the hard disk. All of these files did work, for this reason it is assumed that the carving method was performed properly.
4.1.2.
Result explanation
In order to give a logical explanation for the result of the recovery attempt, the DVR’s overwrite functionality was further examined. The DVR presumably allocates a part of the video stream to overwrite when the hard disk is full. Such allocation of space
Fig. 5 – Old and current recording situation.
could be performed in real-time or by the day, hour or perhaps by the minute. To find out how the DVR allocates space the system started recording with two cameras attached with HDD mode ‘Overwrite’ switched off. The DVR was set to raise an alarm and stop recording when the disk was full. With this setting it was possible to check if the system already allocated space or if this was done real-time. If allocation of space was real-time the system would immediately raise an alarm as no space was left to record on. The DVR stopped recording and raised an alarm after 1.5 min. At this point the system was completely full and first had to allocate space before it could start recording again. Therefore the system was set back to HDD mode ‘Overwrite’, started and manually stopped after 3 s of recording. The interface of the DVR showed that the footage from February 25 at 17:00 until 18:00 was not available anymore. Thus it was determined that space is allocated by the hour. In order to find out if it is possible to view footage that has been removed by the allocation process, the new bookkeeping files were removed and the old files restored. It proved possible to view a big part of the ‘removed’ footage. If this theory was correct it should have been possible to view some footage (maximum of an hour) before February 25 at 17:00. Therefore recovered bookkeeping files of 16:00 and 17:00 were placed on the DVR; then 17:00 was selected and rewinded back as far as possible. At 16:57:32 rewinding stopped and played 2.5 min of ‘removed’ footage.
4.2.
Recovering log files
4.2.1.
The recovery attempt
The system log file has the same structure as the ‘‘.db’’ bookkeeping files. For the recovery attempt a distinctive header and a fixed size of 10 kB was used by Foremost. One removed system log file was recovered and was copied over the system log file on the primary hard disk. The DVR was booted and the log file was successfully showed by the log viewer. The recovered log file solely contained entries of December 26, 2006 with a few quick admin logins.
digital investigation 5 (2008) 19–28
25
Fig. 6 – Example of the contents of an event file opened in a hex editor.
4.2.2.
Result explanation
The system was probably used for some quick testing and was restored back to its original state, removing all data. No log files containing possible malicious activities, such as time change and HDD formats, have been found on the system.
4.3.
Copying video streams
At this point in the forensic examination, the chances of recovering more video than 2.5 min are very slim. However, for the purpose of this paper and possible similar future investigations, more methods were tested. Since every DVR brand is different, one method may be preferred over the others.
4.3.1.
footage resulted in the same results as the first attempt. Fortunately the DVR was powered off quickly enough to avoid damaging the hard disk.
4.3.2.
Result explanation
The ‘‘.db’’ bookkeeping files contain many timestamps and presumably also pointers to locations in the ‘‘MPEG_STREAM’’ file. Timestamps could be checked within the ‘‘MPEG_ STREAM’’ if they correspond with the timestamp from the bookkeeping files. The ‘‘.db’’ bookkeeping files are further examined in the next paragraph.
4.4.
A closer look at the bookkeeping files
4.4.1.
The recovery attempt
The recovery attempt
An empty hard disk was placed in the DVR and was automatically formatted by the system. One camera without audio was set to start recording for 1 h. After this hour the hard disk was mounted on a computer and the created ‘‘MPEG_STREAM’’ file on the third partition was overwritten by the original ‘‘MPEG_ STREAM’’ file of the primary hard disk. The hard disk was placed back in the system and booted. While trying to play footage, a black screen was displayed and the DVR stopped responding. Although the DVR stopped responding, the hard drive LED indicated a lot of hard disk activity as if it was searching. After a few seconds of waiting, the hard disk started to make a ticking sound. This system was immediately powered off as this sound certainly was not correct. The hard disk turned out to be broken. The recovery attempt was repeated with the use of three cameras because it is known that all footage on the primary hard disk was recorded by three cameras. Trying to play
Two types of bookkeeping files were found, with ‘‘.db’’ and ‘‘.eve’’ extensions. The purpose of both bookkeeping files became clear based on examination of test recordings. When a recording starts, the ‘‘.eve’’ and ‘‘.db’’ files are generated. Both bookkeeping files have a numeric UNIX timestamp as filename, containing the recording date/time rounded down to the full hour. When a recording starts at 14:20 a timestamp is made for 14:00. The generated ‘‘.db’’ file is filled with data during the recording hour. The ‘‘.eve’’ file stays untouched after it is generated. The ‘‘.eve’’ – event – files do not hold much valuable information, except for their timestamp they are almost all the same. The event files are responsible for notifying the DVR if there is footage available for a specific hour. The timestamp found within the event files matches the timestamp of the corresponding filename (Fig. 6).
Fig. 7 – Sample structure of .db file viewed within a hex editor. The green frame is a 32 byte block. The repeated bytes are underlined. The timestamp is framed in blue. (For interpretation of the references to colour in this figure legend, the reader is referred to the web version of this article.)
26
digital investigation 5 (2008) 19–28
Fig. 8 – Example of a simple .db file dump.
The ‘‘.db’’ files were first examined in a hex editor. The ‘‘.db’’ files are divided in blocks of 1024 bytes. Each block has a header which is the same for every block in every file. Only the first block has a different header, but equals to all other first blocks from other ‘‘.db’’ files. Within a block a number of bytes are repeatedly found in the same pattern. Each block is subdivided into smaller blocks of 32 bytes, starting with the bytes ‘‘10 00 01.’’ The bytes ‘‘08 00 01’’ with a 32 byte block precede every timestamp. Three 32 byte blocks were found for every second (according to its timestamps). The examined ‘‘.db’’ file belongs to recordings made by three cameras. Therefore the ‘‘.db’’ file presumably contains
pointers for every second and every camera to the ‘‘MPEG_ STREAM’’ file. The byte directly after ‘‘10 00 01’’ is probably the camera. The beginning of a 1024 byte block with the header and the 32 byte blocks within is shown in Fig. 7. As the file extension indicates, the ‘‘.db’’ file is clearly some kind of database file. Perhaps all the contents could be readily dumped with a tool. First the database/file type had to be identified. For identification the ‘file’ function under Ubuntu Linux was used. The ‘‘.db’’ file was identified as a Berkeley database, BTree version 8. After searching the internet it turned out that a Berkeley DB tool suite is available for Linux. This tool suit contains a function called db_dump whereby it was possible to dump ‘‘.db’’ files. The function db_dump supports a simple and more detailed dump. Both dumps were used to obtain a better picture of functioning of a ‘‘.db’’ bookkeeping file. A sample of both dumps of the same part of a ‘‘.db’’ file is shown in Figs. 8 and 9. In order to understand the ‘‘.db’’ files they had to be stripped down as far as possible. Simply removing pages (the detailed ‘‘.db’’ dump showed that a 1024 byte block is called a page) resulted in a corrupt ‘‘.db’’ file that could not be recognized by the DVR. Therefore a more cautious method was required. The headers were made clear by over and over changing bytes and dumping the file. The results of these actions are shown in Figs. 10 and 11. In addition to identifying header bytes, the whole structure of the file was made clear in this way. The ‘‘.db’’ file starts with a header (see Fig. 10) followed by the first page which is identified as the ‘BTree internal’ section. This is actually the ‘top’ of the tree and divides the file down in branches and leaves. The
Fig. 9 – Example of a detailed .db file dump.
digital investigation 5 (2008) 19–28
27
Fig. 10 – Example of the file header of a .db file and the meaning of the bytes.
‘BTree internal’ section functions like an index in a book and points to branches in order to offer fast data access. A branch section starts with a header specified as ‘BTree leaf’ (see Fig. 11) containing the data leaves (32 byte data blocks). With this information it was possible to create a stripped down ‘‘.db’’ file. Starting with a Berkeley Db file header, followed by zero bytes until 1024 bytes (size of one page). Next, without a top level ‘BTree internal section’ – a branch (starting with BTree leaf header) section of 1024 bytes (1 page) containing only one leaf (32 bytes) is followed. The BTree internal section was left out because it had no use in such a small file. Correct page and entry information in the headers (see Figs. 10 and 11) was very important. Wrong page or entry information resulted in a corrupt file. As the .db file was stripped down, it was time to try to alter the leaf information (see Fig. 12). Altering the timestamp in the leaf by only one second caused the ‘‘.db’’ file to be invisible in the DVR interface. All other bytes, with the exception of the bytes ‘‘10 00 01’’ and ‘‘80 00 01,’’ could be changed without any noticeable result. Looking for pointers also turned out to be futile.
4.4.2.
Result explanation
Apart from being a timestamp, it is not clear what information is held in a leaf (32 byte block). Test recordings showed audio is not stored in a separate file as the manual states. Therefore some of these bytes could indicate whether a recording contains sound or not. Although seeking for offsets was unsuccessful, the most logical explanation is that these bytes do represent pointers. The bookkeeping files have to be present in order to view footage. No other artefacts regarding viewing
the video stream have been found. Perhaps a part of the information in the leaf is converted to a pointer with of some kind of function.
4.5.
Playing the entire video stream
4.5.1.
The recovery attempt
Preceding attempts to play the ‘‘MPEG_STREAM’’ file did not work, see Section 3.2. A new test recording with one camera without audio was made for testing purposes. Opening the created video file in a hex editor showed, contrary to the preliminary investigation, a structure. A file header followed by two different sections that could easily be separated from the rest of the data. These sections are probably headers. The only programs which were able to identify the ‘‘MPEG_STREAM’’ file were Transcode (available from: http:// www.transcoding.org, only version 1.02 worked) and Mencoder (available from: http://www.mplayerhq.hu). Both files identified the file as a digital video format. Despite all the efforts, no footage could be revealed with the use of these programs. Attempts to change the file header to headers of other similar video files were also fruitless. By using the DVR’s backup functionality the test footage was exported to DVR format. By viewing the exported file and the ‘‘MPEG_STREAM’’ in a hex editor showed remarkable resemblance in their structure. The two mentioned sections (headers) started and ended at exactly the same offsets. Besides this the exported file and the ‘‘MPEG_STREAM’’ file only differ 152 bytes in size. Another test recording with the use of three cameras showed the same result. The three exported recordings’ files together matched the file size of
Fig. 11 – Example of a page header (BTree leaf) within a .db file a the meaning of the bytes.
28
digital investigation 5 (2008) 19–28
Fig. 12 – Sample leaf.
the ‘‘MPEG_STREAM’’ file. The exported file was not created by a simple substitute code of the ‘‘MPEG_STREAM’’ file. Both video processing chips found within the DVR were manufactured by PentaMicro. A look at the website of PentaMicro (http://www.pentamicro.com) revealed that there is a Reference Design Kit (RDK) available. PentaMicro’s RDK implies a complete solution for the embedded DVR developer including the functionality to view an entire video stream. PentaMicro was contacted to ask if they were able to view a test recording of the DVR. PentaMicro’s support quickly replied notifying that they were not able to view the file because the stream ID did not match their own stream ID. Altering the stream ID to their own did not work either. PentaMicro assumed that Samsung created their own streaming method. PentaMicro stated that the ‘‘MPEG_STREAM’’ file probably holds the PES (Packetized Elementary Stream) format. Research into PES files showed that the header holds several timing references such as DTS (decoding timestamp) and ESCR (elementary stream clock reference). No useful information regarding viewing or converting PES files was found. Samsung was not willing to help in any way, and would not provide any information about the functioning of the DVR system. Samsung stated they cannot decode the video stream for any kind of reason.
4.5.2.
Result explanation
Samsung probably created a proprietary video stream that cannot be viewed without deeper knowledge of the functioning of the system.
reside in the proprietary ‘‘MPEG_STREAM’’ file, it is highly likely that no lost recordings reside on the DVR. The system was set to overwrite mode and had most likely overwritten all footage (except 2.5 min) before February 25, 2007. Furthermore, it is highly plausible that the system did not record anything on February 14 through 20, 2007. No bookkeeping files or even bits of bookkeeping file were found for this period. All other recovered bookkeeping files were entirely recovered without missing pieces. Therefore the DVR that was examined might not be the device that actually recorded the events, or perhaps no recordings were made at all. The lax documentation and tracking of DVR used in the hospital could have led to the misidentification of the relevant DVR system. No indications of malicious tampering attempts were found. It is highly unlikely that someone without an extensive knowledge of computers and a deeper knowledge of the functioning of the system, would be able to tamper with a DVR in such a way that no traces of these activities would remain on the system. Because no evidence was found against the defendant, she was acquitted of all charges. This case example demonstrates the importance of forensic preparedness within an organization. With proper documentation and tracking of the use of DVR’s, and with preservation procedures after each use, it would have been possible to determine whether relevant footage had been recorded.
references
5.
Conclusion
An in-depth forensic examination of the DVR in this case did not find any traces of recordings from the period of interest. Although it is not possible to be certain that no lost recordings
Feldman Marc. Munchausen by proxy. Available from: