Homebrew ARM9Loader -- Technical Details and Discussion

[RednaxelaNnamtra]

Here is a new BootCTR9 dev release: Pre 1.0 RC2
In this version I fixed 3 small Bugs:
autosoftboot will now work properly again
START+SELECT will now stop the animations again
It won't wait for a key release anymore, if no bootpassword is used

For more informations about the usage check out the BootCTR9 Wiki

 

[Selver]

I've updated some of the technical content, links, etc.
Let me know if there's anything that needs changed.

 

[hippy dave]

Hey kids, I've been out of the loop for a while. Did we ever get a thread to allow arm9 kernel access in updated firmwares? Cheers.

 

[Selver]

Did we ever get a thread to allow arm9 kernel access in updated firmwares? Cheers.

No public method is known to obtain Arm9 kernel (via software means). Downgrading to a vulnerable firmware version is what Plialect's guide appears to recommend.

See https://www.3dbrew.org/wiki/3DS_System_Flaws:

Firmware version 11.0.0-33 has no public kernel exploits, and prevents downgrading via software. There are two methods to downgrade from FW 11.0.0-33, described in Plialect's OTP guide.

Plialect's OTP guide is linked in the TOC in various posts here, including the first post.

 

[hippy dave]

Yeah thanks but that's not quite what I meant. There was discussion long ago of starting an arm9 thread from a9lh boot, that would run in the background so you could hook it to gain arm9 access from any firmware version.

 

[Selver]

Yeah thanks but that's not quite what I meant. There was discussion long ago of starting an arm9 thread from a9lh boot, that would run in the background so you could hook it to gain arm9 access from any firmware version.

Ah, OK. I've not heard of that taking root. However, if you're researching this yourself, you may want to look at Corbenik CFW as a starting point, as it has a ... unique ... code patching architecture that may be of interest to you:

https://gbatemp.net/threads/corbenik-another-cfw-for-advanced-users-with-bytecode-patches.429612/

 

[Selver]

A stable thread, but one without recent posts, is dead. Corbenik for the developer world!

 

[Selver]

Well, I went through the first thirty or so pages of posts, and marked some posts as "featured".
It may be time to lock this thread.

 

[einhuman197]

Lock isn't good, arm9loaderhax is still a thing. It's not dead.

 

[Urbanshadow]

Yeah thanks but that's not quite what I meant. There was discussion long ago of starting an arm9 thread from a9lh boot, that would run in the background so you could hook it to gain arm9 access from any firmware version.

I worked on this last year. I got good progress, but a9lh came around and everything turned upside down. I'm planning to restart the developing on this, but we are unsure what the compatibility will be. It's quite different from brahma based arm9 payloads.

The way I did it admited very simple a9lh payloads to be ran from arm11 in 10.6-10.7 (I don't quite remember the version). With some refinement and RE it could be a thing, but it would be only supported through a cfw patch. (Last week I found very promising stuff to beef up this thingie)

Back then I did my thing on cakesfw. It went fairly well. I don't know how useful will be, thought.

 

[einhuman197]

This sounds cool. Arm9 on every firmware yeah great.

 

[Urbanshadow]

This sounds cool. Arm9 on every firmware yeah great.

There's is a small line between what is possible in arm9 and what is possible in arm9 with arm11kernel running behind. Afaik, no crypto. And no crypto = no decryption = no D9 from menu. Perhaps NAND dumps will work, but nothing else (D9 related).

 

[Selver]

There's is a small line between what is possible in arm9 and what is possible in arm9 with arm11kernel running behind. Afaik, no crypto. And no crypto = no decryption = no D9 from menu. Perhaps NAND dumps will work, but nothing else (D9 related).

Hi UrbanShadow,

Perhaps you can help clarify what is / isn't possible with the Arm9 thread. I know that the Corbenik CFW (@chaoskagami) was considering how to get an Arm9 thread hooked also.

Would an Arm9 thread be able to (more useful than Arm11 for):

1. non-destructive memory dumps of running processes?
2. real-time on-3DS debugger / memory editor?
3. Gameshark-style cheats?
4. running some code for each screen refresh, regardless of what the "current" app is?

(Does the hardware have support for real-time write breakpoints? Yes, I'm admitting my ignorance here...)

 

[Urbanshadow]

Hi UrbanShadow,

Perhaps you can help clarify what is / isn't possible with the Arm9 thread. I know that the Corbenik CFW (@chaoskagami) was considering how to get an Arm9 thread hooked also.

Would an Arm9 thread be able to (more useful than Arm11 for):

1. non-destructive memory dumps of running processes?
2. real-time on-3DS debugger / memory editor?
3. Gameshark-style cheats?
4. running some code for each screen refresh, regardless of what the "current" app is?

(Does the hardware have support for real-time write breakpoints? Yes, I'm admitting my ignorance here...)

Ok... let's take a step back. Here is a bit of knowledge of arm9 (this chunk of text is on the house):

Spoiler: ARM9 things

We know both o3ds and n3ds share an internal processor aside from the main core. We know it's called arm9, we know it was in the original DS, we know it is used for retrocompatibility and as security processor in 3ds mode.

That "core", more specifically is an ARM946 SoC. A single hardware threaded arm core running at 134MHz with both data and instruction TCM integrated memories as we can see here: ARM946 specifications

So, while creating a new thread for arm9 on boot might be possible, once the system is up and running the arm9 core is being actively monopolized by the security engine of the system which by the way was not meant to be parallelized. That teach us two things:
1. To ensure system stability (hehe) we have to "halt" all the system at once and be able to restore everything afterwards.
2. There's an arm9 thread already running!

Wellp here's where we got lucky. There's a thing called PXI that handles service calls (svccalls). Service calls can in fact interrupt the whole arm11 system, run in arm9 core and can safely be resumed aftewards. Thing is, the svccalls are well defined and not editable from arm11. And if you get hold of arm9 for editing those what's the point of interrupting the system? That's seems hard to hack. Turns out it's not.

What happens if we call an invalid svccall from arm11?
What if we could write a new svccall?
What if we could put a code as a service call with the sole purpose of running another code as parameter? That effectively would be a runtime reprogramable svccall.
So we can pass arm9 code to pxi, pxi runs it for us and we return to arm11 like nothing happens? Yup. Mostly.
Even from a payload on sdcard? Yup.
And system/security system is sleeping while we do that? Well... not exactly. arm11 is waiting for our return. Security system holds locks on everything important. Those locks are up. Those locks can be removed/edited at this control level, sure, but no one knows what can happen with the system. Most probably kernel panic/unstability/brickland?.
Where is the catch? We need to patch the firm for this. We need arm9 control at least once in the system (like a9lh, in boot). This will never work on a official fw. This is only possible for cfws.
This is not my invention. Credits to b1l1s, Normatt and guys at cakey.

Answering your questions:
1. Arm9 has access to all physical memory. No restrictions. I write to the framebuffer directly with it. Reading the memory should be piece of cake and fairly safe. Writing to any of it is also possible but far more dangerous.
2. If for real time you mean run time yeah. No problem. There's still some delay for the slowy 134Mhz arm9 core if you do long things. setting addresses should be instant.
3 & 4: Sadly, you can't get hold of an app's cycles. Once an app is started, the last one is exited. I have yet to see how it might be possible to inject some code into a foreign app cycles in this system. (perhaps editing the home menu to trick it into doing this sort of things? it's the only app "always" up (Extended memory mode makes home menu sleep)!

Exception handlers are good enough? Luma has a dev branch already doing this!

 

[Mrrraou]

Hi UrbanShadow,

Perhaps you can help clarify what is / isn't possible with the Arm9 thread. I know that the Corbenik CFW (@chaoskagami) was considering how to get an Arm9 thread hooked also.

Would an Arm9 thread be able to (more useful than Arm11 for):

1. non-destructive memory dumps of running processes?
2. real-time on-3DS debugger / memory editor?
3. Gameshark-style cheats?
4. running some code for each screen refresh, regardless of what the "current" app is?

(Does the hardware have support for real-time write breakpoints? Yes, I'm admitting my ignorance here...)

All of this can be done on ARM11 already. No need to hook an ARM9 thread for that.

 

[Urbanshadow]

All of this can be done on ARM11 already. No need to hook an ARM9 thread for that.

This is why I was questioning the usefulness of the method given the effort required, and why was left behind in the first place.

It may be more value hidden in getting grip of the process9 of the system, or perhaps not.

Keep in mind this effort is a RE to better understand the provided software. The use case is to rewrite a svccall to perform tons of little, powerful tasks like a real svccall. Escalating permissions just when absolutely needed and conviving with an otherwise fragile arm11 sandbox.

 

[Mrrraou]

This is why I was questioning the usefulness of the method given the effort required, and why was left behind in the first place.

It may be more value hidden in getting grip of the process9 of the system, or perhaps not.

Keep in mind this effort is a RE to better understand the provided software. The use case is to rewrite a svccall to perform tons of little, powerful tasks like a real svccall. Escalating permissions just when absolutely needed and conviving with an otherwise fragile arm11 sandbox.

Why would you want to rewrite svc calls ? And the only reason I would touch Process9 would be to have access from ARM9-only stuff from ARM11.

 

[Urbanshadow]

Why would you want to rewrite svc calls ? And the only reason I would touch Process9 would be to have access from ARM9-only stuff from ARM11.

Better not touch any of the existing svc calls. You can, with just one address patch in p9, add a new svc call. With a proper hook, you can specify from arm11 which code should p9 run in that new svc call. And you can recover return values back to arm11.

So you can send pxi your arbitrary arm9 code, p9 will run it with full kernel9 permissions, and you get your result back. Whether the arm11 system is still functional after the call depends on your arm9 code. Perhaps your code isn't expecting to return anything or at all. There's no limit on how long the svc call should run. I don't know if its possible to pwn the system into a brahma setup from there, but I know I have physical memory R/W access. (Last tested on 10.7)

 

[Mrrraou]

Better not touch any of the existing svc calls. You can, with just one address patch in p9, add a new svc call. With a proper hook, you can specify from arm11 which code should p9 run in that new svc call. And you can recover return values back to arm11.

So you can send pxi your arbitrary arm9 code, p9 will run it with full kernel9 permissions, and you get your result back. Whether the arm11 system is still functional after the call depends on your arm9 code. Perhaps your code isn't expecting to return anything or at all. There's no limit on how long the svc call should run. I don't know if its possible to pwn the system into a brahma setup from there, but I know I have physical memory R/W access. (Last tested on 10.7)

That's not the way I would personally implement it, though. No need to add svc calls in K9 either, btw.

 

[Urbanshadow]

That's not the way I would personally implement it, though. No need to add svc calls in K9 either, btw.

Yeah I bet. This concept has been around about a year now.

I'm also guessing it would be done for a while if really needed too.