Look first bytes of RAW. Probably it contains the header of some format.
You can show these bytes here in hex.
Here are the first 48 bytes. Please note that my zipped file had folders too.
50 4B 03 04 14 00 00 00 08 00 59 3C 03 3F 4A DA
82 8B E2 61 3B 00 3F 72 3B 00 0C 00 00 00 44 53
43 30 32 31 39 31 2E 4A 50 47 EC BA 05 5C 55 4F
It's ZIP format header.
Rename it to raw.zip and try to open it with 7-Zip / WinRAR / WinZip.
If you can open it with 7-Zip, you can check "Physical size" in "Properties".
Renamed the file to raw.zip (also to raw.7z). Upon extraction there are only the same 4 jpg files which I found earlier during incorrect execution of your instructions. Total raw.7z size is 1.95G, whereas extracted files are of 14M. Can it be that other files that are not being read are inside folders? If yes, then is there a hex notation to identify folders?
Is there a good place where I can read about hex notations for different file/folders?
That zip is first file in RAW.
You just need good praser.
If you have any pareser, you can try to parse manually.
1) Open raw.zip in 7-Zip file manager.
2) Look "Physical size" in "Properties".
And split RAW.zip to
RAW.zip.001 - size of "Physical size"
RAW.zip.002 - ramainder
then try to open RAW.zip.002 in 7-Zip an go to step 1.
Open raw.zip in 7-Zip 9.30 and press "Info" button.
You probably will see 'Physical Size'.
First of all, I can't thank you enough for your expertise and help! I was able to retrieve some files.
But there is still some way to go. First 5 iterations were successful (I could get files). 4 iterations gave jpg file, 5th had an exe file, now after the fifth split it fails to open the archive, says 'Cannot open file bigfile.zip.002.002.002.002.002 as archive'
I still suggest you to search some parser program.
What physical sizes and archive types do you have in previous iterations? Was it ZIP in all cases?
Show first bytes of that file that you can't open.
Trust me, it's on my mind to continue to search for a parser even if I am able to parse all of these manually. I am still searching in parallel.
bigfile.zip 14765194 (jpg files)
bigfile.zip.002 19769688 (jpg files)
bigfile.zip.002.002 18918408 (jpg files)
bigfile.zip.002.002.002 18963427 (jpg files)
bigfile.zip.002.002.002.002 1167681 (exe file)
bigfile.zip.002.002.002.002.002 unable to open
Tried split with .7z type too, failed at the same step.
Here are the first 96 bytes :
52 49 46 46 96 B5 F5 00 41 56 49 20 4C 49 53 54
A6 01 00 00 68 64 72 6C 61 76 69 68 38 00 00 00
35 82 00 00 20 A1 07 00 00 00 00 00 10 00 01 00
54 05 00 00 00 00 00 00 02 00 00 00 00 EE 02 00
40 01 00 00 F0 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 4C 49 53 54 D2 00 00 00
If you open that file in hex editor, you will see text information in ascii column: RIFF *
Probably it's AVI file.
96 B5 F5 00 (little-endian) - probably is some size (total or partial)?
You can convert that value to decimal with CALC program.
Then split again and rename first part to AVI.
Look RIFF (AVI) format description in internet.
Ok, on calc using Dword 96 B5 F5 00 converts to -1766460160. So I used the unsigned value 1766460160, and got one avi file out of that.
1) The avi content is much smaller than 1766460160 -- just 45 seconds. Can the fileSize be inclusive of other avi files?
2) Following msdn content (http://msdn.microsoft.com/en-us/library/windows/desktop/dd318189%28v=vs.85%29.aspx):
"...The value of fileSize includes the size of the fileType FOURCC plus the size of the data that follows, but does not include the size of the 'RIFF' FOURCC or the size of fileSize..."
From this, should I have added 8 bytes to 1766460160?
3) The first bytes of the remainder are -- this also is not opening in the archive (guess I need to find a parser to finish this job)
B3 1E BE D5 40 0E 3A 73 5D 70 97 32 BB 26 71 E5
95 87 00 B4 A0 F7 EB 55 7B 13 A0 B9 E3 9E 69 F1
Wow! Of the 1.95G that came out as RAW.7z, I was able to extract all files except the last 41M as that file's size is ~44M.
If you happen to code the solid block range determination program, where will you be announcing it?
I shall keep searching on the internet for a good parser for this job and update here if I find one.
Thank you so much! Your selfless help has touched me deeply. Really!
By the way, these pictures and videos are of my son from his earliest days till now -- he turns 2 next month. So you know the value it holds. Thanks again!
If the last file in 1.95G RAW file is AVI, probably next file is also AVI, and probably you can find solid block range.
1) compress any AVI file to avi.7z (lzma method, ultra level).
2) open avi.7z in hex editor, and look 4-5 bytes at offset 32 (0x20). First byte of these 5 bytes must have has value 00.
3) try to find these 4-5 bytes in original 3.57 GB bad.7z
Search 5 bytes at first.
4) if you can find these bytes in bad.7z, split bad.7z into 2 parts:
- bad.7z.001 (the part before these bytes)
- bad.7z.002 (that part starts with these bytes)
5) And use original method to restore archive:
split big a.7z into
- a.7z.001 - 32 bytes
- a.7z.002 - bad.7z.002 size
- a.7z.003 - remainder
Rrename bad.7z.002 to a.7z.002
Extracting a.7z.001 gave file.out (RAW). Got few more avi files out by splitting this .out file. Now I have a file.out.002 that has it's first bytes as:
FF D8 FF E0 00 10 4A 46 49 46 00 01 01 00 00 01
It's a JFIF. But this .002 isn't opening in the archive, though it does if I rename it to .001. Can you suggest the way forward?
(Should I manually look for FF D9, the ending bytes of jpg file, and continue like that manually, or is there an easier way to find multiple files at a time?)
Maybe you can search next "FF D8 FF E0".
That will be start for new jpeg file?
Yes, I am looking for the end part of one file, FF D9 (optionally sometimes it seems to be FF D9 FF) followed by either FF D8 FF E0 or FF D8 FF E1 which are the 2 possible start notations. I am not aware of any other.
Good evening friends.
I'm having a similar problem, with a very important file backup, generated by Cobian Backup, format .7 z. The bigger problem is that now I need the files from backup, due to a disk problem, and as always Cobian reported successful backup, I never had the idea to test the compressed file. There possbilidade help me what the problem file, and how to recover what's inside? It is very important.
File Size: 54,781,417,711 bytes
First 48 bytes: 37 7A BC AF 27 1C 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 68 33 BE 1C 86 30 77 60 F4 A4 84 2A 40 0C 1C 76
Last 96 bytes: 62 3F 27 B1 60 20 CC 24 38 C3 F7 80 FA 8E 7E 59 3C 23 B7 0B 7D F7 E0 86 FA F1 68 BA D5 3C 6C 8F 66 E6 6A AE 57 6A 9B D2 3C 11 A8 B1 13 00 4B 21 8F ED F1 E3 6C 3E 0E 45 4A 41 71 6C 3B 31 41 CB 35 B5 3B 6F 99 57 47 61 8F E1 08 29 90 46 80 03 9B FF 87 F1 E4 A6 43 9E 43 67 CB 9F 6C 39 C1 40 3B AB EA
How can I do to get Hexadecimal start of the file, and the end of the file to post for you?
I do have same problem. Almost a year ago, I archived about 7.5GB of data using 7z and now I am not able to open it.
Please let me know how to extract header information as my file is password protected.
Really appreciate any help in this regard as I have deleted the original files thinking I would be able to recover at later time.
Please please help!
I have made a post on StackOverflow looking for a program to do the parsing:
In the time since the last activity on this thread, have there been any relevant developments?
7-Zip 9.32 alpha supports "Parser" mode.
So it can find acrhives (7z, rar, zip, cab, ...) inside big file.
I have started experiencing similar issues. For some time things have been fine. Then suddenly archives have started being corrupted. Or at the least 7-Zip is failing to deal with the archives properly.
The issue has been happening for 7z archives of all shapes and sizes, seemingly also RAR archives files. Usually when extracting file(s), will get 0 bytes if I get any at all. Also when adding/replacing file(s).
File size on disk: 447,086,592 bytes
First 48 bytes:
37 7A BC AF 27 1C 00 03 A0 CA 05 54 9F F7 A5 1A
00 00 00 00 26 00 00 00 00 00 00 00 EC 08 AA 04
00 24 91 02 5E 97 FA C6 2E 8E CC 5F E4 89 44 FF
Last 96 bytes:
15 48 74 B5 E8 65 8E 1E A5 8B 4D D9 CE 23 C0 24
D6 27 1A 42 FD D7 B6 D7 C5 02 4F 5E 5F E5 CE 7C
25 8D 48 AB 53 72 E5 FA 68 5D 2B 9B 51 33 F1 85
86 A9 10 10 08 B3 B8 1B B0 00 17 06 F0 67 F2 A5
1A 01 09 85 38 00 07 0B 01 00 01 23 03 01 01 05
5D 00 18 00 00 0C 94 40 0A 01 06 53 76 76 00 00
This doesn't have to do with any system DLL's possibly breaking?
Update at least on my particular issue. I have many archives that are appearing "corrupt". Actually, I'm not sure whether they are at all. I have also discovered a directory that is "corrupt". I'm not sure I need to run a scan disk on the drive for starters.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.