Security chip WPC-S and WPC-95
Study of the protection
Operation and replacement
of the security Chip.
WPC-S and WPC-95.
On WPC-S and WPC-95 boards, a protection circuit was installed between the CPU and the switches matrix. The role of this circuit is to verify that the game placed in the EPROM corresponds to the originally expected. Thus, it is not possible to substitute another pinball machine CPU board, unless it is of the same model (with the same model number).
In addition to the verification of the model, the Security Chip also contains the serial number of each pinball. It is this number that is displayed during startup (e.g. 530 123456 12345 on a Dirty Harry).
The Security Chip is a PIC 16C57 microcontroler, referred as U22 on WPC-S (G10 on WPC-95), that dialogue with the CPU through the "columns" bus of the switches matrix.
Commands sent by the CPU are read by U14 (LS374/HC374), the returned data is stored in U24 (LS374/HC374). 10 columns (8 on WPC-95) of the switches matrix are accessed via U23 (HC4514/HC237), in return, rows are read by a pair of LS240, U13a/b (U15a/b on WPC-95).
Failure of the Security Chip is, in principle not easily replaceable, since the code of this programmable component is protected. One cannot so copy it in a blank circuit. In addition, the 16C57 is an obsolete component, now replaced by the 16F57. Note, that it is the only microcontroller with a 28 pins wide at Microchip, there is therefore no alternative to change.
We thus sought to understand the functioning of the Security Chip and made our own version. We have also sought how to replace the PIC 16F57 by a more efficient and more sustainable component.
If you need a replacement part SECURITY PIC (U22 or G10), please report to this project. This achievement based on a PIC 16F57, replace the original PIC, pin to pin.
Everything is based on the encryption of a serial number of the form:
AAA BBBBBB CCCCC DDD
It is this number that is displayed when you start Pinball, its fields are:
Model of Pinball (e.g. 530 for Dirty Harry)
Serial number (it's that is registered on the labels)
Serial number n ° 2 (this number has no known utility)
Unlock key of the matrix's contacts key (ALWAYS at the value of 123, it is used to generate the corresponding unlock code)
This number is not stored as in Security Chip, but in the resulting encoded form. The encoding algorithm particularly complex would hardly fit in a 16C57 (who does that 2K x 12-bit memory).
The game's PROM on the other hand, contains the reverse algorithm which is executed by the CPU 68B09. Only the model of Pinball is checked at startup, the rest is just information.
In the end the algorithm generates an encrypted 16 + 3 bytes sequence:
Bytes 02 and 0A is the encryption key used (by default 0x34 and 0x12).
Bytes 05 and 0D are initialized to zero and then change value regularly (it is a rolling code).
Bytes 10, 11 and 12 is the unlock code of the matrix's contacts (which is only generated from the model no and the fixed key "123").
We studied the opportunity to implement this algorithm in a larger circuit. The interest being able to happen external software to generate the encrypted sequence and to work directly with the number clear. A first prototype based on a PIC 16F684 has been evaluated with success (code written in C language), the algorithm uses only 57% of memory (2 KB x 14-bit).
The system works in master-slave mode, the CPU sending a command to the PIC, which (possibly) responds by returning a data. The recognized commands are the following:
|It is the first command sent by the CPU. It resets the PIC and advances the rolling code. No data is returned by the PIC.
|Decrements an internal counter and returns a value in the CPU. It is read periodically, once on four at the beginning, then again fourteen then. After some time, if the returned value is synchronous with that expected by the CPU, this last shipment send then to PIC a command 20 (see below, unlock of the matrix's contacts).
|The CPU send this command followed by three bytes for unlock the matrix contacts. The PIC returns no data, but check at the end of the sequence, if the three bytes correspond to the unlocking code (bytes 10, 11 and 12). If necessary, the matrix of contacts will remain locked.
|The CPU request reading a column x (16 for the 1 column) of the matrix of contacts. If it is not locked, the PIC returns a byte corresponding to read lines. If the matrix is locked the PIC reference value of zero.
|The CPU requests read from one of the 16 bytes of the encrypted code (70 for byte 0, 7F for the last). The PIC returns corresponding value and advances the rolling code.
The command RESET (00) is sent only once at the start of the pinball.
The READ CODE (7x) commands are sent then, but in random order (so the turning code in bytes 05 and 0D will be different each time).
The COUNTER (0D) command is sent periodically and triggers the sending of the order UNLOCK (20) + 3 bytes, when the counter reaches zero.
The SW MATRIX (1x) commands are sent regularly to scan matrix of contacts, whose number may vary depending on the pinball.
The UNLOCK (20) command sent by the CPU is encoded using the internal number of the pinball model (and not the one returned by the PIC).
In the absence of Security Chip, or if this one returns inconsistent information, pinball will display the message "U22 ERROR" (or "G10 ERROR" on WPC - 95): On the other hand, if the Security Chip works, but does not match the expected Pinball model, the message will then be the following: In this case, the CPU continues to regularly send commands UNLOCK (20) followed by 3 bytes, encoded as indicated previously, from the internal number of the pinball. This feature is interesting, because it could allow to design a universal SECURITY CHIP, able to automatically learn the model of Pinball (his generation from this code is indeed possible).
In the first case, the CPU will also send commands UNLOCK (20) followed by 3 bytes, but much more anarchic way (the counter returns a wrong value). The CPU starts to wait 25 commands COUNTER before sending the first command UNLOCK, then sending systematically this command after each request COUNTER. Three bytes that follow the UNLOCK are not usual ones. They correspond to the model, but encoded number with a "000" key (instead of "123").