I want to do some exploit testing, but I have no idea how to tell an exploitable crash or a non-exploitable crash. I do have the developer ErrDisp (thanks to aureinand)
1) Enable NTRDebugger
2) Use the "list kernel exploits" command
3) ?????
4) Profit
2) Use the "list kernel exploits" command
3) ?????
4) Profit
To know whether a crash is exploitable you would have to first look at what the crash is actually causing the system to do, for example jumping to a random section of memory and executing whatever is there. Then you would have to look at whether the crash is controllable, so in this example that would mean whether you can control where it jumps or control what's in memory at that location.
There are many different causes for crashes and not all of them can be exploitable, even the ones that have potential to be exploitable can only be exploited if the crash is controllable. Most crashes won't be useful, so it takes a lot of searching and trial and error to find one that is.
However, if you want to get into 3DS hacking you should probably start by learning ARM assembly. You really do need to know assembly to figure out what the crash is doing and how to exploit it.
I'm no expert and there's a lot more to it than that, but those are the basics.
Last edited by The Real Jdbye,
Similar threads
- No one is chatting at the moment.
-
@
Psionic Roshambo:
I wonder if I could recommend that to some emulation devs that perhaps the sound could use some smoothing out to simulate those old TVs -
@
Psionic Roshambo:
I think a few of the early systems could benefit from that, at least up to the 8 bit generation, by the 16 bit generation I think TVs had gotten a lot better in almost every way
-
-
-
-
-
-
-
-
-
-
@
Xdqwerty:
it says it only works for the original R4, R4i Gold (r4ids.cn), R4iDSN (r4idsn.com) and Acekard R.P.G. -
-
-
-
-
-
@
Psionic Roshambo:
Just give it a try, but honestly if you have a 3DS you can play DS games without a card just off the internal SD card
-
-
-
-
-
-
-
