Page 1 of 1

File truncated because of a false header & other issues

Posted: Mon Feb 01, 2016 2:18 am
by abolibibelot
Hi,

Recently, for the sake of fun and knowledge, I ran a few recovery softwares, including R-Studio (which is my favorite overall and I've tried a few), on a 500GB hard drive which had no problem whatsoever, after copying a large amount of data on it (100GB), which left about 20GB of free space. I knew what files had been on it and then erased at some point, files which I had elsewhere, that way I could make comparisons and check the accuracy of the recovery. So, here are some things I found out.

- When running the scan on the HDD itself with R-Studio 7.7, I had this error message :
Error File System 07/01/2016 21:50:19 Known File Types scan thread analysis timeout at sectors 123687680..123687936 (61843840..61843968KB)
Error File System 07/01/2016 21:50:19 Known File Types scan thread has been restarted because of analysis errors at sectors 123687680..123687936
And very few "extra found files" were actually found. I ran the analysis a second time with the exact same result. Apparently this issue could be related to a lack of memory : http://forum.r-tt.com/scan-freezes-t430.html. It could also be related to the fact that it had been quite a long time since the last proper reboot when I performed this test (several weeks at least).
Yet surprisingly, R-Studio 5.4 (which I have kept on that system despite upgrading) didn't have this issue and found many more files, albeit several of them with inaccurate sizes (too large).
Meanwhile, Recuva and Photorec found many of those files (mostly AVI & WMV videos) with the exact correct size and equal CRC32 for most of them, or only a few "padding" bytes missing at the end (the extra files recovered only by R-Studio 5.4 were mostly fragments of overwritten files, but no other software found these readable fragments).

- I then extracted the free space with X-Ways Forensics, and ran R-Studio 7.7 on that file, treated as a volume image. This time it proceeded with no error, and found most of the same files that were found by R-Studio 5.4 / Recuva / Photorec (albeit not without caveats, see below). But still, there were files recovered by R-Studio 5.4 which were not found by any other software, even Photorec, a free software which is specialized in raw file carving and usually carves everything there is to carve. How can it be explained that the newer version performs worse in this particular case ? (In other instances I've found the opposite.)

- Among the files found by R-Studio 7.7 (from the free space analysis), there's one that is truncated, a WMV file which should be 351MB and is only 265MB ; if I examine both the recovered file and the original in X-Ways Forensics using the "Synchronize & compare" function, I can see that that there is a random false JPG file signature at the truncature point, i.e. « ÿØÿ », which made R-Studio treat it as the begining of a JPG file, which it is not. The file in question was still complete on the remaining free space, and was fully recovered by Recuva and Photorec (same size & CRC as the original).
w w w . c j o i n t . c o m/c/FBbgimIoppy
On the contrary, an MP4 file recovered by R-Studio 7.7 had an abnormally large size, and after painstakingly comparing it with known MP4 files which had been recently erased I found out that it was simply 4 of those files joined together, despite the fact that each of them was still complete and with a correct header. (Recuva didn't find those files though, but Photorec carved them each with their correct sizes.)
As evidenced here file recovery is no exact science (at least from the end user's point of view !), but again how can it be explained that in such a case R-Studio performs worse than free softwares, despite a much longer scan ? (The two failed attempts at scanning the 500GB HDD took about 4 hours, whereas Recuva completed its "deep" analysis in about 20 minutes.) Are any of these known issues, and could they be adressed in a future new version ?

Thanks to those who will scratch their heads trying to figure out these quandaries !...

Gabriel (France -- I hope my english is good enough for me to be well understood on such a technical matter)

Re: File truncated because of a false header & other issues

Posted: Mon Feb 01, 2016 10:04 am
by Data-Medics
RAW file carving has never been R-Studio's strongest point. However it makes up for it in it's ability to work with damaged file systems. Just the other day I ran a scan on a damaged FAT file system that even GetDataBack couldn't understand any folder structure and R-Studio pieced most of it back together just fine. That, plus the ability to custom file carve make it a go to tool for data recovery. However specific file types needing RAW recover still require a different tool at times.

Re: File truncated because of a false header & other issues

Posted: Mon Feb 01, 2016 10:58 am
by Alt
I would rather point out that different data recovery programs use different data recovery algorithms thus producing different results in data recovery. In one case, one program can perform better, in another, another one. Moreover, sometimes, even a junk program can produce outstanding results in some cases, and a well-reputed program can fail. Surely, neither Recuva, nor Photorec are junk programs.

Re: File truncated because of a false header & other issues

Posted: Mon Feb 01, 2016 11:51 am
by abolibibelot
@ Data-Medics

Thanks for this quick reply.

Well, I'd say that R-Studio's file carving ability has been mostly excellent in previous instances, way better than that of GetDataBack for instance. In another situation, GDB [4.2.2} recovered a bunch of AVI files but none was readable or only a few seconds, probably because they had been fragmented, whereas RS [5.4] managed to recover the whole files perfectly readable. Generally, most of the "raw" files recovered by GDB turn out to be garbage, and it recognizes far less file types. I had great success recently with R-Studio [7.7] on a particularly tough recovery situation (it was for a friend's sister and it was not for fun, she was pretty much hopeless about getting her old stuff back from a 250GB HDD which combined bad blocks all over the place and a few botched OS re-install attempts going back and forth between Windows and Ubuntu -- after two nights of imaging with ddrescue, which rescued everything except 15MB of bad blocks, I ran R-Studio [7.7] on the resulting image file and it managed to piece together both the NTFS and the Ext3 partitions, with the structure mostly intact and many "extra found files" that were perfectly readable ; GetDataBack recovered the NTFS arborescence but with more errors, like missing or misplaced folders, and the "raw" files were mostly garbage ; I also tested Active@ File Recovery and Zero Assumption Recovery, which performed poorly, very poorly even for ZAR despite appearing like a very serious software ; I kept this image file so I can make further tests in the future, with other softwares or new versions of the ones I know, it's an ideal "cas d'école" !).

But in this case, I'm wondering why the older version [5.4] did perform better in that regard, and why a free software like Recuva gets a better result in 20 minutes than R-Studio [7.7] in 4+ hours.

By the way, what are your other "go-to" recovery softwares, and which one(s) do you use depending on which situation ? For example, in a similar situation, where you'd want to recover specific files which are no longer referenced in the file system (in this case neither RS v5.5 nor RS v7.7, neither GDB nor Recuva for that matter, could find the original folder which used to contain most of those files), what would be your "weapon(s) of choice" ?


@ Alt

Does that mean that to be serious about data recovery one has to try them all in each situation, and then merge the results ? How do pros proceed ?
And in this case, shouldn't it be expected for a newer version of a given software to perform better in all cases ? Regarding this "Known File Types scan thread analysis timeout", all the relevant insight I could find was in the aforementioned thread ; is this a known bug with this particular version ?

Re: File truncated because of a false header & other issues

Posted: Mon Feb 01, 2016 3:00 pm
by Data-Medics
I think what you are describing though wasn't really a RAW recovery, not if you're getting file names and folder structure. Part of R-Studio's real power is being able to analyze the indexing in the middle of an NTFS partition and combine it with whatever is left of the MFT, it's why it generally always works the best for cases with bad sectors (especially if they are in the file tables). It even works better, in most cases, than Data Extractor software that runs with PC-3000 and costs a small fortune.

As to discussing other software, I'd rather not do that on R-TT's forum. This is their site and anything which could be construed as promoting another product seems inappropriate. Perhaps we could have that discussion on a different data recovery forum such as this one. Data Recovery Forum

Re: File truncated because of a false header & other issues

Posted: Mon Feb 01, 2016 4:46 pm
by Alt
Being a master of this forum, I'd say that data recovery pros usually starts with 3 data recovery programs: R-Studio, UFS explorer, and DMDE. Each has its strengths and weaks.
Really serious professionals have also data recovery hardware like PC3000 and DDI. But they cost a lot and require special skills to work with them.
And then stop disguising other programs except R-Studio.

Re: File truncated because of a false header & other issues

Posted: Mon Feb 01, 2016 6:15 pm
by Data-Medics
You mean UFSExploder! I don't think R-TT has much to fear from them as their program has never been stable enough to use regularly. If I had a dollar for every time that program crashed I could quit working and retire :D . Only reason we use it is for the few odd file systems R-Studio doesn't support like XFS (which I'm hoping is in development ;) ). DMDE I don't find all that necessary, but is a handy tool to have nonetheless.