LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 07-24-2018, 03:45 PM   #1
bpb21
LQ Newbie
 
Registered: Jul 2018
Distribution: Debian, CentOS, Slackware, Ubuntu
Posts: 5

Rep: Reputation: Disabled
Mounting/carving/hex-ing a truly unknown filesystem


I have a unique situation (I've already contradicted myself there) in that I'm trying to examine a filesystem used by a Hikvision DVR system.

I'll save you all the research and say that, "...the HIKVISION products use its own file system...", and that "...the HIKVISION has yet conducted any related digital forensic analysis."* So I've contradicted myself in that others have had this issue as well, so much so that a research paper was done on the file system - the FS doesn't even have an official name!

*citing "Analysis of the HIKVISION DVR File System" by Jaehyeok Han, Doowon Jeong, and Sangjin Lee, Center for Information Security Technologies (CIST), Korea University, Anam-Dong, Seoungbuk-Gu, Seoul, Republic of Korea {one01h,dwjung77,sangjin}@korea.ac.kr

Suffice it to say you definitely won't find any filesystem headers to add to your system for this one!

This research paper I'm citing to actually spells out the file system structure, describing where data is stored. So I'm not completely lost here.
(Example: "The data in each field is stored by Little-endian systems. The Master Sector defines the followings: the capacity of a hard disk (0x25433D6000), offset and size of the system logs (0x3D13200 and 0xF42C00), offset to the video data area (0x4C5E000), size of a data block (0x400000), total number of data blocks (0x94), offset of the HIKBTREE (0x25433BDC00), size of the HIKBTREE (0x6000), time of system initialization (0x37227754), and others. The hexadecimal values in the brackets are the values of samples as shown in Fig. 2.")

So I've got documentation that goes into pretty extensive detail on how the file system is structured and organized.

I've also got an image from dc3dd and EWF of the subject drive to work with, and thankfully there do not appear to be any damaged areas on the drive.

My question: how could I go about mounting or accessing (without mounting) the drive image to actually get at this data?

I have my Slackware system configured for forensic analysis from the CLI, but I've worked with at least known file systems - an unknown file system only documented in a research paper is a new one for me, I'll admit!

Any info, or anything obvious I might be over-thinking would be great!
 
Old 07-24-2018, 06:17 PM   #2
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2.1.2 on Lenovo Thinkpad W520
Posts: 8,776

Rep: Reputation: Disabled
dd if=<device name> of=<file> then scan <file> with a hex editor.

Use lsblk to know <device name> and its size, then check that you have enough space in the partition that will store <file>.

Last edited by Didier Spaier; 07-24-2018 at 06:26 PM.
 
Old 07-24-2018, 06:46 PM   #3
michaelk
Moderator
 
Registered: Aug 2002
Posts: 18,319

Rep: Reputation: 2596Reputation: 2596Reputation: 2596Reputation: 2596Reputation: 2596Reputation: 2596Reputation: 2596Reputation: 2596Reputation: 2596Reputation: 2596Reputation: 2596
I am unfamiliar with Hikvision DVRs so anything posted is pure conjecture.

There is no requirement that data has to be written to a filesystem on a disk. I used a 4 channel recorder awhile ago that recorded the data sequentially to a raw partition and the video was converted to a standard format on playback. You could either configure it to stop when the disk was full or loop back and overwrite. The embedded computer even ran linux.

There is obviously a real time speed advantage to writing raw data. It could be a matter of knowing the start offset from the beginning of the data segment, the size of the block and just reading it with the dd command. How to process the video data is the key but since it depends on the hardware as much as the software it is difficult to reverse engineer...
 
Old 07-24-2018, 07:37 PM   #4
jefro
Moderator
 
Registered: Mar 2008
Posts: 18,915

Rep: Reputation: 2836Reputation: 2836Reputation: 2836Reputation: 2836Reputation: 2836Reputation: 2836Reputation: 2836Reputation: 2836Reputation: 2836Reputation: 2836Reputation: 2836
I agree that generally making a clone of the disk is a good forensic way. dd the disk would create a raw image. That image could be manipulated. I'd start with the command "file" on that raw image. Can try fdisk or other tools on that image also. I usually call it something like dvd.img

I assume the Little-endian tells us more already.

You'd have to make a driver or module to let the linux kernel access it even on read only.

Recently I looked at a similar deal for an old OpenVMS image. Found it was easier to get an Alpha emulator over trying to mount that silly filesystem.

I'd be willing to bet that HKvision already has tools to work on their OS and filesystem from linux.
 
Old 07-25-2018, 08:01 AM   #5
SpacePlod
LQ Newbie
 
Registered: Jan 2014
Posts: 29

Rep: Reputation: Disabled
It looks like you have the forensic imaging/cloning part done already (dc3dd and EWF).

Mounting does not look to be possible without specific FS drivers. Given that you have some offset info from your research, I would take the image and further pare it down with dd or dc3dd using skip, bs, and count to cut the image down to the data area alone (using the "offset to the video data area", block count and block sizes).

The next step would be to try and find actual data signatures. You could see if you could find an intact video from a similar system and check the file signature, but the issue with that is the export process itself (likely using a proprietary tool) sometimes re-encodes as it exports, changing the on-disk signature to a different value for the exported file. Still, it's a place to start. Perhaps use something like sigfind (TSK) on sector boundaries (or data block boundaries - from the research you quoted) to search for repeating signatures.

If you can determine the file signature, then you can start to carve the pared down image for videos (scalpel, formost, X-ways, with custom sigs, etc.). The fun part will be trying to determine how they are encoded. From a "forensic" perspective, and barring any other resource, that's where I'd start.

Of course the other option is to contact the company and see if they have a toolset available to recover videos. If they do, then physically restore the image (image to disk) and work on that. See what you find and reverse it to forensically recover from the image (number of videos, file sigs, etc.).

I have little experience with dedicated DVR hardware, but given a disk with arbitrary structured data, at least it's a place to start. YMMV.
 
1 members found this post helpful.
Old 07-25-2018, 08:04 AM   #6
bpb21
LQ Newbie
 
Registered: Jul 2018
Distribution: Debian, CentOS, Slackware, Ubuntu
Posts: 5

Original Poster
Rep: Reputation: Disabled
Thanks for all the info - good advice

Thanks for the tips - it appears from that research paper I stumbled upon that fdisk/gdisk isn't going to tell me anything (testing seems to support that).

Didier Spaier - makes sense; I'm unfamiliar with even the file extensions that this file system would use, so I'll have to research that.

michaelk - sounds like the same or very similar situation as mine, except in this case I'm missing the passwords (the ones I have are inaccurate) to get into the software that would be used to work with this system - hence the workaround carving out files from hex data!

jefro - I hope so, although I haven't found anything on their website that would allow me to get around that password issue for their tools. This system was provided to me by someone who didn't remember the password (or more accurately, the password had been changed since the last time it had been written down anywhere). So, hopefully there are some tools on the Hikvision site, although that research paper seems to indicate there might not be.

Either way, good stuff and thanks for the info everyone; this got me thinking in the right direction again!
 
Old 07-25-2018, 08:07 AM   #7
bpb21
LQ Newbie
 
Registered: Jul 2018
Distribution: Debian, CentOS, Slackware, Ubuntu
Posts: 5

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by SpacePlod View Post
It looks like you have the forensic imaging/cloning part done already (dc3dd and EWF).

Mounting does not look to be possible without specific FS drivers. Given that you have some offset info from your research, I would take the image and further pare it down with dd or dc3dd using skip, bs, and count to cut the image down to the data area alone (using the "offset to the video data area", block count and block sizes).

The next step would be to try and find actual data signatures. You could see if you could find an intact video from a similar system and check the file signature, but the issue with that is the export process itself (likely using a proprietary tool) sometimes re-encodes as it exports, changing the on-disk signature to a different value for the exported file. Still, it's a place to start. Perhaps use something like sigfind (TSK) on sector boundaries (or data block boundaries - from the research you quoted) to search for repeating signatures.

If you can determine the file signature, then you can start to carve the pared down image for videos (scalpel, formost, X-ways, with custom sigs, etc.). The fun part will be trying to determine how they are encoded. From a "forensic" perspective, and barring any other resource, that's where I'd start.
Good stuff; and yes, the video is exportable from the program's interface although the passwords have been lost (and are apparently stored somewhere in the hardware itself (some program running from the firmware perhaps) and not on the internal 3.5" HDD that's used for data storage).

But, this sounds like a plan. Thanks.

Last edited by bpb21; 07-25-2018 at 08:08 AM. Reason: details
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
grub rescue> errors unknown filesystem, unknown commands, no live boot lazymonk Linux - Software 14 04-19-2016 01:51 AM
Error mounting: mount: unknown filesystem type 'ntfs' sureshpanchanathan Linux - Newbie 11 05-20-2015 05:46 AM
Passable nouveau kernel driver bug (MMIO read of [hex l] FAULT at [hex l]) marbangens Linux - General 1 05-24-2013 01:35 AM
[SOLVED] mounting a scsi disk fails with unknown filesystem error Greebstreebling Linux - Hardware 12 03-29-2013 03:18 PM
Hex output of a hex/ascii input string mlewis Programming 35 04-10-2008 12:05 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 01:44 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration