GCNcrypt - Gamecube AR Crypto Program Program and documentation by Parasyte [ What's New ] 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.