Hacking Path changers - why we should be using argc/argv instead

[chaoskagami]

Sort of a suggestion to homebrew devs, and I also want to pick some other developers' brains on standards.

Right now, many A9LH-based CFWs need to know their location via a path changer and a static string within the program itself. Mostly for re-calling the payload via reboot patches.

Using a path changer is messy for multiple reasons, including:

* Not user friendly when using a boot manager.

* Requires a string search which is a heuristic and can't necessarily be relied upon to be found in every program, and not always stored the same in it (char -> wchar_t conversion, arm9loaderhax.bin / arm9loaderhax_si.bin) as well as the possibility of overwriting an unrelated string.

I propose that we switch over to using argc/argv passing, ideally stored after the arm9loaderhax payload somewhere in FCRAM. Then, payloads could simply use argv[0] to get their own path.

I'm aware that I'm asking a lot. I don't expect anyone to do anything really, so this is more a suggestion. I just feel that it would be a much cleaner solution.

It would allow not only argument passing but would obsolete path changers entirely, provide saner ways to enable and disable features...because it would allow calling programs like any other program on Linux, Windows, etc.

I've personally implemented this into my CFW's chainloader. Take that as you will. Trashing r0 and r1 will work the same as before, regardless, because a no-argument main function doesn't check the arguments.

EDIT: For a summary of what is involved in this, see my start.s file here: https://raw.githubusercontent.com/chaoskagami/corbenik/master/source/start.s

It only requires saving r0 and r1 not to be trashed by the MPU setup, and reloading the registers prior to main.

 

[MassExplosion213]

Chaos: How about using a particular "magic value" specific to your payload and scanning the SD for it?

 

[chaoskagami]

Chaos: How about using a particular "magic value" specific to your payload and scanning the SD for it?

That's not a sane method for determining payload paths, because again, possible false positives. Aside from that, my CFW doesn't need a pathchanger.

 

[MassExplosion213]

That's not a sane method for determining payload paths, because again, possible false positives. Aside from that, my CFW doesn't need a pathchanger.

Large enough values are hard to get false positives of.

 

[chaoskagami]

Large enough values are hard to get false positives of.

You're missing the point here. With argc and argv - which are in use on every computer in existence by the way - it is 100% impossible to get false positives. Not to mention patterns again defeat the point here - which is to standardize a way for programs to recieve their own path (and arguments) without the need for overcomplicated and user-unfriendly hacks/tools.

This is just a suggestion, anyways. It would make it easier for boot managers and chainloaders to provide data to programs. It's even used in userland with HBL, for that matter. There's no real reason not to do it.

Like I said - programs can continue to not use the data and trash r0 and r1 on the processor with no ill effects.

 

[Coto]

well ARM ABI itself defines r0-r3 as "scratchpad" registers for a reason, so the compiler would not put extremely valuable code there (such as a callee frame pointer).

Now it's really up to the ABI to save frame context (r0-r3,r10,r11,lr)^ when a SWI exception occurs (namely because r0 is used as the SWI index for the software function index), so shouldn't be a problem

 

[chaoskagami]

well ARM ABI itself defines r0-r3 as "scratchpad" registers for a reason, so the compiler would not put extremely valuable code there (such as a callee frame pointer).

Now it's really up to the ABI to save frame context (r0-r3,r10,r11,lr)^ when a SWI exception occurs (namely because r0 is used as the SWI index for the software function index), so shouldn't be a problem

I mean, this is coding 101 but cdecl convention mandates the first argument be in r0 and the second in r1. It definitely isn't an issue.

It would be a few changes to start.s and the declaration of main, and programs would be able to get their path from any chainloader.