ROM Hack [HELP] SNES VC Decrypting doesn't work

[Narles]

Its ok, I was mostly just concerned with the sound piece. From what I can tell the rom dump is almost identical between the version in ram and the version from the converted rpx, which suggests that the VC is not patching the rom first, but is instead applying the patch some other way.

I'm on the same hunt as you, ootnes2. In the past, I've used vcromclaim to extract purchased SNES VC titles and found that it handled the sound by extracting the PCM audio, converting it to BRR, then injecting it into the appropriate places within the resulting .smc file (more info here: https://github.com/Plombo/vcromclaim/blob/master/snesrestore.py). Unfortunately for me, I can't even find the file in my decrypted 3DS VC title (Earthbound) that contains the PCM audio. I figured it would just be within data.bin but I am not seeing any PCM references in there. If you find anything more on this, please let know.

 

[ootnes2]

I'm on the same hunt as you, ootnes2. In the past, I've used vcromclaim to extract purchased SNES VC titles and found that it handled the sound by extracting the PCM audio, converting it to BRR, then injecting it into the appropriate places within the resulting .smc file (more info here: https://github.com/Plombo/vcromclaim/blob/master/snesrestore.py). Unfortunately for me, I can't even find the file in my decrypted 3DS VC title (Earthbound) that contains the PCM audio. I figured it would just be within data.bin but I am not seeing any PCM references in there. If you find anything more on this, please let know.

It is directly after the rom in the data.bin. If you delete the rom out using hex editor, you can save the rest as the .pcm file and then use snesrestore.py and it'll restore the sound. The only problem is what I said, the md5 checksum is different than the internet dumps which suggests that something isn't right with how it is restored.

 

[Narles]

It is directly after the rom in the data.bin. If you delete the rom out using hex editor, you can save the rest as the .pcm file and then use snesrestore.py and it'll restore the sound. The only problem is what I said, the md5 checksum is different than the internet dumps which suggests that something isn't right with how it is restored.

Thanks! I'm actually having trouble identifying where the ROM begins and ends within the data.bin. I've done a bunch of research and way back in this thread I saw that offset 33 is supposed to tell me the size of the ROM (08 if for 512KB (4Mb) 16 for 1MB etc.). Unfortunately that doesn't seem to apply for Earthbound. I think the ROM starts at offset 60 but can you verify that and also tell me what the ROM ending offset is? I'm not as concerned with getting a checksum-exact version, I just enjoy learning how these repackaged ROMs and emulators work and getting to extract the ROM that the company produced.

 

[Fugelmir]

The rom begins at offset 60 an ends wherever the actual rom does.

 

[Narles]

The rom begins at offset 60 an ends wherever the actual rom does.

Thank you. I realize that. The thing that is confusing to me is that in the case of Earthbound, I believe that the ROM is supposed to be 3,146,240 bytes. However, when I export from Data.bin offset 60+3,146,240 bytes, I end up with a file that contains many references to PCMF scattered throughout. I am wondering if perhaps the 3DS Earthbound ROM's PCM-encoded audio data is scattered throughout the ROM instead of being appended to the ROM like @ootnes2 said.

 

[Fugelmir]

I was under the impression that the games were 1:1 copies of regional releases. Mind you, I only really looked at SMW and F Zero. I guess it's worth taking a closer look.

 

[ootnes2]

Thank you. I realize that. The thing that is confusing to me is that in the case of Earthbound, I believe that the ROM is supposed to be 3,146,240 bytes. However, when I export from Data.bin offset 60+3,146,240 bytes, I end up with a file that contains many references to PCMF scattered throughout. I am wondering if perhaps the 3DS Earthbound ROM's PCM-encoded audio data is scattered throughout the ROM instead of being appended to the ROM like @ootnes2 said.

@Narles The size you gave is for the rom with header, the rom without header (which is what you see in the file) is only 3,145,728 bytes. It should start 12 bytes after the WUP text you can see in a hex editor. As for the references to PCMF, those are pointers to the PCM file that is after the rom. You can look at the roms from Wii wads and see that they also have the PCMF references scattered about.

 

[Narles]

@Narles The size you gave is for the rom with header, the rom without header (which is what you see in the file) is only 3,145,728 bytes. It should start 12 bytes after the WUP text you can see in a hex editor. As for the references to PCMF, those are pointers to the PCM file that is after the rom. You can look at the roms from Wii wads and see that they also have the PCMF references scattered about.

Thank you! I was starting the ROM 60 bytes in but the key was to start 12 bytes after the title ID. You are a genius. I also appreciate the tip on the PCM pointer. I was wondering why it seemed like such a small amount of data. Thanks again for your help.

 

[Deleted User]

Is it possible to inject 6mb (48mbit) roms? I see the option in snes inyector but when I try it I get a black screen.

 

[izy]

Is it possible to inject 6mb (48mbit) roms? I see the option in snes inyector but when I try it I get a black screen.

no because they dont work

 

[Fugelmir]

Does anyone know what this byte handles? It's 6E for earthbound and 11 for most other games. It causes crashes frequently if modified.

 

[Deleted User]

no because they dont work

OK thanks.

Will this be fixed by the upcoming tool by @Team Fail ? I was reading through this thread and that was the impression I got. (If he's still working on it)

 

[3DxMan]

Apparently the ROMs seem to be the same, for both Wii U and 3DS.

The changes however seem to be stored within the RPX/code.bin files for the Wii U and 3DS respectively .
You see, both of those files include patches to the original ROM where they overwrite certain portions of text for the game.
So the ROM is intact, but when you run the game certain patches are applied.

Unless we find a way to dump the full ROM from RAM with the 3DS or Wii U, we won't be able to tell the exact differences between the two versions.

if you can send me the files of a wiiU SA1 chip vc game im pretty sure i can get us a working SA1 3ds cia vc.

im ryanHOe by the way i just go by 3DxMan here. (:

 

[ShadowOne333]

if you can send me the files of a wiiU SA1 chip vc game im pretty sure i can get us a working SA1 3ds cia vc.

im ryanHOe by the way i just go by 3DxMan here. (:

What files exactly? RAM or normal CIA/ddd dump?
Are we talking Wii U or 3DS?

 

[3DxMan]

What files exactly? RAM or normal CIA/ddd dump?
Are we talking Wii U or 3DS?

the decrypted wiiU files i may be able to compare some of the code and modify it and if its the same then
we have our selfs a working sa1 3ds vc

 

[ShadowOne333]

the decrypted wiiU files i may be able to compare some of the code and modify it and if its the same then
we have our selfs a working sa1 3ds vc

By decrypted I assume you mean the /code/, /content/, /meta/ folders, right?
Not a RAM dump?

 

[3DxMan]

By decrypted I assume you mean the /code/, /content/, /meta/ folders, right?
Not a RAM dump?

yes

 

[ShadowOne333]

yes

Oh okay then, give me til tomorrow.
Do you by any chance know what games on the available SNES VC for the Wii U are SA1?

 

[3DxMan]

Oh okay then, give me til tomorrow.
Do you by any chance know what games on the available SNES VC for the Wii U are SA1?

Super Mario RPG also megaman x2 and x3 have the cx4 chip i can look into that as well.

 

[ShadowOne333]

Super Mario RPG also megaman x2 and x3 have the cx4 chip i can look into that as well.

Okay then I'll see what I can do tomorrow.
I suggest you send me a PM in 9 hours to let you know what happened.