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
a r t i c l e i n f o
Article history:
Received 22 October 2007
Received in revised form
20 March 2008
Accepted 1 April 2008
Keywords:
Digital video recorder
DVR
Digital video
MPEG-4
Hard disk recorder
Video
Carving
Recovery
Berkeley database
BTree
a b s t r a c t
In May 2007, a case of potential child abuse was reported to the hospital where the
victim was under observation. The child had been in the hospital for several months
and there was hope that a digital video recorder (DVR) may have recorded the
maltreatment of a hospitalized child. Unfortunately the recordings could not be found
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
examined, describing the steps that were taken to obtain information and how the
information was interpreted. The methods described in this article can be applied to
other similar devices.
2008 Published by Elsevier Ltd.
1. Background
In May 2007 it was presumed that in February 2007 a hospi-
talized child was possibly maltreated by its mother. The
child was diagnosed with various forms of illness but the
doctor could not nd any denite 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 falsies or induces
an illness in another person to achieve emotional satisfac-
tion. This is a form of maltreatment (abuse and/or neglect)
rather than a mental disorder. Children are the usual vic-
tims and the mother is the usual perpetrator (Dr. Feldman,
2007).
During the entire period of February the child was hospital-
ized. Two cameras in the childs hospital room were con-
nected to a digital video recorder (DVR) that had possibly
recorded these events. By the end of February the hospital se-
curity decided to use the digital video recorder for other pur-
poses in the hospital. Due to the slow progress of the childs
examination and the reporting of possible child abuse, the
DVR had been used for almost a month for other purposes be-
fore any footage was viewed. Furthermore the hospital secu-
rity was not entirely sure if any recordings had been made
in the childs 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
E-mail address: wvdongen@zonnet.nl
avai l abl e at www. sci encedi r ect . com
j our nal homepage: www. el sevi er . com/ l ocat e/ di i n
1742-2876/$ see front matter 2008 Published by Elsevier Ltd.
doi:10.1016/j.diin.2008.04.001
d i gi t a l i nv e s t i ga t i o n 5 ( 2 0 0 8 ) 1 9 2 8
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 re-
cordings or pieces of recordings of the specied period re-
sided on the DVR and to examine if footage could maliciously
have been removed.
2. Methodology
The digital forensics examiners in this case rst performed
a preliminary investigation to obtain an overall picture of
the systems properties, functionalities, settings and situa-
tion, and then used this information to develop a strategy
for an effective technical investigation.
The rst step in the preliminary investigation was to iden-
tify the brand/type/model of the device. As part of this re-
search process, digital forensics examiners collected as
much information as possible concerning the device, compo-
nents and similar devices. After this initial research, the de-
vice 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 systems
functionalities and state, the system was booted. A separate
hard disk was used for additional testing such as test record-
ings. To minimize the risk of mistakes while performing a pre-
liminary 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 nal step in the preliminary investiga-
tion was to use the information in order to construct methods
for extracting lost footage from the device.
During the technical investigation the examination and re-
covery methods constructed during the preliminary investiga-
tion 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 man-
ual was downloaded from the manufacturers 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 com-
pressed in MPEG-4 format and stored in a video le, and audio
is compressed using ADPCM (Adaptive Differential Pulse Code
Modulation) and, according to the manual, is stored in a sepa-
rate audio le. The DVR is capable of transferring video and
audio in real-time over a network so that monitoring is possi-
ble from a PC (Samsung, 2005). A label on the device indicated
that it was manufactured in China by Tianjin Samsung Elec-
tronics in October 2006.
After reviewing and documenting the DVRs specications,
the system was opened for further investigation. Two 160 GB
hard disks specied 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 (avail-
able 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 funda-
mental 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 rst time with the duplicate
hard drives in place and no cameras were attached. Aseparate
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 confer-
ence roomwas 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 les were
found. Within the systemsection it was possible to viewa sys-
tem 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
d i g i t a l i nv e s t i g a t i on 5 ( 2 0 0 8 ) 1 9 2 8 20
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
le is too large) in the system log is provided here:
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 on12-29-2006 (a fewseconds between
entries) and video loss for camera one and two on 2-14-2006.
Beside the system and event log les, the system section
contained an option named HDD mode which was set to
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 spe-
cic recording, but had two ways to remove recordings. The
rst method was to perform an HDD erase, causing all footage
and settings to be lost. The second method was to set the sys-
tem clock back whereby all recordings after that date are
removed.
The DVR offers the functionality to create a backup of re-
cordings 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 Access-
Data 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 le con-
tents from a different le. 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 le system.
The rst 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 le and
dvr_cong.txt le. The bin directory contained the oper-
ating system such as executable les, kernel modules and
log les. Beside these directories, the root directory con-
tained 670 les with a .db and .eve extension. These les
appeared to be used for the bookkeeping of the recordings on
the hard disk. The lenames of these bookkeeping les were
UNIX numeric timestamps. The rst le was named
1172930400.eve/db (March 3 at 14:00) and the last le was
named 1174136400.eve/db (March 17 at 13:00). The book-
keeping lenames matched the last modied timestamps of
the les. Therefore, a good overviewcould be obtained by sort-
ing the bookkeeping les by the last modied date. From this
perspective, the rst modication 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 les were created every hour.
The .db les contained many UNIX timestamps in 32 bit hexa-
decimal, little endian format. Beside the bookkeeping les, an
empty le named overwrite was found in the root direc-
tory. This overwrite le had the exact same modication
time (March 3 at 14:20) as the rst bookkeeping le.
An additional 516 bookkeeping les were stored on the rst
partition of the secondary hard disk. In addition to the .db
and .eve les, there was an overwrite le with the modi-
cation date of March 17 at 13:26. The rst bookkeeping le
was named 1172422800.eve/db (February 25 at 17:00) and
12-27-2006 First: 9:22:53, last: 9:25:51
System start [6 s] setup [50 s] several
admin logins [within a 2 min period].
12-29-2006 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.
02-14-2007 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).
02-16-2007 First: 20:25:47, last: 20:27:27
Setup start, setup end.
02-21-2007 8:29:49
Login (admin).
03-01-2007 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.
03-23-2007 First: 15:48:27, last: 15:56:51
System start and power failure recovery,
several playback entries [within 3 min
period], system shutdown.
05-10-2007 First: 13:39:16, last: 14:03:07
System start [13 min] setup start [3 min]
setup end, login (admin), login (admin).
05-11-2007 First: 06:06:59, last: 07-04-22
Login admin [52 min] several setups
[within 2 min period].
05-15-2007 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).
06-13-2007 System start and power failure recovery,
playback, setup [our own actions].
d i gi t a l i nv e s t i ga t i o n 5 ( 2 0 0 8 ) 1 9 2 8 21
the last le was named 1174557600.eve/db (March 22 at
10:00). When sorting the les by the modication date, two
bookkeeping le periods were observed. The rst 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 rst partition. Parts of the data in the unallocated
space were very similar in structure to the stored .db les
(Fig. 1).
Besides an empty directory named lostfound and an
empty le named PREALARM, no les 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 le named MPEG_STREAM. A review of these les
and some experiments in VLC media player did not reveal
any information. No headers of any kind were found in the
MPEG_STREAM les and several MPEGrepair and detections
tools were not able to decompress/detect/extract/decode any-
thing from the MPEG_STREAM le (Fig. 2).
3.4. Assumptions and steps to take
3.4.1. Putting the information together
The modication date of the last bookkeeping le on the pri-
mary hard disk matched the modication date of the over-
write le on the secondary hard disk. The modication date
of the last bookkeeping le of the rst period matched the
one of the overwrite les stored on the primary hard disk.
Based on this information, and since the DVR was set to over-
write mode it is most likely that the overwrite les indicate
when a video stream hopped from one disk to the other to
start overwriting. The overwrite le on the primary hard
disk was written before the bookkeeping les. Therefore, it
can be assumed that the stream on the primary hard disk is
completely overwritten. By looking at the dates of the book-
keeping les 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 le indicated that the system was rst
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 re-
stored 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 re-
cording. Since no interesting log les were found betweenFeb-
ruary 14 and March 1, it can be presumed that two cameras
recorded the childs room until the rst 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 fromthe hospital secu-
rity 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 les. 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 Sav-
ings 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
les and footage match. The system showed records since
the rst 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 previ-
ous 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 les
were found in the unallocated space of the hard disks. Restor-
ing the old bookkeeping les was the best chance to success-
fully view old footage. The timestamps within the recovered
.db les 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 les on the rst partition of both hard disks.
d i g i t a l i nv e s t i g a t i on 5 ( 2 0 0 8 ) 1 9 2 8 22
of the new bookkeeping les. If these methods proved to be
unsuccessful, more time consuming methods would be re-
quired. Reverse engineering .db les and manually creating
.db les with perhaps the right pointers is one of these
methods. Trying to play, de-multiplex and transcode the en-
tire video stream was the nal method.
As most system activities are logged, recovering log les
that may have been removed would be a good indication of
whether recordings were removed.
4. Technical investigation
4.1. Recovering old bookkeeping les
4.1.1. The recovery attempt
The .db bookkeeping les had a distinctive le header, but
no footer. The bytes of the le header were also stored further
in the le. Therefore the second header match must be set to
be ignored when carving. All .db les found on the primary
hard disk had a xed le size of 166 kB. The .db les on the
secondary hard disk had a xed le size of 548 kB. It is not
clear why the .db les on both hard disks differ in size.
With this information, Foremost (http://foremost.sourceforge.
net) was used to recover bookkeeping les on both disks. In or-
der to give the recovered les the correct lename a Perl script
was written. This Perl script located the rst timestamp,
a UNIX 32 bit hex value, stored within the recovered le and
renamed the le to the equivalent UNIX numeric time. In ad-
dition, the corresponding event (.eve) le was generated.
After restoring the original lenames of all recovered book-
keeping les the recording periods were made insightful. On
the primary hard disk, two bookkeeping periods were recov-
ered. The rst 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 le
was found. On the secondary hard disk, .db les fromFebru-
ary 24 at 6:00 to February 25 at 18:00 were carved conse-
quently. No bookkeeping les were found for February 1420
when the events presumably took place.
With the use of this information the old and current re-
cording situation is shown in Fig. 5.
The recovered bookkeeping les 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 inter-
face showed no option to play these dates. The DVR was pow-
ered off and the hard disk was mounted on a computer to see
what had happened. The DVR appeared to have removed all
the recovered les. This was probably due to the fact the sys-
tem was set to Overwrite mode and had removed the oldest
recordings. Therefore all the bookkeeping les of March were
removed and the recovered les were placed back. Once the
DVR was booted the calendar overviewshowed that the recov-
ered recordings were able to be viewed. Unfortunately the
system showed a black screen and stopped responding
Fig. 2 Screenshot of FTK imager; both raw (dd) images loaded in FTK imager showing the partition and directory structure.
Fig. 3 The course of the recordings on the hard disks.
d i gi t a l i nv e s t i ga t i o n 5 ( 2 0 0 8 ) 1 9 2 8 23
when one of the recovered bookkeeping les 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 recov-
ered. To be certain that the recovery with Foremost was per-
formed properly, carved bookkeeping les of available
recording periods were placed on the hard disk. All of these
les did work, for this reason it is assumed that the carving
method was performed properly.
4.1.2. Result explanation
Inorder to give a logical explanation for the result of the recov-
ery attempt, the DVRs overwrite functionality was further
examined.
The DVR presumably allocates a part of the video streamto
overwrite when the hard disk is full. Such allocation of space
could be performed in real-time or by the day, hour or perhaps
by the minute. To nd 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 rst 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 fromFebruary 25 at 17:00 until 18:00 was not avail-
able anymore. Thus it was determined that space is allocated
by the hour.
In order to nd out if it is possible to view footage that has
been removed by the allocation process, the new bookkeeping
les were removed and the old les restored. It proved possi-
ble 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 les 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 les
4.2.1. The recovery attempt
The system log le has the same structure as the .db book-
keeping les. For the recovery attempt a distinctive header
and a xed size of 10 kB was used by Foremost. One removed
system log le was recovered and was copied over the system
log le on the primary hard disk. The DVR was booted and the
log le was successfully showed by the log viewer. The recov-
ered log le solely contained entries of December 26, 2006 with
a few quick admin logins.
Fig. 4 Timeline.
Fig. 5 Old and current recording situation.
d i g i t a l i nv e s t i g a t i on 5 ( 2 0 0 8 ) 1 9 2 8 24
4.2.2. Result explanation
The systemwas probably used for some quick testing and was
restored back to its original state, removing all data. No log
les 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 re-
covering more video than 2.5 min are very slim. However,
for the purpose of this paper and possible similar future inves-
tigations, more methods were tested. Since every DVR brand
is different, one method may be preferred over the others.
4.3.1. The recovery attempt
An empty hard disk was placed in the DVR and was automat-
ically 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 le
on the third partition was overwritten by the original MPEG_
STREAM le 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 systemwas 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
footage resulted in the same results as the rst attempt. Fortu-
nately the DVR was powered off quickly enough to avoid dam-
aging the hard disk.
4.3.2. Result explanation
The .db bookkeeping les contain many timestamps and
presumably also pointers to locations in the MPEG_STREAM
le. Timestamps could be checked within the MPEG_
STREAM if they correspond with the timestamp from the
bookkeeping les. The .db bookkeeping les are further ex-
amined in the next paragraph.
4.4. A closer look at the bookkeeping les
4.4.1. The recovery attempt
Two types of bookkeeping les were found, with .db and
.eve extensions. The purpose of both bookkeeping les be-
came clear based on examination of test recordings. When
a recording starts, the .eve and .db les are generated.
Both bookkeeping les have a numeric UNIX timestamp as l-
ename, 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 le is lled with data
during the recording hour. The .eve le stays untouched af-
ter it is generated.
The .eve event les do not hold much valuable infor-
mation, except for their timestamp they are almost all the
same. The event les are responsible for notifying the DVR if
there is footage available for a specic hour. The timestamp
found within the event les matches the timestamp of the
corresponding lename (Fig. 6).
Fig. 6 Example of the contents of an event le opened in a hex editor.
Fig. 7 Sample structure of .db le 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 gure legend, the reader
is referred to the web version of this article.)
d i gi t a l i nv e s t i ga t i o n 5 ( 2 0 0 8 ) 1 9 2 8 25
The .db les were rst examined in a hex editor. The
.db les are divided in blocks of 1024 bytes. Each block has
a header which is the same for every block in every le.
Only the rst block has a different header, but equals to all
other rst blocks from other .db les. Within a block a num-
ber 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 le belongs to recordings made by three
cameras. Therefore the .db le presumably contains
pointers for every second and every camera to the MPEG_
STREAM le. 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 le extension indicates, the .db le is clearly some
kind of database le. Perhaps all the contents could be readily
dumped with a tool. First the database/le type had to be iden-
tied. For identication the le function under Ubuntu Linux
was used. The .db le was identied 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 les. 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 le. A
sample of both dumps of the same part of a .db le is shown
in Figs. 8 and 9.
In order to understand the .db les they had to be strip-
ped down as far as possible. Simply removing pages (the de-
tailed .db dump showed that a 1024 byte block is called
a page) resulted in a corrupt .db le that could not be recog-
nized by the DVR. Therefore a more cautious method was re-
quired. The headers were made clear by over and over
changing bytes and dumping the le. The results of these ac-
tions are shown in Figs. 10 and 11.
In addition to identifying header bytes, the whole structure
of the le was made clear in this way. The .db le starts with
a header (see Fig. 10) followed by the rst page which is iden-
tied as the BTree internal section. This is actually the top of
the tree and divides the le down in branches and leaves. The
Fig. 8 Example of a simple .db le dump.
Fig. 9 Example of a detailed .db le dump.
d i g i t a l i nv e s t i g a t i on 5 ( 2 0 0 8 ) 1 9 2 8 26
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 specied 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 le. Starting with a Berkeley Db le header, fol-
lowed 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) contain-
ing only one leaf (32 bytes) is followed. The BTree internal sec-
tion was left out because it had no use in such a small le.
Correct page and entry information in the headers (see Figs.
10 and 11) was very important. Wrong page or entry informa-
tion resulted in a corrupt le.
As the .db le 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 le 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 frombeing 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 le as the manual states. Therefore
some of these bytes could indicate whether a recording con-
tains sound or not. Although seeking for offsets was unsuc-
cessful, the most logical explanation is that these bytes do
represent pointers. The bookkeeping les 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 infor-
mation 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 le 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 le in a hex editor showed, contrary to the pre-
liminary investigation, a structure. A le 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 le were Transcode (available from: http://
www.transcoding.org, only version 1.02 worked) and Men-
coder (available from: http://www.mplayerhq.hu). Both les
identied the le as a digital video format. Despite all the ef-
forts, no footage could be revealed with the use of these pro-
grams. Attempts to change the le header to headers of
other similar video les were also fruitless.
By using the DVRs backup functionality the test footage
was exported to DVR format. By viewing the exported le
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. Be-
sides this the exported le and the MPEG_STREAM le
only differ 152 bytes in size. Another test recording with the
use of three cameras showed the same result. The three
exported recordings les together matched the le size of
Fig. 10 Example of the le header of a .db le and the meaning of the bytes.
Fig. 11 Example of a page header (BTree leaf) within a .db le a the meaning of the bytes.
d i gi t a l i nv e s t i ga t i o n 5 ( 2 0 0 8 ) 1 9 2 8 27
the MPEG_STREAM le. The exported le was not created by
a simple substitute code of the MPEG_STREAM le.
Both video processing chips found within the DVR were
manufactured by PentaMicro. Alook at the website of PentaM-
icro (http://www.pentamicro.com) revealed that there is a Ref-
erence Design Kit (RDK) available. PentaMicros RDK implies
a complete solution for the embedded DVR developer includ-
ing the functionality to view an entire video stream. PentaM-
icro was contacted to ask if they were able to view a test
recording of the DVR. PentaMicros support quickly replied no-
tifying that they were not able to view the le because the
stream ID did not match their own stream ID. Altering the
stream ID to their own did not work either. PentaMicro as-
sumed that Samsung created their own streaming method.
PentaMicro stated that the MPEG_STREAM le probably
holds the PES (Packetized Elementary Stream) format. Re-
searchinto PES les showed that the header holds several tim-
ing references such as DTS (decoding timestamp) and ESCR
(elementary stream clock reference). No useful information
regarding viewing or converting PES les was found.
Samsung was not willing to help in any way, and would not
provide any information about the functioning of the DVR sys-
tem. 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 function-
ing of the system.
5. Conclusion
An in-depth forensic examination of the DVR in this case did
not nd any traces of recordings from the period of interest.
Although it is not possible to be certain that no lost recordings
reside in the proprietary MPEG_STREAM le, 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 book-
keeping les or even bits of bookkeeping le were found for
this period. All other recovered bookkeeping les were en-
tirely 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 misidentication 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 func-
tioning 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 organiza-
tion. With proper documentation and tracking of the use of
DVRs, and with preservation procedures after each use, it
would have been possible to determine whether relevant foot-
age had been recorded.
r e f e r e n c e s
Feldman Marc. Munchausen by proxy. Available from: <http://
www.munchausen.com>; 2007.
Samsung. Real time DVR, SHR-2040/2041/2042 Users manual.
Available from: <http://www.samsung-security.com>; 2005.
Fig. 12 Sample leaf.
d i g i t a l i nv e s t i g a t i on 5 ( 2 0 0 8 ) 1 9 2 8 28