As I mentioned in the fansubbing thread, I've started to tinker with the 3DO's "encryption" to understand it a little better. (But really, the data isn't encrypted, it's just digitally signed.) I'm going to use this thread as a place to keep some notes as I experiment. Hopefully others will find this useful, or if you do any tinkering yourself, please share your knowledge.

Starting with my post from last night:

Mobius wrote:This thread has gotten me thinking and tinkering again. I looked up the basics of digital signatures, and from what I gather, it works like this:

1. A hash function is run to get a hash of the source data
2. The results of the hash are encrypted
3. The encrypted hash is bundled with the data and delivered
4. The encrypted hash is decrypted at the destination
5. The hash function is run on the delivered data
6. If the calculated hash matches the decrypted hash, the signature is verified

So assuming this is the scheme the 3DO uses, there are a couple of ways to approach running homebrew. We could learn the encryption key so that we can create our own signatures, or we can create data that matches an existing signature. Depending on the complexity of the hashing algorithm, creating data to match an existing signature could be fairly straightforward.

Does anyone have more information about what changes to an ISO break a game and what changes don't? As Gir Draxa and 3DOkid have talked about, modifying data files and keeping them the same size doesn't break the game. I just did a test and verified that modifying the main executable (LaunchMe) and keeping it the same size doesn't break it, either.

Does adding a file break it? How about deleting a file? Or changing a file name? Do all files have to remain the same size, or just certain ones? Can you extract and rebuild the ISO and have it work, or do you have to directly edit the original?

I could do some more experiments to answer these questions, but if anyone knows off the top of their head, it would save me some trouble.

Some tests I've done so far... I've primarily worked off of the Homebrew Pack #1 with Freedo, using either a standard FZ-1 or hacked bios.

1.) Hex edited the ISO to modify the contents of the LaunchMe file. Changed all instances of "Select a program" to "Modify a program". Kept all file lengths the same, just modified the contents.

Status:
FZ-1 bios: Works.
Hacked bios: Works.

2.) Used OperaFS[De]Compiler to decompile then recompile an ISO.

Status:
FZ-1 bios: Doesn't work.
Hacked bios: Works.

Recompiling the ISO with OperaFS[De]Compiler does not recreate the same file structure with all the same avatars as the original. Instead, it creates the ISO with only one copy of each file. This seems to break the digital signature. This MAY work with ISOs that do not use avatars, but I'm not aware of any releases that don't use them, so I don't know how to test this currently.

3.) Hex edited the ISO to modify the contents of the BannerScreen file. I tried replacing it wholesale with the "Bogus Title" banner screen and also simply changing a few bytes. The results were the same both ways.

Status:
FZ-1 bios: Doesn't work.
Hacked bios: Works.

So it seems that the hashing algorithm pays special attention to the BannerScreen but not the LaunchMe. Any change to the BannerScreen breaks the digital signature, but that's not the case with LaunchMe.

As a side note, this is probably why all of Mnemonic's releases have the Game Guru banner screen. He's not actually using the Game Guru code anywhere, he just has a proper digital signature for that file and is reusing it.

4.) Some observations regarding the "signatures" file:

The file is called signatures (plural), and has a varying amount of data depending on the release. So there must be several different signatures per game, each signature corresponding to a different hash. But what information gets hashed?

Maybe this isn't the signature for the BannerScreen, since the BannerScreen is identical across all three releases. I would expect the signature to be the same, as well. Maybe there is another file that's identical for Game Guru and Homebrew Pack and slightly different for Icebreaker II? I'll have to look into stuff like the AppStartup, rom_tags, disc label, etc.

The following string of bytes shows up repeatedly in all of the signature files:

FE5B2229C782BD04E680DE55CC238725

Because of this, the 0 padding at the start of the signature files, and the length of the identical signatures in GG and HBP, I think a single signature is probably 16 bytes, but may be 32.

To Do:

Search signature files of the releases that use the Game Guru banner screen for other strings that are identical. Strings repeated across the files may be the signature for the BannerScreen.

Further explore what changes cause the digital signature to break and what doesn't. What files can I modify without breaking the signature, and which can be changed?

Um ok, I should mention I've been working on a stupid way to force "unencrypted" protos to run. I've only had one that actually worked in anyway, a partial boot and then crash. What I need is the exact build that was used to make one of the OlderGames releases. It most likely won't work but it could give us a good chunk of data towards reaching our objective.

3DO Experience wrote:Um ok, I should mention I've been working on a stupid way to force "unencrypted" protos to run. I've only had one that actually worked in anyway, a partial boot and then crash. What I need is the exact build that was used to make one of the OlderGames releases. It most likely won't work but it could give us a good chunk of data towards reaching our objective.

A really stupid brute force way... I'm too embarrassed to mention here. Knowing now that there is a hash my method will never work. However if I could get an exact build that was used to make one of the OlderGames releases I could produce some data that might help our cause.

The following signature string shows up in all three signature files (Game Guru, Homebrew, Icebreaker II) at line three:

61 61 9C 9A EB 4C 4D 2D 78 1C 28 A9 A8 8D D6 7B

Strings of zero show up in all three files at lines 1 and 15

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

The following strings show up repeatedly across all three files, generally in large blocks towards the end of the signatures, before some 0 and 55 padding:

FE 5B 22 29 C7 82 BD 04 E6 80 DE 55 CC 23 87 25

Some observations

AppStartup is not hashed, but rom_tags is

I believe I've found the proper signature for the Game Guru boot screen.

Questions:

Is the disc label isn't hashed? (it's probably not, but worth a look)

Is the BannerScreen signature always the third line of the signatures file?

To Dos

Try to find the BannerScreen signature in another, official game.

If I can find it, then replace the BannerScreen with the Game Guru BannerScreen and the signature with the suspected Game Guru BannerScreen signature to see if it boots. This could confirm the identified string is actually the Game Guru BootScreen signature.

The Disc label always points to sector 0 (first sector) and contains, among other things, the size of the disc in sectors. That info, however, isn't really used and you don't have to care about it.

rom_tags tells the system which files to load when booting (always on the 2nd sector on a proper Opera disc); those files are all digitally signed. They include BannerScreen, boot_code, os_code, misc_code. Note that the rom_tags file doesn't hold any filenames. It only refers to sectors and how many bytes to read.

The Disc label always points to sector 0 (first sector) and contains, among other things, the size of the disc in sectors. That info, however, isn't really used and you don't have to care about it.

rom_tags tells the system which files to load when booting (always on the 2nd sector on a proper Opera disc); those files are all digitally signed. They include BannerScreen, boot_code, os_code, misc_code. Note that the rom_tags file doesn't hold any filenames. It only refers to sectors and how many bytes to read.

Ahh, interesting, this explains some of the things I've been seeing. Thanks for the info!