by Daniel Marschall, 30 April 2022
(The following information is not backed by any official information, but a result of a research and analysis of the soure code of Photoshop version 1.0.1, which is available at the Computer History Museum)
https://github.com/templeblock/ArchiveGit/blob/f9cf965cb7946faa91b64e95fbcf8ad47f438e8b/Clients/Monaco%20Systems/MonacoPrint/Mac_other/eve_stuff_2%263.cpp Source code of 1993 showing that EvE has something to do with Dongles.
https://github.com/search?q=EVEChallenge&type=code A lot of source-code files mentioning EVE methods.
https://github.com/templeblock/ArchiveGit/blob/f9cf965cb7946faa91b64e95fbcf8ad47f438e8b/Clients/Monaco%20Systems/MonacoPrint/Mac_other/eveitf.h Header file of Eveitf.h
EVE is a Dongle of Rainbow Technologies, Inc. The dongles are often also called Software Keys. On eBay, I have found an "EVE II" which uses a PS/2 connector. But Photoshop 1.0 might have used a predecessor?
It becomes clear that EVE must be a hardware/driver-component since a possible error code is named "errNoEveDriver" and the terminology "Challenge" is typical for Dongles or anything that can respond. So, EVEITF.o communicates with a Rainbow Technologies Dongle, and is not part of the Mac OS system.
5 methods are used by Photoshop:
- The method
EVEStatusprobably checks if the EvE driver is available. - The method
EVEEnablereceives a password which is "zsBanSwzaMGpSmDP" for Photoshop 1.0.1. - The method
EVEReadGPRreturns a key - The method
EVEChallengeis used to verify the key (which is very odd, since that is now how a challenge works?!) - The method
EVEResetprobably removes the password from the "session"
The method VerifyEvE is part of the copy-protection mechanism and will decrypt the XOR-encrypted code-segment "AEncoded". The resource 'EvE ' contains some data for the EVE methods and also serves as a flag that tells VerifyEvE whether the code-segment is encrypted (i.e. the binary is copy-protected) or not.
The "AEncoded" code-segment contains 9 methods in Photoshop:
- MPhotoshop.p:
PROCEDURE AEncodedDummy; - UPhotoshop.inc1.p:
PROCEDURE TToolsView.DrawForeground; - UPhotoshop.inc1.p:
PROCEDURE TToolsView.DrawBackground; - UPhotoshop.inc1.p:
PROCEDURE TToolsView.InvalidateColors; - UPhotoshop.inc1.p:
PROCEDURE TToolsView.MarkMode (mode: INTEGER); - UPhotoshop.inc1.p:
PROCEDURE TToolsView.Draw (area: Rect); OVERRIDE; - UPhotoshop.inc1.p:
PROCEDURE TToolsView.DoHighlightSelection (fromHL, toHL: HLState); OVERRIDE; - UPhotoshop.inc1.p:
FUNCTION TToolsView.PickTool (tool: TTool; click: INTEGER): TCommand; - UPhotoshop.inc1.p:
FUNCTION TToolsView.FindTool (pt: Point): TTool; - UPhotoshop.inc1.p:
FUNCTION TToolsView.DoMouseCommand
Since these methods are very important and frequently used, encrypting the machine-codes of these methods will result in the application being impossible to use.
Encrypting just a few important functions is simple and very performant, since not the whole application needs to be encrypted. Furthermore, the developers can easily avoid calling the encrypted methods before VerifyEvE is finished.
So, the copy-protected copy of Photoshop is most likely produced as follows:
- Compile Photoshop
- After the compiling, encrypt the "AEncode" code-segment
- Append the resource
'EvE 'which is a flag to tell the application that its "AEncode" code-segment has been encrypted.
There are three possibilities:
- A. A single key is used (e.g. the Dongle performs a deterministic hash of the password)
- B. Each floppy has a different key (i.e. every Dongle has a different key which is unlocked by the password).
- C. The copy-protection was implemented, but never used in production.
To verify which case is true, we would need to look at two official floppy disks with Photoshop 1.0 for MacOS.
- If the binary data of the application is equal, then there is either no copy-protection (case "C"), or a single key (case "A").
- If the binary data is not equal, then the floppy is either corrupt, or there are different encryption keys (base "B").
- If methods like DrawForeground can be correctly disassembled, then we know that the copy-protection was never applied (case "C").
Since the Photoshop source code was also used for "Barneyscan" (was it bundled with a scanner?), maybe the Dongle was included in the scanner? So that you could only use Photoshop ("Barneyscan XP") if you had a scanner. The normal version of Photoshop was probably not protected.
After the product key check (method RegisterCopy), the method VerifyEvE will be called.
This method will check if the 'EvE ' resource exists (it is used as flag). If it exists, it will communicate with the EVE dongle to receive a key. There are several checks to check if the key is correct (to make sure that the decryption will succeed), before the key will be used to decrypt the "AEncode" code-segment using the method EncodeSegment.
It appears like the EVE*() methods use the data in the 'EvE ' resource, although the resource handle is not passed to these methods. See https://github.com/cquest/dragster/blob/b5bb1f82b89ca6da38b2c8c49d70a668d88831c2/src/EVELib.a . I do not know what the 'EvE ' resource data is.
The method EncodeSegment uses an XOR-algorithm, therefore the same method will be used for encryption and decryption if the key is equal.
Note that simply removing the 'EvE ' resource from a copy-protected application will not remove the copy-protection. It will result in VerifyEvE being aborted and the application beginning to start, however, the "AEncoded" code-segment is still encrypted, therefore, the CPU will execute garbage and crash the system.
If the "AEncoded" code-segment is not encrypted and the 'EvE ' resource is not existing, then VerifyEvE is not required. This is the case if you compile Photoshop 1.0 from the source code.