CCTV File System Examination

http//en.wikipedia.org/wiki/Endianness

Hi,

I'm currently looking at a hard drive extracted from a CCTV system. The file system on the drive is some kind of proprietary file system.

Having a brief look through, I've found jumbled versions of what movie file signatures. The CCTV system seems to be swapping two bytes at a time (instead of having 57 41 56 45, I have 41 57 45 56).

Is anybody aware of a script or tool I can use to swap these bytes back? My programming skills == zero.

Thanks in advance.

I am not sure to get it.
It is just the four bytes you mentioned or the whole file is "reversed in couples"?

I mean, you could use *any* hex/disk editor to replace the occurence(s) of
41 57 45 56with
57 41 56 45(or gsar, or similar command line hex aware replace tool)

jaclaz

Hi both,

Thanks for your replies.

@jaclaz - I'm not sure whether this runs through the entire file, or just the signature. I used HxD to swap the bytes of the signature back around, but the exported file didn't work.

I've found, however, that the CCTV system stores the dates of the recordings at sector 1 on the drive. I'll tinker with this on the clone to see if I can get back any data.

Thanks again.

yeah if you flip the signature it probably wont

what was mentioned before is endianess.
theres little and big ending, it's the way that the file is read (from left to right, or right to left means that the bytes appear backwards)

is there any information that you can provide?
have you tested to see if its just those four bytes that are "flipped", and is there any data outside of the signatures?

Hi randomaccess,

I can't seem to find any other obvious data I can test the flip on. I've found 8 byte entries long entries at Sector 1 which contains the recording date (YY MM DD), followed by three unknown bytes, an 80 and finally 00. Like

11 01 18 3F 00 00 80 00

I can't work out the significance of the bytes after the date, and all entries end with 80 00.

Do you have the CCTV system to hand ? or even the model? if so you can identify the processor and then its endianess.
of course if it is big endian then converting to little endian (as found in x86 processors) is not a trivial process, you'll need to know the structure of the file.

you could try to dd the file with SWAB as a convert option, it might (but probably won't) work.

Below is a link to Windows version of DD
http//gmgsystemsinc.com/fau/

yeah if you flip the signature it probably wont

what was mentioned before is endianess.

Yes and no.
It depends on lenght of fields, one bytes ones are obviously not affected, two bytes one would behave like the example, 4 byte one's won't, etc..

jaclaz

@hmorgan

Thanks for the swab suggestion. I tried it, and it did exactly what I wanted, but the file didn't work.

I don't have the box right now, but will do tomorrow.

If I was to put a clone of the original into the machine and record some extra footage, can anyone suggest a tool I can use to compare the original and clone drive to see what data has been changed? I've seen diff mentioned - never tried it though.

Thanks again.

Beware when looking at endianness, especially with CCTV.

There is endianness of meta data and endianness of the stored files, both, either or neither could be relevant.

I have seen lots of CCTV systems where the meta data (date time, camera etc.) is recorded in a bit swapped manner (for want of a better term) but the files themselves are not - e.g. jpg is jpg irrespective of the endianess of the system is recorded on.