ZenHAX

Free Game Research Forum | Official QuickBMS support | twitter @zenhax | SSL HTTPS://zenhax.com
It is currently Tue May 18, 2021 4:00 am

All times are UTC




Post new topic  Reply to topic  [ 3 posts ] 
Author Message
PostPosted: Sat Apr 17, 2021 7:22 pm 

Joined: Sat Apr 17, 2021 1:01 am
Posts: 2
I have ATIHv14tib archives many and hope your tool can unzip them. I tried with FULL (Standalone) backup archive I made using options of the following.

Choose C: System drive - This drive has two 4K cluster Format NTFS partitons C: and D: For backup System I choose partition 1 C: only it usually has a check mark on it by default.
Set drive to backup another internal drive not this drive for speed. And set file name for the backup archive.

Other Options:
FULL Backup
Maximum Compression
Verify

I check the log after this has completed for errors. Then after restart the pc.

For some reason I cannot figure out how to decompress using offzip so the .bin image is able to be mounted or seen correctly with other softwares. Always seems to produce bad decompressed image.

So far tried with the following, none of these so far has made a working decompressed archive.

Offzip -R -a -1 -Q -z 15
Offzip -R -a -1 -Q -z -15
Offzip -R -a -1

I have also tried with differing numbers than 15 I read that numbers can be 0 to 32 but is a hit and miss and takes a while with large backup archive. Maybe useful if offzip could optimize what best number to use for difficult file with a scan mode to figure that out. That said these archives are maybe same compression as set before backup or are they variable always try to achieve Maximum compression ?


Is it me or is it offzip at fault here !


Top
   
PostPosted: Thu Apr 29, 2021 8:01 am 
Site Admin
User avatar

Joined: Wed Jul 30, 2014 9:32 pm
Posts: 12242
Probably the backup doesn't use deflate or zlib.

It's not possible to "guess/optimize" the choose between zlib and deflate because zlib is a container of deflate data, if you have a zlib data you will dump it if you both use -z 15 and -z -15, if you have deflate data then only -z -15 will do it.

-z is referred to the windowBits field of zlib API:
https://www.zlib.net/manual.html

Quote:
The windowBits parameter is the base two logarithm of the window size (the size of the history buffer). It should be in the range 8..15 for this version of the library. Larger values of this parameter result in better compression at the expense of memory usage. The default value is 15 if deflateInit is used instead.

For the current implementation of deflate(), a windowBits value of 8 (a window size of 256 bytes) is not supported. As a result, a request for 8 will result in 9 (a 512-byte window). In that case, providing 8 to inflateInit2() will result in an error when the zlib header with 9 is checked against the initialization of inflate(). The remedy is to not use 8 with deflateInit2() with this initialization, or at least in that case use 9 with inflateInit2().

windowBits can also be –8..–15 for raw deflate. In this case, -windowBits determines the window size. deflate() will then generate raw deflate data with no zlib header or trailer, and will not compute a check value.

windowBits can also be greater than 15 for optional gzip encoding. Add 16 to windowBits to write a simple gzip header and trailer around the compressed data instead of a zlib wrapper. The gzip header will have no file name, no extra data, no comment, no modification time (set to zero), no header crc, and the operating system will be set to the appropriate value, if the operating system was determined at compile time. If a gzip stream is being written, strm->adler is a CRC-32 instead of an Adler-32.


Top
   
PostPosted: Sat May 15, 2021 12:15 am 

Joined: Sat Apr 17, 2021 1:01 am
Posts: 2
about -z what I have read
-z 15 a zlib file that has headers and crc data (the file can verify itself using crc)
-z -15 a zlib raw file with no headers and crc data
-z a gzip file maybe uses a number between -z 16 to 31 to decompress.

The backup archive is a verified ATIHv14tib file, as verifiable I guess it is -z 15 (headers and crc)

offzip.exe -Q -R -a -1 -z 15 "path:\infile" "path:\outfile.bin" 0

infile - 4,246,256 (compressed ATIHv14tib backup archive source file)
outfile1 - 7,875,284
outfile2 - 2,516,067 (run with same command from outfile1 to outfile2)

Try with with option -z -15 instead of -z 15 on infile produces only errors during scanning -zlib Z_DATA_ERROR, the data in the file not in zip data format.

outfile1 doesn't mount or can be seen with drive image mount softwares as a disk. With a hex viewer outfile1 does now show the NTFS header at the start of the outfile1. With infile this is not viewable as it is compressed.

What is strange is the file sizes in that the data is not been been kept on successive scans outfile1 to outfile2. That also maybe the first scan infile to outfile1 has also lost data as happened from outfile1 to outfile2 any ideas!


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 3 posts ] 

All times are UTC


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Powered by phpBB® Forum Software © phpBB Limited