Re: Mountain Directory revisited

On Thu, 28 Jun 2007 21:37:32 +0000, Robert Bonomi wrote:

In article <1387tr18l6r8f80@xxxxxxxxxxxxxxxxxx>, Frank Tabor
<ftabor@xxxxxxxxx> wrote:
On Thu, 28 Jun 2007 16:34:51 +0000, Robert Bonomi wrote:

In article <n3p583lu655o5n6h7ej6lh5eu306p0el9e@xxxxxxx>, JD
<mycroft.removethis@xxxxxxxxxx> wrote:
On Wed, 27 Jun 2007 14:20:23 -0000, Frank Tabor <ftabor@xxxxxxxxx>
wrote:



Ron

With the numerous copy protection schemes around, it seems like he
should have been able to find one that fit his business model.


I asked him about that but in his opinion, there isn't a copy guard
out there that will do (or so, his disk guru told him). Actually I can
see his point. No sooner does a new copy protection come out than the
hackers crack it.

JD

If the application can read the information, the copy "utility" can
read it.

"bits is bits", to misquote an _old_ remarkt, but with digital data
it is absolutely true.

The only functionally reliable 'copy protection' scheme for software
products is that which utilizes external cryptographic hardware --
what is usually called a 'dongle', and hangs off a parallel (or USB)
port.

Even those can be defeated, but it generally requires more effort --
which must be expended on a copy-by-copy basis -- than the cost of
additional legitimate copies.

Magellan has a pretty good copy protection. You can copy all the CD's
you want, but the program won't run without the disk in the drive. And
it won't recognize a copy. The only hack that will work is to change a
couple of bits it the executable that you install. But that won't
correct the problem with the disk for the next person.

Very _few_ of the 'copy protection breaking' techniques let you 'fix'
the _original_. Almost invariably they let you produce a 'copy' with
the protection removed. You can "copy the copy", but not the original.
changing the function call that _checks_ for the copy-protection to a
simple 'hard-coded' the expected return-value is virtually impossible to
defeat.


I haven't played with Magellan's scheme. If it's mechanism is as
described by some others in this thread, it works on one of about three
methods:
1) hide information in the disk in a place not writable by 'normal'
user-grade software, and read it for validation.
2) force bad sectors at known disk sectors. make sure you get an
error
reading (of the proper type) reading from those sectors.
3) leave a track 'unformatted', and verify you get a read error from
any
attempt to access that track.

All are *trivial* to circumvent with a piece of software that
'intercepts' disk access calls, returns the proper magic incantations
for the 'special' requests, and passes the ones that actually do return
data on to the 'real' disk-access routines.

This kind of code is 'no big deal' for competent 'systems' programmers.
I did one of these in less than an hour once, to allow recovery of data
from a PC hard-disk that had developed a bad spot in the FAT. Disk had
a 'compressed' filesystem living on top of the basic MSDOS filesystem,
so at the true 'DOS' level, there was one file spanning the entire disk.
But the compression driver choked when It couldn't find the complete
sector list (the FAT) that made up the file space it was supposed to
play in. A simple routine that intercepted a BIOS call for 'disk sector
{mumble} and returned a 'hard-coded' copy of the section of the cluster
list that lived in the 'unreadable' sector, and the compression driver
was happy -- whereupon *all* the user data in the compressed filesystem
became accessible. and was quickly copied to a new drive.

For what it's worth, the crack for Magellan was to edit the executable so
that when it put up the warning "couldn't find disk, retry or cancel",
hitting cancel would allow the program to proceed and read the data from
then hard disk. It only requires changing one bit.

--
Frank Tabor
Does he treat your breasts like unripe grapefruit? Who needs him?
-- `J', "The Sensuous Woman"
.

Relevant Pages

  • Re: Hardware musings
    ... scheme that you haven't thought of. ... Well, no one is developing new protection schemes for the Disk II, as far as I know. ... So it doesn't matter what the Disk II is capable of; it only matters which of those capabilities were ever used. ... The only practical way to avoid this hard work is to save everything ...
    (comp.sys.apple2)
  • Re: Hardware musings
    ... By now _ALL_ apple II 5.25 floppy disk that have protection have been produced and most of them have been hacked and their general operation is understood even if not normalized and deprotected fully. ... I was never able to crack Silent service nor normalize Prince of Persia.) ...
    (comp.sys.apple2)
  • Re: Mountain Directory revisited
    ... With the numerous copy protection schemes around, ... but the program won't run without the disk in the drive. ... I haven't played with Magellan's scheme. ... force bad sectors at known disk sectors. ...
    (rec.outdoors.rv-travel)
  • Re: cracked Apple II disks
    ... not all Apple II disks contained games. ... Some nasty ones would read a sector, ... There are a quite a few permutations of the tricks to make a disk ... to get an overview and details on how to remove some of the protection ...
    (comp.emulators.apple2)
  • Re: DVD successors
    ... Every blank disk will have an embedded serial number, ... determined attack or the type of brute-force attack that a distributed ... invalidates the film companies' legitimate codes, ... them to defeat their own copy protection, ...
    (rec.arts.sf.fandom)