MPEG in WinHex 15.1 Log Out | Topics | Search
Moderators | Edit Profile

X-Ways Support Forum » Data Recovery » MPEG in WinHex 15.1 « Previous Next »

Author Message
Top of pagePrevious messageNext messageBottom of page Link to this message

roberto caldas
Username: roberto_sc

Registered: N/A
Posted on Thursday, Nov 6, 2008 - 3:02:   

I downloaded an eval version of WinHex 15.1 to try to find MPEG files, but the signatures are not there. Reading old posts I saw that version 13 had the signatures.
So why are MPEG signatures missing in version 15.1? What should I do to recovery MPEG files?

Thank you.
Top of pagePrevious messageNext messageBottom of page Link to this message

Alfons Kramer
Username: admin3

Registered: 4-2004
Posted on Thursday, Nov 6, 2008 - 9:33:   

It is not missing. Version 15.1 has more file signatures then any version before. Therefore the table has been split. One for searching, one for checking only. Unfortunately is the MPEG signature a weak signature. Therefore it went into the CHECK ONLY table. You are free to move it back to the SEARCH table again.
This new behaviour is documented in the according newsletter and within the help system.
Top of pagePrevious messageNext messageBottom of page Link to this message

roberto caldas
Username: roberto_sc

Registered: N/A
Posted on Thursday, Nov 6, 2008 - 11:14:   

Ok. Thank you for you answer.

So, what I understood is that because of MPEG structure, if I try to recover then I may end up with many similar files. For instance, if I have a 80MB MPEG with signature on each 800B (and I think I really do) and I try to recover with max size = 10MB then I will end up with 80MB/800B = 100.000 files and 1TB. Is that right?

Wouldn't be nice to have a MPEG recovery feature that concatenates these MPEG "blocks" until it finds a non-MPEG signature? Why wouldn't this work?

Thank you
Top of pagePrevious messageNext messageBottom of page Link to this message

roberto caldas
Username: roberto_sc

Registered: N/A
Posted on Thursday, Nov 6, 2008 - 11:47:   

Complementing my post and answering yours,

In the help about File Recovery by Type/File Header Signature Search there is an paragraph that says:

"When searching for MPEG file signatures at sector boundaries, the internal algorithm ensure that no overlapping MPEG fragments and no MPEG fragments in the middle of known MPEG files will be output/listed. This is useful because the MPEG signature occurs throughout MPEG files, not just at the start."

That seems to be not working for me, since I'm getting many files in the log that I believe is the same MPEG file.

Since MPEG moved to CHECK ONLY search, shouldn't this statement move to another part of the help? Well, I'm a bit confused here, since I can't find this check only table, is that a feature of Forensics and not of the plain WinHex??...
Top of pagePrevious messageNext messageBottom of page Link to this message

Alfons Kramer
Username: admin3

Registered: 4-2004
Posted on Thursday, Nov 6, 2008 - 12:27:   

Recovering MPEG files at the sector level is a tricky thing to do. Therefore it is recommended to try to recover at the file system level first. Advanced features like recovery by NTFS Journal analysis are only available for the forensic edition of WinHex.

You are completely right about moving the help entry you referenced.

There is a build-in carving support for a lot of file formats in WinHex right now. Unfortunately, the MPEG file format is not among them. You are right, there is a potential to crawl streams and frames and concatenate them to fragments. But at the moment I cant promise anything.
Top of pagePrevious messageNext messageBottom of page Link to this message

Jimmy Weg
Username: jw

Registered: 7-2006
Posted on Thursday, Nov 6, 2008 - 17:02:   

I've added this signature to my custom signature file: \x00\x00\x01\xBA\x21\x00\x01\x00. I've had better luck with this one. If you want to add any MPEG signature, I suggest a custom file, as it will not be overwritten when you update your application using the setup.
Top of pagePrevious messageNext messageBottom of page Link to this message

Alfons Kramer
Username: admin3

Registered: 4-2004
Posted on Thursday, Nov 6, 2008 - 18:07:   

This signature is too narrow, it just catches certain MPEG1 files. I recommend

MPEG1 \x00\x00\x01\xBA[\x21-\x2F]

and

MPEG2 \x00\x00\x01\xBA[\x44-\x7F]

Footer is \x00\x00\x01\xB9.

There is actually a carving support in WinHex for MPEG files build in as the help entry told - at least in the forensic edition. A MPEG signature must be present in the 'file type signature Search.txt'.
Top of pagePrevious messageNext messageBottom of page Link to this message

Jimmy Weg
Username: jw

Registered: 7-2006
Posted on Thursday, Nov 6, 2008 - 23:30:   

Thanks, Alfons. I ran "my" signature and the two you suggested against an image that contained a large number of MPG videos. I used a default size of 10,000KB. I aborted MPEG1 after XWF found about 7,000 files and reported 505 minutes remaining. There were many corrupt files and fragments.

With MPEG2, I recovered about 200 files, and many were segments or did not render. It took about ten minutes to carve the files.

With the signature that I posted, I carved about 300 files in ten minutes. I'd estimate that 90% were viewable, although some were segments. I added your footer to this signature, and the results were almost identical.

I think that the results are largely due to the type of MPEG that's on my image. This type must be the one that I encounter most often.
Top of pagePrevious messageNext messageBottom of page Link to this message

roberto caldas
Username: roberto_sc

Registered: N/A
Posted on Friday, Nov 7, 2008 - 1:08:   

I have many MPEG files in my HD but I just want to recover the ones that I recorded with my camera. Is it a good idea to see the signature of one of my camera's video and look for this signature? Will it be the same 5 bytes for all my camera videos? (why do MPEG2 signatures change?)

Thank you
Top of pagePrevious messageNext messageBottom of page Link to this message

Jimmy Weg
Username: jw

Registered: 7-2006
Posted on Friday, Nov 7, 2008 - 1:14:   

Yes, it's a very good idea. I may scan a sample of existing MPG's on an image and see which header may be best. I haven't seen a header that deviates from the initial \x00\x00\x01\xBA, and you can add one or more bytes depending on your findings.
Top of pagePrevious messageNext messageBottom of page Link to this message

Alfons Kramer
Username: admin3

Registered: 4-2004
Posted on Friday, Nov 7, 2008 - 9:24:   

The MPEG Type is coded in the first bits of the 4th byte. Next comes the System Clock Reference value scattered over three bitfields. Jimmy's signature has type set to MPEG1 and the System Clock Reference value is zero. This can be characteristic for certain MPEG makes but one can not relay on that.
It is a good practice in file carving to adapt the MPEG signature to the particular circumstances.
Top of pagePrevious messageNext messageBottom of page Link to this message

roberto caldas
Username: roberto_sc

Registered: N/A
Posted on Monday, Nov 10, 2008 - 12:32:   

Thank you Jimmy and Alfons!

I got a good improvement doing this.

Then I noticed that the first 64 bytes of my camera's videos are the same. After I noticed that my cousin's camera are the same until the 11 first bytes. Both cameras are of the same model. So I'm here to ask where to find the specification of MPEG 1 and 2 to understand what are these 64 bytes. I couldn't find on the internet.

Another question, is this the correct way to set "don't care" on some bytes in WinHex: \x00\x00\x01\xBA[\x00-\xFF]\x00\x01 ?

Thank you


My header:
00 00 01 BA 21 00 01 00 01 80 38 E5 00 00 01 BB
00 0C 80 38 E5 06 E1 FF C0 C0 20 E0 E0 40 00 00
01 C0 0B 48 FF 40 20 21 00 01 4D 59 FF FD 48 CC
54 45 54 43 32 12 49 24 92 00 00 AA AA AA AA AA
Top of pagePrevious messageNext messageBottom of page Link to this message

Alfons Kramer
Username: admin3

Registered: 4-2004
Posted on Monday, Nov 10, 2008 - 14:20:   

The relevant specification is ISO/IEC 13818. But this is not available for download in electronic form. Instead you could try
http://dvd.sourceforge.net/dvdinfo/mpeghdrs.html
www.andrewduncan.ws/MPEG/MPEG-1.ps

There is a shortcut for the character class [\x00-\xFF] "any character", it is just the dot "." .

Your sample can be interpreted as MPEG-1 packet header, followed by a System Header at offset 12, followed by an audio stream header at offset 30.
Top of pagePrevious messageNext messageBottom of page Link to this message

roberto caldas
Username: roberto_sc

Registered: N/A
Posted on Tuesday, Nov 11, 2008 - 0:30:   

Thank you Alfons.

Now I think I know the sector (offset) of many good files from the camera!

----

I'm afraid of losing all this by taking a new snapshot.
So, my questions are: with the full version of WinHex is it possible to save a snapshot? Is it possible to tell WinHex to save (copy) the next x megabytes after a given offset into a MPEG file?

Thank you
Top of pagePrevious messageNext messageBottom of page Link to this message

Stefan Fleischmann
Username: admin

Registered: 1-2001
Posted on Tuesday, Nov 11, 2008 - 4:35:   

> with the full version of WinHex is it possible to save a
> snapshot?

The question seems to be based on misinformation. The volume snapshot is always saved to the disk. When working with a case, in the metadata directory of the respective evidence object, otherwise in the directory for temporary files, as "Volume *.dir" files. If the latter is the case, the volume snapshot files are even kept between sessions depending on the corresponding option in Options | Security. You can also copy such files if you like and keep the copy somewhere else.

> Is it possible to tell WinHex to save (copy) the next x
> megabytes after a given offset into a MPEG file?

Maybe you can write a script that does something like this.

Add Your Message Here
Post:
Username: Posting Information:
Only registered users may post messages here, i.e. you need to have an account.
Password:
Options: Enable HTML code in message
Automatically activate URLs in message
Action:
Forum operated by X-Ways Software Technology AG.