OT: "Proprietary" CD/DVD "formats" (layouts)

Doesn't using an ISO type file take care of that ? Or maybe one of the disk cloning softwares out there can do it.

I am *assuming* that the original LIVE *content* of the medium is accurately preserved/reconstructed by the imaging software.

But, AFAICT, these don't preserve the "non-live" data content of the medium. I.e., sectors that are not marked as "in-use" by the filesystem.

So, it is conceivable that an installer could examine the mounted medium and verify that the *used* sectors are all as they should be along with WHERE they should be... AND, that specific UNUSED sectors contain specific data that is deliberately placed there on the distribution medium with the expectation that it would NOT be recovered by simple "file copying" *or* even imaging software.

Beyond that, there is the issue of, does my ADDING a file to the file system image bother any such protection schemes. E.g., if an installer listed the VISIBLE files on the medium and compared that to a MANIFEST, my "SerialNumber" file would result in a discrepancy: "This is not the original installation medium!"

Years ago, folks went to great lengths to try to cripple the installer if they could infer that it wasn't "genuine media" (e.g., things like verifying that the medium was a "CD" drive and not a R/W drive).

Of course, the only way I would know for sure would be to try reinstalling each of these images... (not in my current play book!)

That will work, unless it doesn't. :)

Assuming you have a couple of files like

dos-3.3-install-bluray.iso dos-3.3-serial-number.txt

I would put both of those in something like a zip file or a tar file. tar won't compress - it will actually add a few bytes - but also gives you a checksum around the stored files, which may be handy.

zip can compress or not; sometimes the image file is huge and you know that either it's already mostly compressed, or it's on a slow medium, so just saying "zip -0 dos-3.3.zip dos-3.3-*" will let you create a zip file without wasting a lot of time on compression. Zip also gives you a checksum on the stored files, and these days, it's more likely that any given OS will have an unzip program available "stock" if you want to unpack the file later.

A lot of things seem to depend on an online license server these days, rather than a funny format on the install media, or a dongle. But it's hard to tell unless you try it in each case.

Matt Roberds

Yeah, ain;t that always the case? :-/

D'oh! Yes. But, then I'd need twice the space to decompress the file (i.e., the archive and it's contents -- though the archive may be compressible!) Installing an ISO on a thumb drive and booting off it (or, installing the software *from* that "virtual drive") is a bit easier than having to unpack a tarball/zip before you can get to this point.

For the most part, I've taken to NOT compressing (disk space is cheap) as, in the event of a glitch, I will have a greater chance of recovering *some* of the contents (e.g., most of the files before and after the glitch) instead of risking the entire archive (due to a bad sector, etc.).

I am storing MD5's separately so I always have some sort of "integrity measure" for the objects (which is a side-effect that compression usually affords)

Yup. My archives go back to my earliest days with "computers" (e.g., before PC's were even "mainstream" -- CP/M, ZDOS, etc.) which is why my concern -- and, why I saved *images* of floppies instead of just copying their contents, etc.

[Floppies aren't a problem because you tend to have *many* in a "set" for a particular product. So, you can pack all of the floppy images into an ISO and inject "SerialNumber.txt" without ever putting the contents of the floppy images "at risk"]

I'll have to make a best guestimate as to the risks... it would sure be nice(r) to have the S/N file in the root of the ISO than to have it tagging alongside!

AFAIK sector-mapping copy protection in not currently popular. hell, I don't even know if it's possible to have fragmented files on ISO9660 or UDF filesystems. also Image copies are too easy to do.

Phone-home based copy protection is the way things are done these days. so yeah it should be possible to add a file containing the activation code. I thnk I've done that with windows disks before. extracting the el-Torito boot partition, re-mastering the ISO-9660+Joliet filsystem with a code.txt file added to the root.

However if the images ar just disk files, just put the activation code into the filename of the image. Optionally zip the image.

--
umop apisdn

Use a tar file. Get really good at recognizing what the tar headers look like. Use vi to edit the headers off, leaving just the image file. :D

Good idea.

One argument against altering the image to include a text file with the serial number: at least for very popular install media, and enlightened vendors, the MD5 (or SHA1 or similar) for the install media *should* be available online. This gives you a further integrity check, and/or confirmation of what the hell this unlabeled CD-R/file is. If you put another file in the image, the MD5s won't match anymore.

The way around this is to do what you do now - store the MD5s on your own.

I remember being annoyed, back in the day, because somebody was paranoid of funny-floppy-sector copy protection. So he made disk images of a set of 5 or 6 floppies, but used no compression, so each disk image was like 1.46 MB. I had to zip them to get them to fit on 1.44 MB floppies, take the floppies home (this was faster than dialup), copy the zips to the hard drive, unzip, un-image, write images to floppy... only to find that the program *didn't use* funny-floppy-sector copy protection. Grr.

Matt Roberds

vi(1) would still need space for its temp file. (Some of my ISO's are 30G;

4 and 8G aren't uncommon -- e.g., CD/DVD ISO's)

I suspect it's easier to write a script to compute the MD5's for each file and push those into the database than it is to wander around the 'net hunting down published MD5's! :>

The approach I've taken "requires" me to do this, regardless. E.g., I store the MD5 of the ISO/ZIP/TAR/etc. archive -- because there is an object called "archive.iso" (or whatever).

However, that archive also acts as a *container* for other objects: MANIFEST, Makefile, README, foo.c, foo.s, etc. Each of these *also* has an entry in the database -- and an MD5 (and a date, size, etc.). So, if I am looking for "MyProject.c", I needn't know that it's *in* an archive (vs. being "exposed" in the filesystem) or *which* archive -- the database tells me what "container" holds it (i.e., the container being a "directory name" if the object is directly visible in the filesystem, the name of a tarball/zip/iso/etc. if it is "embedded" in some other object -- which may, in turn, be embedded in ANOTHER object).

I can then "ask" the repository to produce the object in question (MyProject.c, 2014Projects.ISO, etc.) and it can hide all the details of extracting -- and validating -- the object for me (including checking that the backup copy of the object is intact, as well)

I've been bitten by the opposite: someone copying the "contents" (files) on a medium -- only to discover that there was cruft that wasn't visible as such... rendering the copy useless.

When the lower hardware layers were more easily exposed (i.e., not blocked by OS layers), I saw one scheme where the floppy was "scarred" in a particular place. And, the installer would look for this "retry error" in that spot. If you copied the floppy "successfully", the installer complained because there was no error. If you copied the floppy with "bad data" in that spot, it likewise complained. I.e., the installer was looking for the "read error" and not the data itself!

Years ago (decades?), we would design (proprietary) hardware that intended to *slow* counterfeiters -- not prevent copying. The goal was to saturate the market before they had an opportunity to "steal" any of it. Back then, potting a component and embedding metal filings in the potting compound would often be a deterrent. Or, going to a gate array for some KEY part of the design (later, as that became affordable, moving to full customs). The lesson *I* learned from this was efforts to deter copying are a waste of efforts that could be used to improve the product... and, leave the copiers scurrying to copy the *next* version introduced just as they managed to get a copy of the *previous* version into the market ("Sure, your copy is cheaper than the original! But, I want the

*new* version! When will you have THAT ready, at a similar price?")

That can make for some terribly long file names!

ProgramXYZ.version12.9-Jasen Betts.SN 21849848.Activation WXDDG-GHDYT-DKSHY-HDYET-JEYTS.iso

And, it means any "notes" that you might want to add to that "SerialNumber" (i.e., "ReadMe") file would similarly have to be incorporated into the filename.

E.g., most Windows programs like to install themselves into some portion of the hierarchy set aside (usually arbitrarily) for the software vendor: e.g., \Program Files\Software Corp\Product XYZ. I routinely elide the "vendor portion" of the pathname: \Program Files\Product XYZ (cuz most product names are unique, regardless of vendor of origin)

But, there are some "programs" that get upset when you do this. E.g., they include "../" paths for components within -- expecting "../" to get them to the "vendor specific" directory, under which they might elect to create another subdirectory for "library/", "common files/", "documentation/", etc. If I stick to my practice, this puts these vendor specific subdirectories in places they really shouldn't be: "\Program Files\Documentation" (really? Documentation for *what*??)

So, in these sorts of cases, I leave myself a note in the "ReadMe" to the effect of "allow installer to use default install path". Or, "unconditionally reboots after installation" (really annoying if I happen to be doing something *else* alongside the install!)

On Tue, 12 May 2015 14:00:36 -0700 Don Y wrote in Message id: :

If your software creates a true .ISO image, it should be a binary copy of the source CD. Unless the CD has data stored outside of where data is normally stored, it should be a valid backup.

The ISO only stores the physical portions of the medium that the filesystem claims contain data. So, if you deliberately store some data in a particular spot on the medium and don't tell the filesystem that it is *there*, it won't be preserved.

If you (historically) wanted to make it hard for folks to copy your installation media (because that, after all, is the only physical manifestation of your "product"), one way to do so is to hide "something special" in those seemingly unused areas "knowing" that it won't be copied by "normal tools".

If you have a tool that *does* copy the entire medium (i.e., like using the "raw device") *but* you inject a NEW file into the filesystem (e.g., "SerialNumber"), then that file will inevitably clobber the contents of some of those "unused" portions of the medium -- rendering them inaccessible when the copy is used as fresh install media.

On Thu, 14 May 2015 10:59:50 -0700 Don Y wrote in Message id: :

I disagree. Any program that properly creates an .ISO image could care less about what the disc is claiming is allocated. It's a binary copy. For example, if you have a CD partially filled with data, say 400MB, and create a non-compressed .ISO image, it will be 700MB in size. See:

That may be. Short answer is Don't do That!

One other thing, if your preferred ISO creator does not behave this way, you might want to check out UltraISO

It has a cloneCD output format which will yield a true binary image.

That's not true. I just installed a COTS CD medium in my optical drive, opened UltraISO, "Tools | Make CD/DVD Image... | Standard ISO". The resulting file was 48,434KB (Windows lists the volume as having a "total size" of 47.2MB).

On closer inspection, the ISO is 49,596,416 bytes; the CD claims used space of 49,596,416 bytes.

I'd have to see what tools I have that will allow me to edit CD images without dealing with "files".

But, regardless, assume the operation *had* created a 700MB ISO of which only 400MB are "live data". Now, I *add* a file called "SerialNumber" to that image. Let's imagine the file is 200MB! Will the ISO now be 900MB? Or, will 200MB of "unused space" in the image be reallocated for this file?

I.e., will my 200MB file *displace* any "non-live" data in the ISO?? Will the new ISO no longer *fit* on standard CD media -- because there's 200MB of "extra" data to be accommodated (along with the

300MB of "nonlive" data on the original ISO)?

--------------^^^^^^^^^^^^^^^^^^^^

No. ISO ia an ISO-9660 filesystem image, not a media image, a CD can contain several related "ISOs"and also non ISO-9660 data, This was the case with the game "Worms" where the disk had the game data and also in-game music tracks ad ordinary CD-DA, that could be played autonomously by the cd-rom drive (or by any other CD player). There's a doifferent formsat that can image an entire disk. I forget what it's called, I think there's a "CUE" file and then each track as a separate file.

--
umop apisdn

cds are not like hard diska.

you're wrong. (whatever that claim is supposed to mean)

--
umop apisdn

You can't get there from here.

ISO9660 is not an updatable filesystem.

if you want to add a file you need to either re-master the filesystem with the file added or add a new session to the media containing the new file and referencing the old files from the existing session.

option 1 will get you a new ISO that can be biurned to a CDR option 2 (I think this may require using UDF, and not ISO9660) will get you a seconsd ISO that can be added to media that has the first ISO and has not yet been finalised, or can be written to blank media in addition to the first ISO

--
umop apisdn

Exactly.

Most tools just create a new filesystem with the "extra" files injected. I.e., "unused sectors" don't exist. However, it's unclear how unused *portions* of sectors are treated.

E.g., if you wrote exactly *one* sector's worth of data to a filesystem (a single file) then truncated the file to have a length of *1* byte, what could you say about the remaining

2047 bytes in that sector?

I'd first say that it is immutable: it is not an updatable filesystem.

However as files always start at block boundaries there is slack space between the end of each file and the end of the block. disk authentication secrets could theoretically be stored there.

it's probably also possible to inject unreferenced sectors between files or at the end of the ISO, but such data could equally be hidden in a second track on the disk

--
umop apisdn

Yes, that's what I was thinking. But, I am not sure I have any "iso editing tools" that would let me test that hypothesis (alter some "beyond the end" of a file -- or directory sector -- and then see what happens when you try to reconstruct the original medium from that "image").

I *suspect* that the tools that recreate the medium don't scrub "unused" portions of blocks. So, unless they are scrubbed when the image is *created* (and, never modified by some proprietary tool, thereafter), I would imagine any "cruft" comes along with it.

Or not.