Homebrew ARM9Loader -- Technical Details and Discussion

[shamalox]

Yes use the aureinand and follow the guide for updated sysnand

I'm sorry, but can you link me the guide ? I may be dumb, but I don't find it :/

 

[Ekaitz]

what advantage does this have over emunand besides faster loading

None. (Some would tell that you can load GBA/DSi games and install it only once but if you have linked emunands, you can also install it only once. If you have unlinked nands, you've got to install into both but except that, no advantages)

 

[Classicgamer]

What I see as benefits using a9lh over menuhax(I still use emu and):

100% boot rate: I shut down my system after every use. Not having menuhax crash is epic indeed.

Very fast booting: it's only 1-4 seconds slower than a non-hacked system depending on micro sd size.

Perm CFW: booting into reinand cold is a wonderful feeling.

i won't bother setting up a9lh on sys nand. I'd hate to burn my 9.0 if nin finds a way to block a9lh. Scene Devs found a way to make this happen- I'm sure Nintendo can find a way to block it. Imagine if 11.x required firm0/1 to have a certain value before native firm would load or something along those lines? I'm not a programmer so I don't understand it fully but who knows? If you do, speak up lol

 

[Just Passing By]

None. (Some would tell that you can load GBA/DSi games and install it only once but if you have linked emunands, you can also install it only once. If you have unlinked nands, you've got to install into both but except that, no advantages)

Really?
The post above me listed some but here's some benefits:
- faster boot times
- 100% boot rate
- you can restore a backup to your nand if it bricks replacing a hardmod in many cases
- seemingly unpatchable firmware
- screen init
- this is what you were trying to say: GBA roms only have to be installed once if sysnand is your main

 

[hacksn5s4]

Where's the guide to installing this

 

[Just Passing By]

Where's the guide to installing this

ALRIGHT!!! TAKE 2:
https://gbatemp.net/threads/otp-guide.415140/

Please read it before commenting on how 2.1 is useless. Please.

 

[Supster131]

Where's the guide to installing this

https://plailect.github.io/OTP/
To get your OTP.

https://github.com/delebile/arm9loaderhax
To compile and install A9LH.

 

[Ekaitz]

Really?
The post above me listed some but here's some benefits:
- faster boot times
- 100% boot rate
- you can restore a backup to your nand if it bricks replacing a hardmod in many cases
- seemingly unpatchable firmware
- screen init
- this is what you were trying to say: GBA roms only have to be installed once if sysnand is your main

What are you telling me here?
Emunand does not mean that you don't use A9LH...
I boot Emunand using A9LH and I've got exactly the things you described, +2 additional seconds comparing to booting sysnand.

 

[Just Passing By]

What are you telling me here?
Emunand does not mean that you don't use A9LH...
I boot Emunand using A9LH and I've got exactly the things you described, +2 additional seconds comparing to booting sysnand.

He was asking how a9lh is any different than just emunand on 9.2 without a9lh as he was interested. I was just saying some of the benefits of why a9lh+(emu)NAND is greater than just emunand.

 

[Deleted member 373223]

no, you may need to do make screen_init first (sorry about that forgot that my usual setup already has it compiled for me)

if i run "make screen_init" it telss: "no rule to make target "scren_init". stop."

 

[dark_samus3]

if i run "make screen_init" it telss: "no rule to make target "scren_init". stop."

Did you make sure to spell it right?

 

[Deleted member 373223]

Did you make sure to spell it right?

and watching the Makefile, there isn't an option like that, i already git pulled. (i only have the options: firm0 firm1 dector stage2 arm9bootloader)

--------------------- MERGED ---------------------------

Did you make sure to spell it right?

ok, i managed to build the stage file by making the firm1 file.

 

[dark_samus3]

and watching the Makefile, there isn't an option like that, i already git pulled. (i only have the options: firm0 firm1 dector stage2 arm9bootloader)

Then you forked the wrong thing, it's clearly in the makefile https://github.com/dark-samus/arm9loaderhax/blob/master/Makefile#L1

 

[Deleted member 373223]

Then you forked the wrong thing, it's clearly in the makefile https://github.com/dark-samus/arm9loaderhax/blob/master/Makefile#L1

ok, i had defintely forked thw wrong thing.

 

[dark_samus3]

ok, i had defintely forked thw wrong thing.

Misworded that meant to say synced the wrong fork, but you get the jist haha... Anyways, to get mine

git clone https://github.com/dark-samus/arm9loaderhax

 

[Deleted member 373223]

Misworded that meant to say synced the wrong fork, but you get the jist haha... Anyways, to get mine

git clone https://github.com/dark-samus/arm9loaderhax

yeah, alrady did that, i was building bootctr9... i know... i am dumb sometimes...

 

[m45t3r]

i won't bother setting up a9lh on sys nand. I'd hate to burn my 9.0 if nin finds a way to block a9lh. Scene Devs found a way to make this happen- I'm sure Nintendo can find a way to block it. Imagine if 11.x required firm0/1 to have a certain value before native firm would load or something along those lines? I'm not a programmer so I don't understand it fully but who knows? If you do, speak up lol

I am not an exploit developer, however I did read the description of arm9loaderhax and I would say this is really impossible.

All code running in home menu is running in ARM11 CPU while arm9loaderhax is running, well, in ARM9 CPU (hence the name). ARM11 shouldn't have access of ARM9 data, since the idea of ARM9 is to be a security processor (and if you leak information in your security CPU, you're already screwed up). However, yeah, maybe Nintendo could add a code that sets a byte in memory during ARM9 init in more recent firmwares, that isn't set in older firmwares, or something in those lines.

This would be possible, maybe. However, in the end all that we would need to do is patch this check, like we already patch tons of other things to allow CFW to work.

 

[Selver]

Spoiler: Table of Contents

Table of Contents:

Introduction, BootRom, ARM9Loader Theory
ARM9Loader v1
ARM9Loader v2 (1/3 and 2/3)
ARM9Loader v2 (3/3), Conclusions
OTP dumping progress post / summary
Plailect's OTP Dumping Guide (external link)
Arm9LoaderHax source code (GitHub link)
Summary of differences from prior *hax (1/3)
Summary of differences from prior *hax (2/3)
Summary of differences from prior *hax (3/3)

This post is to summarize the differences between use of Arm9LoaderHax vs. other prior *hax.

Spoiler: Prior Hax Background

Prior hax required a bug in the running code of a system after it was fully running. The bug had to be of sufficient severity that it could be exploited by an attacker. In levels of severity, these exploits would:

1. allow custom code in ARM11 (aka homebrew)
2. allow elevation of privileges from ARM11 user-land to ARM11 kernel
3. allow elevation of privileges from ARM11 kernel to ARM9 (ARM9 user ~= ARM9 kernel)

Spoiler: Getting ARM11 User code (homebrew)

Most ARM11 User entry points are based on a technique known as ROP. TODO: Add post about ROP, stack frames, how functions pass parameters and return to caller, etc.
For example, by itself, the Ocarina of Time / Cubic Ninja hax only allow ARM11 user, such as the loading of homebrew. So long as appropriate ROP chains can be generated for new firmware (and blacklist doesn't exclude the title), having one of these cartridges will allow loading of HomeBrew on any firmware.

Hax relying on system software (theme/menu) also enable ARM11 user (homebrew), but newer firmware can fix the bug, and thus exclude that entry point in future firmware. Moreover, there is now a "blacklist" of titles that require updates prior to being allowed to launch. Thus, cartridges were until recently the only long-term reliable method of loading homebrew.

Spoiler: Getting ARM11 Kernel and ARM9 privileges

Even after homebrew was running, a separate exploitable bug would be needed to perform more than a normal game cartridge would have permissions to do itself. This is why, for a long time, it had been necessary for firmware 9.2... there were bugs in that firmware that allowed moving from ARM11 User to ARM11 Kernel and onwards to ARM9. As you can imagine, these types of bugs have been aggressively fixed in newer firmware versions.

Spoiler: Prior *hax drawbacks

Obtaining ARM11 User privileges (aka homebrew) does not provide direct access to the SD or NAND. This causes critical backup utilities (such as Decrypt9) to fail to work, unless an independent bug is used to obtain greater privileges than provided by only Homebrew (ARM11 User) privileges.

Bugs used to load homebrew, while having a reasonably high success rate, still fail to boot some of the time. For example, a 95% success rate for a given *hax is considered very good.

Bugs used to elevate privileges to ARM9 has a lower success rate than those used to load homebrew. Thus, you need to multiply the likelihood of failure. If the ARM11 Usermode hax has a 90% success rate, and the ARM9 hax has a 75% success rate, this results in only an effective 67% success rate for a given boot to reach ARM9 privileges. (0.90 * 0.75) == 0.675.

ARM9 elevation of privilege bugs are high-priority fixes, and so current firmware / system updates leave no public entry points to get from ARM11 User to ARM9 privileges.

Continued in next post.

 

[Agent Moose]

So I understand how A9LH works, but I am confused on whose version I should use. there seems to be around two or three different versions that we can compile and I have no clue which one is better/worse. Can anyone clearify this and hopefully make it easier for me to choose which one to use?

I would love to be able to BootCTR when I do install A9LH because I love that setup over ctrbootmanager.

EDIT:
Also, are there any advantages/disadvantages for using CakesCFW/AueRaiNand/rxTools (I'm not sure if rxTools even has a9lh capabilities yet)

I'm currently on a O3DS U, running menuhax + rxtools.

 

[Svaethier]

So I understand how A9LH works, but I am confused on whose version I should use. there seems to be around two or three different versions that we can compile and I have no clue which one is better/worse. Can anyone clearify this and hopefully make it easier for me to choose which one to use?

I would love to be able to BootCTR when I do install A9LH because I love that setup over ctrbootmanager.

EDIT:
Also, are there any advantages/disadvantages for using CakesCFW/AueRaiNand/rxTools (I'm not sure if rxTools even has a9lh capabilities yet)

I'm currently on a O3DS U, running menuhax + rxtools.

Dark_Samus's version had the screen initialization I believe.