Uberjack: since your original disks are botched, why not use a crack and be done with it?
To write a working copy, you are going to need a working copy - so, it is a chicken-or-the-egg problem (and I've not seen a copy made with dsk-pro floating anywhere). To me it seems kind of pointless to write a fake copy protected disk; but, YMMV 
Uberjack: since your original disks are botched, why not use a crack and be done with it?
To write a working copy, you are going to need a working copy - so, it is a chicken-or-the-egg problem (and I've not seen a copy made with dsk-pro floating anywhere). To me it seems kind of pointless to write a fake copy protected disk; but, YMMV
Hehe, good point, and at the moment, that's what I'm doing. It's a silly distinction, but it just bothers me for some reason
A .dsk file is the actual representation of a standard formatted disk - without any error correction etc., as this data is reduntant in a disk image since the image is already on top of another layer. There is data on a disk besides the standard; and for all sane use (I don't consider copy protection as sane usage 
) that data is not needed and is discarded from disk images. EDIT: this is a simplification in layman terms by another layman; someone might want to elaborate what it is that is (not) stored in a .dsk file, vs an actual floppy
But, I think you do not actually need special hardware, if you have an MSX with a floppy drive, the original (working) disk(s) and some mass media to write the image file with dsk-pro?
Pardon my ignorance, but I was under the impression that DSK would be an accurate representation of the original medium (based on the fact that you can just "dd" the file to floppy).
No, not really... The DSK is just dump of all the disk's stored data, so usually 2 sides * 80 tracks * 9 sectors * 512 bytes = 737280 bytes. If we think of a single track the amount of stored data is therefore 9*512 = 4608 bytes. How ever the real amount of RAW data that can be stored on the track surface is about 6240 bytes +- few depending of situation.
If you think of a concept of "bad sector" you soon realize that computers don't know at all if some data is "good" or "bad" in nature... For computers data is just data and it does not really care that much if you give it a good working disk or a cream cracker. The way to rate if the data on disk is "good" or "bad" is to use CRC checksums that are stored after the "real" data. There is also other things such as headers, footers, sector numbers and gaps stored also there in order to make the computer to find the correct place and allow it to write data without destroying the whole track. This is the data that is written there when you "format" a disk. Usually this meta data is pretty much irrelevant to store since it is usually same on all disks, but the copy protections many times use "weird" meta data to make the disk operations to fail in certain way in certain situations.
I recall that the original Dynamic Publisher also had some kind of copy protection where after I did the copy, I had to open some kind of disk sector editor (no idea anymore what the name of the utility was) to change some values.
This is kind of a very typical copy protection... It just checks if reading certain sector gives read error (=CRC check fail)... It was just implemented in quite a stupid way... You didn't actually even need to change anything... It was enough if you just ejected the disk from drive while DP was decompressing fonts. -> Causes read error -> Copy protection avoided! 
