Controls frozen on save selection screen: Mario & Luigi Bowser's Inside Story

[OmeletHopper]

The game starts up perfectly fine, then when you get to the save file selection screen all controls lock up. The music still plays and the animations continue, however.

[OmeletHopper]

Also, going into the Mic Test simply freezes on a white screen.

[mariogamer2]

Same

[Santelite]

The nds bootstrap does not support that game, but it can boot it Check the nds bootstrap compatibility list to see what games work

[OmeletHopper]

With the XPA patch, I can move around the save selection screen, but when I start a new save file, It black screens. Also, the mic screen still freezes on white. Perhaps I'm not patching it correctly? I got it from here. @mariogamer2 can you try this?

[mariogamer2]

I might not be able to do so. I travelled not so long ago.

[hubert-skowronek]

@OmeletHopper it's the same for me, game hangs on black screen after selecting save

[hubert-skowronek]

@ahezard Does nds-bootstrap redirect properly reads below 8000h? I've cloned desmume repository, commented out a line of code responsible for proper redirection and Bowser Inside Story stopped working, so those below 8000h reads are security measure here. I am working on AP patch for BIS and now I have very nasty chunk of code to patch (an overlay which prepares instructions by modifying memory in the runtime, doing many strange calculations in order to construct critical branch jump which triggers the freeze in save menu if I hardcode redirection from 1000h to 8000h...) but I am wondering whether it would be much easier to just implement that redirection in nds-bootstrap?

[RocketRobz]

We actually tried that a while back, when we we're trying to fix some issues with HGSS, but seemed to not fix it. I've now added the fix back.

Can you see if this bootstrap build fixes the issue?

[hubert-skowronek]

@Robz8 unfortunately clean rom still doesn't work. The questions I ask myself are:

• does game trigger some additional AP measures besides below 8000h reads?
• is overlay "overlay_0138.bin" loaded properly when the game is ran through nds-bootstrap? (if you fill overlay 138 with zeroes then the game behaves like AP is triggered and the game doesn't even attempt to read below 8000h, this overlay seems to contain both AP logic and game logic handling save menu)
• does nds-bootstrap return the correct value/passes proper value in src variable containing the address? Forgive my skepticism, it is because I don't know how to debug nds-bootstrap, added chunk of code seems to be correct (with exception that desmume implements it as < 8000h, not <=); the game attempts to read something at the address 1000h at first (if I make hardcoded fix then it stops to read anything more below 8000h but mentioned branch still prevents game to work, I hope I will be able to deal with it and then try to run the game on no$gba to check whether getting rid off below 8000h reads really saves the day [on desmume with turned off below 8000h redirection and changed troublesome branch during the runtime, it does)

[RocketRobz]

Some card reads are done from overlays, and those aren't patched, which is why the AP is still triggered.

[hubert-skowronek]

@Robz8 will be ever possible for nds-bootstrap to patch card reads from overlays? In BIS case the 8000h below reads are in fact from this particular overlay. Anyway, why overlays are somehow exceptional for nds-bootstrap? I thought they are just loaded into memory, overriding memory areas as specified in y9.bin - could you tell me more why technically it is some obstacle for nds-bootstrap?

[ahezard]

Card read from overlays? I did not know this kind of stuff existed! A read below 8000h into an overlay is clearly an AP measure. nds-booststrap loads the arm9/arm7 bimnaries and patches the card read functions before the game is runned. Overlays are loaded dynamically while the game is running so this makes it much harder to patch.

[RocketRobz]

The card reads are patched before the game is even booted, so as a result, it doesn't affect the overlays, which are loaded after the game is booted. To work around that issue, we would have to load the overlays into the RAM cache before booting the game, and then do the card read patching in the overlay(s).

[hubert-skowronek]

@ahezard unfortunately it does exist, and it happens to do rather nasty things: overlay is initially loaded but it consists of functions which transforms part of memory into target instructions which prepare read command at 0x40001A8.

@Robz8 Am I correct in that if I even successfully patch BIS (hardcoded redirection of card reads in overlay) then it won't work with nds-bootstrap? I mean - any game with card read in overlay whether it is below 8000h or not won't work with nds-bootstrap, right?

[piratesephiroth]

Couldn't this be achieved "simply" by fixing the cheat engine?

The overlays can just be patched on the fly, whenever they're running. Flashcards use patches like these.

[hubert-skowronek]

@piratesephiroth I would like to hear what guys think about this one, but based on what they've already said it could be in fact not feasible - nds-bootstrap sounds like static patching tool, not dynamic one (it loads arm9, arm7 bins, patches them and let them be executed without further interventions) - am I correct @ahezard , @Robz8 ?

What's more, I suppose flashcards implemented at certain stage cartridge protocol - flashcards didn't modify/patched read commands, they handled reads below 8000h by returning expected value, not by changing binaries' code (which would trigger other security measures like byte checksums - and that thing seems to happen also in BIS).

We would need to have a possibility to replace instructions executed on ARM9 processor dynamically (I suppose that's not feasible with nds-bootstrap?) or somehow capture every attempt to read from card dynamically during the runtime (which is again not the case with nds-bootstrap as far as I understand).

One feasible option is the one @Robz8 already mentioned - find responsible overlay, make changes in it before execution and make arm9 load such patched overlay. If I will overcome my hardships with patching BIS then we would know what instructions should be changed (I've identified currently two overlay files 138 and 139 which need patching, but who knows what awaits later, it's like chamber full of sequential traps) and we could patch it using nds-bootstrap. Very hacky, I'm wondering whether there is a better solution for this.

Guys - if there is any hope that my successful patch of BIS would open the door for the game running on nds-bootstrap then please tell me - if not, I'm going to give up if it's not going to work with nds-bootstrap anyway.

[piratesephiroth]

@hubert-skowronek , I believe it's a combination of both (I can't really know because they're not open source) but take YSMenu as an example. It contains a file called extinfo.dat that fixes compatibility with games. It is a basically a database of AR Codes, only they're stored as binary blobs instead of multiple 32 bit values.

It uses this same AR code to bypass BiS's (USA) AP. E23FC400 00000070 E28FE004 E51FF004 02004970 E92D003C E5950004 E28F203C E8920030 E59F2040 E0801002 E891000C E1520004 01530005 1A000004 E59F3024 E5813000 E59F3024 E59F1024 E7803001 E8BD003C E9950003 E51FF004 0203E4FC EA00000C E28D0020 EA000036 00000558 E3A00001 00000638 D0000000 00000000 0203E4F4 E51FF004 0203E4F8 023FC400

That's why I believe the cheat engine could be very efficient on most of these AP issues. Also it's partially working already, it only has to be fixed.

I think that instead of a very precise solution that works with all games, nds-bootstrap could have a generic feature that would be aided by these codes.

[hubert-skowronek]

@Robz8 @ahezard @piratesephiroth Minor update - today I was able to patch M&L: BIS successfully! However "successfully" means that patched rom works on forked desmume with below 8000h reads disabled. It still doesn't work for some reason on no$gba, I wonder why. I've tried my patched rom with nds-bootstrap and it behaves just the same like the patch provided in Robz8's folder with AP patches. The save menu becomes playable, but after choosing save slot the game hangs on black screens, even though it proceeds further on my forked desmume.

The patches are as follow: overlay 138: 0x6F4 : 7870010A -> 7870011A

overlay 139: 0x054 : 10FF2F01 -> 0000A0E1

I've applied those patches on decompressed overlays, modified y9.bin so they could be left decompressed and packed the rom. Overlay 138 attempts to do card reads on the very beginning of booting the game, then again during loading save menu - despite this it still works with nds-bootstrap, isn't that black screen by any chance maybe some other bug?

xdelta patch can be found here: https://gbatemp.net/threads/ap-patch-preservation.477536/

4171 - Mario & Luigi - Bowser's Inside Story (US)(M3)(XenoPhobia) (SHA1 C3EB5EA6F90069294F4BAA9148764102EFF059EA)

@Robz8 , @ahezard would you be able to debug the game then and check what causes the game to hang on black screens?

[Stack3r]

Does the game load with ysmenu?

[hubert-skowronek]

@Stack3r No idea, do you ask whether my patched rom works with ysmenu using some flashcard? I don't have any - could you check it using the patch I've provided?

[ahezard]

I am not sure the cheat engine will be able to fix this. And even if it works it will not be a convenient way to do it. You would have to implements the card read patch which as an ar code, but card read patch exact code are dependent of the nds-boostrap version you are using. Some jump offset at least would slightly change so it would be a mess to maintain.

[Stack3r]

I feel like if ysmenu could be implemented properly into bootstrap a lot of the anti piracy issues would be fixed due to these games working with that file

[piratesephiroth]

well, the frozen controls can be easily bypassed with a cheat but the game gets stuck in a black screen afterwards, heh

[hubert-skowronek]

@piratesephiroth I think that's because of unpatched overlays, as @Robz8 suggested :( I am wondering whether not working Golden Sun DD, Lufia and M&L BiS have that in common - unpatched card reads in overlays/another things needed to be patched, but omitted being present in overlays. @Robz8 , @ahezard, @damianoamatruda are there any plans to implement patching for overlays?

[RocketRobz]

Would be nice, but we don't want to get into any trouble with Nintendo. :P

[piratesephiroth]

uh? do the overlay patches contain copyrighted code?

[hubert-skowronek]

@Robz8 how it differs from patching, let's say, arm9.bin?

[RocketRobz]

@piratesephiroth Nope. The issue is if nds-bootstrap itself does the patching to the ROMs on the fly to remove AP measures.

[piratesephiroth]

what? So it's all because it's a Nintendo game?

[hubert-skowronek]

@Robz8 couldn't we solve it that way that the user has to AP patch the game on his/her own and nds-bootstrap patches all those things (mainly card reads) as it does with arm9.bin?

[piratesephiroth]

I was checking WoodR4's source and saw the patch. It's not really much different from other games however if I tried to apply it on nds-bootstrap, the game gets stuck in a white screen. So I can only guess nds-bootstrap handles the rom in a different manner. (maybe the area where the code is written s being overwritten and the initialzation stops because it jumps to empty/invalid code?) (I can read code but have no idea of how nds roms work)

[Valeri0p]

IIRC @shutterbug2000 made some partial patches some time ago, maybe he can contribute to the discussion.

@ piratesephiroth Nope. The issue is if nds-bootstrap itself does the patching to the ROMs on the fly to remove AP measures.

That's why you removed that commit with the B&W AP cheat?

[hubert-skowronek]

I've done small investigation on overlays (searched for end signatures of card reads, dma reads, card cached reads) and found none - the conclusion is that black screen is some other bug than non patched card reads in overlays or maybe those card reads in overlays are prepared dynamically (just like AP code)

[piratesephiroth]

The thing is that if you look in Wood R4's code, it's really nothing special. It just decompresses the arm9 binary and applies a patch. There's also a similar AP patch in the cheat databases.

So I can only conclude that nds-bootstrap either lacks some generic AP bypass feature that flashcards have or it just does something different that triggers a new AP check.

[hubert-skowronek]

@piratesephiroth yeah, I agree with you, that's why I say that there might be some logic in overlays (not directly related to AP) that needs the same patching (not AP, but maybe card reads, dma etc) as arm9.bin, because arm9 overlays are in fact extensions/modifications of primary arm9.bin, but again I am not so sure

[hubert-skowronek]

@Robz8 I've forked nds-bootstrap and tried to experiment with the redirection of below 8000h reads - it appears that during loading M&L BiS the condition src <= 8000 isn't evaluated to true even once (compiled quick version of nds-bootstrap which should fall into endless loop if that condition evaluated to true, but it never happens). Could you please tell me how can I run nds-bootstrap via no$gba in order to debug it in more detail?

[piratesephiroth]

Well I can run nds-bootstrap on no$gba if I install Unlaunch however the games don't actually start,. They always stop after the loading screen

[hubert-skowronek]

@piratesephiroth it's too bad then, because I wanted to check what values are assigned to "src" variable in arm9/source/cardengine.c - the work on that project seems to be really hard when it comes to debugging!

[piratesephiroth]

yeah, the only way I found to verify things was by enabling logging in the ini and using dbg_printf and dbg_hexa to print stuff to the log file, then checking it out later

[piratesephiroth]

I suppose there is a proper way to debug this but I guess it's a secret to everyone

[hubert-skowronek]

@piratesephiroth if I am correct it isn't the case for cardengine.c in which debugging seems to be done via nocashmessages? I tried to meddle with that code so I could use dbg_printf but I was told by compiler that there is problem with .elf file and code wouldn't fit in VRAM

[piratesephiroth]

what? I just tried and it got compiled fine without any errors.

[hubert-skowronek]

@piratesephiroth and does it write to the file without problems? Could you please paste the code changes in the comment?

[piratesephiroth]

I'll test it, hang on

[piratesephiroth]

ah yeah it seems we can't write to the file once the game is running

[piratesephiroth]

guess we'll have to wait for the solution to debug this on no$gba

[RocketRobz]

Now works as of v0.13.0. AP-patch is still needed.

[TKDarkWolf]

@RocketRobz I know this is post is a little old, but if you see this, can you send a link to a tool so I can AP-patch BIS. I tried looking over google, but the threads that have answers don't have working links to the downloads.

Also wondering if you have and idea for a fix on Golden Sun Dark Dawn, because I was looking through the other nds bootstrap threads and I didn't see an answer (black screen on startup).

[JonArcherII]

Use the kinder_bueno patch from here, and use an xdelta patcher, like this one.

[TKDarkWolf]

Thank you for the help, I was able to get Kirby Mass Attack and BIS AP patched, but I couldn't find a patch for Golden Sun in the odrive list, so if you know where to find one, I would appreciate it very much.