cnwietho@immd4.informatik.uni-erlangen.de (Carsten Wiethoff) (04/06/89)
Hi folks,
two weeks ago I posted the question if publishing a C program which could
decode the eexec format would be legal.
From the responses and from my own understanding of copyright laws I decided not
to post such a program, since I don't want to risk to publish something that
looks similar to the code in the ROM of the Laserwriter.
On the other hand I feel that the algorithm that is used to decrypt eexec cannot be
protected ( at least in Germany, what about U.S. ? ) and that publishing this
algorithm does not directly cause any damage to Apple, Adobe, ITC, or anybody
else.
So here is one of several possible descriptions of an algorithm that can decode
eexec format to produce pure postscript ASCII text (under certain conditions
it may produce binary output, so use your favorite hexdump program in this
case).
START ALGORITHM
- use a 16 Bit internal state
- initialize the internal state with 'd971'(hex)
- while there are input bytes:
- read hexadecimal input byte
- the output byte is the input byte exored with the high byte of the internal
state
- the new internal state is the old internal state plus the input byte
- the new internal state is multiplied with 'ce6d'(hex)
- the value '58bf'(hex) is added to the new internal state
Comment: all operations ignore overflow
- if the output byte is one of the first four bytes, ignore it, otherwise
print it.
- end of while
END ALGORITHM
Now some words about the use of this algorithm and what you will probably see
if you use it on various eexec data:
I PUBLISH THIS ALGORITHM FOR INFORMATION ONLY AND I STRONGLY URGE YOU TO FOLLOW
YOUR LOCAL LAWS WHEN USING IT. IN NO CASE I HOLD ANY RESPONSIBILITY FOR ANY USE
OF THIS ALGORITHM.
I know about two classes of eexec data, on which this algorithm could be used:
Class 1: Patches like the uart-patch (I think, this one is distributed by the Adobe
file server). These programs mainly contain binary executable code for use with
the cexec operator. Use your favorite disassembler. Maybe I will publish a
guide to interpret these assembly language programs and to write them yourself.
But in general I think that the use of assembly language should be restricted
to the cases, where you could not use postscript.
Class 2: Fonts of Adobe and possibly other companies
I don't really know about these since I have never seen one, but I am very sure
that you will see the real character outlines only in a crypted and packed
format, just like the internal ROM fonts. Maybe it is useful to learn about the
structure of fonts.
I would be interested if you find this algorithm helpful and I would like to
start a discussion, which data and algorithms contained in the Laserwriter or
other Adobe postscript printers could be published legally.
Specifically these include:
- passwords that allows you access to internal and protected information
- internal structure of jump-tables to allow writing of semi-portable assembly
programs
- internal algorithms for displaying fonts (including special operations on
fonts in small sizes)
- structures of the internal fonts, that would allow other poeple to write
fonts in the same format, automatically taking advantage of the internal
support routines
- documented ROM Listings to help understanding internal operation.
Thanks for listening, happy hacking, STAY CLEAN!
Carsten Wiethoff
c/o Frank Kardel
Friedrich-Alexander Universitaet
Erlangen-Nuernberg
CS Department IMMD IV
Martensstrasse 1
8520 Erlangen
-------------
West Germany
Voice: +49/(0)9131/85-7908
E-mail: cnwietho@immd4.informatik.uni-erlangen.de
Disclaimer: I have never had any contacts to Apple or Adobe nor have I ever
seen anybody who has ever worked for them. I don't want to hurt Adobe or Apple
(or anybody else) but I sure want to know how my printer works and I would sure
like to see more people writing public domain postscript clones and public
domain fonts.