147 lines
6.6 KiB
HTML
147 lines
6.6 KiB
HTML
|
{% extends "sega.html" %}
|
||
|
{% block title %}mxkeychip{% endblock %}
|
||
|
{% block body %}
|
||
|
<h1>mxkeychip</h1>
|
||
|
|
||
|
<p>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 <a
|
||
|
href="{{ROOT}}/sega/software/drivers/#mxparallel">mxparallel</a> driver. I have not yet documented the parallel
|
||
|
protocol.</p>
|
||
|
|
||
|
<p>Owners wishing to start a system without a legitimate keychip need only replace this binary with a custom binary. <a
|
||
|
href="https://gitea.tendokyu.moe/Bottersnike/micetools/src/branch/master/src/micetools/micekeychip">micekeychip</a>
|
||
|
is an example of one such binary, making use of the official libpcp. (Contact me if you want a build.)</p>
|
||
|
|
||
|
<h2>PCP Service</h2>
|
||
|
<p>mxkeychip runs a PCP service on port <code>40106</code> (data port <code>40107</code>).</p>
|
||
|
|
||
|
<h3><code>keychip.version</code></h3>
|
||
|
<p>Return the keychip version, as two bytes. <code>0104</code> is the current keychip version, representing
|
||
|
<code>1.4</code>. An optional parameter <code>device</code> can be added to retrieve a specific version. The only
|
||
|
allowed value for this however is <code>n2</code>, and <code>0104</code> should be returned in both cases.
|
||
|
</p>
|
||
|
|
||
|
<h3><code>keychip.ds.compute</code></h3>
|
||
|
<p>Perform a query-response challenge. The query is the command argument, and the page is passed as a parameter with
|
||
|
name <code>page</code>. TODO: Details of how to calculate responses!</p>
|
||
|
|
||
|
<h3><code>keychip.ssd.proof</code></h3>
|
||
|
<p>Perform a query-response challenge. The query is the command argument, and the page is passed as a parameter with
|
||
|
name <code>page</code>. TODO: Details of how to calculate responses!</p>
|
||
|
|
||
|
<h3><code>keychip.ssd.hostproof</code></h3>
|
||
|
<h3><code>keychip.status</code></h3>
|
||
|
<p>Get the current keychip status. Reponses should be either <code>init</code> to indicate mxkeychip is still performing
|
||
|
setup, <code>available</code> to indicate the keychip is ready to use, or <code>error</code> to indicate the keychip
|
||
|
is not present, or unusuable.</p>
|
||
|
|
||
|
<h3><code>keychip.encrypt</code></h3>
|
||
|
<h3><code>keychip.decrypt</code></h3>
|
||
|
<h3><code>keychip.setiv</code></h3>
|
||
|
<h3><code>keychip.appboot.*</code></h3>
|
||
|
<p>Request one of a number of variables from the keychip regarding the authorised game configuration:</p>
|
||
|
|
||
|
<table>
|
||
|
<tr>
|
||
|
<td><code>formattype</code></td>
|
||
|
<td>Data format. <code>mxsegaboot</code> will only support version <code>1</code>.</td>
|
||
|
</tr>
|
||
|
<tr>
|
||
|
<td><code>platformid</code></td>
|
||
|
<td>The hardware platform ID. <code>AAL</code> or <code>AAM</code>. <code>___</code> is sent if this is
|
||
|
unavailable.</td>
|
||
|
</tr>
|
||
|
<tr>
|
||
|
<td><code>gameid</code></td>
|
||
|
<td>The four-character game ID. <code>____</code> is sent if this is unavailable.</td>
|
||
|
</tr>
|
||
|
<tr>
|
||
|
<td><code>systemflag</code></td>
|
||
|
<td>A single byte containing a number of system flags. What exactly these bits do is unknown right now, but
|
||
|
<code>64<sub>h</sub></code> works fine.
|
||
|
</td>
|
||
|
</tr>
|
||
|
<tr>
|
||
|
<td><code>modeltype</code></td>
|
||
|
<td><code>02</code></td>
|
||
|
</tr>
|
||
|
<tr>
|
||
|
<td><code>region</code></td>
|
||
|
<td>Region bitmask. 1 = Japan, 2 = USA, 4 = Export, 8 = China</td>
|
||
|
</tr>
|
||
|
<tr>
|
||
|
<td><code>networkaddr</code></td>
|
||
|
<td>The IP address for this machine</td>
|
||
|
</tr>
|
||
|
<tr>
|
||
|
<td><code>dvdflag</code></td>
|
||
|
<td><code>01</code></td>
|
||
|
</tr>
|
||
|
<tr>
|
||
|
<td><code>seed</code></td>
|
||
|
<td>A seed value that will be used for.. something? Not sure yet. It's 16 bytes.</td>
|
||
|
</tr>
|
||
|
</table>
|
||
|
<h3><code>keychip.billing.*</code></h3>
|
||
|
<p>As with appboot, billing contains a number of values stored on the keychip, however some of these are also writiable.
|
||
|
</p>
|
||
|
|
||
|
<table>
|
||
|
<tr>
|
||
|
<td><code>keyid</code></td>
|
||
|
<td>The keychip ID. For example, A72E-0123456. Read-only.</td>
|
||
|
</tr>
|
||
|
<tr>
|
||
|
<td><code>mainid</code></td>
|
||
|
<td>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.</td>
|
||
|
</tr>
|
||
|
<tr>
|
||
|
<td><code>playcount</code></td>
|
||
|
<td>The number of plays that have been performed. This value can be incremented by providing <code>1</code>.
|
||
|
</td>
|
||
|
</tr>
|
||
|
<tr>
|
||
|
<td><code>playlimit</code></td>
|
||
|
<td>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!</td>
|
||
|
</tr>
|
||
|
<tr>
|
||
|
<td><code>nearful</code></td>
|
||
|
<td>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.</td>
|
||
|
</tr>
|
||
|
<tr>
|
||
|
<td><code>signaturepubkey</code></td>
|
||
|
<td>Retrieve the public key for the billing server signing service.</td>
|
||
|
</tr>
|
||
|
<tr>
|
||
|
<td><code>cacertification</code></td>
|
||
|
<td>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).</td>
|
||
|
</tr>
|
||
|
</table>
|
||
|
<h3><code>keychip.tracedata.restore</code></h3>
|
||
|
<h3><code>keychip.tracedata.put</code></h3>
|
||
|
<h3><code>keychip.tracedata.get</code></h3>
|
||
|
<h3><code>keychip.tracedata.logicalerase</code></h3>
|
||
|
<h3><code>keychip.tracedata.sectorerase</code></h3>
|
||
|
<h3><code>keychip.eeprom</code></h3>
|
||
|
<h3><code>keychip.nvram0</code></h3>
|
||
|
<h3><code>keychip.nvram1</code></h3>
|
||
|
<h3><code>keychip.nvram2</code></h3>
|
||
|
<h3><code>keychip.nvram3</code></h3>
|
||
|
<h3><code>keychip.nvram4</code></h3>
|
||
|
<h3><code>keychip.nvram5</code></h3>
|
||
|
<h3><code>keychip.nvram6</code></h3>
|
||
|
<h3><code>keychip.nvram7</code></h3>
|
||
|
<h3><code>keychip.nvram8</code></h3>
|
||
|
<h3><code>keychip.nvram9</code></h3>
|
||
|
|
||
|
{% endblock %}
|