mxkeychip is responsible for interfacing between the physical keychip, and anything that needs to talk to it (the system services and the game). It does this by means of the mxparallel driver. I have not yet documented the parallel protocol.

Owners wishing to start a system without a legitimate keychip need only replace this binary with a custom binary. micekeychip is an example of one such binary, making use of the official libpcp. (Contact me if you want a build.)

PCP Service

mxkeychip runs a PCP service on port 40106 (data port 40107).


Return the keychip version, as two bytes. 0104 is the current keychip version, representing 1.4. An optional parameter device can be added to retrieve a specific version. The only allowed value for this however is n2, and 0104 should be returned in both cases.


Perform a query-response challenge. The query is the command argument, and the page is passed as a parameter with name page. TODO: Details of how to calculate responses!


Perform a query-response challenge. The query is the command argument, and the page is passed as a parameter with name page. TODO: Details of how to calculate responses!



Get the current keychip status. Reponses should be either init to indicate mxkeychip is still performing setup, available to indicate the keychip is ready to use, or error to indicate the keychip is not present, or unusuable.





Request one of a number of variables from the keychip regarding the authorised game configuration:

formattype Data format. mxsegaboot will only support version 1.
platformid The hardware platform ID. AAL or AAM. ___ is sent if this is unavailable.
gameid The four-character game ID. ____ is sent if this is unavailable.
systemflag A single byte containing a number of system flags. What exactly these bits do is unknown right now, but 64h works fine.
modeltype 02
region Region bitmask. 1 = Japan, 2 = USA, 4 = Export, 8 = China
networkaddr The IP address for this machine
dvdflag 01
seed A seed value that will be used for.. something? Not sure yet. It's 16 bytes.


As with appboot, billing contains a number of values stored on the keychip, however some of these are also writiable.

keyid The keychip ID. For example, A72E-0123456. Read-only.
mainid The hardware ID. For example, AASE-0123456. This value can be written. In this respect, it stores the previous owner of the keychip, allowing systems to identify if they have been presented with a new keychip, and allowing a curious owner (or curious sega) to identify who last used this keychip.
playcount The number of plays that have been performed. This value can be incremented by providing 1.
playlimit The number of plays that are allowed until the game must next check in with a billing server. This value can be written, however a signature (128 bytes) must then be sent over a data transfer to validate that this playlimit update was authorised by a legitimate billing server. As the private keys for the billing service are not currently known, and likely never will be, this renders legitimate keychips useless after playcount runs out!
nearful Get the 'nearfull' value stored from the billing server. This is the number of plays remaining at which a game is expected to pre-emptively check in with a billing server. This value is a 32-bit value, also containing the accounting mode in the upper two bytes of the value. As with playlimit, this value can be written, but requires a valid signature to be sent.
signaturepubkey Retrieve the public key for the billing server signing service.
cacertification Retrieve the authorative certiciate for the billing server. This certificate will be trusted implicitly, regardless of the actual legitimacy of the certificate (including allowing self-signing).