GCNcrypt - Gamecube AR Crypto Program
GCNcrypt - Gamecube AR Crypto Program
by Parasyte
Program and documentation by Parasyte
What's New
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 "Game ID" 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 "Game ID" 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, simple enable the Game ID, then decrypt the "(M)" Enable Code for the game. The program will automatically enter the Game ID for you.
Encrypting codes with the Game ID 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 to 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 "Game ID" 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:
027Now 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 Game ID 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 with your code! So let's do that, now. Enter the following into the input box:
Silver survival knife (Jill)
021F11DA 00000001Now 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 Game ID 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 Game ID, 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 it recommended you do not disable Game ID 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 munnesssxxxxxxxxxxxxxxxxxxxxxxxx
c: Code CRC
g: Game ID
i: Code ID
m: Master Code
u: Unknown 1
n: Unknown 2
e: Expansion (1 = off)
s: Expansion Size
x: Expansion DataIf 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 bit must match on every code for a single game.
Code ID bit 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.
