GCNcrypt - Gamecube AR Crypto Program
Program and documentation by Parasyte



[ What's New ]

v1.5 (05-03-2005)
* "Fixed" macros in gcncrypt.h - could prevent problems with future code
  revisions.
* Changed the name of "resource.res" to "res.res".
* Now compiling the resource file with Microsoft Visual Studio .NET.
* Added new function GetVal() to replace the GETVAL macro. This change allows
  decrypting "munged" codes that may attempt to foil decryption attempts.
  For example, some of Sappharad's PSO codes which could not be decrypted by
  earlier versions of GCNcrypt.
* Potential bug fixed in DecryptParseList().
  tmp[] array had no guaranteed null terminator.

v1.41 (05-08-2004)
* Fixed a possible string bug in bintoalpha() - The destination string was not
  null-terminated. This could have caused garbage text to be printed on certain
  systems.
* Changed alphatobin() so the destination argument is first in the arg list.
  This is more of a cosmetic change than anything else.

v1.4 (05-07-2004)
* Changed version display (In program title bar) so the dialog will not have
  to be rebuilt for every new version released. See TITLEBAR definition in
  gcncrypt.h

v1.3 (04-07-2004)
* Cleaned sources some more, breaking away from a direct port of the
  original sources from reverse engineering
* Fixed possible memory corruption bug from the error message strings
* Added extra information to encryption/decryption error messages
* Now Allows encrypting one-line codes with auto-verifier disabled.
  There is no way for me to ensure these codes will work properly on AR.
+ Program window now loads centered on screen
+ Added horizontal scrollbars to input and output boxes

v1.2 (03-11-2004)
* Cleaned sources, now builds multiple objects, etc.
+ New auto-verifier features:
    Region signature selection
    Automatic Master Code detection

v1.1 (06-27-2003)
* Rewrote most of this readme. (yay?)
* Fixed crash when closing the program on Windows 98
* Fixed the "Code Decryption Error" bug on certain official codes
* Fixed code encryption, now 100% complete! (Get to hacking, kiddies)
+ Added the "Game ID" option and auto-verification feature for encryption
= Special thanks to Costis, for noticing the LSB in the encrypted codes is
    used as a parity bit, used for further code verification.
  And Sappharad, The Phantom, and ShinAkuma for testing codes.

v1.0 (06-23-2003)
* Initial release



[ To Do ]

Only thing I can think of to say here is maybe adding a method of remembering
the last auto verifier setting. So you advanced hackers don't have to disable
the option each time you load the program.



[ About GCNcrypt ]

It's about time this thing was cracked. Kenobi and I spent the last week or so
working on the GCN AR code encryption. I'd do a few hundred lines of assembly
a day, so it took a while. (The entire set of crypto routines are a total of
~1700 lines of assembly)
This is my take on the decryption routines. Basically, a direct port to C. You
may notice the main decryption function, batchdecrypt(), is rather unfinished.
I haven't spent much time on it after getting the other routines RE'd. The
unfinished stuff is for verifier expansion. The first line of every decrypted
code contains a 'CRC.' If the CRC fails, the AR will complain. Well, so does my
program. However, GCNcrypt only supports the CRC contained in the upper 4 bits
of this 'verifier.' The rest of the verifier is a series of bitstrings which
give the program information about the code. But, since they're unsupported,
the program doesn't receive any of the information!

The encryption scheme used is much more complex than what I've seen used on
other version of AR. It looks similar to DES, the Data Encryption Standard
scheme. After the keys\seeds have been generated, the decryption process uses
those seeds to mutate the address and value on each line by XOR'ing the two,
along with the set of seeds. It's a tight loop of 8 cycles, which does a
decent job obfuscating the address and value. There are also two different bit
scramblers called during encryption. One before the loop, and the other after.
The scramblers move certain bits around using rotations and XORs. The next
nasty trick in this thing is byteswapping the address and value, as well as
swapping the address and value on the way into the encryption loop.

The final mutation is bit packing the 64-bit string into a string of 5-bit
characters. that part is very easily done, even if the functions I used to do
so in the program are written badly. I just wanted to get this finished when I
said it would be. ;)
The remaining bit in the alpha-numeric encrypted code is used as a parity bit,
which is simply a way to keep the 65-bit number even when each individual bit
is added together in a fashion similar to a checksum.


So, it's just a very, very ugly scheme, but it's about 98% reversed. Great
stuff. (The remaining 2% or so deals with the 'expansion data' contained in the
verifiers. Expansion data can be used to regenerate the encryption seeds, which
in turn changes how the codes are encrypted)



[ Some Notes About the Program ]

You can't just pull any random line out of a code and decide you want it
decrypted. Because of the verifier code, you must decrypt an entire 'code
group' in one go. A code group is just a set of codes, either each code on it's
own line, or having data between\around them. When the program finds one line
of text without a code, it considers it the end of a code group, and proceeds
to decrypt\encrypt that code group and verify. If verification fails, a message
box will open, telling you which code group failed verification. The decrypted
result will still be sent to output, so you can see if it is a program- or
user-error.
Codes can only be decrypted if the follow the format, "xxxx-xxxx-xxxxx."

Encrypting codes is an entirely different process. Each code must have a
'verifier' in order to use it on your AR. GCNcrypt can generate a verifier for
you, but the only way to do that is the enable the "auto verifier" option in
the lower left hand corner of the program window. With this enabled, you can
enter a 3-digit hex value which I'm calling the "Game ID." Each game has a
unique ID number which is exactly 11 bits wide. This means the ID number can be
anywhere from 000 - 7FF. If you know the Game ID for the game you've hacked,
type it into the Game ID edit box. Then encrypt each code WITHOUT entering a
verifier. If you do not know the Game ID, simply enable the auto verifier, then
decrypt the "(M)" Enable Code for the game. The program will automatically
enter the Game ID for you.
Encrypting codes with the auto verifier feature DISABLED is recommended only
for advanced users. You will want to know the exact verifier code format before
attempting encryption without the verifier generator. With the feature
disabled, you must enter your own verifier for every code you encrypt. The
verifier MUST follow the format below, and keep in mind that the code will NOT
work on AR if you are not using the correct Game ID.
Codes can only be encrypted if they follow the format, "xxxxxxxx xxxxxxxx."



[ Simple Code Encrypting Example ]

Let's say you wanted to modify one of the Resident Evil codes which sets a
certain item into slot #1. The first thing you want to do is copy the code
into GCNcrypt. Ensure the auto verifer option is ENABLED, and push the
"Decrypt" button.

Input:
 Silver survival knife (Jill)
  1 XAUQ-995V-EMM2K
  2 HHC0-6EH5-TQ6UD

Output:
 Silver survival knife (Jill)
 004E01EF 08000000
 021F11DA 00000001

Game ID:
 027

Now that you've ripped the Game ID, you can modify the code.

The final step is VERY important. You must remember that the first line in
EVERY code decrypted by GCNcrypt is a "verifier." It is NOT part of the actual
code. All it does is tell the AR that the user has entered a VALID and VERIFIED
code, and not just some random junk. :)
With this in mind, make sure you REMOVE the verifier from each code you encrypt
while the auto verifier option is enabled!! Failure to do so will force
GCNcrypt to treat the verifier as an actual piece of the code, and that will
almost always cause problems! So let's do that, now. Enter the following into
the input box:

Silver survival knife (Jill)
021F11DA 00000001

Now you're all set! You can either encrypt the code as it is, or you can change
the value to something new, and see what new item you get in Slot 1.
When you push the Encrypt button, MAKE SURE the auto verifier option is
ENABLED. The program will use the entered Game ID and generate a random
verifier with it. If you change the Game ID, and then re-encrypt the code, you
will notice the AR tells you that your code is for the wrong game.

Though this whole method may seem a little complex, it was the absolute best
way to handle such a PICKY code format. It's really too bad you have to have
the verifier, things would be so much easier without that crap.

As a final note, there is a VERY, VERY SMALL chance that the generated verifier
has the same "Code ID" as another code in your game list. In this case, simply
push Encrypt again and the verifier will use a new random Code ID. Again, the
chance is EXTREMELY small that this will happen, but the chance is still there.



[ Advanced Code Encrypting Example ]

Not everyone will like the auto verifier option, so when you disable it, you're
disabling the option altogether. With it disabled, you must enter your own
verifier for each and every code encrypted. The program will not attempt to
generate one for you, or even correct the verifier you've entered. For this
reason, it is recommended you do not disable the auto verifier unless you know
what you are doing. I will not provide support for this feature!

The verifier is nothing more than a good sized set of bit strings. These bit
strings are values with very specific bit widths.


AR verifier format

(64-bits)
ccccgggggggggggiiiiiiiiiiiiiiiii murresssxxxxxxxxxxxxxxxxxxxxxxxx

c: Code CRC
g: Game ID
i: Code ID
m: Master Code
u: Unknown
r: Region, 00 = USA, 01 = UK, 10 = Japan, 11 = Invalid?
e: Expansion (1 = off)
s: Expansion Size
x: Expansion Data

If bit 'e' is 0, Expansion Data is enabled. When enabled, the expansion data is
read as a bitstring with a width of 's.' The following bit is another expansion
bit 'e.' Repeat reading in expansion size and data until an expansion disabled
is read, or until the end of the code is reached. If the end of the code is
reached, the verifier is invalid. Expansion data is used for extra features,
such as changing the encryption seeds. (Similar to the "DEADFACE" codetype
available on PS2 and GBA)
The expansion data 'x' bits are variable sizes. The size range is from 6 to 32
bits, and CAN roll over into all consecutive lines of the code. Directly
following the expansion data bit string is another expansion 'e' bit.
Expansion bitstrings are read by GCNcrypt when decrypting codes, but the data
is not processed.

Game ID bits must match on every code for a single game. The Game ID must be
unique to each game in the code list.
Code ID bits must be different for each code for a single game.
Master Code bit sets the code as the game's "(M)" Enable Code.


This is the verifier format, use this information when encrypting without the
Game ID option.



[ Disclaimer ]

This program, source code, and documentation are all provided 'as-is' with no
warranty. The program source code is GPL'd, so follow the GPL rules with that
and stuff. If you decide to rip off some work, make some use of it by opening
it to the general public. :)


Cheers to Titanik and Costis, the fathers of GCN homebrew.
LaC, Dovoto, Dextrose, GCDEV.COM, and all the boys who idle in #gcdev, EFnet.
kenobi, IceMario, GSCENTRAL.COM, and all the Gameshark\AR hackers worldwide.


WORK IT HARDER.
