Homebrew 'ntrcardhax' / downgrading questions

[Plailect]

I've read this entire thread all the way through and I still have no idea what its purpose is or what anyone here is trying to accomplish.

 

[Kitlith]

I've read this entire thread all the way through and I still have no idea what its purpose is or what anyone here is trying to accomplish.

Its purpose is me asking for help. Really. Although, there have been a few bits of off topic...

At the moment, I'm trying to downgrade so that I can dump Process9 to do some debugging on it so I can figure out what the payload would need to be for 'ntrcardhax'.

If you don't know what that is... I suggest looking at the link to my gist in the OP.

 

[Plailect]

I am aware of what it is, and I have read the gist.

I don't know what you mean exactly by "dump Process9" but more power to you if you think you can get kernel on 10.5.

 

[Kitlith]

... but more power to you if you think you can get kernel on 10.5.

I haven't said anything about 10.5 at all. There have been some side-conversations about downgrading from 10.5, but I'm currently on 9.9. There is no way to get kernel access on 10.5 (without downgrading via some fancy NAND magic) yet.

Process9 is the process running on the arm9 processor.

 

[Plailect]

I haven't said anything about 10.5 at all. There have been some side-conversations about downgrading from 10.5, but I'm currently on 9.9. There is no way to get kernel access on 10.5 (without doing some fancy NAND magic) yet.

Process9 is the process running on the arm9 processor.

Ntrcardhax is the theoretical exploit to allow kernel access at all known versions. Seeing as memchunkhax2 works on all versions below 10.3, the only reason you could need ntrcardhax is for gaining kernel on 10.5 and 10.4, so I assumed that's what it would be used for.

I am fully aware of what Process9 is, but it's not just a single file that can be "dumped" so I was looking for a more detailed explanation as to what you're talking about.

Also, its not "NAND magic," its more "NAND science." It is also not really gaining kernel on 10.5. Instead, we are downgrading the firmware to 10.2 to allow our existing 10.2 kernel exploit to work.

 

[Kitlith]

Ntrcardhax is the theoretical exploit to allow kernel access at all known versions. Seeing as memchunkhax2 works on all versions below 10.3, the only reason you could need ntrcardhax is for gaining kernel on 10.5 and 10.4, so I assumed that's what it would be used for.

I am fully aware of what Process9 is, but it's not just a single file that can be "dumped" so I was looking for a more detailed explanation as to what you're talking about.

Also, its not "NAND magic," its more "NAND science." It is also not really gaining kernel on 10.5. Instead, we are downgrading the firmware to 10.2 to allow our existing 10.2 kernel exploit to work.

And... I ninja edited my post after I thought about how I should've mentioned that it was a downgrade, not staying at the same place... xD I called it magic because I don't know cryptography, don't have a NAND mod, and I barely know anything about that method of downgrading to try and describe it. NAND Science it is!

'ntrcardhax', as my understanding goes, requires arm11 kernel to execute. If you have a way around this, I would like to hear that! So, it's still only for <=10.3, and could be a replacement for downgrading. I was hoping I was going to be able to not downgrade, but it looks like I need to finish some research by looking inside of Process9.

My current thoughts on dumping Process9 essentially have to do with taking a ramdump of the arm9-only ram so that I have a copy of the .code and .bss (and anything else important). Sorry for not saying this sooner. ._. You may be able to tell: I'm still a noob here. I'm kind of crossing my fingers and attempting to do research on things that haven't been researched very much yet because, as @smealum said on IRC: "hardware intimidates people". I welcome help here.

I'm sorry for being very terse in my other replies. Still trying to do the blasted downgrade. I suppose I should try browserhax instead of menuhax as an entry point a few times.

 

[dark_samus3]

And... I ninja edited my post after I thought about how I should've mentioned that it was a downgrade, not staying at the same place... xD I called it magic because I don't know cryptography, don't have a NAND mod, and I barely know anything about that method of downgrading to try and describe it. NAND Science it is!

'ntrcardhax', as my understanding goes, requires arm11 kernel to execute. If you have a way around this, I would like to hear that! So, it's still only for <=10.3, and could be a replacement for downgrading. I was hoping I was going to be able to not downgrade, but it looks like I need to finish some research by looking inside of Process9.

My current thoughts on dumping Process9 essentially have to do with taking a ramdump of the arm9-only ram so that I have a copy of the .code and .bss (and anything else important). Sorry for not saying this sooner. ._. You may be able to tell: I'm still a noob here. I'm kind of crossing my fingers and attempting to do research on things that haven't been researched very much yet because, as @smealum said on IRC: "hardware intimidates people". I welcome help here.

I'm sorry for being very terse in my other replies. Still trying to do the blasted downgrade. I suppose I should try browserhax instead of menuhax as an entry point a few times.

Why would it need arm11 kernel access to work? Nothing was said about needing it, you literally cause a buffer overflow in the arm9 kernel and take control of it from there, at least that's what I gathered... Since you can send a payload over you can basically come in through the back way: attack arm9 kernel, then attack arm11 kernel (using the arm9 to do so, and it has more than enough access to just mess with memory so an actual exploit isn't needed) then once you have userland access (through other means) you can basically make the two kinda meet, then you don't need the hardware anymore once execution is gained

 

[Plailect]

And... I ninja edited my post after I thought about how I should've mentioned that it was a downgrade, not staying at the same place... xD I called it magic because I don't know cryptography, don't have a NAND mod, and I barely know anything about that method of downgrading to try and describe it. NAND Science it is!

'ntrcardhax', as my understanding goes, requires arm11 kernel to execute. If you have a way around this, I would like to hear that! So, it's still only for <=10.3, and could be a replacement for downgrading. I was hoping I was going to be able to not downgrade, but it looks like I need to finish some research by looking inside of Process9.

My current thoughts on dumping Process9 essentially have to do with taking a ramdump of the arm9-only ram so that I have a copy of the .code and .bss (and anything else important). Sorry for not saying this sooner. ._. You may be able to tell: I'm still a noob here. I'm kind of crossing my fingers and attempting to do research on things that haven't been researched very much yet because, as @smealum said on IRC: "hardware intimidates people". I welcome help here.

I'm sorry for being very terse in my other replies. Still trying to do the blasted downgrade. I suppose I should try browserhax instead of menuhax as an entry point a few times.

Everything I saw back when it was announced is that ntrcardhax is a kernel exploit and only requires userland, but maybe I am mistaken.

I understand what you're talking about regarding process9 now, I didn't quite know what you were trying to explain before but the details help.

 

[Kitlith]

Everything I saw back when it was announced is that ntrcardhax is a kernel exploit and only requires userland, but maybe I am mistaken.

I understand what you're talking about regarding process9 now, I didn't quite know what you were trying to explain before but the details help.

Well, I'm glad that helped. It is, not a kernel exploit though, but an arm9 exploit.

Why would it need arm11 kernel access to work? Nothing was said about needing it, you literally cause a buffer overflow in the arm9 kernel and take control of it from there, at least that's what I gathered... Since you can send a payload over you can basically come in through the back way: attack arm9 kernel, then attack arm11 kernel (using the arm9 to do so, and it has more than enough access to just mess with memory so an actual exploit isn't needed) then once you have userland access (through other means) you can basically make the two kinda meet, then you don't need the hardware anymore once execution is gained

To both of you: We cause a buffer overflow in the arm9 by overwriting a memory address (IO register) via arm11 kernel. I could be wrong, but I don't think you can write to the address without kernel access. At least, I believe this is what Plutoo said...?

 

[dark_samus3]

Well, I'm glad that helped. It is, not a kernel exploit though, but an arm9 exploit.



To both of you: We cause a buffer overflow in the arm9 by overwriting a memory address (IO register) via arm11 kernel. I could be wrong, but I don't think you can write to the address without kernel access. At least, I believe this is what Plutoo said...?

<dark_samu> Out of curiosity, ntrcardhax doesn't require an arm11 kernel exploit to work does it? Pretty sure it doesn't but I've been wrong before (and there isn't a whole lot of info on it)
<smea> it does

you were right

 

[Plailect]

Well, I'm glad that helped. It is, not a kernel exploit though, but an arm9 exploit.



To both of you: We cause a buffer overflow in the arm9 by overwriting a memory address (IO register) via arm11 kernel. I could be wrong, but I don't think you can write to the address without kernel access. At least, I believe this is what Plutoo said...?

Ah, that's where I was remembering wrong. Thanks for the clarification. For some reason I thought it was ARM11.

 

[Kitlith]

Well, I remember reading something by @173210 theorizing about a possible 'ntrcardhax 2.0': automatic exploitation. The idea being, if we can get arm9 to re-read the header (it telling the 3ds that "I'm actually 0x4000 bytes!") we wouldn't need arm11 kernel because we wouldn't need to overwrite that IO register. However... it seems unlikely that it would actually re-read it on the cartridge's say-so. Wait, DSi cards. Still... Also... if it did re-read the header, it might use the value that the previous header specified as the buffer size, still negating the buffer overflow. Or error out because it doesn't have that much free space in RAM... *shrugs*

Tl;DR: There may be some way, but don't count on it. Don't hype. It probably won't work.

EDIT: We'd still probably need arm11 kernel access to setup the area that arm9 would jump to. Therefore, this is most likely unworkable.

 

[cpasjuste]

Well, it hasn't been bricked in any form... yet... I just need to get it working again. So, if I don't get it working before I get home, I'm going to download the version of sysUpdater from the simple downgrading thread and use that: hopefully it has a better launch rate. ._.

Note that downgrading (n3ds only?) from below 10.3 seems to have a high risk of softbrick. You should really do your hardmod first (or update to 10.3 if possible).

 

[dark_samus3]

Note that downgrading (n3ds only?) from below 10.3 seems to have a high risk of softbrick. You should really do your hardmod first (or update to 10.3 if possible).

yeah and the reason seems to be the update nag, which he cleared

 

[cpasjuste]

yeah and the reason seems to be the update nag, which he cleared

That's good to know. Do you have more/indeep information about this ? For example why o3ds doesn't seems to be impacted.

 

[dark_samus3]

That's good to know. Do you have more/indeep information about this ? For example why o3ds doesn't seems to be impacted.

Not sure on the o3ds, it's just a theory really but so far everyone who has had problems who I've recommended to try clearing the nag has had success... anyways, my theory on it is for the same reason that FBI injection fails on consoles with the update nag: The update system actually puts the downloaded files into the folder of whatever title it's supposed to be updating, so when the system tries to uninstall the title something happens (not sure exactly what) that causes an error

 

[cpasjuste]

Not sure on the o3ds, it's just a theory really but so far everyone who has had problems who I've recommended to try clearing the nag has had success... anyways, my theory on it is for the same reason that FBI injection fails on consoles with the update nag: The update system actually puts the downloaded files into the folder of whatever title it's supposed to be updating, so when the system tries to uninstall the title something happens (not sure exactly what) that causes an error

That's a possibility. I'll update safeupdater warnings with this information anyway.

 

[Aroth]

Not sure on the o3ds, it's just a theory really but so far everyone who has had problems who I've recommended to try clearing the nag has had success... anyways, my theory on it is for the same reason that FBI injection fails on consoles with the update nag: The update system actually puts the downloaded files into the folder of whatever title it's supposed to be updating, so when the system tries to uninstall the title something happens (not sure exactly what) that causes an error

There has got to be more to it or something else going on. If a system with the update nag already had all ctrnand titles downloaded and unpacked, they could easily just forcibly "update" the system on the next boot. All they would have to do is have the nag set the update flag so that it would finish the stuff that requires a reboot on the next boot.

 

[dark_samus3]

There has got to be more to it or something else going on. If a system with the update nag already had all ctrnand titles downloaded and unpacked, they could easily just forcibly "update" the system on the next boot. All they would have to do is have the nag set the update flag so that it would finish the stuff that requires a reboot on the next boot.

*shrug* that's what I was told when investigating why FBI injection didn't work on certain consoles as well as GW downgraded NANDs... several people decrypted their NANDs and this was the case apparently, not sure if they're unpacked though

 

[Kitlith]

Well, I'm on o3DS... so (appearantly?) I shouldn't worry. Still. I'm still working on getting it to boot...

What kills me is that xerpi's linux loader using memchunkhax2 has a higher bootrate, it only fails occasionally. While this, I've only gotten past pink dots 3 times, it got stuck on 'HAX SUCCESSFUL' twice, and froze during CIA verification the third time. ._.