Hacking [Question] Possible to introduce an arm9 kernel exploit in >= 9.3 using a9lh?

[ksanislo]

The technical side of this is a bit beyond what I'm capable of even trying to attempt, but it seems like it could be possible between A9LH and 3ds_injector (the loader replacement) to introduce an arm9 entry point for CFW firmware versions above 9.2 if they were booted through A9LH.

The point of this would be to allow things that need arm9 access from within an updated CFW, where you have all of the normal system still avaliable, unlike a9lh alone where there's no network access and it can only be started from a reboot.

Can anyone with deeper technical knowledge chime in on this?

 

[Deleted member 373223]

the real wuestion is why should we? to mkae that arm9 exploit avaiable we nned to boot it triugh another arm 9 exploit, cause it CAN'T be permanent

 

[ksanislo]

the real wuestion is why should we? to mkae that arm9 exploit avaiable we nned to boot it triugh another arm 9 exploit, cause it CAN'T be permanent

The point was already explained in the original post, when you boot an updated firmware above 9.2, you lose access to the arm9 as soon as A9LH starts the normal OS up. This means things like Decrypt9 can /only/ be run from A9LH. If we can introduce an intentional arm9 exploit, we could have access to the hardware AES engine from within higher firmware versions than 9.2 instead of either needing to boot a 9.2 emuNAND or write apps that need extended access to run under A9LH itself, where there is no network or any of the higher level API available. If we made our own kernel exploit, patched in while booting the updated OS, it would eliminate this limitation.

 

[Supster131]

Yeah, it technically is.
@Urbanshadow was working on an arm9 thread a while back, idk if he still is though.

As @Filo97 stated, why? We can already boot arm9 apps through A9LH. This is why a lot of people ditched 9.2, because we don't need it anymore.

 

[Deleted member 373223]

, where there is no network

ok, it is useful, but network isn't avaiable with arm9 n general, not only a9lh

 

[ksanislo]

ok, it is useful, but network isn't avaiable with arm9 n general, not only a9lh

Network would be available before switching execution into the arm9 though, and depending on how it was implemented since it would be an intentional exploit, it would probably even be possible to get access to run code or change AES keys on the A9 while still keeping the normal arm11 up and functional.

 

[zoogie]

It would seem only a single u32 would need to be changed to re-introduce firmlaunchhax?
https://www.3dbrew.org/wiki/9.5.0-22#NATIVE_FIRM

 

[yifan_lu]

GBAtemp logic: we can't run arm9 code on an unhacked system without an exploit therefore we can't run arm9 code on a hacked system without an exploit.

 

[PaiiNSteven]

And throwback thursday; what about NTRCardhax? That still being worked on? Its been silent for a little while now.

 

[Plailect]

@Urbanshadow's CakesFW fork of CakesFW can hook traditional arm9 calls and run 9.2 only applications on latest firmware using arm9loaderhax.

 

[Urbanshadow]

Yeah, it technically is.
@Urbanshadow was working on an arm9 thread a while back, idk if he still is though.

As @Filo97 stated, why? We can already boot arm9 apps through A9LH. This is why a lot of people ditched 9.2, because we don't need it anymore.

@Urbanshadow's CakesFW fork of CakesFW can hook traditional arm9 calls and run 9.2 only applications on latest firmware using arm9loaderhax.

Heh I wish. Level of completion of arm9hook is certainly about 100% because you can really execute a bunch of arm9 instructions from a firm that was impossible to do before. Also from some time ago to right now, I added return status functionality, so now we can know from our arm11 cia how the execution went in arm9.

But still the execution is very limited by space (13 KB is the maximum that ITCM will hold for us) and by context, as the whole home menu execution is paused when arm9 goes in and tries to resume afterwards, so any possible lock on data or hardware done by the system and messed up by any arm9 code could potentially crash the system inmediatly or when going back to arm11 execution. So you can't, for now, execute whatever code. It must be somewhat careful with the environment. For curious people, our code is handled like an assembler SVC call.

The TODO, obviously is to increase that space by using FCRAM instead of ITCM (favoring size over speed) and starting the investigation of what could be safely made, and what dont. It should be theoretically possible to do memory dumps from whatever memory region. It should be also possible to break some amount of things without an inminent crash and just simply reboot the system when done.

It is not near to be useful to the regular user right now.