search

MacPaw / XADMaster

Objective-C library for archive and file unarchiving and extraction
GNU Lesser General Public License v2.1
103 stars 44 forks source link

Add support for unpacking compressed disk images into uncompressed disk images #21

Open ci-macpaw opened 14 years ago

ci-macpaw commented 14 years ago

Originally reported on Google Code with ID 298

d235j.1:

Disk Copy 6.1 and later generates compressed images in the NDIF format. This can include
two compression algorithms: KenCode and an Apple-specific algorithm. Both of these
algorithms store critical data in the 'bcem' resource in the resource fork.

It would be nice if there was a support to "convert" such images into UNcompressed
NDIF images (where the resource fork does not keep any useful information). Disk Utility
can do this, but the KenCode format is undocumented (there is an ADC compression scheme
documented at http://www.macdisk.com/dmgen.php but I do not know if it was implemented
as early as Disk Copy 6.x).

Disk Copy 6.0 (which was never distributed much, and therefore almost never used) also
has a compression scheme but it appears much simpler and does not use the resource
fork. I don't know if it is worthwhile implementing this.
ci-macpaw commented 14 years ago

d235j.1:

There's that, there's also dmg2img from http://vu1tur.eu.org/tools/

But most of these can only handle UDRW, UDRO, UDZO, and UDBZ (perhaps UFBI too). UDTO
is *probably* just raw device.

There is info about the ADC algorithm at http://www.macdisk.com/dmgen.php . This is
used in UDCO and perhaps UDCo and ROCo. Not too sure.

Also, Rdxx (probably UDRo too) uses some form of RLE or simple compression to eliminate
long runs of zeroes.
ci-macpaw commented 14 years ago

atr000:

Any hints using the lib that the iphone/jb folks use?

http://github.com/planetbeing/xpwn/tree/master/hdutil/
ci-macpaw commented 14 years ago

paracelsus:

Seems to be 14 files here, yes.
ci-macpaw commented 14 years ago

d235j.1:

all fourteen? I may not have uploaded all...
ci-macpaw commented 14 years ago

paracelsus:

All right, got them.
ci-macpaw commented 14 years ago

d235j.1:

I've uploaded various kinds of images (these are zipped with Archive Utility, so the
resource fork is embedded in the zip in AppleDouble format) to http://dec8.info/priv/images/
.

There are the following formats. I've tried to cover as many as possible:

                      UDRW - UDIF read/write image
                      UDRO - UDIF read-only image
                      UDCO - UDIF ADC-compressed image
                      UDZO - UDIF zlib-compressed image
                      UDBZ - UDIF bzip2-compressed image (OS X 10.4+ only)
                      UFBI - UDIF entire image with MD5 checksum
                      UDRo - UDIF read-only (obsolete format)
                      UDCo - UDIF compressed (obsolete format)
                      UDTO - DVD/CD-R master for export
                      UDxx - UDIF stub image
                      UDSP - SPARSE (grows with content)
                      UDSB - SPARSEBUNDLE (grows with content; bundle-backed)
                      RdWr - NDIF read/write image (deprecated)
                      Rdxx - NDIF read-only image (Disk Copy 6.3.3 format)
                      ROCo - NDIF compressed image (deprecated)
                      Rken - NDIF compressed (obsolete format)
                      DC42 - Disk Copy 4.2 image

The ones I'd focus on are Rken and ROCo, as well as the ShrinkWrap "StuffIt" format
(NOT in that list) which is the worst of the whole set, since Disk Utility doesn't
support it. Several of the images are probably uncompressed but with weird headers.
ci-macpaw commented 14 years ago

paracelsus:

Since I don't really know enough about the format, I don't think I have any good ideas
for good test cases, so it's better to just take any old file (or a couple of them)
and use that (and upload the unpacked ones, too). I don't have any myself, so I'm no
help there.
ci-macpaw commented 14 years ago

d235j.1:

I see.
Anyway, can you upload an NDIF (or several) of some sort that I can convert to the
more obscure formats (ShrinkWrap)?
ci-macpaw commented 14 years ago

paracelsus:

The best idea might be to have the library only handle UDIF, and then put in some wrapper
code that can convert an NDIF into UDIF before passing it to the library. Will have
to see.

(The library works entirely on abstract data streams, to make it possible to unpack
directly from inside an archive without temporary files, which is why it is hard to
handle anything that isn't a single data stream.)
ci-macpaw commented 14 years ago

d235j.1:

Probably.

I don't think it would be too hard to use the UNIX API (filename/rsrc) to copy the
resource fork of the file into a temporary data fork file, then use GTResourceFork
or something similar to take that apart. I've attached GTResourceFork (there are references
to FurcKit even though it isn't used) because the developer who had it took down his
site.
ci-macpaw commented 14 years ago

paracelsus:

I was looking things up, and noticed there's some UDIF format which supposedly is just
the data and resource forks of a NDIF concaternated together with a header. That would
be much easier to handle, so that seems like a good thing to start with.
ci-macpaw commented 14 years ago

d235j.1:

I can submit testcases if necessary -- though 'hdiutil' in OS X can generate all of
the DC6.1+ images.

ShrinkWrap images, which are similar to DC6.1+ images in format but use different compression
schemes, are much more important in my opinion. I can submit testcases for these --
just give me some ready-made NDIF images to start with.

I am NOT asking that The Unarchiver handle images fully, just that it decompress them.