Am I correct to assume that 1D92C is the memory address and 0x1E1B4 is the physical binary address?Use Edizon or SXOS? This is a Switch cheat code, not a patch tutorial.
If you want to patch the exefs, then use nx2elf.exe and elf2nso.exe
- extract main from exefs
- use nx2elf.exe to convert it to elf
- open it in HxD, goto 0x1E1B4 and replace "29 00 00 94" with "20 00 80 52"
- use elf2nso.exe to convert it back to nso
- place it in the exefs folder on sd card
Am I correct to assume that 1D92C is the memory address and 0x1E1B4 is the physical binary address?
I get that 1E1B4 is the first address you get if you search for 29000094 in hex, but how would you have found that address had we not been lucky enough for it to be the first? 29000094 has multiple entries in the main executable according to hxd. Of course I may be mistaken.
I guess my main question is: how does one find the relative binary address after finding the appropriate memory address in IDA pro?
.text:000000000001D92C 29 00 00 94 BL RsaCheckHash
.text:000000000001D930 E8 03 1F 32 MOV W8, #2
.text:000000000001D934 E8 CB 01 B9 STR W8, [SP,#0x1340+var_1178]
.text:000000000001D938 C0 01 00 36 TBZ W0, #0, loc_1D970
Awesome! Thank you so much. I'm new to this, and find it intriguing. Edit: Which loader are you using?It's the elf header.
A Switch executable almost always starts at 0x0, so memory addresses are identical to the decompressed binary address, the only thing that comes before that is the elf header.
In Ida pro you can see the binary address, example:
Code:.text:000000000001D92C 29 00 00 94 BL RsaCheckHash .text:000000000001D930 E8 03 1F 32 MOV W8, #2 .text:000000000001D934 E8 CB 01 B9 STR W8, [SP,#0x1340+var_1178] .text:000000000001D938 C0 01 00 36 TBZ W0, #0, loc_1D970
if you click on the line with RsaCheckHash, then ida pro will tell you in the lower left corner this: "0001E0B4 | 000000000001D92C: sub_1D590+39C"
0001E0B4 = binary address,
000000000001D92C = memory address,
sub_1D590+39C = function name + offset
Note: i named the function like that and i did use my own nx2elf.exe to convert the files, it generates better info/data than the public one, places the imagebase at 0x0 instead of 0x0000007100000000 and works with 32 bit nso's like Grandia 1, but it works the same way.
If you convert nso to elf, then you don't need a loader.Awesome! Thank you so much. I'm new to this, and find it intriguing. Edit: Which loader are you using?
I get that now. I was loading the nso in ida and the elf in hxd. When I could just load the elf in both. My bad.If you convert nso to elf, then you don't need a loader.
Elf is a generic format with hundreds of supported executable formats, Switch is ARM32 / ARM64, so no special loader is required.
47 02 00 00 // Bytes used to mark this region as valid, formatted footer data. Like <footer> in HTML terms.
BB AA // Preset ID in reverse order.
XX YY // The confusing parts. Ill explain my theory below.
43 61 6E 31 // Bytes used to mark this region as valid, formatted footer data. Like </footer> in HTML terms.
3C 05
4A 06
50 04
55 02
63 01
6A 38
74 XX - 06, 07
76 XX - 28, 46, 78, 82, 91, A5
47 02 00 00 BB AA 74 06 70 02 0A 00 00 00
int64* ptrData = ptrRom + szRom;
do{
byte type = ptrData[pFooter];
if(type & 0x20)
{
byte value = ptrData[pFooter + 1];
pFooter += 2;
}
else
{
int len = ptrData[pFooter + 1] | ptrData[pFooter + 2] << 8 | ptrData[pFooter + 3] << 16
pFooter += 4;
//then read n-bytes of data in the same way as len
}
}while(ptrData + pFooter < ptrFooterSize)
70 02 -> type 0x70, len = 0x1, value: 0x2
50 04 00 00 1E 00 00 00 -> type 0x50, len = 0x4 value: 0x1E
Super Mario World™ 2: Yoshi's Island™:
47 02 00 00 3D 12 = PresetId
65 0C = Super FX
74 06 = maybe DSP type ?
70 01 = ???
55 02 00 00 4A 06 = maybe Clock Speed (1610)
12 00 00 00 = FooterSize
43 61 6E 31 = "Can1"
Your theory is correct, i did analyze the "ReadRom" / "ReadFooter" function a bit more now.
example:
Code:70 02 -> type 0x70, len = 0x1, value: 0x2 50 04 00 00 1E 00 00 00 -> type 0x50, len = 0x4 value: 0x1E Super Mario World™ 2: Yoshi's Island™: 47 02 00 00 3D 12 = PresetId 65 0C = Super FX 74 06 = maybe DSP type ? 70 01 = ??? 55 02 00 00 4A 06 = maybe Clock Speed (1610) 12 00 00 00 = FooterSize 43 61 6E 31 = "Can1"
the emulator only checks these types:
multi byte: 0x41, 0x44, 0x47, 0x50, 0x53, 0x55
2 byte: 0x61, 0x63, 0x65, 0x68, 0x6A, 0x6D, 0x70, 0x72, 0x74, 0x76
It's in my example...That would clear up some that you say are not checked from my notes. Though you don't list 0x1E, and that clearly seems like a 4 byte value. Omission, or just not referenced?
Joe & Mac 2: Lost in the Tropics
47 02 00 00 62 12 = PresetId (0x1262)
74 06
70 02
50 04 00 00 1E 00 00 00 = type: 0x50, len: 0x4, value: 0x1E
12 00 00 00 = FooterSize
43 61 6E 31 = "Can1"
To be honest, i don't know much about the internal workings of snes games.
Also, they did add Header Support, most likely for internal debug roms only, but the code is there,
If a rom starts with:
Offset 0x00 = 0x00
Offset 0x04 = 0x01
Offset 0x24 = 0x57
then it reads the rom info (0x47 / 0x70 / 0x76 / 0x65 and 0x44) directly from a fixed size header struct and the footer is ignored.
It's in my example...
Code:Joe & Mac 2: Lost in the Tropics 47 02 00 00 62 12 = PresetId (0x1262) 74 06 70 02 50 04 00 00 1E 00 00 00 = type: 0x50, len: 0x4, value: 0x1E 12 00 00 00 = FooterSize 43 61 6E 31 = "Can1"
I'm not sure i get it. If "70 02 -> type 0x70, len = 0x1, value: 0x2" is true, than wouldn't "0x50, len: 0x4" mean "value: 0x1E000004"? Unless with this the length isnt assumed, but instead provided by the data itself. So the 2nd-4th bytes are the length.
if((type & 0x20) > 0) then the length is fixed at 1, otherwise the length is written as a 3 byte value.
I did compare all values with the japanese version and there is only 1 difference, Super Family Tennis:
USA: 0x70 = 2, 0x74 = 7
JPN: 0x68 = 3, 0x70 = 4, 0x74 = 6
all other games match, Super Puyo Puyo 2 even matches the PresetId.
0x55 must be the Super FX Clock Speed
0x63 = snes header location memory bank, default = 0x0 (0x7FC0), Mario Kart uses 0x1 (0xFFC0)
The leftover code matches the 96 Byte 3DS Header, but checks for WiiU data.
Not only does the plane not crash but it goes on to land beautifully. I can run any test you want, just tell me what to do (just keep in mind that I'm not an expert by any description of the word). In any case, thanks to you and Falo for trying to make some sense of this all!Actually, I was about to just post and ask if anyone would be interested in testing a theory about 0x63. I was thinking that it might be for DSP revision. The basis for that when Pilotwings does not use that setting is that I suspected that Pilotwings was using DSP-1A to avoid a bug, while Super Mario Kart is using DSP-1B. "63 01" presumably meaning DSP-1B. Are you certain about that pointing to the internal SNES ROM Header?
FYI, the test id ask is simply to see if the demo bugs out and the plane crashes like with this. If the plane does crash, I'd be wrong and its using 1B. If not, it might be 1A, but then id want to know if inserting "63 01" and bumping the footer size value by 0x02 would then show that plane crash bug.
Street Fighter Alpha 2 doesn't use MSU1, no commercial game uses it since it's a "fictional" chip created by byuu. Trials of Mana doesn't use any chip at all, like all of Square's games for SNES.Street Fighter Alpha 2 doesn't work, it's a MSU1 game but I've tried the patched Snes Classic version, still doesn't work. The ripped Rom of Trials of Mana doesn't work either, same reason MSU1.
Check your ROM, both Pocky & Rocky games work great.Pocky & Rocky - not working at all
The only thing most of these games have in common is that they were published by ENIX but most of them are by different developers so they don't really share anything. Because of that it makes sense that none of the Quintet games (Terranigma, ActRaiser, Gaia, Robotrek, Soul Blazer) work correctly but EVO, which is by Almanic, and Ogre Battle, by Quest (and only published by ENIX outside of Japan), do work correctly. I haven't tested the rest but I expect a lot of them do work so don't give up!The biggest problem is with all games made by Enix,
they all start but have buggy or no sound and freeze after some time.
Enix Titles:
ActRaiser
ActRaiser 2
Brain Lord
Dragon Warrior I & II
E.V.O.: Search for Eden
Illusion of Gaia
King Arthur & the Knights of Justice
Ogre Battle: The March of the Black Queen
Paladin's Quest
Robotrek
Soul Blazer
Star Ocean
Terranigma
The 7th Saga
Are they corrupted (as in, graphical glitches) or do they look kinda out of focus? Cause that game uses the SNES hi-res mode for the menus, like Secret of Mana's initial menus or Rudra does for all text. It would be interesting to see if Super Family Tennis can be used to fix those two games. What is its footer?Putting super family tennis from the sfc online to the snes online doesnt work menus are corrupted
Not only does the plane not crash but it goes on to land beautifully. I can run any test you want, just tell me what to do (just keep in mind that I'm not an expert by any description of the word). In any case, thanks to you and Falo for trying to make some sense of this all!
47 02 00 00 BA 10 74 06 63 01 70 01 0C 00 00 00 43 61 6E 31
BTW, since I haven't seen anyone else mention it here, regardless of what enhancement chip a game uses, any footer I've tried works without even changing the Game ID. For example, Kirby Superstar, Super Mario RPG, Mega Man X 2 & X3 all work great with the Mario Kart footer (without any modifications) when they all use different chips than Mario Kart. In the case of the first two games, they use the same chip as Kirby Dreamland 3 which is included in the official games, but the Mega Man games use a different chip, one only they use, actually.
On the other hand, Street Fighter Alpha 2 shows some pretty extreme graphic glitches on what I assume are the logo screens and then the software crashes completely (the only crash I've experienced, even the couple other games that don't load for me only show a black screen with no crash). Haven't even tried Star Ocean but it'll probably be the same.
I couldn't get the official Star Fox 2 ROM from the SNES mini to work here but I only tried with the Yoshi's Island and Stunt Race footers. I've seen some people say the game works for them but are they using this version or the older, more common, incomplete beta that was available for years? As a curiosity, the Trials of Mana ROM extracted from Mana Collection also doesn't work, but that's probably because it was expanded for the translation.
We should probably try to get a list of games that work and don't work from those of us making our own mods to help determine when the game actually doesn't work or when it's just a bad rom or a simple mistake. Maybe once the footer and other stuff is understood a bit better. From my experience, the vast majority of games work. I've even thrown some very bad, sketchy ass roms I had lying around and they worked too. Even the ones that I was sure wouldn't work, like Mega Man X2 & X3 do work (didn't expect the Cx4 since these games are unlikely to be included officially). It's a shame about the Quintet games, but I'm sure they'll get sorted out eventually and it's even probable that both Act Raiser games are released officially eventually since they came out on Virtual Console.
OK! I'll test it in a minute. At the very least, I can use a hex editor XDThanks. I guess that means it's being emulated using DSP-1A. Which is what I'd expect. This is the test of Pilotwings I'd like to see, using this footer.
Code:47 02 00 00 BA 10 74 06 63 01 70 01 0C 00 00 00 43 61 6E 31
You have to manually edit that in using a hex editor. If necessary, I can probably make an ips patch to do this as unlike the SNESC .sfrom format, the Switch .sfrom format lends itself better to using ips patches as normal.
I'll try out a few different footers and with the correct Preset ID, although the few times I've tried using the real ID the games have not loaded at all. Maybe this version of canoe only recognizes the Preset IDs of the games officially released so far?That is is strange. It suggests some more internal code changes to canoe that allow it to more automatically use a a chip as needed. On the SNESC/WiiU/3DS the Preset ID was what canoe used to know a game needed to emulate a chip.
I did see some evidence on the the SNESC of chip emulation slightly working with other games Preset ID.
Thanks for the explanation! It's great to have more people who actually know what they are doing taking a look at this instead of most of us just throwing stuff around in the dark to see what sticks XD Anything you wanna try out, I'm glad to help out.SFA2 graphics are like that because canoe does not properly emulate the SDD1 chip. Instead its coded just to toss aside any calls to the SDD1 chip and continue on. Since its 99% graphics data thats compressed using the SDD1, it just displays static, or garbage data instead.
I wanted to learn a little more about the footer format before I started trying to get SFA2 and my Star Ocean patch working. One step at a time.
I'll test later it with a bunch of different footers and the real Preset ID and see what happens.I'm not sure why Starfox 2 wouldn't work, unless as you say people are using the only prototype ROM, or maybe for that the proper Preset ID (0x1245, or "45 12" in reverse) is required.
Oof, that's a shame but I expected as much. There's a lot of translations I'd like to use with this that expand the roms. That must be why the translations for games like Fire Emblem Tracia 776 and Dragon Quest 3 appear to work at first but just give garbled text after a while. Do you think that this means that even the expanded roms that do load will eventually crap out? I'd rather know now than start playing Famicom Tantei Club 2 only to run into a brick wall later.Yes, canoe doesn't like expanded HiROM games. It doesnt map or check the expanded regions at all. It can boot ExHiROM games, but as soon as it encounters data in those regions it crashes.
That makes total sense and it's exactly what I thought when I saw X2 & X3 working, so I went and tried Alpha 2 that was also released on Virtual Console. But you already know how that went.There's no reason Megaman X2 and X3 shouldn't work. The SNES emulation code is derived from the coded used to make the SNESClassic emulator. That was derived from the WiiU VC SNES emulator code. That was likely derived from the original Wii's VC SNES emulator code. There no reason to remove support for it if you are not using it.
What will be interesting is to find out if some new games work...
OK! I'll test it in a minute. At the very least, I can use a hex editor XD
Edit:
It works! No idea what that means, but it works. Ha ha.
Thanks for the explanation! It's great to have more people who actually know what they are doing taking a look at this instead of most of us just throwing stuff around in the dark to see what sticks XD Anything you wanna try out, I'm glad to help out.
Oof, that's a shame but I expected as much. There's a lot of translations I'd like to use with this that expand the roms. That must be why the translations for games like Fire Emblem Tracia 776 and Dragon Quest 3 appear to work at first but just give garbled text after a while. Do you think that this means that even the expanded roms that do load will eventually crap out? I'd rather know now than start playing Famicom Tantei Club 2 only to run into a brick wall later.
Ah, I was sure that I had mentioned that it was another perfect landing for the plane. Sorry about that. I guess it didn't work after all.While its good that it still works, thats not the purpose of the test. What id want to know is if the plane crashes during the demo like in that gif from the tweet i linked above. That footer is testing if a value is setting emulation to use DSP-1B instead of 1A.
Cool! I'll give the patch a go later.Well. I was making some IPS patches for my tests. Seems that you don't need the pilotwings patch, but you can try this SFA2 patch. It's a complete shot in the dark. I suspect it wont work and will either require adjustment, or a completely different approach.
Understood! I'll check it out and keep my expectations low.Sluffy did make a DQ3 patch to get it working. But such patches are not easy to make.
Crimson Echoes is a great expanded ROM to see for yourself. As I understand that hack boots, but crashes very early. Otherwise, I wouldn't mess much with expanded ROMs right now.
Ah, I was sure that I had mentioned that it was another perfect landing for the plane. Sorry about that. I guess it didn't work after all.
Cool! I'll give the patch a go later.