In a life long ago on a planet far away it just so happens that I
reversed this protection scheme. I actually built a program that would
generate the required authorization, and work on any of the products
from that company. I don't have those files easily accessible so I
will describe what you are up against.
If you make yourself familiar with macsbug, 68xxx opcodes, and find a
tool such as resourcerer for disassembly you will be on your way to
fixing this, along with some information on how it works.
The basic scheme ->
the authorization process writes a file that contains it's position in
the HFS file system encoded in the file.
On program startup, the program looks for this file, performs some
manipulation on the key and then decides to run or not.
The file was marked invisible on the old HFS.
So if you managed to find the file and copy it it would be of no use,
as it would be copied to a new position on the HD and therefore not
match the key used in authorization.
In regards to the applications' check of the file -
the file is opened, read, and then some code is executed.
That code is very interesting as it includes a few traps for the
novice which I will now describe.
1) The code is built in blocks that modify code in the next block to be run.
If you were to single step the code in the debugger you would not run
it correctly as the correct version is still in the cache - they
disable a cache flushing mechanism - so it is important to identify
the protection code, and then "manually" single step through it.
When I did this I actually built an emulator for the 68K instruction
set, but it is not required.
2) the code protection is built in such a way as to sample the system
clock occasionally. Be carefull with this, as what they intend to do
here is to compare the system clock with the previous and discover
that it is the same value. If it is diffferent, then they jump to a
routine to reboot the system - and therefore you lose your work.
3) Some later versions also attempted to patch out the debugger
vectors in the atrap table, and occasionally check that they remain
patched out.
4) there's about 4-5 such checks and then in the very end they do some
XOR tricks with the value stored in the disk file, and compare it to a
known. Which if it matches, they let you run.
5) they also checksum the protection part of the code, in an attempt
to prevent you from modifying it.
they use a similiar scheme in their authorization mechanism but
instead check for this file on a floppy, and then allow you some
number of installs.
good luck and I hope you are good in macsbug!
That's probably the best I can do for you as I don't have my old files
from back then.
I also suspect that you will have some problems after you get it
running in terms of talking to the midi manager so it may not be
worthwhile to do this, and a cheaper approach would be to buy an old
mac :-) |
