cnwietho@faui44.informatik.uni-erlangen.de (Carsten Wiethoff ) (12/15/88)
Some time ago there were some questions on this group regarding the postscript
eexec operator. There were some answers, too, but in general there does not
seem to be too much information available.
I hacked around a little myself but the facts are not many, nevertheless
there seem to be some theories about how the eexec operator works that
are quite plausible:
- Looking at statistics, I tend to believe that the data given to eexec
are somehow compressed. I didn't try the standard compression algorithms
yet, but unfortunately most compression algorithms make (a little modified)
rather good encryption algorithms.
- Decompressed the data seem to be pure postscript, possibly in some kind of
token form for the internal operators.
- It must be possible to access parts of the postscript machine that are
otherwise inaccessible. For example I have an eexec program that patches
the UART driver of some version of the Laserwriter.
I tend to believe that it is possible to write any data to any memory
location and to install and execute machine code programs.
Possibly in the eexec context some access restrictions do not apply
(unreadable dictionaries could become accessible).
There exists one dictionary in systemdict, which is called "internaldict",
but which is set to noaccess. (I didn't verify it, but possibly this
internaldict is only known in the context of executing the procedure
given to "framedevice", see below)
Dealing with the problem to extract bitmap fonts from a Laserwriter, there
was the "banddevice" operator mentioned, I don't recall by whom.
This is misleading, since the Laserwriter is a "framedevice", not a
banddevice. One parameter to the framedevice operator is a procedure that
is called, if a copypage or showpage is executed. I do not see any possibility
to access the bits in the framebuffer, since all that this procedure usually
does is to care for #copies , set the blink mode and to execute an internal
operator to print out a page.
Somebody also mentioned an article in the September 1988 issue of the
"computer shopper" where something about the eexec format was detailed.
Unfortunately I was not able to get hold of a copy, so I would be very
thankful for a short abstract or preferably a copy of the article. (Send
email first, I don't want to make the photocopy-industry richer than
necessary).
Any opinions or knowledge on the internal features of postscript would be
interesting for me. Thanx for listening...
P.S.: What is cexec, setram, setrom, currentpacking, makevm, psdevice,
setpacking and all the other undocumented operators ???
Carsten Wiethoff
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
#include <disclaimer.h>ddl@husc6.harvard.edu (Dan Lanciani) (12/17/88)
In article <773@faui10.informatik.uni-erlangen.de>, cnwietho@faui44.informatik.uni-erlangen.de (Carsten Wiethoff ) writes: | | Some time ago there were some questions on this group regarding the postscript | eexec operator. There were some answers, too, but in general there does not | seem to be too much information available. | | I hacked around a little myself but the facts are not many, nevertheless | there seem to be some theories about how the eexec operator works that | are quite plausible: | | - Looking at statistics, I tend to believe that the data given to eexec | are somehow compressed. I didn't try the standard compression algorithms | yet, but unfortunately most compression algorithms make (a little modified) | rather good encryption algorithms. Documentation for some of the later Postscript laser printers describes the eexec operator, though not in much detail. It is simply a filter that decodes encrypted Postscript to textual form and feeds it to the interpreter. There is no compression going on. | - It must be possible to access parts of the postscript machine that are | otherwise inaccessible. For example I have an eexec program that patches | the UART driver of some version of the Laserwriter. | I tend to believe that it is possible to write any data to any memory | location and to install and execute machine code programs. | Possibly in the eexec context some access restrictions do not apply | (unreadable dictionaries could become accessible). Yes, eexec files can define operators in machine language. Other powers they do not have directly. | There exists one dictionary in systemdict, which is called "internaldict", | but which is set to noaccess. (I didn't verify it, but possibly this | internaldict is only known in the context of executing the procedure | given to "framedevice", see below) Are you sure the internaldict you are looking at isn't a procedure? | Somebody also mentioned an article in the September 1988 issue of the | "computer shopper" where something about the eexec format was detailed. | Unfortunately I was not able to get hold of a copy, so I would be very | thankful for a short abstract or preferably a copy of the article. (Send | email first, I don't want to make the photocopy-industry richer than | necessary). The article suggested that eexec files could be decoded by clobbering bytes and watching what turned up as syntax errors. This will work to some extent but could get very boring very fast... Also, some of the other comments seemed to indicate that the author didn't have a full understanding of what he was supposedly revealing. Some investigation will probably reveal easier ways to go. | Any opinions or knowledge on the internal features of postscript would be | interesting for me. Thanx for listening... | | P.S.: What is cexec, setram, setrom, currentpacking, makevm, psdevice, | setpacking and all the other undocumented operators ??? Cexec is used by eexec files to run machine code. Setpacking and currentpacking are documented in more recent literature. They control array storage. The others are not familiar to me. Dan Lanciani ddl@harvard.*