Slowest Tool on Earth, but Effective, support for BM2

Using PhotoRec to recover lost data
Forum rules
When asking for technical support:
- Search for posts on the same topic before posting a new question.
- Give clear, specific information in the title of your post.
- Include as many details as you can, MOST POSTS WILL GET ONLY ONE OR TWO ANSWERS.
- Post a follow up with a "Thank you" or "This worked!"
- When you learn something, use that knowledge to HELP ANOTHER USER LATER.
Before posting, please read https://www.cgsecurity.org/testdisk.pdf
Post Reply
Message
Author
neonred
Posts: 3
Joined: 22 Aug 2018, 19:08

Slowest Tool on Earth, but Effective, support for BM2

#1 Post by neonred » 22 Aug 2018, 19:30

It's looking like it will have completed its file recovery in 48 hours for a 64GB USB Stick; I pitty any person with a Terabyte hard drive, using this tool. Though it is a lot cheaper then sending it to the labs. Circumstance, I accidently begun to format with zeroes (say the first 2% of the drive), and I then reformated (without overwrites), so this usb stick has been formatted twice. To my knowledge, the partition with the existing files should be totally destroyed. A mere re-format doesn't do that, but those zeroes make quite work of a partition. Throwing this usb stick at Easeus Data Recovery Wizard for Mac, revealed just how shity the software was under RAW circumstances; it only found 165 files out of many thousands. My first indication photorec was working was when it successfully recovered all 35 FLAC files on the drive; now I havent tested these, but wow these were ~50MB a piece; HQ beattle tracks. I knew then no other software could outperform this one in terms of file recovery, by any significant margins. BTW, I know with great certainty the read/write speed of this USB Stick is a minimum of 20MB/S, though I suspect the read is faster. This is on an old 2009 macbook pro. It would be nice if I could give a few parameters to speed it up a little and specify to start the scan from a particular sector. It would also be nice if its supported the boardmaker file extension .BM2 A lot of templates for therapy are in that file extension, and as I am not the therapist, it is vital that most of these be recovered. I can create and send 1 or 2 sample files if that helps.

Sponsored links

User avatar
cgrenier
Site Admin
Posts: 4468
Joined: 18 Feb 2012, 15:08
Location: Le Perreux Sur Marne, France
Contact:

Re: Slowest Tool on Earth, but Effective, support for BM2

#2 Post by cgrenier » 23 Aug 2018, 06:05

Please provide at least 3 file samples for bm2.

neonred
Posts: 3
Joined: 22 Aug 2018, 19:08

Re: Slowest Tool on Earth, but Effective, support for BM2

#3 Post by neonred » 23 Aug 2018, 17:00

https://www37.zippyshare.com/v/6OjxtIPc/file.html (ones that I made)
Corruption on production files too high to include such files.

I've got some really good feedback for you, most of that I will share in a separate thread. You can improve your documentation and software with the upcoming feedback. But in relation to signatures, let me just comment on that. First of all, the software should indicate that the user signature will has been loaded. I ran your suite on linux, put the signature file in the home directory, but had no indication that it was loaded or working. If it tells me it is loaded, and it is not detecting my signatures, then that indicates a coding issue. But if I don't know that file is even loaded, I cannot figure out what's wrong.
You signature example in your documentation is too simple; I had to think which I was fun but something obviously didn't pan out as it did not detect the files.
Now this will come perhaps a bit as a shock. But hex editors on mac present data differently than they do on windows. On windows, a byte is broken it 4 pieces, and so you have 2 digit groupings. On mac, a byte is not broken up. The confusion is, and to represent a byte, is suppose you have 0x00000100, this is one byte. If I express that in a signature, does the software expect or can I simplify as 0x100? Also, ascii and sort of a lack of standardization make it so that values under the letter A or 38 in the ascii table; it is not clear what is the character representation and by that I mean there are difference between mac and windows. For example, 00 is a dot on windows, but may be a space on mac. For example, 0x40420f0035, on a mac this is @B 5 Three spaces between B and 5. But as I have said on windows 00 is a dot. Also your documentation over simplified signature example doesn't explain how to input multiple signatures for a single extension. The first signature I tried was:

bm2 8 0x00000100c0300000c0300000c0300000

and this photorec.sig was place in the home directory and I ran it for a bit (not all the way) and it didn't detect any.
I then tried the following photorec.sig
bm2 12 "¿...¿...¿" (this is suppose to approximate the above starting from c0300000) Though maybe the software was picky, and this was more accepting.
bm2 36 0x40420f0035
bm2 51 0x40420f0035

Interestingly, the reason for the difference in the last two signatures has to do with whether a background was used. Poor programming on their part, I say.
I did a full scan with that signature and did not detect any file.
Now I have a correction to make with regard to EaseUs which I will go into more detail later.
Easeus detected 42199 files, photorec detected around 25,000 can't remember exact number. I know the reason for this.
The fact that Easeus keeps corrupted files could easily explain the discrepancy, but I know there is more to it.
I will also perform my scan on linux again, but this time with keep corrupted files.
Another possible improvement would be to create a log file, exact appearance as terminal stats, for all corrupted file types.
That way it communicates with the user, "Ya, I found them, but unfortunately they were not recoverable."
You could then have an option in the program, "only scan this sector to this sector, try to recover files, max time allowed 60 min", by the end of, and this case one 1 hour, only the best least corrupted files should remain, the user can then test or examine these files to see if there is any use in keeping them. Stay tuned, I've got a lot more feedback coming your way.

I should add, there should be an option for yet another separate log to log sector ranges for a given extension, in my case, bm2.

neonred
Posts: 3
Joined: 22 Aug 2018, 19:08

Re: Slowest Tool on Earth, but Effective, support for BM2

#4 Post by neonred » 23 Aug 2018, 18:07

Also there seems to be a bug or otherwise misreporting:
10-15% complete scan indicates ~1200 zip files
but a look at a 100% complete scan reveals only 91 zip files.
and I quote, "zip: 1200 recovered" = incorrect, very incorrect.
If you want to log file, just tell what and where it is.

User avatar
cgrenier
Site Admin
Posts: 4468
Joined: 18 Feb 2012, 15:08
Location: Le Perreux Sur Marne, France
Contact:

Re: Slowest Tool on Earth, but Effective, support for BM2

#5 Post by cgrenier » 24 Aug 2018, 05:55

0x00 is an ascii NUL byte. Some utilities choose to display a space or a dot instead of this non-printable char.
When PhotoRec reports 1200 zip, it doesn't mean 1200 files with the zip extension but 1200 files using the zip format, it includes zip, docx, xlsx...

The following signature is valid for the files you shared

Code: Select all

bm2 1 0x0000000000000000000100c0300000c0300000c0300000

Code: Select all

fidentify *.bm2
1.bm2: bm2
2.bm2: bm2
untitled.bm2: bm2
The signature you shared is valid.

Code: Select all

 bm2 8 0x00000100c0300000c0300000c0300000
If PhotoRec is started with "/log", a log file named photorec.log is created. It lists when a signature file is used:

Code: Select all

Open signature file /home/user/.photorec.sig
register a signature for bm2
719 first-level signatures enabled

Post Reply

Who is online

Users browsing this forum: Google Adsense [Bot] and 1 guest