summaryrefslogtreecommitdiffstatshomepage
path: root/src/mame/machine/ns10crypt.c
diff options
context:
space:
mode:
Diffstat (limited to 'src/mame/machine/ns10crypt.c')
-rw-r--r--src/mame/machine/ns10crypt.c26
1 files changed, 13 insertions, 13 deletions
diff --git a/src/mame/machine/ns10crypt.c b/src/mame/machine/ns10crypt.c
index 0650dfceddd..b39dcd70948 100644
--- a/src/mame/machine/ns10crypt.c
+++ b/src/mame/machine/ns10crypt.c
@@ -8,7 +8,7 @@ out knowledge progress.)
The decryption used by type-2 System10 PCBs (MEM-N) acts on 16-bit words and is
designed to operate in a serial way: once the decryption is triggered, every
-word is XORed with a mask calculated over data taken from the previous words
+word is XORed with a mask calculated over data taken from the previous words
(both encrypted and decrypted). Type-1 PCBs seem to use a similar
scheme, probably involving the word address too and a bitswap, but his relation
to what is described here needs further investigation.
@@ -17,14 +17,14 @@ In type-2 PCBs, the encrypted data is always contained in the first ROM of the
game (8E), and it's always stored spanning an integer number of NAND blocks
(the K9F2808U0B is organized in blocks of 16 KiB, each containing 32 pages of
0x200 bytes). Usually the first part of the encrypted data is stored at about the end
-of the ROM, with all the blocks in that area processed in reverse order (first the
+of the ROM, with all the blocks in that area processed in reverse order (first the
one nearest the end, then the second nearest, etc); the second part goes immediately
-after it from a logic perspective, but it's, usually, physically located at the area
+after it from a logic perspective, but it's, usually, physically located at the area
starting at 0x28000 in the ROM. However, in at least a couple of games, there are
out-of-order blocks (details below). Games, after
some bootup code has been executed, will copy the encrypted content from
the NANDs to RAM, moment at which the decryption is triggered. Physical locations
-of the encrypted programs in the first NAND, together with the RAM region where
+of the encrypted programs in the first NAND, together with the RAM region where
they are loaded, are summarized in the following table ( ' indicating processing
in reverse order of the constituting blocks) :
@@ -44,12 +44,12 @@ startrgn [fdc000,1000000)' + [28000,b4000) 80010000
Both knpuzzle & gjspace present a NAND block which is out of order with respect
to the normal layout; besides, that block is physically located immediately before
-the end-of-ROM region, in what maybe is an attempt to hinder the
+the end-of-ROM region, in what maybe is an attempt to hinder the
recognition/reconstruction of the encrypted data.
Most games do a single decryption run, so the process is only initialized once;
however, at least three of them (gamshara, mrdrilrg & panikuru) do reinitialize the
-internal state of the decrypted several times. As of 2015-08-19, only gamshara shows signs
+internal state of the decrypted several times. As of 2015-08-19, only gamshara shows signs
of doing it by writing to the triggering register; how the others two are triggering the
reinitializations is still unclear. gamshara does a reinitialization every 5 NAND blocks
(16 times in total); mrdrilrg does the second one after 0x38000 bytes and then subsequent
@@ -60,10 +60,10 @@ The calculation of the XOR masks seem to operate this way: most bits are
calculated by using linear equations over GF(2) taking as input data the bits from
previously processed words; however, one nonlinear calculation is performed
per word processed, and that calculation typically affect just one bit (the only
-known exception is mrdrilrg, where the same nonlinear terms are
-affecting two of them). Till now, all the formulae seem to depend only on the
+known exception is mrdrilrg, where the same nonlinear terms are
+affecting two of them). Till now, all the formulae seem to depend only on the
previous 3 words, and the first mask after a (re-)initialization is always zero, so
-chances are the mask bits are calculated one word in advance, having access to the
+chances are the mask bits are calculated one word in advance, having access to the
current encrypted and decrypted words plus two further words in each sequence, maybe stored
in 32 bits registers. All the nonlinear terms reverse-engineered till now are of the form
A x B, where A and B are linear formulae; thus, as everything else in the schema involves
@@ -104,7 +104,7 @@ hardware is doing. Two possible simplifications could be:
A) The linear relations are creating lots of identities involving the bits
from the sequence; they could be exploited to simplify the equations (but
only when the implementation be stable, to avoid duplicating work).
-B) It's possible that some of those calculations are being stored and then
+B) It's possible that some of those calculations are being stored and then
used as another input bits for subsequent masks. Determining that (supposed)
bits and factoring out them would simplify the expressions, in case they
really exist.
@@ -123,7 +123,7 @@ const device_type STARTRGN_DECRYPTER = &device_creator<startrgn_decrypter_device
// this could perfectly be part of the per-game logic; by now, only gamshara seems to use it, so we keep it global
const int ns10_decrypter_device::initSbox[16] = {0,12,13,6,2,4,9,8,11,1,7,15,10,5,14,3};
-
+
ns10_decrypter_device::ns10_decrypter_device(device_type type, const ns10_crypto_logic &logic, const machine_config &mconfig, const char *tag, device_t *owner, UINT32 clock)
: device_t(mconfig, type, "Namco System 10 Decrypter", tag, owner, clock, "ns10_crypto", __FILE__)
, _active(false)
@@ -155,7 +155,7 @@ UINT16 ns10_decrypter_device::decrypt(UINT16 cipherword)
_previous_cipherwords ^= cipherword;
_previous_plainwords <<= 16;
_previous_plainwords ^= plainword;
-
+
_mask = 0;
for (int j = 15; j >= 0; --j)
{
@@ -220,7 +220,7 @@ int gf2_reducer::gf2_reduce(UINT64 num)const
// static UINT16 panikuru_nonlinear_calc(UINT64 previous_cipherwords, UINT64 previous_plainwords, const gf2_reducer& reducer)
// {
// return ((reducer.gf2_reduce(0x0000000088300281ull & previous_cipherwords) ^ reducer.gf2_reduce(0x0000000004600281ull & previous_plainwords))
- // & (reducer.gf2_reduce(0x0000a13140090000ull & previous_cipherwords) ^ reducer.gf2_reduce(0x0000806240090000ull & previous_plainwords))) << 2;
+ // & (reducer.gf2_reduce(0x0000a13140090000ull & previous_cipherwords) ^ reducer.gf2_reduce(0x0000806240090000ull & previous_plainwords))) << 2;
// }
static UINT16 chocovdr_nonlinear_calc(UINT64 previous_cipherwords, UINT64 previous_plainwords, const gf2_reducer& reducer)