Homebrew ARM9Loader -- Technical Details and Discussion

[Psi-hate]

Well, PowerFirm automatically lets you update sysnand without risk of overwriting sysnand but I don't think you guys need it

 

[JacksonS]

Well, PowerFirm automatically lets you update sysnand without risk of overwriting sysnand but I don't think you guys need it

Is it a tool that protects the FIRM0/FIRM1 partitions?

 

[Psi-hate]

Is it a tool that protects the FIRM0/FIRM1 partitions?

Pretty much. Plus some other stuff I can't remember

 

[FenrirWolf]

Well, PowerFirm automatically lets you update sysnand without risk of overwriting sysnand but I don't think you guys need it

Does PowerFirm come in a ROCKET CAN? If so then I totally need it =P

 

[Supster131]

Well, PowerFirm automatically lets you update sysnand without risk of overwriting sysnand but I don't think you guys need it

I wouldn't mind a patcher that blocks FIRM0/FIRM1 that lives more closely to A9LH, rather than the CFW itself. Just feels "more safer".

 

[AkGBA]

A9LH installer restores NAND.bin before installing, so this could theoretically work.
However, it's unnecessarily dangerous and is only really worth trying on a hardmod.

And I'd like to understand why this method is more dangerous than another. Is a9lh_installer inject funtion less stable than Decrypt9 ? Is there a risk of a9lh_installer being wiped away for memory after nand injection and before a9lh installation ?
Delebile put the nand injection code in his installer. Why ? To what goal ? What are his thoughts about this proposition ?
I know we've talked about it in two other threads (actually one), but this one seems to be the best one for having answers and maybe hardmod-owning testers.

 

[Audioboxer]

I wouldn't mind a patcher that blocks FIRM0/FIRM1 that lives more closely to A9LH, rather than the CFW itself. Just feels "more safer".

I'm certain that's what @Aurora Wright did with the payload for AuReiNand.

 

[Supster131]

I'm certain that's what @Aurora Wright did with the payload for AuReiNand.

Yeah, but the payload only applies to AuReiNAND. So I'm pretty sure that more CFW side than A9LH side.

That's what I think, at least, I could be wrong.

 

[dkabot]

Yeah, but the payload only applies to AuReiNAND. So I'm pretty sure that more CFW side than A9LH side.

That's what I think, at least, I could be wrong.

It is.
If you were to use something else, like a test/custom Cakes build, you won't have that protection.
Of course, it could be added, and since Cakes is modular it's not the best example, but still.

 

[Supster131]

It is.
If you were to use something else, like a test/custom Cakes build, you won't have that protection.
Of course, it could be added, and since Cakes is modular it's not the best example, but still.

Yeah, so once A9LH is more common (hell, I think it probably already is, I'm seeing a lot of people jumping ship), then I think A9LH should have the feature of FIRM0/FIRM1 blocking integrated. Would be easier for the CFW developer and probably the end user as well.

 

[zetaPRIME]

a9lh itself isn't what patches the kernel.

 

[democracy]

Yeah, so once A9LH is more common (hell, I think it probably already is, I'm seeing a lot of people jumping ship), then I think A9LH should have the feature of FIRM0/FIRM1 blocking integrated. Would be easier for the CFW developer and probably the end user as well.

set partition to read only maybe?

 

[thatbooisaspy]

.

 

[4gionz]

i have an idea here, this may be stupid but for all the people who own n3ds and hate the 3d bug that screen init causes this may be a workaround. Now I don't know if the 3d bug could even ever be fixed(and if cfw and gateway are anything to go by I truly don't think it ever will be) would a nand dumper restorer that boots by holding R at boot without any screen init(so you would just get a black screen) but use the led so a solid led means your in "recovery mode".

So for example you boot holding R and when the led goes solid you let go and you should be booted into a black screen but actually your at the nand dumper restorer. now you use decrypt9 ingenious idea to use multiple button presses to choose what to do. So left, right, up, down on the d pad would start the NAND dump "with flashing blue led" and pressing y, a, b, x would start a NAND restore from sd "flashing red led". Simple yet effective

No other options would be included that someone with screen init have but its a barebones solution to keep people safe that despise the 3d bug. Anyways just an idea (and one that was probably already thought of by some of the genius devs in the scene)

Edit:obviously decrypt9 would have to be heavily modified or a completely new nand restoring solution would have to be made so this is unlikely to happen, and that means 2 different payloads would have to be maintained by devs? I don't know honestly just throwing ideas out there for fun

 

[thatbooisaspy]

.

 

[Supster131]

I thought al9h fixed the 3d bug?

It will return once it gets updated with screen init.

 

[FenrirWolf]

Isn't the solution to that having the A9LH payload de-init the screen before passing control along to a CFW? Or could a CFW de-init the screen before attempting to reinitialize it for its own purposes?

 

[daxtsu]

Couldn't it be avoided in payloads by de-initing the screen and GPU before booting FIRM?

Ninja'd.

 

[Supster131]

Couldn't it be avoided in payloads by de-initing the screen and GPU before booting FIRM?

Ninja'd.

I would assume all this screen initing and de-initing would probably add a few seconds to the boot time, although it personally wouldn't affect me.

 

[shadowofdarkness]

I thought al9h fixed the 3d bug?

It didn't fix it, it just didn't trigger it. But screen init triggers it.